A service environment for air traffic control based on SIP

Proceedings of the 37th Hawaii International Conference on System Sciences - 2004

A service environment for air traffic control based on SIP Klaus Darilion, Christoph Kurth Vienna University of Technology Gusshausstrasse 27-29/384 A-1040 Vienna, Austria {darilion|kurth}@ict.tuwien.ac.at Abstract The long-term growth of air traffic requires integrated audio and data services to improve the support of air traffic controllers in maintaining safety despite increased capacity. The use of an IP (Internet Protocol) based network for voice and data communication will ease this integration but on the other hand causes new challenges when facing the characteristics of packet based networks. The presented software architecture combines audio services with basic data services and offers interfaces to integrate them with other air traffic control systems. Air traffic control uses radio based air/ground communication. We use the session initiation protocol (SIP) for setting up audio sessions and the SIP specific event notification to control radios. We implemented a prototype to measure notification delays. Compared with air traffic control requirements the concept is proven in general, but implementation details have to be improved to reach the performance requirements for large systems.

1. Motivation Todays installed and available voice communication systems for air traffic control (ATC) rely on circuit switched technologies [8]. They are highly reliable and well proven, nevertheless they have limitations. The systems are built upon proprietary software and hardware. Thus, the hardware is very expensive and it’s difficult to interconnect systems from different vendors. The systems lack of data integration, which is necessary for interworking with data services like weather information systems or mission planning systems. The current systems support interconnection of several ATC centers to enable voice communication between the air traffic controllers using ATS-Q.SIG or MFC networks, but the

Wolfgang Kampichler, Karl M. Goeschka Frequentis Nachrichtentechnik GmbH Spittelbreitengasse 34 A-1120 Vienna, Austria [email protected], [email protected]

current systems were not designed for sharing radio resources among several ATC centers. An Internet protocol (IP) based voice communication system can overcome these limitations. Commercial off the shelf (COTS) products instead of proprietary hardware and software have potential to lower the costs. The use of IP will ease the data integration into ATC and enables transparent wide area interconnecting of several ATC centers and sharing of voice and data services between them. To benefit from IP as common network protocol, the offered services will be combined at the controller working position. These higher level services support the air traffic controller maintaining safety despite increased capacity. We do not claim that a newly developed voice communication system based on IP will outperform current circuit switched implementations. Nevertheless, IP based voice communication will become equivalent to circuit switched communication and supersede it, eventually. Therefore, we introduce voice over IP (VoIP) technology into mission critical applications and evaluate it with respect to the requirements of mission critical systems. The integration of radio communication systems require additional signaling for PTT1 and channel arbitration2 compared to the signaling for standard phone calls over IP. Nevertheless, it is useful to use an existing standardized signaling protocol and possibly extend its functionality. This will ensure compatibility between products of different vendors and enables seamless connectivity between ATC centers via WANs. A session initiation protocol (SIP) [11] based voice communication system, as already discussed in [1], generally fulfills the ATC requirements for call-setup times. This work includes an in-depth discussion on radio signaling 1 Push-To-Talk: Necessary for half-duplex devices to transmit and receive voice traffic on the same frequency. 2 The radio is a shared resource. Therefore, if several operators request the same radio, all but the first one will be locked out.

0-7695-2056-1/04 $17.00 (C) 2004 IEEE

1

Proceedings of the 37th Hawaii International Conference on System Sciences - 2004

approaches, and explains why the SIP-specific event notification [10]—a framework for subscription and event based notification—was chosen for radio signaling. SIP can be easily extended to enable new services and already offers instant messaging and presence services, which are of interest for future ATC applications. Furthermore, SIP is the signaling protocol in 3rd generation mobile networks and therefore undergoes heavy development. Watching the current VoIP market place shows that H.323 is still supported, but new products are developed for SIP and there are more interoperability activities for SIP than for H.323. These are the reasons why SIP was chosen over other signaling protocols like H.323. Nevertheless, it will be a challenge to develop an IP based solution which competes with the circuit switched systems in terms of reliability, performance and by offering complex radio services. In this work we present a distributed service architecture to support air traffic controllers with enhanced services. We introduced a radio service which is based on a hierarchical client-server model and a high level radio service model. We extended the functionality of SIP to handle signaling for radio communication without using any proprietary extensions just by combining several SIP methods in a proper way. We measured the event signaling delays of our prototype implementation and compared them to ATC requirements to proof the feasibility of our architecture. Also, the signaling delay of a SIP proxy in a forking scenario was analyzed as further comparison to our radio server implementation. Finally, we present a solution to achieve quality of service (QoS) for voice applications and a method to guarantee WAN access for high priority calls during congested situations. Hence, the presented architecture, based on open standardized protocols, allows not only the interconnection of air traffic centers via WANs, but also the integration of 3rd party products where applicable. Furthermore, it will ease the development of new voice, data or combined services. The voice communication solution presented in this article is suitable for IP based ATC centers and for their interconnection. Also connections to existing ATC networks are supported using gateways. If IP will only be used to interconnect existing circuit switched ATC centers, tunneling will be the proper solution. Such a solution already exists in the form of time division multiplexing over IP (TDMoIP) [12]. The presented work uses IP and SIP only in the ground network. The radio link for the communication between the operators and the pilots is still based on existing analogue radios, in contrast to the 3GPP push-totalk service which uses SIP over cellular networks.

Radio

Radio Service

Radio

Radio Service Radio

IP Controller Working Position

N

Weather Data

WA Conference Service

IP Controller Working Position

Mission Data Service

Controller Working Position

Gateway Service

Gateway Service PSTN/ATS-Q.SIG

Figure 1. Service environment for air traffic control

2. Architecture Figure 1 shows the main architecture of the IP based ATC service environment. Every node in the network can offer and consume services. For example, a radio service offers access to radios and a gateway offers service translation to legacy systems or the public switched telephone network (PSTN). Both services can be consumed by the controller at the controller working position via the LAN or WAN. The separation of the offered services allows to develop new services without conflicting with existing services. Usually, the services will be consumed at the controller working position. Therefore, the working position must implement a client for all the needed services as shown in figure 2. The operator position includes an additional convergence layer to combine the miscellaneous service clients to high level services, for example the weather forecast will be synthesized to speech and transmitted using the radio service. The service APIs allow integration with other systems in ATC, e.g. the radar system can use the ATC radio service to initiate radio transmissions. Currently, the radio communication between aircrafts and ground stations supports only voice, but data links are already discussed within the ATC community. These data links for example enable aircrafts to send their identity within radio messages. This identification can be utilized by the radar application to highlight the aircraft of the currently talking pilot at the radar screen, and will ease the work of the operator. In this work we focus on the voice communication services for ATC, especially radio services for air/ground communication. The voice services in this architecture are already combined services. Figure 3 emphasizes the voice service parts. For phone and radio services, SIP is used for session initiation and RTP for voice transmission. Furthermore, the SIP specific event

0-7695-2056-1/04 $17.00 (C) 2004 IEEE

2

Proceedings of the 37th Hawaii International Conference on System Sciences - 2004

Weather information services SOAP, etc

TCP/UDP

TCP/UDP

IP

IP

IP

Layer 2

Layer 2

Layer 2

Operating system

SOAP, etc

Weather server

Operating system

RTP + SIP + SIP Events

Mission data services

Configuration services

Convergence layer

ATC phone services

Combined services API

ATC radio services

Application and GUI

Operating system

ATC radio services RTP+SIP+ SIP Events

Converged services API

Weather services

Controller working position

Radio server

TCP/UDP

Figure 2. Layered service integration ATC radio services direct connection (backu p)

Radio Gateway

Radio Server

Radio Gateway

Controller Working Position

SIP

SIP presence events

SIP PTT/SQU events

Radio

Sector 1

Radio

RTP Controller Working Position

TCP/UDP

Figure 3. Enhanced voice services notification is used to signal radio events like PTT and squelch (SQU), and to signal the presence status of the operators to enhance the phone service. Additional data services will use SOAP or similar protocols to access the data resources. A voice communication system for ATC mainly consists of phone communication and radio communication. Phone calls will be set up using SIP elements like registrars and proxies and the media will be sent directly between the two participants, whereas radio communication requires a certain architecture to fit into ATC environments.

2.1. Radio architecture Basically, the airspace is divided into sectors. Every sector has a certain frequency, on which the radio transmitters and receivers operate, and one air traffic controller who manages the traffic in this sector. In many cases, ATC requires more advanced configuration where several controllers operate on the same sector and sectors are covered by several radios to achieve better cov-

Controller Working Position

Radio Server

coupling

ATC phone services

Radio Gateway

Radio Gateway

Sector 2

Radio

Radio Server Radio Gateway

Controller Working Position

Radio

Radio

Radio Gateway

Sector 3

Radio

Figure 4. Radio architecture

erage. The radio resources—senders, receivers and their antennas—are typically on remote sites. As the radios only support one voice channel, the bandwidth of the connection between the remote site and the ATC center is typically dimensioned for one voice stream per radio. This leads to a radio server in the LAN of the ATC center, which manages the access to the radios and distributes the received radio messages. Furthermore, a radio gateway is necessary which translates the SIP signaling to radio control lines and the audio packets to analogue audio. If IP is used in the last mile, the radio gateway will reside at the radio location and communicates directly with the radio. When existing connections (4-wire, ISDN) are used, the radio gateway resides in the ATC center—possibly on the same node as the radio server.

0-7695-2056-1/04 $17.00 (C) 2004 IEEE

3

Proceedings of the 37th Hawaii International Conference on System Sciences - 2004

monitors presence status of

0.. *

0.. * Operator pttState phoneState sipUri

disconnected

is coupled with

0..1

isConnectedTo 0.. *

Sector transmissionState 0.. sipUri *

unsubscribe status

subscribe status granted status

0.. *

key-out

key-out

1

isConnectedTo subscriptionState activityState

consistsOf 0.. * Radio radioState sipUri

key-in Tx+Rx granted Tx+Rx

key-in Tx+Rx granted

2.2. Radio service model The radio service model (figure 5) visualizes the radio service. Operators are connected to radio sectors and sectors consist of several radios which cover the sector. The isConnectedTo relation models the subscription state (e.g. Rx for receive only, Tx+Rx for send and receive, ...) and the activity state (e.g. the operator requests access to this radio sector) of the operator to a certain sector. The radio service model can be seen as high level call model, which resides above the call model in the SIP stack. For example, in the model, the operator is connected to the radio sector. For this connection, the SIP stack has to maintain up to 3 SIP dialogs, one for the

Rx

key-in Rx granted

Figure 5. Radio service model Figure 4 shows the architecture of the radio service. The architecture is a hierarchical client-server solution. The radio gateway acts as server and offers a basic radio gateway service to the radio server. The radio server in turn acts as server for the working position. It offers the ATC radio service, manages access to radios and distributes incoming radio messages. The signaling and voice transmission protocols on the “controller-side” are identical to the protocols on the “radio-side”—SIP and RTP—only the transmitted information differs. Thus allowing the working position to connect directly to the radio gateway. This is only useful as fallback scenario where all radio servers have failed as it allows only one operator to connect to a certain radio resource. In periods with low air traffic, sectors are grouped together to form a new sector, called coupling. As the initial sectors operate on different frequencies, the voice communication system has to forward incoming radio messages from one sector to the other sectors. Therefore, the radio servers of the corresponding sectors connect to each other to build a larger, virtual sector. Figure 4 shows a scenario where sector 2 and sector 3 are coupled. A working position may only be connected to one of the coupled radio servers to avoid loops and deadlocks.

key-in Rx granted

Figure 6. Subscription state diagram of the isConnectedTo class

audio call and two for mutual event notification (refer to section 4.2). This mapping of the radio service model to the call model which maintains the peer-to-peer relationship between the call participants (e.g. controller working position and radio server) depends on the call model in the used SIP stack. The several nodes of the radio architecture have different tasks and require different views onto the system, e.g. the operator is not interested in the radios but only in the sector class which offers the complete functionality an operator needs. So, the several nodes implement only the necessary part of the model, for example the controller working position need not to implement the radio class. As a detailed discussion of all nodes of the radio service would exceed the paper length, we focus on the controller working position for further explanations. Figures 6 shows the subscription state diagram of the isConnectedTo class. In the Status state the operator receives only status information about this channel without any voice. In the Rx state, the operator is a passive listener to the channel whereas in Tx+Rx state the operator is allowed to transmit messages, too. In the Rx and Tx+Rx state, the operator still receives status information. Every state transition corresponds with a SIP transaction which can be initiated by the controller working position or by the radio server. Table 1 shows the state transitions of figure 6 and the corresponding SIP messages.

3. Radio signaling The use of radio communication systems requires to add additional signaling to the standard VoIP signaling.

0-7695-2056-1/04 $17.00 (C) 2004 IEEE

4

Proceedings of the 37th Hawaii International Conference on System Sciences - 2004

Table 1. State transitions and their corresponding SIP requests event subscribe status granted unsubscribe status key-in Rx granted key-in Tx+Rx granted key out

SIP messages SUBSCRIBE + 200 OK SUBSCRIBE (Expires: 0) INVITE (SDP: a=recvonly) + 200 OK INVITE + 200 OK BYE

If an operator dispatches a radio message, the PTT information must be sent to the corresponding radio server. The radio server relays the PTT information to all operators subscribed to this sector and to the radio gateways belonging to the sector. At the radio gateway, the PTT signal initiates the activation of the PTT control line which will activate the radio transmitter. In the reverse direction, a radio receiver activates the SQU control line if an incoming radio message is detected. This triggers the radio gateway to send the SQU information to the radio server, which forwards the information to all subscribed operators. The PTT/SQU information may be sent in several ways. Following, we describe the advantages and drawbacks of the several methods and explain why SIP was chosen. • The SIP specific event notification suits perfectly to signal radio events. A SIP node interested in radio events subscribes to the events at the corresponding notifier. Every time an event occurs, the notifier generates a SIP transaction for every subscriber and sends the NOTIFY messages to them. The notifications will be acknowledged by the subscribers, thus the notification delivery is reliable. The SIP based notification is independent from an established RTP connection. • RTP [4] can be used in several ways to transmit PTT and SQU information. If silence suppression is used, the plain presence of an RTP packet signals PTT/SQU. Furthermore, the RTP extension header can be used to transmit additional information. The PTT information is always synchronous to the voice stream, but this method requires an RTP connection even if the subscriber is only interested in events. An acknowledge is not necessary, as the PTT/SQU information will be present in every RTP packet. Multicast, which can usually be used for audio transmission, can not be applied, because the radio server must maintain a dedicated RTP session for every client.

• RTCP is a supplement to RTCP and may be extended to send self defined packets signaling PTT/SQU. This method is event based and does not require sending RTP packets but RTCP packets are not acknowledged. • A proprietary solution will likely be the fastest as it may be fitted exactly onto the needs of radio signaling, but it may cause interoperability problems between different vendors and would require more research work in developing a protocol that supports subscriptions, notifications and acknowledgments. Table 2 compares the several possible radio signaling methods. SIP was chosen, as it is interoperable, delivers the messages reliably and does not need an RTP connection if a subscriber is only interested in the events. Although SIP is used to signal radio events, the clients may act fault tolerant and treat incoming RTP packets without prior SIP-based PTT/SQU signals also as radio messages and treat such scenarios as errors in the SIP signaling.

4. SIP-based radio signaling Radio sessions consist of setting up the session in the requested subscription state and distributing the radio events.

4.1. Radio session setup The Status state (figure 6) can be reached by a successful subscription to the PTT/SQU events at the radio server which administrates the corresponding radio sector. To subscribe, the operator position uses the SUBSCRIBE method which is an extension to SIP (refer to section 4.2). To reach the Rx state, an audio session has to be set up. This call setup differs from standard SIP call setups. If an operator requests an Rx session, it signals this to the radio server by using a special type=value pair in the session description [6]: a=recvonly Hence, the radio server will grant Rx access to this operator. If the operator requests a Tx+Rx session, it sends a standard invite to the radio server. When the radio server receives an invitation for a Tx+Rx session, it tries to subscribes the PTT/SQU events from the requesting controller working position. This is necessary to receive the PTT-on and PTT-off events from the operator. If the subscription is successful, that means the requesting party is a controller position which is capable of radio

0-7695-2056-1/04 $17.00 (C) 2004 IEEE

5

Proceedings of the 37th Hawaii International Conference on System Sciences - 2004

Table 2. Comparison of different radio signaling methods signaling method SIP RTP RTCP Proprietary

acknowledge

signaling type

yes not necessary no yes

event based continuous event based event based or continuous

signaling, it grants Tx+Rx access to the operator. If the subscription fails, which means the requesting party is not capable of radio signaling, the radio server will reject the request or allow an Rx session only (depending on the local security policy). This will be indicated to the caller by sending an a=sendonly line in the session description. If the operator wants to change from Rx to Tx+Rx or vice versa, the controller working position sends a Re-INVITE. This allows changing the keyin state of the session without tearing down the existing call and setting up a new call. The described key-in procedure allows to key-in a radio channel in Rx mode even with a standard SIP phone. Additionally, all known SIP features are supported. For example, proxies in addition with a location service are used to achieve operator mobility and to increase the availability. If a radio server breaks down, another radio server replaces the broken radio server. The working radio server registers its local address with the address-of-record of the radio sector at the registrar. That way, a radio sector can be reached by its SIP address e.g. sip:[email protected] regardless of the physical address of the radio server which serves this radio channel.

4.2. Event signaling The subscription of event channels and the sending of notification messages in SIP are defined in [10]. First, the operator subscribes the events of the radio sector at the appropriate radio server. After a subscription (figure 7), all events related to this radio channel, e.g. PTTon and PTT-off, will be signaled to all the subscribers. The SUBSCRIBE messages usually take the same route as the INVITEs, thus including SIP proxies. As shown in figure 8, the notifications are sent directly to each subscriber and will be retransmitted until a final response or a timeout. On success, the subscriber responds with a 200 OK message. If a NOTIFY request fails—the response times out, or a non-200 class response code is received—the notifier will remove the subscription for this subscriber. As the subscription is unidirectional, the operator

RTP packets required no yes no no

signaling synchronous to voice no yes no no

multicast/broadcast applicable no no no yes

1. SUBSCRIBE sip:[email protected] SIP/2.0 4. SIP/2.0 200 OK Operator Position

SIP Proxy Radio Server

3. SIP/2.0 200 OK

2. SUBSCRIBE sip:[email protected] SIP/2.0

Operator Position

Figure 7. Event subscription 1a. N

OTIF

Operator Position

Y ope

rator@ pc11 .atc-c 2a. S enter. IP/2.0 org S SIP Proxy 200 O IP/2.0 K

1b. NOTIFY [email protected] SIP/2.0 2b. SIP/2.0 200 OK Operator Position

Radio Server

Figure 8. Event notification will only be informed about events corresponding to the subscribed radio sector. As the operator position also has to notify the radio server about certain events, e.g. the activation of the PTT button, the radio server has to subscribe the PTT/SQU events from the operator position, when the operator position requests the Tx+Rx mode. The events will be transmitted in the body of the NOTIFY message. The syntax of the message body is defined in an event package and is type=value based. The following example shows a notification body indicating an incoming radio message on sector f100, sent from the radio server to the subscribed operators: sector=sip:[email protected] status=SQU-on radio=sip:[email protected] signal-level=-30dB flight-id=1234567890

The notifications may also include additional information like the signal level at the receiver, the location of the receiver or the identity of the sender of the radio message.

0-7695-2056-1/04 $17.00 (C) 2004 IEEE

6

Proceedings of the 37th Hawaii International Conference on System Sciences - 2004

2. processing of INVITE request

Table 3. PTT signaling delays

1. INVITE sip:[email protected] SIP/2.0 3. SIP/2.0 100 Trying

Operator Position

SIP Proxy

processing time tOK : send 200 OK tf orw : receive and send NOTIFY tsend : send NOTIFY

messages 5.0 ms 8.1 ms 1.6 ms

1–2 1–3a 3a–3b

Figure 9. RTT estimation to adjust timer T1

4.3. Fast failure detection SIP can use several transport protocols like TCP or UDP. TCP will take care of possibly lost packets and necessary retransmission whereas in case of UDP, the SIP transaction layer is responsible for retransmissions. The timeout values of TCP are not influenceable by the SIP application and may vary between different operating systems. For UDP as transport protocol, [11] proposes a timeout T1 = 0.5 s to wait for a final or provisional response before the retransmission will start. T1 will be doubled every unsuccessful transmission until it reaches T2 = 64*T1, then the transaction will be canceled. T1 reflects the estimated round-trip time (RTT) between the signaling nodes including processing time for the response at the answering node as shown in figure 9. In LANs 0.5 s is obviously too high for T1 and prolongs the detection of failures. Waiting 64*T1 will cause the user agent to wait 32 s before a SIP transaction will be treated as failed, which is far too much for mission critical applications. Therefore, an adjustment of T1 and T2 will be suggestive. Measurements with several SIP softphones and proxies in LANs showed an RTT between 2 and 18 ms, primarily depending on the implementation of the SIP application. In addition to timeouts, related ICMP error messages should also be processed to detect failures before a timeout occurs. Furthermore, ATC applications often require to detect failed components before they will be used. This is achieved by using keep-alive messages between the SIP nodes.

5. Performance To evaluate the feasibility of our signaling approach, we analyzed the event distribution of the radio server. We also measured the forwarding delay of a SIP proxy in a forking scenario, which is similar to the notification distribution scenario, to compare the results. In all scenarios UDP was used as transport protocol, to avoid additional delay due to the handshake of TCP during connection establishment and possible buffering in the TCP stack. The measurements used a dedicated

network protocol analyzer in a 10 MBit Ethernet collision domain and analyzed the timestamps of the captured packets. The proxy scenario was measured using an additional software based protocol analyzer at the SIP proxy to analyze the delay introduced by the operating system and the network. The radio server used the dissipate SIP stack on a Celeron 1.8GHz PC with Linux 2.4.20. As SIP proxy, we used the SIP Express Router on an Athlon 800MHz PC with Linux 2.4.20.

5.1. Radio server signaling performance Outgoing radio messages will be signaled to the radio server by a PTT-event as shown in figure 10. If the radio server grants access to the sector, it forwards the PTT notification to the radio gateway to activate the radio transmitter. Furthermore, the radio server also relays the notification to all subscribed operator positions. This is the confirmation for the PTT requesting operator that he gained access to the sector and all other operators are informed that the sector is currently allocated to operator 1. Table 3 shows average values for the signaling parameters of our radio server implementation. The setup consisted of one radio gateway, one radio server and five subscribed operating positions. The measurements were done in a pure signaling scenario without any RTP relaying. The 200 OK response to the incoming notification is sent by the SIP stack itself and takes about 5.0 ms. The generation of a NOTIFY transaction for each subscriber takes about 1.6 ms and is also done by the SIP stack itself. The required time to signal a PTT event to n operator positions can be calculated with equation (1). The generation of the notification at the operator position plus the processing at the radio gateway takes approximately the same time as the forwarding at the radio server (tsend + treceive = tf orw ). Therefore, tf orw is doubled. Forwarding of the PTT signal to 5 operator positions took about 24.2 ms. tP T T,n = tf orw ∗ 2 + tsend ∗ n

(1)

The same test has been performed with RTP relaying. In this scenario there were additional RTP streams between the radio server and each subscriber. The additional RTP delay was about 0.2 ms per packet. That

0-7695-2056-1/04 $17.00 (C) 2004 IEEE

7

Proceedings of the 37th Hawaii International Conference on System Sciences - 2004

operator position 2 tsend

operator position 3

radio server

1. NOTIFY PTT

operator presses PTT

2. SIP/2.0 200 OK 3d.

radio gateway 1

tOK

3b. NOTIFY PTT

3c.

treceive tsend

3a. NOTIFY PTT

PTT delay

operator position 1

treceive PTT indicated to operator

4b. SIP/2.0 200 OK

4c.

4a. SIP/2.0 200 OK

4d.

Figure 10. PTT signaling delay value reflects the packet time of the RTP packets on a 10 MBit Ethernet. As a fact, the 20th subscriber received the voice packets 4 ms later than the radio server.

5.3. Discussion of the measurement results

As the signaling delay increases with the number of subscribers, the maximum number of subscribers is limited by the performance of the SIP stack. Therefore, we compared our results with a SIP proxy in a similar scenario.

In [3], Eurocontrol suggests a maximum PTT/SQU signaling delay of 25 ms (local). The required 25 ms for PTT/SQU signaling are hard to achieve, even in traditional circuit switched systems. Our implementation achieved this requirement only with 5 or less subscribed operators. Therefore, the SIP stack must be faster, especially the generation of new transactions and requests.

5.2. SIP proxy forking performance

Another way to avoid sequential request generation for each subscriber would be the use of multicast or broadcast. SIP uses multicast only to discover registrars. Therefore, SIP would have to be adopted to support multicast messages. Unfortunately, such a SIP extension would break the existing SIP standard.

If multiple contacts are registered for the same address-of-record, the proxy forks requests to all registered contacts. If the proxy is transaction stateful, it has to maintain the state of all forwarded requests. We registered 20 contacts for one address-of-record and sent a MESSAGE request to this address, which in turn was forwarded to all 20 contacts. The proxy sent the messages approximately every 0.48 ms, which is nearly the theoretical maximum in 10 MBit Ethernet for a packet size of 576 Byte. Therefore, we repeated this test in a switched Fast Ethernet, which reduced the packet interval to one tenth. Capturing on the PC running the SIP proxy showed that the SIP proxy produces the messages every 0.02 ms. As a consequence, even Fast Ethernet is to slow to send the packets as fast as the proxy generates them. The radio server will not be as fast as a SIP proxy as it has to create separate transactions for each notification whereas the SIP proxy may treat the forking scenario as one transaction. The radio server also has to maintain the call state of every connected subscriber. Nevertheless, this comparison showed that there is a high potential to speed up the radio server and the event distribution by using a faster SIP stack.

Plain status information broadcast with UDP using the SIP stack would be a simple and fast way to signal events in the network. However, using the SIP based event notification has the advantage that also the status signaling is done by an open standardized protocol achieving interoperability among several manufacturers. Furthermore, the SIP based approach is also suitable for status signaling over WANs as it uses unicast. One reason for the required fast PTT/SQU signaling are the characteristics of the current circuit switched systems and the radio transmitters. The PTT signaling delay plus the transmitter attack-time delay must be less than the voice delay to avoid loss of syllables. As the voice delay is very small in the current systems, the PTT signaling has to be very fast. In an IP based system the characteristics have changed. Due to the packetizing delay and a necessary jitter buffer in the radio gateway— e.g. 20 ms frames and 40 ms jitter buffer resulting in a 60 ms voice delay—the timing requirements for the PTT/SQU signaling can be softened and should be reexamined.

0-7695-2056-1/04 $17.00 (C) 2004 IEEE

8

Proceedings of the 37th Hawaii International Conference on System Sciences - 2004

6. Quality of service Quality of service (QoS) goes along with fast call signaling, dedicated bandwidth for established calls and no network outages. This section shows one possible way to achieve the required QoS. Therefore, we break down the problem to the different areas of an ATC system. QoS does not only mean to prioritize RTP packets, but also the SIP signaling must be prioritized as both are necessary for voice communication. State of the art LANs use switched 100 MBit Ethernet and are able to operate at full wire speed. This is sufficient for 1050 concurrent streams in each direction when using uncompressed voice and 20 ms frame size. Prioritization mechanisms like IEEE 802.1p will ensure that SIP and RTP packets will be processed before nonprior data packets and as long as there are not more than 1050 streams at one switch port there won’t be any quality degradations caused by the LAN. The bandwidth of the WAN connections, or rather the bandwidth leased from Internet Service Providers (ISPs), is typically much lower, as WAN bandwidth is much more costly than LAN bandwidth. The maximum number of concurrent calls will be reached faster and then no further calls may be established as this would cause packet loss and decreases the quality of ongoing calls. Anyhow, emergency calls have the permission to intercept normal calls. This requires a node which monitors all calls which traverse the WAN and decline new calls if the maximum bandwidth is used or intercept already established calls. Therefore we suggest the use of a SIP B2BUA which controls the WAN calls as shown in figure 11. To prioritize voice packets, integrated or differentiated services [13] will be used, depending on the services offered by the ISP. Not only the network may cause problems, but also the end points. A COTS based infrastructure will use standard PCs and operating systems. Other applications may impact the voice communication application and the sound and network processing is a matter of the operating system and the device drivers. Achieving QoS in networks is much more straight forward than in PCs because various software-hardware combinations may require various prioritization mechanisms.

7. Related work The Eurocontrol Experimental Centre developed Audio-LAN, a Voice Communication System based on VoIP [2]. AudioLAN is used for simulation and training of flight operators only. It uses H.323 for call signaling and demonstrates the general feasibility of VoIP for

ATC, but does not use an open protocol for radio signaling. The Internet radio linking project (IRLP) [7] links ham radio systems together. It does not use any additional signaling, but rather derives the PTT and SQU signals from the existence of the audio stream. This system only has minimal functionality and signals too slow. Several radio equipment manufacturers like Catalyst Communications Technologies, Inc., Telex-Vega or JPS Communications already sell products to interconnect radio transceivers by VoIP. They use proprietary signaling protocols and therefore, these products are not interoperable with products of other vendors. Ericsson, Motorola, Nokia and Siemens mobile recently published a specification for a push-to-talk over cellular (PoC) service for GSM/GPRS networks [9], based on the IP Multimedia Subsystem (IMS) as defined by the 3rd Generation Partnership Project (3GPP). This specification uses SIP for initial session establishment but floor control is done using RTCP, in contrast to our architecture which uses SIP. To achieve reliable delivery of floor control messages, they had to introduce a retransmission mechanism above RTCP whereas our architecture relies on the retransmission mechanism of SIP. [5] proposes the PTT signaling by using the real-time transport control protocol (RTCP), but does not care about packet loss and the concurrent access to the radio channel.

8. Summary and future work Our SIP based approach fulfills the timing requirements for PTT and SQU signaling only for a reduced number of subscribers. The problem is caused by the used SIP stack which needs about 1.6 ms to create a SIP transaction. To meet the PTT/SQU signaling requirements, the used SIP stack has to be optimized to create new transactions faster and additionally the requirements should be re-examined. Furthermore, the signaling delay grows with the number of subscribers. Therefore, the SIP notification mechanism won’t perform well in applications with a lot of subscribers as every notification is a separate SIP transaction which creation takes time. In scenarios with a lot of subscribers, broadcast or multicast would reduce the signaling delay, but would lead to additional complexity if the notifications must be acknowledged. We showed that new applications for voice over IP communication like radio communication do not need new signaling protocols. SIP and its extensions offer enough methods to handle not only call setup but also PTT and SQU signaling. Furthermore it allows com-

0-7695-2056-1/04 $17.00 (C) 2004 IEEE

9

Proceedings of the 37th Hawaii International Conference on System Sciences - 2004

Radio

Radio Gateway Controller Working Position

Controller Working Position

Radio

IP-WAN

SIP B2BUA PSTN Gateway

Radio Gateway SIP B2BUA

PSTN

PSTN Gateway

Controller Working Position

Controller Working Position

Figure 11. B2BUA controls WAN calls patibility with products which do not support all SIP extensions like SIP phones. The presented service environment and the presented radio service architecture based on a client/server model enables vendors to build ATC centers, which comprise current needs by combining voice and data services, and are open for new services. Using an open standard like SIP as signaling protocol guarantees interoperability between different vendors and extensibility of current ATC services. As future work, an event package describing the syntax of the several NOTIFY messages required for radio signaling will be submitted as Internet draft. Furthermore, we plan to evaluate other SIP stacks for better signaling performance and to research interaction of QoS mechanisms with SIP.

[7] The internet radio linking project. http://www.irlp.net/. [8] G. Marsh. Air traffic control switches. Avionics Magazine, February 2001. [9] Push-to-talk over cellular specification. http://www.ericsson.com/multiservicenetworks/distr/ PoC specifications.ZIP. [10] A. B. Roach. Session Initiation Protocol (SIP)-Specific Event Notification, June 2002. RFC 3265. [11] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler. SIP: Session Initiation Protocol, June 2002. RFC 3261. [12] Y. J. Stein, R. Shaashoua, R. Insler, and M. Anavi. TDM over IP, June 2002. Internet Draft draft-anavi-tdmoip04. [13] X. Xiao and L. M. Ni. Internet qos: A big picture. IEEE Network, 13(2):8–18, Mar. 1999.

References [1] K. Darilion, W. Kampichler, and K. M. Goeschka. Event-based radio communication signalling using the session initiation protocol. In Networks, 2003. ICON 2003. 11th IEEE International Conference on, in press. IEEE, 2003. [2] Eurocontrol. Audiolan - radio/telephone voice communication system based on internet technologies. http://www.openatc.org/. [3] Eurocontrol. Eurocontrol guidelines for implementation support (egis), part 5, communication and navigation specifications, chapter 2, voice communication system (vcs). [4] A.-V. T. W. Group, H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson. RTP: A Transport Protocol for Real-Time Applications, Jan. 1996. RFC 1889. [5] D. Haldar. Session control through RTCP, an extension to RTCP, Nov. 2002. Internet Draft draft-haldar-rtpsession-control-00. [6] M. Handley and V. Jacobson. SDP: Session Description Protocol, Apr. 1998. RFC 2327.

0-7695-2056-1/04 $17.00 (C) 2004 IEEE

10