scs_voice_communication_atc

8/7/2019 SCS_Voice_Communication_ATC

1/10

A Simple Voice Communication System For Human-In-The LoopAir Traffic Control Simulations

Florian Hafner, Mohamed Mahmoud

Center for Applied Air Traffic Management Research

Embry-Riddle Aeronautical University

Daytona Beach, Florida

KEYWORDSHuman-in-the-loop, ATC Real-Time Simulation,

VoIP, Voice Communication System, UDP multicast

ABSTRACTThis paper presents the work preformed by the

Embry-Riddle Aeronautical University Center for

Applied Air Traffic Management Research (CAAR) indeveloping a Voice Communication System (VCS) tosupport a human-in-the-loop real-time simulationfacility. The VCS was developed for use in an air-traffic control (ATC) simulation mimicking the actualVHF communication system used by air-trafficcontrollers, but using software-based VoIPtechnology within a UDP broadcast based peer-to-peer architecture. Not only does the VCS systemfacilitate voice communication between aircraftpseudo-pilots, it also allows for direct controller-controller voice communication. The VCS wasoriginally implemented and tested on a LAN based

ATC simulation platform but has been demonstratedas a viable way to connect widely distributed sitesincluding real-time links to live aircraft overSATCOM, all with no appreciable delays [2]. Someadditional features have been implemented tocomply with the FAA Next Generation Air-GroundCommunication VDL3 standard to reduceController/Pilot workload including Step-onprevention and controller pre-emption in addition toautomated change of frequency from one controllerauthority to the next.

Tests on the delay of voice communicationusing the VCS over a 100 Mb/s LAN have shown a

latency of less than 550ms. When used withadditional features such as step-on prevention, thisdelay is entirely acceptable for this type ofapplication [4].

INTRODUCTION

The Embry-Riddle Center for Applied Air TrafficManagement Research (CAAR) has an in-housedesigned and built object-oriented Real-TimeDistributed ATM Simulator (RTDS). This simulator isused to test new concepts or simulate specificscenarios in ATM. The design concept behind theRTDS is to use a User Datagram Protocol (UDP)Multicast messaging system which mirrors the realworld object behavior in terms of widely distributedsites communicating with aircraft. This broadcastapproach allows the addition of new componentswithout adding to the communication load orbandwidth; thus, new controller or pseudo-pilotpositions can be added as needed, making thesystem highly scalable and flexible.

Having a simulator of this size requires anefficient voice communication capability betweencontrollers and pseudo-pilots. Originally, a system

similar to a Public Switched Telephone Network(PSTN) had been developed and installed thatprovided basic analog voice communication.However, it was not expandable, nor was itsimulating radio transmissions in a realistic fashion.

Therefore, after investigating different voicecommunication concepts, an implementation utilizingdigital VoIP technology was developed tocompliment the RTDS. The VCS had to be light-weight, easy to implement and potentially had to runon multiple platforms at widely distributed locations.These requirements suggested the use of Java,since it is a multi-platform capable language and has

high native support for multi-media applications.Even though Java is widely considered to be slowerthan equivalent C/C++ applications, test results fromthis research have shown that the levels of delay inprocessed voice data are acceptable and that thevoice quality is comparably high.


2/10

VCS BACKGROUND

Traditionally, most VoIP applications werebased on the client-server architecture layoutdepicted in Figure 1 where the system is composedof server and client applications. Clients rely onservers to route sound packets between clients.

Despite a number of benefits such as a high level ofcontrol over individual communication channels, thismodel has the disadvantage of a single point offailure: if the server fails, the whole system ceases tobe operational. It also means that if additional clientsare added to the system, the server incurs additionalworkload by having to route additional soundpackets.

Figure 1: Client-Server layout

Another network communication model ofinterest for VoIP communication uses a peer-to-peer architecture model. This type of architecture

provides several advantages over client-server,which strongly suggested the use for a distributedVoIP communications system:

Expandable over any multicast enabled network Content and resources can be shared from the

center and the edge of the network A network of peers is easily and almost

limitlessly scaled and more reliable than a singleserver

Reduced network traffic as VCS uses UDPmulticast for communication

Fault tolerance, in case of failure of one or more

peers the system will still be operational

An architectural overview of networkcommunication in a peer-to-peer infrastructure ispresented below in Figure 2: To implement thispeer-to-peer VoIP infrastructure, the UDP protocolusing multicasting was utilized.

Figure 2: Peer-to-peer layout

UDP is preferred in this application as it is stateless,doesnt require the retransmission of droppedpackets and has smaller headers, which increasesthe amount of audio data in each network packet.

VOIP VERSUS VHFCurrently air traffic controllers are using

communication equipment that has not significantlyadvanced in the last 50 years, and which still has thesame restrictions on communications capabilities.As aircraft cockpits are becoming revolutionized withthe latest technology, communications between pilotand controllers remain the same. While flying in lineof sight of land, pilots communicate with controllersusing Very High Frequency (VHF) radios. Thenumber of VHF frequencies available is barelysufficient for the number of sectors. This has ledEurope to reduce the separation betweenfrequencies in use, at considerable expense to airtraffic service providers and aircraft operators.

Transoceanic flights rely upon High Frequency(HF) radio communications. In-flight pilots contactOceanic Air Traffic Control Centers(OATCC) via HFradio frequencies. These pilots are not alwayscommunicating directly with the controllers.Frequently, the requests and transmissions arerelayed through Aeronautical Radio, Inc. orinternational flight service station, finally arriving tothe OATCC. Utilizing a relay station causes delays intransmissions.

While controllers are relying upon out-datedequipment to provide guidance to aircraft in theskies, businesses and individuals are increasingly

having telephone conversations and conferencesutilizing voice over Internet Protocol (VoIP). Asolution to the limited number of radio frequencies,crowded frequencies, utilizing relay stations andmany other limitations, would be to transition airtraffic communications to VoIP technology. Thistechnology would enable pilots and controllers tocommunicate via voice over data-link that could be


3/10

carried on VHF Data-Link (VDL) or over satellitelinks. VoIP could be a solution to the lack of VHFradio frequencies while decreasing controllerworkload.

Also, air traffic controllers in some sectorsexperience high workloads due to the increase in airtraffic movements. That high workload can beattributed to the handover/takeover process and theassociated radio frequency changes and check-in. Atransition from analog VHF to digital VoIPcommunication would provide the ability to integratevoice communication with other control functions,potentially allowing the automatic switching offrequencies or VoIP channels when aircraft arehanded from one control facility to the next.

VCS ARCHITECTURE

The architecture model chosen for VCSmatches the RTDS in that it uses multicast peer-topeer communication using the UDP protocol, whichallows two or more clients to exchange data witheach other without a central server. Unlike a client-server architecture where data is routed throughservers and replicated for each interested client, amulti-cast peer-to-peer network is uniquelydecentralized and allows computers to communicatedirectly with each other and share data withoutreplication. Figure 2 previously and Figure 3 belowdepict the information flow based on this architecturespecifically adapted to pilot-pilot and controller-pilotcommunication in a human-in-the-loop Air TrafficControl focused simulation.

Figure 3: VCS Context Diagram

The controller-pilot communication structure in

the above diagram may be replicated to include asmany controller and pilot applications as required forthe scenario. The controller and pilot applicationsare separate processes that are selectively executedbased on the scenario requirements. Eachapplication in itself has different components andthreads.

Components Behavior

The core VCS application process is composedof a number of components which are present inboth controller and pilot executables. Figure 4belowshows a conceptual component view of the VCSarchitecture with its internal structured components

and their interactions with the execution platformincluding the sounds card and the network devices:

Figure 4: VCS Conceptual View Diagram

The following is description of each component:

VCSApplication:Starts VCS GUI and initializes/establishescommunication with the system devices

RecordSend:Interfaces with the Digital Sound Processing(DSP) device, capturing the audio data andsending it over the Network device.

PlaySound:Receives sound data over the Multicast voicechannel from the network device. Upon receivingthe sound data, it is sent it to the DSP device forplayback

WaitForControlMessageReceives control data messages over theMulticast data channel through the networkdevice, including commands to change channelsor to mute to allow controllers to override pilots

SendControlMessage:Sends control data to the Multicast data channel

From the core VCS architecture describedabove, controller and pilot specific derivatives aregenerated, which mainly differ in the Graphical UserInterfaces (GUIs) and in the control messages theyprocess.


4/10

Controller VCS

The Controller Application provides voicecommunication between the controller and thepseudo-pilots in the sector being controlled by the airtraffic controller. Each sector has a unique multicastIP address and a port number that replicates the

controller radio frequency and allows all controllersand pilots in the sector to communicate with eachother as they would with conventional VHF radioutilizing a push to talk switch.

In Addition to the Multicast voice channel theVCS uses to send audio packets between controllersand pilots, a second multicast data channel isestablished to provide for the dissemination ofcontrol messages for the GUI application. Thiscontrol channel also provides for the means ofsending text messages between the controller andpseudo-pilot controlling aircraft in his sector, which iscommonly referred to as Controller Pilot Data LinkCommunication or CPDLC. Figure 5 belowprovides a diagrammatic overview of the multicastchannel setup and communication.

Figure 5: Multicast UPD Layout

The use of CPDLC is a novel idea currentlybeing evaluated for use in real-world ATCapplications with the intention of reducing VHFfrequency usage and reducing the number ofmisunderstandings of instructions betweencontrollers and pilots.

Additionally, the VCS controller applicationprovides for communication between two controllerentities. The need for this arises fairly infrequently,but does need to be provided for in case a multiplecontroller simulation scenario requires controller-controller negotiation. Each controller listens to yetanother unique multicast IP address and portnumber for communicating person-to-person withany other controller in the simulation. Thiscommunication channel can be established throughthe graphical user interface (GUI) running on a touchsensitive screen, similar to the Voice Switch ControlSystem of the Display System Replacement (DSR)application used in En-Route Air Traffic Control

Centers throughout the United States. This GUIallows the controller to initiate or accept a point-to-point telephone communication with othercontrollers. Figure 6shows the touch screen GUIapplication for controller RIDDLEWEST (see title barof GUI) with one other sector or controller RIDDLEEAST logged on to the VCS.

Figure 6: Controller GUI

By simply pressing the GUI button of theintended recipient sector controller, the currentcontroller in sector RIDDLEWEST can request a

point-to-point conversation with another controller.This causes the button to flash in blue and yellowrepeatedly until the communication is accepted bythe recipient controller (see Figure 7).

Figure 7: Controller communication with othersector

The controller with whom a point-to-pointconversation is being initiated will see the buttonwith the calling controller sectors name flash in redand blue repeatedly, until the incoming call isaccepted by pressing the flashing button on the GUI.After the call is accepted, the button of the callingcontroller will remain solid blue.

Once this controller-controller communicationchannel has been established, no aircraft beingcontrolled by either controller hear this audio

communication. The controller-controller voicecommunication is essentially done using an openmike (the application continuously transmits andreceives audio data between the controllers withoutthe need to depress the push-to-talk switch). Whilethe phone feature is in use, the controllers can stilltalk to aircraft on their channels by depressing thepush-to-talk switch.


5/10

Pilot VCS

The pilot VCS application provides a GUI thatlists all sectors available for the pilot to select from.The pilot essentially selects the sector for which theywould like to provide pseudo-pilot services. It ispossible for multiple pseudo-pilots to subscribe to

the same sector. This usually occurs when thenumber of aircraft in the particular sector causespseudo-pilot workload large enough to warrantmultiple pilots. Figure 8shows the pilot GUI with twosectors, RIDDLEAST and RIDDLEWEST availableto the pilot to initiate communication with. Once thepilot selects a specific sector for communication, thepilot will hear the controller as well as the other pilotsin that sector, analogous to selecting a sector VHFfrequency. The selected sector will be highlighted inred.

Figure 8: Pilot GUI

The application has two modes of operation,one that allows a pseudo-pilot to be logged on tovoice communication for multiple aircraftsimultaneously without providing for hand-offcapabilities on the pseudo-pilot side, and the otherby using a designated flight number, which

essentially makes a single pseudo-pilot responsiblefor a single flight through all control sectors. Figure 9below shows the pseudo-pilot GUI when logged infor a single aircraft only; in this case the aircraftcallsign is CBB1 (see title bar).

Figure 9: Pilot in Communication

If a pilot is logged-on as an aircraft with aspecific flight number as shown above with aircraftCBB1, when the flight is handed over to a newsector the pilot VCS application will automaticallyretune to the new sector frequency when the hand-

off procedure between sectors is completed. Thepilot may override the frequency change by selectinga different sector from the GUI.

VCS implementation

The EARL VCS was implemented using the

Java core sound API [6] to maintain simplicity, rapiddevelopment, and platform independence. The useof UDP multicasting as a network protocol topropagate messages around an entire LAN allowsfor a very flexible and scalable system. Thissatisfied an early requirement that the VCS beextendable to provide for pseudo-pilot capabilities formany different types of ATC simulation scenarioswith varied numbers of aircraft in the system.

VCS ADVANCED FEATURES

In addition to providing basic voice

communication between controllers and pilots, someadditional features have been implemented whichwere aimed at reducing controller workload and theeffects of transmission latency caused by thesoftware, the use of a codec, and networkcommunication. These additional features includecontroller pre-emption, step-on prevention, and aclose integration of the VCS with the actual RTDSATC simulator.

Integration with ATM System

One of the most important features of the VCSsystem is its capability to interface with the RTDS

Human-in-the-Loop simulation platform. The VCSRTDS interface application listens to the messagesfrom both the VCS process and the RTDS. Figure10 shows the flow of data to and from the RTDSVCS interface application that allow the integrationof VCS with any real-time simulation platform.

Figure 10: RTDS VCS Interface diagram


6/10

For example, when a controller assumescontrol of an aircraft within the RTDS simulation byclicking on the position symbol or entering thecomputer ID (CID), the display issues as part of themessage an assume control message to provideaircraft ID, the handing-over sector and receivingsector. The VCS RTDS Interface process thensends a message to the aircraft VCS application toswitch to the multicast IP of the assuming sector. Noextra action is required and the transfer ofcommunications is automatic. Pseudo pilots mayoverride automated transfer by selecting a particularsector on the VCS touch-panel GUI.

It should also be of interest to note that eventhough the focus in this paper has been on UDPmulticast messaging for the VCS, a simple interfacecan be developed to provide for means tocommunicate with other simulators using TCP/IPmessaging.

Controller pre-emption

A common real-world problem with the currentVHF communication system is that an aircraft canunintentionally monopolize a VHF frequency. Thismay be caused due to equipment failures such as astuck transmit switch. This may cause continuoustransmission from a single pilot, thereby limiting theability of other voice communication on thisfrequency.

The VCS controller application providescontroller pre-emption which allows the controller tobreak into any transmission by a pseudo-pilot atanytime, basically giving the sector controller the

capability to interrupt any pilot who is currentlytransmitting on the multicast channel. This isachieved by sending a mute message to all pseudo-pilots in that specific sector, thereby preventing themfrom sending their sound packets while the controlleris sending a voice transmission.

Step-on Prevention

A major problems with current conventionalradios is two aircraft are allows to transmit at thesame time, which is known as step-on. Duringsimultaneous transmission of two aircraft, all that isreceived by the controller is a squeal, causing the

controller to have to request a repeat of pilotrequests or transmissions. This increases pilot andcontroller workload to an unnecessary degree.

To prevent step-on occurrences within theVCS, whenever the controller application receives avoice transmission from a pilot application, itimmediately issues a mute command to all otheraircraft applications within the controller sector,

thereby preventing them from sending voicemessage until the transmitting pseudo-pilot hasended their voice transmission. The controllerapplication essentially acts as a server controller forthis scenario and gives precedence to the pseudo-pilot voice transmission received first. Thisfunctionality prevents more than one pilot fromtransmitting at any give time.

COMPRESSION

The initial VCS release did not use an audiocodec as bandwidth was not deemed a constraint.However, as later results would show, the size ofvoice packets being transmitted would neverthelessplay a role in the latency of the communication.

The initial requirement for VCS was to providevoice communication support for the RTDS simulatorplatform used by ERAU-CAAR on a 100 Mbits/secLAN. Even though the VCS voice quality and totalperformance was deemed very acceptable, thebandwidth required by the application was higherthen desired. Initial testing of the VCS without acodec showed that during a one minute voicecommunication between a controller and a pilot, thetransmission rate was 13.2 Kbytes/sec. Afterimplementing the GSM6.10 codec [5] thetransmission rate was reduce to 3.8 Kbytes/sec,which lead to a 71 % reduction in bandwidth used bythe VCS application. As test results will show laterin this paper, this reduction in bandwidth alsogenerated a reduction in the latency observed in thecommunication.

HARDWARE INTERFACE

The VCS uses standard PCs equipped withindustry standard Sound Blaster Live Sound cardsand stereo headset with a microphone connected tothe sound cards.

A press-to-transmit foot/handheld switchconnected to either serial/parallel the port to initiatesound recording and transmission.

Touch panel displays were used to run thecontroller and pilot VCS applications. This setupwas intended to mimic the Display System

Replacement (DSR) voice communication system.Setup currently in place in many En-Route Air TrafficControl Centers in the US.


7/10

TESTING METHODOLOGY

Perhaps the most important factor in acontroller and pilot voice or any VoIP communicationis the quality of the service ---- known as QoS. ITU-T Recommendation E.800 defines QoS as Thecollective effect of service performance, which

determines the degree of satisfaction of a user of theservice. A number of different factors affect theQoS, including packet loss, delay, availablebandwidth, network protocol used and jitter.

The VCS application was tested using twodifferent approaches. A subjective test evaluated thequality of the VCS from a user prospective and anobjective test which measured the performance ofthe application in terms of software metrics, such asdelay and packet loss.

Subjective rating

The subjective testing of the VCS system was

based on the measurement techniques that aredefined in ITU-T P.800. These techniques arelargely based on the feedback and opinion ofpseudo-pilot and controller test subjects whoobserved the voice communication and rated thequality of the transmission on a 1 to 5 scale with 5being excellent and 1 unsatisfactory. In doing so,they were briefed about what factors they shouldconsider. These factors included audio loss, circuitnoise, sidetones, talker echo, distortion, delay, andother transmission problems.

Objective rating

The most important factor when objectivelytesting the VCS is the measurement of the latency ordelay since this increases the difficulty to have anormal conversation (and therefore workload). TheITU-T standard recommends a maximum of 0.15seconds unidirectional delay. Specific sources ofdelay can be identified by examining the routes thataudio packets travel from source to destination.Looking at a generic LAN network architecture, thedelay budget contains the following [3]:

Signal encoding/decoding algorithm, typically15-37.5 milliseconds at both the origin anddestination.

Protocol processing overheads in components toinclude UDP, and IP information plus echocancellation, typically less than 5 milliseconds.

Bandwidth and utilization (loading) of the LANand WAN channels, which may introduceframing and queuing delays in the range of 5-25milliseconds, depending on the transmissionrate.

Routing, queuing, and propagation delaysacross the WAN which depend on transmissionmedia and distance, typically 10-40 milliseconds.

Jitter, or variation in the arrival rates of thepackets comprising the audio or video stream.Since the packetized voice samples may take

different paths through the packet-switchednetwork, arrival rates of those packets.

Testing Setup

The VCS1

was deployed and tested withinEmbry-Riddles ATM Research laboratory and theGlobal Communication, Navigation, and SurveillanceSystems (GCNSS) project sponsored by the FAAand Boeing. The project was intended todemonstrate the feasibility of a global satellite-basedCNS, using a highly integrated Common InformationNetwork (CIN) architecture. The demonstration ofthese new concepts involved a single aircraft flying

in and out of radar and VHF coverage over the Gulfof Mexico, while maintaining full communication andcontrol using Satellite communications for bothposition reports and voice communication.

To support the demonstrations, the CAAR RTDSreal time simulation including the VCS was widelydistributed, from Daytona Beach, FL, with 2simulator positions each in McLean, VA; Houston,TX; Irvine CA; and in the Boeing 737-400experimental aircraft flying in the demonstrations.The network architecture was comprised of a mix ofdedicated T1 based WAN and SATCOM over Kugeostationary and L band (Iridium) links. Figure 10shows the network layout for the GCNSS project.Throughout the demonstration, the VCS provided afull party-line capability with step-on prevention andcontroller pre-emption. Controllers at Houston wereable to transfer voice communications as part of astandard silent handover between twosectors/controllers.

1GSM6.10 codec was not available during GCNSS


8/10

Figure 11: GCNSS Network Layout

The measurement for communicationlatency within the VCS, was accomplished using theprocess described in Figure 11.

0 0 .1 0 .2 0 .3 0 .4 0 .5 0 .6 0 .7 0 .8 0 .9-1

-0.8

-0.6

-0.4

-0.2

0

0.2

0.4

0.6

0.8

1

Source sound

into microphone

Source sound into

source phoneSource sound

Delayed sound

emitted from

destination phone

Emitted sound

into microphone

Microphone data

recorded and

stored digitally

TransmissionNetwork

TransmissionNetworkDigitized signal

transmitted to network

Digitized signal

transmitted to

destination phone

Source and Delayed

sounds are co-plotted,

and delay can be

measured

0 0 .1 0 .2 0 .3 0 .4 0 .5 0 .6 0 .7 0 .8 0 .9-1

-0.8

-0.6

-0.4

-0.2

0

0.2

0.4

0.6

0.8

1

Source sound

into microphone

Source sound into

source phone

Source sound into

source phoneSource sound

Delayed sound

emitted from

destination phone

Emitted sound

into microphone

Microphone data

recorded and

stored digitally

TransmissionNetwork

TransmissionNetworkDigitized signal

transmitted to network

Digitized signal

transmitted to

destination phone

Source and Delayed

sounds are co-plotted,

and delay can be

measured

Figure 12: VCS delay measurement setup

Using the above process, a short sound isplayed into both the source headset microphone andthe measurement system (an oscilloscope), which isrecording all sounds. In this case, the sound was asinusoidal tone at 1000 Hz lasting for 100milliseconds. The sound is digitized by the sourceheadset, encoded, and transmitted over the network,where it is received by the destination hardware,decoded, and played through the headsetsspeaker(s). This output version of the test sound isalso played into the measurement system, which iscontinuously recording. The test tone was repeatedfive times for each measurement, with a spacing ofapproximately 1 second, and recording was thenstopped. Using these measurements, the elapsedtimes between the origination and playback of thetones were recorded [2].

EXPERIMENTAL RESULTS

Subjective results

Voice quality tests were run using experiencedcontrollers from Houston En-Route ATC center, andpilots from Embry-Riddle Aeronautical University

(ERAU). The tests included two controllers andeight pilots. These tests essentially evaluated thecontrollers abilities to interact with and controlpseudo-piloted aircraft using the VCS and anyassociated delay and voice quality issues.

The test was repeated four times. Keeping inmind that the test subjects are humans, someexpected variation in the average final ratings wasobserved. However, the overall Mean OpinionScores rating for the VCS was 4 (Good) [3].Additional comments by the air traffic controllers alsore-iterated that the delay inherent in the VCS systemhad very little effect on their ability to control aircraft.

Objective results

Using the measurement procedure outlineearlier, voice latency tests were run for the GCNSSdemonstrations, as well as at ERAU after someenhancements to the VCS software.

The voice latency tests performed during theGCNSS project revealed an average latency of 661milliseconds. This basically means that each voicecommunication packet reached the recipientsheadphones approximately 660ms after beingtransmitted through the microphone.

Following some enhancements to the VCS

aimed at improving performance, the same type ofprocess used to evaluate the VCS previously wasemployed. Test results revealed a mean latency of536ms with a standard deviation of 11ms using theGSM codec. Interestingly, using a PCM codecgenerated a mean latency of 550ms and equalstandard deviation.

BENEFITS OF VOIP INTEGRATION WITH REAL-TIME SIMULATOR

Any human-in-the-loop simulation is likely torequire some form of voice communication betweensubjects and/or supporting staff. Even though it is

sometimes convenient to purchase an off-the-shelfsystem, the benefits of Voice over IP have shownclear merit in its ability to use the existing networkinfrastructure and provide high quality sound. SinceVoIP data as well as real-time human-in-the-loopdata and control messages are both transmitted overthe same network, it becomes convenient to linkboth systems together (this is in fact what select


9/10

voice recognition software accomplishes on somehigh-end simulators).

The integration of the real-time simulation andVCS systems creates a setup that reducesworkload, and provides dynamic scalability toadd/subtract users on the system. It also allows

subjects in the human-in-the-loop simulation tomanipulate frequencies and channels through thereal-time simulation interface without having tomanually perform these tasks on the VoIP system.Also, if the need arises to widely distribute the real-time simulation across multiple locations, the VCSrequires no modifications to accommodate this.

CONCLUSION

This study has shown that a relatively simple,scalable, and flexible Voice Communication Systemcan be developed fairly rapidly using Java and in

particular its multimedia components.The VCS provided a high fidelity voicecommunication system to support human-in-the-loopsimulation scenarios by utilizing VoIP technology,mimicking the actual VHF used in controller/pilotcommunication for use in air-traffic control (ATC)simulation. The VCS was fully compliant with theVDL3 [4] requirements by providing voice and datalink with added features such as controller pre-emption, step-on prevention and transmit statusindicator.

Subjective metrics used to assess the Quality ofService of the voice communication system haveshown a ranking of 4, indicating overall good

performance. An analysis of voice latency over astandard LAN resulted in a delay of 536ms. Whilethis may seem significant, Sollenberger et. al. havedemonstrated that latency greater than 350ms andeven up to 750ms is acceptable in ATC simulationsproviding that controller pre-emption and step-onprevention mechanisms are used [4]. Consequently,the VCS has shown reasonable performance for usein these types of human-in-the-loop simulations.

The system was designed using a pure objectoriented OO methodology with a peer-to-peerarchitecture and UDP multicast communications,which add flexibility and scalability to the system.

The simplicity of the VCS system allows it to beused in a wide variety of simulation scenarios; forexample the VCS can be changed to simulate airlinedispatcher communication with their own aircraft orair-traffic ground control movement.

FUTURE WORK

Current efforts are focused on extending theVCS to use the IEEE 1278.1 DIS standard [9] formessage formats, which will provide the ability tointerface with other voice communications systems.The VCS is also being modified to allow for CPDLC

text messaging between controllers and pilots. Workis also continually on-going to improve theperformance of the VCS and reduce voice latency.

REFERENCES

[1] Federal Aviation Administration (2000). Air trafficcontrol[7110.65M]. Washington, DC: Author.Hopkin,V.D. (1995).Human factors in air trafficcontrol. Bristol, PA: Taylor & Francis.

[2] Boeing Air Traffic Management, 2004, GCNSSDemonstration Segment B Report, Documentnumber: D794-10141-1, pg. 3.

[3] ITU-T Recommendation G.114, May, 2003.[4] Sollenberger, R., McAnulty, D., Kerns, K. TheEffect of Voice Communications Latency in HighDensity, Communications Intensive Airspace,Technical Note DOT/FAA/CT/TN03/04, January2003

[5] GSM06.10 speech compression,At: http://kbs.cs.tu-berlin.de/~jutta/toast.html

[6] Java Sound API,At: http://java.sun.com/j2se/1.4.1/docs/api

[7] Java Sound Resources,At: http://www.jsresources.org/faq_audio.html

[8] A comparison of internet audio compression,At: http://www.sericyb.com.au/audio.html

[9] IEEE. Standard for Distributed InteractiveSimulation. IEEE Std 1278.1-1995

BIOGRAPHY

Mohamed Mahmoud received his Bachelor ofScience in Aerospace Engineering and Masters inSoftware Engineering from Embry-RiddleAeronautical University in Daytona Beach, Florida in1997 and 2002, respectively. While completing hisgraduate degree, Mr. Mahmoud worked for CarrierElectronics, Farmington, CT for one year developingfront end user interface software for controlling ACunits. Upon returning back to ERAU, Mr. Mohamedworked as a graduate student assistant teaching theIntroduction to Software Engineering course. Later,Mr. Mohamed joined the Air Traffic ManagementResearch lab, as a research assistant, participatingin various research projects in the field of ATMsimulation. Following his graduation, Mr. Mahmoud


10/10

was promoted to Software Research Engineer andtasked to investigate VoIP technology and thepossibility of using it in the field of Air Trafficsimulation. Mr. Mohamed developed the concept ofusing VoIP technology to mimic VHFcommunications, which was used in the design andimplementation of the VCS system.

Florian Hafner received his Masters of SoftwareEngineering degree from Embry-Riddle AeronauticalUniversity in 2002. While completing his graduatework at ERAU, Mr. Hafner worked for the Air TrafficManagement Research Lab, where he spent themajority of his time on TAAM simulation projects andsoftware development for a real-time ATC Human-in-the-Loop simulator. Following his graduation, Mr.Hafner joined Preston Aviation Solutions in 2002 asthe Customer Support Manager responsible forproviding deployment and technical support forNorth American users of TAAM, PaxSim, and AADS.In 2003, Mr. Hafner left Preston Aviation Solutions to

rejoin Embry-Riddle as a Senior Air TrafficManagement Research Associate and AdjunctProfessor. In his present position, he is responsiblefor overseeing a variety of ATM Research projectsdealing primarily with fast-time and real-timesimulation, modeling, and analysis, Air Traffic datamining and analysis, and the development andevaluation of novel ATM concepts and systems. Asan Adjunct Professor, Mr. Hafner also instructsgraduate students in the use of TAAM in support ofairport design and master planning. Mr. Hafner iscurrently pursuing a PhD degree in IndustrialEngineering at the University of Central Florida,

focusing on Simulation, Modeling and Analysis.

scs_voice_communication_atc

Documents