07_ M16-1 HW IP

1 © Nokia Siemens Networks CN60021EN50GLA0

For public use – IPR applies

Open MSS Ma16.1

Hardware Changes and IP Connectivity Description



Summary of external connectivity alternatives for the Open MSS

• Control plane (VMU:GISU, VMU:VLRU)

• L3 via AHUB in M16.0 first deliveries. L2 via IPDU in M16.0EP1 and following deliveries

• O&M (OMU, CMM, ..)

• All O&M traffic via OMU direct blade (RTM) L2 connections to DCN

• Billing (CHU)

• CDR delivery (FTP/SFTP, GTP’ or Diameter/Rf) via CHU direct blade (RTM) L2 connections

• First CHU pair aggregates and forwards other CHUs’ traffic (under verification for Ma16.1 P8)

• OLCM/LIC (VMU:STU, OMU) • If no physical segregation is required: OLCM

interface is via the OMU; OLCM reports are forwarded from STU to OMU over FI

• If physical segregation of OLCM traffic is required: Connectivity via VMU:STU direct blade (RTM) L2 connections; OLCM admin is routed via VMU:STU over FI to OMU

RTM RTM

RTM RTM

RTM

RTM storage

OMU

H

u

b

RTM

RTM storage

CHU

VMU

IPDU

CMM

GISU

VLRU

STU

CMU OLCM

(Optional)

Shelf backplane connection, FI

Shelf backplane connection, BI

Virtualized unit

Physical unit



Overview of the Open MSS Control Plane connectivity evolution

M16.0 First Delivery elements

•Physical connectivity:

• All control plane traffic is connected via the Hub blades using a L3 model

•Load Balancing:

• Only GISU based M3UA Load Balancer is supported (and it is mandatory*)

M16.0EP1 FD elements

• Physical connectivity:

• All control plane traffic is connected via the IPDU blades using a L2 model

• Load Balancing:

• GISU based M3UA Load Balancer is still mandatory*

• IPDUs are in IP forwarding mode (no LB performed)

Ma16.1 FD elements

• Physical connectivity:

• All control plane traffic is connected via the IPDU blades using a L2 model

• Load Balancing:

• H.248, SIP and M3UA traffic is load balanced using the IPDUs

RTMRTM

RTMRTM

RTM

RTM storage

O&M

OMU

H

u

b

FI BI, between

shelves

RTM

RTM storage

CHU

VMU

IPDU

CMM

Billing

GISU

VLRU

STU

CMU

OLCM

Control plane

RTMRTM

RTMRTM

RTM

RTM storage

O&M

OMU

H

u

b

FI BI, between

shelves

RTM

RTM storage

CHU

VMU

IPDU

CMM

Billing

GISU

VLRU

STU

CMU

OLCM

Control plane

RTMRTM

RTMRTM

RTM

RTM storage

O&M

OMU

H

u

b

FI BI, between

shelves

RTM

RTM storage

CHU

VMU

IPDU

CMM

Billing

GISU

VLRU

STU

CMU

OLCM

Control plane

*Only exception is one-shelf configurations

See notes for further explanations



Load Balancers and control plane IP connectivity in the Open MSS (Ma16.1)

•All control plane is connected directly to IPDUs (via RTM) using a L2 model

• The L2 model is different from the DX200 L2 model and does not require a loop topology in the external connectivity and thus not either the Spanning Tree Protocol

• IPDUs handle Load Balancing of H.248 and SIP as in the DX200 implementation but now also of M3UA traffic

• The direct IPDU connectivity model is the only supported configuration in Ma16.1 new delivery network elements

L2/L3 MPBN

Site Switch 1

L2/L3 MPBN

Site Switch 2

Open MSS

IPDU 0

RT

M

IPDU 1

RT

M

IPDU 2

RT

M

GISU

GISU

H

u

b

VMU

GISU

GISU

GISU

VMU

GISU



Load Balancers and control plane IP connectivity in the Open MSS, Intermediate steps

The Open MSS IP connectivity will evolve over the first releases in the following way:

•M16.0 first deliveries

• Control plane is connected via the Hub blades (RTM), with a L3 model

• Only the M3UA load balancer is supported, based on the GISU model (similar to SIGU based M3UA Load Balancer in DX200)

• The GISU based M3UA LB is mandatory except for one-shelf configurations

• M16.0 EP1 new deliveries

• All control plane is connected directly to IPDU with L2 model for new deliveries, no Load Balancing is performed by the IPDU but the IPDU is in “IP forwarding” mode

• Thus the MSS is prepared for Load Balancer introduction from connectivity side

RTM RTM

RTM RTM

RT

M

RTM storage

O&M

OMU

H

u

b

FI BI,

between

shelves

RT

M

RTM storage

CHU

VMU

IPDU

CMM

Billing

GISU

VLRU

STU

CMU

OLCM

Control

plane M16.0 EP1

M16.0

Control

plane



IPDU based Control Plane connectivity for M16.0 EP1 new deliveries

•All control plane protocols are connected directly to IPDUs with L2 model

• IPDU is in “IP forwarding” mode.

•MSS is prepared for Load Balancer introduction from connectivity side.

•AHUB3-A is not anymore used for external connectivity but dedicated for elements internal connectivity.

•IPDUs L2 connectivity model is simple and robust without RSTP/MSTP.

•All Open MSSs are and have been delivered with IPDUs.

•IPDU are N+1 redundant units. • 1+1 IPDUs is the minimum

configuration.

• Recommended minimum is 2+1

L2/L3 MPBN

Site Switch 1

L2/L3 MPBN

Site Switch 2

Open MSS

IPDU 0

RT

M

IPDU 1

RT

M

IPDU 2

RT

M

GISU

GISU

H

u

b

VMU

GISU

VMU

OMU-0

RT

M

OMU-1

RT

M

CHU-0

RT

M

CHU-1

RT

M

DCN Site Switch 1

DCN Site Switch 2

GISU



The Load Balancer Challenge

•The H.248, SIP and M3UA Load Balancer features are/will be mandatory features for all Open MSS network elements – they must be deployed after the Ma16.1 upgrade and before the M17.0 upgrade

•The deployment of the load balancers in already existing, live Open MSS elements has network wide impact on network planning and configuration, separate in every migration step

•Ensuring a smooth migration with minimum effort and risk requires highly skilled engineers in network design and implementation and a solid project plan that integrates into other customer scheduled activities

There is significant service cost associated with the migration cases

NSN must have a well managed sales approach to ensure succesful deployments and NSN business

Note that for Ma16.1 first delivery and later Open MSS deliveries the Load Balancers are mandatory* and must be implemented from the beginning, thus avoiding the migration cost described above. (NPO Network Design for first deliveries with LBs is included in the normal network design service scope)

* See notes page or next slide



Supported and mandatory configurations with Ma16.1 SW

The M3UA, SIP and H.248 load balancers are mandatory in the following situations:

All Ma16.1 first delivery network elements (all LB are based on IPDU)*

M16.0 and M16.0EP1 first deliveries upgraded to Ma16.1 SW if M16.0 capacity statement will be exceeded, i.e.:

• If adding 2nd cabinet in Ma16.1

• OR if any of the CPUs in the MSS/TRS will be 6-core CPU types (by upgrade or extensions)

• OR if capacity will exceed 4M BHCA (NSN default profile for visited MSS)

• OR if capacity will exceed 7M BHCA for TRS (NSN transit profile)

• Specifically for the M3UA Load Balancer:

• The GISU based M3UA Load Balancer can continue to be used in Ma16.1, except in case of I-HSPA deployments with M3UA capacity extension up to 8k I-BTS -> then the IPDU based M3UA LB is mandatory

The IPDU based Load Balancers are mandatory requirement for

all type of configurations in the M17.0 release. Upgrade to Load

Balancers must be performed before the M17.0 SW upgrade.

* Depending on risks in LB maturity and piloting schedule VIPT may decide to allow a

limited amount of Ma16.1 first deliveries without Load Balancers for urgent cases.



VMU

O&M connectivity

•Connecitivity of the O&M related traffic is via the OMU unit direct blade ports (on the RTM)

•The following traffic types are by default using the OMU connectivity:

• SSH/Telnet interfaces on OMU unit

• Performance management (statistics) data is obtained from OMU unit

• Traffica related data is obtained from GISU units via OMU unit

• SiMo related data is obtained from OMU unit

• OLCM connectivity: The default OLCM interface is via the OMU; OLCM reports are forwarded from STU to OMU over FI

•For the O&M traffic (which is UDP/TCP based), IPv4 subnet specific VRRP or HSRP group(s) in the DCN multilayer site switches is used as the first hop gateway(s) in egress direction.

•Network elements that have been deployed using Hub based O&M connectivity must be migrated to direct CPU RTM based O&M connectivity latest at M17.0 (and it is planned that O&M uses IPDU in M17.0)

Open MSS

H

u

b

OMU-0

RT

M

OMU-1

RT

M

DCN

Site

Switch

1

DCN

Site

Switch

2

STU-0

STU-1

VMU

GISU

GISU

VMU

GISU

Traffica

OLCM



Charging/billing LAN connectivity

•In Ma16.1 the charging unit (CHU) connectivity is optimized in order to reduce the number of CHU LAN and network element Ethernet uplinks in general.

•CHU LAN aggregation is default configuration for new Ma16.1 deliveries but can be utilized also with M16.0 First Deliveries. The verification is done with Ma16.1 SW release.

•CHU pair in the 1st shelf aggregates the CHU LAN. Only 1st CHU pair has directly Ethernet cabling to Site Switches.

•The 1st CHU pair routes the CHU traffic from/to other CHU pairs.

•Network elements that have been deployed using Hub based CHU connectivity must be migrated to direct CPU RTM based CHU connectivity latest at M17.0 (and it is planned that CHU use IPDU in M17.0)

L2/L3 MPBN

Site Switch 1

L2/L3 MPBN

Site Switch

Open MSS

CHU-1-0

H

u

b

CHU-1-1

CHU-2-0

CHU-2-1

CHU-0-0

CHU-0-1



OLCM connectivity • The OLCM interface is used for:

• Transport of Intercept related information (activity reports from the STU unit) to the LI system

• Administrative purposes (OLCM configuration using MML via the OMU unit)

• The Default connectivity for all OLCM traffic is via O&M LAN (OMU)

• Optional: OLCM LAN configuration with Direct Blade connections from VMU/STU in case physically isolated OLCM LAN is required

• The traffic related to the OLCM reports is terminated at VMU / STU unit. Traffic related to the Administrative actions is forwarded to the OMU unit.

• OLCM traffic is UDP/TCP based, IPv4 subnet specific VRRP or HSRP group(s) in DCN (or OLCM) multilayer site switches is used as the first hop gateway(s) in egress direction.

• Network elements that have been deployed using Hub based OLCM connectivity must be migrated to direct CPU RTM based OLCM connectivity latest at M17.0 (and it is planned that OLCM uses IPDU in M17.0)

VMU

Open MSS

H

u

b

OMU-0

RT

M

OMU-1

RT

M

OLCM

Site

Switch 1

OLCM

Site

Switch 2

STU-0

STU-1

VMU

GISU

GISU

VMU

GISU

OLCM admin

RT

M

RT

M

Option: OLCM LAN via STU when

physical isolation of LI traffic is

required:



Control plane IP connectivity

•All control plane is connected directly to IPDUs (via RTM) using a L2 model

• The L2 model is different from the DX200 L2 model and does not require a loop topology in the external connectivity and thus not either the Spanning Tree Protocol

• IPDUs handle Load Balancing of H.248 and SIP as in the DX200 implementation but now also of M3UA traffic in Open MSS

• All IPDUs (WO and SP) must be connected to the site L2/L3 switches

• The direct IPDU connectivity model is the only supported configuration in Ma16.1 new delivery network elements

L2/L3 MPBN

Site Switch 1

L2/L3 MPBN

Site Switch 2

Open MSS

IPDU 0

RT

M

IPDU 1

RT

M

IPDU 2

RT

M

GISU

GISU

H

u

b

VMU

GISU

GISU

GISU

VMU

GISU



Connectivity of other traffic types in Ma16.1

•VLR BU

• Via IPDU in IP forwarding mode

•DNS


• LDAP (for NVS/TAS)


• Other signaling interfaces (e.g. SGs, Sv)




The IPDU (IP directory unit)

• Open MSS Control LAN connectivity is provided via IPDUs. – sales item code: MSSAB3300

• IPDUs are N+1 redundant

Configuration rules (note, not yet updated in all documents!) :

– Open MSS 1st shelf has two IPDUs by default and one optional IPDU in either slot 13 or 14

– Each extension shelf has one additional IPDU position reserved by default.

– However more IPDUs can be equipped up to currently max 5+1 IPDUs* when more IPDU processing or traffic separation required.

▪ Each shelf can optionally have one IPDU equipped to the slot 16. The same slot may host GPLU or VMU in case IPDU is not needed.

▪ It is recommended to distribute IPDUs to all available shelves

– In most configurations 4+1 IPDUs will be enough (depending on the capacity required, migration issues, traffic segregation etc.)

• SFPs for IPDUs need to be ordered separately.

Nokia Siemens Networks

1 2 3 4 5 6 7 8 9 10 11 12 13

14 15 16

1 2 3 4 5 6 7 8 9 10 11 12 13

14 15 16

1 2 3 4 5 6 7 8 9 10 11 12 13

14 15 16

Nokia Siemens Networks

1 2 3 4 5 6 7 8 9 10 11 12 13

14 15 16

1 2 3 4 5 6 7 8 9 10 11 12 13

14 15 16

* The max number of IPDUs is planned to be increased in M16.2 and M17



Maximum Unit Quantities in M16.0 and M16.1



Note on GPLU, General Purpose Linux Unit (ACPI4-B) The General Purpose Linux unit provides the WSI (Web Service Interface) and Ut/XCAP (XML Configuration Access Protocol interfaces.

Recommended equipping positions for GPLUs are slots 7 and 10, but GPLUs can also be equipped to any free slot. GPLUs are equipped from top to down, from left to right.

GPLU unit is optional. It is based on LinDX and is connected to DX 200 services like messaging and high availability.

The WSI is a web protocol-based interface (HTTP / SOAP) for MSS and NVS.

The XCAP is a 3GPP standards-compliant protocol

.

This protocol is used by subscribers to manage their supplementary service configuration Data.



New Ma16.1 MSS config



New CPU with 6 core inside in new delivery or HW change

No fixed VMAKVM text file in LFILES any longer.

During HW configuration the VMAKVM file will be written, according to the real configuration. With 6 core CPUs is it possible to create 3 GISU per VMU.



Co-located multiple applications in ATCA platform



Co-located multiple applications

Challenge:

• How to decrease the total cost of ownership

• How to enable effective and simple entry deployment of IMS to provide VoLTE to existing MSC Server System networks

Solution:

• One hardware for all core applications: COTS ATCA

• COTS ATCA ecosystem to ensure lowest possible Total Cost Of Ownership in building and

operating current and next-generation networks


• All services from same COTS ATCA platform – fast time to market • Consolidation from today’s ~30 HW plug-in unit variants to ~10 ATCA blades • Simplified management of spare parts stock • Enhanced serviceability benefits for installation, commissioning, operation and

maintenance • Flexible usage of processing capacity to CS traffic or SIP/IMS traffic

Operator benefits

SR5.0




Functionality:

• MSS and CS-MGW for Circuit Switched services

• NVS providing Telephony Application Server (TAS) and IP-SM-GW functionalities for IMS deployments as well as Service Centralization and Continuity Application Server (SCC AS) for VoLTE call continuity

• NVS deployments also for standalone SIP/VoIP access

• Media Gateway Control Function (MGCF) and IM-MGW for IMS – CS interworking

• IMS deployments where CFX-5000 provides 3GPP standard Proxy and Serving CSCF functionality and Policy and Charging Rules Functions (PCRF)

• Embedded SBC in de-composed model where Border Control Function (BCF) and Border Gateway Function (BGF) are provided embedded in MSS and MGW respectively. eSBC provides the necessary security, service level assurance and protocol manipulation functions for IP interconnect in SIP/VoIP traffic

• Also the registers (HSS, HLR) and packet core (MME, SAE-GW, SGSN, GGSN) network elements can be deployed at the same Open COTS ATCA hardware

MSS

NVS

MGCF

BCF

IMS

I/P/S-CSCF

PCRF

CS - MGW

IM – MGW or

BGF

ATGW

SR5.0

07_ M16-1 HW IP

Documents

Transcript of 07_ M16-1 HW IP