USLP Presentation-2-18-15 - The CCSDS Collaborative Work

advertisement
CCSDS Unified Space Data Link
(USLP)
Greg Kazz
Feb. 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-toground, ground-to-space, and space-to-space.
Space App.
Standards
Lossy
Data
Compression
Lossless
Data
Compression
Store
and
Forward
Time
Codes
Interactive
Application
CCSDS
File
Delivery
Protocol
(CFDP)
Onboard
Navigation
Space Packet
Protocol
Onboard Comm
Standards
Onboard Bus and LAN Standards
SOIF: Spacecraft Onboard Interface Standards
Networked CCSDS Space/Ground Communications Protocol Stack
SCPS-FP
Space FTP
Internet
FTP
SCPS-TP
SpaceTCP/UDP
Internet
TCP/UDP
SCPS-SP Space Security Protocol
Space Packet
Protocol
TM Space Data
Link Protocol
SCPS-NP Space
Network Protocol
AOS Space Data
Link Protocol
Communications
Operation
Procedure Prox
Synchronous Links
Reed-Solomon
Coding
Turbo & LDPC
Coding
TC Space Data
Link Protocol
Space Data
Link Security
Protocol
Link Communications
Operation
ARQ
Procedure 1
Asynchronous Links
Code & Frame
Sync.
CLTU and
PLOPs
Draft CCSDS Recommendation
Link
BCH Coding
Physical
Radio Frequency and Modulation
CCSDS Recommendation
Network
Internet Protocol
(IPv4, IPv6)
Proximity-1 Space
Data Link Protocol
Link
ARQ
Convolutional
Coding
Internet IPSec
Transport
CCSDS Report
Internet RFC
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
•
Decouples the link framing from the
channel coding
•
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.
•
Applicable to large and diverse set
of missions from ISS to Cubesats;
Once implemented, reduces future
development & testing from 4 to 1
protocol
Using S/W defined radios, missions
may chose to swap in higher
performing codes(~ 3 to 8 dB gain)
during development or flight
operations
How USLP addresses future needs (2-2)
Features
Provides a variable length transfer
frame for all links including AOS and
TM applications
Benefits
•
•
Utilizes Virtual Channels as
addressable unit in all protocols
•
•
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
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 Aspects
AOS
USLP
2048
65536
Managed/Fixed
Variable/Signaled
VC-OCF Presence in VC
Managed
Signaled
Insert Zone Presence
Managed
Signaled
Insert Zone Size
Fixed
Signaled
Structural
Frame
Error Elements
Control Field
AOS
Fixed
USLP
Signaled
Frame and Code block Alignment
Fixed
Fixed/Variable
256
8192
Sequence Counter Size
Fixed (2.7e8)
Variable (0-7e16)
Virtual Channels
64 maximum
Maximum Frame Size (in Octets)
Frame Size constraint
Spacecraft Ids
64 or
32
independent/32
dependent
USLP vs AOS Structures
USLP
Frame
AOS
6-8 Octets Optional
Mandatory
Variable
Fixed
2 Octets
Optional
USLP
8 bits
Frame
Header
AOS
Transfer Frame Data Field
USLP
AOS
USLP Transfer Frame Structures
Transfer
Frame
Header
Version Spacecraft
ID
ID
3 bits
Destination
or
Source
ID
13 bits
1 bit
6 Bits
1 bit
Transfer
Frame
Header
Transfer
Frame
Virtual
Channel
ID
Insert FECF
Frame
Zone
Length Included Size
Flag
16 Bits
Transfer
Frame
Insert
Zone
Virtual
Channel
Security
Header
6-13 Octets
Mandatory Optional
Variable
Variable
Optional
Optional
Transfer Frame
Data Field
(TFDF_SDU)
MC Group
Transfer
Frame
Data Field
1 bit
OCF
Flag
2 bits 1 bit
Virtual
Channel
Security
Trailer
Variable
Optional
Sequence
Counter
Behavior
Flag
1 bit
3 bits
Transfer
Virtual
Frame
Channel
Error
Control
Operational
Field
Control Field
4 Octets
Variable
Optional
Optional
TFDF Data Zone
Transfer frame Data Field Header
Mandatory
Structuring
Rules
3 bits
!
Contained
Protocol ID
5 bits
Optional (only required for Stream Data)
Optional
Extended
Contained
Protocol ID
8 bits
Optional
•
•
0-56 Bits
Trailer Group
VC Group
VC Data Structure and Protocol fields Identifier
Sequence Sequence
Counter Counter
Length
Value
•
•
•
•
CCSDS Space Packets
Internet Datagrams
DTN Bundles/Fragments
User Octets
First Header Pointer For packets
Last valid octet for user defined data
16 bits
Variable
USLP Transfer Frame Header
Version Spacecraft
ID
ID
3 bits
13 bits
Destination
or
Source
ID
1 bit
Virtual
Channel
ID
1 bit
6 Bits
Insert FECF
Frame
Zone
Length Included Size
Flag
16 Bits
1 bit
OCF
Flag
VC Counter
Behavior
Flag
VC
Counter
Length
VC
Counter
Value
1 bit
3 bits
0-56 Bits
2 bits 1 bit
• 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 Data Zone
TFDF Header
VC Data Structure and Protocol fields Identifier
Mandatory
Data Inclusion
Rules
3 bits
Extended
Protocol ID
Protocol ID
5 bits
Optional (only required for Stream Data)
Streaming Data Pointer
•
First Header Pointer For packets
•
Last valid octet for user defined data
8 bits
16 bits
•
•
•
•
CCSDS Space Packets
Internet Datagrams
DTN Bundles/Fragments
User Octets
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.
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 pointer
II. Last valid user octet
Data Inclusion Rules
Streaming Pointer Field
Protocol ID
(Optional based on Data Rules)
‘00000’ CCSDS Packets
‘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
‘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
Comparison of USLP, AOS and TC for Command
Structural Aspects
USLP
AOS
TC
Maximum Frame Size (in Octets)
2048
65536
1024
Frame 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/Optional
Frame and Codeblock Aligned
Managed/Optional
Fixed
Variable Codeblock
Spacecraft Ids
8192
256
1024
Sequence Counter Size
Variable (0->7e16)
Fixed (2.7e8)
256
Virtual Channels
64*
64
64
Segmentation
Signaled in TFDF
No (uses Streaming)
Separate Format
Segmentation (pseudo VCs)
Signaled (32 VCs)
No
16
Identifies Frame Contents
Signaled in TFDF
Managed by VC
Managed by VC
Transfer Frame Assembly
Received from OCF
2
4
3
Generated and
entered into frame
Transfer
Frame
Header
Transfer
Frame
Insert
Zone
6-10 Octets Variable
Mandatory Optional
Computed and entered in frame
Received from SAP
and inserted into frame
Transfer
Frame
Security
Header
Variable
Optional
1
VC Frame Data
Field
(TFDF_SDU)
Variable
Optional
Calculated and
entered into frame
Transfer
Frame
Security
Trailer
VC
Operational
Control Field
Variable
Optional
4 Octets
Optional
5
Transfer
Frame
Error Check
Field
Variable
Optional
VC Contents
Transfer Frame
Note:
The number within the circles identifies the order of inclusion in the frame formation process
Coding Performance (not including short LDPC codes)
LDPC
Rate ½ Block size 16 384 bits
Rate ½ Block size 1024
1/2, 1024 LDPC with BCH TED
LDPC Rate 4/5 Block size 16384
GSFC-LDPC
(8176,7156)
(provided by JPL Coding Group)
BCH
SEC
TED
Short Uplink Code Performance
VCA_SDUs
Packet SAP
VCA-SAP
Packet
Processing
Function
TSDF_SDUs
TSDF-SAP
VCA
Processing
Function
OCF-SAP
Note:
-Packet SAP can
support multiple
users
-VCA SAP can
only support a
single user
Packets
VCF_SDUs
VC_OCF
Service
Data Unit
Insert Zone
Service
Data Unit
OCF_SDUs
Virtual Channel Creation
Virtual
Channel
Processing
Security Process
Virtual
Channel
Processing
CRC Creation
Virtual Channel Data Unit (VCDU)
Master Channel
Process
Master Channel Data Unit (MCDU)
All Channel Multiplexing
Coding and Sync Sub-Layer
Master Channel Process
(Virtual Channel Multiplexing)
Legend
Optional
Process
Multiplexer
Process
Physical Channel
Replicated
Processes
VCF-SDU = VC Data Field
Download