CAUTION - This text file is provided for the sole purpose of allowing text-string searching. It is NOT a faithful reproduction of the published document: figures, equations, special characters, and character attributes used to convey information are not reproduced in this text file; tables, which may be reproduced as text, may have lost crucial row or column alignment. A Portable Document Format (PDF) version of this document is available in the main document listing. The PDF file contains all elements of the document as published by the CCSDS. The PDF file should be used in all cases where there is a need for faithful reproduction of the information contained in the published document. CONSULTATIVE COMMITTEE FOR SPACE DATA SYSTEMS RECOMMENDATION FOR SPACE DATA SYSTEM STANDARDS +-----------------------------------+ | | | TELECOMMAND | | | | PART 2 | | DATA ROUTING SERVICE | | | +-----------------------------------+ CCSDS 202.0-B-2 BLUE BOOK NOVEMBER 1992 AUTHORITY ******************************************* * Issue: Blue Book, Issue 2 * * Date: November 1992 * * Location: CCSDS Meeting * * November 1992 * * Greenbelt, MD, USA * ******************************************* This Recommendation reflects the consensus technical agreement of the following member Agencies of the Consultative Committee for Space Data Systems (CCSDS): o British National Space Centre (BNSC)/United Kingdom. o Canadian Space Agency (CSA)/Canada. o Central Research Institute of Machine Building (TsNIIMash)/ Russian Federation. o Centre National D'Etudes Spatiales (CNES)/France. o Deutsche Forschungsanstalt fŸr Luft- und Raumfahrt e.V.(DLR)/Germany. o European Space Agency (ESA)/Europe. o Instituto de Pesquisas Espaciais (INPE)/Brazil. o National Aeronautics and Space Administration (NASA)/USA. o National Space Development Agency of Japan (NASDA)/Japan. The following observer Agencies also concur with this Recommendation: o Chinese Academy of Space Technology (CAST)/People's Republic of China. o Central Research Institute of Physics (CRIP)/Hungary. o Department of Communications, Communications Research Centre (DOC- CRC)/Canada. o Institute of Space and Astronautical Science (ISAS)/Japan. This Recommendation is published and maintained by: CCSDS Secretariat Program Integration Division (Code-OI) National Aeronautics and Space Administration Washington, DC 20546, USA STATEMENT OF INTENT The Consultative Committee for Space Data Systems (CCSDS) is an organization officially established by the management of member space Agencies. The Committee meets periodically to address data systems problems that are common to all participants, and to formulate sound technical solutions to these problems. Inasmuch as participation in the CCSDS is completely voluntary, the results of Committee actions are termed RECOMMENDATIONS and are not considered binding on any Agency. This RECOMMENDATION is issued by, and represents the consensus of, the CCSDS Plenary body. Agency endorsement of this RECOMMENDATION is entirely voluntary. Endorsement, however, indicates the following understandings: o Whenever an Agency establishes a CCSDS-related STANDARD, this STANDARD will be in accord with the relevant RECOMMENDATION. Establishing such a STANDARD does not preclude other provisions which an Agency may develop. o Whenever an Agency establishes a CCSDS-related STANDARD, the Agency will provide other CCSDS member Agencies with the following information: - The STANDARD itself. - The anticipated date of initial operational capability. - The anticipated duration of operational service. o Specific service arrangements shall be made via memoranda of agreement. Neither this RECOMMENDATION nor any ensuing STANDARD is a substitute for a memorandum of agreement. No later than five years from its date of issuance, this Recommendation will be reviewed by the CCSDS to determine whether it should: (1) remain in effect without change; (2) be changed to reflect the impact of new technologies, new requirements, or new directions; or (3) be retired or canceled In those instances when a new version of a RECOMMENDATION is issued, existing CCSDS-related Agency standards and implementations are not negated or deemed to be non-CCSDS compatible. It is the responsibility of each Agency to determine when such standards or implementations are to be modified. Each Agency is, however, strongly encouraged to direct planning for its new standards and implementations towards the later version of the Recommendation. FOREWORD This document, which is a technical Recommendation prepared by the Consultative Committee for Space Data Systems (CCSDS), is intended for use by participating space Agencies in their development of space telecommand systems. This Recommendation allows the implementing organizations within each Agency to proceed coherently with the development of compatible Standards for the flight and ground systems that are within their cognizance. Agency Standards derived from this Recommendation may implement only a subset of the optional features allowed herein, or may incorporate features not addressed by the Recommendation. In order to establish a common framework within which the Agencies may develop standardized telecommand services, the CCSDS advocates adoption of a layered systems architecture. Within this approach, specific layers of service (including their operational protocol and data structuring techniques) may be selected for implementation according to mission requirements. The current layered set of CCSDS telecommand Recommendations was developed to match the conventional free-flying mission environment, as characterized by the transmission of command data at relatively low uplink data rates to spacecraft of moderate complexity. Advanced Orbiting Systems (AOS), which are characterized by a more complex mission environment, including the transmission of multiple data types at very high data rates to space vehicles which include extensive onboard data networking capability, may choose to use the AOS protocols and data structures defined in Reference [8] for both uplink and downlink or they may use the telecommand data structures and protocols defined here for uplink. This Recommendation for Telecommand Data Routing Service was developed within the layered architectural framework, and embraces the standard data structures and data communication procedures which may be used by conventional missions within the intermediate telecommand system layers. Through the process of normal evolution, it is expected that expansion, deletion or modification to this document may occur. This Recommendation is therefore subject to CCSDS document management and change control procedures which are defined in Reference [1]. DOCUMENT CONTROL Document Title Date Status and Substantive Changes CCSDS Recommendation for Space January Original Issue 202.0-B-1 Data System Standards. 1987 Telecommand, Part 2 Data Routing Service, Issue 1 CCSDS Recommendation for Space November Supersedes Issue 1 202.0-B-2 Data System Standards 1992 Removal of COP-0 & COP-2 Telecommand, Part 2 Data Longer Frame length Routing Service, Issue 2 Multiple Packets per Frame Single Virtual Channel not required to have Identifier set to "all zeros" Use of AOS downlink Full definition of Frame Error Control algorithm Removal of mandatory performance requirements Correction of error in maximum Packet length specification (B-2.1(1)(a)) Segment layer not optional (Segment Header is still optional) Consistency with part 2.1 (Reference [7]) NOTE: Substantive changes from the previous issue are flagged with change bars in the margin. CONTENTS Sections Page REFERENCES vii 1 INTRODUCTION 1-1 1.1 PURPOSE AND SCOPE 1-1 1.2 APPLICABILITY 1-1 1.3 BIT NUMBERING CONVENTION AND NOMENCLATURE 1-2 2 TELECOMMAND DATA ROUTING SERVICE OVERVIEW 2-1 3 SEGMENTATION LAYER: STANDARD DATA STRUCTURES AND PROCEDURES 3-1 3.1 OVERVIEW OF THE LAYER 3-1 3.2 STANDARD DATA STRUCTURES WITHIN THE LAYER 3-2 3.2.1 Frame Data Unit 3-2 3.2.2 Telecommand Segment 3-2 3.3 STANDARD PROCEDURES WITHIN THE LAYER 3-4 3.3.1 Sending End Procedures 3-4 3.3.2 Receiving End Procedures 3-6 4 TRANSFER LAYER: STANDARD DATA STRUCTURES AND PROCEDURES 4-1 4.1 OVERVIEW OF THE LAYER 4-1 4.2 STANDARD DATA STRUCTURES WITHIN THE LAYER 4-1 4.2.1 TC Transfer Frame Format 4-3 4.2.2 Command Link Control Word Format 4-9 4.3 STANDARD PROCEDURES WITHIN THE LAYER 4-14 4.3.1 Frame Delimiting and Fill Removal Procedure 4-14 4.3.2 Frame Validation Check Procedure 4-15 4.3.3 Command Operation Procedure 4-16 Annexes A DATA ROUTING SERVICE ACRONYMS AND TERMINOLOGY A-1 B DATA ROUTING SERVICE SPECIFICATION B-1 Figures 2-1 Telecommand System 2-2 3-1 Orientation of the Segmentation Layer 3-2 3-2 Telecommand Segment Format 3-3 3-3 Example of the Segmentation Procedure 3-6 4-1 Orientation of the Transfer Layer 4-2 4-2 TC Transfer Frame Format 4-3 4-3 Command Link Control Word Format 4-10 B-1 TC Data Routing Service Elements B-3 Tables 4-1 Interpretation of the "Bypass" and "Control Command" Flags 4-5 REFERENCES [1] "Procedures Manual for the Consultative Committee for Space Data Systems", CCSDS A00.0-Y-5, Issue 5. Yellow Book, Consultative Committee for Space Data Systems, May 1992 or later issue. [2] "Telecommand, Summary of Concept and Service", CCSDS 200.0-G-6, Issue 6, Green Book, Consultative Committee for Space Data Systems, January 1987 or later issue. [3] "Telecommand, Part 3: Data Management Service, Architectural Definition", Recommendation CCSDS 203.0-B-1, Issue 1, Blue Book, Consultative Committee for Space Data Systems, January 1987 or later issue. [4] "Telecommand, Part 1: Channel Service, Architectural Specification", Recommendation CCSDS 201.0-B-1, Issue 1, Blue Book, Consultative Committee for Space Data Systems, January 1987 or later issue. [5] "Packet Telemetry", Recommendation CCSDS 102.0-B-3, Issue 3, Blue Book, Consultative Committee for Space Data Systems, November 1992 or later issue. [6] "Telemetry Channel Coding", Recommendation CCSDS 101.0-B-3, Issue 3 Blue Book, Consultative Committee for Space Data Systems, May 1992 or later issue. [7] "Telecommand, Part 2.1: Command Operation Procedures", Recommendation CCSDS 202.1 B-1, Issue 1, Blue Book, Consultative Committee for Space Data Systems, October 1991 or later issue. [8] "Advanced Orbiting Systems: Networks and Data Links", Recommendation CCSDS 701.0-B-2, Issue 2, Blue Book, Consultative Committee for Space Data Systems, November 1992 or later issue. [9] "Advanced Orbiting Systems: Summary of Concepts, Rationale and Performance," CCSDS 700.0-G-3, Issue 3, Green Book, Consultative Committee for Space Data Systems, November 1992 or later issue. [10] "CCSDS Global Spacecraft Identification Field: Code Assignment Control Procedures, CCSDS A10.0-R-1, Issue 1, Red Book, Consultative Committee for Space Data Systems, May 1992 or later issue of Blue Book. The latest issues of CCSDS documents may be obtained from the CCSDS Secretariat at the address indicated on page i. 1 INTRODUCTION 1.1 PURPOSE AND SCOPE The purpose of this document is to establish a common Recommendation for the implementation of a spacecraft telecommand "Data Routing Service" by the Agencies participating in the Consultative Committee for Space Data Systems (CCSDS). The operating principles and procedures for the CCSDS are defined in Reference [1]. The context of the Data Routing Service within the overall Telecommand System is described in Reference [2]. This Recommendation addresses the procedures and data unit formats implemented within the Segmentation layer and the Transfer layer of the telecommand Data Routing Service. 1.2 APPLICABILITY This Recommendation serves as a guideline for the development of compatible internal Agency standards in the field of conventional spacecraft commanding. This Recommendation is not retroactive, nor does it commit any Agency to implement the recommended telecommand concepts at any future time. Nevertheless, all CCSDS Agencies accept the principle that all future implementations of telecommand which are used in cross- support situations will be based on this Recommendation. The CCSDS has developed a layered concept for conventional spacecraft telecommanding, which is summarized in Reference [2]. Standard services are defined within each layer, and Agencies will be encouraged to develop corresponding facilities to provide these services in support of Projects. To be fully compatible with the CCSDS concept, a conventional Project's telecommanding architecture should follow this Recommendation for Data Routing Service, plus the Recommendations for telecommand "Data Management Service" and telecommand "Channel Service", which are described in References [3] and [4]. Projects may also elect to be partially compatible with the concept by interfacing with the standard systems at intermediate layers within any of the service specifications. Advanced Orbiting Systems (AOS) may use the AOS data structures and protocols defined in Reference [8] for uplinking data and control information or they may use the telecommand data structures and protocols defined here and in References [3], [4] and [7] in a hybrid fashion. See Reference [9] for a discussion of hybrid support. Where preferred options or mandatory capabilities are clearly indicated herein, the indicated sections of the specification must be implemented when this Recommendation is used as a basis for cross-support. Where optional subsets or capabilities are allowed or implied in this specification, implementation of these options or subsets is subject to specific bilateral cross-support agreements between the Agencies involved. The recommendations in this document are to be invoked through the normal standards programs of each member Agency, and are applicable to those missions for which cross-support based on capabilities described in these recommendations is anticipated. 1.3 BIT NUMBERING CONVENTION AND NOMENCLATURE In this document, the following convention is used to identify each bit in an N-bit field: The first bit in the field to be transferred (i.e., the most left justified when drawing a figure) is defined to be "Bit 0"; the following bit is defined to be "Bit 1" and so on up to "Bit N-1". When the field is used to express a binary value (such as a counter), the Most Significant Bit (MSB) shall be the first bit of the field, i.e., "Bit 0". [GRAPHIC ELEMENT OMITTED] In accordance with modern data communications practice, spacecraft data fields are often grouped into 8-bit "words" which conform to the above convention. Throughout this Recommendation, the following nomenclature is used to describe this grouping: [GRAPHIC ELEMENT OMITTED] By CCSDS convention, all "spare" bits shall be permanently set to value "zero". Note that throughout this document, the word "Telecommand" may be abbreviated as "TC". 2 TELECOMMAND DATA ROUTING SERVICE OVERVIEW A complete summary of the acronyms and terminology used internal to this document is presented in Annex A. A detailed specification of the services provided by each layer is presented in Annex B. Figure 2-1 illustrates the significance of the Telecommand (TC) Data Routing Service in the overall Telecommand System, which contains three principal service elements: Telecommand Data Management Service; Telecommand Data Routing Service; and Telecommand Channel Service. Each service is documented in its own Recommendation. A more thorough discussion of the layered services, including expansion of Figure 2-1 in greater detail, is contained in Reference [2]. The Telecommand System is related to the Telemetry System as documented in Reference [5] and Reference [6]. The TC Data Routing Service enables user telecommand data units associated with higher layers to be reliably transferred to the spacecraft, drawing upon the Channel Service to perform its functions. The Data Routing Service contains two distinct layers of data handling operations: (1) A SEGMENTATION layer, which prepares the user data units for transfer by forming them into suitable-sized routable pieces and permitting these pieces to be multiplexed together for transmission through the command channel. (2) A TRANSFER layer, which encapsulates the routable pieces of user data into transfer data structures and controls their transmission through the channel, including any retransmissions needed to ensure delivery of the routable pieces in sequence without gaps or duplication. The detailed specification of the retransmission mechanism, called the Command Operation Procedure, is given in Part 2.1 of the Telecommand Recommendation (Reference [7]). The Data Routing Service provides an interface between the high-layer "user" elements of the TC System and the low-layer communications channel through which data flow. Because the underlying Channel Service inherently includes a noisy signal path, there is a finite probability that it will introduce an error. Since any error in the user's data will render them invalid, it is desirable to break large user data units into relatively small pieces (which will thus each have a lower probability of being invalidated by transmission error than if the entire user data unit were sent contiguously). This improves system throughput efficiency since only small pieces have to be retransmitted when errors are detected. However, there may also be situations in which the user data units are very small. For efficient transfer, the Data Routing Service provides the capability to group these small units into larger pieces. Analysis of the performance of the Channel Service and Data Routing Service under various conditions is contained in Reference [2]. [GRAPHIC ELEMENT OMITTED] Figure 2-1: Telecommand System NOTE A:Figure 2-1 represents a logical view of the TC System, and physical implementations may not necessarily correspond to the sequential flow of operations implied by the figure. NOTE B:This Recommendation primarily specifies the data structures and protocols flowing ACROSS the layers of the TC System, since these have a direct impact on the long lead-time design of future spacecraft hardware and software. Comprehensive definition of the associated flow of control instructions, which are required to initialize the layers and to direct the flow of TC data units BETWEEN the layers, remains an item for potential future extension of this document. NOTE C:Although the layers defined in this document may be used without necessarily implementing those defined in the Channel Service (Reference [4]) and Data Management Service (Reference [3]), the names of the layers in those Services will be used to denote the external interfaces for the Data Routing Service, when appropriate. 3 SEGMENTATION LAYER: STANDARD DATA STRUCTURES AND PROCEDURES 3.1 OVERVIEW OF THE LAYER The data unit received by the Segmentation layer from the higher layer is called a "TC User Data Unit". If the higher layer is the Packetization layer, defined in Reference [3], it will be a TC Packet; otherwise, it may be any other user-provided data unit. The data unit passed from the Segmentation layer to the Transfer layer is the "TC Frame Data Unit". It will normally consist of a TC Segment. If neither segmentation nor multiplexing is used on a particular Virtual Channel, the Segment Header may be omitted on that Virtual Channel. The TC Segmentation layer accepts variable-length TC User Data Units from the layer above and prepares them for transmission by the layers below by: (1) forming the TC User Data Units into TC Frame Data Units, which are compatible with insertion into the data field of the TC Transfer Frame. (2) enabling TC User Data Units from different sources to be multiplexed together so that they may share one Virtual Channel. To accomplish service (1), the Segmentation layer breaks large TC User Data Units into smaller TC Segments or aggregates small TC Packets into a larger TC Segment or TC Frame Data Unit. To accomplish service (2), the Segmentation layer provides "Multiplexer Access Points" (MAPs). A TC User Data Unit arriving at the input to the Segmentation layer is allocated to a MAP at the sending end of the layer and is transferred to the corresponding MAP at the receiving end of the layer using the transfer service of the layers below. The layers below may provide one "real" physical channel, or may logically divide the real channel into multiple, named "Virtual Channels" (as defined in Section 4). Each of "m" (m = 1 to 64) Virtual Channels (VCs) may have "n" (n = 1 to 64) distinct MAPs associated with it. The orientation of the Segmentation layer is shown in Figure 3-1. Section 3.2 defines the format of the protocol data unit (the TC Segment), which is implemented within the Segmentation layer. Section 3.3 describes the procedures used within the Segmentation layer. It should be noted that the Segmentation layer does not include a telemetry reporting mechanism, since it relies on closed-loop procedures performed within the Transfer layer. [GRAPHIC ELEMENT OMITTED] Figure 3-1: Orientation of the Segmentation Layer 3.2 STANDARD DATA STRUCTURES WITHIN THE LAYER 3.2.1 TC FRAME DATA UNIT The TC Frame Data Unit is the data unit transferred from the Segmentation Layer to the Transfer layer. The length of the TC Frame Data Unit may vary from one TC Frame to the next. Its length shall not exceed the maximum allowed length of the Transfer Frame Data Field. The maximum length of the TC Frame Data Unit depends on whether Frame Error Control is being used (See Section 4.2.1.3). With Frame Error Control 1017 octets Without Frame Error Control 1019 octets The maximum length allowed by a particular spacecraft or ground system implementation on a particular Virtual Channel may be shorter than the maximum specified here. The content of a TC Frame Data Unit is defined in Section 3.3.1. 3.2.2 TELECOMMAND SEGMENT The use of a TC Segment is required for any Virtual Channel which has more than one MAP or which transfers TC User Data Units which are larger than permitted in a single TC Frame. Its use is optional otherwise, except that if it is used in any TC Frame carried on a Virtual Channel, it must be used for all TC Frames on that Virtual Channel. The format of the TC Segment is shown in Figure 3-2. [GRAPHIC ELEMENT OMITTED] Figure 3-2: Telecommand Segment Format 3.2.2.1 Segment Header. The Segment Header contains the following two fields: (1) Sequence Flags (Bits 0,1) This two bit field delimits the higher layer TC User Data Unit by indicating the sequential position of the TC Segment relative to the TC User Data Unit (e.g., TC Packet) of which the TC Segment is a part. The flags are interpreted as follows: Bit 0 Bit 1 Interpretation 0 1 First Segment of TC User Data Unit on one MAP 0 0 Continuing Segment of TC User Data Unit on one MAP 1 0 Last Segment of TC User Data Unit on one MAP 1 1 No segmentation (one TC User Data Unit or multiple complete TC Packets) (2) Multiplexer Access Point (MAP) Identifier (Bits 2 through 7) The MAP facility allows user command data from different sources to be multiplexed together so that they share the communications capacity of one Virtual Channel, thus preventing any one user from monopolizing the data transmission resource. This six-bit field enables up to 64 MAP addresses (from MAP 0 to MAP 63) to be associated with each Virtual Channel provided by the Transfer layer. Different TC User Data Units (e.g., separate TC Packets) arriving at the input to the Segmentation layer are allocated to a MAP. The segmentation and aggregation processes are conducted independently for each MAP. The resulting TC Frame Data Units from up to 64 MAPs are then multiplexed onto one Virtual Channel in accordance with user's delivery priorities and instructions. Certain MAPs may have higher transmission priorities than others. There are no restrictions on the selection of MAP Identifiers. In particular, MAPs are not required to be numbered consecutively. If multiple MAPs are not used on a particular Virtual Channel, but the Segment Header is otherwise required to be present, Bits 2 through 7 shall be set to a constant value for all TC Segments which are placed on that Virtual Channel. 3.2.2.2 Segment Data Field. The Segment Data Field contains all or a portion of the higher layer TC User Data Unit (e.g., TC Packet) or an aggregation of TC Packets. The Segment Data Field length is variable with a maximum length of one octet less that the maximum length of the TC Frame Data Unit. 3.3 STANDARD PROCEDURES WITHIN THE LAYER Figure 3-3 illustrates the process of segmenting and aggregating TC User Data Units (in this example, TC Packets) and inserting them as TC Segments into TC Frame Data Units. The procedures are as follows. 3.3.1 SENDING END SEGMENTATION PROCEDURES The sending end of the Segmentation layer performs the following processing steps: (1) Allocates the TC User Data Unit to a particular Multiplexer Access Point. (2) If the TC User Data Unit (e.g., the TC Packet) exceeds a predetermined length, the Segmentation layer divides it into portions that are compatible with insertion into the TC Frame Data Unit and attaches a Segment Header to each portion, forming the TC Segment/Frame Data Unit. If the TC User Data Unit is a TC Packet, the first octet of the TC Packet Primary Header shall appear in the leading octet of the first corresponding Segment Data Field. The first and continuing Segments may each have a length equal to the maximum allowable length of the TC Frame Data Unit on that particular Virtual Channel. The last Segment shall have a length equal to the residue of the TC User Data Unit plus the Segmentation Header. (3) If aggregation is permitted on a particular MAP, the Segmentation layer places complete TC packets into the TC Segment in the order of arrival. If Segment Headers (and hence MAPs) are not used on a particular Virtual Channel, but aggregation is permitted, the Segmentation layer places the TC Packets directly into the TC Frame Data Unit. In either case, the aggregated packets (plus Segment Header, if used) must fit within the maximum size TC Frame Data Unit permitted for the Virtual Channel. The limitations on the number of MAPs which can be aggregating TC Packets simultaneously and mechanisms for ensuring transmission of all TC Packets are implementation dependent. (4) Multiplexes together the TC Frame Data Units from one group of up to 64 MAPs onto one Virtual Channel, according to the mission's priority scheme, and passes the multiplexed stream to the layer below. C A U T I O N A TC FRAME DATA UNIT SHALL CONSIST OF ONLY ONE OF THE FOLLOWING: (a) A TC SEGMENT CONTAINING A PORTION OF ONE TC USER DATA UNIT (E.G. A PORTION OF ONE TC PACKET); or (b) A TC SEGMENT CONTAINING ONE COMPLETE TC USER DATA UNIT(E.G., ONE COMPLETE TC PACKET); or (c) A TC SEGMENT CONTAINING MULTIPLE COMPLETE TC PACKETS; or (d) ONE COMPLETE TC USER DATA UNIT (E.G., ONE COMPLETE TC PACKET); or (e) MULTIPLE COMPLETE TC PACKETS. TC Packets and user-defined data units may not be intermixed. Each MAP (if Segment Headers are used) or Virtual Channel (if Segment Headers are not used) shall carry either TC Packets or user-defined data units, but not both. TC Packets with different destinations, as denoted by the Application Process Identifier in the TC Packet Header, may be carried on a single MAP or Virtual Channel and may be aggregated within a single TC Frame Data Unit. Figure 3-3 shows how TC Packets assigned to one MAP are aggregated or segmented to form TC Segments/Frame Data Units. [GRAPHIC ELEMENT OMITTED] Figure 3-3: Example of the Segmentation Procedure 3.3.2 RECEIVING END SEGMENTATION PROCEDURES The receiving end of the TC Segmentation layer performs the following processing steps: (1) Accepts a stream of multiplexed TC Segments/Frame Data Units on one Virtual Channel from the Transfer layer. (2) Sorts these Segments according to the MAP IDs which appear in their Segment Headers. (3) a. For TC Frame Data Units containing a segment of a TC User Data Unit: reassembles the Segments (less headers) for each MAP, using the Sequence Flags, in order to recreate the original TC User Data Unit. b. For all other TC Frame Data Units: extracts the TC Packets or TC User Data Unit, using the Frame and Packet Length fields. (4) Passes the resulting TC User Data Unit(s) to the layer above. 4 TRANSFER LAYER: STANDARD DATA STRUCTURES AND PROCEDURES 4.1 OVERVIEW OF THE LAYER The TC Transfer layer is the "heart" of the standard conventional TC System. It is this layer which takes care of most of the operations required to move sets of user TC data reliably from the sending end of the system to the receiving end in space. Section 4.2 defines the format of the two standard data structures that reside within the layer: the "TC Transfer Frame", which flows from the sending end of the TC System to its receiving end, and the "Command Link Control Word" (CLCW), which is formatted by the receiving end and is transmitted back to the sending end via corresponding layers within the Telemetry System. Section 4.3 defines the standard procedures which are associated with the layer: - Frame Delimiting and Fill Removal Procedure - Frame Validation Check Procedure - Command Operation Procedure (COP) A COP consists of a pair of synchronized procedures which execute within one TC Virtual Channel (VC) at the sending and receiving ends of the layer. At the sending end a "Frame Operation Procedure" (FOP) is executed. At the receiving end a corresponding spacecraft "Frame Acceptance and Reporting Mechanism" (FARM) is executed. Detail specification of the COPs are contained in Reference [7]. Only one COP is defined in this Recommendation: COP-1. The orientation of these elements within the Transfer layer is shown in Figure 4-1. 4.2 STANDARD DATA STRUCTURES WITHIN THE LAYER This section describes the formats of the following two standard protocol data units which reside within the TC Transfer layer: (1) The TC Transfer Frame, which is the data structure that is "uplinked" to the receiving end of the layer on the spacecraft. (2) The TC Command Link Control Word (CLCW), which is the data structure that is "downlinked" by the spacecraft back to the sending end of the layer in order to provide reports which describe the status of acceptance and reassembly of TC Frames. [GRAPHIC ELEMENT OMITTED] Figure 4-1: Orientation of the Transfer Layer 4.2.1 TC TRANSFER FRAME FORMAT The TC Frame (Figure 4-2) contains the following major fields: Major Field Length (Octets) FRAME HEADER 5 FRAME DATA FIELD Variable (up to 1019) FRAME ERROR CONTROL (Optional) (2) 1024 octets (maximum) The maximum TC Frame length allowed by a particular spacecraft or ground implementation on a particular Virtual Channel may be less than the maximum specified here. [GRAPHIC ELEMENT OMITTED] Figure 4-2: TC Transfer Frame Format 4.2.1.1 Transfer Frame Header. The FRAME HEADER of the TC Transfer Frame consists of the following fields, grouped into octets as shown: Field #Bits #Octets Version Number 2 Bypass Flag 1 Control Command Flag 1 Reserved Spares 2 Spacecraft ID 10 2 Virtual Channel ID 6 Frame Length 10 2 Frame Sequence Number 8 1 5 octets The first two octets of the FRAME HEADER contain the following field allocations: (1) VERSION NUMBER (Bits 0,1) The VERSION NUMBER occupies the two most significant bits of the Frame Header. Future changes in the TC Transfer Frame structure may be accommodated by changing the VERSION NUMBER. At present, only Version "1" of the TC Transfer Frame (the format specified herein) is defined. It shall be identified by setting Bits 0,1 to value "00". (2) BYPASS FLAG (Bit 2) The single-bit BYPASS FLAG controls the application of "Frame Acceptance Checks" by the receiving spacecraft. ALL Frames received by the spacecraft first undergo a basic standard set of "Frame Validation Checks", which are applied regardless of the setting of the BYPASS FLAG. The Frame Acceptance and Reporting Mechanism (FARM) associated with the COP can be made to operate in a normal "Acceptance" (frame "Type-A") mode or a "Bypass" (frame "Type-B") mode, according to the setting of the BYPASS FLAG. Setting Bit 2 to value "0" specifies a Type-A TC Frame; acceptance of this Type of frame by the spacecraft shall be subject to the normal frame acceptance checks of the FARM. Setting Bit 2 to value "1" specifies a Type-B TC Frame; the normal frame acceptance checks of the FARM shall be bypassed. Necessarily, it must be possible to send Type-A and Type-B TC Frames on the same TC Virtual Channel in order to conduct some operations. (3) CONTROL COMMAND FLAG (Bit 3) The CONTROL COMMAND FLAG specifies whether the data field of the TC Transfer Frame is conveying transfer "Control Commands" (the "C" mode), or "Data" (the "D" mode). In the "C" mode the Frame Data Field contains control information which is used to set the parameters of the FARM to the proper configuration to accept telecommand data. In the "D" mode the Frame Data Field contains a Frame Data Unit (e.g., a TC Packet or a TC Segment). Setting Bit 3 to value "0" indicates the "D" mode to the receiving spacecraft, i.e., that the Frame Data Field contains data. Setting Bit 3 to value "1" indicates the "C" mode to the receiving spacecraft, i.e., that the Frame Data Field contains Control Commands. The combined states of the BYPASS FLAG and the CONTROL COMMAND FLAG are interpreted by the receiving spacecraft as shown in Table 4-1. Table 4-1: Interpretation of the "Bypass" and "Control Command" Flags _________________________________________________________________________ Bypass Flag Control Command Flag Interpretation _________________________________________________________________________ 0 0 Type-AD. Frame Data Field carries TC data (e.g., Packets or Segments), subject to acceptance check under control of the FARM. These Frames use the Sequence-Controlled (or AD) Service of the COP. 0 1 Reserved for future application. 1 0 Type-BD. Frame Data Field carries TC data (e.g., Packets or Segments), with all frame acceptance checks bypassed under control of the FARM. These Frames use the Expedited (or BD) Service of the COP. 1 1 Type-BC. Frame Data Field carries FARM Control Commands, with all frame acceptance checks bypassed under control of the FARM. These Frames control the Sequence- Controlled Service of the COP. _________________________________________________________________________ (4) RESERVED SPARES (Bits 4,5) These two bits are reserved for future application. At present, Bits 4,5 shall be set to value "00". (5) SPACECRAFT IDENTIFIER (Bits 6 through 15) These ten bits carry the identification code for the spacecraft being commanded. The Secretariat of the CCSDS assigns the SPACECRAFT IDENTIFIER to each vehicle within a particular mission as defined in Reference [10]. The third and fourth octets of the FRAME HEADER contain the following field allocations: (6) VIRTUAL CHANNEL IDENTIFIER (Bits 16 through 21) As described in Section 3, the Transfer layer provides a "Virtual Channel" service to the Segmentation layer. Beneath the Transfer layer is the single physical telecommand data channel which is provided by the Channel Service (Reference [4]). The Virtual Channel facility allows this single physical channel to be logically multiplexed, on a frame-by-frame basis, so that its transmission capacity may be shared. Every TC Transfer Frame shall have a 6-bit VIRTUAL CHANNEL ID field present in the Frame Header. Each state of the identifier creates one Virtual Channel, from VC 0 to VC 63, so that up to 64 different logical paths may be defined through the single physical channel. The Transfer layer may therefore present up to 64 Virtual Channels to the Segmentation layer. Each Virtual Channel may also have up to 64 Multiplexer Access Points (MAPs) attached to it by the Segmentation layer for the purpose of multiplexing user data together. NOTE If multiplexing is not performed in the Segmentation layer (i.e., if only one MAP is activated per Virtual Channel) or if the Segment Header is omitted for a particular mission, then the Virtual Channel feature of the Transfer layer provides an alternative method for multiplexing user data onto the physical channel. Using this feature of the Transfer layer, up to 64 concurrent users may be multiplexed together by attaching each to its own dedicated Virtual Channel during transfer through the physical channel. However, since every open Virtual Channel has its own CLCW reporting scheme, Virtual Channel multiplexing may increase the spacecraft reporting complexity. The internal partitioning and use of the Virtual Channel field is mission-specified; e.g., some of the bits may be allocated by a mission to form a "Spacecraft Sub-ID", which allows different spacecraft data handling chains to be addressed. (7) FRAME LENGTH (Bits 22 through 31) This 10-bit field contains a length count "C" which equals one fewer than the total octets in the TC Transfer Frame. The count is measured from the first bit of the FRAME HEADER to the last bit of the FRAME ERROR CONTROL FIELD (if present), or the last bit of the FRAME DATA FIELD if the error control is omitted. The size of this field limits the maximum length of a TC Transfer Frame to 1024 octets. The length count "C" is expressed as: "C" = (Total Number of Octets) - 1 The fifth octet of the FRAME HEADER contains the following field: (8) FRAME SEQUENCE NUMBER (Bits 32 through 39) The FRAME SEQUENCE NUMBER, which within this Recommendation is denoted as N(S), is an up-counting binary number which is assigned to each TC Frame by the TC Transfer layer, and which remains a viable entity only within this layer. The FRAME SEQUENCE NUMBER enables the FARM to check the sequentiality of incoming Type-A TC Frames. The 8-bit FRAME SEQUENCE NUMBER field supports a modulo-256 sequence count. The FRAME SEQUENCE NUMBER is Virtual Channel dependent; i.e., the Transfer layer shall maintain a separate FRAME SEQUENCE NUMBER for each of the (up to 64) VIRTUAL CHANNELS. Note that the COP does not use this field when operating with Type-B TC Frames; in this case the contents of the FRAME SEQUENCE NUMBER field shall be set to "all zeros". 4.2.1.2 Transfer Frame Data Field. The FRAME DATA FIELD, which is of variable length up to a maximum of 1019 octets (1017 octets if the FRAME ERROR CONTROL FIELD is present), shall contain either an integral number of octets of telecommand data corresponding to one TC Frame Data Unit or an integral number of octets of Control Command information. The FRAME DATA FIELD shall be inserted directly after the Frame Header with no filler between. 4.2.1.2.1 TC Frame Data Unit. The TC Frame Data Unit is supplied by the Segmentation layer. The content of a TC Frame Data Unit is defined in Section 3.3.1. 4.2.1.2.2 Control Commands. There are two Control Commands defined: UNLOCK and SET V(R). The action to be taken when the FARM receives one of the Control Commands is defined in Reference [7]. All other bit combinations for Control Commands are reserved by the CCSDS for future application. UNLOCK: The UNLOCK Control Command consists of a single octet containing "all zeroes". SET V(R): The SET V(R) Control Command consists of three octets with the following values: 10000010 00000000 XXXXXXXX where XXXXXXXX is the value to which the FARM should set V(R), the Receiver_Frame_Sequence_Number. This octet should therefore be set to the Sequence Number which will be put into the Header of the next Type- A TC Frame to be transmitted on that Virtual Channel. 4.2.1.3 Transfer Frame Error Control Field. The purpose of this optional 16-bit field (which occupies the two trailing octets of the TC Frame) is to provide frame error control information. The Frame Error Control Field is used only for error detection, but it is particularly useful when project requirements dictate an undetected frame error performance that exceeds the inherent performance provided by the underlying Channel Service. Performance information is found in Annex B and Reference [2]. If used, the preferred error control technique is the Cyclic Redundancy Check (CRC) described in the following sections. 4.2.1.3.1 Encoding Procedure. The encoding procedure accepts a Transfer Frame, excluding the Frame Error Control Field, and generates a systematic binary block code by appending a 16-bit Frame Error Control Word (FECW) as the final 16 bits of the codeblock. The equation for the FECW is: FECW = [(X**16 . M(X)) + (X**(n-16) . L(X))] modulo G(X) where all arithmetic is modulo 2 M(X) = the (n-16)-bit message to be encoded expressed as a polynomial with binary coefficients L(X) = the presetting polynomial given by: [GRAPHIC ELEMENT OMITTED] (i.e., all "1" polynomial of order 15) G(X) = the generating polynomial given by: G(X) = X**16 + X**12 + X**5 + 1 n = the number of bits in the encoded message The X**(n-16) . L(X) term has the effect of presetting the shift register to an all "1" state prior to encoding. A possible implementation of an encoder is described in Reference [2]. 4.2.1.3.2 Decoding Procedure. The entire TC Frame, including the Frame Error Control field is provided to the decoder. The error detection syndrome, S(X), is given by S(X) = [(X**16 . C*(X)) + (X**n . L(X))] modulo G(X) where C*(X) = the received block in polynomial form S(X) = the syndrome polynomial, which will be zero if no error is detected and non-zero if an error is detected. A possible implementation of a decoder is contained in Reference [2]. 4.2.2 COMMAND LINK CONTROL WORD (CLCW) FORMAT The CLCW, which is a four-octet word that is conveyed in the Operational Control Field of a CCSDS Telemetry Transfer Frame (Reference [5]) or Virtual Channel Data Unit (VCDU) (Reference [8]), provides the mechanism by which the FARM reports the status of frame acceptance to the Frame Operation Procedure (FOP) at the sending end of the Transfer layer. NOTE The controlling specification for how the CLCW is used within the COP is contained in Reference [7]. The CLCW is the only reporting mechanism for the TC Transfer layer. Although it is not necessary that the Telemetry reporting rate match the Telecommand transfer rate, some minimum CLCW sampling rate is necessary for the proper operation of the COP. The format of the CLCW is shown in Figure 4-3. [GRAPHIC ELEMENT OMITTED] Figure 4-3: Command Link Control Word Format The CLCW contains the following fields: Field Length (Bits) CONTROL WORD TYPE 1 CLCW VERSION 2 STATUS FIELD 3 COP IN EFFECT 2 VIRTUAL CHANNEL ID 6 RESERVED SPARE 2 FLAGS: 5 - No rf available (1) - No bit lock (1) - Lockout (1) - Wait (1) - Retransmit (1) FARM B COUNTER 2 RESERVED SPARE 1 REPORT VALUE 8 32 bits (4 octets) Unless otherwise stated, all fields are required elements. (1) CONTROL WORD TYPE (Bit 0) This one-bit field shall be set to zero to indicate that the Operational Control Field contains a CLCW. (2) CLCW VERSION NUMBER (Bits 1,2) The two-bit CLCW VERSION NUMBER field is included to provide future growth flexibility. However, at present a single "Version-1" CLCW format is defined in this Recommendation. It shall be indicated by setting Bits 1,2 to value "00". The format of the Version-1 CLCW report is described herein. (3) STATUS FIELD (Bits 3,4,5) Application of this field is mission-specified. It may be used by Agencies or Centers for local enhancements to TC operations and is not part of the COP protocol. (4) COP IN EFFECT (Bits 6,7) These two bits indicate the COP which is being used. At present a single COP, COP-1, is defined. It shall be identified by setting Bits 6,7 to the binary value "01". (5) VIRTUAL CHANNEL ID (Bits 8-13) This field contains the VIRTUAL CHANNEL Identifier of the TC Virtual Channel with which this report is associated. Each Virtual Channel which is open shall have its own CLCW reporting activated. (6) RESERVED SPARES (Bits 14,15) These two bits are reserved by CCSDS for future application. For the present, Bits 14,15 shall be set to value "00". (7) FLAGS (Bits 16,17,18,19,20) (a) NO RF AVAILABLE flag (Bit 16) The NO RF AVAILABLE flag provides a logical indication of the "ready" status of the radio frequency (rf) elements within the physical data channel provided by the Channel Service layers. Precise definition of the set of physical states which must each be in the "ready" condition before commanding is possible is mission-specified. For example, the flag can represent a logical sum of the overall ready status of components such as the rf transponder and the demodulator. Whenever Bit 16 is set to value "0", the physical channel is AVAILABLE (i.e., any TC Transfer Frame will be received and processed by the Channel Service layers and passed on to the Transfer layer if correct). Whenever Bit 16 is set to value "1", the physical channel is NOT AVAILABLE and TC Transfer Frames cannot be transferred without corrective action within the Channel Service layers. The single NO RF AVAILABLE flag applies to all Virtual Channels. This input parameter to the CLCW is updated whenever a change is signaled by the Channel Service. (b) NO BIT LOCK flag (Bit 17) The NO BIT LOCK flag is an optional, mission-specific engineering measurement which provides a performance quality indicator that indicates specifically whether the Channel Service layers are working normally by having enough signal energy to achieve bit synchronization with the received data stream. If bit lock is not achieved, this may indicate that the Channel Service layers are operating at a non-nominal performance level and that the TC Frame rejection rate may be correspondingly abnormally high. When Bit 17 is used and set to value "0", this indicates BIT LOCK ACHIEVED. When Bit 17 is used and set to value "1", this indicates NO BIT LOCK ACHIEVED. This flag is not part of the COP protocol, and may therefore be used by Agencies or Centers for local enhancements to TC operations. If not used, it shall be set permanently to value "0". The single NO BIT LOCK flag applies to all Virtual Channels. This input parameter to the CLCW is updated whenever a change is signaled by the Channel Service. (c) LOCKOUT flag (Bit 18) Bit 18 is set to value "1" to indicate LOCKOUT whenever a Type-A TC Frame is received on a particular Virtual Channel which violates certain frame acceptance checks. Once the FARM is in LOCKOUT, all subsequent Type-A TC Frames are rejected by that FARM until the condition is cleared. The conditions for entering and exiting LOCKOUT for the COP are specified in Reference [7]. If the FARM is not in LOCKOUT, Bit 18 shall be set to value "0". Necessarily, separate LOCKOUT flags shall be maintained for each Virtual Channel. (d) WAIT flag (Bit 19) When Bit 19 is set to value "1", this indicates that the receiving end of the Transfer layer is unable to pass data to the Segmentation layer on a particular Virtual Channel. This may be caused by temporary lack of storage and/or processing resources in the receiving end of the Transfer or higher layers. When Bit 19 is set to value "1" (i.e., WAIT) for a particular Virtual Channel, all further Type-A TC Frames on that channel shall be rejected by the FARM until the condition is cleared by freeing the congestion, either automatically or by taking appropriate control action as defined in Reference [7]. When Bit 19 is set to value "0" (i.e., DON'T WAIT), normal Type-A commanding may proceed on that channel. The precise specifications for use of the WAIT Flag are contained in Reference [7]. Necessarily, separate WAIT flags shall be maintained for each Virtual Channel. (e) RETRANSMIT Flag (Bit 20) The RETRANSMIT flag speeds the operation of the COP by providing immediate indication (Bit 20 set to value "1") to the FOP at the sending end that one or more Type-A frames on a particular TC Virtual Channel have been rejected or found missing by the FARM and therefore retransmission is required. The conditions which cause the flag to be set are specified in Reference [7]. When Bit 20 is set to value "0", this indicates that there are no outstanding Type-A frame rejections in the sequence received so far, and thus retransmissions are not required. The precise specifications for use of the RETRANSMIT Flag are contained in Reference [7]. Necessarily, separate RETRANSMIT flags shall be maintained for each Virtual Channel. (8) FARM-B COUNTER (Bits 21,22) This field contains the two least significant bits of a FARM-B COUNTER. This counter is maintained within the FARM and increments once each time a Type-B TC Transfer Frame is accepted in BYPASS mode on a particular Virtual Channel. The field supports the verification that BYPASS mode frames (Control or user Data) were accepted by the spacecraft. Necessarily, separate FARM-B COUNTERs shall be maintained for each Virtual Channel. (9) RESERVED SPARE (Bit 23) This bit is reserved by CCSDS for future application. For the present, Bit 23 shall be set to value "0". (10) REPORT VALUE (Bits 24-31) This field, which shall always be one octet long, contains the value of "N(R)", i.e., the current observed value of the FARM's NEXT EXPECTED FRAME SEQUENCE NUMBER V(R). The FARM V(R) counter shall increment once each time a Type-AD TC Frame is accepted on a particular Virtual Channel. The precise specifications for use of the REPORT VALUE are contained in Reference [7]. Necessarily, separate counters shall be maintained for each Virtual Channel. 4.3 STANDARD PROCEDURES WITHIN THE LAYER Standard procedures within the Transfer layer are concerned with the following operations: (1) At the receiving end of the system, reconstituting TC Frames from the data stream provided by the Channel Service Coding layer and removing any Fill Data transferred from that layer. (2) At the receiving end of the system, performing standard "Frame Validation Checks" on all TC Frames reconstituted from the Coding layer. (3) At both ends of the system, executing the Command Operation Procedure which is used to move TC Frames across the Transfer layer, including performing frame acceptance checks and establishing and using various counters, numbers and windows. 4.3.1 FRAME DELIMITING AND FILL REMOVAL PROCEDURE The Telecommand Channel Service (Reference [4]) resides immediately below the Transfer layer. At the sending end of the TC System, the Transfer layer passes one or more TC Frames to the Channel Service Coding layer, which encodes the frames to protect them from errors which may be introduced as they are transmitted through the physical channel. Fill Data may have to be inserted by the Channel Service to ensure correct transmission of all valid data. The receiving end of the Transfer layer receives as an input from the Coding layer a series of data octets, corresponding to the decoded frame(s), which have been declared "clean" by the Coding layer insofar as they contain no detected errors. The Coding layer provides a "Data Start" signal to the Transfer layer, indicating that data are being transferred. The Data Start signal shall be set TRUE while the Coding layer is in the process of actively transferring data octets. Since the first octet transferred after Data Start goes TRUE corresponds to the first octet of the first TC Transfer Frame, the receiving end of the Transfer layer may delimit this frame-and each of any successive TC Transfer Frames-by reading the FRAME LENGTH field in the first header, and then successively reading the FRAME LENGTH field in each subsequent header. The Data Start signal shall become FALSE (indicating "Data Stop") when the Coding layer stops transferring octets because of a decoder failure or channel deactivation. Decoding failure may be caused by the normal end of the transmitted TC Frame(s), or by a genuine channel-induced error. If one or more valid FRAME LENGTH fields are detected by the receiving end of the Transfer layer and the number of octets received when the Data Stop condition occurs equals the number of octets specified by the FRAME LENGTH(s), then each Frame shall be passed on to the Frame Validation Check procedure (see 4.3.2) as it is delimited. If a valid FRAME LENGTH field is detected by the receiving end of the Transfer layer but the number of octets received when the Data Stop condition occurs is less than the number of octets specified by that FRAME LENGTH, this entire Frame shall be discarded since this indicates that a failure has occurred, possibly due to a channel error detected during reception of the data stream within the Channel Service layers below. If a valid FRAME LENGTH field is detected by the receiving end of the Transfer layer but the number of octets received when the Data Stop condition occurs is greater than the number of octets specified by that FRAME LENGTH, Fill Data was probably appended by the sending end Coding layer to complete the last TC Codeblock (Reference [4]). Because the receiving end Coding layer cannot distinguish between valid data and Fill Data, the Fill Data must be stripped by the Transfer layer. The characteristics of the present TC Codeblock structure are such that no more than six octets of Fill Data can occur. If LESS THAN FIVE trailing octets of Fill Data are present, then they cannot possibly form a Frame Header, and they will be immediately discarded by the Transfer layer. If FIVE OR SIX trailing octets of Fill Data exist, the Transfer layer data handling process might attempt to interpret the Fill Data as a new Transfer Frame Header; however, the subsequent Frame Validation Check (see 4.3.2) will prevent this from happening because the Fill pattern of "01010101" appearing in each octet will violate at least one of the validation tests; in particular, this pattern appearing where the FRAME LENGTH field might be expected will indicate a frame length that exceeds the number of octets received from the Coding layer, thus failing a test and causing the trailing five or six octets to be discarded. 4.3.2 FRAME VALIDATION CHECK PROCEDURE After each TC Transfer Frame is reconstituted from the string of octets provided by the Coding layer, it will next be subjected to a set of standard tests called a "Frame Validation Check". The Frame Validation Check shall be applied to ALL incoming TC Transfer Frames, regardless of whether they are Type-A or Type-B. Failure to pass any test within the Frame Validation Check shall cause the Transfer Frame to be rejected (discarded). The Frame Validation Check consists of the following tests: (1) The TC Frame must have an expected VERSION NUMBER. (2) The TC Frame must have the expected SPACECRAFT ID. (3) The TC Frame Header must not contain any values which are not consistent with the implemented features for that spacecraft. (4) The value of the FRAME LENGTH must be consistent with the number of octets that are present. (5) If implemented, the FRAME ERROR CONTROL test must pass. (6) The Data Field of a TC Frame containing a Control Command must be consistent with the allowed Control Commands. 4.3.3 COMMAND OPERATION PROCEDURE (COP) The Command Operation Procedure fully specifies the closed-loop protocols executed by the sending and receiving ends of the Transfer layer of the TC System. The COP, which exists wholly within the Transfer layer, consists of a pair of synchronized procedures for each Virtual Channel: a Frame Operation Procedure (FOP) that executes within the sending entity; and a Frame Acceptance and Reporting Mechanism (FARM) that executes within the receiving entity. The sending FOP transmits TC Frames to the receiving FARM. The FARM returns telemetered Command Link Control Words (CLCWs) to the FOP and thus closes the loop by providing reports of the status of frame acceptance. The COP provides a basic Quality Of Service (QOS) within the Transfer layer that is central to the operation of the TC System, i.e., the delivery of data units to the receiving end of the layer above, correct and without omission or duplication, and in the same sequential order in which they were received from the layer above at the sending end. Only one COP is defined in this Recommendation: COP-1. C A U T I O N THE CONTROLLING SPECIFICATIONS FOR THE LOGICAL OPERATIONS WHICH MUST BE EXECUTED TO PERFORM THE COP ARE CONTAINED IN A MORE DETAILED CCSDS RECOMMENDATION (REFERENCE [7]). IN THE EVENT OF ANY CONFLICT BETWEEN THE DESCRIPTIVE TEXT CONTAINED IN THIS RECOMMENDATION AND THE TEXT OF REFERENCE [7], THE MORE DETAILED SPECIFICATIONS CONTAINED IN REFERENCE [7] SHALL PREVAIL. Underlying the Transfer layer is the physical telecommand data channel which interconnects its sending and receiving ends. If a perfect data channel existed, the QOS would be assured since the exact duplicate of the series of data units which was input to the sending end would appear at the receiving end. However, space data channels are noisy and may introduce errors or discontinuities into transmitted data streams. The job of the COP within the Transfer layer is therefore to ensure the correctness, completeness and sequentiality of the delivered data units, in the presence of such errors or discontinuities introduced by the layer below. Correctness of the delivered data units is guaranteed (within known error probabilities) by means of the error-protection encoding applied by the Channel Service, and by the Frame Validation Check performed by the Transfer layer. However, validation of the completeness, sequentiality and non-duplication of the delivered data units on a particular Virtual Channel requires that a frame accounting (i.e., numbering) scheme be implemented by the COP. FARM-1 permits Type-AD frames to be accepted only if they are received bearing absolute FRAME SEQUENCE NUMBERS which are in the proper up-counting sequential order; upon detection of the first frame sequence error, the FARM will reject all subsequent Type-AD frames on that Virtual Channel which do not contain the expected FRAME SEQUENCE NUMBER, and the FOP must go back n frames and resume sequential retransmission by repeating all unacknowledged Type-AD frames. Type-BC frames are used to send Control Commands to the FARM. Type-BD frames are processed by the COP only to the extent of causing the FARM to increment the FARM-B COUNTER in the CLCW. ANNEX A DATA ROUTING SERVICE ACRONYMS AND TERMINOLOGY (THIS ANNEX IS PART OF THE RECOMMENDATION) Purpose: This Annex defines the key acronyms and terms which are used throughout this Recommendation to describe activities within the Segmentation and Transfer Layers. ACRONYMS A: ACCEPTANCE CHECK MODE B: BYPASS MODE CCSDS: CONSULTATIVE COMMITTEE FOR SPACE DATA SYSTEMS CLCW: COMMAND LINK CONTROL WORD COP: COMMAND OPERATION PROCEDURE COP-1: COMMAND OPERATION PROCEDURE #1 CTRL: CONTROL FARM: FRAME ACCEPTANCE AND REPORTING MECHANISM FARM-1: FARM PART OF COP-1 FOP: FRAME OPERATION PROCEDURE FOP-1: FOP PART OF COP-1 ID: IDENTIFIER MAP: MULTIPLEXER ACCESS POINT MSB: MOST SIGNIFICANT BIT N(R): THE OBSERVED VALUE OF V(R) CONTAINED IN ONE CLCW N(S): TRANSMITTED FRAME SEQUENCE NUMBER QOS: QUALITY OF SERVICE RF or rf: RADIO FREQUENCY TC: TELECOMMAND TF: TRANSFER FRAME VC: VIRTUAL CHANNEL V(R): RECEIVER_FRAME_SEQUENCE_NUMBER TERMINOLOGY CODING LAYER: The top layer of the Channel Service, specified in Reference [4]. This is the layer immediately below the Transfer layer. COMMAND LINK CONTROL WORD (CLCW): The CLCW is the protocol data unit for TC reporting via telemetry from the FARM back to the FOP. The CLCW resides wholly within the Transfer layer, though it does include a few parameters describing the readiness state of lower layers, which aid the efficient operation of the COP. The CLCW does not perform any reporting service for the Segmentation layer. COMMAND OPERATION PROCEDURE (COP): A sequence of procedural activities designed to assure the reliable, error- controlled delivery of a TC Transfer Frame across the Transfer layer. The COP consists of a Frame Operation Procedure (FOP) operating within the sending end of the layer and a Frame Acceptance and Reporting Mechanism (FARM) operating within the receiving end of the layer. COP-1 = Sequential acceptance and retransmission with frame sequence numbering. CONTROL COMMAND: A special Type-B TC Frame which carries control instructions in its Data Field to set up the internal operating parameters of the FARM. CONTROL INSTRUCTION: Information that is required to set up a TC System layer to support the handling of telecommands. DATA START: A signal from the Coding layer which becomes "true" to notify the Transfer layer that valid decoded data octets are being transferred. DATA STOP: A signal from the Coding layer corresponding to Data Start becoming "false", which notifies the Transfer layer that no more valid data octets are being transferred by the layer below. FARM-B COUNTER: A counter, reported in the CLCW, which increments once for every Type-B frame that is accepted by the FARM on a particular Virtual Channel. FILL DATA: Extra trailing octets of meaningless data added by the sending end Coding layer to complete the last TC Codeblock. Because information in the TC Transfer Frame is needed by the receiving end to determine how much Fill Data has been added, Fill Data must be removed by the receiving end Transfer layer, not by the receiving end Coding layer. FRAME ACCEPTANCE AND REPORTING MECHANISM (FARM): The FARM is the set of procedures executed by the receiving end of the Transfer layer to decide whether to accept a TC Transfer Frame and how to report operation and status back to the FOP via Command Link Control Words. FRAME OPERATION PROCEDURE (FOP): The FOP is the procedure executed by the sending end of the Transfer layer to transmit a TC Transfer Frame. The FOP conducts a transfer sequence using the communication services of the underlying TC Channel Service. Actions of the FOP are dictated by the rules of the COP and the FARM status information passed back to it via the telemetered Command Link Control Word (CLCW). FRAME SEQUENCE NUMBER N(S): The up-counting absolute number that is placed into each Type-A TC Frame. FRAME VALIDATION CHECK: A set of common integrity and quality tests to which ALL TC Transfer Frames are first subjected when they are processed by the receiving end of the Transfer layer. LOCKOUT: A condition whereby the FARM has detected a severe sequentiality anomaly and rejects all subsequent Type-A frames until reset by a Type-B UNLOCK Control Command. MULTIPLEXER ACCESS POINT (MAP): A MAP is a mechanism provided within the Segmentation layer to allow different user data structures to be multiplexed together for transmission on one Virtual Channel provided by the Transfer layer. Multiplexing allows user data structures with different delivery priorities to share the same Virtual Channel and thus provides flow control. NEXT EXPECTED FRAME SEQUENCE NUMBER N(R): The observed current value of V(R) that is telemetered from the FARM to the FOP via each CLCW. PACKETIZATION LAYER: The bottom layer of the Data Management Service, specified in Reference [3]. This is the layer immediately above the Segmentation layer. RECEIVER_FRAME_SEQUENCE_NUMBER V(R): The value of the Frame Sequence Number, N(S), which the FARM expects to see in the next Type-A frame in order to preserve up-counting sequence. RETRANSMIT: A flag indication from the FARM, contained in a CLCW, that at least one Type-A frame has been rejected and that retransmission is required from the FOP. SEGMENTATION LAYER: The top layer of the Data Routing Service, which interfaces user data structures with the protocols used during transfer to the receiving spacecraft. TELECOMMAND FRAME DATA UNIT (TC FRAME DATA UNIT) The data unit generated by the Segmentation layer to be placed in the data field of the TC Transfer Frame which will convey the data to the spacecraft. It will consist of a TC Segment, one or more complete TC Packets or a single TC User Data Unit. TELECOMMAND SEGMENT (TC SEGMENT): The protocol data unit of the TC Segmentation layer. A TC Segment consists of a Segment Header and Segment Data Field. TELECOMMAND TRANSFER FRAME (TC TRANSFER FRAME or TC FRAME): The protocol data unit of the Transfer layer. TC Transfer Frames contain a Frame Header, a Frame Data Field, and an optional Frame Error Control Field. The Data Field carries either a TC Frame Data Unit (e.g., a TC Segment or TC Packet(s)) or a Control Command, which establishes the internal operations of the Transfer layer. TELECOMMAND USER DATA UNIT (TC USER DATA UNIT): A finite-length user data structure provided by the layers above to be carried from the ground to the spacecraft. If the layer above the Segmentation layer is the Packetization layer, the TC User Data Unit will be a TC Packet. If the layers above the Segmentation layer do not conform to the CCSDS telecommand architecture, the TC User Data Unit may be any other higher-layer user data structure. Certain services of the Segmentation layer are provided only for TC Packets. TRANSFER LAYER: The bottom layer of the Data Routing Service, which performs the transfer of user data structures to the receiving spacecraft. TYPE-A (ACCEPTANCE MODE) FRAMES: TC Transfer Frames which have a flag set indicating that they are to be tested against the Frame Acceptance Check. TYPE-B (BYPASS MODE) FRAMES: TC Transfer Frames which have a flag set indicating that they are NOT to be tested against the Frame Acceptance Check, but should be delivered as soon as they pass the Frame Validation Check. UNLOCK: A Type-B Control Command which resets a FARM LOCKOUT condition. VIRTUAL CHANNEL (VC): Virtual Channels are provided by the Transfer layer, which interfaces with the single physical channel in the layers below and presents the service of apparently separating this single channel into multiple "virtual" paths to the Segmentation layer. A Virtual Channel (VC) is simply a unique, multi-bit ID code assigned to a particular sequence of TC Transfer Frames to enable all the frames which are members of that sequence to be identified. When different Virtual Channel IDs are assigned to different TC Transfer Frame sequences, the sequences can be multiplexed onto the physical channel at the sending end and then sorted at the receiving end back into their proper parent sequences. Necessarily, when Virtual Channels are not used, the physical channel in concept is the same as one Virtual Channel. Virtual Channels provide an alternative method for multiplexing user data structures if the multiplexing feature of the Segmentation layer is not used. WAIT: An indication from the FARM, contained in a CLCW, that the receiving end of the Transfer layer has encountered congestion in passing data to the layer above and cannot accept any more Type-A frames. ANNEX B DATA ROUTING SERVICE SPECIFICATION (THIS ANNEX IS PART OF THE RECOMMENDATION) Purpose: This Annex provides the detailed specification of the service provided by the Segmentation and Transfer layers. B-1 OVERVIEW OF THE LAYERS WITHIN THE DATA ROUTING SERVICE The Data Routing Service is implemented using two layers of protocol: the Segmentation layer and the Transfer layer. The function of the Segmentation layer is to prepare user telecommand messages for transmission to the spacecraft, using services of the Transfer layer, by forming them into TC Frame Data Units. The function of the Transfer layer is to reliably move Transfer Frames from the sending end of the Telecommand System to the receiving end, using the Channel Service, including retransmission of any frames which were found by the receiving end to have been damaged or lost during transfer. A diagram defining the principal elements within the Data Routing Service is presented in Figure B-1. Higher-layer TC User Data Units (e.g., TC Packets) may range in length from very short units to very long ones. The characteristics of the physical data channel which interconnects the sending and receiving end of the system are such that the most effective method of transmission requires intermediate length (up to 8 k bit) data structures (see Reference [2]). Furthermore, since this physical data channel has a finite data-carrying capacity, a method must be provided to prevent one user from monopolizing the channel to the exclusion of others. The task of the Data Routing Service is therefore to provide the transformation between the characteristics of the user layers of the TC System and the constraints of the physical channel, including breaking large user messages into smaller communications-oriented pieces or aggregating very small user messages into larger pieces and multiplexing these pieces to provide responsive virtual access to the channel for all users. A "TC Segment" is the specific form of the "TC Frame Data Unit" containing a Segment Header. B-2 TC SEGMENTATION LAYER SERVICE SPECIFICATION The services provided by the Telecommand Segmentation layer are as follows: (1) The layer breaks long user data structures from the layer above (i.e., TC Packets, or other user data structures which have been generated by a non-standard higher layer) into pieces ("TC Frame Data Units") which will fit the data field of TC Transfer Frames, and reassembles them after passage through the Transfer layer. (2) The layer optionally aggregates multiple TC Packets into a single TC Frame Data Unit, which fits into the data field of a TC Transfer Frame and separates them after passage through the Transfer layer. (3) The layer provides a mechanism for multiplexing different TC Frame Data Units together onto a single Virtual Channel, for the purpose of flow control. The Segmentation service described in this Recommendation is designed to support the standard CCSDS telecommand Packetization layer (Reference [3]). It can also provide services to other non-standard higher-layer TC processes as long as the interface requirements of the Segmentation layer are satisfied. [GRAPHIC ELEMENT OMITTED] Figure B-1: TC Data Routing Service Elements B-2.1 Segmentation Layer: Sending End Service Specification (1) INPUTS From the Packetization layer or other layer above: (a) Transportable TC User Data Units (e.g., TC Packets) which are to be routed to the spacecraft. The length of the TC User Data Unit is unconstrained; however, if they are TC Packets, then each will have a maximum length of 65542 octets. (b) Control instructions which are required in order to transfer the user data structures to the spacecraft. Those control instructions specifying delivery priority are read and processed by the Segmentation layer and establish the multiplexing hierarchy within this layer. Other control instructions (e.g., directives to abort specific commands) are passed through to the layer below. NOTE: The abstract content and concrete format of the control instructions are not presently specified and remain an item for potential future extension. From the receiving end of the Segmentation layer: None. From the Transfer layer below: (c) Information describing the status of transfer of TC Frame Data Units through a given Virtual Channel. (2) OUTPUTS To the Packetization layer or other layer above: (a) Information describing the status of transfer of TC User Data Units. To the receiving end of the Segmentation layer: None. To the Transfer layer below: (b) User data structures which have been formed into TC Frame Data Units. (c) Control instructions, possibly passed through from the layer above. (3) INTERNAL FUNCTIONS (a) Assigns individual TC User Data Units to particular Multiplexer Access Points (MAPs) for routing to the spacecraft through a Virtual Channel (VC) provided by the Transfer layer. (b) Breaks or aggregates the TC User Data Units into pieces which are compatible with insertion into the data field of the TC Frame Data Unit. (c) Optionally labels each piece with sequence control and MAP identification information to create a TC Segment. The TC Segment or the piece from (b), if the Segment Header is not used, becomes the TC Frame Data Unit. (d) Multiplexes TC Frame Data Units from different MAPs together onto one Virtual Channel for flow control purposes. (e) Monitors the process of transferring TC Frame Data Units through Virtual Channels by the layers below, and maintains cognizance of the status and availability of particular Virtual Channels. B-2.2 Segmentation Layer: Receiving End Service Specification (1) INPUTS From the Packetization layer or other layer above: (a) Information concerning the ability of the higher layer to accept more data. From the sending end of the Segmentation layer: None. From the Transfer layer below: (b) TC Frame Data Units in sequence and complete, without omission or duplication (if sent as Type-A Frames). (2) OUTPUTS To the Packetization layer or other layer above: (a) Reconstructed User Data Units. To the sending end of the Segmentation layer: None. To the Transfer layer below: (b) Information concerning the ability of the Segmentation layer to accept more data. (3) INTERNAL FUNCTIONS (a) Receives TC Frame Data Units from the Transfer layer, delivered on individual Virtual Channels. (b) Sorts TC Frame Data Units associated with individual VCs according to their MAP identifier and reassembles the Segments associated with a particular MAP to reconstruct the TC User Data Unit. (c) Determines when all TC Segments associated with a particular TC User Data Unit have been received correctly. (d) Extracts the TC Packets. (e) Passes the reconstructed TC User Data Units to the Packetization layer or other higher layer. B-3 TC TRANSFER LAYER SERVICE SPECIFICATION The service provided by the TC Transfer Frame layer is to encapsulate Data Units within a suitable data structure, the TC Transfer Frame, for transmission through the physical channel which interconnects the sending and receiving ends of the TC System, and to reliably convey them without detected error from the sending to the receiving ends of the layer. Efficient telecommand operation can usually be achieved when the Channel Service (Reference [2]) rejects less than 1 frame per 10**3 frames transmitted. To achieve the performance required for a particular mission, an acceptable combination of Channel Service parameters (e.g., codeblock decoding method, number of contiguous TC Codeblocks, error characteristics of the physical layer) must be selected. Information on the frame rejection performance is given in Reference [2]. Project operations are compromised by undetected frame errors. The selected Channel Service parameters not only control the frame rejection rate but also dictate the inherent undetected frame error rate. If the undetected frame error rate provided by the Channel Service is inadequate for a project's needs, the Cyclic Redundancy Check described in sec 4.2.1.3 should be applied to the transfer frame to bring this error rate into conformance. Information on undetected frame error performance is given in Reference [2]. B-3.1 Transfer Layer: Sending End Service Specification (1) INPUTS From the Segmentation layer above: (a) TC Frame Data Units. (b) Control instructions, Management Directives and Data Transfer Requests for the FOP. (See Reference [7] for details.) From the receiving end of the Transfer layer: (c) Information concerning the status of receipt of individual TC Frames, formatted into a Command Link Control Word (CLCW) and extracted from the Telemetry Transfer Frame (Reference [5]) or the Virtual Channel Data Unit (Reference [8]). From the Coding layer below: (d) Status of the physical channel. (2) OUTPUTS To the Segmentation layer above: (a) Status of the data routing process, including the progress of delivering individual TC Frame Data Units and the availability of Virtual Channels. To the receiving end of the Transfer layer: (b) "Control Command" TC Transfer Frames, which instruct the receiving end how to accept and report the received frames. To the Coding layer below: (c) Buffers of TC data bits containing protocol data units from the TC Transfer layer (i.e., one or more TC Transfer Frames). (d) Control instructions defining the operational procedures to be used to transmit the buffer of bits to the spacecraft. (3) INTERNAL FUNCTIONS (a) Encapsulates TC Frame Data Units into TC Transfer Frames. (b) Translates control instructions received from layers above into the appropriate set of operational procedures to be used to transfer the TC Transfer Frames to the spacecraft, including selection of the correct mode (Acceptance Test or Bypass) of the Command Operation Procedure (COP). (c) Creates Control Command TC Transfer Frames for transmission to the receiving end of the layer in order to control the Frame Acceptance and Reporting Mechanism (FARM). (d) Supervises the transfer of TC Transfer Frames to the receiving end by executing a Frame Operation Procedure (FOP) in accordance with the selected mode of the COP. (e) Retransmits TC Frames as required to rectify channel-induced errors. (f) Responds to control instructions from layers above to abort command transmission by issuing the appropriate set of control instructions to the layer below. B-3.2 Transfer Layer: Receiving End Service Specification (1) INPUTS From the Segmentation layer above: (a) Information defining the ability of the Segmentation layer to accept more data (optional). From the sending end of the Transfer layer: (b) Control Command TC Transfer Frames which contain instructions defining how the data-carrying TC Transfer Frames are to be processed. From the Coding layer below: (c) "Clean" octets of decoded TC data. (Note: only correct data, which have passed the decoder quality check, will normally be received.) (d) "Data Start" signal (indication of the start of the first valid octet of TC data). (e) "Data Stop" signal (indication of the last valid octet of TC data). (Note: trailing octets of Fill Data could be present just before the Data Stop signal is received.) (f) Control information describing the status of the physical channel (e.g., rf and bit synchronization). (2) OUTPUTS To the Segmentation layer above: (a) TC Frame Data Units which have been extracted from TC Transfer Frames that passed the validation and, optionally, the acceptance tests. To the sending end of the Transfer layer: (b) CLCWs which will be utilized by the FOP to control the transmission of additional TC Transfer Frames, or the retransmission of previously sent frames, in accordance with the rules of the COP. To the Coding layer below: None. (3) INTERNAL FUNCTIONS (a) Responds to Control Command TC Transfer Frames received from the sending end of the layer. (b) Performs the Frame Validation Check Procedure for all TC Transfer Frames and the frame acceptance checks of the Frame Acceptance and Reporting Mechanism for Type-A Frames. (c) Creates reports (CLCWs) to the sending end describing the status of TC Transfer Frame acceptance. (d) Processes TC Transfer Frames which have been retransmitted as required to rectify channel-induced errors. (e) Extracts TC Frame Data Units. (f) Passes the extracted TC Frame Data Units to the Segmentation layer. (g) Responds to control instructions from layers below to abort command transmission by ceasing the processing of the current TC Transfer Frame, and awaiting new control instructions.