1. Unified Frame Format Next Generation Data SpaceLink Protocol (NGSLP)
Ed Greenberg Greg Kazz 2/20/2013

2. Why a new Frame structure now?
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.
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.
The inclusion of optional VC Sub-Channels enables the use of a single “Go-Back-N” protocol to support near-earth 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.
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.
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.

3. 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:
Transfer Frame Primary Header (mandatory, fixed per VC, difference is signaled]
Security Header (optional, managed)
Transfer Frame Data Field (optional, variable)
Security Trailer (optional, managed)
Operational Control Field (4 octets, optional, managed by VC)
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

4. Managing VCs Data Structure
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
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.

5. 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:
Version ID- is extended to 3 bits to accommodate one additional frame version (111) after this one (110) is codified
Destination/Source - Identifies the Spacecraft ID as either the source of the data or the intended recipient
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”
Spacecraft ID - allows for 2048 address within an enterprise
Frame Length –(N+1) allows a frame to be as small as 6 octets to as large as octets
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
Virtual Channel ID – accommodates 32 Virtual Channels
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
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

6. Rationale for Header Structural Choices
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).

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

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

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

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

11. Link Layer Services Packets Octets VCA Service Packet Service 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
Merge Received VC_SDUs
FEC Coding and Randomization
Add Attached Sync Marker
MC_SDU
Master Channel_SDU (PLTU)
Physical Channel (PC) Formulation
Merge Received MC_SDUs
Add Idle as required
Physical Channel
Symbol Stream

12. Transmitting Entity
Receiving Entity

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

14. Example Physical Layer Stream
Example Variable 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
Erred Code Word
Fill
Frame Header
Security Header
Frame Data Field
Security MAC
OCS
optional
FEC
optional
Note: Fill may be required within the last code word carrying frame data to complete the code word
Example Physical Layer Stream
IDLE
PLTU
PLTU
IDLE
PLTU
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.

15. Example Physical Layer Stream
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
Frame Data Field
Security MAC
OCS
optional
FEC
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

16. 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
Fixed PLTU
IDLE
Fixed PLTU
Variable PLTU
IDLE
Note: All PLTUs will have an integer number of code words, but idle
of any size can be included between frames.

17. 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
Fixed PLTU
Variable PLTU
PLTU
IDLE
IDLE
Notes:
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.
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

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

19. Use of NGSLP Format For TC
The current TC format can be replace by the Common Format using the variable frame approach with either of the two PLTU termination methods
The Bypass feature could be used for operational commanding when minimum frame size is required. (i.e. for hardware commands, Supervisory Data, Proximity Hailing)
Protocol commands could be assigned to a specific VC that is sequence controlled or not.
Redundant receivers could be addressed using a different set of VCs (16 for each)
Segmentation is replaced by using larger frames and/or the MSDU type format.
The Destination/Source Flag default value would be set to “destination” so that the Spacecraft ID is used to identify the target spacecraft
The VCS address could be used to directly deliver the frame contents to one of the 64 provided VCS users within a VC.
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.
Very Long Fixed length Frames would be beneficial to High rate data uplinks

20. Use of NGSLP Format For Proximity-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.
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.
The 64 provided VCS address per VC could be used to direct delivery of the frame contents.
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.
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.

21. Use of Common Format For Telemetry
The current TM and AOS formats can be replace by the Common Format using the fixed length frame approach.
The VCs could identify specific sources within the spacecraft and/or the priority for delivery of the data contained within the frame.
Large packets are supported by using MSDU format (DFCID=“01”).
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.
The VC address could be used to provide prioritized. The VCS ID could provide routing to local entities.
The possible 56 bit VC frame sequence counter provides an adequate counter for ordering received telemetry.
Direct to Earth high rate telemetry does not need to authenticate and encryption only does not necessarily need an initialization vector.

22. Backup-1

23. Possible Upgrades (minimal effect on TC)
New uplink coding for performance improvement in non-emergency 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)
New uplink coding for performance improvement in emergency situations.
Coding gains of up to 5 dB (If 256 bit block LDPC codes used)
Significant improvement in time correlation for deep space missions can be accomplished using regenerative ranging utilizing current CCSDS PN ranging specification
Tens of milliseconds to units of microseconds
5/17/11
Spring 2011 CCSDS Meeting - Berlin

24. Spring 2011 CCSDS Meeting - Berlin
Uplink Coding
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 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
5/17/11
Spring 2011 CCSDS Meeting - Berlin

25. Short Uplink Code Performance

26. Overall Coding Performance (provided by JPL Coding Group)
LDPC
Rate ½ Block size bits
Rate ½ Block size 1024
1/2, 1024 LDPC with BCH TED

27. 64 Bit Attached Synchronization Marker Performance

28. Spring 2011 CCSDS Meeting - Berlin
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