PACKET TELEMETRY SERVICES

1. PACKET TELEMETRYSERVICES PACKET TELEMETRY SERVICES

2. PURPOSE AND RELATIONSHIP TO OSI • To define the service of a packet telemetry system • To define a layered model of packet telemetry protocols • To specify the behavior at the service interfaces to each layer • The Packet Telemetry Services are defined in the style established by the OSI: • communications services are provided by layers of protocols • each layer provides a service interface to users of the service in the layer above • a service interface is defined in terms of primitives independent of specific implementation  abstract model for exchange data structure and control information PACKET TELEMETRY SERVICES

3. PACKET TELEMETRY LAYERS • To define services are used OSI concepts, but the Packet Telemetry PDUs are structured differently from those of OSI protocols  the Packet Telemetry layer are identified by letters (A to D). • The services specified are unidirectional: • the spacecraft can send, but not receive • the station on the ground can receive, but not send • These services are unconfirmed: • spacecraft does not receive confirmation that data it sends has been received  this avoid the delays involved in confirmed services • These services can be implemented as asymmetrical services  layers of subsystem in space and ground can be structured differently • The design is independent of services that could be provided PACKET TELEMETRY SERVICES

4. CCSDS Packet Telemetry Layers PACKET TELEMETRY SERVICES

5. TYPE OF PACKET TELEMETRY SERVICE • They are of two types: queued and buffered • Queued service: • each SDU from a sending user is placed in a FIFO queue • distinctive feature: all the data units from the sending user are transferred, and transferred only once (also if there are errors) • Buffered service: • each SDU from a sending user is placed in a buffer that can hold only one SDU; • his contents are sent at a time determined by the service (constant or aperiodic) • distinctive feature: it is TDM and the time of data transfer is driven by the service provider, not by the user; a particular data unit might be sent once,several times, or not at all PACKET TELEMETRY SERVICES

6. DATA SOURCE • The on-board data units, passed to the Space Transfer layer, are: • Source Packet(SP) • carries variable packet data field of an integral number of octets • provides source identification, sequence control for the packet data field and ancillary data (ex. time-tagging) • requires managed parameters (limit on the length, parameter for flow control…); methods,procedures, formats are not specified • Privately defined data (PDD) • are fixed length data units and with each PDD unit are provided PDD Status Field • requires managed parameters (addressing information, the fixed length of the PDD units…) PACKET TELEMETRY SERVICES

7. Frame Secondary Header (FSH) • is a data structure that carries fixed-length data; format or semantic are not specified, except for the FSH header • requires managed parameters (the fixed length, version number...) • Operational Control Field (OCF) • is a data structure that carries a 32-bit data unit • requires managed parameters (addressing information, OCF type...) • The specification of managed parameters serves to establish associations between space and ground protocol entities, specify address mappings, provide access authorization and define operating limits; methods, procedures or formats are not specified PACKET TELEMETRY SERVICES

8. LAYER D: SPACE TRANSFER LAYER • Provides access to four transfer service (space to ground or space to space) using a virtual channel VC • SP-XFR Service (Service Packet Transfer Service) • transfer a sequence of variable-length Source Packets from a source in space to one or more applications on the ground ( one way) • does not guarantee completeness, but can detect gaps in the sequence of data units delivered to a sink application • is modeled as a queued service linking the on board SP-XFR SAP for a given VC to the corresponding SP-XFR SAP on the ground; a separate queue exists for each VC • the source packets sent are transferred in order • the relationship of SP-XFR Service between two virtual channel is not specified PACKET TELEMETRY SERVICES

9. requires the specification of managed parameters ( which VC provides the SP-XFR Service, length of Frame Data Field, maximum Source Packet length…) • this service has the primitive SP-XFR.request to request the multiplation into the specified VC of the SP-XFR_SDU and the primitive SP-XFR.indication to deliver an SP-XFR_SDU PACKET TELEMETRY SERVICES

10. PDD-XFR Service (Privately Defined Data Transfer Service) • transfers PDD units (only one on a VC) of fixed-length and status field from a on board source to data sink on the ground ( one way, periodic and order preserving) • does not guarantee completeness, but signal gaps • is modeled as a queued service, one for each virtual channel, linking the on board PDD-XFR SAP to the corresponding PDD-XFR SAP on the ground; there is not multiplexing • the source packets sent are transferred in order • the time relationship between PDD-XFR_SDUs sent by different source on different VC is not specified • requires the specification of managed parameters ( which VC is to carry PDD, fixed length of Frame Data Field…) • this service has the primitive PDD-XFR.request to request that a PDD-XFR_SDU be transferred and PDD-XFR.indication to deliver a PDD-XFR_SDU PACKET TELEMETRY SERVICES

11. VC_FSH Service (VC Frame Secondary Header Service) • provides synchronous transfer (with the release of VC_Frame) of a fixed-length FSH in each frame on the VC • is a unidirectional service (space to ground) • is sequence preserving; it does not guarantee completeness, but signal gaps in a sequence of FSHes • is modeled as a buffer, the contents of which are transferred from the on board VC_FSH SAP to the corresponding VC_FSH SAP on the ground. There shall be only one buffer for VC_FSH Service on a given VC PACKET TELEMETRY SERVICES

12. the VC_FSHes sent by an on-board source are transferred in order • exactly one VC_FSH_SDU is sent per VC_Frame (its value is the content of the buffer at some time) • the time relationship between placing a new value of the VC_FSH in the buffer and release of a VC_Frame is not specified • requires the specification of managed parameters ( which application is authorized as the source of VC_FSH data on the VC providing the service, fixed length of FSH on the VC…) • this service has the primitive VC_FSH.request to request that a VC_FSH_SDU be placed into the FSH buffer and the primitive PDD-XFR.indication to deliver an FSH_SDU PACKET TELEMETRY SERVICES

13. VC_OCF Service (VC Operational Control Field Service) • provides synchronous transfer (with the release of VC_Frame) of a fixed-length OCF in each frame on the VC • is a unidirectional service (space to ground) • is modeled as a buffer, the contents of which are transferred from the on board VC_OCF SAP to the corresponding VC_OCF SAP on the ground. There shall be only one buffer for VC_FSH Service on a given VC • the OCFs sent by an on-board source are transferred in order • the time relationship between OCFs sent by different source on different VC is not specified • OCF values are transferred only when a VC_Frame is released  some value may be overwritten before they can be sent13, others may be sent more than once. Frequency transfer is not specified. PACKET TELEMETRY SERVICES

14. requires the specification of managed parameters ( which • application is authorized as the source of VC_FSH data on the • VC providing the service, whether the VC is to provide • VC_OCF Service …) • this service has the primitive VC_OCF.request to request that a VC_OCF_SDU be placed into the OCF buffer and the primitive PDD-XFR.indication used only on the ground to deliver an OCF to the layer above • The primitives of request are passed from the user of the service at the sending end to the specific SAP and their receipt causes the Space Transfer Layer to transfer the relative SDU • The primitives of indication are passed from the Space Transfer Layer at the receiving end to the specific user and the effect of their receipt by the user is undefined • All these four transfer services require VC_Frame Service from the layer below (layer C) PACKET TELEMETRY SERVICES

15. Examples of Space Transfer Layer Services PACKET TELEMETRY SERVICES

16. LAYER C: VIRTUAL CHANNEL ACCESS LAYER • Provides three services to the layer above using Master Channel Transfer Frames: • VC_Frame Service • provides the transfer of VC_Frames (VCF) from each of one to eight Virtual Channel over one Master Channel (MC) and may, or may not, contain FSH or OCF • is sequence preserving, but does not guarantee completeness • is a unidirectional service (space to ground) • is modeled as a queue linking the on board VCF SAP for a given VC to the corresponding VCF SAP on the ground; a separate queue exists for each VC • the VC_Frames sent are transferred in order • the time relationship among VC_Frames sent by different on board sources is not specified PACKET TELEMETRY SERVICES

17. requires the specification of managed parameters (use of Frame Error Control Field, presence of MC_OCF and/or MC_FSH, frame length …) • this service has the primitive VCF.request to request that a VCF_SDU be multiplexed into the specified MC and sent and the primitive VCF.indication to deliver a VCF_SDU PACKET TELEMETRY SERVICES

18. Receipt of VCF.request causes the Virtual Channel Access Layer to transfer the VCF_SDU • Receipt of VCF.indication realizes these functions: deblock, demultiplex packets from Frame Data Field, remove idle packet, generate quality indicators • MC_FSH Service (MC Frame Secondary Header Service) • provides transfer of a fixed-length FSH in each frame on the MC; the transfer is synchronized with the release of MC_Frame • is sequence preserving, but does not guarantee completeness • is a unidirectional service (space to ground) • MC_FSH Service and VC_FSH Service are mutually exclusive • is modeled as a buffer at the sending end MC_FSH SAP, the contents of which are transferred to the corresponding MC_FSH SAP on the ground PACKET TELEMETRY SERVICES

19. exactly one MC_FSH is sent per MC_Frame (its value is the content of the buffer at some time) • the time relationship between placing a new value of the MC_FSH in the buffer and release of a MC_Frame is not specified • requires the specification of managed parameters (which application is authorized to be the source of MC_FSH data, whether the MC is to provide MC_FSH Service …) • this service has the primitive MC_FSH.request to request that an MC_FSH_SDU be placed in the buffer to be sent and the primitive MC_FSH.indication to deliver an MC_FSH_SDU • Receipt of the MC_FSH.request causes the Virtual Channel Access Layer to replace the contents of the buffer • the effect of receipt of MC_FSH.indication by the user of MC_FSH Service is undefined • the MC_FSHes sent by the source are transferred in order PACKET TELEMETRY SERVICES

20. provides the transfer of a fixed-length OCF in each frame on the MC; the transfer is synchronized with the release of MC_Frame • is sequence preserving, but does not guarantee completeness • is a unidirectional service (space to ground) • MC_OCF Service and VC_OCF Service are mutually exclusive • is modeled as a buffer at the sending end MC_OCF SAP, the contents of which are transferred to the corresponding MC_OCF SAP on the ground • the MC_FSHes sent by the source are transferred in order • requires the specification of managed parameters (see point 2) • this service has the primitive MC_OCF.request to request that an MC_OCF_SDU be inserted into the Transfer Frame of a specified MC and sent and the primitive MC_FSH.indication to deliver an MC_OCF_SDU (see 2 for the effect on receipt) • MC_OCF Service (MC Operational Control Field Service) PACKET TELEMETRY SERVICES

21. The primitives of indication are passed from the Virtual Channel Access Layer at the receiving end to the specific user • The services of this layer require Channel Access Service from the layer below • A spacecraft can produce more than one MC  there are additional functions: • multiplex two or more MC into a constant-rate stream of Transfer Frame at the sending end • demultiplex two or more MC from a constant-rate stream of Transfer Frame at the receiving end In general: • The primitives of request are passed from the layer above at the sending end to the specific SAP PACKET TELEMETRY SERVICES

22. Example of structure PACKET TELEMETRY SERVICES

23. LAYER B: CHANNEL ACCESS LAYER • provides Channel Access ( CA) Service which realizes constant-rate transfer of a sequence of fixed-length Transfer Frames • is a unidirectional service (space to ground) with optional error detection/correction • is modeled as a queue at the sending end CA SAP, the contents of which are transferred synchronously and periodically to the corresponding CA SAP on the ground • unlike other queued services at higher layers, does requires timing relationship between the sending CA user and the CA layer  CA user must provide Transfer Frame at an average rate that will allow the CA Provider to maintain a constant symbol rate to the Physical Access layer below • The transfer Frame are transferred in order PACKET TELEMETRY SERVICES

24. requires Physical Access Service from the layer below and the specification of managed parameters as the fixed length of the Transfer Frames on the channel or, if any, the type of modulation and coding • primitives: • CA.request which is passed from the layer above at the sending end to the CA layer to request that a CA_ SDU be transferred (apply the possible type of coding); its receipt causes the CA layer to transfer the CA_SDU • The relationship with another downlink channel is not specified • CA.indication which is passed from the CA layer at the receiving end to deliver a CA_SDU; at its receipt are performed some function as demultiplex VC_Frame, check the Frame Error Control Field, decoding PACKET TELEMETRY SERVICES

25. Channel Access Service PACKET TELEMETRY SERVICES