Académique Documents
Professionnel Documents
Culture Documents
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
04/24/2015
1.01
05/04/2015
1.02
Update TS specification versions to Release 11; input feature content based on the
latest FD documents.
05/19/2015
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
vMME Product Overview
Document Status: 8.2, Draft
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
List of Figures
Figure 1.
Figure 2.
Figure 3.
Figure 4.
Figure 5.
Figure 6.
Figure 7.
Protocol stack for S4 interface and other Session Management interfaces ................... 30
Figure 8.
Figure 9.
Figure 10.
Figure 11.
Figure 12.
Figure 13.
Figure 14.
Figure 15.
Figure 16.
Figure 17.
Figure 18.
Figure 19.
Figure 20.
Figure 21.
Figure 22.
Figure 23.
Figure 24.
Figure 25.
Figure 26.
Figure 27.
Figure 28.
Figure 29.
Protocol Stack for Iu User Bearer Plane Anchored on the SGSN ............................... 71
Figure 30.
Figure 31.
Figure 32.
Figure 33.
Figure 34.
Figure 35.
Figure 36.
Protocol Stack for X interface between the MME and the LIG ....................................... 84
Figure 37.
Figure 38.
Figure 39.
Figure 40.
Figure 41.
Figure 42.
Figure 43.
Figure 44.
Figure 45.
List of Tables
Table 1.
Table 2.
Table 3.
S1-AP Messages................................................................................................................. 24
Table 4.
Table 5.
Table 6.
Table 7.
S6 Messages ....................................................................................................................... 33
Table 8.
S10 Messages..................................................................................................................... 34
Table 9.
Table 10.
S13 Messages................................................................................................................. 39
Table 11.
S16 Messages................................................................................................................. 39
Table 12.
Table 13.
Table 14.
Table 15.
Table 16.
Table 17.
Table 18.
Table 19.
Table 20.
Table 21.
Gb NS messages ............................................................................................................ 52
Table 22.
Table 23.
Table 24.
Table 25.
Table 26.
Gd Messages .................................................................................................................. 57
Table 27.
Table 28.
Table 29.
Table 30.
Table 31.
Gf Messages ................................................................................................................... 63
Table 32.
Table 33.
Table 34.
Table 35.
Gr Messages ................................................................................................................... 67
Table 36.
Gs Messages .................................................................................................................. 69
Table 37.
Iu Messages .................................................................................................................... 73
Table 38.
Table 39.
Table 40.
Table 41.
Table 42.
Table 43.
Table 44.
Table 45.
Table 46.
Table 47.
Table 48.
Table 49.
Table 50.
Table 51.
Table 52.
Table 53.
Table 54.
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:
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.
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.
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.
SMS-SC
C
gsmSCF
Gd
MSC/VLR
A
Gs
Iu
R
TE
Uu
MT
HSS
Ge
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
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.
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.
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).
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.)
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
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.
3 Software Environment
The vMME adopts layered software architecture. From a high level, the system can be divided into
three layers1.
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.
MGMT (OAM)
RM (resource management)
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.
Software Environment
SIG (signaling)
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.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):
Software Environment
PM (Performance Management):
Format: 3GPP XML - per 3GPP Technical Specifications: 32.401, 32.404, 32.406,
32.426, 32.432, 32.425
FM (Fault Management):
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
TRACE:
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.
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.
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
15
15
Yes
Yes
Steering
Load
Balancer
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.
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.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:
Notify the CBC about the message delivery. The response to CBC will not wait for eNodeBs
response to MME
Ability to start and stop the broadcasting of PWS and CMAS messages
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.
MME/SGSN Software
Mobility Management
Session Management
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.
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.
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
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:
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:
The SLs function can be instantiated on the CallP VM when the SLs interface is configured.
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
The instantiation of the S1 function on the Signaling VM depends on whether the vMME is used to
support 4G Access technology or not.
S11
S10
S3
S4
S16
Sv
Gn/Gp
S101
S102
vMME Product Overview
MME/SGSN Software
GTP-Path Management
1x CS based protocol
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.
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.
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.
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.
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
S3
SGSN or
MME
1000
N/A
S4
SGW
1000
N/A
S6
HSS
1000 if via
Relay
Diameter
Agent
20
IPv4 or IPv6
248
248 if direct
connect
S10
MME
1000
N/A
S11
SGW
1000
N/A
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.
Interfaces
Interface
Peer Node
Name
Relay Node
Local IP Usage
Name
Cardinality
Name
Cardinality
Min
S13
EIR
Diameter
Agent
248
IPv4 or IPv6
S16
SGSN
1000
N/A
S101
eAN
15000
N/A
S102
IWS
200
N/A
SBc
CBC
N/A
IPv4 or IPv6
SGs
VLR
256
N/A
IPv4 or IPv6
Sv
VLR
256
N/A
SLg
GMLC
50
DRA
SLs
eSMLC
20
Fxa
AAA
Ga
248
Max
Type
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
Gn/Gp
SGSN
1000
N/A
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)
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
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
Interfaces
Message Type
Message
Direction
V9.5.1/V10.6.0/V11.8.0
Supported
Supported
Supported
Supported
Supported
Supported
Supported
Supported
Supported
10
Supported
11
Supported
12
Supported
13
Supported
14
Supported
15
Supported
16
Supported
17
Handover Required
Supported
18
Handover Command
Supported
19
Supported
20
Handover Request
Supported
21
Supported
22
Handover Failure
Supported
23
Handover Notify
Supported
24
Supported
25
Supported
26
Supported
27
Handover Cancel
Supported
28
Supported
29
Supported
30
Supported
31
Paging
Supported
32
Initial UE Message
Supported
33
Supported
34
Supported
35
Supported
Interfaces
Message Type
Message
Direction
V9.5.1/V10.6.0/V11.8.0
36
Reset
Supported
37
Reset Acknowledge
Supported
38
Error Indication
Supported
39
S1 Setup Request
Supported
40
S1 Setup Response
Supported
41
S1 Setup Failure
Supported
42
Supported
43
Supported
44
Supported
45
Supported
46
Supported
47
Supported
48
Supported
49
Supported
50
Overload Start
Supported
51
Overload Stop
Supported
52
Supported
53
Trace Start
Supported
54
Supported
55
Deactivate Trace
Supported
56
Supported
57
Supported
58
Location Report
Supported
59
Supported
60
Supported
61
Supported
62
Supported
63
Supported
64
Supported
65
Not supported
66
Kill Request
Supported
67
Kill Response
Supported
68
Supported
69
Supported
Interfaces
Message Type
Message
Direction
V9.5.1/V10.6.0/V11.8.0
70
Supported
71
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.
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
Supported
Echo Response
Supported
Supported
Identification Request
Supported
Identification Response
Supported
Context Request
Supported
Context Response
Supported
Interfaces
Message Type
Message Direction
V9.5.0/V10.10.0/V11.13.0
Context Acknowledge
Supported
Forward Relocation
Request
Forward Relocation
Response
Relocation Cancel
Request
Relocation Cancel
Response
Forward Relocation
Complete Notification
Forward Relocation
Complete Acknowledge
15
Supported
16
Suspend Notification
Supported
17
Suspend Acknowledge
Supported
18
Detach Notification
Not supported
19
Detach Acknowledge
Not supported
20
CS Paging Indication
Not supported
21
Not supported
22
Not supported
23
UE Activity Notification
Not supported
24
UE Activity Acknowledge
Not supported
10
11
12
13
14
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.
At the IP layer, the MME supports both IPv4 and IPv6 addresses at the same time, thus allowing
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.
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.
Message Type
Message Direction
V9.5.0/V10.10.0
Echo Request
Supported
Echo Response
Supported
Supported
Supported
Supported
Supported
Supported
Supported
Supported
Interfaces
Message Type
Message Direction
V9.5.0/V10.10.0
10
Supported
11
Supported
12
Supported
13
Supported
14
Supported
15
Supported
16
Supported
17
Supported
18
Supported
19
Supported
20
Supported
21
Supported
22
Supported
23
Supported
24
Supported
25
Supported
26
Suspend Notification
Supported
27
Suspend Acknowledge
Supported
28
Resume Notification
Supported
29
Resume Acknowledge
Supported
30
Supported
31
Supported
32
Supported
33
Supported
34
Supported
35
Supported
36
Not supported
37
Supported
38
Supported
39
Not supported
40
Not supported
41
Not supported
42
Not supported
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.
Message Type
Message Direction
V9.3.0
Echo Request
Receive only
Echo Response
Supported
Error Indication
Supported
Supported
G-PDU
Supported
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
messages supported for each of the configured versions.
Table 7.
S6 Messages
Message Type
Message Direction
V9.5.0/10.7.0/11.11.0
Supported
Supported
Supported
Supported
Supported
Supported
Supported
Interfaces
Message Type
Message Direction
V9.5.0/10.7.0/11.11.0
Supported
Supported
10
Supported
11
Supported
12
Supported
13
Supported
14
Supported
15
Supported
16
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.
Table 8.
S10 Messages
Message Type
Message Direction
V9.5.0/V10.10.0
Echo Request
Supported
Echo Response
Supported
Interfaces
Identification Request
Supported
Identification Response
Supported
Context Request
Supported
Context Response
Supported
Context Acknowledge
Supported
Supported
Supported
10
Supported
11
Supported
12
Supported
13
Supported
14
Supported
15
Supported
16
Supported
17
Supported
The S10 interface is similar to the S3 interface. Please refer to S3 Interface related to the GTP layer
and IP layer information.
Interfaces
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.
Message Type
Message Direction
V9.5.0/V10.10.0
Echo Request
Supported
Echo Response
Supported
Supported
Supported
Supported
Supported
Supported
Supported
Supported
10
Supported
11
Supported
12
Supported
13
Supported
14
Supported
15
Supported
16
Supported
Interfaces
Message Type
Message Direction
V9.5.0/V10.10.0
Acknowledge
17
Supported
18
Supported
19
Supported
20
Supported
21
Supported
22
Supported
23
Supported
24
Supported
25
Supported
26
Suspend Notification
Supported
27
Suspend Acknowledge
Supported
28
Resume Notification
Supported
29
Resume Acknowledge
Supported
30
Supported
31
Supported
32
Supported
33
Supported
34
Supported
35
Supported
36
Not supported
37
Supported
38
Supported
39
Supported
40
Supported
41
Not supported
42
Not supported
43
Not supported
44
Not supported
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.
At the IP layer, the MME supports both IPv4 and IPv6 addresses at the same time, thus allowing
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.
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.
Interfaces
Table 10.
S13 Messages
Message Type
Message Direction
V9.5.0/V10.7.0
ME-Identity-Check-Request
Supported
ME-Identity-Check-Answer
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.
S16 Messages
Message Type
Message Direction
V9.5.0/V10.10.0
Echo Request
Supported
Echo Response
Supported
Identification Request
Supported
Identification Response
Supported
Context Request
Supported
Context Response
Supported
Context Acknowledge
Supported
Supported
Supported
10
Supported
11
Supported
12
Supported
13
Supported
Interfaces
Message Type
Message Direction
V9.5.0/V10.10.0
Acknowledge
14
Supported
15
Supported
16
Supported
17
Supported
18
Suspend Notification
Supported
19
Suspend Acknowledge
Supported
The S16 interface is similar to the S3 interface. Please refer to S3 Interface related to the GTP layer
and IP layer information.
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.
Message Type
Message
Direction
V9.4.0/V10.3.0/V11.0.0
Echo Request
Supported
Echo Response
Supported
Supported
Supported
Supported
Supported
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.
Interfaces
At the IP layer, the MME supports both IPv4 and IPv6 addresses at the same time, thus allowing
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.
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
messages supported for each of the configured versions.
Table 13.
Message Type
Message Direction
V10.0.0/V11.1.0
ICD-v2
Echo Request
Not Supported
Supported
Echo Response
Not Supported
Supported
Supported
Supported
A21-Ack
Supported
Supported
A21-Event Notification
Supported
Supported
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.
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.
Message Type
Message Direction
V9.3.0/10.2.0/11.4.0
Supported
Interfaces
Message Type
Message Direction
V9.3.0/10.2.0/11.4.0
Supported
Supported
Supported
Error Indication
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.
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.
Message Type
Message Direction
V9.3.0/V10.9.0/V11.11.0
SGsAP-ALERT-ACK
Supported
SGsAP-ALERT-REJECT
Supported
Interfaces
Message Type
Message Direction
V9.3.0/V10.9.0/V11.11.0
SGsAP-ALERT-REQUEST
Supported
SGsAP-DOWNLINK-UNITDATA
Supported
SGsAP-EPS-DETACH-ACK
Supported
SGsAP-EPS-DETACH-INDICATION
Supported
SGsAP-IMSI-DETACH-ACK
Supported
SGsAP-IMSI-DETACH-INDICATION
Supported
SGsAP-LOCATION-UPDATE-ACCEPT
Supported
10
SGsAP-LOCATION-UPDATE-REJECT
Supported
11
SGsAP-LOCATION-UPDATE-REQUEST
Supported
12
SGsAP-MM-INFORMATION-REQUEST
Supported
13
SGsAP-PAGING-REJECT
Supported
14
SGsAP-PAGING-REQUEST
Supported
15
SGsAP-RESET-ACK
Supported
16
SGsAP-RESET-INDICATION
Supported
17
SGsAP-SERVICE-REQUEST
Supported
18
SGsAP-STATUS
Supported
19
SGsAP-TMSI-REALLOCATIONCOMPLETE
Supported
20
SGsAP-UE-ACTIVITY-INDICATION
Supported
21
SGsAP-UE-UNREACHABLE
Supported
22
SGsAP-UPLINK-UNITDATA
Supported
23
SGsAP-RELEASE-REQUEST
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.
Interfaces
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
Supported
Echo Response
Supported
Supported
SRVCC PS to CS Request
Supported
SRVCC PS to CS Response
Supported
Supported
Supported
Supported
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.
At the IP layer, the MME supports both IPv4 and IPv6 addresses at the same time, thus allowing
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.
vMME Product Overview
Document Status: 8.2, Draft
Interfaces
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.
Message Type
Message Direction
Supported/Not
Supported
MME GMLC
Supported
MME GMLC
Supported
MME GMLC
Supported
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.
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.
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.
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
Interfaces
MME E-SMLC
Supported
MME E-SMLC
Supported
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.
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.
Message Type
Message Direction
Supported/Not
Supported
RADIUS ACCESS-REQUEST
Supported
RADIUS ACCESS-ACCEPT
Supported
RADIUS ACCESS-REJECT
Supported
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
Supported
Echo Response
Supported
Interfaces
Message Type
Message Direction
Version 9.6.1/10.12.0
Supported
Supported
Supported
Redirection Request
Supported
Redirection Response
Supported
Supported
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
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
Supported
Supported
NS-ALIVE-ACK
Supported
Supported
NS-BLOCK
Supported
Supported
NS-BLOCK-ACK
Supported
Supported
NS-RESET
Supported
Supported
NS-RESET-ACK
Supported
Supported
NS-STATUS
Supported
Supported
NS-UNBLOCK
Supported
Supported
NS-UNBLOCK-ACK
Supported
Supported
10
NS-UNITDATA
Supported
Supported
Table 22.
Message Type
Message Direction
Version 9
Version 10
SNS-ACK
Supported
Supported
SNS-ADD
Supported
Supported
SNS-CHANGEWEIGHT
Supported
Supported
SNS-CONFIG
Supported
Supported
SNS-CONFIG-ACK
Supported
Supported
SNS-DELETE
Supported
Supported
SNS-SIZE
Supported
Supported
SNS-SIZE-ACK
Supported
Supported
Interfaces
Table 23.
Gb BSSGP messages
Message Type
Message Direction
Version 9
Version 10
DL-UNITDATA
Supported
Supported
UL-UNITDATA
Supported
Supported
RA-CAPABILITY
Supported
Supported
DL-MBMS-UNITDATA
Not supported
Not supported
UL-MBMS-UNITDATA
Not supported
Not supported
PAGING PS
Supported
Supported
PAGING CS
Supported
Supported
RA-CAPABILITY-UPDATE
Supported
Supported
RA-CAPABILITY-UPDATE-ACK
Supported
Supported
10
RADIO-STATUS
Supported
Supported
11
SUSPEND
Supported
Supported
12
SUSPEND-ACK
Supported
Supported
13
SUSPEND-NACK
Supported
Supported
14
RESUME
Supported
Supported
15
RESUME-ACK
Supported
Supported
16
RESUME-NACK
Supported
Supported
17
FLUSH-LL
Supported
Supported
18
FLUSH-LL-ACK
Supported
Supported
19
LLC-DISCARDED
Supported
Supported
20
FLOW-CONTROL-BVC
Supported
Supported
21
FLOW-CONTROL-BVC-ACK
Supported
Supported
22
FLOW-CONTROL-MS
Supported
Supported
23
FLOW-CONTROL-MS-ACK
Supported
Supported
24
BVC-BLOCK
Supported
Supported
25
BVC-BLOCK-ACK
Supported
Supported
26
BVC-UNBLOCK
Supported
Supported
27
BVC-UNBLOCK-ACK
Supported
Supported
28
BVC-RESET
Supported
Supported
29
BVC-RESET-ACK
Supported
Supported
30
STATUS
Supported
Supported
31
SGSN-INVOKE-TRACE
Not supported
Not supported
32
DOWNLOAD-BSS-PFC
Supported
Supported
33
CREATE-BSS-PFC
Supported
Supported
34
CREATE-BSS-PFC-ACK
Supported
Supported
Interfaces
Message Type
Message Direction
Version 9
Version 10
35
CREATE-BSS-PFC-NACK
Supported
Supported
36
MODIFY-BSS-PFC
Supported
Supported
37
MODIFY-BSS-PFC-ACK
Supported
Supported
38
DELETE-BSS-PFC
Supported
Supported
39
DELETE-BSS-PFC-ACK
Supported
Supported
40
FLOW-CONTROL-PFC
Supported
Supported
41
FLOW-CONTROL-PFC-ACK
Supported
Supported
42
DELETE-BSS-PFC-REQ
Supported
Supported
43
PS-HANDOVER-REQUIRED
Not supported
Not supported
44
PS-HANDOVER-REQUIRED-ACK
Not supported
Not supported
45
PS-HANDOVER-REQUIREDNACK
Not supported
Not supported
46
PS-HANDOVER-REQUEST
Not supported
Not supported
47
PS-HANDOVER-REQUEST-ACK
Not supported
Not supported
48
PS-HANDOVER-REQUEST-NACK
Not supported
Not supported
49
PS-HANDOVER-COMPLETE
Not supported
Not supported
50
PS-HANDOVER-CANCEL
Not supported
Not supported
51
PS-HANDOVER-COMPLETE-ACK
Not supported
Not supported
52
PERFORM-LOCATION-REQUEST
Not supported
Not supported
53
PERFORM-LOCATIONRESPONSE
Not supported
Not supported
54
PERFORM-LOCATION-ABORT
Not supported
Not supported
55
POSITION-COMMAND
Not supported
Not supported
56
POSITION-RESPONSE
Not supported
Not supported
57
RAN-INFORMATION-REQUEST
Supported
Supported
58
RAN-INFORMATION
Supported
Supported
59
RAN-INFORMATION-ACK
Supported
Supported
60
RAN-INFORMATION-ERROR
Supported
Supported
61
RAN-INFORMATIONAPPLICATION-ERROR
Supported
Supported
62
MBMS-SESSION-STARTREQUEST
Not supported
Not supported
63
MBMS-SESSION-STARTRESPONSE
Not supported
Not supported
64
MBMS-SESSION-STOPREQUEST
Not supported
Not supported
65
MBMS-SESSION-STOP-
Not supported
Not supported
Interfaces
Message Type
Message Direction
Version 9
Version 10
RESPONSE
66
MBMS-SESSION-UPDATEREQUEST
Not supported
Not supported
67
MBMS-SESSION-UPDATERESPONSE
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.
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
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
Combined Information
(I) and Supervisory
(S) frames
ACK
SGSN <--> MS
Supported
Combined Information
(I) and Supervisory
(S) frames
RNR
SGSN <--> MS
Supported
Combined Information
(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.
vMME Product Overview
Document Status: 8.2, Draft
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
Supported
MAP-MO-FORWARD-SHORT-MESSAGE response
Supported
MAP-READY-FOR-SM request
Supported
MAP-READY-FOR-SM response
Supported
MAP-MT-FORWARD-SHORT-MESSAGE request
Supported
MAP-MT-FORWARD-SHORT-MESSAGE response
Supported
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.
Message Type
Message Direction
V9.4.0/V10.8.0
Supported
Supported
Supported
Supported
Receive only
Supported
Supported
ASP Up
Supported
Supported
10
ASP Down
Supported
11
Supported
12
Heartbeat (BEAT)
Supported
13
Supported
14
Not supported
15
Not supported
16
Not supported
17
Not supported
18
ASP Active
Supported
19
Supported
20
ASP Inactive
Supported
21
Supported
22
Error
Supported
23
Notify
Supported
Interfaces
Table 28.
Message Type
Message Direction
V9.4.0/10.8.0
NA
NA
NA
NA
NA
NA
NA
NA
NA
10
NA
11
Released (RLSD)
NA
12
NA
13
NA
14
NA
15
Subsystem-allowed (SSA)
Supported
16
Subsystem-out-of-service-grant (SOG)
Not supported
17
Subsystem-out-of-service-request (SOR)
Not supported
18
Subsystem-prohibited (SSP)
Supported
19
Subsystem-status-test (SST)
Supported
20
Unitdata (UDT)
Supported
21
Supported
22
Supported
23
Supported
24
Supported
25
Supported
26
Supported
For the Gd interface, only the connectionless service classes of the SCCP layer are used.
Table 29.
Message Type
Message Direction
V9.4.0/V10.8.0
TC-BEGIN
Supported
TC-END
Supported
TC-CONTINUE
Supported
Interfaces
Message Type
Message Direction
V9.4.0/V10.8.0
TC-ABORT
Supported
TC-UNIDIRECTIONAL (NOTICE)
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.
Interfaces
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)
Supported
applyChargingReportGPRS (event)
Supported
entityReleasedGPRS
Supported
eventReportGPRS
Supported
initialDpGPRS
Supported
activtyTestGPRS (request)
Supported
applyChargingGPRS
Supported
applyChargingReportGPRS (result)
Supported
cancelGPRS
Supported
10
connectGPRS
Supported
11
continueGPRS
Supported
12
entityReleasedGPRS (result)
Supported
Interfaces
Message Type
Message Direction
V9.2.0/V10.0.0/V11.2.0
13
eventReportGPRS (result)
Supported
14
furnishChargingInformationGPRS
Supported
15
releaseGPRS
Supported
16
requestReportGPRSEvent
Supported
17
resetTimerGPRS
Supported
18
SendChargingInformationGPRS
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.
Interfaces
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
Supported
MAP_CHECK_IMEI response
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.
Interfaces
Message Type
Message Direction
V9.5.0/V10.8.0/V11.11.0
Echo Request
Supported
Echo Response
Supported
Supported
Identification Request
Supported
Identification Response
Supported
Supported
Supported
Supported
Supported
10
Supported
11
Supported
12
Supported
13
Supported
14
Supported
15
Supported
16
Supported
17
Supported
18
Supported
Table 33.
Message Type
Message Direction
V9.5.0/V10.8.0
Echo Request
Supported
Interfaces
Message Type
Message Direction
V9.5.0/V10.8.0
Echo Response
Supported
Supported
Supported
Supported
Supported
Supported
Supported
Supported
10
Not supported
11
Not supported
12
Not supported
13
Not supported
14
Not supported
15
Not supported
16
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).
Interfaces
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.
Message Type
Message Direction
V9.3.0
Echo Request
Receive only
Echo Response
Supported
Error Indication
Supported
Supported
G-PDU
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.
Interfaces
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
Supported
MAP_UPDATE_GPRS_LOCATION response
Supported
MAP_PURGE_MS request
Supported
MAP_PURGE_MS response
Supported
MAP_CANCEL_LOCATION request
Supported
MAP_CANCEL_LOCATION response
Supported
MAP_SEND_AUTHENTICATION_INFO request
Supported
MAP_SEND_AUTHENTICATION_INFO response
Supported
MAP_AUTHENTICATION_FAILURE_REPORT request
Supported
10
MAP_AUTHENTICATION_FAILURE_REPORT response
Supported
11
MAP-INSERT-SUBSCRIBER-DATA request
Supported
12
MAP-INSERT-SUBSCRIBER-DATA response
Supported
13
MAP-DELETE-SUBSCRIBER-DATA request
Supported
Interfaces
Message Type
Message Direction
V9.4.0/V10.8.0
14
MAP-DELETE-SUBSCRIBER-DATA response
Supported
15
MAP_RESET request
Supported
16
MAP_RESET response
Supported
17
MAP-PROVIDE-SUBSCRIBER-INFO request
Not supported
18
MAP-PROVIDE-SUBSCRIBER-INFO response
Not supported
19
MAP-ACTIVATE-TRACE-MODE request
Not supported
20
MAP-ACTIVATE-TRACE-MODE response
Not supported
21
MAP-DEACTIVATE-TRACE-MODE request
Not supported
22
MAP-DEACTIVATE-TRACE-MODE response
Not supported
23
MAP-SEND-ROUTING-INFO-FOR-LCS request
Not supported
24
MAP-SEND-ROUTING-INFO-FOR-LCS response
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.
Interfaces
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
Supported
BSSAP+-ALERT-REJECT
Supported
BSSAP+-ALERT-REQUEST
Supported
BSSAP+-DOWNLINK-TUNNEL-REQUEST
Not supported
BSSAP+-GPRS-DETACH-ACK
Supported
BSSAP+-GPRS-DETACH-INDICATION
Supported
BSSAP+-IMSI-DETACH-ACK
Supported
BSSAP+-IMSI-DETACH-INDICATION
Supported
BSSAP+-LOCATION-UPDATE-ACCEPT
Supported
10
BSSAP+-LOCATION-UPDATE-REJECT
Supported
11
BSSAP+-LOCATION-UPDATE-REQUEST
Supported
12
BSSAP+-MM-INFORMATION-REQUEST
Supported
Interfaces
Message Type
Message Direction
V9.3.0/V10.7.0/V11.7.0
13
BSSAP+-MOBILE-STATUS
Supported
14
BSSAP+-MS-ACTIVITY-INDICATION
Supported
15
BSSAP+-MS-INFORMATION-REQUEST
Supported
16
BSSAP+-MS-INFORMATION-RESPONSE
Supported
17
BSSAP+-MS-UNREACHABLE
Supported
18
BSSAP+-PAGING-REJECT
Supported
19
BSSAP+-PAGING-REQUEST
Supported
20
BSSAP+-RESET-ACK
Supported
21
BSSAP+-RESET-INDICATION
Supported
22
BSSAP+-TMSI-REALLOCATIONCOMPLETE
Supported
23
BSSAP+-UPLINK-TUNNEL-REQUEST
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.
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
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.
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.
Interfaces
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
messages supported for each of the configured versions.
Table 37.
Iu Messages
Message Type
Message Direction
V9.5.0/V10.9.0/V11.6.0
Supported
Supported
Supported
IU RELEASE REQUEST
Supported
IU RELEASE COMMAND
Supported
IU RELEASE COMPLETE
Supported
RELOCATION REQUIRED
Supported
RELOCATION REQUEST
Supported
Supported
Interfaces
Message Type
Message Direction
V9.5.0/V10.9.0/V11.6.0
10
RELOCATION COMMAND
Supported
11
RELOCATION DETECT
Supported
12
RELOCATION COMPLETE
Supported
13
Supported
14
RELOCATION FAILURE
Supported
15
RELOCATION CANCEL
Supported
16
Supported
17
Not supported
18
Not supported
19
Not supported
20
Supported
21
PAGING
Supported
22
COMMON ID
Supported
23
CN INVOKE TRACE
Not supported
24
Supported
25
Supported
26
Supported
27
Not supported
28
LOCATION REPORT
Not supported
29
Not supported
30
Not supported
31
INITIAL UE MESSAGE
Supported
32
DIRECT TRANSFER
Supported
33
Deprecated
NA
34
Deprecated
NA
35
Deprecated
NA
36
OVERLOAD
Not supported
37
RESET
Supported
38
RESET ACKNOWLEDGE
Supported
39
ERROR INDICATION
Supported
40
CN DEACTIVATE TRACE
Not supported
41
NA
42
RESET RESOURCE
Supported
43
Supported
44
Not supported
Interfaces
Message Type
Message Direction
V9.5.0/V10.9.0/V11.6.0
45
Not supported
46
Not supported
47
Not supported
48
Not supported
49
Not supported
50
Not supported
51
Not supported
52
Supported
53
Not supported
54
Not supported
55
Not supported
56
Not supported
57
Not supported
58
Not supported
59
Not supported
60
Not supported
61
Not supported
62
Not supported
63
Not supported
64
Not supported
65
Not supported
66
Not supported
67
Not supported
68
Not supported
69
Not supported
70
Not supported
71
Not supported
72
Not supported
73
Not supported
74
Not supported
75
Supported
76
Supported
Interfaces
Message Type
Message Direction
V9.5.0/V10.9.0/V11.6.0
77
Supported
78
Supported
79
NA
80
NA
81
Not supported
82
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.
Message Type
Message Direction
V9.5.0/V10.9.0
Supported
Supported
Supported
Not supported
Supported
Not supported
Not supported
Not supported
Supported
10
Supported
11
Released (RLSD)
Supported
12
Supported
13
Not supported
14
Not supported
15
Subsystem-allowed (SSA)
Supported
16
Subsystem-out-of-service-grant (SOG)
Not supported
17
Subsystem-out-of-service-request (SOR)
Not supported
18
Subsystem-prohibited (SSP)
Supported
19
Subsystem-status-test (SST)
Supported
Interfaces
Message Type
Message Direction
V9.5.0/V10.9.0
20
Unitdata (UDT)
Supported
21
Supported
22
Supported
23
Supported
24
Not supported
25
Supported
26
Supported
Table 39.
Message Type
Message Direction
V9.5.0/V10.9.0
Supported
Supported
Supported
Supported
Receive only
Supported
Supported
ASP Up
Supported
Supported
10
ASP Down
Supported
11
Supported
12
Heartbeat (BEAT)
Supported
13
Supported
14
Not supported
15
Not supported
16
Not supported
17
Not supported
18
ASP Active
Supported
19
Supported
20
ASP Inactive
Supported
21
Supported
22
Error
Supported
23
Notify
Supported
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.
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.
#
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
UE <- MME
Supported
13
EMM Information
UE <- MME
Supported
14
EMM Status
UE <-> MME
From UE only
15
UE -> MME
Supported
16
UE <- MME
Supported
17
UE -> MME
Supported
18
Identity Request
UE <- MME
Supported
19
Identity Response
UE -> MME
Supported
Interfaces
Message Type
Message Direction
V9.5.0/V10.10.0/
V11.13.0
20
UE <- MME
Supported
21
UE -> MME
Supported
22
UE -> MME
Supported
23
UE <-> MME
Supported
24
Service Request
UE -> MME
Supported
25
Service Reject
UE <- MME
Supported
26
UE -> MME
Supported
27
UE <- MME
Supported
28
UE -> MME
Supported
39
UE <- MME
Supported
30
UE -> MME
Supported
31
UE <-- MME
Supported
32
UE --> MME
Supported
Table 41.
Message Type
Message Direction
V9.5.0/V10.10.0
UE<-MME
Supported
UE -> MME
Supported
UE -> MME
Supported
UE <- MME
Supported
UE -> MME
Supported
UE -> MME
Supported
UE -> MME
Supported
UE <- MME
Supported
UE -> MME
Supported
10
MME->UE
Supported
11
UE <- MME
Supported
12
UE -> MME
Supported
13
UE <- MME
Supported
14
UE -> MME
Supported
15
ESM status
UE <-> MME
Supported
16
UE <- MME
Supported
17
UE -> MME
Supported
18
UE -> MME
Supported
Interfaces
Message Type
Message Direction
V9.5.0/V10.10.0
19
UE -> MME
Supported
20
UE <- MME
Supported
21
UE -> MME
Supported
22
UE <- MME
Supported
23
Notification
UE <- MME
Supported
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
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.
Interfaces
Table 42.
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
UE <- SGSN
Supported
14
UE -> SGSN
Supported
15
Identity Request
UE <- SGSN
Supported
16
Identity Response
UE -> SGSN
Supported
17
UE -> SGSN
Supported
18
UE <- SGSN
Supported
19
UE <- SGSN
Supported
20
UE -> SGSN
Supported
21
UE <- SGSN
Supported
22
UE -> SGSN
Supported
23
UE <- SGSN
Supported
Table 43.
Message Type
Message Direction
V9.5.0/V10.10.0
UE -> SGSN
Supported
UE <- SGSN
Supported
UE <- SGSN
Supported
UE -> SGSN
Not Supported
UE <- SGSN
Not Supported
UE <- SGSN
Not Supported
Interfaces
Message Type
Message Direction
V9.5.0/V10.10.0
UE <- SGSN
Not supported
UE -> SGSN
Not supported
UE <- SGSN
Supported
10
UE -> SGSN
Supported
11
UE -> SGSN
Supported
12
UE <- SGSN
Supported
13
UE <-> SGSN
Supported
14
UE -> SGSN
Supported
15
UE <- SGSN
Supported
16
UE <- SGSN
Not Supported
17
UE -> SGSN
Not Supported
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
vMME Product Overview
Document Status: 8.2, Draft
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
LIG->MME/SGSN
Supported
MME/SGSN->LIG
Supported
LIG->MME/SGSN
Supported
MME/SGSN->LIG
Supported
LIG->MME/SGSN
Supported
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.
Interfaces
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:
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.
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.
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 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.
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
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.
Scenario
RAT involved
UE State
Additional variations
Intra-MME X2 handover
Intra-LTE
Active
Intra-MME S1 handover
Intra-LTE
Active
Intra-MME TAU
Intra-LTE
Idle
Inter-MME S1 handover
Intra-LTE
Active
Inter-MME TAU
Intra-LTE
Idle
LTE->UMTS
Active
LTE->UMTS
Idle
Scenario
RAT involved
UE State
Additional variations
SGW relocation not required
LTE->GERAN
LTE->UMTS
Active or Idle
Active
LTE->UMTS
Idle
LTE->GERAN
Idle
LTE->HRPD
Active
LTE->HRPD
Idle
LTE->WiMax
Active or Idle
LTE->1xRTT
Active or Idle
Inter-RAT 4G to 3G CSFB
LTE->UMTS
circuit
Active or Idle
A Routing Area Update procedure is used regardless whether the UE is active or idle.
Scenario
RAT involved
UE State
Additional variations
Inter-RAT 4G to 2G CSFB
LTE->GSM
circuit
Active or Idle
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
Inter-node 3G to 3G handover
(SRNS)
Intra-UMTS
Active
Gn/Gp interface
S16 interface
SGW relocation required (S4-SGSN)
SGW relocation not required (S4SGSN)
Inter-node 3G to 3G RAU
Intra-UMTS
Idle
Gn/Gp interface
S16 interface
SGW relocation required (S4-SGSN)
SGW relocation not required (S4SGSN)
Intra-node 3G to 4G handover
UMTS->LTE
Active
Intra-node 3G to 4G TAU
UMTS->LTE
Idle
Scenario
RAT involved
UE State
Additional variations
Inter-node 3G to 4G handover
UMTS->LTE
Active
Gn/Gp interface
S3 interface
SGW relocation required
SGW relocation not required
Inter-node 3G to 4G TAU
UMTS->LTE
Idle
Gn/Gp interface
S3 interface
SGW relocation required
SGW relocation not required
Intra-node 3G to 2G RAU
UMTS->GERAN
Active or Idle
Inter-node 3G to 4G RAU
UMTS->LTE
Active or Idle
Intra-node 2G to 2G RAU
Intra-GERAN
Active or Idle
Inter-node 2G to 2G RAU
Intra-GERAN
Active or Idle
S16 interface
Gn/Gp interface
SGW relocation required (S4-SGSN)
SGW relocation not required (S4SGSN)
Intra-node 2G to 3G RAU
GERAN->UMTS
Active or Idle
Inter-node 2G to 3G RAU
GERAN->UMTS
Active or Idle
S16 interface
Gn/Gp interface
Scenario
RAT involved
UE State
Additional variations
SGW relocation required (S4-SGSN)
SGW relocation not required (S4SGSN)
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
SGW relocation required
SGW relocation not required
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.
Multicast Mode
Broadcast Mode
No subscription in database
Audio and/or video downloading for off-line use (download newspaper overnight, read in the
morning)
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.
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.
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
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.
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.
Guards against unauthorized EPS service usage (authentication of the UE by the network and
service request validation).
The vMME excels in delivering the above capability. This section discusses the UE security
management capability of the MME as well as the SGSN.
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.
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.
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.
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
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.
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.
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.
A-1
A-2
A-4
A-3
A-2
A-4
A-1
A-3
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).
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.
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.
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.
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:
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
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:
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.
First, higher number of RNC fan-out capability. The maximum number of RNCs supported is
4096.
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.
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.
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.
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
vMME Product Overview
Document Status: 8.2, Draft
mobility management events, which results in decreased signaling traffic between the core nodes and
further reduces the signaling load on the HSS/HLR.
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.
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.
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.
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:
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
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
TAI-FQDN (for
MME)
x-3gpp-sgw
x-s5-gtp:x-s5-pmip
(local PGW access)
Or
or
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
TAI-FQDN (for
MME)
x-3gpp-sgw
x-s5-gtp:x-s5-pmip
(local PGW access)
Or
or
x-s8-gtp:x-s8-pmip
(Incoming Roamer
Home PLMN PGW
access)
MME
Inter-MME TAU
MME-FQDN
x-3gpp-mme
x-s10
MME
TAI-FQDN
x-3gpp-mme
x-s10
SGSN
RAI-FQDN
x-3gpp-sgsn
x-gn:x-gp:x-s3:x-s16
SGSN
RNC-FQDN
x-3gpp-sgsn
x-gn:x-gp:x-s3:x-s16
GGSN
APN-FQDN
x-3gpp-ggsn
x-gn:x-gp
MSC
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:
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
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.
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.
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.
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.
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.
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.
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 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
This feature is available for both the SGSN function and the MME function.
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.
This feature is only applicable to the UE on the MME. No reporting is generated if the UE moves to
2G or 3G access.
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.
Version
Relevant Specification
V9.6.1
V10.7.0
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:
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
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.
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.
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
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:
Management Intervention
The following billing features trigger generation of partial S-CDRs with closure reason Management
Intervention:
Configuration Changes
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.
basis. This allows the IP backbone in the network to apply proper Per-Hop-Behavior when the IP
traffic passes through.
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.
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,
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.
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:
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
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
T-ADS data retrieval flag in Supported Feature AVP in the ULR and IDA
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
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.
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.
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.
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).
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.
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.
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.
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
vMME Product Overview
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:
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.
GGSN: The SGSN deactivates the PDP contexts for the UE upon the failure of the
GGSN.
system
engineering
feature
imsi-routing
interface
s1
iu
gb
s6
gr
etc
service-area
plmn
etc
subscriber
mobile-context
etc
csl
vMME Product Overview
dns
trace
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 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
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
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
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
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
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:
etc
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:
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
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.
Metric Name
Maximum Value
Attached Subscribers
4,160,000
PDN Connections
8,320,000
12,480,000
Tracking Areas
32,000
Routing Areas
3,000
600
30,000
4,096
25,000
15,000
Table 51.
Metric Name
Maximum Value
10
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.
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.
15,000 eNodeBs
Deployment suggestion:
Minimum of two vMMEs to form a pool. Both nodes are connected to the 15,000 eNodeBs.
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).
Deployment Examples
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
Deployment Examples
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
4,000 eNodeBs
40 3G RNCs
20 2G BSSs
Deployment Examples
Deployment suggestion:
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).
Deployment Examples
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
Deployment Examples
50,000 eNodeBs
30,000 eANs
Support roamers (for 4G LTE subscribers only, no need to interact with legacy MAP based
network
Deployment suggestion:
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.
Deployment Examples
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
200 3G RNCs
Deployment Examples
Deployment suggestion:
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.
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
Documentation Map
Document Name
Document Number
10-0100-082
20-0100-082
20-0101-082
Release Notes
30-0600-082
10-0140-082
10-0200-082
20-0200-082
20-0201-082
10-0130-082
10-0402-082
10-0403-082
10-0404-082
10-0405-082
10-0406-082
30-0300-082
30-0500-082
30-0501-082
30-0502-082
10-0150-082
10-0420-082
Document #
Document Title
Version
URL
TS 21.201
9.2.0
http://3gpp.org/specifications
TS 22.016
9.0.1
http://3gpp.org/specifications
TS 22.071
10.0.0
http://3gpp.org/specifications
TS 22.278
9.6.0
http://3gpp.org/specifications
TS 23.003
10.6.0
http://3gpp.org/specifications
Restoration procedures
10.7.0
TS 23.007
11.9.0
http://3gpp.org/specifications
11.8.0
TS 23.015
10.0.0
TS 23.040
11.5.0
http://3gpp.org/specifications
TS 23.041
10.6.0
http://3gpp.org/specifications
10.11.0
11.3.0
TS 23.060
TS 23.078
http://3gpp.org/specifications
11.3.0
11.6.0
http://3gpp.org/specifications
11.12.0
http://3gpp.org/specifications
Document #
Document Title
Version
URL
10.2.0
http://3gpp.org/specifications
TS 23.167
10.7.0
http://3gpp.org/specifications
TS 23.203
9.7.0
http://3gpp.org/specifications
TS 23.216
10.5.0
http://3gpp.org/specifications
Architectural requirements
10.2.0
TS 23.221
11.11.0
http://3gpp.org/specifications
11.3.0
TS 23.236
10.3.1
10.4.0
10.10.0
10.10.0
TS 23.402
10.8.0
http://3gpp.org/specifications
TS 24.007
10.0.0
http://3gpp.org/specifications
9.5.0
TS 24.011
11.1.0
http://3gpp.org/specifications
TS 24.030
10.0.0
http://3gpp.org/specifications
TS 24.080
10.0.0
http://3gpp.org/specifications
TS 23.271
TS 23.272
TS 23.401
TS 24.008
http://3gpp.org/specifications
11.0.0
http://3gpp.org/specifications
11.3.0
http://3gpp.org/specifications
11.9.0
http://3gpp.org/specifications
11.11.0
11.0.0
http://3gpp.org/specifications
10.10.0
11.13.0
11.0.0
Document #
Document Title
Version
URL
TS 24.171
10.0.0
http://3gpp.org/specifications
9.5.0
TS 25.410
11.0.0
http://3gpp.org/specifications
TS 25.411
11.0.0
http://3gpp.org/specifications
TS 25.412
11.0.0
http://3gpp.org/specifications
TS 25.413
9.5.0
http://3gpp.org/specifications
TS 25.414
11.0.0
http://3gpp.org/specifications
TS 29.002
9.4.0
http://3gpp.org/specifications
TS 24.301
11.0.0
http://3gpp.org/specifications
10.10.0
11.13.0
10.9.0
11.6.0
10.10.0
11.11.0
TS 29.016
11.0.0
http://3gpp.org/specifications
TS 29.018
9.3.0
http://3gpp.org/specifications
9.5.0
TS 29.060
10.7.0
11.7.0
http://3gpp.org/specifications
10.8.0
11.11.0
TS 29.078
9.2.0
http://3gpp.org/specifications
10.0.0
11.2.0
TS 29.118
TS 29.168
9.3.0
9.3.0
http://3gpp.org/specifications
10.7.0
11.11.0
http://3gpp.org/specifications
Document #
Document Title
Version
with EPC
10.2.0
URL
11.4.0
TS 29.171
TS 29.172
10.4.0
10.1.0
http://3gpp.org/specifications
11.3.0
http://3gpp.org/specifications
11.1.0
SLg interface
TS 29.202
11.0.0
http://3gpp.org/specifications
TS 29.229
9.3.0
http://3gpp.org/specifications
TS 29.230
10.9.0
http://3gpp.org/specifications
TS 29.272
9.5.0
http://3gpp.org/specifications
9.5.0
9.4.0
9.1.0
10.4.0
10.3.0
TS 29.274
TS 29.276
TS 29.277
TS 29.280
TS 29.281
10.10.0
11.11.0
http://3gpp.org/specifications
10.10.0
11.13.0
http://3gpp.org/specifications
10.3.0
11.11.0
http://3gpp.org/specifications
10.1.0
11.1.0
http://3gpp.org/specifications
11.6.0
http://3gpp.org/specifications
Document #
Document Title
Version
URL
10.4.0
http://3gpp.org/specifications
(GTPv1-U)
TS 29.303
11.3.0
TS 32.015
TS 32.240
9.6.1
9.0.0
http://3gpp.org/specifications
10.7.0
http://3gpp.org/specifications
10.1.0
11.7.0
TS 32.251
TS 32.295
10.9.0
9.0.0
http://3gpp.org/specifications
11.10.0
http://3gpp.org/specifications
10.0.0
11.0.0
TS 32.297
TS 32.298
9.0.0
9.6.0
http://3gpp.org/specifications
10.2.0
http://3gpp.org/specifications
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
http://3gpp.org/specifications
TS 32.421
10.5.0
http://3gpp.org/specifications
10.11.0
10.5.0
Telecommunication management;
Performance Management (PM)
Performance measurements
Evolved Packet Core (EPC)
network
10.4.0
TS 32.432
Telecommunication management;
Performance measurement: File
format definition
11.0.0
http://3gpp.org/specifications
TS 33.102
10.0.0
http://3gpp.org/specifications
TS 32.422
TS 32.423
TS 32.426
11.6.0
http://3gpp.org/specifications
11.11.0
http://3gpp.org/specifications
11.8.0
http://3gpp.org/specifications
11.4.0
Document #
Document Title
Version
URL
11.7.0
TS 33.106
10.0.0
http://3gpp.org/specifications
TS 33.107
10.4.0
http://3gpp.org/specifications
TS 33.210
10.3.0
http://3gpp.org/specifications
TS 33.310
10.5.0
http://3gpp.org/specifications
TS 33.401
Security Architecture
10.4.0
http://3gpp.org/specifications
11.4.0
11.7.0
TS 331.08
12.6.0
http://3gpp.org/specifications
TS 35.215
9.0.0
http://3gpp.org/specifications
TS 35.216
9.0.0
http://3gpp.org/specifications
TS 35.217
9.0.0
http://3gpp.org/specifications
TS 35.218
9.0.0
http://3gpp.org/specifications
TS 36.300
10.9.0
http://3gpp.org/specifications
10.5.0
10.4.0
TS 36.305
TS 36.401
11.12.0
http://3gpp.org/specifications
11.3.0
http://3gpp.org/specifications
Document #
Document Title
Version
11.2.0
10.3.0
10.1.0
10.1.0
10.6.0
TS 36.440
12.0.0
http://3gpp.org/specifications
TS 36.441
12.0.0
http://3gpp.org/specifications
TS 36.442
12.0.0
http://3gpp.org/specifications
TS 36.444
12.1.0
http://3gpp.org/specifications
TS 44.064
10.1.0
http://3gpp.org/specifications
Subnetwork Dependent
Convergence Protocol (SNDCP)
10.0.0
TS 48.014
11.0.0
http://3gpp.org/specifications
TS 48.016
10.0.0
http://3gpp.org/specifications
10.7.0
TS 36.410
TS 36.411
TS 36.412
TS 36.413
TS 44.065
TS 48.018
URL
http://3gpp.org/specifications
11.1.0
http://3gpp.org/specifications
11.0.0
http://3gpp.org/specifications
11.0.0
http://3gpp.org/specifications
11.8.0
11.0.0
http://3gpp.org/specifications
11.0.0
11.0.0
http://3gpp.org/specifications
Document #
Document Title
Version
URL
protocol (BSSGP)
Table 54.
Document #
Document Title
Version
URL
A.S0008-C
v2.0
http://www.3gpp2.org/Public_ht
ml/specs/index.cfm
A.S0009-C
v1.0
http://www.3gpp2.org/Public_ht
ml/specs/index.cfm
v2.1
A.S0013-C
A.S0014-D
v2.0
http://www.3gpp2.org/Public_ht
ml/specs/index.cfm
A.S0022-0
v1.0
http://www.3gpp2.org/Public_ht
ml/specs/index.cfm
C.S0024-A
v3.0
http://www.3gpp2.org/Public_ht
ml/specs/index.cfm
X.S0057 0
v2.0
http://www.3gpp2.org/Public_ht
ml/specs/index.cfm
Table 55.
http://www.3gpp2.org/Public_ht
ml/specs/index.cfm
Document #
Document Title
URL
RFC-1035
http://www.rfc-editor.org/rfc/rfc1035.txt
RFC-2126
http://www.rfc-editor.org/rfc/rfc2126.txt
RFC-2671
http://www.rfc-editor.org/rfc/rfc2671.txt
RFC-3588
http://www.rfc-editor.org/rfc/rfc3588.txt
RFC-4666
http://www.rfc-editor.org/rfc/rfc4666.txt
http://www.rfc-editor.org/rfc/rfc4960.txt
15 Glossary
Term or Acronym
Full term
1xRTT
3GPP
AAA
ABQP
ACL
ADC
Analog-to-Digital Conversion
ADMF
ADMF
Administration Function
AE
Application Entity
AES
AF
Access Function
AIS
AKA
AMBR
AMC
ANSI
API
APN
APN
APS
ARP
ASN.1
ASP
ATM
AVP
AWT
BBS
BH
Busy Hour
BIX
BS
Base Station
BS
Billing System
BSC
Base Station Controller - The BSC is in charge of the allocation and release of
Glossary
Term or Acronym
Full term
radio channels and handover management.
BSN
BSS
BSSAP
BSSGP
BT
Block Transfer
BVC
BVCI
CALEA
CAMEL
CallP
CAP
CAP
CAR
CATT
CBC
CC
Content of Communication
CDMA
CDP
CDR
CFDS
CGF
CGI
CK/IK
CLI
CM
Configuration Management
CMAS
CMN
CoMmoN
CN
Compute Node
CN
Core Network
CoS
Classes of Service
COTS
CP
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
CPU
CRC
CRR
CS
Circuit Switched
CS
Corporate Standards
CSCF
CSFB
CSG
CSGID
CSI
CSL
DC
Diameter Client
DDR
DF
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
DRT
DSCP
DST
DUPMS
DVL
eAN
ECC
ECGI
ECM
EDP
EIR
ELP
Glossary
Term or Acronym
Full term
EMC
Electromagnetic Compatibility
EMM
EMS
eNB
eNodeB
EP
Emission Priority
EPC
EPLMN
Equivalent PLMN
EPS
E-RAB
eRANAP
ESD
Electrostatic Discharge
E-SMLC
ETSI
E-UTRAN
EV-DO
EV-Data Optimized
FD
Functional Description
FFS
FGW
Femto Gateway
FIFO
FM
Fault Management
FP
Functional Processor
FPGA
FQDN
FQPC
FRS
FRS
FRU
FTP
FTS
FXA
RADIUS Interface
Ga interface
Gb interface
GBR
Glossary
Term or Acronym
Full term
GCSNA
Gd interface
Ge interface
GEC
GERAN
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
GMM
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
GPP
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
Gr interface
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
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
GTT
Glossary
Term or Acronym
Full term
GUMMEI
GUTI
GW
GateWay
HA
High Availability
HFN
HI1
HI2
HI3
HLR
Home Location Register - Used to store the subscription record, temporary data,
the serving-MSC number and VLR number of a mobile subscriber.
HPLMN
HRPD
High Rate Packet Data, also referred to as 1xEV-DO for high speed data over
CDMA
HSS
IAP
I/O
Input/Output
ICD
IDR
IE
Information Element
IEC
IEEE
ILF
IM
Installation Method
IMC
IMEI
IMEISV
IMS
IP Multimedia Services
IMSI
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
Glossary
Term or Acronym
Full term
IPMI
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
IRAU
IRI
Intercept-Related Information
ISC
ISD
ISO
ITU
IWMSC
IWS
InterWorking System
KASME
KPI
KS
Knowledge Services
KSI
KVM
LAI
LAN
LBB
LBO
Local Break-Out
LCF
LCS
Location Services
LCS-AP
LEA
LED
Light-Emitting Diode
LEMF
LI
Legal/Lawful Intercept
LI ID
LIAP
LICP
LIG
Glossary
Term or Acronym
Full term
LIPA
Local IP Access
LISP
LLC
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
LSAF
LSB
LSBF
LSOF
LSPF
LTE
LX
M3UA
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
MBR
MBSFN
MCC
MCE
M-CDR
Mobility CDR
ME
Managed Element
ME
Mobile Equipment
MF
Mediation Function
MLT
MM
Mobility Management
MMC
MME
MNC
MNO
MO
Managed Object
MO-LR
Glossary
Term or Acronym
Full term
MPC
MPU
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
MS-ISDN (MSISDN)
MSS
Multiservice Switch
MT-LR
M-TMSI
MVNO
NA
Not Applicable
NACC
NAPTR
NAS
NAS
NE
Network Element
NEAF
NEBS
NE-RAMS
NI-LR
NMIS
NOR
Notify Request
NPLI
NRI
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
NTP
Operations Administration and Maintenance - All the tasks necessary for providing,
maintaining, or modifying the services provided by a switching system.
OEM
Glossary
Term or Acronym
Full term
ODB
OID
Object Identifier
OM
Operational Measurement
OOS
Out Of Service
OS
Operating System
OTDOA
PCB
PCI
PCRF
PCU
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
PDN
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
PFC
PFE
PFM
PGW or P-GW
PDN Gateway
PHB
Per-Hop Behavior
PLM
PLMN
PM
Performance Management
PMC
POST
Power-On Self-Test
PPP
Point-to-Point Protocol
PS
Packet Switched
PSAP
Glossary
Term or Acronym
Full term
P-TMSI
PVI
PWS
QCI
QoS
Quality of Service
RAB
RAC
RADIUS
RAI
RAI-FQDN
RAM
RAN
RANAP
RAT
RAU
RDSP
RGMII
RIM
RLC
RM
Resource Manager
RNC
RoHS
RPC
RTM
S1-AP
S1 Application Protocol
SA
System Architecture
SAE
SAE-GW
Serving Gateway
SAF
SAI
SAS
SGSN Accounting Server - SGSN entity that provides the SGSN billing
functionality.
SATA
SC
Glossary
Term or Acronym
Full term
SCCP
S-CDR
SCF
SCP
Service Control Point - External entity used to manage Prepaid SMS subscriber
accounts.
SCTP
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
SDRs
SELV
SERDES
Serializer/Deserializer
SFP
SFTP
Secure FTP
SGMII
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
SIGTRAN
SIM
SLB
SLF
SMS
SMS
SMSC
SM-SC
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
Glossary
Term or Acronym
Full term
SNDCP layer
SNMP
SNOW3G
SNR
SNS
Sub-Network Services
SON
SPI
SRAM
SRNS
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
S-SMT-CDR
STP
STPx
SU
Service Unit
SX
TA
Tracking Area
TAC
TAI
TAS
TAU
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
TCP/IP
TDM
TDP
TEID
Glossary
Term or Acronym
Full term
TFT
TI
Technology Introduction
TIPC
TLLI
TLV
TODA
TPE
Twisted-Pair Ethernet
TTCT
UDP
UDP/IP
UE
User Equipment
UE-AMBR
UGL
UMTS
UP
U-plane
User plane - Function associated with the transfer of actual user data to and from a
PDN.
UPM
UPSM
USD
USIM
UMTS SIM
UTC
UTRA
UTRAN
UTRAN
VLAN
VLR
VM
Virtual Machine
VMM
VPLMN
XML