UMTS RNC Product Description v1 04

Radio Network Controller
(RNC)
Product Description
_________________________________________________________________________________________ Document Number: UMT/RAN/INF/012025 Document Issue: 01.04/ EN Document Status: Standard Date of Issue: 19/April/2007 _________________________________________________________________________________________
RADIO NETWORK CONTROLLER (RNC) PRODUCT DESCRIPTION
APRIL 2007
Copyright 2007 by Alcatel-Lucent Technologies. All Rights Reserved.
About Alcatel-Lucent Alcatel-Lucent (Euronext Paris and NYSE: ALU) provides solutions that enable service providers, enterprises and governments worldwide, to deliver voice, data and video communication services to end-users. As a leader in fixed, mobile and converged broadband networking, IP technologies, applications, and services, Alcatel-Lucent offers the end-to-end solutions that enable compelling communications services for people at home, at work and on the move. For more information, visit Alcatel-Lucent on the Internet: http://www.alcatel-lucent.com
H
Notice The information contained in this document is subject to change without notice. At the time of publication, it reflects the latest information on Alcatel-Lucents offer, however, our policy of continuing development may result in improvement or change to the specifications described. Trademarks Alcatel-Lucent, and the respective logo is a trademark and service mark of Alcatel-Lucent.
Document Number: UMT/RAN/INF/012025 | Document Issue: 01.04 / EN | Document Status: Standard Alcatel-Lucent Proprietary See Notice on Page 2
2 / 82
APRIL 2007
CONTENTS
1 0BINTRODUCTION..................................................................................................8 1.1 12BO VERVIEW.....................................................................................................8 1.2 13BSCOPE OF THIS DOCUMENT.......................................................................................9 2 1BALCATEL-LUCENT RNC BENEFITS..........................................................................10 2.1 2.2 2.3 2.4 2.5 2.6 2.7 14BM ARKET LEADER MULTI-SERVICE PLATFORM ......................................................................10 15BH IGHEST DENSITY.............................................................................................10 16BO NE ARCHITECTURE FOR ALL TRAFFIC PROFILES...................................................................11 17BH IGH SCALABILITY.............................................................................................11 18BM ULTI-SERVICE TRANSMISSION AND IP UTRAN..................................................................12 19BPROVEN CARRIER GRADE.......................................................................................12 20BEFFICIENT RADIO RESOURCE MANAGEMENT........................................................................13
3 2BARCHITECTURE................................................................................................16 3.1 21BSYSTEM DESCRIPTION..........................................................................................16 3.2 22BUMTS RNC ARCHITECTURE...................................................................................17 3.2.1 56BRNC System Architecture.........................................................................17 3.2.2 57BModules Description................................................................................18 3.2.3 58BRNC Software Architecture.......................................................................24 3.3 23BT RANSPORT NODES: 7670 RSP AND ESE......................................................................28 3.3.1 59B7670 Routing Switch Platform (RSP)............................................................28 3.3.2 60B7670 Edge Services Extender (ESE)..............................................................28 3.4 24BRNC CAPACITY..............................................................................................29 3.4.1 61BRNC Capacity Metrics..............................................................................29 3.4.2 62BRNC-1500 UA05 Capacity and Scalability.......................................................29 3.4.3 63BRNC Capacity Border Limits......................................................................30 4 3BINTERFACES....................................................................................................32 4.1 25BUTRAN TRANSPORT ATM TO IP EVOLUTION.................................................................32 4.2 26BIP TRANSPORT ON IUB........................................................................................33 4.3 27BRNC TO CORE NETWORK (IU).................................................................................34 4.3.1 64BDefinition............................................................................................34 4.3.2 65BImplementation....................................................................................35 4.4 28BI U-PC INTERFACE.............................................................................................35 4.4.1 66BDefinition............................................................................................35 4.4.2 67BImplementation....................................................................................36 4.5 29BRNC TO NODE B (IUB)......................................................................................37 4.5.1 68BDefinition............................................................................................37 4.5.2 69BImplementation....................................................................................39 4.6 30BRNC TO RNC (IUR)........................................................................................39 4.6.1 70BDefinition............................................................................................39 4.6.2 71BImplementation....................................................................................41 4.7 31BI U-BC INTERFACE.............................................................................................41 4.7.1 72BDefinition............................................................................................41 4.8 32BOMC CONNECTIVITY OPTIONS TO THE RNC.....................................................................42 4.9 33BI NTERFACES SPECIFICATIONS.....................................................................................43 4.9.1 73BOC-3/STM1..........................................................................................43 4.9.2 74BE1.....................................................................................................43 4.9.3 75BSynchronization.....................................................................................43 4.10 34BI NTERFACE COMPLIANCE......................................................................................44 5 4BRNC FUNCTIONALITY.........................................................................................46 5.1 35BRADIO RESOURCE MANAGEMENT (RRM).........................................................................46 5.1.1 76BAdmission Control..................................................................................47 5.1.2 77BCongestion Control.................................................................................48 5.1.3 78BPacket Switched Call Management..............................................................48 Document Number: UMT/RAN/INF/012025 | Document Issue: 01.04 / EN | Document Status: Standard Alcatel-Lucent Proprietary See Notice on Page 2
3 / 82
APRIL 2007
5.2 36BM OBILITY....................................................................................................49 5.3 37BHSDPA.....................................................................................................51 5.3.1 79BHSDPA Background.................................................................................51 5.3.2 80BAlcatel-Lucent HSDPA Implementation.........................................................51 5.3.3 81BDynamic Power Control...........................................................................52 5.3.4 82BMulti-carrier HSDPA Traffic Segmentation....................................................52 5.3.5 83BHSDPA Mobility.....................................................................................52 5.3.6 84BAlways-On on HSDPA...............................................................................53 5.3.7 85BIub Bandwidth Limitation Handling.............................................................53 5.4 38BO THER ALCATEL-LUCENT RNC FUNCTIONS......................................................................53 5.4.1 86BPDCP IP Header Compression.....................................................................53 5.4.2 87BSecurity Features...................................................................................54 5.4.3 88BSecurity between RNC and OMC.................................................................55 6 5BOPERATION AND MAINTENANCE............................................................................58 6.1 39BH ARDWARE...................................................................................................58 6.1.1 89BMemory..............................................................................................58 6.1.2 90BCP3....................................................................................................58 6.2 40BH ARDWARE HANDLING.........................................................................................59 6.3 41BSOFTWARE HANDLING..........................................................................................59 6.3.1 91BSoftware Management.............................................................................59 6.3.2 92BFault Management.................................................................................61 6.3.3 93BConfiguration Management.......................................................................62 6.3.4 94BPerformance Management........................................................................62 7 6BPROVISIONING AND ENGINEERING.........................................................................64 7.1 42BM ARKET CONFIGURATIONS......................................................................................64 7.1.1 95BScalability...........................................................................................64 7.1.2 96BConfiguration Upgrades...........................................................................64 7.2 43BC ONNECTIVITY................................................................................................64 7.3 44BI NSTALLATION AND COMMISSIONING..............................................................................64 7.3.1 97BStart-up Tool........................................................................................64 7.3.2 98BSoftware Upgrading................................................................................64 8 7BFUTURE EVOLUTION..........................................................................................66 8.1 45BC APACITY ROADMAP...........................................................................................66 8.2 46BRNC-ORB IT...............................................................................................66 9 8BHARDWARE TECHNICAL CHARACTERISTICS..............................................................68 9.1 47BRELIABILITY..................................................................................................68 9.1.1 99BPrinciples............................................................................................68 9.1.2 100BMean Time Between Failure (MTBF)...........................................................69 9.1.3 101BMaintainability....................................................................................69 9.1.4 102BOverload Control..................................................................................69 9.2 48BREGULATORY COMPLIANCES...........................................................................70 9.2.1 103BEnvironmental Constraints......................................................................70 9.2.2 104BElectromagnetic Compatibility.................................................................71 9.2.3 105BSafety Requirements.............................................................................71 9.2.4 106BRNC RoHS Compliance............................................................................72 9.3 49BPOWER SUPPLY...............................................................................................72 9.4 50BVENTILATION AND AIR CONDITIONING............................................................................72 9.5 51BPHYSICAL DIMENSIONS..........................................................................................73 9.5.1 107BRNC Cabinet.......................................................................................73 9.6 52BO FFICE LAYOUT & FOOTPRINT .................................................................................74 9.7 53BRNC ENVIRONMENTAL CHARACTERISTICS .........................................................................75 10 9BAPPENDIX A: REFERENCES.................................................................................76 11 10BAPPENDIX B: REGULATORY STANDARDS...............................................................78 12 11BAPPENDIX C: GLOSSARY OF TERMS.....................................................................80 12.1 54BACRONYMS..................................................................................................80 12.2 55BG LOSSARY..................................................................................................82 Document Number: UMT/RAN/INF/012025 | Document Issue: 01.04 / EN | Document Status: Standard Alcatel-Lucent Proprietary See Notice on Page 2
4 / 82
APRIL 2007
5 / 82
APRIL 2007
LIST OF FIGURES
FIGURE 1 UTRAN HIGH-LEVEL ARCHITECTURE................................................................9 FIGURE 2 - PACKET SERVER PHYSICAL VIEW...................................................................11 FIGURE 3 ALCATEL-LUCENT UMTS RNC CABINET VIEW....................................................16 FIGURE 4 RNC-1500 ARCHITECTURE...........................................................................18 FIGURE 5 - CP3 MODULE...........................................................................................19 FIGURE 6 - PACKET SERVER FP MODULE........................................................................20 FIGURE 7 - 16P OC3/STM1 CARD.................................................................................21 FIGURE 8 - FABRIC MODULE.......................................................................................22 FIGURE 9 - 4PT GIGABIT ETHERNET MODULE..................................................................24 FIGURE 10 - PMC ROLE ASSIGNMENT IN THE RNC-1500 (12 PSFP FULL CONFIGURATION)...........25 FIGURE 11 RNC-ORBIT ROLES EVOLUTION...................................................................26 FIGURE 12 PMC ROLE ASSIGNMENT IN THE RNC-ORBIT (12 DCPS FULL CONFIGURATION).........27 FIGURE 13 - ALCATEL-LUCENT RNC ATM TRANSPORT.......................................................32 FIGURE 14 - ALCATEL-LUCENT RNC SEAMLESS EVOLUTION TO IP TRANSPORT.......................33 FIGURE 15 - ALCATEL-LUCENT RNC NATIVE IP IUB...........................................................33 FIGURE 16 - IU-CS PROTOCOL STACKS ATM AND IP.........................................................34 FIGURE 17 - IU-PS PROTOCOL STACKS ATM AND IP.........................................................35 FIGURE 18 - IU-PC PROTOCOL STACK...........................................................................37 FIGURE 19 - IUB PROTOCOL STACK ATM......................................................................38 FIGURE 20 IUB PROTOCOL STACK IP.........................................................................38 FIGURE 21 IUR PROTOCOL STACK ATM......................................................................40 FIGURE 22 - IUR PROTOCOL STACK IP.........................................................................40 FIGURE 23 IU-BC INTERFACE PROTOCOL STRUCTURE TOWARDS BROADCAST DOMAIN.............41 FIGURE 24 CELL BROADCAST CENTRE BASIC NETWORK STRUCTURE...................................42 FIGURE 25 - OMC CONNECTIVITY (IN-BAND AND OUT-OF-BAND)..........................................42 FIGURE 26 ADMISSION CONTROL...............................................................................47 FIGURE 27 - RADIUS AND IPSEC SECURITY TO OMC AND RNC ..............................................56 Document Number: UMT/RAN/INF/012025 | Document Issue: 01.04 / EN | Document Status: Standard Alcatel-Lucent Proprietary See Notice on Page 2
6 / 82
APRIL 2007
FIGURE 28 - ALCATEL-LUCENT RNC CAPACITY ROADMAP...................................................66 FIGURE 29 - COOLING UNIT.......................................................................................73 FIGURE 30 - RNC REAR VIEW......................................................................................74
LIST OF TABLES
TABLE 1 - RNC CARRIER GRADE ROADMAP.....................................................................13 TABLE 2 RNC-1500 CAPACITY WITH UA05 SOFTWARE.....................................................29 TABLE 3 - RNC-1500 SCALABILITY WITH UA05 SOFTWARE.................................................30 TABLE 4 - RNC MODULE MTBF....................................................................................69 TABLE 5 - ENVIRONMENTAL CONDITIONS.......................................................................71 TABLE 6 - RNC CABINET DIMENSIONS............................................................................73 TABLE 7 - RNC ENVIRONMENTAL CHARACTERISTICS.........................................................75
7 / 82
APRIL 2007
0B
INTRODUCTION
Overview
1.1
12B
The Radio Network Controller (RNC) is a pivotal element in the success of any UMTS Terrestrial Radio Access Network (UTRAN) deployment. As such, it is imperative that deployed RNCs have the ability to scale efficiently and to cater for flexible deployment scenarios. It is also essential that the RNC possess the capability to improve performance over time, given the likely exponential growth of wireless data. This performance improvement must be achieved by applying upgrades that do not interrupt service. This document provides a description of Alcatel-Lucents two UMTS Radio Network Controller products: the existing 'RNC-1500', and its platform evolution the 'RNC-ORBiT' which will be introduced in UA06. The RNC-ORBiT has been designed to double the capacity of the RNC1500 through a software upgrade, and to support up to four times the RNC-1500 capacity through an optional hardware upgrade whilst still using half of a single cabinet, thus producing the highest density and capacity RNC on the market. Where the description within this document applies to both RNCs, the product will be referred to simply as the 'AlcatelLucent RNC'. The RNC is compliant to the European Union Environmental Directive on the Restriction of Hazardous Substances (RoHS -2002/95/EC/Article 4). RoHS compliancy is only compulsory for newly deployed systems (is not applicable to already installed systems). Alcatel-Lucent's UTRAN (UMTS Terrestrial Radio Access Network) equipment comprises the Alcatel-Lucent UMTS Node B Family, the Alcatel-Lucent UMTS RNC-1500 and RNC-ORBiT and also uses key elements from Alcatel-Lucents market-leading portfolio of the 7670 IP and ATM multi-service network equipment. illustrates the position of the Alcatel-Lucent UMTS RNC and the standardized interfaces in the UMTS network. The RNC acts as the gateway into the Radio Access Network (RAN) with direct connection to the Alcatel-Lucent Operations and Maintenance Centre (OMC) to ensure continuity of service hence maximizing revenue generation.
XFigure 1X
For further information about any Alcatel-Lucent products please refer to your local AlcatelLucent representative.
CO RE NETWO R K Packet/Circuit Switched
Iu-cs
UTRAN Iub
Iu-ps
Iu-cs
Iur
Iu-ps
Itf -R Iub Iub Node B
O MC
Iub
RNC
R NC
Itf -B
Node B Uu
UE UE
Node B U u
Node B Uu
UE
U u
UE
8 / 82

Figure 1 UTRAN High-Level Architecture
APRIL 2007
1.2
13B
Scope of this document
This document gives customers an overview of the Alcatel-Lucent UMTS RNC-1500 product and its evolution, the RNC-ORBiT. Although this document provides information on Alcatel-Lucent RNC functions, it cannot be considered as a detailed features list or a Plan of Record (PoR). This information is provided in dedicated documents on a per software release basis (e.g. UA05 Feature Planning Guide). A lot of the terms used in this document are referring to definitions of the 3GPP standards. Any time an Alcatel-Lucent specific term is used, it is explicitly elaborated. This document is updated regularly under change control. The basis for this document is the UA05 software release.
9 / 82
APRIL 2007
1B
ALCATEL-LUCENT RNC BENEFITS
Alcatel-Lucent UMTS RNC-1500 and RNC-ORBiT products cement Alcatel-Lucent leadership in the RNC product market for UMTS. RNC-ORBiT is the highest density, smallest footprint and simplest to operate RNC product in the market place. This new offering builds on the momentum created by the existing RNC-1500 product, with higher capacity, performance, functionality and reliability and with a single Multi-service Switch (MSS) based platform. RNC-1500 and RNC-ORBiT are compliant to the European Union Environmental Directive on the Restriction of Hazardous Substances (RoHS -2002/95/EC/Article 4).
2.1
14B
Market Leader Multi-Service Platform
As the number of UMTS subscribers grows and services become more complex, it is important for operators to protect their initial investment. Alcatel-Lucent UMTS RNC delivers investment protection by using the flag-ship multi-service data platform MSS. The MSS platform leverages best-in-class industry technology to evolve the following three dimensions external interface cards, internal switching fabric and processing speeds. Providing a proven packet multi-service platform as part of Alcatel-Lucent UMTS RNC proves that all of the related transmission features will be in place and operational from day one; these features are already operating and running worldwide on the MSS platform. MSS can scale from 40 Gbit/s to 160 Gbit/s non-blocking internal switching fabric. In addition to over 1000 mature ATM and IP features on MSS, Alcatel-Lucent UMTS RNC supports an open architecture to integrate leading edge processors to deliver high-speed high-touch bearer services. This is indeed the case with the Packet Server Functional Processor (PSFP), which uses off the shelf PCI Mezzanine cards (PMCs) to provide unsurpassed processing power. Alcatel-Lucent UMTS RNC increases operators profit margin by increasing revenue along with decreasing both Operational Expenses (OPEX) and Capital Expenses (CAPEX).
2.2
15B
Highest Density
With up to 270 Mbit/s on Iu interface at physical layer for a Mobile Internet Premium traffic profile (see [1] for call profile details) and an evolution path for smooth capacity upgrade, Alcatel-Lucent supports the highest capacity available in a single cabinet. This capacity leadership translates into the following key value-adds: Reduced number of RNCs, which will lower the overall initial CAPEX and lower OPEX Reduced number of inter-RNC handovers that will translate into optimal usage of network resources across the access network and the core network, to put more subscribers and subsequently increasing revenue Reduced footprint because fewer RNCs are required. This will lower the CAPEX The Alcatel-Lucent UMTS RNC is based on off-the-shelf processing technology.
10 / 82
APRIL 2007
2.3
16B
One Architecture for all Traffic Profiles
In the Control Plane as well as in the User Plane, only one kind of processor module (Packet Server FP) deals with either voice traffic, and/or data traffic. The Packet Server performs RLC, MAC, AAL2 conversion, Iu, Iur and Iub User Plane protocols, plus all the Control Plane functions. provides a view of the PS.
XFigure 2 X
This will result in a large capacity gain as compared to a solution where each board is dedicated to a particular task: the available CPU power will be dynamically allocated to the specific tasks (either AAL2 or RLC/MAC or Macro Diversity, Radio Resource Management, etc), and not statically to the tasks that network engineers have foreseen at network deployment time. It also allows the RNC to seamlessly handle changes in traffic profiles as compared to ASICs dedicated to particular tasks. The general purpose PS is the reason why Alcatel-Lucent is able to introduce RNC-ORBiT, the next generation Capacity RNC, and HSPA support on the same platform through a software upgrade. Also, Alcatel-Lucent is introducing a next generation Dual Core Packet Server (DCPS) that can further double RNCORBiT processing capacity in UA06. This capacity upgrades (RNC-ORBiT and DCPS) will be optional and can be unlocked through a software unlock capability. Furthermore, such a flexible architecture reduces OPEX, since there are a small number of module types to keep for maintenance purposes.
Figure 2 - Packet Server Physical view
2.4
17B
High Scalability
The Alcatel-Lucent UMTS RNC allows scalable growth from a minimum configuration at network launch to full capacity configuration through software upgrades and interface board additions. Increasing the RNC capacity is extremely easy and flexible for an operator. A multitude of interfaces is provided, allowing connectivity at E1/T1, STM-1 Channelized electrical and/or optical interfaces in the 7670 RSP and ESE Transport Nodes, providing scalability, investment protection and a future evolution path. Additional modules can be added to the Transport Nodes without affecting service. Increased traffic processing (Erlangs, Subscribers, Mbps throughput) only requires the addition of Packet Servers (PS).
11 / 82
APRIL 2007
In UA06 release, RNC-ORBiT processing capacity can be doubled by an optional software upgrade to the RNC 1500 product. In UA06 release, Alcatel-Lucent introduces the DCPS which will double RNC-ORBiT capacity, providing up to 16K Erlangs in a single shelf (32K Erlangs in a cabinet). Alcatel-Lucent UMTS RNC provides a smooth upgrade path which allows operators to optimize their investment: the high scalability of Alcatel-Lucent UMTS RNC fits to the subscriber growth in the network.
2.5
18B
Multi-Service Transmission and IP UTRAN
Alcatel-Lucent supports a variety of transmission interfaces and can therefore be included in many types of transmission networks, thanks to the high flexibility of connectivity boards in the 7670 Alcatel-Lucent portfolio. Alcatel-Lucent UMTS RNC is future proof by being IP ready - DAY ONE. Within the RNC, UMTS application layers (including radio) are independent of the lower layers (transport layers). An IP deployment is then an operator decision driven by business requirements and not based on vendor technology availability. With the Alcatel-Lucent solution, migration to all IP UTRAN can be achieved through software upgrade and the insertion of redundant Gigabit Ethernet interface cards. The 7670 (RSP and ESE) and the Alcatel-Lucent UMTS RNC (based on the MSS15K platform) are multiservice platforms that already support IP.
2.6
19B
Proven Carrier Grade

XTable 1X
Alcatel-Lucent are committed to building highly available, carrier grade and fault redundant products. The focus of the Carrier Grade program on the RNC, shown in , is as follows: Minimize the impacts and frequency of unscheduled outages In UA5.0, RNC-1500 is 99.997% available or 15.75 mins downtime per RNC/year In UA6.0, RNC-ORBiT will be 99.999% available or 5.25 mins downtime per RNC/year 95% faults that result in outages are automatically recovered i.e. without intervention from the operator Minimize outages associated with scheduled maintenance procedures Provide a hitless (zero outage) patching capability to apply minor bug fixes RNC major SW Upgrades involve an outage of < 9 mins All critical processors in the RNC are 1+1 spared If the active processor is taken out of service for any reason (e.g. fault or maintenance action) there will be no disruption in RNC service
12 / 82
APRIL 2007
All traffic carrying processors in the RNC are N+P spared using load-balancing (all traffic carrying processors are active and when one fails the traffic is re-distributed across the remaining processors) Alcatel-Lucent RNC does not support 1+1 sparing of the traffic carrying processors as this would significantly increase system cost and lower the capacity of the RNC Reducing outages (scheduled and unscheduled events) release over release eliminates the need for a 1+1 sparing model for traffic Call processing processors are N+P spared for the cell function All RNC modules are built to last with very low failure rates and high component MTBF RNC Carrier Grade Road Map (Availability) UA4.2 99.995% UA5.0 99.997% Increased on-line Parm modification Overload Control Enhancements Access Class Barring Closure of Field availability gaps UA6.0 99.999% RNC-ORBiT SW Architecture Increased on-line Parm modification RNC-ORBiT patching PSFP soft locking 1+1 Cell sparing UA7.0 99.999% Increased On-line Parm modification Less than 4 minute outage RNC upgrade Hitless capacity expansion
RNC-1500 (UA4.1) Increased On-line Parm modification Closure of field availability gaps RNC-1500 hitless patching Mib Build at W-NMS
Table 1 - RNC Carrier Grade Roadmap The availability numbers in the table above reflect the predictions for each release. However, current field measurements indicate that release UA4.2 is beating our predictions (already 99,999%).
2.7
20B
Efficient Radio Resource Management
Alcatel-Lucent Radio Resource Management (RRM) is an essential piece of the UMTS RNC software that controls the allocation and maintenance of the radio resources during a communication. Efficient radio resource allocation and management is required to guarantee QoS at maximum capacity. The main functions related to Alcatel-Lucent's RRM solution are:
13 / 82

Admission Control
APRIL 2007
The purpose of the admission control is to admit or deny new users. Alcatel-Lucent's admission control mechanism basically consists of two steps and is described in [2]: RAB Matching It performs the mapping of the requested RAB onto one of the supported Radio Bearer (RB) configurations. This step includes a RAB to RB mapping table which provides a mechanism to admit a RAB at a rate lower than the requested Maximum Bit Rate (MBR) according to the cell load and user priority. This function, which is called intelligent RAB Mapping (iRM), only applies to RABs with an Interactive or Background Traffic Class (TC). Call Admission Control (CAC) it is the function located in the CRNC responsible for deciding whether a request to establish a RAB can be admitted in the UTRAN or not based on the available resources. Radio CAC is based on power and OVSF codes in the downlink and on interference in the UL (note that other CAC decisions are performed at transport and node level i.e. Node B and RNC). CAC is applied: At initial admission On RB reconfiguration: RB bit rate downgrading/upgrading, CELL_FACH to CELL_DCH transition, etc On mobility: SHO, Inter-frequency HHO & 2G to 3G HHO The Alcatel-Lucent RNC supports AAL2 CAC i.e. admission control and reservation at the AAL2 channel level as part of establishing new connections.
Congestion Control The task of congestion control is to monitor, detect and handle situations when the system is reaching an overload situation with the already connected users. Alcatel-Lucent's congestion control provides two ways to fight against overload: Preventive actions to avoid overload, this is achieved thanks to iRM If overload happens, congestion handling mechanisms bring the system back to normal load, this is achieved thanks to the iRM pre-emption feature, described in [3]
Note: Congestion Control is not the same as Overload Control (please refer to section 9.1.4). Power Control This group of functions controls the level of the transmitted power in order to minimize interference and keep the quality of the connections. Alcatel-Lucent supports: DL and UL Outer Loop Power Control DL and UL Inner Loop Power Control and DL power balancing UL Open Loop Power Control
Alcatel-Lucent Power control features are described in [5].
14 / 82

Radio Measurements
APRIL 2007
This function performs measurements on radio channels (located in UE and UTRAN). The UTRAN processes these measurements and make use of them for RRM. In addition to these functions, Alcatel-Lucent's RRM solution also provides a set of sophisticated features allowing an operator to make the best usage of its radio resources such as: Switch from CELL_DCH to CELL_FACH and further to CELL_PCH/URA_PCH (and vice versa) based on user activity (Always-On feature), described in [4] RB bit rate downgrading and upgrading based on radio conditions (iRM Scheduling feature), described in [2] Adapt the RB to the application data rate (RB Rate Adaptation Feature), described in [4]
The UA05 is a major content release. A detailed description of the new features introduced in that release can be found in the UMTS5.0 Access Network Feature Planning Guide. HSPA Supported Alcatel-Lucent UMTS RNC and all the Node Bs portfolio support HSPA (both DL and UL) since day one i.e. it is possible to support HSPA technology in Alcatel-Lucent UTRAN solution with a software upgrade only (assuming the presence of an iCEM on the Node B). Alcatel-Lucent introduced HSDPA in the UA04.2 software release and HSUPA/E-DCH in UA05. For a detailed description of Alcatel-Lucents HSPA solution refer to [6] and [18].
15 / 82
APRIL 2007
2B
ARCHITECTURE
System Description
3.1
21B
The Alcatel-Lucent UMTS RNC is based on a single shelf and single platform based product, occupying the lower part of the cabinet: Alcatel-Lucent multi-service data platform called Multi-Service Switch 1500 (MSS15K). The MSS platform leverages best-in-class industry technology, allowing the UMTS RNC an easy evolution from RNC-1500 to RNC-ORBiT. The upper shelf can be populated with a second UMTS RNC, further increasing performance per footprint. Above and beyond taking advantage of over 1000 mature ATM and IP features on MSS, the AlcatelLucent UMTS RNC transparently incorporates leading edge processor modules to deliver high-speed, hightouch bearer services as well as support of control plane functionalities and Radio Resource Management.
Expansion Space for 2nd UMTS RNC
Figure 3 Alcatel-Lucent UMTS RNC cabinet view The Alcatel-Lucent UMTS RNC provides many connectivity options: OC3 or STM1 clear channel E1 or T1 connectivity * STM1 or OC3 Channelized electrical or optical * Gigabit Ethernet Fast Ethernet * OC12 * PoS interface *
Note (*): Using optional 7670 RSP or 7670 ESE Transport Nodes
16 / 82
APRIL 2007
3.2
22B
UMTS RNC Architecture
Alcatel-Lucent RNC is responsible for UMTS call and signalling processing along with the integrated access network OA&M. Also, it provides layer 2 radio protocol processing as well as all external interfaces. The Alcatel-Lucent RNC is based on the Multi-service Switch 15000 system which supports IP, ATM, Frame Relay and voice services. The mapping of the RNC functions, to the AlcatelLucent UMTS RNC are as follows: All of the RNC is contained within a single shelf, which includes Control Plane, User Plane, Interfaces and OAM systems All of the external physical interfaces of the RNC are implemented on the same shelf (IuCS, IuPS, IuPC, IuBC, IuR, and IuB) The packet distribution function is implemented via HW segmentation/reassembly functions on each card that enable packets to be effectively transported transparently across the Multiservice Switch cell switching fabric Both User Plane functions and Control Plane functions are implemented by the Packet Server Functional Processor (PSFP) modules
The Iub physical interface terminates in the RNCs 16pOC-3/STM-1 module for ATM and 4ptGigE module for IP. The RNC can support the Iub with direct ATM SPVC and PVC in Clear Channel OC-3/STM-1. All common equipment is fully duplicated and protected, with continuous in-service and outof-service fault detection.
3.2.1
56B
RNC System Architecture

XFigure 4X
The whole Alcatel-Lucent RNC architecture is based on Packet Server. The PS makes use of off-the-shelf commercial standard compliant processors i.e. PCI mezzanine cards (PMCs). describes the Alcatel-Lucent UMTS RNC system architecture (PS SW functions specified below are relative to the RNC-1500. The evolution of PS functions for RNC-ORBiT is covered in detail in the Software Architecture section).
17 / 82

Network Management
OC3/ OC3/ STM-1 STM-1 FP FP CP3 CP3 CP3 CP3 OC3/ OC3/ STM-1 STM-1 FP FP
APRIL 2007
Fabric Fabric
Fabric Fabric ATM

PC PC
PC PC Master Master OMU OMU NI NI RAB RAB TMU TMU
PC PC Master Master OMU OMU NI NI RAB RAB TMU TMU
...
2 per RNC 2 per RNC
Upto 12
IP
. .. .. .
2 per RNC
RAB RAB TMU TMU
Upto 40 Upto 14
PS Functions (Logical view)
Iub, Iur, Iu
Figure 4 RNC-1500 architecture
3.2.2
57B
Modules Description
The Alcatel-Lucent RNC is based on the MSS 15000, composed of redundant 56.3 Gbps switch fabrics interconnecting 14 functional processors (FPs) and a redundant pair of control processors (CPs). Each FP and CP is connected to each of the switch fabrics via 3.52 Gbps links. The following sections describe all the RNC HW Modules for RNC-1500 and its evolution, the RNC-ORBiT.
3.2.2.1
109B
108B
RNC-1500
CONTROL PROCESSOR (CP3)
The Control Processor (CP3) manages all MSS resources, interfaces with the MDM/MDP management system and contains a local disk for loads and logs. It is responsible for the following functions: Control of base RNC functions such as loading, fault detection and sparing Disk management (20 Gbytes disks minimum) Ethernet access to MDM/MDP via TCP/IP for Out of band OAM connectivity IP routing function for IuPS and OMC-B/Node Bs links
18 / 82
APRIL 2007
The CP3 processor is a Motorola PowerPC 755 at 400MHz with 256MB of RAM. The CP3 is provisioned in 1+1 redundancy scheme and is built on VxWorks operating system.
Figure 5 - CP3 module
110B
PACKET SERVER FP
The Packet Server FP is responsible for all main RNC functionalities, namely: Support Radio Resource Management Performance, Configuration and Fault Management Call processing, Cell and Node B management Call Trace Management Overload controls and load balancing of Control Plane resources Terminates Radio network interface protocols i.e. RANAP, RNSAP, NBAP High-touch Bearer processing (for example RLC/MAC Ciphering and Integrity) Radio protocol handling (MAC, RLC and PDCP) Interface bearer protocols Macro-Diversity Handover combining/splitting) (frame selection, buffering, synchronization,
19 / 82
APRIL 2007
The packet server processor is based on internal open architecture PMC (PCI Mezzanine Card) interfaces for the daughter boards. Each Packet Server FP board hosts 6 PMC. These PMCs are application independent. The RNC-1500 uses PowerPC 7410 (G4) processors operating at 450 MHz with 256 MB of SDRAM. The Packet Server is provisioned in load sharing redundancy scheme. The load is shared between the PMCs with an engineering margin i.e. if one PS fails then the other PSs take over processing.
Figure 6 - Packet Server FP module
111B
OC3 / STM1 FP
The 16 Port OC-3/STM-1 FP (PQC and MS3 variants available) is a standard MSS 15000 FP which implements all of the Alcatel-Lucent RNC physical interfaces. The connections created on it are standard ATM PVCs or SPVC with AAL2 and AAL5 (IP) traffic including OAM flow. The OC3/STM1 FP has 16 ports and is available in single and multi-mode (multi-mode available optionally with the MS3 variant). This FP contains 16 OC-3/STM-1 duplex fiber optic transceivers and supports either one user-network interface (UNI) or one ATM networknetwork interface (NNI) for each port. The FP can operate from either side of the user/network boundary. Each OC-3/STM-1 ATM port supports a line rate of 155.52Mbit/s that operates in B-ISDN mode. The OC3 FP runs on Motorola Power PC 750 processors at 233MHz and with 128MB of RAM. It is provisioned in 1+1 redundancy scheme and supports Automatic Protection Switching and as such is able to recover from board failure within 50ms.
20 / 82
APRIL 2007
Figure 7 - 16p OC3/STM1 card.
112B
MSS15K FABRIC
The two MSS15K fabric cards provide high-speed serial links between the processor cards (Control Processor and Function Processor) of the switch. Key fabric attributes: MSS 15000 has two 56.3Gbit/s redundant switching fabric cards. Each non-blocking fabric card interconnects the processor cards in a full mesh network configuration. Sixteen 3.52 Gbit/s bi-directional serial links connect each fabric card to the sixteen CP and FP cards of the shelf. Cell switching is connectionless and self-routing cells to be switched by the fabric contain QoS and routing tags. The fabric switches cells based on these tags.
With a disabled fabric, the node is in single-fabric (still 56Gbps capacity) mode and all processor card cells run on the enabled fabric. MSS 15000 automatically switches between single and dual-fabric mode depending on the state of the individual fabrics.
21 / 82
APRIL 2007
Figure 8 - Fabric module
113B
BREAKER INTERFACE PANEL
The Breaker Interface Panel (BIP) provides a central location where redundant DC power feeds (nominal -48/-60 V) of up to 100A are connected to the switch and routed to up to four breaker modules. Power is distributed from these breaker modules to the shelves and cooling units. The RNC supports the use of either a two- (single shelf) or a four-breaker (dual shelf) BIP. The BIP also contains an alarm unit, which monitors system components and generates alarm indications. The BIP provides A and B redundant power supplies to each RNC1500 shelf. Both A and B distribute power to the shelf via 4 x 25 amp breakers plus 1 x 5 amp for the cooling unit.
3.2.2.2
114B
RNC-ORBiT
With the launch of RNC-ORBiT in release UA06, Alcatel-Lucent introduces the DCPS, CP4 and the 4-port Gigabit Ethernet HW modules in addition to the RNC-1500 modules which will continue to be supported.
22 / 82

DUAL CORE PACKET SERVER FP
APRIL 2007
115B
The Dual Core Packet Server (DCPS) is the evolution of the packet server and is introduced in UA06. The DCPS will continue to be responsible for all main RNC functionalities, and will enable up to four times the RNC-1500 capacity whilst still using a single shelf, thus producing the highest density RNC on the market. The DCPS uses three Dual-Core 1.3GHz 8641D PowerPC processors with a total of six PowerPC CPU cores with 512 MB per core. The DCPS supports a faster serial rapid IO bus and IP Packet handling (PQC12). Furthermore, the DCPS is DMA capable and its robustness is improved with Serial Rapid IO.
116B
CONTROL PROCESSOR (CP4)
The CP4 is next generation control processor which enables full capacity of the RNC-ORBiT with DCPS (4x RNC 1500 UA05 capacity). The CP4 provides the following benefits to the RNCORBiT: Highest capacity RNC in the market (with DCPS) Improved reliability Higher-reliability 7200 RPM 80G IDE disk drive ECC detection and correction on CP4 main memory Enable memory parity checking on EMEM Improved performance 7200 RPM 80G IDE disk (vs. 4200 in CP3), 8M cache Faster seeks (10ms vs. 12ms) and latency (4ms vs. 7ms with CP3) Improved memory technology - DDR memory supporting DMA bursts at 266MHz; Up to 2G memory (256M with CP3)
117B
4-port Gigabit Ethernet FP
The 4-port Gigabit Ethernet (4pGe) FP provides four full-duplex Gigabit Ethernet ports (via SFP module sockets that support either optical or electrical SFP modules). Separately ordered small form-factor pluggable (SFP) optical transceiver modules are required to provide optical signal reception and transmission. For a port on the 4pGe card to be operational, the SFP socket must be equipped with the appropriate SFP module. The software name (card type) of the NTHW49 is 4pGe. Operators wishing to deploy Alcatel-Lucent RNC in an IP UTRAN simply add 1+1 4ptGigE cards to the system. If operators want to continue to support ATM on some Iu interfaces e.g. Iub, then they maintain the 16pOC3 1+1 cards in addition. As there are 16 slots on the RNC shelf this means that a maximum of 10 PSs can be supported when both OC3 and GigE are used.
23 / 82
APRIL 2007
Figure 9 - 4pt Gigabit Ethernet module
3.2.3
58B
RNC Software Architecture
The Alcatel-Lucent UMTS RNC software architecture has been designed to provide high performance, scalability, and robustness. The architecture is aligned with 3GPP standards objectives of separating control and user plane functionality. To set the context for the UA06 RNC-ORBIT new software architecture, the RNC-1500 architecture is described first. Then the new elements of the RNC-ORBiT architecture will be described.
3.2.3.1
118B
RNC-1500
The RNC-1500 PCI Mezzanine Cards (PMCs) on the PSFPs run a well defined set of software components (figure 5). The software running on each PMC is indicated by its role. The PMC roles supported by RNC-1500 are the following: Master (PMC-M): there are two PMC-M per RNC. It is used for the management of all the other PMCs. It contains the Resource and Transport managers. PMC-Ms are 1+1 spared i.e. 1 active and 1 standby per RNC and must be on separate PSs. Protocol Converter (PC): there is one per PSFP, with a maximum of 12 per RNC. The functionalities handled by the PC are AAL2 and Segmentation and reassembly (SAR) functions to do IP/AAL5 conversions and vice versa. PCs are shared N+1. Radio Access Bearers (PMC-RAB): up to 40 per RNC. The functionalities handled by PMC-RAB are high touch bearer processing, Radio Protocol Handling (MAC, RLC...), Interface bearer, Macro Diversity Handover. PMC-RABs work in load sharing redundancy. Network Interface (PMC-NI): there are two PMC-NI per RNC. PMC-NI hosts the functionality of the MTP3b and SCCP layers of the SS7 stack. PMC-NIs is 1+1 spared i.e. 1 active and 1 standby per RNC and must be on separate PSs. Traffic management units (PMC-TMU): Up to 14 per RNC. This PMC-TMU terminates Radio network interface protocols i.e. RANAP, RNSAP and NBAP. It also supports Radio Resource Management functionalities. PMC-TMUs are shared N+P.
24 / 82
APRIL 2007
OAM Management Units (PMC-OMU): there are two PMC-OMU per RNC. It manages Control Plane functions on RNC-1500 (equivalent to PMC-M of user plane), like Performance, Configuration and Fault management, Call Trace management, Overload Controls and load balancing of Control Plane resources, Radio Network Subsystem OAM&P. PMC-OMUs are 1+1 spared i.e. 1 active and 1 standby per RNC and must be on separate PSs. PMC role assignment is deterministic in the RNC-1500 as shown in the figure below. Slo t 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Card Type CP3 CP3 PS PS PS PS PS PS OC3/STM1 OC3/STM1 PS PS PS PS PS PS 0 1 2 3 4 5
PMC-M PMC-M RAB RAB RAB RAB
TMU TMU TMU TMU TMU TMU
RAB RAB NI NI RAB RAB
RAB RAB RAB RAB RAB RAB
PC PC PC PC PC PC
RAB RAB OMU OMU RAB RAB
PC PC PC PC PC PC
RAB RAB TMU TMU RAB RAB
Figure 10 - PMC role assignment in the RNC-1500 (12 PSFP full configuration)
3.2.3.2
119B
RNC-ORBiT
The RNC-ORBiT provides wireless services on a high capacity, high availability platform, while maintaining the customer investment in their existing RNC-1500 platform as RNCORBiT is a software upgrade only. The increased capacity can be unlocked by purchasing capacity license keys on a pay as you grow basis. An innovative approach to software design has been taken with the RNC-ORBiT product. The user plane functionality handled by the RAB and PC processors has been redesigned using Optimized Radio Bearer Technology (ORBiT). Furthermore, the user plane software has been re-designed to process as much user traffic as possible using as little CPU as possible. This allows fewer processors to be dedicated to user plane, hence the number of TMUs in the system can be doubled, thus doubling the RNC capacity.
25 / 82
APRIL 2007
Additionally the software re-architecture provided the opportunity to redesign cell handling: all Cell processing functionality has been isolated to run on separate Application Processing Complexes (APCs) which are now 1:1 spared. This greatly improves the robustness of the product as cell loss (common channels) is minimized upon a single processor failure. With the introduction of RNC-ORBiT, three new APC roles are defined which replace the PMCM, RAB and PC roles: OPS (Optimized radio bearer interface technology for Packet and Signaling) OCS (Optimized radio bearer interface technology for Circuit and Switched traffic) CMU (Cell Management Unit) handles cell processing
The following diagram illustrates how the RNC1500 internal role structure has been modified for RNC-ORBiT.
Figure 11 RNC-ORBiT Roles Evolution The PMC roles supported by RNC-ORBiT are described below: Network Interface (NI): there are two PMC-NIs per RNC. PMC-NI hosts the functionality of the MTP3b and SCCP layers of the SS7 stack. PMC-NI is 1+1 spared i.e. 1 active and 1 standby per RNC and must be on separate PSs. Traffic Management Unit (TMU): there are up to 24 PMC-TMUs per RNC. This PMC-TMU terminates radio network interface protocols RANAP, RNSAP. It also manages the call processing for the UEs. TMUs are N+P spared. In a full shelf RNC, all 24 TMUs are active. However, the full provisioned capacity of the RNC has to be supported by 22 TMUs to maintain provisioned capacity in case of a PSFP failure. OAM Management Units (OMU): there are two PMC-OMUs per RNC. The PMC-OMU manages Control Plane OAM functions such as Configuration Management (CM), Performance Management (PM), Fault Management (FM) and Call Trace Management (CT). PMC-OMU is 1+1 spared i.e. 1 active and 1 standby per RNC and must be on separate PSs.
26 / 82
APRIL 2007
Cell Management Unit (CMU): there are up to 12 PMC-CMUs per RNC. The PMC-CMU handles the Control Plane functionality for Cells supported by the RNC. It terminates the NBAP, ALCAP and SSCOP for Iub protocols. Furthermore, it manages the Call processing for Node Bs and also handles Q.AAL2 for Iub and connection for AAL5 VCCs. PMC-CMUs are 1+1 i.e. there are up to six pairs of active/passive CMUs. Orbit CS (OCS): there are up to 12 PMC-OCSs per RNC. The functions performed are: radio Access Bearer Channels management for Circuit switched calls; AAL2 segmentation and reassembly, tunneling, Iub bandwidth Limitation measurements; IubDch, Diversity HandOver Selection (DHO), Outer Loop Power Control; CSV and CSD full path (Iu CS, RLC TM); User Plane support for Cells: Cell FACH support, Paging, MAC-C, IubCch; Sparing (Cell, Calls, and AAL2); User Plane Counters, Call Trace; ORBit Binary Logging (OBL); PMC-OCSs are spared using an N+P load sharing model. Orbit PS (OPS): there are up to 20 PMC-OPSs per RNC. The functions performed are: Termination of Packet Switched RABs and SRBs; RLC AM, UM; RRC User plane SRB relay; GTPu, Iu PS; MAC-d; User Plane Counters, Call Trace; ORBiT Binary Logging (OBL). PMC-OPSs are not spared. PMC role assignment is deterministic in the RNC-ORBiT as shown in the figure below. Slo t 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Card Type CP4 CP4 DCPS DCPS DCPS DCPS DCPS DCPS OC3/STM1 OC3/STM1 DCPS DCPS DCPS DCPS DCPS DCPS 0 1 2 3 4 5
CMU CMU CMU CMU CMU CMU
OCS OCS OCS OCS OCS OCS
OPS OPS OPS OPS OPS OPS
NI NI OMU OMU OPS OPS
CMU CMU CMU CMU CMU CMU
OCS OCS OCS OCS OCS OCS
Figure 12 PMC role assignment in the RNC-ORBiT (12 DCPS full configuration) Migration from RNC-1500 to RNC-ORBiT will be done through a seamless software upgrade which doubles the capacity. This has been made possible by the introduction of the new RNC-ORBiT architecture that makes use of patented signal and parallel vector processing techniques for the user data plane processing. The optimized user data plane processing allows to use less processors dedicated to user plane and to increase the number of processors needed for control plane thus increasing the overall RNC capacity. The same role configuration shown in , applies to both PSFP and DCPS cards.
XFigure 12 X
Due to the introduction of CMU roles which are 1+1 spared, the PSFP cards can be logically grouped in pairs (slot [2, 3] [4, 5] [6, 7] [10, 11] [12, 13] [14, 15]) where each pair hosts a service group.
27 / 82
APRIL 2007
3.3
23B
Transport Nodes: 7670 RSP and ESE
7670 RSP and 7670 ESE transport nodes are optional and allow RNC traffic to scale independently of connectivity: they are used to provide additional connectivity options in addition to OC3 / STM1 and Gigabit Ethernet. The 7670 RSP is a medium/large RNC transport node primarily used for RNC aggregation i.e. N:1 (RNC:RSP). The 7670 ESE is a small/medium RNC transport node primarily used to provide E1 and STM-1 aggregation i.e. 1:1 or 1:N (RNC:ESE). The following sections describe in more detail the 7670 RSP and ESE equipment.
3.3.1
59B
7670 Routing Switch Platform (RSP)
The Alcatel-Lucent 7670 Routing Switch Platform (RSP) is a highly scalable and configurable switching and routing platform designed to provide carriers with the utmost flexibility to increase revenue generating opportunities. Optimized for the next generation multi-service Internet protocol (IP) network, the Alcatel-Lucent 7670 RSP delivers new VoIP, IP VPN and multimedia services as well as existing data services and service level agreements. This multi-service IP platform delivers multiple Layer 3 and Layer 2 services reliably and concurrently. Any service can be provided, using IP, MPLS, ATM, time division multiplexing (TDM), frame relay, Gigabit Ethernet (GigE), 10/100 Ethernet, and packet over SONET (POS). By allowing service providers to harmoniously mix new and traditional services on their existing infrastructure, they can protect established, high revenue services and role out new services quickly, throughout the entire serving area. Currently in the Alcatel-Lucent UTRAN portfolio the following interfaces are deployed: 8p OC3/STM1oCh 8p STM1eCh 2p OC12oCh 16p OC3/STM1c 16p OC3/STM1oPOS
60B
3.3.2
7670 Edge Services Extender (ESE)
The Alcatel-Lucent 7670 Edge Services Extender (ESE) supports the reliable, cost effective delivery of IP, Ethernet, Frame relay, ATM, and circuit emulation services. The AlcatelLucent 7670 ESE builds upon the carrier class service capabilities, high availability and flexibility of the Alcatel-Lucent 7670 Routing Switch Platform (RSP) to accommodate growing traffic demands and evolving service requirements. It can be deployed to extend the reach of an Alcatel-Lucent 7670 RSP to the edge of a carrier's network or as a standalone system providing multi-service adaptation, aggregation, switching, and flexible service delivery over OC-12/STM-4 or OC-3/STM-1 aggregates. Currently in the Alcatel-Lucent UTRAN portfolio the following interfaces are deployed: 32p T1/E1 MS 1p OC3/STM1oCh MS 1p STM1eCh MS OC3/STM1c 10/100 Ethernet
28 / 82
APRIL 2007
3.4
24B
RNC Capacity
The objective of this section is to provide the reader with basic information on the capacity of Alcatel-Lucent UMTS RNC-1500, focusing on key elements allowing for instance to compare the performance of RNCs from different suppliers. The information provided here is for information purposes only. Please refer to Alcatel-Lucent RNC Capacity Roadmap [1] for official capacity commitments and call profile details.
3.4.1

61B
RNC Capacity Metrics
The RNC capacity is defined in three dimensions: traffic coverage connectivity
These dimensions are independent, thus the RNC capacity is determined by the most constraining limit. A definition of the metrics and call profile(s) Alcatel-Lucent uses to provide capacity commitments are provided in the RNC Capacity Roadmap [1].
3.4.2
62B
RNC-1500 UA05 Capacity and Scalability

XTable 2X
The capacity commitments for Speech and Mobile Office Internet profiles for the UA05 release are provided in . Service & Bearer Iu Mbit/s Applicatio n Layer
49 140 110 176 220 130 220 88 88
Capacity of RNC-1500 Iu Mbit/s Physical Layer

83 180 130 217 270 160 260 120 120
RAB
CS Conv.12,2AMR CS Conv. 64 PS I/B 64/64 PS I/B 64/128 PS I/B 64/128 PS I/B 64/64 PS I/B 64/384 R99 RABs R99, HSDPA & EDCH RABs
Typical Service
Speech Video Telephony Basic Browsing Mobile Office Internet Video Streaming Audio Streaming Mobile Office Premium R99 Service-mix HSPA Servicemix
Reference Subscribers
225 000 100 000 530 000 500 000 130 000 140 000 220 000 49 000 70 000
Simultaneous TRB subscribers

3900 1100 3000 2500 1700 2100 1100 2500 2500
Table 2 RNC-1500 Capacity with UA05 Software
29 / 82
APRIL 2007
The Alcatel-Lucent RNC is a very scalable platform, and can be configured to meet different network capacity needs, as shown in .
XTable 3X
RNC-1500 Market Models 1504 Node B Cells Speech (Erlangs) Mobile Office Internet (Mbit/s)
MD UA06; Introduced in UA06
1506 120 600 1600 73
1507 140 720 2000 88
1508 160 800 2550 105
1510 200 1200 3300 147
1512 200 1200 3900 176
80 360 980 44
Table 3 - RNC-1500 Scalability with UA05 Software
3.4.3
63B
RNC Capacity Border Limits
Border limits define the maximum operating range of the RNC for a given release i.e. the maximum capacity figures that cannot be exceeded irrespective of call profile. The following border limits exist on the RNC: 310Mbps Iu DL throughput on the current 16pOC3/STM1 (PQC based) Card A new version of the 16pOC3/STM1 (MS3 based) is being introduced in UA05 that supports line rate (upto 2.5Gbps) IP forwarding CELL_PCH and URA_PCH RRC context states are introduced. A fully configured UA05 RNC-1500 can support a maximum of 41640 RRC contexts. The following is a breakdown of the different RRC contexts pools: Max number of CS RRC contexts: 6048 Max number of PS RRC contexts: 8640 Max number of UE RRC contexts: 9600 Max number of CELL_PCH RRC contexts: 7020 Max number of total CELL_PCH and URA_PCH RRC contexts: 32,040 Max number of FACH RRC contexts: 7020 A fully configured UA06 RNC-ORBiT with DCPS can support: Max number of CS RRC contexts: 12096 RNC-ORBiT; 24192 with DCPS Max number of PS (DCH+FACH) RRC contexts: 17280 RNC-ORBiT; 34560 with DCPS Max number of FACH RRC contexts: 14040 RNC-ORBiT; 28080 with DCPS Max number of CELL_PCH RRC Contexts: 14040 RNC-ORBiT; 28080 with DCPS Max number of total CELL_PCH and URA_PCH RRC contexts: 64080 RNC-ORBiT; 128160 with DCPS
30 / 82
APRIL 2007
This page has been intentionally left blank
31 / 82
APRIL 2007
3B
INTERFACES
The Alcatel-Lucent UMTS RNC provides standard defined interfaces towards core networks (Iu), Node Bs (IuB) and other RNCs (IuR). It also provides an interface to the OMC-R network management subsystem, along with optional transport facilities to carry OMC-B signalling between Node Bs and OMC-B.
4.1
25B
UTRAN Transport ATM to IP Evolution
Alcatel-Lucent UTRAN and 3GPP transport today is based on ATM with a feature rich ATM implementation. The RNC supports multiple ATM service categories on each interface (Iu, Iur and Iub). Operators who deploy Alcatel-Lucents UTRAN solution do not have to overbook scare Iub resources (T1/E1s). Furthermore, Alcatel-Lucent supports Soft PVCs on each Iu, IuB and IuR interface which provides path redundancy i.e. a path fails, PNNI will re-route traffic on a separate S-PVC.
Figure 13 - Alcatel-Lucent RNC ATM transport A seamless transition from ATM to IP UTRAN transport is supported through a software upgrade and the addition of new Gigabit Ethernet interface cards. The Alcatel-Lucent RNC can support simultaneously IP and ATM interfaces, which is essential as operators upgrade from ATM Node Bs to IP Node Bs. Also, operators may wish to keep Node Bs with E1/T1 connectivity over ATM as Alcatel-Lucents ATM implementation provides the most efficient usage of scarce bandwidth. Alcatel-Lucent supports IP Pico (as specified in the next section), hybrid Node Bs and IuPS over IP in its current portfolio. Support of a full IP RAN is already under development.
32 / 82
APRIL 2007
CS Core Network Elements
ATM ATM Transport Transport Networks Networks
All traffic on ATM
RNC2500
ATM MacroBTS ATM ATM Transport Transport R99 & optionally HSPA Hybrid MacroBTS HSPA on IP IP Transport IP Transport
IuB
VLAN GE
IuCS, IuR, IuPS

VLAN GE IP IP Transport Transport Networks Networks
RNCs
All traffic on IP Pico IP
IP Virtual Router Traffic Separation
PS Core Network Elements
Figure 14 - Alcatel-Lucent RNC seamless evolution to IP transport
4.2
26B
IP Transport on IuB
In addition to ATM, the Alcatel-Lucent RNC supports IP transport on the IuB interface. This is a key step towards a full IP-RAN network providing OPEX and CAPEX savings to the UMTS operators. Support for a native IP IuB interface (3GPP compliant IP User and Control plane stacks) is introduced for IP Pico Node Bs (figure 16). A native IP IuB interface is introduced through a software upgrade and the addition of two 4ptGigE Cards on the RNC. No forklift is required and the existing STM1 cards can be used for any interfaces that remain on ATM transport.
Figure 15 - Alcatel-Lucent RNC Native IP IuB The introduction of the native IP IuB Interface does not modify the existing RNC carrier Grade mechanisms e.g. 1+1 on critical processors and N+P on traffic processors, continues to function as is. The Alcatel-Lucent RNC has the ability to segment the IuB control from the other IP interfaces thanks to the implementation of a dedicated IuB Virtual Router. If segmentation is not required, a common virtual router can be used for Iub and other interfaces.
33 / 82
RADIO NETWORK CONTROLLER (RNC) PRODUCT DESCRIPTION 4.3

4.3.1
APRIL 2007
27B
RNC to Core Network (Iu)

64B
Definition
The Iu interface connects the UTRAN to the Core network. The Iu interface towards the PSdomain of the core network is called Iu-PS, and the Iu interface towards the CS-domain is called Iu-CS. The SCCP is used to support signalling messages between the Core Network Domains and the RNC. One user function of the SCCP, called Radio Access Network Application Part (RANAP), is defined. The RANAP uses one signalling connection per active UE and Core Network Domain for the transfer of layer 3 messages. Both connectionless and connection-oriented procedures are used to support the RANAP. The Alcatel-Lucent RNC supports IuFlex which enables many-to-many relations between RNCs, SGSNs and MSCs. ATM and IP stacks for Iu-CS and Iu-PS are shown in and respectively. Note, that AlcatelLucent will support IP over Gigabit Ethernet only i.e. IP over AAL5 for control plane is not planned. IP over AAL5 for PS User plane is supported today.
XFigure 16 X XFigure 17 X
Radio Network Layer
Control Plane RANAP
User Plane Iu UP Protocol Layer
Transport Network Layer
Transport Network User Plan e
Transport Network Control Plane

Q.2630. 2
Transport Network User Plane
SCCP M3UA MTP3b SSCF NNI SCTP IP SSCOP AAL5
Q.2150.1 MTP3b SSCF NNI SSCOP AAL5 AAL2 RTP/ RTCP*) UDP/IP
Data Link
ATM
ATM
Physical Layer
ATM
Data Link
*) RTCP is optional.
Figure 16 - Iu-CS protocol stacks ATM and IP
34 / 82

Radio Network Layer Control Plane RANAP User Plane Iu UP Protocol Layer
APRIL 2007

SCCP MTP3-B SSCF-NNI SSCOP AAL5 IP IP M3UA SCTP M3UA SCTP
Transport Network Control Plane
GTP-U UDP IP AAL5
GTP-U UDP
IP
ATM
Data Link
ATM
Data Link
Physical Layer
Physical Layer
Figure 17 - Iu-PS protocol stacks ATM and IP
4.3.2
65B
Implementation
AAL5 virtual circuits are used to transport the IP packets across the Iu interface toward the packet switched domain. Multiple VCs can be used over the interface. There is a one-to-one relationship between the VC and the IP address as required by Classical IP over ATM. AAL2 Signalling Protocol (Q.2630.1 formerly referenced as Q.aal2) is used for establishing AAL2 connections towards the PSTN/ISDN domain. Dynamic management of GTP tunnel is ensured by user plane towards PS domain. The physical layer is supported by OC3/STM1, and provides APS/MSP protection.
4.4
4.4.1
28B
Iu-PC Interface
66B
Definition
As wireless communication is inherently mobile, emergency E911 (in North America) or E112 (in Europe) service has not been available due to the lack of knowledge of the location of the user. One method of overcoming this limitation is the Global Positioning System (GPS) which can be used to locate any point on the earth to within 10 meters under good conditions.
35 / 82
APRIL 2007
Network A-GPS introduced in UA03.2, consists in locating the geographical position of a mobile with A-GPS positioning technologies. This location based technology is capable of enabling a wireless network to pinpoint a users location within 10 meters of the exact geographical location. To support this technology, the UE must be equipped with a GPS receiver and the RNC must be connected to a Standalone A-GPS SMLC (SAS). The Iu-PC interface is a logical interface for the interconnection of the SAS and the RNC. The SAS provides information and processing for assisted position calculation. The RNC communicates between the UE and the Core Network in order to aid the position calculation and communicate that position to the Core Network.
4.4.2
67B
Implementation
The RNC connects to the operators IP network using ATM while the SAS connects using Ethernet. The operator is free to choose at which point in the IP network the Iupc traffic will pass through an ATM/Ethernet router/gateway. Position Calculation Application Part (PCAP) provides the signalling services between the RNC and the SAS. The Iupc protocol is only defined between the external ATM interface on the RNC and the external Ethernet interface on the SAS. Within the SAS or the RNC the PCAP traffic may be carried by different transport mechanisms. PCAP requests and responses between a PMC-TMU and the SAS are handled by the TCP Application Layer (TAL) relay function in the PMC-NI. The PCAP based messages are transported over TCP/TAL/IP/AAL5/ATM. The Iupc transport uses the existing MSS ATM and IP capabilities to provision IP connectivity between the Iupc address and the SAS IP addresses.
120B
Types of A-GPS
Unfortunately, a GPS receiver can take a significant amount of time (one or more minutes) to determine its exact position (the time to fix) without knowing its approximate position first, which is obviously not desirable in an emergency. To overcome this limitation two types of Assisted GPS (A-GPS) services are defined: UE-assisted: where the location calculation is performed in the network UE-based: where the location calculation is performed in the handset To support a UE-assisted positioning attempt involving a single UE, an RNC provides a SAS with one or more sets of GPS measurement data. Subsequently, the SAS calculates the position estimate of the specific UE and returns this result to the RNC. In the UE-based mode, assistance data is transmitted by the wireless network to the UE (as opposed to waiting for the information from the satellites) with which the location calculation can be done quickly, thus significantly reducing the time to fix. A-GPS can reduce the time to fix to less than five seconds, an acceptable delay in an emergency.
36 / 82

A-GPS Services
APRIL 2007
121B
Position calculator service They are related to a single UE and involve the transfer of GPS measurement data and UE position estimate data over the Iupc interface between the SRNC and the SAS. They utilize connectionless signalling transport provided by the Iupc signalling bearer. Information exchange service They involve the transfer of GPS related data over the Iu-PC interface between the RNC and the SAS on demand, on modification, or at regular intervals. They use connection-oriented signalling transport provided by the Iu-PC signalling bearer.
Figure 18 - Iu-PC protocol stack Note: For the UA04.x release the standard transport network layer Iupc protocol stack (shaded in grey) is not supported.
4.5
4.5.1
29B
RNC to Node B (IuB)

68B
Definition
The Iub interface connects the RNC to a Node B allowing negotiation of radio resources, for example to add and delete cells controlled by the Node B to support communication of the dedicated connection between UE and SRNC.
37 / 82
APRIL 2007
Figure 19 - Iub protocol stack ATM Note: Alcatel-Lucent implementation of the IuB interface is fully compliant with 3GPP. Support for ALCAP (Q.2630.2) is optional and will be supported by Alcatel-Lucent RNC in UA06 release. An ALCAP protocol is not required in case both UTRAN nodes are using the IP transport option. In order to support a seamless transition to IP, Alcatel-Lucent RNC will simultaneously support ATM and IP interfaces. The IP Iub control and user plane stacks are shown in .
XFigure 20 X
C-Plane
NBAP SCTP IP
U-Plane
Iub FPs UDP
Ethernet
Figure 20 IuB protocol stack IP
38 / 82
APRIL 2007
Logical O&M is the signalling associated with the control of logical resources (channels, cells) owned by the RNC but physically implemented in the Node B. The RNC controls these logical resources. A number of O&M procedures physically implemented in the Node B impact on the logical resources and therefore require an information exchange between RNC and Node B. All messages needed to support this information exchange are classified as Logical O&M forming an integral part of NBAP over the Iub interface.
4.5.2
69B
Implementation
The signalling bearer for NBAP is a point-to-point protocol. There may be multiple point-topoint links between an RNC and a Node B. The signalling bearer in the Radio Network Control Plane is SAAL-UNI over ATM in R99. ATM and AAL2 are used at the standard transport layer for Iub RACH, FACH, and DSCH data streams. Asynchronous Transfer Mode (ATM) and ATM Adaptation Layer type 2 (AAL2) are used as a transport layer for DCH data streams on Iub interfaces. It is possible to multiplex several DCH for one user on the same connection. Service Specific Segmentation and Reassembly (SSSAR) sub layer for AAL2 is used for the segmentation and reassembly of AAL2 SDUs. The ATM physical layer is supported: Either by OC3/STM1, with APS protection, if a Transport Node is not used Or by fractional E1 supporting IMA, if a Transport Node is used
The signalling bearer in the Radio Network Control Plane is NBAP over SCTP over IP. ALCAP (Q2630.2) is not required on IuB when both nodes are IP based. In Alcatel-Lucents IuB over IP implementation, Alcatel-Lucent will only support an Ethernet interface (GigE, Fast Ethernet) and E1 / DS1s L1 interfaces. Alcatel-Lucent does not currently plan to support IP over AAL5.
4.6
4.6.1
30B
RNC to RNC (IuR)

70B
Definition
The IuR interface enables the exchange of signalling information between two RNCs; one or more IuR data streams may exist. The SCCP is used to support signalling messages between two RNCs. One user function of the SCCP, called Radio Network Subsystem Application Part (RNSAP), is defined. The RNSAP is terminated at both ends of the Iur interface by an RNC. Both connectionless and connection-oriented procedures are used to support the RNSAP. Note: The SCCP/M3UA/SCTP/IP/AAL5 stack is not implemented in the RNC.
39 / 82
APRIL 2007
Figure 21 IuR protocol stack ATM Note: Alcatel-Lucent implementation of the IuR interface is fully compliant with 3GPP. Support for ALCAP (Q.2630.2) is optional and will be supported by Alcatel-Lucent RNC in UA06 release. An ALCAP protocol is not required in case both UTRAN nodes are using the IP transport option.
C-Plane
RNSAP SCCP M3UA SCTP IP
U-Plane
Iur FPs UDP
Ethernet
Figure 22 - IuR protocol stack IP
40 / 82
APRIL 2007
4.6.2

71B
Implementation
The ATM IuR implementation is as follows The Signalling bearer for RNSAP is either the SS7 through SSCOP or IP. PVC is established through AAL5. Asynchronous Transfer Mode (ATM) and ATM Adaptation Layer type 2 (AAL2) are used as a transport layer for DCH data streams on IuR interfaces. Service Specific Segmentation and Re-assembly (SSSAR) sub-layer for AAL2 is used for the segmentation and re-assembly of AAL2 SDUs. AAL2 signalling protocol Capability Set 1 is the signalling protocol to control AAL2 connections on Iur interface. MTP-3B and SAAL-NNI are used as a signalling for AAL2 signalling. Signalling Transport Converter for MTP-3B is applied. The physical layer is supported by OC3/STM1, and provides APS protection.
The signalling bearer in the Radio Network Control Plane is RNSAP/SCCP/M3UA over SCTP over IP. ALCAP (Q2630.2) is not required on Iub when both nodes are IP based. In AlcatelLucents Iub over IP implementation, Alcatel-Lucent will only support an Ethernet interface. Alcatel-Lucent do not currently plan to support IuR over IP over AAL5.
4.7
4.7.1
31B
Iu-BC Interface
72B
Definition
The Iu-BC interface, supported from UA05, connects the UTRAN to the Broadcast Domain in the CN. There shall not be more than one Iu-BC interface from an RNC towards the CN. The figure below shows the protocol structure for the Iu-BC.
Radio Network Layer SA Broadcast Plane SABP Protocol Layer
TCP IP AAL5
TCP
IP
ATM
Data Link
Physical Layer
Figure 23 Iu-BC Interface Protocol Structure towards Broadcast Domain In Alcatel-Lucent implementation, the TCP/IP/AAL5/ATM stack is available.
41 / 82
APRIL 2007
The Service Area Broadcast Protocol (SABP) is the protocol between Cell Broadcast Centre (CBC) and RNC needed for the CBC Application. The basic network structure of the CBS is shown in the figure below.
UTRAN UE UE Node B RNC Node B Iub Uu IuBC 1
Cell Broadcast Center (CBC)
Figure 24 Cell Broadcast Centre basic network structure The CBC is part of the core network and connected to a routing node e.g. a 3G SGSN via the Bc reference point. Thus the CBC can reach every RNC via the user plane of the Iu interface. On the logical interface between the CBC and the RNC a mandatory protocol shall be defined.
4.8
32B
OMC Connectivity Options to the RNC
The OMC-R link is unique per RNC and is based on TCP/IP over Ethernet (Out-of-Band OMC connectivity), through the CP board. In order to deal with sites with no Ethernet connectivity for OAM data, In-Band OAM management will also be provided, by simply leveraging ATM switching capabilities of the MSS platform. In this case, IP flow containing OAM signalling will be sent to the OMC-R on top of AAL5 ATM on the same STM1 that is used to carry Iu protocol. This type of OMC connectivity is handled by the 16ptOC3/STM1 board. In-Band connectivity will also be supported through the IP over Ethernet when the 4ptGigE card is available in UA06.
Figure 25 - OMC Connectivity (In-Band and Out-of-Band)
42 / 82
RADIO NETWORK CONTROLLER (RNC) PRODUCT DESCRIPTION 4.9

4.9.1
APRIL 2007
33B
Interfaces Specifications
73B
OC-3/STM1
The Iu, IuR and IuB interfaces will be supported over the OC-3 Line Module. The OC-3 Line Module consists of 16 physical SONET/SDH interfaces configured as STS-3c or STM-1. The function of the OC-3/STM-1 module is to perform all physical layer functions necessary in the MSS15K. This includes SONET/SDH overhead processing and transmission convergence. All physical layer overhead is terminated at the OC-3/STM-1 Line Module. On the fabric side of the MSS15K, the OC-3/STM-1 module passes and receives ATM cells which are encapsulated into a proprietary format (Falcon cells) which enable MSS to be multiservice (IP, Frame-Relay, ATM, MPLS, Ethernet). The optical budget for the OC3/STM-1 interface is as follows: Single mode Optical fibre 1310 nm Intermediate Reach (can be used for distances of < 20km) Laser Output Power: -15.0 dBm Guaranteed Receiver Sensitivity: -28.0 dBm Maximum Receive Level: -8.0 dBm Guaranteed System Gain: 13.0 dB This interface is compliant with the applicable sections of the following standards : ITU-T I.432 ITU-T G.783 ITU-T G. 957
74B
4.9.2
E1
This interface can be used for IuB physical layer (if a Transport Node is used). It is compliant with the applicable sections of the following standards: ITU-T G.703 (excluding Annex B) ITU-T G.704 ITU-T G.706 ITU-T G.732 ITU-T G. 823 ITU-T I.323.1
ATM Inverse Multiplexing (IMA) (Inverse Multiplexing for ATM version 1.1 AF-PHY0086.001, March 99) is used on the IuB interface.
4.9.3
75B
Synchronization
The RNC synchronization scheme follows the MSS 15K synchronization scheme. The MSS network clock synchronization system ensures that the clock used by MSS interfaces is the identical clock used by all interfaces across the network such that the clock rate of data entering and leaving are the same. In this way, a MSS node can join a stratum-synchronized network. Synchronization minimizes frame slips and data loss for the access services that use it.
43 / 82

Each MSS can run in one of three synchronization modes:
122B
APRIL 2007
Internal Timing Reference External Timing Reference Line timing Reference
INTERNAL TIMING REFERENCE
The MSS has a Stratum 3 clocking including holdover capability. This is compliant with Telcordia GR-1244-CORE and meets the following characteristics:
123B
Accuracy: +/- 4.6x10-6 (+/- 7.1Hz@1.544 MHz / 9.3HZ@2.048MHz) ) Stability: +/- 3.7x10-7/day for the initial 24 hours of holdover Pull in range: +/-4.6x10-6
EXTERNAL TIMING REFERENCE
The MSS15K can accept two external timing reference sources (A and B) for redundancy. These external timing reference sources should originate on a BITS or SSU clock, and must be traceable to a Stratum 1 PRC/PRS with better than Stratum 3 holdover performance. The chosen timing reference will then be distributed to all outgoing links. These external timing reference inputs on the RNC must be either E1 (International) or DS-1 (North America) electrical carriers that meet the electrical requirements in ITU-T G.703. These signals are framed, but cannot be used to carry traffic. In case of failure of the two external timing reference sources, the RNC will enter holdover operation: in this mode, the RNC's internal Stratum 3 clock continues to operate at its last adjusted frequency, preserving that frequency until one or both external references are restored. In normal operation, the clocks distributed outward on the optical carriers (OC3/STM-1) must meet the synchronization requirements for optical interfaces.
124B
LINE TIMING REFERENCE
The timing reference is extracted from selected incoming traffic interfaces (STM1 or OC-3). These interfaces must be traceable to a Stratum 1 network clock, and must meet the relevant standards for the types of interfaces (SONET or SDH). Three incoming signals can be configured as Primary Reference, Secondary Reference and Tertiary Reference at provisioning time, for redundancy". The chosen timing reference will be distributed to all outgoing interfaces. The clocks distributed on the optical carriers (OC-3/STM-1) meet the synchronization requirements for optical interfaces (Telcordia GR-253 for SONET, G.813 for SDH). In case of failure of all of these incoming signals, the RNC will go to the Holdover Mode: in this mode, the stratum 3 Clock of the RNC continues to operate at its last adjusted frequency and does not update its frequency.
4.10 Interface Compliance

34B
In UA05.0, the reference release is 3GPP Rel 6 for all interfaces applicable to the RNC-1500. The reference versions of the 3GPP specifications correspond at least to the versions available after 3GPP #31 (March 2006) for the specifications that are applicable to the RNC and specifically at minimum on a per interface basis the RNC compliance is as follows: Uu: Rel 6, March 06 Iu: Rel 6, March 06 IuB: Rel 6, March 06 IuR: Rel 6, March 06
44 / 82

IuBC: Rel 6, March 06 IuPC: Rel 6, March 06
APRIL 2007
For more details on RNCs 3GPP release compliance, please refer to the High Level Compliance to 3GPP specifications document [15]. Alcatel-Lucent is an active member of the 3rd Generation Partnership Project (3GPP) and the Network Vendors Interoperability Testing (NVIOT) forum.
45 / 82
APRIL 2007
4B
RNC FUNCTIONALITY
The objective of this section is to describe the software functions of the Alcatel-Lucent RNC, which will help the operator to differentiate their offer in the marketplace. Alcatel-Lucent designed the RNC in order to deliver to the operators a solution that: Maximizes the efficiency of spectrum usage, i.e. the capacity of the system, Delivers first class Quality of Service (QoS) to the subscriber, Reduces the resources necessary to deploy and optimized the network.
5.1
35B
Radio Resource Management (RRM)
Alcatel-Lucent is in a unique position today in the industry to offer a complete RRM solution which maximizes the number of subscribers i.e. revenue increase with no additional investment while ensuring the desired Quality of Service (QoS) levels to the final customer. The UMTS RNC is powered with enhanced Radio Resource Management (RRM) algorithms built on Alcatel-Lucent extensive CDMA and data experience: all this enables UMTS operators to differentiate customers and services, by having the ability to optimize the spectrum in order to match the respective market demographics. Alcatel-Lucents RRM is in charge of allocating and managing radio resources in the most effective way. In fact, efficient RRM enables QoS in the radio without wasting resources and achieving maximum capacity. Alcatel-Lucents RRM main functions are: Admission control the purpose of the admission control is to admit or deny new users. Congestion control - the task of congestion control is to monitor, detect and handle situations when the system is reaching an overload situation with the already connected users. Power control - this group of functions controls the level of transmitted power in order to minimize interference and maintain the quality of the connections. Although these functions are not described in this document, Alcatel-Lucent supports: DL and UL Outer Loop Power Control DL and UL Inner Loop Power Control and DL power balancing UL Open Loop Power Control
In addition, the Alcatel-Lucent RRM solution also provides a set of sophisticated features allowing an operator to efficiently support data traffic on the radio interface primarily when dedicated channels are used: Traffic volume based Radio Bearer (RB) bit rate downgrading and upgrading Adaptation of dedicated channel bit rate according to the observed volume of user traffic Switch from CELL_DCH to CELL_FACH and further to Cell_PCH/URA_PCH (and vice versa) based on user inactivity (Always-On feature) RB bit rate downgrading and upgrading based on radio conditions (iRM Scheduling feature)
46 / 82

5.1.1 Admission Control
APRIL 2007
76B
The purpose of the admission control is to admit or deny new users, new Radio Access Bearers (RAB) or new Radio Links (RL) due to mobility. The admission control prevents from overload situations and bases its decisions on available resources in both uplink (UL) and downlink (DL) directions. Alcatel-Lucent admission control can be divided into two main steps: 1 RAB Matching this is the RAB to RB mapping function, which is responsible for selecting the RB configuration onto which the service is supported. It operates independently on both UL and DL RAB parameters. For PS RAB mapped on DCH (Streaming, Interactive or Background) it includes a function called intelligent RAB Mapping (iRM) allowing to adapt the selected bit rate between the Maximum Bit Rate and the Guaranteed Bit Rate from the RAB, based on the cell load (UL & DL) and the DL radio conditions. Call Admission Control (CAC) this is the UTRAN function responsible for deciding whether a request to establish a RAB can be admitted based on the available resources.
RAB Matching
3. Reference RB is combined with SRB and already established RB (if any)
MIB Supported RB bit rate RAB request Candidate RB selection iRM
Already established RB, e.g. voice call
RB Selection
1. RNC builds a list of candidate RB and selects a Reference RB as the highest bit rate in the ordered list.
2. For Interactive/Background, Reference DL RB can be replaced by a lower RB bit rate according to UE radio conditions and cell congestion status
Selected RB
CAC
Admitted : Yes/No
4. RNC checks resources availability for selected RB
Figure 26 Admission Control The radio Call Admission Control function for the DL consists in checking the availability of DL power and OVSF codes. For the UL, the CAC ensures that the UL load is kept under affordable level. The UTRAN also performs checks on other resources such as transport or Node B resources (e.g. Channel Element).
47 / 82
APRIL 2007
5.1.2
77B
Congestion Control
The task of congestion control is to monitor, detect and avoid overload in the UTRAN as well as to ensure the system remains stable. Although a CAC is implemented to prevent new users from accessing the system when it is already too much loaded, the purpose of the load control mechanisms is to maintain the use of radio resources under the limits that would cause the capacity to shrink and the quality of ongoing calls to be impacted negatively. Load control mechanisms basically include: 1 2 Evaluation of system load (DL and UL) at cell level Congestion handling algorithms responsible for taking the proper actions to control the load in the system. This can be further divided into two parts: Preventive actions to avoid overload If overload happens, congestion handling mechanisms take the proper actions to bring the system back to the load state defined by the operator
125B
5.1.2.1
Cell Load Determination
Alcatel-Lucent congestion control algorithms rely on the following load information: Uplink cell load UL noise rise estimated from the variation of the RTWP, which is periodically reported by the Node B to the RNC (NBAP common measurement). The reference value for the no load case is learnt by the Node B which tracks the minimum value that this measurement reports Uplink Node B CEM load Downlink cell load OVSF code tree load Node B transmitted power (it represents the interference in DL), which is periodically reported by the Node B to the RNC (NBAP common measurement) IuB load Downlink Node B CEM load
78B
5.1.3
Packet Switched Call Management
Alcatel-Lucent has developed specific algorithms to handle packet data sessions and optimize radio resources due to the important role they play in UMTS. The main : Always-On Many data applications (e.g. e-mail or web browsing) transported by the UMTS PS domain are bursty in nature and have long periods of inactivity (e.g. web page reading time). The role of Always-on is to save capacity during periods of inactivity by releasing dedicated resources i.e. an inactivity monitor. Always-on, which is based on volume of user traffic, relies on transitions of 3GPP defined RRC states (namely CELL_DCH, CELL_FACH and CELL_PCH/URA_PCH). This function is applicable to DCH, HSDPA and HSUPA.
48 / 82
APRIL 2007
RF based downgrading/upgrading (iRM Scheduling) When mapped on DCH, coverage of a given DL bit rate is determined by the maximum power the BTS is allowed to transmit for that rate. To limit the interference and optimize the power amplifier usage, high DL bit rates are usually confined to the centre of the cell. Consequently, if the UE is moving out of the high bit rate coverage, the call is likely to drop. To avoid such a call drop and ensure service continuity, the radio bearer can be downgraded to a bit rate (i.e. fallback bit rate) for which continuous coverage is ensured. RB Rate Adaptation - Thanks to this feature further capacity is saved as the RNC is able to dynamically adapt the RB bit rate (UL & DL) as close as possible to the real application traffic needs: the DCH is reshaped according to the actual user throughput. When DL is mapped on HSDPA, RB adaptation works in the UL direction if mapped on DCH (R5 UE).
5.2
36B
Mobility
In any cellular system, and in particular in UMTS, which intends to offer high quality of service to the subscriber, mobility is obviously a key feature. Alcatel-Lucent proposes a complete set of mobility procedures to the operators, focusing on two major objectives: Continuous Quality of Service: Alcatel-Lucent solution guarantees a perfect quality of service for the end user. Addressing the requirements following the network evolution: Alcatel-Lucent believes that the network deployment will go through several phases; initial deployment, interactions with 2G systems, optimization phase when the network load increases, micro-cell layer introduction, HSDPA introduction, etc. Alcatel-Lucent will address the specific needs of the operator in each of those phases.
In a first phase up to release UA4.1, the necessary mobility functionality was provided to ensure the best possible user perception when deploying a single or multi-carrier Release 99 UMTS network. The main mobility features available are: UMTS intra-frequency mobility Best in class Soft Handover, intra and inter-RNC 3G/2G integration UMTS to GSM mobility for service continuity when loosing UMTS coverage, GSM to UMTS mobility to benefit from services and QoS services provided by the UMTS network Introduction of Multiple Carriers, to increase network capacity with either Hotspot deployments or two overlaying layers deployments Inter-Frequency cell reselection Inter-Frequency hard handover with Measurements (intra and inter-RNC) Seamless National Roaming to limit network deployment costs: Inter-Frequency cell reselection Inter-Frequency hard handover without Iur IMSI-based handover
49 / 82
APRIL 2007
In a second phase which was supported with UA4.2 release, the main focus was on HSDPA introduction. Release 99 traffic is nonetheless taken into account with the possibility to redirect speech calls to 2G in case of overload. The main Traffic Management and Mobility features available are: HSDPA intra-frequency mobility to cope with the following cases an HSDPA UE moving from an HSDPA cell to another HSDPA cell, in which case the HS-DSCH Radio Link is deleted on the former primary cell and it is re-established under the new primary cell using a synchronous reconfiguration. an HSDPA UE moving from an non-HSDPA cell to a HSDPA cell, in which case the call is switched to HS-DSCH channel an HSDPA UE moving from an HSDPA cell to non HSDPA cell, in which case the call is downgraded to DCH channel Multi-carrier HSDPA Traffic segmentation, to deal with a multi-layer scenario where HSDPA is deployed on a dedicated carrier. With Traffic Segmentation, mobiles are redirected to the right layer at RRC connection establishment in order that mobiles that are eligible to HSDPA are directed towards the HSDPA layer and that the other ones are directed towards the non-HSDPA layer. HSDPA Alarm Handover, to handover to 2G when loosing 3G coverage 3G to 2G Redirect for Speech calls, which improves call establishment success rate for Speech calls. Effectively, in case no resources are available to establish a speech call in a 3G cell, the RNC will attempt to re-direct the call to the 2G network.
In the third phase, starting with release UA05, we focus on network growth and densification, as well as HSUPA introduction. Alcatel-Lucent believes that an efficient multi-carrier management can lead to a significant increase of UTRAN capacity. Therefore, some advanced Multi-Layer Management features are introduced, in particular: Cell reselection control in a Hierarchical Cell Structure (HCS), which allows prioritizing the cells the mobile should be camping on in idle mode, by giving different HCS priority levels and thresholds, according to the strategy of the operator. For instance, the operator could deploy micro cells and assign them a higher priority so as to push the traffic on those cells. At the same time, the algorithm also takes into account the fast moving UEs so that for instance, those UEs are kept in a macro cell instead of going to the micro layer. Intelligent Multi-Carrier Traffic Allocation (iMCTA): In a multi-carrier network, the user traffic can be unbalanced between carriers without multi-carrier management. That would lead to the non-optimal use of resources: the second carrier F2 is underutilized while carrier F1 starts blocking. A good multi-carrier management improves the trunking efficiency and provides an increase in cell Erlang capacity. iMCTA is an algorithm that intelligently allocates traffic across all carriers available. The algorithm is invoked during certain events in order to check if the call should preferentially be redirected to another carrier. It does not have any effect on mobiles which are idle. It takes into account mobile the requested Service Type, the Priority among different carriers for that service type, the current Load of the originating cell and target cells, the UE Capabilities regarding HSxPA and optionally the Service Handover Information if received from the core network.
50 / 82
APRIL 2007
unifiedRRM: the fundamental concept of Alcatel-Lucents unifiedRRM Solution is to provide the ability to assign the user the best suited radio resource taking into account various factors such as the Service type, the UE capabilities, and the loading across the GSM and UMTS layers. With unifiedRRM, there is an increase in capacity in both UMTS and GSM networks through load balancing mechanisms, an Enhanced QoS by reduced call blocking, and an investment protection because it maximizes the lifetime of GSM and GPRS infrastructure. The unifiedRRM can be considered as the first step towards the re-farming of the GSM spectrum with UMTS technology. SRNS Relocation: This procedure is used to move the UTRAN anchor point from the serving RNC to another RNC (the UTRAN anchor point is the node in which the mobilenetwork RRC connection and RLC/MAC radio protocols are terminating). Depending on the network topology, a SRNS relocation may be either intra or inter MSC or SGSN. Mobility in Cell_PCH AND URA_PCH RRC States: This feature is applicable when the call enters in Cell/URA PCH state.
5.3
5.3.1
37B
HSDPA
79B
HSDPA Background
HSDPA (High Speed Downlink Packet Access) is a UTRAN technology for WCDMA networks. This technology is implemented in the Node B and the RNC and as a system will inter-work with existing R99 UTRAN. It is part of the 3GPP standards and is specified in 3GPP R5 (Approved June 2003). HSDPA increases the throughput (5 times greater than R99), increases capacity (2 times more than R99) and achieves high peak data rates (between 384 kbps and 2 Mbps) compared to R99 based UTRAN. Alcatel-Lucent delivers HSDPA through only software upgrades on the UTRAN. The AlcatelLucent UMTS BTS and RNC are HSDPA hardware ready and therefore will not require a hardware change.
5.3.2

80B
Alcatel-Lucent HSDPA Implementation
The full benefits of Alcatel-Lucents overall high speed UTRAN data solution are as follows Leverages the 1xRT EV-DO Commercial experience Less risk during commercial deployment A complete HSDPA solution Day One enabling: Full flexibility in terms of coverage and capacity Multi and mono carriers HSDPA ready BTS & RNC available since Dec 2000 Pooled CEM for HSDPA Lower CAPEX on introduction Performance advantage with 45W MCPA
51 / 82

OPEX Reduction w/ Iub Bandwidth Management Multi-carrier PA Power Pooling
APRIL 2007
100% capacity gain with Alcatel-Lucent HS-SCCH Power Control and Multi-user scheduling Multi-Carrier Traffic Segmentation i.e. Always put HSDPA capable UEs on HSDPA layer HSUPA in UA05
The RNC specific attributes of this implementation are discussed in the subsequent sections.
5.3.3
81B
Dynamic Power Control
This feature supports dynamic power adjustment so that the remaining power after all common and DCH channels are served is made available to the HS-DSCH channels. Minimum power can also be reserved for HSDPA in order to avoid starvation of the HSDPA service due to power. Flexible power management for HSDPA ensures a dynamic usage of the Node-B PA power versus cell DCH or HS-DSCH traffic for cell HSDPA operation. The entire Node-B PA power is managed in order to ensure the highest HS-DSCH throughput assuming a low cell load in terms of the number of users. The feature ensures a maximum NodeB PA power resource for DCH traffic (pure R99 and associated HSDPA DCH) leaving the remaining power for HS-DSCH as defined by the 3GPP standard for HSDPA behaviour. RNC CAC enhancement for remaining power usage.
82B
5.3.4
Multi-carrier HSDPA Traffic Segmentation
This feature enables operators to deploy HSDPA on a separate frequency by redirecting traffic at call setup time. In this manner, a Node B may control HSDPA and non-HSDPA calls on different frequencies. If HSDPA is deployed on one frequency layer on top of the R99 layer, it will be possible to re-direct UEs on the proper frequency layer at RRC connection setup depending on the UE type and requested traffic class. Both R99 to R5 redirection and R5 to R99 redirection are triggered on certain conditions. One or both re-directions can be activated. Redirection triggers are the UE type (R99 or R5), the traffic class (establishment cause), and whether there is HSDPA carrier presence or not. Emergency calls are not candidates for R5 to R99 redirection.
83B
5.3.5

HSDPA Mobility
Alcatel-Lucents UA04.2 HSDPA Intra-Frequency mobility support is as follows: HSDPA-to-HSDPA mobility upon change of primary cell from HSDPA cell to HSDPA cell HSDPA-to-DCH mobility upon change of primary cell from HSDPA cell to non-HSDPA cell DCH-to-HSDPA mobility upon change of primary cell from non-HSDPA cell to HSDPA cell
52 / 82

APRIL 2007
HSDPA-to-DCH mobility upon change of primary cell from serving RNC cell to drift RNC cell DCH-to-HSDPA mobility upon change of primary cell from drift RNC cell to serving RNC HSDPA cell The RNC may control HSDPA and non-HSDPA cells.
Intra-frequency mobility is required to allow the following scenarios: An HSDPA UE moving from an HSDPA cell to another HSDPA cell (that is, HS-DSCH following the primary cell) An HSDPA UE moving from a non-HSDPA cell to an HSDPA cell (that is, HS-DSCH transition) When a call is already in HSDPA and a new RAB (either CS or PS) is added for multiservice mode, the current HSDPA RAB is switched to a DCH RAB The call is downgraded to DCH when the primary cell moves to a Drift RNC. The call is upgraded to HSDPA, if possible, when the primary cell returns to the SRNC.
During a HSDPA call, a handover to a 2G cell can be triggered when the alarm criteria is reached. The call is maintained thus avoiding a dropped call. In UA05, Alcatel-Lucent will support inter-frequency hard handover and HSDPA over IuR, rather than falling back to DCH before performing the handover.
5.3.6
84B
Always-On on HSDPA
While DL user traffic is carried over the HS-DSCH, UL traffic is carried over an associated DCH channel. To save capacity, the UL dedicated channel is not maintained during periods of inactivity. The UE is moved to Cell_FACH if user traffic falls below a given threshold during a certain period of time using the T1 inactivity timer. When coming back from Always On, the choice between HS-DSCH and DCH is made according to the same criteria at initial admission. HSDPA Alarm HO can be disabled to allow cell re-selection
85B
5.3.7
Iub Bandwidth Limitation Handling
This feature is required to allow HSDPA bearers to operate with under-provisioned transport bandwidth over the Iub links. The benefit is that Iub bandwidth utilization is improved when HSDPA is activated. Iub is provisioned with less bandwidth than what is normally expected to carry the whole Node-B traffic when HSDPA is activated. Minimum bandwidth can be allocated to HS-DSCH traffic on the Iub.
5.4
5.4.1
38B
Other Alcatel-Lucent RNC Functions

86B
PDCP IP Header Compression
Compression and decompression of upper layer protocol control information, e.g. TCP/IP, RTP/UDP/IP headers, is performed by the PDCP sub-layer, using different header compression methods. The header compression algorithm for TCP/IP headers is RFC 2507. The Robust Header Compression scheme (formerly ROHC) has been standardized in IETF (RFC 3095) and 3GPP standards agreed to include it in 3GPP Release 4.
53 / 82
APRIL 2007
This much more robust scheme for air interface will be provided when dealing with IP based multimedia applications.
5.4.2
87B
Security Features
Security is a major concern for all parties involved in the telecommunication market: from the subscriber to the service provider, including the wireless access network (i.e. the UMTS PLMN) operator. UMTS makes use of W-CDMA, which is inherently more secure than 2G/GSM due to its spread spectrum capability and scrambled code support. Anyway, many threats to 3G systems have been identified, especially against the radio interface between the Mobile and the network. From all the threats against the radio interface, the following ones are seen as major: Violation of integrity, characterized by the modification of sensitive data. The use of a false BTS can provide means to modify part of the messages exchanged between the mobile subscriber and the network. Violation of confidentiality, characterized by an unauthorized access to sensitive data.
This can be achieved by: Eavesdropping of user traffic, of signalling data Masquerading Analysis of the traffic (be it a passive attack or an active one).
Support of two essential security mechanisms: Integrity protection & ciphering of radio interface messages. As far as security of the radio access link is concerned, Alcatel-Lucent UMTS RNC provides 2 essential mechanisms, ensuring both: the integrity the confidentiality of the messages exchanges between the mobile user and the network.
54 / 82
APRIL 2007
Integrity protection of the radio interface is a new and mandatory requirement for the 3G systems. Integrity protection applies to signalling messages but not to the user traffic data. This mechanism ensures that the messages received by one party of the dialogue come from the expected remote party and prevents from the use of a false BTS. For that purpose, Integrity protection appends a signature to each signalling message; this signature is generated thanks to an algorithm named f9. Integrity protection is defined as mandatory by 3GPP and hence is supported by AlcatelLucent UMTS RNC ORBiT as from the 1st release. Ciphering (also named Encryption ) is already provided by 2G systems but has been enhanced for 3G. Ciphering ensures confidentiality of signalling messages & of user traffic data. This mechanism makes the content of the messages exchanged not readable, not understandable by external parties other than the 2 ends of the dialogue. For that purpose, the initial content of the message is replaced by an encrypted message generated thanks to an algorithm named f8. Support of ciphering enables secure packet services like eCommerce. Hence, the Alcatel-Lucent RNC implements Ciphering as from the 1st commercial release. However, as far as UMTS R99 standards are concerned, Ciphering as suffered late corrections from 3GPP, the implementation of which is essential for ensuring the interoperability between the mobiles and the network. Some differences to be noticed between 2G & 3G systems and as far as the network are concerned: in 2G systems: ciphering is performed in the BTS (for the CS domain) or in the SGSN (for the PS domain); in 3G systems: ciphering is performed in the RNC (for the CS domain and for the PS domain).
88B
5.4.3
Security between RNC and OMC
Supporting IPSec on the RNC is required to secure the OAM traffic between OMC-R and RNC CP management virtual router. IPsec improves the security of the UMTS RNC OAM Plane toward the following Network Threats: Denial of Service Hacking Intrusion Modification of Data
55 / 82
APRIL 2007
In order to improve the level of security toward the previous threats, this feature introduces a secured data channel between the RNC site and the OMC site of network. The secured data channel would make use of the IPSec technology. IPSec in RNC ORBiT will support: Data integrity Data authentication Manual ESP
In addition to securing the data between RNC and OMC, supporting Radius provides a centralized password management.
Figure 27 - Radius and IPsec security to OMC and RNC
56 / 82
APRIL 2007
57 / 82
APRIL 2007
5B
OPERATION AND MAINTENANCE
This section describes the operations and maintenance of Alcatel-Lucents UMTS RNC. 3GPP specifications define the OMC-R and the OMC-B logical entities which correspond to the wireless specific management of the RNCs and the Node Bs respectively. These two Entities (OMC-R and OMC-B) are managed by the same Alcatel-Lucent OA&M platform, the Wireless Network Management System( W-NMS). This OA&M Platform will provide fault management, configuration and performance management. Connection from the RNC to the W-NMS is done either in band (via 16pOC3/STM1 or 4ptGigE card) or out of band (directly IP / 100Bt to the Cp3).
6.1
6.1.1
39B
Hardware
89B
Memory
All the modules have Flash EEPROM. This Flash memory includes the operational load, so the boot is very quick (all modules in the RNC boot from the Flash memories).
6.1.2
90B
CP3
PMC-OMU handles most of the functionalities for the 20 GB multi-partitioned shared disks. The CP3 has a 20 GByte multi-partitioned shared disk. The disk has 3 partitions whereby the first partition has been created to save alarms and field traces and the second and third partitions are used to store the MIB. The shared disks are identical and are only seen by the active PMC-OMU. In the case of a PMC-OMU switch, their content is not altered, and is always identical. The replacement of a faulty disk by a new one is detected and its content is copied from the active disk. Reads are shared and writes are made on the two volumes. Some functions to speed up the disk management are also handled in the CP. The control Processor provides the most direct method for managing the RNC, using a VT100 terminal (or a PC executing a TELNET session) plugged directly into its V.24 port. This local access provides you with a text interface to enter commands and view alarms. When direct connection is not possible, the RNC can be managed from a remote site using a telnet application.
58 / 82
APRIL 2007
6.2
40B
Hardware Handling
Start-up or Module Insertion An RNC object is automatically created at RNC creation on the W-NMS Platform. The RNC will send notification indicating the hardware configuration detected on the corresponding platform object. This information is stored on the CP disk and sent to the W-NMS Platform. One can read it on the CP disk, even when a module is out of service. This information is also stored at W-NMS Platform level and can be displayed on operator request. Module Extraction Modules must be 'locked' before they can be removed from their slots. A specific event is sent indicating a state change of the object that was previously in the slot (it can also happen for some hardware faults). On reception of this state change, the W-NMS Platform will delete the corresponding logical object. Plug and Play The RNC supports hardware plug and play capability, but only for FPs that have been provisioned via the W-NMS. After the FPs has been provisioned, the system will automatically detect when the FP is inserted and load the FP and bring it into service. For a PSFP, new calls will be allocated to the PMCs but the cells are not redistributed to the new hardware, unless a sparing event causes this to happen later. It also detects when an FP is removed.
6.3
41B
Software Handling
The design of the RNC software is done using special description languages. Thus improving software design and test efficiency by allowing the used of automatic tools.
6.3.1
6.3.1.1
91B
Software Management
126B
Software Delivery
For each version and edition, the complete RNC software will be delivered on a unique CDROM that contains, for each node, the following files: Package files: this is the smallest loadable unit of the software product. The packages are separately installable units that can operate independently from the other packages of that software product. A description file: this details all the packages of the delivery for the given node. The description file is used by SRS, OMC-R and RNC to perform software coherency checks.
59 / 82
APRIL 2007
This volume can be used at W-NMS Platform. It is sufficient for all upgrades from any authorized version (typically N-2 and N-1 versions). The first installation of the software in the disks is made in the factory, which has to install the version/edition ordered by the customer, so the commissioning is reduced.
6.3.1.2
127B
Software Upgrade
An RNC upgrade consists of resetting the standby CP and loading it with the new version of software. Once it is back in service, the standby CP communicates with the active CP. The active CP performs a shelf reset causing a reset of the PSs and 16pOC-3/STM-1s. They are loaded and provisioned in parallel.
6.3.1.3
128B
RNC upgrade from W-NMS
The RNC can be composed of two components: the RNC itself and possibly the optional Transport Node, used to provide E1 connectivity. An upgrade involves installation and activation of new software on each of these nodes individually. An upgrade operation consists in downloading and activating a new software version or edition on the RNC. The downloading of a software version can be done remotely during daylight hours, without any operational impact. Only modified files in the new version are downloaded. The complete RNC software is downloaded from the W-NMS Platform to the RNC. From the UMTS Access specific windows of the W-NMS Platform, the Graphical User Interface (GUI) allows the user to download and/or activate relevant versions of software to the RNC. To make the operations easier, the GUI is a wizard GUI (set of windows having a dedicated linking). For both Download Software and Activate Software, the wizard windows allow the user to: Select the type of Network Element (NE) to activate/download (Node B or RNC) Select the new software version to download/activate from Software Repository Server (SRS). Select the RNC to download. Launch the download and/or activate operation on the selected RNC.
A general monitoring window called Upgrade Manager is automatically launched once the downloading or activation wizard has been completed, allowing for instance the user to monitor the advancement of the upgrade procedure (downloading and/or activation).
6.3.1.4
129B
Patch Management
Patch management is one of the biggest benefits of the RNC. Emergency patch loads (EPL) are often used to introduce bug fixes. An EPL is effectively a non-scheduled Maintenance Load (MNCL) build, which is a full s/w load. EPLs require full upgrade procedures to deploy that involve a < 10 mins outage and scheduled maintenance window to deploy. An EPL contains a bundle of several software fixes (CRs), therefore unless there is a critical issue.
60 / 82
APRIL 2007
RNC patching offers a hitless mechanism to introduce new software for bug fixes or minor features. All boards on the RNC can be patched i.e. CP3, OC3 & PSs. Alcatel-Lucent estimate that approximately 70% of RNC software is patchable; However, greater than 90+ % of bugs can be patched through workarounds in software. Of course RNC will continue to support EPLs, but will require them far less frequently and only when a change that cannot be patched is required e.g. MIB changes. RNC Patching will provide a far less disruptive and operationally less intensive method of doing minor s/w upgrades or applying bug fixes.
6.3.2
92B
Fault Management
Fault management (FM) provides monitoring capabilities to diagnose and rectify hardware, software, and network problems. FM attempts to limit the effects of a failure on the network. Faults generated by the RNC are received at the W-NMS, where they are integrated.
6.3.2.1
130B
Preventive Maintenance
The architecture of the Alcatel-Lucent RNC allows an easy preventive maintenance, since every module is used in normal operation and internal tests are performed periodically on unused/spare resources. Moreover, the operator has a real time display of the RNC hardware state at W-NMS Platform level. The degraded availability status is managed at RNC level. It provides a way of detecting required preventive maintenance actions. A synthetic preventive maintenance report is periodically sent to the W-NMS Platform.
6.3.2.2
131B
Alarm Handling
The most important piece of troubleshooting information is alarms. A component of the RNC generates an alarm when it detects a problem. The alarm contains useful information about the problem, including the OSI state and status of the component. For complex service problems, you can use the Trace System to monitor data flow on a service. Alarms are your primary indication that there is a problem on your RNC. When a component detects a problem it issues an alarm, which, by default, displays on all operator sessions. A component generates an alarm in the following situations: quality of service degradation processing error hardware failure change of administrative OSI state security violation software error
Alarm information includes the OSI state and status values at the time the component generated the alarm as well as the severity, type, and probable cause of the alarm.
61 / 82
APRIL 2007
An alarm can also include a comment that contains brief information about the cause, impact, and recovery of the problem. Whenever the OSI state of a component changes, the RNC issues a state change notification (SCN). The W-NMS Platform uses this information to update its network model.
6.3.3
93B
Configuration Management
Configuration Management (CM) provides the operator with the ability to assure correct and effective operation of UTRAN as it evolves. CM actions have the objective to control and monitor the actual configuration on the Network Elements (NEs) and network resources, and they may be initiated by the operator or by functions in the Operations Systems (OSs) or NEs. CM actions may be requested as part of an implementation program (e.g. additions and deletions), as part of an optimization program (e.g. modifications), and to maintain the overall Quality of Service (QoS). The CM actions are initiated either as a single action on a NE of network or as part of a complex procedure involving actions on many NEs.
6.3.3.1
132B
On-line Configuration
On-line configuration is used to change the UTRAN configuration in real time. On-line tools include command-line interfaces (CLI) and GUIs from the OMC-R. For example, local operator and Telnet sessions are hosted by the CP. These can be used to make adjustments to the network by either tuning the performance of a network element or by executing troubleshooting procedures.
6.3.3.2
133B
Off-line Configuration
Off-line configuration implies the use of a database where provisioning information for a network element (NE) is maintained and, at a later date, downloaded to the NE itself. The manipulation of configuration data is not done on the NE itself. Off-line configuration is performed by a Wireless Provisioning System (WPS) application running on a client PC. CM bulk creations and modifications are performed on the RNC from the WPS.
6.3.4
94B
Performance Management
Performance Management (PM) permits users to monitor the traffic load on the network. The main goal is to detect any gradual degradation before it impacts QoS.
6.3.4.1
134B
Counters
The RNC platform provides many hardware counters (change CPU, Memory usage, protocol status, disk usage) and UMTS logical resources counters(Radio resources usage, radio links quality, etc..). These statistics are collected by the W-NMS via FTP.
6.3.4.2
135B
Call Trace System
Incoming and outgoing data of a particular service can be monitored using the call trace system. This detailed information can help you troubleshoot complex network problems. Trace does not interrupt regular network activities.
62 / 82
APRIL 2007
63 / 82
APRIL 2007
6B
PROVISIONING AND ENGINEERING

Market Configurations
95B
7.1
7.1.1
42B
Scalability
The Alcatel-Lucent RNC is a scalable platform which can be configured to satisfy different network capacity needs. Five RNC-1500 models are supported: 1504, 1506, 1507, 1510, and 1512. The last two digits represent the number of PS modules. The same number of models, with the same quantity of PS modules, will be available with RNC-ORBiT. In UA06 AlcatelLucent will introduce a new model with 8 PSs and manufacture discontinue the 7 PS model.
7.1.2
96B
Configuration Upgrades
With advanced planning, upgrades from one of the existing configurations to a higher capacity configuration can be done with zero downtime of the RNC. These upgrades consist of adding PSs.
7.2
43B
Connectivity
The RNC provides a set of physical interfaces towards other network elements to be easily integrated in the customers transport network. OAM connectivity is based on standard IP over Ethernet for both OMC-R/OMC-B, MDM/MDP, and maintenance and commissioning tools. All of the Iub, Iur and Iu interfaces are optical SDH/STM-1 or SONET/0C-3 in UA05. They are provided by the 16pOC-3/STM-1 modules providing single-mode STM-1 or SONET OC-3 fibers carrying ATM cells at 155 Mbps. There are two 16 ports OC-3/STM-1 modules with active and standby roles for redundancy purpose. IP will be supported via two 4ptGigE cards in the RNC. Additional connectivity options (E1/T1, STM1 channelized, etc..) can be provided by adding an additional Transport Node.
7.3
7.3.1
44B
Installation and Commissioning

97B
Start-up Tool
The purpose of the installation and commissioning tool is to limit any manual operations required to initially configure a node locally. The startup tool runs on a laptop and allows the installer to run startup on the CP to perform basic provisioning and local testing so that the Wireless Provisioning System (WPS) can take over after the switch goes into service.
7.3.2
98B
Software Upgrading
Upgrading to another load is performed from the OMC-R and MDM, although it can be performed by the start-up tool as well. The WPS performs configuration operations.
64 / 82
APRIL 2007
65 / 82
APRIL 2007
7B
FUTURE EVOLUTION
Capacity Roadmap
8.1
45B
The RNC capacity evolution leverages on the unique software development skills of the Alcatel-Lucent Research & Development department. Thanks to the extensive effort in software optimization, Alcatel-Lucent provides its customers the benefit of an advanced real-time code optimization technique allowing the RNC-1500 to evolve to the next generation RNC-ORBiT, giving the possibility to double the capacity values through a simple software upgrade and an optional upgrade of the interface cards to achieve maximum data throughput. In UA06, Alcatel-Lucent also introduces the Next Generation DCPS and further doubles RNC capacity through increased processing to provide 16,000 Erlangs in a single shelf (32,000 Erlangs in a single cabinet).
Figure 28 - Alcatel-Lucent RNC Capacity Roadmap
8.2
46B
RNC-ORBiT
Alcatel-Lucent UMTS RNC-ORBiT is the next generation capacity RNC; the key benefits of this product for an UMTS operator are: Increased number of Node B per RNC, allowing the expected network expansion and densification without any additional RNCs Increased number of Mbit/s per RNC. The added Mbit/s will absorb traffic growth without having to install new RNCs Increased number of subscribers per RNC. The 3G subscriber base will grow and the RNC can absorb this growth without having to install new RNCs. Reduce operational costs thanks to a unique software upgrade and optional upgrade of the OC3/STM1 interface card.
There will be one single UA06 SW stream and architecture for both the RNC-1500 and RNCORBiT. This will which ensure Iso-Functionality for RNC-1500 and RNC-ORBiT in UA06 e.g. 5*9s, features. UA06 enables a hitless optional upgrade to RNC-ORBiT.
66 / 82
APRIL 2007
The evolution from Alcatel-Lucent UMTS RNC-1500 to RNC-ORBiT is achieved through simple software unlocking. No forklift is required. This smooth upgrade to a high performance product is enabled thanks to the software optimization introduced with Real-time coding techniques. Alcatel-Lucent refer to this as ORBiT: The ORBiT PMC directly processes packets, independent of protocol layers Almost all pure application code, no layers i.e. No Operating System Control packets (including the SRBs) are sent to a separate PMCs (e.g. ORBiT PMCs) ORBiT uses a combination of traditional serial and parallel programming techniques ORBiT is optimized for Cache Calls are serviced in groups No Interrupts i.e. code runs to completion Run time image fits within L1 instruction cache (~8K machine instructions) Other characteristics No timers Timers based on PPC Time Base register Performance Scales linearly with Processor CPU e.g. 1GigHz PPMC will be 2X performance of 450MHz PMCs with Turbo sw Some procedures are written in assembly and Altivec (~15% of ORBiT sw) for enhanced performance, but mostly ORBiT is written in C code Elimination ~1 Million Lines of Code Use of sophisticated DMA operation
The performance of Alcatel-Lucent UMTS RNC-ORBiT will be two times the performances of the RNC-1500. As an additional step in Alcatel-Lucent UA06 release, RNC-ORBiT capacity can be doubled again by adding the Next Generation DCPSs, to be able to support up to 16K Erlangs in a single shelf. Please refer to Alcatel-Lucent UMTS RNC capacity roadmap for more information [1].
67 / 82
APRIL 2007
8B
HARDWARE TECHNICAL CHARACTERISTICS

Reliability
99B
9.1
9.1.1
47B
Principles
As the RNC is a potential central point of failure in the UMTS access network, the RNC is designed to have very high availability. The focus of the Carrier Grade program is as follows: Minimize the impacts and frequency of unscheduled outages Minimize outages associated with scheduled maintenance procedures All critical processors in the RNC are 1+1 spared All traffic carrying processors in the RNC are N+P spared. All RNC modules are built to last with very low failure rates and high component MTBF
68 / 82
APRIL 2007
9.1.2
XTable 4
100B
Mean Time Between Failure (MTBF)
The predicted MTBF, return rates and failure rate per module for a MTTR = 4 hours is shown in Committed Description Code Failure Rate (FITS) 50 8640 8049 6424 1148 772 38 106 215 14 30 NTHR11 NTHR13/1 4 79 103 14 MTBF (Years) 2282 13 14 18 99 148 3002 1076 531 8148 3803 1444 1108 8148 MTBF (Hours) 20000000 115741 124239 155666 871080 1295337 26315789 9433962 4651163 71428571 33333333 12658228 9708738 71428571 RR / Year 0.0% 7.6% 7.1% 5.6% 1.0% 0.7% 0.0% 0.1% 0.2% 0.0% 0.0% 0.1% 0.1% 0.0%
Shelf Backplane 16 Port OC-3 FP Packet Server FP Control Processor 3 56G Fabric Card Cooling Unit (Up or Low) BIP Backplane PCP Breaker Module PCP Alarm Module PCP Power Interface Module Optical fiber MAC 1 ALARM/BITS 1 PIM 4
NTHR08 NTHW21 NTHW18BA NTHW06BA NTHR16 NTHR51/5 2 NT6C6002 NT6C60PA NT6C60PB NTHR15
Table 4 - RNC module MTBF
9.1.3
101B
Maintainability
The Mean Active Time to Repair (MTTR), the operational time needed to identify that the RNC requires active maintenance, plus the time required to repair/restore the RNC to normal operation shall not exceed 4 hours for all modules, with the exception of the backplane which requires 24 hours to replace.
9.1.4
102B
Overload Control
RNC overload occurs when the offered load of any resource in the RNC is beyond its rated engineered capacity. The Alcatel-Lucent overload control mechanisms adapt the behaviour of the RNC to the encountered overload situation in order to limit overload severity and to avoid resource starvation.
69 / 82

GRADUAL OVERLOAD
APRIL 2007
Gradual overload mechanisms provide a smooth adaptation by progressively restricting some functionalities of the RNC as overload increases. It concerns either call processing or OAM activities and gives preference to already established services and communications versus new establishments. The actions taken to limit overload severity are as follows: On local and global overload: progressive filtering of requests, with preference given to established calls and emergency calls On local overload: load balancing of calls to other processors.
PANIC OVERLOAD Panic mode overload mechanisms prevent resource exhaustion with a simple defense mechanism to avoid a crash, until gradual overload mechanisms react. Panic overload controls rely on the concept of discardable application messages. These discardable messages are dropped when message queues reach their panic threshold levels. CORE NETWORK OVERLOAD MESSAGE HANDLING RANAP overload messages from the Core Network are handled by the Alcatel-Lucent RNC. This is useful for both the Alcatel-Lucent automatic barring mechanism and the Iu-Flex feature introduced in release UA5.0. AUTOMATIC CELL BARRING ON SERVICE OUTAGE Cell and access class barring mechanisms are triggered automatically by the RNC under certain conditions. This allows throttling of traffic and causes traffic reselection to protect the system in following situations: Core network overload RNC overload Iu interface failure
Manual control and invocation of the cell and access class barring mechanism is also supported.
9.2
9.2.1

48B
REGULATORY COMPLIANCES
103B
Environmental Constraints
The regulatory specifications listed are based on the following assumptions: Regulatory approvals are required for the USA, Canada and Europe and do not presently cover other countries. Other markets could add additional design specifications. The RNC will always be connected to an Underwriters Laboratory/Canadian Standards Association (UL/CSA) certified CSU (or other Network Terminating equipment) that provides the secondary protection for lightning and AC power faults.
70 / 82
APRIL 2007
The following regulatory labels are required on the RNC product (depending on the intended market): Consumer Electronics (CE) Mark CSA marking (bi-national standard) for US and Canada FCC (Part 15 and Part 68) declaration
Alcatel-Lucent have also elected to include the voluntary VCCI Class B emissions logo on the regulatory label to indicate compliance to Japanese EMC requirements. The VCCI regulatory body have granted authorization for the RNC to bear the logo. A summary of the environmental and regulatory specifications of the RNC are as follows(for a complete list, please see appendix B): Storage requirements: the RNC meets the requirements of ETS 300 019-2-1, class 1.2. Transport requirements: the RNC meets the requirements of ETS 300 019-2-2, class 2.3 Operational requirements: the RNC meets the requirements of ETS 300 019-2-3, class 2.3 Ingress protection: the product has been evaluated for water and dust ingress protection according to IP20 (refer to IEC 529) Noise: RNC complies with ETS 300 753, allowing operators to install this product in "Telco center unattended" and "Power room" sites. In further releases, Alcatel-Lucent RNC will also comply with "Business center" sites. Seismic shock : the RNC can be installed in seismic areas up to Zone 4 (it corresponds to the highest areas, according to Telcordia GR-63-CORE).
The below table summarizes the normal operating conditions of the RNC. Parameter Normal operating temperature Normal relative operating humidity Short term operating humidity Temperature variation Earthquake Altitude Vibration Range 5C (41F) to 40C (104F) 10% to 90% relative humidity (no condensing) 5% to 90% relative humidity at 25C (77F) 30C (86F) per hour Up to zone 4 4000 m above sea level 0.1 G (1 m/s2) over the range 5 -200 Hz Table 5 - Environmental conditions
9.2.2
104B
Electromagnetic Compatibility
According to the European standards ETS 300 386 & EN 55022, the Alcatel-Lucent RNC is a Class B telecommunication product allowing operators to install this product in any domestic environment (note: for NAR markets only, the product is Class A, hence it should be installed within telecom centres).
9.2.3
105B
Safety Requirements
The RNC is compliant to EN 60950 (Europe) and CAN/CSA-C22.2 No. 60950-1-03 Bi-National Standard (US/Canada).
71 / 82

9.2.4 RNC RoHS Compliance
APRIL 2007
106B
The RNC complies to the European Union Environmental Directive on the Restriction of Hazardous Substances (RoHS -2002/95/EC/Article 4). Alcatel-Lucent take the lead exemption for telecommunication products. RoHS compliancy is only compulsory for newly deployed systems i.e. RoHS does not apply to extensions or upgrades/spares to systems which have been put on the market prior to July 1st 2006. The new RoHS elements have been re-designed so as to have a seamless transition towards the RoHS compliant module: i.e. there is no UTRAN software impact . RoHS and Non RoHS modules can co-exist in the same RNC system. Note that EuED does not permit Non RoHS modules to be added to a RoHS system sold after July 1 st 2006, but RoHS modules can be put in Non RoHS systems. Please refer to [14] Alcatel-Lucent UMTS RNC Portfolio Evolution: RNC ROHS Compliance for a full list of the RoHS PECs and conversion plans.
9.3
49B
Power Supply
Alcatel-Lucent provides an RNC which is DC powered, the nominal input voltage value of the RNC cabinet is 48 / 60 VDC. The acceptable variations in the input voltage of the equipment, under normal operation, range from -40 VDC to -72 VDC.
9.4
50B
Ventilation and Air Conditioning
The heat transfer is achieved by air forced cooling system. Two cooling units are placed in the middle of the frame: Upper cooling unit pushes air from the fans under modules to the top of the upper shelf assembly. The upper cooling unit is only installed if the upper shelf has been installed Lower cooling unit pulls air from the bottom of the frame to the rear of the lower shelf assembly
The maximum dissipation of the RNC cabinet is of 2600W. In case of risk of dust, the ventilation system must be equipped with a filter which complies with ETS 300 019-1-3 and for which maintenance is periodically performed.
72 / 82
APRIL 2007
Figure 29 - Cooling unit
9.5
9.5.1
51B
Physical Dimensions
107B
RNC Cabinet
The dimensions of the RNC cabinet are as follows: Without cosmetic panel Width (mm) Depth (mm) Height (mm) 600 600 2125 Table 6 - RNC cabinet dimensions With cosmetic panel 660 600 2125
73 / 82
APRIL 2007
Figure 30 - RNC rear view All Alcatel-Lucent UMT RNC models support optional side panels and doors Side panels provide a cosmetic finish to the exposed side of a frame, either at the end of a bolt together line-up or applied to sides of a standalone frame Doors complete with locks are available for front and rear of the frame. Mesh door panels maintain ventilation for system cooling
9.6

52B
Office Layout & Footprint
The layout of the RNC requires: a minimum ceiling clearance of 2.4m a minimum safety distance for front and rear maintenance activities of 0.9m
The footprint of the RNC requires: 600mm W x 600mm D = 0.360 m without cosmetic panels 660mm W x 600mm D = 0.396 m with cosmetic panels 66mm increase in front and rear for a total depth of 732mm when optional doors are used
74 / 82
APRIL 2007
9.7
53B
RNC Environmental Characteristics

Characteristics WxDxH without cosmetic side panels WxDxH with cosmetic side panel Max Weight for fully populated RNC with 12PSs Voltage Typical Power for fully populated RNC with 12PSs Max Power for fully populated RNC with 12PSs (estimated) Max Heat Dissipation Normal Operating Temperatures Short Term Operating Temperatures Temperature Variation Normal Relative Operating Humidity (non-condensing) Short Term Relative Operating Humidity (non-condensing) Acoustic Noise Level (normal conditions) Earthquake Zone Max Altitude m dba < 60 Up to Zone 4 4000 above sea level Unit mm Inches Mm Inches Kg/lbs V dc Nominal W W W/m2 C F C F C / hour F / hour % % RNC-1500 Single 600 x 600 x 2125 23.6 x 23.6 x 83.7 660 x 600 x 2125 25.9 x 23.6 x 83.7 420/925 -48 or -60 1730 2540 2580 5 to 40 41 to 104 -5 to 50 23 to 122 30 86 10 to 90 5 to 90
The table below provides the environmental characteristics of the RNC.
Table 7 - RNC environmental characteristics Note: Typical consumption is the average power consumption of the product, and maximum is the peak power requirements. As shown in this table, Alcatel-Lucent RNC supports -48V and -60V power input. The acceptable variations in the input voltage of the equipment, under normal operation, range from -40 VDC to -72 VDC.
75 / 82
APRIL 2007
10 APPENDIX A: REFERENCES
9B
[1] UMT/PLM/INF/004862 Alcatel-Lucent UMTS RNC Capacity Roadmap, v1.09 [2] UMT/SYS/DD/00128 Intelligent RAB mapping, v3.02 [3] UMT/SYS/DD/10672 iRM Pre-Emption, v1.02 [4] UMT/SYS/DD/0034 PS Call Management, v4.04 [5] UMT/SYS/DD/0086 Power management, v4.02 [6] UMT/SYS/DD/013319 HSDPA System Specification, v1.07 [7] MD-1998.0632 Passport 15000 Product Specification Agreement [8] 241-1501-200 Passport 15000 Hardware Description [9] Alcatel-Lucent 7670 ESE and RSP Hardware Description [10] UMT/SYS/INF/0025 UA02 Access Network Feature Planning Guide v1.13 [11] UMT/SYS/INF/0043 UA03 Access Network Feature Planning Guide v1.14 [12] UMT/SYS/INF/07906 UA04.1 Access Network Feature Planning Guide v1.11 [13] UMT/SYS/INF/12239 UA04.2 Access Network Feature Planning Guide v1.07 [14] UMT/COM/INF/016063 Alcatel-Lucent UMTS RNC Portfolio Evolution: RNC-1500 ROHS Compliance v3.07 [15] UMT/SYS/DD/009966 High Level Compliance to 3GPP specifications v05.02 UA05.0 [16] UMT/SYS/INF/016608 UA05 Access Network Feature Planning Guide [17] UMT/SYS/DD/0054 UMTS Radio Mobility [18] UMT/SYS/DD/018827 E-DCH System Specification
76 / 82
APRIL 2007
77 / 82
APRIL 2007
11 APPENDIX B: REGULATORY STANDARDS

10B
Safety (IT Equipment) UL60950-1 covered by CSA NRTL Mark CSA22.2 No 60950-1-03 EN60950-1 (December 2001) IEC 60950-1, edition 1(2001) CB Report to cover above Standards with National Deviations
Description Safety of Information Technology Equipment (United States) Safety of Information Technology Equipment (Canada) Safety of Information Technology Equipment (Europe) Safety of Information Technology Equipment (International) Safety of Information Technology Equipment generated by CSA from the above testing and used for international markets
Safety (Optical) FDA 21CFR Part 1040.10 IEC 60825-1 & IEC 60825 -2
Description North America Laser Safety International Laser Safety
EMC Emissions Class Limits Class A Class B Class B Class B Class B Class B Class B Regulatory Standards FCC Part 15 ICES 003 EN 300-386 CISPR 22 AS/NZS 3548 VCCI CNS13438 (CISPR 22) Description United States (Federal Communications Commission FCC) Canada European EC member Countries International (other than EC Countries Australia/New Zealand Japan Taiwan Regulatory Certificate BSMI
EMI Immunity Regulatory Standards ETSI 300-386-2 CISPR 22 Europe International Region
Interconnect Compliance Regulatory Standards

Alcatel-Lucent Proprietary See Notice on Page 2
Region
Description
Document Number: UMT/RAN/INF/012025 | Document Issue: 01.04 / EN | Document Status: Standard
78 / 82
APRIL 2007
ITU-T G.707, G.825, G. 957 CTR24 / TBR14
Europe Europe
Optical Interfaces E3 Interfaces
Network Synchronization Compliance Regulatory Standards ITU-T G.813 ITU-T G.823 ITU-T G.824, Telcordia GR-1244, ANSI T1.101 ITU-T G.813, Telcordia GR-1244, Telcordia GR-253, ANSI T1.101 Region Europe Europe N. America N. America Description Optical Interfaces E1 Interfaces Electrical Interfaces Optical Interfaces
Customer Requirements (Coverage for North America & Europe) GR-1089-CORE, Issue 4, June 2006 Electromagnetic Compatibility and Electrical Safety Generic Criteria for Network Telecommunications Equipment Network Equipment-Building System Requirements: Physical Protection
GR-63-CORE, Issue 3, March 2006
79 / 82
APRIL 2007
12 APPENDIX C: GLOSSARY OF TERMS

11B
12.1 Acronyms
54B
A-Z
AAL2 AAL5 ALCAP AP APC AS CAC CBC CDMA CN CPICH CRNC DC/DC DCH DRNS E1 EC EMC ESD ETSI FDD FPG GPRS GSM GUI H/W HSS I/F I/O ICP ATM Adaptation Layer 2 ATM Adaptation Layer 5 Access Link Control Application Part Application Processor Application Processing Complex Access Stratum Call Admission Control Cell Broadcast Centre Code Division Multiple Access Core Network Common Pilot Channel Controlling RNC Direct Current to Direct Current Dedicated Channel Drift RNS Standard European PCM link nickname European Community Electromagnetic Compatibility ElectroStatic Discharge European Telecommunications Standards Institute. Frequency Division duplex Feature Planning Guide General Packet Radio Service Global System for Mobile communications Graphical User Interface Hardware Half Split Shelf Interface Input/Output IMA Control Protocol Cell
80 / 82

IMA ISDN MAC MIB MPLS MS MTBF MTP MTTR NAS NBAP NE O&M OA&M OAM&P OC-3 OMC-R ORBiT OS PCM PMC PoC PSTN QoS RAB RAN RANAP RLC RNC RNS RNSAP RRC SABP SARing SCCP SIR SRNS SRS Inverse Multiplexing ATM Integrated Services Digital Network Medium Access Control Managed Information Base. Multi Protocol Label Switching Mobile Station Mean Time Between Failure Message Transfer Part Mean Time To Repair Non Access Stratum Node B Application Part Network Element Operation and Maintenance. Operation, Administration and Maintenance. Operations, Administration, Maintenance and Provisioning Optical Carrier level 3 (SONET) Operations and Management Console for Radio Optimized Radio Bearer Technology Operating System Pulse Code Modulation PCI Mezzanine Card Point of Concentration Public Switched Telephone Network Quality of Service Radio Access Bearer Radio Access Network Radio Access Network Application Part Radio Link Control Radio Network Controller Radio Network Subsystem Radio Network Subsystem Application Part Radio Resource Control Service Area Broadcast Protocol ExecutING frame Segmentation And Re-assembly Signalling Connection Control Part Signal over Interference Ratio Serving RNS Software Repository Server
APRIL 2007
81 / 82

SS7 STM-1 SWACT TDD TRAU UE UMTS UTRAN VCCI WCDMA W-NMS Common Channel Signalling number 7 Synchronous Transport level 1 (SDH) SWitch of ACTivity Time Division duplex TRAnscoding Unit User Equipment Universal Mobile telecommunication System UMTS Terrestrial Radio Access Network
APRIL 2007
Voluntary Control Council for Interference by Information Technology Equipment Wide band CDMA Wireless Network Management System
12.2 Glossary
55B
Node B MIB
The element in a UMTS network which interfaces with the mobile station, analogous to a Base Station in a GSM network. The Managed Information Base (MIB) contains all the configuration elements for the RNC ORBiT equipment itself as well as the configuration parameters of the radio access network which are under the control of the RNC ORBiT. Pulse Code Modulation is commonly used to refer to the primary rate signals which consist of multiplexed 64 kbit/s Channels sometimes containing PCM encoded voice. PCI Mezzanine Card is a standard of daughter board for VME SBCs. SWitch of ACTivity refers to a sparing action where an inactive board takes control over a faulty active board.
PCM
PMC SWACT
82 / 82

UMTS RNC Product Description v1 04

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

UMTS RNC Product Description v1 04

Hochgeladen von

Copyright:

Verfügbare Formate

Radio Network Controller

RADIO NETWORK CONTROLLER (RNC) PRODUCT DESCRIPTION

Copyright 2007 by Alcatel-Lucent Technologies. All Rights Reserved.

RADIO NETWORK CONTROLLER (RNC) PRODUCT DESCRIPTION

RADIO NETWORK CONTROLLER (RNC) PRODUCT DESCRIPTION

RADIO NETWORK CONTROLLER (RNC) PRODUCT DESCRIPTION

RADIO NETWORK CONTROLLER (RNC) PRODUCT DESCRIPTION

RADIO NETWORK CONTROLLER (RNC) PRODUCT DESCRIPTION

RADIO NETWORK CONTROLLER (RNC) PRODUCT DESCRIPTION

CO RE NETWO R K Packet/Circuit Switched

Itf -R Iub Iub Node B

RADIO NETWORK CONTROLLER (RNC) PRODUCT DESCRIPTION

Scope of this document

RADIO NETWORK CONTROLLER (RNC) PRODUCT DESCRIPTION

ALCATEL-LUCENT RNC BENEFITS

Market Leader Multi-Service Platform

RADIO NETWORK CONTROLLER (RNC) PRODUCT DESCRIPTION

One Architecture for all Traffic Profiles

Figure 2 - Packet Server Physical view

RADIO NETWORK CONTROLLER (RNC) PRODUCT DESCRIPTION

Multi-Service Transmission and IP UTRAN

Proven Carrier Grade

RADIO NETWORK CONTROLLER (RNC) PRODUCT DESCRIPTION

Efficient Radio Resource Management

RADIO NETWORK CONTROLLER (RNC) PRODUCT DESCRIPTION

Alcatel-Lucent Power control features are described in [5].

RADIO NETWORK CONTROLLER (RNC) PRODUCT DESCRIPTION

RADIO NETWORK CONTROLLER (RNC) PRODUCT DESCRIPTION

Expansion Space for 2nd UMTS RNC

RADIO NETWORK CONTROLLER (RNC) PRODUCT DESCRIPTION

UMTS RNC Architecture

RNC System Architecture

RADIO NETWORK CONTROLLER (RNC) PRODUCT DESCRIPTION

Fabric Fabric ATM

PC PC Master Master OMU OMU NI NI RAB RAB TMU TMU

PC PC Master Master OMU OMU NI NI RAB RAB TMU TMU

PS Functions (Logical view)

CONTROL PROCESSOR (CP3)

RADIO NETWORK CONTROLLER (RNC) PRODUCT DESCRIPTION

Figure 5 - CP3 module

RADIO NETWORK CONTROLLER (RNC) PRODUCT DESCRIPTION

Figure 6 - Packet Server FP module

RADIO NETWORK CONTROLLER (RNC) PRODUCT DESCRIPTION

Figure 7 - 16p OC3/STM1 card.

RADIO NETWORK CONTROLLER (RNC) PRODUCT DESCRIPTION

Figure 8 - Fabric module

BREAKER INTERFACE PANEL

RADIO NETWORK CONTROLLER (RNC) PRODUCT DESCRIPTION

CONTROL PROCESSOR (CP4)

4-port Gigabit Ethernet FP

RADIO NETWORK CONTROLLER (RNC) PRODUCT DESCRIPTION

Figure 9 - 4pt Gigabit Ethernet module

RNC Software Architecture

RADIO NETWORK CONTROLLER (RNC) PRODUCT DESCRIPTION

PMC-M PMC-M RAB RAB RAB RAB

TMU TMU TMU TMU TMU TMU

RAB RAB NI NI RAB RAB

RAB RAB RAB RAB RAB RAB

RAB RAB OMU OMU RAB RAB

RAB RAB RAB RAB RAB RAB

TMU TMU TMU TMU TMU TMU

RAB RAB RAB RAB RAB RAB

RAB RAB RAB RAB RAB RAB