Telecommand Features
This page describes some of the telecommand features supported by the Telecommand Encoder Shell and Telecommand Decoder Shell. For the definition of the features described here, see the standards documents.
Note: Older issues of the standards use the term Packet Telecommand for
the protocols that transport data units, such as packets, in
TC Transfer Frames.
However, the protocols are not limited to packets. The current standards
no longer use the term.
Telecommand Services
The TC Space Data Link Protocol defines six services for transporting telecommand Service Data Units (SDUs). A seventh service provides management of the COP-1 protocol.
- MAP Packet (MAPP), for a packet
- MAP Access (MAPA), for a MAP_SDU
- Virtual Channel Packet (VCP), for a packet
- Virtual Channel Access (VCA), for a VCA_SDU
- Virtual Channel Frame (VCF), for a transfer frame
- Master Channel Frame (MCF), for a transfer frame
- COP Management (COPM), for passing directives to COP-1
The Telecommand Encoder Shell and Telecommand Decoder Shell support
any valid combination of the services.
Packets
The Telecommand Encoder Shell and Telecommand Decoder Shell handle the following types of packets on the MAP Packet (MAPP) and Virtual Channel Packet (VCP) services:
- CCSDS Space Packets (also known as Telecommand Packets or Source Packets)
- CCSDS Encapsulation Packets
MAP-SDU
The MAPA service handles MAP_SDUs, which are privately formatted service data units of variable length.
The MAPA service can therefore be used for many applications which have a non-CCSDS packet format.
VCA-SDU
The VCA service handles VCA_SDUs.
A VCA_SDU is a service data unit to be placed in the Transfer Frame Data Field of a transfer frame.
Type-A service and Type-B service
There are two service types for handling telecommand data:
- The Type-A service uses the COP-1 "go-back-n" automatic retransmission protocol and provides delivery of transfer frames in-sequence, without gaps, and without duplication. This is sometimes referred to as the Type-A service guarantee.
- The Type-B service provides no automatic retransmission, so there is no guarantee that sequences of transfer frames will be delivered without gaps.
- Type-A service is also known as Sequenced Controlled Service, A Service or AD Service.
- Type-B service is also known as Expedited Service, B Service or BD Service.
The Telecommand Encoder Shell and Telecommand Decoder Shell support
any combination of the two service types.
The service type is a parameter for each individual SDU submitted to the
Telecommand Encoder Shell for the MAPP, MAPA, VCP or VCA service.
Directives
The COP Management service is used for passing directives to COP-1 for managing the Type-A service. There are directives to initiate and terminate the Type-A service. Other directives set parameters such as timers and transmission limits.
The Telecommand Encoder Shell supports all the directives defined for the COP Management service.
Virtual Channels (VCs)
Multiple Virtual Channels (VCs) can share the capacity of a single Physical Channel. The Telecommand Encoder Shell and Telecommand Decoder Shell support up to 64 Virtual Channels. The VC configuration is set at run time.
Transfer frames from the Virtual Channels are multiplexed onto the Physical Channel. The Telecommand Encoder Shell supports various VC multiplexing algorithms:
- FIFO
- round robin
- polling vector
- absolute priority
- special channel priority
MAPs - Multiplexer Access Points
Telecommand SDUs from different sources may be multiplexed together so that they share one Virtual Channel. This is accomplished by using Multiplexer Access Points (MAPs).
The Telecommand Encoder Shell and Telecommand Decoder Shell support up to 64 MAPs on each Virtual Channel. The MAP configuration is set at run time.
In the Telecommand Encoder Shell, the input for the
MAPs is multiplexed onto the Virtual Channel using a FIFO algorithm.
Segmentation of packets and MAP_SDUs
Segmentation is the process of breaking long packets and MAP_SDUs into segments and transmitting each segment in a separate transfer frame. On arrival, the packet or MAP_SDU is reassembled from the segments. Segmentation makes it possible to send data units which are too big to fit in a single transfer frame. Segmentation is available for the MAPP and MAPA services and is usually limited to data units transmitted on the Type-A service.
The Telecommand Encoder Shell and Telecommand Decoder Shell support segmentation and reassembly. It is a run-time configuration option which can be set for each individual MAP. Additional parameters control segmentation on the Type-A and Type-B services within a Virtual Channel.
The Telecommand Encoder Shell and Telecommand Decoder Shell also include a run-time configuration
option to support the ESA-specified Packet Assembly Controller (PAC) and its associated MAP Reset command.
Packet Aggregation or Blocking
Packet aggregation is the process of placing multiple packets together so that they are all transmitted in a single transfer frame. The aggregated packets must be complete: for example, it is not allowed to aggregate three whole packets with part of a fourth.
Packet aggregation is also known as blocking.
The Telecommand Encoder Shell and Telecommand Decoder Shell support
packet aggregation on the MAPP and VCP services.
It is a run-time configuration option.
There are configuration parameters to set the aggregation timer and to limit
the number of packets that may be placed in a segment.
Individual packets may carry a "do not aggregate" parameter.
Maximum Frame Length
The standards define a maximum transfer frame length of 1024 octets.
The Telecommand Encoder Shell and the Telecommand Decoder Shell support transfer frames of all
valid lengths up to 1024 octets.
There is a run-time configuration option to set a lower maximum length for a Virtual Channel or a Physical Channel.
Frame Error Control
The standards define an optional Frame Error Control Field that may be included at the end of every transfer frame. It uses a CRC mechanism, which enables the receiver to detect errors in the frame.
The Telecommand Encoder Shell and the Telecommand Decoder Shell support the use of Frame Error Control.
It is a run-time configuration option.
CLCW - Communications Link Control Word
The CLCW (Communications Link Control Word) carries the return data of the COP-1 protocol. CLCWs are carried in telemetry frames.
The earlier name for the CLCW was Command Link Control Word.
The Telecommand Decoder Shell generates CLCWs on demand. The Telecommand Encoder Shell
expects CLCWs extracted from the downlink telemetry.
CLTU - Communications Link Transmission Unit
The Coding Sublayer in the ground end of the telecommand system converts transfer frames into Communications Link Transmission Units (CLTUs), earlier known as Command Link Transmission Units.
The data from the frame is encoded into a set of equal-length codeblocks. The last codeblock in a CLTU may include fill bits to bring it up to the correct length.
The Telecommand Encoder Shell generates and delivers CLTUs.
The Telecommand Decoder Shell accepts and processes CLTUs.
BCH code
In a CLTU, the last octet of each codeblock contains a BCH code, which enables the receiver to detect (and possibly correct) errors.
The Telecommand Encoder Shell generates the BCH code in each codeblock. The Telecommand Decoder Shell accepts and processes candidate BCH codeblocks.
The Telecommand Decoder Shell has a run-time configuration parameter to select the processing to be
performed on the BCH field of each codeblock. The parameter may be set for triple error detection or
for single error correction.
CLTU Randomisation
The standards define an option for randomisation of the data in each CLTU. The Telecommand Encoder Shell and Telecommand Decoder Shell support three alternatives for CLTU randomisation. It is a run-time configuration option.
- No randomisation (default). The data in the CLTUs is not randomised.
- The data portion of each CLTU is randomised, but any fill bits in the final codeblock of the CLTU are not randomised.
- The data portion of each CLTU is randomised, and any fill bits in the final codeblock of the CLTU are also randomised.
CLTU Tail Sequences
Every CLTU has a tail sequence. The Telecommand Encoder Shell and Telecommand Decoder Shell support three alternatives for the tail sequence. It is a run-time configuration option.
- 8-octet tail sequence and an idle octet. All the octets contain hexadecimal 55. This follows the original ESA recommendation of June 1990.
- 8-octet tail sequence of hexadecimal 55, but without the idle octet. This follows the original CCSDS recommendation of January 1987.
- 8-octet tail sequence consisting of seven octets of hexadecimal C5 and an eighth octet containing hexadecimal 79. This is the current CCSDS recommendation and the current ESA and ECSS recommendation.
Repeated transmission of CLTUs
The September 2010 issues of the CCSDS recommended standards include an option for the repeated transmission of CLTUs in the Synchronization and Channel Coding Sublayer.
The Telecommand Encoder Shell supports the repeated transmission. The Shell has run-time configuration parameters for repeated transmissions of CLTUs carrying frames for the Type-A service (AD and BC frames) on a Virtual Channel. The repeated transmission does not apply to frames for the Type-B service (BD frames).
The repeated transmission does not affect the behaviour of the receiving end and therefore does not affect the Telecommand Decoder Shell.
Security and Telecommand Authentication
The Telecommand Encoder Shell and Telecommand Decoder Shell have optional extras to support:
- telecommand authentication with the ESA Authentication Unit
- external implementation of security / authentication with the Segment Level Security Interface (SLSI).