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 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, . [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]