1. 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.

2. 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?

3. 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.

4. 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.

5. 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

6. 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.

7. 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

8. 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 bits bits bits Variable

9. 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 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 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

10. 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 bits bits 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
‘ ’ 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

11. 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

12. 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

13. Back-up

14. Coding Performance (not including short LDPC codes) (provided by JPL Coding Group)
Rate ½ Block size 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)

15. Short Uplink Code Performance

16. 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