An Adaptive Packet Dropping Algorithm for Improved ...

This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the ICC 2008 proceedings.

An Adaptive Packet Dropping Algorithm for Improved VoIP Quality at ADSL-subscribers Qin Dai, Le Phu Do, Samer Sulaiman, and Ralf Lehnert Chair for Telecommunications, Technische Universität Dresden Dresden, Germany {qindai, dolephu, sulaiman}@ifn.et.tu-dresden.de, [email protected] Abstract— Delay is one of the most important parameters of VoIP which can significantly impact the voice quality. When crossing an ADSL downlink, a VoIP application has to contend for the bandwidth with other applications, e.g., TCP. With the assumption that the DSLAM only has a FCFS mechanism employed in the downlink direction, the VoIP packets may suffer from serious queueing delay problem in the DSLAM buffer. This problem can be solved by introducing TCP packet dropping at the receiver. But the drop ratio should be adjusted depending on the network conditions such as network load. In this paper, an adaptive packet dropping algorithm based on the RED mechanism is proposed to guarantee the VoIP quality in ADSL downlink under different network conditions. Simulations are conducted to compare our approach with the fixed drop ratio approach considering different network traffic. The results show that our algorithm can successfully adapt to the network conditions. Moreover, compared with the fixed drop ratio one, our approach can achieve better VoIP quality with fewer TCP packet dropping. Index Terms— VoIP, QoS, packet dropping, RED

I. INTRODUCTION VoIP (Voice over IP), thanks to its lower cost and the integration with wider range of advanced services, as compared to the traditional telephone service, has been gaining more and more attention from both users and ISPs (Internet Service Providers). Unlike the traditional telephony which needs the support from its own network—PSTN (Public Switched Telephone Network), VoIP can be supported by data communication networks. The enterprises now can integrate data, voice, fax, and video applications into only one network, which can largely reduce the service cost [1]. However, on the other hand, it means the VoIP has to share the same network with different applications. Since the current data network, i.e., the Internet, was not designed for real-time applications such as VoIP, VoIP can suffer from its QoS (quality of service) problems. Delay, jitter and packet loss are the three most concerns of QoS requirements to VoIP. Delay is always considered as the “only one” biggest obstacle. An end-to-end delay over 150 ms can lead to the poor conversation interactivity. The packet loss of VoIP in the de-jittering buffer caused by the excessive delay of the packets can seriously lower the hearing quality. Jitter can be compensated by the de-jittering buffer through introducing additional delay and losses. To deliver a level of voice quality that is PSTN equivalent, the VoIP packet loss must be held This work was supported by the Sphairon Access Systems GmbH.

below 1% [2]. The authors in [2] also found that packet loss in burst can exacerbate the voice quality rather than loss in isolate. There are many factors that contribute to the total end-to-end delay of VoIP, e.g., the encoding time, the packet serialization time, the propagation time, the queueing delay in a router, etc.. The queueing delay, which is caused by the multiplexing of VoIP packets as well as data packets over the shared link, can be different according to the queue occupation condition. Especially, it can become serious in entering into a bottleneck link due to the latter’s low speed and can finally result in an unnecessary end-to-end delay of VoIP. In recent years, the ADSL (Asymmetric Digital Subscriber Line) technology has become one of the most popular solutions to the last mile problem of broadband networks. In ADSL access network, DSLAM (Digital Subscriber Line Access Multiplexer) is used for the connection to the core network. The voice and data packets from/to a subscriber go to/from the DSLAM through the ADSL up/down-link. The ADSL link becomes the bottleneck in the communication. From the comparatively low speed in the ADSL uplink, e.g., 128 Kbps, one may expect the QoS problems of VoIP mainly arise in this direction. The paper [3] found that with a scheduling scheme that priorities the voice traffic over data traffic to the uplink, the VoIP quality can be well satisfied. Although the ADSL downlink has much higher link rate (typically as 8 times as the uplink), the considerable bandwidth difference between core and access network leads to queueing of downstream in DSLAM buffer. If the IP network operator does not support different service types for VoIP and data applications, FCFS (First Come First Serve) queueing may be necessary. In this paper, we focus on the queueuing delay problem of a VoIP application that competes with TCP applications cross ADSL downlinks. The DSLAM is assumed to only have a FCFS queue implemented. The VoIP packets, therefore, can be delayed seriously in the DSLAM buffer by the coexistent TCP connections. Our main objective is to restrict the number of TCP packets allocated in the DSLAM and thus to reduce the queueing delay of VoIP. Packet dropping, as a simple but effective TCP traffic control mechanism, is widely used in current networks. In [4], a Random Early Detection (RED) gateway by which the incoming packet is dropped according to the average queue length is proposed for network congestion avoidance. [5] proposes an adaptive packet dropping mechanism relying on a per-class queue management in a router to achieve good

978-1-4244-2075-9/08/$25.00 ©2008 IEEE Authorized licensed use limited to: Jyvaskylan Ammattikorkeakoulu. Downloaded on October 16, 2008 at 05:29 from IEEE Xplore. Restrictions apply.

120

This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the ICC 2008 proceedings.

performance both from TCP applications and UDP flows. In our previous paper [6], a simple packet dropping algorithm is introduced in the ADSL router to protect the VoIP quality from TCP applications. In this paper, an adaptive TCP packet dropping algorithm based on the RED mechanism is proposed at user’s side to control the number of TCP packets delaying VoIP packets in the DSLAM buffer under different network conditions. The rest of this paper is organized as follows. In Section II, the TCP packet dropping is at first discussed. The RED mechanism then is introduced. In Section III, our adaptive packet dropping algorithm based on the RED mechanism is proposed. The simulations and results are presented in Section IV. The conclusions are drawn in Section V. II.

RELATED WORK

A. TCP packet dropping As already mentioned previously, it is necessary to limit the number of packets a TCP connection can place in the DSLAM buffer. TCP is a window-based protocol. In TCP a so named congestion window is used to control the network congestion. The congestion window indicates the maximum number of unacknowledged packets that a TCP sender can have outstanding in the network. In TCP, packet loss is considered as the sign of network congestion, and the TCP sender will respond it with a reduced congestion window size. One way by which the TCP sender detects a packet loss is through the receipt of duplicated acknowledgement packets (ACKs) from receiver. By receiving duplicated ACKs, the sender cuts its congestion window to half during “Fast Retransmission and Recovery” phase. Another method used by TCP to inform a packet loss is through using the retransmission timer. In case of retransmission time-out, the congestion window is reduced to one packet. Thus, it is feasible to avoid large window sizes by introducing packet losses in the downstream of active TCP connections and therefore effectively limit the maximum number of packets that are placed in the DSLAM buffer. It is obvious that to guarantee VoIP quality under different network conditions, e.g., different network loads, the required drop ratio should be different. High drop ratio leads to inefficient link utilization and poor perceived quality, e.g., for HTTP application [6]. To protect VoIP from different background TCP traffic, and in the meantime to maintain TCP performance as good as possible, an adaptive packet dropping algorithm which can dynamically adjust the drop ratio, depending on the network traffic, is required. B. Random Early Detection (RED) Sally Floyd and Van Jacobson proposed the Random Early Detection algorithm in [4] for network congestion avoidance. The basic idea of RED is by early packet dropping, i.e., dropping packets before the queue is completely full, to avoid the potential network congestion. In RED the packet is dropped according to the average queue size. As shown in Fig. 1, for

for each packet arrival calculate the average queue size avg if minth < avg < maxth calculate probability pa with probability pa: drop the arriving packet else if maxth < avg drop the arriving packet Fig. 1. General algorithm for RED [4]

each packet arrival the average queue size is updated. RED uses a low-pass filter with an exponential weighted moving average (EWMA) for computing the average queue size avg: (1) avg = (1 − w q ) ⋅ avg + w q ⋅ q Where, wq is the queue weight factor, q is the current queue length. The value of avg will be compared with two thresholds. If the average queue size is less than a minimum threshold minth, no packets are dropped. When the average value crosses minth, the packet will be dropped with probability pa. The probability pa is calculated by the following two steps: p b = max p ( avg − min th ) /(max

th

− min th )

p a = p b /(1 − count ∗ p b )

(2)

Firstly, a linear function of the average queue size is used for calculating the probability pb. With the increasing of avg from minth to maxth, as shown in equation (2), pb increases from 0 to the maximum threshold maxp. The drop probability pb then will be modified by the variable count which records the current distance to the last dropped packet. This ensures the RED does not wait too long before dropping a packet. With increasing the average queue size to a maximum threshold maxth, every arriving packet is dropped. RED has been proved that it can effectively control the average queue size below a certain threshold [4] and can be used to control the average queueing delay in a router [5]. There are other advantages of RED such as: it has no bias against bursty traffic and avoids the global synchronization of many connections decreasing their window at the same time [4]. III.

ADAPTIVE PACKET DROPPING ALGORITHM

A. The motivation and the proposed algorithm As described in the previous section, our main objective is to limit the number of TCP packets in the DSLAM. In other words, the queue size in the DSLAM has to be controlled. Considering the RED algorithm, a main feature of RED is its good ability in controlling average queue size under a threshold. Thus, if we know the queue occupation condition in the DSLAM, or if we know some other parameters which can reflect the queue size condition, the RED algorithm might be suitable to be adopted for our purpose. VoIP delay in ADSL downlink is such a parameter that we need. Since the queueing delay in DSLAM is considered as the main contributor to the total delay of VoIP in ADSL downlink, the latter delay can reflect the former one

121 Authorized licensed use limited to: Jyvaskylan Ammattikorkeakoulu. Downloaded on October 16, 2008 at 05:29 from IEEE Xplore. Restrictions apply.

This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the ICC 2008 proceedings.

for each packet arrival if(VoIP) calculate the average delay avg else calculate probability pa with probability pa: drop the arriving TCP packet

pb 1

maxp minp 0 minth

Fig. 2. The proposed algorithm

which is decided by the DSLAM queue size directly. In a real time application, RTCP (Real Time Control Protocol) is used for synchronization. In a synchronized RTP (Real Time Protocol) session, the time stamp in a RTP packet combined with the NTP (Network Timing Protocol) stamp in a sender report of RTCP, in which the sending time of this report from the RTP sender is recorded, can be used for computing the one-way delay at the VoIP receiver. Since the queueing delay in ADSL downlink is considered as the only reason that varies the total one-way delay, other delays experiencing outside can be estimated with a fixed value. Thus the downlink delay can be computed by the measurement of the total end-to-end one-way delay at the receiver. Moreover, since reducing delay of VoIP is our object indeed, it might be effective to directly use delay as a parameter to control TCP packet dropping. In this paper, we propose a packet dropping algorithm based on the RED algorithm. In our algorithm, we monitor the delay of VoIP at receiver and use it as the network “congestion” indication. The incoming TCP packet then is dropped probabilistically upon the average VoIP delay condition. Fig. 2 gives the pseudo code of our algorithm. As shown in Fig. 2, the incoming packets are treated differently according to their types. With a VoIP packet arriving, only the average delay is updated. When a TCP packet arrives, the drop probability will be calculated. In our algorithm, only the TCP packets are allowed to be dropped. For calculating the average delay, equation (1) from the original RED is adopted. The q and avg in (1) now become the current value and mean value of VoIP delay. To compute the drop probability, we make some modifications to RED. Fig. 3 illustrates the drop functions in the original RED (dotted line) and in our algorithm (solid line). Compared with the original RED, our algorithm introduces a new parameter minp and the linear drop function is extended and separated into three segments. If avg is smaller than minth, the drop probability increases from 0 to minp linearly. This allows packet to be dropped even early in a “good” period of VoIP. This feature benefits to protect VoIP from a bursty but light TCP traffic, e.g., Web surfing. With such traffic in the network, VoIP may have a very small instantaneous delay (good period) in majority time separated by delay spikes (caused by the data bursts). The early drops during these good periods limit the TCP burst size so that prevent the VoIP delay to reach a too high level. If avg locates between minth and maxth, pb increases from minp to maxp. In the case that avg exceeds maxth, pb

maxth

2maxth

avg

Fig. 3. Drop probability in RED and the proposed algorithm

increases linearly to 100% with a slop of (1-maxth)/maxth. This slows down the packet dropping during a bad period of VoIP and might avoid some unnecessary drops during those periods in which a high value of average delay is caused by a transient congestion only. The functions of pb are summarized as equation (3). The drop probability pb then is modified by using equation (2) for calculating the final drop probability pa. (0 ≤ avg < min th )  min p ⋅ avg / min th    (max p − min p ) /(max th − min th ) ⋅ ( avg − min th )  + min p (min th ≤ avg < max th )   pb =   (1 − max ) / max ⋅ ( avg − max ) + max p th th p   (max th ≤ avg < 2max th )   1 ( avg ≥ 2 max th ) 

(3)

B. Parameter setting Obtaining an optimal RED configuration is always difficult. A proper set of parameters for one certain traffic condition may have detrimental effects if used under other conditions. Some studies [7], [8] have been performed to address this problem. In our paper a RED “queue” of VoIP delay is intended to be build up. Its configurations have to be suitable for different background traffic. To simplify the configurations, in this paper, we try to fix maxth, minth, maxp as well as minp and only investigate the influence from wq. The intention is to find a proper setting for all the traffic under investigation. The selection of maxth and minth can be depended on the desired VoIP average delay. The optimal value for maxth should depend on the maximum average delay that can be allowed by the packet. The value of minth ensures a minimum link utilization. A useful rule-of-thumb is to set maxth to at least twice minth [4]. ITU-T recommendation G.114 defines the maximum one-way delay of a voice conversation as 150 ms. For a VoIP communication with ADSL access on both end points and considering to the much lower speed in the ADSL uplink, up to 100 ms’s delay budget has to be conserved for the remote uplink part by neglecting the delay in the Internet. In other words the tolerable maximum delay in ADSL downlink is 50 ms in the

122 Authorized licensed use limited to: Jyvaskylan Ammattikorkeakoulu. Downloaded on October 16, 2008 at 05:29 from IEEE Xplore. Restrictions apply.

This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the ICC 2008 proceedings.

TCP drop ratio:2 Web TCP drop ratio:1 Web TCP drop ratio: FTP

0.055 0.05 0.045 0.04 0.035 0.03 0.025 0.02

SIMULATION RESULTS

0.015 0.01 0.05

0.1

0.15

0.2

0.25

Weight factor (w_q)

Fig. 4. TCP drop ratio with the proposed packet dropping algorithm 0.1 VoIP delay (s)

In our simulation, a VoIP communication with ADSL access on both clients is constructed. The delay in the remote ADSL uplink part is assumed to be 100 ms. A de-jittering buffer with size of 150 ms is implemented at the local side, in which the VoIP packets with delay exceeding the limitation will be discarded. A priority queue for VoIP as well as a FCFS queue is applied in the ADSL uplink and downlink. All of the queue sizes are sufficiently large to ensure a loss of VoIP packet can only happen in the de-jittering buffer due to its excessive delay in the DSLAM. For ADSL rates the 128 Kbps and 1024 Kbps are set for the uplink and downlink respectively. We select G.729A as coder type. With a payload of 20 bytes every 20 ms, it leads to a VoIP packet with size of 159 bytes including all of the overheads (RTP, UDP, IP, PPPoE, AAL, ATM). To evaluate the performance of our algorithm under different network conditions, we use two different competitive traffic for VoIP: Web and FTP. FTP is a kind of steady heavy traffic whereas Web is considered to be light in burden but can be very bursty due to its concurrent short-lived TCP connections. We use one Web session as well as two sessions to simulate different level of burstiness. The traffic model of the Web applications is taken from [9] which specifies several distributions that describe the user behavior and properties of Web pages. To see a more detailed description of our simulation model and the traffic model adopted, please refer our previous paper [6]. Fig. 4 shows the achieved TCP packet drop ratio with different wq by using the proposed algorithm. As can be seen from the figure, it shows an increment of TCP packet drop ratio with an increased wq under Web traffic condition. As described in equation (1), the EWMA weight factor wq decides the proportion of the instantaneous delay in computing the average value. A high wq allows a quick catching of the delay variation which can lead to more packet dropping. Fig. 5 illustrates the calculated average delay avg and the instantaneous delay with different value of wq over time. The TCP traffic is set to 2 Web sessions. As shown in Fig. 5, with a higher value of wq, the calculated average delay catches much closer to the delay spikes. This increases the value of avg on the whole and eventually leads to a higher operation section of the drop function (Fig. 3). A same behavior of VoIP delay has been obtained with 1 Web session. With FTP traffic, the TCP drop ratio shows insensitivity to wq as shown in Fig. 4. The reason is

average delay current delay

0.08 0.06 0.04 0.02 0 0

10

20

0.1 VoIP delay (s)

IV.

0.06

TCP drop ratio

worst case (when the delay in the remote uplink reaches to 100 ms). Thus we select 35 ms and 10 ms for maxth and minth respectively. The value of maxp bounds the drop probability. It is suggested in [4] to set maxp no greater than 0.1 to avoid unnecessary low link utilization under heavy congestion condition. Our previous paper [6] shows that the response time of Web surfing can deteriorate considerably with discarding more than 10% packets. maxp and minp are set to 10% as well as 1% in this paper.

30 Time (s) (w_q=0.01)

40

50

60

average delay current delay

0.08 0.06 0.04 0.02 0 0

10

20

30 Time (s) (w_q=0.1)

40

50

60

Fig. 5. VoIP delay with the proposed algorithm

the steady heavy FTP traffic results in a comparatively steady delay of VoIP. The VoIP delay behavior with 1 Web session and FTP traffic are not shown in this paper due to the space limitation. For evaluating the efficiency of our algorithm, we use the fixed drop ratio algorithm by which the TCP packet is dropped randomly with the given probability, for comparison. The comparison will be taken from the point of view of VoIP quality and TCP quality. For accessing VoIP quality, packet loss ratio and the loss burst ratio are used. Since the delay in DSLAM leads the packet discarding in de-jittering buffer, the problem of delay finally has been converted into the problem of packet loss at the de-jittering buffer. To maintain a good voice quality, the packet loss ratio should not exceed 1% [2] and it is taken as the criteria in this paper. ITU-T recommendation G.107 [10] introduces a factor BurstR to estimate packet loss burstiness. BurstR is defined as the ratio of the average length of observed bursts in an arrival sequence to the average length of bursts expected for the network under “random” loss. The computation of BurstR has been discussed in [11]. A high value of BurstR represents high loss burstiness and introduces more impairment to voice quality. In the case of random loss, BurstR is equal to 1. For estimating the TCP performance, the TCP drop ratio which

123 Authorized licensed use limited to: Jyvaskylan Ammattikorkeakoulu. Downloaded on October 16, 2008 at 05:29 from IEEE Xplore. Restrictions apply.

This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the ICC 2008 proceedings.

10

2 Web: loss ratio 2 Web: loss burst ratio 1 Web: loss ratio 1 Web: loss burst ratio FTP: loss ratio FTP: loss burst ratio

9 8

0.1 VoIP loss ratio

7 6 5

0.01

VoIP loss burst ratio

1

4 3 0.001

2 0.01

0.02

0.03

0.04

0.05 0.06 TCP drop ratio

0.07

0.08

0.09

0.1

ratio under all of the three network conditions. Furthermore, as shown in Fig. 4, our algorithm can successfully adapt to the network traffic. With setting wq to 0.15, the VoIP quality can be well satisfied under all of the three traffic conditions. The required TCP drop ratios are automatically adapt to 3.8%, 4.7% and 4.6% in each of the cases with the obtained VoIP loss burst ratios suppressing to 2.3, 2.7 and 1. As shown in Fig. 6, to control the VoIP loss ratio below 1% under all of the conditions, as high as 7.5% TCP packets have to be dropped in each case with the fixed drop ratio algorithm. The resulted VoIP loss burst ratios are 2.4, 2.8 and 3.6. From our previous paper [6], a higher TCP drop ratio leads to a lower link utilization and poorer perceive quality, e.g., for Web application. V.

Fig. 6. VoIP quality with fixed ratio random packet dropping

0.02

VoIP loss ratio

4

2 Web:VoIP loss ratio 2 Web:loss burst ratio 1 Web:VoIP loss ratio 1 Web:loss burst ratio FTP:VoIP loss ratio FTP:loss burst ratio

3.5 3

0.015

2.5 2

0.01

VoIP loss burst ratio

0.025

1.5 0.005 1 0

0.5 0.05

0.1 0.15 Weight factor (w_q)

0.2

CONCLUSIONS

In this paper, an adaptive packet dropping algorithm based on the RED mechanism has been proposed to protect VoIP application from TCP traffic cross ADSL downlinks. Its basic idea is to use delay of VoIP for deciding TCP dropping since the main problem of VoIP under the investigated scenario is considered to be the queueing delay problem. Our simulation results show that the proposed algorithm can be successfully adaptive to different traffic conditions. Furthermore, compared with the fixed drop ratio algorithm, our algorithm shows the advantages on requiring fewer TCP packet drops and maintaining a better VoIP loss burstiness. However, the calculation of VoIP delay can increase the packet processing time and intensify the complexity for implementation.

0.25

Fig. 7. VoIP quality with the proposed packet dropping algorithm

is necessary to guarantee the VoIP quality is used. All the simulations are realized in ns-2 [12]. The results are taken from 100 subruns of 600 s’ simulated time each at a confidence probability of 95%. Fig. 6 shows the VoIP quality under different traffic with the fixed drop ratio algorithm. In order to have the VoIP loss ratio under 1%, the required TCP drop ratio has to be 2.5% (1 Web), 5.5% (2 Webs) and 7.5% (FTP). The corresponding loss burst ratio is indicated as 3.9, 3.1 and 3.6 respectively. Fig. 7 illustrates the VoIP quality with different wq set in our proposed algorithm. The intension is to find a proper set of wq for each traffic condition. As shown in Fig. 7, for 1 Web session, a very small wq (about 0.005) can guarantee VoIP loss below 1%. Meanwhile the loss burst ratio is suppressed to 3.4. The correspondence TCP packet drop ratio is indicated as 1.6% in Fig. 4. For 2 Web sessions, our criteria can be fulfilled by using a wq above 0.15. The obtained BurstR and the required TCP drop ratio, as shown in Fig. 7 and 4, is 2.7 and 4.7% respectively. In our simulation, the VoIP loss ratio under FTP traffic keeps near 0 which leads to isolated packet losses with an almost constant BurstR of 1. Compared with the fixed drop ratio algorithm, as described above, our algorithm needs fewer TCP packet drops for guaranteeing VoIP quality and achieves smaller VoIP loss burst

REFERENCES [1]

M. Hassan, “Internet Telephony: Services, Technical Challenges, and Products”, IEEE Communication Magazine, April, 2000. [2] J. H. James, B. Chen, L. Garrison, “Implementing o f VoIP: A Voice Transmission Performance Progress Report,” IEEE Communication Magazine, pp. 36-41, July 2004. [3] L. Orozco-Barbosa, A. Siddiqui, A. Yongacoglu, “Efficient integration of voice and data for transmission over Digital Subscriber Line (DSL)”, Proc. of the IEEE Canadian Conf. on Electrical & Computer Engineering, 2002. [4] S. Floyd, V. Jacobson, “Random Early Detection Gateways for Congestion Avoidance,” IEEE/ACM Transactions on Networking, 1(4), pp. 397-413, August 1993. [5] Mei-Ling Shyu, Shu-Ching Chen, Hongli Luo, “Per-class queue management and adaptive packet drop mechanism for multimedia networking”, Proc. Int. Conf. on Multimedia and Expo–Vol.3, Jul. 2003. [6] Q. Dai, M. Baumann, R. Lehnert, “Improvement of VoIP quality by Packet Dropping in ADSL routers”, Proc. of the Int. Conference on Signal Processing and Multimedia Applications, Barcelona, Spain, 2007. [7] T. Ye, S. Kalyanaraman, “Adaptive Tuning of RED Using On-line Simulation”, Proc. of IEEE GLOBECOM, November, 2002. [8] Wuchang Feng, Dilip D. Kandlur, Debanjan Saha, Kang G. Shin, “A Self-Configuring RED Gateway”, IEEE INFOCOM, 1999. [9] B. A Mah, “An Empirical Model of HTTP Network Traffic”, Proc. of IEEE Infocom, April 1997. [10] ITU, Recommendation G.107, “The E-Model, A Computational Model for Use in Transmission Planning”, Recommendation G.107, Geneva, Switzerland, 2005. [11] A. Raake, “Short- and Long-Term Pakcet Loss Behavior: Towards Speech Quality Prediction for Arbitrary Loss Distributions”, IEEE transactions on audio, speech and language processing, Vol. 14, No. 6, November 2006. [12] The Network Simulator- ns-2, from http://www.isi.edu/nsnam/ns/.

124 Authorized licensed use limited to: Jyvaskylan Ammattikorkeakoulu. Downloaded on October 16, 2008 at 05:29 from IEEE Xplore. Restrictions apply.