I.B. + M.A. DE LANDE LONG
SOFTWARE + CONSULTANCY

Packet Telemetry Features

This page describes some of the telemetry features supported by the Telemetry Encoder Shell and Telemetry Decoder Shell. For the definition of the features described here, see the recommendations documents.

NOTE: In common with older issues of the standards and recommendations, we use the term Packet Telemetry. It refers to the protocols for the transport of data units, such as packets, in TM Transfer Frames. However, the protocols are not limited to packets and recent issues of the standards no longer use the term.

Packets and the Packet service

The Telemetry Encoder Shell and Telemetry Decoder Shell handle the following types of packets:

- CCSDS Space Packets (also known as Source Packets or Telemetry Packets)
- CCSDS SCPS NP Datagrams
- IPv4 Datagrams
- CCSDS Encapsulation Packets

Physical Channel

A Physical Channel is a telemetry bitstream. A single instance of the Telemetry Encoder Shell or the Telemetry Decoder Shell supports one Physical Channel.

Virtual Channels (VCs)

Multiple Virtual Channels (VCs) can share the capacity of a single Physical Channel. The Virtual Channels are assigned transmission capacity on a frame-by-frame basis. Typically, Virtual Channels are used to separate sources or destinations with different characteristics. For example, a source which generates very large packets may use a different VC from other sources which generate short packets.

A Virtual Channel is identified by a Virtual Channel Identifier (VCID) and a Spacecraft Identifier (SCID).

The Telemetry Encoder Shell and Telemetry Decoder Shell support up to 8 Virtual Channels on the Physical Channel.

Master Channels (MCs)

The set of Virtual Channels on the same Physical Channel and which have the same Spacecraft Identifier constitute a Master Channel. A Master Channel may have up to 8 Virtual Channels.

The Telemetry Encoder Shell and Telemetry Decoder Shell support multiple Master Channels on the Physical Channel. The overall limit (8) on the number of Virtual Channels on the Physical Channel still applies.

Transfer Frame

Multiple asynchronous sources on board a spacecraft can generate variable-length packets at different rates. The packets can then be multiplexed together into a synchronous stream of fixed-length Transfer Frames for transmission.

A Transfer Frame may carry data from one or more packets. In addition to packet data, the Transfer Frame can carry optional data fields: the Transfer Frame Secondary Header and the Operational Control Field. The Transfer Frame is of fixed length for a given Physical Channel.

The Transfer Frames supported by the Telemetry Encoder Shell and Telemetry Decoder Shell are the Version-1 frames defined for the TM Space Data Link Protocol. (The AOS Encoder Shell and AOS Decoder Shell support the Version-2 frames (VCDU) defined for CCSDS Advanced Orbiting Systems in the AOS Space Data Link Protocol.)

Buffered services (Synchronous services)

The data transfer services which use the Transfer Frame Secondary Header and the Operational Control Field are buffered services. The buffered services are also called synchronous services.

In a buffered service, the data unit for transfer is placed in a special buffer. Whenever the user has a data unit to send, it is placed in the special buffer, overwriting any earlier contents. Whenever a frame for the service is about to be sent, the data unit is read from the special buffer and placed in the frame. Therefore, the fate of any particular data unit depends on the timing. A particular data unit may be transmitted more than once, if the special buffer is not updated between frames for the service. Also, a particular data unit may not be sent at all, if it is overwritten by another data unit before the next frame for the service.

Transfer Frame Secondary Header (FSH)

The Transfer Frame Secondary Header (FSH) can be used to carry fixed-length mission-specific data. The use of the FSH is optional. If present, the length is from 2 to 64 octets.

There is a service, MC-FSH, for transferring data via the FSH at the Master Channel level. In this case, the length of the FSH is fixed for all Transfer Frames for the Master Channel. Each frame on the Master Channel will carry the latest available copy of the data.

There is a service, VC-FSH, for transferring data via the FSH at the Virtual Channel level. In this case, the length of the FSH is fixed for all Transfer Frames for the Virtual Channel. Each frame on the Virtual Channel will carry the latest available copy of the data.

If the MC-FSH service is configured for a Master Channel, this excludes the use of the VC-FSH service for all Virtual Channels on that Master Channel.

The FSH services are buffered services (synchronous services).

The Telemetry Encoder Shell and Telemetry Decoder Shell support the use of the MC-FSH and VC-FSH services.

Operational Control Field (OCF)

The Operational Control Field (OCF) can be used to provide the status of telecommand or other spacecraft operations activities. Telecommand Communications Link Control Words (CLCWs) may be carried in the OCF. The use of the OCF is optional. If present, the length is 32 bits.

There is a service, MC-OCF, for transferring data via the OCF at the Master Channel level. In this case, the OCF is present in all Transfer Frames for the Master Channel. Each frame on the Master Channel will carry the latest available copy of the data.

There is a service, VC-OCF, for transferring data via the OCF at the Virtual Channel level. In this case, the OCF is present in all Transfer Frames for the Virtual Channel. Each frame on the Virtual Channel will carry the latest available copy of the data.

If the MC-OCF service is configured for a Master Channel, this excludes the use of the VC-OCF service for all Virtual Channels on that Master Channel.

The OCF services are buffered services (synchronous services).

The Telemetry Encoder Shell and Telemetry Decoder Shell support the use of the MC-OCF and VC-OCF services.

Idle Packets and Idle Data

Sometimes, a frame must be released before sufficient packet data is available to fill the frame. In this case, an Idle Packet may be used to complete the frame. Idle Packets are identified by a special Application Process Identifier of "all ones".

Idle Data is data which caries no information. To meet timing or synchronisation requirements, it may be necessary to send a Transfer Frame of Idle Data. In this case, the Idle Data occupies all of the Transfer Frame Data Field, though there may be meaningful data in other fields, such as the FSH.

The Telemetry Encoder Shell generates Idle Packets and Idle Data as required. The Telemetry Decoder Shell accepts and discards any Idle Packets or Idle Data contained in Transfer Frames it receives.

Privately formatted data and VCA service

The Virtual Channel Access (VCA) service of the TM Space Data Link Protocol provides for the transfer of privately formatted fixed-length service data units.

The current versions of the Telemetry Encoder Shell and Telemetry Decoder Shell do not support the VCA service. Support may be included in a later version if required.

Source Packet Segmentation

Earlier versions of the CCSDS recommendations defined an optional Source Packet segmentation scheme. It has been removed from all current versions of the CCSDS recommendations. The Telemetry Encoder Shell and Telemetry Decoder Shell do not support Source Packet segmentation.

Frame Error Control Field

A Frame Error Control Field may be included at the end of each Transfer Frame. It uses a CRC mechanism, which enables the receiver to detect errors in the frame.

The Telemetry Encoder Shell and Telemetry Decoder Shell support the use of Frame Error Control. It is a run-time configuration option for a Master Channel.

Virtual Channel Multiplexing

The streams of Transfer Frames from the Virtual Channels are multiplexed into the single Physical Channel. The Telemetry Encoder Shell uses a round-robin algorithm for this multiplexing. Each Virtual Channel in turn is given the opportunity to send a frame. If a channel has no packet data available at that time, it forfeits its turn.

The Telemetry Encoder Shell provides an override mechanism for selecting the next Transfer Frame to be sent. This mechanism is intended, for example, to force the sending of FSH data for a channel which currently has no packet data to send.

Alternative multiplexing algorithms may be added to the Telemetry Encoder Shell in future versions if required.

Channel Coding

The current versions of the Telemetry Encoder Shell and Telemetry Decoder Shell do not support any of the features of the TM Synchronization and Channel Coding recommendations. For example, they do not perform Reed-Solomon or convolutional coding or decoding for the transfer frames they handle. Future version of the Shells may support some of the coding options. The question of support depends on user requirements and performance issues.

TM Products TM Standards AOS Features TC Features