A bit about space communications standards
Satellite Meteor M1
Source: vladtime.ru
Introduction
The operation of space technology is impossible without radio communications, and in this article I will try to explain the basic ideas that formed the foundation of the standards developed by the Consultative Committee for Space Data Systems - CCSDS. This abbreviation will be used below.
This publication will be devoted mainly to the channel level, however, basic concepts for other levels will also be introduced. To become in no way claims to a thorough and complete description of the standards. You can find it on the websiteCCSDS. However, they are very difficult to perceive, and to understand them we spent a lot of time, so here I want to give basic information, having which to deal with everything else will be much easier. So, let's begin.
The noble mission of CCSDS
Perhaps someone had a question: why should everyone adhere to standards if you can develop your own proprietary protocol protocol stack (or your own standard, with blackjack and new features), thereby increasing the security of the system?
As practice shows, it is more profitable to adhere to CCSDS standards for the following series of reasons:
- The committee responsible for publishing the standards included representatives of all the major aerospace agencies in the world, bringing in their invaluable experience gained over many years of designing and operating various missions. It would be very ridiculous to ignore this experience and again step on their rake.
- These standards are supported by ground station equipment already on the market.
- During troubleshooting, you can always ask for help from colleagues from other agencies so that they can conduct a communication session with the device from their ground station.
Architecture
Standards are a set of documents reflecting the most common OSI (Open System Interconnection) model, except that at the channel level, the community is limited to the division into telemetry (channel "down" - space - Earth) and telecommands (channel "up").
Consider some levels in more detail, starting with the physical, and moving up. For greater clarity, we will consider the architecture of the host side. The transmitter is its mirror image.
Physical level
At this level, the modulated radio signal is converted to a bit stream. The standards here are mostly recommendatory in nature, since at this level it is difficult to ignore the specific implementation of iron. Here, the key role of CCSDS is to determine the permissible modulations (BPSK, QPSK, 8-QAM, etc.) and give some recommendations on the implementation of symbol synchronization mechanisms, Doppler shift compensation, etc.
Sync and Encoding Level
Formally, it is a sublayer of the data link layer, but very often it is allocated as a separate layer because of its importance within the framework of CCSDS standards. This level converts the bitstream into the so-called frames (telemetry or telecommands), which we will talk about later. Unlike character synchronization at the physical level, which allows you to get the correct bitstream, frame synchronization is performed here. Consider the way that data goes at this level (from bottom to top):
However, before that, a few words about coding should be said. This procedure is necessary to find and / or correct bit errors that inevitably occur when sending data over the air. Here we will not consider decoding procedures, but only obtain the information necessary to understand the further logic of the level.
Codes are block and continuous. Standards do not force the use of a particular type of coding, but it must be present as such. The continuous ones include convolutional (colvolutional) codes. Using them, a continuous bit stream is encoded. Unlike block codes, where data is divided into code blocks (codeblock), and can only be decoded as part of whole blocks. The code block is the transmitted data and the attached redundant information necessary to verify the correctness of the data and correct possible errors. Block codes include the famous Reed-Solomon codes.
If convolutional coding is used, the bitstream from the beginning goes to the decoder. The result of his work (all this, of course, is happening continuously) are CADU data units (channel access data unit). This structure is necessary for frame synchronization. At the end of each CADU is attached a synchronization marker (ASM - attached synch maker). These are 4 bytes known in advance, by which the synchronizer finds the beginning and end of the CADU. This is how frame synchronization is achieved.
The next optional stage of operation of the synchronization and coding layer is associated with the features of the physical layer. This is derandomization. The fact is that in order to achieve symbol synchronization, frequent switching between symbols is necessary. So, if we transfer, say, a kilobyte of data consisting solely of units, the synchronization will be lost. Therefore, during transmission, the input data is mixed with a periodic pseudo-random sequence so that the density of zeros and ones is uniform.
Next, block codes are decoded, and what remains will be the final product of the synchronization and coding level - frame.
Channel level
On the one hand, the link layer handler receives frames, and on the other hand it produces packets. Since formally the size of packets is not limited, for their reliable forwarding it is necessary to break them into smaller structures - frames. Here we consider two subsections: separately for telemetry (TM) and telecommands (TC).
Telemetry
Simply put, this is the data that the ground station receives from the spacecraft. All transmitted information is divided into small fragments of a fixed length - frames that contain the transmitted data and service fields. Let's consider the frame structure in more detail:
And we will begin our consideration with the main heading of the telemetry frame. Further, I will allow myself in some places to simply translate the standards, simultaneously giving some clarification.
The field of the identifier of the main channel (Master Channel ID) must contain the version number of the frame and the identifier of the device.
Each spacecraft, according to CCSDS standards, must have its own unique identifier, by which it is possible, having a frame, to determine which vehicle it belongs to. Formally, it is necessary to apply for registration of the device, and its name, together with the identifier, will be published in open sources. However, often Russian manufacturers ignore this procedure, assigning an arbitrary identifier to the device. The frame version number helps determine which version of the standards is used to correctly read the frame. Here we consider only the most conservative standard with version “0”.
The Virtual Channel ID must contain the VCID of the channel from which the packet came. There are no restrictions on the choice of VCID, in particular, virtual channels are not necessarily numbered sequentially.
Very often there is a need to multiplex the transmitted data. There is a virtual channel mechanism for this. For example, the Meteor-M2 satellite transmits a color image in the visible range, dividing it into three black and white ones - each color is transmitted in its virtual channel as a separate package, although there is some deviation from the standards in the structure of its frames.
The Operational Control flag field should be an indicator of the presence or absence of the Operational Control field in the telemetry frame. These 4 bytes at the end of the frame serve to maintain feedback when monitoring the delivery of telecommand frames. We will talk about them a little later.
The frame counters of the main and virtual channels are fields that are incremented by one when each frame is sent. They serve as an indicator that no frame has been lost.
The status of telemetry frame data is two more bytes of flags and data, of which we will consider only a few.
The flag field of the secondary header (Secondary Header) should be an indicator of the presence or absence of the secondary header (Secondary Header) in the telemetry frame.
If desired, you can add an additional header to each frame and place any data there at your discretion.
The field of the pointer to the first header (First Header Pointer), with the value of the synchronization flag “1”, must contain the binary representation of the position of the first octet of the first packet in the data field of the telemetry frame. The position is counted from 0 in ascending order from the beginning of the data field. If there is no beginning of a packet in the data field of the telemetry frame, then the field of the pointer to the first header should have a value in the binary representation “11111111111” (this can happen if one long packet extends to more than one frame).
If the data field contains an empty packet (Idle Data), then the pointer to the first header must have a value in the binary representation "11111111110". In this field, the receiver should synchronize the stream. This field guarantees restoration of synchronization even in case of skipping frames.
That is, a packet can, suppose, start in the middle of the 4th frame, and end at the beginning of the 20th. To find its beginning, this field just serves. Packets also have a heading in which its length is registered, so when a pointer to the first heading is found, the data link handler should read it, thereby determining where the packet will end.
If an error control field is presented, then it should be contained in each telemetry frame for a particular physical channel throughout the mission.
This field is calculated using the CRC method. The procedure should accept n-16 bits of the telemetry frame and insert the calculation result into the last 16 bits.
Telecommands
The telecommand frame has several significant differences. Among them:
- Different header structure
- Dynamic length. This means that the frame length is not set rigidly, as is done in telemetry, but may vary depending on the transmitted packets.
- Package delivery guarantee mechanism. That is, the spacecraft must, upon receipt, confirm the correct reception of frames, or request forwarding from the frame that could be received with an uncorrectable error.
Many fields are already familiar to us from the telemetry frame header. They have the same purpose, so here we consider only new fields.
One bit of the bypass flag should be used to monitor the frame check at the receiver. The value “0” of this flag should indicate that this frame is a type A frame and should be checked according to FARM. The value “1” of this flag should indicate to the receiver that this frame is a type B frame and should bypass the check according to FARM.
This flag informs the receiver whether to use the frame delivery confirmation mechanism called FARM - Frame Acceptance and Reporting Mechanism.
The control command flag should be used to understand whether the data field is transporting the command or data. If the flag is “0”, then the data field should contain data. If the flag is “1”, then the data field should contain the control information for the FARM.
FARM is a state machine whose parameters can be configured.
RSVD. SPARE - reserved bits.
It seems that CCSDS has plans for them in the future, and for backward compatibility of protocol versions, they reserved these bits already in current versions of the standard.
The frame length field should contain a number in the bit representation, which is equal to the frame length in octets minus one.
The frame data field should follow the header without gaps and contain an integer number of octets, which can be a maximum of 1019 octets. This field must contain either a block of frame data or information from a control command. The frame data block must contain:
- octet integer user data
- segment header followed by an integer octet of user data
If a header is provided, then the data block should contain a Package, many Packets or part of it. A data block without a header cannot contain parts of Packets, but it can contain data blocks of a private format. From this it follows that the header is required when the transmitted data block does not fit in one frame. A data block with a header is called a segment.
A two-bit flag field should contain:
- “01” - if the first part of the data is in the data block
- "00" - if the middle part of the data is in the data block
- "10" - if the last piece of data is in the data block
- “11” - if there is no division and one or more packets are placed in the data block as a whole.
The MAP identifier field must contain zeros if MAP channels are not used.
Sometimes 6 bits allocated to virtual channels is not enough. And if you need to multiplex data onto a larger number of channels, another 6 bits from the segment header are used.
Farm
Let us consider in more detail the functioning mechanism of the personnel delivery control system. This system only provides for working with telecom personnel in view of their importance (telemetry can always be requested again, and the spacecraft must hear the ground station clearly, and always obey its commands). So, suppose we decided to reflash our satellite, and send a 10 kilobyte binary file on board. At the channel level, the file is divided into 10 frames (0, 1, ..., 9), which are sent one at a time to the top. When the transmission is completed, the spacecraft must confirm the correct reception of the packet, or report on which frame an error occurred. This information is sent to the operational control field in the nearest telemetry frame (Or the spacecraft can initiate the transmission of an empty frame (idle frame) if it has nothing to say). By telemetry, we are either convinced that everything is fine, or proceed to resend the message. Suppose the satellite did not hear frame No. 7. So, we send frames 7, 8, 9. If there is no answer, the packet is sent again completely (and so on several times until we understand that the attempts are futile).
Below is the structure of the field of operational control with a description of some fields. The data contained in this field is called CLCW - Communication Link Control Word.
Since it’s quite possible to guess from the picture the purpose of the main fields, while looking at the others is boring, I hide the detailed description under the spoiler
Decoding CLCW fields
Control Word Type:
For this type of control word, must contain 0
CLCW Version Number:
For this type of control word should be “00” in bit representation.
Status Field:
The use of this field is determined for each mission separately. It can be used for local improvements by different space agencies.
Virtual Channel Identification:
Must contain the identifier of the virtual channel this control word is associated with.
Physical Channel Access Flag:
The flag should provide information about the readiness of the physical layer of the receiver. If the physical level of the receiver is not ready for receiving frames, then the field should contain “1”, otherwise “0”.
Synchronization Failure Flag: A
flag may indicate that the physical layer is operating at a poor signal level and the number of rejected frames is too high. The use of this field is optional, if used, it should contain "0" in the presence of synchronization, and "1" in its absence.
Lock flag:
This bit must contain the FARM lock status for each virtual channel. The value “1” in this field should indicate that the FARM is locked and frames will be dropped for each virtual level, otherwise “0”.
Waiting flag:
This bit should be used to indicate that the receiver cannot process the given on the specified virtual channel. A value of "1" indicates that all frames will be discarded on this virtual channel, otherwise "0".
Resend flag:
This flag must contain “1” if one or more Type A frames were dropped or gaps were found, so resending is necessary. Flag “0” indicates that there were no discarded frames and omissions.
Response value: The
number of the frame that was not received. It is determined by the counter in the header of the telecommands frame.
For this type of control word, must contain 0
CLCW Version Number:
For this type of control word should be “00” in bit representation.
Status Field:
The use of this field is determined for each mission separately. It can be used for local improvements by different space agencies.
Virtual Channel Identification:
Must contain the identifier of the virtual channel this control word is associated with.
Physical Channel Access Flag:
The flag should provide information about the readiness of the physical layer of the receiver. If the physical level of the receiver is not ready for receiving frames, then the field should contain “1”, otherwise “0”.
Synchronization Failure Flag: A
flag may indicate that the physical layer is operating at a poor signal level and the number of rejected frames is too high. The use of this field is optional, if used, it should contain "0" in the presence of synchronization, and "1" in its absence.
Lock flag:
This bit must contain the FARM lock status for each virtual channel. The value “1” in this field should indicate that the FARM is locked and frames will be dropped for each virtual level, otherwise “0”.
Waiting flag:
This bit should be used to indicate that the receiver cannot process the given on the specified virtual channel. A value of "1" indicates that all frames will be discarded on this virtual channel, otherwise "0".
Resend flag:
This flag must contain “1” if one or more Type A frames were dropped or gaps were found, so resending is necessary. Flag “0” indicates that there were no discarded frames and omissions.
Response value: The
number of the frame that was not received. It is determined by the counter in the header of the telecommands frame.
Network layer
A little touch on this level. Two options are possible here: either use the space packet protocol, or encapsulate any other protocol in the CCSDS packet.
A review of the space packet protocol is a topic for a separate article. It was created so that the so-called applications can seamlessly exchange data. Each application has its own address, and basic functionality for exchanging data with other applications. There are also services that route traffic, perform delivery control, etc.
With encapsulation, everything is simpler and more understandable. Standards make it possible to encapsulate any protocol in CCSDS packets by adding an additional header.
Where the header has different meanings depending on the length of the encapsulated protocol:
Here the main field is the length length. It can vary from 0 to 4 bytes. Also in this header you must specify the type of encapsulated protocol, using the table from here .
When encapsulating IP, another add-in is used to determine the type of packet.
You need to add another header, starting from one octet in length:
Where PID is another protocol identifier taken from here
Conclusion
At first glance, it might seem that the CCSDS headers are extremely redundant, and some fields might be discarded. Indeed, the efficiency of the resulting channel (up to the network level) is about 40%. However, as soon as it becomes necessary to implement these standards, it becomes clear that each field, each heading has its own important mission, the ignoring of which leads to a number of ambiguities.
If the habitation community shows interest in this topic, I will be glad to publish a whole series of articles devoted to the theory and practice of space communications. Thanks for attention!
Sources
CCSDS 130.0-G-3 - Overview of the space communications protocols
CCSDS 131.0-B-2 - TM synchronization and channel coding
CCSDS 132.0-B-2 - TM Space Data Link Protocol
CCSDS 133.0-B-1 - Space packet protocol
CCSDS 133.1- B-2 - Encapsulation Service
CCSDS 231.0-B-3 - TC Synchronization and Channel Coding
CCSDS 232.1-B-2 Communications Operation Procedure-1
CCSDS 401.0-B-28 Radio Frequency and Modulation Systems - Part 1 (Earth Stations and Spacecraft)
CCSDS 702.1-B-1 - IP over CCSDS space links
P.S.
Do not hit hard if you find inaccuracies. Report them and they will be fixed :)