Inside GNSS Media & Research

MAY-JUN 2018

Issue link: https://insidegnss.epubxp.com/i/987551

Contents of this Issue

Navigation

Page 55 of 67

56 Inside GNSS M A Y / J U N E 2 0 1 8 www.insidegnss.com Architecture The architecture of the cloud GNSS receiver is composed of three main ele- ments ( Figure 2 ): the cloud GNSS sensor, the cloud front-end in charge of inter- acting with the user, and the back-end module where a High-Sensitivity (HS) GNSS Soware Receiver (SwRx) is run- ning and where all the computational tasks, reporting, and delivery of results are carried out. e cloud GNSS sensor is the IoT hardware element in charge of gathering the raw GNSS samples at the user side, and sending them to the cloud GNSS receiver for subsequent process- ing. It is composed of an RF front-end tuned to the GNSS band of interest that includes an Analog-to-Digital Converter (ADC) for digitizing the GNSS signals, memory, and a communication mod- ule for interacting with the cloud GNSS receiver. e cloud front-end is the interface through which a user or a machine, Hu m a n - t o - M a c h i n e ( H 2 M ) a n d Machine-to-Machine (M2M), respec- tively, interacts with the cloud GNSS receiver. In the H2M approach, the user can access the cloud GNSS through an HTTP web service, where users can log in and enter into a private desktop. en, new executions or jobs can be launched using an online graphic user interface that allows for configuration of the HS- GNSS SwRx. Notwithstanding, H2M interfacing is not a scalable approach and it is not suitable for large cloud GNSS sensor networks. It is for this reason that a M2M interface becomes mandatory. In this sense, an Application Programming Interface (API) has been built to allow sensors to automatically connect with the cloud GNSS receiver. Afterwards, the output results, PVT being an exam- ple, are stored in a database and can be retrieved at any time by the user. Both API and webpage are used to generate a new job with a raw GNSS sample file and a JavaScript Object Notation (JSON) file as inputs. e JSON is used to configure the HS-GNSS SwRx to the specific needs of the analysis to be done, and to the working conditions where the samples were gathered with parameters such as the number of snapshots, the GNSS band to be processed, the coherent and non- coherent integration time, etc. e flex- ibility offered by the cloud GNSS receiv- er allows the choice of some advanced features including using long integration times for processing weak GNSS signals, implementing signal-level analysis, etc. Metadata associated with the capture of raw GNSS samples including RF and Intermediate Frequency (IF), sampling rate, quantization, encoding, etc., can be included in the JSON or by using the Institute of Navigation (ION) Soware- Defined Radio (SDR) metadata standard (J. Curran et alia). Likewise, assistance information regarding the list of satel- lites to be searched together with their Doppler frequency can also be attached to decrease the execution time (like a hot start in an MM GNSS receiver). Assis- tance information can be automatically generated by the cloud GNSS receiver by attaching an approximate location and the timestamp. Finally, a Receiver Independent Exchange Format (RINEX) navigation file must be attached in order to calculate the PVT of the sensor. In this context, the cloud GNSS receiver also procures the capability of down- loading RINEX navigation files from servers of the International GNSS Ser- vice (IGS). is is mainly to avoid the need for capturing GNSS signals during a long interval of time (i.e., at least 30 seconds in GPS L1 C/A are required to read and decode the ephemeris embed- ded into the navigation message) and hence reduce the amount of data to be captured and transferred to the cloud to a few milliseconds of signal. Lastly, the files and job instructions generated by the cloud front-end (i.e., raw GNSS sample file, JSON, API commands) are transferred and communicated to the cloud back-end. Each new job generated by a user or IoT positioning sensor is received and managed by a resource manager in charge of allocating cloud comput- ing resources to the job. e back-end of the cloud GNSS receiver is where the bulk of the processing tasks are carried out. is comprises reading, decoding, and processing the raw GNSS sample file given the configuration param- eters included in the JSON file to finally obtain the desired output such as PVT. is process is implemented by means of an HS-GNSS soware receiver, a snap- WORKING PAPERS FIGURE 2 Cloud GNSS receiver architecture

Articles in this issue

Links on this page

view archives of Inside GNSS Media & Research - MAY-JUN 2018