section seven

©Informa Telecoms

The UMTS Terrestrial Radio Access network – General

UMTS System Overview

The UMTS Terrestrial Radio Access Network – General

UMTS Terrestrial Radio Access Network – General

1. THE UMTS TERRESTRIAL RADIO ACCESS NETWORK – GENERAL1.1 Requirements of the UTRAN 11.2 Functions of the UTRAN 3

2. UTRAN ARCHITECTURE2.1 UTRAN Architecture – General 72.2 The Node B 92.3 The RNC 112.4 RNC Terminology 132.5 Controlling RNC Functions 152.6 Serving RNC Functions 152.7 Drift RNC Functions 15

3. THE UTRAN INTERFACES AND PROTOCOLS3.1 General Protocols Architecture 173.2 General Protocol Model 193.3 Radio Network Layer Protocols 213.4 UTRAN Protocols – Fitting Them Together 233.5 RRC Idle Mode 233.6 RRC Connected Mode (1) 253.7 RRC Connected Mode (2) 273.8 Functions Of The UTRAN Protocols 29

4. HANDOVERS4.1 Softer Handover 314.2 Soft Handover 33

5. THE TRANSPORT NETWORK5.1 Requirements Of The Transport Network 355.2 The Options 355.3 ATM Operation 375.4 The ATM Cell 395.5 ATM and Quality Of Service 415.6 Use Of ATM In The UTRAN 43

6. ANNEX A6.1 A1 TRANSPORT NETWORK LAYER PROTOCOLS 47

©Informa Telecoms




1. THE UMTS TERRESTRIAL RADIO ACCESS NETWORK – GENERAL

1.1 Requirements of the UTRAN

In defining the UMTS Terrestrial Radio Access Network (UTRAN), a number ofrequirements and assumptions were identified. These are specified to ensuremaximum flexibility in the future evolution of the UMTS concept, and to ensure easyevolution to the UMTS concept from second generation networks. In addition, theyprovide flexibility in accessing the core network from not only the UTRAN, but fromevolved GPRS/EDGE GSM networks, Satellite access networks, fixed access(narrowband and broadband), and future access types such as the Broadband RadioAccess Network.

The UTRAN is considered a separate entity to the core network, with a definedinterface connecting them. This interface is designed to provide a logical separationof signalling and user data transport (this fits in with the evolved GSM networkspecified for use in UMTS at Release 99). The interfaces are designed to be fullyspecified, allowing as few options as possible and based on the logical model of theentities concerned. This ensures maximum compatibility between manufacturers.

All radio procedures and aspects are fully handled within the UTRAN, includingmobility of the radio connection (soft handover, relocation of serving entities etc.).This allows replacement of this radio access network with another access technology,fulfilling one of the basic requirements.


©Informa Telecoms1

CORENETWORK

UTRAN

Fig. 1 – Requirements of the UTRAN

2©Informa Telecoms

• Logical Separation of Signalling and Data Transport• CN and UTRAN functions separate from Transport Functions• Macro diversity fully handled in UTRAN• Mobility for RRC connection is fully controlled by UTRAN• Interfaces based on logical model of the entities (with as few functional options

as possible).


1.2 Functions of the UTRAN

UTRAN functions have been specified to provide support for all radio activitiesneeded within the network infrastructure. They can be split into four main areas –System Access, Mobility, Radio Channel Ciphering, and Radio ResourceManagement and Control.

System access functions involve broadcasting system information to allow themobile to configure for access, admission control and radio channel congestion.

Mobility functions within the UTRAN are extensive in that they comprise handovers,Serving Radio Network Controller (SRNC) relocations, and additionally, UTRANRegistration Area (URA) and Cell updates for packet mode procedures. These areused so that the UE can fall back to a less active state whilst retaining its packet data“virtual connection”, known as a Packet Data Protocol Context (which describes thequality of service required as well as specifying the address). In this case, the mobileis tracked at URA or Cell level and paged accordingly when required to receive data.

Radio channel ciphering occurs in the UE and Serving RNC (at the RLC or MAClayer), unlike GSM, where only the air interface is ciphered.


©Informa Telecoms3

UTRAN FUNCTIONS

Radio ChannelCiphering andDeciphering

Systems AccessControl (Admission,

Congestion,System information

broadcast)

Radio Resource Management and

Control

Mobility(Handover, SRNS

Relocation)

Fig. 2 – UTRAN Functions

4©Informa Telecoms

©Informa Telecoms5


Radio resource management and control functions are very comprehensive, coveringall necessary activity to provide, monitor, maintain, and release the radio resourceswhen required. This includes the control and assignment of codes.

Measurement and quality estimates are made with the User Equipment assisting inproviding measurement reports. As a consequence, Radio Frequency power settingand control can be achieved with the necessary accuracy to ensure the requiredquality of service is achieved whilst minimising overall system interference.

The higher layer signalling messages are also supported by the UTRAN in so far asthey are distributed to the correct Core Network Domain (MSC or SGSN).

For FDD mode, Macro-diversity (enabling soft handover between Node Bs), isprovided by the RNC’s ability to receive signals from different Node Bs (whichthemselves may be a combined signal). The signals are assessed, and the best one ischosen for inclusion into the combined signal. The selections are made on a regularbasis (10 – 80 ms). This introduces an overall gain into the system, allowing therequired quality of service to be provided at a lower power.

Note that for micro-diversity (softer handover), the Node B uses the Rake Receiver tocombine the signal from different cells or sectors (in the same way that the Rake isused to combine different multi-path components).


Radio Resource Management and Control

Systems Access Control (Admission, Congestion, System information broadcast)

RadioChannel

Ciphering and

Deciphering

Mobility(Handover,

SRNSRelocation)

UTRAN FUNCTIONS

Fig. 3 – UTRAN Radio Resource Management and Control Functions

6©Informa Telecoms

• Radio resource configuration and operation• Radio quality estimates• Radio Bearer Control (allocation, deallocation, set-up and release)• Radio protocols provision• RF power setting and control• Radio channel coding and decoding (and control of coding)• Random access detection and handling• Distribution of Non Access Stratum messages to required Core

Network domain.

FDD Only• Macro diversity

TDD Only• Dynamic Channel Allocation


2. UTRAN ARCHITECTURE

2.1 UTRAN Architecture – General

The UTRAN architecture comprises of one or more Radio Network Controllers(RNCs), each controlling a number of base sites, known as Node B. Each grouping ofRNC and its associated Node Bs are collectively known as a Radio Network Sub-system (RNS). Hence an UTRAN is comprised of one or more RNS.

Standard interfaces connect each RNS to the Core Network (both Circuit Switchedand Packet Switched Domains), and to the User Equipment. These interfaces areknown as IuCS, IuPS, and Uu respectively.

The UTRAN internal interfaces are also standardised. The Iur connects RNC (andhence RNS), whilst the Iub connects the RNC and Node B.


©Informa Telecoms7

Radio Network Controller

Iur

Iu (CS & PS)

Radio NetworkSub-system

(RNS)

RNC RNS

Iub

Node B

CORE NETWORK

Fig.4 – UTRAN Architecture and Terminology

8©Informa Telecoms

©Informa Telecoms9



2.2 The Node B

The term Node B refers to the base station equipment which communicates with thesubscriber’s handset via the radio link (and of course with the main network via atelecoms link).

It provides radio resources for a UMTS network, and uses UMTS channel allocation tocommunicate with the handset. It provides all the RF processing, enablingtransmission and reception information to and from the mobile terminal. Thisinformation is encoded using the W-CDMA scheme.

A single UMTS channel can be used on adjacent Node B sites and in different sectorsof the same Node B antenna system. A typical Node B may support a three sectorantenna and one or two UMTS carriers, although it is possible to configure up to sixsectors and up to three UMTS carriers. Each sector can be used as a different cell.

Node B tasks are as follows:

• conversion of data to and from the radio interface

• forward error correction

• rate adaptation

• W-CDMA spreading & despreading

• QPSK modulation (Quadrature Phase Shift Keying)

• measuring the quality & strength of connection

• determining the frame error rate

• handover between different sectors on the same Node B (“softer handover”)

• participation in power control, enabling the user terminal to adjust its power (“innerloop power control”)

10©Informa Telecoms

NODE BFUNCTIONS

• Radio Resource Provider• W-CDMA spreading

and despreading• QPSK Modulation• Signal quality & strength

measurement• Inner loop power control

• May support multiple cellsthrough sectored antenna

• Supports Softer Handover

• Converts data to/from W-CDMA transport• Forward error correction and frame error

rate determination• Rate adaptation

Fig. 5 – Node B Functions

©Informa Telecoms11



2.3 The RNC

The RNC controls the operation of multiple Node Bs, managing resources such as allocating capacity for data calls, and providing critical signalling such asconnection set-up, plus switching and traffic routing functionality.

Compared to 2G systems, it is broadly equivalent to the BSC, but also includes somefunctionality of the MSC. In particular, it enables autonomous Radio ResourceManagement by the UTRAN by allowing RNCs to directly communicate (via the Iurinterface), eliminating this burden from the core network. So all handover processes,even where moving between cells controlled by different RNCs, are kept within theUTRAN. Compare this with the situation in GSM, where handover between differentBSC areas required involvement of the MSC, and hence the core network.

The RNC can manage many Node Bs, and allocates radio resources and maintainsthe equilibrium of a live and dynamic network. It must also interface with the corenetwork to provide access to the network operator services, applications, Internetand gateways to networks such as GSM and PSTN.

The Iub is the first example of a fully standardised base-station-to-controller interfacewithin commercial mobile networks, and is defined thus in order to increasecompetition between manufacturers in this very costly part of the network. Forexample it is now possible to source Node B and RNC equipment from differentvendors, and hence for specialist vendors for Node B only, for example, to enter themarket.

The key features of the RNC are:

• management of radio resources

• channelisation code allocation

• QoS monitoring

• handover of users between cells on the same site (softer handover)

• handover of users between cells on different sites (soft handover)

• handover of users between different UMTS carriers (hard handover)

• handover of users to GSM networks (hard handover)

• power control management of user and Node B equipment

• network alarm correlation


RNC

CN

Node B

Fig. 6 – The RNC – General Functionality

• Controls functions of multiple Node Bs• Radio resource management kept within the UTRAN• Interfaces with core network• Manages handover• Power Control Management




2.4 RNC Terminology

The RNC operates in three main modes – Controlling, Serving, and Drift, dependingon whether an RRC connection is established, and how it is configured. Thedescriptions of each mode are with respect to a single User Equipment, since eachphysical RNC contains all the functionality needed for all three modes and is likely tobe acting in different modes with respect to different UE.

Controlling RNC

When mobiles are in idle mode, no RRC connection exists. Hence this mode simplydescribes the functionality of the RNC which controls the Node B on which themobile is camped (i.e. the selected Node B). Any RRC messages relevant to the UEare terminated at the UE and Node B.

Serving and Drift RNC

Once a mobile enters the RRC Connected mode, an RRC connection exists, andRRC messages relevant only to the UE are terminated at the UE and Serving RNC(SRNC).

In Soft Handover, the mobile is effectively served by two or more Node B. In the casewhere the Node B are connected to different RNC, the Serving RNC remains as theonly Serving RNC, whilst the new RNC (now called the Drift RNC, or DRNC) simplyprovides the radio resources necessary for the added radio link, and acts to carry theRadio Resource messages and user data between the SRNC and UE transparentlyover the Iur and Iub interfaces on the relevant channels.

As a result of Soft Handover, the original radio link may be deleted from the "activeset" of links, leaving the Serving RNC without any of its Node B in the active set. Inthis case, the DRNC could become the SRNC by a process called SRNC relocation.This procedure is considered optional.

If another RNC is involved in the active connection through soft handover, it isdeclared a Drift RNC. The Drift RNC is responsible only for the allocation of coderesources, with the original Serving RNC continuing to handle control functions suchas admission, radio resource control, congestion, handover and so on.

It is possible to reallocate the Serving RNC to the former Drift RNC, if this becomesnecessary.


Fig. 7 – RNC Terminology

CoreNetwork

ControllingRNC

MSC/VLRor SGSN

NodeB

"Idle" Mode

"Connected" Mode(After Soft Handover)

SRNC Relocation(Optional)

"Connected" Mode

CoreNetwork

ServingRNC

MSC/VLRor SGSN

NodeB

Soft Handover

CoreNetwork

ServingRNC

MSC/VLRor SGSN

NodeB

DriftRNC

NodeB

CoreNetwork

ServingRNC

MSC/VLRor SGSN

NodeB

DriftRNC

NodeB

CoreNetworkRNC MSC/VLR

or SGSNNode

B

ServingRNC

NodeB


2.5 Controlling RNC Functions

The CRNC controls one or more Node B. In practice, this is likely to be tens of NodeB. It is responsible for loading and congestion of cells, as well as allocating codesand controlling admission. System information broadcasts for mobiles in idle mode(or packet switched cell or URA paging modes) are originated from the controllingRNC.

2.6 Serving RNC Functions

The radio bearers and signalling radio bearers for mobiles in connected mode areterminated here (as well as in the User Equipment). All layer two (data link) processingof information to/from the radio interface is processed here for UE in connected mode(layer 1, the physical layer, is provided by the node B).

Outer loop power control is supported as well as the handover decisions.

Each User Equipment will have only one SRNC. The Serving RNC will often also bethe Controlling RNC for the Node B used by the mobile.

2.7 Drift RNC Functions

The DRNC is any RNC other than the SRNC which controls cells currently used bythe mobile. There may be zero, one or more DRNC at any one time for the specifiedmobile. The DRNC may itself be performing macro-diversity combining and splittingin support of Soft Handover.

No layer 2 processing of the data destined for, or received from, the radio interface isperformed in the DRNC.




Fig. 8 – Controlling, Serving and Drift RNC Functions

Controlling RNC (CRNC)

• Controls one or more Node Bs.• One Node B will have only one CRNC.• Controls load and congestion of own cells.• Executes admission control and code allocation for new radio links.

Serving RNC (SRNC)

• Terminates Radio Bearers and Signalling Radio bearers for the mobile (ie RRC is terminated here in RRC connected mode).

• Performs Layer 2 processing of data to/from radio interface.• Controls handover decisions.• Outer loop power control.• SRNC may also be CRNC for Node B(s) used by the mobile.• Each connected UE has only one SRNC.

Drift RNC (DRNC)

• Any RNC, other than SRNC which controls cells used by the mobile.• May perform macrodiversity combining and splitting.• No layer 2 processing, unless mobile is using common or shared

transport channel.• A mobile may have one or more DRNCs.


3. THE UTRAN INTERFACES AND PROTOCOLS

3.1 General Protocols Architecture

The protocol architecture between the User Equipment and Core Network in UMTS isorganised logically into a User plane and a Control Plane. The user plane is specifiedto transport circuit switched or packet switched user information, whilst the ControlPlane is specified to handle the control information necessary to provide therequested services and features.

In general, the User and Control Planes are described here with respect to the overallsystem, and not for any individual interface.

The general organisation on each plane is that the Non-Access Stratum (theinformation which is only relevant between the UE and Core Network, irrespective ofwhich access network is between used) is specified separately to the Access Stratum(which is specific as the UTRAN access network in this case).

The model shown opposite is therefore relevant to the overall architecture (andtherefore directly applicable to the Non-Access Stratum) in terms of defining the Userand Control Planes.

The Non-Access Stratum protocols shown on the Control Plane comprise ConnectionManagement (Call Control, Short Message Service, Supplementary Services), MobilityManagement (both standard and GPRS), and Session Management (for GPRS), allpart of the evolved GSM network specifications designated for use within the firstphase of UMTS. They do not form part of the UTRAN specifications.



UTRAN

Non-Access Stratum

CNUE

Radio (Uu) Iu

Iuproto-cols

Radioproto-cols

Radioproto-cols

Iuproto-cols

Access Stratum

User Plane

Control Plane

UTRAN

Non-Access Stratum

CNUE

Radio (Uu) Iu

Iuproto-cols

Radioproto-cols

Radioproto-cols

Iuproto-cols

Access Stratum

CM, MM, GMM, SM

CM, MM, GMM, SM

Fig. 9 – General Protocols Architecture



3.2 General Protocol Model

The General Protocol Model provides a framework for considering each individualUTRAN external, or internal, interface. Since it is used to describe UTRAN interfacesonly, it does not include any Non-Access Stratum protocols (these will sit on top ofthe UTRAN General Protocol Model where required, and be seen only as "data" bythe UTRAN protocols).

The model is split into the actual UTRAN protocols layer itself, known as the RadioNetwork Layer, and the Transport Network Layer, which is specified separately.

In the Radio Network Layer (RNL), a control plane and user plane exist on eachinterface. This notation is relevant to that interface only. Hence only control dataoriginated by that particular interface (or higher layer control information carried withinfurther control information which has been originated on that particular interface) isconsidered part of the control plane. It is feasible in some circumstances for somehigher layer control information to be classed as user plane information on theinterface in question (due to not having been originated by that interface).

In the Transport Network Layer, the RNL Control Plane is provided with a SignallingBearer, which is generally a pre-configured ATM link, whilst the RNL User Plane isprovided with a Data Bearer. This is either a pre-configured ATM link (usual for packetdata user information) or set up dynamically by the (Transport Network Layer) AccessLink Control Application Part, or ALCAP, (ATM signalling). The ALCAP itself will have apre-configured signalling bearer.



RadioNetwork

Layer

TransportNetwork

Layer

ControlPlane

ApplicationProtocol

SignallingBearer(s)

TransportNetwork

User Plane

UserPlane

DataStream(s)

DataBearer(s)

TransportNetwork

User Plane

SignallingBearer(s)

ALCAP(s)

TransportNetwork

Control Plane

PhysicalLayer

Fig. 10 – UTRAN General Protocol Model


ALCAP - Access Link Control Application Part


3.3 Radio Network Layer Protocols

The UTRAN General Protocol Model has been redrawn and shown opposite togetherwith a summary of the protocols to be found on each interface at the Radio NetworkLayer.

On the Control Plane, these are:

IuCS, IuPS Radio Access Network Application Part (RANAP)Iub Node B Application Part (NBAP)Iur Radio Network Sub-system Application Part (RNSAP)

On the User Plane:

IuCS, IuPS Either transparent or appropriate framing protocol (mainly for PS)Iub, Iur Framing protocols



Physical Layer (Not specified)

Data Bearer(s) SignallingBearer(s) *

SignallingBearer(s)*

ALCAP

Control Plane User Plane

HigherLayer

Protocols

IuCSIuPS

Transparent or IuFraming Protocols

IubIur

(not shown)

RadioNetwork

Layer

TransportNetwork

Layer

• Transport Network Layer Protocols are ATM Based

* Set up by O & M Action

User Control

Framing Protocols

IuCsIuPs

RANAPRANAP

IubIur

NBAPRNSAP

Fig. 11 – Radio Network Layer Protocols



3.4 UTRAN Protocols – Fitting Them Together

In order to appreciate the complexity, but the logical nature of the UTRAN protocols,several different can be examined:

3.5 RRC Idle Mode

When a mobile is in RRC (Radio Resource Control) idle mode, no RRC connectionexists, and any relevant control information is simply carried over each interface usingthe appropriate control protocol. Hence RRC is found on the Uu interface betweenthe user and network, NBAP on the Iub, and RANAP on both the IuCS and IuPS.

Interface control information, together with such radio resource messages as SystemInformation and Paging comprise the control information in idle mode.

The relevant layer 2 protocols support the transfer of data over the air interface(Radio Link Control, RLC, and Medium Access Control, MAC).

Transport is provided by ATM on the terrestrial interfaces, and W-CDMA on the airinterface.



CoreNetwork

ATM

ATM

W-C

DMA

"IDLE"

NODE B

CRNC

Contro

l (RRC)

Contro

l (NBAP)

Contro

l (RANAP)

Relevant Logicaland Transport Channels

(incorporates RLC and MAC)

• RRC Used mainly for Paging and Broadcast messages

Fig. 12 – Use of Radio Network Layer Protocols (RRC Idle Mode)



3.6 RRC Connected Mode (1)

In RRC Connected Mode, the Serving RNC provides all layer 2 (RLC and MAC)processing as well as terminating the Radio Bearer and Signalling Radio Bearer.Hence the RRC protocol itself is terminated here (as well as in the UE).

All information destined for, or received from the radio interface must therefore becarried transparently from Node B to SRNC (this includes user data, RRC, RLC, MACinformation). This information is organised into logical and transport channels (asprovided through RLC and MAC).

Each transport channel (together with the logical channel(s) it contains), whether dataor control information is simply transferred across the Iub interface as User Planeinformation, as shown opposite.

Once at the SRNC, the data is interpreted as required and either acted upon (for RRCmessages), transferred over the Iu interface within RANAP messages (for Non-AccessStratum control information, i.e. CM, MM, SM messages), or transferred over the Iuinterface either transparently (for circuit switched data) or in the appropriate framingprotocol (for packet switched data).

In addition, extra control information, relevant to each interface is provided throughNBAP on the Iub interface, RANAP on the Iu interface, and Radio Resourcemessages on the air interface.

Transport is provided by ATM on the terrestrial interfaces, and W-CDMA on the airinterface.



CoreNetwork

ATM

ATM

W-C

DMA

NODE B

"CONNECTED"

Relevant Logicaland transport

channels(incorporates

RLC and MAC)

Carries MM, CM (CC, SS,SMS), SM

SRNC

Contro

l

Contro

l (RRC)

User D

ata

Contro

l (NBAP)

Contro

l (RANAP)

User D

ata (C

S or P

S)

"Use

r Plan

e"

Fram

ing P

roto

col

Uu

Iub

Iu

Fig. 13 – Use of Radio Network Layer Protocols (RRC Connected Mode)



3.7 RRC Connected Mode (2)

In this case, a Drift RNC has been introduced into the scenario. However, the RadioBearer and Signalling Radio Bearer, layer 2, and RRC still terminate at the SRNC.Therefore this is basically the same scenario as for the RRC Connected Mode withoutDRNC, but with the transparent path extended over the Iur interface as well as theIub for the relevant transport channels. RNSAP provides the additional controlinformation necessary on that interface.

The framing protocols for the Iur user plane are the same as those for the Iub interface.

Transport is again provided by ATM on the Iur interface.



W-C

DMA

User D

ata (C

S or P

S)

Contro

l (RANAP)

Contro

l

Contro

l (NBAP)

Contro

l (RRC)

User D

ata

CoreNetwork

Node B RRC, MAC & RLCTerminate at UE and SRNCIf common channels are used, MAC atC/DRNC will be used as well as at SRNC

ATM

ATMSRNC

ATM

DRNC

"Use

r Plan

e"

Fram

ing P

roto

col

+Iub

+Uu

+Iu

+Iur

User Plane Framing Protocol

Control (RNSAP)

Fig. 14 – Use of Radio Network Layer Protocols(RRC Connected Mode with Drift RNC)



3.8 Functions Of The UTRAN Protocols

The functions of each of the UTRAN control protocols are outlined opposite.

RANAP includes those functions needed to manage location procedures which mayneed Core Network interaction, such as Hard Handover, and SRNS relocation. Radioaccess bearer management, security, paging, identity management, and transparenttransfer of Non-Access Stratum signalling are all supported by RANAP.

RNSAP provides functions which are split into four modules. Basic inter RNC mobilityis supported in order to provide soft handover between RNS and to transfer waitingdata during SRNS relocations.

In addition, support is provided for both dedicated channel traffic (transparentlytransferred between SRNC and UE in dedicated transport channels) and commonchannel traffic (transferred from the SRNC to the DRNC for inclusion in the commonchannels being supported by that DRNC – which is also acting as the CRNC for theNode B in question).

NBAP functions are classed as either common or dedicated, depending on whetherthey are concerned with common or dedicated channels. RNC in Controlling, Servingor Drift Modes are supported. The functions are generally concerned with the use orconfiguration of the radio channels, including paging, access requests, radio linkmeasurements, handovers and fault management.



NB

AP

RNSAP

RA

NA

P

CoreNetwork

RANAP FUNCTIONS INCLUDE:• Relocation SRNS & Hard Handover• Radio Access Bearer Management• Paging and ID Management• UE <-> CN Signalling Transfer (Transparently)• Security Mode Control• Location Reporting

RNSAP FUNCTIONS INCLUDE:• Basic Inter - RNC Mobility• Dedicated Channel Traffic Support• Common Channel Traffic Support• Global Resource Management (optional)(Implemented in Four Separate Modules Shown Above)

NBAP FUNCTIONS INCLUDE:Common -• Setup First Radio Link of UE• RACH, FACH & PCH Handling• Reporting Cell/Node B Measurements• Cell Configuration• Fault Management

Dedicated• RL Addition, Release & Reconfiguration for

one UE context• Dedicated and Shared Channel Handling• Softer Combining Support• Reporting of RL Specific Measurements• RL Fault Management

SRNC DRNC

NODE B

Fig. 15 – UTRAN Protocol Functions



4. HANDOVERS

A handover primarily allows a moving mobile to remain connected with the networkas different coverage areas (cells) are transited. Alternatively, it allows the networkoperator to control congestion and cell loading by compelling a mobile to hand overbetween adjacent cells in the overlap region (or even between hierarchical overlaidcells).

Of increased importance for UMTS, though, is the possibility to hand over betweencells, frequencies, or even access network types for reasons of service requirements(data rates, capacity, and quality of service issues).

Different handover types exist. Hard handovers (as seen in GSM) are needed forhandover between different UMTS carrier frequencies and between systems. Softhandover provides handover between cells handled by different Node Bs, whilstsofter handover allows handover between cells handled by the same Node B.

Soft and softer handovers can be handled entirely within the UTRAN. Hard handoversmay be handled entirely within the UTRAN for handovers between carrier frequencies.The Core Network will be involved for inter-system hard handovers.

4.1 Softer Handover

In around 10% of connections at any time, the mobile will be served by more thanone cell or sector operating on the same frequency and provided by the same NodeB. With the same codes used, the received signals are simply input into the RakeReceiver as different components of the same signal. This process, together with theRake combining of any multi-path components enhances the signal.

Combining in this case is achieved entirely within the Node B and the UserEquipment. The process is known as micro-diversity. Only a single power control loopis active per connection, provided by the Node B.



SRNC

Node B

Combinedsignal received

via Rakeprocessing

CoreNetwork

Fig. 16 – Softer Handover (Micro Diversity)


• Communication via more than one air interface concurrently• Rake receivers at Node B and mobile station used to combine

signal (similar to multipath reception)• Occurs in about 10% of connections• Only one power control loop per connection is active.


4.2 Soft Handover

In the case of the soft handover, combining is done in the RNC, with the differentarriving signals being continually assessed and the best signal chosen (every 10 –80ms) for inclusion in the combined signal. The process is known as macro-diversity.

Soft handover is generally thought to occur in about 20 – 40% of connections, andhence increases the overall requirement for transmission capacity in the UTRANtransport network. Additional Rake fingers are also required to cope with theincreased number of "wanted" paths.

One of the main reasons for employing the soft and softer handover techniques inCDMA is to mitigate the near-far effect, where a closer mobile contributesdisproportionately to the overall interference levels. Hence in all handover cases,power control is critical.

For softer handover, only one power control loop is active (i.e. only one Node Binvolved), but for soft handover, more than one power control loop is active (powercontrol is now being provided by more than one Node B). This does not present aproblem since the mobile simply responds to the Node B with the lower powerrequirement, minimising overall interference in the system.

Soft and softer handover can be used simultaneously.



SRNCCore

Network

Node B

Node BCombining/Splitting

Node B

DRNC

Fig. 17 – Soft Handover (Macro Diversity)


• Communication via more than one air interface concurrently.• Signal split/combined at RNC (best frame chosen)• Requires additional:

– Rake receiver channels in Node Bs – Transmission links Node B <-> RNC – Rake fingers in mobile stations

• Occurs in about 20 - 40% of connections• Power control active for each Node B (mobile responds to Node B

with lowest uplink power requirements).• Can be combined with softer handover


5. THE TRANSPORT NETWORK

5.1 Requirements Of The Transport Network

As a network of interconnected nodes, the UTRAN presents familiar problems to thedesigner of a transport network.

The UTRAN provides the User Equipment (UE) with access to the Core Network (CN)for both Circuit Switched and Packet Switched services as well as providing transportfor all signalling interactions, including those confined within the UTRAN, thosebetween the UTRAN and the Core Network, and those being transferred through theUTRAN from UE to CN or vice-versa.

The W-CDMA air interface has been designed to support services which vary widelyin terms of acceptable quality of service. Hence services with varying data rates,delay tolerance, delay variance, and acceptable error rates are all possible.

The UTRAN transport network has therefore been specified to support the varyingqualities of service required for all the data types.

5.2 The Options

In choosing the technology, reliability, cost, flexibility, scalability, delivery time scales,and not least suitability for the task at hand were all factors. Specifying a protocolespecially for UMTS was deemed not necessary since ATM (Asynchronous TransferMode) already existed and provided a relatively close match to the requirements.Fortunately, the transport protocol has been specified separately from the UTRANprotocols themselves, hence future flexibility in choice of technology is assured.

At the moment, ATM is specified rather than an Internet Protocol (IP) solution,however the continuing work on IP is bringing it closer to satisfying the requirements(and at an inevitably low cost).




Fig. 18 – UTRAN Transport Network Requirements

RNC

UTRANTransportNetwork

RNC

MSC

Rest ofNetwork

(CS & PS)

SGSN

RNC

NodeB

NodeB

Packet Switched& Circuit Switched

User Data & Signalling

Radio Bearers

Signalling Radio Bearers

Interface Control Information

• ATM Chosen


5.3 ATM Operation

Within a network of ATM switches, virtual channels and virtual paths through thenetwork from entry point to exit point can be provided by ensuring that the switcheshave the relevant identifiers and routing information available. This information can bepre-configured, or set up within the switches dynamically by specific signallingmessages as a requirement for a path or channel through the network arises.

Switching is achieved by the use of fixed length (53 Octet) cells with appropriateidentifiers. Each cell is identified at each ATM switch and simply directed on to thenext switch in accordance with the routing information held in the switch. Theidentifiers will change as the cell passes through the switch, however, each switch willhave been programmed with the correct identifiers and the overall path or channelwill still be valid.

Switching can occur on two levels – at the path level, which may simply switch byanalysing only the "virtual path identifier" (irrespective of the "virtual channelidentifier"); and at the channel level, where both identifiers are analysed and the cellrouted accordingly. This can allow flexibility in network provision by allowing simplerprocessing at virtual path switches, and more in-depth at virtual channel switches.ATM physical switches can of course have both levels of switching available.



ATMNETWORK

ATM Switch

A

A

B

B

Fig. 19 – ATM Operation


• Virtual channels/paths through the network are set up by O&Maction or dynamically using signalling

• Channels and paths identified using VCIs (Virtual ChannelIdentifiers) and VPIs (Virtual Path Identifiers) in the ATM Cell Header


5.4 The ATM Cell

On any link between switches, the cells for a single path or channel will be allocatedas required (asynchronously) within the overall synchronous cell stream.

The cell itself is made up of 48 octets of data (which may include higher layer controlinformation) with 5 octets of ATM header information. This information includes:

The Virtual Path Identifier (VPI)The Virtual Channel Identifier (VCI)Payload Type (PT)Cell Loss Priority (CLP)Header Error Correction (HEC)

The VPI and VCI are used in the switching process. The PT identifies the type ofpayload. The Cell Loss Priority allows cells to be prioritised in terms of which onescould be discarded first in congestion situations. HEC provides a mechanism forchecking for errors within the header (only).



The ATM Cell:

DATA

Contains User Data andAdaptation Information (Quality

of service requirements)

48 Octets 5 Octets

HEADER:(VPI/VCI/PT/CLP/HEC)

ATM Cell Streams:

Asynchronous allocation of cellsin synchronious stream

A B

Continuous stream of cells

Fig. 20 – The ATM Cell



5.5 ATM and Quality Of Service

It is not the ATM cell itself which provides the necessary control and protocols tosupport different Qualities of Service (QoS), but the specified adaptation processwhich occurs between the data to be transported and the ATM cell.

The adaptation process introduces extra overhead (control data) onto the data to beplaced within the 48 octets of data within the ATM cell. In terms of protocol, the ATMAdaptation Layer (AAL) lies directly between the data to be carried and the ATM layer.Four different AALs have been specified for use with ATM, and two have beenadopted within the UTRAN – AAL2 and AAL5.

The characteristics of each are shown opposite. Between them, they provide supportfor all necessary UTRAN QoS requirements.



• Variable bit rates• Packet type data• Segmentation & Reassembly• Constant delays not required• Suitable for signalling, packet user,

data transfer etc

• Variable bit rates• Circuit type data• Segmentation & Reassembly• Constant delays required• Suitable for multimedia, video etc

AAL-ATM Adaptation Layer

ATM NETWORK

AAL5 AAL5

AAL2AAL2

AAL5

AAL2

Fig. 21 – ATM and Quality of Service



5.6 Use Of ATM In The UTRAN

Within UTRAN, the use of AAL2 and AAL5 have been specified over each interface fordifferent types of data. These are shown opposite.

AAL2 is only used wherever circuit switched type data is being transferred, or likely tobe transferred, otherwise AAL5 is specified (where packet user data only is to betransferred, or for signalling).

On the Iub and Iur interfaces, the interfaces’ user plane data would usually include amixture of circuit type and packet type (end user) data, and signalling destined for, orreceived from, the radio interface. On both interfaces, the circuit switched end userdata Quality of Service requirements must be satisfied, hence AAL2 is used.



"USER"

AAL 5 AAL 5ATM

* Includes RRC signalling carried transparently over these interfaces

Iu Packet User Data / Signalling"USER"

"USER"

AAL 2 AAL 2ATM

IuCS, Iub*, Iur* User Data"USER"

Fig. 22 – ATM within the UTRAN



ANNEX 1TRANSPORT NETWORK LAYER PROTOCOLS


A.1 TRANSPORT NETWORK LAYER PROTOCOLS

For clarity, the UTRAN Transport Network Layer protocols are shown for each UTRANinterface.

The Access Link Control Application Part (ALCAP) protocol is specified for allinterfaces except the IuPS. ALCAP allows for dynamic configuration and routingthrough the ATM network and is required to set up the relevant AAL2 connections(circuit switched type connections), ensuring that the requested quality of service issupported. The IuPS interface is the only one which uses AAL5 for transporting bothuser plane and control plane information. In this case, dynamic allocation is notrequired, and the ALCAP is absent. The paths and channels are pre-configured.

The specified ALCAP is International Telecommunications Union (ITU)recommendation Q.2630 which is a protocol originally specified for use with ATM,and designed mainly to control the set up, maintenance, and release of ATMconnections with the required QoS.



Physical Layer (Not specified)

Data BearerSignallingBearer(s) *

SignallingBearer(s)*

ALCAP

Control Plane User Plane

RadioNetwork

Layer

TransportNetwork

Layer

User Control

IuCS Q2630IuPS ABSENTIub Q2630Iur Q2630

IuCS SS7, AAL5, ATMIuPS SS7, AAL5, ATMIub AAL5, ATMIur SS7, AAL5, ATM

IuCS SS7, AAL5, ATMIuPS SS7, AAL5, ATMIub AAL5, ATMIur SS7, AAL5, ATM

IuCS AAL2, ATMIuPS GTP, UDP, AAL5, ATMIub AAL2, ATMIur AAL2, ATM

Fig. A.1 – Transport Network Layer Protocols


section seven

Documents