european space agency
GNSS-1 Project Office

Date
Ref
Issue
Page

:
:
:
:

15/05/2006
E-RD-SYS-E31-010
3Rev. : 1
1

User Interface Document
Ankit Raj Mathur
Félix Torán-Marti
Dr. Javier Ventura-Traveset

THIS DOCUMENT IS THE PROPERTY OF ESAIT CANNOT BE REPRODUCED IN ANY FORM
OR DISCLOSED TO ANY THIRD PARTIESWITHOUT WRITTEN AUTHORIZATION FROM ESA

Prepared by :Reviewed by:Approved by :Ankit Raj Mathur

Felix Toran-Marti

Javier Ventura-Traveset

Centre Spatial de Toulouse - 18 Avenue Edouard Belin - 31401 Toulouse Cedex 4 - France
Tel. : +33 (0)561 282865 - Fax : +33 (0)561 282866

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

User Interface Document

Page : 2

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

DISTRIBUTION LIST
GNSS-1 Documentation.
SISNeT Web Site: http://www.esa.int/sisnet...

User Interface Document

Page : 3

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Page : 4

DOCUMENT CHANGE RECORD
Issue
0

Revision
0Date
15/11/01

Change Status
Draft

OriginFT

1

021/11/01

First release of the document

FT

2

0

01/02/02

Detailed information about the new
SISNeT authorisation process included(major change of the DS2DC protocol)

FT

2

1

28/05/02

3

1

05/05/06

New EPHEM and GPS_IONO messages
added to the DS2DC protocol
Major change in the DS2DC protocol:
CRLF separators. New DS2DC messages
added, including new START/STOP
mechanism, quick receiver initialisation
and retrieval of already broadcast
EGNOS messages.

User Interface Document

FT

FT/AM

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Page : 5

TABLE OF CONTENTS
1. INTRODUCTION....................................................................................................................................7
1.1
1.2
1.3
1.4

PURPOSE OF THE DOCUMENT ................................................................................................................7
ORGANISATION OF THE DOCUMENT .....................................................................................................7
READING GUIDELINES ............................................................................................................................7
CHANGES INTRODUCED IN ISSUE 3.1.....................................................................................................82.

THE SISNET PLATFORM ..................................................................................................................10

2.1 INTRODUCTION .....................................................................................................................................10
2.2 SISNET OBJECTIVES ............................................................................................................................10
2.3 IS SISNET USEFUL? ..............................................................................................................................10
2.4 OVERVIEW OF THE SISNET PLATFORM .............................................................................................12
2.5 THE SISNET COMPONENTS .................................................................................................................142.5.1 THE BASE STATION .............................................................................................................................142.5.2 THE DATA SERVER..............................................................................................................................15
2.5.3 THE USER EQUIPMENT ........................................................................................................................15
2.6 ESA SISNET-BASED DEVELOPMENTS .................................................................................................18
2.6.1 REAL-TIME MONITORING OF THE ESTB PERFORMANCE .....................................................................192.6.2 POSITIONING THROUGH THE INTERNET...............................................................................................20
2.6.3 REAL-TIME ANALYSIS OF THE ESTB MESSAGES .................................................................................22
2.6.4 REAL-TIME MONITORING OF THE ESTB SIS STATUS THROUGH THE INTERNET .................................27
2.7 SUMMARY ..............................................................................................................................................27
3.

USER APPLICATION SOFTWARE DEVELOPMENT ..................................................................28

3.1
3.2
3.3
3.4

INTRODUCTION .....................................................................................................................................28
HOW TO DEVELOP THE UAS? ..............................................................................................................28
HOW TO DEVELOP THE DS2DC CLIENT? ...........................................................................................29
CONCLUSIONS .......................................................................................................................................32

4.

TECHNICAL SPECIFICATIONS OF THE DS2DC CLIENT.........................................................33

4.1 INTRODUCTION .....................................................................................................................................33
4.2 THE DS2DC PROTOCOL .......................................................................................................................33
4.2.1 FUNDAMENTALS OF THE ESA DS2DC PROTOCOL..............................................................................33
4.2.2 AVAILABLE DS2DC MESSAGES .........................................................................................................35
4.3 THE AUTHENTICATION PROCESS ........................................................................................................38
4.4 THE SINCA COMPRESSION ALGORITHM ............................................................................................39
4.5 SINCA DECOMPRESSION ALGORITHM ................................................................................................42
4.6 SUMMARY ..............................................................................................................................................44

User Interface Document

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Page : 6

5.

REFERENCES.......................................................................................................................................45

6.

LIST OF ACRONYMS .........................................................................................................................49

APPENDIX A. DS2DC MESSAGE REFERENCE....................................................................................50
AUTH MESSAGE ............................................................................................................................................51*AUTH MESSAGE ..........................................................................................................................................52
MSG MESSAGE ..............................................................................................................................................53*MSG MESSAGE ............................................................................................................................................54
GETMSG MESSAGE ......................................................................................................................................55*GETMSG MESSAGE ....................................................................................................................................56
START MESSAGE ..........................................................................................................................................57*START MESSAGE ........................................................................................................................................58
STOP MESSAGE .............................................................................................................................................59*STOP MESSAGE ...........................................................................................................................................60
EPHEM MESSAGE .........................................................................................................................................61*EPHEM MESSAGE .......................................................................................................................................63
GPS_IONO MESSAGE ...................................................................................................................................64*GPS_IONO MESSAGE .................................................................................................................................65*ERR MESSAGE .............................................................................................................................................66*TXT MESSAGE .............................................................................................................................................67
APPENDIX B. SISNET ERROR CODES AND ERROR MESSAGES...................................................68

User Interface Document

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Page : 7

1. INTRODUCTION
1.1 Purpose of the Document
This document provides a description of the SISNeT user interface at different levels, from themore general concepts down to the message format and compression algorithm description. The
main purpose is to provide all the information that must be known to develop SISNeT – based
applications. The concepts and techniques exposed in this document shall be carefully applied inany SISNeT development, in order to obtain SISNeT - compliant applications.
1.2 Organisation of the Document
The document is organised as follows:







Section 1 explains the objectives of this User Interface Document (UID) and presents an
overview of its contents.
Section 2 provides a top-level view of the SISNeT platform, justifying its added-value anddescribing all the components of the platform. In addition, some SISNeT-based applications
developed by ESA are shown.
Section 3 introduces the higher-level concepts related to SISNeT user application
development.
Section 4 is centred on the development of the most important component of any SISNeT
application: the DS2DC client. The DS2DC protocol and the SINCA compression
algorithm are explained in detail.
Appendix A explains in detail the available DS2DC messages
Appendix B shows the available error codes and error messages, returned by the SISNeT
Data Server.

1.3 Reading Guidelines
This document is characterised by a top-down design. It starts from a top-level view of the SISNeT
platform, and goes down, progressively, towards lower–level aspects. As a consequence, theintended readership is wide. Depending on the reader's technical background, more or less sections
should be read.

User Interface Document

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Page : 8

A reader with non–technical interest should read Sections 2 and 3, obtaining a clear top–level viewof the SISNeT technology and the general ideas about the UAS development process.
Section 4 is related to the software development. This section has interest mainly for the engineers
who plan to develop SISNeT applications, giving a clear idea of what to do, before they startcoding. Therefore, knowledge about programming is required.
1.4 Changes Introduced in Issue 3.1
With respect to version 2.1 (the previous version) of this document, and responding to user’s
feedback, a nomenclature change has been introduced. Now, R-Commands, S-Commands and ACommands are renamed as R-Messages, S-Messages and A-Messages, respectively. In addition,
the M-Commands are now renamed as E-Messages, being the initial “E” referred to EventTriggered messages.
A major change to the DS2DC protocol has been introduced: the termination of R–Messages and
S–Messages (A–Messages and E–Messages) with a carriage return followed by a line feedcharacter. This change is not compatible with the previous versions of the protocol. In other words,
any application developed according to versions 1.0 to 2.1 of the SISNeT User Interface Document(UID) will not work with the present SISNeT platform, which implements version 3.1 of the UID(the present Document).
Although backwards compatibility constitutes the most respected principle in the evolution of the
SISNeT service, ESA has made an exception in this particular case, taking into account thefollowing facts:•

SISNeT users have requested the implementation of this change repeatedly. In other words,
this change responds to the user requests.

•

This change allows “manually” interacting with the Data Server through a telnet session,
avoiding having to implement software for that purpose.

•

In addition, in the case that any message or answer is broken (by the TCP protocol) into
several independent text messages, CRLF separators allow recovering the information in an
adequate form.

•

ESA has a close communication with the SISNeT user community. The upgrade has beencommunicated to all the users with enough anticipation. Indeed, a testing version 3.0 of the
SISNeT platform, implementing the change, has been running since more than 1.5 years,
giving users enough time to adapt their applications. This testing version has beenannounced by e-mail to all the SISNeT users, and to all the new users, as well as via
different papers and presentations at International Conferences.

User Interface Document

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Page : 9•

In this phase of the project, all the SISNeT developers have full control on the source codeof their applications, being able to adapt the software to the new version 3.1 of the DS2DC
protocol.

•The necessary adaptation to make applications compatible with the current specification(version 3.1) is, in general, easy to implement.

In addition to this major change, several messages have been added to the DS2DC protocol. Thesechanges are concentrated in Appendices A and B, and include the following features:•

Fast authentication and initialisation of receivers, through a new variant of the AUTH
message. This capability will allow dramatically reducing the Time–to–First–Fix (TTFF). If
a GPRS wireless link to the Internet is used, TTFF is typically reduced to about 30 seconds.

•

Ability to get messages already broadcast by EGNOS on demand, via the new GETMSG
message. One of the powerful applications of this new feature (based on the non Safety ofLife nature of SISNeT) is the optimisation of communications bandwidth, by requesting thedifferent messages types with a different periodicity, which corresponds to fast / slow
nature of the requested information.

•

The new START message enables the user to get EGNOS messages continuously until the
new STOP message is sent. This is equivalent to sending a MSG message every second.
Therefore a considerable bandwith is gained thanks to this START/STOP mechanism.

User Interface Document

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Page : 10

2. THE SISNeT PLATFORM
2.1 Introduction
This Section provides a clear big-picture of the SISNeT technology. In particular, the following
questions are answered:••••

What is the utility of SISNeT?
What is the general architecture of the SISNeT platform?
What is the architecture of the main SISNeT components?
Which are the currently existing SISNeT developments?

2.2 SISNeT Objectives
The main purpose of the SISNeT platform is to provide worldwide access to the EGNOS [2–10]
signal through the internet. In other words, SISNeT offers a novel technology for the developmentof applications integrating EGNOS–powered Satellite Navigation and Internet development. The
main advantages of SISNeT are the following:The EGNOS [2-10] signal is available, even if Geostationary (GEO) satellites are notvisible;Any user equipment may have free access to a virtual EGNOS receiver, with the only
condition of being connected to the internet;
SISNeT requires a transfer rate of less than 1 kbps. This is appropriate for accessing
SISNeT from a mobile terminal (e.g. GSM).

For more information about the SISNeT platform, the reading of [11 – 37] is recommended.
2.3 Is SISNeT useful?
SISNeT can provide the EGNOS signal to land–mobile users in urban areas. In that situation thevisibility of the GPS and GEO satellites is frequently poor. Hence, the question to answer is thefollowing:
Is it really useful to have access to the EGNOS services under low visibility conditions?
ESA has performed a preliminary study, in order to answer this question. The study is based on theuse of the ESA ESPADA [38 – 40] simulator. The output of the study is a Technical Note [24],User Interface Document

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Page : 11which is available at [12]. Assumptions used for this analysis may be considered conservative: they
are based on specified URE of 6 meters for the GPS satellites [42], and also on specified residual
corrections statistical errors for EGNOS. A major outcome of this study is illustrated in the bar plotof Figure 1.
The bar plot corresponds to a mask angle of 25 degrees (low visibility conditions). Each bar
indicates the availability, corresponding to an accuracy requirement (horizontal axis). The blue
bars refer to a GPS-only scenario, while the red bars correspond to a GPS+EGNOS configuration.

Figure 1. GPS/EGNOS comparative bar plot for a mask angle of 25 degrees
The reading of this plot is the following:
Under low visibility conditions (mask angle of 25 degrees):o GPS offers low availability. Even in the case of an accuracy requirement of 50 meters,
GPS is available less than 75% of time, while EGNOS is available 95% of the time;

User Interface Document

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Page : 12

o EGNOS is much more resistant to masking angle limitations, providing a highavailability (90% to 100%) even for an accuracy requirement of 10 meters.
Taking those readings into account, a main conclusion can be formulated:

EGNOS provides better availability of accuracy than GPS, for any masking angle. Interestingly,
in situations in which user visibility of GPS satellites is limited (say to 4–5 satellites), theavailability of the SBAS corrections plays a major role. Indeed, SBAS-available accuracy isquite insensitive to the number of GPS satellites in visibility, while GPS-only accuracy degrades
significantly. SISNeT benefits from this, making SBAS messages available regardless of the user
visibility conditions.

This conclusion demonstrates the SISNeT potential. Even if the GEO signals are not accessible and
the GPS satellites are seen with difficulty, the access through other means (e.g. GSM or GPRS via
SISNeT) allows taking benefit of the EGNOS power, i.e. improving the accuracy of positioning.
2.4 Overview of the SISNeT platform
Figure 2 depicts the SISNeT architecture. The three main components of the platform are thefollowing:
Base Station (BS). A PC computer connected to an EGNOS receiver through a serial port. Several
software components are installed on the computer, allowing acquiring the EGNOS messages andsending it to a remote computer (the Data Server) in real-time.
Data Server (DS). A high-performance computer, optimised for running server applications with alarge amount of connected users. The DS functionality is implemented through a software
application called SISNeT Data Server (SDS). This software receives the EGNOS messages fromthe BS and transfers them to the remote SISNeT users in real time through the Internet. In addition,
the SDS implements all the extra services (present and future) provided by the SISNeT system tothe users.
User Application Software (UAS). A Software application that accomplishes the SISNeTinterface specifications (exposed in this document), being able to obtain the EGNOS messages inreal time (1 message per second or 250 bps) from the DS. Moreover, the UAS can access and apply
the present and future additional SISNeT services. Each specific application of the SISNeT
platform is defined by a particular implementation of the UAS. The software can be embedded indifferent kind of computers and electronic devices (e.g. Personal Digital Assistants).

User Interface Document

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Page : 13

At the moment, the BS and the DS are installed on the ESA Radionavigation Laboratory at the
ESA ESTEC centre (Noordwijk, The Netherlands). The first implementation of the UAS wasdeveloped in the EGNOS Project Office (PO) in Toulouse (France), where the SISNeT concept
was validated for the first time during year 2001. The SISNeT UAS has been kept internal sincethen. However, the ESA UAS has been updated and is planned to be made available for download
via the ESA website. Figure 3 illustrates the current location of the SISNeT components. In Figure
3, the UAS is located in Toulouse to illustrate the location of the first UAS implementation, but
obviously, at the time of this writing (May 2006), there are hundreds of different UAS running over
Europe and beyond, with different purposes (EGNOS message real-time processing, SISNeT
receivers, etc.).

Figure 2. Architecture of the SISNeT Platform

User Interface Document

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Figure 3. Current location of the SISNeT components
2.5 The SISNeT Components
2.5.1 The Base Station
The BS consists of the following components (see Figure 4):

Figure 4. Architecture of the SISNeT Base Station

User Interface Document

Page : 14

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Page : 15•

An EGNOS Receiver. The receiver is connected to a PC computer through a serial port.

•

Receiver Control Module (RCM). A software component in contact with the EGNOS
receiver. The RCM controls the receiver via serial or USB port, by sending commands. The
receiver answers by sending logs to the computer each second, containing the EGNOS
messages for different EGNOS GEOs. The way the RCM manages the receiver is defined
through an interpreted scripting language. This allows a total control of the process, and also
gives flexibility to support different types of receivers.

•

SIS2DS Client. A client software component, implementing a SISNeT-specific protocol called
SIS2DS. The SIS2DS client takes the EGNOS messages and sends them to the DS. SIS2DS isbased on the TCP/IP protocol and is optimised for transferring the EGNOS messages to the DS
in real time.

2.5.2 The Data Server
The DS just contains one component: a server application called Data Server Software (DSS). The
DSS implements two server processes:
The SIS2DS Server, linking the DS with the BS.
The DS2DC Server, linking the DS with the users. This server listens to one port bydefault.

Before sending the EGNOS messages to the users, a data compression algorithm (called SINCA) isapplied. The length of the EGNOS message being transferred is always less than 67 bytes. The
compression algorithm frequently reduces the data size to 25% of the original size.
2.5.3 The User Equipment
The SISNeT User Equipment (SUE) is the most flexible part of SISNeT. Figure 5 shows thearchitecture of the SUE, which is made up of two main components:

A hardware platform, which can be freely selected. Examples of possible hardware are
PC computers and Personal Data Assistants (PDA).

The UAS, running on the hardware platform. Any software developer can freely create new
UAS implementations, i.e. define new SISNeT-based applications.

User Interface Document

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Page : 16

USER HARDWARE

Figure 5. User Equipment architecture
The User Application Software
The UAS (Figure 5) includes the following software components:


DS2DC Client. A client software component, implementing the DS2DC protocol. This
component connects to the DS and obtains the EGNOS messages in real time. In addition,
the DS2DC client can take benefit of all the additional services offered by SISNeT (thenumber of services is continuously growing). This component shall respect all the
specifications and recommendations about the DS2DC protocol (see Sections 3 and 4 ofthis document), in order to obtain a SISNeT-compliant UAS.



Processing stage. This block can be freely created by the developer, defining thefunctionality of each specific UAS implementation.



Output Interface, constituting the user interface of the SISNeT User Equipment.

The ESA SISNeT User Application Software
In 2001, ESA developed a first implementation of the SISNeT UAS, providing the following
benefits:

It allowed validating the SISNeT concept;
It was used as a platform for the integration of new SISNeT applications. In fact, three
SISNeT-based applications were internally developed and integrated into the UAS by ESA,in order to demonstrate the potential of the SISNeT technology;

User Interface Document

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Page : 17

The ESA UAS has been enhanced significantly; allowing to process most of the SBAS messages
defined in RTCA MOPS DO229C, and present their contents in a user-friendly form. This softwareis intended to be made available for free download before the end of 2006, through the SISNeT
Website [11].
Figure 6 shows the appearance of the first implementation of the ESA SISNeT UAS (developed in2001).

Figure 6. The first ESA implementation of the UAS
The main GUI contains the following controls:A.

The contents of the EGNOS message received from the DS. This information is updated
in real time (one message per second).

B.

The GPS week corresponding to the current EGNOS message.

C.

The GPS time corresponding to the current EGNOS message.

D.

The message type (MT) corresponding to the current EGNOS message. The purpose andcontents of each MT can be found in [1].

E.

Log Window, containing messages about the status of the UAS operation.

User Interface Document

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Page : 18

F.

Disk buffering option. If checked, a live buffer of EGNOS messages is maintained on
the hard disk. This allows linking the ESA UAS with external applications, such as the
ESA ESPADA [38-40] simulator or other analysis software.

G.

Auto-reconnect option. If checked, the UAS will automatically attempt to reconnect to
SISNeT when the client is disconnected from the Data Server.

H.

Traffic lights, indicating the status of communications.

I.

Command buttons for the control of the UAS.

2.6 ESA SISNeT-based developments
In 2001, ESA developed four UAS applications, with the aim of demonstrating the potential of the
SISNeT platform. Those applications have been integrated with the ESA SISNeT UAS. The
integration consists on substituting the original processing block of the ESA UAS by four
independent processing stages, which run in parallel and define four different applications (seeFigure 7). That degree of parallelism has involved the use of multi-threading techniques.

Figure 7. Integration of parallel processing blocks into the UAS
Those applications are the following:
1. Real-time monitoring of the ESTB performance;
2. Positioning through the Internet (various projects developed by the industry);
3. Real-time analysis of the ESTB messages;

User Interface Document

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Page : 19

4. Real-time monitoring of the ESTB Signal-In-Space (SIS) broadcast status through theInternet.
Note Figure 7 presents four processing blocks. In fact, the second application mentioned above(positioning through the Internet) has been developed in the next years through different ESA
contracts with Industry.
For information, the next Sections describe in more detail those four applications.
2.6.1 Real-time monitoring of the ESTB performance
The objective of this application is to periodically provide maps of the ESTB performance. Eachmap must contain the Vertical Protection Limit (VPL) availability over a specific service volume,for the last 24 hours and for a given alarm limit (AL). In other words, the objective is to calculate for each location on the map - the percentage of time during which VPL is under the AL.
Figure 8 depicts the architecture employed to achieve that goal. The only change with respect tothe general SISNeT architecture (Figure 2) is centred in the processing block of the UAS. In thiscase, the processing block contains an interface with ESPADA [38–40], an advanced EGNOS
simulation tool developed by ESA. The ESPADA software is able to generate offline ESTB
performance maps using files, previously logged through a receiver and the appropriate software.
Thanks to the new interface, ESPADA is now able to provide those maps in real time (one map
each 6 minutes).

User Interface Document

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Page : 20

Figure 8. Real-time monitoring of the ESTB performance
ESPADA can store the maps in two well-known formats:Power Point slides.
AVI video files (generated on a daily basis).

This application has been a precursor of the present EGNOS Real-Time monitoring network.
2.6.2 Positioning through the Internet
The goal of these applications is to provide wireless EGNOS services to land-mobile users throughthe Internet. Figure 9 shows the architecture of one such SISNeT-based system.

User Interface Document

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Page : 21

Figure 9. Positioning through the Internet
In this case, the user equipment is embedded into vehicles or handheld equipment (e.g. mobile
phones or PDAs), and the connection to the Internet is achieved through a GSM or GPRS modem.
The DS2DC client obtains the EGNOS messages in real-time, and a GPS receiver provides
pseudorange measurements, also in real time. The processing block takes the pseudorange
measurements and applies the EGNOS corrections, obtaining a significant improvement of position
accuracy.
This activity and other similar activities have been developed by the industry through a number of
ESA contracts. It is worth to note that, at the time of this writing (May 2006), several SISNeTbased contracts are ongoing. Some of those applications are the following:••

SISNeT receiver based on a PDA device.
SISNeT based receiver used in urban buses of Toulouse, France demonstrated the utility of
SISNeT in urban areas of low satellite visibility conditions.[29]User Interface Document

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006•••

Page : 22

SISNeT-ONCE project. A personal navigator for Blind pedestrians in cities wasdeveloped.[31]ShPIDER, a SISNeT based professional receiver was developed.
MOMO: Personal navigation tool for blind pedestrians on a mobile phone. This contract iscurrently (May 2006) ongoing.[41]2.6.3 Real-time analysis of the ESTB messages
This application consists on the real-time analysis of the messages broadcast by EGNOS(presently, the ESTB). The objective has been achieved through the integration of several
monitoring panels into the ESA UAS (Figure 10). Each panel shows the contents of the EGNOS
messages in a graphical and organised way, allowing the user to quickly find the desired
information.

Figure 10. Real-time monitoring of the ESTB SIS status: integration of monitoring windows
into the ESA SISNeT UAS

User Interface Document

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Page : 23

The original ESA SISNeT UAS integrated the panels for the analysis of the following message
types (MTs):

Analysis of MT1 (Figure 11). This panel presents all the possible satellites that can be
active, classified by constellations. The satellites are referred by the pseudorandom code
number (PRN). All the active PRNs are coloured in green. Due to the specifications of MT1[1] the maximum allowed number of active satellites is 51.

Analysis of MT2 to MT5 (Figure 12). This panel shows the information regarding the fast
corrections, laid out on a table. For each PRN (first column), the user can quickly find thepseudorange corrections (PRC) and the User Differential Ranging Error (UDRE) variance.

Analysis of MT17 (Figure 13). This panel informs about the GEO almanacs. For each
PRN corresponding to a GEO satellite, the user can know if ranging, corrections andintegrity information is being broadcast. The service providers and the co-ordinates of the
GEO satellites are also included.

Analysis of MT25 (Figure 14). This panel shows the long-term satellite error corrections,laid out on a table. For each PRN, the table indicates the corrections to the satellites' orbits,
its rates of change, the clock offset and drift, and the time of day applicability (if pertinent).

User Interface Document

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Figure 11. Real-time analysis window for MT1 (PRN mask)

User Interface Document

Page : 24

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Page : 25

A monitoring panel for each EGNOS message type is available.

Figure 12. Real-time analysis window for message types 2 to 5 (fast corrections)
The ESA UAS has been recently enhanced, and it is ESA intention to make this tool available forfree download before the end of 2006.

User Interface Document

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Page : 26

Figure 13. Real-time analysis window for MT17 (GEO almanacs)

Figure 14. Real-time analysis window for MT25 (long term satellite error corrections)User Interface Document

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Page : 27

2.6.4 Real-time monitoring of the ESTB SIS status through the Internet
This application allows monitoring the ESTB broadcast status and its performance in real time andthrough the Internet, concretely across the World Wide Web (WWW). This application was basedon interfacing the UAS with the ESA ESPADA simulation tool.
2.7 Summary
This section has presented the top-level aspects of the SISNeT technology. Firstly, the utility of the
SISNeT concept has been demonstrated. After that, an overview of the SISNeT platform has beenpresented, focusing the main components. Finally, several ongoing SISNeT developments, aimed
at demonstrating the potential behind the SISNeT concept, have been described, including (forinformation) the very first internal activities performed by ESA in the early days of SISNeT.
Next Section goes to a more technical level of detail, showing high-level concepts regarding thedevelopment of SISNeT applications.

User Interface Document

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Page : 28

3. USER APPLICATION SOFTWARE DEVELOPMENT
3.1 Introduction
The applications shown in Section 2 (the previous Section) are just an example of the potential of
the SISNeT technology, centred in the EGNOS system monitoring and also in EGNOS-augmented
positioning. Furthermore, SISNeT brings the opportunity to combine:

Any Science or Engineering field;
The potential of the Internet;
The potential of EGNOS-augmented Satellite Navigation.

This section presents how to create a new SISNeT application, i.e. creating a new UAS.
Recommended and mandatory practices are also included. The low-level technical knowledge
involved in that process is covered in Section 4.
The user hardware can be freely implemented and has no impact on the UAS development process.
Therefore, no guidelines about hardware development are presented here.
3.2 How to develop the UAS?
Once the user hardware/software platform is implemented (e.g. a PC computer with Microsoft
Windows OS), the application Software part of the user equipment (i.e. the UAS) must be
implemented, in order to provide the desired functionality. As stated in Section 2.8, the UAS
development involves the implementation of three Software components:The DS2DC client;
One or more processing blocks;
A user interface.

The main function of the DS2DC client is to communicate with the Data Server, in order to obtain
the EGNOS messages in real time. The communications protocol is called DS2DC (Data Server toData Client), and is totally based on the TCP/IP protocol. In addition, the DS2DC protocol allows
implementing other functionalities different than the broadcast of EGNOS messages (e.g. broadcastof text messages to the users).
The processing block works over the EGNOS messages provided by the DS2DC client, andoptionally over any other external system (e.g. a GPS receiver, as explained in Section 2.12). This

User Interface Document

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Page : 29

block defines the UAS functionality. Finally, the output interface allows the user to communicate
with the UAS, normally through a GUI.
Since the processing block and the output interface are particular to each UAS implementation,
they can be freely developed without any restriction. However, the DS2DC client accomplishes anessential task: obtaining the EGNOS messages in real time from the SISNeT Data Server. In fact,
the UAS will correctly work only if the DS2DC protocol is properly implemented.
Section 3.3 (the next Section) explains how to develop such a component.
3.3 How to develop the DS2DC Client?
Figure 15 shows the architecture of the DS2DC client. The boxes represent functional components,
while the ellipses represent information. The blue ellipses represent the output data of the DS2DC
client.

Figure 15. Architecture of the DS2DC Client

User Interface Document

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Page : 30

The functional blocks of the DS2DC client's architecture are the following:

TCP/IP Client Socket (TCS). This block opens a TCP/IP connection to the DS, using apreviously agreed IP address and port. It allows sending text messages to the DS, andreceiving the text messages sent by the DS as an answer.



Analysis of DS2DC Messages (ADM). This block analyses the contents of the messages
sent by the DS. As a result, the information contained in those messages is extracted andconverted to an easy-to-process format.



Decompression Algorithm (DA). In the particular case of the EGNOS messages, theinformation extracted by the ADM is compressed through a specific protocol. The DS
applies a compression algorithm (called SINCA) to the EGNOS messages before sending
them to users. That means a decompression algorithm must be implemented into theDS2DC client, only applicable to the messages containing EGNOS messages. The SINCA
algorithm is explained in Section 4.

The components work together as follows:
1.

A TCP/IP connection to the DS is opened, using the TCS for that purpose;

2.

The TCS sends the desired messages to the DS (e.g. a message requesting an EGNOS
message)

3.

The TCS is always listening for incoming messages from the DS. Those messages canbe:• Answers to previously sent messages;• Messages spontaneously sent by the DS.

4.

When a message arrives from the DS, it is captured by the TCS as a text string;

5.

The received message is analysed using the ADM block. This block must extract therelevant information contained in each message and provide it as an output of theDS2DC client. The format of that output should be as simple as possible. The goal is toease the work to the rest of the UAS.

6.

If the received messages contain an EGNOS message, the DA must be applied. That
block's output must be the decompressed EGNOS message (i.e. the message broadcast by
the EGNOS system). The EGNOS messages are part of the DS2DC Client output.

The architecture shown in Figure 15 shall be implemented as shown. The only exception could be
implementing the ADM block as a part of the DS2DC Client's processing block. However, thisUser Interface Document

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Page : 31

practice is not recommended, since the function of the processing block is just defining the specificfunctionality of the UAS, and not performing a general task like DS2DC message analysis.
The most recommended practice is to implement the DS2DC Client as a re-usable Software
component (e.g. an ActiveX or VCL component, or DLL library). The user of the component mustsee the interface shown in Figure 16, in which the green ellipses indicate the input data, and theoutput data is represented by blue ellipses.

Figure 16. DS2DC Client interface.
Using this approach, the processing block of the UAS will not receive DS2DC messages. Instead, it
will directly receive the relevant information to process.
All the blocks (TCS, ADM and DA) shall accomplish the functionality exposed in this Section. In
addition, the specific requirements to respect in the development of each block are the following:TCS: shall implement the DS2DC protocol (explained in Section 4). Any non-DS2DC
incoming message shall be ignored and the user shall be informed about that. Only
DS2DC messages shall be sent to the DS.
ADM: analysis shall be performed strictly following the DS2DC protocol
specifications.
DA: the SINCA decompression algorithm shall be correctly implemented, as explainedin this document..

The valid DS2DC messages are just those specified in this Document. The DS2DC Client shall
ignore any other message, and the user shall be informed about that. The developer shall motivate

User Interface Document

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Page : 32

the user to inform ESA in case of receiving invalid messages (through warning windows or similarmeans). In addition, the DS will detect users sending invalid messages, and will apply several
categories of penalties (including rejecting future connections). This will improve security.
3.4 Conclusions
This section has presented the process to follow when developing a new SISNeT application,
including recommendations and restrictions to take into account.
The main conclusions are the following:•

The development of a SISNeT application is reduced to the development of the UAS,
running on a pre-selected hardware platform (PDAs, mobile phones, PC computers,
etc.)

•

The development of the UAS involves the creation of three blocks: the DS2DC client, aprocessing block and a user interface. Development is only restricted with respect to theDS2DC client, which shall respect the specfications provided in this User Interface
Document.

•

The development of the DS2DC client involves the creation of three blocks: the TCS,
the ADM and the DA. All those blocks shall respect the specifications of the present
UID document.

Section 4 presents in detail he DS2DC protocol and the SINCA algorithm specifications, whichshall be respected in order to obtain SISNeT-compliant UAS.

User Interface Document

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Page : 33

4. TECHNICAL SPECIFICATIONS OF THE DS2DC CLIENT
4.1 Introduction
Section 3 has explained the process to follow when creating a new SISNeT UAS, highlighting the
restrictions to take into account. Those restrictions are related to the components of the DS2DC
client, and require a low-level technical explanation of:••

The DS2DC protocol specifications;
The SINCA compression algorithm.

This Section provides those technical inputs, which shall be strictly respected, in order to assure
the UAS is SISNeT-compliant.
4.2 The DS2DC protocol
4.2.1 Fundamentals of the ESA DS2DC protocol
The DS2DC protocol works with text strings, directly sent and received through the TCP/IP
protocol (via the activation of a TCP socket linking the DS2DC Client and the DS). Those text
strings will be called "messages" hereinafter. Each message is composed of text fields, which areseparated by commas. Each field contains a specific portion of the information included in themessage. The first field is an uppercase text label, identifying the purpose of the message. Thatlabel will be referred as the "Message Name" hereinafter. Figure 17 illustrates the general structureof a DS2DC message.

Figure 17. General structure of a DS2DC message
It is important to note that any message shall end with:••

A line feed (LF) character, orA carriage-return character followed by a line feed character (CRLF).

User Interface Document

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Page : 34

Depending on their directionality, the messages can be classified in two groups:•

Messages going from the UAS to the DS. Following the SISNeT terminology, thesemessages receive the name of R-Messages or RMs, since they usually Request services tothe DS. The R-Messages are usually called “DS2DC messages”.

•

Messages going from the DS to the UAS. Following the SISNeT terminology, thesemessages receive the name of S-Messages or SMs, since the DS uses them to provide a
Service. The SMs can be classified in two groups:
o SMs sent as a response to previously sent RMs. These messages receive the nameof A-Messages or AMs, since they provide an Answer.
o SMs spontaneously sent by the DS. These messages receive the name of EMessages or EMs, since they usually act as Event-trigger signals.

Note that a message could belong to several different categories, depending on the context inwhich it is being used each time. One example is the '*ERR' message. This message can act as an
EM for spontaneously reporting some conflicting situation. On the other hand, if a RM is notcorrectly formatted / employed, or contains incorrect information, the *ERR message acts as an
AM, reporting about the error situation. Classification of the DS2DC messages is illustrated in
Figure 18.

Figure 18. Types of DS2DC messages

User Interface Document

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Page : 35

A relationship exists between message names and message types. The naming rules are thefollowing:•

RMs: Message names always start with an alphabetic character.

•

AMs: Message names always start by a '*' character, followed by the message name being
answered. For instance, the AM associated with a RM called 'MSG' is '*MSG' (or '*ERR' incase of error).

•EMs: Message names always start by a '*' character.

From those rules it is concluded that the '*' character indicates DS to UAS direction, and its
absence indicates UAS to DS way. After presenting the theoretical aspects behind the DS2DC
protocol, Section 4.2.2 focuses on more practical issues, presenting some available DS2DC
messages.
4.2.2 Available DS2DC Messages
The following list explains the purpose of some of the currently available DS2DC messages, using
the classification criteria introduced in the previous section. More information on the syntax ofthese messages is available in the Appendix A.
•

R – Messages:o AUTH. This RM makes possible the implementation of an authentication process,which is mandatory before any interaction with the DS. For further information on
this process, see Section 4.3.
o MSG. Asks the DS for an EGNOS message. This RM is intended to be used in asynchronous way, i.e. sending the MSG message, and waiting for the response, andthen sending another MSG message, and so on. Loss of messages could appear,
especially when connecting to the Internet via GSM or GPRS links. The DS2DC
protocol offers a solution to the problem of message losses: the possibility toretrieve an already broadcast EGNOS message (provided its message type isknown) after detecting its absence. See the ‘GETMSG’ RM.
o GETMSG. This RM allows retrieving an already broadcast EGNOS message. The
message to retrieve is identified by MT number and order of occurrence. This RM

User Interface Document

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Page : 36

has a special interest to quickly obtain the MTs which are broadcast with a low
frequency by the SBAS system. For example, this is the case of the ionosphericcorrections. The UAS can collect all the necessary information to start applying theionospheric corrections, without having to wait several minutes for all the necessary
information to be broadcast. The result is a dramatical reduction of the Time To
First Fix (TTFF).
o START. This RM allows the user to receive the EGNOS messages continuously
from the data server, until the STOP message is sent.
o STOP. This RM is useful if the user wishes to stop receiving the EGNOS messages
after the START message is sent.
o EPHEM. This RM can be used to request ephemeris information for a given GPS
satellite. The ephemeris information is expressed in a RINEX-like format, i.econtaining 8 lines of ASCII characters. The PRN number of the GPS satellite andthe line number (1 to 8) of the ephemeris information must be sent along with therequest.
o GPS_IONO. This RM can be used to request the parameters of the Klobuchar
ionospheric model (broadcast by the GPS system).
•A – Messages:o *AUTH. A positive answer to an authentication message (AUTH). Indicates thatthe DS2DC Client has permission to interact with the DS.
o *MSG. This AM answers the request of an EGNOS message. Its fields include themost updated EGNOS message, together with the GPS time and GPS week number.
The EGNOS message is provided in hexadecimal format. Each EGNOS message isformed by 63 hexadecimal digits (252 bits). Note that the received message could
present 64 hexadecimal digits. In that case, the last digit is always set to zero andshould be ignored. Since the EGNOS messages contain 250 bits, the last 2 bits of
the 63rd digit should be ignored. The message is terminated by an asterisk ‘*’
symbol, followed by two hexadecimal digits constituting a checksum (XOR
operation of the bytes forming the EGNOS message). This checksum can be used by
the UAS to detect transmission errors from the DS to the user. Also note that the
EGNOS messages contain a 24-bit CRC code, generated by EGNOS before
transmission.

User Interface Document

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Page : 37

o *GETMSG. The answer to the 'GETMSG' message. Contains the requested pastmessage (see Appendix A for details).
o *START. The answer to the START message. This answer is continuously
followed by the EGNOS messages, received through the *MSG A-Message..
o *STOP. The answer to the STOP message indicates that the reception of continuous
EGNOS messages has been stopped.
o *EPHEM. It is an answer to the EPHEM message, along with the requested
ephemeris line.
o * GPS_IONO. It is an answer to the GPS_IONO message, providing the Klobuchar
model parameters as broadcast by the GPS system.
o *ERR. This message informs about an error. Its contents include an error code anda text string explaining the problem (see Appendix B). The error code can be used
for identifying the error source.
•

E – Messages:o *TXT. This EM allows the SISNeT operators broadcasting informative text strings
to the users (e.g. information about new SISNeT applications, DS2DC protocol
upgrades, etc.). The normal reaction to this message is to present those strings on
the available output device (PC monitor, LCD display, etc.). When a maintenanceactivity is scheduled, this message is usually sent to notify users in advance.

The complete reference of available messages can be found in Appendix A of this Document. As acomplement, Appendix B introduces the available error messages that the Data Server can return.

User Interface Document

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Page : 38

Figure 19. General structure of the EGNOS messages provided by SISNeTThe number of DS2DC messages will be continuously growing and, hence, being reflected into
new revisions of this document. Those messages are exclusively managed by ESA. Any suggestionof new messages is welcome, and will be studied by ESA. Sending messages not included in thisDocument to the DS is strictly prohibited.
A detailed explanation of the format of each available DS2DC message is presented in Appendix
A. The messages reserved for future use are not included, since they are under study anddevelopment.
4.3 The Authentication Process
After opening a connection to the Data Server, the Client Socket must maintain an authentication
dialog with the DS, in order to obtain permission for accessing the SISNeT services. As introducedin Section 4.2 (the previous Section), the authentication protocol relays on the use of the "AUTH"
R–Message, and its associated "*AUTH" A–Message. The complete sequence of actions is thefollowing:
1. The DS2DC Client establishes a connection with the DS.
2. The DS2DC Client sends an AUTH message, containing the private information
corresponding to a valid account, i.e. user name and password.
3. If the authentication data correspond to a valid account, the Data Server returns an *AUTH
message, indicating that the access to the DS is allowed. The DS2DC client can then start
its normal interaction with the DS.

User Interface Document

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Page : 39

4. If the authentication data is not correct, the DS returns an *ERR message containing error
code number 2. This message indicates the access to the DS is denied. The DS disconnects
the DS2DC client immediately after.
Note the authentication process is mandatory before any interaction with the DS, and must be
respected exactly as shown above. The following remarks shall be taken into account:•Obviously, no user can access the Data Server without having a valid SISNeT account.
SISNeT accounts are managed by ESA, and must be requested through contacting the ESA
SISNeT project team (sisnet@esa.int). A specific username and password for the use of
SISNeT by the future client will then be set up.

•

If the authentication phase is repeated certain number of times without success in a short
time-frame, the DS will apply a penalty to the client, rejecting its connection requests
during a certain number of hours.

•

If the DS2DC Client tries to send other DS2DC messages before successfully passing theauthentication phase, the DS will return an *ERR message, containing error code set to 1.
This message indicates the authorisation process is required. The DS disconnects the client
immediately after.

•

The user name is limited to 15 characters.

•

The password is limited to 8 characters.

•

The authentication protocol does not avoid the possible future release of public SISNeT
Data Servers. In this particular case, any user will be able to access the DS throughcommon authentication data, which will be made public. A hybrid version of the Data
Server is also possible, allowing the public access through common authentication data, as
well as private accounts (which will usually have some privileges in terms of performance).

From version 3.1 of the SISNeT User Interface Document, a new variant of the AUTH message
has been included, enabling authentication combined with quick initialisation of SBAS receivers.
4.4 The SINCA compression algorithm

The SISNeT Compression Algorithm (SINCA) is a simple technique, used by the DS to improvethe communications speed when performing the most critical task: sending the EGNOS messages
through the '*MSG' message. If the EGNOS message were not compressed, its length into thatmessage would always be 66 (or even 67) bytes, as shown in Figure 19. Using the SINCA

User Interface Document

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Page : 40

algorithm, that length is frequently reduced down to 16 bytes, or even less. The compression ratedepends on the contents of each concrete message.
In order to know how to decompress the messages, it is necessary to start by knowing how themessages are compressed. The SINCA compression algorithm is illustrated in Figure 20.

Figure 20. SINCA compression algorithm.

User Interface Document

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Page : 41

The process consists on evaluating each digit of the hexadecimal string. If the digit is repeatedfrom 4 to 15 times, all the repetitions are substituted by:<repeated_digit>|X
Where X is a hexadecimal digit indicating the number of repetitions. For instance, if the following
sub-string is found:
AAAAAAAAAAAA
That string will be substituted by:
A|C
Since 'A' is repeated 12 times. Note just one digit is used to indicate the number of repetitions. Thatis the reason to allow a maximum of 15 repetitions. A minimum of 4 repetitions has been
established, since the compressed string always has three characters. Otherwise, no compression
would be achieved.

And, what happens if the digit is repeated more than 15 times? The way to compress is the same,
but indicating the number of repetitions with two digits, and using the '/' separator:<repeated_digit>/XX
The reason to use a different separator is to ease the decompression. The '|' character indicates toread only the next character. On the other hand, the '/' character indicates to read the next two
characters.
Figure 21 shows an example of SINCA compression, performed over a real EGNOS MT0. The
EGNOS message length goes from 66 characters down to only 16 characters. That means themessage has been reduced to 24.2% of the original size.

User Interface Document

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Page : 42

Figure 21. Example of SINCA compression.

4.5 SINCA decompression algorithm
Once the process of compression is clear, the SINCA decompression algorithm is quite easy to
implement. This algorithm must be implemented by any UAS developer, in order to apply it to thecompressed EGNOS messages included inside the '*MSG' message. Figure 22 illustrates how to
implement such an algorithm.
The process consists on evaluating each character of the compressed string. When an 'X|Y' string isfound, that string is replaced by: 'XX…X', where 'X' has been repeated Y times (note Y is an
hexadecimal digit). When a 'X/YY' string is found, that string is replaced by 'XX…X', where 'X'
has been repeated YY times (note YY is a two-digit hexadecimal number). The algorithm ends
when reaching the end of the compressed string.
Figure 23 shows an example of SINCA-decompression, based on a real message broadcast by the
ESTB. The original string was 26 characters wide. After decompression, the resulting string is 66
characters wide, i.e. 2.54 times longer.

User Interface Document

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Figure 22. SINCA decompression algorithm

User Interface Document

Page : 43

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Page : 44

Figure 23. Example of SINCA decompression
4.6 Summary
This section has added more technical details to the concepts introduced in Section 3. The
knowledge needed for the development of the DS2DC client (i.e. the most critical and restricted
part of the UAS) has been introduced.
Concretely, the following information has been provided:•

A technical description of the DS2DC protocol, including the fundamental theory and theavailable DS2DC messages (see Appendix A).

•

A technical description of the SINCA compression algorithm. Firstly, the compression
algorithm has been described, since this knowledge is necessary to understand how todecompress the information contained in the '*MSG' messages. Then, the decompression
algorithm has been explained. The text has been illustrated through flow diagrams andexamples.

User Interface Document

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Page : 45

5. REFERENCES[1] “RTCA Minimal Operational Performance Standards for GPS / WAAS Airborne
Equipment”, Doc. No. DO 229 C, November 2001.
[2] J. Ventura-Traveset, L. Gauthier and F. Toran-Marti. “The Envisaged EGNOS
System Infrastructure Evolution Plan over 2005-2009”. Proc. of the European
Navigation Conference GNSS 2005. Munich (Germany). July 2005.
[3] F. Toran-Marti, J. Ventura-Traveset and L. Gauthier. “EGNOS Project Status”.
Navigation News (Magazine of the Royal Institute of Navigation), issue of January /February 2005, pp. 15-16.
[4] F. Toran-Marti and J. Ventura-Traveset. “The ESA EGNOS Project: The First Stepof the European Contribution to the Global Navigation Satellite System (GNSS).”
Proc. of ION-CH Navigare Conference, Winterthur (Switzerland), June 2004.
[5] Gauthier L., Michel P., Ventura-Traveset J. and Benedicto J., “EGNOS: the firststep of the European contribution to the Global Navigation Satellite System,” ESA
Bulletin, No. 105, February 2001.
[6] L. Gauthier, J. Ventura-Traveset and F. Toran. “EGNOS Operations and Their
Planned Evolution”. European Space Agency (ESA) Bulletin no 124. November
2005.
[7] Secretan H., Ventura-Traveset J., Toran-Marti F., Solari G. and Basker S., “EGNOS
System Test Bed Evolution and Utilisation,” ION GPS 2001, Sept. 2001, Salt Lake
City, USA. Awarded as best paper presentation in the area of SBAS systems.
[8] Secretan H., Ventura-Traveset J., Toran-Marti F., Solari G. and Basker S., "EGNOS
System Test Bed Evolution and Utilisation," NAVITEC Conference, Noordwijk (TheNetherlands), December 2001. Available at http://www.esa.int/estb[9] European
Space
Agency,
EGNOS
http://www.esa.int/navigation/estb

SystemTest

Bed

Website,[10] EGNOS for Professionals ESA website http://www.esa.int/navigation/egnos-pro[11] European Space Agency, ESA SISNeT website, http://www.esa.int/sisnet

User Interface Document

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Page : 46[12] SISNeT Publications, available at the ESA EGNOS for professionals website
http://esamultimedia.esa.int/docs/egnos/estb/sisnet/publications.htm[13] F. Toran and J. Ventura-Traveset. “Status and Evolution of the ESA SISNeTTechnology”. Proc. of the European Navigation Conference 2006. Manchester(UK). May 2006.
[14] F. Toran-Marti and J. Ventura-Traveset, “SISNeT: Status and Future Plans.” Proc.
of the European Navigation Conference GNSS 2004, Rotterdam (The Netherlands),
May 2004.
[15] Toran-Marti F., Ventura-Traveset J. and de Mateo J.C., "Satellite Navigation and theInternet: Introducing SISNET Technology," Dr. Dobb's Journal, March 2002.
Featuredarticle,available
onlineat
http://www.ddj.com/documents/s=4069/ddj0203a/0203a.htm[16] Toran-Marti F., Ventura-Traveset J. and de Mateo JC, “The ESA SISNeTTechnology: Real-Time Access to the EGNOS Services through Wireless Networks
and the Internet,” ION GPS 2002, Portland, USA, September 2002.
[17] Toran-Marti F. and Ventura-Traveset J. "The ESA SISNET Project: Real-Time
Access to the EGNOS Services across the Internet," 2nd ESA ESTB Workshop, Nice(France), November 2001. Available at http://www.esa.int/estb[18] Toran-Marti F., Ventura-Traveset J. and de Mateo JC, "Internet-based Satellite
Navigation receivers using EGNOS: the ESA SISNET project," ESA Workshop on
Satellite Navigation User Equipment Technologies (NAVITEC), Noordwijk (TheNetherlands), December 2001. Available at http://www.esa.int/estb[19] European Space Agency, "SISNET: Making EGNOS Available Over the Internet,"
ESTB News, ESA Newsletter, Issue 2, page 4, September 2001.
[20] European Space Agency, "SISNeT: Enhancing EGNOS for Land-Mobile Users,"
ESTB News, ESA Newsletter, Volume 2, Issue 1, page 1, May 2002.
[21] Toran-Marti F., Ventura-Traveset J. and de Mateo JC. "The ESA SISNET Project:
Real-Time EGNOS Services through the Internet," ESA Journal Preparing for the
Future, January 2002.
[22] Toran-Marti F., Ventura-Traveset J., and de Mateo JC, "The ESA SISNET Project:
Real-Time Access to the EGNOS Services across the Internet,” 7th International
Workshop on Digital Signal Processing Techniques for Space Communications,
October 2001, Lisbon (Portugal).

User Interface Document

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Page : 47[23] Toran-Marti F. and Ventura-Traveset J. “SISNeT Brochure,” ESA Brochure, June
2002.
[24] Toran-Marti F. and Ventura-Traveset J., "EGNOS Performances in Urban Areas
Using the ESA SISNeT Technology: Advanced Modelling of User Masking Effects,"
ESA Technical Note, Ref. E-TN-PFM-E-0029-ESA, April 2002.
[25] F. Toran-Marti, J. Ventura-Traveset, E. Gonzalez, M. Toledo, A. Catalina, C.
Barredo and A. Salonico, “Positioning Via Internet: SISNeT Catches GPS in Urban
Canyons.” GPS World, vol. 15, number 4, pp. 28 – 35, April 2004.
[26] F. Toran, J. Ventura-Traveset and R. Chen, “Handheld Internet-Based EGNOS
Receiver: The First Product of the ESA SISNET Technology,” GNSS 2003, Graz
(Austria), 22 – 25 April 2003.
[27] European Space Agency, “Navigate via the Web with the SISNeT receiver,” ESA
Press
Release,6
September
2002,
availableat
http://www.esa.int/export/esaSA/ESAW0OZPD4D_navigation_0.html[28] R. Chen, F. Toran-Marti and J. Ventura-Traveset. “Access to the EGNOS Signal In
Space Over Mobile-IP,” GPS Solutions (2003), Vol. 7,No. 1.
[29] European Space Agency, “Toulouse bus test-drives European satellite navigation,”
ESA
Press
Release,14
February
2003,
availableat
http://www.esa.int/export/esaSA/SEM4HZ1A6BD_navigation_0.html[30] E. Gonzalez, M. Toledo, A. Catalina, C. Barredo, F. Toran, J. Ventura and A.
Salonico. “Proposal of an Internet-Based EGNOS Receiver Architecture and
Demonstration of the SISNET Concept,” ION GPS 2003, Portland (Oregon), US,
September 2003.
[31] M. Toledo, E. Gonzalez, F. Toran and J. Ventura, “Proposal of an Internet-Based
EGNOS Receiver: Architecture and Demonstration of the SISNET Concept.”
Proceedings of the 11th IAIN World Congress, October 2003, Berlin (Germany).
[32] European Space Agency, “Space technology to help the blind,” ESA Press Release,30
December2003,
availableat
http://www.esa.int/export/esaSA/SEM4HZ1A6BD_navigation_0.html[33] Catalina A., March J., Davila R., Paniagua J., Busnadiego C., Ventura-Traveset J.,
Toran-Marti F., Fernandez-Coya J.L., Lorente J.L., “Blind Pedestrian Navigator:

User Interface Document

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Page : 48

Operating Features, Performances and EGNOS / SISNET Benefits,” Proceedings of
GNSS 2003, Graz (Austria), 22 – 25 April 2003.
[34] L. Schone, H. Zunker, F. Torán-Martí and J. Ventura-Traveset, “Applying SISNeT
through RTCM Interface.” Proc. of the European Navigation Conference GNSS
2004, Rotterdam (The Netherlands), May 2004.
[35] H. Zunker, JL Gerner, W. Richter, P. Boysen, P. Chaves, "Road Transport andMaritime EGNOS Application Terminals,“ Proc. of the European Navigation
Conference GNSS 2004, Rotterdam (The Netherlands), May 2004.
[36] C. Busnadiego-Gutiérrez and S. Gutiérrez-Lanza. "Navigator for Blind People on a
Mobile Phone". To appear in Proc. of the European Navigation Conference 2006.
May 2006.
[37] European Space Agency. ESA News. “Satellite Navigation Receiver Uses EGNOS
Signals
Deliveredvia
theInternet”.
http://www.esa.int/esaNA/SEMW614J2FE_index_0.html[38] F. Toran, J. Ventura-Traveset and J.C. de Mateo, "ESPADA 3.0: An innovative
EGNOS Simulation Tool Based on Real Data," ESA Journal preparing for the
Future, in press.
[39] A. García, C. Garriga, P. Michel and J. Ventura-Traveset, "EGNOS Simulation Tool
for Performance Assessment and Design Analysis (ESPADA)," ESA Journal
preparing for the Future, Vol. 7, No.4, December 1997.
[40] F. Toran, "Advanced Simulation Tool for Satellite Navigation: from Radio
Frequency to Positioning Using Real Data," Research Work Essay, Directed by Dr.
Diego Ramirez (University of Valencia) and Dr. Javier Ventura-Traveset (ESA),
July 2001.
[41] C. Busnadiego, S. Gutierrez-Lanza, F. Toran-Marti and J. Ventura-Traveset.
“Navigator for Blind People on a Mobile Phone”. Proc. of the European Navigation
Conference 2006. Manchester (UK). May 2006.
[42] "Standard Positioning Service GPS," US DoD, Washington, October 2001.

User Interface Document

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Page : 49

6. LIST OF ACRONYMS
AM
ADM
AL
BS
BSS
DA
DS
DSS
DS2DC
EGNOS
EM
ESTB
FTP
GEO
GUI
JPEG
MT
PRC
PRN
RC
RCS
SC
SDS
SE
SINCA
SIS
SISNeT
SUI
TCS
UAS
UDRE
UID
VPL
WWW

A–Message (Answer–Message)
Analysis of DS2DC Messages
Alarm Limit
Base Station
Base Station Software
Decompression Algorithm
Data Server
Data Server Software
Data Server to Data Client protocol
European Geostationary Navigation Overlay Service
E–Message (Event triggered–Message)
EGNOS System Test Bed
File Transfer Protocol
Geostationary Satellite
Graphical User Interface
Joint Photographic Experts Group
Message Type
Pseudo-Range Correction
Pseudo-Random code number
R–Message (Request–Message)
Receiver Control Software
S–Message (Service–Message)
SISNeT Data Server
Software Engineering
SISNeT Compression Algorithm
Signal In Space
Signal In Space through the interNET
SISNeT User Interface
TCP/IP Client Socket
User Application Software
User Differential Ranging Error
User Interface Document
Vertical Protection Limit
World Wide Web

User Interface Document

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Page : 50

APPENDIX A. DS2DC Message Reference.
The different messages available in the DS2DC protocol are explained in this section. Please notethat each message should terminate in a CRLF or LF. This is one of the major changes
implemented in this version 3.1 of SISNeT. Please refer to Section 1.4 for more information on thischange. It is important to note that any message shall end with:••

A line feed (LF) character, orA carriage-return character followed by a line feed character (CRLF).

Depending on their directionality, the messages can be classified in two groups:•

Messages going from the UAS to the DS. Following the SISNeT terminology, thesemessages receive the name of R-Messages or RMs, since they usually Request services tothe DS. The R-Messages are usually called “DS2DC messages”.

•

Messages going from the DS to the UAS. Following the SISNeT terminology, thesemessages receive the name of S-Messages or SMs, since the DS uses them to provide a
Service. The SMs can be classified in two groups:
o SMs sent as a response to previously sent RMs. These messages receive the nameof A-Messages or AMs, since they provide an Answer.
o SMs spontaneously sent by the DS. These messages receive the name of EMessages or EMs, since they usually act as Event-trigger signals.

User Interface Document

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Page : 51

AUTH Message

Type
R–Message
PurposeThis R–Message is the first to be sent after connecting to the Data Server. It is the base of the
SISNeT authentication protocol, providing information on a particular SISNeT account (i.e.
username and password). This message has an optional field that allows the user to quickly
initialise his receiver. The format is shown below. If the AUTH message ends with a ‘q’ then theserver will return *AUTH followed by all the necessary messages to initialize the receiver(separated by LF or CRLF). If the optional ‘q’ field is omitted, the user is simply authorised toaccess the SISNeT data server, provided the user name and password are correct.
FormatFields:
Field
AUTH
User
Passwordq

Comments
The message name
Username corresponding to a valid SISNeT account.
The corresponding password.
This field is optional and can be used to quickly initialise thereceiver.

User Interface Document

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Page : 52*AUTH Message

Type
A–Message
PurposeThis message gives a positive answer to the AUTH message, indicating that a remote user isauthorised to use the Data Server. If the user is not authorised, an *ERR message (error code 2)
will be sent instead. Section 4.3 of this Document explains the details of the authentication
protocol. If the AUTH message ends with a ‘q’ then the server will return *AUTH followed by all
the necessary messages to initialize the receiver (separated by LF or CRLF). If the optional ‘q’
field is omitted, the user is simply authorised to access the SISNeT data server, provided the username and password are correct.
FormatFields:
Field
*AUTH

Comments
The message name

User Interface Document

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Page : 53

MSG Message

Type
R–Message
PurposeThis RM asks the DS for the most recent EGNOS message. This RM is intended to be used in asynchronous way, i.e. sending the MSG message, and waiting for the response, and then sending
another MSG message, and so on. Loss of messages could appear, especially when connecting to
the Internet via GSM or GPRS links. The DS2DC protocol offers a solution to the problem of
message losses: the possibility to retrieve an already broadcast EGNOS message after detecting its
absence. See the ‘GETMSG’ RM.

FormatFields:Field
MSG

Comments
The message name.

Remarks:•••

The DS shall ignore any field included in this message.
If (for any reason) the DS cannot provide the service to the UAS, a '*ERR' message will be
returned.
The UAS is expected to send this message once per second. However, higher rates can be
employed, depending on the concrete characteristics of the communications link.

User Interface Document

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Page : 54*MSG Message

Type
A–Message
PurposeThis AM constitutes an immediate answer to the MSG message, returning the most recent EGNOS
message, along with the GPS week and GPS time. The EGNOS message is provided in thehexadecimal format.
FormatFields:Field*MSG
GPS Week
GPS time
EGNOS message (hex)Comments
The message name.
The GPS week corresponding to the EGNOS
message
The GPS time corresponding to the EGNOS
message
The EGNOS message, compressed through the
SINCA algorithm (see Sections 4.4 and 4.5)

Remarks:•

The GPS week number is represented using 10 bits, so that the number ranges form 0 to1023. At the time of this writing (May 2006), the first rollover was crossed. Since SISNeT
can use different kinds of EGNOS receivers, and each receiver works with a different GPS
week format, it is possible to receive a GPS week that does not take rollover into account.
For instance, if the UAS receives a week number of 78, this means the real week is
78+1024=1102. On the other hand, if the UAS receives week 1102, no processing isneeded. The developer of the UAS must take this effect into account.

User Interface Document

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Page : 55

GETMSG Message

Type
R–Message
PurposeThis RM allows the user retrieving an SBAS message already broadcast by EGNOS. The SISNeT
Data Server configuration determines the length of the historical archive. As a rule, the Data Server
will always try to make available the latest 30 messages of each message type.
FormatFields:Field
GETMSG
Message TypeOrder
Occurrence

Comments
The message name.
The message type number corresponding to the SBAS
message to retrieve.
of The order of occurrence. A value of 1 means the last
occurrence of the selected message type, and so on. For
instance, say the ESTB broadcasts MT1 at time t1, and thenext time it broadcasts MT1 is at time t2. Then,“GETMSG,1,1” will return MT1 broadcasted at t2, while“GETMSG,1,2” will return the MT1 broadcasted at t1.

User Interface Document

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Page : 56*GETMSG Message

Type
A–Message
PurposeThis AM constitutes an immediate answer to the GETMSG message, returning the selected(already broadcast) SBAS message.
FormatFields:Field*GETMSGGPS Week
GPS time
EGNOS message (hex)Comments
The message name.
The GPS week corresponding to the EGNOS
message
The GPS time corresponding to the EGNOS
message
The EGNOS message, compressed through the
SINCA algorithm (see Sections 4.4 and 4.5)

User Interface Document

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Page : 57

START Message

Type
R–Message
PurposeThis RM is useful when the user wishes to receive EGNOS messages continuously. Sending thismessage to the DS is equivalent to sending the MSG message every second. The data server
answers with the EGNOS messages continuously until the STOP message is received.

FormatFields:
Field
START

Comments
The message name.

User Interface Document

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Page : 58*START Message

Type
A–Message
PurposeThis AM constitutes an immediate answer to the START message. This AM is immediately
followed by continuous *MSG messages each returning the most recent EGNOS message, alongwith the GPS week and GPS time, until the STOP message is sent. The EGNOS message isprovided in the hexadecimal format.
FormatFields:Field*START

Comments
The message name.

User Interface Document

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Page : 59

STOP Message

Type
R–Message
PurposeThis RM is useful when the user wishes to stop receiving the EGNOS messages, that had been
started by the START message.

FormatFields:Field
STOP

Comments
The message name.

User Interface Document

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Page : 60*STOP Message

Type
A–Message
PurposeThis AM constitutes an immediate answer to the STOP message and the continuous EGNOS
messages, which were being received due to the START message, stop.
FormatFields:
Field
*STOP

Comments
The message name.

User Interface Document

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Page : 61

EPHEM Message

Type
R–Message
PurposeThis RM requests information on the GPS ephemeris. The second field specifies the PRN number
for which the information is requested. The resulting information is returned through the *EPHEM
message, being expressed in a RINEX-like format, i.e. containing 8 lines of ASCII characters. The
following example shows the GPS ephemeris information corresponding to PRN 1, on the 24th ofApril 2002 at 6:00:00 UTC:
1 02 4 24 6 0 0.0 .226148404181D-03 .159161572810D-11 .000000000000D+00.710000000000D+02 .237500000000D+02 .499163649312D-08 .299753671406D+01.101514160633D-05 .530451152008D-02 .300258398056D-05 .515364340401D+04.280800000000D+06 .968575477600D-07 -.217827995687D+01 -.651925802231D-07.968381023219D+00 .326937500000D+03 -.168433737953D+01 -.847713882114D-08.284654714154D-09 .000000000000D+00 .116300000000D+04 .000000000000D+00.400000000000D+01 .000000000000D+00 -.325962901115D-08 .583000000000D+03.280799000000D+06

The *EPHEM message does not return the whole block of lines. Instead, each line must be
requested separately. The line number to receive is indicated through the third parameter.
Following the example above, if the client application sends:
EPHEM,1,3
The answer from the DS will be:*EPHEM,.101514160633D-05 .530451152008D-02 .300258398056D-05 .515364340401D+04
FormatUser Interface Document

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Page : 62

Fields:
Field
EPHEM
PRN
Line

Comments
The message name
PRN of the GPS satellite for which ephemeris information isrequested
A number between 1&8 (both inclusive), identifying a line of theresulting RINEX-like block

User Interface Document

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Page : 63*EPHEM Message

Type
A–Message
PurposeThis AM constitutes an immediate answer to an EPHEM message. It contains the ephemeris
information for the requested GPS satellite in a RINEX-like format, i.e. 8 lines of ASCII
characters. The information is retrieved on a line-by-line basis. As a consequence, the *EPHEM
message returns – for the requested PRN – just the requested line of the corresponding RINEX-likeblock. Therefore, 8 *EPHEM messages are needed to retrieve all the ephemeris information for agiven satellite.
FormatFields:Field*EPHEM
Text string

Comments
The message name
The requested line of the RINEX-like block, corresponding to therequested GPS satellite.

Remarks:••

If no information is available for the requested PRN, error code 6 is returned.
The associated EPHEM message must requested a line number greater than 1 and lower
than 8 (both inclusive). Otherwise, error code 5 is returned.

User Interface Document

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Page : 64

GPS_IONO Message

Type
R–Message
PurposeThis RM requests the 8 parameters (α0, α1, α2, α3, β0, β1, β2 and β3), of the Klobuchar ionosphericmodel (broadcast by the GPS system).
FormatFields:Field
GPS_IONO

Comments
The message name.

User Interface Document

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Page : 65*GPS_IONO Message

Type
A–Message
PurposeThis AM answers a "GPS_IONO" message, providing the 8 parameters of the Klobuchar
ionospheric model (α0, α1, α2, α3, β0, β1, β2 and β3). Those parameters are broadcast by the GPS
system.
FormatFields:Field*GPS_IONO
α0…α3, β0…β3

Comments
The message name.
Parameters of the Klobuchar ionospheric model

Remarks:
If no information is available, each parameter is substituted by the " – " character.

User Interface Document

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Page : 66*ERR Message

Type
A–Message. Note this message is an exception to the naming rule for A–Message. It uses the samemessage name for answering any R–Message.
PurposeThis AM informs about any error thrown during the communications between the UAS and the DS.
FormatFields:Field*ERR
Error code
Error message

Comments
The message name.
A number identifying the error. It is used by the UAS toeasily identify what has happened and how to proceed.
A text string explaining the error.

Remarks:
See Appendix B for a comprehensive reference of error codes and messages.

User Interface Document

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Page : 67*TXT Message

Type
E–Message
PurposeThe DS uses this message to broadcast text messages to all the users connected to SISNeT. The
UAS should be able to present the received text messages, normally using a GUI. Some possible
usages of those messages are the following:••

Informing the users about SISNeT-related events (e.g. new enhancements);
Warning the users about a scheduled outage of the SISNeT service;

FormatFields:Field*TXT
Text string

Comments
The message name
The text broadcast from the DS

User Interface Document

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

Page : 68

APPENDIX B. SISNeT Error Codes and Error Messages.
Error Code
1

2

3

4

5
6
7

Error Message
Authorisation required

Comments
This error code is returned when theclient application sends a DS2DC
messagewithout
successfully
passing the initial authentication
process.
After
receivingthismessage, the client is disconnectedfrom the DS. If the client maintains
the same attitude (i.e. avoiding theauthentication process), a penalty
will be applied (e.g. access denied
for a certain number of hours).
Access Denied
Indicates the user has not
successfully
passedtheauthentication process. Hence, theaccess to SISNeT is denied. If theuser fails to pass the authorisation
process more than N times, a penalty
will be applied (N to be determinedand susceptible to change during theoperational life of SISNeT)
Unknown DS2DC Message
Returned when the Data Server
receives an unknown message. A
penalty is applied if a given user
continuallysends
unknown
messages.
Message was not successfully Indicates the Data Server was notcompletedable to complete the requested
action. This can be due to several
reasons, e.g. eventual failures. The
user is encouraged to report thissituation to the SISNeT team.
An EPHEM message has requested a
Invalid line number (x)line number (x) less than 1 or greaterthan 8.
Information not available for PRN x There is no ephemeris information
available for the requested PRN (x).
Requested EGNOS message is not The message requested through aavailable
GETMSG message is not available.

User Interface Document

GNSS-1 Project Office
Ref : E-RD-SYS-31-010
Issue : 3
Rev. : 1 Date : 15/05/2006

8
9
10

GPS week not available
GPS time not available
Already authorized.

Page : 69

Reserved Error Message.
Reserved Error Message
This message is returned when the
UAS sends an AUTH message,
having successfully passed theauthentication process. Note thatsome implementations of the Data
Server could directly disconnect theuser when attempting to AUTH for
the second time, without sending
error message code 10.

User Interface Document