AOS Features
This page describes some of the features of the AOS data link that are supported by the AOS Encoder Shell and AOS Decoder Shell. For the definition of the features described here, see the CCSDS recommended standards documents for AOS.
Features are listed in alphabetical order, using the terminology of the current recommended standard (CCSDS 732.0-B). Features and terminology from the original recommendations (CCSDS 701.0-B-3-S) are also described.
Asynchronous Services
In an asynchronous service, there are no timing relationships between the transfer of service data units supplied by the service user and the transmission of Transfer Frames generated by the service provider. The user may request data transfer at any time. The service provider places the requests on a queue and transmits the data units in the order in which they were presented. The timing of data transfer is determined by factors such as the priority of the Virtual Channel and the traffic at the time of transfer.
The AOS Encoder Shell and AOS Decoder Shell support the asynchronous services defined in the AOS specifications.
Bitstream Service
The Bitstream Service provides transfer of a serial string of bits, whose internal structure and boundaries are unknown to the service provider, across a space link. The service is either asynchronous (queued) or periodic. If the Bitstream Service is defined for a Virtual Channel, then there is only one Bitstream Service user on that Virtual Channel and no other services are available on that Virtual Channel.
The Bitstream Service is defined in the original and in the current AOS specifications. The AOS Encoder Shell and AOS Decoder Shell support the Bitstream Service.
Buffered services
In a buffered service, the data unit for transfer is placed in a special buffer. Whenever the user has a data unit to send, it is placed in the special buffer, overwriting any earlier contents. Whenever a frame for the service is about to be sent, the data unit is read from the special buffer and placed in the frame. Therefore, the fate of any particular data unit depends on the timing. A particular data unit may be transmitted more than once, if the special buffer is not updated between frames for the service. Also, a particular data unit may not be sent at all, if it is overwritten by another data unit before the next frame for the service.
The synchronous services in the AOS specifications are buffered services.
CADU - See Channel Access Data Unit
CCSDS Principal Network
The original AOS specification defines the CCSDS Principal Network (CPN), and the Path Service and Internet Service which provide end-to-end data transfer across it. The CPN is a network including a ground network and an on-board network, in addition to the space links.
Neither the CCSDS Principal Network nor the associated services are included in the current AOS specification. The AOS Encoder Shell and AOS Decoder Shell do not support the CCSDS Principal Network.
Channel Access Data Unit
The original AOS specification defines the Channel Access Data Unit (CADU), which consists of a VCDU or CVDCU with a prefixed Synchronization Marker. The current AOS specification does not include specifications at the synchronization level and refers instead to "TM Synchronization and Channel Coding", CCSDS 131.0-B, for use with the AOS Space Data Link Protocol.
Channel Coding
The original AOS specification defines the Coded Virtual Channel Data Unit which includes a block of error-correcting Reed-Solomon check symbols to protect the data field. The current AOS specification does not include specifications for the addition of Reed-Solomon or other coding to a Transfer Frame and refers instead to the recommendations in "TM Synchronization and Channel Coding", CCSDS 131.0-B.
The AOS Encoder Shell and AOS Decoder Shell do not include channel coding.
Coded Virtual Channel Data Unit
The original AOS specification defines the Coded Virtual Channel Data Unit (CVCDU). The CVCDU is identical to the Virtual Channel Data Unit (VCDU) except that internally its data field is shortened and a block of error-correcting Reed-Solomon check symbols is included. The VCDUs and CVCDUs that are transmitted on a particular Physical Channel are all of the same length.
In the current AOS specification, the name for a Virtual Channel Data Unit has been changed to Transfer Frame. The current AOS specification does not permit coded and non-coded AOS Transfer Frames to be mixed on the same Physical Channel.
The specifications for the addition of Reed-Solomon or other coding to an AOS Transfer Frame are not included in the current AOS specification, which refers instead to the recommendations in "TM Synchronization and Channel Coding", CCSDS 131.0-B. See Channel Coding.
CPN - See CCSDS Principal Network
CVCDU - See Coded Virtual Channel Data Unit
Encapsulation Service
The original AOS specification defines the Encapsulation Service. It provides transfer of variable-length, octet-aligned service data units that are not formatted as CCSDS Source Packets. The service provider encapsulates the user's data unit in a CCSDS Source Packet, which is then transmitted as for the Packet Service. The service is asynchronous (queued).
The current AOS specification does not include the Encapsulation Service. The Packet Service of the current AOS specification includes support for Encapsulation Packets, which may be used to carry similar data units. CCSDS now defines encapsulation services in another document: Encapsulation Service, CCSDS 133.1-B.
The AOS Encoder Shell and AOS Decoder Shell support the use of Encapsulation Packets on the Packet Service.
Error Control fields
The current AOS specification defines two optional error control fields for a Transfer Frame: the Frame Header Error Control and the Frame Error Control Field. The original AOS specification defines the same fields with the names VCDU Header Error Control and VCDU Error Control Field.
The Frame Header Error Control is a 16-bit field in the Transfer Frame Primary Header. It contains an error detecting and correcting code (Reed-Solomon) to protect address fields in the header. The Frame Error Control Field is a 16-bit field at the end of a Transfer Frame. It contains an error detecting code (CRC) to protect the Transfer Frame.
The current AOS specification has the requirement that if the Frame Header Error Control is present, then it occurs within every Transfer Frame on the Physical Channel. Similarly, if the Frame Error Control Field is present, then it occurs within every Transfer Frame on the Physical Channel. The original AOS specification permits a Physical Channel to carry VCDUs with and without the fields.
The AOS Encoder Shell and AOS Decoder Shell support the use of the Frame Header Error Control and the Frame Error Control Field. They are run-time configuration options for a Physical Channel.
Grades of Service
The original AOS specification defines three different Grades of Service:
- Grade-1 (the highest level) depends on the SLAP
- Grade-2 uses the Reed-Solomon error correction of the CVCDU
- Grade-3 uses the VCDU with the Frame Error Control Field
The SLAP is not included in the current AOS specification. The difference between Grade-2 and Grade-3 is only in the selection of coding options. The current AOS specification refers to "TM Synchronization and Channel Coding", CCSDS 131.0-B, for the specification of the coding options. Therefore, the idea of Grades of Service is not used in the current AOS specification. The AOS Encoder Shell and AOS Decoder Shell do not use the idea of Grades of Service.
Idle Data
Idle Data is data which caries no information. It is generated as needed to fill a field, such as the Transfer Frame Data Field.
The AOS Encoder Shell generates Idle Data as needed. The AOS Decoder Shell handles any Idle Data it finds in incoming frames.
Idle Packet
Sometimes, a frame for the Packet Service must be released before sufficient packet data is available to fill the frame. In this case, an Idle Packet may be used to complete the frame. Idle Packets are CCSDS Space Packets identified by a special Application Process Identifier of 63 (all ones). A system configured to use Encapsulation Packets may also use Encapsulation Idle Packets.
The AOS Encoder Shell generates Idle Packets as needed. The AOS Decoder Shell handles any Idle Packets it receives in incoming frames.
Idle Transfer Frame or OID Frame
In the case where no valid Transfer Frame Data Field is available for transmission at release time for a Transfer Frame, a Transfer Frame with a Data Field containing only Idle Data (OID) is transmitted. Such a Transfer Frame is called an OID Frame or an Idle Transfer Frame and it is transmitted on a Virtual Channel with the Virtual Channel Identifier 63 (all ones). An OID Frame does not contain any valid user data in its Data Field, but it contains the Insert Zone if the Insert Service is supported for the Physical Channel.
The AOS Encoder Shell generates OID Frames as needed. The AOS Decoder Shell handles any OID Frames it receives.
Insert Service
The Insert Service provides transfer of private, fixed-length, octet-aligned service data units across a space link. The service is periodic. The Insert Service is defined in the original and current AOS specifications. If the Insert Service is defined for a Physical Channel, then
- there is only one Insert Service user on that Physical Channel
- every Transfer Frame of the Physical Channel has an Insert Zone carrying data for the Insert Service.
The AOS Encoder Shell and AOS Decoder Shell support the Insert Service.
Internet Service
The Internet Service is an end-to-end service across a CCSDS Principal Network, defined in the original AOS specification. See CCSDS Principal Network. The AOS Encoder Shell and AOS Decoder Shell do not support the Internet Service.
Note: The AOS Encoder Shell and AOS Decoder Shell support the transfer of IPv4 and IPv6 datagrams, using Encapsulation Packets on the Packet Service.
Isochronous Service
In the original AOS specification some services are defined as isochronous. In the current AOS specification these are called periodic services.
Master Channel
The set of Virtual Channels on the same Physical Channel and which have the same Spacecraft Identifier constitute a Master Channel. A Master Channel may have up to 64 Virtual Channels.
The AOS Encoder Shell and AOS Decoder Shell support multiple Master Channels on the Physical Channel. The overall limit of 64 on the number of Virtual Channels on the Physical Channel still applies.
Master Channel Frame Service
The Master Channel Frame (MCF) Service provides transfer of a sequence of fixed-length AOS Transfer Frames of a Master Channel, created by an independent protocol entity, across a space link. The service is either asynchronous (queued) or periodic. If the MCF Service is defined for a Master Channel, then there is only one MCF Service user on that Master Channel and no other services are available on that Master Channel or on any Virtual Channel of that Master Channel.
The Master Channel Frame Service is defined in the current AOS specification. There is no equivalent service in the original AOS specification. The AOS Encoder Shell and AOS Decoder Shell support the Master Channel Frame Service.
MCF Service - See Master Channel Frame Service
Multiplexing Service
The Multiplexing Service is one of the SLS Services defined in the original AOS specification, and its purpose is to transfer packets. The Packet Service in the current AOS specification provides similar facilities. The AOS Encoder Shell and AOS Decoder Shell support the Packet Service.
Octet String Service
The Octet String Service is defined in the original AOS specification. It is similar to the Encapsulation Service, but provides an end-to-end service across a CCSDS Principal Network. Neither the CCSDS Principal Network nor the Octet String Service is included in the current AOS specification. The AOS Encoder Shell and AOS Decoder Shell do not support the Octet String Service.
Operational Control Field
The Operational Control Field (OCF) is defined in the original and current AOS specifications. Typically the OCF is used to provide the status of telecommand operations in a hybrid configuration with AOS on the downlink and Packet Telecommand on the uplink. In this case, Communications Link Control Words (CLCWs) are carried in the OCF. The use of the OCF is optional. If present, the length is 32 bits.
The current AOS specification includes a formal specification of the Virtual Channel Operational Control Field (VC-OCF) Service. The service is synchronous or periodic. If the service is in operation, then the OCF is present in all Transfer Frames for the Virtual Channel, so each frame on the Virtual Channel carries the latest available copy of the data.
The AOS Encoder Shell and AOS Decoder Shell support the use of the OCF and the VC-OCF service.
Packet Service or Virtual Channel Packet (VCP) Service
The Packet Service is defined in the current AOS specification. It provides similar facilities to the Multiplexing Service defined in the original AOS specification. It is an asynchronous (queued) service. The Packet Service carries packets which have a Packet Version Number (PVN) authorised by CCSDS: the PVNs are specified by SANA (which replaces CCSDS 135.0-B). Currently this includes the following types of packets:
- CCSDS Space Packets
- CCSDS Encapsulation Packets
Note: CCSDS Space Packets are defined in CCSDS 133.0-B. The definition combines and replaces the separate definitions of Source Packets (Packet Telemetry), TC Packets (Packet Telecommand) and the CP_PDU (from original AOS specification).
The AOS Encoder Shell and AOS Decoder Shell support the Packet Service defined in the current AOS specification. The Shells accept packets with length up to 65542 octets.
Packet Service (old-style)
An old-style Packet Service is defined in the original AOS specification. It provides an end-to-end service for transfer of packets across a CCSDS Principal Network. Neither the CCSDS Principal Network nor the old-style Packet Service is included in the current AOS specification. The AOS Encoder Shell and AOS Decoder Shell do not support the old-style Packet Service.
Path Service
The Path Service is an end-to-end service defined in the original AOS specification. See CCSDS Principal Network. The AOS Encoder Shell and AOS Decoder Shell do not support the Path Service.
Periodic Services
A periodic service is a special case of a synchronous service. In a periodic service, the service data units are transferred at a constant rate. In the original AOS specification, periodic services are called isochronous services.
If a Virtual Channel is timed to send at a fixed interval, that is, every nth Transfer Frame, then the Virtual Channel provides a fixed time slot. In this case, the Virtual Channel can provide a periodic service, for example for the Bitstream Service. Similarly, if a Master Channel is timed to send at a fixed interval, or if it is the only Master Channel on the Physical Channel, then it can provide a periodic service for the Master Channel Frame Service. The Insert Service data units are carried by every Transfer Frame on a Physical Channel, so the Insert Service is a periodic service.
The AOS Encoder Shell and AOS Decoder Shell support periodic services.
Physical Channel
A Physical Channel is a bitstream: a single stream of bits transferred over a space link in a single direction. A single instance of the AOS Encoder Shell or AOS Decoder Shell supports exactly one Physical Channel. See also Recorder.
Recorder
The AOS Encoder Shell can generate Transfer Frames with the Replay Flag set. The frames can then be written to a data recorder. This facility is intended for use when the physical space link is unavailable or overloaded. Later, the frames are read from the recording device and passed to the Shell where they are (optionally) multiplexed with other 'live' frames and transmitted on the space link.
The AOS Encoder Shell handles data for the recorder and for the space link as separate streams and uses separate scheduling vectors for multiplexing within each of the two streams.
SLAP
The original AOS specification contains a section on the Space Link ARQ Procedure (SLAP), a retransmission procedure intended to support Grade-1 Grade of Service. The SLAP is not included in the current AOS specification. The AOS Encoder Shell and AOS Decoder Shell do not support the SLAP.
SLS - See Space Link Subnetwork
Space Link ARQ Procedure - See SLAP
Space Link Subnetwork
The original AOS specification defines the Space Link Subnetwork (SLS), also called the Space Link Subnet. The current AOS specification is generally concerned with data transfer over a single space link. The services defined in the current AOS specification are similar to the SLS services defined in the original AOS specification. An instance of the AOS Encoder Shell or AOS Decoder Shell supports a single Physical Channel, so is therefore concerned with data transfer over a single space link.
Synchronous services
In a synchronous service, the transfer of service data units is synchronized with the release of Transfer Frames of a channel. The channel is either a Virtual Channel, a Master Channel, or a Physical Channel. For a Virtual Channel or a Master Channel, the transfer timing may be periodic or aperiodic. For a Physical channel, the timing is periodic. See Periodic Services.
The synchronous services in the AOS specifications are buffered services. The AOS Encoder Shell and AOS Decoder Shell support the synchronous services defined in the AOS specifications.
Transfer Frame
AOS Transfer Frames are the fixed-length protocol data units used by the AOS service to transfer data through the space links. AOS Transfer Frames are also called Version-2 Transfer Frames. In the original AOS specification, the frames are called Virtual Channel Data Units (VCDUs).
The Transfer Frame is of fixed length for a given Physical Channel. Each Transfer Frame contains a header which provides protocol control information and a fixed-length data field which carries higher-layer service data units.
The AOS Encoder Shell generates AOS Transfer Frames. The AOS Decoder Shell accepts AOS Transfer Frames.
NOTE: The AOS Encoder Shell and AOS Decoder Shell are AOS products to handle CCSDS Version-2 Transfer Frames as defined for the AOS Space Data Link in CCSDS 732.0-B. Our Telemetry Encoder Shell and Telemetry Decoder Shell handle CCSDS Version-1 Transfer Frames as defined for the TM Space Data Link in CCSDS 132.0-B.
Transfer Frame Data Field
The Transfer Frame Data Field is the part of each Transfer Frame which is available to carry data for the Packet Service, the Bitstream Service or the VCA Service. In the original AOS specification, this is called the VCDU Data Unit Zone.
VC_OCF Service - See Operational Control Field
VCA Service - See Virtual Channel Access Service
VCDU - See Virtual Channel Data Unit
VCF Service - See Virtual Channel Frame Service
Virtual Channel
Multiple Virtual Channels can share the capacity of a single Physical Channel. The Virtual Channels are assigned transmission capacity on a frame-by-frame basis.
A Virtual Channel (VC) is identified by a Virtual Channel Identifier and a Spacecraft Identifier. Typically, Virtual Channels are used to separate sources or destinations with different characteristics. For example, an instance of the Bitstream Service uses a different VC from the VCs being used for the Packet Service. See also Master Channel and Virtual Channel Multiplexing.
The AOS Encoder Shell and AOS Decoder Shell support up to 64 Virtual Channels on the Physical Channel.
Virtual Channel Access Service
The Virtual Channel Access (VCA) Service provides transfer of a sequence of privately formatted service data units of fixed length across a space link. The service is either asynchronous (queued) or periodic. If the VCA Service is defined for a Virtual Channel, then there is only one VCA Service user on that Virtual Channel, and no Packet Service or Bitstream Service is available on that Virtual Channel. The Virtual Channel Access Service is defined in the original and current AOS specifications.
The AOS Encoder Shell and AOS Decoder Shell support the Virtual Channel Access Service.
Virtual Channel Data Unit
In the original AOS specification, the frames are called Virtual Channel Data Units (VCDUs). See Transfer Frame.
Virtual Channel Data Unit Service
The Virtual Channel Data Unit Service is one of the SLS Services defined in the original AOS specification. The Virtual Channel Frame Service in the current AOS specification provides similar facilities.
Virtual Channel Frame Service
The Virtual Channel Frame (VCF) Service provides transfer of a sequence of fixed-length AOS Transfer Frames of a Virtual Channel, created by an independent protocol entity, across a space link. The service is either asynchronous (queued) or periodic.
If the VCF Service is defined for a Virtual Channel, then there is only one VCF Service user on that Virtual Channel and no other services are available on that Virtual Channel. The Virtual Channel Frame Service is defined in the current AOS specification. The equivalent service in the original AOS specification is the Virtual Channel Data Unit Service.
The AOS Encoder Shell and AOS Decoder Shell support the Virtual Channel Frame Service.
Virtual Channel Multiplexing
The streams of Transfer Frames from the Virtual Channels (and from any Master Channels using the MCF Service) are multiplexed into the single Physical Channel. The AOS Encoder Shell uses a scheduling vector for this multiplexing. The user can configure the multiplexing, using up to three levels of vectors. The vectors can be fixed, priority or round robin.
Fixed: Each time the channel occurs in the scheduling vector, it is given the opportunity to send a frame.
If it has no frame available at that time, an Idle Transfer Frame (OID Frame) is sent instead.
Priority: The first channel in the vector is given the opportunity to send a frame. If it has no frame
available at that time, the next channel in the vector is given the opportunity, and so on. If none of the
channels has a frame available at that time, an Idle Transfer Frame (OID Frame) is sent instead.
Round robin: Similar to priority, but when one of the channels in the vector sends a frame,
then the next time the scheduler processes the vector, it starts at the following entry.
NOTE: For a periodic service on a Virtual Channel or Master Channel, the channel requires an entry in a fixed, top-level scheduling vector.
Virtual Channel Operational Control Field Service - See Operational Control Field
Virtual Channel Packet (VCP) Service
The Virtual Channel Packet (VCP) Service is the new name for the Packet Service.