JAS Command Packet

All fields are shown in bits. The variable length application data field must be an integral number of bytes for the packet error control calculation. Spare bits may be used for padding purposes at the end to ensure the packets are an even number of bytes in length.

Note: The definition of a CCSDS space packet says the maximum size of a packet can be 65542 bytes, 6 bytes for the primary header plus 65536 bytes of packet data. It also says that the maximum packet length can be less than this if desired. For JAS we have chosen to have a maximum packet length of 65536 bytes.

For command packets the packet fields will be used as follows:

• Version Number – Set to 000 which is the default PUS version. This field replaces the CCSDS packet version.

• Packet Type – Set to 1 meaning this is a command packet.

• Data Field Header Flag – Set to 1 as PUS packets use a data field header.

• Destination Application Process ID – Referred to as the DAPID for command packets. This is the destination application identifier for the packet.

• Sequence Flags – Used if a sequence of packets is sent as part of a single command, an example would be sending a large data file that spans multiple packets. The packet sequence counter is used in combination with the sequence flags to ensure the command is reassembled in order. If the command data fits within a single packet, the packet is a stand-alone packet. The interpretation of sequence flags shall be:

• 01 means first packet of a sequence of packets;

• 00 means continuation packet;

• 10 means last packet of a sequence of packets;

• 11 means “stand-alone” packet.

• Sequence Count – Used by the JAS Packet Service to ensure that data that is segmented into more than one packet can be received and reassembled in order. There is one sequence counter for each JAS Packet Service (i.e. each packet generator) and it will increment each time a packet is generated. Once initialized, the counter should continue to count up. It should never reset. The counter wraps around from 214-1 to zero. This field was redefined from the original CCSDS/PUS specification.

• Packet Length – Number of bytes in the packet data field, which includes the packet secondary header, packet data and error control bytes, minus 1. The maximum length of a JAS command packet is 65536 bytes; 6 bytes are required for packet primary header, 6 bytes are required for the secondary header, up to 65522 bytes for the packet data and 2 bytes are required for the error control.

Note: By CCSDS definition there must be at least one byte in the packet data field portion of a CCSDS packet which in the case of JAS would be the packet secondary header and error control fields which are required on every JAS packet.

• CCSDS Secondary Header Flag – Set to 0 meaning this is a “non-CCSDS defined secondary header”. The requirement for this bit to be in the secondary header was deleted in CCSDS 133.0-B-1, Annex C2.3 [ 5]. Since the PUS specification being used is based on CCSDS 203.0-B-2 [ 6], this bit will continue to be used.

• JAS Version Number – Set to the current JAS packet version. This field replaces the PUS packet version number.

• Ack – This field shall be used by applications that receive commands to indicate status. The receiving applications will respond with a telemetry message to the SAPID using the Transaction ID of the command for each of the four configuration states that are set to a one value. A value of ‘1111’ means that there will be at least four different responses. The definition of the which commands will use the acknowledgement bits and the receiving applications exact behavior will be defined by the service and subtype fields that are used. If a project chooses not to use command acknowledgement they can set these bits to a value of ‘0000’.

• 0000 no acknowledgements shall be sent

• 0001 acknowledge acceptance of the packet by the application process

• 0010 acknowledge start of execution

• 0100 acknowledge progress of execution

• 1000 acknowledge completion of execution

• Service Type – Referred to as the ST. One of the PUS standard, JAS standard, or project-specific packet service types (see section on JAS Packet Services).

• Service Subtype – Referred to as the SST. One of the PUS standard, JAS standard, or project-specific packet service subtypes (see section on JAS Packet Services).

• Source Application Process ID – Referred to as the SAPID for command packets. This is the source application identifier for the packet.

• Transaction ID – Referred to as the TID. Used by applications to provide a unique identifier for commands (i.e. transactions). A single transaction can be partitioned into multiple JAS packets, each with a different sequence counter value. The transaction identifier will be the same for all of the packets in that transaction. The JAS Packet Service uses the sequence counter to process at the packet level and applications use the transaction identifier to process at the command level. The exact definition and use of the transaction identifier will be defined by the service types and subtypes that use it (see section on JAS Packet Sequencing for a more detailed description). If the transaction identifier is not used it can be set to zero.

• Application Data – The data element of the service request (see section on JAS Packet Services). This must be an integral number of bytes in length.

• Packet Error Control – CRC word (see section on JAS Packet Error Control). This is calculated over the entire packet.