Newsletter: GL Announces
Timing Measurement Tools for Air Traffic Management System
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. The familiar industry standard SIP protocol is specified to establish, modify, and terminate voice sessions with endpoint equipment within an Air Traffic Services Ground Voice Network (AGVN).
As shown above, the endpoint equipment can be a SIP based Controller Working Position (CWPs), Next Generation Voice Communication Systems (VCS) and Radios, or VCS/Radio Gateways allowing interworking with older legacy equipment and protocols. The legacy TDM VCS system will initially connect to an IP WAN network backbone using VoIP gateways.
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.
GL has developed a suite of tools to accurately simulate and measure all delay requirements. GL's MAPS™ Controller can be used to control the various GL tools to perform all the tests repeatedly 1000s of times and record the results for post analysis.
Events of Interest within Network as they propagate within Network:
- PTT Activation and Deactivation
- Squelch Enable and Disable
- Voice to/from CWP
- Voice to/from Radio
- Transition in RTP Payload
- Transition in RTP Headers
Network Delay measurements of 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. The below TABLE extracted (from the FAA-E-NVS1_NVS-Specification_v1_1_2012-01-10 document: refer Table 3-9) depicts Setup/Teardown Throughput Timing Requirements during Peak Busy Hour (PBH) and Peak Busy Minute (PBM).
|Type of Event||Max. Response Time, msec1,2 Percent of
A/G Functions within the AVN
|System-Generated A/G PTT Transmit (radio cross coupling)||40||45|
|Frequency cross couple Selection||125||175|
|Frequency cross couple Deselection||125||175|
|Frequency Preemption Activation||25||30|
|PTT Lockout (Preemption) Busy Tone||60||85|
|Frequency Site Selection||125||175|
|Frequency Site Confirmation||125||175|
|Local Receive Mute||50||75|
|Local Receive Mute Indicator||75||100|
|Local Receive Unmute||50||75|
|Local Receive Unmute Indicator||75||100|
To perform several of these timing measurements, one can setup a testbed with appropriate AVN elements and various GL tools at appropriate strategic interfaces. GL's script based and API driven products can be reused for various purposes during performing various test cycles.
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)
Sample Test Scenario:
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 example. This delay measurement is possible using GL's Audio Analyzer and GL's Packet Analyzer. Both are capable of generating TTL triggers based on PTT activation. The Packet Analyzer is capable of generating Packet and TTL triggers based on real time packet detection, filtering, and capture as necessary.
Below a remotely located MAPS™ Controller can instruct GL's Audio Analyzer connected to a CWP to activate PTT and simultaneously generate a TTL trigger. The Discrete Signal Logger connected to the Audio Analyzer can detect the TTL trigger and post an 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 post an 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.
GL Tools used for Timing Measurement
Audio Analyzer - The Audio Analyzer is a 4-wire audio device that can connect to a CWP and emulate a controller. It can also be utilized in other areas of the network where analog audio signals are present. It has the ability to generate TTL for different actions (PTT ON, PTT OFF, Send Audio, Detect Audio)
- Emulate controller by activating PTT and transmitting audio
- Send, detect and record audio signals at the CWP, Radio and VoIP gateway interfaces
- Ability to test for Voice Quality (as per ITU-PESQ, POLQA), Noise, and Latency over the Analog / TDM and VoIP networks
Discrete Signal Logger - The Discrete Signal Logger monitors the TTL output from the Audio Analyzer and generates a corresponding IP packet. This indicates a certain event has occurred. The packets generated by the Discrete Signal Logger are named as discreet events.
Packet Analyzer - It functions like an Ethernet tap. It acts as a transparent Ethernet link in which bidirectional Ethernet traffic flows through at line rate. However, Packet Analyzer filters 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 are forwarded over the Event Data Logger. User can configure the Packet Analyzer to aggregate filtered packets from both directions and forward over a single output port. The packets generated by the Packet Analyzer are named as Timed Events.
Event Data Logger - The Event Data Logger is located at a central location and receives the event packets forwarded from the various Discrete Signal Loggers 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 Discrete Signal Logger) 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. The MAPS™ Controllerwill calculate the time difference between different events posted and reports precise measured delay at different points in the network.
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 new IPNetSim™ an IP Network Emulator emulates an IP network with access to 10 Gbps full duplex link 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.
The IPNetSim™ is 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. The different WAN link speeds are emulated between Port 1 (P1) and Port 2 (P2), with RS232/DSL/Modem/T1/E1/T3/E3 and more speeds. IPNetSim™ supports various impairments like:
- Bandwidth emulation from 100 Kbps up to 10 Gbps in increments of 1 Kbps emulating various WAN technologies like Modem, DSL, T1/E1/T3/E3/OC3/OC12 etc
- Latency/Delay emulation from 0 milliseconds to 8 seconds, with single, uniform and random distributed delay emulation capabilities
- Packet Loss emulation, from 0 to 100%
- Packet Reordering emulation, from 0 to 100% with random reinsertion delay
- Packet Duplication emulation, as a percentage of total packets, from 0 to 100%
- Logic Error Insertion - inserts error anywhere within the frame, from 10-1 to 10-9 rate