We now move away from the physical layer, which has been focused on recovering the satellite data from the receiver
and delivering it as error-free as possible. The CCSDS protocol stack from layers two to seven is orientated about
delivering data from each differnet sensor or source on the spacecraft to the appropriate user application program at
the reception site. Layer two introduces the Virtual Channel layer. The idea is simply a case of setting up the concept
of 64 destination addresses, or mailboxes if you like. It is a routing layer that says "this data is from sensor/source X and
therefore needs to go to processing program Y". The satellite manufacturer supplies a list of datastreams coming from the
sensors and pairs them up with one of the 64 addresses (0 - 63). The whole datastream is assembled and transmitted
over the physical link. On the ground the signal is received and the virtual channel number is used to separate out the
different data sources. For example, Metop has about a dozen different instruments/data sources in its AHRPT downlink
- including the imager data several different microwave sounders and other telemetry and space environment monitoring
sensors. Each of these is assigned a virtual channel number before being bundled together for transmission. In Meteor
LRPT, for example, the imagery is placed in virtual channel address 5 for transmission and on the ground the CCSDS
layer two software collects all the "address 5" VCDU data for further processing.

The virtual channel data unit, or VCDU, is made up of the 892 byte payload in the CADU/CVCDU's that came from
the physical layer processing and the Forward Error Correction (Reed-Solomon decoding). A CVCDU, or coded
virtual channel data unit is simply a VCDU with the 128 R-S bytes appended.

The VCDU is made up of a six byte header field and a 886 byte data payload field. The header is, in fact, the first six
bytes and contains all the information to allow you to confidently identify where the data is from and where it should go.

Here is the VCDU header description from the MTSAT HRIT/LRIT specification.

For Meteor LRPT, the first and second bytes of the VCDU header are (as much as I have seen) either 40h, 05h or
40h, 3Fh. This means that with the 2 version type bits set aside that the spacecraft ID is currently zero. My guess is
Russia has yet to apply for an official CCSDS SSID number for Meteor-M-N1, or that they have simply chosen not
to opt in on this part of the CCSDS scheme.
The lower 6 bits of the second byte contain the VCID. Imagery data appears in all the VCID=5 frames and should be
collected and passed along to the next stage of processing. VCID=63 (3Fh) all contain zeroes. These are known as 'fill
VCDUs'. The next 3 bytes are a 24 bit counter that simply rolls over at some point (on MTSAT HRIT is is not
0xFFFFFF!) and starts again at zero. This count can be used to check on your downlink performance - it should always
increment by one or be all zero (rollover).The last byte of the header is all zero. Some documentation states that the replay
bit can be used to signal that the data has been recorded and is being replayed after the event. For 'live' data this bit
should be zero, and along with the spare bits, the whole byte should be zero.

FILLER DATA
As previously stated, the virtual channel ID number can range from 0 to 63. Imagery and other sensor
data can be sent using any of the VCID addresses from 0 to 62. VCID 63 is reserved for what is known as "fill" data.
For a number of reasons there can be periods when no actual data is ready or available to be sent. Rather than turn off
the RF downlink signal altogether, the spacecraft sends "filler data", which is simply all zeroes packed up in the VCDU
data zone. These zero bytes are always sent using the reserved VCID of 63 (0x3F). The VCDU header has all the same
structure as other VCDUs. It runs its own separate VCDU counter just like the other ID numbers do. Other than for
gathering link/reception performance statistics, these fill VCDUs can be ignored at this stage as they are not involved
in any further processing.