UDP Performance Measurements over TETRA IP 1
D. I. Axiotis1, D. Xenikos2 Telecommunications Laboratory, School of Electrical and Computer Engineering, National Technical University of Athens, Greece 2 Mobile Communications Planning Dept., OTE S.A., Greece Email:
[email protected],
[email protected]
Abstract— This paper presents the results of an extensive measurement survey on the performance of the User Datagram Protocol (UDP) over the Packet Data Channel (PDCH) of Terrestrial Trunked Radio (TETRA) Networks. Measurements were taken over a client – server communication for UDP datagram sizes varying from 50 to 600 bytes with an increment of 50 bytes. For each datagram size, a constant bit rate UDP traffic generator was used and a 1800s measurement was taken with network performance monitoring software. Results obtained include throughput and delay jitter (mean values and standard deviations), percentage of lost datagrams and percentage of datagrams received out-of-order versus the datagram sizes.
I. INTRODUCTION Terrestrial Trunked Radio (TETRA) is an ETSI standard for advanced private mobile radio/public access mobile radio (PMR/PAMR) networks [1]. TETRA is largely deployed in Europe, and since one of its main features is the enhanced security, it is used by various public safety organizations (e.g. police) or public transportation media. It is hence critical to study the performance of the services provided by TETRA; in this paper we focus on measuring and analyzing the performance of User Datagram Protocol (UDP) over IP in TETRA. TETRA provides the capability of trunked, non-trunked and direct mobile-to-mobile communication. The offered services include voice (group or private calls), circuit switched data, packet switched data and Short Data Service (SDS)similar to Short Message Service (SMS) in GSM. TETRA security [2] was based upon the GSM and DECT security and added functionalities which are relevant for professional mobile radio users, such as enhanced key management support, end-to-end encryption [3], encryption for closed user groups and secure enabling / disabling of mobile terminals. The TETRA standard supports the mutual authentication of a Mobile Station (MS) and the TETRA Switching and Management Infrastructure (SwMI). This makes it possible for a TETRA system to control the access to it and for an MS to check if a network can be trusted. OTE S.A. is a commercial TETRA operator in Greece, with a network of over 90 Base Stations, providing radiocoverage in major cities and auto routes, the scale of network deployment being one of the largest in Europe; the network served over 16000 users during the Athens 2004 Olympics [4]. Although the packet data mode was available in the Switching and Management Infrastructure (SwMI), only recently packet-enabled mobile terminals were released. Consequently, many applications previously developed over SDS
1550-2252/$25.00 ©2007 IEEE
are migrating to packet data in order to take advantage of the IP capability: Applications that run over IP (but are aware of the mobile environment and the low bandwidth available, e.g. already developed for GSM) can be adapted for TETRA. Most popular services include Automatic Vehicle Location (AVL), fleet management, Customer Relationship Management (CRM) and transmission of sensor surveillance/security data (relay or backbone for Supervisory Control and Data Acquisition- SCADA systems). In order to effectively design, implement and operate such services under predefined QoS constraints, one must have good knowledge of the wireless medium, as well as the limits imposed by the TETRA air interface in terms of bandwidth and radio capacity. A usual situation we faced working as network engineers in a commercial TETRA network, is that we were contacted by numerous application programmers developing applications/services over TETRA IP. Shortly, it became apparent that in the majority of cases the programmers were recoding old commercial products originally developed for GSM/GPRS or even UMTS to extend their functionality for TETRA. Unfortunately, they were ignoring the particularities of TETRA air interface; applications developed for packet switched networks offering high data rates cannot be easily adapted to TETRA IP. While adapting GSM applications to TETRA, one must also take into account the dense coverage and hence, capacity of GSM networks: For example, the greater Athens area is covered by 20 TETRA cells, while a typical GSM operator has deployed over 500 cells in the same area. Hence TETRA operators must always balance the traffic originating from the massive use of TETRA IP by 3rd party service providers (e.g. Taxi on Demand Dispatchers running AVL over TETRA) by adding carriers, Packet Data Channels (PDCHs) and cells to meet the overwhelming demand for capacity. This paper focuses in the PDCH and the performance of UDP, which is the recommended transport protocol in TETRA. The motivation of this research was -from the scope of a network operator (OTE S.A.)- to facilitate the deployment of commercial services, while at the same time optimize the network performance, by measuring and analyzing system performance metrics. We have found no similar study in the literature up to the time we prepared this manuscript. The metrics examined include throughput, delay jitter, percentage of lost datagrams and datagrams received out-of-order. We should stress out that all TETRA infrastructure and equipment used to achieve the presented results comply with the ETSI TETRA standards and the manufacturers are members of
1331
TETRA MOU [5]; hence the results could be exploited for other TETRA networks complying with the same standards. The paper is organized as follows: In Section II we analyze the TETRA PDCH and the reasons to use UDP instead of TCP. In Section III we describe the measurement setup including information on the traffic generation and the measurement tool we used, as well as the differences of TETRA packet data modems compared to wireline modems. Section IV presents the results obtained, while Section V concludes the paper. II. TETRA PACKET DATA CHANNEL Packet data transfer in TETRA takes place over an assigned secondary control channel (assigned SCCH), termed as Packet Data CHannel (PDCH). The assigned SCCH may be used by a certain group of MSs for a particular signaling message or data exchange (packet data), or it may be shared between several MSs each with intermittent bursts of signaling to send. The BS may use an assigned SCCH as a general packet data channel supporting advanced links for several MSs, where each MS may be intermittently offering data packets. An advanced link is set up before data transfer may begin on the PDCH. When a MS has data to transfer, it implicitly requests permission to switch to the PDCH. If accepted, the SwMI responds with a channel allocation, directing the MS to a PDCH. The Packet Data (PD) bearer service is the implementation of IP version 4 on top of the TETRA SubNetwork Dependent Convergence Protocol (SNDCP). The PD bearer service is terminated at the IP protocol. The Packet Data service follows the principles used in the IP world. Delivery is on a best effort basis, and if it cannot be achieved (MS not registered, MS out of range etc.) the datagram is discarded. The system supports the Internet Control Message Protocol (ICMP), which means that any non-deliveries will be reported to the source (ICMP messages). The PD service is designed to take care of all mobility aspects for the users of the service, thus a host connected to a MS does not need to know the location of the destination when sending a datagram. The applications however, need to take into account the narrow bandwidth channel and varying environmental conditions, as the bandwidth and delay may vary with signal conditions and network loading. Each message is sent across the air interface using the TETRA SNDCP service. The underlying TETRA layer 2 (LLC & MAC) splits the message up into segments which are mapped into slots. Since each segment carries a fixed amount of bits, the used air interface resources increase in jumps on some message length boundaries. The “cost” of sending an IP datagram is therefore a basic signaling cost, plus a “variable cost” depending on the size of the IP datagram. The boundaries where additional slots are necessary are summarized in Table 1 [6]. For example in the downlink, any IP datagram from 21 (minimum IP datagram size) to 49 bytes will consume the same amount of resources. Note that the IP datagram size includes the IP and transport protocol header. For UDP, the IP and UDP overhead is 28 bytes. In order to send 130 bytes of user data, an IP datagram of length 158 bytes must be sent this requires 4 additional downlink slots.
As will be analyzed in the following, the recommended transport protocol on top of IP is UDP. It is a minimal message-oriented transport layer protocol, documented in [7]. Using UDP, applications running in Terminal Equipment (TE) or MS can send short messages known as datagrams to one another. UDP does not provide the reliability and ordering guarantees that Transmission Control Protocol (TCP) does, hence datagrams may arrive out-of-order or be lost without notice. However, as a result, UDP is faster and more efficient for many lightweight or time-sensitive purposes. UDP adds only application multiplexing and data checksumming on top of an IP datagram. Lacking reliability, UDP applications must generally be willing to accept some loss or errors. Some applications may implement additional reliability mechanisms in the application layer if needed. If an application requires a high degree of reliability, a protocol such as the TCP may be used instead. The network does not store data in case an IP datagram is not delivered; it drops the datagram and sends back an ICMP message to the originator. The originator must then decide what action to take. The returned ICMP message will provide the reason why the message was not delivered. For some applications, loss of a packet may not be critical. In the simplest usage of PD, the user sends a packet and ignores all reasons that cause a single packet to be lost. However, if the system refuses to deliver the message because the destination is unknown in the system, the application should flag an error to the user so that corrective action can be taken. If an ICMP "Host unreachable" message is received for a packet, the network has done its best to deliver the packet. In this case, retransmitting the packet will most likely not result in delivery success. Hence, the application should implement a kind of back-off and suspend sending packets for a while. Unlike UDP, TCP needs to establish a connection before any data can be exchanged. This means that several messages must be exchanged between the initiator (the client) and the receiver (the server), before the actual data is sent. TCP in this case has a large overhead compared to using UDP. TCP also retransmits segments for which it has not received acknowledgements within the retransmission timeout period (RTO). The first TCP retransmission occurs after 1*RTO, the next after 2*RTO, then 4*RTO, etc. and the procedure continues until the interval between retransmissions reaches a predefined upper limit. After this, all retransmissions will occur with an interval equal to this limit. Retransmissions will continue until TCP eventually gives up - in a typical TCP implementation this will happen after 9 minutes. The actual RTO used by the transmitter is an estimate of the round trip time (RTT). Typically, the RTO is set to twice the estimated RTT. The retransmission strategy in TCP is designed for use in large IP networks, usually characterized by local links with plenty of bandwidth or long haul links shared by many users. Both of these will tend to provide an RTT variance that is less than the one experienced in a radio environment. As an example, if TCP adapts to the radio environment during one access of the PDCH, then the next time the PDCH is accessed, the traffic conditions may have changed radically (idle to busy system, good signal reception to bad reception).
1332
Table 1: Slots needed in the uplink/downlink vs. Max IP datagram size Additional Max IP dataUplink/ gram size (bytes) Downlink Uplink/ Slots Downlink 50/49 1 79/76 2 107/104 3 136/132 4 164/160 5 193/187 6 221/215 7 250/243 8 278/271 9 307/298 10 335/326
Additional Uplink/ Downlink Slots 11 12 13 14 15 16 17 18 19 20 21
Max IP datagram size (bytes) Uplink/ Downlink 364/354 392/382 421/409 449/437 478/465 506/493 535/520 563/548 592/576 620/604 649/631
III. MEASUREMENT SETUP We performed the UDP performance measurement survey in a commercially deployed TETRA network (OTE S.A.) which provides dense coverage in major Greek cities and auto routes, through over 90 Base Stations (being one of the largest networks in Europe). The network is Voice+Data (V+D) ready and one PDCH was available per direction (uplink, downlink) in the cells where we performed the measurements. The carriers allocated to OTE S.A. by the national regulatory authority are 413.750 – 415.725 MHz (uplink) and 423.750 – 425.725 MHz (downlink). All TETRA infrastructure and terminals we used in this measurement survey, comply with the ETSI TETRA standards as well as TETRA MOU interoperability procedures with respect to the use of hardware from different manufacturers [5]. Hence, our results should apply to other TETRA network operators complying with the same standards, given the measurement setup, network traffic and radio propagation conditions as presented in this chapter. The measurement equipment included two TE running on Microsoft Windows XP (one desktop and one laptop), and two MSs (Motorola MTH 650) that support packet data. The MSs adhered to Class A and Class B receiver class [1]. Class B equipment is optimized for use in built-up and urban areas, guaranteeing good performance at the reference sensitivity and interference level in static and TU50 (Typical Urban at 50 km/h) conditions, but not in extreme propagation conditions [1]. Class A equipment is optimized for use in urban areas and in areas with hilly or mountainous terrain. It is resilient to extreme propagation conditions and is specified in static, TU50 and HT200 (Hilly Terrain at 200 km/h) conditions [1]. The MS receiver dynamic reference sensitivity level is -103 dBm, and the maximum permissible Message Erasure Rate (MER) at this level is for the Signaling Channel (SCH) is 8% at TU50 and 11% at HT200 for Class A terminals, while for Class B terminals it is 8% at TU50 [1]. The mobile terminals were connected to the computers via the PEI over a serial cable (RS-232). The terminals were set to data only mode, so that ongoing voice group calls would not influence our measurements. Interfacing to a MS to access the packet data service is very similar to the way you interface to a wireline modem. When configuring a TE (e.g. a PC) to interface with a MS, the TE will generally be configured to believe that it is connected to a wireline modem. However, there are some essential differences between a TETRA and a wireline modem. One major difference is that a wireline modem pro-
vides a circuit mode connection to the Network Access Server (NAS), whereas the Packet Data service is entirely packet switched. Thus the NAS, the Packet Data Gateway (PDG), and the MS communicate in a truly packet switched manner. Hence, if no data is being sent, no bandwidth is consumed. Furthermore, there is no need to tear down the communication with the NAS (PDG): the MS/TE can remain "connected" all the time, providing very fast access to the packet data service. Another major difference is that, in a normal wireline modem environment, the PPP link from the host is terminated in the NAS, i.e. the modem simply carries PPP transparently. In the packet data service, the PPP link is terminated in the MS. Whenever an IP datagram is sent to/from a host, the IP datagram is re-packed in a TETRA specific protocol, optimized for the radio communication environment. This adaptation to the radio environment provides the following advantages: Radio link layer failure may cause lost IP datagrams but will not cause lost dial-up calls. In a circuit switched dialup environment, (radio) link layer failure will typically cause the circuit (call) to be dropped. Sessions can stay alive even if the radio temporarily moves out of coverage (the PPP link is not broken). In the circuit switched case, re-establishing the circuit requires that the host re-dials the connection and re-establishes the PPP link. This will typically cause all sessions to be lost, requiring the user to re-login and re-authenticate. IP datagrams lost on the radio link layer can be reported as lost (ICMP). After establishing packet data connections on both terminals, we may run a standard application that can measure UDP performance metrics. We chose IPERF [8], an open source application, and configured it to act as a server in the laptop and as a client in the desktop PC. IPERF creates a constant bit rate UDP stream of specified bandwidth. It is possible to adjust the datagram size to the match the application uses. The server detects UDP datagram loss by ID numbers in the datagrams. Out-of-order datagrams are also detected. Jitter calculations are continuously computed by the server, as specified by RealTime Transport Protocol (RTP) in [9]. The client records a 64 bit second/microsecond timestamp in the packet. The server computes the relative transit time as (server's receive time) minus (client's send time). The client and server clocks do not need to be synchronized; any difference is subtracted out in the jitter calculation. Jitter is the smoothed mean of differences between consecutive transit times. The client (fixed PC host) was kept stationary throughout the measurement campaign; the received signal strength had a mean of -77dBm with a standard deviation of 4.8dB. Since we had access to operator proprietary network management & monitoring tools, we verified that the TETRA terminal at the client was attached to the same cell through the measurements and no handovers were performed. Note that the received signal level was measured independently using specialized software (Nemo Technologies ParTet), along with other parameters such as BER/MER. The server (mobile laptop host) resided inside a vehicle, in a different cell with respect to the client. In order to keep the radio propagation conditions as constant as possible throughout the campaign, we chose a route where the mean received signal strength was -80dBm
1333
mean throughput is over 1.5kbps in all occasions. The standard deviation of the throughput is also greatly affected by the datagram size, and increases from 0.2 kbit/s for the small datagrams to over 1kbit/s for datagrams larger than 200 bytes; since larger datagrams take longer to be received, it follows than the instantaneous throughput is influenced and in turn the standard deviation of the throughput is affected. 3.5
3
Mean Throughput (kbps)
with a standard deviation of 6.9dB. Such received signal strength corresponds to approximately 70% of the covered area in the Attica basin based on radiocoverage measurements performed by the operator [10]. The signal to noise ratio, Es/N0, was larger than 19dB in all occasions, corresponding to MER
