Page de signatures électroniques / Electronic Signatures Page

Transcription

1 Page de signatures électroniques / Electronic Signatures Page Information Documentaire / Document Information Titre / Title : Auteur / Author : Reference : This document has been digitally signed and timestamped. To verify signatures validity, please refer to procedure and tools available on web site pki.thalesaleniaspace.fr/pki/ By default, signatures validity is unknown. The? icon is present on each signature. After verification, the? icon disappears if signature is valid. Last product update: july Tous droits réservés Thales Alenia Space All rights reserved

2 Page laissée blanche intentionnellement Blank page intentionally left Tous droits réservés Thales Alenia Space All rights reserved

3 ISSUE : 1.3 PAGE : 1 /35 TOTAL PAGES : 35 PFLP SPECIFICATION & UTILISATION Rédigé par/written by Responsabilité-Société/Responsibility-Company Date Signature Equipe PL/BC DPL/BC Vérifié par/verified by A. MOLLIER DPL/BC O. LEONETTI DPL/BC Approbation/Approved S. SALIOU AIT SAT S. VINAY Chef de service bancs de tests Cannes Entité Emettrice : Service IUGR/DPL/BC (détentrice de l original)

4

5 ISSUE : 1.3 PAGE : 3 /35 ENREGISTREMENT DES EVOLUTIONS / CHANGE RECORDS ISSUE DATE : DESCRIPTION DES EVOLUTIONS : CHANGE RECORD REDACTEUR AUTHOR /04/97 Création du document O. REGNAULT /02/04 Ajout paragraphe " Crypted Service for TC Packets" pour C. CARRERE envoi de commandes cryptées /03/07 Ajout paragraphe " Expedited Service for encrypted TC C. CARRERE Segments " pour envoi de commandes avec Segments cryptées (0x95) 1.3 Ajout du message TM paquet (0x56) M. BEN AMMAR

6 ISSUE : 1.3 PAGE : 4 /35 TABLE DES MATIERES 1. INTRODUCTION GENERAL SCOPE GLOSSARY OF TERMS DOCUMENTS APPLICABLE DOCUMENTS REFERENCE DOCUMENTS GENERAL DESCRIPTION PFLP PROTOCOL SPECIFICATIONS THE THREE STAGES OF THE PFLP PROTOCOL : PFLP MESSAGE STRUCTURE Header Data Trailer GENERAL MESSAGES Acknowledgement Message Status Message SERVICE START Service request Service request response DATA DISTRIBUTION Data distribution TM Data Distribution Request TM Data Distribution Response Stop of Data Distribution Request Stop of Data Distribution Response SERVICE END Service End Request Service End Request Response Service Close TELEMETRY MESSAGES TM SOURCE PACKET TM PACKET TM PACKET TM TRANSFER FRAME TELEMETRY DATA MESSAGE, USER DEFINED : STATUS ONLY TELECOMMAND MESSAGES STANDARD SERVICE FOR TC PACKETS ENCRYPTED SERVICE FOR TC PACKETS SEQUENCE-CONTROLLED SERVICE FOR TC PACKETS SEQUENCE-CONTROLLED SERVICE FOR TC PACKETS : AUTHENTICATION BY OCOE EXPEDITED SERVICE FOR TC PACKETS SEQUENCE-CONTROLLED SERVICE FOR TC SEGMENTS...29

7 ISSUE : 1.3 PAGE : 5 / EXPEDITED SERVICE FOR TC SEGMENTS EXPEDITED SERVICE FOR ENCRYPTED TC SEGMENTS TC PACKET DIRECTIVES TC PACKET - TC SEGMENT - DIRECTIVE ACKNOWLEDGE TC PACKET - TC SEGMENT - DIRECTIVE REPORT SERVER TO CLIENT REPORT...34

8 ISSUE : 1.3 PAGE : 6 /35 1. INTRODUCTION 1.1. GENERAL 1.2. SCOPE This document provides a detailed description of the Packet Front-End Link protocol (PFLP) which is a Packet TM/TC exchange protocol that is applied to EGSE equipment. This protocol permits the direct TM/TC Source- Packet distribution between the TMTC SCOE and other EGSE equipment s. It is utilising the widely accepted TCP/IP communication protocol suite. The protocol can be implemented on many different hardware platforms that are commercially available and support a wide variety of operating systems. The TCP/IP protocols are accessed through Berkeley 4.3 stream sockets on which the PFLP protocol is implemented. Chapter 1 is a general introduction of this document. Chapter 2 lists all the applicable and reference documents. Chapter 3 gives an overview of the system implementation. Chapter 4 lists all the specifications for PFLP implementation. Chapter 5 lists the TM related data messages. Chapter 6 lists the TC related data messages GLOSSARY OF TERMS AIT : Assembly, Integration and Test EGSE : Electrical Ground Support Equipment LAN : Local Area Network OCOE : Overall Check Out Equipment SCOE : Specific Check Out Equipment SVT : System Verification Test TTC : Telemetry and TeleCommand

9 ISSUE : 1.3 PAGE : 7 /35 2. DOCUMENTS 2.1 APPLICABLE DOCUMENTS The following documents form part of this specification. They are basically applicable in their entirety unless when dedicated restrictions or deviations are explicitly specified in the present document. In case of conflict between an applicable document and this specification, the last one shall have precedence. Any discrepancy shall be notified to Aerospatiale for clarification and resolution. None 2.2 REFERENCE DOCUMENTS PFLP Protocol Specification SSBV-MSG.SAT.SA.DS.0006 Rev : draft Issue 2 ; February 3rd 1996 PFLP Protocol Utilisation SSBV-MSG.SAT.SA.DS.0007 Rev : draft Issue 1 ; June 17th 1996 TM & TC SCOE AIT SPACEBUS 3000B TLM.ST SCH Rev : c ; September 20th 1996

10 ISSUE : 1.3 PAGE : 8 /35 3. GENERAL DESCRIPTION The Telemetry and Telecommand SCOE is used in the frame of Assembly, Integration and Tests of a satellite. Ocoe X25/RS232 link with ground station EGSE LAN Power TM/TC RF Power Video signal RF link Spacebus 3000B Spacecraft Figure 1 : Overview of the EGSE architecture The OCOE is the central command and control equipment of the EGSE. It performs the following major functions : parameter acquisition, health and safety monitoring, commanding, automatic execution of test sequences, data logging and archiving. The OCOE interfaces all the other SCOEs via the Ethernet EGSE LAN. The different SCOEs are in charge of interfacing the spacecraft on each different functional entity. The TMTC SCOE interfaces the TTC subsystem and is in charge of : reception, demodulation of the telemetry (baseband signal), transfer frame extraction, source packet reconstitution, datation and distribution of selected data (transfer frame or source packet) to the OCOE, generation and transmission of telecommands. The TMTC SCOE is nominally controlled by the OCOE, but could be controlled on the SCOE itself. The SVT test objective is to verify that the ground segment databases are compliant with the one defined and used in AIT. During this test, the digital bitstream of the telemetry and Telecommand signals are routed via an X25 network or an RS232 interface to/from the TMTC SCOE.

11 ISSUE : 1.3 PAGE : 9 /35 4. PFLP PROTOCOL SPECIFICATIONS The OCOE interfaces the SCOEs by the EGSE Ethernet (thin wire) LAN. The network addressing and management shall use the Internet Protocol. The IP addresses shall be parameters of the implemented SCOE software. The specific application for communication between the SCOE and the OCOE shall be based on TCP stream sockets that shall be parameters of the implemented SCOE software. Actual sockets defined for the TMTC SCOE are 30xx for the telemetry service and 30xx for the telecommand service. The telemetry service enables multiple connections whereas the telecommand service is for the exclusive use of the OCOE. 4.1 THE THREE STAGES OF THE PFLP PROTOCOL : The three stages of the PFLP Protocol involves the transfer of PFLP messages through the TCP/IP sockets. Next figure shows the operations that are performed during the three stages : I CLIENT CLIENT message : Service Request message : Service Response SERVER SERVER CLIENT message : Data Distribution SERVER CLIENT message : Data Distribution Response SERVER II CLIENT CLIENT message : Data transfer optional message: Acknowledgement SERVER SERVER CLIENT message : Stop Data Distribution SERVER CLIENT message : Stop Data Distribution Response SERVER CLIENT message : Service End Request SERVER III CLIENT CLIENT message : Service End Response message : Service Close SERVER SERVER Figure 2 : Operations involved with the three stages of the PFLP Protocol.

12 ISSUE : 1.3 PAGE : 10 /35 The three stages of the protocol are : Service start where the client asks for the availability of the service (I) The Data distribution where the server and client exchange data (II) Service close where the client stops the service (III) 4.2 PFLP MESSAGE STRUCTURE The main purpose of PFLP is to allow for TM and TC Packets exchange between two systems connected via LAN, that support the TCP/IP protocol suite. The protocol is structured in such a way that Packets are transferred without any changes. This is achieved by the attachment of an information header and optional trailer that contain additional information required for proper routing and processing of the Packets. This complete data structure is referred to as a PFLP message. The header contains a number of fixed fields that can be used to identify and allow further processing of the Packet. Following the header, a complete (unchanged) Packet is embedded into the message. The Packet can have a maximum length of Bytes as dictated by the Packet Telemetry Standard ( bytes of data + 6 bytes of Packet header) although the protocol definition would allow larger data structures to be transported. After the Packet, an optional trailer can be present that can be used for several purposes : Packet reconstruction information Time synchronisation and correlation Specific system information Reserved & future applications Header The PFLP Header consists of a fixed number of 24 bytes split up in several fields whose minimum length is one byte. The fields in the header have been carefully grouped such that they may be manipulated with ease by 8, 16, 32, or 64 bit processors. The detailed structure of the PFLP header is depicted in the figure below : Size Offset Description Message ID 1 0 Identification of the message Remaining length 3 1 Length of the message excluding the first 4 bytes Trailer presence 1 4 Trailer offset 3 5 PFLP Version 1 8 System ID 1 9 Message Sequence Count 2 10 One independent counter is used by each connection. Data quality indication 1 12 Filled only for TM message. 0x00 otherwise.

13 ISSUE : 1.3 PAGE : 11 /35 Sequence quality indicator 1 13 Filled only for TM message. 0x00 otherwise. Message Acknowledgement 1 14 A non-zero value will provoke a Request transmission of a message Acknowledgement. Reserved 1 15 Time Code 8 16 Filled with the TM time or the message creation time. Figure 3 : PFLP Message Structure Message ID In order to support a number of different messages with different purpose, a PFLP message starts with a one byte message identifier. This ID can be used to make a distinction between different control, status and data messages. Remaining Message length The message length is a three-byte length field indicating the remaining length of the message including the remaining header fields, data and trailer. Trailer presence information The one-byte trailer presence information field, is currently only used to indicate whether a trailer is present or not, but can be expanded as future extensions evolve. Trailer Offset A three-byte trailer offset is used to indicate the start of the optional trailer with respect to the first byte of the message header. PFLP Version Number This single byte field indicates the version of PFLP that is being used by the messages. The current version number is 0x10. System ID The single byte System Identification is a reference to the system that was responsible for the creation of the message. Message Sequence Count The message sequence count is a two byte counter that counts sequentially from 0 to and then wraps around. This allows incontinuities in the message to be detected. Due to the pipeline mechanisms that are inherent in most lower level protocols, it would be impossible to guarantee that a message being sent from one end of a communication link had the next overall sequence count without continuously flushing the received data. In order to prevent this problem occurring the following procedure shall be used for PFLP : Each message transmitter for each logical link, shall have its own message sequence count, to be incremented with the transmission of every message type. In order to correlate between requests and their corresponding responses, the message sequence count of the request shall be included in the data field of response messages. Data quality

14 ISSUE : 1.3 PAGE : 12 /35 The one-byte data quality field provides an indication of the data quality of the embedded Packet. This quality information is linked to the error detection and correlation codes as well as other system dependant data quality identifiers and is related to Telemetry rather than Telecommands. This field will only be supported for the Telemetry data messages. For other messages, this field will be set to zero. Sequence Quality Indication The one-byte Sequence Quality Indication field indicates whether the sequence in which Packets were received by the system responsible for generation / decommutation maintained was correct or incorrect. This field, therefore, indicates anomalies in the Source packet Sequence Counters. This field will only be supported for the Telemetry data messages. For other messages, this field will be set to zero. Message Acknowledge Request This one byte field allows the acknowledgement of critical messages to be requested. The acknowledgement allows several functions to be fulfilled : Acknowledgement of correct reception of a critical message, Indication of execution or use of data contained in a message, Indication of current operational status of a system (using request/response procedure). The value of message acknowledge request byte, indicates the nature of the requested response. Time Code The PFLP header includes an eight byte «Time Code» preceded by one reserved byte. These fields allow the use of two ESA supported time formats - CUC (CCSDS Unsegmented Time Code) and CDS (CCSDS Day Segmented Time Code). CUC is usually used for on-board spacecraft time keeping whereas the CDS format is encouraged for ground time stamping. The Time Code indicates the reception or creation time of the Source Packet embedded in the message Data The data field of a PFLP message can have a minimum length of 7 bytes and a maximum length of bytes for TM and TC Source Packet as dictated by the CCSDS & ESA packet standards. The complete data field is used to embed a Packet without any modifications to the contents or length of the Packet in question. The length of the data field is equal to the total length of the embedded Packet and can therefore vary for every message. It should be noted that the PFLP-Protocol specification allows for larger data structures to be transported. For the purpose of describing CCSDS and ESA related Packets the recommended length is however limited to bytes. For other types of implementations this length is not mandatory Trailer The optional trailer is directly attached to the last byte of the embedded Source Packet and can be used for several purposes. The trailer is the most flexible part of the PFLP protocol since it allows for system or application specific implementations still maintaining compliance to the PFLP protocol definition. Currently defined uses for the trailer are : Time correlation and synchronisation

15 ISSUE : 1.3 PAGE : 13 /35 Source Packet reconstruction information (bad fields within embedded Source Packet) Test/Debug information System specific codes/information The maximum length of the trailer is equal to the maximum length of the data field.

16 ISSUE : 1.3 PAGE : 14 / GENERAL MESSAGES Acknowledgement Message This message is sent by the TM/TC SCOE after the reception of an OCOE message in which the "Message Acknowledgement. Request" field is different from "0x00". Size Offset Values Message ID 1 0 0x42 Remaining length 3 1 0x16 System ID 1 9 Variable Message Sequence Count 2 10 filled and incremented Data quality indication x00 Sequence quality indicator x00 Message Acknowledgement x00 Request Reserved x41 Data xAA Status Message to be defined 4.4 SERVICE START Service request The TM/TC SCOE waits for a connection on two ports: one for the telemetry and one for the Telecommand. The first message received must be a «Service request» asking for a Telemetry or a Telecommand link. If not the connection will be closed by the TM/TC SCOE. With this message the endianity of the OCOE can be checked. The PFLP protocol uses little endian standard as the TM/TC SCOE uses the big endian standard. The TM/TC SCOE swaps bytes to decode correctly data encoded with more than one byte. Any TM/TC SCOE client shall do the same if its endianity is not «little endian».

17 ISSUE : 1.3 PAGE : 15 /35 Message ID 1 0 0x10 Remaining length 3 1 0x2A System ID 1 9 Variable Message Sequence Count 2 10 Start at 1, increment Reset to 1 after link close Data quality indication x00 Sequence quality indicator x00 Message Acknowledge Request xXX Reserved 1 15 Used as P-field for CDS time code Time Code 8 16 Variable Client description ASCII 16 bytes Service ID x0010 for TM 0x0020 for TC Endianity 4 42 depends on the endianity of the client 0x little endian 0x big endian Service request response Message ID 1 0 0x11 Remaining length 3 1 0x2A System ID 1 9 ID of the SCOE Message Sequence Count 2 10 filled and incremented Data quality indication x00 Sequence quality indicator x00 Message Acknowledge Request x00 Reserved 1 15 Used as P-field for CDS time code Server description ASCII 16 bytes Service ID answer 2 40 see next Endianity x The Service ID response could be : 0x0000 : for service granted ( the connection is accepted ) 0x0010 : ID not allowed

18 ISSUE : 1.3 PAGE : 16 /35 0x0030 : endianity not supported ( if the endianity is not 0x or 0x ) 0x0050 : protocol error ( the connection is rejected ) 4.5 DATA DISTRIBUTION Data distribution For the TM service, a Data Distribution Request is expected by the TMTC SCOE. The behaviour of the SCOE is composed of 5 steps : Step 1. After a service request, the TM/TC SCOE waits for a Data Distribution Request message including ONE filter only. Step 2. The TM/TC SCOE sends back a Data Distribution Response accepting or rejecting the request. Step 3. In case of reject, the TM/TC SCOE returns in the step 1. Step 4. In case of acceptance, the TM/TC SCOE will send the requested data units (frame or packet, one unit per message). If no telemetry signal is received, the TM/TC SCOE optionally transmits a periodical short message towards all the opened connections. Step 5. The transmission continues until the request by the user for the Stop of Data Distribution. In this case the TM/TC SCOE sends back a Stop of Data Distribution Response and returns to step 1. For the TC service, this message is not expected TM Data Distribution Request This message MUST be transmitted by the TM service user after a connection. It defines the data filter to use for CCSDS data selection. In case of PCM telemetry, the user must request transfer frame for any channel. Message ID 1 0 0x20 Remaining length System ID 1 9 Variable Message Sequence Count 2 10 Incremented from previous message Data quality indication x00 Sequence quality indicator x00 Message Acknowledge Request xXX Reserved 1 15 Used as P-field for CDS timecode Request ID x0001 (service start) Service level x0000 : source packet 0x0010 : TM packet 0x0020 : transfer frame Number of filter(s) x0001 Filter 4 30 See text after. The bytes are : 1st: manipulation code

19 ISSUE : 1.3 PAGE : 17 /35 2nd: group identifier 3 rd, 4th: data identifier The filter value depends on the service level : For transfer frame : The Group identifier defines the Virtual Channel ID. Data Identifier is not used. The manipulation code can be : «3» : request specific channel (VCID) «4» : request any channel (VCID) For source or TM packet : The Group identifier defines the Virtual Channel ID Data Identifier defines the Application ID. The manipulation code can be: «1» : request specific packet source (APID) from any channel (VCID) «2» : request specific packet source (APID) from a specified channel (VCID) «3» : request any packet source (APID) from a specified channel (VCID) «4» : request any packet source (APID) from any channel (VCID) TM Data Distribution Response Transmitted as a response to «TM Data distribution request». Message ID 1 0 0x21 Remaining length System ID 1 9 ID of the SCOE Message Sequence Count 2 10 filled and incremented Data quality indication x00 Sequence quality indicator x00 Message Acknowledge Request x00 Reserved 1 15 Used as P-field for CDS time code Request ID x0001 (service start) Request result x0000 : service accepted 0x0010 : service rejected Reason code x0000 : none 0x0010 : system not ready 0x0020 : data not supported 0x0030 : service level N/A 0x0040 : incorrect filter 0x0050 : bad request ID Stop of Data Distribution Request Request for the stop of all Data Distribution offered for this service

20 ISSUE : 1.3 PAGE : 18 /35 Message ID 1 0 0x22 Remaining length System ID 1 9 Variable Message Sequence Count 2 10 Incremented from previous message Data quality indication x00 Sequence quality indicator x00 Message Acknowledge. Request xXX Reserved 1 15 Used as P-field for CDS timecode Reason code x0000 = normal case 0x0010 = due to system error 0x0020 = due to protocol error

21 ISSUE : 1.3 PAGE : 19 / Stop of Data Distribution Response 4.6 SERVICE END Once a successful response has been sent from the server, all data distribution will be halted. New data distributions can still be started by using the Data Distribution Request messages. Message ID 1 0 0x23 Remaining length System ID 1 9 ID of the SCOE Message Sequence Count 2 10 filled and incremented Data quality indication x00 Sequence quality indicator x00 Message Acknowledge Request x00 Reserved 1 15 Used as P-field for CDS time code Request result x0000 (distribution stopped successfully) Service End Request Message ID 1 0 0x60 Remaining length System ID 1 9 Variable Message Sequence Count 2 10 Incremented from previous message Data quality indication x00 Sequence quality indicator x00 Message Acknowledge Request xXX Reserved 1 15 Used as P-field for CDS timecode Time Code 8 16 Variable Reason x0000 : Normal 0x0010 : due to system errors 0x0020 : due to protocol errors

22 ISSUE : 1.3 PAGE : 20 / Service End Request Response (byte s) Message ID 1 0 0x61 Remaining length System ID 1 9 ID of the SCOE Message Sequence Count 2 10 filled and incremented Data quality indication x00 Sequence quality indicator x00 Message Acknowledge x00 Request Reserved 1 15 Used as P-field for CDS time code Result x0000 : service ended successfully 0x0010 : system error 0x0020 : wrong request Service Close (byte s) Message ID 1 0 0x70 Remaining length System ID 1 9 ID of the SCOE Message Sequence Count 2 10 filled and incremented Data quality indication x00 Sequence quality indicator x00 Message Acknowledge x00 Request Reserved 1 15 Used as P-field for CDS time code

23 ISSUE : 1.3 PAGE : 21 /35 Reason code x0000 : not allowed 0x0010 : service terminated by user 0x0020 : system shutdown 0x0030 : system error 0x0040 : server to fail-safe state

24 ISSUE : 1.3 PAGE : 22 /35 5. TELEMETRY MESSAGES 5.1 TM SOURCE PACKET Transmitted as soon as a valid packet is available and matches the filter value. Message ID 1 0 0x50 Remaining length 3 1 variable (packet ) System ID 1 9 ID of the SCOE Message Sequence Count 2 10 filled and incremented Data quality indication 1 12 see text Sequence quality indicator x00 : sequence correct 0x10 : sequence error Message Acknowledge Request x00 Reserved 1 15 Used as P-field for CDS time code Time Code 8 16 CDS time code : date of the frame in which the packet starts Data variable 24 packet (header and data) Data quality indication is : Bit Number Signification PM demod PSK demod Bit synchroniser Viterbi decoder 0 not locked / not not locked / not not locked not locked / not used used used 1 locked locked locked locked Bit 5 Bit 4 Frame synchroniser state 0 0 Search 1 0 Control 1 1 Lock Bit 7 Bit 6 Reed-Solomon and CRC 0 0 Errors detected by CRC 0 1 Errors cannot be corrected by RS 1 0 No RS or CRC error 1 1 Errors detected and corrected by RS

25 ISSUE : 1.3 PAGE : 23 / TM PACKET Transmitted as soon as a valid packet is available and matches the filter value. Message ID 1 0 0x52 Remaining length 3 1 variable (packet ) System ID 1 9 ID of the SCOE Message Sequence Count 2 10 filled and incremented Data quality indication 1 12 see text in source packet definition Sequence quality indicator x00 : sequence correct 0x10 : sequence error Message Acknowledge Request x00 Reserved 1 15 Used as P-field for CDS time code Time Code 8 16 CDS time code : date of the frame in which the packet starts Data variable 24 packet (header and data) 5.3 TM PACKET Transmitted as soon as a frame is available and matches the filter value. Message ID 1 0 0x56 Remaining length 3 1 variable System ID 1 9 ID of the SCOE Message Sequence Count 2 10 filled and incremented Data quality indication 1 12 see text in source packet definition Sequence quality indicator x00 : sequence correct 0x10 : sequence error Message Acknowledge Request x00 Reserved 1 15 Used as P-field for CDS time code Time Code 8 16 CDS time code : date of the beginning of reception of first bit of the synchronisation pattern

26 ISSUE : 1.3 PAGE : 24 /35 Data variable 24 packet (header and data) 5.4 TM TRANSFER FRAME Transmitted as soon as a frame is available and matches the filter value. Message ID 1 0 0x53 Remaining length 3 1 variable System ID 1 9 ID of the SCOE Message Sequence Count 2 10 filled and incremented Data quality indication 1 12 see text in source packet definition Sequence quality indicator x00 : sequence correct 0x10 : sequence error Message Acknowledge Request x00 Reserved 1 15 Used as P-field for CDS time code Time Code 8 16 CDS time code : date of the beginning of reception of first bit of the synchronisation pattern Data variable 24 Frame with/without synchro. pattern, header and trailer 5.5 TELEMETRY DATA MESSAGE, USER DEFINED : STATUS ONLY This message is transmitted if no Telemetry is available and after a time-out which is defined locally. Message ID 1 0 0x57 Remaining length System ID 1 9 ID of the SCOE local set-up Message Sequence Count 2 10 filled and incremented Data quality indication 1 12 see text in source packet definition Sequence quality indicator x00 : sequence correct 0x10 : sequence error Message Acknowledge Request x00

27 ISSUE : 1.3 PAGE : 25 /35 Reserved 1 15 Used as P-field for CDS time code Time Code 8 16 CDS time code : date status generation

28 ISSUE : 1.3 PAGE : 26 /35 6. TELECOMMAND MESSAGES 6.1 STANDARD SERVICE FOR TC PACKETS Message ID 1 0 0x51 Remaining length 3 1 Variable System ID 1 9 Variable Message Sequence Count 2 10 incremented value from previous message Data quality indication 1 12 Variable Sequence quality indicator 1 13 Variable Message Acknowledge Request xXX Reserved 1 15 used as P-field for CDS timecode Time Code 8 16 time value Request ID 2 24 Virtual Channel Number to 63 MAP identifier to 63 TC Packet 6 to variable In this case, TC Packet received by the TM/TC SCOE is transmitted to the spacecraft according to the actual mode of the Packet Telecommand System (TM/TC SCOE). Three interfaces are offered, each providing a different service : Service 1 : Sequence-Controlled Service for TC Packets without Authentication of TC Segments by the TM/TC SCOE Service 2 : Sequence-Controlled Service for TC Packets with Authentication of TC Segments by the TM/TC SCOE Service 3 : Expedited Service for TC Packets SEQUENCE- CONTROLLED EXPEDITED AUTHENTICATION ON 2 3 AUTHENTICATION OFF ENCRYPTED SERVICE FOR TC PACKETS Message ID 1 0 0x94 Remaining length 3 1 Variable System ID 1 9 Variable Message Sequence Count 2 10 Incremented value from

29 ISSUE : 1.3 PAGE : 27 /35 previous message Data quality indication 1 12 Variable Sequence quality indicator 1 13 Variable Message Acknowledge Request xXX Reserved 1 15 Used as P-field for CDS timecode Request ID 2 24 Virtual Channel Number to 63 CLTU 6 to Variable In this case, TC Packet received by the TM/TC SCOE is transmitted to the spacecraft according to the actual mode of the Packet Telecommand System (TM/TC SCOE). Three interfaces are offered, each providing a different service : Service 1 : Sequence-Controlled Service for TC Packets without Authentication of TC Segments by the TM/TC SCOE Service 2 : Sequence-Controlled Service for TC Packets with Authentication of TC Segments by the TM/TC SCOE Service 3 : Expedited Service for TC Packets SEQUENCE- CONTROLLED EXPEDITED AUTHENTICATION ON 2 3 AUTHENTICATION OFF SEQUENCE-CONTROLLED SERVICE FOR TC PACKETS Message ID 1 0 0x80 Remaining length 3 1 Variable System ID 1 9 Variable Message Sequence Count 2 10 incremented value from previous message Data quality indication 1 12 Variable Sequence quality indicator 1 13 Variable Message Acknowledge Request xXX Reserved 1 15 Used as P-field for CDS timecode Request ID 2 24 Virtual Channel Number to 63 MAP identifier to 63 TC Packet 6 to variable

30 ISSUE : 1.3 PAGE : 28 /35 In this case, TC Packet received by the TM/TC SCOE is transmitted to the spacecraft with Sequence-Controlled Service. Two interfaces are offered, each providing a different service : Service 1 : Sequence-Controlled Service for TC Packets without Authentication of TC Segments by the TM/TC SCOE Service 2 : Sequence-Controlled Service for TC Packets with Authentication of TC Segments by the TM/TC SCOE SEQUENCE- CONTROLLED EXPEDITED AUTHENTICATION ON 2 Rejected AUTHENTICATION OFF 1 Rejected 6.4 SEQUENCE-CONTROLLED SERVICE FOR TC PACKETS : AUTHENTICATION BY OCOE Message ID 1 0 0x84 Remaining length 3 1 Variable System ID 1 9 Variable Message Sequence Count 2 10 incremented value from previous message Data quality indication 1 12 Variable Sequence quality indicator 1 13 Variable Message Acknowledge Request xXX Reserved 1 15 Used as P-field for CDS timecode Request ID 2 24 Virtual Channel Number to 63 MAP identifier to 63 TC Packet 6 to 28 variable In this case, TC Packet received by the TM/TC SCOE is transmitted to the spacecraft using the service 2 : Service 2 : Sequence-Controlled Service for TC Packets with Authentication of TC Segments by OCOE For security reasons the authentication process resides in the OCOE. Therefore, it is necessary to transfer the TC Packets in a slightly altered form, in which the Authentication Tail for each TC segment is inserted at the expected place in the Packet Data. OCOE has to perform the segmentation process as well as the authentication process before delivering the recomposed "altered" packet. SEQUENCE- CONTROLLED EXPEDITED AUTHENTICATION ON Rejected rejected AUTHENTICATION OFF 2 rejected

31 ISSUE : 1.3 PAGE : 29 / EXPEDITED SERVICE FOR TC PACKETS Message ID 1 0 0x81 Remaining length 3 1 Variable Trailer presence Trailer offset System ID 1 9 Variable Message Sequence Count 2 10 incremented value from previous message Data quality indication 1 12 Variable Sequence quality indicator 1 13 Variable Message Acknowledge Request xXX Reserved 1 15 Used as P-field for CDS timecode Request ID 2 24 Virtual Channel Number to 63 MAP identifier to 63 TC Packet 6 to variable In this case, TC Packet received by the TM/TC SCOE is transmitted to the spacecraft using the Service 3 ( Expedited Service). SEQUENCE- CONTROLLED EXPEDITED AUTHENTICATION ON 3 3 AUTHENTICATION OFF SEQUENCE-CONTROLLED SERVICE FOR TC SEGMENTS Message ID 1 0 0x8A Remaining length 3 1 Variable Trailer presence Trailer offset System ID 1 9 Variable Message Sequence Count 2 10 incremented value from previous message Data quality indication 1 12 Variable Sequence quality indicator 1 13 Variable Message Acknowledge Request xXX Reserved 1 15 Used as P-field for CDS timecode Request ID 2 24

32 ISSUE : 1.3 PAGE : 30 /35 Virtual Channel Number to 63 TC Segment 1 to 27 variable 249 In this case, TC Segment received by the TM/TC SCOE is transmitted to the spacecraft with Sequence- Controlled Service. Two interfaces are offered, each providing a different service : Service 1 : Sequence-Controlled Service without authentication of TC Segments by the TM/TC SCOE Service 2 : Sequence-Controlled Service with authentication of TC Segments by the TM/TC SCOE SEQUENCE- CONTROLLED EXPEDITED AUTHENTICATION ON 2 Rejected AUTHENTICATION OFF 1 Rejected 6.7 EXPEDITED SERVICE FOR TC SEGMENTS Message ID 1 0 0x8B Remaining length 3 1 Variable System ID 1 9 Variable Message Sequence Count 2 10 incremented value from previous message Data quality indication 1 12 Variable Sequence quality indicator 1 13 Variable Message Acknowledge Request xXX Reserved 1 15 Used as P-field for CDS timecode DATAFIELD Request ID 2 24 Virtual Channel Number to 63 TC Segment 1 to variable In this case, TC Segment received by the TM/TC SCOE is transmitted to the spacecraft using the Service 3 ( Expedited Service).

33 ISSUE : 1.3 PAGE : 31 / EXPEDITED SERVICE FOR ENCRYPTED TC SEGMENTS Message ID 1 0 0x95 Remaining length 3 1 Variable System ID 1 9 Variable Message Sequence Count 2 10 incremented value from previous message Data quality indication 1 12 Variable Sequence quality indicator 1 13 Variable Message Acknowledge Request xXX Reserved 1 15 Used as P-field for CDS timecode DATAFIELD Request ID 2 24 Virtual Channel Number to 63 Encrypted TC Segment 1 to variable In this case, TC Segment received by the TM/TC SCOE is transmitted to the spacecraft using the Service 3 ( Expedited Service). SEQUENCE- CONTROLLED EXPEDITED AUTHENTICATION ON 3 3 AUTHENTICATION OFF TC PACKET DIRECTIVES Message ID 1 0 0x82 Remaining length 3 1 Variable Trailer presence Trailer offset System ID 1 9 Variable Message Sequence Count 2 10 incremented value from previous message Data quality indication 1 12 Variable Sequence quality indicator 1 13 Variable Message Acknowledge Request xXX Reserved 1 15 Used as P-field for CDS time-

34 ISSUE : 1.3 PAGE : 32 /35 code Request ID 2 24 Virtual Channel Number to 63 Directive identifier 1 27 described next Parameter 0 to 4 28 Depends of Directive ID Service Requests from the Higher Layer management function are referred to here as "directives"; They are : 4 Initiate AD Service Directives 1 Terminate AD Service Directive 1 Resume AD Service Directive 5 FOP-1 Directives Furthermore, any other undefined Directive will be rejected and reported as an "Invalid" Directive. The 12 directives correspond to Events E23 through E40 in the FOP-1 State Table. Values of the Directive identifier are : 'I' Initiate AD Service (without CLCW check) Directive (no parameter) 'J' Initiate AD Service (with CLCW check) Directive (no parameter) 'U' Initiate AD Service (with Unlock) Directive (no parameter) 'K' Initiate AD Service (with SET V(R)) Directive Parameter = V(R) ; Size = 1 byte, Values = 0 to 255 'T' Terminate AD Service Directive (no parameter) 'R' Resume AD Service Directive (no parameter) 'V' Set V(S) TO V*(S) Directive Parameter = V(S) ; Size = 1 byte -,Values = 0 to 255 'S' Set FOP_Sliding_Window_Width (K) Directive Parameter = K ; Size = 1 byte -,Values = 1 to 255 '1' Set T1_Initial Directive Parameter = T1_Inital ; Size = 4 bytes -,Values = 1 to ms 'L' Set Transmission_Limit Directive Parameter = T_Limit ; Size = 1 byte -,Values = 1 to 255 'Y ' Set Timeout_type Directive Parameter = TT ; Size = 1 byte -,Values = 0/1 TT = 0, the FOP-1 generates an Alert Indication TT = 1, the FOP-1 suspends the AD service, which may be resumed later if so required Any other character simulate Invalid Directive (no parameter)

35 ISSUE : 1.3 PAGE : 33 / TC PACKET - TC SEGMENT - DIRECTIVE ACKNOWLEDGE Size Offset Values Message ID 1 0 0x5B Remaining length 3 1 0x18 Trailer presence Trailer offset System ID 1 9 ID of the TM/TC SCOE Message Sequence Count 2 10 filled and incremented Data quality indication Sequence quality indicator Message Acknowledge Request Reserved 1 15 Used as P-field for CDS time code DATAFIELD Request ID 2 24 see below. TC Packet. TC Segment. Directive identifier Virtual Channel Number to 63 Answer 1 27 ACCEPT = 0 REJECT = 5 An Accept/Reject response returns after each request of TC Packet, TC Segment or Directive. The returned request ID is the one contained in the original PFLP message TC PACKET - TC SEGMENT - DIRECTIVE REPORT Message ID 1 0 0x5C Remaining length 3 1 0x18 Trailer presence Trailer offset System ID 1 9 ID of the TM/TC SCOE Message Sequence Count 2 10 filled and incremented Data quality indication x00 Sequence quality indicator x00 Message Acknowledge Request x00 Reserved 1 15 Used as P-field for CDS time code DATAFIELD Request ID. TC packet 2 24 variable

36 ISSUE : 1.3 PAGE : 34 /35. TC segment. Directive identifier Virtual Channel Number to 63 Answer 1 27 NEGATIVE CONFIRM = 6 POSITIVE CONFIRM = 0 A Negative/Positive Confirm response returns after each Accept response to transfer TC Packet or TC Segment with Sequence-Controlled Service Interface. A Negative/Positive response returns after each Accept response to Directive. The returned request ID is the one contained in the original PFLP message. This message is asynchronous with regards to the request messages SERVER TO CLIENT REPORT In some specific cases, the TMTC SCOE sends a message to the OCOE indicating a change in the state of the TC FOP status. Message ID 1 0 0x5A Remaining length 3 1 0x18 System ID 1 9 ID of the TM/TC SCOE Message Sequence Count 2 10 filled and incremented Data quality indication x00 Sequence quality indicator x00 Message Acknowledge Request x00 Reserved 1 15 Used as P-field for CDS time code DATAFIELD Information 2 24 described next Virtual Channel Number to 63 Answer 1 27 described next

37 ISSUE : 1.3 PAGE : 35 /35 Alert Indications Suspend Indications Answer ALERT = 12 SUSPEND = 13 Information ALERT_SYNCH = 0x0001 S1 = 0x0001 ALERT_CLCW = 0x0002 S2 = 0x0002 ALERT_LIMIT = 0x0003 S3 = 0x0003 ALERT_NNR = 0x0004 S4 = 0x0004 ALERT_LOCKOUT = 0x0005 S5 = 0x0005 ALERT_LLIF = 0x0006 ALERT_TERM = 0x0007 DOCUMENT