Timing Measurement Tools for IP Based Air Traffic Management
Welcome to another September, 2017 issue of GL Communications' Newsletter providing information and insight into Timing Measurement Tools for Next Generation Air Traffic Management (ATM) Networks.
Overview
The latest European Organization for Civil Aviation Equipment (EUROCAE) ED-137 inter-operability standards, address migration and implementation of IP based technology for voice services for air traffic control. Though migrating to an IP network provides convergence advantages for traffic and interoperable network elements from various vendors, it also poses challenges - of variability of different implementations by equipment vendors. Some of these are: Implementation of technologies with varied jitter buffer, packetization, digital signal processing algorithms, VOX operations, and switching from idle to active state. These implementation differences impact end-to-end delay requirements imposed by various industry standard bodies.
Characterizing and limiting these impairments is critical to the performance of the system as a whole. Rigorous methods are needed to precisely measure the delay introduced by each network element as events propagate end-to-end. Recognizing, capturing, timestamping, and correlating events at Analog, TDM and IP interfaces are necessary. Delay measurements should be conducted repeatedly to ensure that the device and network under test is performing as expected consistently over time.
Product Overview
Typically, in a VoIP ATM network, the following network delay measurements are of primary interest:
- Transmitter activation delay
- Aircraft call indication delay
- Ground transmission voice delay
- Transmitter activation and aircraft call indication loopback delay
- Ground reception voice delay
- Ground transmission and reception voice loopback delay
- Frequency key activation response time and more
Some of the standards bodies like the Federal Aviation Administration (FAA) in the USA has published specification for NVS system defining timing requirements in detail. (ref: FAA-E-NVS1_NVS-Specification_v1_1_2012-01-10 document: refer Table 3-9) which details the Setup/Teardown Throughput Timing Requirements during Peak Busy Hour (PBH) and Peak Busy Minute (PBM).
Also shown below, are timing requirements extracted from EUROCAE standards document: (ED-136 - VoIP ATM System Operational and Technical Requirements Final Draft 2.0_Oct2008 refer Fig:10 and Fig:11)
To perform these timing measurements, one can setup MAPS™ TM-ATM (Timing Measurements in Air Traffic Management) tools at appropriate strategic interfaces. GL’s MAPS™ TM-ATM is a custom suite of test tools, designed to accurately measure various types of delay occurrence in signaling and voice transmission. It includes all necessary hardware and software to identify, capture, timestamp, and correlate events at Analog, TDM and IP interfaces.
MAPS™ TM-ATM is script based and API driven product that can be reused for various purposes during test cycles.
Tools used for Timing Measurement
The MAPS™ TM-ATM server components can be broadly categorized into two sets based on the underlying hardware:
- Packet Analyzer, Packetizer and Event Data Logger - all these are based on the same GL’s PacketExpert™ Ethernet/IP hardware; their functionalities differ through scripts that cater to different needs of test cycle
- Audio Analyzer - this is based on VQuad™ Dual UTA hardware; its main functionality is to simulate radio calls from CWP
All components of MAPS™ TM-ATM are controlled by a centralised component called MAPS Master Test Controller (MAPS MTC). MAPS™ TM-ATM support a client server model, with components acting as servers, the MAPS-MTC acts as a client and controls all components acting as servers, from a centralised location.
MAPS Master Test Controller
Audio Analyzer - The Audio Analyzer is a 4-wire audio device that can connect to a CWP and emulate a controller by activating PTT and transmitting audio. It supports PTT interfaces to connect to CWP Dual Jack Module and other 4-wire interfaces. It can send a PTT signal through 4-Wire interface exactly as though a real user is holding PTT on his/her headset. It can also inject and record analog signals at CWP, Radio and VoIP gateway interfaces. The analyzer can generate TTL for different actions (PTT ON, PTT OFF, Send Audio, Detect Audio). The Audio Analyzer can also be utilized in other areas of the network where analog audio signals are present.
Audio Analyzer
Packetizer - The Packetizer monitors the TTL output from the Audio Analyzer and generates a IP packet corresponding to the signal of interest. The packets generated by the Packetizer are named as Discrete Events. This indicates a certain event has occurred. The Packetizer samples the TTL inputs on a regular interval, for every trigger pulse received, it generates and transmits a timestamped packet indicating which pulse it received
Packetizer
Packet Analyzer - It functions like a highly precise Ethernet tap. It acts as a transparent Ethernet link in which bidirectional Ethernet traffic flows through at line rate. Additionally, Packet Analyzer can filter certain packets of interest from both directions without disturbing the traffic. The filtered packet's first 12 bytes of the MAC header is modified (overwritten) with useful information such as the filter number, port number, and device ID. These modified packets generated by the Packet Analyzer are named as Timed Events, and are forwarded to the Event Data Logger. The Packet Analyzer can aggregate filtered and modified packets from both directions and forward over a single output port. Packet Analyzer also supports generating output TTL signal pulses for every filter match, so that the TTL signal (representing the Filter match) can be taken out, and processed using an external device like Oscilloscope.
Packet Analyzer
Event Data Logger - The Event Data Logger is located at a central location and receives the event packets forwarded from the various Packetizers or the Packet Analyzer systems throughout the network. It timestamps each received packet, decodes the packet to extract information, and updates both Discrete Events (from the Packetizer) and Timed Events (from Packet Analyzer) to the MAPS™ Controller. It utilizes an onboard 2 GB DDR2 memory to temporarily store the received packets before being transferred to the MAPS™ Controller for analysis.
Event Data Logger
MAPS™ MTC - The MAPS™ MTC is a control/logging application, and it uses TCP/IP to send commands to and receive notifications from all the above-mentioned tools. MAPS™ Controller will calculate the time difference between posted events, i.e., Discrete Events (from the Packetizer) and Timed Events (from Packet Analyzer) and reports precise measured delay at different points in the network.
For example, the time from which an Air Traffic Controller depresses the PTT until the IP stream indicates that the PTT bit is set - is an important testing scenario. A remotely located MAPS™ Controller can instruct GL's Audio Analyzer (acts as an Air Traffic Controller) connected to a CWP to activate PTT and simultaneously generate a TTL trigger. The Packetizer connected to the Audio Analyzer can detect the TTL trigger and generate a IP packet corresponding to the signal. This is posted as a Discrete Event to the Event Data Logger. On the IP side, GL's Packet Analyzer which is monitoring the line non-intrusively can detect the packets of interest (e.g. first RTP packet with PTT bit set) based on the filters set and posts an Timed Event to Event Data Logger. Centrally located the Event Data Logger time tags these received events and reports these events to the MAPS™ Controller. The MAPS™ Controller will calculate the time difference between different events posted and reports the measured delay.
Oscilloscope
When Audio Analyzer performs a certain function, it simultaneously sends a discrete pulse to the Packetizer. When the Packetizer receives this pulse, it creates and transmits a timestamped packet indicating which pulse it received. This packet is filtered out by the Packet Analyzer. Up to 16 filters can be operated simultaneously per port.
This allows us to get analog and digital events into the same log for delay measurement. The analog signals can be verified by connecting the TTL I/O Ports to Oscilloscope using SMA cables.
Following signals can be monitored at Audio Analyzer TTL Output ports -
- When a PTT signal sent through 4-Wire interface of Audio Analyzer, exactly as though a real user is holding PTT on his/her headset, a TTL Pulse is sent out TTL Port 1 to Packetizer for packetization
- When PTT signal on 4-Wire interface stops TTL Pulse sent out TTL Port 2 to Packetizer for packetization
- TTL Pulse is sent out TTL Port 3 at start of transmission of Pre-recorded voice file
- TTL Pulse is generated out TTL Port 4 when audio is detected (i. e. not when the command is executed, like the other triggers)
Following signals can be monitored at Packet Analyzer TTL Output ports -
Packet Analyzer can define 2 filters per port, each of which is mapped to the TTL I/Os as shown in the table below:
| Ports | Filters | I/O |
|---|---|---|
| Port2 | Filter1 | I/O 1 |
| Filter2 | I/O 2 | |
| Port3 | Filter1 | I/O 3 |
| Filter2 | I/O 4 |
- When Port 2 filters (Filter1 and Filter2) each have one matched packet, corresponding mapped TTL Port1 and Port2 generate a single TTL pulse, which can be viewed on a connected oscilloscope
- When Port 3 filters (Filter1 and Filter2) each have one matched packet, corresponding mapped TTL Port3 and Por4 generate a single TTL pulse, which can be viewed on a connected oscilloscope
- The number of trigger pulses generated on TTL Ports exactly matches the filter match count
Other Test Tools Useful for Air Traffic Management
MAPS™ ED-137 Radio and Telephone Emulators - GL's MAPS™ ED-137 Radio and MAPS™ ED-137 Telephone Emulators can simulate Radio and Telephone calls as per EUROCAE's ED137-1B and ED137-2B specifications. Using Bulk Call capability of these tools user can generate hundreds of calls as background traffic while making delay measurements. Good sample applications can be to simulate real time scenarios like PBH and PBM by generating required bulk calls in the background.
IPNetSim™ - The IPNetSim™ an IP Network Emulator connected to the 2 end points of a WAN link, allowing it to be configured to act either as a transparent bidirectional Ethernet link or a simple Ethernet bridge between 2 end points. It emulates a 10 Gbps or a 10/100/1000 Mbps full duplex link. The incoming traffic can be identified into separate user defined stream for each direction, which can then be modified to simulate network malfunctions. Each direction supports up to 16 streams, allowing up to a total of 32 streams in both directions.
Back to Latest News Page