MCRNC Ip Transport and Network Resiliency Printable

mcRNC IP Transport and Network
Resiliency
Nokia Siemens Networks
1 (34)
mcRNC IP Transport and Network Resiliency
Legal notice
Intellectual Property Rights
All copyrights and intellectual property rights for Nokia Siemens Networks training
documentation, product documentation and slide presentation material, all of which
are forthwith known as Nokia Siemens Networks training material, are the exclusive
property of Nokia Siemens Networks. Nokia Siemens Networks owns the rights to
copying, modification, translation, adaptation or derivatives including any
improvements or developments. Nokia Siemens Networks has the sole right to
copy, distribute, amend, modify, develop, license, sublicense, sell, transfer and
assign the Nokia Siemens Networks training material. Individuals can use the Nokia
Siemens 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 Siemens Networks. The
Nokia Siemens Networks training material cannot be used outside of an agreed
Nokia Siemens Networks training session for development of groups without the
prior written agreement of Nokia Siemens Networks.
Indemnity
The information in this document is subject to change without notice and describes
only the product defined in the introduction of this documentation. This document is
intended for the use of Nokia Siemens Networks customers only for the purposes of
the agreement under which the document is submitted, and no part of it may be
used, reproduced, modified or transmitted in any form or means without the prior
written permission of Nokia Siemens Networks. The document has been prepared
to be used by professional and properly trained personnel, and the customer
assumes full responsibility when using it. Nokia Siemens Networks welcomes
customer comments as part of the process of continuous development and
improvement of the documentation.
The information or statements given in this document concerning the suitability,
capacity, or performance of the mentioned hardware or software products are given
as is and all liability arising in connection with such hardware or software products
shall be defined conclusively in a separate agreement between Nokia Siemens
Networks and the customer. However, Nokia Siemens Networks has made all
reasonable efforts to ensure that the instructions contained in the document are
adequate and free of material errors and omissions. Nokia Siemens Networks will, if
deemed necessary by Nokia Siemens Networks, explain issues which may not be
covered by the document.
Nokia Siemens Networks will correct errors in the document as soon as possible. IN
NO EVENT WILL NOKIA SIEMENS NETWORKS BE LIABLE FOR ERRORS IN
THIS DOCUMENT OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO
SPECIAL, DIRECT, INDIRECT, INCIDENTAL OR CONSEQUENTIAL OR ANY
MONETARY LOSSES,SUCH AS BUT NOT LIMITED TO LOSS OF PROFIT,
REVENUE, BUSINESS INTERRUPTION, BUSINESS OPPORTUNITY OR
DATA,THAT MAY ARISE FROM THE USE OF THIS DOCUMENT OR THE
INFORMATION IN IT
This document and the product it describes are considered protected by copyrights
and other intellectual property rights according to the applicable laws.
Wave logo is a trademark of Nokia Siemens Networks Oy. Nokia is a registered
trademark of Nokia Corporation. Siemens is a registered trademark of Siemens
AG.
Other product names mentioned in this document may be trademarks of their
respective owners, and they are mentioned for identification purposes only.
Copyright Nokia Siemens Networks 2011. All rights reserved.
2 (34)
Table of Contents:
1
2
Introduction........................................................................................................ 4
Hardware and Deployment ................................................................................ 5
2.1
Box Controller Node Ethernet Interfaces .................................................... 5
2.2
Network Connectivity ................................................................................. 6
2.3
Deployment Options .................................................................................. 7
2.4
Exercise ..................................................................................................... 9
IP Transport Solutions ..................................................................................... 10
3.1
Functional Architecture of mcRNC ........................................................... 10
3.2
External Interface Processing Unit (EIPU) Overview ................................ 11
3.3
IP Redundancy ........................................................................................ 13
3.4
Benefits of Layer 3 Based Redundancy Protection .................................. 14
3.5
Further Evolution of IP Transport ............................................................. 15
3.6
Recommended mcRNC IP Site Solution .................................................. 16
3.7
Exercise ................................................................................................... 19
Redundancy Solutions ..................................................................................... 20
4.1
mcRNC High Availability System ............................................................. 20
4.2
mcRNC Protocol Structure ....................................................................... 21
4.3
User Plane Redundancy .......................................................................... 25
4.4
Control Plane Redundancy Iub Interface ............................................... 26
4.5
Control Plane Redundancy SCCP-based Interfaces ............................. 27
4.6
Exercise ................................................................................................... 29
Network Resiliency .......................................................................................... 30
5.1
Separation of Applications from Network Interfaces ................................. 30
5.2
Basic Routing Configuration ..................................................................... 30
5.3
Network Failure Cases: EIPU Failure ....................................................... 31
5.4
Network Failure Cases: Network Failure .................................................. 32
5.5
Exercise ................................................................................................... 33
Summary ......................................................................................................... 34
3 (34)
Introduction
The multicontroller RNC (mcRNC) is a recently developed alternative to the classical

RNC (IPA2800 RNC), and is based on a compact, modular and highly scalable multipurpose technology platform.
An mcRNC network element consists of between two and eight stacked hardware
modules also called box controller nodes (BCNs). The mcRNC user plane capacity
can be increased by pairwise adding such hardware modules.
The mcRNC architecture is completely based on IP. As such, the IP transport
solutions are inherited from the classical RNC, where IP transport is just one among
several transport options. As a result, the IP-related transport functions of both types
of RNC can be managed in the same way.
The mcRNC architecture enables the implementation of robust and resilient network
interfacing solutions, based on Layer 3 redundancy protection. The network
interfacing redundancy concept always involves at least one pair of hardware
modules.
4 (34)
Hardware and Deployment
2.1 Box Controller Node Ethernet Interfaces

Each hardware module provides the following external IP connectivity:
16 Gigabit Ethernet (1GE) interfaces are available for external cabling

towards the UMTS Terrestrial Radio Access Network (UTRAN), that is,
towards the Iu, Iur, Iub, Iu-PC, and Iu-BC interfaces. The interfacing is based
on Small Form-factor Pluggable (SFP) modules.
Six 10 Gigabit Ethernet (10GE) interfaces are available for inter-module

cabling. The interfacing is based on the more advanced SFP+ modules.
10GE ports can also be configured as 1GE ports, in which case SFP modules
must be used instead of SFP+ modules.
One SFP connector is available for interconnecting to the Operations and

Maintenance (O&M) network. A second connector is reserved for this purpose
for future use.
Regarding the cabling options, distances up to 100 meters can be reached using
twisted-pair copper cabling (based on the 1000Base-T standard). Multimode fiber
connections (based on the 1000Base-SX standard) typically cover distances up to
one kilometer, and the most advanced single-mode fiber connections (based on the
1000Base-LX standard) can handle transmission distances up to tens of kilometers.
Finally, note that the local hardware maintenance port is used for on-site tech support
only, and thus should not be connected to any network.
5 (34)
2.2 Network Connectivity

The basic mcRNC deployment comprises two hardware modules.
Operations and Maintenance (O&M) related entities such as the O&M Server (OMS)
or NetAct are connected via the data communications network (DCN) and via the site
routers (or Layer 3 site switches) in the backbone network to the O&M interfaces in
the hardware modules.
The user and control plane interfacing to the network via the site switches is
arranged in a redundant fashion using pairs of cables as shown in the figure. In this
way, the network connectivity towards the mcRNC is maintained
if a cable fails,
if a hardware module (or part of it) fails, or
if a site switch fails.
Larger mcRNC deployments are obtained by adding pairs of hardware modules to

the configuration. Deployments with up to eight modules are supported. The external
cabling towards the network is similar to that of the first two modules but note that
the O&M cabling only extends to the first two modules.
The inter-module cabling is also arranged in a redundant fashion. The details are not
shown in the figure.
6 (34)
2.3 Deployment Options

In the maximum capacity deployment the interfacing towards the network is as
shown in the figure. This corresponds to the Voice/Data Balanced (VDB) application
case. Each module is connected to the site switches via four Giganet Ethernet (1GE)
links. The first two modules are also connected to the O&M network via 1GE links.
In the Smartphone application case only half of the modules are connected to the
network.
In future mcRNC releases will also feature 10 Gigabit Ethernet (10GE) connectivity
options.
Let our tutor present an alternative option for extending the transport capacity.
7 (34)
8 (34)
2.4 Exercise
9 (34)
IP Transport Solutions
3.1 Functional Architecture of mcRNC

The mcRNC functional architecture consists of four types of processing units: USPU,
CSPU, CFPU, and EIPU. Each processing unit physically corresponds to an add-in
card in the hardware architecture. The add-in cards are identical from the hardware
point of view but can be differentiated by loading different software to different add-in
cards - in this way implementing the processing units shown in the figure.
Only CFPU and EIPU processing units are involved in IP-layer and transport-layer
protocol processing.
The CFPU processing unit is in charge of handling Operations and Maintenance
(O&M) functions and thus provides a Small Form-factor Pluggable (SFP) port for
connecting towards the data communications network via the site switches.
EIPU processing units provide several SFP ports towards the network. There are two
EIPU units in each hardware module. For redundancy reasons the connectivity
towards the site switches should be arranged as shown in the figure.
Move your pointer over the processing units for a short description of each unit.
10 (34)
3.2 External Interface Processing Unit (EIPU) Overview

Each EIPU processing unit can be allocated up to six SFP+ interfaces for intermodule communication and up to 16 SFP interfaces for external communication
purposes in other words these are the interfaces provided by the BCN hardware
module. Actually only two of the SFP interfaces are needed in order to implement the
necessary redundancy protection. Note that several virtual LAN (VLAN) or Layer 2
addresses can be configured to a physical interface.
The EIPU processing unit also contains integrated router functionality, via which IP
traffic can be routed to/from several transport layer termination points or recovery
groups a concept that will be explained later in this course.
One type of recovery group is available for user plane termination applications at the
Iub, Iur, Iu-PS or Iu-CS network interface.
A second type of recovery group takes care of Iub control plane termination
applications. Up to ten signaling subnets per mcRNC are supported.
The Iu or Iur control plane transport layer resiliency is based on a concept called
SCTP multi-homing. Thus, the resiliency mechanism is somewhat different when
compared to the previous cases. As a result, the IP traffic is already terminated at a
physical interface of an EIPU processing unit. For this purpose, one IP address is
configured to each interface.
Let our tutor explain SCTP in more detail.
11 (34)
12 (34)
3.3 IP Redundancy
IP redundancy in the mcRNC is based on a set of four routers two EIPU internal
routers and two external site routers (or Layer 3 site switches). Resilience is provided
through static routing or by using the Open Shortest Path First (OSPF) routing
protocol.
The EIPU internal routers are able to recognize physical link failures as well as
Ethernet remote fault indication as specified in IEEE 802.3 clause 37.2.15.
Using the configuration example shown in the figure, resilient egress routing from
for example the Iub control plane termination point to the external network is
achieved by forwarding the traffic via both site switches using the ECMP routing
mechanism. This solution provides both link and site switch failure protection.
Resilient ingress routing from the external network to the Iub control plane
termination point is achieved by forwarding the traffic via two EIPU processing units
located in separate hardware modules. Note that ECMP is not applied in this case.
Use your mouse pointer to learn more about the ECMP routing mechanism.
13 (34)
3.4 Benefits of Layer 3 Based Redundancy Protection

The mcRNC IP redundancy solution relies entirely on core IP layer (that is, Layer 3)
functionality. No Layer 2 mechanisms are required neither proprietary Layer 2
mechanisms such as Ethernet link protection or interface switchover mechanisms,
nor Spanning Tree Protocol (STP) solutions.
Furthermore, the implementation of redundancy through static route switching
minimizes the failover time.
The simplified maintenance should also be taken into account. Failure analysis in
Layer 3 is simpler compared with Layer 2. The traffic can be easily forced to certain
routes for maintenance purposes simply by modifying static routes.
14 (34)
Another benefit is that external interfaces are always on. This means that
continuous supervision is supported, using protocols or mechanisms such as
Internet Control Message Protocol (ICMP)
Bidirectional Forwarding Detection (BFD)
Ethernet link-layer Operation, Administration, and Maintenance (EFM OAM)
Note that the RNC site switches are true demarcation points. Network failures are
transparent to the mcRNC and vice versa. There is no need for a redundancy
protocol such as Virtual Router Routing Protocol (VRRP) or Hot Standby Router
Protocol (HSRP), nor is there any need for interface tracking at the mcRNC side.
3.5 Further Evolution of IP Transport

Compared with the classical RNC, the mcRNC offers several Quality of Service
enhancements and configuration simplifications.
Among the Quality of Service enhancements the following could be mentioned:
A real IP scheduler option is now available for IP based routes
The configurability of network interface schedulers or shapers is improved
Layer 3 Differentiated Services Code Points (DSCPs) and Layer 2 Priority

Code Points (PCPs) can now be fully configured
15 (34)
Connection admission control (CAC) is supported in load sharing

configurations.
The following configuration simplifications are worth mentioning:
Iub Stream Control Transmission Protocol (SCTP) enhancements avoid the

need for SCTP port planning; for instance different base stations can share
the same SCTP port in the mcRNC
Multiple Iub control plane parameter sets are supported; for instance different
parameters can be used for rural and urban base stations
Different IP addresses for the Iub interface and the data communications
network (DCN) are supported in the mcRNC
The virtual LAN (VLAN) interfaces support the Open Shortest Path First
(OSPF) routing protocol.
3.6 Recommended mcRNC IP Site Solution

The mcRNC fully integrates into the IP site solution of a cabinet-based RNC, among
others by using:
the same pair of Cisco site routers
the same Cisco IOS operating system software version in the site routers
16 (34)
the same line cards in the site routers
the same Timing over Packet (ToP) master solution.
The Layer 3 connectivity model increases the reliability and at the same time reduces
the operational complexity, since
no redundancy protocol such as Virtual Router Routing Protocol (VRRP) or

Hot Standby Router Protocol (HSRP) is required
no Spanning Tree Protocol (STP) solution is required.
Moreover, the link protection at the IP layer includes dynamic routing support for all
logical interfaces.
A number of planned features support the continued IP transport evolution. Use your
pointer to see a short description of each feature.
17 (34)
18 (34)
3.7 Exercise
19 (34)
Redundancy Solutions
4.1 mcRNC High Availability System

The mcRNC high availability system is based on the model shown in the figure. The
purpose of the high availability system is to provide a framework for detecting failures
in the system and to automatically recover from these failures.
At the highest level in the model is the cluster, that is, the mcRNC itself.
Physically, the cluster consists of a number of nodes, in this case the processor
cards of the mcRNC.
A recovery unit consists of a set of processes or applications running in a certain
node. An application is, for example, Iub user plane termination.
A recovery group is a collection of recovery unit instances that obey the same
redundancy principle, for instance, hot active/standby redundancy. An active/standby
recovery group typically spans two nodes. In this way, if the node with the active
recovery unit fails, the standby recovery unit in the other node can take over.
Use your pointer to examine the main redundancy protection schemes employed in
the mcRNC high availability system.
20 (34)
Hot active/standby:
Cold active/standby:
Load sharing:
N+M scheme:
4.2 mcRNC Protocol Structure

The four types of processing units in the mcRNC handle the processing of protocol
stacks over various interfaces as shown in the figure:
Iu-PS user plane and control plane
Iu-CS user plane and control plane

21 (34)
Iur user plane and control plane
Iub user plane and control plane
Iu-PC related to location-based services
Iu-BC related to the Service Area Broadcast service
O&M interface.
The IP and transport layer protocol processing takes place in EIPU processing units
with the exeption of the Iu-BC and O&M interfaces, where the processing takes
place in the CFPU processing unit.
Regarding the redundancy implementation, protocols in the USPU are protected
through load sharing redundancy, protocols in the CSPU are protected using the
N+M redundancy scheme, and protocols in the CFPU are protected using hot
active/standby redundancy.
Protocols in the EIPU are protected either using hot or cold active/standby
redundancy. This will be explained on the following pages in this course. At this point
it may be worth while to notice the different control plane transport solutions at the
Iub interface and at the Iu and Iur interfaces.
You can use your pointer to learn more about the basic functionality of each protocol.
22 (34)
23 (34)
24 (34)
4.3 User Plane Redundancy

Let us next examine the network termination redundancy implementation in the EIPU
processing units starting with the user plane.
The user plane redundancy solution is based on hot active/standby protection
implemented in a pair of BCN hardware modules each containing two EIPU
processing units. In each recovery group one EIPU unit contains the active recovery
unit and another EIPU unit, located in the other hardware module, contains the
standby recovery unit. There are four such recovery groups, each with the active
recovery unit running in a different EIPU processing unit. This allocation scheme was
chosen for load sharing purposes.
If an EIPU processing unit fails, the complementary EIPU unit may be temporarily
running two active recovery units.
If a whole hardware module fails, all recovery groups still contain an active recovery
unit after switchover, as shown in the figure.
The transport protocols in the user plane (that is, UDP and GTP-u) are stateless.
Thus, in case of failure, the standby instance is simply activated.
Note that external IP addresses are tied to recovery groups, not to individual
recovery units.
This user plane termination solution is used at all interfaces, that is, at the Iu, Iur, and
Iub interfaces.
25 (34)
4.4 Control Plane Redundancy Iub Interface

In the Iub control plane the network termination redundancy implementation is based
on cold active/standby protection. The protection scheme is similar to that used in the
user plane, that is, there are four recovery groups, each with the active recovery unit
running in a different EIPU processing unit.
The application protected by active/standby redundancy is Stream Control
Transmission Protocol (SCTP). The application protocol running on top of SCTP in
another type of processing unit is Node B Application Part (NBAP). An SCTP
association failure is recovered by transparent NBAP re-establishment via another
SCTP association. In other words, the SCTP multihoming feature is not used in the
Iub control plane, unlike in the Iu/Iur control plane as will be explained on the next
page.
Cold active/standby provides sufficient protection for the Iub control plane. The
standby unit needs warming (which takes a few seconds) before the protected
service can be resumed. The application protocol running on top of SCTP (that is,
NBAP) is tolerant to delays caused by SCTP association re-establishment. Thus, hot
standby is not required.
Multiple Iub subnets are supported. This enables the use of different SCTP
parameters for different groups of base stations for example, urban and rural base
stations.
26 (34)
4.5 Control Plane Redundancy SCCP-based Interfaces

In the Iu or Iur control plane the connectivity redundancy implementation is based on
cold active/standby protection of Signaling Connection Control Part (SCCP) protocol
instances, as well as a distributed SIGTRAN protocol stack implementation.
SIGTRAN protocols are M3UA and SCTP.
SCCP is centrally configured and automatically distributed to all EIPU processing
units. M3UA/SCTP instances are automatically attached to SCCP instances. Note
that multiple parallel SCTP associations are being used in the Iu or Iur control plane.
Regarding the Iu interface, for each peer core network element a separate SCTP
association is configured to each EIPU processing unit. This results in between 4 and
16 SCTP associations per signaling connection, depending on the mcRNC
configuration. This allows the mcRNC to perform optimum load balancing across all
EIPU units.
Regarding the Iur interface, full load sharing is not feasible, so that fewer SCTP
associations are configured. Otherwise the redundancy implementation is the same
as for the Iu interface.
Network connectivity protection is achieved through SCTP multi-homing within a
certain SCTP association. If the IP termination point fails, another termination point
takes over.
27 (34)
SCTP IP addresses are configured directly to network interfaces. These can be

shared by multiple SCCP signaling connections.
28 (34)
4.6 Exercise
29 (34)
Network Resiliency
5.1 Separation of Applications from Network Interfaces

The IP transport solution in the mcRNC results in a high degree of network resilience,
due to the separation of applications from network interfaces.
The internal routing functionality in the EIPU processing unit provides a real
demarcation between the external IP network and applications running in the
mcRNC.
On one side of the demarcation line, application failovers are transparent to the
external IP network. In case of failure the affected functions are moved to another
EIPU unit without involvement of the external network.
On the other side of the demarcation line, the status of the external network
interfaces is transparent to the mcRNC applications.
5.2 Basic Routing Configuration

The basic routing configuration provides redundancy via static routes as shown in
this routing example. It is assumed that the active recovery unit is located in EIPU
processing unit zero and the standby recovery unit is located in EIPU unit one. Note
30 (34)
the single IP address pointing to the recovery group. The network interface IP
addresses are also shown in the example.
In the egress direction there are two high priority routes via site switch 1.
In the ingress direction there is one high priority route and one low priority route via
site switch 1.
The routes are configured in a similar way via site switch 2.
The internal routing takes place via the 10 Gigabit Ethernet backbone.
Let us next examine some typical failure cases using this basic routing setup
example.
5.3 Network Failure Cases: EIPU Failure

In the first failure case we assume that a whole EIPU processing unit goes out of
service.
When the affected network interfaces recognize a loss of signal (LOS), this causes
the site switches to stop all routing through these interfaces. The IP traffic is now only
routed to/from EIPU processing unit 1.
31 (34)
Taking another failure case, we assume that a single application in EIPU processing
unit 0 fails. As a result, a failover takes place. Now the ingress IP traffic destined for
this application is routed via the 10 Gigabit Ethernet backbone to the application
instance running in EIPU processing unit 1.
5.4 Network Failure Cases: Network Failure

As a typical network failure case we assume an Ethernet link failure as shown in the
figure. The loss of signal recognition causes the stopping of all routing through the
affected network interfaces.
Ingress IP traffic via site switch 1 is now routed via EIPU processing unit 1 and via
the 10 Gigabit Ethernet backbone to the active recovery unit in EIPU unit 0. There
may also be ingress traffic via site switch 2. Egress traffic is only routed through site
switch 2.
As a final failure case we assume that a site switch say site switch 1 fails. Again,
the loss of signal recognition causes the stopping of all routing through the affected
network interfaces. All ingress and egress IP traffic is now routed via site switch 2.
32 (34)
5.5 Exercise
33 (34)
Summary
In summary, the mcRNC transport architecture is completely based on IP and

redundancy protection at the IP layer, that is, Layer 3.
The redundancy solution includes:
A pair of Layer 3 site switches
Pairs of EIPU processing units located in different hardware modules
Integrated router functionality within each EIPU unit
Inter-module connectivity via the 10GE backbone.
The redundancy protection for the various interfaces is as follows:
Hot active/standby protection of UDP or GTP-u traffic in the user plane
Cold active/standby protection of SCTP in the Iub control plane
Multiple (parallel) SCCP associations are used in combination with SCTP

multi-homing in the Iu/Iur control plane.
Thank you for completing this course.
34 (34)

MCRNC Ip Transport and Network Resiliency Printable

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

MCRNC Ip Transport and Network Resiliency Printable

Hochgeladen von

Copyright:

Verfügbare Formate

mcRNC IP Transport and Network

Nokia Siemens Networks