07_ m16-1 hw ip
DESCRIPTION
m16TRANSCRIPT
1 © Nokia Siemens Networks CN60021EN50GLA0
For public use – IPR applies
Open MSS Ma16.1
Hardware Changes and IP Connectivity Description
For public use – IPR applies
2 © Nokia Siemens Networks CN60021EN50GLA0
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
For public use – IPR applies
3 © Nokia Siemens Networks CN60021EN50GLA0
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
For public use – IPR applies
4 © Nokia Siemens Networks CN60021EN50GLA0
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
For public use – IPR applies
5 © Nokia Siemens Networks CN60021EN50GLA0
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
For public use – IPR applies
6 © Nokia Siemens Networks CN60021EN50GLA0
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
For public use – IPR applies
7 © Nokia Siemens Networks CN60021EN50GLA0
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
For public use – IPR applies
8 © Nokia Siemens Networks CN60021EN50GLA0
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.
For public use – IPR applies
9 © Nokia Siemens Networks CN60021EN50GLA0
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
For public use – IPR applies
10 © Nokia Siemens Networks CN60021EN50GLA0
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
For public use – IPR applies
11 © Nokia Siemens Networks CN60021EN50GLA0
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:
For public use – IPR applies
12 © Nokia Siemens Networks CN60021EN50GLA0
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
For public use – IPR applies
13 © Nokia Siemens Networks CN60021EN50GLA0
Connectivity of other traffic types in Ma16.1
•VLR BU
• Via IPDU in IP forwarding mode
•DNS
• Via IPDU in IP forwarding mode
• LDAP (for NVS/TAS)
• Via IPDU in IP forwarding mode
• Other signaling interfaces (e.g. SGs, Sv)
• Via IPDU in IP forwarding mode
For public use – IPR applies
14 © Nokia Siemens Networks CN60021EN50GLA0
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
For public use – IPR applies
15 © Nokia Siemens Networks CN60021EN50GLA0
Maximum Unit Quantities in M16.0 and M16.1
For public use – IPR applies
16 © Nokia Siemens Networks CN60021EN50GLA0
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.
For public use – IPR applies
17 © Nokia Siemens Networks CN60021EN50GLA0
New Ma16.1 MSS config
For public use – IPR applies
18 © Nokia Siemens Networks CN60021EN50GLA0
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.
19 © Nokia Siemens Networks CN60021EN50GLA0
For public use – IPR applies
Co-located multiple applications in ATCA platform
For public use – IPR applies
20 © Nokia Siemens Networks CN60021EN50GLA0
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
Co-located multiple applications
• 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
For public use – IPR applies
21 © Nokia Siemens Networks CN60021EN50GLA0
Co-located multiple applications
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