Mark Sampson

By Mark Sampson, Racelogic

GNSS is changing. The days of only American GPS satellites providing signals to the civilian population are gone as new constellations are launched. GLONASS was a slow starter, but is now well established, and its signal architecture is now commonly implemented in manufacturers’ chipsets. Galileo is still very much in test phase with global coverage planned for 2019, although position fix using only Galileo satellites has already been demonstrated. The Japanese QZSS system, designed to aid navigation in urban canyons, is partially operational with further launches announced for the near future.

The latest openly documented network to come online is BeiDou-2, or BDS. Formerly known as Compass, the Chinese constellation now provides signals to China and surrounding areas, but plans for global coverage should come to fruition by the end of the decade.

Full control over its own constellation gives a country military, socio-political, and commercial advantages, especially if additional functionality — such as search and rescue services — is introduced alongside the standard navigational broadcast. BDS is unique in its use of a combination of standard-orbit and geo-synchronous satellites, the latter giving it a wider range of signal designed to carry more information.

The populace stands to benefit from a wide variety of localized and global satellite coverage, but only if there are end-user products available that actually make use of the new signals. Any manufacturer wanting a share of the market in China, for instance, will need to get BeiDou-2 integrated into its chipsets quickly, especially if an import levy is placed upon devices that don’t support it (as nearly happened with GLONASS).

How do you go about implementing BDS support in your new GPS product if you’re based in Europe or America? The coverage isn’t global yet; you can’t just go out into the office car park to test, and how are you going to incorporate the signals from the three geostationary satellites without actually being underneath them? Moving to China isn’t very practical, so the solution is a GNSS record-and-replay device.

Manufacturers and other customers will want to seek out simulators from companies that have been highly proactive in ensuring their products provide full support for each constellation, even before they come fully online. The convenience in being able to test new designs, applications, and system integration with reliability and consistency can bring significant savings in development cost and time.

With 14 BDS satellites currently in operation, and the recent release of the Interface Specification, we find more and more companies in the marketplace have been asking for BeiDou functionality. An added benefit for existing users would be flexible hardware capable of taking a simple firmware upgrade in order to record and replay BeiDou as well as GPS and GLONASS.

Icing on the system-testing cake would be a hard drive containing pre-recorded scenarios from China and Europe, with good BDS visibility, so that bench testing can commence immediately. Given that such a device can record raw signals, live recordings can be taken in Asia and then transferred to test facilities around the world.

Mark Sampson is Racelogic’s LabSat product manager. He has more than 15 years of experience in the development of GNSS technology. Working closely with leading businesses such as Bosch, Intel, Samsung, and Telefonica, he provides knowledge and expertise in testing any GNSS device, application, or integration.

GNSS have been with us for more than 30 years, giving rise to a wealth of positioning and navigation technologies for military, civilian, and consumer use. Today, we’re entering a new era of experimentation and innovation in satellite and hybrid positioning. In turn, this drives new test challenges and introduces an ever wider group of engineers to the art and science of GNSS test.

Where Is the Testing Panacea? I am sometimes asked, “What is the best way of testing a GPS receiver?” — as if there existed some laboratory panacea to all GNSS test and characterization woes. Well, there is a saying, “There are horses for courses,” meaning what performs well in one situation may not deliver in another, and nowhere is this more true than in the field of GNSS test. Not only is there a wide range of different test equipment available, but there are no universally applicable test objectives, test methods, or parameter definitions, in exactly the same way as there is not one universally applicable GNSS receiver. Just as the rapid time-to-first-fix of an automotive receiver may be less relevant in a maritime environment, so different test approaches have their place.

A Systematic Approach. If there is one thing, it is this: be systematic in your test design. Consider the purpose of the test, the test conditions, and the measurements you plan to take, and be wary of generic tests that may not achieve your objectives.

Equipment. A wide range of GNSS testing equipment is available, ranging from basic single-constellation RF simulators to highly configurable, multi-GNSS constellation simulators. Single-channel, multi-channel, and record and playback systems all have their place, and to get the best results in the fastest time, it’s essential to choose the kit that’s right for the kind of testing you need to do.

Vulnerability, Fidelity, Integrity, and Time Travel. More and more, receivers need to be tested for their vulnerability to interference, jamming, and spoofing. As GNSS-derived position and time become more ubiquitous, so the motivation for confounding the system grows. This has a double impact on test.

First, performance requirements around vulnerability may be introduced, with tests to match. Second, and perhaps less obvious, is the way in which this concern is reflected in the receiver’s design and potential rejection of the laboratory test signal. Yes, I mean receivers getting more fussy about the signals they lock onto. Anyone who has tested a receiver with an out-of-date recording or simulation scenario will have experienced a receiver refusing to track a satellite showing a time and date prior to its firmware release date. The receiver, discounting time travel, knows there has to be something wrong with a satellite showing a date before it was born. With the risk of spoofing, receivers will only get more picky and likely to reject poorly simulated signals. To avoid such effects, it is important to have very high integrity and fidelity in any simulator system. Getting these details right is not esoteric, but is essential to allow the proper attribution of any problems observed and if test results are to have any meaning.

Conclusion. Be systematic in your approach to test; beware the universal and generic; “good enough,” it rarely is.

Steve Hickling is lead product manager for Spirent’s GNSS simulator business and is based at the factory in Paignton, England. Previously he held a variety of marketing, technical, and management roles in the telecoms and optical components industries. He holds a bachelor of science degree in physics and electronic engineering from Birmingham University, an MBA from Open University Business School, and a post-graduate diploma from the Chartered Institute of Marketing.

Today’s customers ask for high-accuracy positioning everywhere, even in the most demanding environments. The time is long gone that the only requirement for a receiver was to track GPS L1 and L2 signals in open-sky conditions. State-of-the-art receivers operate in increasingly difficult conditions, cope with local radio-frequency interference, survive non-nominal signal transmissions, decode differential corrections from potentially untrusted networks — and more!

Difficult real-life operating conditions are typically not addressed in textbooks or in the specialized literature, and yet they constitute the real challenge faced by receiver manufacturers. Most modern GNSS receivers will perform equally well in nominal conditions, or when subjected to nominally degraded conditions such as the ones that correspond to standard multipath models. However, the true quality of a GNSS receiver reveals itself in the environment in which it is intended to be used.

In view of this, a GNSS manufacturer’s testing revolves around three main pillars:
◾    identifying the conditions and difficulties encountered in the environment of the intended use,
◾    defining the relevant test cases, and
◾    maintaining the test-case database for regression testing.

In developing new receiver functionality, it is important to involve key stakeholders to comprehend the applications in which the feature will be used and the distinctive environment in which the receiver will function. For example, before releasing the precise-point-positioning (PPP) engine for the AsteRx2eL, we conducted a field-test campaign lasting a full month on a ship used for dredging work on the River Thames and in the English Channel. This enabled engineers to capture different types of sea-wave frequency and amplitude, assess multipath and signal artifacts, and characterize PPP correction data-link quality.

Most importantly, we immersed the team in the end-user environment, on a work boat and not simply in a test setup for that purpose. As another example, in testing our integrated INS/GNSS AsteRxi receiver for locating straddle carriers in a container terminal, we spent months collecting data with the terminal operator. This was necessary to understand the specificities of a port environment, where large metal structures (shore cranes, container reach-stackers, docked ships) significantly impair signal reception.

Furthermore, the close collaboration between the GNSS specialist, the system integrator, and the terminal owner was essential to confirm everything worked properly as a system. In both examples, in situ testing provide invaluable insight into the operating conditions the receivers have to deal with, much surpassing the possibilities of a standard test on a simulator or during an occasional field trip.

Once an anomaly or an unusual condition has been identified in the field, the next step is to reproduce it in the lab. This involves a thorough understanding of the root cause of the issue and leveraging the lab environment to reproduce it in the most efficient way. Abnormalities may be purely data-centric or algorithmic, and the best approach to investigate and test them would be software-based. For example, issues with non-compliance to the satellite interface control document or irregularities in the differential correction stream are typically addressed at software level, the input being a log file containing GNSS observables, navigation bits, and differential corrections.

Other issues are preferably reproduced by simulators, for example those linked to receiver motion, or those associated to a specific constellation status or location-dependent problems. Finally, certain complicated conditions do not lend themselves to being treated by simulation. For example, the diffraction pattern that appears at the entrance of a tunnel is hard to represent using standard simulator scenarios. For these circumstances, being able to record and play back the complete RF environment is fundamental.

Over the years, GNSS receiver manufacturers inventoried numerous cases they encountered in the field with customers or during their own testing. For each case, once it has been modeled and can be reproduced in the lab, it is essential to keep it current. As software evolves and the development team changes, the danger exists that over time, the modifications addressing a dysfunctional situation get lost, and the same problem is reintroduced. This is especially the case for conditions that do not occur frequently, or do not happen in a systematic way. Good examples are the GLONASS frequency changes, which arise in an unpredictable way, making it very difficult for the receiver designer to properly anticipate. This stresses the importance of regression testing. It is not enough to model all intricate circumstances for simulation, or to store field-recorded RF samples to replay later. It is essential that the conditions of all previously encountered incidents be recreated and regularly tested in an automated way, to maintain and guarantee product integrity.

The coverage of an automated regression test system must range from the simplest sanity check of the reply-to-user commands to the complete characterization of the positioning performance, tracking noise, acquisition sensitivity, or interference rejection. Every night in our test system, positioning algorithms including all recent changes are fed with thousands of hours of GNSS data, and their output compared to expected results to flag any degradation. Next to the algorithmic tests, hardware-in-the-loop tests are executed on a continuous basis using live signals, constellation simulators, and RF replay systems, with the signals being split and injected in parallel into all our receiver models. Such a fully automated test system ensures that any regression is found in a timely manner, while the developer is concentrated on new designs, and that a recurring problem can be spotted immediately. The test-case database is a valuable asset and an essential piece of a GNSS company’s intellectual property. It evolves continuously as new challenges get detected or come to the attention of a caring customer-support team. Developing and maintaining this database and all the associated automated tests is a cornerstone of GNSS testing.

Greg Turetsky

Communications Security, Reliability, and Interoperability Council (CSRIC) Update

Many of us remember way back in 2001 when the FCC first announced E911 position reporting requirements for cell phones. That was a long time ago in many significant ways. Everyone had 2G phones and anxiously anticipated the arrival of 3G, and with it, data. Most people still had a landline at home, and used their mobile sparingly lest they overrun their monthly minutes. Roaming was very expensive and nearly impossible overseas. Very few phones had GPS, and people only turned it on when needed, as it significantly reduced battery life.

Now, in 2013, all of the technology has changed, but — not unexpectedly — the regulations have not. This is one of the reasons the U.S. Federal Communications Commission (FCC) created CSRIC.

The Communications Security, Reliability, and Interoperability Council’s mission is to provide recommendations to the FCC to ensure, among other things, optimal security and reliability of communications systems, including telecommunications, media, and public safety. The current council, CSRIC III, was born on March 19, 2011, and ended on March 18, 2013. Working Group 3 (WG-3), the E911 Location Accuracy group, has looked into both outdoor and indoor location accuracy issues to help the FCC shape new guidelines. I don’t think any of us would argue that given the current patterns of cell phone usage, the ability to provide a location indoors to a public safety answering point (PSAP) is something that is now needed, has significant value to the public, and would seem to lie within our grasp technically.

Working Group 3 is a fairly large group of experts from a wide variety of backgrounds. The actual list of participants is publicly available; what’s more interesting is the groups that they represent. Three main constituencies constitute the Working Group: the public safety community, the wireless operators, and the technology vendors. Each group has a slightly different goal, but they all worked well together to produce clear, unbiased reports that represent all the different members’ views in a way that lends more credibility to the overall report.

On March 14, the FCC released two reports created by WG-3: the “Indoor Location Test Bed Report,” and “Leveraging LBS and Emerging Location Technologies for Indoor Wireless E911 Report.” I will not review either document here as they are available publicly, but I will summarize the highlights of the reports from my perspective as a member of the location community and a concerned citizen, and attempt to predict where the process might lead next.

Figure 1. Indoor accuracy in the dense urban environment.

Test Bed Report. In my mind, two key results emerged from the Test Bed Report. The first was very positive: the test bed showed that there are technologies capable of yielding positions indoors, and their performance can be compared analytically. This may seem like a bland statement, but it carries a significant amount of weight with both the public safety community and the FCC. It acknowledges that the technology has evolved sufficiently such that in a test bed setting, we can gather and compare, in an apples-to-apples way, the performance of diverse technologies in terms of yield and accuracy. Similar to the LightSquared reports, this report focuses on ensuring that the data itself is valid. The interpretation of the data is far too politically and economically charged to be agreed on by all parties involved. It is a great accomplishment to concur on a methodology by which testing should be done, and to produce a set of results that can be given to the FCC with the entire council’s approval.

The second highlight from my perspective was less positive. The test bed originally had seven participants, but in the end only three completed the process. This indicates that there are even more candidate technologies for solving the indoor E911 problem — but for a variety of reasons, they were not ready for CSRIC testing at this juncture. Although having three choices is good, seven (or even more) would be better for the FCC to feel confident in its ability to create a new mandate with sufficient flexibility on implementation. There are clearly many ways to skin this cat technically, but we have to ensure that the test bed methodology allows as many as possible viable alternatives to be compared. There is clearly a gap between those technologies that are commercially available and those that can be used for E911.

Leveraging LBS. The Leveraging LBS Technology report also reached some interesting conclusions. The concept of leveraging LBS was actually how I became involved in the CSRIC. The underlying question that the FCC asked me to explore was “Why can a smartphone user can get a dot on a map indoors (usually with an uncertainty circle, no less), but no location information shows up on the PSAP screen if he makes an E911 call?”

As we dug into this problem, it became clear that this was less of a technology problem and more of a business/policy one. Quite a few large companies make money by providing that indoor location for various applications, but there isn’t any real money in E911 — although there are lots of liabilities. Also, many of these solutions are proprietary either to the phone, the operating system, or the application, while an E911 solution would need to be standardized across all of those as well as different carriers.

Figure 2. Indoor accuracy in the urban environment.

Conclusion. The FCC has received two reports with similar conclusions: We have come a long way since 2001, but we might not be there — the indoor E911 promised land —just yet.

There is still more to come, however. Therefore, many participants and observers hope the work of the current CSRIC will lay the foundation for a rational conversation about indoor E911 right now, and still be around to allow for future improvements. We have recommended that the test bed be maintained so future results can be compared with current ones. At issue is the funding source for the test bed. The FCC has announced the coming of a CSRIC IV, but has not released any further details. It is certainly the hope of WG-3 that the work performed to date to establish and validate the test bed will be available for use by future technologies as they mature.

Locating emergency callers indoors is a critical capability that we as society must address — not for the callers’ convenience, but for their safety and or public safety generally. The problem has technical, commercial, regulatory, financial, legal, and public safety facets to it, making it a very complex issue.

I should also note, that although E911 is a U.S. regulation, the problem of indoor location is under scrutiny in nations all over the world. I earnestly hope that all sides can continue working together to find a solution that can be implemented for the benefit of everyone.

Greg Turetzky is senior director, CTO Office, for CSR. He served on the CSRIC Working Group 3 LBS Subgroup. He will participate in a April 16 GPS World Webinar on this topic. Registration is free.

Paul Flament

A Constellation of 18 by 2015, Rising to 26 by the End of That Year

An Interview with Paul Flament

Paul Flament is the European Commission Programme Manager and Head of the EU Satellite Navigation Programme Unit.

A Belgian civil engineer specialized in telecommunications, he previously worked  for 11 years in the European Space Agency, for space missions control centers and for the design and development of telecommunication satellites. After obtaining a master’s degree in European Studies, he joined the European Commission in 1998.

On the occasion of this special Europe/Galileo issue of the magazine, he speaks to GPS World readers regarding the present and promising future of the European GNSS.

Alan Cameron (AC): Can you recap for us briefly the upcoming satellite launch schedule that will take Galileo to Initial and then to Full Operating Capability?

Paul Flament (PF): It’s very simple. The first two in-orbit validation satellites were launched in October 2011, the next two on October 12, 2012. Satellites 5 and 6 will be launched in September of this year, aboard a Soyuz launcher from Kourou, and numbers 7 and 8 will follow in December.

Then, in 2013 we will see three Soyuz launches of two satellites each. We do not have the precise launch dates yet, but they are likely to be in April, June, and September. In December 2014, we expect to have the first launch using the Ariane 5 launcher, which is capable of deploying four satellites in one go. This means that by the end of 2014 Galileo will have deployed 18 satellites in orbit.

In 2015, there will be two Ariane 5 launches, one in the middle of the year, one at the end, each carrying four satellites. This will bring the total number of satellites to 26 by the end of 2015.

I am doubly confident of this constellation deployment schedule. First, at the technical level: The European Commission (EC) together with the European Space Agency (ESA) is following very closely all the industrial activities. The satellites in production now are with OHB. We have people in Bremen, where the OHB facilities are located, following this very closely. If there are technical issues, we take them up straight away with those concerned, the moment they appear. We also have monthly meetings with Jean-Jacques Dordain, the director general of ESA, and we make a careful tour of all the dates and conditions.

Secondly, there are no unknowns from the budget point of view. Except for the cost of the Ariane 5 launchers, the costs of deployment are already covered. And the EU’s member states have agreed on a budget of €6.3 billion for the next seven years. Budget should not be an issue.

Just recently, on March 12 of this year, we were for the first time able to calculate positions with the four Galileo satellites already in the sky. They pass overhead every so often, depending on geometry of orbit. This is an important technical milestone, even if this does not provide you a service as such. It demonstrates that the capability is there and that the mission part of the system works.

In terms of services, we want to be able at a certain point in time to start offering a guaranteed service. Our objective is October 2014. We will then have a constellation of 14 satellites. On the basis of that constellation, taking some margins, we will guarantee a minimum service of eight operational satellites. That service, in combination with GPS and other systems like GLONASS, will be something that users can start counting on. We will guarantee that at least eight satellites will be in operation from that moment onward.

We will probably translate this number of satellites into a performance-level guarantee. But for the moment it will be based on the number of satellites.

The fact is that we are populating the constellation, and very quickly we will have 26 satellites in orbit. That leads us to the Initial Operational Capability (IOC) phase: With those 26 in the sky we will guarantee a service based on 22 operational satellites.

The target constellation is one of 30 satellites. We don’t know yet for sure when this will be achieved. That will depend on when the last batch of satellites are ordered, and we are still discussing that. But we have an obligation to have deployed 30 satellites by the end of 2020. Then we will guarantee a service based on 24 satellites, with two spares per orbital plane.

AC: What is foreseen as the market readiness to adopt and use Galileo at that time? What companies are taking the lead in designing, manufacturing, and selling combined GNSS receivers?

PF: We believe that market trends go towards multi-constellation receivers. We already see that in some iPhones with GLONASS capability. We already see in the professional market segment that there are some companies providing Galileo capabilities, taking advantage of E1 and E5 for GPS and Galileo.

In the mass market, we also believe many companies will start to build up the multi-signal capability. Companies like STMicroelectronics are working on that. I have asked the European GNSS Agency (GSA) to provide figures. Out of a list more than 60 receiver manufacturers, at least 50 percent of them have at least one product that incorporates European Geosationary Navigation Overlay Service (EGNOS) capabilities. Of those same 60 companies, 30 percent already also have products incorporating Galileo capabilities: STMicro, Septentrio, NovAtel, Leica Geosystems, IFEN, Japan Radio, and others.

We believe that it is important to have continuous interaction with receiver manufacturers so that they understand the benefits of Galileo. EC Vice President Antonio Tajani is devoting a lot of attention to that. We build Galileo, but we do it for users. We have to make sure manufacturers understand the benefits. Discussions with them started in December in London when Mr. Tajani met with a set of CEOs of receivers manufacturers. He promised to meet with them every six months. We are also meeting with them on March 19 to provide information on calendars.

AC: What other European Commission programs will rely on initial or full Galileo capability to fulfill their mission?

PF: As of today, there is no obligation to use Galileo, no mandatory regulation imposing the use of it. There are some initiatives, like the Intelligent Transport Directive, which recommend but do not impose making use of EGNOS and Galileo. Or eCall, which in case of a car accident automatically contacts the rescue services. This will be required in all new cars starting 2015. These systems rely on satellite navigation for positioning. We also have digital tachography to measure the times of driving and rest of truck drivers. This will become a requirement as from 2018, and also relies on satellite navigation.

We also see initiatives by member states to put in place GNSS-based road-pricing systems. Germany has taken a lead in this. The European Union (EU) is trying to harmonize these road-pricing systems across national borders, with programs like Eurovignette and the Interoperability Directive.

In other modes, like aviation, you already have EGNOS. With landing procedures in place based on EGNOS, the system has become a reality.

In Europe we have the common agricultural policy, providing subsidies to farmers. As these are based on field sizes and crops, they need to be controlled, and using EGNOS and Galileo will help achieve more precise measurements.

AC: The Galileo Open Service Signal In Space Interface Control Document (OS SIS ICD) Issue 1 is described as being “subject to evolution.” Can you predict when a further iteration (Issue 2) will appear, and what changes it may contain?

PF: The present version of the ICD is still applicable. It correctly reflects the structure of the messages broadcast by Galileo. The statement you quote refers to the evolution of the document because as you remember there has been a debate about a safety-of-life (SOL) service that is multi-constellation and multi-regional. Since the initial concept of SOL on Galileo was changed in the last two years, some capacity onboard the satellites has been freed. We would like to use that for something else, keeping the backward compatibility for receivers. This will allow us to put in place, for example, a mechanism to improve the tracking performance and availability. Also authentication and higher accuracy for professional markets could be implemented, while maintaining the options for future advanced receiver-autonomous integrity monitoring (RAIM). That explains why we are still working on the evolution of the document. The next version of the ICD will be published in due time.

AC: Can you talk about progress towards increasing the EU share of the GNSS global market — currently 20 percent, but with the objective to reach 33 percent, as in other high-tech sectors? How might this be done?

PF: It is important for us in building Galileo that users benefit in having a second constellation. Satisfying users is the key. It also gives us some sort of independence from GPS, which would otherwise be the sole-source GNSS in the world. We would like our European companies to be more proactive and not to be limited to 20 percent share of the market. Everyone would.

We have our traditional research programs, like the Seventh Framework Programme (FP7). The next installment of the EU’s research programs will be called Horizon 2020, and it will make available budget devoted to the development of applications, receivers, and so on. Whether that will allow European companies to gain market share will depend on their proactivity, their innovation, and market-oriented strategies. That is their responsibility.

We are also active in things like the Galileo Masters, which tries to help small-to-medium enterprises (SMEs) who have good business ideas, young entrepreneurs or scientists with good GNSS-related innovations.

On top of that, we are starting studies to see how we can secure the market uptake of Galileo, not simply to help European industries, but to see that manufacturers and downstream applications developers understand the benefits of Galileo. By the end of the year, we should have created a better understanding by manufacturers and users of the full potential of using Galileo.

AC: Are there any other issues or concerns that you would like to bring to the attention of GPS World readers and the global GNSS community?

PF: I would like to briefly focus on EGNOS. For us it is important that this service will stay for a long time. We promised this to the aviation sector. The EU is finalizing its budget for the period 2014 to 2020, and this will allow us to continue to operate and improve EGNOS. Our objective is that it will augment Galileo as well as GPS, using the dual-frequency approach. That’s a real plus at the regional level for Europe. Its main customer will remain the aviation sector, although it is also widely used in precision farming, tracking and tracing, and so on.

Secondly, we are working on the continuous evolution of the system. We all know that satnav is an evolving domain. It takes time to build satellites and to improve technology. The Mission Evolution Road map that has been developed by experts will be presented to member states later this year.
Finally, we will be organizing the annual European Space Solution conference in Munich in November this year, and in mid-2014 in Prague. We are also hosting the International Committee on GNSS (ICG), which will take place in Prague in November 2014. For us, the location in Prague is symbolic since the European GNSS Agency (GSA), which will be our exploitation entity, is also located there.

Janice Partyka

But Google and Facebook Signal Their Intent to Capture Users’ Location

The biggest international mobile-phone show ever, Mobile World Congress 2013, took place early this month in Barcelona, Spain. It came at an interesting time. Attendees learned it no longer makes sense to think about which device, or screen, is of primary importance to users. Google reports findings that 90 percent of users move sequentially between several screens — TV, phone, desktop computer and tablet — to accomplish tasks.

Google, wanting to more fully exploit ad opportunities across all devices, has revamped its AdWords program to be one platform that advertisers will use to control ads on all types of devices. In the past, advertisers could choose to advertise on desktops and no other devices.  The new rule requires mobile advertising. Although it is an integrated platform, advertisers can use parameters like the device’s location or type to send specially crafted messaging.

The GPS-based fitness watch market looks like it is on a steep curve upwards, and feasible smartphone GPS watches are available.
Rumor says Facebook is going to start tracking users’ locations at all times, to be able to cull more ad revenue from individuals’ preferences and geo life.

Finally, and most importantly in the long run for all location-enabled users, the Federal Trade Commission took a stand on location privacy.

Google Requires Mobile Advertising. Citing concerns that the shift from desktop to smartphones and tablets is damaging its bottom line, Google is revamping its AdWords advertising platform to integrate ad campaigns across all device screens. In fact, Google indicated that it will require all advertisers to pay for mobile ads even if they only wish to reach consumers on desktops. The revamp will allow customers to use contextual factors like location, time of day and device type to control integrated campaigns.

Google provides an example of how a user’s location and device type could change the advertising message. “For example, a pizza restaurant probably wants to show one ad to someone searching for ‘pizza’ at 1pm on their PC at work (perhaps a link to an online order form or menu), and a different ad to someone searching for ‘pizza’ at 8pm on a smartphone a half-mile from the restaurant (perhaps a click-to-call phone number and restaurant locator),” reads Google’s blog.

Will Apple Grab Your Wrist? Rumors continue that Apple will release a GPS-based fitness watch in 2013. Whether Apple enters the market or not, the GPS fitness market is huge and growing. The GPS fitness watch market is set to reach $1.07 billion in 2013, predicts ABI Research. Cellular-connected GPS fitness watches like the I’m Watch may further speed this market.

“There have already been unfounded rumors around Apple in 2013, so let’s wait and see. If an Apple watch did feature integrated GPS, it would no doubt significantly boost shipment forecasts in 2013,” asserts Dominique Bonte of ABI. Some start-ups in the GPS Watch category have joined the action including Leikr, Pebble, Basis and others.

Facebook Is Watching. Is it possible for the relationship between Facebook and Google to get tenser? According to a Bloomberg article, Facebook is developing a smartphone application that will track the location of its users. The app is said to be scheduled for release by mid-March, and would run on handsets in the background, even when the Facebook app or the phone isn’t open or in use.

The location data would help Facebook capture more advertising revenue as ads can be more targeted with information about a user’s location and habits. The project is said to be headed by an ex-Googler and talent from Glancee and Gowalla, both of whom were purchased by Google.

Location privacy Is Covered. Privacy concerns with Facebook location tracking would undoubtedly be raised. Currently Facebook records the GPS coordinates of users when they post status updates or photos from their phones, or check into a venue. Tracking users 24/7 is another thing. Facebook’s current location sharing policy seems to cover them carte blanche. It allows the use of data “to serve you ads that might be more relevant,” and “to tell you and your friends about people or events nearby, or offer deals to you that you might be interested in.”

Also-Rans. Will Windows and BlackBerry smartphones succeed? Will there be a crack, even a tiny one, in the duopoly of iOS and Android? The biggest worry for Microsoft and BlackBerry is if initial sales of their smartphones are too small to excite developer interest. Without abundant applications, consumers won’t continue to buy these phones. ABI Research is predicting that the demand will be strong enough and is forecasting a BlackBerry installed base of 20 million and Windows smartphone base of 45 million by year end.

Location Standards for Next Generation LBS. The Open Geospatial Consortium (OGC) held a free session and reception at the Mobile World Congress for mobile developers, location data providers, network operators and LBS service users. Attendees learned the latest in open standards development.

Path Social Network Charged on Privacy Infringement. The operator of the Path social networking app has agreed to settle Federal Trade Commission (FTC) charges that it deceived users by collecting personal information from their mobile device address books without their knowledge and consent. The settlement requires Path, Inc. to establish a comprehensive privacy program and to obtain independent privacy assessments every other year for the next 20 years. The company also will pay $800,000 to settle charges that it illegally collected personal information from children without their parents’ consent.

The settlement with Path is part of the FTC’s ongoing effort to make sure companies live up to the privacy promises they make to consumers, and that kids’ personal information isn’t collected or shared online without their parents’ consent.

“Over the years the FTC has been vigilant in responding to a long list of threats to consumer privacy, whether it is mortgage applications thrown into open trash dumpsters, kids information culled by music fan websites, or unencrypted credit card information left vulnerable to hackers,” said FTC Chairman Jon Leibowitz. “This settlement with Path shows that no matter what new technologies emerge, the agency will continue to safeguard the privacy of Americans.”

Path operates a social networking service that allows users to keep journals about “moments” in their life and to share that journal with a network of up to 150 friends. Through the Path app, users can upload, store, and share photos, written “thoughts,” the user’s location, and the names of songs to which the user is listening.

In its complaint, the FTC charged that the user interface in Path’s iOS app was misleading and provided consumers no meaningful choice regarding the collection of their personal information. In version 2.0 of its app for iOS, Path offered an “Add Friends” feature to help users add new connections to their networks. The feature provided users with three options: “Find friends from your contacts;” “Find friends from Facebook;” or “Invite friends to join Path by email or SMS.”

However, Path automatically collected and stored personal information from the user’s mobile device address book even if the user had not selected the “Find friends from your contacts” option. For each contact in the user’s mobile device address book, Path automatically collected and stored any available first and last names, addresses, phone numbers, email addresses, Facebook and Twitter usernames, and dates of birth.

The FTC alleged that Path’s privacy policy deceived consumers by claiming that it automatically collected only certain user information such as IP address, operating system, browser type, address of referring site, and site activity information. In fact, version 2.0 of the Path app for iOS automatically collected and stored personal information from the user’s mobile device address book when the user first launched version 2.0 of the app and each time the user signed back into the account.

The agency also charged that Path, which collects birth date information during user registration, violated the Children’s Online Privacy Protection Act (COPPA) Rule by collecting personal information from approximately 3,000 children under the age of 13 without first getting parents’ consent. Through its apps for both iOS and Android, as well as its website, Path enabled children to create personal journals and upload, store and share photos, written “thoughts,” their precise location, and the names of songs to which the child was listening. Path version 2.0 also collected personal information from a child’s address book, including full names, addresses, phone numbers, email addresses, dates of birth and other information, where available.

The COPPA Rule requires that operators of online sites or services directed to children, or operators that have actual knowledge of child users on their sites or services, notify parents and obtain their consent before they collect, use, or disclose personal information from children under 13. Operators covered by the Rule also have to post a privacy policy that is clear, understandable, and complete.

The FTC charged that Path violated the COPPA Rule by:

• not spelling out its collection, use and disclosure policy for children’s personal information;
• not providing parents with direct notice of its collection, use and disclosure policy for children’s personal information; and
• not obtaining verifiable parental consent before collecting children’s personal information.

In addition to the $800,000 civil penalty, Path is prohibited from making any misrepresentations about the extent to which it maintains the privacy and confidentiality of consumers’ personal information. The proposed settlement also requires Path to delete information collected from children under age 13 and bars future violations of COPPA. Path has already deleted the address book information that it collected during the time period its deceptive practices were in place.

The FTC also introduces “Mobile App Developers: Start with Security,” a new business guide that encourages developers to aim for reasonable data security, evaluate the app ecosystem before development, and includes tips such as making someone responsible for data security and taking stock of the data collected and maintained.

The commission vote to authorize the staff to refer the complaint to the Department of Justice and to approve the proposed consent decree was 5-0. The DOJ filed the complaint on behalf of the Commission in U.S. District Court for the Northern District of California on January 31, 2013. The proposed consent decree will be filed with the same U.S. District Court today and is subject to court approval.

Janice Partyka is contributing editor for wireless at GPS World. Subscribe free to her monthly e-newsletter, Wireless Pulse, at www.gpsworldcom/subscribe.

John Lavrakas

Economically, the System Differs Significantly from Its GNSS Cousins

John W. Lavrakas

In May 2007, I authored an article in GPS World looking ten years into the future and envisioning how the GNSS field would operate at that then-distant time. Reviewing my assessments, I see that I was both accurate and wide of the mark with my predictions.

The prediction that has proved accurate was that the GNSS world would be hybrid, with no one system as the sole provider of satellite-based positioning and timing services. This was hardly a risky prediction. Most in the GNSS community would have come to the same assessment.

But what I did not see coming were the advances China would take with its BeiDou program. My original assessment was based on three GNSSs only: GPS, GLONASS, and Galileo, and did not include BeiDou.

When I did my analysis in 2006, China was pretty quiet on BeiDou: no technical descriptions, no interface control document (ICD); no presentations at conferences of the Institute of Navigation. What little we knew about BeiDou was that it was a limited system, offering at best a regional solution. The original design was an active system using geosynchronous satellites, requiring each remote unit to request position from the satellite, which was calculated and sent back to the remote station.

How things have changed.

Since 2007, China has reshaped the BeiDou concept into a full-fledged modern GNSS, offering CDMA codes, navigation messages, and data rates comparable to GPS and Galileo — and lots of satellites. The ICD states in section 3.1, “When fully deployed, the space constellation of BDS consists of five geostationary Earth-orbit (GEO) satellites, twenty-seven medium Earth-orbit (MEO) satellites, and three inclined geosynchronous satellite orbit (IGSO) satellites.” No dates are provided, however, regarding attaining these numbers. So the BeiDou system promises to be on par with the other GNSSs.

Why does this matter?

While technically the BeiDou system resembles its cousins, economically it presents quite a different animal. Unlike other nations offering GNSS, China has a huge capacity for manufacturing at low cost. Considering this situation from a business perspective, a possible scenario could be that China offers GNSS chipsets that operate with BeiDou (either solely or as a hybrid with another GNSS)at extremely low prices. In doing so, China could corner the market for general purpose LBS applications (setting aside specialty receivers, such as for surveying and aviation applications). The price point would be so attractive that LBS services would employ Chinese devices in preference to the GPS ones, much like consumers purchase television sets: most come from China, and none are made in the United States any more.

China offers something, then, in this scenario that neither Russia, Europe, nor the United States can currently match. This may not be the scenario that eventually occurs, but it is possible. Other factors such as local terrestrial PNT solutions and dual-frequency improvements will come into play, but what I have described is one possible scenario. While the signal is free, the equipment is not, and when we are talking about a billion or more installations, cost is going to be a big driver.

Am I going out on a limb and saying that BeiDou will be the system of choice in another ten years or so? No, I would not go this far.

But I do say that serious competition for GNSS users (read “market share”) is now in play. Further, it is important for each GNSS operator to recognize this as they consider the services and features they choose to offer, and the impact these have in capturing their share of the market. GNSS providers now must factor the business aspect of their services as much as the technical, scientific, or safety of life. The U.S. government, for one, has gotten a bit complacent in upgrading GPS services to meet user needs, operating from a basis that it is the only GNSS on the block. It could wake up one day and find this no longer to be the case.

John Lavrakas is president of Advanced Research Corporation, where he provides consulting services on satellite navigation and fishery information systems. He has spent 32 years in GPS, supporting development of the GPS Control Segment, GPS user equipment, GPS performance analysis capabilities, and developing and marketing location-based systems. He is past president of the Institute of Navigation and an ION Fellow.

Oscar Pozzobon

By Oscar Pozzobon

The GNSS interference session this year at the ION-GNSS conference in Nashville was one of the most crowded, confirming the need of all sectors of the community to understand the threats in GNSS and how they can be mitigated. In that context I received one of the most challenging questions of my career: “Can we predict the future of GNSS security?” What is the status of civil and commercial GNSS security today? Which are the threats and risks and how they are mitigated? Where are we going and what shall we expect from the future?

I decided to tackle this topic carefully, using as a basis and inspiration the history of information and communication technology (ICT) security: from the first threats and attacks of the 1980s to a glance at what technology offers today.

Secondly, to obtain different perspectives — and shift the blame to someone else if one day these predictions should prove to be wrong — I solicited the opinions of three other experts and colleagues in the domain of GNSS and security: Logan Scott, Todd Humphreys, and David Last.

Snapshots from History

The Internet was officially born in 1969 when the U.S. Defense Advanced Research Projects Agency (DARPA) crated the Advanced Research Projects Agency Network (ARPANET). A short 11 years later, the 414 Gang, a computer-hacking organization (the term hacking was coined at the Massachusetts Institute of Technology as early as the 1960s) performed one of the first attacks and frauds upon computer systems. In 1983 the first computer virus was discovered. In 1988 the Computer Emergency Response Team (CERT) was created to report and disseminate information on the threats, and AT&T Bell Labs created the first concept of firewalls. Some readers may recall the 1983 movie War Games, which found Hollywood hard at work on cyber-attacks, denial, and deception to computer systems at a time when we had only six GPS satellites in orbit. One year later, Steven M. Bellovin published a paper on the possibility of performing a transmission control protocol/internet protocol (TCP/IP) Spoofing attack.

Six years after that paper, in 1995, the Computer Incident Advisory Committee (CIAC) reported the first TCP/IP spoofing attack to a system. In another four years, the first denial of service (DoS) attack to computer networks was reported by the CERT. A DoS attack consists of several computer systems sending unsolicited requests to the target, causing a saturation of network and computer resources. In terms of objectives, it could be compared to what jamming causes in GNSS systems.

Between 1984 and 1986, Dorothy Denning and Peter Neumann researched and developed the first model of a real-time intrusion detection system (IDS). This prototype was initially a rule-based expert system trained to detect known malicious activity. I like to think that this could be compared to today’s jamming detection and localization systems.

In the 1990s, the need for guidelines to provide general outlines as well as specific techniques for implementing security became a pressing one for all organizations. The first standard, originally published by the British Standards Institution (BSI) in 1995 was the BS 7799, was later adopted by the International Organization for Standardization (ISO) as the ISO/International Electrotechnical Commission (IEC) 27000 series.

Information technology today can be security-evaluated via the Common Criteria (CC) standard (ISO/IEC 15408), which allows computer-systems certification. CC is a framework in which computer system users can specify their security functional and assurance requirements. The Federal Information Processing Standard (FIPS) 140 is an alternative standard for cryptographic modules, developed by the U.S. Federal Information Processing Standards.

The Nessus Project, started by Renaud Deraison in 1998, set as its objective the provision of an open-source vulnerability-assessment tool. Since 2000, Nessus has become one of most popular tools for computer-network security and vulnerability assessment, used by more than 75,000 organizations worldwide.

ICT security today is assured in a lifecycle composed by CERT managing the threats notifications, ISO/IEC 27000 managing the processes, and CC/FIPS 140 defining the security requirements for the system and vulnerability assessment tools to certify the robustness.

Now, Where Are We in GNSS?

Radio-frequency interferences (RFI) or jamming cases can hardly be tracked, as they are difficult to detect and have a long history in the military domain. Recent incidents such the one at Newark International Airport show that the threat is increasing and demonstrate the need for mitigation strategies. GNSS signal falsification frauds, or spoofing, seems to as yet have no evident cases in the civil domain.

The Volpe Report of September 10, 2001 is one of the first government public announcements of GNSS threats, including jamming and spoofing. More than 10 years, later the unmanned aerial vehicle (UAV) experiment coordinated by Todd Humphreys at the University of Texas proved that such attacks are feasible.

In GNSS, jamming detection (and sometime mitigation) are nowadays commercial options for some professional and mass-market GNSS receivers. Spoofing detection has been available in commercial prototype receivers since 2008 (among others, the Trusted GNSS Receiver (TIGER) funded by the European GNSS Agency. In 2012 we have seen the presentation of the first civil GNSS security testbed. For examples of the latter, see the University of Texas TEXBAT initiative, mentioned on page 37, and the GNSS Authentication and User Protection System Simulator (GAUPSS) project, which involved the development of software and algorithms that were integrated and tested in the radio navigation laboratory of the European Space Agency/ European Space Research and Technology Centre (ESA/ESTEC) in Noordwijk, the Netherlands.

I will make the assertion that compared to ICT security, civil GNSS security seems to be reliving the early days of the 1980s: first publication of attack concepts, first publicly known attacks, no standards, and only prototype mitigation strategies. With a gap of almost 30 years, at least four mid-Earth orbit GNSS systems becoming operational in the next few years, and an annual 10 percent growth rate of GNSS applications, the era of civil GNSS security begins now.

The Question Why

Logan Scott is a consultant specializing in radio-frequency signal processing and waveform design for communications, navigation, radar, and emitter location. His opinion on the future threat leaves no doubts:

“In assessing security threats, an important starting question is ‘Why would someone do that?’ If there is no motivation, chances are, there won’t be an attack. Over the last five years or so, the combination of ubiquitous, low-cost communications systems and satellite navigation has moved civil GNSS positioning and timing into use domains where there are stronger motivations for an attack. Specifically, widespread use in asset monitoring and tracking encourages jamming attacks and so, we are seeing more such attack. As GNSS becomes more deeply embedded into societal infrastructure, we can expect to see more attacks of increasing sophistication. Motivation will be there.”

David Last is a consultant engineer and expert witness specializing in radio-navigation and communications systems. He operates in the domain of covert tracking and law enforcement,, an area where interference can be tempting. As expert in the field, and to the best of his knowledge, he believes that “although there are some cases of jamming, we have seen no events of spoofing — so far. To date, all we have seen from criminals are crude jamming attacks. Attacks by technically sophisticated aggressors who understand GNSS vulnerability have yet to start. They will be much more serious.

“Furthermore, when the receiver stops receiving data in a court case, we can’t say it’s jamming: we can mention that is one of the things that stops the signal. Law enforcement is now beginning to use receivers that can perform jamming detection.”

David Last’s opinion on the issue of potential low-cost spoofers appearing in the near future was also provocative: “Criminals don’t buy things, they steal them.”

The Time is Right, Now

An ICT security standard arrived about 10 years after the first publication and case reports of attacks. Are we at the right time, now, to consider security certification of GNSS receivers?

Logan Scott’s opinion is that receivers should be certified in order to provide awareness of the attacks:

“Today, essentially all houses and buildings have smoke alarms. Smoke alarms don’t put out fires but they do alert the occupants to the probability that there is a problem. Similarly, GNSS receiver situation awareness regarding jamming and spoofing is a first step towards militating against attacks on GNSS components. As civil receivers stand today, many don’t discriminate between loss of lock due to signal attenuation and loss of lock due to jamming. This needs to change.

“Fairly simple algorithms can detect most types of jamming and spoofing. Jammers and simple spoofers almost invariably affect automatic gain control gain settings. They are easy to detect. More sophisticated spoofers have difficulty covering apparent direction of arrival and can be detected using some simple antenna techniques.

“The problem for the user community at large is in knowing whether or not a receiver maintains adequate situational awareness. This is where test-based receiver certification can play a role.”

Awareness is indeed needed to notify to the application the security and authentication state. GNSS authentication integrated in the system still lies far off.

Not only is implementing authentication without compromising user cost and simplicity challenging, but the impact on the ground and space segment in GNSS to maintain legacy signals compatibility is also considerable.

We believe that user-based authentication will be the Plan B for the next 5–10 years. This requires the development of receiver techniques and the use of security testbeds as the baseline for vulnerability assessment, in the same way the Nessus tool was used in the 1990s for computer network assessment.
On the test approach, Logan Scott stresses that “Using a series of canned scenarios, GNSS receivers can be tested to determine how well they maintain situational awareness. Do well enough, and the receiver can be stamped as certified, much like an Underwriters Laboratory (UL) label. The test process can be automated and conducted by an independent third party, similar to the way cellular equipment is certified.

“Additional certifications might include cyber security aspects such as accepting only digitally-signed software updates and maps, providing attestation capabilities, and use of authenticatable GNSS signals.

“The benefit for the non-expert user community is that they have a basis for selecting GNSS receivers, secure in the knowledge that they meet minimum performance standards.”

Testing, Testing

Ringing in my third fellow expert, I asked Todd Humphreys, assistant professor in the Department of Aerospace Engineering at the University of Texas at Austin, for his opinion regarding the future of GNSS security testing.

“A testbed capable of simulating realistic spoofing attacks is needed so that the efficacy of proposed civil GPS signal authentication techniques can be experimentally evaluated. A generic testbed capable of evaluating all known authentication techniques would be prohibitively expensive; for example, it would require a large anechoic chamber for evaluating receiver-autonomous antenna-oriented techniques. But if the scope of evaluation is limited to receiver-autonomous signal-processing-oriented techniques and networked techniques, then it is possible not only to develop an inexpensive testbed but to share the testbed’s data component so that the tests can be replicated in laboratories across the globe.

“In October, we released the Texas Spoofing Test Battery (TEXBAT), a set of six high-fidelity digital recordings of live static and dynamic GPS L1 C/A spoofing tests conducted by the Radionavigation Laboratory of the University of Texas at Austin. National Instruments is hosting TEXBAT on cloud servers so that anyone can download it.

“The battery can be considered the data component of an evolving standard meant to define the notion of spoof resistance for civil GPS receivers. According to this standard, successful detection of or imperviousness to all spoofing attacks in TEXBAT, or a future version thereof, could be considered sufficient to certify a civil GPS receiver as spoof-resistant.

“This is a spoofing-specific version of the ‘not stupid’ certification that Logan Scott has suggested for GNSS receivers. In my July congressional testimony, I advocated requiring a ‘spoof resistance’ certification for GNSS devices that are used in critical infrastructure.”

Looking into the Future

Now I turn and attempt to answer the final question: Can we predict the future of civil GNSS security?

I believe that we can predict that, unfortunately, attacks will increase, and new attacks will be discovered. For example, we have been talking about deception jammers (also known as intelligent, PRN, or gold code jammers) only in the last few years, as an emerging threat. We will see certification and standards for security in GNSS, and we expect them to come in the next five years. Tools for GNSS security testing are already available commercially, for example the Qascom GNSS Security testbed (GST). As ICT has CERT for notification of threat, we will also see the raising of a GNSS emergency response team — possibly called a GERT.

In conclusion, whether my predictions turn out to be correct or not, the good news is that GNSS security also has a history in Hollywood’s annals: the 1997 James Bond movie Tomorrow Never Dies narrates a spoofing attack on the GPS navigation system of a submarine, performed via a GPS encoder that modifies the time.

Again, 007 anticipated the future, and he did it 15 years before a handful of world renowned GNSS security experts.

I have not yet seen the 2012 James Bond film Skyfall. I wonder what it portends?

Oscar Pozzobon is the director and co-founder of Qascom S.r.l., based in Bassano del Grappa, Italy. He received a Masters degree in telecommunication engineering from the University of Queensland, Australia, and is the Italian contact for the Civil Global Positioning System Service Interface Committee (CGSIC).