Packet Sequencing

The use of the packet sequencing fields within the JAS packet is different from the definition in the CCSDS and PUS standards. The original intention of the packet sequence counter was to provide two functions. First, it was used in combination with the sequence flags to reassemble data sets that spanned across multiple packets. The sequence counter would increment while the sequence flags were set to “continuation packet” to help reassemble all of the middle packets. Second, applications could use it as a consistency check to ensure that they were receiving packets in order. This is why each application would have a separate sequence counter for each DAPID. For example, if an application sends a series of commands, it is desired that those commands be executed in the order they are sent. The receiving application uses the sequence counter to order the commands and determine if any were missing.

CCSDS and PUS intended that applications would create packets directly so they would have to manage the sequence counter(s) internally. This violates the goal of JAS which intends to support a variety of packet formats, protocols, and data links without having to redevelop the applications. Refer to the section regarding CCSDS SOIS in the Communication Profile and its use in JAS. Projects may want to use a legacy packet format instead of the JAS packet format and that is difficult if the packet processing software is developed within every application. The intention of JAS is to move the functions required to process packets into a standalone service, the JAS Packet Service, to allow the applications to share it and become more agnostic to the communication architecture. Having a standalone JAS Packet Service also allows it to be reused in different projects.

The TID was added to the JAS Packet for two reasons, both of which allow applications to be more decoupled from the processing functions of the JAS Packet Service. First, it is used to move the function to determine if commands, or telemetry messages, were being received in order, to the applications. Applications need this type of information but they don’t need to know the internal processing functions of the packet service to get it. Second, it is used in request/response situations, so applications sending commands can track the results they receive to ensure they get a response. There are many instances where this might be useful. One example would be, if an application on a CH node needs to send multiple data query commands to an application within an RP node. The application would respond to each data query command with a telemetry message. Each telemetry message would contain the data that was read and the transaction identifier that was in the original command. The commanding application can then make sure it received all of the responses and can map the appropriate response with the original requests.

Because of the TID, the only function required by the sequence counter for JAS packets is to handle reassembly of data that spans across multiple packets. It is still useful to have the sequence counter be a continuous rolling counter instead of resetting it each time data needs to be separated into multiple packets. It can be used during troubleshooting to help ensure that data coming from a single packet service has not been lost since the stream of packets will have sequential values based on a 14-bit counter.

The sequence numbers for a particular transaction shall be contiguous. Applications shall pass a set of data to the packet service using a single TID. The packet service shall service one transaction at a time, segment the data if needed, and send the data with the appropriate sequence counts, before handling another transaction from an application. This helps guarantee that the receiving packet service receives the packets in order and with a contiguous sequence count so they can be reassembled properly.

The next two figures show examples to help reinforce the discussion of how sequencing should be implemented. The first example shows a single application sending multiple transactions through the packet service. The second example shows multiple applications sending multiple transactions through the packet service.

The next figure shows an example of a request/response scenario and how the sending and receiving applications should respond. In this case, each packet service maintains its own sequence counter which is shown in the packets in the center. The sequence counters are independent of each other but they still maintain contiguous counts for the packets that are sent.

Packet services shall be able to receive packets simultaneously off multiple data links within the system. The packets for multiple transactions may be interleaved and the packet service must be able to create appropriate data streams, based on SAPID, in order to reassemble the data correctly. The sequence counter can be used to ensure each transaction of packets is reassembled correctly.

The TID is not required to be used in every situation. Since there are different ways to use the TID, JAS allows the services to define the use of the TID as needed. If a service doesn’t need the TID, it can be set to zero.