RNC Product Description

Product Description

_________________________________________________________________________________________

Document Number: UMT/RAN/INF/012025Document Issue: 01.04/ ENDocument Status: StandardDate of Issue: 19/April/2007_________________________________________________________________________________________

Radio Network Controller

(RNC)

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: Hhttp://www.alcatel-lucent.com

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-Lucent’s 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 – ProprietarySee Notice on

2 / 82


CONTENTS

1 0BINTRODUCTION..................................................................................................8

1.1 12BOVERVIEW.....................................................................................................81.2 13BSCOPE OF THIS DOCUMENT.......................................................................................9

2 1BALCATEL-LUCENT RNC BENEFITS..........................................................................10

2.1 14BMARKET LEADER MULTI-SERVICE PLATFORM......................................................................102.2 15BHIGHEST DENSITY.............................................................................................102.3 16BONE ARCHITECTURE FOR ALL TRAFFIC PROFILES...................................................................112.4 17BHIGH SCALABILITY.............................................................................................112.5 18BMULTI-SERVICE TRANSMISSION AND IP UTRAN..................................................................122.6 19BPROVEN CARRIER GRADE.......................................................................................122.7 20BEFFICIENT RADIO RESOURCE MANAGEMENT........................................................................13

3 2BARCHITECTURE................................................................................................16

3.1 21BSYSTEM DESCRIPTION..........................................................................................163.2 22BUMTS RNC ARCHITECTURE...................................................................................17

3.2.1 56BRNC System Architecture.........................................................................173.2.2 57BModules Description................................................................................183.2.3 58BRNC Software Architecture.......................................................................24

3.3 23BTRANSPORT NODES: 7670 RSP AND ESE......................................................................283.3.1 59B7670 Routing Switch Platform (RSP)............................................................283.3.2 60B7670 Edge Services Extender (ESE)..............................................................28

3.4 24BRNC CAPACITY..............................................................................................293.4.1 61BRNC Capacity Metrics..............................................................................293.4.2 62BRNC-1500 UA05 Capacity and Scalability.......................................................293.4.3 63BRNC Capacity Border Limits......................................................................30

4 3BINTERFACES....................................................................................................32

4.1 25BUTRAN TRANSPORT – ATM TO IP EVOLUTION.................................................................324.2 26BIP TRANSPORT ON IUB........................................................................................334.3 27BRNC TO CORE NETWORK (IU).................................................................................34

4.3.1 64BDefinition............................................................................................344.3.2 65BImplementation....................................................................................35

4.4 28BIU-PC INTERFACE.............................................................................................354.4.1 66BDefinition............................................................................................354.4.2 67BImplementation....................................................................................36

4.5 29BRNC TO NODE B (IUB)......................................................................................374.5.1 68BDefinition............................................................................................374.5.2 69BImplementation....................................................................................39

4.6 30BRNC TO RNC (IUR)........................................................................................394.6.1 70BDefinition............................................................................................394.6.2 71BImplementation....................................................................................41

4.7 31BIU-BC INTERFACE.............................................................................................414.7.1 72BDefinition............................................................................................41

4.8 32BOMC CONNECTIVITY OPTIONS TO THE RNC.....................................................................424.9 33BINTERFACES SPECIFICATIONS.....................................................................................43

4.9.1 73BOC-3/STM1..........................................................................................434.9.2 74BE1.....................................................................................................434.9.3 75BSynchronization.....................................................................................43

4.10 34BINTERFACE COMPLIANCE......................................................................................44

5 4BRNC FUNCTIONALITY.........................................................................................46

5.1 35BRADIO RESOURCE MANAGEMENT (RRM).........................................................................465.1.1 76BAdmission Control..................................................................................475.1.2 77BCongestion Control.................................................................................485.1.3 78BPacket Switched Call Management..............................................................48


Alcatel-Lucent – ProprietarySee Notice on Page 2

3 / 82


5.2 36BMOBILITY....................................................................................................495.3 37BHSDPA.....................................................................................................51

5.3.1 79BHSDPA Background.................................................................................515.3.2 80BAlcatel-Lucent HSDPA Implementation.........................................................515.3.3 81BDynamic Power Control...........................................................................525.3.4 82BMulti-carrier HSDPA Traffic Segmentation....................................................525.3.5 83BHSDPA Mobility.....................................................................................525.3.6 84BAlways-On on HSDPA...............................................................................535.3.7 85BIub Bandwidth Limitation Handling.............................................................53

5.4 38BOTHER ALCATEL-LUCENT RNC FUNCTIONS......................................................................535.4.1 86BPDCP IP Header Compression.....................................................................535.4.2 87BSecurity Features...................................................................................545.4.3 88BSecurity between RNC and OMC.................................................................55

6 5BOPERATION AND MAINTENANCE............................................................................58

6.1 39BHARDWARE...................................................................................................586.1.1 89BMemory..............................................................................................586.1.2 90BCP3....................................................................................................58

6.2 40BHARDWARE HANDLING.........................................................................................596.3 41BSOFTWARE HANDLING..........................................................................................59

6.3.1 91BSoftware Management.............................................................................596.3.2 92BFault Management.................................................................................616.3.3 93BConfiguration Management.......................................................................626.3.4 94BPerformance Management........................................................................62

7 6BPROVISIONING AND ENGINEERING.........................................................................64

7.1 42BMARKET CONFIGURATIONS......................................................................................647.1.1 95BScalability...........................................................................................647.1.2 96BConfiguration Upgrades...........................................................................64

7.2 43BCONNECTIVITY................................................................................................647.3 44BINSTALLATION AND COMMISSIONING..............................................................................64

7.3.1 97BStart-up Tool........................................................................................647.3.2 98BSoftware Upgrading................................................................................64

8 7BFUTURE EVOLUTION..........................................................................................66

8.1 45BCAPACITY ROADMAP...........................................................................................668.2 46BRNC-ORBIT...............................................................................................66

9 8BHARDWARE TECHNICAL CHARACTERISTICS..............................................................68

9.1 47BRELIABILITY..................................................................................................689.1.1 99BPrinciples............................................................................................689.1.2 100BMean Time Between Failure (MTBF)...........................................................699.1.3 101BMaintainability....................................................................................699.1.4 102BOverload Control..................................................................................69

9.2 48BREGULATORY COMPLIANCES...........................................................................709.2.1 103BEnvironmental Constraints......................................................................709.2.2 104BElectromagnetic Compatibility.................................................................719.2.3 105BSafety Requirements.............................................................................719.2.4 106BRNC RoHS Compliance............................................................................72

9.3 49BPOWER SUPPLY...............................................................................................729.4 50BVENTILATION AND AIR CONDITIONING............................................................................729.5 51BPHYSICAL DIMENSIONS..........................................................................................73

9.5.1 107BRNC Cabinet.......................................................................................739.6 52BOFFICE LAYOUT & FOOTPRINT.................................................................................749.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..................................................................................................8012.2 55BGLOSSARY..................................................................................................82



4 / 82




5 / 82


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



6 / 82


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


1 0BINTRODUCTION

1.1 12BOverview

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-Lucent’s 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 RNC-1500 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 'Alcatel-Lucent 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-Lucent’s market-leading portfolio of the 7670 IP and ATM multi-service network equipment. XFigure 1X 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.

For further information about any Alcatel-Lucent products please refer to your local Alcatel-Lucent representative.

Iu-cs Iu-ps

UTRAN OMC

Itf -B

Itf -R

RNC

Iur

RNC

Iub

Node B

Iu-psIu-cs

Uu

UE

Iub

Node B

Iub

Node B

Iub

Node B

Uu

UEUE

Uu

UE

Uu

CORE NETWORKPacket/Circuit Switched



8 / 82


Figure 1 – UTRAN High-Level Architecture

1.2 13BScope 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


2 1BALCATEL-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 14BMarket 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 15BHighest 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


2.3 16BOne 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. XFigure 2 X provides a view of the PS.

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 RNC-ORBiT 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 17BHigh 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


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 18BMulti-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 multi-service platforms that already support IP.

2.6 19BProven Carrier Grade

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 XTable 1X, 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


• 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 UA5.0 UA6.0 UA7.0

99.995% 99.997% 99.999% 99.999%

RNC-1500 (UA4.1)

Increased On-line Parm modification

Closure of field availability gaps

RNC-1500 hitless patching

Mib Build at W-NMS

Increased on-line Parm modification

Overload Control Enhancements

Access Class Barring

Closure of Field availability gaps

RNC-ORBiT SW Architecture

Increased on-line Parm modification

RNC-ORBiT patching PSFP soft locking

1+1 Cell sparing

Increased On-line Parm modification

Less than 4 minute outage RNC upgrade

Hitless capacity expansion

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 20BEfficient 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

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 HHOThe 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

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-Lucent’s HSPA solution refer to [6] and [18].



15 / 82


3 2BARCHITECTURE

3.1 21BSystem Description

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 Alcatel-Lucent UMTS RNC transparently incorporates leading edge processor modules to deliver high-speed, high-touch bearer services as well as support of control plane functionalities and Radio Resource Management.

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

Expansion Space for 2nd

UMTS RNC


3.2 22BUMTS 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 Alcatel-Lucent 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 RNC’s 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 out-of-service fault detection.

3.2.1 56BRNC System Architecture

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). XFigure 4X

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


Figure 4 – RNC-1500 architecture

3.2.2 57BModules 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 108BRNC-1500

109BCONTROL 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

Iub, Iur, Iu

OC3/ STM-1

FP

OC3/ STM-1

FP

OC3/ STM-1

FP

OC3/ STM-1

FP

CP3CP3 CP3CP3

FabricFabric FabricFabric

Network Management

PCPC PCPC PCPC

MasterMaster MasterMaster

OMUOMU OMUOMU

NINI NINI

. . .

RABRAB RABRAB RABRAB. . .TMUTMU TMUTMU TMUTMU

. . .

Upto 12

Upto 40

Upto 14

PS Functions (Logical view)

2 per RNC

2 per RNC

2 per RNC

ATM

IP

Iub, Iur, Iu

OC3/ STM-1

FP

OC3/ STM-1

FP

OC3/ STM-1

FP

OC3/ STM-1

FP

CP3CP3 CP3CP3

FabricFabric FabricFabric

Network Management

PCPC PCPC PCPC

MasterMaster MasterMaster

OMUOMU OMUOMU

NINI NINI

. . .

RABRAB RABRAB RABRAB. . .TMUTMU TMUTMU TMUTMU

. . .

Upto 12

Upto 40

Upto 14

PS Functions (Logical view)

2 per RNC

2 per RNC

2 per RNC

ATM

IP


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

110BPACKET 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 (frame selection, buffering, synchronization, combining/splitting)



19 / 82


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

111BOC3 / 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 network-network 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


Figure 7 - 16p OC3/STM1 card.

112BMSS15K 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


Figure 8 - Fabric module

113BBREAKER 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 114BRNC-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


115BDUAL CORE PACKET SERVER FP

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.

116BCONTROL 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 RNC-ORBiT:

• 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)

117B4-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


Figure 9 - 4pt Gigabit Ethernet module

3.2.3 58BRNC 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 118BRNC-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


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.

Slot

Card Type 0 1 2 3 4 5

0 CP31 CP32 PS PMC-M TMU RAB RAB PC RAB3 PS PMC-M TMU RAB RAB PC RAB4 PS RAB TMU NI RAB PC OMU5 PS RAB TMU NI RAB PC OMU6 PS RAB TMU RAB RAB PC RAB7 PS RAB TMU RAB RAB PC RAB

8 OC3/STM19 OC3/STM110 PS RAB TMU RAB RAB PC RAB11 PS RAB TMU RAB RAB PC RAB12 PS RAB TMU RAB RAB PC TMU13 PS RAB TMU RAB RAB PC TMU14 PS RAB TMU RAB RAB PC RAB15 PS RAB TMU RAB RAB PC RAB

Figure 10 - PMC role assignment in the RNC-1500 (12 PSFP full configuration)

3.2.3.2 119BRNC-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 RNC-ORBiT 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


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


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 re-assembly, 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.

Slot

Card Type 0 1 2 3 4 5

0 CP41 CP42 DCPS CMU OCS TMU OPS TMU NI3 DCPS CMU OCS TMU OPS TMU NI4 DCPS CMU OCS TMU OPS TMU OMU5 DCPS CMU OCS TMU OPS TMU OMU

6 DCPS CMU OCS TMU OPS TMU OPS7 DCPS CMU OCS TMU OPS TMU OPS

8 OC3/STM19 OC3/STM110 DCPS CMU OCS TMU OPS TMU OPS11 DCPS CMU OCS TMU OPS TMU OPS12 DCPS CMU OCS TMU OPS TMU OPS13 DCPS CMU OCS TMU OPS TMU OPS14 DCPS CMU OCS TMU OPS TMU OPS15 DCPS CMU OCS TMU OPS TMU OPS

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 XFigure 12 X, applies to both PSFP and DCPS cards.

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


3.3 23BTransport 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 59B7670 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

3.3.2 60B7670 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 Alcatel-Lucent 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


3.4 24BRNC 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 61BRNC 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 62BRNC-1500 UA05 Capacity and Scalability

The capacity commitments for Speech and Mobile Office Internet profiles for the UA05 release are provided in XTable 2X.

Service & Bearer Capacity of RNC-1500

RABTypical Service

Iu Mbit/s Applicatio

n Layer

Iu Mbit/s

Physical Layer

ReferenceSubscribers

Simultaneous TRB

subscribers

CS Conv.12,2AMR Speech 49 83 225 000 3900

CS Conv. 64Video Telephony 140 180 100 000 1100

PS I/B 64/64 Basic Browsing 110 130 530 000 3000

PS I/B 64/128Mobile Office Internet 176 217 500 000 2500

PS I/B 64/128 Video Streaming 220 270 130 000 1700

PS I/B 64/64 Audio Streaming 130 160 140 000 2100

PS I/B 64/384Mobile Office Premium 220 260 220 000 1100

R99 RABs R99 Service-mix 88 120 49 000 2500

R99, HSDPA & EDCH RABs

HSPA Service-mix 88 120 70 000 2500

Table 2 – RNC-1500 Capacity with UA05 Software



29 / 82


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 1506 1507¹ 1508² 1510 1512

Node B 80 120 140 160 200 200

Cells 360 600 720 800 1200 1200

Speech (Erlangs)

980 1600 2000 2550 3300 3900

Mobile Office Internet (Mbit/s)

44 73 88 105 147 176

¹ MD UA06; ² Introduced in UA06

Table 3 - RNC-1500 Scalability with UA05 Software

3.4.3 63BRNC 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


This page has been intentionally left blank



31 / 82


4 3BINTERFACES

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 25BUTRAN 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-Lucent’s 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 operator’s 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-Lucent’s 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


Figure 14 - Alcatel-Lucent RNC – seamless evolution to IP transport

4.2 26BIP 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

HybridMacroBTS

RNCs

ATM TransportNetworks

ATM TransportNetworksATM

Transport

ATM Transport

IP Transport IP Transport

RNC2500

IuB IuCS, IuR, IuPS

ATMMacroBTS

Pico IP

All traffic on ATM

All traffic on IP

HSPA on IP

R99 & optionally HSPA

IP TransportNetworks


CS CoreNetworkElements

PS CoreNetworkElements

IP Virtual RouterTraffic Separation

VLANGE

VLANGE

HybridMacroBTS

HybridMacroBTS

RNCsRNCs

ATM TransportNetworks

ATM TransportNetworksATM

Transport

ATM Transport

IP Transport IP Transport

RNC2500

IuB IuCS, IuR, IuPS

ATMMacroBTS

ATMMacroBTS

Pico IP

All traffic on ATM

All traffic on IP

HSPA on IP

R99 & optionally HSPA



CS CoreNetworkElements

PS CoreNetworkElements

IP Virtual RouterTraffic Separation

VLANGE

VLANGE


4.3 27BRNC to Core Network (Iu)

4.3.1 64BDefinition

The Iu interface connects the UTRAN to the Core network. The Iu interface towards the PS-domain 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 XFigure 16 X and XFigure 17 X respectively. Note, that Alcatel-Lucent 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.

AAL2

UDP/IP

RTP/ RTCP*)

Data Link ATM ATM Data Link

M3UA

Q.2630. 2

RANAP Iu UP Protocol Layer

Transport Network

Layer

Physical Layer

Transport User

Network Plane

Control Plane User Plane

Transport User

Network Plane

Transport Network Control Plane

Radio Network

Layer

SSCOP

AAL5

SSCOP

SSCF -NNI

AAL5

MTP3b MTP3b

SCCP

SSCF -NNI

IP

SCTP

ATM

Q.2150.1

*) RTCP is optional.

Figure 16 - Iu-CS protocol stacks – ATM and IP



34 / 82


IP SSCOP

AAL5

SCTP

MTP3-B M3UA

SCCP

M3UA

RANAP Iu UP Protocol Layer

Tra

nspo

rt N

etw

ork

Lay

er

Physical Layer

Transport User

Network Plane

Control Plane User Plane

Transport User

Network Plane

Transport Network

Control Plane

Rad

io N

etw

ork

Lay

er

AAL5

IP

UDP

GTP-U

Physical Layer

ATM Data Link

IP

SCTP

Data Link ATM

IP

UDP

GTP-U SSCF-NNI

Figure 17 - Iu-PS protocol stacks – ATM and IP

4.3.2 65BImplementation

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 28BIu-PC Interface

4.4.1 66BDefinition

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


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 user’s 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.


The RNC connects to the operator’s 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.

120BTypes 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


121BA-GPS Services

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 29BRNC to Node B (IuB)

4.5.1 68BDefinition

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


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.

Figure 20 – IuB protocol stack – IP



38 / 82

NBAP

SCTP

Iub FPs

UDP

IP

Ethernet

C-Plane U-Plane

NBAP

SCTP

Iub FPs

UDP

IP

Ethernet

C-Plane U-Plane


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.


The signalling bearer for NBAP is a point-to-point protocol. There may be multiple point-to-point 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-Lucent’s 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 30BRNC to RNC (IuR)

4.6.1 70BDefinition

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


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.

Figure 22 - IuR protocol stack – IP



40 / 82

RNSAP

SCTP

Iur FPs

UDP

IP

Ethernet

C-PlaneU-Plane

M3UA

SCCP



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 Alcatel-Lucent’s 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 31BIu-BC Interface

4.7.1 72BDefinition

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.

SABP Protocol Layer

Transport Network

Layer

SA Broadcast Plane

Transport User

Network Plane

Radio Network

Layer

Data Link ATM

AAL5

IP

TCP

IP

TCP

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


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.

Uu

CellBroadcast

Center

(CBC)

UTRAN

RNCNode B

Node BUE

UE

1

Iub

IuBC

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 32BOMC 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


4.9 33BInterfaces Specifications

4.9.1 73BOC-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 multi-service (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

4.9.2 74BE1

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-PHY-0086.001, March 99) is used on the IuB interface.

4.9.3 75BSynchronization

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:

• Internal Timing Reference

• External Timing Reference

• Line timing Reference

122BINTERNAL 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:

• Accuracy: +/- 4.6x10-6 (+/- [email protected] MHz / [email protected]) )

• Stability: +/- 3.7x10-7/day for the initial 24 hours of holdover

• Pull in range: +/-4.6x10-6

123BEXTERNAL 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 (OC-3/STM-1) must meet the synchronization requirements for optical interfaces.

124BLINE 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 34BInterface Compliance

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

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


5 4BRNC 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 35BRadio 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-Lucent’s 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-Lucent’s 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 76BAdmission Control

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.

2 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.

iRM

CAC

RAB request

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

MIB

Supported RB bit rate

4. RNC checks resources availability for selected RB

Admitted : Yes/No

Already established RB, e.g. voice call

Selected RB

RAB Matching

Candidate RB selection

RB Selection

3. Reference RB is combined with SRB and already established RB (if any)

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


5.1.2 77BCongestion 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 Evaluation of system load (DL and UL) at cell level

2 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

5.1.2.1 125BCell 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

5.1.3 78BPacket 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


• 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 36BMobility

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


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


• unifiedRRM: the fundamental concept of Alcatel-Lucent’s 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 mobile-network 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 37BHSDPA

5.3.1 79BHSDPA 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 Alcatel-Lucent UMTS BTS and RNC are HSDPA hardware ready and therefore will not require a hardware change.

5.3.2 80BAlcatel-Lucent HSDPA Implementation

The full benefits of Alcatel-Lucent’s 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

• 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 81BDynamic 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 Node-B 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.

5.3.4 82BMulti-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.

5.3.5 83BHSDPA Mobility

Alcatel-Lucent’s 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


• 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 multi-service 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 84BAlways-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

5.3.7 85BIub 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 38BOther Alcatel-Lucent RNC Functions

5.4.1 86BPDCP 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


This much more robust scheme for air interface will be provided when dealing with IP based multimedia applications.

5.4.2 87BSecurity 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


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 Alcatel-Lucent 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 R’99 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).

5.4.3 88BSecurity 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


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





57 / 82


6 5BOPERATION AND MAINTENANCE

This section describes the operations and maintenance of Alcatel-Lucent’s 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 39BHardware

6.1.1 89BMemory

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 90BCP3

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


6.2 40BHardware 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 41BSoftware 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 91BSoftware Management

6.3.1.1 126BSoftware 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


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 127BSoftware 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 128BRNC 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 129BPatch 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


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 92BFault 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 130BPreventive 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 131BAlarm 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


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 93BConfiguration 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 132BOn-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 133BOff-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 94BPerformance 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 134BCounters

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 135BCall 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





63 / 82


7 6BPROVISIONING AND ENGINEERING

7.1 42BMarket Configurations

7.1.1 95BScalability

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 Alcatel-Lucent will introduce a new model with 8 PSs and manufacture discontinue the 7 PS model.

7.1.2 96BConfiguration 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 43BConnectivity

The RNC provides a set of physical interfaces towards other network elements to be easily integrated in the customer’s 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 44BInstallation and Commissioning

7.3.1 97BStart-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 98BSoftware 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





65 / 82


8 7BFUTURE EVOLUTION

8.1 45BCapacity Roadmap

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 46BRNC-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 RNC-ORBiT. 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

Optional DCPS

+

UA05RNC 1500

UA06RNC-ORBiT

704Mbit/s¹352Mbit/s¹176Mbit/s¹

900Mbit/s²450Mbit/s²225Mbit/s²

16,000Erl

4,800 Cells

4,800 Node B

8,000Erl3,900Erl

2,400 Cells1,200 Cells

2,400 Node B200 Node B

UA06RNC-ORBiT DCPS

SW Upgrade

x2 x2

¹ PS I/B 64/128; ² PS I/B 64/384

Optional DCPS

+

UA05RNC 1500

UA06RNC-ORBiT

704Mbit/s¹352Mbit/s¹176Mbit/s¹

900Mbit/s²450Mbit/s²225Mbit/s²

16,000Erl

4,800 Cells

4,800 Node B

8,000Erl3,900Erl

2,400 Cells1,200 Cells

2,400 Node B200 Node B

UA06RNC-ORBiT DCPS

SW Upgrade

x2 x2

¹ PS I/B 64/128; ² PS I/B 64/384


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


9 8BHARDWARE TECHNICAL CHARACTERISTICS

9.1 47BReliability

9.1.1 99BPrinciples

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


9.1.2 100BMean Time Between Failure (MTBF)

The predicted MTBF, return rates and failure rate per module for a MTTR = 4 hours is shown in XTable 4

Description Code

Committed

Failure Rate (FITS)

MTBF (Years)

MTBF (Hours) RR / Year

Shelf Backplane NTHR08 50 2282 20000000 0.0%

16 Port OC-3 FP NTHW21 8640 13 115741 7.6%

Packet Server FP NTHW18BA 8049 14 124239 7.1%

Control Processor 3 NTHW06BA 6424 18 155666 5.6%

56G Fabric Card NTHR16 1148 99 871080 1.0%

Cooling Unit (Up or Low)

NTHR51/52 772 148 1295337 0.7%

BIP Backplane PCP NT6C6002 38 3002 26315789 0.0%

Breaker Module PCP NT6C60PA 106 1076 9433962 0.1%

Alarm Module PCP NT6C60PB 215 531 4651163 0.2%

Power Interface Module NTHR15 14 8148 71428571 0.0%

Optical fiber 30 3803 33333333 0.0%

MAC 1 NTHR11 79 1444 12658228 0.1%

ALARM/BITS 1 NTHR13/14 103 1108 9708738 0.1%

PIM 4 14 8148 71428571 0.0%

Table 4 - RNC module MTBF

9.1.3 101BMaintainability

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 102BOverload 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

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 48BREGULATORY COMPLIANCES

9.2.1 103BEnvironmental 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


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 Range

Normal operating temperature 5°C (41°F) to 40°C (104°F)

Normal relative operating humidity

10% to 90% relative humidity (no condensing)

Short term operating humidity 5% to 90% relative humidity at 25°C (77°F)

Temperature variation 30°C (86°F) per hour

Earthquake Up to zone 4

Altitude 4000 m above sea level

Vibration 0.1 G (1 m/s2) over the range 5 -200 Hz

Table 5 - Environmental conditions

9.2.2 104BElectromagnetic 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 105BSafety 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 106BRNC RoHS Compliance

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 1st 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 49BPower 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 50BVentilation 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


Figure 29 - Cooling unit

9.5 51BPhysical Dimensions

9.5.1 107BRNC Cabinet

The dimensions of the RNC cabinet are as follows:

Without cosmetic panel With cosmetic panel

Width (mm) 600 660

Depth (mm) 600 600

Height (mm) 2125 2125

Table 6 - RNC cabinet dimensions



73 / 82


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 52BOffice 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


9.7 53BRNC Environmental Characteristics

The table below provides the environmental characteristics of the RNC.

Characteristics Unit RNC-1500 Single

W x D x Hwithout cosmetic side panels

mmInches

600 x 600 x 212523.6 x 23.6 x 83.7

W x D x H with cosmetic side panel

MmInches

660 x 600 x 212525.9 x 23.6 x 83.7

Max Weight for fully populated RNC with 12PSs

Kg/lbs 420/925

Voltage V dc Nominal -48 or -60

Typical Power for fully populated RNC with 12PSs

W 1730

Max Power for fully populated RNC with 12PSs (estimated)

W 2540

Max Heat Dissipation W/m2 2580

Normal Operating Temperatures

C F

5 to 4041 to 104

Short Term Operating Temperatures

C F

-5 to 5023 to 122

Temperature Variation C / hour F / hour

3086

Normal Relative Operating Humidity (non-condensing)

% 10 to 90

Short Term Relative Operating

Humidity (non-condensing)

% 5 to 90

Acoustic Noise Level(normal conditions)

dba < 60

Earthquake Zone Up to Zone 4

Max Altitude m 4000 above sea level

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


10 9BAPPENDIX A: REFERENCES

[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





77 / 82


11 10BAPPENDIX B: REGULATORY STANDARDS

Safety (IT Equipment) Description

UL60950-1 covered by CSA NRTL Mark Safety of Information Technology Equipment (United States)

CSA22.2 No 60950-1-03 Safety of Information Technology Equipment (Canada)

EN60950-1 (December 2001) Safety of Information Technology Equipment (Europe)

IEC 60950-1, edition 1(2001) Safety of Information Technology Equipment (International)

CB Report to cover above Standards with National Deviations

Safety of Information Technology Equipment generated by CSA from the above testing and used for international markets

Safety (Optical) Description

FDA 21CFR Part 1040.10 North America Laser Safety

IEC 60825-1 & IEC 60825 -2 International Laser Safety

EMC Emissions

Class Limits Regulatory Standards Description

Class A FCC Part 15 United States (Federal Communications Commission – FCC)

Class B ICES 003 Canada

Class B EN 300-386 European EC member Countries

Class B CISPR 22 International (other than EC Countries

Class B AS/NZS 3548 Australia/New Zealand

Class B VCCI Japan

Class B CNS13438 (CISPR 22) Taiwan Regulatory Certificate BSMI

EMI Immunity

Regulatory Standards Region

ETSI 300-386-2 Europe

CISPR 22 International

Interconnect Compliance

Regulatory Standards Region Description



78 / 82


ITU-T G.707, G.825, G. 957 Europe Optical Interfaces

CTR24 / TBR14 Europe E3 Interfaces

Network Synchronization Compliance

Regulatory Standards Region Description

ITU-T G.813 Europe Optical Interfaces

ITU-T G.823 Europe E1 Interfaces

ITU-T G.824, Telcordia GR-1244, ANSI T1.101 N. America Electrical Interfaces

ITU-T G.813, Telcordia GR-1244, Telcordia GR-253, ANSI T1.101 N. America 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

GR-63-CORE, Issue 3, March 2006 Network Equipment-Building System Requirements: Physical Protection



79 / 82


12 11BAPPENDIX C: GLOSSARY OF TERMS

12.1 54BAcronyms

A - Z

AAL2 ATM Adaptation Layer 2

AAL5 ATM Adaptation Layer 5

ALCAP Access Link Control Application Part

AP Application Processor

APC Application Processing Complex

AS Access Stratum

CAC Call Admission Control

CBC Cell Broadcast Centre

CDMA Code Division Multiple Access

CN Core Network

CPICH Common Pilot Channel

CRNC Controlling RNC

DC/DC Direct Current to Direct Current

DCH Dedicated Channel

DRNS Drift RNS

E1 Standard European PCM link nickname

EC European Community

EMC Electromagnetic Compatibility

ESD ElectroStatic Discharge

ETSI European Telecommunications Standards Institute.

FDD Frequency Division duplex

FPG Feature Planning Guide

GPRS General Packet Radio Service

GSM Global System for Mobile communications

GUI Graphical User Interface

H/W Hardware

HSS Half Split Shelf

I/F Interface

I/O Input/Output

ICP IMA Control Protocol Cell



80 / 82


IMA Inverse Multiplexing ATM

ISDN Integrated Services Digital Network

MAC Medium Access Control

MIB Managed Information Base.

MPLS Multi Protocol Label Switching

MS Mobile Station

MTBF Mean Time Between Failure

MTP Message Transfer Part

MTTR Mean Time To Repair

NAS Non Access Stratum

NBAP Node B Application Part

NE Network Element

O&M Operation and Maintenance.

OA&M Operation, Administration and Maintenance.

OAM&P Operations, Administration, Maintenance and Provisioning

OC-3 Optical Carrier level 3 (SONET)

OMC-R Operations and Management Console for Radio

ORBiT Optimized Radio Bearer Technology

OS Operating System

PCM Pulse Code Modulation

PMC PCI Mezzanine Card

PoC Point of Concentration

PSTN Public Switched Telephone Network

QoS Quality of Service

RAB Radio Access Bearer

RAN Radio Access Network

RANAP Radio Access Network Application Part

RLC Radio Link Control

RNC Radio Network Controller

RNS Radio Network Subsystem

RNSAP Radio Network Subsystem Application Part

RRC Radio Resource Control

SABP Service Area Broadcast Protocol

SARing ExecutING frame Segmentation And Re-assembly

SCCP Signalling Connection Control Part

SIR Signal over Interference Ratio

SRNS Serving RNS

SRS Software Repository Server



81 / 82


SS7 Common Channel Signalling number 7

STM-1 Synchronous Transport level 1 (SDH)

SWACT SWitch of ACTivity

TDD Time Division duplex

TRAU TRAnscoding Unit

UE User Equipment

UMTS Universal Mobile telecommunication System

UTRAN UMTS Terrestrial Radio Access Network

VCCI Voluntary Control Council for Interference by Information Technology Equipment

WCDMA Wide band CDMA

W-NMS Wireless Network Management System

12.2 55BGlossary

Node B The element in a UMTS network which interfaces with the mobile station, analogous to a Base Station in a GSM network.

MIB 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.

PCM 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.

PMC PCI Mezzanine Card is a standard of daughter board for VME SBCs.

SWACT SWitch of ACTivity refers to a sparing action where an inactive board takes control over a faulty active board.



82 / 82

RNC Product Description

Documents

Transcript of RNC Product Description