Methodology of automated ionosphere front velocity estimation for ground-based augmentation of GNSS



[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.

1 Introduction

[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.

Figure 1.

Illustration of a typical Ground-Based Augmentation Systems (GBAS) configuration (reproduction of Figure 1 of Jung and Lee [2012]).

[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.

Figure 2.

Illustration of a GBAS user impacted by an ionospheric front.

[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.

2 Ionospheric Front Velocity Parameterization

[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].

Figure 3.

Enhanced vertical ionospheric delay during 20 November 2003 ionospheric storm (reproduction of Figure 1 of Pullen et al. [2009]).

[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, Vn, (3) the direction of IPP motion, α, and (4) the speed of the IPP, Vipp. 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 Vn 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 Vn direction should be removed (see section 4.6). The resulting front speed estimates are then referenced to a fixed point on the ground.

Figure 4.

Illustration of ionospheric front velocity parameters.

Table 1. Definition of Ionospheric Front Velocity Parameters
iOrientation of Ionospheric Front
VnSpeed in Normal Direction of Ionospheric Front
αDirection of Ionospheric Pierce Point (IPP)
VippSpeed 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.

3 Data

[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 Conditions
Day (UT mm/dd/yy)KpDstGeomagnetic Storm Class

4 Automated Ionosphere Front Velocity Estimation Algorithm

[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 (Vipp, α) and the orientation and speed of the ionosphere front (i, Vn) are computed from the six steps of this procedure. Once all four parameters are determined, the algorithm finally computes an ionospheric front speed estimate (Viono) 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.

Figure 5.

Automated ionosphere front velocity estimation algorithm.

4.1 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.

4.2 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.

Figure 6.

(a) Dual-frequency estimates of slant ionospheric delay from simple Truth data versus UT hour for nearby stations tracking SVN 46. (b) Illustration of modeled ionospheric wavefront impacting the stations in series.

[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, tpeak _ 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 tpeak_ 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 tpeak_ j) are used to estimate the speed of the front.

[21] The accurate measurement of tpeak_ j is important in the computation of ionosphere front velocity. However, the observed tpeak_ 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 tpeak_ j considering the underlying assumption.

[22] The cases which require this fine tuning mainly fall into three categories: mismatches in the order of observed tpeak_ 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.

4.3 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.

4.4 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, math formula, 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

display math(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)).

display math(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, Vn, as shown in equation ((3)).

display math(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).

4.5 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.

Figure 7.

Illustration of applying linear programming to remove any stations whose observations do not fit with the assumption of a front moving in a constant direction of propagation.

[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

display math(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

display math(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.

4.6 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, Vn, for a pair of stations (1, j + 1), given by equation ((6)).

display math(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, Viono, referenced to a fixed point on the ground.

display math(7)

[37] The method to compute the direction of the IPP, α, and the speed of the IPP, Vipp, is described in Appendix A.

5 Results and Discussions

5.1 Case Study: 20 November 2003 Ionospheric Storm

[38] In this section, we analyze a case study following the process described in section 4. On 20 November 2003, the most extreme ionospheric gradient known to have occurred during the previous solar cycle was observed between a pair of CORS stations, GARF, and ZOB1, while viewing SVN 38 [Pullen et al., 2009; Jung and Lee, 2012]. Thus, the LTIA monitor returns this pair of stations as one of input pairs to the ionosphere front velocity estimation algorithm along with all other station pairs which observed anomalous ionospheric gradients. Given the station pair GARF and ZOB1, the algorithm searched for nearby stations in northern Ohio/Michigan within a circle with a radius of 300 km (centered at the midpoint of the pair), and the resulting number of stations was 38. Ionospheric delays on L1 measurements between these stations and SVN 38 were processed by the k-means algorithm to select a group of 16 stations which exhibited a similar trend of ionospheric delays with those of the input stations GARF and ZOB1.

[39] Figure 8 shows the results from the step of “Grouping Stations by Pattern Recognition.” The slant ionospheric delay estimates (the simple Truth solution generated by the LTIA monitor) observed by the 16 CORS stations that showed similar delay patterns to those of stations GARF and ZOB1 are plotted over time on the left-hand side of the figure. As the leading edge of the front (the finger-shaped feature in Figure 3) passes over these stations, the delays rapidly grow in just under an hour. A lengthy interval of erratic variation in the ionospheric delays is then observed within the feature while the overall delays remain high, followed by a sudden, steep dropoff corresponding to the trailing edge of the front. The remaining 22 stations that have different ionospheric delay patterns from those of this pair, as shown on the right-hand side of Figure 8, are properly excluded by this algorithm. The 16 stations were located mostly under the finger-shaped feature of enhanced delay around 20:15 UT on 20 November 2003 (i.e., the red region in Figure 3), while other excluded stations were at the border or outside of the feature and thus experienced different ionospheric delay patterns.

Figure 8.

Example results from Grouping Stations by Pattern Recognition step of the automated algorithm on 20 November 2003. The left-hand plot shows slant ionospheric delays whose patterns are similar to those of GARF and ZOB1, and the right-hand plot shows delays with different patterns from those of GARF and ZOB1.

[40] The locations of the 16 CORS stations selected by pattern recognition are denoted with circles in Figure 9. Among these stations, the first five stations in order of impact by the ionospheric front (shown as filled circles) were used for estimating the velocity of the front. The step of “Clustering Nearby Stations” started the search over a large area to acquire a sufficient number of stations to estimate the front velocity, because it is not known which stations would exhibit similar delay patterns at the beginning. However, the validity of the underlying assumption that a linear, semi-infinite front moves with constant speed gets weaker as the area of travel expands farther. Thus, we reduce the area by limiting the number of stations, m in equation ((6)), to five when forming pairs of stations for speed computation. The numbers shown to the right of the four-character station IDs indicate the order in which the five stations were impacted by the front, which is illustrated as a straight bar.

Figure 9.

Locations of 16 CORS stations (circles) which exhibit a similar trend of ionospheric delays. The first five stations (filled circles) in order of impact by the front are used for estimating front velocity.

[41] Figure 10 presents the dual-frequency ionospheric delay estimates of the five selected stations tracking SVN 38. This figure zooms in to focus on the delays right before the sudden falloff around 21:00 UT in Figure 8. The local maximum peak points denoted with a capital P were used to compute the speed and direction of the “trailing edge” front that caused this sudden drop. As shown in Figures 9 and 10, the order of peak delay times agrees well with the station locations under the assumption of constant propagation direction. Accordingly, the orientation of the front, i, of 21° and the forward propagation direction toward the southwest should be reasonably accurate in this local region along with other velocity parameters as shown in Table 3. After removing the component of the IPP velocity, Vipp, from the wavefront speed in normal direction, Vn, the resulting front speed referenced to a fixed point on the ground, Viono, is about 551.43 m/s. The negative sign of α and the positive sign of Viono indicate that SVN 38 moved southeastward and the wavefront progressed southwestward, respectively.

Figure 10.

Dual-frequency estimates of slant ionospheric delay from simple Truth data versus UT hour for five CORS stations tracking SVN 38. The local maximum peak points of delays used for speed computation are denoted with P.

Table 3. Front Velocity Computation Results From the Case Study Conducted on 20 November 2003 Ionospheric Storm With the Input Pair of Stations, GARF, and ZOB1
α (deg)−81.66
Vipp (m/s)74.00
i (deg)21.00
Vn (m/s)535.21
Viono (m/s)551.43

5.2 Performance Validation

[42] To examine the performance of the automated algorithm, we obtained automated velocity estimation results for the ionospheric anomaly threat points of the current CONUS threat space [Datta-Barua et al., 2010, Figure A1a] and compared these estimates to those manually computed previously. Figure 11 displays the ionospheric front speeds estimated using the automated algorithm and simple Truth data (denoted with circles) and those computed manually using Supertruth data (denoted with diamonds) for all 34 threat points originally included in the CONUS threat model (in no particular order). All speed estimates from the automated algorithm fall within error bars of ±30% of the manually estimated speeds, except in a few cases with relatively small speeds of less than approximately 30 m/s where the lack of pronounced front motion makes speed estimation difficult. Furthermore, the mean of the deviation of automatically estimated speeds relative to manually estimated speeds is 19.9% of the manually computed speeds. Note that the peak delay times and the sequence of the peaks were carefully adjusted in the prior work of manual estimation considering uncertainties caused by faulty measurements and the violation of assumptions made to the front model. Considering that these adjustments are difficult to be made perfectly in either manual or automated speed estimation when significant inconsistencies between the actual ionospheric front and the model of the front exist, the results shown in Figure 11 suggest that the automated algorithm is sufficiently accurate and robust against faulty measurements and modeling errors.

Figure 11.

Comparison between front speed estimates obtained from the automated algorithm and those computed manually.

[43] The automated algorithm was used to investigate the multiple storm days in CONUS listed in Table 2, and the results are summarized in Figure 12 by populating the threat space with ionospheric anomaly threat points observed in CORS data. The threat points are plotted as a function of ionospheric gradient (mm at L1 per km) and front speed with respect to the ground (m/s). Unlike previous manual analysis, the LTIA monitor examined all possible stations pairs and thus identified more pairs than those discovered previously. The automated algorithm computed ionospheric front velocities for these station pairs between which anomalously large ionospheric gradients were observed. In addition to the 34 threat points previously validated and included in the development of the current CONUS threat model (shown as diamonds), 58 additional threat points (shown as squares) were generated by the automated algorithm. The resulting speed estimates are well within the bounds (750 m/s) of the current threat space.

Figure 12.

Ionospheric anomaly threat points included in the current CONUS threat model (diamonds) and threat points newly generated from the automated algorithm (squares) as a function of ionospheric gradient and front speed.

6 Conclusions

[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.

Appendix A

Computation of Ionospheric Pierce Point (IPP) Velocities

[46] Under nominal conditions, the ionosphere is approximated with reasonable accuracy as a thin shell surrounding the Earth with a mean ionosphere height, Hiono, where the F2 layer which has the highest density of plasma is located. An ionosphere pierce point (IPP) is defined as the point where a line-of-sight vector from a station to a satellite and the spherical shell intersect, as shown in Figure A1. The zenith angle of the satellite at the IPP is denoted as χ, and the Earth-centered angle between the station and the IPP is denoted as ψ. In addition, let us assume the position vector of the reference station, denoted as math formula is given in geodetic Latitude-Longitude-Altitude (LLA) coordinates. The angles χ and ψ are calculated as follows [Misra and Enge, 2006]. First, the radius of the Earth at the reference station is given by

display math(A1)

where the average Earth radius (AE) of 6378.137 km is adjusted by taking the oblateness of the Earth into account and Latref is the latitude of the reference station. From Figure A1, by the law of sines,

display math(A2)

where Hiono of 350 km is used.

Figure A1.

Ionosphere thin shell model and definition of ionosphere pierce point (IPP).

[47] The zenith angle (angle relative to zenith) of the satellite at the station, ξ, or the complement of the elevation angle, El, is expressed as

display math(A3)

From equations (A1)), ((A2), and ((A3)), the zenith angle of the satellite as viewed from the IPP is given by

display math(A4)

[48] Next, the Earth-centered angle between station and IPP is computed as

display math(A5)

[49] The latitude and longitude of the IPP can be calculated using the following formulas:

display math(A6)

and Az is the azimuth angle of the satellite at the station. Latref and Lonref are the latitude and longitude of the reference station, respectively.

[50] Using the position vectors of the IPP at different epochs, we can compute its velocity. Let us denote the IPP position at time t1 to be math formula and the IPP position at time t2 to be math formula in the geodetic Latitude-Longitude-Altitude (LLA) coordinate frame:

display math(A7)

[51] A vector pointing in the direction of IPP motion can be defined by taking the difference of these two vectors:

display math(A8)

[52] The difference vector, math formula, can be transformed from LLA to North-East-Down (NED) local coordinates by taking the geodetic LLA of the IPP at time t1 as the origin of the NED coordinate system [Vallado, 2007]. Finally, the speed, VIPP, and the direction, α, of the IPP are calculated by

display math(A9)
display math(A10)

where the angle α is zero in the direction of east and increases in a counterclockwise rotation within the 2-D northeast plane.

Appendix B

Application of k-Means Algorithm

[53] To select stations which have similar ionospheric delay patterns, we utilize k-means clustering, which is one of the most widely used clustering formations. Given a set of n data points (X1, X2, …, Xn) in real L-dimensional space, RL, k-means clustering aims to partition the n observations into k preselected sets (S = {s1, s2, …, sk}), so as to minimize the mean squared distance (Euclidean norm) from each data point to its nearest center within each cluster [Kannungo et al., 2002]. One of the most popular methods for solving the k-means clustering problem, the k-means algorithm, finds a local minimum solution using a simple iterative scheme [Faber, 1994; Kannungo et al., 2002]. An objective function, E, to be minimized is given by

display math(B1)

where Xj is the data point in the set Si and zi is the reference point of the set Si. The k-means algorithm is the approach applied in this study.

[54] In pattern recognition, the components of a “feature vector” represent the numerical features of any object. In applying the k-means algorithm, n observations, X1, X2, …, Xn, used as inputs to the problem of k-means clustering can be considered as feature vectors. To classify arbitrary ionospheric delay curves into groups according to the type of ionospheric delay pattern, the selection of a feature vector that accurately reflects the important characteristics of ionospheric delays is required. The better determined the feature vector, the better the performance of pattern recognition that we can obtain. This study uses the coefficients obtained from a polynomial curve fitted to a time series of ionospheric delays as the components of the feature vector. The optimal order of polynomial curve was determined in off-line analysis so as to minimize the root-mean-square of residual errors (actual ionospheric delay data minus the delay predicted by the polynomial fit). The resulting order is 30 (beyond which the improvement was minimal), and thus, the dimension L of the feature vector X is 31.

[55] In addition to the feature vector, a k of three, which is the other input of the k-means algorithm, is chosen to partition stations into three clusters. The automated ionosphere front velocity estimation algorithm takes a pair of stations between which a large ionospheric gradient is observed as an input. As addressed above, the polynomial fit is performed to the time series of ionospheric delays of each station selected in the step of Clustering Nearby Stations (see section 4.1) as well as the two input stations. The L coefficients of each polynomial fit are utilized as the components of each feature vector, X. The k-means algorithm initially choose three reference points randomly within the observation domain, X1, X2, …, Xn. It then creates three clusters by associating every observation with the closest reference point. Next the centroids of the clusters become the new reference points and these are used in subsequent partitioning. The procedure is repeated until E in equation ((B1)) is minimized, and thus, observations assigned to each cluster no longer change.

[56] After convergence has been reached, every observation is assigned to one of the three clusters. Thus, one among the three clusters consists of stations whose ionospheric delay pattern is similar to that of the first input station. Another cluster should contain stations whose delay pattern is akin to the second input station. The remaining stations which have different patterns from those of the station pair are separated into the third cluster. Because the separation distance of the station pair is short (in most cases only a few tens of kilometers), the delay patterns of the first two clusters should be similar while the stations track the same satellite during a short time interval. Thus, the union of the first two clusters, including the input pair, is used in the following steps of front velocity estimation. Given the input station pair GARF and ZOB1, as shown in the case study (see section 5.1), the union of the first two clusters includes 16 stations which exhibit similar ionospheric delay patterns to those of the two input stations. The delays of the selected stations are plotted over time on the left-hand side of Figure 8 and the locations of those stations are shown in Figure 9.


[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).