{"id":35921,"date":"2019-10-31T22:07:35","date_gmt":"2019-10-31T19:07:35","guid":{"rendered":"https:\/\/prohoster.info\/blog\/nemnogo-o-standartah-kosmicheskoj-svyazi\/"},"modified":"2019-10-31T22:07:35","modified_gmt":"2019-10-31T19:07:35","slug":"nemnogo-o-standartah-kosmicheskoj-svyazi","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/nemnogo-o-standartah-kosmicheskoj-svyazi","title":{"rendered":"A Little About Space Communication Standards","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"A
\nMeteor M1 Satellite
\nSource: vladtime.ru<\/i><\/p>\n

Introduction<\/h2>\n

\nOperating space technology is impossible without radio communication, and in this article, I will attempt to explain the main ideas that form the basis of the standards developed by the Consultative Committee for Space Data Systems (CCSDS). This abbreviation will be used going forward.<\/p>\n

This publication will mainly focus on the channel level; however, the key concepts for other levels will also be introduced. This article does not claim to provide a comprehensive and complete description of the standards. You can familiarize yourself with them on the website<\/a><\/noindex> CCSDS. However, they are quite challenging to understand, and we spent considerable time to figure them out, so I want to present basic information that will make it much easier to grasp everything else. So, let's begin.
\n<\/a><\/noindex><\/p>\n

The Noble Mission of CCSDS<\/h2>\n

\nPerhaps someone might wonder: why should everyone adhere to standards if one can develop their proprietary stack of radio communication protocols (or their own standard, with blackjack and new features), thereby enhancing system security?<\/p>\n

As practice shows, it is more advantageous to follow the CCSDS standards for a number of reasons:<\/p>\n

    \n
  1. The committee responsible for publishing the standards includes representatives from all major aerospace agencies in the world, bringing invaluable experience gained over many years in designing and operating various missions. It would be quite absurd to ignore this experience and step on the same rakes again.<\/li>\n
  2. These standards are supported by existing ground station equipment already available on the market.<\/li>\n
  3. In case of troubleshooting, one can always seek assistance from colleagues at other agencies to establish a communication session with the spacecraft from their ground station. As you can see, standards are extremely useful, so let's delve into their key aspects.<\/li>\n<\/ol>\n

    <\/p>\n

    Architecture<\/h2>\n

    \nThe standards comprise a set of documents reflecting the conventional OSI (Open System Interconnection) model, except that at the channel level, the commonality is limited to separating telemetry (the 'down' link - space to Earth) and telecommands (the 'up' link).<\/p>\n

    \"A
    \n
    \nLet's take a closer look at some levels, starting from the physical one and moving upwards. For better clarity, we will examine the architecture of the receiving side. The transmitting side is its mirror reflection.<\/p>\n

    Physical Layer<\/h2>\n

    \nAt this level, the modulated radio signal is converted into a bitstream. The standards here are mostly advisory, as it is difficult to abstract from the specific hardware implementation at this level. The key role of CCSDS is to define permissible modulations (BPSK, QPSK, 8-QAM, etc.) and provide some recommendations for implementing mechanisms for symbol synchronization, Doppler shift compensation, and so on.<\/p>\n

    Synchronization and Coding Level<\/h2>\n

    \nFormally, it is a sublayer of the channel layer; however, it is often highlighted as a separate level due to its importance within the CCSDS standards. This level converts the bitstream into so-called frames (telemetry or telecommand), which we will discuss later. Unlike symbol synchronization at the physical level, which allows for obtaining a correct bitstream, here, frame synchronization is performed. Let's review the path that data takes at this level (bottom to top):<\/p>\n

    \"A
    \n
    \nHowever, it is worth saying a few words about coding before that. This procedure is necessary to detect and\/or correct bit errors that inevitably occur when sending data over a radio channel. We will not discuss decoding procedures here, but will only gather information necessary for understanding the further logic of the level's operation. <\/p>\n

    There are block and convolutional codes. The standards do not require a specific type of coding to be used; however, coding as such must be present. Convolutional codes are classified as continuous. They encode a continuous bitstream. Unlike block codes, where data is divided into code blocks, which can only be decoded within intact blocks. A code block consists of the transmitted data and the associated redundant information required to verify the correctness of data reception and to correct possible errors. Reed-Solomon codes are among the well-known block codes.<\/p>\n

    If convolution encoding is used, the bitstream starts flowing into the decoder. The result of its operation (of course, all this happens continuously) is blocks of data called CADU (channel access data unit). This structure is necessary for frame synchronization. At the end of each CADU, a synchronization marker (ASM \u2013 attached synch marker) is attached. This is a predetermined 4 bytes, which the synchronizer uses to find the beginning and end of the CADU. This is how frame synchronization is achieved.<\/p>\n

    The next optional stage of the synchronization and encoding level is related to the specifics of the physical layer. This is derandomization. The fact is that achieving symbol synchronization requires frequent switching between symbols. For instance, if we were to transmit, say, a kilobyte of data consisting exclusively of ones, synchronization would be lost. Therefore, during transmission, the input data is mixed with a periodic pseudorandom sequence to ensure an even density of zeros and ones.<\/p>\n

    Next, the decoding of block codes occurs, and what remains will be the final product of the synchronization and encoding level \u2013 a frame.<\/p>\n

    Channel Level<\/h2>\n

    \nOn one hand, the channel level handler receives frames, and on the other, it outputs packets. As the size of packets is formally unlimited, they must be broken down into smaller structures \u2013 frames \u2013 for reliable transmission. Here we will consider two subsections: one for telemetry (TM) and one for telecommand (TC).<\/p>\n

    Telemetry<\/h3>\n

    \nIn simple terms, these are the data that the ground station receives from the spacecraft (KA). All transmitted information is divided into small fragments of fixed length \u2013 frames \u2013 that contain the transmitted data and control fields. Let's take a closer look at the structure of a frame:<\/p>\n

    \"A
    \n
    \nAnd let's begin our examination with the main header of the telemetry frame. I will allow myself to translate the standards in some places, providing some explanations along the way.<\/p>\n

    \"A
    \n
    \nThe Master Channel ID field must contain the frame version number and the device identifier.<\/p>\n

    Each spacecraft, according to CCSDS standards, must have its unique identifier, which allows determining the belonging spacecraft based on the frame. Formally, it is necessary to apply for the registration of the spacecraft, and its name, along with the identifier, will be published in open sources. However, Russian manufacturers often ignore this procedure, assigning arbitrary identifiers to the spacecraft. The frame version number helps identify which version of the standards is used to correctly read the frame. Here we will consider only the most conservative standard with version '0'.<\/i><\/p>\n

    The virtual channel identifier (Virtual Channel ID) field must contain the VCID of the channel from which the packet was received. There are no restrictions on selecting the VCID; in particular, virtual channels do not have to be numbered sequentially.<\/p>\n

    There is often a need to multiplex transmitted data. For this purpose, there is a mechanism of virtual channels. For example, the Meteor-M2 satellite transmits a color image in the visible range by dividing it into three black-and-white images\u2014each color is transmitted in its virtual channel as a separate packet, although there is some deviation from the standards in the structure of its frames.<\/i><\/p>\n

    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 are used to maintain feedback during the control of frame delivery. We will talk about them a little later.<\/p>\n

    The frame counters for the main and virtual channels are fields that are incremented by one with each frame sent. They serve as an indicator that no frame has been lost.<\/i><\/p>\n

    The status of the telemetry frame data consists of two more bytes of flags and data, of which we will only discuss some.<\/p>\n

    \"A
    \n
    \nThe additional header flag field (Secondary Header) should indicate the presence or absence of an additional (Secondary Header) in the telemetry frame.<\/p>\n

    If desired, you can add an additional header to each frame and place any data of your choice there.<\/i><\/p>\n

    The First Header Pointer field, when the synchronization flag is set to \"1\", must 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 starts at 0 and is counted upwards from the beginning of the data field. If there is no start of the packet in the data field of the telemetry frame, then the first header pointer field should have a value in binary representation of \"11111111111\" (this may happen if one long packet spans more than one frame). <\/p>\n

    If the data field contains an Idle Data packet, the first header pointer should have a value in binary representation of \"11111111110\". The receiver should use this field to synchronize the stream. This field ensures the restoration of synchronization even in the event of frame dropouts.<\/p>\n

    This means that a packet might, for example, start in the middle of the 4th frame and end at the beginning of the 20th. The purpose of this field is to find its start. Packets also have a header that specifies their length, so when the first header pointer is found, the link layer processor must read it, thereby determining where the packet ends.<\/i>
    \nIf the error control field is present, it must be included in every telemetry frame for a specific physical channel throughout the mission.<\/p>\n

    This field is calculated using the CRC method. The procedure must take the last 16 bits of the telemetry frame and insert the computed result into the last 16 bits.<\/p>\n

    Telecommands<\/h4>\n

    \nThe telecommand frame has several significant differences. Among them:<\/p>\n

      \n
    1. A different header structure<\/li>\n
    2. Dynamic length. This means that the length of the frame is not fixed, as is done in telemetry, but can change depending on the packets being transmitted.<\/li>\n
    3. A mechanism for ensuring the delivery of packets. This means that the spacecraft must acknowledge the receipt of frames correctly, or request a resending from the frame that might have been received with an uncorrectable error.<\/li>\n<\/ol>\n

      \n\"A
      \n
      \n\"A
      \n
      \nMany fields are already familiar to us from the telemetry frame header. They serve the same purpose, so here we will only discuss the new fields.<\/p>\n

      One bit of the bypass flag should be used to control frame verification at the receiver. A value of '0' for this flag should indicate that this frame is of type A and its verification should be conducted according to FARM. A value of '1' for this flag should inform the receiver that this frame is of type B and should bypass verification according to FARM.<\/p>\n

      This flag informs the receiver whether to use the frame delivery acknowledgment mechanism called FARM \u2014 Frame Acceptance and Reporting Mechanism.<\/i><\/p>\n

      The control command flag should be used to determine whether the data field carries a command or data. If the flag is '0', the data field should contain data. If the flag is '1', the data field should contain control information for FARM.
      \nFARM is a finite state machine whose parameters can be configured.<\/i><\/p>\n

      RSVD. SPARE \u2013 reserved bits.<\/p>\n

      It seems that CCSDS has plans for them in the future, and they have reserved these bits in the current versions of the standard for backward compatibility of protocol versions.<\/i><\/p>\n

      The frame length field should contain a number in binary representation that equals the frame length in octets minus one.<\/p>\n

      The data field of the frame should follow the header without gaps and contain a whole number of octets, with a maximum length of 1019 octets. This field should contain either a block of frame data or control command information. The block of frame data must contain:<\/p>\n