Faster Time-To-First-Fix using SBAS

Jaron Samson, Alberto Garcia, Massimo Crisci, European Space Agency (ESTEC) Email: jaron.samson@esa.int

BIOGRAPHIES Jaron Samson is a Radio Navigation System Engineer at ESA/ESTEC since 2003. Previously, Jaron has worked at the National Aerospace Laboratory NLR and at Topcon Europe. Jaron holds an M.Sc. Degree in Geodesy from Delft University, the Netherlands. Alberto Garcia works in the radio navigation section at ESA/ESTEC since 2000. He is involved in activities related to GNSS space receivers and applications. He worked previously at GMV (Spain) for several satellite navigation projects. He obtained an M.Sc. in Telecommunications Engineering from the Polytechnic University of Madrid in 1992. Massimo Crisci is the Head of Radio Navigation Systems and Techniques Section at the ESA He is the head of a team of Engineers providing RadioNav expert support to the various ESA programs (EGNOS and Galileo included). He holds a PhD in Automatics and Operations Research from the University of Bologna and a Master Degree in Electronics Engineering from University of Ferrara. ABSTRACT Time To First Fix (TTFF) is an important parameter in Satellite Navigation. Signal acquisition and especially “the time needed to read the essential parts of the navigation message” have the most significant impact on TTFF. Although Satellite Based Augmentation Systems (SBAS) are designed for Safety-of-Life operations, they have certain features which are of interest in the context of TTFF. As the Doppler shift of an SBAS-satellite (in GEO-orbit) is negligible, the search-space is significantly smaller than the search-space of a GNSS-satellite (in MEO-orbit), allowing a faster signal acquisition. Another benefit is that the acquisition of an SBAS-satellite allows to determine the User Frequency Offset in one single step, whereas during the acquisition of multiple GNSS-satellites an iterative process is required for determining the User Frequency Offset. Three concepts for improving TTFF using SBAS have been defined. In this paper, concepts for improving the TTFF of a single-frequency Galileo-user are described

(similar concepts could be developed for improving the TTFF of users of other GNSS-systems, or for multiple-frequency Galileo users). The first concept is the transmission of either the reduced almanacs of 6 Galileo-satellites or the almanacs of 4 Galileo-satellites (having the highest elevation in the center of the SBAS coverage-area). This concept would allow a faster TTFF in Cold Start conditions. The second concept is the transmission of Galileo System Time (GST) using SBAS. This concept would improve the TTFF of a user in a specific Warm Start condition (i.e. having valid ephemerides, but not having a valid GST), as the user would not need to wait for the reception of GST in the Galileo I/NAV-message. The third concept is the transmission of GST and the ephemerides of four or more Galileo-satellites (having the highest elevation in the center of the SBAS coverage-area). This concept is seen as the most interesting one, as it would improve the TTFF in Warm Start conditions (starting up a receiver in Warm Start conditions happens more frequently than starting up a receiver in Cold Start conditions). In order to use these three concepts, three SBAS-scenarios are defined. In the first SBAS-scenario, no changes to the SBAS-system are performed. In this scenario, none of the concepts can be applied. Nevertheless, the acquisition of an SBAS-signal is beneficial to determine the User Frequently Offset in one step (which is beneficial for reducing the search-space for the acquisition of GNSS-satellites). In the second SBAS-scenario, the SBAS-system is modified, maximizing available bandwidth without violating the SBAS-standard (please note that it is expected that this scenario may not be acceptable for SBAS-systems which are already operational). The bandwidth available in this scenario would allow the transmission of the reduced almanacs of 6 satellites, or the transmission of GST. In the third SBAS-scenario, the draft standard of SBAS L1/L5 is considered. In this draft standard, optional Quadra-phase channels are described for L1 and L5. Under a number of assumptions, the bandwidth available on L1-Q will allow all SBAS-scenarios (the ephemerides for up to 7 Galileo satellites could be transmitted). As a result, in Warm Start Conditions, TTFF can be improved by up to 13 seconds when transmitting the ephemerides of 4 satellites, and by up to 10 seconds when transmitting the ephemerides of 7 satellites.

NOTE This paper reflects the personal opinion of the authors on a potential future service for SBAS. This paper should not be seen as a commitment from ESA for the implementation of such a service.

INTRODUCTION

The Time To First Fix (TTFF) of a navigation receiver can be defined as the time required for a receiver to output the first position fix, after the receiver has been turned on. TTFF is an important parameter in Satellite Navigation, especially for Mass Market Users. Depending on the start conditions of the receiver, TTFF is mainly impacted by the time needed to acquire the GNSS-signals, and the time needed to read the essential parts of the navigation message. In case no a-priori information is available in the receiver (i.e. Cold Start), the acquisition time may be significant. However, in case a valid almanac and a rough Position-Velocity-Time (PVT) estimation are available (i.e. Warm Start), the acquisition time is significantly reduced. Both in Cold Start as in Warm Start conditions, the time needed to read the essential parts of the navigation message is either the major contributor or a significant contributor to TTFF. Therefore, a key factor for a good TTFF performance turns out to be the design of the navigation message structure itself [Ref 1].

TTFF can be improved by applying assistance-data received via Terrestrial Networks (e.g. GSM, UMTS). This concept is known as AGNSS [Ref 2]. AGNSS is improving TTFF in two ways. Firstly, the assistance-data may be used by the user for a faster acquisition of the GNSS-signals. Secondly, the assistance-data removes the need to wait for the reception and decoding of the full navigation message, as transmitted by GNSS. Although AGNSS is a powerful and popular technique, some drawbacks can be identified. Obviously, if Terrestrial Networks are unavailable, no assistance can be provided. Unavailability of Terrestrial Networks may occur when a user is outside the coverage area of a Terrestrial Network, or during emergency situations. Therefore it is of interest to investigate concepts which may improve TTFF, without relying on Terrestrial Networks.

In this paper, we will discuss the potential use of SBAS for improving TTFF of GNSS. We will provide concepts for the use of SBAS for improving the TTFF of a single-frequency Galileo-user. Similar concepts could be developed for improving TTFF of users of other GNSS-systems, or for improving TTFF of multiple-frequency Galileo-users.

SATELLITE BASED AUGMENTATION SYSTEMS (SBAS) The main purpose of the Satellite Based Augmentation Systems (SBAS) is to allow Safety-of-Life operations using GPS, and possibly other GNSS-systems in the future. A number of SBAS-systems are operational or under development: EGNOS in Europe, WAAS in the US, MSAS in Japan, SDCM in Russia, and GAGAN in India. For the transmission of messages, an SBAS-system uses a number of geo-stationary satellites (e.g. three in the case of EGNOS). In the SBAS-standard, several Message Types are defined. An SBAS-user which receives and processes these Messages (as specified in [Ref 3]) will improve the precision of its position solution and obtain information on the integrity of the position solution. In spite of the fact that SBAS are designed for aviation, SBAS has been used for a number of other applications, e.g. Agriculture, Road Tolling. More information on SBAS and EGNOS in particular, can be found in e.g. [Ref 9]. When comparing SBAS with GPS or Galileo, there are a number of features which are of interest in the context of TTFF:

Doppler-shift A smaller uncertainty of the Doppler-shift will translate into faster acquisition of the signal. GPS and Galileo satellites are in MEO-orbit, having a speed over 3 km/s, and having a Maximum Range Rate of approximately 800 m/s [Ref 2]. As a result, a user located on the earth surface would receive the GPS or Galileo signal with a Doppler shift in the range of ±4.2 kHz. On the other hand, SBAS uses satellites in GEO-orbit; the speed of the satellite with respect to a user on ground is very small. The SBAS standard has specified a maximum Doppler shift of 210 Hz only [Ref 3].

Data-rate A higher data-rate will reduce the time needed to receive the data which is required by the user for calculating the first position fix. The data-rate for GPS is 50 bits per second [Ref 14], whereas the data-rate for SBAS is 250 bits per second (Each SBAS data block consists of 250 bits, including a 212 bit data-field [Ref 3]).

Frequency-band TTFF is a parameter which is especially important for Mass Market users. Today, Mass Market receivers are single frequency receivers, usually L1/E1-only. The Galileo Commercial Service will offer a data-rate superior to SBAS (i.e. 500 bits per second [Ref 13]). However, the Commercial Service is broadcast in E6, whereas the SBAS-signal is transmitted in L1. At the moment and in the near-future, Mass Market receivers can be expected to be capable of receiving L1/E1 only or L5/E5a only, not the E6-signal of Galileo’s Commercial Service.

However, when comparing SBAS with GPS or Galileo, there is also a feature which is a disadvantage:

Visibility As geostationary satellites are located above the equator, at northern latitudes they are visible at low elevations. At Polar Regions, geostationary satellites are not visible at all. As a result, reception of SBAS-signals is an issue for ground-based application, especially in urban canyons. At the end of this paper, this issue will be discussed in more detail.

TIME TO FIRST FIX The Time To First Fix (TTFF) of a navigation receiver can be defined as the time required for a receiver to output the first position fix, after the receiver has been turned on. TTFF can be described as follows [Ref 1]:

PVTGSTCEDtracqw TTTTTTTFF (1)

, where:

wT denotes the receiver warm-up time,

acqT denotes the acquisition time,

trT denotes the settling time for tracking,

GSTCEDT denotes the navigation data read time,

PVTT denotes the time to compute the navigation

solution.

wT and are negligible in the overall TTFF-budget.

In addition, the contribution of is relatively small

(4.8 seconds

PVTT

acqT

trT[Ref 1]). In this paper we will mainly

consider and . The total TTFF depends

strongly on the information already available in the receiver. In this paper we will use the definitions provided in

GSTCEDT

Table 1 (in line with [Ref 2], please note that alternative definitions may be found in other publications):

Information available in receiver Cold Start

No Almanac No Ephemeris No a-priori PVT No information on user frequency offset

Warm Start

Almanac No Ephemeris A-priori PVT (with limited accuracy) Approximate information on user frequency

offset Hot Start

Almanac Ephemeris A-priori PVT Information on reference frequency offset

Table 1: Receiver starting conditions

SIGNAL ACQUISITION After sampling and filtering, the stage where a global search is performed to determine code delay and Doppler shift ),( f is called signal acquisition [Ref 14]:

L

l

ftjllll

letxtxL

fR1

2~

)ˆ()(1

),( (2)

, where:

),(~

fR l denotes the “Ambiguity Function” (a close

relative of the correlation function), f denotes the Doppler shift (in Hz),

L denotes the number of samples,

l̂ denotes the time shift for the replica code.

The size of the search-space , in which i

to be evacuated, can be defined as follows:

S ),(~

fR l s

250chipschips

bin

Nrf

cs

Nr

f

fS

(3)

, where:

binf denotes the resolution for the search in the

frequency-domain (typically 500 Hz),

chipsNr denotes the number of chips in the GNSS signal,

cs denotes the correlator spacing (typically 0.5 chip).

The Mean Acquisition Time depends not only on the size of the search-space, but also on receiver dependent parameters (e.g. the number of correlators, the dwell time, the probability of detection, etc.). In this paper, for a comparison of the acquisition of the SBAS-signal to the acquisition of the GPS-signal or Galileo-signal, we will only consider the size of the search-space. The budget for the frequency uncertainty has been provided in Table 2 (based on [Ref 2] and [Ref 3]). The following conclusions can be drawn: The impact of the satellite motion is negligible for

SBAS The impact of the user motion is negligible for

terrestrial applications Assuming a user position error of 1000 kilometre, the

total frequency uncertainty is around 50% to 75% smaller when acquiring the SBAS-signal instead of the GPS-signal

Assuming a user position error of 1000 kilometre, in case the User Frequency Offset has been estimated, the frequency uncertainty is around 90% smaller when acquiring the SBAS-signal instead of the GPS-signal. Techniques for estimating the User Frequency Offset will be discussed in the next section.

GPS SBAS Satellite motion

8.4 kHz < 210 Hz

User motion 0.15 kHz (per 100 km/hr)

0.15 kHz (per 100 km/hr)

User position error

1 kHz (per 1000 km)

~0 kHz

User Frequency Offset

3-7.5 kHz (1.5 kHz per ppm)

3-7.5 kHz (1.5 kHz per ppm)

Total 12.4 - 16.9 kHz (1000 km user position error)

3 – 7.5 kHz

Total after estimation of the User Frequency Offset

9.4 kHz (1000 km user position error)

<< 1 kHz

Table 2: Frequency uncertainty Using Table 2, we now can provide a few examples to demonstrate the relatively small size of the search-space

when acquiring the SBAS-signal: S For Galileo E5a (for both I and Q component),

the primary code length is 10230 [Ref 8]. Thus, when the User Frequency Offset is unknown, S=507408-691548. When the User Frequency Offset is estimated, S=384648.

For GPS L1 CA, the code length is 1023 [Ref 6]. Thus, when the User Frequency Offset is unknown, S=50741-69155. When the User Frequency Offset is estimated, S=38465.

For SBAS, the signal structure is identical to GPS L1 CA [Ref 3]. Thus, when the User Frequency Offset is unknown, S=12276-30690. When the User Frequency Offset is estimated, S<<4092.

USER FREQUENCY OFFSET DETERMINATION USING SBAS Table 2 shows that the User Frequency Offset has an important contribution to the size of the search-space. Fortunately, it has an equal impact for all satellites: once it is determined, we can reduce the size of the search-space for all satellites to be acquired. The question is how this User Frequency Offset can be taken into account. In case GPS- or Galileo-signals are to be acquired, a scheme for taking into account the User Frequency Offset is provided in [Ref 2]. When acquiring a first satellite, the frequency offset is due to both the satellite motion of this first satellite, and the User Frequency Offset (see Figure 1). For this reason, an iterative scheme is needed: by acquiring more satellites with varying Doppler values, the search-space is reduced step-by-step.

Figure 1: [Ref 2]: Signal acquisition for GPS L1C/A, assuming a frequency search-space of ±9 kHz. Left image: signal acquisition of one satellite (small cross), allowing a small reduction of the search-space only. Right image: after the acquisition of multiple satellites, the search-space is further reduced. On the other hand, in case SBAS-signals are to be acquired, the User Frequency Offset can be determined in one single step, as all other contributors (satellite motion, User position error, etc.) are negligible. The total frequency offset (which is determined via acquisition) can be assumed to be equal to the User Frequency Offset, and the search-space for GPS or Galileo satellites can be reduced immediately.

NAVIGATION DATA READING In this section we will discuss the situation where the receiver has already acquired the signals and has started tracking these signals. In order to perform the computation of the position of the user, the following information is required:

Satellite Ephemerides GNSS System Time

The satellite ephemerides are required for the calculation of the position and velocity of the GNSS-satellites. The GNSS System Time is required for two purposes: to calculate the position of the GNSS-satellites, and to solve the pseudo-range ambiguity. However, one may argue that GNSS System Time is not strictly required, as this information may also be determined by the user, using a concept called “coarse navigation” [Ref 2]. In this concept, GNSS System Time is estimated in the positioning filter as an additional unknown. Nevertheless, as this concept requires an additional satellite and increases the complexity of the user algorithm, we will assume that GNSS System Time is a parameter which has to be transmitted to the user. In Figure 2, the Galileo I/NAV message is depicted. The I/NAV message transmission takes 30 seconds (repeated continuously). Regarding the essential information for the user position computation, we can observe that the Ephemeris is transmitted once (spread over 4 words; 2, 4, 1, and 3) whereas the Galileo System Time (GST) is transmitted four times (Word 6, 5, and two Spare Words). For the page to be valid, the whole block must be received

and decoded. If a receiver starts reading the message one bit after the beginning of the current page, the message is considered invalid, and one has to wait until the page has been completed before retrieving the next page of useful information [Ref 1]. From Figure 2 we can reach the following conclusions regarding the Navigation read time of the I/NAV

message : GSTCEDT

Min( GSTCEDT ) = 14 seconds.

This situation occurs if the reading of the navigation message would start at t=21 sec. exactly, ending exactly 14 seconds later (i.e. at t=5 sec. mod 30 sec.)

Max( GSTCEDT ) = 32 seconds.

One example of this situation is the following. The reading of the navigation message would start slightly after t=21 sec., ending exactly 32 seconds later (i.e. at t=23 sec. mod 30 sec.)

In [Ref 1], the 95% percent confidence level of for the Galileo I/NAV message was derived:

GSTCEDT

NAVIGSTCEDT /%,95, =31.63 seconds

Figure 2: Galileo I/NAV message content

EPHEMERIS AND ALMANAC: NUMBER OF BITS VERSUS ACCURACY A GNSS-user may use orbital information of the GNSS-satellites for two reasons: 1) Computation of the Doppler-shift (Reduction of the search-space, for signal acquisition) 2) Computation of the location of the satellites at the time of signal transmission (for PVT computation) For the computation of the Doppler-shift, the orbital information does not need to be very accurate, and the number of bits used may be limited. However, for the Computation of the location of the satellites, accurate orbital information is required. The number of bits and update rate of ephemerides and almanacs are summarised in Table 3. Information Nr. of bits

(per satellite)

Update rate

Galileo ephemeris I/NAV 356 30 sec. Galileo almanac I/NAV 133 +161 12 min. GPS ephemeris (L1 C/A) 366 30 sec. GPS almanac (L1 C/A) 174 12.5 min. GPS ephemeris (L1C) 421 18 sec. GPS midi almanac (L1C) 127 Variable2 GPS reduced almanac (L1C) 33 Variable Table 3: Information versus number of bits and update rate ([Ref 8], [Ref 7]). According to [Ref 2], the accuracy of the Doppler shift when using ephemerides is a few milliHerz, which is essentially perfect. When using almanacs, a worst case error of 163.4 Hz was derived. Application of reduced almanac instead of an almanac will lead to a reduced accuracy, due to the limited number of bits. Nevertheless, the application of reduced almanacs still provides a benefit compared to a Cold Start condition (i.e. not having any almanacs).

CONCEPTS FOR IMPROVING TTFF In this section we will discuss concepts, which can be applied for improving the TTFF by using SBAS. We will use the following information:

For a First Fix, only 4 satellites are required

1 Additional parameters: IODa (4 bits), t0a (10 bits), WNa

(2 bits) 2 For the reduced and midi almanac, [Ref 7] states: “Broadcast sequence of subframe 3 pages is a variable and, as such, users must not expect a fixed pattern of page sequence.”

In most cases, the satellites with the highest elevation are the most likely ones to be in view of a user

Concept 1: Transmitting (reduced) almanacs In this concept, either almanacs or reduced almanacs of GNSS-satellites are transmitted by SBAS, to assist a GNSS-user in Cold Start mode. As an example, we will consider an SBAS-system aiding a Galileo-user. Although the concept of reduced almanacs has been introduced for GPS L1C only, reduced almanacs may also be applied by SBAS for aiding the acquisition of Galileo-signals. In case we want to transmit reduced almanacs, we can fit the reduced almanacs of 6 Galileo-satellites into 1 SBAS-message (which has a capacity of 212 data-bits), leaving 14 spare-bits in the message. In case we want to transmit Galileo almanacs, we can fit only 1 almanac into 1 SBAS-message, leaving 63 spare-bits in the message. Alternatively, we could fit 3 almanacs into 2 SBAS-messages, by splitting one almanac over two SBAS-messages, and reducing the number of bits per almanac from 149 to 141 (this reduction will have a limited impact on the Doppler uncertainty). The next question to be answered is the following: How often should the almanacs or reduced almanacs be transmitted? First of all, almanacs or reduced almanacs are of interest only to a user that wants to perform signal acquisition in Cold Start Mode. First let’s consider a user performing a Cold Start without using any aiding:

At t0, the Cold Start is initiated. At t0+ dtGNSS, 4 sats, GNSS-signals of at least 4

satellites have been acquired, without aiding by the almanacs or reduced almanacs.

Next, let’s consider a user performing a Cold Start, allocating a few channels to the acquisition of the SBAS-signals, and the remaining channels to the acquisition of GNSS-signals:

At t0, the Cold Start is initiated. At t0+dtSBAS, at least one SBAS-signal is acquired3 At t0+dtSBAS+dtMessage Rate, almanacs or reduced

almanacs are received via SBAS At t0+dtSBAS+dtMessage Rate +dtGNSS aided acq, 4 sats,

GNSS-signals of at least 4 satellites have been acquired, aided by the almanacs or reduced almanacs received via SBAS.

The message rate of the almanacs or reduced almanacs should be selected in such way that the following condition is fulfilled (with a specific probability):

t0+dtSBAS+dtMessage Rate +dtGNSS aided acq, 4 sats << t0+ dtGNSS, 4 sats

(4)

By assuming that dtSBAS and dtGNSS aided acq, 4 sats

3 As the search-space for SBAS is smaller, it is likely that at least one of the SBAS-signals is acquired before the acquisition of 4 GNSS-signals.

are small compared to dtGNSS, 4 sats (which is a reasonable assumption, taking into account the size of the search-spaces), we have to show that the following condition is fulfilled (with a specific probability):

dtMessage << dtGNSS, 4 sats

(5)

Unfortunately there’s no unique value for dtGNSS, 4 sats, as it depends strongly on receiver specific parameters (e.g. number of correlators). In [Ref 2], it is written that the acquisition of a GNSS-signal in Cold Start mode requires at least 20 seconds. This would mean that the update rate of the reduced almanac or almanac should be better than 20 seconds. However, taking into account that future receivers will have an increased number of correlators, and taking into account that dtSBAS and dtGNSS aided acq, 4 sats are small but not negligible, it is advisable to introduce some margin, having an update rate of e.g. 10 seconds. The following concepts can be defined:

Concept 1a: Transmitting only reduced almanacs of 6 satellites (with the highest elevation in the centre of the SBAS-coverage area). Every 10 seconds, 1 SBAS-message is required (i.e. 10% of the bandwidth of SBAS)

Concept 1b: Transmitting only almanacs of 4 satellites (with the highest elevation in the centre of the SBAS-coverage area). Every 10 seconds, 3 SBAS-messages are required (i.e. 30% of the bandwidth of SBAS)

Concept 2: Transmitting GST only Receiving Galileo System Time (GST) is beneficial for the following reasons: Computation of the satellite positions When already having valid satellite ephemerides, GST is needed to compute the satellite positions at a specific epoch. If the accuracy of GST is 10 ms or better, the effect on the satellite position is around 8 m or less, which is often considered as an acceptable accuracy for a First Fix [Ref 2]. Solving pseudo-range ambiguities In the absence of GST, the receiver only provides fractional pseudo-ranges. GST is required to solve the pseudo-range ambiguities. The accuracy of GST has to be significantly better than the Code length, e.g. better than 4 ms for Galileo E1-C (i.e. primary code length). In Table 1, a Warm Start is defined as a situation in which a user would need to decode both GST and the ephemeris. However, there are specific conditions in which a user is interested in decoding GST only:

The validity time of an ephemeris is 3 hours. In case a user turns on a receiver in less than 3 hours from the moment the last ephemeris was decoded, only GST needs to be retrieved.

A user which is assisted by AGNSS receives the ephemeris over the network. However, due to the

poor synchronisation of most telecom networks, GST needs to be obtained via other means.

The question is whether a user could benefit from getting GST via SBAS. As written above, a user would like to synchronise to GST with an accuracy better than 4 ms. Synchronisation errors are due to the following reasons:

1. Synchronisation of SBAS System Time to GNSS System Time The following requirement is provided in [Ref 3]: “WAAS Network Time will be within 50 nanoseconds of GPS System Time”. In addition, the residual offset between Galileo System Time and GPS System Time will be probably in the order of tens of nanoseconds [Ref 11]. In summary, taking into account the requirement for a synchronisation of better than millisecond-level, the impact of the synchronisation of SBAS System Time to GST is negligible.

2. Offset satellite clock with respect to GST For GPS, the SV clocks are aligned to within 1 millisecond of true GPS time [Ref 12]. For Galileo, the alignment of the satellite clocks may be even less strict. We can conclude that the offset of the satellite clock with respect to GST is an issue, especially for Galileo. As a result, in order to correct for this offset, we have to assume that the user already has valid satellite clock corrections. However, for Galileo I/NAV, this assumption is automatically fulfilled by the assumption that the user has satellite ephemerides: the clock corrections and the fourth part of an ephemeris (4/4) are included in the same Word (Word Type 4) [Ref 8].

3. Downlink delay GST refers to the time of transmission by the Galileo-satellite. A user on the earth surface will receive this information with a certain delay, depending on the distance from user to satellite. The nominal altitude of a Galileo-satellite is 23222 km [Ref 12], whereas the nominal altitude of an SBAS satellite is 35786 km. If a message is transmitted by both the Galileo-satellite and the SBAS-satellite, exactly at t= t0 seconds, the Galileo-message would be received by a user at approximately t= t0+0.08 sec., whereas the SBAS-message would be received at approximately t= t0+0.12 sec. The difference of this downlink delay between Galileo-satellites and SBAS-satellites is significant. In addition, this difference is not constant, as the distance from user to Galileo-satellites varies. However, this difference can be determined in the receiver, as it is the difference in time between the reception of:

The start of the first 8-bit part of the SBAS-message, which has a 1-second duration

The start of the synchronisation pattern of Galileo’s I/NAV message.

As we have shown that synchronisation is not a major issue, we can now assess the benefits of transmitting GST via SBAS. Let’s first review the situation of a user receiving only the I/NAV message. When considering Figure 2, if a user is only in need of GST, we can observe that:

Max( GSTT ) = 23 seconds

This situation occurs if the user starts reading the message slightly after t=5 seconds, obtaining GST at t=27. Now assume that GST is also received via SBAS at t=15 seconds (see Figure 3). In this case:

Max( GSTT ) = 11 seconds

This situation occurs if the user starts reading the message slightly after t=5 seconds, obtaining GST at t=16. In summary, by using a small number of bits only (GST takes 32 bits only, to be transmitted once every 30 seconds, which is equal to approximately 0.5% of the SBAS bandwidth), we obtain a major reduction of the TTFF of a user which is only in need for GST. Obviously, further reductions of TTFF could be obtained by transmitting GST more often.

Figure 3: Galileo I/NAV message content, and a potential SBAS transmission of new Message Type Z. The grey area indicates other SBAS-messages.

Concept 3: Transmitting ephemerides and GST Previously we have seen that a Galileo-user in Warm Start mode needs to wait for the reception of ephemerides and GST, which may take up to 32 seconds. In case this user is also tracking the SBAS-signal, a properly scheduled transmission of ephemerides and GST by SBAS would reduce the time needs to wait for the reception of ephemerides and GST. When considering the transmission of ephemerides via SBAS, the following has to be taken into account:

In the Galileo I/NAV message, an ephemeris is split over 4 words. Each word contains 112 data-bits, and the duration is 2 seconds. [Ref 8].

The Galileo I/NAV ephemeris contains 356 bits (110 bits in Word nr 1, 110 bits in Word nr 2, 104 bits in Word nr 3, and 32 bits in Word Type 4) . [Ref 8].

In the Galileo I/NAV message, the navigation data is disseminated in data batches each one identified by an Issue of Data (IOD). For the ephemeris, IODnav uses 10 bits [Ref 8].

In the Galileo I/NAV message, GST requires 32 bits (12 bits for WN, 20 bits for TOW).

An SBAS-message type consists of 212 data-bits, the duration is 1 second [Ref 3]

In case SBAS would transmit the ephemeris of a GNSS-satellite, it would need to provide information on the PRN-number to which the ephemeris corresponds. In the Galileo I/NAV message, SVID consumes 6 bits [Ref 8].

Taking into account the information above, we can now define two new Message Types for SBAS, containing the ephemeris of one GNSS-satellite. Both Message Types need to include IODnav and SVID, so 196 data bits (i.e. 212-10-6) are still available for the ephemeris. In the first new Message Type, we will combine Word nr 1 and Word nr 3. We will use only the 196 bits available, instead of the 214 bits used for Word nr 1 and Word nr 3 in the I/NAV message. The impact of using 196 instead of 214 bits will be discussed later. In the second new Message Type, we will combine the ephemeris parameters contained in Word nr 2 and Word nr 4. In the I/NAV message, the ephemeris parameters contained in Word nr 2 and Word nr 4 use 142 bits, so we will also use 142 bits in this new SBAS-message. As a result, 54 bits (i.e. 212-142) are still available. We will use 32 bits for transmitting GST, leaving 22 bits spare bits available. Ideally, the schedule of transmission of these 2 new

Message Types should be such that is

minimised. First we will discuss the situation when the transmission of the ephemeris of one GNSS-satellite only is performed. Previously we have discussed the navigation read time of the I/NAV message, concluding

that Min( ) = 14 seconds, Max( ) = 32

seconds. Now let’s assume that a user is also decoding the

SBAS-messages, and the new Message Types are transmitted at t=8 seconds and t=17 seconds, every 30 seconds (see

GSTCEDT

CEDT GSTCEDT GST

Figure 4). In this case:

Min( GSTCEDT ) = 8 seconds.

This situation occurs if the reading of the navigation message would start at t=1 sec. exactly, ending exactly 8 seconds later (i.e. at t=9 sec. mod 30 sec.)

Max( GSTCEDT ) = 18 seconds.

One example of this situation is the following. The reading of the navigation message would start slightly after t=17 sec., ending exactly 18 seconds later (i.e. at t=5 sec. mod 30 sec.)

In summary, both Min( ) and Max( )

are improved significantly by the new SBAS-messages. GSTCEDT GSTCEDT

Figure 4: Galileo I/NAV message content, and a potential SBAS transmission of new Message Types X and Y for one Galileo-satellite. The grey area indicates other SBAS-messages. However, there are still three issues that need to be discussed. First of all, we have mentioned that for the first new SBAS-message Type (containing Word Nr 1 and 3), unfortunately we could use only 196 bits instead of 214 bits. There are a few possibilities for reducing the number of bits:

Use of reference values In the SIS ICD of GPS L1C [Ref 7], reference-values are defined for two ephemeris parameters

(i.e. , A ). By transmitting only the difference with respect to these reference-values, the number of bits is being reduced. This concept is not applied in Galileo’s SIS ICD [Ref 8], but it may be applied in the SBAS-message to save bits.

Reduced flexibility new orbits In Galileo’s SIS ICD [Ref 8], the number of bits and Scale Factor are defined per ephemeris parameter, which impacts accuracy and range per parameter. If the number of bits of a parameter is reduced, we may choose to maintain the accuracy, while reducing the range. However, there is a price to pay when reducing the range: the flexibility to provide the ephemerides of future satellites in new types of orbits is reduced. For GPS and Galileo, this flexibility is important. For a TTFF-service, this flexibility may be less important, as we need only 4 satellites for a First Fix: if, in the future, a few GNSS-satellites are launched in other types of orbits, we may decide that a TTFF-service does not transmit ephemerides for those satellites.

Temporary degraded accuracy If the number of bits of a parameter is reduced, we may choose to maintain the range, while reducing accuracy of the ephemeris parameters. A reduced accuracy of ephemeris parameters would result in a reduced accuracy of the position solution. It should be shown that the worst case reduction of the accuracy of the position solution, for a user at any moment or location, is acceptable. Nevertheless, this accuracy degradation would be temporary. For example, considering Figure 4, assume a user starts decoding both the Galileo I/NAV message as the SBAS-messages at exactly t=8 seconds. At t=18 seconds, this user could use this information for a position calculation, albeit with degraded accuracy due to the limited number of bits in the first new SBAS Message Type (containing Word Nr 1 and 3). However, already at t=25 seconds, the user would also received Word Nr 1 and 3 via the Galileo I/NAV message. At this moment, the user could ignore Word Nr 1 and 3 as received from SBAS, obtaining nominal positioning accuracy.

In summary, although additional analysis is required, it is expected that the reduction of the number of bits in the first SBAS Message Type (containing Word Nr 1 and 3) can be accommodated. The second issue that needs to be discussed is the number of GNSS-satellites for which ephemerides need to be

provided, and the impact on . If more SBAS-

messages are to be transmitted by the same GEO-satellite, the scheduling of the message transmission would

become suboptimal, and T would increase. In

GSTCEDT

GSTCED

Figure 4, an example for an SBAS-transmission containing messages for 1 GNSS-satellite only was shown: 2 SBAS-messages are transmitted once every 30 seconds. In Figure 5, an example for an SBAS-transmission containing messages for 4 GNSS-satellites is shown. When comparing Figure 4 and Figure 5,

Max( ) (the time needed to read GST and the

ephemerides of all 4 satellites) increases from 18 to 19 seconds. One example of this situation is the following. The reading of the navigation message would start slightly after t=16 seconds, ending 19 seconds later (i.e. at t=5 sec. mod 30 sec.) Beyond 4 satellites, the transmission of the ephemeris of every additional satellite would

increase Max ( ) by 1 second.

GSTCEDT

T GSTCED

Figure 5: Galileo I/NAV message content, and a potential SBAS transmission of new Message Types X and Y, for four Galileo-satellites. The third issue that needs to be discussed are the Satellite Clock Correction Parameters. In the Galileo I/NAV message, the Satellite Clock Correction Parameters are contained in the same Word as Ephemeris (4/4) (i.e. Word Type 4), However, in our design of the second SBAS-message (which includes Ephemeris (2/4), Ephemeris (4/4), and GST), only 22 spare bits were left. Unfortunately the Satellite Clock Correction Parameters cannot be included in this second SBAS-message, as they consume 72 bits [Ref 8]. There are two approaches for this issue. We could define another SBAS-message, containing Satellite Clock Correction Parameters. However, this approach would require additional bandwidth. Alternatively, we could assume that old Clock Correction Parameters for a specific satellite are already available in the receiver. According to [Ref 15], the frequency stability of Giove’s satellite clocks is below 1E-15 per day for the PHM, and below the 1E-13 per day level for the RAFS. If we assume that Galileo’s satellite clocks will have similar performance, the application of Galileo’s Satellite Clock Correction Parameters will lead to sub-millisecond errors for a very long time. In other words, if we may assume that Galileo’s Satellite Clock Correction Parameters for a specific satellite are available

in the receiver, even if this information is very old, we do not need to transmit this information via SBAS. Until now we have only considered a transmission of an ephemeris per GNSS-satellite with a rate of once per 30

seconds. A further improvement of may be

obtained by increasing this rate. The draw-back of this approach is the increased bandwidth required, and increased suboptimal scheduling of messages. Another approach would be to use satellite diversity between geostationary satellites: the ephemeris of a specific Galileo-satellite may be transmitted by SBAS-satellites at different moments. The draw-back of this approach is the fact that benefits are only obtained if a user has multiple SBA-satellites in view. These approaches would require further investigation.

GSTCEDT

The following choices could be made:

Concept 3a: Transmitting ephemerides of 4 satellites (with the highest elevation in the centre of the SBAS-coverage area). This would require 27% of the SBAS bandwidth (4 satellites* 2 messages, transmitted every 30 seconds). In Warm Start conditions, TTFF would be

improved by up to 13 seconds (Max( GSTCEDT )

is reduced from 32 seconds to 19 seconds). Concept 3b: Transmitting ephemerides of 7

satellites (with the highest elevation in the centre of the SBAS-coverage area). This would require 47% of the SBAS bandwidth (7 satellites* 2 messages, transmitted every 30 seconds). It will be shown later that the ephemerides of 7 satellites are the maximum which can be transmitted in the SBAS-evolutions scenario (under a number of assumptions). In Warm Start conditions, TTFF would be improved by up to

10 seconds (Max( GSTCEDT ) is reduced from 32

seconds to 22 seconds).

Although concept 3b requires more bandwidth, it offers robustness for the non-visibility of Galileo-satellites by the user due to the Local Environment (a minimum of 4 satellites are required for a First Fix).

SBAS-SCENARIOS In the previous section, we have described several concepts for improving TTFF. In this section, we will investigate how these concepts can be used by SBAS. We will make the following assumption: Whenever there’s bandwidth available, only 50% of the bandwidth may be used for improving TTFF (the remaining 50% shall be reserved, e.g. for other services). Scenario 1: SBAS, no System modification In this first scenario, we will discuss the potential benefits of SBAS for TTFF, in case that SBAS does not transmit

any Message Type other than the ones defined in the SBAS-standard [Ref 3]. The basic assumption made for this specific scenario is that the acquisition of SBAS is beneficial for the acquisition of other GNSS-signals. In the SBAS-standard, no Message Types are defined for the almanacs or ephemerides of GNSS-satellites. Nevertheless, as discussed previously, a user can benefit from acquiring the SBAS-signal, hereby reducing the search-space of GNSS-satellites to be acquired. Scenario 2: SBAS, System modifications allowed by the standard In this scenario, we will discuss the benefits of SBAS for TTFF, in case that SBAS would transmit new Message Types, which does not violate the SBAS-standard [Ref 3], and the available bandwidth. Please note that this scenario may not be desirable for EGNOS and WAAS for programmatic reasons, as EGNOS and WAAS have already been certified. Previously we discussed four types of parameters to be provided to the user: reduced almanacs, almanacs, GST, and ephemerides. In the SBAS-standard [Ref 3], the Message Types 29 to 61 are “Reserved for future messages”, so we can concluded the number of Message Types available is more than sufficient. The next issue is the bandwidth available in SBAS to transmit these new messages. In the SBAS-standard, a “Maximum Update Interval” is defined per Message Type. By reducing the update rate of messages up to the “Maximum Update Interval”, bandwidth for new Message Types could be obtained. According to [Ref 4]:

“The bandwidth available for additional messages will be of the order of 35% of the total bandwidth, i.e. equivalent to 75 bits per second. Since the transmission of EGNOS messages is made in block messages of 250 bits, this opens up for the transmission of about 1 message, of 250 bits per second, each 3–4 seconds”

“EGNOS Bandwidth may still be higher, if the fact that the GPS Selective Availability (SA) has been removed in May 2000 is taken into account. Indeed, actual DO229C standards do allow the relaxation of the update of the fast clock corrections from the 6 seconds to be used in the case of SA activated (which is the current adopted baseline in EGNOS) to up to 60 seconds when SA is off (which is the current situation). EGNOS bandwidth reaches a value of 63% (equivalent to 140 bits per second). Thus, approximately one extra EGNOS message of 250 bits per second could be sent every 2 seconds for extra services”.

The concepts which are feasible for this specific scenario are listed in Table 4.

Scenario 3: SBAS Evolutions The current SBAS standard considers a transmission in L1 only. An evolution of SBAS is under investigation: a transmission shall be performed in L1 and L5. In the draft standard for SBAS L1/L5 [Ref 5], optional Quadra-phase channels are described for L1 and L5. For the Q-channel of both L1 and L5, it is written: “the data rate is TBD and could be selected within the following values: 0, 50, 100, 125, or 250 bps.” As almost all of today’s Mass Market receivers are single Frequency L1-only receivers, it is interesting to have a TTFF-service on the Q-channel of L1. For multi-frequency receivers, a TTFF-service on the Q-channel of L1 and L5 would be of interest. However, in this paper, we have limited the scope to Mass Market receivers, so we will only consider the Q-channel of L1. We will make the following assumptions:

the highest data-rate described in [Ref 5] (i.e. 250 bps) is available

the message structure on the Q-channel is identical to the existing SBAS-messages (i.e. : 212 bits data-field, 1 message per second)

50% of the bandwidth may be used for improving TTFF

Using the assumptions above, we could use 1 message per 2 seconds to transmit new messages for a TTFF-service. The concepts which are feasible for this specific scenario are listed in Table 4.

TTFF-CONCEPTS VERSUS SBAS-SCENARIOS In a previous section, various concepts for improving TTFF were discussed, and the bandwidth required was derived. In the previous section, the available bandwidth per SBAS-scenario was discussed. In Table 4, using the assumption we may use only 50% of the bandwidth available, we summarise which concepts are feasible per scenario. TTFF-Concept SBAS-Scenario SBAS SBAS

evolutions 1.a Reduced almanac 6 sats

(10 sec. update rate)

1.b Almanac 4 sats (10 sec. update rate)

2 GST (30 sec. update rate)

3.a Ephemerides 4 satellites (30 sec. update rate)

3.b Ephemerides 7 satellites (30 sec. update rate)

Table 4: TTFF-concepts versus SBAS-scenarios

If multiple concepts can be selected for a scenario, it is more interesting to transmit ephemerides and GST than almanacs or reduced almanacs, for the following reasons:

Warm Starts occur more frequent than Cold Starts. Warm Starts are improved by ephemerides and GST, not by almanacs or reduced almanacs (due to the limited accuracy of almanacs or reduced almanacs)

Like almanacs or reduced almanacs, ephemerides can also be used to speed up signal acquisition (by reducing the search-space).

VISIBILITY OF GEOS In this paper we have demonstrated the potential benefits of SBAS for a faster TTFF. However, these benefits are only obtained if the user has been able to acquire the signal of at least one of the SBAS GEOs. The question is: how would a user be penalised if no SBAS-signal can be acquired? Assume we have two GNSS-users not having at least one SBAS GEO in visibility (e.g. they are located in an Urban Canyon), both having a 12-channel receiver. Furthermore, let’s assume that the first user tries to acquire only GNSS-signals (using 12 channels), and the second user tries to acquire GNSS-signals (using 9 channels) and SBAS-signals (using 3 channels). Previously, we have seen that the search-space for acquiring an SBAS-signal is much smaller than the search-space for acquiring a GNSS-signal. After having scanned the full search-space for the SBAS-signals (which should be feasible quickly, depending on the number of correlators), this user may conclude that no SBAS-signals can be acquired, allocating these 3 channels to the acquisition of GNSS-signals. It can be concluded that the penalty for trying to acquire SBAS-signals is limited. Nevertheless, although there is no significant penalty, non-visibility of geostationary satellites is an issue for any SBAS-service, including a TTFF-service. This issue would be mitigated by using satellites located in other types of orbits, e.g. inclined geosynchronous orbits (IGSO). For instance, the orbits of the 3 satellites of Japan’s QZSS-system are selected in such way that one satellite is always seen above 70 degrees elevation from Tokyo [Ref 2]. As a result, there is a high probability to have an IGSO-satellite in view, even in an Urban Canyon. Although a TTFF-service using geostationary satellites is considered of interest, the ultimate space-based TTFF-service would be based on IGSO-satellites.

CONCLUSIONS In this paper, the potential use of SBAS for a “Faster TTFF Service” has been discussed. Three SBAS-scenarios have been considered; using SBAS without any change to the system, using SBAS with changes to the system (i.e. changes which do not violate the SBAS-standard), and using an evolution of SBAS. It has been shown that using SBAS without any change to the system is beneficial for fast acquisition. The acquisition of the SBAS-signal can be accomplished quickly, and the User Frequency Offset can be determined immediately, which is beneficial for acquiring other GNSS-signals. It has been shown that using SBAS with changes to the system can be used for transmitting Reduced Almanacs (which is beneficial for Cold Start conditions), and for transmitting GST (which is beneficial for specific Warm Start conditions). Nevertheless, changes to SBAS-systems which are already certified and operational may not be feasible, even if these changes do not violate the SBAS-standard. Finally, it has been shown that using an evolution of SBAS could allow the transmission of the ephemerides of up to 7 satellites (even when assuming that only 50% of the bandwidth of L1-Q may be used). The TTFF in Warm Start Conditions would improve by up to 13 seconds in case the ephemerides of 4 satellites are transmitted, and up to 10 seconds in case the ephemerides of 7 satellites are transmitted. Due to the limited visibility of geostationary satellites in Urban Canyons, the ultimate space-based TTFF-service would be based on IGSO-satellites.

Future work will analyze the TTFF performance improvement (for the different concepts and SBAS-scenarios described in this paper) in more detail.

REFERENCES [Ref 1] M. Anghileri et al., Ready to Navigate! A methodology for the estimation of the Time-To-First-Fix, Inside GNSS, March/April 2010 [Ref 2] F. v. Diggelen, A-GPS, Assisted GPS, GNSS, and SBAS, Artech House 2009, ISBN-13: 978-1-59693-374-3. [Ref 3] Minimum Operational Performance Standards for Global Positioning System/Wide Area Augmentation System Airborne Equipment, RTCA, DO-229D [Ref 4] A. Mathur et al., Provision of emergency communication messages through SBAS: The ESA ALIVE concept, ION 2005, Long Beach, CA, USA [Ref 5] SIGNAL SPECIFICATION FOR SBAS L1/L5, Eurocae, ED-134, draft v.3, May 2008 [Ref 6] INTERFACE SPECIFICATION, IS-GPS-200, Revision E, 8 June 2010

[Ref 7] INTERFACE SPECIFICATION, IS-GPS-800, Revision A, 8 June 2010 [Ref 8] European GNSS (Galileo) Open Service Signal In Space Interface Control Document (OS SIS ICD) Issue 1, 1 September 2010

[Ref 9] EGNOS, The European Geostationary Navigation Overlay System-A cornerstone of Galileo, ESA, SP-1303, ISBN 92-9092-453-5 [Ref 10] M. Paonni et al., Quasi-pilot signals: Improving sensitivity and TTFF without compromises, ION 2011, Portland, USA. [Ref 11] S. Bedrich et al., Interoperability on Time, GPS World, March 2005 [Ref 12] E. Kaplan, Understanding GPS, 2nd edition, ISBN 978-1-58053-894-7 [Ref 13] J. Avila-Rodriguez et al., the MBOC Modulation: The final touch to the Galileo Frequency and Signal plan, ION GNSS 2007, Fort Worth, Texas, USA, 25-28 September 2007 [Ref 14] P. Misra, P. Enge, Global Positioning System, Signals, Measurements, and Performance, ISBN 0-9709544-1-7 [Ref 15] P. Waller et al., Long-term performance analysis of GIOVE clocks, PTTI 2010