PROVIDING QOS IN 3G-WLAN ENVIRONMENT WITH

RSVP AND DIFFSERV

Eero Wallenius

Nokia Networks/ OS, Hatanpäänvaltatie 30, FIN-33100 TAMPERE

Timo Hämäläinen, Timo Nihtilä, Jyrki Joutsensalo

University of Jyväskylä, Department of Mathematical Information Technology, Finland

Keywords: 3G, WLAN, QoS, 3G-WLAN Interworking

Abstract: Here we present the end-to-end QoS mechanism in 3G-multiaccess network environment. As multi-access

wireless WLAN and wired xDSL wideband multi-access technologies has emerge and become more

popular a need for interoperability with different technologies and domains has become necessity. There is

also a need for end-to-end QoS management. We show a scenario where the UE-GGSN connection is

covered by RSVP and RAN network part uses partial over dimensioning and real-time controlled ATM

queuing. DiffServ covers WLAN-Core QoS and radio interface between WLAN AP and WLAN UE uses

IEEE’s 802.11e. Our interest is to find out how well 3G traffic classes can survive in different traffic

conditions in the end-to-end case.

1 INTRODUCTION

With the evolution of QoS-capable 3G wireless

networks, the wireless community has been

increasingly looking for a framework that can

provide effective network-independent end-to-end

QoS control. One bigger problem arises with this

kind of diverse networks. It is the dissimilarity of

traffic characteristics and QoS management

methods. Problem with WLAN networks is the high

error rate probability. 802.11e standard has been

applied trying to correct the situation by enabling the

use maximum of eight separate priority queues for

prioritizing higher priority traffic compared to other

traffic [802.11e]. QoS supported WLAN uses the

Enhanced Distributed Coordination Function

(EDCF). It is the basis for the Hybrid Coordination

Function (HCF) [802.11e]. Our research is also

related to 3GPP WLAN interworking

standardization [TS23.234].

RSVP has been used in domains where there is

no direct radio interface. In the RAN case we have

assumed that the radio interface between BTS and

UE in RAN will be handled similarly to WLAN but

with different methods defined by 3GPP

standardization. As RAN is based on ATM the basic

assumption has been that the RAN correctly

dimensioned to carry al traffic coming from and

going to UE direction so by default RAN QoS is out

of scope of scenarios in this paper.

This research is part of the 3G–WLAN

Interworking research program made during years

2002-2004 [Wallenius E., Hämäläinen T., Nihtilä T.,

Luostarinen K.] and [Hämäläinen T., Wallenius E.,

Nihtilä T., Luostarinen K.]

2 MAPPING QOS ATTRIBUTES

TO CROSS DOMAIN

INTERFACES

3GPP has defined four traffic (QoS) classes and

three subclasses (Interactive THP, Traffic Handling

Priority) that can have their own QoS attributes [TS

23.107]. All traffic in the 3G network will be

handled according to the operator and service’s

requirements at the each of these traffic classes. The

main QoS method to be used at the core network is

supposed to be DiffServ [TS22.934]. Addition to

that 3GPP has defined RSVP as an additional UE

originated QoS method [TS23.917] in Rel6 between

135

Wallenius E., Hämäläinen T., Nihtilä T. and Joutsensalo J. (2004).

PROVIDING QOS IN 3G-WLAN ENVIRONMENT WITH RSVP AND DIFFSERV.

In Proceedings of the First International Conference on E-Business and Telecommunication Networks, pages 135-141

DOI: 10.5220/0001386901350141

 SciTePress

UE-SGSN and GGSN. It can be used at the

situations where scalability problems will not arise

(small networks). 3G traffic classes are:

Conversational class for voice and real-time

multimedia messaging. Streaming class for

streaming applications (Video On Demand (VOD)

etc.), Interactive class for interactive applications

(eCommerce, WEB-browsing, etc.), Background

class for background applications such as email and

FTP. QoS values for each traffic classes are defined

in [TS23.107]. In DiffServ domain four priority

queues can be implemented for the each 3G traffic

classes. The three THPs (Traffic Handling Priority)

are also available for Interactive class to further sub-

classify Interactive class traffic by inserting it to

three separate queues. 3G to DiffServ mapping

process can be policy based controlled and the

mapping can be indicated at the IP level by the

DSCP (DiffServ Code Point) inserted to the TOS

field by DS classifier/marker mechanism or by the

actual application that generates the control plane

traffic. Table 1 shows the PHB actions with DSCP

mappings.

The nature of RSVP functionality differs

significantly from DiffServ. RSVP uses end-to-end

signaling enabling a single UE to reserve end-to-end

transport capacity from the network or RSVP can be

used by Bandwidth Broker and COPS-PR protocol

to set appropriate traffic filters to routing nodes to

achieve similar capacity reservation than by UE

signaling.

3 SIMULATION ENVIRONMENT

AND PARAMETERIZATION

The goal is to study what are throughputs, delays

and dropping rates in RSVP and DiffServ cases.

Simulation environment in Figure 1 consists of 18

Access points which each connected to UEs with

different traffic priorities. Six core network nodes

build up a ring and each of them has three access

points. WLAN stations send data at the rate of

2.5Mb/s. Stations no. 1 and no. 3 generate CBR

traffic and stations no. 2 and no. 4 send VBR traffic.

The stations start sending at time interval 3-4.5

seconds randomly. Simulation time is 40 seconds

and the used packet size is 1000 bytes for all

stations..

Table 1: RSVP parameterization

3GPP Traffic class Bandwidth Mb/s Bucket size

bytes

Conversational 3.0 3000

Streaming 2.5 2000

Interactive (3 THPs) 2.0 1500

Background 2.0 1500

UEs for AP 1-9 are sending and 10-18 receiving.

Available bandwidth within the core network was 8

Mb/s.

In the core network all wired capacity was

reserved for RSVP use and best effort queue size

was 5000 bytes in every node.

We used traffic parameterization shown in

Table 1.

W LA N/3G A ccess Points

18 W ireless 3G/W LAN

Access Points

HITACHI

6 Corenetwork nodes

4 M T s w ith d iffe ren t

traffic priorities

W LAN/3G Access Points

W LA N/3G Access P oints

W LAN/3G Access Points

Figure 1: Simulation environment

As link capacity is small compared to number of

reservations some of the reservations does not

success and traffic related to them goes in the

network as best effort traffic. RSVP uses WFQ

queuing. DiffServ uses Token Bucket Polices and its

parameterization is presented in Table 2.

Table 2: DiffServ token bucket parameterization

3GPP Traffic class CIR Mb/s Bucket size bytes

Conversational 3.0 3000

Streaming 2.5 2000

Interactive (3 THPs) 2.0 1500

Background 2.0 1500

DiffServ uses RED queuing in drop tail mode.

In-profile packet queue lengths are 30 packets for

each class and out-of-profile packet queues are 60

packets long.

We used four priority levels in both scenarios.

EDCF parameters of different Traffic Classes are

shown in the following Table 3.

Table 3: EDCF parameters

3GPP Traffic

class

Conv. Stream Interact. Backgr.

CWMin 7 10 15 127

AIFS

(CWOffset)

2 4 7 15

CWMax 7 31 255 1023

To emulate the process of packet transmission

errors we extended the simulator by implementing a

ICETE 2004 - WIRELESS COMMUNICATION SYSTEMS AND NETWORKS

136

two-state Markov model in the air interface. In our

error scenario, the channel switches between a "good

state" and a "bad state", G and B respectively:

Packets are transmitted correctly when the channel is

in state G, and errors occur when the channel is in

state B. When the channel is in state G, it can either

remain in this state, with probability

or make the

transition to state B, with probability 1-

. Likewise,

if the channel is in state B, it remains in this state

with probability

and changes state with

probability 1-

Table 4: Transition probabilities for 2-state MMPP

Error rate

0% 0 1

20% 0.16 0.63

All test were done with network simulator NS-2

with IEEE 802.11 EDCF functionality implemented

by Project-INRIA [Ni Qiang]. We ran several

different error rate scenarios but we find 0 and 20%

error rates most illustrative.

3.1 Scenario 1: RSVP case

3.1.1 RSVP throughputs

As can be seen in Figure 2 Interactive class has

higher throughput than Streaming class.

Figure 2: RSVP throughput with 0% error rate

This is caused by the random nature of reservation

signalling.

The reservation probabilities are shown in Table

In case that there is already 6Mb/s reservation

for two Conversational class flows only Interactive

and Background classes can reserve the rest of the

bandwidth.

Other traffic characteristics follow very well

expectations on throughput delay.

Table 5: Reservation probabilities

Mb/s Conv. Stream Interact. Backgr.

8 0.25 0.25 0.25 0.25

6 0.25 0.25 0.25 0.25

5.5 0.25 0.25 0.25 0.25

5 0.25 0.25 0.25 0.25

4 0.25 0.25 0.25 0.25

3.5 0.25 0.25 0.25 0.25

3 0.25 0.25 0.25 0.25

2.5 0 0.33 0.33 0.33

2 0 0 0.5 0.5

Average 0.194 0.231 0.287 0.287

Throughput is best and delay follows the

throughput being higher than in other classes due to

the high throughput.

Figure 3: RSVP throughput with 20 % error rate

Also can be seen in Figure 2 and Figure 1 that

the traffic flows are smoother in lower error

environment.

Average throughputs on each traffic class also

follow well our expectations. Throughputs are in

preferable order, Conversational highest and

background lowest.

PROVIDING QOS IN 3G-WLAN ENVIRONMENT WITH RSVP AND DIFFSERV

137

Figure 4: RSVP average throughputs / priority

Figure 4 shows also slight rise of throughput in

Interactive class and corresponding declining in

Background class for higher error rates. This can be

caused by differences in reservation success between

classes.

3.1.2 RSVP Delays

Delay behaviour is similar as throughput. All

aggregate flows, traffic classes, are in correct order

and delay is adequate low (< 0.5 ms) in both

Conversational and Streaming class for their 3G

usages. Also Interactive and Background classes are

far below their worst-case scenario values, several

seconds. See Figure 5 and Figure 6.

Figure 5: RSVP delay with 0% error rate

Figure 6: RSVP delay with 20% error rate

3.1.3 RSVP packet dropping

RSVP packet dropping follows the throughput being

higher in higher throughput classes as expected. In

this case a better describer for packet dropping

would probably be percentage value, which would

turn the order of curves into opposite order.

Figure 7: RSVP dropping rate with 0% error rate

Dropping rate is very stable when the dropping

rate is 0% Figure 7 but becomes unstable and rising

with error rate 20%.

ICETE 2004 - WIRELESS COMMUNICATION SYSTEMS AND NETWORKS

138

Figure 8: RSVP dropping rate with 20% error rate

3.2 Scenario 2: DiffServ case

3.2.1 DiffServ throughputs

DiffServ show different kinds of throughput results

than RSVP. Conversational traffic is dominant and

other traffic classes are very close to nil. The

obvious difference is that RSVP has much better

control over lower priority flows and therefore it

would be a better solution for Interworking QoS

control purposes.

Figure 9: DiffServ throughput with 0% error rate

As can be seen form Figure 9 traffic with

priorities 3 and 4 disappears within 10 seconds after

beginning of the test. This means also that the delay

for priorities 3 and 4 becomes 0 (zero), as there is no

traffic in priority classes 3 and 4 as shown in next

chapter.

Figure 10: DiffServ throughput with 20% error rate

Difference between throughputs with 0% and 20%

error rate is significantly low.

Figure 11 shows that the average throughputs of

the classes are the same between different error

rates. This indicates that throughput behavior is very

stable when using DiffServ in opposite to RSVP,

which causes large variations in class throughputs

between error rates.

Figure 11. DiffServ average throughputs / priority

Still, this stable behavior is achieved in cost of

lower priority class throughputs, which are close to

zero.

PROVIDING QOS IN 3G-WLAN ENVIRONMENT WITH RSVP AND DIFFSERV

139

3.2.2 DiffServ delays

Figure 12: DiffServ delay with 0% error rate.

As presented in Figure 12 the delay for flows

with priorities 3 and 4 become zero (vanishing from

logarithmic scale). This actually means that after a

few seconds after stations have started to send flows

with priorities 3 and 4 are not reaching their target

receiver node but are totally dropped during

transmission. Similar effect occurs with 20% error

rate in Figure 13.

Figure 13: DiffServ delay with 20% error rate

3.2.3 DiffServ packet dropping

Figure 14: DiffServ dropping rate with 0% error rate.

As shown in Figure 14 dropping rates are located

as could be predicted according to their priorities.

Figure 15: DiffServ dropping rates with 20 % error rate.

Naturally as presented in Figure 15 increased

error rate increases dropping rate accordingly. High

air interface error rate affects the dropping rates, so

that there seems to be lower dropping rate in 20%

error rate scenario. As the air interface corrupts

packets, fewer of them reach the wired network.

Hence, there is smaller probability of congestion in

the wired network.

ICETE 2004 - WIRELESS COMMUNICATION SYSTEMS AND NETWORKS

140

3.3 Test conclusions and

recommendations

3.3.1 Combined throughputs

Figure 16: Comparison of total throughputs with RSVP

and DiffServ

Figure 16 shows that the throughput in DiffServ

case is slightly better than in RSVP case. That is

expected due to the resource reservation nature of

RSVP. In DiffServ case all traffic classes can have

unlimited number of flows compared to RSVP’s

bandwidth limiting functionality and access control.

The difference between these techniques is almost

negligible due to the fact that both RSVP and

DiffServ achieve the maximum capacity of the

network. This is due to the amount of traffic in the

network: the flows are sending traffic so intensively

that there is always a demand of bandwidth for best

effort traffic and hence the network is never idle.

4 CONCLUSIONS AND FUTURE

WORK

4.1 Achievements

In this paper we provided architecture for end-to-end

QoS control in a wired-wireless environment with

effective QoS translation. We used DiffServ and

RSVP in the core network and 3G/WLAN and

802.11e at the wireless part of the tests.

Results show clearly that RSVP can keep delays

smaller than in the DiffServ case. Paper also shows

that the best and most suitable combination of QoS

control would be RSVP-802.11e hybrid. Suitability

materializes especially in the control of lower

priority flows enabling them more and more

controllable bandwidth with lower and controllable

delay.

4.2 Future Studies

Next we will expand our simulations to cover a real

operating size network and study how the operating

parameters can be tuned e.g. by using dynamic

policy based management.

Also further development of 3G interworking

with other access methods is gaining increasingly

importance and to achieve solid and robust

Interworking QoS is the next top research challenges

for the future.

REFERENCES

TS22.934, 3GPP Technical Specification, “Feasibility

study on

3GPP system to Wireless Local Area Network (WLAN)

interworking”, Release 6.0

TS23.107, 3GPP Technical Specification, “QoS Concept

and Architecture”, Release 5.7

TS23.917, 3GPP Technical Specification,”Dynamic

policy control enhancements for End to end Quality of

Service (QoS)” V1.2.0

TS23.234, 3GPP Technical Specification, “3GPP system

to Wireles Local Area Network (WLAN)

interworking; System description”, Release 6.0

802.11e, IEEE WG, Draft “Supplement to Standard for

Telecommunications and Information Exchange

Between Systems - LAN/MAN Specific

Requirements” - Part 11: wireless Medium Access

Control (MAC) and physical layer (PHY)

specifications: Medium Access Control (MAC)

Enhancements for Quality of Service (QoS), IEEE

802.11e/D2.0, Nov. 2001.

TS 23.234, 3GPP Technical Specification “3GPP System

to Wireless Local Area Network (WLAN)

Interworking: System Description”, v1.0.0, September

2002. (Release 6)

Ni Qiang, http://www-

sop.inria.fr/planete/qni/Research.html

Hämäläinen T., E. Wallenius E., Nihtilä T., Luostarinen

K., ”Providing QoS at the Integrated WLAN and 3G

Environments”, 14

IEEE International Symposium

on Personal, Indoor and Mobile Radio

Communications (PIMRC2003), Oct. 2003.

Hämäläinen T., Wallenius E., Nihtilä T., Luostarinen K.,

“End-to-End QoS Issues at the Integrated WLAN and

3G Environments”, The 9th IEEE Asia-Pacific

Conference on Communications (APCC), Sept. 2003.

Wallenius E., Hämäläinen T., Nihtilä T., Luostarinen K.,

"3G Interworking with WLAN QoS 802.11e", IEEE

Semiannual Vehicular Technology Conference,

(VTC'2003Fall), Oct. 2003

PROVIDING QOS IN 3G-WLAN ENVIRONMENT WITH RSVP AND DIFFSERV

141