Transcript Common CCSDS Frame for all links-11L

Unified Frame Format
Next Generation Data SpaceLink Protocol
(NGSLP)
Ed Greenberg
Greg Kazz
2/20/2013
1
Why a new Frame structure now?
1.
2.
The new Frame design will support the basic TC, TM, AOS and Proximity Protocols providing a commonality
that should reduce new implementation costs.
•
This single frame specification will support all CCSDS Protocols
•
•
•
Both asynchronous and synchronous link protocols
Both fixed length and variable length frame protocols
Inclusion of a common structure for link layer security (both encryption and authentication)
•
Managed contents within a VC provides considerable flexibility that is useful in optimizing link operations
This proposed protocol was developed to be synergistic with the use of short high performance block codes
and to provide a common link data structure for the inclusion of Link layer security.
•
Investment in new spacecraft implementations for processing the communications link needed to add performance and
security will be required. Having the broadest benefit from this development is the desire.
3.
This frame structure is designed to be very flexible and efficient for use in each of the variety of environments
that space links operate in. The protocol will operate with both short and long LDPC forward error correcting
codes and even allow for the application of short LDPC codes for use in long frame to maximize the
performance and minimize the overhead.
4.
The inclusion of optional VC Sub-Channels enables the use of a single “Go-Back-N” protocol to support nearearth commanding and Proximity data exchanges while delivering data to multiple entities within a spacecraft
as is provided by MAPs (in TC) and Output Ports (in Proximity). This same capability allows a single security
association (SA) used for a single VC to provide crypto services to multiple VC sub-channel data channels.
5.
The protocol would each VC to be tailored to the requirements that it is allocated to support. Each VC can
have its own Security Association, can have 0 to 64 sub-channels and can carry packets an/or user formatted
octet or supervisory data.
6.
Provide enough data within the frame header to enable the Master Frame processing to be performed
enabling Forward Error Correction, Frame delimiting, Frame validation and Master Channel Service and the
the ability to separate and route VC frames without having the VC management details.
2
NGSLP TRANSFER FRAME STRUCTURE
A Transfer Frame shall have a mandatory frame header followed by up to six option
fields, positioned contiguously, in the following sequence:
1) Transfer Frame Primary Header (mandatory, fixed per VC, difference is signaled]
2) Security Header (optional, managed)
3) Transfer Frame Data Field (optional, variable)
4) Security Trailer (optional, managed)
5) Operational Control Field (4 octets, optional, managed by VC)
•
6)
Required to support COP-1 operations
Frame Error Control data Field (optional, managed by VC)
•
Only one CRC algorithm allow per Physical Channel and inclusion is signaled in Frame Header
Note: Coding is managed for a link (only 1 code type and code word size per link session)
Virtual Channel Sub-Channel_SDU
3
Managing VCs Data Structure
1.
A VC can be defined to contain or not contain sub-channels.
–
When Sub-channels are not contained then the data in the frame will be either
complete packets or user provided octets (or supervisory data) defined by
management
•
–
2.
This is very useful for protocol commands that use a VC to limit the required
overhead (e.g. Hardware commands, Hails, or configuration changes)
When Sub-channels are contained then a VCS header will be the initial data
the data in the VCS-SDU. This VCS header will identify the sub-channel, will
identify how the data is included the data field portion of the VCS-SDU and
whether that data are packets or octets. The header and will also contain a
sub-channel sequence counter to validate continuity for re-assembly of
packets and/or notification of an incurred gap.
The frame header must flag the presents of a CRC when included within a
VC. This enables the master frame handling process to know which frames
have a CRC without knowing the managed details for each of the VCs that
it encounters.
4
NGSLP Transfer Frame Header
The Transfer Frame Header has nine (9) required fields. All fields are fixed in length except
the VC Count field and are positioned contiguously in the following sequence:
1.
Version ID- is extended to 3 bits to accommodate one additional frame version (111) after this one (110) is codified
2.
Destination/Source - Identifies the Spacecraft ID as either the source of the data or the intended recipient
3.
Bypass – Identifies the frame as non-sequence controlled Protocol Data and VC Count field contains the data.
•
Thus a 64 bit frame can deliver an 8 bit “emergency command”
4.
Spacecraft ID - allows for 2048 address within an enterprise
5.
Frame Length –(N+1) allows a frame to be as small as 6 octets to as large as 65536 octets
6.
CRC Included -- signals the inclusion of the CRC (y/n)
• Identifying those VC frames that the receiving process needs to use the CRC for transfer Frames validation
7.
Virtual Channel ID – accommodates 32 Virtual Channels
8.
VC Count Extension Size – allows the VC count to be set to different sizes – (size is increased by N x 2 octets)
•
Thus VC Count size can be 8, 24, 40 or 56 bits in length
9.
5
VC Count – Incrementing VC counter that has a minimum size of 1 octet and a maximum size of 7 octets;
•
This counter can be used by the COP for sequence control, by the crypto authentication process eliminating the
need of a second counter or by data reassembly process to stitch together received data.
5
Rationale for Header Structural Choices
1.
2.
3.
4.
5.
6.
7.
Extended Version field to allow addition of a new version to replace this one
if necessary (e.g. may require larger SC_ID Field)
Increased the SC_ID field to accommodate larger number of spacecraft
within an enterprise
Inclusion of the Bypass flag is to allow for the creation of very short
hardware/supervisory (e.g. Hail) commands. Thus the frame data field and
OCF can be omitted. Inclusion of the CRC is signaled in the header.
The 16 bit Frame length allows for creation of much larger frames
CRC Flag is included to provide information to the receiving frame delimiting
process whether that frame contains a CRC to use to validate frame
correctness. If a CRC is to be used in a VC all frames with that VC must have a
CRC included.
32 VC are provided for routing, priority delivery and accounting. Both
Command and Proximity have traditionally only used 1 VC in order to limit
the requirements on the COP. Traditionally most missions use multiple VCs
for telemetry for both delivery routing and latency prioritization.
The proposed format includes a mechanism to vary the VC count size.
(Telemetry usually needs a large counter, Command uses a short counter, and
optionally the security process can use a large counter for reducing the SA
requirements).
6
Virtual Channel Sub-channels
The Virtual channel concept has been expanded to support sub-channels (VCSs)
that can provide sub-addressing for routing the VC frame’s contents. A VCS_SDU
can be created at a VC’s SAP or by a data source. The VCS is a self identified
“Virtual Channel” within a Virtual Channel (much like a VC within a MC in TM).
• A one byte incrementing counter, VCS Count, is provided for continuity testing per VCS
for reassembling packets that span frames and enabling signaling of gaps when carrying
VCA data.
• A VCS ID field of 6 bits is provided to supports the handling and routing of the frame
data field contents.
•
•
•
•
The use of this field replaces the MAP concept used in TC and Port IDs used in Proximity-1.
Enables Instruments and/or attached Platforms to create their own VCS_SDUs that will be
inserted into a VC for transport which then can be delivered to the designated user.
Provides the means for the Command Operations Procedure to verify frame continuity and/or
request retransmission in order to provide for the reception of a complete set of VC frames.
Also provides the means to enable the crypto process to utilize a single Security Association
for the entirety of Virtual Channel Sub-Channel sources within a single VC.
7
Rationale for VCS Inclusion and Structural Choices
The VCS_SDU is a data block that is inserted directly into a VC by the VC
constructor. The VCS_SDU contains the VCS-Count (incrementing the count for
each VCS_SDU passed), its ID for identifying the creator, the DFC to identify the
type of data contained (Packets or Octets) and its composition within the
following VCS data field. Two of the data construction types require a two byte
field to be included (a first header pointer to recover from an outage when carrying
streaming packets or a length value to signal how many octets in the VCS data field should
be passed to the User).
1. Multiple SDUs from different sources can be multiplexed into a single
VCS_SDU. Thus the loss of a single frame could upset the handling of the
multiple sub-channels because a the VC Counter would indicate a lost
Frame but there would be no indication of which VCS frame was lost. The
inclusion of the VCS-count provide the required continuity check.
2. VCS_ID provides for 64 sub-channels within a single VC. This may be over
kill but why waste the bits on unusable spare bits.
3. Data Frame Construction ID have four possible values each identify the way
the data is entered in the VCS Data Field. Note that two of the forms
require a 16 bit field containing information required for processing.
8
Virtual Channel Sub-Channel_SDU
The VCS_SDU is constructed to be inserted into a VC frame. The VCS_SDU contains an incrementing VCS
Count that is used to test continuity of the received data and for the reassembly of packets and for notifying
VCA users of gaps in the delivered data stream. The size of the VCS_SDU is constrained by management for
the VC that is to carry it. The contained fields are:
•
VCS Count – Incrementing count for the VCS
• Provides the means to assure continuity of VCS_SDUs from a single source
•
VCS ID – Identifies the SAP address (originator & intended recipient) for the contained delivery
•
VCS Data Field Construction ID – Identifies the construction rules and type of data contained within the VCS_SDU
•
•
00 - contains VCA data and requires the first 2 octets of the VCS data field to specify the number of valid octets
01 - contains packets and requires the first 2 octets of the VCS data as a first header pointer;
•
•
•
•
•
•
Packets need not be fully contained within a single VCS data field but can flow across multiple sequential VCS_SDUs
from the same VCS_ID.
The first header pointer points to the first byte of the first packet header contained within the VCS data field
Packets contained within a VCS data field must be concatenated (last octet to first octet)
10 –contains VCA data where last octet of VCA data is last octet of VCS data field11 - contains 1 or more complete packets where last octet of last packet is last octet of VCS data field
VCS Data Field – contains the data as signaled by the VCS_DFC_ID
Notes: 1) VCS Data Field Construction (DFC) Types “10” and “11” are used exclusively for variable length frames
2) The size of a VCS_SDU will be constant for a mission phase when the VC’s frame size is fixed by management
Protocol Link Transmission Unit (PLTU)
The PLTU is composed of the Attached Sync Marker (ASM) and the Frame (including the security
information, OCF and CRC). The PLTU contains the information required by the link layer process to delimit
the frame and the forward error correction decoding and derandomization processes:
1.
Delimiting the Frame
–
The Attached Sync Marker delimits the start of the frame , randomization and encoding
–
–
–
The ASM may also be required to resolve data ambiguity if not resolved in the physical layer
All frames within a physical link shall use the same ASM within a link session
There are alternative ways to delimit the end of the PLTU
1.
2.
An erred code word could be used to terminate the contained PLTU
The frame length will always be located within the first code word and by restricting the PLTU to carry a
single frame the frame length could be used to calculate the number of code words in the PLTU.
»
Note that this method (#2) is our choice because it works for all cases, has minimum overhead
but it requires the decoder and de-randomizer processes to get data from the first code word in
the PLTU in order to determine when to stop their process and start the ASM process.
3. A managed maximum number of code words could be established that would delimit a frame and can
also be used to terminate frames associated with a fixed length frame mode.
2.
By management inter-frame Idle can be either prohibited or allowed between PLTUs
⁻
Idle could be prohibited between PLTUs when mandated by management:

To support an isochronous transfer of an octet data stream

To simplify the frame delimiting process possibly allowing a shorter ASM.
10
Link Layer Services
VCA Service
Packet Service
Packets
Octets
VCA SAP
VCA SAP
VCS_Service
OCF Service
VC_OCF_SDU
VCS_SDU
Virtual Channel (VC) Formulation
•
•
•
•
•
Insert Received VCS-SDUs
Add VC Header and increment VC Counter
Compute and Add Security Header and Trailer
Insert OCF
Compute CRC and add FEC
VC_SDU
Virtual Channel_SDU
Master Channel (MC) Formulation
•
•
•
MC_SDU
Merge Received VC_SDUs
FEC Coding and Randomization
Add Attached Sync Marker
Master Channel_SDU (PLTU)
Physical Channel (PC) Formulation
•
•
Merge Received MC_SDUs
Add Idle as required
Physical Channel
Symbol Stream
11
Transmitting Entity
Receiving Entity
12
Inclusion of Security Services
The requirement for uplink to be secure is becoming universal. The uplink needs to
be protected from unauthorized commanding and thus the crypto process needs to
include a NSA authorized code that includes the prevention of unauthorized
replaying of commands. The authentication process requires the inclusion of an
initialization vector that is a counter to provide this assurance. The proposed format
contains a VC counter that could contain a 56 bits that can be used for that function
allowing a single key to be used for about 7x1016 times. This should allow a single SA
to be used for the entire duration of a mission (5x109 years)
Note that a “Security Association” is associated with a VC. This new format allows a
single VC to be an amalgamation of up to 64 sub-channels. This simplifies key
management since one SA could cover up to 64 sub-channels.
Typically high rate video uplink and downlinks do not require the same
authentication requirement but the 56 bit counter provides significant frame
accountability capability to allow these data to be included into a composite data
stream with all the other data if desired or by sending this data on a different VC it
could have its own SA (or none).
If LDPC and or link security is included there probably will be no need to add an FEC
field because both have extremely low undetected error rates.
13
Example Variable Length Frame Mode PLTU Format
When coding is synchronized to the PLTU in the Link Layer
One (1) PLTU
ASM
Erred Code
Word
Code Word Code Word Code Word Code Word
Fill
Frame
Header
Security
Header
Frame
Data Field
Security
MAC
OCS FEC
optional
optional
Note: Fill may be required within the last code word carrying frame data to complete the code word
Example Physical Layer Stream
PLTU
PLTU
I
D
PLTU
I
D
L
L
E
E
PLTU
Note: Each PLTU can have different number of code words and idle can be of any size.
Telecommand currently uses this methodology except that it uses the BCH code.
14
Example Fixed Length Frame Mode PLTU Format
When coding is synchronized to the PLTU in the Link Layer
One (1) PLTU
ASM
Code Word Code Word Code Word Code Word Code Word
Frame
Header
Security
Header
Security
MAC
Frame Data Field
OCS FEC
optional
optional
Example Physical Layer Stream
PLTU
PLTU
PLTU
PLTU
PLTU
Note: 1. Each PLTU will have the same pre defined number of code words
2. At different rates the number of code words per PLTU can be different thus at low
rates each frame can be smaller while at higher rates larger frames can be used.
3. Idle of any size can be included between PLTUs if link management allows
15
Example of a Mixed Mode PLTU Stream (1 of 2)
When coding is synchronized to the PLTU in the Link Layer the
physical stream could contain both variable and fixed length
frames including Idle bits.
Erred Code word
Fixed PLTU
Variable
PLTU
I
D
L
Fixed PLTU
Variable
PLTU
I
D
Fixed PLTU
L
Note: All PLTUs will have an integer
number of code words,E but idle
E
of any size can be included between frames.
16
Examples of a Mixed Mode PLTU Stream (2 of 2)
When coding is not synchronized to the PLTU a separate Code
sync word is required to delimit the code word(s). The number
of code words that follow a code sync word is established by
management but must be fixed for a contact.
Fixed PLTU
Variable
PLTU
IDLE
Fixed PLTU
Variable
PLTU
IDLE
PLTU
Notes:
1. Frames are not constrained to a single frame length that is associated with the
code word length thus no fill is ever required and variable length PLTUs do not
require termination by an erred code word.
2. For emergency commanding the unsynchronized coding with the frame can increase
the required view period and latency by having the frame spread across 2 code
words. This problem can be remedied by synchronously adding the LDPC code to
the command frame within the mission POCC and not having the ground station
add the LDPC coding before transmitting the command
17
Replacing TC and Proximity Segmentation
The Multiple Packet Data Type (DTID=“01”) is provided to
handled packets that are larger than the maximum length
managed for that link.
• Maximum packet length is 65,536
• Maximum packet within a frame is constrained by the
added frame fields required for routing, accounting,
security, and other functions.
• TC Segmentation can be replaced by using the Multiple
Packet Data Type (MSDU) (where the VCS_DTID=“01”)
• The provided VCS sequence counter (8 bit) can
assure the receiving unit of packet contents
continuity within a string of VCs replacing the
segmentation process.
18
Use of NGSLP Format For TC
1. The current TC format can be replace by the Common Format using the variable
frame approach with either of the two PLTU termination methods
2. The Bypass feature could be used for operational commanding when minimum frame
size is required. (i.e. for hardware commands, Supervisory Data, Proximity Hailing)
3. Protocol commands could be assigned to a specific VC that is sequence controlled or
not.
4. Redundant receivers could be addressed using a different set of VCs (16 for each)
5. Segmentation is replaced by using larger frames and/or the MSDU type format.
6. The Destination/Source Flag default value would be set to “destination” so that the
Spacecraft ID is used to identify the target spacecraft
7. The VCS address could be used to directly deliver the frame contents to one of the 64
provided VCS users within a VC.
8. The up to 56 bit sequence counter can be used within a single VC to last a significantly
long time as the initialization vector for command authentication .
•
A single security SA can to be used to provide security for a multitude of VCS sub-channels
within a VC basically allowing for a virtual “Master channel” security approach.
9. Very Long Fixed length Frames would be beneficial to High rate data uplinks
19
Use of NGSLP Format For Proximity-1
1. The current Proximity-1 format can be replace by the Common Format using
the variable frame and/or the fixed length frame approaches.
•
•
The Hail should use the variable length frame with a designate VC and SAP
The PLCW could either be used as in the current Proximity-1 Protocol or as an
added field in the data carrying frames.
2.
3.
4.
5.
6.
The Bypass feature could be efficiently used for Hailing.
Protocol commands could be assigned to a specific VC or a Bypass VCS.
Redundant receivers could be addressed using a different set of VCs (16 for each)
Segmentation is replaced by using larger frames and/or MSDU type format.
The destination/Source Flag default value would be set to “destination” for
data forwarded to a spacecraft; It would be set to source for data to be sent
from a spacecraft that was destined for Earth.
7. The 64 provided VCS address per VC could be used to direct delivery of the
frame contents.
8. Forward control command rates vary and a variable sized sequence counter
can be used within a single VC to optimize use in a specific environment.
9. Return Data typically does not need to be Authenticated but data from
multiple communications sessions need to be stitched together to provide
the total data set for interpretation.
20
Use of Common Format For Telemetry
1. The current TM and AOS formats can be replace by the Common Format
using the fixed length frame approach.
2. The VCs could identify specific sources within the spacecraft and/or the
priority for delivery of the data contained within the frame.
3. Large packets are supported by using MSDU format (DFCID=“01”).
4. The destination/Source Flag default value would be set to “source” to
identify the source of data being sent from a spacecraft destined to Earth
based users.
5. The VC address could be used to provide prioritized. The VCS ID could
provide routing to local entities.
6. The possible 56 bit VC frame sequence counter provides an adequate
counter for ordering received telemetry.
7. Direct to Earth high rate telemetry does not need to authenticate and
encryption only does not necessarily need an initialization vector.
21
Backup-1
22
Possible Upgrades (minimal effect on TC)
1. New uplink coding for performance improvement in nonemergency situations.
–
–
Coding gains of up to 9 dB when LDPC replaces BCH
Using current CCSDS recommendations for:
•
LDPC rate ½ (64, 256, 512,1024 or 4k code words)
2. New uplink coding for performance improvement in
emergency situations.
–
Coding gains of up to 5 dB (If 256 bit block LDPC codes used)
3. Significant improvement in time correlation for deep space
missions can be accomplished using regenerative ranging
utilizing current CCSDS PN ranging specification
–
5/17/11
Tens of milliseconds to units of microseconds
Spring 2011 CCSDS Meeting - Berlin
23
Uplink Coding
1.
2.
3.
5/17/11
TC currently requires use of the BCH (55,63) code in either of 2 modes:
• Triple Error Detection (TED) provides only error detection
– Requires 7 code bits a 1 parity bit for each 8 bytes of frame
– Not recommended for burst environment
– Required Eb/No at BER = 1e-5 is 11.04 dB
• Single Error Correction (SEC)
– Required Eb/No at BER = 1e-5 is 8.75 dB
Adding CC could provide a performance gain of 6 dB over BCH TED
• CC decoding creates a burst error environment which is incompatible
with BCH SEC mode. TED is required for detecting end of PLTU for
current TC recommendation.
Adding LDPC (½, 1024) could provide a performance gain of 9 dB over BCH
TED
• LDPC is a block code and can only be used with TC when used as an
outer code with its own synchronization field (PLTU sync).
– LDPC used in physical layer
Spring 2011 CCSDS Meeting - Berlin
24
Short Uplink Code Performance
25
Overall Coding Performance (provided by JPL Coding Group)
1E-1
Uncoded
BCH TED
BCH SEC/DED
RS
(7,1/2)
LDPC 7/8,7156
LDPC 4/5,16K
(7,1/2)+(255,223)
LDPC 1/2,1K
Turbo 1/2,8920
LDPC 1/2,16K
Rate 1/2 BIAWGN Capacity
1E-2
Bit Error Rate
1E-3
LDPC
Rate ½ Block size 16 384 bits
Rate ½ Block size 1024
1/2, 1024 LDPC with BCH TED
1E-4
1E-5
1E-6
-1
0
1
2
3
4
5
Eb/No (dB)
6
7
8
9
10
11
64 Bit Attached Synchronization Marker Performance
27
Reference
•
“Uplink Coding for New TC Standard”. White paper submitted at Fall 2010 CCSDS
Meeting London Oct 10, 2010 by Fabrizio Pollara, Ken Andrews, Bruce Moison, Jon
Hamkins (NASA/JPL).
5/17/11
Spring 2011 CCSDS Meeting - Berlin
28