Quality of Service Support in the UMTS Terrestrial Radio Access Network

Home , Access network, Radio access network

Ana-Belén García, Manuel Alvarez-Campana, Enrique Vázquez, Julio Berrocal Departamento de Ingeniería de Sistemas Telemáticos Universidad Politécnica de Madrid ETSI Telecomunicación, Ciudad Universitaria, 28040 Madrid, Spain

{abgarcia , mac, enrique, berrocal}@dit.upm.es

Abstract The support of multiple traffic classes with different Quality of Service (QoS) requirements poses new challenges in the field of network design. This is also true in the case of third generation (3G) mobile communications systems, especially in the access network, where radio and transmission resources are usually scarce. In this paper we approach the general issue of UMTS (Universal Mobile Telecommunications System) access network dimensioning, from a practical point of view. Our objective is to give an overall view of the main parameters and design alternatives that can be considered in a real deployment scenario.

Keywords UMTS, Radio access network, Quality of Service, Traffic models, Dimensioning, ATM.

I. INTRODUCTION

There are still many aspects to be solved before 3G mobile systems can be deployed on a large scale. Sometimes the lack of 3G terminals has been presented as the main reason for the delay. However, there are other factors to be taken into account, such as the relative immaturity of the specifications and the significant differences between second and third generation (2G and 3G) mobile systems. The 3GPP (Third Generation Partnership Project), the organization responsible for UMTS specifications, has been working during the last years quite rapidly. Nevertheless, due to the great complexity of the project, there are still some design issues not yet totally covered. Moreover, 3GPP specifications le ave many implementation details open, since they do not fall into this organization’s objectives. Among these aspects, one of the most significant examples is the efficient support of multiple applications with different QoS requirements. This is an issue for which there is still a lack of experience in the communications sector. The UMTS design is influenced by the requirements of the services that will be supported. One of the intervening aspects is the great diversity of application types foreseen [1], including voice, data, video, and multimedia in general. The differences among them (respecting required bandwidth, and tolerance to losses and delay) call for QoS mechanisms inside UMTS. This problem is not simple, especially when it has to be combined with an efficient resource usage. This objective is essential where resources are scarce, such as in the air interface and the access network (UTRAN – UMTS Terrestrial Radio Access Network). Most of the revised UTRAN-related papers focus on radio planning issues (see for instance [2], [3] and [4]). Efficient management of radio resources is of great importance in any cellular network, including UMTS. This is precisely the reason that led 3GPP to choose WCDMA [5] (Wideband Code Division Multiple Access) to be used in the UMTS air interface. However, it is important to remember

1 that the access network also includes the transmission infrastructure between base stations and the core network. This infrastructure is precisely one of the most expensive parts of the cellular network. That is why in this paper we approach the general issue of dimensioning the transmission resources inside the terrestrial part of UTRAN. The rest of the paper is organised as follows. Section II gives an overview of UMTS architecture, focusing on UTRAN. The main factors to be considered in UTRAN dimensioning, including traffic modelling, QoS requirements and traffic multiplexing alternatives, are analysed in section III In section IV we present several alternatives for network deployment, in terms of transmission interfaces and network topologies. Finally, the last section summarises the main conclusions of our study and some future work.

II. UMTS FOUNDATIONS

A. UMTS Architecture Figure 1 represents the basic architecture of an UMTS network [6], showing the main three components: user equipment (UE), access network and core network (CN).

External Networks

PSTN Uu

Iu Air Interface Access Network Core Network Internet WCDMA FDD/TDD (UTRAN) (CN)

User Equipment ··· (UE)

Figure 1: UMTS generic architecture

User equipment access the network via the WCDMA-based air interface (Uu). The access network (UTRAN) is in charge of transporting user traffic (including voice, data and mobile -network signalling) up to the core network, with which it communicates through Iu interface. Inside the core network the necessary switching and transmission equipment will complete the itinerary towards the remote subscriber (located either inside the UMTS network or in an external network). UMTS core network is an evolution of the current 2G networks based on GSM/GPRS (Global System for Mobile Communications/General Packet Radio Service). In fact, the specifications of the first UMTS release (Release 99 [7]) propose to reuse 2G core networks’ infrastructure if possible. Core network evolution is left to subsequent releases (Release 4 [8] and Release 5 [9]). On the contrary, access network significantly differs from 2G networks even in the first release. In order to flexibly accommodate the different application types, packet switching technology is used. Actually, Release 99 specifications establish the use of ATM as the transport technology inside UTRAN1 [11]. The election of ATM is justified since it is (at least at the time the decision was made) one of the most mature and flexible technologies suitable for the deployment of multi-service networks with QoS provisioning. In Figure 2 we can observe UTRAN architecture, including its main elements and the interfaces between them.

1 3GPP has recently defined an alternative solution for the UTRAN based on Internet Protocol (IP) [10].

2 UMTS access network is composed of a collection of RNS (Radio network Subsystems), each one being responsible of the resources of one or several UMTS cells. An RNS includes an RNC (Radio Network Controller) and the group of Node-Bs (or base stations) it controls.

Access Network (UTRAN) Core Network (CN) Iu-CS Iu Iub CS Domain Node B RNC GSM 64 Kbps

Iu-PS Node B RNS PS Domain GPRS GTP/IP Iur Iu Iub Node B RNC Uu (W-CDMA) Node B RNS

Figure 2: UTRAN architecture

Inside the access network two interfaces are defined: Iub interface is located between each Node- B and its controlling RNC, and Iur interface interconnects pairs of RNCs. Iur has no equivalent interface in 2G networks, and it makes it possible to perform soft-handovers between base stations that depend on different RNCs. There are also two interfaces to connect access network with external entities: Uu interface (the air interface), based on WCDMA, and Iu interface, between UTRAN and core network. Iu is logically divided into two entities: Iu-CS (interface to CN circuit switched domain) and Iu-PS (interface to CN packet switched domain).

B. UTRAN Protocols Figure 3 shows a simplified view of the elements that compose UTRAN protocol architecture [11]. Some details have been omitted for clarity (for example, Iur interface is not represented).

UE CN (MSC/SGSN) IP, PPP, ... IP, PPP, ...

CM/SM/MM/GMM AMR, CSD, H.324 Non-access Stratum CM/SM/MM/GMM AMR, CSD, H.324 Access Stratum Node-B RNC

RRC PDCP RRC PDCP

RLC RLC RANAP UP -ps RANAP UP -ps MAC MAC UP-cs UP-cs

NBAP FP NBAP FP Radio Network Layer Transport Network Layer GTP -U GTP -U SCCP UDP SCCP UDP PHY PHY MTP3b IP MTP3b IP SAAL AAL2 SAAL AAL2 SAAL AAL2 AAL5 SAAL AAL2 AAL5

ATM ATM ATM ATM

PHY PHY PHY PHY

Uu Iub Iu Figure 3: UTRAN protocol architecture

UTRAN protocols are structured in two layers: the radio network layer (RNL) and the transport network layer (TNL). This allows the isolation of the UMTS-specific functions (inside RNL) from the functions related with the specific transport technology used (located inside TNL). As already stated, in Release 99 the TNL is based on ATM. Basic ally there are two types of information conveyed over ATM: · Information between mobile and network: signalling information and user traffic that flows between the mobile users and the access node of the core network. This node is an MSC (Mobile Switching Centre) if the communication pertains to the circuit-switched domain, or an SGSN (Serving GPRS Support Node) in the case of the packet-switched domain. · UTRAN signalling: into this category we can find protocols such as NBAP (Node-B Application Part) between Node-Bs and RNCs, RANAP (Radio Access Network Protocol) between RNCs and the core network, and RNSAP (Radio Network Subsystem Application Part) between pairs of RNCs. In Figure 4 we can observe the user plane protocols used at some UTRAN interfaces: Iub, Iu-CS and Iu-PS. The ATM adaptation layers (AAL) chosen are AAL2 at Iub, Iu-CS and Iur (this last one is not represented in the figure), and AAL5 at Iu-PS. In the case of Iu-CS, AAL2 seems a good option for the efficient transport of circuit-mode data (voice packets, fax, etc.). For Iu-PS, each data session utilizes a tunnel (based on GTP, GPRS Tunnelling Protocol) over UDP/IP. In this case AAL5 is chosen, since it is the usual ATM adaptation layer for IP traffic transport.

Iub Interface Iu-CS Interface Iu-PS Interface DCH FP RACH FP FACH FP PCH FP DSCH FP USCH FP CPCH FP

Iu UP Iu UP

GTP-U UDP

IP AAL2 AAL2 AAL5

ATM ATM ATM Physical level Physical level Physical level

Figure 4: UTRAN protocols at the user plane

From the user plane viewpoint, Iub interface can be seen as an air interface prolongation. In fact, from Figure 3, we can infer that radio protocols (i.e. RRC, RLC, MAC) actually end at the RNC. The transport of the MAC frames between a Node-B and its associated RNC is based on AAL2, making each radio channel use an AAL2 connection. AAL2 protocol, specified in ITU-T recommendation I.363.2 [12], allows the efficient multiplexing of several data flows (up to 248) over a single ATM virtual channel. The functioning of this protocol is shown in Figure 5. The first step consists on generating a CPS (Common Part Sublayer) packet flow from each user data flow. Each CPS packet has a 3-octet header and a payload of up to 45 (or 64, whatever is more convenient) octets. Next, CPS packets pertaining to different flows are multiplexed and arranged in 47- octet blocks. Each block is preceded with a 1-octet start field (STF) containing a pointer (useful for re- synchronizing after a cell loss), to form a 48-octet CPS PDU. Each CPS PDU is exactly an ATM cell payload, to which an appropriate ATM header will be attached.

4 User 1 User 2 User 3 Data flows ··· ··· ···

AAL2 CPS-Packets H H H H H ··· 31-64 bytes

AAL2 CPS PDUs P P P ··· 1 47 bytes Pointer

ATM cells ··· 5 48 bytes

H CPS packet header P CPS PDU header (includes AAL2 connection Id.) (includes pointer to 1st. CPS packet) Figure 5: AAL2 protocol

C. Quality of Service in UMTS QoS support in UMTS is based on the hierarchical structure shown in Figure 6, defined in 3GPP specification TS 23.107 [13]. End to end QoS is supported by the several bearer services that can be seen in the figure: at a first level, the local bearer service, the UMTS bearer service and the external bearer service. The objective of this first separation is not limiting neither the terminal equipment type (e.g. a PC) nor the possible external networks (e.g. Internet) with which we can communicate. This is why the specification only relates to the UMTS bearer service.

UMTS

TE MT UTRAN CN Iu CN TE Edge Gateway Node

End-to-End Service

TE/MT Local External UMTS Bearer Service Bearer Service Bearer Service

Radio Access Bearer (RAB) CN Bearer Service Service

Radio Bearer Iu Bearer Backbone (RB) Service Service Bearer Service

UTRA FDD/TDD Physical Service Bearer Service

Figure 6: UMTS QoS architecture

In a second decomposition, UMTS bearer service lies over the RAB (Radio Access Bearer) service and the core network bearer service. The former covers the section between the user’s mobile terminal (MT) and the core network edge node (an MSC or an SGSN). Thus, the air interface, the UTRAN and the Iu interface are involved in the RAB service. This is an essential service for the provisioning of different QoS profiles in UMTS, since the air interface and the UTRAN are the network locations presenting more scarcity of bandwidth. On the other hand, the core network bearer service comprises the network segment located between the CN edge node (MSC or SGSN) and the CN gateway node (GMSC or GGSN – Gateway MSC or Gateway GSN) that gives access to the external network. In this case, the QoS is based on the service provided by the backbone bearer service (whether circuit-switched or packet-switched).

5 UMTS specifications define four QoS classes, corresponding to different traffic QoS requirements (mainly, delay tolerance): · Conversational class. Here we can find audio and video communications with real time constraints derived from human interactivity. They are characterised by a very low tolerance to end-to-end delay. Some application examples falling into this category are voice and video telephony, and videoconference. · Streaming class. This class comprises applications for downloading multimedia contents (audio and video) that are reproduced on-line. Since the information transfer is unidirectional, the beginning of the reproduction can be delayed allowing the use of relatively large buffers on reception (able to absorb delay fluctuations). This makes the delay constraints (to be imposed to the bearer services) significantly less tight than in the conversational class. · Interactive class. Remote access applications, in which a human or a machine sends requests to a distant server and waits for an answer in a “reasonable” time, fall into this category. For instance, web browsing, database access or remote terminal emulation can be considered as interactive class applications. · Background class. This is the category into which we can classify a whole range of data applications for which delay is not a concern. Actually, and depending on the concrete application, users can tolerate end-to-end delays ranging from a few seconds to several minutes. Typical applications pertaining to this class are email and background file transfer. UMTS QoS formalization is based on a group of attributes, defined in specification TS 23.107 together with the associated value ranges, both for UMTS and RAB services. Table 1 shows the attributes defined for UMTS bearer service. As it can be seen, not all the attributes are applicable to all QoS classes.

Table 1: QoS attributes defined for UMTS bearer service

Conversational Streaming Interactive Background

Maximum bitrate x x x x Delivery order x x x x Maximum SDU size x x x x SDU format information x x SDU error ratio x x x x Residual bit error ratio x x x x Delivery of erroneous SDUs x x x x Transfer delay x x Guaranteed bit rate x x Traffic handling priority x Allocation/Retention priority x x x x

TS 23.107 also proposes a general architecture where the main QoS-related functions can be identified. It is a generic framework that leaves all implementation issues open, as well as the concrete location of most of the functions. We can infer that the 3GPP proposes a relatively open architecture, with a great amount of aspects that need to be evaluated and decided when it comes to deploy a real network. In the next sections we approach some of the existing alternatives for several of these open issues. In particular, we will focus our attention on the UMTS access network.

III. UTRAN DIMENSIONING

Using ATM (a packet switching technology) inside the UMTS access network makes a great difference if we compare it with the circuit switching paradigm used in current 2G systems. This

6 affects the dimensioning methodology, since classical Erlang models are no longer useful in this new scenario. UTRAN dimensioning should, instead, be inspired in the models developed for multi-service networks with QoS requisites. However, and despite the achievements made during past years, this is a field in which there is still a certain lack of experience. A rigorous problem approach must take many factors into consideration. Between them, we could consider the following: · The traffic load to be supported by each interface, including all the possible contributions (user traffic, signalling, OAM [Operation and Maintenance], header overhead, etc.). · Source traffic parameters, for the different traffic classes (such as peak and average rates, activity factor, etc.). · QoS requirements related to each traffic type (mainly loss and delay tolerances). · Different traffic multiplexing strategies over ATM and the possible statistical multiplexing gain achievable with each of them. · Traffic management policies (connection admission control, traffic priorities, congestion control, etc.). An analytical solution including all these aspects in detail could be intractably complex. Consequently, many times simplified analytical models used are used (e.g. models with a few activity states or fluid flow models), or a simulation approach is chosen. In the next paragraphs we give some possible guidelines regarding how the mentioned factors could be treated in a practical way.

A. Traffic Load Knowing the traffic demand a network will have to satisfy is an essential starting point when it comes to the dimensioning of its resources. In the case of UMTS, its multi-service nature makes it appropriate to separate traffic characteristics for the different services, or at least, for the different traffic classes. Traffic considerations to be applied in UTRAN have to be in harmony with those applied in the radio planning phase. Radio planning process takes several input factors, such as traffic forecasts and coverage area necessities. Its principal output is the determination of the number and location of base stations necessary to give service to a geographical area. Since the bottleneck of a cellular system is typically located at the air interface, it seems reasonable to adopt as a first criterion for UTRAN dimensioning its capacity to absorb (almost) all the traffic that the air interface is able to serve. In addition to users’ applications, there are other traffic sources: mobile to network signalling, UTRAN signalling (i.e. NBAP, RNSAP and RANAP) and management traffic (OAM). Also, in the case of Iub and Iur interfaces, soft handovers statistically increment the offered load. This contribution is usually applied as a percentage of user traffic, or as a constant contribution for each node (Node-B or RNC, depending on the interface). When performing the relevant calculations, overheads related to the several UTRAN protocols have to be included.

B. Traffic Models There are several studies proposing or using traffic models for 3G mobile networks scenarios (see references [14] to [20]). Nevertheless, we have found no article in the literature in which all the four traffic classes defined for UMTS (conversational, streaming, interactive and background) are jointly treated and adapted to the terrestrial interfaces of UTRAN. In this subsection a traffic model is proposed that we think is appropriate for UTRAN interfaces dimensioning. This model is applicable (with different parameters) to the four UMTS QoS classes, and is able to represent variable rate sources. Rate variability is found in many real life applications, and its inclusion into the model will allow us to evaluate the effect of statistical multiplexing during the dimensioning phase. We focus our study in the UTRAN ATM transport network. Thus, traffic models should consider not only the actual application behaviour, but also the relevant characteristics of the radio network layer

7 protocols. Also, in the case of asymmetric applications, we implicitly model the downstream flow, since this is the direction in which the majority of the traffic is normally observed. The model we propose is structured in three levels, in harmony with several of the revised studies (for instance, [18], [20] and [21]). As it can be seen in Figure 7, the defined levels are: · Session level. User sessions are modelled at this level (for instance, voice calls, or web browsing sessions). Relevant parameters at this level are the session arrival process and session duration statistical distributions. If, as a result of radio planning phase, there is information about the number of simultaneously active users for each traffic class and base station during busy hour, this level could be abstracted (i.e. we could suppose that all considered users are inside an active session). · Burst level. When a user is inside an active session, its traffic generation pattern is modelled via two activity states, that we will call “High” and “Low” states. Each one will have its own packet generation characteristics (as we will see in next paragraph). It is enough to provide the statistical distributions for each state’s duration in order to completely characterize this level. · Packet level. At this level we can specify the statistical process governing packet generation, for each of the previous level states. Two significant statistical distributions are defined, describing packet arrival process and packet size.

Time between session arrivals Session duration

Session

High state Low state duration duration

Burst

Time between packets, Time between packets, High state Low state Packet size, Packet size, High state Low state

Packet

Figure 7: Three-level source model

We propose to choose a significant application of each traffic class, in order to concrete the values of the mentioned parameters. For instance, paying attention to the examples shown in several 3GPP specifications (among them, TS 23.107 [13] and TS 22.105 [22]), we could choose the following set of representative applications: voice (AMR codec [23]) for conversational class, video streaming for streaming class, web browsing for interactive class, and email as an example of background traffic. Table 2 shows an example of the traffic characterization parameters defined so far, for voice and web applications. These values are applicable for Iub and Iur interfaces, and all protocol overheads (up to, but not including, AAL2) have been considered. The exact figures have been calculated using information and indications present in several 3GPP documents, and ETSI recommendations (specifically, ETSI technical report TR 101 112 [21]). Session level is not included in the example, assuming it has already been considered during radio planning phase.

8 Table 2: Traffic characterization parameters (examples for voice and web) Voice Web Burst level exponential geometric High state duration mean: 3 s. mean: 1.5 s. exponential geometric Low state duration mean: 3 s. mean: 412 s. Packet level Time between packet constant constant arrivals value: 20 ms. value: 40 ms. (High and Low states)2 constant constant Packet size, High state value: 40 octets. value: 325 octets. constant constant Packet size, Low state value: 13 octets. value: 0 octets.

C. QoS Parameters Each traffic class imposes a set of requisites to be satisfied by the network. In order to do so, each network element and interface should be carefully dimensioned. Among the set of QoS parameters that UMTS specifications define, there are two that clearly affect UTRAN dimensioning: error ratio and maximum transfer delay (this last one is applicable to the two real time QoS classes, conversational and streaming). Possible starting values for these two parameters can be obtained from the RAB service indications contained in specification TS 23.107 [13]. These parameters have to be adapted to partial requisites for each access network interface, in order to obtain figures directly applicable to the dimensioning of those interfaces. This way, technical report TR 25.853 [24] provides a good basis for the adaptation of transfer delay, since it shows the different delay components for the RAB service (in the case of real time services). We propose to use the values given in the report, adapting them to the specific network circumstances (e.g. regarding the number of ATM switches in each interface), except for the so-called multiplexing and de-multiplexing delays. The reason for excluding them is that those delays depend on the service mix, the interfaces load, their capacity, the type of ATM channels and the multiplexing strategies adopted (i.e. they depend on the chief design inputs and strategie s). This way we can obtain an upper limit for the multiplexing and de-multiplexing delay on each interface. That limit is the figure that, added to the rest of the delay components, makes the total delay for the RAB service be the maximum possible value (stated in TS 23.107). When it comes to adapt the permissible delay, one should consider the possibility of performing error recovery methods (frame retransmissions) by RLC (Radio Link Control) protocol, between mobile termination and its serving RNC. These mechanisms are not used in the case of conversational traffic, since its delay requirements are too tight. However, in [13] we can read that the delay bounds applicable to streaming bearers, in certain ranges, could allow the presence of RLC retransmissions. Respecting the second of the main QoS parameters already mentioned (error ratio), our objective, since we are considering ATM technology, is to find the CLR (Cell Loss Ratio) figure to be respected on each interface. In a similar way as for the delay requisite, we can start from the maximum error ratio admissible for RAB service (from TS 23.107) and progressively adapt it. To do so, several factors should be taken into account, between them: · In occasions a certain error ratio has to be separated into two adjacent physical sections. In this case, if both error probabilities are significantly less than one (this is the case in which the

2 This time has been chosen to be constant, and equal to the TTI (Transmission Timing Interval), since this is the interval between information blocks accepted by the radio physical layer. Actual values have been derived from recommendations found in several papers and specifications.

9 whole system can be in a “usable” situation), the joint error probability can be approximated by the sum of the figures for each section. · If a certain protocol performs SDU (Service Data Units) segmentation and/or concatenation functions, a PDU (Protocol Data Unit) error provokes in general more than one SDU errors, as can be seen in Figure 8. For instance, this kind of processing is typical of AAL2 protocol, for the transmission of variable -length SDUs over fixed-length ATM cells. · Clearly, error detection or correction mechanisms that may be used by several protocols would allow relaxing error ratio limits imposed to lower layers. At this respect, in the case of UTRAN, the possible presence of RLC-level retransmissions should be considered.

Affected SDUs ......

Hdr. Hdr. ...

Erroneous PDU Figure 8: Effects of segmentation and concatenation of SDUs on error ratio

D. Multiplexing Strategies and Channel Types At this point it should be clear that traffic differentiation capabilities at ATM and AAL levels have a determinant influence in the QoS that UTRAN is able to provide. This way, in [16] the two basic methods for differentiating traffic inside AAL2/ATM transport network are explained: AAL2-level differentiation, and ATM-level differentiation. Focusing on UTRAN case, these methods could be applied at Iub, Iur and Iu-CS interfaces. Figure 9 illustrates them, supposing the presence of only two types of services.

AAL2 differentiation

Service 1 AAL2 Mux. Service 2 ATM Channel

AAL2 ATM differentiation Service 1 Mux. ATM Ch. 1 ATM Mux. AAL2 Service 2 Mux. ATM Ch. 2 Figure 9: Basic traffic differentiation methods

We can summarize the basics of each of the mentioned mechanisms in the following manner: · AAL2-level differentiation. AAL2 multiplexer includes a traffic differentiation mechanism (such as a scheduler capable of giving different treatment to different services). Having done so, all the traffic is sent over the same ATM channel (consequently, no ATM traffic

10 management is used in this case). As indicated in report TR 25.934 [25] (first appeared in UMTS Release 4), currently there is no standardized framework for providing QoS at AAL2 level in ITU-T recommendations. However, proprietary or non-standardized mechanisms could be used, and in fact there are a number of papers in which concrete techniques are proposed and analysed (see for instance [15], [17], [26] and [27]). · ATM-level differentiation. In this case there is conceptually a separate AAL2 multiplexer dedicated to each traffic class. Thus, AAL2 level differentiation is useless. However, the output traffic of each multiplexer will be carried over its own ATM channel, specifically parameterised for that service type. That is, ATM-specific traffic management mechanisms are in charge of traffic differentiation. · Differentiation at both levels. There are some authors (not a majority) that mention or propose as a possibility to perform traffic differentiation both at AAL2 and ATM levels simultaneously (see [16] and [17]). As a first approach to the QoS provisioning in UTRAN, we propose to use the second of the above mentioned methods (ATM differentiation), since it is currently the only alternative fully standardized. Figure 10 shows this alternative particularized for the case of Iub interface. Since different ATM channel types provide different QoS guarantees, a possible choice is to dedicate a separate ATM channel, adequately dimensioned, to each user traffic class. Additionally, signalling traffic could also have a dedicated ATM channel, considering its vital importance for correct network operation.

Node-B RNC Iub

VCC1 ATM virtual Voice channel VCC2 Data ... VCCn ... AAL2 Signalling connection Figure 10: ATM level QoS differentiation

The type of traffic contract to be used for each traffic class is other of the aspects to determine. There are a number of possibilities at this respect. To mention one of them, it seems reasonable to use CBR channels for voice and in general for traffic requiring a high isolation degree due to its delay constraints [15]. Variable rate channels (rt-VBR or nrt-VBR traffic contracts) could be a good choice for streaming and interactive classes. And background class seems an ideal candidate to be carried over a UBR channel, since it has no specific delay requirements. Each ATM virtual channel connection (VCC) can carry up to 248 independent AAL2 connections, each of them corresponding to one user’s traffic. If the rate offered by each user is not constant, this multiplexing of AAL2 connections into an ATM VCC could exhibit statistical multiplexing gain behaviour, and consequently bandwidth savings might be achieved. When analytically estimating the total required bandwidth, fluid flow models are a good and simple tool ([28] and [29]). We can see the kind of results that such tools are able to provide in the example of Figure 11. The graph shows the number (N) of ON-OFF3 sources that a link can carry, as a function of C/h, where C is the link capacity and h is the peak rate of each source. Several curves are showed, for different activity factor (á) and loss factor values.

3 There are also fluid flow approximations for “High-Low” sources, similar to those introduced in section III. They yield similar results as the ones shown.

11 -3 -4 -5 -3 -4 -5 10 10 10 10 10 10 70

65 -3 10 60 -4 10 aa = 0,5 -5 55 10 aa = 0,3 50

OFF sources (N) 45 - aa = 0,7 40

Nº de fuentes on-off admisible (N) 25

20 Maximum no. of ON

10 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48 50 No = C/h (capacidad disponible tomando como unidad h) C/h (available capacity taking h as unit) Figure 11: Fluid flow approximation for interface dimensioning

A first conclusion obtained from Figure 11 is that, given a certain activity factor and loss tolerance, required capacity is less than the sum of the peak rates for all the sources (represented as a discontinuous line). This bandwidth saving (equivalently, the statistical multiplexing gain) is higher for lower values of activity factor and loss requirements tightness. To give a numerical example, lets us suppose a Node-B that gives service to 1500 voice subscribers4, each of them generating an average load of 20 mE at busy hour. If the maximum blocking probability at radio interface is 1% we need 42 voice circuits, according to Erlang-B model. If the activity factor of each voice user is estimated to be 50%, and the admissible loss ratio at Iub is 10-4 (i.e. one voice frame lost each 200 seconds), from Figure 11 we infer that on Iub it would be enough to reserve a capacity equivalent to 30 voice peak rates. This gives a bandwidth saving of 29%, as an effect of statistical multiplexing.

IV. TRANSMISSION NETWORK DEPLOYMENT

A. Transmission Interfaces Any of the “traditional” solutions adopted for other types of transmission networks can be chosen for its use at UTRAN: coaxial cable, optical fibre and radio links. Thanks to the existence of numerous normalized ATM interfaces, transmission schemes over those link technologies can be the regular PDH (e.g. E1 or E3) or SDH (e.g. STM-1) solutions. In the initial UMTS deployment phase, one of the main interface types to be used inside UTRAN could be PDH. In particular, for cells with low traffic, it could be possible to choose E1 (2048kbps) interfaces. For more heavily-loaded cells, an E3 (34Mbps) interface could be used. However, this bit rate is probably too high in most of the cases. As an alternative, IMA (Inverse Multiplexing ATM) technique can be applied over several E1 interfaces, in order to better adjust the deployed capacity. An IMA interface allows using a set of E1 interfaces as if they were a single ATM interface. This “fictitious” ATM interface has a capacity that is nearly the sum of all the E1 interfaces capacities. Figure 12 shows how an IMA interface functions.

4 Instead of using the characterization parameters of Table 2, we will suppose that each voice user exhibits ON-OFF behaviour in order to directly apply the curves shown in Figure 11.

n x E1

1 1

2 2 4 3 2 1 4 3 2 1 3 3

4 4

Figure 12: IMA interface

In case higher capacity ATM interfaces are needed, ATM over SDH can be an option (for instance, STM-1 interfaces, at a binary rate of 155Mbps). The necessity of this kind of interfaces should grow as the traffic concentration degree rises, inside the interconnection network between Node-Bs and RNCs, and also in the case of the Iu interface (connecting RNCs and the core network).

B. Transmission Network Topology Several alternatives also exist regarding the access network topology for interconnecting Node-Bs, RNCs, and core network nodes (MSC/SGSN). Figure 13 shows some of the configurations most normally used in the context of cellular networks. From an economical point of view, interconnection topologies that allow high degrees of traffic concentration are especially attractive. For instance, disposing Node-Bs in a chain for connecting them to an RNC might lead to a significant bandwidth saving. This is especially true if each base station’s load is relatively low, which could be the case for rural UMTS cells, of even for most of UMTS cells during the initial deployment phases.

Chain

RNC Star Node-B Node- B Node-B RNC Node-B Node- B Node- B

Node -B Ring Mixed RNC Node-B

Node- B Node -B Node-B

Node- B Node-B RNC

Node- B Node -B Node- B Node-B Figure 13: Examples of UTRAN topology configurations

Traffic concentration in UTRAN could be done by independent auxiliary equipment or by equipment integrated into Node-Bs. A first approach could be to concentrate traffic at PDH level, using DXXs (Digital Cross Connects). Nevertheless, this does not allow benefiting from ATM-level traffic concentration. To take advantage of it, it is more convenient to introduce equipment capable of performing ATM-level multiplexing, such as ATM multiplexers and switches. Moreover, if Node-Bs include these functionalities, no additional equipment would have to be used. Figure 14 shows a possible UTRAN transmission network topology for initial deployment stages. E1 interfaces are used for Node-Bs, since we have supposed low initial traffic loads. In occasions, a Node-B could act as a traffic concentrator for a set of Node-Bs, giving a total number of E1 interfaces lower than in the case of a star topology.

13 Also, as indicated in the figure, intermediate ATM switches can be used to achieve a higher degree of traffic concentration. These ATM switches might be a good option to connect several Node-B branches to a common and distant RNC, and also to concentrate the traffic flowing between groups of RNCs and the core network.

To Core Network To Core

E1 Network E1 RNC STM-1 E1 E1 n x E1 ATM STM-1 ATM n x E1 E1 RNC E1 E1 RNC E1 RNC 2xE1 n x E1 E1 E1 E1 ATM E1 ATM E1 E1 2xE1 E1 2xE1 E1 E1 E1

n x E1 n x E1 ATM n x E1 E1 E1 2xE1 E1

ATM E1 RNC E1

2xE1 E1 ATM E1 E1 2xE1 E1 Figure 14: UTRAN topology example

V. CONCLUSIONS AND FUTURE WORK

In this paper we have given a practical approach to the general issue of UMTS access network dimensioning. Taking resource optimization and QoS support as objectives, we have analysed the main parameters and design alternatives to be considered in a real deployment scenario. The starting point of our work has been the proposal of a traffic model suitable for the four UMTS traffic classes (conversational, streaming, interactive and background) defined by 3GPP. We have also identified the main QoS constraints (loss and delay) for each application type. Both aspects are inputs for the UTRAN dimensioning process. In order to make an efficient use of UTRAN transmission interfaces, several multiplexing strategies have been considered, both at ATM and AAL2 layers. Using a simplified analytical model we have obtained an estimation of the statistical multiplexing gain that can be achieved. However, we think that a more rigorous treatment of the problem should be performed. In line with this, we are currently developing a simulation model for UTRAN. Finally, we have also presented some practical considerations about possible UTRAN transmission network topologies. In particular, we have analysed some examples of topologies that could provide traffic concentration, thus leading to possible bandwidth savings.

REFERENCES

[1] UMTS Forum. “The UMTS Third Generation Market Study Update”. Report from the UMTS Forum No. 17, August 2001. [2] Dimitriou, N.; Tafazolli, R.; Sfikas, G. “Quality of service for multimedia CDMA”. IEEE Communications Magazine, Vol. 38, Issue 7, pp. 88–94, July 2000. [3] Lister, D.; Dehghan, S.; Owen, R.; Jones, P. “UMTS capacity and planning issues”. First International Conference on 3G Mobile Communication Technologies, pp. 218–223, March 2000.

14 [4] Parsa, K.; Ghassemzadeh, S. S.; Kazeminejad, S. “Systems Engineering of Data Services in UMTS W-CDMA Systems”. 2001 IEEE International Conference on Communications (ICC2001). Helsinki (Finland), June 2001. [5] Holma, H.; Toskala, A. “WCDMA for UMTS: Radio Access for Third Generation Mobile Communications”. John Wiley & Sons, 2000. [6] 3GPP. “General UMTS Architecture”. 3GPP TS 23.101. December 2000. [7] 3GPP. “3rd Generation mobile system Release 1999 Specifications”, 3GPP TS 21.101, March 2002. [8] 3GPP. “3rd Generation mobile system Release 4 Specifications”, 3GPP TS 21.102, March 2002. [9] 3GPP. “3rd Generation mobile system Release 5 Specifications”, Draft 3GPP TS 21.103, March 2002. [10] 3GPP. “IP Transport in UTRAN”. 3GPP TR 25.933. March 2002. [11] 3GPP, “UTRAN General Overview”, 3GPP TS 25.401, March 2002. [12] ITU-T Recommendation I.363.2. “B-ISDN ATM Adaptation layer specification: Type 2 AAL”. November 2000. [13] 3GPP. “QoS Concept and Architecture”. 3GPP TS 23.107, March 2002. [14] Valko, A. G.; Racz, A.; Fodor, G. “Voice QoS in Third-Generation Mobile Systems”. IEEE Journal on Selected Areas in Communications, Vol. 17, No. 1, pp. 109-123, January 1999. [15] Isnard, O.; Calmel, J.-M.; Beylot, A.-L.; Pujolle, G. “Handling Traffic Classes at AAL2 / ATM layer over the Logical Interfaces of the UMTS Terrestrial Access Network”. 11th IEEE International Symposium on Personal, Indoor and Mobile Radio Communic ation, Vol. 2, pp. 1464- 1468, London (England), September 2000. [16] Eneroth, G.; Fodor, G.; Leijonhufvud, G.; Rácz, A.; Szabó, I. “Applying ATM/AAL2 as a Switching Technology in Third-Generation Mobile Access Networks”. IEEE Communications, Vol. 37, No. 6, pp. 112-122, June 1999. [17] Yoo, S.-K.; Park, H.-S. “Quality-of-Service Provisioning for Mobile Voice and Data Services over ATM Network using AAL2”. 3rd ICACT, Muju (Korea), February 2001. [18] Reyes-Lecuona, A.; González-Parada, E.; Casilari, E.; Casasola, J. C.; Díaz-Estrella, A. “A page- oriented WWW traffic model for wireless system simulations”. Proceedings of the 16th International Teletraffic Congress (ITC'16), pp. 1271-1280, Edinburgh (United Kingdom), June 1999. [19] Staehle, D.; Leibnitz, K.; Tran-Gia, P. “Source Traffic Modeling of Wireless Applications”. International Journal of Electronics and Communications, Vol. 55, Issue 1, 2001. [20] Klemm, A.; Lindemann, C.; Lohmann, M. “Traffic Modeling and Characterization for UMTS Networks”. Proc. of the Globecom, Internet Performance Symposium, San Antonio TX, November 2001. [21] ETSI. “Universal Mobile Telecommunications System (UMTS); Selection procedures for the choice of radio transmission technologies of the UMTS”. TR 101 112 V3.2.0. April 1998. [22] 3GPP. “Services and Service Capabilities” .3G TS 22.105. [23] 3GPP. “AMR Speech Codec; General Description”. 3G TS 26.071. [24] 3GPP. “Delay Budget within the Access Stratum”. 3GPP TR 25.853. [25] 3GPP. “QoS optimization for AAL type 2 connections over Iub and Iur interfaces”. 3G TR 25.934. [26] Lim, H.; Lee, S.; Lee, D.; Kim, K.; Song, K.; Oh, C. “A New AAL2 Scheduling Algorithm for Mobile Voice and Data Services over ATM”. ITC-CSCC 2000, vol. 1, pp. 229-232, Pusan (Korea), July 2000. [27] Wu, J.-L.C.; Huang, C.-H.; Sheu, R.-T. “Performance study of AAL2 protocol for low-bit-rate multimedia services”. 15th International Conference on Information Networking, pp. 793–798, 2001. [28] McDysan, D. E.; Spohn, D. L. “ATM Theory and Applications”, McGraw-Hill, 1999. [29] Hersent, O.; Gurle, D.; Petit, J.-P. “IP Telephony. Packet-based multimedia communications systems”, Addison-Wesley, 2000.