mcrnc ip transport and network resiliency printable

© Nokia Siemens Networks

1 (34)

mcRNC IP Transport and Network Resiliency



2 (34)

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.



3 (34)

Table of Contents: 1 Introduction ........................................................................................................ 4 2 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

3 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

4 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

5 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

6 Summary ......................................................................................................... 34



4 (34)

1 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 multi-purpose 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.



5 (34)

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



6 (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.



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



8 (34)



9 (34)

2.4 Exercise



10 (34)

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



11 (34)

3.2 External Interface Processing Unit (EIPU) Overview

Each EIPU processing unit can be allocated up to six SFP+ interfaces for inter-module 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.



12 (34)



13 (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.



14 (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.



15 (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



16 (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



17 (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.



18 (34)



19 (34)

3.7 Exercise



20 (34)

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



21 (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



22 (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.



23 (34)



24 (34)



25 (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.



26 (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.



27 (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.



28 (34)

SCTP IP addresses are configured directly to network interfaces. These can be shared by multiple SCCP signaling connections.



29 (34)

4.6 Exercise



30 (34)

5 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



31 (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.



32 (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.



33 (34)

5.5 Exercise



34 (34)

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

mcrnc ip transport and network resiliency printable

Documents