BeiDou-2 Is Born
The year before the main release, China surprised the global community when it published just a test version of the promised ICD for the BeiDou-2 B1 open signal. In this document, the modulation scheme for the signal was confirmed and the pseudorandom code generator for the ranging signal was described.
BeiDou-2 Is Born
The year before the main release, China surprised the global community when it published just a test version of the promised ICD for the BeiDou-2 B1 open signal. In this document, the modulation scheme for the signal was confirmed and the pseudorandom code generator for the ranging signal was described.
Crucially, however, there was no detail of the all-important navigation data message. Without a data message it would not be possible to build a receiver that could create a position solution or a simulator capable of generating compatible signals.
Simulators for the Early Adopter
Despite the lack of a full ICD, many of Spirent’s customers, both inside and outside China, were keen to have a simulator to support their early receiver development. So, Spirent embarked on a two-stage approach to providing a usable, pre-release simulator system based on its GSS8000 series of simulators operating with the SimGEN software suite.
The test ICD had almost all the information needed to actually generate a correctly modulated RF signal and a representative satellite constellation.
· 14 satellites – 5 x GEO, 5 x IGSO plus 4 x MEO
· The PRN codes were fully defined.
· The modulation rate of 2.046Mcps BPSK was declared on the centre frequency of 1561.098MHz
· The data rate was 50bps for the MEO and IGSO satellites and 500bps for the GEO
Aside from the lack of data message content, the other crucial piece of information missing was the form of the secondary code apparently applied to only the MEO/IGSO signal. However, observations made by a number of organisations of actual transmissions of the satellites had identified not only the length of this secondary code but also its content, and they had published this data in the industry press. As a result, Spirent was able to take advantage of this in its implementation.
The test ICD did provide an indication that the BeiDou system time was aligned to UTC on January 1, 2006: so, it was reasonable to assume that it would employ a system similar to GPS and Galileo in that it would not add its own leap seconds should UTC do so. That meant that BeiDou time (BDT) should be 2 seconds ahead of UTC and 14 seconds behind GPS.
That just left the data content.
In the early days of Galileo, when data message content was not available, Spirent was able to offer simulator data message content from a file of data symbols provided by the user. This was an obvious facility to include for early BeiDou, particularly for Chinese customers who were themselves in possession of the internal ICD and who could theoretically construct their own messages for use in the simulator. However, it is a non-trivial task to coordinate this data content with the orbital descriptions needed by the simulator to calculate accurate pseudorange — a task not for the uninitiated or faint-hearted.
As an alternative, Spirent also introduced a facility to simply use the well-established legacy GPS data frame structure instead. Satellite observations had already suggested that the BeiDou data message was based on a similar frame structure and with data rates the same as legacy GPS or the GPS Wide Area Augmentation System (WAAS) for the GEOs. This interim implementation would allow a receiver to generate position solutions.
The GSS8800 BeiDou-2 B1/B2 simulator – the world’s first – was subsequently launched mid-2012.
In the autumn of 2012, however, Spirent became aware of a receiver manufacturer who was able to capture navigation data symbols from real BeiDou satellites and who also had the ability to create RINEX-like files for the constellation. A partnership was established that would allow this manufacturer to format the navigation data symbols as transmitted into data files conforming to Spirent’s supported format and for Spirent to be able to supply copies of these files along with compatible RINEX files.
The beauty of this arrangement was that Spirent needed no knowledge of the structure or coding of the data messages themselves, and this meant the process had the blessing of the Chinese BeiDou authorities.
The RINEX files would provide the underlying orbital parameters to calculate satellite position at time of transmission and, hence, calculation of pseudorange. Moreover, provided the navigation data was aligned to the appropriate BDT epoch, the symbols could be simply re-transmitted onto simulated signals. Spirent has dubbed this process as “synthetic replay.” Spirent was able to adapt its existing RINEX import tools for GPS and Galileo to match the relevant BDT time offset.
There were obvious limitations with this approach.
Data could only be gathered from satellites that were in view at the time of the capture, which meant a number of satellites were missing from the RINEX file. This constrained the time of synthetic replay to the time spanned by the capture itself. Also, the synthesized replays would have to remain a relatively close simulated position (latitude, longitude, height) to that of the capturing receiver.
Data symbols could not be changed or edited in a meaningful way without an in-depth knowledge of the data structure; so, if the data contained health flags marking a satellite as unhealthy, these could not be readily made “healthy.” Any errors in symbols would also be faithfully replicated.
Nevertheless, this solution should allow fully dynamic simulated vehicle trajectories, provided the distance travelled was within a few tens of kilometers, outside of which availability would gradually degrade and geometry become less representative.
In practice, this “solution” was a success, albeit a partial one.
It was found that a BeiDou receiver would indeed track and decode data from all the simulated satellites and produce a very accurate position solution using the simulator. However, unlike its performance using GPS satellites, it did not use all the tracked satellites in the position solution and in particular used none of the GEO satellites. When mixed with GPS signals, the same accurate solution was obtained using signals of both types in any combination, as long as they were not BeiDou GEOs.
Study of the decoded ephemeris output from the receiver was able to explain why some of the IGSO satellites were excluded – they were simply marked as “unhealthy” in the original data messages and so the receiver excluded them.
The GEOs, however, remained a puzzle. The expected arrival angle in terms of azimuth and elevation as displayed by the receiver did not match those generated by the simulator; close, but different by up to a degree or so. By excluding all but GEOs from the simulation, it was possible to create a solution with the receiver but one with a very poor accuracy, erroneous by several degrees of longitude and latitude, which could not be attributed to the poor geometry, and with inconsistent pseudoranges.
This suggested that there was something different about the way GEOs defined their ephemerides when compared to the MEO and IGSO satellites – more different than just having a higher data rate. Unfortunately, without a full ICD it was not possible to resolve this apparent anomaly.
Key Chinese customers, however, were more than happy to accept a solution with these characteristics and deficiencies for their early development needs and while the full ICD release to the rest of World was still pending — so, the GSS8800 became a popular item.
Mystery Solved
Within a few days of the release of the English-language ICD for BeiDou B1(I) in December 2012, it became apparent that the suspicion surrounding a different orbital definition for BeiDou GEOs from the usual Earth-centred-Earth-fixed (ECEF) system employed for GPS and Galileo and for the MEOs and IGSOs was confirmed. The equations of motion were indeed different for GEOs as was the definition of some of the Keplerian terms.
The BeiDou GEOs are not true GEOs at all, apparently oscillating around the equatorial plane in a similar fashion to an IGSO with a very low angle of inclination. In fact, the arrangement is even more unusual.
In general, satellite position with respect to the ECEF frame may be calculated from the position in the orbital plane, the inclination of the orbital plane with respect to the X/Y plane of the reference frame, and the rotation of the orbital plane about the Z axis. The position in the orbital plane is first determined from the Keplerian orbit parameters “eccentricity,” “mean anomaly,” “argument of perigee,” and the “semi-major axis.” This is transformed into an intermediate “inertial” frame using the inclination angle of the orbit and the result transformed into the ECEF frame using the current “longitude of the ascending node” — (Ω0).
For GPS orbits and for BeiDou MEOs and IGSOs, the longitude with regard to the ECEF frame of the ascending node is the point at which the orbit crosses the equator when the satellite is moving into the northern hemisphere. If no right ascension rate applies this node remains fixed in the inertial frame. Consequently, the value of this parameter changes continually due to the Earth’s rotation rate (Ωe) by exactly – the value of Ωe.
For Beidou GEOs the orbital data is referenced to a frame which is inclined with respect to the ECEF frame. Presumably this is to avoid ambiguities for orbits with inclination near to zero.
From the form of the transformation matrix given in the ICD, it is evident that this is defined by rotating through –5 degrees about the ECEF X axis. This frame rotates with the Earth (about the ECEF Z axis); so, for an orbit with an inclination of exactly zero the current longitude of the ascending node will always coincide with the X axis. For an orbit with a small inclination angle the longitude of the ascending node will vary slightly in longitude.
In this context, parameters which would be more or less constant in the GPS case (e.g. argument of perigee and Ω0) can change considerably from one hourly data set to the next. It would seem that the satellite Earth-centered inertial (ECI) position and velocity data is transformed into the inclined frame and the resulting values are used in determining the broadcast orbital parameters.
Whilst it is relatively straightforward to amend the relevant calculations themselves to match these definitions, the fact that GEOs are different from the other satellite types introduced unexpected administrative changes for the constellation since satellite type becomes very important — more so than just having different style and rate data messages.
Particularly challenging was determining how to propagate the GEO orbits from one hourly epoch to the next in order to create the hourly data cutovers in long test scenarios lasting several days. The English ICD does not contain any guidance in this area. It was necessary to study the behaviour of actual data transmissions from the BeiDou satellites to establish a pattern. Perturbation terms, for example, no longer are applicable in the same way as ECEF-based propagation.
The result of all this uncertainty and complication was that the implementation of a fully compliant, fully synthetic BeiDou simulator took significantly longer than would have been expected normally from a published ICD, especially given the strong similarity between the structure of the BeiDou messages and those of legacy GPS, being based on 10 x 30-bit words in 5 x sub-frames that build into a single data frame, with sub-commutated pages.
It is interesting to mention some observations relating to the BeiDou message structures and how they differ from that of legacy GPS.
The most obvious difference is that the GEOs have a different structure of data (D2 type) from the MEOs and IGSOs (D1 type) in addition to a data rate that is 10 times that of the other types.
Moreover, Beidou uses a more robust error detection scheme based on BCH encoding and interleaving at the word level, capable of identifying and correcting a single bit error in any word; legacy GPS can only detect bit errors. This is not as robust as the forward error correction–based schemes used in modernised GPS and Galileo, however, the latter of which also employs data interleaving.
The GEOs additionally broadcast data such as clock corrections and Ionospheric grid data that is more often associated with integrity-boosting augmentation systems, like WAAS and EGNOS, reflecting their dual roles as primary navigation sources and differential assets.
The data field boundaries are less regular, with some data being spread across more than two words and maybe with only the MSB in one word mixed in with several other parameters. This is presumably because the ephemeris sections are accommodating additional parameters, with the Ionospheric coefficients being included every subframe.
Each D2 subframe 1 is only half-populated with data, with the Ephemerides spread over 10 pages.
In spite of the orbital definition of the GEOs being stated in a non-ECEF frame in the Ephemerides, the almanac for the GEOs uses the ECEF frame.
The issue-of-data fields describe the age of the data, rather than identifying the particular data set.
The rules around time of almanac (TOA) and time of ephemeris (TOE) are somewhat different. Data is timed in terms of integer seconds-into-week rather than GPS’s 1.5 second–based z-count. The Week Number (WN) benefits from additional bits, meaning that WN rollovers will be eight times less frequent at 157 years, although not an issue for a constellation with a declared lifespan of less than 10 years before it is replaced with BeiDou-3!
A Proven Test Solution
As this article has shown, there are many pitfalls and “gotchas” in implementing a new GNSS on a simulator platform, but Spirent has nearly 30 years of expertise doing this. Users can be confident that our BeiDou implementation is robust, and successful receiver operation on the simulator is one way to prove this assertion.
These days, there are numerous companies declaring BeiDou (and other GNSS) “simulator” capabilities. Quite what those are in many cases is yet to be proven. What is proven however, is Spirent’s pedigree, expertise, and track record at delivering proper, working and useable GNSS test solutions.
Who do you really trust to support development and testing of your critical GNSS programmes?
Test Solutions Across All Applications
Fully ICD-compliant BeiDou-2 is now available across all of Spirent’s GNSS simulation and signal generation platforms, allowing coherent testing with GPS, Galileo, Glonass, QZSS, SBAS, GBAS, IRNSS and other signals.
Contact your Spirent representative to ask about the GSS8000, GSS6700, GSS6300, GSS6300M and GSS6400/6425 systems. Whatever your GNSS test needs, Spirent has it covered.
Come and see us September 18 and 19 at the ION GNSS+ 2013 exhibition, Island Booth F.
