spirent.com

Testing Real-World A-GPS Performance - The Elements of A-GNSS Simulation - Part 3

Our last posting [Weighing the Options – Three Approaches for Testing Real-World A-GPS Performance] discussed approaches for testing real-world A-GPS performance, ending with a recommendation for a lab-based simulation approach. With its repeatable environment, easy setup, fast test times, automated result collection and enhanced handset performance benchmarking capabilities, lab simulation certainly sounds like a great idea, right? Well actually, of the three approaches we discussed, lab simulation is not the most widely used. Why is this?

For starters, real-world lab simulation is really hard to do correctly. Accurately simulating a handful of moving satellites transmitting wirelessly to a moving receiver while signals are distorted, reflected, and obstructed by moving objects and changing atmospheric conditions is enormously complex. In fact, it has been Spirent’s business for the past 20 years or so to do exactly this, and we’ve struggled with it too!

Nevertheless, if you accept that lab simulation needs to be a “good enough”—not a perfect—representation of the real world, then it’s possible to make lab simulation an essential part of A-GNSS design and verification. For the purpose of this discussion, we’ll define “good enough” to mean:

  • Simulation of all elements that have a noticeable impact on A-GNSS performance in the lab.
  • Correlation of real-world performance with the analogous lab simulation scenarios. The results do not have to be identical to be useful. However, a device that performs relatively well in the real world must show the same relative performance in the lab, and vice versa.

But even “good enough” real-world lab simulation is still very difficult to achieve, and we have spent countless hours perfecting our approach. Our goal is to enable more devices to be tested in this way so that the overall cost of A-GNSS design and verification can be reduced, while device performance is improved.

This post summarizes the essential elements of A-GNSS simulation. Further posts will discuss key elements in more detail. Incidentally, notice that we’ve replaced the term A-GPS from earlier posts with A-GNSS, since there’s an industry movement toward Multi-GNSS devices that support A-GLONASS in addition to GPS. In the future, Multi-GNSS support could also mean Galileo, QZSS or other planned Global Navigation Satellite Systems.

So without further ado, here are the Elements of A-GNSS Simulation (broken down into four groups):

1. Satellite Simulation
Simulation of the GNSS constellation in relation to the A-GNSS receiver, allowing for the simulation of moving satellites and a moving receiver. The key elements are:

  • Location – The physical location of the receiver, expressed in terms of latitude, longitude and altitude. If the receiver is in motion, a route needs to be specified.
  • Date, time and length of simulation – Directly related to the visibility of satellites for a given location. The date and time can be specified to be any point in the past, present, or future.
  • Satellite orbits – The actual satellites available in the sky for a given date, time and location. They can be obtained from YUMA data, maintained by the US Navy.
  • GNSS Satellite Constellations – The satellite constellations being simulated. Although GPS is still by far the most common, GLONASS is gaining momentum and others are coming soon, including Galileo and QZSS.

Satellite simulation uses a combination of hardware and software. The hardware must allow for adequate simulation of satellite channels (at least 8-10) as well as flexibility in configuring power levels. The software must allow for complete control of the characteristics mentioned above, as well as for the introduction of errors and perturbations (if they’re needed.)

2. Environmental and Device Antenna Characteristics

  • GNSS signals are transmitted wirelessly and are therefore subject to many environmental and device antenna factors. These elements are responsible for the majority of performance variations from device to device. Since they are also the most difficult to simulate correctly, they need special attention:
  • Multipath/Fading emulation – A suitable multipath model must be created, based on the geographic elements of the given location, such as buildings, trees, rocks, etc.
  • Atmospheric modeling – Simulation of atmospheric conditions is required to test the GNSS system’s ability to compensate for resultant navigation error.
  • Signal obscuration – The attenuating effect of physical elements, such as buildings and trees, on incoming GNSS signals from the sky must be accounted for.
  • Device Antenna Pattern – As more and more capability gets crammed into shrinking mobile devices, the GNSS antenna performance becomes a critical factor. To simulate real-world performance in the lab, the antenna pattern must be characterized and simulated.

3. Network Simulation

For A-GNSS, it is also necessary to simulate the cellular network and the assistance data that it provides to the mobile device. The main elements are:

  • Flexible Simulation – The network simulator must be capable of supporting all the 2G and 3G cellular technologies required by the device under test, whether GSM/GPRS, UMTS and/or CDMA. The minimum requirements are typically:
    • Support for 3G and 2G location protocols (e.g. RRC/RRLP)
    • Support for common signaling procedures (such as voice calls, supplementary services, etc)
    • Flexibility to modify key protocol information elements, such as desired horizontal accuracy, desired response time, etc.
    • SMLC/PDE Simulation – Required for control of assistance data delivery and position calculation, which are cornerstones of A-GNSS. It is important that this simulation be flexible so that the configuration can be aligned as closely as possible with the real network.

    4. Automation Software

    Software which ties everything together and controls the test settings, procedure, collection and organization of data, and presentation of results.

    • Simulation Parameters – Easy configuration of key parameters of the simulation components mentioned above. May include:
      • Delivery of assistance data
      • Specifying initial location
      • Specifying the number of measurements
      • Protocol and call flow selection.
      • Test Scenario – Determines the timing and flow of test execution. A properly-designed test scenario should be able to replicate real-world scenarios much faster than is possible with field test or record-and-playback approaches.
      • Test Results – Includes analysis that yields common metrics and KPIs used to assess the performance of A-GNSS devices, as well as detailed protocol logs and positioning data:
        • Sigma 1 & 2 calculations for horizontal error
        • Yield calculations
        • Time to first fix (TTFF)
        • Graphical representation of data, including CDF, PDF, etc.

        We hope you find the Elements of A-GNSS Simulation useful. This is something that Spirent continues to refine and perfect—feedback is always welcome. Please check back for Part 4 of this series where we will explore these elements in more detail.

         
        comments powered by Disqus
        × Spirent.com uses cookies to enhance and streamline your experience. By continuing to browse our site, you are agreeing to the use of cookies.