MME Technical Overview

Evolved Packet Core 9471 MME LM5.0.
1
Technical Overview
STUDENT GUIDE
TMO21024 Edition 5.1
COPYRIGHT ALCATEL-LUCENT 2012. ALL RIGHTS RESERVED.
Passing on and copying of this document, use and communication of its

contents not permitted without written authorization from Alcatel-Lucent
Copyright 2012 Alcatel-Lucent. All Rights Reserved.
Terms of use and legal notices

TERMS
OF to
USEnotes
AND LEGAL
NOTICE
Switch
view!
Alcatel-Lucent provides this training course to you subject to these Terms of Use and Legal Notice. Your use of this training
course and/or this site constitutes your acceptance of and agreement to these Terms of Use and Legal Notice. These Terms
of Use and Legal Notice, as well as the contents of this training course, may be updated or amended by Alcatel-Lucent from
time to time without prior notice to you. Your use of the Alcatel-Lucent training materials after such update or amendment
constitutes your acceptance of and agreement to said updated or amended Terms of Use and Legal Notice.
SAFETY WARNING
Alcatel-Lucent training materials can be for products or refer to products that have both lethal and dangerous voltages
present. Always observe all safety precautions and do not work on the equipment alone. The user is strongly advised not to
wear conductive jewelry while working on the products. Equipment referred to or used during this course may be electrostatic
sensitive. Please observe correct anti-static precautions.
PERMISSION TO USE CONTENT
The information, communications, scripts, photos, text, video, graphics, music, sounds, images and other materials provided in
this training course (collectively the "Content"), is intended for the lawful use of employees of Alcatel-Lucent and other
authorized participants in this Alcatel-Lucent training course. You are hereby granted a non-exclusive, non-transferable
permission to access and use the Content solely for your personal training and non-commercial use. This permission may be
terminated by Alcatel-Lucent at any time for any reason or no reason, with or without notice. You must immediately cease use
of the Content upon such termination.
COPYRIGHTS AND TRADEMARKS
The unauthorized copying, displaying or other use of any Content from this training course is a violation of the law and AlcatelLucents corporate policies. The Content is protected in France, the U.S. and other countries by a variety of laws, including but
not limited to, copyright laws and treaty provisions, trademark laws, patent laws and other proprietary rights laws (collectively,
"IP Rights"). In addition to Alcatel-Lucents IP Rights in the Content, in part and in whole, Alcatel-Lucent, and any of the third
parties
who have licensed and/or contributed to
the Content,
a copyright
in the formatting and presentation of the
2
COPYRIGHT
ALCATEL-LUCENTowns
2012. ALL RIGHTS
RESERVED.
Evolved Packet Core 9471 MME LM5.0.1
Content.
Technical Overview
Alcatel-Lucent does not grant you any permission to use the Content other than the permission expressly stated in these Terms
of Use and Legal Notice. All other use of Content from this training course, including, but not limited to, modification,
publication, transmission, participation in the transfer or sale of, copying, reproduction, republishing, creation of derivative
works from, distribution, performance, display, incorporation into another training course or presentation, or in any other way
exploiting any of the Content, in whole or in part, for uses other than those expressly permitted herein is strictly prohibited and
shall not be made without Alcatel-Lucents prior written consent. All characters appearing in this training course are fictitious.
Any resemblance to real persons, living or dead, is purely coincidental.
There may be a number of proprietary logos, marks, trademarks, slogans and product designations found in the
Content. Alcatel, Lucent, Alcatel-Lucent and the Alcatel-Lucent logos are trademarks of Alcatel-Lucent. All other trademarks are
the property of their respective owners. Alcatel-Lucent does not grant you a license to use any of the foregoing logos, marks,
trademarks, slogans and product designations in any fashion. Granting of the right to access and use the Content for training
purposes does not confer upon you any license under any of Alcatel-Lucents or any third party's IP Rights.
DISCLAIMER
ALCATEL-LUCENT DISCLAIMS ALL WARRANTIES REGARDING THE TRAINING COURSES OR THE CONTENT, EXPRESS OR
IMPLIED, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE. THE ALCATEL-LUCENT WILL NOT BE RESPONSIBLE OR LIABLE FOR ANY INJURY, LOSS, CLAIM,
DAMAGE, OR ANY SPECIAL, EXEMPLARY, PUNITIVE, INDIRECT, INCIDENTAL OR CONSEQUENTIAL DAMAGES OF ANY KIND
(INCLUDING WITHOUT LIMITATION LOSS PROFITS OR LOSS SAVINGS), WHETHER BASED IN CONTRACT, TORT, STRICT
LIABILITY OR OTHERWISE, THAT ARISES OUT OF OR IS IN ANY WAY CONNECTED WITH (A) ANY USE OR MISUSE OF THE
CONTENT OR THE TRAINING COURSES BY YOU, OR (B) ANY FAILURE OR DELAY BY ALCATEL-LUCENT, ITS OFFICERS,
DIRECTORS, AGENTS OR EMPLOYEES IN CONNECTION WITH THE CONTENT OR THE TRAINING COURSES (INCLUDING,
WITHOUT LIMITATION, THE USE OF OR INABILITY TO USE ANY COMPONENT OF THE CONTENT OR TRAINING BY
YOU). SOME JURISDICTIONS LIMIT OR PROHIBIT SUCH EXCLUSION OF WARRANTIES OR LIMITATION OF LIABILITIES AND
SO THE FOREGOING EXCLUSION OF WARRANTIES OR LIMITATION OF LIABILITY MAY NOT APPLY TO YOU.
GOVERNING LAW
These Terms of Use and Legal Notice are governed by the laws of France. The operation and use of the training course is
governed by the laws of the country that governs your employment contract, if applicable. If any provision of these Terms of
Use and Legal Notice, or the application thereto to a person or circumstance, is held invalid or unenforceable by law, statute or
a court of competent jurisdiction, for any reason, then such provision shall be modified and/or superseded by a provision that
reflects the intent of the original provision as closely as possible. All other provisions of these Terms of Use and Legal Notice
shall remain in full force and effect. You may not assign these Terms of Use or any permission granted hereunder without
Alcatel-Lucents prior written consent. Nothing herein shall be deemed an employment agreement or an offer of employment
or an alteration in any way of a users terms of employment with or within Alcatel-Lucent.
Copyright 2011 Alcatel-Lucent. All Rights Reserved
Course outline
4. Topic/Section is Positioned Here
@@TOC
Welcome to Evolved Packet Core 9471 MME for LM5.0.1
Technical Overview

1. 9471 MME in the LTE Network

2. Mobility Management Procedures
3. Session Management Procedures
4. Security Functions
5. 9471 MME Support for Roaming
6. Emergency, Warning, and MBMS Services
7. CDMA Interworking
8. UMTS/GSM Interworking
9. Hardware
10.Software
11.IP Addressing and Subnets
3
12.System Reliability

Technical Overview
13.Management Interfaces
A. Acronym list
B. Example UE Context
C. Example IP Addresses
D. Using Comment-Enabled PDF
Course objectives
Welcome
Upon completion
of Packet
this course,
should
to:
to Evolved
Coreyou
9471
MMEbe
forable
LM5.0.1
Technical Overview.
This course covers the 9471 MME in LTE End-to-End Release LE5.0: 9471 MME Release LM5.0.1,
Explain
the 9471
interacts
withR10.0
otherR1.
elements in the LTE network
Linux
Controlhow
Platform
(LCP)MME
CP5.0,
5620 SAM
to provide mobility management and session management functions
Locate and describe 9471 MME hardware components
Explain
theoffunction
of you
keyshould
9471 MME
software
components and applications
Upon
completion
this course,
be able
to:
Locate IP addresses for 9471 MME components, services, and subnets
Explain how
9471 MME interacts
other
elementsthe
in the
LTEMME
network to provide mobility
Identify
the the
management
systemswith
used
to manage
9471
management and session management functions

Explain the function of key 9471 MME software components and applications
Identify the management systems used to manage the 9471 MME
MME = Mobility Management Entity

LTE = Long Term Evolution
EPC = Evolved Packet Core
4
eUTRAN = Evolved Universal Terrestrial Radio Access Network


Technical Overview
Your feedback is appreciated!

Please feel free to Email your comments to:
training.feedback@alcatel-lucent.com
Please include the following training reference in your email:
TMO21024 Edition 1
Thank you!
About this course
Description
This course provides a foundation of knowledge to understand the 9471
Mobility Management Entity (MME) and how it fits in the LTE network.
Audience
The primary audience for this course includes those who need a technical
understanding of the MME functions in the LTE solution and of the MME
software and hardware components.
Course length
Two days

Technical Overview
Course prerequisites
You should have completed the following course prior to taking

this course, or have an equivalent understanding of LTE:
Alcatel-Lucent LTE Overview (TMO21054)
The following course, or an equivalent understanding of the EPC is

recommended:
Alcatel-Lucent LTE EPC Technical Overview (TMO21026)
Successful completion of this course requires basic knowledge of the

following:
LTE architecture and terminology, including Evolved Packet Core (ePC) and
eUTRAN
3GPP standards organization and where to find detailed information if needed
IP telephony, including IP addressing schemes and Ethernet connectivity
Telecommunications-grade equipment

Technical Overview
LTE = Long Term Evolution

EPC = Evolved Packet Core
eUTRAN = Evolved Universal Terrestrial Radio Access Network
3GPP = Third Generation Partnership Project
Do not delete this graphic elements in here:
Section 1
9471 MME Overview
Module 1
9471 MME in the LTE Network
EPC 9471 MME LM5.0.1

Technical Overview
All Rights Reserved Alcatel-Lucent 2012

Section 1 Module 1 Page 1
Blank page
112
9471 MME Overview 9471 MME in the LTE Network

EPC 9471 MME LM5.0.1 Technical Overview
This page is left blank intentionally
Document History
Edition
Date
Author
Remarks
01
YYYY-MM-DD
Last name, first name
First edition

Module objectives
Upon completion of this module, you should be able to:
Identify the LTE network elements that communicate with the 9471 MME
Identify the interfaces and protocols that support communication between the
MME and other LTE network elements
113
This module explains the role of the 9471 Mobility Management Entity (MME) in the LTE network.

Table of Contents
Switch to notes view!
1 LTE and 9471 MME quick review
2 Terminology
3 MME network interfaces and protocols
115

Page
7
16
35
1 LTE and 9471 MME quick review
117
This topic provides a quick review of LTE network components and their functions.

LTE architecture review
eUTRAN
EPC
S10
eNodeB
S11
OFDMA
SC-FDMA
Air
interface
HSS/EIR
MME S6a/S13
S1-MME
PGW
SGW
S5
SGi
S1-U
PCRF
PDN
Gx
Sh/LDAP
EPS = eUTRAN + EPC

User
118
Appendix A contains a list of acronyms used in this course.

The 3GPP LTE web site: http://www.3gpp.org/article/lte
Control
Long Term Evolution (LTE) is the newest 3GPP standard for mobile network technology.
LTE includes three key architectural elements:
Air interface that uses Orthogonal Frequency Division Multiplexing (OFDM) on the downlink,
Single Carrier Frequency Division Multiple Access (SC-FDMA) on the uplink, Multiple-Input MultipleOutput (MIMO) systems, and smart antennas for increased performance and flexible spectrum.
Evolved Universal Terrestrial Radio Access Network (eUTRAN) contains an evolved NodeB
(combines the functions of a NodeB and a Radio Network Controller) that communicates with the
User Equipment (UE) and the Evolved Packet Core (EPC).
The Evolved Packet Core (EPC) is an all-IP core network that manages mobility sessions.
The EPC and the eUTRAN together are called the Evolved Packet System (EPS).

EPC components review
eUTRAN
EPC
S10
eNodeB
HSS/EIR
MME S6a/S13
S11
OFDMA
SC-FDMA
S1-MME
PGW
SGW
S5
SGi
S1-U
PCRF
PDN
Gx
Sh/LDAP
User
Control
119
Components within the EPC:

Mobility Management Entity (MME) is a control-plane element responsible for mobility
management and connection management; manages thousands of eNodeBs. Control functions
include authentication, tracking, paging, choosing the SGW, bearer activation, handover control.
Alcatel-Lucent product is the 9471 MME.
Serving Gateway (SGW) routes and forwards user data packets and is the anchor point for interNodeB handover, and the anchor for mobility between LTE and other 3GPP networks. In standards,
SGW is also abbreviated S-GW. Alcatel-Lucent product is the 7750 Service Router (SR) SGW.
Packet Data Network gateway (PGW) connects the UE to packet data networks. The PGW is
the anchor for a data network for mobility between LTE and non-LTE technologies. The PGW
performs policy enforcement, packet filtering, charging support, and packet screening. In
standards, PGW is also abbreviated P-GW or PDN-GW. Alcatel-Lucent product is the 7750 Service
Router (SR) PGW.
The Policy and Charging Rules Function (PCRF) authorizes service data flows through
installation, modification and removal of Policy Control and Charging (PCC) rules. Provides the PGW
with QoS and charging information per service data flow. Alcatel-Lucent product is the 5780
Dynamic Service Controller (DSC) PCRF.

Other key components review
eUTRAN
EPC
S10
eNodeB
HSS/EIR
(DRA)
MME S6a/S13
S11
OFDMA
SC-FDMA
S1-MME
PGW
SGW
S5
SGi
S1-U
PCRF
PDN
Gx
Sh/LDAP
User
Control
1 1 10
Home Subscriber Server (HSS) provides subscriber database, authorization and authentication.
The HSS may support an Equipment Identity Register (EIR), or EIR may be standalone.
DRA
A Diameter Routing Agent (DRA) or Diameter Proxy Agent may be in the network to centralize
Diameter routing among Diameter clients/servers. In this case, the MME connects to the DRA,
which routes the messages to the appropriate HSS or EIR.

Separation of control plane and data plane
MME optimized for signaling.

SGW optimized to provide bearer services.
eUTRAN
eNodeB
EPC
S10
HSS/EIR
MME S6a/S13
S11
OFDMA
SC-FDMA
S1-MME
PGW
SGW
S5
SGi
S1-U
PCRF
PDN
Gx
Sh/LDAP
1 1 11
The separation of control and bearer functions allows each element to be optimized for its function
and to be scaled independently:
MME
provides only control-plane functions and is optimized for signaling.
SGW
provides mostly data-plane functions and is optimized to provide bearer services.
The
MME and SGW can be independently scaled or in different geographic locations.
Data plane
The data plane (also called user plane) provides bearer functions and carries user data packets.
It needs to address requirements for high bandwidth, high availability and scalability, with
aggregate throughput (per gateway) easily reaching over 100 Gb/s. At the same time, the data
plane needs to allow unaffected performance with sophisticated processing of millions of service
data flows and data bearers turned on, while being able to provide sophisticated, fine-granular (perapplication, per-service, per-user) QoS. A minimum of required control information may be included
in the data plane.
Control plane
The control plane is the portion of a channel or protocol that carries signaling and control data.
The control plane needs to address the requirements for high scalability and high availability of
secure mobility and connection management, along with highly reliable and scalable network-wide
policy and subscriber management.

LTE interworking with other networks

UMTS/GSM
eUTRAN
eNodeB
EPC
S10
HSS/EIR
MME S6a/S13
S11
OFDMA
SC-FDMA
PGW
SGW
S1-MME
S5
SGi
S1-U
PCRF
PDN
IMS
Gx
Sh/LDAP
EV-DO (eHRPD)
9471 MME support for interworking is described in more detail in later modules of this course.
1 1 12

A key feature of LTE and the Evolved Packet Core: In addition to carrying traffic, the EPC allows
connections and handover to other wireless access technologies, thus providing a seamless mobility
experience.
CDMA = Code Division Multiple Access
eHRPD = evolved High Rate Packet Data
GSM = Global Systems for Mobile Communications
IMS = IP Mulitmedia System
UMTS = Universal Mobile Telecommunications System

Support for shared networks

CN
CN
CN
CN
Operator
Operator
B
B
MultiOperator
Operator
Operator AA
Core
Network
(MOCN) Shared RAN
CN
CN
Operator
Operator
C
C
S1
Gateway Core Network (GWCN)
eNB
eNB
Operator X
GWCN
variant
CN
CN
Operator
Operator
A
A
CN
CN
Operator
Operator
B
B
CN
CN
Operator
Operator
C
C
Shared
Shared
MME/
MME/
SGW/PGW
SGW/PGW
Shared
Shared
MME/
MME/
SGW/PGW
SGW/PGW
Shared
Shared
MME/
MME/
SGW/PGW
SGW/PGW
eNB
eNB
Operator
Operator
A
A
eNB
eNB
Operator
Operator
B
B
eNB
eNB
Operator
Operator
C
C
CN
CN
Operator
Operator
A
A
CN
CN
Operator
Operator
B
B
CN
CN
Operator
Operator
C
C
Shared
Shared
MME/
MME/
SGW/PGW
SGW/PGW
Shared
Shared
MME/
MME/
SGW/PGW
SGW/PGW
Shared
Shared
MME/
MME/
SGW/PGW
SGW/PGW
S1
S1
1 1 13
eNB
eNB
eNB
eNB
eNB
eNB
Shared RAN
Operator X
3GPP Technical Specification 23.251 defines two architectures (GWCN and MOCN) to support
network sharing. In both architectures the radio access network is shared.
Multi-Operator Core Network (MOCN) Only the radio access network is shared.
Gateway Core Network (GWCN) The core network (CN) elements, such as MSCs, SGSNs and
MMEs, are also shared.
GWCN variant The Alcatel-Lucent LTE network also supports a variant of GWCN where the radio
access network is not shared. The MME and possibly the SGW/PGW are shared. Example application
of this variant: Public Safety sector, where the Public Safety agents may own and operate their
respective E-UTRAN radio access networks, but will share the EPC with a commercial LTE operator.
In the MOCN configuration, the system information broadcast in each shared cell contains the
Public Land Mobile Network (PLMN) ID of each operator and a single tracking area code (TAC) that
is valid within all the PLMNs sharing the radio access network. For a shared RAN, the operators that
share the RAN must be the same for all cells in a tracking area.
When eNB is shared, eNB includes multiple Broadcast PLMNs in the S1 Setup Request message to
the MME. The UE is responsible for selecting a PLMN from the broadcast PLMN list and will include
the selected PLMN identity when it establishes the RRC connection with the eNB. The MME refers to
the provisioned data that corresponds to the PLMN selected by the UE.
A shared MME scenario would be one MME owner who leases services to other operators.
Management would be shared from one 5620 SAM.

Support for 3GPP standards

9471 MME supports 3GPP Release 9, March 2011 standards.
http://www.3gpp.org/
1 1 14
3GPP Release 9, March 2011 standards are supported for all 9471 MME interfaces.
Exceptions:
The Gn interface (MME to pre-Release 8 SGSN) is Release 8, December 2010.
The SBc interface (MME to Cell Broadcast Center) is Release 9, December 2011.
The Sv interface (MME to 3G MSC) is Release 10, April 2011.
For a detailed listing of standards documents and versions supported by the 9471 MME, see the
9471 MME Technical Description customer document (418-111-200).

Selected Release 9 Change Requests (CRs) are also supported.

Knowledge check: LTE components

Match the LTE components with the most appropriate description:
1. MME
a. Routes user data to eNodeB
2. SGW
b. Provides the PGW with QoS and charging

information per service data flow.
3. PGW
c. Interacts directly with the UE and the EPC
4. PCRF
d. Connects the UE to the PDN
5. eNodeB
e. Provides mobility control functions

1
2
3
4
5
1 1 15
e
a
d
b
-c

2 Terminology
1 1 16
This topic explains key terms that you will need to know in order to understand subsequent sections
and modules in this course.

UE context
Data required to manage the state of the

connection.
MME
S10
eNodeB
UE
Subscriber data
Location
Bearer
Routing
Security keys
Authentication
Registration state
Connection state
...
HSS/EIR
S6a/S13
S11
S1-MME
S5
SGi
S1-U
SGW
1 1 17
PGW

A UE context is the set of session data that is required to manage the state of the connection for a
user equipment. Context information is obtained from various sources (such as the UE and the
HSS). It includes:
Subscriber
data
Location
and bearer information
Network
internal routing information
Security
keys
Authentication
Registration
vectors
and connection state
UE context data, or a portion of UE context data, is maintained at the following network elements to
manage a connection: UE, MME, PGW, SGW, eNodeB.
The terms UE context and UE session context are interchangeable.
Refer to 3GPP TS23.401 for 3GPP-supported context information fields and their descriptions.
Refer to the 9471 MME OAM&P customer document for a description of UE context data on the
9471 MME.

Non-Access Stratum
EPC
eUTRAN
eNodeB
MME
NAS
Uu
1 1 18
NAS
S1-MME
In
the control plane, the Non-Access Stratum (NAS) protocol runs between the MME and the
UE.
NAS
is used for control-purposes such as network attach, authentication, setting up of bearers,

and mobility management.
All
NAS messages are integrity protected by the MME and UE.

Public Land Mobile Network (1 of 2)

Any mobile wireless network intended for use by mobile subscribers.
PLMN number:
310 004
The MCC is a 3-digit string
that identifies a country within
the global mobile
telecommunications network.
1 1 19
The MNC is a 2 or 3 digit string

that identifies a network within
the scope of a mobile country
code.
Public Land Mobile Network (PLMN) is any mobile wireless network intended for use by mobile
subscribers.
Each operator providing mobile services has one or more PLMN.
PLMNs interconnect with:
Other
PLMNs and the Public Switched Telephone Network (PSTN)
Internet
service providers for data and internet access
A PLMN is identified by the Mobile Country Code (MCC) and the Mobile Network Code (MNC).
The ITU-T Recommendation E.212 defines mobile country codes: Annex to ITU Operational Bulletin
No. 932 15.V.2009) which you can find here: http://www.itu.int/oth/T0206000003/en

Public Land Mobile Network (2 of 2)

PLMN
term
Home
Description
Provisionable
The PLMN of the owner of the MME. One Home PLMN per
MME is required.
Notes: The Home PLMN may also refer to the PLMN to which
a UE is subscribed.
From MME node point of view, the MME "Home" is where you
are logged in.
Yes
A PLMN provisioned in an MME that is shared by multiple

operators. Shared PLMNs are treated the same as the Home
PLMN.
Yes
Equivalent Treated as equivalent to the Home PLMN for cell selection or
Yes
Other
PLMN belonging to other operators (previously called roaming

PLMN).
Yes
Visited
Network in which the UE is roaming.
Shared
handover.
Registered Last network where the UE was registered

Serving
Used in the context of a Shared MME: the PLMN selected to

serve a UE (can be the Home or a Shared PLMN).
1 1 20
The following PLMN terms are used at the 9471 MME:

The Home PLMN is PLMN of the owner of the MME. Each operator is assigned a Home PLMN to
uniquely identify itself in a wireless network. One Home PLMN is required per MME.
NOTE: The local MME is called the Home MME on the MME Node provisioning form. From a node
provisioning point of view, it is the MME to which you are logged in and are making changes for.
From a UE point of view, the Home MME is the MME whose Public Land Mobile Network (PLMN)
matches the UE PLMN.
An Equivalent PLMN is a network that the UE should treat as equivalent to the Home PLMN for
the purposes of PLMN selection, cell selection/reselection or handover. An E-PLMN may be, for
example, an LTE, UMTS, or CDMA network owned by the same operator in the same country. The
UE selects a cell belonging to the equivalent network, regardless of technology.
A Shared PLMN is a PLMN provisioned in an MME that is shared by multiple operators. Typically
the Home PLMN is the PLMN of the operator who owns or purchased the MME. The Shared PLMNs
are the PLMNs of the other operators who have service on the existing MME from which they are
sharing. The PLMNs that share an MME are treated the same as the Home PLMN by the MME. UEs
from a Shared PLMN are treated as Homers or Roamers based on the PLMN of the tracking area in
which they access the network.
A Visited PLMN is a network in which the UE is roaming, and not the Home PLMN of the UE (also
called the roaming PLMN).
A Registered PLMN is the PLMN where the UE last successfully registered.
The total number supported is 512: 1 Home; up to 3 Equivalent for the Home PLMN and up to 3
Equivalent for each Shared PLMN; up to 8 Shared; the rest would be Other (roaming). The first four
items are provisionable at the 5620 SAM.
Tracking Area (1 of 2)
TAU
MME
Tracking Area (TA):

Geographical area
eNB
eNB
Tracking Area Identity (TAI):

PLMN 310004
MCC+MNC+TAC
TAC 0x6400
TA1
TA2
TA update (TAU):
Tracks location and availability
Cell:
Single carrier or sector.
At least 3 cells per eNodeB.
TA3
1 1 21
TA4
A tracking area is a geographical area in which a mobile subscriber can freely roam without
informing the MME of its location (i.e., it does not need to send a tracking area update (TAU)). A
tracking area consists of one or more cells. TAs usually have multiple eNodeBs; the cells in an
eNodeB may support different tracking areas (each cell can be in a unique TA). Alcatel-Lucent
recommends that cells belonging to the same eNodeB be in the same TA.
When a UE is in the idle state, its location may not be exactly known. A TA represents an area in
which the UE was last registered, and it is necessary to page the UE in the TA to locate the UE in a
particular eNodeB.
TA update (TAU): Generated when a UE crosses the boundary from one TA to another TA (with
new TAI). The UE also periodically performs a tracking area update procedure to notify the MME of
its availability and location.
TAC: Each tracking area has a unique tracking area code (a number from 1 65535). The network
operator assigns the TAC values and assigns the eNodeB cells to them. The network operator also
provisions the TAC values into the MME, and assigns the TAC values to the different MME groups
and different SGW Pools. When there are multiple MMEs and SGWs in the network, the MME and
SGW selection algorithms depend on this mapping at the MME.
TAI: Identifies each TA: includes PLMN (MCC+MNC) and the TAC. If the MME is Shared, UEs are
treated as Homers or Roamers based on the PLMN of the TAI in which they access the network (the
selected PLMN). The PLMN of the UEs IMSI is used in addition to the selected PLMN to determine if
the UE is treated a Homer or Roamer.
Cell: A cell consists of a single carrier or single sector of the eNodeB. It is expected that at least 3
sectors will be configured per eNodeB (note that an eNodeB may support as few as one cell).
Tracking Area (2 of 2)
The MME uses TAs to:

Page the UE
Determine if new SGW needed
during HO, TAU
TA2
TA7
TA1
TA3
eNB1
TA8
TA4
TA6
TA9
The MME sends a TAI list to the UE

UE requests TAU only when it moves
to a TA that is not in current list.
TA5
TA placement strategies
Minimize frequency of TAUs
Saves UE battery life
Saves eNB/Air interface resources
Less signaling to MME
Cell
TAI list
Tracking Area
Optimize paging effectiveness

Avoid ping-pong scenarios at border
1 1 22
The design and placement of TAs is important for reducing the number of TAUs; for example, an
overlapped area might be placed where users move back and forth between TAs to lower the
number of TAUs, or ping-pong scenario.
The 9471 MME uses tracking areas for paging and to determine when a new SGW is needed during
handover procedures.
The MME also provides the UE with a list of registered tracking area identities (TAI list) during the
Attach and Tracking Area Update (TAU) procedures. The UE may move within any of these
registered tracking areas without triggering a location-based TAU.
The TAI list minimally includes the Last Registered TAI of the UE (this is the last seen tracking area
the TAI sent by the UE to identify its location during Attach or Tracking Area Update). The TAI list
may be provisioned to contain the following:
A
list of neighbors to the Last Registered TAI (used for special cases; normally neighbors are
not provisioned)
The
Old (previous) Last Registered TAI.
The
Older (before the previous) Last Registered TAI

Pooling (1 of 2)
eNodeBs, MMEs, and SGWs may be assigned to pools.

Pool A
MME-1
SGW-1
S10
S1-flex allows
eNodeB to
simultaneously
select more than
one MME.
MME-k
SGW-n
eNB
eNB
eNB
eNB
eNB
eNB
TA1
TA2
TA3
1 1 23

eNodeBs, MMEs, and SGWs may be assigned to pools to:

Improve
service availability
Reduce
MME and SGW relocation during handover
The UE is served by any of the MME/SGWs within a pool. No MME/SGW relocation required within
the MME/SGW pool during a handover.
The PGWs are not grouped into pools since there is no relocation of the PGW during a connection.
(However, there may be multiple PGWs in the network.)
S1-flex
The eNodeBs must support S1-flex, which provides capability for eNodeB to perform MME selection
function.
S1-flex allows the eNodeBs to be connected to more than one MME simultaneously; control traffic
from one eNodeB can be distributed across MMEs. A Relative MME Capacity, or Weight Factor is
assigned for each MME. Each eNodeB then assigns a UE to an MME proportional to its relative
capacity. This capability is known as S1-Flex. Relative MME Capacity and how it is determined is
described in a later module of this course.

Pooling (2 of 2)
Pool area: One or more TAs, served by one or more MME/SGW pools.
Pool A
MME-1
SGW-1
eNB
S10
Pool B
MME-k
MME-1
SGW-n
SGW-1
eNB
eNB
S10
MME-k
SGW-n
eNB
eNB
eNB
Border
eNB
eNB
eNB
eNB
eNB
eNB
TA1
TA2
TA3
TA4
TA5
TA6
1 1 24

Pool area:
One
A
or more TAs, served by one or more MME/SGW pools.
UE in a pool area may be served without changing the serving MME.
Pool
areas may overlap.
The concept of pool area (TS 23.401) comprises one or more Tracking Areas (TAs) that, from a
RAN perspective, are served by a certain group of MMEs.
MMEs have S1-MME connectivity to all eNodeBs within the pool area, and S10 connectivity to all
MMEs in the pool.
All eNodeBs within the pool area must have S1-U connectivity to SGWs.
MME pool: One or more MMEs.
If
the MME and pools are manually provisioned, LTE supports up to 8 MMEs in an MME pool,
and up to 8 MME pools (up to 64 S10 interfaces).
If
DNS is used to discover the MME, then the number of pools and MMEs per pool is unlimited,
though the number of MMEs known at one time using discovery is 128.
SGW pool: One or more SGWs.

If
the SGWs are manually provisioned, LTE supports up to 16 SGWs in an SGW pool per TA,
and up to 16 SGW pools.
Up
to 80 SGW are supported per TA if using DNS.

MME EPS Mobility Management (EMM) states
EMM-DEREGISTERED
EMM-REGISTERED
Detach
Attach
SR
TAU
1 1 25
EMM-REGISTERED
The
MME assigns this state to the UE up on successful completion of an Attach, Service

Request (SR), or Tracking Area Update (TAU) procedure.
In
this state, UE location is known to the MME at least to an accuracy of a tracking area.
UE is registered upon Attach or TAU: Registration occurs when a UE powers on, or requests
a service after a dormant period, or moves to a different tracking area, etc.
EMM-DEREGISTERED
In
this state, the UE is not reachable by the MME as it does not have valid location information
(tracking area).
UE
context is kept by the MME for a provisioned amount of time after deregistration deregistration is determined by a series of provisionable timers. The total default time before
the UE is detached/deregistered is about 6 hours.
Reasons
a UE may be unreachable: Does not respond to a page, powered off, out of network
or valid tracking area, attach request was rejected. An unregistered UE cannot request
services.
Changing states
The
MME changes the UE state from EMM-REGISTERED to EMM-DEREGISTERED state for

events like Detach, Attach Reject, TAU reject etc.
The
MME initiates a Detach after the UE has been idle for a period of time or powers off.

UE EPS Connection Management (ECM) states (1 of 2)
ECM-IDLE
Signaling
Connection
Released
ECM-CONNECTED
Signaling
Connection
Established
1 1 26
The UE connection management states are:

ECM-IDLE
A
UE in this state has no Non-Access Stratum (NAS) signaling connection between the UE and
MME.
No
radio bearer or bearer between SGW and eNodeB.
Bearer
between the SGW and PGW is maintained during the IDLE state so that the connection
can be quickly set up when there is a service request.
The
GUTI is also kept during the IDLE state.
The
UE continues to take cell measurements for cell selection or reselection and TAU.
Periodic tracking area update (TAU) is used to notify the availability of the UE to the
network. Note that a periodic TAU does not transition the UE to the ECM-CONNECTED state.
ECM-IDLE
is similar to the dormant state in EVDO networks.
Reasons
a UE may be idle: the UE is powered on and attached to the network, but is not
moving or using any service.
ECM-CONNECTED
A
UE in this state has NAS signaling connection with MME.
All
bearers are up.
The
UE location is known in MME with an accuracy of the cell ID at the serving eNB.
Reasons
a UE is connected: The UE is communicating with the MME, either to register, to

report a location change, or use a service such as email.
In
this state, not only MME has UE context, but also the SGW and PGW.

UE EPS Connection Management (ECM) states (2 of 2)
Transition to the ECM-CONNECTED state is initiated by:

Attach
TAU
Service Requests (Example: the user clicks a button to read email)
Transition to the ECM-IDLE state is initiated by:

eNodeB (Example: the UE is inactive, or the connection is released)
MME (Example: there is authentication failure or resource problem)
When the UE is in the ECM-IDLE state, timers are triggered at the MME to
initiate the Detach procedure.
Timer values can be modified at the 5620 SAM.
1 1 27

Timers are described in the 5620 SAM LTE Parameter Reference (3HE 06982 AAAA).
The timer T3412 is started when the UE is in the ECM-IDLE state and stopped when the UE enters EMMCONNECTED state. The following timers determine when the UE is detached from the EPC network due to
inactivity. The total default time before the UE is detached is about 6 hours.
For more information about states, refer to the 3GPP web site:
http://www.3gpp.org/ftp/Specs/html-info/23401.htm
3GPP
23.401
3GPP
24.301
Timer
Purpose
Range (Default value)
T3412
UE period for sending a TAU.

This timer does not run when the UE is in the
ECM-CONNECTED state
6 minutes 186 minutes

(120 minutes)
Mobility_Reachable If T3412 expires, minutes beyond T3412

expiration before taking action.
1 minute 60 minutes
(4 minutes)
MME-InitiatedDetach
If Mobility_Reachable expires, MME-Initiated- 60 minutes -1500

Detach timer starts. If the MME-Initiatedminutes
Detach timer expires, the UE is detached from (240 minutes)
the network, all bearers are deleted, and MME
recovers the memory used for the UE context.
Purge Timer
Will allow the UE context to remain on the

MME for a provisioned period of time.
1-120 hours
(48 hours)
When the UE is registered but idle.
What happens when the UE is in EMM-REGISTERED and ECM-IDLE states?

The UE still communicates with the MME.
MME
TAU
SR
Paging
UE states are stored by the MME in the UE context.

1 1 28
When the UE is in EMM-REGISTERED and ECM-IDLE states, it still communicates with the MME:
Performs
Answers
Performs
send
normal and periodic tracking area updates

to paging by performing a service request procedure
the service request procedure to set up the radio bearers when there is uplink data to
Both UE and network (MME, SGW and PGW) keep bearer contexts that were not deactivated. The
MME keeps state information in the UE context so that it knows whether the UE is idle. Periodic TAU
is not performed when the UE is in the ECM-CONNECTED state.

Access Point Name
APN is the name assigned to a PDN.

A mobile user subscribes to one or more APNs.
One is the default APN.
One may be a wildcard (unsubscribed) APN.
The UE receives the IP address for the APN when it attaches to the
network.
eUTRAN
eNodeB
S1-MME
MME
S10
EPC
HSS
S6a/S13
S11
PGW
SGW
S5
SGi
S1-U
1 1 29
PDN:
acme.com
intranet
APN
An Access Point Name (APN) is used as a reference point for an external Packet Data Network (PDN)
that supports the services to be accessed by a UE. Examples of PDNs are:
Operator's managed services network (for example, for IMS VoIP)
Enterprise / corporate network
Public internet
The PGW is the network element that provides UE access to a specific Access Point Name (APN) in
the PDN.
The APN information is permanently distributed and maintained in the HSS, the PGW, and the
Domain Name Server (DNS). A set of APN labels is defined in the HSS. Each mobile user can
subscribe to one or more APNs from this set. The labels of these subscribed APNs are then
stored in the UE at subscription time.
Among the subscribed APNs there is one default APN. A user can connect to any subscribed APN. If
a user attempts to access a service without specifying the APN, then the default APN is used.
A user normally has one default bearer to an APN, but may have two default bearers - one IPv4
bearer and one IPv6 bearer - if "multiple PDN IPv4v6" is provisioned at the MME and PGW, and
the HSS subscription allows IPv4v6.
The HSS may also define a Wildcard APN (*) which allows a UE to access any unsubscribed APNs.
When the wild card APN is present in the subscription context, the UE is authorized to connect
to APNs that are not present in the subscription context.
The default APN cannot be a wildcard APN - it always contains an explicit APN. The UE can connect
to only one APN wildcard. When subscription data from the HSS is provisioned with two wildcard
APNs, the MME rejects the data.

Commonly-used identities (1 of 2)
ID
Purpose
Assigned by
IMSI
International Mobile Station Identity

assigned to each mobile in the EPS network.
Service provider
TMSI
Temporary Mobile Station Number (TMSI)

supports subscriber identity confidentiality
service.
A TMSI assigned by MME is

called M-TMSI.
For paging, the MME assigns
an S-TMSI.
IMEI
International Mobile Equipment Identity is a

globally unique number that identifies a
physical mobile station equipment.
An IMEISV includes the software version
number in the identity.
Equipment manufacturer
EPS
Identifies EPS bearer for one UE accessing the MME
Bearer ID network via eNodeB.
1 1 30
The International Mobile Station Number (IMSI) is assigned to each mobile subscriber in
GSM/UMTS/EPS systems. The maximum number of digits used for IMSI is 15. The IMSI is made up
of Mobile Country Code (MCC) (3 digits) + Mobile Network Code (MNC) (2-3 digits) + Mobile
Subscriber Identification Number (MSIN) (9 or 10 digits). In EPS, S-TMSI is used to page a mobile
(the S stands for SAE, or System Architecture Evolution)). Refer to upcoming GUTI definition for
more information on M-TMSI.
In UMTS and GSM networks, the number uniquely identifying a subscriber is called the Mobile
Subscriber ISDN Number, (MSISDN). MSISDN is the telephone number to the SIM card in the
phone).
The International Mobile Equipment Identity (IMEI) is consists of three fields, including an 8bit regional code to identify origin, a 24-bit manufacturer code, and a 24-bit manufacturer-assigned
serial number. The MME may verify the IMEI with an Equipment Identity Register (EIR). Unlike the
CDMA Mobile Equipment Identifier (MEID) of CDMA and other wireless networks, the IMEI is only
used to identify the device and has no relation to the subscriber. The IMEISV includes an extra 8-bit
field for the software version number.
ePS Bearer ID identifies an EPS bearer for one UE accessing via eUTRAN (eNB). The EPS Bearer
Identity is allocated by the MME and is unique across UE, eNodeB, MME, SGW, and PGW.
UMTS notes on TMSI
TMSI
A
assigned by the MSC is called TMSI.
TMSI assigned by the UMTS SGSN is called P-TMSI.

Commonly-used identities (2 of 2)
ID
Purpose
Assigned by
GUTI
Globally Unique Temporary Identity provides

UE identity without revealing UE or user.
GUTI is assigned by the MME.

GUMMEI is assigned by the
service provider.
GUTI
GUMMEI
MCC
MNC
MME Group ID
MME ID
48 bits
M-TMSI
MME
Code
32 bits
A UE can attach to the network using an IMSI or a GUTI.

1 1 31

The Globally Unique Temporary Identity (GUTI) provides an identity for the UE that does not
reveal the UE or the users identity. The GUTI has two components:
Globally
Unique MME Identifier (GUMMEI) that identifies MME that assigned the GUTI, and
M-TMSI
which identifies a UE within the MME that allocated the GUTI.
The GUTI becomes invalid when the UE moves to an EMM-deregistered state and the UE EMM
context is detached. This can happen for example when the UE is powered off, or when the UE is
relocated to another MME.
GUMMEI
The GUMMEI consists of MCC, MNC and MMEI (MME Identifier). The MMEI is constructed from a 2octet MME Group ID (MMEGI) and a 1-octet MME Code (MMEC). These are assigned by the service
provider. A Shared MME can have up to 9 GUMMEI, one for the Home PLMN and one for each
Shared PLMN (up to 8). The MMEI would be the same, but MCC/MNC would be different for each.
For paging purposes, the mobile is paged with the S-TMSI. The S-TMSI is constructed from the
MMEC and the M-TMSI.
A GUTI may be reallocated periodically, depending on operator network. A UE will remember its
GUTI after it detaches from the network. However, after a period of time the MME will no longer
have information about the GUTI, and may request an IMSI when the UE attempts to re-attach with
a GUTI.
There are many other IDs, including:
eNB
S1AP UE ID identifies a UE on S1 reference point within the eNB. It is unique within eNB.
MME
S1AP UE ID identifies a UE on S1 reference point within MME. It is unique within MME.

Knowledge check: Terminology

If the UE is in the EMM-DEREGISTERED state, the MME still has
information about its location.
True
False
False, the MME does not have valid information about

the location of the UE in this state.
1 1 32


If the UE is in the ECM-IDLE state, a NAS signaling connection and radio
bearers are maintained to create an "always on" environment for the user.
True
False
False, the radio bearers and NAS signaling are not maintained in
the IDLE state. The bearer between PGW and SGW is
maintained so that connections can be quickly set up.
1 1 33


A UE can attach to the EPS network using which of the following
identifiers? (More than one choice may be correct.)
A.
B.
C.
D.
IMSI
TMSI
GUTI
M-TMSI
1 1 34
A and C

3 MME network interfaces and protocols
1 1 35
This topic describes the 9471 network interfaces and supporting protocols.

LTE EPS interfaces supported

Lawful Intercept
X1_1, X2
EIR
eUTRAN
MME
HSS
S6a
S10
eNodeB
EPC
S13
S11
PGW
SGW
S1-MME, NAS
S5
PDN
S1-U
1 1 36
SGi
EPS = Evolved Packet System, which includes eUTRAN plus EPC networks.
DSCP
Provisioning of Differentiated Services Code Point (DSCP) is supported on lawful intercept and all
network interfaces.
DSCP is a mechanism for classifying and managing IP traffic and providing Quality of Service (QoS)
guarantees. DSCP is a field in the IP packet header identifying which class that particular packet is
in.
The 9471 MME supports provisioning of DSCP on network interfaces. Various DSCP values can be
provisioned on the Interface Profile provisioning page for:
Lawful
All
intercept interfaces (X1_1, X2)
network interfaces:
GTP/UDP: S11, S10, Gn, Sv, S3, Sm
SCTP: S1-MME, S6a, SGs, S13, and SBc, SLs, SLg, M3
Provisioning of DSCP on the OA&M interfaces is not supported at this time.

Other interfaces supported
Gn, SGs, and S3 interfaces are described in the UMTS/GSM interworking module of this course.
SBc, SLg, SLs, Sm, and M3 interfaces are described in the Emergency, Warning, and Multimedia
Broadcast services module of this course.

S1-MME
S10
eNodeB
MME
EIR
S13
S1-MME
S11
Reference point between the eUTRAN and

the MME.
S1-U
HEARTBEAT
HEARTBEAT-ACK
Protocols:
SGW
HSS
S6a
HEARTBEAT can be sent

by eNodeB or MME.
S1 Application Protocol (S1-AP)

Application layer
SCTP over IPv4 or IPv6 for control plane

Connection is always up
SCTP supports heartbeat function
SCTP implementation:
Single-homing or Multi-homing between
MME and eNodeB is supported
Multi-streams are supported. For example:
Stream 0 non-UE related S1AP messages
Stream 1 UE-related S1AP messages
eNodeB initiates the connection
1 1 37
Support for dual stack IPv4 or IPv6 is

described in the IP section of this training.
S1-MME is the reference point for the control plane between the eUTRAN and the MME.
S1 Application Protocol (S1-AP): Application Layer Protocol between the eNodeB and the MME.
S1-AP procedures are defined in 3GPP TS 36.413. MME supports all the major functions of the S1
application protocol.
Stream Control Transmission Protocol (SCTP) for the control plane: This protocol
guarantees delivery of signaling messages between MME and eNodeB (S1).
SCTP setup:
Upon initialization, an eNodeB sets up an SCTP connection with all the MMEs of an assigned
MME pool.
MME accepts the SCTP connection for the provisioned eNodeB IP addresses.
After successful setup of SCTP connection, eNodeB sends an S1 Set up message to exchange
application data needed for eNodeB and MME to inter-operate correctly on the S1 interface.
The SCTP association is always up.
eNodeB always initiates the connection; in case of MME restart after initialization, MME sends
an INIT message to eNodeB, and the eNodeB initiates the connection.

Support for optional multi-homing

Multi-homed SCTP paths
IP Address P
(Primary)
Peer Node
MME
(SCTP
endpoint)
IP Address S
(Secondary)
PATH
P to P
PAT
HS
to S
1 1 38
Router
1
Router
3
Router
2
Router
4
PAT
H
IP Address P
P to
to S
H S
PA T
Peer Node
eNB
(SCTP
endpoint)
IP Address S
SCTP multi-homing supports multiple SCTP paths between two SCTP endpoints to increase the
transport reliability. To support local multi-homing, the MME is configured with 2 or 4 IP addresses
on the SCTP interfaces (2 IPv4 addresses; one primary and one alternate, and/or 2 IPv6 addresses.
Each connection link needs to be all IPv4 or all IPv6, but multiple links can exist for a given
interface, some can be IPv4 and others IPv6.
Provisioning of up to two remote IP addresses for an SCTP peer is supported when the MME
interfaces with a remote SCTP peer that supports multi-homing.
The selection of Single Homing vs. Multi-Homing for a particular interface is determined at the
time of field installation. Additional IP addresses can be grown using the MME command line
interface.
The primary destination address is selected by the SCTP endpoint by default.
Each path is terminated at a different physical port.
The SCTP protocol manages redundancy over the separate paths.
The heartbeat support occurs on both the primary and the alternate paths.
Alarms are reported if a path of a multi-homed SCTP connection becomes unavailable or if
there is a provisioning data mismatch.

Relationship of SCTP association to streams
SCTP association
Stream 0
Peer
(MME)
Stream 1
Stream 2
Peer
(eNB)
Stream N
1 1 39
SCTP Multi-Streaming partitions data into multiple streams that are independently sequenced so
that message loss in one stream will only initially affect delivery within that stream. Transport is
done within a single SCTP association - all streams are subjected to a common flow and congestion
control mechanism, reducing transport overhead.
The 9471 MME currently supports SCTP multi-streaming on the S1, S6a, SGs, and SBc interfaces.
For the S1, SGs, and SBc interfaces, multi-stream is applied automatically, and there are two
streams: one for management messages and one for other data.
For the S6a interface, the streams can be provisioned in the Interfaces Profile at the 5620 SAM:
From 1-10 outbound and inbound streams are provisionable (the default setting is 1 inbound
and 1 outbound). The HSS must also support multi-streams.
Outbound streams: MME selects a stream to send using the round-robin selection method.
Inbound streams: MME processes streams as if they are from a single stream.

NAS
eNodeB
Uu
S10
MME
EIR
S13
S1-MME
S11
S1-U
SGW
HSS
S6a
Non-Access Stratum runs between the

MME and the UE.
The peer-to-peer connection is
concatenation of RRC and S1AP.
Protocols are terminated at the MME, rather
than eUTRAN.
1 1 40

EMM = Evolved Mobility Management

ESM = Evolved Session Management
PDCP = Packet Data Context Protocol
MAC = Medium Access Control
L1 = Layer 1
As described in an earlier slide: In the control-plane, the NAS protocol runs between the MME and
the UE, and is used for control-purposes such as network attach, authentication, setting up of
bearers, and mobility management. All NAS messages are ciphered and integrity protected by the
MME and UE.
NAS is the highest stratum of the control plane between UE and MME at the radio interface.
The NAS protocol is a peer to peer S1 mode connection between UE and MME. A NAS signaling
connection consists of the concatenation of an Radio Resource Control (RRC) connection via the
"LTE-Uu" interface and an S1AP connection via the S1 interface.
NAS protocols are the protocols between UE and MME that are not terminated in the eUTRAN.
The Non-Access Stratum protocols define procedures between UE and MME for mobility
management and session management. The MME NAS implementation complies with 3GPP TS
24.301 standards.

NAS messages and cause codes
NAS messages include many information elements (IEs) such as the IMSI.
A message may include a cause IE
Identifies the reason for a failed UE request
1
Attach Request message

IE: IMSI
Attach Reject message

IE: 02-IMSI Unknown
Uu
Authentication Request
MME
S10
HSS
S6a
S1-MME
S11
SGW
IMSI Unknown
3
S1-U
eNodeB
1 1 41
S1-AP and NAS messages are sent between the eNodeB and MME or the UE and MME to support
procedures such as Attach, Paging, and Handover. Messages are made up of various information
elements (IEs), such as the mobile identity (IMSI) and EPS bearer context status, as specified by
3GPP technical specifications.
IEs in a given message may contain cause codes that provide supporting information to help
interpret failure causes associated with 9471 MME procedures. The MME maps GTPv2 cause codes
received from the SGW to the appropriate NAS Cause Code that are sent toward the UE.
At the 9471 MME, operators can use defaults or provision specific NAS cause codes for each PLMN
to be sent in rejected UE Attach, Tracking Ares Update (TAU), and Service Request procedures, or
may choose to use default NAS cause codes.
Operators may also choose to send the S1-AP, EMM, and ESM cause codes to the SGW in S11
messages - the SGW will include these cause codes to populate diagnostic codes of charging data
records (CDRs). Cause codes can be included in the following message types to the SGW: Create
Bearer Response, Delete Session Request, Delete Bearer Command, Delete Bearer Response,
Release Access Bearer Request and Update Bearer Response.
Example Cause code: If an Attach Request message is not sent with the PDN Connectivity
Request, or the Evolved Packet System (ePS) attach type information element (IE) is not set to
initial ePS attach, then the MME sends an Attach Reject to the UE with cause code #19 (Evolved
Session Management (ESM) procedure failure).
References: S1-AP messages are specified in 3GPP TS 36.413. S1-AP. Information elements that
make up a given message may contain cause codes/values as defined in:
S1-AP cause codes/values - 3GPP TS 36.413
Enhanced Mobility Management (EMM) cause codes/values - 3GPP TS 24.301
Enhanced Session Management (ESM) cause codes/values - 3GPP TS 24.301
EMM and ESM procedures are described in the next module of this course.
S6a
eNodeB
S1-MME
S10
MME
HSS
S6a
S11
SGW
S1-U
Reference point between MME and:

HSS, or
Diameter Routing Agent/Diameter Proxy
Agent
Protocols:
eNodeB
S1-MME
DIAMETER
HEARTBEAT
HEARTBEAT can be
sent by HSS or MME.
S10
HEARTBEAT-ACK
MME
S11
AAA Application protocol
DRA/DPR
S6a
S1-U
SGW
SCTP over IPv4 or IPv6 for control plane

Connection is always up
SCTP supports heartbeat function
HSS
DIAMETER
DIAMETER
SCTP
SCTP
IP
IP
L2
L2
L1
L1
SCTP implementation on MME:

Single-homing or Multi-homing
Multi-streams are supported
MME initiates the connection
MME
1 1 42
S6a
HSS or
DRA/DPA
S6A enables the transfer between MME and HSS of subscription and authentication data in order to
authorize user access to the evolved system. S6A procedures are defined in 3GPP TS 29.272.
Diameter Routing Agent/Diameter Proxy Agent
An operator may use a Diameter Routing Agent (DRA) / Diameter Proxy Agent to centralize
Diameter routing in the network and streamline Diameter traffic within and across the EPC and IMS
networks. Mixed connections are not supported the MME connects to either all HSS or all DRAs.
When a Diameter request is received by a Diameter Proxy Agent/DRA from the MME, the Diameter
Proxy Agent determines the HSS identity based on the provided user identity and forwards the
Diameter request directly to the HSS. The user identity to HSS resolution decision is communicated
to the MME in the response. The MME then stores the HSS identity/name/Realm and uses it in
further Diameter requests to the same user identity.
DIAMETER protocol: is specified in RFC 3558 and defines minimum requirements for AAA
protocol.
SCTP for the control plane (SCTP): The SCTP protocol transfers signaling messages. The
Diameter messages on the S6a interface between the MME and an HSS are transported over
SCTP/IP. Either single-homing or multi-homing is supported.
The MME initiates the establishment of the SCTP association toward the HSS. When the MME sets
up a SCTP association with a remote SCTP peer, the MME chooses its local IP addresses (IPv4 or
IPv6) to match the IP address type (IPv4 or IPv6) of the remote SCTP peer. IPs are configured at
the 5620 SAM.

S13
eNodeB
S1-MME
S10
MME
EIR
S13
S11
HSS
SGW
S1-U
S6a
Reference point between MME and EIR.

HEARTBEAT
HEARTBEAT can be
sent by EIR or MME.
Protocols:
HEARTBEAT-ACK
Diameter messages use SCTP protocol

Single-homing or Multi-homing supported
The S13 interface application:

Allows a validity check of the ME Identity
DIAMETER
DIAMETER
S13 message ECR (ME-Identity-CheckRequest)

S13 message ECA (ME-Identity-CheckAnswer)
SCTP
SCTP
IP
IP
L2
L2
L1
L1
MME
S13
EIR
The Identity Check Procedure is executed as part of the Attach procedure and is an
operator-provisionable feature.
1 1 43
S13 enables the UE Identity Check Procedure between the MME and the Equipment Identity
Register (EIR) as described in the 3GPP TS 23.401 (related messages are defined in the TS).
The MME also supports an EIR that is co-located with the HSS. In this case, the S13 reference point
between MME and EIR is implemented over the S6a interface.
EIR background
The Mobile Equipment Identity (ME Identity) Check Procedure permits the operator of the MME,
HSS, and/or the PGW to check the mobile equipment's identity (for example, to check that it has
not been stolen, or to verify that it does not have faults).
The ME Identity can be checked by the MME passing it to an EIR and then the MME analyzing the
response from the EIR in order to determine its subsequent actions (for example, sending an Attach
Reject if the EIR indicates that the Mobile Equipment is blacklisted).

S11
eNodeB
S1-MME
S10
MME
EIR
S13
S11
S1-U
HSS
SGW
S6a
Reference point between MME and SGW.

ECHO REQUEST sent
by SGW and MME.
Protocols:
ECHO REQUEST
ECHO RESPONSE
GTP-C
Tunnels messages between MME and SGW
to set up EPS bearers.
UDP/IPv4 or UDP/IPv6
Transfers signaling messages.
GTP-C
GTP-C
UDP
UDP
IP
IP
L2
L2
L1
L1
MME
1 1 44
S11
SGW
MME supports up to 16 SGWs in a pool and 16 pools. For each SGW Pool ID, the MME is
provisioned with the S11 IP address of each SGW node that is a member of that SGW Pool.
GPRS Tunneling Protocol for the control plane (GTP-C): This protocol tunnels signaling
messages between MME and SGW to set up EPS bearers. GTP tunnels are used to separate traffic
into different communication flows. GTPv2 is used for S11 interface. GTPv2 and GTP are specified in
3GPP TS 29.274 and 29.060.
User Datagram Protocol (UDP): This protocol transfers signaling messages. UDP is defined in
RFC 768.
The GTP path between MME and SGW is monitored using the GTP messages Echo Request and
Echo Response. The failure of the peer entity is identified in two cases:
No
response after 3 successive ECHO REQUESTS
The
peer indicates in the ECHO RESPONSE message restart counter that it has
restarted.

MME
S10
eNodeB
S1-MME
S10
MME
S11
Reference point between MMEs in a pool

and across MME pools.
Used to:
S1-U
ECHO REQUEST
ECHO RESPONSE
Transfer a UE context to another MME in

the case of MME relocation from old MME
to new MME during handover.
Retrieve a UE context from another MME
during Attach.
Manual MME load rebalancing
Protocols:
GTP-C
Tunnels signaling messages between the
MMEs
EIR
S13
HSS
SGW
S6a
ECHO REQUEST
sent by either
MME.
GTP-C
GTP-C
UDP
UDP
IP
IP
L2
L2
L1
L1
MME
S10
MME
Transfers signaling messages between MMEs
1 1 45
The S10 interface connects MMEs, both within a given pool and also across pools. This connection
is used for MME relocation and MME-to- MME information transfer.
New S10 interfaces may be provisioned without disruption to the existing S10 interfaces or other
interfaces.
If the MME is a Shared MME: the same MME may have an identity in the MME Home PLMN and in
each of the Sharing PLMNs, and also have the same IP address for S10 communications in each of
those PLMNs.
Note: Manual MME load rebalancing is used for OA&M activities such as moving an MME from one
pool to another; it is not used for distribution of traffic or overload control.

X1_1 and X2 (IRI): Support for lawful interception
MME interfaces support lawful

interception (LI) of a subscribers
data:
X1_1
X1_1 connects to up to 6 LI
administrative functions to
activate and deactivate
surveillance
X2 (IRI) connects to up to 6 LI
delivery functions to transmit
collected data
(provisioning)
Administrative
Function
X1_3
X1_2
HI2
Information is provided to the LI

about the following events at the
MME:
Attach
Detach
Tracking Area Update
UE requested PDN connectivity
UE requested PDN disconnection
1 1 46
LEA = Law Enforcement Agency
Mediation
Function
LEMF
HSS
X2 (IRI)
Delivery
Function 2
MME
X3 (CC)
HI3
Mediation
Function
Delivery
Function 3
Lawful Interception Gateway (LIG)

LEA Domain
SGW, PGW
Evolved Packet System (EPS)
Communication Service Provider
For more information about lawful interception, refer to

the 9471 MME CALEA/LI Management customer
document (418-111-213).
LEMF = Law Enforcement Monitoring Facility
The Lawful Intercept (LI) network function provides a way for law enforcement agencies to collect data for
specific targets based on IMSI, IMEI, or MSISDN identifiers. The Communications Assistance for Law
Enforcement Act (CALEA) is the North American term used for lawful interception.
The X1_1 link supports communication between the MME and up to six Administration Functions (ADMF) for
activation, deactivation, and interrogation operations related to the surveillance target list for lawful
interception. X1_1 is a proprietary interface that uses TCP/IP for transport.
The X2 (IRI) link allows transmission of Intercept Related Information (IRI) messages from the MME to the LI
Delivery Function 2 (DF2). The MME supports a primary X2 interface and optionally a secondary X2 link to each
DF2. Up to six X2 links are supported.
The MME supports IRI event buffering for up to 5000 IRI events if both X2 links become unavailable. Buffered
IRI events are transmitted as soon as an X2 link becomes available.
Operators can select either the ALU_V3000 proprietary interface or the HI2_V940 interface based on 3GPP
specs for the X2 (IRI) interface. Both use TCP/TPKT. Each X2 link using the HI2 format can be configured to
send Keep-Alive messages every 1 to 5 minutes (default = 5).
IPSEC: The MME supports enhanced security using IPSEC on the X1_1 and X2 interfaces.
Activation: A CLI command issued at the MME can be used to activate the lawful interception of data for a
target in networks that support lawful interception.
Restricted use: Only users with surveillance role can view LI logs and use commands to administer LI links
or remove entries from the target list. Only users with litargetadm role can administer the target list. Users,
roles, and LI commands are described in the 9471 MME Security Management customer document.

Fault detection protocols and mechanisms
The MME supports protocols and mechanisms for fast fault detection:
SCTP with multi-homing
Bidirectional Forwarding Detection (BFD)
External IP Manager Active Connection Management (EIPM- ACM)
Reliable Static Routing (RSR)
It is recommended that each external interface apply one of the fault detection mechanisms.
1 1 47
SCTP with multi-homing provides fast fault detection on those interfaces that have SCTP on the
protocol stack.
Bidirectional Forwarding Detection (BFD) is used to detect failures in communication with a
forwarding plane next hop. It provides low-overhead, short duration detection of failures in the
path. BFD operates on top of any data protocol (network layer, link layer, etc) being forwarded
between two systems and can be run at one or multiple layers in a system. BFD protocol is
available on all MME external interfaces except SCTP interfaces to the 1st hop router at Layer 3
(BFD/UDP/IP/Ethernet, either IPv4 and/or IPv6). End users can choose to enable BFD on an
external service subnet basis. Only BFD Asynchronous mode is supported; BFD Demand mode
and Echo function are not supported on the MME.
External IP Manager Active Connection Management (EIPM- ACM) is an Alcatel-Lucent
proprietary fault detection mechanism that provides fast fault detection using Access Resolution
Protocol (ARP) for deployments with L2 connectivity between 1st hop routers. EIPM-ACM
requires Layer 2 connectivity between the first hop routers to complete a loop between the MME
and the primary and secondary first hop routers. If no Layer 2, either BFD or multi-homing is
used.
Reliable Static Routing (RSR) provides low-overhead detection of failures in the path (usually
for OAM transport routes). RSR uses ARP and Neighbor Discovery Protocol (NDP) to detect
failures in communication with a forwarding plane next hop.
When faults are detected, alarms are raised.
It is recommended that each external interface apply one of the fault detection mechanisms. BFD
subnets and static routes must be added to support BFD.

Knowledge check: MME interfaces

Which of the following MME interfaces use UDP over IP? More than one
choice may apply.
A.
B.
C.
D.
S1 MME
S6a
S11
S10
Both C (S11) and D (S10). S1, S6a, S13 use SCTP; S6a and S13 can also use TCP.
1 1 48

Knowledge check: MME interfaces

The DIAMETER protocol is used between the 9471 MME and the
________?
A.
B.
C.
D.
eNodeB
SGW
PGW
HSS or EIR
1 1 49
D, HSS or EIR.

Module summary (1 of 3)
This module covered:

LTE review
MME-related terminology:
UE context
Non-Access Stratum (NAS)
Public Land Mobile Network (PLMN)
Tracking Area (TA) and Tracking Area Identity (TAI)
EPS Mobility Management states: EMM-Registered and EMM-Deregistered
EPS Connection Management states: ECM-Connected and ECM-Idle
Access Point Name (APN)
Commonly used LTE identities: IMSI, IMEI, EPS bearer ID, GUTI
1 1 50

9471 MME network interfaces and protocols:
S1-MME (between MME and eNodeB)
NAS (between MME and UE)
S6a (between MME and HSS)
S13 (between MME and EIR)
S11 (between MME and SGW)
S10 (between MME and other MMEs)
X1_1 and X2 (between MME and the lawful intercept system)
1 1 51

You should now be able to:
Identify the LTE network elements that communicate with the 9471 MME
Identify the interfaces and protocols that support communication between the
MME and other LTE elements
1 1 52

References
The following customer documents provide information about
the 9471 MME function in the LTE network:
9471 MME Technical
Description
Describes the 9471 MME features, functions, and

interfaces.
(418-111-200)
Customer documentation is found on the Alcatel-Lucent OnLine Customer Support

(OLCS) site: https://services.support.alcatel-lucent.com/services/lte
1 1 53

End of module
9471 MME in the LTE Network
1 1 54

Section 1
9471 MME Overview
Module 2
9471 MME Mobility Management Procedures

Technical Overview

Blank page
122
9471 MME Overview 9471 MME Mobility Management Procedures
Document History
Edition
Date
Author
Remarks
01
YYYY-MM-DD
First edition

Module objectives
Describe how the 9471 MME supports the following LTE mobility management
procedures:
Attach
TAU
Service Request
HSS user profile
Paging
Handover
Explain how the 9471 MME selects network elements to support these
procedures
123
This module provides an overview of the Evolved Packet System (EPS) mobility management
functions provided by the Alcatel-Lucent 9471 MME.

Table of Contents
1 Initial Attach
2 Network element selection and communication
3 TAU, Service Request, and HSS user profile management
4 Paging procedures
5 Handover procedures
125

Page
7
15
31
42
50
1 Initial Attach
127
This topic describes the key functions performed by the Alcatel-Lucent 9471 MME during an initial
Attach by a UE to the LTE network.

EPS mobility management and evolved session management
The 9471 MME functions can be categorized into two procedural areas:
EPS mobility management (EMM)
Keep track of the current location of a UE
Support paging and handovers
Ensure communication is maintained
Evolved session management (ESM)

Support bearer functions
Activation, modification, deactivation, and preservation of data sessions
128
The 9471 MME performs key procedures associated with its functions. These can be categorized as
EPS mobility management procedures and evolved session management procedures. In this
module, MME support for basic LTE mobility management procedures are described
Whats a procedure:
For the MME, procedures are very short duration transactions that can involve the exchange of
between 4 and 20+ messages.
The duration for procedures has a large variance: from 20 milliseconds to several hundred
milliseconds. Paging procedures can go well into the seconds. Service Request and S1 Release
procedures, however, dominate the traffic model, having only about 6 messages per procedure.

Attach procedure
Network Attachment: registration of the UE to receive packet services.

Attach types supported:
IMSI Attach to EPS
GUTI Attach to the same MME in EPS
EPS/IMSI combined
129
Attach types supported:

International
Mobile Station Identifier (IMSI) Attach The UE sends IMSI in the Attach
Request message as UE identity. The eNodeB selects the MME to forward the Attach Request
to.
Attach
with Globally Unique Temporary Identity (GUTI) to the same MME The UE sends a
valid GUTI in the Attach Request message to the MME identified by the GUTI. The eNodeB
derives the MME from the Globally Unique MME ID (GUMMEI) portion of the ID.
Combined
Evolved Packet System/IMSI (EPS/IMSI), which is used by a Circuit-Switch Fallback

(CSFB) enabled UE and Short Message Service (SMS) interworking with UMTS/GSM.
The MME attach procedure differs depending on the UE identity received in the Attach Request
message from the UE. The MME can identify the type of UE identity by examining the ePS mobile
identity IE in the Attach Request message.

Initial Attach with IMSI procedure (1 of 3)

PDN
Power on.
1
UE
eNodeB
MME
SGW
PGW
PCRF
HSS/EIR
2
eNodeB sets up
Radio Resource
Connection (RRC).
Control
Data
If required
NAS
3
UE sends Attach
Request with PDN
Connectivity
Request
MME sends
Authentication
request to HSS.
Response includes
UE static data, APN
information,
Authentication
vectors.
eNB sends S1AP

message
6
MME sends
Authentication
Request to UE.
7
After Authentication
Response, MME
sends Security Mode
Command to secure
the NAS connection.
8
Notes:
For simplicity:
Not all steps are included in this flow.
The flow assumes that the UE does not have a GUTI or previous
NAS security information
Not shown: each request message results in a response message.
Identity
Request/Response
required.
1 2 10
This scenario is an initial Attach with IMSI; MME has no UE context for the UE; UE is connecting to
a single APN; UE is not roaming.
1. The user powers on equipment (UE).
2. The UE and eNodeB exchange messages to set up a Radio Resource Control (RRC) connection.
3. The UE sends an Attach Request to the eNodeB with a PDN connectivity Request. The request
includes an International Mobile Station Identifier (IMSI), and the UE Tracking Area Identity
(TAI) with PLMN in which the UE accessed the network.
4. The eNodeB sends a S1AP Initial UE Message with the Attach Request to the MME.
5. If the UE does not provide a GUTI or if local MME policy requires it, the MME sends an
Authentication Request to the Home Subscriber Server (HSS). In the power-on case,
authentication is always required. If the UE is authentic, the HSS response includes key
information, including: subscriber data, the IP address of the PGW that serves the APN, and
authentication keys that will be used to help provide UE security.
6. The MME sends an Authentication Request to the UE. The Request includes the authentication
key information provided by the HSS so that the MME can verify the UE is valid, and the UE can
verify that the connection is safe.
7. After the UE is authenticated, the MME performs the Security Mode Command procedure to
establish integrity protection for the NAS (described later in this lesson).
8. From the Attach Request, the MME obtained the International Mobile Equipment Identity (IMEI)
from the UE. The MME may verify the IMEI with an Equipment Identity Register (EIR). This is a
provisionable feature.
Variations of the call flow could include: UE attaches with a GUTI; GUTI may no longer be valid;
UE has MME ID; MME ID may no longer be valid ; UE has security context; security context may
no longer be valid.
PDN
UE
eNodeB
MME
SGW
PGW
PCRF
HSS/EIR
MME sends Update

Location Request to
HSS and receives
answer.
10
MME selects SGW,
sends Create Session
Request to SGW.
Request includes
PGW IP address.
MME sends S1AP

14 Initial Context Setup
Request and
Activate DefEPS
Bearer Context
Request to eNodeB.
Message includes
Attach Accept to
UE.
11
SGW sends Create
Session request to
PGW and sends
Create Default
Bearer Request.
13
SGW sends Create
Session Response to
MME.
12
Control
Data
If required
NAS
PGW establishes
QoS and Gateway
Control with PCRF.
PGW response to
SGW includes UE IP
address.
15
eNB sends RRC
Connection
Reconfiguration
with EPS Radio
Bearer ID and
MMEI to the UE.
1 2 11
9. The MME sends an Update Location Request to the HSS to inform the HSS that it is serving the
user and provide location information (the UE name is IMSI).
10. The MME selects a Serving Gateway (SGW) and sends a Create Session Request; this includes a
11.
12.
13.
14.
15.
request for a default EPS bearer. The request includes the IP address for the PGW control plane
and the Access Point Name (APN) to identify the external network and bearer context. The MME
sends eNodeB time zone to the SGW (eNodeB time zone is the same as the MME unless
difference is provisioned at the MME).
If message piggybacking is supported, the MME includes the piggyback flag.
Whats piggybacking: An option that allows the messages for the dedicated bearer activation
to be combined with the default bearer activation at Attach or UE requested PDN connectivity
procedures. Without piggybacking, the dedicated bearer activation procedure is performed after
Attach or PDN connectivity procedures. Piggybacking is only applicable if all nodes in the chain
(MME, SGW and PGW) support piggybacking. Emergency bearers are supported with or without
piggybacking.
The SGW sends a Create Session request to the PGW that includes a Create Default Bearer QoS
request.
If there is no local policy, the PGW establishes a QoS and Gateway Control session with the
Policy and Charging Rules Function (PCRF). In the response to the SGW, the PGW sends the IP
addresses to be used as endpoints to the connection: IP addresses of the UE and the APN.
The SGW sends a Create Session Response to MME. The response includes the IP address for
the UE.
The MME sends an Attach Accept within an S1AP Initial Context Setup Request to the eNodeB.
The Attach Accept goes all the way to the UE via NAS and contains an ESM message container,
which includes: the UE GUTI if none was originally received, or was unknown; and an Activate
Default EPS Bearer Context Request, which contains IP address assigned to the UE and the
APN, and the TAI list.
eNodeB sends the RRC Connection Reconfiguration message including the ePS Radio Bearer
Identity, the MME Identifier (MMEI), and the IP address endpoint to the UE.
PDN
UE
eNodeB
17
UE sends Attach
Complete with
Accept DefEPS
Bearer Context
Accept.
18
19
16
MME
SGW
PGW
eNodeB sends Initial

Context Setup
Response to MME.
HSS/EIR
PCRF
Control
Data
If required
NAS
Optional: MME
sends EMM
information (time
zone) message.
First uplink data

on default EPS
bearer
20
MME sends Modify

Bearer Request to
SGW.
21
Notify
Request/Response if
required.
22
1 2 12
SGW responds and

begins sending
downlink data.
16. eNodeB sends an Initial Context Setup Response to the MME (message includes the eNBs IP
address).
17. The UE sends Uplink Information Transfer (context accept, activate default bearers) with Attach
18.
19.
20.
21.
22.
Complete to MME.
The MME sends the Enhanced Mobility Management (EMM) information message to the UE, if
provisioned at the MME. The message includes the MME time zone, and/or the network name,
and country initials. The message is ignored if the UE does not support receiving time zone
information.
The UE can send uplink packets towards the eNodeB, which will be tunnelled to the SGW and
PGW, and on to the PDN.
Upon receiving the Attach Complete, the MME sends a Modify Bearer Request to the SGW. The
request includes user location information, the eNodeBs IP address, any bearer contexts to be
modified or removed.
After the MME receives Modify Bearer Response message, if the MME selected a PGW that is
different from the PGW identity that was indicated by the HSS in the PDN subscription context
(in step 5), the MME sends a Notify Request including the APN and PGW identity to the HSS.
The HSS stores the APN and PGW identity pair and sends a Notify Response to the MME.
The SGW sends a response and begins sending downlink data.
Procedure references: For detailed 3GPP procedure specifications, see 3GPP TS 23.401.
Operators may also have modified call flows that are specific to their network and equipment.
Queuing network initiated session requests during Attach
During Attach and Handover procedures, immediately after the creation of the session, the MME
may receive S11 Create/Delete/Update Bearer Messages. The MME can queue up to 3 of these
network-initiated requests and execute them at the completion of the procedures, or at a point
where eNB does not reject non-HO related messages and/or communication with the UE is
established.
Key messages in Attach procedure: Exercise

1. Open the text file named Call Flow text file.txt in your student
materials.
2. Locate the key Attach messages:
Attach Request
Attach Accept
Attach Complete
3. Are there any Attach Reject or failure messages?
Time allowed: 5 minutes
Search traces on keyword reject when diagnosing a problem.

Reject and failure messages are followed by a cause value.
1 2 13
The text file shows the high-level exchange of messages in an Attach procedure and was captured
using WireShark in a development lab.
Example Cause code:
If the Attach Request message is not sent with the PDN Connectivity Request, or the Evolved
Packet System (ePS) attach type information element (IE) is not set to initial ePS attach, then the
MME sends an Attach Reject to the UE with cause code #19 (Evolved Session Management (ESM)
procedure failure).
Technical specification reference for procedures in this topic:
http://www.3gpp.org/ftp/Specs/html-info/23401.htm
3GPP
23.401
3GPP
24.301
Refer
to TS 24.008 for definitions of reject cause codes.

Knowledge check: EPS mobility management

The UE sends an initial Attach Request with a PDN Connectivity Request to
the ________.
A. MME
B. eNodeB
C. SGW
B, eNodeB. The eNodeB sends an S1AP Initial UE Message with the Attach Request to the MME.
1 2 14

2 Network element selection and

communication
1 2 15
This topic explains how the 9471 MME finds or selects other elements in the LTE network, as well
as how other elements find the MME. In some cases NE are learned, and in other cases they are
provisioned at the MME.

MME selection
Once a UE is attached to the network, the UE

stores the MME Identifier (MMEI) as part of the
Radio Resource Control (RRC) parameters.
When the UE initiates other procedures, such as

Tracking Area Update, it sends the RRC parameters
to the eNodeB.
The eNodeB selects an MME on initial attach if the

UE has no stored MMEI or if the eNodeB does not
find the MMEI in its list of MMEs.
1 2 16
UE
eNodeB
Attach:
eNB sends RRC
parameters that
include MMEI to
the UE.
UE
eNodeB
TAU:
UE sends MMEI in
Information
Element
registeredMME to
the eNB.
In the case where several S1 links to MMEs are configured, the eNodeB must dispatch UEs to the
specific MMEs to which they are registered, or select an MME to which they will register when they
haven't previously done so.
Initial MME selection by the eNodeB is performed by cycling through MMEs of a selected MME pool
based on provisioned Tracking Area Identity (TAI), the MME pool associated with the TAI, and
provisioned MME capacity data (described on next slide).

Initial MME selection by eNodeB (1 of 2)

To select an MME, the eNodeB:
1. Receives GUMMEI from all MMEs in
pool.
2. Receives a relative MME capacity
(relativeMmeCapacity) from all MMEs in
pool.
3. Establishes a list of MMEs.
4. Computes the total capacity of all
MMEs in pool.
5. Randomly draws a number between 1
and totalMmeCapacity.
6. The randomly drawn identifies MME.
1 2 17
at
re l
I
c
MECapa
M
GU me
M
ive
ity
MME
S1-MME
S10
eNodeB
S1-MME
re l
ati GU
ve MM
Mm E
eC I
ap
ac
MME
ity
To select an MME, the eNodeB:

1.
Receives GUMMEI from all MMEs in a pool during S1-MME setup.
2.
Receives a relative MME capacity (relativeMmeCapacity) from all MMEs during S1-MME setup.
The relative capacity is based on MAF pairs and their state (one pair of functioning MAFs has a
relative capacity of 5).
3.
Establishes a list of MMEs for which the S1-MME link is operational.
4.
Computes the total MME capacity (totalMmeCapacity) by summing the relative capacity of
each eligible MME.
5.
Randomly draws a number between 1 and totalMmeCapacity.
6.
The randomly drawn number falls within a unique selection range generated for each MME,
and identifies the MME selection.
Recall that the GUMMEI contains the MME ID, and an MME pool is the set of tracking areas served
by a group of MMEs. An MME shared by multiple PLMNs may have up to 9 GUMMEIs.
Required provisioning at the MME to ensure the proper selection by an eNodeB:
Define MME data for each MME, including:
Mobile Network Code (MNC) and Mobile Country Code (MCC)
MME identifier
Pool identifier
Relative capacity of the MME
Define each tracking area served by the MME.
Associate the MMEs in the pool with one or more tracking areas.
Initial MME selection by eNodeB (2 of 2)
Generating the MME selection range:

1. Ranges starts at one plus the sum of the relativeMmeCapacity of all the MMEs
preceding it in the list of eligible MMEs.
2. Range ends at the sum of relativeMmeCapacity of all the MMEs preceding it in
the list and of its own relativeMmeCapacity.
Example:
If the randomly drawn number in the following pool is 7, then MME 1 is selected.
MME
Relative capacity
Selection range start
Selection range
end
20
1+0+ = 1
0+20+ = 20
20
1+20 = 21
20+20+ = 40
Total capacity =
40
1 2 18
Required provisioning at the MME to ensure the proper selection by an eNodeB:
Define MME data for each MME, including:
Mobile Network Code (MNC) and Mobile Country Code (MCC)
MME identifier
Pool identifier
Relative capacity of the MME, if auto capacity updates are to be sent to the eNodeB
Define each tracking area served by the MME.
Associate the MMEs in the pool with one or more tracking areas.

SGW selection methods
One SGW in the network: IP address is provisioned at the 9471 MME.

Multiple SGWs in the network:
1. Select an SGW based on TAI served by the pool, or
2. Use a DNS query.
Mode 1: Select an SGW and then select a PGW topologically close.
Mode 2: Select the SGW/PGW simultaneously based on topological
matching of each SGW and PGW returned from the DNS query.
1 2 19
For an LTE network that contains a single SGW, the IP address is provisioned at the 9471 MME and
used for all events.
For multiple SGWs in the network, the operator can provision the MME to use the following
methods:
1.
Select an SGW from a pool based on the TAI served by the pool.
2.
Use a DNS query to select an SGW. Two modes are supported:
Mode 1: MME selects an SGW first and then selects a PGW topologically close to the SGW
(this is the default).
Mode 2: MME chooses the SGW/PGW simultaneously based on topological matching of

each SGW and PGW returned from the DNS query.
Using DNS query and the topological mode are provisioned in the Global Parameters table.
SGW and PGW alternate selection during failure: If the SGW or PGW return a failure in the
Create Session Response, or if MME times out waiting for Create Session Response, the MME
can re-select an alternate SGW or PGW.
Depending on the procedure, failure message, and GW selection mode, the MME selects an
alternate SGW, PGW, or SGW/PGW pair. In some scenarios, such as PGW failure during
handover, the request may be rejected altogether. Refer to the 9471 MME Technical Description
for details.
Geo-redundant SGW support: When the primary SGW in a geo-redundant pair fails, adjacent
nodes (MME, PGW) are not aware of the failure. The IP address and path management is
assumed by the backup SGW, and UEs in Idle mode are maintained. When the SGW receives
control messages on S11 or receives data, it sends a Downlink Data Notification (DDN) to the
MME with special cause code #254 to restore S1-u DL path. The MME performs the appropriate
procedure (Paging an Idle UE or Modify Access Bearer Request for an Active UE). Refer to the
9471 MME Technical Description for details.
DNS basic terminology (1 of 2)
DNS
FQDN
NAPTR
S-NAPTR
TAI FQDN
S-NAPTR procedure
TAI
What SGW's serve this TAI?
TA
UE
MME
1 2 20
DNS
The 9471 MME supports Domain Name Service (DNS) queries to obtain both SGW and PGW IP
addresses. These terminology slides define basic terms for SGW or PGW selection using DNS
query.
The Domain Name System (DNS) is a naming system for computers, services, or other
resources connected to the internet or a private network. A DNS associates various information
with a domain name.
A Domain Name Service (DNS) can be queried to resolve domain names or other data into IP
addresses to locate a specific service or device.
FQDN, or Fully Qualified Domain Name, is an Internet label that uniquely identifies a host, for
example www.xyz.com.
NAPTR, or Name Authority Pointer, is a type of resource record used in DNS. At the MME, it is used
to map the Tracking Area Identity (TAI) FQDN to a specific resource. Each NAPTR record
includes a service parameter, various flags, and an order value.
The NAPTR resource record is defined in IETF RFC 3403 [7] and is a powerful tool that allows DNS
to be used to lookup services for a wide variety of resource names, which are not in domain
name syntax (TAI FQDN, for example). A record includes host name, class and type, time to live
(TTL) for the record, and the data fields describing the resource.
Straightforward NAPTR, or S-NAPTR, refers to the procedures that dynamically resolve a domain
name, application service, or application protocol.

DNS basic terminology (2 of 2)

S-NAPTR
flag
Service
parameter
RR
(A or AAAA)
topon
topoff
NAPTR records
(candidate SGW's)
SGW
DNS
MME
Order Preferences Flags Services
400
999
A or AAA
(SGW IP)
Replacement
x-3gpp-sgw:x-s8-gtp topoff.eth9.gw01.nodes.3gppnetwork.org
1 2 21
S-NAPTR flags indicate what further actions need to be taken on the records:
Currently only the A flag is supported by the MME.
A NAPTR with an A flag includes an FQDN (called a Replacement) that points to the RR A
or RR AAAA.
S-NAPTR flags supported by MME:
A indicates the end of NAPTR processing and means that the next lookup should be for A or
AAAA records (for IP address). A NAPTR with an A flag will include a fully qualified domain
name of the SGW or PGW (called the replacement) that points directly to the A or AAAA
record with the IP address.
The MME prefers to use IPv6 (AAAA record) path to SGW if available.
Service parameter refers to the protocol and interface supported.
Example: the service name for an SGW that supports GTP S5 interface is
x-3gpp-sgw:x-s5-gtp. The service name for an SGW that supports S11 interface is " x-3gppsgw:x-s11".
RR is a resource record in the DNS that maps a host name to an IP address.
RR A defines an IPv4 host address corresponding to the FQDN of the host.
RR AAAA defines an IPv6 host address corresponding to the FQDN of the host.
topon and topoff:
topoff.eth11.gw01.nodes.3gppnetwork.org is the FQDN of SGW01: The format of the host
names with topon and topoff labels allows the selection of nodes that are collocated.
Topology on, or topon indicates that collocated or topologically close node selection is
preferred. Example: if the UE is in Houston, the service provider might want the MME to select
an SGW in the Houston region. It is the responsibility of the service providers to use structured
node names sharing a common suffix to reflect topological closeness.
3gppnetwork.org is the domain name and provides DNS names for 3GPP services.
Example: SGW selection using DNS (1 of 2)
Using DNS query to select an SGW (MME selects an SGW before a PGW):
4 Candidate SGWs sent to MME
DNS NAPTR records
MME
eUTRAN
eNodeB
S10
Example TAI FQDN constructed by the MME:

TAI = TAC+MCC+MNC. In this example, TAC = 2304; MCC = 234; MNC=15:
tac-lb04.tac-hb23.tac.epc.mnc015.mcc234.3gppnetwork.org
MME constructs TAI FQDN
MME ePC
performs S-NAPTR procedure if records not in cache
HSS/EIR
S6a/S13
S11
S1-MME
5 MME selects SGW
UE sends TAI
1 value
from candidate list
PGW
SGW
S5
S1-U
SGi
PDN:
acme.com
intranet
For details about this procedure and other S-NAPTR procedures or records, the
3GPP Technical Specification 29.303.
1 2 22
This scenario describes DNS query to select an SGW in the initial Attach case. Prerequisites:
For each TAI value in their network, the operator provisions NAPTR records under the TAI
FQDN corresponding to each valid SGW interface from the supported "Service Parameters".
The global parameter Discover SGW is provisioned at the MME. Setting the Discover SGW
parameter to Yes tells the MME to use a DNS query to obtain a list of SGW IP addresses for
handling a given Tracking Area Identity (TAI).
The global parameter GW Selection Mode 1 is provisioned at the MME. This tells the MME to
select the SGW first and then select a PGW that is topologically close.
1. When the UE attaches, the MME receives the S1AP Initial UE Message, which contains the TAI
value.
2. The MME uses the TAI to construct a TAI FQDN. The TAI is constructed from the Mobile
Country Code (MCC), Mobile Network Code (MNC) and Tracking Area Code (TAC).
If the MME is shared by multiple PLMNs, the TAI FQDN contains the MCC and MNC of the PLMN
selected by the UE. Note: lb and hb in the FQDN represent the high byte (most significant
byte) and low byte in the hexadecimal TAC.
3. The MME uses the S-NAPTR procedure and the TAI FQDN to obtain a list of candidate SGWs
from the DNS. Note: If the DNS cache contains records for the domain name and time-to-live
(TTL) has not expired, the MME does not launch an external DNS query.
Technicians may use a command (dnsadmin_cli) to purge one or more entries from the cache
and force the MME to launch DNS queries. Another command (dnsadmin) can also be used to
output the cache for troubleshooting (all of the cache or portions based on labels and patterns).
4. The S-NAPTR procedure returns a candidate list of SGWs for a specific TAI. The list includes
host name with services, list of IPV4 and IPv6 IP addresses, an order field, and the TTL for the
record.
5. The MME selects an SGW with an active S11 link from the list based on the required service. If
more than one SGW matches the requirement, the Order field is used to select the SGW.

Example: SGW selection using DNS (2 of 2)
Detail about how the MME selects an SGW using DNS query:
MME performs DNS query based on TAI FQDN.
Data portion of record
DNS server sends NAPTR records (up to 80) for all the SGW services. In
addition, it may return A and AAAA records.
Order
400
100
100
300
300
Preferences
999
999
999
999
999
Flags
a
a
a
a
a
Services
x-3gpp-sgw:x-s8-gtp
x-3gpp-sgw:x-s5-gtp
x-3gpp-sgw:x-s11
x-3gpp-sgw:x-s11
x-3gpp-sgw:x-s5-gtp
Replacement
topoff.eth9.gw01.nodes.3gppnetwork.org
MME selects node gw01 that offers service

x-3gpp:sgw:x-s5-gtp based on Order field.
MME
SGW
(gw01)
S11
MME selects S11 service on the same gw01.
PGW
S5
MME queries DNS for A and AAAA records for the S11 interface if they
were not received with the NAPTR query.
1 2 23
1. MME performs DNS query based on TAI FQDN (see previous slide).
2. DNS server sends the NAPTR records (up to 80 supported per query) for all the SGW services
that serve the TAI as shown in the table*. In addition, it may also give A and AAAA records. In
this example, the DNS returns records with a flag.
*Note that the table represents the data portion of the record. The record also includes host
name, type/class of record (usually 1 for internet), time to live (TTL), and record length.
3. The MME has to select a node that offers service x-3gpp:sgw:x-s5-gtp based on Order field. If
more than one service has the same Order number, the Preference field is used.
In this example, there are two SGW nodes that offer the S5 service: gw01 and gw25. MME
selects the record in row 2 (gw01) since it has the lowest Order number.
gw01 will be used as the primary SGW and gw025 will be used as the secondary SGW.
4. MME selects S11 service on the same gw01.

5. MME queries for A and AAAA records for the S11 interface using the Replacement FQDN (if
they were not received with the NAPTR query). A and AAAA records provide the IP address of
the SGW.

Data portion of record
NAPTR resource record
Order
400
100
100
300
300
DNS
dictated
priorities &
preferences
Preferences
999
999
999
999
999
Flags
a
a
a
a
a
Services
x-3gpp-sgw:x-s8-gtp
x-3gpp-sgw:x-s5-gtp
x-3gpp-sgw:x-s11
x-3gpp-sgw:x-s11
x-3gpp-sgw:x-s5-gtp
This indicates that

the record that will
be obtained with the
new DNS request is
the final IP address.
1 2 24
Replacement
This tells the

MME what are
the capabilities
of the node.
This is the string the MME

uses to issue a new DNS
request in order to get
the IP of the node (SGW
or PGW)
Application-Unique String sent by MME to DNS: TAI/eNode-Id-FQDN or APN-FQDN. The MME

receives the NAPTR resource record in response.

Service string and replacement string
NAPTR Service string:
x-3gpp-sgw:x-s8-gtp
Node type
Interface in
the node
NAPTR replacement string:
Topologically
close node
selection on or
off.
Specifies
single
interface on
the node.
1 2 25
Unique node
name specified
by service
provider.
Domain
name
appended to
each string
Lets have a more detailed look at the service string format in NAPTR.
x-3gpp-sgw:x-s8-gtp
It is composed of two parts separated by a colon. First parts gives the node type, second part is the
interface in the node.
A more detailed look at the replacement string format in NAPTR, which follows the following format
(3GPP defined):
<topon|topoff>.<single-label-interface-name>.<canonical-node-name>
topon
/ topoff: to indicate whether or not collocated or topologically close node selection is

preferred.
Single-label interface name: This label is used to specify a single interface on a node. Examples
names are Eth2, SONET4.
Canonical Node Name:
Each node has exactly one canonical node name
It is the responsibility of the service providers to use hierarchically structured canonical

nodes names sharing a common suffix to reflect topological closeness when topon is
used as the first label
Two topologically closest nodes are those with the longest matching suffix in their
respective canonical node names
$ORIGIN is usually 3gppnetwork.org, the domain name that provides DNS names for 3GPP services.
The $ORIGIN indicates where in the DNS hierarchy the string belongs.

PGW selection methods
PGW allocation type on the HSS
Allocation type provisioned at the HSS is Static:
PGW FQDN or PGW IP address must be provisioned at the HSS and provided to
the MME.
Allocation type provisioned at the HSS is Dynamic:
The MME constructs an APN NAPTR query based on the APN provided by the UE.
Topological selection
Default: MME selects PGW topologically close to SGW (SGW selected first)
Option: Discover an SGW topologically close to the PGW

PGW and SGW are selected simultaneously
1 2 26
The PGW provides UE access to a specific Access Point Name (APN) in the PDN. When a UE
attaches to the ePC, the MME needs to know which PGW serves the APN.
The MME obtains the IP address of the appropriate PGW as follows:
When the allocation type parameter (pdnGwAllocationType) provisioned at the HSS is Static:
Either the PGW FQDN or the PGW IP address must be provisioned at the HSS and provided
to the MME upon attach or handover.
If only the PGW IP address is provided to the MME, it is used.
If PGW FQDN (or both FQDN and IP address) is provided, the MME uses the S-NAPTR
procedure to request a specific PGW replacement. Additional DNS A and AAA queries are
launched to retrieve PGW IP addresses.
When the allocation type parameter (pdnGwAllocationType) provisioned at the HSS is
Dynamic:
The MME constructs an APN NAPTR query based on the APN provided by the UE, regardless
of whether the HSS subscriber data included a PGW FQDN.
A UE can have multiple PDN connections, but cannot establish multiple PDN connections using the
same APN.
In the case of multiple PDN connections, the default PDN connection is established as part of the
initial UE attach procedure. Additional PDN connections are established using a standalone PDN
Connectivity Request.
Selecting PGW topological close to SGW vs Selecting SGW topologically close to PGW
By default, MME discovers a PGW that is topologically close to the selected SGW (SGW is selected
first).
If the operator provisions the MME to discover an SGW that is topologically close to the PGW, the
PGW and SGW are selected simultaneously based on topological matching of each SGW
returned from the TAC NAPTR query with each PGW returned from PGW/APN NAPTR query. The
MME chooses the PGW/SGW pair that has the longest/best topological matching FQDN names
MME selection of another MME

MME selection methods:
Discovery and selection using DNS/S-NAPTR query
Provisioned IP addresses (this is the default)
Pool 1
MME-1
S10
MME pool 1
MME 1 ID (local)
MME 1 IP (local)
MME k ID
MME k IP
TAI 2
TAI 3
eNB
MME-k
S1-MME
MME pool 1
MME k ID (local)
MME k IP (local)
MME 1 ID
MME 1 IP
TAI 2
TAI 3
eNB
TA 2
S1-MME
eNB
eNB
TA 3
1 2 27
The S10 interface connects MMEs, both within a given pool and also across pools. It is used for:
MME relocation during Tracking Area Update (TAU) or handovers in the case where the old MME
does not serve the new tracking area (TA).
MME-to-MME information transfer. For example, if a UE attaches to the network with a GUTI, a
new MME can obtain the UE context from the old MME via the S10 interface.
Used during manual MME load rebalancing (used for activities such as moving an MME from one
pool to another; not used for distribution of traffic or overload control.)
An MME can select another MME by using provisioned MME IP addresses, or by MME discovery and
selection using the following Domain Name System (DNS)/S-NAPTR query procedures
Provisioning method
MME pools and the IP addresses for the MMEs in the pool are provisioned at the 5620 SAM. The
provisioning of MME IP addresses is a three-step process:
1. Provision IP address and other details for each MME in a group from MME Node provisioning
screen.
2. Provision Tracking Area Identity (TAI) for each TA [TAI = Mobile Country Code (MCC) + Mobile
Network Code (MNC) + Tracking Area Code (TAC)]. This is done from the TAI provisioning
screen.
3. Map an MME group to serve a target TAI from the MME Group to TAI provisioning form.
Note: The local MME is called the Home MME on the Provisioning form. From a provisioning point
of view, it is the MME to which you are logged in and are making changes for. From a UE point
of view, the Home MME is the MME whose Public Land Mobile Network (PLMN) matches the UE
PLMN.

HSS selection
The 9471 MME can connect to up to 36 HSS entities over S6a:

PLMN
HSS
routing
Maximum number of HSS per PLMN
Home,
Shared, or
Equivalent
IMSI-based
Up to 2 HSS for each IMSI range

(up to 2 IP addresses per HSS, either IPv4 or IPv6) and
ports for each IMSI Range
Home
PLMN-based Up to 4 - 1 primary and 3 tertiary

(up to 2 IP addresses per HSS, either IPv4 or IPv6)
Visited or
Shared
PLMN-based Up to 2 HSS for each Visited PLMN

(up to 2 IP addresses per HSS, either IPv4 or IPv6)
The 9471 MME directs traffic to HSS based on IMSI or PLMN:

The MME checks the PLMN in the IMSI-to-HSS-Routing table first. If it does
not exist then the HSS is retrieved from the Home or the Visited PLMN table.
IMSI-to-HSS Routing is based on the assigned mapping between an IMSI
range and an HSS server.
Maximum of 4 PLMNs (1 home + 3 equivalent) provision up to 32 ranges per PLMN with total
of 128 IMSI ranges.
1 2 28
The 9471 MME can connect to up to 36 HSS over the S6a interface, including the Home HSS in the
MME's home network. The MME uses the IMSI and PLMN to determine which HSS to query for each
subscriber.
Note: If a Diameter Routing Agent (DRA) is used in the network, the IP addresses are configured
for the DRA instead of the HSS.
The maximum number of HSS that can be provisioned per PLMN is dependent on whether the
provisioning is for an IMSI range or a PLMN (and the type of the PLMN).
Each pair of HSS is configured in active/standby. Subscription data is synchronized across primary
and backup HSS.
When multiple HSS IP addresses exist, MME establishes SCTP associations with all, and starts using
the backup S6a link if the primary fails. 100% of traffic is sent to a single IP address.
If the primary S6a interface to the Home HSS fails, then the 2nd provisioned IP address is used,
then the 3rd, then the 4th. When the primary HSS returns to service, the MME starts using it again.
Multi-homing: With SCTP multi-homing, each HSS Remote Endpoint may be provisioned with an
alternate (secondary) IP address in addition to the required primary IP address.
HSS Retry parameter: Operators may provision a global MME parameter to perform an HSS retry
to another HSS link to mitigate HSS failure. This feature addresses the case where the link to the
primary HSS is up, but the MME does not receive a response (due to overload, for example).
HSS Retry disabled (default): No retry is attempted (the procedure fails if the HSS does not
respond).
HSS Retry enabled: Retry is attempted to a secondary IP for Authentication and Update Location
procedures when primary HSS does not respond. Once the primary returns to service, the MME
selects the primary for the next procedure with no HSS history. The secondary HSS stays
throughout the life of a UE. Only one retry is attempted. If it fails, the procedure fails, and the MME
selects the primary again for the next procedure.
Disconnect messages from/to HSS: If the HSS sends a Disconnect Peer Request (DPR) to MME,
the MME answers with a Diameter Disconnect Peer Answer (DPA) message and fails-over to a
secondary HSS.
How MME learns about eNodeBs

MME IPs are provisioned on eNodeB.
The eNodeB creates an SCTP Association with each MME.
eNodeB
S1-Setup
MME1 IP
MME2 IP
MME1
S1-MME
eNodeB
MME1 IP
MME2 IP
MME2
S1-Setup
1 2 29
SCTP = Stream Control Transmission Protocol

An
eNodeB is provisioned with IP addresses for the set of MMEs with which it can interface.
The
eNodeB creates an SCTP Association with each of those MMEs, and then sends S1
Setup to each of the MMEs to establish an S1-MME communications link between itself and
each of the MMEs.
The
S1 Setup procedure is always initiated by the eNodeB.

How the MME knows which TACs to support
1. eNodeB cells are assigned to a TAC.

2. The MME Group is assigned to cover a set of TACs.
3. In the S1 Setup message, the eNB sends MME the mapping of each
of its cells to a TAC.
4. The MME must have been previously provisioned with the set of TACs.
5. MME IP not provisioned on eNodeB if TAC is not handled by that MME.
TAC A - Cell 1
TAC A - Cell 2
TAC A - Cell 3
MME1 IP
TAC B - Cell 1
TAC B - Cell 2
TAC B - Cell 3
MME1 IP
1 2 30
S1-Setup
MME1
TAC A
TAC B
TAC C
.
.
.
S1-Setup
TAC = Tracking Area Code

PLMN = Public Land Mobile Network
1. eNodeB cells are assigned to a TAC via eNodeB provisioning.
Each eNodeB cell can be in a different TAC, but usually that won't be the case.
2. The MME is provisioned with the set of TACs that its MME Group is assigned to cover.
The TACs handled by a given MME are in the same PLMN as the MME.
This does not include all of the TACs in the operator network, but only those that are handled
by this MME's Group.
3. In the S1 Setup message, the eNB tells the MME what the mapping is of each of its cells to a
TAC.
4. The MME does not accept the mapping unless the MME has been previously provisioned with
the set of TACs.
5. If a TAC is not handled by a given MME, then any eNodeB provisioned with that TAC will NOT
be provisioned with the given MME IP address, and hence, will not establish communications
with the given MME.


An eNodeB initially selects an MME to handle a particular UE by cycling
through MMEs in a pool that is associated with the UEs tracking area.
True
False
True. Once the UE is attached to the network, the UE stores the

MME Identifier (MMEI), which is used by the eNodeB to select the
appropriate MME when the UE initiates other procedures.
1 2 31


The 9471 MME must be provisioned with the IP addresses of each eNodeB
with which it communicates.
True
False
False. An eNodeB is provisioned with IP addresses for the set of

MMEs with which it can interface. The eNodeB then creates an
SCTP Association with each of those MMEs.
1 2 32

3 TAU, Service Request, and HSS user

profile management
1 2 33
This topic describes how the MME supports the following EMM procedures:
Service Request
HSS User Profile management

The Tracking Area Update (TAU) procedure is initiated by the UE to notify

the network of its current location.
Modes supported:
Normal
Periodic
Bearer scenarios supported:

TAU with bearer change
TAU without bearer change no SGW interaction required
1 2 34
Normal TAUs are performed when the UE detects that it is within a new tracking area.
Periodic TAUs are performed when the UE is in the ECM-IDLE state. The UE initiates the TAU
Request at defined intervals.
TAU with bearer change: the MME must interact with the SGW to adjust the set of active bearers
on the SGW side to be consistent with the bearers that UE indicated are active.
TAU without bearer change: no interaction with the SGW. This procedure changes only the 'last
seen tracking area' and 'last seen eNodeB' information in the UE context data.
The Update Location Request (ULR) will be sent as part of the TAU procedure if there is a
change to the location information that is passed to the HSS. The ULR message sent to the HSS
includes MME Identity, IMSI, ME (mobile equipment) Identity, MME Capabilities, ULR-Flags. The
MME capabilities indicate the MME's support for regional access restrictions functionality. ULR-Flags
in a TAU procedure indicate that update location is sent from an MME and indicates that the MME
registration should be updated in HSS.
If there is more than one SGW in the ePC, a TAU may include a change to a new SGW. When MME
relocation is executed in the CONNECTED mode, the UE requests a TAU procedure in the
CONNECTED mode. The new MME assigns a new GUTI and get the Subscriber Data from the HSS.
Time zone to SGW: The MME sends time zone change notification to the SGW when the UE
moves to a new TA with a new time zone. Time Zone information is sent through the SGW to the
charging entity on Create Session Request, Delete Bearer Response, and Modify Bearer Request
during: time zone changes in MME, MME relocation, or Service request.
Optional: The MME sends the Enhanced Mobility Management (EMM) information element
(IE) to the UE, if this feature is provisioned and enabled at the MME. The message includes the
MME time zone (or eNodeB time zone if different from the MME and provisioned at the MME). Time
Zone information is used by the UE to support mobile originated (MO) Short Message Service (SMS)
calls, and update of display if applicable. The EMM IE message may also optionally include the
network name and country initials. The IE is ignored if the UE does not support receiving time zone
information. If a TAU is performed, the UE is notified of a time zone during the TAU procedure.
Key tasks performed by MME during TAU

Message integrity check
Authentication and security if integrity check fails
Update UE context
Update the list of registered Tracking Areas
If UE bearers have changed, send Update Bearer Request to SGW
Send eNodeB time zone to SGW
If MME changed, notify HSS of new location (Update Location Request)
Optional: send time zone and/or network name to the UE
HSS
eNodeB
MME
TAU
1 2 35
SGW

Registered Tracking Area: Purpose

During Attach and TAU, the 9471 MME sends the UE a list of registered
TAIs.
The UE may move within any of these registered TAs without triggering a
location-based TAU.
TA List
TA1
TA2
TA3
TA
TA33
TA
TA11
MME
TA
TA22
1 2 36
During Attach and TAU procedures, the 9471 MME sends the UE a list of Tracking Area Identifiers
(TAIs) where the UEs location is registered.
The UE may move within any of these registered tracking areas without triggering a location-based
TAU.
The purpose of registered Tracking Areas (TAs) is to prevent the ping-pong effect of multiple
Tracking Area Updates (TAUs) when the UE is on the border between TAs. The UE will request a
TAU only when it moves to a TA that is not in the current list of TAs sent by the MME.
The 9471 MME maintains a history of recent UE locations (based on serving cell) in the UE context
for each UE. The data can be used to generate automatic neighbor lists for paging and TAU
strategies.
The MME sends a TAI list to the UE in the Attach Accept message and TAU Accept message. The
UE may move within any of the TAs in the list without triggering a location-based TAU.

Registered Tracking Area: Automatic generation
The list of registered tracking areas for each UE includes:

The TAI of the current location of the UE
Basic Automatic Neighbor List: The TAI of the UEs previous location
TA
TA11
TA
TA22
Basic Automatic Neighbor List generation reduces

TAU when UE is located between two TAs where
rapid registration (TAU) can take place.
Enhanced Automatic Neighbor List: The TAI of the UEs old previous
location.
TA
TA33
TA
TA11
Enhanced Automatic Neighbor list generation

automatically includes an additional TAI if
cyclical movement among three.
TA
TA22
1 2 37
The TAI list sent to the UE always includes the last TAI reported by the UE.
The operator may enable the MME to include additional TAIs in the list if cyclic movement between
tracking areas is detected by the MME:
The
previous location of the UE (Basic ANR is enabled). This allows the UE to travel back and
forth between two neighboring TAIs without performing a TAU, (if available and cyclic
movement between two tracking areas is detected). Basic ANR is the default.
The
previous two locations of the UE (Enhanced ANR is enabled). This allows the UE to cycle
through three neighboring TAIs without performing a TAU (if available and cyclic movement
between tracking two or three areas is detected).
Note: TAIs are not added to the Registered TAI list for simple linear movement. The MME adds
TAIs to the list when it appears that UEs are toggling among TAIs.
Upon receipt of an Attach request, the MME clears the old UE mobility history. The history also
clears if a TAU results in MME or SGW relocation.

Registered Tracking Area: Provisioned TA neighbors

Registered TA list may include provisioned TA neighbors.
Up to 15 provisioned
A maximum of 16 TAI in the TAI list sent to the UE.

Use manually provisioned neighbor lists for special cases!
TA2
TA3
TA4
TA5
TA1
TA7
eNB1
TA8
TA6
TA9
Example neighbor TAs for a UE in TA1.

1 2 38
The
list of registered TAs sent to the UE by the MME always includes the last TAI reported by
the UE.
The operator can also include a manually provisioned Neighbor List in the Registration TAI List.
Up to 15 neighbors can be provisioned per TAI.
Since the TAI list cannot exceed 16 TAIs, if a fully provisioned neighbor list is included, the
current location of the UE will be included in the TAI list, but the previous two locations of the
UE will not be added.
It is recommended that the TAI Neighbor List be provisioned only to deal with special cases. In
normal cases, the manually provisioned TAI Neighbor List should be left empty.
Details about automatic neighbor list generation and TAI lists are found in the 9471 MME Technical
Description (418-111-200).
The 5620 SAM LTE ePC User Guide (3HE 06981) explains how to provision and enable automatic
and manual neighbor lists.
Note: When you look at a UE context, you will see the following fields:
At the successful completion or failure of any MM or SM procedure, the following fields are
populated in the UE context: Last Seen TAI (the UEs last reported location received in the S1-AP
messages), Old Last Seen TAI, Older Last Seen TAI (second two not populated for a new Attach, or
if not different from the first). These are sent to the UE in Attach Accept and TAU Accept messages.
After successful completion of Attach and TAU procedures if Automatic Neighbor List Generation is
enabled, you will also see Last Registered TAI, Old Last Registered TAI, Older Last Registered TAI
populated . These are a snapshot of the tracking areas that were added to the registered tracking
area list that was sent to the UE during the last Attach or TAU procedure. They are used for paging.

Serving cell change reporting

The 9471 MME can be provisioned to report UE location change events in a
ULI information element to the SGW:
Include ULI IE when requested by the PGW, or
Always include ULI IE in S11 messages
MME
eNB
1 2 39
ULI
ULI
S1-MME
S11
SGW
ULI
PGW
S5
The 9471 MME supports the optional UE eNodeB Serving Cell Change Reporting function. If
this feature is enabled, the Location Change Reporting mechanism at the eNodeB is activated for
each connected UE. The MME relays UE location change event information that it receives from the
eNodeB to the location SGW over the S11 interface, which in turn relays it to the PGW.
The MME normally includes the User Location Information (ULI) Information Element (IE) in
applicable S11 messages only if the PGW has requested location change information.
If ULI Enhancement is also enabled, then the ULI information element is always included in S11
messages sent from the MME to the SGW, regardless of whether PGW has requested it.
Both UE eNodeB Serving Cell Change Reporting and ULI Enhancement are provisioned from
the Global Parameters form at the 5620 SAM.
Note that the Radio Access Type (RAT) IE and Serving Network IE are aalso always included in
applicable S11 messages sent from MME to SGW.

Service Request
The Service Request procedure:

Establishes radio and S1-U bearers when user data needs to be sent.
MME
S11
UE
eNB
SGW
PGW
SGi interface
EPS bearer
Radio bearer
S1 bearer
PDN/
APN
S5/S8 bearer
The UE sends the Service Request in ECM-IDLE state.

Triggers:
Click on a web page or polling of a mail server.
UE is paged by MME.
Key tasks performed by MME:

Optional: Authentication
Request eNodeB to establish UE context
Send Modify Bearer Request to SGW with eNodeB IP address
1 2 40
The Service Request procedure establishes the radio and S1-U bearers when uplink or downlink
user data needs to be sent. The UE can send the service request message in ECM-IDLE state when
it or the user network has data pending.
The UE sends the Service Request message in:
ECM-IDLE
state
Examples of events that can trigger a Service Request:

Click
on a web page or polling of a mail server.
When
SGW has downlink data, the MME uses Paging procedure to trigger the UE to send a
Service Request.
Key tasks performed by MME during a Service Request:

Optionally
Request
Send
perform authentication if required by network vendor
eNodeB to establish UE context
Modify Bearer Request to SGW with eNodeB IP address
Reject message:
The MME sends a Service Reject message with appropriate reject cause value if the Service Request
can not be accepted by the network.

HSS user profile management (1 of 2)

HSS User profile management procedures include:
Authentication
HSS authenticates UE upon request of MME.
If HSS receives a UE status request, HSS sends a UE-reachability request to the

UE Reachability
Notification Request MME. If MME has an MM context for that user, MME sets a URRP-MME flag to
report information to HSS regarding changes in UE reachability.
UE Activity
Notification
MME informs HSS that a UE is reachable with a UE Activity Notification if URRPMME flag for that UE is configured to report. The MME clears the URRP-MME
flag once it notifies the HSS of the UEs reachability.
Update location
MME informs HSS about identity of MME serving the user;

MME provides HSS with user data such as location.
Notification
MME notifies HSS if PGW for an APN has been removed or changed.
Insert Subscriber
data
HSS updates MME when UE data record has changed.
Purge function
MME informs the HSS when subscriber data has been deleted from the MME,
usually due to inactivity for several days.
Reset
HSS indicates that subscriber records need to be restored (usually due to

restart). MME performs location update for impacted records.
Delete Subscriber
data
HSS notifies MME when UE data has been removed
Cancel Location
HSS notifies MME when a UE withdraws a subscription
1 2 41
The MME accesses the HSS during various procedures in order to obtain or update subscriber
information. Main cases in which the HSS is actively involved:
At
user registration the HSS is interrogated by the 9471 MME as the user attempts to register
to the network in order to check the user subscription rights.
At
Location update as the UE changes location areas, the HSS is kept updated and maintains
a reference of the last known MME.
UE Reachability Notification Request and UE Activity Notification

The HSS requests to be notified when a UE becomes reachable by sending a UE-REACHABILITYNOTIFICATION-REQUEST (URRP-MME) to the MME. The MME sets the UE Reachability Request
Flag in the IDR flag. The MME then reports to the HSS information regarding changes in UE
reachability (for example, when the next NAS activity with that UE is detected). Once the MME
reports reachability to the HSS, the URRP-MME flag is cleared at the MME.
Why the HSS needs to know UE status: The HSS may receive UE status requests from servicerelated entities in the EPS, such as the SGW.
User Profiles
User profiles are partitioned in memory on the 9471 MME in a UE context data structure, which is
described in the next slide.

HSS user profile management: Exercise

Locate the UE context in Appendix B of your Student Guide.
Review the data in the first table and answer the following questions:
1. What is the UE's IMSI?
2. What is the state of the UE? (registered, idle ??)
1 2 42
User profiles are partitioned in memory on the MME in a UE context distributed data structure.
The UE context data structure has one tuple per UE, and includes:
All
static data retrieved from the HSS (S6a) interface during the Attach procedure (Includes
authentication, subscription, and APN data).
Subsequent
dynamic state information related to that UE and the current UE context (Includes
UE session and bearer data).
The UE context data record retrieved from the HSS is populated during the Attach procedure. The
MME keeps the UE subscriber data, unless it is purged or the user roams out of the MME area.
The data shown is part of a data dump of basic UE context data data using the ueadmin_cli
command.
A full example is in the Appendices of this course. Definitions of UE context fields are found in the
9471 OAM&P customer document (418-111-201). See Interpret UE context data in the Fault
Localization chapter.
The IP address 169.254.161.0 is the fixed service IP address of the MME Application Function
(MAF).
MVLR = MME Visitor Location Register. VLR is a previous name for the UE context data.


Which of the following does NOT happen during the Attach procedure?
A. The UE sends a Service Request to the MME.
B. The MME requests the HSS to perform authentication of the UE.
C. The MME sends the PGW IP address to the SGW.
A, the Service Request is performed by the UE when it is in the ECM-IDLE state.
1 2 43

4 Paging procedures
1 2 44
This topic describes basic paging procedures and how they are supported by the 9471 MME.

Paging overview
The Paging procedure is initiated by the MME when data packets need to
be delivered to the UE.
Paging types supported by the 9471 MME:
Basic
SGs_CS and SGs_PS
QCI_1 through QCI_9
For each type, the following Paging methods, related timers, and number
of attempts are provisioned:
Last Seen eNodeB
Last Seen Tracking Area
Last Seen Tracking Area plus Neighboring Tracking Areas
The last seen eNodeB and last seen TA fields are set by the Attach, TAU, and
Service Request procedures.
The list of Neighbor TAs is created by the automatic neighbor list generation
function and/or provisioned at the MME.
1 2 45
The Paging procedure is initiated by the MME to establish a NAS signaling connection to the UE
when notification is received from Serving Gateway that data packets need to be delivered to the
UE.
The set of eNodeBs that are sent Paging messages is based upon the current paging method and
the last known location of the UE (for example, page all eNodeBs in the last seen tracking area).
When a UE receives the Paging message, a Network Triggered Service Request Procedure is
initiated. Paging is performed as part of the Network Triggered Service Request scenario.
Paging types supported by the 9471 MME:
Basic - is the default type and applies to all paging unless other paging types are provisioned.
SGs_CS and SGs_PS - apply to UEs connected in UMTS circuit-switched or packet-switched
network.
QCI_1 through QCI_9 - allows the MME to select different paging strategies for best effort and
dedicated bearer calls, per Quality of Service Class Identifier (QCI). QCI is derived from EPS
bearer ID in the Downlink Data Notification (DDN) message. Note: The MME and SGW must
support 3GPP R10 S11 DDN message.
Basic Paging Strategies with Multiple Tracking Areas:
This MME utilizes the Paging method that was provisioned by the service provider. The service
provider can specify the paging type, and for each type specify the paging method and other paging
related attributes to be used for each page attempt. The following paging methods are supported:
Last Seen eNodeB (pages the eNodeB that sent the last TAU Request or Service Request)
Last Seen Tracking Area (pages eNodeBs in the TA associated with the last TAU Request or
Service Request)
Last Seen Tracking Area plus Neighboring Tracking Areas (pages eNodeBs associated with the
registered TAI list.
Paging last seen eNodeB

If Last Seen eNB == 107 and
Last Seen TA == 2 and Method
== Last Seen eNB
Tracking Area 1
eNB 101
eNB 102
eNB 107 TA 2
NOTE: TA 2 means TA 2 is passed

in the Paging message to eNB 107.
This causes the eNB to only page on
cells associated with TA 2.
eNB 104
X
eNB 107
eNB 109
eNB 103
eNB 105
eNB 106
eNB 108
eNB 110
eNB 112
eNB 111
Tracking Area 3
Tracking Area 2
Resulting paging list is:
eNB 113
eNB 114
Tracking Area 4
The MME uses the S-Temporary Mobile Subscriber Identity (S-TMSI) for paging the mobile.
This temporary identity is constructed from the 9471 MME code and the M-TMSI and is a shortened
version of the GUTI
1 2 46
The illustrations on the next 3 slides show the flexibility of the MME to provision and enforce a
particular paging strategy. The different methods can be applied to successive paging attempts
(attempt 1, 2, 3) or one method may be applied to all attempts (there can be up to 4 attempts).
Using paging performance measurements, paging strategy can be modified as necessary to be more
effective and accurate.
Background for paging strategies:
Increasing
the effectiveness of Paging:
Reducing the number of failed connection attempts due to Paging failures
Getting response from UE with the fewest possible number of page attempts
Increasing
the efficiency of Paging:
Reducing number of Paging messages sent for each UE (i.e., reducing FL traffic)
Need to avoid overloads on the Down Link whenever possible
Increasing
the efficiency of UE location (i.e., Tracking Area Updates)
Reducing number of TAU Requests generated by each UE (i.e., reducing RL traffic)
Need to avoid overloads on the Up Link whenever possible
Also need a comprehensive strategy for handling UL overloads when they do occur

Paging last seen TA

If Last Seen eNB == 107 and
Last Seen TA == 2 and Method
== Last Seen TA
Tracking Area 1
eNB 101

eNB 107 TA 2
eNB 109 TA 2
eNB 104
X
eNB 107
eNB 109
eNB 103
eNB 105
eNB 106
eNB 108
eNB 110
eNB 112
eNB 111
eNB 113
eNB 114
Tracking Area 4
1 2 47

Tracking Area 3
eNB 104 TA 2
Tracking Area 2
eNB 102
Paging last seen TA + neighbors

If Last Seen eNB == 107 and Last
Seen TA == 2 and Method ==
LSTA+N
Tracking Area 1
eNB 101
TA
TA
TA
TA
TA
TA
TA
TA
TA
TA
TA
TA
1
eNB 104
eNB 105
eNB 106
1
X
eNB 107
eNB 108
1
2
eNB 109
eNB 110
eNB 111
1
eNB 112
eNB 113
1, 2, 4
eNB 114
1, 4
2
Tracking Area 4
4
4
4
NOTE: Assume TA 2 is defined to have neighbors
TA 1 & TA 4
4
Tracking Area 2
101
102
103
104
105
107
108
109
110
112
113
114
eNB 103
1 2 48

Tracking Area 3
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB 102
Basic paging procedure
4
eNB
MME
eNB
Session
Manager
6
2
SGW
1
PGW
Uplink u-plane
Downlink u-plane
c-plane
INVITE sip:19745500055@ims.
Via: SIP/2.0/UDP 10.10.112.1
Max-Forwards:70
7
eNB
Tasks performed by MME:

Sends initial Paging message using S-TMSI.
If Paging timer expires, increments the number of attempts.
Uses Paging Attempt Count to select the method for the next page.
The UE will respond to a Page with a Service Request.
If no response from UE after provisioned number of attempts, MME
sends a Downlink Data Notification Failure to SGW
1 2 49
Paging is part of the Network Triggered Service Request procedure. This example shows paging by
last known tracking area. Paging is initiated when a packet arrives for an idle endpoint:
1. Packet arrives for UE at SGW.
2. SGW Notifies MME that a packet has arrived for an idle UE; SGW queues packet.
3. MME sends initial paging request message to each eNB in UEs registered tracking area(s).
Note: This could be a large number of eNBs.
4. Each eNB sends out a page (UE will respond to one of the pages).
5. UE requests service from MME and establishes a radio bearer with eNB.
6. MME signals bearer path to SGW.
7. SGW forwards packet to UE.
The MME sets the Wait for Page Response timer according to the value that was provisioned within
the Paging Policy.
The MME maintains a current page request count for each Network Triggered Service Request
procedure, and uses the current page request count to determine the current paging method
and timer value to be used for the current page attempt. There can be up to 4 attempts.
Separate strategies can be provisioned for basic paging and circuit-switched paging over the SGs
interface. Paging can be limited during UE load balancing tasks.
S-Temporary Mobile Subscriber Identity (S-TMSI): This temporary identity of the mobile
subscriber is used for paging the mobile. The S-TMSI is constructed from the MME code and the
M-TMSI and is a shortened version of the GUTI.

Paging GAP feature

The Paging Gap feature suppress excessive paging.
Excessive paging could lead to negative
performance.
ZZ ZZ
1 2 50
The
MME provides a Paging Gap feature that allows the operator to suppress excessive paging
that may result when the MME attempts to reach UEs that repeatedly fail to respond to pages
and have lost contact with the LTE network.
Excessive
The
paging could lead to negative impact on system performance and capacity.
Paging Gap functionality is controlled by setting a Paging Gap Timer parameter on the
Timers page at the 5620 SAM.
Reference - How it works:

The MME counts the consecutive 'no page response' failures for each UE. This count increments
when all provisioned page attempts have timed out while attempting to reestablish an S1
connection between the UE and its serving eNB. When the count of 'no page response failures for a
UE reaches 3, the MME begins suppressing new page requests for this UE and continues for the
duration of time specified by the Paging Gap Timer. After the Paging Gap Timer interval has
elapsed, the MME again pages the UE when new page requests are received from the SGW or MSC.
If another paging cycle fails with a 'no page response' result, then suppression of paging requests
begins again and continues for the interval of time specified by the Paging Gap Timer from the point
of the last paging failure.
The MME clears the 'no page response' count and processes new page requests whenever the UE
reestablishes an S1 connection with its serving eNodeB and the MME receives an indication of the
UE's current location.


Which of the following Paging methods is NOT supported by the 9471
MME?
A.
B.
C.
D.
Last
Last
Last
Last
Seen eNodeB
Seen Tracking Area
Seen Tracking Area plus Neighbor Tracking Areas
Two eNodeBs
D, Last Two eNodeBs is not a supported paging method.
1 2 51

5 Handover procedures
1 2 52
This topic describes how the 9471 MME supports handover.

Note: Handover to CDMA and UMTS/GSM networks is described in later lessons.

Intra-LTE X2-based handover (1 of 2)
X2 based handover
Source and target eNodeB use X2 interface for handover interface. MME is
informed of the handover by S1 Path Switch message.
MME and SGW are not relocated.
Key tasks performed by MME during X2-based handover:

Sends an Update User Plane Request to the SGW.
The SGW switches the downlink path to the IP address of new eNodeB.
Sends time zone change notification to the SGW if applicable.

Deletes existing bearers not listed in the S1-AP path request
Updates UE context parameters
Optional: Sends time zone and/or network name to UE
The UE may initiate a Tracking Area Update.
1 2 53
Time zone to SGW: The MME sends time zone change notification to the SGW when the UE
moves to a new TA with a new time zone. Time Zone information is sent through the SGW to the
charging entity on Create Session Request, Delete Bearer Response, and Modify Bearer Request
during: time zone changes in MME, MME relocation, or Service Request.
Optional: The MME sends the Enhanced Mobility Management (EMM) information element
(IE) to the UE, if this feature is provisioned and enabled at the MME. The message includes the
MME time zone (or eNodeB time zone if different from the MME and provisioned at the MME). Time
Zone information is used by the UE to support mobile originated (MO) Short Message Service (SMS)
calls, and update of display if applicable. The EMM IE message may also optionally include the
network name and country initials. The IE is ignored if the UE does not support receiving time zone
information. If a TAU is performed, the UE is notified of a time zone during the TAU procedure.

Intra-LTE X2-based handover (2 of 2)

eUTRAN
ePC
(7)
(10)
(1)
MME
MME
eNB
eNB
(8)(9)
(6)
(4)(3)(11)
(2)
S-GW
S-GW
(5)
Active-mode UE
EPS Bearer
eNB
eNB
(1) UE measures eNodeBs in its neighborhood.

(2) UE provides measurement report to the
source eNodeB.
(3) Source eNodeB decides that a HO is
warranted and signals target eNB that HO is
requested, transferring UE context data.
(4) Target eNodeB admits the HO (based on
evaluation of resources) and Acks it.
(5) On receipt of Ack, source eNodeB directs UE
to re-select target eNodeB and begins
forwarding data to target eNB where it is
buffered. UE suspends sending data.
1 2 54
(6) UE confirms successful re-selection of target

eNodeB which allows buffered DL data to be
emptied to UE.
(7) Target eNodeB instructs MME to do a path
switch.
(8) MME requests a User Plane (UP) switch
which the SGW executes; UE can now send.
(9) SGW acknowledges UP update to MME.
(10) MME acknowledges to target eNodeB.
(11) Source eNodeB is told to delete UE context
(since it is not needed).
The beginning state for all intra-LTE handover types:

The eNodeB may trigger an intra-LTE handover only after the default bearer is established and
security activated. The UE must be in RRC CONNECTED state in the source cell source eNodeB.
The final state for all intra-LTE handover types:
The UE is in RRC CONNECTED state in the target cell, target eNodeB. If the handover occurs, all the
bearers (default and dedicated) not rejected by the target eNodeB and/or MME are handed over
to the target eNodeB cell. The UE context and associated resources in the source eNodeB are
deleted.
MME queuing of certain messages during X2 or S1 handover
If the MME receives a rejection to a UE Context Modification Request message with a circuitswitched (CS) Fallback Indicator from the eNodeB because an X2 or an S1 handover is in
progress, the MME resends a UE Context Modification Request message with CS Fallback
Indicator to the target eNodeB when the handover is complete or to the source eNodeB if the
handover fails.

Intra-LTE S1-based handover (1 of 3)
S1-based handover is used when:

There is no X2 link between the source and target eNodeB
The X2 link is not operational
The target eNodeB is not connected to the MME currently serving the UE
The operator has provisioned (at eNodeB) S1 handover for this source-to-target
eNodeB pair (X2 handover is not allowed)
An X2-based handover has been rejected by the target eNodeB with cause
invalid MME group
MME supports the following S1-based handover scenarios:
Without MME and SGW relocation

Without MME relocation and with SGW relocation
With MME and SGW relocation
With MME relocation and without SGW relocation
Two types of data forwarding from the source eNB to the target eNB:
Direct forwarding: X2 connectivity is available between eNodeBs.
Indirect forwarding: X2 connectivity is not available between eNodeBs; traffic
forwarded via SGW.
1 2 55
Purpose of S1 handover: Move RRC Connection from the source cell to target cell with handover
preparation over S1-MME interface.
Mandatory when the MME changes
Used when: (1) X2 control path not available, (2) operator configuration requires
Specially useful for inter-vendor interworking
Elementary procedures (as specified in 3GPP TS 36.413) that may be used during this procedure:
Handover Required
Handover Command
Handover Preparation Failure
Handover Request
Handover Request Acknowledge
Handover Failure
Handover Notify
Handover Cancel
Handover Cancel Acknowledge
eNodeB Status Transfer
MME Status Transfer
Direct forwarding: X2 connectivity is available between the source and target eNodeBs.
Indirect forwarding: X2 connectivity is not available between the source and target eNodeBs.
Traffic is forwarded from the source eNodeB to the target eNodeB via the SGW.


Source
eNodeB
UE
Target
eNodeB
Source
MME
Target
MME
Source
SGW
Target
SGW
This slide shows the high-level call flow for S1based handover without MME and SGW
relocation and with indirect forwarding.
Measurement
Report
2
For additional call flows, see:
Handover Required
3
Handover Request
9471 MME Technical Description document

(418-11-200)
3GPP TS 23.401 and TS 36.413.
4
HO Request ACK
5
Create Indirect Data
Forwarding Tunnel
Request
6
Create Indirect Data
Forwarding Tunnel
Response
7
8
Handover Command
Handover
Command
9
eNodeB Status Transfer
1 2 56
1. UE measures eNodeBs in its neighborhood and provides measurement report to the source
eNodeB.
2. Source eNodeB decides that a HO is warranted and selects target cell. If target cell belongs to a
different eNodeB, eNodeB determines if X2-based or S1-based handover is needed. In this case,
the source eNodeB initiates an S1-based handover with indirect forwarding to the target eNodeB
(since there is no X2 connection). The eNodeB sends Handover Required message to the MME
that includes target eNodeB Identity, target TAI. Absence of a Direct Forwarding Path Available
flag indicates that indirect forwarding is needed.
3. The MME sends a Handover Request to the target eNodeB. This creates the UE context in the
target eNodeB, including information about the bearers and security context. The MME pauses
non-handover related S1 interface procedures to minimize reject messages.
4. The target eNodeB ACKs the Handover Request and includes the
RRCConnectionReconfiguration message to be transmitted by the source eNB to the UE.
5. MME sends a Create Indirect Data Forwarding Tunnel Request to SGW with a list of bearers and
target eNodeB. Since this is an indirect forwarding case, the target eNodeB establishes an S5
media path through the SGW.
6. SGW responds with Create Indirect Data Forwarding Tunnel Response.
7. The MME sends the Handover Command to the source eNodeB. The message includes the
RRCConnectionReconfiguration from the target eNodeB and DL data information.

8. The source eNodeB forwards the Handover Command to the UE. The UE removes any EPS
bearers for which it did not receive the corresponding EPS radio bearers in the target cell.
9. The source eNodeB sends a Status Transfer message to the MME to convey the UL and DL
status.


Source
eNodeB
UE
Target
eNodeB
Target
MME
Source
MME
Source
SGW
Target
SGW
10
MME Status
Transfer
11
12
Indirect Forward
of Data
Handover Confirm
13
14
Handover Notify
Modify Bearer Request

15
Modify Bearer Response
16
Downlink User Plane Data
17
Tracking Area Update Procedure

18
Delete Session Request
19
UE Context Release Command
20
UE Context Release Complete
1 2 57
10. The MME forwards the Status Transfer to the target eNodeB.
11. The source eNodeB sets up temporary resources and begins an indirect forwarding of DL data
12.
13.
14.
15.
16.
17.
18.
19.
20.
to the target eNodeB via the SGW.

After the UE synchronizes to the target cell, it sends a Handover Confirm message to the target
eNodeB. Downlink packets forwarded from the source eNodeB can be sent to the UE. Also,
uplink packets can be sent from the UE, which are forwarded to the SGW and on to the PGW.
The target eNodeB sends a Handover Notify message to the MME.
The MME sends a Modify Bearer Request to the SGW for each PDN connection. The MME sends
eNodeB time zone to the SGW (eNodeB time zone is the same as the MME unless difference is
provisioned at the MME). The MME also starts a timer to supervise when resources in the source
eNodeB can be released.
SGW sends a Modify Bearer Response to MME.
Downlink packets from the SGW are sent on to the target eNodeB.
UE initiates a Tracking Area Update procedure. The MME knows that it is a Handover procedure
(as it received the bearer contexts by handover messages) and therefore the target MME
performs only a subset of the TA update procedure. Optional: The UE receives notification of
time zone and/or network name during the TAU procedure.
When the timer started in step 12 expires, the source MME sends a Delete Session Request to
the source SGW to release the temporary resources used for indirect forwarding.
The source MME sends a UE Context Release Command message to the source eNodeB.
The source eNodeB releases its resources related to the UE and responds with a UE Context
Release Complete message.

Key handover decisions
Source eNodeB decisions
Whether handover is required

Target cell and target eNodeB
X2-based or S1-based handover
Direct forwarding path or indirect forwarding path
Which EPS bearers are subject to forwarding from source to target eNodeB
Source MME decisions

MME relocation
SGW relocation
1 2 58
eNodeB decisions
The source eNodeB determines whether a handover is warranted and selects a target cell
based on measurement reports from the UE.
If a target cell belongs to a different eNodeB, then the eNodeB determines if X2-based or S1based handover is needed.
The availability of a direct forwarding path in S1-based handover is determined in the source
eNodeB and indicated to the source MME. If X2 connectivity is available between the source
and target eNodeBs, a direct forwarding path is available.
The source eNodeB decides which of the EPS bearers are subject to forwarding of packets from
the source eNodeB to the target eNodeB.
MME decisions
The decision to relocate the MME is made by the source MME. If the target eNB is not in the
source MME serving area, then it selects an MME serving the area of the eNodeB.
The MME also determines (target MME if MME relocation; otherwise the source MME) whether
SGW relocation is required. If the Tracking Area (TA) of the target eNB is not served by the
SGW, then the MME selects another SGW that is assigned to serve the TA.

MME support for restricted handover to reserved cells

Operators may restrict access to newly installed eNodeBs to test UEs only.
To support handovers of test UEs to restricted eNodeBs, the MME:
Receives RFSP index from HSS to indicate the UE is a test UE
Sends RFSP index value to eNodeBs
Test
UE
MME
New
eNodeB
RFSP index = UE is test UE
HSS
S11
PGW
SGW
S1-MME
Subscriber
UE
S6a
S5
S1-U
1 2 59
SGi
PDN
Operators may restrict access to newly installed eNodeBs to test UEs only.
To support handovers of test UEs to restricted eNodeBs, the MME:
Receives a special RFSP index from HSS to indicate the UE is a testing UE
Sends this RFSP index value to eNodeBs
Handover restriction note: 3GPP Standards have a mechanism to forbid idle mode reselection of
commercial UEs towards restricted eNBs, but there is no Standard mechanism to forbid incoming
handovers. The MME supports a proprietary mechanism using the RFSP index to forbid incoming
handovers to commercial UEs.
The Index to RAT/Frequency Selection Priority (RFSP Index) parameter is an index referring to
user information such as mobility profile, service usage profile, and is UE specific.


Which of the following are EPS mobility management procedures supported
by the MME? Select all choices that apply.
A.
B.
C.
D.
E.
Attach
X2 Handover
Radio Resource Connect
Paging
1 2 60
A, B, C, E.

MME support for initial Attach procedure

Network element pooling
Network element selection and communication
Additional mobility management procedures supported by the MME:
TAU
Service Request
HSS user profile procedures
Paging
Handover
1 2 61

Describe how the 9471 MME supports the following LTE mobility management
procedures:
Attach
TAU
Service Request
HSS user profile
Paging
Handover
Explain how the 9471 MME selects network elements to support these
procedures
1 2 62

References
The following customer documents provide information about the
9471 MME mobility management functions:
9471 MME Technical
Description

interfaces.
(418-111-200)
5620 SAM LTE ePC User

Guide
Describes the 9471 MME provisioning.
(3HE 06981)
9471 MME OAM&P
Describes the 9471 MME fault handling procedures.
(418-111-201)
Customer documentation is found on the Alcatel-Lucent OnLine Customer

Support (OLCS) site: https://services.support.alcatel-lucent.com/services/lte
1 2 63

End of module
9471 MME Mobility Management Procedures
1 2 64

Section 1
9471 MME Overview
Module 3
9471 MME Session Management Procedures

Technical Overview

Blank page
132
9471 MME Overview 9471 MME Session Management Procedures
Document History
Edition
Date
Author
Remarks
01
YYYY-MM-DD
First edition

Module objectives
Upon completion of this module, you should be able to describe how the
9471 MME supports LTE bearer sessions, including:
Activation,
Modification,
Deactivation, and
Preservation of data sessions
133
This module provides an overview of the EPS session management procedures and functions
supported by the 9471 MME.

Table of Contents
1 EPS bearers
2 Role of 9471 MME in session management
135

Page
7
17
1 EPS bearers
137
This section provides a review of EPS bearers in the LTE network.

Evolved session management

9471 MME plays a major role in Evolved Session Management (ESM):
Activation,
Modification,
Deactivation of EPS bearers
138
Evolved Session Management (ESM) involves activation, modification and deactivation of EPS
bearers to support communication between the UE and the Evolved Packet Core network.
9471 MME plays a major role in all phases of ESM procedures such as creation, modification and
termination of ePS bearers.

EPS bearers: Review
The EPS bearer is a logical association between the UE and the PGW.
An EPS bearer is composed of three elements:
S5/S8 bearer
S1 bearer
Radio bearer
ePC
eUTRAN
UE
eNB
Internet
PGW
SGW
PDN/
APN
End-to-end service
EPS bearer
Bearer ID is
assigned by
MME.
Radio bearer
Radio
139
S1 bearer
S1
SGi interface
S5/S8 bearer
S5/S8
SGi
The EPS bearer is an equivalent of the PDP Context used in 2G/GPRS and 3G/UMTS standards. It
is a logical association between the UE and the PGW, and aggregates one or several data flows
transported between the two entities.
An ePS bearer is composed of three elements:
S5/S8 bearer a tunnel that transports packets between the SGW and PGW.
This bearer remains up when the UE is in the IDLE state.
S1 bearer a tunnel that transports packets between the SGW and eNodeB. This bearer is
not up when the UE is in the IDLE state.
Radio bearer a Radio Link Control (RLC) connection between the eNodeB and the UE.
There is one RLC protocol machine per radio bearer. This bearer is not up when the UE is in
the IDLE state.

EPS bearer types: Review
There are two bearer types:

Default bearer initial non-GBR bearer established when the UE attached.
Dedicated bearer - additional bearer established by same UE to same PDN.
UE
eNB
SGW
PGW
Default bearer context [PDN addr-1, QoS QCI-9, EPS Bearer-ID 1]

Radio bearer
S1 bearer
S1 bearer
1 3 10
SGi interface
S5/S8 bearer
Dedicated bearer context [PDN addr-1, QoS QCI-9, EPS Bearer-ID 2]

Radio bearer
PDN/
APN
SGi interface
S5/S8 bearer
Default vs. dedicated bearer:

An ePS bearer established when the UE initially attaches to the network and connects to a PDN is
called a Default Bearer (always a non-guaranteed bit-rate (non-GBR)). A Default Bearer remains
established throughout the lifetime of the PDN connection to provide the UE with always-on IP
connectivity to that PDN. Default Bearers can be activated or deactivated independently from one
another.
Any additional ePS bearer established to the same PDN by the UE is referred to as a dedicated
bearer (may be GBR or non-GBR). A dedicated Bearer is always associated with a Default Bearer.
Default and the associated Dedicated bearer provide connections to the same PDN with different
guaranteed QoS. One primary Default bearer might have multiple dedicated bearers assigned.
A user normally has one default bearer to an APN, but may have two default bearers - one IPv4
bearer and one IPv6 bearer - if "multiple PDN IPv4v6" is provisioned at the MME and PGW, and the
HSS subscription allows IPv4v6.
Each bearer is associated with Guaranteed Bit Rate (GBR) and Maximum Bit Rate (MBR) QoS
attributes.

Multiple PDN connections
A UE may connect to multiple PDNs.
Each connection requires one default bearer.

Each connection may have additional dedicated bearers.
The UE is associated with a unique IP address for each PDN.
All EPS bearers for a UE go through the same SGW.
Multiple default EPS bearers: simultaneous independent connections to

different PDNs.
Multiple dedicated EPS bearers: connections to the same PDN but with
different QoS.
1 3 11
A UE may connect to multiple PDNs using multiple bearers:

Each
PDN connection requires one default bearer and may have additional dedicated bearers.
Up
to 11* bearers in combination of dedicated and default (for example 1 default and 3
dedicated, or 1 default and 10 dedicated).
The maximum number of default bearers is 6 (up to 6 PDNs allowed).
For
each APN / PDN that a UE is connected to, the UE is associated with a unique IP address
for that PDN.
*The maximum number of bearers allowed for a UE in the end-to-end LTE network is 8.
Multiple default EPS bearers: provide simultaneous independent connections to different PDNs
(for example, to the Internet for one application, while to a private network for another one).
Default Bearers are created on a per PDN basis. So if a UE is connecting to two PDNs it will need to
establish two default bearers (or two default bearers to each PDN if multiple PDN IPv4v6 (MPDN
IPv4v6) is provisioned).
Multiple dedicated EPS bearers: provide connections to the same PDN but with different QoS.
All EPS bearers for a UE go through the same SGW.
ePS Bearer ID
An ePS bearer identity uniquely identifies an ePS bearer for one UE accessing via E-UTRAN (eNodB).
The ePS Bearer Identity is allocated by the MME. There is one to one mapping between ePS RB and
ePS Bearer, and the mapping between ePS Radio Bearer (RB) Identity and ePS Bearer Identity is
made by E-UTRAN.
Multiple PDN connections example 1
Default Bearer Context 1 [PDN-Addr-1, QoS: QCI 9, EPS Bearer-ID-1]

GTP-Tunnel-4
RB-1
GTP-Tunnel-1
APN_1
IP
address
1
Example 1: UE connected to multiple PDNs
PDN-1
GTP-Tunnel-5
RB-3
UE
GTP-Tunnel-2
GTP-Tunnel-3
GTP-Tunnel-6
eNB
1 3 12
SGW
APN_2
RB-2
PDN-2
APN_3
IP
address
2
IP
address
3
PGW-0
PDN-3
PGW-1
The first example depicts a UE connected to multiple PDNs for a GTP-based S5/S8. The PGW-1
provides access to multiple PDNs.
In this example, there is only one default bearer per PDN connection.

Multiple PDN connections example 2

Example 2: UE with dedicated bearers to PDN-2
Default Bearer Context 1[PDN-Addr-1, QoS: QCI 9, EPS Bearer-ID-1]

GTP-Tunnel-4
IP
address
1
RB-1
GTP-Tunnel-1
Dedicated Bearer Context 1[PDN-Addr-1, QoS: QCI 1, EPS Bearer-ID-2, LBI]

RB-2
PGW
GTP-Tunnel-2
GTP-Tunnel-5
Dedicated Bearer Context21[PDN-Addr-1, QoS: QCI 5, EPS Bearer-ID-3,

LBI]
GTP-Tunnel-6
RB-3
UE
eNB
1 3 13
GTP-Tunnel-3
SGW
The second example shows a UE with a dedicated bearer to PDN-2. The linkage between the
default bearer and dedicated bearer is provided by LBI (Linked Bearer Identifier).
In this example, there is only one default bearer per PDN connection.

PDN-1
Bearer level QoS
All EPS bearers (GBR and non-GBR) are associated with QoS parameters:
QCI 1-9: QoS Class Identifier
ARP: Allocation and Retention Priority
GBR bearers are associated with additional QoS parameters:

GBR: Guaranteed Bit Rate
MBR: Maximum Bit Rate
APN-AMBR: Aggregate Maximum Bit Rate associated with APN

Subscription parameter in HSS for each APN
Indicates the maximum bit rate to be provided across all non-GBR bearers and
across all the PDN connections of the same APN.
UE-AMBR: Associated with each UE in the connected state

Subscription parameter in HSS
Limits the total non-GBR traffic across all the APNs
1 3 14
QoS Class Identifier (QCI) used as a reference to a set of access network related quality of
service (QoS) parameters, for the transmission between the UE and the eNodeB. They include
Resource type, priority, packet delay budget and packet loss rate. (Refer to TS 23.203.)
Allocation Retention Priority (ARP) Allocation and retention mechanisms used for user/bearer
priority when assigning network resources, (not traffic priority). These include Priority level, preemption capability, pre-emption vulnerability.
ARP is typically used for the allocation of the bearer resources at session setup or during handover.
The primary purpose of ARP is to decide whether a bearer establishment or modification request
can be accepted or needs to be rejected in case of resource limitations. ARP can be used (e.g. by
the eNodeB) to decide which bearer(s) to drop during exceptional resource limitations (e.g. at
handover). This drop can be hard (bearer release) or soft (bearer downgrading).
Guaranteed Bit Rate (GBR) applicable only to bearers that require guaranteed Quality of
Service (examples: voice or streaming).
Maximum Bit Rate (MBR) help to set a limit on the data rate expected for the related service.

Knowledge check: Evolved session management

When a UE is in the EMM_REGISTERED state, it is required to have both a
default EPS bearer and a dedicated EPS bearer.
True
False
False. Only the default EPS bearer is required.
1 3 15


1. If a UE is connected to two PDNs, how many PDN IP
addresses are needed by the UE?
Two
2. If a UE has one default bearer and two dedicated bearers

connected to the same PDN, how many PDN IP addresses are
needed by the UE?
One
1 3 16

2 Role of 9471 MME in session

management
1 3 17

MME - SGW session management procedures

The MME supports GTP-C messages over S11 interface to the SGW for:
Session Creation procedures
Session Deletion procedures
MME
S11
UE
SGW
eNB
PGW
SGi interface
EPS bearer
Radio bearer
S1 bearer
1 3 18
PDN/
APN
S5/S8 bearer
The MME supports the relevant GTP-C messages over S11 interface to the SGW:
Session Creation procedures:
Default Bearer Creation
Dedicated Bearer Activation
Bearer Modification with bearer QoS update (PGW initiated)
Dedicated Bearer Modification without bearer QoS update
PGW initiated bearer deactivation
MME initiated Dedicated bearer deactivation
UE requested bearer resource allocation
UE requested bearer resource release
HSS initiated subscribed QoS modification
Session
Deletion procedures:
Release Access Bearers
Update User Plane (handover)

MME - eNodeB session management procedures

The MME interacts with the eNodeB over the S1-MME interface (S1AP
message) to setup S1/radio bearers:
Setup UE context in eNodeB
Release UE context in eNodeB
Activate/Modify/Delete S1 Bearers in eNodeB
MME
S1-MME
eNB
UE
Radio bearer
1 3 19
SGW
S1 bearer

MME - UE session management procedures

The MME interacts with the UE to support procedures over S1-MME
interface (NAS message):
Activate Default EPS bearers

Activate Dedicated ePS bearers
EPS Bearer Context Modification or Deactivation
UE Requested PDN Connectivity or Disconnection
UE Requested Bearer Resource Allocation/Modification
ESM Information Request
MME
S1-MME (NAS)
UE
eNB
SGW
EPS bearer
1 3 20
PGW
SGi interface

PDN/
APN

With which of the following network elements does the MME interact to set
up default and dedicated EPS bearers?
Select all choices that apply.
A.
B.
C.
D.
UE
SGW
PGW
eNodeB
A, B, and D; the MME does not interact with the PGW.
1 3 21

This module covered 9471 MME Evolved Session Management functions in
the LTE network, including:
EPS bearers
PDN connections
Role of MME in bearer management
1 3 22

You should now be able to describe how the 9471 MME supports
LTE bearer sessions, including:
Activation,
Modification,
Deactivation, and
Preservation of data sessions
1 3 23

References
the 9471 MME session management functions:
9471 MME Technical
Description

interfaces.
(418-111-200)

1 3 24

This slide is intentionally left blank.
1 3 25

End of module
9471 MME Session Management Procedures
1 3 26

Section 1
9471 MME Overview
Module 4
9471 MME Security Functions

Technical Overview

Blank page
142
9471 MME Overview 9471 MME Security Functions

Document History
Edition
Date
Author
Remarks
01
YYYY-MM-DD
First edition

Module objectives
Describe the 9471 MME Evolved Packet System (EPS) security functions
143
This module provides an overview of the security functions provided by the 9471 MME in the
Evolved Packet System.

Table of Contents
1 Security functions and procedures
145

Page
7
1 Security functions and procedures
147

Security functions supported by the 9471 MME

Security functions can be categorized into two areas:
EPS security functions and services
EPS-AKA based authentication of UE and MME
NAS Security Mode Control
Secure protocols for OAM and platform traffic
148
EPS-AKA = Authentication and Key Agreement

LTE security functions and MME network security are both specified by the 3GPP standard. The
implementation of MME network security and the architecture supporting the network security
functions is also influenced by the Customer Security requirements, the Alcatel-Lucent Product
Security Guidelines, and the National Security Agreement (NSA) recommendations.
The EPS and OAM security functions supported by the 9471 MME are described in this module.

Security Mode Command overview
UE
SMC procedure provides integrity protection

and ciphering of the downlink and uplink
signaling messages across the NAS.
eNodeB
Security Context
established during
Authentication
During Authentication, an EPS NAS Security

Context is established:
Are there any signaling messages

that would not require the SMC
procedure?
149
After
Authentication, MME
initiates SMC to
secure NAS
connection.
Secured
Contains keys and algorithms.

Is stored on both the UE and the MME.
After Authentication, the MME uses the EPS

NAS Security Context to initiate the SMC
procedure.
MME
NAS signaling messages that do not

require integrity protection:
ATTACH REQUEST
AUTHENTICATION FAILURE
AUTHENTICATION RESPONSE
DETACH ACCEPT
DETACH REQUEST
IDENTITY RESPONSE (if
requested parameter is IMSI)
SECURITY MODE REJECT
EPS Mobility Management (EMM ) messages are the result of mobility management procedures, like
Attach and Tracking Area Update procedures. These procedures can be performed only if there is a
Non-Access Stratum (NAS) signaling connection between the UE and the MME. The NAS Security
Mode Command (SMC) procedure initiated by the MME provides integrity protection and ciphering
of the downlink and uplink of the EMM and ESM NAS signaling messages.
Before NAS security can be activated, the MME and the UE need to establish an EPS security
context, usually during authentication with the HSS.
Then, the MME initiates the SMC procedure, which uses a key obtained during the authentication
procedure to start NAS signaling security between the MME and the UE.
Security context
The ePS NAS security context is the state containing security information that is established
between the UE user and the network (MME). The security context is stored on both the UE and the
MME.
Standard specifications to NAS signaling and NAS signaling security are in 3GPP TS 23.401.

EPS-AKA based authentication of UE and MME
MME uses EPS-AKA protocol for authentication between UE and EPS.

Authenticates the UE to the MME, and the MME to the UE.
A shared secret key is stored in the USIM of the UE and in the AuC located
within the HSS.
1. HSS generates
3. MME compares
key data from HSS
and UE.
key using
algorithm.
=
UE
eNodeB
MME
HSS
2. UE generates
key using same

algorithm as HSS.
1 4 10
AuC = Authentication Center

EPS- Authentication and Key Agreement (EPS-AKA) provide a secure mechanism to authenticate the
UE to the MME and the MME to the UE.
The AKA is a challenge-response based mechanism that uses symmetric cryptography. AKA is run in
the MME as well as in the USIM (Universal Subscriber Identity Module) in the UMTS IC Card (UICC)
in the UE. A detail description of the AKA protocol and parameters for eUTRAN can be found in
3GPP TS 33.401.
The AKA protocol uses a secret shared key K that is stored by the operator in the USIM in the UE
and in the Authentication Center (AuC) located in the Home Subscriber Server (HSS). An EPS
security context is established in the UE and the network when an EPS authentication is successfully
performed.
The NAS COUNT is a pair of counters used in NAS signaling security to count the number of NAS
signaling messages transmitted by a sender ( UE for uplink traffic or the MME for downlink traffic).
NAS COUNT is used as input to the computation of security keys. The 3-octet count is initialized at
0 and wraps around at 224.

When EPS-AKA based authentication is initiated
The MME initiates Authentication Information Request to the AuC in the

HSS as soon as the UE IMSI is known.
The MME can also initiate EPS-AKA:
During TAU, Service Request, or Handover
Randomly during subsequent Attach procedures
When the NAS COUNT is close to wrap around
1 4 11
Authentication frequency
Authentication is always performed on initial Attach of the UE to the network. Authentication
frequency for various other procedures, including LTE Tracking Area Update (TAU), Inter Radio
Access Technology (IRAT) TAU, and number of times a Globally Unique Temporary Identity (GUTI)
is re-allocated can be provisioned by the operator in the PLMN Security provisioning form. For
example, by default GUTI re-allocation is performed for TAU 20% of the time, but may be changed
from 0-100% of the time.

NAS signaling security (1 of 2)

Once the EPS-AKA procedure is successfully completed, the MME uses the
NAS SMC procedure.
UE
eNodeB
MME
MME sends
Authentication Request
to UE.
HSS
MME sends Authentication

request to HSS. Response
include Authentication
vectors.
After Authentication
Response, MME sends
Security Mode Command
to add security to the
NAS connection.
1 4 12

Besides providing a secure mechanism to authenticate the UE to the MME and the MME to the UE,
the EPS-AKA protocol is the base to exchange additional credentials between the UE and the MME
to support higher layer security functions like NAS signaling security.
The MME uses NAS Security Mode Control (SMC) procedures to establish a NAS signaling security
association between the UE and the MME in order to further protect the NAS signaling messages.
Before security can be activated, the ePS-AKA procedure must be successfully completed and the
MME and the UE need to establish an ePS security context (described on previous slide).
The result of the SMC procedure:
The
MME takes the ePS Security Context into use
The
UE and the MME agree on the NAS signaling integrity protection and encryption algorithms
to be used.
NAS signaling security association between the UE and the MME is established with the
corresponding NAS keys and security algorithm.

NAS signaling security (2 of 2)

The MME supports two NAS signaling security mode capabilities:
Ciphering
Integrity protection
Ciphering and integrity protection algorithms are provisioned from the EPS Encryption Algorithm and
EPS Integrity Protection Algorithm provisioning forms at the 5620 SAM.
1 4 13
The MME supports the following NAS Signaling security mode capabilities:
1. Ciphering of UE to MME and MME to UE NAS signaling traffic when the operator chooses to do so.
Messages are encrypted using SNOW3G or AES algorithms
Requires key at UE and MME (KNASenc)

2. Integrity protection of UE to MME and MME to UE NAS signaling traffic.
Messages are protected using no algorithm, SNOW3G, or AES algorithms
Appends hash code to messages
Requires key at UE and MME (KNASint)

Ciphering of NAS signaling messages consists of using symmetric encryption to cipher the content
of the message and then send it. A single secret key is used to encrypt the message at the sender
and decrypt the message at the receiver. This key is called the cipher key and is different from the
integrity protection key.
Integrity protection of NAS signaling messages consists of appending a hashing code to the
content of the NAS signaling messages. The receiver performs the same hashing function as the
sender, and compares the output with the hashing code contained in the message. If the two codes
are the same, it means the integrity of the message is preserved. Since the hashing algorithm is
known, the hashing function requires a secret integrity protection key, that is know only by the
sender and the receiver, as input.
SNOW 3G is the stream cipher for 3GPP encryption algorithms.
Advanced Encryption Standard (AES) is an encryption standard adopted by the U.S.
government.
EPS Security Context - Before security can be activated, the MME and the UE need to establish
an EPS security context. The ePS NAS security context is the state containing security information
that is established between the UE user and the network (MME). The security context is stored on
both the UE and the MME.
OAM traffic security

OAM traffic to remote systems use the
following secure protocols:
5620
SAM
SSH v2 to manage the CLI interfaces

sFTP for file transfer
SNMPv3 for OAM traffic between MME and
external system
NETCONF for configuration requests
SSH
sFTP
SNMPv3
NETCONF
https
https for management GUI

IPSec policies for maintenance terminals
1 4 14

SSH
= Secure Shell
sFTP
= Secure file Transfer Protocol
SNMPv3
= Simple Network Management protocol version 3
NETCONF
https
GUI
9471 MME
= Network Configuration Protocol
= Secure web server
= Graphical User Interface
IPSec
= IP security

IPSec
SSH
sFTP
https
IPSec
SSH
sFTP
https
Knowledge check: 9471 MME security

During an initial Attach procedure, the 9471 MME authenticates the UE at
the HSS after the NAS security procedures have been performed.
True
False
False. The EPS-AKA protocol, which authenticate
the UE at the HSS, is performed before the NAS
security procedures are performed. The AKA
protocol provides a base for the NAS security.
1 4 15

This module covered 9471 MME EPS security functions:
Security mode command

EPS-AKA
NAS security
Network security
OAM security
1 4 16

Describe the 9471 MME Evolved Packet System (EPS) security functions
1 4 17

References
9471 MME security functions:
9471 MME Technical
Description

interfaces.
(418-111-200)
9471 MME Security

Management
Describes the 9471 MME security features.

Provides security-related configuration procedures
such as platform security, SSH, and user
administration.
(418-111-203)
5620 SAM LTE ePC User

Guide (3HE 06981)
Explains how to provision MME application security

parameters such as ciphering algorithms and the
number of times authentication should be
performed.

1 4 18

1 4 19

End of module
9471 MME Security Functions
1 4 20

Section 1
9471 MME Overview
Module 5
9471 MME Support for Roaming

Technical Overview

Blank page
152
9471 MME Overview 9471 MME Support for Roaming

Document History
Edition
Date
Author
Remarks
01
YYYY-MM-DD
First edition

Module objectives
Define roaming UE
Identify two roaming architectures and how they are supported by the 9471
MME: home-routed and local-break-out
153
This module describes how roaming UEs are handled by the 9471 MME.

Table of Contents
1 EPS roaming overview
2 MME support for roaming
155
Page
7
11

1 EPS roaming overview
157

Roaming UE: Definition
MME provisioning identifies the Serving PLMN.
Roaming UE:
PLMN ID in the IMSI does not match

the Serving PLMN.
UE point of view:
If the PLMN ID does not match the

Serving PLMN, then the MME is the
"visited" PLMN.
MME supports UEs roaming from:

Another operators eUTRAN
UTRAN
GERAN
158
The MME considers a UE to be a roamer if the PLMN ID in the UEs IMSI does not match the
Serving PLMN (recall that the Serving PLMN may be the MMEs Home PLMN ID, or a Shared PLMN
ID if the MME is shared by multiple operators).
From the UE point of view, if the PLMN ID in the IMSI does not match the Serving PLMN, then the
MME is the "visited" PLMN.
The MME supports roaming into eUTRAN from GERAN, UTRAN, and from E-UTRAN of a different
operator by way of the roamer sending an Attach Request or TAU Request to the eUTRAN.
Public Land Mobile Network (PLMN) = Mobile Country Code (MCC) plus Mobile Network Code (MNC).
UTRAN = UMTS Terrestrial Radio Access Network
GERAN GSM-EDGE (Global System for Mobile Communications - Enhanced Data rates for GSM
Evolution) Radio Access Network

Determining if a UE is a roamer
MME provisioning identifies the Serving PLMN.
+++ 2012/05/07 14:50:23.547 CRAFT_MAINT HIGH ACTIVE maf:7232

E:44023 S:915 (hssPxy_util.cpp 2658 X-0:9:0
26.49.11.00:1335456548 mmebld 10.165.161.0)
MME-HSSEIR-PXY:MVLR_SUB for IMSI 310012001001001 or IMEI
1a3254161232510:
vlrIdx 0
ueHomePlmn 310012
UE's home PLMN matches the serving PLMN.
isRoamer NOT ROAMER
nonHssData 0
unauthImsi 0
urrpMme 0
subStatus SERVICE_GRANTED
networkAccessMode BOTH PACKET AND CIRCUIT
159
Public Land Mobile Network (PLMN) = Mobile Country Code (MCC) plus Mobile Network Code (MNC).
1.
The UE provides its Home PLMN in the IMSI during Attach or TAU Request.
2.
The MME compares its own PLMN (the serving PLMN) with the UE's home PLMN to determine
if it is a roamer.
Additional checks made by the MME are described in an upcoming slide.
3.
The UEs home PLMN and whether or not it is a roamer are stored in the UE context at the
MME.
The slide shows:
The PLMN provisioning data for the serving MME
A portion of the UE subscriber data table found in the UE context.

Roaming architecture
HSS
PGW
VPLMN
S10
Rx
Operator IP
services
SGi
HPLMN
Roaming architecture for

home-routed scenario
PCRF
Gx
MME S6a
S11
S8
S1-MME
S1-U
SGW
eUTRAN
User data path
PCRF
HSS
Rx
HPLMN
VPLMN
S10
Roaming architecture for

local breakout scenario
S9
MME S6a
V-PCRF
S11
Gx
S1-MME
S5
SGi
S1-U
eUTRAN
1 5 10
Home
operator IP
services
SGW
Visited
operator
PDN
PGW
In the roaming architecture, an MME in Visited PLMN (VPLMN) has an S6a interface to the HSS in
the Home PLMN (HPLMN) of the UE. The bearers for a UE are anchored at the SGW of the VPLMN.
In the home-routed architecture, bearer traffic is routed to the UEs HPLMN (the SGW connects to a
PGW in the UEs home network over S8).
In the local-breakout architecture, bearer traffic is routed to the PGW in the VPLMN (the SGW
connects to the local PGW over S5).
For both cases, the MME selects an SGW resource from the TAI NAPTR query result whose service
type includes S5 or S5+S8. Operators must ensure that all SGWs support both S5 and S8 service in
order to implement roaming.
Notes
For roaming to work properly, operators must deploy SGWs that support S5, S8 and S11. The MME
prefers to select an SGW that supports both S5 and S8. However, if the NAPTR query returns only
SGWs supporting the S5 interface, and if the roaming UE is allowed to connect to a PGW in the
VPLMN, then the MME selects an SGW supporting S5 interface. Any subsequent PDN connection
requests are rejected if local break out is not allowed for the requested PDN.
Some visited networks may not support LTE and/or LTE roaming and so the UE may only obtain
access to 2G/3G coverage.

2 MME support for roaming
1 5 11

How the 9471 MME supports roaming
Up to 512 PLMN can be provisioned at the 9471 MME:

One home PLMN (the MMEs home)
Up to 3 equivalent PLMN for the Home PLMN and up to 3 equivalent PLMN for
each Shared PLMN.
Up to 8 Shared PLMN (when the MME is shared by multiple operators)
The rest are roaming PLMN (PLMN ID does not match the MMEs home PLMN)
MME performs roaming checks when a UE attaches or performs a TAU:

Checks if the UE is a roamer (based on PLMN ID in the IMSI).
Checks whether there is a provisioned roaming agreement for the UEs PLMN.
What capabilities are allowed or restricted for this PLMN.
Obtains subscription data from the UEs home PLMN.

What capabilities are allowed or restricted for this roaming subscriber.
1 5 12
Up to 512 PLMN can be provisioned at the MME. Provisioning the home MME is required.
Optional: Up to 3 equivalent PLMN for the Home PLMN and up to 3 equivalent PLMN for each
Shared PLMN; up to 8 Shared PLMN; and up to 511 Other (roaming) PLMN can be provisioned.
An Equivalent PLMN is treated the same as the Home PLMN. The MME sends the UE a list of
Equivalent PLMNs in the Attach Accept message or the TAU Accept message, if they are provisioned
at the MME.
If the MME is shared by multiple operators, then each Shared PLMN will have its own set of roaming
tables and agreements tables associated with it.
The 9471 MME performs a series of roaming checks when a roaming UE attempts to attach and
perform tracking area update to the network. MME performs these checks by using provisioned
roaming agreement for the PLMN of the UE and subscription data of the UE obtained from the HSS
of the UEs home network. The MME roaming agreement table consists of set of capabilities allowed
and restricted in the MMEs home network (VPLMN).
Provisioning notes: The home PLMN, the roaming (Other) PLMNs, and shared PLMNs are
provisioned as parent PLMN objects at the 5620 SAM. Equivalent PLMNs are provisioned as child
objects of a parent PLMN.
The ueadmin_cli command outputs a summary of roaming UEs when the p <plmn> parameter is
used. The output consists of snapshot of list of PLMN with registered UE (active and idle) with the
MME.

Roaming agreements
If provisioned, these MME parameters override the UEs parameters:

Network Access Mode (Packet only, Packet and Circuit)
Access Restriction Data (UTRAN, GERAN and eUTRAN allowed or not)
Features allowed per PLMN (CSFB, CSFB DTR, IMS voice over PS, SMS)
Default QoS parameters for roaming UEs

May override UE's quality parameters
Operator determined Barring (ODB)

Is UE allowed to use APN?
May be provisioned at the MME or the HSS
Honor VPLMN Requests

Is UE allowed to select a PGW in the VPLMN?
1 5 13
The 9471 MME provides provisioning of various parameters in a roaming agreements table for
PLMNs whose subscribers are allowed to roam. These parameters are provisioned in the parent
roaming PLMN at the 5620 SAM. Provisioning conventions: In LM4.0, provision a "Roaming PLMN;"
in LM5.0 and later, provision an "Other PLMN" to provision a roaming PLMN.
If the following parameters are provisioned, the MME overrides the parameters in the UEs
subscription data with the provisioned parameters:
Network Access Mode: The values for the Network Access Mode are Packet and Circuit and
Packet Only. If this parameter is provisioned for a UE, the MME uses this for all the subscribers of
the PLMN, overriding the subscription data of a UE.
Access Restriction Data: Used for Inter-Radio Access Technology (IRAT) handover restrictions.
This parameter is also called Forbidden Radio Access Technologies (RAT). You can provision
UTRAN, GERAN, and/or eUTRAN Not Allowed.
Features allowed per PLMN:
2G and 3G Circuit Switch Fall Back (CSFB)
Circuit Switch Fall Back Dual Transceiver (DTR)
IMS Voice over Packet Switch
SMS (if SMS feature is supported)

Default QoS: Provide upper limits for quality parameters (may override UE's parameters). If
provisioned for a roaming PLMN, MME uses the provisioned values in setting up the radio bearers
for all the UEs from that PLMN. These quality parameters may override a UE's parameters.
Operator Determined Barring: Indicates whether a roaming UE is allowed or not allowed to use
a PGW for an Access Point Name (APN) in the visited PLMN, home PLMN, or both. ODB parameters
can also be provisioned at the HSS. MME indicates to the HSS in a message whether the MME will
handle ODB barring or whether the HSS should send barring indications.
The Honor VPLMN Requests flag indicates whether or not a UE is allowed to select a PGW in the
VPLMN. If unchecked, the UE must use the PGW in its home network (no local breakout).
Roaming restrictions list and equivalent PLMN
Roaming Restriction list

Contains forbidden TAI/LAI for serving and equivalent PLMN
Up to 4 PLMN ID in a roaming restriction list
1 Serving and up to 3 equivalent
Up to 20 forbidden TAI and LAI per serving or equivalent PLMN.
Who receives the roaming restrictions?

Equivalent PLMN sent to the UE and eNodeB.
Roaming Restriction list sent to eNodeB
1 5 14
Roaming restricted list

MME provides ability to provision a roaming restriction list (sometimes called the handover
restriction list) for each equivalent PLMN and for Serving PLMN (recall that the serving PLMN may
be the Home PLMN or a Shared PLMN). The list consists of forbidden Tracking Area Identities (TAI)
and/or Location Area Identities (LAI) for each PLMN.
The 9471 MME supports provisioning of up to 4 PLMN ID in a roaming restriction list (1 Serving and
up to 3 equivalent).
Forbidden TAI or LAI
For the Serving PLMN and each Equivalent PLMN, up to 20 forbidden TAI and LAI can be
provisioned.
Equivalent PLMN sent to UE
If provisioned, the equivalent PLMNs are provided to the UE in the Attach Accept message or in the
Tracking Area Update message.
The PLMNs in the list are normally neighboring PLMN with agreement of cell selection/reselection
and handovers. They are provisioned as child PLMN of a parent PLMN in the 5620 SAM.
Roaming restriction list and equivalent PLMN sent to eNodeB
The MME sends the roaming restriction list to the eNodeB, and the eNodeB uses this information to
determine a new cell for handover.
Equivalent PLMN list, forbidden TAIs and LAIs, and access restrictions are sent to an eNodeB in the
following S1AP messages:
INITIAL CONTEXT SETUP REQUEST
HANDOVER REQUEST to the new eNodeB
Optionally in DOWNLINK NAS TRANSPORT message if there are changes to the list
Notes: UE roaming TAI and LAI restriction profiles are provisioned at the 5620 SAM.
A Location Area in a UMTS network is the equivalent of a Tracking Area in the LTE network.
Roaming support HSS, SGW and PGW discovery
The MME selects the HSS, SGW, and PGW for a roamer as follows:
Uses the PLMN ID to obtain UE subscription data from HSS in UEs PLMN.
Always selects an SGW with an active S11 interface from its own network.
Selects an SGW supporting S11 and S5.
Selects a PGW in the MMEs PLMN (VPLMN) or the UEs home PLMN (HPLMN)
based on multiple conditions and provisioning:
Whether VPLMN requests are supported by the MME
Provisioned values at the HSS
1 5 15
The HSS IP addresses for roaming PLMN are provisioned in their respective PLMN provisioning
forms at the 5620 SAM.
S11 messages do not have a field to indicate to the SGW whether to use S5 or S8. It is assumed that all
the SGW support the S8 interface if roaming is supported. It is up to the SGW to pick the right interface
(S5 or S8) based on the PGW IP address.
PGW selection in the roaming case is not based on geography, but on various parameters
provisioned at the MME and the HSS, including:
Whether VPLMN requests are supported by the MME
Provisioned values at the HSS:
VPLMN dynamic address allowed or not allowed
Requested or default APN (home or visited) is allowed or barred
For example: VPLMN support is provisioned at the 5620 SAM. If support for a particular VPLMN
is allowed, and VPLMN dynamic address is allowed by the HSS, and there are no Operator
Determined Barring (ODB) attributes received from the HSS, the MME can select a PGW in its
own network. If support for a particular VPLMN is not allowed, the MME requests connection to
a PGW in the UEs PLMN if the UE is not barred from doing so by ODB attributes received from
the HSS (if it is barred, the request fails).
Note that the PGW discovery mechanism (static or dynamic) is controlled by the HSS APN
Configuration Attribute Value Pairs (AVPs). No MME provisioning fields are needed to control
whether or not DNS is used. The HSS provides these values, along with Operator Determined
Barring (ODB) attributes, to the MME in the UEs subscription data.
A complete table of conditions identifying how the MME selects a PGW for a roaming UE is
provided in the 9471 MME Technical Description (418-111-200).
Knowledge check: Roaming

The 9471 MME determines whether a UE is a roamer based on the PLMN
ID provided as part of the IMSI.
True
False
A, true. A roaming UE is one whose PLMN ID in the IMSI does not match the MMEs
Serving PLMN ID.
1 5 16

Definition of a roaming UE
Roaming architectures:
Home routed
Local breakout
How the 9471 MME supports roamers:

Roaming PLMNs
Roaming checks and restrictions
How the MME selects the HSS, SGW, and PGW for a roamer
1 5 17

Define roaming UE
Identify two roaming architectures and how they are supported by the 9471
MME: home-routed and local-break-out
1 5 18

References
The following customer documents provide information about the
9471 MME roaming functions:
9471 MME Technical
Description
Describes the 9471 MME roaming features and rules.
(418-111-200)
5620 SAM LTE EPC User

Guide
Provides procedures to provision roaming

agreements and restrictions.
(3HE 06981)

1 5 19

End of module
9471 MME Support for Roaming
1 5 20

Section 1
9471 MME Overview
Module 6
Emergency, Warning, and Multimedia Broadcast Services

Technical Overview

Blank page
162
9471 MME Overview Emergency, Warning, and Multimedia Broadcast
Document History
Edition
Date
Author
Remarks
01
YYYY-MM-DD
First edition

Module objectives
IMS Emergency Services

Location Based Services in support of IMS Emergency Services
Warning Message Delivery
Multimedia Broadcast/Multicast Service
163
This module describes how the 9471 MME supports the following services that were introduced in
the EPS in LTE 3GPP Release 9: IMS Emergency Service, Location-Based Services that support IMS
Emergency Services, Warning Message Delivery, and Multimedia Broadcast Services.

Table of Contents
1 IMS Emergency Services
2 Location-Based Services
3 Warning Message Delivery Service
4 Multimedia Broadcast Service
165

Page
7
16
26
32
1 IMS Emergency Services
167
This topic describes how the 9471 MME supports IP Multimedia Subsystem (IMS) Emergency
Services.

IMS Emergency Service overview
The 9471 MME includes functionality to support IMS Emergency services:

Emergency bearer services support IMS emergency sessions.
Allows service providers to meet regulatory requirements.
Emergency bearer services are provided to:

Normal attached UEs who dial an emergency number.
Limited service UEs, depending on local regulations and operator policy.
Network requirements:
Release 9 LTE UE that is IMS voice capable.
UE, eNodeB, SGW, and PGW must comply with the Emergency Bearer Services
requirements.
Pre-release 9 UEs will use CS Fallback for emergency calls.
168
The 9471 MME Emergency Service functionality provides the emergency bearer services to support
IMS emergency sessions. The 9471 MME Emergency Service functionality allows service providers
to meet regulatory obligations for Emergency Services support.
If emergency bearer services are provided to a normal attached UE, an emergency dedicated bearer
can be set up with a piggybacked dedicated bearer activation request message or a nonpiggybacked dedicated bearer activation request message in an Emergency PDN Connectivity
Request Procedure.
(Recall that piggybacking is an option that allows the messages for the dedicated bearer activation
to be combined with the default bearer activation at Attach or UE requested PDN connectivity
procedures.)
The MME may allow or reject an emergency attach request for UEs in limited-service state based on
local regulations and operators policy. If emergency bearer services are provided to a limitedservice UE, an emergency dedicated bearer can be set up with a piggybacked dedicated bearer
activation request message or a non-piggybacked dedicated bearer activation request message in
an Emergency Attach Procedure. (UE types are described on the next slide.)
Limited service state: Receiving emergency services in limited service state does not require a
subscription.
Default emergency numbers are configured in the UE. Examples: 911 (U.S.); 112 (Europe, India,
and other countries); 000 (Australia). When a subscriber dials an emergency number, the UE
recognizes it and begins the emergency call procedure. The optional number list provisioned at the
MME can be sent to the UE and allows it to recognize additional emergency numbers.
This feature requires a Release 9 LTE UE that is IMS voice capable, and that the UE, the eNodeB,
the SGW, and the PGW comply with the Emergency Bearer Services requirements stated in the
relevant 3GPP standards.
Pre-release 9 UEs are expected to use Circuit Switched (CS) Fallback for emergency calls.

Emergency UE types supported
All UEs
(default)
Valid UE
only
Valid,
Restricted
location
Valid,
Authentication
failed
169
TAI emergency
enabled
The MME supports emergency bearers for the following UE types based on provisioned settings:
Valid
UEs only
No limited service state UEs.
Authenticated
UEs
All
UEs that have a valid IMSI but are in a restricted location.
that have an IMSI, but authentication fails
UEs allowed
Includes IMSI that cannot be authenticated and UEs with only an IMEI.
This is the default.
UEs
with all TAIs enabled with emergency services
UE types for IMS Emergency Services are provisioned in the Service Behavior field of the Emergency
Profile form.
For UEs with all TAIs enabled with emergency services: The MME indicates to the UE that
emergency services are supported only if emergency services are enabled for all the TAIs in the TAI
list sent to the UE. UE request for emergency support is only allowed if requested from TAI with
both Emergency Services and IMS Voice support enabled.
Provisioning is described in the 5620 SAM LTE EPC User Guide.

IMS Emergency Service example
GMLC/LRF
SLh
2. eNodeB sets
RRC to
Emergency.
1. Emergency eNodeB
Attach.
SLg
MME
S1-MME
3. MME sets up
emergency
bearers;
selects PGW.
S6a
S11
HSS
SLs
S1-Ui
E-SMLC
4. IMS
handles
5. IMS
emergency
routes
registration
info to
M2 PSAP.
PGW .
SGW
S5i
SGi
6. User plane
for voice
established.
IMS
Le
PSAP
7. PSAP may
retrieve location
info from GMLC.
The GMLC and E-SMLC functions are used if Emergency Location Services
(LCS) are used to assist subscribers who place emergency calls.
1 6 10
1. UE detects emergency number is dialed and initiates Emergency Attach. (Emergency numbers
are stored in the UE (i.e., 911 default). The network may optionally download a list of additional
emergency numbers to the UE so the UE can detect if additional emergency numbers are dialed.
Up to 8 emergency numbers can be provisioned at the MME for this purpose).
2. eNodeB sets the Radio Resource Control (RRC) establishment cause to Emergency for:
Emergency Attach (Attach request with Attach type to EPS Emergency.
Emergency PDN connectivity for normally attached UEs (PDN connectivity request set to
Emergency).
Service Request to set up Emergency call.

3. MME recognizes that this is a priority emergency call.
MME uses Emergency configuration data to establish emergency bearer services and select
the PGW associated with the Emergency APN.
The Emergency APN, Emergency QoS profile, and Emergency APN-AMBR (QoS parameters
that are applied to aggregated set of EPS Bearers) are previously provisioned on the MME.
Separate Mobile reachable and T3412 timers for emergency calls may be provisioned in the
Emergency profile.
The MME records the existence of an active Emergency call in the UE Context.
If the UE becomes IDLE, the MME starts a special emergency reachable timer (provisioned
with a similar value to the UEs periodic TAU timer).
4. The IMS handles emergency IMS registration.
5. The Emergency Call State Control Function (E-CSCF) in the IMS routes UE location information
to a Public Safety Answering Point (PSAP).
6. A user plane is established for voice.
PSAP may inquire UE location information from Gateway Mobile Location Center (GMLC) and
Location Retrieval Function (LRF) to dispatch emergency services to the correct address.
Call-back from a PSAP is supported for UEs that are not operating in the limited service state, but
priority paging for Emergency Bearer Services is not supported.
PGW selection during emergency calls

Emergency
PGW
MME selects the PGW provisioned for Emergency Services.

First choice:
Use the static IP address if provisioned.
Second choice:
Use the PGW FQDN if provisioned.
Third choice:
Use S-NAPTR procedure
Emergency PGW is always located in the serving MME's PLMN (local).
1 6 11
The PGW IPv4 address, IPv6 address and/or the PGW FQDN may be provisioned at the MME in the
Emergency Profile provisioning form.
If the PGW FQDN is provisioned, the PGW FDQN is used to query DNS. If DNS query is successful,
the received IP is used. If DNS query fails, the PGW IP provisioned at the MME is used.
If the first PGW fails to set up an emergency session, two additional PGWs may be selected. The
order of PGW selection is as follows:
First
attempt: MME always uses the static IP address if provisioned in the Emergency Profile.
Second
attempt: MME uses the PGW FQDN if provisioned in the emergency profile.
Third
and final attempt: MME uses the S-NAPTR procedure on the emergency APN if
provisioned in the emergency profile. MME selects a PGW with a FQDN different from the failed
FQDN.
In a roaming architecture, the PGW provisioned on the MME for Emergency Services is always
located in the visited PLMN.
In networks that support handover between eUTRAN and HRPD, the MME selects a PGW that is
configured in the MME Emergency Configuration Data.
The PGW selection does not depend on subscriber information in the HSS since emergency call
support is a local.

Handover during emergency calls

UE restrictions ignored.
Call continuity handled by SRVCC.
Emergency bearers not transferred to SGSN.
MME
MME
eNB
eNB
TA1
1 6 12
TA2
The
source eUTRAN and source MME ignore any UE-related restrictions during handover
evaluation when emergency bearers are active.
Once
an IMS Emergency call is in progress, emergency call continuity is supported using Single
Radio Voice Call Continuity (SRVCC) where supported by network and the UE.
Emergency
network).
bearers are not transferred to the SGSN in case of a Routing Area Update (UMTS
SRVCC: Single Radio Voice Call Continuity (SRVCC) is an LTE functionality that provides the ability
to transition a voice call from the VoIP/IMS packet domain to the circuit domain (the ability to
transition from the circuit domain to the packet domain is not currently addressed in LTE
standards).

IMS Emergency Service provisioning overview
MME must be provisioned with Emergency configuration data, including:
Emergency APN and PGW.

Preemption rules, QoS for emergency calls, timers, and UE types allowed.
Optional Emergency numbers
The feature is activated in the PLMN provisioning form
The following may be provisioned separately for emergency-attached UEs:

T3412 timer (Idle-mode timer)
Mobile Reachable timer
Complete provisioning is described in the 5620 SAM LTE Users Guide.

1 6 13
Emergency data is provisioned in the MME Emergency Profile provisioning form. If emergency
timers are not provisioned, then the provisioned data in the regular Timers form is used.
The feature is activated by entering the provisioned Emergency Profile ID in the PLMN provisioning
form. If the MME is not provisioned with Emergency configuration data and a regular or limited
service UE attempts to make an IMS Emergency call, the Emergency call attempt will fail since the
MME does not support IMS Emergency Service.

Knowledge check: IMS Emergency Service

Is the following statement true or false:
By default, 9471 MME supports Emergency Attach for any UE, regardless of
the UEs subscription.
True
False
True. The default behavior is to accept all UEs, including those with only an IMEI (no
IMSI) and no authentication.
Operators may provision the MME to limit the type of UEs accepted, if local regulations
permit:
Only valid UEs with subscription and in a non-restricted location
Valid UEs in a restricted location
UEs that have an IMSI but that cannot be authenticated
1 6 14

Knowledge check: IMS Emergency Service

When a UE initiates an Emergency Attach, the MME selects a PGW
_________________________________________________________.
A. based on subscriber information provided by the HSS during Emergency
Attach
B. based on the Emergency PGW information provisioned in the MME
C. based on the UEs home PLMN
B - based on the Emergency PGW information provisioned in the MME.
1 6 15

2 Location-Based Services
1 6 16
This topic describes how the 9471 MME supports Location-Based Services (LBS) in support of IMS
Emergency Services.

Location Based Service overview
Two common ways to support the location of mobiles in an EPC network:

Open Mobile Alliance Secure User Plane Location (OMA SUPL)
OMA SUPL does not involve the MME and is beyond the scope of this training
Control plane Location Services (LCS)

Supported by the 9471 MME
Categories of Location Services defined in TS 23.271:

Commercial or Value Added LCS (example: restaurant directory in vicinity)
Internal LCS (Access Network internal operations, for example, locationassisted handover)
Lawful Intercept LCS
Emergency LCS (part of a service provided to assist subscribers who place
emergency calls.)
9471 MME supports
only the Emergency
LCS category
1 6 17
NOTE: Because the 9471 MME supports only Emergency LCS, many of the concepts outlined in TS
23.271 and other standards are not implemented because they are not required to implement
Emergency LCS.
OMA SUPL
The Open Mobile Alliance (OMA) is a standards organization that develops standards for mobile
phones. Secure User Plane Location (SUPL) an IP-based service for assisted satellite Global
Positioning System (GPS) on mobile phones.
Details about OMA SUPL are found on the Open Mobile Alliance web page:
http://www.openmobilealliance.org/Technical/release_program/mls_v1_2.aspx

MME support for Location Based Service overview
The 9471 MME supports control plane LCS in the EPS.

Control plane LCS:
Provides capabilities to locate target UEs.
Makes location information available to Location Based Services (LBS).
The 9471 MME supports Emergency Location Based Service:

Reports location of UE caller to the emergency service provider (via a GMLC) for
IMS emergency calls.
If available, positioning method used to obtain the location estimate is provided.
Service may be mandatory in some jurisdictions.
1 6 18
The 9471 MME supports functions required for the control plane Location Services (LCS) in the
Evolved Packet System (EPS) to support the Emergency LCS location services category as defined in
TS 23.271.
LCS vs LBS
Location Services (LCS) in a wireless network deals with the capabilities to locate target UEs,
triggered by either external or internal requests. LCS makes the location information available to
Location Based Services (LBS). LBS Services are information services that makes use of the
geographic position of a mobile device.
LCS category supported
The 9471 MME supports only the Emergency LCS Location Services category. This includes location
reporting of UEs for IMS emergency calls. Emergency LCS is used to assist subscribers who place
emergency calls. The location of the UE caller and, if available, the positioning method used to
obtain the location estimate is provided to the emergency service provider. This service may be
mandatory in some jurisdictions. In the United States, for example, this service is mandated for all
mobile voice subscribers.
GMLC
The gateway Mobile Location Center (GMLC) proxies location requests and responses from location
clients. GMLC is described in the next slide.

Location Services architecture

The 9471 MME supports the Immediate Location Request (LR) type:
Mobile Terminated LR (MT-LR) - on-demand request from GMLC
Network Initiated LR (NI-LR) autonomous request based on MME provisioning
The MME uses LCS in conjunction with IMS Emergency Services.

GMLC
SLg
MME
S6a
S1-MME
eNodeB
Interfaces supported by MME for

LBS:
SLg
SLs
S1-MME has been modified to
support LBS and emergency
services
SLh
LCS
client
HSS
SLs
E-SMLC
1 6 19
The 9471 MME supports the Immediate Location Request (LR) type, which includes Mobile
Terminated LR (MT-LR) and Network Initiated LR (NI-LR). Mobile Originated LR (MO-LR) is not
supported since it is not needed for Emergency LCS.
LCS architecture includes the following components:
GMLC: The Gateway Mobile Location Center (GMLC) supports verification of identity of a client and
clients subscription data, and forwards validated requests to the MME over the SLg interface to
obtain UE positioning data. The GMLC obtains the address of the serving MME from the HSS. The
GMLC consists of location service components and bearers needed to serve the LCS clients.
The GMLC receives UE positioning requests from an LCS external client, which may reside in the UE,
a Public Safety Answering Point (PSAP), or other entity. LCS Clients subscribe to LCS to obtain
location information.
9471 MME: The MME is responsible for managing positioning requests of Location Services (LCS).
Additional details about MME support are on the next slide.
HSS: HSS contains LCS subscription data and routing information.
E-SMLC: The EPS Serving Location Mobile Center (E-SMLC) manages the coordination and
scheduling of resources required for the location of a UE that is attached to eUTRAN. It calculates
the final location and velocity estimate of the UE. The E-SMLC interacts with the UE and the
eUTRAN in order to exchange location information. This interaction is transparent to the MME.
eNodeB: The serving eNodeB communicates with the E-SMLC to receive positioning assistance
data and measurement instructions, and to send positioning measurements from the UE to the ESMLC.

NI-LR for emergency calls example
LCS
client
GMLC
1. MME
receives
Emergency
Request from
UE.
4. MME sends
information
to GMLC.
SLg
MME
S1-MME
2. MME sends
Location
Request to
the ESMLC.
eNodeB
5. MME saves
location data in
UE context
SLs
E-SMLC
1 6 20
3. E-SMLC
determines
UE location
and sends it
to MME.
Network Induced Location Request (NI-LR) for emergency calls

1. MME receives an Emergency Attach Request or Emergency PDN Connectivity Request.
2. MME selects an E-SMLC based on the last visited TAI of the UE. MME sends Location Request to
the E-SMLC, using provisioned data to specify the location accuracy to the E-SMLC. The
Location Request includes the type of location information requested, the requested QoS, and
identity of serving cell.
3. E-SMLC communicates with UE and eNodeB via the MME (transparent to the MME) to obtain
location information, then calculates UE position and velocity and sends it to the MME.
4. MME sends a Location-Report-Request (LRR) Diameter command to a designated GMLC
(provisioned) for emergency calls. The message includes the IMEI of the UE, and IMSI if
available, and location information received from the E-SMLC. If successful it is responded to
with a Location-Report-Answer (LRA) command.
The Location Retrieval Function (LRF) associated with the GMLC uses the information to assist
routing of the emergency session to an emergency center.
5. MME saves location data in UE context.
Note that other than NI-LR, the MME does not autonomously track the UE as it moves through the
network.

MT-LR for emergency calls example

1. LCS client
sends request
to GMLC.
2. GMLC
verifies LCS
client.
LCS
client
GMLC
4. GMLC sends
request to
MME.
5. MME
performs
tasks.
S1-MME
eNodeB
1 6 21
SLh
9. MME sends
position and
velocity to GMLC.
3. GMLC gets
MME IP
from HSS.
MME
S6a
HSS
6. MME sends
location
request to
E-SMLC.
7. E-SMLC communicates with

UE and eNodeB via the MME
to obtain location
information, then calculates
UE position and velocity.
SLg
8. E-SMLC sends
position and
velocity to MME.
SLs
E-SMLC
Mobile Terminated Location Request (MT-LR) for emergency calls

1. External LCS client sends a request for a UE location to GMLC.
2. GMLC verifies LCS client subscription data to verify LCS client is allowed to obtain UE position
data.
3. GMLC obtains the address of the serving MME from the HSS.
4. GMLC sends MME the location request. Diameter command: "Provide-Location-Request" (PLR).
5. MME performs the following tasks:
Verifies the client is emergency services.
If location request type is "CURRENT_OR_LAST_KNOWN_LOCATION", the last known location

is immediately returned to the GMLC.
If the location request type is "CURRENT_LOCATION", and the UE is in IDLE state and can be
paged, MME pages the UE. If the UE does not respond, the MME may respond to the GMLC
with the UEs last known location (if it is available and the GMLC has requested that option).
6. The MME selects an E-SMLC based on the last visited TAI, and MME sends the location request
to the selected E-SMLC. If there is more than one E-SMLC associated with the TAI, the MME
uses load-balancing or primary/secondary preference to select an E-SMLC (the method is
configurable).
7. E-SMLC initiates UE positioning. The positioning method is based on the position accuracy
requested. E-SMLC uses the LPP and LPPa protocol to exchange location information with the
UE and eNodeB respectively. The interaction is transparent to the MME.
8. E-SMLC determines the UE location and sends the results to the MME.
9. MME sends the location data to the GMLC. Diameter command: Provide-Location-Answer
(PLA). The GMLC sends the data to the requesting client.

GMLC
LBS interfaces: SLs
SLh
eNodeB
SLg
S1-MME
The SLs interface supports communication

between the 9471 MME and the E-SMLC
to obtain a UE's position.
Supports of Emergency Location Services
(LCS).
HEARTBEAT
HEARTBEAT-ACK
MME
S6a
HSS
SLs
E-SMLC
HEARTBEAT can be
sent by E-SMLC or
MME.
Protocols:
LCS-AP
SCTP over IPv4 or IPv6 for transport
Single-homing or Multi-homing is
supported
LCS-AP
LCS-AP
SCTP
SCTP
IP
IP
L2
L2
L1
L1
MME
1 6 22
SLs
E-SMLC
The SLs interface supports communication between the 9471 MME and the EPC Serving Mobile
Location Center (E-SMLC ) to obtain a UE's position. The E-SMLC interacts with the UE in order to
exchange location information applicable to UE-assisted and UE-based position methods and
interacts with the eUTRAN to exchange location information applicable to network-assisted and
network-based position methods. E-SMLC uses LTE Positioning Protocol (LPP and LPPa) to UE and
eNodeB respectively for UE positioning.
Downlink Generic NAS Transport messages and Uplink Generic NAS Transport messages are used to
transport transparent LPP messages between a UE and the E-SMLC.
LCS-AP
The Location Services Application Protocol (LCS-AP) is used between the MME and the E_SMLC.
LCS-AP messages are carried over SCTP/IP. The MME establishes semi-permanent connections with
a set of E-SMLCs at the initialization time.
An MME serving area may consist of several E-SMLCs, which are associated with tracking areas. ESMLC selection is based upon the last seen Tracking Area Identity (TAI).

GMLC
SLg
eNodeB
HEARTBEAT
HEARTBEAT-ACK
SLg
MME
S1-MME
The SLg interface supports

communication between the 9471 MME
and the GMLC.
HEARTBEAT can be
sent by GMLC or
MME.
SLh
S6a
HSS
SLs
E-SMLC
Transports positioning requests and

responses for Location Services between
GMLC and MME.
Protocols:
Diameter EPC LCS Protocol (ELP)
supported
Diameter (ELP)
Diameter (ELP)
SCTP
SCTP
IP
IP
L2
L2
L1
L1
MME
1 6 23
SLg
GMLC
The SLg interface supports communication between the 9471 MME and the Gateway Mobile
Location Center (GMLC) to support transport positioning requests and responses for Location
Services (LCS). The MME acts as client to the GMLC. The GMLC supports verification of identity of a
client and the clients subscription data.
The GMLC forwards a validated request to MME over the SLg interface to obtain UE positioning
data.
The EPC LCS defines procedures and coding of messages between GMLC and MME. Semipermanent SCTP associations are set up between the GMLC and MME. The MME establishes SCTP
associations with provisioned GMLCs at MME initialization time (MME allows connections from a list
of provisioned GMLC). Note that the SLg interface is not allowed between a GMLC in one network
and an MME in a different network.
Diameter ELP
The EPC LCS Protocol (ELP) defines procedures and coding of messages between GMLC and MME.
The protocol is specified in 3GPP TS 29.172 and call flows are specified in 3GPP TS 23.271. The ELP
is a vendor-specific Diameter application. It reuses the basic mechanisms defined by the Diameter
base protocol and it defines additional commands to support SLg specific procedures.

Location Services provisioning overview
LCS occurs only if the following are configured:

Interfaces to the GMLC and E-SMLC must be set up.
One or two E-SMLC must be associated with each TAI.
LCS parameters must be provisioned
Optional subscriber location report (SLR) provisioning for network-initiated

location request:
Obtain positioning estimate from E-SMLC and send in SLR to GMLC
Do not obtain positioning estimate, but send SLR to GMLC
Do not obtain positioning estimate or send SLR to GMLC
1 6 24
SLR options are provisioned on the Emergency Profile form.

LCS parameters that must be provisioned include:
The "Activate LCS" global parameter must be set to "Yes*.
"Initiate LCS Emergency" must be enabled on the PLMN form.
"Initiate LCS Request" must be enabled on the Emergency Profile that is associated with
the PLMN that is handling the call.
*Note that if the "Activate LCS" global parameter is set to "No", none of the SLs or SLg links will be
visible to the OA&M interface.
Complete provisioning is described in the 5620 SAM LTE EPC User Guide.
Growth notes:
When growing LCS, it is important to follow all of the steps as indicated in the procedures. You will
NOT see SLs or SLg link states in OA&M until you reach the point in the procedure where "Activate
LCS" is set to "Yes".
Likewise if LCS is provisioned and the "Activate LCS" global parameter is set to "No", all SLg and SLs
links will be taken down. When you change it back to "Yes" they all come back up.

Knowledge check: 9471 MME support for LBS

Which component provides the MME with UE positioning information during
GMLC
an emergency call?
A.
B.
C.
D.
eNodeB
E-SMLC
GMLC
HSS
B: E-SMLC
eNodeB
MME
HSS
E-SMLC
Over which interface is this information provided?

A.
B.
C.
D.
SLs
S1-MME
SLg
S6a
A: SLs
1 6 25

3 Warning Message Delivery Service
1 6 26
This topic describes how the 9471 MME supports Warning Message Delivery Service.

Warning Message Delivery Service overview
The 9471 MME Warning Message Delivery function supports a

Commercial Mobile Alert System (CMAS):
Allows warning messages to be sent to a UE in a particular area.
Warning messages are sent from a Cell Broadcasting Center (CBC).
The MME forwards these messages to the eNodeBs.
Network requirements:
CMAS support on the eNodeB and Cell Broadcast Center is required.
The CMAS service is applicable to mobiles that support Warning Message
Delivery.
1 6 27
The 9471 MME Warning Message Delivery function supports a Commercial Mobile Alert System
(CMAS) and allows warning messages to be sent to a UE in a particular area. The 9471 MME
receives warning messages from a Cell Broadcasting Center (CBC) using the SBc interface, and the
MME forwards these messages to the eNodeBs.
Network requirements
CMAS support on the eNodeB and Cell Broadcast Center is required. The CMAS service is applicable
to mobiles that support Warning Message Delivery.
Notes: The public warning system is intended to alert the general public of public threats such as flu
pandemics, toxic spills, terrorist threats, and natural disasters from tsunamis, earthquakes, or
wildfires. Recipients do not have to sign up to receive alerts on the SIB12 cell broadcast channel,
but they can opt-out by turning off the broadcast channel on their handsets. Whereas SMS
messages are sent point-to-point, Cell Broadcast messages are sent point-to-area. Cell Broadcast is
not as affected by traffic load and it may be usable during a disaster when load spikes occur.

Warning Delivery Message example
4. eNodeBs
broadcast
the message.
FLOOD
WARNING
3. MME sends
WriteReplace
Warning
Request to
eNodeBs in
TAI list.
2. CBC sends
MME WriteReplace
Warning
Request.
1. CBC receives
warning
alert.
MME
S1-MME
CBC
FLOOD
WARNING
SBc
FLOOD
WARNING
eNodeB
Interfaces introduced to support

Warning Delivery Messages:
SBc
1 6 28
1. CBC receives notice of warning alert to be sent to a regional area.

2. CBC sends the 9471 MME (or pool of MMEs) a Write-Replace Warning Request over the SBc
interface. The request includes a TAI list, the warning message, and number of times to repeat
the broadcast.
3. The MME determines which eNodeBs are within the TAI list and sends S1 Write-Replace
Warning Request messages to each of them.
4. The eNodeBs send the broadcast message to UEs in serving area.
The MME verifies receipt and validation of the Request at the eNodeBs it does not depend
on a positive response from UEs.
Broadcast continues at repetition interval until:

1. Number of Broadcast Requested is achieved
2. Broadcast is cancelled by the CBC (using Stop Warning request)
3. Broadcast is replaced with different content by the CBC (using another Write-Replace
Warning Request ).

SBc
eNodeB
CBC
MME
SBc
S1-MME
The SBc interface supports

and the CBC.
HEARTBEAT
HEARTBEAT-ACK
HEARTBEAT can be
sent by CBC or
MME.
Transports messages associated with

Warning Message Delivery function.
Protocols:
SBc-AP
Single-homing or Multi-homing between
MME and CBC is supported
Multiple SCTP streams are supported
SBc-AP
SBc-AP
SCTP
SCTP
IP
IP
L2
L2
L1
L1
MME
1 6 29
SBc
CBC
The SBc interface is the reference point between the MME and the Cell Broadcast Center (CBC) and
is used to transport messages associated with Warning Message Delivery function. These messages
consist of text that warn of safety events, which may impact a geographical region. The CBC can
initiate the SCTP association toward the MME (and with the eNodeB). Messages are forwarded to
the appropriate eNodeB(s) and then broadcasted using a paging channel. The eNodeB(s) provides
state management for the warning messages for broadcast repetition interval, broadcast duration,
message replacement and cancellation.
The eNodeB(s) also manage the case where multiple copies of Warning Message Requests are
received for the same warning message (for example, from multiple MMEs in the case of MME
pooling).
SBc-AP
The SBc Application Protocol (AP) interface is a logical interface between the MME and the CBC. SBc
is an SCTP-based interface that supports multi-homing, IPv4, IPv6, or IPv4 and IPv6 addressing.
The SBc-AP is used between the MME and the Cell Broadcast Center. Messages are carried over
SCTP/IP. The CBC establishes semi-permanent connections with the MME at initialization time. MME
is the server and the CBC clients connect to it. The CBC IP addresses do not need to be configured
at the MME.

Warning Message Delivery Service provisioning overview

MME must be provisioned for the Warning Message Delivery function:
The SBc interface to the CBC must be provisioned on the MME.
The function uses the existing TAI-to-eNodeB mapping that is already contained
on the MME for normal call processing.

1 6 30
Control and provisioning

Provisioning includes setting up the SBc interface to the CBC.
This functionality also uses the TAI to eNodeB mapping that is already contained on the MME for
normal call processing.

Knowledge check: Warning Delivery Message

The 9471 MME receives Write-Replace Warning Requests over which
interface?
A.
B.
C.
D.
E.
SLs
SLg
SBc
SBw
S1
C: SBc interface
1 6 31

4 Multimedia Broadcast Service
1 6 32
This topic describes how the 9471 MME supports Multimedia Broadcast/Multicast Service (MBMS).

Multimedia Broadcast/Multicast Service overview
MBMS is a broadcast service in which data is transmitted from a single

source entity to multiple recipients.
The 9471 MME performs the following functions to enable MBMS support:
Supports session control of MBMS bearers to the eUTRAN.
Reliable delivery of Session Start/Session Stop/Session Update messages.
Transmits session control messages toward Multicast Control Entity (MCE)

function in the eUTRAN using the M3 interface.
Receives MBMS service control messages, which include the IP Multicast
address for MBMS data reception, from MBMS gateway function over the Sm
interface.
Note: In the current Alcatel-Lucent architecture, the MCE function is in the eNodeBs, but this
may not always be the case. Non-Alcatel-Lucent MCEs may not be in the eNodeBs.
1 6 33
Multimedia Broadcast/Multicast Service (MBMS or eMBMS) is a broadcast service in which data is

transmitted from a single source entity to multiple recipients, thus allowing network resources to be
shared. Target applications include mobile TV and radio broadcasting, as well as file delivery and
emergency alerts (note: multicast is not applicable to the eUTRAN).

Multimedia Broadcast/Multicast Service example
5. MME updates
Bearer
Context.
4. MME sends
Session Start 3. MME builds 2. MBMS GW
1. MBMS GW
Request to
Bearer
sends MME
receives
each MCE
Context.
Session Start
notice of
with active
Request.
broadcast
SCTP
from BM-SC.
MME
association.
M3 (to MCE)
Sm
MBMS GW
S1-MME
eNodeB/
MCE
Content
Provider
BM-SC
M1 bearer path for broadcast
6. MBMS session starts;

MCE joins the IP multicast group.
Interfaces introduced to support Multimedia

Broadcast/Multicast service:
Sm
M3
M1
1 6 34
Three main events that can happen within an MBMS session: Session Start, Session Update, and
Session Stop. These events are triggered by an Sm message from the MBMS gateway and result
in the MME distributing messages out to the MCE. In Alcatel-Lucent architecture, the MCE
function is located in the eNodeB.
Session start example:
1. The MBMS GW receives notice of a broadcast from the Broadcast-Multicast Service Center (BM-
SC). The message includes the length of the broadcast and the broadcast service area.
2. The MBMS sends a Session Start Request to the MME. The message includes the length of the
broadcast and the broadcast service area.
3. The MME builds an MBMS Bearer Context with the attributes from the Session Start Request.
4. The MME forwards an M3AP (M3 application protocol message) MBMS Session Start Request to
each MCE with which it has an active SCTP association.
MME verifies receipt and validation of Request at the MCE but does not depend on positive
response from UE.
5. MME updates the MBMS Bearer Context with successful MCE responders data.
6. The MBMS session starts.
MCE joins the IP multicast group for user plane delivery.
Broadcast is over the M1 interface to the MBMS gateway.
A UE can join or leave at any time during the broadcast, but must have a subscription to join.
A UE can subscribe at any time. Subscriptions are stored in the BM-SC.

Sm
MCE/eNodeB
MME
M3
S1-MME
The Sm interface supports

and the MBMS Gateway.
MBMS GW
Sm
Echo Request
Echo response
Echo Request can
be sent by MBMS
GW or MME.
Transports MBMS service control

messages
Protocols:
GTP-C
Tunnels messages between MME and
MBMS gateway
Transfers signaling messages.
GTP-C
GTP-C
UDP
UDP
IP
IP
L2
L2
L1
L1
MME
1 6 35
Sm
GTPv2based
interface
MBMS GW
The Sm interface is the reference point between the Multimedia Broadcast/Multicast Service
(MBMS) Gateway and the 9471 MME.
Multimedia Broadcast/Multicast Service (MBMS) is a broadcast service in which data is transmitted
from a single source entity to multiple recipients. The MME provides a distribution of control
messages associated with Broadcast Session Start/Update/Stop using the Sm (GTPv2) interface to
the MBMS Gateway and the M3 (SCTP) interface to the Multicast Control Entity (MCE). The MME
receives MBMS service control messages for MBMS data reception from MBMS GW function over the
Sm interface.
The Sm messages between an MBMS GW and the MME are transported over GTPv2. The Sm
interface supports signaling/control functions, including Session Management, such as starting,
stopping, and updating MBMS sessions. GTPv2 is defined in 3GPP TS 29.774.

M3
MCE/eNodeB
MME
M3 (to MCE)
The M3 interface supports

and the MCE.
MME transmits session control messages
toward the MCEs.
MBMS GW
Sm
S1-MME
HEARTBEAT
HEARTBEAT-ACK
HEARTBEAT can be
sent by MCE or
MME.
Protocols:
M3-AP
supported
M3-AP
M3-AP
SCTP
SCTP
IP
IP
L2
L2
L1
L1
MME
1 6 36
M3
MCE
The M3 interface is the reference point between the Multicast Control Entity (MCE) and the 9471
MME.
Multimedia Broadcast/Multicast Service (MBMS) is a broadcast service in which data is transmitted
from a single source entity to multiple recipients. The MME provides a distribution of control
messages associated with Broadcast Session Start/Update/Stop using the Sm (GTPv2) interface to
the MBMS Gateway and the M3 (SCTP) interface to the Multicast Control Entity (MCE). The MME
transmits session control messages towards the MCEs using the M3 interface.
M3-AP
The M3-AP messages between an MCE and the 9471 MME are transported over SCTP/IP. The M3
Application Protocol (M3-AP) supports the signaling control functions such as session management,
reset, and error indication.
The MCE initializes the M3 SCTP association with the MME. The MME sends MBMS M3AP messages
to only those MCE that have initialized an M3 SCTP association.

MBMS provisioning overview

MME must be provisioned with MBMS configuration data:
The feature is activated from the MME PLMN provisioning form.
Sm interface to the MBMS gateway must be set up.
M3 interface to the MCE function in eUTRAN must be set up.

1 6 37
The MBMS feature is activated on the MME from the PLMN provisioning form. The Sm interface to
the MBMS Gateway and the M3 interface to the Multicast Control Entity (MCE) must be provisioned.

Knowledge check: Multimedia Broadcast Service

Which component in the diagram supports session control of the
MBMS bearers to the eUTRAN, including delivery of Session
Start/Session Stop/Session Update messages?
MME
M3
Sm
Content
Provider
MBMS GW
S1-MME
BM-SC
M3 bearer path for broadcast
eNodeB/
MCE
The MME supports session control of the MBMS bearers to the eUTRAN access, including
reliable delivery of Session Start/Session Stop/Session Update messages.
1 6 38

This module covered the 9471 MME functions and interfaces required
to support:

Location Base Services that support IMS Emergency Services
1 6 39

Describe the following LTE EPS services supported by the MME:
Location Based Services in support of IMS Emergency Services
1 6 40

References
The following customer document provides information about the
9471 MME emergency and location functions in the LTE network:
9471 MME Technical Description Describes the 9471 MME features, functions, and
interfaces.
(418-111-200)
The following customer documents explain how to provision the

features described in this module:
5620 SAM LTE EPC User Guide
Describes provisioning from the 5620 SAM.
(3HE06503)

1 6 41

End of module
Emergency, Warning, and Multimedia Broadcast
1 6 42

Section 1
9471 MME Overview
Module 7
9471 MME Interworking with CDMA Networks

Technical Overview

Blank page
172
9471 MME Overview 9471 MME Interworking with CDMA Networks
Document History
Edition
Date
Author
Remarks
01
YYYY-MM-DD
First edition

Module objectives
Describe the procedures performed by the 9471 MME to support LTE-to-eHRPD
mobility
173
This module describes how the 9471 MME interworks with CDMA 1x Radio Transmission
Technologies (1xRTT) to allow UEs to travel between eUTRAN (LTE) and eHRPD-RAN (CDMA)
networks. It is assumed that users are already familiar with the 3GPP2 CDMA networks.

Table of Contents
1 Data mobility
2 Voice mobility
Page
7
15
175

1 Data mobility
177
This topic provides an overview of the LTE-rHRPD architecture and describes LTE-eHRPD data
mobility procedures.

LTE-eHRPD architecture
HSS/
HSS/
EIR
EIR
S6a/S13
MME
MME
LTE-eHRPD
Dual -Mode
UE
3GPP2
eHRPD
1xRTT
(3G1x)
Rx
Gx
Gxa
eNB
eNB
3GPP
PCRF
PCRF
S11
S1-MME
LTE
S10
Sh
SWx
VoIP Services
(CSCFs, E-CSCF,
TAS,SMS AS,MRF,
MGCF/MGW)
S1u
SGW
SGW
PGW
PGW
S5
SGi
3GPP
3GPP
AAA
AAA
S2a
E-UTRAN
eBTS
eBTS
STa
eRNC
eRNC
A10/A11
3GPP2
3GPP2
MSC
MSC
eHRPD-RAN
(e-AN)
178
HSGW
HSGW
AAA Authentication, Authorization, and Accounting

eHRPD evolved High Rate Packet Data
1xRTT = CDMA 1x Radio Transmission Technology (used interchangeably with 3G1x and eHRPD in
this lesson.)
eBTS evolved Base Transceiver Station
eRNC - evolved Data-Only (DO) Radio Network Controller
RAN Radio Access Network
HSGW HRPD Serving Gateway
e-AN eHRPD-RAN network
S101 and S102 interfaces from the MME to the eRNC and the 3GPP2 MSC respectively are future
interfaces.
HRPD (High Rate Packet Data) is the standards name for what is commercially known as EV-DO.
eHRPD includes changes needed to attach the 3GPP2 HRPD access network to the 3GPP Evolved
Packet Core (EPC) IP environment.

Support for cell redirection/reselection

9471 MME supports UEs moving from LTE to another RAT, such as 1xRTT.
UE type
Attaches to
Single-receiver/
dualtransmission
One RAT at a time.
When moving from LTE cell to

1xRTT
Dual-receiver/
Both LTE and 1xRTT at
dualthe same time:
transmission
"Camps" on 1xRTT cell
(Dual Transceiver while active/idle on LTE.
or DTR)
Uses 1xRTT for voice and
SMS.
179
eNodeB requests MME to release

UE context.
MME & SGW dialog to release and
delete bearers.
eNodeB requests MME to release
UE context.
MME & SGW dialog to suspend
S11 use.
Resume S11 use when UE receives
a NAS message.
9471 MME supports both single-receiver and dual-receiver UEs moving from LTE to another Radio
Access Technology (RAT), such as 1xRTT.
Information for several Radio Access Technology (RATs) may be available in a UE (either connected
or idle mode). The 9471 MME can detect the RAT when a cell is reselected.
Single receiver/Dual Transmission UE attaches to only one RAT at a time (for example, LTE)
and maintains registration and mobility procedure handling specific to that RAT. The UE regularly
searches for a better cell. When a new cell is found, inter-RAT redirection begins; the eNB requests
that the MME release UE context, at which time the MME and SGW begin a dialogue in order to
release access bearers and delete bearers for this UE.
Dual-receiver/Dual Transmission (DTR) UE attaches separately to each RAT and maintains
separate registration and mobility procedure handling to each RAT. This UE type is able to camp in
1xRTT at the same time as it is active or idle in EUTRAN (LTE). Camping in 1xRTT includes
performing 1xRTT cell re-selection, reading broadcast channels, monitoring paging, performing
location updates, etc. When this type of UE moves from LTE to 1xRTT, inter-RAT redirection begins
such that the eNB requests that the MME release UE context, at which time the MME and SGW
begin a dialogue in order to suspend S11 use. When the UE receives any NAS message, it
automatically resumes S11 use.
DTRs are designed to use a 1xRTT network for voice and SMS and to use an overlying LTE network
for data. The UE can monitor the 1xRTT network overhead channels while actively connected to
LTE. A DTR UE can originate and terminate voice calls and SMS messages on the 1xRTT network
without the use of an S102 interface between the LTE and 1xRTT networks.

LTE-eHRPD/1x data mobility procedures
Non Optimized Handover (NOHO) procedures:
LTE to eHRPD active mode HO

LTE to eHRPD idle mode HO
eHRPD to LTE idle mode HO
Enhanced Non-optimized HO allows limited context to be retained in the
HSGW and the UE
9471 MME has limited role:

Receives UE Context Release Request from eNodeB with cause of Inter-RAT
redirection
Dialogs with SGW to release access bearers
Dialogs with eNodeB to release UE Context
1 7 10
Data sessions can be handed off from LTE to eHRPD in connected or idle mode. In these scenarios,
the 9471 MME plays a limited role.
Upon receipt of the UE Context Release Request from the eNodeB (with cause of Inter-RAT
redirection), the MME:
Sends
a Release Access Bearers Request to the SGW
Sends
a UE Context release Command to the eNB
Data sessions can be handed off from eHRPD to LTE in idle mode.
When non-optimized handover is performed, the UE leaves the LTE network and attaches to the
eHRPD access network.
Optimized handover uses the S101 and S103 interfaces - the UE establishes a context with the
eHRPD access network using an S101 tunnel. Optimized handover is not currently supported.

Data mobility: eHRPD to LTE idle mode handover (1 of 3)

User plane path before HO to LTE
User plane path after HO to LTE
LTE
LTE-eHRPD
Dual -Mode
UE
HSS/
HSS/
EIR
EIR
S6a/S13
MME
MME
S10
PCRF
PCRF
Sh
SWx
VoIP Services
(CSCFs, EE-CSCF,
TAS,SMS AS,MRF,
MGCF/MGW)
Rx
S11
S1-MME
Gx
Gxa
eNB
eNB
S1u
SGW
SGW
SGi
PGW
PGW
S5
3GPP
3GPP
AAA
AAA
S2a
E-UTRAN
eBTS
eBTS
eHRPD
eHRPD-RAN
(e-AN)
1 7 11
STa
eRNC
eRNC
A10/A11
HSGW
HSGW
eHRPD PGW acts

as the mobility
anchor.
3GPP2
3GPP2
MSC
MSC


UE
eNodeB
HSGW
e-AN
MME
SGW
HSS
PGW
+
PCRF
UE discovers LTE access system

and decides to handover to LTE.
1
RRC UL Information Transfer

2
S1 Initial UE Message
Access and User Authentication
IP Address of eHRPD PGW
Location Update and Subscriber Data Retrieval from HSS

3
Create Session Request

4
Create Session Request

5
Create Charging Request

Create Charging Answer
Create Session Response

Create Session Response
Radio and Access Bearer Establishment

9
Modify Bearer Request
Modify Bearer Response

1 7 12
10
1. Radio Resource Control (RRC) uplink (UL) Information Transfer: The UE initiates the attach
procedure by sending to the eNodeB, Attach Request message together with RRC parameters.
(PLMN-ID, GUMMEI, NAS Attach Request (EPS Attachtype=handover, NAS key set identifier, Old
GUTI or IMSI, UE network Capability, ESM Message Container)).
2. The eNodeB derives the MME from the RRC parameters and passes NAS Attach Request to MME
over S1 Initial UE Message.
The MME performs user authentication, location update procedure, and retrieves subscriber
data from the HSS. Since the Request Type is Handover, the MME uses the PGW FQDN provided
by the HSS. This allows MME selection of the same PGW when a UE already has activated
bearers on a PGW in an eHRPD network.
3. Create Session Request (IMSI, ULI, Serving Network, RAT Type, Indication Flags, Sender FTEID for C-plane, PGW Address for C-plane or PMIP, APN, PDN Type, Maximum APN
Restriction, APN-AMBR, Bearer Contexts).
4. Create Session Request (IMSI, ULI, Serving Network, RAT Type, Indication Flags, Sender FTEID for C-plane, PGW Address for C-plane or PMIP, APN, PDN Type, Maximum APN
Restriction, APN-AMBR, Bearer Contexts).
5. Create Charging Request (CCR) (UPDATE, Session-ID, Bearer-Operation=INIT_REQ,APN,IMSINAI)
6. Create Charging Answer (CCA) (UPDATE ,Session-ID, PCC rules)
7. Create Session Response (Cause, Sender F-TEID for C-plane, PGW S5/S8 Address C-plane, PAA,
APN Restriction, Bearer Contexts Created
8. Create Session Response (Cause, Sender F-TEID for C-plane, PGW S5/S8 Address C-plane, PAA,
APN Restriction, Bearer Contexts Created)
9. Modify Bearer Request - MME requests to release all bearers. (Indicator flag=Scope indication,
ESP Bearer ID, ULI)
10. Modify Bearer Response (EPS Bearer ID,Cause, ULI). SGW releases all eNodeB related
information.


UE
eNodeB
HSGW
e-AN
MME
SGW
PGW
HSS
+
PCRF
PDN Initiated eHRPD

resource release
PMIP-Binding Revocation Indication
12
A11 Registration Update
14
15
11
PMIP-Binding Revocation Acknowledgement
13
A11 Registration Acknowledge

A11 Registration Request (lifetime = 0)
A11 Registration Reply
16
The HSGW may clear all UE session context or the HSGW may start the UE
Context Maintenance timer to retain limited context for a period of time. UE
Context Maintenance Timer is provisionable at HSGW.
1 7 13
11. Proxy Mobile IP (PMIP) -Binding Revocation Indication: PGW initiated PMIP connection
termination with PMIP-Binding Revocation Indication (Revocation trigger, Flags, Mobility
options).
12. HSGW responds to PGW PMIP-Binding Revocation Acknowledgement (Status) after PDN
connection is released at SGW.
13. Registration Update: HSGW sends an A11 update message to initiate with the PCF the release
of the A10 session for the UE (to eHRPD-RAN, or e-AN). The HSGW includes in the message an
indication that the corresponding eHRPD session needs to be released by eAN as well.
14. The eAN sends a Registration Acknowledge
15. The eAN sends an A11-Registration Release Request with the lifetime value set to zero to
release A10 session.
16. The HSGW responds with A11-Registration Reply with lifetime zero.
The operator can provision the HSGW to optionally retain limited context from a previously
established eHRPD session when the UE moves to LTE. Upon expiry of the UE Context
Maintenance timer, if it is started, the HSGW proceeds with step 12 (sends an A11-Registration
Update message).
Limited Context includes:
UE Session context
PPP/LCP context
Authentication context
A10 connections are kept between RNC and HSGW

Knowledge check: LTE-eHRPD data mobility

Data sessions can be handed over from eHRPD to LTE when the UE is in
either active or idle mode.
True
False
B False. Handover from eHRPD to LTE in idle mode is supported.
1 7 14

2 Voice mobility
1 7 15
This topic describes LTE-eHRPD voice mobility procedures.

LTE-eHRPD/1x voice mobility procedures

Dual transceiver (DTR) handset
The 9471 MME uses Extended Service Request and suspends/resumes an EPS
session when:
UE to accepts or originates a 1xRTT call
UE moves to a 1xRTT cell
Single receiver handset

The 9471 MME releases EPS session when:
UE accepts or originates a 1xRTT call
Moves to a 1XRTT cell
Simultaneous 1xRTT Voice and LTE data (SVLTE):

UE-only solution without MME or core network involvement.
1 7 16

Voice mobility: CS MT Call with LTE suspension (1 of 2)

User plane path before LTE data service suspended
User plane path after LTE data service suspended
MME
MME
LTE
S1-MME
S11
eNB
eNB
SGW
SGW
S1u
S5
PGW
PGW
S2a
E-UTRAN
DTR UE
eBTS
eBTS
eHRPD
eHRPD-RAN
(e-AN)
1 7 17
eRNC
eRNC
A10/A11
HSGW
HSGW
3GPP2
3GPP2
MSC
MSC

PSTN
Voice mobility: CS MT Call with LTE suspension (2 of 2)

MME sends UE Context
Release command to eNodeB.
UE moves to 1xRTT.
LTE
MME
MME
6 UE context sub-state = SGW suspended.
5 Suspend DL Notification.
UE CONTEXT
3
RELEASE
Request
9 Resume notification, resume bearers, clear SGW
UE CONTEXT
suspended sub-state.
MODIFICATION S11
4
Request
UE sends TAU to
MME to resume LTE
service.
eNB
eNB
S1-MME
S1u
SGW
SGW
PGW
PGW
S5
Extended Service
Request to MME.
S2a
E-UTRAN
DTR UE
1
UE connected in
eUTRAN receives a
page for an
incoming CS voice
call.
eBTS
eBTS
eHRPD
eHRPD-RAN
(e-AN)
eRNC
eRNC
A10/A11
HSGW
HSGW
3GPP2
3GPP2
MSC
MSC
Additional call flows for dual transceiver handsets are found in the 9471 MME
Technical Description customer document (408-111-200).

1 7 18
In this scenario, a UE in Connected mode in the LTE receives a page for a voice call from the 1xRTT
network. Note that all requests receive a response; this is not shown for simplicity.
1. The UE registered with the eUTRAN accepts a mobile-terminated circuit-switched (CS) voice call
from 1xRTT.
2. The UE sends Extended Service Request to the MME (UE may be in either EMM-Connected or
EMM-Idle mode).
3. MME sends the eNB a UE Context Modification request with the dual-receiver fallback indicator.
Dual-receiver fallback is a term used when an LTE data session is suspended while the UE
accepts or places a voice call.
4. The eNodeB sends a UE Context Release Request to the MME.
5. The MME sends S11: Suspend Notification message to the SGW requesting it to stop sending
Downlink Data Notification for this UE. SGW forwards Suspend Notification message to the PGW.
6. The MME sets UE Context Sub-State to SGW Suspended.
7. The MME responds to eNodeB with an S1 UE Context Release Command to release Radio
resource Control (RRC) and S1 UE Context. The UE Context is set to ECM-IDLE at the MME.
The UE moves to 1xRTT and performs the procedure for mobile originating/ terminating call.
8. The UE returns to LTE operation when it sends a NAS message (TAU or Service Request) to
MME.
9. The MME sends S11: Resume Notification to the SGW, allowing it to resume Downlink Data
Notifications for this UE, and the Resume Request (IMSI) message to the SGW that requests the
resumption of EPS bearers for the UE. The MME clears the SGW Suspended sub-state.

Knowledge check: LTE-eHRPD voice mobility

When a UE in an active LTE session gets a voice call originating from the
1xRTT network, the 9471 MME:
A. Hands the call over to the eHRPD
B. Suspends LTE service until the UE sends an LTE service request or TAU
C. Detaches the UE from the LTE network
B
1 7 19

This module described:
LTE-eHRPD data mobility handover procedures
9471 MME support of dual transceiver handsets for voice mobility
1 7 20

Describe the procedures performed by the 9471 MME to support
LTE-to-eHRPD mobility
1 7 21

References
The following customer documents contain information and procedures
related to 9471 MME CDMA interworking:
9471 MME Technical
Description
Describes MME functions
(418-111-200)

1 7 22

1 7 23

End of module
9471 MME Interworking with CDMA Networks
1 7 24

Section 1
9471 MME Overview
Module 8
9471 MME Interworking with UMTS/GSM Networks

Technical Overview

Blank page
182
9471 MME Overview 9471 MME Interworking with UMTS/GSM Networks
Document History
Edition
Date
Author
Remarks
01
YYYY-MM-DD
First edition

Module objectives
Describe the procedures performed by the 9471 MME to support LTE-to-UMTS
or GSM mobility
183
This module describes how the 9471 MME interworks with UMTS and GSM networks. It is assumed
that students are already familiar with the UMTS or GSM networks.
UMTS = Universal Mobile Telecommunications System
GSM = Global Systems for Mobile Communications

Table of Contents
1 LTE-UMTS/GSM interworking overview
2 PS Handover, TAU, RAU, NACC
3 Voice service and SMS
185

Page
7
19
31
1 LTE-UMTS/GSM interworking overview
187
This topic provides a high-level overview of LTE-UMTS/GSM network, interfaces, and interworking
options.

LTE-UMTS/GSM architecture
BTS
BTS
(GERAN)
(GERAN)
NodeB
NodeB
(UTRAN)
(UTRAN)
BSC
BSC
(GERAN)
(GERAN)
Iu ps (UTRAN)
Gb (GERAN)
RNC
RNC
(UTRAN)
(UTRAN)
UTRAN/
GERAN
Iu cs (UTRAN)
A (GERAN)
Gn (pre-R8)
Gp (R8)
SGSN
SGSN
Gr
S4
3GPP
3GPP
Gn (pre-R8)
MSC/VLR
MSC/VLR
S3 (R8)
HSS/
HSS/
EIR
EIR
Gn/Gp
S6a/S13
Sv
SGs
S12
GGSN
GGSN
Operators IP
services
(VoIP, IMS)
S10
Rx
NAS
eNB
eNB
S1-MME
S1-U
E-UTRAN
MME
MME
188
SGi
S11
SGW
SGW
3GPP
PCRF
PCRF
S5 (MME home PGW)

S8 (roaming UE PGW)
PGW
PGW
UTRAN = UMTS Terrestrial Radio Access Network

GERAN GSM-EDGE (Global System for Mobile Communications - Enhanced Data rates for GSM
Evolution) Radio Access Network
RNC = Radio Network Controller (UTRAN component)
BTS = Base Transceiver Station (GERAN component; Node B is the UTRAN equivalent)
BSC = Base Station Controller (GERAN component; RNC is the UTRAN equivalent)
SGSN = Serving GPRS Support Node
MSC = Mobile Switching Center
VLR = Visitor Location Register
GGSN = Gateway GPRS Support Node
The 9471 MME supports UEs from both UTRAN and GERAN:
GERAN traffic between
BTS/BSC and the MSC uses the A interface
BTS/BSC and SGSN uses the Gb interface

UTRAN traffic between
NodeB/RNC and the MSC uses the Iu_cs interface
NodeB/RNC and SGSN uses the Iu_ps interface

The 9471 MME supports both Pre-Release 8 and Release 8 SGSN:
Pre-Release 8 SGSN uses:
Gn interface between the SGSN and MME
Gn interface between the SGSN and PGW

Release 8 SGSN (called the S4 SGSN) uses:
S3 interface between the MME and SGSN (S3/Gn and S4/Gn can coexist)
S4 interface between the SGSN and PGW
GP interface between SGSN and GGSN

The 9471 MME supports: Pre-Release 8 SGSN and Release 8 SGSN; UEs from UTRAN (UMTS) and
GERAN (GSM) Radio Access network.
Terminology mapping
GPRS/UMTS
LTE
PDP Context
EPS Bearers
Primary PDP Context
Default EPS Bearer
Secondary PDP Contexts
Dedicated EPS Bearers
NSAPI
EPS Bearer ID
UMTS QoS
LTE QoS
GTPv1-C/GTPv2-C
GTPv2-C
Routing Area
Tracking Area
189
PDP = Packet Data Protocol

EPS = Evolved Packet System
NSAPI = Network Service Access Point Identifier
QoS = Quality of Service
GTP = GPRS Tunneling Protocol
RAU = Routing Area Update
TAU = Tracking Area Update

UMTS/GSM interfaces supported by the 9471 MME: Gn

Reference point between the SGSN and MME in
pre-Release 8 SGSN.
This interface may be used during:
Gn-based TAU
RAU
Network assisted cell change
Handovers between LTE and UMTS
Attach if MME requests ID information from old
SGSN
SGSN
SGSN
Gs
3GPP
3GPP
MSC/VLR
MSC/VLR
SGs
ECHO REQUEST sent by

SGSN and MME.
ECHO REQUEST
ECHO RESPONSE
GTP-C
UDP
UDP
IP
IP
L2
L2
SGSN

MME
MME
GTP-C
L1
1 8 10
Gn
L1
Gn
MME
Gn interface is the reference point between the 9471 MME and the SGSN. The Gn interface allows
the MME to effect a handover for a user who transitions from a 3GPP UMTS network to the LTE
network.
The Gn interface from the SGSN transports both signaling and bearer information. The signaling is
directed to the MME and the bearer is directed to the PGW.
The Gn interface is a control plane interface using the General Packet Radio System (GPRS)
Tunneling Protocol Control Plane (GTPv1-C) protocol. GTP tunnels are used between two nodes
communicating on a GTP-based interface to separate traffic into different communication flows.
GTPv1-C messages are sent over UDP/IP/GigE. The MME ensures that unique Sequence Numbers
are used in every ongoing GTPv1-C communication. Once the GTPv1-C signaling transaction has
been completed, the Sequence number may be re-used.
Dual stack support on Gn interface
The 9471 MME supports the IPv4v6 Dual Stack end-user address in the PDP context information
element. This facilitates transferring the Dual Stack Address between old and new network element
in the Context Response or Forward Relocation Request message.
The IPv4v6 SGSN global parameter must be set to "Yes" by the operator at the 5620 SAM if the
SGSN supports dual stack addresses. The default is set to "No" to prevent sending multiple address
types over the Gn interface to an SGSN that does not support dual stack.
Bearer context conversion
MAF bearer session management supports UTRAN/GERAN PDP context which converts bearer
contexts from LTE EPS bearer context to UTRAN/GERAN PDP context, and vice versa.

UMTS/GSM interfaces supported by the 9471 MME: S3

Reference point for the SGSN and the 9471 MME
in Release 8 SGSN.
This interface may be used during
Attach procedure
Tracking area update
Routing area update
Inter-RAT handover
Network assisted cell change
SGSN
SGSN
S3
Gs
3GPP
3GPP
MSC/VLR
MSC/VLR
SGs

SGSN and MME.
ECHO RESPONSE
GTP
GTP
UDP
IP
IP
L2
L2
S4-SGSN

ECHO REQUEST
UDP
L1
1 8 11
MME
MME
L1
S3
MME
S3 interface is the reference point between the 9471 MME and a Release 8 SGSN. The S3 interface
allows the MME to effect a handover for a user who transitions from a 3GPP UMTS network to the
LTE network. The MME is also able to effect a handover of a user who transitions from the LTE
network to a 3GPP UTRAN network.
The S3 interface from the SGSN transports both signaling and bearer information. The signaling is
directed to the MME and the bearer is directed to the PGW.
The GTPv2-C protocol stack tunnels signaling messages between the MME and the S4-SGSN using
the S3 interface. GTPv2-C is defined in 3GPP TS 29.274.
The User Datagram Protocol (UDP) transfers signaling messages between the MME and the S4SGSN. UDP is defined in RFC 768.
Fallback to GTPv1 on Gn interface
The MME supports MME fallback to GTPv1 on the Gn interface if an S4-SGSN sends the Cause Code
"Fallback to GTPv1" in a GTPv2 Context Response message to the MME over the S3 interface.
This may happen during a TAU when a UE already has an activated a PDP context on an S4-SGSN
to a GGSN. The MME may request for UE context from SGSN over GTPv2 message if S3 interface is
configured, but if SGSN doesnt support the S3 interface then it may send "Fallback to GTPv1" to
the MME. The MME in this case may fall back to GTPv1 and request the context from SGSN over Gn
interface. The TAU is rejected if a Gn interface is not available.

UMTS/GSM interfaces supported by the 9471 MME: SGs

Reference point between the MSC/VLR and the
9471 MME:
SGSN
SGSN
Gs
3GPP
3GPP
MSC/VLR
MSC/VLR
This interface:
Allows coordination of the location information for
UEs with CS fallback capability.
Relays messages related to GSM CS services over
the EPS system.
Gn or
S3
SGs
HEARTBEAT can be sent

by MSC/VLR or MME.
MME
MME
HEARTBEAT
HEARTBEAT-ACK
SGsAP
SGsAP
SCTP/TCP
SCTP/TCP
IP
IP
L2
L2
L1
MME
1 8 12
L1
SGs
MSC
Procedures and SGs Application Part (SGsAP) messages are used on the SGs interface between the
MME (in the EPS and the MSC/Visitor Location Register (VLR) in the UMTS/GSM networks to:
Coordinate
services
Relay
MME
the location information of UEs that are IMSI attached to both EPS and non-EPS
certain messages related to GSM circuit-switched (CS) services over the EPS system via
The SGs association is applicable to UEs with CS Fallback capability activated and to UEs configured
for Short Message Service (SMS) delivery via the CS core network.
SGs includes the following protocols:
SGsAP connects MME to MSC Server
SCTP over IPv4
MME establishes SCTP associations
Single-homing or Multi-homing
Multiple SCTP streams supported
Up to 6 SCTP profile types

Stream Control Transmission Protocol (SCTP) is used for the transport of SGsAP messages.
The MME and the VLR support IPv4. The IP layer of SGs only supports point-to-point transmission
for delivering SGsAP messages.
With SCTP multi-homing, each SGs Remote Endpoint may be provisioned with an alternate
(secondary) IPv4 address in addition to the required primary IPv4 address. Heartbeat support
occurs on both the primary and the alternate paths.
Up to six different SCTP profile types can be provisioned and assigned to an SGs VLR entity.

UMTS/GSM interfaces supported by the 9471 MME: Sv

Reference point between the MSC/VLR and the
9471 MME.
SGSN
SGSN
Gs
3GPP
3GPP
MSC/VLR
MSC/VLR
This interface:
Allows MME to interact with the MSC to handover
IMS-anchored voice sessions from LTE to UMTS.
Supports SRVCC, which provides IMS continuity
when the UE is a single radio.
Supports Release 8 SGSN
Sv

SGSN and MME.
ECHO REQUEST
ECHO RESPONSE
GTP-C
UDP
UDP
IP
IP
L2
L2
MME

MME
MME
GTP-C
L1
1 8 13
Gn or
S3
L1
Sv
MSC
The Single Radio Voice Call Continuity (SRVCC) architecture supports voice call continuity (session
transfer) from IMS voice over packet-switched (PS) access to circuit-switched (CS) voice access for
calls that are anchored in IMS.
UE
must be capable of transmitting/receiving on only one of these access networks at a given

time (a single radio access technology is active at one time).
Note that transfer of the call back to the LTE packet network is not currently supported.
The MME uses the Sv interface to request the MSC to reserve CS resources before handover. The
call stays in IMS.
Protocols:
GTPv2-C
UDP/IPv4
or IPv6

S4 and S12 for Release 8 SGSN

S12 provides the interface between
RNC and SGW:
RNC
RNC
Iu ps/
Gb
SGSN
SGSN
Provides direct tunnel between RNC

and SGW without SGSN (optional)
S4 provides the interface between

SGSN and SGW:
S4 SGSN
handles EPS
Bearer
contexts.
S4
S3
S12
If no direct tunnel via S12, S4

provides user-plane tunnel between
SGW and SGSN.
S10
MME
MME
S11
SGW
SGW
1 8 14
S5/S8
PGW
PGW
An S4-SGSN is a Release 8 SGSN that:

Supports the S4 interface to the SGW and the S3 interface to the MME.
Is capable of handling EPS Bearer Contexts (eliminating the need for the MME to perform the
mapping between the EPS Bearer Contexts and PDP Contexts).
The S12 interface supports direct communication between UTRAN and the SGW for user plane
tunneling when Direct Tunnel is established. It is based on the Iu u/Gn-u reference point using the
GTP-U protocol as defined between SGSN and UTRAN or respectively between SGSN and GGSN.
Usage of S12 is an operator configuration option.
When the S12 interface is supported, data packets are delivered directly between the RNC and
SGW, without going through the intermediate SGSN.
The S4 interface supports SGW communication with Release 8 SGSNs (S4 SGSN) in 3G data
networks. If Direct Tunnel is not established, S4 provides the user plane tunneling.
When a UE moves between E-UTRAN and UTRAN/GERAN, if the SGW does not change, then the
MME and the SGSN interact with the same SGW for a given UE over the respective S11 and S4
interfaces.
The same SGW tunnel is shared for the incoming control messages related to the operations on the
same UE.
Both interfaces use GTPv2 protocol and support IPv4 and IPv6.

Support for UEs
The MME supports a UE moving to:

GSM network
A/Gb-mode capable UE
GERAN
UMTS network
Iu-mode capable UE
UTRAN
LTE network
S1-mode capable UE
E-UTRAN
The MME receives mode information from UE.

Supported modes stored in the UE Context
1 8 15
The MME identifies that a UE supports these modes when the UE includes the MS Network
Capability information in an Attach or TAU request.
If the UE starts in 2G/3G and moves to LTE during idle mobility or active mobility, the Context
Response message or Forward Relocation Request message will contain the A/Gb and Iu mode
related parameters.
During S1 handover over S10 interface the MME exchanges these parameters with the target MME.
During Inter-Radio Access Network Technology (IRAT) handover over Gn/S3 interface, the MME
exchanges these parameters with the target SGSN.
GSM interfaces:
A
is the reference point between the BSC and the MSC/VLR;
Gb
is the reference point between the BSC and the SGSN.
UMTS interfaces:
Iu-CS
is the reference point between the RNC and the MSC/VLR;
Iu-PS
is the reference point between the RNS and the SGSN.
LTE interfaces:
S1-MME
S1-U
is the reference point between the eNodeB and the MME;
is the reference point between the eNodeB and the SGW.

Interworking options
Mobility in idle mode

Idle UE reselects UTRAN, GERAN, or LTE cell
Mobility in active mode
Cell reselections when UE is in GPRS packet transfer mode

Cell redirection of UE to LTE, UMTS, GSM based on RF measurements
NACC mechanism in core network moves UE from LTE to GERAN
PS handover
Voice service continuity

CSFB: Push UE to 2/3G layer for CS services
SRVCC: voice call continuity from IMS voice to CS voice
MME assists in these procedures.
1 8 16
RAT = Radio Access Technology

Cell Reselection provides the ability for the LTE IRAT capable mobile to do an idle autonomous
(no network assistance) move from LTE to UMTS, GSM, or eHRPD without sending RF
measurements to the network.
Cell Redirection is the capability of the Cell directing the LTE IRAT capable mobile to move to
LTE, UMTS, GSM, utilizing mobile serving cell or/and target cell RF measurements. Redirection
provides for a more reliable mobility since it uses RF measurements to determine where the mobile
will move.
Network Assisted Cell Change (NACC) provides the ability of a LTE-GSM capable mobile to use
the network to send RF target cell GSM measurements to the LTE eNodeB to determine where to
send the mobile. Additionally the LTE network provides GSM system information of the target
GERAN network while still connected to LTE. NACC is used when Packet Switch Handover is
unavailable. It is described more in an upcoming section of this module.
Packet Switch Handover (PSHO) uses the RF measurements as in Redirection and also does pre
network setup and forwards any remaining data so that no data is lost. This is the most reliable
Packet Switch handover. PSHO is described more in an upcoming section of this module.
Circuit Switched Fallback (CSFB) allows a UE to fall back to the CS network from LTE to
originate or terminate a voice call. CSFB is described more in an upcoming section of this module.
Single Radio Voice Call Continuity (SRVCC): voice call continuity from IMS voice over packetswitched to circuit-switched (CS) voice
The mobility decision regarding redirection versus handover is based on the UE capability as well as
the configuration information of the network capability to support UTRAN to E-UTRAN PS handover,
and the received cell measurement reports.

Knowledge check: LTE-UMTS/GSM interworking

Match the reference point in the left column with the correct
description in the right column:
1. S12
A. Reference point between the pre-Release 8 SGSN and MME;

used to coordinate mobility procedures such as TAU, RAU, and
handover.
2. S3
B. Reference point between the Release 8 SGSN and MME; used to

coordinate mobility procedures such as TAU, RAU, and
handover.
3. SGs
C. Reference point between the MSC/VLR and the MME. Used to

coordinate CSFB and relay SMS messages.
4. Gn
D. Optional reference point between the RNC and SGW. This

interface can be used to tunnel data packets directly from the
RNC and the SGW and avoid going through the SGSN.
1
2
3
4
D
B
C
-A
1 8 17

Knowledge check: LTE-UMTS/GSM interworking

The 9471 MME supports UEs that are capable of moving to an LTE, UMTS,
or GSM network.
True
False
True
The MME supports a UE moving to a:
GSM network (must be an A/Gb-mode capable UE)
UMTS network (must be an Iu-mode capable UE)
LTE network (must be an S1-mode capable UE)
1 8 18

2 PS Handover, TAU, RAU, NACC
1 8 19
This topic describes the 9471 MME procedures that are performed over the Gn interface, including
Inter-Radio Access Technology (IRAT) handover, Tracking Area Update (TAU) and Routing Area
Update (RAU).

Gn interface functions
Gn interface: MME to pre-Release 8 SGSN.
pre-Release 88
pre
pre-Release
SGSN
SGSN
UTRAN
Supports handover:
UMTS network to the LTE network
LTE network to a 3GPP UMTS network
Supports TAU and RAU procedures.
E-UTRAN
1 8 20
The Gn interface is the reference point between an MME and a pre-Release 8 SGSN. The Gn
interface is supported by a pre-Release 8 SGSN, and is called Gn-SGSN.
The Gn interface allows the MME to handover a user who transitions from:
UMTS
LTE
network to the LTE network
network to a 3GPP UMTS network
The Gn interfaces also support TAU and RAU procedures:

Gn-based
TAU is performed when:
The UE moves from UTRAN to LTE in connected or idle mode
The UE moves from GERAN to LTE in idle mode
Gn-based
RAU is performed when:
The UE moves from LTE to UTRAN in connected or idle mode
The UE moves from LTE to GERAN in idle mode
The Gn interface does not support handover between the LTE and GERAN, or TAU/RAU when a
connected UE moves between LTE and GERAN.

S3 interface functions
S3 interface: MME to Release 8 SGSN.
Supports handover:
Release
Release 88
SGSN
SGSN
UTRAN
GERAN
UMTS network to the LTE network

LTE network to a UMTS network
GSM network to the LTE network
LTE network to a GSM network
Supports TAU and RAU procedures.

E-UTRAN
1 8 21
The S3 interface is the reference point between an MME and a Release 8 SGSN. A Release 8 SGSN
is also called an S4-SGSN (after the S4 interface that it supports between the SGW and SGSN).
The S3 interface allows the MME to handover a user who transitions from:
UMTS
LTE
network to a UMTS network
GSM
LTE
network to a GSM network
The S3 interface also support TAU and RAU procedures:

S3-based
The UE moves from UTRAN or GERAN to LTE in connected or idle mode
S3-based
TAU is performed when:

RAU is performed when:
The UE moves from LTE to UTRAN or GERAN in connected or idle mode

TAU and RAU procedures

Procedure
When performed
Tracking
UE moves from
Area Update UTRAN or GERAN
(TAU)
into LTE
High-level description
UE sends TAU message to MME, which includes information
to determine the SGSN to which it is registered.
MME uses DNS to obtain the SGSN IP address and request
MM and PDP context info.
MME follows standard process to set up EPS connection.
MME sends a location update to HSS this ensures release
of SGSN resources.
UE sends RAU message to SGSN. SGSN requests context

Routing Area UE moves from
information from the MME.
Update
LTE into UTRAN or
(RAU)
GERAN
MME translates EPS bearers and QoS to values that support
equivalent PDP context in UTRAN and provides to SGSN*.
SGSN follows standard process to set up UMTS connection.

SGSN sends a location update to HSS.
MME requests eNodeB and SGW to release RRC and bearer
resources.
*An S4 SGSN is able to handle EPS bearer contexts, so the MME does not need to map
between EPS bearer contexts and PDP contexts.
1 8 22
A TAU or RAU is performed when the UE moves to another network in the IDLE state. If the UE is
CONNECTED, a handover is performed and a TAU or RAU is performed as part of the handover.
RAU vs TAU
If a UE has reselected from a UMTS cell to an LTE cell, a TAU is performed. Since the UE does not
have a Globally Unique Temporary ID (GUTI), the Packet Temporary Mobile Identity (P-TMSI) and
the Routing Area Identity (RAI) are mapped to the GUTI by the MME. The newly assigned MME can
contact the SGSN to request the subscribers current profile (IP address, PDP contexts, etc.).
The same mechanisms apply when the UE moves from an LTE cell to a UMTS cell. A RAU is
performed instead of a TAU; the GUTI is mapped to the RAI, P-TMSI, and P-TMSI Signature by the
SGSN.
DNS query to obtain SGSN IPs
The MME supports a provisioning option to use pre-Release 8 SGSN FQDNs or Release 8 S-NAPTR
procedures to discover an SGSN. The following procedures can use DNS query to discover and
select an S3 or Gn link to an SGSN:
GUTI Attach with relocation from an SGSN
TAU with relocation from an SGSN
Handover with relocation to an SGSN
If the provisioning option is set to pre-Release 8 FQDN discovery of SGSNs, then the MME always
uses the Gn interface to the selected SGSN. If the provisioning option is set to Release 8 FQDN
discovery of SGSNs, then the MME prefers to use the S3 interface over the Gn interface to the
selected SGSN, but it will use Gn records if they are returned in the query and if no S3 links are
available.
If a query for SGSN fails to return any DNS records, then the MME performs a pre-Rel8 type query.
This allows a customer to slowly migrate DNS records for SGSN from pre-Rel8 to Rel8+ queries.

Inter RAT packet switched handover procedures

Procedure
When
performed
High-level description
eUTRAN to
UTRAN InterRAT handover
with SGW
relocation and
RAU
UE in Connected UEs existing eUTRAN connection is relocated from source

state moves into
MME, eNodeB, and SGW to a UTRAN connection at the target
SGSN, NodeB, and RNC.
UTRAN from
LTE
A RAU is performed as part of the procedure.
UTRAN to
eUTRAN hard
handover with
SRNS Relocation
and TAU
UE in Connected UEs existing UTRAN connection is relocated from the source

state moves
SGSN, NodeB, and RNC to an eUTRAN connection at the target
from UTRAN
eNodeB, MME, and SGW.
into LTE
A TAU is performed as part of the procedure.
eUTRAN to
GERAN A/Gb
mode Inter RAT
handover
UE in Connected UEs existing eUTRAN connection is relocated from source

MME, eNodeB, and SGW to a GERAN connection at the target
state moves into
SGSN, BTS, and BSC.
GERAN from
LTE
A RAU is performed as part of the procedure.
GERAN A/Gb
UE in Connected UEs existing GERAN connection is relocated from the source
mode to eUTRAN state moves
SGSN, BTS, and BSC to an eUTRAN connection at the target
eNodeB, MME, and SGW.
handover
from GERAN
into LTE
A TAU is performed as part of the procedure.
1 8 23
The Inter Radio Access Technology (Inter RAT) handover procedure (also referred to as the Serving
Radio Network Subsystem (SRNS) Relocation procedure) is a handover that is triggered by a UE in
CONNECTED mode.
Handover with Pre-Release 8 SGSN:
The
UE may be going from eUTRAN (LTE) to UTRAN, or from UTRAN to eUTRAN.
Requires
Appears
no network upgrade of the existing 2G/3G elements (RNC, SGSN, etc.).

like an inter-SGSN relocation.
Handover with Release 8 SGSN:

UEs
going between eUTRAN and GERAN or between eUTRAN and UTRAN are supported.
Enables
combined network to leverage features like Idle Signaling Reduction (ISR) to improve
performance.
Appears
like an LTE handover with MME and SGW relocation.
The role of the SGSN and MME during Inter RAT procedures is to maintain the user session
continuity during the relocation, and to work with the source and target nodes to complete the
relocation as per 3GPP TS 23.401.
InterRadio Access Technology (RAT)
As per 3GPP TS 25.304 (v8.6.0, June 2009), stored information for several Radio Access Technology (RATs)
may be available in the UE. In idle mode, the UE regularly searches for a better cell as per cell selection
criteria. When a better cell is found, inter-RAT redirection begins - the eNodeB requests that the MME release
UE context, and the MME and SGW begin a dialogue in order release access bearers and delete bearers for the
UE.

LTE-to-UMTS PS handover with pre-Release 8 SGSN
User plane path before and after HO
Handover execution is done by a combined

hard handover and SRNS relocation
procedure as described in Section D.3.3 of
3GPP TS 23.401 (Release 8).
UTRAN
NB
NB
Iub
RNC
RNC
SGSN
SGSN
Pre-Rel.
Pre
Rel. 88
Pre-Rel.
Iu-ps
Gn (signaling)
S6a
HSS
HSS
Rx
MME
MME
S11
S1-mme
E-UTRAN
PCRF
PCRF
S10
Gx
Gn (user)
S5/S8
S1u
eNB
eNB
SGW
SGW
Application
Function
SGi
PGW/GGSN
PGW/GGSN
Data Services
(e.g., VPN, FTP)
Control plane
User plane
1 8 24
SRNS = Serving Radio Network Subsystem

In pre-Release 8 SGSN:
MME
acts like an SGSN.
PGW
acts like a GGSN.
MME
and PGW have to support Gn interface (GTP2 support).
It is assumed that the network supports collocated PGW and GGSN in order for session continuity.

LTE-to-UMTS PS handover with Release 8 SGSN using S3/S4

SGW acts as the local mobility anchor.
UTRAN
RNC
RNC
NB
NB
SGSN
SGSN
Iub
Rel.
Rel. 88
Iu-ps
HSS
HSS
Data session
handover
coordination
via the S3
S6a
S3
S4
MME
MME
PCRF
PCRF
S11
S1-mme
E-UTRAN
Rx
S10
Gx
S5/S8
S1u
eNB
eNB
SGW
SGW
SGi
PGW
PGW
Control plane
User plane
1 8 25
Application
Function
Legacy handling via MME and SGW.

SGSN has to support S3 and S4 interfaces.
S4 interface delivers downlink packets to idle terminal.

Data Services
(e.g., VPN, FTP)
LTE-to-UMTS PS handover with Release 8 SGSN using S3/S12
UTRAN
RNC
RNC
NB
NB
SGSN
SGSN
Iub
Iu-ps
Rel.
Rel. 88
HSS
HSS
S6a
S3
MME
MME
S12
PCRF
PCRF
S11
S1-mme
E-UTRAN
Rx
S10
eNB
eNB
Gx
S5/S8
S1u
Application
Function
SGW
SGW
SGi
PGW
PGW
Data Services
(e.g., VPN, FTP)
Control plane
User plane
1 8 26
Direct Tunnel via S12 is an optional function in Iu mode that allows the user plane to bypass the
SGSN/RNC while the UE is active. It then brings lower cost for carrying high volume of data traffic
(limiting the number of required SGSNs in the core network).
Direct tunneling with Rel.8 core network
The direct user plane tunnel is established with PS domain between the RAN and the S-GW through
S12 interface.
S4 interface is still needed to deliver downlink packets to idle terminal and to support networks that
dont want to deploy S12.
The key advantages of S12 compared to Gn direct tunneling:
S12
allows consolidation of WCDMA/LTE traffic at the SGW and so the PGW/GGSN no longer
sees inter-RAT mobility nor active/idle transitions.
The
SGW acts as a local gateway point hiding the micro-mobility between NBs from the
PGW/GGSN and is available for use for both home and visiting UEs (NB-GGSN direct tunnel is
not allowed for roamers).
S12
offers the same RNC/SGSN bypass advantage as Gn from NB (flat-IP) without the
disadvantages of going directly to GGSN.
Additional handover procedures are found in the MME functions chapter of the 9471 MME
Technical Description (418-111-200).

LTE-to-GSM cell redirection with NACC (1 of 2)

Overview:
Network Assisted Cell Change (NACC) transfers existing packet data session
from an LTE serving cell to GSM target cell.
Used when PSHO is not available.
The BSC provides the eNodeB (through MME and SGSN) with system
information of the target GSM cell.
GSM system information messages are exchanged using the RAN Information
Management (RIM) procedure.
1 8 27
Network Assisted Cell Change (NACC) enables better performance for packet data services when a
UE moves between GSM cells for those networks that do not support packet-switched handover.
NACC reduces the service interruption time for UEs in active mode upon cell change.
Prior to the cell change, the source cell system information is provided to the target cell by the core
network, thus allowing packet access.
NACC is applicable for inter-RAT cell changes from a source eUTRAN cell towards a target GERAN
cell, which is described in TS 25.413 and TS 23.060.
Support for NACC for a UE moving from eUTRAN to UTRAN is provided by the MME in an upcoming
release.
The NACC mechanism is not applicable for UTRAN to LTE mobility because acquiring target eNodeB
system information does not involve long delays.
RIM
The information is exchanged in RAN Information Management (RIM) elementary procedures. The
information in the RIM container is transparent to the core network the core nodes provide
only addressing, routing, and relay functions - they do not interpret the messages.

LTE-to-GSM cell redirections with NACC (2 of 2)

5-6. BSC relays
information to
SGSN/MME.
GERAN
RIM Signaling
BSC
BSC
SGSN
SGSN
Gb
4 4. SGSN determines
BSC.
1. eNodeB
invokes
NACC.
2. eNodeB sends
source and
destination. 2
eNodeB
eNodeB
8
3
3. MME routes
message to
SGSN.
1 8 28
Relaying
RIM Signaling
MME
MME
S1-C
RIM Signaling
8. eNB commands cell

redirection to BSC.
S3/
Gn
7. MME relays
information to
eNodeB.
E-UTRAN
In this example, the UE is in the connected state.

1. eNodeB decides to invoke NACC on receipt of UE measurement reports.
2. The source RAN node (eNodeB) sends a message to its MME or SGSN including the source and
destination addresses.
3. The MME performs a DNS S-NAPTR query to determine the IP address of the target SGSN in the
3G or 2G Network. The SGSN/MME uses the destination address to route the message
encapsulated in a GTP message to the correct MME/SGSN via the Gn/S3 interface.
4. The MME/SGSN connected to the destination RAN node decides which RAN node (BSC) to send
the message to based on the destination address.
5 through 6. The destination RAN node (BSC) relays information to the MME or SGSN
7. SGSN/MME relay information to the eNodeB.
8. eNodeB relays RAN information to UE and commands the cell redirection towards the target GSM
cell.

Knowledge check: Gn- and S3-based procedures

When a UE in IDLE state moves from UTRAN into LTE, the UE sends a
______ request to the _______ to indicate its new location.
A.
B.
C.
D.
the UE sends a RAU request to the MME

the UE sends a TAU request to the MME
the UE sends a RAU request to the SGSN
None of the above neither TAU nor RAU is performed if the UE is idle.
1 8 29

Knowledge check: Gn- and S3-based procedures

When a UE in CONNECTED state moves from LTE to UTRAN, which of the
following functions is performed by the MME?
A. The MME routes user data packets to the SGW via the new SGSN.
B. The MME temporarily forwards user data packets to the SGW until the
handover from the eNodeB to the RNC is complete.
C. The MME coordinates a handover to the UTRAN with the target SGSN,
the SGW, and the source eNodeB.
C
1 8 30

3 Voice service and SMS
1 8 31
This topic describes the 9471 MME procedures that are performed over the SGs interface, including
the current voice service options and Short Message Service (SMS) handling.
This topic also describes an IMS voice call handover from LTE to UMTS and GSM.

Voice over LTE options
UE is registered and paged in LTE.

Circuit-Switch
Fall-back (CSFB) UE takes voice call in CS (GSM or UMTS).
IMS over LTE; or IMS over LTE and UMTS.

Voice over IMS
(VoIMS)
Use SRVCC to handover legacy circuit switched

voice to GSM/UMTS.
1 8 32
Circuit-Switch Fall-back (CSFB)

UE
is registered in LTE and is paged on MT in LTE but takes call in CS (GSM or UMTS).
Two
deployment scenario possible:
Camp on 3G and handover to LTE during active data sessions.
Camp on LTE and use CSFB to handle voice services.
Voice over IMS (VoIMS)

Uses
a standard 3GPP IMS coupled with Single Radio Voice Call Continuity (SRVCC) when using
circuit switched voice over legacy GSM/UMTS access.
Two
deployment scenarios:
IP Multimedia Service (IMS) over LTE only and use SRVCC to handover to UMTS and
GSM.
IMS over LTE and UMTS and use SRVCC only for GSM coverage.

CSFB and SMS procedures using SGs interface

The MME supports the following CS fallback and SMS procedures:
Combined EPS/IMSI attach
Tracking area update (TAU)
Combined tracking area/location area update and periodic TA/LA update
procedures
Mobile originating (MO) and mobile terminated (MT) call in active mode with
and without packet-switched handover supported
MO and MT call in idle mode
UE, MME and HSS initiated detach
Returning back to eUTRAN
MO or MT call rejection
Non-EPS Alert
Paging
1 8 33
The 9471 MME supports all the Mobility Management procedures, mobile originating (MO) and
mobile terminating (MT) calls as specified in TS 23.272.
The MME supports the provisioning of a paging method and timers for each paging attempt from
the MSC. By default, the paging policy is the same as the regular paging policy for LTE networks.
Separate paging policies for CS calls and SMS services can optionally be provisioned.

CSFB UEs
Voice,
SMS
GERAN
UTRAN
(CS)
Data
connection
E-UTRAN
(PS)
MME identifies a CSFB-capable UE.

Stores information in UE context.
MME coordinates location and

paging with the MSC/VLR.
CSFB
UE
1 8 34
The 9471 MME supports UEs that are enabled to use both the LTE network and the UMTS/GSM
networks. These are known as a Circuit Switch Fallback (CSFB) capable UEs.
The MME identifies a CSFB-capable UE in the following ways:
Attach: UE sets attach type to combined EPS/IMSI attach in the NAS Attach
Request
During
During
TAU: UE sets EPS update type to combined TA/LA updating or combined
TA/LA updating with IMSI attach
A CSFB-capable UE can:
Initiate
Send
a CSFB voice call with or without handover of PS bearers
Voice calls fall back to use the UTRAN or GERAN access network and traditional setup for
voice services. The UE will use the standard CS voice call set-up procedures to establish
the voice call in the CS domain.
a Short Message Service (SMS) message to the CS domain
Originate and terminate over EPS network
UE stays in LTE access network and will send/receive SMS over EPS.
Receive
pages for incoming SMS or voice calls
MME coordinates location and paging with the MSC/VLR. The MME performs paging
procedures upon request of the MSC/VLR, depending on the state of the UE.
The combined IMSI/EPS attach is used by a CSFB enabled UE and SMS interworking with
GSM/UMTS. MME sets up the UE Attach Request for both EPS and non-EPS services.

Paging CSFB UE
Voice call is destined for a
CSFB UE in the eUTRAN.
Circuit
Voice
Network
SGSN
SGSN
Iups
Node
Node B
B
Iucs
RNC
RNC
MSC
MSC
Rel8
Rel8
SGs
UTRAN
MME
MME
CSFB
UE
S1-mme
2 MSC/VLR checks SGs
association for the UE
MSC/VLR sends paging

request to the MME.
MME pages the UE

(depending on UE state)
S11
E-UTRAN
S1u
eNB
eNB
1 8 35
SGi
S5/S8
SGW
SGW
PGW
PGW
PDN
The paging procedure applies to UEs that are simultaneously attached for EPS services and non-EPS
services, or for EPS services and SMS only.
1. A voice call is destined for a CSFB UE in the eUTRAN.
2. The VLR checks whether it has an SGs association for that UE.
3. Depending on the result* the VLR sends a SGsAP-PAGING-REQUEST message to the MME.
4. MME handles the paging, depending on the state of the UE:
1. If the UE is known and the SGs association is not in the state SGs-NULL, the MME pages the
UE based on the location information stored in the MME.
2. If the UE is not known and the MME-Reset restoration indicator at the MME is set to false,
the MME returns a reject message to that VLR.
3. If the UE is not known and the MME-Reset restoration indicator at the MME is set to true
and the SGsAP-PAGING-REQUEST message included the Location area identifier information
element, the MME pages the UE in all the tracking areas served by the MME that can be
mapped to the location area indicated in the Location area identifier.
If the SGsAP-PAGING-REQUEST message does not include the Location area identifier
information element, the MME may page in all the tracking areas served by the MME.
If an SGs paging attempt from the MSC fails, the MSC is responsible for paging retries.
The paging method and timers for each paging attempt from the MSC can be provisioned from
the MME.
*The VLR sends SGsAP-PAGING-REQUEST messages to the MME if:
The state of the SGs association for the UE is SGs-ASSOCIATED, LA-UPDATE-PRESENT, or
The state of the SGs association is SGs-NULL and the Confirmed by Radio Contact
restoration indicator is set to false. In this case the VLR performs a search procedure.
The Confirmed by Radio Contact restoration indicator is set to true, the VLR includes the
Location area identifier information element into the SGsAP-PAGING-REQUEST message.
CSFB with Pre-Release 8 SGSN

User plane path before and after voice call.
User plane path during voice call.
Iu-cs
MSC
MSC
UTRAN
RNC
RNC
NB
NB
Iub
SGs
SGSN
SGSN
Iu-ps
Circuit
Voice
Network
Gn (signaling)
S6a
HSS
HSS
MME
MME
PCRF
PCRF
Rx
S11
S1-mme
E-UTRAN
Gn (user)
SGW
SGW
1 8 36
Gx
S5/S8
S1u
eNB
eNB
S10
SGi
PGW/GGSN
PGW/GGSN
Operators
Charging
Data Services
(e.g., VPN, FTP)
This example describes a mobile terminating voice call to a UE that is in active mode in the LTE
network. The UE will fallback to the legacy 2G/3G network with a pre-Release 8 SGSN. CSFB
with Release 8 UTRAN networking is also supported (S3 interface).
1. The EPS-attached UE receives a page from the MME for a CS voice call.
2. The UE sends an Extended Service Request with CSFB indication to the MME after the user
answers the terminating call.
3. The MME sends an S1-AP message to the eNodeB with the Fallback Indicator.
4. The eNodeB initiates a handover based on CSFB indicator.
5. A packet switched handover is performed and the UE retunes to the UTRAN after RAB is
established in 3G. The UE data session falls back to 3G (Optionally, depending on the operator
configuration, a network assisted cell change may be performed rather than a handover,)
6. The UE sends a service request for circuit services to the RNC and the call is established via the
MSC/VLR.
7. When the call ends, a packet-switched handover to LTE is performed.
8. RAU and TAU are performed as part of the handover procedures if needed.
CSFB can be applied for Emergency Services calls. The MME supports the mobile originating CS
fallback emergency call value in the Service Type information element (IE) within the Extended
Service Request from UE. The MME passes the value as CS Fallback High Priority to the
eNodeB in the S1AP UE Context Modification or S1AP Initial Context Setup message.

SMS support illustration
SMS message path in LTE.

SMS message path in UMTS and GSM.
BSC
BSC
BTS
BTS
Gb
SGSN
SGSN
Gr
GERAN
RNC
RNC
MSC
MSC
Rel8
Rel8
Home
(sender)
SGs
UTRAN
eNB
eNB
SMS-SC
SMS
SMS-SC
D
Iucs
E-UTRAN
MSC
MSC
Iups
Node
Node BB
Gd
HLR
HLR
MME
MME
S1-mme
S1u
1 8 37
Home
(receiver)
S11
SGW
SGW
S5/S8
SGi
PGW
PGW
PDN
Visited
Short Message Service (SMS) delivery is also via the CS core network using the SGs interface, but
without the need to fallback.
UEs must be configured to use SMS. Procedures such as IMSI attach, combined IMSI Attach,
location update, combined TAU, and paging may be used to establish SMS.
Current solution:
Rely on legacy SMS architecture
MSC hands over SMS to MME (mobile terminated SMS) or vice versa (mobile originated SMS)
SGs interface between MME and MSC supports SMS.

Operator CSFB preferences

The operator can provision the circuit switched voice and SMS preference:
No CSFB or SMS Support

SMS-only support (no CSFB supported)
CSFB support for Voice and SMS
CSFB support for Voice and SMS, but Voice is not preferred. If the UE has IMS
PS Voice available, it will be used.
Operators can also specify preferences for a given location area:

Both SGs-based CSFB voice and SMS are supported in a given Location Area
Only SMS is supported.
1 8 38
Circuit switched voice and SMS preference is specified at the PLMN provisioning form at the 5620
SAM.
Location Area preferences are specified at the UE Roaming Restrictions form of the 5620 SAM.

Roaming support for 2G/3G networks

The 9471 MME supports CSFB from an LTE operator to a different 2G/3Gonly operator, where the coverage of the LTE operator is overlaid with the
coverage of the 2G/3G-only operator.
The MME is provisioned with MSC addresses for up to three other 2G/3G
operators.
If the UE is a roamer and belongs to one of the other provisioned 2G/3G
operators, the MME selects an MSC in that operators network.
If the UE is a roamer and does not belong to one of the other 2G/3G operators,
the MME may select an MSC in the LTE operators network, depending on the
roaming agreement.
1 8 39

SRVCC procedures
The SRVCC procedures support:
Handover
type
From
Scenario
CS-only
E-UTRAN to
UTRAN/GERAN
CS+PS
E-UTRAN to
UTRAN/GERAN
Voice bearers are handed-over to the CS

network via Sv interface to MSC.
Voice bearers are handed-over to the CS
network via Sv interface to MSC.
Packet bearers are handed-over to a PS
network via Gn/S3 interfaces to SGSN.
Note that if the PS HO fails, the CS HO will proceed.
1 8 40
SRVCC = Single Radio Voice Call Continuity; CS = circuit switched; PS = packet-switched; HO =

handover
The 9471 MME supports the following SRVCC procedures (as specified in 3GPP TS 23.216):
E-UTRAN
Single
Attach procedure for SRVCC
Radio (SR) procedure for SRVCC
SRVCC
from E-UTRAN to GERAN without Dual Transfer Mode* (DTM) support
SRVCC
from E-UTRAN to GERAN with DTM but without DTM handover (HO) support
SRVCC
from E-UTRAN to UTRAN without packet switched (PS) HO
SRVCC
from E-UTRAN to UTRAN with PS HO
SRVCC
from E-UTRAN to GERAN with DTM HO
*Dual Transfer Mode simultaneous transfer of voice and data

Sv-based handover from E-UTRAN to UTRAN/GERAN
Path for LTE IMS voice call

Voice path after HO to CS network
Iu-cs
MSC
MSC
UTRAN
RNC
RNC
NB
NB
Iub
Iu-ps
Sv
SGSN
SGSN
Gn (signaling)
HSS
HSS
S6a
IMS
MME
MME
S11
S1-mme
E-UTRAN
Gn (user)
S5/S8
S1u
eNB
eNB
PCRF
PCRF
S10
SGW
SGW
1 8 41
PGW/GGSN
PGW/GGSN
SRVCC for CS-only HO from E-UTRAN to UTRAN/GERAN is performed as follows:

1. The MME receives the handover request from the eNodeB with the indication that this is for
SRVCC handling.
2. If the MME has SRVCC STN-SR* information for this UE, the MME then triggers the SRVCC
procedure with the MSC Server (enhanced with SRVCC) via the Sv interface.
3. The MSC initiates the session transfer procedure to IMS and coordinates it with the CS handover
procedure to the target UTRAN/GERAN cell.
4. The MSC then sends PS-to-CS Response to the MME, which includes the necessary CS HO
command information for the UE to access the UTRAN/GERAN cell.
5. The MME subsequently forwards the information to the eNodeB.
*STN-SR is Session Transfer Number for SRVCC and is part of the UE's HSS Subscription Data.

Knowledge check: SGs-based procedures

A CSFB-capable UE is camped on an LTE eNodeB and receives a voice call
from the circuit-switched network.
What core node sends a page to the UE?
A. MSC/VLR
B. SGSN
C. MME
When the subscriber answers, how does the UE handle the call?
A. The data connection falls back to the UMTS network and the UE requests
circuit services to connect the voice call.
B. The data connection remains in the LTE network and the UE requests circuit
services to connect the voice call.
C. The data connection is suspended in the LTE network and the UE requests
circuit services to connect the voice call.
A
1 8 42


LTE-UMTS/GSM interworking, including
Network architecture
Gn, S3, SGs, S4, and S12 interfaces
Interworking options: cell reselection, redirection, Network Assisted Cell Change (NACC),
Circuit Switched Fallback (CSFB)
Gn-and S3-based interworking procedures supported by the MME, including;
Handover
Tracking Area Update (TAU)
Routing Area Update (RAU)
Network Assisted Cell Change (NACC)
Attach
SGs-based interworking procedures supported by the MME, including:

Circuit-switched fallback (CSFB) voice call capabilities
Short Message Service (SMS) capabilities
Paging by the 9471 MME
Sv-based interworking procedures supported by the MME, including:

Voice bearers handed-over to the CS network via Sv interface to MSC
1 8 43

Describe the procedures performed by the 9471 MME to support LTE-to-UMTS
or GSM mobility
1 8 44

References
related to 9471 MME CDMA interworking:
9471 MME Technical
Description
Describes MME call flows and MME functions
(418-111-200)

1 8 45

End of module
9471 MME Interworking with UMTS/GSM Networks
1 8 46

Section 1
9471 MME Overview
Module 9
9471 MME Hardware

Technical Overview

Blank page
192
9471 MME Overview 9471 MME Hardware

Document History
Edition
Date
Author
Remarks
01
YYYY-MM-DD
First edition

Module objectives
Locate and explain the function of the key 9471 MME components
Describe how 9471 MME components are physically connected
193
This module describes the hardware components of the 9471 Mobility Management Entity (MME)
system and how they are interconnected. It explains how the 9471 MME is built upon standard
Alcatel-Lucent platforms.

Table of Contents
1 9471 MME hardware architecture
2 Power distribution
3 Chassis components
4 Cabling and connections
5 Failure scenarios
195

Page
7
17
23
41
57
1 9471 MME hardware architecture
197
This topic describes the hardware layout for the 9471 MME.

Base platform: 5400 LCP

Blades
Product-specific
interface or traffic
processors
Application/
product
OAM Server
5400 LCP platform
Ethernet Hub
ShMC
ATCA platform
198

The 5400 Linux Control Platform (LCP) is an Alcatel-Lucent hardware/software platform that can be
built on the ATCA platform. Various independent Alcatel-Lucent applications can be run on top of of
the 5400 LCP.
The Alcatel-Lucent 5400 Linux Control Platform (LCP) is used for mutiple Alcatel-Lucent
applications, including:
HP-PTT
LTE
Registration Manager
9471 Mobility Management Entity (MME)
5450
ISC (IP Session Control)
5450
IRC (IP Resource Control)
5420
CTS (Converged Telephony Server)
The 5400 LCP ia a standardized Alcatel-Lucent proprietary platform for the telecommunications
industry. Required blades for 5400 LCP:
Provided by ATCA platform:
Ethernet
Shelf
Hub/switch
Management Controller (ShMC)
Additional blades:
OAM
Server, which hosts the management functions for the 5400 LCP
Traffic
and applications processors that host specific product functions (example: 9471 MME
applications)
Rear
Transition Modules can be added for additional connections.

Functional architecture
5620 SAM
MME
OAM
server
MAF
SGSN
LI
eNodeB
MSC
Server
MME
MIF
SGW
MPH
HSS/EIR
Control
OAM&P
199

This slide identifies the subcomponents of the MME: the OAM server, the MME Application Function
(MAF) , the MME Interface Function (MIF); the MME Packet Handler (MPH) service; and, illustrates
the interfaces between them.
MME subcomponents:
OAM
Server: Supports OA&M functions and graphical user interfaces
MME
Interface Function (MIF):
MME
Provides paging broadcast and link management services
Selects and distributes messages to the appropriate MAF
Application Function (MAF):
MME
Provide mobility and session/bearer management for user sessions and

procedures
Store UE Contexts in memory
Packet Handler (MPH) service

Terminates the external signaling SCTP, UDP and TCP stacks to offload the MIF from this
function.
Lawful Intercept (LI) as mandated under government agencies enhances the ability of law
enforcement and intelligence agencies to conduct electronic surveillance.

Minimum configuration with 16-GB MIF/MAF

PDU
Single 44U enclosed cabinet

Power distribution unit at top of frame
Single ATCA 300W per slot chassis with horizontal

redundancy:
1 pair of Shelf Management Cards (ShMCs) slot 15
1 pair of Ethernet Hubs in slots 7-8
Host MPH on High Speed Packet Processor AMC
RTMs plugged into the rear of the Hubs

ShMC
1 9 10
MPH/Hub
MPH/Hub
MAF
MAF
MIF
MIF
OAM Server
OAM Server
External interfaces via the RTM behind the Hubs.
ShMC
1 pair of 16-GB OAM Server blades (Diskful) slots 1-2

1 pair of MIF blades (Diskless)
1 pair of MAF blades (Diskless) in slots 5-6
Upper and lower 300W fan trays with filters
RTM
RTM
When 16-GB traffic/interface processor blades are used, the MIF cards are located in slots 3 and 4
of shelf 0 and do not have RTMs.
AMC = Advanced Mezzanine Card
MPH = MME Packet Handler
RTM = Rear Transition Module (ROETHAA is the mnemonic name that distinguishes the RTM on the
Hubs from the SS7 RTM on the MIFs.)
MIF = MME Interface Function
MAF = MME Application Function
Diskful = A card that includes an additional hard disk inserted in the AMC card slot to provide
storage.
Diskless = A card with no additional disk for storage (an AMC card providing another function may
or may not be present).
The 9471-MME is delivered to the customer in a single 44U Alcatel-Lucent cabinet. The 44U is a 19inch/48.3 cm (internal dimension) Rack Mounting Unit (RMU). All internal wiring and cabling is
already mounted. The cabinet must be installed. A single-shelf or two-shelf configuration is
supported. Up to 3 MAF pairs can be added to the minimum configuration in the first shelf.
The Power Distribution Unit at the top of the cabinet provides reduntant -48V power and alarms.
44U cabinet external dimensions:
Width: 598 mm (23.5 inches)
Depth: 600 mm 23.6 inches)
Height: 2125.5 mm (83.7 inches)
All empty slots, front and rear, contain protective fillers.
Two-shelf configuration with 16-GB MIF/MAF

PDU
MAF pairs are grown from left to right in pairs.

Second shelf consists of:
Shelf 1 hubs interconnect with shelf 0;
No RTM or AMC
RTM
RTM
1 to 6 pair of MAF blades

Upper and lower fan trays
ShMC
MAF
MAF
MAF
MAF
MAF
MAF
Hub
Hub
MAF
MAF
MAF
MAF
MAF
MAF
ShMC
Shelf 1
1 pair of ShMC
1 pair of Hubs
1 9 11
ShMC
MAF
MAF
MAF
MAF
MAF
MAF
MPH/Hub
MPH/Hub
MAF
MAF
MIF
MIF
OAM Server
OAM Server
ShMC
Shelf 0


Up
to 3 additional MAF pair may be added to the first shelf (4 pair total).
Second shelf equipage consists of:

1
pair of Shelf Management Cards (ShMCs)
pair of Hubs
Shelf 1 hubs interconnect with shelf 0; no RTM or AMC
to 6 pair of MAF blades
Upper
and lower fan trays
The number of MAF blade pairs is dependent on the capacity required. Up to three MAF pairs (in
addition to the required single pair) may be added to Shelf 0. From one to six pairs may be added
to a second shelf. No down time is required for growth of a MAF pair or shelf.
The numbering of the shelves begins with 0. The first shelf in a Alcatel-Lucent 9471 MME system is
designated as Shelf 0. This is often, but not always, the lower shelf in the rack. The next chassis is
Shelf 1.
The second shelf does not require OAM blades, RTM blades, MIF blades, or MPH cards in the Hubs.
Shelf 1 hubs contain a chassis interconnect with shelf 0. Failover of cards is supported within a
shelf, but not across shelves.
Growth procedures for MAF blades and second shelf are found in the 9471 MME OAM&P (418-111201) document.
Note: Front filler panels must cover any unused slot.
Minimum configuration with 32-GB MIF/MAF

PDU
Single 44U enclosed cabinet

Power distribution unit at top of frame
Single ATCA 300W per slot chassis with horizontal

redundancy:
1 pair of Shelf Management Cards (ShMCs) in slot 15
1 pair of Ethernet Hubs in slots 7-8
Host MPH on High Speed Packet Processor AMC
RTMs plugged into the rear of the Hubs
SS7 RTM
SS7 RTM
RTM
RTM
1 pair of 16-GB OAM Server blades (Diskful) slots 1-2

1 pair of MIF blades (Diskless) in slots 13-14
Include SS7 RTM and SS7 E1/T1/J1 AMC (future use)
1 pair of MAF blades (Diskless) in slots 3-4

ShMC
MIF
MIF
ShMC
MPH/Hub
MPH/Hub
1 pair of Upper and lower 300W fan trays with filters
MAF
MAF
OAM Server
OAM Server
Include HSPP4 AMC (future use)
All external interfaces via RTM behind the Hubs.

1 9 12
When 32-GB traffic/interface processor blades are used, the MIF cards are located in slots 13 and
14 of shelf 0 and have RTMs. 32-GB MIF/MAF blades are installed with new systems beginning in
LM4.0. 32-GB blades are not required. MIF/MAF hardware blade pairs must match (the pair must
both be 32-GB or both be 16-GB).
AMC = Advanced Mezzanine Card
MPH = MME Packet Handler
RTM = Rear Transition Module (ROETHAA is the mnemonic name that distinguishes the RTM on the
Hubs from the SS7 RTM on the MIFs.)
MIF = MME Interface Function
MAF = MME Application Function
Diskful = A card that includes an additional hard disk inserted in the AMC card slot to provide
storage.
Diskless = A card with no additional disk for storage (an AMC card providing another function may
or may not be present).
The 9471-MME is delivered to the customer in a single 44U Alcatel-Lucent cabinet. The 44U is a 19
inch Rack Mounting Unit (RMU). All internal wiring and cabling is already mounted. The cabinet
must be installed. A single-shelf or two-shelf configuration is supported. Up to 3 MAF pairs can be
added to the minimum configuration in the first shelf.
The Power Distribution Unit at the top of the cabinet provides reduntant -48V power and alarms.
44U cabinet external dimensions:
Width: 598 mm (23.5 inches)
Depth: 600 mm 23.6 inches)
Height: 2125.5 mm (83.7 inches)
All empty slots, front and rear, contain protective fillers.

Two-shelf configuration with 32-GB MIF/MAF

PDU

ShMC
Shelf 1
Shelf 1 hubs interconnect with shelf 0

No RTM or AMC
1 9 13
ShMC
MIF
MIF
MAF
MAF
MAF
MAF
MPH/Hub
MPH/Hub
MAF
MAF
MAF
MAF
OAM Server
OAM Server
ShMC
Shelf 0
SS7 RTM
SS7 RTM
RTM
RTM
1 to 6 pair of MAF blades

Upper and lower fan trays
ShMC
MAF
MAF
MAF
MAF
MAF
MAF
Hub
Hub
MAF
MAF
MAF
MAF
MAF
MAF
1 pair of ShMC
1 pair of Hubs


Up
to 3 additional MAF pair may be added to the first shelf (4 pair total).

1
pair of Shelf Management Cards (ShMCs)
pair of Hubs
Shelf 1 hubs interconnect with shelf 0; no RTM or AMC
to 6 pair of MAF blades
Upper
and lower fan trays
The number of MAF blade pairs is dependent on the capacity required. Up to three MAF pairs (in
addition to the required single pair) may be added to Shelf 0. From one to six pairs may be added
to a second shelf. No down time is required for growth of a MAF pair or shelf.
The numbering of the shelves begins with 0. The first shelf in a Alcatel-Lucent 9471 MME system is
designated as Shelf 0. This is often, but not always, the lower shelf in the rack. The next chassis is
Shelf 1.
The second shelf does not require OAM blades, RTM blades, MIF blades, or MPH cards in the Hubs.
Shelf 1 hubs contain a chassis interconnect with shelf 0. Failover of cards is supported within a
shelf, but not across shelves.
Growth procedures for MAF blades and second shelf are found in the 9471 MME OAM&P (418-111201) document.
Note: Front filler panels must cover any unused slot.

Chassis-only configuration
A chassis-only option is available:
Shelf 1
MAF
MAF
MAF
MAF
MAF
MAF
ShMC
Hub
Hub
MAF
MAF
MAF
MAF
MAF
MAF
ShMC
Customer provides the frame.

No PDU
One- or two-shelf configurations possible.
RTM
RTM
A chassis-only option is available:

No
frame the customer provides the frame or rack.
No
Power Distribution Unit (PDU) power is provided directly to the chassis.
One-
or two-shelf configurations are possible.
16-GB
or 32-GB MIF/MAF blades are available.
The shelf configuration for a chassis with 16-GB MIF/MAF blades is shown in the graphic.
Note: Alcatel-Lucent performs 9471 MME hardware installation, including chassis-only options.

ShMC

MAF
MAF
MAF
MAF
MAF
MAF
MIF
MPH/Hub
MPH/Hub
MAF
MAF
MIF
OAM Server
OAM Server
1 9 14
ShMC
Shelf 0
Growth and hardware replacement in LM5.0

Upgrade OAM Server blades
Systems with 8-GB OAM Server blades MUST UPGRADE to 16-GB OAM Server
blades before a software upgrade to LM5.0.
Procedure is found in the 9471 MME OAM&P guide (418-111-201).
Upgrade MIF/MAF blades

There is no procedure to upgrade existing MIF/MAF blades from 16-GB to 32GB in LM5.0.
Grow MAF blades

New MAF pairs grown into the system must be 32-GB.
The LM5.0 software supports a mixture of 16-GB blade pairs and 32-GB blade
pairs.
Replace MIF/MAF blades

Each MIF and MAF blade pair must be of the same kind, either both 16-GB or
both 32-GB.
16-GB blades are available to replace failed 16-GB MIF or MAF hardware.
1 9 15
9471 MME systems installed in LM4.0 or later are installed with 16-GB OAM Servers.
For older systems that are still on 8-GB OAM Servers: the procedure to convert from 8-GB OAM
Servers to 16-GB OAM Servers is found in the 9471 MME OAM&P customer document.
Note: If there is one 16-GB MIF/MAF blade pair in the system, any 32-GB blade pairs will perform at
16-GB capacity.
MIF blades cannot currently be grown since here is no reason to have more than one MIF pair.

Knowledge check: 9471 MME hardware architecture
Where is the mate to this OAM Server?

Redundancy is configured horizontally, so the
mate would be in the next slot (slot 2)

OAM Server
OAM Server
1 9 16

2 Power distribution
1 9 17
This topic explains how power is distributed in the 9471 MME functionality.

MME with power distribution unit

Fuses
Circuit breakers
Power Bus A
Circuit Breakers
Power Bus B
Each power zone

fed by A and B
power feeds.
Power
Source
7 LED
Alarm panel
1 9 18

Redundant DC power is brought into the cabinet through the Power Distribution Unit (PDU). Two
independent and secured DC power sources are required for all configurations: Power Bus A and
Power Bus B. Each is capable of independently supporting the full 9471-MME cabinet load. The DC
sources are 48 V DC or 60 V DC nominal voltage (40.5 to 72 V).
For configurations that include the Alcatel-Lucent cabinet and PDU, redundant DC power is brought
into the cabinet through the Power Distribution Unit (PDU).
The PDU, placed at the top of the cabinet, distributes power to the chassis and devices.
Both A and B are fed to each slot in the chassis, with alternate slots serviced by alternate sets of
input feeders to improve reliability.
Input power feeds pass through power conditioning filters in the Power Entry Modules (PEMs) at
the rear of the chassis before distribution to the midplane (see upcoming PEM slide).
DC sources are 48 V DC or 60 V DC.
Alarm Card:
The PDU also includes an alarm card, which monitors the power for each blade:
6
system alarms (critical, major and minor, each audible and visible). The alarm LEDs are
lit/unlit based on the highest alarm status on the system. System alarm status is transferred
to the PDU from the OAM Server blade (described in an upcoming slide).
2x
6
48V loop external alarms 48V supervision
LEDs on the PDU face-plate for critical, major and minor alarms
Alarm
Cut Off (ACO) and 48VA/48VB presence
The circuit breakers, alarm card, and fuses are field replaceable.

MME without power distribution unit

For chassis-only configurations:
Redundant DC power is brought into the chassis through Power Bus A and
Power Bus B.
RTM
RTM
ShMC
MAF
MAF
MAF
MAF
MAF
MAF
MIF
ShMC
MPH/Hub
MPH/Hub
MAF
MAF
MIF
OAM Server
OAM Server
Power
Source
1 9 19
For chassis-only configurations, redundant DC power is brought into the cabinet through two
independent and secured DC power sources. These are required for all configurations: Power Bus A
and Power Bus B.
Each is capable of independently supporting the full 9471-MME cabinet load. The DC sources are 48
V DC or 60 V DC nominal voltage (40.5 to 72 V).
Both A and B are fed to each slot in the chassis, with alternate slots serviced by alternate sets of
input feeders to improve reliability.
Power is distributed to blades from the midplane.
Input power feeds pass through power conditioning filters in the Power Entry Modules (PEMs) at
the rear of the chassis before distribution to the midplane (see upcoming PEM slide).

Power Entry Module (1 of 2)

Fan area
RTM area
Ground
Bus B
Bus A
Fan area
Rear view of chassis
1 9 20

The power flows from the PDU (or direct power source for chassis-only configuration) to the Power
Entry Modules (PEMs).
The PEM distributes power to the midplane.
There are connections on the midplane from both the A and B power sources to each slot in the
chassis.
A PEM is required for the chassis with or without a frame.
The PEM is not field replaceable.

Power Entry Module (2 of 2)
Node 2
Node 3
Node 4
Node 5
Node 6
Hub 1
Hub 2
Node 7
10 11 12 13 14
ShMC
ShMC
Node 12
Node 11
Node 10
Node 9
Node 8
1
Node 1
FAN
M48V-A2
Filter M48V-B2
Filter
M48V-A1
Filter
Filter M48V-B1
FAN
1 9 21

There are two A&B power connections:

The
A1/B1 connections power the odd slots.
The
A2/B2 connections power the even slots.

Knowledge check: Power

Power is distributed to individual blades in the chassis by the
________________.
A.
B.
C.
D.
PDU
PEM
Circuit breakers
midplane
1 9 22
D - midplane

3 Chassis components
1 9 23
This topic describes the hardware components 9471 MME chassis.

Shelf architecture: 16-GB application nodes

Even-odd slots provide
redundancy
Chassis 0 (bottom).
300W per slot.
Ground point
Upper cooling unit

14 slot rack-mount
ShMC 1
ShMC 2
Lower cooling unit
Slot 15
Slot 1
1 9 24

An LM4.0 hardware configuration with MIF blades in slots 13-14 is shown. The shelf holds the
circuit boards and consists of:
Guide
ESD
rails
discharge clips
Alignment/keying
Handle
Face
interface
plate mounting hardware
Midplane
Cooling
units
9471 MME supports 1+1 blade redundancy. Mates are side-by-side, left to right.
Numbering:
Elements
increase numerically from left to right, and from bottom to top. Hence: The bottom
shelf in cabinet 0 is shelf 0.
The
leftmost slot is 1; the rightmost slot (for ShMC) is 15.
The
ShMc are the exception: they increase numerically from top to bottom (1 and 2).
Note: The graphic shows the SAV2AB chassis. The newer chassis is SAV2AC. Key additions for
SAV2AC:
On
the front of the chassis above the ShMC (where the ground point is shwon) there is a slot
for an optional chassis alarm card.
On
the rear of the chassis, left side, there is an optional rear transition card with ports to an
external alarm system.
Neither of these features are currently used in the 9471 MME.

Shelf architecture: 32-GB application nodes

Even-odd slots provide
redundancy
Upper cooling
unit
Ground point
Chassis 0
(bottom):
300W per
slot.
ShMC 1
ShMC 2
Lower cooling
unit
Slot 15
Slot 1
1 9 25
An LM4.0 hardware configuration with MIF blades in slots 13-14 is shown. The shelf holds the
circuit boards and consists of:
Guide rails
ESD discharge clips
Alignment/keying
Handle interface
Face plate mounting hardware
Midplane
Cooling units
9471 MME supports 1+1 blade redundancy. Mates are side-by-side, left to right.
Numbering:
Elements increase numerically from left to right, and from bottom to top. Hence: The bottom shelf
in cabinet 0 is shelf 0.
The leftmost slot is 1; the rightmost slot (for ShMC) is 15.
The ShMc are the exception: they increase numerically from top to bottom (1 and 2).
Note: The graphic shows the SAV2AB chassis. The newer chassis is SAV2AC. Key additions for
SAV2AC:
On the front of the chassis above the ShMC (where the ground point is shwon) there is a slot
for an optional chassis alarm card.
On the rear of the chassis, left side, there is an optional rear transition card with ports to an
external alarm system.
Neither of these features are currently used in the 9471 MME.
Shelf card positions

Slots 3-6 and 9-14 for
additional
processor/application
cards.
Slots 1-2 are
reserved for the
OAM Server (Shelf
0 only).
Dual Shelf
Management
Controllers in
slot 15.
OAM Server A
Slots 7-8: dedicated Ethernet

switch hubs (shelf 0 Hubs
include the MPH AMC cards
and RTM; shelf 1 does not).
OAM Server B
1 9 26

Card position guidelines for Shelf 0:

Slot
positions 7 and 8 are dedicated for the Ethernet Hubs, with RTMs at the rear of the
chassis in slots 7-8.
Two
half-size positions in slot 15 are reserved for the Shelf Management Controllers.
Diskful
blades (the OAM Servers) are placed at slot positions 1 and 2 (shelf 0 only).
Diskless
blades fill remaining slot positions, left to right beginning with slot 3.
For systems with 16-GB traffic processors, MIF blades are in slots 3 and 4; the remaining
traffic slots are for MAF blades.
For systems with 32-GB traffic processors, MIF blades are in slots 13 and 14 with RTMs.
The remaining traffic slots are for MAF blades.
For
a 300W chassis, each slot position can dissipate a maximum of 300 Watts.
For
a good air flow and cooling, empty slot positions must be closed with a filler (NBFILL).
At
the rear side, empty RTM positions also require a filler to be inserted (NAFILL).
Card position guidelines for Shelf 1:

Slot
positions 7 and 8 are dedicated for the Ethernet Hubs. Hubs on Shelf 1 do not have the
MPH AMCs or RTMs.
Two
half-size positions in slot 15 are reserved for the Shelf Management Controllers.
MME
processors fill the remaining slot positions from left to right beginning with slot 1 (all
dedicated for MAF blades).
For
a 300W chassis, each slot position can dissipate a maximum of 300 Watts.
For
a good air flow and cooling, empty slot positions must be closed with a filler (NBFILL).
At
the rear side, empty RTM positions also require a filler to be inserted (NAFILL).
OAM Server card architecture

Supports OA&M functions and graphical user
interfaces.
Single Board Computer with:
16 GB of memory
300 GB data storage disk.
OS is Red Hat Linux.
The mnemonic name for the 16-GB OAM Server is

FMO16JD.
1 9 27
The Northbound interface (NBI) is logically terminated on the OAM Server. Where copper
connections are used, the NBI may also be physically terminale on the OAM Server.
Single Board Computer has:
2x
quad-core 2.4 GHz processors (8 total cores) with 16 GB of memory
300
GB data storage disk inserted in the top AMC slot.
Update notes:
In LM4.0, a new diskful OAM Server blade with 16 GB of memory became available providing
increased storage capacity for Per Call Measurement Data (PCMD), Call Trace, and other data . New
systems are installed with the 16-GB blade, and operators may upgrade with no downtime.
Systems with pre-LM4.0 8-GB OAM Servers must upgrade to 16-GB OAM Servers before upgrading
to LM5.0 software.
Reference:
Details about the LEDs and ports are described in the 9471 MME Technical Description customer
document (418-11-200).
Serial Attached SCSI (SAS) is a computer bus that moves data to and the storage device.
The AMC cards are used in fixed configuration and are not field replaceable.

Ethernet switch blade (Hub)

Responsible for:
Internal communication
External communication to OA&M network and
lawful intercept
Connects to each blade via midplane.

Hardware:
Single-blade computer in switch-only mode
RTM for external communication
AMC supports MPH service
F0 and F1 support optional copper interfaces

to OA&M or LI network.
OS is MontaVista Linux.
1 9 28
Connection to Hubs
on second shelf.
The Layer 2 Ethernet hubs in the ATCA platform are responsible for internal and some external
communications.
All external communication is supported by the ROETHAA RTMs at the rear of the chassis behind
the hubs. This is the recommended configuration. However, if the external network cannot support
optical connectivity for OA&M and lawful intercept (LI) interfaces, copper interfaces F0 and F1 on
the hub front panel may be used.
All inter-host communication goes through the base switch (versus the fabric switch) on the hub.
The two Ethernet Hubs comprise a single-blade computer in switch-only mode. Slots 7 and 8 are
dedicated to the hub blades.
Each processor blade is connected through the midplane to the two Ethernet hub blades.
Each hub card also contains one HSPP4 AMC card to support the MME Packet Handler (MPH)
service and one NBAFILL filler.
The AMC cards are used in fixed configuration and are not field replaceable.
Note that connections to Hubs on a second shelf may be in place, even if no second shelf yet exists.
Hardware consists of:
One single-blade computer in switch-only mode
ROETHAA RTM for external communication
An HSPP4 AMC to support MME Packet Handler (MPH) service
document (418-11-200).

HSPP4 AMC to support MPH service

Houses the MPH service.
Inserted in AMC slots of Shelf 0 Hubs
only.
1 9 29

On the shelf 0 Ethernet Hub blades in an MME configuration, an AMC card houses the MME Packet
Handler (MPH) service, which logically terminates the SCTP, UDP and TCP layers from the
ROETHAA RTM external MME signaling connections.
OA&M and lawful intercept connections do not pass through the MPH.
The HSPP4 terminates and manages logical interface links with the MME, including:
S1-MME
(eNodeB) interfaces
S6a
(HSS) and S13 (EIR) interfaces
S11
(SGW) interfaces
S10
(MME) interfaces
UMTS/GSM/CDMA
interworking interfaces
This is a logical termination, not physical. The IP address for the link is assigned to the MPH service
and it terminates the protocol layers above layer 1, which is the physical layer. Interfaces are
physically terminated at the RTM.
NOTE: The AMC cards are used in a fixed configuration and are not field replaceable. The MPH
service is active on one Hub and standby on the other Hub. Hubs run in active-active mode.
Hardware consists of:
800MHz
2
processor with 16 cores
GB of DDR2 SDRAM
288
Mb of RLDRAM
ROETHAA RTM
ROETHAA RTM for Hub

Physically terminate external signaling and optical OA&M
connections.
Thirteen SFP interfaces support optical modules.
Port 12 (debug) may optionally host a copper SFP.
SFP module
connector
The mnemonic name for

this RTM is ROETHAA.
1 9 30
All external communication (signaling and optical OA&M) is supported by the ROETHAA RTM. This is
the recommended configuration. If the external network cannot support optical connectivity for
OA&M and lawful intercept (LI) interfaces, copper interfaces F0 and F1 on the hub front panel may
be used.
Thirteen small form-factor pluggable (SFP) interfaces supporting 1G optical modules are
configurable for MME signaling and OA&M. Each port is configurable for either Multi-Mode or SingleMode optical (a mix is supported). Ports are labeled 0 -12. Port 12 is reserved for port mirroring or
debugging. Hot swapping of SFP modules is not supported.
The two RTMs provide connections to each of the Ethernet hubs and HSPP4 AMCs on Shelf 0.
Messages from/to multilayer switches in the network arrive and exit at the RTM. The RTM transfers
the messages to the MPH or the Hub, depending on the destination:
The MPH service on the HSPP4 logically terminates the SCTP, UDP and TCP layers.
Lawful Intercept interfaces X1_1 and X2 terminate directly to the MIF application, via the Hubs.
OA&M messages terminate to the OAM blades via the Hubs.
Optical SFP modules: The Gigabit Ethernet interfaces use small form-factor pluggable (SFP)
modules for the physical ports. The RTM is made with a generic GigE port with no cable interface.
The physical port type is determined by the SFP module that the customer installs in the generic
hole. I.e. if the customer wants the port to be multi-mode fiber, they only need to install an MMF
SFP and connect the appropriate patch cord.
Copper SFP modules: A 1000Base-T Copper Electrical interface SFP Transceiver module can be
hosted on the ROETHAA RTM. This 1GB copper transceiver module is intended only for Integrated
Traffic Capture and Raw Debugging using port 12 Interface on the ROETHAA RTM. This
Copper/Electric Transceiver is not supported for OAM or any logical network interfaces.
Note: An LM4.0 hardware configuration with MIF blades in slots 13-14 is shown (from the rear view,
slot numbering begins on the right side). The RTMs on the back of the MIFs are not currently used.
Shelf Management Controller

ShMCs
Supervise all chassis elements.
Monitor health of all chassis
elements.
Monitor environment of chassis
(temperature, fans, voltage, etc.)
ShMC 2 ShMC 1
OS is Pigeon Point Linux
The mnemonic name for the ShMC is NBSHMC.

1 9 31
document (418-11-200).
Each ATCA chassis includes two ShMC controllers that run in active/standby mode. ShMCs supervise
all elements of the chassis (fan trays, blades, RTMs, air filters and Power Entry Modules (PEMs)
through intelligent Platform Management Bus (IPMB) and inter Integrated Circuit (I2C) connections.
The Shelf Management Controllers (ShMC) are positioned in the shelf management slot at the far
right of the chassis, and are numbered 1 on the top to 2 on the bottom.
The ShMC controller performs the following functions within the ATCA shelf:
Monitoring of temperatures and voltages for chassis components
Monitoring of blade and fan tray presence and fan speeds
Power supply status monitoring
Control of the power states for automated power sequencing and power supply inhibition
Control of blade power states and fan speed for automatic recovery in case of temperature
events
Management of the chassis through supporting scripts for system status and corrective actions.
Provision of interfaces for remote management
Logging of chassis status events
When a sensor detects an event, it reports the problem. The shelf manager can take action and
report the problem to an element or network manager. For example, one of the actions the ShMC
can take could be change the rotation speed of the fans, or more drastic such as powering off a
blade.
Hardware features:
Redundant pair of cards share slot 15 in active-standby mode
SNMP communication over Ethernet to/from other blades
Traffic processors: MAF

MME Application Function (MAF):
Provide mobility and session/bearer
management
Store UE Contexts in memory
Can be grown in pairs
1 9 32
MAF
The graphic shows 32-GB processor blades with MIF blades in slots 13 and 14. For 16-GB processor
blades, the MIF interface processors are in slots 3 and 4. The AMC cards shown on the MIF and
MAF blades are for future use.
The primary role of the MME Application Function (MAF) is to provide mobility and session/bearer
management for user sessions and procedures. The MAF also holds the VLR registry in memory.
document (418-11-200).

Interface processors: MIF

MME Interface Function (MIF):
Selects MAF to handle UE session.
Distributes messages to the appropriate
MAF.
Receives messages internally from the
MPH service.
Terminates/manages Lawful Intercept
interface.
1 9 33
MIF
The graphic shows 32-GB processor blades with MIF blades in slots 13 and 14. For 16-GB processor
blades, the MIF interface processors are in slots 3 and 4. The AMC cards shown on the MIF and
MAF blades are for future use.
Messages from the MIF that need to be sent out the external signaling links are passed over TCP to
the MPH, which bridges them to the appropriate external signaling layer, SCTP, TCP or UDP.
The MIF provides a load distribution function (LDAC) to select a MAF to handle a particular UE
session, which is performed primarily when end users attach or detach from the MME.
The MIF distributes messages from the external interfaces to the appropriate MME Application
Function (MAF) handling the session or procedure (eg, attach, detach) for a particular end user
equipment.
document (418-11-200).

Traffic and interface processors hardware details

16-GB processors (MIF and MAF)
Single Board Computer (FMO16JB) with:
2x Quad-Core processors running at 2.3 GHz
with 16 GB RAM
No AMC or RTM
32-GB processor (MAF)

Single Board Computer (FMO32MK) with:
with 32 GB of RAM
1x AMC with HSPP4
No RTM
32-GB processor (MIF)

Single Board Computer (FMO32MP) with:
with 32 GB of RAM
1x AMC with SS7 E1/T1/J1 and 31 links per
interface
SS7 RTM (RPCMCA) with 8 E1/T1 connections
The 32-GB processors are shipped

with new systems beginning in
LM4.0.
Existing systems are not upgraded.
OS is Red Hat Linux

1 9 34
When 16-GB traffic processor blades are used, the MIF cards are located in slots 3 and 4 of shelf 0
and do not have RTMs.
When 32-GB traffic processor blades are used, the MIF cards are located in slots 13 and 14 of shelf
0 and have RTMs. 32-GB MIF/MAF blades are installed with new systems in LM4.0 and later. 32-GB
blades are not required - LM4.0/5.0 software will recognize LM3.0 hardware. All MIF/MAF hardware
blade pairs must match (replace failed 16-GB with 16-GB blades, and failed 32-GB with 32-GB
blades).
SS7 AMC and HSPP4 AMC
The SS7 and the HSPP4 AMCs are not currently used. They will be leveraged in a future release
when combo (MME/SGSN) software is applied.
The SS7 AMC will provide SS7 protocol processing and will be used in conjunction with the MIF
blade to support the MME MIF/SS7 service. The SS7 AMC does not provide additional functionality
when used with the MIF in an MME-only configuration.
The HSPP4 AMC will provide IP Packet Processing and iPPU (Integrated Packet Processing Unit)
functionality to support SGSN bearer. The HSPP4 AMC does not provide additional functionality
when used with the MAF in an MME-only configuration.

ATCA shelf cooling units
The mnemonic name for the upper fan tray unit is SFT300AA.
The mnemonic name for the lower fan tray unit is SFB300AA.
The mnemonic names for the filters are NDAFF (front) and NDAFR (rear).
1 9 35

Each cooling unit consists of:

Two air filters:
One
for the blades (called NDAFF)
One
for the RTM (called NDAFR)
Two field replaceable fan trays

A
300W chassis has 12 fans per tray
The ShMC performs fan-speed monitoring and is the alarm interface

The first air filter is located on the lower front of the chassis. The second air filter is located on the
lower rear of the chassis. Two air filters, one for the blade, termed NDAFF, and one for the reartransition module (RTM), termed NDAFR, are provided at the intake. The first is located on the
lower front of the chassis the second is located on the lower rear of the chassis. To access the air
filters, its necessary to open the front or rear covers. Dust filters can be changed while the system
is running. Sliding system makes the operation easy.
The fan tray draws air from the bottom front side and pressurizes air to flow through the shelf. Air
then exits the shelf through dedicated rear upper exhaust. Each cooling unit control provides fan
speed monitoring and alarm interface.
If a fan fails, the controller adjusts the speed of the other fans to cool the unit until the fan tray can
be replaced. The whole tray is replaced (a single fan cannot be replaced). Each tray is powered
from the midplane on alternate power feeds.

Knowledge check: 9471 MME chassis

Please answer the following questions
about the chassis in the photo.
1. What blades are in the center slots?
Ethernet Hubs
2. What blades are in the far-right slots?

Shelf Management Controllers
3. Where are the OAM Servers?

Slots 1-2.
1 9 36


All external signaling messages enter and exit the 9471 MME using GigE
ports on the faceplate of the Ethernet Hubs.
True
False
False external signaling messages enter and exit the from the optical
ROETHAA RTM for the Hubs. Messages to the external OA&M
network may optionally terminate on the GigE ports on the faceplate
of the Ethernet Hubs if copper connections are used to the OA&M
network.
1 9 37


Is the OAM Server a diskful blade or a diskless blade?
Diskful - it includes a hard disk drive inserted into the AMC slot on the blade.
_______________________________________________________
1 9 38


Which of the following blades hosts the MPH service, which terminates
external signaling connections from the ROETHAA RTM?
A.
B.
C.
D.
E.
Ethernet Hub
HSPP4 AMC in the Hub
OAM Server
MIF
MAF
1 9 39
B The HSPP4 AMC in the Hub hosts the

Message Packet Handler (MPH) service. The
SCTP, UDP and TCP layers from the RTM are
logically terminated by the MPH service on the
HSPP4 blade. They are physically terminated at
the RTM.


Which blades host the MME graphical user interface?
A.
B.
C.
D.
E.
Shelf Management Controllers

OAM Servers
MIF
B- OAM Servers
MAF
Hubs
1 9 40

4 Cabling and connections
1 9 41
This topic describes the cabling and connections for the 9471 MME.

MME cabling and connections
External connections
RTMs behind the Ethernet Hubs terminate physical external transport.

Option: Hub front panel can be used for OA&M and Lawful Intercept copper
interface connections.
Internal connections
Provided by the ATCA chassis midplane and the blades.

Hubs coordinate distribution of internal message.
1 9 42
External connections
The ROETHAA RTMs behind the Ethernet Hubs terminate physical external transport interfaces for
the system.
The
RTM supports all external connections (signaling and OA&M) to the MME.
The
front panel of the Hub can be used for OA&M and Lawful Intercept copper interface
connections when optical interfaces are not supported.
Using
the RTM is recommended whenever possible.
Internal connections
Within a shelf, the intra-shelf communications are provided by the ATCA chassis midplane and the
blades.
Each
blade in an ATCA shelf can connect to other blades in the same shelf.
The Hubs coordinate distribution of internal messages to blades on their respective shelves.

System cabling
All internal wiring is done at the factory.
After system installation, cables to the customer network are connected.
1 9 43
All internal wiring is done at the factory before the cabinet is installed.
After system installation, external cables to the customer network are connected.
Signaling
and OAM cables are copper GigE or fiber optic cables.

Connectivity example
Copper OA&M connections (optional) will connect to the faceplate of the Hub.
DNS1
DNS2
CE 1
MME1
OAM
Midplane
OAM
OAM
MIF
H
U
B
7
R
T
M
MPH
MAF
MPH
ShMC
H
U
B
ShMC
R
T
M
CE 3
S1
CE 5
CE 7
CE 9
Hub in slot 7 = LSN0 (left-side, Eth0)
Hub in slot 8 = LSN1 (right-side, Eth1)
1 9 44
OAM
NTP
MIF
MAF
LI
eNB1
eNB2
eNBn
S11
SGW1
SGW2
S6a
HSS1
HSS2
S10
MME2
Customers edge routers or multilayer switches.

This slide provides one example of internal and network connectivity. Each MME connection
connects to a pair of customer edge routers or multilayer switches. The exact configuration on
the external side is customer-dependent. Not all RTM ports are shown. 1+1 GigE connections
are shown (1+1 is described in an upcoming slide).
LSN = Local Secure Network; CE = Customer Edge Router; MLS = Multilayer Switch
Each Shelf is equipped with 2 Hub Cards. Shelf 0 is also equipped with 2 HSPP4 cards for MPH
service and 2 RTMs.
Each Node Card and ShMC has an Ethernet link in the midplane to each of the two Hub Cards.
Each Hub RTM has 13 Gig-E (1000MB/s = 1Gb/s) faceplate ports available for external
communication
Four or more 1000Base-SX/LX physical connections from the customers IP network terminate
on each Hubs RTM to support signaling flow (subnets may be combined).
No single point of failure for communication.
Software within each Node Card monitors connectivity and chooses working paths.
Hubs are cross-connected to allow the MPH service to communicate with LSN0 and LSN1 local
networks on each Hub.
Internal communication for the ATCA is provided through the Hubs and the midplane Ethernet links.
The Hub Card in Slot 7 is the center of the Local Secure Network LSN0 star network.
The Hub Card in Slot 8 is the center of the LSN1 star network. (The terms LSN0, LSN1
interchangeble with left-side, right-side.)
In a multi-shelf configuration, the Slot 7 Hub Cards are linked; similarly the Slot 8 Hub Cards.
Both hubs are active and may serve any of the blades on a shelf.
10-Gig links between Hub Cards are used for cross-chassis connections.
External links: 1+1 configuration

MME1
midplane
OAM
OAM
MIF
H
U
B
7
MAF
1 9 45
Primary
(Active)
interface
CE A
L3
MPH
MIF
MAF
R
T
M
(primary)
Active
Secondary
MPH
ShMC
H
U
B
ShMC
Secondary
interface
R
T
M
CE B
L3
(secondary)
MLS = Multi-Layer Switch; L2, L3 = Layer 2 or 3. CE = Customer Edge Router.

The MME redundant GigE links configuration has the following features:
Redundant GigE links are not required on the same ROETHAA RTM.
Allows traffic on a GigE link on an RTM to be switched to a GigE link on the other RTM without
an MPH switch occurring.
Allows an MPH switchover without requiring a switchover of GigE links.
Two redundant links consist of one GigE link on each MPH in primary/secondary configuration.
The primary link is always on the active MPH and transmits and receives traffic. The two links are
connected to two separate adjacent MLS.
The active MPH can receive traffic from the network on either primary or secondary interface.
However, it strongly recommended to set forwarding of incoming traffic in such way that MME
receives the traffic on the primary interface.
The graphic shows the active MPH has a primary GigE link in GigE port 1 for signaling traffic. Its
secondary GigE link on the standby MPH is connected from port 2 to the secondary MLS. Similarly,
other redundant link groups for signaling and OA&M will have two links: one primary and one
secondary link.
By default the interfaces on Hub 7 (in slot 7) are connected to the primary MLS. If the MME loses
connectivity to the primary MLS, then the MME uses the interfaces on Hub 8 (slot 8). The traffic
received on the secondary is forwarded by to the active MPH. If a fault is detected on the primary
route (or route that is carrying traffic) then the MME switches traffic to the other route. No
switchover of MPH is required as traffic from the secondary route can be forwarded to the active
MPH.

External links: 1+3 configuration

MME1
midplane
OAM
OAM
H
U
B
R
T
M
MLS A
MIF
MPH
MIF
MAF
MAF
ShMC
Active
Standby
(master)
L2 L3
Active
Standby
MPH
H
U
B
R
T
M
VRRP
Standby
MLS B
(standby)
Standby
L2 L3
ShMC
1 9 46
MLS = Multi-Layer Switch; L2, L3 = Layer 2 or 3.

Four redundant links: consists of two GigE links on each MPH. The two links are connected to
two separate MLS in VRRP configuration. One link is active and three are standby.
The active link is always on the active MPH and transmits and receives traffic.
One of the major advantages of two GigE links on the same MPH is that if the active link loses
connection to its MLS, then it fails-over to its standby link which is connected to a different MLS
avoiding the need for MPH failover. If the active link fails, MME attempts to failover to the standby
link on the same MPH. If the standby link is down on the active MPH then MPH failover occurs.
The graphic shows the active MPH has an active GigE link in GigE port 1 for signaling traffic. Its
standby GigE link on the active MPH is connected from port 2 to the standby MLS. The standby
MPH has standby links on ports 1 and 2 connected to the master and standby MLS, respectively.
Similarly, other link groups for signaling and OA&M may have four links: one active and three
standby links.
Note: Conversions from 1+3 GigE configuration to 1+1 GigE configuration is performed by AlcatelLucent Tier3/Tier4 personnel.

Cabling example: 16-GB application nodes - front

Ethernet cables to
alarm card in PDU.
10GigE link (port UPF) connects hubs so

that HSPP4 modules are on internal
networks for both left and right hubs.
Copper cable for
OAM&P and
Lawful Intercept
may optionally
connect to the
GigE ports at front
of the Hubs.
10GigE port (port
UPB) for interchassis
communication
when two shelves in
system.
Front view - Hubs in slots 7, 8

1 9 47
The intra-hub connection uses the top 10GigE port (UPF) on the front panel of the hub blade to
connect the hubs. The connection is needed so that the HSPP4 modules are on both Local Secure
Networks (LSN) 0 (left hub) and 1 (right hub). LSN0 ad LSN1 are described later in this training
module.
The lower 10GigE port (UPB) on the front panel of the hub blade is used for inter-chassis
communication when there are two shelves in the system.
For a chassis-only configuration, there are no cables to the PDU.

Cabling example: 32-GB application nodes front

Copper cable for
OAM&P and Lawful
Intercept are
connected to the
GigE ports at the
front of the Hubs in
this example
10GigE link (port
UPB) for inter-chassis
communication when
two shelves in
system.
Ethernet cables
to alarm card in
PDU.
1 9 48
Front view - Hubs in slots 7, 8
10GigE link (port

UPF) connects hubs
so that HSPP4
modules are on
internal networks for
both left and right
hubs.
The intra-hub connection uses the top 10GigE port (UPF) on the front panel of the hub blade to
connect the hubs. The connection is needed so that the HSPP4 modules are on both Local Secure
Networks (LSN) 0 (left hub) and 1 (right hub). LSN0 ad LSN1 are described later in this training
module.
The lower 10GigE port (UPB) on the front panel of the hub blade is used for inter-chassis
communication when there are two shelves in the system.
For a chassis-only configuration, there are no cables to the PDU.

Cabling example: 16-GB application nodes - rear

Optical cables to/from external
destinations will connect to the
ROETHAA RTM.
Yellow
ground cable
Power
cables
Rear view - Hubs in slots 8, 7

1 9 49
The ROETHAA RTM provides thirteen (13) SFP faceplate interfaces capable of supporting optical
(1G) modules. Fiber is routed through the top of the frame, along the sides, and over to the RTM.
Port 12 may optionally host a copper SFP for traffic capture and debugging.
The exact number of interfaces used and configuration is customer-dependent. Port zero is typically
used for OAM and/or DNS and/or Lawful Intercept (LI) networks.
Note that slot number 1 is on the right side when viewed from the rear.

Cabling example: 32-GB application nodes - rear

Optical cables to/from external
destinations will connect to the
ROETHAA RTM.
Yellow
ground cable
Power
cables
Rear view - Hubs in slots 8, 7

1 9 50
The ROETHAA RTM provides thirteen (13) SFP faceplate interfaces capable of supporting optical
(1G) modules. Fiber is routed through the top of the frame, along the sides, and over to the RTM.
Port 12 may optionally host a copper SFP for traffic capture and debugging.
The exact number of interfaces used and configuration is customer-dependent. Port zero is typically
used for OAM and/or DNS and/or Lawful Intercept (LI) networks.
Note that slot number 1 is on the right side when viewed from the rear.

Signaling connectivity flow example: Normal flow

MME1
midplane
OAM
OAM
MIF
4
5
H
U
B
7
R
T
M
MLS A
MIF
MAF
MPH
MAF
In this example, 1+1 GigE links are configured.

Refer to the 9471 MME Technical Description
(418-111-200)for message flow with1+3 GigE
links.
3
MPH
S1
L3
MLS B
Radio
access
network
eNB1
eNB2
eNBn
L3
ShMC
H
U
B
ShMC
R
T
M
6 Return message is sent in the reverse path.

The OAM flow to/from the OAM Server follows a
similar path, except the MIF and MAF are not used.

1 9 51

Configuration consists of pairs of optical links for MME signaling traffic and optical links or copper
GigE links for OA&M traffic connected to a pair of adjacent Multilayer Switches or Edge Routers
(MLS/ER) deployed in VRRP configuration.
Example signaling flow from eNodeB:
1.
eNodeB sends a message to the L3 switch on MLS A.
2.
The message from MLS A arrives at the active S1-MME signaling interface on the ROETHAA RTM.
3.
The RTM transfers the message to the active MPH on the Hub.
4.
MPH switches the message over the midplane (internal LAN) to the MIF.
5.
MIF selects a MAF (uses previously selected MAF if UE is already attached) and sends the message to the
MAF via the Hub.
6.
The MAF sends a return message in the reverse direction: to the MIF via the Hub, the MIF sends the
message to the RTM via the MPH on the Hub, then the messages goes out from the active signaling
interface on the RTM to the L3 switch.
OAM flow
The flow to/from the OAM Server follows a similar path, except the MPH, MIF, MAF are not used:
1.
Message from the MLS connected to the 5620 SAM arrives at the MME Hub via the ROETHAA RTM on the
active OAM interface.
Note: For customers utilizing a copper interface, the message from the 5620 SAM arrives by way of the
faceplate of the Hub instead of the RTM.
2.
The MME Hub switches the message to the OAM Server over the midplane (OAM messages do not use the
MIF).
3.
Return messages go in the reverse from OAM Server to MME Hub, to the RTM, then out from the active
OAM interface to MLS.

Signaling connectivity flow example: Primary interface fails

links.
MME1
midplane
OAM
OAM
MIF
5
6
MIF
H
U
B
7
4
ShMC
ShMC
H
U
B
X
MLS A
R
T
M
S1
L3
MPH
MPH
MAF
MAF
R
T
M
2
3
MLS B
Radio
access
network
eNB1
eNB2
eNBn
L3

1 9 52
A heartbeat mechanism (either using periodic Allocation Retention Priority (ARP) requests, periodic
pinging, or BFD packets) is supported between MME and MLS to monitor MME connectivity to
the first hop router.
In this example, there is a primary GigE link on the active MPH and a secondary GigE link to the
standby MPH. The primary interface becomes unavailable.
Signaling message flow when a Primary Interface failure occurs
1. eNodeB sends a message to the L3 switch on MLS A.
2. The link from MLS A to the ROETHAA RTM is down, so the message is sent to MLS B. MLS B
selects a port on the redundant ROETHAA RTM.
3. Message from MLS B arrives at the active S1-MME signaling interface of the RTM.
4. The MPH associated with Hub 7 is the active MPH, so the message is sent from the RTM (8) to
Hub 8, and then transferred to the MPH on Hub 7.
5. The MPH switches the message over the midplane (internal LAN) to the MIF.
6. MIF selects a MAF (uses previously selected MAF if UE is already attached) and sends the
message to the MAF via the Hub.
7. The MAF sends a return message in the reverse direction.

Signaling connectivity flow example: Hub 7 fails

links.
MME1
midplane
X
H
U
B
OAM
OAM
MIF
MIF
MAF
ShMC
MLS A
MPH
H
U
B
S1
L3
ShMC
MPH
MAF
R
T
M
2
MLS B
R
T
M
Radio
access
network
eNB1
eNB2
eNBn
L3

1 9 53
A heartbeat mechanism (either using periodic Allocation Retention Priority (ARP) requests, periodic
pinging, or BFD packets) is supported between MME and MLS to monitor MME connectivity to
the first hop router.
In this example, Hub 7 has failed so the primary interface and active MPH are switched to Hub 8.
Signaling message flow when Hub failure occurs
1 eNodeB sends a message to the L3 switch on MLS A.
2 The link from MLS A to the ROETHAA RTM is down since the Hub is down, so the message is sent
to MLS B. MLS B selects a port on the redundant RTM.
3 Message from MLS B arrives at the active S1-MME signaling interface of the RTM.
4 The RTM transfers the message to the MPH.
5 The MPH switches the message over the midplane (internal LAN) to the MIF.
6 MIF selects a MAF (uses previously selected MAF if UE is already attached) and sends the
message to the MAF via the Hub.
7 The MAF sends a return message in the reverse direction.

Temporary cabling
Serial connections required in some procedures need the following cables:
Mini-USB to female DB-9 cable (provided with the system) to connect to the
serial ports on cards.
During system installation:

A straight Cat-5 Ethernet cable is connected from the laptop to the ge1 port of
OAM Server.
1 9 54
For procedures that require serial connections, customers will need the following cables:
A
mini-USB to female DB-9 cable is provided with the system to connect to the serial ports
(RS232) on cards.
If your laptop does not have a DB-9 port, you will also need a USB to male DB-9 serial
cable with corresponding drivers loaded on the laptop.
The USB to male DB-9 cable will need to be connected with the mini-USB to female DB-9
cable. The USB end connects to the laptop while the mini-USB end connects to the
faceplate.
During system installation:

A
straight Cat-5 Ethernet cable is connected from the laptop to the ge1 port of OAM Server to
FTP the software package to the OAM Server A (first slot).
Serial connections are those made through the serial ports at the faceplate of the blade. This
type of connection may be needed because the blade does not yet have an IP (for example, during
system installation), or because IP connectivity between the laptop and the blade may be lost
during a particular procedure (for example replacement of a ShMC).
Before system installation, serial-over-LAN is not yet activated.

Knowledge check: Cabling and connections

Each blade in an ATCA shelf can connect to other blades in the same shelf
___________________________________.
A. by cables pre-wired internally at the factory
B. by cables connected at the faceplates of the blades
C. through connectors at the midplane
C - through connectors at the midplane
1 9 55

Knowledge check: Cabling and connections

Draw connector lines on the following graphic to explain how the
Hubs are connected to the other blades in the shelf.
MME1
OAM
OAM
Each blade, including

the ShMC, connects to
each Hub via a
midplane. The Hubs
are not connected to
each other.
H
U
B
R
T
M
MIF
MIF
MPH
MAF
MPH
MAF
ShMC
H
U
B
R
T
M
ShMC
1 9 56

5 Failure scenarios
1 9 57
This topic describes how the 9471 MME proceeds when an S1-MME or S11 link fails.
Fault management is described in the 9471 MME OAM&P training course.

What happens if 9471MME S1-MME link fails? (1 of 3)
1. MME/eNodeB detect link failure from SCTP heartbeat failure.

2. MME marks link OOS and raises an S1-MME link down alarm.
3. UEs served by associated eNodeB are transitioned to Idle state:
Bearers released at SGW/PGW.

Active sessions dropped.
eNodeB releases RRC connection and deletes UE context.
4. UEs must re-establish connection via TAU or Attach.
MM
E
n
S11
S10
MME
1
S11
S1-MME
S1-U
SGW
n
SGW
1
S5
PGW
SGi
PDN
eNodeB
1 9 58

This scenario describes the actions of the MME when one or more S1-MME links fail at the MME.
Links may fail for various reasons, including: the MME is out of service (OOS) or initializing, the
heartbeat is lost due to network issues, the link is locked, provisioning data is incorrectly changed,
or there is a software failure.
When MME or S1-MME link goes out of service, the MME:
1. The S1-MME link to the eNB is monitored at SCTP layer via MME-invoked heartbeats and by eNBinvoked heartbeats.
HB interval is provisionable (default 30 seconds)
Retry Number when no HB ack is provisionable (default 5)
Min/Max Retransmit Timeout is provisionable (defaults 50/400ms)
2. When the timeout is reached, the MME marks the link OOS and raises a link-down alarm (major
if only a single S1-MME link down).
What happens to UE connections:
3. UEs served by the associated eNB that were in the Connected state are transitioned to the Idle
state.
Bearers are released at the SGW/PGW.
All active sessions are dropped.
eNB releases RRC connection and deletes UE context for affected UEs.
4. UEs must re-establish via TAU, or Attach.
UE data on the failed MME may be lost, or will eventually be purged.

What happens if 9471 MME S1-MME link fails? (2 of 3)

5.
6.
7.
8.
If UE attempts Service Request, eNodeB selects another MME in pool.

Service Request fails since GUTI points to the old MME.
UE performs TAU or Attach and is relocated to MME with active link.
eNodeB adjusts for the MME capacity (minus the failed MME) and
spreads UEs across the remaining MMEs in the pool.
MM
E
n
S1-MME
S11
S10
MME
1
S11
S1-U
SGW
n
SGW
1
S5
PGW
SGi
PDN
eNodeB
1 9 59
UE reconnection (assuming MME Pooling):

5. UEs attempt to re-connect, and the eNB selects one of the remaining available MMEs in the pool.
6. The service request will fail since the eNB will direct the service request to an active MME but
the GUTI will point to the old MME.

Network initiated Service Request will also fail until UE establishes bearers via an MME with an
active link.
7. TAU or new Attach will result in relocation to an MME with an active link.
8. UEs attached to the other MME(s) are spread across the pool via round robin adjusted for MME
capacity (weight factor) without the failed MME.
The other MME(s) are likely to experience high signaling load as the UEs all register.
The other MME(s) monitor the attach rate, as well as other overload parameters (CPU, Memory, UE
Context database utilization). Overload management is described in the 9471 MME load
distribution and overload condition management section of this course.

What happens if 9471 MME S1-MME link fails? (3 of 3)
9. MME service is restored eNodeB re-establishes the SCTP association.

10. MME sends relative capacity to eNodeB.
11. eNodeB uses normal selection process. Over time, MME loads become
equal.
MM
E
n
S1-MME
S1-U
S11
S10
MME
1
S11
SGW
n
SGW
1
S5
PGW
SGi
PDN
eNodeB
1 9 60
S1-MME service restored:

9. The eNodeB periodically attempts to re-establish the SCTP association. Once MME service is
restored, the eNodeB is able to successfully establish the association.
10. The MME sends relative capacity information to the eNodeB.

11. New UE attachments are slowly grown on the recovered MME through normal eNB selection
process (round robin/MME capacity weighting). Over time, the MME loads will be relatively equal
again.
Recovery time
A fault is detected and link recovered in less than .5 seconds.
Switchover times for MME links, cards, and when performing SUs are listed in the 9471 MME
Technical Description (418-111-200).

What happens if an S11 link fails? (1 of 2)
1. MME detects link failure from GTP-C heartbeat failure.

2. MME marks link OOS and raises an S11 link down alarm.
3. MME initiates a detach with reattach required for CONNECTED UEs
that are assigned to the SGW.
The UE initiates the reattach.
MM
E
n
S11
S10
MME
1
S11
S1-MME
S1-U
SGW
n
SGW
1
S5
PGW
SGi
PDN
eNodeB
1 9 61

When an S11 link goes out of service:

1. The MME detects link failure from GTP-C heartbeat failure. As with S1-MME links, the heartbeat
interval, number of retries, and retransmit timeout is provisionable.
2. When the timeout is reached, the MME marks the link OOS and raises a link-down alarm. A
major alarm is issued when only a single S11 link is down.
What happens to UE connections:

3. The MME initiates a detach with re-attach required for CONNECTED UEs that are assigned to
the SGW. Upon detach, all bearers associated with the UE are removed, and the state of the UE
is changed to deregistered.
The UE initiates a re-attach.
No action is taken on IDLE UEs assigned to the SGW until they initiate a Service Request (SR) or
Tracking Area Update (TAU). Then the MME rejects the SR or TAU, forcing the UE to re-attach.
Additional information: If the UE is in the connected state and the S11 link goes down, the
MME assumes that the SGW has detected that the link is down as well. When the SGW detects
that the S11 link to an MME is down, the SGW deletes all bearer context data for the UEs
associated with that MME. So the session data with bearer information will be deleted. Refer to
3gpp standard 23.007 under section 16.1.1: Restoration Procedures.
In the Alcatel-Lucent implementation, both the SGW and MME treat the S11 link down event the
same as if they had detected a restart of the neighboring NE. Since the bearers will no longer
be valid, the MME will send a detach request to all UEs associated with the impacted SGW so
that these UEs can attach again and potentially make use of a different SGW to support call
traffic.

What happens if an S11 link fails? (2 of 2)
4. MME performs an SGW relocation to another SGW.

5. When the S11 link returns to service, the MME uses normal methods to
select SGWs.
MM
E
n
S1-MME
S11
S10
MME
1
S11
S1-U
SGW
n
SGW
1
S5
PGW
SGi
PDN
eNodeB
1 9 62
UE reconnection (assuming SGW Pooling):

4. The MME performs an SGW relocation for affected UEs and selects another SGW that is
assigned to serve the tracking area Identity (TAI) of the eNodeB.

Note that on subsequent attach requests, the MME excludes the old SGW and selects another
SGW that is assigned to serve the TAI of the eNodeB.
S11 service restored:

5. When the S11 link returns to service, the MME uses normal methods to select from the pool of
SGWs. Over time, the SGW loads become equal.

Recall from an earlier lesson that the MME cycles through the SGWs in the pool or across pools
associated with a TAI in round-robin fashion.

Knowledge check: 9471 MME failure scenarios

1. If a single S1-MME link fails, the 9471 MME may still be up and
handling calls for other eNodeBs.
True
False
True.
2. If the 9471 MME initiates a detach with re-attach required, it is

up to the eNodeB to initiate the re-attach.
True
False
False. The UE initiates the re-attach.
1 9 63

Exercise: Identify components

A
If you have access to a lab, go to the lab to

identify the 9471 MME components listed
below. If not, use the photo.
Frame components
C D
E
A. PDU
B. ATCA chassis
Chassis components
C. OAM Server
D. Interface or traffic processor
E. Ethernet Hub
F. ShMC 1
G. Lower fan tray
G
1 9 64

This module described the 9471 MME hardware and how it is built
from common platforms:
The 5400 LCP platform

9471 MME hardware architecture
Power distribution
Chassis components
Cabling and connections
1 9 65

Locate and explain the function of the key 9471 MME components
Describe how 9471 MME components are physically connected
1 9 66

References
related to the 9471 MME hardware:
9174 MME Technical
Description
Describes the MME hardware components, LEDs,

cabling, interfaces, and technical specifications.
(418-111-200)
9471 MME OAM&P

(418-111-201)
Describes concepts and procedures to perform MME

OA&M tasks.

1 9 67

End of module
9471 MME Hardware
1 9 68

Section 1
9471 MME Overview
Module 10
9471 MME Software

Technical Overview

Blank page
1 10 2
9471 MME Overview 9471 MME Software

Document History
Edition
Date
Author
Remarks
01
YYYY-MM-DD
First edition

Module objectives
Describe the services provided by the ATCA and 5400 LCP platform software
elements
Explain the functions of the 9471 MME software components
Identify the key tables of a UE context
1 10 3
This module describes the software components of the 9471 MME system.

Table of Contents
1 Software overview
2 Services provided by the 5400 LCP
3 MME software architecture details
4 UE context
1 10 5

Page
7
13
26
35
1 Software overview
1 10 7
This topic identifies the software functions provided by the ATCA platform, the 5400 Linux Control
Platform (LCP), and the 9471 MME.

Software and OA&M provided by platform
1 10 8
SW Platform
9471 MME
SW
5400 LCP SW
Alcatel-Lucent
ATCA common
chassis SW
HW OS
Installation
Internal communication
Hardware monitoring (disk, power, fan, etc.)
Hardware management
Initialization
Configuration
Platform management (GUI)
Fault recovery/ escalation
Logging
Alarms
SW Upgrade
Redundancy/High availability
Overload
Security
Memory Management
Database
Performance measurements
Hardware diagnostics
Software tools
System Integrity (asserts, data audits, etc.)
System Backup and restore
Signaling software (SIP, Diameter, etc.)
Most of the OAM&P functionality is provided by the platform.

The first 4 functions are provided by the ATCA platform.

RedHat Linux
ATCA
Platform services
9471 MME
SW
5400 LCP SW
Services:
MI
5400 LCP SW
CNFG
AlcatelLucent
ATCA
common
chassis SW
SNS
RedHat Linux
ATCA
1 10 9
These three key services are hosted on the OAM Server blade:
Management Interface (MI) service
Local
graphical user interface (MI GUI)

SNMP manager function
Northbound interface to other network subsystems
Network Timing Protocol (NTP)
Internal Domain Name Service (DNS)
Configuration (CNFG) management service
Stores
configuration databases
Collects alarms from all servers and forwards to MI service
Collects performance management data from all servers and forwards to MI service
Performs as a LogServer
Collects software errors and debug data
Provides the REdundancy Manager (REM) system monitor function
Controls active/standby state of the diskless hosts
Performs system audits
The Shared Network Service (SNS)
Provides
access to an external DNS server.

Application services
9471 MME
SW
9471 MME SW
Services:
MPH
5400 LCP SW
MIF
AlcatelLucent
ATCA
common
chassis SW
MAF
OAM Server:
PM
Call trace
PCMD
1 10 10
RedHat Linux
ATCA
MME Packet Handler (MPH) service is hosted on HSPP4 AMC cards on the Hubs.
Provides the interface to the external entities (eNodeB, SGW, HSS, EIR, another MME,
SGSN).
MME Interface Function (MIF) service is hosted on the traffic blades in slots 13-14.
Provides load balancing: assigns UEs to a particular MAF during Attach; distributes
messages from external interfaces to the appropriate MAF handling the session or
procedure for a particular UE.
Manages the link service states.
Provides paging broadcast services when a UE needs to be paged.
Terminates and manages all Lawful Interface links.
If Multimedia Broadcast and Warning Delivery Message Delivery applications are
used, the MIF performs broadcast functions.
MME Application Function (MAF) service is hosted on application blades in slots 3-6 and 9-12.
Provides session/bearer management for user sessions and procedures.

Stores UE context data in memory.
Responsible for selecting an SGW.
OAM Server functions specific to the 9471 MME:
In addition to standard LCP functions, the OAM Server also:

Is the primary location for Performance Monitoring collection, analysis, and
forwarding.
Coordinates the start/stop of call trace and provides temporary storage for call trace
data.
Provides temporary storage of Per Call Measurement Data (PCMD) files.
Software component redundancy

Software and databases are fully redundant (active/standby)
Redundancy is controlled by RCC reliability control feature.
Stable transactions are unaffected in the event of a component switchover.
1 10 11
All
MI
(active)
MI
(stby)
CNFG
(active)
CNFG
(stby)
SNS
(active)
SNS
(stby)
OAM Server 1
OAM Server 2
software components and databases are fully redundant (active/standby)
Infrastructure designed to support 1+1 configurations
Databases support peer-to-peer replication
Software
component redundancy is centrally controlled by the Reliable Cluster Computing

(RCC) reliability control feature.
Active
software component checkpoints per-transaction info to standby component over IP

connections
Software
Stable
supports an escalation strategy intended to recover at the lowest level possible.
transactions are unaffected in the event of a component switchover
Reliable Cluster Computing (RCC) software provides support for monitoring and restart of the server
software and hardware.

Knowledge check: Software

Place a checkmark next to software that is specific to the MME
functionality.
A. MI
B. MIF
C. CNFG
D. SNS
E. MAF
F. MPH
1 10 12

2 Services provided by the 5400 LCP
1 10 13
This topic provides additional details about the key services provided by the 5400 LCP: MI service,
CNFG service, and Shared Network Services.

Services provided by 5400 LCP
5400 LCP
MI
Service
CNFG
Service
Product
applications
and services
SNS
Service
Diskless application processors

(MME MIF and MAF blades)
OAM Server
1 10 14

LCP = Linux Control Platform

SNS = Shared Network Services
DNS = Domain Name Server
The 5400 LCP requires two services as the basic building blocks in order to have an operational
Control Platform:
Management
Interface (MI) service
Configuration
(CNFG) service
In addition, the following service is provided by the platform:

Shared
Network Services (SNS) supports external DNS queries
The CNFG, MI, and SNS services are hosted on the OAM Server blade.

Service functions provided by the MI
MI
service
SNMP
Manager
NTP
Northbound
interface
DNS
MI
Agent
MI-Agent GUI
1 10 15

The Management Interface (MI) provides the following functions:

Main
maintenance interface from which to perform OA&M functions (MI-Agent)
HTTP-based webserver to maintain the 5400 LCP and its related sub-network elements
Provides access to command line interface (CLI)
SNMP
manager function
Northbound
interface to other element or network subsystems
Network
Timing Protocol (NTP)
Internal
Domain Name Service (DNS)
Notes:
MME application parameters are provisioned from the 5620 SAM.
The term northbound refers to upstream management systems such as the 5620 SAM.
External NTP is not required.

SNMP Manager function
MI
service
The SNMP manager allows the MI service to:

Collect fault and performance management information.
SNMPv2
SNMP
Manager
MI service
OAM Server
1 10 16
SNMP
Collector
SNMP
Traps
CNFG service
The Simple Network Management Protocol (SNMP) manager function allows the MI service to
Collect
fault and performance management information about the Alcatel-Lucent LCP and the
related sub-network elements

Northbound interface
PM
FM
MI
service
The NBI allows the MI service to:
RMT
Exchange information with the other network

or element management systems.
ssh
sFTP
EMS
(5620 SAM)
ssh
XML/sFTP
SNMPv3
ssh
SNMPv2
SNMP
Manager
SNMP
Collector
MI service
SNMP
Traps
CNFG service
OAM Server
1 10 17

The LCP uses SNMPv3 to provide security between the LCP and northbound systems.
NMS = Network Management System
EMS = Element Management System
PM = Performance Measurement, or Performance Management
FM = Fault Management
RMT = Remote Maintenance Terminal
The network management system for the 9471 MME is the 5620 Service Aware manager (SAM).

Network Time Protocol
MI
service
The LCP components are usually

synchronized as follows:
MI service on the OAM Server is
synchronized with an external NTP
server in the customer network*.
OAM
Server
Other hosts
MI service
All other diskful and diskless hosts are

synchronized to the OAM Server.
External
IP
NTP server
in
customer
network
*External NTP is not required.

1 10 18
Network Time Protocol (NTP) is an Internet standard protocol that is used to synchronize
computer clock times in a network of computers.
In common with similar protocols, NTP uses Coordinated Universal Time (UTC) to synchronize
computer clock times to a millisecond, and sometimes to a fraction of a millisecond.
Timing synchronization: The MI service on the OAM Server derives its timing from the external
NTP server located in the customers network.
All timing for the diskful and diskless hosts in Alactel-Lucent 5400 LCP is derived from the OAM
Server.
IP addresses: Up to three external IP addresses can be configured on the MI for NTP service.
These are configured during system installation.
Benefits of pointing to the OAM server as NTP server:
Timestamps
applied to events are synchronized among the MI GUI and the individual
components.
If
the primary NTP server needs to be changed, only the MI host would need to be reconfigured to move it to the new NTP server

Internal Domain Name Service
MI
service
The 5400 LCP manages DNS entries in its internal DNS system on the MI.
Examples:
When a port is provisioned, the internal DNS is updated with the ports Fully
Qualified Domain Name (FQDN), IP address, and port.
The internal DNS is updated as components and ports are grown, degrown, or
go out of service and back in service.
1 10 19
The
5400 LCP self-creates, maintains, updates, and deletes the LCP related DNS entries in its
internal DNS system on the MI (BIND 9.4.2).
When
a port is provisioned, the internal DNS is updated with the ports Fully Qualified Domain
Name (FQDN), IP address, and port.
The
internal DNS is updated as components and ports are grown, degrown, or go out of
service and back in service.
Berkeley Internet Name Domain (Bind) is the most commonly used DNS server.

Service functions provided by the CNFG
CNFG
service
PM
Host
Config
database
Redundancy
Manager
Log
Server
Secondary
DNS
System
Audits
SNMP
Collector
(alarms)
1 10 20

The Configuration (CNFG) service provides the following services:

Stores
configuration databases
Collects
alarms from all servers and forwards them to the MI service
Collects
performance management data from all the servers and forwards to the MI service
Performs
Collects software errors and debug data
Provides
the REdundancy Manager (REM) system monitor function
Controls active/standby state of the diskless hosts
Performs
Acts
as a LogServer
system audits
as a secondary DNS, controlled by the DNS on the MI service.

CNFG data collection
PM
FM
CNFG
service
RMT
EMS
SNMPv3
sFTP
SNMP
Msg
PM
files
5400 LCP
SNMPv2
SNMP
Collector
PM
Host
Proprietary protocol
SNMPv2
SNMP
Traps
Log
Server
MI-Agent
MI service
PM
Local
Agent
Logger
CNFG service
OAM Server
1 10 21

NMS = Network Management System

EMS = Element Management System
PM = Performance Measurement, or Performance Management
FM = Fault Management
RMT = Remote Maintenance Terminal
The
CNFG service collects alarm, PM, and log data from applications on other hosts in the LCP.
User
Data Protocol (UDP) is used by the CNFG to retrieve PM data from the various hosts.
Proprietary Socket is used for communication.
The MI uses FTP to retrieve XML files and logs from the various hosts.
SNMP
is used for fault management data collection.

Alarms (SNMP messages) are forwarded to the EMS by the MI service.
SNMP trap is sent to the EMS each time a new XML file for performance measurements (PM)
is generated.
Log
PM files can optionally be retrieved by the EMS.

files are not forwarded to the EMS; users may use FTP or sFTP to retrieve them.

+
+
DNS query using SNS service
SNS
Service
The SNS provides access to an external DNS server.

4
DNS sends response to SNS service.
It is cached and then sent to the
MAF aDNS software and cached,
then sent to MAF application.
Example
5400 LCP
DNS request
DNS request
SNS
Service
External
Customer
DNS
DNS response
Unbound
MAF
aDNS
DNS response
1 10 22
aDNS SW on MAF checks
2 cache; if not there, forwards
MIF
request to SNS (Unbound) on

OAM Server.
aDNS
OAM Server
3
MAF makes DNS request

to aDNS software.
SNS Service checks cache; if not

there, DNS query sent to external
authoritive DNS.
Diskless
application processors
The SNS service provides an external fixed IP address to communicate with a operators DNS
server, which is the authoritative server for the resource records used by MME. The 9471 MME
can be configured with one or more remote DNS clients (each must be able to resolve the same
queries). If the default gateway configured on the SNS service host does not allow
communication to a remote DNS server because the DNS server is on a different subnet, then a
static route to the DNS server subnet must be defined.
Example, during the Attach procedure, if the MAF needs the IP address of an SGW:
1. The MAF application makes a DNS request.
2. The request is sent to the aDNS software on the MAF, which checks to see if response is cached
and time-to-live has not expired. If not cached, MAF aDNS service forwards the request to the
OAM Server SNS service (which is another Unbound resolver that checks its cache).
3. If SNS Unbound does not have a response, the DNS query is forwarded to the external DNS
authoritative server. An internal Unbound algorithm randomly selects which SNS Unbound
resolver is used to make the external query.
4. The response is sent back from the DNS server to the SNS where it is cached, then sent to MAF
aDNS software where it is also cached, then to the MAF application.
SNS service is active/active on both OAM Servers. The IP is fixed.
Unbound: a validating, recursive, and caching DNS resolver developed by NLnet Labs. Unbound
software is a recursive DNS client on the OAM Server.
aDNS: asynchronous-capable DNS client library/utilities, published by the Free Software
Foundation. aDNS is a DNS client on the MIF and MAF.
Time-to-live: Theres a column labeled TTL for each record. The MME first looks for a record in
cache; if it is there and the TTL has not expired, that record is used. It is recommended that the
operator set the TTL high so as to reduce the number of external DNS queries (hours or even
days).

Knowledge check: MI and CNFG services

Identify which service functions are provided by the MI service and which
are provided by the CNFG service. (Some functions may be provided by
both services).
MI service functions
CNFG service functions
a)
OA&M user interface
b)
SNMP
c)
Configuration database
d)
Collect measurements and alarms

from all hosts
e)
System audits
MI service = a, b
CNFG service = b, c, d, e
1 10 23


Which 5400 LCP service interfaces with the element management system
(5620 SAM) using SNMPv3?
A, MI service
A. MI service
B. CNFG service
C. Both MI and CNFG services
1 10 24


The network time for the MIF and MAF blades is synchronized with
___________________.
A. an external NTP server
B. the OAM Server
C. the CNFG service
B, OAM Server. The OAM Server is synchronized with an
external NTP server.
1 10 25

3 MME software architecture details
1 10 26
This topic provides additional details about the the software required for the 9471 MME to function
in the LTE network.

Software architecture
MME Interface
Function
MME Application Function

MWare
MWare
L
D
AC
MWare
MWare
MME
Hub
MWare
MWare
MME
OAM
Server
1 10 27

MWare
MWare
The 9471 MME software architecture includes software components on the MPH, MIF, and MAF as
well as on the OAM Server to provide mobility services. This software is described on the next
slides.
The diagram used in this topic is a logical depiction of the software and does not depict the physical
connectivity.
For simplicity, only basic EPS interfaces are shown. The 9471 MME also supports interfaces for
lawful intercept, emergency and location-based services, and UTRAN/GSM interworking.

Software architecture: MPH

1 MPH
S1-MME
eNB
S
C
T
P
eNB
eNB
eUTRAN
SGSN
MSC
MME
HSS
EIR
S11
IPv4
IPv6
Gn
SGs
S10
S6a
S13
User MAF
Registry
MWare
MWare
MidWare
Paging
Diam S6a Intfc
eter
L
D
A
C
S13 Intfc
S10 Intfc
S11 Intfc
TCP
Session
Dist.
UE Connection Mgr
Mobil
Mgmt
Bearer
Mgmt
Handoff
MWare
Link
Mgmt
User Context
Data
SGW
Selector
Link
Mgmt
SGs Intfc
Gn Intfc
EPC & 2G/3G Core
MWare
MidWare
Base Host
MME
Hub
S1-AP Intfc
T
C
P
TCP
Bridge
SGW
U
D
P
MME Interface
Function
MWare
Paging
Ethernet
Switch
MWare
MidWare
Intfc
Proxy
NML
MME OAM
Server
Call Trace
PCMD
OA&M Network
1 10 28
Perf Mon
MWare
MWare
MidWare

MME Packet Handler (MPH) software

1. The MPH service provides the interface to the external entities (eNodeB, SGW, HSS, EIR,
another MME, SGSN). The service runs on the HSPP4 AMC cards on the Hubs. The MPH service
logically terminates the SCTP, UDP and TCP layers from the RTM external MME signaling
connections (OA&M connections are not passed through the MPH). The payload is then bridged
to TCP and sent internally to the MIF over an internal TCP LAN connection.
2. MME messaging coming into the MPH from the MIF (via the internal network over TCP) is
bridged to the correct MME external layer, SCTP, UDP, TCP.
In the future, the MPH service will also provide IPsec functionality for S1-MME.
Interprocessor communication: The LCP platform infrastructure is used to establish TCP
connections between the MPH and the MIF, and between the MIF and the MAFs. These
connections are established using the internal floating IP addresses. Standard LCP mechanisms
are used for failover.
Message bundling provides enhanced throughput by bundling signaling messages from the MIF to
the MAF(s), from the MAF(s) to the MIF, and from the MIF to the MPH.
UDP = User Data Protocol
TCP = Transmission Control Protocol
LDAC = Load Distribution Admission Control
PCMD = Per Call Measurement Data

Software architecture: MIF
2
MPH
S1-MME
eNB
S
C
T
P
eNB
eNB
eUTRAN
SGSN
MSC
MME
HSS
EIR
S11
IPv4
IPv6
Gn
SGs
S10
S6a
S13
S1-AP Intfc
1
Dia S6a Intfc
mete
r
S13 Intfc
G
T
C
P
TCP
Bridge
SGW
U
D
P
MME Interface
Function
T
P
TCP
EPC & 2G/3G Core
User MAF
Registry
MWare
MWare
MidWare
Paging 4
L
D
A
C
S10 Intfc
S11 Intfc
Link 3
Mgmt
User Context
Data
SGW
Selector
Session
Dist.
UE Connection Mgr
Mobil
Mgmt
Bearer
Mgmt
Handoff
Link
Mgmt
SGs Intfc
Gn Intfc
5
Base Host
MME
Hub
MWare
MWare
MidWare
MWare
Paging
Ethernet
Switch
MWare
MidWare
Intfc
Proxy
NML
OA&M Network
1 10 29
MME OAM
Server
Call Trace
PCMD
Perf Mon

MWare
MWare
MidWare
MIF software
The primary function of the MIF is to distribute messages from the external interfaces to the
appropriate MAF handling the session or procedure for a particular UE.
1. To provide this functionality, the MIF sets up multiple protocol stacks for messages from
external interfaces. Messages are received internally from the MPH over an internal TCP LAN
connection.
2. The MIF provides load balancing for the MME: It assigns UEs to a particular MAF during Attach
based on resource utilization. The MIF then distributes messages from the external interfaces to
the appropriate MAF handling the session or procedure for a particular UE. The MIF uses the
User MAF Registry to track this UE-to-MAF assignment.
3. The MIF provides facility management for each signaling link type, managing the link service
states and reporting to the MIB and MIs equipment status reports.
4. The MIF also provides paging broadcast services when a UE needs to be paged.
5. Overload detection occurring on both the MIF and the MAFs is done by standard LCP
middleware. An alarm is issued if there is an overload
6. The MIF terminates and manages all Lawful Interface links.
7. If Multimedia Broadcast and Warning Delivery Message Delivery applications are used, the MIF
performs broadcast functions. It receives requests from network elements such as a Multimedia
Gateway or Broadcast Center and, in turn, sends signaling/control to other network elements
such as eNodeBs and MulticastControl Centers (MCEs).
UDP = User Data Protocol
LDAC = Load Distribution Admission Control
PCMD = Per Call Measurement Data
Software architecture: MAF

MPH
S1-MME
eNB
S
C
T
P
eNB
eNB
eUTRAN
SGSN
MSC
MME
HSS
EIR
S11
IPv6
Gn
SGs
S10
S6a
S13
User MAF
Registry
Data
Paging
Dia S6a Intfc

mete
r
S13 Intfc
G
T
P
TCP
EPC & 2G/3G Core
L
D
A
C
S10 Intfc
S11 Intfc
SGW
Selector
1
Session
Dist.
UE Connection Mgr
Mobil
Mgmt
Bearer
Mgmt
Handoff
Link
Mgmt
SGs Intfc
Gn Intfc
MWare
Link
Mgmt
MWare
MidWare
Base Host
MME
Hub

3
MWare
User Context
MWare
MidWare
4
S1-AP Intfc
T
C
P
TCP
Bridge
SGW
IPv4
U
D
P
MME Interface
Function
MWare
Paging
Ethernet
Switch
MWare
MidWare
Intfc
Proxy
NML
OA&M Network
1 10 30
MME OAM
Server
Call Trace
Perf Mon
PCMD

MWare
MWare
MidWare
MAF software
The primary function of MAF is to provide session/bearer management for user sessions and
procedures.
1. External messages are sent/received by UE Connection Manager, which contains UE Session
Contexts.
Each UE Session Context represents a single User and their associated

sessions/procedures.
2. Within the UE Session Context are one or more objects, including a Mobility Management
object, a Bearer Management Object, a HandOver Object, a Paging Object, and interface proxy
objects (i.e., an S1 object, an S6a object, etc).
3. These objects access the UE context data structure within the MAF memory for information
about the UE.
The UE context data structure has one tuple per UE, and includes all static data
retrieved from the HSS at Attachment, as well as all subsequent dynamic state
information related to that UE and their current UE context.
The UE context data is a distributed data structure, with user tuples on each MAF
being unique to that MAF.
With each user Attach to the MME, the MIF chooses a MAF to serve the user until
the user de-attaches. The UE context data record retrieved from the HSS is
populated on the MAF chosen by the MIF during the Attach procedure.
4. The MAF is responsible for selecting an SGW.

Software architecture: OAM Server

MPH
S1-MME
eNB
S
C
T
P
eNB
eNB
eUTRAN
SGSN
MSC
MME
HSS
EIR
S11
IPv4
IPv6
Gn
SGs
S10
S6a
S13
User MAF
Registry
MWare
Dia S6a Intfc

mete
r
S13 Intfc
G
T
P
L
D
A
C
S10 Intfc
S11 Intfc
TCP
OA&M Network
1 10 31
Session
Dist.
MWare
Link
Mgmt
MWare
MidWare
MWare
PCMD
Intfc
Proxy
Paging
Perf Mon
Bearer
Mgmt
1
Call Trace
Mobil
Mgmt
Ethernet
Switch
UE Connection Mgr
Handoff
MWare
MidWare
MME OAM
Server
User Context
Data
SGW
Selector
Link
Mgmt
SGs Intfc
Gn Intfc
Base Host
NML
MWare
MidWare
Paging
EPC & 2G/3G Core

MME
Hub
S1-AP Intfc
T
C
P
TCP
Bridge
SGW
U
D
P
MME Interface
Function

MWare
MWare
MidWare
OAM Server
1. The addition to standard LCP functions, the OAM Server is also the primary location for
Performance Monitoring collection, analysis, and forwarding for the MME.

2. The OAM Server coordinates the start/stop of call trace and provides temporary
storage for call trace data. The data can be retrieved and analyzed by upstream
systems.
3. The OAM Server provides temporary storage of Per Call Measurement Data (PCMD) files.
PCMD is described in the Management interfaces module of this course.
Future:
Paging logger/analysis, adaptive paging based on user history will be supported. The MAF
will collect the user data and forward to the OAM Server for storage.

Knowledge check: 9471 MME software

Which 9471 MME software terminates and manages all logical signaling
interfaces?
A.
B.
C.
D.
Hub software
MPH application software
MAF application software
OAM Server application software
1 10 32
B -MPH application software


Which 9471 MME software manages UE context data and UE session data?
A.
B.
C.
D.
Hub software
MIF application software
MAF application software
OAM Server application software
1 10 33
C -MAF application


Information about which MAF is handling a particular UE is listed in the
User MAF Registry on the MIF
____________________________.
A.
B.
C.
D.
MIF uses the User MAF Registry to

track a UE-to-MAF assignment.
User MAF Registry on the MAF

User MAF Registry on the MIF
UE context data on the MAF
UE context data on the MIF
1 10 34

4 UE context
1 10 35
This topic describes the data stored on the 9471 MME for a UE.

UE context data tables
UE context data supports tables for:

Static data
Dynamic data
UE context data is partitioned in MAF memory.

Data synchronized on active/standby MAF
Data unique to logical pair - not replicated across pairs
No centralized or disk copy of the UE context data
Reboots:
MAF service or MAF blade switch to mate on reboot
No stable data lost
If a MAF pair simultaneously reboot, UE context data is lost on partition
1 10 36
The UE context data supports tables for:

Static
data (usually from the HSS including authentication, subscription, and APN data).
Dynamic
data (UE session and bearer data).
The UE context data is partitioned by groups of UEs in MAF memory.

Data
is not replicated across logical MAF application pairs*.
There
is no centralized or disk copy of the UE context data on the MME.
If a MAF service or MAF blade reboots, the MAF service or MAF blade switches to its mate at reboot,
and no stable data is lost.
If
a MAF pair simultaneously reboot, UE context data is lost for the MAF pair partition.
*A logical MAF service pair consists of an active and standby MAF service. They are logically
considered to be one MAF, and data is synchronized on the active MAF and its standby. Data is
unique the logical pair.
UE Context capacity
The number of supported UE context: 500K UE context per MAF pair (10 total MAF pairs * 500K =
5 million total UE contexts per MME).
An MME supports between 2-5 million attached UEs per MME with a maximum configuration,
depending on call model.

UE context data tables: Table example
UE context
1. Open Appendix B in your student guide.

2. Locate the following static and dynamic UE context data tables:
UE context data
tuple
Purpose
MVLR_Base
Common (or basic) parameters associated with a UE context, such as

mobility management state.
MVLR_AUTH
Individual UEs authentication data.
MVLR_SUB
Individual UEs subscriber data
MVLR_APN
Per APN profile configuration data. APNs are unique to each UE and
accessed by both the UE context data index and APN configuration
ID.
MVLR_SXN
Individual UEs general dynamic data per UE session data.
MVLR_BRR
Individual UEs dynamic per bearer data. Tuples are accessed by the
UE context data index and the EPS bearer ID (EBI).

1 10 37

All of the data output from the ueadmin_cli command is considered UE Context with one exception within UE context data_SXN mmeUeS1ApId is a derived field and is noted as such.
Displaying UE Context
The ueadmin_cli command can be used to display all of the UE context tables or specific UE context
tables. For example, you may want to see only the bearer information associated with a particular
UE. The ueadmin_cli command is described in the 9471 MME OAM&P customer document (418111-201).
Manual purging of UE context
The ueadmin_cli command can also be used to delete a UE context for a specified IMSI or IMEI that
is causing a problem in the network.
The MME also supports a service-provider provisioned option to purge the UE Context after
repeated Attach failures or Service Request failures by a single UE. The Global parameter "VLR Auto
Recovery Purge Count" provisioned at the 5620 SAM may be set to 0 (functionality is disabled
[default]), or a value from 6 to 10 (the threshold limit for failed procedures). Note that any
successful EMM attempt after a failure clears the counter.
References:
An example of UE context data is found in Appendix B of the course.
For details about UE context data, see the topic Interpret UE context data in the Fault
Localization chapter of the 9471 MME OA&M customer document (418-111-201).


The UE context data table is unique on each active MAF.
True
False
True - The UE context data is a distributed data structure, with user
tuples on each MAF being unique to that MAF.
1 10 38


Which of the following data is found in a UE context?
Select all correct answers.
A. Subscriber data
B. Bearer IDs for a data session
C. User's APN profile
D. Authentication data for the connection
E. Current mobility management state of the UE
All of the data is found in a UE context.
1 10 39

Common software functions provided by the ATCA platform
Services provided by the 5400 LCP software:
MI service
CNFG service
SNS service
9471 MME software components:
MPH application
MIF application
MAF application
Performance monitoring, call trace, and PCMD storage on the OAM server
Structure of a UE context
1 10 40

Describe the services provided by the ATCA and 5400 LCP platform software
elements
Explain the functions of the 9471 MME software components
Identify the key tables of a UE context
1 10 41

References
related to 9471 MME software:
9471 MME Technical
Description
(418-111-200)
9471 MME OAM&P

(418-111-201)
9471 MME Software

Update
Describes:
Functions of MI, CNFG, SNS platform services
Functions of MME MIF, MAF, MPH application
services
Describes the meaning of UE Context fields

Explains how to perform software backup and
restore.
Provides software update and patching

procedures
(418-111-206)
1 10 42

1 10 43

End of module
9471 MME Software
1 10 44

Section 1
9471 MME Overview
Module 11
9471 MME IP Addressing and Subnets

Technical Overview

Blank page
1 11 2
9471 MME Overview 9471 MME IP Addressing and Subnets

Document History
Edition
Date
Author
Remarks
01
YYYY-MM-DD
First edition

Module objectives
Describe the IP architecture of the 9471 MME
1 11 3
This module provides an overview of the basic IP addressing concepts for the 9471 MME.

Table of Contents
1 IP addressing
2 Internal IP address subnets
3 Externally routable service subnets
1 11 5

Page
7
12
24
1 IP addressing
1 11 7
This topic provides an overview of the basic IP addressing concepts for the 9471 MME.

IPv4 and IPv6

The 9471 MME supports:
IPv4/IPv6 dual stack transport Internet Layer Protocol for external signaling
traffic
IPv4 for internal communication and communication to the external OA&M
network
Dual-stack UEs
IPv6 IP address example:
2001:0db8:85a3:0000:0000:8a2e:0370:7334
IPv4 IP address example:

192.0.2.128
Simplified IPv6 IP address if there are leading zeros:

2001:db8:85a3::8a2e:370:7334
Same IPv4 address mapped to IPv6 in hex:

::ffff:c000:280
IPv6 if port is specified:

[2001:0db8:85a3:08d3:1319:8a2e:0370:7344]:443/
Same IP address mapped to IPv6 with standard dot

notation:
::ffff:192.0.2.128
1 11 8
Details about IPv4, IPv6, and address mapping can be found on many Internet sites.
IPv4/IPv6 for S11 link
The MME supports an IPv6 SGW address as the preferred SGW address if it is available.
However, when both IPv4 and IPv6 addresses are in the senders F-TEID in the Create Session (CS)
Response message from the SGW, the MME uses the IP version on which the CS Response was
received. For example, if the CS response is received on an IPv4 path, then the MME uses an IPv4
S11 path if available. If the IPv4 S11 path is not available, then the session fails.

Example of IPv4 and IPv6 nodes using IPv4 network

MME has an IPv4 address and
IPv6 address for S1 interface:
IPv4 eNB can set up a SCTP
association using the S1 IPv4.
IPv6 eNB can set up SCTP
association using the S1 IPv6.
MME
Dual Stack
Router
eNB 1
(IPv4 only)
MME is provisioned with S11

interface IPv4 and IPv6
addresses.
SGW 1 IPv4 and SGW 2 IPv6
address will be provisioned
on MME if DNS query is not
used to discover SGW.
IPv6 over
IPv4 Tunnel
IPv4 Network
Dual Stack
Router
Dual Stack
Router
EMS
(IPv4)
eNB 2
(IPv6 only)
SGW 1
(IPv4)
1 11 9
SGW 2
(IPv6)
IPv4 (used for OA&M interfaces and services like FTP, etc.) and IPv6 (not for OA&M interfaces)
stacks are supported on the 9471 MME to enable to MME to communicate with IPv4-only nodes and
IPv6-only nodes, and provide a graceful migration to an all-IPv6 network. Internet Control Message
Protocol for the IPv6 (ICMPv6) is also supported (for Echo Request and Echo Reply).
IPv4
and IPv6 addresses is supported for MME interfaces: S1-MME, S10, S11, S6a.
IPv4
is supported for OA&M interfaces and is used for services like FTP, etc.
IPv4
is supported for UMTS interworking interfaces: Gn, SGs.
The graphic shows an example of supporting IPv4 and IPv6 nodes using an IPv4 network.

Virtual and fixed IP addresses

For each pair of servers:
One virtual IP address is available for application signaling.

A unique fixed IP address is assigned to each server that can be used for any
messages needed to maintain heartbeating and configure that particular server.
Clients use the virtual IP addresses to communicate with services on the

9471 MME.
Active MI service
Fixed IP
Floating IP
MI GUI
IP address
Standby MI service
Fixed IP
1 11 10
A virtual IP address is an IP address that is assigned to the active server (or service) in a redundant
pair. If the active server or service switches over, the IP "floats" to the new active server or service.
The advantage of using a virtual IP address is that clients that use this IP address to talk to the
active server do not know which of the servers is currently active. When the active server fails, its
mate becomes active and assumes ownership of this IP address. Clients with active connections
detect the failure, and try to re-establish the connection. Although the client uses the same IP
address, the new connection is to a different processor. UE context data is maintained across the
switchover.

LCP required IP address subnets
IP address subnets are required for LCP configuration:

Internal IP address subnets (IPv4 only)
Used for internal communication among hosts within the LCP.
Do not route out of the LCP.
Predefined and are reusable by multiple LCP systems.
Externally routable service subnets (IPv4 or IPv6)
Assigned to services that communicate outside the LCP.
Provided by the customer.
Also called transport subnets.
1 11 11
The following types of IP address subnets are required for LCP configuration:
Internal
IP address subnets (IPv4 only)

Subnets used for internal communication among hosts within the LCP. These subnets do not
route out of the LCP. These subnets are predefined and are reusable by multiple LCP systems.
Externally
routable service subnets (IPv4 or IPv6)

Assigned to services within the LCP that need to communicate with entities outside the LCP or
within the customer network. These subnets should be provided by the customer.
Also called transport subnets
A subnet is a logically visible subdivision of an IP network. In order to better understand the

functions and necessity of the different subnetwork types, it is useful to know that within a Lucent
LCP cabinet, each component:
Can
have multiple IP addresses at the same time
The
IP addresses can belong to different subnetworks
Notes:
Subnets
are configured using CLI commands at the Hub during initial configuration. They do
not normally change unless requested by customers.
The
externally routable service subnets are sometimes informally called transport subnets.
addressing and subnets are explained in the Alcatel-Lucent 9471 MME Technical Description
(418-111-201), 9471 MME internal IP addresses and subnets chapter.
IP

2 Internal IP address subnets
1 11 12
This topic explains the internal 9471 MME IP address schemes.

Internal IP address subnetworks

Six internal IP subnets are used to route internal IP messages between the
different cards and processes:
Five hardware-related subnets:
Host Subnet
DHCP0 Subnet
DHCP1 Subnet
LSN0 Subnet
LSN1 Subnet
One service-related subnet
1 11 13
Within the 9471 MME, six internal IP subnetworks (subnets) are used to route internal IP messages
between the different cards and processes that are running on these cards. The subnetworks used
can be divided into five hardware-related subnetworks and one service-related subnetwork.
The internal subnets allow all MME elements (ShMC, Hub, OAM Server, MIF/MAF, alarm card) to
communicate with each other. Internal IP addresses are automatically assigned from the defined
subnet.
All redundant MME elements (ShMC, Hub, OAM Server, MIF/MAF) have a host-active, host-standby
and internal service subnet. Elements also have DHCP and local subnet IP addresses.
Multiple IP addresses per component
Each cabinet each component:
Can
have multiple IP addresses at the same time.
The
IP addresses can belong to different subnetworks.
MME supports assignment of the same IPv4/IPv6 subnet for all the GigE interfaces or a different
IPv4/IPv6 subnet for each GigE interface.
DHCP: Dynamic Host Protocol (DHCP) service provides IP configuration information to blades.
During system initialization or when a blade is replaced, the blade sends a DHCP broadcast message
to obtain IP configuration information. The blade obtains operating system and application specific
data from the CNFG service database during bootup.

Hardware-related internal subnets: Host

Host Subnet
Used to communicate with Host IP addresses of other hosts.
Each host, including the Hub and ShMC host, is associated with a Host IP
address.
Host IP addresses are used by the RCC, REM; they can be used to telnet to
other hosts.
The active host is reachable using the fixed IP or floating IP address.
1 11 14
The host subnet assigns each Host a specific IP address based on the Shelf number, Slot Number,
and Host Number. Host Subnet is also known as Host Active Subnet.
The Hub cards have the host active addresses on only ONE interface (VLAN), whereas in Node
cards host active addresses are on both interfaces. The Host Active address on Hub 7 is in VLAN
800 while on Hub 8, it is in VLAN 801.
RCC (Reliable Cluster Computing) and REM (Redundancy Manager) are the two processes used to
maange redundancy on the blades. They are described in the "Reliability" module of training.

Hardware-related internal subnets: DHCP

DHCP subnets 0 and 1
Used by booting hosts for DHCP requests and responses
DHCP0 requests traverse the left Hub (VLAN 300, eth0)
DHCP1 requests traverse the right Hub (VLAN 301, eth1)
eth0 and eth1 are the names for the virtual switch interfaces on the left and right Hubs respectively.
1 11 15
The DHCP network is used during system initiation or when the blades needs to be replaced in
order to jumpstart the blades. A broadcast DHCP request that does not specify a VLAN goes to the
left HUB (VLAN 300). For the untagged and internal VLANs, the Left Hub broadcast areas and the
Right Hub broadcast areas DO NOT INTERCONNECT.
VLAN 300 is used for DHCP requests and responses in the Left Hubs
VLAN 301 is used for DHCP requests and responses in the Right Hubs
Eth0 and Eth1: Each MME host has a primary and secondary port for internal and external
communications. Typically, the primary port will be Eth0 and the secondary port will be Eth1. On
the Hubs, Eth0 (primary) is associated with the left Hub, and Eth1 is associated with the right Hub.

Hardware-related internal subnets: LSN

LSN subnets 0 and 1
Used by blades that communicate using the internal midplane

Example of use: MIF to MAF communication
LSN0 requests traverse the left Hub (VLAN 800, eth0)
LSN1 requests traverse the right Hub (VLAN 801, eth1)
eth0 and eth1 are the names for the virtual switch interfaces on the left and right Hubs respectively.
1 11 16
LSN is the Local Secure Network, which runs in two modes LSN0 and LSN1 and enables the cards to
communicate with each other.
The internal network runs in duplex mode: LSN0 and LSN1. The blades communicate internally
using this network. If LSN0 is down, then LSN1 will be used. All blades are members of both LSN0
and LSN1. The terms left-side and right-side are interchangeable with LSN0 and LSN1.
All hosts have the same interface/vlan correlation (LSN0 on eth0 vlan 800 and LSN1 on eth1 vlan
801) EXCEPT for the hub in slot 8 (the right hub) and the bottom ShMC. These two hosts have the
interfaces flipped with respect to the other hosts in the system. The LSN0 IP is on the eth1.800
interface and the LSN1 IP is on the eth0.801 interface.
Eth0 and Eth1: Each MME host has a primary and secondary port for internal and external
communications. Typically, the primary port will be Eth0 and the secondary port will be Eth1. On
the Hubs, Eth0 (primary) is associated with the left Hub, and Eth1 is associated with the right Hub.

IP address conventions
32
48
64
80
96
10
11
12
13
14
SHMC2
ShMC1
OAM
16
HUB
Slot
HUB
1
OAM
Example: IP addresses in the Host Subnet:
Host 0
112 128 144 160 176 192 208 224
Formula for fixed IP address of a Node (host) in the Host Subnet = x.y.(64+s).(c*16+h)
Calculate:
The fixed IP address for the first OAM Server host in the first shelf = 169.254.64.16
?
1 11 17
This slide helps explain the structure and IP calculation of the host IP using the default base IP
address.
Each component has an IP address in each of the hardware subnets (Host, DHCP, LSN subnets)
according to standard formulas.
The Host Subnet IP addresses were chosen for this example since they can be used to telnet to
individual cards.
There are also standard calculations for the LSN and DHCP subnets for each card.
c = Card/Slot number
s = Shelf Number
h = Host number. h = 0 for every card except ShMC. For ShMC, h = 0 for the virtual IP; h = 1 for
the upper card; h = 2 for the lower card.
When the MIF moves to an AMC slot in the Hub in a future release, the Hub will have 3 hosts: 0, 1,
2.
The recommended value of x.y for internal subnets is 169.254. However, customers may change
this (in some Alcatel-Lucent lab examples in this course, you will see 10.220).
Standard addresses for all elements and subnets is listed in Alcatel-Lucent 9471 MME Technical
Description (418-111-201), 9471 MME internal IP addresses and subnets chapter.

Service-related internal subnet

Internal Service subnet
IP addresses within subnet assigned to each service instance.
Used for internal communication, like collecting logs.
Divided into internal fixed and internal floating service addresses.
IP addresses are assigned by the system. IP address ranges:

IP address range
Network mask
169.254.128.0 - 169.254.191.255
255.255.128.0
169.254.192.0 - 169.254.255.255
Example:
Service
Service name Internal fixed IP Internal floating IP
CNFG service
cnfg
1 11 18
169.254.130.0
169.254.194.0
IP addresses within subnet assigned to each service instance (for example: MI, CNFG, MPH,
MIF, MAF).
Internal Service IP addresses are used for internal communication, like collecting logs.
Internal service subnet is divided into internal fixed service address and internal floating service
address.
The majority of the IP communication will exclusively use Service IP Addresses. The exceptions
are certain maintenance and fault management activities, which use Host IP Addresses. Each
interface is a service and must have a unique IP address.
In some documentation, the service subnet is called the transport subnet.

Displaying subnet IP addresses

Display the IPv4 addresses that each blade
has in each subnet:
net4conf_adm --action show_ip_address
Display the IPv6 addresses that each blade

has in each subnet:
net6conf_adm --action show_ip_address
<lm12-s00c01h0:root>/root:
# net4conf_adm --action show_ip_address
IPv4 lsn0 IP address
---------------------169.254.32.16
lm12-s00c01h0
169.254.32.32
lm12-s00c02h0
169.254.32.48
lm12-s00c03h0
169.254.32.64
lm12-s00c04h0
169.254.32.80
lm12-s00c05h0
169.254.32.96
lm12-s00c06h0
169.254.32.112
lm12-s00c07h0
169.254.32.128
lm12-s00c08h0
169.254.32.241
lm12-s00c15h1
169.254.32.242
lm12-s00c15h2
---------------------169.254.48.16
lm12-s00c01h0
169.254.48.32
lm12-s00c02h0
169.254.48.48
lm12-s00c03h0
169.254.48.64
lm12-s00c04h0
169.254.48.80
lm12-s00c05h0
169.254.48.96
lm12-s00c06h0
169.254.48.112
lm12-s00c07h0
169.254.48.128
lm12-s00c08h0
169.254.48.241
lm12-s00c15h1
169.254.48.242
lm12-s00c15h2
IPv4 host IP addresses
---------------------169.254.64.16
lm12-s00c01h0
169.254.64.32
lm12-s00c02h0
169.254.64.48
lm12-s00c03h0
169.254.64.64
lm12-s00c04h0
169.254.64.80
lm12-s00c05h0
169.254.64.96
lm12-s00c06h0
169.254.64.112
lm12-s00c07h0
169.254.64.128
lm12-s00c08h0
169.254.64.240
lm12-s00c15h0
Full output from this command is found in the

appendices of this course.
1 11 19
IPv4 internal fixed service IP addresses

---------------------------------------169.254.130.0
lm12-cnfg-p00m000-d0
This command is executed on the command line interface of the OA&M Server. Commands are
described in the 9471 MME OAM&P course.

VLANs for internal traffic (1 of 2)

The VLANs are defined on the Hubs/RTMs for the 9471 MME:
Range
Purpose
300
Platform, Untagged for DHCP
300
301
600-710 Transport R-0 - GE0

Transport R-1 GE1
Transport R-2 GE2
Transport R-3 GE3
Transport R-4 GE4
Transport R-5 GE5
Transport R-6 GE6
Transport R-7 GE7
Transport R-8 GE8
Transport R-9 GE9
Transport R-10 GE10
Transport R-11 GE11
Transport R-12 GE12 reserved for port
mirroring, VLAN not used.
600
610
620
630
640
650
660
670
680
690
700
710
601
611
621
631
641
651
661
671
681
691
701
711
800
801
800
Left hub Right

hub
For use by internal services on ATCA shelf
1 11 20
VLAN = Virtual Local Area Network. Not shown in slide: The 400 Range is used for External Service
on the Hub front panel (GE0-GE4).
VLAN tagging of internal traffic segregates communication flows. Chassis-related communications,
such as DHCP, use untagged VLANs
All Ethernet ports and interfaces within the 9471 MME chassis are configured according to a
coordinated VLAN numbering scheme. All Ethernet frames on the midplane and within the Hub
cards include VLAN tagging.
VLAN tagging is the means by which:
Frames from different applications and services are kept separate ("Internal service VLANs").
Frames to or from external service Ports on the Hub cards can be distinguished (external
service VLANs").
There are different VLANs defined for different purposes. Therefore, each Host will have:
Untagged interfaces for the use of DHCP and transport connections
Tagged interfaces for use of Internal Subnets (Internal Service and Host Active subnets in the
800 series of VLAN tags)
Differently tagged interfaces for use of External Subnets (External Service subnets in the 400
and/or 600 series of VLAN tags)
VLANs in the 600-700 range are used in the Left/Right Hubs for External Service Subnet IP
Addresses accessed from the customer network over the ROETHAA RTM panel connections. VLAN
600/601 (port 0) is used for OAM traffic.
VLAN 800/801 is used in the Left/Right Hubs for all IP addresses that stay on the ATCA shelf.
Neither of these VLANs is configured on any port of the Hub that is connected to the customer
network.
VLANs for internal traffic (2 of 2)

Customer Network
MLS/
CE
Links to customer networks

802.1Q VLANs supported for
external traffic
MLS/
CE
OAM
S1-MME
GE0
GE1
RTM
VLAN 800
VLAN 601
(External OAM)
(Internal services)
VLAN 610
(External Signaling)
VLAN 611
VLAN 800
MIF
Service
(Internal services)
MAF
Service
ETH1
(Internal services)
(External Signaling)
Hub 8
VLAN 801
(Internal services)
ETH0
VLAN 800
MPH
Service
VLAN 801
(Internal services)
ETH1
Hub 7
OAM Server
ETH1
ETH0
VLAN 600
(External OAM)
ETH0
MPH
Service
GE0
GE1
RTM
VLAN 801
(Internal services)
midplane traffic
(tagged)
1 11 21
MLS = multi-layer switch; CE = Customer Edge router.

Each External Service port is assigned a unique VLAN ID within the system.
The
port itself is untagged
Frames
received on the port are tagged when carried within the HSPP4, Hub Cards, and
midplane. This allows a Node Card to know the Transport Port on which a frame was received.
Frames
sent by a Node Card are similarly tagged inside the application such that they can be
directed out a specific Transport Port.
Each MME host supports a primary and secondary port for internal communications. Typically
the primary port is Eth0 and the secondary port is Eth1. The primary port (Eth0) is the default
communication link for each host, and the secondary port (Eth1) is the alternate
communication link. Upon host initialization, the primary port is always the initial active link.
After route switchover(s) that utilize the secondary port (Eth1), link fault recovery software
reverts back to primary port (Eth0), within 60 seconds of primary port becoming operational.
Only two external VLANS are shown in the diagram for simplicity.
Internal VLAN tags are removed before message is sent to the external network.
VLAN definition: A VLAN is a group of hosts that communicate as if they were attached to the
Broadcast domain, regardless of their physical location. Reconfiguration can be done through
software instead of physically relocating devices.

Knowledge check: IP subnets

Which IP subnet within the internal MME network are you using when you
telnet to a MIF blade?
A.
B.
C.
D.
host active subnet

LSN subnetwork
internal service subnet
externally routable service subnet
A host active subnet
1 11 22


What traffic travels on VLAN 800?
A.
B.
C.
D.
Internal services accessing the left Hub

Internal services accessing the right Hub
External services using OAM ports
External services using signaling ports
1 11 23

3 Externally routable service subnets
1 11 24
This topic explains how traffic may be routed to external networks.

Externally routable service subnets
Services that need to communicate outside the MME are assigned IP

addresses within externally routable service subnets.
Address calculation automatic by the system once the base is assigned.
Each external subnet must be configured on:
Redundant transport connections to the customer multi-layer service pair, or
SCTP multi-homed connections to the customer multi-layer service pair.
The externally routable subnets include:

OA&M subnet (for MI, CNFG, SNS services)
Signaling subnet (for MPH, MIF and MAF services)
1 11 25
IP addresses within externally routable service subnets are assigned to services in the MME (for
example, MIF) that need to communicate with entities outside the MME.
These
subnets are provided by the customer.
Calculations for addresses are done automatically by the system once the base is assigned.
Each subnet used for external communication must be configured on a set of redundant transport
connections, or SCTP multi-homed connections to the customer multi-layer service pair.
Multiple
A
service subnets can use the same set of transport connections, but
subnet cannot be present on more than one set of connections
The externally routable subnets include:

OA&M
subnet (for MI, CNFG, SNS services)
Signaling
subnet (for MPH, MIF and MAF services)
Review: Services include MI, CNFG, SNS, MPH, MIF, MAF.

Externally routable service subnets should be large enough for growth as applicable.
Each externally routable service subnet MUST be unique if visible to each other.
Transport connection An Ethernet connection between the MME and the external network.
Transport Connections may be tagged or untagged. VLAN tagging on external interfaces is site
specific. A Transport Interface is the MME system Ethernet port in which a cable is plugged to carry
IP traffic to or from the platform.
EMS IP address note: On the element management system side, the EMS will have two IP
addresses: one for the active EMS and one for the standby EMS. Traps are sent to both IP
addresses, since the MME does not know which is active and which is standby.
Externally routable service subnets: OAM

OAM subnet
Each OAM subnet is configured with one default gateway.
A static route is configured for each additional OA&M subnet
Example for DNS or Lawful Intercept connections.
1 11 26
Note: You might see two service addresses for MI and CNFG on the GUI; though the signaling
address may not be used.
The OAM subnet used for external communication is configured with a default gateway (next hop
routing address) that is used by the MME for associated outbound packets.
Subnet routing terminates to the customer multi-layer switches (MLSs) or customer edge routers
attached to the ROETHAA RTM ports for signaling.

Externally routable service subnets: Signaling
Signaling subnets for MIF services

The subnet used for signaling interfaces on the MIF blade is configured with one
default gateway.
A static route is configured for each additional subnet configured on the MIF
blade.
Signaling subnets for MPH services
Default gateways and static routes are not needed for MPH services.
Service subnets can include:
BFD service subnet
SCTP-multi-homed (non-BFD) service subnet
ACM (non-BFD service subnet)
1 11 27
The signaling subnet used for external communications on the MIF blade are configured with a
default gateway (next hop routing address) that is used by the MME for associated outbound
packets. Currently the Lawful Intercept interfaces terminate in the MIF.
Services on the MPH use source-based routing and do not need a default gateway or static route.
This includes the following service subnets:
BFD service subnet for interfaces that use BFD (S11, S10, Gn, S3 can use BFD)
SCTP-MH service subnet (non-BDF) for interfaces that use multi-homing (S1-MME, S6a, S13,
for example)
ACM (non-BFD) service subnet for interfaces that do not use BFD or multi-homing
MPH service-based routing is described in an upcoming slide.
Subnet routing terminates to the customer multi-layer switches (MLSs) or customer edge routers
attached to the ROETHAA RTM ports for signaling.
Review of fault-detection mechanisms and protocols:
SCTP with multi-homing provides fast fault detection for SCTP interfaces.
Bidirectional Forwarding Detection (BFD) is available on all MME non-SCTP external interfaces
to the 1st hop router at Layer 3.
External IP Manager Active Connection Management (EIPM- ACM) is an Alcatel-Lucent
proprietary fault detection mechanism that provides fast fault detection for deployments with L2
connectivity between 1st hop routers. If no Layer 2, either BFD or multi-homing is used.

MPH source-based routing

MME supports source-based routing for interfaces on the MPH:
Default gateways and static routes not needed.
New SGW, MME, SGSN and MSC introduced on each MME without provisioning.
Destination-based static routes supported for interfaces not terminated to MPH.
1 11 28
BFD = Bidirectional Forwarding Detection

The MME supports source-based routing for interfaces on the MPH:
Default
gateways and static routes are not needed on MPH interfaces.
New
SGW, MME, SGSN and MSC servers can be introduced on each MME without any
provisioning.
Destination-based
static routes are supported for interfaces that are not terminated to the MPH
(OA&M interfaces, MIF interfaces).
Source-based routing vs destination-based static routes

When source-based routing is used, the sender of a packet specifies the route the packet takes
through the network. It is useful when sending traffic to different outgoing network interfaces
based on their source IP. The source can send packets over a particular path to prevent congestion
on other paths.
When destination-based static routing is used, network routers determine the path based on the
packet's destination.
Source-based routing provides easier troubleshooting and improved trace route over destinationbased static routing.

Ethernet/IP redundant setup on the 9471 MME (1 of 2)
Each external interface uses one of the following Ethernet/IP redundant

setups:
eipm_acm (External IP Manager Active Connection Mode)

eipm_bfd (External IP Manager Bidirectional Forwarding Detection mode)
bfd_rsr (Bidirectional forwarding Detection Reliable Static Routing)
none (used for SCTP multi-homing)
The setup depends on the network layer protocol used:

Protocol
Redundancy setup
SCTP multi-homed
none
SCTP single-homed
eipm_acm
All other protocols
eipm_acm, eipm_bfd, or bfd_rsr
1 11 29
The redundancy mode for a particular interface is determined at the time of field installation.
Definitions are on the next slide.
BFD transport subnets/IPs and the BFD subnets/IPs (signaling and OA&M external subnets) can be
added on to existing MME systems. Once added, the BFD sessions are enabled
automatically. Customers must also add corresponding BFD-enabled static routes to their first
hop routers.
Procedures to configure IP addresses and subnets are found in the 9471 MME OA&M document
(418-111-200).
Subnets and transport connections are described the 9471 MME Technical Description document
(418-111-201).
To show which redundancy modes are used for each subnet, run the following commands in the MI
CLI:
net4conf_adm --action show_redundancy_mode, or
net6conf_adm --action show_redundancy_mode

Ethernet/IP redundant setup on the 9471 MME example 1

OAM interface:
Redundant setup: EIPM_ACM
2 transport connections to separate
MME1
routers
MME and routers
have a presence in
Midplane
service subnet
H
R
U
S1 and S6a interfaces:
OAM setup: MH SCTP (NONE)
T
Redundant
B
1 transport connection to 1 router per
M
IP; SCTP handles redundancy over
7
separate paths.
DNS1
DNS2
CE 1
LI
OAM
OAM
NTP
OAM
MME MIF
and router have a presence in
service subnet
MPH
MIF
CE 5
MPH
MAF
MAF
ShMC
H
U
B
ShMC
R
T
M
S10 and S11 interface:

Redundant setup: EIPM_BFD
2 transport connections to separate routers
MME has a presence in service subnet
Router must support BFD static route
1 11 30
CE 3
CE 7
CE 9
S1
eNB1
eNB2
eNBn
S11
SGW1
SGW2
S6a
HSS1
HSS2
S10
MME2
CE - Customer Edge Router.
The graphic shows examples of where various redundancy setups might be used. Each Ethernet/IP
redundancy setup has both MME and router configuration requirements.
eipm_acm provides two physical transports, each connected to a separate router. The MME and
routers have a presence (IP address) in a single "service" subnet. A Layer 2 connection is
required between the routers, and a single gateway IP address is provided (e.g., via VRRP or
HSRP) to reach the routers.
none provides a single physical transport connected to a single router per IP address. SCTP
protocol manages redundancy over the separate paths. The ports serving a set of redundant
transport connections are connected to physically diverse networks. The MME and router have a
presence in a "service" subnet. SCTP multi-homing capability supports multiple SCTP paths
between two endpoints to increase the transport reliability. SCTP fault detection is end-to-end.
eipm_bfd provides two physical transports, each connected to a separate router. Only the MME
has a presence in the "service" subnet. A separate bfd transport subnet per physical transport
is required, which provides routing to/from the "service" subnet. The router is required to
support BFD static routes.
bfd_rsr (not shown in graphic) provides two physical transports each connected to a separate
router. Only the MME has a presence in the "service" subnet. A separate bfd transport subnet
per physical transport is required, which provides routing to/from the "service" subnet. The
router is required to support "reliable" static routes (e.g., verifies static routes via ARP/NDP, or
ICMP).

Ethernet/IP redundant setup on the 9471 MME example 2

LI
OAM interface:
Redundant setup: BFD_RSR
2 transport connections to separate
MME1
routers
MME has a presence
in service subnet
Midplane
OAM
CE 1
CE 3
IP;MIF
SCTP handles redundancy over
separate paths.
MME and router have a presence
MPHin
MIF subnet
service
MAF
ShMC
H
U
B
ShMC
CE 5
R
T
M
CE 7
S10 and S11 interfaces:

Redundant setup: EIPM_BFD
2 transport connections to separate routers
MME has a presence in service subnet
Router must support BFD static route
1 11 31
OAM
S1
eNB1
eNB2
eNBn
DNS1
DNS2
MPH
MAF
OAM
NTP
H
U
B
R
T
S1 and S6a interfaces:
M
Redundant setup: MH SCTP (NONE)
1 transport connection to 1 router
per
7
OAM
CE 9
S11
SGW1
SGW2
S6a
HSS1
HSS2
S10
MME2
CE - Customer Edge Router.
The graphic shows examples of where various redundancy setups might be used. Each Ethernet/IP
redundancy setup has both MME and router configuration requirements. Also in this example, the OAM
external interfaces are connected to the faceplate of the Hubs this implies that the connections are
copper rather than optical.
bfd_rsr provides two physical transports each connected to a separate router. Only the MME has a presence
in the "service" subnet. A separate bfd transport subnet per physical transport is required, which provides
routing to/from the "service" subnet. The router is required to support "reliable" static routes (e.g.,
verifies static routes via ARP/NDP, or ICMP).
none provides a single physical transport connected to a single router per IP address. SCTP protocol manages
redundancy over the separate paths. The ports serving a set of redundant transport connections are
connected to physically diverse networks. The MME and router have a presence in a "service"
subnet. SCTP multi-homing capability supports multiple SCTP paths between two endpoints to increase the
transport reliability. SCTP fault detection is end-to-end.
eipm_bfd provides two physical transports, each connected to a separate router. Only the MME has a
presence in the "service" subnet. A separate bfd transport subnet per physical transport is required, which
provides routing to/from the "service" subnet. The router is required to support BFD static routes.
eipm_acm (not shown in graphic) provides two physical transports, each connected to a separate
router. The MME and routers have a presence (IP address) in a single "service" subnet. A Layer 2
connection is required between the routers, and a single gateway IP address is provided (e.g., via VRRP or
HSRP) to reach the routers.

VLANs for external traffic

The MME supports 802.1Q VLAN tagging on external signaling interfaces.
The following VLAN tagging is provisionable during installation:
Define VLAN tags on non-LAG interfaces

Assign VLAN tags per subnet and transport
Reuse a VLAN tag on a per transport interface basis
Use multiple VLAN tags per interface
External interfaces may be untagged
External VLAN tagging is site specific.
1 11 32
The MME supports VLAN tagging on external signaling interfaces. VLAN tags are assigned non-LAG
interfaces (support for VLAN tags for LAG interfaces is future).
VLAN tags are assigned per subnet and transport and the same tag can be reused on a per
interfaces basis. The MME supports 802.1Q VLAN tagging.
VLAN tagging on external interfaces is site specific.


To communicate with the 5620 SAM, each MI service instance is
assigned an IP address within _____________.
A.
B.
C.
D.
a host active subnet

an LSN subnet
an internal service subnet
an externally routable service subnet
D - Each MI service has an external service IP address
for communication with the EMS, and an internal
service IP address for communication with the CNFG
Server and other internal services.
1 11 33


When the MME communicates with the eNodeB, it uses the
_____________ subnet.
A.
B.
C.
D.
host active
LSN
external OA&M routable service
external signaling routable service
1 11 34

Basic IP addressing
Internal IP address subnets
Internal VLANs
Externally routable service subnets
Ethernet/IP redundant setups
Support for external VLANs
1 11 35

Describe the IP architecture of the 9471 MME
1 11 36

Customer documentation reference

related to 9471 MME IP addressing:
9471 MME Technical
Description
(418-111-200)
Describes:
Internal subnets
Internal IP addresses
Redundancy setups
Internal and external VLANs
9471 MME OAM&P
(418-111-201)
Explains how to configure routes, gateways, and

add or remove IPv4/IPv6 IP addresses.

1 11 37

End of module
9471 MME IP Addressing and Subnets
1 11 38

Section 1
9471 MME Overview
Module 12
9471 MME System Reliability

Technical Overview

Blank page
1 12 2
9471 MME Overview 9471 MME System Reliability

Document History
Edition
Date
Author
Remarks
01
YYYY-MM-DD
First edition

Module objectives
Describe 9471 MME redundancy and switchover processes
Explain what happens during overload conditions
1 12 3
This module describes the reliability features of the 9471 MME and explains how the MME handles
overload conditions.

Table of Contents
1 System reliability
2 Load distribution and overload management
1 12 5

Page
7
17
1 System reliability
1 12 7
This topic describes the reliability features and capacity of the 9471 MME.

Reliability features provide 99.999% availability
Redundant
Redundant
components
components
Recover
Recover
Ethernet
Ethernet
interface
interface
<
< 0.5
0.5 sec
sec
1 12 8
Graceful
Graceful
shutdown
shutdown
Platform
Platform
overload
overload
control
control
mechanisms
mechanisms
Isolation
Isolation
of
of faults
faults
MIF
MIF and
and MAF
MAF
overload
overload
control
control
Automatic
Automatic
recovery
recovery
UE
UE load
load
balancing
balancing
by
by eNodeB
eNodeB
The 9471 MME provides the following reliability features:

Redundant blades, services, interconnections, power distribution, clock distribution, shelf
management, application software.
Graceful
shutdown (fail-safe) when total outages occur. This includes emergency saving of
service measurements and unwritten configuration and provisioning data.
Isolation
of faults to the smallest field replaceable unit, with alarm and log reporting.
Automatic
Detection
seconds.
recovery from power outages and disruptions.

and recovery of Ethernet communication interface failures is less than 0.5
platform overload control mechanism monitors and controls utilization of critical system
resources.
MIF
UE
and MAF overload control is provided by MME software.
load balancing across MMEs is provided by eNodeB.
Planned events (maintenance activity) and unplanned events (faults) do not impact context
information and related performance data of attached users or active stable sessions.

Platform redundancy management processes

Redundancy management for processor blades is provided by two 5400
LCP processes:
Reliable Cluster Computing (RCC)
REdundancy Manager (REM)
1 12 9

Redundancy management processes: RCC

Reliable Cluster Computing (RCC):
Manages diskful hosts (such as the OAM Servers) and processes.
Diskful host
Diskful host
(Lead-active)
(Active)
Command example:
RCCcstat provides the status of a lead-active/active pair.
1 12 10
Reliable Cluster Computing (RCC) manages diskful hosts (such as the OAM Servers) and processes.
Monitors the status of a resource pair to maintain high availability and take actions upon errors (for
example, switchover).
RCC provides commands to view status and power up and down blades.
For
example, RCCcstat provides the status of a lead-active/active pair.
RCC provides a number of management features and commands to power up and power down a
blade.
RCC commands are described in the 9471 MME OAM&P customer document.

Redundancy management processes: REM

REdundancy Manager (REM):
Manages the diskless hosts.
OAM Server
OAM Server
(lead-active)
1 12 11
(active)
REdundancy Manager (REM) software on the OAM Server manages the diskless hosts.
REM is composed of the System Monitor (SM) resident on the OAM Server and a Local Monitor (LM)
task on each diskless card.

Platform component redundancy and switchover (1 of 2)

Component Redundancy type
Notes
OAM Server RCC states are

host
Lead/Active.
OAM Server
processes,
virtual
machines
Active/Standby.
This includes all MMEspecific tasks on the
Server.
Ethernet
Hub
Active/Active
AMC card in Active/Standby

Hub (hosts
MPH
service)
1 12 12
Both elements are available; both active, but only the

processing result of the lead-active is used. When lead-active
host or process fails, the active takes over immediately.
At switchover, no data lost; GUI user connections lost.
Both VMs are available; only one is active, the standby is used
when the active one fails.
If a VM becomes unavailable, the mate handles all procedures
Configuration data and some databases are synchronized
across the hard drives by DataBlitz. However, disks are not
replicated.
Duplex operation, both elements available; each active at the
same time, each serving a part of the functionality.
Failure of one hub is transparent to traffic; GUI user
connections are lost.
Only one is active, the standby is used when the active one, or
both its links, fail.
Failure of one AMC card is transparent to traffic.

RCC = Reliable Cluster Computing

REM = Redundancy Manager
MIF and MAF data is described in the Software module of this course. The OAM Server software is
also described in the Software module.
A Host is an instance of an operating system running on hardware.
DataBlitz is a general purpose main memory database management system developed by Bell
Labs. It is responsible for synchronizing configuration data an some other databases across hard
drives on the OAM Servers. Data such as log files that are collected on the active OAM Server are
not replicated across active/standby pairs. Log files remain on the same physical blade on which
they were collected in the event of a switchover.
An unplanned event consists of any event (e.g., fault) which may impact MME
service/functionality if no proper detection/recovery takes place. The fault may be due to hardware
(blade/board failure, Ethernet interface), service/application software, or operational software. This
requires check-pointing of context information associated with each attached user.
Service and performance measurements (PMs) are collected from both blades. A small
number of counts are the same on the active and standby blades, but most counts are zero on the
standby. With a switchover, those counts are not copied over to the mate.

Platform component redundancy and switchover (2 of 2)

Component Redundancy
type
Diskless
blades
(MIF, MAF
blades)
Active/Standby
ShMC
Active/Standby
Notes
PDU
Two independent
power sources
Fans
Two independent
trays at top and
bottom of shelf
with 12
independent fans
per tray
1 12 13
Both elements are available; only one is active, the standby is

used when the active one fails.
In the event that a blade becomes unavailable:
The mate handles all procedures.
UE context data, dynamic data tables are synchronized
when blade returns to service (REM synchronization).
Both elements are available; only one is active, the standby is
Switchover has no impact on users.
Each power source can supply power to the full cabinet.
MME recovers automatically from power outages.
MME will operate indefinitely when a single power supply fails.
MME will operate when a single fan fails, but the fan tray
should be replaced as soon as possible.
Switchover of a link is less than a half second; switchover of a blade is less than 2 seconds.
A fan tray controller detects when a fan in the tray has failed and adjusts the speed of the
other fans until the fan tray is replaced.
Switchover time for links, blades, and applications are listed in the 9471 MME Technical Description
customer document.

Virtual IP address assignment

A virtual (floating) IP address is assigned to the active server or service in
a redundant pair.
RCC or REM declares one of the servers or services active.
That server or service assumes ownership of the virtual IP address.
Run the Linux command ifconfig a to display all network interfaces on server, active
or inactive.
1 12 14

Knowledge check: Redundancy

Which of the following best describes the redundancy of the MIF/
MAF pairs?
A. Lead-Active/active both elements are active, but only the
processing result of the information on the lead-active is used.
B. Active-active elements operate in duplex, and both elements
are available and active at the same time.
C. Active-standby - only one element is active, and the standby is
D. Independent the pairs are not really related
Active-standby
1 12 15

Knowledge check: Redundancy

Complete the following sentences:
1. In the event of a failure of the active MI service, switchover to
RCC
the standby MI service is managed by the _________
process.
2. If a MAF blade is rebooted, synchronization of data after the

REM
blade returns to service is handled by the _________
process.
1 12 16

2 Load distribution and overload

management
1 12 17
This topic describes how the 9471 MME manages the load.

Capacity
Parameter
Number supported by MME
Tracking area
1024 per MME
Attached UEs
2-5 million per MME with max configuration, depending on call model
Simultaneous UE connections 500,000 per MAF, any HW configuration

MPH throughput
300,000 uni-directional messages per second per MPH pair

(150,000 in and 150,000 out) at 70% processor occupancy
MIF message throughput
300,000 uni-directional messages per second per MIF pair

(150,000 in and 150,000 out) at 70% processor occupancy
Typical message size
200 bytes
MAF message throughput
36,000 uni-directional messages per second per MAF pair

(18,000 in and 18,000 out)
APN connections per UE
6 per UE
PGW IP address in HSS
6 per UE
Bearers per UE
Max 11 (combination of default and dedicated; up to 6 default)
MME
8 MME pools containing up to 8 MMEs each (64) if provisioned;

unlimited if DNS is used
SGW
Provisioned: 16 SGW per TA if provisioned; up to 80 SGW if using DNS
PGW
Unlimited (6 PDN connections per UE)
eNodeB
12,000 per MME (active SCTP required for each; only 6000 SCTP
connections supported for the M3 interface)
1 12 18
Additional capacity information is found in the 9471 MME Technical Description (418-111-200).
APN = Access Point Name
Note that if DNS is used to discover the MME, then the number of pools and MMEs per pool is
unlimited, though the number of MMEs known at one time using discovery is 128.
The M3 interface is the interface between the MME and a Multicast Control Entity (MCE).
Each customer has its own call model based on busy hour call attempts (BHCA) per UE and types of
services offered, such as VoIP, SMS, and data services. The hardware configuration required to
support 12,000 eNodeBs depends on the customer's call model.
A tracking area may support multiple eNodeBs; each eNodeB is associated with one TA.
Procedures
For the MME, procedures are very short duration transactions and can involve between 4 and 20+
messages. The duration for procedures has a large variance, from 20 msec to several hundred
milliseconds. Paging procedures can go well into the seconds. Service Request and Release
procedures, however, dominate the traffic model; having only about 6 messages/procedure.
BHCA
The term Busy Hour Call Attempt (BHCA) from EPC perspective applies to all services:
Whenever the user needs to send/receive application packets it needs to have an EPS bearer
established. The UE needs to trigger a Service Request procedure. Changes state from idle to
active.
Service Request procedure is required to change AT/UE state from idle to active (e.g., for VOIP
calls, SMS, data sessions).
A Connection Attempt includes the signaling required to establish the EPS resources (e.g.,
default and dedicated EPS bearers) and to release the resources.

UE load balancing across MMEs

Two mechanisms to distribute the load across MMEs in a pool:
The eNodeB assigns a UE to the MME based on the relative capacity.
9471 MME restricts load generated by the eNodeB on overload.
1 12 19
Load balancing between MMEs in a pool is achieved by directing UEs entering into an MME pool
area to an appropriate MME.
Two mechanisms to distribute the load across MMEs in a pool:
If provisioned, MME calculates its relative capacity (RC) based on MAF pairs and state, and
sends the RC to the eNodeBs.
The eNodeB assigns a UE to the MME based on the relative capacity.
The automatic calculation can be overridden during maintenance activities.

MME controls overload by restricting the load generated by the eNB this is used on overload
conditions.
Automatic capacity calculation
Whether or not the MME automatically adjusts the relative capacity and sends the information to
the eNodeB is provisioned for the home MME in the Home MME Node provisioning form on the
5620 SAM. The default is set to true. You can uncheck the Auto adjusts Relative Capacity
parameter to prevent the MME from updating the relative capacity.
Overload control
The OVL_START and OVL_STOP messages are used to control overload. The MME will send these
messages only when CPU occupancy is greater than 95% for all MAF pairs or for the MIF pair.
The MME will start by sending the OVL_START message to a subset of eNodeBs (about 5%)
randomly selected from all the in-service eNodeBs. Periodically (not < 30 seconds) the MME
checks if the CPU usage is still above the 95% threshold, and if true, then MME will send the
same message to more eNodeBs (still about 5% of the remaining eNodeBs) and so on, until the
condition persists.
As soon as the CPU usage is below the threshold, the MME starts to send OVL_STOP messages to a
subset of eNodeBs (~5%) from the list of eNodeBs that previously received the OVL_START
message every 30 seconds.
MME re-load balancing
Inter MME relocation

Move all registered UEs on MME to another MME in the same pool.
Inter MME relocation by percentage

Move percentage of registered UEs to another MME in the same pool.
Intra MME relocation by percentage of registered or deregistered UEs

Redistribute UEs after a new MAF pair grown.
Manually send MME capacity to eNodeB

Send MME capacity to eNodeBs
Manual MME load re-balancing is mostly used for OA&M activities of an MME, such as
moving an MME from one pool to another or redistributing UEs after system growth.
1 12 20

The MME supports the following manual load re-balancing capabilities:

Inter MME relocation
Moves
all of the registered UEs on one MME to another MME in the same pool.
Inter MME relocation by percentage

Moves
the specified percentage of registered UEs to another MME in the same pool.
Intra MME relocation by percentage of registered or deregistered UEs
Allows the redistribution of UEs after a new MAF pair has been grown.
Manually send MME capacity to eNodeB

Sends
MME capacity to eNodeBs using a range or list of eNodeBs Inter MME relocation and
manually sending capacity to eNodeBs is initiated by a manual action using the uelb_cli CLI
command.
Notes:
Manual
MME load re-balancing can be performed from the MME command line or from the
5620 SAM. (look for the load balancing topic in documentation).
MME
loading data (UE loading, MME capacity) is displayed by the 5620 SAM in the MME
Properties form.
The
number of page attempts to UEs during inter-MME UE relocation can be provisioned

separately from the number of page attempts during normal conditions.

Platform resource monitoring

Platform monitoring:
CPU occupancy
Memory utilization
Resource usage for any monitored resource
Alarms triggered when thresholds are crossed.

Alarms auto-cleared when the overload condition clears.
1 12 21
Platform mechanisms monitor resources for the OAM Server, MIF, and MAF blades, including:
CPU occupancy
Memory utilization
Resource usage for any monitored resource
Thresholds for utilization of CPU resources:
Minor 91%
Major 93%
Critical 95%
Thresholds for utilization of memory resources:
Minor 94%
Major 96%
Critical 98%
When thresholds are crossed, alarms are triggered.
Alarms are auto-cleared when the overload condition clears.
Notes:
CPU usage is calculated as an average value across all the processor cores on a board. The
overload state of a board is defined by the worst overload condition of all the resources being
monitored.
When a transition occurs in the overload state of a board, an alarm event is sent to the EMS, and
an alarm record is created
The platform software automatically clears the overload state of a board when the overload
condition ceases to exist.
The resource utilization thresholds are set so that there is enough memory to send reject messages.
Resource monitoring for MIF

MIF monitoring based on:
Utilization of the IMSI-to-MAF mapping table
When utilization thresholds are crossed:

Alarms are triggered.
No mitigation actions if the IMSI table utilization in overload.
If a MIF service is in CPU Critical Overload state, it drops all external messages.
The MME monitors the rate of UE attaches

If the rate exceeds the engineered capacity: MIF drops attaches until the rate
falls.
1 12 22
MIF monitoring is based on:

Utilization
of the IMSI-to-MAF mapping table
The thresholds for utilization of the IMSI-to-MAF mapping table are:

Minor
- 93%
Major
- 95%
Critical
- 97%
When thresholds are crossed:

Alarms
are triggered
No
mitigation actions are taken if the IMSI table resource utilization crosses into the Minor,
Major, or Critical state.
If
a MIF service instance is in CPU Critical Overload state, it drops all messages destined to be
sent or received from the external interfaces.
The MME monitors the rate of UE attaches

If
the rate exceeds the engineered capacity for attaches per second, the MIF drops attaches
until the rate falls below the engineered capacity.
Whenever the utilization crosses the Minor, Major, or Critical thresholds in the upwards direction,
the MME sends an Alarm to the MI subsystem to indicate the condition.
The thresholds are hard-coded (i.e., not provisionable).
MIF safety control
Defensive controls are provided by the MME as a safety net and to provide attach storm mitigation.
The MME monitors the rate of UE attaches handled by it. The MME supports a maximum of 5250
attaches per second, depending on the number of MAF pairs in the system. Any attaches beyond
the limit are dropped by the MIF.
Resource monitoring for MAF

MAF monitoring is based on:
Session Distributor Buffer utilization
Number of ConnectionManager in-progress procedures
When minor thresholds are crossed:

Alarms are triggered but no mitigation actions are taken
When major or critical thresholds are crossed:

Alarms are triggered
Actions are described on next slide
1 12 23

MAF monitoring is based on:

Session
Distributor Buffer utilization
Number
of ConnectionManager in-progress procedures
The thresholds for utilization of these resources are:

Alarm
Session Distributor buffer

threshold (%)
Connection Manager threshold (%)
Minor
80
80
Major
85
85
Critical
90
90
When minor thresholds are crossed:

Alarms
are triggered but no mitigation actions are taken
When major or critical thresholds are crossed:

Alarms
For
are triggered
the MAF, various actions are taken (described on next slide).
The thresholds are hard-coded (i.e., not provisionable).

MAF congestion control: procedure handling

Default: Shed procedures that generate
highest signaling.
Optional: Provision selective shedding
overload:
Target Idle UEs during major overload.
Target connected UEs during critical
overload.
Emergency and warning messages:

Not shed during minor and major overload.
If critical overload persists, emergency
messages may be shed.
1 12 24
Shed during major overload

(default):
Attach
TAU
Service Request
Downlink Data Notification
(paging)
SGs Paging Request
Handover requests
Additional procedures shed
during critical overload
(default):
Detach
Bearer-related requests
PDN connectivity/disconnect
requests
Default
MME sheds procedures that generate the highest signaling to maximize total impact and minimize
number of procedures aborted.
Selective shedding (optional)
Selective shedding overload is provisioned in the Global Parameters form at the 5620 SAM. Refer to
the 9471 MME Technical Description document for a complete list of procedures shed using the
default or optional algorithms.
For major and critical conditions, an alarm is sent and incoming procedures are rejected with a
priority that preserves active connections at the expense of adding new connections (with the
exception of Emergency requests).
With major overload, the MME notifies the eNodeB of overload conditions, and the capacity of the
MME can be reduced by the eNodeB, causing the eNodeB to direct new requests to a different MME.
Connection Manager alarm handling
If the Connection Manager is in a Major or Critical alarm condition, the MME software immediately
examines the actual Connection Manager utilization with each message being processed. If the
actual usage is below the Major or Critical alarm threshold, then the message is processed (not
rejected), even if the alarm condition still exists. Since alarm clearing is performed after a 30second wait period, the Connection Manager examination ensures that message rejection is stopped
very quickly without waiting for the alarm-clearing interval.
Emergency and warning message call handling
Emergency call messages and warning messages are not subject to the shedding algorithm under
Minor, Major, or Critical Overload. If the Critical Overload persists for a few seconds, then 100% of
non-emergency calls are subject to shedding. If the Critical Overload persists for a few additional
seconds, then emergency calls are also subject to 100% shedding. If the MME starts running out of
non-CPU resources (for example, number of UE Contexts it can store), existing non-emergency and
non-priority calls are dropped to make room for new priority and emergency calls. Existing priority
calls and emergency calls remain.
MAF congestion control: call trace and PCMD handling
Call trace
Default: Call trace suspended when a MAF is in Major or Critical overload.
Option: Provision call trace to continue during overload conditions.
PCMD
Default: PCMD collection continues when a MAF is in Major or Critical overload.
Option: Suspend PCMD collection during overload:
Drop PCMD to OAM during overload

Do not drop PCMD during overload
Drop all PCMD in minor overload
Drop all PCMD in major overload
1 12 25
Call trace and Per Call Measurement Data (PCMD) handling during overload conditions are
provisioned in the Global Parameters form at the 5620 SAM.
MME resumes sending PCMD data or resumes call trace after coming out of overload.
Drop PCMD to OAM during overload configured like this, MME only drops PCMD data from all
MAFs to the OAM.
Do not drop PCMD during overload No PCMD shedding.
Drop all PCMD in minor overload - once in minor overload, MME sends a PCMD message stop
request to any eNodeB that sends PCMD data to MME. MME does not broadcast PCMD stop request
to all eNodeBs, it only targets those eNodeBs that send PCMD data to MME. Also, MME drops PCMD
data from all MAFs to the OAM.
Drop all PCMD in major overload - once in major overload, MME sends a PCMD message stop
request to any eNodeB that sends PCMD data to MME. MME does not broadcast the PCMD stop
request to all eNodeBs, only targets those eNodeBs that send PCMD data to MME. Also, MME drops
PCMD data from all MAFs to the OAM.

MAF congestion control: eNodeB load restriction

Option: Restrict load generated by eNodeBs when MAF in major overload:
MME sends an S1AP OVERLOAD START message to randomly selected
eNodeBs with active S1 connections.
MME sends an S1AP OVERLOAD STOP message when the overload ends.
1 12 26
Service providers can optionally provision the MME to restrict the load generated by eNodeBs when
a MAF pair goes into major overload:
If
provisioned, the MME sends an S1AP OVERLOAD START message to randomly selected
eNodeBs with active S1 connections.
MME
sends an S1AP OVERLOAD STOP message when the overload conditions end.
The Global Parameter, OC Send Overload Start and Stop to eNBs provides a mechanism to
indicate whether an Overload Start messages should be sent when the MME is in an overload
condition.

Knowledge check: Overload

Is the following statement true or false:
Emergency and Warning messages are not shed during minor or
major MAF overload conditions.
True
False
1 12 27
True. If critical overload persists, emergency

messages may be shed.

9471 MME reliability features
Redundancy processes:
REM (for diskless hosts)
RCC (for diskful hosts)
Switchover types
System capacity
Load distribution
Actions taken during overload conditions
1 12 28

Describe 9471 MME redundancy and switchover processes
Explain what happens during overload conditions
1 12 29

References
related to 9471 MME system reliability:
9471 MME Technical
Description
(418-111-200)
Describes:
9471 MME reliability features
Redundancy
Overload behavior and congestion control
Switchover times

1 12 30

1 12 31

End of module
9471 MME System Reliability
1 12 32

Section 1
9471 MME Overview
Module 13
9471 MME Management Interfaces

Technical Overview

Blank page
1 13 2
9471 MME Overview 9471 MME Management Interfaces

Document History
Edition
Date
Author
Remarks
01
YYYY-MM-DD
First edition

Module objectives
Name the interfaces used to manage the 9471 MME

Identify typical tasks performed from each management interface
Log into the MI-Agent and the OAM Server command line interface
View hardware and software status
1 13 3
This module provides an overview of the tools used to manage the 9471 MME.

Table of Contents
1 OAM&P architecture
2 Overview of 5620 SAM
3 Quick tour:5620 SAM
4 Local OAM&P interfaces
5 Quick tour: MI-Agent
6 PCMD overview
1 13 5
Page
7
10
18
24
32
56

1 OAM&P architecture
1 13 7
This topic provides an overview of the OAM&P design strategy for the 5400 LCP and 9471 MME.

OAM&P architecture (1 of 2)
OAM&P management levels:
Network Management Level (NML)
Element Management Level (EML)
Network Element Level (NEL)
NML
Network
x
Management
System
EML
5620
SAM
NEL
9471 MME
OAM Server
1 13 8

The Alcatel-Lucent OAM&P architecture is based on the standard International Telecommunication

Union (ITU) Telecommunication Management Network (TMN) model. Following the model, the 9471
MME can be managed from the:
Network
Management Level (NML)
Element
Management Level (EML)
Network
Element Level (NEL)
SNMP = Simple Network Management Protocol

SCP = Secure Copy Protocol
SSH = Secure Shell

OAM&P architecture (2 of 2)
Network
Management
x
System
NML
Web-enabled
User Interface,
CLI
5620
SAM
Alarms
Events
PM trap events
Configuration
File transfer (PM)
SNMPv3
NETCONF
SCP/FTP/sFTP
Access to
MME user
interfaces
SSH, https
EML
NEL
9471 MME OAM Server

Web-enabled
User Interface,
CLI
MI-Agent
CLI
8950 ID GUI
Direct access to CLI via

faceplate:
OAM Server
Ethernet Hub
ShMC
MME
maintenance
terminal
1 13 9

The 5400 LCP Management Interface Agent (MI-Agent) is the central interface for the most local
FCAPS operations and is the main focus of this course.
The 9471 MME is managed at the element level using the following user interfaces:
MI-Agent
GUI for most OA&M tasks
Command
The
Line Interface (CLI)
8950 ID GUI for centralized login and password management
The MME user interfaces are described later in this module.

From the Alcatel-Lucent 5620 Service Aware Manager (SAM), users can monitor and configure the
9271 MME, as well as view performance measurements and statistics.
Alarms
SNMP
Users
and events are forwarded to the 5620 SAM using the SNMP protocol..
Traps are sent to the 5620 SAM when a performance measurement file is generated.
The 5620 SAM then retrieves PM files using FTP.
can log into the 9471 MME from the 5620 SAM using a cut-through.
The functions of SAM are described in the next section of this module.

2 Overview of 5620 SAM
1 13 10
This topic provides a a high-level over view of the 5620 SAM and the services it provides to the
9471 MME.

Network elements managed by the 5620 SAM

The 5620 SAM manages the following LTE network elements:
9471 MME
7750 SR (SGW or PGW)
5780 DSC (PCRF)
eNodeB
1 13 11
SR = Service Router. The 7750 SR is used as an SGW or a PGW in the Alcatel-Lucent LTE.
DSC = Dynamic Service Controller. The 5780 DSC is used as a PCRF in the Alcatel-Lucent LTE.
The 5620 SAM is capable of providing element, network, and service management. In addition to
managing the LTE ePC network elements, the 5620 SAM also manages 7705 Service Aggregation
Routers (SARs) and 7750 Multi-Layer Switches (MLSs) at IP backhaul edges.
Training for the 5620 SAM is provided by the following course: Alcatel-Lucent 5620 SAM
Fundamentals (TOS36033).
For information about the 5620 SAM, see the Alcatel-Lucent 5620 SAM LTE User Guide (3HE
06981).

Functions provided by 5620 SAM: FM

Fault management
Mme<alarm name>
Alarm and event traps forwarded using SNMPv3.

5620 SAM supports
Listing alarms
Clearing alarms
Turning on or suppressing alarms by severity type
View and perform state/status queries of MME

managed objects.
Cut-through to the MI-Agent GUI or the OAM
Server CLI.

Web-enabled
User Interface,
CLI
SNMPv3
SSH, https
5620 SAM users can:
1 13 12
5620
SAM
9471 MME
OAM Server
The 9471 MME forwards alarm and event traps to 5620 SAM using SNMPv3 interface for
centralized monitoring of the network.
5620
SAM supports listing, clearing, turning on or suppressing alarms by severity type.
5620 SAM users can:

View
and perform state/status queries of MME managed objects (chassis, shelf, blades).
Cut-through
to the MI-Agent GUI or the OAM Server CLI using an SSH or https interface to
perform local fault analysis and management tasks.
A SAM administrator gains access to an MME using a secure interface. To enhance the security, this
interface is in a different subnet from the IP addresses used by the MME signaling and bearer
control interfaces.
The list of known 9471 MME alarms are prefixed in 5620 SAM with "Mme" so that 9471 MME alarms
can be differentiated from 5620 SAM generated alarms. If the 5620 SAM receives a trap from the
9471 MME that the 5620 SAM cannot interpret, the alarm is prefixed with MmeUnknown. Alarms
must be cleared from the 9471 MME.

Functions provided by 5620 SAM: PM

Performance management
PM file notification sent using a SNMP trap.
5620 SAM automatically retrieves XML PM files via
SCP when a trap is received.
5620 SAM collects and displays MME load:
Number of MAF slots occupied

Number of registered connected UEs
Number of registered idle UEs
Number of de-registered UEs
MME capacity and MME auto capacity flag
5620
SAM
Web-enabled
User Interface,
CLI
SNMPv3
SCP
9471 MME
OAM Server
1 13 13

PM = performance management and also performance measurement

The 9471 MME sends a SNMP trap to the 5620 SAM when a new PM file is generated in XML
format.
5620
SAM automatically retrieves and stores XML PM files from MME via SCP when a trap is
received.
The 5620 SAM collects and displays MME capacity data:

Number
of MAF slots occupied
Number
of registered connected UEs
Number
of registered idle UEs
Number
of de-registered UEs
MME
capacity and value of MME auto capacity flag
Number of MAF slots occupied = relative number of subscribers vs. memory limited subscriber
capacity.
An MME auto capacity flag value of TRUE means the MME uses calculated capacity; otherwise the
MME uses provisioned capacity as MME capacity).

Functions provided by 5620 SAM: CM

Configuration management
Provisioning commands sent to MME using the
NETCONF.
5620 SAM users can:
Set up communication and management policies
for the MME.
View and modify MME application parameters.
Perform bulk provisioning.
Perform load re-balancing by redistributing the
UEs.
5620
SAM
Web-enabled
User Interface,
CLI
NETCONF
9471 MME
OAM Server
1 13 14
CM = configuration management
Provisioning commands are sent to the 9471 MME using the NETCONF protocol.
5620 SAM users can:
Set up communication and management policies for the MME.
View and modify MME application parameters.
Examples: Paging policy, MME pools, interfaces

Perform bulk provisioning. Examples:
MME pool growth
Tracking areas
Critical Performance Indicators (CPIs)
Diameter profile
Emergency number list

Perform load re-balancing by redistributing the UEs between MMEs or within an MME
The NETCONF protocol provides a mechanism to install, manipulate, and delete the configuration of
the 9471 MME applications from the 5620 SAM.
Application parameters include things like IP endpoints for EPC peers, paging policy, Public Land
Mobile Network association, Tracking Area association, and MME pools.
Note that platform configuration procedures are performed from the local 9471 MME management
Interface (MI) GUI. These include configuration of subnets, static routes, Domain Name Server
(DNS), and Network Time Protocol (NTP).
Users can provision MME-based parameters individually or using bulk provisioning from 5620 SAM.
Bulk provisioning may be performed on parameters like MME pool growth, tracking areas (TAs), TA
neighbor lists, eNodeB to TA mapping, TA to Location Area Identity (LAI) to MSC mapping, and GTP
profiles, SCTP profiles.
NETCONF vs SNMP views in the 5620 SAM

MME management from the 5620 SAM is subdivided into two main areas:
Logical object monitoring through SNMP
Configuration Management through NETCONF
(NETCONF, read and write)
Logical object monitoring

(SNMP, Read only)
1 13 15
The view displayed in the graphic on the left is the standard view shown from the Navigation tree.
(Click the Navigation tree icon if the tree is not visible, and then select Equipment view. Click
the plus signs next to the Equipment to show details.) In the example, the MAF blades in slots 3-4
are expanded to show that the MAF service on blade 4 is providing service, and the MAF service on
blade 3 is hot standby. There is a minor alarm on blade 4.
The view displayed in the graphic on the right is an MME instance view (select Manage > Mobile
Core > MME Instances). The MME provisioning tables are listed on the left panel (these are
read/writable). The status of the MME instance and its components can also be seen from this view
(SNMP, read only).
Simple Network Management Protocol (SNMP) is part of the Internet Protocol Suite defined
by the IETF. It is an Internet standard for monitoring the elements in an IP network. SNMP traps
are sent from the MME to the SAM.
Network Configuration Protocol (NETCONF) is an IETF network management protocol that
provides mechanisms to install, manipulate, and delete the configuration of network devices. A
NETCONF Request is sent from the SAM to the MME. The SAM receives a NETCONF Response from
the MME.

NETCONF and SNMP configuration for MME management
NETCONF
Dedicated user account is required on the MME for NETCONF:
At the 9471 MME: A user is manually preconfigured.
At the 5620 SAM: The NETCONF user credentials configured as part of the
mediation policy.
SNMP
SNMP must be set up:
At the 9471 MME: the MME must be enabled to send SNMP traps.
At the 5620 SAM: The SNMPv2c or SNMPv3 mediation policy is configured.
1 13 16
NETCONF
A dedicated user account is required on the MME for NETCONF provisioning and CLI access.
At the 9471 MME: A user is manually preconfigured.
At the 5620 SAM: The NETCONF user credentials must be configured as part of the mediation
policy in order for SAM to discover the NETCONF objects on the MME.
SNMP
SNMP must be set up:
At the 9471 MME: the MME must be enabled to send SNMP traps.
At the 5620 SAM: The SNMPv2c or SNMPv3 mediation policy must be configured
Notes:
Using an existing MME user for the NETCONF user (such as lss) is not supported.
To view the mediation policies at the 5620 SAM: From the main menu select Administration
> Mediation.
To verify that the sending of SNMP traps are enable at the 9471 MME: In the CLI enter
miconfig get PMFileEvent (should be set to true).
If the NETCONF user credentials are wrong but the SNMP credentials are correct, the MME will
be discovered but the NETCONF tree will be empty. You will also see a ResyncFailed alarm and
a message in the EMS server log When the NETCONF Credentials are wrong.
Procedures to set up a NETCONF user and configure SNMP and NETCONF mediation policies to
manage the MME from the SAM are described in the 5620 SAM Management Configuration
section of the 5620 SAM LTE ePC Users Guide.
Procedures to enable and verify SNMP traps at the MME are found in the Performance
management section of the 9471 MME OAM&P document.
User configuration at the MME is described in the 9471 MME Security Management document.
Knowledge check: 5620 SAM

Which of the following 9471 MME OAM&P tasks can be performed
from the 5620 SAM? Select all that apply.
A.
B.
C.
D.
Application provisioning
Alarm monitoring
Log in to the MI-Agent
Bulk provisioning
1 13 17
A, B, C, D

3 Quick tour:5620 SAM
1 13 18
This topic provides a brief view of the 5620 SAM management system.

Launching the 5620 SAM GUI client

Double-click
the 5620
SAM Client
App icon
Enter Login name

and Password
Default Login
Login Name: admin
Password: 5620Sam!
Click on the Login button

1 13 19
To start the 5620 SAM GUI Client from a Microsoft Windows machine:
1. Double-click on the shortcut icon that was created on your desktop when the software was
installed. The 5620 SAM login window appears.
2. Enter the appropriate Login Name and Password, and click on the Login button.
The 5620 SAM GUI opens.
To start the 5620 SAM GUI from a UNIX machine:
1. As root in the bash shell, navigate to the appropriate bin directory in the 5620 SAM client
installation directory, for example the c:/<sam directory>/client/nms/bin directory.
2. Start the 5620 SAM client by typing nmsclient.bash. The 5620 SAM login window appears.
3. Enter your Login Name and Password, and click on the Login button.
The 5620 SAM GUI opens.

NEs viewed from the 5620 SAM
1 13 20
The 5620 SAM manages the 9471 MME as well as the 7750 SGW or PGW, and the 5780 DSC in the
ePC network.
The Network tree is displayed here to show the Equipment view on the left, the Topology view on
the right, and alarms at the bottom.
Note that screen captures were taken in a lab environment and thus show multiple alarms dues to
testing.

GUI components
Menu bar
Tool bar
Navigation
tree
Working
pane
Dynamic
alarm list
Task bar
Status bar
1 13 21
There are seven (7) basic components to the 5620 SAM GUI. They are the:
Menu Bar used to execute tasks
Tool Bar provides shortcuts for Menu functions
Navigation Tree Window displays all managed equipment, services, and protocols
Working Window Pane displays drawings and configuration forms
Dynamic Alarms List displays incoming events and alarms
Task Bar used to track all currently opened windows of the client session.
Status Bar displays user account, date, redundancy, alarm-related object, propagation, and
connection status information.
Using the Menus, the Toolbar, or Shortcuts:
Open the 5620 SAM GUI.
Choose a menu:
From the drop down submenu options under each top-level menu. An applicable shortcut icon
for that menu function is shown next to the options text.
From the menu equivalent in the Toolbar. Scrolling over the icons will display their function.
By typing the appropriate ALT+Key shortcut. For example, ALT+P opens the policies menu.
The underlined letter indicates the shortcut action.

MME instance management

To access an MME instance:
1. Select the MME in the Equipment Manager
2. From the main menu, select Manage > Mobile Core > MME Instances.
Equipment Management
Mobile/LTE Management
MME form
1 13 22
The MME instance logical object in SAM is used to differentiate between Equipment management
and Mobile/LTE management.
Equipment management is managed through standard SAM equipment views shown on the
previous slide. It includes inventory, status, hardware, and alarms management.
Mobile/LTE management is managed through the MME instance logical object that is
associated with each MME. It includes management of reference points (interfaces), EPS peers, LTE
profiles, LTE alarms, provisioning, etc.

Access to the 9471 MME user interfaces from 5620 SAM

From the 5620 SAM GUI:
1. Right click the 9471 MME in the Equipment Manager and select an NE
session:
Telnet or SSH session to access the lead OAM Server CLI

Launch MI GUI to access the MI-Agent GUI
2. Log in using the appropriate MME user login and password.
1 13 23
References:
Training for the 5620 SAM is provided in the following course: Alcatel-Lucent 5620 SAM
Fundamentals (TOS36033).
5620 SAM procedures for the MME are found in the 5620 SAM LTE ePC User Guide.
The 9471 MME cut-through procedure is explained in detail in the User Interfaces section of the
9471 MME OAM&P documentation.
The 5620 SAM shortcut icon is created when the SAM client software is installed.

4 Local OAM&P interfaces
1 13 24
This topic provides a high-level overview of the OAM&P interfaces provided by the 9471 MME.

Local 9471 MME OAM&P interfaces
MI-Agent GUI
CLI
8950 ID GUI
1 13 25
The 9471 MME network element includes the following user interfaces to perform OAM&P activities:
MI-Agent
GUI hosted on the OAM Server (also called the MI GUI)
Command
8950
ID
Line Interface (CLI) to each sub-network element

GUI for user administration
IMPORTANT: Beginning in LM5.0, 9471 MME application provisioning tasks are performed from
the 5620 SAM. The 9471 MME Provisioning GUI is not supported in LM5.0.

Standard functions provided by the MI-Agent
MI-Agent GUI
Fault management
Monitor the system
Collect system events and logs
Display state information and alarms for fault events
Hardware discovery, audit, state management

Software management: backup, restore, software update
Provision northbound interface to EMS
Provision interfaces
Performance management
Set performance data collection parameters

View collected performance data
Forward collected data to upstream systems
Overload monitoring and control
Security management
View security logs and audit trails

Specify security alarm triggers
1 13 26
This slide lists the general platform OAM&P functions provided by the MI-Agent. These functions are
described in the MI-Agent quick tour section at the end of this module.
The MI-Agent is used for most maintenance tasks. The GUI is organized according to the FCAPS
model, with a section of network maps that are used to describe and monitor the sub-network
elements (SNEs). The MI-Agent does not perform accounting management tasks.

Additional functions provided by the MI-Agent
MI-Agent GUI
MI-Agent collects measurement data specific to the 9471 MME and LTE:
Failure-Percentage for UE access to the LTE network

Number of successful attach requests
Maximum and average number of ACTIVE and IDLE UEs
Average number of default bearers
1 13 27
This slide describes the key OAM&P functions that are provided by the MI-Agent specifically for the
9471 MME.
The following MME-specific functions can be performed from the MI-Agent:
Collect key measurement data specific to the 9471 MME and the LTE network. For example*:
Failure-Percentage
Number
of successful attach requests
Maximum
Average
for UE access to the LTE network
and average number of ACTIVE and IDLE UEs in the current measurement period
number of default bearers
* A complete list of performance measurement counters is found in the 9471 MME Observation
Counters document (418-111-209).

Command Line Interface overview
Each card can be logged on to at an OS level.

Each host:
Observes OS files and directories
Executes commands
Can be used to view log files
When to use the CLI:

MI-Agent GUI recommended for most tasks.
Some GUI tasks can be performed from the CLI.
Some tasks require CLI.
1 13 28

Each of the MME cards is a computer unto itself and can be logged on to at an OS level.
Each host:
Observes
standard OS files and directories.
Executes
application-specific commands.
Can
be used to view application-specific log files.
When to use the CLI:

The
MI-Agent GUI is recommended for most tasks.
Some
Some
GUI tasks can alternatively be performed from the CLI. Example:

Scheduling PM collection, viewing status
tasks require the use of the CLI. Examples:
Manual software backups and software updates
Initial system installation and IP configuration
Hardware replacement
MME-specific commands to start a trace, display UE data, lock links, etc.
Emergency access when the MI-Agent is not available
OS = operating system
OS for OAM Server and diskless cards is Red Hat Linux
OS for the Hubs is MontaVista Linux
OS for the ShMC is Pigeon Point Linux
The customer documentation indicates where CLI procedures are required.

CLI
Command Line Interface access methods
CLI
Routine access:
From the MI-Agent, access the CLI of any sub-network element.
The system logs into the OAM Server and runs an SSH session to the element.
From the 5620 SAM, SSH to CLI.

The system logs into the OAM Server.
Special procedures:
Serial over LAN (SOL) connection.
Serial connection using terminal server.
Connect a terminal (laptop) directly to the debug port.
Access methods depend on the procedure. Always follow the method specified in the
customer documentation.
1 13 29
Routine access:
From the MI-Agent, access the CLI of any sub-network element.
The system logs into the OAM Server and runs an SSH session to the element.
Used for routine maintenance procedures, browsing log files and data structures, etc.
From the 5620 SAM, open the MME Properties window and click SSH.
You will be logged in to the OAM Server.

Special procedures such as system installation and troubleshooting:
Set up a Serial over LAN (SOL) connection.
SSH from a remote Linux maintenance terminal to the Hub using SOL IP
From the Hub, set up a console session to the other blades
For remote access and procedures where console access is required (software update).
Set up a serial connection using a customer-provided terminal server.
Connect a terminal (laptop) directly to the debug fast Ethernet port or console port (CP) on the
faceplate of the blade. Typically only used for debug.
Serial Over LAN (SOL) enables the input and output of the serial port of a managed system to be
redirected using an Intelligent Platform Management Interface (IPMI) session over IP.
On blade server systems, the serial ports are not normally connected to a traditional serial port
socket. To access applications on the blades via the serial port, the input/output of the serial port is
redirected to the network, and you must SSH to a network address and log in.
The SOL connection allows you to set up a console session so that administrative output messages
can be observed during procedures.
SOL access requires a Red Hat Linux maintenance terminal with SOL client and SSH installed.
Customers may use SOL or a terminal server to provide serial access from a remote site.
Knowledge check: 9471 MME OAM&P interfaces

Match the management interface you would use to perform each of
the listed tasks (some tasks could be performed from more than
one place).
Task
5620 SAM
1. Change MME Paging parameters

2. View the state of an element
3. Monitor the system for faults
4. View performance data

5. Run a call trace
MI-Agent
GUI
MME CLI
6. Replace an Ethernet Hub

7. Modify S6a interface parameters
1 13 30

Knowledge check: 9471 MME OAM&P GUI access

What port number would you add to the MI Service floating IP
address to access the 9471 MME MI-Agent GUI:
MI-Agent GUI
9090
http://135.2.26.132:_______
MI-Agent GUI
8443
https://135.2.26.132:_______
1 13 31

5 Quick tour: MI-Agent
1 13 32
This topic demonstrates some of the capabilities of the 9471 MME MI-Agent GUI.

Log in to the MI-Agent from a maintenance terminal
1. At a maintenance terminal, open an Internet Explorer browser and enter:
http://<MI Service floating IP address >:9090, or

https://<MI Service floating IP address >:8443
2. Click Web Start Client

3. In the login window, enter
user name and password.
login
The MI IP address is the external floating service IP address of the MI service.

All active pop-up blockers must be turned off in Internet Explorer.
The URL can be used in place of the floating IP address.
1 13 33
9090 and 8443 are the port numbers.

The MI-Agent GUI can also be invoked from the element management system (5620 SAM) using
secure http.
Log-in rules
The 5400 LCP uses Role-Based Access Control (RBAC) to manage user security.
If you have trouble performing specific tasks at the MI-Agent or the command line interface:
Refer to the topic Centralized password management and role based access control in the
Platform Security chapter of the Alcatel-Lucent 9471 MME Security documentation for
information about roles and login permissions.
Verify that the login and group to which you are assigned has appropriate permissions to
perform the task.
If necessary, consult your security or system administrator.
RBAC allows security administrators to set up logins based on tasks performed by users. Users are
able to access systems and information based on their role within the organization.
A set of default users is included with installation: root, lss, sysadmin, secadm (security
administrator), and trainee.
Emergency access with root and lss account is possible at all the times. Note that root is NOT a
superuser.
Notes: Customers may have specific login procedures and/or centralized login methods. Follow the
method that is supported at your facility.
Log in to the MI-Agent assumes that appropriate terminal server settings and software have
previously been set up. Maintenance terminal requirements are described in the 9471 MME OAM&P
customer document (418-111-201).
Screen layout
Menu bar
Toolbar
Tree view
organized by
FCAPS
Map view
Alarm count
panel
Status bar
1 13 34

Network maps
In the Management Interface tree, select Network Maps > System Name
1 13 35
The Network Map shows the elements configured in the system.

The top element in the tree is the LCP system, which shows the shelves in the frame.
Network maps are created by the discovery process.
Some navigation notes: The right pane does not always have a scroll bar. To close windows in the
right pane, click the x in the upper right corner of the window.

Shelf view LM3.0 hardware
Select Network Maps >System Name > Managed Element Name > Shelf #
Rollover help
2
From any hardware view, rightclick to call up a menu of

actions that can be performed
on that sub-network element.
The actions are also available in
the Managed Objects Menu.
1 13 36

The Shelf view shows the all of the components in the shelf and their status. Cards shown in this
example from LM3.0 hardware configuration:
Slots
1-2 host OAM Servers
Slots
3-4 host the MIF
Slots
5-6 host the MAF; remaining empty slots support additional MAFs
Slots
7-8 host the Hubs
Slot
15 hosts the ShMC (top and bottom)
In this example, the MME has 16-GB MIF cards. 32-BG MIF cards would be in slots 13-14 and would
have RTMs and AMCs. 32-GB MAF cards would have AMCs see next slide.

Shelf view LM4.0 hardware
Rollover help
2
From any hardware view, rightclick to call up a menu of

actions that can be performed
on that sub-network element.
The actions are also available in
the Managed Objects Menu.
1 13 37

The Shelf view shows the all of the components in the shelf and their status. Cards shown in this
example from LM4.0 hardware configuration:
Slots
1-2 host OAM Servers
Slots
3-4 host the first pair of MAFs (these include an AMC card, which will be used in a future
relase)
Slots
5-6, 9-10, 11-12 host additional MAF pairs
Slots
7-8 host the Hubs
Slots
13-14 host the MIF pair (these include an AMC card and SS7 RTM, which will be used in a
future release)
Slot
15 hosts the ShMC (top and bottom)

Card-host view OAM Server

> node name.
Host
status
CNFG
Service
MI
Service
SNS
Service
SNMP
interface
Status of diskful
card
Midplane port status

Faceplate
port status
1 13 38
SNS = Shared Network Service, the service required for external DNS lookup.
A solid green pill indicates the component is active in an active/standby pair; or the lead-active in
a lead-active/active pair.
Red indicates that ports are not functioning or are not used.
For Hubs, you would scroll right to see the RTM port status.

Meaning of key status icons (1 of 2)

Initialization is
indicated by a
broken green
capsule.
Disabled
operational
state is
displayed
during
hardware
replacement
(fru_cli)
Overload is
indicated by a
thermometer.
1 13 39
The list of status icons and their meanings are also found in the User Interface section of the
OAM&P customer documentation.
The Unknown status is normally seen for a brief time during transient states, such as switchover or
initialization. A card that is improperly powered off, inserted in a slot, or taken out of service may
display the Unknown icon, and alarms may be generated.

Meaning of key status icons (2 of 2)
Identifies the
standby in an
active/standby
pair; or the
active in a leadactive/active
pair.
Identifies the
active in an
active/standby
pair; or the leadactive in a leadactive/active
pair.
Locked icons
include a small
graphic of a lock
1 13 40

Accessing the CLI of the host
Right-click the host and select CLI Access.

mme24
Host
area
mme24
Host name format:

system-shelf#card#host#
mme24
1 13 41
Note that you can perform other actions on the host from this menu, including display alarms and
power the host up or down (Physical Host Control menu item).
From the CLI window, you can SSH to other cards in the system using their IP address or host
name.

Service Members menu

Navigate to Network Maps > System > Shelf > Service Members
Member 0 and1 in
Pool 0
Standby
Active
5
6
1 13 42

Provides IP addresses and status of services.

The following services are displayed in the Service Members menu:
Configuration
(CNFG)
Management
Interface (MI)
MME
Application Function (MAF)
MME
Interface Function (MIF)
MME
Packet Handler (MPH) a future service that will terminate external signaling to offload
the function from the MIF
Shared
Network Service (SNS) for DNS access

Service Members: IP addresses
5
6
1 13 43
Hosts
MI
have both fixed and floating IPs when active.
has an external fixed IP in order to log in.
Internal
There
IP addresses are used by internal services, like log file forwarding.
is one floating IP for each external connection (some may not be used).
Note that some external floating connections are not used, but are part of the standard
configuration. For example, the CNFG Service has two floaters one is for coordinating
configuration changes with an external DNS service, which may or may not be used by customers.

Interfaces: IP addresses
eNodeBs communicate with MME using this IP
1 13 44
The 9471 MME communicates with other network elements in the network using external network
interface IP addresses.
For example, eNodeB uses the S1-MME IP address to communicate with the 9471 MME.
In this example, the MME uses single-homing for SCTP interfaces.

Fault management tree
Right-click an alarm to
access Help page
specific to that alarm.
Alarm summary is
always present; select
bar, table, or pie format.
1 13 45
Tasks:
View alarm severity, probable cause, impacted components; filter alarms
Call up step-by-step clearance procedures
View, search, and filter system events.
The FM tree is used to view alarms, severity, probable cause, impacted components. Alarms can be
filtered according to various criteria (severity, component, etc.).
Alarm clearance procedures:
Alarm clearance procedures: Right-click any alarm and in the context menu and click Help. The html
page that contains the Alarm clearance procedure is displayed.
You can also search the Alarms manual using the alarm name string.
Alarm summary:
Just below the Tree view, the Alarm Summary view shows the alarm counts for each severity of
alarm in each category, and the total of each severity in the main frame. This panel is updated
automatically, and the counts can be seen all the time, irrespective of the functional view.
By clicking the counts in the alarm count panel, the respective alarms are displayed in the panel on
the right.
Alarm summaries can be viewed as Table, Bar graph, or Pie chart
Events:
Events provide more details about what happened at the time an alarm was generated. Events
themselves may or may not trigger an alarm. Example of events include state changes,
configuration changes, power up or down.

Configuration management tree
View software versions, hardware description

Backup configuration and database files
View software upgrade completion information
Modify some IP addresses. These tasks may be service impacting.
1 13 46
The Configuration Management tree is mainly used to schedule backups and perform manual
backups.
The other tasks performed from the CM tree are not everyday tasks. Tasks include:
View hardware inventory
Manage software
View network interfaces and their IP addresses
Modify IP addresses for default gateway and static routes
Inventory: View card descriptions, software versions, serial numbers.
Backup Management
Scheduling - Schedule regular and one-time backups for system components. The backup copies
configuration data and also database files for cards that have databases. Backup files are stored in
a backup directory on each OAM Server and may be FTPed to another site.
Backup Status - View the date, time, and success status of recent backups.
Login administration set passwords and logins to backup components that are not managed by
Centralized Password Management function. This function is not needed by the 9174 MME.
Backup Configuration - shows the number of configuration backups by element.
Upgrade Management - Used to support system upgrade procedures.
IP configuration trees
All IP addresses are manually configured using CLI commands during system setup and are typically
changed with CLI commands. Static routes, network interfaces for services, and default gateways
can be modified here at the MI-Agent GUI.
Changes to these parameters can impact service and are not routine tasks.
Default Gateway view and modify the default gateway IP address. Default gateway (default route)
is the network route used by a router when no other known route exists for a given IP packet's
destination address.
Network interface - modify the network IP addresses for a service.
Static Route modify IP addresses for static routes. Static routes are those that are manually,
rather than dynamically assigned.
Performance management tree
Collect and view data about system performance, such as

CPU capacity.
Collect and view data about call-processing performance; for

example, number of successful attaches
1 13 47
Tasks:
Poll and view statistics by host
Schedule XML-based performance measurements to be collected from sub-elements at regular
intervals and forwarded to upstream system
View xml PM reports
Polled Data
Use Polled Data to view statistical information about hosts. You can select objects to poll, set
thresholds, and view polled data reports. For example, you can set a threshold for a minor, major,
and critical alarms to trigger when CPU capacity reaches certain percentages. The example is
showing polled data for the local host (MI).
XML Report Scheduling
Schedule regular performance measurements to be collected at specified intervals. A PM
measurement job includes single or multiple measurements for one or more network elements. The
PM measurement jobs are divided into the following categories:
Traffic measurements - for signaling and OAM related measurements. A standard set of traffic
measurements is configured for the 9471 MME.
SNMP measurements - for IP network related measurements. The SNMP protocol is used to
collect measurements, and includes measurements for the Hubs and CNFG Service.
TL1 measurements - for networks elements that use the TL1 language. Not used by MME.
XML Reports
Allows you to view XML files that contain performance data collected from different sub-network
elements.

Security management tree
Example audit browser
1 13 48

Tasks:
View security logs and audit trails
Specify security alarm triggers
Management Interface Security Audit
Lists Security Logs and Audit Trail Logs and
Alarm Control
Allows you to specify security alarm triggers.
The recommended interface for the user account management is the Alcatel-Lucent 8950 ID
Identity GUI. The CLI can be used for the emergency access in case the Alcatel-Lucent 8950 ID
Identity GUI is not accessible. This GUI is accessible only by the Security Administrators or an
equivalent user with the corresponding privileges. User account management is not described in
this course.

Tools tree
1 13 49
Tasks:
View
Use
details about managed objects
SNMP tools to
Load and view the system MIBs
Set up the SNMP interface the Northbound interface
Set up SNMPv3 security (normally performed by a security administrator)
MIBs, or Management Information Base, are the set of data used to describe and manage system
objects.

Tools menu
1 13 50
In addition to the Tools window, there is also a Tools menu.

Tasks:
Perform and track a global discovery
View your permission level
Change runtime defaults and parameters
Change your password
Global Discovery
Perform global re-discovery of equipment and update the MI database. Discovery is the process of
adding information for a card or sub network element (SNE) in the MI GUI database so that the MI
GUI can manage the SNE. Discovery takes place automatically during growth procedures, but may
need to be performed when hardware is updated.
Discovery Status
Track progress of the global discovery, since it sometimes takes a while to complete.
User Roles
View permissions related to a role.
Runtime administration
Change MI runtime configuration without restarting the server. For example, change polling or
alarm filters, disable discovery, set the number of log files stored on the system. Normally
performed by a system administrator.
Security Administration
These tasks are normally performed at Alcatel-Lucent 8950 ID GUI by a security administrator.
Change Password
Change your own password.
Help files
View online customer documentation:
1 13 51
Note that the HTML documents must be loaded into the system. They may be updated in between
software updates to include new information.

Knowledge check: MI-Agent

The MI-Agent Network Map view shows the ________________________.
A. MMEs configured in the ePC network
B. elements configured in the MME system B
C. element management systems that interface with the MME
1 13 52


What is the status of MAF service member number 1 in the window below?
A. Out of service
B. Degraded
C, the red and green identifies the standby in an active standby pair.
C. Standby
5
6
1 13 53


The following prompt is displayed in an MME CLI window. What user is this
and where is the user logged in?
<lm12-s00c02h0:sysadmin>/sysadmin
#
User sysadmin, logged into the OAM server in slot 2 on shelf 0 of the system named lm12.
1 13 54


How do you access online customer documentation from the MI-Agent?
Select Help > Help Contents.
1 13 55

6 PCMD overview
1 13 56
This topic provides a high-level overview of the Per Call Measurement Data (PCMD) and its uses.

PCMD overview
Diagnose and troubleshoot connection data:
How long did a procedure take?
What quality was maintained?
What was the performance of each bearer?
What was the RF coverage?
What was the data throughput?
How did the procedure end?
What events occurred?
1 13 57
MME
Data
collection
eNodeB
Data
collection

Provides real-time diagnostics and troubleshooting tool for connection information such as:
Duration
Quality
of each UE procedure
and disposition of the UE connections
Important
events that occurred, such as Connection or handover failure
Collects selected measurement data for every UE connection

Complements cumulative PM counters
Individual
connections can be analyzed
Data collected at:

eNodeB
9471
MME
The PCMD function is complementary to performance measurements . PCMD provides a more

detailed method of reporting system performance data than is possible with performance
measurement counters, which relies on cumulative counts that cannot be used to analyze how
individual UEs interact with the MME.
PCMD is collected at both the eNodeB and the 9471 MME. The 9471 MME serves as the coordinator
of the PCMD data.
For details about PCMD, see the Alcatel-Lucent LTE Network PCMD Reference Guide (417-111-009).

PCMD collection
9471 MME:
Starts and stops collection for MME
and eNodeBs
Collects PCMD records from MME
and eNodeBs
Integrates all data for a UE
connection from all participating
eNodeBs with own data into one
record.
Stores files to disk (OAM Server)
Allows data to be retrieved by a
remote host
1 13 58
Real-Time Client
(optional)
PCMD is collected at both the eNodeB and the 9471 MME. The 9471 MME serves as the coordinator
of the PCMD data.
The eNodeB collects PCMD records under the 9471 MMEs instruction and sends its PCMD data to
the 9471 MME. After PCMD is turned on at the eNodeB, the eNodeB collects PCMD data for each UE
that it services and forwards the data to the MME that is currently handling the UE.
The 9471 MME integrates all the PCMD data for a UE procedure from all the participating eNodeBs
with its own data and generates a single PCMD record. Hence saved PCMD records are perprocedure records, and a subset of the data contains information from the eNodeB. The UE PCMD
record is saved to the OAM Server.
PCMD records are generated when an LTE procedure ends either successfully or unsuccessfully. If
enabled, all UE calls are logged at all times.
Optional: A client at a remote data collection server is notified that a new file is ready, and the file
can be pulled from the OAM Server by the remote client. (The client can ssh into the OAM Server
and run the pcmdExport tool, which will notify the client when a file is ready to be pulled.)
A remote near-real-time processing application such as the Alcatel Lucent Network Performance
Optimization tool may be connected to the 9471 MME using ssh to retrieve the PCMD records as a
near-real-time data stream.
Starting and stopping collection: PCMD collection is started and stopped from the PCMD form
of the 5620 SAM.
IMPORTANT: To include eNodeB data, eNodeB collection must first be enabled on the eNodeB
this is done from the eNodeB Properties form at the 5620 SAM.
You can provision the MME to either stop or continue PCMD collection during overload conditions.
PCMD uses
Troubleshoot:
Evaluate UE performance
Determine failure scenarios
Analyze RF coverage
Capture the following:
400
400
Cell Number
RTD
Cell Number (+:SN50,-:SN53)
300
300
HWid 132672fa
07/23/2008
Philadelphia +
Plymouth1
200
200
100
0
100
-100
0
-200
-300
-100
-400
1 13 59
2:00:00
1:55:00
1:50:00
1:45:00
1:40:00
1:35:00
1:30:00
1:25:00
1:20:00
1:15:00
1:10:00
-500
1:05:00
-200
1:00:00
Examples of collected data displayed on a post-processing system:

Top: Connection attempts over time sorted by device type
Bottom: Single user ping-ponging between two cells
Round Trip Delay (1/8 chip) (+:SN50,-:SN53)
Signaling performance on per UE, per bearer

level
User experience
eNodeB internal data
Time Of Day (hh:mm:ss)
PCMD is primarily used for troubleshooting. PCMD can help:

Evaluate UE performance. PCMD can determine if a particular brand or model or even a specific
mobile is causing set-up failures and dropped calls. This enables the service provider to narrow
down the root cause of the problem - network related, UE related, or air interface related.
Quickly determine failure scenarios. PCMD collects data associated with the call/connection.
This allows quick response to customer trouble tickets. There is no need to recreate the failure
scenario in the lab to understand why a call failed or was dropped. This greatly reduces the need
for the drive test, which is very expensive and time consuming.
Analyze RF coverage. PCMD gives very useful information regarding RF coverage. Once the
network is established, the RF coverage can be analyzed by looking at signal strength at the end of
calls. Inadequate RF coverage can result in lost calls, and signal strength at the time of a lost call
can be examined in the PCMD record. PCMD significantly reduces RF Optimization and engineering
costs.
Each PCMD record captures the following:
Signaling
performance on per UE, per bearer level by indicating the procedure disposition
codes (Final Class, Final Class Qualifiers)
User
experience such as, data throughput and procedure setup duration
eNodeB
internal data such as, MIMO decision, SINR, Buffer Size, and normalized power
headroom UE Measurements

Support for private message
S1AP private message:

Start PCMD collection
Stop PCMD collection
Send PCMD data
MME
S1-MME
eNodeB
1 13 60
PCMD messages are exchanged using the 3GPP standard for private messaging.
The
9471 MME uses the S1AP private message element procedure to support PCMD
collection.
The
eNodeBs and MME exchange private messages to start and stop PCMD data collection.
Delivery
of PCMD data by eNodeB to the MME is also via private message. Data is collected for
procedures, and a single PCMD record is created for the procedure (records are not cumulative
across procedures).
Private message:
As described in TS36.413, the private message mechanism for non-standard use may be used for:
Specific
features not to be part of the basic functionality,
Research
purposes (for example, to implement and evaluate new algorithms/features before

such features are standardized).
The private message mechanism is not used for basic functionality, since such functionality is
standardized.

Knowledge check: PCMD

PCMD is a troubleshooting and performance data collection tool that
replaces standard performance counters and call trace.
True
False
False. PCMD records compliment performance measurement counters by
allowing analysis of individual connections. Call trace is used to collect signaling
and protocol data.
1 13 61

OAM&P architecture and the FCAPs model
5620 SAM overview and tasks performs by 5620 SAM
9471 MME local OAM&P interfaces:
MI-Agent
CLI
MI-Agent basic screens and navigation

Basic views of the 9471 MME from the 5620 SAM
PCMD overview
1 13 62

Name the interfaces used to manage the 9471 MME

Identify typical tasks performed from each management interface
Log into the MI-Agent and the OAM Server command line interface
View hardware and software status
1 13 63

References
The following customer documents contain information and
procedures related to 9471 MME OAM&P:
9471 MME OAM&P
Explains how to:

Log into the system and various user interfaces
Perform routine maintenance tasks such as backup, alarm monitoring
Schedule Performance Measurement (PM) collection
Perform fault correction procedures such as hardware replacement and
restore
Provision MME network interfaces
Configure hardware
Grow the system
Start and stop PCMD collection and call trace
(418-111-201)
9471 MME Technical Description
Describes the 9471 MME functions, hardware, software, IP addressing.
9471 MME Alarm Dictionary
Provides procedures to clear alarms.
5620 SAM LTE ePC User Guide
9471 MME Observation Counters
Alcatel-Lucent LTE Network PCMD

Reference Guide (417-111-009)
(418-111-200)
(418-111-208)
customer document (3HE06981)

(418-111-209)
1 13 64
Contains MME procedures performed from the 5620 SAM, including

application provisioning, policy setting, alarm monitoring.
Describes each PM and key performance indicator.
Provides reference for PCMD procedures.
Describes PCMD record fields and values.
Customer documentation is found on the Alcatel-Lucent OnLine Customer Support (OLCS) site:
https://services.support.alcatel-lucent.com/services/lte

1 13 65

End of module
9471 MME Management Interfaces
1 13 66

Section 1
9471 MME Overview
Module 14
End of Course Summary

Technical Overview

Blank page
1 14 2
9471 MME Overview End of Course Summary

Document History
Edition
Date
Author
Remarks
01
YYYY-MM-DD
First edition

This course covered the following topics:
1. 9471 MME in the LTE network
2. Mobility management procedures
3. Session management procedures
4. Security functions
5. 9471 MME support for roaming
6. Emergency, warning, and MBMS services
7. CDMA interworking
8. UMTS/GSM interworking
9. Hardware
10. Software
11. IP addressing and subnets
12. System reliability
13. Management interfaces
1 14 3

This module was designed to enable you to:
Explain how the 9471 MME interacts with other elements in the LTE network to
provide mobility management and session management functions
Explain the function of key 9471 MME software components and applications
Identify the management systems used to manage the 9471 MME
1 14 4

To obtain course credit

To obtain credit for this course, please complete the Student Satisfaction
Questionnaire (SSQ).
To assess your knowledge gained from this course, please complete the
Level 2 Assessment (L2A):
Access the L2A from the Alcatel-Lucent Learning Management System web page
for the course:
https://training.alcatel-lucent.com
Select My Training tab

Click Enrollments
Click View Content
Click the course number
Click the Help link at the top of the page if you need instructions or assistance.
Do you have any questions before taking the assessment?

1 14 5

End of module
End of Course Summary
1 14 6

Appendix A: List of acronyms and abbreviations

Numbers
1X
CDMA2000 1X
1X RNC
1X Radio Network Controller
2G
2nd Generation (GSM, TDMA, IS95A)
3G
3rd Generation (CDMA2000, UMTS)
3GPP
Third Generation Partnership Project
3GPP2
Third Generation Partnership Project 2
4G
4th Generation
A
AAA
Authentication, Authorization, and Accounting
AAT
Average Aggregate Throughput
ACK
Acknowledgement
ACL
Access Control List
ACLR
Adjacent Channel Leakage Ratio
ACM
Active Connection Mode
ADMF
Administrative Function
AF
Assured Forwarding, or Application Function
AGW
Access Gateway
aIMS
Advances to IP Multimedia Services
AKA
Authentication and Key Agreement
ALU
Alcatel-Lucent
AM
Acknowledge Mode
AMBR
Aggregate Maximum Bit Rate
AM
Access Manager
AM
Accounting Management
AMC
Advanced Mezzanine Card
AN
Access Network
AN
Access Node
ANDSF
Access Network Discovery and Selection Function
ANR
Automatic Neighbor Relations
AP
Application Processor
AP
Application Protocol
APB
Active Phone Book
APN
Access Point Name
AR
Access Router
AR
Aggregation Router
ARP
Access Resolution Protocol, or
ARP
Allocation and Retention Priority
ARQ
Automatic Repeat Request

Copyright 2012 Alcatel-Lucent. All rights reserved.
Appendix-1
AS
Access Stratum
AS
Application Server
ASN.1
Abstract Syntax Notation 1
ASN-GW
Access Service Network Gateway
AT
Access Terminal
ATCA
Advanced Telecommunications Computing Architecture
ATCA-LCP
Advanced Telecommunications Computing Architecture Linux Control Platform
AVP
Attribute Value Pair
AWS
Advanced Wireless Services
B
BCCH
Broadcast Control Channel
BCH
Broadcast Channel
BE
Best Effort
BFD
Bidirectional Forwarding Detection
BHCA
Busy Hour Connection Attempts
BHL
Back Haul
BM
Bearer Manager
BM-SC
Broadcast-Multicast Service Center
B-PCF
1X RNC Blade PCF
BRC
Baseband Resources Controller
BS (BTS)
Base Station
BSC
Base Station Controller
BSR
Base Station Router
BTS (BS)
Base Transceiver Station
C
CAC
Call Admission Control
CALEA
Communications Assistance for Law Enforcement Act
CAZAC
Constant Amplitude Zero Auto-Correlation
CB
Controller Board
CBC
Cell Broadcasting Center
CC
Content of Communication
CC
Cumulative Counter
CCCH
Common Control Channel
CCM
Common Chassis Management
CDMA
Code Division Multiple Access
CE
Customer Edge router
CER
Capabilities Exchange Request (Diameter Setup)
CFC
Call Final Class
CFCQ
Call Final Class Qualifier
C/I
Carrier-to-Interference Power Ratio
CIM
Circuit Interface Module

Appendix-2
CLI
Command Line Interface
CM
Configuration Management
CMAS
Commercial Mobile Alert System
CMC
Connection Mobility Control
CMIP
Cliencompany IP
CN
Core Network
CNFG
Configuration
CP
Cyclic Prefix
CPI
Critical Performance Indicator
C-plane
Control Plane
CPM
Centralized Password Management
CPRI
Common Public Radio Interface
CPU
Central Processing Unit
CQI
Channel Quality Indicator
CRC
Cyclic Redundancy Check
C-RNTI
Cell RNTI
CS
Circuit Switched
CSFB
Circuit Switched Fall Back
CTM-HSSPC
Controller Turbo Mode - High Speed Serial Protocol Controller (Xilinx IP)
CU
Controller Unit
D
d2U
Digital 2 Unit
d4U
Digital 4 Unit
DCCH
Dedicated Control Channel
DCI
Downlink Control Information
DER
Discrete Event Registration
DF
Delivery Function
DHCP
Dynamic Host Configuration Protocol
DL
Downlink
DL-SCH
Downlink Shared channel
DO
CDMA Data Only
DNS
Domain Name Server
DPA
Disconnect Peer Answer
DPH
Data Protocol Handler
DPI
Deep Packet Inspection
DPR
Disconnect Peer Request
DRA
Diameter Routing Agent
DRA&PS
Dynamic Resource Allocation & Packet Scheduling
DRB
Data Radio Bearer carrying user plane data
DRX
Discontinuous Reception
DS1
Digital Signal level 1 (1.544 Mbit/s)
DSC
Dynamic Service Controller

Appendix-3
DSCH
Downlink Shared Channel
DSCP
Differentiated Services Code Point
DTCH
Dedicated Traffic Channel
DTR
Dual Transceiver
DTX
Discontinuous Transmission
DWR
Device Watchdog Request (heartbeat)
E
E1
Standard European PCM link (2.048 Mbit/s)
eAT
Evolved Access Terminal
EBI
ePS Bearer ID
eBTS
Enhanced Base Transceiver Station
ECM
ePS Connection Management
E-DCH
Enhanced Dedicated Channel
EDGE
Enhanced Data rates for GSM Evolution
EF
Expedited Forwarding
EGCI
EUTRAN Cell Global Identifier
eHRPD
Evolved High Rate Packet Data
EIPM
External IP Manager
EIPM-ACM
External IP Manager Active Connection Mode
EIR
Equipment Identity Register
ELP
ECP Location Services Protocol
EML
Element Management Level
EMM
ePS Mobility Management
EMS
Element Management System
eNodeB (eNB)
Evolved Node B
EPC
Evolved Packet Core
ePDSN
Evolved Packet Data Serving Node
EPS
Evolved Packet System
eRAN
Evolved Radio Access Network
eRNC
Evolved DO-RNC
ESD
Electrostatic Discharge
ESM
Evolved Session Management
E-SMLC
EPS Serving Mobile Location Center
eUTRAN
Evolved Universal Terrestrial Radio Access Network
EVDO
Evolution-Data Optimized or Evolution-Data Only
F
FA
Foreign Agent
FBC
Flow Based Charging
FCAPS
Fault, Configuration, Accounting, Performance, and Security
FDD
Frequency Division Duplex
FDM
Frequency Division Multiplexing

Appendix-4
FFS
For Future Study
FM
Fault Management
FRS
Feature Requirements Specification
FRU
Field Replaceable Unit
FQDN
Fully Qualified Domain Name
FS
Frame Selection
FTP
File Transfer Protocol
G
GBR
Guaranteed Bit Rate
GERAN
GSM EDGE Radio Access Network
GGSN
Gateway GPRS Support Node
GMLC
Gateway Mobile Location Center
GNSS
Global Navigation Satellite System
GPRS
General Packet Radio Service
GRE
Generic Routing Encapsulation
GSM
Global System for Mobile Telecommunications
GTP
GPRS Tunneling Protocol
GTP-C
GPRS Tunneling Protocol - Control
GTP-U
GPRS Tunneling Protocol - User
GUI
Graphical User Interface
GUMMEI
Globally Unique MME Identifier
GUTI
Globally Unique Temporary Identity
GWCN
Gateway Core Network
H
HA
Home Agent
HARQ
Hybrid ARQ
HO
Handover
H-PCRF
Home PCRF
HPLMN
Home PLMN
HRPD
High Rate Packet Data
HSDPA
High Speed Downlink Packet Access
HSGW
HRPD Serving Gateway
HSPD
High Speed Packet Data
HSPP
High Speed Packet Processor
HSRP
Hot Standby Router Protocol
HSS
Home Subscriber Server
HSSL
High Speed Serial Link
HSSPC
High Speed Serial Protocol Controller
HW
Hardware
Appendix-5
I
ICIC
Inter-Cell Interference Coordination
ICMP
Internet Control Message Protocol
IE
Information element
IETF
Internet Engineering Task Force
IM
Instant Messaging
IMEI
International Mobile Equipment Identifier
IMS
IP Multimedia Subsystems
IMSI
International Mobile Station Identifier
IP
Internet Protocol
IPBH
Internet Protocol Back Haul
IPM
IP Manager
IPMI
Intelligent Platform Management Interface
IPSec
Internet Protocol Security
I-RAT
Inter-Radio Access Technology
IRI
Intercept Related Information
ITU
International Telecommunication Union
J
JMS
Java Message Service
K
KPI
Key Performance Indicator
L
L1
Layer 1
L2
Layer 2
L3
Layer 3
LA
Location Area
LAI
Location Area Identity
LB
Load Balancing
LVI
LVI Application Function
LBI
Linked ePS Bearer Identity
LBO
Local Break Out
LBS
Location Based Service
LCID
Logical Channel Identifier
LCP
Linux Control Platform
LCR
Low Chip Rate
LCS
Location Services
LDAC
Load Distribution and Access Control
LEA
Law Enforcement Agency
LED
Light-emitting Diode
LEMF
Law Enforcement Monitoring Function

Appendix-6
LI
Lawful Interception
LIF
LVI Interface Function
LMA
Local Mobility Anchor
LMT
Local Maintenance Terminal
LPP
LTE Positioning Protocol
LR
Location Request
LRF
Location Retrieval Function
LSN
Local Secure Network
LTE
Long Term Evolution
LVI
LTE Voice Interworking
M
MAC
Medium Access Control
MAF
MAG
Mobility Access Gateway
MBMS
Multimedia Broadcast Multicast Service
Mbps
Megabits per second
MBR
Maximum Bit Rate
MCC
Mobile Country Code
MCCH
Multicast Control Channel
MCE
Multicast Control Entity
MCM
Media Conversion Module
MCS
Modulation and Coding Scheme
MEI
Mobile Equipment Identifier
META
Mobile Evolution Transport Architecture
MGW
Media Gateway
MH
Multi-homed
MI
Management Interface
MIB
Management Information Base
MIF
MME Interface Function
MIMO
Multiple Input Multiple Output
MIP
Mobile Internet Protocol
MLS
Multi-Layer Switch
MM
Mobility Management
MME
Mobility Management Entity
MMEC
MME Code
MMEGI
MME Group Id
MMEI
MME Identifier
MNC
Mobile Network Code
MO
Managed Object
MO
Mobile Origination
MOCN
Multi-Operator Core Network
MPH
Message Packet Handler

Appendix-7
MPLS
Multi-Protocol Label Switching
MSC
Mobile Switching Center
MSIN
Mobile Subscriber Identification Number
MT
Mobile Termination
MTCH
MBMS Traffic Channel
MTU
Maximum Transmission Unit
MU
Modem Unit
N
NACK
Non-Acknowledgement
NAPTR
Name Authority Pointer
NAS
Non-Access Stratum
NBI
Northbound Interface
NDP
Neighbor Discovery Protocol
NE
Network Element
NEL
Network Element Level
NEM
Network Element Manager
NML
Network Management Level
NMS
Network Management System
NSA
National Security Agreement
NTP
Network Time Protocol
O
OA&M (OAM)
Operations, Administration, and Maintenance
OCAN
Offline Configuration of Access Networks
OCS
Online Charging System
OFCS
Offline Charging System
OFDM
Orthogonal Frequency Division Multiplexing
OFDMA
Orthogonal Frequency Division Multiple Access
OMC
Operations Management Center
OMC-RAN
Operations and Maintenance Center Radio Access Network
OMP
Operations and Management Platform
OOS
Out of Service
OS
Operating System
OSS
Operations Support System
P
PA
Power Amplifier
PAPR
Peak-to-Average Power Ratio
PBCH
Physical Broadcast Channel
PBR
Prioritized Bit Rate
PCC
Policy and Charging Control/Policy Control and Charging
PCCH
Paging Control Channel
PCEF
Policy and Charging Enforcement Function

Appendix-8
PCFICH
Physical Control Format Indicator Channel
PCI
Physical Cell Identifier
PCMD
Per Call Measurement Data
PCRF
Policy and Charging Rules Function
PDCCH
Physical Downlink Control Channel
PDCP
Packet Data Context Protocol
PDN
Packet Data Network
PDP
Packet Data Protocol
PDSN
Packet Data Serving Node
PDU
Packet Data Unit
PEF
Policy Enforcement Function
PEM
Power Entry Module
PGW (P-GW)
Packet Gateway (Packet Data Network Gateway)
PHICH
Physical Hybrid ARQ Indicator Channel
PHY
Physical layer
PIM
Packet Interface Module
PLMN
Public Land Mobile Network
PM
Performance Management
PM
Performance Measurements
PMC
Performance Measurement Counter
PMIP
Proxy Mobile IP
PO
Processor Occupancy
PPP
Point to Point Protocol
PRB
Physical Resource Block
PS
Packet Switched
PSAP
Public Safety Answering Point
PSC
Packet Scheduling
PSTN
Public Switched Telephone Network
PTM-MC
Point-to-Multipoint, Multi-Cell
PTM-SC
Point-to-Multipoint, Single-Cell
Q
QAM
Quadrature Amplitude Modulation
QCI
QoS Class Identifier
QoS
Quality of Service
QRM
Quality and Reliability Measurements
R
RA
Routing Area
RAC
Radio Admission Control
RACH
Random Access Channel
RA-RNTI
Random Access RNTI
RAN
Radio Access Network

Appendix-9
RAT
Radio Access Technology
RAU
Routing Area Update
RB
Radio Bearer
RBAC
Role-Based Access Control
RBC
Radio Bearer Control
RBP
Rack Back Plane
RCC
Reliable Cluster Computing
ReM
Redundancy Manager
RF
Radio Frequency
RFC
Request For Comments
RLC
Radio Link Control
RMT
Remote Maintenance Terminal
RNC
Radio Network Controller
RNL
Radio Network Layer
RNTI
Radio Network Temporary Identifier
R-OCM
Reverse - Optical Control Module
ROHC
Robust Header Compression
RQMS
Reliability and Quality Measurements for Telecommunications Systems
RR
Resource Record
RRC
Radio Resource Control
RRH
Remote Radio Head
RRM
Radio Resource Management
RSR
Reliable Static Routing
RTM
Rear Transmission Module
RTT
Radio Transmission Technology
RU
Resource Unit
RUC
Rack User Commissioning
RX
Receive
S
S1-MME
S1 for the control plane
S1-U
S1 for the user plane
SACK
SCTP Acknowledgement
SAE
System Architecture Evolution
SAM
Service Aware Manager
SAML
Security Assertion Markup Language
SAP
Service Access Point
SAR
Service Aggregation Router
SC-FDMA
Single Carrier - Frequency Division Multiple Access
SCH
Synchronization Channel
SCM
System Control Module
SCTP
Stream Control Transmission Protocol
SDF
Service Data Flow

Appendix-10
SDM
Subscriber DB Manager
SDMA
Spatial Division Multiple Access
SDU
Service Data Unit
SFM
Switch Fabric Module
SFN
Single Frequency Network
SFP
Small Form-factor Pluggable
sFTP
Secure File Transfer Protocol
SGSN
Serving GPRS Support Node
SGW (S-GW)
Serving Gateway
SGW
Signaling Gateway
SH
Single-Homed
ShMC
Shelf Management Controller
SIP
Session Initiation Protocol
SLOAM
Slave Operation and Administration
SM
Security Management
SM
Session Management
SMC
Security Mode Command
SMS
Short Message Service
S-NAPTR
Straightforward Name Authority Pointer
SNMP
Simple Network Management Protocol
SNS
Shared Network Services
SOAP
Simple Object Access Protocol
SOL
Serial Over LAN
SON
Self-Organizing Network
SPR
Subscription Profile Repository
SR
Service Router
SRNS
Serving Radio Network Subsystem
SRS
Sounding Reference Signal
SRV
DNS Service Record
SRVCC
Single Radio Voice Call Continuity
SSH
Secure Shell
S-TMSI
S-Temporary Mobile Subscriber Identity
SU
Scheduling Unit
SU
Software Update
SW
Software
T
TA
Tracking Area
TAC
Tracking Area Code
TAI
Tracking Area Identity
TAS
Telephony Application Server
TAU
TB
Transport Block
Appendix-11
TCP
Transmission Control Protocol
TDD
Time Division Duplex
TEID
Tunnel Endpoint Identifier
TFT
Traffic Flow Template
TIPC
Transparent Inter Process Communication
TM
Transparent Mode
TMN
Telecommunication Management Network
TMSI
Temporary Mobile Station Identity
TNL
Transport Network Layer
TRDU
Transmit Receive Duplex Unit
TTI
Transmission Time Interval
TX
Transmit
U
UDP
User Datagram Protocol
UE
User Equipment
UL
Uplink
ULBO
Uplink Buffer Occupancy
ULI
User Location Information
ULR
Update Locate Request
UM
Un-acknowledge Mode
UMB
Ultra Mobile Broadband
UMTS
Universal Mobile Telecommunications System
UPA
User plane Application
U-plane
User plane
USIM
Universal Subscriber Identity Module
UTC
Coordinated Universal Time
UTRAN
Universal Terrestrial Radio Access Network
V
VCC
Voice Call Continuity
VLAN
Virtual Local Area Network
VLR
Visitor Location Register
VoIMS
Voice over IMS
VoIP
Voice over IP
V-PCRF
Visited PCRF
VPLMN
Visited PLMN
VRB
Virtual Resource Block
VRRP
Virtual Router Redundancy Protocol
W
WAP
Wireless Access Protocol
W-CDMA
Wideband Code Division Multiple Access
WiMAX
Worldwide Interoperability for Microwave Access

Appendix-12
X
X2-C
X2-Control plane
X2-U
X2-User plane
xCCM-U
Extended Core Controller Module Unit
xCEM-U
Extended Channel Element Module Unit
XML
Extensible Markup Language
XMS
Extended Management System
Appendix-13
Appendix-14
Appendix B: Example UE context data

The following UE context example was collected for IMSI 310012001001001 from a
Naperville lab 9471 MME using the ueadmin_cli command: ueadmin_cli o dump -i
310012001001001.
__________________________________________________________________________
+++ 2012/05/07 14:50:23.547 CRAFT_MAINT HIGH ACTIVE maf:7232 E:44021 S:913
(hssPxy_util.cpp 1603 X-0:9:0 26.49.11.00:1335456548 mmebld 10.165.161.0)
MME-HSSEIR-PXY:MVLR_BASE for IMSI 310012001001001 or IMEI 1a3254161232510:
vlrIdx 0
ueCxnQid 17
ueCxnIdx 0
ueCxnMsgQCnt 0
emmState REGISTERED
ecmState CONNECTED
lastUeActivityTimestamp 6204910 (inactTime=567021) (clock ticks)
deletingEntry 0
deletingEntryForCli 0
cliMoveInProg 0
localCpMoveInProg 0
remoteCpMoveInProg 0
dumpCxnStateTrans 0

MME-HSSEIR-PXY:MVLR_AUTH for IMSI 310012001001001 or IMEI 1a3254161232510:
vlrIdx 0
numAv 2
curAuthIdx 0
reuseCurAuthIdx FALSE
avIdx 0
RAND 0xf579f86973065306f192bd226e1b283f
XRES 0x05b5941772ffdb47 (8)
AUTN 0xcf5cebe9de7e825def810a7038c28b17
Kasme
0x09744260c34fb87917d216e72abc089a1f85dfd2adb5fcd06f12af3267b36ecf
avIdx 1
RAND 0xe4fc3a5e6189957adf15f0165d9e5a33
XRES 0xd48e39a25b5b7c3e (8)
AUTN 0x0d78a329c200825d659b581d7be270f4
Kasme
0x075dc0281e0354d58db0d7c930c91b0d76e9d77211fa8f7173b52614e557d33a

MME-HSSEIR-PXY:MVLR_SUB for IMSI 310012001001001 or IMEI 1a3254161232510:
vlrIdx 0
ueHomePlmn 310012
isRoamer NOT ROAMER
nonHssData 0
unauthImsi 0
urrpMme 0
subStatus SERVICE_GRANTED
networkAccessMode BOTH PACKET AND CIRCUIT
odb
Appendix-15
hplmnOdb 0x0
ratFreqSelectPriorityId 0
roamRestrictDueToUnsupFeature NOT RESTRICTED
regSubsZoneCode
imsi 310012001001001 (digCnt 15)
msisdnNaiNpi 91
msisdn (stored) 6103792900f0
msisdn 16309792000
stnSr 6103793900f0
icsIndicator FALSE
accessRestrictionData NONE
apnOiReplacement mnc012.mcc310.gprs (18)
default3gppChargingCharac 0x3132
ambr
maxReqBandwidthUl 11000000
maxReqBandwidthDl 100000000
defaultApnConfigId 1
wildCardApnConfigId 4294967295
wildCardApnNiInUse (0)
numApn 6
apnConfigId 1 2 3 4 5 6
apnConfigIdPoolIdxList 0 1 2 3 4 5

MME-HSSEIR-PXY:MVLR_APN for IMSI 310012001001001 or IMEI 1a3254161232510:
vlrIdx 0
apnConfigId 1
serviceSelection wap1.company.com (16)
apnNameInUse mnc012.mcc310.gprs (18)
vPlmnCreation 0
servedPartyIpAddressIpv4 10.0.1.1
servedPartyIpAddressIpv6
ambr
maxBandwidthUl 0
maxBandwidthDl 0
epsDefaultQosProfile
qci 9
arp
priorityLevel 15
preemptCapability DISABLED
preemptVulnerability DISABLED
ambr
pdnType IPv4
mip6AgentInfo
addrIPv4 135.1.1.1
vplmnDynamicAddrAllowed ALLOWED
pdnGwAllocationType DYNAMIC
3gppChargingCharac 0x3132

vlrIdx 0
apnConfigId 2
Appendix-16
apnNameInUse (0)
vPlmnCreation 0
ambr
maxBandwidthUl 0
maxBandwidthDl 0
qci 9
arp
priorityLevel 15
ambr
pdnType IPv4
mip6AgentInfo
addrIPv4 135.1.1.1

vlrIdx 0
apnConfigId 3
apnNameInUse (0)
vPlmnCreation 0
ambr
maxBandwidthUl 0
maxBandwidthDl 0
qci 9
arp
priorityLevel 15
ambr
pdnType IPv4
mip6AgentInfo
addrIPv4 135.1.1.1

vlrIdx 0
apnConfigId 4
Appendix-17
apnNameInUse (0)
vPlmnCreation 0
ambr
maxBandwidthUl 0
maxBandwidthDl 0
qci 9
arp
priorityLevel 15
ambr
pdnType IPv4
mip6AgentInfo
addrIPv4 135.1.1.1

vlrIdx 0
apnConfigId 5
apnNameInUse (0)
vPlmnCreation 0
ambr
maxBandwidthUl 0
maxBandwidthDl 0
qci 9
arp
priorityLevel 15
ambr
pdnType IPv4
mip6AgentInfo
addrIPv4 135.1.1.1

vlrIdx 0
apnConfigId 6
Appendix-18
apnNameInUse (0)
vPlmnCreation 0
ambr
maxBandwidthUl 0
maxBandwidthDl 0
qci 9
arp
priorityLevel 15
ambr
pdnType IPv4
mip6AgentInfo
addrIPv4 135.1.1.1

MME-HSSEIR-PXY:MVLR_SXN for IMSI 310012001001001 or IMEI 1a3254161232510:
vlrIdx 0
callTraceIdx 40
createdByHo no record created
relocType no relocation
uePriorityType NONE
stopPaging (due to UE inactivity) 0
stopPaging (due to no page response) 0
stopPaging (due to UELB context release sent) 0
stopPaging (effective flag state) 0
procSetStopPaging 0
firstProcSucceed 1
failedMobilityProcCount 0
forceAkaOnNextProc 0
noPageRspCnt 0
pagingGapTimestamp (clock ticks) 0
hssReset 0
hssEvolved 0
plmnConfigDataCount 0
apnBrrModInprog 0
isLbCxtRelSent 0
supportsPFC 0
lastSentAccessRestrictionData NONE
enbRestartCount 1
sgsRestartCount 0
sgwRestartCount 1
sgwId 1
sgwPoolId 0
pcmdRecordSequenceNum 1
pcmdServiceInitiationNum 1
imeiStatus no IMEI status
imei 1a3254161232510 (digCnt 16)
svn f1
uePreviousPlmn 000000
Appendix-19
guti
mplmnId 310012
mmeGroupId 38912
mmeCode 1
mtmsi 0xc0300000
oldGuti
mplmnId fffff
mmeGroupId 0
mmeCode 0
mtmsi 0xffffffff
foreignGuti
mplmnId fffff
mmeGroupId 0
mmeCode 0
mtmsi 0xffffffff
drx
present 0
splitCycleCode 0
s1ModeOrCnCycle 0
splitOnCcchFlag 0
nonDrxTimer 0
includeNbTaiList 1
currentTai
plmn 310012
tac 0x6400
lastSeenTai
plmn 310012
tac 0x6400
oldLastSeenTai
plmn 000000
tac 0x0000
olderLastSeenTai
plmn 000000
tac 0x0000
lastRegTai
plmn 310012
tac 0x6400
oldLastRegTai
plmn 000000
tac 0x0000
olderLastRegTai
plmn 000000
tac 0x0000
MME-HSSEIR-PXY:
currentCell
plmn 310012
cellId 0x00232303
lastSeenCell
plmn 310012
cellId 0x00232303
enbPcmdLastSeenCell
plmn 310012
cellId 0x00232303
currentEnbIdx 2
lastSeenEnbIdx 2
mmeUeS1ApId 00000000
current enbIdx 2
Appendix-20
current enbUeS1ApId 0x00000001

previous enbIdx 0
previous enbUeS1ApId 0xffffffff
ueRadioCap (0)
sgsIdx 0
sgsState 0
numSgsPageAttempts 0
mscVlrReliable 0
neaf 0
csfbCapable 0
lai
plmn 000000
lac 0x0000
currentTmsi 0x00000000
ueNetworkCap e0e0000002 (5)
msNetworkCap 0100 (2)
ueVoiceDomainPref no UE Voice Domain Pref
ueUsageSetting no UE Usage Setting
sgwSuspended 0
interRatCellRedirect 0
srvccTo2g3gCap 0
nfCapability 0
maxUsedAmbr
sgwFqdn
topon.eth1.sgw32.mme100.pool1.nodes.epc.mnc012.mcc310.3gppnetwork.org (69)
mmeTeid
teid 1
IPv4 172.16.47.4
IPv6 2511:0:0:993::4
sgwTeid
teid 1
IPv4 172.16.49.178
emerApnOi NONE (0)
numEbi 1
ebiList 5 0 0 0 0 0 0 0 0 0 0
ebiListPoolIdxList 0 255 255 255 255 255 255 255 255 255 255
numEmerEbi 0
emerEbiList 0
mnrg 0
smsOnlyIndSent 0
emerOrigSlrSent 0
lcsNotificationSupport 0
lppCapability 0
sendToHss NONE (0)
recvFrHssHost HSS_HOST (8)
recvFrHssRealm HSS_REALM (9)
MME-HSSEIR-PXY:MVLR_BRR for IMSI 310012001001001 or IMEI 1a3254161232510:
bearerId (ebi) 5
linkedbearerId (lbi) 5
presentMap (common and LTE parameters) 0x375f
apnInUse 1
apnAmbr
Appendix-21
epsBrrQos
qci 9
arp
priorityLevel 15
preemptCapability 1
preemptVulnerability 1
ambr.maxReqBandwidthUl 0
ambr.maxReqBandwidthDl 0
ulDlType LTE
ulGuaranteedBandwidth 0
dlGuaranteedBandwidth 0
ul2g3gMaxBandwidth 0
dl2g3gMaxBandwidth 0
ueReqTrafficFlowQos
qci 255
arp
priorityLevel 4294967295
preemptCapability 2
preemptVulnerability 2
ambr.maxReqBandwidthUl 0
ambr.maxReqBandwidthDl 0
ulGuaranteedBandwidth 0
dlGuaranteedBandwidth 0
chargingId 1
locChangeReport 7
pgwFqdn topon.lb1.pgw01.pool1.nodes.epc.mnc012.mcc310.3gppnetwork.org
(61)
ueAddr
source PGW
addrType IPv4
ipv6PrefixLen 0
addrIPv4 135.1.1.1
sgwS1uTeid
teid 1
IPv4 135.252.34.158
IPv6 2001:238:0:1000:2e0:81ff:fe5c:ef21
sgwS5S8uTeid
teid 0
pgwControlTeid
teid 1
IPv4 135.252.130.75
pgwControlGreKey
greKey 0
pgwS5S8uTeid
teid 1
IPv4 135.252.130.76
enbS1uTeid
teid 1
IPv4 172.16.49.23
presentMap (additional common and LTE parameters) 0x1b
llcSapi 11
radioPriority 4
packetFlowId 0
pdpTransId 1
nasReqType 1
psHoXid (0)
Appendix-22
Appendix C: Example IP addresses

The following example output from the net4conf_adm command shows the IP
addresses for each blade in each of the subnets. Note that this is output is from a lab
that does not use the standard 169.254 subnet value for the first two octets of internal
IP addresses.
<mme44-s00c01h0:root>/root:
> net4conf_adm --action show_ip_address
---------------------169.254.32.16
mme44-s00c01h0
169.254.32.32
mme44-s00c02h0
169.254.32.48
mme44-s00c03h0
169.254.32.64
mme44-s00c04h0
169.254.32.112
mme44-s00c07h0
169.254.32.116
mme44-s00c07h4
169.254.32.128
mme44-s00c08h0
169.254.32.132
mme44-s00c08h4
169.254.32.241
mme44-s00c15h1
169.254.32.242
mme44-s00c15h2
---------------------169.254.48.16
mme44-s00c01h0
169.254.48.32
mme44-s00c02h0
169.254.48.48
mme44-s00c03h0
169.254.48.64
mme44-s00c04h0
169.254.48.112
mme44-s00c07h0
169.254.48.116
mme44-s00c07h4
169.254.48.128
mme44-s00c08h0
169.254.48.132
mme44-s00c08h4
169.254.48.241
mme44-s00c15h1
169.254.48.242
mme44-s00c15h2
IPv4 host IP addresses
---------------------169.254.64.16
mme44-s00c01h0
169.254.64.32
mme44-s00c02h0
169.254.64.48
mme44-s00c03h0
169.254.64.64
mme44-s00c04h0
169.254.64.112
mme44-s00c07h0
169.254.64.116
mme44-s00c07h4
169.254.64.128
mme44-s00c08h0
169.254.64.132
mme44-s00c08h4
169.254.64.240
mme44-s00c15h0
IPv4 internal fixed service IP addresses
---------------------------------------169.254.130.0
mme44-cnfg-p00m000-d0
169.254.130.1
mme44-cnfg-p00m001-d0
169.254.131.0
mme44-mi-p00m000-d0
169.254.131.1
mme44-mi-p00m001-d0
169.254.161.0
mme44-maf-p00m000-d0
169.254.161.1
mme44-maf-p00m001-d0
169.254.162.0
mme44-mif-p00m000-d0
Appendix-23
169.254.162.1
169.254.169.0
169.254.169.1
169.254.188.0
169.254.188.1
mme44-mif-p00m001-d0
mme44-mph-p00m000-d0
mme44-mph-p00m001-d0
mme44-sns-p00m000-d0
mme44-sns-p00m001-d0
IPv4 internal floating service IP addresses

------------------------------------------169.254.194.0
mme44-cnfg-p00f000-g0
169.254.195.0
mme44-mi-p00f000-g0
169.254.225.0
mme44-maf-p00f000-g0
169.254.226.0
mme44-mif-p00f000-g0
169.254.233.0
mme44-mph-p00f000-g0
IPv4 external fixed service IP addresses
---------------------------------------10.145.220.172 mme44-sns-p00m000-d1
10.145.220.173 mme44-sns-p00m001-d1
135.2.164.180
mme44-mi-p00m000-d1
135.2.164.181
mme44-mi-p00m001-d1
IPv4 external floating service IP addresses
------------------------------------------10.145.220.161 mme44-mif-p00f000-g1
10.145.220.162 mme44-mif-p00f000-g2
10.145.220.163 mme44-mif-p00f000-g3
10.145.220.164 mme44-mif-p00f000-g4
10.145.220.165 mme44-mif-p00f000-g5
10.145.220.166 mme44-mif-p00f000-g6
10.145.220.167 mme44-mif-p00f000-g7
10.145.220.168 mme44-mif-p00f000-g8
10.145.220.169 mme44-mif-p00f000-g9
10.145.220.170 mme44-mif-p00f000-g10
10.145.220.171 mme44-mif-p00f000-g11
135.2.164.182
mme44-mi-p00f000-g1
135.2.164.183
mme44-cnfg-p00f000-g1
The following example output from the net6conf_adm command shows the IPv6
addresses.
<mme44-s00c01h0:root>/root:
> net6conf_adm --action show_ip_address
IPv6 external fixed service IP addresses
---------------------------------------No external fixed service IPv6 IP addresses defined.
IPv6 external floating service IP addresses
------------------------------------------fd56:ac4f:f6ad:002e:0000:0000:0000:0001 mme44-mif-p00f000-g1
fd56:ac4f:f6ad:002e:0000:0000:0000:0002 mme44-mif-p00f000-g2
Appendix-24
Comment-Enabled PDF
Exercises
Version 2, October 2011
Comment-enabled PDF
Alcatel-Lucent University cares about the environment. We decided to start
using CE-PDF for our course materials: Comment-enabled PDF.
CE-PDFs allow you to take notes electronically and to quickly search the
document.
This short training will show the basic features.
Together we can save our planet. Thanks.
2
CE-PDF Tutorial
Ensure commenting is enabled in the PDF file

1. Open the PDF document using Adobe Reader (v9 or later is recommended).
2. Go to File and select Properties as shown below.
3
3. In the Security tab, ensure

Commenting is set to Allowed.
3
CE-PDF Tutorial
Setting the Commenting toolbars in Adobe Reader 9

1. If not already set, in Reader 9 go
to Tools > Comment & Markup.
2. Then select Show Comment
& Markup Toolbar.
3. The tool bar will now be permanently

displayed on the main screen:
3
4
CE-PDF Tutorial
Setting the Commenting toolbars in Adobe Reader X

1. The Add Sticky Note and Highlight tools are automatically displayed in Reader X.
1
2. To display additional tools, go to:
View > Comment and select Annotations.

View > Comment and select Drawing Markup.
3. Tools are on the right side of the page:
5
CE-PDF Tutorial
Comment-enabled PDF tools

In a few small exercises, you will become familiar with CE-PDF:
6
CE-PDF Tutorial
Typewriter function (add text to your file)
Sticky Notes (call outs)
Stamp tool (for checkboxes and evaluation)
Highlight
4
5
Autosave
Typewriter function (add text to your file)
Using the Typewriter, you can add text to your files. Click on the
button to start it.
If you do not see the Typewriter:
1.
Adobe Reader 9 users select Tools >Typewriter

1
2.
Adobe Reader X users select Extended on

the right side of the page.
Then click Add or Edit Text box.
Exercise: type your class number in this box:

Class number:
7
CE-PDF Tutorial
Sticky Notes (& call outs)

You will find the Sticky Note tool in the toolbar.
(Note: if you want to print your notes, use
the Typewriter instead.)
Exercise 1: put a sticky note on the first cross below.
With the
you can change your name and some other features, like color.
Exercise 2: Change your name on the sticky note.

Exercise 3: put a call out on the second cross.
8
CE-PDF Tutorial
Stamp tool (for checkboxes and evaluation)

In the course material and for the evaluation, you might need to
mark some dots. The Stamp is useful here.
Exercise: Fill in the questionnaire below using the Stamp tool.
9
CE-PDF Tutorial
Highlight
The comment-enabled PDF offers a lot of features. We are not going to see them all
in detail. But one of them, the Highlight
, is very useful. It allows you to
indicate the important things in the text.
Adobe Reader 9 toolbar:
Adobe Reader X toolbar:
In the tool set you will also find some drawing tools: squares and circles (
and arrows and lines (
). Or you could use the pencil to draw lines. (
Exercise: Highlight the most important words in the text above.
10
CE-PDF Tutorial
)
)
Autosave
IMPORTANT: dont forget to regularly save your file. Otherwise your

changes could get lost. Change the name of the file if you added comments.
To ensure that you do not forget to save, lets activate the AutoSave function:
Select Edit > Preferences, then click Documents.
Exercise: set the Autosave to 5 minutes.
11
CE-PDF Tutorial
Saving files in Adobe Reader X

If you cannot save your CE-PDF file after you add notes in Adobe Reader X:
1.
In the Adobe Reader X menu, select Edit > Preferences > General.
2.
Under Application Startup, uncheck Enable Protected Mode at Startup.
3.
Click OK and then restart Adobe Reader X.
12
CE-PDF Tutorial
Last but one page
Congratulations
You have finished the training
Your feedback is appreciated!
Please feel free to Email your comments to:
training.feedback@alcatel-lucent.com
Please include the training reference in your email (see cover page)
Thank you!
All Rights Reserved Alcatel-Lucent @@YEAR
@@PRODUCT
@@COURSENAME

@@COURSENAME - Page 1
All rights reserved Alcatel-Lucent

Passing on and copying of this document, use and communication of its
contents not permitted without written authorization from Alcatel-Lucent

@@COURSENAME - Page 2

MME Technical Overview

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

MME Technical Overview

Uploaded by

Copyright:

Available Formats

Evolved Packet Core 9471 MME LM5.0.

COPYRIGHT ALCATEL-LUCENT 2012. ALL RIGHTS RESERVED.

Passing on and copying of this document, use and communication of its

Terms of use and legal notices

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Welcome to Evolved Packet Core 9471 MME for LM5.0.1

5. Topic/Section is Positioned Here

6. Topic/Section is Positioned Here

1. 9471 MME in the LTE Network

COPYRIGHT ALCATEL-LUCENT 2012. ALL RIGHTS RESERVED.

Evolved Packet Core 9471 MME LM5.0.1

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Locate and describe 9471 MME hardware components

MME = Mobility Management Entity

eUTRAN = Evolved Universal Terrestrial Radio Access Network

Evolved Packet Core 9471 MME LM5.0.1

Your feedback is appreciated!

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

About this course

COPYRIGHT ALCATEL-LUCENT 2012. ALL RIGHTS RESERVED.

Evolved Packet Core 9471 MME LM5.0.1

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

You should have completed the following course prior to taking

The following course, or an equivalent understanding of the EPC is

Successful completion of this course requires basic knowledge of the

COPYRIGHT ALCATEL-LUCENT 2012. ALL RIGHTS RESERVED.

Evolved Packet Core 9471 MME LM5.0.1

LTE = Long Term Evolution

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Do not delete this graphic elements in here:

EPC 9471 MME LM5.0.1

All Rights Reserved Alcatel-Lucent 2012

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

COPYRIGHT ALCATEL-LUCENT 2012. ALL RIGHTS RESERVED.

9471 MME Overview 9471 MME in the LTE Network

This page is left blank intentionally

Last name, first name

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

COPYRIGHT ALCATEL-LUCENT 2012. ALL RIGHTS RESERVED.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

COPYRIGHT ALCATEL-LUCENT 2012. ALL RIGHTS RESERVED.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

1 LTE and 9471 MME quick review

COPYRIGHT ALCATEL-LUCENT 2012. ALL RIGHTS RESERVED.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

LTE architecture review

EPS = eUTRAN + EPC

Appendix A contains a list of acronyms used in this course.

COPYRIGHT ALCATEL-LUCENT 2012. ALL RIGHTS RESERVED.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

EPC components review

COPYRIGHT ALCATEL-LUCENT 2012. ALL RIGHTS RESERVED.

Components within the EPC:

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Other key components review

COPYRIGHT ALCATEL-LUCENT 2012. ALL RIGHTS RESERVED.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Separation of control plane and data plane

MME optimized for signaling.

COPYRIGHT ALCATEL-LUCENT 2012. ALL RIGHTS RESERVED.

provides only control-plane functions and is optimized for signaling.

provides mostly data-plane functions and is optimized to provide bearer services.

MME and SGW can be independently scaled or in different geographic locations.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.