01 RN30031EN40GLA0 RAN Equipments PDF

3GTPL RAN Equipment
RN30031EN40GLA0 ©2014 Nokia Solutions and Networks. All rights reserved.

Nokia Solutions and Networks Academy
Legal notice
Intellectual Property Rights

All copyrights and intellectual property rights for Nokia Solutions and Networks
training documentation, product documentation and slide presentation material, all of
which are forthwith known as Nokia Solutions and Networks training material, are the
exclusive property of Nokia Solutions and Networks. Nokia Solutions and Networks
owns the rights to copying, modification, translation, adaptation or derivatives
including any improvements or developments. Nokia Solutions and Networks has the
sole right to copy, distribute, amend, modify, develop, license, sublicense, sell,
transfer and assign the Nokia Solutions and Networks training material. Individuals
can use the Nokia Solutions and Networks training material for their own personal
self-development only, those same individuals cannot subsequently pass on that
same Intellectual Property to others without the prior written agreement of Nokia
Solutions and Networks. The Nokia Solutions and Networks training material cannot
be used outside of an agreed Nokia Solutions and Networks training session for
development of groups without the prior written agreement of Nokia Solutions and
Networks.
2 RN30031EN40GLA0 ©2014 Nokia Solutions and Networks. All rights reserved.

Objectives
• This module is mainly focusing on new mcRNC product

characteristics and then giving an overview of IPA RNC and
Flexi Multiradio equipments.
• Objective of this module is to

– Briefly introduce UTRAN interfaces and equipments
– Explain mcRNC architecture
– Compare main aspects of mcRNC and IPA RNC
– Introduce Flexi Multiradio main aspects

RAN Equipment
• Introduction
• mcRNC Introduction
• mcRNC Architecture
• mcRNC Scalability and Resources Management
• Networking and Transport
• mcRNC Protection
• Operability
• Calls Flow compared to cRNC
• IPA-RNC
• Flexi Multiradio

UTRAN Interfaces
SAS
or
Iu-pc A-GPS
Server
or
UTRAN ADIF
Uu
WBTS Iu-BC CBC
SRNC
WBTS
Iu-CS 3G-
MSC
Iub Iur
Iu-PS
User Equipment
(UE) WBTS
3G-
DRNC SGSN
WBTS
Core Network
(CN)

UTRAN Interfaces
Picture shows UTRAN interfaces. In addition to the MSC and SGSN, interfaces to optional
core network nodes are shown:
CBC (Cell Broadcast Centre) supports cell broadcast traffic to all mobiles within a
service area.
SAS (Standalone SMLC, Standalone Serving Mobile Location Centre) or Assisted
GPS (A-GPS) server supports location services (LCS).
For location services the following methods are supported by RNC:
Cell Coverage Based with Geographical Coordinates

In the Cell Coverage Based positioning method, the location of the UE is estimated on the
basis of its serving cell. Information about the serving cell is obtained, for example, by
paging, location area update, cell update, URA update or routing area update.
Assisted GPS
Since RAS05.1 / RAS05.1 ED, in addition to Cell Coverage Based positioning, A-GPS
(Assisted GPS) is supported. The objective of this method is to forward to the UE the GPS
Navigation Message in a specified Assistance Measurement Control message. Hence, the
satellite acquisition time can be significantly reduced and the availability of the positioning
service can be enhanced to urban canyons and light indoor environments. Moreover, the A-
GPS positioning accuracy can be improved if rough location of the UE can be included in the
Assistance Measurement Control message. Rough position of the UE can be estimated
based on, e.g., introduced Cell Coverage Based location technique.
IP Based Iub
Protocol Stack
Control Plane User Plane

Iub User Plane Protocol
NBAP
BFD
SCTP ICMPv4 UDP ICMPv4
IPv4 ARP IPv4 ARP
Ethernet-MAC Ethernet-MAC
Ethernet-Phy Ethernet-Phy

IP Based Iu-CS
Protocol Stack
RANAP
Iu User Plane Protocol
SCCP
RTP
M3UA OSPFv2 ICMPv4
OSPFv2 ICMPv4 UDP
SCTP
InATMARP IPv4
IPv4
ARP
LLC/SNAP ARP
AAL5
ATM
SDH/SONET Ethernet-PHY Ethernet-Phy

IP Based Iu-PS
Protocol Stack
RANAP
Iu User Plane Protocol

SCCP
M3UA GTP-U
OSPF ICMP OSPF ICMP 4
SCTP v2 v4 UDP v2 v4
InATMARP InATMARP
IPv4 IPv4
LLC /SNAP ARP LLC/SNAP ARP
Ethernet-Phy - Ethernet-Phy

IP Based Iu-PS, cont.
Protocol Stack
Feature ID: RAN750

This feature enables the use of IP and Ethernet transport according to 3GPP Rel-5 and Rel-
6, at the Iu-PS interface for the RNC. It supports IP over Ethernet for the user plane and
control plane, and IP over ATM for the control plane
Benefits for the operator:

OPEX and CAPEX savings in transport between RNC and Core Networks nodes. This
feature allows to use more cost efficient transport network for Iu-PS traffic
Functional description:
With this feature the RNC supports 3GPP Rel-5 / Rel-6 compliant protocol stack on Iu-PS
interface. Dual stack operation allows usage of ATM Iu-PS and IP Iu-PS simultaneously. A
connection to a single SGSN can be either ATM or IP based.
IP Differentiated Services Code Point (DSCP) marking is the backbone of the QoS solution
for the Iu-PS over IP. The IP packets are classified into PHBs according to the DSCP field in
the IP header and based on this information the RNC and routers schedule the packets. The
RNC supports a scheduling algorithm with multiple queues, which are used to implement the
PHBs. Scheduling is based on the Weighted Fair Queuing policy. WRED is also supported to
avoid TCP global synchronization.

IP Based Iu-PS, cont.
Protocol Stack
Maximum Transmission Unit (MTU) defines the largest datagram that can be transmitted by an IP interface. If
the IP packet size exceeds the MTU, the RNC fragments the packet into smaller units. In the Ethernet network
the MTU is 1500 bytes. The RNC is able to operate with bigger than 1500 bytes MTU if the external network
supports it.RTP is used to carry the user plane traffic. RTCP is supported in order to monitor lost packets and
delay variance. Additionally, RTCP can be used to supervise the continuity of the RTP session.
This solution is based on IPv4 as IPv4 networks are very widely used and they are expected to be favored in
the future as well.
Interdependencies between features:

•This feature requires the RNC Ethernet Physical Interface feature
•This feature needs to be activated in order to use RAN1510 ”OSPF for redundancy”
•The end-user will have the same service experience with this feature as with the default ATM transport option
•This feature does not replace any older features
Note:
Control plane
Same as Iu-CS
User Plane
GTP-U
•Tunneling protocol between RNC and SGSN
•Multiplexing of user contexts
- Tunnel endpoint identifier
•Based on single UDP port (2152)
•Keep-alive messages
- Echo request / reply („GTP signalling“)
IP Based Iur
Protocol Stack
RNSAP Control Plane User Plane

Iur User Plane
Protocol
SCCP BFD
M3UA
OSPF ICMP UDP
SCTP v2 v4 OSPFv2 ICMPv4
InATMARP
IPv4 IPv4
LLC /SNAP ARP ARP
AAL5
ATM
SDH/SONET Ethernet-Phy
- Ethernet-Phy

14
WBTS RNC
4
3
NIP1 2 NIP1 0 SFU 1 SFU 0
NIP1 3 NIP1 1
ICSU ICSU NIS1P 5 NIS1P 4
ICSU ICSU NIS1P 7 NIS1P 6
ICSU ICSU NISx 1 NISx 0
DMCU DMCU Optional ESA24 A2SU
CPD80-B 0
DMCU DMCU RRMU 1 ICSU RRMU 0 ICSU

DMCU DMCU RSMU 1 RSMU 0
RNC196 CS1-5
MXU 4 MXU 2 MXU 1 MXU 0

PD20 PD20 PD20 PD20
MXU 5 MXU 3 FDU (OMU) EHU
DMCU DMCU ESA24
ESA12 / ESA24
DMCU DMCU NEMU
DMCU DMCU HDD 1 (NEMU) HDD 0 (NEMU)
A2SU A2SU
ICSU - OMU 1 OMU 0
CPD80-B 1
RRMU removed. Release plug-in unit configured as ICSU.

GTPU GTPU WDU 1 (OMU) WDU 0 (OMU)
NISx 3 NISx 2
38
38
38
38
TBUF TSS3
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
TBUF TBUF TBUF TBUF TSS3 TBUF
4
3
2
1
NIP1 10 NIP1 8 NIP1 6 NIP1 4

NIP1 11 NIP1 9 NIP1 7 NIP1 5
ICSU ICSU ICSU ICSU
ICSU ICSU ICSU ICSU
ICSU ICSU ICSU ICSU
step 1-8
DMCU DMCU DMCU DMCU

RNC196
CPD80-B 0
DMCU DMCU DMCU DMCU

DMCU DMCU DMCU DMCU
Metrosite
PD20 PD20 PD20 PD20
DMCU DMCU DMCU DMCU
DMCU DMCU DMCU DMCU
DMCU DMCU DMCU DMCU
A2SU A2SU A2SU A2SU
GTPU GTPU GTPU GTPU
CPD80-B 1
DMCU DMCU DMCU DMCU

DMCU DMCU DMCU DMCU
38
38
38
38
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
TBUF TBUF TBUF TBUF TBUF TBUF TBUF TBUF
4
3
2
1
1
1
1
1
DMCU DMCU SFU 1 SFU 0

2
2
2
2
DMCU DMCU
3
3
3
3
ICSU ICSU DMCU DMCU

4
4
4
4
ICSU ICSU DMCU DMCU

5
5
5
5
ICSU ICSU Optional ESA24 ESA24

6
6
6
6
DMCU DMCU GTPU OMS

7
7
7
7
DMCU DMCU RRMU 1 ICSU RRMU 0 ICSU

8
8
8
8
DMCU DMCU RSMU 1 RSMU 0

PD30 PD30 PD30 PD30
A2SU A2SU A2SU A2SU
RNAC
DMCU DMCU A: WDU 1 OMU A2SU

DMCU DMCU B: HDD 1 NEMU A: WDU 0 OMU
NIS1P / NIS1 5 NIS1P / NIS1 4 / (Opt. NIP1) EHU B: HDD 0 NEMU
RRMU removed. Release plug-in unit configured as ICSU.
GTPU GTPU OMU 1 OMU 0

NIS1P / NIS1 1 NIS1P / NIS1 0 ICSU ICSU
NSN RAN Equipments
NIS1P / NIS1 3 NIS1P / NIS1 2 ICSU ICSU

38
9 10 11 12 13 14 15 16 17 18 19
38
9 10 11 12 13 14 15 16 17 18 19
38
9 10 11 12 13 14 15 16 17 18 19
38
9 10 11 12 13 14 15 16 17 18 19
TBUF TBUF TBUF TBUF TSS3 TBUF TBUF TSS3
RN30031EN40GLA0
4
3
2
1
1
1
1
1
- - - -
2
2
2
2
DMCU DMCU DMCU DMCU

3
3
3
3
ICSU ICSU ICSU ICSU

4
4
4
4
ICSU ICSU ICSU ICSU

5
5
5
5
ICSU ICSU ICSU ICSU

6
6
6
6
Ultrasite
DMCU DMCU - DMCU

7
7
7
7
DMCU DMCU DMCU DMCU

8
8
8
8
DMCU DMCU DMCU DMCU

step 1-3

RNC450
PD30 PD30 PD30 PD30

A2SU A2SU A2SU A2SU
RNBC
DMCU DMCU DMCU DMCU

DMCU DMCU DMCU DMCU
DMCU DMCU GTPU DMCU
GTPU GTPU GTPU GTPU
NIS1P 9 NIS1P / NIS1 8 NIS1P 5 NIS1P / NIS1 4
NIS1P 11 NIS1P / NIS1 10 NIS1P 7 NIS1P / NIS1 6
38
9 10 11 12 13 14 15 16 17 18 19
38
9 10 11 12 13 14 15 16 17 18 19
38
9 10 11 12 13 14 15 16 17 18 19
38
9 10 11 12 13 14 15 16 17 18 19

4
3
2
1
1
1
1
1
ICSU 8 ICSU 3 SFU 1 SFU 0

2
2
2
2
ICSU 9 ICSU 4
3
3
3
3
ICSU 10 ICSU 5 ICSU 1 ICSU 0

4
4
4
4
ICSU 11 ICSU 6 RSMU 1 RSMU 0

5
5
5
5
ICSU 12 EHU SWU 1 SWU 0

6
6
6
6
DMCU 13 DMCU 8 ICSU 2 OMS

7
7
7
7
DMCU 14 DMCU 9 DMCU 4 DMCU 0

8
8
8
8

PD30 PD30 PD30 PD30
RNAC

ICSU 13 ICSU 7 A: WDU 1 (OMU) A: WDU 0 (OMU)
NPS1(P)/ NPGE(P) 3 NPS1(P)/ NPGE(P) 2 B: HDD 1 (OMS) B: HDD 0 (OMS)
OMU 1 OMU 0
NPS1(P)/ NPGE(P) 5 NPS1(P)/ NPGE(P) 4 NPS1(P)/ NPGE(P) 1 NPS1(P)/ NPGE(P) 0
38
9 10 11 12 13 14 15 16 17 18 19
38
9 10 11 12 13 14 15 16 17 18 19
38
9 10 11 12 13 14 15 16 17 18 19
38
9 10 11 12 13 14 15 16 17 18 19
TBUF TBUF TBUF TBUF TSS3

TSS3 TBUF TBUF TSS3
4
3
2
1
1
1
1
1

2
2
2
2

3
3
3
3

4
4
4
4

5
5
5
5

6
6
6
6

step 1-3
7
7
7
7

8
8
8
8

RNC2600
PD30 PD30 PD30 PD30

RNBC


38
9 10 11 12 13 14 15 16 17 18 19
38
9 10 11 12 13 14 15 16 17 18 19
38
9 10 11 12 13 14 15 16 17 18 19
38
9 10 11 12 13 14 15 16 17 18 19

Flexi Multiradio
©2014 Nokia Solutions and Networks. All rights reserved.

step 1-7
mcRNC
NSN RAN Equipments, cont.
Basic new delivery configuration steps in RN6.0 are:
RNC2600 step 1
RNC2600 step 2
RNC2600 step 3
Feature upgrade configuration steps in RN5.0 are:

RNC196/48 or RNC196 step 1
RNC196/1000 or RNC196 step 8 (New in RN5.0)
RNC450/1000 or RNC450 step 4 (New in RN5.0)

Flexi Multiradio Variants
RU40
Flexi Multiradio 10 BTS

• GSM/EDGE/WCDMA/HSPA/
LTE/LTE-A SM
Flexi Multiradio BTS

• GSM/EDGE SM Everything in SW upgradeable
• WCDMA/HSPA/LTE BTS SM 2 Modules - Every technology
- Capacity
SW upgradeable
- WCDMA to LTE Indoor System
- Capacity Module
Outdoor System
Module
Capacity &
technology extension
sub-modules

Standalone OMS with mcRNC
• Standalone OMS can support several RNC NetAct
– RAN1784 is prerequisite for this feature
– there can exist max 10 RNCs controlled by one
standalone OMS
– mixed configuration of RNCs is supported
meaning that both cRNCs and mcRNCs can be Element Managers
controlled by one standalone OMS GUI interface OMS
– there are anyway some BTS and cell level
capacity limitations in OMS
 max 10 000 BTSs supported BTS
 max 30 000 cells supported O&M
 connection establishment initiated by RNC is OMU
rejected if above mentioned numbers are OMU
already exceeded in OMS
 OMS must be able to handle RNCs which are
in different SW level e.g. RN6.0 and RN6.0 EP OMU
(backward compatibility to RN5.0 release is not
supported)
• For operators shared OMS will bring savings
on maintenance and HW costs
BTSs
• Specification and implementation of this BTSs
feature is started already within mcRNC1.0. BTSs

RAN Equipment
• Introduction
• Operability
• IPA-RNC

BCN HW Architecture
“The box”

BCN HW Architecture
“The box”
Fans and power

supply units field
replaceable and hot
swappable
Add-in
cards
Optional air
filter

BCN HW Architecture
Cabinet installation
• 19” cabinet with max.

configuration
• 8 pcs of modules with cable
trays in front
• 2 pcs of PDU (either AC or DC)
modules on the top

Multi Controller RNC - mcRNC
• Multicontroller RNC inherits the existing IP transport features

– Multicontroller will support the same IP transport functions as classical RNC in
RU30EP2
– Transport function of both RNC types to be managed in the same way
• RNC architecture is completely based on IP
• Modular RNC architecture based on stacked nodes
– Network redundancy concept is always provided based on a pair of modules
– Single modules can be added for additional capacity in smartphone configuration
– RNC user plane capacity can be increased by adding a pair of modules
Single modules can be

added for smartphone Adding a pair of
capacity extension modules, additional
(redundant) network
connectivity
Each pair of modules provides extended
IP Network provides redundant user plane capacity
network connectivity
Capacity Capacity Capacity

Step 1 Step 2 Step 3

mcRNC HW Names and Abbreviations
Capacity step names used when BCN and processor type is indicated
Examples:
Supported in RU40 (mcRNC 3.0) :
Supported in RU30EP2
(mcRNC 2.0) :
S1-A1 S5-A1 S1-B2 S3-B2 S7-B2

2 BCN-A 6 BCN-A 2 BCN-B 4 BCN-B 8 BCN-B
modules, modules, modules, modules, modules,
Octeon+ Octeon+ OcteonII OcteonII OcteonII
processors processors processors processors processors
BCN module names: BCN-A, BCN-B
These BCN module names include

• motherboard, mechanics, power supplies, fans and air filter
• NOT any add-in cards
BCN-A
BCN-A
= current BCN module with
six 10GigE ports
BCN-B
BCN-B
= modified BCN module with
nine 10GigE ports

BCN module names used, if processor type needs to be shown
BCN-xy
| |_______ Octeon type:
| 1 = Octeon+ (BOC-A add-in card)
| 2 = OcteonII (BMPP2 add-in card)
|
|_________ BCN module type:
A = BCN-A
B = BCN-B

BCN HW Architecture
Processors
RU30 EP2
• Cavium Octeon+ CN5650
– 12 x MIPS64 cores. 2MB of L2 cache
– Replaces the dedicated processing architectures used in the past
▪ x86, TI DSP, PowerQuicc and APP network processors.
– Big-endian, which is different compared to x86 hardware
▪ Minor impact on the current control plane SW.
RU40
• Introduction of Cavium Octeon II CN68xx processors
– 32 x cnMIPS II cores, 4MB L2 cache, 4xDDR3 slots
– Approximately doubled performance in comparison to CN5650

RAN Equipment
• Introduction
• Operability
• IPA-RNC

mcRNC Functional Architecture
Logical View of BCN
SER
The Ethernet switch domain is USB
LMP
logically divided into two parts:
FD
MGT
VCMC
local
HD
LAN1 1 GigE HW Management
(Element management) 1000Base-T
PCIe
CSPU
CSPU
USPU
USPU
USPU
CFPU
CSPU
Oct 1
EIPU
HDU
PTU
CFPU
Oct 2
External Interfaces part of Ethernet switch

CSPU
Ethernet switch
HW Management.
Back-plain part of Ethernet switch
Oct 3
CSPU
• 10GigE
IPMB-L
Internal – for communication Network Oct 4
between the various Interfaces CSPU
processing units (USPUs, Oct 5
CSPUs and CFPUs) as well as USPU
for flexible connecting the 1GigE Oct 6
external network interfaces to Network
Interfaces
USPU
the processing units. Oct 7
USPU
• External - for external and
LAN2 1 GigE Oct 8
inter-module cabling (Four 10 (Element management) EIPU
GE and sixteen 1 GE 10GigE
HiGig
interfaces are provided). Back-Plane

Terminology
• Functional Unit
– A unit of execution and deployment that relates to a node in the cluster.
– Belongs to one of Control, User, Transport or Management planes.
– Equivalent to a “computer” in the traditional sense.
• Processing Unit ̶ add-in card

– A unit of deployment that spans one multi-core processor containing one or
more functional units.
– The functional units contained may belong to any of the planes but are
grouped together to ease processing and communication.
• Interface card / Transport card

– An add-in card containing one or more processing units used to process
network interface related functions and transport layer services.
• BCN module
– 1 Box Controller Node hardware containing 8 add-in cards.

Block Diagram of mcRNC
Main processing units of the

RNC are listed below -
• CFPU - Centralized
Functions Processing Unit
• CSPU - Cell-Specific
Processing Unit
• USPU - UE-Specific
Processing Unit
• EIPU - External Interface
Processing Unit
• Ethernet Switches

Block Diagram of mcRNC
The functions are distributed in entities of hardware and software. The main
functional units of the RNC are listed below.
CFPU Centralized Functions Processing Unit
CSPU Cell-Specific Processing Unit
USPU UE-Specific Processing Unit
Ethernet switches
The distributed processing architecture of the mcRNC is implemented by a

multiprocessor system, where the data processing capacity is divided among
several processors.
Based on the application need several general purpose processing units with
appropriate redundancy principle can be assigned to different tasks.
In general, processing capacity can even be increased later on by distributing the
functionality of the network element to multiple modules, and by upgrading
processors with more powerful variants

Functional Units
RNC can be thought to comprise of 4 planes:
• Control Plane, User Plane, Transport Plane and Management Plane.
User and Control Plane Functional Units

• CSCP – Cell Specific functions and services in Control Plane
• USCP – UE Specific functions and services in Control Plane
• CFCP – Centralized Functions and services in Control Plane
• CSUP – Cell Specific functions and services in User Plane
• USUP - UE Specific functions and services in User Plane. This includes
the dedicated and shared channel services since they are relevant for a
UE.
Transport Plane Functional Units

• SITP – Signalling Transport Plane
• EITP – External Interface functions in Transport Plane
Management Plane Functional Units

• OMU – Operation and Maintenance Unit for Management Plane
CSPU
Cell Specific Processing Unit
CSPU
CSPU
USPU
USPU
CFPU
CSPU
Function
EIPU
EIPU
• Co-located user and control
planes for Cell specific services
•CSUP
• Handles common channels
and BTSs
• Resources for a BTS allocated
from the same unit.
• CSCP
• Handles NBAP, RRC-c and
RRC-s
• Admission control, load control
and packet scheduler
• Redundancy: N+M among all
CSPUs within mcRNC

CSPU
Cell Specific Processing Unit, cont.
Cell-Specific Processing Unit (CSPU) - This processing unit implements

all cell-specific control and user plane processing. All control and user
plane resources for a single BTS are allocated from the same CSPU unit.
Allocation of BTSs under control of specific CSPUs is controlled by OMU.
The same functionality in OMU allows also graceful reallocation of BTSs
one-by-one from one CSPU under control of different CSPUs. This feature
provides quite seamless shutdown and replacement of one mcRNC
hardware unit.

USPU
UE Specific Processing Unit
CSPU
CSPU
USPU
USPU
CFPU
CSPU
EIPU
EIPU
•Function
•Co-located user and control
planes for UE specific services
•USUP
• Handles DCH, HS-DSCH
and E-DCH channels
• Hosts RTP,RTCP
• USCP
• Handles connection oriented
protocols
• Localized User plane
resource manager
• Redundancy: SN+ (load shared)

CFPU
Centralized Functions Processing Unit
• Function
CSPU
CSPU
USPU
USPU
CFPU
CSPU
EIPU
EIPU
• Hosts critical services
• OMU
• Basic system maintenance functions
• CM, FM, PM, HW and SW
management
• Hosts RNW Database
• Plan management
• CFCP
• LCS services, Iu-PC, SABP
• Centralized information maintenance
• Connectionless protocols including
paging
• Redundancy : 2N

CFPU
Centralized Functions Processing Unit, cont.
Centralized Functions Processing Unit (CFPU) - The CFPU consists of

Operation and Management Unit (OMU) and Centralized Functions for Control
Plane (CFCP). OMU performs the basic system maintenance functions such as
hardware configuration, alarm system, configuration of signaling transport and
centralized recovery functions. It also contains cellular network related functions
such as radio network configuration management, radio network recovery and
RNW database.
It also takes care of accounting of simultaneous on-going location related
procedures in the whole network element. The communication between OMU in
CFPU and OMS/NetAct happens through dedicated Ethernet interface.
Redundancy – 2N

EIPU
External Interface Processing Unit
• Function
CSPU
CSPU
USPU
USPU
CFPU
CSPU
EIPU
EIPU
– Handles incoming packets
• SITP
• Hosts the SIGTRAN stack and
SCCP user level distribution block
• EITP
• Hosts IP/IPSec/UDP and GTPu
stack and GTPu level distribution
• Provides QoS control, traffic
shaping and scheduling functions
Redundancy : 1+1

EIPU Capability Overview
– User plane transport layer termination

 Supports Iub, Iur, Iu-PS and Iu-CS at the same
time
 Up to 64 + 64 IP addresses supported for Iub
and Iu/Iur (per RNC)

– Iu/Iur control plane transport layer

termination
 SCTP multi-homing supported via multiple
network interfaces
 Up to 32 SCTP associations per signalling
link supported
 Up to 256 IP addresses supported per RNC

– Implements network interfaces

 External network interfaces (SFP7 - SFP22)
 Internal network interfaces (SFP+1 –
SFP+6) for RNC internal messaging and
redundancy

– Iub control plane transport layer

termination
 Up to 10 Iub signalling subnets supported
(per RNC), allowing different Iub transport
configurations
 Up to 64 IP addresses supported (per RNC)

External Physical Interfaces
• Network interfaces provide external interfaces and the means to execute

physical layer and transport layer functions, such as policing, statistics,
OAM, buffer management and scheduling.
• Any interface can be configured to be used as an Iu, Iub, or Iur interface.
• In addition to the network interfaces, local area network (LAN) interfaces

as well as debugging and maintenance interfaces are provided in front of
the module.
• Synchronization interface for receiving a reference clock can be used, if

required.

External Physical Interfaces BCN-A
• The controller module front panel, shown in next slide, contains the
following interfaces:
• 6x 10/1 GigE (SFP+ or SFP) interfaces for external cabling and inter-node cabling
• 16x 1 GigE (SFP) interfaces for external cabling
• 2 additional 1 GigE (SFP) interfaces providing access to add-in card slots 1 and 8 for
network element management purposes
• 1x 1 GigE (1000Base-T) interface for local hardware management and debugging
purposes
• 2x USB 2.0 interfaces for software downloading (typically during commissioning)
• direct RS232 interface to the local management processor (LMP) for debugging
purposes
• USB 2.0 slave port for software debugging purposes
• connector for hard disk cross-connecting
• 2x RJ 45 connectors for eight external voltage-sensitive alarm inputs (with 1 mA pull-up
load)
• 2x external synchronization (2.048 MHz/E1 or 1.544 MHz/T1/J1) interfaces

External Physical Interfaces – BCN-A
2x USB
1x RJ-45 (SW download)
(HW maintenance)
2 4 6 8 10 12 14 16 18 20 22
1 3 5 7 9 11 13 15 17 19 21
2x RJ-45
Debugging SFP 2x RJ-45 (ext. alarm input)
interfaces 6x SFP+ 16x SFP (EM, (unused)
(BCN interconnect) (UTRAN interfaces) DCN)
Iu, Iur, Iub interfaces: 16x 1000BASE-T/SX/LX, SFP (RJ-45 or LC-type)

O&M connectivity: 1x 1000BASE-T/SX/LX, SFP (RJ-45 or LC-type)
– 2nd SFP reservered for future use
Local HW maintenance: 1x 1000BASE-T, RJ-45
– This interface must not be connected to network (allows low level hardware debugging)!
RNC internal backplane: 6x 10GBASE-SR/LR, SFP+ (LC-type connector)

External Physical Interfaces – BCN-A, cont.
1.4U high
Easier Temperature management. AMC extension slots possible.
2.Number and grouping of external interfaces

6x10GE ports in one group. Used as external 1/10GE ports or as
interconnection ports between nodes.
16x1GE ports in one group. Used as external 1GE ports
3.No dedicated 1GE port for network management.
4.AMC bays in vertical position.

mcRNC External Physical Connectivity
Recommended site solution incl. backplane connectivity – capacity
step1

mcRNC External Physical Connectivity
Recommended site solution incl. backplane connectivity – capacity
step5

RAN Equipment
• Introduction
• Operability
• IPA-RNC

Scalability
• Scalability in multiple dimensions
▪ Throughput
▪ Supported number of WBTS
▪ Transport connectivity
▪ Supported number of users
– Flexibility in configuring and optimizing the system in any dimension
• Possibility to stack more BCN modules without breaking the system
– BCN modules can be of varying processing capacities
– Newer processors providing higher processing capacity can be added
▪ Over-provisioned internal backplane
• Less centralized processing and shared resources improves scalability
• Load balancing and multiple distribution points in design
– Incoming connections are distributed evenly
– Multiple points of distribution provide pipelined execution
▪ Avoids pressure points

Overload Protection
• Ensure graceful degradation in overload mode

– Platform, Middleware and application specific overload control
mechanisms
– Predictable behavior under sustained load ensured by load shared
processing units and distribution schemes
▪ Round-robin used in many distribution algorithms
▪ Units in overload mode above higher threshold removed from participation
list
▪ Inclusion in the participation list on coming below lower threshold
▪ Distribution entity does not maintain the list of participants
• List of eligible participants provided by different load monitors / managers
– Support for controlled switchover
– Access control at the earliest point
▪ Closer to boundary dropping of requests, when needed
• Avoids wast of internal resources when under load

Traffic Data Flows
• The EITP and SITP units in EIPUs send data to and receive data from the
Iub, Iu and Iur interfaces.
• All transport and network layer related functionality related to Iub, Iu and
Iur interfaces is performed in the EIPU units.
• One EITP unit of EIPU can send data to and receive data from multiple
CN elements or neighboring RNCs.
• The data from one CN element or neighbouring RNC can be received by
the EITP unit of any EIPU.
• The centralized scheduling for Iu, Iur and Iub interface happens in the
EITP.
• The scheduling can be simpler for Iu/Iur than Iub.
• One EITP unit can send to and receive data from many BTSs.
• One BTS sends data to and receives data from one EITP unit .

mcRNC Traffic Flows
SRB setup on DCH Data Path
IPA NPGE SFU MXU DMCU MXU SFU MXU ICSU
mcRNC Eth Switch EIPU USPU

mcRNC Traffic Flows
SRB setup on FACH Data Path
IPA NPGE SFU MXU DMCU MXU SFU MXU ICSU
mcRNC Eth Switch EIPU CSPU USPU

mcRNC Traffic Flows
CS Call on DCH Data Path
DMCU
IPA NPGE SFU MXU
DSP
MXU SFU NPGE
mcRNC Eth Switch EIPU USPU EIPU Eth Switch

mcRNC Traffic Flows
PS call setup on DCH Data Path
DMPG
IPA NPGE SFU MXU
DSP
MXU SFU MXU NPGE

mcRNC Traffic Flows
PS setup on FACH/RACH data path
DMCU DMCU
IPA NPGE SFU MXU
DSP
MXU SFU MXU
DSP
MXU SFU NPGE
mcRNC Eth Switch EIPU CSPU USPU EIPU Eth Switch
• The Iu resource is same as the PS on DCH, just without the Iub resource setup which already done when
common channel setup.
• The Iu and Iub connect is done by application itself.
mcRNC Traffic Flows
PS on HSPA data path
DMPG
IPA NPGE SFU MXU
DSP
MXU SFU MXU NPGE
• The Iu resource is same as the PS on DCH, just there are two Iub resources dedicated
for uplink and downlink.
• From call management point of view, 2 Iub leg are some especially the MAC protocol are
different and the handover concept is different.
mcRNC Traffic Flows
Soft handover intra-RNC
DMPG
IPA NPGE SFU MXU
DSP
MXU SFU MXU NPGE

mcRNC Resource Management
Decoupled layers and services
• Transport layer decoupled from the Radio Layer

– Resourced from different cards
– Enables flexible and independent adaptation of Transport
requirements
– Enables application of 1+1 redundancy for TNL
• Cell services and UE services in RNL decoupled
– Resourced from different cards
– Enables specific addressing of CSPU redundancy (N+M)
• Control Plane and User Plane in RNL co-located
– Resourced from the same card
– Enables flexible resource allocation between CP and UP
– Enables local resource management for UP resources

Capacity allocation
• RNC can be viewed as a pool of processing resources
– Coordinated capacity allocation from the pool for various services
• Capacity allocation among Processing Units
– Based on Traffic profile
▪ No. of CSPUs : Depends on the number of WBTSs to be handled
▪ No. of USPUs : Depends on the number of UEs to be handled
▪ No. of EIPUs : Depends on the traffic capacity and needed services
• QoS, IPSec
– Statically allocated at commissioning time
– Modification possible
▪ Manual, through service personnel only
▪ Requires restart of units that have to change role
• Provided as inputs to RDT

• Balancing of units shall take these as high level inputs
• Actual number of units will vary based on balancing
Capacity allocation
• Capacity allocation within Processing Unit

– Resource sharing between co-located CP and UP
– Based on the needs of traffic profile
– Different for CSPU and USPU
– Statically configured at commissioning time
– Modification possible
▪ Manual, through service personnel only
▪ Requires restart of the system.
– Automatic resource optimization under study

What does it mean ?
Different layers: Different Planes:

- Transport Network Layer - Transport Plane
- Radio Layer 2 - User Plane
- Radio Layer 3 - Control Plane
Different principles: Different Service groups:

- Static allocation - Cell-specific services
- Round Robin - UE-specific services
- Weighted Round Robin
- …

Load balancing and distribution in Transport Network Layer
1.1 SCTP association set is held between RNC and each CN element
• Each SCTP association binds to a certain CP service IP address (preferably on
different EIPU units)
• For a new request , the SCTP association is selected based on policy (e.g. Round
Robin)
2 The distribution of the Iu (and Iur) signaling
2.
messages to the application protocol handlers 2
(RANAP and RNSAP) in service cards is handled
1
by SITP (at SCCP level)
• connectionless messages and connection oriented
messages that do not have a local reference allocated
-> distributed to the least loaded service card.
• connection oriented messages (UE specific) having
a valid local reference->forwarded to the relevant service card

• The USUP unit that handles a certain traffic flow to a UE is determined by the
RNC.
• The EITP to be used for the traffic flow is selected by the TRM
• The address of the User Plane entity that shall handle the traffic is provided to the
EITP.

mcRNC Resource Management, cont.
1. The User Plane addresses used in the RNC are signaled and hence the USUP
unit that handles a certain traffic flow to a UE is determined by the RNC. During
the assignment of resources for user plane traffic, the EITP to be used for the
traffic flow is selected by the transport resource manager and resources are
reserved to handle the Iu connection. The address of the User Plane entity that
shall handle the traffic is provided to the EITP. The GTP TEID is mapped to the
FaStDist address (DMX in mcRNC1.0) of the UP entity.
1. It is worth noting here that the IP and SCTP layers are terminated in the SITP
and the UDP in the EITP in the interface card. The SCCP user adaptor
(SAGPRO) communicates with the signalling application protocol programs
(RANAP and RNSAP) using the internal DMX based messaging network. The
Traffic Forwarder (TRF) communicates with the user plane entities using the
FaStDist protocol.

• No dynamic load balancing for NBAP signalling messages.

• The CSCP units to handle BTS and cells are selected using a policy e.g.round
robin as part of RNW plan download and configuration in RNC.
• The NBAP load distributor in SITP only dispatches the signaling messages based
on IP/SCTP level information.
The centralized dispatching only serves to help in applying principles of availability

and redundancy without affecting the BTSs involved, when possible.
• EITP to be used for the Iub traffic flow is selected by the TRM
• The address of the User Plane entity that shall handle the traffic is provided to
both the EITP.
• The IP address and UDP port in EITP is mapped to the FaStDist address of the
user plane for the purpose of forwarding.

mcRNC Resource Management, cont.
During the assignment of resources for user plane traffic, the EITP to be
used for the Iub traffic flow is selected by the transport resource manager
and resources are reserved to handle the Iub connection. The address of the
User Plane entity that shall handle the traffic is provided to both the EITP.
The IP address and UDP port in EITP is mapped to the FaStDist address of
the user plane for the purpose of forwarding.
The centralized dispatching only serves to help in applying principles of

availability and redundancy without affecting the BTSs involved, when
possible.

Cell Services and UE Services - overview
• Assignment of WBTS to CSPUs from Centralized unit at runtime

• Round robin used, provision for load based optimization
• Common channels for WBTS handled in the same CSPU
• CP – UP co-location enables local resource management
• Assignment of a call to the USPUs from CSPUs

• Round robin used
• Any USPU can handle calls from any WBTS
• UP resources for the call handled in the same board
• CP – UP co-location enables local resource management
• Eligible set of USPUs determined based on load
• Data pushed to the CSPUs from centralized resource manager

Cell Services – CSPU selection
• A BTS object is added to the RNW DB

• The BTS handler chooses the next available CSCP by round robin
– The eligible list is maintained based on existing load
– A unit in overload mode can ask to be made ineligible
• The CSCP uses its own CSUP in same processor for user plane
resources
– All resources needed for a BTS provided from the same processing unit
• The Transport Resource Manager selects an EIPU
– Configures it with the address and port information for the newly added BTS
and the address of the selected CSCP
– The distribution table in EIPU is updated.

UE Services - Definitions
All Cell Specific User Bearers (SRB / RAB) of particular type are
located into a designated Processing Unit (not Cell Services)
A Processing Unit, where HSPA RAB services (concentration of
Bearers of certain cell) are allocated
A Processing Unit, where HS CELL FACH Cell Services are
allocated
A Processing Unit, where SRB of the particular UE is located (It is
preferred to keep the Bearers of a UE in its UE-Home PU - in order
to avoid cross PU signalling specific to the UE.
User Bearer of a particular type allocated in the Cell-Home
User Bearer of a particular type allocated in the non Cell-Home PU

UE Services – USPU selection
• Processing resource allocation for UE services – dynamic allocation,

• A call from a UE attached to any cell can be handled in any of the USPUs.
• Different policies defined for the distribution of SRBs and data bearers to USPUs:
• When the SRB for a UE needs to be allocated, the least loaded USPU – in terms of
both CP and UP load – is selected and the CP and UP resources are co-located in the
unit. This USPU is referred to as the UE home.
• When a radio bearer needs to be assigned for a UE in CELL_DCH state, resource
allocation from UE home is checked and if not available, another unit with a lower unit
load is selected.
• When the UEs use shared channels, it is beneficial to allocate resources for them in the
same functional unit, so that common limits and constraints can be enforced with ease.
This results in the definition of a Cell Home –the USUP unit that handles the HS bearers
for the UEs in a given cell.

UE Services - UE-home and Cell-Home concept
Cell-Home for HS Cell-

FACH service of C3 Cell-Home for
HSDPA RABs
Cell-Home for of C3
HSDPA RABs
of C1 and C2 PUs
Cells
UEs
Cell 1 (C1) – Capable of handling DCH + HSDPA RABs

Cell 2 (C2) – Capable of handling DCH + HSPA RABs
Cell 3 (C3) – Capable of handling HS Cell-FACH Service + DCH + HSDPA RABs

UE-home and Cell-Home concept
Cell-Home for HS Cell-

FACH service of C3 Cell-Home for
HSDPA RABs
Cell-Home for of C3
HSDPA RABs
of C1 and C2 PUs
Cells
UEs
Connected to C1, having HSDPA Connected to C2, having HSDPA Connected to C3, having HS Cell-
RAB resource in USPU1 – Native RAB resource in USPU3 – Visitor FACH SL in USPU2 – Native
Bearer for USPU1 Bearer for USPU3 Bearer for USPU2

Deployment of resource managers
• Local resource management (LRM) for UP resources (USPU/CSPU)
– mediates the allocation of resources in the USUP
– When resources are not available in the local USUP, the LRM contacts the CRM to get
an alternate USUP for allocating the resources
– Per-call resources managed locally in the USPUs
▪ No need to use centralized resource manager for each call
• Centralized resource management (CRM) for exceptions (in CFPU)

– Used in overload, fault situations etc.
– Distributes the load information of USPUs to the CSCP which then, makes use of the
data in selecting the USPU unit
– When receives an indication from LRM about resource unavailability, selects alternate
handler for that call
▪ Board removed from the eligible list
▪ CS services don’t assign further calls to the “overloaded” board
▪ Board added to the eligible list once load is below lower threshold
LRM
Fast decisions on resource allocation
Service pools
No. Pool PU U-Plane Services Managed Resources
1 CCH (“C”) CSPU Rel 99 cell Rel 99 cell specific:

services •RLC/MAC-c
• RACH/FACH/BCCH/PCH
2 Non-CCH USPU User- specific User Specific:

(“nC”) services • RLC/OLPC/ Cipher
HS cell services • MAC-d/-HS/-es/-is
• MDC
• FP DCH/HS-DSCH/E-DCH
HS Cell Specific:
• MAC-c/-sh
• FP E-DCH/HS-DSCH
The U-Plane Services shall be grouped into Two Statically separated Pools as
Non-CCH pool in USPU
No. Pool Subsections Allocation

1 Non-CCH DCH (SRB,AMR, Rel99) GBR service - X% allocation for
(“nC”) HSCF (HS Cell_FACH) DCH, nGBR HSCF Cell/RAB
Services- Deterministic services
HSPA (HSDPA, HSUPA) nGBR service - HS - Y% allocation
for services – Non-deterministic
Services
Excess reservation 0%
The non-CCH pool can be further logically divided into sub-pools for the different USUP
Services offered.
The allocations above are used by the Resource Manager to make the decisions such
as UP Admission Control and Service Prioritization in order to balance the load on different
Pus.

mcRNC resource management
Admission control
• Local resource management (LRM) functionality in USCP/CSCP performs user

plane admission control functionalities with different policies for:
• Deterministic Services (DS) or Guaranteed Bit Rate Service (GBRS), for which the cost
of a U-Plane Service can be can be evaluated up-front at the service admission;
• managed by Capacity Counter mechanism
• LRM monitors the Fill Level of the services with deterministic Load against the X% Limit
• When a Deterministic Service is admitted, LRM shall increment the appropriate Traffic Mix
Counter – till the Limit X% is reached
• If the X% is reached, the LRM shall not admit the call by itself, but escalate it to the CRM. CRM
shall try to find a Processing Unit with deterministic Load less than the X% Limit
• non-Deterministic Services (nDS) - The Best Effort class services and the HSPA
services with various range of QoS during the call that cannot be modeled as the
deterministic services.
• Admission is dynamically evaluated by measuring the PU Load to provide the Best Effort
Service.

cRNC vs mcRNC - comparison
C-plane functionalities reside on ICSU and C-plane functionalities are divided on the
RSMU functional unit. basis of cell specific and UE specific
functionalities and reside on different
functional units (CSCP/USCP)
Centralized CP functionalities reside on Centralized CP functionalities reside on
RSMU CFPU
· C-plane FU and U-plane FU are deployed C-plane and U-plane Fus are deployed on
on different Processing units same processing unit:
(ICSU/DMCU) • CSCP and CSUP FUs on CSPU PU
· • USCP and USUP FUs on USPU PU

RAN Equipment
• Introduction
• Operability
• IPA-RNC

Transmission and Transport Features in mcRNC
• Integrated transmission interfaces for IP over Ethernet

• Ethernet VLAN support
• Full 3GPP QoS support
• Integrated IPSec functionality (future option)
• ATM not supported

IP Interface Hierarchy
• mcRNC Ethernet interfaces provide L2 and L3 functionalities and

addressing for external packet network links configuration.
• Link Aggregation Group (LAG), VLAN, IP Addressing, Routing Protocols.
• Up to 10 IP addresses can be configured to Ethernet interfaces (ports).
• Alternatively, Ethernet interfaces can be assigned to a Link Aggregation
Group (future option) or they can be used to host VLAN interfaces.

Fragmentation and Reassembly
• IP fragmentation and reassembly is supported by mcRNC,

also in case fragments are received in wrong order.
• IP fragmentation and reassembly is applied when the
Ethernet frame payload size exceeds the configured MTU of
the network interface
• User plane, Control plane and management plane traffic supported
• In case the IP reassembly fails the partial elements of the
frame shall be discarded and shall not be forwarded to the
user plane.
Fragment 1
IP Payload Fragment 2, offset xx
IP Payload
IP Payload

Fragmentation and Logical Interfaces
• Iub/Iur
• At the Iub DL direction the 1500 bytes MTU is not exceeded with NSN
NEs and the DL IP layer fragmentation can be avoided.
• DL direction HS-DSCH frame size is limited at User plane.
• The Jumbo frames are not supported by the BTS and thereby not to
be used over the Iub.
• For CP, if needed it's handled at SCTP layer.
• Iu-PS
• For Iu-PS, the maximum T-PDU size over GTP tunnels is 1500 bytes,
thus maximum IP frame size including overhead is 1560 Bytes.
• As general recommendation we could use 1600 Bytes for MTU in case
Jumbo frames are supported
• Iu-CS
• For Iu-CS maximum RAB size is 84 Bytes, then fragmentation is never
required since maximum packet size is 124 Bytes.
VLAN Configuration
• mcRNC allows separation of

traffic and interfaces using VLAN configuration for mcRNC 1.0
VLANs
• For example
• Iu CS UP + Iu PS UP + Iur UP +
Iu CP + Iub
• Iu CS UP + Iu PS UP + Iur UP +
Iu CS CP + Iu PS CP + Iur CP +
Iub
• Ethernet interfaces or LAG
can be configured to support
none, single or multiple
VLANs.
• VLANs are identified by
VLAN-tag in Ethernet frame.
• VLAN Priorities are
supported only if VLAN tag is
used.
Routing
• mcRNC integrates into RU10 RNC IP site solution

– Same pair of Cisco routers
– Same IOS SW version
– Same line cards can be used
– Same ToP master solution

RAN Equipment
• Introduction
• Operability
• IPA-RNC

mcRNC Protection
Introduction
• In mcRNC protection against failures is provided by logical
functional units redundancy.
• Then compared to RNC-2600 there’s no hardware protection

with hot-standby mechanism, except for some hw units as
hard disk, power supplies and fans.
• Using this Functional Unit (FU) protection approach, it’s

possible to manage single points of failures, without impacts
on the service, with the appropriate traffic engineering.

Protection Mechanisms
Depending on the Functional Unit (FU) type, specific protection

schemes are supported:
• FUs in CFPU: 2N protection mechanism in cold-stanby mode for OMU

and CFCP.
• FUs in CSPU: N+M protection mechanism, then M protecting FUs for N

working FUs with M>=1. This is applied to CSCP.
• FUs in USPU: SN+ protection mechanism, then load sharing between

USUP units.
• FUs in EIPU: 2N protection mechanism, then if an EIPU fails it is

protected by another working one.

Recovery Group and Recovery Unit
Resiliency and high availability is achieved with following concepts:

• Recovery Unit (RU) – Functional Unit participating in the protection
group.
• Recovery Group (RG) – Containing Active and Protecting RUs.
RG types configurable in mcRNC are :

• QNUP – which can terminate User Plane connections of both Iub and Iu.
• QNIUB – which can terminate Control Plane connection for Iub only (Iu
Control Plane protection is managed with SCTP Multihoming which
terminates directly in EIPU).
• QNOMU – which terminates O&M connections and is bound to CFPU
nodes.
• QNCFCP – which terminates Service Area Broadcast service and is also
bounded to CFPU.

Recovery Units and Groups
CFPU-0 LAN1
Standby
EIPU-3
Active
SFP18
SFP17
Site routers
b.b.b.b/32 • Example configuration
EIPU-1 for QNUP for
Standby
Active
SFP14
terminating Iu and Iub
BCN-2
SFP13
user plane connections:
• There is QNUP-1,
CFPU-0 LAN1 QNUP-2, QNUP-3 and
QNUP-4
Standby
EIPU-2
Active
SFP18 • One QNUP per EIPU

SFP17
EIPU-0
Standby
Active
SFP14
BCN-1
SFP13
Recovery group Recovery unit

mcRNC Services Protection
Module 2
EIPU-3
• Egress: Traffic
Application
10.0.0.30/30 (SFP18) generated in the
IP#2
ACT
10.0.0.14/30 (SFP17)
EIPUs is forwarded
10.0.0.29/30 with ECMP routing to
10.0.0.25/30
both connected site
EIPU-1 routers
Application
IP#1
10.0.0.26/30 (SFP14) 10.0.0.21/30
• Ingress: Incoming
St-By 10.0.0.10/30 (SFP13) 10.0.0.17/30 traffic from one
router can access
the service
Module 1
termination on both
EIPU-2 10.0.0.13/30
10.0.0.9/30
BCN modules.
Application
IP#2
10.0.0.22/30 (SFP18) • Primary route points
St-By
10.0.0.6/30 (SFP17) to the EIPU that is
10.0.0.5/30 primarily running the
EIPU-0
10.0.0.1/30 service.
Application
10.0.0.18/30 (SFP14)
IP#1
ACT
10.0.0.2/30 (SFP13) Recovery Group (RG)
Active / Standby Recovery Unit

(RU), Application IP termination

mcRNC External Links Protection mechanism
• Protection of the mcRNC's external network connectivity is a

very crucial aspect for the customer, as a failure of e.g. a
single Iu link may bring the whole RAN area down, resulting
in huge loss of revenues and bad service experience.
• Different protection mechanisms are available in mcRNC for

external connectivity:
– EIPU protection
– Ethernet Link protection
– SCTP multihoming
• It is expected that the protection mechanisms would work

similarly compared to NPGE switchover, maintaining calls.

mcRNC External Links Protection mechanism,
cont.
Several means shall be implemented to protect the network access. Mainly
the following failure cases are covered:
Failure of certain SW or HW functionality in mcRNC (can be a single SW
process, but also a complete BCN),
Failure of an Ethernet link
Failure of an mcRNC site router
Failures in the transport network
Packet forwarding failures between mcRNC and the transport network
(transport link between mcRNC and network physically operational, but still
(e.g. due to router malfunction) packets are not forwarded -> traffic
blackholing)

Basic IP Layer Routing in mcRNC
EIPU-3
Application
IP#2
ACT
10.0.0.30/30 (SFP18) • Traffic is forwarded to
10.1.0.1 /28 10.0.0.14/30 (SFP17) Application address using
BCN#2
10.0.0.29/30
10.0.0.25/30
Primary routes
EIPU-1 • In case of failure,
Application Secondary routes are
10.0.0.26/30 (SFP14)
IP#1 10.0.0.21/30
available as backup
10GE Backplane
St-By
10.0.0.10/30 (SFP13) 10.0.0.17/30
10.0.0.1 /28
pointing to Stand By
Application address.
EIPU-2 10.0.0.13/30
Application 10.0.0.9/30
Primary Route
IP#2 10.0.0.22/30 (SFP18)
St-By (from Switch-1)
10.1.0.1 /28 10.0.0.6/30 (SFP17) BackupRoute
(from Switch-1)
BCN#1
10.0.0.5/30
Secondary Route
10.0.0.1/30 (from Switch-2)
EIPU-0 BackupRoute
(from Switch-2)
Application
IP#1 10.0.0.18/30 (SFP14)
ACT
10.0.0.1 /28 10.0.0.2/30 (SFP13)

EIPU Protection in mcRNC
EIPU-3
Application
IP#2
ACT
10.0.0.30/30 (SFP18) • Applications affected
10.1.0.1 /28 10.0.0.14/30 (SFP17) by the failure are
BCN#2
10.0.0.29/30
10.0.0.25/30
moved to a redundant
unit
EIPU-1
Application • Traffic flow continues
10.0.0.26/30 (SFP14)
IP#1 10.0.0.21/30
there based on
10GE Backplane
St-By
10.0.0.10/30 (SFP13) 10.0.0.17/30
10.0.0.1 /28
existing routing
definitions
EIPU-2
• No dynamic changes
10.0.0.13/30
10.0.0.9/30
are required.
Application
IP#2 10.0.0.22/30 (SFP18)
St-By
10.1.0.1 /28 10.0.0.6/30 (SFP17) Primary Route
(from Switch-1)
BCN#1
10.0.0.5/30 BackupRoute
10.0.0.1/30 (from Switch-1)
EIPU-0 Secondary Route
(from Switch-2)
Application BackupRoute
IP#1 10.0.0.18/30 (SFP14)
(from Switch-2)
ACT
10.0.0.1 /28 10.0.0.2/30 (SFP13)

EIPU Protection in mcRNC, cont.
1. mcRNC internal failures
In case of SW or HW related failures in mcRNC, sufficient redundancy needs

to be provided by the system, e.g. by relocating affected services to other
(non-affected) parts of the system.
Obviously, mcRNC internal protective mechanisms should not have an impact
on the external network connectivity - in fact the transport network should not
even notice such events. Consequently, a fundamental requirement of the
network connectivity solution is that each protected service in the mcRNC
(regardless of the module that it is physically running in) is able to use the
network via redundant interfaces. Furthermore, in case a protective action
(e.g. a switchover to a redundant processor) is really performed, impacts on
the transport network shall be minimized. Applications affected by the failure
are moved to a redundant unit, traffic flow continues there based on existing
routing definitions - no dynamic changes are required.

EIPU Application Failure in mcRNC
EIPU-3
Application
IP#2 10.0.0.30/30 (SFP18)
• The scenario looks
ACT
10.1.0.1 /28 10.0.0.14/30 (SFP17)
slightly different in
BCN#2
10.0.0.29/30
10.0.0.25/30
case just a single
EIPU-1
application fails
Application
within one EIPU
IP#1 10.0.0.26/30 (SFP14) 10.0.0.21/30
10GE Backplane
St-By
10.0.0.1 /28 10.0.0.10/30 (SFP13) 10.0.0.17/30 • All applications tied
to e.g. QNUP-0
would be moved
EIPU-2 10.0.0.13/30
10.0.0.9/30
– E.g. Iub, Iu-PS, Iu-CS
Application
IP#2 10.0.0.22/30 (SFP18)
St-By
(from Switch-1)
BCN#1
10.0.0.5/30
BackupRoute
10.0.0.1/30 (from Switch-1)
(from Switch-2)
Application
IP#1 10.0.0.18/30 (SFP14) BackupRoute
ACT (from Switch-2)
10.0.0.1 /28 10.0.0.2/30 (SFP13)

EIPU Application Failure in mcRNC, cont.
In this case, traffic will still be forwarded from site switches towards
EIPU #1 - but it needs to be forwarded internally as the application
was moved to the redundant unit. In RNC egress direction existing
route definitions in EIPU #1 are used.
This could be e.g. some SW crash. FlexiPlatform High Availability

system has some means to detect such failures.
Ethernet Link Protection
• mcRNC provides the following mechanisms to supervise

Ethernet link status:
– Physical link status, i.e. physical carrier status (e.g. "lights on" in
optical case),
– Remote fault status indication (i.e. link status bit as defined in
IEEE802.3-2005 clause 28 and clause 37)
• In RU30 RAN2254 “Ethernet Link OAM in RNC” is

introduced, which can be used for ethernet link faults
discovery based on IEEE802.3 clause 57.
• It WILL also possible to use Link Aggregation Group

functionality (IEEE802.3ad) grouping up to 8 ethernet ports.
Ethernet link protection in mcRNC
EIPU-3
Application
IP#2
ACT
10.0.0.30/30 (SFP18)
• In case of a
10.1.0.1 /28 10.0.0.14/30 (SFP17)
recognized failure,
BCN#2
10.0.0.29/30
10.0.0.25/30 mcRNC provides
EIPU-1 routing of the
Application
affected traffic via
IP#1 10.0.0.26/30 (SFP14) 10.0.0.21/30 redundant IP
10GE Backplane
St-By
10.0.0.1 /28 10.0.0.10/30 (SFP13) 10.0.0.17/30
routes.
EIPU-2 10.0.0.13/30
Application 10.0.0.9/30 Primary Route

IP#2 10.0.0.22/30 (SFP18) (from Switch-1)
St-By
10.1.0.1 /28 10.0.0.6/30 (SFP17) BackupRoute
(from Switch-1)
BCN#1
10.0.0.5/30 Secondary Route

10.0.0.1/30 (from Switch-2)
EIPU-0 BackupRoute
(from Switch-2)
Application
IP#1 10.0.0.18/30 (SFP14)
ACT
10.0.0.1 /28 10.0.0.2/30 (SFP13)
Ethernet link protection in mcRNC, cont.
if first gateway becomes unavailable (e.g. total loss of

connectivity for the IP interface or lack of external routes
induced by dynamic routing protocol - OSPF), mcRNC will
route affected traffic via the other interface
mcRNC Site Router redundancy
EIPU-3
Application
IP#2
ACT
10.0.0.30/30 (SFP18)
• In case of a
10.1.0.1 /28 10.0.0.14/30 (SFP17)
recognized failure,
BCN#2
10.0.0.29/30
10.0.0.25/30 mcRNC provides
EIPU-1 routing of the
Application
affected traffic via
IP#1 10.0.0.26/30 (SFP14) 10.0.0.21/30 redundant IP
10GE Backplane
St-By
10.0.0.1 /28 10.0.0.10/30 (SFP13) 10.0.0.17/30
routes.
EIPU-2 10.0.0.13/30
Application 10.0.0.9/30
IP#2 10.0.0.22/30 (SFP18)
St-By
(from Switch-1)
BCN#1
10.0.0.5/30 BackupRoute
10.0.0.1/30 (from Switch-1)
(from Switch-2)
Application BackupRoute
IP#1 10.0.0.18/30 (SFP14)
(from Switch-2)
ACT
10.0.0.1 /28 10.0.0.2/30 (SFP13)
SCTP Multi-homing in mcRNC
• In mcRNC, redundancy at SCTP layer is provided by multi-
homing. It enables network level redundancy.
• Similar to cRNC but here SCTP connections are terminated
in EIPU unit.
In mcRNC, redundancy at SCTP layer is provided by multi-homing. It enables

network level redundancy (separate routes through network possible).
mcRNC O&M Connection Protection
• Redundancy for
O&M connection
is implemented
through Active-
Stby OMU
configuration on
different modules.
• In case of failure
of one of the
elements
involved in O&M
traffic forwarding,
network
configuration
should be able to
forward traffic on
a backup path.
RAN Equipment
• Introduction
• Operability
• IPA-RNC
Operability (1/2)
• Configuration Management
– Plan based management
▪ RNW Plan file
▪ IP Plan file
▪ IPSec plan file
▪ Signaling Plan file (only in ADA3, possibly in mcRNC2.0)
• SW Management
– Local SW management in mcRNC1.0
▪ Using sCLI of Flexi PF, CLIs and STEs
▪ MMLs of cRNC replaced by sCLI commands and Linux based CLIs
– Remote SW management in mcRNC2.0
Operability (2/2)
• PM, FM and CM
– Frameworks from Flexi PF used
– IL1 provides interface layer to applications where needed
▪ To maintain compatibility with cRNC code base and concepts
• OMS
– Standalone OMS
▪ No more integrated OMS
▪ OMS can handle multiple mcRNCs
– OMS – RNC interface changed from EMT to BTSOM
RNW Plan Objects
• Same RNW object as

IPA-RNC are managed
by mcRNC to be
configured in Netact.
• COCO Object here is

not managed since
ATM configurations are
not yet supported.
• MMLs of cRNC replaced

by sCLI commands and
Linux based CLIs
IP Plan Objects
The mcRNC IP plan interface to NetAct uses similar object model and structure as the
Stuctured Command Line Interface (SCLI).
IP Plan Objects
description
IP Plan Objects
description
IP Plan Objects
description
RAN Equipment
• Introduction
• Operability
• IPA-RNC
cRNC and mcRNC calls flow differences
cRNC architecture comprises RNC-196/450 and RNC-2600

types.
Calls flow is managed in different way according to the RNC
type.
RNC-196 RNC-2600
In following slides we consider just some examples of calls flow

comparing RNC-2600 and mcRNC architecture.
Control-plane Flow
DCH
CCH
User-plane Flow
DCH
CCH
RAN Equipment
• Introduction
• Operability
• IPA-RNC
RNC2600 Configuration Steps
• Step 1: First cabinet, four subracks with

DL Iub throughput 1100 Mbps
• Step 2: First cabinet+two subracks in

second cabinet with DL Iub throughput
1800 Mbps
• Step 3: Two cabinets with DL Iub

throughput 2500 Mbps
RNC2600 step 1
RNC2600 step 2
RNC2600 step 3
RNC2600 Configuration Steps
RNC2600 is the RNC shipped in all new deliveries and comes in three configuration steps
offering 1100, 1800 and 2500 Mbps throughput for DL Iub interface. It provides higher
capacity compare to earlier RNC196 and RNC450 due to several hardware changes:
New plug-in units:

CDSP-DH – Configurable Digital Signal Processing platform.
SF20H – 20 Gbits/s Switching Fabric. New variant for SFU supports 32pcs new high
speed SFU-ports.
MX1G6/-A – ATM multiplexer 1.6 Gbit/s.
NP2GE/-A – Network interface and processing 2x1000Base-T/LX.
NP8S1/-A – Network interface and processing 8xSTM-1.
Removed functional units:

A2SU – functionality is included in the STM-1 interface unit.
GTPU – functionality is included in the Ethernet or STM-1 interface units.
RRMU – functionality is included in ICSU and RSMU/OMU units.
NIP1 –E1/T1/JT1 interfaces are no longer supported in RNC2000.
New mechanics and electromechanics:

BISFA – Back interface panel with SFP connectors for SF20H.
BISFB – Back interface panel with SFP connectors for MX1G6/-A.
BISFC – Back interface panel with SFP connectors for NP2GE/-A and for NP8S1/-A.
BISFD – Back interface panel with SFP connectors for SF20H.
CSB – Intermediate cable with SFP connectors.
RNC2600 Capacity
•Main Capacity values:
RNC2600 Capacity Step 1 Step 2 Step 3
Number of subscribers 680 000 1 360 000 2 000 000
CS busy hour call attempts 680 000 1 360 000 2 000 000
CS Erlangs 17 000 34 000 50 000
CS Erlangs (including soft handover) 23 800 47 600 70 000
PS busy hour call attempts 800 000 1 400 000 2 000 000
DL Iub throughput (Mbps) 1 100 1 800 2 500
DL+UL Iub throughput (Mbps) 1 540 2 520 3 500
Number of carriers 1 440 2 100 2 800
Number of BTSs
1 440 2 100 2 800
(Max 1000 recommended)
RRC connected mode subscribers 100 000 152 000 200 000
•Interfaces capacity:
STM-1 / OC-3 Gigabit Ethernet
RNC2600
Unprotected Protected Unprotected Protected
Step 1 48 24 + 24 16 8+8
Step 2 80 40 + 40 24 12 + 12
Step 3 112 56 + 56 32 16 + 16
This table shows the capacity figures for RNC2600 step 1, 2 and 3. The configuration used is the standard
configuration, which is optimized for traffic handling capacity.
RAN2198 RNC2600 Capacity Increase for
Smartphones
• RNC2600 control plane capacity can be increased by
upgrading RSMU and ICSU functional units with new
CCP1D-A plug-in-units in order to provide more control plane
processing capacity.
• RNC2600 capacity can be increased in case ICSU or RSMU
is the limiting factor and the user plane capacity limits are not
yet exceeded. Control plane capacity increase can be up to
50%.
• CCP18 and CCP1D-A mixed in control plane upgrade is not
supported.
RAN2220 ESA40
• ESA40 in RU30 gives the possibility to replace
ESA24/ESA12 with incresed capacity device.
ESA24 ESA40
24 FE Ports 40 GE Ports
• Compared to ESA24, ESA40 is a Layer 3 Switch, so it

supports L3 protocols and many additional future features.
• It's actually suggested to use it still as L2 Switch as
replacement of ESA24, since L3 performance tests are still
ongoing. RNC site
DCN
OMS
Netact
R1
RNC
VRRP
OMU (WO) ESA40
OMU (SP) ESA40
NP2GE (WO)
NP2GE (SP)
R2
ToP HSRP (ToP,
NPGE)
Block Diagram and Plug-in Unit Variants for
RNC2600 FU/Product PIU Variant
ICSU CCP18-A /
CCP1D-A
RSMU CCP18-A /
CCP1D-A
OMU CCP18-A
DMCU CDSP-DH
SFU SF20H
MXU MX1G6-A
Standalone
or Integrated
SWU ESA24
WDU HDS-B 73G
OMS (integrated) MCP18-B
TBUF TBUF
TSS3 TSS3
PDU PD30
NPS1 NP8S1-B
NPGE NP2GE-A
RNC2600, cont.
Functional units (FU) and their functionalities:
ICSU (Interface Control and Signalling Unit) – signalling to other network elements
and distributed radio resource management related tasks of the RNC.
RSMU (Resource and Switch Management Unit) – RNC's central resource
management tasks such as connection control, internal ATM/IP resource scheduling,
DSP related resource management tasks, call connection related functions.
OMU (Operation and Maintenance Unit) – maintaining the radio network configuration
and recovery, basic system maintenance functions, interface to the OMS unit.
DMCU (Data and Macro Diversity Combining Unit) – RNC-related user and control
plane functions in Frame Protocol (FP), Radio Link Control (RLC), Medium Access
Control (MAC).
SFU (Switching Fabric Unit) – ATM cell switching function supporting point-to-point
and point-to-multipoint connection topologies, as well as differentiated handling of
various ATM service categories.
MXU (Multiplexer Unit) – multiplex traffic from tributary units to the ATM switching
fabric, ATM layer processing functions such as policing, statistics, OAM, buffer
management and scheduling.
SWU (Switching Unit) – Ethernet switch.
WDU (Winchester Disk Unit) – system disk units for OMU.
OMS (Operation and Maintenance Server) – RNC element.
RNC2600 Transmission Units
• Functionalities
– Physical layer functions
– ATM layer functions
– User plane L2 functions NPS1(P)
SFU
– Timing and synchronisation functions
• Redundancy type: NONE or 2N
• NPS1P will support protection mode MSP 1+1
(SDH) and APS 1+1 (SONET)
• Plugin unit type
– NP8S1-B (two slots wide)
• Functionalities
– Physical layer functions
– IP layer functions
– User plane L2 functions
• Redundancy type: NONE or 2N SFU
• Plugin unit type
NPGE(P)
– NP2GE-B
RNC2600 Transmission Units, cont.
The NPS1(P) executes physical layer and ATM layer

functionalities, e.g.
•Map ATM cell to and from transmission frame structure of

SDH/SONET
•ATM header translation
•User Parameter Control (UPC)/ Network Parameter
Control (NPC)
•AAL2 Switching etc.
Beside above functionalities, it also provides an optional

reference clock for timing and synchronisation and GTP
termination when used on Iu-PS.
NPGE and NPS1 Units in RNC2600
• The max number of possible NPGEs is depending also on the
number of needed NPS1 units
RNC450 Capacity Steps
• Step 1: First cabinet, four subracks with

Iub throughput 150 Mbps
• Step 2: First cabinet+two subracks from

second cabinet with Iub throughput 300
Mbps
• Step 3: Two cabinets with Iub

throughput 450 Mbps
RNC450 step 1
RNC450 step 2
RNC450 step 3
RNC450 Capacity Steps, cont.
There are 3 steps for RNC450, with DL Iub throughput of 150, 300 and 450
Mbps. The three steps are also known as RNC450/150, RNC450/300 and
RNC450/450.
Besides the standard configuration, RNC450 can be configured in two special

configurations via software settings and appropriate licenses:
•HSPA optimized configuration – with larger number of HSPA users while
R99 data capacity only 67% of standard configuration.
•Carrier-optimized configuration – with larger number of carriers but
reduced Iub throughput.
RNC450 can be upgraded for higher HSDPA throughput at 14 Mbps per user by
replacing 4, 6 and 8 CDSP-DH units for step 1, 2 and 3, respectively. The number
of HSPA users also increases compare to HSPA optimized configuration. The 14
Mbps peak HSDPA rate per user is an RU10 feature. Without the upgrade, the
peak rate per user is 10 Mbps.
By hardware changes, the RNC450 can be upgraded to RNC2600.
RNC450 Capacity
RNC450 Capacity RNC450/150 RNC450/300 RNC450/450
Number of subscribers 181 000 284 000 360 000
Busy hour call attempts 240 000 375 000 576 000
Erlangs 4 000 6 250 8 000
Iub throughput (Mbps) 150 300 450
Number of carriers 600 900 1 152
Number of BTSs 200 300 512
AAL2UP connectivity (Mbps) 1 950 2 800 3 594
RRC connected mode subscribers 35 000 70 000 100 000
Users supported by CS voice over HSPA 4 000 6 250 8 000
STM-1 / OC-3 E1 / T1 Gigabit Ethernet

RNC450
Unprotected Protected Unprotected Unprotected Protected
8+8
150 16 or 12 + 12 16 8 4+4
(if no E1/T1)
16 + 16
300 24 or 20 + 20 16 12 6+6
(if no E1/T1)
450 24 24 + 24 16 16 8+8
This table shows the capacity figures for RNC450/150, RNC450/300 and
RNC450/450 in standard configuration.
RAN2261 Flexible User Plane Capacity in RNC196
and RNC450
• RAN2261 gives the possiblity to use the new CDSP-DH card as DMCU unit also
in RNC196/450
• RU30 introduces High Speed FACH and HSDPA 84 Mbps for which the DH card
is mandatory due to memory and processing requirements. With RAN2261, also
these features can be taken into use without swapping the RNCs. Other benefits
include reduced DMCU load which converts into better RNC stability in high load
situations and smaller total number of DMCU units required in the RNC.
• Also RNC internal processing for HSPA gets more efficient, as separate HSPA
and DCH pools are not required. Only CCH and non-CCH pools must be
configured.
• All C cards are removed in the upgrade. The number of DH cards required is
smaller than the number of existing C cards.
RNC450
RNC450 IP Upgrade
Functional unit architecture – all IP based
IPoE IuCS/IuPS/Iur
NPGE(P)
ICSU IPoE Iub

MXU NPGE(P)
DMCU
SFU
(SF10E)
ICSU
ICSU
DMCU
MXU MXU
RSMU DMCU
SWU OMU
TBU
OMS
EHU
PDU
HDD WDU
RRMU A2SU GTPU
RNC450 IP Upgrade
Functional unit architecture – hybrid transport
IPoE IuCS/IuPS/Iur
IPoA IuCS/Iur NPGE(P)
NIS1(P)
or ATM IuCS/Iur
IPoE Iub
ATM Iub NIS1(P) NPGE(P)
SFU
(SF10E) A2SU
ICSU
GTPU
DMCU
MXU MXU
ICSU
RSMU
SWU OMU DMCU
OMS TBU
EHU
HDD WDU PDU

RRMU
GTPU and A2SU are exist as long as NIS1(P) is used as network interface
RNC450 HSPA Upgrade
Functional architecture
A2SU NIS1(P)
GTPU
MXU
ICSU
NIP1 (opt.)
DMCU
A2SU
CDSP-DH
SFU
ICSU MXU GTPU
DMCU ICSU
MXU
RSMU DMCU
SWU OMU
TBU
OMS CDSP-DH
EHU
PDU
HDD WDU
RRMU
RNC 196 Capacity Steps
RAN Equipment
• Introduction
• Operability
• IPA-RNC
Flexi Multiradio BTS Platform
technologies
Common for
Modular BTS platform

all radio
Site acquisition and construction principles
Antenna system / transport / power systems

Flexi BTS
building
Optional
blocks
System Remote RF
Module
RF Module OR Head
AC/BBU
Module
Flexi Multiradio BTS
Flexi Multiradio BTS - System Modules
BTS Site level
functionality Baseband Radio
O&M processing processing
Timing/synch
Transport
Flexi Multimode System Module

• HW supports following SW operating modes
• WCDMA dedicated mode
• LTE dedicated mode
• Multiband support
• RF Modules for different frequency bands can
be connected to same System Module
Flexi EDGE System Module

• Performance optimized for single mode operation
• 18 carrier and 36 carrier variants
• Multiband support
• RF Modules for different frequency bands can
be connected to same System Module
Transport sub-modules Microwave
Support
FTEB FTHA FTOA
FTPB 8xE1, IMA 16xE1/T1, IMA 1xSTM1 VC4 New in RU30
8xE1/T1/JT1, IMA 75 Ohm (Coax) 120 Ohm
120 Ohm
FTIF
See Next Slide
FTLB
4xE1/T1/JT1, IMA
3xGE, TOP, Sync. Ethernet, FTFA
Dual Iub, IP Iub, Integrated MWR
ATMoEth, I-HSPA ready, 2xFlexbus,
Full readiness for LTE 16xE1 add/drop,
E1 cross-connect
between interfaces
I-HSPA
LTE
FTFB
Integrated MWR
3x Flexbus (2x powered), 2xGE,
FTIB Sync. Eth. slave & regeneration,
4xE1/T1/JT1, IMA PDH and Packet, Dual Iub & IP Iub,
3xGE, E1 cross-connect & Eth switching
TOP, Sync. Ethernet, FTJA FTIA Full readiness for LTE
Dual Iub, IP Iub, ATMoEth 4xE1 coax, IMA 4xE1/T1/JT1, IMA
Full readiness for LTE 2xFE, 1xGE 2xFE, 1xGE
LTE
LTE
FTIF Transport Module
Optional Outdoor Transport Sub-Module FTIF extends capabilities of Outdoor Flexi Multiradio
System Modules (FSMF, FSMG and FSML) by:
• 2x Combo Ports supporting following combinations
- 2x 100/1000Base-T or
- 2x optional optical SFP or
- 1x 100/1000Base-T and 1x optional optical SFP
• Power + Ethernet optionally supported on electrical Ethernet interfaces, exclusively for zero
footprint FlexiPacket Radio deployment
• Flexi Multiradio System Module + FTIF supports Ethernet Switching across up to 3
interfaces
• 8x E1/T1/JT1 (twisted pair); coaxial connectivity can be provided via baluns
FTIF is required
• for ATM Iub, Dual Iub and IP Iub over ML-PPP
• if collocation (CESoPSN, ML-PPP) or synchronization shall include TDM
• if more/other Ethernet interfaces are required than available on Multiradio System Module
• if Synchronization Hub function based on Synchronous Ethernet input or output shall be
used
Flexi BTS system evolution (FDD) Flexi Multiradio 10 BTS
Multiradio
-Flexi Multiradio System
Flexi WCDMA BTS Flexi Multiradio BTS
Module
WCDMA /HSPA+/LTE --indoor and outdoor
Variants WCDMA /HSPA
-Flexi WCDMA System -Flexi Multimode System
Module (FSMB) Module (FSMC/D/E)
-240CE -240/576/912CE
-3 cells 20MHz LTE
Outdoor
- FSMF core- GSM/WCDMA/LTE
- FSMG core WCDMA/GSM
- FSML core GSM
-FBBA submodule WCDMA/LTE
-FBBB submodule WCDMA/LTE
Flexi EDGE BTS
GSM GSM
-Flexi EDGE -Flexi EDGE
System Module System Module
(ESMA) (ESMB/C) Indoor
-12 TRX -18/36 TRX - FSIH core- TD-LTE
- FBIH submodule
Time
Flexi Multiradio BTS System Modules
2009 2010 2011 2012 2013

EDGE
System Flexi EDGE 18 TRX (ESMB)
available
Modules GSM RG10
Flexi EDGE 36 TRX (ESMC)
available
GSM RG10
720 CE (FSMD)
WCDMA/LTE, available
WCDMA RU10
System LTE RL30
Modules
1140 CE (FSME)
available
WCDMA RU10
LTE RL10
TD-LTE RL05TD
300 CE (FSMC)
available
WCDMA RU20
Flexi Multiradio 10 BTS System Modules
2012 2013 2014 2015

Outdoor Medium capacity (FSMG)
System 2Q/12 HW
Modules GSM RG20EP2
GSM optimized 18 TRX (FSML)

2Q/12 HW
GSM RG20EP2
High capacity (FSMF)

3Q/12 HW
GSM RG20EP2
TD-LTE RL25
LTE RL40
WCDMA RU40
Planned HW availability
• Actual availability and Sw support depends on market needs and customer orders.
Dedicated Transport Scenario
Multiple system modules: physical and logical interfaces (1/2)
EDGE/WCDMA/LTE BTS
3-sector RF
S1: Ethernet
LTE Multimode SM
Iub (ATM, CESoPSN, IP-based): TDM or Ethernet
WCDMA Multimode SM
Abis (Dynamic Abis, CESoPSN, Packet Abis): TDM or Ethernet
GSM/EDGE ESMB/C SM
 Basic scenario:
 each technology has its own backhaul link
 each system module is equipped with transport module which provides
connectivity
 interface dimensioning and configuration done per technology
Shared Transport Scenario
Multiple system modules: physical and logical interfaces (2/2)
EDGE/WCDMA/LTE BTS
“daisy chain” via
integrated Ethernet switch
(QoS aware!)
3-sector RF
Ethernet towards
LTE Multimode SM
PSN backhaul
WCDMA Multimode SM
GSM/EDGE ESMB/C SM
 Transport sharing by chaining of system modules
 both electrical or optical cabling possible
 no formal limitation for length of the chain but…
▪ …each SM in chain introduces small delay and PDV so PSN impairments may limit
the length of chain
 physical realizations: daisy chain via Integrated Ethernet Switching, RP3-1 optical interface, …
 relevant features (enabled on “master” system module):
 transport sharing WCDMA-LTE (RU40, RL30); GSM combined via integrated Eth switch
 QoS aware switching (RG30, RU30, RL20)
 synchronization hub (RG20, RU20, RL30), cf. next slide for details!!!
Synchronization aspects
Synchronization aspects
1. Basic scenario:
▪ each system module is synchronized on its own…
▪ …e.g. via ToP IEEE1588v2 => in such case each module needs its own IP/Eth
connectivity and consumes backhaul bandwidth (small but yet) as well as capacity on
timing server (each module seen as a „client” => the more clients the more servers)
▪ …or via SyncEth => in such case no bandwidth is consumed in the backhaul
but SyncEth must be supported by PSN
▪ …or by any other method (see below); and each one has pros and cons.
2. Synchronization hub:
▪ sync reference signal is provided to system module where the feature is enabled
(RG20, RU20, RL30) and…
▪ …chained system modules can rely on synchronization distributed by “the master”,
e.g. 2G
PDH line interface
FIYx/FIQx
LMUB (GPS) PDH line interface
2.048MHz (only Packet Abis or PWE3) 2.048MHz
Adaptive Clock Recovery (PWE3)

Synchronous Ethernet (FIYB/FIQB) RG20
RG20 Synchronous Ethernet (FIYB/FIQB)
RG20 IEEE1588-2008 via Ethernet switching

IEEE1588-2008 (FIYB/FIQB)
Flexi EDGE (ESMA),
RG25 PPS (Flexi Multiradio) Flexi Multiradio (ESMB/C)
Planning aspects - Overview
Planning aspects: overview (1/4)

 Main planning activities in case of IP/Eth transport are related to:
 bandwidth estimation (CIR definition for traffic shaping needs)
 IP address planning (per plane addressing might be needed depending on
controller addressing concept, i.e. traffic termination entity)
 QoS planning (per plane assignment to L2/L3 QoS classes)
BTS must have configured

(i.e. planning outcome):
- CIR
- set of addresses (IP, …)
- TOS, VID, PCP in L3/L2 headers
Planning aspects – Bw and Addressing
Planning aspects: backhaul capacity and addressing (2/4)
 Bandwidth estimation:
 traffic shaping per technology
 in case of multiple system modules per technology: traffic shaping per system
module and avoid oversubscription within technology
 Bandwidth per BTS depends on: traffic load, codec used, feature configuration
(header compression, bundling efficiency, …)
 IP address:
 IP address determines the equipment where given traffic type is to be
terminated
 if different planes have different termination points (e.g. different BSC
modules) then different addresses needed per single BTS
▪ e.g. example below for GSM
BTS
BSC
Network Gateway Network Gateway
PSN
M-plane CS U-plane
M-plane
C/U-plane PS U-plane
C/U-plane CS/PS U-plane (ETx)
C-plane
C-/M-plane (BCSU)
M-plane
Planning aspects - QOS
Planning aspects: QoS aspects (3/4)
 Traffic differentiation on IP layer and on Ethernet layer
 example for 2G, applicable for any technology (RG20, RU10, RL10)
Eth IP Eth
BTS BSC
PS U-plane CS U-plane C-/M-plane S-plane QoS marking PS U-plane CS U-plane C-/M-plane S-plane
RTP RTP IUA PTP (DSCP) RTP RTP IUA PTP
UDP UDP SCTP UDP UDP UDP SCTP UDP
IP IP forwarding IP
L2 L2 L2 L2
L1 L1 L1 L1
 DiffServ Code Points (DSCP) are configurable per traffic type
Eth Ethernet Eth

BTS BSC
PS U-plane CS U-plane C-/M-plane S-plane QoS marking PS U-plane CS U-plane C-/M-plane S-plane
RTP RTP IUA PTP RTP RTP IUA PTP
UDP UDP Eth p-bit UDP UDP SCTP UDP
SCTP UDP
IP IP
Eth MAC Ethernet Switching Eth MAC
Eth PHY Eth PHY Eth PHY Eth PHY
 Ethernet priority bits (IEEE 802.1p) and/or VLAN ID's (IEEE 802.1q) are used on
Ethernet layer like DiffServ markings (DSCP) on IP layer
Planning aspects - QOS
Planning aspects: QoS aspects (4/4)
 QoS planning (per technology) helps:
 performing „QoS aware” traffic shaping per technology in case of multiple system
modules
traffic shaping level <
low (traffic BTS1 + traffic BTS2)…
priority
high low
Flexi priority
priority
BTS bursty traffic of BTS1 high
priority
BTS low
priority Aggregated uplink traffic
high
Co-located BTS… priority
…e.g. „daisy chained” system modules …but high priority traffic of
bursty traffic of BTS2 both BTSs fully protected!!
 performing „QoS aware” handling of traffic served by different technologies (also

throughout PSN!!!)
2 EVC services
BSC
S1/Packet Abis PSN BSC
GSM-LTE
SLA 1
SLA 2
P-Bit 7
P-Bit 5 P-Bit 7 P-Bit 4
LTE QoS P-Bit 4 P-Bit 7 P-Bit 5
SAE/MME
P-Bit 2
0
P-Bit 7
P-Bit 4 P-Bit 4 P-Bit 3
1
GSM QoS P-Bit 3
1 P-Bit 0
2 P-Bit 2
0
P-Bit 2
0
For further details see "Module 7 – QOS".

Transport in Multiradio BTS
Summary
An example of „all-IP” integrated transport
• LTE SM as synchronization hub with common backhaul
– E1 cables between the System Modules and LTE over ToP
• LTE SM provides Ethernet connectivity towards common backhaul
– integrated QoS aware Ethernet switching via daisy chaining
(simplified picture!)
ETH
BSC
GSM/LTE
RF
S1/IP-Iub/PacketAbis ETH
LTE SM ToP PSN
SAE/MME
E1
3G SM E1
E1
GSM SM E1
ETH
RNC
Transport in Multiradio BTS
Summary
To recap
 Basic scenario: each module acts on its own towards backhaul (possible but non-efficient)
 Transport sharing fully supported:
– integrated Ethernet switching, QoS aware
– efficient synchronization assurance via synchronization hub
– controlled by SW features
 Multiradio flexibility and advanced site solutions allows handling even complex setups
(any mixtures of RATs, multiple system modules per RAT, …)
1/3 RFM 1
S1 (2600 MHz)
FSMD(E)
S1 1/3 RFM 2
FSMD(E) (2100 MHz)
1/3 RFM 3
FSMD(E)
(2100 MHz)
lub
FSMD(E) 1/3 RFM 5
(900 MHz)
Abis
ESMB(C)
1/3 RFM 4
(1800 MHz)
Abis
ESMB(C)
Exercise
Exercise through questions...
• What are the Recovery Group names in mcRNC?
• What are the two traffic profiles names designed for mcRNC?
• What Flexi Multiradio technologies combinations are available

in RU30?
• What is the main benefit of EUBB introduction in Ultrasite

WBTS?

01 RN30031EN40GLA0 RAN Equipments PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

01 RN30031EN40GLA0 RAN Equipments PDF

Transféré par

Droits d'auteur :

Formats disponibles

3GTPL RAN Equipment

RN30031EN40GLA0 ©2014 Nokia Solutions and Networks. All rights reserved.

Intellectual Property Rights

2 RN30031EN40GLA0 ©2014 Nokia Solutions and Networks. All rights reserved.

• This module is mainly focusing on new mcRNC product

• Objective of this module is to

4 RN30031EN40GLA0 ©2014 Nokia Solutions and Networks. All rights reserved.

5 RN30031EN40GLA0 ©2014 Nokia Solutions and Networks. All rights reserved.

6 RN30031EN40GLA0 ©2014 Nokia Solutions and Networks. All rights reserved.

For location services the following methods are supported by RNC:

Cell Coverage Based with Geographical Coordinates

Control Plane User Plane

SCTP ICMPv4 UDP ICMPv4

IPv4 ARP IPv4 ARP

8 RN30031EN40GLA0 ©2014 Nokia Solutions and Networks. All rights reserved.

Control Plane User Plane

SDH/SONET Ethernet-PHY Ethernet-Phy

9 RN30031EN40GLA0 ©2014 Nokia Solutions and Networks. All rights reserved.

Iu User Plane Protocol

10 RN30031EN40GLA0 ©2014 Nokia Solutions and Networks. All rights reserved.

Feature ID: RAN750

Benefits for the operator:

11 RN30031EN40GLA0 ©2014 Nokia Solutions and Networks. All rights reserved.

Interdependencies between features:

RNSAP Control Plane User Plane

13 RN30031EN40GLA0 ©2014 Nokia Solutions and Networks. All rights reserved.

DMCU DMCU RRMU 1 ICSU RRMU 0 ICSU

MXU 4 MXU 2 MXU 1 MXU 0

RRMU removed. Release plug-in unit configured as ICSU.

TBUF TBUF TBUF TBUF TSS3 TBUF

NIP1 10 NIP1 8 NIP1 6 NIP1 4

DMCU DMCU DMCU DMCU

DMCU DMCU DMCU DMCU

DMCU DMCU DMCU DMCU

TBUF TBUF TBUF TBUF TBUF TBUF TBUF TBUF

DMCU DMCU SFU 1 SFU 0

ICSU ICSU DMCU DMCU

ICSU ICSU DMCU DMCU

ICSU ICSU Optional ESA24 ESA24

DMCU DMCU GTPU OMS

DMCU DMCU RRMU 1 ICSU RRMU 0 ICSU

DMCU DMCU RSMU 1 RSMU 0

DMCU DMCU A: WDU 1 OMU A2SU

GTPU GTPU OMU 1 OMU 0

NIS1P / NIS1 3 NIS1P / NIS1 2 ICSU ICSU

TBUF TBUF TBUF TBUF TSS3 TBUF TBUF TSS3

DMCU DMCU DMCU DMCU

ICSU ICSU ICSU ICSU

ICSU ICSU ICSU ICSU

ICSU ICSU ICSU ICSU

DMCU DMCU - DMCU

DMCU DMCU DMCU DMCU

DMCU DMCU DMCU DMCU

MXU 14 MXU 12 MXU 10 MXU 8

PD30 PD30 PD30 PD30

DMCU DMCU DMCU DMCU

TBUF TBUF TBUF TBUF TBUF TBUF TBUF TBUF

ICSU 8 ICSU 3 SFU 1 SFU 0

ICSU 10 ICSU 5 ICSU 1 ICSU 0

ICSU 11 ICSU 6 RSMU 1 RSMU 0

ICSU 12 EHU SWU 1 SWU 0

DMCU 13 DMCU 8 ICSU 2 OMS

DMCU 14 DMCU 9 DMCU 4 DMCU 0