> MME in LTE/SAE Wireless Data Services
> The Cisco® ASR 5000 chassis provides LTE/SAE wireless carriers with a flexible solution that functions as a Mobility Management Entity (MME) in 3GPP Long-Term Evolution/System Architecture Evolution wireless data networks.
> This overview provides general information about the MME including:

> • | Product Description

> • | Product Specification

> • | Network Deployment and Interfaces

> • | Features and Functionality - Base Software

> • | Features and Functionality - Licensed Enhanced Feature Software

> • | How MME Works

> • | Supported Standards

> Product Description
> This section describes the MME network function and its postion in LTE network.
> The MME is the key control-node for the LTE access-network. It works in conjunction with Evolved NodeB (eNodeB), Serving Gateway (SGW) within the Evolved Packet Core (EPC) or LTE/SAE core network to perform the following functions:

> • | Involved in the bearer activation/deactivation process and is also responsible for choosing the serving gateway (SGW) and for a UE at the initial attach and at time of intra-LTE handover involving Core Network (CN) node relocation

> • | Provide PDN Gateway (P-GW) selection for subscriber to connect to PDN.

> • | Provide idle mode UE tracking and paging procedure including retransmissions

> • | Responsible for authenticating the user (by interacting with the HSS)

> • | Work as termination point for the Non-Access Stratum (NAS) signaling

> • | Responsible for generation and allocation of temporary identities to UEs

> • | It checks the authorization of the UE to camp on the service provider’s Public Land Mobile Network (PLMN) and enforces UE roaming restrictions.

> • | The MME is the termination point in the network for ciphering/integrity protection for NAS signaling and handles the security key management.

> Besides above mentioned functions the Lawful interception of signaling is also supported by the MME. The MME also provides the control plane function for mobility between LTE and 2G/3G access networks with the S3 interface terminating at the MME from the SGSN. The MME also terminates the S6a interface towards the home HSS for roaming UEs.
> Architecture of LTE/SAE Network
> In accordance with 3GPP standard, the MME provides following functions and procedures in LTE/SAE network:

> • | Non Access Strutum (NAS) signalling

> • | NAS signalling security

> • | Inter CN node signalling for mobility between 3GPP access networks (terminating S3)

> • | UE Reachability in ECM-IDLE state (including control and execution of paging retransmission)

> • | Tracking Area list management

> • | PDN GW and Serving GW selection

> • | MME selection for handover with MME change

> • | SGSN selection for handover to 2G or 3G 3GPP access networks

> • | Roaming (S6a towards home HSS)

> • | Authentication

> • | Bearer management functions including dedicated bearer establishment

> • | Lawful Interception of signalling traffic

> • | Warning message transfer function (including selection of appropriate eNodeB)

> • | UE Reachability procedures

> • | Interfaces with MSC for Voice paging

> • | Interfaces with Gn/Gp SGSN for interconnecting to legacy network

> • | MAP based Gr interface to legacy HLR

> Important: Some of the features may not be available in this release. Kindly contact your local Cisco representative for more information on supported features.
> Product Specification
> This section describes the hardware and software requirement for MME service.
> The following information is located in this section:

> • | Licenses

> • | Hardware Requirements

> • | Operating System Requirements

> Licenses
> The MME is a licensed product. A session use license key must be acquired and installed to use the MME service.
> The following licenses are available for this product:

> • | MME Software Bundle License, 10K Sessions, 600-00/01-7646

> • | MME Software Base License, 1K Sessions, 600-00/01-7648

> For more information on supported features, refer Features and Functionality sections.
> Hardware Requirements
> Information in this section describes the hardware required to enable the MME service.
> Platforms
> The MME service operates on the following platform(s):

> • | ASR 5000

> System Hardware Components
> The following application and line cards are required to support MME services on the system:

> • | System Management Cards (SMC): Provides full system control and management of all cards within the ASR 5000 platform. Up to two SMC can be installed; one active, one redundant.

> • | Packet Services Cards (PSC/PSC2): Within the ASR 5000 platform, PSCs/PSC2s provide high-speed, multi-threaded EPS Bearer context processing capabilities for MME services. Up to 14 PSCs/PSC2s can be installed, allowing for multiple active and/or redundant cards.

> • | Switch Processor Input/Outputs (SPIOs): Installed in the upper-rear chassis slots directly behind the SPCs/SMCs, SPIOs provide connectivity for local and remote management, central office (CO) alarms. Up to two SPIOs can be installed; one active, one redundant.

> • | Line Cards: The following rear-loaded line cards are currently supported by the system:

> • | Ethernet 10/100 and/or Ethernet 1000 Line Cards: Installed directly behind PSCs, these cards provide the physical interfaces to elements in the LTE/SAE network. Up to 26 line cards should be installed for a fully loaded system with 13 active PSCs/PSC2, 13 in the upper-rear slots and 13 in the lower-rear slots for redundancy. Redundant PSCs/PSC2s do not require line cards.

> • | Quad Gig-E Line Cards (QGLCs):The 4-port Gigabit Ethernet line card is used in the ASR 5000 system only and is commonly referred to as the Quad-GigE Line Card or the QGLC. The QGLC is installed directly behind its associated PSC/PSC2 to provide network connectivity to the packet data network.

> • | 10 Gig-E Line Cards(XGLCs): The 10 Gigabit Ethernet Line Card is used in the ASR 5000 system only and is commonly referred to as the XGLC. The XGLC supports higher speed connections to packet core equipment, increases effective throughput between the ASR 5000 and the packet core network, and reduces the number of physical ports needed on the ASR 5000.

> The one-port XGLC supports the IEEE 802.3-2005 revision which defines full duplex operation of 10 Gigabit Ethernet.
> The XGLC is configured and monitored via the System Management Card (SMC) over the system’s control bus. Both SMCs must be active to maintain maximum forwarding rates.

> • | Redundancy Crossbar Cards (RCCs): Installed in the lower-rear chassis slots directly behind the SPCs/SMCs, RCCs utilize 5 Gbps serial links to ensure connectivity between Ethernet 10/100/Ethernet 1000/Quad Gig-E/10 Gig-E line cards and every PSC/PSC2 in the system for redundancy. Two RCCs can be installed to provide redundancy for all line cards and PSCs/PSC2a.

> Important: Additional information pertaining to each of the application and line cards required to support LTE/SAE services is located in the Hardware Platform Overview chapter of the Product Overview Guide.
> Operating System Requirements
> The MME is available for ASR 5000 platforms running StarOS™ Release 9.0 or later.
> Network Deployment and Interfaces
> This section describes the supported interfaces and deployment scenario of MME in LTE/SAE network.
> The following information is provided in this section:

> • | MME in the LTE/SAE Network

> • | Supported Interfaces

> MME in the LTE/SAE Network
> The following figure displays simplified network views of the MME in an LTE/SAE network with GPRS/UMTS network as neighboring network.
> The MME in LTE/SAE Networks and Interfaces
> Supported Interfaces
> In support of both mobile and network originated subscriber UE contexts, the system MME provides the following network interfaces:

> • | S1-MME Interface: This interface is the reference point for the control plane protocol between eNodeB and MME. S1-MME uses S1- Application Protocol (S1-AP) over Stream Control Transmission Protocol (SCTP) as the transport layer protocol for guaranteed delivery of signaling messages between MME and eNodeB (S1).

> This is the interface used by the MME to communicate with eNodeBs on the same LTE Public Land Mobile Network (PLMN). This interface serves as path for establishing and maintaining subscriber UE contexts.
> One or more S1-MME interfaces can be configured per system context.

> • | S3 Interface: This is the interface used by the MME to communicate with SGSNs on the same Public PLMN for interworking between GPRS/UMTS and LTE network access technology. This interface serves as both the signalling and data path for establishing and maintaining subscriber UE contexts.

> The MME communicates with SGSNs on the PLMN using the GPRS Tunnelling Protocol (GTP). The signalling or control aspect of this protocol is referred to as the GTP Control Plane (GTPC) while the encapsulated user data traffic is referred to as the GTP User Plane (GTPU).
> One or more S3 interfaces can be configured per system context.

> • | S6a Interface: This is the interface used by the MME to communicate with the Home Subscriber Server (HSS). The HSS is responsible for transfer of subscription and authentication data for authenticating/authorizing user access and UE context authentication. The MME communicates with the HSSs on the PLMN using Diameter protocol.

> One or more S6a interfaces can be configured per system context.

> • | S10 Interface: This is the interface used by the MME to communicate with MME in same PLMN or on different PLMNs. This interface is also used for MME relocation and MME to MME information transfer or handoff.

> One or more S10 interfaces can be configured per system context.
> Note: This interface will be supported in future release.

> • | S11 Interface: This interface provides communication between MME and Serving Gateways (SGW) for information transfer using GTPv2 protocol.

> One or more S11 interfaces can be configured per system context.

> • | S13 Interface: This interface provides communication between MME and Equipment Identity Register (EIR). This interface is not supported in this release.

> One or more S13 interfaces can be configured per system context.
> Note: This interface will be supported in furture release.

> • | S101 Interface: This interface provides communication between MME and High Rate Packet Data (HRPD) access node in a 3GPP2 network. It uses an application layer protocol S101-AP to enable interactions between Evolved Packet System (EPS) and HRPD access node to allow for pre-registration and handover signalling with the target system. The S101 interface supports procedures for pre-registration, session maintenance, and active handoffs between E-UTRAN and HRPD networks.

> One or more S101 interfaces can be configured per system context.
> Note: This interface will be supported in furture release.

> • | DNS Interface: MME supports DNS interface to locate the S-GW in EPS core network. The MME uses the Tracking Area List as fully qualified domain name (FQDN) to locate the address of the S-GW to establish the call with.

> One or more DNS interface can be configured per system context.

> • | Gr Interface: This is the interface used by the MME to communicate with the Home Location Register (HLR) via a eGTP-to-MAP (Mobile Application Part) protocol convertor. This interface is used for network initiated UE contexts.

> For network initiated UE contexts, the MME will communicate with the protocol convertor using eGTP. The convertor, in turn, will communicate with the HLR using MAP over Signalling System 7 (SS7).
> One or more Gr interfaces can be configured per system context.
> Note: This interface will be supported in furture release.
> Important: MME Software also supports additional interfaces. For more information on additional interfaces, refer Features and Functionality - Licensed Enhanced Feature Software section.
> Features and Functionality - Base Software
> This section describes the features and functions supported by default in base software on MME service and do not require any additional license to implement the functionality with the MME service.
> Important: To configure the basic service and functionality on the system for MME service, refer configuration examples provide in MME Administration Guide.
> Following features and supports are discussed in this section:

> • | Subscriber Session Management Features

> • | Session and Quality of Service Management

> • | Network Access Control Functions

> • | Network Entity Management

> • | Network Operation Management Functions

> • | System Management Features

> Subscriber Session Management Features
> This section describes following features:

> • | EPS Bearer Context Support

> • | NAS Protocol Support

> • | EPS GTPv2 Support on S11 Interface

> • | Subscriber Level Session Trace

> EPS Bearer Context Support
> Provides support for subscriber default and dedicated Evolved Packet System (EPS) bearer contexts in accordance with the following standards:

> • | 3GPP TS 36.412 V8.4.0 (2008-12): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Access Network (E-UTRAN); S1 signaling transport (Release 8)

> • | 3GPP TS 36.413 V8.4.0 (2008-12): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1 Application Protocol (S1AP) (Release 8)

> • | IETF RFC 4960, Stream Control Transmission Protocol, December 2007

> EPS bearer context processing is based on the APN that the subscriber is attempting to access. Templates for all of the possible APNs that subscribers will be accessing must be configured within the system. Up to 1024 APNs can be configured on the system.
> Each APN template consists of parameters pertaining to how UE contexts are processed such as the following:

> • | PDN Type:IPv4, IPv6, or IPv4v6

> • | EPS Bearer Context timers

> • | Quality of Service

> A total of 11 EPS bearer per subscriber are supported. These could be all dedicated, or 1 default and 10 dedicated or any combination of default and dedicated context. Note that there must be at least one default EPS Bearer context in order for dedicated context to come up.
> NAS Protocol Support
> MME provides this protocol support between the UE and the MME. The NAS protocol includes following elementary procedures for EPS Mobility Management (EMM) and EPS Session Management (ESM):
> EPS Mobility Management (EMM)
> This feature used to support the mobility of user equipment, such as informing the network of its present location and providing user identity confidentiality. It also provides connection management services to the session management (SM) sublayer.
> An EMM context is established in the MME when an attach procedure is successfully completed. The EMM procedures are classified as follows:

> • | EMM Common Procedures: An EMM common procedure can always be initiated when a NAS signalling connection exists.

> Following are the common EMM procedure types:

> • | Globally Unique Temporary Identity (GUTI) reallocation

> • | Authentication and security mode

> • | Identification

> • | EMM information

> • | EMM Specific Procedures: This procedure provides Subscriber Detach or de-registration procedure.

> • | EMM Connection Management Procedures: This procedure provides connection management related function like Paging procedure.

> EPS Session Management (ESM)
> This feature is used to provide the subscriber session management for bearer context activation, deactivation, modification, and update procedures.
> EPS GTPv2 Support on S11 Interface
> Support for the EPS GTPv2 on S11 interface in accordance with the following standards:

> • | 3GPP TS 29.274 V8.1.0 (2009-03): 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; 3GPP Evolved Packet System (EPS); Evolved General Packet Radio Service (GPRS) Tunnelling Protocol for Control plane (GTPv2-C); Stage 3 (Release 8)

> The system supports the use of GTPv2 for EPS signalling context processing.
> When the GTPv2 protocol is used, accounting messages are sent to the charging gateways (CGs) over the Ga interface. The Ga interface and GTPv2 functionality are typically configured within the system's source context. As specified by the standards, a CDR is not generated when a session starts. CDRs are generated according to the interim triggers configured using the charging characteristics configured for the MME, and a CDR is generated when the session ends. For interim accounting, STOP/START pairs are sent based on configured triggers.
> GTP version 2 is always used. However, if version 2 is not supported by the CGF, the system reverts to using GTP version 1. All subsequent CDRs are always fully-qualified partial CDRs. All CDR fields are R4.
> Whether or not the MME accepts charging characteristics from the SGSN can be configured on a per-APN basis based on whether the subscriber is visiting, roaming or, home.
> By default, the MME always accepts the charging characteristics from the SGSN. They must always be provided by the SGSN for GTPv1 requests for primary EPS Bearer contexts. If they are not provided for secondary EPS Bearer contexts, the MME re-uses those from the primary.
> If the system is configured to reject the charging characteristics from the SGSN, the MME can be configured with its own that can be applied based on the subscriber type (visiting, roaming, or home) at the APN level. MME charging characteristics consist of a profile index and behavior settings. The profile indexes specify the criteria for closing accounting records based specific criteria.
> Important: For more information on GTPv2 configuration, refer eGTP Service Configuration in MME Service Administration Guide.
> Subscriber Level Session Trace
> The Subscriber Level Trace provides a 3GPP standards-based session-level trace function for call debugging and testing new functions and access terminals in an LTE environment.
> In general, the Session Trace capability records and forwards all control activity for the monitored subscriber on the monitored interfaces. This is typically all the signaling and authentication/subscriber services messages that flow when a UE connects to the access network.
> As a complement to Cisco's protocol monitoring function, the MME supports 3GPP standards based session level trace capabilities to monitor all call control events on the respective monitored interfaces including S6a, S1-MME and S11. The trace can be initiated using multiple methods:

> • | Management initiation via direct CLI configuration

> • | Management initiation at HSS with trace activation via authentication response messages over S6a reference interface

> • | Signaling based activation through signaling from subscriber access terminal

> The session level trace function consists of trace activation followed by triggers. The time between the two events is treated much like Lawful Intercept where the EPC network element buffers the trace activation instructions for the provisioned subscriber in memory using camp-on monitoring. Trace files for active calls are buffered as XML files using non-volatile memory on the local dual redundant hard drives. The Trace Depth defines the granularity of data to be traced. Six levels are defined including Maximum, Minimum and Medium with ability to configure additional levels based on vendor extensions.
> All call control activity for active and recorded sessions is sent to an off-line Trace Collection Entity (TCE) using a standards-based XML format over a FTP or secure FTP (SFTP) connection.
> Note: In the current release the IPv4 interfaces are used to provide connectivity to the TCE. Trace activation is based on IMSI or IMEI and only Maximum Trace Depth is supported in this release.
> The following figure shows a high-level overview of the session-trace functionality and deployment scenario:
> Session Trace Function and Interfaces
> For more information on this feature, refer Configuring Subscriber Session Tracing chapter in MME Service Administration Guide.
> Session and Quality of Service Management
> This support provides a foundation for contributing towards improved Quality of User Experience (QoE) by enabling deterministic end-to-end forwarding and scheduling treatments for different services or classes of applications pursuant to their requirements for committed bandwidth resources, jitter and delay. In this way, each application receives the service treatment that users expect.
> The MME Operator Policy configuration allows the specification of QoS for each traffic class that can either be used as a default or as an over ride to the HSS settings.
> In LTE-EPC 4G architectures, QoS management is network controlled via dynamic policy interactions between the PCRF and PDN GW. EPS bearer management is used to establish, modify or remove dedicated EPC bearers in order to provide service treatments tied to the needs of specific applications/service data flows. The service priority is provisioned based on QoS Class Identifiers (QCI) in the Gx policy signaling. PCRF signaling interaction may also be used to establish or modify the APN-AMBR attribute assigned to the default EPS bearer.
> When it is necessary to set-up a dedicated bearer, the PDN GW initiates the Create Dedicated Bearer Request which includes the IMSI (permanent identity of mobile access terminal), Traffic Flow Template (TFT - 5-tuple packet filters) and S5 Tunnel Endpoint ID (TEID) information that is propagated downstream via the SGW over the S11 interface to the MME. The Dedicated Bearer signaling includes requested QoS information such as QCI, Allocation and Retention Priority (ARP), Guaranteed Bit Rate (GBR - guaranteed minimum sending rate) and Maximum Bit Rate (MBR- maximum burst size).
> The MME allocates a unique EPS bearer identity for every dedicated bearer and encodes this information in a Session Management Request that includes Protocol Transaction ID (PTI), TFT’s and EPS bearer QoS parameters. The MME signals the Bearer Setup Request in the S1-MME message toward the neighboring eNodeB.
> Network Access Control Functions
> These functions enable secure user and device level authentication between the authenticator component of the MME and a 3GPP HSS / AuC and Diameter-based S6a interface support.
> This section describes following features:

> • | Authentication and Key Agreement (AKA)

> • | HSS Support Over S6a Interface

> Authentication and Key Agreement (AKA)
> MME provides EPS Authentication and Key Agreement mechanism for user authentication procedure over the E-UTRAN. The Authentication and Key Agreement (AKA) mechanism performs authentication and session key distribution in networks. AKA is a challenge- response based mechanism that uses symmetric cryptography. AKA is typically run in a Services Identity Module.
> The AKA is the procedure that take between the user and network to authenticate themselves towards each other and to provide other security features such as integrity and confidentiality protection.
> In a logical order this follows the following procedure:

> 1. | Authentication: Performs authentication by, identifying the user to the network; and identifying the network to the user.

> 2. | Key agreement: Performs key agreement by, generating the cipher key; and generating the integrity key.

> 3. | Protection: When the AKA procedure is performed it protects, the integrity of messages; confidentiality of signalling data; and confidentiality of user data

> HSS Support Over S6a Interface
> Provides a mechanism for performing Diameter-based authorization, authentication, and accounting (AAA) for subscriber bearer contexts based on the following standards:

> • | 3GPP TS 23.401 V8.1.0 (2008-03): 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access (Release 8)

> • | 3GPP TS 29.272 V8.1.1 (2009-01): 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Evolved Packet System (EPS); Mobility Management Entity (MME) and Serving GPRS Support Node (SGSN) related interfaces based on Diameter protocol (Release 8)

> • | 3GPP TS 33.401 V8.2.1 (2008-12): 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 3GPP System Architecture Evolution (SAE): Security Architecture; (Release 8)

> • | RFC 3588, Diameter Base Protocol, December 2003

> The S6a protocol is used to provide AAA functionality for subscriber EPS Bearer contexts through Home Subscriber Server (HSS).
> During the initial attachment procedures the MME sends to the USIM on AT via the HSS the random challenge (RAND) and an authentication token AUTN for network authentication from the selected authentication vector. At receipt of this message, the USIM verifies that the authentication token can be accepted and if so, produces a response. The AT and HSS in turn compute the Cipher Key (CK) and Integrity Key (IK) that are bound to Serving Network ID. During the attachment procedure the MME requests a permanent user identity via the S1-MME NAS signaling interface to eNodeB and inserts the IMSI, Serving Network ID (MCC, MNC) and Serving Network ID it receives in an Authentication Data Request to the HSS. The HSS returns the Authentication Response with authentication vectors to MME. The MME uses the authentication vectors to compute the cipher keys for securing the NAS signaling traffic.
> At EAP success, the MME also retrieves the subscription profile from the HSS which includes QoS information and other attributes such as default APN name and SGW/PGW fully qualified domain names.
> Among the AAA parameters that can be configured are:

> • | Authentication of the subscriber with HSS

> • | Subscriber location update/location cancel

> • | Update subscriber profile from the HSS

> • | Priority to dictate the order in which the servers are used allowing for multiple servers to be configured in a single context

> • | Routing Algorithm to dictate the method for selecting among configured servers. The specified algorithm dictates how the system distributes AAA messages across the configured HSS servers for new sessions. Once a session is established and an HSS server has been selected, all subsequent AAA messages for the session will be delivered to the same server.

> Network Entity Management
> This section describes following features:

> • | MME Selection

> • | Packet Data Network Gateway (P-GW) Selection

> • | Serving Gateway (S-GW) Selection

> • | 3GPP R8 Identity Support

> • | Tracking Area List Management

> • | Reachability Management

> MME Selection
> The MME selection function selects an available MME for serving a UE. This feature is needed for MME selection for handover with minimal MME changes.
> MME selection chooses an available MME for serving a UE. Selection is based on network topology, i.e. the selected MME serves the UE’s location and in case of overlapping MME service areas, the selection function may prefer MME’s with service areas that reduce the probability of changing the MME.
> Packet Data Network Gateway (P-GW) Selection
> Provides a straightforward method based on a default APN provided during user attachment and authentication to assign the P-GW address in the VPLMN or HPLMN. The MME also has the capacity to use a DNS transaction to resolve an APN name provided by a UE to retrieve the PDN GW address.
> P-GW selection allocates a P-GW that provides the PDN connectivity for the 3GPP access. The function uses subscriber information provided by the HSS and possibly additional criteria. For each of the subscribed PDNs, the HSS provides:

> • | an IP address of a PDN GW and an APN, or

> • | an APN and an indication for this APN whether the allocation of a PDN GW from the visited PLMN is allowed or whether a PDN GW from the home PLMN shall be allocated.

> The HSS also indicates the default APN for the UE. To establish connectivity with a PDN when the UE is already connected to one or more PDNs, the UE provides the requested APN for the PDN GW selection function.
> If the HSS provides an APN of a PDN and the subscription allows for allocation of a PDN GW from the visited PLMN for this APN, the PDN GW selection function derives a PDN GW address from the visited PLMN. If a visited PDN GW address cannot be derived, or if the subscription does not allow for allocation of a PDN GW from the visited PLMN, then the APN is used to derive a PDN GW address from the HPLMN.
> Serving Gateway (S-GW) Selection
> The Serving GW selection function selects an available Serving GW to serve a UE. This feature reduces the probability of changing the Serving Gateway and a load balancing between Serving Gateways The MME uses DNS procedure to for S-GW selection.
> S-GW selection chooses an available S-GW to serve a UE. The selection is based on network topology, i.e. the selected S-GW serves the UE’s location and in the case of overlapping S-GW service areas, the selection may prefer S-GWs with service areas that reduce the probability of changing the Serving GW. If a subscriber of a GTP only network roams into a P-MIP network, the PDN GWs selected for local breakout supports the P-MIP protocol, while P-GWs for home routed traffic use GTP. This means the S-GW selected for such subscribers may need to support both GTP and PMIP, so that it is possible to set up both local breakout and home routed sessions for these subscribers.
> 3GPP R8 Identity Support
> Provides the identity allocation of following type:

> • | EPS Bearer Identity

> • | Globally Unique Temporary UE Identity (GUTI)

> • | Tracking Area Identity (TAI)

> • | MME S1-AP UE Identity (MME S1-AP UE ID)

> • | EPS Bearer Identity: An EPS bearer identity uniquely identifies EPS bearers within a user session for attachment to the E-UTRAN access and EPC core networks. The EPS Bearer Identity is allocated by the MME. There is a one to one mapping between EPS Radio Bearers via the E-UTRAN radio access network and EPS Bearers via the S1-MME interface between the eNodeB and MME. There is also a one-to-one mapping between EPS Radio Bearer Identity via the S1 and X2 interfaces and the EPS Bearer Identity assigned by the MME.

> • | Globally Unique Temporary UE Identity (GUTI): The MME allocates a Globally Unique Temporary Identity (GUTI) to the UE. A GUTI has; 1) unique identity for MME which allocated the GUTI; and 2) the unique identity of the UE within the MME that allocated the GUTI.

> Within the MME, the mobile is identified by the M-TMSI.
> The Globally Unique MME Identifier (GUMMEI) is constructed from MCC, MNC and MME Identifier (MMEI). In turn the MMEI is constructed from an MME Group ID (MMEGI) and an MME Code (MMEC).
> The GUTI is constructed from the GUMMEI and the M-TMSI.
> For paging, the mobile is paged with the S-TMSI. The S-TMSI is constructed from the MMEC and the M-TMSI.
> The operator needs to ensure that the MMEC is unique within the MME pool area and, if overlapping pool areas are in use, unique within the area of overlapping MME pools.
> The GUTI is used to support subscriber identity confidentiality, and, in the shortened S-TMSI form, to enable more efficient radio signaling procedures (e.g. paging and Service Request).

> • | Tracking Area Identity (TAI): Provides the function to assign the TAI list to the mobile access device to limit the frequency of Tracking Area Updates in the network. The TAI is the identity used to identify the tracking area or group of cells in which the idle mode access terminal will be paged when a remote host attempts to reach that user. The TAI consists of the Mobile Country Code (MCC), Mobile Network Code (MNC) and Tracking Area Code (TAC).

> • | MME S1-AP UE Identity (MME S1-AP UE ID): This is the temporary identity used to identify a UE on the S1-MME reference point within the MME. It is unique within the MME per S1-MME reference point instance.

> Tracking Area List Management
> Provides the functions to allocate and reallocate a Tracking Area Identity (TAI) list to the UE to minimize the Tracking Area updates.
> The MME assigns the TAI list to a UE so as to minimize the TA updates that would be sent by the UE. The TAI list should not be very long as this would mean that the paging load would be high. There is a trade-off between paging load and Tracking Area Update procedures number.
> To avoid ping-pong effect, the MME includes the last visited TAI (provided that the TA is handled by the MME) in the TAI list assigned to the UE.
> The tracking area list assigned to different UEs moving in from the same tracking area should be different so as to avoid Tracking Area Update message overflow.
> Reachability Management
> It provides a mechanism to track a UE which is in idle state for EPS connection management.
> To reach a UE in idle state the MME initiates paging to all eNodeBs in all tracking areas in the TA list assigned to the UE. The EPS session manager have knowledge about all the eNodeB associations to the MME and generates a list of eNodeBs that needs to be paged to reach a particular UE.
> The location of a UE in ECM-IDLE state is known by the network on a Tracking Area List granularity. A UE in ECM-IDLE state is paged in all cells of the Tracking Areas in which it is currently registered. The UE may be registered in multiple Tracking Areas. A UE performs periodic Tracking Area Updates to ensure its reachability from the network.
> Network Operation Management Functions
> This section describes following features:

> • | Overload Management in MME

> • | Radio Resource Management Functions

> • | Mobile Equipment Identity Check

> • | Multiple PDN Support

> Overload Management in MME
> Provides mechanism to handle overload/congestion situation. It can use the NAS signalling to reject NAS requests from UEs on overload or congestion.
> MME restricts the load that its eNodeBs are generating on it. This is achieved by the MME invoking the S1 interface overload procedure as per 3GPP TS 36.300 and 3GPP TS 36.413 to a proportion of the eNodeB’s with which the MME has S1 interface connections.
> Hardware and/or software failures within an MME may reduce the MME’s load handling capability. Typically such failures result in alarms which alert the operator or Operation and Maintenance system.
> For more information on congestion control management, refer Configuring Congestion Control chapter in MME Administration Guide.
> Caution: Only if the operator or Operation and Maintenance system is sure that there is spare capacity in the rest of the pool, the operator or Operation and Maintenance system might use the load re-balancing procedure to move some load off an MME. However, extreme care is needed to ensure that this load re-balancing does not overload other MMEs within the pool area (or neighboring SGSNs) as this might lead to a much wider system failure.
> Radio Resource Management Functions
> Benefits
> Radio resource management functions are concerned with the allocation and maintenance of radio communication paths, and are performed by the radio access network.
> Description
> To support radio resource management in E-UTRAN the MME provides the RAT/Frequency Selection Priority (RFSP) parameter to an eNodeB across S1. The RFSP is a ‘per UE’ parameter that is used by the E-UTRAN to derive UE specific cell reselection priorities to control idle mode camping. The RFSP can also be used by the E-UTRAN to decide on redirecting active mode UEs to different frequency layers or RATs.
> The MME receives the RFSP from the HSS during the attach procedure. For non-roaming subscribers the MME transparently forwards the RFSP to the eNodeB across S1. For roaming subscribers the MME may alternatively send an RFSP value to the eNodeB across S1 that is based on the visited network policy, e.g. an RFSP pre-configured per Home-PLMN, or a single RFSP values to be used for all roamers independent of the Home-PLMN.
> Mobile Equipment Identity Check
> The Mobile Equipment Identity Check Procedure permits the operator(s) of the MME and/or the HSS and/or the PDN-GW to check the Mobile Equipment's identity with EIR.
> The ME Identity is checked by the MME passing it to an Equipment Identity Register (EIR) and then the MME analyzes the response from the EIR in order to determine its subsequent actions; like rejecting/attaching a UE.
> Multiple PDN Support
> It provides multiple PDN connectivity support for UE initiated service request.
> The MME supports an UE-initiated connectivity establishment to separate PDN GWs or single PDN GW in order to allow parallel access to multiple PDNs. Up to 11 PDNs are supported per subscriber.
> System Management Features
> This section describes following features:

> • | Management System Overview

> • | Bulk Statistics Support

> • | Threshold Crossing Alerts (TCA) Support

> • | NAS Signalling Security

> Management System Overview
> The system's management capabilities are designed around the Telecommunications Management Network (TMN) model for management - focusing on providing superior quality network element (NE) and element management system (Web Element Manager) functions. The system provides element management applications that can easily be integrated, using standards-based protocols (CORBA and SNMPv1, v2), into higher-level management systems - giving wireless operators the ability to integrate the system into their overall network, service, and business management systems. In addition, all management is performed out-of-band for security and to maintain system performance.
> Operation and Maintenance module of ASR 5000 offers comprehensive management capabilities to the operators and enables them to operate the system more efficiently. There are multiple ways to manage the system either locally or remotely using its out-of-band management interfaces.
> These include:

> • | Using the command line interface (CLI)

> • | Remote login using Telnet, and Secure Shell (SSH) access to CLI through SPIO card's Ethernet management interfaces

> • | Local login through the Console port on SPIO card using an RS-232 serial connection

> • | Using the Web Element Manager application

> • | Supports communications through 10 Base-T, 100 Base-TX, 1000 Base-TX, or 1000

> • | Base-SX (optical gigabit Ethernet) Ethernet management interfaces on the SPIO

> • | Client-Server model supports any browser (i.e. Microsoft Internet Explorer v5.0 and above or Netscape v4.7 or above, and others)

> • | Supports Common Object Request Broker Architecture (CORBA) protocol and Simple Network Management Protocol version 1 (SNMPv1) for fault management

> • | Provides complete Fault, Configuration, Accounting, Performance, and Security (FCAPS) capabilities

> • | Can be easily integrated with higher-level network, service, and business layer applications using the Object Management Group's (OMG’s) Interface Definition Language (IDL)

> The following figure demonstrates these various element management options and how they can be utilized within the wireless carrier network.
> Element Management Methods
> Important: MME management functionality is enabled by default for console-based access. For GUI-based management support, refer Web Element Management System.
> Important: For more information on command line interface based management, refer Command Line Interface Reference.
> Bulk Statistics Support
> The system's support for bulk statistics allows operators to choose to view not only statistics that are of importance to them, but also to configure the format in which it is presented. This simplifies the post-processing of statistical data since it can be formatted to be parsed by external, back-end processors.
> When used in conjunction with the Web Element Manager, the data can be parsed, archived, and graphed.
> The system can be configured to collect bulk statistics (performance data) and send them to a collection server (called a receiver). Bulk statistics are statistics that are collected in a group. The individual statistics are grouped by schema. Following is a partial list of supported schemas:

> • | System: Provides system-level statistics

> • | Card: Provides card-level statistics

> • | Port: Provides port-level statistics

> • | MME: Provides MME service statistics

> • | GTPC: Provides GPRS Tunneling Protocol - Control message statistics

> • | GTPU: Provides GPRS Tunneling Protocol - User message statistics

> The system supports the configuration of up to 4 sets (primary/secondary) of receivers. Each set can be configured with to collect specific sets of statistics from the various schemas. Statistics can be pulled manually from the chassis or sent at configured intervals. The bulk statistics are stored on the receiver(s) in files.
> The format of the bulk statistic data files can be configured by the user. Users can specify the format of the file name, file headers, and/or footers to include information such as the date, chassis host name, chassis uptime, the IP address of the system generating the statistics (available for only for headers and footers), and/or the time that the file was generated.
> When the Web Element Manager is used as the receiver, it is capable of further processing the statistics data through XML parsing, archiving, and graphing.
> The Bulk Statistics Server component of the Web Element Manager parses collected statistics and stores the information in the PostgreSQL database. If XML file generation and transfer is required, this element generates the XML output and can send it to a Northbound NMS or an alternate bulk statistics server for further processing.
> Additionally, if archiving of the collected statistics is desired, the Bulk Statistics server writes the files to an alternative directory on the server. A specific directory can be configured by the administrative user or the default directory can be used. Regardless, the directory can be on a local file system or on an NFS-mounted file system on the Web Element Manager server.
> Threshold Crossing Alerts (TCA) Support
> Thresholding on the system is used to monitor the system for conditions that could potentially cause errors or outage. Typically, these conditions are temporary (i.e high CPU utilization, or packet collisions on a network) and are quickly resolved. However, continuous or large numbers of these error conditions within a specific time interval may be indicative of larger, more severe issues. The purpose of thresholding is to help identify potentially severe conditions so that immediate action can be taken to minimize and/or avoid system downtime.
> The system supports Threshold Crossing Alerts for certain key resources such as CPU, memory, number of sessions etc. With this capability, the operator can configure threshold on these resources whereby, should the resource depletion cross the configured threshold, a SNMP Trap would be sent.
> The following thresholding models are supported by the system:

> • | Alert: A value is monitored and an alert condition occurs when the value reaches or exceeds the configured high threshold within the specified polling interval. The alert is generated then generated and/or sent at the end of the polling interval.

> • | Alarm: Both high and low threshold are defined for a value. An alarm condition occurs when the value reaches or exceeds the configured high threshold within the specified polling interval. The alert is generated then generated and/or sent at the end of the polling interval.

> Thresholding reports conditions using one of the following mechanisms:

> • | SNMP traps: SNMP traps have been created that indicate the condition (high threshold crossing and/or clear) of each of the monitored values.

> Generation of specific traps can be enabled or disabled on the chassis. Ensuring that only important faults get displayed. SNMP traps are supported in both Alert and Alarm modes.

> • | Logs: The system provides a facility called threshold for which active and event logs can be generated. As with other system facilities, logs are generated Log messages pertaining to the condition of a monitored value are generated with a severity level of WARNING.

> Logs are supported in both the Alert and the Alarm models.

> • | Alarm System: High threshold alarms generated within the specified polling interval are considered “outstanding” until a the condition no longer exists or a condition clear alarm is generated. “Outstanding” alarms are reported to the system's alarm subsystem and are viewable through the Alarm Management menu in the Web Element Manager.

> The Alarm System is used only in conjunction with the Alarm model.
> Important: For more information on threshold crossing alert configuration, refer Thresholding Configuration Guide.
> NAS Signalling Security
> It provides integrity protection and encryption of NAS signalling. The NAS security association is between the UE and the MME.
> The MME uses the NAS security mode command procedure to establish a NAS security association between the UE and MME, in order to protect the further NAS signalling messages.
> The MME implements AES algorithm (128-EEA1 and 128-EEA2) for NAS signalling ciphering and SNOW 3G algorithm (128-EIA1 and 128-EIA2) for NAS signalling integrity protection.

> • | 128-EIA1= SNOW 3G

> • | 128-EIA2= AES

> Features and Functionality - Licensed Enhanced Feature Software
> This section describes the optional enhanced features and functions for MME service.
> Important: Some of the following features require the purchase of an additional license to implement the functionality with the MME service.
> This section describes following enhanced features:

> • | Session Recovery Support

> • | IPv6 Support

> • | IP Security (IPSec)

> • | Lawful Intercept

> • | MME Inter-Chassis Session Recovery

> • | Web Element Management System

> Session Recovery Support
> The Session Recovery feature provides seamless failover and reconstruction of subscriber session information in the event of a hardware or software fault within the system preventing a fully connected user session from being disconnected.
> This feature is also useful for Software Patch Upgrade activities. If session recovery feature is enabled during the software patch upgrading, it helps to permit preservation of existing sessions on the active PSC during the upgrade process.
> Session recovery is performed by mirroring key software processes (e.g. session manager and AAA manager) within the system. These mirrored processes remain in an idle state (in standby-mode), wherein they perform no processing, until they may be needed in the case of a software failure (e.g. a session manager task aborts). The system spawns new instances of “standby mode” session and AAA managers for each active control processor (CP) being used.
> Additionally, other key system-level software tasks, such as VPN manager, are performed on a physically separate packet processing card to ensure that a double software fault (e.g. session manager and VPN manager fails at same time on same card) cannot occur. The packet processing card used to host the VPN manager process is in active mode and is reserved by the operating system for this sole use when session recovery is enabled.
> The additional hardware resources required for session recovery include a standby system processor card (SPC) and a standby packet processing card.
> There are two modes for Session Recovery.

> • | Task recovery mode: Wherein one or more session manager failures occur and are recovered without the need to use resources on a standby packet processing card. In this mode, recovery is performed by using the mirrored “standby-mode” session manager task(s) running on active packet processing cards. The “standby-mode” task is renamed, made active, and is then populated using information from other tasks such as AAA manager.

> • | Full packet processing card recovery mode: Used when a PSC or PSC2 hardware failure occurs, or when a packet processing card migration failure happens. In this mode, the standby packet processing card is made active and the “standby-mode” session manager and AAA manager tasks on the newly activated packet processing card perform session recovery.

> Session/Call state information is saved in the peer AAA manager task because each AAA manager and session manager task is paired together. These pairs are started on physically different packet processing cards to ensure task recovery.
> Important: For more information on session recovery support, refer Session Recovery chapter in System Enhanced Feature Configuration Guide.
> License
> 600-00-7513, 600-00-7546, 600-00-7552, 600-00-7554
> IPv6 Support
> This feature allows IPv6 subscribers to connect via the GPRS/UMTS infrastructure in accordance with the following standards:

> • | RFC 2460: Internet Protocol, Version 6 (IPv6) Specification

> • | RFC 2461: Neighbor Discovery for IPv6

> • | RFC 2462: IPv6 Stateless Address Autoconfiguration

> • | RFC 3314: Recommendations for IPv6 in 3GPP Standards

> • | RFC 3316: Internet Protocol Version 6 (IPv6) for Some Second and Third Generation Cellular Hosts

> • | RFC 3056: Connection of IPv6 domains via IPv4 clouds

> • | 3GPP TS 23.060: General Packet Radio Service (GPRS) Service description

> • | 3GPP TS 27.060: Mobile Station Supporting Packet Switched Services

> • | 3GPP TS 29.061: Interworking between the Public Land Mobile Network (PLMN) supporting Packet Based Services and Packet Data Networks (PDN)

> The MME allows an APN to be configured for IPv6 EPS Bearer contexts. Also, an APN may be configured to simultaneously allow IPv4 EPS Bearer contexts.
> The MME supports IPv6 stateless dynamic auto-configuration. The mobile station may select any value for the interface identifier portion of the address. The link-local address is assigned by the MME to avoid any conflict between the mobile station link-local address and the MME address. The mobile station uses the interface identifier assigned by the MME during the stateless address auto-configuration procedure. Once this has completed, the mobile can select any interface identifier for further communication as long as it does not conflict with the MME's interface identifier that the mobile learned through router advertisement messages from the MME.
> Control and configuration of the above is specified as part of the APN configuration on the MME, e.g., IPv6 address prefix and parameters for the IPv6 router advertisements. RADIUS VSAs may be used to override the APN configuration.
> Following IPv6 EPS Bearer context establishment, the MME can perform either manual or automatic 6to4 tunneling, according to RFC 3056, Connection of IPv6 Domains Via IPv4 Clouds.
> License Keys: IPv6, part numbers 600-00-7521, 600-00-7576
> License
> 600-00-7521, 600-00-7576
> IP Security (IPSec)
> IP Security provides a mechanism for establishing secure tunnels from mobile subscribers to pre-defined endpoints (i.e. enterprise or home networks) in accordance with the following standards:

> • | RFC 2401, Security Architecture for the Internet Protocol

> • | RFC 2402, IP Authentication Header (AH)

> • | RFC 2406, IP Encapsulating Security Payload (ESP)

> • | RFC 2409, The Internet Key Exchange (IKE)

> • | RFC-3193, Securing L2TP using IPSEC, November 2001

> IP Security (IPSec) is a suite of protocols that interact with one another to provide secure private communications across IP networks. These protocols allow the system to establish and maintain secure tunnels with peer security gateways. IPSec can be implemented on the system for the following applications:

> • | PDN Access: Subscriber IP traffic is routed over an IPSec tunnel from the system to a secure gateway on the packet data network (PDN) as determined by access control list (ACL) criteria.

> • | Mobile IP: Mobile IP control signals and subscriber data is encapsulated in IPSec tunnels that are established between foreign agents (FAs) and home agents (HAs) over the Pi interfaces.

> Important: Once an IPSec tunnel is established between an FA and HA for a particular subscriber, all new Mobile IP sessions using the same FA and HA are passed over the tunnel regardless of whether or not IPSec is supported for the new subscriber sessions. Data for existing Mobile IP sessions is unaffected.

> • | L2TP: L2TP-encapsulated packets are routed from the system to an LNS/secure gateway over an IPSec tunnel.

> The following figure shows IPSec configurations.
> IPSec Applications
> Important: For more information on IPSec support, refer IP Security chapter in System Enhanced Feature Configuration Guide.
> License
> 600-00-7507
> Lawful Intercept
> Provides a standards-based architecture for lawful monitoring and interception of subscriber call control events as mandated by a warrant from a law enforcement agency.
> In accordance with 3GPP TS 33.108 Release 8 requirements the Cisco MME supports the Lawful Intercept Access Function for intercepting control plane traffic pursuant to a court ordered subpoena. Lawful Intercept involves the process of mirroring subscriber call control or call content based on a request from a law enforcement agency to a telecom service provider.
> In this release the MME support the X1 provisioning interface and X2 interface for mirroring Intercept Related Information (IRI) to an upstream Delivery Function/Mediation server. Intercept targets can be provisioned using subscriber information including MSISDN, IMSI and MEI. The Cisco MME supports secure provisioning via remote CLI over SSH connections from a DF mediation server. Our solution is currently interoperable with leading third party solutions.
> The intercepted call control data is encoded in a Cisco proprietary message header format using an optional TLV field to pack the IRI information. The message header includes other identifying information including sequence numbers, timestamps and session & correlation numbers to correlate session and bearer related information with interception on other EPC elements. The MME can intercept any of the following IRI information:

> • | Subscriber attachments

> • | Subscriber detachments

> • | Tracking Area Updates

> • | UE requested PDN connectivity

> • | UE requested PDN disconnection

> Important: For more information on Lawful Intercept support, refer Lawful Intercept Configuration Guide.
> License
> Lawful Intercept is included with purchase of MME bundle
> MME Inter-Chassis Session Recovery
> The ASR-5000 provides industry-leading carrier class redundancy. The systems protects against all single points of failure (hardware and software) and attempts to recover to an operational state when multiple simultaneous failures occur.
> The system provides several levels of system redundancy:

> • | Under normal N+1 packet processing card hardware redundancy, if a catastrophic packet processing card failure occurs all affected calls are migrated to the standby packet processing card if possible. Calls which cannot be migrated are gracefully terminated with proper call-termination signaling and accounting records are generated with statistics accurate to the last internal checkpoint

> • | If the Session Recovery feature is enabled, any total packet processing card failure will cause a packet processing card switchover and all established sessions for supported call-types are recovered without any loss of session.

> Even though ASR 5000 provides excellent intra-chassis redundancy with these two schemes, certain catastrophic failures which can cause total chassis outages, such as IP routing failures, line-cuts, loss of power, or physical destruction of the chassis, cannot be protected by this scheme. In such cases, the MME Inter-Chassis Session Recovery feature provides geographic redundancy between sites. This has the benefit of not only providing enhanced subscriber experience even during catastrophic outages, but can also protect other systems such as the RAN from subscriber re-activation storms.
> The Interchassis Session Recovery feature allows for continuous call processing without interrupting subscriber services. This is accomplished through the use of redundant chassis. The chassis are configured as primary and backup with one being active and one in recovery mode. A checkpoint duration timer is used to control when subscriber data is sent from the active chassis to the inactive chassis. If the active chassis handling the call traffic goes out of service, the inactive chassis transitions to the active state and continues processing the call traffic without interrupting the subscriber session. The chassis determines which is active through a propriety TCP-based connection called a redundancy link. This link is used to exchange Hello messages between the primary and backup chassis and must be maintained for proper system operation.

> • | Interchassis Communication

> Chassis configured to support Interchassis Session Recovery communicate using periodic Hello messages. These messages are sent by each chassis to notify the peer of its current state. The Hello message contains information about the chassis such as its configuration and priority. A dead interval is used to set a time limit for a Hello message to be received from the chassis' peer. If the standby chassis does not receive a Hello message from the active chassis within the dead interval, the standby chassis transitions to the active state. In situations where the redundancy link goes out of service, a priority scheme is used to determine which chassis processes the session. The following priority scheme is used:

> • | router identifier

> • | chassis priority

> • | SPIO MAC address

> • | Checkpoint Messages

> Checkpoint messages are sent from the active chassis to the inactive chassis. Checkpoint messages are sent at specific intervals and contain all the information needed to recreate the sessions on the standby chassis, if that chassis were to become active. Once a session exceeds the checkpoint duration, checkpoint data is collected on the session. The checkpoint parameter determines the amount of time a session must be active before it is included in the checkpoint message.
> Important: For more information on inter-chassis session recovery support, refer Interchassis Session Recovery chapter in System Enhanced Feature Configuration Guide.
> Web Element Management System
> Provides a graphical user interface (GUI) for performing fault, configuration, accounting, performance, and security (FCAPS) management.
> The Web Element Manager is a Common Object Request Broker Architecture (CORBA)-based application that provides complete fault, configuration, accounting, performance, and security (FCAPS) management capability for the system.
> For maximum flexibility and scalability, the Web Element Manager application implements a client-server architecture. This architecture allows remote clients with Java-enabled web browsers to manage one or more systems via the server component which implements the CORBA interfaces. The server component is fully compatible with the fault-tolerant Sun® Solaris® operating system.
> The following figure demonstrates these various element management options and how they can be utilized within the wireless carrier network.
> Element Management Methods
> Important: MME management functionality is enabled by default for console-based access. For GUI-based management support, refer Web Element Management System.
> How MME Works
> This section provides information on the function and procedures of the MME in an EPC network and presents message flows for different stages of session setup.
> The following procedures are supported in this release:

> • | EPS Bearer Context Processing

> • | Purge Procedure

> • | Paging Procedure

> • | Subscriber Session Processing

> • | Connection Setup and Registration Procedures

> • | Subscriber Registration Setup Procedure

> • | UE De-registration Procedures

> • | User-initiated Subscriber De-registration Setup Procedure

> • | Service Request Procedure

> • | User-initiated Service Request Procedure

> EPS Bearer Context Processing
> EPS Bearer context processing is based on the APN that the subscriber is attempting to access. Templates for all of the possible APNs that subscribers will be accessing must be configured within the P-GW system.
> Each APN template consists of parameters pertaining to how EPS Bearer contexts are processed such as the following:

> • | PDN Type: The system supports IPv4, IPv6, or IPv4v6.

> • | Timeout: Absolute and idle session timeout values specify the amount of time that an MS can remain connected.

> • | Quality of Service: Parameters pertaining to QoS feature support such as for Traffic Policing and traffic class.

> A total of 11 EPS bearer contexts are supported per subscriber. These could be all dedicated, or 1 default and 10 dedicated or any combination of default and dedicated context. Note that there must be at least one default EPS bearer context in order for dedicated context to come up.
> Purge Procedure
> The purge procedure is employed by the Cisco MME to inform the concerned node that the MME has removed the EPS bearer contexts of a detached UE. This is usually invoked when the number of records exceeds the maximum capacity of the system.
> Paging Procedure
> Paging is initiated when there is data to be sent to an idle UE to trigger a service request from the UE. Once the UE reaches connected state, the data is forwarded to it.
> Paging retransmission can be controlled by configuring a paging-timer and retransmission attempts on system.
> Subscriber Session Processing
> This section provides information on how LTE/SAE subscriber data sessions are processed by the system MME. The following procedures are provided:

> • | User-initiated Transparent IP: An IP EPS Bearer context request is received by the MME from the UE for a PDN. The subscriber is provided basic access to a PDN without the MME authenticating the subscriber. Either a static or dynamic IP address can be assigned to the MS in this scenario.

> • | User-initiated Non-transparent IP: An IP EPS Bearer context request is received by the MME from the UE for a PDN. The MME provides subscriber authentication services for the data session. Either a static or dynamic IP address can be assigned to the MS in this scenario.

> • | Network-initiated: An IP EPS Bearer context request is received by the MME from the PDN for a specific subscriber. If configured to support network-initiated sessions, the MME, will initiate the process of paging the MS and establishing a EPS Bearer context.

> Subscriber Registration Setup Procedure
> The following figure and the text that follows describe the message flow for a successful user-initiated subscriber registration setup procedure.
> Subscriber Registration Setup Message Flow

> 1. | UE and eNodeB performs Random Access procedure.

> 2. | After Random Access procedure completion, UE sends Attach Request with user identity to eNodeB.

> 3. | The eNodeB forwards the Attach Request to MME

> 4. | MME starts Authentication procedure with eNodeB and UE.

> 5. | Once UE get authenticated MS sends Update Location Request to HSS with user IMSI derived during Authentication procedure.

> 6. | Once user get validated at HSS with IMSI, HSS sends Insert Subscriber Data Request to MME providing subscriber profile and service subscription information to MME.

> 7. | MME sends Create Bearer Request to Serving Gateway.

> 8. | The S-GW forwards the request to P-GW.

> 9. | P-GW reserves the EPS bearer and sends Create Bearer Response to the S-GW and establishes the EPS bearer with S-GW for this user.

> 10. | Once S-GW receives the Create Bearer Response from P-GW it reserves the EPS bearer and sends Create Bearer Response to the MME and establishes the EPS bearer with MME for this user.

> 11. | MME sends Attache Accept Response to eNodeB with new S-TMSI for this user.

> 12. | The eNodeB sends Radio Bearer Establish Request as Attach Accept Response to UE to establish Radio bearer with UE.

> 13. | UE sends Radio Bearer Establish Response as Attach Complete Response to eNodeB.

> 14. | The eNodeB sends Attach Complete Response to MME with Initial EPS Bearer Context Setup procedure.

> 15. | EPS Bearer established between UE and PDN through eNodeB, S-GW, and P-GW and subscriber session starts.

> User-initiated Subscriber De-registration Setup Procedure
> The following figure and the text that follows describe the message flow for a user-initiated subscriber de-registration procedure.
> Subscriber De-registration Setup Message Flow

> 1. | Subscriber session established between UE, eNodeB, S-GW, and P-GW.

> 2. | Optional. If UE in idle or dormant mode it will initiate Random Access procedure.

> 3. | UE initiates detach procedure and sends Detach Request to eNodeB.

> 4. | eNodeB forwards the UE Detach Request to MME.

> 5. | MME sends the Delete Session Request to S-GW for this subscriber.

> 6. | S-GW forwards the Delete Session Request to P-GW for this subscriber.

> 7. | P-GW deletes the EPS bearer for this subscriber and sends the Delete Session Response to S-GW.

> 8. | S-GW deletes the UE context for this subscriber and sends the Delete Session Response to MME.

> 9. | MME removes the subscriber context and sends the Detach Response to eNodeB.

> 10. | MME sends S1 Release Command to eNodeB.

> 11. | eNodeB forwards the Detach Accept to UE.

> 12. | eNodeB starts Radio Release procedure with UE.

> 13. | Once Radio Release procedure completed with UE, eNodeB sends S1 Release Complete response to MME and S1 link released for this UE.

> 14. | Once S1 link released for subscriber, MME sends the Purge UE Request to HSS.

> 15. | HSS clears all UE data and sends the Purge UE Ack to MME and subscriber de-registered.

> Service Request Procedure
> The Service Request procedure is used by the UE in the ECM Idle state to establish a secure connection to the MME as well as request resource reservation for active contexts. The MME allows configuration of the following service request procedures:

> • | Prohibition of services

> • | Enforce identity check

> User-initiated Service Request Procedure
> The following figure and the text that follows describe the message flow for a successful user-initiated subscriber registration setup procedure.
> User-initiated Service Request Message Flow

> 1. | UE and eNodeB performs Random Access procedure.

> 2. | UE sends service request (RRC Connection Request) to eNodeB.

> 3. | eNodeB forwards Service request in Initial UE message to MME.

> 4. | eNodeB preforms contention resolution with UE

> 5. | eNodeB starts RRC connection reconfiguration.

> 6. | eNodeB sends RRC Connection Request Complete and Reconfiguration Complete message to UE.

> 7. | Authentication procedure starts between UE, MME and HSS.

> 8. | eNodeB sends NAS Security Mode Command to UE with selected algorithm.

> 9. | UE sends NAS Security Mode Complete Command to eNodeB.

> 10. | MME sends initial Context Setup Request to eNodeB with radio bearer QoS, security algorithm etc.

> 11. | eNodeB sends RB_Establishment Request to UE.

> 12. | UE sends RB_Establishment Response to eNodeB and radio bearer established.

> 13. | eNodeB sends initial Context Setup Request Response to MME.

> 14. | MME sends Modify Bearer Request to S-GW.

> 15. | S-GW modify the session for this UE and sends Modify Bearer Request response to MME.

> Network-initiated Service Request Procedure
> The following figure and the text that follows describe the message flow for a successful network-initiated service request procedure.
> Network-initiated Service Request Message Flow

> 1. | Downlink data received on S-GW from PDN for targeted UE.

> 2. | S-GW sends Downlink Data notification to MME for a targeted UE.

> 3. | MME sends Downlink Data notification acknowledgement to S-GW.

> 4. | MME send Paging request to eNodeB for targeted UE.

> 5. | eNodeB broadcasts Paging request in its coverage area for UE.

> 6. | Once identified UE located S-GW and eNodeB starts messaging through UE Paging response.

> 7. | S-GW sends Stop Paging message to MME.

> 8. | Data downlink starts between identified UE and PDN.

> Supported Standards
> The MME complies with the following standards for 3GPP LTE/EPS wireless networks.

> • | 3GPP References

> • | IETF References

> • | Object Management Group (OMG) Standards

> 3GPP References

> • | 3GPP TS 23.122 V8.4.0 (2008-12): 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Non-Access-Stratum (NAS) functions related to Mobile Station (MS) in idle mode (Release 8)

> • | 3GPP TS 23.401 V8.1.0 (2008-03): 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access (Release 8)

> • | 3GPP TS 24.301 V8.0.0 (2008-12): 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS); Stage 3 (Release 8)

> • | 3GPP TR 24.801 V8.0.1 (2008-10): 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; 3GPP System Architecture Evolution; CT WG1 Aspects (Release 8)

> • | 3GPP TS 29.274 V8.1.0 (2009-03): 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; 3GPP Evolved Packet System (EPS); Evolved General Packet Radio Service (GPRS) Tunnelling Protocol for Control plane (GTPv2-C); Stage 3 (Release 8)

> • | 3GPP TS 33.401 V8.2.1 (2008-12): 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 3GPP System Architecture Evolution (SAE): Security Architecture; (Release 8)

> • | 3GPP TS 36.401 V8.4.0 (2008-12): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Architecture description (Release 8)

> • | 3GPP TS 36.410 V8.1.0 (2008-12): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Access Network (E-UTRAN); S1 General aspects and principles (Release 8)

> • | 3GPP TS 36.411 V8.1.0 (2008-12): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Access Network (E-UTRAN); S1 layer 1 (Release 8)

> • | 3GPP TS 36.412 V8.4.0 (2008-12): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Access Network (E-UTRAN); S1 signaling transport (Release 8)

> • | 3GPP TS 36.413 V8.4.0 (2008-12): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1 Application Protocol (S1AP) (Release 8)

> IETF References

> • | RFC-768, User Datagram Protocol (UPD), August 1980

> • | RFC-791, Internet Protocol (IP), September 1982

> • | RFC-793, Transmission Control Protocol (TCP), September 1981

> • | RFC-894, A Standard for the Transmission of IP Datagrams over Ethernet Networks, April 1984

> • | RFC-1089, SNMP over Ethernet, February 1989

> • | RFC-1144, Compressing TCP/IP headers for low-speed serial links, February 1990

> • | RFC-1155, Structure & identification of management information for TCP/IP-based internets, May 1990

> • | RFC-1157, Simple Network Management Protocol (SNMP) Version 1, May 1990

> • | RFC-1212, Concise MIB Definitions, March 1991

> • | RFC-1213, Management Information Base for Network Management of TCP/IP-based Internets: MIB-II, March 1991

> • | RFC-1215, A Convention for Defining Traps for use with the SNMP, March 1991

> • | RFC-1224, Techniques for managing asynchronously generated alerts, May 1991

> • | RFC-1256, ICMP Router Discovery Messages, September 1991

> • | RFC-1305, Network Time Protocol (Version 3) Specification, Implementation and Analysis, March 1992

> • | RFC-1332, The PPP Internet Protocol Control Protocol (IPCP), May 1992

> • | RFC-1398, Definitions of Managed Objects for the Ethernet-Like Interface Types, January 1993

> • | RFC-1418, SNMP over OSI, March 1993

> • | RFC-1570, PPP LCP Extensions, January 1994

> • | RFC-1643, Definitions of Managed Objects for the Ethernet-like Interface Types, July 1994

> • | RFC-1701, Generic Routing Encapsulation (GRE), October 1994

> • | RFC-1850, OSPF Version 2 Management Information Base, November 1995

> • | RFC-1901, Introduction to Community-based SNMPv2, January 1996

> • | RFC-1902, Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2), January 1996

> • | RFC-1903, Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2), January 1996

> • | RFC-1904, Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2), January 1996

> • | RFC-1905, Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2), January 1996

> • | RFC-1906, Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2), January 1996

> • | RFC-1907, Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2), January 1996

> • | RFC-1908, Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework, January 1996

> • | RFC-1918, Address Allocation for Private Internets, February 1996

> • | RFC-1919, Classical versus Transparent IP Proxies, March 1996

> • | RFC-2002, IP Mobility Support, May 1995

> • | RFC-2003, IP Encapsulation within IP, October 1996

> • | RFC-2004, Minimal Encapsulation within IP, October 1996

> • | RFC-2005, Applicability Statement for IP Mobility Support, October 1996

> • | RFC-2118, Microsoft Point-to-Point Compression (MPPC) Protocol, March 1997

> • | RFC 2131, Dynamic Host Configuration Protocol

> • | RFC-2136, Dynamic Updates in the Domain Name System (DNS UPDATE)

> • | RFC-2211, Specification of the Controlled-Load Network Element Service

> • | RFC-2246, The Transport Layer Security (TLS) Protocol Version 1.0, January 1999

> • | RFC-2328, OSPF Version 2, April 1998

> • | RFC-2344, Reverse Tunneling for Mobile IP, May 1998

> • | RFC-2394, IP Payload Compression Using DEFLATE, December 1998

> • | RFC 2401, Security Architecture for the Internet Protocol

> • | RFC 2402, IP Authentication Header (AH)

> • | RFC 2406, IP Encapsulating Security Payload (ESP)

> • | RFC 2409, The Internet Key Exchange (IKE)

> • | RFC-2460, Internet Protocol Version 6 (IPv6)

> • | RFC-2461, Neighbor Discovery for IPv6

> • | RFC-2462, IPv6 Stateless Address Autoconfiguration

> • | RFC-2486, The Network Access Identifier (NAI), January 1999

> • | RFC-2571, An Architecture for Describing SNMP Management Frameworks, April 1999

> • | RFC-2572, Message Processing and Dispatching for the Simple Network Management Protocol (SNMP), April 1999

> • | RFC-2573, SNMP Applications, April 1999

> • | RFC-2574, User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3), April 1999

> • | RFC-2597, Assured Forwarding PHB Group, June 1999

> • | RFC-2598, Expedited Forwarding PHB, June 1999

> • | RFC-2618, RADIUS Authentication Client MIB, June 1999

> • | RFC-2620, RADIUS Accounting Client MIB, June 1999

> • | RFC-2661, Layer Two Tunneling Protocol “L2TP”, August 1999

> • | RFC-2697, A Single Rate Three Color Marker, September 1999

> • | RFC-2698, A Two Rate Three Color Marker, September 1999

> • | RFC-2784, Generic Routing Encapsulation (GRE) - March 2000, IETF

> • | RFC-2794, Mobile IP Network Access Identifier Extension for IPv4, March 2000

> • | RFC-2809, Implementation of L2TP Compulsory Tunneling via RADIUS, April 2000

> • | RFC-2845, Secret Key Transaction Authentication for DNS (TSIG), May 2000

> • | RFC-2865, Remote Authentication Dial In User Service (RADIUS), June 2000

> • | RFC-2866, RADIUS Accounting, June 2000

> • | RFC-2867, RADIUS Accounting Modifications for Tunnel Protocol Support, June 2000

> • | RFC-2868, RADIUS Attributes for Tunnel Protocol Support, June 2000

> • | RFC-2869, RADIUS Extensions, June 2000

> • | RFC-3007, Secure Domain Name System (DNS) Dynamic Update, November 2000

> • | RFC-3012, Mobile IPv4 Challenge/Response Extensions, November 2000

> • | RFC-3056, Connection of IPv6 Domains via IPv4 Clouds, February 2001

> • | RFC-3101 OSPF-NSSA Option, January 2003

> • | RFC-3143, Known HTTP Proxy/Caching Problems, June 2001

> • | RFC-3193, Securing L2TP using IPSEC, November 2001

> • | RFC-3314, Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards, September 2002

> • | RFC-3316, Internet Protocol Version 6 (IPv6) for Some Second and Third Generation Cellular Hosts, April 2003

> • | RFC-3706, A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers, February 2004

> • | RFC-3543, Registration Revocation in Mobile IPv4, August 2003

> • | RFC 3588, Diameter Base Protocol, September 2003

> • | RFC 4006, Diameter Credit-Control Application, August 2005

> • | Draft, Route Optimization in Mobile IP

> • | Draft, Generalized Key Distribution Extensions for Mobile IP

> • | Draft, AAA Keys for Mobile IP

> Object Management Group (OMG) Standards

> • | CORBA 2.6 Specification 01-09-35, Object Management Group

Cisco Systems Inc.
Tel: 408-526-4000
Fax: 408-527-0883