Performance Optimization of VoIP Calls over
Wireless Links Using H.323 Protocol
Sajal K. Das, Member, IEEE Computer Society, Enoch Lee,
Kalyan Basu, Member, IEEE Computer Society, and Sanjoy K. Sen
Abstract—Intelligent mobile terminals (or users) of next generation wireless networks are expected to initiate voice over IP (VoIP) calls using session set-up protocols like H.323 or SIP (session initiation protocol). To guarantee the service quality of such applications, the call set-up protocol should be robust against network impairments. In this paper, we analyze the performance of the H.323 call set-up procedure over wireless links using a simple call model under two modes of operations, namely, Regular and Fast Connect. The proposed model assumes the presence of a radio link protocol (RLP) and recommends that the VoIP packets be transferred without any RLP retransmissions, while H.323 control packets be transferred with RLP retransmissions. Our analytical models and detailed experiments show that the VoIP call set-up performance can undergo significant degradation if RLP is not used at all, even for moderately high frame error rates (FERs) in wireless links. On the other hand, a robust radio link layer, such as RLP, can improve the call-set-up delay performance as compared to the existing wireless voice call-set-up delay.
Index Terms—Wireless network, H.323 protocol, link-level QoS, radio link protocol (RLP), performance study.
æ
1
I
NTRODUCTIONT
HE success of wireless voice services has createdopportunities for multimedia data and entertainment services, leading to a ubiquitous information environment for the future. The potential for wireless data services has also been demonstrated recently through the tremendous success of the I-Mode [1] services in Japan. More and more users are getting accustomed to the concept of wireless appliances that can provide many attractive services by integrating contents, voice, and text communications. Alongside this development, the core global information networks are becoming a reality that converge multimedia (audio, video, and text) services on a single seamless network infrastructure. Such convergence will not only reduce the network complexity and infrastructure equip-ment, but will also be easy to maintain. The switching and routing technologies of the core networks are evolving toward packet-based transmission such as IP (Internet Protocol), ATM (Asynchronous Transfer Mode), Frame Relay, and optical routing. This migration has created the opportunity for integrating the voice and data traffic on the same wireless and IP network infrastructure.
Although the evolution of the core network to IP is enabling the migration of the traditional circuit-switched voice and call signaling message traffic over the Internet
using the voice over IP (VoIP) technology, there are many technical issues and challenges that need to be resolved for its successful commercial deployment. Before proceeding further, let us first analyze the benefits offered by such a unified end-to-end IP network solution.
. Cost Reduction: The convergence of both voice and
data traffic can improve network efficiency and reduce operation costs.
. Simplification: An integrated infrastructure that sup-ports all forms of communication, allows more standardization, and, thus, provides convergence of different functionalities on the same platform.
. Consolidation: Since users are among the most
significant cost elements in a network, any opportu-nity to combine operations, to eliminate points of failure, and to consolidate accounting systems would be beneficial.
. Advanced Applications: Even though telephony is the basic application for voice over all IP networks, the long-term benefits are expected to be derived from multimedia and multiservice applications. For ex-ample, e-commerce solutions can combine WWW access to information repository with a voice call button that allows an immediate access to a call center agent from personal computers.
Currently, the voice and data traffic are treated sepa-rately by the GSM (Global Special Mobile) and GPRS (General Packet Radio Service) wireless access technologies. The Release.1 definition of 3rd Generation (3G) systems also kept this separation in the following sense: The wireless voice traffic is routed through the circuit-switched cellular infrastructure, whereas data traffic is routed through the packet-switched (e.g., GPRS) network. Although wireless and Internet technologies perform quite well within their own domains, the integration of wireless links into the . S.K. Das and K. Basu are with the Center for Research in Wireless Mobility
and Networking (CReWMaN), Department of Computer Science, Uni-versity of Texas at Arlington, Arlington, TX 76019-0015.
E-mail: {das, basu}@cse.uta.edu.
. E. Lee is with the Department of Mathematics and Computer Science, University of North Carolina, Pembroke, NC 28372.
E-mail: [email protected].
. S.K. Sen is with Siemens Information Systems, Gurgaon, Haryana 122 015, India. E-mail: [email protected].
Manuscript received 13 Oct. 2001; revised 10 Oct. 2002; accepted 30 Oct. 2002.
For information on obtaining reprints of this article, please send e-mail to: [email protected], and reference IEEECS Log Number 117663.
Internet exhibits considerable challenges. Unpredictability in the air-link conditions, such as rapid fading, shadowing, and intermittent disconnections, affect the radio link such that the frame error rate (FER) can be as high as 10ÿ1. This causes serious quality degradation to the end users because the packet traffic is very sensitive to the bit error rate (BER). To overcome the higher BER problem, the wireless air interface protocol standards included the definition of a new protocol layer, called the Radio Link Protocol (RLP), on top of the MAC (medium access control) layer. The RLP layer provides higher reliability of the air link by using the ARQ (Automatic Repeat request) protocol in conjunction with the cyclic redundancy check (CRC). Thus, the wireless air interface is made to interwork with IP networks to support useful data services.
To converge the voice and data networks, the signaling for VoIP should also be able to gracefully migrate into the existing infrastructure. Existing GSM voice network and terminals use SS7 (signaling system 7) and ISDN (Integrated Signaling Digital Network) protocols. The International Telecommunications Union (ITU) has defined H.323 [5] as the key protocol that implements this migration to today’s PSTN (public switched telephone network) signaling domain. To overcome some limitations of H.323, additional new protocols have been proposed recently to implement VoIP services through gateway decomposition. They in-clude SIP or Session Initiation Protocol [4], MGCP or Media Gateway Control Protocol [2], and H.248 [3], which are beyond the scope of our study. It is worth pointing out that SIP, as defined by the Internet Engineering Task Force (IETF), is a signaling protocol for telephone calls over the IP. Unlike H.323, SIP is specifically defined for the Internet and also includes mobility management function. It exploits the manageability of IP and makes the telephony application development relatively simple. It is basically used for the setting up, controlling, and tearing down sessions in the Internet that include telephone calls and multimedia conferences. SIP supports various facets of telecommunica-tion such as user locatelecommunica-tion, user capabilities, user availability, call setup, and call Handling. In our view, for the foresee-able future, multiple VoIP protocols will exist and inter-work among themselves. (For internetinter-working between SIP and H.323, refer to [15].) For our study in this paper, we have considered H.323 as the protocol of choice for
implementing VoIP services. However, the proposed analysis is quite general in nature and can be easily extended to SIP or other protocols.
In this paper, we investigate the impact of link errors on the performance of VoIP call set-up in wireless networks. In particular, we estimate the average call set-up delay for various link error conditions. The proposed model and analysis uses the simple Direct Routing Call Model of H.323 protocol, as shown in Figs. 1 and 2, although it has the flexibility to be extended easily to other types of call models such as Gatekeeper routed call signaling as proposed in the H.323 standard. By analytical models, we show that the VoIP call set-up performance can degrade significantly even for moderately high air-link FERs if there is no protection on the air link for FER. Therefore, we recommend that the H.323 call signaling messages be treated as data packet, instead of treating them in the same way as the current voice packets in the air link. We also show that the call set-up performance can be improved significantly using a robust radio link layer such as the RLP. Detailed laboratory experiments validate the analysis proposed. A preliminary version of this paper appeared in [16].
The rest of the paper is organized as follows: Section 2 gives an overview of H.323 protocol. Section 3 presents the mathematical model to estimate the performance of H.323 and RTCP (real-time transport control protocol) signaling over wireless. In Section 4, the call set-up delay for the Fast Connect procedure is compared with the regular call set-up procedure. Section 5 describes the experimental results conducted with Microsoft NetMeeting to validate our model. Section 6 presents the idea of a classifier to separate media streams and control messages, while Section 7 concludes the paper with directions for future research works.
Fig. 1. H.225 Call signaling message flow.
2
O
VERVIEW OFH.323 P
ROTOCOLThis section presents a brief introduction to the H.323 [5] and RTP/RTCP [6] protocols. The H.323 standard provides a foundation for audio, video, and data communications across IP-based networks. It is the umbrella recommenda-tion from the ITU that sets standards for multimedia communications over LANs. The implementation of the H.323 standard does not provide guaranteed quality of service (QoS); it is broad in scope and supports both stand-alone devices and embedded personal computer technol-ogy, as well as point-to-point and point-to-multipoint conferences. It also addresses call control, multimedia management, bandwidth management, and interfaces between LANs and other networks like PSTN. The H.323 protocol uses the concept of channels to structure the information exchange between communication entities. A channel is a transport layer connection, which can be either unidirectional or bidirectional. The call set-up-delay is very large in H.323 for a Regular call set-up which involves multiple messages from each of the H.225 [7] and H.245 [8] protocols (see Figs. 1 and 2). This delay is rather prominent for a low bandwidth connection, especially in a high loss environment such as wireless link connections. The Fast Connect call set-up method is an option specified in H.323 that reduces the delay involved in establishing a call and initial media streams.
The Real-time Transport Protocol (RTP) used in conjunc-tion with H.323 provides end-to-end delivery services for data with real-time characteristics, such as interactive audio and video, over a connectionless network [6] with the ability to carry timing information. The protocol RTP/ RTCP, along with UDP (unified datagram protocol) has the capability to provide bare-bones real-time services with minimum reliability. A typical H.323 network, shown in Fig. 3, consists of a number of zones interconnected by a wide area network (WAN). The H.323 protocol defines four major components for a network-based communications system: terminals, gateways, gatekeepers, and multipoint control units (MCUs). The terminals are the client end-points that provide real-time, two-way communications. All H.323 terminals must also support the H.245 protocol, which is used to negotiate channel usage and capabilities. Three other components are required: 1) H.225 for call signaling and call set-up, 2) a component called Registra-tion/Admission/Status (RAS) protocol used to communi-cate with a gatekeeper, and 3) support of RTP/RTCP for
sequencing audio and video packets. The protocol suite is shown in Fig. 4.
A typical H.323 call set-up is a three-step process [5] which involves call signaling, establishing communication channel for signaling, and establishing media channels. In the first phase of call signaling, the H.323 client requests permission from the (optional) gatekeeper to communicate with the network. Once the call is admitted, the rest of the call signaling will proceed according to one of the several call models, as described in [5]. In this paper, we have chosen the Direct Routing Call Model. Figs. 1 and 2 describe the message flows in H.225 and H.245, respectively.
In the Direct Routing Call Model scenario, the two endpoints communicate directly instead of registering with a gatekeeper. Endpoint 1 (the calling endpoint) sends the H.225 Setup (1) message to the well-known Call Signaling Channel Transport Identifier of Endpoint 2 (the called endpoint) who responds with the H.225 Connect (4) message which contains an H.245 Control Channel Trans-port Address for use in H.245 signaling. The H.225 Call Proceeding (2) message is optional.
Once the H.245 Control Channel (unidirectional) has been established, the procedures of Recommendation H.245 are used for capability exchange and to open media channels. The first H.245 message to be sent in either direction is TerminalCapabilitySet (5, 7) which is acknowl-edged by the TerminalCapabilitySetAck (6, 8) message. There can be an optional MasterSlaveDetermination proce-dure invoked at this stage to resolve the conflict, for example, between the two endpoints trying to open a bidirectional channel. The procedures of H.245 are then used to open logical channels for the various information streams (9, 11). The OpenLogicalChannelAck (10, 12) message returns the transport address that the receiving end has assigned to the logical channel. Both the H.225 and H.245 messages are transmitted over a reliable transport layer. Two different TCP sessions are established for H.225 and H.245 procedures.
After the media channel has been set up, the RTCP CNAME (canonical name) [6] is exchanged so that multiple media streams (e.g., audio and video) to the same user can Fig. 3. H.323 system components.
be synchronized. This works reasonably well for wire line networks having a frame error rate (FER) less than 10ÿ8. However, significant performance degradation to the end users may occur in wireless networks in which the FER can be as high as 10ÿ1.
3
P
ERFORMANCEA
NALYSIS OFH.323 S
IGNALINGOVER
W
IRELESSWe will assume the simple call set-up message flows of H.323 as depicted in Figs. 1 and 2. The total call set-up delay will be the cumulative delay due to:
1. set-up time for two TCP sessions (exchange of SYN, SYN-ACK, ACK messages);
2. successfully transmitting all the H.225 and H.245
messages;
3. successfully receiving an RTCP CNAME message.
First, we present the analysis of RTCP packets based on mathematical models similar to those suggested in [9], [10] for CDMA networks. Next, we analyze the H.323 call set-up flows and their interactions with TCP.
Some information in an RTCP packet is more important than others (e.g., CNAME and BYE). They are critical and need to be reliably transmitted to guarantee user perceived quality of service (QoS) and also, to a certain extent, the network performance. On the other hand, end-to-end retransmission is not recommended for real-time applica-tions like voice packets to avoid delay variance. Local (and controlled) retransmission mechanisms at the wireless link, however, seems feasible, at least for RTCP packets. A semireliable link layer retransmission mechanism like Radio Link Protocol (RLP) is used to reduce the air link FER and, hence, increase reliability. Performance will be compared between models with and without the RLP.
When RLP at the receiving end finds a frame in error (or missing), it sends back a NAK requesting retransmission of this frame and starts a retransmission timer. When the timer expires for the first attempt, RLP resets the timer and sends back NAK twice, each of which triggers a retransmission of the requested frame. In this way, the number of attempts per retransmission increases by one with every retransmis-sion trial. As noted in [9], the number of trials ðnÞ is usually less than four. Hereafter, in our analysis, we assume n ¼ 3. We restrict the maximum retransmission time for a packet to be much less than the RTCP transmission interval (T ). An overdue RTCP packet is useless since a new one will be generated and transmitted at a certain period of time.
3.1 Analysis of RTCP CNAME Packet Delay
Let p be the probability of a frame being in error in the air link as obtained from the FER. Let K be the number of frames per RTCP packet transmitted over air and let T 5 sec be the RTCP transmission interval. Let D (of the order of 100 msec) and (of the order of 20 msec) be, respectively, the end-to-end frame propagation delay over the radio channel and the interframe time of RLP. Thus, the packet loss rate without the RLP is
q¼ 1 ÿ ð1 ÿ pÞK ð1Þ
and, with the RLP, is
q¼ 1 ÿ ð1 ÿ pðpð2 ÿ pÞÞ6ÞK: ð2Þ
This parameter will be used in the appropriate context of our analysis without notational ambiguity.
3.1.1 Without Any Link Layer Reliability Mechanism Assume a user just joined the RTP session. The average delay for receiving this CNAME packet indicates the waiting period for this user to be able to play the associated RTP streams properly. This is given as
T1¼ D þ ðK ÿ 1Þ þ T 2 ð1 ÿ qÞ þ T þT 2 qð1 ÿ qÞ þ 2T þT 2 q2ð1 ÿ qÞ þ . . . ¼ T 1þ q 2ð1 ÿ qÞ þ D þ ðK ÿ 1Þ ¼ T 2ÿ ð1 ÿ pÞ K 2ð1 ÿ pÞK " # þ D þ ðK ÿ 1Þ : ð3Þ
3.1.2 With a Semireliable Link Layer Mechanism (RLP) For this analysis, let us define the following terms:
. Xij¼ ith retransmission frame at the jth retransmis-sion trial received correctly at the destination. . Yij¼ ith NAK frame at the jth retransmission trial
received correctly at the source.
. Cij¼ the first frame received correctly at the
destination, being the ith retransmission frame at the jth retransmission trial.
. Aj¼ the missing frame not received correctly at the jthretransmission trial.
. Bj¼ the missing frame not received correctly up to the end of the jth retransmission trial.
Assume P ðXijÞ ¼ P ðYijÞ ¼ 1 ÿ p, where p is the prob-ability of a frame being in error in the air link. Therefore, if a frame is not received correctly at the jth retransmission trial, then
PðAjÞ ¼ Yi¼j i¼1
ð1 ÿ P ðXijÞP ðYijÞÞ ¼ ðð2 ÿ pÞpÞj: ð4Þ
Note that the probability that the frame is aborted after the nth retransmission trial is equivalent to the probability that the frame is not received correctly up to the end of the nthretransmission trial. This implies
PðBnÞ ¼ p Yn j¼1 PðAjÞ ¼ pðpð2 ÿ pÞÞ nðnþ1Þ 2 : ð5Þ
Thus, PðCijÞ ¼ P ðBjÿ1ÞP ðXijÞP ðYijÞ Yjÿ1 k¼1 ð1 ÿ P ðXkjÞP ðYkjÞÞ ¼ pð1 ÿ pÞ2ðð2 ÿ pÞpÞjðjÿ1Þ2 þiÿ1: ð6Þ
Therefore, the probability of transmitting a frame success-fully over the RLC (radio link control) layer is given by
Pf¼ 1 ÿ P ðBnÞ ¼ 1 ÿ pðpð2 ÿ pÞÞ
nðnþ1Þ
2 : ð7Þ
Then, the probability of a packet loss is given by q¼ 1 ÿ PK
f , where K is the number of RLP frames in the
RTCP packet. Since retransmission is performed, the effective transport delay per frame increases from D to D0, where D0¼ 1 Pf Dð1 ÿ pÞ þX n j¼1 Xj i¼1 PðCijÞðð2j þ 1ÞD " þ jðj þ 1Þ 2 þ i Þ : ð8Þ
The ratio of the RTCP bandwidth usage when RLP is used to that without RLP is given as
1 Pf ð1 ÿ pÞ þX n j¼1 Xj i¼1 PðCijÞðjðj ÿ 1Þ þ 2i ÿ 1Þ " # : ð9Þ
The delay experienced by an RTCP packet provided that RLP is used, is estimated as D00¼ 1 PK f XK l¼0 K l ð1 ÿ pÞKÿl X n j¼1 Xj i¼1 PðCijÞ !l 8 < : ðD þ ðK ÿ 1Þ Þ þ l Pf Xn j¼1 Xj i¼1 PðCijÞ " 2jD þ jðj þ 1Þ 2 þ i ¼ D þ ðK ÿ 1Þ þKðPfÿ ð1 ÿ pÞÞ P2 f Xn j¼1 Xj i¼1 PðCijÞ 2jD þ jðj þ 1Þ 2 þ i ! : ð10Þ
If RLP is used, the average delay for a newly joined member to receive the RTCP packet containing the CNAME item can be approximated by
T2¼ D00þ T 2ð1 ÿ qÞ þ T þ T 2 qð1 ÿ qÞ þ 2T þT 2 q2ð1 ÿ qÞ þ . . . ¼ T 1þ q 2ð1 ÿ qÞ þ D00¼ T 2ÿ P K f 2PK f " # þ D00: ð11Þ
3.2 H.323 Call Set-Up Message Delay Analysis
Since TCP Handshake H.225 and H.245 messages are carried over TCP, an analysis of TCP transport delay over wireless will lead to an insight into the performance of H.323 call set-up delay. For this purpose, we have assumed a fixed radio channel bandwidth of 9.6 Kbps. The two endpoints are assumed to be in close proximity, hence, any wire line network delay is assumed to be negligible. The following assumptions are made about the end-to-end TCP sessions carrying the H.323 messages:
1. TCP is assumed to operate in an interactive mode
(this is valid since most of the transactions consist of a single message and its acknowledgment).
2. The delayed acknowledgment mode of TCP
opera-tion is turned off. This implies that every TCP data packet will be acknowledged.
3. TCP always times outs whenever a packet is lost
(i.e., it never does fast retransmit). This is valid due to the interactive nature of the transactions where an endpoint after transmitting an H.323 message (e.g., TerminalCapabilitySet) typically waits for its acknowledgment (e.g., TerminalCapabilitySetAck) before transmitting the next H.323 message.
4. The one way delay for the message path is assumed
to be D 100 msec. Hence, the round trip delay is about 200 msec.
5. The initial TCP round-trip timer (RTO) value is
assumed to be exactly equal to the round-trip delay. Subsequent variation of RTO is as specified for TCP in [8].
6. The TCP packet sizes for each H.323 message are
obtained from the actual H.225 and H.245 packets captured using a protocol analyzer.
7. Assume, for simplicity, that if initial capability exchange or master-slave determination procedures fail, no retry should be issued, as opposed to the standard that suggests at least two additional retransmissions before the endpoint abandons the connection attempt.
Following Karn’s algorithm for TCP timer back-off, the RT O is multiplied by a constant factor after each retrans-mission due to time-out. Hence,
RT Oiþ1¼ c RT Oi;
where RT Oi is the ith TCP retransmission timer. This
causes RT O to grow exponentially after each retransmis-sion. We let c ¼ 2 as it is most commonly implemented. Initially, RT O ¼ 100 msec, as assumed previously. Hence, RT O1¼ 2 100 msec, ..., RT Oi¼ 2i 100 msec. Further-more, TCP will not allow an infinite number of retransmis-sions. Hence, if the TCP retransmission succeeds, say after
Nm attempts (without loss of generality, we assume
Nm¼ 10), the average delay to transmit a TCP packet is: Tþ RT O1þ RT O2þ . . . þ RT Om
¼ T þ ð2Nmþ1ÿ 2Þ 100; ð12Þ
where T is the end-to-end propagation delay of the TCP packet. We shall first derive the average delay for successful transmission of a TCP packet both with and without the
radio link reliable transmission scheme (RLP). We will then compare the average total call set-up delay for H.323 with and without RLP. For the purpose of our analysis, we stipulate in the following that the packet loss rate is q < 0:5. Indeed, if the packet loss rate is as high as 50 percent, wireless application users may not be able to enjoy any proper services over the air link. Recall that D ( 100 msec) and ( 20 msec) are, respectively, the end-to-end frame propagation delay over the radio channel and the inter-frame time.
3.2.1 Average TCP Packet Transmission Delay without RLP
The TCP packet loss rate is q ¼ 1 ÿ ð1 ÿ pÞK, where p is the probability of a frame being in error in the air link and K is the number of air-link frames contained in a TCP segment. The probability of successfully transmitting a TCP segment is ð1 ÿ qÞ þ ð1 ÿ qÞq þ . . . þ ð1 ÿ qÞqNmÿ1¼ 1 ÿ qNm. Using
(12), we obtain the average (normalized) delay for
success-fully transmitting a TCP segment with no more than Nm
retransmission trials as T N ¼ 1 1ÿ qNm½ð1 ÿ qÞðD þ ðK ÿ 1Þ Þ þ ð1 ÿ qÞqð3D þ ðK ÿ 1Þ Þ þ . . . þ ð1 ÿ qÞqNmÿ1ðð2Nmÿ 1ÞD þ ðK ÿ 1Þ Þ ¼ ðK ÿ 1Þ þ 1ÿ q 1ÿ qNmD 1þ 4q 1ÿ 2qÿ q 1ÿ q þ 1ÿ q 1ÿ qNmD qNm 1ÿ qÿ 2Nmþ1qNm 1ÿ 2q ¼ ðK ÿ 1Þ þ D ð1 ÿ qNmÞð1 ÿ 2qÞ þ 1ÿ q 1ÿ qNmD qNm 1ÿ qÿ 2Nmþ1qNm 1ÿ 2q : ð13Þ
The TCP packets are going to carry the H.323 control messages in the payload. Hence, the total call set-up delay is the cumulative addition of the delays for transmitting all the TCP call set-up messages (TCP synchronization as well as H.323 TCP control messages) and the RTCP:CNAME packet.
The total delay without RLP is given as TnoRLP ¼
XN i¼1
T Niþ T C; ð14Þ
where T Ni is the average delay given by (13) for the ith TCP segment (carrying one of the TCP messages in the payload) and T C is the average delay to receive the first RTCP:CNAME packet after joining the session. Here, N is the total number of TCP messages used in the call set-up function. Notice that this equation assumes message processing time at the terminals is negligible. In reality, a finite amount of time will be spent at the terminals to process the TCP message and send the response back. The cumulative delay of this processing can be from a few tens to hundreds of milliseconds and will depend upon the processing speed of the terminal and the scheduler.
3.2.2 Average TCP Packet Transmission Delay with RLP
We first evaluate the average delay to transmit a TCP segment (all K frames) successfully given that the radio link layer guarantees the transmission of each frame. This is given as D00¼ 1 PK f XK l¼0 K l ð1 ÿ pÞKÿl X n j¼1 Xj i¼1 PðCijÞ !l 8 < : ðD þ ðK ÿ 1Þ Þ þ l Pf Xn j¼1 Xj i¼1 PðCijÞ " 2jD þ jðj þ 1Þ 2 þ i ¼ D þ ðK ÿ 1Þ þKðPfÿ ð1 ÿ pÞÞ P2 f X n j¼1 Xj i¼1 PðCijÞ 2jD þ jðj þ 1Þ 2 þ i ! ; ð15Þ where n ¼ 3 is the maximum number of RLP retransmis-sion trials and
Pf¼ 1 ÿ p þ Xn j¼1 Xj i¼1 PðCijÞ ¼ 1 ÿ pðpð2 ÿ pÞÞ nðnþ1Þ 2 ; ð16Þ
as shown in Section 3.1. Recall also that the packet loss rate is given by q ¼ 1 ÿ PK
f . Thus, the average delay to transmit a TCP segment successfully is given by:
T R¼ 1 1ÿ qNm½ð1 ÿ qÞD 00þ ð1 ÿ qÞqð2D þ D0Þ þ . . . þ ð1 ÿ qÞqNmÿ1ðð2Nmÿ 2ÞD þ D00Þ ¼ D00þ2Dqð1 ÿ qÞ 1ÿ qNm 1þ 4qð1 ÿ ð2qÞNmÿ2Þ 1ÿ 2q " ÿqð1 ÿ q Nmÿ2Þ 1ÿ q : ð17Þ
When the air-link FER is very high, it is possible that too much of the RLP retransmissions will cause enough delay that the TCP’s retransmission timer always times out. In those cases, the situation degenerates to the case described in Section 3.1.1. Thus, the average call set-up delay with RLP is given by
TRLP ¼ XN
i¼1
Tiþ T C; where Ti¼ minfT Ri; T Nig; ð18Þ where T Riis the average delay given by (17) for the ith TCP segment (carrying one of the TCP messages in the payload) with RLP and T C is the average delay to receive the first RTCP:CNAME packet after joining the session. Also recall that N is the total number of TCP messages used in the call set-up function.
4
A
VERAGEH.323 C
ALLS
ET-U
PD
ELAYLet us now compute the average call set-up delay for a regular H.323 procedure (as described in Section 2) and a Fast Connect procedure as described in [5] (see the Appendix for an introduction). The model presented in the previous section implicitly implies that an average Regular H.323 call set-up delay increases exponentially as the FER increases. Three major factors contribute to this delay—the number of message exchanges, the size of message exchanges, and the number of TCP sessions set-up. Reduction of any of these factors will result in shorter call set-up delay for an H.323 call. The Recommendation for H.323 provides ways for addressing this or similar issues. This includes encapsulation of H.245 messages within H.225 messages, called Tunneling, and the Fast Connect procedure. In order to conserve resources, either or both of the mechanisms invoked by the H.323 calling endpoint synchronize call signaling and control and reduce call set-up time. In this section, we investigate the call set-set-up delay incurred by the Fast Connect procedure only. See the Appendix for a brief introduction to the Fast Connect procedure.
H.323 endpoints may establish media channels in a call using either the Regular procedure defined in Recommen-dation H.245 (see Section 2) or the so-called Fast Connect procedure. The Fast Connect procedure allows the end-points to establish a basic point-to-point call with as few as one round-trip message exchange, thus enabling immediate media stream delivery upon call connection.
4.1 Fast Connect Procedure
As the number and size of TCP messages (H.225 signaling) increases, the cumulative transmission time for those messages also increases. Therefore, the size and the number of TCP packets affect the call set-up time. As an example, Table 1 shows the size1 of the H.225 signaling for Fast Connect procedures. We assume a TCP segment is carried in one IP packet and frames imply air-link frames. Each of TCP and IP headers’ sizes are assumed as 20 octets (or “oct” for short). For the Setup + fastStart message, we assume three openLogicalChannel structures included; whereas, in the Connet + fastStart case, one openLogicalChannel is chosen for media exchanges by the called endpoint.
4.2 Regular Procedure
Based on the H.323 call model, the overall delay for call set-up is computed and shown below. As the number and size of TCP messages (TCP hand shake, signaling, and control messages) increases, the cumulative transmission time for these messages increases correspondingly. Therefore, the size and the number of the TCP packets affect the call set-up time. For example, RTCP SDES:CNAME packet is needed for synchronization purpose. Data in Table 2 shows the size of the signaling and control messages as an example. For brevity, TCSet denotes “Terminal CapabilitySet” and OC denotes “OpenlogicalChannel.” Again, the notation “oct” in the table means octets.
Figs. 5 and 6 compare the average call set-up delays associated with a Regular connect procedure and a Fast Connect procedure for 9.6 Kbps and 19.2 Kbps channels, respectively. Each procedure is further evaluated with and without support from RLP over the error-prone wireless channel. It can be observed that Fast Connect with RLP support provides the minimum call set-up delay. Further-more, the call set-up delay for the Fast Connect procedure is consistently below 5 seconds and 4 seconds for 9.6 Kbps and 19.2 Kbps channels, respectively, if FER is less than 9 percent. This is much faster than the corresponding
1. The analysis includes the TCP set-up messages, SYN, SYN-ACK, ACK, although they are not shown in Table 1.
TABLE 1
Message Sizes Associated with the H.225 Fast Connect Procedure
TABLE 2
Message Sizes Associated with the Regular Call Set-Up Procedure
Regular call set-up procedure that was close to a minute for 9.6 Kbps air link.
5
E
XPERIMENTALV
ERIFICATIONExperiments for call set-up delay at various FER rates between 1-10 percent over the Wireless Link Emulator (WLE) were conducted using Microsoft NetMeeting. An end-to-end Microsoft NetMeeting VoIP session from End-point A (Caller) to EndEnd-point B (Callee) over the WLE was created in the Lab. NetMeeting 3.01 uses the H.323v2 call signaling (Q.931/H.225/H.245 over TCP) to set up VoIP session and the default Microsoft codec G.723.1, 8 KHz Mono, 6400 bps for audio compression. In these experi-ments, the call is considered successful only when the voice path is cut through (i.e., Endpoint B can hear the caller’s voice). In addition, the maximum amount of time the called
party waited for voice cut-through is 2 minutes, after which the call was marked as unsuccessful.
Two sets of experiments were conducted, one with the channel bandwidth fixed at 9.6 Kbps and the others at 19.2 Kbps. Thirty delay samples were collected at each FER with RLP and without RLP. Then, the sample mean was computed (see Figs. 7 and 8). The wireless link was simulated in the Lab using Smart-bit to adjust the bit error rate of the link. The success rate at each FER is shown in Table 3. The experimental results for 9.6 Kbps channel without RLP was not collected for the complete range of the FER as such a curve is partial in Fig. 7.
With RLP turned on, the results of the call setup success for both 9.6 Kbps and 19.2 Kbps are perfect, at 100 percent success. With RLP turned off, at 1 percemt air-link FER for 9.6 Kbps and 1-2 percent air-link FER for 19.2 Kbps, the call setup success rate is 100 percent. However, as the air-link FER rate increases, the average call setup delay increases (Figs. 7 and 8) and the success rate declined (Table 3).
A fast call set-up time is considered a significant step toward providing QoS (Quality of Service). Previous sections demonstrated that it is advantageous to transmit H.323 call set-up messages and RTCP packets over air link with RLP, especially in the case of using VoIP client that Fig. 6. Call set-up delay in a 19.2 Kbps channel.
Fig. 7. Comparison of NetMeeting and Theoretical model Call Set-up delay versus FER over 9.6 Kbps radio channel.
Fig. 8. Comparison of NetMeeting and Theoretical model Call Set-up delay versus FER over 19.2 Kbps radio channel.
TABLE 3
requires exchanges of several signaling and control mes-sages before connection. For instance, the call set-up procedure for H.323 involves exchanges of H.225 and H.245 messages. As a consequence, the total delay to replay media is the sum of the delays experienced by each of these messages. Hence, the usage of RLP, with either the Regular or Fast Connect call set-up procedure, enhances services without sacrificing a great deal of the limited bandwidth. The difference between the theoretical model and the experimental set-up is explained by the additional delay (in the experimental results) of Microsoft’s NetMeeting processing of the message at the Terminal. As mentioned in Section 3.2.1, this delay component is not included in the Theoretical analysis.
6
H.323 S
UBFLOWC
LASSIFICATION FORV
OIP
So far, we have demonstrated that the performance of the H.323 protocol to set up a multimedia call can be poor even under moderately high air-link FERs. This is primarily due to the poor performance of TCP under high FER without the support of a local retransmission mechanism over the wireless link, such as the RLP or radio link protocol. It is established by our analysis that the call set-up delay performance will not meet the grade of service requirements of the wireless voice call without RLP retransmission. On the other hand, the voice media packets can handle higher FER, but are adversely affected by the jitters caused by such retransmission. Hence, there is a need to treat the H.323 media streams for interactive traffic (particularly, VoIP) differently from the H.323 control packet streams (e.g., H.225, H.245, RTCP messages). It is recommended thattransparent RLP (i.e., without RLP retransmissions) be used for VoIP packets while nontransparent RLP (i.e., with RLP retransmissions) be used for H.323 control packets. Also, due to the interactive nature of voice, VoIP packets should get higher priority over any in-band H.323 control packets within the session. Two types of subflows requiring differentiation have been identified for VoIP service using H.323. These are:
. H.323 control packets, including H.225, H.323, and
RTCP, which need higher reliability for better performance but have less stringent delay requirements compared to the media packets.
. H.323 media packets carried by RTP which have
lower reliability requirements than the control packets, but stringent delay requirements.
This subflow characterization is graphically depicted in Fig. 9.
7
C
ONCLUSIONIn this paper, we explained the implementation of VoIP services in wireless networks using H.323 protocol. We discussed the voice quality issues with reference to RLP and how bypassing RLP can help improve voice quality. We proposed an implementation architecture of VoIP using H.323 protocol. The architecture recommends the use of DirectConnect with FastConnect features of H.323 to keep the call set-up delay low. We also proposed a concept of Classifier to separate the control and media packets and exclude RLP function for the media packet transmission. We have given a detailed analysis of H.323 call set-up delay with variable frame error rates and RLP retransmissions. Fig. 9. H.323 Subflow classes requiring different treatment.
An experimental NetMeeting setup was used to determine the VoIP call set-up delay under various frame error rates. The analytical results are compared with the experimental results. Our analysis of the proposed architecture of H.323 control message confirms that it may be possible to provide call-set-up delay of wireless VoIP that is comparable to current wireless voice services. Future research on VoIP includes analysis of the delay budgets of the voice packets and how to model the voice packet burst level blocking. The potential role of different Codecs, the voice packet bundling by the terminal, and the possibility of silent detection in the terminal are important research areas to make wireless VoIP services successful.
A
PPENDIXH.323 F
ASTC
ONNECTP
ROCEDUREInitiation of Fast Connect procedure.The calling endpoint initiates the Fast Connect procedure by sending a H.225
Setup message containing the fastStart element to the
called endpoint. The fastStart element consists of a sequence of H.245 OpenLogicalChannel structures (in order of preference), each describing a media channel to which the calling endpoint proposes to send and receive, including all the parameters necessary to immediately open and begin transferring media on the channels.
Refusal of Fast Connect procedure.The called endpoint may refuse to use the Fast Connect procedure, either because it does not implement it or because it intends to invoke features that require the use of the procedures defined in Recommendation H.245.
Acceptance of Fast Connect Procedure. When the
called endpoint desires to proceed with the Fast Connect procedure, it sends an H.225 message (CallProceeding, Alerting, Progress, or Connect) containing a fastStart element selecting from among the openLogicalChannel proposals offered by the calling endpoint. Channels
accepted are considered opened as the usual H.245
openLogicalChanneland openLogicalChannelAck
proce-dure has been followed.
Media transmission. The called endpoint may begin
transmitting media (according to the channels opened) immediately after sending an H.225 message containing the fastStart element. The calling endpoint must therefore be prepared to receive media on any of the receive channels it proposed in the H.225 Setup message since it is possible for the media to be received prior to the H.225 message indicating precisely which channels are to be used. Once an H.225 message containing the fastStart element is received by the calling endpoint, it may discontinue attempting to receive media on the channels for which proposals were not accepted by the called endpoint. The calling endpoint may begin transmitting media (according to the channels opened) immediately upon receiving an H.225 message containing the fastStart element. Therefore, the called endpoint must be prepared to receive media on the channels it accepted in the H.225 message containing the fastStartelement.
Switching to H.245 procedures.After establishing a call using the Fast Connect procedure, either endpoint may initiate the use of H.245 procedures at any time during the call, using tunneling or a separate H.245 connection.
Terminating a call. If a call connect using the Fast Connect procedure continues to completion without initia-tion of the H.245 procedure, the call may be terminated by either endpoint sending an H.225 Release Complete message. We assume the simple direct call set-up message flows as described in Fig. 10. The TCP level interactions for exchanging the H.225 messages is shown in Fig. 11. The Fig. 10. H.225 Fast Connect Call Signaling.
associated message sizes are given in Table 1. The total call set-up delay will be the cumulative delay for 1) set-up time for the TCP session (exchange of SYN, SYN-ACK, ACK messages), 2) successfully transmitting all the H.225 messages shown in Figs. 1 and 3) successfully receiving an RTCP CNAME message.
Assume that, in this Fast Connect procedure, the calling endpoint advertises three different media channels and one codec in each openLogicalChannel structure in the fastStart element of the Setup message. Furthermore, the corresponding response to fastStart is done in Connect message without loss of generality.
A
CKNOWLEDGMENTSThe authors are grateful to the anonymous referees and the guest editors for their helpful comments which improved the quality of the manuscript. This work was started while E. Lee, K. Basu, and S.K. Sen were with Nortel Networks in Richardson, Texas.
R
EFERENCES[1] K. Knoki, “i-Mode: The Mobile Internet Service of the 21st Century,” IEEE Int’l Solid-State Circuits Conf. (ISSCC), Digest of Technical Papers, pp. 12-15, 2001.
[2] N. Greene, M.A. Ramalho, and B. Rosen, “Media Gateway Control Protocol Architecture and Requirements,” RFC 2805, Apr. 2000. [3] Int’l Telecomm. Union, “Gateway Control Protocol?;
Recommen-dation H. 248, Telecom Standardization Sector of ITU,” June 2000. [4] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, “SIP: Session Initiation Protocol,” Request for Comments (Proposed Standard) 2543, Internet Eng. Task Force, Mar. 1999.
[5] Int’l Telecomm. Union, “Packet Based Multimedia Communica-tions Systems,” Recommendation H.323, Telecomm. Standardiza-tion Sector of ITU, Geneva, Switzerland, Feb. 1998.
[6] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” Request for Comments (Proposed Standard) 1889, Internet Eng. Task Force, Jan. 1996.
[7] Int’l Telecomm. Union, “Media Stream Packetization and Syn-chronization on Non-Guaranteed Quality of Service LANs,” Recommendation H.225.0, Telecomm. Standardization Sector of ITU, Geneva, Switzerland, Nov. 1996.
[8] Int’l Telecomm. Union, “Control Protocol for Multimedia Com-munication,” Recommendation H.245, Telecomm. Standardiza-tion Sector of ITU, Geneva, Switzerland, Feb. 1998.
[9] G. Bao, “Performance Evaluation of TCP/RLP Protocol Stack over CDMA Wireless Link,” Wireless Networks, vol. 3, no. 2, pp. 229-237, 1996.
[10] S.K. Sen, J. Jawanda, K. Basu, N.K. Kakani, and S.K. Das, “A Call Admission Control Scheme for TCP/IP Based CDMA Voice/Data Network,” Proc. ACM/IEEE Int’l Conf. Mobile Computing and Networking, pp. 276-283, Oct. 1998.
[11] J. Postel, “Transmission Control Protocol,” Request for Comments 793, Internet Eng. Task Force, Sept. 1981.
[12] L. Westberg and M. Lindqvist, “Realtime Traffic over Cellular Access Networks,” IETF draft-westberg-realtime-cellular-01.txt, Oct. 1999.
[13] S.A. Thomas, IPng and the TCP/IP Protocol. New York: Wiley Computer Publishing, 1996.
[14] D. Minoli and E. Minoli, Delivering Voice over IP Networks. New York: Wiley Computer Publishing, 1998.
[15] K. Singh and H. Schulzrinne, “Interworking Between SIP/SDP and H.323,” IETF draft-singh-sip-h323-00.txt, Jan. 2000.
[16] S.K. Das, K. Basu, E. Lee, and S.K. Sen, “Performance Optimiza-tion of VoIP Calls over Wireless Links Using H.3233 Protocol,” Proc. IEEE Infocom, vol. 3, pp. 1386-1394, June 2002.
Sajal K. Das received the BTech degree in 1983 from Calcutta University, the MS degree in 1984 from the Indian Institute of Science, Bangalore, and the PhD degree in 1988 from the University of Central Florida, Orlando, all in computer science. Currently he is a professor of computer science and engineering and also the founding director of the Center for Research in Wireless Mobility and Networking (CReWMaN) at the University of Texas at Arlington (UTA). Prior to 1999, he was a professor of computer science at the University of North Texas (UNT), Denton, where he founded the Center for Research in Wireless Computing (CReW) in 1997 and also served as the director of the Center for Research in Parallel and Distributed Computing (CRPDC) during 1995-1997. He has visited numerous universities, research organiza-tions, government, and industry research labs worldwide for collaborative research and delivered invited talks. His current research interests include resource and mobility management in wireless networks, mobile and pervasive computing, wireless multimedia and QoS provisioning, sensor networks, mobile internet architectures and protocols, distributed processing, grid computing, performance modeling, and simulation. He has published more than 200 research papers in these areas and received Best Papers awards from several conferences, and directed numerous funded projects. He holds four US patents in wireless mobile networks and received the UTA College of Engineering 2003 Research Excellence Award. He is a member of the IEEE Computer Society.
Enoch Lee received the PhD degree in mathe-matics and the MS degree in computer science. He worked for Nortel Networks and, subse-quently, Yotta Networks after his graduation. He is currently an assistant professor in the Mathe-matics and Computer Science Department of the University of North Carolina at Pembroke. His research interests include core switching technology, wireless access networks, voice/ data/multimedia streaming traffic characteristics, and various algebraic structures.
Kalyan Basu received the BEE degree from Calcutta University, India, and the Master of Computer Technology degree from the Indian Institute of Technology, Delhi. He has been the managing director of CreWMaN Lab and a faculty member of the Computer Science and Engineer-ing Department at the University of Texas at Arlington since January 2002. He has more than 30 years of telecommunication industry experi-ence of which the last 27 years is on telecommu-nication resear ch. Since 1980, he has worked at Nortel Telecommunications Research Division.He moved to BNR, Richardson, Texas, in 1989 to set up the wireless system engineering group and became the director of Wireless System Engineering in 1995. He left Nortel in early 2001 to become the vice president of system engineering for Yotta Networks, Plano, Texas, and lead the architecture team to design the Petabit Photonic Switch. He has received multiple US / international patents and published more than 50 papers at various international/national conferences. He is a member of the IEEE Computer Society.
Sanjoy K. Sen received the PhD degree in computer science from the University of North Texas, Denton, Texas, in 1997, and the MBA degree from Southern Methodist University, Dallas, Texas in 2002. He joined the Wireless Systems Technologies Group at Nortel Net-works in 1997, where his primary research interests were IP multimedia over radio link, Quality-of-Service, and designing convergent network architectures. He is one of the pioneer-ing contributors for development of the IP Multimedia Subsystem in the current UMTS/3GPP Standards. Currently, he is a senior manager of the Telecome Strategic Business Unit at Siemens Information Systems. His current research interests include multimedia security, QoS, and value-added services (VAS) for 3G mobile and broadband networks.