Mobifone GPRS Phase6 HLD v1.5

Upgrading and Expanding NSN PS Core system
MobiFone Phase 6
High Level Design
1 / 136 © 2017 Nokia

Contents
1 Introduction ........................................................................................................................................ 10
1.1 Scope .............................................................................................................................................. 10
1.2 Mobifone requirement ................................................................................................................. 10
1.3 Mobifone traffic profiles .............................................................................................................. 12
1.4 Nokia solution................................................................................................................................ 13
1.4.1 Delivery ..................................................................................................................................... 13
1.5 Mobifone radio coverage plan .................................................................................................... 15
1.5.1 The Radio Coverage of current network .............................................................................. 15
1.5.2 The Radio Coverage of target network ................................................................................ 16
1.5.3 The target service pooling coverage per area for each vendor ....................................... 17
1.6 Naming convention ...................................................................................................................... 19
2 Network architecture ......................................................................................................................... 20
2.1 Network layers .............................................................................................................................. 20
2.2 Logical topology............................................................................................................................ 26
2.3 Physical topology .......................................................................................................................... 27
3 Network design ................................................................................................................................... 28
3.1 Capacity ......................................................................................................................................... 28
3.1.1 SAE-GW ..................................................................................................................................... 28
3.1.2 Upgrade Flexi NS ..................................................................................................................... 28
3.1.3 New Flexi NS ............................................................................................................................. 29
3.1.4 CMD ........................................................................................................................................... 29
3.1.5 DNS ........................................................................................................................................... 29
3.2 Hardware ........................................................................................................................................ 30
3.2.1 Overview ................................................................................................................................... 30
3.2.2 SAE-GW ..................................................................................................................................... 30
3.2.3 SGSN/MME ............................................................................................................................... 33
3.2.4 SAM ........................................................................................................................................... 40
3.2.5 CMD ........................................................................................................................................... 41
3.2.6 Traffica ..................................................................................................................................... 41
3.2.7 FMA ........................................................................................................................................... 42
2 / 136 © 2017 Nokia

3.2.8 DNS ........................................................................................................................................... 42
3.3 Software......................................................................................................................................... 42
3.4 Connectivity .................................................................................................................................. 43
3.4.1 SAE-GW ..................................................................................................................................... 43
3.4.2 SGSN/MME ............................................................................................................................... 57
3.4.3 NetAct ....................................................................................................................................... 70
3.4.4 SAM ........................................................................................................................................... 71
3.4.5 CMD ........................................................................................................................................... 72
3.4.6 Traffica ..................................................................................................................................... 73
3.4.7 FMA ........................................................................................................................................... 74
3.4.8 DNS ........................................................................................................................................... 75
3.4.9 NTP server ................................................................................................................................ 80
3.5 QoS and DSCP Marking ................................................................................................................ 80
3.5.1 Overview ................................................................................................................................... 80
3.5.2 QoS requirements of Mobifone network for the LTE deployment. ................................. 81
3.6 Pooling ........................................................................................................................................... 82
3.6.1 Pool location ............................................................................................................................ 82
3.6.2 MME Functionality ................................................................................................................... 84
3.6.3 SGSN functionality .................................................................................................................. 88
3.6.4 SGSN/MME Pooling parameters ............................................................................................ 90
3.6.5 Pooling requirement ............................................................................................................... 91
3.6.6 SGSN MME Pool Configuration .............................................................................................. 91
3.6.7 Traffic flows ............................................................................................................................. 93
3.7 IPv6 support .................................................................................................................................. 103
3.7.1 User Plane IPv6 Implementation........................................................................................... 103
3.7.2 User Plane IPv6 Stack and Interfaces Impacted ................................................................. 104
3.7.3 Mobifone UE IP Address Allocation – IPv6 ........................................................................... 106
3.8 Service control .............................................................................................................................. 107
3.8.1 PDN services ............................................................................................................................ 107
3.8.2 Application Assurance ............................................................................................................ 110
3.8.3 Per application Policing and Charging Enforcement .......................................................... 113
3.8.4 PCEF .......................................................................................................................................... 115
3 / 136 © 2017 Nokia

3.9 Charging ......................................................................................................................................... 118
3.9.1 SAE-GW ..................................................................................................................................... 118
3.9.2 CMD ........................................................................................................................................... 123
3.10 KPI requirement ............................................................................................................................ 124
3.11 Redundancy concept .................................................................................................................... 129
3.11.1 7750 MG SGW/PGW/GGSN Redundancy .............................................................................. 129
3.11.2 Flexi NS LAN redundancy ....................................................................................................... 129
4 Document control .............................................................................................................................. 132
5 Glossary ............................................................................................................................................... 133
4 / 136 © 2017 Nokia

Index of figures
Figure 1 Network topology Multilevel of Northern area currently ......................................................................... 20
Figure 2 Network topology Multilevel of Northern area after project ................................................................... 21
Figure 3 Network topology Multilevel of Middle area currently .............................................................................. 22
Figure 4 Network topology Multilevel of Middle area after project ....................................................................... 23
Figure 5 Network topology Multilevel of Southern area currently ......................................................................... 24
Figure 6 Network topology Multilevel of Southern area after project .................................................................. 25
Figure 7 Logic topology ................................................................................................................................................ 26
Figure 8 Target Mobifone Packet Core Network in Phase 6 Upgrading and Expanding..................................... 27
Figure 9: Global deployment architecture. ................................................................................................................ 30
Figure 10: 7750 SR-12 MG Hardware ........................................................................................................................ 32
Figure 11 Application architecture for ucces access Flexi NS................................................................................. 34
Figure 12 New units for MME function ....................................................................................................................... 35
Figure 13 Flexi NS Shelf Configuration for Site C30 & Q09 .................................................................................... 36
Figure 14 Flexi NS Shelf Configuration for Site YHA and GBT ................................................................................ 37
Figure 15 MME_ATQ0903N and MME_ATQ0904N Shelf Configuration ................................................................. 38
Figure 16 MME_ATNVL01N and MME_ATADN01N Shelf Configuration ................................................................. 39
Figure 17 – 5620 SAM – HP DL380 Gen 9 Server – Front ........................................................................................ 40
Figure 18 – 5620 SAM – HP DL380 Gen 9 Server – Rear .......................................................................................... 40
Figure 19 Infoblox Trinzic 2220 .................................................................................................................................. 42
Figure 20 Infoblox Trinzic 1420 .................................................................................................................................. 42
Figure 21: Logical interfaces ....................................................................................................................................... 43
Figure 22 : Physical Connectivity Diagram- EPG_MGYHA01N ................................................................................. 45
Figure 23 : Physical Connectivity Diagram- EPG_MGGBT01N ................................................................................. 46
Figure 24 : Physical Connectivity Diagram- EPG_MGQ0901N................................................................................. 47
Figure 25: Physical Connectivity Diagram-EPG_MGQ0902N................................................................................... 48
Figure 26: Physical Connectivity Diagram-EPG_MGC3001N ................................................................................... 49
Figure 27: Physical Connectivity Diagram-EPG_MGC3002N ................................................................................... 50
Figure 28 L3 Service Architecture-Hanoi................................................................................................................... 55
Figure 29: L3 Service Architecture-Ho Chi Minh ....................................................................................................... 56
Figure 30 Flexi NS-SGSN_MME High Level Interface Logical Connectivity ............................................................ 57
Figure 31 Internal connectivity Base Interface ......................................................................................................... 58
Figure 32 Internal connectivity Fabric Interface ....................................................................................................... 58
Figure 33 Physical Interface Requirement for new Flexi NS at Site Q09 ............................................................ 59
Figure 34 Physical Interface Requirement for new Flexi NS at Site DaNang ...................................................... 59
Figure 35 : Physical Connectivity Diagram- MME_ATADN01N ................................................................................ 60
Figure 36 : Physical Connectivity Diagram- MME_ATNVL01N ................................................................................. 61
Figure 37 : Physical Connectivity Diagram- MME_ATQ0903N ................................................................................ 62
Figure 38 : Physical Connectivity Diagram- MME_ATQ0904N ................................................................................ 63
Figure 39 L3 Service Architecture .............................................................................................................................. 64
Figure 40 SAM Mediation ............................................................................................................................................. 70
Figure 41 Connection from SAM to router ................................................................................................................ 71
5 / 136 © 2017 Nokia

Figure 42 Connection from CMD to switch ............................................................................................................... 72
Figure 43 TNES Server High Level Interface Connectivity...................................................................................... 73
Figure 44 Existing FMA Server High Level Interface Connectivity ......................................................................... 74
Figure 45 DNS traffic - Redundant GRID Master with HA Pair ............................................................................... 75
Figure 46 Infoblox OAM ............................................................................................................................................... 75
Figure 47: DNS records in 4G ...................................................................................................................................... 76
Figure 48 IPv6IPv4 ........................................................................................................................................................ 79
Figure 49 SGSN MME Pool Locations .......................................................................................................................... 83
Figure 50: Load balancing with MME pools ................................................................................................................ 84
Figure 51: MME pool overlap ....................................................................................................................................... 85
Figure 52 Mapping of 2G/3G identifiers to LTE GUMMEI ........................................................................................ 86
Figure 53 MME selection in idle mode IRAT change to LTE ..................................................................................... 87
Figure 54 SGSN selection in idle mode IRAT change to 2G/3G .............................................................................. 89
Figure 55 RA updates between pool areas ................................................................................................................ 94
Figure 56 RA updates with traditional SGSNs ........................................................................................................... 94
Figure 57: Network Scenario ....................................................................................................................................... 95
Figure 58: Default SGSN Functionality ....................................................................................................................... 99
Figure 59: Non-pool to Pool handover .................................................................................................................... 100
Figure 60: Non-pool to Pool handover .................................................................................................................... 101
Figure 61: DNS64&NAT64 Traffic Flow .................................................................................................................... 104
Figure 62: E2E stack and interfaces impacted with IPv6 ....................................................................................... 105
Figure 63: High Level Architecture IPv6 ................................................................................................................... 105
Figure 64: Virtual APN Selection Alternatives ......................................................................................................... 108
Figure 65: Application Assurance on MS-ISA ........................................................................................................... 110
Figure 66: Example of protocols included in signatures file ................................................................................. 111
Figure 67: S/PGW L7 classification ........................................................................................................................... 113
Figure 68: S/PGW Rate-limiting ................................................................................................................................. 116
6 / 136 © 2017 Nokia

Index of tables
Table 1 Requirement of SGSN/MME ........................................................................................................................... 11
Table 2 Requirement of SAE-GW/GGSN ..................................................................................................................... 11
Table 3 – 2G/3G Traffic Mix in Mobifone Network .................................................................................................... 12
Table 4 – 4G Traffic Mix in Mobifone Network ........................................................................................................... 12
Table 5 Offered Network Elements for the Proposed Solution ............................................................................. 13
Table 6 List the existing and new network elements’ name and their location ................................................... 14
Table 7 North Area ........................................................................................................................................................ 15
Table 8 South Area ....................................................................................................................................................... 16
Table 9 North Area ........................................................................................................................................................ 16
Table 10 South Area ..................................................................................................................................................... 16
Table 11 North Area – Ericsson ................................................................................................................................... 17
Table 12 North Area – Nokia ........................................................................................................................................ 17
Table 13 Midle Area – Nokia ......................................................................................................................................... 18
Table 14 South Area – Ericsson ................................................................................................................................... 18
Table 15 South Area – Nokia ........................................................................................................................................ 19
Table 16 Node name rule example ............................................................................................................................. 19
Table 17 Mobifone Capacity Requirements .............................................................................................................. 28
Table 18 Upgrade Flexi NS Capacity Requirement ................................................................................................... 28
Table 19 Upgrade Flexi NS Configuration .................................................................................................................. 28
Table 20 New Flexi NS Capacity Requirement .......................................................................................................... 29
Table 21 New Flexi NS Configuration ......................................................................................................................... 29
Table 22 DNS capacity .................................................................................................................................................. 29
Table 23 Nodes Inventory ............................................................................................................................................ 30
Table 24 7750MG hardware ........................................................................................................................................ 30
Table 25 – New and Upgraded Flexi-NS in Phase 6 .................................................................................................. 35
Table 26 Location, site and node name .................................................................................................................... 41
Table 27 Traffica hardware .......................................................................................................................................... 41
Table 28 Node name .................................................................................................................................................... 41
Table 29 Software releases ......................................................................................................................................... 42
Table 30 Logical interfaces and 3GPP compliancy ................................................................................................... 43
Table 31 Physical Connectivity Table- EPG_MGYHA01N .......................................................................................... 45
Table 32 Physical Connectivity Table- EPG_MGGBT01N......................................................................................... 46
Table 33 Physical Connectivity Table- EPG_MGQ0901N ......................................................................................... 47
Table 34 Physical Connectivity Table-EPG_MGQ0902N .......................................................................................... 48
Table 35 Physical Connectivity Table-EPG_MGC3001N........................................................................................... 49
Table 36 Physical Connectivity Table- EPG_MGC3002N.......................................................................................... 50
Table 37 7750 MG Transport Connectivity- EPG_MGYHA01N ................................................................................ 51
Table 38 7750 MG Transport Connectivity-EPG_MGGBT01N ................................................................................. 52
Table 39 7750 MG Transport Connectivity-EPG_MGQ0901N ................................................................................ 52
Table 40 7750 MG Transport Connectivity- EPG_MGQ0902N ............................................................................... 53
Table 41 7750 MG Transport Connectivity-EPG_MGC3001N ................................................................................. 53
7 / 136 © 2017 Nokia

Table 42 7750 MG Transport Connectivity-EPG_MGC3002N ................................................................................. 54
Table 43 7750 MG VPRN Details – Site Ha Noi .......................................................................................................... 55
Table 44: 7750 MG VPRN Details – Site Ho Chi Minh ................................................................................................ 56
Table 45 Physical Connectivity Table- MME_ATADN01N ......................................................................................... 60
Table 46 Physical Connectivity Table- MME_ATNVL01N .......................................................................................... 61
Table 47 Physical Connectivity Table- MME_ATQ0903N ......................................................................................... 62
Table 48 Physical Connectivity Table- MME_ATQ0904N ......................................................................................... 63
Table 49 FNS VPRN Details – Da Nang site ................................................................................................................ 64
Table 50 FNS VPRN Details – HCM site ....................................................................................................................... 65
Table 51 Upgraded Flexi NS IP address and VLAN requirement ............................................................................ 65
Table 52 New Flexi NS IP address and VLAN requirement ...................................................................................... 66
Table 53 High Level IP Address Allocation for Flexi NS SGSN-MME in HCMC....................................................... 66
Table 54 High Level VLAN Allocation for Flexi NS SGSN_MME in HCMC ................................................................. 67
Table 55 High Level IP Address Allocation for Flexi NS SGSN-MME in HCMC........................................................ 67
Table 56 High Level VLAN Allocation for Flexi NS SGSN_MME in HCMC ................................................................. 67
Table 57 High Level IP Address Allocation for Flexi NS SGSN-MME in Hanoi ....................................................... 67
Table 58 High Level VLAN Allocation for Flexi NS SGSN_MME in Hanoi ................................................................. 68
Table 59 High Level IP Address Allocation for Flexi NS SGSN-MME in DaNang .................................................... 68
Table 60 High Level VLAN Allocation for Flexi NS SGSN-MME in DaNang .............................................................. 68
Table 61 SPC & GT ........................................................................................................................................................ 69
Table 62. IP range allocation ....................................................................................................................................... 72
Table 63 Existing TNES Server IP address and VLAN allocation ............................................................................. 73
Table 64 New TNES Server IP address and VLAN allocation.................................................................................... 74
Table 65 Existing FMA Server IP address and VLAN allocation ............................................................................... 74
Table 66 IP requirement .............................................................................................................................................. 76
Table 67 QoS mapping ................................................................................................................................................. 81
Table 68 SGSN MME Pools ........................................................................................................................................... 83
Table 69 MME pool area vs MME pool ........................................................................................................................ 84
Table 70 Show the parameters that required to be configured on Flexi NS for pooling functionality. ........... 90
Table 71 Hanoi SGSN MME Pool Configuration ......................................................................................................... 91
Table 72 DaNang SGSN MME Pool Configuration ..................................................................................................... 91
Table 73 HCMC SGSN MME Pool Configuration ........................................................................................................ 92
Table 74 Handover scenario (3G-3G) ......................................................................................................................... 95
Table 75: Handover scenario (2G-2G) ........................................................................................................................ 96
Table 76: Handover scenario (2G-3G) ........................................................................................................................ 97
Table 77: Mobifone Existing APNs ............................................................................................................................ 109
Table 78. CDR handling description ......................................................................................................................... 123
Table 79. Elements at south interface ..................................................................................................................... 123
Table 80. Traffic distribution at south interface .................................................................................................... 123
Table 81. North interface description ...................................................................................................................... 124
Table 82. FNS KPI ........................................................................................................................................................ 124
Table 83. 7750MG KPI ................................................................................................................................................ 125
Table 84. FNS KPI Formula ......................................................................................................................................... 125
Table 85. 775MG KPI Formula ................................................................................................................................... 128
8 / 136 © 2017 Nokia

Table 86 Abbreviations .............................................................................................................................................. 133
9 / 136 © 2017 Nokia

1 Introduction
1.1 Scope
The main scope of the document is to describe the high level design of the new packet core elements to be
installed at Mobifone site pertaining to Phase 6 expansion project.
1.2 Mobifone requirement
Expanding and upgrading NSN PS Core for triple access 2/3/4G.
SGSN/MME pool implementation with total capacity as following:
• SGSN/MME support 12.000k 2/3G subs, 1.000k 4G subs.

• SAE-GW support 8.400k pdpctx/bearer and 280Gbps.
Suppling:
• 01 new GnDNS and 01 new GiDNS (with 1+1 redundancy) for Hanoi site.
• 01 new GnDNS and 01 new GiDNS (with 1+1 redundancy) for Ho Chi Minh site.
Detail requirements for CSI systems:
• Charging Gateway:
 Upgrade to the latest software version for charging gateway
• OMC system
 Upgrade to the latest software version for OMC system for both 12.000k 2G/3G subscribers
and 1.000k 4G subscribers license.
• Monitoring and reporting system
 Upgrade to the latest software version for monitoring and reporting system for existing SGSN
nodes and provide the new monitoring system for new SGSN-MME nodes.
10 / 136 © 2017 Nokia

Detail requirements for number of SGSN/MME nodes and capacity of SGSN/MME nodes as following:
Table 1 Requirement of SGSN/MME
Current system Requirement for this procurement package

Location Node kSubs kPDP 2G Thp 3G Thp 2/3G kPDP 2G Thp HW 2G Thp SW 3G Thp SW LTE HW New LTE SW
Information (Mbps) (Mbps) kSubs (Mbps) (Mbps) (Mbps) ksubs ksubs
HNI FNS_Ph5 1.200 840 300 1.000 700 490 500 300 250 180 70
HNI FNS_Ph5 800 560 300 1.000 700 490 500 300 250 180 70
HNI FNS_Ph5 800 560 300 1.000 700 490 500 300 250 180 70
DNG FNS_NEW 1.100 770 500 500 250 400 150
DNG FNS_NEW 1.100 770 500 500 250 400 150
HCM FNS_Ph4.5 600 420 400 400 1.100 770 500 300 250 220 70
HCM FNS_Ph5 1.100 770 300 1.000 1.100 770 500 300 250 220 70
HCM FNS_Ph5 1.100 770 300 1.000 1.100 770 500 300 250 220 70
HCM FNS_Ph5 1.200 840 300 1.000 1.100 770 500 300 250 220 70
HCM FNS_Ph5 800 560 300 1.000 1.100 770 500 300 250 220 70
HCM FNS_NEW 1.100 770 500 300 250 220 70
HCM FNS_NEW 1.100 770 500 300 250 220 70
Total HNI 4.000 2.800 1.200 3.300 2.100 1.470 1.500 900 750 540 210
Total DNG 800 560 200 200 2.200 1.540 1.000 1.000 500 800 300
Total HCM 7.200 5.040 5.040 5.000 7.700 5.390 3.500 2.100 1.750 1.540 490
Grand Total 12.000 8.400 8.400 8.500 12.000 8.400 6.000 4.000 3.000 2.880 1.000
Detail requirements for number of SAE-GW nodes and capacity of SAE-GW nodes as following:
Table 2 Requirement of SAE-GW/GGSN
Current system Requirement for this procurement package

Location Node Information kpdpctx/kbearer Thp (Gbps) kpdpctx/kbearer Thp (Gbps)
HNI FISN 400 5
HNI FISN 400 5
HNI FNG_Ph4 800 20
HNI FNG_Ph5 1.600 40
HNI New GW 1.400 40
HNI New GW 1.400 40
HCM FISN 400 5
HCM FISN 400 5
HCM FNG_Ph4 800 20
HCM FNG_Ph4.5 800 20
HCM FNG_Ph5 1.400 40
HCM FNG_Ph5 1.400 40
HCM New GW 1.400 50
HCM New GW 1.400 50
HCM New GW 1.400 50
HCM New GW 1.400 50
Total HNI 3.200 70 2.800 80
Total HCM 5.200 130 5.600 200
Grand Total 8.400 200 8.400 280
11 / 136 © 2017 Nokia

1.3 Mobifone traffic profiles
The Traffic profile from Mobifone as follows:
• % prepaid/postpaid subscribers: (90/10)%.

• % using DPI: 100%
• 2G/3G Traffic Mix (2016)
Table 3 – 2G/3G Traffic Mix in Mobifone Network
Traffic Mix (trs/ sub / BH) 2G 3G

GPRS Attach, combined GPRS/IMSI Attach 1.4 3.39
GPRS Detach, combined GPRS/IMSI Detach 0.65 0.21
PDP Context activation 1.18 0.58
PDP Context deactivation 0.61 0.39
PDP Context modification 0.23 0.1
3G PDP Context GTP endpoint modification - 20.14
Intra PAPU RAU no ctx 1.44 1.37
Inter PAPU RAU no ctx 3.56 1.76
Periodic RAU 0.14 0.11
Intra PAPU HO 0.49 0.79
Inter PAPU HO 1.72 0.91
Intra PAPU SRNS Relocation - 0.19
Inter PAPU SRNS Relocation - 0.17
Paging 0.95 3.85
Service request - 10.42
Iu release - 15.13
RAB assignment - 10.6
RAB release - 8.7
Average packet DL 642 490
Average packet UP 134 303
Table 4 – 4G Traffic Mix in Mobifone Network
Traffic Mix (trs/ sub / BH) 4G

Attach 0.38
Detach 0.04
Bearer activation 1.52
Bearer deactivation 0.22
Bearer modification 6.72
Mobility 26.38
Service request 59.16
S1- Release 58.88
CSFB 1.36
SMS Delivery 4.3
Total (transaction/bearer/hour) 158.96
LTE Bearer to SAU Ratio 1.4
12 / 136 © 2017 Nokia

1.4 Nokia solution
1.4.1 Delivery
1.4.1.1 Summary
Deliverables in Capacity Upgrading and Expanding hardware of GPRS System Phase 6 project include:
SGSN/MME:
1. Software & eSW Upgrading, Expand and Reconfigure of existing 8 FNS SGSN ATCA. (from SG8PCD4.4
and NS4.0CD3.0 to NS17)
2. Install 4 new FNS NS17.
3. Change mode to Triple Access (SGSN&MME).
4. Group FNS into pool for each site.
SAE-GW:
1. Install 6 new 7750-SR12-MG (8.R07, S-GW & P-GW).
Other Network Elements:
1. FMA Server: upgrade existing FMA for FNS.

2. NetAct: upgrade 1 existing node to version 16.8 and install 5620 SAM Mediation.
3. Traffica: upgrade 8 TNES and 1 TS to version 16, install 4 new TNES.
4. Flexi CMD: swap of existing Gen7 and Gen8 blades to 2 Gen9 server blades in active-standby, and
upgrade software to version 16.
5. Infoblox Trinzic: swap 2 new Gi-DNS and 2 new Gn-DNS (software level NIOS 7).
6. SAM: install 1 new node at software version 14.0 R5.
The proposed solution comprises of the following network elements:
Table 5 Offered Network Elements for the Proposed Solution
Network Functionality Nokia Product Name

SGSN/MME Flexi NS17
GGSN/SAE-GW 7750-SR12-MG 8.R07
Network Management System NetAct 16.8
Network Management System SAM 14.0 R5
Charging Flexi CMD16
Traffica Traffica version 16
Flexi Maintenance Application FMA NS 17
DNS Infoblox Trinzic NIOS 7
13 / 136 © 2017 Nokia

Table 6 List the existing and new network elements’ name and their location
Site Network Element Type Network Element Name Remark

Ha Noi – Yen Hoa FlexiNG#1 GG_FINGYHA01N Phase 5
7750SR-MG#1 EPG_MGYHA01N Phase 6, new
DXSGSN#1 SG_DXYHA01N Old DX200
FlexiNS#1 MME_ATYHA01N P5, old SG_ATYHA01N
FlexiNS#2 MME_ATYHA02N P5, old SG_ATYHA02N
TNES Server#1 TN_ATYHA01N Traffica Client
TNES Server#2 TN_ATYHA02N Traffica Client
FMA Server#1 OM_FMYHA1N
FMA Server#2 OM_FMYHA2N
SAM SAM_MGYHA01N Phase 6, new
CMD CG_YHA01N Phase 6, new
GnDNS GNDNS_YHA01N Phase 6, new
GiDNS GIDNS_YHA01N Phase 6, new
Ha Noi – Giap Bat FlexiNG#1 GG_FINGGBT01N Phase 4
7750SR-MG#1 EPG_MGGBT01N Phase 6, new
DXSGSN#1 SG_DXGBT01N Old DX200
FlexiNS#1 MME_ATGBT01N P5, old SG_ATGBT01N
Traffica Server #1 TNHNI_1N Traffica Server
TNES Server#1 TN_ATGBT01N Traffica Client
NetAct NA01
HCM – C30 FlexiNG#1 GG_FINGC3001N Phase 4
FlexiNG#2 GG_FINGC3002N Phase 4.5
7750SR-MG#1 EPG_MGC3001N Phase 6, new
7750SR-MG#2 EPG_MGC3002N Phase 6, new
DXSGSN#1 SG_DXC3001N Old DX200
FlexiNS#1 MME_ATC3001N P4.5, old SGHCM_3N
FlexiNS#2 MME_ATC3002N P5, old SG_ATC3002N
FlexiNS#3 MME_ATC3003N P5, old SG_ATC3003N
TNES Server#1 TN_ATC3001N Traffica Client
HCM – Q9 new site 7750SR-MG#1 EPG_MGQ0901N Phase 6, new
7750SR-MG#2 EPG_MGQ0902N Phase 6, new
FlexiNS#1 MME_ATQ0901N P5, old SG_ATHBT01N
FlexiNS#2 MME_ATQ0902N P5, old SG_ATHBT02N
FlexiNS#3 MME_ATQ0903N Phase 6, new
FlexiNS#4 MME_ATQ0904N Phase 6, new
TNES Server#1 TN_ATQ0901N Old TN_ATHBT01N
TNES Server#2 TN_ATQ0902N Old TN_ATHBT02N
TNES Server#3 TN_ATQ0903N Phase 6, new
TNES Server#4 TN_ATQ0904N Phase 6, new
GnDNS GNDNS_Q0901N Phase 6, new
GiDNS GIDNS_Q0901N Phase 6, new
CMD CG_Q0901N Phase 6, new
HCM - HBT DXSGSN#1 SG_DXHBT01N Old DX200
Da Nang - NVL DXSGSN#1 SG_DXDNG01N Old DX200
DXSGSN#2 SG_DXDNG02N Old DX200
DXSGSN#3 SG_DXDNG03N Old DX200 SG_DXHAP01N
FlexiNS#1 MME_ATADN01N Phase 6, new
FlexiNS#2 MME_ATNVL01N Phase 6, new
TNES Server#1 TN_ATADN01N Phase 6, new
TNES Server#2 TN_ATNVL01N Phase 6, new
Note: the text in Yellow highlight is new elements, in turquoise highlight is upgrade elements.
14 / 136 © 2017 Nokia

1.4.1.2 Flexi NS using AB3-B processing board (from Phase 4.5 and Phase 5)
• HCMC
 1100k 2G/3G subs requires 11 VMU
 400Mbps 2G throughput requires 4 GBU and 250Mbps Non-DT 3G throughput requires 2 IPPU
 220k LTE subs (10% VoTLE) requires 7 CPPU and 2 IPDU
 The total 1100+220k subs requires 3 MMDU pair -> 6 MMDU
• Hanoi
 700k 2G/3G subs requires 6 VMU
 400Mbps 2G throughput requires 4 GBU and 250Mbps Non-DT 3G throughput requires 2 IPPU
 180k LTE subs (10% VoTLE) requires 6 CPPU and 2 IPDU
 The total 700+180k subs requires 2 MMDU pair -> 4 MMDU
1.4.1.3 Flexi NS using 5A processing board (new in Phase 6)
 1100k 2G/3G subs requires 11 VMU, VMU includes GBU and IPPU which is enough for
 500Mbps 2G and 400Mbps 3G non-DT throughput.
 400k LTE subs (10% VoLTE) requires 8 CPPU and 2 IPDU at DaNang
 220k LTE subs (10% VoLTE) requires 6 CPPU and 2 IPDU at HCMC
 Total 1100+400 subs require 3 MMDU pair -> 6 MMDU
1.5 Mobifone radio coverage plan
The current radio plan for GSM/WCDMA coverage is depicted in below table. The coverage for pool will
update before cut-over.
1.5.1 The Radio Coverage of current network
Table 7 North Area
SGSN Vendor Attach Subs (ksub) Util Area

MMEMKXYHA01E Ericsson 127 25% Phía đông nội thành Hà Nội
SG_ATGBT01N Nokia 300 37% Hà Nam, Ninh Bình, Nam Định, Thanh Hoá, Nghệ An, Hà Tĩnh,
Quảng Bình
SG_ATYHA01N Nokia 534 59% Bắc Ninh, Bắc Giang, Hưng Yên, Thái Bình, Hải Dương, Hải
Phòng, Quảng Ninh
SG_ATYHA02N Nokia 369 46% Hà Nội (phần còn lại), Cao Bằng, Lạng Sơn, Hà Giang, Lào Cai,
Lai Châu, Điện Biên
SG_DXYHA01N Nokia 73 8% Hoà Bình, Sơn La, Yên Bái, Vĩnh Phúc, Phú Thọ, Bắc Cạn, Thái
Nguyên, Tuyên Quang
15 / 136 © 2017 Nokia

Table 8 South Area

SG_DXC3001N Nokia 440 37% Q8, H.CC, H.HM, H.BC
SG_DXHBT01N Nokia 193 18% H.NB, H.CG
SG_DXQ201N Nokia 223 28% Q9, Q.TĐ
SG_ATC3001N Nokia 298 50% Q.5, Q.6, Q.10, Q.11,
SG_ATC3002N Nokia 765 70% Q.TB, Q.TP, Q.BI, Q.GV, Q.12
SG_ATHBT01N Nokia 519 47% Q1, Q3, Q.PN, Q.BT
MMEMKXC3001E Ericsson 230 46% Q2, Q4, Q7, eNdoe B
SG_DXCTO01N Nokia 237 26% Bạc Liêu,Kiên Giang, Cà Mau, Hậu Giang, Sóc Trăng
SG_DXCTO02N Nokia 298 33% Tiền Giang, Bến Tre, Trà Vinh
SG_ATC3003N Nokia 695 63% Cần Thơ, An Giang, Đồng Tháp, Vĩnh Long
SG_DXDNI01N Nokia 210 14% Bình Phước, Bình Thuận, Ninh Thuận, Lâm Đồng
SG_ATHBT02N Nokia 1,128 75% Đồng Nai, BR-VT, Bình Dương, Tây Ninh, Long An
1.5.2 The Radio Coverage of target network
Table 9 North Area

MMEMKXYHA01E Ericsson
250 25% Nội thành Hà Nội
MMEMKXGBT01E Ericsson
MME_ATGBT01N Nokia
MME_ATYHA01N Nokia 1.150 55% Ngoại thành Hà Nội + các tỉnh phía bắc
MME_ATYHA02N Nokia
SG_DXYHA01N Nokia 0 0 Tách ra khỏi mạng
Table 10 South Area

MME_ATC3001N Nokia
MME_ATC3002N Nokia
MME_ATC3003N Nokia Đông Nam Bộ
MME_ATQ0901N Nokia 4390 57% Tây Nam Bộ
MME_ATQ0902N Nokia HCM (các quận còn lại)
MME_ATQ0903N Nokia
MME_ATQ0904N Nokia
MMEMKXC3001E Ericsson
820 41% HCM (Q.1, 2, 3, 5, 10, PN, 4, 7)
MMEMKXQ901E Ericsson
SG_DXC3001N Nokia
SG_DXHBT01N Nokia
SG_DXQ201N Nokia
0 0 Tách ra khỏi mạng
SG_DXCTO01N Nokia
SG_DXCTO02N Nokia
SG_DXDNI01N Nokia
16 / 136 © 2017 Nokia

1.5.3 The target service pooling coverage per area for each vendor
Table 11 North Area – Ericsson
SAE-GW SGSN/MME MSC RNC BSC

EPG_SSR_YHA01E MMEMKXYHA01E MSHN01E RHNCG1E BHNCG1E
EPG_SSR_GBT01E MMEMKXGBT01E MSHN02E RHNHM1E BHNHM1E
MSDN01H BHNHM2E
MSDN02H
Table 12 North Area – Nokia

EPG_MGYHA01N MME_ATYHA01N MSHN01E MBHDHD1H BAC_GIANG_1 MBHDHD2H
EPG_MGGBT01N MME_ATYHA02N MSHN02E MBHDHD2H BAC_GIANG_2 MBHPHA1H
MME_ATGBT01N MSDN01H MBHPHA1H BAC_KAN_1 MBHPHA2H
MSDN02H MBHPHA2H BAC_NINH_1 MBHPHA3H
MSSHN01H MBHPHA3H BAC_NINH_2 MBHPHA4H
MSSHN02H MBHPHA4H BNDND1H MONG_CAI_1
RHNCG1H BQNHL1E MY_DUC
RHNCG2H BSC_DIEN_CHAU NAM_DINH_2
RHNCG3H BSC_DUC_THO NAM_DINH_3
RHNCG4H BSC_HAM_RONG NINH_BINH_1
RHNHM2H BSC_HA_TINH_2 NINH_BINH_2
RHNHM3H BSC_NGHE_AN_2 QUANG_NINH_3
RHNHM4H BSC_NGHE_AN_3 QUANG_NINH_4
RHNHM5H BSC_QUANG_BINH_1 SON_LA_1
RHTHT1H BSC_QUANG_BINH_2 SON_TAY_1
RNAVI1H BSC_THANH_HOA_3 SON_TAY_2
RNDND1H BSC_TRIEU_SON THAI_NGUYEN_1
RQBDH1H CAM_PHA_1 THAI_NGUYEN_2
RQNUB1H CAO_BANG_2 TUYEN_QUANG_2
iHNCG1H DIEN_BIEN_1 UONG_BI_1
iHNCG2H GIAP_BAT_4 UONG_BI_2
iHNCG3H HA_GIANG_1 VIET_TRI_2
iHNDD1H HA_NAM_1 VIET_TRI_3
iHNHM1H HA_NAM_2 VINH_PHUC_1
iHNHM2H HA_TAY_1 VINH_PHUC_2
iHNHM3H HOA_BINH_1 YEN_BAI_1
HUNG_YEN_1 YEN_HOA_2
HUNG_YEN_2 iHNCG1H
LAI_CHAU iHNCG2H
LANG_SON_1 iHNCG3H
LANG_SON_2 iHNDD1H
LAO_CAI_1 iHNHM1H
MBHDHD1H iHNHM2H
iHNHM3H
17 / 136 © 2017 Nokia

Table 13 Midle Area – Nokia

EPG_MGYHA01N MME_ATADN01N MSDN01H RBDQN1N BDAN05E BGLA06A
EPG_MGGBT01N MME_ATNVL01N MSDN02H RDLBT1N BDAN06E BGLA07A
MSDN02E RDNST1N BDAN08E BGLA08A
RDNST2N BDAN09E BGLA09A
RDNST3N BDAN10E BHUE01H
RDNST4N BDLK04A BHUE03E
RDNST5N BDLK05A BHUE04H
RDNST6N BDLK08A BKHNT01N
RDNST7N BDLK09A BKHNT02N
RDNST8N BDLK10A BKTM02A
RDNST9N BDLK11A BKTM04A
RDNTK1N BDLK12A BKTM05A
RGLPK1N BDLK13A BPYPY01N
RKHNT1N BDNG01A BPYPY02N
RQTDH1N BDNG02A BQNH03E
BDNG04A BQNH04E
BDNG05A BQNI03E
BGLA03A BQNM01E
BGLA04A BQNM02E
BGLA05A BQTI01H
BQTI02H
Table 14 South Area – Ericsson

EPG_SSR_C3001E MMEMKXC3001E MSHC01E RSG012E BSG011E
EPG_SSR_Q901E MMEMKXQ901E MSHC02E RSG021E BSG013E
MSHC03E RSG031E BSG021E
RSG101E BSG032E
BSG041E
BSG051E
BSG052E
BSG071E
BSG101E
BSG102E
BSGPN1E
18 / 136 © 2017 Nokia

Table 15 South Area – Nokia

EPG_MGC3001N MME_ATC3001N MSHC01E RBDTM1N RLDDA1E BAGG01E BDNLT1N BSGBI3E
EPG_MGC3002N MME_ATC3002N MSHC02E RBDTM2N RNTPR1E BAGG02E BDNTN2A BSGBT1E
EPG_MGQ0901N MME_ATC3003N MSHC03E RBDTM3N RSG061E BAGG03E BDNTP2A BSGBT2E
EPG_MGQ0902N MME_ATQ0901N MSHC04E RBLBL1Z RSG091E BBDBC2A BDNXL1A BSGCC1N
MME_ATQ0902N MSHC05E RBLBL2Z RSG111E BBDDT2A BDTP01E BSGGV1N
MME_ATQ0903N MSDNI01H RBPDX1N RSG121E BBDPG1A BDTP02E BSGHM1N
MME_ATQ0904N MSDNI02H RBTPT1E RSGBC2E BBDTA1N BDTP03E BSGNB2E
MSDNI03H RCMCM1Z RSGBI2E BBDTM1N BDTP04E BSGTB1E
MSDNI04H RCMCM2Z RSGBT1E BBLU01Z BHGG01E BSGTB3E
MSDNI05H RCTNK10N RSGGV1E BBLU04Z BKGG02E BSGTD1E
MSCT02H RCTNK11N RSGHM1E BBPBL1A BKGG05Z BSGTP1E
MSCT03H RCTNK1N RSGNB1E BBPDX1A BKGG06Z BSGTP2E
MSTG01H RCTNK2N RSGTB2E BBPGM1A BLABL1H BSTG02H
MSTG02H RCTNK3N RSGTD1E BBPLN1A BLATA1H BSTG03H
MSCT04H RCTNK4N RSGTP1E BBTE02H BLATA2H BSTG04H
MSCT05H RCTNK9N RSTST1Z BBTE03H BLATA3H BTGG01H
RDNBH1N RSTST2Z BBTE04H BLDBA1A BTGG02H
RDNBH2N RSTST3Z BBTHT2A BLDBL1A BTGG03H
RDNBH3N RTGMT1N BBTLG1A BLDDA1A BTGG04H
RDNBH4E RTGMT2N BBTPT2A BLDDD1A BTGG05H
RKGRG1Z RTGMT3N BBTTL2A BLDDL1A BTNCT1A
RKGRG4Z RTNTN1N BBTTN2A BLDDT1A BTNDM1A
RLATA1N RVLLH1N BBTTP1A BNTNH1A BTNTB1A
RLATA2N RVTVT1N BCMU01Z BNTNP1A BTNTC1A
RVTVT2N BCMU04Z BNTNS2A BTNTN1A
BCMU05Z BNTPR1A BTVH01H
BCTO02E BSG061E BTVH02H
BCTO03E BSG081E BTVH03H
BCTO04E BSG092E BVLG01E
BCTO05E BSG111E BVLG02E
BCTO06E BSG121N BVLG03E
BCTO08E BSGBC1E BVTBR1N
BDNBH1N BSGBC2E BVTVT1N
BDNBH2N BSGBI1E BVTVT2N
BDNBH3N BSGBI2E BHUE05H
1.6 Naming convention
Table 16 Node name rule example
EPG_MGHBT01N Fullname
EPG Node function
MG Platform
Q09 Building location
01 Node order
N Vendor
19 / 136 © 2017 Nokia

2 Network architecture
2.1 Network layers
Figure 1 Network topology Multilevel of Northern area currently
SERVICE LAYER
MCA SMS C INH N04A INH N06A
BGM VOICE MAIL INH N05A INH N07A INT ERNATIONAL INT ERNATIONAL
OPERATOR PEERING
HTC
CALL CENTER CP RBT INH NT2A
OTHER
NATIONAL NATIONAL
OPERATOR OPERATOR PEERING
CACHING NTP
CP TELEVISION NATIONAL OPERATOR VAS IN HN SYSTEM SERVER
GATEWAY LAYER Centralize at HN1&2 with 1+1 model
GIÁP BÁT GIÁP BÁT GIÁP BÁT GIÁP BÁT GIÁP BÁT
BG BG
FW
STPHN1E STP HN2E GSH N01H FISNHNI1N FISNHNI2N EPG_SSR_GBT01E
NATIONAL INTERNATIONAL
PEERING PEERING
YÊN HÒA YÊN HÒA YÊN HÒA
YÊN HÒA GG_FINGGBT 01N
BG BG
STPHN3E STP HN4E GSH N02H YÊN HÒA EPG_SSR_YHA01E
FW
PEERING PEERING
GG_FINGYHA01N
STP GT-MSC BORDER GW GGSN S/PGW
SWITCHING LAYER Centralize at HN1&2 with 1+1 model
GIÁP BÁT GIÁP BÁT AN ĐỒN GIÁP BÁT GIÁP BÁT YÊN HÒA
MSH N01H MSH N01E MSC_ANDON MMEM KXGBT01E SG_ATGBT01N SG_DXYH A01N

SG_ATYHA01N
MSH N02H MSH N02E MMEM KXYHA01E
SG_ATYHA02N
POOL MSC POOL MSC POOL MME SGSN
HUAWEI ERICSSON ERICSSON NOKIA
4.6M 1M SAU 3M
TRANSPORT LAYER
2 MGW 3 MGW 3 MGW
TRANSMISSION TRANSMISSION TRANSMISSION
HẢI PHÒNG HN1 – GIÁP BÁT HN2 – YÊN HÒA
ACCESS LAYER
BSC/RNC BSC/RNC BSC/RNC BSC/RNC BSC/RNC
BTS/NodeB/eNodeB BTS/NodeB/eNodeB BTS/NodeB/eNodeB BTS/NodeB/eNodeB BTS/NodeB/eNodeB
1,099K 157K 417K 417K 203K

Nam Định, Hải Phòng, Hải Hà Nam, Ninh Bình Thanh Hóa, Nghệ An, Hà Thanh Hóa, Nghệ An, Hà Bắc Ninh, Bắc Giang, Cao
Dương, Thái Bình, Hưng Yên, Tĩnh, Quảng Bình Tĩnh, Quảng Bình Bằng, Bắc Cạn, Lạ ng Sơn, Hà
Quả ng Ninh Giang, Tuyên Quang, Thái Nguyên
20 / 136 © 2017 Nokia

Figure 2 Network topology Multilevel of Northern area after project
SERVICE LAYER
OPERATOR PEERING
HTC
OTHER
NATIONAL NATIONAL
CACHING NTP
GATEWAY LAYER Centralize at HN1&2 with 1+1 model
GIÁP BÁT GIÁP BÁT GIÁP BÁT GIÁP BÁT GIÁP BÁT GIÁP BÁT
BG BG
FW
STPHN1E STP HN2E GSH N01H FISNHNI1N FISNHNI2N EPG_SSR_GBT01E EPG_M GGBT01N
NEW
PEERING PEERING
YÊN HÒA YÊN HÒA YÊN HÒA YÊN HÒA
YÊN HÒA GG_FINGGBT 01N
BG BG
STPHN3E STP HN4E GSH N02H EPG_SSR_YHA01E EPG_M GYHA01N
FW YÊN HÒA NEW
PEERING PEERING
GG_FINGYHA01N
SWITCHING LAYER Centralize at HN1&2 with 1+1 model
GIÁP BÁT GIÁP BÁT AN ĐỒN GIÁP BÁT GIÁP BÁT YÊN HÒA
MSH N01H MSH N01E MSC_ANDON MMEM KXGBT01E MME_ATGBT01N SG_DXYH A01N
UPGRADE

MME_ATYHA01N
UPGRADE
MSH N02H MSH N02E MMEM KXYHA01E
MME_ATYHA02N
POOL MSC POOL MSC POOL MME UPGRADE
HUAWEI ERICSSON ERICSSON POOL SGSN/MME
4.6M 1M SAU NOKIA 2.1M/210K
TRANSPORT LAYER
2 MGW 3 MGW 3 MGW
TRANSMISSION TRANSMISSION TRANSMISSION
HẢI PHÒNG HN1 – GIÁP BÁT HN2 – YÊN HÒA
ACCESS LAYER
BSC/RNC BSC/RNC BSC/RNC BSC/RNC BSC/RNC
BTS/NodeB/eNodeB BTS/NodeB/eNodeB BTS/NodeB/eNodeB BTS/NodeB/eNodeB BTS/NodeB/eNodeB
1,099K 157K 417K 417K 203K

Nam Định, Hải Phòng, Hải Hà Nam, Ninh Bình Thanh Hóa, Nghệ An, Hà Thanh Hóa, Nghệ An, Hà Bắc Ninh, Bắc Giang, Cao
Dương, Thái Bình, Hưng Yên, Tĩnh, Quảng Bình Tĩnh, Quảng Bình Bằng, Bắc Cạn, Lạ ng Sơn, Hà
Quả ng Ninh Giang, Tuyên Quang, Thái Nguyên
21 / 136 © 2017 Nokia

Figure 3 Network topology Multilevel of Middle area currently
SERVICE LAYER
OPERATOR PEERING
HTC
OTHER
NATIONAL NATIONAL
CACHING NTP
GATEWAY LAYER
2 STP
STP
SWITCHING LAYER
QUẢN G TRỊ TÂY NGUYÊN QUẢNG NAM TÂY NGUYÊN QUẢNG TRỊ
KHÁNH HÒA KHÁNH HÒA ĐÀ NẴNG
SG_DXDNG1N SG_DXDNG2N SG_DXDNG3N
POOL MSC POOL MSC SGSN

HUAWEI ERICSSON NOKIA
3M SUB 500k SUB
TRANSPORT LAYER
4 MGW-H 1 MGW-E
TRANSMISSION TRANSMISSION
QUẢNG TRỊ - KHÁNH HÒA TÂY NGUYÊN
ACCESS LAYER
BSC/RNC
BTS/NodeB/eNodeB
3,5M SUB VLR

MIỀN TRUNG
22 / 136 © 2017 Nokia

Figure 4 Network topology Multilevel of Middle area after project
SERVICE LAYER
OPERATOR PEERING
HTC
OTHER
NATIONAL NATIONAL
CACHING NTP
GATEWAY LAYER
2 STP
STP
SWITCHING LAYER
QUẢN G TRỊ TÂY NGUYÊN QUẢNG NAM TÂY NGUYÊN QUẢNG TRỊ NEW
KHÁNH HÒA KHÁNH HÒA ĐÀ NẴNG
MME_ATNVL01N
SG_DXDNG1N SG_DXDNG2N SG_DXDNG3N NEW
MME_ATADN01N
POOL MSC POOL MSC SGSN POOL SGSN/

HUAWEI ERICSSON NOKIA MME NOKIA
3M SUB 500k SUB 2.2M/300K
TRANSPORT LAYER
4 MGW-H 1 MGW-E
TRANSMISSION TRANSMISSION
QUẢNG TRỊ - KHÁNH HÒA TÂY NGUYÊN
ACCESS LAYER
BSC/RNC
BTS/NodeB/eNodeB
3,5M SUB VLR

MIỀN TRUNG
23 / 136 © 2017 Nokia

Figure 5 Network topology Multilevel of Southern area currently
SERVICE LAYER
MCA SMS C HCM-C30 HCM-C30 HCM-C30
BGM VOICE MAIL HCM-Q09 HCM-Q09 HCM-Q09 INT ERNATIONAL INT ERNATIONAL
OPERATOR PEERING
HTC
CALL CENTER CP RBT
OTHER
NATIONAL NATIONAL
CACHING NTP
CP TELEVISION NATIONAL OPERATOR VAS IN HCM SYSTEM SERVER
GATEWAY LAYER
HCM-C30 HCM-HBT HCM-C30 HCM-Q09 HCM-C30 2 FISN HCM-C30

BG BG
FW
INT ER S TP INT ER S TP INT ER GT INT ER GT FISNHCM1N FISNHCM2N EPG_SSR_C3001E
PEERING PEERING
4 FNG HCM-Q09
INT RA STP INT RA STP INT RA GT INT RA GT HCM-HBT
BG BG
FNGC301N FNGC302N EPG_SSR_Q901E
FW
EAGLE S TP EAGLE S TP
PEERING PEERING
FNGHBT1N FNGHBT2N
SWITCHING LAYER
WESTERN HCM EASTERN HCM-Q09 HCM-C30 HCM-HBT
MMEM KXQ901E MME_ATC3001N MME_ATQ0901N
HCM-C30 MME_ATC3002N MME_ATQ0902N
MMEM KXC3001E MME_ATC3003N

6 MSC-H 5 MSC-E 5 MSC-H 5 SGSN DX200
POOL MME SGSN DX200 SGSN ATCA

POOL CS HUAWEI POOL CS ERICSSON POOL CS ERICSSON
ERICSSON NOKIA NOKIA
3.5/8M SUB 5.5/11.8M SUB 3.3/7M SUB
2M SAU 0.8M SUB 6M SUB
TRANSPORT LAYER
3 MGW-H 4 MGW-H 6 MGW-E 4 MGW-E 3 MGW-H 4 MGW-H
TRANSMISSION TRANSMISSION TRANSMISSION TRANSMISSION TRANSMISSION TRANSMISSION
TIỀN GIANG CẦN THƠ HCM-C30 HCM-HBT ĐỒNG NAI BÌNH DƯƠNG
ACCESS LAYER
BSC/RNC BSC/RNC BSC/RNC
BTS/NodeB/eNodeB BTS/NodeB/eNodeB BTS/NodeB/eNodeB
3,5M SUB VLR 5,5M SUB VLR 3,3M SUB VLR

12 W estern provinces Hồ Chí Minh city 9 Eastern provinces
24 / 136 © 2017 Nokia

Figure 6 Network topology Multilevel of Southern area after project
SERVICE LAYER
MCA SMS C HCM-C30 HCM-C30 HCM-C30
BGM VOICE MAIL HCM-Q09 HCM-Q09 HCM-Q09 INT ERNATIONAL INT ERNATIONAL
OPERATOR PEERING
HTC
CALL CENTER CP RBT
OTHER
NATIONAL NATIONAL
CACHING NTP
CP TELEVISION NATIONAL OPERATOR VAS IN HCM SYSTEM SERVER
GATEWAY LAYER
HCM-C30 HCM-HBT HCM-C30 HCM-Q09 HCM-C30 2 FISN HCM-C30

BG BG
FW
INT ER S TP INT ER S TP INT ER GT INT ER GT FISNHCM1N FISNHCM2N EPG_SSR_C3001E EPG_M GC3001N EPG_M GC3002N
NEW NEW
PEERING PEERING
4 FNG HCM-Q09
INT RA STP INT RA STP INT RA GT INT RA GT HCM-HBT
BG BG
FNGC301N FNGC302N EPG_SSR_Q901E EPG_M GQ0901N EPG_M GQ0902N
FW NEW NEW
EAGLE S TP EAGLE S TP
PEERING PEERING
FNGHBT1N FNGHBT2N
SWITCHING LAYER
WESTERN HCM EASTERN HCM-Q09 HCM-C30 HCM-Q09
NEW
MMEM KXQ901E MME_ATC3001N MME_ATQ0901N MME_ATQ0903N
HCM-C30 NEW
MME_ATC3002N MME_ATQ0902N MME_ATQ0904N
MMEM KXC3001E MME_ATC3003N

6 MSC-H 5 MSC-E 5 MSC-H 5 SGSN DX200
POOL MME SGSN DX200 SGSN ATCA

POOL CS HUAWEI POOL CS ERICSSON POOL CS ERICSSON
ERICSSON NOKIA NOKIA
3.5/8M SUB 5.5/11.8M SUB 3.3/7M SUB
2M SAU 0.8M SUB 6M SUB
TRANSPORT LAYER
3 MGW-H 4 MGW-H 6 MGW-E 4 MGW-E 3 MGW-H 4 MGW-H
TRANSMISSION TRANSMISSION TRANSMISSION TRANSMISSION TRANSMISSION TRANSMISSION
TIỀN GIANG CẦN THƠ HCM-C30 HCM-HBT ĐỒNG NAI BÌNH DƯƠNG
ACCESS LAYER
BSC/RNC BSC/RNC BSC/RNC
BTS/NodeB/eNodeB BTS/NodeB/eNodeB BTS/NodeB/eNodeB
3,5M SUB VLR 5,5M SUB VLR 3,3M SUB VLR

12 W estern provinces Hồ Chí Minh city 9 Eastern provinces
25 / 136 © 2017 Nokia

2.2 Logical topology
Figure 7 Logic topology
PCRF AAA
eNodeB
GAT EWAY
Iuu Gi, SGi
Mult ipoint Iu
In ternet
HA NOI
NodeB RN C
SGS N/MME
BTS BSC SAM

HLR/H SS
Gr
S13
STP DRA EIR MSC Gn-DN S NetAct TRAFFICA CG

S13
MSC
eNodeB
SGS N/MME
DA NANG
NodeB RN C
Traffica
TRAFFICA
BTS BSC
STP DRA Gn-DN S MSC TRAFFICA CG

Gr
HLR/H SS
HCM
BTS BSC SGS N/MME
GAT EWAY
Mult ipoint Iu
Iuu Gi, SGi
NodeB RN C In ternet
eNodeB
AAA PCRF
26 / 136 © 2017 Nokia

2.3 Physical topology
Figure 8 Target Mobifone Packet Core Network in Phase 6 Upgrading and Expanding
MME_ATYHA02N GG_FINGYHA01N GNDNS_YHA01N GIDNS_YH A01N DNG - NVL DNG - AN DON CG_Q0901N TN_ ATQ0901N TN_ ATCQ0902N TN_ ATQ0903N TN_ ATQ0904N
MME_ATYHA01N
MME_ATNVL01N MME_ATADN01N TN_ ATADN01N TN_ ATNVL01N
EPG_M GQ0902N
EPG_M GYHA01N
GNDNS_Q0901N
TN_ ATYH A01N
CG_YHA01N
PE_ASR9010_ NVL01C/02C
HA NOI - YEN HOA
New_SW
PE_ASR9010_ ADN 01C/02C New_SW
SW2960 40Gb
HCM – Q9
ps
P_ASR9010Q0901C/02C GIDNS_Q0901N
New_SW
SAM_MGYH A01N
EPG_M GQ0901N
P_ASR9010_NVL01C/02C
TN_ ATYH A02N
PE_7609YH A01C/02C 60Gb

ps
P_ASR9010_ADN 01C/02C PE_ASR9010Q0903C/04C
PE_ASR9010YH A01C/02C
TSH NI_1N OM_FMYH A1N OM_FMYH A2N
TRAFFICA_ SERVER FMA_ FNG FMA_ FNS PCRF MME_ATQ0901N MME_ATQ0902N MME_ATQ0903N MME_ATQ0904N
P_ASR9010YHA01C/02C
@COM OneAAA OneDNS WPH NI_1N MME_ATC3002N MME_ATC3003N MME_ATC3001N
PCRF
Intersite
TN_ ATC3003N
NetAct
Connection
NA01
PE_7609G BT01C/2C P_ASR9010C3001C/02C PE_ASR9010C3003C/04C

HA NOI – GIAP BAT
HCM – C30
P_ASR9010GBT01C/02C
TN_ ATC3002N
TNES HNI_1N
SW4948 PE_ASR9010C3005C/06C
SW_ pcsswh cm1/2

OAM
PE_ASR9010G BT01/02C
TN_ ATC3001N
MME_ATGBT01N GG_FINGGBT01N EPG_M GGBT01N
EPG_M GC3001N EPG_M GC3002N OneAAA OneDNS
New install Upgrade No touch
27 / 136 © 2017 Nokia

3 Network design
3.1 Capacity
3.1.1 SAE-GW
Below table shows Mobine 7750 MG requirements per nodes at each side.
Table 17 Mobifone Capacity Requirements
Location Node Hostname kpdpctx/kbearer Thp(Gbps)

Hanoi SAE-GW EPG_MGYHA01N 1400k 40
Hanoi SAE-GW EPG_MGGBT01N 1400k 40
Ho Chi Minh SAE-GW EPG_MGQ0901N 1400k 60
Ho Chi Minh SAE-GW EPG_MGQ0902N 1400k 40
Ho Chi Minh SAE-GW EPG_MGC3001N 1400k 60
Ho Chi Minh SAE-GW EPG_MGC3002N 1400k 40
3.1.2 Upgrade Flexi NS
The table shows capacity requirement of the upgrade Flexi NS SGSN in Phase 6.
Table 18 Upgrade Flexi NS Capacity Requirement
2G Thp SW 2G Thp HW 3G Thp SW LTE ksub New LTE ksubs

Site Node name 2G/3G sub PDP Ctx
(Mbps) (Mbps) (Mbps) HW SW
Hanoi MME_ATYHA01N 700,000 490,000 300 500 250 180 70
Hanoi MME_ATYHA02N 700,000 490,000 300 500 250 180 70
Hanoi MME_ATGBT01N 700,000 490,000 300 500 250 180 70
HCMC MME_ATC3001N 1,100,000 770,000 300 500 250 220 70
HCMC MME_ATC3002N 1,100,000 770,000 300 500 250 220 70
HCMC MME_ATC3003N 1,100,000 770,000 300 500 250 220 70
HCMC MME_ATQ0901N 1,100,000 770,000 300 500 250 220 70
HCMC MME_ATQ0902N 1,100,000 770,000 300 500 250 220 70
Table 19 Upgrade Flexi NS Configuration
Node #Shelf AHUB OMU MCHU MMDU IPDU CPPU VMU

MME_ATC3001N 3 6 2 2 6 2 7 11
MME_ATC3002N 3 6 2 2 6 2 7 11
MME_ATC3003N 3 6 2 2 6 2 7 11
MME_ATQ0901N 3 6 2 2 6 2 7 11
MME_ATQ0902N 3 6 2 2 6 2 7 11
MME_ATYHA01N 3 6 2 2 4 2 6 6
MME_ATYHA02N 3 6 2 2 4 2 6 6
MME_ATGBT01N 3 6 2 2 4 2 6 6
28 / 136 © 2017 Nokia

3.1.3 New Flexi NS
The table shows capacity requirement of the new Flexi NS SGSN in Phase 6.
Table 20 New Flexi NS Capacity Requirement
2G Thp SW 2G Thp HW 3G Thp LTE New LTE

Site Node name 2G/3G Ksub PDP Ctx
(Mbps) (Mbps) SW (Mbps) Ksub HW Ksubs SW
DaNang MME_ATNVL01N 1,100,000 770,000 500 500 250 400 150
DaNang MME_ATADN01N 1,100,000 770,000 500 500 250 400 150
HCMC MME_ATQ0903N 1,100,000 770,000 300 500 250 220 70
HCMC MME_ATQ0904N 1,100,000 770,000 300 500 250 220 70
Table 21 New Flexi NS Configuration
Node #Shelf AHUB OMU MCHU MMDU IPDU CPPU VMU

MME_ATNVL01N 3 6 2 2 6 2 8 11
MME_ATADN01N 3 6 2 2 6 2 8 11
MME_ATQ0903N 3 6 2 2 6 2 6 11
MME_ATQ0904N 3 6 2 2 6 2 6 11
3.1.4 CMD
With the new capabilities of Gen 9 blades, given 10 Busy Hour a day, the total capacity of offered system
can scale up to 1512M CDRs per day (42000 CDR/s * 10 Busy Hours * 3600s).
• Hanoi Site: SW capacity of 342M CDRs per day

• HCMC Site: SW capacity of 436M CDRs per day
3.1.5 DNS
Table 22 DNS capacity
Site Trinzic 2220 Trinzic 1420

Gn-DNS Gi-DNS
DNS Queries per Seconds* 143,000 50,000
DHCP Leases per Seconds 600 300
Hardware Redundancy Hot swappable redundant power Optional second power supply, hot
supplies, fans and four disks RAID-10 swappable, redundant. Field
replaceable hard-disk
* The stated performance numbers were derived in an Infoblox test environment. Actual performance in live production
environments may be different.
29 / 136 © 2017 Nokia

3.2 Hardware
3.2.1 Overview
The following network elements (NE) will be installed as part of the project:
Table 23 Nodes Inventory
SW Quantity
Product HW Scope Function
Release HN DNG HCM
SGSN&MME
Flexi NS (modernize DX SGSN) 17 0 2 2 ATCA 4 New
pool in each site
7750-SR12-MG 8R07 2 0 4 7750-SR12 New S-GW and P-GW
FMA Server 2 DL380 SW Upg Troubleshooting for FNS
SGSN and MME
Flexi NS Ph5, Ph4.5 17 3 0 5 ATCA 8 Upg/Exp/Reconfig
pool in each site
5620 SAM 14.0R5 1+1 DL380 G9 New EMS for 7750SR
Charging Collection
Flexi CMD 16 1 1 DL380/EMC VNX SW upg/HW swap
Function, Offline
Monitoring/Reporting for
Traffica (Server & TNES) 16 3/1 TS 2 7 DL360 Gen9 New 4/Upg 8 an TS
FNS
OSS for Flexi NS, CMD,.. and
NetAct 16.8 1 HP Blade Upg and EPC license
SAM PM/FM integration
Infoblox Trinzic NIOS 7 2+2 2+2 Trinzic New Gn/S5 DNS and Gi/SGi DNS
3.2.2 SAE-GW
Mobifone is building up its LTE network and accelerating data service business with 4G . Mobifone will be
installing 6x7750 MG Combo S/PGW/GGSN at two sites which are Hanoi and Ho Chi Minh.
There are 6 7750 SR-12 MG hardware will be deployed for Mobifone project
• Hanoi : 2 x 7750 SR-12 MG

• Ho Chi Minh : 4 x 7750 SR-12 MG
Below table shows the BoQ data of the 6 x 7750 SR-12 MG nodes per sites.
Table 24 7750MG hardware
HN FNG/7750 HCM FNG /7750 HN 7750 HCM 7750

Card /SFP
MG Swap MG Swap MG new MG new
QTY QTY QTY QTY
BNDL -7750 SR-12 Chassis + SFM5/CPM5 1 2 1 2
SFM – 7750 SR SFM5-12 + CPM5 1 2 1 2
7750 SR Mobile Gateway ISM-MG-C 5 10 5 10
IMM – 7x50 12-PT 10GE FP3 SFP+ - L3HQ 2 4 2 4
SFP+ 10GE LR – LC ROHS6/6 0/70C 10 20 10 36
Figure 9: Global deployment architecture.
30 / 136 © 2017 Nokia

HA NOI
7750MG
HO CHI MINH
7750MG
31 / 136 © 2017 Nokia

Below figure shows the card positioning of 7750 SR-12 MG .Each 7750 MG node will be deployed with below
card configuration . Mobifone 7750 MG SGW/PGW/GGSN nodes are grouped in a single chassis combo
gateway built on the following model.
Figure 10: 7750 SR-12 MG Hardware
“IMM - 7750 12-PT 10GE FP3 SFP+ - L3HQ”

slot 5-6
7750 SR-12
Ser vic e Router
1 2 3 4 5 A SFM B SFM 6 7 8 9 10
Pwr
Stat
Pwr
Stat
Pwr
Stat
Pwr
Stat
Pwr
Stat
7750 SR CMP5 7750 SR CMP5
Reset Reset
“MG-ISM:ISA-MG”
Pwr
Stat
Media
Pwr
Stat
Media
Link
Link
ME1-ISA2-MS
ME1-ISA2-MS
ME1-ISA2-MS
ME1-ISA2-MS
ME1-ISA2-MS
Mgmt
Mgmt
slot 1-2-3-4-7 Data
Data
Lnk
Lnk
Act
Act
PORT 1
PORT 1
Lnk
Lnk
Act
Act
PORT 2
PORT 2
BITS
BITS
Lnk
Lnk
Act
Act
PORT 3
PORT 3
Lnk
Lnk
Act
Act
PORT 4
PORT 4
Compact Flash # 1
Compact Flash # 2
Compact Flash # 1
Compact Flash # 2
Lnk
Lnk
Act
Act
PORT 5
PORT 5
Pwr
Stat
Pwr
Stat
MG ISM MG ISM MG ISM MG ISM MG ISM
Pwr
Stat
Pwr
Stat
Pwr
Stat
Lnk
Lnk
Act
Act
PORT 6
PORT 6
Lnk
Lnk
Act
Act
Compact Flash # 3
Compact Flash # 3
PORT 7
PORT 7
“MG-ISM:ISA-AA”
AUX
AUX
Lnk
Lnk
Act
Act
PORT 8
PORT 8
slot 1-2-3-4-7
DCE
DTE
DCE
DTE
Lnk
Lnk
Act
Act
ME1-ISA2-MS
ME1-ISA2-MS
ME1-ISA2-MS
ME1-ISA2-MS
ME1-ISA2-MS
PORT 9
PORT 9
Console
Console
Lnk
Lnk
Act
Act
PORT 10
PORT 10
Alarm
Alarm
Lnk
Lnk
Act
Act
PORT 11
PORT 11
ACO /LT
ACO /LT
Lnk
Lnk
Act
Act
PORT 12
PORT 12
IMM12-10GB-SFP
IMM12-10GB-SFP
Stat
Card
Stat
Card
1 2 3 4 5 A SFM B SFM 6 7 8 9 10
50-0100-01 REV 1
“SFM - 7750 SR SFM5-12 + CPM5"
Slot Card
1 7750 SR Mobile Gateway ISM-MG-C (ISA-MG:ISA-AA)
5 IMM – 7x50 12-PT 10GE FP3 SFP+ - L3HQ
Slot A SFM – 7750 SR SFM5-12 + CPM5
Slot B SFM – 7750 SR SFM5-12 + CPM5
6 IMM – 7x50 12-PT 10GE FP3 SFP+ - L3HQ
8
9
10
32 / 136 © 2017 Nokia

• Two SF / CPM cards for Control processing and Switch Fabric. One is active, one is standby.
• Two IMM boards supporting 12 ports -10GE are positioned in slots 5 and 6.
• The MG-ISM cards are positioned in slots 1-2-3-4-7
 Each MG-ISM contains 2 ISA cards.
• One is configured as ISA-MG (Mobile-gateway)
• One is configured as ISA-AA (DPI and Firewalling)
The MG-ISM cards are configured in 5 non-redundancy group since all the the cards will be working as Active
mode.
• The all ISA-MG cards are running in active/active mode.

• Using the MG-ISM in 1+1 Redundancy Mode the Control Plane and Data Plane states of
active MG-ISM are replicated in the standby to be a hot standby MG-ISM. Active/Active is
done only in cases whereby scaling has been an issue.
SGW and PGW/GGSN run on the same ISA-MG cards. The ISA-AA are configured in one AA group for DPI
functionality and all ISA-AA will be working active. All ISA-AA will be configured as primary in AA group.
3.2.3 SGSN/MME
With success access (2G/3G/LTE), application architecture of the SGSN/MME consists of:
• MME functions
• SGSN functions
• shared functions, such as O&M functions, Diameter, subscriber database, and functions related to
statistics, lawful interception, Traffica and trace
The application software architecture consist of the following components.
There are new units for 4G traffic:
• MMDU function: The Mobility Management and Database Unit (MMDU) stores visiting subscriber
information into the visiting subscriber database (2G/3G/LTE). Italso controls the EPS mobility
management (EMM) or EPS session management (ESM) level functions for LTE subscribers. The
MMDU is N+ redundant.
• CPPU function: The Control Plane Processing Unit (CPPU) executes the LTE control plane signaling
under the supervision of the MMDU. The CPPU is N+ redundant.
• IPDU function: While Diameter transactions are handled by the MMDU, the externally visible IP
interfaces are provided by the IPDU which takes care of load balancing by sending Diameter
messages to active MMDUs. GTP, NAS and S1AP/LCS-AP transactions are handled by the CPPU, and
the externally visible IP interfaces are provided by the IPDU. For SBc, both SbcAP transactions and
the external interface are in the IPDU. The IPDUs are deployed as one or two recovery groups
depending on the hardware configuration, and each group is N+1 redundant. Thus, in a multishelf
MME configuration, the second IPDU group (IPDU-2 and IPDU-3), works according to the same high
availability mechanism as the first group. Traffic load is balanced between the two IPDU groups by
configuring S1-MME to the second group and other interfaces to the first group.
33 / 136 © 2017 Nokia

Figure 11 Application architecture for 34ucces access Flexi NS
34 / 136 © 2017 Nokia

Figure 12 New units for MME function
Deliverables in Upgrade and Capacity Expansion of GPRS System Phase 6 project for the SGSN-MME are:
• New 4 x Flexi NS SGSN-MME (FNS 17)

• Software and hardware upgrade of existing 8 x Flexi NS (SG8.0/NS4.0 to be NS17)
The table below lists the new and upgraded Flexi NS elements and their location.
Table 25 – New and Upgraded Flexi-NS in Phase 6
Site Network Element Type Network Element Name Remark

Flexi NS#1 MME_ATYHA01N Upgraded FNS
Hanoi – Yen Hoa
Flexi NS#2 MME_ATYHA02N Upgraded FNS
Hanoi – Giap Bat Flexi NS#1 MME_ATGBT01N Upgraded FNS
Da Nang – NVL Flexi NS#1 MME_ATNVL01N New FNS
Da Nang – AND Flexi NS#2 MME_ATADN01N New FNS
Flexi NS#1 MME_ATC3001N Upgraded FNS
HCMC – C30 Flexi NS#2 MME_ATC3002N Upgraded FNS
Flexi NS#3 MME_ATC3003N Upgraded FNS
Flexi NS#1 MME_ATQ0901N Upgraded FNS
Flexi NS#2 MME_ATQ0902N Upgraded FNS
HCMC – Q09
Flexi NS#3 MME_ATQ0903N New FNS
Flexi NS#4 MME_ATQ0904N New FNS
35 / 136 © 2017 Nokia

3.2.3.1 Upgrade Flexi NS Configuration
3.2.3.1.1 Site C30 and Q09 FNS Shelf Configuration
The figure below shows the Flexi NS shelf configuration for the Flexis NS at site C30 and Q09, namely:
• MME_ATQ0901N & MME_ATQ0902N

• MME_ATC3001N, MME_ATC3002N & MME_ATC3003N
Figure 13 Flexi NS Shelf Configuration for Site C30 & Q09
ATCA FNS17 46 1U
45
PDUs 44 3U Power Distribution Unit
43
42 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
41
40
MMDU 0
MMDU 1
MCHU 0
MCHU 1
Software
CPPU 0
CPPU 1
CPPU 2
CPPU 3
OMU 0
SWU 0
SWU 1
OMU 1
IPDU 0
IPDU 1
39
38
1st Shelf 37
ATCA Flexi NS 36 13U
SGSN & MME 35
34
AHUB3-B
AHUB3-B
Hardware
ACPI4-B
ACPI4-B
ACPI4-B
ACPI4-B
ACPI4-B
ACPI4-B
ACPI4-B
ACPI4-B
ACPI4-B
ACPI4-B
ACPI4-B
ACPI4-B
33
32
31
30
29 1U
28 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
27
26
MMDU 2
MMDU 3
MMDU 4
MMDU 5
Software
CPPU 4
CPPU 5
CPPU 6
VMU 0
VMU 1
VMU 2
SWU 2
SWU 3
VMU 3
25
24
2nd Shelf 23
SGSN & MME 21
20
AHUB3-B
AHUB3-B
Hardware
ACPI4-B
ACPI4-B
ACPI4-B
ACPI4-B
ACPI4-B
ACPI4-B
ACPI4-B
ACPI4-B
ACPI4-B
ACPI4-B
ACPI4-B
19
18
17
16
15 1U
14 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
13
12
Software
VMU 10
SWU 4
SWU 5
VMU 4
VMU 5
VMU 6
VMU 7
VMU 8
VMU 9
IPPU 0
IPPU 1
GBU 0
GBU 1
GBU 2
GBU 3
GBU 4
11
10
3rd Shelf 9
ATCA Flexi NS 8 13U
SGSN & MME 7
6
AHUB3-B
AHUB3-B
Hardware
ACPI4-B
ACPI4-B
ACPI4-B
ACPI4-B
ACPI4-B
ACPI4-B
ACPI4-B
ACPI4-B
ACPI4-B
ACPI4-B
ACPI4-B
ACPI4-B
ACPI4-B
ACPI4-B
5
4
3
2
1 1U
36 / 136 © 2017 Nokia

3.2.3.1.2 Site YHA and GBT FNS Shelf Configuration
The figure below shows the Flexi NS shelf configuration for the Flexis NS at site C30 and Q09, namely:
• MME_ATYHA01N & MME_ATYHA02N

• MME_GBT01N
Figure 14 Flexi NS Shelf Configuration for Site YHA and GBT
ATCA FNS17 46 1U
45
43
42 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
41
40
MMDU 0
MMDU 1
MCHU 0
MCHU 1
Software
CPPU 0
CPPU 1
CPPU 2
CPPU 3
SWU 0
SWU 1
OMU 0
IPDU 0
IPDU 1
OMU 1
39
38
1st Shelf 37
SGSN & MME 35
34
AHUB3-B
AHUB3-B
Hardware
ACPI4-B
ACPI4-B
ACPI4-B
ACPI4-B
ACPI4-B
ACPI4-B
ACPI4-B
ACPI4-B
ACPI4-B
ACPI4-B
ACPI4-B
ACPI4-B
33
32
31
30
29 1U
28 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
27
26
MMDU 2
MMDU 3
Software
CPPU 4
CPPU 5
SWU 2
SWU 3
VMU 0
VMU 1
VMU 2
VMU 3
25
24
2nd Shelf 23
SGSN & MME 21
20
AHUB3-B
AHUB3-B
Hardware
ACPI4-B
ACPI4-B
ACPI4-B
ACPI4-B
ACPI4-B
ACPI4-B
ACPI4-B
ACPI4-B
19
18
17
16
15 1U
14 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
13
12
Software
SWU 4
SWU 5
IPPU 0
IPPU 1
VMU 4
VMU 5
GBU 0
GBU 1
GBU 2
GBU 3
GBU 4
11
10
3rd Shelf 9
ATCA Flexi NS 8 13U
SGSN & MME 7
6
AHUB3-B
AHUB3-B
Hardware
ACPI4-B
ACPI4-B
ACPI4-B
ACPI4-B
ACPI4-B
ACPI4-B
ACPI4-B
ACPI4-B
ACPI4-B
5
4
3
2
1 1U
37 / 136 © 2017 Nokia

3.2.3.2 New Flexi NS Configuration
The figure below shows the Flexi NS shelf configuration for MME_ATQ0903N and MME_ATQ0904N.
Figure 15 MME_ATQ0903N and MME_ATQ0904N Shelf Configuration
46 1U
45
43
42 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
41
40
MMDU 0
MMDU 1
MCHU 0
MCHU 1
Software
CPPU 0
CPPU 1
CPPU 2
CPPU 3
OMU 0
IPDU 0
IPDU 1
OMU 1
SWU 0
SWU 1
39
38
1st Shelf 37
SGSN & MME 35
34
AHUB3-B
AHUB3-B
Hardware
ACPI5-A
ACPI5-A
ACPI5-A
ACPI5-A
ACPI5-A
ACPI5-A
ACPI5-A
ACPI5-A
ACPI4-B
ACPI4-B
ACPI4-B
ACPI4-B
33
32
31
30
29 1U
28 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
27
26
MMDU 2
MMDU 3
MMDU 4
MMDU 5
Software
CPPU 4
CPPU 5
SWU 2
SWU 3
25
24
2nd Shelf 23
SGSN & MME 21
20
AHUB3-B
AHUB3-B
Hardware
ACPI5-A
ACPI5-A
ACPI5-A
ACPI5-A
ACPI5-A
ACPI5-A
19
18
17
16
15 1U
14 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
13
12
Software
VMU 10
VMU 0
VMU 1
VMU 2
VMU 3
VMU 4
VMU 5
VMU 6
VMU 7
VMU 8
VMU 9
SWU 4
SWU 5
11
10
3rd Shelf 9
ATCA Flexi NS 8 13U
SGSN & MME 7
6
AHUB3-B
AHUB3-B
Hardware
ACPI5-A
ACPI5-A
ACPI5-A
ACPI5-A
ACPI5-A
ACPI5-A
ACPI5-A
ACPI5-A
ACPI5-A
ACPI5-A
ACPI5-A
5
4
3
2
1 1U
38 / 136 © 2017 Nokia

39 / 136
PDUs
1st Shelf
3rd Shelf
2nd Shelf
SGSN & MME

SGSN & MME
SGSN & MME
ATCA Flexi NS
ATCA Flexi NS
ATCA Flexi NS
1
2
3
4
5
6
7
9
10
11
12
13
14
15
16
17
18
19
20
21
23
24
25
26
27
28
29
30
31
32
33
34
35
37
38
39
40
41
42
43
44
45
46
1U
1U
1U
3U
1U
8 13U
22 13U
36 13U
1
1
1
ACPI5-A MMDU 2 ACPI4-B OMU 0
2
2
2
ACPI5-A MMDU 3 ACPI4-B MCHU 0
3
3
3
ACPI5-A MMDU 4 ACPI5-A MMDU 0
4
4
4
ACPI5-A VMU 0 ACPI5-A MMDU 5 ACPI5-A MMDU 1
5
5
5
ACPI5-A VMU 1 ACPI5-A CPPU 0
6
6
6
7
7
ACPI5-A VMU 3 ACPI5-A CPPU 2 7
8
8
8
AHUB3-B SWU 4 AHUB3-B SWU 2 AHUB3-B SWU 0
9
9
9
AHUB3-B SWU 5 AHUB3-B SWU 3 AHUB3-B SWU 1

Power Distribution Unit
ACPI5-A VMU 7 ACPI5-A CPPU 6 ACPI5-A IPDU 0
ACPI5-A VMU 8 ACPI5-A CPPU 7 ACPI5-A IPDU 1
ACPI5-A VMU 9 ACPI4-B MCHU 1
ACPI5-A VMU 10 ACPI4-B OMU 1
10 11 12 13 14 15 16
10 11 12 13 14 15 16
10 11 12 13 14 15 16
Hardware Software Hardware Software Hardware Software

Figure 16 MME_ATNVL01N and MME_ATADN01N Shelf Configuration
The figure below shows the Flexi NS shelf configuration for MME_ATNVL01N and MME_ATADN01N.
© 2017 Nokia
3.2.4 SAM
Figure 17 – 5620 SAM – HP DL380 Gen 9 Server – Front
Figure 18 – 5620 SAM – HP DL380 Gen 9 Server – Rear
40 / 136 © 2017 Nokia

3.2.5 CMD
What to deliver:
• 02 Flexi CMD16 HA systems.

• Hardware for each system: 02 servers HP DL380 G9, 01 storage EMC VNX 5200, 02 switches HP
5510
Table 26 Location, site and node name
Location Site Node name

Ha Noi (HNI) Yen Hoa (YHA) CG_YHA01N
Ho Chi Minh city (HCMC) Quan 9 (Q09) CG_Q0901N
Da Nang (DNG) N/A N/A
3.2.6 Traffica
Nokia proposed Traffica 16 in this case. Existing Traffica system will be upgraded to the latest software
version (Traffica 16.8). Four new Traffica Network Element Server (TNES) will be provided to connect to new
Flexi NS under the scope of the core network expansion (2 in Da Nang, 2 in HCMC).
Table 27 Traffica hardware
Traffica Computing Platform Da Nang HCMC

Traffica TNES HW
HP DL360 Gen9 8SFF CTO Server 2 2
HPE E5-2667v4 DL360 8c G9 FIO Kt 1st CPU 2 2
HP DL360 Gen9 SFF DVD-RW/USB Kit 2 2
HP 800W FS Plat Ht Plg Pwr Supply Kit 4 4
HPE 16GB 2Rx4 PC4-2400T-R Kit 8 8
HPE 600GB 6G SAS 10K 2.5 SC Ent HDD 40 40
HP Smart Array P440ar/2G FIO Controller 2 2
HP Smart Array P441/4G Controller 2 2
HP D3700 Enclosure 2 2
HP 1U SFF Easy Install Rail Kit + CMA 2 2
Traffica OEM SW
HP iLO Adv incl 3yr TS U E-LTU 2 2
Windows Server 2012 2P 64B STD DVD 2 2
Table 28 Node name
Network Element Site Node Name

Traffica TNES Server Danang TN_ATADN01N
Traffica TNES Server Danang TN_ATNVL01N
Traffica TNES Server#1 HCM TN_ATQ0903N
Traffica TNES Server#2 HCM TN_ATC3004N
41 / 136 © 2017 Nokia

3.2.7 FMA
Keep existing 2 HP DL380p Gen8 8-SFF CTO Servers on site Yen Hoa (FMA Server).
Upgrade software version FMANS17.
3.2.8 DNS
Install new DNS servers at 2 sites (Ha Noi – Yen Hoa and HCM – Q9).
Each site included (totally 4 cluster DNS servers for whole network, mean 8 DNS server):
• 1 cluster Gn-DNS (Infoblox Trinzic 2220, 1+1 redundancy).

• 1 cluster Gi-DNS (Infoblox Trinzic 1420, 1+1 redundancy).
Figure 19 Infoblox Trinzic 2220
Figure 20 Infoblox Trinzic 1420
3.3 Software
Table 29 Software releases
Network Functionality Nokia Product Name

SGSN/MME Flexi NS17
GGSN/SAE-GW 7750-SR12-MG 8.R07
Network Management System NetAct 16.8
Network Management System SAM 14.0 R5
Charging Flexi CMD16
Traffica Traffica version 16
Flexi Maintenance Application FMA NS 17
DNS Infoblox Trinzic NIOS 7
42 / 136 © 2017 Nokia

3.4 Connectivity
3.4.1 SAE-GW
3.4.1.1 Logical interfaces
Table 30 Logical interfaces and 3GPP compliancy
Interface Protocol Related NE Standard compliancy

S11 GTPv2 MME-SGW 3GPP TS 29.274
S4C GTPv2 SGSN-SGW 3GPP TS 23.060

S4U GTPv2 SGSN-SGW 3GPP TS 23.060
S12 GTPv2 RNC-SGW 3GPP TS 23.060

S1u GTPv2/v1 EnodeB-SGW 3GPP TS 29.281
S5/S8 GTPv2/v1 SGW-PGW 3GPP TS 29.274, 3GPP TS 29.281

Gn/Gp GTPv1 SGSN-GGSN 3GPP TS 29.060
Gz Diameter PGW-OFCS (CG) 3GPP TS 32.251, 3GPP TS 32.295, 3GPP TS 32.297

Gy Diameter PGW-OCS 3GPP TS 30.240, 3GPP TS 32.251, 3GPP TS 32.299
Gx Diameter PGW-PCRF 3GPP TS 23.203, 3GPP TS 29.212, 3GPP TS 32.251
Figure 21: Logical interfaces
ePDG Access GW S-GW
Lawful
Policy and charging CEMoD
interception
rule function OTT Insight
gateway
S2b S2a/Gn S5/S8
X1_1
Dr
Gxc Gx X2 S6b
AAA
X3
SGi
P-GW
S5/S8 Packet data

networks
S1-U SGi
Access S11
network S4
S-GW P-GW
S12 CAM
Gn/Gp
Gy
Traffica
Bp Gz/Ga O&M
Network Online
Offline charging
management charging
system
system system
43 / 136 © 2017 Nokia

In Mobifone project 7750 MG will be serving as Combo Gateway which consist of the SGW /PGW and GGSN
functionality.
• Gn/Gp interface: Interface between the SGSN and the PDN-Gateway (GGSN) entity. The
GPRS 44uccess44t protocol, version 1 (GTPv1) is used.
• S11 interface: Interface between the Mobility Management Entity (MME) and the Serving
Gateway (S-GW) entity. The GPRS 44uccess44t protocol, version 2 (GTPv2) is used in the
S11 interface.
• S4 interface: It provides related control and mobility support between GPRS Core and the
3GPP Anchor function of Serving GW. In addition, if Direct Tunnel is not established, it
provides the user plane 44uccess44t.
• S5/S8 interface: The S5/S8-GTP interface provides evolved packet core (EPC) 44uccess44t
for the user plane between the S-GW and the P-GW. The GTP-based S5/S8 user plane is
based on GTPv1 and the GTP-based S5/S8 control plane is based on GTPv2. GTP tunnels
are used between two nodes that communicate over a GTP-based interface, to separate
traffic into different communication flows.
• S1U interface: User plane interface between eNodeB and Serving Gateway. It is a pure user
data interface (U=User plane). A single eNodeB can connect to several Serving GWs.
• S12 interface: Reference point between UTRAN and Serving GW for user plane
44uccess44t when Direct Tunnel is established. It is based on the Iu-u/Gn-u reference
point using the GTP-U protocol as defined between SGSN and UTRAN or respectively
between SGSN and GGSN. Usage of S12 is an operator configuration option.
• Sgi interface: Traffic between 7750 MG and PDN consists of IP packets. As traffic from
Gi/Sgi arrives to 7750 MG, it checks the destination address and the routing instance of an
IP packet and assigns a PDN connection
• Gx interface: The Gx interface is used between the P-GW or the GGSN (depending on
whether 7750 MG is used in LTE or 3G mode) and the PCRF. 7750 MG supports default
evolved packet system (EPS) bearer control, dedicated bearer flow control, and service
data flows.
• Gy interface: 7750 MG uses the Gy interface for connection with online charging system
(OCS) through the Diameter credit-control application (DCCA) protocol. 7750 MG delivers
online charging information to the OCS server, and acts according to instructions received
from OCS. Several OCS nodes can connect to 7750 MG and routing for each OCS can
reside in its own routing instance.
• Gz interface: The Gz reference point is functionally equivalent to Ga for Legacy PS domain
and to Ga or Rf for Evolved Packet Core domain, and hence is replaced by Ga or Rf within
the common charging architecture.
• Bx/Bp Interface: Offline Charging. The Bx reference point supports interaction between a
Charging Gateway Function and the Billing Domain. The information crossing this reference
point is comprised of CDR files. A common, standard file transfer protocol (e.g. FTAM, FTP)
shall be used, including the transport mechanisms specified for the selected protocol.
44 / 136 © 2017 Nokia

3.4.1.2 Physical Connectivity
The physical connectivity between 7750 MG nodes and Mobifone site routes are described with the
following diagrams and tables. The connectivity details can be seen for each site. A pair of LAGs (Link
Aggregation Group) will be configured between 7750 MG and Mobifone site routers in order to provide link
redundancy.
Figure 22 : Physical Connectivity Diagram- EPG_MGYHA01N

LAG-1
EPG_MGYHA01N PE_ASR9010YHA01C
5/1/1 4/0/3
5/1/2 4/1/1
5/1/3 5/0/1
5/1/4 5/0/4
5/1/5 6/0/6
5/1/6 6/1/2
SW_OAM_2960_YHA_01C
Slot A Mngmt 1/0/21
Slot B Mngmt 1/0/25
SW_OAM_2960_YHA_02C
6/1/1 4/0/3
6/1/2 4/1/1
6/1/3 5/0/1
6/1/4 5/0/4
6/1/5 6/0/6
6/1/6 6/1/2
PE_ASR9010YHA02C
LAG-2
Table 31 Physical Connectivity Table- EPG_MGYHA01N

EPG_MGYHA01N Site Router
Module Slot Port Type Router Port Mode encap-type Type
5 1 SFP+ 10GE TenGigE0/4/0/3 Access dot1q SFP+ 10GE
IOM Slot 1 LAG 1 PE_ASR9010YHA01C
IOM Slot 2 LAG 2 PE_ASR9010YHA02C
Access dot1q SFP+ 10GE
CPM/SF 1 A 1 RJ45 SW_OAM_2960_YHA_01C Gi1/0/21 Access dot1q SFP+ 1GE
CPM/SF 1 B 1 RJ45 SW_OAM_2960_YHA_02C Gi1/0/25 Access dot1q SFP+ 1GE
45 / 136 © 2017 Nokia

Figure 23 : Physical Connectivity Diagram- EPG_MGGBT01N
LAG-1
EPG_MGGBT01N PE_ASR9010GBT01C
5/1/1 2/0/2
5/1/2 2/0/3
5/1/3 2/0/4
5/1/4 2/1/2
5/1/5 2/1/3
5/1/6 2/1/4
SW_OAM_4948_GBT01C
Slot A Mngmt 1/19
Slot B Mngmt 1/19
SW_OAM_4948_GBT02C
6/1/1 2/0/2
6/1/2 2/0/3
6/1/3 2/0/4
6/1/4 2/1/2
6/1/5 2/1/3
6/1/6 2/1/4
PE_ASR9010GBT02C
LAG-2
Table 32 Physical Connectivity Table- EPG_MGGBT01N

EPG_MGGBT01N Site Router
Module Slot Port Type Router Port Mode encap-type Type
5 1 SFP+ 10GE Te0/2/0/2 Access dot1q SFP+ 10GE
IOM Slot 1 LAG 1 PE_ASR9010GBT01C
IOM Slot 2 LAG 2 PE_ASR9010GBT02C
Access dot1q SFP+ 10GE
CPM/SF 1 A 1 RJ45 SW_OAM_4948_GBT01C Gi1/19 Access dot1q SFP+ 1GE
CPM/SF 1 B 1 RJ45 SW_OAM_4948_GBT02C Gi1/19 Access dot1q SFP+ 1GE
46 / 136 © 2017 Nokia

Figure 24 : Physical Connectivity Diagram- EPG_MGQ0901N
EPG_MGQ0901N LAG-1 PE_ASR9010Q0903C
5/1/1 0/0
5/1/2 0/1
5/1/3 0/2
5/1/4 0/3
5/1/5 0/4
5/1/6 0/5
5/1/7 0/6
5/1/8 0/7
Slot A Mngmt
Slot B Mngmt
6/1/1 0/0
6/1/2 0/1
6/1/3 0/2
6/1/4 0/3
6/1/5 0/4
6/1/6 0/5
6/1/7 0/6
6/1/8 0/7
LAG-2 PE_ASR9010Q0904C
Table 33 Physical Connectivity Table- EPG_MGQ0901N

EPG_MGQ0901N Site Router
Module Slot Port Type Router Slot Port Mode encap-type Type
5 1 SFP+ 10GE 0 0 Access dot1q SFP+ 10GE
IOM Slot 1 LAG 1 PE_ASR9010Q0903C
CPM/SF 1 A 1 RJ45 Router 1 Access dot1q SFP+ 1GE

CPM/SF 1 B 1 RJ45 Router 2 Access dot1q SFP+ 1GE
47 / 136 © 2017 Nokia

Figure 25: Physical Connectivity Diagram-EPG_MGQ0902N
EPG_MGQ0902N PE_ASR9010Q0903C
LAG-1
5/1/1 1/0
5/1/2 1/1
5/1/3 1/2
5/1/4 1/3
5/1/5 1/4
5/1/6 1/5
Slot A Mngmt
Slot B Mngmt
6/1/1 1/0
6/1/2 1/1
6/1/3 1/2
6/1/4 1/3
6/1/5 1/4
6/1/6 1/5
LAG-2
PE_ASR9010Q0904C
Table 34 Physical Connectivity Table-EPG_MGQ0902N

EPG_MGQ0902N Site Router

48 / 136 © 2017 Nokia

Figure 26: Physical Connectivity Diagram-EPG_MGC3001N
EPG_MGC3001N PE_ASR9010C3003C
5/1/1 LAG-1 0/0

5/1/2 0/1
5/1/3 0/2
5/1/4 0/3
5/1/5 0/4
5/1/6 0/5
5/1/7 0/6
5/1/8 0/7
Slot A Mngmt
Slot B Mngmt
6/1/1 0/0
6/1/2 0/1
6/1/3 0/2
6/1/4 0/3
6/1/5 0/4
6/1/6 0/5
6/1/7 0/6
6/1/8 LAG-2 0/7
PE_ASR9010C3004C
Table 35 Physical Connectivity Table-EPG_MGC3001N

EPG_MGC3001N Site Router
IOM Slot 1 LAG 1 PE_ASR9010C3003C
IOM Slot 2 LAG 2 PE_ASR9010C3004C

49 / 136 © 2017 Nokia

Figure 27: Physical Connectivity Diagram-EPG_MGC3002N
LAG-1
EPG_MGC3002N PE_ ASR9010C3003C
5/1/1 1/0
5/1/2 1/1
5/1/3 1/2
5/1/4 1/3
5/1/5 1/4
5/1/6 1/5
Slot A Mngmt
Slot B Mngmt
6/1/1 1/0
6/1/2 1/1
6/1/3 1/2
6/1/4 1/3
6/1/5 1/4
6/1/6 1/5
PE_ ASR9010C3004C
LAG-2
Table 36 Physical Connectivity Table- EPG_MGC3002N

EPG_MGC3002N Site Router
IOM Slot 1 LAG 1 PE_ ASR9010C3003C
IOM Slot 2 LAG 2 PE_ ASR9010C3004C

50 / 136 © 2017 Nokia

3.4.1.3 Transport Connectivity
Each VPRN on 7750 MG has 2 x transport interfaces with /30 address, first transport interface is connected
to site Router 1 and the second transport interface is connected to site Router 2 in order to have
redundancy. There are also loopback interfaces which are terminated with /32 addresses in each VPRN for
3GPP interfaces.
Each transport subnet /30 is configured with a VLAN-ID in VPRN. Below tables describe the transport
connectivity details per each node and show the proposed IP addressing plan for 7750 MG nodes .
Table 37 7750 MG Transport Connectivity- EPG_MGYHA01N

EPG_MGYHA01N VLAN ID IP Requirement
Router
VLAN Internal Internal Transport Transport Interface Name Loopback Loopback Address Remarks
VPRN Name VRF
Requirement VLAN IDs Subnet Interface
450 10.51.28.0/30 Access_Data_to_Router1
S1u 2 S1U 10.51.28.64/32 LRAN-U
452 10.51.28.8/30 SIG_to_Router1 S11 10.51.28.65/32
S11 2 Gn-Gp-C
453 10.51.28.12/30 SIG_to_Router2 S4C 10.51.28.66/32
454 10.51.28.16/30 SIG_to_Router1
Gx 2 Gx 10.51.28.67/32 Gi-apn
455 10.51.28.20/30 SIG_to_Router2
456 10.51.28.24/30 SIG_to_Router1
Gy 2 Gy 10.51.28.68/32
457 10.51.28.28/30 SIG_to_Router2
Billing
458 10.51.28.32/30 SIG_to_Router1
Gz 2 Gz 10.51.28.69/32
459 10.51.28.36/30 SIG_to_Router2
GpS8 137.59.36.17/32
460 10.51.28.40/30 Core_Data_to_Router1
GnS5 137.59.36.18/32
Gn 2 Gn-Gp-U
S4U 10.51.28.70/32
S12 10.51.28.71/32
RADIUS 10.51.28.72/32
462 10.51.28.48/30 Sgi_to_Router1 Sgi-1 APN1 10.51.28.73/32
Sgi-1 APN2 10.51.28.74/32
Sgi 2 Gi-apn
Sgi-1 APN3 10.51.28.75/32
Sgi-1 APN5 10.51.28.77/32
464 10.51.28.56/30 GRT_to_Router1 system 10.51.28.78/32
OAM 2 OAM
465 10.51.28.60/30 GRT_to_Router2 FTP_Cha(Bp) 10.51.28.79/32
51 / 136 © 2017 Nokia

Table 38 7750 MG Transport Connectivity-EPG_MGGBT01N
EPG_MGGBT01N VLAN ID IP Requirement
Router
VPRN Name VRF
S1u 2 S1U 10.51.152.64/32 LRAN-U
402 10.51.152.8/30 SIG_to_Router1 S11 10.51.152.65/32
S11 2 Gn-Gp-C
403 10.51.152.12/30 SIG_to_Router2 S4C 10.51.152.66/32
404 10.51.152.16/30 SIG_to_Router1
Gx 2 Gx 10.51.152.67/32 Gi-apn
405 10.51.152.20/30 SIG_to_Router2
406 10.51.152.24/30 SIG_to_Router1
Gy 2 Gy 10.51.152.68/32
407 10.51.152.28/30 SIG_to_Router2
Billing
408 10.51.152.32/30 SIG_to_Router1
Gz 2 Gz 10.51.152.69/32
409 10.51.152.36/30 SIG_to_Router2
GpS8 137.59.36.25/32
GnS5 137.59.36.26/32
Gn 2 Gn-Gp-U
S4U 10.51.152.70/32
S12 10.51.152.71/32
RADIUS 10.51.152.72/32
Sgi-1 APN2 10.51.152.74/32
Sgi 2 Gi-apn
Sgi-1 APN3 10.51.152.75/32
Sgi-1 APN5 10.51.152.77/32
OAM 2 OAM
Table 39 7750 MG Transport Connectivity-EPG_MGQ0901N

EPG_MGQ0901N VLAN ID IP Requirement
Router
VLAN Internal Internal Transport Loopback Remarks
VPRN Name Transport Interface Name Loopback Address VRF
S1u 2 S1U 10.53.86.128/32 LRAN-U
803 10.53.86.8/30 SIG_to_Router1 S11 10.53.86.129/32
S11 2 Gn-Gp-C
804 10.53.86.12/30 SIG_to_Router2 S4C 10.53.86.130/32
805 10.53.86.16/30 SIG_to_Router1
Gx 2 Gx 10.53.86.131/32 Gi-apn
806 10.53.86.20/30 SIG_to_Router2
807 10.53.86.24/30 SIG_to_Router1
Gy 2 Gy 10.53.86.132/32
808 10.53.86.28/30 SIG_to_Router2
Billing
809 10.53.86.32/30 SIG_to_Router1
Gz 2 Gz 10.53.86.133/32
810 10.53.86.36/30 SIG_to_Router2
GpS8 137.59.39.1/32
GnS5 137.59.39.2/32
Gn 2 Gn-Gp-U
S4U 10.53.86.134/32
S12 10.53.86.135/32
RADIUS 10.53.86.136/32
Sgi-1 APN2 10.53.86.138/32
Sgi 2 Gi-apn
Sgi-1 APN3 10.53.86.139/32
Sgi-1 APN5 10.53.86.141/32
OAM 2 OAM
52 / 136 © 2017 Nokia

Table 40 7750 MG Transport Connectivity- EPG_MGQ0902N
EPG_MGQ0902N VLAN ID IP Requirement
Router
VLAN Internal Internal Transport Loopback Remarks
VPRN Name Transport Interface Name Loopback Address VRF
S1u 2 S1U 10.53.86.144/32 LRAN-U
823 10.53.86.72/30 SIG_to_Router1 S11 10.53.86.145/32
S11 2 Gn-Gp-C
824 10.53.86.76/30 SIG_to_Router2 S4C 10.53.86.146/32
825 10.53.86.80/30 SIG_to_Router1
Gx 2 Gx 10.53.86.147/32 Gi-apn
826 10.53.86.84/30 SIG_to_Router2
827 10.53.86.88/30 SIG_to_Router1
Gy 2 Gy 10.53.86.148/32
828 10.53.86.92/30 SIG_to_Router2
Billing
829 10.53.86.96/30 SIG_to_Router1
Gz 2 Gz 10.53.86.149/32
830 10.53.86.100/30 SIG_to_Router2
GpS8 137.59.39.3/32
GnS5 137.59.39.4/32
Gn 2 Gn-Gp-U
S4U 10.53.86.150/32
S12 10.53.86.151/32
RADIUS 10.53.86.152/32
Sgi-1 APN2 10.53.86.154/32
Sgi 2 Gi-apn
Sgi-1 APN3 10.53.86.155/32
Sgi-1 APN5 10.53.86.157/32
OAM 2 OAM
Table 41 7750 MG Transport Connectivity-EPG_MGC3001N

EPG_MGC3001N VLAN ID IP Requirement
Router
VPRN Name VRF
S1u 2 S1U 10.53.85.128/32 LRAN-U
703 10.53.85.8/30 SIG_to_Router1 S11 10.53.85.129/32
S11 2 Gn-Gp-C
704 10.53.85.12/30 SIG_to_Router2 S4C 10.53.85.130/32
705 10.53.85.16/30 SIG_to_Router1
Gx 2 Gx 10.53.85.131/32 Gi-apn
706 10.53.85.20/30 SIG_to_Router2
707 10.53.85.24/30 SIG_to_Router1
Gy 2 Gy 10.53.85.132/32
708 10.53.85.28/30 SIG_to_Router2
Billing
709 10.53.85.32/30 SIG_to_Router1
Gz 2 Gz 10.53.85.133/32
710 10.53.85.36/30 SIG_to_Router2
GpS8 137.59.39.5/32
GnS5 137.59.39.6/32
Gn 2 Gn-Gp-U
S4U 10.53.85.134/32
S12 10.53.85.135/32
RADIUS 10.53.85.136/32
Sgi-1 APN2 10.53.85.138/32
Sgi 2 Gi-apn
Sgi-1 APN3 10.53.85.139/32
Sgi-1 APN5 10.53.85.141/32
OAM 2 OAM
53 / 136 © 2017 Nokia

Table 42 7750 MG Transport Connectivity-EPG_MGC3002N
EPG_MGC3002N VLAN ID IP Requirement
Router
VPRN Name VRF
S1u 2 S1U 10.53.85.144/32 LRAN-U
723 10.53.85.72/30 SIG_to_Router1 S11 10.53.85.145/32
S11 2 Gn-Gp-C
724 10.53.85.76/30 SIG_to_Router2 S4C 10.53.85.146/32
725 10.53.85.80/30 SIG_to_Router1
Gx 2 Gx 10.53.85.147/32 Gi-apn
726 10.53.85.84/30 SIG_to_Router2
727 10.53.85.88/30 SIG_to_Router1
Gy 2 Gy 10.53.85.148/32
728 10.53.85.92/30 SIG_to_Router2
Billing
729 10.53.85.96/30 SIG_to_Router1
Gz 2 Gz 10.53.85.149/32
730 10.53.85.100/30 SIG_to_Router2
GpS8 137.59.39.7/32
GnS5 137.59.39.8/32
Gn 2 Gn-Gp-U
S4U 10.53.85.150/32
S12 10.53.85.151/32
RADIUS 10.53.85.152/32
Sgi-1 APN2 10.53.85.154/32
Sgi 2 Gi-apn
Sgi-1 APN3 10.53.85.155/32
Sgi-1 APN5 10.53.85.157/32
OAM 2 OAM
3.4.1.4 Layer 3 Service Architecture
This section describes Layer 3 service architecture on 7750 MG and also on Mobifone site routers .Each
VPRN (virtual private router network) is connected to a specific VRFs on site routers.
• Each VPRN on 7750 MG has 2 x transport interfaces with /30 address, first transport interface is
connected to site Router 1 and the second transport interface is connected to site Router 2 in
order to have redundancy.
• Each 3GPP interface has a specific termination loopback interfaces with /32 addresses.
• “Gp-C , Gp-U” and “S8-C ,S8-U” loopback have same public IP addresses on 7750 MG.
• “Gn-C , Gn-U” and “S5-C ,S5-U” loopback have same public IP addresses on 7750 MG.
Below diagrams shows the detailed service architecture and L3 connectivity between 7750 MG and
Mobifone site routers .VRF design on Mobifone routers are different per sites Hanoi and Ho Chi Minh.
54 / 136 © 2017 Nokia

Figure 28 L3 Service Architecture-Hanoi
EPG_MGYHA01N
EPG_MGGBT01N
7750MG LAG-1
S/PGW/GSN MBF Site Route 1
4/5x10G
S1U VPRN S1U VRF Gn-Gp
S11
S4C VPRN S11 VRF Billing
GN/S5
Gp/S8
S4U VPRN Gn VRF Gi-APN
S12
Gy VPRN Gy VRF OAM
Gz VPRN Gz
Gx VPRN Gx
Radius
Apn1
Apn2
MBF Site Route 2
Apn3
Apn4
VPRN SGi
Apn5
Apn6 VRF Gn-Gp
System GRT Base
FTP-CHA (Bp)
VPRN VRF Billing
CPM A
VRF Gi-APN
Out of Band
Management Ports
CPM B
VRF OAM
LAG-2
4/5x10G
Transport Interface
Loopback address
Table 43 7750 MG VPRN Details – Site Ha Noi
VPRN Definition
VRF Name Interfaces OSPF area
Service ID Service name
VPRN S1u S1U 200 Gn-Gp 11
S11
VPRN S11 210 S11 17
S4C
VPRN Gx Gx 220 Gx 14
VPRN Gy Gy 230 Gy 13
VPRN Gz Gz 240 Gz 15
GpS8
GnS5
Gn 250 Gn 11
S4U
S12
Sgi
VPRN Sgi 260 SGi 12
BP
OAM n/a OAM 16
system
55 / 136 © 2017 Nokia

Figure 29: L3 Service Architecture-Ho Chi Minh
EPG_MGQ0901N
EPG_MGQ0902N
EPG_MGC3001N
EPG_MGC3002N
7750MG LAG-1
S/PGW/GSN MBF Site Route 1
4/5x10G
S1U VPRN S1U VRF Gn-Gp
S11
S4C VPRN S11 VRF Billing
GN/S5
Gp/S8
S4U VPRN Gn VRF Gi-APN
S12
Gy VPRN Gy VRF OAM
Gz VPRN Gz
Gx VPRN Gx
Radius
Apn1
Apn2
MBF Site Route 2
Apn3
Apn4
VPRN SGi
Apn5
Apn6 VRF Gn-Gp
System GRT Base
FTP-CHA (Bp)
VPRN VRF Billing
CPM A
VRF Gi-APN
Out of Band
Management Ports
CPM B
VRF OAM
LAG-2
4/5x10G
Transport Interface
Loopback address
Table 44: 7750 MG VPRN Details – Site Ho Chi Minh
VPRN Definition
Service ID Service name
VPRN S1u S1U 200 S1U 150
S11
VPRN S11 210 S11 151
S4C
VPRN Gx Gx 220 Gx 152
VPRN Gy Gy 230 Gy 153
VPRN Gz Gz 240 Gz 154
GpS8
GnS5
Gn 250 Gn 154
S4U
S12
Sgi
VPRN Sgi 260 SGi 152
BP
OAM n/a OAM 155
system
56 / 136 © 2017 Nokia

3.4.1.5 MTU
The MTU policy of Mobifone network is designed to offer to the UE the maximum value allowed in the
internet network: 1500 bytes.
3.4.1.6 Routing Protocol
In Mobifone project OSPF/OSPFv2 will be configured as a dynamic routing protocol between 7750 MG and
Mobifone site routers. Each routing domain (VPRN) in MG will advertise the loopback addresses towards site
routers by using ospf dynamic routing protocol. By configuring the ospf metric best routes will be selected
by the Mobifone site routers. 7750 MG should select the best routes towards site routers with the same
method which is ospf metric.
OSPF details such as ospf parameters and configuration steps will be discussed in 7750 MG LLD.
3.4.2 SGSN/MME
3.4.2.1 Logical interfaces
The diagram below shows the overview of the new FNS internal and external connectivity.
Figure 30 Flexi NS-SGSN_MME High Level Interface Logical Connectivity
57 / 136 © 2017 Nokia

Figure 31 Internal connectivity Base Interface
Figure 32 Internal connectivity Fabric Interface
58 / 136 © 2017 Nokia

3.4.2.1.1 Site HCMC – Q09
In Phase 6, 2 new Flexi NS will be delivered to Site Q09 in HCMC.
The diagram below shows the Flexi NS physical interface requirement at Site Q09.
Figure 33 Physical Interface Requirement for new Flexi NS at Site Q09
HCMC – Q09
6xGE (Optical)
6 xG ASR9K-1
SGSN-MME E(
MME_ATQ0903N
Op
tica
l)l)
PE_ASR9010Q0903C Mobifone
tica
(Op IP Backbone Network
GE
6x
6xGE (Optical)
SGSN-MME
ASR9K-2
MME_ATQ0904N
PE_ASR9010Q0904C
3.4.2.1.2 Site DaNang – NVL and AND

In Phase 6, 2 new Flexi NS will be delivered to DaNang. The diagram below shows the Flexi NS physical
interface requirement at Site DaNang.
Figure 34 Physical Interface Requirement for new Flexi NS at Site DaNang
DaNang
Site - NVL
)
(Optical
6xGE
ASR9K-1
PE_ASR9010NVL01C
6xG
E (Op
tic al)
SGSN-MME
MME_ATNVL01N
ASR9K-2 Mobifone
PE_ASR9010NVL02C IP Backbone
Site - ADN Network
)
(Optical
6xGE
ASR9K-1
PE_ASR9010ADN01C
6xG
E (Op
tic al)
SGSN-MME
MME_ATADN01N
ASR9K-2
PE_ASR9010ADN02C
59 / 136 © 2017 Nokia

3.4.2.2 Physical Connectivity
Figure 35 : Physical Connectivity Diagram- MME_ATADN01N
MME_ATADN01N PE_ASR9010_ADN01C
3/1 0/7/0/2
SWU0
LAG
3/2 0/7/0/3
0/7/0/4
0/7/0/5
3/1
SWU1
LAG
0/7/0/0
3/2
0/7/0/1
3/1
LAG
SWU4
3/2
0/7/0/2
0/7/0/3
3/1 0/7/0/4
SWU5
LAG
3/2 0/7/0/5
EL4 0/7/0/0
OMU-0
EL5 0/7/0/1
EL4
OMU-0 PE_ASR9010_ADN02C
EL5
Table 45 Physical Connectivity Table- MME_ATADN01N

MME_ATADN01N Site Router
Unit Interface Type Name Slot Port Used for
OMU-0 EL4 1GE Optical 0 OAM
SWU0 3/1 1GE Optical 2 Traffica,Ga,CP1,Gnc,Gnu,Iucp1,S1-MME,S11,S10,S6a1,SGs1,S3,S4c,S13
PE_ASR9010_ADN01C 0/7/0
SWU4 3/1 1GE Optical 4 CP1,Gnc,Gnu,Gn2G,Iuu,GboIP,S4u
PE_ASR9010_ADN02C 0/7/0
60 / 136 © 2017 Nokia

Figure 36 : Physical Connectivity Diagram- MME_ATNVL01N
MME_ATNVL01N PE_ASR9010_NVL01C
3/1 0/7/0/2
SWU0
LAG
3/2 0/7/0/3
0/7/0/4
0/7/0/5
3/1
SWU1
LAG
0/7/0/0
3/2
0/7/0/1
3/1
SWU4 LAG
3/2
0/7/0/2
LAG 0/7/0/3
3/1 0/7/0/4
SWU5
LAG
3/2 0/7/0/5
EL4 0/7/0/0
OMU-0
EL5 0/7/0/1
EL4
OMU-0 PE_ASR9010_NVL02C
EL5
Table 46 Physical Connectivity Table- MME_ATNVL01N

MME_ATNVL01N Site Router
PE_ASR9010_NVL01C 0/7/0
PE_ASR9010_NVL02C 0/7/0
61 / 136 © 2017 Nokia

Figure 37 : Physical Connectivity Diagram- MME_ATQ0903N
MME_ATQ0903N PE_ASR9010Q0903C
3/1 0/7/0/3
SWU0
LAG
3/2 0/7/0/4
0/7/0/5
0/7/0/6
3/1
SWU1
LAG
0/7/0/1
3/2
0/7/0/2
3/1
SWU4 LAG
3/2
0/7/0/3
LAG 0/7/0/4
3/1 0/7/0/5
SWU5
LAG
3/2 0/7/0/6
EL4 0/7/0/1
OMU-0
EL5 0/7/0/2
EL4
OMU-0 PE_ASR9010Q0904C
EL5
Table 47 Physical Connectivity Table- MME_ATQ0903N

MME_ATQ0903N Site Router
PE_ASR9010Q0903C 0/7/0
PE_ASR9010Q0904C 0/7/0
62 / 136 © 2017 Nokia

Figure 38 : Physical Connectivity Diagram- MME_ATQ0904N
MME_ATQ0904N PE_ASR9010Q0903C
3/1 0/7/0/9
SWU0
LAG
3/2 0/7/0/10
0/7/0/11
0/7/0/12
3/1
SWU1
LAG
0/7/0/7
3/2
0/7/0/8
3/1
SWU4 LAG
3/2
0/7/0/9
LAG 0/7/0/10
3/1 0/7/0/11
SWU5
LAG
3/2 0/7/0/12
EL4 0/7/0/7
OMU-0
EL5 0/7/0/8
EL4
OMU-0 PE_ASR9010Q0904C
EL5
Table 48 Physical Connectivity Table- MME_ATQ0904N

MME_ATQ0904N Site Router
PE_ASR9010Q0903C 0/7/0
PE_ASR9010Q0904C 0/7/0
63 / 136 © 2017 Nokia

3.4.2.3 Layer 3 Service Architecture
Figure 39 L3 Service Architecture
FNS SGSN/MME MBF Site Route 1
Billing VRF
Ga
Sigtran VRF
Traffica
Iuc-PS VRF
SCTP
LAG
S1-MME VRF
Iu_C
S1-MME
Control-Plane
Gn-Gp VRF
S3-S10-S11 SWU0
Iuu-PS VRF
Gn-DNS-MME
Gb-IP VRF
S6a_S13
LAG
SGs
SWU1 OAM VRF
S3-S4-C
Sv
Gn_C
MBF Site Route 2
Iu_U Billing VRF

LAG
SWU4
Sigtran VRF
Data-Plane
Gb
LAG Iuc-PS VRF
Gn-S4U-3G S1-MME VRF
SWU5
Gn-S4U-2G
Gn-Gp VRF
LAG
Iuu-PS VRF
OMU-0
OAM Active Gb-IP VRF
OMU-0
OAM Standby
OAM VRF
Table 49 FNS VPRN Details – Da Nang site

OAM OAM 11
Gn-Gp (Control Plane) S11, S10, S3-C, S4-C, Gn-C, DNS, 12 nssa
Gn-Gp (Data Plane) Gn-U, S4-U 13 nssa
Billing Ga, Traffica 13 nssa
Iuu-PS Iuu 11 nssa
Iuc-PS Iuc 11 nssa
Gb-IP Gb 11 nssa
Sigtran SCTP, S6a, S13, Sv 11 nssa
S1-MME S1-MME 11 nssa
64 / 136 © 2017 Nokia

Table 50 FNS VPRN Details – HCM site

OAM OAM -
Gn-Gp (Control Plane) S11, S10, S3-C, S4-C, Gn-C, DNS, 22 nssa
Gn-Gp (Data Plane) Gn-U, S4-U 23 nssa
Billing Ga, Traffica 23 nssa
Iuu-PS Iuu 21 nssa
Iuc-PS Iuc 21 nssa
Gb-IP Gb 21 nssa
Sigtran SCTP, S6a, S13, Sv 21 nssa
S1-MME S1-MME 21 nssa
3.4.2.4 IP Address and VLAN Requirement
The table below shows IP Address and VLAN Requirement per one upgrade Flexi NS SGSN-MME node.
The table below shows IP Address and VLAN requirement per one upgraded Flexi NS SGSN-MME node.
All the existing IP addresses and VLAN IDs in the existing upgraded SGSNs will be reused. The rows that were
highlighted in Blue are the newly added IP subnets and VLANs needed for the new functional units after the
upgrade.
Table 51 Upgraded Flexi NS IP address and VLAN requirement
VLAN Name VLAN ID Subnet Type Unit Remark for Traffic Type
OAM 1x1 VLAN 1X/29 Private OMU Operation & Maintenance
Ga 914 1X/29 Private MCHU Charging
Traffica 915 1X/28 Private MCHU OAM to Traffica server
SCTP_pri 916 1X/27 Private SMMU SS7 Signalling (Primary)
SCTP_sec 918 1X/27 Private SMMU SS7 Signalling (Secondary)
Iu_C_pri 924 1X/26 Private PAPU RANAP Signalling (Primary)
Iu_C_sec 925 1X/26 Private PAPU RANAP Signalling (Secondary)
Iu_U 922 1X/27 Private IPPU IuPS User Plane
Gb 911 1X/28 Private GBU Gb User & Control Plane
S1-MME-Pri 380 1X/29 Private IPDU S1-MME Control Plane (Primary)
S1-MME-Sec 381 1X/29 Private IPDU S1-MME Control Plane (Secondary)
S3-S10-S11 389 1X/29 Private IPDU S11, S10 & S3
Gn-DNS-MME 390 1X/29 Private IPDU Gn-DNS
S6a-S13-Pri 382 1X/29 Private IPDU S6a & S13 Diameter (Primary)
S6a-S13-Sec 383 1X/29 Private IPDU S6a & S13 Diameter (Secondary)
SGs-Pri 384 1X/29 Private IPDU SGs Diameter (Primary)
SGs-Sec 385 1X/29 Private IPDU SGs Diameter (Secondary)
S3-S4-C 388 1X/26 Private PAPU S3 & S4-C
Sv 386 1X/29 Private IPDU Sv Signalling
Gn_C 912 1X/26 PUBLIC PAPU Gn Control Plane
Gn-S4U-3G 926 1X/28 PUBLIC IPPU Gn User Plane
Gn_S4U-2G 921 1X/28 PUBLIC GBU Gn User & Control Plane of 2G
L3 Interface 16xVLANs 16x/30 Private SWUs
Loopbacks - 32x/32 Private SWUs
65 / 136 © 2017 Nokia

Table 52 New Flexi NS IP address and VLAN requirement
VLAN Name VLAN ID Subnet Type Unit Remark for Traffic Type
OAM 1x1 VLAN 1X/29 Private OMU Operation & Maintenance
Ga 914 1X/29 Private MCHU Charging
Traffica 915 1X/28 Private MCHU OAM to Traffica server
SCTP_pri 916 1X/27 Private SMMU SS7 Signalling (Primary)
SCTP_sec 918 1X/27 Private SMMU SS7 Signalling (Secondary)
Iu_C_pri 924 1X/26 Private PAPU RANAP Signalling (Primary)
Iu_C_sec 925 1X/26 Private PAPU RANAP Signalling (Secondary)
Iu_U 922 1X/27 Private IPPU IuPS User Plane
Gb 911 1X/28 Private GBU Gb User & Control Plane
S1-MME-Pri 380 1X/29 Private IPDU S1-MME Control Plane (Primary)
S1-MME-Sec 381 1X/29 Private IPDU S1-MME Control Plane (Secondary)
S3-S10-S11 389 1X/29 Private IPDU S11, S10 & S3
Gn-DNS-MME 390 1X/29 Private IPDU Gn-DNS
S6a-S13-Pri 382 1X/29 Private IPDU S6a & S13 Diameter (Primary)
S6a-S13-Sec 383 1X/29 Private IPDU S6a & S13 Diameter (Secondary)
SGs-Pri 384 1X/29 Private IPDU SGs Diameter (Primary)
SGs-Sec 385 1X/29 Private IPDU SGs Diameter (Secondary)
S3-S4-C 388 1X/26 Private PAPU S3 & S4-C
Sv 386 1X/29 Private IPDU Sv Signalling
Gn_C 912 1X/26 PUBLIC PAPU Gn Control Plane
Gn-S4U-3G 926 1X/28 PUBLIC IPPU Gn & S4 User Plane
Gn_S4U-2G 921 1X/28 PUBLIC GBU Gn User & Control Plane of 2G
L3 Interface 16xVLANs 16x/30 Private SWUs
Loopbacks - 32x/32 Private SWUs
3.4.2.5 IP Address and VLAN Allocation
3.4.2.5.1 Site HCMC

The table below shows the existing and new IP address subnets allocated for each upgraded Flexi NS in
HCMC.
Table 53 High Level IP Address Allocation for Flexi NS SGSN-MME in HCMC
Network Element Subnet Type Remark

10.53.32.0/24
Private IP Existing IP
10.53.34.0/25
MME_ATQ0901N 10.53.74.0/29 OAM Private IP New IP
103.53.254.0/26 Public IP Existing IP
103.53.254.160/28 Public IP New IP
10.53.33.0/24
10.53.34.128/25
MME_ATQ0902N 10.53.74.8/29 OAM Private IP New IP
103.53.254.176/28 Public IP New IP
10.53.79.0/23 Private IP New IP
MME_ATC3001N 103.53.255.128/26
Public IP New IP
103.53.255.192/27
MME_ATC3002N 10.53.48.0/24 Private IP Existing IP
66 / 136 © 2017 Nokia

10.53.50.0/25
103.53.255.224/28 Public IP New IP
10.53.49.0/24
10.53.50.128/25
MME_ATC3003N 10.53.82.0/24 Private IP New IP
103.53.255.240 /28 Public IP New IP
Table 54 High Level VLAN Allocation for Flexi NS SGSN_MME in HCMC
Network Element Allocated VLAN ID Remarks

MME_ATC3001N 901-920 New
MME_ATC3002N 941-960 Existing
MME_ATC3003N 961-980 Existing
MME_ATQ0901N 601-620 Existing
MME_ATQ0902N 621-640 Existing
Table 55 High Level IP Address Allocation for Flexi NS SGSN-MME in HCMC.
Network Element Subnet Mask Comments

MME_ATQ0903N 10.53.77.0 23 Private IP
10.53.74.16 29 OAM Private IP
137.59.38.128 25 Public IP
MME_ATQ0904N 10.53.75.0 23 Private IP
10.53.74.24 29 OAM Private IP
137.59.38.0 25 Public IP
Table 56 High Level VLAN Allocation for Flexi NS SGSN_MME in HCMC
Network Element Allocated VLAN ID

MME_ATQ0903N 641 – 660
MME_ATQ0904N 661 – 680
3.4.2.5.2 Site Hanoi

The table below shows the existing and new IP address subnets allocated for each upgraded Flexi NS in
Hanoi.
Table 57 High Level IP Address Allocation for Flexi NS SGSN-MME in Hanoi

10.51.0.0/24
MME_ATHYA01N 10.51.1.0/25 Private IP Existing IP
10.51.152.0/24
67 / 136 © 2017 Nokia

10.51.8.0/24
MME_ATHYA02N Private IP Existing IP
10.51.9.0/25
137.59.36.0/28 Public IP New IP
10.51.128.0/24
MME_ATGBT01N Private IP Existing IP
10.51.129.0/25
137.59.36.16/28 Public New IP
Table 58 High Level VLAN Allocation for Flexi NS SGSN_MME in Hanoi
Network Element Allocated VLAN ID Remarks

MME_ATHYA01N 100-116,392-393 Existing
MME_ATHYA02N 331-350 Existing
MME_ATGBT01N 501-520 Existing
3.4.2.5.3 Site Da Nang
Table 59 High Level IP Address Allocation for Flexi NS SGSN-MME in DaNang
Network Element Subnet Mask Comments

MME_ATADN01N 10.52.111.0 23 Private IP
137.59.37.0 25 Public IP
MME_ATNVL01N 10.52.113.0 23 Private IP
137.59.37.128 25 Public IP
Table 60 High Level VLAN Allocation for Flexi NS SGSN-MME in DaNang
Network Element Allocated VLAN ID

MME_ATNVL01N 1021-1038
MME_ATADN01N 1001-1018
68 / 136 © 2017 Nokia

3.4.2.6 Routing signalling
Table 61 SPC & GT
Center Site Node name NA0 SPC NA0 NA1 SPC NA1 GT SGID
SP Name SP Name NRI
Center 1 Giap Bat MME_ATGBT01N H’106B/04203 SGHN5 H’106B/04203 SGN5N 84900414 14
Center 1 Yen Hoa MME_ATYHA01N H’106C/04204 SGHN3 H’106C/04204 SGN3N 84900415 11
Center 1 Yen Hoa MME_ATYHA02N H’106F/04207 SGHN4 H’106F/04207 SGN4N 84900417 12
Center 3 NVL MME_ATNVL01N H’140B/05131 SNL1N H’140B/05131 SNL1N 84900509 2
Center 3 An Đồn MME_ATADN01N H’140A/05130 SAN1N H’140A/05130 SAN1N 84900508 1
Center 2 HCM-C30 MME_ATC3001N H’2044/08260 SHC3N H’0A2B/02603 SHC3N 84900812 24
Center 2 HCM-C30 MME_ATC3002N H’2011/08209 SHC1N H’0A2C/02604 SHC1N 84900813 25
Center 2 HCM-C30 MME_ATC3003N H’2014/08212 SHC2N H’0A2D/02605 SHC2N 84900814 26
Center 2 HCM-Q09 MME_ATQ0901N H’201A/08218 SHC7N H’0A2E/02606 SHC7N 84900815 21
Center 2 HCM-Q09 MME_ATQ0902N H’2020/08224 SHC8N H’0A2F/02607 SHC8N 84900816 22
Center 2 HCM-Q09 MME_ATQ0903N H’202E/08238 SQ93N H’202E/08238 SQ93N 84900821 23
Center 2 HCM-Q09 MME_ATQ0904N H’202F/08239 SQ94N H’202F/08239 SQ94N 84900822 27
69 / 136 © 2017 Nokia

3.4.3 NetAct
We only upgrade running NetAct system, don’t install new or change any connectivity.
Upgrade current NA01 (HP blade servers, at Ha Noi site) from software version NetAct 15.5MP3 to NetAct
16.8.
To connect to SAM, NetAct server install the “5620 SAM Mediation”, use protocol SOAP over HTTP(S), SOAP
over JMS, (S)FTP.
3.4.3.1 Connectivity
Figure 40 SAM Mediation
70 / 136 © 2017 Nokia

3.4.4 SAM
The SAM use 2 HP DL380 servers for cluster 1+1 redundancy.
Each server included 4 NIC ports and 1 iLO PORT, there’re 2 type of traffic northbound and southbound.
Below are IP plan for SAM:
• SAM name: SAM_MGYHA01N

• IP range: 10.51.30.96/27 & 10.51.30.128/27
• IP between switch and PE routers: 10.51.30.160/30, 10.51.30.164/30
• VRRP is deployed on 2 switches.
• VLAN ID: 353 & 354
• Port SFP on router (via switch):
 Router PE_ASR9010YHA01C & PE_ASR9010YHA02C
 Port on each switch and router: 5 ports/switch, T.B.D
Figure 41 Connection from SAM to router
SAM Server 1 SWITCH 1 PE_ASR9010YHA01C
/30
/30
SAM Server 2 SWITCH 2 PE_ASR9010YHA02C
71 / 136 © 2017 Nokia

3.4.5 CMD
Figure 42 Connection from CMD to switch

cmd-sw01 cmd-sw02
SWHNI_1N Stacking Cables SWHNI_2N
cmd1
Gi 1/37 ETH 1/0/1 ETH 1/0/15 iLO eth4 ETH 2/0/2 ETH 2/0/1 Gi 1/37
VLAN 812
ETH 1/0/2 eth0 eth5 ETH 2/0/19
ETH 1/0/8 eth2 cmd2

iLO ETH 2/0/15
ETH 1/0/20 eth1 eth5 ETH 2/0/20
Gi 1/38 ETH 1/0/18 ETH 1/0/9 eth2 eth6 ETH 2/0/9 ETH 1/0/18 Gi 1/38
FC1 FC2
ETH 1/0/14 SPA SPB ETH 2/0/14
EMC
3.4.5.2 IP Planning
Table 62. IP range allocation
Note name OAM Traffic (for Ga/Gz)

CG_YHA01N 10.51.30.0/28 10.51.30.16/28
CG_Q0901N 10.53.51.128/28 10.53.51.144/28
Note: Large range 10.53.51.128/25 is reserved by MBF, however, only sub-set of the range is planned for
CG_Q0901N
Function
• FCMD acts as Charging gateway for Nokia PS elements: offline charging mediation for Flexi NS 17
(fNokia product) and 7750-SR12-MG 8.R07 (fALU product).
72 / 136 © 2017 Nokia

3.4.6 Traffica
3.4.6.1 Physical connectivity
Figure 43 TNES Server High Level Interface Connectivity
Site
Router 1
GW VIP: x.x.x.1/29
iLO IP=a.a.a.5/29 iLO router 1 x.x.x.2/29
et h0
router 2 x.x.x.3/29
RTT IP=x.x.x.4/29 Mobifone IP Backbone
et h1
Network
et h2
TNES GW VIP: a.a.a.1/29
Traffica App=x.x.x.4/29
Server et h3 router 1 a.a.a.2/29
router 2 a.a.a.3/29
Routing
Destination = SGSN MCHU IP, Next hop = x.x.x.1/29 (Billing VRF) Site
Destination = 0.0.0.0/0, Next hop = a.a.a.1/29 (OAM VRF) Router 2
Network TNES_SGSN x.x.x.x/29 VLAN x (VRF Billing)
Network TNES_TS a.a.a.a/29 VLAn z (VRF OAM)
3.4.6.2 IP Planning
Table 63 Existing TNES Server IP address and VLAN allocation
Server (Server name) Site Requirement IP Subnet VLAN ID (Untagged) Remark

TNES_TS 10.51.129.128/29 517 OAM VRF
(TNES-SGHNI5N) Giap Bat
TNES_SGSN 10.51.129.136/29 518 Billing VRF
TNES_TS 10.51.1.144/29 531 OAM VRF
(TN_ATYHA01N) HNI – Yen Hoa
TNES_TS 10.51.1.152/29 533 OAM VRF
(TN_ATYHA02N) HNI – Yen Hoa
TNES_TS 10.53.51.0/29 3001 OAM VRF
(TN_ATC3001N) HCM-C30
TNES_TS 10.53.51.8/29 3003 OAM VRF
TNES_TS 10.53.51.16/29 3005 OAM VRF
TNES_TS 10.53.51.24/29 3007 OAM VRF
(TN_ATHBT01N) HCM-C30
TNES_TS 10.53.51.32/29 3009 OAM VRF
(TN_ATHBT02N) HCM-C30
73 / 136 © 2017 Nokia

Table 64 New TNES Server IP address and VLAN allocation
TNES Name Site VLAN NAME IP Subnet VLAN ID Remark

TN_ATDNG01N-TS 10.52.114.240/29 1039 VRRP on GW routers – OAM VRF
TN_ATDNG01N DNG-NVL
TN_ATDNG01N-SG 10.52.114.248/29 1040 VRRP on GW routers – Billing VRF
TN_ATDNG02N-TS 10.52.112.240/29 1019 VRRP on GW routers – OAM VRF
TN_ATDNG02N DNG-AND
TN_ATDNG02N-SG 10.52.112.248/29 1020 VRRP on GW routers – Billing VRF
TN_ATQ0903N-TS 10.53.78.240/29 659 VRRP on GW routers – OAM VRF
TN_ATQ0903N HCM-Q9
TN_ATQ0903N-SG 10.53.78.248/29 660 VRRP on GW routers – Billing VRF
TN_ATC3004N-TS 10.53.76.240/29 679 VRRP on GW routers – OAM VRF
TN_ATC3004N HCM-Q9
TN_ATC3004N-SG 10.53.76.248/29 680 VRRP on GW routers – Billing VRF
3.4.7 FMA
3.4.7.1 Physical connectivity
Figure 44 Existing FMA Server High Level Interface Connectivity
Routing Gateway on Site Router

Destination = 0.0.0.0/0, Next hop = GW IP: 10.51.1.129 GW IP: 10.51.1.129 Site Yen Hoa
10.51.1.132 iLO Gi 3/1
10.51.1.133 PORT 1 Gi 3/2
PORT 2
PORT 3
OM_FMYHA1N
PORT 4 Mobifone IP Backbone
Network
10.51.1.140 iLO Gi 3/1
10.51.1.141 PORT 1 Gi 3/2
PORT 2
PORT 3
OM_FMYHA2N Gateway on Site Router
PORT 4 GW IP: 10.51.1.137
Routing
Destination = 0.0.0.0/0, Next hop = GW IP: 10.51.1.137
FMAHNI1N-OAM VLAN ID: 117 IP: 10.51.1.128/29
FMAHNI1N-OAM VLAN ID: 118 IP: 10.51.1.136/29
3.4.7.2 IP Planning
Table 65 Existing FMA Server IP address and VLAN allocation
Server
Site Requirement IP Subnet VLAN ID Remark
(Server name)
FMA Server#1
HNI- Yen Hoa 1x/29 , 1 VLAN 10.51.1.128/29 117 (Untagged)
(OM_FMYHA1N)
FMA Server#2
HNI- Yen Hoa 1x/29 , 1 VLAN 10.51.1.136/29 118 (Untagged)
(OM_FMYHA2N)
74 / 136 © 2017 Nokia

3.4.8 DNS
Figure 45 DNS traffic - Redundant GRID Master with HA Pair
Active Site SW PE Router PE Router Site SW Active

LAN 1: IP3 LAN 1: IP3
HA: IP2 HA: IP2

Grid Master
Grid Master
HA Pair
HA VIP: IP1
HA VIP: IP1
HA Pair
Loopback
Loopback
GW for DNS traffic GW for DNS traffic
Mobifone Gn/Gi
LAN 1: IP5 LAN 1: IP5
Network
HA: IP4 HA: IP4

Passive Passive
Ha Noi DC HCM DC
Figure 46 Infoblox OAM
Active OAM SW PE Router PE Router OAM SW Active
MGMT: IP1 MGMT: IP1

Grid Master
Grid Master
HA Pair
HA Pair
GW for Infoblox OAM GW for Infoblox OAM
Mobifone OAM
MGMT: IP2 Network MGMT: IP2
Passive Passive
Ha Noi DC HCM DC
3.4.8.2 IP Planning
Each Cluster DNS server need 10 IP addresses:
• 4 IP for DNS traffic. (GnDNS use public IP, GiDNS use private IP)
• 2 IP for HA. (GnDNS use public IP, GiDNS use private IP)
• 2 IP for management. (private IP)
• 2 IP for LOM. (private IP)
75 / 136 © 2017 Nokia

Table 66 IP requirement
Site Hostname Server no. Traffic type Subnet Value VLAN ID
DNS traffic & HA 1x/28 10.51.30.32/28 30
GNDNSYHA_1N 1&2 Loopback (Public) /32 x.x.x.x/32 N/A
Mgmt & LOM 1x/28 10.51.30.48/28 31
Ha Noi
DNS traffic & HA 1x/28 10.51.30.64/28 32
GIDNSYHA_1N 1&2 Loopback (Private) /32 x.x.x.x/32 N/A
Mgmt & LOM 1x/28 10.51.30.80/28 33
DNS traffic & HA 1x/28 10.53.87.0/28 ?
GNDNSQ09_1N 1&2 Loopback (Public) /32 x.x.x.x/32 N/A
Mgmt & LOM 1x/28 10.53.87.16/28 ?
Ho Chi Minh
DNS traffic & HA 1x/28 10.53.87.32/28 ?
GIDNSQ09_1N 1&2 Loopback (Private) /32 10.53.87.254/32 N/A
Mgmt & LOM 1x/28 10.53.87.48/28 ?
3.4.8.3 DNS records
• TAI is used as input parameter for finding the S-GW during initial attach.
• APN is used as input parameter for finding the P-GW during intial attach.
• GUTI is used as input parameter for finding the old MME/R8 SGSN during Tracking area update.
• RNC ID is to resolve target SGSN during Inter-system handover from LTE to 3G.
• RAI is used by MME to find old SGSN during inter-system attach.
Figure 47: DNS records in 4G
TAI S-GW
APN P-GW
GUTI MME
RAI SGSN
RNC ID SGSN
76 / 136 © 2017 Nokia

3.4.8.3.1 TAI records
TAI FQDN record is used to resolve a list of S-GW hosts that serves the Tracking area.
TAI/TAC is also used to retrieve the context from old MME during initial attach or from new MME during
inter-MME handover.
If topological closeness is considered, prefix label topon/topoff MUST be dded to the hostname.
When both collocation and topological closeness are enabled, the MME selects S-GW and P-GW in the
following order of preference:
7. collocated S-GW and P-GWs

1. topologically closer S-GW and P-GW
2. S-NAPTR order
3. priority and weight order.
In this trial, collocation is enabled.

ZBIM:DNS: TOP=ON,COLOC=ON:;
3.4.8.3.2 APN records

APN records in DNS are used to resolve the S5/S8 and Gn of the P-GW IP address.
MME select the P-GW based on the NAPTR records return from DNS server.
Flag “a” indicate that the next lookup will be using a A record.
In this trial, one dedicated APN is defined for 4G: m-lte. It has to be defined in APN records for both the new
MME DNS and existed 2G/3G DNS. For detaild records for the new MME DNS, please refer the datafill MME
DNS planning.xls file. For existed 2G/3G DNS, a new records need to be added if APN m-lte is allowed to use
in 2G/3G network.
m-lte.ap IN NAPTR 200 999 “a” “x-3gpp-pgw:x-gn:x-gp” “” topon.gnlb.ggfinggbt01n.node
topon.gnlb.ggfinggbt01n.node IN A 113.187.3.64
3.4.8.3.3 GUTI records

GUTI records are used to resolve old MME during inter-eNodeB with inter-MME handover (S10 interface), or
inter-rat handover (S3 interface between MME and R8 SGSN or gn interface between MME and pre-Rel8
SGSN).
3.4.8.3.4 S-GW and P-GW node records

According to 3gpp ts29.303, if TAI or RAI isn’t obtained, MME/SGSN selects S-GW from SGW’s canonical node
records.
3.4.8.3.5 RNC ID record

SGSN selection: If the UE moves with TAU/RAU between LTE and 2G/3G or with handover from LTE to 3G,
SGSN is selected using DNS (pre-Rel 8 or Rel-8). In inter-RAT handover via Gn (pre-Rel 8) or S3 (Rel 8), the
serving node selects the target SGSN using either RAI or RNC-ID.
In this Mobifone EPC trial, we use RAI records instead. So there is no need to define for RNC id FQDN
records.
77 / 136 © 2017 Nokia

3.4.8.3.6 RAI records
RAI FQDN is used by R8 SGSN/MME to to resolve the old pre-Rel8 SGSN hostname during RAU and 3G attach
(Gn interface).
Regarding the use of RAI FQDN is used by R8 SGSN to select the S-GW during bearer activation (S3
interface-Rel8 SGSN to MME) and resolve the R8 SGSN hostname during RAU and 3G attach (S16 interface-
Rel8 SGSN to Rel8 SGSN), it isn’t used in this Mobifone EPC trial.
In SGSNs ATCA platform in Hanoi, there are 2 PAPU/GBU groups: one for 2G, one for 3G. So DNS queries for
2G RAI records are pointed to all IP addresses of GBUs in 2G group while DNS queries for 3G RAI records are
pointed to all IP addresses of PAPUs in 3G group.
Note that the format for pre-Rel8 DNS records and Rel8 DNS records are different.
Pre-Rel8: racDDDD.lacEEEE.mncYYY.mccZZZ.gprs
Rel8: rac<RAC>.lac<LAC>.rac.epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org
3.4.8.3.7 SOA and NS records

SOA and NS records Specify authoritative information about the EPC DNS zone, including the primary name
server, the email of the domain administrator, the domain serial number, and several timers relating to
refreshing the zone.
In this trial, zone epc.mnc001.mcc452.3gppnetwork.org is defined according to 3GPP standard.

$ORIGIN epc.mnc001.mcc452.3gppnetwork.org.
$TTL 86400; zone TTL
@ IN SOA ns1.mobifone.vn. hostmaster.mobifone.vn. (
2012013526 ; serial
21600 ; refresh after 6 hours
3600 ; retry after 1 hour
604800 ; expire after 1 week
86400 ) ; minimum TTL of 1 day
IN NS ns1.mobifone.vn. ; out-of-zone name server
3.4.8.4 DNS64
To support the increasing number of IPv6 and dual-stack networks, Infoblox DNS servers now support
DNS64, a mechanism that synthesizes AAAA records from A records when no AAAA records exist. When you
enable DNS64 on an Infoblox DNS server, it can operate with a third-party NAT64 device so IPv6-only nodes
can communicate with IPv4-only nodes without any changes to either of the devices.
As illustrated in Figure 17.3, when an IPv6-only host requests the AAAA record of an IPv4-only server and
none exists, a DNS64-enabled server can retrieve the A record of the IPv4 server and synthesize an AAAA
record. The IPv6-only host can then use the synthesized AAAA record, which contains the IPv6 proxy
address for the IPv4 address in the original A record, to initiate communication with the IPv4 host.
78 / 136 © 2017 Nokia

Figure 48 IPv6IPv4
Following are the steps illustrated in above figure:
1. An IPv6-only host sends a recursive query for the AAAA record of the IPv4 server
mail1.corp100.com.
2. The Infoblox DNS server attempts to resolve the request for the AAAA record, and determines that
an AAAA record for mail1.corp100.com does not exist. The DNS server then performs a query for
the A record of mail1.corp100.com.
3. The DNS server creates a synthetic AAAA resource record from the information in the A record, and
returns the synthesized AAAA record to the requesting IPv6 host.
4. The host receives the synthetic AAAA record and sends a packet to the destination address
specified in the synthetic AAAA record. The packet is routed to the IPv6 interface of the NAT64
device, which translates the packet
from IPv6 to IPv4 and forwards it to the server, mail1.corp100.com.
Infoblox DNS servers can return synthesized AAAA records to both IPv4 and IPv6 clients when the client
explicitly requests an AAAA record and none exists for the requested host. If a host has multiple A records,
the DNS server synthesizes an AAAA record for each A record.
Infoblox DNS servers can also synthesize records for reverse-mapping zones. When a DNS server receives a
query for a PTR record in the IP6.ARPA domain whose address matches a configured DNS64 prefix, the
server synthesizes a CNAME record that contains an IPv4 address derived from the IPv6 address in the
query. The server then sends a query for the PTR record so it can resolve the IPv4 address to the hostname.
For example, if a DNS server that is configured to synthesize records for the prefix 2001:db8::/96 receives a
query for the PTR record of 2001:db8::0102:0304, it synthesizes a CNAME record that contains the IPv4
79 / 136 © 2017 Nokia

address 4.3.2.1.in-addr.arpa. The server then resolves the PTR record of the IPv4 address 4.3.2.1.in-
addr.arpa.
If the server obtains the PTR record, then it sends the synthesized CNAME record and the PTR record to the
client. If the zone exists, but there is no PTR record, then the server sends the synthesized CNAME record
only. If the zone does not exist, then the server responds with a SERVFAIL with no answers.
Additionally, Infoblox DNS servers can generate synthesized records for DNSSEC secure zones, but only for
non-DNSSEC clients. A DNS client or resolver includes the EDNS OPT pseudo-RR with the DO (DNSSEC OK)
bit set to indicate that they are requesting DNSSEC data. DNS servers can generate synthesized AAAA
records only when the request does not have the DO bit set. This ensures that DNSSEC clients receive only
valid responses.
For additional information about DNS64, refer to the following Internet drafts:
• http://tools.ietf.org/html/draft-ietf-behave-dns64-11
• http://tools.ietf.org/html/draft-ietf-behave-address-format-10
3.4.9 NTP server
Currently, use below 2 IP addresses for Network Time Protocol:
• Northern: 10.151.9.33
• Southern: 10.151.70.33
3.5 QoS and DSCP Marking
3.5.1 Overview
Several mechanisms are implemented in the network to provide the required level of QoS and guarantee
that the network conforms to the highest standards in terms of service availability bandwidth, transit time,
roundtrip delay, packet loss. This is implemented through packets scheduling, traffic shaping and resources
allocation management.
Each type of traffic (Signaling, OAM and user flows) has specific constraints regarding jitter, delay and loss of
packets. For example, voice Service is a real-time application and it has stringent requirements concerning
the jitter, latency and bandwidth.
Different flows could be differentiated:
LTE Sessions User flows
In the LTE network a bearer is a path defined to carry data flows with specific QoS parameters with
guaranteed capacity, delay and bit error rate.
Each subscriber has at least one default bearer established during the UE attach procedure. In addition, the
subscriber might have several dedicated bearers depending of the type of service he has subscribed. Each
bearer is associated to a QCI, (QoS Class Identifier). This parameter is a scalar between 1 and 9. It identifies
the relative priority of the different active bearers mounted in the LTE access network and also defines the
scheduling to be applied on the data flow that belongs to this bearer.
80 / 136 © 2017 Nokia

Two kinds of bearers have to be differentiated: the guaranteed bit rate bearers (that means a minimum
throughput is guaranteed to the user once it has been established) and the non-guaranteed bearer (that
mean throughput is not guaranteed to the user).
QoS marking for user plane is performed by eNodeB for uplink flows, by the PGW for downlink flows.
LTE Signaling flows:
These flows concern LTE signaling protocols exchanged between LTE network elements at the 3GPP
interfaces.
In the SGW, it concerns only the following interfaces flows
• S5 and S8 GTP-C (Using GTP-Profile)

• Ga (Using Egress interface)
In the PGW/GGSN, it concerns only the following interfaces flows
• S5/Gn and S8/Gp GTP-C (Using GTP-Profile)

• S11 (Using Egress interface)
• Ga (Using Egress interface)
• Gx, Gy (Using Egress interface)
Network Signaling flows:
These flows concern routing protocols and services establishment protocol (OSPF, BGP, LDP, MP-BGP…).
These flows are managed by the routers, services router and depending on the configuration, S/PGW,
SecGW which are based on 7750 chassis and able to deal with dynamic routing protocols.
OAM flows:
These flows concern the OAM of network elements which include the flows between P-GW and the servers
(SAM…) which manage, configure, supervise and debug these network elements.
3.5.2 QoS requirements of Mobifone network for the LTE deployment.
Table 67 QoS mapping

Default Setting Customer Setting
Traffic type DSCP value DSCP value
QCI PHB QCI PHB
(decimal) (decimal)
Conversational voice 1 46 EF 1 46 EF
Conversational video 2 26 AF31 2 46 EF
Realtime gaming 3 46 EF 3 46 EF
Non-conversational video 4 28 AF32 4 34 AF41
IMS signalling 5 34 AF41 5 46 EF
Voice, video, interactive gaming 6 18 AF21 6 18 AF21
Video (buffered streaming) 7 20 AF22 7 34 AF41
8 10 AF11 8 0 BE
TCP-based (e.g: www, email, ftp, p2p file sharing)
9 0 BE 9 0 BE
C-plane - 46 EF 46 EF
S-plane - 46 EF 46 EF
M-plane - 34 AF41 18 AF21
ICMP - 10 AF11 46 EF
IKE traffic - 34 AF41 46 EF
SSE (Site Support Equipment) - 10 AF11 0 BE
BFD1 to BFD16 - 34 AF41 46 EF
81 / 136 © 2017 Nokia

3.6 Pooling
3.6.1 Pool location
Pooling in general is a 3GPP feature enabling radio nodes to connect to several core network elements. The
set of core network elements serving the same geographical area (connected to the same radio nodes) is
referred to as a ‘pool’. Pooling has been standardized for GERAN, UTRAN and E-UTRAN access networks and
for all three accesses the basic concept of pooling is the same. The 2G and 3G pooling details are nearly
identical while the LTE pooling details differ slightly due to the fact that for 2G/3G, the pooling feature is an
optional addition, while the whole LTE system has already been built to support pooling from the beginning.
When pooling is enabled, the radio nodes try to maintain the initially chosen core network element for the
UE as long as the UE stays within the pool area. As the initially chosen network element is indicated in the
subscriber’s temporary identifier, it is also possible to maintain the same core network element between
attaches.
Pooling provides geographical resiliency due to the fact that a single radio node is connected to several core
elements and thereby a failure of an individual core network element never results in a geographical outage.
This also means that core network element maintenance-related actions become easier, for example, SW
upgrades can be done without causing an outage to the area of the network element being upgraded. The
most visible benefit of pooling, however, is the ability to maintain the same core network element for the
subscriber, which significantly reduces the signaling associated to the core network element changes.
In pooling the UE’s temporary identifier – P-TMSI in 2G/3G, GUTI in LTE – also contains a core network
element identifier with which radio nodes are always able to choose the same SGSN or MME in intra-access
idle mode mobility. Within 2G/3G the core network identifier is NRI and within LTE it is GUMMEI.
If Flexi NS is used in combined SGSN/MME mode, there is additional functionality to maintain the same
physical SGSN/MME network element even upon inter-access changes. This, however, also assumes that the
pool areas of the SGSN and MME in the combined node are aligned.
In Phase 6 Flexi NS upgrade and expansion, 3 SGSN-MME pools will be created. They are as stated below:
• Hanoi pool: 3 Flexi NS nodes

• DaNang pool: 2 Flexi NS nodes
• HCMC pool: 7 Flexi NS nodes
82 / 136 © 2017 Nokia

Figure 49 SGSN MME Pool Locations
HA NOI
FNS
DA NANG
FNS
Flexi NS SGSN/MME
HO CHI MINH
FNS
Table 68 SGSN MME Pools
SGSN MME Pool Node name

Hanoi MME_ATYHA01N
MME_ATYHA02N
MME_ATGBT01N
HCMC MME_ATC3001N
MME_ATC3003N
MME_ATC3002N
MME_ATQ0901N
MME_ATQ0902N
MME_ATQ0903N
MME_ATQ0904N
DaNang MME_ATNVL01N
MME_ATADN01N
83 / 136 © 2017 Nokia

3.6.2 MME Functionality
3.6.2.1 S1 flex (MME pooling)
The S1 flex functionality provides support for network redundancy and load sharing of traffic between MMEs
by creating pools of MMEs, allowing each eNB to be connected to all MMEs within a pool area. eNBs can also
be connected to MMEs in several pools.
Other MMEs within a pool can provide services when one of the MMEs is not available. For example, network
upgrade and maintenance work can be carried out without disturbing the traffic. In addition, MME pooling
reduces signalling load on the S10 interface between MMEs as one MME can serve a larger geographical
area. Overlapping MME pools minimize the number of tracking area updates.
The MME selection function is located in the eNB. To allow eNB to select a specific MME from the pool, each
MME is associated with globally unique MME identifier (GUMMEI), which consists of PLMN Identity, MME group
identity (the pool) and MME code (MME identity within the pool).
Figure 50: Load balancing with MME pools
Table 69 MME pool area vs MME pool
MME pool area MME pool

▪ Area within which a UE may be served without need ▪ Set of MMEs that serve one or more MME pool
to change the serving MME. area.
▪ Is served by one or more MMEs (MME pool) in ▪ Takes advantage of load sharing concept (MME
parallel. selection algorithm) and prevents:
▪ Is a collection of complete Tracking Areas. o Overload: newly incoming requests will
▪ May overlap each other. be distributed between MMEs based on
MME capacity weights.
o Failure: in case of failure, dropped calls
can be reestablished with the
remaining MMEs.
84 / 136 © 2017 Nokia

This functionality permits Ues that are entering into an MME pool area to be directed to an appropriate MME
in a manner that achieves load balancing between MMEs. This is achieved by setting a weight factor (MMERC
– MME relative capacity parameter) for each MME, so that the probability of the eNB selecting an MME is
proportional to its weight factor. The weight factor is typically set according to the capacity of an MME node
relative to other MME nodes. The weight factor is sent from the MME to the eNB via S1-AP messages.
The weight factor can be modified after the establishment of S1-MME connectivity as a result of changes in
the MME capacities. For example, a newly installed MME may be given a very much higher weight factor for
an initial period of time in order to make it increase its load faster.
MME pooling is configured as part of system parameter configuration.
3.6.2.2 MME pool overlap
MME Pool overlap is a deployment technique that an LTE operator may utilize to limit the amount of
handover and tracking area update signaling in the core network.
In LTE the following geographic areas are defined. The basic building block is the cell coverage area. A group
of cells, typically contiguous, make up a tracking area (TA). A group of complete TAs constitutes an MME Pool
area. TAs don’t overlap but MME Pool areas may indeed overlap. When they do overlap they have one or
more complete TAs in common. A particular TA can be a member of more than one MME Pool Area.
An MME Pool area is serviced by a distinct set of MMEs referred to as an MME Pool. When a UE attaches it will
be assigned an MME that services the pool area the UE is in. Following is a simple example of how MME Pool
overlap might be used.
Imagine a city with eastern and western suburbs and a downtown area in the middle.
Figure 51: MME pool overlap
MME1 MME2 MME3 MME4
Western Suburbs Downtown Eastern Suburbs
TA X
MME Pool Area 1 MME Pool Area 2
The western suburbs are MME pool area 1, served by MME 1 and 2. The eastern suburbs are MME pool area
2, served by MME 3 and 4. The two pool areas intersect/overlap in the downtown area which in the example
is a single TA namely Tracking Area 'X'.
The users waking up in the morning in the eastern and western ‘burbs will be assigned MMEs from their
respective pools depending on where they powered up. When rush hour brings users to work in the
85 / 136 © 2017 Nokia

downtown area, TA ‘X’ in the picture, there is no need to do MME handover as TA ‘X’ is part of both MME
pool areas. At the end of the day when users travel home the same benefit of reduced MME handover is
realized.
The reduction in MME handover that this configuration enables results in a major benefit in that it saves
on signaling message processing in the network resulting in capacity gains in the MME, the HSS and the SGW.
3.6.2.3 Provision of mapped GUMMEIs
In standard SGSN only and MME only deployment, NRI and GUMMEI identifiers guarantee that radio nodes
are able to maintain the same SGSN network element or an MME network element during intra-access idle
mode mobility within pool.
However, if Flexi NS is operated in combined SGSN/MME mode and there is also a preference to maintain
the same physical network element during inter-access changes, additional functionality ensures that the
same node is also kept on inter-RAT mobility. This is because during access changes between 2G/3G and
LTE, when the ISR is not active, the UE does not use the native temporary identifier of the target system, P-
TMSI or GUTI. Instead, it creates the target radio access identifier based on 3GPP defined mapping rules.
The following figure illustrates how the UE constructs the GUMMEI when it performs access change from
2G/3G to LTE (the mapping is specified in 3GPP TS 23.003):
Figure 52 Mapping of 2G/3G identifiers to LTE GUMMEI
In case the same physical SGSN/MME is required to be maintained in 2G/3G-to-LTE access change, the eNB
needs to be communicated so that it recognizes not only the MME’s native GUMMEI but also all the possible
GUMMEIs (PLMNs + MMECs + MMEGIs) that are a result of the identifier mapping.
For this purpose, the S1-SETUP-RESPONSE message specified in 3GPP TS 36.413 contains a Served GUMMEI
IE. It is possible for the MME to include different Served GUMMEIs for each supported radio access
technology. The native LTE GUMMEI is always encoded as the first entry. Additional Served GUMMEIs are
used to provide the eNB with GUMMEIs that are the result of the identifier mapping described in Figure
Mapping of 2G/3G identifiers to LTE GUMMEI.
The UE maps LAC to the MMEGI field and NRI to the MMEC field of the GUMMEI. Therefore, the eNB needs to
be provisioned with such Served GUMMEIs that have an MMEGI entry for each LAC that the collocated SGSN
86 / 136 © 2017 Nokia

application hosts and also with an MMEC entry for each NRI that the collocated SGSN application is
configured with.
The following figure illustrates the correlation of S1 SETUP RESPONSE contents, the data MME provides to
eNB and identifier mapping in the UE:
Figure 53 MME selection in idle mode IRAT change to LTE
When Flexi NS operates in combined SGNS/MME mode and the collocated SGSN is pooled, the MME
application reads the collocated SGSN’s PLMN, LAC and NRI configuration and includes it as additional
Served GUMMEIs into the S1AP S1-SETUPRESPONSE message. Separate Served GUMMEIs are used for 2G
and 3G access technologies.
If SGSN’s NRI or LAC configuration changes, MME uses the S1AP MMECONFIGURATION-UPDATE message to
update the Served GUMMEIs to the eNBs.
3.6.2.4 Inter-RAT mobility
Typically, in IRAT handovers between SGSN and MME, the core network element performs a DNS query to
resolve the core network element hosting the handover target. In pooled systems, the DNS returns IP
addresses of several core network elements from which one is chosen based on load-balancing algorithms.
87 / 136 © 2017 Nokia

However, when using the combined SGSN/MME element, there is also a preference to maintain the same
physical SGSN/MME network element in the IRAT handover. To achieve this, when receiving the S1AP
Handover Required message with 3G target, the MME first checks whether the collocated SGSN’s
configuration hosts the target RNC/RA. If the target RNC/RA is not found, MME proceeds with a DNS query.
If the handover target RNC/RAI is found from the local SGSN configuration, the DNS query is omitted and
the handover within the same SGSN/MME network element.
In addition, RAU from the local MME (LTE to 2G/3G RAU) is handled without DNS query, because the local
MME is identified based on the configuration available in the SGSN. The NRI of the SGSN part and the MME
code of the MME part refer to the same node. LAC is mapped to the MME Group ID and NRI is mapped to
MME Code.
<LAC><NRI> = <MME Group Id> <MME Code>
old RAI = <MCC<<MNC><LAC><RAC>
Also when the SGSN receives a reattach message and the P-TMSI points to the local MME, no DNS query is
needed to find the MME.
Alarms
When MME has initiated the MME configuration update procedure towards E-UTRAN, the notice 0222 MME
CONFIGURATION TO E-UTRAN UPDATED is raised.
If the MME is unable to deliver the MME Configuration Update message to one or more eNBs after the
maximum number of retries, disturbance 1384 MME CONFIGURATION UPDATE TO ENB FAILED is raised.
3.6.3 SGSN functionality
3.6.3.1 NRI support
In the current architecture, SGSN supports Multipoint Gb and Iu functionalities according to the TS 23.236
specification. SGSN is identified with the NRI parameter and it is included in P-TMSI or TLLI whenever MS/UE
registers to a core network, either through attach or RAU procedures.
SGSN currently supports NRI lengths 0, 5, 6, 7 and 10 bits. The NRI length 10 bits is disabled when the
SGSN/MME is configured because the fixed maximum size of the MME code (MMEC) is 8 bits.
Adding or modifying the PLMN ID without an SGSN restart is supported in SGSN. Adding new RAI information
(MCC, MNC, RAC, LAC) into an SGSN configuration is also possible without an SGSN restart.
An SGSN restart is needed when the NRI length changes as it changes the PAPU ID bit positions in P-TMSI.
3.6.3.2 MMEC support
Figure SGSN selection in idle mode IRAT change to 2G/3G illustrates how the UE constructs the P-TMSI when
it performs an access change from LTE to 2G/3G. The UE maps the MMEC to the NRI field of the P-TMSI. If
the same physical SGSN/MME is required to be maintained in the LTE-to-2G/3G access change, the GERAN
88 / 136 © 2017 Nokia

and UTRAN radio controllers need to be configured so that an additional NRI matches the collated MME
code.
When SGSN utilizes an NRI that is shorter than 8 bits, the GERAN and UTRAN radio controllers are configured
so that they read only the configured amount of bits from the subscriber’s temporary identifier. If the NRI is
7 bits in length, the BSC and RNC only read 7 bits, the rest is neglected.
This presents a problem, since by definition the MME is identified by an 8 bit MME code (MMEC). Depending
on the SGSN NRI length and the related GERAN/UTRAN configuration, some of the MMEC bits might not be
taken into account while selecting the core network node in BSC or RNC.
This means that when the SGSN NRI is shorter than 8 bits, the MMEC needs to be chosen so that the MME
can be uniquely identified within a pool by the bit amount of the NRI, starting from MSB. For example, if the
NRI length is 6 bits, the MMECs in the pool need to be chosen so that the 2 LSBs of MMEC are insignificant in
MME identification:
Figure 54 SGSN selection in idle mode IRAT change to 2G/3G
If the same physical SGSN/MME is maintained without a DNS query, the local MME is verified based on the
MME configuration available in the SGSN.
• <LAC><NRI> = <MME Group Id> <MME Code>

• old RAI = <MCC<<MNC><LAC><RAC>
89 / 136 © 2017 Nokia

3.6.4 SGSN/MME Pooling parameters
In case handover from 4G to 3G and vice versa The UE maps the MMEC to the NRI field of the P-TMSI. But
MMEC in Nokia has 8 digits length (range from 0 to 255) which is longer than NRI bit (we current choose has
5 digits length) . So to ensure the uniqueness of the converted NRI in the pool, the MMEC needs to be
chosen so that the MME can be uniquely identified within a pool by the bit amount of the NRI, starting from
MSB. For example, if the NRI length is 5 bits, the MMECs in the pool need to be chosen so that the 3 LSBs of
MMEC are insignificant in MME identification. So we can propose like Ericsson
NRI-BIN/DEC MMEC-BIN/DEC
00001___/1 00001.000/ 8
00010___/2 00010.000/16
00011___/3 00011.000/24
...
11111___/31 11111.000/248
We plan some common parameter as below:
• NRI length: 5 bits

• NNRI: 31 (Null NRI)
• NMCC: 452 (Non-broadcast MCC)
• NMNC: 1 (Non-broadcast MNC)
• OFFP: 4s (Offload Periodic RA Update Timer)
Table 70 Show the parameters that required to be configured on Flexi NS for pooling functionality.
Location Pool SGSN/MME CN-ID Non-broadcast Non- NRI MMEC MME Group Relative
LAC Dec/Hex broadcast 5 8 bits ID Dec/Hex ccapacity
RAC bits MMERC
Dec/Hex Weigh Factor
DaNang 1 MME_ATADN01N 3001 65504/FFE0 255/FF 1 8 1301/515 64
DaNang 1 MME_ATNVL01N 3002 65504/FFE0 255/FF 2 16 1301/515 64
DaNang SG_DXDNG02N 3 24
4 32
5 40
6 48
7 56
8 64
9 72
10 80
Hanoi 2 MME_ATYHA01N 1011 65520/FFF0 255/FF 11 88 1102/44E 64
Hanoi 2 MME_ATYHA02N 1012 65520/FFF0 255/FF 12 96 1102/44E 64
DaNang SG_DXDNG01N 13 104
Hanoi 2 MME_ATGBT01N 1013 65520/FFF0 255/FF 14 112 1102/44E 64
15 120
16 128
17 136
18 144
19 152
20 160
HCM 3 MME_ATQ0901N 2011 65488/FFD0 255/FF 21 168 1202/4B2 64
90 / 136 © 2017 Nokia

Location Pool SGSN/MME CN-ID Non-broadcast Non- NRI MMEC MME Group Relative
LAC Dec/Hex broadcast 5 8 bits ID Dec/Hex ccapacity
RAC bits MMERC
Dec/Hex Weigh Factor
HCM 3 MME_ATC3001N 2014 65488/FFD0 255/FF 24 192 1202/4B2 64
28 224
29 232
30 240
31 248
3.6.5 Pooling requirement
To implement pooling, we must doing the below steps:
• Enabling Multipoint-Iu (SG02002) and Multipoint-Gb (SG01023) feature in Flexi NS SGSN/MME.

• Enabling feature Flexible Gb/Iu in BSCs/RNCs (also enable NNSF in the RNCs as it is belong to this
feature).
• Modify the RAI entries in Gn-DNS. (By activating either of the Multipoint-Iu or Multipoint-Gb feature,
the SGSN NRI, which is extracted from subscriber’s P-TMSI, will be inserted in every DNS RAI query
that sent out from the SGSN. Therefore, modification of the RAI entries in Gn DNS is needed.)
• IP Backbone should provide IP for IuPS and Gb traffic to make sure bi-directional communication
between BSC/RNC to multiple SGSN/MME.
• For LTE, on LTE the multipoint S1 is inbuilt and most of the building blocks of multipoint S1 are part
of basic functionalities.
• Connect RNC/BSC to all SGSN/MME within each pool.
3.6.6 SGSN MME Pool Configuration
Table 71 Hanoi SGSN MME Pool Configuration

SGSN Pool MME Pool
SGSN-MME NRI NRI Null Non-broadcast Non-broadcast Non-broadcast Non-broadcast MME MME Relative
CNID
Name value length NRI MCC MNC LAC (dec) RAC Code Group ID Capacity
MME_ATYHA01N 11 5 31 452 1 65520 255 1011 88 1102 64
MME_ATYHA02N 12 5 31 452 1 65521 255 1012 96 1102 64
MME_ATGBT01N 13 5 31 452 1 65522 255 1013 104 1102 64
Table 72 DaNang SGSN MME Pool Configuration

SGSN Pool MME Pool
CNID
MME_ATADN01N 1 5 31 452 1 65504 255 3001 8 1301 64
MME_ATNVL01N 2 5 31 452 1 65505 255 3002 16 1301 64
91 / 136 © 2017 Nokia

Table 73 HCMC SGSN MME Pool Configuration
SGSN Pool MME Pool
CNID
MME_ATQ0901N 21 5 31 452 1 65488 255 2011 168 1202 64
MME_ATQ0902N 22 5 31 452 1 65489 255 2012 176 1202 64
MME_ATQ0903N 23 5 31 452 1 65490 255 2013 184 1202 64
MME_ATC3001N 24 5 31 452 1 65491 255 2014 192 1202 64
MME_ATC3002N 25 5 31 452 1 65492 255 2015 200 1202 64
MME_ATC3003N 26 5 31 452 1 65493 255 2016 208 1202 64
MME_ATC3004N 27 5 31 452 1 65494 255 2017 216 1202 64
92 / 136 © 2017 Nokia

3.6.7 Traffic flows
3.6.7.1 Mobility Management
By enabling the NAS Node selection function (NNSF) in the RAN node, the RAN node will be able to derive the
NRI from the P-TMSI assigned to the subscriber. Then it will use the specific table containing NRI to SGSN
SPC or CNID to select the Iu\Gb connection and route the initial NAS signaling messages to the SGSN with
the NRI that matches the derived one.
But if the selected SGSN node is not available or if no SGSN node signaling point code is configured in the
RAN node for the requested NRI or if the provided identity contains no NRI (e.g. IMSI is used, since it’s the
very first attach) then the RAN node will route the initial NAS signaling message to a SGSN node selected,
using a load balancing algorithm, from the available SGSN nodes.
Since each FlexiNS SGSN has the same capacity, equal load balancing algorithm will be set in the RAN node.
3.6.7.2 Default SGSN vs Old SGSN
The NRI uniquely identifies a given SGSN node out of all the SGSNs serving the same pool area. The new
SGSN tries to extract the NRI from the old P-TMSI, and thus obtain the address of the old SGSN from the
NRI and the old RAI. The NRI-to-SGSN assignments can be either configured by the operator in the new
SGSN or retrieved from a DNS server.
• In scenario “RA updates between pool areas”: SGSNs with multipoint Iu support query the old SGSN
by adding the SGSN specific NRI to the DNS query. Requires new data in the DNS servers. Note:
within a pool area, all RAUs are intra_SGSN RAUs.
• In scenario “RA updates with traditional SGSNs”: All multipoint Iu SGSN must be able to act as
“default” SGSNs for the pool area. DNS query only contains the RAI, instead of the NRI+RAI. DNS
responds with the IP address of one of the SGSNs in the destination pool area.
If the new SGSN cannot extract the NRI from the old P-TMSI, it retrieves the address of the default SGSN
serving the old RA. If the old SGSN used for the routing area is not the default SGSN, the default SGSN
identifies the old SGSN by the NRI in the old P-TMSI, and relays the GTP signaling to it.
This mean:
• If the new SGSN can extract the NRI from PTMSI, use for DNS query and DNS server find the record
then new SGSN will know IP address of old SGSN, then directly send “Context query” to old SGSN.
• If the new SGSN can not extract the NRI from PTMSI, or DNS server can’t find the record
for that NRI then it return the IP address of default SGSN. At default SGSN, after receive
the “Context query”, it will extract the NRI from PTMSI to find out the correct old SGSN (by
doing another DNS query), and relay the GTP signaling.
Note that: If the DNS does not recognize the NRI, it returns the IP address of the default SGSN as
the routing area identity (RAI). The default SGSN must be chosen in such a way that the SGSNs
serving the pool area are loaded equally, for example, with round robin.
93 / 136 © 2017 Nokia

Figure 55 RA updates between pool areas
1. Query: nri013b.rac000e.lac032c.mnc006.mcc244.gprs
2. Response: IP-address-of-SGSN1
3. Context query
SGSN 1 SGSN 2 SGSN 3 SGSN 4 SGSN 5
4. Context response
RA14 RA4
UE
Figure 56 RA updates with traditional SGSNs
4. Query: nri013b.rac000e.lac032c.mnc006.mcc244.gprs 1. Query: rac000e.lac032c.mnc006.mcc244.gprs

5. Response: IP-address-of-SGSN1 2. Response: IP-address-of-SGSN3
6. Context query 3. Context query
SGSN 1 SGSN 2 SGSN 3 SGSN 4
7. Context response
RA14 RA4
UE
94 / 136 © 2017 Nokia

3.6.7.2.1 Handover Cases
This chapter provides information about the possible handover cases in MBF network during migration
phase.
Note that: there’re 2 possible ways to find out the old serving SGSN (default SGSN & old SGSN) as
mentioned in section 3.6.7.2. The difference is more steps (DNS query&response, and relay GTP signaling) if
use default SGSN. From now on, the term we use in handover case is default SGSN, but the scenario is same
with old SGSN, just more steps.
Below figure shows the network setup used as assumption for handover scenario listed in below tables.
Figure 57: Network Scenario

DX200-1 FNS-1 FNS-2 FNS-3
RNC-4 RNC-3
RA4 RA3
BSC-4 BSC-3 BSC-1 BSC-2 RNC-1 RNC-2

RA8 RA7 RA5 RA6 RA1 RA2
Pool Area
Table 74 Handover scenario (3G-3G)
No. Handover case RAN Inter/Intra SGSN DNS RAI query DNS response
Pool/Non-
pool
1 Between RA1 and RA2 Within pool Intra-SGSN,
area Intra PAPU
group
2 From RA1 (session Pool to Non- Intra-SGSN,
served by FlexiNS1) to Pool Intra PAPU
RA3 group
3 From RA1 (session Pool to Non- Inter-SGSN FlexiNS1 send RAI query = IP address of FlexiNS2
served by FlexiNS2) to Pool NRI(NS2)+RA1 (3G-PAPUs)
RA3
4 From RA1 to RA4 Pool to Non- Inter-SGSN DX200 SGSN send RAI IP address of Default SGSN
Pool query = RA1 only (3G-PAPUs) for RA1
5 From RA3 to RA4 Non-Pool to Inter-SGSN DX200 SGSN send RAI IP address of FlexiNS1
Non-Pool query = RA3 only (3G-PAPUs)
6 From RA3 to RA1 Non-Pool to Intra-SGSN,
Pool
95 / 136 © 2017 Nokia

Pool/Non-
pool
Note: When the request Intra PAPU
come to RNC1, RNC1 group
will direct the session
to FlexiNS1, since the
P-TMSI contain
FlexiNS1’s NRI.
7 From RA4 to RA1 Non-pool to Inter-SGSN Option1 Option1
Note: When the request Pool Step1: FlexiNS send RAI Step1 response: No such
come to RNC1, RNC1 query = NRI (random no.) + name
will direct the session RA4 Step2 response: IP address
to either FlexiNS1 or Step2: FlexiNS send RAI of DX200 SGSN (3G-PAPUs)
FlexiNS2 (loadsharing). query = RA4 only Option2*
Option2* Response: IP address of
FlexiNS send RAI query = DX200 SGSN (3G-PAPUs)
NRI (random no.) + RA4
* Note: Option2 is for the case that the “*.” Prefix is added into the non-pool RAI (RA4 for this case).
Table 75: Handover scenario (2G-2G)
Pool/Non-
pool
1 Between RA5 and RA6 Within pool Intra-SGSN,
area Intra PAPU
group
2 From RA5 (session Pool to Non- Intra-SGSN,
served by FlexiNS1) to Pool Intra PAPU
RA7 group
served by FlexiNS2) to Pool NRI(NS2)+RA5 (GBU/PAPU pairs)
RA7
4 From RA5 to RA8 Pool to Non- Inter-SGSN DX send RAI query = RA5 IP address of Default SGSN
Pool only (GBU/PAPU pairs) for RA5
5 From RA7 to RA8 Non-Pool to Inter-SGSN DX send RAI query = RA7 IP address of FlexiNS1
Non-Pool only (GBU/PAPU pairs)
6 From RA7 to RA5 Non-Pool to Intra-SGSN,
Note: When the request Pool Intra PAPU
come to BSC1, BSC1 group
will direct the session
to FlexiNS1, since the
P-TMSI contain
FlexiNS1’s NRI.
7 From RA8 to RA5 Non-pool to Inter-SGSN Option1 Option1
come to BSC1, BSC1 query = NRI name
will direct the session (random no.)+RA8 Step2 response: IP address
to either FlexiNS1 or Step2: FlexiNS send RAI of DX200 (2G-PAPUs)
FlexiNS send RAI query = DX200 (2G-PAPUs)
NRI (random no.)+RA8
96 / 136 © 2017 Nokia

Table 76: Handover scenario (2G-3G)
Pool/Non-
pool
1 From RA1 to RA5 Within pool Intra-SGSN, FlexiNS1 send RAI query = IP address of FlexiNS1
(session served by area Inter-PAPU NRI(NS1)+RA1 (3G-PAPUs)
FlexiNS1) (3G->2G) group
2 From RA1 and RA5 Within pool Intra-SGSN, FlexiNS2 send RAI query = IP address of FlexiNS2
(session served by area Inter-PAPU NRI(NS2)+RA1 (3G-PAPUs)
3 From RA5 to RA1 Within pool Intra-SGSN, FlexiNS1 send RAI query = IP address of FlexiNS1
(session served by area Inter-PAPU NRI(NS1)+RA5 (GBU/PAPU pairs)
4 From RA5 and RA1 Within pool Intra-SGSN, FlexiNS2 send RAI query = IP address of FlexiNS2
(session served by area Inter-PAPU NRI(NS2)+RA5 (GBU/PAPU pairs)
5 From RA1 (session Pool to Non- Intra-SGSN, FlexiNS1 send RAI query = IP address of FlexiNS1
served by FlexiNS1) to Pool Inter-PAPU NRI(NS1)+RA1 (3G-PAPUs)
RA7 (3G->2G) group
served by FlexiNS2) to Pool NRI(NS2)+RA1 (3G-PAPUs)
RA7 (3G->2G)
Pool query = RA1 only (3G-PAPUs) for RA1
(3G->2G)
8 From RA5 (session Pool to Non- Intra-SGSN, FlexiNS1 send RAI query = IP address of FlexiNS1
served by FlexiNS1) to Pool Inter-PAPU NRI(NS1)+RA5 (GBU/PAPU pairs)
RA3 (2G->3G) group
served by FlexiNS2) to Pool NRI(NS2)+RA5 (GBU/PAPU pairs)
RA3 (2G->3G)
Pool query = RA5 only (GBU/PAPU pairs) for RA5
(2G->3G)
11 From RA7 to RA1 Non-Pool to Intra-SGSN, Option1 Option1
Note: When the request Pool Inter-PAPU Step1: FlexiNS1 send RAI Step1 response: No such
come to RNC1, RNC1 (2G->3G) group query = NRI (NS1)+RA7 name
will direct the session Step2: FlexiNS1 send RAI Step2 response: IP address
to FlexiNS1, since the query = RA7 Only of FlexiNS1 (GBU/PAPU
P-TMSI contain Option2* pairs)
FlexiNS1’s NRI. FlexiNS1 send RAI query = Option2*
NRI (NS1)+RA7 Response: IP address of
FlexiNS1 (GBU/PAPU pairs)
12 From RA8 to RA1 Non-Pool to Inter-SGSN Option1 Option1
come to RNC1, RNC1 (2G->3G) query = NRI (random name
will direct the session no.)+RA8 Step2 response: IP address
13 From RA3 to RA5 Non-Pool to Intra-SGSN, Option1 Option1
Note: When the request Pool Inter-PAPU Step1: FlexiNS1 send RAI Step1 response: No such
come to BSC1, BSC1 (3G->2G) group query = NRI (NS1)+RA3 name
97 / 136 © 2017 Nokia

Pool/Non-
pool
will direct the session Step2: FlexiNS1 send RAI Step2 response: IP address
to FlexiNS1, since the query = RA3 Only of FlexiNS1 (3G-PAPUs)
P-TMSI contain Option2* Option2*
FlexiNS1’s NRI. FlexiNS1 send RAI query = Response: IP address of
NRI (NS1)+RA3 FlexiNS1 (3G-PAPUs)
14 From RA4 to RA5 Non-Pool to Inter-SGSN Option1 Option1
come to BSC1, BSCC1 (3G->2G) query = NRI (random name
will direct the session no.)+RA4 Step2 response: IP address
98 / 136 © 2017 Nokia

3.6.7.2.2 Handover from pool to non-pool (Use of Default SGSN)
In the handover case from pool to non-pool area and the the target SGSN (new SGSN) is not able to extract
the NRI from the old P-TMSI (e.g. SGSN with no multipoint feature enabled), it retrieves the address of the
Default SGSN serving the old RA. If the old SGSN used for the routing area is not the default SGSN, the
default SGSN identifies the old SGSN performing a query to the DNS containing the NRI extracted from the
old PTMSI, and relays the GTP 99ignaling to it.
Note that in NSN implementation, each SGSN in a pool can act as the default SGSN.
Below figure shows the traffic flow for the case that involves Default SGSN functionality.
Figure 58: Default SGSN Functionality
99 / 136 © 2017 Nokia

3.6.7.2.3 Handover from Non-Pool to Pool area
In summary, when the subscriber comes back to RA in the pool area, after being under a “normal non-pool
area”, the load-balancing mechanism in the RNC will choose one SGSN in the pool serving the pool RA.
The chosen SGSN will perform a query to the DNS containing the old RA and the NRI that it extracts from P-
TMSI according to the configured NRI length.
Since the DNS doesn’t have this entry (since the old SGSN doesn’t have Iu Multipoint feature), it will send a
response containing “host not found” (Reply code: No such name (3)).
As a consequence, the chosen SGSN will send a second query this time without NRI, but only with old RAI.
The DNS will correctly respond this time with the IP address of the previous serving SGSN and the routing
area update will continue as normal.
Below figure shows traffic flow for this handover case.
Figure 59: Non-pool to Pool handover
As explained, two times of DNS query are required for resolving the previous serving SGSN address when
the subscriber is handover from non-pool are to pool area.
With this two times DNS query, it causes the additional 100ignaling message to the network and potentially
adding the delay to the non-pool to pool area handover operations.
100 / 136 © 2017 Nokia

The solution for this impact can be done by adding the additional RAI entries of the “nonpool area” with the
prefix of “*.”
The format would be as follows:
*.rac<non-pool RAC>.lac<non-pool LAC>.mnc0003.mcc01F9.gprs
It is to be noted that this entry type will need to be removed when the respective nonpool area have been
migrated into the pool area.
Below figure shows the traffic flow with the additional “*.” Prefix implemented on the RAI of the non-pool
area.
Figure 60: Non-pool to Pool handover
101 / 136 © 2017 Nokia

3.6.7.2.4 3G to 4G in SGSN/MME Pooling Scenario
GGSN_SGW_PGW_1 GGSN_SGW_PGW_2
1. UE does RAU/Attach Request to SGSN_MME_1.
2. After the successful Auth Process, SGSN_MME_1 creates new
PTMSI with SGSN and PAPU identification value embedded.
3. PTMSI is shared with UE in RAU/Attach Accept message.
4. UE maps the PTMSI value to GUTI value.
5. UE sends a TAU with GUTI constructed from PTMSI.
SGSN_MME_1
SGSN_MME_2
2 6. Based on the MMEC ID present in GUTI, eNodeB_2 will forward
POOL the request to SGSN_MME_1
4
3
6
PTMSI NRI
eNodeB_2
RNC_1
RAI LAC RAC
1 5
GUTI MMEGI MMEC
3.6.7.2.5 4G to 3G in SGSN/MME Pooling Scenario

GGSN_SGW_PGW_1 GGSN_SGW_PGW_2
1. UE does TAU/Attach Request to SGSN_MME_1.
2. After the successful Auth Process, SGSN_MME_1 creates new
GUTI with MMEGI and MMEC identification value embedded.
3. GUTI is shared with UE in TAU/Attach Accept message.
4. UE maps the GUTI value to PTMSI value.
5. UE sends a RAU with PTMSI constructed from GUTI.
SGSN_MME_1
SGSN_MME_2
2 6. Based on the NRI ID present in PTMSI, RNC_2 will forward the

POOL request to SGSN_MME_1
4
M-TMSI
3
6
GUTI PLMN-ID MMEGI MMEC
eNodeB_1
RNC_2
RAI LAC RAC
23-16 NAS token

1 5 PTMSI NRI from UE
PTMSI Signature
GUTI PLMN-ID MMEGI MMEC

4
M-TMSI
2 bits 1 bits 3 bits 4 bits 22 bits
MMDU Reset Unique ID
11 pair ID Counter number
MMDU
unit ID
102 / 136 © 2017 Nokia

3.7 IPv6 support
3.7.1 User Plane IPv6 Implementation
Mobifone is planning to propose services to access the internet by using the IPv6 addresses for the user
equipment. This solution brings the usage of IPv6 addressing for user plane as can be explained with the
following case ;
• APN IPv4/IPv6 for Internet Services using dual stack: LTE 3GPP TS23.401 release 8 onwards,
defines the capability for a UE to request a single bearer with dual addresses , i.e an IPv4v6 PDN
connection. There is no more need to have two different PDNs and bearers per type of address
before that release. Dual Stack definition used for this case and it is specified in that 3GPP standard
and also well described in RFC 6459.Based on this definition, the implementation at mobile core
should be compliant with Evolved Packet Core and HSS level. As being dual stack still needs IPv4
addressing in which IPv4 address will be used only in case the destination does not support IPv6.In
that case NAT will be used.
• APN IPv6-only for Corporate Services: In this case it is should be guaranteed that the source and
destination are IPv6 compliant .This will be the condition to deploy this type of APN which there will
be no need to have IPv4 addressing for user plane at all .
• APN IPv6-only for Internet Services: The difference between the previous use case and this one is
the fact to consider that it is not guaranteed that the destination end point supports IPv6 which is
still the case for many web sites over internet. In this case additional two features NAT64 and
DNS64 are required to be activated at core network to interact and convert any IPv6 packet
contacting an IPv4 destination to be previously converted to IPv4.DNS64 should be activated in
Mobifone core network .This functionality is described in RFC 6147.The IPv6 address resolution is
performed by using the AAAA type of record. DNS will be resolving the FQDN to a fake IPv6 address
when there is no real one available (only IPv4 one) using a reserved prefix ( named “Pref64::/n) .The
IPv6 addresses representing IPv4 addresses included in AAAA RR synthesized by the DNS64 contain
Pref64::/n and they are also embed to the original IPv4 address. Then NAT64 will perform NAT
functionality for IPv6 addresses having Pref64::/n . This functionality is represented with the
following DNS64/NAT64 traffic flow .
103 / 136 © 2017 Nokia

Figure 61: DNS64&NAT64 Traffic Flow
In Mobifone solution NAT64 functionality should be supported in core network especially on the site
routers.
3.7.2 User Plane IPv6 Stack and Interfaces Impacted
The goal of the IPv6 deployment at user plane is to provide the capacity for a UE to use IPv6 addressing to
access the applications and internet or Corporate services by using the IPv6 addresses. There is no IPv6
addressing implementation at transport,control and OAM planes.As mentioned before 3GPP release 8 8
onwards defines the capability for a UE to request a new single PDN connection for PDN type IPv4v6 Dual
Stack , RFC 6459.
The following figure summarizes the stacks in user plane representing in yellow the header using IPv6 in a
IPv6 PDN connection. As represented there are IPv4 headers at S1-U and S5/S8 ( IPsec is not represented )
meaning that those interfaces are tunnelled over IPv4 with GTP-U.
104 / 136 © 2017 Nokia

Figure 62: E2E stack and interfaces impacted with IPv6
As LTE network user plane is tunneled between UE and PGW , the traffic that is carried over the tunnel will
be using IPv6 but transparent for underlying network. The rest of the nodes in the chain will be carrying a
tunneled user traffic using IPv4 addressing .
The interface which is impacted by IPv6 implementation is the SGi/Gi one which resides on on PGW .
The following figure summarizes the high level architecture with the section impacted by the insertion of
IPv6 user plane.
Figure 63: High Level Architecture IPv6
IPv4 IPv6
IPv6
Web Server
Evolved Packet Core
7750 MG S/PGW
Mobifone Router Mobifone Router ISP Router

Mobile Backhaul
Packet
GTP-U (GTPv2) Backbone
IPv4v6 Internet
UE IPv4 &IPv6
NAT64
IPv6
eNB
IPv6 IPv4
MME
DNS64
Data Subscription with

APN IPv6
HSS
105 / 136 © 2017 Nokia

3.7.3 Mobifone UE IP Address Allocation – IPv6
7750 SR MG supports static and dynamic assigned addressing for IPv4 address and IPv6 prefix as described
in TS 23.401 . In Mobifone solution local IP pools will be configured for UE IP address allocation.
In order to configure IPv6 IP address allocation on 7750 MG the following points has be included with
current solution
• Additional IPv6 transport IP address has to be configured on each transport interface inside Gi
VPRN on 7750 MG . These transport interfaces should be terminated with IPv6 interfaces on
Mobifone site router’s either.
• Particular IPv6 IP pool should be configured which means “ip-local-pool” should be configured with
“IPv6 Prefix” inside Gi VPRN where the IP-Pools are defined.
• IPv6 pools should be advertised by using the routing protocol OSPF towards the Mobifone site
routers .OSPFv3 is used for advertising the IPv6 routes in 7750 MG .The details of the configuration
will be covered in 7750 MG LLD.
• APN should support the IPv6 pdn type ; pdn-type should be configured with pure IPv6 and with dual
stack IPv4v6 .
• APN should include the dns servers with IPv6 address inside the PCO option which is described in
section 3.14.2 . “dns-server-ipv6” should be configured with primary and secondary address.
The following figure summarizes the IPv6 UE IP address allocation structure in 7750 MG .
All the configuration details will be covered with 7750 MG LLD.
Figure 5-3: 7750 MG IPv6 UE IP Allocation
Site Router 1
ip-local-pool
• IPv4 prefix
• IPv6 prefix
VRF Gi-APN
7750 MG
APN
Additional IPv6 addresses required for OSPFv3
VPRN Gi each transport interface
Site Router 2
pdn-type
• IPv4 , VRF Gi-APN
• IPv6,
• IPv4v6
dns-server-ipv6
• Primary address
• Secondary address
106 / 136 © 2017 Nokia

3.8 Service control
3.8.1 PDN services
3.8.1.1 APN Handling
7750 MG PGW/GGSN is the IP anchor for UE regardless of which access network the user initially attaches
from 7750 MG PGW/GGSN supports assigning UE IPv4/v6 address from a local configured pool or supports
assigning UE IPv4/v6 address from collocated DHCP server.
To support overlapping between IP address domains, operators can configure the mapping between APNs
and IP-VPRN (VRF) in the following ways:
• Mapping of a single APN to a single IP VPRN;

• Mapping of multiple APNs to a single IP VPRN.
3.8.1.2 IP Address Allocation
7750 SR MG supports static and dynamic assigned addressing for IPv4 address and IPv6 prefix as described
in TS 23.401 , IP address assignment can be based on the following mechanisms:
• Local IPv4/IPv6 Address Pool;

• Static IP address from HSS;
• RADIUS Server assigned Pool Name;
• RADIUS Server assigned IP address;
• DHCP Proxy Agent IPv4/IPv6;
• IPv6 Stateless address auto-configuration (SLAAC)
To control IP address allocation mechanisms, operators can configure per APN (real or virtual APN), the
following parameters:
• IP allocation method: local, HSS-static, AAA, DHCP-Proxy, DHCP-Relay;

• PDN Type: IPv4, IPv6, IPv4v6;
• PDN Allocation Type: IETF or RAN Signaling. It determines if UE gets the IP address by NAS signaling
or from its DHCPv4 client functionality or IPv6 address stateless auto-configuration after the
default bearer is established;
• IP-VPN (VPRN) and optionally, IP local pools mapped on this IP-VPN.
IP local pools are configured under IP-VPNs. An APN can be mapped to IP-VPN and the IP address pool
allocated to Ues for the given APN, should be configured under the respective mapped IP-VPN. IP local pool
supports both IPv4 and IPv6 prefixes.
Operators can configure per APN the follow parameters that will be provided in PCO options towards UE:
• DNS Server IPv4 primary IP address, secondary IP address;

• DNS Server IPv6 primary IP address secondary IP address;
• P-CSCF IPv4 primary IP address or FQDN;
• P-CSCF IPv6 primary P address or FQDN.
107 / 136 © 2017 Nokia

Routing Protocols (OSPF) will advertise the local IP pools defined in PGW/GGSN. The subscriber IP Pool
prefixes are injected into Routing Table Manager. Routes will be advertised when Routing Policies export the
subscriber routes into respective protocols. Subscribers IP addresses assigned by RADIUS or static IP
addresses from HSS are advertised in the same way whether RADIUS returns a single address or points to a
local pool name.
3.8.1.3 Virtual APN
Virtual APNs allow the operator to override the APN specified by the UE or HLR/HSS to consolidate or
expand APNs. When a UE attaches to the EPC packet core it may provide an APN that indicates the network
to which it desires to attach. Alternatively, the MME or SGSN may assign a different APN learned from the
HSS during the authentication process. The APN is used by the MME or SGSN to determine the
SGW/PGW/GGSN through which the UE is to be attached to the network. Ultimately, the attach request
arrives at the PGW/GGSN in the form of a GTP create request message that contains an APN. The request
may determine the VPRN to which the UE’s PDN connection should be bound and/or several configuration
parameters (IP addressing, charging, DNS servers, and so on) that apply to the PDN connection.
Using the virtual APN feature the operator can override the APN that arrives in the GTP create message and
assign the UE to an APN of choice. This mapping may be configured locally (based on IMSI, MSISDN, or IMEI)
on the PGW/GGSN or it can be obtained from an external system during the session creation. The local
configuration provides option to specify a static APN change for N:1 relation, or selecting the APN based on
subscriber information (such as IMSI) 1:N relation. The APN change may also be performed via specific
RADIUS pre-authentication messaging or S6b.
The following figure shows the examples of virtual APN selection alternatives.
Figure 64: Virtual APN Selection Alternatives
108 / 136 © 2017 Nokia

There are options to configure parameters on a per-interface basis to use either the real or virtual APN in
the messages toward the peer network elements. It is possible to enable multiple virtual APN selection
methods simultaneously for an APN:
• The virtual-apn (static 1:1 mapping) always takes precedence. If it is configured, it is always used
and the other virtual APN configurations are ignored.
• The second priority are the virtual-apn-selection rules. If those rules match, the virtual APN
selection procedure ends. It is possible that multiple rules match, but then the selection-priority
defines which match will be used.
• The selection via pre-auth i.e. by external systems is evaluated last.
As the above rules describe, the real APN can only be overridden once.
The virtual APNs also have their own statistics. If a PDN connection is remapped to a virtual APN, the
statistics for the real APN are not incremented.
3.8.1.4 Mobifone APN Configuration
The APN configuration is still in discussion. The existing APN configuration in Flexi NG GGSN will be
configured for 2G/3G PDN connections in 7750 MG as well. The details of the Flexi NG GGSN apn
configuration can been seen the CIQ files.
Below tables show the existing Flexi NG GGSN APNs and IP Pools for Hanoi sites .
The details will be updated in CIQ files per Hanoi and Ho Chi Minh 7750 MG nodes.
Table 77: Mobifone Existing APNs

Dns-server-
Public-access- dns-server-ipv4
apn Session profile Pcc rule ipv4 Ip-alloc-method Pdn-type
point primary
secondary
m-wap.MNC001.MCC452.GPRS m-lte-pcrf m-wap M0 10.11.197.180 209.244.0.3 local-pool IPv4/IPv6
m-wap.0001 m-wap-no-pcrf m-wap.0001 M0 10.11.197.180 209.244.0.3 local-pool IPv4/IPv6
m-wap.0010 m-wap-pcrf m-wap.0010 M0 10.11.197.180 209.244.0.3 local-pool IPv4/IPv6
Blackberry.net blackberry.net Blackberry.net Null 10.11.197.180 8.8.8.8 local-pool IPv4/IPv6
Vietinbank Vietinbank vietinbank Null 10.11.197.180 8.8.8.8 local-pool IPv4/IPv6
m-wap m-wap-Roaming vietinbank M0 208.67.222.222 209.244.0.3 local-pool IPv4/IPv6
m-wap.0100 m-wap-no-pcrf M0 10.11.197.180 8.8.8.8 local-pool IPv4/IPv6
m-wap.1000 m-wap M0 10.11.197.180 8.8.8.8 local-pool IPv4/IPv6
test-upgrade T.B.D M0 10.11.197.180 8.8.8.8 local-pool IPv4/IPv6
109 / 136 © 2017 Nokia

3.8.2 Application Assurance
3.8.2.1 Overview
The PGW/GGSN integrated Application Assurance (AA) function provides stateful, pattern- and string based
identification of applications to enable dynamic per-application QoS and Charging policy control.
Figure 65: Application Assurance on MS-ISA
3.8.2.2 Application Identification
The AA engine can identify both generic IP based applications as well as typical Mobile applications. It
provides a set of pre-defined application protocol signatures as well as a flexible configuration environment
that allows the operator to easily add purpose built application filters based on multiple string recognition.
Application protocol signatures can identify and measure non-encrypted IP traffic flows using any available
information from Layer 2-Layer 7, and encrypted IP traffic flows using heuristic techniques. Application
Assurance engine attempts to positively identify the protocols and applications for new flows based on a
pattern signature observation of the setup and initial packets in a flow. The system correlates control and
data flows belonging to the same application.
The protocols are identified using a combination of pattern and behavioural techniques. The protocols are
used in generating statistics by protocol, and are used as input in combination with other information to
identify applications.
• Pattern signatures are the set of pattern-match signatures used in analysis.

• Behavior signatures are the set of diagnostic techniques used in analysis.
The signature database file for most common used protocols is delivered by Nokia. It is updated in every
maintenance release and upgradable independently of mobile gateway software. The protocol signatures
are included in a specific software load which is not tightly coupled with software releases allowing for
110 / 136 © 2017 Nokia

protocol signature updates without upgrading and impacting of routing/forwarding engines. The operation
consists in a flexible in-service upgrade of database-file with limited service-impact.
Figure 66: Example of protocols included in signatures file

Application Groups Description Example configured Application classified to this Application Group
Database and Business Business and Citrix, CVS, SQL, FIX, Oracle, SAP, Sybase, IBM_DB2
DataBase traffic
FileServer File Access, backup FTP, TFTP, FTP-overTLS, CIFS, CIFSandSMB, Netbios, Gopher, RSFTP, SFTP
and Storage
Mail Email services Gmail, SMTP, POP3, IMAP, MSexchange, Domino
Network Networking protocols DNS, ICMP, DHCP, Rsync, Isakmp, NTP, BGP, Kerberos, LDAP, LDAP-overTLSS, OSPF, Syslog, SNMP,
for control, SOCKS, SunRPC, Stun, Iperf, UnidatLDM, ActiveDirectory, Authentication, Time, Timed, BootP-Client,
monitoring and BootP-Server, WHOIS, Finger, LDP, LoginWho, PrintServer, RadiusAccounting, RadiusAuthentication,
testing RIP, TACACS
P2P Peer to Peer Ares, BitTorrent, DHT, Direct Connect, Emale, FastTrack, Gnutella, Hotline, Kontik, iManolto, OpenFT,
Filesharing services SoulSeek, WinMX Xunlei
RT_Communication Interactive AOL Instant Messenger, Asterisk, Betamax_VoIP, Ekiga, Google Talk, H323, HeadCall, ICQ, IRC, Jajah,
communication, Megaco, MGCP, MS Communicator, MSN Messenger, Net2Phone, NetMeeting, OhPhone, OoVoo,
including IM and VoIP Primus, QQ, RTP, RTSP, SIP, Skinny, Skype, TeamSpeak, Telepresence, Ventrilo, Vonage, WebEx,
XMeeting, XMPP, Yahoo Messenger
SoftwareUpdate SW version updates WindowsUpdate, AntivirusUpdate, SymantecAntivirus
Streaming Streaming traffic, WindowsMediaPlayer, HTTP_Video, HTTP_Audio, RTMP, RTSP, Ultravox, Shoutcast, RealNetworksRDT,
including webcasts Youtube, GoogleVideo, MoveVideo, Netflix, XboxLiveVideo, iTunes, Hulu, TVU
and conderences
Tunnel and RemoteAccess Tunneling and GRE, SSH, IPsec, IPnIP, RemoteDesktop, Vnc, Rlogin, Shell, Telnet, Telnet-OverTLS,
protocols to allow TermincalEmulation, L2TP, PcAnywhere, Xwindows, TLS, OpenVPN, XoT
remote access
Web Web Browsing Google.com, Yahoo.com, Facebook.com, Myspace.com, Blogger.com, Wikipedia.org, WindowsLive,
Ebay.com, Craigslist.com, Amazon.com, Kijiji.com, MSN.com, ESPN.com, Twitter, Flickr.com, CNN.com,
People.com, Photobucket.com, Weather.com, Bing.com, HTTPS, RSS, HTTP
WebFileHosting One-click file-sharing Megaupload.com, Megavideo.com, Rapidshare.com, 4shared.com, Badongo.com, Easy-share.com,
Web Services Filecloud.com, Gigasize.com, Mediafire.com, Sendspace.com, Up-file.com, Upload.to, Uploading.com,
Yourfilehost.com, Zshare.net
3.8.2.3 Partition
Multiple sets of applications and application match-criteria can be configured in different AA Partition
Policies to support e.g. different traffic identification policies for different APNs.
APN profile is associated to a partition and eventually several APN profiles can refer to the same partition.
3.8.2.4 Application Level Control Policies
AQPs are a numbered list of configurable entries with match criteria and action configured at the
group/partition level. They are complementing PCC rules.
AQP rules consist of match and action criteria:
AQP Match Criteria
AQP can include the following match criteria: the source/destination IP address and port, flow direction
Application name, Application Group or Charging Group name, one or more Application Service Option
characteristics and value pairs.
AQP Actions
It defines actions to be applied to the identified traffic. Several options are available:
111 / 136 © 2017 Nokia

• Dual or single-bucket bandwidth rate limit policer;
• Flow setup rate limit policer;
• Total active flow count limit policer;
• Remark QoS (one or a combination of discard priority, forwarding class name, DSCP). When applied,
ingress marked FC and discard priority is overwritten by AA ISA and the new values are used during
egress processing (for example, egress queuing or egress policy DSCP remarking). For MPLS class-
based forwarding, ingress-marked FC is still used to select an egress tunnel;
• Drop (discard);
• None (monitor and report only);
• HTTP Redirect 404 redirect;
• HTTP Redirect 302 redirect: allows HTTP redirect for selective traffic steering of HTTP traffic while
not affecting other traffic;
• HTTP header enrichment.
Application Profiles typically contain one or more characteristics defined as Application Service Options
(ASOs). The operator can associate each APN profile (real or virtual) to a default application profile to
customize services by matching a specific subset of application QoS policies.
The PCRF will customize characteristics values per subscriber on Gx interface.
3.8.2.5 HTTP Header Enrichment
The Application Assurance function supports modifications of the HTTP header for traffic going to specific
sites (URLs/IPs) in order to add user’s Network based information, such as MSISDN, to the HTTP header.
These sites use the inserted information to authenticate the user and /or present the user with user
specific information / services.
The PGW/GGSN can add of one or more of the following identifiers:
• IMSI
• MS-ISDN
• Subscriber IP address
• IMEI-SV
• RAT-Type
• Charging_Id
• PGW/GGSN address
• SGW/SGSN address.
• APN
• User-Location (ULI)
• Static-String: configured text string
The HTTP header names are configurable for each of these identifiers.
When configured to enrich MSISDN field, the PGW will overwrite any pre-existing MSISDN fields within the
header if the ant-spoofing option is enabled.
112 / 136 © 2017 Nokia

3.8.2.6 Tethering
The operator may request tethering detection and in that case, the GGSN/PGW notifies the PCRF of
tethering state using two Event-Triggers:
• When PGW/GGSN detects a bearer tethering, an APP_CHANGE_TO_TETHERING_STATE event is sent

and,
• When PGW detects that a bearer, which was in tethering state, is no longer tethering, it sends
APP_CHANGE_FROM_TETHERING_STATE event.
The PCRF can install this event-trigger at bearer or IP-CAN session level. The PCRF, based on its knowledge
of the UE subscription, can instruct the PGW/GGSN to block tethered traffic (through a modification of a
PCC rule). It can install a PCC rule that redirects the user’s tethered HTTP traffic to a portal, either to explain
why the service is blocked or to offer additional top-up features.
3.8.3 Per application Policing and Charging Enforcement
3.8.3.1 L7 Service classification
The Application Assurance identification engine is fully integrated into the Policy and Charging Control
Architecture (PCC). All classification and the resulting QoS and billing differentiation are guided by the
subscriber profile.
As a result of flow identification, packets are bound to charging groups. The PCEF can classify applications
into Service Data Flows using identified charging groups. This is reflected in the diagram below:
Figure 67: S/PGW L7 classification
The following services provided by PCEF integrated are available with L7 classification:
• Transport level packet marking in the uplink and downlink;

• Per bearer/PDP Context QoS (Policers for rate-limiting) APN-AMBR for non-GBR QCI bearers;
• Per bearer/PDP Context QoS (Policers) for rate-limiting MBR, GBR for GBR QCI bearers;
• Tethering detection event-trigger
113 / 136 © 2017 Nokia

• Offline / Online flow-based charging
• Usage monitoring at service or session level.
3.8.3.2 Pre-defined PCC rules Configuration
The operator may configure pre-defined PCC rules in the PGW/GGSN that are dynamically instated/removed
by the PCRF. But it is also possible to define static local PCC rules, to be applied when no PCRF is available.
The same data structure is applied in both local policies in PGW/GGSN and dynamic PCC rules.
The PCEF supports three ways to provision PCC rules:
• PCC rules in PCEF (static PCC / no PCRF): Local rules in the PCEF. This configuration is suited for
service offers where the QoS and charging settings is not modified throughout an IP session’s
lifetime or where subscription differentiation is limited.
• Predefined PCC rules in PCEF (predefined rule template within PCRF): The PCC rules are directly
provisioned into the PCEF and activated by the PCRF. The predefined PCC rules cannot be modified
by the PCRF in the PCEF. This configuration is suited in situation where subscriber differentiation is
required and a new service may be established or release dynamically, but the PCC rules are not
exchanged over the Gx interface.
• Dynamic PCC rules provisioned by the PCRF (provisioned rule template within PCRF): The
complete PCC rule is dynamically provided to PCEF by the PCRF via the Gx interface. This
configuration is suited in cases where a new service is setup during the IP session, like an IMS-based
voice service. It allows centralizing the PCC rule management in a single point, i.e. in the PCRF, and
offering more flexibility in the rule management.
The configuration implementation for application identification policy rules is based on a two-level model:
5. At the first level, one or more Policy-Rule-Bases are configured, each with a set of policy-rules to:
5.1. Identify all flows which can be identified just using 5-tuple classification (‘shallow packet-
inspection’). Unless there is a specific requirement to still perform signature-based inspection
on these flows, identification of these flows completes at the policy-rule level and no
processing by the L7 DPI processing engine is required.
5.2. Filter traffic which requires L7 protocol analysis on the DPI inspection engine. The traffic-
match criteria in the policy-rule will in this case refer to the name of a charging-group defined
at the next hierarchy-level in an application policy partition on the AA engine.
6. The second level is configured on the flow detection engine, to define L4-L7 flow match criteria for
traffic which requires L7 protocol analysis including both well-known application protocols (like SIP)
and heuristic analysis for encrypted protocol.
114 / 136 © 2017 Nokia

3.8.4 PCEF
3.8.4.1 Overview
The PCEF function embedded in the Mobile Gateway is compliant with 3GPP Rel-9 PCC architecture defined
in 3GPP TS 23.203, TS 23.401 and can support 2G/3G and LTE subscribers.
The PCEF supports the IP-CAN session establishment, termination and modification procedures. In order to
allow handover between Gn PDP contexts and S5 EPS bearers, a PDP context is treated as an EPS IP-CAN
session (for Gx only).
The PGW/GGSN may perform the following functions:
• Per-user based packet filtering;

• Uplink and downlink service level gating control;
• Downlink bearer binding;
• Downlink rate enforcement based on Aggregate Maximum Bit Rate (APN-AMBR) for all non GBR
bearers belonging to a PDN connection through aggregate policer. Background and Interactive PDP
contexts are similar to non-GBR bearers (QCI 5-9). The MBR rate will match the APN-AMBR if
handover to EPS occurs;
• Downlink rate enforcement based on the accumulated Maximum Bite Rates (MBRs) of the aggregate
of SDFs with the same GBR QCI. Conversational and Streaming PDP contexts are similar to GBR
bearers (QCI 1-4). A policer instance is applied per PDP context or EPS bearer;
• Uplink bearer binding verification: to ensure that UE applies the uplink packet filters correctly and
does not misbehave, e.g., by sending packets on a “premium bearer” even though the packets do
not match the UE’s uplink packet filters associated with that “premium bearer”;
• Transport level packet marking in the uplink and downlink: e.g. setting the DSCP value, based on the
Quality Class Identifier (QCI) of the associated EPS bearer/PDP Context;
• Uplink and downlink service level charging;
• Usage Monitoring at service or session level;
• Event Reporting.
In addition, SGW may perform the following functions:
• Uplink bearer binding verification;

• Transport level packet marking in uplink and downlink: e.g. setting the DSCP value, based on the
Quality Class Identifier (QCI) of the associated EPS bearer.
3.8.4.2 Rate-limiting
Rate-limiting is based on policing. In order to maximize network resource utilization, policing is performed
by tagging. Packets are not immediately dropped but classified as in-profile or out-profile depending on the
configured characteristics of rate policers like Peak Information Rate (PIR), Committed Information Rate
(CIR), Committed Burst Size (CBS), Maximum Burst Size (MBS). These characteristics are derived from QoS
rules (CIR from GBR, PIR from MBR or APN-AMBR) or configured by the operator like CBS and MBS.
115 / 136 © 2017 Nokia

Bandwidth limitation per subscriber is performed separately for non-GBR bearers and GBR bearers and is
based on the following authorized QoS parameters:
• APN-AMBR for all non-GBR bearers of a PDN connection. The APN-AMBR limits the aggregate bit
rate that can be expected to be provided across all Non-GBR bearers of a subscriber session and
across all PDN connections of the same APN. Any Non-GBR bearer can potentially utilize the entire
APN-AMBR, e.g. when the other Non-GBR bearers do not carry any traffic.
• MBR for each GBR bearer. For GBR bearers, the PCEF function sets the bearer MBR to the sum of
the MBRs of all PCC rules that are active/installed and bound to that GBR bearer.
• GBR for each GBR bearer. PCEF also performs DOWNLINK rate enforcement based on the
accumulated GBRs of the aggregate of SDFs with the same GBR QCI (e.g. by rate policing/shaping).
Figure 68: S/PGW Rate-limiting
3.8.4.3 Usage monitoring
The usage monitoring function allows the PCRF to request the PGW to monitor volume or time usage and
report usage against a set of thresholds.
Note _ the online charging (Ro/Gy) protocol may be applied to perform the same function using similar
Diameter AVPs (Granted-Service-Units and Used-Service-Units).
Usage Monitoring is applicable for a single service data flow (SDF), a group of SDFs or for all the traffic in an
IP-CAN session. Usage Monitoring is applicable for service data flows associated with either dynamic PCC
rules or pre-defined PCC rules. A monitoring key is used to group services that share a common allowed
usage. A monitoring key identifies a usage monitoring control instance. Many PCC rules may share the same
monitoring key. PCRF controls the usage monitoring by providing the required usage monitoring
information to the mobile gateway, which includes the monitoring key, associated volume threshold and the
monitoring level (session-level or PCC rule level).
When usage monitoring is enabled, the mobile gateway measures the volume of the IP-CAN session or the
volume of the applicable service data flows and reports the accumulated usage to the PCRF when any of
following conditions is matched:
116 / 136 © 2017 Nokia

• An usage threshold is reached
• All PCC rules associated with a monitoring key are removed or deactivated
• Usage monitoring is explicitly disabled by the PCRF
• An IP-CAN session is terminated
• when requested by the PCRF (on demand)
Usage monitoring is triggered by the PCRF by registering a USAGE_REPORT Event-Trigger.
When the GGSN/PGW notifies the PCRF the termination of the Gx session (as defined in 3GPP 29.212), the
PCEF is required to provide an event report with the outstanding [not-consumed / consumed] granted
service units. Based on the incoming usage update, the PCRF finds the correct metering limit and updates
the actual usage in the SPR.
3.8.4.4 HTTP Redirect Policy
The PCRF may request the PGW/GGSN to perform HTTP/HTTPS redirection. Since the Gx protocol does not
provide a way to convey HTTP redirection parameters to the PGW/GGSN, the PGW/GGSN will support HTTP
redirection by using locally configured PCC rules. Therefore the PCRF can add, modify and delete HTTP
redirection by triggering the corresponding PCC Rule Base. The redirect server (Web Portal) URL is
configured as part of a pre-defined rule.
When a redirection is active, the PGW/GGSN will redirect all TCP port 80 (HTTP) and TCP port 443 (HTTPS)
traffic by sending a 302 Redirect (along with the configured URL) to the UE.
The following use cases are considered:
• Hot-lining: This feature provides the ability for a PCRF to initiate hot-lining of subscriber’s
http/https traffic to a (hot-lining) server whose URL is configured as part of a pre-defined PCC rule.
Hot-lining is used for many applications, but is typically used in cases where the subscriber has not
paid his bill.
• Gx Usage Monitoring: The PCRF may use Gx HTTP redirection in coordination with the Gx Usage
Monitoring feature. The operator may use the re-direction functionality to re-direct a user’s HTTP
traffic to a Top-UP server / Web portal upon reaching a specific usage threshold.
Once the UE is attached, the user can initiate a browser session. On invocation of the browser session the
GGSN/PGW will detect the HTTP request, and the PGW/GGSN will redirect all TCP port 80 (HTTP) and TCP
port 443 (HTTPS) traffic by sending a 302 Redirect (along with the configured URL) to the UE.
The web server authenticates the user using local policy. After successful authentication and whatever
other action required e.g. refilling credit, the web server instructs the PCRF to de-activate the HTTP redirect
rule for this user. In turn the PCRF instructs the GGSN/PGW to remove the rule for this user’s APN. The UE
can now access the internet as well as any local services.
Note : HTTP redirection is provided at the PDN session level only.
3.8.4.5 PCRF Failover and Failure
The operator may configure a primary and a secondary PCRF. When the Primary PCRF goes down, all new
sessions are sent to the Secondary PCRF.
117 / 136 © 2017 Nokia

The operator may also allow existing sessions to be moved to the secondary PCRF when the primary PCRF
fails. When the Primary PCRF recovers, all new sessions will be sent to the primary, but all existing sessions
on the secondary will remain on the secondary. (Existing sessions will be handled in a non-revertive manner.)
Also, the sessions failed over to the secondary must support secondary PCRF initiated Gx session
modifications and terminations via Re-Auth-Request messages.
The PGW/GGSN may continue supporting sessions when either the PCRF is unreachable due to a failure or if
the PCRF responds with a Result-Code = 3xxx or 4xxx (where xxx are wildcard numbers). The operator must
specify if the failure handling is allowed in either case.
The PCRF failure corresponds to situations when PCC is enabled under APN configuration and if the Primary
and the Secondary PCRF are both out of service or there is no secondary configured and the Primary PCRF
goes down.
The PGW/GGSN can fallback to static PCC rules specified at the APN level in these cases.
If failure handling is allowed, new calls will set up without any PCRF control. Any default policy (e.g., Default
Bearer QCI/ARP, APN-AMBR and any other static policy) configured under that APN is applied and such calls
continue without any further PCRF control (even if PCRF recovers) until they are terminated by the UE or
PGW (as a result of idle-timeout or session-timeout timers).
3.9 Charging
3.9.1 SAE-GW
3.9.1.1 Charging profiles
Charging profiles may be used to customize the charging options for a particular PDN connection, based on
the received Charging Characteristics IE (CC). The CC IE includes a single octet charging characteristics value
and is supplied by HSS to MME or SGSN as part of subscriber information and sent from the MME or SGSN to
SGW or PGW/GGSN.
If the PGW/GGSN receives a CC IE in the “Create Session Request” GTP message, it will look for a match
between the value of the CC and any of the Charging Profiles configured in the node. If no matching profile
is found or CC IE is not provided, the PGW applies the configured default charging profile (if any).
Also, the PCRF may provide the charging method to be applied, effectively overriding a local selection.
Separate charging profiles may be defined for home subscribers, home-routed roamers and visiting roamer
(local breakout)
3.9.1.2 Online charging
The PCEF function integrated in the 7750 MG PGW/GGSN performs flow-based online charging as specified
in 3GPP TS32.251, and using the Diameter Credit Control Application defined in 3GPP TS 32.299 and RFC
4006.
118 / 136 © 2017 Nokia

IP-CAN bearer and Service Data Flow online charging are supported. In both cases, charging data pertain to
sessions (IP-CAN bearers) and are associated to the session based online charging (SCUR) with centralized
rating and centralized unit.
The online charging function complies with the following standards:
• 3GPP TS 32.251 v11.8.0: Packet Switched (PS) domain charging (Dec 2013)
• 3GPP TS 32.299 v11.10.0: Diameter charging applications (Dec 2013)
• IETF RFC 3588: Diameter Base Protocol
• IETF RFC 4006: Diameter Credit Control Application
The PGW/GGSN supports Centralized Unit Determination with Centralized Rating. This means that the
PGW/GGSN requests quota based on the service-id and rating-group associated with the PCC rules bound
to the EPS bearer/PDP context and therefore has no idea how many units will be required to offer service.
Furthermore, the PGW/GGSN is not aware of the monetary value of the quota since this is handled by the
OCS.
The PGW/GGSN will request quota and will report usage against the quota provided by the OCS. Credit
control is always on a per-rating group basis.
PGW/GGSN establishes an online charging session for each EPS bearer/PDP Context. It will request and track
quota for rating-groups that belong to the bearer. Therefore each rating-group within a bearer has its own
quota.
Rating-groups are applied to EPS bearer/PDP Context via PCC rules. The PCC rules themselves may be
associated with the bearer via static configuration or may be installed by a PCRF.
3.9.1.2.1 Quota Expiration

If PGW/GGSN has been granted volume (Granted Service Units) or time (Validity Time) quota it will send a
CC-Request upon expiry of that quota. It will also report the used quota to the OCS. While the PGW/GGSN is
waiting to receive new quota it may discard or allow the received traffic (configurable)
3.9.1.2.2 Quota Threshold triggers

In addition, the OCS may install threshold triggers. The PGW/GGSN supports the following triggers:
• TIME_QUOTA_THRESHOLD: Specified in [s] when the granted quota is time.

• VOLUME_QUOTA_THRESHOLD: Specified in [byte] when the granted quota is volume.
The threshold triggers are assumed to take effect before quota expires. Therefore, the PGW/GGSN will
continue to pass traffic while waiting for the CC-Answer to possibly update the quota.
3.9.1.2.3 Quota Holding Time

Quota-holding-time (QHT) is used to prevent that certain amount of credit is “stranded” with a given CC-
client while the end-user is not using the service anymore. The distinction between active-usage and active-
connection is made by defining an “activity-threshold” which defines an average data rate under which the
subscriber-host is considered silent.
As long as the effective rate of the application-usage will not exceed the rate defined by activity-threshold,
given subscriber will be considered “silent”. QHT will be considered expired every time there was no change
in usage during its period. This approach approximates 3GPP 119uccess119 that requires to cease and to
restart timer at the end of each packet.
119 / 136 © 2017 Nokia

3.9.1.2.4 Change of charging condition triggers
These triggers may be installed by the OCS in a CC-Answer. One or more triggers may be installed
simultaneously. If one of the installed trigger conditions is met PGW/GGSN shall send a reauthorization
request for quota.
• CHANGE_IN_SGSN_IP_ADDRESS (1): This value is used to indicate that a change in the SGSN IP
address shall cause the credit control client to ask for a re-authorization of the associated quota.
• CHANGE_IN_QOS (2): This value is used to indicate that a change in the end user negotiated QoS
shall cause the credit control client to ask for a re-authorization of the associated quota.
• NOTE 1: This should not be used in conjunction with enumerated values 10 to 23.
• CHANGE_IN_LOCATION (3): This value is used to indicate that a change in the end user location shall
cause the credit control client to ask for a re-authorization of the associated quota.
• NOTE 2: This should not be used in conjunction with enumerated values 30 to 34.
• CHANGE_IN_RAT (4): This value is used to indicate that a change in the radio access technology shall
cause the credit control client to ask for a re-authorization of the associated quota.
• CHANGEINLOCATION_MCC (30): This value is used to indicate that a change in the MCC of the
serving network shall cause the credit control client to ask for a re-authorization of the associated
quota.
• CHANGEINLOCATION_MNC (31): This value is used to indicate that a change in the MNC of the
serving network shall cause the credit control client to ask for a re-authorization of the associated
quota.
• CHANGEINLOCATION_LAC (33): This value is used to indicate that a change in the LAC where the end
user is located shall cause the credit control client to ask for a re-authorization of the associated
quota.
• CHANGEINLOCATION_CellId (34): This value is used to indicate that a change in the Cell Identity
where the end user is located shall cause the credit control client to ask for a re-authorization of
the associated quota.
3.9.1.2.5 Tariff time change trigger

The OCS may install a trigger that causes PGW/GGSN to track usage before and after a Tariff Time change.
PGW/GGSN reports usage that straddles the change time by sending two instances of the Used-Service-Unit
AVP, one with Tariff-Change-Usage = ‘unit-before-tariff-change’ and one with ‘unit-after-tariff-change’.
3.9.1.2.6 Termination Action

Graceful service termination is supported to redirect the subscriber to a service portal for online balance
refill or other services offered by the home service provider. After the final granted units have been
consumed, the prepaid user may be connected to a top-up server that plays an announcement and
prompts the user to replenish the account.
3.9.1.2.7 Failure situations

When the primary OCS fails, the PGW/GGSN will automatically begin using the secondary OCS for new
sessions. Failover handling for existing sessions is supported according to the Credit Control Failure
Handling (CCFH) method described in RFC 4006 as specified in Annex B of 32.251. Session failovers are
considered non-revertive, i.e. they are not moved back to their previous OCS when it becomes available.
120 / 136 © 2017 Nokia

OCS can determine per subscriber whether or not an existing session should be subject to failover by
sending the CC-Session-Failover AVP (FAILOVER_SUPPORTED or FAILOVER_NOT_SUPPORTED).
If failover is supported, the OCS may control failover handling via the Credit-Control-Failure-Handling AVP
which can be inserted in any messages sent to GGSN. OCS can request a different failure handling at any
time, during the session (initiation/update/termination) because GGSN always applies the latest CCFH value
received.
The CCFH AVP may be set to one of three values that control the PGW/GGSN 121uccess121 if the OCS fails
to respond:
• TERMINATE: Terminate the session immediately;

• CONTINUE: Allow the session to continue, but resend the CC request to the alternative OCS. In case
the alternative OCS also fails to respond the session is allowed to continue for a configurable
amount of time;
• RETRY_AND_TERMINATE: Resend the CC request to the alternative OCS. In case the alternative OCS
also fails to respond the session will be terminated.
The PGW/GGSN also supports local configuration at gateway level or per APN/per charging profile for CC-
Session-Failover and Credit-Control-Failure-Handling, which applies when OCS does not specify CCSF or
CCFH.
The PGW/GGSN also supports a Failure-Handling-Session-Continue timer to be configured at gateway level

or per APN/per charging profile. This timer controls the amount of time a session is allowed to continue
when CCFH = CONTINUE.
3.9.1.2.8 OCS Selection

The operator can configure the PGW/GGSN to support multiple pairs of primary/secondary OCS. Sessions
are associated with the OCS pair (or single OCS if a secondary is not specified) according to a configurable
range of IMSI or MSISDN values.
This feature is intended for load-balancing purposes (when online charging traffic is expected to exceed the
capacity of a single OCS). If used with IMSI ranges, it can also be used to direct sessions to OCS pairs based
on PLMN IDs.
3.9.1.3 Offline charging
The S/PGW/GGSN supports multiple CDR formats. The PGW-CDRs are used for both session and flow-based
charging when the 7750 is operating as a PGW/GGSN. The PGW-CDRs may also be used to support charging
for PDP contexts and EPS bearers simultaneously. The gateway may generate SGW-CDR to collect charging
information related to the IP-CAN bearer data information for visiting roamers.
The S/ PGW/GGSN includes the volume (separately in uplink and downlink direction), elapsed time and/or
number of events per rating group or a combination of rating group and service id into specific containers in
“List Of Service Data” field.
The mobile gateway activates Service Data Flow container when traffic is detected and no matching active
SDF container already exists. It closes a Service Data Flow container when the termination of the last service
data flow matching to the Service Data Flow container is detected.
121 / 136 © 2017 Nokia

When a change of charging condition occurs, the S/PGW/GGSN adds all containers to the CDR.
The CDR format complies with the following specifications:
• SGW-CDR: format is compliant with 3GPP TS 32.251 v11.8.0, paragraph §6.1.2;

• PGW-CDR: format is compliant with 3GPP TS 32.251 v11.8.0, paragraph §6.1.3.
The mobile gateway transfers the CDRs from the CDF to the CGF over the Ga interface as specified in 3GPP
TS 32.295. The communication between S/PGW and the charging gateways is carried out using GTP’ over
UDP and IP. The following GTP’ functions are supported:
• CDR transfer between the CDF and the CGF;

• Detect communication failures between the communicating peers, using Echo Request/Response
messages;
• Advertise to peers about its CDR transfer capability (e.g., after a period of service downtime) using
Node Alive Request/Response messages.
3.9.1.3.1 Charging Triggers

There are two sets of triggers for offline CDRs:
• Charging info triggers: These triggers cause information to be added to the CDR, but don’t
necessarily cause the CDR to be closed. These triggers are applicable to flow-based charging.
• Partial record closure triggers: These triggers cause the CDR to be closed. If GTP’ is configured the
CDR will be sent to the CGF. Otherwise the CDR is stored in a local file. The GGSN will open a new
CDR unless the PDN connection has been terminated.
The CDR is also closed (and optionally sent) upon the termination of the PDN connection.
List of charging info triggers:
• plmn-change
• qos-change
• rat-change
• sgw-change (or SGSN change)
• tariff-time-change
• termination of service-data-flow
• time-limit-per-rating-group
• user-loc-change
• volume-limit-per-rating-group
List of partial record closure triggers:
• max-change-condition
• ms-time-zone-change
• rat-change
• time-limit
• volume-limit
122 / 136 © 2017 Nokia

3.9.2 CMD
Table 78. CDR handling description
CDR type Input Processing Output

S-CDR GTP’ raw data S-CDR records are collected and accumulated Files in ASN.1 format
from raw file. When file cloresure limits
triggered, workflow will write to a file at optput
directory.
SGW-CDR GTP’ raw data SGW-CDR and PGW-CDR records will are Files in ASN.1 format
PGW-CDR identified, collected and accumulated from raw
file. S-CDR records are collected and
accumulated from raw file. When file cloresure
limits triggered, workflow will write to a file at
optput directory.
Archival Output file Output files are archived to archival directory Archived CDR file
daily at low peak hour.
Cleanup Archived file Old archived files are cleaned up every day at Storage space recovered
low peak hour
3.9.2.1 South interface
Table 79. Elements at south interface
Location
South element type Interface CDR type
HNI DNG HCMC
Flexi NS 17 Ga (GTP’) S-CDR 3 2 7
SGW-CDR
7750-SR12-MG 8.R07 Gz (GTP’) 2 0 4
PGW-CDR
Table 80. Traffic distribution at south interface
South elements Primary CG Secondary CG

@HNI, DNG CG_YHA01N CG_Q0901N
@HCMC CG_Q0901N CG_YHA01N
Remarks
• South elements distribute GTP’ traffic to CG by active-standby mechanism. By default, primary CG

is active CG.
• In case Ga, Gz is down for a period of time
 7750-SR12-MG 8.R07 will write data to its flash. As current FCMD release does not support
collection of these files, MBF billing should prepare an application to process them.
 Flexi NS 17 will write to files on local disk in the same format as output on CMD. MBF Billing
system can fetch and decode those files directly.
123 / 136 © 2017 Nokia

3.9.2.2 North interface
Table 81. North interface description
Output CDR
North element Interface Location
S-CDR PGW-CDR PGW-CDR
MBF Billing application FTP pull HNI ASN.1 ASN.1 ASN.1
Remarks
• For saving transferring time and bandwidth purpose, all output CDR files are compressed
• For monitoring purpose, all output CDR file name contain timestamp and sequence number
information
3.10 KPI requirement
NSN will put best effort to support MobiFone to reach the targeted MBF KPIs as specified in the tables
below, NSN do not responsible for any other parts of Mobifone networks which may directly or indirectly
impact the mentioned KPIs.
3.10.1.1 Flexi NS SGSN/MME
Table 82. FNS KPI
Type KPI Value

CPU ≤ 70%
Attach SR % ≥ 96%
PSSR % ≥ 99%
AUTHEN % ≥ 96%
2G-3G PAGING % ≥ 97%
Inter SGSN RAU SR % ≥ 97%
Intra PAPU RAU SR % ≥ 97%
Inter PAPU Intra SGSN RAU SR % ≥ 97%
EPS Attach SR % ≥ 96%
Service Request Success Rate % ≥ 99%
Paging Success Rate % ≥ 96%
Intra MME Handover Success Rate % ≥ 98%
Inter MME Handover Success Rate % ≥ 93%
Inter-RAT Outgoing Handover Success Rate % (EPS->UMTS) ≥ 90%
4G Paging for SMS SR % ≥ 93%
CSFB Redirection to 2G/3G Success Rate % ≥ 95%
LU (SGs) SR % ≥ 99%
Authentication SR % ≥ 99%
Activate Default EPS Bearer SR % ≥ 96%
TAU SR % ≥ 99%
EPS Round Trip Time measurement (M65)
GnDNS DNS Inquiry success ratio ≥ 99%
124 / 136 © 2017 Nokia

3.10.1.2 7750-SR12-MG S-GW&P-GW
Table 83. 7750MG KPI
KPI Value
CPU ≤ 70%
PSSR % ≥ 99%
Gx SR % ≥ 99%
Gy SR % ≥ 99%
SGW S4/S11 Creat Session SR % ≥ 97%
PGW Create Bearer SR % ≥ 97%
PGW UL Data Drop Ratio % ≤ 1%
PGW DL Data Drop Ratio % ≤ 1%
3.10.1.3 KPI Formula
During project implementation, the KPI formula might need further optimization.
Table 84. FNS KPI Formula

Type KPI Name Formula
LoadSMMU = Max(average(PEAK_LOAD_RATE_OF_OBJECT))
time SMMUs
LoadOMU = Max(average(PEAK_LOAD_RATE_OF_OBJECT))
time OMUs
CPU
LoadPAPU = Max(average(PEAK_LOAD_RATE_OF_OBJECT))
time PAPUs
Load average = Max (Load SMMU, Load OMU, Load PAPU)
Success attach (1)
=sum(iu_succ_gprs_attach, succ_gprs_attach, SUCC_COMBINED_ATTACH, iu_succ_combined_attach,

SUCC_IMSI_ATTACH, IU_SUC_IMSI_ATTACH)
Attempt to Attach (2): AttSR% Include all cause
ATTACH_SR_DROP_CAUSES =Sum(Success attach (1), FAIL_ATTACH)
Attempt to Attach (2): AttSR%
= sum(Success attach (1) + FAIL_ATTACH – Sum(ILLEGEL MS (#3), ILLEGEL ME (#6), SER_NONSER_NA

(#8), SER_NA_PLMN (#14), NO_CELL_IN_LA (#15), SIM_NOT_PROV (#7), PLMN_NA (#11), ROAMING_NA
(#13), LA_NA (#12), PROTOCOL MS ERROR, PROTOCOL COLLISIONS)
Success PDP Acted (1)
=sum(iu_succ_mo_pdp_con_act, succ_mo_pdp_context_act, SUCC_PDP_ACT_ROAMING,

MO_SEC_PDP_ACTIVATION_SUCC, IU_MO_SEC_PDP_ACTIVATION_SUCC)
2G-3G
Attempt to act PDP ctx (2): PSSR% Include all cause
=Success PDP Acted (1) + FAIL ACT PDP

PSSR_DROP_CAUSES
Attempt to act PDP ctx (2): PSSR%
=Success PDP Acted (1) + FAIL ACT PDP – Sum(MISSING/UNKNOWN APN (#27), UNKNOWN PDP
ADDRESS/TYPE (#28), USER AUTHENTICATION FAIL (#29), SER.OPT NOT SUPPORTED (#32), SER.OPT
NOT SUBSCRIBED (#33), MS NOT RESPONSE, MS PROTOCOL ERROR, NSAPI USED (#35)) –
FAIL_PDP_ACT_ROAMING
Authen SR% = Authen success/authen request
Authen request = Sum(UMTS_auth_attempts)+Sum(gsm_auth_attempts)

AUTH_SUCR
Authen success = Sum(UMTS_succ_mm_auth, MTS_succ_sm_auth) + Sum (GSM_succ_mm_auth,
GSM_succ_sm_auth)
PAGING_SUCR Paging success rate % = Paging success / paging request
125 / 136 © 2017 Nokia

Paging success: =Sum(sgsn_level_ps_pagings – sgsn_level_unsucc_ps_pag) +
Sum(sgsn_level_iu_ps_pagings – gsn_level_unsucc_iu_ps_pag)
Paging request = Sum(sgsn_level_iu_ps_pagings, sgsn_level_ps_pagings)
RUSR% Include all cause
=(4.1)=sum(Success Inter SGSN RAU, Inter RAU Fail)
RUSR%
=(4.1)-sum(INTER_SGSN_RAU_F_ILL_MS, INTER_SGSN_RA_LA_UP_F_ILL_MS,
IU_INTER_SGSN_RA_LA_U_F_3, IU_INTER_SGSN_RAU_F_3) – sum(IU_INTER_SGSN_RAU_F_6,
INTER_SGSN_RAU_F_ILL_ME, IU_INTER_SGSN_RA_LA_U_F_6, INTER_SGSN_RA_LA_UP_F_ILL_ME) –
sum(IU_INTER_SGSN_RAU_F_7, IU_INTER_SGSN_RA_LA_U_F_7, INTER_SGSN_RAU_F_GPRS_NA,
INTER_SGSN_RA_LA_UP_F_GPRS_NA) – sum(IU_INTER_SGSN_RA_LA_U_F_8,
INTER_SGSN_RA_LA_UP_F_NGPRS_NA) – sum(INTER_SGSN_RAU_F_MS_IDENT,
INTER_SGSN_RA_LA_UP_F_MS_IDENT, IU_INTER_SGSN_RAU_F_9, IU_INTER_SGSN_RA_LA_U_F_9) –
INTER_RAU_SUCR_DROP_CAUSES sum(IU_INTER_SGSN_RAU_F_10, IU_INTER_SGSN_RA_LA_U_F_10, INTER_SGSN_RAU_F_IMP_DETACH,
INTER_SGSN_RA_LA_UP_F_IM_DETACT) – sum(INTER_SGSN_RAU_F_PLMN_NA,
INTER_SGSN_RA_LA_UP_F_PLMN_NA, IU_INTER_SGSN_RAU_F_11, IU_INTER_SGSN_RA_LA_U_F_11) –
sum(IU_INTER_SGSN_RAU_F_12, IU_INTER_SGSN_RA_LA_U_F_12, INTER_SGSN_RAU_F_LA_NA,
INTER_SGSN_RA_LA_UP_R_LA_NA) – sum(IU_INTER_SGSN_RAU_F_13, IU_INTER_SGSN_RA_LA_U_F_13,
INTER_SGSN_RAU_F_ROAMING_NA, INTER_SGSN_RA_LA_UP_F_R0_NA) –
sum(IU_INTER_SGSN_RAU_F_14, IU_INTER_SGSN_RA_LA_U_F_14, INTER_SGSN_RAU_F_GPRS_NA_PL,
INTER_SGSN_RA_LA_UP_F_NA_PL) – sum(INTER_SGSN_RAU_F_NO_S_CELL,
INTER_SGSN_RA_LA_UP_F_NO_CELL, IU_INTER_SGSN_RAU_F_15, IU_INTER_SGSN_RA_LA_U_F_15) –
sum(IU_FAIL_INTER_SGSN_RAU_MS, IU_FAIL_INTER_SGSN_RA_LA_MS, FAIL_INTER_SGSN_RAU_MS,
FAIL_INTER_SGSN_RA_LA_MS) – sum(FAIL_INTER_SGSN_RAU_COLL, FAIL_INTER_SGSN_RA_LA_COLL,
IU_FAIL_INTER_SGSN_RAU_COLL, IU_FAIL_INTER_SGSN_RA_LA_COLL)
=(6.1)=sum(Success Intra SGSN RAU, FAIL_INTRA,_PAPU_RA_UPDA, FAIL_INTRA_PAPU_RA_LA_UPDAT,

FAIL_INTRA_PAPU_RA_UPDAT_IMSI, FAIL_PERIODICAL_RA_UPDAT, FAIL_PERIODIC_RA_LA_UPDAT,
IU_FAIL_INTRA_PAPU_3G_2G_SHO, IU_FAIL_OG_INTR_PAPU_2G_3G_SHO,
IU_FAIL_IN_INTRA_PAPU_RA_UPD, IU_FAIL_OG_INTRA_PAPU_RA_UPD, IU_FAIL_PERIODIC_RA_UPD,
IU_FAIL_COMB_PERIODIC_UP_PS, IU_FAIL_COMB_INTRA_PAPU_UPD_PS,
IU_FAIL_INTRA_PAPU_2G3G_ISHO, IU_FAIL_OG_INTA_PAPU_3G2G_ISHO)
RUSR%
=(6.1) – sum(IU_INTRA_PAPU_RAU_F_3, IU_PERIODIC_RAU_F_3, IU_PERIODIC_RA_LA_U_F_3,

IU_INTRA_PAPU_RA_LA_U_F_3, IU_FAIL_INTRA_PAPU_2G3G_3, INTRA_PAPU_RAU_F_ILL_MS,
INTRA_PAPU_RA_LA_UP_F_ILL_MS, PERIODIC_RAU_F_ILL_MS, PERIODIC_RA_LA_UP_F_ILL_MS,
IU_FAIL_INTRA_PAPU_3G2G_3) – sum(IU_INTRA_PAPU_RAU_F_6, IU_PERIODIC_RAU_F_6,
IU_PERIODIC_RA_LA_U_F_6, IU_INTRA_PAPU_RA_LA_U_F_6, IU_FAIL_INTRA_PAPU_2G3G_6,
INTRA_PAPU_RAU_F_ILL_ME, INTRA_PAPU_RA_LA_UP_F_ILL_ME, PERIODIC_RAU_F_ILL_ME,
PERIODIC_RA_LA_UP_F_ILL_ME, IU_FAIL_INTRA_PAPU_3G2G_6) – sum(IU_INTRA_PAPU_RAU_F_7,
IU_PERIODIC_RAU_F_7, IU_PERIODIC_RA_LA_U_F_7, IU_INTRA_PAPU_RA_LA_U_F_7,
IU_FAIL_INTRA_PAPU_2G3G_7, IU_FAIL_INTER_PAPU_2G3G_7, INTRA_PAPU_RAU_F_GPRS_NA,
INTRA_PAPU_RA_LA_UP_F_GPRS_NA, PERIODIC_RAU_F_GPRS_NA, PERIODIC_RA_LA_UP_F_GPRS_NA,
IU_FAIL_INTRA_PAPU_3G2G_7) – sum(IU_PERIODIC_RA_LA_U_F_8, IU_INTRA_PAPU_RA_LA_U_F_8,
INTRA_PP_RAU_SUCR_DROP_CAUSES IU_FAIL_INTRA_PAPU_2G3G_8, INTRA_PAPU_RA_LA_UP_F_NGPRS_NA,
PERIODIC_RA_LA_UP_F_NGPRS_NA, PERIODIC_RA_LA_UP_F_NGPRS_NA, IU_FAIL_INTRA_PAPU_3G2G_8)
– sum(INTRA_PAPU_RAU_F_MS_IDENT, INTRA_PAPU_RA_LA_UP_F_MS_IDENT,
PERIODIC_RAU_F_MS_IDENT, PERIODIC_RA_LA_UP_F_MS_IDENT, IU_FAIL_INTRA_PAPU_3G2G_9,
IU_INTRA_PAPU_RAU_F_9, IU_PERIODIC_RAU_F_9, IU_PERIODIC_RA_LA_U_F_9,
IU_INTRA_PAPU_RA_LA_U_F_9, IU_FAIL_INTRA_PAPU_2G3G_9) – sum(IU_INTRA_PAPU_RAU_F_10,
IU_FAIL_INTRA_PAPU_2G3G_10, INTRA_PAPU_RAU_F_IMP_DETACH,
INTRA_PAPU_RA_LA_UP_F_IM_DETAC, PERIODIC_RAU_F_IMP_DETACH,
PERIODIC_RA_LA_UP_F_MS_DETACH, IU_FAIL_INTRA_PAPU_3G2G_10) –
sum(INTRA_PAPU_RAU_F_PLMN_NA, INTRA_PAPU_RA_LA_UP_F_PLMN_NA,
PERIODIC_RAU_F_PLMN_NA, PERIODIC_RA_LA_UP_F_PLMN_NA, IU_FAIL_INTRA_PAPU_3G2G_11,
IU_FAIL_INTRA_PAPU_2G3G_12, INTRA_PAPU_RAU_F_LA_NA, INTRA_PAPU_RA_LA_UP_F_LA_NA,
PERIODIC_RAU_F_LA_NA, PERIODIC_RA_LA_UP_F_LA_NA, IU_FAIL_INTRA_PAPU_3G2G_12) –
sum(INTRA_PAPU_RAU_F_ROAMING_NA, INTRA_PAPU_RA_LA_UP_F_RO_NA,
PERIODIC_RAU_F_ROAMING_NA, PERIODIC_RA_LA_UP_F_RO_NA, IU_FAIL_INTRA_PAPU_3G2G_13,
126 / 136 © 2017 Nokia

IU_FAIL_INTRA_PAPU_2G3G_14, INTRA_PAPU_RAU_F_GPRS_NA_PL, INTRA_PAPU_RA_LA_UP_F_NA_PL,
PERIODIC_RAU_F_GPRS_NA_PL, PERIODIC_RA_LA_UP_F_GPRS_NA_PL, IU_FAIL_INTRA_PAPU_3G2G_14)
– sum(INTRA_PAPU_RAU_F_NO_S_CELL, INTRA_PAPU_RA_LA_UP_F_NO_CELL,
PERIODIC_RAU_F_NO_S_CELL, PERIODIC_RA_LA_UP_F_NO_CELL, IU_FAIL_INTRA_PAPU_3G2G_15,
U_INTRA_PAPU_RA_LA_U_F_15, IU_FAIL_INTRA_PAPU_2G3G_15) – sum(IU_FAIL_INTRA_PAPU_RAU_MS,
IU_FAIL_PERIODIC_RAU_MS, IU_FAIL_PERIODIC_RA_LA_MS, IU_FAIL_INTRA_PAPU_RA_LA_MS,
IU_FAIL_INTRA_PAPU_2G3G_MS, FAIL_INTRA_PAPU_RAU_MS, FAIL_INTRA_PAPU_RA_LA_MS,
FAIL_PERIODIC_RAU_MS, FAIL_PERIODIC_RA_LA_MS, FAIL_INTRA_PAPU_3G2G_MS) –
sum(FAIL_INTRA_PAPU_RAU_COLL, FAIL_INTRA_PAPU_RA_LA_COLL, FAIL_PERIODIC_RAU_COLL,
FAIL_PERIODIC_RA_LA_COLL, FAIL_INTRA_PAPU_3G2G_COLL, IU_FAIL_INTRA_PAPU_RAU_COLL,
IU_FAIL_PERIODIC_RAU_COLL, IU_FAIL_PERIODIC_RA_LA_COLL, IU_FAIL_INTRA_PAPU_RA_LA_COLL,
IU_FAIL_INTRA_PAPU_2G3G_COLL)
=(5.1)=sum(Success Intra SGSN RAU, FAIL_INTRA_PAPU_RA_UPDAT, FAIL_INTRA_PAPU_RA_LA_UPDAT,

FAIL_INTRA_PAPU_RA_UPDAT_IMSI, FAIL_PERIODIC_RA_UPDAT, FAIL_PERIODIC_RA_LA_UPDAT,
IU_FAIL_INTRA_PAPU_3G_2G_SHO, IU_FAIL_OG_INTR_PAPU_2G_3G_SHO,
IU_FAIL_IN_INTRA_PAPU_RA_UPD, IU_FAIL_OG_INTRA_PAPU_RA_UPD, IU_FAIL_PERIODIC_RA_UPD,
IU_RAIL_COMB_PERIODIC_UP_PS, IU_FAIL_COMB_INTRA_PAPU_UPD_PS,
IU_FAIL_INTRA_PAPU_2G3G_ISHO, IU_FAIL_OG_INTA_PAPU_3G2G_ISHO)
RUSR%
=(5.1)=sum(IU_INTER_PAPU_RAU_F_3, IU_INTER_PAPU_RA_LA_U_F_3, IU_FAIL_INTER_PAPU_2G3G_3,

INTER_PAPU_RAU_F_ILL_MS, INTER_PAPU_RA_LA_UP_F_ILL_MS, IU_FAIL_INTER_PAPU_3G2G_3) –
sum(IU_INTER_PAPU_RAU_F_6, IU_INTER_PAPU_RA_LA_U_F_6, IU_FAIL_INTER_PAPU_2G3G_6,
INTER_PAPU_RAU_F_ILL_ME, INTER_PAPU_RA_LA_UP_F_ILL_ME, IU_FAIL_INTER_PAPU_3G2G_6) –
sum(IU_INTER_PAPU_RAU_F_7, IU_INTER_PAPU_RA_LA_U_F_7, IU_FAIL_INTER_PAPU_2G3G_7,
INTER_PAPU_RAU_F_GPRS_NA, INTER_PAPU_RA_LA_UP_F_GPRS_NA, IU_FAIL_INTER_PAPU_3G2G_7) –
sum(IU_INTER_PAPU_RA_LA_U_F_8, IU_FAIL_INTER_PAPU_2G3G_8,
INTER_PAPU_RA_LA_UP_F_NGPRS_NA, IU_FAIL_INTER_PAPU_3G2G_8) –
sum(INTER_PAPU_RAU_F_MS_IDENT, INTER_PAPU_RA_LA_UP_F_MS_IDENT,
INTER_PP_RAU_SUCR_DROP_CAUSES IU_FAIL_INTER_PAPU_3G2G_9, IU_INTER_PAPU_RAU_F_9, IU_INTER_PAPU_RA_LA_U_F_9,
IU_FAIL_INTER_PAPU_2G3G_9) – sum(IU_INTER_PAPU_RAU_F_10, IU_INTER_PAPU_RA_LA_F_10,
IU_FAIL_INTER_PAPU_2G3G_10, INTER_PAPU_RAU_F_IMP_DETACH,
INTER_PAPU_RA_LA_UP_F_IM_DETAC, IU_FAIL_INTER_PAPU_3G2G_10) –
sum(INTER_PAPU_RAU_F_PLMN_NA, INTER_PAPU_RA_LA_UP_F_PLMN_NA,
IU_FAIL_INTER_PAPU_3G2G_11, IU_INTER_PAPU_RAU_F_11, IU_INTER_PAPU_RA_LA_U_F_11,
IU_FAIL_INTER_PAPU_2G3G_11) – sum(IU_INTER_PAPU_RAU_F_12, IU_INTER_PAPU_RA_LA_U_F_12,
IU_FAIL_INTER_PAPU_2G3G_12, INTER_PAPU_RAU_F_LA_NA, INTER_PAPU_RA_LA_UP_F_LA_NA,
IU_FAIL_INTER_PAPU_3G2G_12) -sum(INTER_PAPU_RAU_F_ROAMING_NA,
INTER_PAPU_RA_LA_UP_F_RO_NA, IU_FAIL_INTER_PAPU_3G2G_13, IU_INTER_PAPU_RAU_F_13,
IU_INTER_PAPU_RA_LA_U_F_13, IU_FAIL_INTER_PAPU_2G3G_13) – sum(IU_INTER_PAPU_RAU_F_14,
IU_INTER_PAPU_RA_LA_U_F_14, IU_FAIL_INTER_PAPU_2G3G_14, INTER_PAPU_RAU_F_GPRS_NA_PL,
INTER_PAPU_RA_LA_UP_F_NA_PL, IU_FAIL_INTER_PAPU_3G2G_14) -
sum(INTER_PAPU_RAU_F_NO_S_CELL, INTER_PAPU_RA_LA_UP_F_NO_CELL,
IU_FAIL_INTER_PAPU_3G2G_15, IU_INTER_PAPU_RA_LA_U_F_15, IU_FAIL_INTER_PAPU_2G3G_15) -
sum(IU_FAIL_INTER_PAPU_RAU_MS, IU_FAIL_INTER_PAPU_RA_LA_MS, IU_FAIL_INTER_PAPU_2G3G_MS,
FAIL_INTER_PAPU_RAU_MS, FAIL_INTER_PAPU_RA_LA_MS, FAIL_INTER_PAPU_3G2G_MS) –
sum(FAIL_INTER_PAPU_RAU_COLL, FAIL_INTER_PAPU_RA_LA_COLL, FAIL_INTER_PAPU_3G2G_COLL,
IU_FAIL_INTER_PAPU_RAU_COLL, IU_FAIL_INTER_PAPU_RA_LA_COLL,
IU_FAIL_INTER_PAPU_2G3G_COLL)
100/(EPS_ATTACH_SUCC + EPS_ATTACH_FAIL - EPS_ATTACH_NAS_07_FAIL -

EPS Attach SR % EPS_ATTACH_NAS_08_FAIL - EPS_ATTACH_NAS_11_14_FAIL - EPS_ATTACH_NAS_SM_27_FAIL-
EPS_ATTACH_NAS_SM_USER_FAIL- PDN_UEINIT_ACT_NAS_33_FAIL - PDN_UEINIT_ACT_NAS_28_FAIL)
((MMMT.eps_service_request_succ) / (MMMT.eps_service_request_succ +
Service Request Success Rate %
MMMT.eps_service_request_fail))*100
Paging Success Rate % MMMT.eps_paging_succ / (MMMT.eps_paging_succ + MMMT.eps_paging_fail)*100
100*((mmmt.intratau_wo_sgw_change_succ + mmmt.intramme_tau_sgw_chg_succ) /
Intra MME Handover Success Rate % (mmmt.intratau_wo_sgw_change_succ + mmmt.intramme_tau_sgw_chg_succ +
4G mmmt.intratau_wo_sgw_change_fail))
(mmmt.intermme_s1ho_wo_sgw_chg_succ + mmmt.INTERMME_S1HO_SGW_CHG_IN_SUCC) /
Inter MME Handover Success Rate % (mmmt.intermme_s1ho_wo_sgw_chg_succ + mmmt.INTERMME_S1HO_SGW_CHG_IN_SUCC +
mmmt.intermme_s1ho_in_fail)*100
Inter-RAT Outgoing Handover (mmmt.eps_to_3g_gn_isho_succ / (mmmt.eps_to_3g_gn_isho_succ + mmmt.eps_to_3g_gn_isho_fail
Success Rate % (EPS->UMTS) + mmmt.eps_to_3g_gn_isho_trgt_reje + mmmt.eps_to_3g_gn_isho_enb_cncl))*100
Paging for SMS SR % 100- (SGSAP_PAGING_REJECT_SMS/SGSAP_PAGING_REQUEST_SMS)*100
CSFB SR % (MT - paging 1st
100*(EPS PAGING CSFB SUCC/EPS PAGING 1ST ATTEMPT ATTEMPT)
attempt)
127 / 136 © 2017 Nokia

LU (SGs) SR % (SGSAP_LOCATION_UPDATE_ACCEPT/SGSAP LOCATION UPDATE REQUEST)*100
(SMLM.eps_auth_succ / (SMLM.eps_auth_succ + SMLM.eps_auth_fail_by_ue +
Authentication SR %
SMLM.eps_auth_reject_by_mme))*100
(SMMT.eps_def_bearer_act_succ / (SMMT.eps_def_bearer_act_succ +
Activate Default EPS Bearer SR %
SMMT.eps_def_bearer_act_fail))*100
TAU SR % (MMMT.eps_tau_succ / (MMMT.eps_tau_succ + MMMT.eps_tau_fail))*100
EPS Round Trip Time measurement
RTT_ATTACH_DUR_MIN/RTT_ATTACH_DUR_MAX/RTT_ATTACH_DUR_SUM/RTT_ATTACH_DUR_DEN
(M65)
(sum(ALL_OWN_DN_INQUIRIES)/sum(ALL_OWN_DN_INQUIRIES +
GnDNS DNS Inquiry success ratio
NAME_INQS_FAIL_NO_RECOVERY))*100
Table 85. 775MG KPI Formula
KPI Formula
CPU avg(avgCpuUtilization)
sum(CreatePdpRsp-(CreatePdpRspFail+ NetInitPdpRspFail))
PSSR % ------------------------------------------------------------------------------- *100
sum(CreatePdpReq)
sum(RxCcaI+RxCcaU+RxCcaT)
Gx SR % ---------------------------------------------*100
sum(TxCcrI+TxCcrU+TxCcrT)
sum(RxCcaI+RxCcaU+RxCcaT)
Gy SR % ------------------------------------------*100
sum(TxCcrI+TxCcrU+TxCcrT)
sum(CreateSessnRespSuccess)
SGW S4/S11 Creat Session SR % ----------------------------------------- * 100
sum(CreateSessnReq)
sum(CreateSessnRespSuccess)
PGW Create Bearer SR % ----------------------------------------------- * 100
sum(CreateSessnReq)
PGW UL Data drop ratio % (VS.ulDropPackets/VS.ulPackets)*100
PGW DL Data Drop Ratio % (VS.dlDropPackets/VS.dlPackets)*100
128 / 136 © 2017 Nokia

3.11 Redundancy concept
3.11.1 7750 MG SGW/PGW/GGSN Redundancy
In Mobifone solution all the 7750 MG are running in Active state and all the ISM-MG cards are working Active
mode on each node. The node redundancy will be provided by DNS selection and round-robin mechanism
will be implemented to have the load sharing across the 7750 MG nodes.
Redundancy is ensured by having the following;
• Redundant SF/CMP cards

• Redundant IMM cards with 10GE ports for connectivity
• ISA-MG : All cards are configured as “Active” : Redundancy is ensured by DNS round-robin
mechanism.
• ISA-AA : All cards are configured “primary” in AA group.
3.11.2 Flexi NS LAN redundancy
The Flexi NS LAN redundancy divided into two regions:
• Intra-Flexi NS redundancy
 2N/N+1 redundancy mode for functional units (CPUs).
 Redundancy CPU Ethernet interfaces.
 Hub blade (SWU) redundant L2 trunk between them for inter-hub blade redundancy.
• Inter-Flexi NS LAN redundancy
 Redundancy towards the backbone.
Where redundancy mechanism with the following method:
• Carrie sense
 During the switchover, the IP address move from the failed interface to a new active interface.
After switchover, the MAC address of the active interface is advertised using a gratuitous ARP
message.
• Bidirectional forwarding detection (BFD)
 Network protocol used for providing low-overhead, short-duration detection of failures in the
path between interface, data links and etc.
 BFD does not have a discovery mechanism; session must be explicitly configured between
endpoints. Protocols that support a form of adjacency setup such as OSPF are used to
bootstrap a BFD session. These protocols use BFD to receive faster notification of failing links
using keepalive mechanism.
 For more details information referring to RFC5880.
• Virtual router redundancy protocol (VRRP)
 Protocol that dynamically assigns router responsibility to one of the redundant multilayer site
switches in case the master router fails. It allows a redundant router to automatically assume
the function of an active router in case the active router fails.
 VRRP enable to reduce the possibility of a single point of failure in a network.
 For more details information referring to RFC3768.
129 / 136 © 2017 Nokia

• Steam control transmission protocol (SCTP)
 Transport protocol, serving similar role to the transmission control protocol (TCP) and user
datagram protocol (UDP).
 SCTP provide message-oriented like UDP and ensure reliable, in-sequence transport of
message with congestion control like TCP.
 SCTP multi-homing enabling transparent fail-over between redundant network paths.
3.11.2.1 CPU hosts connectivity with OSPF/BFD and carrier sense IP address
Failover 2 Failover 3
IP
(A) EL0
(A) IPDU-0
SWU-0 3/1
(S) EL1 IP2 (A)
(A)
Failover 1 OSPF/BFD network
VRRP VIP 1
SWU-1 3/1
(A)
(S) EL0 (A)
IP3
(S) IPDU-1
(S) EL1
(IP)
TA SGSN MME
Redundancy mechanism as below:
• Host blade -> Blade standby/working change

• Internal port/link -> Carrier sense redundancy (other blade port takes active role and send
gratuitous ARP for host IP) & VRRP master switch
• External port/link -> OSPF/BFD
Failover 1: The logical IP addressing-based redundancy model can be used to hide internal failover actions
and to keep the serving IP address the same as for the remote peer-end application over a local unit
switchover. The logical IP address in an N+1 redundant unit group is associated with a working (WO)
functional unit inheriting the redundancy scheme of its functional unit. If one of the working (WO) functional
unit fail, the logical IP addressing in an N+1 redundant unit group float from one unit to another based on
the logical address of the unit.
Failover 2: Carrier-sense IP address which is interface redundancy where configured two integrated
Ethernet interfaces and is active on one interface at a time, while the other interfaces are used as backup
interface. If physical link fails, a carrier-sense IP address is moved to the backup interface and a gratuitous
address resolution protocol (ARP) message is sent to advertise the IP and MAC address of new active
interface.
130 / 136 © 2017 Nokia

The redundancy IP addressing switchover is a transparent action for IP user applications. This means that
the redundant IP addressing switchover does not affect the established TCP/IP connections. VRRP uses a
priority scheme to determine which VRRP-configured router is the default active router. Highest priority
configured as active router. VRRP functions by the exchange of multicast message that advertise priority
among VRRP-configured routers. If physical link fails, the standby router will become active router and the
transition of the packet-forwarding functions betweens routers is completely transparent to all hosts in the
network. The VRRP advertisement interval is 1 seconds.
Failover 3: Bi-directional Forwarding Detection (BFD) provides rapid failure detection times between
forwarding engines, while maintaining low overhead. It also provides a single, standardized method of
link/device/protocol failure detection at any protocol layer or over any media. OSPF router specifies the
next hop on the uplink side or another OSPF router as its 131eighbor using BFD. It means that it makes BFD
session with a 131eighbor for monitoring and management purpose. If SWU uplink path fail, the BFD failure
detection operation with OSPF provide fast forwarding path failure detection times for topologies and OSPF
routing table changes to another SWU uplink path.
131 / 136 © 2017 Nokia

4 Document control
Title: Mobifone GPRS Phase 6 High Level Design
Version: 1.1
Document edit by
NOKIA SOLUTION NETWORK

Date:
Signature
Name: Lê Ngọc Thảo
Title: Packet Core Engineer
Document Check by
NOC CENTER MOBIFONE CORPORATION

Date:
Signature
Name:
Title:
Document Approve by
MOBIFONE CORPORATION
Date:
Signature
Name:
Title:
132 / 136 © 2017 Nokia

5 Glossary
Table 86 Abbreviations
Term Explanation
3GPP 3rd Generation Partnership Project
5620 SAM Nokia 5620 Service Aware Manager
7750 MG Nokia 7750 Mobile Gateway
AC Alternate Current
AS Access Server
ASCII American Standard Code for Information Interchange
BOQ/BOM Bill Of Quantities / Bill Of Material
BSS Base Station System
BTS O&M Nokia Solutions and Networks proprietary management interface between iOMS mediator and
Flexi Multiradio BTS LTE network elements.
CAPEX Capital Expenditure
CDR Charging Data Record
CIR Committed Information Rate
CM Configuration Management
COD Cell Outage Detection
CORBA Common Object Request Broker Architecture
CPM Control Plane Module
CPU Central Processing Unit
CS Connectivity Server
DC Direct Current
DCN Data Communication Network
DNS Domain Name System
DS Data Server
DSS Data Storage Subsystem
DTRS Digital Train Radio System
E-LMI Ethernet local management interface
EBDC East Burwood Data Centre
ECMP Equal Cost Multi-Path
EMS Element Management System
eNodeB Evolve NodeB
eTOM Enhanced Telecommunications Operations Map
EPC Evolved Packet Core
FD Full Duplex
Flexi NG The Flexi NG is NOKIA’s next generation Gateway node. They form the basis of the target
network for PS core (they are analogous to GGSNs for GPRS)
Flexi NS The Flexi NS is NOKIA’s next generation Serving node. They form the basis of the target
network for PS core (they are analogous to SGSNs for GPRS)
FM Fault Management
FQDN Fully Qualified Domain Name
GC Global Cluster often referred to in the DTRS environment as Global Reporter Cluster. NOKIA
documentation usually refers to Global Cluster.
GGSN GPRS Gateway Support Node
GNSS Global Navigation Satellite System
GPRS General Packet Radio Service
GR Global Reporter, a set of reporting applications running on a Global Cluster. Within DTRS
environment it can be used interchangeably with Global Cluster.
GUI Graphical User Interface
133 / 136 © 2017 Nokia

Term Explanation
GUIS Graphical User Interface Server
HA High Availability
HLR Home Location Register
HSPA High Speed Packet Access
HSS Home Subscriber Server
HTTP Hypertext Transfer Protocol
HTTPS HTTP Secure
HW Hardware
Hz Hertz
I/O Input/output
ICA Citrix’s Independent Computing Architecture
i-HSPA Internet HSPA
IIOP Internet Inter-ORB Protocol
iOMS Integrated OMS
IPSEC Internet Protocol Security
IEEE Institute of Electrical and Electronics Engineers
IP Internet Protocol
ISA Integrated Service Adapters
ISSUs In-service software upgrades
J2EE Java 2 Enterprise Edition
JRE Java Runtime Environment
JWS Java Web Start
KCI Key Capacity Indicator
KPI Key Performance Indicator
LACP Link Aggregation Control Protocol
LAG Link Aggregation Group
LAN Local area Network
LNS L2TP Network Server
LinAS Linux Application Server
LTE Long Term Evolution
MDA Media Dependent Adapters
MEF Metro Ethernet Forum
MGW Multimedia Gateway
MHDC Mount Helen Data Centre
MS-ISA Multiservice Integrated Services Adapter
MS-ISM Multiservice Integrated Services Module
MVI Multi Vendor Integration
NAS NetAct Application Server
NAT Network Address translation
NB Northbound
NE Network Element
NOC Network Operation Centre
NOKIA Nokia Solutions and Networks
NE3S Nokia enhanced SNMP solution suite
NPM NOKIA Performance Manager. The NOKIA umbrella performance data management solution
NTP Network Time Protocol
NWI3 CORBA-based Nokia Solutions and Networks proprietary management interface between
Network Management System (NMS) like NetAct and mediation devices like iOMS. (CORBA IIOP
and FTP)
O&M Operations & Maintenance
OAM Operations, Administration, and Maintenance
OmeS Open Measurement Standard
OMS Operation & Maintenance Server
134 / 136 © 2017 Nokia

Term Explanation
ORB Object Request Broker
OPEX Operational Expenditure
OSS Operations Support Systems
OSS5 Refers to items that are common to all software levels after OSS5. For example, OSS5
hardware is common to OSS5.1, OSS5.1 CD1, OSS5.2, etc.
P-GW Packet Gateway
PaCo Packet Core
PIR Peak Information Rate
PM Performance Management
PoE Power over Ethernet
PTV Public Transport Victoria
RAM Random Access Memory
RAN Radio Access Network
RC Regional Cluster
RHCS Red Hat Cluster Suite
RMI Remote Method Invocation
RNC Radio Network Controller
SAA Service Assurance Agent
SAM Service Aware Manager
SAI Server @Once Intelligent
SAR Service Aggregation Router
SB Southbound
SDM Subscriber Data Management
SGSN Serving GPRS Support Node
SF Switch Fabric
SMPP Simple Message Peer-to-Peer
SoW Scope of Work
TDM Time Division Multiplexing
VLAN Virtual Local Area Network
VM Virtual Machine
WAN Wide Area Network
135 / 136 © 2017 Nokia

Author Le Ngoc Thao
Owner
Organization Nokia
Approver Vuong Quoc Thinh
Document ID
Document location
Change History
Version Status Date Author Owner Reviewed by Reviewed Approver Approval Description of changes
date date
0.1 Draft 06-03-2017 Le Ngoc Thao SGSNMME pool
0.2 17-03-2017 Le Ngoc Thao Done: FNS, NetAct, CMD, Traffica, FMA
0.3 17-03-2017 Le Ngoc Thao Done: DNS
Partly done: KPI, Net topo
Pending: SAM
0.4 18-03-2017 Le Ngoc Thao Done SAM
Pending partly: KPI, net topo
0.5 22-03-2017 Le Ngoc Thao Add DNS features
Add net topo multi level
0.6 22-03-2017 Le Ngoc Thao Add net topo multi level of Middle area
0.7 23-03-2017 Le Ngoc Thao Add traffic cases
0.8 23-03-2017 Le Ngoc Thao Add more traffic cases, KPI, network topo
BI&FI
0.9 24-03-2017 Le Ngoc Thao Update 7750 physical connectivity
1.0 24-03-2017 Le Ngoc Thao KPI, update node name, physical port
1.1 30-03-2017 Le Ngoc Thao Change structure of document
1.2 04-04-2017 Le Ngoc Thao Update according to T.Hung request
1.3 11-04-2017 Le Ngoc Thao Add index of pictures & tables, KPI list and
formula
1.4 12-04-2017 Le Ngoc Thao Add MME pool overlap, default SGSN, NTP
1.5 20-04-2017 Le Ngoc Thao Modify KPI, add license capacity, update
topology, add routing signalling
End of document
136 / 136 © 2017 Nokia

Mobifone GPRS Phase6 HLD v1.5

Uploaded by

Copyright:

Available Formats

Mobifone GPRS Phase6 HLD v1.5

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Mobifone GPRS Phase6 HLD v1.5

Uploaded by

Copyright:

Available Formats

What is the scope of the document?

What is the scope of the document?

What are the network layers and logical topology described?

What are the network layers and logical topology described?

Upgrading and Expanding NSN PS Core system

1 / 136 © 2017 Nokia

1.1 Scope .............................................................................................................................................. 10

1.2 Mobifone requirement ................................................................................................................. 10

1.3 Mobifone traffic profiles .............................................................................................................. 12

1.4 Nokia solution................................................................................................................................ 13

1.4.1 Delivery ..................................................................................................................................... 13

1.5 Mobifone radio coverage plan .................................................................................................... 15

1.5.1 The Radio Coverage of current network .............................................................................. 15

1.5.2 The Radio Coverage of target network ................................................................................ 16

1.6 Naming convention ...................................................................................................................... 19

2 Network architecture ......................................................................................................................... 20

2.1 Network layers .............................................................................................................................. 20

2.2 Logical topology............................................................................................................................ 26

2.3 Physical topology .......................................................................................................................... 27

3 Network design ................................................................................................................................... 28

3.1 Capacity ......................................................................................................................................... 28

3.1.1 SAE-GW ..................................................................................................................................... 28

3.1.2 Upgrade Flexi NS ..................................................................................................................... 28

3.1.3 New Flexi NS ............................................................................................................................. 29

3.1.4 CMD ........................................................................................................................................... 29

3.1.5 DNS ........................................................................................................................................... 29

3.2 Hardware ........................................................................................................................................ 30

3.2.1 Overview ................................................................................................................................... 30

3.2.2 SAE-GW ..................................................................................................................................... 30

3.2.3 SGSN/MME ............................................................................................................................... 33

3.2.4 SAM ........................................................................................................................................... 40

3.2.5 CMD ........................................................................................................................................... 41

3.2.6 Traffica ..................................................................................................................................... 41

3.2.7 FMA ........................................................................................................................................... 42

2 / 136 © 2017 Nokia

3.4 Connectivity .................................................................................................................................. 43

3.4.1 SAE-GW ..................................................................................................................................... 43

3.4.2 SGSN/MME ............................................................................................................................... 57

3.4.3 NetAct ....................................................................................................................................... 70

3.4.4 SAM ........................................................................................................................................... 71

3.4.5 CMD ........................................................................................................................................... 72

3.4.6 Traffica ..................................................................................................................................... 73

3.4.7 FMA ........................................................................................................................................... 74

3.4.8 DNS ........................................................................................................................................... 75

3.4.9 NTP server ................................................................................................................................ 80

3.5 QoS and DSCP Marking ................................................................................................................ 80

3.5.1 Overview ................................................................................................................................... 80

3.6 Pooling ........................................................................................................................................... 82

3.6.1 Pool location ............................................................................................................................ 82

3.6.2 MME Functionality ................................................................................................................... 84

3.6.3 SGSN functionality .................................................................................................................. 88

3.6.4 SGSN/MME Pooling parameters ............................................................................................ 90

3.6.5 Pooling requirement ............................................................................................................... 91

3.6.6 SGSN MME Pool Configuration .............................................................................................. 91

3.6.7 Traffic flows ............................................................................................................................. 93

3.7 IPv6 support .................................................................................................................................. 103

3.7.1 User Plane IPv6 Implementation........................................................................................... 103

3.7.3 Mobifone UE IP Address Allocation – IPv6 ........................................................................... 106

3.8 Service control .............................................................................................................................. 107