Source packets are blocks of data of a given size, sent with a header that defines their instrument source as well as their
size. The packet size (length in bytes) is more determined by the instrument source and the manufacturer rather than the
CCSDS protocol layers. This usually means that the packets don't fit in the 886 byte user data space in the underlying
VCDU layer. Thus, the packet boundaries appear randomly throughout the VCDU data zone and can sometimes even
cross the boundary between successive VCDUs. As such, we need a mechanism to identify these packet boundaries in
order for us to retrieve each packet. The MPDU sub-layer provides this mechanism.

The MPDU sub-layer is technically part of the data link layer, layer two. It is simply an extra few bytes after the VCDU
header that point to the first packet header contained in the data zone. Awkwardly, there are two versions of this MPDU
header structure. So far, it seems that polar orbiters use a 4 byte header and geostationary satellites use a 2 byte header.
The last two bytes (only two bytes for LRIT etc) contain an 11 bit value representing the byte offset to the first byte of
any packet header minus 1. If no packet header is present then the value will be set to all ones - 7FFh. For LRPT, the
2 byte 'vcdu insert zone' is intended to be used for encrytion control. If set to all zeroes, then encrytion is not enabled.
So far, Meteor LRPT remains un-encrypted - thankfully.

The diagram below shows the location of the MPDU header within the 1024 byte CVCDU line structure.

How do we use this header offset number? On the surface it looks easy - just step into the MPDU data field the indicated
amount of bytes and then collect the 6 byte packet header, read out the length value and recover these remaining data
bytes. But you can quickly see that there are several 'boundary' conditions that come along and spoil things. The problem
of packet boundaries being in variable positions can be broadly divided into four separate situations.
1) There is no packet header present in the current data zone. The MPDU pointer is set to all one's (7FFh).
All the data is part of a packet that started in an earlier VCDU/MPDU.
2) There is one packet header in the current data zone. The first-header pointer indicates the byte position of
this header. The data before this position belongs to the previous packet. The data after the header belongs to that
packet - up to the end of the data zone. The end of the packet is in a following MPDU.
3) There are 2 or more packet headers in the data. The MPDU first-header pointer points to the start of the first header.
The packet length is short enough that it doesn't reach the end of the current data zone. The next packet header follows,
along with its data. If the packets are short enough there can be three or more packets in a single MPDU.
4) The situation can arise where the packet header is split across two MPDUs. The first few bytes of the packet header
are at the end of the current MPDU and the remaining bytes are in the next one. In this second MPDU, the first-header
pointer does not point to this partial header. The start of the header has already been defined in the first MPDU.

Remember, for HRIT/LRIT from the geostationary satellites the MPDU header is only 2 bytes and the data zone is 884
bytes long. Otherwise, the process of recovering the packets is all the same.

BACK