### Abstract

- Top of page
- Abstract
- Introduction
- Ionospheric Front Velocity Parameterization
- Data
- Automated Ionosphere Front Velocity Estimation Algorithm
- Results and Discussions
- Conclusions
- Appendix
- Appendix
- Acknowledgments
- References

[1] Extreme ionospheric anomalies occurring during severe ionospheric storms can pose integrity threats to Global Navigation Satellite System (GNSS) Ground-Based Augmentation Systems (GBAS). Ionospheric anomaly threat models for each region of operation need to be developed to analyze the potential impact of these anomalies on GBAS users and develop mitigation strategies. Along with the magnitude of ionospheric gradients, the speed of the ionosphere “fronts” in which these gradients are embedded is an important parameter for simulation-based GBAS integrity analysis. This paper presents a methodology for automated ionosphere front velocity estimation which will be used to analyze a vast amount of ionospheric data, build ionospheric anomaly threat models for different regions, and monitor ionospheric anomalies continuously going forward. This procedure automatically selects stations that show a similar trend of ionospheric delays, computes the orientation of detected fronts using a three-station-based trigonometric method, and estimates speeds for the front using a two-station-based method. It also includes fine-tuning methods to improve the estimation to be robust against faulty measurements and modeling errors. It demonstrates the performance of the algorithm by comparing the results of automated speed estimation to those manually computed previously. All speed estimates from the automated algorithm fall within error bars of ± 30% of the manually computed speeds. In addition, this algorithm is used to populate the current threat space with newly generated threat points. A larger number of velocity estimates helps us to better understand the behavior of ionospheric gradients under geomagnetic storm conditions.

### Introduction

- Top of page
- Abstract
- Introduction
- Ionospheric Front Velocity Parameterization
- Data
- Automated Ionosphere Front Velocity Estimation Algorithm
- Results and Discussions
- Conclusions
- Appendix
- Appendix
- Acknowledgments
- References

[2] Ground-Based Augmentation Systems (GBAS) support aircraft precision approach and landing operations within several tens of kilometers of GBAS-installed airports. GBAS augments the Global Navigation Satellite System (GNSS) Standard Positioning Service by providing differential GNSS corrections and integrity information to aviation users. The GBAS ground facility consists of typically four GNSS receivers/antennas sited at surveyed locations, a very high frequency (VHF) Data Broadcast (VDB) transmitter for sending differential corrections, integrity information, and path guidance, and software for integrity monitoring and correction generation, as illustrated in Figure 1. GBAS users improve navigation accuracy by applying these corrections to their L1 measurements. They meet their safety requirements by eliminating any system failures from their position calculations within the time to alert for the operations being conducted. The users also compute confidence bounds on their position solution based on information broadcast by the GBAS ground facility. These bounds, known as the protection levels, play a key role in assuring a required level of integrity.

[3] Residual ionospheric delay errors remaining after differential corrections are applied are almost negligible. Typical ionospheric spatial delay variations are on the order of 1 mm/km, and a conservative one sigma bound under nominal conditions is 4 mm/km [*Lee et al*., 2007]. However, unusual solar activity, such as Coronal Mass Ejections or solar flares, can cause extremely large spatial decorrelations. Gradients as large as 412 mm/km at high elevation and 360 mm/km at low elevation [*Pullen et al*., 2009; *Lee et al*., 2011a] were observed during the severe ionosphere storms of November 2003. For a GBAS user at the minimum decision height (for Category I precision approaches) of 200 ft and separated by 6 km from the GBAS ground facility, a spatial gradient of 412 mm/km could cause a residual range error of 0.412 m/km × 20 km (6 + 14 km due to the memory of code-carrier smoothing filter) = 8.2 m [*Pullen et al*., 2009]. This anomalous event, if undetected, could be a potential threat to GBAS users by producing unacceptably large position errors when combined with the worst-case satellite geometries and aircraft approach timing with respect to the ionospheric front motion.

[4] To understand the impact of this event to GBAS users and to design monitors to detect it, an ionospheric anomaly “threat model” was generated for GBAS Category (CAT) I precision approaches [*RTCA*, 2004] in the Conterminous United States (CONUS) [*Datta-Barua et al*., 2010]. This threat model is used to predict the worst-case position errors that GBAS users might suffer in the presence of ionospheric anomalies and to determine potentially hazardous satellite geometries. These unsafe geometries are removed by inflating one or more broadcast integrity parameters, and thus, the hypothetical errors under worst-case conditions are mitigated [*Lee et al*., 2011b]. The position-domain geometry screening scheme can be improved by inflating satellite-specific broadcast parameters instead of inflating parameters common to all satellites. This new targeted parameter inflation method, recently proposed, determines satellite-specific inflation factors by solving optimization problems and resulting in minimizing the availability penalty [*Seo et al*., 2012].

[5] The ionospheric anomaly as seen by a GBAS installation is modeled as a spatially linear semi-infinite front (parameterized by the gradient or “slope” of the ramp and its width) moving with constant propagation speed, as shown in Figure 2. A detailed data analysis procedure was developed to determine the upper bounds of these parameters, and a comprehensive analysis of days with ionospheric disturbances took several years to obtain the current set of threat model bounds [*Datta-Barua et al*., 2010]. While the magnitude of the gradient and its statistical distribution have been studied extensively by many researchers [*Pullen et al*., 2009; *Lee et al*., 2006; *Yoshihara et al*., 2010], the front velocity under ionospheric storm conditions has not been examined to the same degree. Existing GBAS ground monitors measure the time rate of change of ionospheric delays to detect ionospheric threats [*Luo et al*., 2005]. Thus, this monitor performance and resulting errors vary with the ionospheric front speed relative to the speed of the ionospheric pierce point (IPP), which is a theoretical point where an ionosphere thin shell model and a line of sight between a receiver and a satellite intersect. The orientation of the front with respect to the aircraft and runway and the approach direction of the front with respect to the GBAS ground facility are also important parameters in GBAS impact simulations.

[6] Since the CONUS threat model was based on only the last decade of observed anomalies (GNSS network stations were not dense enough to observe anomalous spatial gradients prior to the last solar cycle) and the peak of the next solar cycle is expected in around 2013, ionospheric data should be analyzed continuously going forward as long as system integrity relies on an empirically driven threat model. A Long-term Ionospheric Anomaly (LTIA) monitor software package was developed to validate and update this threat model over the life cycle of the system by monitoring ionospheric behavior continuously [*Jung and Lee*, 2012]. This tool focuses on estimating ionospheric gradient magnitudes and automatically detecting gradients large enough to be hazardous to users. A two-station-based method was previously developed to estimate front speed, but this requires manually estimated front orientation as an input [*Datta-Barua et al*., 2010]. Since this manual estimation requires time-intensive effort, the ionosphere front velocity computation needs to be automated when processing the vast amount of data.

[7] An automated procedure for computing ionospheric anomaly front velocity is required to obtain a larger number of velocity estimates, better understand ionospheric behavior, and derive area-specific threat models for all regions where GBAS will become operational. This paper presents a methodology to estimate ionospheric threat front velocity automatically and validates its performance by comparing results to those manually computed previously. Section 2 defines the front velocity parameters. Section 3 introduces the data used to estimate ionospheric front velocities and reviews the LTIA monitor which generates the inputs to front velocity computation in this study, which are ionospheric delay estimates for pairs of stations that appear to observe large spatial gradients in delay. Section 4 explains the automated front velocity estimation procedure in detail. Section 5 presents the results from case studies, evaluates the performance of the algorithm, and populates the current threat space with newly generated threat points by calculating their velocities. Section 6 provides the conclusions of this paper.

### Ionospheric Front Velocity Parameterization

- Top of page
- Abstract
- Introduction
- Ionospheric Front Velocity Parameterization
- Data
- Automated Ionosphere Front Velocity Estimation Algorithm
- Results and Discussions
- Conclusions
- Appendix
- Appendix
- Acknowledgments
- References

[8] Based on the observations made during the ionospheric storms in 2000–2004 [*Datta-Barua et al*., 2002, 2010], an ionospheric front is approximated as a straight and semi-infinite line that moves with constant speed, to first order, relative to the ground. Models with curved front lines or time-varying speeds may fit segments of actual data better. However, these simplifications were made to enable easier estimation of front velocities and assessment of user position errors through GBAS impact simulation tools. Moreover, these approximations are reasonable (to first order) for the short duration of an aircraft approach (a few hundred seconds) and within the local area of a few tens of kilometers.

[9] Figure 3 shows a map of vertical ionospheric delay over the eastern United States during the severe 20 November 2003 ionospheric storm. Color contours represent meters of code-phase vertical delay on GPS L1-frequency measurements from low (blue) to high (red) delays. Extremely large spatial gradients were observed on both the leading (westward) and trailing (eastward) edges of the finger-shaped feature of enhanced delay. These approximately straight edges in horizontal direction can be modeled as a linear semi-infinite wedge where sharp transitions from small to large delay errors occur. The storm fronts whose edges run roughly northwest to southeast recede toward the southwest at an average speed of between 100 and 200 m/s with substantial local variation [*Pullen et al*., 2009; *Datta-Barua et al*., 2010].

[10] The movement of ionospheric fronts can be approximated by estimating the front velocity model parameters described in Figure 4 and Table 1. The ionospheric wavefront, illustrated in Figure 4, is inclined and moves in a southwest direction, as indicated with a solid arrow. A GNSS satellite in this example moves toward the northeast; thus, the ionospheric pierce point (IPP), the point where the line-of-sight vector and the theoretical model of the ionosphere as a “thin shell” intersect (see Appendix A), also moves in the same direction, as shown in a dashed arrow (denoted with “IPP track”). To describe the ionospheric front motion, four parameters are defined: (1) the orientation of the ionospheric front, *i*, (2) the speed of the ionospheric front normal to the front, *V*_{n}, (3) the direction of IPP motion, *α*, and (4) the speed of the IPP, *V*_{ipp}. The orientation of the front, *i*, is the angle between the *y* axis and the front (measured in a counterclockwise direction starting from the *y* axis). The direction of IPP motion, *α*, is the angle between the *x* axis and the vector describing the direction of IPP motion direction (measured in a counterclockwise direction starting from the *x* axis). Note that *V*_{n} contains the velocity component resulting from the movement of the satellite in addition to that from actual ionospheric front motion. Thus, the speed and direction of the IPP must be computed, and the component of IPP speed to the *V*_{n} direction should be removed (see section 4.6). The resulting front speed estimates are then referenced to a fixed point on the ground.

Table 1. Definition of Ionospheric Front Velocity ParametersParameter | Definition |
---|

*i* | Orientation of Ionospheric Front |

*V*_{n} | Speed in Normal Direction of Ionospheric Front |

*α* | Direction of Ionospheric Pierce Point (IPP) |

*V*_{ipp} | Speed of Ionospheric Pierce Point (IPP) |

[11] A three-station-based trigonometric method [*Ene et al*., 2005] was originally developed to estimate the speed and direction of ionospheric fronts. Speed is computed by measuring the travel time during which the ionospheric wavefront sweeps through a pair of stations, and the third station is used to observe the direction of the front. However, this algorithm often returns faulty results corrupted by measurement errors and errors in the approximations made by the simplified front threat model (i.e., the front is assumed to be a straight line and to move with a constant speed relative to the ground). Especially when a perfectly straight front is extended to impact three stations, a small measurement error causes the estimate of front direction to deviate significantly from the truth.

[12] To improve estimation accuracy, a manual two-station-based method was used in the development of the CONUS threat model [*Datta-Barua et al*., 2010]. This method first manually estimates front orientation using measurements from more than three stations and then computes its speed after setting the orientation. Measurements which contain errors are manually adjusted by human judgment to avoid faulty results which can be worsened by the discrepancy between an actual front and its simplified model. However, the manual method may introduce additional errors due to imperfect human intuition and is not adequate for processing large amounts of data continuously. This paper proposes an automated procedure of ionospheric front velocity computation by combining both the three-station-based method (used for orientation estimation) and the two-station-based method (used for speed estimation). The detailed algorithms will be described in section 4.

### Data

- Top of page
- Abstract
- Introduction
- Ionospheric Front Velocity Parameterization
- Data
- Automated Ionosphere Front Velocity Estimation Algorithm
- Results and Discussions
- Conclusions
- Appendix
- Appendix
- Acknowledgments
- References

[13] High-precision ionospheric delay measurements are used to estimate ionospheric anomaly front velocity in this paper. A group of nearby stations viewing the same satellite experiences similar ionospheric delay patterns which are shifted in time when an ionospheric wavefront sweeps over the stations. The propagation speed can be computed by measuring those time shifts (i.e., the travel time of the front from one station to another) and travel distances across the stations. More details are provided in section 4.2. Precise estimates of ionospheric delays can be obtained using dual-frequency GPS observations collected from networks of stations and sophisticated data-processing algorithms. This paper uses two types of precise ionospheric delay estimates: “Supertruth” data for validating performance of the proposed ionosphere front velocity estimation algorithm and “simple Truth” data for computing the automated velocity estimates and generating new ionospheric anomaly threat points.

[14] The current CONUS threat model for GBAS CAT-I approaches was determined by analyzing ionospheric delay measurements generated by the NASA's Jet Propulsion Laboratory Supertruth processing algorithm [*Komjathy et al*., 2004, 2005; *Datta-Barua et al*., 2010]. The GPS measurements collected from the network of Continuously Operating Reference Stations (CORS) and the Wide Area Augmentation System reference stations were processed using JPL's GPS Inferred Positioning System module Sanity Edit and the global ionosphere mapping software to provide high-precision dual-frequency ionospheric delay estimates. These Supertruth data were used again in this study to compare the velocity estimates obtained from the newly proposed method to those previously determined and included in the current threat model (see section 5.2).

[15] Unlike the previous manual analysis performed to build the CONUS threat model, the Long-term Ionospheric Anomaly (LTIA) monitor has been designed to examine all possible station pairs automatically; thus, the LTIA monitor identified many more ionospheric gradient threat points than those discovered previously [*Jung and Lee*, 2012]. To determine the ionospheric front velocities of all ionospheric anomalies observed, we use ionospheric delay estimates obtained from the LTIA monitoring tool as inputs to the automated ionosphere front velocity computation algorithm. These precise ionospheric delay measurements, called simple Truth data, are created by processing GPS observation data collected from the CORS network using a simpler and faster algorithm implemented in the LTIA monitor. The quality of simple Truth was proven to be sufficiently accurate to identify ionospheric anomalies by comparing it to Supertruth data generated by the off-line postprocessing approach for several sets of raw measurements [*Jung and Lee*, 2012].

[16] The dates on which data were analyzed to define the current threat model are shown in Table 2. The ionosphere is coupled to the magnetosphere, which is driven by the solar wind. Thus, unusual geomagnetic activity indicates when ionospheric disturbances are probable. These dates were selected based on two indices of global geomagnetic activity: planetary *K* (*Kp*) and *disturbance*, *storm time* (*Dst*). *Kp* represents solar particle effects on the Earth's magnetic fields and ranges from 0 (no activity) to 9 (extreme activity) in thirds of an index unit [*Menvielle and Berthelier*, 1991]. *Dst* measures worldwide magnetic disturbance derived from low-latitude horizontal magnetic variation [*Sugiura and Kamei*, 1991]. A negative *Dst* with a higher magnitude indicates that a more intense magnetic storm is in progress. The level of storm intensity is scaled with geomagnetic storm class (minor, moderate, strong, severe, and extreme) based on the measured *Kp* index.

Table 2. Ionospheric Storm Dates Analyzed and Corresponding Geomagnetic Storm ConditionsDay (UT mm/dd/yy) | *Kp* | *Dst* | Geomagnetic Storm Class |
---|

04/06/00 | 8.3 | −287 | Severe |

04/07/00 | 8.7 | −288 | Extreme |

07/15/00 | 9.0 | −289 | Extreme |

07/16/00 | 7.7 | −301 | Strong |

09/07/02 | 7.3 | −163 | Strong |

10/29/03 | 9.0 | −345 | Extreme |

10/30/03 | 9.0 | −401 | Extreme |

10/31/03 | 8.3 | −320 | Severe |

11/20/03 | 8.7 | −472 | Extreme |

07/17/04 | 6.0 | −80 | Moderate |

### Automated Ionosphere Front Velocity Estimation Algorithm

- Top of page
- Abstract
- Introduction
- Ionospheric Front Velocity Parameterization
- Data
- Automated Ionosphere Front Velocity Estimation Algorithm
- Results and Discussions
- Conclusions
- Appendix
- Appendix
- Acknowledgments
- References

[17] The automated algorithm for estimating ionospheric wavefront velocity consists of six steps: clustering nearby stations, grouping stations by pattern recognition, ionospheric pierce point (IPP) speed and direction estimation, orientation determination, propagation direction determination, and speed computation. The methodologies used in each corresponding step are listed to the right of the list of steps in Figure 5. Station pairs from which extremely large ionospheric spatial gradients are observed and the ionospheric delay observables of those pairs are taken as inputs to the automated algorithm. The four parameters in boxes with dotted lines in Figure 5 that describes the speed and direction of the IPP (*V*_{ipp}, *α*) and the orientation and speed of the ionosphere front (*i*, *V*_{n}) are computed from the six steps of this procedure. Once all four parameters are determined, the algorithm finally computes an ionospheric front speed estimate (*V*_{iono}) relative to a fixed point on the ground by removing the velocity component resulting from satellite (and thus IPP) movement. The details of each step are described in the following sections.

#### Clustering Nearby Stations

[18] The automated ionosphere front velocity estimation algorithm first searches for nearby reference stations whose distances from the station pair (from which an extremely large gradient was observed and thus selected as an input to the velocity estimation algorithm) are less than a predefined threshold (e.g., 300 km). A cluster of stations within close proximity of each other would experience similar ionospheric behavior in the presence of an ionospheric storm. The underlying assumption in this step is that the model of a linear, semi-infinite front with constant speed is valid over this local area.

#### Grouping Stations by Pattern Recognition

[19] From the chosen cluster of nearby stations, we subselect a group of stations that show a similar ionospheric delay pattern. Figure 6a shows the time history of ionospheric delay measurements observed from five nearby CORS stations as they tracked GPS Space Vehicle Number (SVN) 46 during the storm of 20 November 2003, and Figure 6b illustrates an ionospheric wavefront impacting those stations in order. Because these stations were affected by the same ionospheric wavefront, they exhibit a similar trend of estimated ionospheric delays. Grouping stations whose delay patterns are similar was done manually in prior work, and thus, it was a time-consuming task. We implement a *k*-means algorithm, a well-known pattern recognition technique, to automate the selection of stations to be used for ionosphere front velocity computation. The details of applying the *k*-means algorithm are described in Appendix B.

[20] The growth in delays associated with the passing of the leading edge of the wavefront is shown in Figure 6a. The delays of each station reach the maximum values (denoted with “P” in Figure 6a) and rapidly decrease in about half an hour while passing through the trailing edge of the front. The peak delay times, *t*_{peak _ j}, at which the slant delay of the station *j* reached the local maximum values are recorded. The order in which the stations were affected by the front, denoted with the numbers following the four-character station IDs in Figure 6b, are deduced from *t*_{peak_ j}. This order and the locations of the affected stations determine the forward propagation direction of the motion, and the travel times of the front from one station to the others (which can be estimated from *t*_{peak_ j}) are used to estimate the speed of the front.

[21] The accurate measurement of *t*_{peak_ j} is important in the computation of ionosphere front velocity. However, the observed *t*_{peak_ j} and the sequence of affected stations may violate the simplified model of the front as a straight line moving with constant speed, which is not true in reality. The slant delays may also have multiple peaks (i.e., more than one local maximum or minimum) within continuous arcs. Moreover, the peak times of multiple stations sometimes occur concurrently. This ambiguity, which can be caused by faulty measurements as well as modeling errors, requires the peak delay times to be carefully adjusted; thus, this algorithm includes an automated fine tuning of *t*_{peak_ j} considering the underlying assumption.

[22] The cases which require this fine tuning mainly fall into three categories: mismatches in the order of observed *t*_{peak_ j} and stations impacted, the same peak times of multiple stations, and multiple peaks at a station. As an example, in Figure 4, the front sweeps through Station 1 first, followed by Station 2, and then Station 3. The order of the peak delay times observed from the stations and the location of stations usually match. However, if the peak delay time of Station 3 is earlier than that of Station 2, this observation is physically impossible under the assumptions made to the front model even if the front moves backward because the front has to pass Station 2 before it reaches Station 3. Thus, in this case the order of the peak delay times is adjusted in a way that the peak of Station 3 occurs after that of Station 2. Due to the low data rate (30 s interval) of measurements, the peak delay times of multiple stations may appear to occur simultaneously, resulting in a zero travel time and an infinite speed. The peak delay times are adjusted in these cases as well.

[23] The underlying principle of fine-tuning method applied is essentially the same for all those cases. It first computes the orientation of the ionospheric front as described in section 4.4. After placing the front at the first station impacted and fixing the orientation of the front, distances between the first station and all other stations projected onto the line perpendicular to the front are measured. Then the peak delay times are rearranged based on those distances and the travel times from the first station to the other stations. This method improves the accuracy of front speed estimation by reducing measurement errors assuming the front model is correct. Continuing work will investigate the amount and effect of modeling errors and methods to mitigate those errors under real-world conditions.

#### IPP Speed and Direction Estimation

[24] The velocity of ionospheric pierce point (IPP) can be directly estimated from the geometry between a station and a GPS satellite and the known orbital motion of the satellite. The detailed steps are described in Appendix A.

#### Orientation Determination

[25] This step determines the orientation, *i*, of the ionospheric front using the three-station-based method [*Ene et al*., 2005]. As noted before, orientation estimation is highly sensitive to even small measurement errors, and the resulting faulty estimate can be aggravated by the difference between an actual front and the simplified model. Since this discrepancy tends to be less significant as the distance and duration of front travel get shorter, orientation estimation is done only once using the first three stations impacted and is then fixed when estimating other front velocity parameters. In Figure 4, the ionospheric front sweeps through Station 1, Station 2, Station 3, and then other stations (denoted with triangles) in sequence. The Cartesian local horizontal coordinate, , is the location of the station. The distances of Stations 2 and 3 measured from Station 1 in *x* and *y* axes are expressed as

- (1)

[26] The travel time of the front measured from the peak delay time of Station 1 to the peak delay time of Station *j* + 1 is given by equation ((2)).

- (2)

[27] The distance between the three stations and the travel time are used to compute the orientation, *i*, in degrees, and the speed in the normal direction of the front, *V*_{n}, as shown in equation ((3)).

- (3)

[28] Under the assumption that the direction of ionospheric wavefront motion does not vary within a local area, we fix the orientation parameter, *i*, obtained in this step and solve for the speed of the front using the two-station-based method (see section 4.6).

#### Propagation Direction Determination

[29] Once the orientation of the ionospheric front is determined, this next step is to estimate the forward propagation direction of the front by using the order of peak delay times and the known locations of the stations. However, the order of front impact at the stations does not always agree with the assumption of constant-velocity front motion. This mismatch mainly is caused by measurement errors. Any stations that produce faulty measurements are removed by applying a linear programming concept in which a feasible region is defined by a set of linear constraints [*Vaserstein*, 2003].

[30] Figure 7 illustrates an example of determining front propagation direction. The order, *m* (numbers shown to the right of stations), in which the stations are hit by the front is determined based on peak delay times. According to the order of impact and the location of stations, the front in this figure appears to propagate southwestward until it impacts the third station and then moves backward in a northeastward direction until the front hits the fourth station. This scenario is not feasible under the assumption that the ionospheric front moves in a constant propagation direction during a short time period. This implies that the fourth station observed faulty measurements; thus, it should be removed to accurately estimate the propagation speed of the front. Note that we basically assume that the observations from the first three stations are correct in this step and try to discard stations which do not fit to the propagation direction. Thus, any faulty measurements observed from the first three stations should be corrected by the fine-tuning method.

[31] To create a linear constraint, a line representing the ionospheric front with an orientation of *i* in Figure 7 is defined in a local coordinate frame that takes the location of Station 1 as the origin of the coordinate plane. When the front impacts Station 1, the front line is expressed as

- (4)

[32] The coordinates of stations when substituted in equation ((4)) make the left side of the equation negative (i.e., a minus sign) except for the case of Station 4. Thus, a feasible region is defined to be the lower side of the front line (the shaded area) in Figure 7. Any coordinates in this area satisfy the linear inequality constraint defined by

- (5)

[33] Station 4, which is not in this feasible region, is discarded, and the forward propagation direction of the front is determined to be southwest. Note that a numerical value of propagation direction is not estimated in this step.

#### Speed Computation

[34] A range of possible front speeds that are normal to the ionosphere front is obtained by constructing all feasible pairs of stations and computing speeds for each pair using the two-station-based method. Since the orientation of the front, *i*, is given from section 4.4, equation ((3)) can be modified to compute the speed in the normal direction, *V*_{n}, for a pair of stations (1, *j* + 1), given by equation ((6)).

- (6)

[35] The total number of stations which show a similar ionospheric delay pattern, *m*, is determined from section 4.2. The numerator of equation ((6)) represents the distance between two stations projected onto the line perpendicular to the front, and the denominator is the travel time of the front given by equation ((2)).

[36] Based on the assumption of constant propagation speed, we take the mean value of the resulting speed estimates obtained from equation ((6)). As discussed above, this speed estimate contains the velocity component resulting from the movement of the GPS satellite in addition to that from actual front motion with respect to the ground. Thus, after removing the component of the IPP velocity from the mean value, as shown in equation ((7)) and in Figure 4, we finally obtain the speed estimate of the ionospheric front, *V*_{iono}, referenced to a fixed point on the ground.

- (7)

[37] The method to compute the direction of the IPP, *α*, and the speed of the IPP, *V*_{ipp}, is described in Appendix A.

### Conclusions

- Top of page
- Abstract
- Introduction
- Ionospheric Front Velocity Parameterization
- Data
- Automated Ionosphere Front Velocity Estimation Algorithm
- Results and Discussions
- Conclusions
- Appendix
- Appendix
- Acknowledgments
- References

[44] This paper presents an automated ionospheric front velocity estimation algorithm and shows test results obtained by processing data from the CONUS ionospheric storm archive. The algorithm automatically selects a group of stations that exhibit a similar ionospheric delay pattern, determines the propagation direction of the front, and computes the orientation and speed for the front. The necessity for developing an automated front speed estimation algorithm comes from the vast amount of data to be processed in the near future. Ionospheric threat models must be derived for all regions where GBAS will become operational. In addition, because the CONUS threat model was based on only the last decade of observed anomalies, ionospheric data should be analyzed continuously going forward.

[45] This paper has examined the performance of this automated algorithm by comparing its results (parameterized by front speed, orientation, and propagation direction) to manually computed speeds for the same inputs and showed the robustness of the algorithm against measurement errors and violation of the underlying assumptions of the simplified front model (the front is assumed to be a straight line and to move with constant speed relative to the ground). While this paper uses the simple wedge model to describe ionospheric storm fronts, more work is needed to expand this model or introduce different models to cover other types of anomalous events (e.g., plasma bubbles in equatorial regions). This algorithm also has been used to populate the current threat space with newly generated threat points obtained from the Long-Term Ionospheric Anomaly Monitoring tool. A larger number of velocity estimates, produced by the automated data processing, will help to better understand the motion of ionospheric wavefronts under geomagnetic storm conditions. It is expected to benefit future GBAS development and deployment by fully utilizing the available data to better understand the wide range of ionospheric behavior.

### Acknowledgments

- Top of page
- Abstract
- Introduction
- Ionospheric Front Velocity Parameterization
- Data
- Automated Ionosphere Front Velocity Estimation Algorithm
- Results and Discussions
- Conclusions
- Appendix
- Appendix
- Acknowledgments
- References

[57] The authors thank John Warburton of the Federal Aviation Administration (FAA) William J. Hughes Technical Center and his team for their support. We also would like to thank Leo Eldredge, Carlos Rodriguez, Jason Burns, Tom Dehel, Barbara Clark, Hamza Abduselam of the FAA, Oliver Jeannot, Cedric Lewis, Dieter Guenter, and Achanta Raghavendra of the AMT Tetra Tech, Attila Komjathy of the Jet Propulsion Laboratory, and Per Enge, Sam Pullen, Todd Walter, and Juan Blanch of Stanford for their support of this work. The opinions expressed in this paper are solely those of the authors and do not necessarily represent those of the FAA. Eugene Bang was supported by Basic Science Research Program through the National Research Foundation of Korea (NRF) funded by the Ministry of Education, Science and Technology (2012–0007550).