S UMMARY

This chapter described IEEE 802.1X authentication for WLAN and Cellular integration. We presented the protocol stack and the authentication message flow, and measured the response times of all EAPOL message exchanges in the IEEE 802.1X authentication for the integrated system implemented in NCTU.

In the IEEE 802.1X standard, a fixed-value timer is used in all authentication message exchanges, which does not reflect the real network operation. A modeling study was presented in this chapter to tune the values of individual timers, which yields better performance than the fixed timeout period setting.

Our study provides guidelines to select appropriate timeout periods for corresponding authentication message exchanges. For example, comparing with the fixed timeout periods setting where T_X are set to 10 seconds, the suggested setting for the timeout periods (i.e., Ts = 10 seconds, Ta1 = 10 seconds, Ta2 = 5 seconds, and Ta3 = 30 seconds) decreases the false failure detection probability p_f and significantly improves the expected response time E[τ] of the IEEE 802.1X authentication procedure.

Chapter 3

IPsec-Based VoIP Performance in WLAN Environments

3GPP specifies 3G-WLAN interworking that allows a Mobile Station (MS) to access the 3G network through a WLAN Access Gateway/Packet Data Gateway (WAG/PDG), and specifies that the packets delivered between the MS and the WAG/PDG should be protected with IPsec.

This chapter studies the performance of IPsec-based VoIP service in a WLAN environment.

The IPsec overheads in terms of throughput, packet loss rate, latency, and jitter are investigated. Our study provides guidelines to select appropriate system parameter values for VoIP over WLAN.

3.1 Introduction 

The 3GPP Technical Specification 23.234 [20] specifies 3G-WLAN interworking that extends 3G services to the WLAN environment. In 3G-WLAN interworking, a Mobile Station (MS) in the WLAN accesses the 3G core network through a WLAN Access Gateway/Packet Data Gateway (WAG/PDG). The security requirements are enforced such that between an MS and the WAG/PDG, IPsec security association is established and the transmitted packets are protected by IPsec with Encapsulating Security Payload (ESP) in the tunnel mode [21]. In an IPsec tunnel, an original IP packet, including the header and the payload, is encrypted and authenticated, and a new IP header is added to route the packet between the MS and the WAG/PDG. Before sending an IP packet, the MS checks the security policies applied to the

packet and performs IPsec encapsulation according to the methods defined by the security association. When receiving an IPsec packet, the WAG/PDG validates and decapsulates the packet according to the security information of the corresponding security association. By exercising IPsec encapsulation, the sizes of the packets transmitted between the MS and the WAG/PDG increase and the performance degrades.

Voice over Internet Protocol (VoIP) provides voice communications over Internet [15], where Session Initiation Protocol (SIP) [22] is often used to control the call and Real-time Transport Protocol (RTP) [23] is used to deliver the voice data. Several codecs can be used in the RTP calls to meet the bandwidth restrictions. In a 3G-WLAN interowking environment, the VoIP performance may be degraded due to IPsec encapsulation. This chapter investigates the performance of IPsec-based VoIP in the WLAN environment, and is organized as follows. The related works are elaborated in Section 3.2. Our experimental environment is described in Section 3.3, and the performance measures (throughput, packet loss rate, latency, and jitter) are reported in Section 3.4. Based on the performance measurements, Section 3.5 suggests proper system parameter setups for IPsec-based VoIP in the WLAN environment.

3.2 Related Works 

The IPsec performance for VoIP in the wireless environments has been investigated in [24, 25, 26, 27]. The latency performance for IPsec security association was investigated in [25]. The study in [24] presented the IPsec performance for VoIP by evaluating speech quality with G.711 codec. The speech quality was evaluated by a subjective method called Mean Opinion Score (MOS). The study in [25] measured IPsec-based VoIP over 3G-WLAN interworking system with different types of codecs. The studies in [26, 27] investigated the VoIP performance with mathematical analysis and simulation experiments of network capacity (in

terms of the number of supported RTP streams).

In the previous experimental studies, the performance measurement tools were run on the MS, which may affect the accuracy of the reported results. In [24], the QoS measurement tool developed by the authors was executed on the MS. In [25], four tools were executed on the MS, including RTP Tools to send and receive the RTP packets, network monitor tools pktstat and Netperf to measure the network traffic and collect the performance data, and Ethereal to record network packet events on the MS. In our experiments, all performance data are collected and measured by Smartbit. The MS only processes the VoIP packets as in the normal operation mode, and its computing power is not consumed for measurement.

The performance results presented in the previous studies are quite different due to different experimental setups and the output measures defined. The MOS measure considered in [24]

provides useful insight for voice quality. However, it does not reflect the effect of delays. Also the IPsec performance in terms of packet loss, latency, and jitter were not presented. The analytical studies in [26, 27] showed the IEEE 802.11b AP capacity for plain VoIP without packet loss. They did not consider the relationships between the throughput and the VoIP traffic load. The performance results in [25] are not consistent with that in [26, 27]. On the other hand, we conduct our measurements by setting the same experimental parameters to those in [26, 27], and obtain the consistent results

All these previous studies did not consider heavy VoIP traffic issues that are further elaborated in this chapter. Heavy traffic analysis provides useful insight to a VoIP operator to determine what kinds of codec and packet loss concealment techniques should be employed. We also elaborate on the IPsec overhead in terms of latency, and compare the jitter performance for VoIP with and without IPsec. These aspects were not investigated in the previous studies.

3.3   IPsec­based VoIP Experimental Environment

Figure 3.1 illustrates a simplified 3G-WLAN integration system, where the MS (Figure 3.1 (1)) is a laptop equipped with Pentium M 1.3GHz CPU and 256MB memory. The WAG/PDG (Figure 3.1 (2)) is a laboratory prototype implemented in a PC equipped with Pentium IV 3.0 GHz CPU and 1GB memory. The MS communicates with the WAG/PDG via a D-Link DL-524 IEEE 802.11b access point (AP; Figure 3.1 (3)). The AP connects to the WAG/PDG through the Ethernet where the peak rate is 10Mbps. The Smartbit (Figure 3.1 (4)) is utilized for performance measurement [28], and is connected to the MS and the WAG/PDG using CAT 5 cables with the RJ-45 interface.

Figure 3.1 The Experimental Environment Table 3.1: The Codec Attributes

Codec G.711 G.729

Bit Rate

64 Kbps, sampling at an 8 KHz rate with 8 bits

160 Bytes, one frame per RTP packet

10*2 Bytes, two frames are combined into one RTP packet

RTP Packet Rate 50 packets/sec 50 packets/sec MS

In the experiments, the Smartbit generates multiple RTP streams identified with different source/destination IP address pairs, and injects them to the MS. The RTP packets are transmitted over UDP. Two kinds of voice codecs, G.711 [29] and G.729 [30], are used in generating the RTP streams. G.711 is a high bit-rate codec with a sample period of 20 ms.

G.729 is a low bit-rate codec with a sample period of 10 ms. The codec attributes are summarized in Table 3.1.

When the MS receives the RTP packets from the Smartbit, it encapsulates these packets with IPsec ESP in the tunnel mode. The RTP packets are encrypted by the 3DES algorithm [31], and are authenticated by the HMAC-SHA-1-96 algorithm [32]. Then the encapsulated packets are sent to the WAG/PDG via the IPsec tunnel. Upon receipt of the IPsec packets, the WAG/PDG executes the IPsec decryption procedure. The decrypted RTP packets are then collected by the Smartbit. From the measured packets, the Smartbit produces the output statistics.

3.4   Performance Measurement 

Based on the experimental environment described in Section 3.3, we measure the IPsec overhead in terms of throughput, packet loss rate, latency, and jitter.

3.4.1 Throughput and Packet Loss Rate 

Figure 3.2 (a) illustrates the packet loss rate measured by the Smartbit. The study in [26, 27]

derived an upper bound for the VoIP capacity (in terms of the number of the supported RTP streams) over IEEE 802.11b without packet loss. By using the equation derived in [26, 27], we compute the upper bound of network capacity for IPsec-based VoIP. Table 3.2 compares

the VoIP capacity without packet loss between the measured values in our experiments (Figure 3.2) with the upper bounds derived in [26, 27]. This table shows that the measured capacity without packet loss achieves about 85% of the calculated upper bound capacity.

Table 3.2 also indicates that after IPsec encryption, the capacities without packet loss degrade by 4% (in terms of the number of RTP streams supported) for G.729 and 5% for G.711, respectively.

(a) Packet Loss Rate (b) Throughput Figure 3.2 Packet Loss and Throughput (N: Number of RTP Streams) Table 3.2 Measured Capacities without Packet Loss and Their Upper Bounds Codec IPsec Encrypted Upper Bound Capacity Measured Capacity

G.729 no 24.1 RTP Streams 20 RTP Streams

yes 23.2 RTP Streams 19 RTP Streams

G.711 no 21.5 RTP Streams 18 RTP Streams

yes 20.7 RTP Streams 17 RTP Streams

The study in [25] showed that the IEEE 802.11b AP can support 28 IPsec VoIP connections

for G.711 with packet loss rate less than 1%. This result is probably misleading because the reported number of VoIP connections (i.e., 28) exceeds the capacity upper bound derived in [26, 27]. Our experiments and the studies in [26, 27] show that when the packet loss rate is less than 1%, the IEEE 802.11b AP can only support 20 and 17 IPsec VoIP connections for G.711, respectively.

Figure 3.2 (a) indicates that to maintain the same packet loss rate, the system can support one less IPsec RTP streams than original RTP streams. For examples, when the packet loss rate is 10%, the system can support 21.86 original RTP streams or 21.13 IPsec RTP streams for G.729 (i.e., the IPsec overhead is 3.34%), and can support 20.02 original RTP streams or 19.15 IPsec RTP streams for G.711 (i.e., the IPsec overhead is 4.35%).

Figure 3.2 (a) also shows that as the system attempts to support more RTP streams (and therefore the packet loss rate increases), the IPsec overhead becomes less significant. For example, when the packet loss rate increases from 5% to 20%, the IPsec overhead decreases from 3.80% to 3.29% for G.729, and from 5.12% to 3.55% for G.711.

Based on the mathematical analysis in [26, 27], we further derive the capacity of an IEEE 802.11b AP for IPsec VoIP. Figure 3.2 (a) indicates that the packet loss rate increases to 5% – 6.3% when the VoIP traffic is one RTP stream larger than the network capacity without packet loss. This result is consistent with the simulation results in [26, 27].

Figure 3.2 (b) illustrates the throughput performance. We note that the following relationship holds:

Packet Loss Rate = Arrival Rate × Packet Size – Throughput Arrival Rate × Packet Size

where the arrival rate is 50 packets/sec times the number of RTP streams. This figure indicates

that the system saturates if we pump more than 20 original RTP streams or 19 IPsec RTP streams for G.729 (or 18 original RTP streams or 17 IPsec RTP streams for G.711). By exercising IPsec, the maximum throughput for the system degrades by 5% for G.729, and 5.56% for G.711. When the system is not saturated, the throughput for supporting both original and IPsec RTP streams are the same.

3.4.2 Latency   

The latency performance is affected by the following factors: (1) packet processing, (2) packet delivery, and (3) packet loss. Both packet processing and packet delivery contribute to queueing, and therefore will increase the latency. During delivery, packets may be retransmitted due to transmission errors or collisions (i.e., congestion of the radio link). In IEEE 802.11b, a packet is transmitted after a backoff delay. For each retransmission, the average backoff delay is doubled. When the number of retransmissions for a packet reaches the retry threshold, it is discarded. Packet loss mitigates queueing effect, and therefore will

“stop” increasing of the latency caused by packet retransmission.

Figure 3.3 (a) shows that the mean latency is an “S”-shape increasing function of the number N of RTP streams.

Case I. When N < 10, increasing the stream number insignificantly affects the latency. In this case, there is no packet loss, and packet retransmission seldom occurs. Therefore, the latency is caused by the queueing effect of packet processing. For example, when N increases from 5 to 10, the latency increases from 1.17 ms to 1.30 ms (i.e., increases 11.11%) for G.729, and from 1.39 ms to 1.41 ms (i.e., increases 1.44%) for G.711.

Case II. When 10 ≤ N ≤ 20, the latency increases significantly as N increases due to both

packet processing and packet retransmission. For example, when N increases form 15 to 20, the latency increases from 1.72 ms to 101.22 ms for G.729, and from 2.10 ms to 139.38 ms for G.711.

(a) The Mean Latency (b) Latency Overhead Figure 3.3 Latency Performance

Case III. When N > 20, the latency only slightly increases as N increases due to packet loss.

As shown in Figure 3.3 (a), packet loss significantly increases as N increases for N ≥ 20.

When N increases form 25 to 30, the latency increases from 132.99 ms to 134.95 ms (i.e., increases 1.47%) for G.729, and from 147.82 ms to 149.23 ms (i.e., increases 0.95%) for G.711.

The latency performance reported in [25] showed the same trend as our results for Case I and II. However, Case III was not investigated in [25].

Since the packet size for G.711 is larger than that for G.729, Figure 3.3 (a) shows that the packet processing time for G.711 is longer than that for G.729. Similarly, the latencies for IPsec RTP streams are longer than that for original streams. Specifically, the latency overhead for IPsec can be calculated as

Latency Overhead = IPsec RTP Latency – Original RTP Latency Original RTP Latency .

When N < 15, the IPsec overhead is less than 9.26% due to insignificant queueing effect contributed by packet processing. When 15 ≤ N ≤ 20, the latency overhead for IPsec significantly increases (can be up to 570.97%). In this case, for the same N value, IPsec streams experience heavy packet retransmission. On the other hand, packet retransmission is not significant for original streams. For N > 20, the system saturates for both IPsec and original streams. That is, many packets will reach the retransmission threshold and are dropped in both IPsec and original streams. Therefore, the latency overhead for IPsec drops to less than 4.38%.

3.4.3 Jitters 

Jitter or the variation of packet inter-arrival time may create unexpected pauses between utterances, and therefore affects the intelligibility of the VoIP speech. It was reported that an average jitter exceeding 35 ms results in unacceptable QoS for VoIP [28]. To reduce jitter, a buffer is used to store the incoming packets before they are played. If the jitter buffer size is too small, network jitter will result in packet loss and therefore degrade the intelligibility of the voice. If the jitter buffer size is too large, long packet delay will be experienced, which results in QoS degradation (e.g., echo level may be more easily perceptible). NTT Communications specifies that the average jitter should be no more than 0.5 ms for VoIP [33].

Figure 3.4 shows that without jitter buffer, the jitter is an “S”-shape increasing function of the number N of RTP streams in our experiments. When N < 5, the RTP packets experience less link congestions and the average jitters are less than 0.5 ms. When 5 ≤ N ≤ 25, the average jitter significantly increases as N increases. When N > 25, the system saturates and the average jitter increases to about 10 ms. To maintain the same average jitter, the system supports about one less IPsec RTP streams than original RTP streams. For example, to limit the average jitter to 1 ms, the system cannot support more than 17.77 original RTP streams or 16.75 IPsec RTP streams for G.729 (i.e., the IPsec overhead is 5.74%), and cannot supports more than 15.88 original RTP streams or 15.39 IPsec RTP streams for G.711 (i.e., the IPsec overhead is 9.79%).

Figure 3.4 Jitter Performance (Without Jitter Buffer)

Figure 3.4 also indicates that the jitters for the G.711 RTP streams are larger than that for G.729 RTP streams. Since packet size for G.711 is larger than that for G.729, G.711 causes more link congestion than G.729 does.

In our experiments without jitter buffer, the average network jitters (between the MS and the WAG/PDG) range from 0.44 ms to 14.55 ms. Thus, to eliminate the jitter effect caused by

WLAN, at least one G.711 or G.729 RTP packet (i.e. 20 ms) should be buffered to achieve the jitter performance specified by [33]. Also, the jitter buffer size is not affected by IPsec in this case.

3.5 Conclusions 

This chapter investigated the performance of IPsec-based VoIP service measured in the WLAN environment. The overheads caused by IPsec encapsulation were discussed in several aspects.

After IPsec encapsulation, the performance of IEEE 802.11b without packet loss degrades by 4% (in terms of the number N of RTP streams supported) for G.729 and 5% for G.711, respectively.

The IPsec encapsulation causes more packet processing, packet retransmisstions, and packet loss, and therefore results in extra latency. When N < 15, the IPsec overhead is less than 9.26%. When 15 ≤ N ≤ 20, the latency overhead for IPsec significantly increases (can be up to 570.97%). For N > 20, the latency overhead for IPsec drops to less than 4.38%.

Similarly, IPsec encapsulation results in extra jitter overhead. When N < 15, the IPsec overhead is about 10%. When 15 ≤ N ≤ 25, the jitter overhead for IPsec significantly increases (can be up to 26.3%). For N > 25, the jitter overhead for IPsec drops to less than 13.47% for G.711 and 8.24% for G.729.

Our study provides guidelines to select appropriate system parameters setups for the VoIP service over WLAN environment. Specifically, for an IEEE 802.11b AP, the system saturates if we pump more than 20 original RTP streams or 19 IPsec RTP streams for G.729 (or 18 original RTP streams or 17 IPsec RTP streams for G.711). Also, for transmission in IEEE 802.11b, at least one G.711 or G.729 RTP packet (i.e. 20 ms) should be queued in the jitter

buffer to achieve acceptable VoIP performance specified by [33]. We also observed that the jitter buffer size is not affected by IPsec encapsulation in the IEEE 802.11b configuration in our study.

Chapter 4

M-Taiwan Experience in VoIP-WiMAX Trial

Considering voice as a dominant telecommunication service, the performance of Voice over IP (VoIP) plays a critical role in deployment of WiMAX technology providing All-IP network services. To that effect, in this chapter we investigate the performance of a WiMAX-based VoIP established under the Mobile Taiwan (M-Taiwan) field-trial funded program. To achieve the objectives of the trial the measurement results expressed in the form of Mean Opinion Score (MOS), packet loss, packet delay and jitters. For the worst-case-scenario, the tests were conducted under a stringent condition of both communicating devices, wirelessly connected to the same WiMAX base station under a heavy background traffic and interference, were experiencing simultaneous handovers during the communication.

Upon our analysis the field measurements confirm an excellent performance when both communicating devices kept stationary and show an acceptable quality for the service when both communicating devices are on the move at a speed of 50 Km/h.

4.1   Introduction 

Taiwan's Wi-Fi industry accounts for more than 90% of the global market share. In its quest to identify the next generation products, the Taiwan government has chosen Worldwide Interoperability for Microwave Access (WiMAX) [5] as one of the major directions for Taiwan’s wireless industry, and has established the Mobile Taiwan (M-Taiwan) Program as the blueprint for an island-wide WiMAX environment. M-Taiwan aims at developing chip

sets and base stations (BS). For example, WiMAX chip sets have been developed by Mediatek, and the BSs have been developed by T-Com and ZyXEL. Furthermore, by creating its own WiMAX ecosystem, Taiwan offers not only manufacturing capabilities, but also an entire service and application test-bed for mobile services, mobile learning and mobile life.

Since 2006, 18 large-scale WiMAX service trials have been deployed in Taiwan [34, 35].

In M-Taiwan, the Voice over IP (VoIP) service is considered as an enabling technology integrating broadband data applications with the voice. In particular, IP Multimedia Core Network Subsystem (IMS) [15] is utilized for voice and data integration. Under the support of the M-Taiwan Program, this chapter investigates the VoIP performance for a WiMAX deployment in Taipei City. In this chapter, we elaborate on the VoIP experimental environment, describe the output measures, and demonstrate the VoIP performance with and without mobility. The remainder of this chapter is organized as follows. Sections 4.2 and 4.3 provide a brief overview of VoIP service and WiMAX system. The general configuration

In M-Taiwan, the Voice over IP (VoIP) service is considered as an enabling technology integrating broadband data applications with the voice. In particular, IP Multimedia Core Network Subsystem (IMS) [15] is utilized for voice and data integration. Under the support of the M-Taiwan Program, this chapter investigates the VoIP performance for a WiMAX deployment in Taipei City. In this chapter, we elaborate on the VoIP experimental environment, describe the output measures, and demonstrate the VoIP performance with and without mobility. The remainder of this chapter is organized as follows. Sections 4.2 and 4.3 provide a brief overview of VoIP service and WiMAX system. The general configuration