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 main ideas that formed the basis of the standards developed by the International Consultative Committee for Space Data Systems (CCSDS. This abbreviation will be used further).
This publication will be devoted mainly to the link layer, however, the basic concepts for other layers will also be introduced. Article in no way claims to be a thorough and complete description of the standards. You can familiarize yourself with it at CCSDS. However, they are very difficult to understand, and we spent a lot of time to figure them out, so here I want to give basic information, having which it will be much easier to deal with everything else. So, let's begin.
The noble mission of CCSDS
Perhaps someone has a question: why should everyone adhere to standards if you can develop your own proprietary stack of radio protocols (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 number of reasons:
- The committee responsible for publishing the standards includes representatives from all the major aerospace agencies in the world, bringing their invaluable experience gained over many years of design and operation of various missions. It would be very ridiculous to ignore this experience and step on their rake again.
- These standards are supported by ground station equipment already on the market.
- In the course of troubleshooting any problems, you can always ask for help from colleagues from other agencies so that they conduct a communication session with the device from their ground station. As you can see, standards are extremely useful, so let's look at their key points.
Architecture
The standards are a set of documents reflecting the most common OSI (Open System Interconnection) model, except that at the data link level, the generality is limited to the division into telemetry (downward-space-to-Earth channel) and telecommands (upward channel).
Let's look at some levels in more detail, starting with the physical and moving up. For greater clarity, we will consider the architecture of the host. The transmitter is its mirror image.
Physical layer
At this level, the modulated radio signal is converted into a bit stream. The standards here are mostly advisory in nature, since at this level it is difficult to abstract from the specific implementation of iron. Here, the key role of CCSDS is to determine the allowed modulations (BPSK, QPSK, 8-QAM, etc.) and give some recommendations on the implementation of symbol synchronization mechanisms, Doppler shift compensation, etc.
Synchronization and encoding level
Formally, it is a sublayer of the link layer, but very often it is separated into a separate layer due to its importance within the CCSDS standards. This layer converts the bit stream into so-called frames (telemetry or telecommands), which we will talk about later. Unlike symbol synchronization at the physical layer, which allows you to get the correct bit stream, frame synchronization is performed here. Consider the path that the data takes at a given level (from bottom to top):
However, before that, it is worth saying a few words about coding. 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 the decoding procedures, but only obtain the information necessary to understand the further logic of the level.
Codes are block and continuous. The standards do not force the use of a specific encoding type, but it must be present as such. Convolutional (colvolutional) codes are continuous. They encode a continuous bitstream. Unlike block codes, where data is divided into code blocks (codeblock), and can only be decoded within solid blocks. The code block is the transmitted data and the attached redundant information necessary to check the correctness of the data received and correct possible errors. Block codes include the famous Reed-Solomon codes.
If convolutional encoding is used, the bitstream is fed to the decoder from the beginning. The result of his work (all this, of course, happens continuously) are CADU (channel access data unit) data blocks. This structure is necessary for frame synchronization. At the end of each CADU, an attached synch maker (ASM) is attached. These are 4 bytes known in advance, by which the synchronizer finds the beginning and end of CADU. This is how frame synchronization is achieved.
The next optional step in the operation of the synchronization and coding layer is related to the features of the physical layer. This is derandomization. The fact is that frequent switching between symbols is necessary to achieve symbol synchronization. So, if we transfer, say, a kilobyte of data consisting entirely of ones, 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, the block codes are decoded, and what is left will be the final product of the synchronization and coding layer - the frame.
Link level
On the one hand, the link layer handler receives frames, and on the other hand, it issues packets. Since formally the size of packets is not limited, for their reliable transmission it is necessary to break them into smaller structures - frames. Here we will consider two subsections: separately for telemetry (TM) and telecommands (TC).
Telemetry
Simply put, these are 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 take a closer look at the frame structure:
And let's start with the main header of the telemetry frame. Further, I will allow myself in some places to simply translate the standards, along the way giving some explanations.
The Master Channel ID field must contain the frame version number and device ID.
Each spacecraft, according to CCSDS standards, must have its own unique identifier, by which it is possible, having a frame, to determine which device it belongs to. Formally, it is necessary to submit an application 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 being used to correctly read the frame. Here we will consider only the most conservative standard with version "0".
The Virtual Channel ID field must contain the VCID of the channel from which the packet arrived. 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. To do this, there is a mechanism of virtual channels. 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 in a separate package, although there is some deviation from the standards in the structure of its frames.
The Operational Control flag field shall be an indicator of the presence or absence of an Operational Control field in the telemetry frame. These 4 bytes at the end of the frame are used to maintain feedback while 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 each time a frame is sent. Serves as an indicator that no frames have been lost.
The data status of the telemetry frame is two more bytes of flags and data, of which we will look at just a few.
The Secondary Header Flag field shall be an indicator of the presence or absence of a 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 First Header Pointer field, when set to 1, shall hold 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 packet start in the data field of the telemetry frame, then the pointer to the first header field should have a binary value of "11111111111" (this can happen if one long packet spans 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". The receiver must use this field to synchronize the stream. This field ensures that synchronization is restored even if frames are dropped.
That is, the packet may, for example, 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 header that specifies its length, so when it finds a pointer to the first header, the link layer processor must read it, thereby determining where the packet will end.
If an error control field is present, then it must be contained in every telemetry frame for a particular physical channel throughout the mission.
This field is calculated using the CRC method. The procedure must take n-16 bits of the telemetry frame and insert the result of the calculation 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 rigidly set, as is done in telemetry, but may vary depending on the transmitted packets.
- Packet delivery guarantee mechanism. That is, the KA must, after receiving, confirm the correctness of receiving frames, or request a transfer 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 will only consider the new fields.
One bit of the bypass flag must be used to control frame checking at the receiver. The value "0" of this flag should indicate that this frame is a type A frame and its checking should be carried out 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 FARM check.
This flag informs the receiver whether to use the FARM - Frame Acceptance and Reporting Mechanism.
The control command flag must be used to understand whether the data field is transporting a command or data. If the flag is "0", then the data field must contain data. If the flag is "1", then the data field must contain control information for FARM.
FARM is a state machine whose parameters are configurable.
RSVD. SPARE - reserved bits.
It seems that CCSDS has plans for them in the future, and for backward compatibility of protocol versions, they have reserved these bits already in current versions of the standard.
The frame length field shall contain a number in bit representation equal to the length of the frame in octets minus one.
The frame data field shall follow the header without gaps and contain an integer number of octets, which may be a maximum of 1019 octets in length. This field shall contain either a frame data block or control command information. The frame data block must contain:
- integer number of user data octets
- segment header followed by an integer number of user data octets
If a header is present, then the data block must contain a Packet, a set of 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. It follows from this that the header is required when the transmitted data block does not fit in one frame. A block of data with a header is called a segment.
The two-bit flags field shall 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 fit entirely in the data block.
The MAP identifier field shall contain zeros if MAP channels are not used.
Sometimes 6 bits allocated to virtual channels is not enough. And if it is necessary to multiplex data on a larger number of channels, 6 more bits from the segment header are used.
FARM
Let us consider in more detail the mechanism of functioning of the frame delivery control system. This system provides only work with frames of telecommands due to 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 decide to reflash our satellite, and send a binary file of 10 kilobytes in size to it. At the link level, the file is divided into 10 frames (0, 1, ..., 9), which are sent one by one to the top. When the transmission is completed, the KA must confirm the correctness of the packet reception, or report on which frame the error occurred. This information is sent to the field of operational control in the next frame of telemetry (Or the KA can initiate the transmission of an empty frame (idle frame) if it has nothing to say). According to the received telemetry, we either make sure that everything is fine, or start resending the message. Suppose the satellite did not hear frame #7. This means that we send him frames 7, 8, 9. If there is no response, the packet is sent in its entirety again (and so on several times until we realize that the attempts are futile).
Below is the structure of the operational control field with a description of some of the fields. The data contained in this field is called CLCW - Communication Link Control Word.
Since it is quite possible to guess the purpose of the main fields from the picture, and itβs boring to look at others, I hide the detailed description under the spoiler
Explanation of CLCW fieldsControl Word Type:
For this type of control word must contain 0
Control Word Version (CLCW Version Number):
For this type of control word, it must be equal to "00" in bit representation.
Status Field:
The use of this field is determined for each mission separately. Can be used for local enhancements by various space agencies.
Virtual Channel Identification:
Must contain the identifier of the virtual channel with which this control word is associated.
Physical channel access flag:
The flag should provide information about the readiness of the physical layer of the receiver. If the physical layer of the receiver is not ready to receive frames, then the field should contain "1", otherwise "0".
Synchronization failed flag:
The flag may indicate that the physical layer is working with a bad signal level and the number of discarded frames is too high. The use of this field is optional, if used, it should contain "0" if there is synchronization, and "1" if it is not.
Lock flag:
This bit shall contain the FARM lock status for each virtual channel. The value "1" in this field should indicate that FARM is disabled and frames will be dropped for each virtual level, otherwise "0".
Wait flag:
This bit shall be used to indicate that the receiver cannot process the data on the specified virtual channel. A value of "1" indicates that all frames will be dropped on this virtual channel, otherwise "0".
Forward flag:
This flag must be set to "1" if one or more Type A frames were dropped or gaps were found, so a retransmission is required. The "0" flag indicates that there were no dropped frames or gaps.
Answer value:
Frame number that was not received. Determined by the counter in the header of the telecommand frame
network layer
Let's touch on this level a bit. Two options are possible here: either use the space packet protocol, or encapsulate any other protocol in the CCSDS packet.
An overview of the space packet protocol is a topic for a separate article. It is designed to allow so-called applications to communicate seamlessly. Each application has its own address, and basic functionality for exchanging data with other applications. There are also services that perform traffic routing, delivery control, etc.
With encapsulation, everything is simpler and clearer. The standards make it possible to encapsulate any protocols 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 of the length. It can vary from 0 to 4 bytes. Also in this header, you must specify the type of encapsulated protocol, using the table .
IP encapsulation uses another add-on to determine the packet type.
You need to add one more header, with a length of one octet:
Where PID is another protocol identifier, taken
Conclusion
At first glance, it might seem that the CCSDS headers are extremely redundant, and some fields could be omitted. Indeed, the efficiency of the resulting channel (up to the network layer) 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, ignoring which leads to a number of ambiguities.
If the habrasociety shows interest in this topic, I will be glad to publish a number of more articles on the theory and practice of space communications. Thank you for your attention!
Sources of
PS
Do not hit hard if you find inaccuracies. Report them and they will be fixed :)
Source: habr.com