CCSDS Next Generation Space Link Protocol (NGSLP) Greg Kazz Peter Shames NASA-JPL 3-31-2014

CCSDS Next Generation Space Link Protocol (NGSLP)

Greg KazzPeter Shames

NASA-JPL3-31-2014

2

What’s the overall story here?

• Current and Future Space Link Frames– What is similar, what is different?– What makes NGSLP special?– How does NGSLP do what’s currently done better ?

• Impact of NGSLP on Future Mission Operations– Cross-Support Services– Optical Communication

• NGSLP Path to Standardization

SLS-Plan Comm - CCSDS Spring 2014 Meeting - Noordwijkerhoot, the Netherlands

3

Drivers for the NGSLP• Will accommodate Higher Data Rates impacting frame handing services

– Provides Longer frames to make the frame handling processes more efficient– Provides Longer sequence counter to enable frame ordering from multiple downlinks

• Takes advantage of decoupling the transfer frame length from the code block size– Requires variable length frame service from coding & synchronization sub-layer– Separates link protocol from coding & synchronization functionality enabling modularity

• Provides a path to deliver control directives with minimum latency • To support such applications as data rate and/or Modulation changes (VCM),• Provide aperiodic Telerobotics, launch and decent landing operations directives

• Provides increased addressing for greater spacecraft population – Need for enlarged S/C ID field and SCID Use Field (Pre vs. Post Launch Data Discriminator)

• Allows Space Link Layer Security to run under all space links including Proximity-1• Simplifies Mars Communications (direct to/from Earth and In-situ)

– Requires only one format for all Lander communication links– NGSLP enables orbiters the means to provide a frame relay service similar to the CSTS forward frame

service currently in development

• We believe NGSLP supports Optical Communications and its Unique Environment – Longer frames to support higher rate data handling– Decoupling frame from codeblock option provides straight forward evolution to next generation of codes

for optical links while maintaining same framing structures– Coding/Decoding could be more naturally performed in communication devices not in data system

4

NGSLP Frame

CCSDS Frames Structures• Tailored for short hop communications• Variable length frames • Separate frames for Control and Data• TC uses a short BCH code concatenating code

words as needed to capture complete frame• Prox uses a Convolutional code for return link• Maven Orbiter is equipped with an LDPC where the

frames and code blocks are decoupled

• Initial design for telemetry using CC-RS code• Fixed length frames, couples frame to code block • Separate frames for Control and Data• TC uses a low performance BCH code • Prox uses a Convolutional code for return link

• Upgraded design for telemetry using any long block code but where the code block and frame are coupled

• Added an Insert Zone for isochronous data transfer• Increase the number of Virtual Channels• Eliminated the MC counter and increased the VC

counter

• Upgraded design to accommodate long frames, more SCIDs, expanable larger VC counter and integrated the best of all the CCSDS frame formats so that NGSLP can be used for all links.

• Allows for frames to be either coupled or uncoupled to the frame.

• Uncoupled approach supports insertion of low latency messages into frames & remove the requirement for Idle frames

5

NGSLP Format with Payload Options

1

2

3

4

6

NGSLP Format CharacteristicsData Driven (contained in Frame Header) Transfer Frame

VariableOptional

Transfer Frame Data Field(VCDF_PDU)

Managed VC Content

Link Managed Control Parameters:1. Physical: Frequency (wavelength), Modulation, 2. Link Layer: Coding, Frame-Codeblock coupling, fixed or variable frame sizeNote: Use of high performance codes with very steep WER/SNR and exceeding low error floors, means that little performance is lost when frames span multiple code words.

Frame Header Data supports Cross Support Services: 3. Frame Services: Verify Frame is unmodified then deliver MC and/or VC frames4. Insert Service: deliver Insert Zone content5. Operation Control Service: deliver OCF data

VC content is managed by VC user:6. Establish Security Association (or none)7. Specify VC handling: Sequence Control, VC Sub Channels included,8. Specify VC and VC Sub-channel content: Packets, Octets, IP Datagrams, DTN, other

7

NGSLP for Proximity or Telecommand Application

Plan Comm - CCSDS Spring 2014 Meeting - Noordwijerhoot, the Netherlands

VersionID

3 bits

FECFSize

2 bits

OCFFlag

3 bits

VCCount

size

16 Bits

Frame Length

1 bit

Destinationor

SourceID

SpacecraftID

13 bits2 Bits

SCIDUseField

1 bit

InsertZoneFlag

1 bit 6 Bits

Virtual Channel

ID

VCCount

0-56 Bits

Transfer Frame Header

FECF Size: Identifies the size of the Frame Error Control Field and the applied algorithm

VC Count Size: • a one octet field is all required for adequate sequence control• a zero octet field is all that is required for bypass and control/configuration directives• Up to seven octet field can be used for sequence control, accounting and security for high rates

Frame Length: Identifies the length of the frame

Destination or Source ID: Set to Destination

SCID, SCID: identifies the spacecraft to whom the frame is being sent

OCF Flag: provides reporting for Go-Back-N protocols (one way or bi=directionally) and/or operational reports

VC ID: identifies the rule set to apply for frame acceptance and content handling and routing

Insert Zone: 1. can be used to provide source ID to allow recipient to know who sent data2. can be used to provide access for low latency messages during Launch or Decent & Landing

Inclusion of VC Sub channels: 3. provides the same functionality that MAPs and Ports provide in current TC & Prox without segmentation4. enable the use of a single SA for multiple data streams emanating from the same User facility

8

THE FUTURE

9

Cross Support Changes Required for NGSLP Forward Services

CSTS F-Frame Service • Currently in definition to provide new symmetric forward cross support services. • Support NGSLP frame assembly, frame merging and encoding in the ground station. • Essential to support space internetworking (DTN); required for high rate forward

optical comm.• Can be development model for network wide frame multiplexing service for hubs

The service will be layered to provide the required functionality:

1) The Frame building layer accepts user supplied data to create the transfer frame.

2) The Frame Multiplexing layer accepts frames from the underlying service and multiplexes them into a stream of frames for uplinking. Frame selection prioritization is a management function.

3) The Coding layer applies error correcting codes to the stream of frames. Depending on the NGSLP option selected either a single ASM is used (coupled) or a separate ASM and CSM is used.

4) The layer closest to the antenna will form the bit stream that will be modulated onto transmission carrier.

Plan Comm - CCSDS Spring 2014 Meeting - Noordwijkerhoot, the Netherlands

CCSDS NGSLP Work Plan Timeline

1. October 2013 1. Deliver a White Paper at CCSDS Fall Meeting2. Get commitment for support from other International agencies

2. October 2013 – April 20141. Establish a Project with the SLP Working Group starting the process toward creation of the

NGSLP Recommendation including a Concept paper.2. Generated a Draft Green Book for the Protocol3. Review the Concept Paper and Green Book at the Spring 2014 CCSDS Meeting4. Officially sanction NGSLP as a project within SLP WG

3. April 2014 – October 20141. Generate a Red 1 Book for the Protocol2. Review the Red 1 Book at the Fall 2014 CCSDS Meeting (generate RIDs)

4. October 2014 – April 20141. Work the RIDs and generate a Red 2 Book for the Protocol2. Review the Red 2 Book at the Spring 2015 CCSDS Meeting (generate RIDs)

5. April 2014 – Nov 20171. Prepare Draft Blue Book2. Get 2 independent implementations of the Protocol for evaluation (DLR has signed up)3. Codify and publish the NGSLP Blue Book

11

BACKUP

PlanComm - CCSDS Spring 2014 Meeting - Noordwijerhoot, the Netherlands

12

LINK PROTOCOL UNIFICATIONOR

“MISTER CCSDS TEAR DOWN THAT WALL OF INOPERABILITY NOW”

CCSDS-NGSLP BB

13

NGSLP for Direct with Earth High Rate Links

Plan Comm - CCSDS Spring 2014 Meeting - Noordwijerhoot, the Netherlands

VersionID

3 bits

FECFSize

2 bits

OCFFlag

3 bits

VCCount

size

16 Bits

Frame Length

1 bit

Destinationor

SourceID

SpacecraftID

13 bits2 Bits

SCIDUseField

1 bit

InsertZoneFlag

1 bit 6 Bits

Virtual Channel

ID

VCCount

0-56 Bits

Transfer Frame Header

FECF Size: set to 0VC Count Size: up to 7 byte –for long term accounting and or as the security count for authenticationFrame Length:

1. identifies the length of the frame 2. rubber banding allows TFDF to carry complete user PDUs

Destination or Source ID: Set to Source

SCID, SCID: identifies the spacecraft that generated the frame

OCF Flag: provides reporting for Go-Back-N protocols (one way or bi=directionally)

VC ID: identifies the rule set to apply for frame acceptance and content description

Insert Zone: can be used to provide access for low latency messages

Inclusion of VC Sub channels: enables a single SA to protect a VC including all of its Sub channels

14

NGSLP Header

CCSDS Transfer Frame Headers

15

Telecommand – NGSLP StyleTelecommand (TC) Protocol supports Direct From Earth (DFE) communication to a Spacecraft.

• Variable length frame structure that transports protocol control directives and mission control/operations messages (i.e. sequencing and instrument control).

• Incorporates a low performance forward error correcting code that doubles as an error detection code.

• The maximum frame length size is 1024 octets; necessitating the inclusion of a segmentation process.

NGSLP can provide the same functionality as TC, but adds additional services. The key features of NGSLP that enables the upgrade of service are:

• The use of high performance block codes that can be either coupled or uncoupled with the transfer frame. The proposed codes can improve link performance by up to 9 db

• Longer frames and / or the use of data streaming (as done in TM and AOS) can be used to eliminate segmentation

• The use of Virtual Channel (VC) Sub channels provides an internal path identifier to direct the received data to a specific element within the spacecraft.


16

Telemetry – NGSLP StyleTelemetry Protocol (TM) supports Direct To Earth (DTE) communication from a Spacecraft.

• Uses a fixed length frame structure that is coupled to a code block. • The code and frame use the same synchronization word (ASM). • The maximum fixed frame length is 2048 octets. • The frame carries both a Master Counter (MC) counter and a Virtual Channel (VC)

counter each 8 bits in length.• A technique identified here as “streaming” provides a means to allow packets

transported in a VC to span frames of the same VC.

NGSLP can provide the same functionality as TM, but adds additional services. The key features of NGSLP that enables the upgrade of service are:

• Longer frame counter (MC) and longer VC counters to support higher data rates, reduce operational frame handling complexities and improve efficiency.

• Frames may either be coupled or uncoupled from the code blocks. • Uncoupling the frame permits greater flexibility in frame length variability and

coding choices. It also supports the irregular use of the Insert Zone to transport latency intolerant messages that can be inserted in the next frame that is to radiate.


17

Space Internetworking – NGSLP StyleCCSDS has created a Encapsulation Space Packet to provide a shim to support networking protocols• The encapsulation packet identifies the protocol data unit (PDU) it contains and as such identifies

the network service process to which the PDU is to be delivered.• The Virtual Channel process allows packets of from different applications to share the physical

channel. This process also allows different packet types to be segregated• This process requires a shim entity that can rebuild the network PDU using the packet process

when the TM or AOS streaming process places portions of the packet in to multiple frames.

NGSLP’s frame length flexibility and Virtual Channels and Virtual Channel Sub-channels provide the means to carry complete network protocol packets.

• Longer variable length frames that can “rubberband” to contain an integer number of IP, Bundle Fragments or LTP Segments data units. This process allows the frame handling process to extract the collection of complete network PDUs and deliver them to their respective processing entity.

PlanComm - CCSDS Spring 2014 Meeting - Noordwijkerhoot, the Netherlands

18

Other system elements that need to change for Optical Communication

• New coding, modulation and signaling to handle new optical comm features– Extensions to Service Management standard to schedule, request and configure

all of these new link, coding, modulation and signaling features

• Interaction between receiving and transmitting terminals due to weather and/or slant angle– Uncoupled NGSLP enables the insertion of small control messages into the link either

in the Insert Zone of by use of a small control frame

• Interaction between different ground stations due to weather and/or slant angle– Extensions to Service Management standard to handle station hand-over to deal with

weather and “seeing” effects

• Weather may affect “seeing” at any of the possible ground stations– New standards for weather forecast and weather effects exchanges


TransferFrameHeader

TransferFrame

SecurityHeader

VC Frame Data Field

(VCF_SDU)TransferFrame

SecurityTrailer

VCOperationalControl Field

TransferFrame

Error ControlField

VC Transfer Frame

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

VC Data Field

Received from SAPand inserted into frame

Received from OC Service and

Inserted into frameCalculated and

entered into frame

Computed and entered in frame

Generated and entered into frame 1

4

32 5

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

Transfer Frame Assembly

MasterChannel

InsertZone

VariableOptional

VariableOptional

VirtualChannel

InsertZone


20

PacketsPacket Service VCA Service

VCA-SDUsOCF Service

Virtual Channel (VC) Formulation• Add VC Header and increment VC Counter• Insert Received VC-SDUs • Insert OCF• Compute and Add Security Header and Trailer• Compute and add FEC(optional)

• Master Channel (MC) Formulation• Merge Received VC Frames

TFDF_PDU (VC_Frame Data Field)

Virtual_Channel_Frame

MC_Frame

Physical Channel (PC) Formulation- - Add Idle as required to maintain continuous bit stream

Packet SAP

Data Sub-layer

Sync& Coding Sub-layer

Packets

Packet Service

VCA Service

OCF_PDU

- Perform Security Process - Deliver Verified VC-Frames - Check VC Continuity- Extract OCF

- Delimit Frames using Sync Marker- FEC Decoding and Derandomization-

VC_Service

Master_Channel_Frame

Physical Channel (PC) Reception• Acquire symbols

Physical Channel Symbol Stream

VCS SAP

Data Sub-layer

Receiving Physical Layer

Sync& Coding Sub-layer

Transmitting (sending) Side Receiving Side

MC Service

MC_Frame

Virtual Channel Frame

Separate MC_Frames

Select VCS_SDU

VCA SAP VCA SAPExtract Octets Extract Packets

TFDF_PDU Creation- Build the TFDF Header - Insert Packet/VCA Data into FDF

ExtractOCF

VC_Frame

1 of many1 of many

VCS Service

Separate VC Frames

VCS_SDU

Extract TFDF

• Add Attached Sync Marker• Randomize• FEC Coding

Master_Channel_Frame Merge MC Frames

Transmitting Physical Layer

Merge VC Frames

Separate VCS_PDUs

Validate Frame using FEC (when contained)

VCA-SDUs


21

Pink sheets for separating Coding from Data Transfer Frame.docx 10/15/13By V. Sank, M. Bertinelli

Pink sheets for separating Coding from Data Transfer Frame Purpose Revise several sections, of CCSDS 131.0-B-2 and add one to allow separation of Data Transfer Frame layer and coding layer codes. IntroductionThe requirement on data Transfer Frames used with LDPC codes have been found to be unnecessarily restricted. Both DVB-S2 and SCCC use a slicing technique proposed here for CCSDS LDPC codes. BackgroundSection 10.8 of CCSDS 131.0-B-2 requires that the Transfer Frame lengths must match the information block length for the selected LDPC code and that the data Transfer Frame is synchronized to the start of the LDPC codeword. We have found that in several cases, satellite and transmitter vendors are including the coding in the transmitter and find it easier to not have to synchronize the Data Transfer Frame length with the codeword message length. ScopeThis pink sheet addresses the use of the LDPC codes. In the bigger picture, we suggest that CCSDS not require that the Data (Transfer) Frame length be of the same length as the codeblock message size. Impact of Slicing on Performance

Since a code frame can contain the tail end of one data frame and the beginning of the next, the loss of one code frame can result in the loss of two data frames. However, the codes under consideration, LDPC in particular, but also SCCC, have such steep BER and FER vs Eb/No slopes that the real performance is either error free when slightly above the waterfall threshold or totally unuseable when slightly below the threshold. From a practical point of view, when using CCSDS LDPC, SCCC or DVB-S2 LDPC, there is no significant BER or FER impact. The same statement is not necessarily true for the concatenated RS+Convo codes. Even though the composite curve is also steep, the data must get through the convolutional decoder before it can get handed to the RS decoder. In many receiver implementations the convolutional curve dominates the system due to decoder lock limitations and the actual curve is not as steep as the ideal curve.


22

End to End Data Flow and Processes with NGSLP by Ed Greenberg 9/29/2013

• All frames use the NGSLP frame format each contain an ASM, a length field and a source S/C ID.

• The coding (LDPC) is performed in the physical layer in a manner such that the transfer frame is asynchronous to the code block. Thus a Code Synchronization Word (CSM) is required and is inserted between each code block forming a concatenate string of CSM and code block.

• Lander Frames are transferred to the Orbiter using a “Go back N” reliable transfer protocol. The VC of the received frames can be examined and placed into a designated buffer for selection to downlink.

• The Orbiter creates its own frames placing them into prioritized buffers for selection to downlink.

• The Orbiter provides a priority frame delivery service selecting frames from the buffers as required. Thus at the scheduled time to downlink the stored data, the orbiter pulls the framed data from the desired buffer. No processing is added and the stored frames are output serially to the radio where the data is chopped into code block sized pieces and encoded. The encoded code block is randomized then a CSM is prepended to the randomized code block and set up for transmission. This process continues till and the desired amount of data in the buffer is extracted and transferred.

• At the ground receiving station the received bit stream is searched for the CSM. Once the CSM is located a code block amount of data is derandomized and the passed to the decoder. The decoded octet stream is then searched for the ASM. After the ASM is found the frame length field is located and frame is delimited. The S/C ID and its VC are read from the frame header and using that information is passed to the pre-configured SLE RCF service. The frame is ten delivered to the mission’s data center that is designated for receiving the frames.

Note: Lander always transmits the same transfer frame and always receives the same frame. It may also be possible to provide a “bent pipe” mode by injecting low rate Lander frames into the high rate downlink.


23

NGSLP Issues

1. The Lander frame size and the Orbiter Frame size may be different. This can cause an impact on the reliable delivery process from the orbiter. The current frame retransmission approach used on MRO requires the operations team to know where the missed frames are located.

2. If the Orbiter and Lander frames are of different length the simplest solution is to store the Lander ASM with its Frame in the buffer. This increases the storage requirement but allows the frames to be extracted from the buffer without complete knowledge of where the frame boundaries are located.


24

Protocol FeaturesFormat• Larger Frame size• Increased S/C name space• Flexible frame sequence counter sizing allowing significant increase in

frame counter size• Enables frame counter to be used by security algorithm

• Inclusion of Sub-channels supports Go-back-N (COP-1) protocol• Allows a single Virtual Channel to carry frames with diverse destinations

• Common format for all links (uplink, downlink and space to space links)• Enables a Lander to use the same frames for direct to earth and relay links

• Provides the way to replace the Telecommand MAPs and Segmentation methodology by providing Sub-channels to replace MAPs and allowing packets to cross frame boundaries as per the current TM and AOS specifications.

Coding• Allows for the disassociation of the frame and the code block• Allows for the use of short code word to be combined to form a code block• Enables the coding to be limited to the transceivers as is the mode with

commercial equipment (including those being purchased for LandSat Next.

Documents

CCSDS Next Generation Space Link Protocol (NGSLP) Greg Kazz Peter Shames NASA-JPL 3-31-2014