244

EVOLUTION OF THE UTRAN ARCHITECTURE Markus Bauer, Peter Schefczik, Michael Soellner, Wilfried Speltackex Lucent Technologies, Germany

Abstract . . In this paper, we discuss possible evolution scenarios for the UMTS Terrestrial Radio Access Network (UTRAN) beyond 3GPP standards Release 5 . The current UTRAN has inherited its centralised network architecture with a quite complex central radio network controller (RNC) and simple base stations (called NodeB in UMTS) from the 2d generation GSM system. Fifteen years ago, this basic architecture was designed for GSM to provide wireless access to the circuit-switched, voice-oriented telecommunications network (PSTN). Though in the meantime, the network architecture has been extended to packet data services (Global Packet Radio Service GPRS), the rise of the Internet and its different service requirements have not been reflected adequately. With standards Release 5 in 3GPP UMTS, as a first step towards a stronger Internet orientation, IP transport shall replace the ATM-based links between RNC and NodeB. However, the full advantage of 1P transport cannot be realised, because of the unchanged characteristics of the interface that requires to cany synchronised radio link blocks with a high quality of service, regardless of the user-service to which they belong. To overcome this drawback and to enable real service differentiation, some modifications of the 3GPP Rel. 5 architecture have been investigated. Preserving the Iu interface between UTRAN and core network, the proposed architecture can take full advantage of the IP-based protocols in the transport network. In addition, it offers improved scalability due to its separation of control and user-plane. 1. Introduction The rise of the Internet during the past years results in the trend that more and more IP-based services will be demanded also. by mobile users. However, it might be questioned whether todays UMTS Terrestrial Radio Access Network (UTRAN) is able to satisfy this demand efficiently. UTRAN has inherited its centralised network architecture with a quite complex central radio network controller (RNC) and simple base stations (called N o d e B in UMTS) from the 2d generation GSM system. About fifteen years ago, this basic architecture was designed for GSM to provide wireless access to the circuit-switched, voice-oriented telecommunications network (PSTN). Though in the meantime. the network architecture has been extended
I The research reported in this paper bas been partly conducted within the IPonAir program funded by the German Ministry of Education and Research (BMBF) under grant 01BU161.The responsibility for contents of this publication is with the authors.

to packet data services (Global Packet Radio Service GPRS), the provision of IP services over GPRS protocols seems unnecessarily complex. This situation has not improved much by introduction of the 31d generation UMTS system, since for sake of a smooth migration, the 3GPP standards bodies decided not to change network architectures and protocols dramatically. So it is still up to later releases to cope with the difficulties of evolving 3G networks to optimised IP environments.
This is what stimulates current research in 3G and beyond networks [I], [2]. The research work presented here is part of a research project IPonAir. The IPonAir project [3] concentrates on the seamless integration of complementary wireless access networks built upon existing and future IP-based protocols. The focus of this paper is to discuss how to evolve the current UTRAN Rel. 5 architecture to a new architecture thereby exploiting the full advantages of an IP transport network. Even though IP transport is introduced to replace ATM transport between base station (NodeB) and Radio Network Controller (RNC) in UTRAN Re1.5 [5], this solution is seen as a first step towards an all-IP network architecture. This evolved solution should be simpler (IP-based), concerning protocol stacks, network elements and IP transport effectiveness thus enabling lower costs for each service provided. However, as a strong constraint, the capital invested into the existing 3G networks so far must be preserved for the operators. Key contribution of this paper is the proposal to relocate radio specific processing from the RNC to the NodeB. Thereby the Iuh interface becomes a NodeB internal interface. This enables a total separation of user and signalling plane inside the UTRAN, whereas the lu interface towards the CN remains unchanged. This improves the scalability of the system and eases the integration of new services. The RAN transport functionality is more or less reduced to a plain IP-routed network with the possibility of traffic engineering. Last hut not least the centralised functionality of the RNC hecomes obsolete. The remaining RNC control functions, called RAN Server, primarily are consigned to perform the micro-mobility functionality, i.e. the mobility inside the UTRAN. This allows the coexistence of the proposed UTRAN architecture with former UTRAN R5 network elements. The paper is organised as follows. It firstly describes the current UTRAN Re1.5 architecture. Secondly, it formulates a rearrangement of the current UTRAN

Q 2003 The Institution of Electrical Engineers. Printed and published by The IEE. Michael Faraday House, Six Hiiis Way, Stevenage. SGI 2AY

Authorized 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. Restrictions apply.

245
Re1.5 architecture called the Distributed architecture and discusses its pros and cons. RAN

2. The Release 5 UTRAN Any new architecture with prospect to acceptance by standardisation bodies (e.g. 3GPP) should be based on previous solutions. They shall also be compatible with already installed systems as depicted in Figure 1. The Iu interface, which connects the UTRAN with the Core Network is realised as an IP-tunnel. In UTRAN Release 3, each NodeB communicates with its respective RNC via the Iub interface by means of ATM-links to establish the logical connections. These are substituted by IP in Release 5 . This however means, that a connectionless mechanism will he introduced instead of the connection orientation, ATM provides. Due to its connectionless characteristics, IP is very well suited for hest-effort services without high QoS requirements. As the 3G system shall be able to offer any type of service, some kind of QoS differentiation and management may he necessary. Especially the traffic for real-time services between RNC and NodeB

Radio Bearer (Control Plane) Radio Bearer (User Plane)

IuBearer (Control Piane) IuBearer (User Plane)

Radio Access Bearer

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. ~. . . .. . . . ~ . . . . . . . . . . . . . . . . . . . .
I

U
(User Plane)

Figure I : The Release 5 UTRAN cannot he properly handled with a hest-effort transport mechanism. Additional means to provide the required quality must be implemented in order to establish a connection oriented behaviour for these service types. Moreover, through the current distribution of radio link related functions, the Iuh interface requires a synchronised transport of radio link blocks with undifferentiated high quality services.
3. Reorganising The UTRAN In the current architecture, the main intelligence of the UTRAN is concentrated in the Radio Network Controller (RNC, see figure I). As a central instance, it manages the provisioning of all necessary hearer services for control and user traffic in order to establish the Radio Access Bearer (RAB) between UE and Core Network.

( h e r Plane]

Figure 3: Bearer Services in Distributed RAN two flows, of which one is directed to the remaining RNC, now called RAN Server, canying the control traffic (Iu-c). The other flow, carrying the user traffic, is directly routed to the destination NodeB (Iu-U). This leads to a new arrangement of network elements (as depicted in figure 4), which is called Distributed R A N architecture. The RAN Server has full control on the new UTRAN and manages the provisioning of necessary lu-hearers, Iu-c for the control plane and Iu-U for the user plane. It also provides the new Distributed RAN Control (DRC) bearers (int-ctrl). This interface between RAN Server and the new NodeB is functionally an internal interface of the former RNC (int-ctrl, dashed lines in figure 4) whereas the former external Iuh is now inside that node. Similar to the former RNC, the RAN Server keeps track of all users in its UTRAN and provides the function of a Micro-Mobility Management.

On demand, the radio and the Iu hearers are established by means of different protocols with some processing in the RNC (mainly segmentation and re-assembly of

Authorized 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. Restrictions apply.

n
CN Edgs
ROUlW

As a consequence all radio-specific user data handling (PDCP, RLC, MAC), located in the RNC in todays UTRAN, is moved into the iNodeB as depicted in figure 5. Due to the relocation of this functionality the nonservice differentiated Iub-u interface becomes iNodeB internal whereas the Iu-U interface connects iNodeB and CN throughout the whole UTRAN in a standardized manner, which is open to any elaborate IP transport solution. With the Iu-U connection between iNodeB and CN, not only a logical, even more a physical separation is achieved between user plane and all control plane related elements within the Distributed RAN.

With the transfer of all radio-specific user data handling from RNC to the iNodeB, also a relocation of associated control plane functionality is required. Therefore all cell specific Radio Resource Management functionality is moved into the intelligent NodeB. As a result of this relocation of cell specific Radio Resource Management, the former external control part of the Iub interface (tub-c) migrates to an internal one in the iNodeB. This new internal nature of the Iub-c interface facilitates improved Radio Link optimization strategies as might be required by the introduction of High Speed Downlink Packet Access (HSDPA). In addition, some complex Iub protocol scenario of todays UTRAN becomes obsolete. The remaining Radio-Resource Management functions of todays RNC are concentrated in the RAN Server within the suggested Distributed RAN architecture. The cell-specific Radio-Resource Management located in the iNodeB is connected via the new intctrl interface to the Radio-Resource Management functions in the RAN Server. The RAN Sewer With the separation of control and user plane and the relocation of radio and cell specific functions to the iNodeB, the remaining RNC functions include management of necessary bearer services and the handling of micro mobility inside the UTRAN. Although the RAN Server does not directly handle user traffic (see figure 3), it manages the appropriate transport resources within UTRAN as Switched Virtual Paths. Bearer services for control traffic (i.e. Iu-c and int-ctrl) are also in the responsibility of the RAN Server, but are organised as Permanent Virtual Paths. Both types use IP transport and describe the strategy how the appropriate resources are allocated. In general, permanent virtual paths are pre-arbitrated for the expected mean capacity and may be adjusted in advance, if required. Switched virtual paths are provided on demand, tailored for the requested capacity and QoS type.
5.

Radio-specific User Data Handling (PDCP. RLC. MAC)

lub-c

lub-u

Figure 5 ; Intelligent NodeB

Management of the Iu-c bearer is still performed by the RA application and underlying protocols. This fully complies with the standardised Rel. 5 IP-option for the lu interface. The only difference is, that it is

Authorized 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. Restrictions apply.

247
terminated in the RAN Server within the Distributed RAN architecture instead of the RNC. The RAN Server also requests the necessary radio resources from the respective iNodeB before the transport resources are set up. Handoff (hard handom can easily be performed by redirecting the user traffic at Iu-U interface to the new iNodeB. This is possible, because all available transport resources within the UTRAN are under control of the RAN Server, which may use an appropriate IETF protocol environment for resource allocation and traffic engineering (e.g. MPLS with RSVP-TE). int-ctrl the Iuh interface of the legacy RNC requires special precautions, if it shall he carried in an IP based network. Simple tunnelling technique could he used, but with reduced scalability and no capability of service differentiation or improved network resource management (traffic engineering). ..As the RAN Server appears to the Core Network as a regular RNC, (hard) handoff between NodeB and iNodeB is seamlessly possible.

Soft handoff in this mixed arrangement is a bit more problematic, because the neighbouring NodeB to an

I U U

Cell-specific Radio-Resource

Sofl HO

To other

- U

I ~---I

Figure 7: Co-operation of Distributed RAN with Legacy RAN Figure 6 : iNodeB with Sofl Handoff Capability
Soft handoff however is not subject of the RAN Server, because it does not handle user traffic and its RLCPDUs, which are necessary for the appropriate splitting and combining of radio signals to and from different legs. The role of a drift and serving RNC in this case are taken by the iNodeBs, which have to provide an Iur-like interface and handle the RNSAP protocol as depicted in figure 6. In the Distributed RAN architecture, each iNodeB must therefore be (logically) connected with its neighbouring iNodeB by a highquality path to satisfy the required frame synchronisation conditions. The capacity of such a path however may be quite low, because it needs only to carry the traffic (user as well as control plane) of those users, which are currently in the soft handoff condition. As soft handoff is a powerful means for managing CDMA systems, this needs further detailed investigation. However, we expect that modified schemes for soft handoff on control channels and shared channels will help to reduce the complexity.

iNodeB does not provide the Iur interface and a link to the respective RNC might he necessary. A possible solution could he that the RNC splits the Iur on separate IP tunnels towards those NodeBs, which are potential candidates of soft handoff to iNodeBs.

7 . Conclusion To cope efficiently with the expected growth of data communication and the introduction of the full scope of IP applications, some further modifications to the system architecture for the UMTS radio access network as defined in Rel.5 have been proposed. The presented new architecture offers the necessary scalability and service differentiation for flexible adaptation to future requirements. It allows seamless migration from previous UTRAN solutions (Release 5 ) and even the coexistence with their predecessors. With its ability for traffic engineering, it is a further step towards an efficient realization of an All-IFnetwork.
References
[ l ] Uskela S., Key Concepts for Evolution toward 3G Networks, IEEE Wireless beyond Communications Mag., February 2003, pp43-48

6. Co-operation with Legacy UTRAN

As the evolved architecture does not touch the Iu interface, it can easily he merged with the regular UTRAN of previous releases as shown in figure 7. Only

Authorized 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. Restrictions apply.

248
[2].Yungsoo K., Byung J., Jaehak C., Chan-Soo H., Ryu J. S., Ki-Ho K., Young K., Beyond 3G: vision, requirements, and enabling technologies, IEEE Communications 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, Mobility and Services, John Wiley & Sons, Ltd., Chichester, England, 2001
[ 5 ] 3GPP TR 25.933, 1P Transport in UTRAN,

V5.1 .O, June 2002

Authorized 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. Restrictions apply.