Return to main article

Engineering specialties

Optimal estimation algorithms, e.g., Kalman filters, and signal processing.

GNSS event that most signified to you that GNSS had “arrived”

Return to main article

Engineering specialties

Optimal estimation algorithms, e.g., Kalman filters, and signal processing.

GNSS event that most signified to you that GNSS had “arrived”

Frank van Diggelen says, “‘GPS’ is now a general-purpose noun meaning ‘a thing, method or idea to help you find your way.’ Search for ‘GPS’ in Amazon Books, and you’ll find ‘GPS for the Soul’, by Rabbi Nadav Cohen, ‘Your Jesus GPS: Find Direction, Personal Growth, Inner Peace and Joy’, ‘The Money GPS: Guiding You Through an Uncertain Economy’, and so on”

“I think it’s kind of funny and really great.”

As a consumer, what GNSS product, application, or engineering innovation would you most like to see?

Cars with well-placed docking stations for smartphones and/or the ability to mirror the smartphone screen on a car monitor so that we can use the phone for navigation – and music, podcasts, etc.

“Features and performance in new phones are almost always superior to what’s built into a car,” van Diggelen says.

Favorite equation:

x = Hy

“This will make sense to most Matlab geeks,” says van Diggelen.

The backslash operator ( ) is the matrix division of H into y, or shorthand for the solution to y = Hx.

When y is the vector of pseudorange residuals, and x is the 4-vector of position and time adjustments, then this is the standard GNSS nav equation, and x = Hy is the least-squares solution. If you differentiate both sides with respect to time (while holding H constant), then this is the equation to produce velocity from Doppler residuals.

If you differentiate both sides w.r.t. time (including H), and rearrange terms, then this equation produces the Doppler-Nav result (where you can compute position simply from Dopplers, or from a combination of Doppler and pseudoranges). If you add differential corrections to y, then all of the above is true for DGNSS.

“So you see,” he concludes, “this simple equation is at the heart of everything we do in GNSS nav.”

GNSS Mentors

Alison Brown at Navsys introduced van Diggelen to GPS and taught him most of what he knows. Charlie Abraham and Sergei Podshivalov taught him the rest of GPS and GLONASS, at Global Locate and Broadcom.

“Per Enge, at Stanford, continues to teach me to teach,” he says, “and John Betz [of MITRE Corporation] is the world’s best mentor and guide through the increasingly complex jungle of new GNSS codes.”

Patents held and/or pending:

Frank van Diggelen holds more than 80 patents primarily about assisted-GPS, with many more pending. Issued patents include: Coarse-time Navigation; Long-Term Orbits for A-GNSS; GPS Doppler- Navigation; and interchangeable use of satellites from different GNSS systems, using A-GNSS and other techniques to resolve clock offsets. Also, author of A-GPS: Assisted GPS, GNSS & SBAS, published by Artech House and available in English and Chinese versions.

The post Frank van Diggelen’s Compass Points appeared first on Inside GNSS - Global Navigation Satellite Systems Engineering, Policy, and Design.

1996 soccer game in the Midwest, (Rick Dikeman image)

Nouméa ground station after the flood

A pencil and a coffee cup show the size of NASA’s teeny tiny PhoneSat

Bonus Hotspot: Naro Tartaruga AUV

Pacific lamprey spawning (photo by Jeremy Monroe, Fresh Waters Illustrated)

“Return of the Bucentaurn to the Molo on Ascension Day”, by (Giovanni Antonio Canal) Canaletto

The U.S. Naval Observatory Alternate Master Clock at 2nd Space Operations Squadron, Schriever AFB in Colorado. This photo was taken in January, 2006 during the addition of a leap second. The USNO master clocks control GPS timing. They are accurate to within one second every 20 million years (Satellites are so picky! Humans, on the other hand, just want to know if we’re too late for lunch) USAF photo by A1C Jason Ridder.

Detail of Compass/ BeiDou2 system diagram

Hotspot 6: Beluga A300 600ST

1. SLAVE TRADE
Bangkok, Thailand

1. SLAVE TRADE
Bangkok, Thailand
√ That cheap Thai shrimp we buy at Walmart or Costco is likely to have been caught, harvested, or processed by slaves. Migrant workers from the poorer countries near Thailand are plentiful and ripe for exploitation. In a June 2014 report, the United States ranked Thailand as one of the worst offenders when it comes to human trafficking for sex tourism, garment sweatshops, house servants, and the seafood industry. In an effort to get off that list, the Thai government is installing GPS on fishing boats, establishing minimal work rules, increasing fines and hiring hundreds of anti-corruption staff. Early in January, the foreign ministry said large fishing ships had 60 days to install satellite-based monitoring systems or face 100,000 baht (US$3,469) fines and one-year imprisonment.

January 12, 2015 Reuters: Thailand to adopt fines, GPS to ‘eradicate slave trade’

Guardian investigation on Thai slavery:
June 10 2014 The Guardian: Trafficked into slavery on Thai trawlers to catch food for prawns

U.S. Department of State: Trafficking in Persons Report

U.S. Department of Labor: List of Goods Produced by Child Labor or Forced Labor (Thailand)

2. SWISS CHEESE ON ICE
Greenland
√ Greenland’s melting ice sheet has a leading role in rising ocean levels, and University of California-Los Angeles researchers just found out where most of that water goes. Using highly precise imaging, GPS-equipped buoys, a robotic boat designed by a Jet Propulsion Lab scientist and a helicopter to keep the field team out of danger, they saw networks of rushing turquoise rivers and streams that suddenly disappeared. The land acts like a sponge in part. Mostly, though, it’s like Swiss cheese, the lead researcher said. The island efficiently collects the meltwater and flushes it into the ocean at 23,000 to 46,000 feet per second, double the flow of the Colorado River. See the dramatic video on the UCLA news page.

3. QZSS PLAYS DEFENSE
Tokyo, Japan
√ In a historic pivot in January, Japan’s Prime Minister Shinzo Abe de-emphasized the peaceful uses of outer space and replaced it with military defense, national security, and business development in the administration’s new 10-year Basic Plan on Space Policy. Among many other projects, JAXA and the military will begin a military effort to monitor space debris by 2019, sharing data with the U.S. Defense Department. They also plan six more QZSS launches in the next 10 years to bolster the GNSS regional network now consisting of only one satellite. And the administration intends to increase the value of its public and private space sector industries to ¥5 trillion (US$42.7 billion) in the next decade.

January 9, 2015 The Yomiuri Shimbun: Basic plan on space policy to emphasize natl security

Cabinet Office, Government of Japan (CAO): Basic policy on the implementation of the operational Quasi-Zenith Satellite System (QZSS) project

4. BEASTQUAKE
Seattle, Washington
√ In 2011, the Pacific Northwest Seismic Network found that what came to be known as the Seattle Seahawks’ “Beastquake” created vibrations that measured between a magnitude 1 and 2 earthquake during a magnificent touchdown run. By the time you read this, the 2015 NFL playoff between Seahawks and Panthers will have delivered more data. PNSN set up three earthquake monitors in CenturyLink Field to register the seismic effects of 67,000 people jumping around. Fans can simultaneously check out a live feed from the game to discover how the Earth is responding. PSNS is testing a web-based monitoring and alert system connected to the regional array of PNSN seismometers and GNSS reference stations and using software that shows vibrations within three seconds. When it’s perfected, scientists hope to give residents a few seconds or even minutes to prepare in a city where a major subduction zone quake is now overdue.

January 7, 2015 University of Washington: How the ‘Beast Quake’ is helping scientists track real earthquakes

The post GNSS Hotspots | January 2015 appeared first on Inside GNSS - Global Navigation Satellite Systems Engineering, Policy, and Design.

That’s why the long-standing comity among system operators in the GNSS sphere is particularly notable and welcome. “Interoperable and compatible” is the first principle espoused by the four nations under the aegis of the International Committee on GNSS.

These days getting the United States, Russia, China, and Europe to agree on a common policy seems to be an increasingly rare event.

That’s why the long-standing comity among system operators in the GNSS sphere is particularly notable and welcome. “Interoperable and compatible” is the first principle espoused by the four nations under the aegis of the International Committee on GNSS.

Another principle particularly dear to U.S. policymakers is ensuring a “level playing field” that avoids preferential treatment for one’s own system so as to disadvantage the use of other GNSSes within a nation’s boundaries.

So, the latest incursion of the Federal Communications Commission (FCC) into GNSS affairs is more than annoying; it’s potentially ruinous for U.S. interests in both the commercial and diplomatic domains.

In recent testimony to the board that advises the National Space-Based Positioning, Navigation, and Timing Executive Committee that oversee GPS policy, a high-ranking official from the FCC Office of Engineering and Technology said that foreign GNSS systems will need to obtain authorization to operate legally in the United States. Further, he suggested that imported GNSS products may need to be regulated and domestic GNSS products, certified as meeting FCC standards.

Dee Ann Divis provides the details in this issue’s Washington View — but they aren’t pretty and plenty of ambiguities have arisen.

The FCC, an agency established and overseen by Congress, has a checkered past in GNSS affairs. It appeared to become aware of the technology only in 1996 after issuing its first notice of proposed rulemaking for enhanced 911 (E911), which provides automatic position reporting for emergency callers using mobile phones. Even then, the benefit of GNSS had to be thrust upon the agency by industry — FCC engineers had helped shape the policy with the assumption that less precise network-based techniques would be used for positioning.

After GNSS and cell phone manufacturers demonstrated the superior accuracy of GPS and its utility in remote areas where cell towers were few and far between, the agency adopted a “technology-agnostic” stance but still set a double standard for network-based and GNSS-based solutions.

The FCC next showed up in the early 2000s as advocates of ultrawideband (UWB) sought to cut a swath through GNSS frequencies. Only after extensive tests showed the potentially devastating effects on GPS did the agency modify the UWB proposal and design to protect the bands.

That exercise foreshadowed the recent experience with LightSquared’s wireless broadband initiative, which the FCC only grudgingly — and still not completely — squashed.

From the outside (and through the eyes of an admittedly partisan GNSS supporter), these persistent missteps of the FCC seem to arise from a lack of appreciation of the positioning technology — both in how it works differently from two-way voice and data services and in its free access to users.

Technically, the minutely powered GNSS transmissions are whispers in a room full of partygoers. In a Washington, D.C., environment where billion-dollar spectrum auctions by lots of attention and favors, a free service like GPS gets treated like a panhandler on the street corner.

What is to be done in this situation?

First, the agency needs to make its intentions and plans clear and unambiguous. If they include authorization of foreign GNSS services’ operation in the United States, that should be granted to any compatible system without delay. Then, if import controls and receiver standards are at issue, those should be dealt with on the same basis as GPS.

Apparently, because of the agency’s relative autonomy, even the president — who hasn’t noticeably appreciated GPS much more than the FCC — can only request waivers of the authorization requirement. But the White House appoints the agency’s commissioners; so, it should be able to persuade them to do the right thing, if it comes down to that.

There’s quite a party going on with GNSS these days. The FCC would play better as an invited guest than in its current guise as a gate crasher.

The post The Party Crashers appeared first on Inside GNSS - Global Navigation Satellite Systems Engineering, Policy, and Design.

A decade has passed since the first GNSS system-level authentication protocols were proposed, and yet the current ongoing discussion is still, “Do we really need GNSS signal authentication?” Indeed, the current argument is whether we need authentication at the system level (the satellite broadcast service) or whether user-based authentication (anti-spoofing) is sufficient for a number of application requirements.

A decade has passed since the first GNSS system-level authentication protocols were proposed, and yet the current ongoing discussion is still, “Do we really need GNSS signal authentication?” Indeed, the current argument is whether we need authentication at the system level (the satellite broadcast service) or whether user-based authentication (anti-spoofing) is sufficient for a number of application requirements.

Risk analysis for every application should produce security requirements that would allow us to discriminate determine the actual need of either user-based or system-based techniques. For instance, if the likelihood of a spoofing attack on your favorite car navigator is quite low and the resulting effect would be negligible, car navigators probably will not require use of encrypted signals with security module for authentication. Some simple checks on the receiver time bias and carrier-to-noise power density (C/N₀) will do the job to fulfill these requirements.

On the other hand, unfortunately, we expect a growing number of threats and cyber-attacks in the future: the Internet has three billion users today, and the annual impact of attacks on the global economy has risen to $445 billion. With GNSS having more than two billion devices in operation today and seven billion predicted for 2020, a number of GNSS safety and financial critical applications will demand more and more security and trust.

This article will take up the problem of GNSS signal authentication, beginning with the definition and classification of requirements and presenting a categorization of applicable schemes. We will provide an extensive summary on state-of-the-art, data-level authentication schemes, based on well-established broadcast authentication protocols that can be exploited for providing efficient navigation data authentication. In particular, we introduce a novel scheme for open signal authentication using supersonic codes.

Foundations of Signal Authenticity
GNSS authentication is a complex multi-domain problem. A receiver estimates its own position and time by calculating ranges and time bias from satellites, with satellite positions and system time obtained from the same source. This leads to the conclusion that GNSS authentication is achieved by:

• the level of trust in the range estimation
• the level of trust in satellite position and system time information
• the level of trust in the component equipment that calculates position, time, and velocity from the foregoing factors.

Various branches of science and engineering help us address these three problems, particularly, signal estimation theory, information source authentication and non-repudiation, and physical and software security.

As physical and software security pertains to receiver design requirements, we will focus on range estimation and data authentication and trust for the system-level aspects. One complexity in GNSS signal authentication design is that the use of data-level authentication does not necessarily fulfill the trust requirement for range estimation, and trust in range estimation does not satisfy the trust requirement for the authenticity of satellite data.

Another crucial point to discuss in requirements analysis is the need for source authentication or non-repudiation, the ability to ensure that a party to a communication cannot deny its authenticity. For example, in cryptography source authentication can be achieved with a message authentication code (MAC). “Alice” sends information with an attached MAC to “Bob,” and Bob can verify the source authentication. However, MAC does not achieve satisfy the need for non-repudiation, as an impartial third party cannot verify the origin of the message because both Alice and Bob own the secret key to generate the MAC.

In GNSS non-repudiation could be a requirement worth considering. For example, as illustrated in Figure 1 (for Figures 1 – 4, see inset photo, above right), a ship might be navigating in water from Country B, and Country A might challenge its position as being within Country A’s territorial boundary. The ship’s crew might reply that the ship position only appears to be in Country A because of a spoofed signal, but it actually did not cross the borderline. Country C would be the impartial third party that has the capability to verify if Country B used authentic signals.

We can summarize the requirements for GNSS authentication in terms of the following factors:

• navigation data integrity, source authentication, non-repudiation and/or position/velocity/time (PVT) authentication
• performance, such as time to authentication (TTA) and accuracy of authentic position
• probability of failure
• robustness
• interoperability.

Time to authentication refers to the time required by the system to detect an anomaly and respond to it. In signal authentication, TTA is an important requirement, as the receiver time and dynamics will be compromised from the beginning of a spoofing attack until its detection. Therefore, these effects need to be minimized quickly and appropriately, based on application requirements.

Probability of failure refers to the trust that one can give to the authentication scheme. This includes the probabilities of missed detection and false alarm, and is fundamental for the determination of the integrity risk in safety-critical applications. For example, if we want to use an authenticated signal in a safety-of-life (SoL) application with an integrity risk requirement of 3.5 x 10–7 over 150 seconds, these requirement constraints are expected to represent the lower bound for the probability of failure of the authentication protocol.

Robustness refers to the capability to mitigate a number of known attacks. For example, some application may require protection from replay attacks, while others may not.

Finally, interoperability refers to the capability of the authentication scheme to be used by a number of different applications in various environmental contexts, and to be transparent to legacy equipment. For example, providing support to L1 frequency without compromising other navigation service performance represents an important interoperability requirement.

Authentication Domains
To date, GNSS authentication protocols have been proposed in three domains: data level, signal level, and hybrid level (data + signal).

Data-level authentication schemes refer to the implementation of cryptographic protocols in the navigation data. In simple words, such approaches can be seen as “digitally signing” the navigation data in order to authenticate the source of the data generator and ensure the integrity of the received message.

In a 2005 paper by C. Wullems et alia (listed in the Additional Resources section near the end of this article), we introduced the concept of data-only authentication, calling the technique “navigation message authentication” (NMA). NMA has the advantage of having a low system impact, as it requires only upgrades of the GNSS satellites’ navigation data generation subsystem along with a low-cost implementation on the receiver side. NMA can be implemented through various schemes that we will discuss later in this article.

Disadvantages of NMA include TTA performance, which is limited to the specific implementation (e.g., digital signatures, block hashing, hash chaining, etc.), as well as the required bandwidth to implement NMA. The probability of failure for an NMA scheme depends on the number of bits included in the authentication function and on the size of the authentication payload. For instance, if 30 seconds of data are authenticated, a single bit error not detected by the channel-coding scheme would result in a false alarm. On the other hand, a missed detection in nominal conditions (not under attack) is unlikely with a well-designed NMA scheme.

Unfortunately, NMA is exposed to replay attacks if the spreading codes are public and available to everyone for the estimation and replay of the symbols. This forces the receiver to integrate a trusted clock in order to increase robustness.

Signal-level schemes tackle the vulnerability to replay attacks by exploiting the properties of spread spectrum signals, which in GNSS are below the thermal noise. For an attacker, with standard equipment and without knowledge of the secret code, it is therefore very difficult to demodulate the signal. Only the knowledge of the secret code, in fact, allows the signal de-spreading to perform ranging and data demodulation.

This article will discuss the state of the art in data-level authentication, and a new approach for signal-based authentication capable of carrying high data rate needed to achieve an efficient hybrid authentication scheme (data+signal authentication).

GNSS Data-Level Authentication
In the field of broadcast authentication, GNSS data authentication seeks to provide a set of security properties, including data integrity, data authentication, and possibly non-repudiation. In particular, GNSS data authentication aims at providing source authentication, that is, at ensuring that a legitimate GNSS satellite actually generated the navigation data received by generic user equipment.

The simplest broadcast data authentication schemes are based on standard applications of authentication solutions, such as message authentication codes (MACs) and digital signatures (DSs), including variations such as hash-based MACs and cipher-based MACs. In general, MACs provide data integrity and data authentication together with bandwidth and computational efficiency but cannot ensure non-repudiation. Moreover, they require secure use and storage of symmetric keys (e.g., via smartcards) in order to prevent a malicious user from compromising the security of the entire authentication service by disclosing the secret keys.

Digital signatures, on the other hand, address all the required security properties (integrity, authentication, and non-repudiation). Unfortunately, they result in high computational and per-packet communication overheads.

More elaborate broadcast data authentication schemes leverage the aforementioned standard authentication solutions and trade-off the following features: computation and communication overhead, buffer space requirements, authentication delay, verification probability, and loss tolerance as opposed to reliable delivery. In the following, three main families of broadcast authentication schemes are considered: block hashing, hash chaining, and MAC-based source authentication schemes. Figure 2 depicts the taxonomy of the broadcast authentication schemes considered.

Block hashing schemes follow the paradigm of spreading the cost of the signature operation among a number of blocks by using the properties of hash functions. The main idea is that, for each set of blocks, a single signature is transmitted together with the hashes of each block. This allows the receiver to verify the authenticity of all blocks, by checking the consistency of each hash with the digital signature.

Block hashing can use either a star or a tree-based approach, depending on the hierarchy of the authenticated blocks. This type of hashing leverages the reduced size of hashes as compared with digital signatures in order to minimize both the bandwidth and the computational requirements. In the context of GNSS authentication, blocks could be identified either with corresponding portions of data (e.g., the same pages) sent by different satellites, or with different navigation message chunks in each satellite (e.g., different pages in a sub-frame).

Hash chaining is a further technique for authenticating streaming data, based on a hash chain commitment via digital signature. The hash chaining can be either “forward” (signature follows data packets, thus resulting in a delayed authentication) or “backward” (signature is transmitted first, thus allowing immediate authentication).

Hash chaining schemes require the sender to know the entire data stream in advance (and is therefore applicable to GNSS ground segment design). In its standard application, however, hash chaining does not tolerate packet loss. Because of this, its application in GNSS authentication is limited, as the bit error rate rapidly degrades with lower satellite visibility at the receiver.

Variations of standard hash chaining have been proposed to address this issue, based on multiple hash chains and resulting in a higher per-packet communication and computational overhead. Efficient multi-chained stream signature (EMSS) is an example of such an authentication protocol, supporting loss-resilient and probabilistic authentication verification. EMSS is based on hash chains of degree k, meaning that each packet’s hash is sent in k different packets, with random chaining sequences leading to a higher probability of verification. Augmented chaining is another strategy that, based on the transmission of redundant hashes, provides resiliency against errors burst. Finally, the piggybacking scheme deals with the case where data carried by different packet has more or less importance from the point of view of the application level.

Various levels of priorities could be assigned to data packets, so that the higher the priority of a packet, the more redundant will be the hash chaining of packets belonging to that class. This approach allows tailoring the robustness of packets against bursty losses as a function of their priority. In the context of GNSS such a technique could be used for maximizing the robustness of the authentication scheme for some selected data (e.g., time of week (TOW), ephemerides, and so on) as compared with less critical types (e.g., the almanacs).

MAC-based source authentication schemes are hybrid solutions that jointly use MACs and digital signatures in order to provide broadcast authentication. More precisely, these schemes are based on four main ingredients: one-way hash chains, (loose) time synchronization, MACs, and digital signatures for the source verification of hash chain commitments.

A remarkable example of MAC-based source authentication is the timed efficient stream loss-tolerant authentication (TESLA) protocol and its extensions, including instant authentication, management of concurrent instances, and increased robustness to denial-of-service attacks. It is worth mentioning that the authors of TESLA also presented another protocol, BiBa (bins and balls signature), that falls in none of the previous three families of authentication schemes. BiBa is based on one-way hash functions without a trapdoor: to sign a message, the signer uses the message to seed a random process, which throws a set of balls into bins. The balls represent SElf-Authenticating Values or SEALs, random numbers generated in a way that the receivers can instantly authenticate them with the public key. The bins correspond to the range of the hash function. When enough balls fall into the same bin, the combination of those balls constitutes a signature.

As a conclusion to this overview, we should note that the robustness of any data-level authentication protocol to transmission errors could also be increased — that is, the probability of authentication failure could be decreased — by using forward error correction (FEC) schemes.

In this context, as described in the paper by M. Canale et alia (Additional Resources), we have tested two different solutions for enhancing the data-level authentication with FEC on the Galileo Commercial Service. The first solution employs a common and effective code concatenation: the inner convolutional code (already available in Galileo) is coupled with an outer Reed-Solomon (RS) block code. These two codes respectively combine good performance in the presence of random and bursty errors. The second solution is based on the nested use of convolutional encoding and interleaving, achieving a double time diversity of the data broadcasting, while keeping the same end-to-end delay of a block interleaver.

Figure 3 shows the performance of the proposed schemes with various parameters in terms of bit error rate (BER) and carrier-to-noise density ratio (C/N₀) when a second layer of FEC is applied. The top panel (a) shows convolutional code and interleaving (CC) for various lengths of the input data stream, e.g., two seconds for a single E1 page. The bottom panel (b) illustrates the performance of Reed-Solomon codes with rates 1/2, 2/3, and 0.82 Note that the length of the input data stream has little effect on the E6 BER.

Even though these schemes are proposed in order to compensate the gap between the Galileo Open Service and the Galileo Commercial Service in terms of bit error rate, their use could be extended to an arbitrary data-level authentication scenario. (Due to the E6 SIS design, however, the BER on the CS navigation messages is considerably higher than the one measured on the E1 Open Service for the same signal-to-noise ratio.)

GNSS Signal-Level Authentication
A known technique to provide signal authentication as well as access control is the full encryption of the spreading code. This approach, however, lacks the interoperability property and requires time knowledge (time fix) for the acquisition of the signal.

The first signal-level authentication proposal that allowed interoperability was presented in a 2003 paper by L. Scott (Additional Resources) with a scheme called spread spectrum security codes (SSSCs), which also proposed a data-supporting infrastructure. A similar approach was proposed in 2004 by M. G. Kuhn. Later, in the paper by O. Pozzobon et alia (2010) we proposed a concept based on the dissemination of encrypted chips with a scheme called signal authentication sequences (SAS). A drawback of all these signal-based authentication schemes is a weakness in TTA. They also require an aiding channel or a dedicated bandwidth as chips are transmitted in the navigation data.

One interesting approach that Qascom has investigated is the transmission of secret codes multiplexed with open codes, to achieve what is also known as “signal watermarking.” This led us to the concept of supersonic GNSS authentication codes[18], a solution that provides hybrid authentication achieving both data-only, signal-only, or combined data- and signal-level authentication. The scenic term “supersonic” derives from the fact that authentication could be achieved faster than the symbol speed.

We designed the protocol in order to fulfill the previously mentioned requirements for signal authentication. Particularly, we considered these main drivers:

• Low probability of failure in nominal conditions. The protocol can define the code length in order to satisfy the desired probability of failure requirements.
• Legacy hardware support via combination with an open signal (multiplexing). The main idea is to transmit the supersonic codes multiplexed with open codes (such as GPS C/A or Galileo OS) to allow interoperability with open services and support mass-market applications. 
• Based on symmetric cryptographic schemes. This is required for signal-level authentication. 
• Based on block ciphers. The supersonic codes are block ciphered and in code phase with open codes, and the same code is repeated for a predefined security period. This allows direct authentication without time dependency, as opposed to stream-cipher-based solutions.
• High data rate capability to support the transmission of data authentication schemes such as block hashing digital signatures or hash chains as discussed before.
• Comprises two stages, for achieving different security levels based on robustness requirements and/or receiver constraints.

High-Level Protocol Description
As an introduction to the proposed authentication scheme, the following section provides a high-level description of supersonic code generation.

The proposed protocol assumes that the supersonic codes are multiplexed with an open code, and that they are synchronized to it. This scheme is based on the block-cipher encryption of the open code, resulting in an encrypted code valid for a predetermined crypto-period T_crypto (Figure 4). When a crypto-period expires, a new initialization vector (IV) is provided as input to the block cipher and a new encrypted spreading code is generated. In the following discussion, we refer to the encrypted code as “fundamental code.”

This strategy allows a receiver that knows the IVs (for example, through previous transmission via navigation data) to select the IV to be used with a loose system time synchronization of the receiver and without a time fix. For example, a receiver clock with poor performance (e.g., 10–5 seconds in a one-second drift) could guess a five-minute window after one year. So, a receiver lacking a time fix can still acquire the supersonic code based on a rough estimate of time.

The fundamental code is then modulated with a code-shift-keying (CSK) modulation, where the CSK shifts are generated by time-dependent unpredictable symbols. This ensures that the scheme is not vulnerable to an attack based on coherent integration and forces an adversary to continuously read the CSK shifting in order to perform a signal-based replay attack, by making the attack very complex and unlikely.

As a further benefit, GNSS signal design is looking to CSK as a new opportunity to increase the bit rate of GNSS signal data components and extend the possibility of adding new services. Indeed, with the introduction of new dataless (pilot) signal components that enables receivers to achieve precise synchronization on the pilot channel alone removes the need to adopt BPSK modulation for the data.

Supersonic Codes: An Analytical Description
We will now describe the process of generation of the supersonic codes with an analytical approach. First, we will detail the signal generation process, then describe the estimation at the receiver, and follow up with an explanation of the procedure for verifying signal authentication.

Signal Generation. Let p and c₀ be the open and a fundamental code, respectively, and L_p and L_c the corresponding number of chips. In addition, let T_p and T_c be their respective chip period, so that the fundamental code duration T_s is defined as T_s = T_c • L_c, corresponding to a symbol-rate of R_s = 1/T_s.

In order to allow synchronization, the number of chips of the fundamental code c₀ shall be chosen such that:

L_p = N ⋅ L_c    (1)

where N is integer and T_p = T_c. Note that this also ensures that the signal carrying the secure code has the same chipping rate as the open code.

The first step of the supersonic authentication scheme consists of the generation of a fundamental crypto-code c₀ that is used as a baseline for a subsequent CSK modulation. This secret code c₀ is valid for a crypto-period T_crypto >> T_s, and is then renewed; the time slots associated with each crypto-period are denoted by j, so that the fundamental code for the j-th slot is denoted by c₀(j).

More precisely, the fundamental code is generated for each crypto-period as follows:

c₀(j) =  E_k₁‚(p,IV(j))    (2)

with E_k₁ being a block cipher (e.g., AES-CBC) indexed with a secret key k₁, and IV₁(j) representing the initialization vector. Note that (2) takes into account neither the truncation nor the padding that may be required for meeting the synchronization condition (1). Such parameters depend both on the specific block cipher used for the encryption and on L_p. For the sake of readability, in the following discussion, the dependency of the fundamental code on j is omitted in the notation.

From a security perspective, the fundamental code described in (2) ensures that c₀ is not known to an adversary who does not have access to the secret key k₁. In principle, this should ensure that the attacker is not able to despread the signal. However, as mentioned earlier, the scheme is vulnerable to a coherent integration attack, and this vulnerability is the main driver for the design of the second step.

The second step of the supersonic authentication scheme, in fact, addresses this security issue by leveraging the CSK modulation, that is, by circularly shifting the fundamental code c₀ for every time slot of duration T_s (in the following, each of these time slots is indexed with i).

The CSK shift is chosen by means of a cryptographic data authentication function in the symbols modulation. This ensures its unpredictability for the adversary and prevents coherent integration. The alphabet of possible CSK shifts is denoted by δ and is a sampled sub-set of {0,1 … , L_c – 1} with cardinality M; each shift can therefore be uniquely identified by B = log₂(M) bits . . .

(For the complete story, including equations and figures, please download the PDF using the link at the top of the page.)

Acknowledgments
The authors wish to thank Dr. José Angel Ávila Rodriguez, Dr. Massimo Crisci, and Dr. Rigas T. Ioannides from the European Space Agency for the fruitful discussions on signal design, Ignacio Fernándex Hernández from the European Commission for the important considerations on data schemes, and Prof. Vincent Rijmen from KU Leuven University for his insightful support on cryptographic features.

Additional Resources
[1] Bellare, M., and R. Canetti, and H. Krawczyk, “Keying Hash Functions for Message Authentication,” Advances in Cryptology, CRYPTO ’96 (Vol. 1109), Springer-Verlag, 1996
[2] Canale, M., and S. Fantinato, and O. Pozzobon, Qascom S.r.l, “Performance Comparison of Different Data Authentication Solutions for the Galileo CS”, in NAVITEC 2014 Conference Proceedings, Noordwijk, Netherlands
[3] Dworkin, M. J., Recommendation for Block Cipher Modes of Operation: the CMAC Mode for Authentication, Special Publication 800-38B, National Institute of Standards and Technology, 2005
[4] Fernández-Hernández, I., “GNSS Authentication: Design Parameters and Service Concepts,” Proceedings of European Navigation Conference GNSS 2014
[5] Garcia-Peña, A., “Analysis of Different CSK Configurations in a Urban Environment When Using Non-coherent Demodulation,” Proceedings of Navitec 2014
[6] Garcia-Pena, A., and D. Salos, O. Julien, L. Ries, and T. Grelier, “Analysis of the Use of CSK for Future GNSS Signals,” 26th International Technical Meeting of the Institute of Navigation Satellite Division, (ION GNSS+ 2013), Nashville, Tennessee USA
[7] Gennaro, R., and P. Rohatgi (1997), “How to Sign Digital Streams,” Advances in Cryptology, CRYPTO’97, 1997
[8] Gennaro, R., and P. Rohatgi (2001), “How to Sign Digital Streams,” Information and Computation, 165(1):100–116, February 2001
[9] Golle, P., and N. Modadugu, “Authenticating Streamed Data in the Presence of Random Packet Loss,” NDSS’01: The Network and Distributed System Security Symposium, 2001
[10] Humphreys, T., “Detection Strategy for Cryptographic GNSS Anti-Spoofing,” IEEE Transactions on Aerospace and Electronics Systems, vol. 49, no. 2, pp. 1073–1090, April 2013
[11] Kuhn, M. G., “An Asymmetric Security Mechanism for Navigation Signals”, in 6th Information Hiding Workshop. LNCS 3200, Springer-Verlag, pp. 239-252, 2004
[12] Merkle, R. C. “Advances in Cryptology — CRYPTO ‘87,” Lecture Notes in Computer Science 293, p. 369, 1988
[13] Miner, S., and J. Staddon, “Graph-Based Authentication of Digital Streams,” IEEE Symposium on Security and Privacy, 2001
[14] Paonni, M., and M. Bavaro, M. Anghileri, and B. Eissfeller, “On the Design of a GNSS Acquisition Aiding Signal,” Proceedings of ION GNSS+ 2013, Nashville, Tennessee USA
[15] Park, J-M., and E. KP. Chong, and H. Siegel, “Efficient Multicast Packet Authentication Using Signature Amortization,” Proceedings of the 2002 IEEE Symposium on Security and Privacy
[16] Perrig, A., and R. Canetti, J. D. Tygar, and D. Song “The TESLA broadcast authentication protocol,” CryptoBytes, Volume 5, No. 2 (Summer/Fall 2002), RSA Laboratories, EMC Corporation, Hopkinton Massachusetts USA
[17] Perrig, A., and R. Canetti, D. Song, and J. D. Tygar, “Efficient and secure source authentication for multicast.” Network and Distributed System Security Symposium, NDSS. Vol. 1. 2001.
[18] Perrig, A., “The BiBa One-Time Signature and Broadcast Authentication Protocol,” Proceedings of the 8th ACM conference on Computer and Communications Security, 2001
[19] Pozzobon, O. (2010), and L. Canzian, M. Danieletto, and A. D. Chiara, “Anti-spoofing and open GNSS signal authentication with signal authentication sequences,” 5th ESA Workshop on Satellite Navigation Technologies and European Workshop on GNSS Signals and Signal Processing (NAVITEC), Noordwijk, Netherlands, 2010
[20] Pozzobon, O. (2014), and G. Gamba, M. Canale, and S. Fantinato, Qascom S.r.l., “Supersonic GNSS Authentication Codes,” Proceedings of the 27th International Technical Meeting of The Satellite Division of the Institute of Navigation (ION GNSS+ 2014), Tampa, Florida USA
[21] Scott, L., “Anti-Spoofing and Authenticated Signal Architectures for Civil Navigation Systems,” Proceeding of ION GPS/GNSS 2003, Institute of Navigation, Portland, Oregon, 2003, pp. 1542–1552
[22] Sun, and G. Bi, Y. Guan, and Y. Shi, “Performance analysis of M-ary CSK Based Transform Domain Communication System,” Proceedings of the 2nd International Conference on Circuits, Systems, Control, Signals (CSCS 2011)
[23] Wullems, C., and O.Pozzobon, and K.Kubik, “Signal Authentication and Integrity Schemes for Next Generation Global Navigation Satellite Systems,” Proceedings of the European Navigation Conference GNSS 2005, Munich, Germany

The post From Data Schemes to Supersonic Codes appeared first on Inside GNSS - Global Navigation Satellite Systems Engineering, Policy, and Design.

After dodging budget cuts, thwarting other teams’ attempts to grab critical frequencies, and dealing with jamming and technical problems, members of the U.S. GNSS community were thrown another curve late last year when they learned that signals from GLONASS and other international constellations must be authorized for use in the United States.

No reality show contestant ever neared the finish line without the producers serving up another challenge. And so it is for would-be multi-GNSS users in the United States.

After dodging budget cuts, thwarting other teams’ attempts to grab critical frequencies, and dealing with jamming and technical problems, members of the U.S. GNSS community were thrown another curve late last year when they learned that signals from GLONASS and other international constellations must be authorized for use in the United States.

“There’s an authorization that is required in order to operate with those signals,” said Ronald Repasi, deputy chief of the Federal Communications Commission (FCC) Office of Engineering and Technology.

“That’s the key word ‘operate with.’ The capability to receive in a piece of equipment a signal from a foreign system doesn’t in itself make it legal. It is the process that the receiver goes through to operate with those signals that requires the authorization.”

The genesis of the regulation goes back to World Trade Organization (WTO) agreements made in the late 90s, Repasi explained to the December meeting of the National Space-Based Positioning, Navigation, and Timing (PNT) Advisory Board.

“Countries around the world were worried about access to each other’s markets,” Repasi said. “One of the things that’s important from the Commission’s standpoint is that there are effective competitive opportunities in the foreign country that operates that satellite for all our individuals who want to serve their country. The process that was set up under the WTO codified that point as far as establishing competitive opportunities.”

Although it is doubtful that the rules in question were originally aimed at radio navigation satellite services (RNSS), the term of art used in spectrum allocations that include GNSS systems, they are in place and must be dealt with, said an expert familiar with the subject.

“That rule was written largely for communications outlets but it was written very generally to includes all kinds of signals that might be coming from space,” said the expert, who like nearly all who spoke to Inside GNSS, asked not to be named so as to speak freely on the subject.

“While I don’t think the people were really thinking about RNSS systems back in the day, the language is such that it does apply. Technically there needs to be an authorization or an allowance, if you will, to accept foreign RNSS signals in the U.S.”

The consequences of not getting authorized are twofold. First, the unauthorized signal cannot be used for official, nonfederal purposes such as helping determine locations of mobile E911 callers. And, second, the signal will not be protected against interference.

That reality is part of why the issue is coming to a head now.

“We would like all the pieces of critical infrastructure in the United States to be able to take advantage of these signals with appropriate integrity,” said another expert familiar with the issue.

“That implies, at least as far as the FAA [Federal Aviation Administration] level of integrity, that we have some kind of integrity monitoring system in place. As soon as you dig into that, you discover not only isn’t there anything in place in any formal way, [but] furthermore, in general, the signals aren’t even authorized to be received and used in the United States.”

“To use these other (signals) in any meaningful way,” this source asserted, “you have to ensure that they have integrity and that they are authorized to be used.”

Five Criteria
Fortunately, the process to get over this hurdle is fairly straightforward. The National Telecommunications and Information Administration (NTIA), on behalf of the executive branch, recommended in 2011 that waivers be granted as long as the GNSS system applying for the waiver met five criteria.

First, the system would have to comply with United Nations’ space debris mitigation guidelines. This is something the FCC has to do for a lot of other communication satellites, explained a source familiar with the process.

Second, granting the waiver has to be consistent with U.S. trade and other treaty obligations. “So we wouldn’t be granting a waiver to, say, a space system built by Iran, where we have sanctions,” the expert quipped.

Then it must be clear that the waiver is limited to receive-only RNSS, said the source, “including positioning, standard time and frequency satellite services. So, we’re not talking about waiving messaging services, data transmissions, or other sorts of things.”

The fourth criteria is that the incoming signal has to be compatible with U.S. government systems operating in the same band — that is, in this case, the international signal must not interfere with GPS.

Generally speaking, the technical information being requested to address that criterion is already filed publicly at the International Telecommunication Union (ITU), said the expert, and filing an application should not put a system at a competitive disadvantage.

“We’re not asking for anything sensitive or for any trade secret information,” said the source. “[W]e would not want to do the same reciprocally. So, we want it to be as simple as possible.”

Finally, granting the waiver must be in the public interest.

Few would question the new signals as being in the public interest, according to the first source. Access to additional satellites from other GNSSs will improve service for users and reduce the need for the U.S. to launch even more GPS satellites to deal with signal blockage caused by steep terrain or tall buildings.

“You get police or firemen in places where there are tall buildings, and they are sky-impaired,” said the expert. “ For heaven’s sake, they ought to be authorized formally to use that signal.”

Although the government-to-government process is not complicated, a risk exists that other nations will not look kindly on having to file for a waiver — something the U.S. is not required to do anywhere on behalf of GPS service. The source said that delegates to the recent meeting of the International Committee on GNSS (ICG) were incredulous when they learned of the requirement.

In fact, concern has arisen that the United States could find itself filing for GPS landing rights in other nations.

“Despite the fact that this a fair [application] process because everyone has to do it,” said another expert familiar with what is going on, “some of the nations around the world might decide that they might want to try to apply this process to GPS.”

Having to submit an application is not the issue, the expert explained.

If another nation’s application process “was as simple as our process, that would be fine,” the source said. “It would be bad for anyone to use this process as an excuse to create their own process which is not fair and actually is a trade barrier.”

Given that, would it not be simpler still to void the requirement and allow other nations to skip the process altogether? It would be, said one of the sources, but that is not possible. Today’s radio regulations and the other provisions that apply don’t have a carve-out for RNSS.

“The executive branch can’t issue a waiver,” the source explained. Although the White House can request a waiver, the independent FCC is the one that must issue it.

Certified Confusion
The process for getting waivers may be clear, but the process, if there is one, for U.S. receivers using non-GPS signals, is not.

“I’m trying to see if there’s any way through this morass, said Brad Parkinson, the acting chair of the PNT Advisory Board. “Right now there are literally hundreds of thousands of GPS–GLONASS, nonfederal receivers using GLONASS for very useful purposes to navigate tractors and all kinds of stuff — and iPhones probably. The horse has sort of left the barn, but is he going to get shot? What are you going to do with this thing?”

“It comes down to what we expect to happen in the public comment process when we get the request to operate with those foreign systems,” replied Repasi.

During the comment process, he explained, “the public has the opportunity to object to us, agree to issuing that authorization or supporting it, or finding some other issues that may be important from their perspective, like power levels and out-of-band emission levels and such. The Commission, in adjudicating those differences of opinion that come in during that comment period, will issue an order giving a rationale why we are granting in part or perhaps even denying an authorization request.”

Any public comment process, however, has the potential to open the door to debate over other the considerations.

“I would imagine,” said Repasi, “that, when there are requests to waive the FCC rules to permit operation with foreign signals, that the first question some may have is ‘What are the interference protection rights that are being afforded by any kind of a waiver.’”

One of the issues, an expert pointed out, is that a previous proposal by would-be wireless broadband supplier LightSquared to use bands adjacent to GPS would have impacted signals from other GNSS systems as well. Giving interference protection to those services through a waiver or authorization could color debate on that issue, which is not fully resolved.

Another attendee at the advisory board meeting expressed concern to Inside GNSS that the process may become a back door to trying to set receiver GNSS standards so that a wider range of other applications could use bands adjacent to those used for satellite navigation.

LightSquared Redux?
It’s easy to see what might prompt such a concern. During his talk Repasi mentioned several issues rooted in the ongoing standards debate, some of which seemed out of context for a discussion about a seemingly straightforward GNSS waiver process.

Noting that the primary RNSS band at 1575 MHz was surrounded by noisy mobile satellite services, he said he thought “this is where we start focusing on what exactly is adjacent to this RNSS allocation. If you look at Globalstar, Iridium, Inmarsat, these are all systems that have been deployed in handsets as well as terminals. Those are operating a very high power levels compared to, like, a cell phone. . . . There are ships out there that have these terminals on the same mast as the GPS antenna, and it would be an interesting question to understand how something in their close proximity geographically and that closer proximity frequency can tolerate that type of power level.”

Repasi added, “I think that’s something that the [Department of Transportation (DoT) Adjacent Band Compatibility (ABC)] Assessment may want to start looking at. What is actually out there as far as the RF environment goes and see how these receivers are able to tolerate that?”

The ABC Assessment is considering ways to limit interference to GNSS services by setting maximum power levels for adjacent bands. It is the flip side of receiver standards, which put the onus for dealing with interference on the receivers.

Repasi noted that an FCC technical advisory council is weighing whether “risk informed” interference assessments should be introduced to take into account the risk of interference occurring as opposed to using the worst-case scenario, he said which was traditionally used by the DoT.

Repasi also suggested, based on the experience of the WiFi Alliance, that standards will not stifle innovation.

Receiver Standards & Certification
The WiFi discussion sprang from a question on ensuring that equipment, particularly imported devices, complied with the rules.

“We have accredited certification bodies throughout the world,” Repasi said. “So, those devices [for example, imported] from Bangladesh would go into a certification body of their choice. They have to be accredited, of course; there are some hoops that they would have to jump through to show that they get the accreditation, these certification bodies.”

He added, “But after going through the process of certification bodies, if they are going to be bringing their equipment into the U.S., they have to respect our compliance rules. So, they have to test against what the FCC rules would be for entering U.S. markets. And they get it an identifier associated with that device to show that they passed the certification process.”

While discussion of certifying GPS receivers is part of the separate debate over setting receiver standards for spectrum reasons, said one expert, “I don’t see any legislative or regulatory authority” for doing so as part of the waiver process. “I certainly don’t see anybody on the GPS industry side or any of the government agencies that think that’s a good idea.”

The apples and oranges juxtaposition of the signal waivers/authorizations requests with elements of setting standards for GNSS receivers and certification process for foreign-made devices, created confusion around the requirements for receivers, suggested another person following the issue. Indeed, the half a dozen people who spoke to Inside GNSS after attending the meeting were split on whether equipment certification was required or not for multi-GNSS equipment. Requests to Repasi for more information were not returned by press time. Repasi did say that existing multi-GNSS receivers are not illegal.

Whatever the confusion, GNSS advocates agree on one point in particular — that any holdup in granting landing rights would be antithetical to America’s clearly stated and inclusive GNSS policy.

“There is a vulnerability in that we need to be good global citizens because other people are relying on GPS,” explained one of the experts. “I think it is incumbent upon us as part of our policy of promoting interoperability and compatibility that we not put up artificial restrictions to foreign systems in the U.S. lest other people try to do the same to us. We want to set a good example.”

The post FCC Raises Questions about U.S. Access to Non-GPS GNSS appeared first on Inside GNSS - Global Navigation Satellite Systems Engineering, Policy, and Design.

It is well known that carrier phase ambiguities are integer values. Intuitively, this is hard to understand with a common counter-argument progressing along these lines: even if the receiver measures the instantaneous phase of the incoming signal (thus removing any fractional cycle component at the receiver end), the phase of the signal at the satellite cannot be guaranteed to be zero, so how can the ambiguity be integer?

In this article we explain why the carrier phase ambiguities are indeed integer.

It is well known that carrier phase ambiguities are integer values. Intuitively, this is hard to understand with a common counter-argument progressing along these lines: even if the receiver measures the instantaneous phase of the incoming signal (thus removing any fractional cycle component at the receiver end), the phase of the signal at the satellite cannot be guaranteed to be zero, so how can the ambiguity be integer?

In this article we explain why the carrier phase ambiguities are indeed integer.

To keep things simple, we begin by assuming the propagation errors (ionosphere, troposphere, etc.) and clock errors are zero. This is not limiting but greatly simplifies the analysis and interpretation because it only leaves geometric terms (i.e., range and range rate).

Geometric Interpretation of Carrier Phase
Before getting into too many details, it can be instructive to give a geometrical understanding of the carrier phase.

Recall that carrier phase observations are obtained by integrating the measured Doppler shift of the signal (details in the next section). This is why the term accumulated Doppler range (ADR) is often used to describe the same observation. In the absence of errors, the Doppler shift, f_Doppler, of the received signal is

Equation (1) (see inset photo, above right)

where λ is the carrier phase wavelength and ρ̇ is the geometric range rate between the receiver and satellite (the over-dot represents the time-derivative of the geometric range, ρ).

Integrating the Doppler over time gives the carrier phase observation at time t, ϕ(t), as

Equation (2) (see inset photo, above right)

where t₀ is the start of the integration period (usually when the signal is first acquired), is the change in range over the integration period, and ρ(t₀) is the initial range and represents the integration constant. Equation (2) also shows that the carrier phase observation is a measure of the change in range over time.

Setting t = t₀ in equation gives

Equation (3)

because the change in the range over zero time interval is zero. Of course, the initial range is generally unknown (after all, that is what the receiver is trying to measure) and thus can be loosely interpreted as being ambiguous. This is the geometric analogy to the carrier phase ambiguity.

Carrier Phase Generation
Figure 1 (at the top of this article) shows a high-level diagram of a GNSS receiver-tracking loop. The purpose of the loop is to ultimately have the numerically controlled oscillator (NCO) generate a signal with the same frequency and phase as the incoming signal (after down-conversion). This image is included to help clarify the notation used below.

The Doppler shift of the received signal is given by

f_Doppler = f_dc − f_IF     (4)

where f_dc is the frequency of the signal after down-conversion, and f_IF is the nominal intermediate frequency (IF). The down-converted frequency is given by

f_dc = f_Rx − f_LO    (5)

where f_Rx is the received signal frequency, and f_LO is the frequency of the receiver’s local oscillator (after being mixed up or down from its fundamental frequency).

The IF is given by

f_IF = f_SV − f_LO     (6)

where f_SV is the nominal signal frequency (e.g., 1,575.42 MHz for GPS L1).

Using a frequency lock loop (FLL), the receiver’s NCO tries to generate a frequency, f_NCO, that matches the down-converted frequency as closely as possible. The error (discriminator output), δ f_NCO, is passed to the loop filter that computes the feedback to NCO. The carrier phase equivalent of the equation (4) is

ϕ(t) = ϕ_dc(t) − ϕ_IF(t)    (7)

where the term on the left is the carrier phase observation, ϕ_dc is the phase of the signal after down-conversion in the front-end, and ϕ_IF is the phase of the receiver’s IF signal.

For convenience, we assume that f_IF = 0 such that ϕ_IF is constant. From equation (6), this is equivalent to f_SV = f_LO (ignoring relativistic effects). In this case, and assuming the receiver’s oscillator is phase synchronized with the satellite (recall our initial assumption of perfect clocks), it follows that ϕ_IF = 0.

Let us now consider the signal phase after down-conversion, which is given by

ϕ_dc(t) = ϕ_Rx(t) − ϕ_LO(t)    (8)

where ϕ_Rx is the phase of the signal at the receive antenna (i.e., before down-conversion), and ϕ_LO is the receiver’s locally generated phase. Analogous to the FLL, a phase lock loop (PLL) tries to drive the NCO phase to the down-converted phase.

Accounting for tracking errors, δϕ_NCO, we can write

ϕ_NCO = ϕ_dc + δϕ_NCO        (9)

Since the receiver does not know ϕ_dc, it instead uses ϕ_NCO as its best estimate. In other words, equation (7) can be approximated and then simplified (using equation [9] then [8] and ϕ_IF = 0) as follows:

ϕ(t) ≈ ϕ_NCO(t) − ϕ_IF(t)        (10)
= ϕ_dc(t) + δϕ_NCO(t)
= ϕ_Rx(t) − ϕ_LO(t) + δϕ_NCO(t)
= ϕ_Rx(t) − ϕ_SV(t) + δϕ_NCO(t)

where ϕ_SV is the phase of the satellite (equivalent to the receiver’s phase for the assumptions made). We can break this down further by realizing that the received phase is equal to the phase of the satellite when the signal was transmitted. Knowing that the time of propagation of the signal is T = ρ/c, we can write

Equation (11) (see inset photo, above right)

Substituting equation (11) into (10) gives

Equation (12) (see inset photo, above right)

This shows us that the carrier phase observation under ideal conditions equals the true range plus tracking errors. The latter is zero mean with typical noise and multipath contributing approximately one millimeter and two to three centimeters of error, respectively.

But where’s the carrier phase ambiguity, you ask? To answer this, we need to recognize that the NCO is really only concerned with matching the phase of the local and received signals within one cycle. More specifically, the carrier phase discriminators in the tracking loops (not shown) cannot distinguish between one cycle and another and thus converge to the nearest cycle.

In other words, while the previously described development implicitly assumed ϕNCO = ϕ_dc, in reality

ϕ_NCO = mod(ϕ_dc,1 cycle)        (13)

where mod(a,b) is the modulus (remainder) of a / b. Practically, this means the NCO phase is ambiguous by an integer number of cycles and explains why the ambiguity is integer.

Also worth noting is that the carrier phase ambiguities are determined when the signal is first acquired. After this time, the change in range/phase is captured by integrating the measured Doppler shift. In other words, with reference to equation (2), the integration constant is determined at t₀.

Discussion
Carrier phase measurements can, in theory, be generated using an FLL only. In this case however, the phase tracking error, δϕ_NCO, will not, in general, be zero. This is because the FLL is only concerned with matching the frequency of the received and generated signals. If this is done perfectly, the phase tracking error would be a (generally non-zero) constant. In practice, tracking jitter in the frequency loop causes the phase tracking error to exhibit random walk effects.

Ultimately, the ambiguity term will absorb any mean error in phase tracking error. With a PLL, these errors are zero-mean and thus are not problematic. For an FLL, the non-zero tracking error would be absorbed.

We should also note that the IF phase of the receiver plays a role in the “integer-ness” of the ambiguities. Earlier, we assumed the receiver phase was synchronized with the satellite’s phase; however, this is not true in general, and any offset will be absorbed by the ambiguity term. This error is effectively random at turn-on (due to the random nature of the oscillator’s phase) and thus cannot be easily compensated. This is part of the challenge of ambiguity resolution with precise point positioning (PPP) algorithms. Fortunately, for double difference processing, this effect cancels.

Similar to the IF phase, any unaccounted for delays in the receiver hardware (e.g., inter-channel delays, etc.) will affect the integer-ness of the ambiguities. Fortunately, many of these effects can be calibrated with proper techniques.

Finally, although the previously described development ignored error sources, including these in the development is relatively straightforward and the same conclusion results. The only difference is that equation (12) would include all of the normal error terms and, of course, the ambiguity!

The post Why are carrier phase ambiguities integer? appeared first on Inside GNSS - Global Navigation Satellite Systems Engineering, Policy, and Design.

After some years of concept studies and simulations, the Galileo Commercial Service is taking off. The journey has started toward what can be the most accurate and secure worldwide satellite-based navigation services for civil use.

After some years of concept studies and simulations, the Galileo Commercial Service is taking off. The journey has started toward what can be the most accurate and secure worldwide satellite-based navigation services for civil use.

Employing only GNSS signals, authenticated position fixes accurate to the decimeter level were achieved for the first time in the summer of 2014. Future prospects are for even better results. Although the journey is exciting, many challenges still lay ahead. This article presents the work accomplished thus far on the development of the Commercial Service and the first results of the Authentic and Accurate Location Experimentation with the Commercial Service (AALECS) project with real Galileo signals.

Galileo and the Commercial Service
Since its inception, the Galileo program has experienced several ups and downs, and the Commercial Service (CS) has been no exception. In the late 1990s, the European Union (EU) conceived Galileo and proposed a public-private partnership to share program development costs and risks. At that time, the Commercial Service, named “Control-Access Service 2” or CAS-2, was one of the pillars of Galileo, intended to enable private partners to recover their investment. (CAS-1 is now known as the Public Regulated Service or PRS.)

This approach helped the EU Member States to make the important decision for Europe to develop its own satellite-based navigation system. However, the “added-value” services that Galileo could offer, on top of the ubiquitous, free, and already excellently performing GPS — especially after the removal of that system’s civil accuracy–degrading Selective Availability feature in 2000 — remained unclear.

Perhaps the lack of a clear return on investment ultimately deterred prospective industrial concessionaires from accepting the risk of building Galileo with their own resources. After years of negotiations, the concession-based approach was discarded in the late 2000s, in favor of a fully EU-funded program. At that time, priorities were shifted to those services considered to be more critical for public or governmental uses, such as the PRS, the Open Service (OS), and the Safety-Of-Life (SOL) and Search-And-Rescue (SAR) services.

The evolving Galileo regulation that guided program development still mandated the existence of a commercial service with “improved performance and data with greater added value” than the other services. However, that “added value” was not concretized in any mission or system requirement, and the program budget was already fully allocated to other priorities. Early definition tasks identified high accuracy (HA) and authentication as the two most promising services, but it was not clear if and how the services could be provided, what their performance would be, and how they would be implemented and operated.

The re-profiling of the Galileo SOL in the early 2010s was an important event for the Galileo CS. SOL had been a major factor in defining the Galileo ground infrastructure and signal structure. Its original mission was to provide a worldwide integrity service, satisfying the stringent requirements of aviation communities, among others.

For several reasons, the Galileo program decided to re-profile the SOL into a lighter service, currently being defined, which will provide integrity in likely cooperation with other regions. Therefore, some Galileo features designed to provide the SOL service became available for other purposes. These features include:

• a high data bandwidth compared to other GNSS signals.
• the transmission of data with a latency of few seconds through satellites connected to Galileo ground uplink stations.
• an external real-time input channel initially expected to transmit integrity data from and to other regions in the world.

A Broader Scope
The “post-concessionaire” era has broadened the scope of the CS, and the objective of creating a source of revenue for Galileo in order to partly recover its operation costs has been balanced with other aims, in accordance with the Galileo program’s new status as a public initiative. These aims have been summarized in the following five objectives:

• to maximize the public benefits offered by satellite navigation
• to create economic value, by creating new services, or enlarging the existing ones, with the related increase in economic activity
• to improve Galileo navigation performance
• to promote innovation by enabling new services, ideas and solutions
• and finally, to create a complementary revenue source for the EU satellite navigation programs.

With these objectives in mind, by early 2013, two parallel studies were launched to define the Commercial Service and its implementation in Galileo. The main premise for the studies was to offer the maximum value with the minimum modifications, if any, to the Galileo core infrastructure. This means no or minimal modifications to the Galileo ground infrastructure and the satellite on-board software, and no modifications at all to the satellite hardware, which implies that the current Galileo CS signal definition needs to be maintained.

The Galileo CS Signals
The Commercial Service signals define the capabilities that the Galileo CS will bring. As described in the Galileo OS SIS ICD, the CS signal is composed of a data (E6-B) component and a pilot (E6-C) component transmitted in the E6 band (1260–1300 MHz).

The signals are modulated with a binary phase shift keying BPSK(5) at a carrier frequency of 1278.75 MHz, which is used by all satellites and shared through a code division multiple access (CDMA) RF channel access method. Therefore, the signal main lobe and most of the signal power is in the 1273.75-1283.75 MHz band. Figure 1 (see inset photo, above right) shows the CS and other signals from all satellite-based navigation systems operating in the same band.

Both E6-B and E6-C signals are modulated on the in-phase component, leaving the quadrature component to the E6-A signal, used in conjunction with the E1-A for the Public Regulated Service. Table 1 (see inset photo, above right) summarizes the main properties of the E6-B and E6-C signal components.

A relevant feature of the CS signal is that the primary spreading codes of both components can be either encrypted or in the clear when transmitted. When encrypted, the spreading codes are replaced by an unpredictable bit-stream generated through a secret key, making the signal indistinguishable from noise for unauthorized receivers.

One of the challenges for the Galileo CS is that it will have to share the RF spectrum with other users. The 1240–1300 MHz band is currently used by several applications, and ensuring compatibility with some of them, such as aeronautical and land military radars or the amateur radio community, may require coordination and interference mitigation in the vicinity of these systems’ ground-based transmitters.

In addition to those applications, the E6 band is also used by the space research and satellite-based Earth exploration communities. Early CS tests involving real signals have shown satisfactory performance when no interferers are around but have suffered interference effects in the vicinities of transmitters.

The European Commission (EC) is pursuing actions to facilitate the use of the E6 for satellite-based radionavigation to the widest extent, and discussions with telecom regulators and user communities will continue over the next few years, in parallel with the experimentation of the services that Galileo CS aims to offer: high accuracy and authentication.

High Accuracy
High accuracy is generally understood as a positioning accuracy on the order of a few centimeters. Two primary approaches have been used in the past years to provide high accuracy: real time kinematic (RTK) and precise point positioning (PPP). The main advantage of using PPP instead of RTK is that it provides a global and absolute positioning and timing service without the need for nearby reference stations.

PPP is based on the use of accurate GNSS satellite orbits and clock data to estimate a user position based on carrier phase measurements, where the ionospheric delay is typically removed by performing the iono-free combination. The main disadvantage of PPP is the time needed to converge to a centimeter-level accuracy, which currently takes about 15–30 minutes to achieve, while RTK is almost instantaneous. The most common and optimized technique in terms of bandwidth for real-time PPP is to send orbits and clock corrections to the navigation message, allowing the reconstruction of the accurate values in the receiver.

The Galileo E6-B channel is well suited to transmit PPP information. Various analyses have shown that the available rate of 448 bps per satellite allows the transmission of satellite orbits and clock data at an adequate update rate to provide accuracy at the centimeter level. (See Table 2 (inset photo, above right).)

The data update rate is especially relevant for satellite clock corrections, which are not as stable in the medium and long term as the orbits. In order to obtain the highest accuracy, corrections must be updated every few seconds, especially for the satellites with less stable clocks.

Figure 2, generated for GALCS (“Galileo Commercial Service definition”), one of the two parallel studies mentioned previously, shows the evolution of the 3D position error and the corresponding root mean square (RMS) for a static GNSS receiver after convergence on a position solution. The reference products were computed by means of a network of 50 worldwide GPS and GLONASS stations. The corrections used below 400 bps, which is compatible with the CS.

The panel on the left of Figure 2 shows the PPP positioning error with a 5-second clock update rate, while the panel on the right shows the error with a 30-second clock update rate. The system latency was configured to 5 seconds, understanding latency as the time between when the system processes the satellite measurements and when corrections based on these measurements are transmitted.

Both latency and clock update rates contribute to the age of data of the clock corrections applied at a given time, which have an impact on the PPP accuracy. As the CS allows for the transmission of different bits from different satellites, the total bandwidth can be highly increased leading to a better performance that, when combined with other factors may reduce the PPP receiver convergence time.

Spreading Code Encryption
Due to their low power, GNSS signals can be easily jammed, and because of the lack of authentication, they could also be forged or “spoofed” with the appropriate equipment. Therefore, protecting GNSS has become one of the major topics of interest for GNSS.

In addition to other technical and regulatory measures, features in the GNSS signals allowing authentication are undoubtedly a major building block of location security. GNSS authentication is different from information authentication, as its objective is not only to authenticate the information encoded in the signal but also to authenticate the signal time of arrival, at least against certain threats and with a certain confidence level. Both factors are required for a trustworthy position and time estimation.

With this in mind, Galileo is a good candidate to offer authentication services to civil communities for two main reasons. The first is that Galileo E6-B and E6-C signal spreading codes can be encrypted, which provides spreading code authentication for receivers (or server-receiver architectures) having the encryption keys. Also, the fact that the keys are not used for military purposes implies that they can be shared under certain conditions with certain users, providing additional flexibility. The second reason is that the available bandwidth in both E6-B and E1-B Galileo signals permits the transmission of authentication and re-keying data while guaranteeing full backward-compatibility.

Navigation Message Authentication
As mentioned earlier, the CS objectives go beyond obtaining revenues. In addition to an access-controlled E6-based authentication service, The Galileo program is working to offer an open navigation message authentication (NMA) service. The latter service can use the E1 signal for data transmission through an underlying architecture similar to that for E6-B.

Some work already performed shows that Galileo can achieve very good performance, including the possibility to authenticate the navigation messages of other constellations. (For further discussion of this point, see the article by I. Fernández-Hernández et alia (2014a) listed in the Additional Resource section near the end of this article.)

Putting It All Together
The exact definition and implementation of the HA and authentication services is yet to be finalized and will depend on EU member states’ agreement and the involvement of external providers. Nevertheless, we can already envision the following service bundle:

• a commercial high-accuracy service on the E6-B signal, transmitted unencrypted at spreading code level and whose access is controlled at data level.
• two authentication services — an open authentication service based on Galileo E1-B for applications requiring a medium security level and a commercial authentication service based on encrypted spreading-codes on the E6-C pilot tone, the data authentication on E1-B and some additional E6-B data for spreading code re-keying.

Conceptually, the provision by Galileo of different authentication services (PRS, CS, OS) seems coherent with general security principles, whereby the level of security is commensurate with the criticality of the assets to protect.

Galileo CS Architecture
As said before, the CS is designed to be as respectful as possible of the current Galileo core system infrastructure. To achieve this, CS will be provided through an external interface already built into the core system. This scheme, once accredited, will offer a high flexibility and fit very well with the premise that Galileo is eminently a civil system for civil purposes.

Figure 3 shows the CS data transmission process, which consists of the following steps:

• The data is generated by an external source, for example, a high accuracy service provider with its own network of monitor stations. These data are formatted and transmitted to the European GNSS Service Center (GSC), located in Torrejón de Ardoz, Spain.
• The GSC ensures the integrity and authenticity of the data, and after the required security verifications it relays data to the operational Galileo Ground Control Center (GCC) in Oberpfaffenhofen (Germany) or Fucino (Italy). 
• The GCC incorporates the CS data into the messages that contain all other mission and navigation data and sends them to the five up-link stations (ULS) located at Papeete (French Polynesia), Kourou (French Guyana), Svalbard (Norway), Reunion (France) and Noumea (New Caledonia, France), for the transmission to the satellites.
• At each ULS site, uplink antennas pointing at Galileo satellites transmit the data. Currently two antennas per site are available, but more may be deployed soon. Only the satellites pointed by a ULS antenna can transmit real-time data; so, the uplink connections are also one of the drivers of the CS performance.
• Each ground-connected satellite receives its own 448-bit data page and incorporates it into the E6-B data structure. Users and ground monitor stations worldwide receive the signals with the CS data, closing the loop.

This scheme not only allows transmission of CS data in the E6-B but also transmission of data in the E1 I/NAV “Reserved 1” field as per the OS SIS ICD.

The AALECS Project: Three Steps Ahead
The CS definition work started ramping up in mid-2012, but by the end of 2013 it still was based on concept studies and simulations. In January 2014, the EC Directorate-General for Enterprise and Industry (DG ENTR), in charge of the definition and management of the CS, launched the Authentic and Accurate Location Experimentation with the Commercial Service (AALECS) project, with the aim of experimenting with the real architecture and satellite signals.

The project, carried out by a consortium composed of GMV, CGI, Qascom, IfEN, KUL, and Veripos, will run until 2016 and is composed of three phases. Firstly, it has developed an early proof-of-concept (EPOC) platform for initial testing, the results of which will be reported later in this article. Secondly, the AALECS project is developing a distributed platform across Europe to transmit and receive real-time CS data through the Galileo satellites. The platform is composed by four receivers located in UK, Italy, Germany and Spain, as well as two core platforms in Spain and Italy, as shown in Figure 4.

In addition, the platform will integrate EC Joint Research Center’s simulation capabilities. Finally, in its last phase, AALECS will support potential external providers to test their applications and solutions with Galileo.

The EPOC: AALECS’s First Step
During the summer of 2014 the EPOC tested the E6 external data transmission. Given the unique opportunity to use the real CS signals and the flexibility provided by the platform, the European Com-mission and the AALECS team agreed to make the tests as realistic as possible within the limits of the architecture. This included the generation of high-accuracy satellite orbit and clock predictions and data authentication, both with and without the spreading code signals encrypted. The EPOC experimentation activities with real signals in space started in July and finished in late September, although an extension of the testing is under discussion.

As shown in Figure 5, the EPOC platform is composed of three independent hardware and software items: the CS Receiver, the receiver platform (RXP) host and the EPOC-host. The CS receiver is a modified multi-frequency commercial receiver capable of performing E6 ranging with and without spreading code encryption (SCE) and can decode data from the E6-B channel.

The RXP-host commands the CS receiver and includes the authentication and position/velocity/time (PVT) software modules that process the received CS data together with the observations gathered from Galileo and GPS satellites. The EPOC-host generates the authenticated high-accuracy data to be broadcast in the E6 signal. It also includes the historical archive, where the generated and received data is stored, and a software tool that analyzes the received data.

Each EPOC test consists of the following steps:

• A commercial, off-the-shelf software product — consisting of a set of software tools that supports a wide variety GNSS performance and accuracy analyses — generates satellite orbit and clock predictions for the desired testing period. (See “Manufacturers “section near the end of this article for more details. Note that the AALECS project does not finance or call for the development or adaptation of any high accuracy technologies.)
• Based on the software tool set’s predictions, the EPOC generates CS data files in the E6-B message structure format and sends them to the GCC operator.
• The GCC operator performs the required “sanitization” activities to insure that the files are correct and their incorporation into the navigation message does not pose a risk to the system. The CS data is uploaded to the satellites via an uplink station and injected into the signals; then the Galileo satellites start broadcasting the E6-B data.
• During the periods of transmission, the EPOC collects the data in the receiver. Then, in post-processing, it obtains the transmission metrics, the authentication solution, and the PVT solution, producing a comprehensive report with the most relevant information.

In addition to the foregoing, for tests with SCE enabled, the EPOC operator needs to install the NAVSEC key (i.e., the key used to encrypt the E6-B/C components) in the receiver, to enable decryption of the spreading code.

Generating High Accuracy and Authentication Data
Figure 6 shows the format of the HA and authentication data transmitted in the EPOC tests. The HA data generated by the software tool set is formatted in 160-bit messages, each of which contains the predicted XYZ position and clock bias of a given satellite at a given epoch. These 160-bit messages are authenticated and packed together to fit in the 448 bps available in the E6 pages.

The current format allows for 8 HA sections every 5 seconds, for a total of 48 HA sections every 30 seconds. All Galileo satellites synchronously transmit the same 30-second sequence of authenticated HA data for 32 GPS + 3 Galileo satellites. The remaining HA sections are left empty.

Data obtained from the International GNSS Service (IGS) Multi-GNSS Experiment (MGEX) station network feeds the software tool set in order to generate the satellite ephemerides and clock products. One of the major limitations of the EPOC compared with a future operational CS is the data latency: Satellite orbit and clock predictions had to be generated and transmitted to the Galileo operator about two days in advance of the planned test; therefore, the age of the predicted products — and associated decorrelation of real-time and predicted data — limited EPOC’s achievable PVT performance.

The authentication solution used for the EPOC is an adaptation of the Timed-Efficient Stream Loss-tolerant Authentication (TESLA) algorithm described in the article by A. Perrig et alia listed in the Additional Resources section near the end of this article. TESLA seems more bandwidth-efficient compared to other solutions, such as standard digital signatures.

The proposed TESLA implementation is based on a single one-way chain of 256-bit keys for data authentication. An initial random seed key (K_n) generates this chain by performing a given number of hashes using the SHA-256 algorithm. The key-chain is generated from K_n to K₀, but keys are disclosed to the user from K₀ (certified as correct through non-SIS means in this implementation) to K_n, as shown in Figure 7.

This approach enables the user to recover an old key from a recently disclosed one, while insuring that future keys cannot be inferred from disclosed ones. As shown in Figure 6, out of five seconds of the data message, four are devoted to authenticated HA data and one to the authentication key, plus a bit pattern to differentiate key pages from HA pages, and a message authentication code (MAC) of the preceding HA packet (HAP) authenticated with a key delivered 30 seconds later. This MAC is intended to resist data spoofing attacks to receivers with very inaccurate clocks using already disclosed keys, and is called “Long Term Authentication” by the EPOC developers (as opposed to “Short Term Authentication,” which refers to all other cases).

The keys are used to authenticate the HA 160-bit data through a hash-based MAC (HMAC) function truncated to 64 bits. The receiver can then verify the authenticity of the HA data by comparing the MAC generated from the HA data and the later disclosed key, with the previously received MAC.

In the Additional Resources section, further details on the authentication solution implemented in the EPOC can be found in the article by D. Calle et alia, and additional details about TESLA-based implementations for satellite-based navigation in the articles by C. Wullems et alia, S. Lo and P. Enge, and J. T. Curran et alia.

We must emphasize that this message structure and data definition have been implemented for testing purposes only and are not bandwidth-optimized, neither for high accuracy nor for authentication. We must also highlight the fact that future HA and authentication services are expected to be provided separately, although they may be combined in the receiver.

EPOC Testing
The EPOC Signal-In-Space (SIS) test campaign had two main objectives. The first was to check that the Galileo system and signals were capable of delivering the future CS. This implies testing the E6-B data transmission, including synchronization aspects, the satellite uplink process, potential data glitches or duplications, spreading code encryption and decryption, and correct signal transmission in terms of power and modulation. The second objective was to evaluate the potential of Galileo-based high accuracy and authentication applications, including open sky/urban and static/dynamic use cases.

Test slots were predicted that would guarantee the best visibility of the three available Galileo in-orbit validation (IOV) satellites over GMV’s premises in Madrid. Based on these predictions and other operational constraints, six-hour slots were allocated to the EPOC SIS tests on a weekly basis.

The test campaign began on June 12 and finished on September 30, 2014, with the following main outcomes:

• A total of 18 tests were executed: 4 “dry runs” involving no data transmission, 10 static/open-sky tests, and 4 dynamic tests in open-sky and urban conditions.
• Out of the 10 static tests, E6-B/C spreading code encryption was activated for 3 of them, between July 15 and 25. These were reflected in Notice Advisories to Galileo Users (NAGUs). The signals were transmitted in the clear the rest of the time.
• More than 83 hours of generated, transmitted, and received E6 data from the available IOV satellites were recorded. 
• A GPS L1/L2 + Galileo E1/E5 PPP solution based on E6-B corrections was implemented. As satellite E20 was not available, Galileo-only PVT could not be calculated.

The following sections describe the results obtained in terms of data transmission, authentication, and high accuracy. We will analyze the test performed on July 22 in detail as it illustrates the results obtained under nominal conditions in most of the other tests.

Data Transmission Results
Figure 8 shows the tracking profile for satellites E11, E12, and E19 for the July 22 test, which was performed with SCE activated. The figure shows that dummy messages (broadcast when no data is uplinked) were transmitted due to a scheduled uplink station handover for E12 and E19 at around 19:40 UTC. A similar event is observed for E19 around 23:15 UTC. Two repeated-or-missing messages of two seconds each occurred for E19 between 21:30 UTC and 22:00 UTC. This is due to the current data uplink process, which is based on data files of some minutes’ duration and will be replaced in future Galileo ver-sions by a continuous data stream.

As expected, some tracking losses were observed at the end of the satellite pass, principally when satellites were at a 5/7-degree elevation. A few other tracking losses were observed due to receiver or environmental issues, but overall the page-loss ratio was below 0.5 percent.

Other tests confirmed this good data transmission performance and also showed that SCE and decryption at the receiver are correctly implemented.

These results demonstrate that a seamless synchronization was achieved during almost all of the several hours of tests. This feature is very important not only for the HA data transmission but also for the TESLA-based authentication requirements, which require fully synchronized messages. In summary, the field testing has demonstrated the correct transmission of external data through the E6 signal. Given that the Galileo system is still under deployment and the performance is expected to improve, we consider the data transmission results to be very good.

Authentication Results
Before presenting the results, we can characterize the authentication performance theoretically in terms of authentication error rate (AER), time between authentications (TBA) and time to first authenticated fix (TTFAF) as described in the article by I. Fernández Hernández et alia (2014a).

TBA is five seconds without SCE and zero seconds with SCE, as the receiver can navigate with previously authenticated data and continuously re-authenticated spreading codes. TTFAF is around 30 seconds (the time to receive from E6 all the HA data, excluding the time for a PPP algorithm to converge and the potential need to extrapolate from two XYZ given satellite datasets). As regards AER, it is calculated as follows:

AER + 1 − (1 − BER)^NNA      [1]

where BER is the bit error rate, calculated according to the method described in the book by E. Kaplan and C. Hegarty (see Additional Resources), and NNA is the number of bits for navigation and authentication, which for a given authentication verification are 480 bits (160 + 64 + 256), as per Figure 6. Figure 9 characterizes AER versus the carrier-to-noise power spectral density ratio (C/N₀) analytically for an additive white Gaussian noise (AWGN) channel.

By way of example, Figure 10 shows the actual (short-term) AER versus C/N₀ results from the July 22 test for E11, E12, and E19. AER was measured every 30 seconds, i.e., it was the percentage of failed data authentications per satellite every 30 seconds out of the total expected authentications. Some spikes observed for E12 and E19 at around 19:40 UTC are related to the previously mentioned uplink transition.

Some smaller spikes observed for E19 between 21:30 UTC and 22:00 UTC are related to the aforementioned data file de-synchronization. This latter event affected TESLA synchronization leading to failed authentications. All other AER spikes are related to C/N₀ drops. The figures show that, at a C/N₀ below 40 dBHz, AER starts to increase. Further analyses are ongoing to understand the discrepancy with respect to the theoretical values, and C/N₀ higher than expected, which seem due to a C/N₀ overestimation in the receiver.

All in all, these valuable results show how asymmetric authentication can work in a real satellite navigation system. They also confirm the feasibility of data authentication through Galileo, which can be extremely valuable in thinking of future data-based and even spreading-code–based open authentication services for future Galileo generations. One could, for example, foresee a scheme whereby spreading codes are water-marked with a TESLA key and transmitted some time before the key is disclosed.

High Accuracy Results
This section presents some data-authenticated high accuracy results. As only three Galileo satellites were available during the tests, positioning was calculated using signals from GPS as well as Galileo. Figure 11 shows the 3D accuracy obtained in a July 22 static open-sky test with data-authenticated corrections sent by Galileo satellites E11, E12, and E19 through E6-B. HA data was transmitted 48 hours after its generation by the software tool set.

The performances are remarkably good given the age of corrections and show accuracies on the order of decimeters. So, the CS performance appears promising, especially taking into account that the target data latency for Galileo is on the order of seconds rather than days.

Figure 12 shows the authenticated high-accuracy performance on September 17 during a kinematic test, including open-sky and deep urban environments, as well as around GMV’s premises in Tres Cantos, Madrid. Figure 13 shows the trajectory followed.

For this test, HA data was transmitted 15 hours after its generation. The solution remains stable after the convergence period (due to good modeling of satellite clock behavior) and is only destabilized when the environmental conditions go beyond a certain level of severity. The first signs of instability are seen at 16:25 UTC, and then the position solution is definitely destabilized by 16:35 UTC.

Although the accuracy results are not as good as in other cases, due to a higher error in the clock predictions for this particular test, they are still very good and — to the knowledge of the authors — better than the accuracy provided to date by the navigation message of any global navigation system. (Note that the user error includes not only the orbital and clock error but also propagation and receiver effects.) We should also point out that, even under harsh urban conditions, the AER of E12, the only satellite visible, remained very low, leading to almost no degradation of the authenticated versus non-authenticated performance, as shown in Figure 14.

These results, we conclude, demonstrate the feasibility of obtaining high accuracy from the Galileo Commercial Service, even with the substantial latency imposed by the test design. When this latency is reduced, we expect the achievable performance can be much higher — down to the centimeter-level error of state-of-the-art, high-accuracy services.

Conclusions and Next Steps
This article has presented the Galileo Commercial Service as it stands now, including its brief history, its signals, its anticipated services, architecture, and early field testing.

Galileo, through the Commercial Service, presents relevant differentiators with respect to other systems, such as an external data transmission channel and spreading code–encrypted signals for purely civil purposes. These capabilities, even if limited for the time being, have demonstrated accurate positioning and authentication, as shown in detail for the first time in this article. The test results are remarkable, considering that an accuracy at the decimeter level has been achieved by a standalone receiver with two-day-old orbit and clock predictions. Further, data and code authentication schemes over civil GNSS signals have been tested for the first time, to the knowledge of the authors.

In the years to come, Galileo has a great opportunity to deliver highly accurate and robust services worldwide. In spite of the many challenges ahead, the authors believe that the Galileo program will be capable of turning the test results of today into the operational services of tomorrow for the benefit of industries and citizens.

Acknowledgments
The authors would like to thank the people that made possible the transmission of the E6-B signal-in-space data, principally Spaceopal and ESA teams, all of the people involved in the AALECS project, and GSA Communications Department.

Additional Resources
[1] Calle, D., and E. Carbonell, I. Rodriguez, G. Tobias, E. Göhler, O. Pozzobon, M. Canale, and I. Fernández Hernández, “Galileo Commercial Service from the Early Definition to the Early Proof-Of-Concept,” Proceedings of the ION GNSS 2014+, Tampa, Florida USA
[2] Curran, J.T., and M. Paonni and J. Bishop, “Securing the Open-Service: A Candidate Navigation Message Authentication Scheme for Galileo E1 OS,” Proceedings of ENC 2014, European Navigation Conference, Rotterdam, Netherlands
[3] European Union, European GNSS (Galileo) Open Service Signal In Space Interface Control Document, 2010
[4] European GNSS Service Center, Notice Advisories to Galileo Users
[5] European Union, “Regulation (EU) No 1285/2013 of the European Parliament and of the Council,” Brussels: Official Journal of the European Union, 2013
[6] Fernández-Hernández, I. (2014a), and V. Rijmen, G. Seco-Granados, J. Simón, I. Rodríguez, J. David Calle, “Design Drivers, Solutions and Robustness Assessment of Navigation Message Authentication for the Galileo Open Service,” Proceedings of the ION GNSS 2014+, Tampa. Florida USA
[7] Fernández Hernández, I., (2014b) and J. Simón, R. Blasi, C. Payne, T. Miquel, and J. P. Boyero, J. P. (2014). “The Galileo Commercial Service: Current Status and Prospects,” Coordinates, July 2014, pp. 18–25
[8] Kaplan, E., and C. Hegarty, Understanding GPS: Principles and Applications, 2nd Edition, Artech House, 2005
[9] Lo, S., and P. Enge, “Authenticating Aviation Augmentation System Broadcasts,” IEEE/ION Position Location and Navigation Symposium (PLANS), Indian Wells, California USA, 2010
[10] National Telecommunications and Information Administration, U.S. Department of Commerce, “1240-1300 MHz,” NTIA Publications, 2014
[11] Parkinson, B., “Assured PNT – What actions can/should be taken to reduce vulnerability and ensure PNT availability?” Proceedings of ENC 2014, European Navigation Conference, Rotterdam, Netherlands
[12] Perrig, A., and R. Canetti, J. D. Tygar, and D. Song, “The TESLA Broadcast Authentication Protocol,” CryptoBytes, 5:2, Summer/Fall 2002, pp. 2-13
[13] Pozzobon, O., and C. Sarto, A. Pozzobon, D. Dötterböck, B. Eissfeller, E. Pérez, D. Abia , “Open GNSS Signal Authentication Based on the Galileo Commercial Service (CS),” Proceedings of the 26th ION GNSS+ 2013, September 16–20, 2013, Nashville, Tennessee USA
[14] Wullems, C., and O. Pozzobon and K. Kubik, “Signal Authentication and Integrity Schemes for Next Generation Global Navigation Satellite Systems,” in Proceedings of the 2005 European Navigation Conference GNSS, Munich, Germany

The post Galileo’s Commercial Service appeared first on Inside GNSS - Global Navigation Satellite Systems Engineering, Policy, and Design.

Investment in and implementation of EGNOS, the European Geostationary Navigation Overlay Service, on Ukrainian territory is the subject of discussions on the international level. In November 2013, the European Commission Ukraine signed a cooperation agreement declaring both sides’ intention to include the Ukrainian territory in the coverage of EGNOS (the European Geostationary Overlay Service). A satellite-based augmentation system (SBAS) providing integrity messages and improved positioning accuracy, EGNOS represents a considerable step in implementation of satellite-based services as primary navigation systems for aircraft.

Starting from October 1, 2009, the EGNOS Open Service has provided signal transmission on EGNOS-capable satellite navigation receivers. The EGNOS safety-of-life service became available on March 2, 2011. Space-based signals are typically used for safety-critical operations over the territory of western Europe.

Possible methods and steps of implementation, potential benefits for Ukrainian users, and other important issues were discussed at an two EGNOS workshops held in Kiev and were an essential part of the Fifth World Congress on Aviation in the XXI-st Century, with the theme “Safety in Aviation and Space Technology,” held in Kiev in 2012.

The goal of the experimental work described in this article is the estimation of the quality of EGNOS system performance in Ukraine (in the Kiev area, particularly) after the system was declared available.

Introduction of EGNOS in Ukraine will benefit not only the aviation sphere, which is an important part of our national development, but also could be used for monitoring ground traffic, creating efficient agriculture solutions, free and accurate mapping, various maritime uses, and other location-based services.

As our primary concern is aeronavigation, the key benefits of EGNOS for GNSS users are:

• improvement of the accuracy of receiver location to about one meter
• integrity data that validates the signals transmitted by GNSS satellites along with alerts in near–real time
• accurate and reliable synchronization with coordinated universal time (UTC).

The measurement facilities of the EGNOS ground segment are known as RIMSs (ranging and integrity monitoring stations), which send raw data streams to the central processing facilities of the EGNOS Mission Control Center.

The active RIMSs nearest to Ukraine are located in Warsaw (Poland), Sofia (Bulgaria) and Golbasi (Turkey).

Setting the Goal of the Research
Our experimental research consists of receiving GPS data and corrections transmitted over geostationary satellites used by EGNOS. We processed the experimental data using PEGASUS software (Prototype EGNOS and GBAS Analysis System Using SAPPHIRE) developed by the GNSS Tools Team at the Eurocontrol Experimental Center. Based on the results, we will draw conclusions at to whether the characteristics of the navigational system fit the safety requirements of aviation users in the Ukraine region.

The receiving station is located on the roof of the eleventh wing of National Aviation University (NAU). The coordinates of the receiving station were surveyed to five-centimeter accuracy and are considered as the primary reference point for our investigations.

Figure 1 (see inset photo, above right, for all figures and tables) shows a screenshot of the monitor at our receiving station. On the screen, one can see the location and status of GPS and Galileo satellites, as well as two Inmarsat geostationary (GEO) satellites that have EGNOS transponders on board, which transmit messages with corrections.

The GEO satellites, which transmit the messages with EGNOS corrections, appear as hexagonal icons in the left-hand panel of the screenshot and are identified by their pseudorandom noise code (PRN) numbers 120 (Inmarsat 3F2 AOR) and 126 (Inmarsat 3F2 IND-W). GLONASS satellites also appear in the figure, but the EGNOS system does not use these and, therefore, they are not considered as the part of the experiment.

The primary focus of our research was on the following characteristics:

• accuracy ( in terms of deviation of coordinates in horizontal and vertical planes from the coordinates of the reference station and numerical values in meters);
• availability of ionospheric corrections (considering the ionospheric pierce points of satellite signals, presented as a graph)
• integrity information (summarized in the form of horizontal and vertical “Stanford” diagrams)
• continuity of data (given in the form of tables of discontinuities found)
• overall availability of service — measured as the availability of signals meeting the requirements for instrumented approaches with vertical guidance (APV) APV-1, APV-2, and Category 1 (CAT-1) precision approaches to runways. Our experiments began in 2008, even before EGNOS’s official launch, and ran up to 2014.

Research Results
In this article, we will use the results of research conducted on November 24, 2014, to provide an example of our experimental program’s findings.

Figure 2 depicts the accuracy achieved in the horizontal plane displayed as north-south and east-west deviations from the primary reference point. It is calculated as the difference between measured position and the actual coordinates of the receiving station. Data come from static receiver tests and were collected at the NAU during a period lasting 5 hours and 14 minutes, with 18,475 out of 18,846 received epochs considered valid EGNOS solutions.

Figure 3 depicts a map of the availability of ionospheric pierce points (IPPs). Availability indicates how many satellites that use the given IPP received ionospheric corrections from a EGNOS geostationary satellite. Only those satellites that received ionospheric corrections should be used in an EGNOS solution. Because some of the GNSS satellites visible from our antenna don’t receive EGNOS corrections they cannot be used in an EGNOS solution.

The coordinates of Kiev are 30° 30’ E 50° 27’ N. Availability of IPPs in this area was approximately 50 percent. Availability of pierce points was 90–100 percent for satellites to the west, decreasing somewhat to the south and north, and falling rapidly to 40–50 percent for satellites to the east.

Definitions of measured accuracy, scaled accuracy, integrity, integrity event, misleading information are taken from the efforts of a EUROCONTROL Airspace and Navigation Team, APV Working Group, and are specifically used in the PEGASUS software. (See the Additional Resources section near the end of this article for a complete citation of this document.)

Integrity is a measure of the trust that can be placed in the correctness of the information supplied by the total system and includes the ability of a system to provide timely and valid warnings to the user (alerts) when the system must not be used for the intended operation (or phase of flight).

EGNOS broadcasts an integrity signal giving users the capability of calculating a confidence interval, alerting them when a GPS satellite malfunctions and is not to be used for a safety-of-life application. The data produced and transmitted by EGNOS thus include estimates of GPS satellite orbit and clock errors and estimates of errors due to GPS signals passing through the ionosphere. The alert limit (AL) is a fixed threshold corresponding to a type of operation.

The mechanism to trigger an integrity alert compares, for each epoch, a (conservative) estimate of the position accuracy in relation to the alert limit. This estimate, called the protection level (PL), is computed based on quality estimates provided by the SBAS system and tropospheric, ionospheric, and SARPS variance models embedded in the receiver software. The PL provides an indication of error uncertainty modeled by the variance of a zero-mean normal distribution that describes user differential range errors, user ionospheric range error, aircraft pseudorange errors due to multipath, and residual pseudorange errors from a tropospheric model.

An integrity event is an epoch in which the position error (PE) exceeds a maximum allowable alert limit, while no alert is generated within an allowable time period, called the Time to Alert (TTA).

A misleading information (MI) event is considered as every epoch in which PE is greater than the PL, which can be regarded as reflecting a system anomaly. Hazardously misleading information (HMI) is defined as every epoch where the position error is greater than the alert limit and the protection level, which represents an anomaly and can be hazardous for users. HMI thus means that the epoch is actually unavailable but would have been labeled as a valid one in flight. (Note that ALs can differ for various types of users/operations.) In HMI situations the actual position error is greater than the alert limit (PE>AL) and the alert limit is larger than the protection level (AL>PL) but the epoch still passed as valid for this operation because the protection level was estimated incorrectly.

A near-MI event is defined as every epoch where PE/PL > 0.75.

During flight only the protection level can be calculated, as an aircraft’s true position is unknown, therefore we cannot calculate position errors.

In PEGASUS, accuracy is divided into measured and scaled. Measured accuracy is defined as a 95 percentile of the error distribution of all the valid samples within the assessed period. Scaled accuracy is defined as 95 percentile of the error distribution of all the valid samples scaled with an alert limit (XAL)/protection level (XPL) ratio. Here, X means a horizontal or vertical plane, the alert limit is defined by the specific flight operation, and the protection level is defined for each sample.

The calculation of scaled accuracy can be represented as

(See Equation, above right)

where i is the number of samples, AL is defined for each kind of operation by ICAO, and PL is based on estimates made for a current epoch.

Data is scaled to the worst-case geometry in order to eliminate the variability in system accuracy that is caused by the geometry of the orbiting satellites. Theoretically the error statistics should only be based on the samples during which the service level was available, that is, the horizontal and vertical protection levels must be less than the horizontal and vertical alert limits (HPL<HAL and VPL<VAL). This will result in a different number of samples for each type of procedure, as the alert limit will differ for each type of procedure.

Our experiment results showed that the horizontal measured accuracy at NAU in the APV-1 category is 3.32 meters and the vertical measured accuracy is 1.73 meters. The horizontal measured accuracy results for APV-2 category is 2.82 meters and the vertical measured accuracy is 1.62 meters.

The scaled accuracy for APV-1 is equal to 8.35 meters and 5.28 meters for horizontal and vertical planes, respectively, and the scaled accuracy for APV-2 equals 8.86 meters and 2.18 meters, respectively. These results were well inside the accuracy requirements for meeting International Civil Aviation Organization (ICAO) standards and recommended practices (SARPs) for integrity operations aircraft approach and landing operations as given in Table 1.

To summarize the integrity information generated by our research, we used the format developed by Stanford University to characterize performance of the U.S. Wide Area Augmentation System (WAAS). The measurements that correspond to typical operations of APV-1, APV-2, and CAT-1 for horizontal and vertical planes are shown on Figure 4 and Figure 5. On the horizontal axes, precision errors are plotted for horizontal (hpe) and vertical (vpe) planes; on the vertical axes we have alarm limits for horizontal (hpl) and vertical planes (vpl), respectfully.

The color scale allows us to calculate the number of points (therefore the number of epochs) that meet — or, conversely, fail to meet — the required performance for various approach and landing procedures. All epochs that meet a stricter standard will satisfy a lower standard. For example, all epochs that meet APV-2 requirements will satisfy APV-1, too.

For 18,475 valid epochs in the horizontal plane (Figure 4), all of them were fit for safety-critical operations. From 18,475 valid epochs on the vertical plane (Figure 5) 8,159 epochs met only APV-1 requirements, 10,289 met those for APV-2, and 27 epochs satisfied CAT-1. Such figures can only be built based on observations made on the ground, as we have no position errors information during the flight.

There were no integrity concerns and therefore we may conclude that EGNOS is safe to use from the integrity point.

The most problematic parameter for Ukraine is continuity of service, which in turn affects the availability and reliability of service. Continuity of service refers to the capability of the navigation system to provide a navigation output within the required integrity parameters during a given period.

In practical terms, a continuity event occurs either due to the inability of a receiver to output a position solution or because the system generates an alert not to use the provided position solution. This alert is normally generated based on the vertical or horizontal protection level (XPL) exceeding a corresponding predefined alert limit (XAL).

In our experimental tests, no discontinuity of service events occurred for position solutions and APV-1. Table 2 lists the discontinuity events for APV-2.

The service availability of an SBAS system is defined as the ratio of the number of samples that are available for a given operation to the total number of valid samples.

In this research we have received 100 percent availability for APV-1 category but only 55.838 percent availability for APV-2, with negligible availability for CAT-1, 0.146 percent. These are extremely good results compared to previous years and indicate improvement of EGNOS from approximately 40 percent availability for APV-1 in 2009, 70 percent availability in 2011, and 80 percent availability in 2013. As we are primarily interested in APV-1 results, the positive changes are evident.

Conclusions
Even with the absence of a RIMS station on the territory of Ukraine, the reliability and effectiveness of EGNOS has significantly changed over the years. Nevertheless, the good availability of positioning for the APV-1 category does not guarantee EGNOS use on the territory of Ukraine. Without proper equipment and infrastructure, EGNOS is unavailable for safety-critical operations. Still it is available for other non-critical applications such as agriculture or mapping.

Additional Resources
[1] CNES (French Space Agency)/European Space Agency/European Commission, User Guide for EGNOS Application Developers, Ed 1.1, 2009
[2] EUROCONTROL, PEGASUS Interface Control Document, 2010
[3] EUROCONTROL Airspace and Navigation Team, APV Working Group/EGNOS SIS Validation Sub Group, “First Glance Algorithm Description,” October 13, 2005]
[4] Hansen, A. J., “WAAS Precision Approach Metrics: Accuracy, Integrity, Continuity and Availability,” 1997. Available from Stanford University website
[5] International Civil Aviation Organization, Aeronautical Telecommunications Annex 10 to the Convention on International Civil Aviation, Volume I (Radio Navigation Aids)
[6] International Civil Aviation Organization, Global Navigation Satellite System (GNSS) Manual 2005
[7] European GNSS Agency, “EGNOS Service Definition Document – Safety of Life (SOL SDD),” Rev. 2.1 19/12/2014. Available from EGNOS Portal website

The post Extending the Reach of SBAS appeared first on Inside GNSS - Global Navigation Satellite Systems Engineering, Policy, and Design.

SIDEBAR: Frank van Diggelen’s Compass Points

“It all traces back to my parents,” says Frank van Diggelen. “My father, Tromp van Diggelen, was a surfer. He taught me to surf and swim, in that order, when I was five. I was racing sailboats before I was 10, and there’s a lot of navigation there. Even when you’re just on a lake, the racing is all about reading the wind, understanding angles of convergence, velocity-made-good, and so on.”

SIDEBAR: Frank van Diggelen’s Compass Points

“It all traces back to my parents,” says Frank van Diggelen. “My father, Tromp van Diggelen, was a surfer. He taught me to surf and swim, in that order, when I was five. I was racing sailboats before I was 10, and there’s a lot of navigation there. Even when you’re just on a lake, the racing is all about reading the wind, understanding angles of convergence, velocity-made-good, and so on.”

And then there was his mother, Judith, who sparked Frank’s early interest in engineering by buying him ever-more complex “Meccano” sets — similar to Legos “but much more mechanical: all metal, with actual nuts and bolts, gears, and electric motors. We used to spend many hours making elaborate machines, like little electric cars and motorcycles.”

Now an American citizen, van Diggelen is South African by birth.

“I grew up in an incredibly segregated society,” he recalls, referring to the South African government’s policy of apartheid that ended  in1994 after nearly 50 years. “Everything was segregated — where you could live, what schools you could go to, and what cinemas, restaurants, beaches, buses, taxis, everything.”

One of his first memories of South Africa is an incident that occurred when he was four years old. “My mother was taking my sister and me out somewhere. We were waiting to catch a bus by a black sign with white lettering ‘Bus Stop.’ After a while, a bus stopped and the driver told us to go and look for a different bus stop, with a white sign and black letters,” indicating its designation for whites only.

“As a child you just accepted that that’s how things were,” van Diggelen says. “It wasn’t until I was in college that I really understood what was going on.”

His parents, Tromp and Judith, believed strongly in a good education for their children and always made sure that little Frank and his siblings, a brother and a sister, went to the best schools the family could afford.

“This required some creativity,” van Diggelen says, “since we had very little money, and my dad changed jobs and moved us to different towns frequently.”

Thus, at ages four to five, he found himself in a Jewish religious school, and, from 11–15, at a Catholic boarding school, with some regular government schools in between. “I think the belief in good education stuck,“ he says.

Today, satellite navigation, a natural extension of his early waterborne interests, has impressed itself into every facet of his life.

“There is no boundary between my work and non-work life,” he says. “I love what I do and do what I love. So, whether I’m sitting in the office, or running in the hills, or racing a sailboat, I’m working on or with GNSS, usually testing something new, and trying to figure out how to make it better.”

In the Navy
As an 18-year-old midshipman in the South African Navy, van Diggelen was responsible for maintaining and operating the navigation systems aboard a minesweeper, including the U.S. Navy’s TRANSIT system, the world’s first operational GNSS.

He considers that assignment at sea to be doubly fortunate. In addition to learning satellite navigation skills, his tour of duty took him away from the “border war” with Angola and Namibian guerrillas fighting to liberate South West Africa from South African control.

“I joined the military because all white men were conscripted back then,” he says. In the 1980s, South Africa had continued to occupy the Namibian region that it had administered under a League of Nations mandate which had been revoked by the United Nations in 1966.

Most South African conscripts drew infantry posts and the border war.

“Many of my friends were there at the border while I was being taught navigation,” he says. “So, this may have been the luckiest thing that ever happened to me. I think it was because I was school swimming captain that I got into the Navy.”

Again, he had another reason to thank his father for those early swimming lessons.

“Anyway, only two percent of the conscripts got into the Navy, and two percent of those got into officer’s school,” van Diggelen says. “For me it was like winning the lottery.”

The ‘Real’ Cambridge
After his stint in the Navy, van Diggelen went back to school, earning a bachelor’s degree at the University of the Witwatersrand, South Africa, and a Ph.D. in electrical engineering from Cambridge University in England, both on full academic scholarship.

Of course, going off to college would have been a bit boring if it had only been about getting an education. However, in addition to classes, he met his wife Alison at Cambridge University, where she was also a student. “Alison is from Scotland. We like to tease people by saying we met ‘half-way’ between South Africa and Scotland,” van Diggelen says. “Anyone who knows Scotland, England, and South Africa gets it.”

More serious matters were not far ahead. Van Diggelen was in the throes of writing up his Ph.D. thesis when another Alison – Alison Brown, CEO and founder of NAVSYS Corporation — visited his supervisor, Professor Keith Glover, who had been her professor when she was at Cambridge.

“He knew I was looking for a job,” says van Diggelen. “So, he called me and I had an ‘insta-interview’ with Alison [Brown]. I hadn’t shaved or changed clothes, and had hardly slept, for three days — I must have looked like the ideal candidate! Next thing I knew I was working in Colorado Springs, and I’ve never looked back.”

Meeting Up with GPS
Van Diggelen began working on GPS in 1992, with Brown and company at NAVSYS in Colorado. There, he helped design a receiver autonomous integrity monitoring (RAIM) system for the U.S. Coast Guard. The result was an operational system for verifying the integrity of the differential GPS location of aids to navigation, mostly buoys, on U.S. marine charts. The system was still in use over a decade later.

After NAVSYS, van Diggelen worked on GPS, GLONASS, and assisted GPS (A-GPS) for Ashtech, Magellan, and, crucially, Global Locate, a San Jose, California-based GPS technology company where, as VP-technology & chief navigation officer, he was involved in the TomTom ONE XL portable navigation device (PND) project for which Global Locate supplied its Hammerhead chip.

“This may have been the best-selling PND ever,” he says. “It was the first project I was involved in where we sold a million GPS chips.” As an aside he adds, “Now we sell almost that many every day!”

Global Locate got involved with TomTom because both groups were in the HP iPaq, the first smartphone to include GPS. “TomTom did the maps and we did the GPS chip,” says van Diggelen. Until then, Global Locate had focused on A-GPS, high sensitivity, first-fix technology.

“We had a really steep learning curve to manage turn-by-turn navigation; but we learned quickly,” van Diggelen says..”

Looking back, he says, that may have been the peak of the PND business, before smartphones made navigation free and ubiquitous. “I still have a working TomTom ONE that I use now and again; and I have an original still in the box, with Mr. T celebrity voice, on display in my office.”

iPhone 3G and beyond
Another handheld gadget that changed van Diggelen’s life, the iPhone 3G, was also equipped with Global Locate’s Hammerhead. “This was the smartphone that made GNSS what it is today,” van Diggelen says. “It wasn’t the first smartphone to include GPS, but it was the first iPhone with GPS, and then every other smartphone followed, and that’s why everyone on Earth now knows what GPS is.”

Shortly after winning the iPhone 3G contract, Global Locate company was acquired by Broadcom Corporation headquartered in Irvine, California. Following the acquisition, van Diggelen became vice-president of technology and Broadcom Fellow.

All of which has only meant more fun.

About Samsung’s Galaxy Note 4, with Broadcom inside, he says, “The GNSS in this phone, the BCM4773, marks the beginning of a new phase of GNSS chip architecture. It is a combined GNSS-Sensor Hub, also called a ‘Location Hub.’” For van Diggelen, this is a back-to-the-future moment for the industry; all cell-phone GNSS [signal processing] used to be host-based, to save on cost and size; now the chips are so small anyway that size is not the issue, battery life is.

Broadcom’s current GNSS chips operate on ultra-low power — a 95 percent savings compared to host-based processing, he says, “by doing GNSS in the background when the host application processor is asleep. This means we are once again making GNSS with system-on-chip architecture, like 20 years ago, but, after 10 iterations of Moore’s Law, a thousand times smaller and lower power.”

Van Diggelen’s current projects also include the BCM4771 and BCM4774. Both are successors to the BCM4773. And GPS has plenty of company on the company’s chips, which also support Galileo, BeiDou, GLONASS, satellite-based augmentation systems, Japan’s Quasi-Zenith Satellite System, and inertial sensors.

Indeed, another area that fascinates van Diggelen is sensor and GNSS integration. “I’ve been working on this for about 10 years,” he says. “You may not know it, but most smartphones use inertial sensors, in particular gyros and accelerometers, to aid the GNSS in urban canyons.”

The next big challenge, he says, is indoor navigation with the same accuracy that mobile device customers are used to outdoors: “It’s coming, but it requires an integration of sensors as well as other wireless technologies, like WiFi and Bluetooth.”

Family and Leisure
Now long established in the San Francisco Bay area, van Diggelen is a family man with two children. His wife Alison, now a noted Silicon Valley journalist, is creator of the Fresh Dialogues interview series and a contributor to the BBC World Service, Public Radio International’s The World, NPR’s KQED in San Francisco, and the Huffington Post.

“I’m a very bad example of the so-called ‘work-life’ balance,” van Diggelen admits. Luckily, he shares some major interests with his two kids, Lewis and Tanera. “Both my daughter and son enjoy running, and it’s a great way to spend time together.

“Like many children, they are forging their own paths,” he says. “ Both are interested in biology, which is great. I think biotech is today where electronics was in the fifties.”

He is also an avid fan of skiing — “Three years in Colorado with NAVSYS was a great way to make up for the geographic deficiencies of my birthplace.” — and hiking. “My son and I climbed Kilimanjaro when he was 14.”

But wherever he is, whomever he’s with, and whatever he’s doing, van Diggelen says, he’s always trying out some interesting new GNSS thing. This year it’s accelerometers on his skis, linked to GPS in his phone, primarily to analyze what happens over moguls.

“All I can say is that my children know far more about GNSS than they ever wanted to.”

And there’s sailing. On weekends van Diggelen is navigator and tactician aboard a racing yacht home-ported in Santa Cruz, California.

All the while, he does his best to maintain ties with the folks in South Africa.

“I try to visit at least once every two years,” he says. “It’s difficult since the San Francisco bay area is almost as far from Johannesburg as you can get. Luckily we have Skype!”

The Icing
Van Diggelen, not least of all, is also a passionate teacher, starting way back at the University of the Witwatersrand, where he ran the mathematics department of an all-volunteer weekend high school for children from the non-white townships of Soweto and Alexandra.

“School kids would spend every Saturday on our college campus,” he explains, “getting taught the school syllabus by college students.” The school had 10 math teachers, all, and about 700 school kids taking courses in engineering and physics as well as math.

The children were highly motivated, van Diggelen recalls. They had almost no instruction in mathematics in their regular schools. For example, in one part of Soweto, five high schools were served by one math teacher at that time, he says.

“I became good friends with some of the school students,” van Diggelen remembers, “and that really changed how I understood my own country. I think that whole experience has made me value education and enjoy teaching to this day.”

Throughout his career, van Diggelen has continued to lead seminars and training courses in his professional capacity. In addition, under the Lyceum school program, he taught navigation to middle school children in San Jose, California. Today he is a consulting professor at Stanford University, teaching post-graduate class on GNSS as well as GNSS-themed massive open online courses or MOOCs.

“Teaching GPS strongly influences me in my working life,” he says. “There are always great questions from students that challenge me to think better about what I thought I knew.”

So, like any good teacher, van Diggelen remains an active learner, and he credits many who have guided him on his way: “I’ve been really lucky to have the right mentors and colleagues at the right time, and there have been several important teachers through my career.”

Among the latter, of course, we should include the early inspiration of Tromp and Judith van Diggelen, who ultimately gave all of us one of the world’s leading GNSS engineers.

The post Frank van Diggelen: Riding the GNSS Wave appeared first on Inside GNSS - Global Navigation Satellite Systems Engineering, Policy, and Design.