7/27/2019 Evolution of UTRAN Architecture

1/5

244EVOLUTION OF TH E UTRAN ARCHITECTUREMarkus Bauer, Peter Schefczik, Michael Soellner, Wilfried SpeltackexLucent Technologies, Germany

Abstract . .In this paper, we discuss possible evolution scenariosfor the UMTS Terrestrial Radio Access Network(UTRAN) beyond 3GPP standards Release 5 . Thecurrent UTRAN has inherited its centralised networkarchitecture with a quite complex central radio networkcontroller (RNC) and simple base stations (calledN od eB in UMTS) from the 2d generation GS Msystem. Fifteen years ago, this basic architecture wasdesigned for GSM to provide wireless access to thecircuit-switched, voice-oriented telecommunicationsnetwork (PSTN). Though in the meantime, the networkarchitecture has been extended to packet data services(Global Packet Radio Service GPRS), the rise of theInternet and its different service requirements have notbeen reflected adequately. With standards Release 5 in3GPP UMT S, as a first step towards a stronger Internetorientation, IP transport shall replace the ATM-basedlinks between RNC and NodeB. However, the fulladvantage of 1P transport cannot be realised, because ofthe unchanged characteristics of the interface thatrequires to cany synchronised radio link blocks with ahigh quality of service, regardless of the user-service towhich they belong. To overcome this drawback and toenable real service differentiation, some modificationsof the 3GPP Rel. 5 architecture have been investigated.Preserving the Iu interface between UTRAN and corenetwork, the proposed architecture can take fulladvantage of the IP-based protocols in the transportnetwork. In addition, it offers improved scalability dueto its separation of control and user-plane.1. In t roduct ionThe r i se of the Internet during the past years results inthe trend that more and more IP-based services will bedeman ded also. by m obile users. However, it might bequestioned whether todays UMT S Terrestrial RadioAccess Network (UTRAN) is able to satisfy thisdemand efficiently. UTRAN has inherited its centralisednetwork architecture with a q uite complex central radionetwork controller (RNC) and simple base stations(ca l led NodeB in UMTS) from the 2d generationGSM system. About fifteen years ago, this basicarchitecture was designed for G SM to provide wirelessaccess to the circuit-switched, voice-orientedtelecommunications network (PSTN). Though in themeantime. the network architecture has been extended

I The research reported in this paper bas been partlyconducted within the IPonAir program funded by theGerman Ministry of Education and Research (BMB F)under grant 01BU161. he responsibility for contents ofthis publication is with the authors.

to packet data services (Global Packet Radio ServiceGPRS), the provision of IP services over GPRSprotocols seems unnecessarily complex. This situationhas not improved much by introduction of the 31 dgeneration UMTS system, since for sake of a smoothmigration, the 3GPP standards bodies decided not tochange network architectures and protocolsdramatically. So it is still up to later releases to copewith the difficulties of evolving 3G networks tooptimised IP environments.This is what stimulates current research in 3G andbeyond networks [ I ] , [2]. The research work presentedhere is part of a research project IPonAir. TheIPonAir project [3] concentrates on the seamlessintegration of complementary wireless access networksbuilt upon existing and future IP-based protocols.The focus of this paper is to discuss how to evolve thecurrent UTRAN Rel. 5 architecture to a newarchitecture thereby exploiting the full advantages of anIP transport network. Even though IP transport isintroduced to replace ATM transport between basestation (NodeB) and Radio Network Controller (RNC)in UTRAN Re1.5 [5], this solution is seen as a first steptowards an all-IP network architecture. This evolvedsolution should be simpler (IP-based), concerningprotocol stacks, network elements and IP transporteffectiveness thus enabling lower costs for each serviceprovided. However, as a strong constraint, the capitalinvested into the existing 3G networks so far must bepreserved for the operators.Key contribution of this paper is the proposal to relocateradio specific processing from the RNC to the NodeB.Thereby the Iuh interface becomes a NodeB internalinterface. This enables a total separation of user andsignalling plane inside the UTRAN, whereas the luinterface towards the CN remains unchanged. Thisimproves the scalability of the system and eases theintegration of new services. The RAN transportfunctionality is more or less reduced to a plain IP-routednetwork with the possibility of traffic engineering. Lasthut not least the centralised functionality of the RNChecomes obsolete. The remaining RNC controlfunctions, called RAN Server, primarily are consignedto perform the micro-mobility functionality, i.e. themobility inside the UTRAN. This allows thecoexistence of the proposed UTRAN architecture withformer UTRAN R 5 network elements.Th e paper is organised as follows. It firstly describes thecurrent UTRAN Re1.5 architecture. Secondly, itformulates a rearrangement of the current UTRAN

Q 2003 The Institution of Electrical Engineers. Printed and published by The IEE. Michael Faraday Hou se, Six Hiiis Way , Stevenage. SGI 2A Y

orized licensed use limited to: NUST School of Electrical Engineering and Computer Science (SEECS). Downloaded on June 14,2010 at 06:33:06 UTC from IEEE Xplore. Restrictio

7/27/2019 Evolution of UTRAN Architecture

2/5

24 5

Radio Bearer(Control Plan e)

Re1.5 architecture called the Distributed RANarchitecture and discusses its pros and cons.2. The Release 5 UTRANAny new architecture with prospect to acceptance bystandardisation bodies (e.g. 3GPP) should be based onprevious solutions. They shall also be compatible withalready installed systems as depicted in Figure 1. The Iuinterface, which connects the UTRAN with the CoreNetwork is realised as an IP-tunnel.In UTRAN Release 3, each NodeB communicates withits respective RNC via the Iub interface by means ofATM-links to establish the logical connections. Theseare substituted by IP in Release 5 . This however means,that a connectionless mechanism will he introducedinstead of the connection orientation, ATM provides.Due to its connectionless characteristics, IP is very wellsuited for hest-effort services without high Qo Srequirements. As the 3G system shall be able to offerany type of service, some kind of QoS differentiationand management may he necessary. Especially thetraffic for real-time services between RNC and NodeB

IuBearer(Control Pian e)

, I............................... . ~ . ~..........................

Radio Bearer(User Plane)

Figure I :The Release 5 UTRANcannot he properly handled with a hest-effort transportmechanism. Additional means to provide the requiredquality must be implemented in order to establish aconnection oriented behaviour for these service types.Moreover, through the current distribution of radio linkrelated functions, the Iuh interface requires asynchronised transport of radio link blocks withundifferentiated high quality services.3. Reorganising The UTRA NIn the current architecture, the main intelligence of theUTRAN is concentrated in the Radio NetworkController (RNC, see figure I) . As a central instance, itmanages the provisioning of all necessary hearerservices for control and user traffic in order to establishthe Radio Access Bearer (RAB) between UE and CoreNetwork.On demand, the radio and the Iu hearers are establishedby means of different protocols with some processing inthe RNC (mainly segmentation and re-assembly of

IuBearer(User Plane)

Radio Access Bearer

I I I I U I( h e r P lane] (User P lane)

Figure 3: Bearer Services in Distributed RANtwo flows, of which one is directed to the remainingRNC, now called RAN Server, canying the controltraffic (Iu-c). The other flow, carrying the user traffic, isdirectly routed to the destination NodeB (Iu-U). Thisleads to a new arrangement of network elements (asdepicted in figure 4) , which is called DistributedRANarchitecture.Th e RAN Server has full control on the new UTRANand manages the provisioning of necessary lu-hearers,Iu-c for the control plane and Iu-U for the user plane. Italso provides the new Distributed RAN Control (D RC)bearers (int-ctrl). This interface betwee n RAN Serverand the new NodeB is functionally an internal interfaceof the former RNC (int-ctrl, dashed lines in figure 4)whereas the form er external Iuh is now inside that node.Similar to the former RNC, the R AN Server keeps trackof all users in its UTRAN and provides the function of aMicro-Mobility Management.

orized licensed use limited to: NUST School of Electrical Engineering and Computer Science (SEECS). Downloaded on June 14,2010 at 06:33:06 UTC from IEEE Xplore. Restricti

7/27/2019 Evolution of UTRAN Architecture

3/5

CN EdgsnOUlW

lub-c

Radio-specific UserData Handling(PDCP.RLC. MAC)lub-u

Figure 5 ; Intelligent NodeB

As a consequence all radio-specific user data hand ling(PDCP, RLC, MAC), located in the RNC in todaysUTRAN, is moved into the iNodeB as d epicted in figure5. Due to the relocation of this functionality the non-service differentiate d Iub-u interface becom es iNodeBinternal whereas the Iu-U interface connects iNodeBand CN throughout the whole UTR AN in a standardizedmanner, which is open to any elaborate IP transportsolution. With the Iu-U connection between iNodeB andCN, not only a logical, even more a physical separationis achieved between user plane and all control planerelated elements within the Distributed RAN.With the transfer of all radio-specific user data handlingfrom RNC to the iNodeB, also a relocation ofassociated control plane functionality is required.Therefore all cell specific Radio Resource Managem entfunctionality is moved into the intelligent NodeB. As aresult of this relocation of cell specific Radio ResourceManagement, the former external control part of the Iubinterface (tub-c) migrates to an internal one in theiNode B. This new internal nature of the Iub-c interfacefacilitates improved Radio Link optimization strategiesas might be required by the introduction of High SpeedDownlink Packet Access (HSDPA). In addition, somecomplex Iub protocol scenario of todays UTRANbecomes obsolete.The remaining Radio-Resource Management functionsof todays RNC are concentrated in the RAN Serverwithin the suggested Distributed RAN architecture. Thecell-specific Radio-Resource Management located inthe iNodeB is connected via the new in tc tr l interface tothe Radio-Resource Management functions in the RANServer.5. T he RAN S e w e rWith the separation of control and user plane and therelocation of radio and cell specific functions to theiNodeB, the remaining RNC functions includemanagement of necessary bearer services and thehandling of micro mobility inside the UTRAN.Although the RA N Server does not directly handle usertraffic (see figure 3), it manages the appropriatetransport resources within UTRAN as Switched VirtualPaths. Bearer services for control traffic (i.e. Iu-c andint-ctrl) are also in the responsibility of the RANServer, but are organised as Permanent Virtual Paths.Both types use IP transport and describe the strategyhow the appropriate resources are allocated. In general,permanent virtual paths are pre-arbitrated for theexpected mean capacity and may be adjusted inadvance, if required. Switched virtual paths areprovided on demand, tailored for the requestedcapacity and QoS type.Management of the Iu-c bearer is still performed by theRA application and underlying protocols. Thisfully complies with the standardised Rel. 5 IP-option forthe lu interface. The only difference is, that it is

orized licensed use limited to: NUST School of Electrical Engineering and Computer Science (SEECS). Downloaded on June 14,2010 at 06:33:06 UTC from IEEE Xplore. Restricti

7/27/2019 Evolution of UTRAN Architecture

4/5

247

terminated in the RAN Server within the DistributedRAN architecture instead o f the RNC.Th e RAN Server also requests the necessary radioresources from the respective iNodeB before thetransport resources are se t up.Handoff (hard handom can easily be performed byredirecting the user traffic at Iu-U interface to the newiNodeB. This is possible, because all available transportresources within the UTRAN are under control of theRAN Server, which may use an appropriate IETFprotocol environment for resource allocation and trafficengineering (e.g. MPL S with RSVP-TE).

IIU-UIint-ctrl

Cell-specificRadio-Resource Sofl HOTo other

e

Figure 6: NodeB with Sofl Handoff CapabilitySoft handoff however is not subject of the RAN Server,because it does not handle user traffic and its RLC-PDUs, which are necessary for the appropriate splittingand combining of radio signals to and from differentlegs. The role of a drift and serving RNC in thiscase are taken by the iNodeBs, which have to providean Iur-like interface and handle the RNSAP protocol asdepicted in figure 6. In the Distributed RANarchitecture, each iNodeB must therefore be (logically)connected with its neighbouring iNodeB by a high-quality path to satisfy the required framesynchronisation conditions. The capacity of such a pathhowever may be quite low, because it needs only tocarry the traffic (user as well as control plane) of thoseusers, which are currently in the soft handoff condition.As soft handoff is a powerful means for managingCDMA systems, this needs further detailedinvestigation. However, we expect that modifiedschemes for soft handoff on control channels and sharedchannels will help to reduce the complexity.6 . Co-operation with Legacy UTRANAs the evolved architecture does not touch the Iuinterface, it can easily he merged with the regularUTRAN of previous releases as shown in figure 7. Only

the Iuh interface of the legacy RNC requires specialprecautions, if it shall he carried in an IP based netwo rk.Simple tunnelling technique could he used, but withreduced scalability and no capability of servicedifferentiation or improved network resourcemanagemen t (traffic engineering)...As the RAN Server appears to the Core Network as aregular RNC, (hard) handoff between NodeB andiNodeB is seamlessly possible.

Soft handoff in this mixed arrangement is a bit moreproblematic, because the neighbouring NodeB t o an

I I I ~ - - - I- UFigure 7: Co-operation of Distributed RAN with Legacy RANiNodeB does not provide the Iur interface and a link tothe respective RNC might he necessary. A possiblesolution could he that the RNC splits the Iur on separateIP tunnels towards those NodeBs, which are potentialcandidates of soft handoff to iNodeBs.7. ConclusionTo cope efficiently with the expected growth of datacommunication and the introduction of the full scope ofIP applications, some further modifications to thesystem architecture for the UMTS radio access networkas defined in Rel.5 have been proposed. The presentednew architecture offers the necessary scalability andservice differentiation for flexible adaptation to futurerequirements. It allows seamless migration fromprevious UTRAN solutions (Release 5 ) and even the co-existence with their predecessors. With its ability fortraffic engineering, it is a further step towards anefficient realization of a n All-IF network.References[ l ] Uskela S., Key Concepts for Evolution towardbeyond 3G Networks, IEEE WirelessCommunications Mag., February 2003, pp43-48

orized licensed use limited to: NUST School of Electrical Engineering and Computer Science (SEECS). Downloaded on June 14,2010 at 06:33:06 UTC from IEEE Xplore. Restricti

7/27/2019 Evolution of UTRAN Architecture

5/5

248

[2].Yungsoo K., B yung J., Jaehak C., Chan-Soo H., RyuJ . S. , Ki-Ho K., Young K., Beyond 3G: vision,requirements, and enabling technologies, IEEECommunications Mag., March 2003, pp120-124[3] IPonAir homepage, http://www.iuonair.de[4] Kaaranen H., Ahtiainen A., Laitinen L., Naghian S. ,Niemi V., UMTS Networks: Architecture, Mobilityand Services, John Wiley & Sons, Ltd., Chichester,England, 2001[ 5 ] 3GPP TR 25.933, 1P Transport in UT RA N ,V5.1 O, June 2002

orized licensed use limited to: NUST School of Electrical Engineering and Computer Science (SEECS) Downloaded on June 14 2010 at 06:33:06 UTC from IEEE Xplore Restricti

http://www.iuonair.de/http://www.iuonair.de/