USLP transmission frame data transmission method and system
By performing frame synchronization, legality check, multiplexing, format delimiting and error control processing in the USLP transmission frame data transmission method, general resolution and frame grouping processing of transmitted frames is realized, and transmission of frame data in the prior art is solved The problem of the inability to decouple transmission services from spatial link types and application data types reduces costs and improves the efficiency of data processing in spatial networks.
Patent Information
- Application Number
- CN202411301029.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-09-18
- Publication Date
- 2025-01-10
AI Technical Summary
The existing USLP transmission frame data transmission service cannot be decoupled from the spatial link type and application data type, resulting in the transmission frame data transmission service that needs to be customized and developed, which is costly and poorly versatile, and cannot meet the generalization and integration of spatial network links. Requirements for intensive development.
Provide a USLP transmission frame data transmission method, including processing steps after receiving transmission frame data from a spatial link and processing steps for transmitting application data sets before sending transmission frames to a spatial link, through frame synchronization processing and frame legality check , frame multiplexing processing, frame format structure delimiting processing, frame error control processing and frame application data identification delimiting processing to realize the general resolution of transmitted frames and frame grouping processing.
The transmission frame structure format is realized, the transmission frame processing flow and spatial link type are decoupled, and the different data unit format types carried by the transmission frame application data domain are decoupled, reducing the development and implementation costs and improving the space Network data processing and interaction efficiency.
Smart Images

Figure CN119299530A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of space data network technology, and in particular to a USLP transmission frame data transmission method and system. Background Art
[0002] Since the 1980s, CCSDS has developed a series of space communication protocols, which have become the de facto standard for space link data transmission of spacecraft at home and abroad. Based on transmission services and application scenarios, the data link protocol sublayer has successively developed four standard protocols: TM space data link protocol, TC space data link protocol, AOS space data link protocol, and Proximity-1 space link protocol-data link layer.
[0003] However, with the rapid increase in the number of spacecraft in orbit, the complexity of operation and the increase in data interaction, traditional space data link protocols have the following problems:
[0004] 1) The functions of the transmission frame protocol format are limited, and the telemetry and remote control transmission frame formats are inconsistent.
[0005] 2) High-speed spatial transmission requires a longer maximum transmission frame length to accommodate longer user data units, reduce user data unit segmentation and reconstruction processing, and improve frame processing efficiency at both the sending and receiving ends.
[0006] 3) High-speed spatial transmission requires more frame count bits to improve the ability to identify transmission frames.
[0007] 4) Based on the space data link protocol independently developed by the service, the space link communication between different data services also requires additional costs.
[0008] In order to unify the data link protocol sublayer standards, CCSDS released the Unified Space Data Link Protocol (USLP) CCSDS 732.1-B-2, which introduced a new transmission frame format. This format not only uses the functions verified by space missions in the existing data link protocol sublayer standards, but also provides additional options to meet mission customization requirements. USLP can efficiently transmit telemetry and telecontrol data through satellite-to-ground and intersatellite bidirectional space links, and can also be used for payload data transmission.
[0009] USLP provides a flexible transmission frame structure. The main header and data domain header have sufficient fields and scalability to support the transmission of various space application data. It can unify the satellite-to-ground and inter-satellite data link layer protocols and transmission frame processing, and reduce the development and testing of end-to-end links in complex space networks. Based on the unified data link layer protocol, the data link layer protocols of different satellite-to-ground and inter-satellite transmission services can be generalized to achieve compatibility across link transmission protocol stacks and minimize adaptation overhead.
[0010] After searching and analyzing the prior art, it was found that the unified space data link protocol USLP has some problems: it has limitations in research results. For example, some patents do not involve USLP link layer processing methods, some do not involve USLP data format processing and application data bearer service processing methods, and some do not involve USLP frame processing. In terms of transmission service mode, the existing transmission frame data transmission service has the following defects:
[0011] 1) Existing transmission frame data transmission services cannot be decoupled from space link types. Different data link protocols are often used for customized processing in response to actual telemetry, remote control, and payload remote sensing data transmission requirements, resulting in the need for customized development of transmission frame data transmission services for different space links.
[0012] 2) Existing transmission frame data transmission services cannot be decoupled from the type of application data they carry. They are usually customized for application data encapsulation protocol types, with poor versatility, resulting in high development and implementation costs.
[0013] In summary, under the development trend of universalization, integration and intensification of space network links, a new USLP transmission frame data transmission method and system is urgently needed to improve the above technical problems. Summary of the invention
[0014] In view of the defects in the prior art, the purpose of the present invention is to provide a USLP transmission frame data transmission method and system, which can realize universal deframing and framing processing of transmission frames, optimize the transmission method mode, enhance versatility, reduce costs, and meet the development needs of universalization, integration, and intensiveness of space network links.
[0015] A USLP transmission frame data transmission method provided according to the present invention comprises: a processing step after receiving transmission frame data from a space link and a processing step of an application data group transmission frame before sending a transmission frame to a space link;
[0016] The processing steps after receiving the transmission frame data from the space link are: frame synchronization processing, frame legality check, frame multiplexing processing, frame format structure delimitation processing, frame error control processing and frame application data identification and delimitation processing;
[0017] The processing steps of the application data transmission frame before sending the transmission frame to the space link are: framing application data field, framing leading header, framing error control and framing synchronization.
[0018] Preferably, in the processing steps after receiving the transmission frame data from the space link:
[0019] Frame synchronization processing, retrieving a frame synchronization header with a predefined fixed byte length and a fixed feature code in the data bit stream to achieve frame synchronization of continuous transmission frames or burst transmission frames;
[0020] Frame legitimacy check: Check the compliance of the transmission frame version number, spacecraft identifier, source or destination identifier field in the transmission frame header;
[0021] Frame multiplexing processing, identifying the virtual channel identifier and multiplex access identifier fields in the main header of the transmission frame, and realizing channel sharing of different application data in the space link;
[0022] Frame format structure delimitation processing, processing the frame header end flag, frame length, virtual channel frame count length, and virtual channel frame count field in the transmission frame header to determine the frame header format and transmission frame boundary;
[0023] Frame error control processing, which detects errors that may be introduced into the transmission frame during space transmission based on the transmission frame error control field;
[0024] Frame application data identification and delimitation processing identifies and delimits the data units carried by the transmission frame application data field according to the construction rules in the transmission frame data field header, the transmission frame protocol identifier, and the first header / last valid byte pointer field.
[0025] Preferably, in the processing step of the application data group transmission frame before sending the transmission frame to the space link:
[0026] Framing application data fields, grouping the data to be transmitted into USLP data fields according to the format data unit or byte stream type to be transmitted, the transmission frame length management parameters and the construction rules;
[0027] Frame the leading header and add the fields of the leading header according to the format field requirements and management parameters of the USLP frame leading header;
[0028] Framing error control, cyclic redundancy check calculation for USLP frame header and data field;
[0029] Frame synchronization: add a frame synchronization header before the USLP transmission frame.
[0030] Preferably, the processing step after receiving the transmission frame data from the space link includes the following sub-steps:
[0031] R1, frame synchronization processing, if the same as the predefined fixed byte length and fixed feature code is detected in the bit stream, it means that the frame synchronization is successful, and then enter step R2; otherwise, continue to step R1;
[0032] R2, frame legitimacy check, includes the following sub-steps:
[0033] R2.1, check the transmission frame version number field. If the transmission frame version number is the binary code 1100, proceed to step R2.2, otherwise return to step R1;
[0034] R2.2, determine the source or destination identifier field. If the source or destination identifier is binary code 1, it means that the spacecraft identifier field indicates the destination spacecraft, and proceed to step R2.3; if the source or destination identifier is binary code 0, it means that the spacecraft identifier field indicates the source spacecraft, and proceed to step R3;
[0035] R2.3, check the spacecraft identifier field. The spacecraft identifier on the same main channel of the spacecraft is a predefined fixed setting. If the spacecraft identifier is a fixed byte length and a fixed feature code predefined for this spacecraft, proceed to step R3. Otherwise, it indicates that the transmission frame is not processed by this spacecraft, and returns to step R1.
[0036] R3, frame multiplexing processing, includes the following sub-steps:
[0037] R3.1, identify the virtual channel identifier field, predefine a set of feature codes according to the spacecraft space link application data transmission and processing requirements, each feature code represents a type of application data transmission and processing requirements, and enter step R3.2 after the virtual channel identifier field is identified; if the virtual channel identifier in the transmission frame is not in the predefined feature code, return to step R1;
[0038] R3.2, perform multiplex access identifier field identification, predefine a set of feature codes according to the different device access requirements of the same virtual channel of the spacecraft for characterization, each feature code represents a type of virtual channel access requirement, and enter step R4 after multiplex access identifier field identification; if the multiplex access identifier in the transmission frame is not in the predefined feature code, return to step R1;
[0039] R4, frame format structure delimitation processing, including the following sub-steps:
[0040] R4.1, judge the end flag field of the frame leading header. If the end flag of the frame leading header is binary code 1, it means that the transmission frame leading header is truncated. The transmission frame length is obtained according to the truncated frame length management parameter corresponding to the virtual channel, and the process goes to step R5; if the end flag of the frame leading header is binary code 0, it means that the transmission frame leading header is not truncated. The transmission frame length is obtained according to the frame length field of the frame leading header, and the process goes to step R4.2;
[0041] R4.2, perform virtual channel frame count length field judgment, determine the byte length of the virtual channel frame count field according to the virtual channel frame count length field, determine the complete frame leading header format and byte length, and enter step R5;
[0042] R5, frame error control processing, according to the frame error control field, a cyclic redundancy check is performed on the transmission frame. If the check result is correct, the process proceeds to step R6; if the check result is wrong, indicating that there is a data error in the transmission frame, the process returns to step R1;
[0043] R6, frame application data identification and delimitation processing, including the following sub-steps:
[0044] R6.1, judge the transmission frame data field construction rule field. If the transmission frame data field construction rule is binary code 000, it means that the transmission frame length on the virtual channel is fixed, and the application data carries the formatted data unit with data unit delimiting capability and variable length of whole bytes as specified by CCSDS, and enters step R6.2; if the transmission frame data field construction rule is binary code 001 or 010, it means that the transmission frame length on the virtual channel is fixed, and the application data carries the privately defined formatted data unit with variable length of whole bytes, and enters step R6.2; if the transmission frame data field construction rule is binary code 011, it means that the transmission frame length on the virtual channel is fixed, and the application data carries the privately defined formatted data unit with variable length of whole bytes, and enters step R6.2; The transmission frame length is variable, and the application data carries an integer-byte data stream, and the processing is finished; if the transmission frame data field construction rule is binary code 100, 101 or 110, it means that the transmission frame length on the virtual channel is variable, and the application data carries a privately defined formatted data unit with an integer-byte variable length or a formatted data unit specified by CCSDS, then enter step R6.2; if the transmission frame data field construction rule is binary code 111, it means that the transmission frame length on the virtual channel is variable, and the application data carries a privately defined formatted data unit with an integer-byte variable length or a formatted data unit specified by CCSDS, then enter step R6.2;
[0045] R6.2, perform transmission frame protocol identifier judgment, predefine a set of feature codes according to the privately defined formatted data unit or CCSDS formatted data unit carried by the application data field for characterization, each feature code represents a type of privately defined format or CCSDS formatted data unit encapsulation protocol; after identifying the data unit encapsulation protocol of the application data field according to the transmission frame protocol identifier, if the transmission frame data field construction rule is binary code 000, then enter step R6.3; if the transmission frame data field construction rule is binary code 001 or 010, then enter step R6.4; if the transmission frame data field construction rule is binary code 100, 101 or 110, then enter step R6.5; if the transmission frame data field construction rule is binary code 111, then enter step R6.6;
[0046] R6.3, delimit the formatted data unit. The byte length of the data unit itself is determined by the encapsulation protocol of the formatted data unit. The first byte position of the first encapsulation protocol data unit in the transmission frame is pointed to by the transmission frame header / last valid byte pointer field. Delimitation between data units is achieved when one or more data units are transmitted across frames. The processing ends.
[0047] R6.4, delimit the formatted data unit. The data field construction rule of the transmission frame is binary code 001, indicating that the formatted data unit starts at the first byte of the data field of the transmission frame, and the first header / last valid byte pointer field of the transmission frame points to the last byte position of the formatted data unit. If the transmission frame cannot completely contain the formatted data unit, the first header / last valid byte pointer is set to binary code all 1, and the remaining data will continue to be parsed in the next transmission frame, and the data field construction rule of the transmission frame is set to binary code 010, and the processing is completed.
[0048] R6.5, format the data unit delimiter, the transmission frame data field construction rule is binary code 100, indicating that the data unit starts at the first byte of the transmission frame data field; if the transmission frame cannot completely contain the data unit, the remaining data will continue to be transmitted in the next transmission frame, and the next transmission frame can completely contain the remaining data, then the data field construction rule of the transmission frame is binary code 110, and the next transmission frame cannot completely contain the remaining data, then the data field construction rule of the transmission frame is binary code 101; processing ends;
[0049] R6.6, delimits the formatted data unit. The byte length of the data unit itself is determined by the encapsulation protocol of the formatted data unit. The application data field of the transmission frame contains one or more complete data units. The data unit starts at the first byte of the data field of the transmission frame, and the processing is completed.
[0050] Preferably, the step of processing the application data group transmission frame before sending the transmission frame to the space link comprises the following sub-steps:
[0051] S1, framing the application data field, includes the following sub-steps:
[0052] S1.1, determine the transmission frame length, and determine whether the transmission frame length is fixed or variable according to the transmission frame length management parameter corresponding to the virtual channel. If the transmission frame length is fixed, the transmission frame length is determined by the management parameter; if the transmission frame length is variable, the transmission frame length is determined by the length of the data unit carried by the application data field; proceed to step S1.2;
[0053] S1.2, determine the type of format data unit or byte stream to be transmitted, and predefine a set of feature codes according to the privately defined formatted data unit or CCSDS formatted data unit carried by the application data field for characterization, each feature code represents a type of privately defined format or CCSDS formatted data unit encapsulation protocol; if the data unit to be transmitted is a privately defined formatted data unit, a CCSDS formatted data unit or a whole byte data stream, add the corresponding transmission frame protocol identifier field; if the transmission frame length is fixed, go to step S1.3, if the transmission frame length is variable, go to step S1.4;
[0054] S1.3, construct the application data of the fixed-length transmission frame. If the application data carries the CCSDS formatted data unit, the transmission frame header / last valid byte pointer field points to the first byte position of the first encapsulation protocol data unit in the transmission frame, and the transmission frame data field construction rule is binary code 000, supporting one or more data units to be transmitted across frames; if the application data carries the privately defined formatted data unit, the transmission frame header / last valid byte pointer field points to the last byte position of the formatted data unit, and the transmission frame data field construction rule is binary code 001. If the transmission frame cannot completely contain the formatted data unit, the header / last valid byte pointer is set to binary code all 1, and the remaining data will continue to be transmitted in the next transmission frame, and the transmission frame data field construction rule will be set to binary code 010; enter step S2;
[0055] S1.4, construct application data of variable-length transmission frame, the transmission frame header / last valid byte pointer field is a fixed fill code or deleted; if the application data carries a whole-byte data stream, the transmission frame data field construction rule is binary code 011; if the application data carries a privately defined formatted data unit or a CCSDS formatted data unit and needs to be transmitted in segments, the data unit starts at the first byte of the transmission frame data field, and the transmission frame data field construction rule is binary code 100. If the transmission frame cannot completely contain the data unit, the remaining data will continue to be transmitted in the next transmission frame, and the next transmission frame can completely contain the remaining data, then the data field construction rule of the transmission frame will be set to binary code 110. If the next transmission frame cannot completely contain the remaining data, then the data field construction rule of the transmission frame will be set to binary code 101; if the application data carries a privately defined formatted data unit or a CCSDS formatted data unit and does not need to be transmitted in segments, the data unit starts at the first byte of the transmission frame data field, and the transmission frame data field construction rule is binary code 111, supporting non-cross-frame transmission of one or more complete data units; enter step S2;
[0056] S2, framing leading header, includes the following sub-steps:
[0057] S2.1, adding a frame multiplexing field, adding a multiplexing access identifier field according to different access devices of the virtual channel, and adding a virtual channel identifier field according to different virtual channel transmission requirements of the space link; proceeding to step S2.2;
[0058] S2.2, adding a frame format structure delimiter field, determining whether to truncate based on the frame leading header truncation management parameter corresponding to the virtual channel, if truncated, adding a binary code 1 to the frame leading header end flag; if not truncated, adding a binary code 0 to the frame leading header end flag, adding a virtual channel frame count length field based on the virtual channel frame count length management parameter corresponding to the virtual channel, determining the byte length of the virtual channel frame count field based on the virtual channel frame count length field, and sequentially counting by adding 1 to the virtual channel frame count of each transmission frame; proceeding to step S2.3 for processing;
[0059] S2.3, add the frame legitimacy field, determine the source or destination identifier field according to the transmission frame data source or destination management parameter corresponding to the virtual channel; if the spacecraft identifier field indicates the destination spacecraft, add binary code 1 to the source or destination identifier field, add the spacecraft identifier of the destination end of the transmission frame to the spacecraft identifier field, and add binary code 1100 to the transmission frame version number field; if the spacecraft identifier field indicates the source spacecraft, add binary code 0 to the source or destination identifier field, add the spacecraft identifier of the source end of the transmission frame to the spacecraft identifier field, and add binary code 1100 to the transmission frame version number field; enter step S3;
[0060] S3, framing error control, adding a frame error control field, performing a cyclic redundancy check on the transmission frame, and adding the check result to the frame error control field; proceeding to step S4;
[0061] S4, framing synchronization, frame synchronization header field addition, adding a predefined fixed byte length and fixed feature code before the transmission frame header.
[0062] Preferably, the formatted data unit specified by CCSDS supports spatial data packet and encapsulated data packet protocols;
[0063] For spatial data packets, the packet data field length field in the packet leader header implements the delimitation between data units;
[0064] For encapsulated data packet protocols, the packet length field in the encapsulation header is used to delimit data units.
[0065] Preferably, when the construction rule of the transmission frame data field is binary code 111, and the application data field is a privately defined formatted data unit, the privately defined encapsulation protocol has the delimitation capability between data units.
[0066] Preferably, in the processing steps after receiving transmission frame data from the space link and the processing steps of the application data group transmission frame before sending the transmission frame to the space link, the same set of predefined feature codes are used to characterize the privately defined formatted data unit or CCSDS formatted data unit carried by the application data field.
[0067] Preferably, for any virtual channel, the formatted data unit or byte stream type to be transmitted is any one of a privately defined formatted data unit, a CCSDS formatted data unit, and an entire byte data stream.
[0068] The present invention also provides a USLP transmission frame data transmission system, comprising:
[0069] Receiving processing module: used for frame synchronization processing, frame legitimacy check, frame multiplexing processing, frame format structure delimitation processing, frame error control processing and frame application data identification and delimitation processing;
[0070] Send processing module: used for framing application data field, framing leading header, framing error control and framing synchronization.
[0071] Compared with the prior art, the present invention has the following beneficial effects:
[0072] 1. The USLP transmission frame data transmission method disclosed in the present invention can unify the satellite-to-ground and inter-satellite data link layer protocols, decouple from space link types such as measurement and control, relay, and data transmission, and realize the universalization of the transmission frame structure format.
[0073] 2. The USLP transmission frame data transmission method disclosed in the present invention can unify the transmission frame deframing and framing processing flow, decouple from the spatial data types such as telemetry, remote control, and remote sensing, and realize the generalization of the transmission frame processing flow.
[0074] 3. The USLP transmission frame data transmission method disclosed in the present invention can unify the transmission requirements of different data unit format types carried by the transmission frame application data field, decouple from application data such as spatial data packets, encapsulated data packets, custom formats, byte streams, etc., and realize the generalization of transmission frame data carrying. BRIEF DESCRIPTION OF THE DRAWINGS
[0075] Other features, objects and advantages of the present invention will become more apparent from the detailed description of non-limiting embodiments made with reference to the following drawings:
[0076] Figure 1 It is a schematic diagram of the data processing process of the USLP transmission frame data transmission method in an embodiment of the present invention;
[0077] Figure 2 Schematic diagram of the USLP transmission frame data structure in an embodiment of the present invention;
[0078] Figure 3 Schematic diagram of the format of the USLP transmission frame dominant header in an embodiment of the present invention;
[0079] Figure 4 Schematic diagram of the data structure of the USLP transmission frame data field header in an embodiment of the present invention;
[0080] Figure 5 Schematic diagram of the USLP transmission frame data receiving process in an embodiment of the present invention;
[0081] Figure 6 Schematic diagram of USLP transmission frame application data identification and delimitation processing in an embodiment of the present invention;
[0082] Figure 7 The figure is a schematic diagram of the frame transmission process of the application data group USLP in an embodiment of the present invention. DETAILED DESCRIPTION
[0083] The present invention supports the bidirectional de-framing and framing processing between the space network data link layer transmission frame bit stream and the privately defined formatted data unit, CCSDS formatted data unit, and whole byte data stream carried in the frame application data field. By adopting the USLP protocol, the universalization of the transmission frame structure format, processing flow and data carrying is realized, and the processing and interaction efficiency of space network data is improved.
[0084] The present invention is described in detail below in conjunction with specific embodiments. The following embodiments will help those skilled in the art to further understand the present invention, but are not intended to limit the present invention in any form. It should be noted that, for those of ordinary skill in the art, several changes and improvements can also be made without departing from the concept of the present invention. These all belong to the protection scope of the present invention.
[0085] Embodiment 1:
[0086] Figure 1 It is a schematic diagram of the data processing process of the USLP transmission frame data transmission method in an embodiment of the present invention.
[0087] like Figure 1 As shown, this embodiment provides a USLP transmission frame data transmission method, including a processing step after receiving the transmission frame data from the space link and a processing step of the application data group transmission frame before sending the transmission frame to the space link.
[0088] The processing steps after receiving the transmission frame data from the space link are: frame synchronization processing, frame legitimacy check, frame multiplexing processing, frame format structure delimitation processing, frame error control processing and frame application data identification delimitation processing. Specifically:
[0089] Frame synchronization processing, retrieving a frame synchronization header with a predefined fixed byte length and a fixed feature code in the data bit stream to achieve frame synchronization of continuous transmission frames or burst transmission frames.
[0090] Frame validity check: Check the compliance of the transmission frame version number, spacecraft identifier, source or destination identifier field in the transmission frame header.
[0091] Frame multiplexing processing identifies the virtual channel identifier and multiplex access identifier fields in the main header of the transmission frame to achieve channel sharing of different application data in the space link.
[0092] The frame format structure is delimited by processing the frame header end flag, frame length, virtual channel frame count length, and virtual channel frame count field in the transmission frame header to determine the frame header format and transmission frame boundary.
[0093] Frame error control processing detects errors that may be introduced during spatial transmission of the transmission frame based on the transmission frame error control field.
[0094] Frame application data identification and delimitation processing identifies and delimits the data units carried by the transmission frame application data field according to the construction rules in the transmission frame data field header, the transmission frame protocol identifier, and the first header / last valid byte pointer field.
[0095] Figure 2Schematic diagram of the USLP transmission frame data structure in an embodiment of the present invention.
[0096] like Figure 2 As shown in the figure, in response to the communication requirements of different data types in different space links, USLP has designed a flexible frame structure with a total of 5 fields, which are arranged in order:
[0097] (1) Transmission frame header: 4-14 bytes, carries protocol control information, required field.
[0098] (2) Transmission frame insertion field: integer bytes, optional field.
[0099] (3) Transmission frame data field: integer bytes, carrying service data unit, required field.
[0100] (4) Operation Control Field: 4 bytes, provides a reporting mechanism for the retransmission mechanism and security protocol, optional field.
[0101] (5) Frame error control field: 2 bytes, provides data detection mechanism, optional field.
[0102] The transmission frame insertion field and the operation control field are optional fields for specific data transmission requirements, and are not specifically discussed in the present invention.
[0103] Figure 3 Schematic diagram of the USLP transmission frame dominant header format in an embodiment of the present invention.
[0104] like Figure 3 As shown in FIG. 1 , a complete USLP transmission frame header consists of 13 fields, including a transmission frame version number, a spacecraft identifier, a source or destination identifier, a virtual channel identifier, a multiplex access identifier, a frame header end flag, a frame length, a bypass / sequence control flag, a protocol control command flag, a reserved bit, an operation control field flag, a virtual channel frame count length, and a virtual channel frame count.
[0105] The transmission frame data field consists of a transmission frame data field header and an application data field.
[0106] Figure 4 Schematic diagram of the data structure of the USLP transmission frame data field header in an embodiment of the present invention.
[0107] like Figure 4 As shown in the figure, the header of the data field of the transmission frame indicates the service type, format specification, and delimitation rules of the application data carried. It consists of three fields, including the construction rules of the data field of the transmission frame, the protocol identifier of the transmission frame, and the first header / last valid byte pointer. The application data field can carry three types of application data, including:
[0108] (1) Multiplexed access data packet: variable length, delimited, byte-aligned formatted data unit.
[0109] (2) Multiplexed Access Service Data Unit: A variable-length, byte-aligned data unit with a privately defined data format and unlimited data length, delimited by a data field header.
[0110] (3) Multiplexed access to byte stream: variable length, byte-aligned, continuous byte string, privately defined data format.
[0111] In addition to the transport frame protocol format, the USLP uses related management parameters designed for each channel and data transmission. Management parameters are parameters that tend to be static over a period of time, and their changes usually mean a major reconfiguration of the protocol entities related to a specific task.
[0112] The data link layer is built on the bit stream transmission of the physical layer. The spacecraft receives and sends transmission frames through space links such as satellite-to-ground and inter-satellite.
[0113] Figure 5 The figure is a schematic diagram of a USLP transmission frame data receiving process in an embodiment of the present invention.
[0114] like Figure 5 As shown, the processing steps after receiving the transmission frame data from the space link include the following sub-steps:
[0115] R1, frame synchronization processing, if the same as the predefined fixed byte length and fixed feature code is detected in the bit stream, it means that the frame synchronization is successful, and then enter step R2; otherwise, continue to step R1.
[0116] R2, frame legitimacy check, includes the following sub-steps:
[0117] R2.1, check the transmission frame version number field. If the transmission frame version number is the binary code 1100, go to step R2.2, otherwise return to step R1.
[0118] R2.2, judge the source or destination identifier field. If the source or destination identifier is binary code 1, it means that the spacecraft identifier field represents the destination spacecraft, and enter step R2.3; if the source or destination identifier is binary code 0, it means that the spacecraft identifier field represents the source spacecraft, and enter step R3.
[0119] R2.3, check the spacecraft identifier field. The spacecraft identifier on the same main channel of the spacecraft is a predefined fixed setting. If the spacecraft identifier is a fixed byte length and a fixed feature code predefined for this spacecraft, go to step R3. Otherwise, it means that the transmission frame is not processed by this spacecraft, and return to step R1.
[0120] R3, frame multiplexing processing, adopts a two-level multiplexing mechanism of virtual channel and multiplexed access. The upper layer service data unit uses different multiplexing services to share the physical channel. The virtual channel multiplexing service provides different types of data transmission methods by the virtual channel identifier. The multiplexed access service provides service data units from different sources to multiplex virtual channels by the multiplexed access identifier. Specifically, it includes the following sub-steps:
[0121] R3.1, identify the virtual channel identifier field, and predefine a set of feature codes to characterize the data transmission and processing requirements of the spacecraft space link application. Each feature code represents a type of application data transmission and processing requirements. For example, real-time telemetry, delayed telemetry, and remote sensing data can be distinguished by different virtual channels; after identifying and judging the virtual channel identifier field, enter step R3.2; if the virtual channel identifier in the transmission frame is not in the predefined feature code, return to step R1.
[0122] R3.2, identify the multiplexed access identifier field, predefine a set of feature codes to characterize the different device access requirements of the same virtual channel of the spacecraft, each feature code represents a type of virtual channel access requirement. For example, multiple onboard computers can provide telemetry transmission frame access services, and different onboard computers are distinguished by the multiplexed access identifier; after identifying and judging the multiplexed access identifier field, enter step R4; if the multiplexed access identifier in the transmission frame is not in the predefined feature code, return to step R1.
[0123] R4, frame format structure delimitation processing, on the one hand, the 13 fields of the USLP frame header provide rich frame information, on the other hand, for differentiated requirements such as short frame fast transmission, long frame segmented transmission, high-rate frame counting and positioning, it provides configurable options for the header structure. In order to meet the universal processing under differentiated requirements, it specifically includes the following sub-steps:
[0124] R4.1, judge the frame dominant header end flag field. If the frame dominant header end flag is binary code 1, it means that the transmission frame dominant header is truncated. It is generally used to transmit shorter remote control commands. For a given virtual channel, the length of the truncated transmission frame is also fixed. The transmission frame length is obtained according to the truncated frame length management parameter corresponding to the virtual channel, and enter step R5; if the frame dominant header end flag is binary code 0, it means that the transmission frame dominant header is not truncated. The transmission frame length is obtained according to the frame length field of the frame dominant header, and enter step R4.2.
[0125] R4.2, perform the virtual channel frame count length field judgment, the virtual channel frame count length field defines the byte length of the virtual channel frame count field, and maintains an independent virtual channel frame count length field according to the virtual channel, as shown in Table 1. According to the virtual channel frame count length field, determine the byte length of the virtual channel frame count field, determine the complete frame leading header format and byte length, and enter step R5.
[0126] Table 1 Description of virtual channel frame count length
[0127] Virtual channel frame count length Length of the Virtual Channel Frame Count field Maximum virtual channel frame count 000 0 NA 001 1 byte 255 010 2 bytes 65,536 011 3 bytes 16,777,215 100 4 bytes 4,294,967,295 101 5 bytes 1,099,511,627,775 110 6 bytes 281,474,976,710,655 111 7 bytes 7.20575940379279E16
[0128] R5, frame error control processing, according to the frame error control field, perform cyclic redundancy CRC check on the transmission frame. If the check result is correct, go to step R6; if the check result is wrong, indicating that there is a data error in the transmission frame, return to step R1.
[0129] R6, frame application data identification and delimitation processing identifies the types and delimitations of the three types of application data carried.
[0130] Figure 6 The figure is a schematic diagram of the identification and delimitation processing of application data of the USLP transmission frame in the embodiment of the present invention.
[0131] like Figure 6 As shown, step R6 specifically includes the following sub-steps:
[0132] R6.1, perform transmission frame data field construction rule field judgment, identify whether the transmission frame length on the virtual channel is fixed or variable, and determine the type of data carried by the application data field. Specifically, if the transmission frame data field construction rule is binary code 000, it means that the transmission frame length on the virtual channel is fixed, and the application data carries the formatted data unit with data unit delimiting capability and variable length of whole bytes as specified by CCSDS, and then go to step R6.2; if the transmission frame data field construction rule is binary code 001 or 010, it means that the transmission frame length on the virtual channel is fixed, and the application data carries the privately defined formatted data unit with variable length of whole bytes, and then go to step R6.2; if the transmission frame data field construction rule is binary code 011, it means that the transmission frame length on the virtual channel is variable, and then go to step R6.2. The data carries a whole-byte data stream and the processing is completed; if the transmission frame data field construction rule is binary code 100, 101 or 110, it means that the transmission frame length on the virtual channel is variable, and the application data carries a privately defined formatted data unit with a variable length of an integer byte or a formatted data unit specified by CCSDS, then enter step R6.2; if the transmission frame data field construction rule is binary code 111, it means that the transmission frame length on the virtual channel is variable, and the application data carries a privately defined formatted data unit with a variable length of an integer byte or a formatted data unit specified by CCSDS, then enter step R6.2.
[0133] R6.2, determine the transmission frame protocol identifier, and predefine a set of feature codes to characterize the privately defined formatted data unit or CCSDS formatted data unit carried by the application data field, each feature code represents a type of privately defined format or CCSDS formatted data unit encapsulation protocol; after identifying the data unit encapsulation protocol of the application data field according to the transmission frame protocol identifier, if the transmission frame data field construction rule is binary code 000, enter step R6.3; if the transmission frame data field construction rule is binary code 001 or 010, enter step R6.4; if the transmission frame data field construction rule is binary code 100, 101 or 110, enter step R6.5; if the transmission frame data field construction rule is binary code 111, enter step R6.6.
[0134] R6.3, perform formatted data unit delimitation, the byte length of the data unit itself is determined by the encapsulation protocol of the formatted data unit, the transmission frame leader / last valid byte pointer field is used as the leader pointer processing, the transmission frame leader / last valid byte pointer field points to the position of the first byte of the first encapsulation protocol data unit in the transmission frame in the application data field, the delimitation capability of the formatted data unit itself and the position pointing capability of the leader pointer are combined to achieve delimitation between data units when one or more data units are transmitted across frames, and the processing is completed.
[0135] R6.4, delimit the formatted data unit, the transmission frame data field construction rule is binary code 001, indicating that the formatted data unit starts at the first byte of the transmission frame data field, and the transmission frame header / last valid byte pointer field points to the last byte position of the formatted data unit; if the transmission frame cannot completely contain the formatted data unit, the header / last valid byte pointer is set to binary code all 1, and the remaining data of the data unit will continue to be parsed in the next transmission frame, and the data field construction rule of the transmission frame is set to binary code 010 to indicate the continuation under segmented transmission, and the processing is completed.
[0136] R6.5, format the data unit delimiter, the transmission frame data field construction rule is binary code 100, indicating the starting part of the segmented transmission, the data unit starts at the first byte of the transmission frame data field; if the transmission frame cannot completely contain the data unit, the remaining data will continue to be transmitted in the next transmission frame, and the next transmission frame can completely contain the remaining data, then the data field construction rule of the transmission frame is binary code 110, indicating the end of the segmented transmission, the next transmission frame cannot completely contain the remaining data, then the data field construction rule of the transmission frame is binary code 101; indicating the continuation of the segmented transmission; processing is completed.
[0137] R6.6, delimits the formatted data unit. The byte length of the data unit itself is determined by the encapsulation protocol of the formatted data unit. The application data field of the transmission frame contains one or more complete data units. The data unit starts at the first byte of the data field of the transmission frame, and the processing is completed.
[0138] The formatted data unit specified by CCSDS supports the space data packet and encapsulation data packet protocols, has the data unit delimitation capability and is variable in length. For space data packets, the packet data field length field in the packet header is used to delimit data units; for encapsulation data packet protocols, the packet length field in the encapsulation header is used to delimit data units.
[0139] When the transmission frame data field construction rule is binary code 111, if the application data field is a privately defined formatted data unit, and the transmission frame application data field contains multiple complete data units, in order to achieve delimitation between data units, the privately defined encapsulation protocol should have the ability to delimit between data units.
[0140] The processing steps of the application data transmission frame before sending the transmission frame to the space link are: framing application data field, framing leading header, framing error control and framing synchronization. Specifically:
[0141] The framing application data field groups the data to be transmitted into the USLP data field according to the format data unit or byte stream type to be transmitted, the transmission frame length management parameters and the construction rules.
[0142] The framing leading header is assembled, and each field of the leading header is added according to the format field requirements and management parameters of the USLP frame leading header.
[0143] Framing error control, cyclic redundancy check calculation on the USLP frame header and data field.
[0144] Frame synchronization: add a frame synchronization header before the USLP transmission frame.
[0145] Figure 7 The figure is a schematic diagram of the frame transmission process of the application data group USLP in an embodiment of the present invention.
[0146] like Figure 7 As shown in FIG. 1 , the processing steps of the application data group transmission frame before sending the transmission frame to the space link are opposite to the processing steps after receiving the transmission frame data from the space link. There are similarities and differences, and specifically include the following steps:
[0147] S1, framing application data field.
[0148] Step S1 includes the following sub-steps:
[0149] S1.1, determine the transmission frame length, and determine whether the transmission frame length is fixed or variable based on the transmission frame length management parameter corresponding to the virtual channel. If the transmission frame length is fixed, the transmission frame length is determined by the management parameter; if the transmission frame length is variable, the transmission frame length is determined by the length of the data unit carried by the application data field; proceed to step S1.2.
[0150] S1.2, determine the type of format data unit or byte stream to be transmitted, and predefine a set of feature codes to characterize the privately defined formatted data unit or CCSDS formatted data unit carried by the application data field, each feature code represents a type of privately defined format or CCSDS formatted data unit encapsulation protocol; the data unit to be transmitted is a privately defined formatted data unit, a CCSDS formatted data unit or a whole-byte data stream, and add the corresponding transmission frame protocol identifier field; for any virtual channel, the type of format data unit or byte stream to be transmitted is determined, and can be any type of data among privately defined formatted data units, CCSDS formatted data units, and whole-byte data streams; if the transmission frame length is fixed, go to step S1.3, if the transmission frame length is variable, go to step S1.4.
[0151] S1.3, construct application data of a fixed-length transmission frame. If the application data carries a CCSDS formatted data unit, the transmission frame header / last valid byte pointer field points to the first byte position of the first encapsulation protocol data unit in the transmission frame, and the transmission frame data field construction rule is binary code 000, supporting one or more data units to be transmitted across frames; if the application data carries a privately defined formatted data unit, the transmission frame header / last valid byte pointer field points to the last byte position of the formatted data unit, and the transmission frame data field construction rule is binary code 001. If the transmission frame cannot completely contain the formatted data unit, the header / last valid byte pointer is set to binary code all 1, and the remaining data will continue to be transmitted in the next transmission frame, and the transmission frame data field construction rule will be set to binary code 010; proceed to step S2.
[0152] S1.4, construct application data of a variable-length transmission frame, and the transmission frame header / last valid byte pointer field is a fixed fill code or deleted; if the application data carries a whole-byte data stream, the transmission frame data field construction rule is binary code 011; if the application data carries a privately defined formatted data unit or a CCSDS formatted data unit and needs to be transmitted in segments, the data unit starts at the first byte of the transmission frame data field, and the transmission frame data field construction rule is binary code 100. If the transmission frame cannot completely contain the data unit, the remaining data will continue to be transmitted in the next transmission frame, and the next transmission frame can completely contain the remaining data, then the data field construction rule of the transmission frame will be set to binary code 110, and if the next transmission frame cannot completely contain the remaining data, then the data field construction rule of the transmission frame will be set to binary code 101; if the application data carries a privately defined formatted data unit or a CCSDS formatted data unit and does not need to be transmitted in segments, the data unit starts at the first byte of the transmission frame data field, and the transmission frame data field construction rule is binary code 111, supporting non-cross-frame transmission of one or more complete data units; enter step S2.
[0153] S2, framing leading header, includes the following sub-steps:
[0154] S2.1, frame multiplexing field addition, add multiplexing access identifier field according to different access devices of virtual channels, for example, input access data streams from multiple onboard computers are distinguished by different multiplexing access identifiers. Add virtual channel identifier field according to different virtual channel transmission requirements of space links; for example, virtual channels leading to measurement and control, distribution, and data transmission channels are different; go to step S2.2.
[0155] S2.2, add the frame format structure delimiter field, determine whether to truncate based on the frame main header truncation management parameter corresponding to the virtual channel, if truncation is done, add binary code 1 to the frame main header end flag; if not truncated, add binary code 0 to the frame main header end flag, add the virtual channel frame count length field based on the virtual channel frame count length management parameter corresponding to the virtual channel, for a given virtual channel, the value of the virtual channel frame count length is fixed; determine the byte length of the virtual channel frame count field based on the virtual channel frame count length field, and count sequentially by adding 1 to the virtual channel frame count for each transmission frame; proceed to step S2.3 for processing.
[0156] S2.3, add the frame validity field, and determine the source or destination identifier field according to the transmission frame data source or destination management parameters corresponding to the virtual channel; if the spacecraft identifier field represents the destination spacecraft, add binary code 1 to the source or destination identifier field, and add the spacecraft identifier of the destination end of the transmission frame to the spacecraft identifier field. For example, the remote control transmission frame in satellite-to-ground transmission usually adds the spacecraft identifier of the data destination end to the spacecraft identifier field; if the spacecraft identifier field represents the source spacecraft, add binary code 0 to the source or destination identifier field, and add the spacecraft identifier of the source end of the transmission frame to the spacecraft identifier field. For example, the telemetry transmission frame in satellite-to-ground transmission usually adds the spacecraft identifier of the data source end to the spacecraft identifier field; add binary code 1100 to the transmission frame version number field; proceed to step S3.
[0157] S3, framing error control, adding a frame error control domain field, performing a cyclic redundancy CRC check on the transmission frame, and adding the check result to the frame error control domain field; proceed to step S4.
[0158] S4, framing synchronization, frame synchronization header field addition, adding a predefined fixed byte length and fixed feature code before the transmission frame header.
[0159] In the processing steps after receiving the transmission frame data from the space link and the processing steps of the application data group transmission frame before sending the transmission frame to the space link, the same set of predefined feature codes are used to represent the privately defined formatted data unit or CCSDS formatted data unit carried by the application data field.
[0160] For any virtual channel, the format data unit or byte stream type to be transmitted is any one of a privately defined format data unit, a CCSDS format data unit, and an entire byte data stream.
[0161] Embodiment 2:
[0162] An embodiment of the present invention provides a USLP transmission frame data transmission system, including:
[0163] Receiving processing module: used for frame synchronization processing, frame legality check, frame multiplexing processing, frame format structure delimitation processing, frame error control processing and frame application data identification and delimitation processing.
[0164] Send processing module: used for framing application data field, framing leading header, framing error control and framing synchronization.
[0165] Those skilled in the art know that, in addition to realizing the system and its various devices, modules, and units provided by the present invention in a purely computer-readable program code, it is entirely possible to realize the same functions in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers by logically programming the method steps. Therefore, the system and its various devices, modules, and units provided by the present invention can be considered as a hardware component, and the devices, modules, and units included therein for realizing various functions can also be regarded as structures within the hardware component; the devices, modules, and units for realizing various functions can also be regarded as both software modules for realizing the method and structures within the hardware component.
[0166] The above describes the specific embodiments of the present invention. It should be understood that the present invention is not limited to the above specific embodiments, and those skilled in the art can make various changes or modifications within the scope of the claims, which does not affect the essence of the present invention. In the absence of conflict, the embodiments of the present application and the features in the embodiments can be combined with each other arbitrarily.
Claims
1. A method for transmitting USLP transmission frame data, characterized in that: include: The processing step after receiving the transmission frame data from the space link and the processing step of the application data group transmission frame before sending the transmission frame to the space link; The processing steps after receiving the transmission frame data from the space link are: frame synchronization processing, frame legality check, frame multiplexing processing, frame format structure delimitation processing, frame error control processing and frame application data identification delimitation processing; The processing steps of the application data group transmission frame before sending the transmission frame to the space link are: framing application data field, framing leading header, framing error control and framing synchronization.
2. The USLP transmission frame data transmission method according to claim 1, characterized in that: In the processing steps after receiving the transmission frame data from the space link: The frame synchronization processing retrieves a frame synchronization header having a predefined fixed byte length and a fixed feature code in the data bit stream to achieve frame synchronization of a continuous transmission frame or a burst transmission frame; The frame legitimacy check performs a compliance check on the transmission frame version number, spacecraft identifier, source or destination identifier field in the transmission frame leading header; The frame multiplexing process identifies the virtual channel identifier and multiplex access identifier fields in the transmission frame master header to achieve channel sharing of different application data in the space link; The frame format structure delimitation process is to process the frame leading header end flag, frame length, virtual channel frame count length, and virtual channel frame count field in the transmission frame leading header to determine the frame leading header format and the transmission frame boundary; The frame error control processing detects errors that may be introduced into the transmission frame during spatial transmission according to the transmission frame error control field; The frame application data identification and delimitation processing identifies and delimits the data units carried by the transmission frame application data field according to the construction rules in the transmission frame data field header, the transmission frame protocol identifier, and the first header / last valid byte pointer field.
3. The USLP transmission frame data transmission method according to claim 1, characterized in that: In the processing step of the application data group transmission frame before sending the transmission frame to the space link: The framing application data field groups the data to be transmitted into a USLP data field according to the format data unit or byte stream type to be transmitted, the transmission frame length management parameter and the construction rule; The framing leading header adds various fields of the leading header according to the USLP frame leading header format field requirements and management parameters; The framing error control performs cyclic redundancy check calculation on the USLP frame leading header and data field; The frame synchronization is performed by adding a frame synchronization header before the USLP transmission frame.
4. The USLP transmission frame data transmission method according to claim 2, characterized in that: The processing step after receiving the transmission frame data from the space link includes the following sub-steps: R1, frame synchronization processing, if the same as the predefined fixed byte length and fixed feature code is detected in the bit stream, it means that the frame synchronization is successful, and then enter step R2; otherwise, continue to step R1; R2, frame legitimacy check, includes the following sub-steps: R2.1, check the transmission frame version number field. If the transmission frame version number is the binary code 1100, proceed to step R2.2, otherwise return to step R1; R2.2, determine the source or destination identifier field. If the source or destination identifier is binary code 1, it means that the spacecraft identifier field indicates the destination spacecraft, and proceed to step R2.3; if the source or destination identifier is binary code 0, it means that the spacecraft identifier field indicates the source spacecraft, and proceed to step R3; R2.3, check the spacecraft identifier field. The spacecraft identifier on the same main channel of the spacecraft is a predefined fixed setting. If the spacecraft identifier is a fixed byte length and a fixed feature code predefined for this spacecraft, proceed to step R3. Otherwise, it indicates that the transmission frame is not processed by this spacecraft, and returns to step R1. R3, frame multiplexing processing, includes the following sub-steps: R3.1, identify the virtual channel identifier field, predefine a set of feature codes according to the spacecraft space link application data transmission and processing requirements, each feature code represents a type of application data transmission and processing requirements, and enter step R3.2 after the virtual channel identifier field is identified; if the virtual channel identifier in the transmission frame is not in the predefined feature code, return to step R1; R3.2, perform multiplex access identifier field identification, predefine a set of feature codes according to the different device access requirements of the same virtual channel of the spacecraft for characterization, each feature code represents a type of virtual channel access requirement, and enter step R4 after multiplex access identifier field identification; if the multiplex access identifier in the transmission frame is not in the predefined feature code, return to step R1; R4, frame format structure delimitation processing, including the following sub-steps: R4.1, judge the end flag field of the frame leading header. If the end flag of the frame leading header is binary code 1, it means that the transmission frame leading header is truncated. The transmission frame length is obtained according to the truncated frame length management parameter corresponding to the virtual channel, and the process goes to step R5; if the end flag of the frame leading header is binary code 0, it means that the transmission frame leading header is not truncated. The transmission frame length is obtained according to the frame length field of the frame leading header, and the process goes to step R4.2; R4.2, perform virtual channel frame count length field judgment, determine the byte length of the virtual channel frame count field according to the virtual channel frame count length field, determine the complete frame leading header format and byte length, and enter step R5; R5, frame error control processing, according to the frame error control field, a cyclic redundancy check is performed on the transmission frame. If the check result is correct, the process proceeds to step R6; if the check result is wrong, indicating that there is a data error in the transmission frame, the process returns to step R1; R6, frame application data identification and delimitation processing, including the following sub-steps: R6.1, judge the transmission frame data field construction rule field. If the transmission frame data field construction rule is binary code 000, it means that the transmission frame length on the virtual channel is fixed, and the application data carries the formatted data unit with data unit delimiting capability and variable length of whole bytes as specified by CCSDS, and enters step R6.2; if the transmission frame data field construction rule is binary code 001 or 010, it means that the transmission frame length on the virtual channel is fixed, and the application data carries the privately defined formatted data unit with variable length of whole bytes, and enters step R6.2; if the transmission frame data field construction rule is binary code 011, it means that the transmission frame length on the virtual channel is fixed, and the application data carries the privately defined formatted data unit with variable length of whole bytes, and enters step R6.2; The transmission frame length is variable, and the application data carries an integer-byte data stream, and the processing is finished; if the transmission frame data field construction rule is binary code 100, 101 or 110, it means that the transmission frame length on the virtual channel is variable, and the application data carries a privately defined formatted data unit with an integer-byte variable length or a formatted data unit specified by CCSDS, then enter step R6.2; if the transmission frame data field construction rule is binary code 111, it means that the transmission frame length on the virtual channel is variable, and the application data carries a privately defined formatted data unit with an integer-byte variable length or a formatted data unit specified by CCSDS, then enter step R6.2; R6.2, perform transmission frame protocol identifier judgment, predefine a set of feature codes according to the privately defined formatted data unit or CCSDS formatted data unit carried by the application data field for characterization, each feature code represents a type of privately defined format or CCSDS formatted data unit encapsulation protocol; after identifying the data unit encapsulation protocol of the application data field according to the transmission frame protocol identifier, if the transmission frame data field construction rule is binary code 000, then enter step R6.3; if the transmission frame data field construction rule is binary code 001 or 010, then enter step R6.4; if the transmission frame data field construction rule is binary code 100, 101 or 110, then enter step R6.5; if the transmission frame data field construction rule is binary code 111, then enter step R6.6; R6.3, perform formatted data unit delimitation, determine the byte length of the data unit itself by the encapsulation protocol of the formatted data unit, point the first byte position of the first encapsulation protocol data unit in the transmission frame by the transmission frame header / last valid byte pointer field, and implement delimitation between data units when one or more data units are transmitted across frames, and the processing ends; R6.4, delimit the formatted data unit, the transmission frame data field construction rule is binary code 001, indicating that the formatted data unit starts at the first byte of the transmission frame data field, and the transmission frame header / last valid byte pointer field points to the last byte position of the formatted data unit; if the transmission frame cannot completely contain the formatted data unit, the header / last valid byte pointer is set to binary code all 1, the remaining data will continue to be parsed in the next transmission frame, and the data field construction rule of the transmission frame is set to binary code 010, and the processing is completed; R6.5, format the data unit delimiter, the transmission frame data field construction rule is binary code 100, indicating that the data unit starts at the first byte of the transmission frame data field; if the transmission frame cannot completely contain the data unit, the remaining data will continue to be transmitted in the next transmission frame, and the next transmission frame can completely contain the remaining data, then the data field construction rule of the transmission frame is binary code 110, and the next transmission frame cannot completely contain the remaining data, then the data field construction rule of the transmission frame is binary code 101; processing ends; R6.6, format the data unit delimiter, the byte length of the data unit itself is determined by the encapsulation protocol of the formatted data unit, the transmission frame application data field contains one or more complete data units, the data unit starts at the first byte of the transmission frame data field, and the processing is completed.
5. The USLP transmission frame data transmission method according to claim 3, characterized in that: The step of processing the application data group transmission frame before sending the transmission frame to the space link includes the following sub-steps: S1, framing the application data field, includes the following sub-steps: S1.1, determine the transmission frame length, and determine whether the transmission frame length is fixed or variable according to the transmission frame length management parameter corresponding to the virtual channel. If the transmission frame length is fixed, the transmission frame length is determined by the management parameter; if the transmission frame length is variable, the transmission frame length is determined by the length of the data unit carried by the application data field; proceed to step S1.2; S1.2, determining the type of format data unit or byte stream to be transmitted, and predefining a set of characteristic codes for characterization according to the privately defined format data unit or CCSDS format data unit carried by the application data field, each characteristic code representing a type of privately defined format or CCSDS format data unit encapsulation protocol; If the data unit to be transmitted is a privately defined formatted data unit, a CCSDS formatted data unit or a whole byte data stream, add the corresponding transmission frame protocol identifier field; if the transmission frame length is fixed, proceed to step S1.3; if the transmission frame length is variable, proceed to step S1.4; S1.3, construct application data of a fixed-length transmission frame. If the application data carries a CCSDS formatted data unit, the transmission frame header / last valid byte pointer field points to the first byte position of the first encapsulation protocol data unit in the transmission frame, and the transmission frame data field construction rule is binary code 000, supporting cross-frame transmission of one or more data units; if the application data carries a privately defined formatted data unit, the transmission frame header / last valid byte pointer field points to the last byte position of the formatted data unit, and the transmission frame data field construction rule is binary code 001. If the transmission frame cannot completely contain the formatted data unit, the header / last valid byte pointer is set to binary code all 1, and the remaining data will continue to be transmitted in the next transmission frame, and the data field construction rule of the transmission frame will be set to binary code 010; Go to step S2; S1.4, construct application data of variable-length transmission frame, the transmission frame header / last valid byte pointer field is a fixed fill code or deleted; if the application data carries a whole-byte data stream, the transmission frame data field construction rule is binary code 011; if the application data carries a privately defined formatted data unit or a CCSDS formatted data unit and needs to be transmitted in segments, the data unit starts at the first byte of the data field of the transmission frame, and the transmission frame data field construction rule is binary code 100. If the transmission frame cannot completely contain the data unit, the remaining data will continue to be transmitted in the next transmission frame, and the next transmission frame can completely contain the remaining data, then the data field construction rule of the transmission frame will be set to binary code 110, and if the next transmission frame cannot completely contain the remaining data, then the data field construction rule of the transmission frame will be set to binary code 101; if the application data carries a privately defined formatted data unit or a CCSDS formatted data unit and does not need to be transmitted in segments, the data unit starts at the first byte of the data field of the transmission frame, and the transmission frame data field construction rule is binary code 111, supporting non-cross-frame transmission of one or more complete data units; enter step S2; S2, framing leading header, includes the following sub-steps: S2.1, frame multiplexing field is added, multiplexing access identifier field is added according to different access devices of virtual channels, and virtual channel identifier field is added according to different virtual channel transmission requirements of space links; Go to step S2.2 for processing; S2.2, the frame format structure delimiter field is added, and whether to truncate is determined according to the frame leading header truncation management parameter corresponding to the virtual channel. If truncation is performed, the frame leading header end flag is added with binary code 1; If it is not truncated, the frame leading header end mark is added with binary code 0, and the virtual channel frame count length field is added according to the virtual channel frame count length management parameter corresponding to the virtual channel, and the byte length of the virtual channel frame count field is determined according to the virtual channel frame count length field, and the virtual channel frame count of each transmission frame is counted by 1 sequentially; and the process goes to step S2.3; S2.3, frame legitimacy field is added, and the source or destination identifier field is determined according to the transmission frame data source or destination management parameter corresponding to the virtual channel; If the spacecraft identifier field indicates the destination spacecraft, a binary code 1 is added to the source or destination identifier field, the spacecraft identifier field is added with the spacecraft identifier of the destination end of the transmission frame, and a binary code 1100 is added to the transmission frame version number field; if the spacecraft identifier field indicates the source spacecraft, a binary code 0 is added to the source or destination identifier field, the spacecraft identifier field is added with the spacecraft identifier of the source end of the transmission frame, and a binary code 1100 is added to the transmission frame version number field; proceed to step S3; S3, framing error control, adding a frame error control field, performing a cyclic redundancy check on the transmission frame, and adding the check result to the frame error control field; proceeding to step S4; S4, framing synchronization, frame synchronization header field addition, adding a predefined fixed byte length and fixed feature code before the transmission frame header.
6. The USLP transmission frame data transmission method according to claim 4, characterized in that: The formatted data unit specified by CCSDS supports the spatial data packet and encapsulated data packet protocols; For the spatial data packet, the packet data field length field in the packet leader header realizes the delimitation between data units; For the encapsulated data packet protocol, the packet length field in the encapsulated packet header implements delimitation between data units.
7. The USLP transmission frame data transmission method according to claim 4, characterized in that: When the construction rule of the transmission frame data field is the binary code 111, and the application data field is a privately defined formatted data unit, the privately defined encapsulation protocol has the delimitation capability between data units.
8. The USLP transmission frame data transmission method according to claim 1, characterized in that: In the processing steps after receiving the transmission frame data from the space link and the processing steps of the application data group transmission frame before sending the transmission frame to the space link, the same set of predefined feature codes are used to represent the privately defined formatted data unit or CCSDS formatted data unit carried by the application data field.
9. The USLP transmission frame data transmission method according to claim 5, characterized in that: For any virtual channel, the format data unit or byte stream type to be transmitted is any one of a privately defined format data unit, a CCSDS format data unit, and an entire byte data stream.
10. A USLP transmission frame data transmission system, characterized in that: include: Receiving processing module: used for frame synchronization processing, frame legitimacy check, frame multiplexing processing, frame format structure delimitation processing, frame error control processing and frame application data identification and delimitation processing; Send processing module: used for framing application data field, framing leading header, framing error control and framing synchronization.