Internet Engineering Task Force                                Phil Karn
INTERNET DRAFT

File: draft-karn-satellite-telemetry-00.1.txt             November, 2000
                                                 Expires:      May, 2001


                 The Satellite Telemetry Protocol (STP)


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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.

Abstract

   This document proposes a Spacecraft Telemetry Protocol (STP) to carry
   spacecraft telemetry and operational data over the Internet. It may
   also be used for archival storage.  The protocol specifies a standard
   header format and a set of header options that identify the
   spacecraft, the telemetry format, the receiving station, etc.

   This protocol was primarily motivated by the launch of the AMSAT-
   Oscar-40 amateur radio satellite, but it is intended to be general
   purpose in nature.


Introduction and Overview

   Most modern spacecraft, including nearly all amateur (ham) radio
   spacecraft, carry on-board computers that control its operation,
   execute commands from ground stations and format and transmit digital
   telemetry about its operating condition.

   There is a growing need to exchange spacecraft telemetry data over
   the Internet between ground stations, spacecraft controllers and
   users.  To date, several ad-hoc protocols have been used, but none
   appears to have the features necessary for general purpose use. This
   document proposes such a protocol, the Spacecraft Telemetry Protocol,
   or STP.

   Telemetry formats vary widely from one type of spacecraft to another.
   For example, they lack a uniform identification scheme and an
   unambiguous indication of the particular data format(s) in use.  For
   this reason, the primary purpose of the protocol described here is to
   add a standardized header to each frame of spacecraft data to
   identify the spacecraft and the particular spacecraft subsystem
   generating the data and/or its format. Optional header fields may
   also be added to identify and locate the receiving station, timestamp
   the telemetry data, indicate the telemetry transmission frequency,
   and so forth.

Port Numbers and Multicasting

   STP may be used over either TCP or UDP. The Well Known Port numbers
   assigned by IANA for STP are XXX for TCP and YYY for UDP. This port
   number SHOULD be used in the TCP or UDP Destination Port field of all
   packets carrying satellite telemetry in STP format.

   When STP is used over IP Multicasting [RFC1112] [RFC2236], UDP is the
   transport layer protocol. Different multicast IP destination
   addresses may be assigned and used to segregate data from different
   satellites so that STP recipients may select the satellite or groups
   of satellites from which they wish to receive telemetry. Multicast IP
   address assignments for STP are TBD.

   If a host implements STP, it SHOULD implement it over both UDP and
   TCP, and it SHOULD support the use of IP Multicasting.

Terminology

   In this document, the term "receiving station" refers to the station
   receiving telemetry directly from the spacecraft.  The term "STP
   sender" refers to the Internet host that relays this telemetry to the
   Internet using STP.

STP Header Format

   The STP header consists of one or more lines of 7-bit ASCII text,
   each terminated by a two-octet cr/lf sequence. The end of the STP
   header is denoted by a blank line, i.e., two consecutive cr/lf
   sequences. This is followed by the spacecraft telemetry block in raw
   binary. (This format is intentionally similar to the Hypertext
   Transport Protocol, HTTP [RFC2616])

   STP headers are not case sensitive. STP receivers MUST ignore case in
   incoming headers.

   STP defines the following header lines and their meanings:

   Source: <name authority>.<spacecraft name>[.<subsystem
   name].<format>]|null

   This header line gives the name of the authority issuing spacecraft
   names, the name assigned by the specified authority to the spacecraft
   generating the telemetry, the name of the subsystem within the
   spacecraft (if any), and the format specifier of the telemetry
   contained in this packet.  To ensure interoperability, standard
   values of these fields will be formally assigned to each spacecraft
   and subsystem.

   This header line is mandatory.


   Length: <length>

   This header line gives the length of the telemetry frame in bits,
   excluding the STP header.

   This header line is mandatory.


   Frequency: <frequency> [MGk]Hz [<frequency> [MGk]Hz ...]

   This header line gives the carrier frequenc(ies) of the spacecraft
   transmitter(s) on which the telemetry frame was received. The
   receiving station need not measure the exact frequenc(ies); it is
   sufficient to indicate the nominal downlink frequenc(ies), as the
   intent is only to distinguish among different transmitters on the
   same spacecraft.

   The multiple frequency fields are provided for spacecraft that
   transmit the same telemetry stream on more than one RF channel,
   allowing receiving stations to use diversity reception. Receiving
   stations supporting diversity SHOULD specify only the frequencies
   actually used to receive the current frame; i.e., multiple
   frequencies should be specified only when the receiving station has
   actually combined data from more than one channel to demodulate the
   current frame.

   This header line is optional.


   EbNo: <value> dB

   This header line gives the average received Eb/No ratio in decibels
   at the receiving station for the telemetry frame in the packet.

   If the satellite transmission is in Morse code, Eb shall be the
   received energy in a single Morse element, i.e., a dot.

   This header line is optional.


   Date: <date>

   This header line gives the date and time at the receiving station
   when the end of the telemetry frame was received.  The date field
   MUST be in the format specified by section 3.3.1 of RFC2616 and MUST
   indicate Universal time. The date SHOULD be made as accurate as
   possible, either by use of a local timing receiver (e.g., GPS) or by
   use of the Network Time Protocol [RFC1305] to synchronize the
   receiving station's clock to UTC.

   This header line is optional.


   Receiver: <station name>

   This header line gives the name of the receiving station.  This may
   be assigned by the operator of the station. If the station is an
   amateur radio station, the station name SHOULD include the amateur
   radio call sign.

   The intent of this field is that it uniquely identify the receiving
   station, that it remain constant over the life of the station, and
   that it be at least somewhat meaningful to a human.  If a given
   amateur operator has more than one station, they SHOULD be
   distinguished with different station names. These names may take the
   form of additional text appended to the callsign. Imbedded spaces are
   allowed in the name.

   This header line is optional.


   Rx-Location: <N|S><latitude> <E|W><longitude> [<altitude>]

   This header line gives the geodetic location of the receiving
   station.  The latitude is given in decimal degrees and is immediately
   preceded by a N for north or a S for south. The longitude is given in
   decimal degrees and is immediately preceded by a W for west or a E
   for east. The altitude, if present, is in meters. This field may be
   negative. These fields are separated by exactly one space character.

   This header line is optional.

Source name authorities

   This document defines one source naming authority, "amsat", the Radio
   Amateur Satellite Corporation. Other source naming authorities are
   TBD.

   The issuance of a STP spacecraft name by a particular naming
   authority does not imply any ownership or control of the spacecraft
   by that authority.

Header line usage

   Only two header lines, Source and Length, are mandatory; the rest are
   all optional. STP senders SHOULD include any header for which
   accurate information is available. STP senders MUST NOT send any
   header with inaccurate information. In particular, because the time-
   of-day clocks in many computers are notoriously inaccurate, STP
   senders SHOULD send the Date: header only if the local clock is
   externally synchronized to a reliable source, such as GPS, the NTP
   hierarchy, WWVB receiver, etc.

   STP header lines MAY be issued in any order.

Experimental headers

   STP header names beginning with "X-" are reserved for experimental
   use, and will never be assigned to new official header types.
   However, because of the inconvenience and interoperability problems
   that can occur when official names are assigned to formerly
   experimental types, STP implementers SHOULD request an official
   header name, if possible, instead of using the X- format.


Spacecraft telemetry block

   After the STP header, the spacecraft telemetry block follows in
   binary. If the block is not an integral number of octets, it must be
   padded out to the next octet boundary.  The length of this block,
   excluding bit padding, MUST match the value in the Length field. This
   block MUST appear just as it was received from the spacecraft,
   including block synchronization and error control (e.g., CRC) fields.
   Inter-block padding, if any, SHOULD be deleted.

   If the spacecraft uses multiple layers of error control, only the
   uppermost layer need be retained. For example, if a Reed-Solomon (RS)
   code is layered on top of convolutional coding, the RS parity symbol
   should be retained after Viterbi decoding. But if the satellite
   generates a CRC before RS encoding, then only the CRC need be
   retained.

   The intent is to provide an end-to-end integrity check on the data by
   passing at least some of the error checking information generated by
   the spacecraft unchanged to the ultimate consumer of the telemetry
   data. It is not necessary, however, to include all of the error
   control information added by the spacecraft to protect the space-to-
   ground radio link.


Bit order

   The bit ordering within each data octet sent in STP is defined by the
   appropriate Source definition. For the amsat.ao-40.ihu.standard
   source, octets are filled with received bits starting with the high
   order bit of each octet, as defined by the Phase 3 telemetry
   standard.

Processing STP packets

   STP may be used to multiplex telemetry from different satellites and
   in different formats onto a single TCP/IP connection or UDP/IP
   multicast stream. STP receivers therefore MUST silently ignore any
   STP packets from sources they do not understand or implement, while
   continuing to process STP packets from sources they do understand.
   Similarly, STP receivers MUST silently ignore any unimplemented
   header lines and continue to process the ones they do implement.

   This language is not intended to preclude an STP receiver from
   notifying the user of the reception of a packet with an unsupported
   source type.  If this is done, however, the receiver MUST provide the
   user with a means to disable these notifications.

Header values for AMSAT-Oscar-40

   When STP is used to carry housekeeping telemetry for the AMSAT-
   Oscar-40 satellite (known before launch as AMSAT Phase 3D), the
   following Source field shall be used:

   Source: amsat.ao-40.ihu.standard

   For this telemetry format, the Length field will always be 4144.

Header values for GPS navigation messages

   When STP is used to carry the navigation messages broadcast by Global
   Positioning System (GPS) satellites on the L1 frequency, the
   following Source field shall be used:

   Source: amsat.gps-prn##.navigation

   where "##" represents the two-digit PRN number of the satellite being
   received.

   Some GPS receivers, e.g., the Motorola Oncore-VP, strip the Hamming
   parity bits from the incoming message, so they are not available to
   the host computer. When parity-stripped GPS messages are sent with
   STP, the following header shall be used:

   Source: amsat.gps-prn##.navigation-noparity

Null messages

   STP senders MAY send messages without telemetry for test purposes, or
   to indicate to receivers that it is functional but that no spacecraft
   telemetry is being received. If such messages are sent, they MUST use
   the following Source header:

   Source: null

   Null STP MAY include test data. If such data is included, its length
   MUST be correctly indicated with the Length: field. If a null STP
   packet contains no data, the Length field MUST indicate a zero
   length.

   Other headers MAY be present in a null STP message, but MAY be
   ignored by the receiver if they are not applicable.

Examples

   Here are the headers as they would appear on a block of AO-40
   telemetry received at a station at my house in San Diego, CA:

   Source: amsat.ao-40.ihu.standard
   Frequency: 145.898 MHz
   Date: Tue, 28 Nov 2000 16:58:04 UTC
   Receiver: KA9Q
   EbNo: 15.6 dB
   Rx-Location: N32.8605 W117.1889 +113
   Length: 4144
   [blank line]
   [518 bytes of AO-40 telemetry, starting with sync vector, ending with
2-octet CRC]

   Here are the headers as they might appear on the navigation message
   broadcast every 30 seconds by the PRN-02 GPS satellite:

   Source: amsat.gps-prn02.navigation-noparity
   Frequency: 1575.42 MHz
   Date: Tue, 28 Nov 2000 16:58:04 UTC
   Receiver: KA9Q
   Rx-Location: N32.8605 W117.1889 +113
   Length: 1200
   [blank line]
   [150 bytes of GPS navigation message, with parity bits removed]


References

   References of the form RFCnnnn are Internet Request for Comments
   (RFC) documents available online at www.rfc-editor.org.



Security Considerations

   To be added - particularly when we multicast this protocol, we need
   an "authenticator" header that carries a digital signature on the
   block added by the ground station.


Authors'  Addresses:

   Phil Karn (karn@qualcomm.com)