How would optics fit in CCSDS Stack? Which Cross Support Services should be picked up by the IOAG Catalogs? G.P. Calzolari (SLS Area Director) CCSDS Spring 2012 Meetings 16 April Version 0.9

Let’s remember CCSDS goal The goal:  For Space Data Systems, enhance interoperability and cross-support, while also reducing risk, development time and project costs, for government, industry, agencies, vendors and programs. Interoperability between agencies & teams translates to operational flexibility, capability and access to additional resources CCSDS Started in 1982 developing at the lower layers of the protocol stack. The CCSDS scope has grown to cover standards throughout the ISO communications stack, plus other Data Systems areas (architecture, archive, security, XML exchange formats, etc.)

Some Organizational Interrelationships Typical IOAG communiqué to CCSDS: IOP: Interoperability Plenary – highest level interagency agreements on space interoperability R 12.9.1 The IOAG requests the CCSDS: to initiate the transition to an end-to-end networked communications architecture by : developing a standard for CCSDS encapsulation service; developing the DTN suite as standards developing a recommended practice for the deployment of the IP suite. IOAG: Interagency Operations Advisory Group interoperable mission support infrastructure (Comm & Nav only) CCSDS: open international standards for space mission interoperability SFCG: Space Frequency coordination Group: space agency spectrum management forum OLSG IOAG OLSG: Optical Link Study Group Looking at Requirements for Optical Comms in Space

Layered approach in CCSDS This is where we are today (more or less ) SECURITY DATA COMPRESSION CFDP DTN-BP/BSP IPv6 IPv4 LTP Encap Space Packet Protocol AOS Services Till which layer shall Optical Comms go upward? Prox-1 TM, TC AOS Channel Coding and Sync DELTA DOR RF & Modulation PN RANGING RANGING SLS AREA

One year ago in Berlin we stated… CCSDS, starting from the Space Link Services Area, has been (and still is) very receptive to Optical Communications. In other words, SLS do care about Optical matters (thanks to Jean-Luc Gerner former SLS AD) as demonstrated by the existence of the OCM SIG. SLS favors the definition of standards in this field but stability is a key issue for standards and starting hazardous work should be carefully avoided for the best guarantee of success . Technical Analysis is a key factor to go into the right direction with large support and consolidated consensus. For the reasons above this workshop is an important event for discussion and future steps. 5

Near and Log Term Views/Catalogs For the near term, IOAG identified those services already defined or whose definition shall be accomplished “soon” with implied objective that the plurality of the IOAG agencies shall be capable of providing these services around 2015. Such a Catalog is “IOAG Service Catalog #1”. Mandatory and Optional Services have been identified. For the long term, IOAG specified an enhanced catalog covering end-to-end services and extending cross-support into space as driver for further CCSDS standardization efforts; i.e. “IOAG Service Catalog #2”. From a practical point of view, while IOAG Service Catalog #1 addresses current mission scenarios where access is provided to a single space/ground data link, IOAG Service Catalog #2 addresses space communication services for in-space relay and network cross-support scenarios which would enable future Solar System Internetworking (SSI); i.e. Catalog #2 comprises typically Delay/Disruption Tolerant Networking (DTN) and / or Internet Protocol (IP) technologies. The Approach was: Document the current practice, Keep as simple as possible, Refer to CCSDS existing technical standards and point to standards to be written (with remarks about what they should contain). The Catalogs Do not define an associated operations concept, Do not define an associated architecture

Scenario for Service Catalog #1 CFDP, Space Packet and TM/TC/AOS Frame Standards Ground based Cross-Support Standards Ground Link Space Link A Spacecraft Ground Tracking Asset Control Center B IOAG Services

Scenario for Service Catalog #2 Space Link A B C Lander Control Center Ground Tracking Asset Spacecraft (Orbiter) Spacecraft (Lander) Orbiter Ground Link This scenario is not (yet) relevant for Optical Comms.

Groups of IOAG Services in Catalog #1 The following groups of IOAG Services have been identified within IOAG Service Catalog #1. Each group includes several service types. Forward Data Delivery Services Group: these services allow transfer of data from a control center to a spacecraft. Return Data Delivery Services Group: these services allow transfer of data from a spacecraft to a control center. Radio Metric Services Group: these services allow the results of radio metric measurements to be provided to a control center. In addition Service Management functions are defined. They allow for interaction between the space agencies in order to coordinate the provision of the above space communications and radio metric services. Moreover, these functions allow the radio link status to be provided to a control center. Presently, for OCM we should only care about Return Services

Core Services in Catalog#1 IOAG Service Catalog #1 has identified the following IOAG “core” services (the relevant implied core Ground Link Interface standards appear in parentheses). Forward CLTU Service (SLE Forward CLTU) Return All Frames Service (SLE Return All Frames) Return Channel Frames Service (SLE Return Channel Frames) Validated Data Radio Metric Service (CSTS Offline Radio Metric, over CSTS File Transfer) The first 3 services above are fully implemented since they rely on the draught-horses of cross support. The "most traditional" level of Return Services is at frame level. Not at "lowest level" because of the Return Unframed Telemetry Service but surely at “lowest level among the existing services”. As long as you can use those two services the interface between a ground station and a control center can be used immediately "as is".

Extended Return Services in Catalog#1 Some of the Extended Services rely on standards available but not commonly supported by all agencies (e.g. FSP and R-OCF), other ones address standardization activities in evolution. The following Extended Return Services are defined: Return Operational Control Field Service (SLE Return OCF, existing) )  only needed for TC Support (i.e. for COP-1 ARQ) Return Unframed Telemetry Service (CSTS Return Unframed Telemetry)  no format TM Return File Service (CSTS Return File, over CSTS File Transfer) )  it allow performing a terrestrial file transfer for data received through the space link in form of Space/Encapsulation packets or CFDP files The Return File Service can be seen as a valid alternative to support Optical Communications, but it lacks full implementations. Optical Communications could eventually be the pushing factor for the implementation or Return File Services.

How do IOAG Services Work? A given IOAG Service can be built on top of a number of combinations of Space Link Interface standards and Ground Link Interface standards. Both types of standards rely on Data Structure standards. While OCM is certainly going to “operate” on (all or a subset of) the Standards in the second column, you will have no (short term) influence on those in the third column. The obvious suggestion for Optical Communications is therefore to foresee usage of the current SLE Standards.

Which impact keeping Return All Frames (RAF) and Return Channel Frames (RCF)? You need to maintain the frame structure defined either in CCSDS 132.0-B TM Space Data Link Protocol. Blue Book or the one in CCSDS 732.0-B AOS Space Data Link Protocol Blue Book. Note that both standards limit the frame length to about 2048 octets. Actually the main constraint is on frame length, but keeping the structure allows better accountability (e.g. lost frames, VC demultimplexing, etc.) Conversely you can modify the details for the Synchronization and Channel Coding sublayer and for the Physical layer. This is quite logical as the implementation behind the interface (the so called "production") will need to handle optical parameters instead of the traditional one and this will imply changes confined to the station. This would be my recommendation at least in first analysis.

However something shall be taken into account: e.g. data rates. RAF and RCF have some limitations about the amount data can be immediately delivered online from a Station to a Control Center. The data throughput is currently limited by terrestrial line capacity as well as by sending and receiving systems. To avoid loosing data when the Telemetry data rates exceed the terrestrial line capacity, those services can be carried out also in offline delivery mode. To give you some numbers, the SLE-API software shows a theoretical limit of 700 Mbps excluding frame encoding overhead but including SLE protocol overhead etc. (i.e. a real limit around 90-95% of this figure). This is assuming unlimited processing capability by sending and receiving systems as well as a suitable terrestrial line capacity. Therefore it looks very reasonable to assume that – for optical downlinks - those services (at least initially ) will not be used in online mode but rather in offline (i.e. store and retrieve later "slowly").

More considerations about rates The frame format defined by both CCSDS 132.0 & 732.0 is limited to about 16 kbits (i.e. about 2048 bytes). Such a size can imply a very high frame rate for optical bit rates. If the frame rate becomes very high the time available to decode a frame till the next one is received will be very short. In case the optical decoding hardware is not fast enough you shall either decode offline ( higher storage requirements as you shall store the coded bitstream) or increase the frame size. This means deciding between unlimited latency or defined latency. The latter solution would require new standards for the Data link protocol sublayer and new cross support services. If the optical bit rate is extremely high, you may still risk to have too many data in a station without being able to deliver them timely to a control center even with offline delivery mode.

Alternatives Using only the Return All Frames service, one could cheat and use a frame structure different from CCSDS 132.0 & 732.0. However the frame length constraints still apply and therefore it does not look worth. Using the Return Unframed Telemetry service (that basically provides a bit stream to the user) frame structures different from CCSDS 132.0 & 732.0 and longer frame sizes could be used. However this service is not available yet and there are doubt it will be ready in "short“ time. The issue about avoiding online delivery would however remain.

What about using files? IOAG defines also a Return File Service. This Service allows a Ground Station to provide a Control Center with files received from a spacecraft. The Ground Station informs the Control Center whether the file contains a collection of Space Packets, or a collection of Encapsulation Packets, or a file reconstructed from CFDP PDUS that were embedded either in Space Packets or Encapsulation Packets. Note that a generic transfer file service allowing to transfer files between two units is also foreseen. Using CFDP to downlink files is an attractive option. Many components of the Return File service are not yet available. The capability to ask the Control Center to perform a CFDP retransmission request is not available. The possibility of compacting received frames into files is not directly foreseen. Therefore these are just future options to consider.

Conclusions IOAG Service Catalog #1 addresses the scenario relevant for Optical links. SLE Return All Frames Service and SLE Return Channel Frames Services exist and can satisfy the initial needs of an optical downlink. The possibility of modifying or adding SLE or CSTS services is unlikely and would require long time. Replacing current Telemetry RF and Coding standards would not impact the interface behavior of SLE Services. Therefore it is completely reasonable to limit the OCM work to the Synchronization and Channel Coding sublayer and to the Physical layer while using existing SLE Services taking into account possible limitations for e.g. usage limited to offline delivery mode, systems in line with frame rates imposed by present structures or unlimited latency, etc. Other solutions as e.g. new frame structures, usage of files, etc. can be considered now but addressed in future.

Thank you for your attention.