Testing the antenna performance of GNSS signals such as GPS, GLONASS, Beidou, Galileo and Metropolitan Beacon Systems (MBS) is key to location accuracy performance of a mobile device.
To address the testing need for A-GNSS services, Rohde & Schwarz and Bluetest are partnering in creating test concepts for over-the-air (OTA) antenna measurements.
The CMW500 wideband radio communication tester. (Photo: Rohde & Schwarz)
The two companies integrate the R&S LBS Server, a software component running on the R&S CMW500 wideband radio communication tester, and the Bluetest OTA test solution for A-GNSS systems based on Bluetest’s RTS65 reverberation chamber and Bluetest’s Flow measurement software.
In the test setup, the R&S LBS Server controls the Rohde & Schwarz base-station simulator R&S CMW500 for LTE, WCDMA and GSM, and uses the R&S SMBV100B vector signal generator for simulation of GNSS and MBS signals.
A simple and straightforward upgrade of the setup for 5G will be available soon, making sure that investments are protected and most relevant standards can be tested with the same system.
The R&S LBS Server is an essential part of the R&S TS8991 OTA Performance Test System. This cooperation between Rohde & Schwarz and Bluetest marks the first time that the R&S LBS Server, used here as a software tool on R&S CMW500, is available also for third parties.
“We are delighted to collaborate with Bluetest to contribute with our test and measurement expertise to OTA 4G/3G/GSM and GNSS technology development,” said Alexander Pabst, vice president, Systems and Projects at Rohde & Schwarz. “With a strong global footprint for location based services LBS and close cooperation with partners, Rohde & Schwarz is committed to accompanying the evolution path from OTA testing for GPS, GLONASS, BeiDou and Galileo with innovative test and measurement solutions.”
“The addition of A-GNSS measurements means that the full range of wireless technology in a modern cellular device can be verified with just one test solution,” said Robert Rehammar, Bluetest CTO. “Bluetest has enjoyed the close cooperation with Rohde & Schwarz on this project, leading to a very strong joint solution and customer offering.”
R&S TS8991 Wireless Performance Test Chamber.(PRNewsFoto/Rohde & Schwarz)
PCTEST Engineering Laboratory, an accredited testing laboratory for wireless testing and certification, has expanded its over-the-air (OTA) conformance testing capabilities with the purchase of a CTIA-compliant R&S TS8991 Wireless Performance Test Chamber (WPTC) from Rohde & Schwarz.
The R&S TS8991 OTA Test System is configured with hardware and software extensions for legacy and LTE A-GPS, a R&S ZND vector network analyzer for passive antenna measurements and faster system calibrations, and a second antenna boom with additional R&S NRP power sensors for faster total radiated power (TRP) measurements. The entire system is controlled via R&S AMS32 wireless performance software.
As the number of technologies and the variety of mobile devices continue to increase, the ability to verify a device’s radiated performance is becoming more important to ensure end-user quality of experience. For 4G/LTE, there are major developments involving the Internet of Things, machine-to-machine communication, LTE at 5GHz (LTE-U), assisted global navigation satellite system (A-GNSS), and carrier aggregation, which are driving the need for improved as well as additional OTA tests required for both carrier acceptance and industry conformance test plans.
“As wireless devices become more specialized and continue to push the boundaries of transmission efficiency, the ability to fully characterize a device in an over-the-air environment is becoming more critical,” said Randy Ortanez, president of PCTEST Lab. “Every day we are seeing the acceptance bar being raised and more test cases defined from operators and standard bodies such as CTIA and 3GPP. To meet these growing demands, we are very pleased to be working with our partner Rohde & Schwarz who is able to deliver and support a complete turn-key solution for our OTA testing needs.”
PCTEST is exhibiting in the Test Pavilion of Hall C, Booth 5159, at the CTIA Super Mobility trade show, taking place this week at the Sands EXPO in Las Vegas. Rohde & Schwarz is exhibiting in Booth 3249.
Sessions on indoor navigation and a keynote from Google at February’s International Navigation Conference (INC15), organised by the Royal Institute of Navigation, addressed the revised E911 positioning requirements in the United States, and flowed over into speculation about E112 emergency calling parameters in Europe’s near future.
According to the 2014 U.S. Federal Communications Commission report, 75 percent of 911 calls now come from mobile phones, more than half of those originate indoors, and around 1 percent of emergency calls contain no location information from the caller (due to distress, confusion, language issues, illness, and so on). The report estimates 10,000 deaths per year in the United States might have been avoided if a landline had been used instead, since location information for landlines can be provided confidently.
Discussion in the breaks of INC highlighted a misunderstanding amongst some parties that E911 mandates the use of GPS for position location determination. In fact,E911 does not mandate any specific technology; it specifies performance criteria in terms of accuracy that must be met. The recently revised performance criteria include indoor performance, and some of the technology discussed at the INC is able to meet these requirements without using GNSS at all.
This could be troublesome for Europe, which is looking at the imposition of Galileo as part of an A-GNSS technology push for the E112 application. The real problems, discussed during INC and in European consultation processes with safety of life services such as E112, are:
the accuracy of the position derived by the device and/or network, and
the timeliness of the delivery of that position to the Public Service Answering Point (PSAP).
The E911 directives address these points directly, and the infrastructure in the cellular networks is in place. Does simply implementing a Galileo capability into a European mobile device solve these problems?
In many outdoor cases, implementing Galileo can bring benefits, including signal diversity. And of course the E112 proposal is greater than just “adding Galileo.” It does address the second problem of timeliness of delivery and data transfer, but there are significant infrastructure upgrades required across Europe for the provision of this location data to the PSAPs.
What the E112 processes do not currently do is specify performance criteria for the position location accuracy. This means that the position estimate provided under E112 is likely to be a cell-ID fix, with an accuracy ranging from hundreds of meters to dozens of kilometers.
Galileo on Mobiles. Further discussion during the conference delved into the realms of the specifics of implementing A-GNSS, including Galileo, onto a mobile device. Conversations centered around if any future E911 or E112 positioning capability would be aligned around a single-chip solution as generally currently deployed on a device, or if some of the functions will be moved up the stack into the operating system (OS) of the device, into software.
Most opinions were against this latter concept, and a panel at the ION GNSS+ last year in Florida concluded the same thing. However, questions were asked about some ideas relating to identifying the emergency number at the time of dialing and then starting the position location determination functions in readiness for the need to provide the device location. This addresses the first bullet point earlier, the accuracy of the position derived by the device and/or network. If this is carried out in the OS or software layers, vulnerability of the system will be increased overall as the OS of a mobile device is a target for the cyber criminal community.
A robust software-based solution is, however, being rolled out in the United Kingdom in the form of eSMS, bringing mobile operators, government and handset vendors together to provide location data via SMS to the PSAP. The advantage of this approach is that no new standards or major infrastructure changes are required, and the time to implement is small.
Further discussions established that future chipsets are likely to use whatever GNSS signals are available, regardless of whether they are GPS, Galileo, GLONASS, Beidou and so on. This, coupled with new signal processing techniques (single-frequency observable for example), increasing sensor clustering on devices, and user demand for services, may make the use of a specific GNSS system above others somewhat redundant. Certainly picking up on a point made by Chandu Thota from Google, GNSS is “not relevant” for their indoor positioning solutions, and technologies they are working on, in both hardware and mapping improvements, are looking at meeting indoor accuracy requirements down to a target requirement of 1 meter, without GNSS.
Taking these points into account, questions were asked from the floor of the conference about the legal position of the EC mandating Galileo as a positioning method as well as the willingness of the global mobile chipset and device industry to be told what to do. Perhaps specifying strong performance criteria, as in the United States, is the way forward to “reboot” the European E112 system. No one disputes that a properly functioning E112 is a life saver and a good thing to do; however, the points discussed here detail some of the concerns expressed during and after hours at INC15.
In February 2015, the Royal Institute of Navigation hosted the International Navigation Conference in Manchester, UK. Keynotes at this well-attended conference included Harold Martin, director of the GPS Coordination Office; Gian Gherardo Calini, the head of market development at the European GNSS Agency; Todd Humphreys from the University of Texas; Chandu Thota from Google; and others. The conference covered multiple technology tracks including indoor navigation, autonomy, quantum technology and the resilience of GNSS systems.
Andy Proctor is lead technologist for satellite navigation at InnovateUK, the UK’s innovation agency. He acknowledges Ramsey Faragher, Cambridge University, for help in the preparation of this article.
LTE brings a promise of improved location accuracy with new positioning technologies and their integration using hybrid techniques. Although established technologies such as A-GNSS (A-GPS and A-GLONASS) provides excellent performance in environments with a clear view of the sky, performance is often poor indoors, where detection of satellite signals is limited. In LTE, current standards support Observed Time Difference of Arrival (OTDOA), an advanced cellular positioning technology that can augment A-GNSS and provide a more accurate location fix for indoor scenarios.
With large-scale VoLTE rollouts imminent, leading operators are confronted with the need for extensive and complex testing of LTE positioning technologies to ensure VoLTE E911 works well from day one. Additionally, the FCC, whose current E911 regulations apply only to outdoor environments, has proposed stringent indoor requirements as a response to increased mobile usage for emergency calls and lack of accurate positioning information on calls that originate indoors.
“Roughly 70 percent of 911 calls are placed from wireless phones and a majority of these calls originate indoors, so there is a real urgency in providing better location accuracy for mobile users, wherever they are calling from,” said Nigel Wright, vice president at Spirent Communications. “Spirent is currently working with all the key industry players to evaluate OTDOA and its integration with other positioning technologies, and to enable operators to meet the location requirements for VoLTE E911 and the evolving FCC requirements.”
Spirent 8100 LTS has won widespread acceptance as the leading platform for location testing in the wireless industry, and with this latest capability is now able to support OTDOA Position Calculation Function (PCF). Minimum performance testing for OTDOA looks only at the raw measurements from the device, whereas use of OTDOA PCF enables full verification of a device’s position accuracy performance. Recognizing its importance, leading carriers have established their own OTDOA positioning performance requirements beyond bare minimum standards. Ensuring that devices fully meet these requirements as well as the evolving FCC regulations for E911 requires comprehensive testing.
Tri-Band Multi-Constellation GNSS in Smartphones and Tablets
This article presents a single-chip BeiDou/Galileo/GLONASS/
GPS/QZSS/SBAS architecture for use in cell phones and tablets. The authors explain the advantages to end users of multiple constellations. They also examine the details of system interchangeability, multi-system issues, and how assisted-GNSS data operates with all constellations, including BeiDou.
By Frank van Diggelen and Kathy Tan
With GPS, GLONASS, SBAS, BeiDou, QZSS, and Galileo there are over eighty operational satellites. Why do we need all these satellites in the first place? The answer is simple: in urban environments we want a few (six to eight) good satellites with an unobstructed line-of-sight (LoS) to the receiver and good horizontal dilution of precision (HDOP). In order to achieve this, we need many more satellites in space than any single constellation. In this article, we address the following issues.
Receiver intersystem RF bias with a tri-band front-end. BeiDou uses a different RF section than GPS/Galileo/QZSS/SBAS and GLONASS. As a result, there is a receiver intersystem bias between BeiDou and each of these other systems—not just because BeiDou is on a different frequency, but because of the different RF path through the receiver. We explain how this bias is calibrated and removed.
In the space segment there are intersystem biases primarily caused by differences in time standards. We discuss time management and show how the different systems can be made interoperable.
BeiDou Assistance. In order to realize the benefits mentioned, we need infrastructure deployment for BeiDou assistance in accordance with 3GPP standards. We will discuss what is available, and what is left to do.
Coverage outside of China. Europeans can see more BeiDou satellites than Galileos. At the time of writing (March 2014) they could see approximately twice as many. Thus, when used in a multi-GNSS receiver, BeiDou is far from being just a regional system. We will provide coverage analysis, and live-test data, including a focus on Europe.
Finally, we will demonstrate all of the above in practice, explaining and showing how interchangeability is achieved, and where first fixes can be computed with no more than one of each satellite type.
Figure 1 illustrates the point referenced at the beginning, that we need many more satellites in space than any single constellation.
All of the lines in Figure 1 show signals that were actively tracked by the receiver at the position shown on the right. The orange lines are to satellites that are blocked, but the reflected signal is tracked. We do not want to use these measurements if we can help it, so we need many satellites to provide enough LoS signals.
Let’s look at the HDOP of the LoS signals. In this example, the HDOP for the three LoS GPS satellites was 50. For the three LoS GLONASS satellites, the HDOP was 45. However, with the combined GNSS constellation, the HDOP for the six LoS satellites was 2.2. In other words, we expect about a 20x accuracy improvement by using the combined constellation.
There are many places and times in cities where we see just one or two direct LoS signals from a particular constellation, and we need more than just GPS and GLONASS to get the desired number of good signals, thus explaining the desire and need for all available constellations.
We’ll now look at the coverage provided by BeiDou2, which has five Geostationary satellites (GEOs), five inclined Geosynchronous satellites (GSOs), and four Medium Earth Orbit satellites (MEOs). With this 14-satellite constellation, the global coverage is as shown in Figure 2. This figure shows the percentage of time in a day that four or more BeiDou satellites are visible above a 10-degree mask angle. In the Asia-Pacific region, where the GEOs and GSOs are positioned, the coverage is predictably 100 percent. In fact, there are seven or eight BeiDou satellites visible in much of this region most of the time.
Figure 2. BeiDou2 global coverage.
As shown in Figure 3, outside the Asia-Pacific region the coverage is also interesting. We see that at least four BeiDou satellites are available over Europe about half of the time. This is quite significant given the previous discussion; even one or two extra satellites can make all the difference in an urban environment. Another notable fact is that, for now at least, Europe can see more BeiDou than Galileo satellites.
Figure 3. BeiDou coverage over Europe. The different colors show the percent of time that four or more BeiDou satellites are visible above a 10° mask angle.
Technical Requirements
There are five significant technical requirements that we want to satisfy when creating a multi-GNSS receiver for consumer applications:
Three Separate RF Paths. To acquire and track all of the satellites already mentioned, we need three separate RF paths. Details follow in Section 3 (Front-End Architecture).
Search and Track capability for all visible GNSS satellites. The receiver must have the ability to search a very large number of code-frequency bins at once.
Host-Based. As much as possible, we want to make use of the host application processor (AP) and memory. This allows for tight integration with assistance data (which is coming from the host), other sensors, and other wireless data (such as Wi-Fi and Bluetooth for indoor locations). A host-based architecture also keeps size and cost as low as possible.
With Host-Offload. A significant trend in location applications is the need for “always-on low power” location. The host AP cannot be used for continuous position updates, since it draws too much power. So, while we want host-based location when the host AP is active (such as when navigating with turn-by-turn directions and a map), we also want a host-offload capability so that the GNSS chip can compute positions internally while the host is asleep.
Interchangeability. The ultimate requirement for multi-system GNSS is the ability to use any combinations of satellites as if they were all in the same constellation. This is summarized as “any four satellites will do.”
Front-End Architecture
From a cell phone/tablet perspective, the signals in space are all in the L1 band, with frequencies as shown in Figure 4. The key architecture feature of the GNSS front-end is that it should have three separate RF chains for the three separate frequencies-of-interest; see Figure 5.
Figure 4. Frequencies-of-interest for GNSS in cell phones.Figure 5. Front-end architecture showing three RF chains.
Baseband Architecture
The preferred architecture of a chip, as shown in Figure 6, is host-based to take advantage of the large host CPU when it is active. When the host CPU is asleep, a small, low-power, on-chip CPU is leveraged for background “always on” location. This enables applications such as geofencing to run without significantly reducing battery life.
Figure 6. Block diagram of the preferred architecture, showing a host-based configuration that includes a host-offload capability for geofencing and position caching on-chip when the host is asleep.
When the host is active, such as when you are actively using the phone for turn-by-turn navigation, the host AP is on and we want to make as much use as possible of the host AP and memory. This allows for tight integration with assistance data coming from the host, other sensors, and other wireless data (such as Wi-Fi and Bluetooth for indoor locations). A host-based architecture also keeps size and cost as low as possible, even with host-offload capability, which adds very little to the size of the chip.
Receiver Intersystem RF Biases
With the three different bands of frequencies, we will get RF group delays in the receiver front-end. These must be calibrated out by the receiver’s designer as part of the chip’s system design. If the group delay between BeiDou and GPS is not calibrated, it will lead to approximately three meters of bias between the two systems (Figure 7). Once it is calibrated, there is essentially no bias.
Figure 7. L1 frequency spectrum for BeiDou2, GPS, Galileo, QZSS, SBAS, and GLONASS.
Satellite Intersystem Biases
Different GNSS constellations run off their own master clocks; referenced to different realizations of UTC. GPS is referenced to UTC (USNO), QZSS is referenced to UTC (NICT), GLONASS to UTC (SU), BeiDou to UTC (NTSC), and Galileo to UTC (INRIM). GLONASS UTC (SU) differs from the others by 3 hours.
Furthermore, different systems treat leap seconds differently. This is indicated by the red arrows in the clocks in FIGURE 8. GPS, QZSS, BeiDou and Galileo system times are continuous and ignore leap seconds. Thus, each system time is ahead of UTC by a number of leap seconds. GPS time started in 1980 in synch with UTC; there have been 16 leap seconds since, so now GPS is 16 seconds ahead of UTC. QZSS and Galileo system times were started in synch with GPS. BeiDou system time was started in 2006 in synch with UTC; there have been 2 leap seconds since, so now BeiDou is 2 seconds ahead of UTC. GLONASS system time, on the other hand, includes leap seconds.
Apart from this, each of the different realizations of UTC is within several nanoseconds of the others.
To combine measurements from these different systems and avoid any time-induced intersystem biases, we need to resolve the time offsets. Each system transmits the delta-time between its system time and the systems that preceded it, as listed in Figure 8. To combine the systems, we either need to decode these data messages or obtain the delta-time values from Assisted GNSS.
Figure 8. Intersystem time differences and broadcast delta-time values from each system.
Note, however, that in the BeiDou broadcast Nav message the intersystem time-offset data values are all set to zero (even though the true offsets are not zero).
Assisted-GNSS Including BeiDou
Assisted GNSS, or A-GNSS, increases sensitivity and decreases the time-to-first-fix of a receiver by providing assistance data in the form of the receiver’s approximate position, time and frequency, as well as all data that the receiver might decode from the broadcast signals. The assistance data may also include data beyond what is broadcast, in particular, let’s focus on BeiDou time offsets. The BeiDou time offset to the other systems is included in the BeiDou broadcast Nav message as shown in Figure 8; however, at present these data values are all set to zero (even though the true offsets are not zero). Thus, in order to get these offsets and integrate BeiDou properly into a combined GNSS system, one must compute the offsets at a reference station and provide them as part of the assistance data, as shown in Figure 9.
Figure 9. A-GNSS provides broadcast satellite data over some other wireless network, as well as time-offsets between the different pairs of systems.
Commercial Implementation
The preferred architecture described in this article has been implemented in a commercial GNSS receiver that is now available for commercial host-based products, such as cell phones and tablets. The chip, Broadcom’s BCM47531, is the first consumer GNSS chip with a tri-band front-end capable of acquiring and tracking satellites from GPS, SBAS, QZSS, GLONASS, and BeiDou constellations, simultaneously; and operating in host-based mode for navigation and in host-offload mode for Always-On location.
Broadcom has collaborated with leading smartphone manufacturers to launch the first wave of BeiDou enhanced consumer smartphones. Figure 10 shows one of these smartphones being tested in Europe. Note the number of BeiDou satellites in view. As predicted by the availability plots shown earlier, there are many BeiDou satellites in view (in this case, six).
Figure 10. GPS/GLONASS phone and GPS/GLONASS/BeiDou phone being tested in Warsaw, Poland. Note the six BeiDou satellites (red) that are seen and tracked by the BeiDou phone.
Interchangeability: Any Four
Now that we have addressed all of the major issues related to integrating different GNSS systems (in particular BeiDou), we can demonstrate the payoff.This is the achievement of interchangeability, where any GNSS satellites can be used together, as if they all belong to a single constellation. Figures 11 and 12 show assisted cold starts, where first fixes are obtained with no prior knowledge other than that provided by A-GNSS data. In each case, we show a different combination of satellites; including one satellite from each of four different constellations, and all four from BeiDou.
Figure 11. Interchangeability: Position fix with 1 GPS satellite, 1 GLONASS, 1 QZSS, and 1 BeiDou. The receiver is in Perth, Australia, where all of these constellations can be seen.Figure 12. Interchangeability: Assisted cold start, first fixes. Blue numbers show the satellites used in the position fix (top: two GPS and two BeiDou; middle: one GPS, one GLONASS, and two BeiDou; and bottom: four BeiDou only). The receiver is in San Jose, California, where four BeiDou satellites can be seen some of the time (some of the BeiDou GSOs can be seen and all the BeiDou MEOs can be seen for a few hours each day).
Multi-Constellation Robustness
While this article was being edited, the GLONASS system provided us with the most dramatic demonstration yet of the need for, and benefits of, multi-constellation receivers. On April 2, 2014, the GLONASS system failed spectacularly for a period of 11 hours. Receivers that used GPS and GLONASS had very large position errors, or no positions at all. While the receiver discussed in this article, the BCM47531, operated seamlessly. This receiver tracked GPS, GLONASS, QZSS and BeiDou satellites, correctly identified the faulty GLONASS satellites, and automatically stopped using them.
The details of the incident are as follows: The GLONASS control system uploaded incorrect orbit data to several satellites. When receivers used these satellites they had position errors of hundreds of meters, or no positions at all. At that time, the BCM47531 was being tested alongside a GPS/GLONASS receiver, and we have the data to show what happened. The receiver using only GPS/GLONASS suffered position errors of ten thousand meters, and long periods with no position at all; at the same time the multi-constellation receiver produced continual positions with normal accuracy. Figure 13 shows the test data — the left most image shows the route being driven, the middle image shows the data from the GPS/GLONASS receiver, and the right image shows the data from the BCM47531 multi-GNSS receiver. Figure 14 shows the details of the multi-GNSS receiver, you can see that no GLONASS satellites are being used.
FIGURE 13. Side-by-side tests of GPS/GLONASS receiver and multi-constellation receiver during the GLONASS incident of April 2, 2014. The GPS/GLONASS receiver produced errors of ten thousand meters and long periods with no position at all, while the multi-constellation BCM47531 operated seamlessly.FIGURE 14. Detail from the multi-constellation receiver when there is a problem with some satellites. The errors are recognized automatically by algorithms comparing the measurements to redundant measurements from the extra constellations, and the erroneous signals are not used.
This incident may raise the question: Why use GLONASS at all, why not just GPS? The answer is that in urban canyons, such as where this test was done, GPS alone does not have enough satellites to give the performance now expected in consumer products — for the reasons explained in the beginning of this article. Also, GPS, although it has been more reliable than GLONASS, is not immune to failures or jamming itself. The lesson of this incident is that reliability and accuracy comes from the combination of all the available constellations, with a receiver that can use the signals interchangeably.
Conclusion
We have shown the preferred architecture for a consumer GNSS receiver that includes all of the available constellations. We have addressed the major requirements of such a receiver for the consumer market, in particular, for cell phones and tablets. A receiver that meets these requirements is now available, the Broadcom BCM47531, has been designed into a new generation cell phones and tablets for 2014. Finally, we have shown how, with this receiver, the ultimate GNSS goal of interchangeability can be achieved.
Frank van Diggelen is vice president of technology at Broadcom Corporation, a consulting professor at Stanford University, and inventor of coarse-time GNSS navigation, co-inventor of Long Term Orbits for A-GNSS, and author of A-GPS: Assisted GPS, GNSS, and SBAS.
Kathy Tan is a senior principal engineer at Broadcom Corporation. She has worked on GNSS development and Assisted GNSS for Ashtech, Magellan, Global Locate and Broadcom. She received her MS and BS in electrical engineering from Fudan University, China.
Rx Networks, Inc., a mobile location technology and services company, has completed the upgrade of its GPStream Global Reference Network (GRN) to include the BeiDou constellation. A top-tier GNSS semiconductor vendor has already incorporated this new feature so its platform can take advantage of the extra satellites now available in the BeiDou constellation, the company said.
Global real-time assistance and high-accuracy long-term orbit and clock prediction products are now uniformly available across the GPS, GLONASS and BeiDou constellations. In the second quarter of 2014, BeiDou support will also extend to GPStream PGPS — Rx Networks’ popular synthetic A-GNSS software that has been deployed in more than 100 million smartphones and personal navigation devices worldwide.
In commercial service since 2006, the GPStream GRN is a collection of 26 highly reliable earth stations deployed in 21 countries. It forms the foundation underneath many of Rx Networks’ products, on which nearly a billion devices rely for their GNSS performance. The network is highly redundant and, combined with a carrier-grade service delivery network, is provided with a 99.999 percent service-level availability (SLA). A further upgrade, to support the European-run Galileo constellation, will be available later this year.
From network operators’ commercial and E911 location servers to GNSS chipset vendors and device OEMs, the addition of BeiDou means faster and higher availability GNSS location fixes.
“The addition of BeiDou to our existing GPStream GRN service meant a complete overhaul of our reference network and service delivery architecture while maintaining the 99.999 percent SLA we’re well known for,” commented Guylain Roy-MacHabee, CEO of Rx Networks. “As multi-GNSS chipsets come to market, there is commensurate requirement for a uniform, reliable and device-independent assistance data service like our GPStream GRN.”
On October 2, NextNav announced that Broadcom Corporation acquired a commercial license to NextNav’s Metropolitan Beacon System (MBS) technology, a so-called terrestrial constellation that brings GNSS-like performance to indoor and urban environments where satellite-based positioning is either unavailable or significantly degraded.
The agreement enables Broadcom to integrate NextNav’s location technology into its mass-market GNSS connectivity and mobility platforms, used primarily in cell phones and tablets.
NextNav President and Founder Ganesh Pattabiraman characterized the deal in a conversation with GPS World: “This is a commercial license to a Tier 1 chipset provider, whose products are in a vast number of smart and feature phones in the country. The partnership enables our technology in a low-cost, high-volume form factor. This is important for us since we don’t make chips. We rely on partners such as Broadcom. This is the first of many such agreements; we’ll have more through the year.”
Most wireless companies have a mobility group addressing cellular modems, the central clearinghouse for so-called connectivity: the combination of Wi-Fi, Bluetooth, GNSS, and other technologies. Standard assisted GNSS (A-GNSS) packages to date in such cases generally consist of ephemeris from all GNSS satellite constellations supported by the wireless company’s chips, cell ID and Wi-Fi ID from base-station databases, and additional proprietary assistance mechanisms.
The NextNav MBS concept shares many operating principles with GNSS satellite constellations, but because the NextNav beacons are installed terrestrially instead of in space, they transmit sufficient signal strength for reliable reception indoors and in urban canyons where a clear view of the sky is unavailable. MBS is deployed much like a cellular network, to provide consistent indoor positioning to every building within a covered metropolitan area. MBS offers both accurate horizontal positioning and highly accurate altitude information, a particularly important capability for emergency responders in urban and indoor areas where GNSS systems tend to be most challenged.
NextNav built its MBS network across forty large U.S. markets (see list at end of story) with its own Federal Communications Commission (FCC) licensed spectrum. “We bring more a managed network providing consistency and reliability of position information,” continued Pattabiraman. “Also the vertical component that other systems do not provide.” He characterized Wi-Fi, for example, as “an unmanaged network,” subject to frequent changes without a centralized and continually updated source of certified data.
NextNav location performance was recently highlighted in side-by-side technology tests conducted by the Communications Security, Reliability, and Interoperability Council (CSRIC) of the FCC, and published in March of this year; see reportage and analysis of these tests at The Inner Edge: Who Holds the Key to Indoor Nav?
The trial compared the performance of location systems across urban, suburban, and rural areas in the San Francisco Bay Area for determining the location of callers during emergency calls (E911), a critical case for mobile-phone users. NextNav was the only technology capable of reporting a valid height or altitude estimate, enabling floor-level positioning. NextNav’s horizontal accuracy results also reduced first-responder “search rings” by 90 percent over its nearest competitor.
Don Fuchs, director of business development at Broadcom, added “Nextnav is a metropolitan area location system, which is typically a wider area than that covered by Wi-Fi. Wireless emergency assistance calling (E911) needs a wider venue covered. And across 40 metro areas. Nextnav is wide area, while Wi-Fi is essentially local area.”
Pattabiraman said that in a typical metro area, NextNav’s terrestrial constellation of beacons is deployed for maximum coverage and minimum GDOP, and is not constrained by capacity like a cellular network. He stated that the San Francisco Bay area covered by NextNav extends to 900 square miles, from South San Jose into Marin County and East Bay. “With a fraction of the beacons required for cellular coverage in the same area, which would be in the neighborhood of a few thousand antenna installations, our deploy and operating costs are much less. Less than 20 percent of that for a cellular network.”
In comparison with Locata, another recently rolled out terrestrial constellation designed to fill GNSS gaps, Pattabiraman said, “Locata and NextNav are two entirely different systems serving different needs. We are in the mass-market commercial cell phone wide area use case, filing that gap, providing 5–10 meter accuracy, with vertical as a critical component, and full market coverage.Locata covers centimeter-level precision application in localized environments. The two companies could both eventually get to the other side [of the market-sector spectrum], but currently each of us is focused on the particular requirements of our designated market areas.Also, we operate with licensed spectrum versus the Locata operation in 2.4 GHz unlicensed.”
“At the highest level, they are both multi-lateration systems. Time of arrival, time difference of arrival. We arrive at our core synchronization via GPS, which has its own synchronization, but we’ve got our IP on top of that to improve it. Each beacon is autonomous. You can drop it anywhere with a clear view of the sky, and it is synchronized to the rest of the network, it has its own self-synchronizing mechanisms. Locata is a synchronized network.
“Another way of looking at it, they have a replacement for GPS. We do more complementing for GPS, we count on GPS being there.”
Broadcom’s Fuchs added, “From the perspective of a company designing GPS and GNSS client-side semiconductors, we view NextNav as a terrestrial constellation, no more difficult or challenging than adding support for any new or legacy constellation like BeiDou or GLONASS. We see this integration as being very straightforward, we have lots of IP in the area of signal processing, these sort of signals, this sort of positioning algorithm. We add NextNav as a secondary technology for challenging urban conditions. We view this as a piece of location technology to develop and integrate as the market demands.
“In six years at Broadcom and seven before that at Global Locate (acquired by Broadcom in 2007), we have a history of turning support like this, we’ve been able to do this very quickly. Depending on market demand, in less than a year. I can’t lay out a roadmap at this point. We expect to see market demand for this, certainly expect regulatory demand. We wanted to get to the point where we can react to that in less than a year. That was the motivation to get this agreement into place, and we are now positioned.”
“We all operate under standard operating environments as specified by the FCC. We’re metro-wide just like paging towers or broadcast TV,” continued Pattabiraman. “We’re not necessarily doing anything different as regards the indoor environment. We’re not adding anything additional to the noise spectrum or floors. Our maximum transmission is 30 watts, very small compared to cell transmission in kilowatts. It is bits per second by the time it hits the receiver. Because it’s calibration for navigation, the network design is optimized for location. We take into account GDOP and coverage, maximizing the latter, minimize the former. There is a very low throughput. It’s a tradeoff between power and coding. We code the heck out of this thing. We just new a few bits to get our information through, not like cellular that needs to get megabits through.”
As to any data or issues about the human health impacts of an RF-rich indoor environment, Pattabiraman concluded, “There’s none of this concern about power into your head. We transmit only at the tower, receive only at the user. It is very, very heavily coded, like GPS, and very low-powered. It’s not even close [to cell transmission power]. We’re a feather, they’re a hammer.”
List of NextNav Covered Metro Areas
NextNav characterizes San Francisco as built to “commercial grade” and the other markets as “Initial Builds.”
Boston-Worcester-Lawrence, ME
Syracuse, NY-PA
New York-North New Jersey, NY-NJ
Philadelphia-Wilmington-Atlantic City, PA-NJ-DE-MD
Spirent now offers A-GNSS record and playback capabilities for mobile device testing.
Spirent Communications today announced the availability of carrier-approved Assisted GNSS Record and Playback capabilities on its Hybrid Location Technology Solution (HLTS). This new A-GNSS Record and Playback capability provides unprecedented realism and repeatability by recording GNSS signals in the field and delivering synchronized assistance data over a radio access interface to test the A-GNSS positioning performance of mobile devices in the lab.
“With user location playing a key role in most smartphone services and applications, A-GNSS positioning performance greatly influences the end-user experience,” said Nigel Wright, vice president of wireless, Spirent Communications. “This new A-GNSS Record and Playback solution enables device manufacturers and network operators, as well as chipset and technology vendors, to accurately test this essential technology using real-world field conditions. This helps ensure high quality LBS and emergency service performance for every mobile subscriber.”
Combining GNSS signals from multiple satellite positioning systems (such as GPS and GLONASS) with assistance data delivered by the network to the device, A-GNSS is regarded as the most universal and precise positioning technology. As such, it is used in mobile devices to support the location information required by commercial services, social media and emergency services such as E911.
Although established A-GNSS simulation tools play an important role in generating repeatable and reliable controlled environments in the lab, they can have limitations when it comes to representing the full range of challenging conditions experienced by mobile users on live networks. Spirent’s A-GNSS Record and Playback addresses these limitations by capturing conditions in the field and playing them back in a reliable and repeatable lab environment. This helps to reduce device time to market and control testing cost by reducing the need for extensive field testing.
Spirent HLTS is recognized by the industry for its unique capabilities that span a wide range of test requirements from early R&D phases to mobile device acceptance. The HLTS now incorporates Spirent’s GSS6400 GNSS Record and Playback System (RPS), together with patent-pending SimHybrid software that generates and delivers the correct assistance data, synchronized with the recorded GNSS signals.
