Why we need USLP Greg Kazz Ed Greenberg November 9-10, 2014 CCSDS Fall London Greg Kazz Ed Greenberg Question: Why the change of name from NGSLP to USLP? Answer: 1) In time the next generation will be the previous generation 2) This Protocol ties together the capabilities of all current CCSDS link layer protocols.

Evolving Space Communications Environment Development of very high rate Optical Communications Evolution of very small low cost space vehicles Small remote enterprises of communicating space entities (e.g. Multi-agency Mars enterprise) Manned missions’ utilization of Internet Protocols Growth of Delay Tolerant Network technology for use of selective retransmission and reliable link layer protocols. Flight technology to support high performance Forward Error Correcting Codes and VCM/ACM What’s next?

Emerging Requirements on Link Layer Higher Data Rates put increased pressure on current implementations and operational data handling and routing Larger number of space vehicles requires more spacecraft identifiers Inclusion of uplink security (SDLS) will require new flight implementations Advances in technology provides the means to improve uplink performance using improved codes and FPGA devices. Support reprogramming of Flight FPGAs systems Increased control command size due to inclusion of security NOTE: Significant advances in technology also provides the capability to incorporate regenerative ranging for improved tracking and spacecraft clock calibration.

How USLP addresses the future needs (1-2) Longer frames provides more efficient frame processing Greater number of Spacecraft Identifiers needed Independence of Coding and Framing protocol Provides for the use of high performance uplink FEC coding Provides a single protocol that can be used across all space links Allows direction insertion of other protocols (i.e. IP, DTN) into USLP frame, making internetworking more efficient. NOTE: A single protocol for all space links (DTE, DFE, cross-links) will reduce the number of protocols required for space missions and provides for broader use of firmware needed developments to support security and increased data rates.

How USLP addresses the future needs (2-2) Provides a variable length frame capability for all Links Duplicating TC and Proximity functionality Added capability for TM and AOS type links Utilizes VC IDs for MAPs/Ports in both TC and Prox Replaces TC Segmentation Mode Replaces Proximity Output Ports Offers an Optional Insert Zone Service to be used as needed For insertion of low latency commanding/status or ARQ reporting Can be used to duplicate current AOS functionality if required Eliminates the need for insertion of Idle Frames when performing AOS type operations. Supports Mission Need for more agile use of Coding Frame need not be coupled to code block allowing easy code change Supports commanding of physical parameters via USLP

USLP is designed to optionally provide the Data Link Services while residing transparently above the Space Link Coding and Synchronization sub-layer. Data Link Protocol Sub-layer (USLP) Coding and Synchronization Sub-layer Upper Layer Protocol (Including Session Control and Reliable Delivery) CCSDS Data Link Layer Physical layer Note: USLP explicitly defines the frame length in all frames to optionally decouple the relationship of the Space Link C&S Sub-Layer from the Data Link Protocol Sub-Layer.

Link Layer Services Transmitting (sending) Side Receiving Side Packets Packet Service VCA Service VCA Service User Units Packet Service Packets User Units Packets VCS SAP VCA SAP Form TFDFF_SDU Form VCF_SDU VCA SAP VCS SAP Extract Packets Extract Octets OCF Service Input Sub-layer Select VCF_SDU OCF_SDU VCS_SDU Separate GVCS_Frames Output Sub-layer TFDF_SDU (Transfer Frame Data Field) Virtual Channel (VC) Formulation Add VC Header and increment VC Counter Insert Received TFDF-SDUs Insert OCF Compute and Add Security Header and Trailer VC_Frame VC Frame (post security) Deliver Received and verified VC-Frames Check VC Continuity Perform Security Process Extract OCF Data Sub-layer VC_Frame Service Data Sub-layer Virtual_Channel_Frame Virtual_Channel_Frame MCF Service Merge VC Frames MC_Frame Separate VC_Frames Master_Channel_Frame Master_Channel_Frame Master Channel (MC) Formulation Merge Received VC_PDUs Insert Insert_PDU into Frame FEC Coding and Randomization Add Attached Sync Marker Insert SDU Separate VC_Frames Extract Insert SDU Separate MC_Frames Validate Frame using CRC when contained FEC Decoding and Derandomization Delimit code block(using ASM if required) Sync& Coding Sub-layer Sync& Coding Sub-layer MC_Frame Link_Transmission_Unit Link Transmission_Unit (ASM+VC_Frame) Merge MC Frames Physical Layer Physical Layer Physical Channel Symbol Stream Physical Channel Symbol Stream Physical Channel (PC) Formulation Merge Received MC_PDUs Add Idle/Idle Frames as required Physical Channel (PC) Reception Acquire symbols

USLP Transfer Frame Structures Header Version ID 3 bits Spacecraft 13 bits 6 Bits Virtual Channel ID Sequence Counter Value 0-56 Bits 16 Bits Frame Length 1 bit Destination or Source OCF Flag FECF Size 2 bits Length Insert Zone Included Behavior Unspecified Transfer Frame Header Transfer Frame Insert Zone Virtual Channel Security Header Virtual Channel Security Trailer Virtual Channel Operational Control Field Transfer Frame Error Control Field Transfer Frame Data Field (TFDF_SDU) Transfer Frame 6-13 Octets Variable Variable Variable 4 Octets Variable Mandatory Optional Optional Optional Optional Optional Optional MC Group VC Group Trailer Group Transfer Frame Data Field Transfer frame Data Field Header TFDF Data Zone VC Data Structure and Protocol fields Identifier Mandatory ! Optional Optional (only required for Stream Data) Optional CCSDS Space Packets Internet Datagrams DTN Bundles/Fragments User Octets Structuring Rules Contained Protocol ID Extended Contained Protocol ID First Header Pointer For packets Last valid octet for user defined data 3 bits 5 bits 8 bits 16 bits Variable

USLP Transfer Frame Header Version ID 3 bits Spacecraft 13 bits 6 Bits Virtual Channel ID VC Counter Value 0-56 Bits 16 Bits Frame Length 1 bit Destination or Source OCF Flag FECF Size 2 bits Length Insert Zone Included VC Counter Behavior Unspecified Version ID- is extended to 3 bits to accommodate an additional frame version after this one (110) is codified Spacecraft ID - allows for 8192 names Destination/Source - Identifies the Spacecraft ID as either the source of the data or the intended recipient Unspecified – A spare bit Virtual Channel ID – provides for 64 VC that can be divided into 4 groups Frame Length –(N+1) allows for frame to be as large as 65536 octets Transfer Frame Inset Zone Flag Frame Error Control Field – signals if a FECF is contained and its size in octets Operation Control Field Flag –signals the presence if an operational control field is present VC Counter Behavior Flag indicates whether there is a separate VC counter for each VC or only VCs 0-31 while VCs 32-63 share a single counter VC Counter Size – the contained value identifies the size of the VC count field– (size can be 0 to 7 octets) VC Counter Value –VC counter value field has a minimum size of 0 octet and a maximum size of 7 octets; This counter will increment for each VC or VC “Group” based on the VC Counter Behavior Flag value

Transfer Frame Data Field TFDF Header TFDF Data Zone VC Data Structure and Protocol fields Identifier Mandatory Optional (only required for Stream Data) Streaming Data Pointer CCSDS Space Packets Internet Datagrams DTN Bundles/Fragments User Octets Data Inclusion Rules Protocol ID Extended Protocol ID First Header Pointer For packets Last valid octet for user defined data 3 bits 5 bits 8 bits 16 bits Variable The organization of data within a VC is signaled within a VC header. Header identifies both the type of data unit contained and the data delimiting rules that apply. Identifies Protocol of User’s data (i.e. CCSDS Space Packets, Internet Datagrams, DTN Bundles or bundle segments, user octets) Streaming requires added header information for the VC service data unit. First header pointer Last valid user octet   Data Inclusion Rules Streaming Pointer Field (Optional based on Data Rules) ‘000’ Complete User Data units Not Required ‘001’ Streaming packets First Header Pointer ‘010’ Streaming User Octets Last Valid Octet in VC Data Field ‘011-111’ To be defined via SANA To be defined per defined rules Protocol ID ‘00000’ CCSDS Packets ‘00001’ IP Datagrams ‘00010’ DTN Bundle ‘00011’ User Octets ‘11111’ Field Extension

Computed and entered in frame and inserted into frame Transfer Frame Assembly Received from OCF 2 Computed and entered in frame 4 Received from SAP and inserted into frame Generated and entered into frame Calculated and entered into frame 1 3 Transfer Frame Security Header Transfer Frame Security Trailer 5 VC Frame Data Field (TFDF_SDU) VC Operational Control Field Transfer Frame Header TransferFrame Insert Zone Transfer Frame Error Check Field 6-10 Octets Variable Variable Variable Variable 4 Octets Variable Mandatory Optional Optional Optional Optional Optional Optional VC Contents Transfer Frame Note: The number within the circles identifies the order of inclusion in the frame formation process

Possible Modifications to USLP Add a “from” address field into frames to identify the source of the frame when Source/Destination set to Destination To inform recipient of source Possible use for a frame relay service Provide a Code Block Accountability capability for Link Analysis Include a 1 or 2 byte incrementing counter in the beginning of the code block data field (reducing the size of the data contained within the code block) providing a better mechanism for clock calibration when code block and frame are uncoupled. Other suggestions: Increase Version ID to 8 bits for compatibility with other format protocols (e.g. Internet, DTN) and allow all compatible formats to share the error free link provided by a CCSDS FEC code. Utilize a protocol like HDLC to delimit all data units without knowledge of data unit fields

Back-up

Coding Performance (not including short LDPC codes) (provided by JPL Coding Group) Rate ½ Block size 16 384 bits Rate ½ Block size 1024 1/2, 1024 LDPC with BCH TED LDPC Rate 4/5 Block size 16384 BCH SEC TED GSFC-LDPC (8176,7156)

Short Uplink Code Performance

Virtual Channel Processing Legend Packets VCA_SDUs TSDF_SDUs Note: -Packet SAP can support multiple users -VCA SAP can only support a single user Packet SAP VCA-SAP TSDF-SAP VC_OCF Service Data Unit Insert Zone Service Data Unit Packet Processing Function VCA Processing Function OCF-SAP OCF_SDUs VCF_SDUs Virtual Channel Creation Virtual Channel Processing Security Process Virtual Channel Processing CRC Creation Virtual Channel Data Unit (VCDU) Master Channel Process Master Channel Process (Virtual Channel Multiplexing) Master Channel Data Unit (MCDU) VCF-SDU = VC Data Field Legend All Channel Multiplexing Optional Process Multiplexer Coding and Sync Sub-Layer Process Physical Channel Replicated Processes