CCSDS Unified Space Data Link(USLP)

Greg KazzFeb. 18, 2015

SCaN Noon Time Talk

Purpose

• The Unified Space Link Protocol (USLP) is currently a Draft CCSDS Recommended Standard at the Data Link Layer to be used over all space communications links: space-to-ground, ground-to-space, and space-to-space.

Radio Frequency and Modulation

LinkARQ

TM Space DataLink Protocol

AOS Space DataLink Protocol

TC Space DataLink Protocol

CommunicationsOperation

Procedure 1

Space DataLink Security

Protocol

TimeCodes

LosslessData

Compression

LossyData

Compression

Reed-SolomonCoding

BCH CodingConvolutional

CodingTurbo & LDPC

CodingCode & Frame

Sync.CLTU and

PLOPs

Synchronous Links Asynchronous Links

Networked CCSDS Space/Ground Communications Protocol Stack

Physical

Link

Network

Transport

Application

Internet RFCDraft CCSDS RecommendationCCSDS Recommendation CCSDS Report

OnboardNavigation

Internet IPSecSCPS-SP Space Security Protocol

Space PacketProtocol

SCPS-NP Space Network Protocol

Internet Protocol(IPv4, IPv6)

Storeand

ForwardInteractive

SCPS-FPSpace FTP

InternetFTP

InternetTCP/UDP

SCPS-TPSpaceTCP/UDP

CCSDS File

DeliveryProtocol(CFDP)

Space PacketProtocol

Space PacketProtocol

On

bo

ard

Bu

s an

d L

AN

Sta

nd

ard

sO

nb

oar

d C

om

m

Sta

nd

ard

s

SO

IF:

Sp

acecra

ft O

nb

oard

In

terf

ace S

tan

dard

s

Sp

ace

Ap

p.

Sta

nd

ard

s

Proximity-1 Space Data Link Protocol

CommunicationsOperation

Procedure Prox

LinkARQ

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 Variable Code Modulation • 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 (CCSDS 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 (S/W Radios)– 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 future needs (1-2)Features Benefits

Provides a single link protocol used by flight and ground across all manned and robotic space links

• Applicable to large and diverse set of missions from ISS to Cubesats;

• Once implemented, reduces future development & testing from 4 to 1 protocol

Decouples the link framing from the channel coding

• Using S/W defined radios, missions may chose to swap in higher performing codes(~ 3 to 8 dB gain) during development or flight operations

Expands the number of Spacecraft CCSDS can identify to 8192; Makes them Transfer Frame version independent

• Existing name space is 75% full• Expectation is current ID space will

run out in the next 5-10 years due to small sat growth and slow attrition

Allows direct data delivery of other protocol data units (PDUs)

• USLP is more efficient using direct insertion requiring no encapsulation of IP Datagrams or DTN bundles

Up to 32X greater transfer frame size(64K bytes)

• Provides efficient transfer frame processing for high rate application including optical comm.

How USLP addresses future needs (2-2)

Features Benefits

Provides a variable length transfer frame for all links including AOS and TM applications

• Provides optional Insert Zone service for low latency commanding/ARQ without forcing every frame to carry it

• More efficient AOS type ops by eliminating Fill frame insertion

Utilizes Virtual Channels as addressable unit in all protocols

• Replaces MAPs in TC; Port IDs in Proximity-1

• Replaces TC and Prox-1 Segmentation

Master Channel Services are signaled (OCF, FECF, Insert Zone, TF length)

• MC Services no longer managed• Data driven approach allows for

more spacecraft control

Can support Variable Code Modulation

• Physical layer parameters (modulation type, etc) can be commanded via USLP much like Proximity-1

Comparison of USLP to AOS

Structural Elements AOS USLPFrame and Code block Alignment Fixed Fixed/Variable

Spacecraft Ids 256 8192

Sequence Counter Size Fixed (2.7e8) Variable (0-7e16)Virtual Channels 64 maximum 64 or

32 independent/32 dependent

Structural Aspects AOS USLPMaximum Frame Size (in Octets) 2048 65536Frame Size constraint Managed/Fixed Variable/SignaledVC-OCF Presence in VC Managed SignaledInsert Zone Presence Managed SignaledInsert Zone Size Fixed SignaledFrame Error Control Field Fixed Signaled

USLP

AOS6-8 OctetsMandatory

OptionalFixed

2 OctetsOptional

Variable

8 bits

Frame

USLP

AOS

FrameHeader

USLP AOS

Transfer Frame Data Field

USLP vs AOS Structures

USLP Transfer Frame Structures

VersionID

3 bits 3 bits

SpacecraftID

13 bits 6 Bits

Virtual Channel

ID

SequenceCounter

Value

0-56 Bits16 Bits

Frame Length

1 bit

Destinationor

SourceID

OCFFlag

1 bit

FECFSize

2 bits

SequenceCounterLength

1 bit 1 bit

InsertZone

IncludedFlag

Sequence CounterBehavior

Flag

1 bit

Unspecified

TransferFrameHeader

VirtualChannelSecurityHeader

Transfer FrameData Field

(TFDF_SDU)

VirtualChannelSecurityTrailer

VirtualChannel

OperationalControl Field

TransferFrame

Error ControlField

6-13 Octets 4 Octets VariableVariableVariable VariableMandatory Optional Optional OptionalOptional Optional

VC Group MC Group Trailer Group

TransferFrameInsert Zone

Optional

Transfer frame Data Field Header

VC Data Structure and Protocol fields Identifier Mandatory ! Optional

Structuring Rules

Contained Protocol ID

Optional (only required for Stream Data)

Optional• First Header Pointer For packets• Last valid octet for user defined data

3 bits 5 bits 8 bits 16 bits Variable

• CCSDS Space Packets• Internet Datagrams• DTN Bundles/Fragments • User Octets

TFDF Data Zone

TransferFrameHeader

TransferFrame

TransferFrame

Data FieldExtended

Contained Protocol ID

• 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

USLP Transfer Frame Header

VersionID

3 bits 3 bits

SpacecraftID

13 bits 6 Bits

Virtual Channel

ID

VCCounter

Value

0-56 Bits16 Bits

Frame Length

1 bit

Destinationor

SourceID

OCFFlag

1 bit

FECFSize

2 bits

VCCounterLength

1 bit 1 bit

InsertZone

IncludedFlag

VC CounterBehavior

Flag

1 bit

Unspecified

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.

1. Identifies Protocol of User’s data (i.e. CCSDS Space Packets, Internet Datagrams, DTN Bundles or bundle segments, user octets)

2. Streaming requires added header information for the VC service data unit. I. First header pointerII. 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

TFDF HeaderVC Data Structure and Protocol fields Identifier Mandatory

Data Inclusion Rules

Protocol ID

Optional (only required for Stream Data)Streaming Data Pointer

• First Header Pointer For packets• Last valid octet for user defined data

3 bits 5 bits 8 bits 16 bits Variable

• CCSDS Space Packets• Internet Datagrams• DTN Bundles/Fragments • User Octets

TFDF Data Zone

Transfer Frame Data Field

ExtendedProtocol ID

Protocol ID

‘00000’ CCSDS Packets

‘00001’ IP Datagrams

‘00010’ DTN Bundle

‘00011’ User Octets

‘11111’ Field Extension

USLP Summary• Greater number of Spacecraft require a larger Spacecraft ID field• Longer Frames reduce handling processing complexities at

higher rates• Higher rates require longer frame sequence counters for

accounting • Unifying the Link Layer Protocols would reduce development &

maintenance costs• Running the data link layer protocol unaligned to the channel

code allows more independence between layers • Uses data driven (Frame Header Signaled) Master Channel

Services instead of control via management

Back-up

Structural Aspects USLP AOS TC

Maximum Frame Size (in Octets) 2048 65536 1024Frame Size Constraint Variable/Signaled Managed/Fixed Variable/Signaled

VC-OCF Presence in VC Signaled Managed Not Included

Control Data Flag Presence Signaled in TFDF Managed Signaled

Insert Zone Size Managed/Fixed Variable/Signaled Not Included

Frame Error Control Field Managed/Optional Managed/Fixed Managed/OptionalFrame and Codeblock Aligned Managed/Optional Fixed Variable Codeblock

Spacecraft Ids 8192 256 1024

Sequence Counter Size Variable (0->7e16) Fixed (2.7e8) 256Virtual Channels 64* 64 64

Segmentation Signaled in TFDF No (uses Streaming) Separate FormatSegmentation (pseudo VCs) Signaled (32 VCs) No 16 Identifies Frame Contents Signaled in TFDF Managed by VC Managed by VC

Comparison of USLP, AOS and TC for Command

Transfer Frame Assembly

TransferFrameHeader

TransferFrame

SecurityHeader

VC Frame Data Field

(TFDF_SDU)

TransferFrame

SecurityTrailer

VCOperationalControl Field

TransferFrame

Error CheckField

Transfer Frame

6-10 Octets 4 Octets VariableVariableVariable VariableMandatory Optional Optional OptionalOptional Optional

VC Contents

Received from SAPand inserted into frame

Received from OCF

Calculated and entered into frame

Computed and entered in frame

Generated and entered into frame 1

4

3

2

5

Note: The number within the circles identifies the order of inclusion in the frame formation process

TransferFrameInsertZone

VariableOptional

LDPCRate ½ Block size 16 384 bitsRate ½ Block size 1024 1/2, 1024 LDPC with BCH TEDLDPC Rate 4/5 Block size 16384

GSFC-LDPC (8176,7156)

BCH SEC TED

Coding Performance (not including short LDPC codes) (provided by JPL Coding Group)

Short Uplink Code Performance

Packet SAP VC_OCFService

Data Unit

VCA_SDUs

VCF_SDUsOCF_SDUs

Virtual Channel

Processing

Virtual Channel Creation

Virtual Channel Data Unit (VCDU)

Master Channel Process (Virtual Channel Multiplexing)

Master Channel Data Unit (MCDU)

All Channel Multiplexing

Physical Channel

Coding and Sync Sub-Layer

Packets

PacketProcessingFunction

VCAProcessingFunction

VirtualChannel

Processing

Master ChannelProcess

VCA-SAP

OptionalProcess

Multiplexer

ReplicatedProcesses

Process

Legend

Security Process

CRC Creation

OCF

-SAP

Note: -Packet SAP can support multiple users-VCA SAP can only support a single user

TSDF-SAP

TSDF_SDUs

VCF-SDU = VC Data Field

Insert ZoneService

Data Unit