Hitachi vMME Product Overview

vMME Product Overview
Document Number:
Document Revision Number:
10-0100-082
1.02
Document Status:
Issue Date:
Release Identifier
Security Status:
Draft
2015-05-19
8.2
Hitachi-CTA Confidential
Abstract:
This document provides an overview of the release 8.2 version of the Hitachi vMME product.
2015 Hitachi-CTA
All rights reserved.
UNCONTROLLED COPY: The master of this document is stored on an electronic database and is write
protected; it may be altered only by authorized persons. While copies may be printed, it is not
recommended. Viewing of the master electronically ensures access to the current issue. Any hardcopies
taken must be regarded as uncontrolled copies.
HITACHI-CTA CONFIDENTIAL: The information contained in this document is the property of HitachiCTA. Except as expressly authorized in writing by Hitachi-CTA, the holder shall keep all information
contained herein confidential, shall disclose the information only to its employees with a need to know,
and shall protect the information from disclosure and dissemination to third parties. Except as expressly
authorized in writing by Hitachi-CTA, the holder is granted no rights to use the information contained
herein. If you have received this document in error, please notify the sender and destroy it immediately.
Publication History
Issue
Change Summary
Date
1.00
This is the initial draft version of the document.
04/24/2015
1.01
Input 8.2 feature content based on the latest FD documents.
05/04/2015
1.02
Update TS specification versions to Release 11; input feature content based on the
latest FD documents.
05/19/2015

Document Status: 8.2, Draft
Hitachi Proprietary and Confidential

iii
Table of Contents
1 About the Document ............................................................................................................................ 1
1.1 Purpose of the Document .......................................................................................................... 1
1.2 What is New in 8.2 Software Release........................................................................................ 1
1.3 Documentation changes ............................................................................................................ 3
1.4 Structure of this document ......................................................................................................... 3
2 Wireless Packet Network Overview..................................................................................................... 4
2.1 GPRS and UMTS network architecture ..................................................................................... 4
2.2 EPS network architecture .......................................................................................................... 6
3 Software Environment ......................................................................................................................... 9
3.1 Operating System ...................................................................................................................... 9
3.2 Application Management ........................................................................................................... 9
3.3 Time Management ................................................................................................................... 10
3.4 OAM ......................................................................................................................................... 10
4 MME/SGSN Software ........................................................................................................................ 12
4.1 Architectural Highlights ............................................................................................................ 12
4.2 Software Components ............................................................................................................. 12
4.3 Management VM ...................................................................................................................... 13
4.4 Resource Manager VM ............................................................................................................ 14
4.5 Call Processing VM .................................................................................................................. 15
4.6 Signaling VM ............................................................................................................................ 18
4.7 Data VM ................................................................................................................................... 20
4.8 Steering Load Balancer VM ..................................................................................................... 21
5 Interfaces ........................................................................................................................................... 22
5.1 Supported Interfaces ................................................................................................................ 22
5.2 Summary .................................................................................................................................. 22
6 Features and Services ....................................................................................................................... 88
6.1 Combined MME/SGSN Node .................................................................................................. 88
6.2 Mobility Management ............................................................................................................... 90
6.3 Customizable Cause Code Mapping ....................................................................................... 95
6.4 Session Management .............................................................................................................. 99
6.5 UE Security Management ........................................................................................................ 99

iv
6.6 Subscriber Management ........................................................................................................ 101

6.7 User Bearer ............................................................................................................................ 106
6.8 HSPA+ Support ...................................................................................................................... 109
6.9 Direct Tunnel .......................................................................................................................... 109
6.10 Access Sharing .................................................................................................................... 110
6.11 UE Reachability Management ............................................................................................. 114
6.12 UE/MS Purge ....................................................................................................................... 114
6.13 RAN Information Management ............................................................................................ 114
6.14 DNS Support ........................................................................................................................ 115
6.15 SGW, PGW, MME, GGSN and SGSN Selection ................................................................. 117
6.16 Advanced Tracking Area Management................................................................................ 118
6.17 Session-less UE Automatic Detach ..................................................................................... 119
6.18 GGSN Black Listing ............................................................................................................. 119
6.19 Dynamic Load Status Based SGW and PGW Selection ..................................................... 119
6.20 3GPP Trace ......................................................................................................................... 119
6.21 Call Summary Log................................................................................................................ 120
6.22 Subscriber Location Notification .......................................................................................... 120
6.23 P-GW Relocation ................................................................................................................. 121
6.24 Peer node anchor point relocation ....................................................................................... 121
6.25 Accounting Service .............................................................................................................. 122
6.26 Signaling IP Traffic Management ......................................................................................... 125
6.27 1x CSFB Id to eNodeB Mapping .......................................................................................... 126
6.28 Priority Paging for Emergency 1xCSFB Call ....................................................................... 126
6.29 Multiple-SIM Sharing the Same MS-ISDN ........................................................................... 126
6.30 Diameter Based Interface Future Compatibility ................................................................... 126
6.31 Single Radio Voice Call Continuity (SRVCC) ...................................................................... 126
6.32 IMS Emergency Call ............................................................................................................ 127
6.33 VoLTE Support..................................................................................................................... 128
6.34 Femto Cell Support .............................................................................................................. 129
6.35 Multi-SIM Support ................................................................................................................ 130
6.36 Camel Support and Enhancements ..................................................................................... 130
6.37 Sigtran Enhancements ......................................................................................................... 131
6.38 Unknown RAI Reporting ...................................................................................................... 131
6.39 Multimedia Priority Service .................................................................................................. 131


v
6.40 HSS and PCC Based Network Provided Location Information ........................................... 132
6.41 S6d Override Support and Enhancements .......................................................................... 132
6.42 Non Responsive PGW Quarantine ...................................................................................... 132
6.43 Location Service ................................................................................................................... 133
6.44 TAC level service control ..................................................................................................... 134
7 Carrier Grade Capabilities ............................................................................................................... 135
7.1 Redundancy ........................................................................................................................... 135
7.2 Overload Control .................................................................................................................... 135
7.3 SON Support .......................................................................................................................... 136
7.4 In-service Upgrade ................................................................................................................. 137
7.5 In-service Patching................................................................................................................. 137
8 Operation, Admin and Maintenance Capabilities ............................................................................ 138
8.1 Configuration Management .................................................................................................... 138
8.2 Fault Management ................................................................................................................. 139
8.3 Performance Management .................................................................................................... 139
8.4 CLI .......................................................................................................................................... 144
9 Security Capabilities ........................................................................................................................ 145
10 Capacity ......................................................................................................................................... 146
11 Specification Compliance .............................................................................................................. 147
12 Deployment Examples ................................................................................................................... 148
12.1 Stand-alone MME for a green field LTE operator ................................................................ 148
12.2 Combined MME/SGSN for a G/U operator .......................................................................... 150
12.3 Stand-alone MME for a CDMA Operator ............................................................................. 153
12.4 Stand-alone Gn SGSN for a UMTS only operator ............................................................... 154
13 8.2 Software Release Document Map ........................................................................................... 156
14 References and Related Documents ............................................................................................ 157
14.1 Internal References .............................................................................................................. 157
14.2 External References............................................................................................................. 157
15 Glossary......................................................................................................................................... 166


vi
List of Figures
Figure 1.
Gn/Gp Based 3GPP Network Architecture ....................................................................... 4
Figure 2.
S4-Based 3GPP Network Architecture ............................................................................. 5
Figure 3.
Non-roaming architecture for 3GPP access ..................................................................... 7
Figure 4.
Roaming architecture for 3GPP access ............................................................................ 7
Figure 5.
Protocol Stack for S1 Interface for Control Plane ........................................................... 24
Figure 6.
Protocol Stack for S3 and other Mobility Management interfaces .................................. 28
Figure 7.
Protocol stack for S4 interface and other Session Management interfaces ................... 30
Figure 8.
Protocol stack for S4 user plane interface ...................................................................... 32
Figure 9.
Protocol Stack for S6 interface ........................................................................................ 33
Figure 10.
Protocol stack for S11 interface ...................................................................................... 36
Figure 11.
Protocol Stack for S13 interface...................................................................................... 38
Figure 12.
Protocol stack for S101 interface .................................................................................... 41
Figure 13.
Protocol stack for S102 interface .................................................................................... 42
Figure 14.
Protocol Stack for CBC eNB ........................................................................................ 43
Figure 15.
Protocol Stack for SGs interface ..................................................................................... 44
Figure 16.
Protocol stack for Sv interface ........................................................................................ 46
Figure 17.
Protocol Stack for SLg interface...................................................................................... 47
Figure 18.
Protocol Stack for SLs interface ...................................................................................... 48
Figure 19.
Protocol Stack for Fxa interface ...................................................................................... 49
Figure 20.
Protocol stack for Ga interface ........................................................................................ 50
Figure 21.
Protocol stack for Gb interface (IP based transport) ....................................................... 51
Figure 22.
Protocol Stack for Gb User Bearer Plane ....................................................................... 55
Figure 23.
Protocol Stack for Gd interface ....................................................................................... 57
Figure 24.
Protocol Stack for Ge interface ....................................................................................... 61
Figure 25.
Protocol Stack for Gf interface ........................................................................................ 63


vii
Figure 26.
Protocol Stack for GTP-U................................................................................................ 66
Figure 27.
Protocol Stack for Gr interface ........................................................................................ 67
Figure 28.
Protocol Stack for Gs interface ....................................................................................... 69
Figure 29.
Protocol Stack for Iu User Bearer Plane Anchored on the SGSN ............................... 71
Figure 30.
Protocol Stack for Iu User Bearer Plane Direct Tunnel ............................................... 71
Figure 31.
Protocol Stack for Iu User Bearer Plane S4-SGSN case ............................................ 72
Figure 32.
Protocol Stack for Iu Control Plane ................................................................................. 73
Figure 33.
Protocol Stack for Control Plane for UE - MME .............................................................. 78
Figure 34.
Protocol Stack for Control Plane MS SGSN in A/Gb Mode ......................................... 82
Figure 35.
Protocol Stack for Control Plane MS SGSN in Iu Mode .............................................. 82
Figure 36.
Protocol Stack for X interface between the MME and the LIG ....................................... 84
Figure 37.
Protocol Stack for HI2 ..................................................................................................... 86
Figure 38.
Protocol Stack for Domain Name Service interface ........................................................ 86
Figure 39.
Combined MME/SGSN in a wireless network with 2G/3G/4G access technologies ...... 89
Figure 40.
National roaming network Example .............................................................................. 104
Figure 41.
Deployment example 1 Network Level View ............................................................ 149
Figure 42.
Deployment example 1 Nodal level view .................................................................. 150
Figure 43.
Figure 44.
Figure 45.


viii
List of Tables
Table 1.
vMME Application Software Composition ........................................................................... 13
Table 2.
Logical Interfaces ................................................................................................................ 22
Table 3.
S1-AP Messages................................................................................................................. 24
Table 4.
S3 Interface Messages ....................................................................................................... 28
Table 5.
S4 interface GTP-C Messages ........................................................................................... 30
Table 6.
S4 User Bearer Plane Messages ........................................................................................ 32
Table 7.
S6 Messages ....................................................................................................................... 33
Table 8.
S10 Messages..................................................................................................................... 34
Table 9.
S11 interface Messages ...................................................................................................... 36
Table 10.
S13 Messages................................................................................................................. 39
Table 11.
S16 Messages................................................................................................................. 39
Table 12.
S101 Interfaces Messages .............................................................................................. 41
Table 13.
S102 Interface Messages ............................................................................................... 42
Table 14.
SBc Interface Messages ................................................................................................. 43
Table 15.
SGs Interface Messages ................................................................................................. 44
Table 16.
Sv Interface Messages .................................................................................................... 46
Table 17.
SLg Interface Messages ................................................................................................. 47
Table 18.
SLs Interface Messages .................................................................................................. 48
Table 19.
Fxa Interface Messages .................................................................................................. 49
Table 20.
Ga Interface Messages ................................................................................................... 50
Table 21.
Gb NS messages ............................................................................................................ 52
Table 22.
Gb IP Sub-Network Service Control messages .............................................................. 52
Table 23.
Gb BSSGP messages ..................................................................................................... 53
Table 24.
SNDCP Messages .......................................................................................................... 55
Table 25.
LLC Messages ................................................................................................................ 56


ix
Table 26.
Gd Messages .................................................................................................................. 57
Table 27.
M3UA Layer Messages ................................................................................................... 58
Table 28.
SCCP Layer Messages ................................................................................................... 59
Table 29.
TCAP Layer Messages ................................................................................................... 59
Table 30.
Ge Interface messages ................................................................................................... 61
Table 31.
Gf Messages ................................................................................................................... 63
Table 32.
Gn/Gp Interface Mobility Management Messages .......................................................... 64
Table 33.
Gn/Gp Interface Session Management Messages ......................................................... 64
Table 34.
Gn/Gp Interface User Bearer Plane Messages .............................................................. 66
Table 35.
Gr Messages ................................................................................................................... 67
Table 36.
Gs Messages .................................................................................................................. 69
Table 37.
Iu Messages .................................................................................................................... 73
Table 38.
SCCP Layer Messages ................................................................................................... 76
Table 39.
M3UA Layer Messages ................................................................................................... 77
Table 40.
NAS Evolved Mobility Management Messages .............................................................. 79
Table 41.
Evolved Session Management messages ...................................................................... 80
Table 42.
NAS GPRS Mobility Management Messages ................................................................. 83
Table 43.
Session Management messages .................................................................................... 83
Table 44.
X Interface Messages ..................................................................................................... 85
Table 45.
Mobility Scenarios Supported ......................................................................................... 91
Table 46.
DNS Procedure and service parameter usage ............................................................. 115
Table 47.
3GPP Technical Specifications ..................................................................................... 122
Table 48.
Group Sets and Groups ................................................................................................ 139
Table 49.
System Capacity and Performance............................................................................... 146
Table 50.
Per Subscriber Capacity ............................................................................................... 146
Table 51.
Documentation Map ...................................................................................................... 156
Table 52.
External References and Related Documents (3GPP) ................................................. 157


x
Table 53.
External References and Related Documents (3GPP2) ............................................... 164
Table 54.
External References and Related Documents (IETF)................................................... 164


xi
1 About the Document

1.1 Purpose of the Document
This document presents the technical information regarding the virtualized combined MME/SGSN
node. The technical detail includes functions and capabilities implemented up to the 8.2 Release.
With virtualization complete, the combined MME/SGSN node is no longer confined to the computing
power of a physical chassis or a frame.
This product can be deployed as a combined MME/SGSN node. In addition, it can also be deployed
as a standalone MME, or a standalone SGSN, depending on the needs of the wireless network
operator. For operators that are currently using earlier releases on Advanced Telecom Computing
Architecture (ATCA) platform, the vMME can be introduced to the MME/SGSN pool and gradually
phase out the ATCA based nodes.
The term vMME in this document refers to the product as a whole, which includes both the MME
function and the SGSN function. When the term MME is used alone, it means the MME function of
the vMME whether it is a standalone MME or part of a combined MME/SGSN. When the term
SGSN is used, it means the SGSN function of the vMME whether it is a standalone SGSN or part of
a combined MME/SGSN. The term S4-SGSN refers to one configuration of the SGSN function that
utilizes the S4 interface for session management. The term Gn-SGSN refers to one configuration of
the SGSN function that utilizes the Gn interface for session management. The SGSN can
simultaneously support Gn-SGSN and S4-SGSN capability.
1.2 What is New in 8.2 Software Release

The following features/functionalities are added in this release:
AGW-21835 Proprietary RAN and NAS cause code to SGW This feature enables the MME to
support the inclusion of RAN/NAS causes in S11 messages: Delete Session Request and Delete
Bearer Command
AGW-23552 EMBMS - This feature implements the Multimedia Broadcast and Multicast Service
(MBMS) specified in TS 23.246 on the MME. MBMS is a point-to-multipoint service which data is
transmitted from a single source entity to multiple recipients. Multiple subscribers can receive the
same data at the same time on the same frequency.
AGW-24378 CLI Initiated Explicit Detach This feature allows the operator to choose the detach
type (implicit or explicit) when clearing the subscriber. Previous functionality performed an implicit
detach.
AGW-24908 MME Collision With this feature, the MME is enhanced to provide the following
collision handling:


1
About the Document
An enhanced Mobility Management (eMM) procedure (except network initiated Detach)

suspended due to handover (HO) is implicitly completed if the X2 or S1 HO indicates a
Tracking Area Identity (TAI) change.
Radio Link Failure (RLF): When eNodeB (eNB) sends UE Context Release Request with
cause Radio Connection with UE lost during HO, the MME aborts any suspended eMM
and/or enhanced Session Management (eSM) procedures, aborts the HO and releases
all S1 connections. During HO, if the MME receives a UE initiated procedure on a new S1
connection due to RLF, the MME aborts any suspended eMM and/or eSM procedures,
aborts the HO, releases all old S1 connections and processes the UE initiated procedure.
If another X2 or S1 HO request is received while the MME is waiting for the handoverresource-release-timer to expire or in the middle of cleaning up sessions from the source
Serving Gateway (S-GW) due to S-GW relocation, the new HO request is buffered until
the MME completes cleaning up the sessions on the source S-GW.
UE is implicitly detached by MME when an expected Tracking Area Update (TAU)

Request after HO is not received.
For Mobile Terminated (MT) Circuit Switched Fallback (CSFB) in ECM-Active mode, the
Non-Access Stratum (NAS) CS Service Notification message is queued when MME
receives NAS Non Delivery Indication from the eNB indicating the NAS message is not
delivered due to HO in progress. After HO completes, the MME resends the NAS CS
Service Notification message to the UE.
Home Subscriber Server (HSS) initiated T-ADS Retrieval via Insert-Subscriber-DataRequest (IDR) is immediately processed by the MME even if the MME is in the middle of
paging, handover or an eMM procedure. The last known TAI for the UE is used to provide
information such as VoLTE support in the Insert-Subscriber-Data-Answer (IDA) message
to the HSS.
AGW-25446 MME 3GPP Interfaces to Release 11 - The MME interfaces are upgraded to be
compliant to the September 2014 version of the Release 11 specifications. Further, for each
interface, an attribute is added to allow the operator to control the version of the interface used by
the node. The operator can use the latest version when the related network nodes are ready to
utilize the new version of the related protocols.
AGW-25498 CLI Ping through Routing Instance This feature provides a CLI command to ping
adjacent 3GPP nodes (an eNodeB) using a configured 3GPP source IP (s1 interface address)
through an LB VM.
AGW-25809 MME LCS Emergency Service Enhancement - This feature enhances the MME
Location Service (LCS) functionality for the emergency. The enhancements are categorized into
configuration, counters, messages and new supported functionality for LCS.
AGW-25811 Inter PLMN Roaming Restriction - This feature enables the network operator to
restrict idle mode inter-node inter-PLMN TAU procedure. The operators are given the ability to
reject or allow the idle mode inter-node inter-PLMN TAU procedure based on the source PLMN
derived from the old GUTI in the TAU request.


2
About the Document
AGW-25814 GW Blacklisting Enhancements - This feature allows the operator to manually

blacklist SGWs and PGWs and improves the GW selection process by dynamically detecting
failed SGW and PGW.
1.3 Documentation changes

None in this release.
1.4 Structure of this document

The Hitachi vMME is the ultimate mobility management product for the wireless packet network. Its
capabilities span the Evolved Packet System (EPS); aka, 4G networks, as well as the widely
deployed GPRS (2G) and UMTS (3G) packet networks. The rest of the document presents the
capabilities and functions of the vMME.
Wireless Packet Network Overview provides an overview of the wireless packet network from the
standards point of view. Readers familiar with reference network architecture as defined by the 3GPP
standards body should already be familiar with the content of this chapter.
Software Environment provides an overview of the software Environment.
MME/SGSN Software discusses the MME/SGSN software.
Interfaces covers the supported logical interfaces, including both 3GPP defined interfaces and a few
proprietary interfaces.
Features and Services details the features and services provided by the vMME. This chapter also
showcases a rich set of value-add features available on the node. Many of the features are unique in
the industry. Carrier grade capabilities are one of the key differentiators of the vMME and are detailed
within this chapter. To enable ease of use, the vMME also boasts a rich set of OAM capabilities. A
highlight of the key functions is described. To ensure both nodal and end user security, the vMME
supports both network domain and user domain security. The chapter ends with a description of the
capacity and performance of the vMME.
Deployment Examples showcases a few possible network level use cases and related configurations.
This helps the network operators better understand how the vMME can be integrated smoothly into
their networks.
8.2 Software Release Document Map provides a document map for the other documents available to
our customers for this release.


3
2 Wireless Packet Network Overview

2.1 GPRS and UMTS network architecture
Prior to the publication of release 8 specifications by 3GPP standards body, the General Packet
Radio Service is a second generation (2G) wireless standard based on a GSM access network and
MAP (Mobile Application Part) core. The Universal Mobile Telecommunications System is a third
generation (3G) wireless standard based on a Code Division Multiple Access (CDMA) access
network and a MAP core.
Since release 8, the traditional network architecture is now referred to Gn/Gp based network whereas
the new network architecture is referred to as S4-based architecture. The following figure shows the
Gn/Gp based architecture as defined by 3GPP specification TS 23.060.
Figure 1. Gn/Gp Based 3GPP Network Architecture
SMS-GMSC
SMS-IWMSC
E
SMS-SC
gsmSCF
C
Gd
MSC/VLR
Gs
Iu
Uu
R
TE
MT
Gc
Gr
Iu
UTRAN
HLR
Ge
Gi
SGSN
Gn
Gb
TE
MT
R
BSS
Um
SGSN
Gn
PDN
GGSN
Ga
Ga
Gp
CGF
GGSN
TE
Gf
Billing
System
EIR
Other PLMN
Signalling Interface (including SMS)
Signalling and Data Transfer Interface
As part of the release 8 specification, the core network has evolved to be a mixture of MAP and
Diameter core. Further, the wireless architecture is gradually evolving towards a unified packet core
that is embodied in the EPC network architecture discussed in the next section. The R8 based 2G/3G
packet network is referred as the S4-based network.


4
Wireless Packet Network Overview
Figure 2. S4-Based 3GPP Network Architecture

SMS-GMSC
SMS-IWMSC
E
SMS-SC
C
gsmSCF
Gd
MSC/VLR
A
Gs
Iu
R
TE
Uu
MT
HSS
Ge
S6d/Gr (see Note)
Iu
SGi
SGSN
UTRAN
Gb
P-GW
PDN
TE
S4
S5
TE
MT
R
BSS
Um
SGSN
S16
S12
S13
S-GW
S8
EIR
P-GW
Other PLMN
Signalling Interface (including SMS)

Signalling and Data Transfer Interface
In this section we will provide basic introduction to the interfaces that are relevant to the SGSN. The
readers are referred to the 3GPP specifications (mainly TS23.060) for a full discussion of each node
in the network architecture and its interfaces. See section External References.
Regardless of the architecture flavor, the interfaces from the core to the access nodes remain the
same. For the 2G network, the interface between the SGSN and the Access node is the Gb interface.
For the 3G network, the interface between the SGSN and the Access node is the Iu interface. The
interfaces used to bridge the packet network and circuit network are also the same. Additionally,
some SS7 based interfaces remain:
Gs: Interface between the SGSN and MSC/VLR for combined attached subscribers.
Gd: Interface between the SGSN and the SMS Gateway MSC for SMS delivery for the Short
Message Center.
Ge: Interface between the SGSN and the SCF to control UEs usage of the packet network. It is
typically used for prepaid data services.
The interfaces between the packet core nodes have changed from the Gn/Gp based architecture to
S4 based architecture.


5
Gn: Interface between the SGSN and GGSN for user session management as well as between
two SGSNs for user mobility management. Another flavor for Gn is Gp, which is the same
interface but between networks belonging to two operators.
S4: Interface between the SGSN and the SGW for session management. S4 supersedes the
session management aspect of the Gn interface when a network moves from Gn/Gp based
architecture to S4 based architecture.
S16: Interface between two SGSNs for user mobility management, replacing the mobility
management aspect of the Gn interface.
Gr: Interface between the SGSN and the HLR for authentication information and subscription
information management.
S6d: Interface in the S4-based architecture between SGSN and the HSS for authentication
information and subscription information management. This interface supersedes the Gr
interface.
Ga: Interface between the SGSN and the CGF for SGSN Accounting.
Gf: Interface between the SGSN and the EIR for equipment validation.
S13: Interface between the SGSN and the EIR for equipment validation. S13 interface replaces
Gf interface in the S4 based 3GPP Network Architecture.
2.2 EPS network architecture

The EPS network evolves from the GPRS and UMTS network. There are a few major changes
compared to the GPRS and UMTS network:
All IP based infra-structure: Not only is the interface between the access nodes and the core
nodes IP based, the interfaces between the core nodes are also all IP based. The Diameter
based protocol replaces MAP based interfaces.
No more circuit domain: Unlike the 2G and 3G network, the 4G EPS network no longer has a
circuit domain that used to provide parallel mobility management for the UEs. Voice services are
achieved using either: IMS (VoLTE) or CS Fallback (SGs).
The following figures show the network architecture as defined by TS 23.401.


6
Figure 3. Non-roaming architecture for 3GPP access

UTRAN
SGSN
HSS
GERAN
S3
S6a
S1-MME
MME
PCRF
S12
S11
LTE-Uu
Serving
Gateway
E-UTRAN
UE
Rx
Gx
S4
S10
S5
PDN
Gateway
SGi
S1-U
Operator's IP
Services
(e.g. IMS, PSS etc.)
Figure 4. Roaming architecture for 3GPP access
HSS
PCRF
Gx
Rx
S6a
PDN
Gateway
SGi
Operators IP
Services
(e.g. IMS, PSS etc.)
HPLMN
VPLMN
S8
UTRAN
SGSN
GERAN
S12
S3
S1-MME
S4
MME
S11
S10
LTE - Uu
UE
Serving
Gateway
E-UTRAN
S1-U
The following interfaces are related to the MME:

S1-MME: Interface used to connect the E-UTRAN access nodes to the MME for signaling. The data
plane interface is the S1-U between the access nodes to the Serving Gateway.
S3: Interface between the MME and the S4-SGSN for mobility management purpose.
S6a: Interface between the MME and the HSS for subscription and authentication information
management.


7
S10: Interface between two MME nodes for inter-MME mobility management.
S11: Interface between the MME and the S-GW for PDN and bearer management. The S-GW
extends the signaling from the MME to the PGW via the S5 or S8 interface.
The readers are referred to TS23.401 for more details on the other interfaces mentioned in the figures
above. Please note, EPC network architecture figures in this section do not cover all the interfaces.
For example, the SGs interface between the MME and the VLR/MSC. This interface allows UE in the
4G network to fall back to 2G GSM or 3G UMTS network for voice call. Another interface not depicted
here is the S13 interface between the MME and the EIR for equipment validation.
In addition to the interfaces discussed above, the vMME also supports other interfaces used to bridge
the existing CDMA 1xRTT network with the 4G E-UTRAN network:
S101: Interface between the HRPD access nodes with the MME to facilitate mobility between the
E-UTRAN network and the HRPD network.
S102: Interface between the MME and the InterWorking System (IWS) to facilitate falling back to
the 1xRTT circuit domain for voice call.


8
3 Software Environment
The vMME adopts layered software architecture. From a high level, the system can be divided into
three layers1.
The operating system layer
Platform services (also referred to as middleware) layer
The application layer
This section delves into the function and capability of the Operating System layer and Platform
Services layer. The application layer is detailed in the next section.
3.1 Operating System

The vMME virtual machines run the Linux operating system. The Linux OS is based on the Ubuntu
12.04.2 LTS server distribution, with customization to remove un-needed software. The Linux kernel
from Ubuntu has been optimized to run in the virtual environment, and configured to exclude options
and functions that are not needed. Carrier grade extensions developed by Hitachi are incorporated to
enable the high availability application environment and tools necessary to meet Hitachis stringent
reliability requirements.
The same operating system runs on every virtual machine of the system.
3.2 Application Management

The vMME software is partitioned into several types of virtual machines. One of the virtual machine is
the management VM (or MGMT VM), which is responsible for the Operations, Administration and
Maintenance of a logical vMME node. The six types of virtual machines of the vMME are:
MGMT (OAM)
RM (resource management)
CALLP (call processing, control plane)
DATA (data plane for SGSN)
For a virtualized environment, there are other layers of software to support and orchestrate the virtualized
machines. We will not discuss details of that layer of software in this document.


9
Software Environment
SIG (signaling)
SLB (steering load balancer)
The Application Management software is part of the platform middleware that runs mainly on the
MGMT VM, with local agent on every VM. The Application Management software manages the
lifecycle of application software installed on the system. It is responsible to control the start, stop,
switch of activity of application software entities. Further, it performs monitoring of the application
software to ensure they are running properly.
There can be multiple instances of a VM type. For a given VM type, the redundancy scheme is fixed.
Two types of redundancy schemes are used by the vMME. One is 1:1 active/standby synchronized
redundancy, the other is N-way load shared redundancy. For 1:1 spared VMs such as CALLP and
MGMT, there are up to two units in a VM service pair. For N-way load shared VMs such as DATA, all
the VMs are active while the collection is engineered at capacity and performance of N-1 instances. If
one VM fails, the remaining N-1 VMs are able to take over the capacity without exceeding
engineering limit on each VM.
Each VM contains an aggregation of software functions where each software function represents a
running software resource, for example, a set of processes.
A comprehensive set of CLI commands are supported to allow the operator to configure and manage
the VMs required for a particular vMME.
3.3 Time Management

The vMME uses Network Time Protocol (NTP) to manage time both across the network and within
the system. It is imperative to configure at least one NTP server to ensure that all the nodes in the
network to have synchronized timestamps for all events generated, including charging, fault reporting
etc.
3.4 OAM
For Operations, Administration and Maintenance, the vMME (mme-sgsn) provides the following
functions and northbound interfaces to an NMS (Network Management System):
CM (Configuration Management):
All semantic rules run on the MGMT VM prior to commit
Supports connections via IETF NETCONF
CLI (Command Line Interface): SSH and local serial console
Multiple concurrent CLI and NETCONF sessions are supported


10
Software Environment
Hierarchical organization of commands and config
Tab based auto-completion and short form on-line help
PM (Performance Management):
One file per node per collection interval
Collection intervals: 5, 15, 30 minutes
CLI access cumulative registers
SFTP pull via external IP address of MGMT VM
Format: 3GPP XML - per 3GPP Technical Specifications: 32.401, 32.404, 32.406,
32.426, 32.432, 32.425
FM (Fault Management):
Customer logs and alarms available by IETF RFC-5424 compliant syslog
Supports SNMPV2 (MIB and OpenNMS eventconf.xml files provided for MME/SGSN)
SNMP and syslog streams presented to NMS via OAM interface of MGMT VM
CSL (Call Summary Log):
One binary file per node per collection interval
SFTP pull of output file via external IP of MGMT VM
Off-board SCTP streaming mode available, recommended for large systems
Captures configurable call release events per UE including
Category: failure, reject, release (abnormal and normal releases), success
Units: mobility, bearer, PDN, radio bearer
TRACE:
Up to ten UE may be configured persistently per: IMSI, IMEI, or MSISDN
One XML file per UE session
SFTP pull of output file via external IP of MGMT VM
Implemented per 3GPP technical specifications: 32.421/422/423


11
4 MME/SGSN Software
The vMME software traces its origin back in late 1990s when the GPRS SGSN was first developed.
By the year 2000, the UMTS SGSN completed development and was being deployed in customer
networks worldwide shortly thereafter. With the support for LTE being defined by the 3GPP
organization, our vision for LTE has been to leverage the field-tested and successful SGSN software
base combined with support for MME utilizing common procedures wherever possible. With MME 6.0,
the product can be deployed to customer networks in a combined MME/SGSN configuration, allowing
Operators to reduce operational and capital expenditures by providing high-capacity LTE solutions
while at the same time allowing the same node to manage the 2G and 3G access networks. The
previous release introduced the virtualization technology to the combined MME/SGSN, where the
MME/SGSN is no longer confined to the physical limitations of a chassis.
4.1 Architectural Highlights

The vMME follows the following architectural principle in developing a highly reliable carrier grade
core node:
No single point of failure: From the hardware to platform software to the application software,
redundancy is innate to the design. The system continues to maintain normal service even if there is
a single fault on the system. Furthermore, mobile users that have already attached to the node are
not impacted and continue to receive service.
IP Address efficiency: Despite the high capacity of the vMME, the IP address consumption is at
minimum. Packet steering technology is used within the system to ensure the same IP address can
be serviced by multiple VMs across multiple compute nodes.
Separation of Data and Control: To ensure independent scaling of the signaling load and user bearer
load, the vMME separates control plane software and data plane software on two different sets of
VMs. This ensures CPU resource between the control plane and data plane is properly fenced.
Independent scaling of subscriber capacity and access node connection capacity: The subscriber
capacity and the access node connection capacity are two competing requirements on an MME or an
SGSN. To allow the maximum flexibility, the vMME allows scaling of the two requirements
independently.
4.2 Software Components

The vMME software is grouped based on its function into six different types of virtual machines. Each
virtual machine represents an instance of Linux Operating System running on a compute node that
has a host operating system and a hypervisor. There can be more than one virtual machine on a
single compute node.


12
MME/SGSN Software
4.2.1 Summary
The details of each type of virtual machine are examined in the ensuing sections. In this section we
provide a tabular view of all the different types that can be configured.
Table 1.
vMME Application Software Composition
VM Type
Function
Max number
of Active per
System
Max total
number per
System
Used by
MME
Used by
S4SGSN
Used by
GnSGSN
Management
Operations,
Administration and
Maintenance
Yes
Yes
Yes
Resource
Manager
Application layer
resource management
Yes
Yes
Yes
Call
Processing
Subscriber Control
function
11
22
Yes
Yes
Yes
Signaling
Termination of logical
interfaces
20
Yes
Yes
Yes
Data
Handling of user data

plane
15
15
Yes
Yes
Steering
Load
Balancer
Handling control plane

IP packet steering
Yes
Yes
Yes
For a node that is deployed to support multiple functions, all the required virtual machine types should
be configured. For example, a combined MME/SGSN node that supports both S4-SGSN and GnSGSN capability should have all the VM types present in the system.
4.3 Management VM
The Management VM is the center of Operations, Administration and Maintenance for the vMME. It
runs in 1:1 active/standby mode. It hosts software functions that perform configuration management
of the vMME, collect performance data from the application layer, monitor faults and process status
queries from the operator or the north-bound element manager.
Only one active instance of Management VM and one standby is required.
One instance is deployed for Diameter Client use only if the operator wants to use single Diameter instance.


13
MME/SGSN Software
On top of the above mentioned standard OA&M functions, the Management VM also hosts a couple
of data collection applications. One is the collector for the Call Summary Logs that are generated as
the result of call processing; the other is the collector for the 3GPP Trace data when the activities of
traced subscribers are captured.
4.4 Resource Manager VM

The Resource Manager VM is responsible for managing the application layer resources. It also hosts
single active instance applications on the vMME. The following software functions can be instantiated
on the Resource Manager VM.
4.4.1 Resource Manager

The Resource Manager (RM) manages the global resources of the vMME, which is built on a
distributed virtualized environment. It enables multi-dimensional scaling of subscriber count, access
fan-out and user data throughput. The application software, such as the Subscriber Control in the
CallP VM, needs the resources to manage a slice of the subscribers on the vMME. The Resource
Manager ensures that system resources are utilized to their maximum extent without collision
between the applications on various virtual machines. The Resource Manager is also responsible for
the load-balancing within the cluster of VMs that form one vMME node.
4.4.2 SBc
The MME supports the SBc interface to start, stop and receive Public Warning System (PWS) and
Commercial Mobile Alert System (CMAS) messages from the CBC, and broadcast the message to all
the eNodeBs in the tracking area designated by the CBC. The SBc interface uses the SBc
Application protocol and SCTP as the message transport. The SBc function is responsible for the
following functions:
Maintain up to four SCTP connections to the CBC
Encode/Decode SBc-AP layer messages
Deliver the warning message to the eNodeB with highest priority
Notify the CBC about the message delivery. The response to CBC will not wait for eNodeBs
response to MME
Support redundancy in case of blade failure
Ability to start and stop the broadcasting of PWS and CMAS messages


14
MME/SGSN Software
The instantiation of SBc function depends on if the operator requires the use of the SBc interface for
emergency broadcasting purpose. If the interface is configured, the vMME instantiates the SBc
function on the Resource Manager VM.
4.4.3 LI
The LI function is used to provide Legal Interception (LI) capability to the vMME. It maintains
connection to the Legal Intercept Gateway which directs the MME/SGSN on the monitoring
information.
The LI function supports the reporting of activity of the UE, known as Intercept-Related Information, or
IRI to the Legal Intercept Gateway (LIG). In the case when user bearer is also established on the
node (SGSN with 2G subscribers, or non-direct tunnel 3G subscribers), the LI function can also report
the communication content of the UE to the LIG if requested.
The LI function is only instantiated if Legal Intercept interface is required and configured on the
vMME.
4.4.4 Ga
The Ga function is used for the SGSN to transfer charging records to the Charging Gateway Function
via the Ga interface. It can also store the charging records locally on the file system for retrieval. The
SGSN can be configured to generate M-CDRs for mobility related records, S-CDR for session related
records and SMS-CDRs for short message service related records. The generated CDR records are
transferred to the CGFs. If the CGFs are down, the records are spooled in the local disk. The spooled
records are replicated on the standby Resource Manager VM.
The Ga function is only instantiated on the Resource Manager VM when the Ga interface is
configured on the vMME.
4.5 Call Processing VM

The Call Processing VM is the signaling processing center of the vMME. It runs in 1:1 active/standby
mode. The key function of the Call Processing VM is subscriber management.
Each vMME can have multiple pairs of Call Processing VMs running in 1:1 spared mode. The
capacity of the vMME grows with the number of Call Processing VMs configured.
The following functions are hosted on the Call Processing VM.


15
MME/SGSN Software
4.5.1 Subscriber Control

The Subscriber Control (SC) is responsible for processing signaling for the UE, regardless whether it
is originated by the UE or initiated by a network node. The Subscriber Control is the processing
engine for all UE related messages.
The following functions are provided by the Subscriber Control:
Mobility Management
Session Management
Layer 2 Mobility management for optimized active mode handover
The SC process is responsible for handling user signaling. The SC also handles commands received
from the OAM interface, and the CLI interface.
At least one Call Processing VM pair should be deployed on the vMME. For higher subscriber
capacity, more Call Processing VMs can be deployed (up to ten pairs3). Each VM pair is deployed in
1:1 redundancy scheme on two different compute nodes.
4.5.2 Diameter Client

The MME and S4-SGSN utilize the Diameter Clients configured on the MME/SGSN for the S6 (S6a
and S6d) interface, the S13 interface, as well as the SLg interface. The MME or the SGSN requests
the subscription related information via the S6 interface from the HSS. The above mentioned
interfaces use Diameter and SCTP as the message transport. The Diameter Client is responsible for
the following functions:
Maintain the SCTP connections to a set of Diameter peers
Encode/Decode S6,S13 and SLg Application layer messages
Route the messages to the correct SC process
When Diameter protocol is required for the vMME, the Diameter Client is instantiated on at least one
of the CallP VM pairs. For higher Diameter Client processing capability, multiple instances can be
deployed. At maximum, there can be a Diameter Client per CallP VM pair on the vMME.
One additional pair of CallP VMs can be deployed if only Diameter Client is enabled on the pair.


16
MME/SGSN Software
4.5.3 lu
The Iu function provides interface to the 3G access network, or the UTRAN. The Iu function is
responsible for the following:
terminate the RANAP and SCCP layer between the RNC and the SGSN
route the RANAP messages to the correct SC process
manage the SCCP layer connections for UE signaling
Please note, unlike the S1 function which provides connectivity to 4G access network, the Iu function
does not maintain direct SCTP association to the access network. The SCTP associations are fulfilled
by the IPSP function hosted on the Signaling VM discussed in the next section.
The Iu function is instantiated on the CallP VM if the SGSN supports 3G access technology.
4.5.4 SGs
The SGs function is used to terminate the SGs interface between the MME and the VLR. The key
functions of the SGs are:
Maintain SCTP association with the VLRs
Encode/Decode SGs-AP layer messages
Route the message to the current Subscriber Control
The SGs function can be instantiated on the CallP VM when the SGs interface is configured.
4.5.5 SLs
The SLs function is used to terminate the SLs interface between the MME and the eSMLC. The key
functions of the SLs are:
Maintain SCTP association with the eSMLCs
Encode/Decode LCS-AP layer messages
Route the message to the current Subscriber Control
The SLs function can be instantiated on the CallP VM when the SLs interface is configured.


17
MME/SGSN Software
4.6 Signaling VM
The Signaling VM is responsible for terminating the logical interfaces with an external node. All the
interfaces hosted on the Signaling VM use N-way load-sharing redundancy. As such, multiple active
instances of a signaling VM can be deployed on the vMME. The higher the number of Signaling VMs,
the higher the fan-out and signaling processing capability of the vMME.
The following functions are hosted on the Signaling VM.
4.6.1 S1
The S1 function provides interface to the 4G access network, or the E-UTRAN. The S1 is responsible
for the following:
receive and maintain SCTP connections from the eNodeBs that are in the service area of the
MME
terminate the S1-AP layer
route the S1-AP messages to the correct SC process
The instantiation of the S1 function on the Signaling VM depends on whether the vMME is used to
support 4G Access technology or not.
4.6.2 UDP Path Manager (UPM)

The UPM function is used to process all GTP-C based interfaces, as well as other UDP based
interfaces, including the following:
S11
S10
Fxa (Radius based)
S3
S4
S16
Sv
Gn/Gp
S101
S102

18
MME/SGSN Software
Details of afore-mentioned interfaces are discussed in Supported Interfaces.

The function of UPM includes:
For GTP based protocols:
GTP-Path Management
Decoding/Encoding GTP headers
Routing the GTP messages to the correct SC process
For RADIUS based protocols (Fxa):
RADIUS Fxa Path Management
Routing the messages to the correct SC process
1x CS based protocol
S102 Path Management
Relay S1AP CDMA2000 messages between the MME and IWS
Routing the messages to the correct SC process
4.6.3 TCAP
The Transaction Capabilities Application Part (TCAP) application provides a communication channel
towards an SS7-based network for a number of applications that are based on MAP.
The TCAP function supports the Gf, Gr, Ge and Gd interfaces.
The instantiation of the TCAP function depends on if SS7 signaling is used for the SGSN.
4.6.4 SIGTRAN
The SIGTRAN function (also referred to as SIGTRAN ASP or ASP) implements the M3UA layer, and
provides signaling transport over an IP network for the Gr, Gs, Gf, Ge and Gd interfaces to the HLR,
MSC/VLR, EIR, SCF and SMSC. This application provides support for both ANSI and ITU based
signaling.
Similar to TCAP, the instantiation of the SIGTRAN depends if SS7 signaling is required or not on the
vMME.


19
MME/SGSN Software
4.6.5 IPSP
The IPSP function is used to provide M3UA connectivity to the 3G access network, or the UTRAN to
support the Iu function that runs on the CallP VM. It provides the M3UA layer function for the Iu
function discussed above. The IPSP function maintains SCTP associations with the peer M3UA
based peer node. The IPSP further routes the incoming messages based on the destination point
code to the correct Iu function residing on the right CallP VM.
The instantiation of IPSP depends on whether 3G access technology is supported on the vMME or
not.
4.7 Data VM
The Data VM is used only with the SGSN function to support 2G or 3G user data packets. Multiple
active instances are configured to support the needed throughput required for the SGSN. When 2G
access technology is required, it is recommended to be configured in pairs to provide redundant
connectivity to every 2G BSS node. Otherwise, any number of active instances of Data VM can be
configured.
The following functions are hosted on the Data VM.
4.7.1 Gb
The Gb function provides the Gb interface to the 2G access network, or the GERAN. It terminates
both the BSSGP layer and NS layer towards the BSS. The SGSN IP based NS layer. It can be used
to connect to BSS nodes that support IP based Gb interface directly via an IP backbone network. The
instantiation of the Gb function depends on whether connectivity to a 2G access network is required.
To provide redundancy, two Data VMs should be used to connect to the same BSS node. The two
data VMs support the same set of BSS nodes and run in active/active load-sharing redundancy
mode. The two VMs are synchronized with regard to the connectivity information to the BSSs.
Connectivity to the BSS is maintained as long as one of the two VMs is in service.
4.7.2 Subscriber Data

The Subscriber Data (SD) function provides user bearer service on the SGSN. For 3G subscribers, it
acts as a split tunnel that relays user packets from the GGSN to the RNC and vice versa. For 2G
subscribers, it provides additional services. The services include:
Link layer: The SD function supports both acknowledged and unacknowledged LLC layer
between the UE and the SGSN. Additionally, it performs ciphering/de-ciphering based on agreed
ciphering algorithm on the link layer frames.


20
MME/SGSN Software
SNDCP layer: This layer bridges the LLC layer and the IP layer for the UE. The SD function can
provide both header compression and V.42bis data compression at this layer to reduce the data
size over the air.
The SD function is required for the SGSN. It is instantiated on every Data VM unless the data VM is
used for SGSN specific signaling functions below.
4.8 Steering Load Balancer VM

The SLB VM, or LB VM, forwards ingress packets to the 3GPP address of the target VMs. On the
SLB VM, the LBCtrl process programs steering policies into a forwarding infrastructure running within
the SLB VM kernel. This configuration is used to steer incoming traffic to specific target VMs.
Two or more (up to eight) SLB VMs can be instantiated on separate hosts. All policies are
programmed on each SLB VM allowing the ability to load balance ingress 3GPP traffic across all SLB
VMs. Egress traffic is handled on the target VM by routing the packets back to the SLB VM using
multi-path routing (in order to load balance the egress 3GPP traffic). 2G and 3G user data does not
transverse the SLB VM and is routed directly to the target Data VMs with a static route configured in
the next-hop router/L3-capable switch.


21
5 Interfaces
5.1 Supported Interfaces
The vMME supports a plethora of interfaces that make it the most flexible mobility management core
node on the market. It can be deployed as a legacy 2G-only SGSN, 3G only SGSN, a combined
2G/3G SGSN, an S4-based SGSN, a standalone MME (suitable for both current CDMA operators as
well as GPRS/UMTS operators) or a combined 2G/3G/4G MME/SGSN.
In this section, we will discuss the characteristics of each interface supported. The sub-section below
captures the summary of all interfaces while the ensuing sub-sections provide an in-depth look for
each interface.
5.2 Summary
As a combined MME/SGSN, the vMME supports an extensive array of 3GPP defined interfaces as
well as a few value-added proprietary interfaces. The following table provides a condensed view of all
the logical interfaces available on the MME/SGSN. The ensuing sections provide a more detailed
view of each interface.
Table 2.
Logical Interfaces
Interface
Peer Node
Relay Node
Name
Name
Cardinality
Name
S1
eNodeB
25000
N/A
Local IP Usage
Cardinality
Min
Max
Type
IPv4 and IPv6
IPv4 and IPv6
S3
SGSN or
MME
1000
N/A
S4
SGW
1000
N/A
IPv4 and IPv6
S6
HSS
1000 if via
Relay
Diameter
Agent
20
IPv4 or IPv6
248
248 if direct
connect
S10
MME
1000
N/A
IPv4 and IPv6
S11
SGW
1000
N/A
IPv4 and IPv6
The IP addresses of a GTP-C based interface can be shared with other GTP-C interfaces. Thus the minimum
IP consumption for all the interfaces sharing the IP addresses can be 1 in total, instead of 1 for every interface.


22
Interfaces
Interface
Peer Node
Name
Relay Node
Local IP Usage
Name
Cardinality
Name
Cardinality
Min
S13
EIR
Diameter
Agent
248
Shared with S6.
IPv4 or IPv6
S16
SGSN
1000
N/A
IPv4 and IPv6
S101
eAN
15000
N/A
IPv4 and IPv6
S102
IWS
200
N/A
IPv4 and IPv6
SBc
CBC
N/A
IPv4 or IPv6
SGs
VLR
256
N/A
IPv4 or IPv6
Sv
VLR
256
N/A
IPv4 and IPv6
SLg
GMLC
50
DRA
SLs
eSMLC
20
Fxa
AAA
Ga
248
Max
Type
Shared with S6.
IPv6 and IPv6
N/A
IPv6 or IPv6
128
N/A
IPv4 or IPv6
CGF
N/A
IPv4
Gb
BSS
(PCU)
600
N/A
15 (GbIP)
IPv4
Gn/Gp
(tunnel)
GGSN
1000
N/A
IPv4 and IPv6
Gn/Gp
SGSN
1000
N/A
IPv4 and IPv6
Gn/Gp
(user
bearer)
GGSN
No limit
N/A
15
IPv4
Gd
SMSGMSC or
SMSIWMSC
No limit
M3UA
peer
500
10
IPv4
Ge
SCP
128
Gf
EIR
Gr
HLR
1000
Gs
VLR
256
Iu
(signaling)
RNC
4096
M3UA
peer
8192
40
IPv4
Iu (user
RNC
No limit
N/A
15
IPv4
(mobility)
Shared with the SGs interface for a combined MME/SGSN.


23
Interfaces
Interface
Peer Node
Name
Relay Node
Name
Cardinality
Name
NAS
UE
4,160,000
X1
LIG ADMF
X2/X3
DNS
Local IP Usage
Cardinality
Min
Max
Type
Access Node (See Gb,

Iu and S1)
N/A
N/A
IPv4 or IPv6
LIG DF
N/A
DNS
Server
N/A
IPv4 or IPv6
bearer)
5.2.1 S1 Interface
The S1 Interface allows the eNodeBs to communicate with the Evolved Packet Core network. The
interface is split between S1-MME (also referred to as S1-C) for Control plane and S1-U for User
plane. The MME only terminates the S1-MME, whereas the Serving Gateway terminates the S1-U.
The following figure shows the protocol stack for S1-MME.
Figure 5. Protocol Stack for S1 Interface for Control Plane
S1-AP
S1-AP
SCTP
SCTP
IP
IP
L2
L2
L1
L1
S1-MME
eNodeB
MME
For the S1 interface, the peer node for the MME is the eNodeB.
The MME allows the operator to configure the version of the S1-AP specification to be used over the
S1 interface. The supported versions of TS36.413 are: V9.5.1, 10.6.0 or 11.8.0. The following table
shows the messages supported for each of the configured versions.
Table 3.
S1-AP Messages


24
Interfaces
Message Type
Message
Direction
V9.5.1/V10.6.0/V11.8.0
E-RAB Setup Request
eNB <- MME
Supported
E-RAB Setup Response
eNB -> MME
Supported
E-RAB Modify Request
eNB <- MME
Supported
E-RAB Modify Response
eNB -> MME
Supported
E-RAB Release Command
eNB <- MME
Supported
E-RAB Release Response
eNB -> MME
Supported
E-RAB Release Indication
eNB -> MME
Supported
Initial Context Setup Request
eNB <- MME
Supported
Initial Context Setup Response
eNB -> MME
Supported
10
Initial Context Setup Failure
eNB -> MME
Supported
11
UE Context Release Request
eNB -> MME
Supported
12
UE Context Release Command
eNB <- MME
Supported
13
UE Context Release Complete
eNB -> MME
Supported
14
UE Context Modification Request
eNB <- MME
Supported
15
UE Context Modification Response
eNB -> MME
Supported
16
UE Context Modification Failure
eNB -> MME
Supported
17
Handover Required
eNB -> MME
Supported
18
Handover Command
eNB <- MME
Supported
19
Handover Preparation Failure
eNB <- MME
Supported
20
Handover Request
eNB <- MME
Supported
21
Handover Request Acknowledge
eNB -> MME
Supported
22
Handover Failure
eNB -> MME
Supported
23
Handover Notify
eNB <- MME
Supported
24
Path Switch Request
eNB -> MME
Supported
25
Path Switch Request Acknowledge
eNB <- MME
Supported
26
Path Switch Request Failure
eNB <- MME
Supported
27
Handover Cancel
eNB -> MME
Supported
28
Handover Cancel Acknowledge
eNB <- MME
Supported
29
eNodeB Status Transfer
eNB -> MME
Supported
30
MME Status Transfer
eNB <- MME
Supported
31
Paging
eNB <- MME
Supported
32
Initial UE Message
eNB -> MME
Supported
33
Downlink NAS Transport
eNB <- MME
Supported
34
Uplink NAS Transport
eNB -> MME
Supported
35
NAS Non Delivery Indication
eNB -> MME
Supported


25
Interfaces
Message Type
Message
Direction
V9.5.1/V10.6.0/V11.8.0
36
Reset
eNB <-> MME
Supported
37
Reset Acknowledge
eNB <-> MME
Supported
38
Error Indication
eNB <-> MME
Supported
39
S1 Setup Request
eNB -> MME
Supported
40
S1 Setup Response
eNB <- MME
Supported
41
S1 Setup Failure
eNB <- MME
Supported
42
Downlink S1 CDMA2000 Tunneling
eNB <- MME
Supported
43
Uplink S1 CDMA2000 Tunneling
eNB -> MME
Supported
44
eNodeB Configuration Update
eNB -> MME
Supported
45
eNodeB Configuration Update

Acknowledge
eNB <- MME
Supported
46
eNodeB Configuration Update Failure
eNB <- MME
Supported
47
MME Configuration Update
eNB <- MME
Supported
48
MME Configuration Update Acknowledge
eNB -> MME
Supported
49
MME Configuration Update Failure
eNB -> MME
Supported
50
Overload Start
eNB <- MME
Supported
51
Overload Stop
eNB -> MME
Supported
52
UE Capability Info Indication
eNB -> MME
Supported
53
Trace Start
eNB <- MME
Supported
54
Trace Failure Indication
eNB -> MME
Supported
55
Deactivate Trace
eNB <- MME
Supported
56
Location Reporting Control
eNB <- MME
Supported
57
Location Report Failure Indication
eNB -> MME
Supported
58
Location Report
eNB -> MME
Supported
59
Write Replace Warning Request
eNB <- MME
Supported
60
Write Replace Warning Response
eNB -> MME
Supported
61
eNodeB Direct Information Transfer
eNB -> MME
Supported
62
MME Direct Information Transfer
eNB <- MME
Supported
63
eNodeB Configuration Transfer
eNB -> MME
Supported
64
MME Configuration Transfer
eNB <- MME
Supported
65
Cell Traffic Trace
eNB -> MME
Not supported
66
Kill Request
eNB <- MME
Supported
67
Kill Response
eNB -> MME
Supported
68
Downlink UE Associated LPPA Transport
eNB <- MME
Supported
69
Uplink UE Associated LPPA Transport
eNB -> MME
Supported


26
Interfaces
Message Type
Message
Direction
V9.5.1/V10.6.0/V11.8.0
70
Downlink Non UE Associated LPPA

Transport
eNB <- MME
Supported
71
Uplink Non UE Associated LPPA

Transport
eNB -> MME
Supported
At the SCTP layer, the MME supports multi-home function as well as SCTP association recovery
capability required by TS36.412. For the multi-home support, up to two IP addresses are supported at
the local end-point or the remote end-point. The two IP addresses for the same multi-home
association must be of the same IP address type (either IPv4 or IPv6). Mixture of IPv4 address and
IPv6 address for the same SCTP association is not supported. The MME also supports configurable
number of streams for both directions.
At the IP layer, the MME supports both IPv4 and IPv6 addresses at the same time, thus allowing
connectivity to both IPv4 eNodeBs and IPv6 eNodeBs simultaneously. At the minimum consumption,
only a single local IPv4 address is required. At maximum, two local IPv4 addresses and two local
IPv6 addresses are used to support SCTP multi-home to IPv4 eNodeBs and IPv6 eNodeBs.
The maximum number of eNodeBs that the MME can connect to is 25,000 in this release.
5.2.2 S3 Interface
The S3 interface facilitates the UE mobility between an S4-SGSN and an MME. This interface along
with mobility interfaces between the S4 SGSNs (S16), Gn-SGSN (Gn/Gp), and between the MMEs
(S10) is based on the prevalent GTP protocol. For the S-based EPC interfaces, GTPv2 is used. For
the legacy Gn/Gp interface, GTPv1 is used.


27
Interfaces
Figure 6. Protocol Stack for S3 and other Mobility Management interfaces
GTP-C
GTP-C
UDP
UDP
IP
IP
L2
L2
L1
L1
S3/S10
MME or SGSN
SGSN or MME
S16/Gn/Gp
The peer node for the S3 interface is either the MME if this node is acting as the source or old SGSN,
or the SGSN if this node is acting as the source or the old MME.
The vMME allows the operator to configure the specification version of the GTPv2 to be used over
the S3 interface. The same version is also used for the S10/S16 interfaces. The supported versions
of TS 29.274 on the MME/SGSN are: V9.5.0, V10.10.0 and V11.13.0. The following table shows the
messages supported for each of the configured versions.
Table 4.
S3 Interface Messages
Message Type
Message Direction
V9.5.0/V10.10.0/V11.13.0
Echo Request
Source SGSN -> Target MME,
Supported
Source MME -> Target SGSN

2
Echo Response
Source SGSN <- Target MME, Source MME

<- Target SGSN
Supported
Version Not Supported

Indication
Gn/Gp only SGSN -> MME
Supported
Identification Request
Source SGSN <- Target MME
Supported
Source MME <- Target SGSN

5
Identification Response
Source SGSN -> Target MME
Supported

6
Context Request
Supported

7
Context Response
Supported


28
Interfaces
Message Type
Message Direction
V9.5.0/V10.10.0/V11.13.0
Context Acknowledge
Supported

9
Forward Relocation
Request
Forward Relocation
Response
Relocation Cancel
Request
Relocation Cancel
Response
Forward Relocation
Complete Notification
Forward Relocation
Complete Acknowledge
15
RAN Information Relay
SGSN <-> MME
Supported
16
Suspend Notification
SGSN -> MME
Supported
17
Suspend Acknowledge
SGSN <- MME
Supported
18
Detach Notification
SGSN <-> MME
Not supported
19
Detach Acknowledge
SGSN <-> MME
Not supported
20
CS Paging Indication
SGSN <-> MME
Not supported
21
Alert MME Notification
SGSN <-> MME
Not supported
22
Alert MME Acknowledge
SGSN <-> MME
Not supported
23
UE Activity Notification
SGSN <-> MME
Not supported
24
UE Activity Acknowledge
SGSN <-> MME
Not supported
10
11
12
13
14
Supported

Supported

Supported

Supported

Supported

Supported
At the GTP layer, the vMME supports up to 1000 peers for mobility management purpose. Each peer
is represented by a unique IP address of the peer. Path management function is used to monitor the
health and/or reach-ability of the peer node. DNS procedures as defined in TS29.303 are used for the
discovery of the peer IP addresses.
connectivity to both IPv4 SGSN or MME and IPv6 SGSN or MME at the same time. Up to two local IP
addresses (one IPv4, one IPv6) are needed for the S3 interface. If only IPv4 is used by all the peer
nodes, then the IPv6 address is not required. The local IP addresses can be shared with GTP-C
based interfaces.


29
Interfaces
5.2.3 S4 Interface
The S4 interface is used for session management between the S4-SGSN and the SGW. This
interface along with the other session management interfaces between the Gn SGSN and the GGSN
(Gn/Gp) or between the MME and the SGW (S11) is based on the GTP protocol. For the S-based
EPC interfaces, GTPv2 is used. For the legacy Gn/Gp interface, GTPv1 is used.
Figure 7. Protocol stack for S4 interface and other Session Management interfaces
GTP-C
GTP-C
UDP
UDP
IP
IP
L2
L2
L1
L1
S4
SGSN
S-GW or GGSN
Gn/Gp
The peer node for the S4 interface is the SGW. The versions supported in this release are TS29.274
V9.5.0 and TS29.274 V10.10.0. The following table shows the messages supported for each of the
configured versions.
Table 5.
S4 interface GTP-C Messages
Message Type
Message Direction
V9.5.0/V10.10.0
Echo Request
S-GW <- SGSN,

S-GW -> SGSN
Supported
Echo Response
S-GW <- SGSN,

S-GW -> SGSN
Supported
Create Session Request
S-GW <- SGSN
Supported
Create Session Response
S-GW -> SGSN
Supported
Create Bearer Request
S-GW -> SGSN
Supported
Create Bearer Response
S-GW <- SGSN
Supported
Bearer Resource Command
S-GW <- SGSN
Supported
Bearer Resource Failure Indication
S-GW -> SGSN
Supported
Modify Bearer Request
S-GW <- SGSN
Supported


30
Interfaces
Message Type
Message Direction
V9.5.0/V10.10.0
10
Modify Bearer Response
S-GW -> SGSN
Supported
11
Delete Session Request
S-GW <- SGSN
Supported
12
Delete Session Response
S-GW -> SGSN
Supported
13
Delete Bearer Request
S-GW -> SGSN
Supported
14
Delete Bearer Response
S-GW <- SGSN
Supported
15
Downlink Data Notification
S-GW -> SGSN
Supported
16
Downlink Data Notification Acknowledge
S-GW <- SGSN
Supported
17
Downlink Data Notification Failure Indication
S-GW <- SGSN
Supported
18
Modify Bearer Command
S-GW <- SGSN
Supported
19
Modify Bearer Failure Indication
S-GW -> SGSN
Supported
20
Update Bearer Request
S-GW -> SGSN
Supported
21
Update Bearer Response
S-GW <- SGSN
Supported
22
Delete Bearer Command
S-GW <- SGSN
Supported
23
Delete Bearer Failure Indication
S-GW -> SGSN
Supported
24
Create Indirect Data Forwarding Tunnel

Request
S-GW <- SGSN
Supported
25
Create Indirect Data Forwarding Tunnel

Response
S-GW -> SGSN
Supported
26
S-GW <- SGSN
Supported
27
Suspend Acknowledge
S-GW -> SGSN
Supported
28
Resume Notification
S-GW <- SGSN
Supported
29
Resume Acknowledge
S-GW -> SGSN
Supported
30
Create Forward Tunneling Request
SGSN -> S-GW
Supported
31
Create Forward Tunneling Response
SGSN <- S-GW
Supported
32
Delete Indirect Data Forwarding Tunnel Request
S-GW <- SGSN
Supported
33
Delete Indirect Data Forwarding Tunnel

Response
S-GW -> SGSN
Supported
34
Release Access Bearers Request
S-GW <- SGSN
Supported
35
Release Access Bearers Response
S-GW -> SGSN
Supported
36
Stop Paging Indication
S-GW -> SGSN
Not supported
37
Trace Session Activation
SGSN -> S-GW
Supported
38
Trace Session Deactivation
SGSN -> S-GW
Supported
39
Change Notification Request
S-GW -> SGSN
Not supported
40
Change Notification Response
SGSN -> S-GW
Not supported
41
Delete PDN Connection Set Request
SGSN <-> S-GW
Not supported
42
Delete PDN Connection Set Response
SGSN <-> S-GW
Not supported


31
Interfaces
At the GTP layer, the vMME supports up to 1000 peers for session (or tunnel) management purpose.
Each peer is represented by a unique IP address of the peer. Path management function is used to
monitor the health and/or reach-ability of the peer node. For the S4 interface, DNS procedures as
defined in TS29.303 are used for the discovery of the peer IP addresses.
At the IP layer, the SGSN supports both IPv4 and IPv6 addresses at the same time, thus allowing
connectivity to both IPv4 SGW and IPv6 SGW at the same time. Up to two local IP addresses (one
IPv4, one IPv6) are needed for the S4 interface. If only IPv4 is used by all the peer nodes, then the
IPv6 address is not required. The local IP addresses can be shared with all other GTP-C based
interfaces.
Figure 8. Protocol stack for S4 user plane interface
GTP-U
GTP-U
UDP
UDP
IP
IP
L2
L2
L1
L1
S4 user plane
SGSN
SGW
The SGSN uses only one local IPv4 address for the purpose. The number of IP addresses that can
be used by the GGSNs is not limited. The following table shows the messages supported.
Table 6.
S4 User Bearer Plane Messages
Message Type
Message Direction
V9.3.0
Echo Request
SGSN <--> GGSN
Receive only
Echo Response
SGSN <--> GGSN
Supported
Error Indication
SGSN <--> GGSN
Supported
Supported Extension Header Notification
SGSN <--> GGSN
Supported
G-PDU
SGSN <--> GGSN
Supported


32
Interfaces
5.2.4 S6 Interface
The S6 interface permits the MME or SGSN to retrieve the Authentication information and
Subscription data from the Home Subscriber Server (HSS). The interface between the MME and the
HSS is referred to as S6a, and the interface between the SGSN and the HSS as S6d. In this
document, S6 is used to refer to both.
The following figure shows the protocol stack used by the S6 interface.
Figure 9. Protocol Stack for S6 interface
S6
S6
Diameter
Diameter
SCTP
SCTP
L2
L2
L1
L1
S6
MME/SGSN
HSS
The peer node for the S6 interface is the HSS. The vMME can connect directly to the HSS nodes, or
indirectly via a set of Diameter Agents. The vMME has a limitation of 248 direct connected peer
nodes. If all the HSSs are directly connected, then the total number is limited to 248. However, if
Diameter Agents are used, the number of HSSs that can be supported is 1000.
The vMME allows the operator to configure the specification version of the S6 to be used. The
supported versions of TS.29.272 are: V9.5.0 ,V10.7.0 and 11.11.0. The following table shows the
Table 7.
S6 Messages
Message Type
Message Direction
V9.5.0/10.7.0/11.11.0
Update Location Request Command
HSS <- MME/SGSN
Supported
Update Location Answer Command
HSS -> MME/SGSN
Supported
Authentication Information Request Command
HSS <- MME/SGSN
Supported
Authentication Information Answer Command
HSS -> MME/SGSN
Supported
Cancel Location Request Command
HSS -> MME/SGSN
Supported
Cancel Location Answer Command
HSS <- MME/SGSN
Supported
Insert Subscriber Data Request Command
HSS -> MME/SGSN
Supported


33
Interfaces
Message Type
Message Direction
V9.5.0/10.7.0/11.11.0
Insert Subscriber Data Answer Command
HSS <- MME/SGSN
Supported
Delete Subscriber Data Request Command
HSS -> MME/SGSN
Supported
10
Delete Subscriber Data Answer Command
HSS -> MME/SGSN
Supported
11
Purge UE Request Command
HSS <- MME/SGSN
Supported
12
Purge UE Answer Command
HSS -> MME/SGSN
Supported
13
Reset Request Command
HSS -> MME/SGSN
Supported
14
Reset Answer Command
HSS <- MME/SGSN
Supported
15
Notify Request Command
HSS <- MME/SGSN
Supported
16
Notify Answer Command
HSS -> MME/SGSN
Supported
At the SCTP layer, the MME supports multi-home function for the S6 interface. For the multi-home
support, up to two IP addresses are supported at the local end-point or the remote end-point. The two
IP addresses for the same multi-home association must be of the same IP address type (either IPv4
or IPv6). Mixture of IPv4 address and IPv6 address for the same SCTP association is not supported.
At the IP layer, the MME supports either IPv4 or IPv6. At the minimum consumption, only a single
local IP address is required. At maximum, up to ten pairs of IP addresses can be used.
5.2.5 S10 Interface

The S10 interface facilitates the intra-LTE UE mobility between two MME nodes. This interface along
with other mobility interfaces (S3, S16 and Gn/Gp) is based on the prevalent GTP protocol. For the Sbased EPC interfaces, GTPv2 is used. For the legacy Gn/Gp interface, GTPv1 is used.
The protocol stack for the S10 interface is captured in Figure 6 Protocol Stack for S3 and other
Mobility Management interfaces.
The peer node for the S10 interface is the other MME involved in the mobility management
procedure.
the S10 interface. The same version is also used for the S3/S16 interfaces. The supported versions
of TS 29.274 are: V9.5.0 and V10.10.0. The following table shows the messages supported for each
of the configured versions.
Table 8.
S10 Messages
Message Type
Message Direction
V9.5.0/V10.10.0
Echo Request
Old MME <-> New MME
Supported
Echo Response
Old MME <-> New MME
Supported


34
Interfaces
Old MME <- New MME
Supported
Old MME -> New MME
Supported
Context Request
Old MME <- New MME
Supported
Context Response
Old MME -> New MME
Supported
Context Acknowledge
Old MME <- New MME
Supported
Forward Relocation Request
Target MME <- Source MME
Supported
Forward Relocation Response
Target MME -> Source MME
Supported
10
Relocation Cancel Request
Supported
11
Relocation Cancel Response
Supported
12
Forward Relocation Complete

Notification
Supported
13

Acknowledge
Supported
14
Forward Access Context

Notification
Supported
15

Acknowledge
Supported
16
Configuration Transfer Tunnel
Source MME -> Target MME
Supported
17
MME <-> MME
Supported
The S10 interface is similar to the S3 interface. Please refer to S3 Interface related to the GTP layer
and IP layer information.
5.2.6 S11 Interface

The MME is connected via the S11 interface to the S-GW to manage the PDN Connections and the
dedicated bearers associated with the PDN connections. The role of S11 is similar to that of S4
(between the SGSN and S-GW) and Gn/Gp between the SGSN and the GGSN. This interface is
based on GTPv2. The protocol stack for this interface is depicted as follows.


35
Interfaces
Figure 10. Protocol stack for S11 interface
GTP-C
GTP-C
UDP
UDP
IP
IP
L2
L2
L1
L1
MME
S-GW
The peer node for the S11 interface is the S-GW. The MME allows the operator to configure the
specification version of the GTPv2 to be used over the S11 interface. The same version is also used
for the S4 interfaces if the node is configured as a combined MME/SGSN. The supported versions of
TS 29.274 are: V9.5.0 and V10.10.0. The following table shows the messages supported for each of
the configured versions.
Table 9.
S11 interface Messages
Message Type
Message Direction
V9.5.0/V10.10.0
Echo Request
S-GW <-> MME
Supported
Echo Response
S-GW <-> MME
Supported
Create Session Request
S-GW <- MME
Supported
Create Session Response
S-GW -> MME
Supported
Create Bearer Request
S-GW -> MME
Supported
Create Bearer Response
S-GW <- MME
Supported
Bearer Resource Command
S-GW <- MME
Supported
Bearer Resource Failure Indication
S-GW -> MME
Supported
Modify Bearer Request
S-GW <- MME
Supported
10
Modify Bearer Response
S-GW -> MME
Supported
11
Delete Session Request
S-GW <- MME
Supported
12
Delete Session Response
S-GW -> MME
Supported
13
Delete Bearer Request
S-GW -> MME
Supported
14
Delete Bearer Response
S-GW <- MME
Supported
15
S-GW -> MME
Supported
16
S-GW <- MME
Supported


36
Interfaces
Message Type
Message Direction
V9.5.0/V10.10.0
Acknowledge
17
Downlink Data Notification Failure

Indication
S-GW <- MME
Supported
18
Modify Bearer Command
S-GW <- MME
Supported
19
Modify Bearer Failure Indication
S-GW -> MME
Supported
20
Update Bearer Request
S-GW -> MME
Supported
21
Update Bearer Response
S-GW <- MME
Supported
22
Delete Bearer Command
S-GW <- MME
Supported
23
Delete Bearer Failure Indication
S-GW -> MME
Supported
24
Create Indirect Data Forwarding

Tunnel Request
S-GW <- MME
Supported
25
Create Indirect Data Forwarding

Tunnel Response
S-GW -> MME
Supported
26
S-GW <- MME
Supported
27
Suspend Acknowledge
S-GW -> MME
Supported
28
Resume Notification
S-GW <- MME
Supported
29
Resume Acknowledge
S-GW -> MME
Supported
30
Create Forward Tunneling Request
MME -> S-GW
Supported
31
Create Forward Tunneling Response
MME <- S-GW
Supported
32
Delete Indirect Data Forwarding

Tunnel Request
S-GW <- MME
Supported
33
Delete Indirect Data Forwarding

Tunnel Response
S-GW -> MME
Supported
34
Release Access Bearers Request
S-GW <- MME
Supported
35
Release Access Bearers Response
S-GW -> MME
Supported
36
Stop Paging Indication
S-GW -> MME
Not supported
37
Trace Session Activation
MME -> S-GW
Supported
38
Trace Session Deactivation
MME -> S-GW
Supported
39
Change Notification Request
S-GW -> MME
Supported
40
Change Notification Response
MME -> S-GW
Supported
41
Delete PDN Connection Set Request
MME <-> S-GW
Not supported
42
Delete PDN Connection Set

Response
MME <-> S-GW
Not supported
43
Modify Access Bearers Request
MME -> S-GW
Not supported
44
Modify Access Bearers Response
S-GW -> MME
Not supported


37
Interfaces
At the GTP layer, the MME maintains S11 relationship with up to 1,000 S-GWs. Each S-GW peer is
represented by a unique IP address. Path management function is used to monitor the health and/or
reach-ability of the peer node. DNS procedures as defined in TS29.303 are used for the discovery of
the SGW IP addresses.
connectivity to both IPv4 S-GWs and IPv6 S-GWs at the same time. Up to two local IP addresses
(one IPv4, one IPv6) are needed for the S11 interface. If only IPv4 is used by all the peer nodes, then
the IPv6 address is not required. The local IP addresses can be shared with all other GTP-C
interfaces.
5.2.7 S13 Interface

The S13 interface permits the MME or SGSN to validate the equipment used by the subscriber.
The following figure shows the protocol stack used by the S13 interface.
Figure 11. Protocol Stack for S13 interface
S13
S13
Diameter
Diameter
IP
IP
L2
L2
L1
L1
S13
MME/SGSN
EIR
The peer node for the S13 interface is the Equipment Identity Register (EIR). The vMME can connect
directly to the EIR nodes, or indirectly via a set of Diameter Agents. S13 and S6 can use the same set
of Diameter Agents.
Per specification, the vMME supports one EIR only via the S13 interface. The versions supported for
the S13 interface are TS 29.272 v9.5.0 and 10.7.0. The following table shows the messages
supported.


38
Interfaces
Table 10.
S13 Messages
Message Type
Message Direction
V9.5.0/V10.7.0
ME-Identity-Check-Request
HSS <- MME/SGSN
Supported
ME-Identity-Check-Answer
HSS -> MME/SGSN
Supported
At the SCTP layer and IP layer, the S13 interface shares the local IP addresses with the S6 interface.
Therefore, S13 interface does not cause additional IP address consumption on the node.
5.2.8 S16 Interface

The S16 interface facilitates the inter-SGSN UE mobility between two S4-SGSN nodes. This interface
along with other mobility interfaces (S3, S10 and Gn/Gp) is based on the prevalent GTP protocol. For
the S-based EPC interfaces, GTPv2 is used. For the legacy Gn/Gp interface, GTPv1 is used.
The protocol stack for the S16 interface is captured in Figure 6 Protocol Stack for S3 and other
Mobility Management interfaces.
The peer node for the S16 interface is the other S4-SGSN involved in the mobility management
procedure.
For the S16 interface, the vMME supports TS29.274 V9.5.0 and V10.10.0. The following table shows
the messages supported.
Table 11.
S16 Messages
Message Type
Message Direction
V9.5.0/V10.10.0
Echo Request
Old SGSN <-> New SGSN
Supported
Echo Response
Old SGSN <-> New SGSN
Supported
Old SGSN <- New SGSN
Supported
Old SGSN -> New SGSN
Supported
Context Request
Supported
Context Response
Old SGSN -> New SGSN
Supported
Context Acknowledge
Supported
Target SGSN <- Source SGSN
Supported
Target SGSN -> Source SGSN
Supported
10
Supported
11
Supported
12

Notification
Supported
13
Supported


39
Interfaces
Message Type
Message Direction
V9.5.0/V10.10.0
Acknowledge
14

Notification
Supported
15

Acknowledge
Supported
16
Configuration Transfer Tunnel
Source SGSN -> Target SGSN
Supported
17
SGSN <-> SGSN
Supported
18
SGSN <-> SGSN
Supported
19
Suspend Acknowledge
SGSN <-> SGSN
Supported
The S16 interface is similar to the S3 interface. Please refer to S3 Interface related to the GTP layer
and IP layer information.
5.2.9 S101 Interface

The S101 interface bridges the 4G E-UTRAN network with the CDMA HRPD network. The interface
connects the MME with the eAN in the HRPD network to facilitate inter-RAT mobility between the EUTRAN and HRPD networks.
The S101 is yet another interface based on GTPv2. The protocol stack is as shown in the following.


40
Interfaces
GTP-C
GTP-C
UDP
UDP
IP
IP
L2
L2
L1
L1
MME
eAN
The MME allows the operator to configure the specification version of the S101. The supported
versions of TS 29.276 are: V9.4.06 V10.3.0 and V11.0.0. The following table shows the messages
supported for each of the configured versions.
Table 12.
S101 Interfaces Messages
Message Type
Message
Direction
V9.4.0/V10.3.0/V11.0.0
Echo Request
MME <--> eAN
Supported
Echo Response
MME <--> eAN
Supported
Version Not Supported Indication
MME <--> eAN
Supported
Direct Transfer Request message
MME <--> eAN
Supported
Direct Transfer Response message
MME <--> eAN
Supported
Notification Request message
MME <--> eAN
Supported
Notification Response message
MME <--> eAN
Supported
The MME maintains S101 relationship with up to 15,000 eANs. Each eAN is represented by a unique
IP address. Path management function is used to monitor the health and/or reach-ability of the peer
node. The IP addresses of the eANs are locally configured on the MME to map from a CDMA2000
reference cell identifier to a particular eAN.
With proprietary extensions.


41
Interfaces
connectivity to both IPv4 eANs and IPv6 eANs at the same time. Up to two local IP addresses (one
IPv4, one IPv6) are needed for the S101 interface. If only IPv4 is used by all the peer nodes, then the
IPv6 address is not required.
5.2.10 S102 Interface

The S102 interface is used between the MME and the 1xRTT Interworking System (IWS) used to
support traditional circuit voice calls in CDMA network. This is to support circuit switched fallback
function for UE current attached on the 4G E-UTRAN network to make a voice call in the CDMA
1xRTT network. The following figure shows the protocol stack of the interface.
S102AP
S102AP
UDP
UDP
IP
IP
L2
L2
L1
L1
MME
IWS
The MME supports two different versions of protocol. One is based on version 10.0.0 of TS 29.277.
The second version is based on a proprietary Interface Control Document (ICD). The operator can
configure the version to use based on the protocol used by the IWS. The following table shows the
Table 13.
S102 Interface Messages
Message Type
Message Direction
V10.0.0/V11.1.0
ICD-v2
Echo Request
MME <--> IWS
Not Supported
Supported
Echo Response
MME <--> IWS
Not Supported
Supported
A21-1x Air Interface Signaling
MME <--> IWS
Supported
Supported
A21-Ack
MME <--> IWS
Supported
Supported
A21-Event Notification
MME ---> IWS
Supported
Supported


42
Interfaces
The MME connects up to 200 IWS nodes over the S102 interface. Each IWS is represented by an IP
address. When a tunneled CDMA 2000 message is received from the eNodeB, the MME maps the
1xRTT CDMA sector id to the IP address of the IWS. The MME also keeps a mapping of the IP
address of the IWS to a list of eNodeBs that have sent uplink CDMA 2000 messages that are
destined to the IWS.
Both IPv4 and IPv6 IP addresses can be used locally on the MME. If IPv6 is not used by any of the
IWS nodes, then the IPv6 address does not need to be configured.
5.2.11 SBc Interface

The SBc interface is used for the operator to broadcast emergency warning messages via the MME
to the eNodeBs in the area that emergency condition exists or is about to happen. Its main use is to
deliver Earthquake and Tsunami warnings in some countries and Public Warning System messages
in others. This is an optional interface and can be configured based on the regulations in the country
the MME is deployed.
The warning messages received from the SBc interface are broadcast via the S1 interface. The
protocol stack for the related interfaces is shown in the following figure.
Figure 14. Protocol Stack for CBC eNB
Interworking
S1-AP
S1-AP
SBc-AP
SBc-AP
SCTP
SCTP
SCTP
SCTP
IP
IP
IP
IP
L2
L2
L2
L2
L1
L1
L1
L1
SBc
S1-MME
eNodeB
MME
CBC
The application layer protocol is SBc Application Protocol (SBc-AP). This protocol supports transfer of
warning messages. The MME supports two version of TS 29.168 for the SBs interface: v9.3.0,v10.2.0
and v11.4.0. The version used can be configured by the operator. The following table shows the
messages supported for each version.
Table 14.
SBc Interface Messages
Message Type
Message Direction
V9.3.0/10.2.0/11.4.0
Write-Replace Warning Request
CBC -> MME
Supported


43
Interfaces
Message Type
Message Direction
V9.3.0/10.2.0/11.4.0
Write-Replace Warning Response
CBC <- MME
Supported
STOP Warning Request
CBC -> MME
Supported
STOP Warning Response
CBC <- MME
Supported
Error Indication
CBC <-> MME
Supported
The MME supports multiple-homed SCTP associations with the CBC nodes. A maximum of four
SCTP associations can be established. For the SBc interface, either IPv4 or IPv6 addresses can be
used.
5.2.12 SGs Interface

SGs is the interface between the MME and the VLR used for Circuit Switched Fallback (CSFB) to the
GSM/UMTS network and Short Message Service (SMS). The protocol stack is shown in the following.
Figure 15. Protocol Stack for SGs interface
SGsAP
SGsAP
SCTP
SCTP
IP
IP
L2
L2
L1
L1
SGs
MME
VLR/MSC
Server
The vMME is compliant to TS 29.118 with regard to the SGs interface. The different versions of
TS29.118 that are supported are: v9.3.0, v10.9.0 and 11.11.0. The following table shows the
messages supported over the SGs interface.
Table 15.
SGs Interface Messages
Message Type
Message Direction
V9.3.0/V10.9.0/V11.11.0
SGsAP-ALERT-ACK
MME --> MSC/VLR
Supported
SGsAP-ALERT-REJECT
MME --> MSC/VLR
Supported


44
Interfaces
Message Type
Message Direction
V9.3.0/V10.9.0/V11.11.0
SGsAP-ALERT-REQUEST
MME <-- MSC/VLR
Supported
SGsAP-DOWNLINK-UNITDATA
MME <-- MSC/VLR
Supported
SGsAP-EPS-DETACH-ACK
MME <-- MSC/VLR
Supported
SGsAP-EPS-DETACH-INDICATION
MME --> MSC/VLR
Supported
SGsAP-IMSI-DETACH-ACK
MME <-- MSC/VLR
Supported
SGsAP-IMSI-DETACH-INDICATION
MME --> MSC/VLR
Supported
SGsAP-LOCATION-UPDATE-ACCEPT
MME <-- MSC/VLR
Supported
10
SGsAP-LOCATION-UPDATE-REJECT
MME <-- MSC/VLR
Supported
11
SGsAP-LOCATION-UPDATE-REQUEST
MME --> MSC/VLR
Supported
12
SGsAP-MM-INFORMATION-REQUEST
MME <-- MSC/VLR
Supported
13
SGsAP-PAGING-REJECT
MME --> MSC/VLR
Supported
14
SGsAP-PAGING-REQUEST
MME <-- MSC/VLR
Supported
15
SGsAP-RESET-ACK
MME <--> MSC/VLR
Supported
16
SGsAP-RESET-INDICATION
MME <--> MSC/VLR
Supported
17
SGsAP-SERVICE-REQUEST
MME --> MSC/VLR
Supported
18
SGsAP-STATUS
MME <--> MSC/VLR
Supported
19
SGsAP-TMSI-REALLOCATIONCOMPLETE
MME --> MSC/VLR
Supported
20
SGsAP-UE-ACTIVITY-INDICATION
MME --> MSC/VLR
Supported
21
SGsAP-UE-UNREACHABLE
MME --> MSC/VLR
Supported
22
SGsAP-UPLINK-UNITDATA
MME --> MSC/VLR
Supported
23
SGsAP-RELEASE-REQUEST
MME <-- MSC/VLR
Supported
The MME supports connections to a maximum of 256 VLRs. The MME initiates SCTP associations
with the VLR nodes. Multi-homed SCTP associations are supported to provide additional reliability for
the SGs interface. To help signaling scalability on the VLR side, the MME supports the ability to have
multiple SCTP associations between the MME and the VLR. Either IPv4 or IPv6 can be used for the
SGs interface.
5.2.13 Sv Interface
The Sv interface supports the Single Radio Voice Call Continuity procedure between the MME and
the VLR such that a voice call started on the EPC network using VoLTE can be handed over to the
legacy circuit domain seamlessly.
The Sv is another interface based on GTPv2. The protocol stack is as shown in the following.


45
Interfaces
Figure 16. Protocol stack for Sv interface
GTP-C
GTP-C
UDP
UDP
IP
IP
L2
L2
L1
L1
MME
VLR
The Sv interface supported on the MME is based on TS29.280 v10.4.0. The following table shows the
messages supported.
Table 16.
Sv Interface Messages
Message Type
Message Direction
V10.4.0
Echo Request
MME <--> VLR
Supported
Echo Response
MME <--> VLR
Supported
MME <--> VLR
Supported
SRVCC PS to CS Request
MME --> VLR
Supported
SRVCC PS to CS Response
MME <-- VLR
Supported
SRVCC PS to CS Complete Notification
MME <-- VLR
Supported
SRVCC PS to CS Complete Acknowledge
MME --> VLR
Supported
SRVCC PS to CS Cancel Notification
MME --> VLR
Supported
SRVCC PS to CS Cancel Acknowledge
MME <-- VLR
Supported
The MME maintains Sv relationship with up to 256 VLRs. Each VLR is represented by a unique IP
address. Path management function is used to monitor the health and/or reach-ability of the peer
node. The IP addresses of the VLR are obtained using DNS procedure or local configuration, based
on the current location of the UE.
connectivity to both IPv4 VLR and IPv6 VLR at the same time. Up to two local IP addresses (one
IPv4, one IPv6) are needed for the Sv interface. If only IPv4 is used by all the peer nodes, then the
IPv6 address is not required. The local IP addresses used for the Sv interface can be shared with
other GTP-C based interfaces.

46
Interfaces
5.2.14 SLg Interface

SLg is the interface between MME and GMLC. The protocol used in this interface is ELP (EPC LCS
Protocol) which is defined as a Vendor Specific diameter application. This interface is used to convey
a location request to the MME currently serving a particular target UE whose location was requested.
It is also used by the MME to return location results to the GMLC. The following figure shows the
protocol stack for this interface.
Figure 17. Protocol Stack for SLg interface
ELP
ELP
Diameter
Diameter
SCTP
SCTP
IP
IP
L2
L2
L1
L1
SLg
MME
E-GMLC
The SLg interface supported on the MME is based on TS29.172 v10.1.0 and v11.1.0. The messages
supported over the SLg interface are detailed in the following table.
Table 17.
SLg Interface Messages
Message Type
Message Direction
Supported/Not
Supported
Provide Location Request (PLR)
MME GMLC
Supported
Provide Location Answer (PLA)
MME GMLC
Supported
Location Report Request (LRR)
MME GMLC
Supported
Location Report Answer (LRA)
MME GMLC
Supported
The MME supports communication with up to 50 GMLCs either directly or via Diameter Relay Agents.
The SLg interface shares the Diameter Clients with the other Diameter based interfaces on the
vMME: S6/S13. Thus the lower layer capability such as the SCTP layer and IP layer is the same as
that of the S6/S13 interfaces.


47
Interfaces
5.2.15 SM Interface
The SM interface is a GTPv2 based protocol between the MBMS-GW and the MME for MBMS Bearer
context management.
5.2.16 SLs Interface

SLs is the interface between MME and E-SMLC. The protocol used in this interface is LCS-AP (LCS
Application Protocol). The SLs interface is used to convey location requests from the MME to the ESMLC and to convey corresponding location reports back from the E-SMLC to the MME. It is also
used for tunneling LTE Positioning Protocols (LPP, LPPa), which are transparent to the MME. The
protocol stack for this interface is LCS-AP over SCTP with MME as the SCTP client (see the following
figure).
Figure 18. Protocol Stack for SLs interface
Relay
LPP/LPPa
NAS
LCS-AP
LCS-AP
SCTP
SCTP
SCTP
IP
IP
IP
L2
L2
L2
L1
L1
L1
S1-AP
SLs
MME
E-SMLC
The SLs interface supported on the MME is based on TS29.171 v10.4.0 and v11.3.0. The messages
supported over the SLs interface are detailed in the following table.
Table 18.
SLs Interface Messages
Message Type
Message Direction
Supported/Not
Supported
Location Request
MME E-SMLC
Supported
Location Response
MME E-SMLC
Supported
Abort Request
MME E-SMLC
Supported
Reset Request
MME E-SMLC
Supported


48
Interfaces
Reset Request ACK
MME E-SMLC
Supported
Connection Oriented Information message
MME E-SMLC
Supported
Connectionless Information message
MME E-SMLC
Supported
The MME supports connections to a maximum of 20 E-SMLCs, which can be group into pools. The
MME initiates SCTP associations with the E-SMLC. Multi-homed SCTP associations are supported to
provide additional reliability for the SLs interface.
5.2.17 Fxa Interface

The Fxa interface is used to allow the MME to interface with an AAA server to support a PGW
selection procedure so as to facilitate non-optimized mobility procedure between HRPD network and
E-UTRAN network. The interface is proprietary and is not defined by the 3GPP specification.
The Fxa interface is based on the RADIUS protocol. The peer node is the AAA server. The following
figure shows the protocol stack for the interface.
Figure 19. Protocol Stack for Fxa interface
RADIUS
RADIUS
UDP
UDP
IP
IP
L2
L2
L1
L1
Fxa
MME
AAA
The messages supported over the Fxa interface are detailed in the following table.
Table 19.
Fxa Interface Messages
Message Type
Message Direction
Supported/Not
Supported
RADIUS ACCESS-REQUEST
MME -> AAA
Supported
RADIUS ACCESS-ACCEPT
MME <- AAA
Supported
RADIUS ACCESS-REJECT
MME <- AAA
Supported


49
Interfaces
The MME supports a max of 128 peer AAA servers. Each AAA server is represented with an IP
address. Locally, only one IP address is required. It can be either IPv4 or IPv6.
Path management function is used to monitor the health and/or reach-ability of the peer node. The
MME monitors the status of the external AAA by sending a pseudo-RADIUS ACCESS REQUEST
and receiving either a pseudo RADIUS ACCESS ACCEPT or a pseudo ACCESS REJECT message
from the external AAA server.
5.2.18 Ga Interface
The Ga interface is used between the SGSN and the Charging Gateway Function (CGF) for
transferring billing records collected on the SGSN. The SGSN transfers S-CDR, M-CDR and SMSCDR to the CGF using this interface. The following figure shows the protocol stack of the interface.
Figure 20. Protocol stack for Ga interface
GTP
GTP
UDP
UDP
IP
IP
L2
L2
L1
L1
SGSN
CGF
The SGSN supports four different versions of billing record format, the version of GTP protocol used
to is determined based on the version of the billing record format. The operator can configure the
version to use based on the billing record format required and compatibility with the CGF, i.e., the
configured version needs to match what can be decoded by the CGF. Please refer to Accounting
service for the mapping of billing record format version and the GTPs protocol version. The following
table shows the messages supported.
Table 20.
Ga Interface Messages
Message Type
Message Direction
Version 9.6.1/10.12.0
Echo Request
SGSN <--> CGF
Supported
Echo Response
SGSN <--> CGF
Supported


50
Interfaces
Message Type
Message Direction
Version 9.6.1/10.12.0
Version Not Supported
SGSN <--> CGF
Supported
Node Alive Request
SGSN <--> CGF
Supported
Node Alive Response
SGSN <--> CGF
Supported
Redirection Request
SGSN <-- CGF
Supported
Redirection Response
SGSN --> CGF
Supported
Data Record Transfer Request
SGSN --> CGF
Supported
Data Record Transfer Response
SGSN <-- CGF
Supported
The SGSN connects up to two CGF nodes over the Ga interface. The SGSN only starts to use the
second CGF if the first CGF fails.
For the Ga interface, only IPv4 address is supported.
5.2.19 Gb Interface
The Gb interface connects the 2G GERAN to the SGSN. It is used to transport user signaling as well
as user data. The SGSN supports IP based transport towards the BSS (or PCU).
Figure 21. Protocol stack for Gb interface (IP based transport)
BSSGP
BSSGP
NS-IP
NS-IP
UDP
UDP
L2
L2
L1
L1
SGSN
BSS


51
Interfaces
The peer node for the Gb interface is the Base Station System (BSS). More precisely, the function in
the BSS that interfaces with the SGSN is referred to as the Packet Control Unit (PCU). Each PCU
can logically support one or more Network Service Entities (NSEs). The SGSN supports connection
to a maximum of 600 NSEs. Within each NSE, a group of cells can be supported. The protocol to
manage the cells runs on top of the Network Service (NS) layer. The protocol is referred to as
BSSGP (Base Station System GPRS Protocol). At the BSSGP layer, each cell is represented as a
BVC (BSSGP Virtual Circuit). The SGSN supports up to 1000 BVCs per NSE and a maximum of total
30000 BVCs across all NSEs.
The SGSN allows the operator to configure the specification version of the Gb to be used. The
following tables show the messages supported for each of the configured versions.
Table 21.
Gb NS messages
Message Type
Message Direction
Version 9
Version 10
NS-ALIVE
SGSN <--> BSS
Supported
Supported
NS-ALIVE-ACK
SGSN <--> BSS
Supported
Supported
NS-BLOCK
SGSN <--> BSS
Supported
Supported
NS-BLOCK-ACK
SGSN <--> BSS
Supported
Supported
NS-RESET
SGSN <--> BSS
Supported
Supported
NS-RESET-ACK
SGSN <--> BSS
Supported
Supported
NS-STATUS
SGSN <--> BSS
Supported
Supported
NS-UNBLOCK
SGSN <--> BSS
Supported
Supported
NS-UNBLOCK-ACK
SGSN <--> BSS
Supported
Supported
10
NS-UNITDATA
SGSN <--> BSS
Supported
Supported
Table 22.
Gb IP Sub-Network Service Control messages
Message Type
Message Direction
Version 9
Version 10
SNS-ACK
SGSN <--> BSS
Supported
Supported
SNS-ADD
SGSN <--> BSS
Supported
Supported
SNS-CHANGEWEIGHT
SGSN <--> BSS
Supported
Supported
SNS-CONFIG
SGSN <--> BSS
Supported
Supported
SNS-CONFIG-ACK
SGSN <--> BSS
Supported
Supported
SNS-DELETE
SGSN <--> BSS
Supported
Supported
SNS-SIZE
SGSN <--> BSS
Supported
Supported
SNS-SIZE-ACK
SGSN <--> BSS
Supported
Supported


52
Interfaces
Table 23.
Gb BSSGP messages
Message Type
Message Direction
Version 9
Version 10
DL-UNITDATA
SGSN --> BSS
Supported
Supported
UL-UNITDATA
SGSN <-- BSS
Supported
Supported
RA-CAPABILITY
SGSN --> BSS
Supported
Supported
DL-MBMS-UNITDATA
SGSN --> BSS
Not supported
Not supported
UL-MBMS-UNITDATA
SGSN <-- BSS
Not supported
Not supported
PAGING PS
SGSN --> BSS
Supported
Supported
PAGING CS
SGSN --> BSS
Supported
Supported
RA-CAPABILITY-UPDATE
SGSN <-- BSS
Supported
Supported
RA-CAPABILITY-UPDATE-ACK
SGSN --> BSS
Supported
Supported
10
RADIO-STATUS
SGSN <-- BSS
Supported
Supported
11
SUSPEND
SGSN <-- BSS
Supported
Supported
12
SUSPEND-ACK
SGSN --> BSS
Supported
Supported
13
SUSPEND-NACK
SGSN --> BSS
Supported
Supported
14
RESUME
SGSN <-- BSS
Supported
Supported
15
RESUME-ACK
SGSN --> BSS
Supported
Supported
16
RESUME-NACK
SGSN --> BSS
Supported
Supported
17
FLUSH-LL
SGSN --> BSS
Supported
Supported
18
FLUSH-LL-ACK
SGSN <-- BSS
Supported
Supported
19
LLC-DISCARDED
SGSN <-- BSS
Supported
Supported
20
FLOW-CONTROL-BVC
SGSN <-- BSS
Supported
Supported
21
FLOW-CONTROL-BVC-ACK
SGSN --> BSS
Supported
Supported
22
FLOW-CONTROL-MS
SGSN <-- BSS
Supported
Supported
23
FLOW-CONTROL-MS-ACK
SGSN --> BSS
Supported
Supported
24
BVC-BLOCK
SGSN <-- BSS
Supported
Supported
25
BVC-BLOCK-ACK
SGSN --> BSS
Supported
Supported
26
BVC-UNBLOCK
SGSN <-- BSS
Supported
Supported
27
BVC-UNBLOCK-ACK
SGSN --> BSS
Supported
Supported
28
BVC-RESET
SGSN <--> BSS
Supported
Supported
29
BVC-RESET-ACK
SGSN <--> BSS
Supported
Supported
30
STATUS
SGSN <--> BSS
Supported
Supported
31
SGSN-INVOKE-TRACE
SGSN --> BSS
Not supported
Not supported
32
DOWNLOAD-BSS-PFC
SGSN <-- BSS
Supported
Supported
33
CREATE-BSS-PFC
SGSN --> BSS
Supported
Supported
34
CREATE-BSS-PFC-ACK
SGSN <-- BSS
Supported
Supported


53
Interfaces
Message Type
Message Direction
Version 9
Version 10
35
CREATE-BSS-PFC-NACK
SGSN <-- BSS
Supported
Supported
36
MODIFY-BSS-PFC
SGSN <-- BSS
Supported
Supported
37
MODIFY-BSS-PFC-ACK
SGSN --> BSS
Supported
Supported
38
DELETE-BSS-PFC
SGSN --> BSS
Supported
Supported
39
DELETE-BSS-PFC-ACK
SGSN <-- BSS
Supported
Supported
40
FLOW-CONTROL-PFC
SGSN <-- BSS
Supported
Supported
41
FLOW-CONTROL-PFC-ACK
SGSN --> BSS
Supported
Supported
42
DELETE-BSS-PFC-REQ
SGSN <-- BSS
Supported
Supported
43
PS-HANDOVER-REQUIRED
SGSN <-- BSS
Not supported
Not supported
44
PS-HANDOVER-REQUIRED-ACK
SGSN --> BSS
Not supported
Not supported
45
PS-HANDOVER-REQUIREDNACK
SGSN --> BSS
Not supported
Not supported
46
PS-HANDOVER-REQUEST
SGSN --> BSS
Not supported
Not supported
47
PS-HANDOVER-REQUEST-ACK
SGSN <-- BSS
Not supported
Not supported
48
PS-HANDOVER-REQUEST-NACK
SGSN <-- BSS
Not supported
Not supported
49
PS-HANDOVER-COMPLETE
SGSN <-- BSS
Not supported
Not supported
50
PS-HANDOVER-CANCEL
SGSN <-- BSS
Not supported
Not supported
51
PS-HANDOVER-COMPLETE-ACK
SGSN --> BSS
Not supported
Not supported
52
PERFORM-LOCATION-REQUEST
SGSN --> BSS
Not supported
Not supported
53
PERFORM-LOCATIONRESPONSE
SGSN <-- BSS
Not supported
Not supported
54
PERFORM-LOCATION-ABORT
SGSN --> BSS
Not supported
Not supported
55
POSITION-COMMAND
SGSN <-- BSS
Not supported
Not supported
56
POSITION-RESPONSE
SGSN --> BSS
Not supported
Not supported
57
RAN-INFORMATION-REQUEST
SGSN <--> BSS
Supported
Supported
58
RAN-INFORMATION
SGSN <--> BSS
Supported
Supported
59
RAN-INFORMATION-ACK
SGSN <--> BSS
Supported
Supported
60
RAN-INFORMATION-ERROR
SGSN <--> BSS
Supported
Supported
61
RAN-INFORMATIONAPPLICATION-ERROR
SGSN <--> BSS
Supported
Supported
62
MBMS-SESSION-STARTREQUEST
SGSN --> BSS
Not supported
Not supported
63
MBMS-SESSION-STARTRESPONSE
SGSN <-- BSS
Not supported
Not supported
64
MBMS-SESSION-STOPREQUEST
SGSN --> BSS
Not supported
Not supported
65
MBMS-SESSION-STOP-
SGSN <-- BSS
Not supported
Not supported


54
Interfaces
Message Type
Message Direction
Version 9
Version 10
RESPONSE
66
MBMS-SESSION-UPDATEREQUEST
SGSN --> BSS
Not supported
Not supported
67
MBMS-SESSION-UPDATERESPONSE
SGSN <-- BSS
Not supported
Not supported
The Gb interface provides transport for both user signaling and user bearer. The following subsection
covers the user bearer. The user signaling is discussed in NAS layer for the SGSN.
5.2.19.1 User Bearer over Gb

The following figure shows the protocol stack used for the 2G user bearer.
Figure 22. Protocol Stack for Gb User Bearer Plane
Application
IP
IP
SNDCP
Relay
SDNCP
LLC
UDP
UDP
LLC
Relay
RLC
RLC
BSSGP
-
BSSGP
IP
IP
L2
MAC
MAC
NS
NS
L2
GSM RF
GSM RF
L1
L1
L1
MS
GTP-U
GTP-U
Uu
BSS
Iu -PS
SGSN
L1
Gn/S4
GGSN/SGW
The key protocol used between the SGSN and the MS for user bearer transport is the SNDCP layer
and the LLC layer. The SGSN supports the release 9 version of TS44.064 (LLC) and TS44.065
(SNDCP). The following tables show the messages supported for the two protocols.
Table 24.
SNDCP Messages
Message Type
Message Direction
V9.0.0/V10.1.0/V11.0.0
SN-DATA
SGSN <--> MS
Supported
SN-UNITDATA
SGSN <--> MS
Supported
SN-XID
SGSN <--> MS
Supported


55
Interfaces
Table 25.
LLC Messages
Frame Type
Message Type
Message Direction
V9.0.0/V10.0.0/V11.0.0
Combined Information
(I) and Supervisory
(S) frames
RR
SGSN <--> MS
Supported
(I) and Supervisory
(S) frames
ACK
SGSN <--> MS
Supported
(I) and Supervisory
(S) frames
RNR
SGSN <--> MS
Supported
(I) and Supervisory
(S) frames
SACK
SGSN <--> MS
Supported
Unnumbered (U)
frames
DM
SGSN <--> MS
Supported
Unnumbered (U)
frames
DISC
SGSN <--> MS
Supported
Unnumbered (U)
frames
UA
SGSN <--> MS
Supported
Unnumbered (U)
frames
SABM
SGSN <--> MS
Supported
Unnumbered (U)
frames
FRMR
SGSN <--> MS
Supported
10
Unnumbered (U)
frames
XID
SGSN <--> MS
Supported
11
Unnumbered (U)
frames
NULL
SGSN <--> MS
Supported
12
Unconfirmed
Information (UI) frame
UI
SGSN <--> MS
Supported
5.2.20 Gd Interface
The Gd interface allows the SGSN to deliver SMS text message to subscribers. For the vMME, the
Gd interface is only available for UEs currently attached on the 2G network. For UEs on the 3G
network, the SMS delivery is achieved via the VLR directly to the UE. For UEs on the 4G network, the
MME supports SMS delivery from the VLR via the SGs interface.
The Gd interface uses MAP based protocol suite, which is shared by the Gr and Gf interface.
Furthermore, message transport layers are shared with other SS7 based interfaces: Gf, Gs and Ge.

56
Interfaces
The SGSN only support SIGTRAN based signaling transport. However, off the shelf signaling
gateway can be used to convert from SIGTRAN to traditional E1/DS1 based SS7 transport.
The SGSN uses the Gd interface to communicate with the SMS-GMSC or SMS-IWMSC for the SMS
originated from or terminated to the UE. The protocol stack is depicted in the following figure.
Figure 23. Protocol Stack for Gd interface
MAP
MAP
TCAP
TCAP
SCCP
SCCP
M3UA
M3UA
SCTP
SCTP
IP
IP
L2
L2
L1
L1
Gd
SGSN
SMS-GMSC or
SMS-IWMSC
The SGSN supports two versions of TS29.002 for all MAP based interfaces: V9.4.0, 10.10.0 or
11.11.0. The following table shows the messages supported for each version.
Table 26.
#
Gd Messages
Message Type
Message Direction
V9.4.0/V10.10.0/
V11.11.0
MAP-MO-FORWARD-SHORT-MESSAGE request
SGSN --> SMS-GMSC
Supported
MAP-MO-FORWARD-SHORT-MESSAGE response
SGSN <-- SMS-GMSC
Supported
MAP-READY-FOR-SM request
SGSN --> SMS-GMSC
Supported
MAP-READY-FOR-SM response
SGSN <-- SMS-GMSC
Supported
MAP-MT-FORWARD-SHORT-MESSAGE request
SGSN <-- SMS-GMSC
Supported
MAP-MT-FORWARD-SHORT-MESSAGE response
SGSN --> SMS-GMSC
Supported


57
Interfaces
The SGSN supports direct connections to a maximum of 500 SIGTRAN capable peers. At a minimum
the peer node should support M3UA and SCTP layer. Upper layer capabilities of the peer depend on
the role of the peer. For example, if the peer is a SIGTRAN capable SMS-GMSC, then the peer node
has all the protocol layers depicted in the preceding figure. The following tables show the messages
supported at the M3UA layer, SCCP layer and TCAP layer. The versions used correspond to the
TS29.002 even though TS29.002 does not define the details of the protocols. The M3UA layer is
defined by RFC 4666. The SCCP layer is defined by ITU-T Q.711-Q.716. The TCAP layer is defined
by ITU-T Q.771-Q.775.
Table 27.
M3UA Layer Messages
Message Type
Message Direction
V9.4.0/V10.8.0
Payload Data Message (DATA)
SGSN <--> M3UA peer
Supported
Destination Unavailable (DUNA)
SGSN <-- M3UA peer (SG)
Supported
Destination Available (DAVA)
Supported
Destination State Audit (DAUD)
SGSN --> M3UA peer (SG)
Supported
Signaling Congestion (SCON)
SGSN <--> M3UA peer
Receive only
Destination User Part Unavailable (DUPU)
Supported
Destination Restricted (DRST)
Supported
ASP Up
SGSN <--> M3UA peer
Supported
ASP Up Acknowledgement (ASP Up Ack)
SGSN <--> M3UA peer
Supported
10
ASP Down
SGSN <--> M3UA peer
Supported
11
ASP Down Acknowledgement (ASP Down Ack)
SGSN <--> M3UA peer
Supported
12
Heartbeat (BEAT)
SGSN <--> M3UA peer
Supported
13
Heartbeat Acknowledgement (BEAT Ack)
SGSN <--> M3UA peer
Supported
14
Registration Request (REG REQ)
SGSN <--> M3UA peer
Not supported
15
Registration Response (REG RSP)
SGSN <--> M3UA peer
Not supported
16
Deregistration Request (DEREG REQ)
SGSN <--> M3UA peer
Not supported
17
Deregistration Response (DEREG RSP)
SGSN <--> M3UA peer
Not supported
18
ASP Active
SGSN <--> M3UA peer
Supported
19
ASP Active Acknowledgement (ASP Active Ack)
SGSN <--> M3UA peer
Supported
20
ASP Inactive
SGSN <--> M3UA peer
Supported
21
ASP Inactive Acknowledgement (ASP Inactive Ack)
SGSN <--> M3UA peer
Supported
22
Error
SGSN <--> M3UA peer
Supported
23
Notify
SGSN <--> M3UA peer
Supported


58
Interfaces
Table 28.
SCCP Layer Messages
Message Type
Message Direction
V9.4.0/10.8.0
Connection Confirm (CC)
SGSN <--> SCCP peer
NA
Connection Request (CR)
SGSN <--> SCCP peer
NA
Connection Refused (CREF)
SGSN <--> SCCP peer
NA
Data Acknowledgement (AK)
SGSN <--> SCCP peer
NA
Data Form 1 (DT1)
SGSN <--> SCCP peer
NA
Data Form 2 (DT2)
SGSN <--> SCCP peer
NA
Expedited Data (ED)
SGSN <--> SCCP peer
NA
Expedited Data Acknowledgement (EA)
SGSN <--> SCCP peer
NA
Inactivity Test (IT)
SGSN <--> SCCP peer
NA
10
Protocol Data Unit Error (ERR)
SGSN <--> SCCP peer
NA
11
Released (RLSD)
SGSN <--> SCCP peer
NA
12
Release Complete (RLC)
SGSN <--> SCCP peer
NA
13
Reset Confirm (RSC)
SGSN <--> SCCP peer
NA
14
Reset Request (RSR)
SGSN <--> SCCP peer
NA
15
Subsystem-allowed (SSA)
SGSN <--> SCCP peer
Supported
16
Subsystem-out-of-service-grant (SOG)
SGSN <--> SCCP peer
Not supported
17
Subsystem-out-of-service-request (SOR)
SGSN <--> SCCP peer
Not supported
18
Subsystem-prohibited (SSP)
SGSN <--> SCCP peer
Supported
19
Subsystem-status-test (SST)
SGSN <--> SCCP peer
Supported
20
Unitdata (UDT)
SGSN <--> SCCP peer
Supported
21
Unitdata Service (UDTS)
SGSN <--> SCCP peer
Supported
22
Extended Unitdata (XUDT)
SGSN <--> SCCP peer
Supported
23
Extended Unitdata Service (XUDTS)
SGSN <--> SCCP peer
Supported
24
Subsystem Congested (SSC)
SGSN <--> SCCP peer
Supported
25
Long Unitdata (LUDT)
SGSN <--> SCCP peer
Supported
26
Long Unitdata Service (LUDTS)
SGSN <--> SCCP peer
Supported
For the Gd interface, only the connectionless service classes of the SCCP layer are used.
Table 29.
TCAP Layer Messages
Message Type
Message Direction
V9.4.0/V10.8.0
TC-BEGIN
SGSN <--> TC-peer
Supported
TC-END
SGSN <--> TC-peer
Supported
TC-CONTINUE
SGSN <--> TC-peer
Supported


59
Interfaces
Message Type
Message Direction
V9.4.0/V10.8.0
TC-ABORT
SGSN <--> TC-peer
Supported
TC-UNIDIRECTIONAL (NOTICE)
SGSN <--> TC-peer
Supported
At the SCTP layer, the SGSN supports multi-home capability. Each peer can have up to two IP
addresses configured on the SGSN. In this release only IPv4 is supported for the interface.
5.2.21 Ge Interface
The Ge interface is used to support the Customized Application for Mobile network Enhanced Logic
(CAMEL) Phase 3, which offers service providers the ability to implement an Intelligent Network (IN)
solution that functions as part of a General Packet Radio Service (GPRS) and/or Universal Mobile
Telephone System (UMTS) Network.
The Ge interface allows the SGSN to interact with the Service Control Point (SCP) in determining the
service rendered for a subscriber. This interface is one of the SS7 based interfaces, as such, it
shares the transport layer with Gf, Gr, Gd, Gs interfaces. The following figure shows the protocol
stack of the interface.


60
Interfaces
Figure 24. Protocol Stack for Ge interface

CAP
CAP
TCAP
TCAP
SCCP
SCCP
M3UA
M3UA
SCTP
SCTP
IP
IP
L2
L2
L1
L1
Ge
SGSN
SCP
The CAMEL Application Part (CAP) protocol allows the SCP and the SGSN to coordinate service
control for a UE. The SGSN is compliant to TS 29.078 version 9.2.0, V10.0.0 and V11.2.0. The
version to be used can be configured on the SGSN. The messages supported are detailed in the
following table.
Table 30.
Ge Interface messages
Message Type
Message Direction
V9.2.0/V10.0.0/V11.2.0
ActivityTestGPRS (result)
SGSN --> SCP
Supported
applyChargingReportGPRS (event)
SGSN --> SCP
Supported
entityReleasedGPRS
SGSN --> SCP
Supported
eventReportGPRS
SGSN --> SCP
Supported
initialDpGPRS
SGSN --> SCP
Supported
activtyTestGPRS (request)
SGSN <-- SCP
Supported
applyChargingGPRS
SGSN <-- SCP
Supported
applyChargingReportGPRS (result)
SGSN <-- SCP
Supported
cancelGPRS
SGSN <-- SCP
Supported
10
connectGPRS
SGSN <-- SCP
Supported
11
continueGPRS
SGSN <-- SCP
Supported
12
entityReleasedGPRS (result)
SGSN <-- SCP
Supported


61
Interfaces
Message Type
Message Direction
V9.2.0/V10.0.0/V11.2.0
13
eventReportGPRS (result)
SGSN <-- SCP
Supported
14
furnishChargingInformationGPRS
SGSN <-- SCP
Supported
15
releaseGPRS
SGSN <-- SCP
Supported
16
requestReportGPRSEvent
SGSN <-- SCP
Supported
17
resetTimerGPRS
SGSN <-- SCP
Supported
18
SendChargingInformationGPRS
SGSN <-- SCP
Not supported
For the transport layer capabilities, please refer to Gd Interface for information related to the TCAP
layer, the SCCP layer, the M3UA layer and the SCTP layer.
5.2.22 Gf Interface
The Gf interface allows the SGSN to verify the validity of the device used by the subscriber. This
interface has the same function as the S13 interface covered in S13 Interface.
As discuss in the previous section, Gf interface also uses the MAP based protocol suite. The protocol
stack is as shown below.


62
Interfaces
Figure 25. Protocol Stack for Gf interface

MAP
MAP
TCAP
TCAP
SCCP
SCCP
M3UA
M3UA
SCTP
SCTP
IP
IP
L2
L2
L1
L1
Gf
SGSN
EIR
The Gf interface only has a couple of messages as show the table below. Since it is MAP based
interface, it shares the configured version for all MAP based interfaces. Two versions of TS29.002 are
supported on the SGSN: V9.4.0 or V10.10.0.
Table 31.
Gf Messages
Message Type
Message Direction
V9.4.0/V10.8.0
MAP_CHECK_IMEI request
SGSN --> EIR
Supported
MAP_CHECK_IMEI response
SGSN <-- EIR
Supported
For the detail of the message transport layers for the Gf interface, please refer to Gd Interface for
information related to the TCAP layer, the SCCP layer, the M3UA layer and the SCTP layer.
5.2.23 Gn/Gp Interface

The Gn/Gp interface covers both the signaling plane and user bearer plane. The signaling plane is
used to support both the mobility management function between two SGSN nodes as well as session
management function between the SGSN and the GGSN. The user bearer plane is used to tunnel
user bearer plane packets between the SGSN and the GGSN. The Gn interface is for the GSN nodes
within a PLMN and the Gp interface denotes communication between nodes that belong to two
different PLMNs.

63
Interfaces
5.2.23.1 Gn/Gp Interface Control Plane

3GPP defined both GTPv0 and GTPv1 for the Gn/Gp interface. The vMME only supports GTPv1 for
the Gn/Gp interface. The protocol stack for the Gn/Gp interface is the same as the S3 interface for
the mobility management function (please refer to Figure 6 Protocol Stack for S3 and other Mobility
Management interfaces) and the same as the S4 interface for session management function (please
refer to Figure 7 Protocol stack for S4 interface).
the Gn/Gp interface. Two versions of TS29.060 are supported on the MME/SGSN: V9.5.0, V10.8.0
and V11.11.0. The following tables show the messages supported for each of the configured
versions.
Table 32.
Gn/Gp Interface Mobility Management Messages
Message Type
Message Direction
V9.5.0/V10.8.0/V11.11.0
Echo Request
SGSN <--> SGSN
Supported
Echo Response
SGSN <--> SGSN
Supported
SGSN <--> SGSN
Supported
SGSN <--> SGSN
Supported
SGSN <--> SGSN
Supported
SGSN Context Request
SGSN <--> SGSN
Supported
SGSN Context Response
SGSN <--> SGSN
Supported
SGSN Context Acknowledge
SGSN <--> SGSN
Supported
SGSN <--> SGSN
Supported
10
SGSN <--> SGSN
Supported
11
SGSN <--> SGSN
Supported
12
SGSN <--> SGSN
Supported
13
SGSN <--> SGSN
Supported
14

Acknowledge
SGSN <--> SGSN
Supported
15
Forward SRNS Context
SGSN <--> SGSN
Supported
16
Forward SRNS Context Acknowledge
SGSN <--> SGSN
Supported
17
SGSN <-> SGSN
Supported
18
Supported Extension Headers

Notification
SGSN <-> SGSN
Supported
Table 33.
Gn/Gp Interface Session Management Messages
Message Type
Message Direction
V9.5.0/V10.8.0
Echo Request
SGSN <--> GGSN
Supported


64
Interfaces
Message Type
Message Direction
V9.5.0/V10.8.0
Echo Response
SGSN <--> GGSN
Supported
SGSN <--> GGSN
Supported
Create PDP Context Request
SGSN --> GGSN
Supported
Create PDP Context Response
SGSN <-- GGSN
Supported
Update PDP Context Request
SGSN --> GGSN
Supported
Update PDP Context Response
SGSN <-- GGSN
Supported
Delete PDP Context Request
SGSN --> GGSN
Supported
Delete PDP Context Response
SGSN <-- GGSN
Supported
10
Initiate PDP Context Activation Request
SGSN <-- GGSN
Not supported
11
Initiate PDP Context Activation Response
SGSN --> GGSN
Not supported
12
PDU Notification Request
SGSN <-- GGSN
Not supported
13
PDU Notification Response
SGSN --> GGSN
Not supported
14
PDU Notification Reject Request
SGSN --> GGSN
Not supported
15
PDU Notification Reject Response
SGSN <-- GGSN
Not supported
16
Supported Extension Headers Notification
SGSN <--> GGSN
Supported
At the GTP layer, the vMME supports up to 1000 peers for mobility management purpose. Each peer
is represented by a unique IP address of the peer. Path management function is used to monitor the
health and/or reach-ability of the peer node. For Gn/Gp interface, the SGSN can use simple domain
name to IP mapping procedure when it is configured to be a standalone Gn SGSN node or the
NAPTR based procedure as defined in TS29.303 when S4 function is enabled.
At the IP layer, the SGSN supports both IPv4 and IPv6 addresses at the same time, thus allowing
connectivity to both IPv4 SGSN or GGSN and IPv6 SGSN or SGSN at the same time. Up to two local
IP addresses (one IPv4, one IPv6) are needed for the Gn/Gp mobility management part of the
interface. If only IPv4 is used by all the peer nodes, then the IPv6 address is not required. The local
IP addresses are shared with all other mobility management interfaces (S3/S10/S16). Similarly, up to
two local IP addresses (one IPv4, one IPv6) are needed for the Gn/Gp session management part of
the interface. If only IPv4 is used by all the peer nodes, then the IPv6 address is not required. The
local IP addresses are shared with the other session management interface (S4).
5.2.23.2 Gn/Gp Interface User Bearer Plane

The user bearer plane is used to tunnel user originated or terminated IP packets to and from the
GGSN. The figure below shows the protocol stack. The same protocol stack is also used by the Iu
interface user bearer traffic discussed in the Iu interface section.


65
Interfaces
Figure 26. Protocol Stack for GTP-U
GTP-U
GTP-U
UDP
UDP
IP
IP
L2
L2
L1
L1
SGSN
GGSN
RNC
SGSN
The SGSN uses only one local IPv4 address for the purpose. The number of IP addresses that can
be used by the GGSNs is not limited. The following table shows the messages supported.
Table 34.
Gn/Gp Interface User Bearer Plane Messages
Message Type
Message Direction
V9.3.0
Echo Request
SGSN <--> GGSN
Receive only
Echo Response
SGSN <--> GGSN
Supported
Error Indication
SGSN <--> GGSN
Supported
Supported Extension Header Notification
SGSN <--> GGSN
Supported
G-PDU
SGSN <--> GGSN
Supported
5.2.24 Gr Interface
The Gr interface is used for the SGSN to retrieve authentication and subscription information from the
HLR. The Gr interface is the most important interface that is based on the MAP protocol. The protocol
stack is the same as other MAP based interfaces.


66
Interfaces
Figure 27. Protocol Stack for Gr interface

MAP
MAP
TCAP
TCAP
SCCP
SCCP
M3UA
M3UA
SCTP
SCTP
IP
IP
L2
L2
L1
L1
Gr
SGSN
HLR
The SGSN supports two versions of TS29.002 for all MAP based interfaces: V9.4.0 or V10.8.0. The
following table shows the Gr messages supported for each version.
Table 35.
Gr Messages
Message Type
Message Direction
V9.4.0/V10.8.0
MAP_UPDATE_GPRS_LOCATION request
SGSN --> HLR
Supported
MAP_UPDATE_GPRS_LOCATION response
SGSN <-- HLR
Supported
MAP_PURGE_MS request
SGSN --> HLR
Supported
MAP_PURGE_MS response
SGSN <-- HLR
Supported
MAP_CANCEL_LOCATION request
SGSN <-- HLR
Supported
MAP_CANCEL_LOCATION response
SGSN --> HLR
Supported
MAP_SEND_AUTHENTICATION_INFO request
SGSN --> HLR
Supported
MAP_SEND_AUTHENTICATION_INFO response
SGSN <-- HLR
Supported
MAP_AUTHENTICATION_FAILURE_REPORT request
SGSN --> HLR
Supported
10
MAP_AUTHENTICATION_FAILURE_REPORT response
SGSN <-- HLR
Supported
11
MAP-INSERT-SUBSCRIBER-DATA request
SGSN <-- HLR
Supported
12
MAP-INSERT-SUBSCRIBER-DATA response
SGSN --> HLR
Supported
13
MAP-DELETE-SUBSCRIBER-DATA request
SGSN <-- HLR
Supported


67
Interfaces
Message Type
Message Direction
V9.4.0/V10.8.0
14
MAP-DELETE-SUBSCRIBER-DATA response
SGSN --> HLR
Supported
15
MAP_RESET request
SGSN <-- HLR
Supported
16
MAP_RESET response
SGSN --> HLR
Supported
17
MAP-PROVIDE-SUBSCRIBER-INFO request
SGSN <-- HLR
Not supported
18
MAP-PROVIDE-SUBSCRIBER-INFO response
SGSN --> HLR
Not supported
19
MAP-ACTIVATE-TRACE-MODE request
SGSN <-- HLR
Not supported
20
MAP-ACTIVATE-TRACE-MODE response
SGSN --> HLR
Not supported
21
MAP-DEACTIVATE-TRACE-MODE request
SGSN <-- HLR
Not supported
22
MAP-DEACTIVATE-TRACE-MODE response
SGSN --> HLR
Not supported
23
MAP-SEND-ROUTING-INFO-FOR-LCS request
SGSN <-- HLR
Not supported
24
MAP-SEND-ROUTING-INFO-FOR-LCS response
SGSN --> HLR
Not supported
The lower layers of the Gr interface are the same as other MAP based interfaces. For the detail of the
message transport layers for the Gr interface, please refer to Gd Interface for information related to
the TCAP layer, the SCCP layer, the M3UA layer and the SCTP layer.
5.2.25 Gs Interface
The Gs interface connects the SGSN and the VLR/MSC to coordinate signaling for a combined
attached subscriber. It allows the UE to park at the packet domain while continuing to receive
signaling from the circuit domain. The main purpose for the interface is to allow delivery of CS paging
to the UE via the packet network.
The Gs interface uses SS7 based protocol suite. However, it does not use the MAP layer or the
TCAP layer. Instead, it uses connectionless SCCP layer to carry application layer protocol named
BSSAP (Base Station System Application Part). The protocol stack is shown in the following
illustration.


68
Interfaces
Figure 28. Protocol Stack for Gs interface
BSSAP
BSSAP
SCCP
SCCP
M3UA
M3UA
SCTP
SCTP
IP
IP
L2
L2
L1
L1
Gs
SGSN
VLR/MSC
The vMME supports connectivity to a max of 256 VLRs. For a combined MME/SGSN, the 64 VLRs
include the ones connected via SGs or Gs interface. A single VLR can have both SGs and Gs
interfaces (counted as one VLR).
The Gs interface is based on TS29.018; the SGSN is compliant to version V9.3.0, V10.7.0 or V11.7.0
based on the configuration. The following table shows the supported messages.
Table 36.
Gs Messages
Message Type
Message Direction
V9.3.0/V10.7.0/V11.7.0
BSSAP+-ALERT-ACK
SGSN --> VLR
Supported
BSSAP+-ALERT-REJECT
SGSN --> VLR
Supported
BSSAP+-ALERT-REQUEST
SGSN <-- VLR
Supported
BSSAP+-DOWNLINK-TUNNEL-REQUEST
SGSN <-- VLR
Not supported
BSSAP+-GPRS-DETACH-ACK
SGSN <-- VLR
Supported
BSSAP+-GPRS-DETACH-INDICATION
SGSN --> VLR
Supported
BSSAP+-IMSI-DETACH-ACK
SGSN <-- VLR
Supported
BSSAP+-IMSI-DETACH-INDICATION
SGSN --> VLR
Supported
BSSAP+-LOCATION-UPDATE-ACCEPT
SGSN <-- VLR
Supported
10
BSSAP+-LOCATION-UPDATE-REJECT
SGSN <-- VLR
Supported
11
BSSAP+-LOCATION-UPDATE-REQUEST
SGSN --> VLR
Supported
12
BSSAP+-MM-INFORMATION-REQUEST
SGSN <-- VLR
Supported


69
Interfaces
Message Type
Message Direction
V9.3.0/V10.7.0/V11.7.0
13
BSSAP+-MOBILE-STATUS
SGSN <--> VLR
Supported
14
BSSAP+-MS-ACTIVITY-INDICATION
SGSN --> VLR
Supported
15
BSSAP+-MS-INFORMATION-REQUEST
SGSN <-- VLR
Supported
16
BSSAP+-MS-INFORMATION-RESPONSE
SGSN --> VLR
Supported
17
BSSAP+-MS-UNREACHABLE
SGSN --> VLR
Supported
18
BSSAP+-PAGING-REJECT
SGSN --> VLR
Supported
19
BSSAP+-PAGING-REQUEST
SGSN <-- VLR
Supported
20
BSSAP+-RESET-ACK
SGSN <--> VLR
Supported
21
BSSAP+-RESET-INDICATION
SGSN <--> VLR
Supported
22
BSSAP+-TMSI-REALLOCATIONCOMPLETE
SGSN --> VLR
Supported
23
BSSAP+-UPLINK-TUNNEL-REQUEST
SGSN --> VLR
Not supported
The Gs interface uses SIGTRAN for the message routing and transport to the VLR. Please refer to
Gd Interface for the details on the SCCP layer, the M3UA layer and the SCTP layer used by the Gd
interface.
5.2.26 Iu Interface
The Iu interface connects the 3G access network, namely the UTRAN to the core network. The
interface includes both user bearer plane and user signaling plane. For the user bearer plane, there
are a few variations based on the capability of the RNC and the core network. The first variation is
that the bearer plane is anchored on the SGSN. The other variations are that the user bearer plane
by-passes the SGSN in the case of Direct Tunnel or S4-SGSN.
5.2.26.1 Iu Interface User Bearer

The following figures show the protocol stacks used for the Iu user bearer traffic. As can be seen from
the figures, only in the first case is the SGSN involved in the 3G user bearer.


70
Interfaces
Figure 29. Protocol Stack for Iu User Bearer Plane Anchored on the SGSN
Application
IP
IP
Relay
Relay
PDCP
PDCP
GTP-U
GTP-U
GTP-U
GTP-U
RLC
RLC
UDP/IP
UDP/IP
UDP/IP
UDP/IP
MAC
MAC
L2
L2
L2
L2
L1
L1
L1
L1
L1
L1
Uu
Gn
Iu-PS
MS
3G-SGSN
UTRAN
Gi
3G-GGSN
Figure 30. Protocol Stack for Iu User Bearer Plane Direct Tunnel
Application
IP
IP
Relay
PDCP
PDCP
GTP-U
GTP-U
RLC
RLC
UDP/IP
UDP/IP
MAC
MAC
L2
L2
L1
L1
L1
L1
Uu
MS
Gn
Iu-PS
3G-SGSN
UTRAN
Gi
3G-GGSN


71
Interfaces
Figure 31. Protocol Stack for Iu User Bearer Plane S4-SGSN case
Application
IP
IP
Relay
Relay
PDCP
PDCP
GTP-U
GTP-U
GTP-U
GTP-U
RLC
RLC
UDP/IP
UDP/IP
UDP/IP
UDP/IP
MAC
MAC
L2
L2
L2
L2
L1
L1
L1
L1
L1
L1
Uu
UE
S5/S8
S12
S-GW
UTRAN
SGi
P-GW
The protocol used by the SGSN to tunnel user bearer packet is called GTP-U. This is the same as
used for the Gn/Gp user bearer plane. Please refer to Gn/Gp Interface User Bearer Plane for more
details.
5.2.26.2 Iu Interface Signaling

The signaling plane for the Iu interface uses SIGTRAN based transport 7. The protocol stack is show
in the figure below. The RANAP layer is the application layer protocol used to carry UE related
signaling. The RANAP layer message is carried using connection oriented SCCP layer. There is a
logical connection for a signaling session for a UE. The M3UA/SCTP layers perform signaling routing
and transport for the upper layers.
3GPP also supports broadband SS7 transport using ATM. For the SGSN, such an option requires intermediate
signaling gateway to convert SIGTRAN to ATM based broadband SS7.


72
Interfaces
Figure 32. Protocol Stack for Iu Control Plane
RANAP
RANAP
SCCP
SCCP
M3UA
M3UA
SCTP
SCTP
IP
IP
L2
L2
L1
L1
Iu
RNC
SGSN
The RNCs can maintain direct M3UA/SCTP connection with the SGSN or connect indirectly using an
intermediate signaling gateway. The SGSN supports connectivity to up to 4096 RNCs. There can be
multiple SCTP links per RNC to enhance the network reliability. The maximum number of SCTP
associations that can be established is 8192. Furthermore, multi-home SCTP can be deployed to
enhance reliability within a link.
The SGSN allows the operator to configure the specification version of the Iu to be used. Two
versions of TS25.413 are supported: V9.5.0, V10.9.0 and V11.6.0. The following table show the
Table 37.
Iu Messages
Message Type
Message Direction
V9.5.0/V10.9.0/V11.6.0
RAB ASSIGNMENT REQUEST
SGSN --> RNC
Supported
RAB ASSIGNMENT RESPONSE
SGSN <-- RNC
Supported
RAB RELEASE REQUEST
SGSN <-- RNC
Supported
IU RELEASE REQUEST
SGSN <-- RNC
Supported
IU RELEASE COMMAND
SGSN --> RNC
Supported
IU RELEASE COMPLETE
SGSN <-- RNC
Supported
RELOCATION REQUIRED
SGSN <-- RNC
Supported
RELOCATION REQUEST
SGSN --> RNC
Supported
RELOCATION REQUEST ACKNOWLEDGE
SGSN <-- RNC
Supported


73
Interfaces
Message Type
Message Direction
V9.5.0/V10.9.0/V11.6.0
10
RELOCATION COMMAND
SGSN --> RNC
Supported
11
RELOCATION DETECT
SGSN <-- RNC
Supported
12
RELOCATION COMPLETE
SGSN <-- RNC
Supported
13
RELOCATION PREPARATION FAILURE
SGSN --> RNC
Supported
14
RELOCATION FAILURE
SGSN <-- RNC
Supported
15
RELOCATION CANCEL
SGSN <-- RNC
Supported
16
RELOCATION CANCEL ACKNOWLEDGE
SGSN --> RNC
Supported
17
SRNS CONTEXT REQUEST
SGSN --> RNC
Not supported
18
SRNS CONTEXT RESPONSE
SGSN <-- RNC
Not supported
19
SRNS DATA FORWARD COMMAND
SGSN --> RNC
Not supported
20
FORWARD SRNS CONTEXT
SGSN <--> RNC
Supported
21
PAGING
SGSN --> RNC
Supported
22
COMMON ID
SGSN --> RNC
Supported
23
CN INVOKE TRACE
SGSN --> RNC
Not supported
24
SECURITY MODE COMMAND
SGSN --> RNC
Supported
25
SECURITY MODE COMPLETE
SGSN <-- RNC
Supported
26
SECURITY MODE REJECT
SGSN <-- RNC
Supported
27
LOCATION REPORTING CONTROL
SGSN --> RNC
Not supported
28
LOCATION REPORT
SGSN <-- RNC
Not supported
29
DATA VOLUME REPORT REQUEST
SGSN --> RNC
Not supported
30
DATA VOLUME REPORT
SGSN <-- RNC
Not supported
31
INITIAL UE MESSAGE
SGSN --> RNC
Supported
32
DIRECT TRANSFER
SGSN <--> RNC
Supported
33
CN INFORMATION BROADCAST REQUEST
Deprecated
NA
34
CN INFORMATION BROADCAST CONFIRM
Deprecated
NA
35
CN INFORMATION BROADCAST REJECT
Deprecated
NA
36
OVERLOAD
SGSN <--> RNC
Not supported
37
RESET
SGSN <--> RNC
Supported
38
RESET ACKNOWLEDGE
SGSN <--> RNC
Supported
39
ERROR INDICATION
SGSN <--> RNC
Supported
40
CN DEACTIVATE TRACE
SGSN --> RNC
Not supported
41
RANAP RELOCATION INFORMATION
RNC <--> RNC
NA
42
RESET RESOURCE
SGSN <--> RNC
Supported
43
RESET RESOURCE ACKNOWLEDGE
SGSN <--> RNC
Supported
44
RAB MODIFY REQUEST
SGSN <-- RNC
Not supported


74
Interfaces
Message Type
Message Direction
V9.5.0/V10.9.0/V11.6.0
45
LOCATION RELATED DATA REQUEST
SGSN --> RNC
Not supported
46
LOCATION RELATED DATA RESPONSE
SGSN <-- RNC
Not supported
47
LOCATION RELATED DATA FAILURE
SGSN <-- RNC
Not supported
48
INFORMATION TRANSFER INDICATION
SGSN --> RNC
Not supported
49
INFORMATION TRANSFER CONFIRMATION
SGSN <-- RNC
Not supported
50
INFORMATION TRANSFER FAILURE
SGSN <-- RNC
Not supported
51
UE SPECIFIC INFORMATION INDICATION
SGSN --> RNC
Not supported
52
DIRECT INFORMATION TRANSFER
SGSN <--> RNC
Supported
53
UPLINK INFORMATION EXCHANGE

REQUEST
SGSN <-- RNC
Not supported
54

RESPONSE
SGSN --> RNC
Not supported
55

FAILURE
SGSN --> RNC
Not supported
56
MBMS SESSION START
SGSN --> RNC
Not supported
57
MBMS SESSION START RESPONSE
SGSN <-- RNC
Not supported
58
MBMS SESSION START FAILURE
SGSN <-- RNC
Not supported
59
MBMS SESSION UPDATE
SGSN --> RNC
Not supported
60
MBMS SESSION UPDATE RESPONSE
SGSN <-- RNC
Not supported
61
MBMS SESSION UPDATE FAILURE
SGSN <-- RNC
Not supported
62
MBMS SESSION STOP
SGSN --> RNC
Not supported
63
MBMS SESSION STOP RESPONSE
SGSN <-- RNC
Not supported
64
MBMS UE LINKING REQUEST
SGSN <-- RNC
Not supported
65
MBMS UE LINKING RESPONSE
SGSN <-- RNC
Not supported
66
MBMS REGISTRATION REQUEST
SGSN <-- RNC
Not supported
67
MBMS REGISTRATION RESPONSE
SGSN --> RNC
Not supported
68
MBMS REGISTRATION FAILURE
SGSN --> RNC
Not supported
69
MBMS CN DE-REGISTRATION REQUEST
SGSN --> RNC
Not supported
70
MBMS CN DE-REGISTRATION RESPONSE
SGSN <-- RNC
Not supported
71
MBMS RAB ESTABLISHMENT INDICATION
SGSN --> RNC
Not supported
72
MBMS RAB RELEASE REQUEST
SGSN --> RNC
Not supported
73
MBMS RAB RELEASE
SGSN --> RNC
Not supported
74
MBMS RAB RELEASE FAILURE
SGSN --> RNC
Not supported
75
ENHANCED RELOCATION COMPLETE

REQUEST
SGSN <-- RNC
Supported
76

RESPONSE
SGSN --> RNC
Supported


75
Interfaces
Message Type
Message Direction
V9.5.0/V10.9.0/V11.6.0
77

FAILURE
SGSN --> RNC
Supported
78

CONFIRM
SGSN --> RNC
Supported
79
RANAP ENHANCED RELOCATION

INFORMATION REQUEST
RNC <--> RNC
NA
80
RANAP ENHANCED RELOCATION

INFORMATION RESPONSE
RNC <--> RNC
NA
81
SRVCC CS KEYS REQUEST
SGSN <-- RNC
Not supported
82
SRVCC CS KEYS RESPONSE
SGSN --> RNC
Not supported
The RANAP messages for the Iu interface use the SCCP layer, M3UA layer for transport over the
SCTP associations. The following tables show the SCCP layer and M3UA layer messages supported.
The versions used align to the RANAP specification version.
Table 38.
SCCP Layer Messages
Message Type
Message Direction
V9.5.0/V10.9.0
Connection Confirm (CC)
SGSN <--> SCCP peer
Supported
Connection Request (CR)
SGSN <--> SCCP peer
Supported
Connection Refused (CREF)
SGSN <--> SCCP peer
Supported
Data Acknowledgement (AK)
SGSN <--> SCCP peer
Not supported
Data Form 1 (DT1)
SGSN <--> SCCP peer
Supported
Data Form 2 (DT2)
SGSN <--> SCCP peer
Not supported
Expedited Data (ED)
SGSN <--> SCCP peer
Not supported
Expedited Data Acknowledgement (EA)
SGSN <--> SCCP peer
Not supported
Inactivity Test (IT)
SGSN <--> SCCP peer
Supported
10
Protocol Data Unit Error (ERR)
SGSN <--> SCCP peer
Supported
11
Released (RLSD)
SGSN <--> SCCP peer
Supported
12
Release Complete (RLC)
SGSN <--> SCCP peer
Supported
13
Reset Confirm (RSC)
SGSN <--> SCCP peer
Not supported
14
Reset Request (RSR)
SGSN <--> SCCP peer
Not supported
15
Subsystem-allowed (SSA)
SGSN <--> SCCP peer
Supported
16
Subsystem-out-of-service-grant (SOG)
SGSN <--> SCCP peer
Not supported
17
Subsystem-out-of-service-request (SOR)
SGSN <--> SCCP peer
Not supported
18
Subsystem-prohibited (SSP)
SGSN <--> SCCP peer
Supported
19
Subsystem-status-test (SST)
SGSN <--> SCCP peer
Supported


76
Interfaces
Message Type
Message Direction
V9.5.0/V10.9.0
20
Unitdata (UDT)
SGSN <--> SCCP peer
Supported
21
Unitdata Service (UDTS)
SGSN <--> SCCP peer
Supported
22
Extended Unitdata (XUDT)
SGSN <--> SCCP peer
Supported
23
Extended Unitdata Service (XUDTS)
SGSN <--> SCCP peer
Supported
24
Subsystem Congested (SSC)
SGSN <--> SCCP peer
Not supported
25
Long Unitdata (LUDT)
SGSN <--> SCCP peer
Supported
26
Long Unitdata Service (LUDTS)
SGSN <--> SCCP peer
Supported
Table 39.
M3UA Layer Messages
Message Type
Message Direction
V9.5.0/V10.9.0
Payload Data Message (DATA)
SGSN <--> M3UA peer
Supported
Destination Unavailable (DUNA)
Supported
Destination Available (DAVA)
Supported
Destination State Audit (DAUD)
SGSN --> M3UA peer (SG)
Supported
Signaling Congestion (SCON)
SGSN <--> M3UA peer
Receive only
Destination User Part Unavailable (DUPU)
Supported
Destination Restricted (DRST)
Supported
ASP Up
SGSN <--> M3UA peer
Supported
ASP Up Acknowledgement (ASP Up Ack)
SGSN <--> M3UA peer
Supported
10
ASP Down
SGSN <--> M3UA peer
Supported
11
ASP Down Acknowledgement (ASP Down Ack)
SGSN <--> M3UA peer
Supported
12
Heartbeat (BEAT)
SGSN <--> M3UA peer
Supported
13
Heartbeat Acknowledgement (BEAT Ack)
SGSN <--> M3UA peer
Supported
14
Registration Request (REG REQ)
SGSN <--> M3UA peer
Not supported
15
Registration Response (REG RSP)
SGSN <--> M3UA peer
Not supported
16
Deregistration Request (DEREG REQ)
SGSN <--> M3UA peer
Not supported
17
Deregistration Response (DEREG RSP)
SGSN <--> M3UA peer
Not supported
18
ASP Active
SGSN <--> M3UA peer
Supported
19
ASP Active Acknowledgement (ASP Active Ack)
SGSN <--> M3UA peer
Supported
20
ASP Inactive
SGSN <--> M3UA peer
Supported
21
ASP Inactive Acknowledgement (ASP Inactive

Ack)
SGSN <--> M3UA peer
Supported
22
Error
SGSN <--> M3UA peer
Supported
23
Notify
SGSN <--> M3UA peer
Supported


77
Interfaces
At the SCTP layer, the SGSN supports SCTP multi-home. Up to two IP addresses can be configured
for each M3UA peer. The number of local IP addresses desired can be engineered based on the Iu
signaling volume required for a network. In the maximum case the number of IP addresses used is 40
(two IP addresses for multi-home for a maximum of 20 end points). Only IPv4 is allowed for the Iu
interface.
5.2.27 M3 Interface
The M3 interface is used between the MME and MCE for MBMS Bearer service activation.
5.2.28 NAS
The Non-Access Stratum (NAS) is the protocol used between the UE and the MME/SGSN. The
signaling is relayed from the access nodes to the MME/SGSN.
For the MME, the NAS layer is composed of the EMM layer and the ESM layer. For the SGSN, the
NAS layer is composed of the GMM layer and the SM layer. The following two sub-sections discuss
the NAS capability of the vMME.
5.2.28.1 NAS layer for the MME

The Non Access Stratum (NAS) messages from the UE are transported using the S1-AP messages
passing through the S1- MME interface. To enhance the efficiency, NAS layer allows piggybacking of
NAS layer messages within an S1 layer message. The following figure shows the protocol stack for
the NAS layer for the MME.
Figure 33. Protocol Stack for Control Plane for UE - MME


78
Interfaces
NAS
NAS
Relay
RRC
RRC
S1-AP
S1-AP
PDCP
PDCP
SCTP
SCTP
RLC
RLC
IP
IP
MAC
MAC
L2
L2
L1
L1
L1
L1
LTE-Uu
UE
S1-MME
MME
eNodeB
The MME allows the operator to configure the highest specification version supported for the NAS
layer. Two versions of TS24.301 are supported for the MME: V9.5.0, V10.10.0 and V11.13.0. The
messages for the EMM layer and ESM layer are detailed in the following two tables.
Table 40.
#
NAS Evolved Mobility Management Messages
Message Type
Message Direction
V9.5.0/V10.10.0/
V11.13.0
Attach Request
UE -> MME
Supported
Attach Accept
UE <- MME
Supported
Attach Complete
UE -> MME
Supported
Attach Reject
UE <- MME
Supported
Authentication Request
UE <- MME
Supported
Authentication Response
UE -> MME
Supported
Authentication Failure
UE -> MME
Supported
Authentication Reject
UE <- MME
Supported
CS Service Notification
UE <- MME
Supported
10
Detach Request
UE <-> MME
Supported
11
Detach Accept
UE <-> MME
Supported
12
Downlink NAS Transport
UE <- MME
Supported
13
EMM Information
UE <- MME
Supported
14
EMM Status
UE <-> MME
From UE only
15
Extended Service Request
UE -> MME
Supported
16
GUTI Reallocation Command
UE <- MME
Supported
17
GUTI Reallocation Complete
UE -> MME
Supported
18
Identity Request
UE <- MME
Supported
19
Identity Response
UE -> MME
Supported


79
Interfaces
Message Type
Message Direction
V9.5.0/V10.10.0/
V11.13.0
20
Security Mode Command
UE <- MME
Supported
21
Security Mode Complete
UE -> MME
Supported
22
Security Mode Reject
UE -> MME
Supported
23
Security Protected NAS Message
UE <-> MME
Supported
24
Service Request
UE -> MME
Supported
25
Service Reject
UE <- MME
Supported
26
Tracking Area Update Request
UE -> MME
Supported
27
Tracking Area Update Accept
UE <- MME
Supported
28
Tracking Area Update Complete
UE -> MME
Supported
39
Tracking Area Update Reject
UE <- MME
Supported
30
Uplink NAS Transport
UE -> MME
Supported
31
Downlink Generic NAS Transport
UE <-- MME
Supported
32
Uplink Generic NAS Transport
UE --> MME
Supported
Table 41.
Evolved Session Management messages
Message Type
Message Direction
V9.5.0/V10.10.0
Activate Dedicated EPS Bearer Context Request
UE<-MME
Supported
Activate Dedicated EPS Bearer Context Accept
UE -> MME
Supported
Activate Dedicated EPS Bearer Context Reject
UE -> MME
Supported
Activate Default EPS Bearer Context Request
UE <- MME
Supported
Activate Default EPS Bearer Context Accept
UE -> MME
Supported
Activate Default EPS Bearer Context Reject
UE -> MME
Supported
Bearer resource allocation request
UE -> MME
Supported
Bearer resource allocation reject
UE <- MME
Supported
Bearer Resource Modification Request
UE -> MME
Supported
10
Bearer Resource Modification Reject
MME->UE
Supported
11
Deactivate EPS Bearer Context Request
UE <- MME
Supported
12
Deactivate EPS Bearer Context Accept
UE -> MME
Supported
13
ESM Information Request
UE <- MME
Supported
14
ESM Information Response
UE -> MME
Supported
15
ESM status
UE <-> MME
Supported
16
Modify EPS Bearer Context Request
UE <- MME
Supported
17
Modify EPS Bearer Context Accept
UE -> MME
Supported
18
Modify EPS Bearer Context Reject
UE -> MME
Supported


80
Interfaces
Message Type
Message Direction
V9.5.0/V10.10.0
19
PDN Connectivity Request
UE -> MME
Supported
20
PDN Connectivity Reject
UE <- MME
Supported
21
PDN Disconnect Request
UE -> MME
Supported
22
PDN Disconnect Reject
UE <- MME
Supported
23
Notification
UE <- MME
Supported
5.2.28.2 NAS layer for the SGSN

The Non Access Stratum (NAS) messages from the UE are transported using the Gb or Iu interfaces
depending on the technology used. The following figures show the protocol stacks for the NAS layer
for the SGSN.


81
Interfaces
Figure 34. Protocol Stack for Control Plane MS SGSN in A/Gb Mode
NAS
NAS
LLC
LLC
Relay
RLC
RLC
BSSGP
BSSGP
MAC
MAC
Network
Service
Network
Service
GSM-RF
GSM-RF
L1bis
L1bis
Um
Gb
MS
SGSN
BSS
Figure 35. Protocol Stack for Control Plane MS SGSN in Iu Mode
NAS
NAS
Relay
RANAP
RANAP
RRC
RRC
SCCP
SCCP
RLC
RLC
Signalling
Bearer
Signalling
Bearer
MAC
MAC
L2
L2
L1
L1
L1
L1
MS
SGSN
RNC
Iu-PS
Uu
Similarly to the MME, the SGSN allows the operator to select the highest 3GPP version supported on
the SGSN. Two versions of TS 24.008 are supported for the SGSN: V9.5.0, V10.10.0 and V11.13.0.
The following tables show the GMM and SM messages supported for each version.


82
Interfaces
Table 42.
NAS GPRS Mobility Management Messages
Message Type
Message Direction
V9.5.0/V10.10.0/
V11.13.0
Attach Request
UE -> SGSN
Supported
Attach Accept
UE <- SGSN
Supported
Attach Complete
UE -> SGSN
Supported
Attach Reject
UE <- SGSN
Supported
Authentication Request
UE <- SGSN
Supported
Authentication Response
UE -> SGSN
Supported
Authentication Failure
UE -> SGSN
Supported
Authentication Reject
UE <- SGSN
Supported
Detach Request
UE <-> SGSN
Supported
10
Detach Accept
UE <-> SGSN
Supported
11
GMM Information
UE <- SGSN
Supported
12
GMM Status
UE <-> SGSN
Supported
13
P-TMSI Reallocation Command
UE <- SGSN
Supported
14
P-TMSI Reallocation Complete
UE -> SGSN
Supported
15
Identity Request
UE <- SGSN
Supported
16
Identity Response
UE -> SGSN
Supported
17
Service Request (3G only)
UE -> SGSN
Supported
18
Service Accept (3G only)
UE <- SGSN
Supported
19
Service Reject (3G only)
UE <- SGSN
Supported
20
Routing Area Update Request
UE -> SGSN
Supported
21
Routing Area Update Accept
UE <- SGSN
Supported
22
Routing Area Update Complete
UE -> SGSN
Supported
23
Routing Area Update Reject
UE <- SGSN
Supported
Table 43.
Session Management messages
Message Type
Message Direction
V9.5.0/V10.10.0
Activate PDP context request
UE -> SGSN
Supported
Activate PDP context accept
UE <- SGSN
Supported
Activate PDP context reject
UE <- SGSN
Supported
Activate Secondary PDP Context Request
UE -> SGSN
Not Supported
Activate Secondary PDP Context Accept
UE <- SGSN
Not Supported
Activate Secondary PDP Context Reject
UE <- SGSN
Not Supported


83
Interfaces
Message Type
Message Direction
V9.5.0/V10.10.0
Request PDP context activation
UE <- SGSN
Not supported
Request PDP context activation reject
UE -> SGSN
Not supported
Modify PDP context request (Network to MS direction)
UE <- SGSN
Supported
10
Modify PDP context request (MS to network direction)
UE -> SGSN
Supported
11
Modify PDP context accept (MS to network direction)
UE -> SGSN
Supported
12
Modify PDP context accept (Network to MS direction)
UE <- SGSN
Supported
13
Modify PDP Context Reject
UE <-> SGSN
Supported
14
Deactivate PDP context request
UE -> SGSN
Supported
15
Deactivate PDP context accept
UE <- SGSN
Supported
16
Request Secondary PDP Context Activation
UE <- SGSN
Not Supported
17
Request Secondary PDP Context Activation Reject
UE -> SGSN
Not Supported
5.2.29 X Legal Intercept Interface

The interface between the vMME and the Legal Intercept Gateway is used to provide the law
enforcement agencies the ability to track the activity of a target UE. The vMME supports two different
protocols for the X interface. The protocol stack for the first protocol is depicted as follows.
Figure 36. Protocol Stack for X interface between the MME and the LIG
LICP
LICP
TCP
TCP
IPSec*
IPSec*
IP
IP
L2
L2
L1
L1
X
MME
LIG
*IPSec is optional
The protocol is proprietary as it is defined by Hitachi. Three different versions are supported. The
current version is v10.4.0 which delivers all the required fields as specified in TS33.106, and

84
Interfaces
TS33.107 V10.4.0. V7 should be used to be backwards compatible with R7 compliant LIGs that have
not been updated to V10.4.0. V9 should be used for LIG compatible with R9. The following messages
are defined and supported.
Table 44.
X Interface Messages
Message Type
Message Direction
V7/V9/V10.4.0
Target Activation Request
LIG->MME/SGSN
Supported
Target Activation Response
MME/SGSN->LIG
Supported
Target Deactivation Request
LIG->MME/SGSN
Supported
Target Deactivation Response
MME/SGSN->LIG
Supported
Target Interrogation Request
LIG->MME/SGSN
Supported
Target Interrogation Response
MME/SGSN->LIG
Supported
Reset Request
LIG->MME/SGSN
Supported
Reset Notification
MME/SGSN->LIG
Supported
SC Reset Notification
MME/SGSN->LIG
Supported
10
IRI Delivery
MME/SGSN->LIG
Supported
11
CC Delivery
SGSN-> LIG
Supported
The vMME is responsible to establish TCP connections with the LIG. There are two types of TCP
connections. One is to the ADMF. This connection is setup as long as the IP address of the ADMF is
configured. The other is to the DF. The connection to the DF is setup once the address is received
from the LIG (as a target is activated). Configuration of the X interface requires an operator that has
the proper LI user privilege for security reasons.
For the legal intercept interface, either IPv4 or IPv6 can be used.
The second protocol utilizes the 3GPP defined HI2 interface for the X2 interface. The X1 interface
uses the ssh based OAM interface for target management. Only authorized LI user can manage the
target setting. The X2 interface uses the same protocol as HI2. The protocol stack is shown in the
following illustration. The specification used is 33.108 v12.6.0. In this release only MME IRI can be
reported using HI2 based protocol. Thus, for a combined MME/SGSN, it is recommended to use LICP
based protocol.


85
Interfaces
Figure 37. Protocol Stack for HI2

IRI
ASN.1
TPKT
TCP
IP
5.2.30 Domain Name Service

The vMME supports both locally configured domain name to IP address mapping or use an external
domain name server. For the MME function or SGSN function with the S4 interface enabled, the DNS
procedure defined in TS29.303 is used. The formation of the FQDN is based on the definitions in
TS23.003. If the node is deployed as a legacy Gn SGSN, then the traditional DNS procedure based
on RFC1035 is used.
Figure 38. Protocol Stack for Domain Name Service interface
DNS
DNS
UDP
UDP
IP
IP
MME/SGSN
or
DNS
DNS
TCP
TCP
IP
IP
MME/SGSN
DNS Server
DNS Server
The MME/SGSN can send DNS queries to up to eight DNS servers. The usage of the DNS servers is
based on configured weight for each server. The MME/SGSN supports the query of the following
record types:
A: Domain name to IPv4 records
AAAA: Domain name to IPv6 records
SRV: Domain name to SRV records
NAPTR: Domain name to NAPTR records


86
Interfaces
When multiple records are returned from the DNS server, the MME/SGSN selects the records based
on the weight/preference for the SRV and NAPTR records. For A/AAAA records, a simple round-robin
method is used to rotate between the records.
The vMME supports RFC2671 for UDP based queries that are larger than 512 bytes. If the DNS
server cannot provide all the query results due to limitation in UDP capability in the DNS server, the
vMME switches to TCP to re-attempt the query. The largest message supported is 65535 bytes.


87
6 Features and Services

6.1 Combined MME/SGSN Node
The combined MME/SGSN combines the 2G, 3G and 4G access technologies on the same core
network node. On top of enabling the node to be deployed in a wider variety of wireless packet
networks, it also brings network level efficiency by reducing the number of inter-nodal messages
required to support the inter-RAT (Radio Access Technology) mobility events when the UE moves
between access technologies. The following figure shows the logical interfaces supported by the
combined MME/SGSN in a wireless network.


88
Features and Services
Figure 39. Combined MME/SGSN in a wireless network with 2G/3G/4G access technologies
S4-SGSN
Gn-SGSN
S3/S16
MME
Gn/Gp
LIG
S10/S3
CGF
Ga
VLR
SGs/Gs
GERAN
Gb
Um
SMS
Gd (2G only)
Uu
UE
MME/SGSN
lu-PS
S13/Gf
UTRAN
EIR
-M
S1
Gr
LTE-Uu
HLR
Gn/Gp
EUTRAN
direct
tunnel
S6
HSS
S4/S11
SBc
S1-U
GGSN
CBC
S12
S5/S8
Serving Gateway
PDN Gateway
In addition to the logical interfaces shown in the preceding figure, the combined MME/SGSN also
supports interfaces for CDMA based access technologies: S101 and S102. These interfaces are not
shown in the figure above. Nevertheless, if such a use case arises, the combined MME/SGSN is fully
capable of supporting such a deployment.


89
With the combined MME/SGSN, the vMME provides unparalleled deployment flexibility. The follow list
samples some of the configurations that can be deployed (many more are possible depending on
operator needs):
A standalone MME. The ability to use the node as a standalone MME is maintained. The
standalone MME can be deployed with S101/S102 interfaces for operators adding LTE
technology to an existing CDMA based network. The standalone MME can be deployed with S3,
Gn/Gp (for mobility management) for operators adding LTE technology to an existing G/U based
network. The standalone MME can be deployed without interfaces to legacy technologies for
operators building up a purely 4G E-UTRAN network.
A standalone 2G/3G Gn-SGSN. The ability to use the node as a standalone SGSN is maintained.
The SGSN can have either 2G Access or 3G Access or both.
A standalone 2G/3G S4-SGSN. The node can be configured as a standalone S4-SGSN. The
SGSN can have either 2G Access or 3G Access or both. In this configuration, the S4-SGSN
interacts with the SGW to manage subscriber PDP contexts.
A combined MME/SGSN that supports 2G/3G/4G access technologies. The combined

MME/SGSN requires that the SGSN function on the combined node to be an S4-SGSN. In order
to serve a UE that can move between the 2G/3G and 4G access technologies, the SGSN must
use the EPS interfaces: S4, S3, S11 and S6d. A roaming UE from a partner network that uses
legacy interfaces can still obtain service from the SGSN function; however, the UE will not be
able to move to the MME function of the combined node.
A combined MME/SGSN that supports 3G and 4G only with EPC cores. In this configuration, the
combined MME/SGSN only needs to have control plane capability whereas the data plane is
completely handled by the S-GW and P-GW. This effectively brings 4G like network architecture
to the 3G access as well.
On the combined MME/SGSN node, the total subscriber capacity is independent of the access
technology of the users. The combined node allows complete swing from one access technology to
another without requiring hardware or software change on the node.
6.2 Mobility Management

The Mobility Management (MM) layer is key part of the MME and SGSN function. It is responsible for
the following functions:
controlling network access such as mobile attaching and detaching
performing security functions to guard against unauthorized access to the network and to provide
data confidentiality
controlling the routing path of an established network connection in order to support user mobility
storing mobility context information for all mobiles served on the node


90
handling all mobility functions for users, including paging
enabling or disabling of encryption across the air interface
One of the strengths of the vMME is that it supports a wide array of mobility scenarios. After the UE is
attached on the core network (MME or SGSN), there are two types of mobility events possible: one is
performed while the UE is in an active state (ECM-connected for 4G, PMM-connected for 3G or ready
state for 2G), the other one is performed while the UE is in idle state (ECM-idle for 4G, PMM-idle for
3G and standby state for 2G).
The following table summarizes the mobility scenarios supported by the vMME.
Table 45.
Mobility Scenarios Supported
Scenario
RAT involved
UE State
Additional variations
Intra-MME X2 handover
Intra-LTE
Active
SGW relocation required

SGW relocation not required
Direct forwarding
Indirect forwarding
TAU list change
Intra-MME S1 handover
Intra-LTE
Active

Direct forwarding
Indirect forwarding
TAU list change
Intra-MME TAU
Intra-LTE
Idle

Inter-MME S1 handover
Intra-LTE
Active

Direct forwarding
Indirect forwarding
Inter-MME TAU
Intra-LTE
Idle

Intra-node 4G to 3G intersystem handover
LTE->UMTS
Active

Direct forwarding
Indirect forwarding
Intra-node 4G to 3G intersystem change
LTE->UMTS
Idle


91
Scenario
RAT involved
UE State
Intra-node 4G to 2G intersystem change
LTE->GERAN
Inter-node 4G to 3G intersystem handover
LTE->UMTS
Active or Idle

SGW relocation not required.
Active

Direct forwarding
Indirect forwarding
Gn/Gp interface
S3 interface
Inter-node 4G to 3G intersystem change
LTE->UMTS
Idle

Gn/Gp interface
S3 interface
Inter-node 4G to 2G intersystem change
LTE->GERAN
Idle

Gn/Gp interface
S3 interface
Inter-RAT 4G to CDMA HRPD

handover
LTE->HRPD
Active
Inter-RAT 4G to CDMA HRPD

un-optimized
LTE->HRPD
Idle
Inter-RAT 4G to WiMax unoptimized
LTE->WiMax
Active or Idle
Inter-RAT 4G to 1xRTT CSFB
LTE->1xRTT
Active or Idle
Active handover to HRPD at the

same time
No active handover to HRPD at the
same time
Inter-RAT 4G to 3G CSFB
LTE->UMTS
circuit
Active or Idle
Handover to 3G Packet domain at

the same time
No active handover to 3G packet
domain at the same time
3G Packet Domain on the same
node as the MME
3G Packet Domain on a different
node
A Routing Area Update procedure is used regardless whether the UE is active or idle.


92
Scenario
RAT involved
UE State
Inter-RAT 4G to 2G CSFB
LTE->GSM
circuit
Active or Idle
RAU to Packet domain at the same

time
2G Packet Domain on the same
node as the MME
2G Packet Domain on a different
node
Inter-RAT 4G to 2G CS
LTE -> 2G CS
Active
DTM supported
DTM not supported
Inter-RAT 4G to 3G CS
LTE -> 3G CS
Active
With PS handover
Without PS handover
Intra-node 3G to 3G handover
(SRNS)
Intra- UMTS
Active
RAI change
No RAI change
UE uses S4-SGSN for session
management
UE uses Gn-SGSN for session
management
SGW relocation required (S4-SGSN)
SGW relocation not required (S4SGSN)
Intra-node 3G to 3G RAU
Intra- UMTS
Idle

management
management
Inter-node 3G to 3G handover
(SRNS)
Intra-UMTS
Active
Gn/Gp interface
S16 interface
Inter-node 3G to 3G RAU
Intra-UMTS
Idle
Gn/Gp interface
S16 interface
Intra-node 3G to 4G handover
UMTS->LTE
Active

Intra-node 3G to 4G TAU
UMTS->LTE
Idle



93
Scenario
RAT involved
UE State
Inter-node 3G to 4G handover
UMTS->LTE
Active
Gn/Gp interface
S3 interface
Inter-node 3G to 4G TAU
UMTS->LTE
Idle
Gn/Gp interface
S3 interface
UMTS->GERAN
Active or Idle

management
management
UMTS->LTE
Active or Idle
SGW Relocation Required

SGW Relocation not required
Gn/Gp interface
S3 interface
Intra-GERAN
Active or Idle

management
management
Intra-GERAN
Active or Idle
S16 interface
Gn/Gp interface
GERAN->UMTS
Active or Idle

management
management
GERAN->UMTS
Active or Idle
S16 interface
Gn/Gp interface


94
Scenario
RAT involved
UE State
Intra-node 2G to 4G TAU
GERAN->LTE
Active or Idle

Inter-node 2G to 4G TAU
GERAN->LTE
Active or Idle
S3 interface
Gn/Gp interface
6.3 eMBMS
This feature implements the Multimedia Broadcast and Multicast Service (MBMS) specified in TS
23.246 on the MME. MBMS is a point-to-multipoint service which data is transmitted from a single
source entity to multiple recipients. Multiple subscribers can receive the same data at the same time
on the same frequency.
The MBMS bearer service offers two modes: 1) Broadcast and 2) Multicast.
Broadcast Mode is supported for EPS and GPRS. Multicast Mode is supported for GPRS. MBMS for
EPS supports E-UTRAN and UTRAN. MBMS for GPRS supports UTRAN and GERAN.
The principal differences between Multicast and Broadcast modes are show in the following table.
Table 46.
Mulitcast vs Broadcast Modes
Multicast Mode
Broadcast Mode
User Authentication against subscription before

MBMS service access
No subscription in database
User indicates joining and leaving for charging

purposes
Charging based on service key stored in USIM
MBMS may be used to realize some of the following applications:
Audio and/or video streaming (TV reception, weather report, ..)
Audio and/or video downloading for off-line use (download newspaper overnight, read in the
morning)
File downloading (useful for software upgrade for sample)
Images and text distribution


95
6.3.1 Multi-cell/multicast Coordination Entity (MCE)

The MCE is a logical entity whose function are:
Admission control and the allocation of the radio resources used by all eNBs in the MBSFN area
for multi-cell MBMS transmissions using MBSFN operation. The MCE decides not to establish the
radio bearer(s) of the new MBMS service(s) if the radio resources are not sufficient for the
corresponding MBMS service(s) or may pre-empt radio resources from other radio bearer(s) of
ongoing MBMS service(s) according to ARP. Besides allocation of the time/ frequency radio
resources this also includes deciding the further details of the radio configuration e.g. the
modulation and coding scheme.
Counting and acquisition of counting results for MBMS service(s).
Resumption of MBMS session(s) within MBSFN area(s) based on for example, the ARP and/or
the counting results for the corresponding MBMS service(s).
Suspension of MBMS session(s) within MBSFN area(s) based on for example, the ARP and/or on
the counting results for the corresponding MBMS service(s).
The MCE is also responsible for coordinating MBMS Session Control Signaling in the E-UTRAN.
The MCE may be deployed as a standalone entity or collocated with the eNodeB. Each is illustrated
in the following figures.


96
Figure 40. Centralized MCE


97
Figure 41. Distributed MCE
SGi to P-GW for unicast

Contents
Provider
P-GW
BM-SC
S5
SGmb
S11
S-GW
MBMS GW
Sm
MBMS
MBMS
CP
CP
MME
S1-MME
M3
S1-MME
MCE
SGImb
MBMS
MBMS
UP
UP
M1
Multicast Router
M3
MCE
MCE
MBMS Service
Area
MBMS Service
Area
6.4 Customizable Cause Code Mapping

This feature allows the operator to configure the causes used in mobility management related reject
messages (such as Attach Reject, RAU or TAU Reject). The feature can be used for customized UE
response beyond the definition of the 3GPP specification. A GMM or EMM cause code can be
configured to be used for a particular failure condition. One example use of this feature is to avoid
using the new cause codes introduced by 3GPP specifications such that older mobiles in the field can
handle an error condition properly.
The capability is supported both in SGSN GMM layer as well as MME EMM layer.


98
6.5 Session Management

Session Management (SM) is another key part of the MME/SGSN function. It is responsible for the
following functions:
Primary PDP Context Activation (SGSN) or PDN Connectivity Activation (MME). This includes the
capability to perform APN selection to determine the proper APN to use for a request from the
UE, the SGW/PGW and GGSN selection.
PDP Context or PDN Connectivity deactivation.
PDP context or bearer modification.
In addition to the above capabilities, the vMME also supports the following features for session
management:
Packet Flow Context: This feature enables improved quality of service control for the subscribers
on 2G GERAN. It allows the UE, the BSS and the SGSN to have a consistent way of managing
the QoS similar to the radio bearer function common to the 3G and 4G network.
Direct Tunnel support: The SGSN supports set up and tear down of the direct tunnel for 3G user
bearer traffic between the RNC and the GGSN. Please refer to Direct Tunnel.
Dual stack support: The vMME supports activation of a dual stack PDN Connection or PDP
context. This allows the UE to have both IPv4 and IPv6 address at the same time.
QoS management: The vMME performs QoS negotiation during session management
procedures. Further, the QoS can be controlled via the local policy configuration for different
subscribers. Please refer to Location based QoS management for more details.
6.6 UE Security Management

UE security is one of the main functions for the wireless network. As required by the 3GPP
specifications, the MME/SGSN needs to provide security functions to support the following:
Guards against unauthorized EPS service usage (authentication of the UE by the network and
service request validation).
Provision of user identity confidentiality (temporary identification and ciphering).
Provision of user data and signalling confidentiality (ciphering).
Provision of origin authentication of signalling data (integrity protection).
Authentication of the network by the UE (this is applicable to USIM based users).
The vMME excels in delivering the above capability. This section discusses the UE security
management capability of the MME as well as the SGSN.


99
In the case of the MME, the following security capabilities are provided:
Authentication Using EPS Vectors (Quartets) received from the HSS. Only UE passes the
authentication is allowed to access the network.
Verification of the user equipment. The MME supports the use of either the S13 interface or the
Gf interface to validate the user equipment (IMEI). The access of the blacklisted UE is denied
whereas the greylisted UE is at the discretion of the operator configuration.
The MME supports the following NAS integrity protection algorithms: null, eia1 and eia2. The
MME selects the algorithm based on the UE capability and operator preference via configuration.
The MME supports the following NAS ciphering algorithms: eea0, eea1 and eea2. The MME
selects the algorithm based on the UE capability and operator preference via configuration.
The operator can configure the lifetime of a security context to ensure that the MME reauthenticate the UE once the security context established has be in use for a configured amount
of time.
The MME passes the security keys to the eNodeB for user bearer confidentiality.
The MME manages the unused authentication vectors according to TS33.401.
To protect the UE identity confidentiality, the MME assigns GUTI to the UE when a UE attaches
or performs an incoming inter-MME TAU. Further, there is a lifetime of the GUTI to ensure that
the same GUTI is not used for too long to make the UE vulnerable to hackers. When the lifetime
expires, the MME will assign a new GUTI to the UE when possible.
In the case of SGSN, the following security capabilities are provided:
Authentication using GPRS or UMTS Vectors (Triplets or Quintets) received from the HLR/HSS.
Only UE passes the authentication is allowed to access the network.
Verification of the user equipment. The SGSN supports the use of either the S13 interface or the
Gf interface to validate the user equipment (IMEI). The access of the blacklisted UE is denied
whereas the greylisted UE is at the discretion of the operator configuration.
The SGSN supports selection of integrity and ciphering algorithm in the 3G case and provides the
suggested list to the RNC (the final selection is done by the RNC).
The SGSN supports selection of ciphering algorithm in the 2G case. For 2G subscribers, the
SGSN supports the following ciphering algorithms: gea1, gea2 and gea3.
The operator can configure the lifetime of a security context to ensure that the SGSN reauthenticate the UE once the security context established has be in use for a configured duration.
The SGSN manages the unused authentication vectors according to TS33.102.
To protect the UE identity confidentiality, the SGSN assigns PTMSI to the UE when a UE
attaches or performs an incoming inter-SGSN RAU. Further, there is a lifetime of the PTMSI to


100
ensure that the same PTMSI is not used for too long to make the UE vulnerable to hackers.
When the lifetime expires, the SGSN will assign a new PTMSI to the UE when possible.
6.7 Subscriber Management

The vMME provides a set of features to manage the subscribers on the system. The following subsections discuss these features and their purpose.
6.7.1 PLMN Based Monitoring and Admission Control

This feature provides the operator the ability to control Attaches, Incoming TAU/RAU or Handover
Requests, and dedicated bearer setup of their roaming partners subscribers. This includes control
over both the request rates and maximum numbers of subscribers and sessions for a particular
PLMN; the operator can control the rate at which a partners mobiles can attach to the MME and
SGSN, as well, the maximum number of subscribers and bearers supported for that partner operator.
This allows the operator to ensure that the system resource on the MME/SGSN is not over-allocated
to incoming roamers from a particular partner and ensures that the home users are not impacted.
Furthermore, the feature also allows the monitoring of the number of subscribers for each partner and
generating alarms based on the configured thresholds. The monitoring capability and the admission
control capability can be enabled together or separately depends on the operators needs.
This feature is optional to the operator and can be enabled or disabled through the feature control
configuration. By default the feature is disabled.
6.7.2 Subscriber Classification

The vMME allows the operator to classify UE into different subscriber classes. The other features
discussed below utilize the Subscriber Classification capability.
The classification of a UE is based on the following two attributes associated with the UE: 1) its IMSI
and 2) the current service area of the UE. The operator can configure how to map the two attributes
of a UE to a particular subscriber class. The granularity of the service area that the operator can
configure is at the Routing Area or Tracking Area level. The operator can also specify larger areas
such as: a Location Area, a PLMN or simply global to mean the entire coverage area of the node.
The ability to classify the same UE to different classes based on its service area can be utilized to
manage the network more effectively. For example, the operator can cap the maximum bandwidth of
incoming visitors in a congested coverage area and yet allow them to obtain higher bandwidth in
other coverage areas.
For each subscriber class, a set of attributes can be defined as to how the UE is treated in the
MME/SGSN. This allows the operator to apply local policy for the UE to override information received
from the HSS. The following attributes are defined per subscriber class (for more information the
reader is encouraged to consult the Operators Guide):

101
Subscriber type: homer, roamer and snr-roamer. Homer is used to indicate an operators own
subscribers. Roamer is used to indicate incoming visitors. SNR-Roamer is a special type of
roamer that the operator has a Seamless National Roaming agreement with (more detail in the
next section).
EPLMN list: each subscriber class may be associated with its own list of equivalent PLMN list.
This assists the UE in locating the correct PLMN once it moves out of the coverage area of the
current PLMN.
Forbidden APN list: This attribute allows the operator to limit certain APN from being used by a
particular class of subscribers.
Local QoS Profile: This attribute allows the operator to apply local QoS on the subscribers. More
detail is covered in Location based QoS management.
CSFB capability: This attribute allows the operator to control whether the subscriber is permitted
to perform CSFB.
RFSP index: This attribute allows the operator to override the value received from the HSS. This
is useful particularly when the incoming visitors operator uses different RFSP conventions
compared to this network.
Voice domain profile: This attribute allows the operator to set different voice domain preference
for different subscribers.
SNR APN Operator id: This attribute allows the operator to replace the default APN OI with the
configured value for SNR-roamers.
SNR EMM Reject cause and SNR GMM reject cause: These attributes are used for SNR
purpose. More detail in the following section.
When both PLMN Based Monitoring and Admission Control and Subscriber Class based control are
enabled, the PLMN Based control is always applied first.
6.7.3 Seamless National Roaming

This feature enables the network operator to offer seamless roaming to subscribers of partner
operators. The transition between PLMN coverage areas is transparent to the subscribers. Handover
of PDP contexts or Bearers without interruption across PLMN boundaries is enabled by fast PLMN
selection through equivalent PLMN (EPLMN) support.
In order to reduce the initial build-out cost of networks, providers and customers often sign roaming
agreements with other in-country operators to share coverage areas. Seamless National Roaming
allows operators to reduce initial network build-out costs but still provide large, countrywide coverage
footprints.
In support of National Roaming, both Operator A and Operator B build unshared and shared areas.
The unshared coverage areas of Operator A serve subscribers of Operator A and international
roaming partners only. Subscribers of Operator B are denied service in Operator As unshared area.

102
Operator Bs subscribers are allowed service in Operator As shared-coverage areas and are, in
some respects, treated as home subscribers in these areas. The reverse scenario holds true for
Operator Bs shared and un-shared coverage areas.
The following figure depicts coverage areas owned by two network operators A and B. Both operators
have 4G spectrums. Both operators have shared and unshared areas, with roaming agreements in
place for the shared areas. This feature allows both operators to offer a coverage area that is the
complement of both operators.


103
Figure 42. National roaming network Example

Operator A Unshared Area
A-1
A-2
A-4
A-3
Operator A LTE Coverage

Operator A Shared Area
Operator A LTE Allowed

Operator B LTE Restricted

Operator B LTE Allowed
Operator B Shared Area
A-2
A-4
Operator B LTE Coverage
A-1
A-3
Operator B Unshared Area


Operator A LTE Restricted
At a high level, the following is the functionality implemented in the feature:
Operator configurable EPLMN lists (maximum of 16)
Subscriber Class based selection of EPLMN list: This allows the partners UE to move to their
own network once the UE moves out of the coverage of this operator into an area covered by
partner or an area that both operator compete in.
Subscriber Class based cause-code for Attach and RAU/TAU rejects. If the Reject cause is set to
non-0, the subscriber class is considered to be not allowed in the location.
Subscriber class based APN OI override. This allows the operator to set the APN OI for the
partner based on the partners own convention.
This feature is applicable to both the MME (4G coverage) and the SGSN (2G/3G coverage).


104
6.7.4 Location based QoS management

As discussed above, the subscriber class is determined based on the current location as well as the
IMSI and a particular QoS profile can be applied on a particular class, this allows the operator to
control the QoS allowed to a subscriber based on the location. This feature can be used to control the
congestion in certain hot spots. For example, a subscriber is allowed to use full throughput capability
in all areas except in the congested downtown area. This feature can also be used to limit the QoS for
incoming visitors. In the present release the Location Based QoS Management feature is only
available on the SGSN.
6.7.5 APN NI Management

The APN Management feature allows the operator to resolve a few issues related to PDN or PDP
activations when the UE fails to provide an APN, or provides an invalid APN. Under normal 3GPP
APN selection procedure the request would be rejected. This usually leads to customer calls to the
support line and unhappy customers.
This feature allows the operator to select a replacement APN based on the local configured policies
such that the PDN/PDP activations can be completed. This feature supersedes the APN Override
feature in the prior release of the MME.
This capability can be tailored on a per subscriber class basis. Please refer to Subscriber
Management for the background information related to subscriber class. The following actions can be
selected by the operator to determine the MME/SGSN behavior when the UE failed to provide an
APN or provided an invalid APN: use the default APN, or use the only non-wildcard APN; use the first
non-wildcard APN or use the locally configured APN.
6.7.6 APN OI Management

This feature allows the operator to change the APN OI of a subscriber based on the local
configuration on the vMME. This capability can be used to direct the SGW/PGW/GGSN selection
based on the subscriber.
6.7.7 Local EPS QoS Control

This feature added support for Local EPS QoS Control in the MME and S4-SGSN. Local EPS QoS
Control allows operators to define Local EPS QoS profiles which are used to downgrade/enforce the
QoS parameters that are received from the HSS and enforce the QoS parameters that are received
from the S-GW.
For the MME, Local EPS QoS Control is performed during Attach, PDN Connectivity, UE/GW Initiated
Activation, UE/GW/HSS Initiated Modification, Inter MME/Inter RAT Tracking Area Update and Inter
MME/Inter RAT S1 Handover procedures.


105
For the S4-SGSN, Local EPS QoS Control is performed during Session Management procedures of
PDP Context Activation, PDP Context Modification, HSS Initiated Modification, Inter-SGSN Routing
Area Update and Inter-SGSN SRNS Handover (for 3G mobiles).
Based on the UE and its location, the MME/S4-SGSN can override or reject the HSS
provided/requested QoS values. This feature gives the operator control over management of QoS
requested by roaming partners and UEs.
6.7.8 Local Breakout Control

This feature allows the operator to control if local break out (utilizing the PGW and GGSN in the
serving network) is allowed or not on per partner PLMN basis. Additionally, the operator can define
the APN for which local break out is allowed.
6.7.9 Operator determined barring

The vMME can reject the service of users, particularly incoming roamers, based on the Operator
Determined Barring parameter received from the HSS/HLR.
6.7.10 MVNO subscribers

This feature allows the support of Mobile Virtual Network Operator (MVNO) on the MME. An MVNO is
a mobile operator that does not own spectrum and the entire necessary network infrastructure, but
has business arrangements with traditional Mobile Network Operators (MNO) to buy wholesale
access to their infrastructure which they use to provide service for their own customers. This feature
allows for an MNO to optionally support the MVNO architecture on their MME. This feature currently
classifies a PDN as MVNO based on the S5 interface supported by the PGW and a configured list of
APNs. The MME classifies a PDN as MVNO using the following criteria:
If the MNO network uses PMIP as the S5 interface protocol
The DNS procedure returns GTP for a home user
and the selected APN is configured
The MME applies locally administered policy on the MME to control the QoS level allowed for such a
user.
In the present release, the MVNO feature is only available on the MME.
6.8 User Bearer

User bearer allows the user originated or terminated IP packets to be tunneled via the vMME. User
bearer capability is only provided by the SGSN for the following cases:

106
UE is currently on the 2G access network.
UE is currently on 3G network and the PDP context is based on Gn interface. Even if direct tunnel
is enabled, the SGSN still provides the user bearer path capability for the ability to perform
downlink paging.
In the case of the MME or the UE is on 3G using S4-SGSN capability, the user bearer is not
established on the vMME. Rather, the SGW is used for the user bearer.
6.8.1 2G User Plane

When the UE is attached on the 2G network, the user data path is anchored on the SGSN. On the Gn
interface, the SGSN sends uplink user packets via the GTP-U tunnel to the GGSN, at the same time
it receives downlink user packets from the GGSN. Please refer to Gn/Gp Interface User Bearer Plane
for details on the interface.
For the Gb interface, the SGSN provides the following function to enable the reception and delivery of
user packets:
Logical link control (LLC) layer
The Logical Link Control (LLC) layer provides acknowledged and unacknowledged exchange with the
peer LLC entity on the MS.
The LLC provides six (6) Service Access Points (SAP) to the upper layers:
four dedicated to SNDCP which manage data packet transmission
SAPI/3 => QoS1 (real time application: accept no delay)
SAPI/11 => QoS4 (best effort)
one dedicated to GPRS Mobility Management (GMM) => SAPI/1
one dedicated to Short Message Service (SMS) => SAPI/7
LLC is involved in the negotiation of Layer 2 and Layer 3 parameters associated with the data path of
a mobile session. More than one mobile session can share the same SAPI. As can be seen above,
the LLC layer provides service to the GMM layer (as well as the SM layer) the SMS layer for SMS
services and the SDNCP layer for user bearer packets. The LLC layer also performs ciphering to
protect the confidentiality of the user packets. Please refer to UE Security Management for more
details with regard to UE security.
SNDCP layer


107
The SubNetwork Dependent Convergence Protocol (SNDCP) layer multiplexes multiple PDP
contexts from a user onto corresponding LLC SAPIs (logical links). A PDP Context is associated with
a particular NSAPI.
SNDCP also provides segmentation and re-assembly for any packets that are larger than the LLC
frame size of the corresponding SAPI.
SNDCP provides support for Data and IP Header compression. These capabilities can be negotiated
with the mobile station:
V.42bis data compression helps optimize radio resource usage efficiency
TCP/IP header compression improves network performance for small packet for mobile
applications such as audio/video streaming
An uplink user packet traverses the LLC layer and the SNDCP layer and then it is pushed to the Gn
interface after the IP packet is reassembled. A downlink user packet received from the GGSN is
pushed through the SNDCP layer to the LLC layer and then transmitted via the Gb interface to the
BSS and the UE.
6.8.2 3G User Plane

For 3G user plane, the role of the SGSN is quite simple. It supports transfer of both uplink and
downlink bearer traffic in the Packet Domain between the RNC and the GGSN. The SGSN terminates
the GPRS Tunneling Protocol (GTP) from the RNC and re-originates GTP to the GGSN for transport
of user data packets.
When the support of Direct Tunnel is available at the RNC and the GGSN, the user bearer on the
SGSN can be suspended, allowing the RNC and the GGSN to transmit bearer packets directly to
each other. The negotiation of Direct Tunnel is handled by the Session Management based on the
capabilities of the GGSN and RNC. The Direct Tunnel feature may be deactivated and re-activated
during mobility events, depending on the capabilities of the RNC.
When the S4-SGSN capability is enabled, the operator can control if the S4-SGSN should support 3G
user plane on the SGSN or not. If configured, the S4-SGSN sets up user bearer path on the SGSN
for all S4 based PDP contexts.
6.8.3 Packet Buffering

The SGSN supports buffering of the downlink user packets during paging procedure as well as during
inter-system change, or inter-SGSN RAU procedures. The buffering capability reduces packet loss
during the mobility events. This capability is applicable to both 2G and 3G user bearer scenarios.


108
6.8.4 Traffic Shaping

This is an optional feature that the operator can enable on the SGSN to allow the SGSN to apply
different DSCP code marking based on the following QoS attributes of the PDP context of the UE:
ARP, Traffic Class and Traffic handling priority. This allows the IP network to prioritize the user
packets based on the QoS of the PDP contexts.
This feature is applicable to both 2G and 3G user bearer plane.
6.9 HSPA+ Support

The HSPA+ feature allows higher data rate in the 3G network. For SGSN, the feature provides the
following capability:
First, higher number of RNC fan-out capability. The maximum number of RNCs supported is
4096.
Second, higher maximum user throughput capability.
The SGSN supports the QoS profile required for the UE to obtain the highest throughput allowed by
the HSPA+ network. Third, the enhanced SRNS Relocation procedure is supported. This allows
faster handover from one RNC to another.
This feature is only applicable for the SGSN.
6.10 Direct Tunnel

The Direct Tunnel function is a solution introduced for the 3G UMTS network prior to the advent of
EPS network architecture. This feature allows the user bearer to bypass the SGSN and link the RNC
directly to the GGSN. This enhances the network efficiency particularly when high data rate PDP
contexts are established using the HSPA technology.
Not all the 3G access nodes or the GGSN nodes need to support the function. Based on the
configuration, the SGSN determines when to use direct tunnel and when not to use direct tunnel
based on the capability of the RNC and the GGSN.
For cases where it is desirable that certain APNs not use Direct Tunnel, an apn screening table can
be utilized to disable direct tunnel functionality to a GGSN on a per APN basis. An APN check is
performed for each activation and if the APN is in the restricted list, then Direct Tunnel is not used. If
it is not contained in the list, the activation procedure continues as normal (check is performed to see
if the GGSN IP supports Direct Tunnel). Note that APN screening takes precedence over per GGSN
configuration on the SGSN.
This feature is only applicable for the SGSN.


109
6.11 Access Sharing

Access Sharing, also known as Intra Domain Connection of Radio Access Network (RAN) Nodes to
Multiple Core Network (CN) Nodes, allows multiple Core Network nodes to serve the same set of
access nodes. This allows a single CN node to provide coverage to a greater geographical area. The
feature can be applied to the 2G access network (called Gb Flex), 3G access network (called Iu Flex)
or 4G access network (called S1 flex). The vMME supports access sharing for all three access
technologies. The access sharing capability also introduces the concept of pool areas. Pool Areas
allow a Mobile Station (MS) to move between the access nodes in the Pool Area and be serviced by
the same core network node (either the MME or the SGSN, it can even be the VLR/MSC in the case
of 2G/3G circuit domain).
The access sharing feature provides many benefits to the operator:
Improved Scaling between the access nodes and core nodes
Without the capability, each access node can only be connected to a single core node. This means
that the total capacity used by all the access nodes cannot exceed the total capacity of the core node.
Otherwise, there can be wastage in the access network capability. In reality, it is difficult for an
operator to match these two values such that neither access capacity nor core capacity is wasted.
Using 2G access as an example, if each BSS requires 40% of the SGSN capacity, an operator can
only connect two BSSs to the SGSN. 20% of the SGSN capacity would go unused. If the operator
connects three BSSs to the SGSN, then the SGSN will be overloaded while some of the access
capacity is not realized.
Access sharing allows an access node to be supported by multiple core nodes. This means the total
capacity of the access network can be shared by the total capacity of the core network, resulting
more efficient usage of the network equipment. Using the example above, the operator could have
two SGSNs serving five BSCs. In simple terms, the capacity from 2.5 BSSs would be served by each
SGSN.
Core Node Scalability
Given that multiple core nodes can be placed in the same pool, the capacity supporting a group of
access nodes may be increased, or scaled, by adding new core nodes to the pool. This can be
achieved without impact the subscribers already in the system.
Pooling of Hardware Resources
Generally, each core node is engineered to support its Busy Hour (BH) capacity. Based on
geographical coverage, the BH for different core nodes are not necessarily the same. If multiple core
nodes can be pooled, then the total hardware requirements for a pool of core nodes needs to meet
the peak engineering demands of the pool and not each individual core node. This can result in lower
number of core nodes needed for the same coverage area.
Reduction of Signaling
A UE served by a core node in a Pool Area does not need to migrate to another core node when
moving between access nodes within the Pool Area. This means that there are less inter-nodal

110
mobility management events, which results in decreased signaling traffic between the core nodes and
further reduces the signaling load on the HSS/HLR.
Redundancy and Geo-redundancy of the Core Node
Multiple core nodes can serve the same pool area. This allows a new way to provide network level
redundancy. For example, if N core nodes are needed to meet the engineered capacity, then
deploying N+1 core nodes within the pool would allow for an entire nodal failure and still be capable
of meeting the engineered capacity. Further, access sharing feature also allows geo-redundancy for
the core network. The core nodes can be deployed in geographically dispersed fashion across the
pool area. This ensures that the subscriber base can always reach the network even if there is a loss
of a site (eg due to power outage etc).
The vMME supports access sharing for all three access technologies. The following sub-sections
discuss the capability for each.
6.11.1 Gb Flex
Gb Flex allows the 2G access nodes to connect to multiple SGSN nodes. This also requires that the
SGSN has relatively high fan-out capability to support a larger geographic area. The vMME is
capable of connecting to a maximum of 600 BSS nodes with up to 30,000 cells.
For Gb Flex, part of the PTMSI is used to identify the core node in a pool. The bit field is thus called
NRI (Network Resource Identifier). The 3GPP specification allows NRI to be from 1 to 8 bits. We
recommend the operator to use 8 bit such that it is aligned with the length of MME code so that
migration to a combined 4G/2G/3G pool is simplified.
The SGSN supports multiple NRI values to be assigned for a single node. By assigning different
number of NRI values to different SGSNs in the pool, the BSS will be able to properly load-balance
the core network node9. We also recommend that all the NRI values to be divided among the SGSNs
in the pool except for a few reserved ones that can be used as null NRIs for load redistribution
purpose (see Load Redistribution). Given that the NRI is part of the PTMSI, not using some of the
values would reduce the number of available PTMSIs, thus increase the probability of collision
between two UEs with the same PTMSI. When multiple NRI values are assigned, the vMME is
capable of round-robin between the NRI values to maximize the number of PTMSIs.
The SGSN can act as the default SGSN in a pool. This function is needed for inter-pool mobility
events. When an incoming request for a mobile context is received, the default SGSN can forward the
request to the right SGSN in the pool. On the SGSN, the IP addresses of the neighboring SGSNs are
configured for each NRI such that no additional DNS procedure is required for message forwarding.
This assumes the Access Node properly round-robin between the list of NRIs configured on it.


111
6.11.2 Iu Flex
Iu Flex is similar to Gb Flex, it allows the 3G access nodes to connect to multiple SGSN nodes. This
also requires that the SGSN has relatively high fan-out capability to support a larger geographic area.
The vMME is capable of connecting to a maximum of 4096 RNC nodes.
The NRI management and default SGSN capability for Iu Flex is identical to Gb flex, please refer to
previous section for more details.
6.11.3 S1 Flex
S1 Flex is used for the 4G network. It also requires high fan-out capability of the MME. The vMME
supports a maximum of 25,000 eNodeBs, thus is conducive for S1 Flex deployment.
S1 Flex was built into the 4G specifications from the beginning (as compared to add-on in the cased
of Gb and Iu Flex). Thus the method used is slightly different.
The identification of the MME uses the MME code id instead of the NRI value which is bit field
borrowed from the PTMSI. Furthermore, the MME has the ability to indicate its relative capacity to the
eNodeBs during the SETUP procedure. This avoids the need for utilizing multiple MME codes for a
standalone MME. In the case of a combined MME/SGSN node, we recommend the list of MME code
to be the same as the list of NRI values supported on the node. This reduces the probably of PTMSI
collision when UEs move from 4G network to 2G or 3G network.
6.11.4 Circuit Domain Flex

The vMME also supports VLR pooling. For the SGs interface and Gs interface, the MME and the
SGSN is responsible to select the VLR based on the location as well as the IMSI of the UE. This
ensures that the same VLR is used when the UE moves between different location areas served by
different MME/SGSN nodes. In the downlink messaging, the MME/SGSN passes the proper VLR
core node identifier such that the UE can be served by the correct VLR when it responds to downlink
messages.
6.11.5 Load Redistribution

When an MME or an SGSN is part of core node pool, the Load Re-balancing functionality permits
UEs that are registered on an MME or an SGSN (within a Pool Area) to be moved to other MMEs or
SGSNs in the pool. The purpose for this function is to support a set of maintenance operations that
the operators may take on the MME or the SGSN and to reduce the impact to the subscribers in the
network during the maintenance operations.
This feature provides a command line interface for the operator to start an offload on per VM basis or
all VMs (the entire MME/SGSN). As of this release, additional command line options are available
that allow operators to direct a particular UE or a number of UEs to a specified target MME/SGSN in
the same pool. This feature also addresses the handling of the SERVICE SHUTDOWN command for

112
the Subscriber Control function. During the quiescing period of the SHUTDOWN process, the
MME/SGSN will initiate an off-loading procedure pre-configured by the operator.
The MME/SGSN allows the operator to specify different actions for Idle UEs versus Connected UEs.
The actions range from passive (i.e. waiting for the UE to detach) to detach (i.e. forcefully detach
the UE). For a combined MME/SGSN, the specified action is applied to all the subscribers. Please
note, the exact procedure applied on each subscriber may be different between the MME and the
SGSN, this is due to the 3GPP specification difference in handling load redistribution between 2G/3G
and 4G. In the case of the MME, the operator is also advised to adjust the MME relative-capacity
such that the eNodeBs can distribute new incoming Attach request appropriately, i.e., avoiding the
node being offloaded.
In the case of the MME, when a CallP VM is being offloaded, no new attaches are routed to the CallP
VM. If the new attaches are not already routed to other MMEs due to relative-capacity of the MME
belong offloaded, internally, the attaches will be routed to any CallP VM hosting the SC function that
are not being offloaded. In the case of the SGSN, given that there is no concept of relative-capacity,
the behavior is slightly different. In the case of the SGSN, when a CallP VM is being offloaded with
passive action for both the connected UE and idle UE, that SC is not selected for any new Attach,
IRAU or handover requests. If one of the actions is non-passive, then the SC allows incoming attach
requests and such that the SGSN can send an attach accept or rau accept with new PTMSI
containing the null NRI and non broadcast RAI, which would trigger the UE to move to a different
SGSN.
The maintenance operations that can benefit from this feature are listed below.
Off-load all the subscribers from an MME or an SGSN and migrate the UEs to other MMEs or
SGSNs in the pool. Operator can pick passive option for both idle and connected subscribers and
let UEs detach on their own slowly.
Load-balance the MMEs or SGSNs in a pool by off-loading part of the subscribers from one MME
or SGSN and migrating the subscribers to other MMEs and SGSNs in the pool after a new node
is added to the pool to achieve quicker load-rebalancing within the pool.
Off-load all the subscribers from the MPU on the MME or SGSN and migrate the UEs to either
other SGSNs in the pool. After the completion, the freed-up MPU can be removed for hardware
maintenance or to be reconfigured for other functions.
Seamless upgrade of a node by moving all UEs from one MME/SGSN to another MME/SGSN in
the same pool.
Manual redistribution after adding new nodes in the network is achieved with minimal impact to
the UEs.
Move a single UE from one MME/SGSN to a specified MME/SGSN.
This feature is applicable to both the MME and the SGSN.


113
6.12 UE Reachability Management

The vMME supports the UE Reachability procedure as described in specification 3GPP 23.401 and
TS23.060. The function is available for both the MME and the S4-SGSN. This feature allows the HSS
to be notified of UE activity on the MME/SGSN such that any services pending delivery to the UE can
be resumed.
In the case of Gn-SGSN, the SGSN supports the capability to notify the HLR when UE activity is
detected on the SGSN such that the HLR can trigger UE terminated SMS delivery.
6.13 UE/MS Purge

After a subscriber detaches on the SGSN or the MME, the mobile context information is retained
unless the Detach is triggered by a Cancel Location request from the HSS or the HLR. The benefit of
retaining the mobile context is that it enhances the efficiency of the network as some messages to the
HSS or the HLR can be avoided. It also enhances UE confidentiality such that network does not need
the UE to send IMSI in plain text when the UE re-attaches. On the other hand, it may not be desirable
to keep the mobile context on a node for too long as it can be a security concern. The vMME supports
the use of UE/MS Purge to inform the HSS or the HLR that the mobile context information on the
node is removed. Furthermore, the vMME allows the operator to control how UE purge is triggered.
The operator can specify via configuration, whether to transmit the UE/MS Purge on explicit detach,
after a specified period of time after detach, or immediately. Further, the operator can apply different
Purge trigger points for home users versus incoming roamer users.
6.14 RAN Information Management

The RAN Information Management (RIM) feature provides a generic mechanism for the exchange of
arbitrary information between applications belonging to the GERAN, UTRAN or E-UTRAN nodes. The
RAN information is transferred via the MME and SGSN core network node(s). In order to make the
RAN information transparent for the Core Network (CN), the RAN information is included in a RIM
container that is not interpreted by the Core Network nodes.
The RIM procedures are optional both in the RAN node and in the SGSN or the MME. For the Gb
interface, the use of RIM procedures is negotiated at start/restart of the Gb link. For the Iu or the S1
interface, there is no negotiation of using RIM procedures at Iu or S1 link start/restart.
The RAN information is transferred in RIM containers from the source RAN node to the destination
RAN node using RIM messages. The contents of the RAN information is transparent to the Core
Network (SGSN or MME), that is the RIM containers are not interpreted by the SGSN or the MME.
Each message carrying the RIM container is routed and relayed independently by the core nodes.
The vMME supports RAN Information Management for all three types of access nodes. If the target
node is locally on the MME or the SGSN, the information is routed within the node. If the target node


114
belongs to a different core node, the MME or the SGSN sends the message to the target core node
via the GTP-C based interfaces.
The RAN Information Management feature can be used to support any inter-RAN nodes applications.
The following are possible examples:
NACC Network Assisted Cell Change
SON Self Organizing Network
This feature is applicable to both the MME and SGSN.
6.15 DNS Support

The vMME supports both static cache (locally configured) and dynamic cache. The static cache
entries can be used in lieu of a DNS server in a small configuration. For large networks, we expect
DNS servers to be deployed. However, the static cache can still be used for various purposes such
as to improve network efficiency, to address missing DNS entries by a roaming partner etc.
When the vMME is deployed as a standalone Gn-SGSN, only A record based queries are performed.
Once S4 SGSN function is enabled, or the MME function is deployed, DNS procedures defined in
TS29.303 is performed. This section discusses the capability related to the S-NAPTR based
procedure.
For the S-NAPTR based procedure, 3GPP defines the concept of app-service and app-protocol
used in the place of a service parameter in a NAPTR record. When performing an address
resolution, the app-service and app-protocol information in a record received in a DNS response is
used by the vMME to determine which record to use for the next step. The next step can be a query
to translate the selected hostname to IP addresses or additional NAPTR query or an SRV query.
The MME uses the DNS function for the following procedures for resolving the logical name to obtain
an IP address for the following nodes via 3GPP TS 29.303 SNAPTR procedure. The MME allows the
operator to configure the static addresses locally on the MME. If the logical name resolution cannot
be performed locally, than the external DNS server will be utilized for obtaining the IP address. The
following table details the components of each query type and the involved procedures and the
corresponding app-service and app-protocol used. The names for app-service and app-protocol
are standardized in TS23.003.
Table 47.
DNS Procedure and service parameter usage
Node to
select
Procedure
PGW
PDN connectivity
Domain name
used in SNAPTR
Query
Service Parameters/
Service Parameters/
app-service
app-Protocol
APN-FQDN
x-3gpp-pgw
x-s5-gtp:x-s5-pmip
(local PGW access)
or


115
Node to
select
Procedure
Domain name
used in SNAPTR
Query
Service Parameters/
Service Parameters/
app-service
app-Protocol
x-s8-gtp:x-s8-pmip
(Incoming Roamer
Home PLMN PGW
access)
SGW
PDN connectivity, PGW

pairing
TAI-FQDN (for
MME)
x-3gpp-sgw
x-s5-gtp:x-s5-pmip
(local PGW access)
Or
or
RAI-FQDN (for S4SGSN)
x-s8-gtp:x-s8-pmip
(Incoming Roamer
Home PLMN PGW
access)
SGW
s11 discovery
SGW canonical
node name
x-3gpp-sgw
x-s11
SGW
s4 discovery
SGW canonical
node name
x-3gpp-sgw
x-s4
SGW
TAU/RAU and handover

with SGW change
TAI-FQDN (for
MME)
x-3gpp-sgw
x-s5-gtp:x-s5-pmip
(local PGW access)
Or
or
RAI-FQDN (for S4SGSN)
x-s8-gtp:x-s8-pmip
(Incoming Roamer
Home PLMN PGW
access)
MME
Inter-MME TAU
MME-FQDN
x-3gpp-mme
x-s10
MME
Inter MME handover or

RIM procedure
TAI-FQDN
x-3gpp-mme
x-s10
SGSN
Inter SGSN RAU
RAI-FQDN
x-3gpp-sgsn
x-gn:x-gp:x-s3:x-s16
SGSN
Inter SGSN handover or

RIM procedure
RNC-FQDN
x-3gpp-sgsn
x-gn:x-gp:x-s3:x-s16
GGSN
PDP Context activation
APN-FQDN
x-3gpp-ggsn
x-gn:x-gp
MSC
Single Radio Voice Call

Continuity
TAI-FQDN
x-3gpp-msc
x-sv
Even though there can be many valid variations of DNS procedure to select a node and resolve to the
IP address needed, the typical steps supported by the vMME are as follows:
Two steps: NAPTR -> A or AAAA.
This is the most common and efficient case. The MME/SGSN first translates the FQDN input into a
list of NAPTR records. From the NAPTR records, a record is selected and the corresponding


116
hostname is used as input for the ensuing A or AAAA query. One of the IP address in the returned
record is used for the procedure.
Three steps: NATPR -> NAPTR -> A or AAAA
This approach can be used as a means to reduce maintenance cost of the DNS servers when there
are changes in the network. The first step retrieves the intermediate record linked to the input FQDN,
and ensuing query retrieves a set of hostnames supporting the input FQDN. Finally the third step
retrieves the needed record for IP address resolution.
Three steps with SRV: NAPTR -> SRV -> A or AAAA
This is the same as in the previous case except the second step uses SRV record instead of an
NAPTR record.
As part of the SNAPTR based DNS procedure, the vMME supports the following capabilities:
Collocation and location proximity based search: The operator can configure to enable the
location proximity based search. This capability mainly applies to SGW and PGW selection.
When the capability is enabled, the MME/SGSN tries to select the PGW and SGW that are
closest to each other based on the host name provided the hostnames are preceded with topon.
The collocated PGW/SGW is considered as closest to each other.
Static load balancing: When multiple NAPTR records returned match the criteria, the vMME
applies the preference field from the records to perform weighted round-robin to select a record.
When multiple SRV records returned match the criteria, the vMME applies the weight value from
the records to perform weighted round-robin to select a record. For A/AAAA records, a simple
round-robin is used to select an IP address.
6.16 SGW, PGW, MME, GGSN and SGSN Selection

As discussed in DNS support, the vMME uses NAPTR based DNS procedures to perform nodal
selection. On top of that, there are other capabilities that are supported on the MME/SGSN related to
the selection of the nodes. This section discusses such features.
First, one aspect of the PGW selection is to support a UE move from non-3GPP wireless network
(such as CDMA HRPD or WiMax) and be able to preserve the IP address allocated to the UE. The
MME supports the usage of the PGW identity received from the HSS in this case if the UE indicates
that the PDN Connectivity request is for a handover from non-3GPP wireless network. Furthermore,
for a UE capable of moving to non-3GPP network, the MME promptly updates the HSS when a new
PGW is selected for the UE.
Second, 3GPP allows two different tunneling protocols between the SGW and PGW. Table 47 in the
previous section already revealed the two competitors: GTP and PMIP. The MME/SGSN ensures that
the matching protocol is used. To enable the proper selection, the operator can specify on the vMME
the protocol used for each PLMN.


117
Third, node reselection capability. To enhance the reliability, the vMME performs node re-selection
when the initial selection turns out to be a failed node. The MME/SGSN can reselect a different SGW,
PGW, MME, GGSN and SGSN if that happens. The initial selection is excluded from the reselection.
Through configuration, it is possible to allow GGSN selection based on Charging Characteristics.
When this functionality is enabled, a comma separated list of charging characteristic in 0x prefixed
hexadecimal notation can be defined. If there is a match between the provisioned values in the list
and the charging characteristics values received from the HSS/HLR for the UE, the DNS query string
used to select a GGSN is modified to add the charging characteristic value as an APN-NI suffix.
6.17 Advanced Tracking Area Management

The MME supports multiple (up to 16) TAIs in the TAI list. The MME supports two different ways to
create the TAI list. One is based on the following simple method:
The TAI list will only include the current TAI after a new attach, a MME relocation or a SGW
relocation.
After a normal TAU procedure without SGW or MME relocation, current TAIs will be included to
the TAI list. If the number of TAIs on the resultant list is more than the configured max, then the
oldest TAI is displaced by the current TAI.
When the UE is paged, all the TAIs in the TAI list are paged.
The second method is used when the Advanced Tracking Area feature is enabled. With this method,
the MME utilizes heuristics based on mobility data collected on the MME. The key concepts to
advanced tracking area management are:
The MME predicts the tracking area a UE is likely going to travel into based on the mobility
information of all the UEs on the MME.
By including the likely TAs in the TAI list for a UE, the UE does not have to perform a tracking
area update when it moves into a tracking area in the list. This minimizes the non-revenue
generating signaling.
A UE that has a high probability of being paged relative to its tracking area updates will have a
smaller tracking area list, since the cost of paging is typically higher than a single tracking area
update.
By using the Advanced Tracking Area management capability, the operator can reduce the overall
idle mode signaling rate, including both TAU update related signaling and Paging signaling.
This feature is applicable to the MME only.


118
6.18 Session-less UE Automatic Detach

This feature is mainly used to control the capacity of the SGSN. It can be optionally enabled on the
SGSN and is only applicable to the SGSN.
When enabled, the feature automatically detaches UEs on the SGSN that do not have a session
when the subscriber overload condition reaches critical level. The operator can exclude subscribers
whose subscribed APN-NI is on the configured exclusion list.
6.19 GGSN Black Listing

This feature allows the operator to identify the GGSN that is not used by the SGSN for a PDP context
creation. Once configured, the SGSN does not consider the black listed GGSN for new PDP contexts.
This feature can be used to temporarily alleviate a heavily loaded GGSN or avoid a GGSN altogether
due to compatibility or other issues.
6.20 Dynamic Load Status Based SGW and PGW Selection

Prior to this feature, the MME was only able to perform SGW and PGW selection based on the static
weight and priority information retrieved during the DNS procedure. Unfortunately, the static weight
and priority information does not truly know the load status of the SGW or the PGW. As a result, an
MME could select a highly-loaded SGW/PGW or a PGW that has failed. This feature adds support for
proprietary extensions that enable the load status of SGW and PGW and the failure status of PGW to
be passed to an MME and subsequent usage of that status by the MME when selecting SGW and
PGW. This feature is also referred to as Inter-Nodal Congestion Control feature.
This feature requires an SGW that is capable of the proprietary extensions. The feature is only
applicable to the MME at this point.
6.21 3GPP Trace

3GPP Trace provides operators the capability to enable/disable tracing for a subscriber or equipment
(IMSI/IMEI/IMEISV). Tracing allows an operator to monitor the communication between the UE and
the LTE core network.
The tracing for a subscriber is activated locally on the MME using either the CLI or the NETCONF
based OAM interface. The MME propagates trace parameters to other network nodes eNodeBs
and SGWs using signaling messages. The set of nodes to which MME can propagate trace
parameters is indicated in the configuration.
On top of propagating trace command to other nodes, the MME itself also captures messages from
the following interfaces: S1, including the NAS messages, S6a, S10 and S11 messages. The


119
operator can set different depth level as part of the configuration. The captured messages are
recorded in a file using the XML format.
In this release, only the MME function supports the 3GPP Trace. The support for SGSN interfaces is
planned in a future release.
6.22 Call Summary Log

The Call Summary Log (CSL) is an aggregate of relevant service utilization details collected for every
call handled by the MME. These records are generated in the following scenarios:
When a UE (User Equipment) disconnects from an MME or an SGSN: detach (explicit or implicit),
ITAU (Inter-MME Track Area Update), IRAU (inter-SGSN Routing Area Update) or Handover to
another node.
When a session (PDN Connection or PDP Context) is deactivated from the MME or the SGSN.
When a dedicated bearer is deactivated from the MME.
When an attempt to attach, activate a PDN Connection or PDP context, or activate a dedicated
bearer fails.
Each capture event is recorded in a binary file encoded in network byte order. A CSL file consists of a
CSL file header followed by a series of CSL records.
The CSL records can be a useful tool to the operator. It can be used in many different ways. The
following lists possible uses of the CSL feature:
Analyze network resource usage and thus help better engineer the network.
Analyze user pattern in the network and thus help the operator to optimize the deployment of
resources in the network
Trouble-shooting issues in the network to improve operations
Support resolution of issues raised by an end-user
This feature is available for both the SGSN function and the MME function.
6.23 Subscriber Location Notification

The SLN feature allows the operator to track the location of a specified set of subscribers. The
identifiers of the subscribers are configured on the MME. Both the NETCONF interface and the CLI
can be used to start SLN monitoring, cancel SLN monitoring, and trigger On Demand Paging.
The MME supports the following events that are related to the subscriber location notification
function:

120
Target Set (SLN Start Command): set the target.
Target Removal (SLN Cancel): remove the target.
On-demand Page (SLN Page): trigger an on-demand paging for the target to ascertain its current
location.
Timed report due event (:00 or :30): period reporting of the current location every 30 second.
Stop Reporting Time: the MME stops reporting the periodic report after this point.
Target State change (IDLE->CONNECTED, CONNECTED->IDLE): If set, the MME generates an

alarm for the target UEs state change.
This feature is only applicable to the UE on the MME. No reporting is generated if the UE moves to
2G or 3G access.
6.24 P-GW Relocation

As the deployment of LTE ramps up, network operators may want to move load from one EPC node
in an orderly manner with minimal impact to end users and/or additional load on other network
entities. This MME feature facilitates the PGW load re-balancing which results in a re-distribution of
the PGW capacity.
After the S-GW and P-GW conducts the load re-distribution messaging, the selected target P-GW
information is sent to the MME from the S-GW via a Private Extension IE in the GTP Update Bearer
Request. The new P-GW information is encoded in the Fully Qualified TEID format in the Private
Extension IE as defined in 3GPP 29.274. The encoding of the Private Extension IE is proprietary.
This feature requires a SGW that is capable of using the afore-mentioned Private Extension.
After the MME receives the new P-GW F-TEID, it may send a Notify Request (NOR) to the HSS to
update the PDN Identity for the APN. When the successful Notify Answer is received from the HSS,
the MME may update the subscription data, and it should also send an Update Bearer Response with
Request Accepted cause to the S-GW to complete the migration of a PDN connection from one PGW to another.
This feature is only applicable to the MME.
6.25 Peer node anchor point relocation

The vMME dynamically allocate a SIG VM to be the anchor for a peer node when the communication
with the peer is established. This applies to the eNodeB as well as GTP peers (SGW/SGSN/MME)
etc. Once a peer is anchored on a SIG VM, the ingress and egress communication with the peer is
handled by the VM. The vMME automatically selects the target SIG VM based on the load balancing
at the time. Occasionally, the operator may want to move the anchor point for maintenance reasons


121
This feature provides the operator the ability to manually move or relocate an Evolved Node B (eNB)
from one signaling Virtual Machine (VM) to another. The relocation of eNB is performed in-service,
meaning there is no impact to the users connected to the MME from the eNB. Operators can relocate
both home and Macro eNBs. This includes Home eNB gateways, which are classified as macro
eNBs.
This feature also allows the operator to relocate a GTP peer (SGW/SGSN/MME) etc, from one SIG
VM to another SIG VM. Again the migration is in service without taking down the connection or
causing the peer to detect a failure.
6.26 Accounting Service

Charging information in the GPRS/UMTS network is collected for each Mobile Station (MS) by the
SGSNs that are serving the MS. The SGSN transfers collected charging information to the Charging
Gateway Function (CGF), as provisioned by the network operator. The CGF acts as a storage buffer
for real-time charging information collection, and provides the charging information to the operators
Billing System (BS).
Between the SGSN and the CGF, the Ga interface allows accounting for mobility events, Short
Message Service transactions (SMS is available only in GPRS), and data sent and received between
the mobile and the SGSN. Please refer to section Ga Interface for more details.
The vMME also supports a CGF-less option when the SGSN itself collects the CDRs and store them
locally using file format required by the down-stream Billing System. In this mode, the operator can
retrieve the CDR files via secure ftp from the node.
The SGSN Billing supports 3GPP versions v9.6.1 and v10.7.0. Note that only one version is used at a
time. The encoder-version is a configurable parameter and is defaulted to version v10.7.0.
The 3GPP Technical Specifications can be found at www.3gpp.org:
Table 48.
3GPP Technical Specifications
Version
Relevant Specification
V9.6.1
3GPP TS 32.295 v9.0.0- Charging Data Record (CDR) transfer

3GPP TS 32.297 v9.0.0- Charging Data Record (CDR) file format and transfer
3GPP TS32.298 v9.6.0 - Charging Data Record (CDR) parameter description
V10.7.0
3GPP TS 32.240 v10.1.0 - Charging Architecture and Principles

3GPP TS 32.251 v10.7.0 - Packet Switched (PS) domain charging
3GPP TS 32.295 v10.0.0 - Charging Data Record (CDR) transfer
3GPP TS 32.298 v10.7.0 - Charging Data Record (CDR) parameter description


122
6.26.1 Charging information collected by the SGSN

For billing purposes, the SGSN is responsible for collecting charging information related to radio
network usage. The SGSN collects charging information on:
Usage of the radio network, which includes the amount of data, categorized by QoS and user
protocols. The data volumes in both uplink and downlink direction are counted separately.
Usage of the packet data protocol address (for example, how long the MS has used the PDP
address).
Usage of the SGSN-related network resources and the mobile's network activity (for example,
mobility management).
There are various applications involved in the billing information capture and transfer. Information is
generally captured on the SC and SD applications. The SC application encodes the billing records
and transfers them to the Ga application where they are sent to the CGF.
These are the billing functions performed at the SGSN:
Call Detail Record generation/handling (S-CDR, M-CDR, and SMS CDRs)
Partial record generation for both S-CDRs and M-CDRs
ASN.1 encoding of CDRs prior to transfer to the CGF
Transfer CDRs to the CGF using the GTP' protocol
6.26.2 Call Detail Record (CDR) Types Generated by the SGSN

The collected charging information is formatted into Call Detail Records (CDR) for transfer to the
Charging Gateway. The SGSN supports the following CDR types:
SGSN CDR (S-CDR) - Used to collect charging information related to the packet data information
for a mobile in the SGSN. An S-CDR is opened for each activated PDP Context, and contains the
uplink and downlink data volume counters and the PDP Context duration. Please note,
generation of S-CDR is only done when the PDP context is created via the Gn/Gp interface, for
the S4 based PDP context, the SGSN no longer generates the S-CDRs as the responsibility is
shifted to the SGW instead.
Mobility CDR (M-CDR) - Used to collect charging information related to the mobility management
of a mobile in the SGSN. An M-CDR is opened for each mobile upon attach, and contains the
mobile's location information.
SGSN delivered Short message Mobile Originated CDR (S-SMO-CDR) - Used to collect charging
information related to the transfer of short message service transfers from the mobile to the
SGSN. No active PDP Context is required when sending short messages, and data volume
counters in the SGSN are not incremented. Note that SMS messages are sent over the circuit


123
domain in UMTS network. Therefore, the 3G SGSN will not generate S-SMO-CDRs or S-SMTCDRs.
SGSN delivered Short message Mobile Terminated CDR (S-SMT-CDR) - Used to collect
charging information related to the transfer of short message service transfers from the SGSN to
the mobile station. No active PDP Context is required when sending short messages, and data
volume counters in the SGSN are not incremented.
The default configuration is set to collect only S-CDRs. This can be changed through the configurable
cdr-capture parameter of the sgsn-ga-profile. It is recommended that the operator configure what is
required based on the need of the network.
6.26.3 Capabilities of the SGSN Accounting
Daylight Saving Time interaction
The SGSN reacts to Daylight Savings Time (DST) adjustments. Each timestamp within CDRs reflects
the local time of the SGSN at the time of that event, including the system offset at that time.
An example would be a record that is opened before DST, a Tariff Time Change Trigger (TTCT)
event after a DST change and the subsequent CDR closure. The record opening time stamp shows a
pre-DST time and the TTCT changeTime timestamp is a post-DST time stamp with the changed
offset. The duration calculation recognizes the time change event and provides the actual elapsed
time that the CDR was open.
Modifications to system time that are not done with DST affect the CDR time stamps and duration in
an unpredictable manner.
Partial record generation
The standard governing GPRS/UMTS billing supports the concept of partial records. The following
sections describe the partial record generation functionality for S-CDRs and M-CDRs.
Two types of partial CDRs are available:
Fully qualified Partial CDR (FQPC): Partial CDR that contains a complete set of SGSN supported
mandatory fields and SGSN supported conditional fields. This includes all the mandatory and
conditional fields supported by the SGSN. The first partial CDR is a Fully qualified Partial CDR.
Reduced Partial CDR (RPC): Partial CDRs that only provide mandatory fields and information
regarding changes in the session parameters relative to the previous CDR. For example, location
information is not repeated in these CDRs if the subscriber did not change its location.
The default value is FQPC, and can be modified by setting the partial-cdr-type attribute.
S-CDR partial records
An ongoing PDP Context may have several partial records generated in realtime. Upon certain
triggers, an S-CDR is closed and a new S-CDR opened with the same Charging ID/GGSN Address


124
but with a different Local Record Sequence Number. The downstream CGF or Billing System is
responsible for aggregating multiple S-CDRs for the same PDP Context.
An S-CDR record is closed, and a new partial record opened upon the following conditions:
Data volume limit
Time (PDP Context duration limit)
Maximum number of charging condition changes
Management Intervention
Intra-Sgsn Inter-System Change
The following billing features trigger traffic volume updates:
Tariff Time Change
PDP Context QoS modifications
The following billing features trigger generation of partial S-CDRs with closure reason Management
Intervention:
Location Based Billing
Configuration Changes

The Location Based Billing (LBB) feature enables the network operator to configure SGSN to
generate partial S-CDRs when a Mobile changes routing areas (via intra-SGSN Routing Area
Update).
The advantage of this partial record generation scheme is that it gives the service provider the
flexibility to perform volume-based billing on a geographic location basis. Note that this feature
increases the number of partial S-CDRs generated by the SGSN (dependent upon MS mobility
characteristics). For this reason, Location Based Billing is an optional feature that is disabled by
default.
Roamer Only Billing
In the network where billing record is not required for the home users, the SGSN can be configured to
generate billing records for the incoming roamers only.
6.27 Signaling IP Traffic Management

To assist the IP network in managing the priority of the signaling traffic leaving the MME and the
SGSN, the vMME provides the capability for the operator to define a DSCP mark on a per interface


125
basis. This allows the IP backbone in the network to apply proper Per-Hop-Behavior when the IP
traffic passes through.
6.28 1x CSFB Id to eNodeB Mapping

This feature allows a persistent mapping of 1xCSFB IWS identifiers to eNodeBs from which
CDMA2000 uplink messages have been received. The mapping survives an MME reset. The function
facilitates a more focused paging area for delivering 1xCSFB page message to a UE after an MME
reset.
6.29 Priority Paging for Emergency 1xCSFB Call

This feature makes use of the GEC (Global Emergency Call) bit received in the GCSNA (Generic
Circuit Services Notification Application) status over the S102 interface to provide high priority paging
over the S1-MME interface. This feature also incorporates an enhancement to the S1 interface
introduced in 3GPP Release 10. For emergency 1xCSFB messages, the MME will perform high
priority paging to the eNodeBs.
6.30 Multiple-SIM Sharing the Same MS-ISDN

This feature allows a small set of devices that share the MS-ISDN to attach and obtain service on the
MME or the SGSN. Further, the SGSN/MME will perform legal intercept for all the devices if the MSISDN is the target of a legal interception request.
6.31 Diameter Based Interface Future Compatibility

This feature allows the vMME to configure a list of AVPs that are not supported by the MME/SGSN
based on the current version of the 3GPP specifications and yet marked as mandatory by the peer. If
such an AVP is configured, the vMME would ignore the AVP instead of rejecting the incoming
request.
6.32 Single Radio Voice Call Continuity (SRVCC)

This feature implements the SRVCC functionality defined in TS 23.216 v10.5.0 and v11.11.0, TS
29.280 v10.4.0 and v11.6.0. SRVCC functionality enables a SRVCC-capable UE to seamlessly move
an active IMS voice call (in PS domain) from LTE coverage to legacy circuit domain.
The following types of SRVCC HO are supported by this feature:


126
E-UTRAN to GERAN without DTM support
E-UTRAN to GERAN with DTM without DTM HO
E-UTRAN to UTRAN without PS HO
E-UTRAN to UTRAN with PS HO
For SRVCC from E UTRAN to UTRAN/GERAN, the MME first receives the handover request (S1-AP
handover required message) from E UTRAN with the indication that this is for SRVCC handling. The
MME then triggers the SRVCC procedure with the MSC Server enhanced with SRVCC via the Sv
reference point. The MSC Server enhanced for SRVCC then initiates the session transfer procedure
to the IMS and coordinates it with the CS handover procedure to the target cell. The MSC Server
enhanced for SRVCC then sends a PS-CS handover Response to the MME, which includes the
necessary CS HO command information for the UE to access the UTRAN/GERAN.
Handling of any non voice PS bearer is done by the PS bearer splitting function in the MME. The
MME starts the handover of non voice PS bearer during SRVCC procedure based on the information
received from E UTRAN. The handover of non voice PS bearer(s), if performed, is done as according
to Inter RAT handover procedures. The MME is responsible for coordinating the Forward Relocation
Response from PS-PS handover procedure and the SRVCC PS to CS Response.
6.33 IMS Emergency Call

Emergency bearer services are functionalities provided by the network to support IMS emergency
sessions. This feature adds support for Emergency bearer services on the vMME. An emergency
bearer could be a default EPS bearer which was activated for emergency, or any dedicated EPS
bearer associated to this default EPS bearer.
A UE can request emergency services using one of the two available procedures:
E_UTRAN Initial Attach procedure with emergency indicators
PDN Connectivity procedure with emergency indicators
Emergency bearer services are provided to normal attached UEs and depending on local regulation
to UEs that are in limited service state. Receiving emergency services in limited service state does
not necessarily require a subscription. Depending on configured policy, the MME will allow or reject
an emergency attach request for UEs in limited service state. A UE that camps normally on a cell
without any conditions that result in limited service state, initiates a normal initial attach procedure, if
not already attached. The normally attached UE then initiates the UE Requested PDN Connectivity
procedure to receive emergency bearer services. From the MMEs perspective, a UE is considered
emergency attached if it has only one PDN connection and that PDN connection is setup for
emergency bearer services.
Emergency Service is not a subscription service. If a UE roams out of its home network, emergency
services are not provided by the home network, but instead are administered by the visited network,


127
as long as the visited network supports emergency services. If a UE has sufficient credentials, it may
require the involvement of the home network depending on the configured option.
The MME allows the following four different flavors of emergency bearer support:
Valid UEs only: Only UEs that have a valid subscription, are authenticated and authorized for PS
service in the attached location are allowed.
Only UEs that are authenticated are allowed: These UEs must have a valid IMSI. A UE that
cannot be authenticated is rejected.
IMSI required, authentication optional: These UEs must have an IMSI. If authentication fails, the
UE is still granted access and IMEI is used in the network as the UE identifier. IMEI only UEs are
rejected (e.g., UICCless UEs).
All UEs are allowed: Authenticated UEs, unauthenticated UEs with IMSI and IMEI only UEs are
supported. If an IMSI based UE fails authentication, it is granted access and IMEI is used in the
network as that UEs identifier.
In addition to the above configured options, there is an option for the operator to turn off
authentication for options 3 (IMSI required, authentication optional) and 4 (all UEs are allowed) above
to reduce additional messaging during attach onto the MME.
6.34 VoLTE Support

This feature expands the functionality of IMS voice support on the MME/S4-SGSN.
IP Multimedia Subsystem (IMS) is a standardized architecture for telecom operators that want to
provide mobile and fixed multimedia services. It uses a Voice-over-IP (VoIP) implementation based
on a 3GPP standardized implementation of Session Initiation Protocol (SIP), and runs over the
standard Internet Protocol (IP). An example use of IMS is Voice over LTE: the LTE standard only
supports packet switching (PS) with its all-IP network; voice calls in GSM, UMTS and CDMA2000 are
circuit switched (CS), with the adoption of LTE, carriers have to re-engineer their voice call networks
to transfer voice traffic over LTE.
IMS voice support for LTE was introduced in an earlier release, but recently had the following
enhancements to the IMS support functionality as follows:
Separated ims-voice configuration for the MME and the SGSN with attributes to indicate nodal
IMS voice supportability.
UE using HLR is not allowed to have IMS voice access on the S4-SGSN, i.e., IMS voice over PS
Session Indicator should not be set to 1 in the Network Feature Support IE of the Attach
Accept or RAU Accept to the UE.
Addition of per-PLMN configuration of IMS voice supportability. This configuration can override
the nodal IMS supportability configuration, it can affect the following areas:


128
The value of IMS voice over PS session Indicator in the IE EPS Network Feature
Support in the Attach Accept or TAU Accept for the MME or in the IE Network Feature
Support in the Attach Accept or RAU Accept for the S4-SGSN
Homogeneous Support of IMS Voice over PS Sessions AVP in Update Location

Request (ULR)
Support of following AVPs and configuration for the S6 interface:
AVPs IMS Voice over PS sessions Supported, Last UE Activity Time, and RAT Type
in Insert Subscriber Data Answer (IDA), these three AVPs are considered T-ADS
(Terminating Access Domain Selection) data
AVP Homogeneous Support of IMS Voice over PS Sessions in Update Location

Request for the MME
T-ADS data retrieval flag in Supported Feature AVP in the ULR and IDA
T-ADS data retrieval control on the MME/S4-SGSN
Addition of the control of the number of IMS voice bearers per UE for the MME and the S4-SGSN
Addition of new paging configuration for IMS voice calls (QCI=1 or QCI=5) for the MME
Capability to select whether the s5-gtp protocol should be used for PDN connections used for
VoLTE for home subscribers as well, local breakout for roam-in UEs
6.35 Femto Cell Support

This feature enables support for interconnecting the MME and SGSN to an HeNB GW or HNB GW
respectively with the purpose of supporting HeNBs and HNBs. The H(e)NB GW is generically referred
to as the Femto Gateway (FGW). The MME/SGSN is updated to support the functionality associated
with the H(e)NBs which includes Closed Subscriber Groups (CSG) and Local IP Access (LIPA). Note
that HeNBs can be directly connected to the MME, but they will be treated the same as a macro
eNBs (with the exception that macro eNB does not support CSG); HNBs cannot be directly connected
to the SGSN since HNBs use the Iuh protocol instead of the Iu protocol.
The FGW appears to the MME/SGSN like a macro eNB/RNC (note the operator, through
provisioning, must identify a FGW for system engineering reasons). The principle difference between
a FGW and macro eNB/RNC is that the FGW is a concentrator for many H(e)NBs. The volume of S1
transaction over a given FGW association can be considerably larger than that from a macro eNB.
The following MME 3GPP interfaces are updated: S6, S1 and S11/S10.
The following SGSN 3GPP interfaces are updated: Gr, Iu, Gn, S4, Ga and Ge.
The MME and SGSN receive CSG Subscription information (CSG ID, Expiration Date, and a list of
LIPA APNs) along with LIPA permissions (roaming permission, and which APNs allow LIPA) from the


129
HSS and HLR over S6 and Gr respectively. The MME and SGSN store this information and use it to
control access of UEs from CSG cells.
The MME/SGSN validates whether a UE is allowed to access a CSG applicable femto cell during the
different mobility scenarios.
6.36 Multi-SIM Support

The IMSI is a number uniquely identifying s subscription in a mobile network. The MSISDN is a
number that is assigned to the subscription. Simply put, it is the telephone number to the SIM card in
a mobile/cellular phone.
The MSISDN together with the IMSI are two important numbers used to identify a mobile subscriber.
The latter identifies the SIM (the card inserted into the mobile phone), while the former is used for
touring calls to the subscriber. IMSI is often used as a key in the HLR (subscriber database) and
MSISDN is the number normally dialed to connect calls to the mobile phone. The SIM is uniquely
associated to an IMSI, while the MSISDN can change in time (due to number portability); different
MSISDNs can be associated to the SIM.
This feature allows more than one IMSI, using the same MSISDN number to attach to the SGSN.
This feature also supports Lawful Interception (LI) for dual or multiple IMSIs that use the same IMEI.
In practice there can be multiple MSs attached to an SGSN/MME using the same MSISDN with
different IMSIs. Operators create ringing groups of more than one IMSI, all with the same MSISDN
number in the HLR. Operators control feature activation by creating or removing ringing groups from
the HLR. With this feature, the SGSN/MME can accept an Attach from more than one MS with the
same MSISDN. This feature also supports a single device (IMEI) that contains multiple IMSIs
(multiple SIM cards).
6.37 Camel Support and Enhancements

This feature authenticates the CAMEL Phase 3 sourcing implemented in an earlier release and added
3GPP Rel 10 support for Location Information for GPRS (LocationInformationGPRS). Location
Information for GPRS is used to indicate CGI/SAI/RAI of where the MS is currently located. The
LocationInformationGPRS IE will hold the location information for GPRS. Tariff Switch functionality
was introduced as an addendum to the existing CAMEL Phase 3 functionality. This allows the
operator increased flexibility in the prepaid tariff structure by supporting more than one tariff rate.
Without it, the operator is confined to offering a flat rate for prepaid data.


130
6.38 Sigtran Enhancements

SIGTRAN provides a signaling transport over an IP network for Gr, Gs, Ge, Gd and Gf interfaces. It
enables direct communications to SS7 signaling nodes in both SGP and IPSP modes and allows for
greater signaling capacity through using IP-based technologies.
The SIGTRAN interface is provided for SCCP-based signaling interfaces from the SGSN. These
interfaces include the Gr, Gs, Ge, Gd and Gf interfaces to HLR, MSC/VLR, SCP, SMS-C and EIR
nodes. GPRS or UMTS networks are supported using ANSI and ITU SCCP signaling protocols.
SIGTRAN provides SCCP connectionless services (class 0 and class 1) as required by these
interfaces.
This feature provides the following high level functionalities:
The SS7 congestion control is enhanced under current system overload control architecture.
The capability is added to specify the subsystem numbers for each 3GPP subsystems configured
on the SGSN.
ASP sends SCON to peers when congestion level on receiver buffer passes configured
threshold.
The SIGTRAN process (ASP) sheds traffic based on the local subsystems and the configured
importance levels in case of congestion/overload.
An option is provided to configure the reconnect timer for ASP to establish the association with
applicable peers.
6.39 Unknown RAI Reporting

The purpose of this feature is to inform the operator when an unknown Routing Area Identity (RAI) is
received by the SGSN. This feature enhances the SGSN to raise an alarm when a mobility message
is received with an unknown RAI. The SGSN records an unknown RAI if it receives a mobility
message where either an RAI is not configured on the SGSN or an RAI which is known, but does not
match the RNC ID or NSE ID configured against that particular RAI. The alarm is periodically reissued when there are unresolved RAIs. CLI was updated so that operators can list the 50 most
recent unknown RAIs. Note that if there are more than 50 mismatches, the operator needs to
continue to issue the cli command to display the table contents, until all the mismatches are resolved.
6.40 Multimedia Priority Service

This feature introduced Multimedia Priority Service (MPS) on the MME. During emergency type
situations such as floods, hurricanes, earthquakes, terrorist attacks, etc. government and emergency
officials and other authorized users may rely on the public network services for communication. MPS
allows authorized users to obtain priority treatment over normal users by providing priority access to

131
the next available radio resource on a priority basis before normal users. MPS also allows authorized
users the ability to communicate during congestion conditions when session and bearer
establishment attempts are normally blocked.
6.41 HSS and PCC Based Network Provided Location

Information
Currently the User Equipment (UE) provides the location information, but this information may be
untrustworthy because it may have been tampered with. This feature implements Network Provided
Location Information (NPLI) which is considered more accurate. NPLI is useful during Lawful
interception, Charging, IMS emergency calls routing, Retention of location information data, Special
call routing for localized services and Location-based service triggering. The NPLI consists of Cell
Global Identity (CGI), Closed Subscriber Group Identity (CSGID) and Geographical Identifier (GI),
Public Land Mobile Network identifier (PLMN ID), UE time zone etc.
This feature introduces the following NPLI mechanisms on the MME/SGSN:
HSS based NPLI retrieval
PCC based NPLI retrieval
6.42 S6d Override Support and Enhancements

This feature enhances the ability of a Combined MME/S4-SGSN or a stand-alone S4-SGSN to
retrieve authentication information over the Gr interface for an EPC subscriber located in a
GERAN/UTRAN coverage area, and then to retrieve subscription information for the EPC capable
subscriber over the S6a interface. This can be used by an operator who has an HSS deployment that
does not support the S6d interface. This feature also provides the flexibility to retry the authentication
or subscription information over Gr interface, if the attempt to retrieve over S6 interface fails. The
operator control for this feature is provided on a per IMSI range basis.
6.43 Non Responsive PGW Quarantine

This feature enables the MME to remove a PGW from PGW selection for new sessions for a period of
time which is configurable. When the MME receives a create session response message with a
cause of remote peer not responding with a CS bit of 0, the MME removes that particular PGW
selection. This function is controlled by a configuration parameter. This feature only applies to GTP
based PGWs.


132
6.44 GW Blacklisting Enhancements

This feature allows operators to manually blacklist SGWs and PGWs, as well improves the GW
selection process by dynamically detecting failed SGWs and PGWs. This is accomplished by:
Path Failure Detection Dynamically blacklists a failed SGW or PGW.
Path Failure Handling Improves the S11 path failure handling by allowing the MME to
proactively resuscitate the failed SGW. For an echo-based SGW, the MME frequently probes the
peer with echo requests. For an echo-less SGW the MME allows one outstanding transaction
with the SGW.
Configuration Allows the operator to manually blacklist SGWs and PGWs so that the MME
does not attempt to create a new session on them.
Selection Process Allows the MME to select the SGW/PGW by filtering out the blacklisted
SGW/PGW. Further, the MME excludes failed GWs in the selection. If there are no SGW/PGW
available for selection, then the MME performs normal GW selection including the failed GW in
the selection list (but excluding the manually blacklisted GW).
6.45 Location Service

EPC Location Service on the MME furnishes users with information regarding the physical location of
a UE. This positioning information is typically used by the following:
Value added services LCS (LoCation Service) Clients use LCS to support various value added
services. These clients can include UE subscribers as well as non-subscribers to other services.
PLMN Operator LCS Clients use LCS to enhance or support certain O&M related tasks,
supplementary services, IN related services and bearer services and teleservices.
Emergency Services LCS Clients use LCS to enhance support for emergency calls from
subscribers.
Lawful Intercept LCS clients use LCS to support various legally required or sanctioned services.
LCS is applicable to any target UE whether or not the UE supports LCS, but with restrictions on the
choice of positioning method or notification of a location request to the UE user. LCS is also
applicable to an unauthorized UE in the emergency cases.
The vMME also allows an operator to determine if location service for roamers should be allowed for
the incoming roamers.
This feature is supported on the MME only.


133
6.46 TAC level service control

This feature allows the operator to control the introduction of services such as IMS voice, Emergency
etc on a per Tracking Area basis. Additionally, this feature also allows one vMME to support multiple
time zones. The operator can define the time zone for each tracking area and each routing area
supported on the vMME.


134
7 Carrier Grade Capabilities

As a node that hosts millions of mobile subscribers, the vMME is designed to meet or exceed
99.999% availability. From the platform hardware and software perspective, all active functions are
deployed with redundancy.
At the application layer, both 1:1 redundancy and N-way load-sharing redundancy are used to provide
the needed reliability for the MME and the SGSN. Additionally, there is also comprehensive overload
controls on the MME to ensure it functions at or above the industry standard with regard to Telecom
equipment during mass call events and other overload conditions.
7.1 Redundancy
The vMME supports 1:1 sparing for the Management VM, the Resource Manager VM and the CallP
VM. For the Signaling VM, the Data VM and the SLB VM, N-way load-sharing redundancy is used.
For the software running on the 1:1 spared virtual machines, synchronization for subscriber data as
well as critical internal data is achieved via proprietary data journaling mechanism.
For the software running on the N-way load-sharing virtual machines, recovery action is taken by the
vMME to migrate any impacted peer nodes or subscriber sessions to other surviving virtual machines
when the failure of a virtual machine is detected.
For all the application using SCTP as transport, the MME/SGSN supports SCTP multi-home to
enhance the transport layer redundancy. The supported multiple home configurations include dual
local IP, single peer IP; dual peer IP and single local IP; dual local IP and dual peer IP.
For the SCTP based interface where the MME acts as the server, namely, the S1 interface and the
SBc interface. The MME ensures that the SCTP association with the peer is maintained up a failure
(including managed shutdown of the service). For example, in the case of the S1 interface, when a
SIG VM fails or is shutdown, the Resource Manager VM would co-ordinate the migration of the SCTP
associations on the failed VM to other surviving VMs. The receiving VM would perform SCTP INIT
procedure to ensure that the peer maintains the SCTP association.
7.2 Overload Control

The vMME supports a set of overload control mechanisms to ensure proper operation of the MME
and the SGSN under any overload conditions. The general guidance for the overload design is based
on the ITU specification on performance design objectives for a switching system ITU-T Q.543. The
high level function is as follows:
Monitor system resources and report overload conditions
Trigger abatement actions when certain resources are over-subscribed


135
Carrier Grade Capabilities
The following resources are monitored at the application component level. For these resources, direct
abatement actions can be defined to recover from the overload condition.
Bearer Capacity or PDP context capacity: This resource is applicable to the Subscriber Control
on the CallP VM. When the total number of bearers (including both default and dedicated, or PDP
contexts) exceeds configured thresholds, the Subscriber Control function generates alarm and
trigger abatement actions. For a combined MME/SGSN, a bearer and a PDP context counts
towards the bearer capacity for overload control purpose.
Processing Capacity: This resource applies to SC (Subscriber Control) applications on the MME
and the SGSN. Each application will use its local buffer usage to determine its congestion level.
The buffer monitored can be the local buffer and/or transaction buffer at the application layer. The
configured abatement action is taken by the Subscriber Control as it is the function that performs
admission control for the subscribers. Additionally, the congestion level of all SCs will be
monitored to determine the overall MME/SGSN congestion level. When the MME/SGSN is in
congestion, configured abatement actions will be taken. In the case of MME, two additional
system wide abatement actions can be taken. One is to use MME Configuration Update to inform
the new MME capacity is 0 to avoid receiving additional new UEs. Second, S1 Overload Start and
S1 Overload Stop messages can be triggers to inform the eNodeBs to reduce the rate of
incoming messages.
Subscriber Capacity: This resource is applicable to the SC application on the MME and the
SGSN. The subscriber capacity level of the individual SC applications is monitored to determine
the overall MME subscriber level. Configured abatement actions are taken when the MME/SGSN
is in subscriber overload. This resource is applicable to the Subscriber Control (SC) on the
MME/SGSN. When the number of attached subscribers reaches configured thresholds, the
Subscriber Control function generates alarm and trigger abatement actions on a per MPU basis
(on every MPU where Subscriber Control is configured).
Paging Capacity: This resource is used to control the paging rate delivered to the Access Nodes
(eNodeBs, RNCs and BSSs). The main purpose for this is to protect the access nodes to ensure
that the paging channel is not over flooded. The paging rate of all the SC function is monitored to
determine the MME/SGSN paging overload level. When the MME/SGSN is in paging overload,
abatement actions are taken.
7.3 SON Support

SON stands for Self Organizing, or Self Optimizing Networks. It is a feature used to reduce the
complexity and the associated cost of managing a large wireless network. The need for SON
becomes more acute with the advent of the flattened EPS network architecture. The high number of
access nodes that need to connect to the core network becomes a management burden. While the
capability for SON is more imperative for the access nodes, it is also important for the core node. The
vMME provides a set of functionalities to help reduce the management cost of the network:
Dynamic eNodeB configuration: The MME supports the dynamic setup of the eNodeBs. The only
information the operator needs to configure on the MME is the PLMN of the serving area. The
MME automatically acquires the eNodeB identifiers and the tracking area information from the

136
Carrier Grade Capabilities
eNodeBs. Further, the MME informs the eNodeBs about its relative capacity which the eNodeBs
use to load-balance all the MMEs belonging to the same pool.
EnodeB configuration transfer: The MME assists the eNodeBs by passing SON related
information received from the source eNodeB to the target eNodeB.
Peer node reset handling: The vMME automatically reacts to the failure or reset of the nodes it
interacts with. Actions are taken to ensure the service to the UE is not interrupted or is restored
properly. The rate of the action taken is checked instead of all-at-once to avoid congestion in the
network. The failure or reset of the following peer nodes are handled:
eNodeB: The impacted UEs are moved to ECM-IDLE state.
SGW: The vMME deactivates the PDN connections or the PDP contexts for the UE upon
the failure of the SGW.
HSS: The vMME performs ULR procedure with the HSS after it recovers for all the
impacted UEs.
VLR: The vMME performs Location Update Procedures for impacted UEs after the
RESET indication is received from the failed VLR.
HLR: The SGSN perform Update Gprs Location with the HLR after it recovers for all the
impacted UEs. This is applicable to the Gn SGSN.
RNC: The impacted UEs are moved to PMM-IDLE state.
GGSN: The SGSN deactivates the PDP contexts for the UE upon the failure of the
GGSN.
7.4 In-service Upgrade

The vMME can be upgraded while maintaining service.
MME/SGSN in-service upgrade leverages the 1:1 redundancy of many Call Processing VMs, and the
N+1 over engineering of others to avoid impact to subscribers while performing software upgrades.
As such, it is effectively a VM at a time procedure, with some VM reloads occurring in parallel.
Software download to the node may be performed by SFTP at any time while it is in service. The
upgrade procedure should be scheduled for an off-peak maintenance window of at least two hours in
duration.
7.5 In-service Patching

The vMME allows software updates (patches) to be applied while maintaining services to the
subscribers. The procedure is the same as an upgrade, but only the VM resident software patch
version is incremented.

137
8 Operation, Admin and Maintenance Capabilities

This section provides an overview of the OA&M capabilities. The reader is referred to the user guides
and reference guides included in the document map.
8.1 Configuration Management

vMME configuration is based on the hierarchical system of objects. The organization is intended to
promote maximum re-use of entities between MME and SGSN, and logical presentation of interfaces
and other aspects based on the treatment in the 3GPP standards. In this release, the vMME has over
120 configuration object types. The major groupings are:
mme-sgsn
system
engineering
feature
imsi-routing
interface
s1
iu
gb
s6
gr
etc
service-area
plmn
etc
subscriber
mobile-context
etc
csl

138
Operation, Admin and Mgmt Capabilities
dns
trace
8.2 Fault Management

vMME formally modeled alarms and logs are organized by application (service, such as SC for
subscriber control). For each application, the alarms and logs are numbered by an index. Multiple
instances of the same app/index alarm are distinguished by entity tag fields which indicate the service
and unit number that originated the alarm.
For example, the S1 master application of the Resource Manager VM is application id 2043, and
alarm index 1306 for that application is "One or more enodeBs are no longer reachable".
In this release, the vMME has over 128 alarms and 44 logs.
8.3 Performance Management

vMME Performance Management is organized into a three level hierarchy composed of groupset,
group, and register. The groupset is used to organize the PM by interface or application, and the
group is typically used to denote the procedure of sub-function. In this release, the vMME has over
140 groups comprised of over 2000 unique registers (which may have multiple instances). Register
types are:
CC (cumulative) reset to zero on collection period, except for CLI version
INST (gauge) instantaneous sample
SI (min/max/avg) per collection period, sampled every 20 seconds
Naming and organization follows 3GPP 32.406 and 32.426 where a clear precedent is set.
The groupset/groups of 8.2 are shown in the following table.
Table 49.
Group Sets and Groups
Group Set
Group
Application
Cardinality
Technology
cdma
sc
SC
10
LTE/CDMA
diameter
general
DC
10
LTE
diameter
msg
DC
10
LTE
dns
dns
SC
10
ALL
fxa
sc
SC
10
LTE
fxa
upm
UPM
20
LTE
fxaPeer
upm
UPM
128
LTE


139
Group Set
Group
Application
Cardinality
Technology
ga
msg
GA
GPRS/UMTS
gb
bssgp
GB
1200
GPRS
gb
llc
SD
16
GPRS
gb
nsfr
GB
1200
GPRS
gb
nsip
GB
1200
GPRS
gb
sndcp
SD
16
GPRS
gprsMm
attach
SC
10
GPRS
gprsMm
attachFail
SC
10
GPRS
gprsMm
detach
SC
10
GPRS
gprsMm
general
SC
10
GPRS
gprsMm
irau
SC
10
GPRS
gprsMm
irauFail
SC
10
GPRS
gprsMm
misc
SC
10
GPRS
gprsMm
procedure
SC
10
GPRS
gprsMm
rau
SC
10
GPRS
gprsMm
rauFail
SC
10
GPRS
gprsMm
security
SC
10
GPRS
gprsMm
snr
SC
10
GPRS
gprsMm
camel
SC
10
GPRS
gprsSm
deactivation
SC
10
GPRS
gprsSm
general
SC
10
GPRS
gprsSm
irau
SC
10
GPRS
gprsSm
irauFail
SC
10
GPRS
gprsSm
modify
SC
10
GPRS
gprsSm
priActGgsnFail
SC
10
GPRS
gprsSm
primaryAct
SC
10
GPRS
gprsSm
primaryActFail
SC
10
GPRS
gprsSm
procedure
SC
10
GPRS
gtpV1
accessFlex
UPM
20
ALL
gtpV1
general
UPM
20
ALL
gtpV1
mobility
UPM
20
ALL
gtpV1
path
UPM
20
ALL
gtpV1
tunnel
UPM
20
ALL
gtpV1Path
accessFlex
UPM
1000
ALL
gtpV1Path
mobility
UPM
1000
ALL


140
Group Set
Group
Application
Cardinality
Technology
gtpV1Path
path
UPM
1000
ALL
gtpV1Path
tunnel
UPM
1000
ALL
gtpV2
general
UPM
20
ALL
gtpV2
mobility
UPM
20
ALL
gtpV2
path
UPM
20
ALL
gtpV2
tunnel
UPM
20
ALL
gtpV2Path
mobility
UPM
2000
ALL
gtpV2Path
mobilitySrvcc
UPM
2000
ALL
gtpV2Path
path
UPM
3000
ALL
gtpV2Path
tunnel
UPM
1000
ALL
iu
m3ua
IPSP
16
UMTS
iu
ranap
SC
10
UMTS
iu
Sccp
IU
4096
UMTS
lteHandover
interRat
SC
10
LTE
lteHandover
intraRat
SC
10
LTE
lteHandover
Srvcc
SC
10
LTE
lteMm
attach
SC
10
LTE
lteMm
attachFail
SC
10
LTE
lteMm
detach
SC
10
LTE
lteMm
general
SC
10
LTE
lteMm
itau
SC
10
LTE
lteMm
itaufail
SC
10
LTE
lteMm
paging
SC
10
LTE
lteMm
procedure
SC
10
LTE
lteMm
security
SC
10
LTE
lteMm
serviceRequest
SC
10
LTE
lteMm
Snr
SC
10
LTE
lteMm
tau
SC
10
LTE
lteMm
tauFail
SC
10
LTE
lteSm
bearerActFail
SC
10
LTE
lteSm
Deact
SC
10
LTE
lteSm
eRab
SC
10
LTE
lteSm
general
SC
10
LTE
lteSm
pgwReloc
SC
10
LTE
lteSm
procedure
SC
10
LTE


141
Group Set
Group
Application
Cardinality
Technology
lteSm
sessionAct
SC
10
LTE
lteSm
sessionActFail
SC
10
LTE
lteSm
sgwReloc
SC
10
LTE
nodal
s1
S1M
LTE/FGW
nodal
s1Mme
S1M
LTE/FGW
nodal
Upsm
RM
ALL
s1
Enb
S1
20
LTE
s1
general
S1
20
LTE
s1
Msg
S1
20
LTE
s101
general
UPM
20
LTE/CDMA
s101
Msg
UPM
20
LTE/CDMA
s102
general
UPM
20
LTE/CDMA
s102
Msg
UPM
20
LTE/CDMA
s13
Sc
SC
10
LTE
s1Enb
Enb
S1
15000
LTE
s1Enb
Msg
S1
15000
LTE
s6
s6
DC
10
LTE
s6
Sc
SC
10
LTE
sbc
Sbc
SBC
LTE
sc
loadControl
SC
160
ALL
sc
Npli
SC
10
ALL
sc
Rim
SC
10
ALL
sc
Sms
SC
10
GPRS
sc
uePurge
SC
10
ALL
sd
general
SD
16
GPRS/UMTS
sd
Relay
SD
16
GPRS/UMTS
sGs
detach
SGS
64
LTE
sGs
Failure
SC
10
LTE
sGs
general
SGS
64
LTE
sGs
procedure
SGS
64
LTE
sGs
vlrSelection
SC
10
LTE
sgsnAcct
abnormalClosure
SC
10
GPRS/UMTS
sgsnAcct
mcdr
SC
10
GPRS/UMTS
sgsnAcct
scdr
SC
10
GPRS/UMTS
sgsnAcct
smsCdr
SC
10
GPRS/UMTS


142
Group Set
Group
Application
Cardinality
Technology
ss7
Bssap
SC
10
GPRS/UMTS
ss7
Cap
SC
10
GPRS/UMTS
ss7
m3ua
SIGTRAN
16
GPRS/UMTS
ss7
Map
SC
10
GPRS/UMTS
ss7
Sccp
SIGTRAN
16
GPRS/UMTS
ss7
Tcap
TCAP
16
GPRS/UMTS
umtsHandover
interRat
SC
10
UMTS
umtsHandover
intraRat
SC
10
UMTS
umtsMm
Attach
SC
10
UMTS
umtsMm
attachFail
SC
10
UMTS
umtsMm
detach
SC
10
UMTS
umtsMm
general
SC
10
UMTS
umtsMm
Irau
SC
10
UMTS
umtsMm
irauFail
SC
10
UMTS
umtsMm
Misc
SC
10
UMTS
umtsMm
procedure
SC
10
UMTS
umtsMm
Rau
SC
10
UMTS
umtsMm
rauFail
SC
10
UMTS
umtsMm
security
SC
10
UMTS
umtsMm
Snr
SC
10
UMTS
umtsSm
camel
SC
10
UMTS
umtsSm
deactivation
SC
10
UMTS
umtsSm
general
SC
10
UMTS
umtsSm
Irau
SC
10
UMTS
umtsSm
irauFail
SC
10
UMTS
umtsSm
modify
SC
10
UMTS
umtsSm
priActGgsnFail
SC
10
UMTS
umtsSm
primaryAct
SC
10
UMTS
umtsSm
primaryActFail
SC
10
UMTS
umtsSm
procedure
SC
10
UMTS
X2
LI
LTE


143
8.4 CLI
In addition to the config modeling, the vMME has over 40 operational commands that are used to
check status (show) or initiate an action (request). These commands are invoked on the active
MGMT VM and automatically dispatched to the applicable VM. The response is presented back at the
MGMT VM CLI. The response is presented back at the CLI. Examples of operational commands
include:
show mme-sgsn status system
show mme-sgsn status storage
show mme-sgsn interface s1 enb
show mme-sgsn interface iu rnc
show mme-sgsn interface gb nse
show mme-sgsn interface gtp path
show mme-sgsn status lte
request mme-sgsn subscriber page imsi 1234567890
request mme-sgsn callp shutdown service 1 unit 0
request mme-sgsn dns dynamic-cache flush
etc


144
9 Security Capabilities
SGSN/MME security is based on configurable users and groups as defined by an extended version of
IETF RFC 6536 (NACM) that applies not only to the NETCONF interface but also to the CLI and WEB
interfaces. Groups are used to control permissions to read/write/exec in specified areas of the
system.
The pre-defined groups are:
admin: can view/change all configuration except for lea
lea: can view all configuration except for nacm/aaa; can perform request commands only on lea
operator: can view/change all configuration except for lea and nacm/aaa
viewer: can only view configuration and operational data, but cannot perform request commands


145
10 Capacity
The vMME offers market leading capacity. We have discussed many of the metrics already in prior
sections, particularly in the Summary. In this section, we summarize the key capacity and
performance metrics of the vMME in the following two tables. The first table captures the nodal level
capacity. The second table captures the per subscriber maximum. Note, the system capacity only
reflects the verified capacity. In the virtualized environment, the capacity can be expanded with
additional verification. No additional software change is required.
Table 50.
System Capacity and Performance
Metric Name
Maximum Value
Attached Subscribers
4,160,000
PDN Connections
8,320,000
Bearers (includes default and dedicated)
12,480,000
Tracking Areas
32,000
Routing Areas
3,000
2G Access Fan Out: NSE
600
2G Access Fan Out: Cells
30,000
3G Access Fan Out: RNC
4,096
4G Access Fan Out: eNodeB
25,000
CDMA HRPD Access Fan Out: eAN
15,000
Table 51.
Per Subscriber Capacity
Metric Name
Maximum Value
Number of unused authentication vectors
Number of bearers (including default and dedicated)
Number of dedicated bearers
Number of APN subscribed
10
Number of PDP Contexts


146
11 Specification Compliance
The MME and SGSN interfaces are compliant to the March 2013 version of the Release 10
specifications. Further, each interface has an attribute to allow the operator to control the version of
the interface used by the node. The operator can use the latest version when the related network
nodes are ready to utilize the new version of the related protocols.


147
12 Deployment Examples
With the flexibility of the vMME, the node can be deployed in many different network configurations.
In this section, we will provide a few examples to show how the vMME can be deployed. Please note,
the examples below only showcases a few use cases. They are not meant to be exhaustive.
12.1 Stand-alone MME for a green field LTE operator

Let us assume the following requirements for the network:
Target: five million subscribers
15,000 eNodeBs
Voice call via IMS instead of legacy circuit domain
Legal Intercept required by the government
Warning system required by the government
Support roamers (incoming and outgoing)
Support of equipment verification
Deployment suggestion:
Minimum of two vMMEs to form a pool. Both nodes are connected to the 15,000 eNodeBs.
A third vMME can be considered to provide network level redundancy.
Interface required on the MME: S6a, S1, S11, S10, S13, SBc, X.
Additionally, Gn/Gp and S3 are needed for roaming purpose (interaction with other PLMNs
network).
Given multiple MME nodes are used, a DNS server is recommended.


148
Deployment Examples
Figure 43. Deployment example 1 Network Level View

DNS
server
LIG
EIR
SGW
pool
HSS
eNodeBs
PGWs
Core
IP
netw
ork
Access
IP
network
PCRF
IpSec
Gateway
MME
pool
IpSec
Gateway
To other
PLMNs
core IP
network
Internet /IMS
domain


149
Deployment Examples
Figure 44. Deployment example 1 Nodal level view
S4-SGSN
Gn-SGSN
S3
MME
Gn/Gp
LIG
S10
S13
EIR
DNS
HSS
S6
MME
UE
SBc
CBC
S11
LTE-Uu
S1-MME
EUTRAN
S5/S8
S1-U
Serving Gateway
PDN Gateway
12.2 Combined MME/SGSN for a G/U operator

Target: 1 million subscribers
4,000 eNodeBs
40 3G RNCs
20 2G BSSs
GTPv2 used for signaling within the PLMN
Voice call via existing voice network


150
Deployment Examples
Legal Intercept required by government
A single vMME node is sufficient for the entire coverage area.
A second vMME can be considered to provide network level redundancy unless the access
nodes do not support access sharing (Gb Flex, Iu Flex and S1 Flex).
Interface required on the MME/SGSN: S6a, S1, SGs, S4, S11, X, Gb, Iu and Gs.
Additionally, Gn/Gp, S3/S10/S16 and Gr are needed for roaming purpose (interaction with other
PLMNs network).
A DNS server is optional. Local static configuration can be used. A DNS server helps roaming
cases (allow roaming partners DNS server to retrieve records).


151
Deployment Examples
Figure 45. Deployment example 2 Nodal level view
S4-SGSN
Gn-SGSN
S3/S16
MME
Gn/Gp
LIG
S10/S3
GERAN
SGs/Gs
Um
Uu
UE
VLR
Gb
MME/SGSN
lu-PS
S13
UTRAN
EIR
-M
S1
Gr
LTE-Uu
HLR
Gn/Gp
EUTRAN
S6
HSS
ct
re l
di nne
tu
S4/S11
S1-U
GGSN
S12
S5/S8
Serving Gateway
PDN Gateway


152
Deployment Examples
12.3 Stand-alone MME for a CDMA Operator

Target: 20 million subscribers currently on CDMA to be moved to 4G
50,000 eNodeBs
30,000 eANs
GTPv2 used for signaling within the PLMN
Voice call via existing CDMA voice network (CSFB to 1xRTT)
Warning system required by the government
Equipment verification is required
Support roamers (for 4G LTE subscribers only, no need to interact with legacy MAP based
network
Divide the network into two service areas, each forms its own pool.
Within each pool, one vMME per pool at minimum. Deploy another vMME per pool to provide
network level redundancy.
Interface required on the MME: S6a, S1, S11, S13, SBc, S101 and S102.
Multiple DNS servers are required given the number of nodes in the network.


153
Deployment Examples
Deployment example 3 Nodal level view
Figure 46.
DNS
MME
S10
IWS
S102
eAN
S101
S13
EIR
MME/SGSN
UE
S6
HSS
S1-MME
LTE-Uu
SBc
EUTRAN
S1-U
CBC
S11
S5/S8
Serving Gateway
PDN Gateway
12.4 Stand-alone Gn SGSN for a UMTS only operator

Target: 10 million subscribers
200 3G RNCs
Ability to migrate the network to EPS
Voice call via 3G UMTS voice network
Legal Intercept required by government
Device verification required


154
Deployment Examples
Direct tunnel for data traffic
Billing records are required for incoming roamers
A single SGSN pool using four vMMEs is sufficient for the entire coverage area provided the
RNCs are capable of connecting to four SGSNs. Otherwise, two separate pool each with 100
RNC nodes can be deployed.
Interface required on the SGSN: Iu, Gr, Gf, Gs, Gn/Gp.
A couple of DNS servers are recommended for redundancy purpose.

Deployment example 4 Nodal level view
Figure 47.
DNS
Gn-SGSN
LIG
Gn/Gp
CFG
Ga
Gs
VLR
Uu
UE
lu-PS
SGSN
Gf
UTRAN
EIR
Gn/Gp
direct tunnel
GGSN


155
13 8.2 Software Release Document Map

The following table lists the documents applicable to this release.
Table 52.
Documentation Map
Document Name
Document Number
vMME Product Overview [this document]
10-0100-082
vMME Product Overview Contrail Solution
20-0100-082
vMME Product Overview VMware Solution
20-0101-082
Release Notes
30-0600-082
vMME SGSN Billing Samples
10-0140-082
vMME Operators Guide
10-0200-082
vMME Operators Guide Contrail Solution
20-0200-082
vMME Operators Guide VMware Solution
20-0201-082
vMME Monitoring Guide
10-0130-082
vMME Configuration Management Reference Guide
10-0402-082
vMME CLI Reference Guide
10-0403-082
vMME CSL Reference Guide
10-0404-082
vMME Performance Management Reference Guide
10-0405-082
vMME Fault Management Reference Guide
10-0406-082
vMME CIQ Spec EXCEL TOOL
30-0300-082
vMME Engineering Guide
30-0500-082
vMME Engineering Guide Contrail Solution
30-0501-082
vMME Engineering Guide VMware Solution
30-0502-082
vMME Lawful Interception Interface Guide for Packet

Data
10-0150-082
vMME CLI User Guide
10-0420-082


156
14 References and Related Documents

14.1 Internal References
See 8.2 Software Release Document Map.
14.2 External References

14.2.1 Specification References
The following table lists the external specification references and related documents that are relevant
to this release.
Table 53.
External References and Related Documents (3GPP)
Document #
Document Title
Version
URL
TS 21.201
USIM and IC card requirements
9.2.0
http://3gpp.org/specifications
TS 22.016
International Mobile Equipment

Identities (IMEI)
9.0.1
TS 22.071
Location Services (LCS); Service

description stage 1
10.0.0
TS 22.278
Service requirements for the

Evolved Packet System (EPS)
9.6.0
TS 23.003
Numbering, addressing and

identification
10.6.0
Restoration procedures
10.7.0
TS 23.007
11.9.0
11.8.0
TS 23.015
Technical realization of Operator

Determined Barring (ODB)
10.0.0
TS 23.040
Technical realization of the Short

Message Service (SMS)
11.5.0
TS 23.041
Technical realization of Cell

Broadcast Service (CBS)
10.6.0
General Packet Radio Service

(GPRS); Service description;
Stage 2
10.11.0
Customised Applications for

Mobile network Enhanced Logic
11.3.0
TS 23.060
TS 23.078
11.3.0
11.6.0
11.12.0


157
References and Related Documents
Document #
Document Title
Version
URL
(CAMEL) Phase 3 - Stage 2

TS 23.107
Quality of Service (QoS) concept

and architecture
10.2.0
TS 23.167
IP Multimedia Subsystem (IMS)

emergency sessions
10.7.0
TS 23.203
Policy and charging control

architecture
9.7.0
TS 23.216
Single Radio Voice Call Continuity

(SRVCC); Stage 2
10.5.0
Architectural requirements
10.2.0
TS 23.221
11.11.0
11.3.0
TS 23.236
Intra-domain connection of Radio

Access Network (RAN) nodes to
multiple Core Network (CN) nodes
10.3.1
Functional stage 2 description of

Location Services (LCS)
10.4.0
Circuit Switched (CS) fallback in

Evolved Packet System (EPS)
10.10.0

(GPRS) enhancements for
Evolved Universal Terrestrial
Radio Access Network
10.10.0
TS 23.402
Architecture enhancements for

non-3GPP accesses
10.8.0
TS 24.007
Mobile radio interface signaling

layer 3; General Aspects
10.0.0
Mobile radio interface Layer 3

specification; Core network
protocols; Stage 3
9.5.0
TS 24.011
Point-to-Point (PP) Short Message

Service (SMS) support on mobile
radio interface
11.1.0
TS 24.030
Location Services (LCS);

Supplementary service operations;
Stage 3
10.0.0
TS 24.080
3rd Generation Partnership

Project; Technical Specification
Group Core Network and
Terminals; Mobile radio interface
layer 3 supplementary services
specification; Formats and coding
10.0.0
TS 23.271
TS 23.272
TS 23.401
TS 24.008
11.0.0
11.3.0
11.9.0
11.11.0
11.0.0
10.10.0
11.13.0
11.0.0


158
Document #
Document Title
Version
URL
TS 24.171
3rd Generation Partnership

Project; Technical Specification
Group Core Network and
Terminals; Control Plane Location
Services (LCS) procedures in the
Evolved Packet System
10.0.0
Non-Access Stratum (NAS)

Protocol for Evolved Packet
System (EPS)
9.5.0
TS 25.410
UTRAN Iu Interface: General

Aspects and Principles
11.0.0
TS 25.411
UTRAN Iu interface Layer 1
11.0.0
TS 25.412
UTRAN Iu interface signalling

transport
11.0.0
TS 25.413
UTRAN Iu Interface Radio Access

Network Application Part (RANAP)
signaling
9.5.0
TS 25.414
UTRAN Iu interface data transport

& transport signalling
11.0.0
TS 29.002
Mobile Application Part (MAP)

specification
9.4.0
TS 24.301
11.0.0
10.10.0
11.13.0
10.9.0
11.6.0
10.10.0
11.11.0
TS 29.016
Serving GPRS Support Node

SGSN - Visitors Location Register
(VLR); Gs Interface Network
Service Specification
11.0.0
TS 29.018

(SGSN) - Visitors Location
Register (VLR); Gs interface layer
3 specification
9.3.0
GPRS Tunneling Protocol (GTP)

across the Gn and Gp interface
9.5.0
TS 29.060
10.7.0
11.7.0
10.8.0
11.11.0
TS 29.078
CAMEL Application Part (CAP)

specification
9.2.0
10.0.0
11.2.0
TS 29.118
TS 29.168
Mobility Management Entity

(MME) Visitor Location Register
(VLR) SGs interface specification
9.3.0
Cell broadcast centre interfaces
9.3.0
10.7.0
11.11.0


159
Document #
Document Title
Version
with EPC
10.2.0
URL
11.4.0
TS 29.171
TS 29.172
LCS Application Protocol (LCSAP) between the Mobile

Management Entity (MME) and
Evolved Serving Mobile Location
Centre (E-SMLC); SLs interface
10.4.0
Evolved Packet Core (EPC) LCS

Protocol (ELP) between the
Gateway Mobile Location Centre
(GMLC) and the Mobile
Management Entity (MME);
10.1.0
11.3.0
11.1.0
SLg interface
TS 29.202
SGSN SS7 SIGNALLING

TRANSPORT IN CORE
NETWORK
11.0.0
TS 29.229
Cx and Dx interfaces based on the

Diameter protocol; Protocol details
9.3.0
TS 29.230
Diameter applications; 3GPP

specific codes and identifiers
10.9.0
TS 29.272

(MME) and Serving GPRS
Support Node (SGSN) related
interfaces based on Diameter
protocol (MME) and Serving
GPRS Support Node (SGSN)
related interfaces based on
Diameter protocol
9.5.0
Evolved General Packet Radio

Service (GPRS) Tunneling
Protocol for Control plane (GTPv2C
9.5.0
Optimized Handover Procedures

and Protocols between EUTRAN
Access and cdma2000 HRPD
Access
9.4.0
Optimized Handover Procedures

and Protocols between EUTRAN
Access and 1xRTT Access
9.1.0
3GPP Sv interface (MME to MSC,

and SGSN to MSC) for SRVCC
10.4.0
Tunnelling Protocol User Plane
10.3.0
TS 29.274
TS 29.276
TS 29.277
TS 29.280
TS 29.281
10.10.0
11.11.0
10.10.0
11.13.0
10.3.0
11.11.0
10.1.0
11.1.0
11.6.0


160
Document #
Document Title
Version
URL
10.4.0
(GTPv1-U)
TS 29.303
Domain Name System Procedures
11.3.0
TS 32.015
TS 32.240
3G call and event data for the

Packet Switched (PS) domain
9.6.1
Charging architecture and

principles
9.0.0
10.7.0
10.1.0
11.7.0
TS 32.251
TS 32.295
Packet Switched (PS) domain

charging
10.9.0
Charging Data Record (CDR)

transfer
9.0.0
11.10.0
10.0.0
11.0.0
TS 32.297
TS 32.298
Charging Data Record (CDR) file

format and transfer
9.0.0
Charging Data Record (CDR)

parameter description
9.6.0
10.2.0
10.12.0
11.12.0
TS 32.406
Telecommunication management;
Performance Management (PM);
Performance measurements; Core
Network (CN) Packet Switched
(PS) domain
11.4.0
TS 32.421
Subscriber and equipment trace;

Trace concepts and requirements
10.5.0

Trace control and configuration
management
10.11.0

Trace data definition and
management
10.5.0
Performance Management (PM)
Performance measurements
Evolved Packet Core (EPC)
network
10.4.0
TS 32.432
Performance measurement: File
format definition
11.0.0
TS 33.102
3G security; Security architecture
10.0.0
TS 32.422
TS 32.423
TS 32.426
11.6.0
11.11.0
11.8.0
11.4.0


161
Document #
Document Title
Version
URL
11.7.0
TS 33.106
Lawful interception requirements
10.0.0
TS 33.107
3G security; Lawful interception

architecture and functions
10.4.0
TS 33.210
3G security; Network Domain

Security (NDS); IP network layer
security
10.3.0
TS 33.310
Network Domain Security (NDS);

Authentication Framework (AF)
10.5.0
TS 33.401
Security Architecture
10.4.0
11.4.0
11.7.0
TS 331.08
3G security; Handover interface

for Lawful Interception
12.6.0
TS 35.215
Specification of the 3GPP

Confidentiality and Integrity
Algorithms UEA2 & UIA2;
Document 1: UEA2 and UIA2
specifications
9.0.0
TS 35.216

Document 2: SNOW 3G
specification
9.0.0
TS 35.217

Document 3: Implementers test
data
9.0.0
TS 35.218

Document 4: Design conformance
test data
9.0.0
TS 36.300

Radio Access (E-UTRA) and
Radio Access (E-UTRAN); Overall
description; Stage 2
10.9.0
Stage 2 functional specification of

User Equipment (UE) positioning
in E-UTRAN
10.5.0
10.4.0
TS 36.305
TS 36.401
11.12.0
11.3.0


162
Document #
Document Title
Version
Radio Access Network (EUTRAN); Architecture description
11.2.0

Radio Access Network (EUTRAN); S1 layer 1 general
aspects and principles
10.3.0

Radio Access Network (EUTRAN); S1 layer 1
10.1.0

Radio Access Network (EUTRAN); S1 signaling transport
10.1.0

Access (E-UTRAN) ; S1
Application Protocol (S1AP)
10.6.0
TS 36.440
General aspects and principles for

interfaces supporting Multimedia
Broadcast Multicast Service
(MBMS) within E-UTRAN
12.0.0
TS 36.441
Layer 1 for interfaces supporting

Multimedia Broadcast Multicast
Service (MBMS) within E-UTRAN
12.0.0
TS 36.442
Signalling Transport for interfaces

supporting Multimedia Broadcast
Multicast Service (MBMS) within
E-UTRAN
12.0.0
TS 36.444
M3 Application Protocol (M3AP)
12.1.0
TS 44.064
Logical Link Control (LLC) Layer

Specification
10.1.0
Subnetwork Dependent
Convergence Protocol (SNDCP)
10.0.0
TS 48.014

(GPRS); Base Station System
(BSS) - Serving GPRS Support
Node (SGSN) interface; Gb
Interface Layer 1
11.0.0
TS 48.016

(SGSN) interface; Network service
10.0.0

(GPRS); Base Station System
(BSS) - Serving GPRS Support
Node (SGSN); BSS GPRS
10.7.0
TS 36.410
TS 36.411
TS 36.412
TS 36.413
TS 44.065
TS 48.018
URL
11.1.0
11.0.0
11.0.0
11.8.0
11.0.0
11.0.0
11.0.0


163
Document #
Document Title
Version
URL
protocol (BSSGP)
Table 54.
External References and Related Documents (3GPP2)
Document #
Document Title
Version
URL
A.S0008-C
Interoperability Specification (IOS) for

High Rate Packet Data (HRPD) Radio
Access Network Interfaces with Session
Control in the Access Network
v2.0
http://www.3gpp2.org/Public_ht
ml/specs/index.cfm
A.S0009-C

High Rate Packet Data (HRPD) Access
Network Interfaces with Session Control
in the Packet Control Function
v1.0
ml/specs/index.cfm
v2.1
A.S0013-C

cdma2000 Access Network Interfaces
part 3 Features"
A.S0014-D

CDMA2000 Access Network Interfaces
Part 4,
v2.0
ml/specs/index.cfm
A.S0022-0

Evolved High Rate Packet Data
(eHRPD) Radio Access Network
Interfaces and Interworking with
Enhanced Universal Terrestrial Radio
Access Network (E-UTRAN)
v1.0
ml/specs/index.cfm
C.S0024-A
Cdma2000 High Rate Packet Data Air

Interface Specification
v3.0
ml/specs/index.cfm
X.S0057 0
E UTRAN - eHRPD Connectivity and

Interworking: Core Network Aspects
v2.0
ml/specs/index.cfm
Table 55.
ml/specs/index.cfm
External References and Related Documents (IETF)
Document #
Document Title
URL
RFC-1035
DOMAIN NAMES - IMPLEMENTATION

AND SPECIFICATION
http://www.rfc-editor.org/rfc/rfc1035.txt
RFC-2126
ISO Transport Service on top of TCP

(ITOT)
RFC-2671
Extension Mechanisms for DNS

(EDNS0)
RFC-3588
Diameter Base Protocol
RFC-4666
Signaling System 7 (SS7) Message


164
Transfer Part 3 (MTP3) - User

Adaptation Layer (M3UA)
RFC-4960
Stream Control Transmission Protocol


165
15 Glossary
Term or Acronym
Full term
1xRTT
cdma2000 Radio Transmission Technology
3GPP
3rd Generation Partnership Project
AAA
Authentication, Authorization, and Accounting
ABQP
Aggregate BSS QoS Profile
ACL
Access Control List
ADC
Analog-to-Digital Conversion
ADMF
ADMinistration Function for Legal Intercept
ADMF
Administration Function
AE
Application Entity
AES
Advanced Encryption Standard
AF
Access Function
AIS
Application Interface Specification
AKA
Authentication and Key Agreement
AMBR
Aggregated Maximum Bit Rate
AMC
Advanced Mezzanine Card
ANSI
American National Standards Institute
API
Application Programming Interface
APN
Access Point Name
APN
Application Programming Interface
APS
Automatic Protection Switching
ARP
Allocation and Retention Priority
ASN.1
Abstract Syntax Notation One
ASP
Application Server Process, as defined by RFC 4666
ATM
Asynchronous Transfer Mode
AVP
Attribute Value Pair
AWT
Average Working Time
BBS
Basic Blade Service
BH
Busy Hour
BIX
Byte Information Exchange
BS
Base Station
BS
Billing System
BSC
Base Station Controller - The BSC is in charge of the allocation and release of


166
Glossary
Term or Acronym
Full term
radio channels and handover management.
BSN
Broadband Service Node
BSS
Base Station System or Subsystem
BSSAP
Base Station System Application Part
BSSGP
Base Station System GPRS Protocol
BT
Block Transfer
BVC
BSSGP Virtual Connection - An end-to-end virtual communications path between

remote network service user entities.
BVCI
BSSGP Virtual Connection Identifier
CALEA
Communications Assistance for Law Enforcement Act of 1994
CAMEL
Customized Application for Mobile network Enhanced Logic
CallP
Call Processing, a type of Virtual Machine on the vMME
CAP
CAMEL Application Part
CAP
Common Administration Part
CAR
Common Alarm Record
CATT
Common Automated Test Tool
CBC
Cell Broadcasting Center
CC
Content of Communication
CDMA
Code Division Multiple Access
CDP
Common Delivery Part
CDR
Call Detail Record
CFDS
Customer Feature Deliver System
CGF
Charging Gateway Function - External entity that processes GPRS accounting

records.
CGI
Cell Global Identity
CK/IK
Cipher Key/Integrity Key
CLI
Command Line Interface
CM
Configuration Management
CMAS
Commercial Mobile Alert System messages
CMN
CoMmoN
CN
Compute Node
CN
Core Network
CoS
Classes of Service
COTS
Common Off The Shelf
CP
Control Processor Control processors manage and control applications


167
Glossary
Term or Acronym
Full term
supporting both system and network functions.
C-plane
Control plane - Administration functions outside the transfer of user data packets
associated with functions such as setting up and tearing down of connections,
establishing identities, and authorizing users.
CPR
Common Performance Record
CPU
Central Processing Unit
CRC
Cyclic Redundancy Check - The monitoring of a digital bit stream to detect

deviations from the expected bit patterns.
CRR
Call Release Reason
CS
Circuit Switched
CS
Corporate Standards
CSCF
Call State Control Function
CSFB
Circuit Switched Fallback
CSG
Closed Subscriber Group
CSGID
Closed Subscriber Group Identity
CSI
Camel Subscription Information
CSL
Call Summary Log
DC
Diameter Client
DDR
Double Data Rate
DF
Delivery Function for Legal Intercept
DNS
Domain Name System - Part of the IP protocol stack. Allows host name to IP
address mapping within an Internet environment.
DP
Discard Priority
DPR
Disconnect Peer Request
DRT
Data Record Transfer
DSCP
Differentiated Services Code Point
DST
Daylight Savings Time
DUPMS
Distributed UDP Path Management System
DVL
Data Volume Limit
eAN
Evolved Access Node for CDMA HRPD network.
ECC
Embedded Communications Computing
ECGI
E-UTRAN Cell Global Identity
ECM
EPC Connection Management
EDP
Event Detection Point
EIR
Equipment Identity Register
ELP
EPC LCS Protocol


168
Glossary
Term or Acronym
Full term
EMC
Electromagnetic Compatibility
EMM
EPS Mobility Management
EMS
Element Management System
eNB
enhanced or evolved Node B
eNodeB
evolved NodeB, the access node in EPS
EP
Emission Priority
EPC
Enhanced or Evolved Packet Core
EPLMN
Equivalent PLMN
EPS
Evolved Packet System
E-RAB
E-UTRAN Radio Access Bearer
eRANAP
enhanced RANAP (Radio Access Network Application Protocol)
ESD
Electrostatic Discharge
E-SMLC
Enhanced Serving Mobile Location Center
ETSI
European Telecommunications Standards Institute
E-UTRAN
Evolved UMTS Terrestrial RAN
EV-DO
EV-Data Optimized
FD
Functional Description
FFS
For Future Study
FGW
Femto Gateway
FIFO
First In, First Out
FM
Fault Management
FP
Functional Processor
FPGA
Field Programmable Gate Array
FQDN
Fully Qualified Domain Name
FQPC
Fully qualified Partial CDR
FRS
Functional Requirements Specification
FRS
Feature Requirements Specification
FRU
Field Replaceable Unit
FTP
File Transfer Protocol
FTS
Feature Technical Specification
FXA
RADIUS Interface
Ga interface
The interface between the SGSN and the CGF.
Gb interface
The interface between the SGSN and the BSS.
GBR
Guaranteed Bit Rate


169
Glossary
Term or Acronym
Full term
GCSNA
Circuit Services Notification Application
Gd interface
The interface between the SGSN and the GSM SMS-GMSC/SMS-IWMSC.
Ge interface
The interface between the SGSN and the EIR.
GEC
Global Emergency Call
GERAN
GSM EDGE Radio Access Network
GGSN
Gateway GPRS Support Node - The node within the GPRS core network that is
responsible for interworking with external PDNs, such as the Internet.
GI
Geographical Identity
Gi interface
An external interface between the GGSN and another packet data network.
GMLC
Gateway Mobile Location Center
GMM
GPRS Mobility Management
GMM context
GPRS Mobility Management - The GMM context is the information sets held at the
MS and the SGSN. It contains mobility related information such as the Mobility
Management state as well as location information, IMSI, and negotiated timer
values.
Gn interface
The interface between the SGSN and the GGSN.
GPP
3rd Generation Partner Project
GPRS
General Packet Radio Service - A packet radio access technique based on GSM
radio to transfer data in an efficient manner optimizing the use of network
resources. It re-uses existing GSM radio technology.
GPS
Global Product Support
Gr interface
The interface between the SGSN and the HLR.
Gs interface
The interface between the SGSN and MSC/VLR. The Gs interface provides
mobiles the ability to communicate with the MSC/VLR for circuit switch services
while they are attached to the packet network.
GSM
Global System for Mobile communications - A technical standard for European

mobile networks.
GSN
GPRS Support Node - Constitutes the interface between the radio system and the
fixed networks for packet switched services. The GSN performs all necessary
functions in order to handle the packet transmission to and from the mobile
stations.
GT
Global Title
GTP
GPRS Tunneling Protocol - The transport protocol used between the SGSN and
GGSN for both signaling and user data transfer. (C-Plane or U-Plane)
GTP-C
GPRS Tunnel Protocol-Control is the protocol between the subscriber control and
the GGSN used to communicate on behalf of the GMM and SM functions.
GTP-U
GPRS Tunneling Protocol U-Plane
GTT
Global Title Translation


170
Glossary
Term or Acronym
Full term
GUMMEI
Globally Unique MME Identifier
GUTI
Globally Unique Temporary Identity
GW
GateWay
HA
High Availability
HFN
Hyper Frame Number
HI1
HI1 - Handover Interface Port 1 (for administration information)
HI2
HI2 - Handover Interface Port 2 (for intercept related information)
HI3
HI3 - Handover Interface Port 3 (for communication content information)
HLR
Home Location Register - Used to store the subscription record, temporary data,
the serving-MSC number and VLR number of a mobile subscriber.
HPLMN
Home PLMN. This represents the operator of an incoming roamer.
HRPD
High Rate Packet Data, also referred to as 1xEV-DO for high speed data over
CDMA
HSS
Home Subscriber Server
IAP
Intercept Access Point
I/O
Input/Output
ICD
Interface Control Document
IDR
Insert Subscriber Data Request
IE
Information Element
IEC
International Electrotechnical Commission
IEEE
Institute of Electrical and Electronics Engineers
ILF
IMSI Locator Function
IM
Installation Method
IMC
IPMC Master Controller
IMEI
International Mobile Equipment Identity
IMEISV
International Mobile Equipment Identity Software Version
IMS
IP Multimedia Services
IMSI
International Mobile Subscriber Identity
IN
Intelligent Network
IOS
Inter-Operability Specification
IP
Internet Protocol - One of the fundamental protocols of the TCP/IP Internet Protocol
suite. It defines the IP datagram as the unit of information passed across an
Internet and provides the basis for connection-less, best-effort packet delivery
service.
IPC
Inter-Process Communication
IPMC
Intelligent Peripheral Management Controller


171
Glossary
Term or Acronym
Full term
IPMI
Intelligent Platform Management Interface
IPSec
IP Security Protocol
IPSP
IP Server Process as defined by RFC 4666. IPSP is essentially the same as ASP.
For the vMME, we use IPSP to denote the function interfaces with the RNC,
whereas ASP is used to denote the function interfaces with the core SS7 network.
IRAT
Inter Radio Access Type
IRAU
Inter-SGSN Routing Area Update - Procedure that enables a subscriber to move

between cells covered by different SGSNs while maintaining an active PDP
context.
IRI
Intercept-Related Information
ISC
IPMC Slave Controller
ISD
Insert Subscriber Data
ISO
International Organization for Standardization
ITU
International Telecommunication Union
IWMSC
Interworking Mobile Switching Center
IWS
InterWorking System
KASME
Key Access Security Management Entries
KPI
Key Performance Indicators
KS
Knowledge Services
KSI
Key Set Identifier
KVM
Kernel-based Virtual Machine
LAI
Location Area Identity
LAN
Local Area Network
LBB
LBO
Local Break-Out
LCF
Location Client Function
LCS
Location Services
LCS-AP
LCS Application Protocol
LEA
Law Enforcement Agency
LED
Light-Emitting Diode
LEMF
Law Enforcement Monitoring Facility
LI
Legal/Lawful Intercept
LI ID
Lawful Intercept Identity
LIAP
Lawful Intercept Access Part
LICP
Lawful Intercept Common Protocol
LIG
Legal/Lawful Intercept Gateway


172
Glossary
Term or Acronym
Full term
LIPA
Local IP Access
LISP
Lawful Interception Service Processor
LLC
Logical Link Control layer protocol
LLC layer
Logical Link Control - The upper sublayer of the data link layer of the seven-layer
OSI model, which provides media-independent functions and the logical connection
between the stations within the local area network.
LP
Logical Processor
LPP
LTE Positioning Protocol
LSAF
Location Subscriber Authorization Function
LSB
Least Significant Bit
LSBF
Location System Billing Function
LSOF
Location System Control Function
LSPF
Location Subscriber Privacy Function
LTE
Long Term Evolution
LX
Long Range Optical Transceiver
M3UA
MTP Level 3 (MTP3) User Adaptation Layer
MAP
Mobile Application Part - The MAP is the software protocol layer that allows
information about a roaming mobile-subscriber (MS) to flow between functional
entities in the Public Land Managed Network (PLMN).
MBMS
Multimedia Broadcast-Multicast Service
MBR
Maximum Bit Rate
MBSFN
MBMS over a Single Frequency Network
MCC
Mobile Country Code
MCE
Multi-cell/multicast Coordination Entity
M-CDR
Mobility CDR
ME
Managed Element
ME
Mobile Equipment
MF
Mediation Function
MLT
Multi Link Trunk
MM
Mobility Management
MMC
Mezzanine Management Controller
MME
MNC
Mobile Network Code
MNO
Mobile Network Operator
MO
Managed Object
MO-LR
Mobile Originated Location Request


173
Glossary
Term or Acronym
Full term
MPC
Modular Port Concentrators
MPU
Main Processing Unit
MS
Mobile Station - Subscriber equipment that provides access into the PLMN.
MSC
Mobile Switching Center - Provides switching and call control of GSM basic and
supplementary services.
MSC/VLR
Mobile Switching Center/Visitor Location Register
MS-ISDN (MSISDN)
Mobile Subscriber ISDN Number
MSS
Multiservice Switch
MT-LR
Mobile Terminated Location Request
M-TMSI
MME-Temporary Mobile Subscriber Identity
MVNO
Mobile Virtual Network Operator
NA
Not Applicable
NACC
Network Assisted Cell Change
NAPTR
Naming Authority Pointer
NAS
Non Access Stratum
NAS
Network Attached Storage
NE
Network Element
NEAF
Non-EPS Alert Flag
NEBS
Network Equipment Building Systems
NE-RAMS
Network Element Reliability, Availability, Maintainability, and Survivability
NI-LR
Network Induced Location Request
NMIS
Network Management Interface Specification
NOR
Notify Request
NPLI
Network Provided Location Information
NRI
Network Resource Identifier
NS layer
Network Services layer - The transport protocol used between the SGSN and the
BSS, specifically the PCUSN of the BSS, to ensure in order delivery of packets
sent between higher layer protocols.
NSE
Network Services Entity - A logical entity that exists on both the SGSN and the
BSS for managing the transport of both signaling and data packets between them.
NS-VC
Network Services Virtual Connection - An end-to-end logical connection for the

transport of signaling and data packets between the SGSN and the BSS.
NTP
Network Time Protocol
OA&M (or OAM)
Operations Administration and Maintenance - All the tasks necessary for providing,
maintaining, or modifying the services provided by a switching system.
OEM
Other or Original Equipment Manufacturer


174
Glossary
Term or Acronym
Full term
ODB
Operator Determined Barring
OID
Object Identifier
OM
Operational Measurement
OOS
Out Of Service
OS
Operating System
OTDOA
Observed Time Difference Of Arrival
PCB
Printed Circuit Board
PCI
Peripheral Component Interconnect
PCRF
Policy and Charging Rules Function
PCU
Packet Control Unit
PCUSN
Packet Control Unit Support Node - A node in the BSS that interacts either directly
or indirectly with all the BSS nodes, except the Transcoder Unit (TCU).
PDCP-SN
Packet Data Convergence Protocol-Sequence Number
PDN
Packet Data Network - A communications system designed to carry packet data.
PDP context
The Packet Data Protocol (PDP) context is the information sets held in the MS and
the GSNs for a PDP address. It contains information such as PDP Type, QoS
Profile, APN, and GGSN.
PDU
Protocol Data Units - A data unit that (a) is transferred among peer entities of a
network and (b) contains protocol information, such as control information and
address information.
PEC
Product Engineering Code
PFC
Packet Flow Context
PFE
Packet Forwarding Engine
PFM
Packet Flow Management
PGW or P-GW
PDN Gateway
PHB
Per-Hop Behavior
PLM
Product Line Management
PLMN
Public Land Mobile Network - A network, established and operated by an

Administration or its licensed operator(s), for the specific purpose of providing land
mobile communication services to the public.
PM
Performance Management
PMC
PCI Mezzanine Card
POST
Power-On Self-Test
PPP
Point-to-Point Protocol
PS
Packet Switched
PSAP
Public Safety Answering Points


175
Glossary
Term or Acronym
Full term
P-TMSI
Packet-Temporary Mobile Subscriber Identity
PVI
Preemption Vulnerability Indication
PWS
Public Warning System
QCI
QoS Class Identifier
QoS
Quality of Service
RAB
Radio Access Bearer
RAC
Routing Area Code
RADIUS
Remote Authentication or Access Dial in User Service
RAI
Routing Area Identity
RAI-FQDN
Routing Area Identity-Fully Qualified Domain Name
RAM
Random Access Memory
RAN
Radio Access Network
RANAP
Radio Access Network Application Part
RAT
Radio Access Type
RAU
Routing Area Update
RDSP
RAT Frequency Selection Priority
RGMII
Reduced Gigabit Media Independent Interface
RIM
RAB Information Management
RLC
Radio Link Control
RM
Resource Manager
RNC
Radio Network Controller
RoHS
Restriction of Hazardous Substances Directive
RPC
Reduced Partial CDR
RTM
Rear Termination Module
S1-AP
S1 Application Protocol
SA
System Architecture
SAE
System Architecture Evolution
SAE-GW
Serving Gateway
SAF
Service Availability Forum
SAI
Service Area Identity
SAS
SGSN Accounting Server - SGSN entity that provides the SGSN billing
functionality.
SATA
Serial Advanced Technology Attachment
SC
Subscriber Control: Primary purpose is to organize the related C-plane processes,

such as GMM, SM, HLR Cache, and MAP Client.


176
Glossary
Term or Acronym
Full term
SCCP
Signalling Connection Control Part
S-CDR
Serving GPRS Support Node - CDR
SCF
Service Control Function
SCP
Service Control Point - External entity used to manage Prepaid SMS subscriber
accounts.
SCTP
Stream Control Transmission Protocol
SD
Subscriber Data - Consists of the application handling the protocols involved in the
2G and 3G subscriber data path, namely LLC, SNDCP and GTP.
SDRAM
Synchronous Dynamic Random Access Memory
SDRs
Sensor Data Record
SELV
Safety Extra Low Voltage Circuits
SERDES
Serializer/Deserializer
SFP
Small Form-Factor Pluggable
SFTP
Secure FTP
SGMII
Serial Gigabit Media Independent Interface
SGSN
Serving GPRS Support Node - Main functions are to detect new GPRS mobile
stations in its service area, send/receive data packets to/from the mobile stations,
and record the location of mobile stations inside its service area.
S-GW or SGW
Serving Gateway
SIG
SS7/IP Gateway
SIG
SIGnaling VM, a type of VM on the vMME
SIGTRAN
SIGnaling TRANsport. Defines a family of protocols that provide reliable datagram

transport service and user adaptation layer for traditional Signaling System 7 based
protocols.
SIM
Subscriber Identity Module
SLB
Steering Load Balancer, a type of VM for the vMME
SLF
Subscriber Locator Function
SMS
Short Message Service
SMS
Short Messages Service - Provides the means to transfer messages between a

GPRS PLMN MS and a Short Message entity through a service center.
SMSC
Short Message Service Center
SM-SC
Short Message service Service Centre
SNAPTR
NAPTR (Naming Authority Pointer) Resource Record is defined by the IETF for
Dynamic Delegation Discovery System (DDDS). It is defined in RFC 3401, 3402,
3403 and 3404. S-NAPTR is straightforward-NAPTR. It limits the NAPTR record
types to a, s and . It also simplifies the rewrite rules to replacement rules only.
SNDCP
SubNetwork Dependent Convergence Protocol


177
Glossary
Term or Acronym
Full term
SNDCP layer
Sub Network Dependent Convergence Protocol - Responsible for segmentation or

reassembly and possibly compression of data packets for transport between the
MS and the SGSN.
SNMP
Simple Network Management Protocol
SNOW3G
SNOW3G is a stream cipher which uses a 128-bit Key and IV.
SNR
Seamless National Roaming
SNS
Sub-Network Services
SON
Self Optimized Networks
SPI
Serial Peripheral Interface
SRAM
Static Random Access Memory
SRNS
Serving Radio Network Subsystem
SS7
Signaling System 7 Common channel signaling system designed for the control
of voice and non-voice services and for use in a digital environment, where
signaling information may be sent at 64 kbit/s.
SSH
Secure Shell
S-SMO-CDR
SGSN delivered Short message Mobile Originated CDR
S-SMT-CDR
SGSN delivered Short message Mobile Terminated CDR
STP
Shielded Twisted Pair
STPx
System Test Phase <x> (milestone)
SU
Service Unit
SX
Short Range Optical Transceiver
TA
Tracking Area
TAC
Tracking Area Code
TAI
Tracking Area Identity
TAS
Technical Assistance Services
TAU
Tracking Area Update
TBD
To Be Determined
TCAP
Transaction Capabilities Application Part - TCAP uses the MTP and SCCP
software layers to provide connectionless signaling for transaction services. Simply
put, it allows two nodes to communicate with each other in the same language.
TCP
Transmission Control Protocol
TCP/IP
Transmission Control Protocol/Internet protocol - A protocol stack, designed to

connect different networks, on which the Internet is based.
TDM
Time Division Multiplex
TDP
Trigger Detection Point
TEID
Tunnel End IDentifier


178
Glossary
Term or Acronym
Full term
TFT
Traffic Flow Template
TI
Technology Introduction
TIPC
Transparent Inter Process Communication
TLLI
Temporary Logical Link Identifier - Describes an identified MS registered in the

network and owning a LLC context with the SGSN.
TLV
Type Length Value
TODA
Time Of Day Accounting
TPE
Twisted-Pair Ethernet
TTCT
Tariff Time Change Trigger
UDP
User Datagram Protocol
UDP/IP
User Datagram Protocol/Internet Protocol - A transport layer, connectionless mode

protocol, providing a datagram mode of communication for delivery of packets to a
remote or local user.
UE
User Equipment
UE-AMBR
User Equipment- Aggregated Maximum Bit Rate
UGL
Update GPRS Location
UMTS
Universal Mobile Telecommunications System
UP
User Plane; see U-Plane
U-plane
User plane - Function associated with the transfer of actual user data to and from a
PDN.
UPM
UDP Path Manager (a software component on the MME)
UPSM
UDP Path Steering Manager
USD
UMTS Subscriber Data
USIM
UMTS SIM
UTC
Universal Time Coordinated
UTRA
Universal Terrestrial Radio Access
UTRAN
UMTS Terrestrial Radio Access Network
UTRAN
UMTS Terrestrial RAN
VLAN
Virtual Local Area Network
VLR
Visitor Location Register
VM
Virtual Machine
VMM
Virtual Machine Management
VPLMN
Visited Public Land Mobile Network
XML
eXtensible Markup Language


179


180

Hitachi vMME Product Overview

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Hitachi vMME Product Overview

Hochgeladen von

Copyright:

Verfügbare Formate

vMME Product Overview

This is the initial draft version of the document.

Input 8.2 feature content based on the latest FD documents.

vMME Product Overview

Hitachi Proprietary and Confidential

Hitachi Proprietary and Confidential

6.6 Subscriber Management ........................................................................................................ 101

vMME Product Overview

Hitachi Proprietary and Confidential

vMME Product Overview

Hitachi Proprietary and Confidential

Gn/Gp Based 3GPP Network Architecture ....................................................................... 4

S4-Based 3GPP Network Architecture ............................................................................. 5

Non-roaming architecture for 3GPP access ..................................................................... 7

Roaming architecture for 3GPP access ............................................................................ 7

Protocol Stack for S1 Interface for Control Plane ........................................................... 24

Protocol Stack for S3 and other Mobility Management interfaces .................................. 28

Protocol stack for S4 user plane interface ...................................................................... 32

Protocol Stack for S6 interface ........................................................................................ 33

Protocol stack for S11 interface ...................................................................................... 36

Protocol Stack for S13 interface...................................................................................... 38

Protocol stack for S101 interface .................................................................................... 41

Protocol stack for S102 interface .................................................................................... 42

Protocol Stack for CBC eNB ........................................................................................ 43

Protocol Stack for SGs interface ..................................................................................... 44

Protocol stack for Sv interface ........................................................................................ 46

Protocol Stack for SLg interface...................................................................................... 47

Protocol Stack for SLs interface ...................................................................................... 48

Protocol Stack for Fxa interface ...................................................................................... 49

Protocol stack for Ga interface ........................................................................................ 50

Protocol stack for Gb interface (IP based transport) ....................................................... 51

Protocol Stack for Gb User Bearer Plane ....................................................................... 55

Protocol Stack for Gd interface ....................................................................................... 57

Protocol Stack for Ge interface ....................................................................................... 61

Protocol Stack for Gf interface ........................................................................................ 63

vMME Product Overview

Hitachi Proprietary and Confidential

Protocol Stack for GTP-U................................................................................................ 66

Protocol Stack for Gr interface ........................................................................................ 67

Protocol Stack for Gs interface ....................................................................................... 69

Protocol Stack for Iu User Bearer Plane Direct Tunnel ............................................... 71

Protocol Stack for Iu User Bearer Plane S4-SGSN case ............................................ 72

Protocol Stack for Iu Control Plane ................................................................................. 73

Protocol Stack for Control Plane for UE - MME .............................................................. 78

Protocol Stack for Control Plane MS SGSN in A/Gb Mode ......................................... 82

Protocol Stack for Control Plane MS SGSN in Iu Mode .............................................. 82

Protocol Stack for HI2 ..................................................................................................... 86

Protocol Stack for Domain Name Service interface ........................................................ 86

Combined MME/SGSN in a wireless network with 2G/3G/4G access technologies ...... 89

National roaming network Example .............................................................................. 104

Deployment example 1 Network Level View ............................................................ 149

Deployment example 1 Nodal level view .................................................................. 150

Deployment example 2 Nodal level view .................................................................. 152

Deployment example 3 Nodal level view .................................................................. 154

Deployment example 4 Nodal level view .................................................................. 155

vMME Product Overview

Hitachi Proprietary and Confidential

vMME Application Software Composition ........................................................................... 13

Logical Interfaces ................................................................................................................ 22

S3 Interface Messages ....................................................................................................... 28

S4 interface GTP-C Messages ........................................................................................... 30

S4 User Bearer Plane Messages ........................................................................................ 32

S11 interface Messages ...................................................................................................... 36

S101 Interfaces Messages .............................................................................................. 41