CCSDS Historical Document

CCSDS Historical Document This document s Historical status indicates that it is no longer current. It has either been replaced by a newer issue or withdrawn because it was deemed obsolete. Current CCSDS publications are maintained at the following location: http://public.ccsds.org/publications/

Consultative Committee for Space Systems RECOMMENDATION FOR SPACE DATA SYSTEM STANDARDS PACKET TELEMETRY SERVICE SPECIFICATION CCSDS 103.0-B-2 BLUE BOOK June 2001

AUTHORITY Issue: Blue Book, Issue 2 Date: June 2001 Location: Oxfordshire, UK This document has been approved for publication by the Management Council of the Consultative Committee for Space Systems (CCSDS) and represents the consensus technical agreement of the participating CCSDS Member Agencies. The procedure for review and authorization of CCSDS Recommendations is detailed in reference [B1], and the record of Agency participation in the authorization of this document can be obtained from the CCSDS Secretariat at the address below. This Recommendation is published and maintained by: CCSDS Secretariat Program Integration Division (Code MT) National Aeronautics and Space Administration Washington, DC 20546, USA CCSDS 103.0-B-2 Page i June 2001

STATEMENT OF INTENT The Consultative Committee for Space 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 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. 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 CCSDSrelated 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. CCSDS 103.0-B-2 Page ii June 2001

FOREWORD This document is a technical Recommendation for use in developing packetized telemetry systems and has been prepared by the Consultative Committee for Space Systems (CCSDS). The Packet Telemetry Services described herein are intended for spacecraft-toground data communication within missions that are cross-supported between Agencies of the CCSDS. This Recommendation establishes a common framework and provides a common basis for the data services of spacecraft telemetry systems. It allows implementing organizations within each Agency to proceed coherently with the development of compatible derived Standards for the flight and ground systems that are within their cognizance. Derived Agency Standards may implement only a subset of the optional features allowed by the Recommendation and may incorporate features not addressed by the Recommendation. 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 [B1]. CCSDS 103.0-B-2 Page iii June 2001

At time of publication, the active Member and Observer Agencies of the CCSDS were: Member Agencies Agenzia Spaziale Italiana (ASI)/Italy. British National Space Centre (BNSC)/United Kingdom. Canadian Space Agency (CSA)/Canada. Centre National d Etudes Spatiales (CNES)/France. Deutsches Zentrum für Luft- und Raumfahrt e.v. (DLR)/Germany. European Space Agency (ESA)/Europe. Instituto Nacional de Pesquisas Espaciais (INPE)/Brazil. National Aeronautics and Space Administration (NASA)/USA. National Space Development Agency of Japan (NASDA)/Japan. Russian Space Agency (RSA)/Russian Federation. Observer Agencies Austrian Space Agency (ASA)/Austria. Central Research Institute of Machine Building (TsNIIMash)/Russian Federation. Centro Tecnico Aeroespacial (CTA)/Brazil. Chinese Academy of Space Technology (CAST)/China. Commonwealth Scientific and Industrial Research Organization (CSIRO)/Australia. Communications Research Centre (CRC)/Canada. Communications Research Laboratory (CRL)/Japan. Danish Space Research Institute (DSRI)/Denmark. European Organization for the Exploitation of Meteorological Satellites (EUMETSAT)/Europe. European Telecommunications Satellite Organization (EUTELSAT)/Europe. Federal Service of Scientific, Technical & Cultural Affairs (FSST&CA)/Belgium. Hellenic National Space Committee (HNSC)/Greece. Indian Space Research Organization (ISRO)/India. Institute of Space and Astronautical Science (ISAS)/Japan. Institute of Space Research (IKI)/Russian Federation. KFKI Research Institute for Particle & Nuclear Physics (KFKI)/Hungary. MIKOMTEK: CSIR (CSIR)/Republic of South Africa. Korea Aerospace Research Institute (KARI)/Korea. Ministry of Communications (MOC)/Israel. National Oceanic & Atmospheric Administration (NOAA)/USA. National Space Program Office (NSPO)/Taipei. Swedish Space Corporation (SSC)/Sweden. United States Geological Survey (USGS)/USA. CCSDS 103.0-B-2 Page iv June 2001

DOCUMENT CONTROL Document Title Date Status CCSDS 103.0-B-1 Packet Telemetry Services, Issue 1 May 1996 Original Issue (supeseded) CCSDS 103.0-B-2 Packet Telemetry Service Specification, Issue 2 June 2001 Current Issue: adds specifications to support use of the CCSDS Version-1 Telemetry Transfer Frame to transport other types of packets in addition to CCSDS Version-1 Packets, including CCSDS Network Protocol (NP) Packets and Internet Protocol (IP) packets. NOTE Substantive changes from the previous issue are flagged with change bars in the inside margin. CCSDS 103.0-B-2 Page v June 2001

Section CONTENTS Page 1 INTRODUCTION... 1-1 1.1 PURPOSE... 1-1 1.2 SCOPE... 1-1 1.3 APPLICABILITY... 1-1 1.4 RATIONALE... 1-1 1.5 DOCUMENT STRUCTURE... 1-1 1.6 CONVENTIONS AND DEFINITIONS... 1-2 1.7 REFERENCES... 1-4 2 OVERVIEW... 2-1 2.1 PACKET TELEMETRY SERVICES... 2-1 2.2 RELATIONSHIP TO OSI... 2-1 2.3 PACKET TELEMETRY LAYERS... 2-2 2.4 QUEUED VERSUS BUFFERED SERVICE... 2-5 3 SOURCE DATA... 3-1 3.1 SOURCE DATA OVERVIEW... 3-1 3.2 PACKET DATA... 3-1 3.3 PRIVATELY DEFINED DATA... 3-1 3.4 FRAME SECONDARY HEADER DATA... 3-2 3.5 OPERATIONAL CONTROL FIELD DATA... 3-3 4 LAYER D SPACE TRANSFER LAYER... 4-1 4.1 SPACE TRANSFER LAYER OVERVIEW... 4-1 4.2 PACKET TRANSFER (PT_XFR) SERVICE... 4-2 4.3 PRIVATELY DEFINED DATA TRANSFER SERVICE... 4-5 4.4 VIRTUAL CHANNEL FRAME SECONDARY HEADER SERVICE... 4-11 4.5 VIRTUAL CHANNEL OPERATIONAL CONTROL FIELD SERVICE... 4-16 5 LAYER C VIRTUAL CHANNEL ACCESS LAYER... 5-1 5.1 OVERVIEW OF VIRTUAL CHANNEL ACCESS LAYER... 5-1 5.2 VIRTUAL CHANNEL FRAME SERVICE... 5-1 5.3 MASTER CHANNEL FRAME SECONDARY HEADER SERVICE... 5-7 5.4 MASTER CHANNEL OPERATIONAL CONTROL FIELD SERVICE... 5-13 5.5 ADDITIONAL (OPTIONAL) FUNCTIONS OF THIS LAYER... 5-19 6 LAYER B CHANNEL ACCESS LAYER... 6-1 6.1 OVERVIEW OF CHANNEL ACCESS SERVICE... 6-1 6.2 DEFINITIONS AND ABBREVIATIONS... 6-1 6.3 CHANNEL ACCESS SERVICE SDU... 6-3 6.4 PREREQUISITES FOR THE CHANNEL ACCESS SERVICE... 6-3 CCSDS 103.0-B-2 Page vi June 2001

Section CONTENTS (continued) Page 6.5 SERVICE PRIMITIVES OF THE CHANNEL ACCESS SERVICE... 6-4 6.6 CHANNEL ACCESS SERVICE PARAMETERS... 6-4 6.7 DETAILED SPECIFICATION OF CHANNEL ACCESS SERVICE PRIMITIVES... 6-5 ANNEX A ACRONYMS... A-1 ANNEX B INFORMATIVE REFERENCES... B-1 ANNEX C A BRIEF TUTORIAL ON OSI SERVICE TERMINOLOGY... C-1 Figure 2-1 OSI Service Concept...2-1 2-2 CCSDS Packet Telemetry Layers...2-4 2-3 Queued Service Model...2-5 2-4 Buffered Service Model...2-6 4-1 Examples of Space Transfer Layer Services...4-1 4-2 Privately Defined Service...4-6 4-3 Abstract Model of PDD-XFR Service...4-7 4-4 VC_Frame Secondary Header Service...4-12 4-5 Abstract Model of VC_FSH Service...4-13 4-6 VC_OCF Service...4-17 4-7 Abstract Model of VC_OCF Service...4-18 5-1 VC_Frame Service...5-2 5-2 Abstract Model of a VC_Frame Service...5-3 5-3 MC_Frame Secondary Header Service...5-8 5-4 Abstract Model of an MC_FSH Service...5-9 5-5 MC_OCF Service...5-14 5-6 Abstract Model of MC_OCF Service...5-15 6-1 Channel Access Service...6-2 6-2 Abstract Model of Channel Access Service...6-3 C-1 OSI-Service Model... C-2 C-2 Example of a Peer-to-Peer Connection-Mode Service... C-3 C-3 OSI-Service Components on Open Systems... C-4 Table 2-1 Summary of Packet Telemetry Services...2-3 CCSDS 103.0-B-2 Page vii June 2001

1 INTRODUCTION 1.1 PURPOSE The purpose of this Recommendation is to define the services of a packet telemetry system. To do so, it establishes a layered model of Packet Telemetry protocols and defines Packet Telemetry Services by specifying the behavior at the service interfaces to each layer. The layered model and services are based on the CCSDS Recommendations for Packet Telemetry and Telemetry Channel Coding, references [1] and [2]. These referenced Recommendations define the formats of the protocol-data-units used to transfer telemetry from spacecraft to ground or spacecraft to spacecraft, as well as the protocol procedures that support that transfer. NOTE Definitions of service, layer, and other terms used in this Recommendation are provided in 1.6, and are further explained in 2.2. 1.2 SCOPE This Recommendation defines only the services provided between protocol layers of the CCSDS space to ground link. It does not define the extension of these services across distributed components of the spacecraft or ground data systems. 1.3 APPLICABILITY This Recommendation applies to the creation of Agency standards and to the future exchange of Packet Telemetry between CCSDS Agencies in cross-support situations. The Recommendation includes comprehensive specification of the services that can be provided by remote space vehicles (spacecraft) for telemetering to space mission data processing facilities (which are usually located on Earth). The Recommendation does not attempt to define the architecture or configuration of these data processing facilities, except to describe assumed data processing services which affect the selection of certain on-board formatting options. 1.4 RATIONALE The rationale for Packet Telemetry is presented in reference [B2]. 1.5 DOCUMENT STRUCTURE The remainder of this document is organized as follows: section 2 provides an overview of this Recommendation, including a layered model of packet telemetry services; section 3 describes the data that is transferred from data sources in space to data sinks on the ground by the packet Telemetry Services; CCSDS 103.0-B-2 Page 1-1 June 2001

section 4 defines Space Transfer services, which support the transfer of data units (created by applications) by means of Virtual Channels; section 5 defines Virtual Channel Access services, which provide for the transfer of Virtual Channel, and certain application data units, in a single stream of fixed-length Transfer Frames; section 6 defines Channel Access Coding services, which support the transfer of a stream of Transfer Frames over a noisy channel; annex A lists acronyms and abbreviations used in this text along with their definitions; annex B lists informative references; annex C provides a brief tutorial on OSI service terminology. 1.6 CONVENTIONS AND DEFINITIONS 1.6.1 DEFINITIONS FROM REFERENCED DOCUMENTS The definitions below were adapted from references [B3], [B4], and [B5]. Concepts related to these terms are discussed in section 2 and in annex C of this Recommendation. association: a cooperative relationship among entities in the same layer. blocking: a protocol function that maps multiple service-data-units into one protocol-data-unit. multiplexing: a protocol function that uses one association in the layer below to support more than one association for users of the protocol. one-way communication: data communication in one pre-assigned direction. primitive, service primitive: an abstract, atomic, implementation-independent representation of an interaction between a service-user and its service-provider. protocol: a set of rules and formats (semantic and syntactic) which determines the communication behavior of layer entities in the performance of communication functions. protocol-data-unit (PDU): a unit of data specified in a protocol and consisting of protocolcontrol-information and possibly user data. segmentation: a protocol function that maps one service-data-unit into multiple PDUs. service: a capability of a layer, and the layers beneath it (a service-provider), which is provided to service-users at the boundary between the service-provider and the service-users. NOTE The service defines the external behavior of the service-provider, independent of the mechanisms used to provide that behavior. Layers, layer entities, applicationservice-elements, etc. are components of a service-provider. CCSDS 103.0-B-2 Page 1-2 June 2001

service-access-point (SAP): the point at which services are provided by an entity in a layer to an entity in the layer above. service-data-unit (SDU): an amount of information whose identity is preserved when transferred between peer entities in a given layer and which is not interpreted by the supporting entities in that layer. service-provider: an abstract representation of the totality of those entities which provide a service to service-users; i.e., a layer, and the layers beneath it. service-user: an entity in a single system that makes use of a service. NOTE The service-user makes use of the service through a collection of service primitives defined for the service. sink: an entity that receives SDUs from a service provider. source: an entity that sends SDUs, using a service provider. symmetric service: in a symmetric service, the local views at the service interfaces in two systems are the same. See annex C and reference [B5] for further discussion. unconfirmed service: in an unconfirmed service, the sending end does not receive confirmation that data that it sends has reached the receiving end. 1.6.2 TERMS DEFINED IN THIS RECOMMENDATION The terms defined below are used throughout this Recommendation. Many other terms that pertain to specific services are defined in the appropriate sections. aperiodic: not occurring at a constant rate (see below). asynchronous: not synchronous (see below). constant rate; periodic: a sequence of events in which each event occurs at a fixed time interval (within specified tolerance) after the previous event in the sequence. synchronous: a sequence of events occurring in a fixed time relationship (within specified tolerance) to another sequence of events. Note that synchronous does not necessarily imply constant rate. user-optional: a qualification of a service capability indicating that the entity using the service may choose to use, or not to use, the capability. The service provider is presumed to provide the capability if requested, but also to be able to provide service that does not include the user-optional capability. NOTE An example of a user-optional capability is a -Quality Flag that a receiving user may choose not to receive. CCSDS 103.0-B-2 Page 1-3 June 2001

1.6.3 USE OF BOLDFACE Boldface characters are used for names of Packet Telemetry data units, layers and services. 1.7 REFERENCES The following documents contain provisions which, through reference in this text, constitute provisions of this Recommendation. At the time of publication, the editions indicated were valid. All documents are subject to revision, and users of this Recommendation are encouraged to investigate the possibility of applying the most recent editions of the documents indicated below. The CCSDS Secretariat maintains a register of currently valid CCSDS Recommendations. [1] Packet Telemetry. Recommendation for Space System Standards, CCSDS 102.0- B-5. Blue Book. Issue 5. Washington, D.C.: CCSDS, November 2000. [2] Telemetry Channel Coding. Recommendation for Space System Standards, CCSDS 101.0-B-5. Blue Book. Issue 5. Washington, D.C.: CCSDS, June 2001. [3] CCSDS Global Spacecraft Identification Field Code Assignment Control Procedures. Recommendation for Space System Standards, CCSDS 320.0-B-2. Blue Book. Issue 2. Washington, D.C.: CCSDS, October 1998. [4] Space Link Identifiers. Draft Recommendation for Space System Standards, CCSDS 135.0-R-1. Red Book. Issue 1. Washington, D.C.: CCSDS, November 2000. CCSDS 103.0-B-2 Page 1-4 June 2001

2 OVERVIEW 2.1 PACKET TELEMETRY SERVICES This Recommendation complements the CCSDS Recommendations for Packet Telemetry (reference [1]), and Telemetry Channel Coding (reference [2]). The Packet Telemetry and Telemetry Channel Coding Recommendations define data units for telemetry systems; define formats of these data units; define rules and procedures for creation and use of these data units. These Recommendations, however, do not specify the interface between a data source or sink and the entity providing transfer of data units from space to ground, nor do they explicitly define the characteristics of the transfer process, from the viewpoint of a data source or sink. This Recommendation for Packet Telemetry Services defines a layered model of a packet telemetry system consistent with references [1] and [2]; defines services provided by each layer; provides parameters and conditions for use of each service. This Recommendation does not alter or redefine reference [1] or [2]. 2.2 RELATIONSHIP TO OSI This Recommendation defines Packet Telemetry Services in the style established by the OSI Basic Reference Model (reference [B3]), which describes communications services as being provided by layers of protocols, each layer providing a service interface to users of the service in the layer above, as shown in figure 2-1. The concepts and terminology of the OSI Basic Reference Model are summarized in annex C. (N)-service-user (N)-service-user Layer (N+1) (N)-service-primitives = (N)-service-data-units + parameters (N)-service-access-points (N)-service-provider Layer (N) Figure 2-1: OSI Service Concept CCSDS 103.0-B-2 Page 2-1 June 2001

A service interface is defined in terms of primitives, which present an abstract model of the exchange of data structures and control information between the layer and the service user. The primitives are independent of specific implementation approaches, and so do not specify aspects of the service interface that might vary from one implementation to another. These local issues include handshaking and flow control across the service interface (i.e., between the service user, in one layer, and the protocol entity in the layer below). A service user is not a mission user, such as a scientific investigator or spacecraft operator. A service user is typically a software process that is part of an instrument, subsystem, or data handling system on a spacecraft, or part of a data capture or data processing system on the ground. 2.3 PACKET TELEMETRY LAYERS Although this Recommendation uses OSI concepts to define services, the services of Packet Telemetry are not structured into the same seven layers as are OSI services. Further, because a key design goal of Packet Telemetry is efficient use of limited space link resources, the Packet Telemetry PDUs are structured differently from those of OSI protocols. Because of these differences, the Packet Telemetry layers are identified by letters (A through D) rather than numbers (1 to 7), to avoid confusion with the seven OSI layers. Figure 2-2 illustrates the Packet Telemetry layers, and table 2-1 summarizes the services that these layers provide. The services specified in this Recommendation are unidirectional services: one end (the spacecraft) can send, but not receive, data through the protocols providing the service, while the other end (on the ground) can receive, but not send. These services are also unconfirmed services: the sending end (spacecraft) does not receive confirmation that data it sends has been received. This is a consequence of the design of the space link protocols, which avoid the delays involved in confirmed services. These services can be implemented as asymmetrical services, in which the local view in one system is not the same as that in another system. That is, the implementation of the layers in one set of subsystems in space need not be structured in the same way as another set of subsystems on the ground. CCSDS 103.0-B-2 Page 2-2 June 2001

Table 2-1: Summary of Packet Telemetry Services Layer Services Service Capabilities D Space Transfer layer i. Packet Transfer Service Transfer of a sequence of variable-length PACKETs from a source application in space to one or more sink applications on the ground. C Virtual Channel Access layer B Channel Access layer A Physical Access layer ii. Privately Defined Service iii. Virtual Channel Frame Secondary Header Service iv. Virtual Channel Operational Control Field Service i. Virtual Channel Frame Service ii. Master Channel Frame Secondary Header Service iii. Master Channel Operational Control Field Service Channel Access Service Transfer of a sequence of PRIVATELY DEFINED DATA units of fixed length, along with status fields, from an on-board source to data sinks on the ground. Synchronous transfer of fixed-length FRAME SECONDARY HEADER in each frame on the VIRTUAL CHANNEL. Synchronous transfer of a fixed-length OPERATIONAL CONTROL FIELD in each frame of the VIRTUAL CHANNEL. Transfer of Transfer FRAMES from each of one to eight VIRTUAL CHANNELS over one MASTER CHANNEL. Synchronous transfer of a fixed-length FRAME SECONDARY HEADER in each frame on a MASTER CHANNEL. Synchronous transfer of a fixed-length OPERATIONAL CONTROL FIELD in each frame of the MASTER CHANNEL. Constant-rate transfer of fixed-length TRANSFER FRAMES, with optional error detection/correction. Physical Access Service Provision of a modulated radio link from spacecraft to ground. This service is not within the scope of this Recommendation, but is shown in this model since it provides the foundation for services defined here. The emphasis in this Recommendation is on descriptions of a single instance of a type of service. It does not treat system engineering issues (such as relationships among various users of a particular data transfer service, or among those system elements that provide these services). Such issues are discussed in the Packet Telemetry Concepts and Rationale Report (reference [B2]). This Recommendation makes no assumptions concerning the allocation of services, or the functions that provide services, to particular systems, subsystems or components, either on board a spacecraft, or in a ground system. Thus this Recommendation provides a designindependent description of services that could be provided, reserving for each mission the choice of which services to implement, and how to do so. CCSDS 103.0-B-2 Page 2-3 June 2001

On-Board System (Sending End) Sourc Sourc Source Sourc Ground System (Receiving End) Sink Sink Sink Sink Layer Packet, PDD, VC-FSH, or VC-OCF Space Transfer Layer D VC Transfer Frame; [MC-FSH]; [MC-OCF] [xxx] => 'Optional' Virtual Channel Access Layer C MC Transfer Frame Channel Access Layer B Stream of Symbols Physical Access Layer A Modulated r/f (Space to Ground) Figure 2-2: CCSDS Packet Telemetry Layers CCSDS 103.0-B-2 Page 2-4 June 2001

2.4 QUEUED VERSUS BUFFERED SERVICE Packet Telemetry Services are of two types: queued and buffered. Queued service In queued service (figure 2-3), each SDU from a sending user is placed in a queue, the contents of which are sent to a receiving user (or users) in the order in which they were presented. Although transmission errors may prevent delivery of some data units, the service provider attempts to transfer all data units provided by the user exactly once. The distinctive feature of queued service is that all of the data units from the sending user are transferred, and transferred only once. Sending User Receiving User Provider Transfer from sending end to receiving end Figure 2-3: Queued Service Model Buffered service In buffered service (figure 2-4), each SDU from a sending user is placed in a buffer that can hold only one SDU; the contents of the buffer are sent to a receiving user (or users) at a time determined by the service (but usually known to the user). The timing may be constant rate (e.g., in every Transfer Frame sent by a spacecraft), or aperiodic (e.g., in every Transfer Frame of a Virtual Channel that produces frames at irregular intervals depending on the arrival of packets). The distinctive feature of buffered service, which is essentially time-division multiplexing, is that the timing of data transfer is driven by the service provider, not by the user. Thus a particular data unit from a user might be sent once, several times (if the new value is not placed in the buffer soon enough), or not at all (if one value is replaced by a second before the service provider can send it). CCSDS 103.0-B-2 Page 2-5 June 2001

Sending User Receiving User Buffer Provider Buffer contents are transferred once per frame Transfer from buffer at sending end to receiving end Figure 2-4: Buffered Service Model These models of queued and buffered service are intended only to illustrate the characteristics of services. They are not intended to guide or restrict design of on-board or ground systems. CCSDS 103.0-B-2 Page 2-6 June 2001

3 SOURCE DATA 3.1 SOURCE DATA OVERVIEW 3.1.1 This section describes the data that is transferred from data sources in space to data sinks on the ground by the Packet Telemetry Services described in sections 4 through 6. 3.1.2 The on-board data sources format the data units according to the specifications for the data units defined in reference [1]. These data units are a) Packet; b) the Privately Defined (PDD) field; c) the Frame Secondary Header (FSH); d) the Operational Control Field (OCF). 3.1.3 These data units are passed to the Space Transfer layer for transfer across the space/ground link. On the ground are the sinks that accept the transferred data units. 3.1.4 The purpose of this subsection is to establish the requirements for formatted data units produced by on-board data sources, so that the interface requirements for the lower-layer services can be met. These service definitions also identify the data units delivered to sink applications by each of the transfer services provided by lower layers. 3.2 PACKET DATA Packets are variable-length, delimited, octet-aligned data units, and are usually the protocol data unit of a Network Layer protocol. Packets are transferred over a space link with the Packet Service. The Packets transferred by this service must be assigned a Packet Version Number (PVN) by CCSDS. For the Packet Version Numbers presently authorized by CCSDS, see reference [4]. The position and length of the Packet Length Field of the Packets must be known to the service provider in order to extract Packets from Transfer Frames at the receiving end. 3.3 PRIVATELY DEFINED DATA 3.3.1 PDD units are fixed-length data units from source applications on board that can be transferred to sink applications on the ground. A PDD unit consists of an integral number of octets, the format of which is not defined by CCSDS. CCSDS 103.0-B-2 Page 3-1 June 2001

3.3.2 Along with each PDD unit, PDD Status Fields are provided by the on-board source for transfer to the ground. The PDD Status Fields are the CCSDS Transfer Frame First Header Pointer Field and three other bits of the transfer frame Status Field: the Packet Order Flag (1 bit), and Segment Length ID (2 bits). These are undefined by CCSDS when a Virtual Channel is used to transfer PDD. They may (optionally) be used to convey information on the validity, sequence, or other status of the data in the PDD. Provision of this field is mandatory; semantics are user-optional. 3.3.3 Use of PDD requires the specification of managed parameters, which serve to establish associations between space and ground protocol entities, specify address mappings, provide access authorization, and define operating limits. 3.3.4 Managed parameters include a) addressing information needed to route PDD units to the Virtual Channel which is to provide the underlying PDD Transfer Service; b) the fixed length of the PDD units (see reference [1], section 5); c) implementation-specific parameters for timing, latency, or flow control. 3.3.5 Neither this Recommendation nor reference [1] specifies methods, procedures, or formats for providing these managed parameters. 3.3.6 PDD units are transferred by the PDD Transfer (PDD-XFR) Service to data sinks on the ground (see 4.3). 3.4 FRAME SECONDARY HEADER DATA 3.4.1 The FSH reference [1], section 5, is a data structure that carries fixed-length data from a source on board to a sink on the ground. Except for the FSH header defined in reference [1], CCSDS specifies no format or semantics for the content of an FSH. 3.4.2 FSHes may be sent in every frame of a Virtual Channel, using Virtual Channel FSH (VC_FSH) Transfer (VC_FSH-XFR) Service (see 4.4), or in every frame of a Master Channel, using Master Channel FSH (MC_FSH) Transfer (MC_FSH-XFR) Service (see 5.3). 3.4.3 Since MC_FSH-XFR and VC_FSH-XFR are buffered services as defined in 2.4, the creation and formatting of data to be transferred in FSHes may or may not be synchronized with the Virtual Channel or Master Channel that will provide the transfer service. Such synchronization, if required for timing or other purposes, is a mission-design issue. 3.4.4 The use of FSHes requires the specification of managed parameters, which serve to establish associations between space and ground protocol entities, specify address mappings, provide access authorization, and define operating limits. CCSDS 103.0-B-2 Page 3-2 June 2001

3.4.5 Managed parameters include a) addressing information needed to route the FSH to the Virtual Channel or Master Channel which is to provide the underlying transfer service; b) the fixed length of the FSH; c) the FSH Version Number; e) implementation-specific parameters for timing, latency, or flow control. 3.4.6 Neither this Recommendation nor reference [1] specifies methods, procedures, or formats for providing these managed parameters. 3.5 OPERATIONAL CONTROL FIELD DATA 3.5.1 The OCF (reference [1], section 5) is a data structure that carries a fixed-length (32- bit) data unit from a source on board to a sink on the ground. As defined in reference [1], CCSDS specifies the use of the first bit of this field to indicate the type of data carried. 3.5.2 An instance of OCF Service may be carried in every frame of one Virtual Channel, using Virtual Channel OCF (VC_OCF) Transfer (VC_OCF-XFR) Service (see 4.5), or, in every frame of a Master Channel, using Master Channel OCF (MC_OCF) Transfer (MC_OCF-XFR) Service (see 5.4). 3.5.3 Since MC_OCF-XFR and VC_OCF-XFR are buffered services as defined in 2.4, the creation and formatting of data to be transferred in the OCF may or may not be synchronized with the Virtual Channel or Master Channel that will provide the transfer service. Such synchronization, if required for timing or other purposes, is a mission-design issue. 3.5.4 Use of OCFs requires the specification of managed parameters, which serve to establish associations between space and ground protocol entities, specify address mappings, provide access authorization, and define operating limits. Managed parameters include a) addressing information needed to route the OCF to the Virtual Channel(s) or Master Channel which will provide the underlying transfer service; b) OCF Type; c) implementation-specific parameters for timing, latency, or flow control. 3.5.5 Neither this Recommendation nor reference [1] specifies methods, procedures, or formats for providing these managed parameters. CCSDS 103.0-B-2 Page 3-3 June 2001

4 LAYER D SPACE TRANSFER LAYER 4.1 SPACE TRANSFER LAYER OVERVIEW 4.1.1 The Space Transfer layer provides access to four transfer services from space to ground or space to space, using the Virtual Channel Frame (VC_Frame) as its PDU. These services are Packet Transfer (PT-XFR) Service; PDD-XFR Service; VC_FSH-XFR Service; VC_OCF-XFR Service. NOTE PT-XFR Service and PDD-XFR Service are mutually exclusive on any one Virtual Channel during a mission phase. A given Virtual Channel, whether it carries Packets or PDD, may also carry an FSH, an OCF, both, or neither. 4.1.2 The interface between on-board users of space transfer services and the Space Transfer layer is illustrated in figure 4-1. This figure shows only a few of the possible combinations of services and users, and thus should not be interpreted as specification. On-Board System (Sending End) Ground System (Receiving End) Source Source Source Source Source Sink Sink Sink Sink Sink Packets Operational Control Fields Privately Defined Units VC Frame Secondary Headers Packets Operational Control Fields Privately Defined Units VC Frame Secondary Headers Packet Transfer Function OCF Transfer Function VCj PDD Transfer Function FSH Transfer Function VCk Packet Transfer Function OCF Transfer Function VCj PDD Transfer Function FSH Transfer Function VCk Lower Layers provide Transfer to ground Layers C, B, A Figure 4-1: Examples of Space Transfer Layer Services CCSDS 103.0-B-2 Page 4-1 June 2001

4.2 PACKET TRANSFER (PT_XFR) SERVICE 4.2.1 OVERVIEW OF PACKET TRANSFER SERVICE The Packet Service transfers a sequence of variable-length, delimited, octet-aligned service data units known as Packets across a space link. The Packets transferred by this service must have a Packet Version Number (PVN) authorized by CCSDS. For the PVNs presently authorized by CCSDS, see reference [4]. The service is unidirectional (one way), asynchronous and sequence preserving. It does not guarantee completeness, nor does it signal gaps in the sequence of service data units delivered to a receiving user. A user of this service is a protocol entity that sends or receives Packets with a single PVN. A user is identified with the PVN and a GVCID. Different users (i.e., Packets with different versions) can share a single Virtual Channel, and if there are multiple users on a Virtual Channel, the service provider multiplexes Packets of different versions to form a single stream of Packets to be transferred on that Virtual Channel. 4.2.2 PACKET SERVICE PARAMETERS NOTE The parameters used by the Packet Service primitives are described below. 4.2.2.1 Packet The parameter Packet is the service data unit transferred by the Packet Service. For restrictions on the Packets transferred by the Packet Service, see reference [4]. 4.2.2.2 GVCID The GVCID is part of the SAP address of the Packet Service, and indicates the Virtual Channel through which the Packet is to be transferred. The GVCID consists of an MCID and a VCID. 4.2.2.3 Packet Version Number The Packet Version Number is part of the SAP address of the Packet Service, and identifies the protocol entity of the upper layer that uses the Packet Service. 4.2.2.4 Packet Quality Indicator The Packet Quality Indicator is an optional parameter that may be used to notify the user at the receiving end of the Packet Service whether the Packet delivered by the primitive is complete or partial. CCSDS 103.0-B-2 Page 4-2 June 2001

4.2.3 PACKET SERVICE PRIMITIVES 4.2.3.1 General The service primitives associated with this service are: a) PACKET.request b) PACKET.indication The PACKET.request primitive is passed from the Packet Service user at the sending end to the service provider to request that a Packet be transferred to the user at the receiving end through the specified Virtual Channel. The PACKET.indication is passed from the service provider to the Packet Service user at the receiving end to deliver a Packet. 4.2.3.2 PACKET.request 4.2.3.2.1 Function The PACKET.request primitive is the service request primitive for the Packet Service. 4.2.3.2.2 Semantics The PACKET.request primitive shall provide parameters as follows: PACKET.request (Packet, GVCID, Packet Version Number) 4.2.3.2.3 When Generated The PACKET.request primitive is passed to the service provider to request it to send the Packet. 4.2.3.2.4 Effect On Receipt Receipt of the PACKET.request primitive causes the service provider to transfer the Packet. 4.2.3.2.5 Additional comments The PACKET.request primitive is used to transfer Packets across the space link on the specified Virtual Channel. CCSDS 103.0-B-2 Page 4-3 June 2001

4.2.3.3 PACKET.indication 4.2.3.3.1 Function The PACKET.indication primitive is the service indication primitive for the Packet Service. 4.2.3.3.2 Semantics The PACKET.indication primitive shall provide parameters as follows: PACKET.indication (Packet, GVCID, Packet Version Number, Packet Quality Indicator (optional)) NOTE Packet Quality Indicator applies only to CCSDS Source Packets (see 4.2.2.4). CCSDS 103.0-B-2 Page 4-4 June 2001

4.3 PRIVATELY DEFINED DATA TRANSFER SERVICE 4.3.1 OVERVIEW OF PDD-XFR SERVICE The PDD-XFR Service provides transfer of a PDD unit of fixed length, along with status fields, from an on-board source to data sinks on the ground (see figure 4-4). The service is unidirectional (one way, space to ground), periodic, and order preserving. It does not guarantee completeness, but signals gaps. Only one instance of PDD-XFR Service can be provided on a Virtual Channel. NOTE PDD-XFR Service and SP-XFR Service (4.2) are mutually exclusive on any one Virtual Channel, within a mission phase. 4.3.2 DEFINITIONS AND ABBREVIATIONS For the purposes of this Service Definition, the following definitions and abbreviations apply: a) PDD-XFR_SDU a fixed-length data unit, consisting of an integral number of octets, the format of which is not defined by CCSDS (see reference [1]); b) sending PDD-XFR user an on-board source of PDD-XFR_SDUs to be transferred; c) receiving PDD-XFR user a sink for PDD-XFR_SDUs on the ground; a process that receives all PDD units of a particular Virtual Channel on the ground; d) PDD-XFR SAP service-access-point for PDD-XFR Service on a particular Virtual Channel. CCSDS 103.0-B-2 Page 4-5 June 2001

On-Board System (Sending End) Ground System (Receiving End) Source Sink Privately Defined Units Privately Defined Units PDD Transfer Function VCi D Space Transfer Layer PDD Transfer Function VCi VC Partial Frames VC Partial Frames Lower layers provide transfer to ground Layers C,B,A Legend Layer Entity Function providing service SAP for service fff nnn Entity Name Other Layer Functions (not identified) Figure 4-2: Privately Defined Service CCSDS 103.0-B-2 Page 4-6 June 2001

4.3.3 PDD-XFR SERVICE SDU 4.3.3.1 The abstract model of PDD-XFR Service is a queue linking the on-board PDD-XFR SAP for a given Virtual Channel to the corresponding PDD-XFR SAP on the ground. A separate queue exists for each Virtual Channel. There shall be only one queue for PDD- XFR Service on a given Virtual Channel. This model is illustrated in figure 4-5. Sending PDD User Receiving PDD User PDD Provider Transfer from sending end to receiving end Figure 4-3: Abstract Model of PDD-XFR Service 4.3.3.2 This model implies that a) the PDD-XFR_SDUs sent by an on-board source are transferred in order; b) the time relationship between PDD-XFR_SDUs sent by different on-board sources, on different Virtual Channel s, is not specified. 4.3.4 PREREQUISITES FOR PDD-XFR SERVICE 4.3.4.1 The PDD-XFR Service requires VC_Frame Service from the layers below (see 5.2). PDD-XFR Service also requires the specification of managed parameters. 4.3.4.2 Managed parameters for PDD-XFR Service include a) which Virtual Channel is to carry PDD; b) which application is authorized as the source of PDD on the Virtual Channel providing the service; c) fixed length of Frame Field; d) routing information for delivery at receiving end; e) whether optional parameters are to be delivered with PDD at the receiving end. CCSDS 103.0-B-2 Page 4-7 June 2001

4.3.4.3 Neither this Recommendation nor reference [1] specifies methods, procedures, or formats for providing these managed parameters. 4.3.5 SERVICE PRIMITIVES OF THE PDD-XFR SERVICE The service primitives associated with this service are a) PDD-XFR.request The PDD-XFR.request primitive is passed from the PDD-XFR Service user at the sending end to the PDD-XFR SAP of a Virtual Channel to request that a PDD- XFR_SDU be transferred. b) PDD-XFR.indication The PDD-XFR.indication is passed from the Space Transfer layer to the PDD- XFR user at the receiving end to deliver a PDD-XFR_SDU. 4.3.6 PDD-XFR SERVICE PARAMETERS The parameters for the PDD-XFR Service primitives are described below. a) PDD-XFR_SDU The PDD-XFR service-data-unit. A PDD-XFR_SDU is a delimited, fixed-length data unit, consisting of an integral number of octets. The content and format of a PDD-XFR Unit are not further specified by the CCSDS. b) PDD Status Field The CCSDS Transfer Frame First Header Pointer Field and three other bits of the Transfer Frame Status Field: the Packet Order Flag (1 bit) and Segment Length ID (2 bits). These are undefined by CCSDS when a Virtual Channel is used to transfer PDD. They may (optionally) be used to convey information on the validity, sequence, or other status of the data in the PDD-XFR_SDU. Provision of this field is mandatory; semantics are user-optional. c) GVCID The GSCID (see reference [3]) concatenated with the Virtual Channel Identifier (VCID). CCSDS 103.0-B-2 Page 4-8 June 2001

4.3.7 DETAILED PDD-XFR SERVICE SPECIFICATION 4.3.7.1 General This subsection describes in detail the primitives and parameters associated with the PDD- XFR Service. The parameters are specified in an abstract sense and specify the information to be made available to the user of the primitive. The way in which a specific implementation makes this information available is not constrained by this specification. 4.3.7.2 PDD-XFR.request a) Function: The PDD-XFR.request primitive is the service request primitive for the PDD-XFR Service. b) Semantics: The PDD-XFR.request primitive shall provide parameters as follows: PDD-XFR.request (PDD-XFR_SDU, PDD Status Fields) c) When Generated: The PDD-XFR.request primitive is passed to the Space Transfer layer from the PDD-XFR user at the sending end to request that the PDD-XFR_SDU be transferred. d) Effect on Receipt: Receipt of the PDD-XFR.request primitive causes the Space Transfer layer to transfer the PDD-XFR_SDU. e) Additional Comments: 1) The PDD-XFR.request primitive is used to transfer PDD units across the space link. 2) The functions performed at the sending end when the PDD-XFR.request primitive is sent are summarized below. This functional overview is not part of this Recommendation; see 5.3 in Packet Telemetry, reference [1]. Functions include: create and number a partial VC_Frame; insert PDD into Frame Field, and PDD Status Field into frame header. These are components of a Transfer Frame, and are collectively referred to in this Recommendation as a partial VC_Frame. CCSDS 103.0-B-2 Page 4-9 June 2001

4.3.7.3 PDD-XFR.indication a) Function: The PDD-XFR.indication primitive is the service indication primitive for the PDD- XFR Service. b) Semantics: The PDD-XFR.indication primitive shall provide parameters as follows: PDD.indication (PDD-XFR_SDU, Status Fields, GVCID, Virtual Channel Frame Count) c) When Generated: The PDD-XFR.indication primitive is passed from the Space Transfer layer to the PDD Service user to deliver a PDD-XFR_SDU. d) Effect on Receipt: The effect of receipt of the PDD-XFR.indication primitive by the user of the SP- XFR is undefined. e) Additional Comments: 1) The PDD-XFR.indication primitive is used to deliver PDD units to the PDD- XFR user sink application process(es) identified by managed information at the receiving end. Virtual Channel Frame Count provides the means to determine if data has been lost. 2) The functions performed at the receiving end before the PDD-XFR.indication primitive is sent are summarized below. This functional overview is not part of this Recommendation; see 5.3 in Packet Telemetry, reference [1]. Functions include: accept VC_Frames from the layer below; extract Frame Field, and PDD Status; deliver extracted fields with GVCID and Virtual Channel Frame Count. CCSDS 103.0-B-2 Page 4-10 June 2001

4.4 VIRTUAL CHANNEL FRAME SECONDARY HEADER SERVICE 4.4.1 OVERVIEW OF VC_FSH SERVICE The VC_FSH Service is a unidirectional (one way, space to ground) service which provides synchronous transfer of fixed-length FSH in each frame on the Virtual Channel (see figure 4-6). The transfer is synchronized with the release of VC_Frames for transfer in the Master Channel. The service is sequence preserving, but completeness is not guaranteed. Gaps in a sequence of FSHes can be detected by the receiving-end user. NOTES 1 VC_FSH Service and MC_FSH Service are mutually exclusive. 2 Synchronization of the VC_FSH values to be transferred with the release of VC_Frames is user-optional. It is the responsibility of each implementation (i.e., each spacecraft) to assure that the timing requirements for the FSH are met, and that the time of measurement of data carried in the FSH can be determined, if necessary. 4.4.2 DEFINITIONS AND ABBREVIATIONS For the purposes of this Service Definition, the following definitions and abbreviations apply: a) VC_FSH_SDU an FSH to be sent on a particular Virtual Channel; b) sending VC_FSH user an on-board source of VC_FSH_SDUs to be transferred; c) receiving VC_FSH user a sink for VC_FSH_SDUs on the ground; a process that receives all VC_FSHes of a particular Virtual Channel on the ground; d) VC_FSH SAP service-access-point for VC_FSH Service on a particular Virtual Channel. CCSDS 103.0-B-2 Page 4-11 June 2001

On-Board System (Sending End) Ground System (Receiving End) Source Sink VC Frame Secondary Headers VC Frame Secondary Headers FSH Transfer Function VCi D Space Transfer Layer FSH Transfer Function VCi VC Partial Frames VC Partial Frames Lower layers provide transfer to ground Layers C,B,A Legend Layer Entity Function providing service SAP for service fff nnn Entity Name Other Layer Functions (not identified) Figure 4-4: VC_Frame Secondary Header Service CCSDS 103.0-B-2 Page 4-12 June 2001

4.4.3 VC_FSH SERVICE SDU 4.4.3.1 VC_FSH Service is modeled as a buffer at the sending-end VC_FSH SAP, the contents of which are transferred to the corresponding VC_FSH SAP on the ground. There shall be only one buffer for VC_FSH Service on a given Virtual Channel. This model is illustrated in figure 4-7. Sending VC-FSH User Receiving VC-FSH User Buffer VC_FSH Provider Buffer contents are transfered once per VC_Frame Transfer from buffer at sending end to receiving end Figure 4-5: Abstract Model of VC_FSH Service 4.4.3.2 This model implies that a) exactly one VC_FSH_SDU is sent per VC_Frame. Its value is the content of the buffer at some time between release of successive VC_Frames; b) the VC_FSHes sent by an on-board source are transferred in order; c) the time relationship between placing a new value of the VC_FSH in the buffer, and release of a VC_Frame is not specified; i.e., the timing, polling, or synchronization scheme used to coordinate between VC_FSH source and the VC_FSH Service provider is mission specific. 4.4.4 PREREQUISITES FOR VC_FSH SERVICE 4.4.4.1 The VC_FSH Service requires VC_Frame Service from the layer below (see 5.2). VC_FSH Service also requires the specification of managed parameters, which serve to establish associations between space and ground protocol entities, specify address mappings, provide access authorization, and define operating limits. CCSDS 103.0-B-2 Page 4-13 June 2001

4.4.4.2 Managed parameters for VC_FSH Service include a) whether the Virtual Channel is to provide VC_FSH Service; b) which application is authorized as the source of VC_FSH data on the Virtual Channel providing the service; c) fixed length of the FSH on the Virtual Channel; d) implementation-specific parameters for timing, latency, or flow control. 4.4.4.3 Neither this Recommendation nor reference [1] specifies methods, procedures, or formats for providing these managed parameters. 4.4.5 SERVICE PRIMITIVES OF THE VC_FSH SERVICE The service primitives associated with this service are a) VC_FSH.request The FSH.request primitive is passed from the user of the VC_FSH Service at the sending end to the VC_FSH SAP to request that a VC_FSH_SDU, structured as an FSH, be placed into the FSH buffer on the specified Virtual Channel. b) VC_FSH.indication The FSH.indication is passed from the Space Transfer layer at the receiving end to the VC_FSH user to deliver an FSH_SDU. 4.4.6 VC_FSH SERVICE PARAMETERS The parameters for the VC_FSH Service primitives are described below. a) VC_FSH_SDU The VC_FSH service-data-unit. An FSH_SDU is a fixed-length data unit consisting of an integral number of octets. b) Virtual Channel Frame Count The Virtual Channel Frame Count of the Transfer Frame carrying a VC_FSH. CCSDS 103.0-B-2 Page 4-14 June 2001