ASTERIX CAT-240 Protocol For Video Data

Overview

Introduction

The Eurocontrol Standard Document for Surveillance Data Exchange, Category 240 (henceforth referred to as “CAT-240”) describes the application of ASTERIX to the transmission of rotating radar video.

This document describes the Navtech Radar implementation of CAT-240. It is not intended to replace CAT-240; rather it describes how the standard has been implemented and provides clarification, including details of any assumptions made, any limitations that apply and any Navtech-specific extensions that are provided. It is recommended this document is read in conjunction with CAT-240.

This document is applicable to the development of a client application that receives network radar video in ASTERIX CAT-240 format from a Navtech radar system.

Field Representation

The CAT-240 standard defines messaging fields in terms of (groups of) octets; and, in the case of individual bits, field reference numbers.  Such definitions are independent of any particular implementation.

For this document, field layouts are defined in terms more consistent with, and more familiar to, common programming languages such as C or C++.

Message structures are always defined in declaration order.  That is, in ascending address order.

Fields sizes are specified using Posix type aliases.

Where multi-byte fields are depicted, the least-significant byte is shown on the right; the most-significant byte is shown on the left.

Where individual bits in a field are significant (that is, bit field types) bit numbers are specified from zero.  The least significant bit is always depicted on the right; the most-significant bit on the right.

Note, the depiction of multi-byte fields does not imply endianness.  See section 2.3 for more details on byte ordering.

Data Transmission

Network Transport

CAT-240 messages are sent as UDP network packets.

The radar may unicast UDP packets to a single client, or multicast UDP packets for receipt by multiple clients.

The IP address and port used by the radar to send CAT-240 message are configurable options.  By default, the following address and port are used:

Table 1 - Default IP address and port for CAT-240 data

Supported Message Types

CAT-240 defines two message types:

• Video summary messages

• Video messages

Navtech only supports Video messages.  This document therefore only specifies Video message requirements.

Video summary messages may be supported in future releases.

Data Framing & Rates

Video data from a Navtech radar is sent on an azimuth-by-azimuth basis.  The data for each azimuth is a sequence of bins (range cells), each representing a power level at a distance from the radar.  The first value represents the bin closest to the radar.

Each CAT-240 message encapsulates a single azimuth’s worth of data.

The maximum number of bins for each azimuth is a configurable property of the radar.

Radar data may be contoured, meaning the number of bins in each message could change on an azimuth-by-azimuth basis.

The number of CAT-240 messages generated is a factor of:

• The number of azimuths sampled per rotation

• The rotation rate of the radar

The number of azimuths sampled for each rotation and the rotation rate of the radar depend on the radar model.

For example, a radar may generate 400 azimuths per rotation, and rotate at 4Hz, giving a message rate (or Packet Rate Frequency, PRF) of 1600 messages/sec

Byte Ordering

All data is sent as Network (that is, Big) endian.

Clients may therefore have to performing byte-swapping on multi-byte words to retrieve data correctly.

Message Structure

Overview

A CAT-240 message is illustrated in Figure 1.  It consists of five main elements:

• A data block, containing basic message details

• The video data header, which defines the context of the video data

• The video (FFT) data

• A time-of-day field

• A special-purpose field containing Navtech-specific extended information

Open

Figure 1 - CAT 240 message structure overview

Message Data Block

The message data block defines basic characteristics of the message and the specific configuration of the message.

The structure of the message data block is shown in Figure 2

Open

Figure 2 - Message data block layout

Feature Specifications

The Feature Specification bit field structure defines which fields are present in the message and, in the case of optional features, which option(s) have been selected.

The feature specification is laid out as shown in Figure 3.

For the Navtech implementation of CAT-240 some fields are mandated.  Figure 3 shows the default flag settings.  Note, in the cases where bit field values have not been specified these fields will be set according to the supplied video data.  See later for more details.

Video Header

The video header provides the context for the FFT data packaged in the message.

In the Navtech implementation of CAT-240 a video message represents a single azimuth of data.

The video header is structured as shown in Figure 4. CAT-240 field references are provided for cross-reference.

Data Source Identifier

The Data Source Identifier provides a unique identifier for the radar source.  The Data Source Identifier is a 16-bit field structured as shown in Figure 5.

For Navtech, the values of the SIC/SAC values are set to

Start & End Azimuth

A Navtech radar outputs its FFT data on discrete azimuths.  The number of azimuths sampled per rotation depends on the radar; and is configurable.

A CAT-240 message requires the azimuth start and end to be specified as an 16-bit angle, with a resolution of 1/360 degree.

and for extracting the angle:

Data is sent on a per-azimuth basis, with the start and end fields determined as follows:

·        The end azimuth is set to the angle of the current azimuth.

·        The start azimuth is set to the angle of the previous azimuth

Azimuth angle is calculated as follows:

Similarly, the current azimuth can be calculated from the angle:

The number of azimuths in a full rotation is not a defined field in CAT-240.  Therefore, this value is provided as part of the Special Purpose field.  See XXXXX for more details.

Cell Duration

Cell duration defines the size of an FFT bin in femtoseconds.

Cell duration is calculated as follows

Where c represents the speed of light (defined as 299, 792, 458 ms^-1).

By extension, the range of the range of the radar can be calculated as

Where fsec represents 1 femtosecond in seconds – 10^-15 sec. 

Range in bins is not part of the CAT-240 standard message, so is included in the Special Purpose field extended data.

If non-contoured data can be assumed, then the range in bins will be the same as the video block cell size.

Resolution

The resolution field defines two properties of the message

·        The resolution of the FFT data, in bits

·        Whether the data is compressed

The structure of the resolution/compression field is shown in Figure 6.

Radar data is never compressed.  The MSB of the resolution/compression field will always be zero.

The resolution is defined as an encoded value, as shown in the table below.

Note, for Navtech radars, only 8-bit or 16-bit data will be transmitted.

Data Size In Bins

The number of bins in the message is calculated as

Where resolution in bytes must be computed from the resolution/compression field value.

Video Data

The video data block holds the FFT data.  It is structured as shown in Figure 7.

CAT-240 frames video data into fixed-sized blocks.  The size of each block and the number of blocks depends on the size of the FFT data.

Video Data Block Size

The framing configuration for an incoming message is specified with two fields:

• The feature specification bits low data volume, medium data volume and high data volume define the size of a block (See 3.2.1)

• The Block field defines the number of blocks contained in the message.

The block size is defined in the table below.  Note, the data volume flags are mutually exclusive; at most one of the fields must be set.

If the number of bytes in the FFT data is not an exact multiple of the video block size, then the number of video blocks is rounded up. Any unused bytes used to pad the last video block are set to zero.

NOTE:

For extracting FFT data, client applications should use the NB_VB field, as this gives the actual size, in bytes, of the FFT data.

For extracting the Time-of-day (and any other subsequent fields) client applications must use REP * block size to calculate the alignment correctly.

Time-Of-Day

Time-of-day is an absolute time stamp, expressed in UTC.  The time-of-day is reset each day at midnight; that is, the time-of-day holds no date information.

Time-of-day is stored as a 24-bit number, interpreted as an integer fixed-point representation, as shown in Figure 8

The time-of-day field uses an 8-bit value for the sub-seconds; therefore, time resolution is 1/128 sec – 7.8125 msec. 

For a radar sampling 400 azimuths per rotation, at 4Hz, each azimuth message is generated every 625 microseconds.  Time-of-day is too low resolution to use for precise azimuth timing.  To expedite this, precise azimuth timing, to nanosecond resolution, is supplied in the Special Purpose field.

Special Purpose Field

The Special Purpose Field allows an application to include custom data that is not specified in the ASTERIX standard. This field includes more detailed information describing the format of the data than is supported by the ASTERIX standard.

For Navtech radars, the Special Purpose field is defined in Figure 9.

Radar Health Status

Radar health status provides information on the current operating status. The field is encoded as a bit field, as shown in Figure 10.

Each bit field is encoded with two bits.  The value of the bits indicates the health status of the property, as shown by the table below.

Endianness & Field Layout

Network Endian Encoding

Bit Field Structure Layout

Example Video Message

Below is an example video message with representative values for each field.  This message is designed to be used to validate client application decoding.

Field values are given in big endian (network order) and little endian, as well as decimal (when relevant).

The video message is for a radar system producing data as follows:

• Rotation rate – 4 Hz

• Azimuths per rotation – 400

• Radar range in bins – 2856

• Radar range in metres – 500m

• 8-bit (high) resolution, no compression

Message Block

Video Header

Special Purpose Field

Packet Fragmentation

Encoding an azimuth into a single Video Message will result in a UDP network packet that may exceed the size of the MTU (Maximum Transmission Unit) for the network. A typical value for the MTU is 1500 bytes, which is smaller than a typical azimuth FFT message.  If the operating system supports Jumbo Frames the MTU may be as high as 9kB.  This may be adequate for typical radar returns, but longer-range radar azimuth data may still exceed this.

The operating system at the sending end will normally split the outgoing packet into fragments that are smaller than the MTU. The operating system at the receiving end will recombine the fragments to rebuild the packet, which is then passed to the receiver. This process of IP fragmentation and recombination is completely transparent to both the sending and receiving applications.

However, at the packet rates associated with typical radar data streams there is a potential problem with typical MTU sizes, which can lead to significant data loss.

The ID field in the IP header in a UDP packet is used by the networking system to recombine fragmented UDP packets.  For a typical data rate (PRF) of 1600 messages/sec this ID field will rollover approximately every 41 seconds.

Consider a case where a message is split into 4 fragments by the networking system, but one of those fragments is lost (UDP does not guarantee delivery).  The OS will hold the (delivered) three fragments of the packet in a reassembly buffer, waiting for a byte that will never arrive.  However, after 41 seconds, the ID field would have wrapped around and a fragment with a ‘correct’ ID will be received.  This will complete the packet in the reassembly buffer but will result in a corrupt packet.  Furthermore, even though all 4 fragments of the current message were delivered, one of the fragments has now been appropriated for the previous message, meaning the current message is now ‘broken’. This self-propagating problem can lead to the reassembly buffer growing continually.  The result is that a small packet loss can cascade into a major data loss and hence loss of radar data.

Fragments are discarded if they are not completed within the Packet Reassembly Timeout. On Windows, this is set at 60 seconds, so PRFs that cause the ID value to wraparound faster than that are susceptible to this problem. On Linux the PRT is configurable; although a balance must be made between the requirements of a lower timeout value for radar distribution, and a higher value that might be necessary for other networking operations.

More information on this topic can be found in RFC 4963 at http://tools.ietf.org/html/rfc4963 .

To minimise this problem, larger video messages can be split into multiple smaller messages, each less than the MTU in size.  The receiving client must then re-combine these messages into a single azimuth return.

To illustrate this, the example message of Appendix B will be used.

Given an MTU of 1400, the message will be split into three smaller messages, that each fit completely within the MTU.  The messages will be generated as shown in Figure 13.  In the figure, fields which do not change between messages are shaded.  That is, the fields from the original (un-split) message will be replicated across each of the fragmented messages.

Notes:

• The video block will remain aligned to the (original) block size, so the payload will be the largest whole block size that can be contained within the MTU

• The payload size will be constrained by the fixed-sized fields – the message block and video header

• The payload size will be further constrained if the message contains a time-of-day and/or special purpose field

• Fields such as the time-of-day and special purpose fields are replicated across each fragment message; that is, the time-of-day and any other azimuth-specific data will remain the same for the entire azimuth.