Internet DRAFT - draft-tyson-lgsp
draft-tyson-lgsp
Network Working Group M R. Tyson
Internet-Draft C. Kopp
Intended status: Experimental Monash University
Expires: June 21, 2008 December 19, 2007
The Lightweight Global Navigation Satellite System (GNSS) Support
Protocol (LGSP)
draft-tyson-lgsp-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 21, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Tyson & Kopp Expires June 21, 2008 [Page 1]
Internet-Draft LGSP December 2007
Abstract
This document presents the Lightweight GNSS (Global Navigation
Satellite System) Support Protocol (LGSP). The Lightweight GNSS
Support Protocol (LGSP) is being developed in order to provide a
comprehensive solution which solves the problems inherent in
traditional radio-based Differential GPS (DGPS) protocols. LGSP will
also provide additional support for GNSS user equipment, such as a
GPS almanac retrieval method, allowing compatible units to perform
faster almanac acquisition, thus resulting in less time until an
initial position measurement can be established. Other supporting
features include alternative distribution of GPS navigation messages
and differential correction messages, a hierarchical mirroring
architecture, redundant backup operation and load balancing
functions.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. System Overview . . . . . . . . . . . . . . . . . . . . . 7
2.2. Protocol Overview . . . . . . . . . . . . . . . . . . . . 12
2.3. GNSS Message Overview . . . . . . . . . . . . . . . . . . 14
2.3.1. GPS Family Messaging . . . . . . . . . . . . . . . . . 15
2.3.2. Galileo Family Messaging . . . . . . . . . . . . . . . 16
2.3.3. GLONASS Family Messaging . . . . . . . . . . . . . . . 17
3. Protocol Definition . . . . . . . . . . . . . . . . . . . . . 19
3.1. Messaging Modes . . . . . . . . . . . . . . . . . . . . . 19
3.1.1. Request/Response . . . . . . . . . . . . . . . . . . . 19
3.1.2. Streaming . . . . . . . . . . . . . . . . . . . . . . 21
3.2. Basic Message Formats . . . . . . . . . . . . . . . . . . 24
3.2.1. Request Message . . . . . . . . . . . . . . . . . . . 25
3.2.2. Response Message . . . . . . . . . . . . . . . . . . . 26
3.2.3. Join Stream Request Message . . . . . . . . . . . . . 27
3.2.4. Join Stream Response Message . . . . . . . . . . . . . 28
3.2.5. GNSS Request Message . . . . . . . . . . . . . . . . . 29
3.2.6. GNSS Response Message . . . . . . . . . . . . . . . . 30
3.3. Robustness and Cryptographic Security . . . . . . . . . . 30
3.3.1. Protection For Request/Response Sessions . . . . . . . 31
3.3.2. Protection for Stream Sessions . . . . . . . . . . . . 32
3.4. Authentication for Access Control . . . . . . . . . . . . 33
3.5. Extension Provisions . . . . . . . . . . . . . . . . . . . 33
3.5.1. Extended Request Message . . . . . . . . . . . . . . . 35
3.5.2. Extended Response Message . . . . . . . . . . . . . . 35
3.6. Mirroring . . . . . . . . . . . . . . . . . . . . . . . . 37
3.6.1. Full Sync Request Message . . . . . . . . . . . . . . 38
3.6.2. Full Sync Response Message . . . . . . . . . . . . . . 39
Tyson & Kopp Expires June 21, 2008 [Page 2]
Internet-Draft LGSP December 2007
3.6.3. Differential Sync Request Message . . . . . . . . . . 41
3.6.4. Differential Sync Response Message . . . . . . . . . . 42
3.7. Backup Servers . . . . . . . . . . . . . . . . . . . . . . 42
3.8. Status Information . . . . . . . . . . . . . . . . . . . . 45
3.8.1. Status Request Message . . . . . . . . . . . . . . . . 45
3.8.2. Status Response Message . . . . . . . . . . . . . . . 46
3.9. Load Balancing . . . . . . . . . . . . . . . . . . . . . . 47
4. System Protocol Identifiers . . . . . . . . . . . . . . . . . 49
4.1. System Identifiers . . . . . . . . . . . . . . . . . . . . 49
4.2. Request Types . . . . . . . . . . . . . . . . . . . . . . 49
5. Reserved Response Codes . . . . . . . . . . . . . . . . . . . 53
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54
7. Security Considerations . . . . . . . . . . . . . . . . . . . 55
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 56
8.1. Normative References . . . . . . . . . . . . . . . . . . . 56
8.2. Informative References . . . . . . . . . . . . . . . . . . 56
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 59
Intellectual Property and Copyright Statements . . . . . . . . . . 60
Tyson & Kopp Expires June 21, 2008 [Page 3]
Internet-Draft LGSP December 2007
1. Introduction
Global Navigation Satellite Systems comprise constellations of
orbiting satellites that transmit specific signals to Earth, which
are utilised by a receiver to calculate an estimated location of the
user (Figure 1). Such systems, which include the U.S. Global
Positioning System (GPS), the Russian Global Navigation Satellite
System (GLONASS), and the fledgling European Galileo, are utilised
for a variety of applications, including land, air and sea
navigation, surveying and geology and accurate positioning for
military applications. [GLONASS-ICD][GPS-IS][Galilei][GGW]
GPS SV GPS SV
GPS SV =||= =||= GPS SV
=||= \ / =||=
`-. \ / .-'
`-. \ / .-'
`-._ \ / .-'
`-. \ / .-'
`-.\ /.-'
,
<==/= Airborne platform
with GPS receiver hardware
_,..-------..._
,.-'' `'-..
,-' `-.
-' EARTH `-
Figure 1: GPS CONOPS Example
Due to a variety of factors including atmospheric effects such as
tropospheric and ionospheric delays, clock drift, out-of-date orbital
data and geometrical dilution of precision, the calculated positions
typically involve some time variant error. In order to improve
precision, various differential schemes have been developed. These
mostly employ precisely surveyed ground-based stations which generate
and distribute periodic correction messages for use by compatible
receivers. Such Differential GPS (DGPS) systems can operate in a
local geography, essentially generating differential co-ordinates
that offer accurate corrections within a small area - these are known
as Local Area DGPS systems (LADGPS). Alternatively, Wide Area DGPS
systems (WADGPS) offer corrections that are valid over a much larger
area, generally continental, and typically generate models to
represent different sources of error, instead of simple offset co-
ordinates (Figure 2). [LAAS][WAAS][EDGE][WAGE]
Tyson & Kopp Expires June 21, 2008 [Page 4]
Internet-Draft LGSP December 2007
\\ Communications SV
=== (INMARSAT I-3)
\\
|
GPS SV | GPS SV
GPS SV =||= | =||= GPS SV
=||= \ | / =||=
`-. \ | / .-'
`-. \ | / .-'
`._ \ | / .-'
`-. \ | / .-'
`-.\|/.-'
'
__ <==/= Airborne platform
VHF __.-''
WAAS (' _,..-------..._
GS \\,.-' `'-..
,-' `-.
-' EARTH `-
Figure 2: WAAS CONOPS Example
Differential GPS corrections are typically broadcast over a
specialised radio channel. The widely used WADGPS system known as
the Wide Area Augmentation System (WAAS) [WAAS], developed by the
Federal Aviation Administration (FAA), uses a number of satellites to
broadcast differential information. Most LADGPS systems, such as the
FAA's Local Area Augmentation System (LAAS) [LAAS], use a local radio
transmitter to distribute corrections.
There are a number of drawbacks inherent in traditional DGPS systems.
The use of a radio link for DGPS means that a dedicated, discrete
channel is required for each system. Firstly, hardware for
maintaining a radio link represents a significant cost to a DGPS
system, both monetarily and in terms of power consumption, hardware
reliability and heat dissipation. A dedicated channel also results
in relatively sub-optimal use of the available radio spectrum, a
finite resource. As wireless technologies become increasingly
popular, and radio spectrum usage increases, it will be increasingly
important to utilise spectrum efficiently. In addition, the
widespread use of wireless devices, as well as digital electronics in
general, results in interference issues. Combined with intentional
jamming, this presents a developing vulnerability for radio-based
DGPS, requiring more robust and complex components, in turn raising
the cost of DGPS hardware. Traditional DGPS channels also typically
have a low data rate, resulting in slow update rates. Multipath and
other radio propagation issues represent another impairment, further
constraining traditional DGPS system implementations.
Tyson & Kopp Expires June 21, 2008 [Page 5]
Internet-Draft LGSP December 2007
Many DGPS-equipped platforms also contain some other form of wireless
connectivity, such as IP (Internet Protocol) [RFC0791] wireless via
satellite or another high capacity channel like the U.S. Military's
Joint Tactical Information Distribution System (JTIDS)
[JTIDS-MIDS][JTIDS-IP] or civilian channels such as WiFi
[IEEE802.11], WiMAX [WiMax] or GPRS [GPRS].
Such channels are typically more robust, faster and more affordable
than specialised dedicated links, and are typically also
bidirectional, providing for more flexible operation. By using an
existing channel for DGPS correction update distribution, instead of
establishing new dedicated channels, costs can lowered, while
increasing robustness and availability of communications. If a DGPS
system makes use of an established link technology, dedicated radio
hardware is not required. In addition, existing channels typically
provide high availability, jam or interference resistance and
reliability, which a DGPS system would benefit from.
Tyson & Kopp Expires June 21, 2008 [Page 6]
Internet-Draft LGSP December 2007
2. Overview
LGSP is a client/server protocol. It allows clients to retrieve
GNSS-related data, such as almanac data, or DGPS corrections. LGSP
operates over UDP, and does not keep per-session state except where
necessary for channel protection purposes.
LGSP defines a modular architecture, providing for future expansion
and new message types. LGSP has a redundant hierarchical structure
of LGSP Master Nodes and LGSP Mirror Nodes, providing a high degree
of robustness.
A number of message types are defined in this document for the three
main GNSS systems, the United States' Global Positioning System (GPS)
[GPS-IS], the European Galileo [Galilei] and the Russian GLONASS
[GLONASS-ICD], and a few augmentation systems such as the Wide Area
Augmentation System (WAAS) [WAAS].
LGSP offers both protected and unprotected modes, for operation on a
variety of channel types. LGSP's protected mode offers channel
protection in the form of encryption, wrapped in a FEC (Forward Error
Control) code, and is designed for operation over rudimentary
channels lacking adequate protection. Alternatively, LGSP's
unprotected mode is designed for more robust and secure channels,
which already have protection and thus do not require the overhead of
addition protection layers.
Additional LGSP features include mirroring, load balancing and
provisions for multiply-redundant backup server operation.
2.1. System Overview
The system architecture of a single LGSP server comprises three
elements: One or more source feeds, a server unit, and client units
(Figure 3) [LGSP].
Tyson & Kopp Expires June 21, 2008 [Page 7]
Internet-Draft LGSP December 2007
Sources Clients
,-. ,-.
( )---. ,-->( )
`-' | | `-'
| +-------------+ |
,-. '-->| LGSP |---' ,-.
( )------>| |------>( )
`-' .-->| STATION |---. `-'
| +-------------+ |
,-. | | ,-.
( )---' '-->( )
`-' `-'
Figure 3: System architecture overview
Source feeds are incoming sources of data. This can be a radio
receiving transmitted DGPS signals such as WAAS [WAAS], for example.
Alternatively, a direct communications link to a DGPS station could
replace the radio receiver, offering a more reliable and high-
bandwidth link. Such a software module would store received messages
in a buffer, for subsequent retrieval by clients.
A local geographically-surveyed GPS receiver with accompanying
software to generate a Local Area DGPS signal could be used as
another source feed. Additionally, a GPS receiver can be used to
record GPS messages for subsequent distribution.
A direct communications link to a GNSS control centre offers a
reliable and flexible high-bandwidth link for direct distribution of
GNSS navigation messages. This allows LGSP to offer a high
performance distribution channel for navigation data, as well as for
supporting GNSS data that may not be feasibly broadcast over the
traditional space-based channel, due to bandwidth, latency or
security limitations.
Wide area differential systems, such as the US Air Force EDGE RRN
demonstrator [EDGE] and WAGE [WAGE] system represent other possible
sources of data, either via a radio link or a direct connection to a
master station.
Source feeds are paired with an accompanying software module within
the LGSP server software, which provides functionality for storing
and later accessing the source data. Each software module implements
a source-specific network protocol that is encapsulated within LGSP,
and understood by a corresponding software module located in the LGSP
client software.
The LGSP server is a unit which assimilates the data incoming from
Tyson & Kopp Expires June 21, 2008 [Page 8]
Internet-Draft LGSP December 2007
the sources, and provides an interface (LGSP) for dissemination of
this data. The LGSP server provides a relatively simple and robust
mechanism for serving clients. The server is largely stateless,
except for provisions for streaming functionality and channel
protection, and thus does not attempt to provide guaranteed service
in any way. This enhances the protocol's robustness, so that clients
operating over unstable channels do not needlessly tie up server
resources. No retransmissions are attempted in the case of packet
loss when sending to a client. Connectionless UDP datagram
communications are used, which ensures that server resources will not
be tied up if a client drops out. These features are tailored for
maximum performance in the presence of a poor network operating
environment, with frequent disconnections and packet loss; such
conditions are common in a mobile wireless scenario.
We envisage a hierarchy of LGSP servers with redundancy, similar in
concept to that of DNS (Domain Name System) [RFC1034][RFC1035]. LGSP
Master Station Nodes form the top level of the hierarchy, while LGSP
Mirror Nodes form the remainder of the tree.
Clients access LGSP Mirror Nodes only. LGSP Master Station Nodes
will only accept connections from other LGSP Master Station Nodes, or
LGSP Mirror Nodes. This avoids the danger of overloading an LGSP
Master Station Node with too many incoming connections, as there will
only ever be a relatively small number of LGSP Mirror Nodes
connecting to an LGSP Master Station Node at any time.
As in DNS's redundant name server architecture, LGSP clients maintain
knowledge of multiple LGSP Mirror Nodes, for redundancy and load
balancing purposes (Section 3.9). Similarly, LGSP Mirror Nodes
themselves can maintain knowledge of multiple LGSP Mirror Nodes and
multiple LGSP Master Nodes.
The two LGSP server types are defined below:
Tyson & Kopp Expires June 21, 2008 [Page 9]
Internet-Draft LGSP December 2007
,-.
( )--.
`-' |
| +----------------+ ,-. ,-.,-. +--+
,-. '-->| MASTER STATION | ( ) +--+ |
( )----->| |----> ; NETWORK'. ---> | | |
`-' .-->| NODE | ( ) | |-+
| +----------------+ `-'( )`-' +--+
,-. | ` '
( )--' LGSP
`-' Mirror
GNSS master stations Nodes
Local Area DGPS feed
GNSS SVs
Network
Figure 4: LGSP Master Station example
An LGSP Master Station Node (Figure 4) provides service to LGSP
Mirror Nodes, forming the top level of the hierarchy. Master Station
Nodes can typically have a connection to a GNSS master station, such
as the GPS control segment.
The primary function of LGSP Master Station Nodes is to present a
standard interface to access GNSS data from one or more GNSS master
stations. This also offers firewall-type functionality to isolate
the GNSS master stations. LGSP Master Station Nodes can also source
data from elsewhere, such as a Local Area DGPS feed.
LGSP Master Station Nodes will only accept connections from LGSP
Mirror Nodes, and reject connections from LGSP clients. LGSP clients
connect to an LGSP Mirror Node to gain access. This avoids possible
overloading of the LGSP Master Node, ensuring maximum availability.
Tyson & Kopp Expires June 21, 2008 [Page 10]
Internet-Draft LGSP December 2007
+---+ ,-. ,-.,-.
| | ( )
| |--> ; NETWORK'.
| | ( ) ,-.
+---+ `-'( )`-' +->( )
LGSP ` ' | | `-'
MASTER | +----------------+ ,-. ,-.,-. |
NODE ,-. '-->| | ( ) --' ,-.
( )----->| MIRROR NODE |--> ; NETWORK'. ---->( )
`-' .-->| | ( )--. `-'
| +----------------+ `-'( )`-' |
,-. | ` ' | ,-.
( )--+ +->( )
`-' `-'
Local Area DGPS feed LGSP Clients
GNSS SVs
Figure 5: LGSP Mirror Node example
LGSP Mirror Nodes (Figure 5) connect to one or more LGSP Master
Station Nodes and mirror data to a local cache, which is updated
periodically (Section 3.6). LGSP Mirror Nodes provide both
redundancy and load balancing (Section 3.9). A Mirror Node that is
geographically proximate to a client accessing it offers reduced
latency as communications have less distance to travel, and greater
security due to the shorter communication path, resulting in less
exposure to malicious parties.
LGSP Mirror Nodes can also obtain data from other sources, such as a
Local Area DGPS feed, as described above. Additionally, an LGSP
Mirror Node that loses all connections to other LGSP Mirror Nodes or
LGSP Master Nodes can source GNSS data from a GNSS satellite. Such
functionality can be considered a 'casualty mode' that provides some
level of service even in the event of multiple connection failures to
LGSP Master Nodes or LGSP Mirror Nodes.
An LGSP client, when accessing an LGSP Mirror Node, will request the
current status of the Mirror Node. The client will evaluate the
response, and determine the level of load the Mirror Node is under.
If load is high, the client will attempt a connection with the next
LGSP Mirror Node it is aware of. By adding load sharing facilities
to the communication protocol, clients actively avoid placing too
much strain on the resources of any particular LGSP Mirror Node
(Section 3.9).
Similarly, if a connection to an LGSP Mirror Node fails, an LGSP
client will simply move on to the next LGSP Mirror Node it is aware
of. In the same fashion, LGSP Mirror Nodes will attempt to contact
Tyson & Kopp Expires June 21, 2008 [Page 11]
Internet-Draft LGSP December 2007
other LGSP Master Station Nodes or Mirror Nodes if a connection
cannot be made. This redundant architecture offers considerably more
robustness than an architecture with a single point-of-failure.
LGSP clients are units connected to the LGSP server via a network
connection, typically the Internet or another network with the
capability to tunnel IP traffic: a military network such as JTRS
[JTRS], Joint Tactical Information Distribution System/
Multifunctional Information Distribution System (JTIDS/MIDS)
[JTIDS-MIDS], a Satcom link, IP over Improved Data Modem (IDM) links,
or IP over Family of Advanced Beyond-Line-of-Sight Terminals (FAB-T)
links [FAB-T], or a civilian system like WiMAX [WiMax], GPRS [GPRS],
WiFi [IEEE802.11] or GSM [GSM].
LGSP clients could be human portable devices with integrated GPS
navigation systems such as a mobile phone, PDA (Portable Data
Assistant) or a laptop, or GPS-equipped platform devices, such as an
airborne platform, automobile or ship.
LGSP clients will be equipped with GPS receiver hardware and other
supporting infrastructure. In the case of a platform-based client,
the LGSP client software can be integrated into the navigation
computer, with few other modifications required.
2.2. Protocol Overview
LGSP makes data available to clients via two messaging mechanisms: A
request/response mechanism, and a multicast streaming mechanism
(Section 3.1). The former involves a single request message
originating from a client, invoking a single response message from
the server. This is a self-contained transaction, and no state is
maintained between such transactions. The latter, multicast
streaming mechanism, allows data to be continually broadcast to
listening clients, and is initiated upon an initial request by a
client.
LGSP's request/response mode is simple, and by not maintaining state
between consecutive transactions is able to remain robust and
efficient in the face of unreliable connections. As no persistent
state is maintained between connections, few resources are expended
on maintaining sessions. This is an important property for a
protocol that may frequently operate over unreliable channels.
LGSP's multicast streaming mode offers a mechanism to distribute data
to a large number of clients, with lower bandwidth and processor
resource requirements than would otherwise exist with only a per-
client request/response mode.
Tyson & Kopp Expires June 21, 2008 [Page 12]
Internet-Draft LGSP December 2007
Request/response mode is suitable for messaging formats which offer
discrete blocks of data with a relatively slow update rate, or which
require bidirectional communication. Streaming mode suits system
protocols which distribute continuous streams of information, such as
frequent local Differential GPS (DGPS) updates. In particular, the
use of streaming modes is appropriate when the distributed data has a
short life-span.
LGSP is designed to be operated over a wide variety of channel types.
These could include secure and robust channels such as the U.S.
Military's Joint Tactical Radio System (JTRS) or the Joint Tactical
Information Distribution System (JTIDS), or the civilian WiMAX.
Alternately, channels may also possess poor security features and/or
poor reliability and robustness; such channels include GPRS, WiFi, or
rudimentary satellite communications links.
To cater for this large variation in channel characteristics, LGSP
defines a protected mode and an unprotected mode (Section 3.3).
LGSP's protected mode, designed to be used in situations where a
rudimentary channel with poor or absent security or reliability is
used, adds an encryption and Forward Error Correction (FEC) layer to
LGSP communications. This mode is also used to support
authentication, via a standard certificate system.
LGSP's unprotected mode, on the other hand, is designed to operate
over channels that already possess sufficiently high-grade security
and robustness. In unprotected mode, LGSP messages are passed in
cleartext. Unprotected mode avoids the extra overhead of protected
mode when such protection is not necessary.
To aid development of new system protocols for LGSP, an extension
mode is offered, which allows developing system protocols to be
rapidly integrated into LGSP during development Section 3.5. Upon
completion of development on such new system protocols, it is
intended that a final top-level system protocol identifier is to be
allocated, administered by the Internet Assigned Numbers Authority
(IANA).
LGSP defines a hierarchical architecture of LGSP Master Station Nodes
and LGSP Mirror Nodes. This provides a high degree of robustness to
the network architecture. To support this capability, a series of
messages are defined to provide mirroring functionality between
Mirror Nodes and Master Station Nodes (Section 3.6).
This mirroring functionality also supports a redundant backup server
architecture (Section 3.7). This allows one or more backup servers
to monitor a primary server, and maintain synchronisation. After
detecting the failure of the primary server, a predefined order
Tyson & Kopp Expires June 21, 2008 [Page 13]
Internet-Draft LGSP December 2007
dictates which backup server takes over from the offline primary
server.
LGSP defines a status reporting facility, for administrative and load
balancing purposes (Section 3.8). This reports the level of load on
the LGSP server, along with other per-system protocol metrics, such
as reliability and age of data.
Load balancing functionality is also provided: All connecting LGSP
clients maintain a list of LGSP servers (Section 3.9). Upon
connection, the LGSP client selects a server at random, then queries
the server for its status. If the returned status information
reports that server load is too high, the LGSP client moves on to the
next server in its internal list.
2.3. GNSS Message Overview
LGSP provides support for most common GNSS message formats, including
GPS, GLONASS and Galileo, and several Differential GPS systems. It
also contains provisions for future additions.
When supporting an existing GNSS message format, the GNSS message
data structure is preserved, encapsulating GNSS messages unchanged
within LGSP messages. This allows the received messages at the LGSP
client to be de-encapsulated and passed to a compatible device or
software module without requiring significant changes to the device.
There are two modes of operation for interfaces; unicast request/
response, and streaming (Section 3.1). Unicast request/response
interfaces involve a single response from the LGSP server following a
request from a client. Streaming interfaces involve a client request
to begin receiving continually streamed data, until no more clients
are connected to the stream.
LGSP message formats (Section 3.2) provide for a large number of
modes (up to 255, plus one reserved utility mode), each of which can
contain up to 256 message types. This allows LGSP to support any
existing GNSS system, with provisions for later expansion.
The system protocols for the systems described in this section all
use the generic GNSS request/response message format defined in
Section 3.2.5, Section 3.2.6, or for streaming mode messages, the
join stream request defined in Section 3.2.3, Section 3.2.4.
Currently supported GNSS systems are defined below.
In the tables below, the 'ID' column describes the 'Request Type'
identifier of the message, while the 'Mode' column defines whether
Tyson & Kopp Expires June 21, 2008 [Page 14]
Internet-Draft LGSP December 2007
the given message is request/response (R/R) or a stream (S).
2.3.1. GPS Family Messaging
GPS messages are represented by the System ID constant SID_GPS.
GPS Messages
+----------------------------+----+---------------+----------+------+
| Message | ID | Payload Size | Update | Mode |
| | | (bits) | Rate | |
+----------------------------+----+---------------+----------+------+
| NAV message subframe | 1 | 300 | Minutes | R/R |
| | | | | |
| NAV message frame | 2 | 1500 | Minutes | R/R |
| | | | | |
| NAV message stream | 3 | 300 | Minutes | S |
| | | | | |
| CNAV message subframe | 4 | 300 | Minutes | R/R |
| | | | | |
| CNAV message frame | 5 | 1500 | Minutes | R/R |
| | | | | |
| CNAV message stream | 6 | 300 | Minutes | S |
| | | | | |
| CNAV-2 message subframe | 7 | 300 | Minutes | R/R |
| | | | | |
| CNAV-2 message frame | 8 | 900 | Minutes | R/R |
| | | | | |
| CNAV-2 message stream | 9 | 300 | Minutes | S |
| | | | | |
| Enhanced differential | 10 | Variable | Minutes | R/R |
| correction message | | | | |
| | | | | |
| Enhanced differential | 11 | Variable | Minutes | S |
| correction stream | | | | |
| | | | | |
| Almanac page | 12 | 300 | < 6 days | R/R |
| | | | | |
| Expansion mode | 13 | Variable | Variable | R/R |
+----------------------------+----+---------------+----------+------+
Wide Area Augmentation System (WAAS) messages are represented by the
System ID constant SID_WAAS.
Tyson & Kopp Expires June 21, 2008 [Page 15]
Internet-Draft LGSP December 2007
Wide Area Augmentation System (WAAS) Messages
+--------------------+----+--------------------+-------------+------+
| Message | ID | Payload Size | Update Rate | Mode |
| | | (bits) | | |
+--------------------+----+--------------------+-------------+------+
| MOPS Message | 1 | 250 | Seconds | S |
| stream | | | | |
| | | | | |
| MOPS Message block | 2 | 250 x N | Seconds | R/R |
+--------------------+----+--------------------+-------------+------+
Local Area Augmentation System (LAAS) messages are represented by the
System ID constant SID_LAAS.
Local Area Augmentation System (LAAS)/RTCM SC-104 Messages
+--------------------+----+--------------------+-------------+------+
| Message | ID | Payload Size | Update Rate | Mode |
| | | (bits) | | |
+--------------------+----+--------------------+-------------+------+
| RTCM Message | 1 | 990 | Seconds | S |
| stream | | | | |
| | | | | |
| RTCM Message block | 2 | 990 x N | Seconds | R/R |
+--------------------+----+--------------------+-------------+------+
GPS Special Applications messages are represented by the System ID
constant SID_GPS_SA
GPS Special Applications Messages
+--------------------+----+--------------------+-------------+------+
| Message | ID | Payload Size | Update Rate | Mode |
| | | (bits) | | |
+--------------------+----+--------------------+-------------+------+
| Pending definition | | | | |
+--------------------+----+--------------------+-------------+------+
2.3.2. Galileo Family Messaging
Galileo messages are represented by the System ID constant
SID_GALILEO.
Tyson & Kopp Expires June 21, 2008 [Page 16]
Internet-Draft LGSP December 2007
Galileo Messages
+---------------------+----+--------------------+------------+------+
| Message | ID | Payload Size | Update | Mode |
| | | (bits) | Rate | |
+---------------------+----+--------------------+------------+------+
| F/NAV message | 1 | 2500 | Minutes | R/R |
| subframe | | | | |
| | | | | |
| F/NAV message frame | 2 | 30000 | Minutes | R/R |
| | | | | |
| F/NAV message | 3 | 2500 | Minutes | S |
| stream | | | | |
| | | | | |
| I/NAV message | 4 | 7440 | Minutes | R/R |
| subframe | | | | |
| | | | | |
| I/NAV message frame | 5 | 178560 | Minutes | R/R |
| | | | | |
| I/NAV message | 6 | 7440 | Minutes | S |
| stream | | | | |
| | | | | |
| Almanac page | 7 | 250 | Minutes | R/R |
+---------------------+----+--------------------+------------+------+
EGNOS messages are represented by the System ID constant SID_EGNOS.
EGNOS Messages
+--------------------+----+--------------------+-------------+------+
| Message | ID | Payload Size | Update Rate | Mode |
| | | (bits) | | |
+--------------------+----+--------------------+-------------+------+
| MOPS Message | 1 | 250 | Seconds | S |
| stream | | | | |
| | | | | |
| MOPS Message block | 2 | 250 x N | Seconds | R/R |
+--------------------+----+--------------------+-------------+------+
2.3.3. GLONASS Family Messaging
GLONASS messages are represented by the System ID constant
SID_GLONASS.
Tyson & Kopp Expires June 21, 2008 [Page 17]
Internet-Draft LGSP December 2007
GLONASS Messages
+------------------------+----+------------------+-----------+------+
| Message | ID | Payload Size | Update | Mode |
| | | (bits) | Rate | |
+------------------------+----+------------------+-----------+------+
| Navigation message | 1 | 1275 | Minutes | R/R |
| frame | | | | |
| | | | | |
| Navigation message | 2 | 6375 | Minutes | R/R |
| superframe | | | | |
| | | | | |
| Navigation message | 3 | 1275 | Minutes | S |
| stream | | | | |
| | | | | |
| Almanac | 4 | 170 | Days | R/R |
+------------------------+----+------------------+-----------+------+
Tyson & Kopp Expires June 21, 2008 [Page 18]
Internet-Draft LGSP December 2007
3. Protocol Definition
This section describes LGSP's operation; in particular, basic message
types, management messaging formats, channel protection, mirroring
and backup functions, extension provisions and the expected system
protocol development path.
LGSP defines a modular architecture, which is reflected in the
messaging format. A series of identifiers in the LGSP message header
(System ID and Request Type) indicate the contents of the message.
A number of management messaging formats are defined. These support
LGSP features like mirroring and backups, which require regular state
synchronisation, and load balancing, which requires a query for load
on the target LGSP server. These messages are all identified by the
LGSP System ID constant SID_LGSP.
When LGSP is used over channels that provide weak or absent
encryption, a 'protected mode' is provided, that uses encryption and
Forward Error Correction (FEC). The FEC layer gives LGSP some
resilience to channel errors, and thus allows LGSP to utilise more of
the available bandwidth when running over rudimentary channels.
3.1. Messaging Modes
LGSP supports both a unicast request/response mode, as well as a
multicast streaming mode. These two separate mechanisms are tailored
to two distinct styles of GNSS-support messages. The first mode
supports on-demand messaging, where data is supplied only when it is
requested. This is used, for example, with the GPS almanac page
message format listed in Section 2.3.1. The second, streaming mode
supports real-time streaming messages such as WAAS [WAAS]. These
services continually transmit update information to clients, and thus
would not suit a unicast request/response delivery method.
3.1.1. Request/Response
The unicast request/response mode is a very simple, stateless
protocol. Clients send a UDP request message to the server, which
processes the data and returns a UDP response (Figure 11, Figure 13).
There is no more persistent state than is necessary for channel
encryption purposes; this maximises the robustness of the protocol in
the face of disconnections.
Refer Section 3.3 for security details.
The interface to the request/response mode can be defined in the C
language as:
Tyson & Kopp Expires June 21, 2008 [Page 19]
Internet-Draft LGSP December 2007
struct lgsp_request_t {
address host; /* Host to query (optional - will use
predefined hosts if not supplied) */
u8 system_id; /* ID of system */
u8 request_type; /* Type of request */
char* parameter; /* Parameter data (dependent on request
/* type and system ID) */
};
struct lgsp_response_t {
u8 system_id; /* ID of system */
u8 request_type; /* Type of request that initiated response */
u8 response_code; /* Identifier for response */
char* data; /* Data (dependent on system id) */
};
/**
* Perform LGSP request
*
* Performs query on host, and returns response.
*
* @param request Appropriately filled request structure
* @param response Pointer to placeholder for response data - will
* be allocated by procedure
* @return LGSP response code if error, or copy of response_code
* from response structure
*/
int lgsp_request(struct lgsp_request_t* request,
struct lgsp_response_t** response);
Request/response mode C interface
An LGSP server's request/response mode operation, for both
unprotected and protected mode, is illustrated below. In LGSP's
unprotected mode (Section 3.3), which provides no additional channel
protection, all communications are in plaintext. Thus, the LGSP
server maintains no state between transactions. Conversely, in
LGSP's protected mode, where an encryption layer is used, as well as
Forward Error Correction (FEC), a handshake procedure must take place
for each transaction, to establish and maintain a secure
communications channel.
Tyson & Kopp Expires June 21, 2008 [Page 20]
Internet-Draft LGSP December 2007
+----------------+
| Listening |<--.
+----------------+ |
+----------------+ | |
| Listening |<--. Incoming |
+----------------+ | handshake |
| | | |
Client | +-------------------+ |
Request | |Handshake procedure| |
| | +-------------------+ |
+----------------+ | | |
| Send Response |---' Client request |
+----------------+ | |
+----------------+ |
| Send Response |----'
+----------------+
Unprotected mode Protected mode
Request/Response flowchart (Unprotected and protected mode)
3.1.2. Streaming
The streaming mode is more complex than the request/response mode, as
some state is required. Through command messages from clients, LGSP
supports join and part operations on streams (Section 3.2.3,
Section 3.2.4).
When a stream is joined by a client for the first time (that is,
there are no other clients subscribed to the stream), the LGSP server
begins broadcasting the new stream. Subsequent joins by other
clients simply subscribe the new clients to the created stream.
After no more clients are subscribed to the stream, the broadcast is
stopped, conserving resources.
Streaming can be implemented as multicast, in order to efficiently
distribute data to multiple recipients simultaneously.
Alternatively, this can be implemented as parallel unicast sessions,
or using a hybrid technique, which may be more achievable, given the
underdeveloped state of multicast support [IP-Multicast].
Refer Section 3.3.2 for security details.
The interface to the streaming mode can be defined in C as:
struct lgsp_request_t {
address host; /* Host to query (optional - will use predefined
Tyson & Kopp Expires June 21, 2008 [Page 21]
Internet-Draft LGSP December 2007
hosts if not supplied) */
u8 system_id; /* ID of system */
u8 request_type; /* Type of request */
char* parameter; /* Parameter data (dependent on request type and
system ID) */
};
struct lgsp_response_t {
u8 system_id; /* ID of system */
u8 request_type; /* Type of request that initiated response */
u8 response_code; /* Identifier for response */
char* data; /* Data (dependent on system id) */
};
struct lgsp_stream_t;
/**
* Perform LGSP stream join
*
* Performs query on host, and returns response.
*
* @param request Appropriately filled request structure
* @param stream Pointer to placeholder for stream identifier
* @return LGSP response code
*/
int lgsp_join_stream(struct lgsp_request_t* request,
struct lgsp_stream_t* stream);
/**
* Read latest data from stream
*
* Reads latest data from given stream into given response structure.
* Reads a single unit of data, and removes from front of queue.
*
* @param stream Stream identifier
* @param response Pointer to placeholder for response data - will be
* allocated by procedure
* @return LGSP response code
*/
int lgsp_read_stream(struct lgsp_stream_t* stream,
struct lgsp_response_t** response);
/**
* Part stream
*
* Leaves stream, and closes associated internal structures
*
* @param stream Stream identifier
Tyson & Kopp Expires June 21, 2008 [Page 22]
Internet-Draft LGSP December 2007
* @return LGSP response code
*/
int lgsp_part_stream(struct lgsp_stream_t* stream);
Streaming mode C interface
LGSP begins broadcasting a stream on request from a client, until no
more clients are receiving the stream. That is, the LGSP server
continues streaming until no encryption key requests are received
before a 'client request timeout' occurs. This must be longer than
the encryption key refresh timeout (refer Section 3.3.2 for details
related to encryption of streams).
This is outlined below:
Tyson & Kopp Expires June 21, 2008 [Page 23]
Internet-Draft LGSP December 2007
+-----------+
| Listening |<------------------------+
+-----------+ |
| |
Client (+ DTLS handshake |
Request in protected mode) |
| |
+--------------+ |
| Generate | |
|encryption key| |
+--------------+ |
| |
+-----------------+ |
| Obtain multicast| |
| address | |
+-----------------+ |
| |
.------------------------------. |
| | |
+-----------------+ +-----------------+ |
.->| Begin streaming |----. | Send encryption | |
| +-----------------+ | |key and multicast|--'
| | | | address |
| Crypto timeout | +-----------------+
| | |
| +--------------+ Client request
|___| Re-generate | Timeout
|encryption key| | +---------------+
+--------------+ '------->| End streaming |
+---------------+
Figure 9: Streaming flowchart
3.2. Basic Message Formats
A number of basic message formats are defined, which form the basis
of all LGSP communication. These provide standard headers, which
both provide unique identification of a communication session, and
identify the message payload.
In addition, a number of other message formats are defined, which
provided more specific functionality. A basic join stream request/
response pair is defined which can be used by system protocols as-is.
Similarly, a basic GNSS request/response pair is provided for use by
system protocols that do not need any other special parameters for a
transaction.
These messaging formats can be represented in an inheritance
Tyson & Kopp Expires June 21, 2008 [Page 24]
Internet-Draft LGSP December 2007
hierarchy thus:
+------------------+
| Basic |
| Request/Response |
+------------------+
|
+----------------------+----------------------+
| | |
v v v
+------------------+ +------------------+
| GNSS | | Join Stream | System protocol-
| Request/Response | | Request/Response | specific
+------------------+ +------------------+ messages
| |
v v
System protocol- System protocol-
specific GNSS specific join
formats messages
Figure 10: Basic message format inheritance heirachy
As represented in the above figure, the defined basic formats provide
a basis for the definition of other messages.
These basic messages are defined in the following sections.
3.2.1. Request Message
The basic LGSP request message, forming the basis for all LGSP
communication, is illustrated below, excluding any TLS, FEC or UDP
encapsulation:
0 31
+------------+-------------+---------------+--------------+
| Request ID | System ID | Request Type | .
+------------+-------------+---------------+ .
. Parameter data .
+---------------------------------------------------------+
Figure 11: Request message
The structure can be represented in C as:
Tyson & Kopp Expires June 21, 2008 [Page 25]
Internet-Draft LGSP December 2007
struct lgsp_request_hdr {
u8 request_id;
u8 system_id;
u8 request_type;
}; /* System-specific data follows */
Figure 12: C structure for request message
The fields within this structure are defined as follows:
request_id Request messages are uniquely defined by this 8-bit
monotonically increasing integer; combined with the source address
from the UDP header field, this tuple provides a global identifier
for any request message, valid for a limited time.
system_id All encapsulated system protocols are defined by an 8-bit
unsigned integer, giving a maximum of 255 system protocols,
excluding one value for 'extended' mode (refer below and
Section 3.5). This identifier, combined with the following one,
specifies how the following data is to be interpreted.
request_type This 8-bit unsigned integer identifies the system
protocol-specific request being made. As mentioned above, the
<system_id,request_type> tuple defines the structure of the
following message data.
3.2.2. Response Message
The structure of the basic LGSP response message is illustrated
below:
0 31
+------------+-------------+---------------+--------------+
|Response ID | Request ID | System ID | Response Code|
+------------+-------------+---------------+--------------+
. .
. Data .
+---------------------------------------------------------+
Figure 13: Response message
The response message format can be represented in C as:
Tyson & Kopp Expires June 21, 2008 [Page 26]
Internet-Draft LGSP December 2007
struct lgsp_response_hdr {
u8 response_id;
u8 request_id;
u8 system_id;
u8 response_code;
}; /* System-specific data follows */
Figure 14: C structure for response message
The fields within are defined as follows:
response_id This is a monotonically increasing 8-bit unsigned
integer, used to identify LGSP response messages within the
context of each session. When coupled with the destination
address from the UDP header, this tuple forms a global unique
identifier, valid for a limited time.
request_id An 8-bit unsigned integer which identifies the
corresponding original request from the client. This field is
primarily for the use of the client system, so responses can be
associated with requests.
system_id Like the similarly-named field in the request message
structure, this 8-bit unsigned integer identifies the GNSS support
system protocol encapsulated within the message.
response_code An 8-bit unsigned integer that gives an indication of
the result of a request. This is a largely system protocol-
specific value, except for the values 0-10, which are reserved by
LGSP for more basic result identifies, such as failed
authentication or server offline notification. Refer Section 5
for a definitive list of these reserved codes.
3.2.3. Join Stream Request Message
LGSP clients can request to join a stream originating from the
requested server (Section 3.1.2). This technique minimises network
and processor resources by using multicast technologies to distribute
data to all listening nodes, thereby bypassing the need for both
repeated 'polling' and separate network connections for each
listening node.
This message is standardised for all messaging formats that use
streaming, unless extended parameters are required.
The join stream request is defined below.
Tyson & Kopp Expires June 21, 2008 [Page 27]
Internet-Draft LGSP December 2007
0 31
+------------+-------------+---------------+--------------+
| Request ID | System ID | Request Type |Param (option)|
+------------+-------------+---------------+--------------+
Join stream request message
This includes an 8-bit optional parameter field.
Note that this basic message type has no global identifier - it is up
to system protocols to define which request types correspond to a
stream format.
3.2.4. Join Stream Response Message
After receiving a join stream request, the following message will be
returned to the requesting node:
0 31
+------------+-------------+---------------+--------------+
|Response ID | Request ID | System ID | 1 |
+------------+-------------+---------------+--------------+
| Multicast Address |
+---------------------------------------------------------+
|Crypto type | DK len | :
+------------+-------------+ Decode Key data :
| :
+---------------------------------------------------------+
Join stream response message
This response provides the requester with a multicast address to
listen to, and a key to decode the data from the multicast stream.
The response can be represented in C as:
/* Standard lgsp_response_hdr precedes */
struct lgsp_join_stream_response {
ip_addr_t multicast_address;
u8 crypto_type;
u8 decode_key_length;
};
/* decode_key_length bytes of decode key follow */
Figure 17: C structure for join stream response message
The fields within are defined as follows:
Tyson & Kopp Expires June 21, 2008 [Page 28]
Internet-Draft LGSP December 2007
multicast_address A multicast address which the stream is broadcast
to.
crypto_type Type of encryption used
decode_key_length The length of the decode key
(decode key) The key used to decode the data from the stream
Periodically, the broadcasting server must generate a new decode key.
When listening nodes are no longer able to use the existing key to
decode the stream, they must initiate a new join stream request,
which will allow listening nodes to obtain the new key.
3.2.5. GNSS Request Message
A generic message format for GNSS requests is defined below:
0 31
+------------+-------------+---------------+--------------+
| Request ID | System ID | Request Type | Timestamp...|
+------------+-------------+---------------+--------------+
| ...Timestamp | SV Number |
+------------+--------------------------------------------+
GNSS request message
The GNSS request message format can be represented in C as:
/* Standard lgsp_response_hdr precedes */
struct lgsp_gnss_request {
uint_32 timestamp;
u8 sv_number;
};
C structure for GNSS request message
The fields within are defined as follows:
timestamp A 32 bit UNIX-style timestamp, representing the number of
seconds since the epoch (January 1, 1970). This is optional, and
should be ignored when it does not apply to the request.
sv_number An 8-bit unsigned integer which identifies the satellite
vehicle involved in the request. This is optional, and should be
ignored when it does not apply to the request.
Note that this basic message type has no global identifier - it is up
Tyson & Kopp Expires June 21, 2008 [Page 29]
Internet-Draft LGSP December 2007
to system protocols to define which request types correspond to a
GNSS format.
3.2.6. GNSS Response Message
A generic response message format for carrying GNSS data is defined
below:
0 31
+------------+-------------+---------------+--------------+
|Response ID | Request ID | System ID | Response Code|
+------------+-------------+---------------+--------------+
| Timestamp |
+------------+--------------------------------------------+
| SV Number | :
+------------+ :
: Data :
+---------------------------------------------------------+
GNSS response message
The response message format can be represented in C as:
/* Standard lgsp_response_hdr precedes */
struct lgsp_gnss_response {
uint32 timestamp;
u8 sv_number;
}; /* Data follows */
C structure for response message
The fields within are defined as follows:
timestamp A 32 bit UNIX-style timestamp, representing the number of
seconds since the epoch (January 1, 1970).
sv_number An 8-bit unsigned integer which identifies the satellite
vehicle involved in the request. This is optional, and should be
ignored when it does not apply to the request.
3.3. Robustness and Cryptographic Security
LGSP can be used with a large variety of channel types. Some
channels, such as JTRS and JTIDS offer strong encryption, and
corresponding guarantees of packet integrity. Conversely, channels
such as GSM/GPRS, or simpler 'bent pipe' channels using an RF modem
offer no such integrity guarantees and weak or absent channel
encryption.
Tyson & Kopp Expires June 21, 2008 [Page 30]
Internet-Draft LGSP December 2007
For the sake of data integrity and confidentiality, it is thus
essential that measures for channel protection exist within LGSP.
When LGSP is used over channels that provide weak or absent
encryption and/or poor reliability, a 'protected mode' is provided,
that uses encryption and Forward Error Correction (FEC). The FEC
layer gives LGSP some resilience to channel errors, and thus allows
LGSP to utilise more of the available bandwidth when running over
rudimentary channels.
Where suitable channel encryption is already in place, as when LGSP
is used over a protected military channel, for example, LGSP can be
run in 'unprotected mode', where no encryption or FEC is used within
LGSP. As the channel is already encrypted, there is no need for an
extra layer of encryption. Similarly, as the nature of an encrypted
channel provides the assurance of data integrity, FEC is also not
required. This conserves processing and bandwidth resources.
LGSP's protected mode operates on a different port number to LGSP's
unprotected mode. This scheme allows a simple and low-overhead
selection mechanism, akin to the differentiation between clear-text
HTTP and secured HTTPS port numbers [RFC2818].
3.3.1. Protection For Request/Response Sessions
For request/response messages (Section 3.1.1), encryption and
authentication for LGSP's protected mode is to be provided by
Datagram Transport Layer Security (D-TLS) [RFC4347]. This is an
extension to TLS 1.1 [RFC4346] that permits operation over the
connectionless User Datagram Protocol (UDP) [RFC0768].
The D-TLS handshake occurs when a new connection is initiated by a
client, and the D-TLS session is maintained until either a D-TLS
'close_notify' message exchange occurs, or a session timeout is
reached.
TLS-supported certificates are used to authenticate clients. Initial
exchange and registration of certificates is outside the scope of
this document.
The D-TLS layer is encapsulated by a Forward Error Correction code.
The diversity of channel types over which LGSP can operate results in
wide variations in the available channel bandwidth, channel error
rates and other factors. Thus, it is not practical to specify a
single FEC scheme to suit all purposes.
Ideally, all channels over which LGSP is operated would have a
suitable FEC layer built-in at the data link level, but this is
Tyson & Kopp Expires June 21, 2008 [Page 31]
Internet-Draft LGSP December 2007
regrettably not yet the case. Thus, LGSP must offer FEC in place of
a code provided by the channel.
As the performance of FEC codes is often strongly dependent on the
error properties of the channel and block sizes employed, there is no
good 'universal' or 'one size fits all' choice available for an FEC
codec. LGSP therefore mandates only the use of an RFC3452-compatible
code. This defines a standardised and generalised scheme for FEC
coding [RFC3452].
+--------------------+
| LGSP |
+--------------------+
| D-TLS |
+--------------------+ +--------------------+
| FEC | | LGSP |
+--------------------+ +--------------------+
| UDP | | UDP |
+--------------------+ +--------------------+
| IP | | IP |
+--------------------+ +--------------------+
| Insecure/Fragile | | Secure/Robust |
| channel | | channel |
+--------------------+ +--------------------+
Figure 22: LGSP Protocol Stacks - Protected and Unprotected
Note that the D-TLS protection operates only for request/response
mode messages, which take place between a single client and an LGSP
server. As the nature of the encryption system used does not provide
multi-party encryption, it is not compatible with the multicast
streaming mode. An exception to this is when the streaming mode is
implemented as a series of unicast sessions.
3.3.2. Protection for Stream Sessions
This section only applies to LGSP's streaming mode if it is
implemented as a multicast stream. If streaming is implemented as
parallel unicast sessions, then these are protected by the standard
request/response protection mechanisms (Section 3.3.1).
All multicast streaming sessions that are initialised (Section 3.1.2)
in protected mode are protected by encryption and Forward Error
Correction. Due to the nature of D-TLS (refer Section 3.3.1), it is
not possible to support multicast sessions with this mechanism.
Instead, the multicast stream is secured by a secure multicast
architecture described in [RFC3740]. Each protected multicast stream
Tyson & Kopp Expires June 21, 2008 [Page 32]
Internet-Draft LGSP December 2007
is encrypted with a key that is distributed to all listening clients
on request (Figure 9). This key is re-generated at pseudo-random
intervals, requiring clients to re-request the shared key.
In the terms defined by [RFC3740], the LGSP server plays the part of
the Policy Server, the Group Controller/Key Server and the Sender.
That is, the LGSP server is responsible for dictating access
restrictions to streams, managing authentication and joining/parting
of clients and generation of cryptographic keys.
This architecture gives the LGSP server a high degree of control over
the multicast stream, allowing the server to grant and revoke
multicast stream access to any individual client at any time during
transmission.
Forward Error Correction (FEC) for multicast streams is as defined
for request/response messages - refer Section 3.3.1 for more
information.
3.4. Authentication for Access Control
Authentication in LGSP is provided by the D-TLS layer of LGSP's
protected mode (refer Section 3.3.1), which offers digital
certificate functionality.
Certificates are exchanged out-of-band; certificate generation and
exchange is beyond the scope of this document.
Certificate-based authentication is performed as part of the D-TLS
session initialisation routine. An LGSP server uses the
identification from the certificate to grant access to protected
resources.
Refer Section 3.3 for more information on LGSP's protected mode.
3.5. Extension Provisions
As the use of GNSS systems becomes more widespread, the demand for
more accurate, more robust and more consistent service increases.
Consequently, LGSP contains provisions for future expansion.
Examples of such growth could be additional differential correction
messaging schemes.
In order to support rapid deployment of new technologies, an
extension mode is offered, which allows new system protocols to be
quickly built into LGSP, before a formal definition has matured.
This also provides for prototyping and demonstrator platform
development.
Tyson & Kopp Expires June 21, 2008 [Page 33]
Internet-Draft LGSP December 2007
The LGSP extension mode consists of two pre-defined variable size
message formats. The extension message header contains fields to
identify the system and message type, and fields to support both
variable size messages, and message fragmentation.
Request/response and stream variants of the extension message are
supported:
Extension Messages
+-------------------+--------------+-------------+------+
| Message | Payload Size | Update Rate | Mode |
+-------------------+--------------+-------------+------+
| Extension Message | Variable | Variable | R/R |
| | | | |
| Extension Message | Variable | Variable | S |
+-------------------+--------------+-------------+------+
Extension messages are identified by a System ID identifier of
SID_EXTEND, as well as a Temporary System ID (TSID) identifier, used
in place of the standard Request Type field. Allocation of TSID
values are to be performed by a central authority. It is expected
this will be performed in a similar fashion to IP port number
allocation, which is regulated by the Internet Assigned Numbers
Authority (IANA) [RFC2780].
When developing a new LGSP system protocol, it is expected that the
developer will contact the central LGSP authority to request the
reservation of a Temporary System ID (TSID). Such a request would be
accompanied by a statement of the time span for which the reserved
TSID is required. If granted, the reserved TSID is available for use
by the system protocol developer until it expires, after the stated
time.
By the time the reserved TSID has expired, it is expected that the
system protocol would have matured sufficiently to be formally
incorporated into LGSP, through a standard submission process which
would be managed by an LGSP standards authority. If the system
protocol is not accepted as a new standard, discretion is given to
the LGSP central authority to grant an extension on the TSID, or
allow the reservation to expire.
After being accepted, the new system protocol would be allocated a
top-level System ID value.
Tyson & Kopp Expires June 21, 2008 [Page 34]
Internet-Draft LGSP December 2007
3.5.1. Extended Request Message
The extended request message format is identified by the system
identifier SID_EXTEND, and is illustrated below:
0 31
+------------+-------------+---------------+--------------+
| Request ID | SID_EXTEND | Temp Sys. ID | Param. len...|
+------------+-------------+---------------+--------------+
| Param. len | :
+------------+ Parameter data :
: :
+---------------------------------------------------------+
Figure 23: Extended request message
This special case of the standard request message is provided for
evolvability (refer Section 3.5 for more details). The extended
request message format contains a constant system_id value,
SID_EXTEND, which is reserved for systems that are not yet officially
supported by LGSP, and are thus an unofficial extension.
The extended request message format can be represented in C as:
struct lgsp_extended_request_hdr {
u8 request_id;
u8 system_id; /* (= SID_EXTEND) */
u8 temporary_system_id;
unsigned int parameter_length:24;
}; /* parameter_length bytes of system-specific data follows */
Figure 24: C structure for extended request message
The extended request message format uses the temporary_system_id
field to identify the extended system protocol being used. In
addition, a 16-bit parameter_length field is used to specify the
length of the following data block.
A 16-bit unsigned value gives a maximum request data length of 64
kilobytes. Note that the theoretical maximum size of a UDP packet is
64 KB, so the maximum length for parameter data, which is
encapsulated within a UDP packet with several layers of headers and
control information, will be somewhat less than 64 KB in practice.
3.5.2. Extended Response Message
The LGSP extended response message format is illustrated below:
Tyson & Kopp Expires June 21, 2008 [Page 35]
Internet-Draft LGSP December 2007
0 31
+------------+-------------+---------------+--------------+
|Response ID | Request ID | SID_EXTEND | Response Code|
+------------+------+------+---------------+--------------+
|Temp Prot ID| SC | SID | Data Length |
+------------+------+------+------------------------------+
. .
. Data .
+---------------------------------------------------------+
Figure 25: Extended response message
As with the extended request message, this is a special case provided
for evolvability. As above, this format is designated by the special
system_id value, SID_EXTEND.
This message format can be represented in C as:
struct lgsp_extended_response {
u8 response_id;
u8 request_id;
u8 system_id; /* = SID_EXTEND */
u8 response_code;
u8 temporary_system_id;
unsigned int segment_count:4;
unsigned int segment_id:4;
unsigned int data_length:16;
}; /* System-specific data follows */
Figure 26: C structure for extended response message
These additional fields are described below.
segment_count Identifies the total number of extra segments
(packets) this response comprises. This value does not include
the first segment; thus, responses of only one segment have a
segment_count value of 0. This unsigned 4-bit value allows
extended system protocols to issue long responses with up to 16
segments.
segment_id Identifies the current segment. This unsigned 4-bit
integer is used with the above segment_count value to allow
extended system protocols to send large messages. The first
segment of a long response has an ID of 0.
Tyson & Kopp Expires June 21, 2008 [Page 36]
Internet-Draft LGSP December 2007
data_length An unsigned 16-bit integer that gives the size of the
system-specific data in the message. As with the extended request
format, this value allows for up to 64 kilobytes of data, although
this is limited in practice by the UDP packet format. When
combined with the segment provisions above, responses of almost 1
MB can be sent.
3.6. Mirroring
LGSP provides functionality to synchronise data from one LGSP server
to another. This supports both LGSP Mirror Node operation, as well
as redundant backup server operation.
Three complementary messaging formats exist for maintaining
synchronisation. The first is a unicast request/response mechanism
for obtaining an entire dump of current state information for
selected system protocols. The second is another unicast request/
response format which provides for the transfer of all changes in
state for selected system protocols since a given time. The third
involves a streaming multicast-style transmission that the
destination node subscribes to, to receive changes to data at the
source node as they occur.
Mirroring Messages
+--------------------------+--------------+-------------+------+
| Message | Payload Size | Update Rate | Mode |
+--------------------------+--------------+-------------+------+
| Full synchronise | Variable | Variable | R/R |
| | | | |
| Differential synchronise | Variable | Variable | R/R |
| | | | |
| Synchronisation stream | Variable | Variable | S |
+--------------------------+--------------+-------------+------+
The first, full synchronisation operation begins with the
transmission of a synchronisation request by the initiating LGSP
node. The request indicates the systems for which data is to be
synchronised; this is a list of system IDs (as presented in
Section 2.3 and Section 3.5), or a special flag that identifies all
available systems.
Upon receiving the request, the remote LGSP server packages the
entire state of the requested system protocols into a special message
(or multiple messages if the data does not fit in a single message)
and transmits the reply back to the initiating LGSP node.
The second, differential synchronisation operation begins with a
Tyson & Kopp Expires June 21, 2008 [Page 37]
Internet-Draft LGSP December 2007
request that contains a list of system IDs, or a flag to identify all
available system protocols, as above, as well as a timestamp field.
The timestamp field indicates that all changes after the specified
time are to be returned. All synchronisation responses from the
remote LGSP server are accompanied by a timestamp; this field is
typically used in subsequent differential synchronisation requests,
in order to obtain all changes since the last synchronisation
operation.
The full synchronisation operation is useful when performing an
initial synchronisation, or when some time has passed since the last
synchronisation. The differential synchronisation operation
conserves bandwidth, avoiding the need to send all state for each
update. This allows more rapid updates with less demand upon
resources.
The third synchronisation method involves the initiating LGSP node
joining a stream initiating from the remote node. This request from
the initiating node includes a list of system IDs, as with the
previous two operations. A handshake procedure follows, during which
the local LGSP node is subscribed to the multicast update stream.
The remote LGSP node selects for transmission the union of the
previous set of system protocols and the set of system protocols
identified by the requesting LGSP node. This ensures that the update
stream contains all the requested system protocol update data for all
subscribers. Subscribers receiving updates for system protocols that
were not requested are expected to simply discard the irrelevant
updates.
Note that in the case of connection failure during streaming, missed
synchronisation data can be retrieved by recipients by a unicast
differential synchronisation request to the originating LGSP server.
A multicast synchronisation stream mechanism allows immediate
distribution of updates in a bandwidth-efficient fashion.
3.6.1. Full Sync Request Message
To support both mirroring and redundant backup servers, a number of
synchronisation messages are defined. The full sync exchange results
in an entire dump of the requested server's state being transferred
to the requesting node. The full sync request is identified by the
System ID SID_LGSP, and the Request Type RT_LGSP_FULL_SYNC, and is
defined below.
Tyson & Kopp Expires June 21, 2008 [Page 38]
Internet-Draft LGSP December 2007
0 31
+------------+-------------+---------------+--------------+
| Request ID | SID_LGSP |..GSP_FULL_SYNC|Num of sources|
+------------+-------------+---------------+--------------+
| SID 1 | SID 2 | ...SID 3 .. n ... |
+------------+-------------+------------------------------+
Figure 27: Full sync request message
This can be represented in C as:
/* Standard lgsp_response_hdr precedes */
struct lgsp_full_sync {
u8 number_of_sources;
};
/* number_of_sources u8 SIDs follow */
Figure 28: C structure for status message
The fields within are defined as follows
number_of_sources The number of sources for which synchronisation
should take place. If 0, then all sources are selected for
synchronisation.
pid The id of the represented source
3.6.2. Full Sync Response Message
The full sync response message is illustrated below:
Tyson & Kopp Expires June 21, 2008 [Page 39]
Internet-Draft LGSP December 2007
0 31
+------------+-------------+---------------+--------------+
|Response ID | Request ID | SID_LGSP | 1 |
+------------+-------------+---------------+--------------+
|Num segments|Segment ID=0 | Num sources | S0 SID |
+------------+-------------+---------------+--------------+
| S0 data len| :
+------------+ :
: S0 data :
+---------------------------------------------------------+
| S1 SID | S1 data len | :
+------------+-----------------------------+ :
: S1 data :
+---------------------------------------------------------+
: ... S2 ... Sn ... :
+---------------------------------------------------------+
Full sync message
Due to limitations in the UDP packet size, the full sync message may
have to be broken into multiple segments. In this case, subsequent
segments will contain a continuation of the data in the prior
packets, as below:
0 31
+------------+-------------+---------------+--------------+
|Response ID | Request ID | SID_LGSP | 1 |
+------------+-------------+---------------+--------------+
|Num segments|Segment ID=1+| :
+------------+-------------+ :
| ... Continued data ... :
+---------------------------------------------------------+
Full sync message (subsequent packets)
If when parsing a full sync message the end of the packet is reached
before reaching the end of a data block, then the data block
continues at the beginning of the next packet.
That is, if data_length for the current source is n, and only m bytes
are read before reaching the end of the packet, then the remaining
n-m bytes of the source's data can be found in the following packet
or packets.
The full sync message format can be represented in C as:
Tyson & Kopp Expires June 21, 2008 [Page 40]
Internet-Draft LGSP December 2007
/* Standard lgsp_response_hdr precedes */
struct lgsp_full_sync_hdr {
u8 num_segments;
u8 segment_id;
};
struct lgsp_full_sync_first { /* In first packet only */
u8 number_of_sources;
};
/* lgsp_full_sync structs follow */
struct lgsp_full_sync {
u8 system_id;
u16 data_length;
};
/* Up to data_length bytes system-specific data
follows, followed by the next lgsp_full_sync struct */
C structure for status message
The fields within are defined as follows:
num_segments Number of segments (packets) the message is broken up
into.
segment_id Number of the current segment [0 .. num_segments-1].
number_of_sources A count of all LGSP sources for which data is
being transferred. This is only included in the first packet of a
full sync message (subsequent packets are simply a continuation of
the first packet)
system_id System ID for source N
data_length Length of data being transferred for the current source
3.6.3. Differential Sync Request Message
LGSP's differential sync exchange results in the transfer of an
incremental update of the requested server's state since a given
time, representing the time of last sync. The differential sync
request is identified by the System ID SID_LGSP, and the Request Type
RT_LGSP_DIFF_SYNC, and is defined below.
Tyson & Kopp Expires June 21, 2008 [Page 41]
Internet-Draft LGSP December 2007
0 31
+------------+-------------+---------------+--------------+
| Request ID | SID_LGSP |..GSP_DIFF_SYNC|Date of last..|
+------------+-------------+---------------+--------------+
|... sync | Num sources |
+------------+-------------+---------------+--------------|
| SID 1 | SID 2 | ...SID 3 .. n ... |
+------------+-------------+------------------------------+
Differential sync request message
This can be represented in C as:
/* Standard lgsp_response_hdr precedes */
struct lgsp_diff_sync {
uint32_t last_sync_timestamp; /* Secs since epoch */
u8 number_of_sources;
};
/* number_of_sources u8 SIDs follow */
C structure for status message
The fields within are defined as follows
last_sync_timestamp A UNIX timestamp representing the last sync time
- only changes since this time will be returned.
number_of_sources The number of sources for which synchronisation
should take place. If 0, then all sources are selected for
synchronisation.
pid The id of the represented source
3.6.4. Differential Sync Response Message
Refer Section 3.6.2 - message formats are identical.
3.7. Backup Servers
LGSP contains provisions for multiple standby backup servers. These
are entirely separate physical servers that maintain synchronisation
and a `heartbeat' link with the primary LGSP server. This involves
periodically querying the LGSP server, to confirm that the server
remains online. When no reply is detected from the primary server,
it is assumed that the primary server is offline, and the backup
server switches to primary mode, replacing the offline server. In
the case of multiple backup servers, a pre-defined order dictates
which server switches to primary mode.
Tyson & Kopp Expires June 21, 2008 [Page 42]
Internet-Draft LGSP December 2007
A backup server when activated initially performs a full
synchronisation with the primary LGSP server (Section 3.6.2). The
backup server then waits for a small interval of time, typically a
small number of seconds, then performs a differential synchronisation
with the primary server (Section 3.6.3). The backup server repeats
this wait-synchronise process indefinitely.
The synchronisation communication doubles as a heartbeat
notification. If no response is received from the primary server,
the backup server switches into primary mode and takes it's place.
The server then performs the functions of the primary server, until
it is manually returned to backup mode by direct intervention by an
administrator.
In a multiply-redundant environment, with several backup servers, all
backup servers perform the wait-synchronise process. Each backup
server is assigned an ID number, which defines an order. All backup
servers possess a list of the address of each backup server with its
assigned ID number. When the primary server does not respond, the
backup servers reconfigure to select the highest-ordered backup
server as the new primary server. All other backup servers self-
configure to begin synchronising with the new primary server.
This process takes place implicitly and doesn't require an election
process to take place, as all backup servers already possess the
ordered list of backup servers.
Similarly, if the new primary server fails, and does not respond to
subsequent synchronisation requests, this process is repeated; the
next backup server in line takes the place of the failed primary
server, and operation continues.
This process is illustrated below.
Tyson & Kopp Expires June 21, 2008 [Page 43]
Internet-Draft LGSP December 2007
+----------------+
| Backup server |
| brought online |
+----------------+
|
+-----------------+
| Perform full |
| synchronisation | <-----------.
+-----------------+ |
| |
+---------+ |
| Sleep | <---------. |
+---------+ | |
| | |
Time interval | |
elapsed | |
| | |
+----------------------+ | |
| Perform differential |____| |
| synchronisation | Success |
+----------------------+ |
| |
Failure |
| |
+----------------+ |
.--| Check local ID |--. |
Next in | +----------------+ | Not next |
line | | in line |
| v |
+--------------+ +---------------+ |
| Switch to | | Set address of| |
| primary mode | |primary to next|----'
+--------------+ | backup in line|
+---------------+
Backup server flowchart
This redundancy offers a large degree of robustness; even if a
physical server is destroyed, the backups will begin to function in
its place almost immediately. Separating the servers by some
distance offers further security, from physical destruction, power
outages, adverse local radio propagation or network link failures,
depending on the physical configuration of the servers. As the
primary and backup servers are connected via an IP communications
link, some degree of flexibility is offered in terms of location.
Primary and backup servers could easily be located in separate
buildings, across a campus, or even in separate campuses. This
flexibility is limited only by network administration factors.
Tyson & Kopp Expires June 21, 2008 [Page 44]
Internet-Draft LGSP December 2007
3.8. Status Information
Certain information is made available by an LGSP server to clients
and other LGSP nodes through a status query. The returned status
block contains:
o System load information, including network and CPU load.
o Status information of each source:
* Reliability measure, also indicating offline/online status at
either extreme of the scale
* Age of data (time since last update)
* Optional system-specific status messages
The status message allows LGSP nodes and clients to determine both
the load of the LGSP node in question, and the validity of the data
at the node. As discussed in Section 2, LGSP nodes and clients will
query the status of an LGSP node as part of the connection process;
if the status returned indicates that the remote node is overloaded
or contains unreliable data, then the connecting node will move on to
the next known LGSP node.
In addition, each LGSP message containing system data that an LGSP
node returns contains header fields that give an indication of the
validity and age of the accompanying data. The receiving client then
decide whether to accept the received data, or attempt to connect to
another mirror to obtain more recent or reliable data.
3.8.1. Status Request Message
For load-distribution and administrative purposes, the status request
message is used to prompt an LGSP server to return current status
information. The status message is identified by the System ID
SID_LGSP, and the Request Type RT_LGSP_STATUS, and is defined below.
0 24
+------------+-------------+---------------+
| Request ID | SID_LGSP | RT_LGSP_STATUS|
+------------+-------------+---------------+
Figure 35: Status request message
Tyson & Kopp Expires June 21, 2008 [Page 45]
Internet-Draft LGSP December 2007
3.8.2. Status Response Message
The LGSP status response message is illustrated below:
0 31
+------------+-------------+---------------+--------------+
|Response ID | Request ID | SID_LGSP | 1 |
+------------+-------------+---------------+--------------+
| CPU load |Avg. Net load| Num of sources| S0 SID |
+------------+-------------+---------------+--------------+
|S0 rel'blity| S0 age | Opt. S0 stat | S1 SID |
+------------+-------------+---------------+--------------+
|S1 rel'blity| S1 age | Opt. S1 stat | ...S1..Sn ...|
+------------+--------------------------------------------+
Figure 36: Status message
The status message format can be represented in C as:
/* Standard lgsp_response_hdr precedes */
struct lgsp_status {
u8 cpu_load;
u8 avg_net_load;
u8 number_of_sources;
};
/* number_of_sources lgsp_source_stat structs follow */
struct lgsp_source_stat {
u8 system_id;
u8 reliability;
u8 age;
u8 optional_system_stats;
};
Figure 37: C structure for status message
The fields within are defined as follows:
cpu_load Used to give an indication of the amount of load the
server's processor is under.
avg_net_load An average of network load in [0...255] over all
network interfaces.
number_of_sources A count of all LGSP sources.
Tyson & Kopp Expires June 21, 2008 [Page 46]
Internet-Draft LGSP December 2007
system_id System ID for source N
reliability Measure of reliability for source N; a value of 0
indicates N is offline, a value of 255 indicates N is online and
fully operational.
age Age of data for source N; units are system-specific
optional_system_stats Additional 8-bit statistics field for optional
use by system protocols
3.9. Load Balancing
LGSP defines functionality to support load balancing within the
protocol. This avoids the situation where a single LGSP server is
overwhelmed while other LGSP servers remain idle. By constraining
LGSP clients' behaviour, load can be evenly spread over a number of
LGSP mirrors.
LGSP clients contain a list of LGSP Mirror Nodes to connect to. When
initiating a connection, the LGSP client initially chooses a random
LGSP server from the list. The LGSP client will request the current
status of the Mirror Node, using the status information query defined
in Section 3.8. The client will evaluate the response, and determine
the level of load the Mirror Node is under. If load is high, the
client will attempt a connection with the next LGSP Mirror Node in
the client's internal list.
Similarly, if a connection to an LGSP Mirror Node fails, an LGSP
client will simply move on to the next LGSP Mirror Node in the
client's list.
This same functionality is required of LGSP Mirror Nodes when
connecting to LGSP Master Station Nodes. This redundant architecture
offers considerably more robustness than an architecture with a
single point-of-failure.
This process is illustrated below:
Tyson & Kopp Expires June 21, 2008 [Page 47]
Internet-Draft LGSP December 2007
+------------------+
| Client selects |
|random LGSP server| +------------------+
+------------------+ | Client selects |
| | next LGSP server |
| +------------------+
|---------------| ^
v |
+--------------+ |
| Client sends |__ No server _|
| status query | response |
+--------------+ |
| |
Server responds |
| |
v |
+-----------+ |
| Client | |
| evaluates |-- Load too ----'
| response | high
+-----------+
|
Load adequate
|
v
+-----------------+
| Client proceeds |
| with request |
+-----------------+
Figure 38: Load Balancing Flowchart
Tyson & Kopp Expires June 21, 2008 [Page 48]
Internet-Draft LGSP December 2007
4. System Protocol Identifiers
LGSP defines a number of system identifiers for currently supported
GNSS systems (Section 2.3), and for management and extension use
(Section 3). For each system, LGSP also defines a number of request
identifiers. Both are listed in this section.
4.1. System Identifiers
System identifiers for the supported GNSS systems (Section 2.3) and
for management and extension use (Section 3) are defined below.
+-------------+----+--------------------------------+
| Name | ID | Description |
+-------------+----+--------------------------------+
| SID_LGSP | 0 | LGSP Internal Messages |
| | | |
| SID_EXTEND | 1 | Extension Message |
| | | |
| SID_GPS | 2 | Global Position System |
| | | |
| SID_GPS_SA | 3 | GPS Special Applications |
| | | |
| SID_WAAS | 4 | Wide Area Augmentation System |
| | | |
| SID_LAAS | 5 | Local Area Augmentation System |
| | | |
| SID_GALILEO | 6 | Galileo |
| | | |
| SID_EGNOS | 7 | EGNOS |
| | | |
| SID_GLONASS | 8 | GLONASS |
+-------------+----+--------------------------------+
4.2. Request Types
Request types for the existing LGSP systems are defined below.
The 'Mode' column defines whether the given type is request/response
or streaming. Excepting all requests for System ID SID_LGSP, all
request/response ('R/R') messages use the GNSS request/response
message format (Section 3.2.5, Section 3.2.6).
All streaming messages below (S) use the join stream message format,
with no parameters (Section 3.2.3, Section 3.2.4).
Tyson & Kopp Expires June 21, 2008 [Page 49]
Internet-Draft LGSP December 2007
+------------+------------------------+----+------+-----------------+
| System | Name | ID | Mode | Description |
+------------+------------------------+----+------+-----------------+
| SID_LGSP | RT_LGSP_STATUS | 1 | R/R | Request status |
| | | | | from node |
| | | | | |
| SID_LGSP | RT_LGSP_FULL_SYNC | 2 | R/R | Request all |
| | | | | stored data and |
| | | | | state |
| | | | | (mirrors/backup |
| | | | | sonly) |
| | | | | |
| SID_LGSP | RT_LGSP_DIFF_SYNC | 3 | R/R | Request changes |
| | | | | since last sync |
| | | | | (m/b only) |
| | | | | |
| SID_LGSP | RT_LGSP_SYNC_STREAM | 4 | S | Request to |
| | | | | join/part sync |
| | | | | stream (m/b |
| | | | | only) |
| | | | | |
| SID_GPS | RT_GPS_NAV_SUBFRAME | 1 | R/R | NAV message |
| | | | | subframe |
| | | | | |
| SID_GPS | RT_GPS_NAV_FRAME | 2 | R/R | NAV message |
| | | | | frame |
| | | | | |
| SID_GPS | RT_GPS_NAV_STREAM | 3 | S | NAV message |
| | | | | stream |
| | | | | |
| SID_GPS | RT_GPS_CNAV_SUBFRAME | 4 | R/R | CNAV message |
| | | | | subframe |
| | | | | |
| SID_GPS | RT_GPS_CNAV_FRAME | 5 | R/R | CNAV message |
| | | | | frame |
| | | | | |
| SID_GPS | RT_GPS_CNAV_STREAM | 6 | S | CNAV message |
| | | | | stream |
| | | | | |
| SID_GPS | RT_GPS_CNAV2_SUBFRAME | 7 | R/R | CNAV-2 message |
| | | | | subframe |
| | | | | |
| SID_GPS | RT_GPS_CNAV2_FRAME | 8 | R/R | CNAV-2 message |
| | | | | frame |
| | | | | |
| SID_GPS | RT_GPS_CNAV2_STREAM | 9 | S | CNAV-2 message |
| | | | | stream |
| | | | | |
Tyson & Kopp Expires June 21, 2008 [Page 50]
Internet-Draft LGSP December 2007
| SID_GPS | RT_GPS_EDCM | 10 | R/R | Enhanced |
| | | | | differential |
| | | | | correction |
| | | | | message |
| | | | | |
| SID_GPS | RT_GPS_ECDS | 11 | S | Enhanced |
| | | | | differential |
| | | | | correction |
| | | | | stream |
| | | | | |
| SID_GPS | RT_GPS_ALMANAC | 12 | R/R | Almanac page |
| | | | | |
| SID_GPS | RT_GPS_EXPANSION | 13 | R/R | GPS expansion |
| | | | | mode |
| | | | | |
| SID_WAAS | RT_WAAS_MOPS_STREAM | 1 | S | MOPS message |
| | | | | stream |
| | | | | |
| SID_WAAS | RT_WAAS_MOPS_BLOCK | 2 | R/R | MOPS message |
| | | | | block |
| | | | | |
| SID_LAAS | RT_LAAS_RTCM_STREAM | 1 | S | RTCM message |
| | | | | stream |
| | | | | |
| SID_LAAS | RT_LASS_RTCM_BLOCK | 2 | R/R | RTCM message |
| | | | | block |
| | | | | |
| SID_GALILE | RT_GALILEO_FNAV_SUBFRA | 1 | R/R | F/NAV message |
| O | ME | | | subframe |
| | | | | |
| SID_GALILE | RT_GALILEO_FNAV_FRAME | 2 | R/R | F/NAV message |
| O | | | | frame |
| | | | | |
| SID_GALILE | RT_GALILEO_FNAV_STREAM | 3 | S | F/NAV message |
| O | | | | stream |
| | | | | |
| SID_GALILE | RT_GALILEO_INAV_SUBFRA | 4 | R/R | I/NAV message |
| O | ME | | | subframe |
| | | | | |
| SID_GALILE | RT_GALILEO_INAV_FRAME | 5 | R/R | I/NAV message |
| O | | | | frame |
| | | | | |
| SID_GALILE | RT_GALILEO_INAV_STREAM | 6 | S | I/NAV message |
| O | | | | stream |
| | | | | |
| SID_GALILE | RT_GALILEO_ALMANAC | 7 | R/R | Almanac page |
| O | | | | |
| | | | | |
Tyson & Kopp Expires June 21, 2008 [Page 51]
Internet-Draft LGSP December 2007
| SID_EGNOS | RT_EGNOS_MOPS_STREAM | 1 | S | MOPS message |
| | | | | stream |
| | | | | |
| SID_EGNOS | RT_EGNOS_MOPS_BLOCK | 2 | R/R | MOPS message |
| | | | | block |
| | | | | |
| SID_GLONAS | RT_GLONASS_NAV_FRAME | 1 | R/R | Navigation |
| S | | | | message frame |
| | | | | |
| SID_GLONAS | RT_GLONASS_NAV_SUPERFR | 2 | R/R | Navigation |
| S | AME | | | message |
| | | | | superframe |
| | | | | |
| SID_GLONAS | RT_GLONASS_NAV_STREAM | 3 | S | Navigation |
| S | | | | message stream |
| | | | | |
| SID_GLONAS | RT_GLONASS_ALMANAC | 4 | R/R | Almanac |
| S | | | | |
+------------+------------------------+----+------+-----------------+
Tyson & Kopp Expires June 21, 2008 [Page 52]
Internet-Draft LGSP December 2007
5. Reserved Response Codes
Several system-wide response codes have been defined, for use within
LGSP response messages (Figure 13). The response codes from 0x0 to
0xA inclusive are reserved. These codes identify LGSP-specific
result conditions and are defined below.
SUCCESS = 0x0 A general success indicator, used when a request was
successfully processed.
FAILURE = 0x1 This is a general error condition that reflects that
an unknown error occurred when processing the client's request.
This value should only be used when no other error condition can
represent the problem.
ILLEGAL_RESOURCE = 0x2 A general error condition triggered when
trying to access a resource illegally.
RESOURCE_OFFLINE = 0x3 A condition caused when the requested
resource is currently unavailable. This should be returned when a
resource is temporarily offline. If the resource has been
permanently decommissioned, or has never been available, the
following code should be returned instead.
NO_SUCH_RESOURCE = 0x4 This code should be returned when the
requested resource does not exist. Note the distinction between
this condition, which reflects a permanent state, and the previous
condition, which reflects a temporary unavailability of the
resource.
The remainder of the codes, up to and including 0xA, are reserved for
future expansion and should not be used by any system under LGSP.
Tyson & Kopp Expires June 21, 2008 [Page 53]
Internet-Draft LGSP December 2007
6. IANA Considerations
LGSP requires two port allocations, for the protected and unprotected
modes (refer Section 3.3).
As defined in Section 3.2, LGSP defines an 8-bit System Identifier
field, which identifies the LGSP system protocol the message
concerns. It is proposed that the IANA will oversee allocation of
new System Identifiers when new LGSP system protocols are developed.
In addition, LGSP provides an expansion message format, used for
developing LGSP system protocols and defined in Section 3.5. It is
proposed that the IANA will perform the administrative tasks related
to allocation of Temporary System IDs for this purpose.
Following the policies outlined in [RFC2434], System Identifier
values in the range 9-255 are allocated through IETF Approval;
numbers between 0-8 are already allocated (Section 4).
All Temporary System Identifier values are allocated through IETF
Approval, for the time period stated in the request, but no longer
than three years. Renewal of Temporary System Identifier values is
to be assessed by the IETF, and granted only if reasonable progress
has been made in development of the new protocol towards a standard.
Tyson & Kopp Expires June 21, 2008 [Page 54]
Internet-Draft LGSP December 2007
7. Security Considerations
Channel encryption for LGSP is provided by Datagram Transport Layer
Security (D-TLS) [RFC4347] and the multicast group security
architecture [RFC3740], when operating in protected mode (refer
Section 3.3). This is an optional mode, but is strongly recommended
for use over channels that do not already possess some adequate form
of channel encryption.
For channels that are already cryptographically protected, LGSP's
unprotected mode is sufficient, and will minimise processing and
network overhead.
Tyson & Kopp Expires June 21, 2008 [Page 55]
Internet-Draft LGSP December 2007
8. References
8.1. Normative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC3452] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley,
M., and J. Crowcroft, "xForward Error Correction (FEC)
Building Block", RFC 3452, December 2002.
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security
Architecture", RFC 3740, March 2004.
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006.
8.2. Informative References
[EDGE] Blackwell, Moeglein, M., and D. Nakayama, "A global DoD-
optimized DGPS for precision-strike", 1995.
[FAB-T] Schiavone, LJ., "Airborne networking - approaches and
challenges", 2004.
[GGW] Kopp, C., "GPS Guided Weapons", 1996,
<http://www.ausairpower.net/TE-GPS-Guided-Weps.html>.
[GLONASS-ICD]
Russian Space Agency, "GLONASS Interface Control
Document", 2002.
[GPRS] European Telecommunications Standards Institute, "Digital
Cellular Telecommunications System (Phase 2+), General
Packet Radio Service, Service Description, Stage 1",
August 1999.
[GPS-IS] U.S. Air Force, "NAVSTAR GPS Space Segment/Navigation User
Interfaces", 2006.
[GSM] Rahnema, M., "Overview of the GSM system and protocol
Tyson & Kopp Expires June 21, 2008 [Page 56]
Internet-Draft LGSP December 2007
architecture", 1993.
[Galilei] European Commission, "The Galilei Project: GALILEO Design
Consolidation", 2003.
[IEEE802.11]
ANSI/IEEE, "802.11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications", 2000.
[IP-Multicast]
Sylvia, Andrey , and Scott, "Revisiting IP Multicast",
2006.
[JTIDS-IP]
Stinson, W., "Internet Protocol (IP) over Link-16",
March 2003.
[JTIDS-MIDS]
Hura, M., McLeod, G., Larson, EV., Schneider, J.,
Gonzales, D., Norton, DM., Jacobs, J., O'Connell, KM.,
Little, W., Mesic, R., and L. Jamison, "Interoperability:
A Continuing Challenge in Coalition Air Operations", 2000.
[JTRS] Place, J., Kerr, D., and D. Schaefer, "Joint Tactical
Radio System", 2000.
[JTRSb] Davis, K., "JTRS - An Open, Distributed-Object Computing
Software Radio Architecture", 1999.
[LAAS] U.S. Federal Aviation Administration, "Performance Type
One Local Area Augmentation System Ground Facility", 2002.
[LGSP] Tyson, M R. and C. Kopp, "Lightweight GNSS Support
Protocol (LGSP) Definition (Unpublished internal
document)", January 2007.
[LGSP2] Tyson, M R. and C. Kopp, "LGSP: A Lightweight GNSS Support
Protocol for Military and Civil Applications",
November 2007.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
Values In the Internet Protocol and Related Headers",
Tyson & Kopp Expires June 21, 2008 [Page 57]
Internet-Draft LGSP December 2007
BCP 37, RFC 2780, March 2000.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
[WAAS] Loh, R., Wullschleger, V., Elrod, B., Lage, M., and F.
Haas, "The U.S. Wide-Area Augmentation System (WAAS)",
1995.
[WAGE] Vittorini, LD., "GPS URE/UE evolutionary improvements and
end-user accuracy results", 1998.
[WiMax] Vaughan-Nichols, S., "Achieving wireless broadband with
WiMax", 2004.
Tyson & Kopp Expires June 21, 2008 [Page 58]
Internet-Draft LGSP December 2007
Authors' Addresses
Mike Tyson
Monash University
Email: mtyson@csse.monash.edu.au
URI: http://www.csse.monash.edu.au/~mtyson
Carlo Kopp
Monash University
Email: carlo@csse.monash.edu.au
URI: http://www.csse.monash.edu.au/~carlo
Tyson & Kopp Expires June 21, 2008 [Page 59]
Internet-Draft LGSP December 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Tyson & Kopp Expires June 21, 2008 [Page 60]
