Codigos Convolucionales-Carlos Sanchez

9471 Wireless Mobility Manager LTE Parameters User Guide for MME Application
9471 WIRELESS MOBILITY MANAGER

LTE PARAMETERS USER GUIDE FOR MME
APPLICATION
EXTERNAL
LTE/DCL/APP/031094
JUNE 2016
SYSTEM RELEASE: LR16.1 L
PRELIMINARY 11.01 /EN
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
1 / 652
About Nokia
Nokia is a registered trademark of Nokia Corporation. Other products and company names
mentioned herein may be trademarks or tradenames of their respective owners.
For more information, visit Nokia on the Internet:
http://www.nokia.com
Notice
The information presented is subject to change without notice. No responsibility is assumed for
inaccuracies contained herein.
2016 Nokia. Allrights reserved.
Contains proprietary/trade secret information which is the property of Nokia and must not be made
available to, or copied or used by anyone outside Nokia without its written authorization. Not to be
used or disclosed except in accordance with applicable agreements.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
2 / 652
Contents
CONTENTS ..............................................................................................................................................3
LIST OF TABLES ..................................................................................................................................13
LIST OF FIGURES .................................................................................................................................14
1 INTRODUCTION .................................................................................................................................17
1.1 OBJECTIVE .......................................................................................................................................17
1.2 SCOPE OF THIS VOLUME ...................................................................................................................17
1.3 AUDIENCE FOR THIS DOCUMENT ........................................................................................................17
1.4 LPUG TERMINOLOGY .......................................................................................................................18
2 RELATED DOCUMENTS AND PREREQUISITES ............................................................................19
2.1 PREREQUISITE FOR READING THIS VOLUME .......................................................................................19
2.2 REFERENCE DOCUMENTS .................................................................................................................19
3 LTE OVERVIEW .................................................................................................................................21
3.1 MOTIVATION FOR LTE .......................................................................................................................21
3.2 LTE ARCHITECTURE OVERVIEW ........................................................................................................22
3.3 EUTRAN C-PLANE PROTOCOL STACK OVERVIEW .............................................................................24
3.3.1 e-UTRAN & ePC Functional Split.............................................................................................24
3.3.1.1
eNB Functions .............................................................................................................26
3.3.1.2
MME Functions ............................................................................................................27
3.3.1.3
S-GW Functions...........................................................................................................28
3.3.1.4
P-GW Functions...........................................................................................................28
3.3.1.5
SRS functions ..............................................................................................................28
4 MME INTERFACES ............................................................................................................................29
4.1 RS10 ...............................................................................................................................................34
4.2 S1-MME ..........................................................................................................................................35
4.2.1 Multiple S1MME local IP addresses.......................................................................................37
4.2.2 Shared IP address between S1MME and M3 interfaces .......................................................37
4.3 S3 ...................................................................................................................................................39
4.4 S4 ...................................................................................................................................................41
4.5 S6A .................................................................................................................................................42
4.6 S6D .................................................................................................................................................44
4.7 S6AD ...............................................................................................................................................44
4.8 S10 .................................................................................................................................................45
4.9 S11 .................................................................................................................................................46
4.10 S12 ...............................................................................................................................................50
4.11 S13 ...............................................................................................................................................51
4.12 S102 .............................................................................................................................................53
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
3 / 652
4.13 SBC ..............................................................................................................................................55
4.14 SDS (SGS LITE) ............................................................................................................................56
4.15 SGS ...............................................................................................................................................57
4.16 SLG...............................................................................................................................................58
4.17 SLS................................................................................................................................................59
4.18 SM .................................................................................................................................................60
4.19 SV .................................................................................................................................................61
4.20 GN ................................................................................................................................................62
4.21 M3 .................................................................................................................................................64
4.22 X1_1 .............................................................................................................................................65
4.23 X2 (IRI)..........................................................................................................................................66
5 MME OA&M ........................................................................................................................................67
5.1 MME MANAGEMENT INTERFACES ......................................................................................................68
5.1.1 TMN Model by ITU-T ................................................................................................................68
5.1.1.1
General Description .....................................................................................................68
5.1.1.2
TMN Model ..................................................................................................................68
5.1.1.3
Business Management Layer ......................................................................................68
5.1.1.4
Service Management Layer .........................................................................................69
5.1.1.5
Network Management Layer ........................................................................................69
5.1.1.6
Element Management Layer ........................................................................................69
5.1.1.7
Network Element Layer................................................................................................70
5.1.1.8
Related information ......................................................................................................70
5.1.2 TMN Model in the 9471 WMM Architecture .............................................................................70
5.1.2.1
Layers ..........................................................................................................................70
5.1.2.2
NML Systems ...............................................................................................................70
5.1.2.3
EML Elements ..............................................................................................................70
5.1.2.4
NEL Elements ..............................................................................................................70
5.1.2.5
SNEL Elements ............................................................................................................71
5.1.2.6
MI-Agent.......................................................................................................................71
5.1.2.7
Northbound Interfaces .................................................................................................71
5.1.2.8
Discovery for MI-Agent ................................................................................................72
5.1.2.9
Access to SNES via MI-Agent .....................................................................................72
5.1.2.10
Netconf Protocol ..........................................................................................................72
5.1.2.11
Maintenance Terminal .................................................................................................72
5.1.3 9471 WMM ATCA OAM&P Architecture ..................................................................................73
5.1.4 5620 SAM.................................................................................................................................75
5.1.4.1
MME Provisioning with SAM GUI ................................................................................77
5.1.4.1.1
MME Provisioning Sequence .................................................................................77
5.1.4.1.1.1 Required Provisioning ..........................................................................................................77
5.1.4.1.1.2 Provisioning Optional Interfaces...........................................................................................78
5.1.4.1.1.2.1
SGs (Interface to 3G-MSC/VLR) .......................................................................80
5.1.4.1.1.2.2
S3 (Interface to Release 8 SGSNs (S4-SGSN)) ...............................................80
5.1.4.1.1.2.3
Gn (Interface to Pre-Release 8 SGSNs) ...........................................................80
5.1.4.1.1.2.4
S10 (Inter-MME Connections, MME Pooling) ...................................................80
5.1.4.1.1.2.5
X1_1 and X2 (Lawful Intercept Interfaces) ........................................................80
5.1.4.1.1.2.6
S13 (Interface to 1st EIR) ...................................................................................81
5.1.4.1.1.2.7
S13 (Interface to 2nd through 4th EIRs) ..............................................................81
5.1.4.1.1.2.8
S13 (Converting from Combined S6a/S13 to Standalone S13) ........................81
5.1.4.1.1.2.9
SLs (Interface to E-SMLC, for Location-Based Services) .................................82
5.1.4.1.1.2.10
SLg (Interface to GMLC, for Location-Based Services) ....................................82
5.1.4.1.1.2.11
SBc (Interface to CBC, for Warning Message Delivery) ...................................82
5.1.4.1.1.2.12
M3 (Interface to Multicast Control Entity (MCE) in the eNodeB nodes) ............83
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
4 / 652
5.1.4.1.1.2.13
Sm (Interface to MBMS or eMBMS Gateway)...................................................83
5.1.4.1.1.2.14
Sv (Interface to MSC Server, for SRVCC Support) ...........................................83
5.1.4.1.1.2.15
S102 (Interface to 1xCS IWS) ...........................................................................83
5.1.4.1.1.2.16
SRS provisioning ...............................................................................................84
5.1.4.1.1.3 Provisioning Optional Functionality ......................................................................................85
5.1.4.1.1.3.1
Paging Methods and Neighbors ........................................................................85
5.1.4.1.1.3.2
SGW Discovery .................................................................................................85
5.1.4.1.1.3.3
Equivalent PLMNs .............................................................................................85
5.1.4.1.1.3.4
Roaming PLMNs ...............................................................................................85
5.1.4.1.1.3.5
Insert/Delete Tracking Areas .............................................................................86
5.1.4.1.1.3.6
Insert/Delete SGW & SGW Pools .....................................................................86
5.1.4.1.1.3.7
Change local port for in-service profiles ............................................................87
5.1.4.1.1.3.8
Time Zone provisioning .....................................................................................87
5.1.4.1.1.3.9
EPS Integrity Protection Algorithm and EPS Encryption Algorithm ..................88
5.1.4.1.1.3.10
IMSI Range ........................................................................................................88
5.1.4.1.1.3.11
MME Discovery .................................................................................................88
5.1.4.1.1.3.12
Automatic Neighbor List generation ..................................................................88
5.1.4.1.1.3.13
NAS cause code ................................................................................................89
5.1.4.1.1.3.14
Convert IPv4 connections to IPv6 .....................................................................89
5.1.4.1.1.3.15
IMS Emergency Services ..................................................................................89
5.1.4.1.1.3.16
Location-Based Services ...................................................................................90
5.1.4.1.1.3.17
Warning Message Delivery (CMAS)..................................................................90
5.1.4.1.1.3.18
eMBMS ..............................................................................................................90
5.1.4.1.1.3.19
CSFB Enhancements ........................................................................................90
5.1.4.1.1.3.20
SMS-Only Over SGs Interface ..........................................................................91
5.1.4.1.1.3.21
SRVCC MSC Discovery ....................................................................................91
5.1.4.1.1.3.22
Network Sharing ................................................................................................91
5.1.4.1.2
5620 SAM Provisioning GUI Rules.........................................................................91
5.1.4.1.3
Related Information ................................................................................................91
5.1.5 9471 WMM MME Local OAM&P ..............................................................................................92
5.1.5.1
MI-Agent.......................................................................................................................92
5.1.5.1.1
Overview .................................................................................................................92
5.1.5.1.2
MI-Agent GUI ..........................................................................................................92
5.1.5.1.3
5.1.5.1.4
MI-Agent User Access Rules and Troubleshooting ................................................93
5.1.5.2
8950 ID GUI ..............................................................................................................93
5.1.5.2.1
5.1.5.2.2
8950 ID GUI Screens ...........................................................................................94
5.1.5.3
Command Line Interface..............................................................................................95
5.1.5.3.1
5.1.5.3.2
User Access Methods .............................................................................................96
5.2 FAULT MANAGEMENT AND STATE MANAGEMENT ................................................................................97
5.2.1 CPI Thresholds.........................................................................................................................98
5.2.2 Per Call Measurement Data (PCMD) .....................................................................................103
5.2.3 Call Trace ...............................................................................................................................104
5.2.4 HSS initiated call trace ...........................................................................................................105
5.2.4.1
ePC deactivation mechanisms ..................................................................................108
5.2.4.2
Interaction between HSS and on demand call traces on the same IMSI ..................108
5.2.5 WMM Overload Control ..........................................................................................................108
5.2.5.1
Low Priority Access Overload Control .......................................................................108
5.2.5.1.1
LPA S1AP Overload Control ................................................................................109
5.2.5.1.2
shedding of lpa MM/SM procedures (General NAS Mobility Management and
Session Management Congestion Control) ................................................................................110
5.2.5.1.3
MME overload control enhancements: Throttling of DDN (Downlink Data
Notification) requests...................................................................................................................111
5.2.5.2
PCMD Overload Control ............................................................................................113
5.3 SOFTWARE LICENSING ....................................................................................................................116
6 MME NETWORK PROVISIONING ...................................................................................................117
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
5 / 652
6.1 PLMN IDENTIFICATION ....................................................................................................................117
6.1.1 Mobile Country Code .............................................................................................................118
6.1.2 Mobile Network Code .............................................................................................................118
6.1.3 PLMN .....................................................................................................................................119
6.1.4 Home and Equivalent PLMNs ................................................................................................120
6.1.5 Roaming PLMN ......................................................................................................................122
6.1.6 ISDN Country Code................................................................................................................124
6.1.7 MNC Length ...........................................................................................................................124
6.1.8 Inter-Gateway Protocol ..........................................................................................................125
6.1.9 Operator Determined Barring Supported ...............................................................................125
6.1.10 Access Not Allowed .............................................................................................................127
6.1.11 UE Roaming Allowed ...........................................................................................................128
6.1.12 VPLMN HSS IP Addresses ..................................................................................................129
6.1.13 QoS Profile for Visiting Roaming Subscribers .....................................................................130
6.1.14 QoS Profile for Visiting Roaming Subscribers .....................................................................131
6.1.14.1.1
Default Roamer Policy for a Roamer IMSI series .................................................132
6.1.14.1.2
Default Roamer Policy for IMS APNs ...................................................................133
6.1.14.1.3
Local Roamer Qos Policy .....................................................................................133
6.1.14.1.4
Treating an IMSI Series as Home Subscribers ....................................................134
6.1.14.1.5
PGW overrides .....................................................................................................135
6.1.14.1.6
Local Breakout Enhancements .............................................................................137
6.1.14.1.7
Restricting UE access to a network based on Regional Subscription Zone Code
(RSZC)
143
6.1.14.1.8
Roaming enhancements .......................................................................................146
6.2 WMM FIELD INSTALL/SYSTEM INFORMATION....................................................................................149
6.3 MME IDENTIFICATION .....................................................................................................................151
6.3.1 Home MME ............................................................................................................................152
6.3.2 Local Name ............................................................................................................................153
6.3.3 MME Code (MMEC) ...............................................................................................................154
6.3.4 S10 IP Address ......................................................................................................................155
6.3.5 eNB MME selection algorithm using the mapped GUMMEI ..................................................156
6.3.6 MME Time Zone .....................................................................................................................157
6.3.7 eNB Time Zone ......................................................................................................................158
6.3.8 UE Time Zone ........................................................................................................................159
6.4 MME POOLING ...............................................................................................................................160
6.4.1 MME Group Identifier (MMEGI) .............................................................................................162
6.4.2 MME Discovery Via DNS .......................................................................................................163
6.4.3 MME Group to TAI List ...........................................................................................................164
6.4.4 MME node Relative Capacity .................................................................................................164
6.4.5 MME Relative Capacity per tracking area ..............................................................................166
6.4.6 Auto Adjust Relative Capacity ................................................................................................168
6.4.7 MME load RE-balancing ........................................................................................................169
6.4.8 handling of NAS level mobility management congestion control ...........................................169
6.4.9 Ue load balancing...................................................................................................................176
6.4.9.1
Common UE Load balancing implementation based GUTI/PTMSI reallocation (interWMM UE load balancing) .............................................................................................................176
6.4.9.2
Ue load balancing extended provisionable parameters.............................................179
6.4.9.3
Quarantine mode .......................................................................................................181
6.5 TRACKING AREA IDENTIFIERS ..........................................................................................................182
6.6 TAI NEIGHBOR LIST ........................................................................................................................184
6.7 UE ROAMING RESTRICTION PROFILE ...............................................................................................185
6.8 SERVING GATEWAY ........................................................................................................................187
6.8.1 SGW Identification..................................................................................................................188
6.8.2 SGW Inter-Gateway Protocol .................................................................................................188
6.8.3 SGW Pool ID ..........................................................................................................................189
6.8.4 Serving Gateway Pool to TAI List ..........................................................................................190
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
6 / 652
6.8.5 Serving Gateway Discovery Via DNS ....................................................................................191
6.8.6 NAPTR (Naming Authority Pointer Record) ...........................................................................192
6.9 MSC ..............................................................................................................................................197
6.9.1 MSC Server ID .......................................................................................................................197
6.9.2 SGs Message Delivery Retry Attempts ..................................................................................200
6.9.3 Location Area Code................................................................................................................201
6.9.4 MSC/VLR (IWF) load balancing .............................................................................................202
6.10 REMOTE END POINT CONFIGURATION ............................................................................................204
6.11 CIRCUIT SWITCHED FALLBACK (CSFB) ..........................................................................................208
6.11.1 SMS Only Pointer .................................................................................................................211
6.11.2 Data Centric UE ...................................................................................................................212
6.12 S102-BASED CIRCUIT SWITCHED FALLBACK (ECSFB) ...................................................................213
6.13 SHARED NETWORK SUPPORT ........................................................................................................218
7 MME TRANSPORT PROTOCOLS ...................................................................................................222
7.1 BFD ...............................................................................................................................................222
7.2 SCTP ............................................................................................................................................222
7.3 GTP ..............................................................................................................................................222
7.4 M3-AP ...........................................................................................................................................222
7.5 EPC LCS.......................................................................................................................................223
7.6 LCS-AP .........................................................................................................................................223
7.7 DIAMETER ......................................................................................................................................224
7.8 DIAMETER ROUTING AGENT SUPPORT..............................................................................................225
7.9 S6AD DIAMETER ROUTING AGENT ROAMING SUPPORT ......................................................................227
7.10 MIXED MODE DIAMETER ROUTING AGENT SUPPORT........................................................................228
7.11 SNMPV3 PROTOCOL ....................................................................................................................229
7.11.1 Fault Management ...............................................................................................................229
7.11.2 Administrative Management.................................................................................................229
7.12 TRANSPORT CONTROL PROTOCOL (TCP) ......................................................................................230
7.13 INTERNET PROTOCOL (IP) .............................................................................................................231
8 MME CALL MANAGEMENT ............................................................................................................232
8.1 EMM PROCEDURES ........................................................................................................................233
8.1.1 EMM States ............................................................................................................................233
8.1.2 Network Element Selection ....................................................................................................233
8.1.2.1
Network Element Selection Using DNS .....................................................................233
8.1.2.2
Service Resource records (SRV) for MME DNS discovery .......................................234
8.1.2.3
APN-NI extension for DNS query ..............................................................................238
8.1.2.4
DNS Selection Mechanisms (for SGW/PGW selection) ............................................240
8.1.2.5
Network Element Selection Mode 1........................................................................241
8.1.2.5.1
MME Pooling and Selection .................................................................................241
8.1.2.5.1.1 Selection Using Provisioned MME IP Addresses...............................................................241
8.1.2.5.1.2 Selection Using NAPTR/DNS Query ..................................................................................242
8.1.2.5.1.3 Attach Impact......................................................................................................................243
8.1.2.5.1.4 S1-MME Link Failure Mitigation .........................................................................................244
8.1.2.5.2
SGW Selection Failure .........................................................................................245
8.1.2.5.2.1 Selection Using Provisioned SGW Pool .............................................................................246
8.1.2.5.2.2 Selection Using NAPTR/DNS Query ..................................................................................246
8.1.2.5.2.3 Roaming 247
8.1.2.5.2.4 SGW Selection Failure .......................................................................................................248
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
7 / 652
8.1.2.5.3
APNs and APN Wildcard ......................................................................................248
8.1.2.5.3.1 APN correction ...................................................................................................................251
8.1.2.5.3.2 PDN On demand signaling only UE ...................................................................................253
8.1.2.5.3.3 UE load balancing of On Demand PDN only UEs without a PDN connections .................254
8.1.2.5.4
PGW Selection .....................................................................................................255
8.1.2.5.4.1 Roaming 261
8.1.2.5.4.2 Topological label matching for S8 PGW Selection.............................................................261
8.1.2.5.4.3 PGW selection failure .........................................................................................................261
8.1.2.5.4.4 HPLMN/VPLMN PGW Selection for PDN Connection Requests ......................................262
8.1.2.5.5
Fallback to Default APN-OI on DNS Failures .......................................................266
8.1.2.5.6
SGSN Selection ....................................................................................................267
8.1.2.5.6.1 Pre-Release 8 Discovery....................................................................................................271
8.1.2.5.6.2 Release 8 Discovery ..........................................................................................................273
8.1.2.5.6.3 MME Support for DNS Fallback Enhancements from R8 DNS Query to pre-R8 DNS
Query
275
8.1.2.5.6.4 SGSN Pooling ....................................................................................................................276
8.1.2.5.7
HSS / DRA Selection ............................................................................................277
8.1.2.5.8
HSS / DRA Load balancing: .................................................................................281
8.1.2.5.8.1 HSS user Profile Management ...........................................................................................284
8.1.2.5.8.2 HSS Retry 287
8.1.2.5.8.3 HSS signaling load reduction .............................................................................................288
8.1.2.5.8.4 HSS handling of Disconnect Peer Request and answer (DPR /DPA) ...............................290
8.1.2.5.8.5 support for IMS Voice over PS sessions to the HSS) ........................................................293
8.1.2.5.8.6 Number of Authentication Vectors......................................................................................296
8.1.2.5.8.7 Proxy Call Session Control Function (P-CSCF) Restoration function................................298
8.1.2.5.8.8 SS based P-CSCF recovery for 3GPP access ..................................................................299
8.1.2.5.8.9 S6a fault handling enhancements ......................................................................................302
8.1.2.5.9
SGSN Discovery Using DNS Queries ..................................................................304
8.1.2.6
Network Element Selection Mode 2........................................................................304
8.1.2.6.1
S11 Managed Objects ..........................................................................................306
8.1.2.6.2
PGW/SGW Selection for UE Attach/PDN Request After UE Attach ....................306
8.1.2.6.3
SGW Selection for Intra-LTE ................................................................................307
8.1.2.6.4
PGW reselection if no response from the SGW ...................................................307
8.1.2.6.5
enhanced SGW and PGW selection ....................................................................308
8.1.3 Registered Tracking Area Selection.......................................................................................313
8.1.3.1
Tracking area discovery at eNB setup .......................................................................314
8.1.3.2
Controlling Automatic Neighbor List Generation .......................................................316
8.1.3.2.1
Automatically Add TAI to the TAI List ...................................................................317
8.1.3.2.2
Include provisioned Neighbor List in the Registration TAI List .............................318
8.1.3.3
Limitations and Restrictions for Automatic Neighbor List Generation .......................319
8.1.3.4
Impacts to UE Context Data Maintained by MME .....................................................320
8.1.3.5
Impacts to Attach Procedure .....................................................................................321
8.1.3.6
Impacts to TAU Procedure.........................................................................................321
8.1.3.7
Impacts to Paging Method .........................................................................................322
8.1.3.8
Controlling TAU Suppression ....................................................................................323
8.1.3.8.1
Provisionable TAU Suppression Threshold ..........................................................323
8.1.3.8.2
Scenario: TAU Suppression Triggered by UE toggling between tracking areas ..324
8.1.3.8.3
Scenario: No TAU suppression from normal UE movement between tracking
areas
325
8.1.3.8.4
Alternate T3412 Timer with TAU Suppression .....................................................326
8.1.3.8.5
Optimazation of periodic TAU signalling for LPA UEs ..........................................327
8.1.4 Impact of Forbidden PLMN using Regional Subscription Zone Codes (RSZC) ....................328
8.1.5 Handover Restrictions ............................................................................................................330
8.1.6 Roaming .................................................................................................................................330
8.1.7 Emergency Bearer and Location Services Functionality .......................................................332
8.1.7.1
IMS Emergency Services...........................................................................................333
8.1.7.1.1
Emergency Profile ................................................................................................339
8.1.7.1.2
Emergency Number List .......................................................................................345
8.1.7.2
Location-Based Services ...........................................................................................347
8.1.7.3
Warning Message Delivery (CMAS) ..........................................................................373
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
8 / 652
8.1.7.3.1
Restoration of Warning Message Delivery upon eNB Failure/Restart .................379
8.1.7.4
Multimedia Broadcast/Multicast Service ....................................................................381
8.1.8 Multimedia Priority Service (MPS) .........................................................................................384
8.1.8.1
Determining High Priority Access ..............................................................................385
8.1.8.2
Roaming .....................................................................................................................386
8.1.8.3
Provisioned Parameters.............................................................................................386
8.1.9 Home enodeb .........................................................................................................................388
8.1.9.1
X2 support ..................................................................................................................389
8.1.9.2
S1 HO SUPPORT ......................................................................................................389
8.1.9.3
HO with S4 SGSN and Gn/Gp SGSN interactions ....................................................390
8.1.9.4
Closed Subscriber Group (CSG) access restrictions for HO scenarios ....................390
8.1.9.5
Impact to MME procedures ........................................................................................391
8.1.10 Attach Request .....................................................................................................................391
8.1.11 TAU Request ........................................................................................................................391
8.1.12 SERvice request...................................................................................................................392
8.1.13 paging optimization ..............................................................................................................392
8.1.14 Detach procedure .................................................................................................................393
8.1.15 X2 Handover ........................................................................................................................394
8.1.16 s1 HO ...................................................................................................................................396
8.1.17 irat HO ..................................................................................................................................396
8.1.18 LIPA architecture ..................................................................................................................397
8.1.18.1
LIPA mobility ..............................................................................................................398
8.1.18.2
Impact to the idle mode TAU procedure ....................................................................398
8.1.19 GUTI Reallocation Procedure ..............................................................................................399
8.1.20 Directed Inter-MME UE Move ..............................................................................................401
8.1.21 Authentication and Key Agreement (AKA) Procedure .........................................................404
8.1.22 EMM Information Procedure ................................................................................................406
8.1.23 Identification Procedure .......................................................................................................409
8.1.24 Security Mode Command Procedure ...................................................................................410
8.1.25 Attach Procedure..................................................................................................................411
8.1.25.1
Initial Attach Procedure ..............................................................................................411
8.1.25.2
Combined Attach Request .........................................................................................413
8.1.25.3
Message Collision Handling (Attach) .........................................................................415
8.1.25.4
Roaming .....................................................................................................................416
8.1.25.5
Attach Request Rejection ..........................................................................................419
8.1.25.6
Inter-PLMN provisioning for Attach Restrictions ........................................................421
8.1.25.7
S1-AP Reset ..............................................................................................................423
8.1.25.8
Queue Network Initiated ESM Requests During Initial Attach Procedure .................423
8.1.25.9
APN correction ...........................................................................................................424
8.1.25.10 UE Power Saving Mode .............................................................................................425
8.1.26 Extended Service Request Procedure .................................................................................428
8.1.26.1
Support for 3G1X Voice on Dual Receiver/ Transmitter Handset .............................428
8.1.26.2
DTR Handset Procedures ..........................................................................................429
8.1.26.3
Roaming .....................................................................................................................439
8.1.26.4
Extended Service Request Rejection ........................................................................440
8.1.26.5
8.1.27 enhanced restoration procedure FOR Extanded service request (eSR) .............................442
8.1.28 Detach Procedure ................................................................................................................443
8.1.28.1
UE Detach Upon Moving Across Region ...................................................................445
8.1.28.2
Message Collision Handling (Detach)........................................................................450
8.1.28.3
Controlling UE behavior after MME detach ...............................................................451
8.1.28.4
S1-AP Reset ..............................................................................................................451
8.1.29 Tracking Area Update Procedure.........................................................................................452
8.1.29.1
TAU Call Flows ..........................................................................................................453
8.1.29.2
Enhanced restoration procedure impact on TAU Request ........................................455
8.1.29.3
Gn-based TAU Procedure .........................................................................................457
8.1.29.4
S3-based TAU ...........................................................................................................459
8.1.29.5
Enhanced restoration procedure for TAU requests ...................................................461
8.1.29.6
Enhanced Restoration procedure impact on TAU with EPS Update. ........................462
8.1.29.7
Support for A/GB and IU Mode Capable UES ...........................................................463
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
9 / 652
8.1.29.8
Determine GUTI Origination ......................................................................................463
8.1.29.9
Roaming .....................................................................................................................464
8.1.29.10 Inter-PLMN provisioning for TAU Restrictions ...........................................................465
8.1.29.11 TAU Request Rejection .............................................................................................466
8.1.29.12 Message Collision Handling ......................................................................................467
8.1.29.13 S1-AP Reset ..............................................................................................................472
8.1.29.14 Power Saving Mode (PSM)........................................................................................472
8.1.30 Service Request Procedure .................................................................................................474
8.1.30.1
Message collision handling ........................................................................................475
8.1.30.2
Roaming .....................................................................................................................476
8.1.30.3
Service Request Rejection.........................................................................................477
8.1.30.4
S1-AP Reset ..............................................................................................................477
8.1.31 Paging Procedure.................................................................................................................478
8.1.31.1
Paging Strategy .........................................................................................................478
8.1.31.2
Paging Initiated By MME............................................................................................478
8.1.31.3
Paging Policy Selection Based on QCI......................................................................481
8.1.31.4
Paging Initiated By MSC/VLR ....................................................................................482
8.1.31.5
SGs Paging Enhancements .......................................................................................486
8.1.31.6
Network-Initiated Paging ............................................................................................487
8.1.31.7
SGs-AP Paging Request ...........................................................................................488
8.1.31.8
Message Collision Handling ......................................................................................488
8.1.31.9
Provisioned Paging Parameters ................................................................................490
8.1.32 Inter-eNodeB X2-based Handover Procedure .....................................................................497
8.1.32.1
Message Collision Handling ......................................................................................499
8.1.32.2
Neighbor Information Collection ................................................................................499
8.1.32.3
S1-AP Reset ..............................................................................................................502
8.1.32.3.1
Extended Queuing for all CSFB Scenarios (X2HO triggered) ..............................502
8.1.32.3.2
Enhanced Queuing Network Initiated Session Requests for X2HO .....................503
8.1.33 Inter RAT Handover procedure ............................................................................................504
8.1.33.1
e-UTRAN to UTRAN IRAT Handover ........................................................................505
8.1.33.2
UTRAN to E-UTRAN IRAT Handover........................................................................508
8.1.33.3
E-UTRAN to GERAN A/Gb IRAT Handover ..............................................................511
8.1.33.4
Queue Network Initiated ESM Requests During IRAT HO Procedure ......................519
8.1.33.5
Enhanced queuing for network-initiated sessions IRAT ............................................520
8.1.33.6
Direct Forwarding and Indirect Forwarding................................................................520
8.1.33.7
Support for A/GB and IU Mode Capable UES ...........................................................521
8.1.33.8
Network Assisted Cell Change (NACC).....................................................................521
8.1.33.8.1
RIM Procedures ....................................................................................................521
8.1.33.9
Failure handling .........................................................................................................522
8.1.33.10 Inter RAT Provisioned Parameters ............................................................................522
8.1.34 Intra-LTE S1-based Handover Procedure ...........................................................................527
8.1.34.1
Failure Scenarios .......................................................................................................533
8.1.34.2
8.1.34.3
Extended Queuing for CSFB Scenarios (S1 HO triggered).......................................536
8.1.34.4
Enhanced Queuing Network Initiated Session Requests for S1 HO .........................536
8.1.34.5
S11 CIDF configuration Parameters ..........................................................................538
8.1.35 Routing Area Update Procedure ..........................................................................................538
8.1.35.1
GN-based RAU ..........................................................................................................539
8.1.35.2
S3-Based RAU ...........................................................................................................541
8.1.36 E-UTRAN Radio Access Bearer (E-RAB) Procedure ..........................................................543
8.1.36.1
E-RAB Setup ..............................................................................................................543
8.1.36.2
E-RAB Release ..........................................................................................................544
8.1.37 UE Context Procedure .........................................................................................................544
8.1.37.1
Initial Context Setup ...................................................................................................545
8.1.37.2
UE Context Release Request - ENODEB-initiated ....................................................546
8.1.37.3
UE Context Release Request - MME-initiated...........................................................548
8.1.37.4
UE Context Modification ............................................................................................549
8.1.37.5
Collision Handling ......................................................................................................550
8.1.38 Enhanced restoration procedures ........................................................................................551
8.1.38.1
DDN with IMSI and service request ...........................................................................551
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
10 / 652
8.1.38.2
Restoration Service Request .....................................................................................554
8.1.38.3
Restoration Extended Service Request .....................................................................555
8.1.39 EMM Procedure Common Parameters ................................................................................556
8.1.39.1
MME Relocation .........................................................................................................556
8.1.39.2
Zone Code Parameters..............................................................................................557
8.1.39.3
IMEI Parameters ........................................................................................................558
8.1.39.4
Mobility Management Timers .....................................................................................561
8.1.39.5
Number of Message Retransmissions .......................................................................565
8.1.39.6
Deleting Dynamically Created Managed Objects ......................................................567
8.1.39.7
Implicit/Explicit Detach ...............................................................................................568
8.1.39.8
SCTP Delivery ...........................................................................................................568
8.1.39.9
S1 Timer Provisioning ................................................................................................569
8.1.39.10 NAS Provisioning .......................................................................................................572
8.1.39.11 NAS Cause Code Provisioning ..................................................................................574
8.1.39.12 Diameter cause code provisioning .............................................................................580
8.1.39.13 Extend Procedures to Include ULI Message .............................................................585
8.2 ESM PROCEDURES ........................................................................................................................589
8.2.1 ESM Overview........................................................................................................................589
8.2.1.1
ESM Procedures ........................................................................................................589
8.2.1.2
Network Assisted Cell Change EUTRAN to GERAN .............................................591
8.2.1.3
Piggybacking ..............................................................................................................591
8.2.1.4
Cell Reselection and Redirection ...............................................................................592
8.2.1.5
Enhanced SGW restoration procedure ......................................................................593
8.2.1.6
S11 PGW Restart notification ....................................................................................598
8.2.2 EPS Bearers...........................................................................................................................604
8.2.2.1
Multiple Bearers and Multiple PDNs ..........................................................................605
8.2.3 EPS Bearers and QoS ...........................................................................................................607
8.2.3.1
Allocation and Retention Priority (ARP) .....................................................................608
8.2.3.2
Operator Defined QoS Class Identifier (QCI) ............................................................610
8.2.3.3
QOS Mapping ............................................................................................................612
8.2.3.4
Mapping EPS Bearer QOS to 3G UMTS PDP Context QOS ....................................614
8.2.4 Message collision handling during ESM procedures .............................................................617
8.2.5 SGW and PGW Reselection ..................................................................................................618
8.2.5.1
Reselection Methods .................................................................................................618
8.2.5.1
Provisionable Depth of Retry for SGW/PGW Re-selection .......................................620
8.2.6 Single Radio Voice Call Continuity.........................................................................................621
8.2.6.1
SRVCC Call Flow CS-Only HO ..............................................................................621
8.2.6.2
SRVCC Call Flow CS+PS HO ................................................................................622
8.2.6.3
SRVCC Provisioned Parameters ...............................................................................622
8.2.7 Single Radio Voice Call Continuity across S102 interface.....................................................624
8.2.7.1
Reference architecture service for E-UTRAN to 3GPP2 1xCS SRVCC ...................624
8.2.7.2
eUtran-to-voice- service continuity procedure ...........................................................625
8.2.8 SRVCC emergency call handling ...........................................................................................629
8.2.9 Session restoration server (SRS)...........................................................................................630
8.2.10 Machine-type communications (MTC) .................................................................................633
8.2.10.1
UE LPA (Low priority access) ....................................................................................633
8.2.10.2
Dual Priority UE handling: ..........................................................................................635
9 ANNEXES .........................................................................................................................................637
9.1 ABBREVIATIONS ..............................................................................................................................637
9.2 DEFINITIONS ...................................................................................................................................639
9.3 MI-AGENT GUI EXAMPLES AND INDICATOR LEGEND .........................................................................640
9.3.1 MI-Agent Screen Examples ...................................................................................................640
9.3.2 State/Status and Alarm Indicators on the MI-Agent ...............................................................646
9.3.2.1
State or Status Indicators...........................................................................................647
9.3.2.2
Alarm Indicators .........................................................................................................648
9.4 PARAMETER CHANGES ....................................................................................................................649
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
11 / 652
9.4.1 Parameter Updates for WM10.0.0 .........................................................................................649
9.4.1.1
New Parameters in Release WM10.0.0.....................................................................649
9.4.1.2
WM9.1.0 Parameters that are obsolete in WM10.0.0 ................................................651
9.4.1.3
WM9.1.0 tables and Parameters with New label or Values in WM10.0.0 .................651
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
12 / 652
List of tables
Table 1: 3GPP Standards...................................................................................................................... 33
Table 2: WMM Blade Operating Systems ............................................................................................. 95
Table 3: CPI Alarm Thresholds ........................................................................................................... 102
Table 4 : Shedding/Reject Algorithm ................................................................................................... 115
Table 5 : APN-NI APN-OI ................................................................................................................. 140
Table 6 APN Operator Identifier DNS Domain name derivation ......................................................... 142
Table 7 setting of the Homogeneous-Support-of-IMS-Voice-Over-PS-Sessions AVP when UE IMSI is
not in any of the provisioned IMSI series ..................................................................................... 294
Table 8 setting of the Homogeneous-Support-of-IMS-Voice-Over-PS-Sessions AVP when UE IMSI is
in one or more IMSI series and each IMSI series also has TAI provisioning............................... 295
Table 9: IDR-Flags .............................................................................................................................. 369
Table 10: PLMN Security Procedure Defaults..................................................................................... 400
Table 11: Authentication Interaction Defaults...................................................................................... 405
Table 12: Provisioning for Sending EMM Information Message ......................................................... 406
Table 13 : MME decisions based on Inter-PLMN configuration options. ............................................ 422
Table 14: Extended Service Request Roamer Handling..................................................................... 439
Table 15: Extended Service Request Rejection Scenarios................................................................. 440
Table 16 : TAU procedure with inter PLMN GUTI ............................................................................... 465
Table 17: Service Request Roamer Handling ..................................................................................... 476
Table 18: Service Request Rejection Scenarios ................................................................................. 477
Table 19 SGs Timers........................................................................................................................... 485
Table 20: TAI Values in Paging Messages ......................................................................................... 494
Table 21: enhanced queuing behaviors .............................................................................................. 503
Table 22 Mobility Management Timers ............................................................................................... 564
Table 23: EPS Integrity Algorithm Defaults ......................................................................................... 572
Table 24: EPS Encryption Algorithm Defaults ..................................................................................... 573
Table 25: Access Restriction Default NAS Cause Values .................................................................. 576
Table 26 : NAS Cause Numeric Values and Description .................................................................... 577
Table 27: Diameter result-code AVP to NAS Cause Code Mapping .................................................. 583
Table 28: Diameter experimental-result code AVP to NAS Cause Code Mapping............................. 584
Table 29: How the MME restores the PDN connection based on UEs ECM state and provisioning. 599
Table 30: MME action on the UE based on MM procedures. ............................................................. 601
Table 31: SGW/PGW Reselection Method 1 ...................................................................................... 618
Table 32: SGW/PGW Reselection Method 2 ...................................................................................... 619
Table 33 Machine-type-communication Applications ......................................................................... 633
Table 34: MI-Agent State/Status Indicators......................................................................................... 647
Table 35: MI-Agent Alarm Indicators ................................................................................................... 648
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
13 / 652
List of Figures
Figure 3-1: Summary of Motivations for LTE......................................................................................... 21
Figure 3-2: Summary of Motivations for LTE......................................................................................... 22
Figure 3-3 : LTE Network Architecture .................................................................................................. 22
Figure 3-4: EUTRAN Topology ............................................................................................................. 23
Figure 3-5: S1 and Uu interfaces (signaling control plane) ................................................................... 24
Figure 3-6: Functional Split between E-UTRAN and EPC .................................................................... 25
Figure 3-7: Description of Node Functions ............................................................................................ 26
Figure 4-1: Position of 9471 WMM in LTE SAE .................................................................................... 31
Figure 4-2: MME Interfaces/Functions .................................................................................................. 31
Figure 4-3: SRS - MME Interfaces ........................................................................................................ 34
Figure 4-4: S1-MME Protocol Stack ...................................................................................................... 35
Figure 4-5: S1-MME Heartbeat Support................................................................................................ 35
Figure 4-6: S1-MME Bearer Support..................................................................................................... 36
Figure 4-7: NAS Protocol....................................................................................................................... 37
Figure 4-8: Control Plane for NAS Protocol .......................................................................................... 38
Figure 4-9: S3 Protocol Stack................................................................................................................ 39
Figure 4-10: Control Plane for S4 Interface........................................................................................... 41
Figure 4-11: S6a Protocol Stack ........................................................................................................... 42
Figure 4-12: S6a Heartbeat Support ..................................................................................................... 43
Figure 4-13: S6ad interface ................................................................................................................... 44
Figure 4-14: S10 Protocol Stack ........................................................................................................... 45
Figure 4-15: S10 Heartbeat Support ..................................................................................................... 45
Figure 4-16: S11 Bearer Support .......................................................................................................... 46
Figure 4-18: S11 Heartbeat Support ..................................................................................................... 47
Figure 4-19: Control Plane for S12 Interface......................................................................................... 50
Figure 4-20: S13 Supporting MEID Check Procedure .......................................................................... 51
Figure 4-22: S102 Protocol Stack ......................................................................................................... 53
Figure 4-23: SBc Protocol Stack ........................................................................................................... 55
Figure 4-24: SGs Lite Protocol Stack .................................................................................................... 56
Figure 4-25 MME to GW-TS TCP connections ..................................................................................... 56
Figure 4-26: SGs Protocol Stack ........................................................................................................... 57
Figure 4-27: SLg Protocol Stack ........................................................................................................... 58
Figure 4-28: SLs Protocol Stack ............................................................................................................ 59
Figure 4-29: Sm Protocol Stack ............................................................................................................ 60
Figure 4-30: Sv Protocol Stack .............................................................................................................. 61
Figure 4-31: 3GPP Access for Pre-Release 8 SGSN ........................................................................... 62
Figure 4-32: Gn Protocol Stack ............................................................................................................. 62
Figure 4-33: M3 Protocol Stack ............................................................................................................. 64
Figure 4-34: X1_1 Protocol Stack MME/SGSN to ADMF .................................................................. 65
Figure 4-35: X2 (IRI) Protocol Stack WMM to DF2 ............................................................................ 66
Figure 5-1: ITU-T TMN Model ............................................................................................................... 68
Figure 5-2: 9471 WMM OAM&P Architecture ....................................................................................... 73
Figure 5-3: 5620 SAM Functionality ...................................................................................................... 75
Figure 5-4: 8950 ID GUI for Administrators ........................................................................................ 94
Figure 5-5: 8950 ID GUI for non-administrative users ........................................................................ 94
Figure 5-6: SOL connection to hub faceplate ........................................................................................ 96
Figure 5-7: Containment Tree for WMM MOs ....................................................................................... 98
Figure 5-8: WMM Critical Performance Indicator Table (MAF AttachFailures Example) ...................... 99
Figure 5-9: WMM per Call Measurement Data Table (Example) ........................................................ 103
Figure 5-10: Trace Session activation procedure in ePC :.................................................................. 105
Figure 5-11 Overload start/stop message to ENB .............................................................................. 109
Figure 5-12 Throttling of DDN storm ................................................................................................... 111
Figure 6-1 3GPP view of the Local Breakout ...................................................................................... 137
Figure 6-2: Illustration of MME Pools and Tracking Areas .................................................................. 160
Figure 6-3 SAM5620 Inter-WMM UE Load Balancing configuration ................................................... 178
Figure 6-4: GWCN Architecture .......................................................................................................... 218
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
14 / 652
Figure 6-5: MOCN Architecture ........................................................................................................... 218
Figure 6-6: GWCN Variant Architecture .............................................................................................. 220
Figure 7-1: SNMPv3 ............................................................................................................................ 229
Figure 8-1: MME and SGW Pooling .................................................................................................... 241
Figure 8-2 Call Flow showing handling of SR for a UE without a PDN connection and UE subsequently
requesting a PDN Connection ...................................................................................................... 253
Figure 8-3: PGW Functionality ............................................................................................................ 255
Figure 8-4 Handling of IPV4 and IPV6 PDN....................................................................................... 268
Figure 8-5: Example of UE Context Data ............................................................................................ 286
Figure 8-6 : Previous MME DPR handling in LM4.0.2 ....................................................................... 290
Figure 8-7: MME Handling of HSS originated DPR ............................................................................ 291
Figure 8-8: MME Originating DPR to HSS .......................................................................................... 292
Figure 8-9: HSS-based P-CSCF restoration ....................................................................................... 299
Figure 8-10 SGW and PGW pair isolation and topological selection ................................................ 312
Figure 8-11 MME TAI Provisioned Status ......................................................................................... 314
Figure 8-12: EPS LCS Network Architecture ...................................................................................... 348
Figure 8-13: Mobile Terminating Location Request (MT-LR) Procedure ............................................ 364
Figure 8-14: Network Induced Location Request (NI-LR) Procedure ................................................. 367
Figure 8-15 : Mobile Originated Location Request (MO-LR procedure .............................................. 368
Figure 8-16: Warning Message Delivery Network Architecture .......................................................... 373
Figure 8-17: Warning Message Delivery ............................................................................................. 375
Figure 8-18: Warning Message Cancellation ...................................................................................... 376
Figure 8-19 PWS Restart indication .................................................................................................... 379
Figure 8-20: MBMS/eMBMS Network Architecture ............................................................................. 381
Figure 8-21: MBMS/eMBMS Session Start ......................................................................................... 382
Figure 8-22: eUTRAN architecture with deployed HeNB gateway ..................................................... 388
Figure 8-23 X2 HO between HeNBs and enodeB ............................................................................... 394
Figure 8-24: LIPA Architecture. ........................................................................................................... 397
Figure 8-25: Procedure Dual Receiver UE Suspend when Performing LTE to 1xRTT Cell Reselection
...................................................................................................................................................... 401
Figure 8-26: AKA Procedure ............................................................................................................... 404
Figure 8-27: Identification Procedure .................................................................................................. 409
Figure 8-28: Security Mode Command Procedure .............................................................................. 410
Figure 8-29: Call flow - Initial Attach .................................................................................................... 412
Figure 8-30: Call flow - Combined Attach with GUTI (steps 16 - 22) .................................................. 414
Figure 8-31: Procedure Dual Receiver UE Suspend when Performing LTE to 1xRTT Cell
Reselection ................................................................................................................................... 429
Figure 8-32: Procedure Dual Receiver UE Resume when Performing 1xRTT to LTE Cell Reselection
...................................................................................................................................................... 431
Figure 8-33: Procedure - Circuit Switched MO/MT Call with LTE Suspension DTR Handset CONNECTED ............................................................................................................................... 432
Figure 8-34: Procedure - Circuit Switched MO/MT Call with LTE Suspension DTR Handset - IDLE
...................................................................................................................................................... 434
Figure 8-35: Procedure - Circuit Switched MO/MT Call with LTE Suspension DTR Handset Error CONNECTED ............................................................................................................................... 436
Figure 8-36: Procedure Resume Procedure Returning from 3G1x Call DTR Handset ................ 437
Figure 8-37: enhanced restoratioin procedure for Extended Service Request (ESR) ........................ 442
Figure 8-38: Call flow - UE-initiated Detach ........................................................................................ 444
Figure 8-39: Call-flow - Tracking Area Update without bearer change ............................................... 453
Figure 8-40: Call flow - Tracking Area Update with bearer change .................................................... 453
Figure 8-41: Call flow - Tracking Area Update with SGW Change and MME Change ....................... 453
Figure 8-42: Call flow eUTRAN Tracking Area Update without SGW Change ................................ 454
Figure 8-43: Call flow - Tracking Area Update with enhanced restoration procedure ........................ 455
Figure 8-44: Call flow Gn-based Tracking Area Update .................................................................. 457
Figure 8-45: Call flow S3-based Tracking Area Update with SGW Change .................................... 459
Figure 8-46: Call flow S3-based Tracking Area Update without SGW Change ............................... 460
Figure 8-47 :Enhanced Restoration Procedure impact on TAU request. ........................................... 461
Figure 8-48 Procedure of TAU request with EPS Update IE .............................................................. 462
Figure 8-49 Idle Mode TAU with MME Change and SGW Change .................................................... 471
Figure 8-50: UE Triggered Service request Procedure ....................................................................... 474
Figure 8-51: Paging Message Flow ..................................................................................................... 478
Figure 8-52: Procedure - Paging ......................................................................................................... 479
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
15 / 652
Figure 8-53: Paging attempts to eNodeBs .......................................................................................... 480
Figure 8-54 Network-initiated Paging .................................................................................................. 487
Figure 8-55 Handling of SGs Paging Request after MME failure or Restart....................................... 488
Figure 8-56: Paging Policy .................................................................................................................. 490
Figure 8-57: Inter-eNodeB X2-based handover .................................................................................. 497
Figure 8-58: Call flow - Inter-eNodeB X2-based Handover without SGW Relocation ........................ 498
Figure 8-59: Call flow Configuration Transfer for Automatic Neighbor Relation (single MME) ........ 499
Figure 8-60: Call flow Configuration Transfer for Automatic Neighbor Relation (MME Pools) ........... 501
Figure 8-61: Call flow E-UTRAN to UTRAN Inter-RAT Handover with SGW Relocation and RAU. 505
Figure 8-62: Call flow E-UTRAN to UTRAN Inter-RAT Handover with SGW Relocation ................ 506
Figure 8-63: Call flow E-UTRAN to UTRAN Inter-RAT Handover without SGW Relocation ........... 507
Figure 8-64: Call flow UTRAN Iu Mode to E-UTRAN Inter-RAT Handover, Preparation Phase ..... 508
Figure 8-65: Call flow UTRAN Iu Mode to E-UTRAN Inter-RAT Handover, Execution Phase ........ 509
Figure 8-66: Call flow UTRAN to E-UTRAN Hard Handover with SRNS relocation and TAU ......... 510
Figure 8-67: Call flow E-UTRAN to GERAN Inter-RAT Handover, Preparation Phase ................... 511
Figure 8-68: Call flow E-UTRAN to GERAN Inter-RAT Handover, Execution Phase ...................... 513
Figure 8-69: Call flow GERAN to E-UTRAN Inter-RAT Handover, Preparation Phase ................... 515
Figure 8-70: Call flow GERAN to E-UTRAN Inter-RAT Handover, Execution Phase ...................... 517
Figure 8-71: Call flow - S1-based Handover without MME and SGW Relocation with Direct Forwarding
...................................................................................................................................................... 528
Figure 8-72: Call flow - S1-based Handover without MME and SGW Relocation with Indirect
Forwarding ................................................................................................................................... 529
Figure 8-73: Call flow - S1-based Handover without MME and with SGW Relocation with Indirect
Forwarding ................................................................................................................................... 530
Figure 8-74: Call flow - S1-based Handover with MME and SGW Relocation with Indirect Forwarding
...................................................................................................................................................... 531
Figure 8-75: Call flow RAU Procedure with MME Interaction and with SGW Change (Gn) ............ 540
Figure 8-76: Call flow RAU Procedure with MME Interaction and without SGW Change (S3) ........ 541
Figure 8-77: Call flow RAU Procedure with MME Interaction and with SGW Change (S3) ............. 542
Figure 8-78: Call flow E-RAB Setup Procedure ............................................................................... 543
Figure 8-79: Call flow Initial Context Setup Procedure .................................................................... 545
Figure 8-80: Call flow UE Context Release Request Procedure (eNodeB-Initiated) ....................... 546
Figure 8-81: Call flow UE Context Release Request Procedure (MME-Initiated) ............................ 548
Figure 8-82: Call flow UE Context Modification Procedure (Successful) ......................................... 549
Figure 8-83: Call flow UE Context Modification Procedure (Unsuccessful) ..................................... 549
Figure 8-84 UE enhanced restoration procedure for the network-initiated service requests. ............. 552
Figure 8-85 Restoration Service Request procedure .......................................................................... 554
Figure 8-86 restoration Extended Service Request (ESR) procedure ................................................ 555
Figure 8-87: Validate IMEI over S13 ................................................................................................... 558
Figure 8-88: SGW Restoration algorithm ............................................................................................ 594
Figure 8-89: PGW failure / PGW Restart ............................................................................................ 598
Figure 8-90: ePS Bearer Components for GTP-based S5/S8 ............................................................ 604
Figure 8-91: ePS Bearer UE Connected to Multiple PDNs for a GTP-based S5/S8 ....................... 605
Figure 8-92: ePS Bearer UE Connected to a Single PDN for a GTP-based S5/S8 ........................ 605
Figure 8-93: Basic Default and Dedicated ePS Bearers for QoS........................................................ 607
Figure 8-94 reference architecture SRVCC ........................................................................................ 624
Figure 8-95 : LTE VoIP-to-1x CS voice service continuity .................................................................. 626
Figure 9-1: MI-Agent Screen Layout ................................................................................................... 640
Figure 9-2: MI-Agent Web Network Maps ........................................................................................... 640
Figure 9-3: MI-Agent Web Shelf View ................................................................................................. 641
Figure 9-4: MI-Agent Card-host View .................................................................................................. 641
Figure 9-5: MI-Agent Service Members Menu .................................................................................... 642
Figure 9-6: MI-Agent Fault Management ............................................................................................ 642
Figure 9-7: MI-Agent IP Addresses ..................................................................................................... 643
Figure 9-8: MI-Agent Configuration Management ............................................................................... 643
Figure 9-9: MI-Agent Performance Management ................................................................................ 644
Figure 9-10: MI-Agent Security Management ..................................................................................... 644
Figure 9-11: MI-Agent Tools Tree ....................................................................................................... 645
Figure 9-12: MI-Agent Tools Menu...................................................................................................... 645
Figure 9-13: MI-Agent Help Menu ....................................................................................................... 646
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
16 / 652
1 INTRODUCTION
1.1 Objective
The Wireless Mobility Manager (WMM) LTE Parameters User Guide (WMM-LPUG)
document provides parameter setting recommendations for the Nokia 9471 WMM.
The recommendations are the result of Nokias systems engineering expertise, and lab
and field experience.
The parameters described in this document are mainly customer configuration
parameters accessible by the customer (operator) via the 5620 Service Aware Manager
(5620 SAM) or local MME maintenance interface. Nevertheless, some manufacturer
configuration parameters as well as some static parameters are also covered when they
are required to understand the different LTE mechanisms.
In the case when the recommended values of the LPUG are different from any other
document, the LPUG recommended value should prevail.
A common and single 9471 WMM load is delivered to address the needs of all Nokia
LTE customers in LR16.1.L.
1.2 Scope of this Volume

This volume describes the LTE system with special emphasis on the configuration
parameters that are associated with the MME application running on the 9471 WMM
WM10.0.0.The Nokia 9471 WMM ATCA platforms and Virtualized Mobility Manager
(VMM) are covered in this document. In general, the WM10.0.0 release of 9471 WMM
is delivered with LTE LR16.1.L.
The parameter values provided in this document are primarily based on systems
engineering expertise and, whenever possible, ALU lab test results and field
experience.
Engineering Recommendation: Parameter Values
Parameter values provided in this version of the WMM LPUG document reflect the
best information available at the time of publication.
If a newer software delivery is used, then the related Release Notes should be
consulted for newer parameter values.
1.3 Audience for this Document

This document targets an audience involved in the following activities:
Issue 11.01
R&D engineering
WMM Datafill
Operational teams (Trials, FOA, Services, QACC)
LTE/DCL/APP/031094
Nokia 2016
17 / 652
1.4 LPUG Terminology
This document describes the static and dynamic parameters that are associated with
the 9471 WMM and how the parameters affect other WMM or LTE system parameters.
Most parameter recommendations are based on systems engineering expertise, and
are listed as the default value on the configuration interface. Wherever possible, lab and
field experience and an engineering point of view are used to give a rationale for the
recommended parameter setting.
Also note that WM10.0.0 is delivered as a system. Therefore, the idea of feature
interactions does not apply. All interactions between internal development features are
accounted for in the parameter description.
This document does not cover read-only parameters. Such parameters are used to
provide system information like state and status. These parameters are not
configurable. Each parameter is described using a table as shown below:
Parameter
The Name of the parameter is provided here
SAM Table Name
The provisioning screen in the SAM Provisioning GUI used to

update the parameter.
OSS ID
The parameter is listed in <package.class.property> format in

OSS calls.
Range & Unit
The minimum and maximum values of the parameter or the

choice list for parameter values, and the unit of measurement.
Impact of Change
Most parameters can be updated with no service impact. Some

parameters require a server to be in a locked state prior to
update. There are no known cases where a parameter update
requires a full reboot.
Value
The default or recommended value of the parameter.
Datafill rules are presented as follows:

Rule:
System restrictions are presented as follows:

Restriction:
Engineering recommendations for parameter values are presented as follows:

Engineering Recommendation:
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
18 / 652
2 RELATED DOCUMENTS AND

PREREQUISITES
2.1 Prerequisite for Reading this Volume
The WMM volume is written as a stand-alone volume, so there are no prerequisites for
reading this volume. However, if the reader has already read the introduction chapter
(Volume 1) of the eNB LPUG [R30] then some of the introductory information in this
volume will be familiar.
2.2 Reference Documents

[R01] 3GPP TS 23.018, Basic Call Handling
[R02] 3GPP TS 23.060, GPRS Service Description
[R03] 3GPP TS 23.107, Quality of Service (QoS) Concept and Architecture
[R04] 3GPP TS 23.272, Circuit Switched (CS) Fallback in Evolved Packet System
(EPS)
[R05] 3GPP TS 23.303, Policy Charging Control Architecture
[R06] 3GPP TS 23.401, GPRS Enhancements for E-UTRAN Access
[R07] 3GPP TS 24.008, Mobile Radio Interface Layer 3 Specification; Core Network
Protocols
[R08] 3GPP TS 24.301, NAS Protocol for Evolved Packet System (EPS)
[R09] 3GPP TS 25.304, User Equipment (UE) Procedures in Idle Mode and
Procedures for Cell Reselection in Connected Mode
[R10] 3GPP TS 25.413, UTRAN Iu Interface Radio Access Network Application Part
(RANAP) Signaling
[R11] 3GPP TS 29.060, GPRS Tunneling Protocol Across the Gn and Gp Interface
[R12] 3GPP TS 29.118, Mobility Management Entity (MME) Visitor Location Register
(VLR) SGs Interface Specification
[R13] 3GPP TS 29.272, Mobility Management Entity (MME) and Serving GPRS
Support Node (SGSN) Related Interfaces Based on Diameter Protocol
[R14] 3GPP TS 29.274, Evolved General Packet Radio Service (GPRS) Tunnelling
Protocol for Control Plane (GTPv2-C)
[R15] 3GPP TS 29.303, Domain Name System Procedures
[R16] 3GPP TS 33.107, Lawful Interception Architecture and Functions
[R17] 3GPP TS 33.401, 3GPP System Architecture Evolution (SAE), Security
Architecture
[R18] 3GPP TS 36.300, Evolved Universal Terrestrial Radio Access (E-UTRA) and
Evolved Universal Terrestrial Radio Access Network (E-UTRAN) Overall
description
[R19] 3GPP TS 36.413, S1 Application Protocol (S1AP)
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
19 / 652
[R20] 3GPP TS 22.368 Service requirements for Machine-Type Communications
(MTC) Stage 1
[R21] RFC 768, User Datagram Protocol (UDP)
[R22] RFC 2960, Stream Control Transmission Protocol
[R23] RFC 3309, Stream Control Transmission Protocol (SCTP) Checksum Change
[R24] RFC 3403, Dynamic Delegation Discovery System (DDDS) Part Three: The
Domain Name System (DNS) Database
[R25] RFC 3503, Message Disposition Notification (MDN) Profile for Internet Message
Access Protocol (IMAP)
[R26] RFC 6733, Diameter Base Protocol
[R27] RFC 3958, Domain-Based Application Service Location Using SRV RRs and the
Dynamic Delegation Discovery Service (DDDS)
[R28] RFC 4960, Stream Control Transmission Protocol (Obsoletes RFC 2960)
[R29] LTE/IRC/APP/028585: Transport Engineering Guide For LR14.3
[R30] 9471 WMM CALEA/LI Management, 9YZ-06421-0012-REZZA
[R31] FDD eNodeB LTE Parameters User Guide LR15.1 LTE/DCL/APP/046710
[R32] Alcatel-Lucent 5620 Service Aware Manager Release 14.0 Wireless Parameter
Reference, 3HE-10713-AAAA-TQZZA Issue 0.1 March 2016
[R33] Alcatel-Lucent 5620 Service Aware Manager Release 14.0 R1 LTE ePC User
Guide, 3HE-10691-AAAA-TQZZA March 2016
[R34] 9471 WMM Release Note WM10.0.0
March 2016
9YZ-06832-0016-FMZZA
Issue 0.10
[R35] 9471 WMM Technical Description, Release WM10.00, 9YZ-06613-0001-DEZZA

Issue 0.07 March 2016
[R36] 9471 WMM ATCA Operations, Administration and Maintenance, 9YZ-068320002-REZZA
[R37] 9471 WMM Guest In-Service Software Upgrade, 9YZ-06832-0004-RJZZA
[R38] 9471 WMM Alarm Dictionary, 9YZ-06832-0005-RKZZA
[R39] 9471 WMM HP c7000 Host Software Upgrade, 9YZ-06832-0022-RJZZA
[R40] 9471 WMM HP c7000 Software Installation and Integration, 9YZ-06832-0025RJZZA
[R41] 9471 WMM Command Line Interface Reference Guide, 9YZ-06832-0013-RKZZA
[R42] 9471 Wirelease Mobility Manager Product Engineering Guide for MME
Application LTE/DCL/APP/046628
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
20 / 652
3 LTE OVERVIEW
3.1 Motivation for LTE
Some of the motivations for LTE include the following:
Reduced delays, in terms of both connection establishment and transmission

latency,
Increased user data rates,
Increased cell-edge bit-rate, for uniformity of service provision,
Reduced cost per bit, implying the need for improved spectral efficiency,
Greater flexibility of spectrum usage, in both new and pre-existing bands,
Simplified network architecture,
Seamless mobility, including between different radio-access technologies,
Reasonable power consumption for the mobile terminal.
Figure 3-1: Summary of Motivations for LTE

LTE employs some new technologies to help attain the goals listed above. These
technologies include:
Multicarrier technologies (OFDMA for downlink and SC-FDMA for uplink),
Multiple antenna technology (increases diversity gain, array gain and spatial
multiplexing gain).
Issue 11.01
Packet-switched radio interface and evolved pack core.
LTE/DCL/APP/031094
Nokia 2016
21 / 652
3.2 LTE Architecture Overview
An LTE network is a packet switched system, where the E-UTRAN is limited to a set of
interconnected nodes (E-NodeB, or eNB). The eNB handles all radio access and control
functions. In it simplest form, the Evolved Packet System (ePS) architecture consists of
2 nodes in the Evolved Packet Core (ePC) network: Mobility Management Entity (MME)
and SGW/PGW; and a single node in the RAN called the enhanced Node-B (eNB).
Refer to Figure 3-2
SGW /
PGW
Figure 3-2: Summary of Motivations for LTE

In the core network (ePC), the UMTS equivalent SGSN has been split into MME
(Mobility Management Entity), which handles control functions, and Serving GW (SGW),
which handles U-plane traffic. There is one anchor SGW per UE. (Note: MME and SGW
may be collocated.)
The UMTS GGSN equivalent is PDN GW (PGW), which may or may not be collocated
with SGW. The PGW is the inter-system anchor point for each UE. It provides access to
PDNs. Refer to Figure 3-3: LTE Network Architecture
Figure 3-3 : LTE Network Architecture
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
22 / 652
The ePS contains the eUTRAN and the ePC. The eUTRAN contains only one type of
node (eNB) with four logical interfaces. S1-U is the S1 U-plane interface that carries
user traffic between eNB and SGW. S1-MME is the S1 C-plane interface that carries
control traffic between eNB and MME. There are two X2 interfaces, X2-C and X2-U. X2C is the X2 C-plane interface that carries control traffic between eNBs (for mobility, such
as for inter-eNB handover.) X2-U is the X2 U-plane interface that is used for data
forwarding between source and target eNB to support lossless handover. All S1 and X2
interfaces share the same IP-based carrier transport network.
The air interface between the eNB and UE is called LTE-Uu. It is OFDMA-based with
shared channels to carry user traffic. Refer to
Figure 3-3: EUTRAN Topology.
eUTRAN
EPC
LTE-Uu
MME
S1-MME
eNB
UE
S1U
S1-MME
S1-MME
X2C
X2U
X2C
X2U
LTE-Uu
S1U
X2C
X2U
eNB
eNB
AP
AP
UE
AP
Serving
SAE
Gateway
S1U
AP
IP Transport Network (IP Cloud)
AP
X2C - X2 Cplane
X2U - X2 Uplane
AP - Access Point (for IP cloud)
S1U - S1 Uplane
S1-MME - S1 Cplane
Figure 3-4: EUTRAN Topology

A key feature of the ePS architecture is the clean separation in the core network of
control plane (MME) and the user plane (SGW/PGW), allowing for independent scaling
of these two planes.
Capacity of user plane depends on aggregate data throughput required.
Control plane functionality depends on number of mobiles and their mobility patterns.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
23 / 652
3.3 EUTRAN C-Plane Protocol Stack Overview
3.3.1 E-UTRAN & EPC FUNCTIONAL SPLIT
The split between radio protocols and S1 protocols is shown in Figure 3-4: S1 and Uu
interfaces (signaling control plane).
EMM,ESM(3)
Radio
protocols
(1)
Radio
protocols
(1)
1.
2.
3.
S1
proto
cols
(2)
Access Stratum
EUTRAN
Radio
(Uu)
UE
EMM,ESM(3)
Non-Access Stratum
S1
proto
cols
(2)
S1
EPC
The radio interface protocols are defined in documents TS 36.2xx and

TS 36.3xx.
The protocol is defined in documents TS 36.41x. (Description of S1
interface).
EMM, ESM: This exemplifies a set of NAS control protocols between
UE and ePC. The evolution of the protocol architecture for these
protocols is outside the scope of the present document.
Figure 3-5: S1 and Uu interfaces (signaling control plane)

NOTE: Both the radio protocols and the S1 protocols contain mechanisms to
transparently transfer NAS messages, including:
- Transfer of user data
- Radio channel ciphering and deciphering
- Integrity protection
- Header compression
- Mobility control functions
- Handover
- Paging
- Positioning
- Inter-cell interference coordination
- Connection setup and release
- Load Balancing
- Distribution function for NAS messages
- NAS node selection function
- Synchronization
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
24 / 652
- Radio access network sharing
- MBMS function
- Subscriber and equipment trace
- RAN Information Management
The split between the functions performed by the eNB and the functions performed by
the ePC is shown in Figure 3-5: Functional Split between E-UTRAN and EPC. Figure
3-6 describes the node functions in more detail.
eNB
Inter Cell RRM
RB Control
Connection Mobility Cont.
MME
Radio Admission Control
NAS Security
eNB Measurement
Configuration & Provision
Idle State Mobility
Handling
Dynamic Resource
Allocation (Scheduler)
EPS Bearer Control

RRC
PDCP
S-GW
P-GW
RLC
Mobility
Anchoring
MAC
UE IP address
allocation
S1
PHY
Packet Filtering
internet
E-UTRAN
EPC
Figure 3-6: Functional Split between E-UTRAN and EPC
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
25 / 652
Mobility Management Entity
Authentication
Tracking area list management
eNB- contains all radio access functions

Radio admission control
Scheduling of UL and DL data
Scheduling and transmission of
paging and system broadcast
Idle mode UE reachability

S-GW/PDN-GW selection
Inter core network node signaling for
mobility between 2G/3G and LTE
IP header compression (PDCP)

Outer-ARQ (RLC)
Bearer management functions
eNB
MME
Inter Cell RRM

RB Control
Policy & Charging Rules Function

Network control of Service Data Flow (SDF)
detection, gating, QoS & flow based
charging
Dynamic policy decision on service data flow
treatment in the PCEF (xGW)
NAS Security
PCRF
Connection Mobility Cont .
Idle State Mobility

Handling
Radio Admission Control
Policy
eNB Measurement
Configuration & Provision
Policy
Decisions
EPS Bearer Control

Dynamic Resource
Allocation ( Scheduler )
Authorizes QoS resources
RRC
S- GW
P-GW
PDCP
Mobility
Anchoring
RLC
PDN Gateway
UE IP address
allocation
S1
MAC
Packet Filtering
PHY
internet
E -UTRAN
EPC
Serving Gateway
IP anchor point for bearers

UE IP address allocation
Per -user based packet filtering
Connectivity to packet data network
Local mobility anchor for inter -eNB

handovers
Idle mode DL packet buffering
Lawful interception
Packet routing and forwarding
Figure 3-7: Description of Node Functions
3.3.1.1
eNB Functions
The eNB hosts the following functions:
Functions for Radio Resource Management: Radio Bearer Control, Radio

Admission Control, Connection Mobility Control, Dynamic allocation of resources
to UEs in both uplink and downlink (scheduling);
IP header compression and encryption of user data stream;
Selection of an MME at UE attachment when no routing to an MME can be

determined from the information provided by the UE;
Routing of User Plane data towards Serving Gateway;
Scheduling and transmission of paging messages (originated from the MME);
Scheduling and transmission of broadcast information (originated from the MME

or O&M);
Measurement and measurement reporting configuration for mobility and

scheduling.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
26 / 652
3.3.1.2
MME Functions
The MME hosts the following functions (see 3GPP TS 23.401):
Authenticates and authorizes a UE at the time of initial attachment and

subsequent attachments
Terminates Non-Access Stratum (NAS) from the UE
Supports NAS message integrity and ciphering
Assigns temporary identities (GUTI) to UEs
Selects SGW at the time of initial attachment and during relocation
Selects PGW based on subscriber profile or provisioned data
Performs idle-mode paging
Manages tracking-area lists
Performs bearer management functions such as activation and deactivation of

bearer when requested by UE or the network.
Provides lawful intercept support for CALEA (see [R29] for details).
Selects SGW for intra-LTE handover
Supports intra-LTE handover
Supports inter-Radio Access Technology (RAT) handovers
Supports MME and SGW pooling
Supports Call trace
Supports IMS Emergency Services to allow service providers to meet regulatory

obligations for Emergency Services support.
Supports Location Based Services to assist subscribers who place emergency

calls.
Supports Warning Message Delivery to UEs in a particular area.
Supports Multimedia Broadcast/Multicast Service, a broadcast service in which

data is transmitted from a single source entity to multiple recipients.
Supports network sharing
Supports connected mode mobility for reserved cells
Supports cell redirection (such as from LTE to 1xRTT)
Supports directly connected HeNBs
Supports HeNBs connected through HeNB GW
Supports Local IP Access (LIPA)
Enhanced Restoration procedures.
Enhanced SGW Restoration Procedure
Supports provisioning using the 9471 WMM CLI
A detailed description of the MME functions and interfaces supported in WM10.0.0 can
be found in [R34].
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
27 / 652
3.3.1.3
S-GW Functions
The Serving Gateway (S-GW) hosts the following functions (see 3GPP TS 23.401):
The local Mobility Anchor point for inter-eNB handover;
Mobility anchoring for inter-3GPP mobility;
E-UTRAN idle mode downlink packet buffering and initiation of network triggered
service request procedure;
Lawful Interception;
Packet routing and forwarding;
Transport level packet marking in the uplink and the downlink;
Accounting on user and QCI granularity for inter-operator charging;
UL and DL charging per UE, PDN, and QCI.
3.3.1.4
P-GW Functions
The PDN Gateway (P-GW) hosts the following functions (see 3GPP TS 23.401):
Per-user based packet filtering (by e.g. deep packet inspection);
Lawful Interception;
UE IP address allocation;
Transport level packet marking in the downlink;
UL and DL service level charging, gating and rate enforcement;
DL rate enforcement based on AMBR.
3.3.1.5
SRS functions
The Session Restoration Server (SRS) is a standalone system that is used to maintain
a backup copy of UE context data from client MMEs. In the event that an MME in a pool
becomes isolated, the remaining MMEs in the pool can retrieve UE context data to
complete procedures that were previously managed by the unavailable MME, without
requiring UEs to reattach.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
28 / 652
4 MME INTERFACES
The WMM supports both 2G/3G (SGSN) and LTE (MME) functionality but LPUG
described parameters applicable for the MME application.
The following network interfaces are supported:
Issue 11.01
RS10: proprietary link between the MME and the WMM session restoration
server (SRS). The SRS is a standalone system. In the event that an MME in a
pool becomes isolated, the remaining MMEs in the pool can consult the SRS to
retrieve UE context data to complete procedures that were previously managed
by the unavailable MME, without requiring UEs to reattach.
S1-MME: link between the MME and the eNodeB that carries both the S1-AP
(Application Part) and Non-Access Stratum (NAS) signalling to/from the UE.
S3: link between the MME and the release 8 SGSN (S4-SGSN) that allows the
MME to support handovers between a 3GPP UMTS or GERAN network and an
LTE network. Eventually, S3 will replace Gn in the architecture. Both S3 and Gn
are supported.
S4: interface between the SGSN and the SGW (similar to the S11 interface
between the MME and the SGW). In combo MME-SGSN configuration, the
SGSN S4 interface and the corresponding MME S11 interface can be
configured to share the same local IP address or to have separate local IP
addresses.
S6a: link between the MME and the subscriber profile database (HSS) that
allows transfer of subscription and authentication data.
S6d: interface between the SGSN and the HSS In the S4SGSN network.
S10: a GTP tunnel connecting MMEs in the same or different MME pools. The
tunnel enables MME relocation and MME-to-MME information transfer.
S11: link between the MME and the SGW that supports session creation and
deletion procedures, including selection of SGW and PGW for a UE at the time
of initial attachment.
S13: link between the MME and the Equipment Identity Register (EIR) that
enables the UE Identity Check Procedure between the MME and the EIR.
SBc: link between the MME and the Cell Broadcast Center (CBC) that is used
to transport messages associated with the Warning Message Delivery function
(CMAS).
SDS- SGS Lite : link between the MME and the Gateway to Thing Space
(GWTS) server. The interface provides support for SDS UE Bearer Less (UEs
that are subscribed to connect to the network without any bearers)
SGs: link between the MME and the MSC/VLR that supports coordinating the
location of UEs that are IMSI attached to both EPS and non-EPS services and
supports relaying certain messages related to GSM circuit-switched services
over the EPS system via MME. The SGs link supports CSFB.
SLg: link between the MME and the Gateway Mobile Location Center (GMLC).
The interface supports transporting positioning requests and responses for
Emergency Location Services (LCS). The MME acts as a client to the GMLC.
LTE/DCL/APP/031094
Nokia 2016
29 / 652
SLs: link between the MME and the EPC-Serving Mobile Location Center (ESMLC). This interface is used in support of Emergency Location Services (LCS)
to obtain a UEs position.
Sm: link between the MME and the Multimedia Broadcast/Multicast Service
(MBMS) Gateway that transports Sm-AP messages to support signaling
functions for MBMS sessions.
Sv: link between the MME and the MSC server that supports UMTS hand down
of IMS-anchored voice sessions to the CS domain in the UTRAN/GERAN. The
MME provides SRVCC (Single Radio Voice Call Continuity) from the E-UTRAN
to the UTRAN/GERAN.
M3: link between MME and the Multicast Control Entity (MCE) in the eNB
nodes that transports M3-AP messages to support signaling functions for
session management, reset functionality and error indication functionality.
Gn-c: common link between the MME/SGSN and the pre-release 8 SGSN (GnGp SGSN) that allows the MME to support handovers between a 3GPP UMTS
or GERAN network and an LTE network. The Gn interface is the reference
point between SGSN and MME when S3 interface is not supported.
Gn-u: link between the 2G/3G SGSN and the GGSN.
Iu-PS: link between the 2G/3G SGSN and the RNC.
Gb: link between the 2G/3G SGSN and the BSC.
Gr: link between the 2G/3G SGSN and the HLR.
Gf: link between the 2G/3G SGSN and the EIR.
Ge: link between the 2G/3G SGSN and the SCP for CAMEL.
Gd: link between the 2G/3G SGSN and the SMS GW.
Gs: link between the 2G/3G SGSN and the MSC.
Ga: link between the 2G/3G SGSN and the CGF.
CALEA interfaces
North Bound Interface (NBI): link between the MME and the 5620 SAM. The
NBI supports NETCONF, SSH, SNMPv3 and HTTPS.
- X1_1: common link between the MME/SGSN and the Administrative Function
(ADMF) in the LIG.
- X2: link between the MME and the DF2 in the LIG, and link between the
SGSN and the DF2 in the LIG. Different X2 encoding requires 2 physical
links to the LIG. (Note: this is not the X2 interface between eNBs.)
- X3: link between the SGSN and the DF3 in the LIG.
Please refer to Figure 4-2: Position of 9471 WMM in LTE SAE
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
30 / 652
5620
SAM
LIG
(DF2)
LIG
(ADMF)
1xCS
IWS
S102
MCE
X1_1
NETCONF,
SNMPv3,
SSH,
HTTPS
Ge
Gd
HLR
Gr
CGF
EIR
Ga
Gf
S13
Sv
S6a
SGs
Gs
eNB
LIG
(DF3)
X3
MSC
SMS GW
CAMEL
X2
S6d
Gn-u
S1-MME
MME-SGSN Combo
M3
RNC
Iu-PS
BSC
Gb
S11
S4
SLs
HSS
GGSN
SGW
E-SMLC
SLg
RS10
SRS
Legend:
MME specific
S16
S3
S4-SGSN
S3 S10
MME
Sm
MBMS GW
Gn-c
Gn-Gp
SGSN
SBc
GMLC
CBC
(CMAS)
SGSN specific
Shared
Figure 4-1: Position of 9471 WMM in LTE SAE

Network elements communicate by sending messages to each other (note however that
not all initiating messages result in a success/failure response message).
These messages contain information elements (IEs) that provide the necessary data for
the receiving network element to act upon.
The WMM interfaces and functionality conform to 3GPP Standards as shown in Table
1. The table lists the supported versions of the 3GPP Technical Specifications (TS), and
if applicable, notes any additional TS CRs supported Figure 4-3, on page Error!
Bookmark not defined.Error! Bookmark not defined. shows the interfaces/functions
supported by the MME.

Figure 4-2: MME Interfaces/Functions
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
31 / 652
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
32 / 652
WMM Interface /
Function
3GPP TS
Document
Version(s)
Supported
Ga
32.251
10.7.0
32.298
10.7.0
32.295
10.7.0
44.060
10.1.0
44.065
10.0.0
44.014
10.0.0
44.016
10.0.0
44.018
10.4.0
23.278
10.1.0
Release 7 March 09, 29.078
29.078
10.0.0
Release 7 June 2010,
Gf
29.002
10.5.0
Release 12, September 2014+ selected CRs
Gn
29.060
10.4.0
Gr
29.002
10.5.0
25.410
10.2.0
25.411
10.1.0
25.412
10.1.0
25.415
10.1.0
Gb
Comments
Release 7, December 2010 + selected CRs
Release 7, December 2011 plus selected CRs
Ge
Release 7
Iu-ps
Release 8, March 2012, June 2012,

25.413
10.4.0
September 2012, and December 2012

+ selected CRs
MME Assisted
23.401
11.4.0
24.301
10.5.0
29.274
10.5.0
36.413
9.6.0
S1-based
eNodeB
Release 10, March 2012, June 2012,
Handoff
33.401
9.6.0
September 2012, and December 2012

+ selected CRs
23.401
11.4.0
24.301
10.5.0
29.274
10.5.0
NAS
RS10
Issue 11.01
Release 10, September 2011 and December 2011

plus selected CRs
LTE/DCL/APP/031094
Nokia 2016
33 / 652
WMM Interface /
Function
3GPP TS
Document
Version(s)
Supported
Comments
MME can detect the version of the S1-MME protocol
S1-MME
36.413
11.2.0
used on a S1 link automatically.

Once the protocol version is detected for a S1 link,
MME interprets all the S1-MME messages using that
version.
S3
29.274
11.5.0
S4
29.274
11.5.0
S10
29.274
11.5.0

Release 11 December 2012
S102
29.277
10.0.0
3GPP2 A.S00009 Cv4.0 v4.0

3GPP2 A.S00008 Cv4.0 v4.0
S11
29.274
11.5.0
S13
29.272
10.5.0
S16
29.274
11.5.0
S6a
29.272
10.5.0
S6d
29.272
10.5.0
29.118
11.5.0
23.272
11.3.0
SLs
29.171
11.3.0
SLg
29.172
11.4.0
SBc
29.168
11.4.0
Release 11, December 2012
M3
36.444
11.4.0
Sm
36.444
11.4.0
Sv
29.280
10.0.0
not
not
applicable
applicable
SGs
X2 (IRI)
X1_1
X3 (CC)
These interfaces follow the basic principles detailed

in TS 33.107 (version 8.8.0, Jun.09), however the
X1 and X2 interfaces are proprietary interfaces.
Table 1: 3GPP Standards
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
34 / 652
4.1 RS10
The RS10 interface is the Nokia proprietary interface between the MME and the WMM
session restoration server (SRS). The RS10 protocol specification is based on GTPv2
(3GPP TS 29.274), with proprietary messages and proprietary GTPv2 IE definitions.
RS10 interfaces carry RS10 messages between the MME client and SRS.
WM10.0.0 release provides call tracing on the RS10 interface. (Default = activate)
SRS
RAF
Restoration
Application
Function
Pool X
MIF
oRTM
RS10
MME
1
RS10
MME
2
Up to 8
MMEs
Pool X
Figure 4-3: SRS - MME Interfaces
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
35 / 652
4.2 S1-MME
S1-MME supports the control plane between the eNB and the MME. The link carries
both the S1-AP (Application Part) and Non-Access Stratum (NAS) signaling. The eNB
uses the S1 interface to send/receive NAS messages to/from the UE. The associated
protocol stack is shown in Figure 4-4 below.
Figure 4-4: S1-MME Protocol Stack

S1-AP is the application layer protocol between the eNB and the MME. S1-AP
procedures are defined in 3GPP TS 36.413. 9471 WMM supports all the major
functions of the S1 application protocol, such as Paging, Handover, and E-RAB. The
Information Elements (IEs) that make up the S1-AP messages sent between the MME
and eNB may contain S1-AP cause codes/values as defined in 3GPP TS 36.413, EMM
cause codes/value as defined in 3GPP TS 24.301, and/or ESM cause codes/value as
defined in 3GPP TS 24.301.
SCTP is the control plane protocol between the eNB and the MME. SCTP over IP is an
always-up connection for the control plane supporting heartbeat (as depicted in Figure
4-5) and guaranteeing delivery of signaling messages between 9471 WMM and
eNodeB (S1). The SCTP protocol is defined in RFC 2960.
Figure 4-5: S1-MME Heartbeat Support
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
36 / 652
At initialization time, an eNB sets up an SCTP association with all the MMEs of an
assigned MME pool. The MME accepts the SCTP association for all eNBs provisioned
to TAIs within the MME. (Note: The MME is provisioned with a set of TAIs that the MME
group is responsible for. If the MME is provisioned with a particular TAI, it means that
the MME is able to communicate with each of the eNBs in that TA, or that the MME can
communicate with another MME that can communicate with each of the eNBs in that
TA. MMEs are not directly provisioned with eNB information.
The 9471 WMM interacts with the eNodeB to setup S1/radio bearers over the S1
interface (via S1-AP message) to:
Setup UE context in eNodeB
Release UE context in eNodeB
Activate/Modify/Delete S1 Bearers in eNodeB
Lock & Unlock the MME aggregate service
When the MME aggregate service is locked:
MME (as SCTP server for S1 interface) will close the SCTP socket for each S1MME link.
SCTP layer will automatically re-establish, but MME will respond to eNodeB's
S1SETUPREQUEST with a S1SETUPFAILURE with S1AP cause code "OAM
Intervention". This causes the S1-MME links to be in
Unlocked/Disabled/Dependency state.
All UE contexts are purged at locking. Note that Attach requests will fail when
MME aggregate service is locked.
The MAFs MTMSI restart counter is incremented. MTMSI restart counter is

unique per MAF pair and is not synched with other MAF pairs.
When the MME aggregate service is unlocked:
S1-MME links will be in Unlocked/Disabled/Dependency state until the eNB

reconnects and sends S1SETUPREQUEST. MME will respond with
S1SETUPRESPONSE. At that point, S1-MME links will transition to
Unlocked/Enabled/None state.
Please refer to Figure 4-6 :
Figure 4-6: S1-MME Bearer Support
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
37 / 652
4.2.1 MULTIPLE S1MME LOCAL IP ADDRESSES
To facilitate segregation of eNB S1-MME traffic, an operator can provision up to nine (9)
S1-MME local IP addresses. In network sharing scenarios, all an operators eNBs can
use one of the IP addresses and all the eNBs of a different operator can use a different
IP address to keep their S1-MME traffic logically separate.
A single GigE interface can be shared by multiple S1-MME local IP addresses.
A separate SCTP profile can be assigned to each local IP address.
The total number of eNB associations across all the local S1-MME IP addresses is
limited by the maximum number of eNB supported by the 9471 WMM.
4.2.2 SHARED IP ADDRESS

INTERFACES
BETWEEN
S1MME
AND
M3
The MME supports growth of the M3 interface using the same IP address as S1-MME
without interrupting UEs in ECM-CONNECTED and ECM-IDLE state and without
interrupting MME call processing.
SCTP multi-homing is supported on both S1-MME and M3 interfaces. Operators must
use different SCTP ports for S1-MME interface (standards port # 36412) and M3
interface (standards port# 36444) on the MME. Only one M3 interface can be shared.
Operators must provision the same SCTP configuration (either MH or SH) for S1-MME
and M3 when the IP address is shared.
The Non-Access Signaling Stratum (NAS) is a concatenation of the interfaces between
the UE and eNodeB, and between the eNodeB and 9471 WMM. It is the functional layer
supporting Evolved Mobility Management (EMM) and EPS Session Management (ESM)
procedures that support signaling and traffic between the UE and the ePC. NAS
supports mobility management and user plane bearer functions, as well as ciphering
and integrity protection of NAS signaling. The eNB uses the S1 interface to send and
receive NAS messages for a UE. The NAS protocol is defined in 3GPP TS 24.301.
Please refer to Figure 4-7 below :
Figure 4-7: NAS Protocol
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
38 / 652
The Non-Access Stratum (NAS) protocol is the highest stratum of the control plane
between UE and 9471 WMM at the radio interface. NAS messages (supporting
procedures such as Attach, TAU, and Service Request) are sent between the
UE/eNodeB and the MME to support mobility management and session management
and contain IEs as specified in [R08] and [R07].
Information elements (IEs) that make up a given message may contain cause
codes/values defined in 3GPP TS 24.301. If the service provider has enabled Use
Mapped NAS Codes via MME provisioning, then the MME sends a provisioned NAS
cause value in mobility management reject messages resulting from access restrictions.
If use of the mapped NAS codes is not enabled, MME uses the default values.
All NAS message integrity is protected by the 9471 WMM and UE.
eNB
UE
MME
NAS
NAS
RRC
RRC S1-AP
S1-AP
PDCP
PDCP SCTP
SCTP
RLC
RLC
MAC
MAC MAC
MAC
PHY
PHY
PHY
LTE-Uu
IP
IP
PHY
S1-MME
Figure 4-8: Control Plane for NAS Protocol

Note: LTE-Uu is the EUTRAN protocol between the UE and the eNB. It is defined in
3GPP TS 36.300.
The peer-to-peer S1 mode connection is a concatenation of Radio Resource Control
(RRC) connection via the LTE-Uu interface (radio protocol between the UE and the
eNodeB) and an S1AP connection via the S1 interface.
Protocols are terminated at the 9471 WMM, instead of at the 9400 LTE RAN.
EPS sessions on an MME are not preserved when transitioning from one version of the
standard to another version. That is, MME does not preserve stable sessions in ECMCONNECTED state or in ECM-IDLE state when version of the NAS is changed via
configuration.
One (or more) SCTP profiles can be defined via the SCTP Profile page on the
provisioning web interface. A profile can then be mapped to the S1-MME interface via
the Interface Profile page.
Please refer to [R28] for further information regarding the SCTP protocol.
Several timers are used to define S1-MME interface behavior. The MME is also
provisioned other NAS attributes. Please refer to Section 0 for further information
regarding S1 and NAS parameter provisioning.
PCMD is also supported between the MME and Nokia eNBs. The MME uses the
PRIVATE MESSAGE to control the start/stop of PCMD collection on PCMD-capable
eNBs. The eNB uses the PRIVATE MESSAGE to inform the MME that it is PCMDcapable. The eNodeB also uses this message to deliver PCMD data to the MME.
Note that the IEs contained within the PRIVATE MESSAGE are Nokia proprietary.
Refer to PCMD Reference Guide, 9YZ-05481-0015-RKZZA, for PCMD information.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
39 / 652
4.3 S3
The S3 interface supports 9471 WMM communication with Release 8 SGSNs (S4SGSN) in 3G data networks enabling user and bearer information exchange for inter3GPP access network mobility in idle and/or active state.
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).
This interface may be used during:
Attach procedure
Tracking area update procedure, with or without SGW change, when UE moves
from UTRAN/GERAN to E-UTRAN.
Routing area update procedure, with or without SGW change, when UE moves
from E-UTAN to UTRAN/GERAN.
Inter RAT handover procedure
MME
SGSN
GTPv2-C
GTPv2-C
UDP
UDP
IP
IP
Data Link Layer
Data Link Layer
Physical Layer
Physical Layer
S3
Figure 4-9: S3 Protocol Stack
Legend:
GTPv2
GTPv2 protocol stack tunnels signaling messages between the MME

and the S4-SGSN using the S3 interface. GTPv2 is defined in 3GPP
TS 29.274.
UDP
User Datagram Protocol (UDP): This protocol transfers signaling

messages between the MME and the S4-SGSN. UDP is defined in
RFC 768.
MME supports transporting of S3 messages over either UDP/IPv4 or UDP/IPv6. MME

uses UDP port 2123 for GTPv2-C request messages; the response message UDP port
is set to the source UDP port of corresponding message.
The GTP path between Nokia 9471 WMM and S4-SGSN is monitored using the GTP
messages Echo Request and Echo Response.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
40 / 652
The S3 link managed object (MO) operational state can be ENABLED or DISABLED
(depending on the outcome of the periodic Echo Request/Echo Response and on the
operational state of its superior MO).
The S3 link MO administrative state can be LOCKED or UNLOCKED, depending on the
action of the administrator.
When the S3 link MO is in the LOCKED or DISABLED state:
MME call processing does not send any S3 request messages on the interface.
MME rejects any S3 request message from the S4-SGSN on the interface.
When the S3 link MO is in the UNLOCKED and ENABLED state, the MME sends and
receives S3 messages.
Combo MME-SGSN supports the use of a common IP address between the S3 and
S16 interfaces.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
41 / 652
4.4 S4
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 tunnelling.
If the SGW does not change when a UE moves between E-UTRAN and
UTRAN/GERAN (Inter RAT handover Procedure), then the MME and the SGSN interact
with the same SGW for a given UE over the respective S11 and S4 interfaces. From an
SGW point of view, there is only one SGW TEID-C per UE on the S11 and the S4
interfaces. The same SGW tunnel is shared for the incoming control messages related
to the operations on the same UE. At any given time, for the same UE, the SGW stores
only one TEID-C from either the MME or the SGSN. The SGW uses this TEID-C to
send S11 or S4 messages to the respective MME or SGSN.
SGW
S4-SGSN
GTPv2-C
GTPv2-C
UDP
UDP
IP
IP
Data Link Layer
Data Link Layer
Physical Layer
Physical Layer
S4
Figure 4-10: Control Plane for S4 Interface
Legend:
GTPv2
GTPv2 protocol stack tunnels signaling messages between the SGW and the
S4-SGSN using the S4 interface. GTPv2 is defined in 3GPP TS 29.274.
UDP
User Datagram Protocol (UDP): This protocol transfers signaling messages

between the MME and the S4-SGSN. UDP is defined in RFC 768.
S4 messages may be sent over either UDP/IPv4 or UDP/IPv6. UDP port 2123 is used
for GTPv2-C request messages; the response message UDP port is set to the source
UDP port of corresponding message. Combo MME-SGSN supports the use of a
common IP address between the S4 and S11 interfaces.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
42 / 652
4.5 S6A
S6a supports the control plane between the MME and the stand-alone Home
Subscriber Server (HSS). (A combined HSS/EIR server is not supported since LM4.0.
The S13 interface must be used to support EIR communication.) The link supports
DIAMETER and SCTP protocols. The MME uses DIAMETER messages to/from the
HSS to transfer subscription and authentication information, and authenticate users.
The DIAMETER messages are carried over SCTP. (The TCP protocol is not supported
on MME.) The associated protocol stack is shown in Figure 4-11 below.
MME
HSS
Diameter
Diameter
SCTP
SCTP
IP
IP
Data Link Layer
Data Link Layer
Physical Layer
Physical Layer
S6a
Figure 4-11: S6a Protocol Stack
Legend:
Diameter
Diameter protocol defines minimum requirements for AAA protocol

and supports transferring of subscription and authentication data for
authenticating/authorizing user access to the evolved system between
Nokia 9471 WMM and HSS (S6a).
SCTP
Stream Control Transmission Protocol transfers signaling messages.

Diameter messages over the S6a interface utilize the SCTP
checksum method defined in RFC 3309.
The Nokia 9471 WMM initiates the establishment of the SCTP
association toward the HSS.
The DIAMETER protocol is defined in RFC 3588.

SCTP is the control plane protocol between the MME and the HSS. The SCTP protocol
is defined in RFC 2960. The S6a interface also uses the SCTP checksum method
described in RFC 3309.
The S6a interface supports multiple SCTP streams. The number of outbound and
inbound streams are provisionable (note that the default setting is 1 inbound and 1
outbound). With multiple outbound streams, MME selects a stream to send using the
round-robin selection method.With multiple inbound streams, MME lumps messages
from all streams together and processes them as if they are from a single stream.
Note on TCP/SCTP differences: SCTP is a transport layer protocol that provides a role
similar to the traditional TCP. SCTP is transaction-oriented, transporting a group of
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
43 / 652
bytes in a message that is read in the same order at the receiver application. TCP is
stream-oriented, transporting bytes that it correctly reorders if they are delivered out of
order. SCTP provides features that TCP does not: multi-homing, multiple streams, and
better error checking and validation checks.
provisioning web interface. A profile can then be mapped to the S6a interface via the
Interface Profile page. Please refer to [R28] for further information regarding the SCTP
protocol.
A single DIAMETER profile can be defined via the DIAMETER Profile page on the
provisioning web interface. The profile is then used with the DIAMETER Connections
page and assigned to the MIF pair. Please refer to [R28] for further information
regarding the DIAMETER protocol.
S6a interface enables the transfer of subscription and authentication data between the
Nokia 9471 WMM and HSS in order to authorize user access to the evolved system.
The MME supports up to eight S6a associations, including primary, secondary, tertiary
and fourth to eight additional S6a associations. Specifically, eight unique HSS IP
addresses (one SCTP connection for each HSS) may be provisioned and associated to
each IMSI rule via an HSS Group. When SCTP multi-homing is active on the HSS side,
each HSS Remote Endpoint must be provisioned with an alternate (secondary) IP
address in addition to the required primary IP address. When multiple HSS IP
addresses exist, the MME sets up a double SCTP association with the primary and the
secondary S6a IP addresses. The SCTP association is for both the primary and
alternative paths. If the first path fails, the association has already allowed for the
second path. 100% of the traffic is sent to a single IP address, be it the primary IP
address or one of the backup IP addresses. As soon as the primary IP address is
available, the MME starts using it again.
Subscription data is synchronized across all HSS S6a interfaces.
Figure 4-12: S6a Heartbeat Support
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
44 / 652
4.6 S6d
The S6d interface provides the following benefits:
Support for a common S6ad interface toward the HSS for the MME-SGSN
configuration.
Consolidation of 2G/3G/4G subscription data in the HSS, at least for LTE

subscribers with 2G/3G service.
Support for all IP-based interfaces to the HSS over the Diameter protocol for
both MME and SGSN
Provide operators the option to keep and use the Gr interface for legacy 2G/3G
users and/or to connect to roaming partners legacy HLR while using S6ad
interface for LTE users with 2G/3G subscription
The S6a and S6d interfaces (the diameter-based interfaces between MME and HSS)
share the same managed object and link, S6ad.
4.7 S6ad
S6ad supports the control plane between the MME and the HSS/DRA in combo MMESGSN configuration.
The S6ad interface is used for LTE users whose 2G/3G/4G subscription data is stored
in HSS and the Gr interface is used for 2G/3G users whose subscription data is stored
in the HLR
Figures 4-12 shows 9471 WMM interfaces to the HSS/HLR in WM7.1.0 after adding
S6d interface support
9471 WMM
MME-SGSN
S6ad
Gn
S3
RNC
Gb
BSC
(diameter)
Gr (MAP)
SGSN
HSS /DRA
SCTP
Iu-PS
SCTP
eNB
MME
S1-MME
-
HLR / STP
Figure 4-13: S6ad interface
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
45 / 652
4.8 S10
The S10 interface is a GPRS Tunneling Protocol (GTP) tunnel connecting MMEs, both
within a given pool and also across pools. It supports the control plane between MMEs.
This connection is used for MME relocation and "MMEa-to-MMEb" information transfer.
LTE supports up to 8 MMEs in an MME pool and up to 8 MME pools, resulting in up to
63 S10 interfaces. New S10 interfaces may be provisioned without disruption to the
existing S10 interfaces and other interfaces. The GTP-C messages are carried over
UDP. The associated protocol stack is shown in Figure 4-14 below.
MME
MME
GTPv2-C
GTPv2-C
UDP
UDP
IP
IP
Data Link Layer
Data Link Layer
Physical Layer
Physical Layer
S10
Legend:
GTP-C
GPRS Tunneling Protocol for the control plane (GTP-C):

This protocol tunnels signaling messages between the MMEs using the S10
interface. GTPv2 and GTP are defined in 3GPP TS 29.274.
UDP
User Datagram Protocol (UDP): This protocol transfers signaling messages

between the MMEs. UDP is defined in RFC 768.
MME supports transporting of S10 messages over either UDP/IPv4 or UDP/IPv6.

MME uses UDP port 2123 for GTP-C request messages; the response message UDP
port is set to the source UDP port of corresponding message.
One (or more) GTP profiles can be defined via the GTP Profile page on the provisioning
web interface. A profile can then be mapped to the S10 interface via the Interface
Profile page. Please refer to [R28] for further information regarding the GTP-C protocol.
The path between the 9471 WMMs is monitored using the GTP messages Echo
Request and Echo Response.
Figure 4-15: S10 Heartbeat Support
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
46 / 652
4.9 S11
S11 interface is the reference point between 9471 WMM and 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.
The 9471 WMM supports the relevant GTP-C messages over S11 interface to the SGW
for the following:
Session Creation procedures
Session Deletion procedures
Indirect Data Forwarding Tunnel Creation procedures
Indirect Data Forwarding Tunnel Deletion procedures
Figure 4-16: S11 Bearer Support

S11 supports the control plane between the MME and the SGW. The link supports
GTP-C and UDP protocols. The MME uses GTP-C messages to/from the SGW to
create and delete bearer sessions. The GTP-C messages are carried over UDP. The
associated protocol stack is shown in Figure 4-17 below:
MME
SGW
GTPv2-C
GTPv2-C
UDP
UDP
IP
IP
Data Link Layer
Data Link Layer
Physical Layer
Physical Layer
S11
Legend:
Issue 11.01
GTP-C
GPRS Tunneling Protocol for the control plane (GTP-C) supports tunnelling
signalling messages between Nokia 9471 WMM and SGW to set up ePS
bearers. GTP-C V2 is defined in 3GPP TS 29.274.
UDP
User Datagram Protocol (UDP) transfers signaling messages between the MME
and the SGW. UDP is defined in RFC 768.
LTE/DCL/APP/031094
Nokia 2016
47 / 652
web interface. A profile can then be mapped to the S11 interface via the Interface
Profile page. Please refer to [R28] for further information regarding the GTP-C protocol.
The GTP path between 9471 WMM and SGW is monitored using the messages Echo
Request and Echo Response.
Figure 4-18: S11 Heartbeat Support

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.
If the global parameter Send RAN NAS Codes on S11 is set to YES, then the MME:
a) sends a provisioned cause value in the Private Extension IE of the following
S11 messages toward the SGW (related to rejection of Attach, TAU, or
SR/ESR), and
b)
the UE state changes to de-registered only if the rejection involves deactivation

of bearers in the EUTRAN and/or in the network:
Create Bearer Response.
Release Access Bearer Request.
Update Bearer Response.
Please refer to 8.1.38.11 for provisioning of the global parameter Send RAN NAS
Codes on S11
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
48 / 652
When the following conditions are fulfilled:
the RAT type has not changed
the Serving Network has not changed
the MME does not need to send UE's location and/or User CSG information
or/and UE Time Zone to the PDN GW
the MME does not need to send an MME-FQ-CSID as per the requirements
specified in 3GPP TS 23.007
and if the global parameter Support Modify Access Bearer Request is enabled,
the
MME may send a Modify Bearer Request message per PDN Connection on the S11
interface to an SGW (when the MME and SGW both support the Modify Access Bearer
Request) as part of the following procedures:
UE triggered Service Request if there is no suspended bearer for the UE.
S1-based Handover without SGW relocation.
X2-based Handover without SGW relocation.
Inter-MME E-UTRAN Tracking Area Update without SGW relocation.
Intra-MME E-UTRAN Tracking Area Update without SGW relocation with Active
Flag
If the global parameter Support Modify Access Bearer Request is enabled, S11 Echo
Request and Echo Response messages contains Node Feature IE to indicates the
support of the Support Modify Access Bearer Request.
Parameter
Support Modify Access Bearer Request
SAM Table Name
Global Parameters
ltemme.MMEGParmsAbs.gParmName
ltemme.MMEGParmsAbs.gParmValue
OSS ID
Range & Unit
gParmName
String
Support Modify Access Bearer Request
gParmValue
Boolean
Yes (enable) or No (disable)
Issue 11.01
Impact of Change
No service impact.
Value
Operator Dependent; default = No
Feature
m20105-01
LTE/DCL/APP/031094
Nokia 2016
49 / 652
If MME also receives support of Support Modify Access Bearer Request indication in
the Node Feature IE of the Echo Request or Response message from SGW, MME
starts to use Support Modify Access Bearer Request in the following scenarios when
ULI, CSG, and UE Time Zone are not reported to PGW:
Issue 11.01
In Service Request procedure including SRS triggered Service Request, if UE

is not suspended, MME replaces current multiple Modify Bearer Requests with
one Modify Access Bearer Request. The Modify Access Bearer Request
includes S1-U eNodeB F-TEID for all successful bearers and may also contain
list of bearers that to be removed.
In S1-based handover without SGW relocation procedure, MME replaces

current multiple Modify Bearer Requests with one Modify Access Bearer
Request. The Modify Access Bearer Request includes S1-U eNodeB F-TEID
for all successful bearers. The Modify Access Bearer Request. may also
contain list of bearers that to be removed.
In X2-based handover without SGW relocation procedure, MME replaces

current multiple Modify Bearer Requests with one Modify Access Bearer
Request. The Modify Access Bearer Request includes S1-U eNodeB F-TEID
for all successful bearers. The Modify Access Bearer Request may also contain
list of bearers that to be removed.
In inter-MME Tracking Area Update without SGW relocation procedure, MME

replaces current multiple Modify Bearer Requests with one Modify Access
Bearer Request prior to Update Location exchange with HSS. The Modify
Access Bearer Request includes MMEs sender F-TEID. If the TAU Request
has active flag, MME will also replace second set of Modify Bearer Requests
with a second Modify Access Bearer Request after Initial Context Setup
exchange with eNodeB. The second Modify Access Bearer Request includes
S1-U eNodeB F-TEID for all successful bearers. The Modify Access Bearer
Request may also contain list of bearers that to be removed.
In intra-MME Tracking Area Update without SGW relocation procedure, MME

replaces current multiple Modify Bearer Requests with one Modify Access
Bearer Request. The Modify Access Bearer Request includes S1-U eNodeB FTEID for all successful bearers and may also contain list of bearers that to be
removed.
LTE/DCL/APP/031094
Nokia 2016
50 / 652
4.10 S12
The S12 interface supports direct communication between UTRAN and the SGW for
user plane tunnelling 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.
SGW
NodeB RNC
GTPv2-C
GTPv2-C
UDP
UDP
IP
IP
Data Link Layer
Data Link Layer
Physical Layer
Physical Layer
S12
Figure 4-19: Control Plane for S12 Interface
Legend:
GTP-C
GPRS Tunneling Protocol for the control plane (GTP-C) supports

tunnelling signalling messages between Nokia 9471 WMM and SGW
to set up ePS bearers. GTP-C V2 is defined in 3GPP TS 29.274.
UDP
User Datagram Protocol (UDP) transfers signaling messages between

the MME and the SGW. UDP is defined in RFC 768.
S12 messages may be sent over either UDP/IPv4 or UDP/IPv6. UDP port 2123 is used
for GTPv2-C request messages; the response message UDP port is set to the source
UDP port of corresponding message.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
51 / 652
4.11 S13
From an MME perspective, the S13 link 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 Mobile Equipment Identity Check Procedure permits the operator(s) of the MME 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) as part of the Attach procedure detailed in Figure
4-20.
Figure 4-20: S13 Supporting MEID Check Procedure

Legend:
1
The MME sends Identity Request (Identity Type) to the UE. The UE responds
with Identity Response (Mobile Identity).
If the MME is configured to check the IMEI against the Equipment Identity
Register (EIR), it sends ME Identity Check (ME Identity, IMSI) to EIR.
The EIR responds with ME Identity Check Ack (Result).
MME analyzes the result code in the response from the EIR in order to
determine its subsequent actions (such as allowing Attach procedure to
continue, or sending an Attach Reject).
If there is no response from EIR, (and the UE was previously blacklisted or
unknown) MME sends Attach Reject.
The S13 protocol stack is shown here. Refer to 3GPP TS 29.272 for detailed
specifications.
MME
HSS
Diameter
Diameter
SCTP
SCTP
IP
IP
Data Link Layer
Data Link Layer
Physical Layer
Physical Layer
S13
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
52 / 652
Diameter protocol (as specified in 3GPP TS 29.272) supports UE identify check
procedure between MME and EIR. Diameter messages over the S13 interface use
SCTP as the transport protocol to transfer signaling messages.
With SCTP multi-homing, the S1-AP interface is configured with a primary IP address
(IPv4 and/or IPv6) and an alternate (secondary) IP address (of the same type: IPv4 if
the primary is IPv4, and/or IPv6).
EIR handling of DPR/DPA messages:
If the MME detects the EIR link is being blocked, the MME sends a DPR to the EIR, and
waits duration of Diameter Profile Timer DPRMessageTimer (default 6 seconds) for the
EIR to respond with a DPA. When the DPA is received or times out, the MME
gracefully closes the connection and completes the link 'blocking' operation to this EIR.
Previously, the MME did not initiate DPR (when blocking an EIR link) and immediately
closed the connection.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
53 / 652
4.12 S102
The S102 interface is the reference point between the MME and 3GPP2 1xCS IWS.
The S102 interface is used to support UEs that do not transmit and receive on both the
LTE and 1x radio interfaces simultaneously. The S102 interface allows CSFB to 1xRTT
to establish voice calls in the CS domain by supporting registration over EPS
procedures as specified in 3GPP TS 23.272.
The S102 reference point is used to convey 3GPP2 1xCS signaling messages between
the MME and 3GPP2 1xCS IWS. These 1xCS signaling messages are actually
exchanged between the UE and the 3GPP2 1xCS IWS, and S102 is only one link in the
overall UE-1xCS IWS tunneling path.
The S102 interface provides the following functions:
Relays 3GPP2 1xCS signaling messages to support Single Radio Voice Call
Continuity (SRVCC) as specified in TS 23.216. 1xCS signaling messages are
messages that are defined for A21 interface as described in 3GPP2 A.S0008-C
and 3GPP2 A.S0009-C. The S102 interface messages are based on A21
messages.
Provides Circuit Switched Fallback (CSFB) to 1xCS network as specified in TS

23.272. S102 interface on the MME supports Circuit Switch Fallback from LTE
Data to 3G1X Circuit Voice for 3G1X Voice Call Origination and Termination.
Supports SMS over S102 in EPS. SMS does not require any overlapped CDMA
1xRTT coverage. The 3G1x Mobile Originated (MO) and Mobile Terminated (MT)
SMS are tunneled in EPS and over S102, and do not cause any CS fallback to
CDMA 1xRTT.
The S102 application is based on UDP/IP transport medium.
MME
1xCS IWS
IOSAP (A21)
IOSAP (A21)
UDP
UDP
IP
IP
Data Link Layer
Data Link Layer
Physical Layer
Physical Layer
S102
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
54 / 652
MME supports up to two standalone IWSs nodes for same MSCID if the global
parameter Multiple IWS Support is enabled (default=no, MME supports one IWS node
per MSCID)
Parameter
Multiple IWS Support
SAM Table Name
Global Parameters
OSS ID
Range & Unit
gParmName
Multiple IWS Support
gParmValue
Boolean
Yes (enable) or No (disable)
Impact of Change
No service impact.
Value
Feature
m20103-02
If the global parameter Multiple IWS Support flag is enabled, messaging that is
exchanged across S102 interface remains on the same MSC/IWS path. The two IWSs
nodes do not share information and they are completely separate systems.
As such, once the MME selects an IWS node for a given UE, all messages associated
with that UE remain on that same connection. If one link to the primary IWS node is
unavailable, the MME switches to the secondary link. In addition, MME supports load
balancing and failover for multiple/pool of IWSs nodes for same MSCID.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
55 / 652
4.13 SBC
The SBc-AP is the interface between the MME and the Cell Broadcast Center (CBC)
and is used to transport messages associated with the Warning Message Delivery
function. These messages consist of text that warns of safety events that may impact a
geographical region. When SBc is enabled, the MME acts as an SCTP server for the
SBc interface type. The MME supports the SBc interface as an SCTP protocol stack
with semi-permanent associations, and local and remote multi-homing. The CBC can
initiate the SCTP association toward the MME (along with eNB).
Messages are forwarded to the appropriate eNodeB(s) and then broadcast 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 manages the case where multiple copies of WriteReplace Warning Message Request are received for the same warning message (for
example, from multiple MMEs in the case of MME pooling).
The SBc interface is an SCTP based interface with multi-homing and supports IPv4,
IPv6, or IPv4 and IPv6 addressing. The associated protocol stack is shown in Figure
4-23 below.
The MME supports SCTP associations with local multi-homing and/or remote multihoming on the SBc interface. A maximum of two local multi-homing addresses per
SCTP association is supported. When MME is the SCTP client, the MME supports the
provisioning of up to two addresses per SCTP association for a remote multi-homed
SCTP peer. When the MME as the SCTP client is setting up a SCTP association with a
remote SCTP peer, the MME chooses its local IP addresses (IPv4 or IPv6) that
matches with the IP address type (IPv4 or IPv6) of the remote SCTP peer.
MME
CBC
S
SBcAP
S
SBcAP
SCTP
SCTP
IP
IP
Data Link Layer
Data Link Layer
Physical Layer
Physical Layer
SBc
Figure 4-23: SBc Protocol Stack
SBcAP is the application layer protocol between the MME and the CBC.
SBcAP procedures are defined in 3GPP TS 29.168.
SCTP is the control plane protocol between the MME and the CBC. The SCTP protocol
is defined in RFC 2960.
provisioning web interface. A profile can then be mapped to the SBc interface via the
Interface Profile page.
Please refer to [R28] for further information regarding the SCTP protocol.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
56 / 652
4.14 SDS (SGS Lite)
SDS is the interface between the MME and the Gateway to Thing Space (GWTS)
server.
It provides support for SDS UE Bearer Less (UEs that are subscribed to connect to the
network without any bearers) and used proprietary SGs Lite Protocol over TCP (Verizon
proprietary). The SGs Lite interface and protocols messages are loosely based on
SGsAP messages.
MME
GW-TS
SGSAP / SDS
SGSAP / SDS
TCP
TCP
IP
IP
Data Link Layer
Data Link Layer
Physical Layer
Physical Layer
SGS Lite
SDS
Figure 4-24: SGs Lite Protocol Stack
The SGs Lite messages for MTC UE devices are transported over the TCP/IP.
Up to four GW-TS nodes and four TCP connections to each GW-TS can be provisioned
with different preference to GW-TS. All the SGsLite messages are sent to the GW-TS
with highest preference value. MME uses the GW-TS with next highest preference if the
GW-TS with the highest preference fail.
Figure 4-25 MME to GW-TS TCP connections
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
57 / 652
4.15 SGs
The SGs interface is used for the mobility management and paging procedures
between EPS and the CS domain. This interface is also used for the delivery of both
mobile originating and mobile terminating calls with LTE suspension.
The interface is used to:
Coordinate the location information of UEs that are IMSI attached to both EPS
and non-EPS services
Relay certain messages related to GSM circuit-switched services over the EPS
system via MME
The SGsAP messages for individual CSFB-capable UE are transported over the SCTP
association between the MME and the MSC/VLR. The MME shall establish the SCTP
association towards the MSC/VLR. For a given MSC/VLR, there is only one SCTP
association. However, the MME maintains many SGs associations with the MSC/VLR,
one for each attached CSFB-capable UE. The associated protocol stack is shown in
Figure 4-24 below.
MME
MSC/VLR
SGsAP
SGsAP
SCTP
SCTP
IP
IP
Data Link Layer
Data Link Layer
Physical Layer
Physical Layer
SGs
Figure 4-26: SGs Protocol Stack
SGsAP is the application layer protocol between the MME and the MSC/VLR.
SGsAP procedures are defined in 3GPP TS 29.118.
SCTP is the control plane protocol between the MME and the MSC/VLR. The SCTP
protocol is defined in RFC 2960.One (or more) SCTP profiles can be defined via the
SCTP Profile page on the provisioning web interface. A profile can then be mapped to
the SGs interface via the Interface Profile page. Please refer to [R28] for further
information regarding the SCTP protocol.
With SCTP multi-homing, each SGs Remote Endpoint can be provisioned with an
alternate (secondary) IPv4 address and/or IPv6 address in addition to the required
primary IPv4 address. WM9.0.0 adds IPv6 support for SGS links. 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.
Several timers are used to define SGs interface behavior. Please refer to Section
8.1.31.4 for further information regarding provisioning SGs timers.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
58 / 652
4.16 SLG
The SLg interface supports communication between the 9471 WMM and the Gateway
Mobile Location Center (GMLC).to support transport positioning requests and
responses for Emergency 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.
Semi-permanent SCTP associations are set up between the GMLC and MME.
The GMLC establishes SCTP association with MME either at GMLC initialization time
(MME allows connections from a list of provisioned GMLC) or at the time GMLC sends
a positioning request to MME.
Note that the SLg interface is not allowed between a GMLC in one network and an
MME in a different network.
MME
GMLC
Diameter (ELP)
Diameter (ELP)
SCTP
SCTP
IP
IP
Data Link Layer
Data Link Layer
Physical Layer
Physical Layer
SLg
Figure 4-27: SLg Protocol Stack
Up to eight SLG remote endpoints can be configured per MME.
GMLC handling of DPR/DPA messages:
If the MME detects that the SLg link is being blocked, the MME sends a DPR to the
GMLC, and waits duration of Diameter Profile timer DPRMessageTimer (default 6
seconds) for the GMLC to respond with a DPA. When the DPA is received or times out,
the MME gracefully closes the connection and completes the link 'blocking' operation to
this GMLC. Previously, the MME did not initiate DPR (when blocking an GMLC link) and
immediately closed the connection.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
59 / 652
4.17 SLs
The SLs interface supports communication between the 9471 WMM and the EPC
Serving Mobile Location Center (E-SMLC) to obtain a UE's position.
This is currently used in support of Emergency Location Services (LCS).
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 E-UTRAN to
exchange location information applicable to network assisted and network based
position methods. The E-SMLC uses LTE Positioning Protocol (LPP) to transfer location
commands and data to a UE. The E-SMLC uses LTE Positioning Protocol Annex
(LPPa) to transfer commands and messages to the eNB. LPP messages are always
associated with an in-progress Location Request. LPPa messages may be either
associated with an in-progress Location Request (UE associated or connectionoriented) or not associated with a particular location (NON-UE associated or
connectionless).
NAS messages Downlink Generic NAS Transport and Uplink Generic NAS Transport
messages are used to transport transparent transport of LPP messages between a UE
and the E-SMLC.
These are the messages used for the LPP and LPPa transports:
LPP :
LPP Connection Oriented Information Transfer (TS 29.171)
Downlink Generic NAS Transport (TS 24.301)
Uplink Generic NAS Transport (TS 24.301)
LPPa :
LPPa Connection Oriented Information Transfer (TS 29.171)
DOWNLINK UE ASSOCIATED LPPA TRANSPORT (TS 36.413)
UPLINK UE ASSOCIATED LPPA TRANSPORT (TS 36.413)
LPPa Connectionless Information Transfer (TS 29.171)
DOWNLINK NON-UE ASSOCIATED LPPA TRANSPORT (TS 36.413)
UPLINK NON-UE ASSOCIATED LPPA TRANSPORT (TS 36.413)
E-SMLC
MME
LCSAP
LCSAP
SCTP
SCTP
IP
IP
Data Link Layer
Data Link Layer
Physical Layer
Physical Layer
SLs
Figure 4-28: SLs Protocol Stack
The MME establishes semi-permanent connections with a set of E-SMLCs at the
initialization time. MME supports both local and remote multi-homing. An MME serving
area may consist of several E-SMLCs. E-SMLCs are associated with TAIs, and ESMLC selection is based upon the last seen TAI. When a location request is aborted;
the E-SMLC may have enough information to provide a location estimate. If so, it may
include location information in the location response to the abort. If this information is
received by the MME it will be returned to the GMLC.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
60 / 652
4.18 Sm
The Sm interface is the reference point between the Multimedia Broadcast/Multicast
Service (MBMS) Gateway and the MME. It transports Sm-AP messages to support
signaling functions for MBMS sessions. The MME acts as a GTPcV2 server for the Sm
interface.
MME
MBMS GW
GTPv2-C
GTPv2-C
UDP
UDP
IP
IP
Data Link Layer
Data Link Layer
Physical Layer
Physical Layer
Sm
Figure 4-29: Sm Protocol Stack
The Sm-AP messages between an MBMS GW and the MME are transported over GTPC. GTPv2 is defined in 3GPP TS 29.274 and 29.060. Sm is defined in TS 36.444.
The Sm Application Protocol supports signaling/control functions.
These signaling functions include Session Management, such as starting, stopping, and
updating MBMS sessions.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
61 / 652
4.19 SV
The Sv interface is the link to the MSC server that supports UMTS hand down of IMSanchored voice sessions to the CS domain in the UTRAN/GERAN. The MME provides
SRVCC (Single Radio Voice Call Continuity) from the E-UTRAN to the UTRAN/GERAN.
MME
MSC Server
GTPv2-C
GTPv2-C
UDP
UDP
IP
IP
Data Link Layer
Data Link Layer
Physical Layer
Physical Layer
Sv
Figure 4-30: Sv Protocol Stack
Sv is defined in 3GPP TS 29.280. The Sv messages are transported over GTP-C.
GTPv2 is defined in 3GPP TS 29.274. The UDP destination port for GTPv2-C request
messages is 2123.
Starting in In WM9.1.0 and later releases, MME provides a configuration of up to four
Sv MSC servers per LAI.
The provisioned MSC servers for LAI are selected in a round-robin load assignment.
The global parameter SGs SV_MSC_PREFERENCE allows to configure UE
assignment preference for MSC supporting both SGs and Sv interface
Following choices are proposed for the MSC selection:
All UE : MME uses the MSCs supporting SGs and Sv interface only for the
SRVCC capable UEs and these MSC are excluded for the UEs that do not
support SRVCC.
SRVCC UE Only: MME uses these MSC for both SRVCC capable and SRVCC
not capable UEs.
Parameter
SGs SV MSC PREFERENCE
SAM Table Name
Global Parameters
OSS ID
Range & Unit
gParmName
SGs SV MSC PREFERENCE
gParmValue
All UE, SRVCC UE Only
Issue 11.01
Impact of Change
No service impact.
Value
Operator Dependent; default = All UE
Feature
m30102-07
LTE/DCL/APP/031094
Nokia 2016
62 / 652
4.20 GN
The Gn interface is the link between the 9471 WMM and the Pre-Release 8 SGSN. It
enables mobility handling and inter-RAT handover. This interface allows the MME to
support a handover for a user who transitions from a 3GPP UMTS or GERAN network
to the LTE network and also for a user who transitions from the LTE network to a 3GPP
UTRAN or GERAN network.
The Gn interface transports both signaling and bearer information. The signaling is
directed to the MME and the bearer is directed to the PGW.
Figure 4-31: 3GPP Access for Pre-Release 8 SGSN

The associated Gn protocol stack is shown in Figure 4-30 below.
MME
SGSN
GTPv1-C
GTPv1-C
UDP
UDP
IP
IP
Data Link Layer
Data Link Layer
Physical Layer
Physical Layer
Gn
Figure 4-32: Gn Protocol Stack
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
63 / 652
Legend:
GTP-C
The Gn interface is a control plane interface using the General

Packet Radio System (GPRS) Tunnelling 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.
UDP/IP
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.
The MME uses GTP-C V1. It is defined in 3GPP TS 29.060.

The UDP protocol is defined in RFC 768.
MME supports transporting of Gn messages over UDP/IPv4 only. MME uses UDP port
2123 for GTP-C request messages; the response message UDP port is set to the
source UDP port of corresponding message.
web interface. A profile can then be mapped to the Gn interface via the Interface Profile
page. Please refer to [R28] for further information regarding the GTP-C protocol.
Prior to WMM 7.1.0, the interfaces Gn-MME and Gn-GGSN each had a unique local IP
address. Starting in WMM 7.1.0 and later releases, the Gn control link toward target
MME/SGSN and Gn control link toward GGSN can share or not share the same IP
address. Please refer to the [R28] for further information regarding the sharing of IP
adress between similar interfaces.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
64 / 652
4.21 M3
The M3 interface is the reference point between the Multicast Control Entity (MCE) in
the eNodeB nodes and the 9471 WMM. The MME acts as an SCTP server for the M3
interface type.
The M3AP messages between an MCE and the 9471 WMM are transported over
SCTP/IP. The M3 Application Protocol (M3AP) supports the signaling control functions.
The signaling functions include:
Session Management starting, stopping, and updating MBMS sessions
Reset Functionality ensures a well-defined initialization on the M3 interface
Error Indication Functionality allow a proper error reporting/handling in cases

where no failure messages are defined.
Starting in WM8.0.0 and later releases, support for eMBMS includes the following
enhancements:
M3 setup procedure defined by 3GPP TS 36.444
MCE Configuration Update procedure defined by 3GPP TS 36.444
MCE Service Area list management management of service area lists provided
by MCEs using the M3 Setup and MCE Configuration Update procedures.
Service Area Filtering The MME sends sessions only to MCEs that support one
or more service areas provided by the MBMS gateway.
Radio
Network
Layer
MME
eNB
M3AP
M3AP
Transport
Network
Layer
SCTP
SCTP
IP
IP
Data Link Layer
Data Link Layer
Physical Layer
Physical Layer
M3
Figure 4-33: M3 Protocol Stack
The local IP addresses for the S1-MME and M3 interfaces can be shared. Operators
must use different SCTP ports for S1-MME interface (standards port # 36412) and M3
interface (standards port# 36444) on the MME. The same SCTP profile must be
provisioned for S1-MME and M3 interfaces when the IP address is shared.
With SCTP multi-homing, the M3 interface is configured with a primary IP address (IPv4
and/or IPv6) and an alternate (secondary) IP address. (The secondary IP address must
be the same type as the primary: IPv4 if the primary is IPv4, and/or IPv6 if the primary is
IPv6).
The maximum number of enodeB and MCEs that can be connected to the MME has
increased from 50k to 150k.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
65 / 652
4.22 X1_1
The X1_1 link is a common MME/SGSN interface that supports communication from the
MME/SGSN to the provisioned lawful interception ADMinistration Function (ADMF) for
activation, deactivation and interrogation of surveillance by the Surveillance
Administrator.
TPKT protocol is used for encapsulation of Administration messages for the X1_1
interface. IP layer is IPv4 or IPv6
See [R29], for details regarding MME support for CALEA.
Figure 4-34: X1_1 Protocol Stack MME/SGSN to ADMF
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
66 / 652
4.23 X2 (IRI)
The X2 (IRI) link allows transmission of Intercept Related Information (IRI) messages
from the MME to the Delivery Function 2 (DF2) and from the SGSN to the DF2.
Different X2 encoding requires 2 physical links to the DF2. (Note: this is not the X2
interface between eNBs.)
TPKT protocol is used for encapsulation of Intercept Related Information (IRI)
messages for the X2 interface. IP layer is IPv4 or IPv6.
The two X2 interfaces are combined into one X2 interface and share source and remote
IP addresses. The new X2 interface version also support single ASN.1 encoding
scheme for both MME and SGSN IRI events instead of 2 different encoding schemes.
This new X2 Calea/LI interface connectivity option is supported for combo MME-SGSN
as well as for standalone MME or SGSN configuration.
See [R29], for details regarding MME support for CALEA/LI.
Figure 4-35: X2 (IRI) Protocol Stack WMM to DF2

Note: The MME application supports IPsec for the X2 interface. IPSec is used to
protect the data transmitted between the MME application and the customer's
equipment for the CALEA Interfaces.
The MME application provides the provisioning interface for setting up IPsec
connections by using Openswan to generate the required IPsec information.
The current IPSec implementation is built on assumption that IPSec tunnels are either
terminated at the Lawful Intercept Gateway (LIG), where encrypted data is deciphered,
or at a firewall, where the data is fully deciphered and passed to the LIG unencrypted.
In WM8.0, MME allows the firewall to discriminate services that can be read by the
firewall and only allow encrypted Lawful Intercept data to be tunneled through to the
operators LIG with the assumptions that the encrypted data is passed through the
firewall without deciphering to the LIG .in architecture when there is a firewall in
between.
See [R29], for details regarding MME support for CALEA/LI.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
67 / 652
5 MME OA&M
Nokia personnel typically provide the initial configuration of the MME. Changes to these
parameters may be necessary due to changes in hardware or software, or due to
changes in required functionality. Changes may also be necessary to update
parameters to improve performance. A detailed description of configuration procedures
supported in WM10.0.0 can be found in the customer document [R36].
These procedures include:
How to access all supported user interfaces,
How to configure the MME application,
How to provision the MI-Agent GUI,
How to grow and degrow WMM hardware,
How to upgrade and patch software.
The MME is managed at the element level using the MI-Agent GUI, and the Command
Line Interface (CLI.) The MME can be managed at the network level by the 5620 SAM.
Rule: Provisioning GUI

The local MME Provisioning GUI is not supported in WM7.0.0. Customers must
use the 5620 SAM provisioning GUI for MME provisioning.
Restriction: MME Provisioning

MME provisioning procedures are performed via the 5620 SAM Provisioning GUI.
The MME does not support a local provisioning GUI.
MME OAM activities (configuration management, fault management, performance

management and security management) are supported from user interfaces located on
the OAM server blade. The 5620 SAM provides a provisioning GUI and the ability to cut
through to the 9471 WMM, and also collects traps when a performance measurement
file is generated at the 9471 WMM. Please refer to Section 5.1.3.
Additional information regarding the OA&M process can be found in the customer
document [R35]. All processes and user interfaces associated with fault management,
configuration management, performance management, and security management are
described within that document.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
68 / 652
5.1 MME Management Interfaces
5.1.1 TMN MODEL BY ITU-T
This topic gives a brief overview of the telecommunication management network (TMN)
model as provided by the International Telecommunication Union-Telecommunication
Standardization Sector (ITU-T) which provides a basic understanding of the various
management layers of the telecommunication network.
5.1.1.1
General Description
The TMN model provides a logical idea about how the business of a service provider is
managed.
The concept is that management decisions at each layer are different but interrelated.
For example, detailed information is needed at the element management layer to keep
a switch operating, but only a subset of that information is needed at the network layer
to keep the network operating.
5.1.1.2
TMN Model
The basic TMN model:
Figure 5-1: ITU-T TMN Model
5.1.1.3
Business Management Layer
The business management layer (BML) has responsibility for the total enterprise.
Principal roles of the BML:
Support the decision-making process for the optimal investment and use of new
telecommunications resources
Support the management of operations, administration, and maintenance

(OA&M) related budget
Issue 11.01
Support the supply and demand of OA&M related manpower
Maintain aggregate data about the total enterprise
LTE/DCL/APP/031094
Nokia 2016
69 / 652
5.1.1.4
Service Management Layer
The service management layer (SML) is concerned with and responsible for the
contractual aspects of services that are being provided to customers or available to
potential new customers. Some of the main functions are service order handling,
complaint handling and invoicing.
Principal roles of the SML:
Interface with other public telecommunications operators or recognized operating

agencies
Interact with service providers
Maintain statistical data
Interact between services
5.1.1.5
Network Management Layer
The network management layer (NML) has the responsibility for the management of a
network as supported by the element management layer. Functions addressing the
management of a wide geographical area are located at this layer.
Control and coordination of the network view of all network elements within its
scope or domain
Provisioning, cessation, or modification of network capabilities for the support of

the service to customers
Maintenance of network capabilities
Maintenance of statistical, log, and other data about the network and interaction
with the service management layer on performance, usage and availability
Management of the relationships between the network element functions (NEFs)
Thus, NML provides the functionality to manage a network by coordinating activity

across the network. NML is responsible for the technical performance of the actual
network and controls the available network capabilities and capacity to give the
appropriate accessibility and quality of service.
5.1.1.6
Element Management Layer
The element management layer (EML) systems, generally called operations

maintenance centers or network operations centers manage each individual network
element. EML manages each network element on an individual or group basis.
Principal roles of EML:
Control and coordination of a subset of network elements on an individual

network element function basis
Control and coordination of a subset of network elements on a collective basis
Maintenance of statistical, log, and other data about the elements within its scope
of control
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
70 / 652
5.1.1.7
Network Element Layer
The network element layer (NEL) is where the physical network elements (NEs) are
represented.
The network elements to be managed consist of layer 2-7 switches, edge routers,
firewalls / VPN gateway, and WebCache.
5.1.1.8
Related information
Refer to: ITU-T M.3400.
5.1.2 TMN MODEL IN THE 9471 WMM ARCHITECTURE

This topic describes the high-level Telecommunication Management Network (TMN)
architecture in the 9471 WMM.
5.1.2.1
Layers
Layers in the High-level Architecture:
Network Management Layer (NML)
Element Management Layer (EML)
Network Element Layer (NEL)
Sub-Network Element Layer (SNEL).
5.1.2.2
NML Systems
Systems within the NML:
Network management systems - Network management on the 9471 WMM is

performed via the Simple Network Management Protocol (SNMP) or the
Hypertext Transfer Protocol (HTTP) connection to the Management Interface
(MI)-agent.
5.1.2.3
EML Elements
Elements within the Element Management Layer (EML):
5620 SAM (see Section 5.1.4)
5.1.2.4
NEL Elements
Elements within the NEL:
Issue 11.01
9471 WMM
Note: The 9471 WMM is considered as one network element.
LTE/DCL/APP/031094
Nokia 2016
71 / 652
5.1.2.5
SNEL Elements
SNEL elements are:
9471 WMM sub-components (for example, OAM servers, MIF servers, MAF
servers, hubs, etc.)
5.1.2.6
MI-Agent
The MI-Agent acts as one point of contact for the FCAPS operations. The MI-Agent GUI
(GUI) is web-browser based.
Functions which can be performed on the MI-Agent are:
Fault management
Configuration management
Performance management
Security management.
Please refer to Section 5.1.5.1 for more detailed information.
5.1.2.7
Northbound Interfaces
The Northbound interface (NBI) to the element management system (5620 SAM) is set
up during system installation. Starting in WMM9.1.0 release MME supports both IPv4
and IPv6 transport simultaneously for both the Northbound interfaces and is able to add
IPv6 addresses for the following without interruption to traffic on IPv4 transport :
SNMPv3
SSH
SFTP
NETCONF
MI
Configuration Server (CNFG)
NTP
The MI-Agent provides SNMP and http interfaces to network management systems.
There are three SNMP versions available:
v1
v2c
v3
SNMPv3 is a further stage of the SNMP protocols and provides three important
services:
Issue 11.01
Authentication
Privacy
Access Control
LTE/DCL/APP/031094
Nokia 2016
72 / 652
5.1.2.8
Discovery for MI-Agent
The discovery feature on the MI-Agent discovers the Subnetwork Elements (SNEL) and
their components. The MI-Agent displays the logical view of the managed objects
whose presence is detected during discovery.
5.1.2.9
Access to SNES via MI-Agent
The MI-Agent provides the capability to access SNELs via:
Command-line interface (CLI)
Cut-through, which offers access to the GUI of the SNEL.
5.1.2.10
Netconf Protocol
The NETCONF protocol provides a provisioning interface between the MME and an
EMS (such as the SAM). The NETCONF protocol provides a mechanism from an EMS
to install, manipulate, and delete the configuration of the MME, and to request and
monitor activities. It can be used to provision parameters (individually and using bulk
provisioning).
Note: This functionality does not cover CALEA tables whose access is limited to
specific RBAC roles.
For additional information on the use of the SAM as the EMS for the MME, refer to:
5620 SAM LTE ePC User Guide.
5.1.2.11
Maintenance Terminal
The Maintenance Terminals (MTs) are used as:
Issue 11.01
MI-Agent GUI
Command Line Interface (CLI)
LTE/DCL/APP/031094
Nokia 2016
73 / 652
5.1.3 9471 WMM ATCA OAM&P ARCHITECTURE
5620
SAM
Alarms
Events
PM Trap Events
SNMPv3
sFTP
SSH
NETCONF
MME
WM9.1.0
OAM Server
MI-Agent
CLI
Field Install GUI
8950 ID GUI
Figure 5-2: 9471 WMM OAM&P Architecture
For the MME:
A Field Install GUI and System Configuration Data Tool (SCDT) are included in
the MME. Note that Nokia personnel use these tools for initial hardware
installation and configuration. The field install GUI is not used again after intial
installation. The following platform data and IP addresses are configured during
field install:
- system name
- shelf configuration
- time zone
- Internal IP addresses schema (fixed, floating)
- External IP address schema (fixed, floating)
- Association between external IP addresses and Service (MIF/MAF) and
logical interfaces (S6a, S11, etc.)
- OA&M network IP address
- DNS IP addresses
- DHCP
- NTP configuration
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
74 / 652
After initial configuration, the MME is provisioned via the 5620 SAM with application,
mobility management, and session management parameters.
See 5620 SAM LTE ePC User Guide, section 9471 WMM MME application
provisioning, for provisioning procedures.[R33]
The MI-Agent GUI is used for fault management, configuration management,

performance management, and security management.
The 8950 ID GUI is used for centralized login and password management.
Traps are sent to the 5620 SAM when a performance measurement file is
generated.
Users can log into the MME from 5620 SAM.
The MME network element includes the following user interfaces to perform OAM&P
activities:
MI-Agent GUI hosted on the OAM Server (including State/status and alarm
indicators on the MI-Agent).
Issue 11.01
8950 ID GUI
Command Line Interface (CLI) to each sub-network element.
5620 SAM GUI
LTE/DCL/APP/031094
Nokia 2016
75 / 652
5.1.4 5620 SAM
The 5620 SAM manages the Nokia eNodeBs as well as the Nokia LTE Evolved Packet
Core (ePC) network components. The ePC components include:
7750 Service Router (SR) when used as a PGW or SGW
5780 Dynamic Service Controller (DSC) used as the PCRF
MME component of 9471 WMM.
The 5620 SAM provides element, network, and service management, including:
network and service provisioning and scripting - point and click end-to-end
service provisioning
[Benefit: rapid, repeatable, simple, no mistakes reduces drop outs]
Network and service assurance - problem detection, isolation, and prevention

[Benefit: quick, graphical identification of root cause. Customer problems solved
faster due to troubleshooting time savings]
OSS integration - [Benefit: timely, low cost integration to existing OSS systems
and portals]
network-operations process streamlining - provides a pre-configured toolbox for

troubleshooting
[Benefit: network commission automation and assurance reduces steps and risk
of errors]
NETCONF
Figure 5-3: 5620 SAM Functionality
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
76 / 652
5620 SAM functions supported by the MME:
The MME forwards alarm and event traps to 5620 SAM using SNMPv3 interface
for centralized monitoring of the network. The 5620 SAM GUI supports listing all
the Alarms, clearing all, or a subset of alarms, and turning ON, or suppressing,
alarms by severity or type. Alarm management also will continue to be supported
locally at the MI-Agent.
Performs state/status queries of MME managed objects
Provision MME based parameters individually or using bulk provisioning
Request MME capacity data
Monitor inter/intra MME UE relocation activities
Users can cut-through to the MI-Agent GUI or the OAM Server CLI from the 5620
SAM using a Secure Shell interface. This allows users to perform tasks remotely
using the MI-Agent GUI and MME CLIs.
Performance files may be sent from the MME to 5620 SAM.
Performance measurements are supported such that an SNMP trap is sent to the
5620 SAM when each new PM file is available. Data is written to an XML file and
an SNMPv3 trap is sent to the 5620 SAM EMS to notify that a file is available for
retrieval. Upon receipt of the trap, the 5620 SAM automatically retrieves and
stores the PM file from the MI. The PM data collected from the MME is also
viewable in both tabular and graphical forms using the 5620 SAM GUI.
Additionally, the MME writes local and remote IPv4 and IPv6 addresses and address
values into interface MOs (managed objects). An ascii name associated with the remote
end point is also included if available. The local and remote IP address (es) and the
remote end point name (if obtained) are then made available on the SNMPv3 interface
to the EMS along with the interface MO state information. Note that if multi-homing is
implemented, both local IP addresses are saved in the interface MO to support localend multi-homing. If the remote end point supports multi-homing, both the remote end
point IP addresses (or the first two remote end point addresses learned) are also
recorded for the interface MO instance.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
77 / 652
5.1.4.1
MME Provisioning with SAM GUI
Initial provisioning of the MME functionality is performed from an XML configuration file
and XML interface / XML provisioning, which is loaded into the WMM.The XML file is
manually built and loaded into the WMM by Nokia personnel. This creates the WMM
Instance. WMM instances are displayed in the 9471 WMM Instances table. To view to
9471 WMM Instances form, select Manage -> Mobile Core -> WMM Instances from the
5620 SAM main menu.
Once the 9471 WMM has been loaded with data using the XML file, Netconf and the
5620 SAM are used to update provisioning data such as:
parameters that define the identity of an WMM
parameters that control the operation of logical operational interfaces
threshold values that are used to define Alarm conditions
Note that the list of eNodeBs that communicate with the 9471 WMM is dynamically
learned by the 9471 WMM from S1-MME messages, and is not part of the provisioned
data.
5.1.4.1.1 MME PROVISIONING SEQUENCE

When populating tables to provision the MME functionality, data must initially be
entered in a specific order for predictable results. All provisioning dependencies are
repeated throughout the document as rules (Rules: in blue boxes) in the
corresponding section for individual parameter provisioning. The provisioning sequence
consists of a set of required provisioning followed by provisioning for optional interfaces
and provisioning for optional functionality. For optional interfaces and optional
functionality, provisioning steps only need to be followed for the interfaces and
functionality used in the network. Please note that the following sections present a high
level view of MME provisioning. Consult the 5620 SAM LTE ePC User Guide for
detailed provisioning information.[R33]
5.1.4.1.1.1 REQUIRED PROVISIONING

The following provides provisioning order rules for required provisioning.
1. Set up PLMN for local MME.
2. Create an MME pool.
3. Assign the local (home) MME to an MME pool.
4. Lock the MME Aggregate Services. Put the MME Aggregate Service in the
locked state to prevent other nodes from attempting services from this MME
before provisioning is complete.
5. Define the Tracking Areas.
6. Associate the Tracking Areas within the home MME Group.
7. Define the S6a (HSS) connection data.
8. Define the S1 connection data
9. Define the S11 (Serving Gateway) connection data by provisioning each SGW
IP address or using DNS to discover the SGW IP address.
10. Unlock the MME Aggregate Services. Put the MME Aggregate Service in the
unlocked state to make it available for serving user sessions.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
78 / 652
5.1.4.1.1.2 PROVISIONING OPTIONAL INTERFACES
The following sections provide provisioning steps required for provisioning optional
interfaces. An interface must be provisioned if communication with the associated
network element is desired.
The WMM supports both 2G/3G (SGSN) and LTE (MME) functionality.
The following network interfaces are supported:
RS10: proprietary link between the MME and the WMM session restoration
server (SRS). The SRS is a standalone system. In the event that an MME in a
pool becomes isolated, the remaining MMEs in the pool can consult the SRS to
retrieve UE context data to complete procedures that were previously managed
by the unavailable MME, without requiring UEs to reattach.
Issue 11.01
S1-MME: link between the MME and the eNodeB that carries both the S1-AP
(Application Part) and Non-Access Stratum (NAS) signaling to/from the UE.
S3: link between the MME and the release 8 SGSN (S4-SGSN) that allows the MME
to support handovers between a 3GPP UMTS or GERAN network and an LTE
network. Eventually, S3 will replace Gn in the architecture. In WMM7.1, both S3 and
Gn are supported.
S4: interface between the SGSN and the SGW (similar to the S11 interface between
the MME and the SGW). In combo MME-SGSN configuration, the SGSN S4 interface
and the corresponding MME S11 interface can be configured to share the same local
IP address or to have separate local IP addresses.
S6a: link between the MME and the subscriber profile database (HSS) that allows
transfer of subscription and authentication data.
S6d: interface between the SGSN and the HSS in the S4SGSN network.
S10: a GTP tunnel connecting MMEs in the same or different MME pools. The tunnel
enables MME relocation and MME-to-MME information transfer.
S11: link between the MME and the SGW that supports session creation and deletion
procedures, including selection of SGW and PGW for a UE at the time of initial
attachment.
S13: link between the MME and the Equipment Identity Register (EIR) that enables
the UE Identity Check Procedure between the MME and the EIR.
SBc: link between the MME and the Cell Broadcast Center (CBC) that is used to
transport messages associated with the Warning Message Delivery function (CMAS).
SGs: link between the MME and the MSC/VLR that supports coordinating the location
of UEs that are IMSI attached to both EPS and non-EPS services and supports
relaying certain messages related to GSM circuit-switched services over the EPS
system via MME. The SGs link supports CSFB.
SLg: link between the MME and the Gateway Mobile Location Center (GMLC). The
interface supports transporting positioning requests and responses for Emergency
Location Services (LCS). The MME acts as a client to the GMLC.
SLs: link between the MME and the EPC-Serving Mobile Location Center (E-SMLC).
This interface is used in support of Emergency Location Services (LCS) to obtain a
UEs position.
LTE/DCL/APP/031094
Nokia 2016
79 / 652
Sm: link between the MME and the Multimedia Broadcast/Multicast Service (MBMS)
Gateway that transports Sm-AP messages to support signaling functions for MBMS
sessions.
Sv: link between the MME and the MSC server that supports UMTS hand down of
IMS-anchored voice sessions to the CS domain in the UTRAN/GERAN. The MME
provides SRVCC (Single Radio Voice Call Continuity) from the E-UTRAN to the
UTRAN/GERAN.
M3: link between MME and the Multicast Control Entity (MCE) in the eNB nodes that
transports M3-AP messages to support signaling functions for session management,
reset functionality and error indication functionality.
Gn-c: common link between the MME/SGSN and the pre-release 8 SGSN (Gn-Gp
SGSN) that allows the MME to support handovers between a 3GPP UMTS or GERAN
network and an LTE network. The Gn interface is the reference point between SGSN
and MME when S3 interface is not supported.
Gn-u: link between the 2G/3G SGSN and the GGSN.
Iu-PS: link between the 2G/3G SGSN and the RNC.
Gb: link between the 2G/3G SGSN and the BSC.
Gr: link between the 2G/3G SGSN and the HLR.
Gf: link between the 2G/3G SGSN and the EIR.
Ge: link between the 2G/3G SGSN and the SCP for CAMEL.
Gd: link between the 2G/3G SGSN and the SMS GW.
Gs: link between the 2G/3G SGSN and the MSC.
Ga: link between the 2G/3G SGSN and the CGF.
CALEA interfaces
X1_1: common link between the MME/SGSN and the Administrative Function (ADMF)
in the LIG.
X2: link between the MME and the DF2 in the LIG, and link between the SGSN and
the DF2 in the LIG. Different X2 encoding requires 2 physical links to the LIG. (Note:
this is not the X2 interface between eNBs.)
X3: link between the SGSN and the DF3 in the LIG.
North Bound Interface (NBI): link between the MME and the 5620 SAM. The NBI
supports NETCONF, SSH, SNMPv3.
Figure 4-2 on page 29 shows all MME interfaces and associated network elements.
Optional interfaces include: SGs, S3, Gn, S10, X1_1, X2, S13, SLs, SLg, SBc, M3, Sm,
Sv, and S102.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
80 / 652
5.1.4.1.1.2.1
SGS (INTERFACE TO 3G-MSC/VLR)
1.
Prerequisite: Local SGs interface IP address (es) must be configured. It can be

configured during MME Field Install (preferred) or the external subnet and
fixed/floating IP addresses can be configured manually using procedures
described in [R35].
2.
Define the SGs Interface data.
3.
Define MSC Server(s), LAI and TAI objects, and configure required mappings.
4. Review SGs-related default values (paging policy, timers, message and

retransmissions) and make any desired changes.
5.1.4.1.1.2.2
S3 (INTERFACE TO RELEASE 8 SGSNS (S4-SGSN))
1. Prerequisite: Local S3 interface IPv4 and/or IPv6 addresses must be

configured. They can be configured during MME Field Install (preferred) or the
external subnet and fixed/floating IP addresses can be configured manually
using procedures described in [R35].
2. Define the S3 Interface data.
3. Review S3-related default values (global parameters, timers) and make any
desired changes.
5.1.4.1.1.2.3
GN (INTERFACE TO PRE-RELEASE 8 SGSNS)
1. Prerequisite: Local Gn interface IP address must be configured. It can be

described in [R35].
2. Define Gn Interface data.
3. Review Gn-related default values (QoS Mapping, global parameters, timers)
and make any desired changes.
5.1.4.1.1.2.4
S10 (INTER-MME CONNECTIONS, MME POOLING)
1. Prerequisite: Local S10 interface IP addresses must be configured. They can

be configured during MME Field Install (preferred) or the external subnet and
described in the [R35].
2. Define the S10 connection data by provisioning each S10 IP address or using
DNS to discover the S10 IP addresses.
5.1.4.1.1.2.5
X1_1 AND X2 (LAWFUL INTERCEPT INTERFACES)
1. Note: This procedure is not supported by the 5620 SAM. The procedure must
be completed using the MME CLI. Please refer to the Command Line Interface
(CLI) Reference Guide and CALEA/LI Management [R29] for more information.
2.
Prerequisite: The MME local end X1_1 port and the MME local X2 interface port
are hard-coded. Contact Nokia MME support for CALEA/LI link management
and administration details.
3. Configure an interface profile for the X1_1 interface using the 5620 SAM.
4. Configure an interface profile for the X2 interface using the 5620 SAM.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
81 / 652
5. Provision the X1_1 configuration record.
6. li_link_cli command
7. Provision the X2 configuration record.
8. li_link_cli command
5.1.4.1.1.2.6
S13 (INTERFACE TO 1ST EIR)
Use this procedure when no S13 link is currently configured, and IMEI validation is not
turned on. (Note: IMEI validation is turned on by checking the Validate IMEI with EIR
checkbox on the PLMN form.)
described in [R35].
2. Create an SCTP Profile for the S13 interface.
3. Define the EIR IP address and port.
4. Define the S13 connection data.
5. Define the S13 interface data.
6. Verify S13 link operational status.
a. link_cli o query t s13 command
The S13 link associated with Destination IP 1 (defined on the Diameter
Connection form) should show the operational state set to Enable.
7. Turn on IMEI validation. Caution! Only execute this step if at least one S13 link
is enabled.
5.1.4.1.1.2.7
S13 (INTERFACE TO 2ND THROUGH 4TH EIRS)
Use this procedure when more than one EIR is required.

2. Define the S13 connection data.
a. link_cli o query t s13 command
The S13 link associated with Destination IP 1 (defined on the Diameter
Connection form) should show the operational state set to Enable.
5.1.4.1.1.2.8
S13 (CONVERTING FROM COMBINED S6A/S13 TO STANDALONE

S13)
Use this procedure when no S13 link is currently configured, and IMEI validation is
turned on.
described in [R35].
2. Turn off IMEI validation.
3. Create an SCTP Profile for the S13 interface.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
82 / 652
5. Define S13 connection data.
6. Define S13 interface data.
link_cli
o
query
t
s13
command
The S13 link associated with Destination IP 1 (defined on the Diameter Connection
form) should show the operational state set to Enable.
8. Turn on IMEI validation.
Caution! Only execute this step if at least one S13 link is enabled.
5.1.4.1.1.2.9
SLS (INTERFACE TO E-SMLC, FOR LOCATION-BASED SERVICES)
1. Prerequisite: Local SLs interface IP address(es) must be configured. It can be

described in the [R35].
2.
Define SLs interface data.
3. Define Remote End Point(s) and add/grow E-SMLC(s).

4. Associate E-SMLC with a TAI.
5. Review SLs-related default values (global parameters, timers) and make any
desired changes.
5.1.4.1.1.2.10 SLG (INTERFACE TO GMLC, FOR LOCATION-BASED SERVICES)
1. Prerequisite: Local SLg interface IP address(es) must be configured. It can be
described in [R35].
2.
Define SLg interface data.
3. Define Remote End Point(s) and add/grow GMLC(s). (Note: At least one GMLC
is required when using the SLg interface.)
4. Review SLg-related default values (timers) and make any desired changes.
5. Activate LCS. (Note: Only activate LCS after both SLs and SLg interfaces are
provisioned. Also refer to Section 5.1.4.1.1.14.15, IMS Emergency Services on
page 89 and Section 8.1.7.2, Location-Based Services on page 347 for more
information.)
5.1.4.1.1.2.11 SBC (INTERFACE TO CBC, FOR WARNING MESSAGE DELIVERY)
1. Prerequisite: Local SBc interface IP address(es) must be configured. It can be
described in [R35].
2. Define SBc Interface data.
3. Review SBc-related default values (timers) and make any desired changes.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
83 / 652
5.1.4.1.1.2.12 M3 (INTERFACE TO MULTICAST CONTROL ENTITY (MCE) IN THE
ENODEB NODES)
1. Prerequisite: Local M3 interface IP address(es) must be configured. It can be
described in [R35].
2. Define M3 Interface data.
3. Review M3-related default values (timers) and make any desired changes.
5.1.4.1.1.2.13 SM (INTERFACE TO MBMS OR EMBMS GATEWAY)
1. Prerequisite: Local Sm interface IP address must be configured. It can be
described in [R35].
2. Define Sm Interface data.
3. Review Sm-related default values (timers) and make any desired changes.
4. Activate MBMS. (Note: Only activate MBMS after both the M3 and Sm
interfaces are provisioned.)
5.1.4.1.1.2.14 SV (INTERFACE TO MSC SERVER, FOR SRVCC SUPPORT)
1.
Prerequisite: Local Sv interface IP address(es) must be configured. It can be

described in [R35].
2.
Define the Sv Interface data.
3.
Verify parameters necessary for SRVCC operation.
4.
Define MSC Server(s), and LAI objects, and configure required mappings.
5. Review Sv-related default values (global parameters) and make any desired
changes.
5.1.4.1.1.2.15 S102 (INTERFACE TO 1XCS IWS)
1.
Prerequisite: Local S102 interface IP address(es) must be configured. It can be

described in [R35].
2.
Define the S102 Interface data.
3.
Define MSC to IWS mapping, using MSC Server ID and 1xCS IWS IP address.
4.
Enable S102 services on the Service Agreement form.
5.
Define the S102 paging policy, when desired (paging policy, call priority paging
profile, S102 paging priority profile). Note: The paging policy for the Basic
paging type is used when an S102 policy is not defined.
6. Review S102-related default values (timers, message retransmissions) and

make any desired changes.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
84 / 652
5.1.4.1.1.2.16 SRS PROVISIONING
1.
Configure an RS10 interface profile
2.
Configure a restoration access object and add the SRS IP address
3. configure a restoration APN list object and add the APNs for which UE context
data is sent to the SRS
4.
Set the Support Session Restoration global parameter to Yes
5. Review SRS-related default values (SRS response timer) and make any desired
changes.
6.
Issue 11.01
Define the SRS paging policy (paging type = SxnRestoration)
LTE/DCL/APP/031094
Nokia 2016
85 / 652
5.1.4.1.1.3 PROVISIONING OPTIONAL FUNCTIONALITY
The following sections provide provisioning steps required for provisioning optional
functionality.
5.1.4.1.1.3.1
PAGING METHODS AND NEIGHBORS
The paging policy controls how UEs are paged when the network needs to
communicate with a UE that is in the EMM IDLE state. The paging policy specifies an
ordered sequence of paging methods, where each method defines a set of eNB to
page. The total number of page attempts can be adjusted by updating the TAI Neighbor
List (Section 6.6) or updating the total number of page attempts in the paging policy
(Section 8.1.31.8).
1. Review and adjust the paging policy. Please refer to Section 8.1.31.8 for
information regarding provisioned paging parameters.
2. Review and adjust TAI neighbor lists.
5.1.4.1.1.3.2
SGW DISCOVERY
The MME can be provisioned to discover SGWs using DNS by setting the Discover
SGW parameter to yes on the Global Parameters form. The alternative to discovery
is to manually provision all SGWs and associated TAIs. See Section 6.8 for details
regarding manual provisioning.
5.1.4.1.1.3.3
EQUIVALENT PLMNS
An equivalent PLMN is used by a UE for cell reselection across PLMNs. The equivalent
PLMNs are considered equal to the registered PLMN by the UE when performing PLMN
selection, cell selection, cell re-selection and handover. A list of up to 15 equivalent
PLMNs (networks) can be provisioned at the MME.
The equivalent PLMNs in the list are normally neighboring PLMNs with agreement of
cell selection/reselection and handovers. Equivalent PLMNs must also be in the
roaming agreement list.
5.1.4.1.1.3.4
ROAMING PLMNS
The UE is considered a roaming UE if the PLMN ID indicated by the IMSI of the UE

does not match the home PLMN ID of the MME.The MME supports a series of checks
when a roaming UE attempts to attach and perform tracking area updates to the
network. The checks are performed using the 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 roaming agreement table consists of a set of capabilities allowed
and restricted in the MMEs home network. Local MME provisioning overrides
parameters in the UEs subscription data.
1. Define a roaming PLMN.
2. Define an equivalent PLMN, if necessary.
3. Provision restricted TAIs, if necessary.
4. Provision restricted LAIs, if necessary.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
86 / 652
5.1.4.1.1.3.5
INSERT/DELETE TRACKING AREAS
Inserting tracking areas requires adding TAIs to the MME Based Tracking Area table. It
may also require adding entries to the MME Group to TAI List table, adding entries to
the Serving Gateway Pool to TAI List table, adding entries to the TAI to LAI Mapping
table, and adding entries to the UE Roaming TAI and LAI Restriction List table.
1. Create new Tracking Area. (Section 6.5)
2. Add TAI to MME Group. (Section 6.4.3)
3. Add TAI to SGW Pool. (Section 6.8.4)
4. If MME is configured for combined network support, define TAI to LAI
association. (Section 6.9.3)
5. If TAI is restricted, define restrictions. (Section 6.7)
Similarly, deleting a TAI requires removing all entries that reference the TAI in the
following tables: MME Group to TAI List table, TAI Neighbor List table, Serving Gateway
Pool to TAI List table, TAI to LAI Mapping table, and UE Roaming TAI and LAI
Restriction List table, and then deleting the TAI from the TAI table itself. (See Section
6.5.)
1. Ensure TAI to be deleted does not have any associated eNBs.
2. Delete all entries that reference the TAI to be deleted.
a. MME Based Tracking Area (Edit) form, TAI Neighbor List tab
b. MME Based Tracking Area (Edit) form, TAI to LAI Mapping tab
c.
MME Based Tracking Area (Edit) form, UE Roaming TAI and LAI
Restriction List tab
d. MME Based Tracking Area (Edit) form, MME Group to TAI List tab
e. MME Based Tracking Area (Edit) form, MME Zone Code tab
f. MME Based Tracking Area (Edit) form, Serving Gateway Pool to TAI List tab
3. Delete entry for TAI.
5.1.4.1.1.3.6
INSERT/DELETE SGW & SGW POOLS
Inserting an SGW requires adding a new entry to the Serving Gateway table, and may
also require updating the Serving Gateway Pool to TAI List table. (See Section 6.8.)
1. Configure SGW object.
2. Configure SGW pool to TAI list.
Similarly, deleting an SGW requires removing the entry in the Serving Gateway table,
and may also require updating the Serving Gateway Pool to TAI List table. (See Section
6.8.)
1. Find the S11 Link index for the SGW to be deleted and lock the SGW to
prevent use during deletion. Log on to the OA&M server as user lss and enter
the following commands:
a. link_cli o query t s11
b. Check the fs.log to find Link_Index for the SGW.
c.
Issue 11.01
link_cli o lock t s11 l <link_index>

LTE/DCL/APP/031094
Nokia 2016
87 / 652
2. Check members in SGW Pool. If this is the only SGW in the SGW pool, then
delete the SGW pool. Otherwise, do not delete the SGW pool.
3. Delete the SGW entry.
5.1.4.1.1.3.7
CHANGE LOCAL PORT FOR IN-SERVICE PROFILES
Changing the local port for an in-service profile requires defining a new SCTP profile
that specifies the correct port, and then updating the associated Interface Profile.
Additionally, if the original local port is no longer used by any Interface Profile, the
SCTP Profile should be deleted. (Refer to [R28].)
1. Create a new SCTP profile using the correct port for the interface type.
2. Update Interface Profile to use the new SCTP profile ID.
3. Delete old SCTP profile ID if it is not used by any other interfaces.
5.1.4.1.1.3.8
TIME ZONE PROVISIONING
eNB Time Zone: Individual eNBs may be provisioned to have a different time zone than
the MME. (See Section 6.3.7.) An eNB is assumed to be in the same time zone as the
MME unless an explicit entry is added/updated in the eNB table.
MME Time Zone: Note that provisioning MME time zone uses CLI commands.
1. Log on to the active MI as root.
2. Enter the following command to
tzconf_adm action show_timezone
find
the
3. Enter the following command to find the

tz_adm a list_country_code l <country name>
4. Enter the following command to find
tz_adm a list_tz_name n <country_code>
5. Enter
the
following
command
tz_adm a change t <time zone>
6. Enter
the
following
tz_adm a commit
command
to
the
current
time
zone:
country
code:
valid
time
zone:
the
time
zone:
valid
change
to
commit
the
change:
7. Switch the CNFG server twice to send the new time zone data to the diskless
blades.
Enter
the
following
command:
FScmd
switch
cnfg
Wait for the command to complete and enter the same command a second
time:
FScmd switch cnfg
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
88 / 652
5.1.4.1.1.3.9
EPS INTEGRITY PROTECTION ALGORITHM AND EPS

ENCRYPTION ALGORITHM
The EIA and EEA priorities may be updated by locking the MME aggregate service and
then changing the priorities in the respective EIA and EEA tables (Section 0). Note that
locking the MME aggregate service detaches all UEs. This procedure is serviceaffecting. The MME aggregate service can be locked and unlocked via CLI or via the
MME Instance form.
1. Lock the MME.
2. Change the desired Priority settings. (See Section 0.)
3. Unlock the MME.
5.1.4.1.1.3.10 IMSI RANGE
Defining the IMSI range requires completing the Remote End Point Configuration
form to define all HSS servers, and completing the IMSI to HSS Routing form for
each HSS server to define the mapping between IMSI Range and the HSS.
1. Define HSS Servers. (See Section 6.10.)
2. Define mapping between IMSI Range and HSS. (See Section 8.1.2.5.6.)
5.1.4.1.1.3.11 MME DISCOVERY
The MME can be provisioned to discover other MMEs using DNS by setting the
Discover MME parameter to yes on the Global Parameters form (Section 0). The
alternative to discovery is to manually provision all MMEs using the MME Node form.
See Section 6.3.
5.1.4.1.1.3.12 AUTOMATIC NEIGHBOR LIST GENERATION
The MME supports two global parameters that contribute to Enhanced Automated
Neighbor List Generation:
- Include Neighbor List in TAI List If set to True in the Global Parameters
form (default), then the MME includes the manually provisioned set of
Neighbor TAIs in the list of TAIs that is sent to the UE when the UE
registers at the MME (ATTACH ACCEPT or TAU ACCEPT). Note: this only
has an impact if the TAI Neighbor List is populated. If set to False, then
the MME only includes the Last Seen TAI in the list of TAIs that is sent to
the UE. When set to False, the TAI Neighbor List will only affect paging
when the LastSeenTAINBTAI paging method is used.
- Auto Add TAI to TAI List This Global Parameter can be set to Off, Basic
(default), or Enhanced.
- If set to Off, then the MME only includes the Last Seen Tracking Area in the
registered tracking area list sent to the UE when the UE registers at the
MME (ATTACH ACCEPT or TAU ACCEPT) .
- If set to Basic, then the MME adds the old Last Seen TAI to the TAI list that is
sent to the UE. Including the last two tracking areas where the UE has
been seen accounts for the case where cyclic movement between two
tracking areas is observed.
- If set to Enhanced, then the MME adds the old Last Seen TAI and the
previous old Last Seen TAI to the TAI list that is sent to the UE. Including
the last three tracking areas where the UE has been seen accounts for the
case where cyclic movement between three tracking areas is observed.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
89 / 652
Review default/current values related to controlling the list of registered tracking areas
sent to the UE in the ATTACH ACCEPT and TAU ACCEPT messages, and make any
desired changes. Please refer to Section 8.1.3 for more information.
5.1.4.1.1.3.13 NAS CAUSE CODE
The MME can be provisioned to use default NAS cause code values when sending
replies to the UE for access restriction cases, or individually provisioned NAS cause
code values can be used. Updates should be made to the Global Parameters form
(useMappedNAScodes, Use Mapped Diameter Codes, Send NAS RAN Cause on S11),
the Access Restriction to NAS Cause Mapping form and the Diameter Cause to NAS
Cause Mapping form, where appropriate. See Section 8.1.38.11 for more information.
1. To specify the NAS cause code a UE will receive for certain types of access
restrictions cases, set the useMappedNAScodes field to Yes. Note: since this
is a global parameter, all UEs with PLMNs listed in the Access Restriction to
NAS Cause Mapping table will use the mapped codes.
2. Specify PLMN and NAS Cause Codes for desired restriction types.
3. To specify the NAS cause codes to use for errors reported by the HSS and EIR
network elements, set the Use Mapped Diameter Codes field to Yes. Note:
since this is a global parameter, all UEs with PLMNs listed in the Diameter
Cause to NAS Cause Mapping table will use the mapped codes. (See Section
4. Specify PLMN and NAS Cause Codes for desired Diameter codes on the MME
DIAMETER Cause object.
5. To indicate that the MME should send NAS and RAN failure indication codes in
Private Extension IE on the S11 interface to the SGW, set the global parameter
Send NAS RAN Cause on S11 field to Yes.
6. To enable or disable the inclusion of 3GPP specified NAS or RAN failure
indication cause code in Delete Session Request, Delete Bearer Command,
Create Bearer Response and Update Bearer Response on S11 interface to
SGW, set the global parameter Send SGW 3GPP NAS or RAN Cause field to
Yes.
5.1.4.1.1.3.14 CONVERT IPV4 CONNECTIONS TO IPV6
Each interface (S10, S11, S6a, S1, S13) has a unique procedure for converting from
IPv4 to IPv6. This document explains when IPv6 addresses can be used as valid input
for a parameter. Please refer to 5620 SAM LTE ePC User Guide for detailed information
regarding conversion procedures.
5.1.4.1.1.3.15 IMS EMERGENCY SERVICES
The MME can be provisioned with emergency configuration data and UE access
restrictions, as well as mobility restrictions and overload restrictions for emergency
sessions. Updates should be made to the Emergency Profile and Emergency Digits
forms, as appropriate. Timer values and the PLMN form (Emergency Profile ID field)
should also be updated when IMS emergency services are used.
1. Configure Emergency Number Lists.
2. Configure Emergency Profile.
3. Set Timer values.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
90 / 652
4. Activate IMS Emergency Service by updating the Emergency Profile ID field
with the ID of a profile defined in step 2 above. (0 indicates no associated
emergency configuration data.)
5.1.4.1.1.3.16 LOCATION-BASED SERVICES
The MME is responsible for managing positioning requests for LCS. LCS requires
deployment of GMLC and E-SMLC. Additionally, eNB must support LPPa and ECID
(Enhanced Cell ID) positioning capability. The Initiate LCS Request parameter on the
Emergency Profile form is used to enable the feature.
Note: Only activate LCS after both SLs and SLg interfaces are provisioned. Also refer to
Section 5.1.4.1.1.14.15, IMS Emergency Services (above) and Section 8.1.7.2,
Location-Based Services on page 347 for more information.)
5.1.4.1.1.3.17 WARNING MESSAGE DELIVERY (CMAS)
CMAS allows warning messages to be sent to a UE in a particular area. An MME
receives warning messages from a Cell Broadcasting Center (CBC) using the SBc
interface, and the MME forwards these messages to the eNBs. CMAS support on the
eNodeB and Cell Broadcast Center is required. CMAS is enabled automatically when
SBc interface configuration is complete.
5.1.4.1.1.3.18 EMBMS
Multimedia Broadcast/Multicast Service (MBMS or eMBMS) is a broadcast service in
which data is transmitted from a single source entity to multiple recipients. The MME
provides for 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) in the eNB nodes.
Note: Only activate MBMS after both the M3 and Sm interfaces are provisioned.)
5.1.4.1.1.3.19 CSFB ENHANCEMENTS
CSFB was introduced in LM2.0 and allowed operators to specify if the network would
provide CSFB for voice and SMS to UEs with the corresponding Home PLMN. LM4.0
added support for provisioning CSFB for SMS-only and CSFB not preferred over the
SGs interface. This allows operators to deploy SMS service over the SGs interface
without having to deploy CSFB voice calls. The operator may specify the MME network
capability as no CSFB, CSFB for voice and SMS, or CSFB for SMS-only and may
also specify no CSFB, CSFB for voice and SMS, CSFB for SMS-only or CSFB not
preferred on a per-PLMN basis. Updates should be made to the PLMN form, where
appropriate. (See Section 6.11.)
1. Specify RFSP index values and circuit switch voice preference option.
2. Update Tracking Area Identity attributes. (Enable the IMS Supported parameter.)
3. Update Location Area Identity attributes. (Enable the Is CSFB Supported?
Parameter.)
4. Specify paging policies for UE paging triggered by SGs CS and SGs PS paging
(up to 4 attempts for each paging type).
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
91 / 652
5.1.4.1.1.3.20 SMS-ONLY OVER SGS INTERFACE
1. Indicate Circuit Switched Capability option to use for Home UEs and UEs that
roam into the MME Home Network by configuring PLMN parameters for CSFB.
(See Section 6.11.)
2. Update SMS-Only LAI fields, where necessary. Note: These fields are only
required if TAI-LAI Mapping is not used.
3. Specify MSC server.
4. Specify Remote End Point Configuration for SGs interface.
5. Specify paging policies for UE paging triggered by SGs CS and SGs PS paging
(up to 4 attempts for each paging type).
5.1.4.1.1.3.21 SRVCC MSC DISCOVERY
The MME can be provisioned to discover SRVCC MSCs using DNS by setting the
Discover SRVCC MSC parameter to yes on the Global Parameters form. The
alternative to discovery is to manually provision all SRVCC MSCs. See Section 6.9 for
details.
5.1.4.1.1.3.22 NETWORK SHARING
1. Set up Shared PLMN.
2. Set up Shared MME Node.
5.1.4.1.2 5620 SAM PROVISIONING GUI RULES

The system checks parameter ranges and duplicate key values (such as duplicate
MNC), but does not verify that dependencies are maintained.
Key fields, such as MCC and MNC, are grayed out and cannot be modified. You must
delete the entry and add it back if you really wish to change it.
If more than one user makes a change, the last change entered is the one used.
5.1.4.1.3 RELATED INFORMATION

See 5620 SAM LTE ePC User Guide for complete provisioning information.
See [R41] for complete 9471 WMM CLI and MI-Agent access and usage details.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
92 / 652
5.1.5 9471 WMM MME LOCAL OAM&P
The 9471 WMM network element includes the following user interfaces to perform
OAM&P activities:
MI-Agent (Section 5.1.5.1) GUI hosted on the OAM Server (including State/status
and alarm indicators on the MI-Agent (Section 9.3.2))
8950 ID GUI (Section 5.1.5.2)
Command Line Interface (Section 5.1.5.3) (CLI) to each sub-network element
5.1.5.1
MI-Agent
5.1.5.1.1 OVERVIEW
The Management Interface Agent (MI-Agent) remains the single point of contact for the
FCAPS maintenance operations.
OAM&P management functions provided by the MI-Agent include
Fault management
Configuration management
Performance management
Security management
NOTE: The MI-Agent does not perform accounting management tasks.
5.1.5.1.2 MI-AGENT GUI

The MI-Agent GUI can be invoked from the element management system (5620 SAM)
using secure http.
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 following 9471 WMM MME-specific functions can be performed from the MI-Agent:
Collect key measurement data specific to the MME and the LTE network. For
example:
- Failure-Percentage for UE access to the LTE network
- Number of successful attach requests
- Maximum and average number of Active and Idle UEs in the current
measurement period
- Average number of default bearers.

This document provides a high-level overview of the MI-Agent, but detailed access and
usage is outside the scope of this document.
Refer to [R35] for MI-Agent access and usage details.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
93 / 652
5.1.5.1.4 MI-AGENT USER ACCESS RULES AND TROUBLESHOOTING
Role-Based Access Control (RBAC) is used to manage user security
(access/authentication to perform certain tasks). 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, but note that
root is not a superuser.
If you have trouble performing specific tasks at the MI-Agent or the command line
interface, verify that the login you are using has appropriate permissions to perform the
task, and if necessary, consult your security or system administrator.
5.1.5.2
8950 ID GUI
The 8950 ID GUI manages CLI and GUI user accounts across all diskful and diskless
blades.
Administrator tasks include:
Create, modify, or delete user accounts
Lock or unlock user accounts
Modify pre-login banner text and message of the day.
Users can perform the following tasks for their own accounts:
Change password
View account settings and permissions
Upload SSH public keys.
If 8950 ID Identity GUI becomes inaccessible
The CLI can be used for the emergency access.
Passwords can be changed from the MI-Agent GUI or the CLI.

Refer to 9471 MME Security Management, 9YZ-05481-0003-USZZA for 8950 ID
Identity GUI access and usage details.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
94 / 652
5.1.5.2.2 8950 ID GUI SCREENS
Figure 5-4: 8950 ID GUI for Administrators
Figure 5-5: 8950 ID GUI for non-administrative users
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
95 / 652
5.1.5.3
Command Line Interface
Each of the 9471 WMM cards is a computer unto itself and can be logged on to at an
operating system (OS) level.
Card
OS
OAM Server
Red Hat Linux
Hubs
MontaVista Linux
ShMC
Pigeon Point Linux
Table 2: WMM Blade Operating Systems

Each host
observes standard OS files and directories.
executes application-specific commands.
can be used to view application-specific log files.
While the MI-Agent GUI is recommended for most tasks, many tasks can alternatively
be performed from the CLI, such as
Scheduling PM collection
Manual backups.
However, some tasks must be performed from the CLI, such as
Initial system installation and IP configuration
Hardware replacement
Software update
Emergency access when the MI-Agent is not available

Refer to [R35] for complete CLI access and usage details.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
96 / 652
5.1.5.3.2 USER ACCESS METHODS
You can access the CLI using the following methods. The access method depends on
the procedure; always follow the procedure indicated in the customer documentation:
From the MI-Agent, access the CLI of any sub-network element in the system.
The system logs into the OAM Server and runs an SSH session to the selected
element. This is used for more routine maintenance procedures.
From the 5620 SAM, open the WMM Properties window and click SSH.
Set up a Serial over LAN (SOL) connection (see Figure 5-6).

Log in remotely or at the faceplate of the Hub blade using the host IP address,
then from the Hub, set up a console session to the other blades using their SOL
IP addresses. This is used for remote access and special procedures such as
installation and software update.
Connect a terminal (laptop) directly to the debug fast Ethernet port or debug USB
port on the faceplate of the blade. This is typically only used for debugging.
Figure 5-6: SOL connection to hub faceplate
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
97 / 652
5.2 Fault Management and State Management
Critical Performance Indicator (CPI) thresholds are provisioned to identify the onset of
WMM or other network problems, and also to identify when alarm conditions exist.
Thresholds can be set for critical, major, and minor severities. If the provisioned
threshold is crossed, the MME application sends a trap to each IP address provisioned
for the Element Management System (EMS) and to the MI to alert it to the event
occurrence. CPI thresholds can be defined via the Critical Performance Indicator
Thresholds page on the provisioning web interface. Individual CPIs are defined by a
service (MIF or MAF) and an element within that service. A detailed description of
configuration procedures supported in WM9.1.0 can be found in the customer document
[R35].
The MI/EMS displays the trap as an alarm, as necessary. The WMM Alarms window
lists the severity, name, managed object ID, probable cause, specific problem, alarm
type, owner, and date/time for each alarm. Additionally, a customer document [R36] is
provided to define all supported alarms. The document includes a description, default
severity, root cause, and fault clearance procedure for each alarm.
An understanding of the MIB may also be helpful in determining a probable cause for an
alarm. Figure 5-7 shows the containment tree for WMM WM7.0.0 managed objects.
ITU-T X.731 specifies a standard for managing the state of a network element. This
standard is used in the management of state in the WMM. The Administrative state of a
Managed Object can take the values of locked, unlocked, or shutting down. The
Operational State of a Managed Object can take on the values Enabled or Disabled.
The Usage State of a Managed Object can take on the values of Idle, Active, or
Busy.
The set of application Managed Objects (MOs) used for WMM management include the
aggregate MIF and MAF Service Members, the WMM aggregate Service MO, and the
Interface MOs that represent the set of communications interfaces set up between the
WMM and specific endpoints. These endpoints and associated communications
interfaces are defined via the provisioning web interface.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
98 / 652
Figure 5-7: Containment Tree for WMM MOs

The MME provides a configuration management procedure to enable sending an SNMP
trap to an EMS when a Performance Measurement file is available for collection. The
MME must have a Northbound Interface configured and PM collection must be enabled.
A detailed description of configuration procedures supported in WM7.0.0 can be found
in the customer document [R35].
5.2.1 CPI THRESHOLDS

Several performance counters and service measurements are correlated to Critical
Performance Indicators (CPI). Each defined CPI can be provisioned with a threshold for
Critical, Major and Minor alarms. The threshold indicates a potential problem in the
WMM or network when the threshold is crossed. The WMM contains a fixed set of CPIs
that can be enabled or disabled. By default, all CPIs are enabled, populated with values
for all thresholds (Critical Alarm %, Major Alarm %, Minor Alarm %), and assigned a
default value for number of calculations required to generate a statistically valid failure
percentage (Minimum Number of Attempts). The failure rate for each CPI is calculated
every 5 minutes. An alarm threshold will not be crossed until the minimum number of
calculations is completed. All defaults can be changed, so the Critical Performance
Indicator Threshold form should be reviewed to determine whether or not the defaults
provide adequate performance. Updates should be made to the form as required.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
99 / 652
Figure 5-8: WMM Critical Performance Indicator Table (MAF AttachFailures Example)
At this time, the default values listed on the form are the recommended settings.
However, users are encouraged to review the form to ensure compatibility with their
network.
Parameter
SAM Table Name
CPI Service
Critical Performance Indicator (CPI)
OSS ID
ltemme.CPIProfileAbs.cPIService
Range & Unit
Fixed field
MIF or MAF
Issue 11.01
Impact of Change
No service impact.
Value
Field is fixed according to CPI.
LTE/DCL/APP/031094
Nokia 2016
100 / 652
Parameter
CPI Element
SAM Table Name
OSS ID
ltemme.CPIProfileAbs.cPIElement
Range & Unit
Fixed field
List of CPIs
Impact of Change
No service impact.
Value
Field is fixed according to defined WMM CPIs
Parameter
CPI Enabled
SAM Table Name
OSS ID
ltemme.CPIProfileAbs.cPIEnabled
Range & Unit
Boolean
True (checked) or False (unchecked)
Impact of Change
No service impact.
Value
Operator Dependent; default = True (CPI is enabled)
Parameter
Critical Alarm %
Major Alarm %
Minor Alarm %
SAM Table Name
OSS ID
ltemme.CPIProfileAbs.cPICritical
ltemme.CPIProfileAbs.cPIMajor
ltemme.CPIProfileAbs.cPIMinor
Range & Unit
Integer
[1..99]
Impact of Change
No service impact.
Value
Operator Dependent; see Table 3: CPI Alarm Thresholdsfor

defaults.
Parameter
Minimum Number of Attempts
SAM Table Name
OSS ID
ltemme.CPIProfileAbs.cPIMinAttempts
Range & Unit
Integer
[0..100]
Issue 11.01
Impact of Change
No service impact.
Value
CPI Element dependent; see Table 3: CPI Alarm Thresholdsfor

defaults.
LTE/DCL/APP/031094
Nokia 2016
101 / 652
CPI Element
Critical
Alarm %
Major
Alarm %
Minor
Alarm %
Min # of
Attempts
AttachFailures
15
10
100
AttachFailuresSysRelated
15
10
100
CreateDedicatedBearerFailures
15
10
100
DeactivateDedBearerFailures
15
10
100
EIRfailuresS13
10
100
ExtServiceReqFailuresSysRelated
15
10
100
ExtServiceRequestFailures
15
10
100
FailuresOverSGs
10
100
GTPcResponseTO_Gn
10
100
GTPcResponseTO_S10
10
100
GTPcResponseTO_S11
10
100
GTPcResponseTO_S3
10
100
GTPcResponseTO_Sv
10
100
HOfailuresFromGERANoverS3
10
100
HOfailuresFromUTRANoverS3
10
100
HOfailuresRAUto2G3GnewSgwOverS3
10
100
HOfailuresRAUto2G3GOverS3
15
10
100
HOfailuresRAUto2G3GsameSgwOverS3
10
100
HOFailuresTo3G2GOverGn
10
100
HofailurestoGERANoverS3
10
100
HOFailuresToLTEOverGn
10
100
HOfailurestoUTRANoverS3
10
100
HOwMMErelocFailures_atSource
10
100
HOwMMErelocFailures_atTarget
10
100
HOwNoRelocFailures
10
100
HOwSGWrelocFailures
10
100
HSSauthFailures
15
10
100
MAFCommunicationFailureRate
95
90
80
100
MBMSSessionStartM3FailureRate
15
10
100
MBMSSessionStartSmFailureRate
15
10
100
MBMSSessionStopM3FailureRate
15
10
100
MBMSSessionStopSmFailureRate
15
10
100
MBMSSessionUpdateM3FailureRate
15
10
100
MBMSSessionUpdateSmFailureRate
15
10
100
MMEUEcapacity
99
95
90
100
MobileTermLocRequestFailures
15
10
100
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
102 / 652
CPI Element
Critical
Alarm %
Major
Alarm %
Minor
Alarm %
Min # of
Attempts
NetwrkInducedLocRequestFailures
15
10
100
NoPSHOFailuresOverSv
10
100
PSHOFailuresOverSv
10
100
S1MMEconnFailures
15
100
S3TauFailures
15
10
100
S3TauFailuresInterSgw
15
10
100
S3TauFailuresIntraSgw
15
10
100
ServiceReqFailuresSysRelated
15
10
100
ServiceRequestFailures
15
10
100
StopWarnMsgDeliveryS1MMEFailureRate
15
10
100
StopWarnMsgDeliverySBcFailureRate
15
10
TauFailures
15
10
100
TauFailuresInterMme
15
10
100
TauFailuresInterMmeInterSgw
15
10
100
TauFailuresInterSgw
15
10
100
UEauthFailures
15
10
100
UpdateBearerFailures
15
10
100
UpdateDedicatedBearerFailures
15
10
100
WarnMsgDeliveryS1MMEFailureRate
15
10
100
WarnMsgDeliverySBcFailureRate
15
10
Table 3: CPI Alarm Thresholds
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
103 / 652
5.2.2 PER CALL MEASUREMENT DATA (PCMD)
PCMD jobs are pre-defined. PCMD data collection is always enabled.
The collection of optional Cell Measurement data can be also configured
Please refer to Per Call Measurement Data Reference Guide (9YZ-06010-0015RKZZA) for the primary PCMD records in WM9.1.0.
Figure 5-9: WMM per Call Measurement Data Table (Example)
Parameter
Enable CM Report
SAM Table Name
Per Call Measurement Data (PCMD)
OSS ID
ltemme.PCMDConfigAbs.enableCMReport
Range & Unit
Boolean
Impact of Change
No service impact.
Value
Operator Dependent; default = True (eNB per-cell

measurement reports are included in PCMD records)
MME provides the ability to capture RRC connection establishment failures reason and
count in PCMD to troubleshout accessibility issues on a per IMSI basis or do analysis
on handsets to identify make/model performance compared to other device types.
Successful RRC connection setups and failed RRC Connection Setups are pegged on
the eNB and sent to MME in the S1AP message.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
104 / 652
5.2.3 CALL TRACE
WMM supports Call Trace on the S1MME, S3, S6a, S11, Sv, Gn, S10, S102, SGs,
S13, SLs, SLg. Up to 40 Call Trace sessions can be started on the WMM concurrently.
Call trace can be started, stopped, and queried from the 5620 SAM. All call trace output
is stored locally on the WMM in the protocolmonitor.log file in the /export/home/lss/logs
directory of the OA&M server. Additionally, call trace files on a per-IMSI basis are stored
in the /storage/calltrace/stopped directory. These files are in pcap format and can be
viewed using Wireshark.
The WMM is provisioned with a field to indicate whether or not Call Trace should
continue when a MAF is in a Major or Critical Overload condition. The Global
Parameters form provides a default value of do not continue, but the form should be
reviewed to determine whether or not the default value provides adequate performance.
Updates should be made to the form as required.
Parameter
OC Call Trace Continue
SAM Table Name
Global Parameters
OSS ID
Range & Unit
gParmName
String
OC_Call_Trace_Continue
gParmValue
Boolean
Yes (continue) or No (suspend)
Issue 11.01
Impact of Change
No service impact.
Value
Operator Dependent; default = No (suspend)
LTE/DCL/APP/031094
Nokia 2016
105 / 652
5.2.4 HSS INITIATED CALL TRACE
Starting in WM8.0.0 and later releases, trace session activation is introduced from HSS.
HSS indicates to the MME that a call trace for a given UE must be initiated or
terminated.
In contrast to Management Activation of Call Trace, the HSS initiated call trace
parameters are configured in the HSS, passed to the MME, and propagated from the
MME to the SGW (over S11) and to the eNodeB (over S1-mme) and between MMEs
(over S10). Figure 5 10: summarizes the Trace Session activation procedure in ePC
EMS
MME
HSS
SGW
eNodeB
PGW
UE
Trace Session Activation

Attach_Request
Storing Trace Control &
Configuration
Attach_Request
Update Location Request

Update Location Answer
Configuration Parameters
Starting Trace Session
Create Session Request

Create Session Request

Create Session Response

Create Session Response
Initial Context Setup Request
Figure 5-10: Trace Session activation procedure in ePC :
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
106 / 652
HSS-initiated Call trace provides the capability of network-wide tracing with UE mobility
including UELB operations.
Support for HSS-initiated call trace complies with 3GPP TS 32.422 Rel-11 Dec 2012.
When the HSS activates the trace to the MME, the following trace control and
configuration parameters are included in the message:
o
o
o
o
o
IMSI or IMEISV
Trace Reference
Triggering events for MME, Serving GW, PDN GW
List of NE types to trace: The list of the NEs includes serving GW,
PDN GW, and eNB
List of interfaces for the MME, serving GW, PDN GW, and eNB.
The following interfaces are supported in WMM8.0 : S1mme, S10,
S11, S13. Interfaces specified for other NEs in the trace are not
impacted.
IP address of Trace Collection Entity.
The HSS-Initiated call trace is activated via the global parameter HSS Initiated Call
Trace
Parameter
SAM Table Name
OSS ID
Range & Unit
HSS Initiated Call Trace

Global Parameters
gParmName
String
OC_Call_Trace_Continue
gParmValue
Boolean
Yes (continue) or No (suspend)
Issue 11.01
Impact of Change
No service impact.
Value
Operator Dependent; default = No (suspend)
Feature
m10501-08
LTE/DCL/APP/031094
Nokia 2016
107 / 652
The HSS propagates the trace control and configuration data to the MME by including
the trace control and configuration parameters into the S6a-Update Location Answer
or the S6a-Insert subscriber data messages.
o
During inter-MME TAU, the MME propagates the trace control and configuration
parameters to the target MME within an S10- Context Response as part of interMME TAU procedures.
During attach procedures where the context information is requested from the
target MME, the MME propagates the trace control and configuration parameters
within an S10-Identification Response message.
During inter-MME handover, the MME propagates the trace control and
configuration parameters to the target MME within an S10- Forward Relocation
Request message as part of inter-MME handover procedures.
If the SGW is in the list of NEs to trace then the MME activates the trace to the SGW.
Also, when a HSS-initiated trace recording session is started and the list of NE types
parameter requires eNB tracing, MME propagate the trace control and configuration
parameters including the Trace Recording Session Reference via the S1 interface to
the eNodeB per one of the following messages:
1. if an S1 connection exists, via the S1-Trace Start message
2. if the S1 connection does not exist, via the S1-Trace Start message prior to
S1 connection setup, or via the S1-Initial Context Setup Request message
during S1 connection setup
3. during intra/inter-MME handover over S1, via the S1-Handover Request
message
In above cases the Trace Session and the Trace Recording Session in the receiving NE
start at the same time
If all events are set in the triggering event parameter at the MME, MME sends Trace
Session Activation message to eNB not only when the MME starts the Trace Recording
Session, but also when an Intra-MME handover happens. In this case the MME sends
Trace Session activation to the target eNB via the S1-Handover Request message.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
108 / 652
5.2.4.1
ePC deactivation mechanisms
When an HSS receives a Trace Session Deactivation from the Management System it
sends an S6a-Delete Subscriber Data Request message to the to remove the trace
data from subscription data ( 3GPP TS 29.272).
The HSS deactivates trace session record if trace is active at the HSS.
When the MME receives the S6a-Delete Subscriber Data Request message to remove
the trace data from subscription data (see 3GPP TS 29.272 )or the Trace Session is
deactivated directly from the EM it shall deactivate the Trace Session identified by the
Trace Reference.
If the UE was registered to the HSS by an MME via the S6a interface, (i.e. the user is
attached to a 3GPP access network), the Trace Session shall be deactivated to the
MME via the S6a interface. A trace recording session can be stopped locally in the
MME but the trace session shall be deactivated only by the HSS. A stopped call trace
recording session does not affect the propagation of the trace session.
5.2.4.2
Interaction between HSS and on demand call traces
on the same IMSI
Because of the propagation of trace information it is required that at any point in time
there is only one active HSS initiated trace. TS32.422 specifies in section 4.2.3.6 that
there can only be one Trace Recording Session Reference per Trace Reference at one
given time for a UE trace session. So there shall be only one TR/TRSR to be
propagated during S1 and X2 handover.
HSS and EM initiated traces remain independent and its possible in the WMM8.0 to
have concurrent HSS and EM traces. Since the output of both traces is written to file it
is required that the files be clearly differentiated for the Trace collection element.
5.2.5 WMM OVERLOAD CONTROL

The mechanism of Overload Control is described in details in [R42]
5.2.5.1
Low Priority Access Overload Control
The MME provides in WM10.0.0 the following overload control mechanisms that are
described hereafter:
Issue 11.01
Reduce traffic from the low priority access UEs when MME is in overload by
supporting cause Reject new RRC connection requests from UE that access
network with low priority access in S1AP OVERLOAD START/STOP
messages.
Shedidng of LPA MM/SM procedure.
Throttling of DDN (Downlink Data Notification) requests.
LTE/DCL/APP/031094
Nokia 2016
109 / 652
5.2.5.1.1 LPA S1AP OVERLOAD CONTROL
In the event of MME overload caused by large amount of MTC traffic, the MME
indicates to the eNB to reject new RRC connection requests from UEs that access the
network with low priority access in S1AP Overload Start message so that eNB can use
access barring to prevent UEs to access the network.
Figure 5-11 Overload start/stop message to ENB

When LPA UE penetration is equal and above 30%, the MME sends overload start to
eNBs only if MIF or MPH or all MAFs entered in critical overload and if both Low
Priority Access and Overload Control Send Overload Start and Stop Messages to
eNBs global parameters are enabled . The global parameter Overload Control Send
Overload Start and Stop Messages to eNBs controlled the overload start/stop
mechanisms.
If both Low Priority Access and Overload Control Send Overload Start and Stop
Messages to eNBs global parameters are enabled, the MME sends S1AP Overload
Start messages to all eNBs with delayTolerantAccess action. After a set timer expired,
if the overload condition is still persistent, the MME send overload start message to
randomly selected eNBs asking them to throttle LPA traffic towards the MME (S1AP
cause reject only RRC connection establishment for delay tolerant traffic).
If the critical overload condition persists after 3 min. from the start of the action, or after
MME had sent overload start messages to all eNBs, the MME sends another overload
start message to randomly picked ENBs to throttle all traffic except emergency and high
priority traffic (S1AP cause reject RRC connection establishments for signalling (i.e.,
reject traffic corresponding to RRC cause mo-data, mo-signalling and
delayTolerantAccess).
If the OC Send Overload Start and Stop to eNBs is enabled and LPA global
parameters is disabled, MME send S1AP Overload Start messages to randomly picked
eNBs with Reject RRC connection establishments for non-emergency MO DT
overload action
When LPA UE penetration is below 30%, the existing overload control mechanism will
be applied.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
110 / 652
5.2.5.1.2 SHEDDING OF LPA MM/SM PROCEDURES (GENERAL NAS
MOBILITY MANAGEMENT AND SESSION MANAGEMENT
CONGESTION CONTROL)
If the percentage of LPA UE is equal and above 30% and the MME OC detects minor
overload, MME progressively shed the LPA UE procedures. MME sheds procedure for
regular UEs starting at major overload.
If the percentage of registered LPA UEs is above 70%, then MME will not shed
procedures for LPA UEs at minor overload, rather shed procedures for all UEs starting
major overload.
When the MME is declared in overload based on the rate of LPA UE requests
compared to the non-LPA UE, the MME reject LPA UE mobility mangamenet request
with EMM cause code as specified by the global parameter "MME Overload MM
Rejection NAS CC" ( default CC #22 ,congestion). The MME includes provisioned
T3346) "back-off" timer IE in the rejection message, which instructs the LPA UEs to
refrain from reattaching for the specified time interval.
If configured, MME also rejects following LPA UE SM requests with ESM cause code
#26 (insufficient resources) and start T3396 back-off timer.
PDN CONNECTIVITY REQUEST,
BEARER RESOURCE ALLOCATION REQUEST and
BEARER RESOURCE MODIFICATION REQUEST
The T3396 timer value to be used for an SM request rejection due to overload is
randomly assigned in the provisioned T3396 min range (15 seconds) and T3396 max
range (60 secdonds) of the new back-off timer introduced in WM10.0.0 release:
Issue 11.01
Displayed
Name
timerName
timerValue
(Range)
Default
Value
Purpose
T3396 Min
T3396 Min
0 600
seconds
15 seconds
The minimum value to

consider when randomly
assigning the T3396 timer
value.
T3396 Min
T3396 Min
0 600
seconds
15 seconds
The maximum value to

consider when randomly
value.
LTE/DCL/APP/031094
Nokia 2016
111 / 652
5.2.5.1.3 MME OVERLOAD CONTROL ENHANCEMENTS: THROTTLING
OF DDN (DOWNLINK DATA NOTIFICATION) REQUESTS.
MME provides a configuration option to indicate SGW to selectively reduce the DDN
messages for the low priority access UEs when MME is in overload to reduce the
network signaling traffic. MME can indicate to SGW in the DDN Acknowledge message
using the Data Notification Delay (Throttling Delay) IE and the DL low priority traffic
throttling IE. MME computes the throttling delay and throttling factor based on the DDN
arrival rate impact on the MME overload.
So, throttling delay and throttling rate may differ from SGW to SGW.
eNB
MME
S -GW
P -GW
start of MME overload

DL user plane packet
Downlink Data Notification
Paging
Downlink Data NotificationAck

( throttle 50% of low prio DL MTC traffic, for duration
T
)
DL user plane packet

During period T, if low prio traffic
throttle or send DDN msg according
to reduction factor
If no throttling
Downlink Data Notification

Downlink Data NotificationAck
Paging
service request procedure
Figure 5-12 Throttling of DDN storm

MME uses the ARP to determine the priority of the DDN messages. Low priority traffic
indication is determined by the ARP value received in the DDN message. The priority
level field of the ARP value is compared to the one provisioned under the global
parameter ARP Low access priority level to determine low priority traffic. Any priority
level that is equal or higher to the locally provisioned priority level is considered low
priority.
Parameter
SAM Table Name
OSS ID
Range & Unit
ARP Low Access Priority Level

Global Parameters
gParmName
gParmValue
Integer
1 - 15
Issue 11.01
Impact of Change
No service impact.
Value
Operator Dependent; default = 15
Feature
m10115-01
LTE/DCL/APP/031094
Nokia 2016
112 / 652
MME rejects the DDN request for low priority traffic for UEs in idle mode by sending
DDN Failure Indication with cause set to UE is not responding if MME is in critical
overload.
Two thresholds are set for the throttling of DDN storm; one for low priority DDN and one
for overall DDN.
If the global parameter Low priority traffic ddn throttling and low priority access are
both enabled, when the DDN rate coming from low priority UEs exceeds the LPA DDN
threshold, which is set lower than or equal to the overall threshold, MME sends DDN
NACK to SGW with throttling fraction to LPA UEs. The throttling fraction is only valid for
30 seconds.
Parameter
SAM Table Name
OSS ID
Range & Unit
Low Priority Traffic DDN Throttling

Global Parameters
gParmName
gParmValue
Boolean
Yes - No
Impact of Change
No service impact.
Value
Feature
m10115-01
When LPA DDN threshold is crossed, MME calculates a throttling percentage based on
fraction of LPAs in DDN. This percentage is sent as a throttling fraction to SGWs. The
throttling fraction is valid for 30 seconds.
Once MME recovers from LPA DDN storm, it does not send an updated throttling
fraction of 0, rather let the previously sent throttle fraction to expire (its validity period is
30 seconds).
MME computes the percentage of age of registered LPA UEs as follows:
Percentage of LPA registered UEs = (number of LPA registered UEs/number of
registered UEs) x 100, collected over a period of one hour.
Note that right after an init, the percentage of LPA is equal to 0 even when there are
LPA UEs attached to the MME. Only after one hour does MME get a positive measure
of percentage of LPA UEs
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
113 / 652
5.2.5.2
PCMD Overload Control
The WMM supports two global parameters. One allows the ability to discard PCMD
messages during overload conditions. A second parameter allows the service provider
the ability to configure an algorithm to shed (reject) a set of procedures during overload
conditions.
The PCMD Overload global parameter can be set to one of the following three values:
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. Please
note that the MME application 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. MME resumes all PCMD
operation 5 minutes after coming out of minor overload.
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. Please
note that the MME application 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. MME resumes all PCMD operation
5 minutes after coming out of major overload.
Parameter
PCMD Shedding During Overload
SAM Table Name
Global Parameters
OSS ID
gParmName
String
PCMD_Shedding_during_overload
Range & Unit
gParmValue
Choice List
Do not drop PCMD during Overload
Drop all PCMD in Minor Overload
Drop all PCMD in Major Overload
Issue 11.01
Impact of Change
No service impact.
Value
Operator Dependent; default = Do not drop PCMD during

Overload
LTE/DCL/APP/031094
Nokia 2016
114 / 652
The MME uses a default shedding algorithm (Reject Max Signaling Load First) to target
the messages associated with procedures that generate the highest signaling load. The
algorithm maximizes the impact of shedding and minimizes the number of procedures
aborted due to shedding. The service provider may select a different set of
messages/procedures to target at Major and Critical overload thresholds.
When the Reject Algorithm during Overload flag is set to Reject Idle User First, the
optional algorithm targets procedures used by idle users during Major Overload and
escalates to targeting procedures used by connected users during Critical Overload
Table 4 : Shedding/Reject Algorithmdefines the behavior for each reject algorithm.
Parameter
SAM Table Name
OSS ID
Reject Algorithm During Overload

Global Parameters
gParmName
String
Reject_Algorithm_during_overload
Range & Unit
gParmValue
Choice List
Reject Max Signaling Load First
Reject Idle User First
Issue 11.01
Impact of Change
No service impact.
Value
Operator Dependent; default = Reject Max Signaling Load First
LTE/DCL/APP/031094
Nokia 2016
115 / 652
Reject Max Signaling Load
First
Reject Idle User First
Shed/rejected during Major

Overload
Overload
Overload
Overload
Overload
Shed/rejected during Critical
Overload
Overload
Overload
Overload
Overload

Overload
Overload
Overload
Overload
Overload
Overload
Overload
Overload
Overload
Overload
Deactivate Dedicated
Bearer

Overload

Overload
PDN Connectivity

Overload
Overload
Overload

Overload
Overload
Overload
Inter RAT Handover with

Gn

Overload

Overload

UTRAN

Overload

Overload

GSM

Overload

Overload
Context Request

Overload
Not shed/rejected
Procedure Targeted
Attach
TAU
Service Request
Paging
SGs Paging
S1 Release
Detach
X2 Handover
Create Dedicated Bearer
Modify Bearer
PDN Disconnect
S1 Handover
Table 4 : Shedding/Reject Algorithm

A threshold can be provisioned to prevent sending excessive alarm upon failover or link
loss failure and limit the number of managed object informational alarms sent
northbound.
Once the MME crossed a certain threshold (100) of disabled links for a given link type
(S1, Gn, etc.) a critical alarm is raised to the SAM indicating excessive link failure.
Once the number of disabled links falls below the threshold (95) the alarm will be
cleared.
The onset threshold is 100 and the clear threshold is 95.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
116 / 652
5.3 Software Licensing
A license file is required as part of the installation.
Please refer to the HP c7000 Software and integration [R40] for Instructions in obtaining
and installing this license.
A license file must be generated from the Software License Manager (ASLM) corporate
license generator. The name of file must be license and installed in both OAM hosts
under the/storage/lic/ directory with file permission of at least readable by the root user
id.
Missing or invalid license for the application instance will result in an aggregate service
lock within 60 minutes of detection and a wmmLicenseKeyValidationError critical alarm
been raised to make aware of the condition. Once the aggregate service has been lock,
it has to be manually unlocked after installation of a valid license file.
When the licenses expiration date is approaching, minor, major, critical alarm will be
raised based on the expiration date. See alarm dictionary for severity and time interval
for the alarms. When the license expired, aggregate service lock will be enforced in 60
minutes.
Please contact Nokia Technical Support team or Sales team for assistance with
obtaining a license file from Nokia Software License Manager.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
117 / 652
6 MME NETWORK PROVISIONING

6.1 PLMN Identification
4096 PLMN values can be provisioned per WMM, one PLMN value for the WMM home
network plus a PLMN value for each network where the WMM has a roaming
agreement plus up to 15 equivalent PLMNs (Standalone MME only configuration). Note:
An equivalent PLMN is any PLMN declared (by the home network operator) as an
equivalent to the home PLMN. Equivalent PLMNs are treated the same as the home
PLMN regarding PLMN selection by UE. Equivalent PLMNs are generally (but not
always) owned by the home network that contains the home WMM.
The 5620 SAM also uses the term Mobile Region to refer to a PLMN. Each Mobile
Region is configured with a Region ID and Region name, and an indication of whether
or not it is used as a PLMN, in addition to the MCC and MNC. For 9471 WMM, the
Mobile Region must be used as a PLMN.
The Manage Mobile Regions/Public Land Mobile Networks (PLMNs) form is displayed
by selecting Manage -> Mobile Core -> Mobile Regions/Public Land Mobile Networks
(PLMNs) from the main menu. Once configured, Mobile Regions appear in the Mobile
Node Region List. The list is available from other provisioning forms whenever Mobile
Region selection is required.
Parameter
Region ID
SAM Table Name
Manage Mobile Regions/Public Land Mobile Network
OSS ID
lte.MobileNodeRegion.id
Range & Unit
Integer
[1..1024]
Impact of Change
No service impact.
Value
Parameter
Region Name
SAM Table Name
OSS ID
lte.MobileNodeRegion.regionString
Range & Unit
Alphanumeric string
Up to 10 characters
Issue 11.01
Impact of Change
No service impact.
Value
Operator Dependent; default = False
LTE/DCL/APP/031094
Nokia 2016
118 / 652
Parameter
Used as PLMN
SAM Table Name
OSS ID
lte.MobileNodeRegion.isPLMN
Range & Unit
Boolean
Enabled (checked) or Disabled (unchecked)
Impact of Change
Must be set to Enabled for MME.
Value
6.1.1 MOBILE COUNTRY CODE

The Mobile Country Code (MCC) is used in several forms. The MCC value is a
component in the PLMN as well as in the GUMMEI & TAI.
PLMN uniquely identifies a network. PLMN = <MCC> + <MNC>
GUMMEI uniquely identifies the MME. = <MCC> + <MNC> + <MMEGI> +

<MMEC>
TAI uniquely identifies the TAs. TAI = <MCC> + <MNC> + <TAC>
Parameter
Mobile Country Code
SAM Table Name
Manage Mobile Regions/Public Land Mobile Network, MME

Public Land Mobile Network
OSS ID
lte.MobileNodeRegion.mcc
Range & Unit
3-digit Integer
[000..999]
Impact of Change
No service impact.
Value
6.1.2 MOBILE NETWORK CODE

The Mobile Network Code (MNC) is used in several forms. The MNC value is a
component in the PLMN as well as in the GUMMEI & TAI. The GUMMEI and TAIs are
used to uniquely identify the MME and the TAs, respectively.
Parameter
Mobile Network Code
SAM Table Name
Manage Mobile Regions/Public Land Mobile Network, MME

OSS ID
lte.MobileNodeRegion.mnc
Range & Unit
Integer
[000..999]
Issue 11.01
Impact of Change
No service impact.
Value
LTE/DCL/APP/031094
Nokia 2016
119 / 652
6.1.3 PLMN
The following parameters are used to define the PLMN:
PLMN ID
SMS Only Pointer (See Section 6.11.16.1.4.)
Emergency Profile (See Section 8.1.7.1.)
Home PLMN (See Section 6.1.4.)
PLMN Type (See Section 6.1.4.)
Is Equivalent PLMN (See Section 6.1.4.)
Number of MNC Digits (See Section 6.1.7.)
ISDN Country Code (See Section 6.1.6.)
Obtain IMEISV (See Section 8.1.38.3.)
MBMS Enabled (See Section 0.)
CS RFSP (See Section 6.11.)
CS Preferred RFSP (See Section 6.11.)
IMS RFSP (See Section 6.11.)
IMS Preferred RFSP (See Section 6.11.)
Inter-Gateway Protocol (See Section 6.1.8.)
Initiate LCS Emergency (See Section 8.1.7.2.)
CS Capability Supported (See Section 6.11.)
Validate IMEI with EIR (See Section 8.1.38.3.)
NRI Length (See Section 8.1.2.5.5.1.)
SBc Enabled (See Section 8.1.7.3.)
QoS Profile for Visiting Roaming Subscribers: QCI, ARP, Maximum Bit Rate Up
(kbps), Maximum Bit Rate Down (kbps) (See Section 6.1.13.)
Issue 11.01
MCC (See Section 6.1.1.)
MNC (See Section 6.1.2.)
Honor VPLMN Requests (See Section 6.1.5.)
RFSP Index (See Section 6.1.5)
Network Access Mode (See Section 6.1.5.)
All APN (See Section 6.1.9.)
VPLMN APN (See Section 6.1.9.)
HPLMN APN (See Section 6.1.9.)
GERAN (See Section 6.1.10.)
UTRAN (See Section 6.1.10.)
CDMA2000 (See Section 6.1.10.)
EUTRAN (See Section 6.1.10.)
IMS Voice Over PS (See Section 6.1.11.)
CSFB DTR (See Section 6.1.11.)
Remote Endpoint IP 1 (See Section 6.1.12.)
Remote Endpoint IP 2 (See Section 6.1.12.)
LTE/DCL/APP/031094
Nokia 2016
120 / 652
6.1.4 HOME AND EQUIVALENT PLMNS
The home PLMN is the network where the WMM resides. The definition of the Home
PLMN does not include any Roaming parameters listed in Section 6.1.3. The home
PLMN is identified by setting the Home PLMN parameter equal to True and the PLMN
Type parameter equal to Home Network in the Public Land Mobile Network form.
WM10.0.0 allows one PLMN value for the WMM home network plus up to 15 equivalent
PLMNs.
Note: An equivalent PLMN is any PLMN declared (by the home network operator) as an
equivalent to the home PLMN. Equivalent PLMNs are treated the same as the home
PLMN regarding PLMN selection by UE. Equivalent PLMNs are generally (but not
always) owned by the home network that contains the home WMM.
Parameter
Home PLMN
SAM Table Name
OSS ID
ltemme.MMEPLMN.homePLMN
Range & Unit
Boolean
Impact of Change
No service impact.
Value
Parameter
PLMN Type
SAM Table Name
Public Land Mobile Network (PLMN)
OSS ID
ltemme.MMEPLMNAbs.pLMNType
Choice List
Range & Unit
Home Network
Shared Network
Other Network
Impact of Change
No service impact.
Value
Operator Dependent; default = Other Network
Parameter
Is Equivalent PLMN
SAM Table Name
MME Public Land Mobile Network
OSS ID
ltemme.MMEPLMN.isEquivalentPLMN
Range & Unit
Boolean
Issue 11.01
Impact of Change
No service impact.
Value
Operator Dependent; default = false (unchecked)
LTE/DCL/APP/031094
Nokia 2016
121 / 652
Rule: Provisioning Sequence Dependency

The home PLMN must be provisioned prior to provisioning the WMM Node.
Rule: Home PLMN

The WMM can have one (and only one) home PLMN.
Rule: PLMN Maximum for WM10.0.0

The home WMM can be provisioned with up to 4096 PLMN values (including the
home PLMN, roaming PLMNs, and equivalent PLMNs).
These values include 1 PLMN for the WMM home network, up to 15 equivalent
PLMNs, and 1 PLMN value for each network where the WMM has a roaming
agreement.
Rule: Equivalent PLMN

A maximum of 15 equivalent PLMNs may be defined per Home and shared
PLMN.An equivalent PLMN is defined by an MCC value together with an MNC
value.
Rule: Equivalent PLMN

A maximum of 135 equivalents PLMNs may be defined. ( 1 home PLMN + 8
shared PLMNs x 15 equivalent PLMNs )*
Rule: Equivalent PLMNs

An equivalent PLMN must also be in the roaming agreement list.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
122 / 652
6.1.5 ROAMING PLMN
WM10.0.0 release allows a total of up to 4096 PLMN values per WMM, one PLMN
value for the WMM home network plus a PLMN value for each network where the WMM
has a roaming agreement plus up to 15 equivalent PLMNs.
The Roaming PLMN itself is identified with the parameters defined in Section 6.1.3
above. The Roaming PLMN includes parameters used to describe roaming
characteristics that should be reviewed to determine whether or not they are consistent
with the network. Updates should be made to the form as required.
The Honor VPLMN Dynamic Address Allowed Request parameter indicates whether a
UE is allowed to select a PGW in its Home Network to reach the given APN or whether
a PGW in the visited network is allowed. If the Honor VPLMN Requests parameter is
set to True, then the UE is allowed to use a PGW in the current visited network to reach
the given APN. If the parameter is set to False, then the PGW must be selected from
the UE Home PLMN.
Parameter
Honor VPLMN Requests
SAM Table Name
Public Land Mobile Network (PLMN), UE PLMN Services
OSS ID
ltemme.SVCAgreementProfile.vPLMN_Allowed
ltemme.UEPLMNServices.vPLMN_Allowed
Range & Unit
Boolean
Impact of Change
No service impact.
Value
Operator Dependent; default = True (VPLMN request is

allowed)
The RAT Frequency Selection Priority (RFSP) ID is received from the HSS in the UE
home PLMN via S6a. This HSS RFSP can be used as the RFSP Index or the it can be
overridden using the provisioned RFSP Index on a per UE PLMN basis.
The WMM forwards the RFSP Index to the eNB across the S1-MME interface via the
Subscriber Profile ID For RAT Frequency Priority IE (aka SPID). The eNB uses the
RFSP Index to apply specific RRM strategies to all the radio bearers of a UE.
*note : the maximum number of equivalent PLMNs is per Serving (home or shared)
PLMN. Since there is one home PLMN and up to 8 shared PLMNs, there can be up to
9 Serving PLMNs and a maximum of 9X15=135 equivalent PLMNs.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
123 / 652
Parameter
RFSP Index
SAM Table
Name
UE PLMN Services,
UE PLMN and Served PLMN Service Agreement Profile
OSS ID
ltemme. SVCAgreementProfile.rFSP_Index
ltemme.UEPLMNServicesAbs.rFSP_Index
Range & Unit
Integer
[0..256], where 0 indicates the HSS in the UE home PLMN
provides the value.
Impact of
Change
No service impact.
Operator Dependent; default =
0 for ltemme.SVCAgreementProfile.rFSP_Index
Value
100 for ltemme.UEPLMNServicesAbs.rFSP_Index
The Network Access Mode is used to specify the type of access allowed for UEs that
roam into the WMM Home PLMN. This value overrides the subscription data of the UE.
Parameter
Network Access Mode
SAM Table Name
UE PLMN Services,
OSS ID
ltemme.SVCAgreementProfile.networkAccessMode
ltemme.UEPLMNServices.networkAccessMode
Range & Unit
Choice list
Packet and Circuit, Packet Only
Issue 11.01
Impact of Change
No service impact.
Value
Operator Dependent; default = Packet and Circuit
LTE/DCL/APP/031094
Nokia 2016
124 / 652
6.1.6 ISDN COUNTRY CODE
The ISDN Country Code parameter is actually the number of digits used to represent
the ISDN Country Code itself. It is used when validating the Zone Codes received from
the HSS. Zone Codes include a Country Code identifier.
Parameter
ISDN Country Code
SAM Table Name
OSS ID
ltemme.MMEPLMN.iSDN_CC
Range & Unit
Integer
[1..3]
Impact of Change
No service impact.
Value
Operator Dependent; default = 1 digit
6.1.7 MNC LENGTH

This parameter indicates the number of digits used to represent the Mobile Network
Code.
Parameter
SAM Table
Name
Number of MNC Digits
OSS ID
ltemme.MMEPLMN.mNCDigits
Range & Unit
Choice list
2 digits, 3 digits, or 2/3 digits (either 2 or 3 digits)

Impact of
Change
No service impact.
Value
Operator Dependent; defaults: 3 digits for the first entry of a

specific MCC. Default for additional entries equals the value
of the first entry.
Rule: MNC Digits Default

All MNCs within one MCC must have the same number of MNC digits. The default
value for MNC digits is 3 for the first entry of a specific MCC but the default value of
any additional entries equals the value defined for the first entry.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
125 / 652
6.1.8 INTER-GATEWAY PROTOCOL
This parameter indicates the protocol used in this network, specifically the protocol used
by the PGWs in the network. Please refer to Section 6.8.2 for information regarding
SGW Inter-Gateway Protocol.
Parameter
Inter-Gateway Protocol
SAM Table Name
OSS ID
ltemme.MMEPLMN. pLMNNetProtocol
Range & Unit
Choice list
GTP or PMIP
Impact of Change
No service impact.
Value
Operator Dependent; default = GTP
Rule: Inter-Gateway Protocol

Each PLMN uses the protocol used by the PGWs in that PLMN. The SGW is
selected so it supports the PGW protocol. A mismatch between PGW and SGW
protocols results in a failure to establish a UE bearer path between SGW & PGW.
Rule: Inter-Gateway Protocol for Roaming PLMNs

This parameter is not used to define the inter-gateway protocol for roaming PLMNs.
The protocol for each PLMN is defined by the individual PLMN.
6.1.9 OPERATOR DETERMINED BARRING SUPPORTED

The All APN parameter specifies whether or not the Operator Determined Barring of all
Packet Oriented Services (ODB-all-APN) feature is Enabled or Disabled for UEs that
roam into the WMM Home Network. If ODB-all-APN is Enabled, then the WMM sets the
corresponding bits in the Supported-features IE to inform the HSS that the WMM will
enforce ODB barring restrictions received in a ULA or IDR message. If ODB-all-APN is
Disabled, then the WMM will not set the corresponding bits in the Supported-features IE
sent to the HSS in the ULR and IDA message, and the HSS must handle barring locally.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
126 / 652
Parameter
All APN
SAM Table Name
OSS ID
ltemme.SVCAgreementProfile.oDB_All_APN
ltemme.UEPLMNServices.oDB_All_APN
Range & Unit
Boolean
Impact of Change
No service impact.
Value
Operator Dependent; default = Enabled (WMM enforces ODB

barring restrictions)
The HPLMN APN parameter specifies whether or not the Operator Determined Barring
of all Packet Oriented Services within the UE Home PLMN (ODB-HPLMN-APN) feature
is Enabled or Disabled for UEs that roam into the WMM Home Network. If ODBHPLMN-APN is enabled, then the WMM sets the corresponding bits in the Supportedfeatures IE to inform the HSS that the WMM will enforce ODB barring restrictions
received in a ULA or IDR message. If ODB-HPLMN-APN is Disabled, then the WMM
will not set the corresponding bits in the Supported-features IE sent to the HSS in the
ULR and IDA message, and the HSS must handle barring locally.
Parameter
HPLMN APN
SAM Table Name
OSS ID
ltemme. SVCAgreementProfile.oDB_HPLMN_APN
ltemme.UEPLMNServicesAbs.oDB_HPLMN_APN
Boolean
Range & Unit

Impact of Change
No service impact.
Value

The VPLMN APN parameter specifies whether or not the Operator Determined Barring
of all Packet Oriented Services within the WMM Home PLMN (ODB-VPLMN-APN)
feature is Enabled or Disabled for UEs that roam into the WMM Home Network. If ODBVPLMN-APN is Enabled, then the WMM sets the corresponding bits in the Supportedfeatures IE to inform the HSS that the WMM will enforce ODB barring restrictions
received in a ULA or IDR message. If ODB-VPLMN-APN is Disabled, then the WMM
will not set the corresponding bits in the Supported-features IE sent to the HSS in the
ULR and IDA message, and the HSS must handle barring locally.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
127 / 652
Parameter
VPLMN APN
SAM Table Name
OSS ID
ltemme. SVCAgreementProfile.oDB_VPLMN_APN
ltemme.UEPLMNServicesAbs.oDB_VPLMN_APN
Range & Unit
Boolean
Impact of Change
No service impact.
Value

6.1.10 ACCESS NOT ALLOWED

Each PLMN provisioned into the WMM (other than the WMM home network) is
provisioned with Access Restriction Data. The Access Restriction Data includes a list of
RAT network types that restrict handover from the current (Home) WMM network.
That is, handover of the provisioned RAT network types is forbidden from the WMM
home network.
Choices include any combination of GERAN, UTRAN, CDMA2000, EUTRAN. If no
network types are selected (no restrictions provisioned in the WMM), then inter-RAT
handover restrictions received from the HSS/HLR in the UE home network are used.
Otherwise, the selected value(s) over-ride the values received from the HSS/HLR in the
UE home network.
The WMM home network always has a value of none, and it is not possible to change
that value.
Parameter
CDMA2000, EUTRAN, GERAN, UTRAN
SAM Table Name
UE PLMN and Served PLMN Service

Agreement Profile (SVC Agreement Profile)
OSS ID
ltemme. SVCAgreementProfile.acc_Rest_CDMA2000
ltemme. SVCAgreementProfile.acc_Rest_EUTRAN
ltemme. SVCAgreementProfile.acc_Rest_GERAN
ltemme. SVCAgreementProfile.acc_Rest_UTRAN
ltemme.UEPLMNServicesAbs.acc_Rest_CDMA2000
ltemme.UEPLMNServicesAbs.acc_Rest_EUTRAN
ltemme.UEPLMNServicesAbs.acc_Rest_GERAN
ltemme.UEPLMNServicesAbs.acc_Rest_UTRAN
Range & Unit
Boolean
Access not Allowed (checked) or Access Allowed (unchecked)
Issue 11.01
Impact of Change
No service impact.
Value
Operator Dependent; default = None (Inter-RAT handover

restrictions received from the HSS/HLR in the UE home
network are used)
LTE/DCL/APP/031094
Nokia 2016
128 / 652
6.1.11 UE ROAMING ALLOWED
When a UE accesses the WMM home network, the HSS that serves the home network
of the UE provides subscription data that includes the list of services allowed to the UE
in its home network. The WMM can be provisioned to over-ride the subscription data
while the UE roams into the WMM home network. However, a service is allowed only if
the HSS subscription data from the home network of the UE AND the provisioning at
the UE home PLMN both allow the service.
The Roaming tab identifies the services that UEs can utilize when roaming into this
WMM Home Network from another network.
Parameter
IMS Voice Over PS
SAM Table Name
OSS ID
ltemme.SVCAgreementProfile.iMS_Over_PS
Range & Unit
Boolean
Impact of Change
No service impact.
Operator Dependent; default = True
Value
(IMS Voice Over PS is allowed)
Parameter
CSFB DTR
SAM Table Name
OSS ID
ltemme.SVCAgreementProfile.cSFB_DTR
Range & Unit
Boolean
Issue 11.01
Impact of Change
No service impact.
Value
Operator Dependent; default = True (CSFB DTR is allowed)
LTE/DCL/APP/031094
Nokia 2016
129 / 652
6.1.12 VPLMN HSS IP ADDRESSES
After provisioning the remote HSS end point using the Remote End Point Configuration
form (Section 6.10), the associated IP Identifier is provisioned in the HSS IP Addresses
tab. IP Id 1 is the ID number associated with the primary HSS in the roaming PLMN. IP
Id 2 is the secondary IP address. When multi-homing is used, each IP Id can be defined
with two IPv4 or IPv6 IP addresses.
Parameter
VPLMN HSS IP Id 1, VPLMN HSS IP Id 2
SAM Table Name
Select Remote Endpoint IP 1 - Public Land Mobile Network

Select Remote Endpoint IP 2 - Public Land Mobile Network
Also: Public Land Mobile Network
OSS ID
ltemme.MMERmtEndPtCfg.IP_1
ltemme.MMERmtEndPtCfg.IP_2
Range & Unit
Integer
[0..100], where 0 indicates IP ID is not used
IP Id must be previously defined in the Remote End Point
Configuration form
Impact of Change
No service impact.
Value
Operator Dependent; no defaults: IP Id 1 = 1, IP Id 2 = 0

The IP Identifier corresponding to the S6a interface must be provisioned in the
Remote End Point Configuration form prior to provisioning the HSS IP Addresses in
this PLMN form.
Rule: Maximum HSS Entities

The total number of unique HSS provisioned entities (including those provisioned for
roaming PLMNs, equivalent PLMNs, and the home PLMN) must not exceed 36.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
130 / 652
6.1.13 QOS PROFILE FOR VISITING ROAMING SUBSCRIBERS
The following parameters apply to PLMNs when the PLMN Type (Section 6.1.4) is set
to Home Network or Shared Network. The parameters define a default QoS profile
for roaming subscribers who are visiting the PLMN. If the subscription data obtained
from the roaming UEs HSS indicates a lower value (worse QoS) than the default QoS
profile, then the subscription value takes precedence.
QCI (QoS Class Identifier): indicates the best possible QoS value allowed for
roamer UEs.
ARP (Allocation/Retention Priority, Priority Level)
MaxBitRateUp (Aggregate Maximum Bit Rate (AMBR) Uplink): this limit applies
to UE-AMBR, not APM-AMBR.
MaxBitRateDown (Aggregate Maximum Bit Rate (AMBR) Downlink) ): this limit

applies to UE-AMBR, not APM-AMBR.
Parameter
QCI
SAM Table Name
Roaming QoS Profile
OSS ID
ltemme.MMEPLMNAbs.qCI
Range & Unit
Integer
[6..9]
Impact of Change
No service impact.
Value
Operator Dependent; Default = 6
Parameter
ARP
SAM Table Name
Roaming QoS Profile
OSS ID
ltemme.MMEPLMNAbs.aRP
Range & Unit
Integer
[1..15]
Issue 11.01
Impact of Change
No service impact.
Value
LTE/DCL/APP/031094
Nokia 2016
131 / 652
Parameter
Maximum Bit Rate Up (kbps)
SAM Table Name
Roaming QoS Profile
OSS ID
ltemme.MMEPLMNAbs.maxBitRateUp
Range & Unit
Integer
[0..63] kbps, in 1 kbps increments
Impact of Change
No service impact.
Value
Parameter
Maximum Bit Rate Down (kbps)
SAM Table Name
Roaming QoS Profile
OSS ID
ltemme.MMEPLMNAbs.maxBitRateDown
Range & Unit
Integer
Impact of Change
No service impact.
Value
6.1.14 QOS PROFILE FOR VISITING ROAMING SUBSCRIBERS

The Local Roamer QoS Policy can be enabled or disabled globally. When the Local
Roamer QoS Policy is disabled globally, the MME uses the QoS policies from the
roamers Home HSS subscriptions and/or Roamers Home PCRF/PGW. The global
parameter "Enable Local Roamer QoS Policy" must be enabled before enhanced Qos
profile is applied.
Parameter
SAM Table Name
Enable Local Roamer QoS Policy

Global Parameters
OSS ID
Range & Unit
gParmName
String
Enable_Local_Roamer_QoS_Policy
gParmValue
Boolean
Yes or No
Issue 11.01
Impact of Change
No service impact.
Value
Operator Dependent; default = Yes (enabled)
LTE/DCL/APP/031094
Nokia 2016
132 / 652
6.1.14.1.1 DEFAULT ROAMER POLICY FOR A ROAMER IMSI SERIES
The MME supports a default local roamer QoS policy for a Roamer IMSI series. The
MME can apply the local roamer QoS policy at the PDN connection level and at the
default bearer level separately. The default roamer policy for a roamer IMSI series is not
applicable for IMS and SoS APNs.
The following subsets specific policy provisioning.
- Subset 1 Default Bearer with the following QoS attributes:
QCI with value range from 6-9
Allocation Retention Priority with value range from 1-15
APN-AMBR
UE-AMBR
- Subset 2 Non-GBR Dedicated Bearer policy with the following QoS attributes:
ARP Priority Level with value range from 1-15
- Subset 3 GBR Dedicated Bearer policy with the following QoS attributes:
ARP Priority Level value range from 1-15
Guaranteed Bit Rate
Maximum Bit Rate
If the Roaming QoS policy feature is enabled, for Subset 1, provisioning is required for
at least one Roaming QoS policy.
Operators can leave Subset 2 and Subset 3 empty. If either of them is empty or if both
of them are empty, the Operator does not support either type or both types for a
Roamer, and the MME rejects the establishment of the type dedicated bearers or
rejects both types of bearers.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
133 / 652
6.1.14.1.2 DEFAULT ROAMER POLICY FOR IMS APNS
The MME supports a Default Roamer Policy for specific IMS APNs.
The following subsets specify policy provisioning:
- Subset 1 Default Bearer policy with the following QoS attributes:
- QCI with a value range from 5-9
- ARP with value range from 1-15
- APN-AMBR
- UE-AMBR
- Subset 2 Non-GBR Dedicated Bearer policy with the following QoS attributes:
- QCI with value range from 6-9
- ARP with value range from 1-15
-
- Subset 3 for GBR Dedicated Bearer policy with the following QoS attributes:
ARP Priority Level with value range from 1-15
Guaranteed Bit Rate
Maximum Bit Rate
If the Roaming QoS policy feature is enabled, for Subset 1 of IMS APN, provisioning is
a required. Operators can leave Subset 2 and 3 empty. When a subset is empty, the
operator does not support either or both types of dedicated bearers, and the MME
rejects the establishment of the type of dedicated bearers or reject both types. If one of
the fields in all subsets is filled, all fields are filled. AMBR, GBR and MBR cannot be
zero. For the SoS APN of E911 service, QoS provisioning is part of the MME local
configuration for E911 service.
The MME uses the local E911 provisioning data.
Operators can allow/disallow access to IMS APN on a per roaming PLMN basis.
6.1.14.1.3 LOCAL ROAMER QOS POLICY

The MME support a Local Roamer QoS policy. The MME can apply the local roamer
QoS policy at the PDN connection level and at the default bearer and dedicated bearer
levels separately.
Issue 11.01
At the PDN connection level, operators can configure APN-AMBR for each
requested PDN connection
For each default bearer, operators can configure the QoS QCI value, ARP
value, the Preemption Vulnerability Indication (PVI) / Preemption Capability
Indication (PCI) value and Maximum Bit Rate values (uplink/downlink).
For each dedicated bearer with GBR service, operators can configure the QCI
value, the PCI/PVI value and the Guaranteed Bit Rate (GBR) values
(uplink/downlink).
For each dedicated bearer with non-GBR service, operators can configure the
QCI value, PCI/PVI and the MBR values (uplink/downlink).
LTE/DCL/APP/031094
Nokia 2016
134 / 652
6.1.14.1.4 TREATING AN IMSI SERIES AS HOME SUBSCRIBERS
MME can be provisionned to:
Treat ranges of IMSIs series from a PLMN as roamers when, at the roaming
agreement level, they are to be treated as home subscribers of the Serving
PLMN.
Treat ranges of IMSIs as home subscribers of the Serving PLMN when, at the
roaming agreement level, they are to be treated as roamers.
In addition, at the roaming agreement level and an IMSI range/TAI-or-LAI List

level,the MME can be provisioned as follows :
o
Normal PGW DNS domain derivation (which is the default as is done

today)
Override Normal PGW DNS domain derivation and use a provisioned

override <mcc> and <mnc> (epc.mnc.mcc.3gppnetwork.org).
This functionality does not change SGW DNS domain derivation.
The Serving PLMN above can be either the home PLMN or a shared PLMN.
IMSI Range Services entries take precedence over UE PLMN Services entries.
Thus if Treat as Homer is indicated on the UE PLMN Services record for the PLMN, but
not for a given IMSI Range within the PLMN, the UEs within the IMSI Range will not
receive Treat as Homer treatment. This provides the ability to provide roamer
treatment for UEs that would otherwise be treated as homers based upon the applicable
UE PLMN Services record.
IMSI Range Services records can also be applied or not applied based upon the serving
eNB and whether that eNB is within the TAI list indicated on the IMSI Range Services
record. MME support for Treating an IMSI Series as Home Subscribers does not
change SGW DNS domain derivation.
The activation of the service this feature provides is on a per roaming agreement basis.
The operator can activate for all UEs belonging to a given roaming agreement level or a
subset of UEs (IMSI range / TAI list level).
To truly provide treatment as a home subscriber of the Serving PLMN, the operator
must explicitly set service-profile and other related fields to the same values as for
actual home subscribers of the Serving PLMN.
Parameter
Treat Roamer As Home Subscriber
SAM Table Name
IMSI Range Service
OSS ID
ltemme.IMSIRangeServices.treatAsHomeSubscriber
Range & Unit
Boolean
Issue 11.01
Impact of Change
No service impact.
Value
Operator Dependent; default = False ( disabled )
Feature
m10132-01
LTE/DCL/APP/031094
Nokia 2016
135 / 652
6.1.14.1.5
PGW OVERRIDES
The override PGW MCC and MNC fields on UE PLMN Services and IMSI Range
Services enable the MME to pick a different PGW on which the MME can perform a
DNS NAPTR query.
Parameter
PGW Domain name MCC Override
SAM Table Name
IMSI Range Service,
OSS ID
ltemme.IMSIRangeServices.PgwDomainMccOverride
Range & Unit
3-digit Integer
[000..999]
Impact of Change
No service impact.
Value
Feature
m10132-01
Parameter
PGW Domain name MNC Override
SAM Table Name
IMSI Range Service
OSS ID
ltemme.IMSIRangeServices.PgwDomainMncOverride
Range & Unit
3-digit Integer
[000..999]
Impact of Change
No service impact.
Value
Feature
m10132-01
Parameter
PGW Domain name MCC Override
SAM Table Name
UE PLMN Services
OSS ID
ltemme.UEPLMNServices. LtePgwDomainMccOverride
Range & Unit
3-digit Integer
[000..999]
Impact of Change
No service impact.
Value
Feature
m10132-01
Parameter
PGW Domain name MNC Override
SAM Table Name
UE PLMN Services
OSS ID
ltemme.UEPLMNServices.LtePgwDomainMncOverride
Range & Unit
3-digit Integer
[000..999]
Issue 11.01
Impact of Change
No service impact.
Value

LTE/DCL/APP/031094
Nokia 2016
136 / 652
Rules: provisioned PGW Domain name MCC / MNC Override
PGW override is applied to UEs receiving Treat-as-Homer treatment
The provisioned override <mcc> and <mnc> are used for treated as Homer
Subscribers and although the APN-OI replacement string does not affect both the
APN-OI sent to other nodes in GTP messages as well as the MCC/MNC values
used for DNS queries.
The provisioned override <mcc> and <mnc> are not used for Roamer HomeRouted scenarios.
The provisioned override <mcc> and <mnc> are used for Roamer Local Breakout
scenarios whether the HSS subscription data for the UE does, or does NOT,
include an APN-OI replacement string.
PGW overrides are used for both Gateway Selection Mode 1 and Mode 2.
PGW overrides are applied only when the subscription PDN-GW-Allocation-Type
AVP is Dynamic.
Any provisioned override <mcc> and <mnc> is not used for emergency scenarios.
Any provisioned override <mcc> and <mnc> is not used for home subscribers.
Restrictions: Treat-as-Homer treatment of roaming

The following roaming restrictions are ignored for Treat-as-Homer UEs:
Acc_Rest_GERAN, Acc_Rest_UTRAN, Acc_Rest_CDMA2000, Acc_Rest_EUTRAN,
VPLMN_Allowed, NetworkAccessMode, VPLMNLipaAllowed, VPLMNCsgAllowed,
S102Allowed, DefIMSApnQosProfile, DefNonIMSApnQosProfile, CustApnQosProfile1,
CustApnQosProfile2, and CustApnQosProfile3.
For the following roaming restrictions, the MME uses the data indicated from the HSS
rather than any provisioned values on the MME: MaxBitRateUp (Aggregate Maximum
Bit Rate (AMBR) Uplink), MaxBitRateDown (AMBR Downlink), QCI (QoS Class
Identifier), ARP (Allocation/Retention Priority) Priority-Level, ARPPCIDisabled,
ARPHiPriorityLevel.
For the following roaming restrictions, the MME uses the data configured for the
serving PLMN: VPLMN_HSS_IP_ID_1, VPLMN_HSS_IP_ID_2.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
137 / 652
6.1.14.1.6
LOCAL BREAKOUT ENHANCEMENTS
Local breakout enhancement This feature closes security gap in the selection and
activation of PDN activation of unauthorized APNs in the visited network when wild card
APN is allowed for a roaming UE by supporting a capability to provision an APN white
list per IMSI number series of roaming subscribers. The MME supports in WMM 8.1.0
the provisioning of an APN white list per IMSI series for roaming subscribers. This
capability is used in PDN selection and activation of unauthorized APNs in the visited
network when a wild card APN is allowed for a roaming UE. MME will allow local
breakout PDN connections to the APNs defined in the white list. The MME checks the
APN Operator Identifier (APN-OI) if it is explicitly sent by the UE to proceed with PDN
connection request if the APN either matches the visited network PLMN ID or UE's
home network PLMN ID.
Figure 6-1 3GPP view of the Local Breakout
LBO enhancement is enable/diabled at the MME level and also at the UE PLMN level.
The global parameter Apply LTE APN White list is used to enable/disable the LBO
APN white list checks gloablly for LTE. If the LBO enhancement is disabled (set to No )
MME will not apply LBO APN white list checks irrespectively of the UE PLMN LBO APN
white list provisioning. LBO APN white lists can be enabled/disabled at the UE PLMN
Services level for individual Roaming Agreements. MME allows all APNs when LBO
APN White List screening is enabled globally but not enabled at roaming agreement
level ( flags apply LTE APN White List under UE PLMN Services Roaming )
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
138 / 652
Parameter
SAM Table Name
OSS ID
Range & Unit
Apply LTE APN White List

Global Parameters
gParmName
String
gParmValue
Boolean
Yes or No
Impact of Change
No service impact.
Value
Operator Dependent; default = No (enabled)
Feature
m10128-02
The MME provides an ability to configure and assign an APN white list to a roaming
agreement level at the network level and an IMSI range. The APN white list table
consists of APN Network Identifiers (APN-NI). LBO APN white list can be provision at
the UE PLMN level and an IMSI Range level of the network..
Parameter
APN White List Name
SAM Table Name
APN White List
OSS ID
Range & Unit
ltemme.APNWhiteList.aPNWhiteListName
Alphanumeric String
Impact of Change
No service impact.
Value
string
Feature
m10128-02
MME supports up to 256 LBO APN white lists. Each list can have a maximum of 16
APNs.
Parameter
Access Point Name Network Indicator
SAM Table Name
APN White List
OSS ID
ltemme.APNWhiteList.apnNI
Range & Unit
Issue 11.01
Impact of Change
No service impact.
Value
string
Feature
m10128-02
LTE/DCL/APP/031094
Nokia 2016
139 / 652
LBO enhancement also provides ability to provision home routed domain (MCC and
MNC) override to be used for a roamer home routed traffic. This is similar to the domain
override MCC/MNC provisioning for Treating an IMSI Series As Home Subscriber , but
applies only to Home-Routed roamers.
LBO enhancement implements an APN-OI override mechanism for roamer homerouted PGW selection by DNS query, where MCC/MNC values used to form the APN
NAPTR DNS query and used to form the APN-OI domain override value sent in the
GTP messages to other nodes can be explicitly provisioned:
Parameter
MCC LTE Home Routed PGW DNS Domain Override
SAM Table Name
UE PLMN Services
ltemme. UEPLMNServices.
MCCLTEHmRtPGWDnsDmOvrd
OSS ID
Range & Unit
3-digit Integer
[000..999]
Impact of Change
No service impact.
Value
Feature
m10128-02
Parameter
MNC LTE Home Routed PGW DNS Domain Override
SAM Table Name
UE PLMN Services
ltemme.
UEPLMNServices.MNCLTEHmRtPGWDnsDmOvrd
OSS ID
Range & Unit
3-digit Integer
[000..999]
Impact of Change
No service impact.
Value
Feature
m10128-02
Parameter
MCC LTE Home Routed PGW DNS Domain Override
SAM Table Name
IMSI Range Service
OSS ID
ltemme. IMSIRAngeServices.MCCHmRtPGWDnsDmOvrd
Range & Unit
3-digit Integer
[000..999]
Issue 11.01
Impact of Change
No service impact.
Value
Feature
m10128-02
LTE/DCL/APP/031094
Nokia 2016
140 / 652
Parameter
MNC LTE Home Routed PGW DNS Domain Override
SAM Table Name
IMSI Range Service

ltemme. IMSIRAngeServices.
MNCHmRtPGWDnsDmOvrd
OSS ID
Range & Unit
3-digit Integer
[000..999]
Impact of Change
No service impact.
Value
Feature
m10128-02
If the override is provisioned then MME uses the domain override to construct both APN
FQDN for the PGW selection and APN-OI sent to external nodes for the roamer UE
home routed traffic. If the override is not provisioned then MME uses the UE PLMN ID
derived from the IMSI to construct the APN-OI
LBO enhancement supports the following capabilities if a roaming UE sends both APNOI and APN-NI to the MME in the PDN Connection Request message:
Table 5 summarizes the MME decisions for a roaming UE sending both APN-OI and
APN-NI:
Scenarios :
MME actions :
If the APN-OI from the roamer UE is the UE

Home PLMN, regardless of the LBO setting on
the serving MME,
the Serving MME uses Home Routed

architecture for this APN, unless the
HSS/HLR has ODB barring on the APN
If the APN-OI from the roamer UE is the Serving

PLMN and if the APN is not allowed for LBO
(i.e., either IMSI range is not allowed or the IMSI
range is allowed for LBO but the APN is not in
the APN white list for the IMSI range),
then the MME falls back to home routed

architecture i.e. selects a PGW in UE
PLMN.
If the APN-OI from the roamer UE is the Serving

PLMN and if the APN is allowed for LBO,
then the MME allows PDP/PDN

activation based on the LBO
architecture, unless the roamer's HSS
has ODB barring on the APN.
If the APN-OI from the roaming UE is neither the

UE Home PLMN or Serving PLMN, nor matches
the home router APN-OI override setting,
Then the PDP/PDN session activation is

rejected. With NAS ESM cause code 32
( Service option not allowed )
If a roaming UE does not include the APN-OI
the APN-OI setting depends upon LBO

or home routed traffic
Table 5 : APN-NI APN-OI
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
141 / 652
The following table summarizes how the MME select APN-OI realms
Scenarios :
How the APN-OI realm is derived

Case 1: APN-OI-replacement field is received in the
UE subscription
1. Home Subscribers
(Not LBO roamer).
If UE sends APN OI check that the
APN-OI matches the HPLMN OI. If it
does not match then the MME/S4SGSN reject the PDN Connectivity
Request with NAS ESM CC #32
(Service option not allowed).
NAPTR Query: MME uses the APN-OIreplacement as the APN-OI of the APN FQDN in
the PDN Connection Request
GTP Messages: MME uses the APN-OI derived
from the UE PLMN.
Case 2: APN-OI-replacement is not received in the
UE subscription
NAPTR Query: MME uses the APN-OI derived
from the Serving PLMN.
GTP Messages: MME uses the APN-OI derived
from the UE PLMN.
2. Treat as home subscribers

(applicable to MME only) If UE
sends APNOI check that the
APN-OI matches the APN OI
derived for the GTP messages in
the following.
If it does not match then the
MME reject the PDN
Connectivity Request with NAS
ESM CC #32 (Service option not
allowed).
Case 1: APN-OI-replacement is received in the UE

subscription
NAPTR Query: MME uses the APN-OI
replacement field as the APN-OI of the APN
FQDN.
GTP Messages: If DNS domain override is
provisioned then use it as APN-OI. Otherwise
APN-OI is derived from the UE PLMN.

UE subscription
NAPTR Query: MME derives the APN-OI using
the DNS override if provisioned. Otherwise from
the serving Network PLMN.
provisioned then use it as APN-OI. Otherwise
APN-OI is derived from the UE PLMN.
In this case, MME ignores the APN-OIreplacement AVP received in the subscription data
3. Inbound Roamers with LBO (UE
sends APN-OI matching the
VPLMN or UE does not send
APN-OI)
Issue 11.01
NAPTR Query:. The MME always uses the

serving network PLMN ID to derive the APN-OI.
GTP Messages: The MME always uses the
serving network PLMN ID to derive the APN-OI.
LTE/DCL/APP/031094
Nokia 2016
142 / 652
Case 1: APN-OI-replacement is received in the UE
subscription
NAPTR Query: MME uses the APN-OIreplacement field as the APN-OI of the APN
FQDN.
4. Inbound Roamers with LBO but

UE sends APN-OI matching UE
PLMN or

provisioned for the HOME ROUTED TRAFFIC
then use the provisioned DNS domain to derive
the APN-OI. If the DNS domain override is not
provisioned then APN-OI is derived from the UE
PLMN.
5. Inbound Roamers with Homerouted APN or

6.
Inbound Roamer with APN-OI

matching VPLMN but
MME/SGSN denies LBO access
(fallback to home-routed):

UE subscription
NAPTR Query: If DNS domain override is
PLMN.
PLMN.
Table 6 APN Operator Identifier DNS Domain name derivation
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
143 / 652
6.1.14.1.7
RESTRICTING UE ACCESS TO A NETWORK BASED ON

REGIONAL SUBSCRIPTION ZONE CODE (RSZC)
UE access to a network can be restricted based on Regional Subscription Zone Code

(RSZC) in UE subscription data. Forbidden PLMNs can be specified per UE basis,
unlike roaming agreements where all UE are provided the same treatment. The RSZC
is mapped to provisioned forbidden PLMN identity (MCC and MNC) on the MME.
If the feature activation flag EnableRSZCForbiddenPLMN is enabled for home
subscribers and also for a roaming partner, the MME checks the RSZC for the
forbidden PLMN, and the MME uses the provisioned mapping to obtain the forbidden
PLMN. This forbidden PLMN is not included in the Equivalent PLMN list (or allowed
PLMN list) in the NAS PDU and in the Handover Restriction List sent to the eNB, so the
eNB will not allow the UE to handover to the forbidden PLMN.
In addition, if the UE selects the forbidden PLMN as the serving PLMN, the MME (that
is the serving PLMN) rejects UE mobility management requests with a provisioned NAS
cause code. The default cause code is PLMN not allowed.
Parameter
Enable RSZC Forbidden PLMN
SAM Table Name
UE PLMN Services
OSS ID
ltemme.UEPLMNServices. enableRSZCForbiddenPLMN
Range & Unit
Boolean
Yes or No
Impact of Change
No service impact.
Value
Operator Dependent; default = No (unchecked)
Feature
m10135-01
Parameter
SAM Table Name
NAS cause for RSZC PLMN

UE PLMN Services
OSS ID
ltemme.UEPLMNServices.RSZCForbiddenNASCauseCode
Range & Unit
Choice list
Table 22: NAS Cause Numeric Values and Description
Issue 11.01
Impact of Change
No service impact.
Value
Operator Dependent; default = 11 - PLMN Not allowed
Feature
m10135-01
LTE/DCL/APP/031094
Nokia 2016
144 / 652
Two new provisioning tables are added with this feature :
Restricted Zone Code per Served PLMN: Up to 127 Regional Subscription

Zone Codes (RSZC) per served PLMN can be provisioned for applying access
restriction.
Parameter
Zone Code
SAM Table Name
Restricted Zone Code Per Served PLMN
OSS ID
ltemme.ForbiddenRSZCTable.ZoneCode
Range & Unit
3-digit Integer
[0..127]
Impact of Change
No service impact.
Value
Feature
m10135-01
Forbidden RSZC PLMN List: allows to provision up to 4 forbidden PLMNs

(MCC and MNC) per each served PLMN and RSZC combination provisioned
in ForbiddenRSZC Table. Up to 4 forbidden PLMNs can be provisioned under
the Forbidden Zone Code per PLMN List table (under PLMN tab)
Parameter
Mobile Country Code
SAM Table Name
Forbidden Zone Code PLMN List
OSS ID
ltemme.forbiddenRSZCPLMNList.Mcc
Range & Unit
3-digit Integer
[000..999]
Impact of Change
No service impact.
Value
Feature
m10135-01
Parameter
Mobile Network Code
SAM Table Name
OSS ID
ltemme.forbiddenRSZCPLMNList.Mnc
Range & Unit
3-digit Integer
[000..999]
Issue 11.01
Impact of Change
No service impact.
Value
Feature
m10135-01
LTE/DCL/APP/031094
Nokia 2016
145 / 652
Parameter
Number of MNC Digits
SAM Table Name
OSS ID
ltemme.forbiddenRSZCPLMNList.MNCDigits
Range & Unit
3-digit Integer
[2..3]
Impact of Change
No service impact.
Value
Feature
m10135-01
Please refer to [R29] procedure 8-84 to configure a RESTRICTED Zone code PLMN
list.
If the feature Local roamer Qos Policy is enabled, the MME performs the following
checks:
The validates QoS values received from the network for Roaming UE in Create Bearer
Request message for Dedicated Bearer setup against the provisioned QoS profile. If the
provisioned QoS profile is empty, the MME rejects the dedicated bearer setup with the
Cause Value Request Rejected Unspecified (#31).
The MME validates QoS values received from the network for Roaming UE in Create
Bearer Request for Non-GBR Dedicated Bearer against the provisioned QoS profile. If
the provisioned QoS profile is empty, the MME rejects the request with the Cause value
Request Rejected Unspecified (#31)
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
146 / 652
6.1.14.1.8
ROAMING ENHANCEMENTS
Prior to the implementation of the roaming enhancement feature, Service Agreement

parameters are set based on the UE's Home PLMN and the Serving PLMN.
This feature allows those parameters to be set based on Ranges of UE IMSIs and on
the UE's current location (TAI or LAI).
The roaming enhancements feature supports configuration and enforcement of roaming
agreements per-PLMN basis to IMSI range and per-TAI basis to support more granular
area restrictions and different roaming agreements to different group of subscribers in
the same PLMN.
The set of roaming agreements that can be configured per IMSI and per TAI/LAI basis
include the following:
Service Agreement Profile specifies EUTRAN/UTRAN/GERAN/CDMA2000

access restrictions, network access mode, RFSP index values, Circuit
Switchcapabilities, and other service attributes.
Diameter NAS Cause Mapping
HLR Cause Mapping
Access Restriction Cause Mapping
QOS Profiles (for IMS, nonIMS, and custom APNs)
UE Roaming Restriction Profile (20 forbidden TACs/ 20 forbidden LACs)
Two major restrictions supported by this feature are access restriction (which is also
termed forbidden RAT) and IMS voice over PS service.
NAS code provisioning per IMSI range and TA basis is supported as follows:
NAS cause value to be sent if a UE requested mobility management (Attach,

TAU and Service Request) procedure is rejected due to access restriction.
When a UEs' IMSI and TAI/LAI match multiple entries in the IMSI Range
Services table, the entry with the lowest Entry ID will be applied by the MME.
NAS cause value to be sent if a UE requested mobility management (Attach,

TAU and Service Request) procedure is rejected due to HSS errors.
The IMSI range can consist of MCC, MNC and MSIN. The MSIN can be specified in
various ways, for example, range such as 100 to 200, individually listed IMSI, or all UEs
with the MCC and MNC.
The MME supports a maximum of 4K IMSI ranges across the maximum number of
PLMNs supported on MME.
For each IMSI range, the MME supports configuration of the TA list consisting of TACs
in the serving network (PLMN) The MME supports up to 300 TACs per IMSI range. If
the TAI list is not specified, it is assumed that the restrictions apply to all the TAs.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
147 / 652
Roaming enhancements are supported by the MME and Gn-SGSN. Support for this
feature is as follows:
Issue 11.01
IMSI ranges and TA/LA lists can overlap.
The TA lists and LA lists are separate. There are no combined TA/LA lists.
The maximum number of TAs in a TA list is 300.
The maximum number of LAs in an LA list is 300.
MME/SGSN supports a maximum of 4096 IMSI Range/TA and IMSI range/LA

list combinations.
The maximum number of TAs that can be in TA Lists associated with all IMSI
Ranges is 10,240.
The maximum number of different TA Lists associated with all IMSI Ranges is
128.
The maximum number of different TA Lists that can be provisioned via CLI is
128.
The maximum number of LAs that can be in LA Lists associated with all IMSI
Ranges is 10,240.
The maximum number of different LA Lists associated with all IMSI Ranges is
128.
The maximum number of different LA Lists that can be provisioned is 128.
If EUTRAN is allowed, provisioning must ensure that forbidden TAC and LACs
do not appear in the corresponding TAI/LAI list .
If the MME/SGSN knows the UE's IMSI, but does not know the UE's current
TAI/LAI, the MME/SGSN uses the roaming/service restrictions associated with
the IMSI Range and all-other TAI/LAI (if provisioned). If the IMSI Range and all.
TAI/LAI is not provisioned, the MME uses the roaming/service restrictions
associated with the UE PLMN and Serving PLMN.
The maximum number of provisioned Service Agreement Profiles is 4608.
The maximum number of provisioned restrictions to NAS CC profiles is 1024.
The maximum number of provisioned diameter errors to NAS CC profiles is

1024.
The maximum number of MAP errors to NAS CC mapping profile is 1024.
LTE/DCL/APP/031094
Nokia 2016
148 / 652
If a UE matches an IMSI range and current TAI is contained in the TAIList (or
TAIList=all), and if there is a Roaming Restriction Profile provisioned for that IMSI range
and current TAI, the MME uses that Roaming Restriction Profile to populate the
restricted TACs and/or LACs in the Handover Restriction List IE. If there is no Roaming
Restriction Profile provisioned, the MME does not send any restricted TACs or LACs in
the Handover Restriction List IE.
Otherwise, if a UE does not match an IMSI range, and if there is a Roaming Restriction
Profile provisioned for the UE Home PLMN/Serving PLMN pair, the MME use that
Roaming Restriction Profile to populate the restricted TACs and/or LACs in the
Handover Restriction List IE. If there is no Roaming Restriction Profile provisioned, the
MME does not send any restricted TACs or LACs in the Handover Restriction List IE.
The MME supports provisioning of NAS Cause code to be sent to the UE in an MM
rejection message for the following Access Restriction reasons:
Issue 11.01
LTE PLMN Not Allowed
TAI not allowed for HPLMN
TAI not allowed for Roamer UE
EUTRAN not allowed for HPLMN
EUTRAN not allowed for roamer UE in VPLMN
Unsupported feature
All ODB barred
CSG Restricted
LAI not allowed for HPLMN
LAI not allowed for Roamer UE
GPRS not allowed for HPLMN
GPRS not allowed for Roamer UE in VPLMN
LTE/DCL/APP/031094
Nokia 2016
149 / 652
6.2 WMM Field Install/System Information
Nokia personnel use the field install GUI for initial hardware installation and
configuration. The field install GUI is not used again after intial installation. The following
parameters are configured during field install and also appear in the System Information
table of the 5620 SAM GUI. The 5620 SAM cannot be used to change these
parameters; they are read-only.
Parameter
SAM Table Name
WMM Switch Name

System Information
OSS ID
ltemme.MMESystemInforAbs.switchName
Range & Unit
Up to 16 ascii characters.
Impact of Change
No service impact.
Value
Operator Dependent; no default
Parameter
SAM Table Name
Time Zone
System Information
OSS ID
ltemme.MMESystemInforAbs.timeZone
Range & Unit
Up to 16 ascii characters.
Impact of Change
No service impact.
Value
Parameter
SAM Table Name
Time Zone Offset

System Information
OSS ID
ltemme.MMESystemInforAbs.timeZoneOffset
Range & Unit
Integer
[1..24]
Issue 11.01
Impact of Change
No service impact.
Value
Parameter
SAM Table Name
Application Type
System Information
OSS ID
ltemme.MMESystemInforAbs.application
Range & Unit
MME
Impact of Change
No service impact.
Value
MME is the only valid value.
LTE/DCL/APP/031094
Nokia 2016
150 / 652
Parameter
SAM Table Name
Release Number
System Information
OSS ID
ltemme.MMESystemInforAbs.releaseNum
Range & Unit
Alphanumeric
Impact of Change
No service impact.
Value
Release Dependent; no default
Parameter
SAM Table Name
Build Number
System Information
OSS ID
ltemme.MMESystemInforAbs.buildNum
Range & Unit
Alphanumeric
Impact of Change
No service impact.
Value
Parameter
SAM Table Name
Maint Conditions
System Information
OSS ID
ltemme.MMESystemInforAbs.maintConditions
Range & Unit
Integer
[1..20]
Impact of Change
No service impact.
Value
Parameter
SAM Table Name
Read only mode

System Information
OSS ID
ltemme.MMESystemInforAbs.readOnly
Range & Unit
Boolean
Issue 11.01
Impact of Change
No service impact.
Value
LTE/DCL/APP/031094
Nokia 2016
151 / 652
6.3 MME Identification
A unique identifier (the Globally Unique MME ID, GUMMEI) is required to differentiate
the MME nodes in the LTE network. The GUMMEI is the concatenation of <MCC>,
<MNC>, <MMEGI> and <MMEC>. The MCC and MNC define the PLMN. (Refer to
Section 6.1.) The MMEGI and MMEC are described in Sections 6.4.1 and 6.3.3,
respectively. All MMEs in the network are defined in the following manner and the
Home MME or this MME is identified by checking the Home MME checkbox on the
MME Node form. (See below.)
The following parameters are used to define the PLMN:
Site ID
Site Name
Pool Information
Local Name (See Section 6.3.2.)
MME Code (See Section 6.3.3.)
Relative Capacity (See Section 6.4.4.)
Auto Adjusts Relative Capacity (See Section 6.4.6.)
Home MME (See Section 6.3.1.)
Node Type (See Section 6.3.1.)
S10 IP (See Section 6.3.4.)
The
Site
ID
and
Site
equipment.EquipmentSpecifics.
Name
properties
Parameter
SAM Table Name
Site ID
MME Node
OSS ID
equipment.EquipmentSpecifics.siteId
Range & Unit
Alphanumeric String
are
inherited
from
Up to 64 characters
Impact of Change
No service impact.
Value
Parameter
SAM Table Name
Site Name
MME Node
OSS ID
equipment.EquipmentSpecifics.siteName
Range & Unit
Alphanumeric String
Up to 252 characters
Issue 11.01
Impact of Change
No service impact.
Value
LTE/DCL/APP/031094
Nokia 2016
152 / 652
Pool Information is an internal ID for the Global object representing an MME

Pool.
Parameter
Pool Information
SAM Table Name
MME Node
OSS ID
ltepool.MmePool.id
Range & Unit
Integer
[1..1024]
Impact of Change
No service impact.
Value
6.3.1 HOME MME

The Home MME refers to the MME that is currently being provisioned. When DNS is not
used for MME discovery, all MMEs in the network must be manually defined and
identified for this Home MME. They are defined in the same way, but they are not the
Home MME.
Parameter
SAM Table Name
Home MME
MME Node
OSS ID
ltemme.MMENode.homeMME
Range & Unit
Boolean
Impact of Change
No service impact.
Value
Parameter
Node Type
SAM Table Name
MME Node
OSS ID
ltemme.MMENode.nodeType
Range & Unit
Choice List
Home Network
Shared Network
Other Network
Impact of Change
No service impact.
Value
Operator Dependent; default = Other Network
Restriction: Updating Home MME

The Home MME cannot be deleted and cannot be redefined as other than the Home
MME. An MME that is not the Home MME can be deleted or added post-installation.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
153 / 652
6.3.2 LOCAL NAME
The Local Name is a provisionable, human-readable name provided to ease the MMEs
identification in the LTE network. The local name is sent to the eNB as the MME
identifier in the S1 setup response.
The MME is assigned a System Name during installation. (Note installation occurs prior
to provisioning.) The System Name is used at the 5620 SAM as the MME identifier. It is
recommended that customers use the same string for Local Name and System Name,
but this recommendation is not enforced.
Parameter
SAM Table Name
Local Name
MME Node
OSS ID
ltemme.MMENode.localName
Range & Unit
Up to 32 ascii characters from the following sets:

[A..Z], [a..z], [0..9], [ - . : ], and the space character.
Impact of Change
No service impact.
Value
Operator Dependent; default = System Name from

installation if System Name follows Local Name range &
unit rules, otherwise no default.
Engineering Recommendation: MME Local Name

The recommendation is to use a simple text name that indicates the geographical
location of the MME, as in a city or neighborhood name.
Rule: MME System Name

The MME System Name assigned during installation must follow the range and
unit rules of the MME Local Name (above) if the same string is used for both
names.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
154 / 652
6.3.3 MME CODE (MMEC)
The MME Code is the node ID of the MME within the MME Group. Note that the MMEC
is the last piece of the GUMMEI. (The GUMMEI is the concatenation of <MCC>,
<MNC>, <MMEGI> and <MMEC>.)
Parameter
SAM Table Name
MME Code
MME Node, S10 Peer
OSS ID
ltemme.MMENodeAbs.mMEC
Range & Unit
Integer
[0..255]
Impact of Change
No service impact.
Value
Rule: MME Code

The MMEC must be unique within the MME group. Additionally, if a TAI is
covered by more than one MME group, the MMEC values cannot be duplicated
across groups.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
155 / 652
6.3.4 S10 IP ADDRESS
Each unique MME node (GUMMEI) is associated with a single S10 IP address.
Parameter
SAM Table Name
S10 IP
MME Node
OSS ID
ltemme.MMENode.s10IP
Range & Unit
Either IPv4 or IPv6 address
Impact of Change
No service impact.
Value
Operator Dependent; default = 0.0.0.0
Rule: S10 IP
An S10 IP address is associated with 1 and only 1 GUMMEI.
Rule: Home PLMN S10 IP Address

The S10 IP address of the Home MME must be set to the default of 0.0.0.0.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
156 / 652
6.3.5 eNB MME SELECTION ALGORITHM USING THE MAPPED
GUMMEI
MME supports sending of mapped GUMMEI to eNodeB to facilitate enodeB to select
the same physical node supporting the combo MME/SGSN when UE is moving
between 2G/3G and LTE area served by the same combo MME/SGSN.
UE Mobility
2G/3G
(GERAN/UTRAN
)
WMM 1
(Combo MME/SGSN)
WMM 2
(Combo MME/SGSN)
LTE
(EUTRAN)
Assume UE is registered with WMM 1 when it is in 2G/3G.

When it moves to LTE, eNB must select the same WMM 1.
In order for the eNB to select the same combo MME/SGSN, the MME application has to
send both native GUMMEI and also GUMMEI derived using the SGSN application NRI
in S1-AP SETUP RESPONSE message and also in S1-AP MME CONFIGURATION
UPDATE message.
MME includes the native GUMMEI first in the list i.e. provisioned MME group and MME
code Mapped GUMMEI is derived as follows for each PLMN supported (MME home
network and shared networks):
GERAN/UTRAN LAC is mapped to MME Group ID
NRI maps to the MME Code
MME supports 3072 mapped GUMMEI equals to (max number PLMN * max number
LACs * number NRIs = 3 * 1024 * 1).
MME supports a single NRI in WM8.0.0 and a maximum of 1024 LAIs.
The following describes the eNB MME selection algorithm using the mapped GUMMEI.
A UE which has previously registered with a given MME will provide the identity of the
MME by including either optional information element S-TMSI containing MME Code in
RRC Connection Request message (when the UE is registered in the Tracking Area of
the cell it is attempting to access) or optional information element registered MME
(GUMMEI that consists of the PLMN ID, the MME Group ID and the MME Code) in the
RRC Connection Setup Complete message. Rel 10 UEs will also populate optional IE
mmegi-type-r10 indicating whether it is native (from LTE MMEs) or mapped (combo
MMEs/SGSNs). Rel-9/8 UEs wont support the optional IE. In either case of S-TMSI or
registered MME, the ENB will attempt to match the provided MME with an MME identity
in the list of GUMMEIs received during S1 Setup procedure or MME Configuration
Update procedure.
A new global parameter "Include Mapped GUMMEI " has been added to enable/disable
the functionality associated with this feature. Default setting is No.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
157 / 652
Parameter
SAM Table Name
OSS ID
Include Mapped GUMMEI

Global Parameters
gParmName
String
Include Mapped GUMMEI
Range & Unit
gParmValue
Boolean
Yes or No
Impact of Change
No service impact.
Value
Operator Dependent; default = no
Feature
m10920-01
6.3.6 MME TIME ZONE

The Time Zone for the MME itself is configured during initial installation using the Field
Install GUI. The MME time zone can be changed using a series of commands shown in
Section 5.1.4.1.1.14 or using the 5620 SAM.
Rule: MME Time Zone Login

The user must be logged in to the active MI as user root.
Rule: MME Change Time Zone Command

The change time zone command backs out automatically if a failure occurs and
shows a success message if the change was successful.
Rule: MME Change Time Zone Backout

The change time zone command can be manually backed out before committing by
entering the following command:
tz_adm a backout
Restriction: Send New Time Zone to Diskless Blades

The CNFG server must be switched over two times after changes are committed to
send the new time zone to the diskless blades. Enter the following command:
FScmd switch cnfg
Wait for the command to complete and enter it again.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
158 / 652
6.3.7 ENB TIME ZONE
eNB provisioning is only required to provision the time zone for an eNB that is in a
different time zone than this MME. The default is to assign the eNB to the same time
zone as this (home) MME. The MCC, MNC and Macro eNB ID are used to identify the
eNB.
Parameter
SAM Table Name
Macro eNB Id
eNodeB
OSS ID
ltemme.MMEeNBAbs.macroeNBId
Range & Unit
20-bit value
As specified in TS 36.413 v8.6.1
Impact of Change
No service impact.
Value
Parameter
SAM Table Name
Region Name
eNodeB
OSS ID
ltemme.MMEeNBAbs.mobileNodeRegionPointer
Range & Unit
Choice List
Asia, Africa, Europe, North America, South America,

Oceania
Impact of Change
No service impact.
Value
Operator Dependent; default = North America
Parameter
Time Zone Name
SAM Table Name
eNodeB
OSS ID
ltemme.MMEeNBAbs.timeZoneName
Range & Unit
Choice List
Provides time zone names that correspond to the Region
selected above.
Issue 11.01
Impact of Change
No service impact.
Value
LTE/DCL/APP/031094
Nokia 2016
159 / 652
6.3.8 UE TIME ZONE
In large networks spanning across multiple time-zones, it is necessary to define time
zone for every part of radio coverage. This information is then used during charging, so
the information about time zones must be propagated in the GTP-C messages to the
PGW or GGSN.
The 9471 WMM supports a system-level parameter that defines the time zone. The
system-level parameter specifies the time zone where the physical system is located.
Inlarger networks, this time zone might not correspond to time zone served by the given
node and the served area can span different time zones.
The 9471 WMM supports the following time zone configurations. To determine in which
time zone a UE is in, the 9471 takes the values of configured time zone in the given
order (the first three time zone configurations are optional) :
1. eNB time zone configuration
2. Routing-area (RA)/Tracking-area (TA) time zone configuration
3. Mobile-network default time zone configuration
4. System level time-zone configuration
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
160 / 652
6.4 MME Pooling
Figure 6-2 below shows an example of MME pools and tracking areas. The figure
shows two MME pools supporting four tracking areas, where tracking area #2 is
assigned to both MME pools. The figure also illustrates some provisioning rules,
namely:
A UE may be registered in several tracking areas. (This is done as part of eNB

provisioning.)
An MME Pool (or group) is a set of complete tracking areas served by a common
pool of MMEs.
An MME may be registered in one (and only one) MME pool.
A tracking area may be assigned to more than one MME pool.
A single tracking area may not be split between MME pools.
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
Tracking
Area 1
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
Tracking
Area 2
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
MME
MME
MME
MME
MME
MME
MME
MME
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
Tracking
Area 3
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
Tracking
Area 4
MME
MME
MME
MME
MME
MME
MME
MME
Figure 6-2: Illustration of MME Pools and Tracking Areas
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
161 / 652
All MMEs within the MME pool are active. There is no standby MMEs. Each MME is
assigned a relative capacity (6.4.4 and 6.4.6) that indicates its capacity compared to
other MMEs in the group, as opposed to its absolute capacity. (For instance, relative
capacity would say whether the MME is capable of supporting the same number of
UEs, the number of UEs, or 3 times the number of UEs as other MMEs in the group.
Relative capacity does not say that the MME is capable of supporting 3 million UEs.)
MME capacity is based on the number of active MAF/vMAF blades in the Enabled and
Unlocked states. 1 10 MAF blade pairs may be provisioned on a single MME ATCA
and a maximum of 10 vMAF may be provisioned on a standalone HPc7000 in LR15.1.L
release. The MAFs/vMAF use active/standby redundancy, meaning 1 blade in each pair
is active at a given time. Relative capacity is only affected if both MAF/vMAF blades in a
pair fail. An MME will continue serving UEs if at least 1 MAF/vMAF remains Enabled
and Unlocked. If one MME in the MME group fails completely, then, over time, all UEs
will be equally assigned to the remaining MMEs in the group. When the failed MME
comes back into service, then, over time, all UEs will again be equally split over all the
MMEs in the group.
The MME Group table includes read-only parameters to represent the number of MMEs
associated with the MME pool (ltepool.MmePool.numberOfMMEs) and the number of
tracking areas associated with the MME pool (ltepool.MmePool.numberOfTAs).
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
162 / 652
6.4.1 MME GROUP IDENTIFIER (MMEGI)
Each MME is assigned to one (and only one) MME Group. The MME Group ID
identifies the MME pool that the MME belongs to. The MMEGI is used to define the
MME in the MME Node form and is then used to associate the MME group to a TAI in
the MME Group to TAI List form. A single TA can be assigned to more than one MME
group.
Please refer to Section 6.4.4 for a discussion of how the eNB selects an MME.
Parameter
SAM Table Name
Pool ID
MME Group to TAI List
OSS ID
ltepool.MmePool.mMEGI
Range & Unit
[0x0000..0xFFFF]
increments of 1
Impact of Change
The MME must be in a locked state to change MME Group ID

parameter.
Value
Rule: MME Groups

The MME supports a maximum of 16 MME groups with at least 16 MME entities per
MME group even if using DNS
Restriction: MME Discovery Effect on MME Group Provisioning

The provisioning entries for MME groups are ignored when MME discovery is used.
Restriction: MME To MME Group Mapping

An MME may be registered in one (and only one) MME pool.
Because the <MMEGI> is part of the Globally Unique MME ID (GUMMEI), the MME
will acquire a new GUMMEI if it is moved to a new MME group. (The GUMMEI is the
concatenation of <MCC>, <MNC>, <MMEGI> and <MMEC>.)
Rule: MME Groups within PLMN

All MMEs in an MME pool must be in the same PLMN. An MME can be reassigned
to a different pool within the PLMN.
Rule: Moving MME to Different MME Groups

All SGW, TAI mapping and S11 peer associations to the MME must be deleted prior
to moving an MME to a different MME group.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
163 / 652
6.4.2 MME DISCOVERY VIA DNS
When multiple MMEs exist in the network, an MME can be selected using provisioned
MME IP addresses or an MME can be selected using MME discovery and S-NAPTR
query procedures. Please refer to Section 8.1.2.5.1 for more information regarding
MME selection. (S-NAPTR query procedures are also used to select an SGW. Please
refer to Section 0 for more information regarding S-NAPTR.)
The global parameter Discover MME indicates whether or not to use a DNS query to
obtain a list of MME IP addresses for handling a given TAI.
Parameter
Discover MME
SAM Table Name
Global Parameters
OSS ID
gParmName
String
Discover_MME
Range & Unit
gParmValue
Boolean
Yes or No
Impact of Change
No service impact.
Value
Operator Dependent; default = no (use provisioned S10 IP

addresses)
If set to yes, the S10 Interface Managed Objects (MOs) are created dynamically. If set
to 'no', the S10 Interface MOs are created from provisioned data and are deleted when
this provisioning data is removed from the system.
If DNS is used, a DNS application timer is also used. The platform-based DNS resolver
uses a two-second timer for returning to the application. This DNS application timer can
be set to a value less than two seconds to support call processing under high load
conditions. That is, the application will not wait two seconds before proceeding with call
processing for a UE if the DNS application timer is set to a value less than 2000 msec.
Double dipping of DNS is used to obtain old nodes IP address if MME needs to obtain
the UE context from the old node.
For Attach/TAU scenarios, MME uses the NAS message markers to first determine the
Serving Node, such markers of Old Guti Type IE, Old P-TMSI Signature, and
Additional GUTI.
If any of the markers are present MME only relies on those markers to determine the
serving NODE type (i.e. SGSN or MME). If the NAS message does not contain previous
serving node IE markers, MME may perform a double DNS dip to determine the
serving node and its IP address.
Restriction: DNS Server
The DNS belongs to the operator's network and is not part of the 9471 WMM. The
operator is responsible for accurate configuration of their DNS.
The 5620 SAM Provisioning GUI only allows or disallows using DNS for MME
discovery.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
164 / 652
Parameter
DNS Application Timer
SAM Table Name
Timer
ltemme.MMETimerAbs.timerName
ltemme.MMETimerAbs.timerUnit
ltemme.MMETimerAbs.timerValue
OSS ID
timerName
Choice List
DNS_Application_Timer
Range & Unit
timerUnit
Choice List (automatically populated based on
timerName)
msec
timerValue
Integer
[100..5000] msec, 100 msec increments
Impact of Change
No service impact.
Value
Operator Dependent; default = 5000 (use platform-based DNS

resolver timer)
6.4.3 MME GROUP TO TAI LIST

The MMEGI is used to associate the MME group to a TAI in the MME Group to TAI List
form. A single TA can be assigned to more than one MME group. Please refer to
Section 6.4.4 for a discussion of how the eNB selects an MME.
The MME Node and TAI list must be provisioned prior to provisioning the MME
Group and the TAIs that the MME Group will serve.
6.4.4 MME NODE RELATIVE CAPACITY

Relative Capacity of the MME is used by the eNB in the selection algorithm. The
Relative Capacity parameter indicates the ability of this (Home) MME to serve UEs. The
eNB selects the MME from the MME group(s) that cover the TA using the S1-flex
algorithm. (Please refer to Figure 6-2.)
S1-Flex supports network redundancy and load sharing of traffic across network
elements by allowing each eNB to be connected to multiple MMEs and SGWs in a pool.
(This is done as part of eNB provisioning.) The eNB selects an MME from the pool (per
TS 23.401) and the MME selects the SGW. The S1-Flex algorithm selects an MME
proportional to its relative capacity.
Please refer to the eNB LPUG [R30] for more information.)
All MMEs in an MME group share the load according to their relative capacity. The
Relative Capacity is a measure of an MME's ability to serve UEs compared to the other
MMEs in the same group. An MME should have a relative capacity value that is
consistent with its configured capacity within the group. That is, if all the MMEs in an
MME group have the same configured capacity (same number of MAFs), then the
relative capacities of all MMEs in that group should be equal. However, if one of the
MMEs has twice the configured capacity as the others (twice the number of MAFs), this
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
165 / 652
MME should have a relative capacity that is twice the relative capacity of the other
MMEs in the group.
As an example, if there are two MMEs in a group and each has the same relative
capacity, then, on average, half the UEs served by all the eNBs managed by that MME
group will appear on one MME and half will appear on the other MME. There are no
spare MMEs in an MME group; the MMEs share the load as their capacity allows.
Parameter
Relative Capacity
SAM Table Name
MME Node
OSS ID
ltemme.MMENode.capacity
Range & Unit
Integer
[1..255]
Impact of Change
No service impact.
Value
Engineering Recommendation: Relative Capacity

An MME should have a relative capacity value consistent with the configured capacity
relative to all other MMEs in the MME group.
Note: The MMEs configured capacity is directly proportional to the number of active
MAF/vMAF pairs.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
166 / 652
6.4.5 MME RELATIVE CAPACITY PER TRACKING AREA
MME relative capacity can be provisioned per tracking area in home PLMN and shared
PLMN separately.
A new provisioned value of MME Relative Capacity level is introduced, that could be
different than MME Node Relative Capacity.
Parameter
MME Relative Capacity
SAM Table Name
MME Tracking Area
OSS ID
ltemme.MMETAI. mmeRelCapacity
Range & Unit
Integer
[0..255]
Impact of Change
No service impact.
Value
The MME populates the MME Relative Capacity in an S1AP S1-SETUP-RESPONSE

or S1AP MME-CONFIGURATION-UPDATE to all the eNBs in a TA based on the MME
Relative Capacity provisioned in that Tracking area. If a TAI is not provisioned with
relative capacity, the MME uses the default MME node relative capacity
At S1-Setup, the MME can either send Node or Tracking Area level MME Relative
Capacity in the S1 Setup Response Message for the following :
-
If the Auto Adjust Relative Capacity flag is set tot True and also if the Trac
Area Relative Capcity global parameter is disabled MME sends the MME
Node Relative Capacity in the S1 Setup Response Message
Parameter
Trac Area Relative Capcity
SAM Table Name
Global Parameters
OSS ID
Range & Unit
gParmName
String
Trac Area Relative Capcity
gParmValue
Boolean
Yes or No
Issue 11.01
Impact of Change
No service impact.
Value
Operator Dependent; default = no (disabled)
LTE/DCL/APP/031094
Nokia 2016
167 / 652
-
If the Trac Area Relative Capcity global parameter is enabled and also if the
Auto Adjust Relative Capacity is set to False then the MME sends either
maximum or minimum of Node/Tracking Area provisioned relative capacities
of all the TAIs supported by the eNB. The selection of maximum or minimum
MME Relative Capacity of a TA is defined by the Max TA Relative Capacity
global parameter :
Parameter
Max TA Relative Capcity
SAM Table Name
Global Parameters
OSS ID
Range & Unit
gParmName
Max TA Relative Capacity
gParmValue
Boolean
Yes
No
Impact of Change
No service impact.
Value
Operator Dependent; default = no (disabled)
If the Max TA Relative Capacity global parameter is set to No (default) the MME select
the minimum relative capacity of tracking areas supported by the eNB.
MME can also send the Tracking Area level MME Relative Capacity to all eNBs
requiring an update via the MME CONFIGURATION UPDATE message. Broadcast is
complete within a max of 180 seconds to all the eNBs requiring an update.
Rule: MME relative capacity per TA :

The MME relative capacity maximum value per tracking area cannot be greater
than the node level MME relative capacity.
Note: The MME Relative Capacity of a TA overrides the node level MME Relative
Capacity (calculated or provisioned) unless the value of the MME Relative Capacity of a
TA is greater than the value of the node level MME Relative Capacity.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
168 / 652
6.4.6 AUTO ADJUST RELATIVE CAPACITY
The Auto Adjust Relative Capacity parameter indicates whether or not this (Home)
MME automatically adjusts the relative capacity value based on the number of active
MAF blades in the enabled and unlocked states. (The number of active and unlocked
MAF blades in this MME determines MME capacity.)
When Auto Adjust Relative Capacity flag is set to True, the relative capacity parameter
defined above (Section 6.4.4) is ignored.
When Auto Adjust Relative Capacity flag is set to False, the MME only uses the
relative capacity value provisioned above. That is, if auto adjust is not used, the relative
capacity of the MME will not be adjusted and the selection algorithm used by the eNB
will not be affected due to MAF failures.
Whenever there is change to the MME node level capacity (either explicitly provisioned
or via "Auto Adjust Relative Capacity" then MME automatically adjusts any per tracking
are capacity values to the new node level value if the per tracking are capacity exceeds
the new MME node capacity value.
If the MME Relative Capacity by Tracking Area is disabled and also if the Auto Adjust
Relative Capacity is disabled, MME sends the relative capacity provisioned for the
MME to only those eNB that require updates. Similarly, if the MME Relative Capacity by
Tracking Area is enabled then MME sends the relative capacity as specified above to
only the eNBs that require updates.
Parameter
Auto Adjust Relative Capacity
SAM Table Name
MME Node
OSS ID
ltemme.MMENode.autoAdjustCap
Range & Unit
Boolean
Impact of Change
No service impact.
Value
Operator Dependent; default = True (Auto adjust relative

capacity)
Restriction: Relative Capacity & Auto Adjust Relative Capacity

The Relative Capacity and Auto Adjust Relative Capacity fields can only be
provisioned on the Home MME, that is, if the Home MME field is checked (true).
Each MME is treated independently. That is, other MMEs in the MME group do not
know if/when the relative capacity of an individual MME changes.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
169 / 652
6.4.7 MME LOAD RE-BALANCING
The MME provides an overload mechanism to rebalance MAF load automaticaly to
balance the load on the Service blades based on the number of UE context entries.
This mechanism gives priority to the lighter loaded Service blades during UE distribution
to balance the number of subscribers among the Service blades. The preferred
treatment mechanism is adjusted every second as new subscribers are assigned to the
lighter loaded Service Blades.
The enhanced Overload Control to rebalance MAF load provides the following
enhancements:
New objects to the list of resources monitored by the Overload Control function:
APN usage and Bearer Resources. These resources are budgeted and
when a MAF exhausts either one of them, it is no longer selected by the MAF
selection function as the recipient for new UE attaches.
When usage thresholds for the new resources

softwareAllocatedResourceOverload alarm is raised.
are
crossed,
an
In scenarios where no imbalance is present, the round robin is the approach used by
the MAF selection.
When an imbalance is present, for example, due to the addition of a new MAF pair in an
in-service WMM, MAF selection uses the new preferred treatment where the least
loaded MAF is selected more often.
When the imbalance is no longer present, the MAF selection function returns to the
round robin distribution method.
The mechanism is especially useful during Service Blade growth when all new
subscribers should be assigned to the new Service Blade.
During normal operational load, this mechanism rebalances the subscribers on the
Service Blades within 48 hours.
6.4.8 HANDLING OF NAS LEVEL

CONGESTION CONTROL
MOBILITY
MANAGEMENT
As defined in 3GPP 24.301, under general overload conditions the MME may reject
Mobility Management signalling requests from UEs. When a NAS request is rejected, a
Mobility Management back-off timer (T3346) may be sent by the MME and MME may
store the back-off time per UE if a request without the low access priority indicator is
rejected by the MME and if MME maintains the UE context.
The MME may immediately reject any subsequent request from the UE before the
stored back-off timer expired. While the Mobility Management back-off timer is running,
the UE shall not initiate any NAS request for Mobility Management procedures except
for Detach procedure and except for high priority access, emergency services and
mobile terminated services. After any such Detach procedure, the back-off timer
continues to run. While the Mobility Management back-off timer is running, the UE is
allowed to perform Tracking Area Update if it is already in connected mode. If the UE
receives a paging request from the MME while the Mobility Management back off timer
is running, the UE shall stop the Mobility Management back-off timer and initiate the
Service Request procedure or the Tracking Area Update procedure.
While the Mobility Management back-off timer is running, the UE configured with a
permission for overriding low access priority is allowed to initiate the Mobility
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
170 / 652
Management procedures without low access priority if the Mobility Management backoff timer was started due to a reject message received in response to a request with low
access priority and the upper layers in UE request to establish a PDN connection
without low access priority or the UE has an established PDN connection that is without
low access priority.
The Mobility Management back-off timer shall not impact Cell/RAT and PLMN change.
Cell/RAT and TA change do not stop the Mobility Management back-off timer. The
Mobility Management back-off timer shall not be a trigger for PLMN reselection. The
back-off timer is stopped as defined in TS 24.301 [46] when a new PLMN that is not an
equivalent PLMN is accessed.
To avoid that large amounts of UEs initiate deferred requests (almost) simultaneously,
the MME should select the Mobility Management back-off timer value so that the
deferred requests are not synchronized.
When the UE receives a handover command, the UE shall proceed with the handover
procedure regardless of whether Mobility Management back-off timer is running.
The MME should not reject Tracking Area Update procedures that are performed when
the UE is already in connected mode.
For idle mode inter CN node mobility, the MME may reject Tracking Area Update
procedures and include a Mobility Management back off timer value in the Tracking
Area Reject message.
If the MME rejects Tracking Area Update request or Service request with a Mobility
Management back-off timer which is larger than the sum of the UE periodic TAU timer
plus the Implicit Detach timer, the MME should adjust the mobile reachable timer and/or
Implicit Detach timer such that the MME does not implicitly detach the UE while the
Mobility Management back-off timer is running.
WM8.0.0 introduced a mechanism for offloading UEs from MAFs in CPU overload (CPU
consumption above 85%) to lightly loaded MAFs. The MME also provides a global
parameter called " Enable MME Overload Backoff Timer to enable/disable inclusion of
T3346 timer when a UE mobility management request is rejected by the MME due to
overload conditions including a MAF overload with NAS cause code #22 (Congestion).
Currently, when MPH or MIF or MAF goes into CPU overload, MME responds by
rejecting of fractions of mobility management and session management procedures.
As the CPU overload increases or decreases, MME progressively increases or
decreases the fraction of procedures it rejects. As part of this rejection mechanism,
IMSI and GUTI attaches are also candidates for rejection.
The MME support for offloading overloaded MAFs builds upon this mechanism of
rejection of IMSI and GUTI attaches during MAF CPU overload to relocate UEs to lightly
loaded MAFs in the MME when available. Only enough UEs are offloaded so that the
MAF in CPU overload are brought out of CPU overload.
The following new capabilities are provided to rebalance MAF load, which builds upon
existing MME overload control mechanisms:
Offload all IMSI and GUTI attaches targeted for rejection from MAFs in CPU overload to
the lightly loaded MAF/s when available. Lightly loaded target MAFs have CPU
consumption lower than 70% and room in available in the UE context table.
MIF will target a percentage of IMSI and GUTI attaches towards MAFs in CPU overload
and instruct the MAF to reject these attaches and then to delete the UE context. The
deletion of the UE context is only performed when there is/are lightly loaded MAFs
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
171 / 652
within the MME. Note that the deletion of the UE context is done irrespective of whether
the global parameter MME Overload NAS Cause Code for throttling (NAS CC #22,
congestion) is provisioned or not.
The global parameter MME Overload MM Rejection NAS CC specifies the EMM NAS
Cause Code (CC) to be sent in UE mobility management reject messages
(AttachReject,TAUReject and Service Reject) due to any MME overload and also due to
any throttling of UE mobility management requests.By default,the NAS CC is set to #22
(congestion). All the EMM NAS CC # specified in Annex A of 3GPP TS24.301 are
allowed. The WMM includes T3346 with a value of 0 whenever it rejects UE request
with cause#22.
When MME rejects an Attach Request, MME includes in the Attach Reject message a
T3346 timer and sets the NAS cause code to #22 (Congestion) (This assumes that the
MME Overload MM Rejection NAS Cause Code is set to 22) to spread the re-attaches
back to the MME so that MME gets enough time to delete the UE context clean up
associated maps. Please note that under CPU overload MME currently can reject GUTI
attaches, this feature simply takes advantage of the rejection to set the stage for
subsequent offloading of the UE to a lightly loaded MAF within the same MME.
When the UE subsequently retries the IMSI or GUTI attach, MME will not find UE
context, forcing MME to assign a MAF that is not in CPU overload and that has room in
the UE context table. MME proceeds with the attach request by obtaining IMSI from the
UE to establish its identity.
This method of offloading UEs is chosen for the following reason. The MIF distribution
of the UE to MAFs is such that MAFs would never experience overload. But, if MAF/s
experiences overload due to some unforeseen reason and there is/are lightly loaded
MAFs available (following new MAF pair growth or after duplex fault of a MAF pair and
their subsequent recovery), the scheme offloads certain percentage of UEs until the
MAF/s in CPU overload comes out of overload.
The UE offload rate depends on attach rate experienced by the MME and also by the
procedure rejection rate applied to the MAF in CPU overload.
The UE offloading activity is performed until the source MAFs CPU overload alarm
state goes from major to minor. After that point no more forced offloading using the
above method is performed and it is left to weighted MAF selection to do further
balancing.
A first global parameter Allow UE Offload on MME during MAF CPU Overload
enabled /disabled UE offloading from MAFs in CPU overload when lightly loadeds
MAFs are present in the MME.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
172 / 652
Parameter
Allow UE Offload on MME During MAF CPU Overload
SAM Table Name
Global Parameters
OSS ID
gParmName
String
Allow UE Offload on MME During MAF CPU Overload
Range & Unit
gParmValue
Boolean
Yes or No
Impact of Change
No service impact.
Value
Feature
m10709-02
A second global parameter enable MME Overload Backoff Timer is used to enable
the capability of MME to include a randomly-selected T3346 timer value whenever an
Attach Request, TAU Request, Service Request, or Extended Service Request
procedure is rejected due to MPH CPU overload, MIF CPU overload, MAF CPU
overload, or CXN object overload.
Parameter
Enable MME Overload Backoff Timer
SAM Table Name
Global Parameters
OSS ID
gParmName
String
Enable MME Overload Backoff Timer
Range & Unit
gParmValue
Boolean
No (default) - Set the T3346 back-off timer to 0.
Yes - Set the T3346 back-off timer to a randomly-selected
value between provisioned minimum and maximum values.
Impact of Change
No service impact.
Value
Feature
m10709-02
MME provides an ability to provision separate minimum and maximum T3346 timers
value for the attach reject, TAU Request, and Service Request. The range of values
allowed for both minimum and maximum value is 0 to 600 seconds with a minimum
default of 15 seconds and maximum default value of 60 seconds.
MME randomly selects a timer value between the minimum and maximum timer values.
This random selection is used so that UEs subsequent requests to avoid clustering of
UE requests. If timer values are not provisioned then MME sets the T3346 to 0.
T3346 is used as follows:
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
173 / 652
If NAS cause code #22 (Congestion) is used to reject Attaches, TAUs and Service
requests due to MPH CPU overload, MIF overload and/or MAF CPU or CXN object
overload, the MME also includes the back-off timer T3346 IE. MME sets the T3346
value as described in the following. UE is expected to not send any new requests until
the expiration of the timer. Note that the NAS cause code #22 is only sent if provisioned
Parameter
SAM Table Name
OSS ID
See table below for Displayed Name.

Timer
timerName
Choice List
See table below for timerName.
Range & Unit
timerUnit
timerName)
See table below for timerUnit.
timerValue
Integer
See table below for timerValue
Issue 11.01
Impact of Change
No service impact.
Value
Operator Dependent; See table below for default values.
Feature
m10709-02
LTE/DCL/APP/031094
Nokia 2016
174 / 652
Displayed
Name
timerName
timerValue
(Range)
Default
Value
Purpose
T3346 Attach
Reject
Minimum
T3346 Attach
Reject
Minimum
0 600
seconds
15 seconds
Specifies the minimum value

to consider when randomly
value to be used for an
attach procedure rejection
due to MPH CPU overload,
MIF CPU overload, MAF
CPU overload, and CXN
object overloads with NAS
cause
code
#22
(Congestion).
T3346 Attach
Reject
Maximum
T3346 Attach
Reject
Maximum
0 600
seconds
60 seconds
Specifies
the
maximum
value to consider when
randomly
assigning
the
T3346 timer value to be
used for an attach procedure
rejection due to MPH CPU
overload,
MIF
CPU
overload,
MAF
CPU
overload, and CXN object
overloads with NAS cause
code #22 (Congestion).
T3346 Service
Request
Reject
Minimum
T3346 Service
Request
Reject
Minimum
0 600
seconds
15 seconds

value to be used for an SR
procedure rejection due to
MPH CPU overload, MIF
CPU overload, MAF CPU
T3346 Service
Request
Reject
Maximum
T3346 Service
Request
Reject
Maximum
0 600
seconds
60 seconds
Specifies
the
maximum
randomly
assigning
the
used for an SR procedure
overload,
MIF
CPU
overload,
MAF
CPU
code #22 (Congestion)
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
175 / 652
Displayed
Name
timerName
timerValue
(Range)
Default
Value
Purpose
T3346
TAU
Reject
Minimum
T3346
TAU
Reject
Minimum
0 600
seconds
15 seconds

value to be used for a TAU
procedure rejection due to
MPH CPU overload, MIF
CPU overload, MAF CPU
T3346
TAU
Reject
Maximum
T3346
TAU
Reject
Maximum
0 600
seconds
60 seconds
Specifies
the
maximum
randomly
assigning
the
used for a TAU procedure
overload,
MIF
CPU
overload,
MAF
CPU
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
176 / 652
6.4.9 UE LOAD BALANCING
6.4.9.1
Common UE Load balancing implementation based
GUTI/PTMSI reallocation (inter-WMM UE load balancing)
MME UE load balancing capabilities extends a common strategy for MME and SGSN
and specific procedures that allow more granular definition of UE's to move and utilizes
3GPP mobility management procedures to select specific source and target
MMEs/SGSNs to which to move the UE's.
A UE subscriber is only in one technology at a given time, 4G, 3G, 2G, or none.
The following functionality are provided:
-
Combined UE load balancing procedures for 4G, 3G and 2G UEs in a WMM.
In a standalone MME, the procedure can be used to load balance 4G UEs from
a source MME to other MMEs in the home MME pool or to a specified MME in
the home MME pool.
In a standalone SGSN, the procedure can be used to load balance 2G and/or

3G UEs from a source SGSN to other SGSNs within a pool or to a specified
SGSN.
In a WMM combo, the procedure can be used to load balance 4G UEs from a
source MME to other MMEs in the home MME pool or to a specified MME in the
home MME pool.
The procedure can also be used to load balance 2G and/or 3G UEs from a source
SGSN to other SGSNs within a pool or to a specified SGSN.
An operator can use the 5620 SAM or the WMM CLI to load balance UEs using the
following multiple UE selection criteria:
Radio type: All (4G, 3G, 2G) OR 4G only OR 3G only OR 2G only OR 2G and
3G.
UE Number: Either specify the number of UEs to be load balanced (absolute)

or specify the percentage of UEs to be load balanced (%) or specify that all UEs
be load balanced. (number=All)
UE State: UEs can be chosen by its ECM state which include (1) all registered
UEs, (2) UEs in registered connected/active state or (3) UEs that are registered
idle.
Other UE filters:
IMSI range: All UEs in the chosen UE state within IMSI the range are load balanced.
MSISDN range: All UEs in the chosen UE state within MSISDN the range are load
balanced.
Mobile Network: All UEs in the chosen UE state within the Mobile Network the range
are load balanced
Location Area: Location areas need to be identified separately for 4G and 2G/3G. For
4G, user needs to provide Tracking area (TA) and for 2G/3G, user needs to provide
Routing area (RA). When load balancing UEs by location area, all UEs in the chosen
UE state within the specified location area are load balanced. In a UE load balancing
job, only one TA and one RA can be used.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
177 / 652
RAN (Radio Access Node): RANs need to be identified separately for 4G, 2G and 3G.
For 4G, operator needs to provide eNB, for 3G user needs to provide RNC and for 2G
user needs to provide NSE. When load balancing UEs by location area, all UEs in the
chosen UE state within the specified RAN are load balanced. In a UE load balancing
job, only one ENB, one RNC and one NSE can be used.
Operator can not mix the following ue filter in a single UE load balancing job:
-
IMSI range
MSISDN range
Mobile Network
Location Area
Radio Network
Operator can combine the following selection criteria with any load balancing request:
-
Radio type
UE State
Dynamic Drain Interval
Throttle Rate (%)
UE load balancing is started after user inputs all of the requested parameters and runs
a no-shutdown CLI command. User can abort the load balancing process by running a
shutdown command. If the load balancing job has already been completed, running
shutdown will undo any permanent conditions on the WMM imposed by UE load
balancing, either WMM is locked or WMM is quarantined.
The operator can also request the WMM (Standalone MME or SGSN or MME and
SGSN combo) to be put in lock state at the end of UE load balancing. To lock the
WMM after UE load balancing, the user must choose to load balance all UEs (100%) in
all UE states in all radio technology types (4G+3G+3G) in the WMM. Additionally, the
user can also require UE load balancing to ignore or not ignore emergency calls before
locking the WMM. If emergency calls are not to be ignored, UE load balancing process
does not lock the WMM if it finds any emergency calls. The user has the option of
aborting the load balancing or forcing a lock using the rsm_cli command to lock the
WMM.
Please refer to [R20] and [R32] procedure 11-8 on how to perform inter-WMM UE load
balancing.
The parameters used for inter-WMM load balancing depend on the 9471 WMM
configuration type, such as MME, SGSN, and combination.
Ue load balancing parameters are displayed hereafter on Figure 6-3 SAM5620 InterWMM UE Load Balancing configuration:
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
178 / 652
Figure 6-3 SAM5620 Inter-WMM UE Load Balancing configuration
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
179 / 652
6.4.9.2
Ue
load
parameters
balancing
extended
provisionable
The UE Load Balancing Dynamic Drain Interval flag allows MME to compute
dynamically the UE Load Balancing drain timer interval based on provisionable paging
parameters for the UE Load Balancing operation, which can result in much shorter wait
time at the end of UE load balancing operation and a provisionable Throttle Rate %
parameter to slow down the UE Load Balancing move rate to prevent surge in S6a
traffic from overwhelming HSS/DRA capacity. (e.g: when MME send an Update
Location Request for every moved UE even with overload protection via DRA, some
load balancing TAU events can fail due to throttling at the DRA so pacing is valuable
with or without DRA) .
Prior to implementation of the UE Load balancing extended parameters in WM9.1.0:
A hard coded timer parameter was used by MME to control the rate that the load
balancing process walks through the UE Context Database to move UEs. The value of
this parameter has been optimized to complete the largest UE move (draining all UEs
from a fully loaded MME) within a standard maintenance window. It would be
advantageous to slow down the move rate when a smaller set of UEs are to be moved,
or HSS/HLR/DRA capacity can be impacted.
The UE drain interval (hard coded at 5 minutes) was set with the largest volume of UEs
moved and consideration for the longest possible time for any UE to be paged and
complete the move process.
The MME UE Load Balancing Dynamic Drain Interval takes the product of the actual
provisionable global parameter called Number of Page Attempts UE Load Balancing
(default:2 attempts) and the provisioned T3413 timer (default timer value=6sec) settings
for those attempts and adds a 10 seconds safety margin to this calculation for
procedure latency.
[T3413 timer (attempt1) + T3413 timer (attempt2) + ] + 10 seconds = (6 + 6) + 10 =
22 (seconds). This ensures that the actual UE drain interval is never undershot during
UE Load balancing procedure.
Parameter
Dynamic drain interval
SAM Table Name
UE Load Load Balancing Inter WMM configuration
OSS ID
Ltemme.dynUELBDrainIntv
Range & Unit
Boolean
False (default)
True (enabled)
Issue 11.01
Impact of Change
No service impact.
Value
Operator Dependent; default = false (disabled)
Feature
m10702-04
LTE/DCL/APP/031094
Nokia 2016
180 / 652
The dynamic drain interval flag for UE Load Balancing, when enabled (checked),
dynamically computes the product of the global parameter Number of Page Attempts
UE Load Balancing and the T3413 timer parameter values.
Parameter
Number of Page Attempts UE Load Balancing
SAM Table Name
Global Parameters
OSS ID
Range & Unit
gParmName
String
Number of Page Attempts UE Load Balancing
gParmValue
Integer
Range : 1-4 attempts
Impact of Change
No service impact.
Value
When the dynamic drain interval flag is disabled (unchecked) , a longer, maximum
possible interval to complete the move for a UE is used (5 min) which ensures that all
UEs have moved and all transient procedures have completed prior to the UE Load
Balancing operation completion.
The UE Load Balancing Throttle Rate % provisioning parameter slows down the UE
load balancing move rate in order to protect S6a resources from overload. (set to
minimize complete drain of a maximum loaded MME within a nominal maintenance
interval) by increments of 10% from 100 % unthrottled rate (with range of 10 to 100
percent in 10 percent increments with default value of 100% )
Parameter
Throttle Rate %
SAM Table Name
UE Load Load Balancing Inter WMM configuration
OSS ID
Ltemme. uELBThrottleRate
Range & Unit
Integer
Range : 10-100 %
Issue 11.01
Impact of Change
No service impact.
Value
Feature
m10702-04
LTE/DCL/APP/031094
Nokia 2016
181 / 652
6.4.9.3
Quarantine mode
User also has another option to put either the MME in quarantine mode after the
completion of the load balancing procedure. Quarantine mode means that the MME
doesnt take on new UE contexts via Attach or TAU/RAU but will continue to serve any
remaining UE context. At the end of load balancing procedure, MME does not send
configuration update message to eNBs resetting its capacity from zero to some finite
value. The MME always sends nonzero relative capacity to eNBs at the end of UE Load
Balancing procedure that involves 4G UEs, as long as quarantine mode is not specified.
When UEs belonging to an eNB or a tracking area are targeted for UE Load Balancing
and quarantine mode for LTE is specified, the MME does not accept UE contexts from
the affected eNBs.
If an inter-system UE Move command includes UEs registered in 4G, at the end of the
move operation in the MME, if quarantine mode is not specified, the MME sends MME
Configuration Update message with normal (non-zero) Relative MME Capacity to every
eNB served by the MME, except when the move command specifies 100% of UEs in all
applicable technologies (4G+3G+2G), or 100% of UEs in a 4G only application. In this
scenario, the MME initiates WMM Aggregate Service Lock.
Also, if the quarantine mode is specified for 100% of an all-UEs move, the WMM does
not lock the WMM Aggregate Service at the end of the move operation.
Request to lock the WMM or request to quarantine all or part of WMM are mutually
exclusive. If the WMM is locked or quarantined, the affects and state can be undone by
executing a shutdown command on UE load balancing.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
182 / 652
6.5 Tracking Area Identifiers
A tracking area is an area in which an idle UE may move without signaling to an MME.
If the MME is provisioned with a particular TAI, it means that the MME can
communicate with all the eNB in that TA, or that the MME can communicate with
another MME that can communicate with all the eNB in that TA. Individual eNBs are not
provisioned into the MME database.
Note that an MME Tracking Area Identifier is composed of the PLMN and the Tracking
Area Code. That is <TAI> = <MCC> + <MNC> + <TAC>.
Once a TAI is defined, it can be assigned to an MME group. A UE may be registered in
several tracking areas. (UE registration is not part of MME provisioning.) A tracking area
may be associated with more than one MME group. (Please refer to Figure 6-2.)
Parameter
Tracking Area Code
SAM Table Name
MME Based Tracking Area; Zone Code
OSS ID
ltemme.MMETAIAbs.tAC
ltemme.MMEZoneCodeAbs.tAC
Range & Unit
Integer
[1..65533,65535]
TAC values 0 and 65534 are reserved in some special cases
when no valid TAI exists in the MS (see [R08] for more
information.
Impact of Change
No service impact.
Value

The home PLMN must be provisioned prior to provisioning Tracking Area identifiers.

The TAI must be provisioned in the MME prior to provisioning any eNB with the TAI.
The MME will reject connections from eNBs associated with unknown tracking areas.
Rule: Maximum Number of TACs

MME allows provisioning a maximum of up to 10240 TAC values.
The MME must always be provisioned with the set of TAIs that include all of the TAIs for
the MME groups provisioned into this MME. When DNS is not used for MME discovery,
it is also necessary to provision the set of TAIs for all MME groups known to this MME.
When DNS is used for MME discovery, it is not necessary to manually provision the set
of TAIs that are covered by other MME Groups.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
183 / 652
Restriction: TAI Provisioning without MME Discovery
The MME must be provisioned with the set of TAIs that include all of the TAIs for all
MME groups known to this MME when DNS is not used for MME discovery.
Rule: TAI Provisioning with MME Discovery

When DNS is used for MME discovery, the minimum set of TAIs that must be
provisioned includes all of the TAIs for the MME groups provisioned into this MME.
TAIs defined for MME groups other than this Home MME are ignored.
Rule: Deleting TAI Sequence Dependency

The TAI must be removed from all eNB elements associated with the TAI before the
TAI can be removed from the MME.
The MME rejects connections from eNBs associated with unknown Tracking Areas.
Deletion of Tracking Areas associated with active eNBs is service affecting.
Rule: Deleting TAI Sequence Dependency

The TAI must be removed from the following tables before the TAI can be removed
from the MME.
MME Group to TAI List
TAI Neighbor List
Serving Gateway Pool to TAI List
TAI to LAI Mapping
UE Roaming TAI and LAI Restriction List
MME Zone Code
The MME also supports emergency support on a per-TAI basis. All TAIs within the
MME need to have both IMS supported (ltemme.MMETAIAbs.iMSSupported=true) and
Emergency supported (ltemme.MMETAIAbs.emergencySupported=true) to support
emergency calls without operator action.
Parameter
Emergency Supported
SAM Table Name
MME Based Tracking Area
OSS ID
ltemme.MMETAIAbs.emergencySupported
Range & Unit
Boolean
Issue 11.01
Impact of Change
No service impact.
Value
Operator Dependent; default = False (not supported)
LTE/DCL/APP/031094
Nokia 2016
184 / 652
6.6 TAI Neighbor List
Each TAI assigned to an MME group can be provisioned with a set of up to 15 neighbor
TAIs. For any TAI, the set of neighbor TAIs must also be in the set of TAIs assigned to
the MME group. The set of neighbor TAIs is used in some Paging Methods to determine
the eNBs that should be sent a paging message. (Note: the TAI Neighbor List is not
used when the Paging Method is Last Seen eNB. Therefore, provisioning the TAI
Neighbor List is not necessary when Last Seen eNB is the only Paging Method used.)
The MME builds a table showing the complete TAI neighbor list for this MME, where
reciprocal neighbor relationships are provisioned automatically. That is, if TAIx is
provisioned to be a neighbor of TAIy, then the MME will automatically set TAIy to be a
neighbor of TAIx.
Note that a Tracking Area Neighbor List is composed of TAIs that are defined by their
PLMN and Tracking Area Code. That is <Neighbor TAI> = <Neighbor MCC> +
<Neighbor MNC> + <Neighbor TAC>
Rule: Neighbor TAI Identification

Neighbor MCC, Neighbor MNC, and Neighbor TAC follow the same provisioning
rules as MCC, MNC, and TAC.

The neighbor TAI must be provisioned as a TAI in the MME (Tracking Area identity
form) prior to provisioning it as a neighbor.
Restriction: TAI Neighbors

All TAIs in the TAI neighbor list must be serviced by the same SGW.
A UE cannot send a TAU request when it moves from a TAI serviced by one SGW to
another TAI serviced by a different SGW. This prohibits SGW relocation and can
cause UE session failures.
It is generally recommended to leave the TAI Neighbor List empty.
An empty TAI Neighbor List provides the expected behavior when the Include
Neighbor List in TAI List and Auto Add TAI to TAI List global parameters are at their
default values. The TAI Neighbor List can be used for special cases that are not fully
addressed by the Automatic Neighbor List Generation feature.
Provisioning of the TAI Neighbor List is optional if the only Paging Method is Last
Seen eNB.
The TAI Neighbor List is not utilized with the Last Seen eNB Paging Method. The
values in the list and settings of associated global parameters are irrelevant.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
185 / 652
6.7 UE Roaming Restriction Profile
The MME can be provisioned with a list of up to 20 TAI values and up to 20 LAI values
where handover/roaming is not allowed for the MME Home network and each of the
Equivalent PLMNs. That is, each Home and Equivalent PLMN can have a unique list of
20 restricted TAI values and 20 restricted LAI values. The PLMN of the UE (the
restricted PLMN) is used to determine the correct list to examine and then the TAI list
and/or LAI list is used to send the Handover Restriction information to the eNB for a
given UE.
A Restricted TAI is composed of the Restricted PLMN (Mobile Node Region) and the
Tracking Area Code. Likewise, a Restricted LAI is composed of the Restricted PLMN
and the Location Area Code.
Parameter
UE Roaming Restrict Profile ID
SAM Table Name
UE Roaming Restriction Profile
OSS ID
ltemme.UERoamRestrictProfileAbs.uERoamRestrictProfileId
Range & Unit
Integer
[000..999]
Impact of Change
No service impact.
Value
Parameter
List Type
SAM Table Name
UE Roaming Restriction Profile
OSS ID
ltemme.UERoamRestrictionAbs.lIST_TYPE
ltemme.UERoamRestrictProfileAbs.lIST_TYPE
Choice List
Range & Unit

TAI List, LAI List
Impact of Change
No service impact.
Value
Operator Dependent; default = TAI List
Parameter
Mobile Node Region Pointer
SAM Table Name
Select Tracking Area Information UE Roaming TAI and LAI

Restriction List
Select Location Area Information UE Roaming TAI and LAI
Restriction List
OSS ID
ltemme.UERoamRestrictProfileAbs.mobileNodeRegionPointer
Range & Unit
Integer
[000..999]
Issue 11.01
Impact of Change
No service impact.
Value
LTE/DCL/APP/031094
Nokia 2016
186 / 652
Parameter
Tracking Area Information
SAM Table Name
Select Tracking Area Information UE Roaming TAI and LAI

Restriction List
OSS ID
ltemme.UERoamRestriction.tAIPointer
Range & Unit
Integer
[1..65535]
Impact of Change
No service impact.
Value
Parameter
Location Area Information
SAM Table Name
Select Location Area Information UE Roaming TAI and LAI

Restriction List
OSS ID
ltemme.UERoamRestriction.lAIPointer
Range & Unit
Integer
[1..65535]
Impact of Change
No service impact.
Value

A TAI must be provisioned in the MME prior to provisioning the value in the TAI
Restricted List.

An LAI must be provisioned in the MME prior to provisioning the value in the LAI
Restricted List.
Restriction: Global Provisioning

The TAI and LAI Restriction Lists are globally provisioned. Field values in this form
must match across the network.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
187 / 652
6.8 Serving Gateway
Individual serving gateways (SGW) are provisioned and assigned to a serving gateway
pool. The SGW pool is then provisioned with a set of TAIs that it is able to serve. The
MME can support up to 16 SGW pools with up to 16 SGWs per pool. The MME is able
to communicate with all the SGWs in all the provisioned SGW pools.
Rule: SGW Groups

The MME supports a maximum of 16 SGW groups with a maximum of 16 SGW
entities per SGW group.
When there are multiple SGWs in the network, the SGW is selected by the MME from a
pool of SGWs based upon the tracking areas identifiers (TAIs) served by the SGW pool
or based upon Domain Name System (DNS) query procedures. Service providers may
configure whether SGW discovery and selection uses provisioned data (default) or uses
the Straightforward-Name Authority Pointer (S-NAPTR) procedure by means of the
global provisioning parameter Discover SGW.
The MME constructs a mapping of TAI to SGW Pool ID(s). MME selects an active SGW
in a pool for a UE at the time of Attach or whenever SGW needs to be changed.
During Attach, SGW selection is performed by cycling through SGWs of a selected
SGW pool in a round-robin scheme based on provisioned TAI -> SGW pools -> SGW
data. In the case where a TAI is assigned to more than one SGW pool, if the first pool is
exhausted, the selection process cycles through the next pool, cycling through pools
until an SGW is found. During TAU, if SGW relocation is required, MME uses SGW
selection to select an SGW. If MME fails to select a SGW, TAU is rejected. S11
interfaces are added/created without service disruption to the existing S11 and other
interfaces; that is, all S11 links towards SGW will be up at the time of initialization, and
S11 ECHO request/response are always on for all S11 links even if there is no UE
using the link. The links are not added dynamically. MME relocates bearers to the new
SGW (target SGW) and deletes the bearers on the source SGW (old SGW). MME is
provisioned with a timer value used in processing procedures that involve SGW
relocation but no MME relocation, and indicates when the MME deletes the UE bearers
at the source SGW. Please refer to Section 8.1.29.1 for a call flow of TAU with SGW
and MME relocation.
Rule: SGW Selection
During Attach, SGW selection is performed by cycling through SGWs of a selected
SGW pool in a round-robin scheme based on provisioned TAI to SGW pools to SGW
data.
In the case where a TAI is assigned to more than one SGW pool, if the first pool is
exhausted, the selection process cycles through the next pool, cycling through pools
until an SGW is found.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
188 / 652
6.8.1 SGW IDENTIFICATION
The SGW itself is identified by an SGW Name and an S11 IP address. When SGW
Discovery (Section 0) is ON, DNS is used to obtain the SGW IP address to serve a
particular TAI.
Parameter
SGW Name
SAM Table Name
Serving Gateway
OSS ID
ltemme.MMESGWAbs.sGWName
Range & Unit
Up to 64 alphanumeric characters from the following sets:

Impact of Change
No service impact.
Value
Parameter
S11 IP
SAM Table Name
Serving Gateway
OSS ID
ltemme.MMESGWAbs.s11IP
Range & Unit
Either IPv4 or IPv6 address
Impact of Change
No service impact.
Value
Operator Dependent; 0.0.0.0
Restriction: SGW Discovery

SGW provisioning and SGW pool provisioning is ignored when SGW Discovery is
used.
6.8.2 SGW INTER-GATEWAY PROTOCOL

The protocol used in a particular network should be the protocol supported by the PGW
elements in that network. (The PGW may support GTP or PMIP network protocols.) The
SGW is selected so it supports the PGW protocol. A mismatch in the network protocol
capabilities between the PGW and the SGW results in a failure to establish a path
between the SGW and the PGW for the UE bearer packets.
Parameter
SAM Table Name
Inter-Gateway Protocol
Serving Gateway (S11 Peer)
OSS ID
ltemme.MMESGWAbs.netProtocol
Range & Unit
Choice list
GTP, PMIP, or Both
Issue 11.01
Impact of Change
The SGW must be in a locked state to change the InterGateway Protocol parameter.
Value
Operator Dependent; default = GTP
LTE/DCL/APP/031094
Nokia 2016
189 / 652
Rule: SGW Inter-Gateway Protocol
From WM7.0.0 release all SGWs must have the same inter-gateway protocol as the
MME PLMN inter-gateway protocol. (See Section 6.1.8.)
6.8.3 SGW POOL ID

Each SGW is assigned to one (and only one) SGW Pool. The SGW Pool ID identifies
the SGW pool that the SGW belongs to. All SGW that serve the same set of TAIs are in
the same SGW pool. Therefore, only one Serving Gateway Pool to TAI List is required
for each SGW Pool ID (Section 6.8.4). When SGW Discovery (Section 0) is ON, there is
no need to provision SGW pools and pool members.
The Select Pool Information Serving Gateway List form opens from the Serving
Gateway (Create) form. This form enables selection of the SGW Pool ID.
Parameter
SAM Table Name
Pool ID
Select Pool Information Serving Gateway List
OSS ID
ltepool.SgwPool.sGWPoolID
Range & Unit
Integer
[1..20]
Impact of Change
No service impact.
Value
Engineering Recommendation: SGW Pool ID Value

When different MMEs communicate with the same set of SGWs as provisioned in an
SGW pool, it is recommended (but not required) to use the same SGW Pool ID for
that set of SGWs at each MME. That is, using the same SGW Pool ID for the same
set of SGWs across different MMEs helps avoid confusion.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
190 / 652
6.8.4 SERVING GATEWAY POOL TO TAI LIST
The MME is provisioned with the set of TAIs that each SGW pool is able to serve. The
Serving Gateway Pool to TAI List form contains the SGW Pool ID (Section 6.8.3) and
associated TAIs (Section 6.5) for each SGW pool.
For a given eNB, the MME selects an SGW from among all the SGWs in the pool(s)
that can cover the TA, so the load is roughly balanced across all the SGW elements.
When SGW Discovery (Section 0) is ON (Yes), there is no need to provision SGW
pools and pool members.
Please refer to Section 8.1.2 for more information regarding SGW selection.
The list of TAIs that the MME knows about must be provisioned prior to provisioning
the SGW pool and the TAIs that the SGW pool will serve. The SGWs and SGW
pools need to be provisioned only when SGW Discovery is OFF (No).
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
191 / 652
6.8.5 SERVING GATEWAY DISCOVERY VIA DNS
Service providers may configure whether SGW discovery and selection uses
provisioned data (default) or uses the Straightforward-Name Authority Pointer (SNAPTR) procedure by means of the Discover SGW parameter described below.
(Please refer to Section 0 for NAPTR information.)
A provisioned global parameter indicates whether or not (YES or NO) to use a DNS
query to obtain a list of SGW IP addresses for handling a given TAI. If set to yes, the
S11 Interface Managed Objects (MOs) are created dynamically. If set to 'no', the S11
Interface MOs are created from provisioned data and are deleted when this provisioning
data is removed from the system.
If provisioning is used to obtain the IP address of an SGW that handles a TAI (See
Section 6.8.4.), the database tables are organized into SGW pools. Any SGW IP
address in the same pool can serve the set of TAI values assigned to the pool.
When DNS is used to discover the SGW IP addresses, the concept of an SGW pool
and its TAI coverage is no longer applicable. Each TAI has a list of SGW IP addresses
that can serve it. The MME is provisioned with a value to indicate whether or not the
MME uses a DNS query to obtain a list of SGW IP addresses for handling a given TAI.
Issue 11.01
Parameter
Discover SGW
SAM Table Name
Global Parameters
OSS ID
Range & Unit
gParmName
String
Discover_SGW
gParmValue
Boolean
Yes or No
Impact of Change
No service impact.
Value
Operator Dependent; default = no (use provisioned S11 IP

addresses)
LTE/DCL/APP/031094
Nokia 2016
192 / 652
6.8.6 NAPTR (NAMING AUTHORITY POINTER RECORD)
The SGW discovery as specified in TS 29.303 uses straight forward NAPTR (SNAPTR) procedures. The NAPTR and S-NAPTR are specified in RFC 3403 and RFC
3958. Refer to these three documents for details on NAPTR procedure. This document
uses an example to show NAPTR capabilities and how it is used in SGW discovery.A
NAPTR record is identified by the type code 35 (defined in RFC 3403). A NAPTR query
may return multiple NAPTR RRs. The RData field of each NAPTR RR consists of six
fields:
Field Name
Description
Order
A 16-bit unsigned integer specifying the order in which the NAPTR

records must be processed. The list of NAPTR records returned must
be ordered from lowest to highest and lowest order number is tried first.
Preferences
A 16-bit unsigned integer specifying the order in which NAPTR records

with equal Order value should be processed. The lower preference
value is processed first.
Flags
A character string. S-NAPTR procedure allows only three values: A,

S and . The flags indicate further actions that need to be taken on the
records. The flag indicates that further query should be launched to
obtain additional NAPTR records. The flag will not be supported for
the SGW discovery and NOKIA will inform this restriction via user
documentation. The a and s flags are called terminal flags indicating
end of the NAPTR processing. In the case of an s flag, DNS query is
launched with the replacement field target to obtain SRV records. In the
case of an a flag, an IP address is sought for the replacement field
target.
Services
A character string that identifies a service and its associated protocol

that is supported by the host. The service names (app-service) and
protocol names (app-protocol) to be used by the EPC are specified in
section 19.4.3 of 23.003. A SGW service is identified by an app-service
name of x-3gpp-sgw. The protocol names supported by a SGW are xs5-gtp, x-s5-pmip, x-s8-gtp, x-s8-pmip, x-s11, x-s1-u, x-s2apmip, x-s2a-pmip, and x-s2b-pmip. MME only cares about x-s5gtp, x-s5-pmip, x-s8-gtp, x-s8-pmip and x-s11 protocol names.
Regular
Expression
A character string. The will not be used by the EPC discovery

procedures.
Replacement
A domain name in label format. This is the next domain name to query
to obtain A, AAA or SRV records.
Restriction: Flag
The flag will not be supported for the SGW discovery and NOKIA will inform this
restriction via user documentation.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
193 / 652
Example 1: MME S-NAPTR procedure for SGW discovery and selection with only
a flag:
Assume MME needs to discover and select SGW for a TAU with SGW relocation (nonroaming). The new TAI is 2304, GTP bearer and MME needs to discover a SGW that
supports GTP S5 interface, i.e. service x-3gpp-sgw:x-s5-gtp.
1. MME constructs FQDN using the new TAI for obtaining NAPTR records. The
FQDN used is shown in the following:
IMSI in use: 234150999999999
MCC = 234,
MNC= 15 and
MSIN = 0999999999
FQDN for a TAC of 2304 is
tac-lb04.tac-hb23.tac epc.mnc015.mcc234.3gppnetwork.org
2. DNS server sends all the NAPTR records for all the services as shown in the
following table. In addition, it may also give A and AAAA records. In this
example, the server returns records with a flag. The following table shows the
NAPTR record Rdata:
Order
Prefer
ences
Flags
Services
Replacement
400
999
x-3gpp-sgw:x-s8-gtp
topoff.eth9.gw01.nodes.$ORIGIN
100
999
x-3gpp-sgw:x-s5-gtp
100
999
x-3gpp-sgw:x-s11
300
999
x-3gpp-sgw:x-s11
300
999
x-3gpp-sgw:x-s5
3. MME has to select a node that offers service x-3gpp:sgw:x-s5-gtp based on

the Order field. In addition it has to determine whether traffic distribution is
required or not. In this example, there are two SGW nodes that offer the
service: gw01 and gw25. MME selects record in row 2 as it has low Order
number i.e. gw01. The gw01 is used as the primary GW and gw025 is used as
the secondary GW.
4. MME selects S11 service on the same gw01.
5. MME queries for A and AAAA records for the S11 interface if they were not
received along with the NAPTR query.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
194 / 652
Example 2: MME S-NAPTR procedure for SGW discovery and selection with s
flag:
Assume MME needs discover and select SGW for TAU with SGW relocation (nonroaming). The new TAI is 2304. The session uses GTP bearer. In this case, MME need
to discover a SGW that supports GTP S5 interface, i.e. service x-3gpp-sgw:x-s5-gtp.
1. MME constructs FQDN using the new TAI for obtaining NAPTR records. The
FQDN used is shown in the following:
IMSI in use: 234150999999999
MCC = 234,
MNC= 15 and
MSIN = 0999999999
FQDN for a TAC of 2304 is
tac-lb04.tac-hb23.tac epc.mnc015.mcc234.3gppnetwork.org
2. DNS server sends all the NAPTR records for all the services as shown in the
following table. In addition, it may also give A and AAAA records.
The following table shows the NAPTR record Rdata:
Order
Prefer
ences
Flags
Services
Replacement
400
999
x-3gpp-sgw:x-s8-gtp
_x-3gpp-sgw._x-s8.$ORIGIN
100
999
x-3gpp-sgw:x-s5-gtp
x-3gpp-sgw._x-s5.$ORIGIN
100
999
x-3gpp-sgw:x-s11
300
999
x-3gpp-sgw:x-s11
In this example, the server returns records with s flag.

3. The DNS server may return all SRV records for the domain names _x3-3gppsgw._x-s8.$ORIGIN and also for _x-3gpp-sgw.x-s5.$ORIGIN. If not the MME
launches a query to obtain SRV records for the domain name _x3gpp-sgw.xs5.$ORIGIN.
4. The DNS server returns a set of SRV records. Only the fields in the RData are
shown in the following table.
Issue 11.01
Priority
Weight
Port
Node Name
999
6000
999
6000
999
6000
999
6000
999
6000
LTE/DCL/APP/031094
Nokia 2016
195 / 652
MME selects the SGW with priority 1 and uses all other hosts as backup. If host
topoff.eth9.gw01.nodes.$ORIGIN cannot be reached then MME would assign sessions
to hosts topoff.eth10.gw02.nodes.$ORIGIN and topoff.eth11.gw03.nodes.$ORIGIN in
round-robin fashion as these hosts has same priority and weight. MME obtains A and
AAAA records for the S11 interface for the selected SGW.A mobility procedure will fail if
MME cannot obtain S5 and S11 services on the same MME. The mobility procedure
that requires SGW selection is initial Attach and also in the case of TAU and HO if new
TAI is not serviced by the current SGW. Attach procedure is rejected if a SGW can not
be selected. In the case of TAU, MME would reject TAU with SGW relocation if a SGW
cannot be selected to service the new TAI. Similarly, HO would fail, if a SGW serving
the TAI cannot be obtained.
The following guidelines and rules simplify and provide efficient method of node
discovery.
Service providers deploy a DNS server/servers appropriately configured to

enable SGW selection. They may provide a primary and second DNS server IP
addresses for reliability.
Service providers use domain names, service names and protocol names as
specified in 23.003 and 29.303. Allowed services are
_ x-3gpp-sgw:x-s8-gtp (for 3.0 roaming feature),
_ x-3gpp-sgw:x-s8-pmip (for 3.0 roaming feature),
_ x-3gpp-sgw:x-s5-gtp,
_ x-3gpp-sgw:x-s5-pmip and
_ x-3gpp-sgw:x-s11.
Note: MME does not support PMIP.

MME picks a node based on the service and uses S11 interface on the node to
communicate with that node.
It is expected that service providers use the following rules in configuring records
in their DNS servers for TAI domain name for the services mentioned above to
simplify the use of S-NAPTR:
o
Issue 11.01
NAPTR records with a flag will only be configured. If MME receives

NAPTR records for the same service with a and s flags, MME uses
the NAPTR records with a flag.
LTE/DCL/APP/031094
Nokia 2016
196 / 652
o
If NAPTR record with a flag is used for a service, service providers

can have up to ten records. If a distribution of traffic is required then
service providers shall set Order field of each field to the same value
and also the Preference field shall be set to a value to reflect the nodes
capacity. MME assigns sessions to a SGW proportionate to the value
of the Preferance field. If service providers choose to select a primary
and backup SGWs then the primary nodes Order field shall be set to
the lowest value. MME only selects the primary SGW and other SGW
are selected if the primary SGW can not be reached. Each of the
nodes selected may have multiple A or AAAA records for S11
interface. MME distributes the traffic in round-robin fashion if query
returns multiple A and AAAA records. Only one type transport will be
used: IPv4 or IPv6. In this case, DNS server must return NAPTR RR
and its associated A and AAAA records. Service providers must restrict
maximum number of A or AAAA records to 2 for S11 interface on each
SGW assuming that SGW uses GigE interfaces. MME is not required
to query for A and AAAA records for s5 and s8 as MME has no use
for these IP addresses.
If NAPTR records with s flag is used, service provider are required to

send only a single NAPTR RR for a given service, its associated SRV
records, A and AAAA records. A maximum of 8 SRV records can be
supported with each node supporting two A or AAAA S11 records.
MME uses the priority and weight fields to determine whether to
distribute the traffic across the nodes or use one as a primary and
other nodes as backups. If a distribution of traffic is required then
service providers shall set the Priority field of each field to the same
value and the Weight field shall be set to a value to reflect the nodes
capacity. . MME assigns sessions to the SGWs proportionate to the
value of the Weight field. If service providers choose to select a primary
and backup SGWs then the primary nodes Priority field shall be set to
the lowest value. MME only selects the primary SGW and backup
SGW are selected if this SGW can not be reached. Each of the NAPTR
record may have multiple A or AAAA records for S11 interface. MME
distributes the traffic in round-robin fashion if query returns multiple A
and AAAA records.
Service providers use a hierarchical canonical naming scheme with common
o
prefixes if they use topon as the first label.
DNS server configured to provide not only S-NAPTR and/or SRV records but
also A and AAAA records in a single query to avoid multiple queries.
It is recommended to use large TTL values (in days) to minimize number of DNS
queries.
MME is the only node in the EPC that runs the S-NAPTR procedure.
Rule: S-NAPTR
The MME is the only node in the EPC that runs the S-NAPTR procedure.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
197 / 652
6.9 MSC
Provisioning MSC servers, LAIs, etc. is required when the network contains a CS
domain. The SGs interface is used for the mobility management and paging procedures
between ePS and the CS domain. The Sv interface is used for voice call continuity
(session transfer) from IMS voice over PS access to CS voice access for calls that are
anchored in IMS when the UE is capable of transmitting/receiving on only one of these
access networks at a given time.
6.9.1 MSC SERVER ID

The MME can be provisioned with up to 128 MSC Server IP addresses for setting up
SGs and Sv communications. The MSC Server itself is identified by a unique ID, a
name and up to 4 IP Ids. The MME uses each IP address to set up an SCTP
association with the MSC server. The MME distributes the UEs across the set of SCTP
associations. Note: the Remote End Point Configuration form is used to associate an IP
Id with an IP address and IP port. See Section 6.10.
Rule: MSC ID
The MSC identifier must be unique within the MME.
Parameter
SAM Table Name
MSC ID
Mobile Switching Center Server (MSC)
OSS ID
ltemme.MSCServerAbs.mSCSrvId
Range & Unit
Integer
[1..128]
Impact of Change
An MSC Server can be added post installation, as needed. An

MSC server must be in the locked state before it can be
deleted.
Value
Parameter
SAM Table Name
MSC Name
OSS ID
ltemme.MSCServerAbs.mSCSrvName
Range & Unit
Up to 64 ascii characters from the following sets:

Issue 11.01
Impact of Change

deleted.
Value
LTE/DCL/APP/031094
Nokia 2016
198 / 652
Parameter
Discover SRVCC MSC
SAM Table Name
Global Parameters
OSS ID
Range & Unit
gParmName
String
Discover_SRVCC_MSC
gParmValue
Boolean
Yes or No
Impact of Change
No service impact.
Value
Parameter
MSC E.164 Address
SAM Table Name
OSS ID
ltemme.MSCServerAbs.mSCSrvE164Address
Range & Unit
Integer
[0..15]
Issue 11.01
Impact of Change

deleted.
Value
Parameter
Remote Endpoint SV IP
SAM Table Name
OSS ID
ltemme.MSCServer.rmtEndPtCfgPointerSV
Range & Unit
IP Address
Impact of Change
No service impact.
Value
Operator Dependent; default = 0 (no MSC IP Id)
LTE/DCL/APP/031094
Nokia 2016
199 / 652
Parameter
MSC IP Id 0, MSC IP Id 1, MSC IP Id 2, MSC IP Id 3
SAM Table Name
OSS ID
ltemme.MSCServer.rmtEndPtCfgPointer
ltemme.MSCServer.rmtEndPtCfgPointer1
Integer
[0..200]
Range & Unit

Configuration form
Impact of Change
No service impact.
Value
Operator Dependent; default = 0 (no MSC IP Id)

The IP Identifier must be provisioned in the Remote End Point Configuration form
(Section 6.10) prior to provisioning in this MSC Server form.
Rule: Deleting MSC Server

The MME must be in a locked state prior to deleting an existing MSC Server.
Use the rsm_cli command or the SAM GUI to lock and unlock the MME.
Rule: SRVCC Provisioning Dependency

The Sv IP Identifier must be provisioned with the MSC address (E164).
Either both parameters must be set to 0/NULL, or both parameters must be
provisioned with other values.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
200 / 652
6.9.2 SGS MESSAGE DELIVERY RETRY ATTEMPTS
The MME allows delivery retry attempts for several SGs message types. The behavior
can be defined via the MME Instance (Edit) form. Expand the Message
Retransmissions object in the navigation tree to view the properties of each
retransmission parameter. The form provides default values for each of the SGs
message types, but the form should be reviewed to determine whether or not the
defaults provide adequate performance. Updates should be made to the form as
required.
At this time, the default values listed on the SGs Message Delivery Retry Attempts
form are the recommended settings. However, when an MSC server is provisioned in
the network, users are encouraged to review the form to ensure compatibility with
their network.
Parameter
SAM Table Name
OSS ID
Ns8, Ns9, Ns10, Ns12

Message Retransmissions
ltemme.MSGRetriesAbs.mSGName
ltemme.MSGRetriesAbs.mSGNumRetries
Range & Unit

ltemme.MSG
RetriesAbs.
mSGName
ltemme.MSGRetriesAbs.mSGNumRetries
Timer Name
Ns8
Ns9
Ns10
Ns12
Default
Value
2
2
2
2
Range
Granularity
1-4
1-4
1-4
1-4
1
1
1
1
Impact of Change
No service impact.
Value
Operator Dependent; see above for default values.
Rule: Total Number of Delivery Attempts

The total number of attempts to deliver a message is the Number of Retransmissions
plus 1 (the original transmission attempt).
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
201 / 652
6.9.3 LOCATION AREA CODE
If the MME is provisioned with a particular LAI, it means that the MME can
communicate with all the NB in that location area (or MSC).
A Location Area Identifier is composed of the PLMN and the Location Area Code. That
is <LAI> = <MCC> + <MNC> + <LAC>.
Once an LAI is defined, it can be mapped to an MSC (using the LAI to MSC Mapping
form) and then to 1 or more TAIs (using the TAI to LAI Mapping form).
Parameter
Location Area Code
SAM Table Name
Location Area Code
OSS ID
ltemme.MMELAIAbs.lAC
Range & Unit
Integer
[1..65535]
Impact of Change
A Location Area Code cannot be deleted if it is mapped to an

MSC.
Value

The home PLMN and roaming PLMNs must be provisioned prior to provisioning
Location Area identifiers.
Rule: LAI Identification

LAI MCC, LAI MNC, and LAC follow the same provisioning rules as MCC, MNC, and
TAC.

The LAI must be provisioned in the MME (Location Area Code form) prior to
provisioning the LAI to MSC Mapping, the TAI to LAI Mapping, and the UE Roaming
TAI and LAI Restriction List.
Rule: LAI to MSC Mapping

An LAI can be mapped to up to four VLRid values, where each VLRid value is an
MSC. Note that in the case of SMS only feature for in-bound roamers for operators
that deploy a dedicated Inter-Working Function (IWF) in the place of a 3GPP
MSC/VLR, there is only one LAI that maps to all the MSC/VLRs.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
202 / 652
Rule: TAI to LAI Mapping

A TAI can be mapped to one and only one LAI. However, several TAIs can be
mapped to the same LAI. Additionally, all neighbor TAI values must be mapped to
the same LAI value.
The MME builds the inverse table of LAI to TAI mapping based on this TAI to LAI
provisioning. That is, the MSC is mapped to a list of TAI values that it covers.
Rule: Deleting LAI Sequence Dependency

The LAI must be removed from the following tables before the LAI can be removed
from the MME :
LAI to MSC Mapping
UE Roaming TAI and LAI Restriction List
6.9.4 MSC/VLR (IWF) LOAD BALANCING

The MSC load balance algorithm option IMSI Has can be enabled to assign UEs
based on the hash value derived from the UE IMSI (3GPP TS 23.272.) for the
MSC/VLR (IWF) for the CSFB and SMS services.
By default as in the previous release, the MSC/VLR load balance algorithm is set to
round robin when multiple MSC/VLRs served the same LAI.
Parameter
MSC Load Balance
SAM Table Name
Global Parameters
OSS ID
Range & Unit
gParmName
String
MSC Load Balance
gParmValue
Round Robin
IMSI Hash
Impact of Change
No service impact.
Value
Operator Dependent; default = Round Robin
Feature Name
m30101-07
In WM10.0.0, the MME supports provisionining of a dedicated IWS-SMS or MSC/VLR

for low access priority devices attached with SMS only service.
The MME uses the UE LPA marking at the registration time for selecting MSC/VLR if
the MSC/VLR dedicated to LPA UE is provisioned.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
203 / 652
MME continues to use the same MSC/VLR irrespective of LPA treatment.
MME selects MSC designated for the SMS only LPA UE for the LPA UE performing
combined Attach or TAU request with SMS only option if the MSC Server parameter
LPA SMS Only UE is enabled.
If there are multiple MSCs then MME uses the provisioned MSC load balancing
Parameter
LPA SMS Only UE
SAM Table Name

ltemme.MSCServer. lpaSmsOnlyUe
OSS ID
Boolean
Range & Unit
True/False
Impact of Change
No service impact.
Value
Feature Name
m10115-01
When multiple MSCs are configured, MME applied MSC selection algorithm defined in
the global parameter MSC Load Balance to select SMS-only MSC for combined attach
from LPA SMS UE.The LPA SMS UE includes Additional Update Type IE with value set
to SMS-only is included in combined attach request or TAU request.
If SGsAP Location Update times out after all the attempts or if MSC/VLR rejects the
Location Update message with cause Congestion for a UE then MME selects an
alternate MSC/VLR if there are multiple MSC/VLR provisioned. MME retries up two
times other MSC/VLR.
This operating principle applies to both combined attach request and TAU request, but it
applies also to both LPA and non-LPA UE.
Parameter
MSC VLR Reselection
SAM Table Name
Global Parameters
OSS ID
Range & Unit
gParmName
Boolean
MSC VLR Reselection
gParmValue
True/False
Issue 11.01
Impact of Change
No service impact.
Value
Feature Name
m10115-01
LTE/DCL/APP/031094
Nokia 2016
204 / 652
6.10 Remote End Point Configuration
The MME requires manual configuration of an end point profile for all S13, S6A, SBC,
SGs, SLg, SLs, and Sv interfaces. Each end point definition contains a profile identifier
(IP ID), an indication of the associated interface type, the primary IP address for the
remote end point (Address 1), and a port number. When remote-end multi-homing is
supported, a secondary IP address (Address 2) may also be entered.
Once an IP address is defined in this profile, the associated IP ID can be provisioned in
the MSC Server form (SGs), Diameter Connections form (S6ad or S13), SBc Peer form
(SBc), ESMLC form (SLs), IMSI to HSS Routing form (S6ad) and Public Land Mobile
Network (PLMN) (Create) form.
Engineering Recommendation: Updating and Deleting End Point Configuration Data

There is a service impact when updating or deleting remote end points. However the
service impact can be avoided by creating another remote endpoint profile and
moving the existing interface to the newly created profile.
The parameter DRASupported in the Remote End Point table enables or disables DRA
support on a per link basis for S6ad, SLg, and S13.
If set to Yes (DRASupported is enabled), the provisioned value for DRA Destination
Realm Name and optional DRA Destination Host name is used in the initial diameter
request message from the MME.
Issue 11.01
Parameter
DRA Supported
SAM Table Name
Remote Endpoint
OSS ID
ltemme.MMERmtEndPtCfgAbs.draSupported
Range & Unit
Boolean
Yes (checked) or No (unchecked)
Impact of Change
No service impact.
Value
Feature
m11311-01
LTE/DCL/APP/031094
Nokia 2016
205 / 652
Parameter
DRA Destination Host Name
SAM Table Name
Remote Endpoint
OSS ID
ltemme.MMERmtEndPtCfgAbs.draDestHostFQDNName
Range & Unit
string
Impact of Change
Updating and/or deleting remote end point configuration

data impacts service. Please refer to Engineering
Recommendation: Updating and Deleting End Point
Configuration Data above.
Value
Operator Dependent;
Feature
m11311-01
Parameter
DRA Destination Realm Name
SAM Table Name
Remote Endpoint
OSS ID
ltemme.MMERmtEndPtCfgAbs.draDestRealmFQDNNa
me
Range & Unit
string
Impact of Change

Value
Operator Dependent;
Feature
m11311-01
Parameter
IP ID
SAM Table Name
Remote Endpoint
OSS ID
ltemme.MMERmtEndPtCfgAbs.endPtId
Integer
Range & Unit

[0..1024], see recommendation below.
Impact of Change
Value
Issue 11.01

LTE/DCL/APP/031094
Nokia 2016
206 / 652
Engineering Recommendation: IP ID Values
It is recommended to use the following ranges when defining remote end point
profiles:
-
[1..100], for S6a, SBc and S13 interfaces
[101..200], for SGs interfaces
[0], reserved for an unused profile
The recommendation allows for enough S6a and S13 entries when converting
HSS/EIR from IPv4 to IPv6.
Operator can select any range for SLg, SLs, and Sv endpoints.
Parameter
Interface Type
SAM Table Name
Remote Endpoint
OSS ID
ltemme.MMERmtEndPtCfgAbs.interfaceName
Range & Unit
Choice List
S6ad, SBc, S13, SGs, SLg, SLs, Sv
Impact of Change
Updating and/or deleting remote end point configuration data

impacts service. Please refer to Engineering
Value
Two diameter connections within same DRA can share same IP addresses at the
remote ends but different port, when both connections terminated on the same interface
blade of DRA.
S6ad provisioned remote IPs can be the same; however remote ports in remote end
point table must be different.
For example, MME support the following remote endpoint configuration:
- MME S6a interface IP address locally configured: 172.0.0.1, 172.0.0.2
- S6a Endpoint of diameter connection 1: 1 pair of IP address (172.1.1.1, 172.1.1.2),
port 3870
- Endpoint of diameter connection 2: 1 pair of IP address (172.1.1.1, 172.1.1.2), port
3871
- Diameter connection 1 and 2 have same remote endpoint IP address with different
SCTP ports
Engineering Recommendation: Shared IP Addresses
If the same DRA is used for routing S6a, S13/S13', and SLg the Remote End-Point
definitions for S6a, S13/S13', and SLg are sharing the same IP addresses different
ports must be used to result in different SCTP associations.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
207 / 652
Parameter
Address 1
SAM Table Name
Remote Endpoint
OSS ID
ltemme.MMERmtEndPtCfgAbs.iP_1
Range & Unit
IPv4 or IPv6 IP address
Impact of Change

Value
Parameter
Address 2
SAM Table Name
Remote Endpoint
OSS ID
ltemme.MMERmtEndPtCfgAbs.iP_2
Range & Unit
IPv4 or IPv6 IP address

Must use the same protocol as Address 1
Impact of Change

Value
Parameter
Port
SAM Table Name
Remote Endpoint
OSS ID
ltemme.MMERmtEndPtCfgAbs.port
Range & Unit
Integer
[1024..65535]
Impact of Change
Value

Operator Dependent; defaults: S6a = 3868, S13 = 3868, SGs =

29118, SLs = 9082, SLg = 3868, SBC = 29168
The Remote Endpoint table also contains a Shutdown Reconnect Timer parameter. The
table should be reviewed to determine whether or not the default value provides
adequate performance. Updates should be made as required. Please refer to [R28] for
further information.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
208 / 652
6.11 Circuit Switched Fallback (CSFB)
The CS Capability Supported field indicates the SGs-based CS Fallback Support for
Home UEs and all UEs that roam into the MME Home Network.
Parameter
CS Capability Supported
SAM Table Name
UE PLMN Services,
OSS ID
ltemme.SVCAgreementProfile.cS_Cap_Supported
ltemme.UEPLMNServices.cS_Cap_Supported
Range & Unit
Choice List
SGS_None
SMS_Only
CSFB_2G3G
CSFB_Not_Preferred
Impact of Change
No service impact.
Value
Operator Dependent; default = CSFB_2G3G
Rule: CSFB Capability Definitions

The CSFB capabilities are defined as follows:
SGS_None (specifies no CSFB or SMS support)
SMS_Only (specifies no CSFB support, only SMS support)
CSFB_2G3G (specifies CSFB support for voice and SMS)
CSFB_Not_Preferred (specifies CSFB support for voice and SMS, although

voice is not preferred.if UE has IMS PS Voice available, it will be used)
A UE can signal its UE Voice Domain preference for E-UTRAN as one of the following:
CS Voice Only (CS RFSP)
IMS PS Voice Only (IMS RFSP)
CS Voice Preferred, IMS PS Voice as Secondary (CS Preferred RFSP)
IMS PS Voice Preferred, CS Voice as Secondary (IMS Preferred RFSP)
Each PLMN is provisioned with an IMS RFSP Index to use for each voice domain
preference. If the UEs voice domain preference is not known, the MME selects the
RFSP Index value from the HSS (for non-roamer UEs) or the MME selects the
provisioned generic RFSP Index value (for a roamer UE).
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
209 / 652
Parameter
CS RFSP
SAM Table Name
UE PLMN Services,
OSS
ltemme.SVCAgreementProfile.cS_RFSP
ltemme.UEPLMNServices.cS_RFSP
Range & Unit
Integer
provides the value.
Impact of Change
No service impact.
Value

100 for ltemme.MMEPLMN.cS_RFSP;
255 for ltemme.UEPLMNServices.cS_RFSP
Parameter
IMS RFSP
SAM Table Name
UE PLMN Services,
OSS
ltemme.UEPLMNServices.iMS_RFSP
ltemme.SVCAgreementProfile.iMS_RFSP
Range & Unit
Integer
provides the value.
Impact of Change
No service impact.
Value

100 for ltemme.MMEPLMN.iMS_RFSP;
255 for ltemme.UEPLMNServices.iMS_RFSP
Parameter
CS Preferred RFSP
SAM Table Name
UE PLMN Services,
OSS
ltemme.SVCAgreementProfile.cS_PrefRFSP
ltemme.UEPLMNServices.cS_PrefRFSP
Range & Unit
Integer
provides the value.
Impact of Change
Value
No service impact.

100 for ltemme.MMEPLMN.cS_PrefRFSP;
255 for ltemme.UEPLMNServices.cS_PrefRFSP
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
210 / 652
Parameter
IMS Preferred RFSP
SAM Table Name
UE PLMN Services,
OSS
ltemme.SVCAgreementProfile. iMS_PrefRFSP
ltemme.UEPLMNServices.iMS_PrefRFSP
Range & Unit
Integer
provides the value.
Impact of Change
No service impact.

100 for ltemme.MMEPLMN. iMS_PrefRFSP
Value
256 for ltemme.UEPLMNServices.iMS_PrefRFSP
Parameter
IMS Supported
SAM Table Name
OSS
ltemme.MMETAIAbs.iMSSupported
Range & Unit
Boolean
Impact of Change
No service impact.
Value
Operator Dependent; default = False (IMS not supported)
Parameter
Is CSFB Supported?
SAM Table Name
Location Area Code
OSS
ltemme.MMELAIAbs.cSFBSupported
Range & Unit
Boolean
Impact of Change
Value
No service impact.
Operator Dependent; default = False (SMS-only)
Note: True indicates SGs-based CSFB is CS Voice and SMS
When deploying SMS service over the SGs interface without supporting CSFB voice
calls (CSFB for SMS-only), the MME home network (MCC, MNC, LAC) that supports
the SMS-only feature must be provisioned if TAI-LAI mapping is not used.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
211 / 652
6.11.1 SMS ONLY POINTER
When deploying SMS service over the SGs interface without supporting CSFB voice
calls (CSFB for SMS-only), the MME home network (MCC, MNC, LAC) that supports
the SMS-only feature must be provisioned if TAI-LAI mapping is not used.
Parameter
SMS Only Pointer, Mobile Country Code
SAM Table Name
OSS ID
ltemme.SVCAgreementProfile.smsonlyMcc
Range & Unit
Integer
[000..999]
Impact of Change
No service impact.
Value
Operator Dependent; default: none
Parameter
SMS Only Pointer, Mobile Network Code
SAM Table Name
OSS ID
ltemme.SVCAgreementProfile.smsonlyMnc
Range & Unit
Integer
[000..999]
Impact of Change
No service impact.
Value
Parameter
SMS Only Pointer, Location Area Code
SAM Table Name
OSS ID
ltemme.SVCAgreementProfile.smsonlyLAC
Range & Unit
Integer
[1..65535]
Issue 11.01
Impact of Change
No service impact.
Value
LTE/DCL/APP/031094
Nokia 2016
212 / 652
6.11.2 DATA CENTRIC UE
For each UE voice capability provisioned in Section 6.11, the MME adds a data centric
RFSP index value. This allows independent support for voice centric UEs and data
centric UEs. A voice centric UE will always attempt to find a RAT where voice services
can be supported. A data centric UE will always attempt to find the best possible PS
access; voice is not a determining factor to move away from an ePS.
Parameter
SAM Table Name
OSS ID
CS RFSP for Data Centric UE

UE PLMN and Served PLMN Service Agreement Profile , UE
PLMN Services
ltemme.UEPLMNServices.cS_RFSP_DATACENTRICUE
ltemme.SVCAgreementProfile.cS_RFSP_DATACENTRICUE
Integer
Range & Unit
[0..256]
Impact of Change
No service impact.
Value
Parameter
CS Preferred RFSP for Data Centric UE

PLMN Services
ltemme.UEPLMNServices.cS_PrefRFSP_DATACENTRICUE
ltemme.SVCAgreementProfile.cS_PrefRFSP_DATACENTRIC
UE
SAM Table Name

OSS ID
Integer
Range & Unit
[0..256]
Impact of Change
No service impact.
Value
Parameter
IMS RFSP for Data Centric UE

PLMN Services
SAM Table Name

OSS ID
ltemme.UEPLMNServices.iMS_RFSP_DATACENTRICUE
ltemme.SVCAgreementProfile.iMS_RFSP_DATACENTRICUE
Range & Unit
Integer
[0..256]
Issue 11.01
Impact of Change
No service impact.
Value
LTE/DCL/APP/031094
Nokia 2016
213 / 652
Parameter
SAM Table Name
OSS ID
IMS Preferred RFSP for DATA Centric UE

PLMN Services
ltemme.UEPLMNServices.iMS_PrefRFSP_DATACENTRICUE
ltemme.SVCAgreementProfile.iMS_PrefRFSP_DATACENTRIC
UE
Integer
Range & Unit
[0..256]
Impact of Change
No service impact.
Value
Parameter
RFSP Index for Voice Capable UEs

PLMN Services
ltemme.UEPLMNServices.rFSPIndex_VoiceCapableUE
ltemme.SVCAgreementProfile.rFSPIndex_VoiceCapableUE
SAM Table Name

OSS ID
Integer
Range & Unit
[0..128]
Impact of Change
No service impact.
Value
6.12 S102-Based Circuit Switched Fallback (eCSFB)

The MME supports the following additional functions when CSFB to 1xRTT is enabled:
It serves as a signalling tunnelling end point towards the 3GPP2 1xCS IWS via
S102 interface for sending/receiving encapsulated 3GPP2 1xCS signalling
messages to/from the UE, which are encapsulated in S1-MME S1 CDMA2000
Tunneling messages, as defined in TR 36.938.
It provides 1xCS-IWS (terminating S102 reference point) selection for CSFB

procedures.
It supports handling of S102 tunnel redirection in case of MME relocation.
If the network supports CSFB priority call handling, the MME supports the following
additional functions:
For page messages received on the S102 interface with priority indication, the
MME provides preferential treatment to this message and also the subsequent
CSFB procedure compared to other normal transactions. If the UE needs to be
paged, the MME sets priority indication on the paging request to eNodeB. The
MME also sets priority indication, i.e. "CSFB High Priority", in the S1AP message
to the eNodeB, so that eNodeB may initiate the CSFB procedure with priority, as
specified in TS 36.413.
For a CSFB request from the service user, the MME determines if the CSFB
request requires priority handling based on the UE's EPS subscription
information. If the MME is in a congestion situation, it provides preferential
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
214 / 652
treatment to this request and also sets priority indication, i.e. "CSFB High
Priority", in the S1AP message to the eNodeB to initiate the CSFB procedure, as
specified in TS 36.413
The MME selects the 3GPP2 1xCS IWS based upon the local configuration in the MME.
The MME is provisioned with a map of 1x MSC ID to 1xCS IWS IP address, where the
1x MSC ID value is the first 3 octets (first 24 contiguous bits) of the reference cell ID IE
received in the CDMA2000Uplink message. The coding of the reference cell ID is
shown in the figure below.
Octet
A21 Element Identifier
Length
MCSID
MSB
4
LSB
5
6
Cell
MSB
Cell
Identifier
Sector
LSB
Legend:
Length field contains the number of octets in this IE following this field, as a
binary number.
MSCID field contains the MSC identifier, as 24 contiguous bits contained within
the 3 octets. The first 2 octets (octets 3 and 4) represent the Market ID and the
last octet represents the Switch Number. In the MSCID field, bit 7 of octet 3 is the
most significant bit of the Market ID field and bit 0 of octet 4 is the least significant
bit of the Market ID field. Bit 7 of octet 5 is the most significant bit of the Switch
Number field and bit 0 of octet 5 is the least significant bit of the Switch number
field.
Cell field contains the cell identifier, as 12 bits.
Sector field contains sector number, as 4 bits.
Provisioning that is required to activate an S102 interface includes interface

configuration [R28], MSC to IWS mapping, and Allowing S102 in the MME service
Agreement profile.
Some provisioning is optional because defaults have been provided. Users are
encouraged to review the parameters to ensure compatibility with their network.
Optional provisioning includes S102 Tack Timer [R28], S102 paging policy (See Section
8.1.31.8), S102 Paging Priority Profile, S102 Call Priority Paging Profile, and Ns102
message retransmissions (See Section 0).
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
215 / 652
Parameter
MSC to IWS Name
SAM Table Name
MSC to IWS provision
OSS ID
ltemme.MscToIws.mscIwsSrvName
Range & Unit
Alphanumeric String
Up to 64 ascii characters
Impact of Change
No service impact.
Value
Parameter
MSC Server ID
SAM Table Name
OSS ID
ltemme.MscToIws.mscIwsSrvID
Range & Unit
Integer
[0..16777215]
Impact of Change
Value must equal the first 3 octets (first 24 contiguous bits) of

the reference cell ID IE received in the CDMA2000Uplink
message.
Value
Parameter
1x CS IWS IP
SAM Table Name
OSS ID
ltemme.MscToIws.ip1xCsIws
Range & Unit
Valid IPv4 or IPv6 address
Impact of Change
No service impact.
Value
Parameter
Heart Beat
SAM Table Name
OSS ID
ltemme.MscToIws.htBt
Range & Unit
Boolean
Issue 11.01
Impact of Change
No service impact.
Value
LTE/DCL/APP/031094
Nokia 2016
216 / 652
Parameter
Heart Beat Time Out
SAM Table Name
OSS ID
ltemme.MscToIws.htBtTmOut
Range & Unit
Integer
[1..300] sec, 1 sec interval
Impact of Change
No service impact.
Value
Parameter
S102 Services Allowed
SAM Table Name
OSS ID
ltemme.SVCAgreementProfile.s102Allowed
Range & Unit
Boolean
Impact of Change
No service impact.
Value
Parameter
S102 Paging Priority Profile ID

S102 Paging Priority Profile
S102 Call Priority Paging Profile
ltemme.S102PagingPriProfile.s102PagingPriProfileID
ltemme.S102CallPriPagingProfile.s102PagingPriProfileID
SAM Table Name

OSS ID
Integer
Range & Unit
[1..8]
Impact of Change
No service impact.
Value
Parameter
No Call Priority Paging Priority Level
SAM Table Name
OSS ID
ltemme.S102PagingPriProfile.NoCallPriPagingPriLevel
Range & Unit
Integer
[PrioLevel0..PrioLevel8]
Issue 11.01
Impact of Change
No service impact.
Value
Operator Dependent; default = PrioLevel0
LTE/DCL/APP/031094
Nokia 2016
217 / 652
Parameter
GEC Emergency Paging Priority Level
SAM Table Name
OSS ID
ltemme.S102PagingPriProfile.gECEmerPagingPriLevel
Range & Unit
Integer
Impact of Change
No service impact.
Value
Parameter
S102 Call Priority
SAM Table Name
OSS ID
ltemme.S102CallPriPagingProfile.s102CallPriority
Range & Unit
Integer
[0..15]
Impact of Change
No service impact.
Value
Parameter
S1AP Paging Priority Level
SAM Table Name
OSS ID
ltemme.S102CallPriPagingProfile.s1APPagingPriLevel
Range & Unit
Integer
Issue 11.01
Impact of Change
No service impact.
Value
LTE/DCL/APP/031094
Nokia 2016
218 / 652
6.13 Shared Network Support
Network sharing is a way for operators to share the deployment costs for mobile
networks by allowing different core network operators to connect to a shared radio
access network (RAN). Support of network sharing requires additional functionalities on
the eNB and MME. Starting in Release 8, all E-UTRAN and UTRAN capable UEs are
required to comply with network sharing requirements, among them PLMN selection
and reception of network sharing related system information.
When connected to a shared radio access network, the operators may share the radio
resources themselves in addition to sharing the radio network elements. The operators
may have dedicated radio access networks in addition to this shared radio access
network.
TS 23.251 define two architectures to be supported by network sharing. In both
architectures the radio access network is shared. The first architecture is referred to as
Gateway Core Network (GWCN), in which the core network elements such as MSCs,
SGSNs and MMEs are also shared. (See Figure 6-4.) For GWCN, this feature supports
shared MME and possibly shared SGW/PGW. The second architecture is referred as
Multi-Operator Core Network (MOCN) configuration, in which only the radio access
network is shared. (See Figure 6-5.) For MOCN, the impact to MME is minimal; the eNB
is responsible for most of the functionality.
CN
Operator A
CN
Operator B
CN
Operator C
Shared
MME/(S/
PGW)
Shared
MME/(S/
PGW)
Shared
MME/(S/
PGW)
S1
eNB
eNB
eNB
Shared Radio Access Network

Operator X
Figure 6-4: GWCN Architecture
WMM
WMM
WMM
WMM
WMM
WMM
WMM
WMM
PLMN
PLMN AA
PLMN
PLMN BB
(A)
(A)
(B)
(B)
RNC/BSC
RNC/BSC
RNC/BSC
RNC/BSC
PLMN
PLMN AA
PLMN
PLMN BB
PLMN
PLMN AA
PLMN
PLMN BB
RNC/BSC
RNC/BSC -1
-1
PLMN
PLMN AA
RNC/BSC
RNC/BSC -- 22
RNC/BSC
RNC/BSC -3
-3
PLMN
PLMN AA
PLMN
PLMN BB
PLMN
PLMN AA
PLMN
PLMN BB
Figure 6-5: MOCN Architecture
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
219 / 652
In MOCN architecture, UEs devices are divided into two groups:
Supporting UE: Supporting UEs are devices capable to read broadcast

messages containing advertisement of multiple PLMNs and choosing the PLMN
of their home network. The radio equipment broadcasts all PLMNs sharing the
given RAN and UE selects its own home PLMN. Based on this RAN controller
will re-direct the messages to the correct packet core. This means that from
WMM point of view MOCN operation is completely transparent.
Non-supporting UEs: Non-supporting UE are devices which are not capable to

recognize multiple PLMNs and hence choosing so called common PLMN per
default. The multiple PLMNs are not recognized and UE will always try to attach
to so called common PLMN. In practice, the PLMN of the provider owning the
RAN infrastructure is configured as common. In these cases the mobility
manager receiving the UE request needs to be aware which other PLMNs are
potential candidates for taking over and forward request to SGSN in a correct
packet core network.
The decision to which core network UE request is forwarded is made based on UE

home-PLMN and the fact whether this PLMN is configured PLMN participating in RANsharing. If yes, the UE request is forwarded to SGSN of its home network rather than
handling it locally as a roamer
If the UE belongs to a PLMN that is different from the Home PLMN (or mhome) and this
PLMN is an allowed roaming partner and the UE is allowed to roam, the UE will be
considered as a roamer as in todays supported roamers.
If the UE belongs to a PLMN that is different from the Home PLMN (or mhome) and this
PLMN is not an allowed roaming partner, the UE will not be allowed service in the
SGSN. The SGSN will reject Attach/RAU and will include a redirect indication to the
RAN if the RAN has included the redirect flag in its message to the SGSN. This process
will continue until the UE is redirected into its Home PLMN or into a roaming partner
PLMN where UE is allowed roaming.
Please note that for LTE there are no non-supporting UEs and therefore the
considerations related to forwarding UE requests are relevant only for 2G (all UEs are
considered as non-supporting) and 3G (only old devices are non-supporting) routing
areas.
The following rules apply to support MOCN operation:
At mobile-network level the configuration will indicate whether the network

participates in ran sharing along with the list of PLMNs participating in sharing.
If set, the system will per default assume that all routing-areas are participating
in ran-sharing (see section 6).
At routing area level, there will be a configuration to remove the area from ransharing. In order words, the areas not participating in ran-sharing will have to be
explicitly indicated (see section 6).
If request is received from supporting UE, it will be handle as usual
Issue 11.01
If request is received from non-supporting UE, which is not homer for the given
mobile-network it will be forwarded to its home PLMN in case this is on the list
of ran-sharing-plmns, otherwise it will be forwarded to first PLMN on th ransharing-list
LTE/DCL/APP/031094
Nokia 2016
220 / 652
In addition to GWCN and MOCN as defined in TS 23.251, this feature also supports a
variant of GWCN, in which the MME and possibly the SGW/PGW are shared, but the
radio access network is not shared. (See Figure 6-6.) This configuration may be useful
in the 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.
.........
CN
Operator A
Shared
MME/(S/
PGW)
CN
Operator B
Shared
MME/(S/
PGW)
CN
Operator C
.........
Shared
MME/(S/
PGW)
S1
eNB
eNB
(Operator
A)
(Operator A)
eNB
eNB
(Operator
B)
(Operator B)
eNB
eNB
(Operator
C)
(Operator C)
Figure 6-6: GWCN Variant Architecture

A shared PLMN is identified by setting the PLMN Type parameter equal to Shared
Network in the Manage Mobile Regions/Public Land Mobile Network form. (See Section
6.1.)
Rule: Shared PLMN

The MME can have a maximum of 8 Shared PLMNs.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
221 / 652
The following parameters are added to support network sharing:
Core Network Sharing global parameter - Used to allow provisioning of Shared

PLMNs in the MME PLMN table. Must be set to Yes to allow provisioning of
Shared PLMNs in the MME PLMN table. (default=No)
Parameter
Core Network Sharing
SAM Table Name
Global Parameters
OSS ID
Range & Unit
gParmName
String
Core_Network_Sharing
gParmValue
Boolean
Yes or No
Impact of Change
No service impact.
Value
Operator Dependent; default = No (Disable)
SBcEnabled - Used to allow the transmission of CMAS S1-AP messages to

specific eNBs in a given PLMN. Must be set to True to allow transmission of
CMAS S1-AP messages to specific eNBs in a given PLMN. (default=False) See
Section 8.1.7.3.
PLMN Type - Used to distinguish a type of PLMN. Must be set to Home

Network to specify a Home PLMN. There can only be 1 Home PLMN. Must be
set to Shared Network to specify a Shared PLMN. There can be up to 8 Shared
PLMNs. Other Network specifies a roaming PLMN. Note: A Home Network
(Home PLMN) must be provisioned before any other PLMN type can be
provisioned. A Shared Network or Other Network PLMN is dependent on the
Home PLMN. (default=Other Network) See Section 6.1.4.
NodeType - Used to distinguish a type of Node. Must be set to Home Network

to specify a Home Node. Must be set to Shared Network to specify a Shared
Node. Other Network specifies a roaming Node. (default=Other Network) See
Section 6.3.1.)
Additionally, the following forms must be must be provisioned with a PLMN to

associate it to a specific Home or Shared PLMN.
- Allocation/Retention Priority (ARP)
- Equivalent PLMN
- Paging Policy
- EPS Mobility Management Information (EMM)
- Zone Code
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
222 / 652
7 MME TRANSPORT PROTOCOLS

The MME supports the following transport protocols in WM10.0.0:
SCTP for S1-MME, SGs, SBc, SLs, and M3
TCP for SDS / SGS Lite
Diameter over SCTP for S6a, S13, and SLg
UDP for S11, S10, S102, Gn, S3, Sm, and Sv
Each interface type must be mapped to an SCTP or GTP profile after the local IP
address for the interface type has been provisioned.
There are no default interface profile mappings.
SCTP profiles include information defining port numbers, heartbeat mechanism, and
timers. Diameter profiles (Diameter/SCTP) include watchdog timers, capability
exchange request information, and destination information. GTP profiles include
information to control echo requests and resending GTP messages.
Please refer to the Transport Engineering Guide [R28] for further information regarding
the transport protocols.
7.1 BFD
BFD requirements are covered in the section 8.3 of the Transport Engineering Guide
[R28]
7.2 SCTP
Please refer to the section 8.2.3 of the Transport Engineering Guide [R28] for further
information regarding SCTP protocol.
7.3 GTP
The GTP requirements are covered in the section 8.2.11 of the Transport Engineering
Guide [R28]
7.4 M3-AP
The M3AP messages between an eNB and the MME are transported over SCTP/IP.
The M3 Application Protocol (M3AP) supports the signaling control functions.
The signaling functions include:
o
Session Management starting, stopping, and updating MBMS sessions
Reset Functionality ensures a well-defined initialization on the M3 interface
Error Indication Functionality allow a proper error reporting/handling in

cases where no failure messages are defined
M3-AP requirements are covered in the section 8.2.9 of the Transport Engineering
Guide [R28]
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
223 / 652
7.5 EPC LCS
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 procedures 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 and AVPs to support SLg specific procedures.
Main functions of the ELP protocol are to allow for:
the GMLC to request position estimates for a particular target UE from the MME
to support the EPC-MT-LR positioning procedures.
the MME to return a position estimate or an error report to the GMLC in response
to a Provide Subscriber Location request as part of an EPC-MT-LR positioning
procedure
the MME to forward an unsolicited position estimate to the GMLC as part of the
EPC-NI-LR procedure
the GMLC to acknowledge receipt of an unsolicited position estimate as part of

the EPC-NI-LR procedure
procedures that support the handover of an IMS emergency call with EPS/GPRS
access
7.6 LCS-AP
The LCS application protocol is used between the MME and the EPC Serving Mobile
Location Center (E-SMLC) to support Location Services (LCS). LCS-AP messages are
carried over SCTP/IP on the SLs interface. The messages are used to exchange
location request/responses and for carrying LPP and LPPa messages (LTE Position
Protocol).
Refer to TS 29.171 and TS 23.271 for details on LCS-AP procedures, messages and
message formats, and use of SCTP for LCS-AP.
The payload size of the information element in the LPP PDU that can be sent or
received by the MME cannot exceed 7915 bytes.
This is significant because the likely direction where this size message will be seen is in
the response from the cell toward the MME with a large PDU with location information in
it. Traffic from the E-SMLC toward the MME would likely never come even close to
these limits.
LPP APDUs between the E-SMLC and UE are limited to 7915 octets in length.
Message if the MME received an LCS-AP LPP message with a PDU exceeding the
maximum allowed size of 7915 bytes, the message will be discarded and the MME will
send a LCS-AP LOCATION-ABORT message.
LPPa also has an APDU payload limit of 2000 bytes. For connection-oriented transfer,
if the limit is exceeded the MME will drop the message and attempt to abort the location
request. For connection-less transfer, the message will be dropped.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
224 / 652
7.7 Diameter
DIAMETER protocol is defined in RFC 3588. Diameter protocol defines minimum
requirements for the AAA protocol and supports transferring of subscription and
authentication data, positioning requests, and UE Identity Check for
authenticating/authorizing user access to the evolved system between Nokia 9471
WMM and HSS, GMLC and EIR. Please refer to the Transport Engineering Guide [R28]
for further information regarding DIAMETER protocol.
Following are details about DRA support:
The S6a and S6d interfaces (the diameter-based interfaces between 9471 WMM and
HSS) share the same managed object and link, s6ad.
In Release WM7.0.0 and later releases, DRA is managed on a per link basis;
previously, it was managed at the system level.
Shared IP addresses: If the same DRA is used for routing S6a, S13, and SLg, the
Remote End-Point definitions for S6a, S13, and SLg are sharing the same IP addresses
so different ports must be used to result in different SCTP associations.
If a Diameter request from the WMM is received by a DRA, the DRA determines the
HSS/EIR/GMLC identity based on the user-provided identity and forwards the Diameter
request directly to the HSS/EIR/GMLC. In this case, the user identity to HSS/EIR/GMLC
resolution decision is communicated to the MME in the Origin-Host/Origin-Realm
attribute-value pairs (AVPs) of the response. The ME can store the determined
HSS/EIR/GMLC identity/Realm and use it in further Diameter requests to the same user
identity.
When the DRASupported parameter is disabled on a diameter end point, MME
populates Destination-Host and Destination-Realm AVPs in requests with values of
Origin-Host and Origin-Realm AVPs in CEA from HSS/EIR/GMLC.
AVP support:
The 9471 WMM supports the following routing-related AVPs and routing-related errors:
o
Origin-Realm
Origin-Host
Destination-Realm
Destination-Host
Proxy-Info
Route-Record
The 9471 WMM supports up to three (3) Route-Record AVPs in the answer or request
messages from the HSS/EIR/GMLC. The MME can receive and ignore up to 3 RouteRecord AVPs in these messages. The MME echoes back Proxy-Info AVPs in the same
order with the same Protect bit and it applies to both success and error MME answer
messages.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
225 / 652
7.8 Diameter Routing Agent support
WMM supports Diameter Routing Agent (DRA) on the following interfaces:
Interface
Release
WM6.0.0
WM6.0.1
S6a
WM7.0.0
WM7.1.0
S6ad
Issue 11.01
DRADestRealm : Introduced in the Remote End Point

table, used to specify a HSS Destination Realm when MME
does not have the history of the HSS at the beginning of a
call. Once MME and DRA have exchanged the first set of
S6a messages, the MME store the received HSS
destinationrealm information in the VLR for later use.
DRASupported: field in the Remote End Point table
enables or disables DRA support on a per link basis. If set
to Yes (DRASupported is enabled), the provisioned value
for DRADestRealm is used in the initial diameter request
message from the MME.
The S6a DRA Supported global parameter is deprecated
WM7.1.0 M1
Destination Realm is deprecated in Remote End Point

table. The DRA Destination Host and RealmFQDN names
are added in Remote End Point and IMSI To HSS routing
tables for S6ad.
WM7.0.0

WM7.1.0 M1

are added in Remote End Point table.
LM6.0
and
later release
System-level global parameter SLG DRA Supported
WM7.0.0

message from the MME. SLG DRA Supported is
deprecated
WM7.1.0 M1

are added in Remote End Point table.
S13
SLg
Provisioning options
LTE/DCL/APP/031094
Nokia 2016
226 / 652
Following are details about DRA support:
The S6a and S6d interfaces (the diameter-based interfaces between 9471 WMM and
HSS) share the same managed object and link, s6ad.
DRA is managed on a per link basis . If the same DRA is used for routing S6a,
S13/S13', and SLg, the Remote End-Point definitions for S6a, S13/S13', and SLg are
sharing the same IP addresses so different ports must be used to result in different
SCTP associations.
If a Diameter request from the WMM is received by a DRA, the DRA determines the
HSS/EIR/GMLC identity based on the user-provided identity and forwards the Diameter
request directly to the HSS/EIR/GMLC. In this case, the user identity to HSS/EIR/GMLC
resolution decision is communicated to the 9471 WMM in the Origin-Host/Origin-Realm
attribute-value pairs (AVPs) of the response. The MME can store the determined
HSS/EIR/GMLC identity/Realm and use it in further Diameter requests to the same user
identity.
When the DRASupported parameter is disabled on a diameter end point, MME
populates Destination-Host and Destination-Realm AVPs in requests with values of
Origin-Host and Origin-Realm AVPs in CEA from HSS/EIR/GMLC.
MME supports up to three (3) Route-Record AVPs in the answer or request messages
from the HSS/EIR/GMLC. The MME can receive and ignore up to 3 Route-Record
AVPs in these messages. The MME echoes back Proxy-Info AVPs in the same order
with the same Protect bit and it applies to both success and error MME answer
messages.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
227 / 652
7.9 S6ad Diameter Routing Agent roaming support
To enable DRA roaming support, the following settings must be enabled or
provisioned:
o
DRA is enabled on the S6a link
Roaming support is enabled on the S6a link.
The DRA Destination Realm Name is provisioned.
If the MME does not have DRA Destination-Host /Destination Realm Name, for
example, when a UE show up for the first time, the MME does not include
Destination-Host AVP, but populates Destination-Realm AVP as follows:
Issue 11.01
For homers, the serving PLMN and UE PLMN is the same, the
provisioned DRA Destination Realm value and optional DRA destination
host (WM7.1.0M1) from the RemoteEndPoint table
For roamers, if the serving PLMN and the UE PLMN do not match, use
the "epc.mnc###.mcc###.3gppnetwork.org" as DRA Destination Realm,
instead of any provisioned Destination Realm. The DRA Destination Host
will not be populated, even if provisioned.
LTE/DCL/APP/031094
Nokia 2016
228 / 652
7.10 Mixed mode Diameter Routing Agent support
MME supports mixed mode for DRA or HSS/EIR/GMLC for the S6a, S13, and SLg
interfaces. DRA support can be enabled or disabled on a per link basis.
Each DRA can have its own provisioned Destination-Realm.
Prior to WM7.0.0 mixed mode DRA was not supported; the MME either connects to
all DRAs or all HSSs/EIRs/GMLCs.
When DRA is enabled and MME does not have Destination-Host /Destination-Realm
in VLR (UE shows up for the first time), the following tables summarize usage of DRA
Destinations as provisioned in the first Diameter message sent to the DRA.
Issue 11.01
Scenario
The Destination Host AVP is formulated as

follows
For S6a, if a selected IMSI rule has DRA

Destination Host provisioned
Use the DRA Destination Host from IMSI rule
For S6a, if a selected IMSI rule does not

have DRA Destination Host provisioned,
but its end point has DRA Destination
Host provisioned
Use the DRA Destination Host from the

Remote End Point table for the selected end
point.
For S6a, if neither selected IMSI rule nor

Remote end point have DRA Destination
Host provisioned
MME does not populate the Destination

Host AVP
For S13 and SLg, if a selected Remote

End-Point has DRA Destination Host
provisioned
Use the provisioned DRA Destination Host

from the Remote End Point table for the
selected end point

End-Point has no DRA Destination Host
provisioned
MME does not populate the Destination

Host AVP
For S6a, if a selected IMSI rule has DRA

Destination Realm provisioned
Use the DRA Destination Realm from IMSI

rule
For S6a, if a selected IMSI rule does not

have DRA Destination Realm
provisioned, but its end point has DRA
Destination Realm provisioned
Use the DRA Destination Realm from the

Remote End Point table for the selected end
point.
For S6a, if neither selected IMSI rule nor

Remote end point have DRA Destination
Realm provisioned
MME populates the Destination Realm AVP

with the hard-coded value of
epc.mnc###.mcc###.3gppnetwork.org
per standard.

End-Point has DRA Destination Realm
provisioned
Use the provisioned DRA Destination Realm

from the Remote End Point table for the
selected end point

End-Point has no DRA Destination
Realm provisioned
MME populates the Destination Realm AVP

with the hard-coded value of
epc.mnc###.mcc###.3gppnetwork.org
per standard.
LTE/DCL/APP/031094
Nokia 2016
229 / 652
7.11 SNMPv3 Protocol
As part of basic 5400 LCP OAM&P architecture, SNMPv3 protocol is used between the
MME and the external management system (EMS) for fault management and
administrative management. SNMPv3 provides security between the MME and
northbound systems.
The northbound interface (NBI) configuration between the MMEs MI-Agent and the
EMS (5620 SAM) is SNMPv3, over which MME alarms, events, and performance
management data are forwarded.SNMPv3 protocol configuration is managed using the
MI-Agent GUI.
NETCONF
MME
WM6.0.1
Figure 7-1: SNMPv3
7.11.1 FAULT MANAGEMENT

Every alarm or Event sent to MI generates an SNMPv3 Trap that is sent to the 5620
SAM to notify the administrator of its presence.In active-standby EMS configurations,
traps are sent to both the active and standby EMS IP addresses.
7.11.2 ADMINISTRATIVE MANAGEMENT

MME supports Netconf Notifications for the files generated by PM Jobs configured in
the WMM instead of SNMP traps being used for this WMM notify the SAM via Netconf
when a new PM file is created. SNMP is used for files generated by PM Jobs configured
in the WMM. The 5620 SAM retrieves files using sFTP and a special PM user login and
password. Note : that PM files can be viewed at the MI-Agent or the 5620 SAM.
The administrator may use SNMPv3 GET to get MME application Managed Object
(MO) states, as well as SNMPv3 SET to set MME application MO Administrative
States..
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
230 / 652
7.12 Transport Control Protocol (TCP)
MME supports the following TCP connection capabilities:
MME establishes semi-permanent TCP connections to the provisioned GW-TS

Remote end points. The TCP connection remains up in normal circumstances.
MME supports configuration of up to four TCP connections to each GW-TS.

( total of 16 TCP connections)
MME sends SGsLite messages to all the provisioned TCP connections in round-robin
fashion on the selected GW-TS and receives response to a SGsLite message on any of
the TCP connections.
A TCP Profile is assigned to each TCP connection associated to the Remote GW-TS
endpoint (IPv4 or IPv6 address and TCP port number) with the following global TCP
parameters for monitoring the TCP connections:
Parameter
Keep Alive Idle Timer
SAM Table Name
TCP Profile
OSS ID
ltemme.MME TCPProfile. Keep Alive Idle Timer

ltemme.MME TCPProfile..seconds
ltemme.MME TCPProfile..timerValue
Range & Unit
timerValue
Integer
[1..300]
Impact of Change
No service impact.
Value
Operator Dependent; default = 30 sec
Keep Alive interval is the duration between two successive Keep Alive retransmissions.
Parameter
Keep Alive Interval
SAM Table Name
TCP Profile
OSS ID
ltemme.MME TCPProfile. Keep Alive Interval

ltemme.MME TCPProfile..seconds
Range & Unit
timerValue
Integer
[1..3600]
Impact of Change
No service impact.
Value
Operator Dependent; default = 30 sec
Issue 11.01
Keep Alive idle timer is set to send keep alive packets to the GW-TS if there are
no other TCP packets received.
Keep Alive Retry : After exhausting all keep-alive re-transmissions/retry on a

TCP connection, MME declares that the TCP connection is down and
generates a major alarm. MME attempts to set up TCP connection immediately
after it stops sending keep alive packets.
LTE/DCL/APP/031094
Nokia 2016
231 / 652
Parameter
Keep Alive Retry
SAM Table Name
TCP Profile
OSS ID
ltemme.MME TCPProfile. Keep Alive Retry

ltemme.MME TCPProfile.
Range & Unit
Number of Keep Alive failures before declaring TCP

connection failure
Integer
[1..10]
Impact of Change
No service impact.
Value
Note that MME keeps on trying to establish TCP connection even after the expiration of
the Keep Alive Idle timer. If the number of active/in-service TCP links is less than the
provisioned minimum number of TCP links for the GW-TS then MME isolates the GWTS and selects next preferred GW-TS that at least has minimum number of TCP
connections.
7.13 Internet Protocol (IP)

IPv4 and IPv6 stacks are supported on the 9471 WMM to enable the WMM 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).
Rule: Internet Protocol

WMM does not support IPv6 for Gn, SGs, Sv and OA&M interfaces.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
232 / 652
8 MME CALL MANAGEMENT

The Nokia MME performs key procedures associated with its functions. These can be
categorized as ePS Mobility Management (EMM) procedures and ePS Session
Management (ESM) procedures.
The ePS Mobility Management (EMM) procedures:
keep track of the current location of a User Equipment (UE) as it moves around a
network
support paging and handovers
Ensure communication is maintained.
The ePS Session Management (ESM) procedures support bearer activation,

modification, deactivation, and preservation of data sessions (specifically, ePS bearers
to support communication between the UE and the Evolved Packet Core Network).
MME supported procedures include:
GUTI reallocation procedure
Directed Inter-MME UE Move
Authentication and key agreement (AKA) procedure
EMM information procedure
Identification procedure
Security mode command procedure
Attach procedure (IMSI attach and GUTI attach)
Extended service request procedure
Detach procedure
Tracking area update procedure
Service request procedure
Paging procedure
Inter-eNB X2-based handover procedure
Inter-RAT handover procedure
Intra-LTE S1-based handover procedure
Routing area update procedure
E-RAB procedure
UE context procedure
Resynchronization of UE context data between MME clients and the SRS
Restoration data updates for MM and SM procedures
Enhanced restoration procedures for DDN w/ IMSI and service request
A detailed description of the MME procedures supported in WM10.0.0, along with call
flows, can be found in [R34].
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
233 / 652
8.1 EMM Procedures
As stated previously, the ePS Mobility Management (EMM) procedures:
keep track of the current location of a User Equipment (UE) as it moves around a
network
support paging and handovers
Ensure communication is maintained.
8.1.1 EMM STATES

EMM states are:
EMM-REGISTERED: The MME assigns this state to UE upon successful Attach

or Tracking Area Update (TAU) procedure. UE location is known to the MME at
least to an accuracy of a tracking area.
The UE, MME, SGW, and PGW all keep the UE context.
EMM-DEREGISTERED: UE is not reachable by the MME. Some UE context is

kept by the MME.
The MME changes UE state from EMM-REGISTERED to EMM-DERGISTERED for

events like Attach Reject, TAU reject, Detach (for example, the UE powers off).
8.1.2 NETWORK ELEMENT SELECTION

A key task in EMM procedures is selection of network elements needed to complete the
procedure. An MME, SGW, PGW, and/or HSS may need to be selected, depending on
the procedure.
8.1.2.1
Network Element Selection Using DNS
The MME supports Domain name System (DNS) query procedures to obtain IP
addresses for the following network elements (NE) (as defined in 3GPP TS 29.303):
SGW
PGW
far end MME
far end SGSN
A maximum of 2 IPv4 and/or IPv6 resource records. Additional records are

ignored. If only IPv6 records are received, the MME assigns the IPv6 address in
round-robin. If IPv6 records are not received, but IPv4 records are, the MME
assigns the IPv4 address in round-robin. If both IPv4 and IPv6 records are
received, the MME assigns only the IPv6 addresses in round-robin. If no IPv4 or
IPv6 records are received, another query is launched based on the next NAPTR
MME hostname.
Configuring DNS server IP addresses for DNS discovery and selection. The
recommendation is that service providers use a single DNS server for the
discovery of Network Elements (such as PGW, SGW, or MME). The MME will not
select a target node whose interface link is in the Disabled/None state. If a TTL
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
234 / 652
expires, the next DNS query for that resource causes the MME to launch a DNS
query to retrieve the latest data from the DNS server.
Configuration of up two DNS server pairs. Each DNS server pair is configured as
primary/secondary for redundancy. When two DNS servers are configured, each
DNS pair can serve a different domain: one DNS pair for .3gppnetwork.org
domain queries and the other pair for .gprs domain queries. This would to
separate DNS queries on a technology related basis that is, 2G/3G related
queries going to one DNS server [gprs. DOMAIN] and 4G related queries going
to another DNS server [3gppnetwork.org.]
Dump the contents of MME DNS cache and flush DNS cache entries
8.1.2.2
Service Resource records (SRV) for MME DNS
discovery
Starting in WM8.0 and later releases, MME provides Service (SRV) Resource Records
(RR) for MME DNS discovery of the MME, PGW, SGW, and SGSN.
MME selection of a SGW/PGW/MME/SGSN (host) using the priority and weight fields is
as follows:
MME first selects a host with lowest priority value.
If there are multiple hosts with the same priority value then MME assigns UE
sessions to a host in proportion to the weight. Hosts with high weight value are
considered to have higher capacity.
Hosts with high priority values are considered as back up and are selected if
hosts with low priority values are unavailable.
When the Support DNS SRV global parameter is enabled, the MME first uses
NAPTR Order/Preference fields to select a NAPTR record, then for type "s" NAPTR
records, the MME uses the priority and weight fields to select the associated SRV
records.
The MME support for a given host name up to 80 records in a single SRV query, but
limits the number of NAPTR s flag record as follows:
Issue 11.01
A maximum of 64 NAPTR s flag records for PGW discovery.
A maximum of 16 SGW NAPTR s flag records for SGW discovery.
An overall limit of 80 NAPTR records for MME/SGSN discovery. (sum of

NAPTR a flag records + NAPTR s flag records + SRV records)
LTE/DCL/APP/031094
Nokia 2016
235 / 652
Parameter
Support DNS SRV
SAM Table Name
Global Parameters
OSS ID
Range & Unit
gParmName
String
Support DNS SRV
gParmValue
Boolean
Yes or No
Impact of Change
No service impact.
Value
Feature
m10103-07
The MME supports the following:
Type "A" NAPTR records and Type "S" NAPTR records (if DNS SRV Support
global parameter is enabled) and independent NAPTR queries for network
element selection.
NAPTR record with empty flag type if the MME PGW QUERY EMPTY FLAG
RR global parameter is enabled for the selection of a PGW for both mode 1 and
mode 2 selection.
Parameter
MME PGW QUERY EMPTY FLAG RR
SAM Table Name
Global Parameters
OSS ID
Range & Unit
gParmName
String
MME PGW QUERY EMPTYFLAG RR
gParmValue
Boolean
Yes or No
Issue 11.01
Impact of Change
No service impact.
Value
Feature
m10103-16
LTE/DCL/APP/031094
Nokia 2016
236 / 652
The following services for both type A and type S NAPTR Resource Records are
supported for the Gn-SGSN discovery of collocated PWG/SGSN :
x-3gpp-pgw : x-s5-gtp,
x-3gpp-pgw : x-s8-gtp
x-3gpp-pgw : x-gn
x-3gpp-pgw : x-gp.
When MME PGW QUERY EMPTY FLAG RR global parameter is enabled, it is
assumes that the query using replacement string of NAPTR RR with empty flag returns
only NAPTR RR with "a" and "s" flags. Any NAPTR RR received with empty flag (i.e.
does not use these) is discarded.
The processing of the NAPTR RR with "a" and "s" flag remains unchanged.
Note that S4-SGSN PGW/SGW/GGSN Selection enhancements feature (m10103-15)
does not support provisioning of node selection mode similar to MME. The node
selection behavior of S4-SGSN is similar to the MME mode 2 selection in which the
best topological matching SGW and PGW pair is selected at the attach time. The
enhancements include support of the following:
NAPTR record with empty flag is used only for PGW selection if the S4 SGSN
QUERY EMPTY FLAG RR global parameter is enabled. (Set to Yes).
Parameter
S4SGSN QUERY EMPTYFLAG RR
SAM Table Name
Global Parameters
OSS ID
Range & Unit
gParmName
String
S4SGSN QUERY EMPTYFLAG RR
gParmValue
Boolean
Yes or No
Impact of Change
No service impact.
Value
Feature
m10103-15
If the S4 SGSN QUERY EMPTY FLAG RR global parameter is set to Yes then
"S4SGSN QUERY SRV RR" must be set to Yes
NAPTR RR with s flag and NAPTR SRV RR for both SGW and PGW if the S4SGSN
QUERY SRV RR
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
237 / 652
Parameter
S4SGSN QUERY SRV RR
SAM Table Name
Global Parameters
OSS ID
Range & Unit
gParmName
String
S4SGSN QUERY SRV RR
gParmValue
Boolean
Yes or No
Impact of Change
No service impact.
Value
Feature
m10103-15
If the S4SGSN QUERY SRV RR element is set to No then "S4SGSN QUERY

EMPTYFLAG RR" must be set to No
For a home subscriber or for local break out case, the SGSN shall prefer a PGW
supporting both x-s5-gtp and x-gn. If there are no PGW supporting both then the SGSN
will select a PGW supporting x-s5-gtp only if available
Load balancing across NAPTR RR with empty flag , a and/or s flag.
Starting in WM8.0.0 and later releases, a maximum number of 400 records are
supported for NAPTR queries with an APN FQDN (a sum total of NAPTR Aflags
records plus NAPTR S flags records plus NAPTR SRV records).
Other NAPTR queries are limited to 80 records (The total sum of NAPTR a flag
records + NAPTR s flag records + SRV records). If more than one resource with
the same order value exists, the MME distributes sessions across these network
elements in proportion to the preference value. FQDN size must be less than or
equal to 100 characters.
Issue 11.01
Network element selection using independent NAPTR queries
LTE/DCL/APP/031094
Nokia 2016
238 / 652
8.1.2.3
APN-NI extension for DNS query
MME extends the APN-NI with a configurable length of MSISDN Digits by adding all
APNs with the first N digits of the national significant mobile number of UEs MSISDN
after the country code from MSISDN when selecting PGW during DNS query per
provisioning if UEs APN-NI matches any of the APN-NI provisioned in the National
APN List for UEs in MMEs HPLMN. The APN-NI has to be an exact match however its
not case sensitive.
If the final PGW FQDNs mnc.mcc matches the MMEs HPLMN and if APN-NI is in the
National APN List and if the APN-NI extension capability is enabled, then APN will be
extended with N digits from the MSISDN.
For example, if the MSISDN is 861234567890 and the country code length is
provisioned to 2 and number of digits added (N) is provisioned to 7, the extended APN
format for the DNS query is like this (the red part is inserted):
APN-NI.1234567.apn.epc.mncXXX.mccXXX.3gppnetwork.org
A new Global Parameter MME APN NI Extension is introduced to enable or disable
the extension of the APN-NI with configurable length of the MSISDN digits.
By default this capability is disabled.
Parameter
MME APN NI Extension
SAM Table Name
Global Parameters
OSS ID
gParmName
String
MME APN NI Extension
Range & Unit

gParmValue
Boolean
Yes or No
Issue 11.01
Impact of Change
No service impact.
Value
Operator Dependent; default = No ( disabled)
Feature ID
m10121-03
LTE/DCL/APP/031094
Nokia 2016
239 / 652
The National APN List is provisioned on the APN table (SGSN) via the extend National
APN flag. Up to 31 APNs can be added to the Apn List table The APN table is displayed
by selecting Mobility /Public Land Mobile Networks (PLMNs) Session Management
Access Point Names (APN) from the main menu.
Once configured, Mobile Regions appear in the Mobile Node Region List. The list is
available from other provisioning forms whenever Mobile Region selection is required.
Note that one can only provision APNs on this table for MMEs HPLMN or own network.
It does not allow provisioning of APNs for Shared Network, M-home Network
(applicable to SGSN only), or Other Network PLMNs. In addition, although the APN-NI
check is not case sensitive, provisioning of APNs in this table can be case sensitive.
The number of digits from the MSISDN (or N) to be added to the APN and the country
code length are existing data fields in MMEPLMN, i.e. numberOfAddedDigits (range
from 0 to 15 with 0 being the default) and hplmnCcLength (range from 1 to 3 with 2
being the default), respectively.
If the APN NI Extension global parameter is enabled but PLMN Number of Digits
Added to APN is set to 0, then no digits will be added to the APN that it behaves like
the extended National APN feature is being off.
This feature applies to homers, local breakout (LBO) roamers, and roamers treated as
homers during PGW selection / reselection in the UE attach and standalone PDN
connection procedures, regardless of GW selection modes. This feature does not apply
to Shared Network (i.e. the serving network cannot be a Shared Network) and it doesnt
change the APN for any other reason except for APN DNS query when selecting the
PGW.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
240 / 652
8.1.2.4
DNS Selection Mechanisms (for SGW/PGW selection)
The MME supports a provisionable global parameter that allows user to select between
two mechanisms for SGW and PGW Selection.
In prior releases, the MME selected the SGW first based on Order and Preference
values of the resources returned from the TAC NAPTR DNS query response. It then
selected the PGW from the APN/PGW NAPTR query response based on topological
matching of PGW FQDN names with chosen SGW FQDN. To use this mechanism now,
the user sets a global parameter to 'GW Selection Mode 1'.
An alternative mechanism the user can provision is 'GW Selection Mode 2'. With this
mechanism, during the initial attach the MME will chose the SGW/PGW 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 (using NAPTR
Order/Preference values if multiple pairs have the same number of matching nodes).
The MME only considers PGWs that are designated as combined GGSN/PGW (provide
both x-gn and x-s5/x-s8 service), unless none are returned in the query response.
Parameter
SAM Table Name
OSS ID
GW Selection Mode
Global Parameters
gParmName
String
GW_Selection_Mode
Range & Unit
gParmValue
Choice List
GW Selection Mode 1
GW Selection Mode 2
Impact of Change
No service impact.
Value
Operator Dependent; default = GW Selection Mode 1
3GPP operators with GSM and UMTS networks deploying LTE and operators deploying
WMM (combo MME and SGSN) must set the GW Selection Mode global parameter to
Select Close Pair, which specifies GW mode 2.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
241 / 652
8.1.2.5
Network Element Selection Mode 1
8.1.2.5.1 MME POOLING AND SELECTION

The network may contain one or more MMEs, for which multiple MMEs are organized
into pools. Refer to Section 6.4.1 for information regarding the number of MMEs
supported.
An MME pool area is an area within which a UE may be served without the need to
change the serving MME (that is, no MME relocation is required within the MME pool).
The pool area is served by one or more MMEs (pool of MMEs) in parallel. MME pool
areas are a collection of complete tracking areas (TAs).
MMEs have S1 (e.g., SCTP) connectivity to all eNBs within the pool area, and S10
connectivity to all MMEs in all pools.
Figure 8-1: MME and SGW Pooling
8.1.2.5.1.1 SELECTION USING PROVISIONED MME IP

ADDRESSES
MME selection is performed by cycling through MMEs of a selected MME pool based
on provisioned TAI -> MME pools -> MME data. Provisioning of MME IP addresses is
described in Nokia 5620 SAM LTE ePC User Guide.
When transitioning from using S-NAPTR procedure to using provisioned data, then:
An in-progress procedure that has already proceeded to discover the MME IP

address using the S-NAPTR procedure will continue to discover the MME IP
address using the S-NAPTR procedure.
An in-progress procedure that has not yet proceeded to discover the MME IP
address using the S-NAPTR procedure will use the provisioned data to discover
the MME IP addresses.
All new procedure will use the provisioned data to discover the MME IP
addresses.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
242 / 652
8.1.2.5.1.2 SELECTION USING NAPTR/DNS QUERY
When there are multiple MMEs in the network, an MME may be selected by using
provisioned MME IP addresses, or by MME discovery and selection using Domain
Name System (DNS)/S-NAPTR query procedures (supported as defined in 3GPP TS
29.303 and used during these mobility procedures :
GUTI Attach with MME relocation: The new MME queries the DNS based on the
GUTI received from the UE to find the IP address of the old MME in order to
retrieve UE context from the old MME.
TAU with MME relocation: The new MME queries the DNS based on the GUTI
received from the UE to find the IP address of the old MME in order to retrieve
UE context from the old MME.
S1-based handover with MME relocation: The source MME queries the DNS
based on the Selected TAI in the Target ID IE received from the source eNB to
find the IP address of the target MME in order to hand over the call.
Automatic Neighbor Relations: The source MME queries the DNS based on the
Selected TAI in the Target eNB-ID IE received from the source eNodeB to find
the IP address of the target MME that will forward the self-organizing network
(SON) information to the target eNodeB.
MME discovery and selection are also used for MME load-rebalancing. If no S10 path
setup exists to an MME in the MME pool, and MME discovery is active (global
parameter Discover MME, then the MME will launch a DNS query using a TAI
serviced by the MME to set up S10 paths. The MME will continue the load-rebalancing
procedure after successful setup of at least a single S10 path.
If transitioning from using provisioned data to using S-NAPTR procedure, then:
An in-progress procedure that has already proceeded to discover the MME IP

address based on provisioned data will continue to discover the MME IP address
using the provisioned data..
An in-progress procedure that has not yet proceeded to discover the MME IP
address based on provisioned data will use the S-NAPTR procedure to discover
the MME IP addresses.
All new procedures will use the S-NAPTR procedure to discover the MME IP
addresses.
A configurable flag is used to determine whether MME uses the DNS S-NAPTR
procedure or uses provisioned data to find the MME IP addresses (default setting is to
use provisioned data). See Section 6.4.2.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
243 / 652
8.1.2.5.1.3 ATTACH IMPACT
For GUTI attach, the new MME:
Obtains the IMSI from the UE by requesting UE context from the old MME using
the Identification Request S10 message. The old MME returns the information
within the Identification Response S10 message.
Authenticates the UE if
- the GUTI is not valid (i.e. UE context may not have a GUTI or GUTI does not
match)
- the new MME has no S10 link or S10 is down to the old MME.
In WM10.0.0 release, when a GUTI attach request is received, if the GUTIs PLMN ID
matches the serving network PLMN ID but doesnt match with the Group ID of the new
MME and both Discover MME and Restrict S10 Links to Neighbor MME global
parameters are enabled the MME doesnt established S10 link to the old MME to do the
S10 Identity Request if no S10 link exists to the taget MME, but instead the new MME
authenticates the UE directly. If S10 link exists to the old MME then MME sends S10
Identity Request to the old MME.TAU Impact
For TAU request in which there is an MME change, the new MME checks whether the
TAU request message is integrity protected.
If no, then TAU is rejected.
If yes, then the new MME checks S10 link status to the old MME.
- If the S10 link is not active, it sends the TAU reject message to the UE.
- If the S10 link to the old MME is active, it sends the S10 Context Request
message.
The old MME performs several checks and based upon the results of those checks,
sends to the new MME the Context Response S10 message with the applicable data
and cause value. The S10 context response message contains all the necessary
information for the new MME to set up bearers if needed.
The new MME validates the Context Response message, saves UE MM context data (if
message is valid), runs Authentication and key agreement (AKA) procedure(Section
8.1.20) or Security mode command procedure(Section 8.1.24), and responds to the
old MME with the Context Acknowledge S10 message. The old MME then releases the
S1 connection if it exists.
TAU is rejected if
the new MME fails to get a response to a S10 Context Request message within
the allowed number of retransmissions,
Issue 11.01
S10 connection is lost, or
old MME restarted while waiting for a S10 Context Response message
LTE/DCL/APP/031094
Nokia 2016
244 / 652
8.1.2.5.1.4 S1-MME LINK FAILURE MITIGATION
MME connection to the eNodeBs is monitored and failure is handled as follows:
1. The S1-MME link to the eNodeB is monitored at the SCTP layer via MME-invoked
heartbeats and by eNodeB-invoked heartbeats.
These parameters are used in the monitoring:
Heartbeat interval
Retry Number when no heartbeat acknowledgement
Min/Max Retransmit Timeout
2. When the timeout is reached, the MME will mark the link Out Of Service (OOS)
and raise an alarm.
The following occurs:
When the S1 link fails, UEs served by the associated eNodeB that were in the
Connected state will be transitioned to the Idle state, including releasing bearers
at the SGW/PGW all active calls will drop.
eNodeB will release RRC connection and delete UE context for affected UEs.
UEs will have to re-establish via TAU, or Attach.
3. Assuming MME Pooling, the UEs will attempt to re-connect, and the eNodeB will
select one of the remaining available MMEs in the pool. The service request will fail
(the eNodeB will direct the service request to an active MME but the GUTI will point
to the unavailable MME).
The following occurs:
TAU or new Attach will result in relocation to an MME with an active link.
Network-initiated Service Request will fail until UE establishes bearers via an

MME with an active link.
New Attaches to the new MME(s) are spread across the MME pool via round
robin adjusted for MME capacity (weight factor).
The new MME(s) are likely to experience a high signaling load as the UEs all
register.
The new MME(s) monitor the attach rate, as well as other overload parameters (CPU,
Memory, UE Context database utilization) and paces attachments through rejecting
overloading attachments on a per-UE basis.
Once service is restored to the MME that had failed, new UE attachments will slowly be
grown on the recovered MME through the normal eNodeB selection process (round
robin/MME capacity weighting). Use of MME load re-balancing (MME initiates the S1
Release procedure with release cause "load balancing TAU required) will move traffic
back off of the now highly loaded MME(s), to all available MMEs (not re-directing to only
the just-restored MME). See Section 6.4 for further details on MME load balancing
using relative capacity, and MME load re-balancing.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
245 / 652
Additionally, the MME can control overload by restricting eNB load when a MAF pair is
overloaded (MAF overload alarms are present). A global parameter can be set to allow
the MME to send S1 Overload Start and Overload Stop messages to an eNB. When the
MME is in critical overload, it sends an S1-AP OVERLOAD START messages to a
randomly selected eNB to reduce the traffic so that MME load is reduced. The MME
slowly ramps the traffic back up by sending S1-AP OVERLOAD STOP messages
gradually over a period of time. This global parameter gives operators the option to
select MME overload control solely by the MME without any eNB interactions or traffic
shedding by the eNB.
Parameter
OC Send Overload Start and Stop to eNBs
SAM Table Name
Global Parameters
OSS ID
gParmName
String
OC_Send_Overload_Start_and_Stop_to_eNBs
Range & Unit
gParmValue
Boolean
Yes or No
Impact of Change
No service impact.
Value
8.1.2.5.2 SGW SELECTION FAILURE

The network may contain one or more SGWs, for which multiple SGWs are organized
into pools. Refer to section 6.8 for information regarding the number of SGWs
supported.
For an LTE network that contains a single SGW, the IP address is provisioned at the
Nokia MME and used for all events. When there are multiple SGWs in the network, the
SGW is selected by the Nokia MME from a pool of SGWs based upon the tracking
areas identifiers (TAIs) served by the SGW pool or based upon Domain Name System
(DNS) query procedures.
MME generates a minor alarm if MME can not select a SGW.
Service providers may configure whether SGW discovery and selection uses
provisioned data (default) or uses the Straightforward-Name Authority Pointer (SNAPTR) procedure by means of the global provisioning parameter discover SGW.
(See Section 5.1.4.1.1.6.2 SGW DISCOVERY.)
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
246 / 652
8.1.2.5.2.1 SELECTION USING PROVISIONED SGW POOL
The MME constructs a mapping of TAI to SGW Pool ID(s). MME selects an active SGW
in a pool for a UE at the time of Attach or whenever SGW needs to be changed. During
Attach, SGW selection is performed by cycling through SGWs of a selected SGW pool
in a round-robin scheme based on provisioned TAI -> SGW pools -> SGW data. If the
pool is exhausted, the selection process cycles through the next pool, cycling through
pools until an SGW is found. During TAU, if SGW relocation required, MME uses SGW
selection to select an SGW. If the PGW is selected from the VPLMN, MME selects an
SGW with S5 interface. Note that the MME operates on the assumption that for roaming
support, every SGW in the operator network supports both the S5 and S8 interfaces.
When dynamic selection is performed using DNS, the MME choses a candidate SGWs
resource that supports S5 service or both S5 and S8 services from the NAPTR
response, and discards any records that do not include S5 service.
If MME fails to select an SGW, the TAU is rejected. S11 interfaces are added/created
without service disruption to the existing S11 and other interfaces; that is, all S11 links
towards SGW will be up at the time of initialization, and S11 ECHO request/response
are always on for all S11 links even if there is no UE using the link. The links are not
added dynamically. MME relocates bearers to the new SGW (target SGW) and deletes
the bearers on the source SGW (old SGW). MME is provisioned with a timer value used
in processing procedures that involve SGW relocation but no MME relocation, and
indicates when the MME deletes the UE bearers at the source SGW.
If transitioning from using S-NAPTR procedure to using provisioned data, then:
stable sessions continue to use the assigned SGWs that were assigned using the
S-NAPTR procedure until UE detaches or UE is relocated to a new SGW due to
TAU or HO.
any sessions in progress sessions (i.e. sessions that are being set up) continue
use the assigned SGW if it is already assigned until UE detaches or UE is
relocated to a new SGW due to TAU or HO.
MME begins using the provisioned data to discover and select for all the initial
UE Attaches, TAU with SGW relocation and HO with SGW relocation.
8.1.2.5.2.2 SELECTION USING NAPTR/DNS QUERY

SGW discovery and selection using Domain Name System (DNS) query procedures are
supported as defined in 3GPP TS 23.303 (v8.2.0) and used during these mobility
procedures:
TAU and HO (Inter-eNodeB X2-based and Intra-LTE S1-based handovers) with

SGW change for non-roaming case
Issue 11.01
UE initial Attach.
LTE/DCL/APP/031094
Nokia 2016
247 / 652
8.1.2.5.2.3 ROAMING
For roaming cases, the MME supports discovery and selection of SGW using the SNAPTR procedure. Both S5/S8 and S11 MME-SGW interfaces are supported. Selection
of SGW and PGW based on the geographical proximity does not apply to roaming UEs.
Each SGW NAPTR record selected for load-balancing purposes must support any
Service type combination including S5 (e.g. S5, S5+S11, S5+S8, S5+S8+S11).
Each S11 NAPTR record selected for load-balancing purposes must support any
Service Type combination including S11 (e.g. S11, S5+S11, S5+S8+S11).
For roaming cases, the MME supports both local-breakout (SGW connects to local
PGW over S5) and home-routed (SGW connects to PGW in UEs home network over
S8) scenarios. For both cases, the MME selects an SGW resource from the TAI NAPTR
query result whose service type includes S5. Operators must ensure that all SGWs
support both S5 and S8 service. SGW selection proceeds as follows:
MME first selects SGWs that service the TAI and support both x-S5 and x-s8
interface. The MME forms the list of SGW host names from the NAPTR "a"
record resource names and from the SRV record target names for NAPTR "s"
records.
If there are records with equal label matching across two or more NAPTR
records, the MME use the NAPTR records preference and order attributes to
select the NAPTR record. SGW hosts with higher order values are considered
backup SGWs and are selected if an SGW with lower order value cannot be
used.
If the lowest order NAPTR record is associated with SRV records, MME uses
the SRV record Priority andWeight values to select the SGW. SGWs with higher
Priority values are considered backup SGWs and are selected if an SGW with
lower Priority cannot be used.
S11-based selection
The MME selects and assigns UE sessions across S11 SGW hosts specified by type
"A" NAPTR records as follows:
MME uses the canonical node name of the SGW selected to select a NAPTR
record supporting S11 service on the same SGW node. If two or more records
are selected, MME uses the Order and Priority value of each record to distribute
the traffic as previously described for the S8 interface.
MME launches a DNS query to obtain A and AAAA records for the selected S11
interface.
Sessions of UE are assigned to the same SGW host.
For S1-Handover and TAU, MME continues the use the current S11 interface if
the SGW supporting the interface exists in the NAPTR records (irrespective of
the Order value of the other SGW NAPTR records).
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
248 / 652
8.1.2.5.2.4 SGW SELECTION FAILURE
SGW selection failures include scenarios such as no NAPTR records for S5, S5+S8,
and S11 services and no active S11 interfaces. The MME collects SGW selection
failures every two minutes and reports a minor alarm (SGW selection failure alarm) at
the end of the two-minute interval. Detailed information about the SGW selection
failures (such as the FQDN used in the DNS query, the interface type and the reason
for SGW selection failure) is available in a customer-viewable log file. The alarm must
be manually cleared.
8.1.2.5.3 APNS AND APN WILDCARD

The Access Point Name (APN) is used as a reference point for an external PDN that
supports the services accessed by a UE. The APN information is permanently
distributed and maintained in the HSS, the PGW, and the 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 at subscription time. There is one
default APN within the subscribed APNs. If a user attempts to access a service without
specifying the APN then the default APN is used.
In WM8.1.0, MME supports a total of 20 APN and PDP context per UE on average at
maximum UE capacity in subscriber data received from HSS. This feature uses FQDN
indirection and results in MAF (MME) and RAF (SRS) memory savings
The HSS may also define a Wildcard APN which allows a UE to access any
unsubscribed APNs. When the wildcard APN is present in the subscription context, the
UE is authorized to connect to APNs which are not present in the subscription context.
The default APN cannot be the wildcard APN.
WM8.1.0 enhances the current limitation of allowing PDN connection to only one APN
for wild card APN in UE subscription by allowing multiple PDN connections to multiple
APNs. MME provides provisioning of the maximum number of APNs allowed for the wild
card APN per PLMN basis.
A UE subscription data may contain a wild card APN if the Home PLMN allows
subscriber to access any network.If MME has received such a wild card APN, MME can
allow an APN NI received from the UE even if the APN is not in the UE subscription.
The wild card APN is coded as an APN with "*" as its single label,(i.e. a length octet
with value one, followed by the ASCII code for the asterisk) in UE subscription.
The parameter named Maximum APNs Allowed for Wildcard APN is added to the UE
PLMN Services table By default, the "Maximum APNs Allowed for Wildcard APN "
parameter is set to 1. This default value of 1 causes the MME to handle wildcard APNs
(i.e., only allow one APN NI to match the wildcard APN). If this parameter is set to 0,
then the MME will reject any PDN connection that uses an APN NI that matches the
wildcard APN. However, it does not prevent the inclusion of a wildcard APN in UE
subscription data.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
249 / 652
Parameter
Maximum APNs Allowed for Wildcard APN
SAM Table Name
UE PLMN Services
OSS ID
ltemme.UEPLMNServices.
Range & Unit
Integer
0-8
Impact of Change
No service impact.
Value
Operator Dependent;
Feature
m10100-04 . m10100-07
The MME supports two PDN connections to the same APN, meaning two Default
Bearers to the same APN (such that one Default bearer session is for the IPv4
connection and the other default bearer session is for the IPv6 connection).
This scenario is supported only if HSS subscription data allows IPv4v6 and the global
parameter Support Two UE Bearers for Dual PDN Type is set to Yes (default is No).
When set to No, two PDN connections to the same APN are not allowed.
Parameter
Support Two UE Bearers for Dual PDN Type
SAM Table Name
Global Parameters
OSS ID
Range & Unit
gParmName
String
Support_Two_UE_Bearers_for_Dual_PDN_Type
gParmValue
Boolean
Yes or No
Impact of Change
No service impact.
Value
Operator Dependent; default = No (not supported)
Prior to WM8.0.0 release, the UE requests PDN type IPv4v6 and if the HSS
subscription data allows IPv4v6 version, but the network overrides or responds with a
PDN type requested by the UE with a single IP version only (such as when the PGW
does not support IPv4v6 dual stack connection), the MME sets the PDN type value to
the version assigned in the response (PDN type is adjusted to that PDN type either
"IPv4" or "IPv6"). The UE then subsequently requests another PDN connection for the
other IP version using the UE-requested PDN connectivity procedure to the same APN
with a single address PDN type (IPv4 or IPv6) other than the one already activated.
When the global parameter Allow Mixed PDN Address Allocation Types is set to Yes
and upon sending a Create Session Request and the PDN type is IPv4v6, if only one of
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
250 / 652
the IP versions is statically provisioned in the HSS, other IP version is set to all zeros
thus also allowing for dynamic PDN Address Allocation.
Parameter
Allow Mixed PDN Address Allocation Types
SAM Table Name
Global Parameters
OSS ID
Range & Unit
gParmName
String
gParmValue
Boolean
Yes or No
Impact of Change
No service impact.
Value
Feature Name
m10099-06
PDN types IPv4, IPv6 and IPv4v6 are supported. An EPS Bearer of PDN type IPv4v6
can be associated with one IPv6 prefix only or with both one IPv4 address and one IPv6
prefix. It is possible to specify per APN which PDN Types are accepted.
Prior to WM8.0, when an an additional PDN connection request is received after attach
the MME checks to see whether there is already a PDN connection to the network
specified by the APN in the request. When the received APN is the same as the APN of
a PDN connection that has already been established for the given UE, the MME sends
a PDN Connectivity Reject with cause code 55.
Instead of sending a PDN Connectivity Reject the MME first delete the previously
established PDN connection and then honor the subsequent PDN connection request.
Note that if the PDN Connectivity Request with APN=x is for a UE with only one already
established PDN connection and that connection is for APN x, the MME would have to
reject the PDN Connectivity Request as is currently done.
The global parameter Delete Previous PDN Connection On New Request determines
the call flow of a PDN Connectivity request where a UE already has PDN connection
If the global parameter Delete Previous PDN Connection On New Request is set to
true, upon the receipt of a PDN connectivity request (APN=x) for which the MME has
an already established connection to the same APN=x, and that PDN connection is not
the only APN connection, the MME deletes the existing PDN connection prior to
processing the new PDN Connectivity request.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
251 / 652
Parameter
Delete Previous PDN Connection On New Request
SAM Table Name
Global Parameters
OSS ID
gParmName
String
Dlt Prev PDN Conn On New Req
Range & Unit
gParmValue
Boolean
Yes or No
Impact of Change
No service impact.
Value
Feature Name
m10140-01
8.1.2.5.3.1 APN CORRECTION

The MME supports APN correction for incorrect APN request by the UE.
During the initial attach procedure, if the Support APN correction global parameter is
enabled, MME checks if the UE indicated a preferred APN against the APNs listed in
the subscription profile received from the HSS. If the preferred APN does not match any
of the APNs listed in the subscription profile, the MME uses the default APN from the
subscription profile in order to perform APN correction, so as not to fail a Request and
Create Session Request activation procedure.
Parameter
Support APN Correction
SAM Table Name
Global Parameters
OSS ID
gParmName
String
Range & Unit
gParmValue
Boolean
Yes or No
Impact of Change
No service impact.
Value
Feature name
m10137-02
When the Support APN correction global parameter is enabled:

MME checks if the UE requested APN is incorrect or illegal.
Illegal or Invalid APN constitute apn requested by UE is not according 3GPP 23.003
format. Following are some of the examples of illegal/invalid APN:
The user request APN that doesnt follow 3GPP defined apn format;
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
252 / 652
User request APN with .gprs in the beginning or APN network identifier start with any of
the strings rac, lac, or rnc or with "*".
When there is no ESM Information Transfer exchange during the initial attach, MME just
attach to the default APN without considering it as a correction. This is a normal
behavior.
MME attach to the default APN, when there is ESM Info transfer, but the APN field is
empty during initial attach. This is a normal behavior and is not considered as an APN
correction. However, on a subsequent PDN connectivity request, or upon receipt of the
PDN CONNECTIVITY REQUEST message, the MME checks whether APN name
would be included. If no requested APN is included in the PDN CONNECTIVITY
REQUEST message and the request type is different from "emergency", the MME
rejects the PDN connect request. This is also a normal behavior, regardless whether
the Support APN Correction global parameter is enabled or not.
With the support of Dual PDN type, MME supports APN Correction on the second PDN
connection under the same APN as the first PDN connection if the PDN type is
different. In addition, additional PDNs from subscribed APNs are handled when sending
or receiving from other SGSN and MME.
APN Correction Support only applies to homers or treats as homer UEs. For roamers,
any illegal APNs request would be rejected with ESM cause (#33) but any unsubscribed
APNs that could be found in the DNS database are honored if the UE has wildcard APN
subscribed.
PDN type can be same or different (IPv4, IPv6, IPv4v6). If 2 PDN connections existing
on same default APN, consequent PDN connection requests with invalid APN will be
rejected.
Dual Bearers (multiple PDN connections are supported, i.e. separate IPv4 and IPv6
default bearers are supported)
Wildcard APN profile is ignored if its populated in the subscription profile.
A maximum number of two illegal or incorrect APN corrections are supported.
Any consequent PDN connection request with the third invalid APN will be rejected.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
253 / 652
8.1.2.5.3.2 PDN ON DEMAND SIGNALING ONLY UE
UE can be in ECM-CONNECTED or ECM-IDLE state without a PDN connection. In the
UE subscription, the data vendor-specific AVP, PDN-On-Demand-Allowed indicates
whether a UE is allowed to be in ECM-CONNECTED or ECM-IDLE state without any
bearers.
When the global parameter Signaling only UE is set to YES (enabled), the MME
supports UEs with signaling-connection only, otherwise the MME treats these UE as
normal UEs. This feature is applicable only to UEs that can support the EMMREGISTERED and ECM-IDLE state without a PDN connection. The Figure 10-2 shows
handling of UE Service Request and a subsequent UE PDN Connectivity request
handling.
eNB
UE
SGW/
PGW
MME
1. Service Request
2. S1AP INITIAL UE MESSAGE
The UE has no PDN connections. So, MME will not send S1AP
INITIAL CONTEXT SETUP REQUEST message. Instead MME will
send NAS EMM INFORMATION REQUEST message using S1AP
DOWNLINK NAS TRANSPORT message to establish UE S1 link so
that any UE requests can be sent by eNB to MME.
3a. ESM INFORMATION REQUEST in

S1AP DOWNLINK NAS TRANSPORT
3b. ESM INFORMATION REQUEST
4a. PDN CONNECTION

REQUEST
4b. S1AP UPLINK NAS
TRANSPORT message with
PDN CONNECTION REQUEST
MME upon successful creation of the session will send S1AP

INITIAL CONTEXT SETUP REQUEST message with NAS PDU set
to ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST
message.
5. Create Session Request/

Response
7a. ACTIVATE DEFAULT EPS BEARER
CONTEXT REQUEST
7b. ACTIVATE DEFAULT EPS

BEARER CONTEXT ACCEPT
6. S1AP INITIAL CONTEXT SETUP

REQUEST message with NAS PDU set
to ACTIVATE DEFAULT EPS BEARER
CONTEXT REQUEST
7c. S1AP UPLINK NAS

TRANSPORT message with
ACTIVATE DEFAULT EPS
BEARER CONTEXT ACCEPT
8. Modify Bearer Request/

Response
Figure 8-2 Call Flow showing handling of SR for a UE without a PDN

connection and UE subsequently requesting a PDN Connection
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
254 / 652
When the global parameter Signaling only UE is enabled, the MME supports the
following capabilities for On Demand PDN only UEs:
Combined Attach Request with SMS-only option
Periodic TAU request without MME relocation only (with and without active flag)
Service Request
All SM procedures
The following MM capabilities are not supported:
X2 Handover without a PDN connection
S1 Handover without a PDN connection (with/without MME relocation)
MME relocating TAU without a PDN connection
Note that the MME does not update the SRS with the context of these UEs.
8.1.2.5.3.3 UE LOAD BALANCING OF ON DEMAND PDN ONLY

UES WITHOUT A PDN CONNECTIONS
The MME supports load balancing (UELB) of PDN-on-Demand (Signaling only) UEs
without any bearers. When requested by a new MME sending S10 Context Request,
the old MME sends the context of UEs without bearers. The old MME indicates to the
new MME that the context is for a PDN on Demand UE with a proprietary cause 253 in
the S10 Context Response message.
The MME UE loab balancing mechanism treats connected signaling UE without any
bearers as ECM-IDLE UEs. When UE loab balancing is run with locate ECMCONNECTED UEs, the connected signaling-only UEs are relocated.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
255 / 652
8.1.2.5.4 PGW SELECTION
The PGW is the network element that 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 PGW IP address and APN information is sent in the
Create Session Response message.
After selecting a SGW, if a PGW also needs to be assigned for this UE's PDN session,
the MME uses topological matching to select a PGW that is closest to the SGW. By
default, topological matching to select a PGW is not required if an SGW supporting the
S8 interface is selected.
If there are more than a single PGW, MME selects a PGW as follows:
PGW host with lowest service-provider-defined order value is selected.
If more than one S-NAPTR record has the same lowest order value, the MME
selects a record in proportion to the S-NAPTR preference value. If the elected SNAPTR record is an "S" type record, the SRV record with the lowest Priority
value is selected (where a lower priority gets higher proportion of traffic).
If more than one SRV record has the same lowest priority value, the MME selects
a record in proportion to the SRV weight value (where a higher weight gets
higher proportion of traffic).
If there are more than a single host with the same order value, MME assignsUE
sessions in proportion to the preference value.
The PGW S-NAPTR record returned from initial APN NAPTR query with the
lowest order value is selected.
If the selected S-NAPTR record is of type "", the MME must consider a second
level of S-NAPTR records associated obtained by querying the resource
replacement string. The MME uses Order and Preference of the 2nd level SNAPTR record to further refine selection of the PGW.
If the selected S-NAPTR record is an "S" type the selected S-NAPTR was a " "
type record, the SRV record with the lowest Priority value is selected ().
A PDN can have multiple PGWs. MME either uses statically-allocated PGW FQDN or
IP address or selects a PGW using S-NAPTR procedure (dynamic allocation of PGW).
The PGW allocation information for each APN is obtained from the HSS at the attach
time.
Figure 8-3: PGW Functionality
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
256 / 652
During the Attach procedure, the HSS subscriber data specifies dynamic allocation
type. If MIP6AgentInfo, Hostname FQDN, or IP address is provided, it is ignored. The
MME performs an APN S-NAPTR procedure to obtain PGWs from the DNS. For an
eHRPD Handover Attach type, the MME uses the MIP6AgentInfo FQDN to perform a
PGW FQDN NAPTR query instead of APN NAPTR.
Utilizing information from the subscription data the MME determines how to handle the
request as follows:
When Allocation type is set to "Static" and the Request type is Handover or
Initial Request, the MME does not send a Notify Request (NOR) to the HSS.
Instead, the MME acts based upon the following decision table:
PGW FQDN in
UE
Subscription
Data?
PGW IP
Address in
UE
Subscription
Data?
Handover
to Non3GPP
Access is
Allowed?
MME Actions
Yes
Yes
Does not
If FQDN starts with topon or
matter
topoff (such as FQDNs

provisioned in HSS), MME strips
off the first two labels and uses the
resulting FQDN in the S-NAPTR
procedure.
Yes
No
Does not
If FQDN does not start with
matter
topon or topoff, MME strips off

the first label and uses the
procedure.
No
No
Yes
No
Does not
MME uses the IP address for the
matter
PGW.
Does not
MME treats this as an error and
matter
rejects the Attach/PDN

Connectivity Request with cause
value missing or unknown APN.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
257 / 652
When Allocation type is set to "Dynamic" and the Request type is Handover, the
MME does not send a Notify Request (NOR) to the HSS. Instead, the MME acts
based upon the following decision table:
PGW FQDN in
UE
Subscription
Data?
PGW IP
Address in
UE
Subscription
Data?
Handover
to Non3GPP
Access is
Allowed?
No
Yes
Yes
Yes
Yes
No
Does not
matter
Yes
Yes
Yes
No
No
No
No
Yes
MME Actions

procedure.
procedure.
IP address is not used.
procedure.
procedure.
MME uses the constructed APN
FQDN in the S-NAPTR procedure.
MME treats this as error and
Connectivity Request.
MME treats this as error and
Connectivity Request.
Even though Dynamic allocation is indicated, if the UE already has activated bearers on
a PGW in a non-3GPP network (eHRPD) and then moves into LTE (setting the PDN
Connectivity Request's Request Type information element to handover), the eHRPD
stores the replacement FQDN string (obtained and selected from the S-NAPTR
procedure in HSS) so that the LTE MME selects an interface on the same PGW.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
258 / 652
When Allocation type is set to "Dynamic" and the Request type is Initial
Request, the MME acts based upon the following decision table:
PGW FQDN
in UE
Subscription
Data?
Present
Present
Not Present
Not Present
PGW IP
Address in UE
Subscription
Data?
Any
Any
Any
Any
Handover
to Non3GPP
Access is
Allowed?
MME Actions
Yes
IP address is not used. If the

FQDN starts with topon or
topoff MME strips off the first two
labels and uses the resulting
the first label and use the resulting
MME sends Notify Request (NOR)
to HSS.
No
IP address is not used. If the

FQDN starts with topon or
topoff, MME strips off the first
two labels and uses the resulting
the first label and use the resulting
MME sends Notify Request (NOR)
to HSS.
Yes
MME uses the APN FQDN for the

NAPTR procedure to select the
PGW. See Note 1 (below) for an
exception for roamers.
No
MME uses the APN FQDN for the

NAPTR procedure to select the
PGW. MME is not required to
send the Notify Request to the
HSS.
Note 1: For a roamer, if the provisioning Access Restriction Data for the UEs PLMN is
set to cmda_2000_not_allowed, then the MME does not send Notify Request
irrespective of the roamers subscription Access-Restriction-Data AVP indicates that HO
to Non-3GPP access is allowed.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
259 / 652
Sample PGW FQDNs:
PGW FQDN provisioned in HSS:

topon.lb1.pgw01.WSBO.SA001.NE.ENT002.node.epc.mnc480.
mcc311.3gppnetwork.org
PGW FQDN (after having labels stripped) used in S-NAPTR procedure:
pgw01.WSBO.SA001.NE.ENT002.node.epc.mnc480.mcc311. 3gppnetwork.org
The information obtained from the subscriber data is then used in S-NAPTR procedures
(as per standard TS 29.303) to select the PGW. MME supports:
both type A and AAAA records. MME supports up to 10 A and AAAA records per
PGW FQDN. FQDN size must be less than or equal to 100 characters.
PGW selection is based on topological match to the chosen SGW (if topon
specified) and Order value.
Note: Topological matching will not be performed for roamer home-routed PGW
scenario (where PGW is located in the UE's home network).
Once a PGW is selected, the MME sends the PGW IP address and APN to the SGW.
The SGW then sets up the connection to the PGW, and the PGW connects the UE to
the APN.
MME sends a Notify Request (NOR) to the HSS to delete the PGW IP address and
FQDN whenever MME successfully deletes a PDN connection for an APN if all of the
following conditions are met:
MME selected the PGW when the PGWAllocation type was set to Dynamic.
MME sent a Notify Request (NOR) to the HSS to update the PGW FQDN and IP
addresses.
MME has not deleted the PDN connection due to a Delete Bearer Request from
PGW specifying "RAT changed from 3GPP to Non-3GPP".
NOTE: To ensure consistency in sending/not sending of the Notify Request (NOR) to

the HSS as a result of an Insert Subscriber Data Request command (IDR) from HSS for
the PGWAllocation Type and Access restriction Data, the service provider must update
the PGW allocation type and Access Restriction data by having the HSS imitate a
detach to update the fields. MME simply updates the UE Context data upon receiving
the IDR.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
260 / 652
Th global parameter PGW PLMN ID Exclusion support controls the inclusion of the
PGW PLMN ID AVP when PDN GW Identity IE containing an FQDN is present in an
S6a NOR message.
As per [R13], Table 5.2.5.1.1/1: Notify Request, the PGW PLMN ID IE identifies the
PLMN in which the PDN GW is located and is conditionals to the following conditions
states :
IE name
Mapping to Diameter AVP
Description
This IE identifies the PLMN in which the
PGW PLMN ID
Visited-Network-Identifier
PDN GW is located. It shall be present

when the PDN GW Identity is present and
does not contain an FQDN.
The MME currently includes this IE when the PDN GW Identity is present both when the
PDN GW identity does and does not contain an FQDN. The standards are not clear
whether or not the IE should be included. It is clear that the IE is not needed when the
PDN GW ID contains an FQDN (since the PLMN ID is required to be present in the
FQDN).
By default, global parameter PGW PLMN ID Exclusion support is disabled, which
means that the PGW PLMN ID IE (Visited-Network-Identifier AVP )is always included
when PDN GW Identity IE containing an FQDN is included in an S6a NOR message.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
261 / 652
8.1.2.5.4.1 ROAMING
Operators must ensure that all SGWs in their network support both S5 and S8
interfaces prior to using the Roaming feature.
For roaming cases, the MME selects a PGW in the UE's PLMN (home network) or
VPLMN. Selection of SGW and PGW based on the geographical proximity does not
apply to roaming UEs when the PGW is located in the UEs home network (that is,
home-routed scenario). If selected from the UE home network, the MME selects a PGW
supporting the S8 interface. It selects a PGW supporting the S5 interface if selected
from the VPLMN.
8.1.2.5.4.2 TOPOLOGICAL LABEL MATCHING FOR S8 PGW

SELECTION
The global parameter Topological Label Matching for S8 PGW Selection controls
whether topological matching is used to select an S8 PGW for home-routed scenarios.
By default, this parameter is disabled. When the Topological Label Matching for S8
PGW Selection parameter is set to false, the MME will not attempt to use label
matching to select the PGW but instead use just the DNS order and preference values.
When the parameter is set to true, the MME will use the same label matching algorithm
used for S5 PGW selection for S8 PGW selection. When this parameter is set to true, it
is up to the service provider to ensure that the labels provided in the SGW and PGW
FQDNs are consistent so that label matching will be effective. In particular, the SGW
and PGW FQDN values provisioned in the DNS server for mnc and mcc must match.
This parameter is only valid for GW Selection Mode 1, and has no effect on PGW
selection if GW Selection Mode 2 is enabled.
Parameter
Topological Label Matching for S8 PGW Selection
SAM Table Name
Global Parameters
OSS ID
Range & Unit
gParmName
String
Topological_Label_Matching_for_S8_PGW_Selection
gParmValue
Boolean
Yes or No
Impact of Change
No service impact.
Value
Operator Dependent; default = No (not supported)
8.1.2.5.4.3 PGW SELECTION FAILURE

PGW selection failures include scenarios such as no NAPTR records for S5 and S8
services. The MME collects PGW selection failures for every two minutes and reports a
minor alarm (PGW selection failure alarm) at the end of the two-minute interval.
Detailed information about the PGW selection failures (such as the FQDN used in the
DNS query, the interface type and the reason for PGW selection failure) is available in a
customer-viewable log file. The alarm must be manually cleared.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
262 / 652
8.1.2.5.4.4 HPLMN/VPLMN PGW SELECTION FOR PDN
CONNECTION REQUESTS
The following table specifies how a PGW is selected by the MME for a roamer UE for
an Attach Request and standalone PDN Connectivity Request. It is assumed that the
PGW is dynamically allocated (PDN-GW-Allocation Type AVP is set to DYNAMIC) and
the HSS does not provide FQDN in MIP6-Agen-Info AVP. These rules apply whether a
UE is in a connected state or in idle state.
Honor
VPLMN
Request
(MME GUI,
Roaming
PLMN form)
HSS
VPLMNDynamicAddressAllowed
AVP
HSS-ODBHPLMNAPN AVP
HSSODBVPLMNAPN AVP
HSS-ODBAll-APN
AVP
Barred
Barred
Barred
Allow
Allowed
Not Barred
Not
Barred
Not Barred
Allow
Allowed
Barred
Not
Barred
Not Barred
Allow
Allowed
Not Barred
Barred
Not Barred
Not
Allowed
Not Barred
Not Barred
Not
Allowed
Barred
Not Allow
Not Barred
Not Barred
Not Allow
Barred
Attach Request MME

Actions
MME rejects the attach

request with ESM failure
and PDN Connectivity
request with ESM cause
value of operator
determined barring.
value of operator
determined barring.
MME selects PGW with S5
interface in PLMN (See
Note).
interface in VPLMN always.
interface in UEs HPLMN.
value of operator
determined barring.
MME selects PGW withS8
value of operator
determined barring.
(*) indicates the value does not matter.

Note: If full APN is specified in initial attach or PDN connectivity request and APN OI
matches MNC and MCC of VPLMN (MMEs HPLMN), then the MME ignores any APNOI replacement and MME selects a PGW that supports s5 (local-breakout) from the
APN NAPTR query.
If full APN is specified in initial attach or PDN connectivity request, and APN OI matches
the MNC/MCC of the UEs IMSI (UE HPLMN), the MME applies APN-OI replacement (if
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
263 / 652
specified) to form the APN NAPTR FQDN, and MME selects a PGW that supports s8
(home routed) from the APN query result.
If full APN is specified in attach/PDN connectivity request and APN-OI does not match
UEs HPLMN or the VPLMN, MME rejects the PDN Connection Request with ESM
cause #27 Missing or unknown APN and rejects Attach Request with EMM cause #19
ESM failure.
If APN-NI only is received in attach/PDN connectivity request, and APN-OI
Replacement string is present, then the MME generates an APN using APN-OI
replacement and the MME selects a PGW that supports s8 (home routed) from the APN
query result.
Else (APN-NI only specified and no APN-OI Replacement string), the MME generates
the full APN using the MME HPLMN MNC/MCC values and MME selects a PGW that
supports s5 (local breakout) from the APN query result.
The following table specifies ODB checks and S8 or S5 selection for the roaming cases
below:
PDN-GW- Allocation-Type is set to STATIC and MIP6-Agent-Info is populated

with FQDN.
PDN-GW- Allocation-Type is set to DYNAMIC and MIP6-Agent-Info is populated

with a FQDN.
The MME checks the <MNC> and <MCC> lavels of the Destination-Realm AVP to
determine the location of the PGW.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
264 / 652
Network
pointed to by
DestinationRealm AVP
Setting
Honor
VPLMN
Request
(MME GUI,
Roaming
PLMN form)
HSS-ODBHPLMN-APN
AVP
HSS-ODBVPLMN-APN
AVP
HSSODBAll-APN
AVP
Attach Request
MME Actions
Barred
MME shall reject the

attach request with
ESM failure and
PDN Connectivity
request with ESM
cause value of
operator determined
barring.
UEs Home
Network (Note
1)
Barred

attach request with
ESM failure and
PDN Connectivity
request with ESM
cause value of
operator determined
barring.
UEs Home
Network (Note
1)
Not Barred
Not
Barred
MME shall select S8

interface.

attach request with
ESM failure and
PDN Connectivity
request with ESM
cause value of
operator determined
barring.
MMEs Home
Network
Not Allow
MMEs Home
Network
Barred

attach request with
ESM failure and
PDN Connectivity
request with ESM
cause value of
operator determined
barring.
MMEs Home
Network
Allow
Not Barred
Not
Barred
MME shall select S5

interface.
(*) indicates the value does not matter.

Notes:
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
265 / 652
1
MME treats PGWs location as if it were in UEs HPLMN for the following
conditions and selects S8 if all the conditions in the table are satisfied:
MCC and MNC matches with MCC and MNC in UEs IMSI, DestinationRealm is missing,
Destination-Realm does not contain a valid format (valid format is
epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org) or Destination-Realm is not
UEs home network and MMEs home network
Issue 11.01
If full APN is specified in attach/PDN connectivity request and APN-OI does

not match the Destination-Realm, MME rejects the PDN Connection
Request with ESM cause #27 Missing or unknown APN and rejects Attach
Request with EMM cause #19 ESM failure.
LTE/DCL/APP/031094
Nokia 2016
266 / 652
8.1.2.5.5 FALLBACK TO DEFAULT APN-OI ON DNS FAILURES
The global parameter Fallback to Default APN-OI" controls the use of default APN-OI
in APN NAPTR query if the NAPTR query for an APN with APN-OI replacement string
fails :
Parameter
Fallback to Default APN-OI
SAM Table Name
Global Parameters
OSS ID
gParmName
String
Fallback to Default APN-OI
Range & Unit
gParmValue
Boolean
Yes or No
Impact of Change
No service impact.
Value
Depending if a UE is a home subscriber, roamer treated as a home subscriber or

roamer, MME takes the following actions if NAPTR query for an APN using APN OI
replacement fails (i.e. MME timed out waiting for DNS server response or DNS query
response has not returned any valid RR):
UE Treatment
MME Actions
Home Subscribers UE:
MME launches the APN NAPTR query with APN OI of

the APN FQDN set to the UE HPLMN ID (I.e. PLMN ID
in the UE IMSI).
Treat
As
Subscriber UE
MME launches a second APN NAPTR query with APN

OI of the APN FQDN set to the provisioned PGW DNS
Domain Override. Separate domain override can be
provisioned for home subscriber and roamer UE. If this
NAPTR query fails to return any valid RR or times out
then MME launches a third APN NAPTR query with
APN OI set to the serving PLMN ID
Roamer UE:
Issue 11.01
Home
MME launches a second APN NAPTR query with APN

OI of the APN FQDN set to the provisioned home
routed APN OI override for the roamer UE. If this
NAPTR query fails to return any valid RR or times out
then MME launches a third APN NAPTR query with
APN OI of APN FQDN set to the UE HPLMN ID (i.e.
PLMN ID in UE IMSI).
LTE/DCL/APP/031094
Nokia 2016
267 / 652
This feature is applicable to home subscriber UE, UE that treated as home subscribers
and also inbound roamers. LTE PGW DNS Domain Override (PGW Domain name
MCC/MNC) has to be provisioned or Home Routed PGW DNS Domain Override (Treat
Roamer As Home Subscriber) has to be enabled.
8.1.2.5.6 SGSN SELECTION

The MME supports a provisioning option to indicate whether or not the SGSNs in the
network support dual stack for the UE. If the global parameter is set to No, then the
MME only allocates IPv4 addresses for a PDN connection so all bearers can be
preserved over a handover.
Parameter
IPv4v6 SGSN
SAM Table Name
Global Parameters
OSS ID
gParmName
String
IPv4V6_SGSN
Range & Unit
gParmValue
Boolean
Yes or No
Impact of Change
No service impact.
Value
Operator Dependent; default = No (dual stack is not supported)
Rule: EPS Bearers for IPv4 & IPv6 Addressing

An operator that has pre-Rel 8 SGSNs in its network should use separate EPS
bearers for IPv4 and IPv6 addressing, so that both addresses can be maintained
when moving to a pre-Rel 8 SGSN from a Rel 8 SGSN or MME.
In support of this, the MME complies with section 5.8 "Functionality for Intra Domain
Connection of RAN Nodes to Multiple CN Nodes" of 3GPP TS 23.060 for Pre-Release 8
Gn interface and the Release 8 S3 interface. This is for cases/scenarios involving
Identification Response and SGSN Context Response messages that come back from
a different SGSN than the one the MME originated to.
Pre-Release R8 dual-stack solution consists of two Single-Address-Bearers (SAB), one
IPv4 and one IPv6 address while Dual Address Bearers (DAB) consists of dual-stack
PDP/PDN type, IPv4 and IPv6 addresses are assigned to the PDP context.
Since Release 8, the 3GPP EPS architecture supports the coexistence of IPv4 and IPv6
with dual-stack operation. Dual-stack operation means that native IPv4 and native IPv6
packets are transported in parallel by tunneling them from the UE to the PGW within a
single EPS bearer/. This dual-stack EPS bearer is associated with both an IPv4 address
and an IPv6 prefix.
There are three main applications of the DAB bearer:
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
268 / 652
3G and LTE combined deployment: requires IPv4v6 bearer in 2G/3G/LTE. During interRAT mobility between E-UTRAN and UTRAN/GERAN, an EPS bearer with PDP type
IPv4v6 is mapped onto a PDN type IPv4v6. In order to offer service continuity during IRAT HO from an IPv4v6 enabled LTE network, it is required that all the inter-working
2G/3G SGSNs support 3GPP Rel-9 with IPv4v6 PDP type (this is called coherent
support of IPv4v6 PDP type)
5620 SAM
9453 XMS
GERAN
UTRAN
BTS/NB
BSC/RNC
EUTRAN
9471 WMM
MME/SGSN
Public IPv6
Internet
5780 DCS
PCRF
S12
IPv4
Backhauling
S1-U
Application
Servers
Border
Gateway
Public IPv4
Internet
IPv4
Network
Application
Servers
S5/S8
eNB
7750
SGW
(*) Interworking with S4-SGSN is assumed
End-user level
Application
Servers
8650 SDM
HSS/HLR
7750
PGW
Private
IPv4/IPv6
Network
Transport level
IPv4-only
IPv4-only
Dual-stack
Dual-stack
IPv6-only
IPv6-only
GTP tunnel
VitalQIP
DNS
5910
MiTV
Figure 8-4 Handling of IPV4 and IPV6 PDN

Evolution of the 3G network from SAB to DAB: This scenario covers the evolution of a
pre Rel-8 network to a 3GPP Rel-9 or later. The network has to cope with the
interworking by accepting the PDP Type IPv4v6 requests and assigning a PDP type
according to the capabilities of the SGSN, the preference of the GGSN and the data
provisioned per APN in the HLR.
Roaming support of DAB: IPv4v6 PDP type could be part of a roaming agreement.
VPLMNs SGSN can decide which PDP type (IPv4, IPv6, and IPv4v6) is allowed for
roaming users. A DAB VPLMN, can be configure so that IPv4v6 PDP type is not
allowed in the roaming agreement. This application is of general interest to all operators
because of roaming interoperability for networks in different stages of upgrades. If DAB
is not allowed the decision process is followed as if the DAB capability is disabled in
SGSN.
Prior to WMM8.1.0 (without DAB support), upon completion of an Inter-RAT HO/TAU,
the MME delete the PDN connections if the session are determined to be DAB
restricted
In, WMM8.1.0, (with DAB support enabled), the HOs processing continue as normal, no
additional restrictions will apply.
MME supports the handling of IPV4 and IPV6 PDN when the home network of the
roaming agreements does not support for the IPv4v6 bearers. The UE request IPv4 and
IPV6 dual-stack addresses allocation in a single session by sending IPv4 and IPv6 PDN
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
269 / 652
type. An IPv4v6 PDN connection can be associated with one IPv6 address / prefix only
or with both IPv4 and IPv6 address / prefix.
The following DAB (Dual Address Bearer) bearer context access restrictions is
supported during an Inter RAT HO/TAU:
MME DAB-support
configuration
MME action / Results
DAB support is disabled
MME terminates DAB bearers of all UEs (DAB

restricted)
(Accept DAB = false )

DAB support enabled
MME allows DAB bearers for homers and

roamers-treated-as-homers UE. (Not restricted).
(Accept DAB = True )

DAB-support
enabled
and
roaming-agreements
roamingnetwork accept-dab is enabled
MME allows DAB bearers for roamers. DAB

bearer contexts for Roamers are allowed (not
restricted)
DAB support enabled

accept-dab is disabled
DAB bearer contexts for Roamers are restricted

for that PLMN
and
DAB support can be turned off in order to support interworking with nodes of earlier
releases.
By default, the global parameter DAB support is disabled to support interworking with
MME or SGSN where DAB is not supported or also to support interworking with nodes
of earlier releases.
The operator must activate DAB support when all MME and SGSNs are capable of
supporting dual address bearers. DAB support is configured at the system level and
applies to all defined mobiles networks.
Parameter
Accept DAB
SAM Table Name
UE PLMN Services
OSS ID
ltemme.UEPLMNServices. AcceptDab
Range & Unit
Boolean
Yes or No
Indicates whether PLMN accepts DAB (Dual Access
Bearer).
Issue 11.01
Impact of Change
No service impact.
Value
Operator Dependent;
Feature
m50051-01, m50051-02
LTE/DCL/APP/031094
Nokia 2016
270 / 652
The parameter IPv6 PDN Type Used When DAB Is Not Supported can be defined
at PLMN level or Roaming Agreement level (UE PLMN Service). The two distinct IPv6
PDN Type Used When DAB Is Not Supported specifiies the preference of the IPv6
PDN/PDP when IPv4v6 PDN is not granted for either homer or either roamer UE on the
target MME or SGSN for HO/TAU to 4G procedures .
Theres no interaction between both parameter IPv6 PDN Type Used When DAB Is
Not Supported configured at PLMN level and UE PLMN service
Parameter
IPv6 PDN Type Used When DAB Is Not Supported
SAM Table Name
UE PLMN Services
OSS ID
ltemme.UEPLMNServices. IPv6SupportForNoDab
Range & Unit
Boolean
Yes or No
Indicates whether IPv6 PDN type is used when PLMN does
not support DAB otherwise IPv4 PDN type is used
Impact of Change
No service impact.
Value
Operator Dependent;
Feature
m50051-01, m50051-02
By default, if the MS requested type is IPv4v6 and the APN subscribed is not IPv4v6 or
the dab support is flag is set to NO, or the parameter accept-dab is set to No (PLMN
dont accepts DAB), the selected PDP-type is IPv4. The operator may change the
default to IPv6 by setting IPv6 PDN Type Used When DAB Is Not Supported to Yes.
There is no interaction with the IPv6-default-for-no-dab configured at the mobilenetwork level. IPv6-default-for-no-dab applies ONLY to the SGSN function.
Parameter
IPv6 PDN Type Used When DAB Is Not Supported
SAM Table Name
OSS ID
ltemme.MMEPLMN. IPv6SupportForNoDab
Range & Unit
Boolean
Yes or No
Indicates whether IPv6 PDN type is used when PLMN does
not support DAB otherwise IPv4 PDN type is used
Impact of Change
No service impact.
Value
Operator Dependent;
Feature
m50051-01, m50051-02
(Please refer to the 9471 WMM Command Line Interface Reference Guide on how to
enabled DAB-support flag )
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
271 / 652
The global parameter Include R7 Qos Extensions Gn indicates whether or not R7
extensions to the QoS information element should be included in SGSN context
response and forward relocation request messages sent to SGSNs on the Gn interface.
Parameter
SAM Table Name
OSS ID
Include R7 Qos Extensions Gn

Global Parameters
gParmName
String
Include_R7_QoS_Extensions_Gn
Range & Unit
gParmValue
Boolean
Yes or No
Impact of Change
No service impact.
Value
Operator Dependent; default = No (R7 extensions not

included)
8.1.2.5.6.1 PRE-RELEASE 8 DISCOVERY

If the provisioning option for SGSN discovery is set to use pre-Rel 8 FQDN, then the
MME always uses the Gn interface to the selected SGSN.
For IRAT handover procedure to UTRAN/GERAN, the MME performs a DNS query to
determine the IP address of the target SGSN as follows the the provisioning option preRel-8 FQDN:
If the Target ID IE in the S1 Handover Required message contains the value

Target RNCID, the MME constructs the RNC FQDN as:
rnc<RNC>.mnc<MNC>.mcc<MCC>.gprs
The MME initiates a DNS query to obtain A and AAAA records. If the query returns no
records, the MME terminates the IRAT handover procedure and sends the S1
Handover Preparation Failure message to the source eNB with the cause set to
Unknown Target ID.

CGI, and RAC is included in the CGI, the MME constructs the RAI FQDN as:
rac<RAC>.lac<LAC>.mnc<MNC>.mcc<MCC>.gprs
records, the MME terminates the IRAT handover procedure and sends the S1
Handover Preparation Failure message to the source eNB with the cause set to
Unknown Target ID.

CGI, and RAC is not included in CGI, the MME terminates the IRAT handover
procedure and sends the S1 Handover Preparation Failure message to the
source eNB with the cause set to UnknownTarget ID.
For the Attach and TAU procedures with an MME change, the new MME first
determines if the old node is an SGSN or an MME. If the old node is an SGSN, the
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
272 / 652
MME performs a DNS query to determine the IP address of the old SGSN as follows
when pre-Rel8 FQDN is used:
The MME extracts the MCC and MNC fields from the GUTI contained in the old
GUTI or IMSI IE in the Attach Request message or contained in the old GUTI
IE in the TAU Request message.
The MME extracts the MME Group ID from the GUTI and maps it to LAC.
The MME extracts bit 23 to bit 16 from the M-TMSI in the GUTI and maps them
to RAC
The MME extracts the NRI from the P-TMSI.
The MME constructs the RAI FQDN if the provisioned number of NRI bits is nonzero: nri<NRI>.rac<RAC>.lac<LAC>.mnc<MNC>.mcc<MCC>.gprs
If the provisioned number of NRI bits is zero, then the MME uses the RAI FQDN to
determine the SGSN address.
records, the provisioned number of NRI bits is zero or it fails to discover the SGSN, then
it uses the RAI FQDN.
If DNS query with pre-Rel 8 NRI FQDN fails to discover SGSN or provisioned number of
NRI bits is zero, the following procedure occurs. For Attach and TAU procedures with
an MME change, the new MME first determines if the old node is an SGSN or an MME.
If the old node is a SGSN, the MME performs a DNS query to determine the IP address
of the old SGSN as follows pre-Rel8 FQDN is used:
The MME extracts the MME Group ID from the GUTI and maps it to the LAC.
to RAC
The MME constructs the RAI FQDN as:
rac<RAC>.lac<LAC>.mnc<MNC>.mcc<MCC>.gprs
The MME initiates a DNS query to obtain A and AAAA records. If the query
returns no records, the MME takes the appropriate actions according to the
Attach procedure and TAU procedure.
The MME also provides a provisioning option to use the pre-Rel8 FQDNs or the SNAPTR procedure for the discovery of SGSN. The default value is S-NAPTR and is
provisioned per MME. It also provides an option to provision number of NRI digits for
MME home PLMN and all other PLMNs (i.e. PLMN in the roaming PLMN table).
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
273 / 652
Parameter
SAM Table
Name
SGSN Discovery Method

Global Parameters
OSS ID
Range & Unit
gParmName
String
SGSN_Discovery_Method
gParmValue
Choice List
Use S-NAPTR Procedure
Use pre-Rel 8 FQDN
Use S-NAPTR and fallback
Impact of
Change
No service impact.
Value
Operator Dependent; default = Use S-NAPTR Procedure
Parameter
NRI Length
SAM Table Name
OSS ID
ltemme.MMEPLMN.nRILength
Range & Unit
Integer
[0..8]
Impact of Change
No service impact.
Value
Operator Dependent; defaults: 8 for Home PLMN, 0 for all

other PLMNs
8.1.2.5.6.2 RELEASE 8 DISCOVERY

If the provisioning option is set to Release 8 FQDN discovery of SGSNs (Use S-NAPTR
Procedure), then the MME will prefer 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 NAPTR query
and if no S3 links are available.
If an S-NAPTR query for SGSN fails to return any DNS records then the MME performs
a pre-Rel8 type query as described in the section Pre-Release 8 discovery.This is
done to allow a customer to slowly migrate DNS records for SGSN from pre-Rel8 to
Rel8+ queries instead of performing one flash cut of all SGSN records in DNS.
For IRAT handover procedures to UTRAN/GERAN, the MME performs a DNS SNAPTR query to determine the IP address of the target SGSN as follows. The SNAPTR procedure is only used if the provisioning option is set to use it.

Target RNC-ID, the MME constructs the RNC FQDN as:
rnc<RNC>.rnc.epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org
The MME initiates a DNS S-NAPTR query with this RAI FQDN and with Service
Parameters of x-3gpp-sgsn:x-s3 and x-3gpp-sgsn:x-gn. If the returned NAPTR
records contains x-3gpp-sgsn:x-s3 and x-3gpp-sgsn:x-gn services, the MME
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
274 / 652
chooses the x-s3 records over the x-gn records. If the returned S-NAPTR records do
not contain x-3gpp-sgsn:x-s3 or x-3gpp-sgsn:x-gn services, the MME terminates the
IRAT handover procedure and sends the S1 Handover Preparation Failure message to
the source eNB with cause set to Unknown Target ID.

procedure and sends an S1 Handover Preparation Failure message to the
source eNB with cause set to Unknown Target ID.
The MME initiates a DNS S-NAPTR query with the RAI FQDN and with Service
Parameters of x-3gpp-sgsn:x-s3 and x-3gpp-sgsn:x-gn. If the returned NAPTR
records contain x-3gpp-sgsn:x-s3 and x-3gpp-sgsn:x-gn services, the MME chooses
the x-s3 records over the x-gn records. If the returned S-NAPTR records contain neither
x-3gpp-sgsn:x-s3 nor x-3gpp-sgsn:x-gn services, the MME terminates the IRAT
handover procedure and sends an S1 Handover Preparation Failure message to the
source eNB with the cause set to Unknown Target ID.

procedure and sends an S1 Handover Preparation Failure message to the
source eNB with the cause set to Unknown Target ID.
For Attach and TAU procedures with an MME change, the new MME first determines if
the old node is an SGSN or an MME. If the old node is an SGSN, the MME performs a
DNS S-NAPTR query to determine the IP address of the old SGSN as follows:
MME extracts the MME Group ID from the GUTI and maps it to LAC. If the
MME needs to obtain the UE context from the old node, the MME supports
double-dipping of DNS to obtain the old node's IP address. The MME uses the
NAS message markers Old Guti Type IE or Old P-TMSI Signature. If any of the
markers are present, the MME relies only on those markers to determine the
serving node type (SGSN or MME). If the NAS message does not contain
previous serving node IE markers, MME can perform a double DNS dip to
determine the serving node and its IP address.
to RAC.
The MME extracts the NRI if the provisioned number of NRI bits is non-zero from
the P-TMSI. nri<NRI>.rac<RAC>.lac<LAC>.mnc<MNC>.mcc<MCC>.gprs. If the
provisioned number of NRI bits is zero, then the MME uses the RAI FQDN.
nri-sgsn<NRI>.rac<RAC>.lac<LAC>.rac.epc.mnc<MNC>.mcc<MCC>. 3gppnetwork.org
The MME initiates a DNS S-NAPTR query with this NRI FQDN and with Service
Parameters of x-3gpp-sgsn:x-s3 and x-3gpp-sgsn:x-gn. If the returned
NAPTR records contain x-3gpp-sgsn:x-s3 and x-3gpp-sgsn:x-gn services, the
MME chooses the x-s3 records over the x-gn records. If the returned S-NAPTR
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
275 / 652
records does not contain x-3gpp-sgsn:x s3 or x-3gpp-sgsn:x-gn services, then
the MME uses RAI FQDN.
If MME fails to discover an SGSN either using a NRI FQDN or RAI FQDN, then the
MME takes the appropriate actions according to the Attach procedure and TAU
procedure.
The following procedure only runs if an S-NAPTR procedure with NRI FQDN fails to
discover an SGSN or the provisioned number of NRI bits is zero. For Attach and TAU
procedures with MME change, the new MME first determines if the old node is an
SGSN or an MME. When the old node is an SGSN, the MME performs a DNS SNAPTR query to determine the IP address of the old SGSN as follows:
The MME extracts the MME Group ID from the GUTI and maps it to LAC.
to RAC.
rac<RAC>.lac<LAC>.rac.epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org
The MME initiates a DNS S-NAPTR query with this RAI FQDN and with Service
Parameters of x-3gpp-sgsn:x-s3 and x-3gpp-sgsn:x-gn. If the returned
NAPTR records contain x-3gpp-sgsn:x-s3 and x-3gpp-sgsn:x-gn services, the
MME chooses the x-s3 records over the x-gn records. If the returned S-NAPTR
records does not contain x-3gpp-sgsn:x-s3 or x-3gpp-sgsn:x-gn services, the
MME takes the appropriate actions according to the Attach procedure and TAU
procedure.
8.1.2.5.6.3 MME SUPPORT FOR DNS FALLBACK

ENHANCEMENTS FROM R8 DNS QUERY TO PRE-R8 DNS QUERY
If the SGSN Discovery Method global parameter is set to Use S-NAPTR and fallback,
the process is as follows:
The MME queries R8 NRI-RAI FQDN If R8 DNS query fails (that is, if the S3 interface
Hostname query fails), the MME uses the Gn interface to continue the processing.
The MME performs R8 RAI FQDN.
If the DNS responds including both S3 interface and Gn interface, MME prefers the S3
interface and start with the S3 interface list. If the current chosen S3 interface hostname
query fails, the MME goes down the list to choose another one until the S3 list is
exhausted, and then the MME goes through the Gn list as above.
If the DNS responds including ONLY the S3 interfaces and the current chosen S3
hostname query fails, the MME goes down the list to choose another one until the S3
list is exhausted. If the S3 list is exhausted, then the MME falls back to Pre-Rel8 NRI
query.
If the DNS responds including only the Gn interface list and the current chosen Gn
interface hostname query fails, the MME goes down the list to choose another one until
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
276 / 652
the Gn list is exhausted. If the Gn list is exhausted then the MME falls back to Pre-Rel8
NRI query.
8.1.2.5.6.4 SGSN POOLING

For SGSN pooling, the SGSN forwards a S3/Gn Identification Request and Context
Request to the correct SGSN in the pool for a UE attached to another SGSN. Using the
IEs in the messages that provide the requesting GTP entity source IP address and
source UDP port, the SGSN that received the forwarded messages responds to the
requesting GTP entity. The MME accepts the S3/Gn Identification Response and
Context Response received with the source IP address and source UDP port that is
different from the destination IP address and destination UDP port that were used in the
S3/Gn Identification Request and Context Request message.
The MME sets the destination IP address of the Context Acknowledge message as
specified in the following:
S3 Context Acknowledge Uses the IP address from the Sender F-TEID IE for
Control Plane IE received in the S3 Context Response
Gn Context Acknowledge Uses the IP address received in the SGSN Address

for the Control Plane IE of the Gn Context Response
The MME sources the UDP port of the S3/Gn Context Response message as the
destination UDP port for the S3/Gn Context Acknowledge message.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
277 / 652
8.1.2.5.7 HSS / DRA SELECTION
MME performs HSS selection based on whether IMSI range-based mapping is
provisioned or not. If there is no provisioned IMSI mapping, then selection is based
upon whether the UE has a Home PLMN or Roaming PLMN (roaming feature).
The MME supports HSS / DRA selection as follows:
A maximum of 63 unique HSS / DRA entities can be defined and connected for
HSSs in the MME Home PLMN, in any equivalent PLMNs, and in roaming
PLMNs. Either one or two IP addresses can be provisioned for each HSS / DRA
Remote Endpoint. If two addresses are provisioned, this indicates that remoteend multi-homing (when available) will be used for the interface between the
MME and the provisioned HSS. When SCTP multi-homing is available each
HSS endpoint may be configured with a primary IP address and an alternate
(secondary) IP address.
Up to eight HSS / DRAendpoints can be defined via an HHS group for the Home
PLMN,Shared PLMN or a roaming PLMN .
Up to 144 PLMNs can be used for IMSI ranges per PLMN, with a combined total
of up to 8192 IMSI to HSS rules that can be shared between all PLMN
Provisioning of HSS entities for either a PLMN or an IMSI range. The maximum
number of HSS entities which can be provisioned is dependent on whether the
provisioning is for an IMSI range or a PLMN (and the type of the PLMN if it is for
a PLMN). All the HSS servers are provisioned in order of decreasing precedence.
The MME can be provisioned with:

-
One HSS group can be defined with up to eight HSS/DRA entities if an IMSI to
HSS rule of type ALL without a range defined (without Minimum MSIN and
Maximum MSIN) and using HSS group name.
One HSS group on the Home PLMN replaces the S6a Diameter Connection set
of 1-4 HSS IP IDs from previous releases.
The HSS entities in a HSS group are considered as 1 primary, 2 secondary, 3

tertiary, and 4-8 as n-ary HSS (or DRA) entity.
IMSI-to-HSS routing rule of type odd or even: The mapping type can be
provisioned as "odd" or "even". An odd IMSI value or an even IMSI value is
determined based on the least significant digit of the IMSI MSIN. For both odd
and even IMSI value, an HSS group including up to eight HSS servers can be
provisioned.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
278 / 652
-
IMSI-to-HSS routing rule of type "all" with MSIN ranges: The mapping type is
provisioned as "all". The IMSI value may be divided into multiple ranges
exclusively indicated by pairs of minimum IMSI MSIN values and maximum IMSI
MSIN values. For each IMSI value range, an HSS group including up to eight
HSS/DRA entities/servers may be provisioned
Parameter
Mapping Type
SAM Table Name
IMSI to HSS Routing
OSS ID
ltemme.MMEImsiToHssAbs.mappingType
Range & Unit
Choice List
Odd, Even, Range
Impact of Change
No service impact.
Value
Operator Dependent; default = Even
Rule: IMSI to HSS routing rule

For home PLMN, shared network PLMN and other PLMN, each should at least
have an entry provisioned in the IMSI to HSS routing table with Mapping
Type=ALL, and MinMSIN and MaxMSIN.
Parameter
Minimum MSIN
SAM Table Name
IMSI to HSS Routing
OSS ID
ltemme.MMEImsiToHssAbs.minMSIN
Range & Unit
Integer
8 or 9 digits (if the number of MNC digits is 3)
Impact of Change
No service impact.
Value
Parameter
Maximum MSIN
SAM Table Name
IMSI to HSS Routing
OSS ID
ltemme.MMEImsiToHssAbs.maxMSIN
Range & Unit
Integer
Issue 11.01
Impact of Change
No service impact.
Value
LTE/DCL/APP/031094
Nokia 2016
279 / 652
Parameter
Mapping identifier
SAM Table Name
IMSI to HSS Routing
OSS ID
ltemme.MMEImsiToHssAbs.mappingId
Integer
1-8192
Range & Unit
Impact of Change
No service impact.
Value
Note : If DRA Destination Realm fields existed prior to software update from WM710 to
WM710 M1, they will be converted by creating new entries in Dra-destination-fqdn
table, and the new names replaced in Dra Destination Realm Name in corresponding
Remote End-Points.
Existing DRA Roaming Support (if used) feature behavior is preserved (unchanged) in
WM710 M1. However with this feature it will be possible for customers to evolve the
roamers behavior using new Dra Destination Realm Strings including available UE
variables and/or Network variables to match specific DRA requirements.
Parameter
DRA Destination Host Name
SAM Table Name
IMSI to HSS Routing
OSS ID
ltemme.MMEImsiToHssAbs.draDestRealmFQDNName
Range & Unit
Issue 11.01
string
Impact of Change
No service impact.
Value
Parameter
Subscriber Database type
SAM Table Name
IMSI to HSS Routing
OSS ID
ltemme. MMEImsiToHssAbs DraDestHostFQDNName
Range & Unit
string
Impact of Change
No service impact
Value
Operator Dependent;
LTE/DCL/APP/031094
Nokia 2016
280 / 652
Parameter
HSS 1 Id, HSS 2 Id, HSS 3 Id, HSS 4 Id,
SAM Table Name
Select Remote Endpoint IP 1 - IMSI to HSS Routing
OSS ID
Range & Unit
Integer
Configuration form
Impact of Change
No service impact.
Value
Operator Dependent; defaults: IP Id 1 = 1, IP Id 2 = 0

The Home PLMN and equivalent PLMN(s) must be configured prior to defining the
mapping between the IMSI range and the HSS.

The IP Identifier corresponding to the S6a interface must be provisioned in the
Remote End Point Configuration form prior to provisioning the HSS IP Addresses in
this IMSI to HSS Routing form.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
281 / 652
8.1.2.5.8 HSS / DRA LOAD BALANCING:
In WM8.0 and later releases, MME provides load balancing of the S6a, S6d, and
S6ad Diameter traffic to an HSS group using random spread. The HSS group
provides the infrastructure for load distribution for up to eight HSS in an HSS group.
Load balancing applies to both MME (S6a) and SGSN (S6d), and is supported over
the S6ad interface. A new mode for load-balance per IMSI routing rule attribute
priority-group is provided in WM8.0 and later releases :
Load balancing is enabled for an IMSI range or for all UEs in a PLMN, if no IMSI range
is specified. Load balancing is turned on / off at IMSI range level (IMSI to HSS routing
rules) or PLMN level.
For all types of IMSI to HSS selection rules listed above, the following rules apply:
Issue 11.01
When the load balancing option on an IMSI rule is set to none (default), the nary HSS/DRAs are treated in the n-th order priority. For example, the secondary
HSS/DRA (order number 2 HSS/DRA in the HSS group) is used for S6ad traffic
only when order number 1 HSS/DRA in HSS group is not available.
When load balance is set to all, HSS/DRAs with nonzero weight are treated as
one Primary HSS/DRA set with S6ad messages distributed in accordance with
relative weights (the greater weight receives more traffic; HSS/DRA with
identical weight get message traffic evenly distributed among them), a
Secondary HSS/DRA set is defined by the remaining HSS/DRA having a zero
(0) weight value. The secondary HSS/DRA set gets S6ad traffic evenly
distributed among its HSS/DRA members only when the primary group is
completely unavailable (all nonzero weighted HSS are unavailable).
When load balance is set to priority group, a set of HSS/DRA is defined in a

group with different weights. The set of HSS/DRA with the same highest weight
form the Primary group used in load balancing. The set of HSS/DRA with the
next common highest weight form the Secondary group used in load balancing.
The Secondary group is only used for call processing when the Primary group
is out of service. The last n-ary group is always the group with 0 weight (if
used).
LTE/DCL/APP/031094
Nokia 2016
282 / 652
Example:
HssGroup1 order
HSS Name
Load balancing Weight
selection
Hss1
60
Primary Group
Hss4
20
Secondary Group
Hss3
20
Secondary Group
Hss9
Tertiary group
Hss8
Tertiary group
Hss10
60
Primary Group
Parameter
Load Balance
SAM Table Name
IMSI to HSS Routing
OSS ID
ltemme. MMEImsiToHssAbs.loadBalance
Range & Unit
Impact of
Change
None, All, Priority Group
No service impact
Value
Operator Dependent; None.
Feature
m11320-01
A new table HSS Group is introduced to define a series of HSS (DRA) Remote EndPoint. Each group has a maximum of 8 entries defined in table. Hss names and their
associated load balancing weight are defined in the Hss Group table.
Parameter
HSS Group Profile Name
SAM Table Name
IMSI to HSS Routing
OSS ID
ltemme. MMEImsiToHssAbs.hssGrpPrflName
Range & Unit
String
1 - 31
Issue 11.01
Impact of Change
No service impact.
Value
Operator Dependent; HSS Name specified in the HSS

Group Profil List and associate to the IMSI to HSS routing
rules Remote End Point Configuration
Feature
m11320-01
LTE/DCL/APP/031094
Nokia 2016
283 / 652
Parameter
HSS Order in Group
SAM Table Name
HSS Group Profile
OSS ID
ltemme.hssOrderId
Range & Unit
Integer
1-8
Impact of Change
No service impact.
Value
Operator Dependent; defaults:
Feature
m11320-01
A weight factor from 0 through 100 can be applied to each HSS in the HSS group.
The zero weight factors is used to evenly and randomly distribute load among remaining
available HSSs (when all nonzero weighted HSS are unavailable).
Messages within the same procedure go to the same HSS or DRA.
Parameter
Weight for Load Balancing
SAM Table Name
HSS Group Profile
OSS ID
ltemme. lbWeight
Range & Unit
Integer
0 - 100
Impact of Change
No service impact.
Value
Operator Dependent; defaults:
Feature
m11320-01
Parameter
HSS Group Profile Name
SAM Table Name
HSS Group Profile
OSS ID
ltemme. MMEHssGrpPrf
Range & Unit
String
1 - 31
Issue 11.01
Impact of Change
No service impact.
Value
Operator Dependent; HSS Name specified in the Remote

End Point Configuration
Feature
m11320-01
LTE/DCL/APP/031094
Nokia 2016
284 / 652
8.1.2.5.8.1 HSS USER PROFILE MANAGEMENT
The Nokia MME accesses the HSS during various procedures in order to obtain or
update subscriber information. For example, at
user registration the HSS is interrogated by the Nokia MME as the user
attempts to register to the network in order to check the user subscription rights.
location update as the UE changes location areas, the HSS is kept updated
and maintains a reference of the last known area.
HSS User profile management procedures include:

Authentication HSS authenticates UE upon request of
Authentication
Nokia MME.
Nokia MME informs HSS about identity of Nokia MME
serving the user; Nokia MME provides HSS with user data;
Update location
HSS may optionally update Nokia MME with subscriber

data.
If the HSS has received UE reachability status, the HSS
sends a UE-REACHABILITY-NOTIFICATION-REQUEST
UE reachability
(URRP-MME) to the MME. The MME then reports to the
notification request
HSS information regarding changes in UE reachability (for

example, when the next NAS activity with that UE is
detected).
Nokia MME informs HSS of a UE-Activity-Notification if
UE activity notification
URRP-MME for that UE is configured to report once the UE

is reachable.
Nokia MME notifies HSS if PGW for an APN has been
Notification
removed or changed.
Insert subscriber data
changed.
Nokia MME requests to delete a subscriber record from
Purge function
HSS.
Reset
Nokia MME restores impacted subscriber records to HSS.
Delete Subscriber data
HSS notifies Nokia MME when UE data has been removed
Cancel location
Issue 11.01
HSS updates Nokia MME when UE data record has
HSS notifies Nokia MME when a UE withdraws a

subscription
LTE/DCL/APP/031094
Nokia 2016
285 / 652
If the global parameter UE Reachability T-ADS in Supported Features AVP is set to
True (default), MME indicates in the Authentication-Information-Request (AIR) or
Update Location Request (ULR) commands in the Feature-List AVP, by setting bits 26
and 27 that it supports UE-reachability-Notification and T-ADS (Terminating Access
Domain Selection Data Retrieval) of the Feature-List Flags.
Parameter
UE Reach T-ADS in Supported Features AVP
SAM Table Name
Global Parameters
gParmName
String
UE Reach T-ADS in Supported Features AVP
OSS ID
Range & Unit
gParmValue
Boolean
Yes/No
Impact of Change
No service impact.
Value
Operator Dependent; default = Yes
Feature
m10099-14
This feature is applicable for the ULR/ULA and IDR/IDA command pairs, over S6a and
S6d. If the MME or SGSN indicates in the ULR command that it does not support the
retrieval of T-ADS data via IDR/IDA commands, the HSS shall not set the "T-ADS Data
Request.
User profiles are partitioned in memory on the Nokia MME in a UE context data
structure, which supports tables for:
Static data retrieved from the HSS during the Attach procedure (includes
authentication, subscription, and APN data).
Dynamic state information related to the UE and the current UE context (includes
UE session and bearer data).
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
286 / 652
Figure 8-5: Example of UE Context Data
The data shown in the figure above is part of a data dump of basic UE context data
using the ueadmin_cli command. (Commands are covered in [R35].)
The UE context data structure has one tuple per UE, and includes all static data
retrieved from the HSS (S6a) interface at Attachment, as well as all subsequent
dynamic state information related to that UE and the current UE context.
The UE context data is a distributed data structure.
The UE context data record retrieved from the HSS is populated during the Attach
procedure. The Nokia MME keeps the UE subscriber data, unless it is purged or the
user roams out of the Nokia MME area.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
287 / 652
8.1.2.5.8.2 HSS RETRY
In order to mitigate UE-specific failures, the MME supports a service provider
provisioned option to perform HSS retry on an alternate link during the following MMEHSS sub-procedures:
Authentication (utilizing the Authentication-Information-Request (AIR) /

Authentication-Information-Acknowledge (AIA) commands)
Update Location (utilizing the Update-Location-Request (ULR) / Update-LocationAcknowledge (ULA) commands)
Notify-Request (NOR) command)
Purge-UE-Request (PUR) command).
The Global parameter "S6a Retry Different HSS" can be disabled [default], or can be
enabled.
When the functionality is enabled:
Any new Authentication, Update Location, Notify request (NOR), Purge-UERequest procedures executed without the history of HSS would always go to the
primary HSS, which is the first one provisioned in Home PLMN table.
Upon AIA, ULA timeout, NOA or PUA timeout or one of the three following
diameter errors, a different HSS would be retried and selected if retry succeeded
:
DIAMETER_TOO_BUSY
DIAMETER_OUT_OF_SPACE
DIAMETER_UNABLE_TO_DELIVER
If the selected HSS is a secondary HSS, it would stay throughout the life of the
UE. However, if the primary HSS would become available, the current
implementation reverts back to the primary HSS.
Only one retry will be attempted. If the retry fails, the procedure will fail, and the
primary HSS will be selected for the next procedure.
When the functionality is disabled, any HSS failure will fail the procedure:
Even if multiple HSSs are defined, only the first HSS available (S6a link enabled)
will be selected.
If a timeout occurs or the connection goes down, then no retry is attempted

(resulting in failure of the overall procedure).
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
288 / 652
Parameter
S6a Retry Different HSS
SAM Table Name
Global Parameters
OSS ID
gParmName
String
S6a_Retry_Different_HSS
Range & Unit
gParmValue
Boolean
Yes or No
Impact of Change
No service impact.
Value
Operator Dependent; default = No (disabled)
8.1.2.5.8.3 HSS SIGNALING LOAD REDUCTION

To reduce the HSS signaling load (especially duing attach storms events), the following
changes are introduced:
HSS ULR reduction: When the HSS ULR Reduction global parameter is set to
True, MME does not send S6a ULR request to HSS if the following conditions
are true:
when UE attaches with a valid local GUTI that the MME is successfully able
to identify without using the NAS Identity Request procedure
the UE has subscription data
the PLMN for the TAI provided by the eNodeB matches the GUTI in shared
network scenario.
Parameter
HSS ULR Reduction
SAM Table Name
Global Parameters
OSS ID
Range & Unit
gParmName
String
HSS_ULR_Reduction
gParmValue
Boolean
Yes or No
Issue 11.01
Impact of Change
No service impact.
Value
HSS NOR reduction : When the HSS NOR reduction global parameter is set
to true, MME does not send PGW-assignment Notify-Request (NOR) to the
HSS when the PGW that MME selects is identical to the one received from
HSS in the S6a Update Location Answer and Insert Subscriber Data request
message.
LTE/DCL/APP/031094
Nokia 2016
289 / 652
Parameter
HSS NOR Reduction
SAM Table Name
Global Parameters
OSS ID
Range & Unit
gParmName
String
HSS_NOR_Reduction
gParmValue
Boolean
Yes or No
Impact of Change
No service impact.
Value
Both suppression policies are controlled by the setting of the two independent HSS
Signaling Load reduction parameters.
To avoid HSS/DRA overload, the MME can be provisioned to throttle S6a Update
Location Request messages during to UE restoration.
When UE restoration using the SRS occurs due to an MME restart or due to an eNB
losing S1-MME link to MME, the MME sends the ULR message to the HSS to update
location and also to obtain complete UE subscription data. These large numbers of
ULR can cause overload conditions at the HSS/DRA. In order to avoid HSS/DRA
overload, the MME monitors the rate of ULR messages due to UE restoration. If the rate
of these ULR messages exceeds a provisioned threshold (Global Parameter
SRS_ULR_DEFER_THRESHOLD), the MME delays the sending of the ULRs. The
delayed ULRs are sent on a subsequent mobility management procedure if the rate of
ULR due to restoration is below the threshold
Throttling of Recovery ULRs during SRS restoration can be enabled (disabled by
default) via the provisioning of the ULR rate threshold.
The provisioning of the feature can only be done by NOKIA support personnel.
Parameter
SRS ULR DEFER THRESHOLD
SAM Table Name
Global Parameters
OSS ID
To be updated
Range & Unit
Issue 11.01
Impact of Change
No service impact.
Value
Feature
m10538-18
LTE/DCL/APP/031094
Nokia 2016
290 / 652
8.1.2.5.8.4 HSS HANDLING OF DISCONNECT PEER
REQUEST AND ANSWER (DPR /DPA)
Diameter protocol interactions with an HSS DPR/DPA messages according to RFC
3588 are as follows:
When the HSS sends a Disconnect Peer Request (DPR) to the MME, the MME
answers the HSS with diameter Disconnect-Peer-Answer (DPA) message, and will failover to a another (secondary) HSS. The MME then expects the HSS to close the
connection.
After a grace period of the DPRMessageTimer (default 6 seconds), the MME attempts
to reconnect with this HSS. Following a ~25 second interval, the MME re-initiates the
connection.
Prior to WM7.0, the MME did not respond to an HSS initiated DPR, expecting the HSS
to time out while waiting for a DPA to close the connection, and if the HSS did not close
the connection, the MME closed the connection after the watchdog DWR maximum
retry failures was reached. Then, the MME re-initiated the connection as shown in
Figure 8-5 : Previous MME DPR handling in LM4.0.2
Figure 8-6 : Previous MME DPR handling in LM4.0.2
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
291 / 652
If the MME detects that the HSS link is being blocked , a DPR message is sent to the
HSS before and waits the duration of Diameter Profile timer, DPRMessageTimer
(default 6 seconds), for the HSS to respond with a DPA.
When the DPA is received or times out, the MME gracefully closes the connection and
completes the link 'blocking' operation to this HSS.
Figure 8-7: MME Handling of HSS originated DPR

Prior to WMM7.0, the MME did not initiate DPR (when blocking an HSS link) and
immediately closed the connection:
Upon receipt of DPR from HSS MME responds with DPA, however MME does not close
the SCTP connection when responding with DPA since DPA needs to reach HSS first
and then it is up to HSS that initiated DPR to close the connection.
MME initiated DPR can be applied to provisioning change or link state change:
When an HSS link is blocked, prior to un-provisioning, the corresponding Diameter
connection is put in a Blocked/Not Used mode, MME sends DPR (with a provisionable
Disconnect Cause of default value of DO_NOT_WANT_TO_TALK_TO_YOU), wait for
DPA (or timeout) before closing the connection.
To reduce detection time in case of a loss of Primary HSS via DWR/DWA (watchdog)
monitoring, the default Diameter timers can be adjusted in 100ms steps to more closely
match the timer settings of a peer DRA or HSS.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
292 / 652
Parameter
DPR Message Timer
SAM Table Name
Diameter Profile
ltemme. DiamProfileID. DPRMsgTimer
OSS ID
Range & Unit
Integer
Range : 100 30000 ms
Impact of Change
No service impact.
Value
Default = 6000 msec
Feature
m11301-01
Figure 8-8: MME Originating DPR to HSS
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
293 / 652
8.1.2.5.8.5 SUPPORT FOR IMS VOICE OVER PS SESSIONS
TO THE HSS)
In the Update Location Request (ULR) message, the optional AVP, HomogeneousSupport-of-IMS-Voice-Over-PS-Sessions indicates to the HSS whether or not "IMS
Voice over PS Sessions" is supported homogeneously in all TAs or RAs in the serving
PLMN.
The
Homogeneous-Support-of-IMS-Voice-Over-PS-Sessions
AVP
can
take
the
following values:
NOT_SUPPORTED (0): this value indicates that "IMS Voice over PS Sessions"
is not supported, homogeneously, in any of the TAs or RAs associated to the
serving node.
SUPPORTED (1): this value indicates that "IMS Voice over PS Sessions" is
supported, homogeneously, in all of the TAs or RAs associated to the serving
node.
If this AVP is not present in the command, it indicates that there is no homogeneous
support of IMS Voice over PS Sessions on all the TA/RAs of the serving node, or that
the homogeneity of this support is unknown to the serving node.
MME checks the following IMS voice enabled provisioning to determine setting of the
Homogeneous-Support-of-IMS-Voice-Over-PS-Sessions AVP:
MME Tracking Area,
IMS Voice setting in Service Profile provisioned at the PLMN level and
IMS Voice setting in Service Profile provisioned at the IMSI series and TA level:
A UE may belong to multiple IMSI series and TA level provisioning.

To determine setting of the Homogeneous-Support-Of-IMS-Voice-Over-PS-Sessions,
MME has to examine all IMSI series and TA level provisioning.
Table 5& Table 6 show how the AVP is set based on the provisioning.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
294 / 652
Configuration 1: UE IMSI is not in any of the provisioned IMSI series
In this case, MME looks the IMS voice provisioning of the TAI and IMS Voice
provisioning in the Service Profile assigned at the PLMN level.
MME TAI : IMS supported in all
IMS Voice Support setting
In ULR and IDA
TAIs (Voice setting of all TAIs )
provisioned at UE PLMN
messages
True Supported in all TAI
and Served PLMN Service
Homogeneous-
False - Not supported in any TAI
Agreement Profile - IMS
Support-of-IMS-Voice-
Mixed Partial Support
Supported
Over-PS-Sessions
AVP IE :
False
False
(0) NOT SUPPORTED
False
True
(0) NOT SUPPORTED
True
True
(1) SUPPORTED
True
False
(0) NOT SUPPORTED
Mixed
True
AVP is not sent
Mixed
False
(0) NOT SUPPORTED
Table 7 setting of the Homogeneous-Support-of-IMS-Voice-Over-PSSessions AVP when UE IMSI is not in any of the provisioned IMSI series
Configurations 2: UE IMSI is in one or more IMSI series and each IMSI series also has
TAI provisioning.
The TAI provisioned are a subset or no TAIs specified i.e. the provisioning applies to all
TAs of the MME. If a UE in multiple IMSI series that have different TAC provisioning
then MME has to look at all the provisioned data to determine the setting of the AVP.
The IMSI series level checks will result in the following values of IMS support:
Supported in some TAIs : IMSI series and TAC level provisioning indicate that the IMS
voice is enabled for a subset of TAC served by the MME. There is no IMSI series and
TAC level provisioning for which IMS voice is disabled.
Supported in all TAIs : IMSI series and TAC level provisioning indicates that IMS voice
is enabled for an IMSI series for all the TAC served by the MME.
Not supported in some TAI : IMSI series and TAC level provisioning indicate that the
IMS voice is disabled for a subset of TAC served by the MME. There is no IMSI series
and TAC level provisioning for which IMS voice is enabled.
Not support in all TAIs : IMSI series and TAC level provisioning indicates that IMS voice
is disabled for an IMSI series for all the TAC served by the MME.
Supported in some TAIs and not supported in other TAI (Mixed) : IMSI series and TAC
level provisioning indicate that the IMS voice is enabled for a subset of TAC served by
the MME and disabled for another subset of TACs.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
295 / 652
IMS Voice Support
IMS Voice Support
setting provisioned
result of IMS Voice

Support Setting in the
Service Profile
IMS Voice Setting of

all MME TAIs
Provisioned at multiple
at UE PLMN and
Served PLMN
Service Agreement
Profile - IMS
IMSI series and TA
Supported
level
Any value
Supported in some TAI
In ULR and IDA

messages
HomogeneousSupport-of-IMS-VoiceOver-PS-Sessions
AVP IE :
No
Any Value
(0) NOT SUPPORTED
Yes
No
AVP is not sent
Yes
Yes
(1) SUPPORTED
Mixed
Any value
AVP is not included
Yes
N/A
(1) SUPPORTED
Mixed
N/A
AVP is not included
Yes or Mixed
No
(0) NOT SUPPORTED
Yes or Mixed
Yes
AVP is not sent
Yes or Mixed
N/A
(0) NOT SUPPORTED
Yes or Mixed
Any value
AVP is not sent
Supported in all TAI
Not supported in some

TAI
Not Supported in all

TA
Supported in some TAI
and not Supported in
other TAI
Table 8 setting of the Homogeneous-Support-of-IMS-Voice-Over-PSSessions AVP when UE IMSI is in one or more IMSI series and each IMSI series also
has TAI provisioning.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
296 / 652
8.1.2.5.8.6 NUMBER OF AUTHENTICATION VECTORS
The MME exchanges the number of authentication vectors with the HSS as part of the
Authentication-Information-Request/Answer (AIR/AIA) messages.
When a UE registers with the MME for the first time via IMSI, GUTI, or P-TMSI attach or
the UE initiates an inter RAU/TAU to the 9471 WMM, if the UEs subscriber
authentication information is stored in the HSS, the MME retrieved both 2G/3G
authentication vectors and 4G authentication vectors from the HSS even if only one of
them is used during the current procedure. (The other one is for future usage.)
When running MME-SGSN combo configuration 2G/3G/4G authentication vectors are
retrieved during initial attach or TAU or RAU. This eliminates the need for the MME or
the SGSN to send separate authentication requests and hence reduce signalling to the
HSS when the UE subsequently moves within the combo. As an example, in 3G initial
attach procedure, the AIA message contains 1 UTRAN Vector and 2 eUTRAN vectors.
Combined MME-SGSN will not send the AIR Requested-eUTRAN-Authentication-Info
AVPs in the 4G attach procedure because 4G authentication vector is available.(AV
value in the S6a InterfaceProfile table greater than 1)
When a UE does a 2G/3G procedure that needs 2G/3G authentication vectors from
HSS,and the number of 4G authentication vectors in VLR is less than the provisioned
value, the WMM request HSS for both 2G/3G authentication vectors and 4G
authentication vectors.
Starting in WMM 7.1 and later releases, MME no longer asks for one more
authentication vector than provisioned value. The authentication vector (AV) requested
value range is 1 to 5 with default value set to 3. Number of authentication vectors that
WMM asks HSS is equal or less than provisioned value. For MME, number of un-used
authentication vectors in VLR is equal or less than provisioned value.In a combined
WMM configuration, combo-indication=yes in the S6ad interface/S6ad termination
using SAM. Other interface types cannot be provisioned with a Number of
Authentication Vectors value.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
297 / 652
Parameter
Number of Authentication Vectors
SAM Table Name
Interface Profile
OSS ID
ltemme.InterfaceProfileAbs.avRequested
Range & Unit
Integer
[1..5]
Impact of Change
No service impact.
Value
Operator Dependent; default = 1, when interface type = S6a
Feature
m11317-01
The provisioned number of authentication vectors and immediate response preferred

are used for both the MME and SGSN. MME always requests the HSS for the exact
number of provisioned authentication vectors. Previously, the MME was able to request
for one more authentication vector than the provisioned value. In this release, the
default (and recommended) number of authentication vectors that the 9471 WMM
requests in the AIR message to the HSS is 3.
MME can be provisioned with immediate response preferred.
A new global parameter Support Immediate Response Preferred AVP with the
following possible values:
o
Yes the 9471 WMM always populates Immediate-Response-Preferred AVP
No the 9471 WMM never populates Immediate-Response-Preferred AVP.

This is the default.
Dynamic the 9471 WMM populates Immediate-Response-Preferred AVP

when authentication vector is needed for current procedure and synchronization
failure.
Parameter
SAM Table Name
Support Immediate Response Preferred AVP

Global parameters
OSS ID
Yes - WMM always populates Immediate-Response-Preffered
AVP in AIR
Range & Unit
No - WMM never populates this AVP

Dynamic - WMM populates this AVP when authencation
vector is needed for current procedure.
Issue 11.01
Impact of Change
No service impact.
Value
Operator Dependent; default = No, when interface type = S6a
Feature
m11317-01
LTE/DCL/APP/031094
Nokia 2016
298 / 652
8.1.2.5.8.7 PROXY CALL SESSION CONTROL FUNCTION (PCSCF) RESTORATION FUNCTION
P-CSCF restoration procedures are described in 3GPP TS 23.380
A UE must register with a P-CSCF in order to make outbound IMS calls (UE originated
call) or to receive inbound IMS calls (UE terminating call). If the P-CSCF fails (either the
node fails completely or it loses the UEs registration info), the UE is not reachable for
terminating calls until it registers again with a working P-CSCF.
Without the functionality for P-CSCF recovery, the UE is reachable for terminating calls
only when:
the UEs registration timer expires and it re-registers or
the UE attempts to make an originating call.
Depending on the operators registration timer, it could take several hours.

MME provides indication of the support of the Proxy Call Session Control Restoration
(P-CSCF) as part of the supported features AVP in the Update Location Request
message to the HSS.
If the MME does not support P-CSCF recovery, the HSS does not send the related
information to the MME within the Insert-Subscription-Data-Request (IDR)
P-CSCF Restoration Required indication bit shall be set to 1 to indicate P-CSCF
restoration needed for the user and in all other cases the bit shall be set to 0
P-CSCF recovery occurs for P-CSSF failure scenarios while UE is in idle state and
having PDN. The S-CSCF detects failure based on timeout and initiates P-CSCF failure
to HSS which will initiate IDR procedure to MME by sending an introduced restoration
info AVP to MME. MME as a result will initiate Modify Bearer Request with Private
Extension IE set to P-CSCF Restoration Required to SGW.
Insert-Subscribption-Data-Request (IDR) sent from HSS to MME is a proprietary IDR.
(Bit 31), when set, indicates that the P-CSCF the subscriber is bound to has failed and
the MME trigger P-CSCF Registration procedures in order to force the UE to register
via a new P-CSCF.
Private IE P-CSCF Restoration required is encoded as follows.
Octets
1
2 to 3
4
5 to 6
7
8
9
Issue 11.01
Bits
6
5
4
3
2
Type = 255 (decimal)
Length = n
Spare
Instance
12951
3
Spare
P-CSCF Restoration Required - ENUM
7
LTE/DCL/APP/031094
Nokia 2016
299 / 652
8.1.2.5.8.8 SS BASED P-CSCF RECOVERY FOR 3GPP
ACCESS
In 3GPP release 9, PGW/GGSN monitors the health of a P-CSCF and informs all
affected UE in case of P-CSCF failure which can result in a signaling storm when a
large number of UEs are impacted. (current P-CSCF Recovery mode 1)
The HSS based P-CSCF restoration mechaninsm (3GPP TS 23.380 Release 12) is
invoked for terminating calls that are affected by a P-CSCF failure. (Only affects the
UEs that are receiving calls at the time of P-CSCF failure). The HSS based P-CSCF
restoration mechaninsm do not rely on the PGW to detect the P-CSCF failure itself but
makes usage of a path through HSS (PGW is informed of a P-CSCF failure indirectly by
the MME) and MME to request the release of the IMS PDN connection to the
corresponding UE. The HSS-based P-CSCF mechanism is optionally extended by
reusing part of the "Update PDP context/bearer at P-CSCF failure" mechanism that
avoids the need to deactivate and reactivate the IMS PDN connection. The call flow for
the HSS-based P-CSCF for 3GPP Access recovery mechanism is described in Figure
8-8 :
Failed
P-CSCF
MME/
SGSN
UE
New
P-CSCF
HSS
S-CSCF
1. SIP message
2. SIP message
3. SIP Error or lack of response
4. Cx SAR
(P-CSCF Rest ind)
5a. Cx SAA)
5b. S6a/S6d IDR/IDA (P-CSCF Restoration Indication)

Gr ISD (P-CSCF Restoration Indication)
6. SIP Response
PCO-based optional
extension is NOT supported
7. IMS PDN
release
If PCO-based
optional
extension is
supported
IMS PDN re-establishment

8. SIP Register
8. SIP Register
Register completion
Figure 8-9: HSS-based P-CSCF restoration
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
300 / 652
Legend:
Step
Description
The terminating S-CSCF receives a SIP message for a destination UE.
The S-CSCF forwards the SIP message to this called UEs terminating P-CSCF
S-CSCF detects P-CSCF failure for a terminating service.
4.
If UE is registered, S-CSCF unregisters UE by sending a Cx SAR to the HSS, including a PCSCF Restoration indication.
5a. 5b
HSS forward it to MME via IDR, if the serving MME supports HSS-based P-CSCF restoration.
S-CSCF sends a SIP response back to the HSS
Upon reception of the P-CSCF Restoration indication from the HSS, the MME from the received
IMSI identify if the MM context of the UE exists and if the UE has an IMS PDN connection
context. If either the MM context or the IMS PDN connection context does not exist, the
MME/SGSN shall discard the P-CSCF Restoration indication without further processing;
otherwise the MME/SGSN shall continue as below.
The MME checks the UE state:
- If the UE is in ECM-IDLE state, the MME page the UE.
-If the UE is initially in ECM-CONNECTED state or when it gets a response from
the UE after paging:
- If ISR is active, the MME sends a message, via the S3 interface, to stop
paging the UE at the other ISR-associated node; and
- The MME executes the optional Protocol Configuration Option (PCO) based
optional extension to this mechanism as,
it proceeds as below :
NOTE 5: The support of this feature by the serving SGW/PGW is determined
based on the local configuration at the MME.
-if this is not the last PDN connection of the UE, MME releases the UEs IMS
PDN connection towards the UE by initiating a PDN disconnection procedure
with the NAS cause "reactivation requested".
If this is the last PDN connection of the UE, the MME initiates a detach
procedure with the NAS cause code "reactivation requested". Additionally, the
MME/SGSN also releases the same PDN connection towards the SGW/PGW
by sending Delete Session message (not shown in the Figure 8-8: HSS-based
P-CSCF restorationFigure 8-8).
IMS PDN connection re-established and a new SIP Register.

If the global parameter PCSCF Recovery is enabled (either set to mode1 or mode 2) ,
the MME indicates the support of this feature to the HSS in S6a/S6d ULR (Private IE PCSCF Restoration required bit (List 2 Bit 16);
If P-CSCF has failed when the user is in Idle/Connected Mode after IMS registration, SCSCF detects failure based on timeout and initiates P-CSCF failure to HSS which will
initiate IDR procedure to MME by sending 3GPP Release 12 introduced AVP to MME.
(Bit 8 in IDR Flags AVP is used for P-CSCF Recovery). Upon receiving IDR with Bit 8 in
IDR Flags AVP, MME detachs IMS PDN.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
301 / 652
The global parameter PCSCF Recovery determines the mode of P-CSCF recovery:
If the global parameter PCSCF Recovery is set to none (the default), the MME
ignores the bit in IDR flags AVP for P-CSCF recovery and the MME continues with the
ongoing procedure.
If the global parameter PCSCF Recovery is set to mode 1, the HSS uses bit 31 in
IDR-Flags for P-CSCF recovery. The MME will honor the request only if the UE is in
IDLE mode. The MME informs the SGW by sending a proprietary IE in Modify Bearer
Request.
If the global parameter PCSCF Recovery is set to mode 2, the HSS uses bit 8 in the
IDR-Flags AVP for P-CSC F recovery. The MME will honor the request whether or not
the UE is in IDLE or CONNECTED mode. If the UE is idle, the MME pages the UE.
Once the UE is in connected state,the MME will request the UE to deactivate and reactivate the IMS PDN connection.
Parameter
PCSCF Recovery
SAM Table Name
Global parameters
OSS ID
Range & Unit
None
Mode1
Mode2
Impact of Change
No service impact.
Value
Operator Dependent; default = None
Feature
m11002-01
The PCSCF Recovery introduces a new table Match APN List that provides a list of
configure IMS alias selection that applies and covers ims prefix, ims suffix, ims
anywhere and ims match in an APN NI.
The MME determines if an APN is IMS related by looking for QCI=5. If IMS-alias is
provisioned and if QCI =5 then it is considered IMS APN, however if IMS-alias is not
provisioned and QCI entries matches to value 5 then it is considered IMS APN.
If IMS alias is provisioned and if QCI =5 then it is considered IMS APN;
If IMS alias is not provisioned and QCI matches to value 5 then it is considered IMS
APN;
Operator is allowed to define "ims" alias with their own
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
302 / 652
8.1.2.5.8.9 S6A FAULT HANDLING ENHANCEMENTS
Prior to WM8.0.0, when there are no Enabled S6a links, the MME relative capacity is
unchanged at the eNBs and a fraction of IMSI attach requests controlled by that relative
capacity value is sent to the MME where the attempts will fail. Since a relative capacity
of zero will cause the eNBs to redirect all traffic, if all MMEs cannot access the HSS
Starting in WM 8.0.0 and later releases, the following two fault handling enhancements
are provided to S6ad depending of the setting of the global parameters:
S6a HSS Update eNB Capacity When the last Enabled S6a link for the home PLMN
transitions from Enabled to Disabled, (and when this condition persists for more than 30
seconds) an MME Configuration Update message is sent to the eNBs with the MME
relative capacity set to one. Likewise when there are no S6a links in the Enabled state
and any one transitions to Enabled, the MME will send MME Configuration Update
messages to the eNBs with the MME relatvie capacity set to its normal value.
S6a Fault Continue Procedure with AKA Optional is set to Yes (enabled) a new
behaviour allows some UE procedure to continue without using/requiring authentication
vectors: When all of the S6a links relevant for a single UE are down and an
authentication challenge is about to be executed by the MME solely because of the
PLMN security settings (implying that the AKA is optional), then skip the AKA and
continue the procedure. Any other call processing activity that requires a transaction on
S6a will still cause procedure failures as they do today. Note that only the S6a links
used to support the specific UE are relevant for this capability.
The home PLMN s6ad links are defined as links that are associated with hss-mappingrules that are keyed by the home network MCC and MNC. There may be one rule or
many mapping rules. The set of s6ad links that are defined in this feature are the ones
associated with any rule keyed by the home MCC and MNC.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
303 / 652
S6a fault handling
global parameters
settings
Scenario
Action taken
All Home PLMN HSS are

unavailable (the last Home
PLMN HSS link transitions
A MME Configuration
from enabled to disabled)

S6a HSS Update eNB
Capacity global
parameter is set to
HomeHSS
This setting enables the
detection of link
availability and/or
degradation of all the
Home PLMN HSS
resulting in action to
update eNB capacity
parameters.
Update message is sent to
and while this condition
eNBs with the MME relative
persists and all Home PLMN
capacity set to one (1).
HSS link remain out of

service during a wait period
(~30 seconds)
No S6ad links were
previously in service, after a
first Home PLMN HSS link is
A MME Configuration
restored into service (and it
Update message is sent to
remains in service), and
the eNBs withthe MME
there is at least one Home
relative capacity restored to
PLMN HSS link in service
its normal value.
during a waiting period

(~ 30 45 seconds).
Skip the AKA and continue
S6a Fault Continue
Procedure with AKA
optional global parameter
is set to YES
This setting allows some
UE procedures to
continue without requiring
authentication vectors
When all of the S6a links
the procedure. Any other
relevant for a single UE are
call processing activity that
down and an authentication
requires a transaction on
challenge is about to be
S6a will still cause
executed by the MME solely
procedure failures. Note
because of the PLMN
that only the S6a links used
security settings (implying
to support the specific UE
that the AKA is optional)
are relevant for this

capability.
Note: In addition the status of links on S6ad is impacted by the configuration of s6adendpoints and IMSI routing rules referring to these end-points (via an hss-group).
When an HSS/DRA s6ad-endpoint is in shutdown state, it is not longer available for
IMSI routing in any of the referring rules.
When an IMSI rule is shutdown references from these rules to Home PLMN HSS for
example are discounted. It is possible to have no Home PLMN HSS left in use in any
rule without locking/blocking all them if all the referring rules (or s6ad-endpoint) are in
shutdown state.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
304 / 652
8.1.2.5.9 SGSN DISCOVERY USING DNS QUERIES
To avoid provisioning SGSN IP addresses in the MME, the MME uses the DNS service
to identify an SGSN in the Release 8 3G or 2G Network when handover between the
networks occurs. If the DNS query succeeds, the MME determines from the NAPTR
record the address of the SGSN S3 interface, if one is available, and creates an S3
Interface managed object (MO) to represent the new S3 interface (if one does not
exist).
If the NAPTR record does not contain an SGSN S3 IP address, the MME software
searches the NAPTR record for the address of the SGSN Gn interface. If one is
available, the MME creates a Gn Interface MO to represent the new Gn interface (if one
does not exist).
SGSN selection failures include scenarios such as no NAPTR records for S3/Gn
services, no active S3/Gn interfaces, or S3/Gn services having no matching A/AAAA
record. The MME collects SGSN selection failures for every two minutes and reports a
minor alarm (SGSN selection failure alarm) at the end of the two-minute interval.
Detailed information about the SGSN selection failures is available in a customerviewable log file. The alarm must be manually cleared.
8.1.2.6
Network Element Selection Mode 2
Note: This section describes the differences between Mode 1 and Mode 2. That is, it
describes how Mode 2 works differently. All other areas of network selection described
in Section 8.1.2.5 apply unless stated otherwise.
The primary distinction between Mode 1 and Mode 2 is in DNS selection for the
SGW/PGW.
When the selection method is set to 'GW Selection Mode 1', SGW discovery and
selection using Domain Name System (DNS) query procedures are supported as
defined in 3GPP TS 23.303 (v8.2.0) and used during these mobility procedures:
TAU and HO (Inter-eNodeB X2-based and Intra-LTE S1-based handovers) for

non-roaming and roamer local-breakout scenarios.With the home-routed
scenario, topological matching between PGW/SGW node names does not apply
because the PGW is in a different network.
UE initial Attach and pdnconnect
Subsequent PDN Connectivity Requests.
Gn and S3 Handover to the MME
The MME first selects an SGW with a TAI query using the S-NAPTR procedure. The
MME selects a SGW based on the Order and Preference parameters in the NAPTR
record. After the selection of SGW, MME selects PGW topologically close to the SGW
based on topon/topoff label. If there are multiple PGWs, then the MME uses the Order
and Preference value in selecting a PGW.
With 'GW Selection Mode 2', the concept of a combined PGW/GGSN node exists. A
PGW is considered a combined PGW/GGSN node if it supports both x-gn and x-s5/x-s8
protocols. The MME only considers PGWs returned from an APN NAPTR query that
supporst x-gn service type, unless there are no candidate PGW resources that support
x-gn. This limits the list of PGW resource that the MME considers for collocation and
topological matching with the SGW resources.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
305 / 652
When the selection method is set to 'GW Selection Mode 2', the MME selects the
SGW/PGW simultaneously, based on topological matching of each SGW returned from
the TAC NAPTR query and each PGW returned from PGW/APN NAPTR query,
irrespective of SGW and PGW Order and Preference values. The MME obtains a
SGW candidate list using S-NAPTR procedure. For a non-roamer UE or a roamer UE
with PGW in VPLMN, the MME uses the SGW candidate list to select a collocated SGW
or one that is geographically close to the selected PGW by matching FQDN labels of
PGW and SGW. This occurs only if the PGW FQDN has a topon label. The MME only
performs topological matching with SGW FQDNs with a topon label. Topological
matching is not required for a home routed traffic scenario (such as a PGW is in UEs
HPLMN). If there are multiple SGW/PGW pairs of equal geographical closeness (that is,
the same number of matching labels in node names), the MME uses the Order and
Preference values from the NAPTR response, along with Priority and Weight values
from associated SRV records, to select the preferred SGW/PGW pair.
When UE Subscriber data indicates Dynamic Allocation is enabled and a PGW FQDN
(Hostname and Realm) is provisioned in the MI6AgentInfo, the MME ignores the PGW
FQDN and issues a APN NAPTR query. During subsequent PDN Connectivity
Requests, the MME uses topological matching of the existing SGW node with the
candidate PGWs to choose a PGW that is geographically close to the SGW.
During GN and S3 Handover to the MME, the MME attempts to chose a new SGW that
is topologically near the existing PGW allocated to an active PDP session.
The MME performs DNS query to determine the service types supported by the
selected PGW. If the PGW is in VPLMN and if it does not support both service types xs5-gtp and x-gn, the MME rejects the IRAT TAU procedure with implicit detach.
If the PGW is in UEs selected network or in a remote network and if it does not support
service types x-s8-gtp and x-gp, the MME rejects the IRAT TAU procedure with
implicit detach.
If the PGW supports appropriate service types, the MME proceeds with the IRAT TAU.
Exceptions when 'order/preference' is used
Note that if multiple pairs have the same number of matching nodes, NAPTR
Order/Preference values are also considered.
If the NAPTR record is of type "s" and there are multiple SRV records for the NAPTR
resource, the SRV Priority/Weight values are also considered.
Exception when 'SGW DNS Discovery' global parameter disabled
When the 'SGW DNS Discovery' global parameter is disabled, the MME uses static
SGW provisioning data (not DNS) to resolve the SGW. In addition, if this parameter is
disabled, the MME will not give preference to a collocated GGSN/PGW resource,
regardless of the GW Selection Mode chosen.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
306 / 652
8.1.2.6.1 S11 MANAGED OBJECTS
The MME functionality for S11 MOs is the same for Mode 1 except for the following:
S11 MO creation is not based on the address resolved from the DNS query, but rather
the source address received in the CREATESESSIONRSP from the SGW. The MME
expects that SGW resources returned from a TAC NAPTR query to instead correspond
to the address of a load balancer. The lock operation for the ueadmin_cli command is
not support on S11 links when Mode 2 is enabled.
8.1.2.6.2 PGW/SGW SELECTION FOR UE ATTACH/PDN REQUEST

AFTER UE ATTACH
At the initial attach, MME obtains a SGW candidate list using the S-NAPTR procedure
(same as Mode 1). For a non-roamer UE or a roamer UE with PGW in VPLMN, the
MME uses the SGW candidate list to select a collocated SGW or one geographically
close to the selected PGW by matching the FQDN labels of PGW and SGW (only if
PGW FQDN has topon label). The MME only perform topological matching with SGW
FQDNs with the topon label. In addition for roamers, if the SGW and PGW are in
different networks, the MME is not required to select the SGW that is topologically close
to the PGW.
The MME selects a topologically closer PGW/SGW using a topological matching
method. TS 29.303 defines a topological close node. The two topologically closest
nodes are those with the longest matching suffix in their respective canonical node
names and collocated SGW/PGWs that have the same canonical node name. Two
pairs of PGW and SGW are defined to have the same topological closeness if the
number of matched labels is the same in both the pairs.
Topological matching is not required for the home routed traffic scenario (that is, when
the PGW is in UEs HPLMN).
For a homer and local break out roamer, the MME selects an SGW that supports x-s5gtp service irrespective of SGW support for x-s8-gtp. This method ensures selection of
an SGW that is geographically closer to the PGW supporting IMS APN (assuming that
IMS APN is the default APN and is allowed in serving network). However, if there are
multiple SGWs with equal topological distance to the PGW for a local breakout roamer,
the MME prefers the SGW that supports x-s5-gtp and x-s8-gtp.
The MME prefers an SGW that supports x-s5-gtp and x-s8-gtp service for home-routed
roamer UEs and roamer UEs with static PGW IP address assignment (without PGW
FQDN). In scenarios where the TAC NAPTR response contains no SGWs that support
x-s5-gtp, the MME selects an SGW that supports only x-s8-gtp service.
The MME rejects the procedure if MME fails to select a SGW as specified.
If there are multiple pairs with the same topological closeness, only then does the MME
use SGW NAPTR Order and Preference values along with SRV Priority and Wright
values for NAPTR s records for selecting a PGW and SGW pair.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
307 / 652
The following rules apply:
If the PGW/SGW pairs reference the same SGW, use PGW NAPTR
Order/Preference fields and PGW SRV Priority/Weight values for "s" NAPTR
records to allocate sessions.
If the PGW/SGW pairs reference different SGWs, use the SGW

Order/Preference fields and SGW SRV Priority/Weight values for "s" NAPTR
records to allocate sessions.
If all candidates have the same Order/Priority values, assign new sessions in
proportion to the Preference orWeight values.
For any subsequent PDN Connection Requests, MME selects a PGW topologically
close to the selected SGW in the initial attach procedure. The MME always selects a
topologically close PGW and SGW pair even if there are other pairs with PGW and/OR
SGW with lower order value.
8.1.2.6.3 SGW SELECTION FOR INTRA-LTE

The following applies when:
The MME selects an SGW if there is SGW relocation for intra LTE mobility with
or without MME (TAU, X2 HO and S1 HO) for both roamers and non-roamers.
The MME selects an SGW if there is SGW relocation for inter RAT mobility (TAU
and HO) where the old node is S4-SGSN for both roamers and non-roamers.
If the old SGW is in MMEs home network, and if any of the PGW in the existing bearer
context are in MME home network, then the MME uses the SGW FQDN to find a
topologically closer PGW in the EPS bearer contexts. The MME then uses that PGW's
FQDN for the new SGW selection based on the topology.
For a roaming UE in the MME network, or for a UE that is a non-roamer but has at least
one active PDN connection to an APN in another network, the MME selects an SGW
supporting both x-s5 and x-s8. Otherwise, the MME selects an SGW supporting x-s5.
The MME rejects the procedure if the MME fails to select a SGW.
8.1.2.6.4 PGW RESELECTION IF NO RESPONSE FROM THE SGW

When the MME receives no response from the SGW even after retransmissions if there
is no response from S11 Create Session Request message (i.e. MME failed to get a
response SGW/PGW after N3 attempts), before the MME times out (6 seconds), the
MME treats it as an SGW failure. If the global parameter Force PGW Reselection on
CS Request Timeout is enabled, the MME handles the "no response from SGW"
scenario as a possible PGW failure and follows the PGW reselection logic identical to
the case where it would have received a CSR with failure cause code 100 (PGW not
responding). This feature applies to PGW selection for both attach request and a
subsequent UE PDN connectivity request.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
308 / 652
Parameter
Force PGW Reselection on CS Request Timeout
SAM Table Name
Global parameters
OSS ID
Range & Unit
If set to Yes, MME shall select an alternate PGW

if there is no response to the Create Session Request. The
number of attempts to select PGW remains the same. The
feature only applies to GW selection mode 2.
The applicable procedures are Attach and subsequent PDN
Connectivity Request
Impact of Change
No service impact.
Value
Feature
m10112-06
8.1.2.6.5 ENHANCED SGW AND PGW SELECTION

A load balancing mechanism is applicable for the mode 2 selection of SGW and for both
mode 1 and mode 2 selection of PGW. The mode 2 selection is specifically developed
to support a load balancer in front of SGW and PGWs.
When MME uses DNS query for the SGW selection, MME receives IP addresses of the
load balancers. So, MME always sends the Create Session Request message to the
load balancer. The load balancer selects a SGW and forwards the Create Session
Request to the SGW. The SGW includes its IP address when it responds with the
Create Session Response to the MME. The MME start sending echo request to the IP
addresses obtained from the create session response to monitor S11 path to the SGW.
However, MME will not be able to monitor the load balancer as the load balancers do
not support GTP echo. So, enhancement of SGW and PGW selection provides the
MME capability to determine that the load balancer cannot be used for a configurable
period of time. MME determines that a load balancer cannot be used as follows:
MME provides provisioning of a create session request timeout threshold and a
duration. If the number of create session requests timeouts cross the provisioned SGW
Isolation fault threshold within the duration of the SGW isolation declaration timer then
MME will not include the SGW in the selection and send a major alarm to the SAM5620
The load balancer will not be considered for the SGW selection until the LTE SGW
isolation timer expires (or manually enabled to be selected). If there is only one SGW
remaining then MME does not suspend the SGW. MME sends a critical alarm to the
SAM and continue to use the SGW. MME provide a capability to manually suspend the
last remaining SGW. MME also generates a critical alarm if MME has not already
generated a critical alarm when the last SGW is manually suspended.
Enhanced SGW and PGW selection represents SGW load balancers for mode 2
selection as Maintenance Objects (MO).
When a GW is declared isolated / blacklisted then the node is suspended from selection
for a configurable period of time. MME provides CLI commands to manually suspend a
MO representing a SGW from selection and also provide an ability to manually resume
selecting a suspended SGW MO
Enhanced SGW and PGW selection is only enabled when at least one of the two MME
GW isolation associated global parameters are enabled:
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
309 / 652
Parameter
LTE PGW Isolation
SAM Table Name
Global parameters
OSS ID
Range & Unit
Yes - enables PGW Isolation feature on MME.

No - disables PGW Isolation feature on MME.
Impact of Change
No service impact.
Value
Feature
m10113-04
Parameter
LTE SGW Isolation
SAM Table Name
Global parameters
OSS ID
Range & Unit
Yes - enables SGW Isolation feature on MME.

No - disables SGW Isolation feature on MME.
Impact of Change
No service impact.
Value
Feature
m10113-04
In addition, separate PGW and SGW fault thresholds, suspension declaration timers
and GW isolation duration timers are used to control when and how long a LTE
SGW/PGW is declared as suspended or resumed after its isolation timer expired.
It's very critical to have proper fault threshold, suspension declaration timer and
isolation duration timer values. Otherwise, GW will be suspended too frequently or all
gets suspended and stop new PDN connection requests in the network.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
310 / 652
Issue 11.01
Parameter
PGW Isolation Fault Threshold
SAM Table Name
Global parameters
OSS ID
Range & Unit
If the number of the PGW faults (remote peer not responding

cause received in the S11/S4 Create Session Response)
exceed the provisioned threshod in a provisioned duration
timer then MME will isolate the PGW from the selection to new
PDN connection for provisionable duration
Impact of Change
No service impact.
Value
Feature
m10113-04
Parameter
SGW Isolation Fault Threshold
SAM Table Name
Global parameters
OSS ID
Range & Unit
If the number of the SGW faults (number of S11/S4 Create

Session Response timeouts) exceed the provisioned
threshold in a provisioned duration timer then MME will isolate
the SGW from the selection for provisionable duration.
Impact of Change
No service impact.
Value
Feature
m10113-04
Parameter
PGW Isolation Duration
SAM Table Name
Timer
OSS ID
Range & Unit
1 3600
minute
Impact of Change
No service impact.
Value
Feature
m10113-04
LTE/DCL/APP/031094
Nokia 2016
311 / 652
Parameter
PGW Isolation Duration Timer
SAM Table Name
Timer
OSS ID
Impact of Change
1 600
minute
No service impact.
Value
Feature
m10113-04
Parameter
SGW Isolation Duration
SAM Table Name
Timer
OSS ID
Range & Unit
1 3600
minute
Impact of Change
No service impact.
Value
Feature
m10113-04
Parameter
SGW Isolation Declaration Timer
SAM Table Name
Timer
OSS ID
Range & Unit
1 - 600
Impact of Change
No service impact.
Value
Feature
m10113-04
Range & Unit
Enhanced SGW and PGW selection supports similar capability for the determination
that a SGW and PGW pair cannot be used due to PGW faults. MME provides
provisioning of a create session request failure due to remote peer not responding
threshold and a duration. If the number of create session requests failures cross the
provisioned isolation fault threshold within the provisioned duration (SGW & PGW
isolation declaration timer) then MME will not select the pair for a configurable period of
time (SGW&PGW pair isolation timer). The pair will not be considered for the selection
until the isolation timer expires or manually enabled to be selected.
The following diagram illustrates the isolation of SGW and PGW for Create Session
Failures due to PGW.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
312 / 652
SGW 1
MME
PGW 1
SGW 2
SGW 3
PGW 2
Figure 8-10 SGW and PGW pair isolation and topological selection
In the following diagram SGW 1 may report number of Remote peer not responding
exceeding the configured threshold whenever PGW 1 is selected. This result in not
selecting PGW 1 whenever SGW 1 is selected for mode 1 selection and selecting a
SGW and PGW pair for mode 2 selection based on the selection of the topologically
closer SGW and PGW pair. Note that SGW 1 can still be selected in combination of
other PGWs and also PGW 1 can still be selected in combination of with the other
SGWs.
A new type of Maintenance Object (MO) Node is provided to support of the following:
Send events to the SAM if MME determines to suspend a SGW load balancer
or a SGW and PGW pair from selection.
Provide CLI commands to perform the following:

o
Manually suspend a node MO. A suspended MO would be excluded

from the node selection until manually enabled to be selected.
Manually resume node selection of a suspend node manually.
Obtain node status.
The feature represents SGW and PGW pair for mode 1 and mode 2 selection that have
been used at least once as Maintenance Objects. These maintenance objects state
can be obtained using a show command. When MME declare a pair is
isolated/blacklisted then the node is suspended from selection for a configurable period
of time. A CLI commands allows to manually suspend a MO representing a SGW and
PGW pair from selection and also provide an ability to manually resume selecting a
suspended GW.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
313 / 652
8.1.3 REGISTERED TRACKING AREA SELECTION
The MME is responsible for the selection of registered tracking areas (TAs) for each UE
during the Attach and Tracking Area Update (TAU) procedures. During these
procedures, the UE is sent a list of tracking area identifiers (TAIs) where the UEs
location is registered within the ATTACH ACCEPT and TAU ACCEPT messages. The
UE may move within any of these registered tracking areas without triggering a locationbased TAU.
The list of registered tracking areas for each UE always includes the tracking area
where the UE last reported its location. Additional tracking areas may be included by
the MME if cyclic movement between tracking areas is detected. For example, if a UE
moves from tracking area A to tracking area B and then back to tracking area A, this is
considered to be cyclic movement between two tracking areas and the both tracking
areas (A & B) can be included in the registered tracking area list sent to the UE. Please
note that automatic inclusion of additional tracking areas based on UE mobility history
can be enabled or disabled by the service provider via an MME Global Parameter.
The MME supports the automatic inclusion of previously visited tracking areas when
cyclic movement between tracking areas is detected in order to avoid a potential issue
with UEs at the border of multiple tracking areas. Concern has been raised that such a
UE would rapidly toggle between cells located within adjacent tracking areas, thus
generating a high number of TAU requests. This phenomenon is commonly referred to
as the ping pong effect. However, the automatic inclusion of previously visited tracking
area (or tracking areas) should help eliminate this issue.
Please note that automatic inclusion of previously-visited tracking areas is only
performed when UE movement is reported via Tracking Area Update procedures. If a
UE is in the connected state and movement is reported during a handover procedure,
then no automatic addition of tracking areas to the registered tracking area list will be
performed.
The MME will also include the neighbor tracking areas that have been provisioned in
the TAI Neighbor List based on the tracking area where the UE last reported its
location. However, it is recommended that the TAI Neighbor List be provisioned with
neighbor tracking areas only to deal with special cases. In normal cases, the TAI
Neighbor List should be left empty.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
314 / 652
8.1.3.1
Tracking area discovery at eNB setup
MME can learn TAIs as eNBs set up and update S1 connections to MME in addition to
the current method of pre-provisioning all TAIs serviced by MME.
The objective is to alleviate potential delays in the MME provisioning while the access
network (eNBs) provisioning is being modified by the operator
If the global parameter Discover TAIs is enabled, the full list of TAs provided by the
eNB will be entered in the TAI provisioned table, if it is not already included in it.
Parameter
Discover TAIs
SAM Table Name
Global parameters
OSS ID
gParmValue
Boolean
Yes or No
Impact of Change
No service impact.
Value
Feature
m10916-01
A new field TAI Provisioned Status is added to MME TAI table, with values Provisioned,
Discovered and ProvisionedAndDiscovered. The default value for new provisioned table
entries is provisioned:
Figure 8-11 MME TAI Provisioned Status

A learned TAI is added to MME TAI table with ProvisionedStatus set to Discovered.
The provisioned Status transitions from Discovered or ProvisionedAndDiscovered to
Provisioned after TAI is added to MME Group TAI table and from Discovered to
ProvisionedAndDiscovered after other data base updates involving learned TAI.
The mechanism provided by this feature is not call processing affecting, the TAI
discovery is expected to occur during commissioning of a node with radios-off.
To obtain correct function in an active network the operator shall configure the TAI
information in the usual way.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
315 / 652
The TAI-LAI mappings, for instance shall be provisioned to achieve proper combined
UE attach. If these mappings are not provisioned the UE shall proceed with an EPSonly-attach.
Note: even though this feature allows a learned TAI to be dynamically added to the list
of TAs, the parameters are not automatically provisioned in the MME Group to TAI list
and remains at default values.
The provisioning of the MME Group to TAI list table still have to be provisioned for
correct MME call processing for new enodeB
MME uses the MME Group to TAI List table when processing a S1 Handover.
If a TAI record exists in the MME Group to TAI List, MME proceed as normal.
If the TAI record does not exist and either:
The target eNB ID is known to the MME, processing continues with S1HO without MME
relocation, or
The target eNB ID is not known to the MME; MME examines the Discover MME global
parameter and proceed as follows:
If the Discover MME global parameter is set to No, MME reject the S1HO attempt.
If the Discover MME global parameter is set to Yes, MME performs a TAI DNS query
to proceed with the S1HO attempt with MME relocation.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
316 / 652
8.1.3.2
Controlling Automatic Neighbor List Generation
The MME allows control over registered tracking area selection using the following two
MME Global Parameters:
Automatically Add TAI to the TAI List
Parameter
Auto Add TAI to TAI List
SAM Table Name
Global Parameters
OSS ID
Range & Unit
gParmName
String
Auto_Add_TAI_to_TAI_List
gParmValue
Choice List
Off
Basic
Enhanced
UpdateThree
Impact of Change
No service impact.
Value
Operator Dependent; default = Basic
Include provisioned Neighbor List in the Registration TAI List :
If this parameter is set to Yes, the MME includes the provisioned set of Neighbor TAIs
in the list of TAIs that is sent to the UE when the UE registers at the MME (Attach or
TAU).
If this parameter is set to 'No', the MME only includes the Last Seen TAI in the list of
TAIs sent to the UE
Parameter
Include Neighbor List in TAI List
SAM Table Name
Global Parameters
OSS ID
Range & Unit
gParmName
String
gParmValue
Choice List
Off
Basic
Enhanced
Issue 11.01
Impact of Change
No service impact.
Value
Operator Dependent; default = Basic
LTE/DCL/APP/031094
Nokia 2016
317 / 652
8.1.3.2.1 AUTOMATICALLY ADD TAI TO THE TAI LIST
The Automatically Add TAI to the TAI List global parameter is used to control if
tracking areas are automatically added to the registered tracking area list based on UE
mobility history.
The following values are supported:
Off: tracking areas are not automatically added to the registered tracking area list
based on UE mobility history.
Basic (default): the MME will add the tracking area where the UE was previously
seen by the MME to the registered tracking area list when the MME detects cyclic
movement between two tracking areas.
Enhanced: the MME will add the previous two tracking areas to the registered
tracking area list when the MME detects cyclic movement between three tracking
areas. Support of handling cyclic movement between two tracking areas (that is,
BASIC mode) is also provided by the ENHANCED mode.
Update Three: the MME adds the previous two tracking areas to the registered
tracking area list. No cyclical behavior is required.
If the older TA does not match the preceding criteria, the neighbor list sent to the UE will
only contain the current TA. If the number of TAs in the neighbor list exceeds 3, MME
removes the oldest TA from the list.
The following table summarizes the impact of the Automatically Add TAI to the TAI List
global parameter on registered tracking area selection.
Registered Tracking Area List Generated for:
Issue 11.01
Automatically
Add TAI to the
TAI List Value
Initial
Attach on
TA-a
Linear
Movement
Off
TA-a
Basic
Cyclic Movement
between 2 TAs
(TA-a to TA-b to
TA-a)
Cyclic Movement
between 3 TAs
TA-b
TA-a
TA-a
TA-a
TA-b
TA-a and TA-b
TA-a
Enhanced
TA-a
TA-b
TA-a and TA-b
TA-a, TA-b, and TA-c
Update Three
TA-a
TA-a and TA-b
TA-a and TA-b

(cyclical move not
required)
TA-a, TA-b and TA-c

(cyclical move not
required)
(TA-a to TA-b)
LTE/DCL/APP/031094
(TA-a to TA-b to TA-c

to TA-a)
Nokia 2016
318 / 652
8.1.3.2.2 INCLUDE PROVISIONED NEIGHBOR LIST IN THE
REGISTRATION TAI LIST
The Include Provisioned Neighbor List in the Registration TAI List parameter is used
to control if the neighbor tracking areas provisioned in the TAI Neighbor List for the
tracking area for the UEs current location are included in the registered tracking area
list sent to the UE in the Attach Accept and TAU Accept messages. The following
values are supported:
Yes (default): the MME includes the provisioned set of Neighbor TAIs in the
registered tracking area list sent to the UE when the UE registers at the MME
(during Attach or TAU).
No: the MME will not include the provisioned set of Neighbor TAIs in the
registered tracking area list.
Please note that if the TAI Neighbor List is empty, then the value of the Include
provisioned Neighbor List in the Registration TAI List parameter will have no affect on
the generation of registered tracking area lists.
Also note that if the Automatically Add TAI to the TAI List parameter is set to Off and the
Include provisioned Neighbor List in the Registration TAI List parameter is set to No,
then only a single tracking area (that is, the tracking area for the UEs current location)
is included in the registered tracking area list.
Parameter
SAM Table Name
Global Parameters
OSS ID
Range & Unit
gParmName
String
Include_Neighbor_List_in_TAI_List
gParmValue
Boolean
Yes or No
Impact of Change
No service impact.
Value
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
319 / 652
8.1.3.3
Limitations and Restrictions for Automatic Neighbor
List Generation
The following limitations and restrictions affect the MMEs ability to automatically add
tracking areas to the registered tracking area list based on the UEs mobility history:
The length of the registered tracking area list cannot exceed the limit of 16 TAIs.
The MME clears the old UE mobility history and does not detect cyclical movement
between tracking areas in the following cases:
MME relocation has occurred due to inter-RAT handover or intra-LTE handover

to another MME.
SGW relocation has occurred due to the UE crossing a SGW service area
boundary.
The data session at the SGW is suspended (e.g., due to a prior circuit switched
fallback (CSFB) to 1x, GSM, or UMTS).
TAIs are not added to the registered tracking area list in the following cases:
The tracking area is associated with a different location area than the UEs
current location and the UE is capable of circuit-switched fallback (CSFB) and
has registered with combined Attached.
Access to tracking area is forbidden for the UE due to regional subscription

restrictions and/or the provisioned UE Roaming TAI and LAI Restriction List.
Service providers must also ensure that the provisioned TAI Neighbor List
contains only TAI that can be serviced by the same SGW.
If the Automatically Add TAI to the TAI List global parameter is provisioned to add
automatically-collected TAs, the older TAs must meet the following criteria:
older TAs VoLTE parameters (IMS voice over PS session indicator and
Emergency bearer services indicator) provisioning must match the current TA
Issue 11.01
older TAs must have the same Time Zone as current TA
older TAs must map to the same LAI
older TAs must be served by the same SGW
LTE/DCL/APP/031094
Nokia 2016
320 / 652
8.1.3.4
Impacts to UE Context Data Maintained by MME
In order to support registered tracking area selection, the MME tracks each UEs
mobility history using the following UE context fields:
Last Seen TAI - This is the tracking area identifier (TAI) where the UE was last
seen by the MME. In other words, this is the UEs last reported location. The TAI
value is received within the S1-AP messages from the cell where the UE is
currently served. This field is set at the completion of each mobility management
procedure.
Old Last Seen TAI - This is the tracking area identifier (TAI) where the UE was
previously located (that is, prior to the Last Seen TAI). Whenever the Last Seen
TAI field for a UE is changed to a new value, the Old Last Seen TAI field is set to
the previous value of the Last Seen TAI field. If a UE has not moved from the
tracking area where it attached to the network, then this field will be empty.
Older Last Seen TAI - This is the tracking area identifier (TAI) where the UE was
located prior to visiting the Old Last Seen TAI. This field is set to the Old Last
Seen TAI value only when the Last Seen TAI field is set to a value that is
different from the existing Last Seen TAI and Old Last Seen TAI values.
In order to allow the MME to page the UE in all tracking areas where it is currently
registered, the MME records the results of automatic neighbor list generation using the
following UE context fields:
Last Registered TAI - This TAI is a snapshot of the Last Seen TAI value taken at
the successful completion of an Attach procedure or Tracking Area Update
procedure. Please note that the Last Seen TAI is always included in the
registered tracking area list sent to the UE.
Old Last Registered TAI - This TAI is a snapshot of the Old Last Seen TAI value
that is set only if Old Last Seen TAI was included in the registered tracking area
list sent to the UE. The snapshot is taken at the successful completion of an
Attach procedure or Tracking Area Update procedure. If the Old Last Seen TAI
was not included in the registered tracking area list, then this field will be empty.
Older Last Registered TAI - This field is a snapshot of the Older Last Seen TAI
value that is set only if Older Last Seen TAI was included in the registered
tracking area list sent to the UE. The snapshot is taken at the successful
completion of a successful completion of an Attach procedure or Tracking Area
Update procedure. If the Older Last Seen TAI was not included in the registered
tracking area list, then this field will be empty.
Please note that the Old Last Registered TAI and Older Last Registered TAI fields are
only populated with TAI values when the associated TAI value was added to the
registered tracking area list due to Automatic Neighbor List Generation.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
321 / 652
8.1.3.5
Impacts to Attach Procedure
Upon receipt of an Attach request, the MME clears the old UE mobility history, including
the Last Seen TAI, Old Last Seen TAI, Older Last Seen TAI, Last Registered TAI, Old
Last Registered TAI, and Older Last Registered TAI fields of the UE context. The TAI
list sent in the Attach Accept message is not dependent on the Paging method used for
the first page attempt.
The set of registered tracking areas for a UE is initially specified during the Attach
procedure. The TAI list generated by the MME for the Attach Accept message includes
the following TAIs:
The Last Seen TAI (that is, the UEs current location).
The TAI of each neighbor of the Last Seen TAI (if a TAI Neighbor List was
provisioned and the Include provisioned Neighbor List in the Registration TAI
List parameter is set to Yes).
Note: Please note that 0 to 15 TAI neighbors may be provisioned for any TAI.
However, it is strongly recommended to limit the number of TAI neighbors provisioned
for any TAI so that the total number of eNodeBs associated with a TAI list does not
exceed 60 eNodeBs.
Upon successful completion of the Attach Procedure, the MME sets the TAI registration
fields of the UE context as follows:
The Last Registered TAI is set to the Last Seen TAI value.
The Old Last Registered TAI and Older Last Registered TAI fields are empty.
8.1.3.6
Impacts to TAU Procedure
Upon receipt of a TAU request, the MME clears the old UE mobility history, including
the Last Seen TAI, Old Last Seen TAI, Older Last Seen TAI, Last Registered TAI, Old
Last Registered TAI, and Older Last Registered TAI fields of the UE context for the
following situations:
MME relocation has occurred due to inter-RAT handover or intra-LTE handover

to another MME.
SGW relocation has occurred due to the UE crossing a SGW service area
boundary.
The data session at the SGW is suspended (for example, due to a prior circuit
switched fallback (CSFB) to 1x, GSM, or UMTS).
The UEs updated location will be used to update the Last Seen TAI and the other last
seen fields in the UE context. If Automatic Neighbor List Generation is enabled, the
MME will generate the registered tracking area list (sent to the UE within the TAU
ACCEPT message) based on the UEs mobility history.
Upon the successful completion of the Tracking Area Update procedure, the MME sets
the mobility history fields of the UE context as follows:
The Last Registered TAI is set to the Last Seen TAI value.
The Old Last Registered TAI is set to the Old Last Seen TAI value if the
associated TAI value is included in the registered tracking area list due to
Automatic Neighbor List Generation. Otherwise, this field is cleared.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
322 / 652
The Older Last Registered TAI is set to the Old Last Seen TAI if the associated
TAI value is included in the registered tracking area list due to Automatic
Neighbor List Generation. Otherwise, this field is cleared.
8.1.3.7
Impacts to Paging Method
The Last Registered TAI, Old Last Registered TAI, Older Last Registered TAI, and Last
Seen TAI fields are set by EPS mobility management for use by the Last Seen
Tracking Area Plus Neighboring Tracking Areas paging method. This UE location
information is saved for each successful Attach procedure and Tracking Area Update
procedure since this paging method attempts to page the UE within every tracking area
in which it is registered.
The Last Seen Tracking Area Plus Neighboring Tracking Areas paging method pages
the eNodeBs associated with the following TAIs:
The Last Registered TAI.
The TAI of each neighbor of the Last Registered TAI if a TAI Neighbor List was
provisioned and irrespective of the provisioning of the Include provisioned
Neighbor List in the Registration TAI List parameter.
The Old Last Registered TAI (if available).
The Last Seen TAI (if it differs from all the previous TAIs listed above).
The Older Last Registered TAI (if available).
Engineering Recommendation: Final Paging Attempt

It is strongly recommended that the Last Seen Tracking Area plus Neighboring
Tracking Areas method be utilized for the final page attempt in the MME Paging
Policy.
If this method is not used for any page attempt, then it is possible for a UE to move
within its set of registered tracking areas and not receive page messages at its current
location.
Please refer to Section 8.1.31 for more information on the paging methods supported by
the MME.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
323 / 652
8.1.3.8
Controlling TAU Suppression
When a UE is located near the boundary between eNBs, the UE can switch rapidly
between the eNBs as the signal strength fluctuates. If the eNBs are associated with
different tracking areas, this switching between eNBs can generate many unnecessary
TAU procedures (toggling or ping-ponging).
TAU suppression at tracking area borders occurs when the MME detects cyclical UE
movement between neighboring tracking areas. This mechanism stops many
unnecessary Tracking Area Updates (TAUs) from UEs that are toggling, but it can also
trigger TAU suppression when the UE makes a round trip that crosses a tracking area
boundary. Since TAUs may trigger the MME to update the Time Zone information in the
UE, unnecessary TAU suppression has the unintended consequence that Time Zone
information updates to the UE are also suppressed.
TAU Timer Override provides improved UE reach-ability and allows support for
customized T3412 timers per IMSI or device profile. It allows the MME to override the
locally provisioned T3412 timer if Subscribed-Periodic-RAU-TAU-Timer as defined in
TS 29.272 is present and received as part of subscription data/profile from HSS. (If Periodic-RAU-TAU-Timer is not present, the locally provisioned T3412 timer is used.) In
addition, provisioning is provided to override TAU timer value received from HSS. This
can be used to slow down TAU requests from roaming subscribers and MTC devices.
The provisioning is extended to each roaming PLMN.
8.1.3.8.1 PROVISIONABLE TAU SUPPRESSION THRESHOLD

The operator can provision an MME timer parameter (TAU Suppression Threshold) that
indicates the maximum time interval for movement between TAs that will trigger the
MMEs TAU suppression mechanism. Controlling TAU suppression optimizes the TAU
signaling load by suppressing updates that are due to UE toggling between tracking
areas while providing timely Time Zone updates to UEs that are truly moving between
tracking areas.
Parameter
TAU Suppression Threshold
SAM Table Name
Timer
ltemme.MMETimerAbs.TAU_Suppression_Threshold
ltemme.MMETimerAbs.seconds
OSS ID
Issue 11.01
Range & Unit
timerValue
Integer
[0..180]
Impact of Change
No service impact.
Value
Operator Dependent; default: 0 (indicates TAU suppression is

performed without regard to the interval of the cyclic movement
between tracking areas.)
LTE/DCL/APP/031094
Nokia 2016
324 / 652
8.1.3.8.2 SCENARIO: TAU SUPPRESSION TRIGGERED BY UE
TOGGLING BETWEEN TRACKING AREAS
Assume the following conditions:
The TAU Suppression Threshold timer has been set to 180 seconds (3 minutes)
Both tracking areas used in this example are served by the same SGW
No TAIs have been added to the MMEs TAI Neighbor List
The global parameter Auto Add TAI to TAI list parameter is set to Basic or
Enhanced
In this example, the UE moves between two tracking areas as shown below:
1. UE attaches to an eNB in TA 3100120x6400 at 7:15:30 AM.
2. UE triggers a TAU procedure in TA3100120x6401 at 7:15:40 AM.
3. UE triggers another TAU procedure in TA 3100120x6400 at 7:16:10 AM.
In steps 1 and 2, the MME has not yet detected any cyclic movement. As a result, the
TAI List sent to the UE in both steps includes only one TAI, the Last Seen TAI (that is,
TA 3100120x6400 in step 1 and TA3100120x6401 in step 2).
In step 3, the MME determines that cyclic movement between tracking areas has
occurred and the calculated interval of the cycle is 40 seconds, which is less than the
provisioned TAU Suppression Timer value. Consequently, the following TAIs are
included in the TAI List of the TAU ACCEPT message sent to the UE in Step 3:
TA 3100120x6400
TA3100120x6401
Since the UE is now registered in both tracking areas, it no longer triggers TAU
procedures as it switches between eNBs located in these two tracking areas.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
325 / 652
8.1.3.8.3 SCENARIO: NO TAU SUPPRESSION FROM NORMAL UE
MOVEMENT BETWEEN TRACKING AREAS
Assume the following conditions:
The TAU Suppression Threshold timer has been set to 180 seconds (3 minutes)
Both tracking areas used in this example are served by the same SGW
No TAIs have been added to the MMEs TAI Neighbor List
The global parameter Auto Add TAI to TAI list parameter is set to Basic or
Enhanced
In this example, the UE moves between two tracking areas as shown below:
1. UE attaches to an eNB in TA 310012-0x6400 at 7:15:30 AM
2. UE triggers a TAU procedure in TA 310012-0x6401 at 7:25:10 AM
3. UE triggers another TAU procedure in TA 310012-0x6400 at 7:50:40 AM
In steps 1 and 2, the MME has not yet detected any cyclic movement and, as a result,
the TAI List sent to the UE in both steps includes only one TAI, the Last Seen TAI.
In step 3, the MME determines that cyclic movement between tracking areas has
occurred, but the calculated interval of the cycle is more than 35 minutes, which is
greater than the provisioned TAU Suppression Threshold timer value. Consequently,
the following TAI is included in the TAI List of the TAU ACCEPT message sent to the
UE in step 3:
TA 310012-0x6400
Since the UE is still registered in only one tracking areas, it triggers a location-based
TAU procedure if it moves back to TA 310012-0x6401.
Note: If the TAU suppression threshold timer is set to zero, the TAU procedure in
Section 8.1.3.8 on page 323 is followed.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
326 / 652
8.1.3.8.4 ALTERNATE T3412 TIMER WITH TAU SUPPRESSION
The operator can provision an alternate T3412 timer value (T3412 TAU Suppression
parameter) that will be used when the MME detects a toggling UE. To suppress future
TAU procedures between the affected tracking areas, the MME automatically adds one
or more TAIs to the registered tracking area list sent to the UE in the TAU ACCEPT
message.
Parameter
SAM Table Name
OSS ID
T3412 with TAU Suppression

Timer
ltemme.MMETimerAbs.T3412_with_TAU_Suppression
ltemme.MMETimerAbs.decihour
Range & Unit
timerValue
Integer
[0..31]
Impact of Change
No service impact.
Value
Operator Dependent; default: 0 (indicates the standard T3412

timer should be used.)
The T3412 Source parameter determines how the T3412 timer is set. The field provides
the ability to override the provisioned T3412 timer with Subscribed-Periodic-RAU-TAU
Timer subscription data or to use the maximum of the provisioned and subscription
data.
Parameter
T3412 Source
SAM Table Name
Public Land Mobile Network (PLMN), UE PLMN Services
OSS ID
ltemme.SVCAgreementProfile.t3412src
Range & Unit
Choice List
Maximum of Provisioned and Subscription
Provisioned
Subscription
Impact of Change
No service impact.
Value
Operator Dependent; default = Provisioned (T3412 timer

provisioned at the MME)
Note: if T3412 Source is provisioned to use the subscription value and no data is
received from the HSS, then the provisioned value is used.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
327 / 652
The following table shows how the T3412 timer value included in the TAU ACCEPT
message can be affected by the provisioned TAU Suppression parameters.
TAIs Added to
TAI List for
TAU
Suppression?
T3412src Value
MME
T3412
Timer
Value
MME T3412
withTAU
Suppression
Timer Value
T3412 Timer
Value from
Subscription
T3412 Timer
Value Sent to
UE in TAU
Accept
No
Provisioned
(MME)
10
10
Yes
Provisioned
(MME)
10
Yes
Provisioned
(MME)
10
12
10 *
No
Subscription
10
Yes
Subscription
10
No
Maximum
10
10
Yes
Maximum
10
No
Maximum
10
10
Yes
Maximum
10
8.1.3.8.5 OPTIMAZATION OF PERIODIC TAU SIGNALLING FOR LPA UES

To reduce network load from periodic TAU signaling, a separate T3412 Extended for
LPA UE can be configured for LAP UEs to specify the use the locally provisioned LPA
T3412 timer value, HSS-provided T3412 timer value, or the higher setting between the
locally provisioned timer and the HSS-provided timer values.
Parameter
SAM Table Name
OSS ID
T3412 Extended for LPA UE

Timer
ltemme.MMETimerAbs.T3412_Extended_for_LPA_UE
ltemme.MMETimerAbs.decihour
timerValue
Integer
[0..31]
Range & Unit
Granularity
Seconds, Minute, Hour, DeciHour, and Hour.
Impact of Change
No service impact.
Value
Operator Dependent; default: 31.
Feature
m10115-01
T3412 with TAU Suppression Timer value is only used if it is less than the T3412 Timer value.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
328 / 652
8.1.4 IMPACT OF FORBIDDEN PLMN USING
SUBSCRIPTION ZONE CODES (RSZC)
REGIONAL
Forbidden PLMN using RSZC (Regional Subscription Zone Codes restricts UE access
to a network based on RSZC in UE subscription data.
If the parameter Enable RSZC Forbidden PLMN is set to True ( RSZC enabled), the
MME checks for RSZC in UE subscription data and MME uses the provisioned mapping
to obtain the forbidden PLMN. If an RSZC map to forbidden PLMN is included then
MME takes the following action:
If the serving PLMN (this can be MME home PLMN or shared PLMN) is not
provisioned to be forbidden then the MME proceeds with UE request.
If any of these forbidden PLMN are provisioned in the equivalent PLMN list for
the UE PLMN then MME does not include these forbidden PLMNs in the
equivalent PLMN list sent to the UE in Attach accept and TAU accept
messages and also these forbidden PLMN are not includes in Equivalent
PLMNs IE in Handover Restriction List IE of S1AP INITIAL CONTEXT SETUP
MESSAGE,
HANDOVER
REQUEST
and
DOWNLINK
TRANSPORT
messages. MME also excludes any forbidden LAI and TAI for these excluded
equivalent networks. The handover restriction list IE is only included in the
DOWNLINK TRANSPORT message if changes are received from HSS or
forbidden PLMN provisioning is changed.
If the serving PLMN itself is forbidden then MME rejects MM request with the
provisioned NAS cause code.
The cause code for rejecting Attach and TAU requests can be provisioned. The default
value is 11 (PLMN not allowed).
Forbidden PLMN using RSZC can be enabled/disabled via activation Enable RSZC
Forbidden PLMN.
Issue 11.01
Parameter
Enable RSZC Forbidden PLMN
SAM Table Name
UE PLMN Service
OSS ID
ltemme.UEPLMNServices. EnableRSZCForbiddenPLMN
Range & Unit
Boolean
Yes or No
Impact of Change
No service impact.
Value
Feature
m10135-01
LTE/DCL/APP/031094
Nokia 2016
329 / 652
Regional Subscription Zone Codes per served PLMN is provisioned in the table
Forbidden
RSZC
Table
for
applying
access
restriction
Up to 127 RSZC per PLMN can be provisioned.

Up to 4 forbidden PLMN (MCC and MNC) can be provisioned in table Forbidden RSZC
PLMN List per each served PLMN and RSZC combination provisioned in Forbidden
RSZC Table.
Parameter
NAS cause code for RSZC PLMN
SAM Table Name
UE PLMN Service
OSS ID
Range & Unit
Issue 11.01
ltemme.UEPLMNServices.
RSZCForbiddenNASCauseCode
Choice List
Table 17 NAS Cause Values
Impact of Change
No service impact.
Value
Feature
m10135-01
LTE/DCL/APP/031094
Nokia 2016
330 / 652
8.1.5 HANDOVER RESTRICTIONS
Handover restriction data is provisioned at the MME and consists of the following UE
information:
Serving (home) Public Land Mobile Network (PLMN).
Equivalent (allowed) PLMNs.
Forbidden tracking area codes (TACs).
Forbidden location area codes (LACs).
Forbidden Inter-Radio Access Technologies (IRATs) (such as GERAN, UTRAN,

and CDMA).
Refer to Section 6 for provisioning information.

The MME always includes the Handover Restriction List information in the INITIAL
CONTEXT SETUP REQUEST and HANDOVER REQUEST S1-AP messages if
provisioned handover restriction data exists.
If the handover restriction data is changed for a UE's home PLMN (even to remove
restrictions), the MME includes the Handover Restriction List information in the first
DOWNLINK NAS TRANSPORT S1-AP message to the UE after the data is changed.
Subsequent DOWNLINK NAS TRANSPORT messages to the same UE do not include
the Handover Restriction List information until there is change to the handover
restriction data.
8.1.6 ROAMING
A 3GPP network is divided into a radio access network (RAN) and a core network (CN),
which are connected via an open interface over the Iu or S1 or A/Gb reference point(s).
The A interface runs between the BTS/BSC and the MSC/VLR.
The Iu interface runs between the eNodeB RNC and the MSC/VLR, and between
the eNodeB RNC and the SGSN.
The S1 interface runs between the eNodeB and the MME, and the eNodeB and
the SGW/PGW.
The MME supports a UE moving to:
a GSM network (must be an A/Gb mode capable UE).
a UMTS network (must be an Iu mode capable UE).
an LTE network (must be an S1 mode capable UE).
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.
The MME stores the supported modes in the UE's Context data.
The MME considers a UE to be a roamer if the PLMN ID in the UEs IMSI does not
match the MMEs home PLMN ID.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
331 / 652
Issue 11.01
If
Then
A PLMN ID is removed from the roaming

agreement table
The MME takes actions on both ECMCONNECTED and ECM-IDLE UEs when
the MME performs the next EMM
procedure (either triggered by the UE or
the network).
The provisioned Network Access Mode

parameter is changed from "Packet" to
"Packet and Circuit" for a PLMN
The MME does not take any action on

either ECM-CONNECTED and ECMIDLE UEs.
The provisioned Network Access Mode

parameter is changed from "Packet and
Circuit" to "Packet"
The MME takes actions on both ECMCONNECTED and ECM-IDLE UEs when
the MME performs the next EMM
procedure (either triggered by UE or
network).
The provisioned Access Restriction Data is

changed for a PLMN
The MME takes no action on the UE. The

changed data is included in the handover
restriction list whenever one of the
following messages is next sent: INITIAL
CONTEXT
SETUP
REQUEST,
HANDOVER REQUEST, or DOWNLINK
NAS TRANSPORT.
The handover restriction list is changed
The MME takes no action on the UE. The

changed data is included in the handover
restriction list whenever one of the
following messages is next sent: INITIAL
CONTEXT
SETUP
REQUEST,
HANDOVER REQUEST, or DOWNLINK
NAS TRANSPORT.
CSFB feature restrictions for a PLMN are

changed from "Allowed" to "Not Allowed"
The MME rejects any ESR received from

a UE and the MME shall also rejects any
paging requests received over SGs
interfaces.
CSFB feature restrictions for a PLMN are

changed from "Not Allowed" to "Allowed"
The MME takes no actions. The MME

stores the AVP. The MME does not use
the AVP until a new PDN connection
request is received from the UE.
The
VPLMN-Dynamic-Address-Allowed
attribute value pair (AVP) is changed from
"Allowed" to "Not Allowed"
The MME stores the value. The MME

does not take any action if the UE is not
connected to the PDN. If a PGW from the
VPLMN is used, the MME disconnects
the UE from the PDN. If this is the last
PDN then the MME detaches the UE
explicitly if UE is in ECM-CONNECTED
state and implicitly if it is in ECM-IDLE
state.
LTE/DCL/APP/031094
Nokia 2016
332 / 652
If
Then
The
VPLMN-Dynamic-Address-Allowed
attribute value pair (AVP) is changed from
"Not Allowed" to "Allowed"
The MME stores the value. The MME

does take any action until a new PDN
connection request is received from the
UE for the PDN specified by the APN.
Regional
SubscriptionWithdrawal
is
included in the Delete Subscriber Request
(DSR) from the HSS
The MME deletes the Regional

Subscription data from the UE context.
The MME allows the UE in all TA of the
MME serving area.
Roaming Restricted due to unsupported

feature is included in the Delete Subscriber
Request (DSR) from the HSS
The MME deletes the AVP and takes no

action.
The MME supports roaming into E-UTRAN 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 E-UTRAN.
During EMM procedures, the various S1-AP messages' information elements are
populated from the MME's provisioned data, and if nonexistent in the MME then the
data is populated from the HSS data. The MME includes the UE's Handover Restriction
List information as described in "Handover restrictions".
When a roamer moves from GERAN or UTRAN to EUTRAN, the MME derives a
mapped security context from a UMTS security context that has been established while
the UE was in A/Gb mode or Iu mode.
If the 'SGW discovery by DNS query' is not enabled then the MME assumes that all the
provisioned SGWs support the S8 interface for the selection of SGW with S8 interface.
This applies to all scenarios where MME is required to select a new SGW serving the
target tracking area identifier (TAI). The scenarios include Attach, TAU with SGW
relocation, X2 Handover with SGW relocation, and S1 Handover with SGW relocation.
8.1.7 EMERGENCY BEARER

FUNCTIONALITY
AND
LOCATION
SERVICES
The MME supports the following emergency/location services:
Issue 11.01
IMS emergency services
Location Base Services and UE Coarse Positioning
Warning message delivery
Multimedia Broadcast/Multicast Service
LTE/DCL/APP/031094
Nokia 2016
333 / 652
8.1.7.1
IMS Emergency Services
This functionality allows service providers to meet regulatory obligations for emergency
services support.
Emergency bearer services are provided to normal attached UEs. The MME may allow
or reject an emergency attach request for UEs in limited service state (local regulations
and operators policy dependency).
The MME supports emergency bearers for following UEs types based on settings:
Valid UEs only : No limited service state UEs are supported in the network.
Authenticated UEs that have a valid IMSI : May be in limited service state due to
being in a location that they are restricted from service.
IMSI required, authentication optional :UEs must have an IMSI. If authentication

fails, the UE is granted access and the unauthenticated IMSI retained in the
network for recording purposes. The IMEI is used in the network as the UE
identifier, however, IMEI only UEs are rejected Emergency Bearer Services.
All UEs allowed : Includes UEs with an IMSI that cannot be authenticated and
UEs with only an IMEI.
UEs with all TAIs enabled with emergency services : MME indicates to UE that
emergency services are supported only if emergency services is enabled for all
the TAIs in the TAI list sent to the UE. Note: UE request for emergency support is
only allowed if requested from TAI with both Emergency Services and IMS Voice
support enabled.
UE with emergency bearer services in S1 mode. MME indicates to a UE whether

emergency services are supported or not at PLMN level (home, shared and
roaming partner networks), IMSI number series level, and at tracking area level.
MME sets the Emergency bearer services indicator of the EPS network feature
support IE in Attach Accept or in TAU Accept message based on on the setting of
the emergency parameter in the tracking area and service profile. If IMS voice is
not enabled then the bit shall always be set to emergency bearer services in S1
mode not supported. In order to support emergency service, both IMS voice and
Emergency Supported parameter in the service profile must be enabled." UE
uses this information to access LTE network when initiating an emergency call.
Note that any provisioning changes to the support of the IMS emergency service
will be notified to UE on a subsequent Attach Request or TAU Request. If the
emergency services is not allowed then MME rejects any UE attach request for
emergency services and also PDN connectivity request for emergency services
with cause code #17 (network failure).
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
334 / 652
The parameter emergency supported in UE PLMN and Served PLMN Service

Agreement Profile enable/disable emergency services
Parameter
Emergency Supported
SAM Table Name
OSS ID
ltemme.SVCAgreementProfile. emergencySupported
Range & Unit
Boolean
Yes or No
Impact of Change
No service impact.
Value
Feature Name
m10112-09
The following parameter must be provisioned to provide emergency services to a UE of

a PLMN:
The serving PLMN must be provisioned with an emergency profile.
Emergency services must be enabled for the current tracking area of the PLMN
and IMS voice capability must be enabled at the PLMN level or at the IMSI series
level.
If there is service profile provisioned for an IMSI range and TAC that includes UE
IMSI and current TAC then MME must check IMS voice and emergency services
are enabled. If not check the service profile provisioned for the UE PLMN to
check that both IMS voice and emergency are enabled.
Current requirements still apply for UEs with no roaming agreements and SIM
less UEs.
WM9.0.0 SU will set the emergency parameters of the service profile of a

PLMN or IMSI series enabled if the ims-voice parameter of the service profile is
enabled. Operators who want to disable the IMS emergency support for a PLMN
or IMSI series whose IMS voice over PS is enabled then the operator has to
change the setting to disable via provisioning.
To provide emergency bearer services, the MME Emergency Configuration Data is

applied to emergency bearer services established by an MME on UE request. An MME
Emergency Profile on the MME corresponds to a specific set of MME Emergency
Configuration data. There may be up to 10 MME Emergency Profiles provisioned on the
MME. The IMS Emergency Service is always located in the visited PLMN.
In order to provide emergency service, the visited PLMN must choose a provisioned
MME Emergency Profile on the MME.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
335 / 652
The following fields are provisioned on the MME:
Emergency Profile ID: the profile defines the bearer level QoS parameter values
for the Emergency APNs default bearer. Provisioning the Emergency Profile ID
field in the PLMN form activates IMS Emergency Services.
Emergency Number Table ID: defines an emergency number (such as 911) and
the type of emergency services associated with the number (such as police, fire,
etc.) See Section 8.1.7.1.2 for definition of individual Emergency Digit
parameters.
UE PLMN and Served PLMN Service Agreement Profile Emergency Supported

parameter.
Reference [R32], section 9471 WMM MME application provisioning, for provisioning
procedures
The Emergency Profile, Emergency Digits, and Timers forms should be reviewed and
updated (as necessary) prior to activating IMS Emergency Services on the PLMN form.
Rule: Activating IMS Emergency Services

Provisioning the Emergency Profile ID field in the PLMN form activates IMS
Emergency Services.
The Emergency Services feature should be enabled on all MMEs in the PLMN.
Parameter
Emergency Profile ID
SAM Table Name
Emergency Profile
OSS ID
ltemme.MMEEmergencyProfile.emergencyProfileId
Range & Unit
Integer
[0..10]
Impact of Change
No service impact.
Value
Operator Dependent; defaults: PLMN form = 0 (no associated

profile; IMS Emergency Services is not active), Emergency
Profile form = next available number
Emergency Mobile Reachable Timer: time to wait for UE to send TAU after T3412
expires. The MME initiates an implicit detach of the Emergency Attached UE once the
Emergency Mobile Reachable Timer expires and purge the UE context.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
336 / 652
Parameter
SAM Table Name
OSS ID
Range & Unit
Emergency Mobile Reachable

Timer
timerName
Choice List
Emergency_Mobile_Reachable
timerUnit
timerName)
minutes
timerValue
Integer
[0..1500] minutes
Impact of Change
No service impact.
Value
Operator Dependent; default = 124 minutes

The
Rule: Emergency Mobile Reachable Timer Length
The Emergency Mobile Reachable Timer must be longer than the T3412 timer.
The Emergency Mobile Reachable Timer is started after the T3412 timer expires.
MME includes a PUR-Flags AVP in the Diameter Purge-Ue-Request command if the

global parameter PUR-Flags is to Yes (Default Value of Yes) .
Parameter
PUR-Flags AVP
SAM Table Name
Global Parameters
gParmName
OSS ID
Range & Unit
String
PUR-Flags AVP
gParmValue
Boolean
Yes/No
Issue 11.01
Impact of Change
No service impact.
Value
Feature
m10099-14
LTE/DCL/APP/031094
Nokia 2016
337 / 652
When the global parameter E911 APN NI MODE 1 PGW SELECTION is enabled, the
provisioned Emergency PGW FQDN for GW Selection Mode 1 is no longer utilized.
Instead, the MME uses S-NAPTR procedure to select a PGW.
In the case of emergency attach, MME selects a PGW using topological matching if
there are multiple S-NAPTR records. MME also supports re-selection of SGW and/or
PGW based on the Create Session Request failure and source of the failure.
If S-NAPTR DNS query fails then MME uses the provisioned static IP address.
Parameter
E911 APN NI for Mode 1 PGW Selection
SAM Table Name Global Parameters

OSS ID
Range & Unit
gParmName
E911 APN NI for Mode 1 PGW Selection
gParmValue
Boolean
Yes or No
Impact of
Change
No service impact.
Value
Feature
m10112-06
In networks that support handover between E UTRAN and HRPD accesses, the MME
selects a PDN GW that is configured in the MME Emergency Configuration Data. The
PDN GW selection does not depend on subscriber information in the HSS since
emergency call support is a local. An assumption is made that the same PDN GW is
configured in 3GPP and HRPD. Once an IMS Emergency call is in progress,
emergency call continuity is supported using SRVCC where supported by network and
the UE. Additionally, the source E-UTRAN and source MME ignore any UE-related
restrictions during handover evaluation when emergency bearers are active.
During Tracking Area Update procedures, including a TAU as part of a handover, the
target MME ignores any mobility or access restrictions for the UE with emergency
bearer services. Any non-emergency bearer services are deactivated by the target
MME when not allowed by the subscription for the target location. These UEs behave
as emergency attached UEs in the target MME. 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. UEs in ECM-CONNECTED mode with an active
emergency bearer service are not released by MME for rebalancing. The MME waits
until the UE initiates a TAU or becomes inactive.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
338 / 652
MME supports the following enhancements starting in WMM7.0.0 and later releases:
During RAU and handover to SGSN procedures, emergency bearers are not
transferred to the SGSN.
A separate configurable T3412 timer (Emergency T3412) is provided for

emergency-attached UEs only.
A separate configurable Mobile Reachable timer is provided for emergencyattached UEs only.
For Network-Induced Location Services, the type of UE location reporting is

provisionable to include or not include the UE location estimate in the Subscriber
Location Report sent to the GMLC.
If the MME sends a Subscriber Location Report (LRR) with location event
"Emergency Origination", it will send LRR with "Emergency Release" when the
UE deactivates emergency bearers.
Emergency calls are not subject to the shedding algorithm under Minor, Major, or
Critical Overload. If the Critical Overload condition persists for an extended period (a
few seconds) then 100% of the non-emergency calls are subject to shedding. If the
Critical Overload condition persists for a few additional seconds, then emergency calls
are also subject to 100% shedding. In the event 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.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
339 / 652
8.1.7.1.1 EMERGENCY PROFILE
The Emergency Profile defines the bearer level QoS parameter values for the
Emergency APNs default bearer. The following parameters may be provisioned as part
of the profile:
Emergency Profile ID: (See Section 8.1.7.1 above.)
Emergency Number Table ID: The profile ID for the Emergency Digits form.
Emergency APN: describes the Emergency PDN connection
Emergency APN-AMBR: the maximum aggregated uplink and downlink MBR

values to be shared across all non-GBR bearers that are established for the
Emergency APN, as decided by the PDN GW.
Emergency PDN GW identity: may be statically provisioned on the MME or, if not
provisioned, the MME uses S-NAPTR to discover a PGW; the PDN GW for
Emergency Services is always located in the visited PLMN.
Non-3GPP HO Emergency PDN GW identity: PDN GW used for emergency APN

when a PLMN supports handover to non-3GPP access.
Emergency QCI: The QoS Class Identifier (QCI) value to use with Emergency
Service Default Bearers. (QCI is used to reference a set of access network
related quality of service (QoS) parameters, for the transmission between the UE
and the eNodeB. See Section 8.2.3.)
Emergency ARP: allows the service provider the ability to provide priority
treatment to public safety personnel whose UEs are assigned ARP high priority
values and whose UEs hold high priority access codes. Sessions initiated by
these UEs with high priority access will be given high priority treatment in the
MME, specifically during MME overload scenarios.
Preemption Capability & Preemption Vulnerability: Indicate the preemption

capability and preemption vulnerability to use with Emergency Service Default
Bearers. (Non-emergency default bearers are defined using the ARP form. See
Section 8.2.3.1.)
Service for Black Listed UE: Indicates whether or not Emergency Services should
be provided to UEs with an IMEI that is black listed in the EIR.
Service Behavior: Defines the UE types that receive MME emergency bearer
support
Emergency T3412 Timer (minutes).
Rule: Number of Emergency Profiles

The MME supports up to 10 Emergency Profiles.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
340 / 652
Rule: SLs Multi-homing
The SCTP interface for LCS-AP (SLs) supports local and remote multi-homing with
IPv4, IPv6, or IPv4/IPv6 dual stack addressing.
Parameter
Emergency Number Table ID
SAM Table Name
MME Emergency Number List, Emergency Profile

mmepolicy.MMEEmergencyNumListPolicy.emergencyNumber
TableId
OSS ID
ltemme.MMEEmergencyNumList.emergencyNumberTableId
Integer
Range & Unit
[0..10], where 0 indicates no Emergency Number List

No service impact.
Impact of Change
Issue 11.01
Value
Parameter
APN Network Identifier
SAM Table Name
Emergency Profile
OSS ID
ltemme.MMEEmergencyProfile.aPN_NI
Range & Unit
[1..100] Valid APN Network Identifier
Impact of Change
No service impact.
Value
Parameter
PGW IPv4
SAM Table Name
Emergency Profile
OSS ID
ltemme.MMEEmergencyProfile.pDNGW_IPV4
Range & Unit
Valid IPv4 address
Impact of Change
No service impact.
Value
Operator Dependent; default: 0.0.0.0
LTE/DCL/APP/031094
Nokia 2016
341 / 652
Parameter
PGW IPv6
SAM Table Name
Emergency Profile
OSS ID
ltemme.MMEEmergencyProfile.pDNGW_IPV6
Range & Unit
Valid IPv6 address
Impact of Change
No service impact.
Value
Operator Dependent; default: ::
Parameter
PGW Fully Qualified Domain Name
SAM Table Name
Emergency Profile
OSS ID
ltemme.MMEEmergencyProfile.pDNGW_FQDN
Range & Unit
Valid FQDN
Impact of Change
No service impact.
Value
Parameter
AMBR UpLink in bit/s
SAM Table Name
Emergency Profile
OSS ID
ltemme.MMEEmergencyProfile.aMBR_UL
Range & Unit
Integer
[0..4294967295], where 4294967295 = 0xFFFFFFFF
Impact of Change
No service impact.
Value
Operator Dependent; default=4096000
Parameter
AMBR DownLink in bit/s
SAM Table Name
Emergency Profile
OSS ID
ltemme.MMEEmergencyProfile.aMBR_DL
Range & Unit
Integer
[0..4294967295], where 4294967295 = 0xFFFFFFFF
Issue 11.01
Impact of Change
No service impact.
Value
Operator Dependent; default=4096000
LTE/DCL/APP/031094
Nokia 2016
342 / 652
Parameter
Emergency QCI
SAM Table Name
Emergency Profile
OSS ID
ltemme.MMEEmergencyProfile.emerQCI
Range & Unit
Integer
[5..9]
No service impact.
Impact of Change
Value
Parameter
Emergency ARP
SAM Table Name
Emergency Profile
OSS ID
ltemme.MMEEmergencyProfile.emerARP
Range & Unit
Integer
[1..15]
No service impact.
Impact of Change
Value
Parameter
Preemption Capability
SAM Table Name
Emergency Profile
OSS ID
ltemme.MMEEmergencyProfile.preemptionCapability
Range & Unit
Boolean
No service impact.
Impact of Change
Value
Issue 11.01
Operator Dependent; default = Yes (resources from lower

priority level service data flows may be used)
LTE/DCL/APP/031094
Nokia 2016
343 / 652
Parameter
Preemption Vulnerability
SAM Table Name
Emergency Profile
OSS ID
ltemme.MMEEmergencyProfile.preemptionVulnerability
Range & Unit
Boolean
No service impact.
Impact of Change
Operator Dependent; default = No (resources cannot be given
Value
to a service data flow with a higher priority level)
Parameter
Service for Black Listed UE
SAM Table Name
Emergency Profile
OSS ID
ltemme.MMEEmergencyProfile.esrvcBlackListedUE
Range & Unit
Boolean
Allow (checked) or Do Not Allow (unchecked)
Impact of Change
No service impact.
Value
Operator Dependent; default = Allow (provide services to UEs

with an IMEI that is black listed in the EIR)
Parameter
Service Behavior
SAM Table Name
Emergency Profile
OSS ID
ltemme.MMEEmergencyProfile.esrvcBehavior
Range & Unit
Choice List
All UEs are allowed
Valid UEs only
Only UEs authenticated are allowed
UE IMSI required
Authentication optional
Impact of Change
Value
Issue 11.01
No service impact.
Operator Dependent; default = All UEs are allowed
LTE/DCL/APP/031094
Nokia 2016
344 / 652
Parameter
Emergency T3412 Timer (minutes)
SAM Table Name
Emergency Profile
OSS ID
ltemme.MMEEmergencyProfile.esrvcT3412Timer
Range & Unit
Integer
[0 190] minutes, where 0 indicates timer is not used
Impact of Change
Value
Issue 11.01
No service impact.
LTE/DCL/APP/031094
Nokia 2016
345 / 652
8.1.7.1.2 EMERGENCY NUMBER LIST
The Emergency Profile form includes an optional Emergency Number Table ID
parameter. That parameter is the identifier for this Emergency Number List table. The
Emergency Number List table defines an emergency number (such as 911) and the
type of emergency services associated with the number (such as police, fire, etc.). Up
to eight emergency numbers can be defined for each MME.
Provisioning this list is optional, but if it is provisioned, the MME sends the list to the UE
regardless of whether or not emergency services are enabled.
Parameter
Emergency Digits
SAM Table Name
MME Emergency Number List
OSS ID
mmepolicy.MMEEmergencyNumListPolicy.emergencyDigits
ltemme.MMEEmergencyNumListAbs.emergencyDigits
Range & Unit
Up to 10 alphanumeric characters from the following sets:

[0..9], [a..c], *, #, and 0xf (used as an endmark for an
emergency number with an odd number of digits).
Impact of Change
No service impact.
Value
Parameter
Police
SAM Table Name
OSS ID
mmepolicy.MMEEmergencyNumListPolicy.police
ltemme.MMEEmergencyNumListAbs.police
Range & Unit
Boolean
Checked or Unchecked
Impact of Change
No service impact.
Value
Operator Dependent; default = Checked (Police service is

included as an Emergency Service Category for the associated
Emergency Number (Emergency Digits).
Parameter
Ambulance
SAM Table Name
OSS ID
mmepolicy.MMEEmergencyNumListPolicy.ambulance
ltemme.MMEEmergencyNumListAbs.ambulance
Range & Unit
Boolean
Impact of Change
Value
Issue 11.01
No service impact.
Operator Dependent; default = Checked (Ambulance service is

included as an Emergency Service Category for the associated
Emergency Number (Emergency Digits).
LTE/DCL/APP/031094
Nokia 2016
346 / 652
Parameter
Fire Brigade
SAM Table Name
OSS ID
mmepolicy.MMEEmergencyNumListPolicy.fireBrigade
ltemme.MMEEmergencyNumListAbs.fireBrigade
Range & Unit
Boolean
Impact of Change
No service impact.
Value
Operator Dependent; default = Checked (Fire Brigade service

is included as an Emergency Service Category for the
associated Emergency Number (Emergency Digits).
Parameter
Marine Guard
SAM Table Name
OSS ID
mmepolicy.MMEEmergencyNumListPolicy.marineGuard
ltemme.MMEEmergencyNumListAbs.marineGuard
Range & Unit
Boolean
Impact of Change
No service impact.
Value
Operator Dependent; default = Checked (Marine Guard service

is included as an Emergency Service Category for the
Parameter
Mountain Rescue
SAM Table Name
OSS ID
mmepolicy.MMEEmergencyNumListPolicy.mountainRescue
ltemme.MMEEmergencyNumListAbs.mountainRescue
Range & Unit
Boolean
Impact of Change
Value
Issue 11.01
No service impact.
Operator Dependent; default = Checked (Mountain Rescue

service is included as an Emergency Service Category for the
LTE/DCL/APP/031094
Nokia 2016
347 / 652
8.1.7.2
Location-Based Services
The MME supports the following Location Based Services:
Location reporting of UEs for IMS emergency calls. Emergency Location

Services (LCS) is used to assist subscribers who place emergency calls.
Coarse location.
HSS triggered location request.
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.
The following restriction applied for location-based-services in WM10.0.0 release:
Only the Immediate Location Request type; Deferred Location Request is not
supported.
Mobile Terminating Location Request (MT-LR) procedure is used to manage

external LCS client requests. MT-LR location query based upon MSISDN is not
supported and will be ignored
Network Induced Location Request (NI-LR) procedure is supported for UE

positioning for emergency calls.
Mobile Originated Location Request procedure (MO-LR) is not supported.
Because MO-LR is not supported, the MME does not support authentication
associated with LCS.
LCS must also be used in conjunction with IMS Emergency Services.
Non-dialable callback numbers are not supported.
LCS Billing and Charging are not supported
The Lawful Intercept LCS-Client-Type is not supported.
MSISDN is provided only it is available from the HSS.
Only the 1 digit IMEI format is supported.
LPP APDUs between the E-SMLC and UE are limited to 7915 octets in length.Message
if the MME received an LCS-AP LPP message with a PDU exceeding the maximum
allowed size of 7915 bytes, the message will be discarded and the MME will send a
LCS-AP LOCATION-ABORT message.
LPPa also has an APDU payload limit of 2000 bytes. For connection-oriented transfer,
if the limit is exceeded the MME will drop the message and attempt to abort the location
request. For connection-less transfer, the message will be dropped.
When a location request is aborted; the E-SMLC may have enough information to
provide a location estimate. If so, it may include location information in the location
response to the abort. If this information is received by the MME it will be returned to
the GMLC
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
348 / 652
MME supports positioning of LTE devices like data only devices. MME obtains
positioning information of these devices when requested by a GMLC i.e. using Mobile
Terminated Location Request procedures. MME supports positioning request with LCS
client type:
Emergency Services
Value Added Services
PLMN Operator Services
The following defines the EPS reference architecture for the support of LCS.
DIAMETER
SCTP or TCP
IP
GigE
LTE-Uu
E-UTRAN
E-UTRAN
S1-MME
HSS
SLh
S6a
9471 MME
GMLC
SLg
DIAMETER (ELP)
SCTP
IP
GigE
SLs
LCS-AP
SCTP
IP
GigE
E-SMLC
Figure 8-12: EPS LCS Network Architecture
MME supports the following interfaces for LCS: SLg to the Gateway Mobile Location
Center (GMLC) and SLs to EPS Serving Location Mobile Center (E-SMLC).
Up to 8 SLg remote endpoints may be configured per MME. For NI-LR, each
emergency profile supports up to two GMLCs. The MME is responsible for managing
positioning requests for LCS. The LCS functions of the MME are LCS co-ordination, ESMLC selection, location request, and operation of the LCS services. The MME may
inform HLR/HSS about the UE's LCS Capabilities for EPS and may include the IP
address of the GMLC associated with the MME in the Update Location Request
message, during Attach and Inter-MME Tracking Area Update procedures. The MME
selects an available E-SMLC to serve the location request for a UE. The selection is
based on last seen TAI and provides load balancing between E-SMLCs.
Restriction: LCS Network Support
LCS requires deployment of GMLC and E-SMLC. Additionally, eNB must support
LPPa and ECID (Enhanced Cell ID) positioning capability.
Restriction: GMLC Domain

The GMLC must be in the same domain as the MME. The SLg interface is not
supported between GMLC and MME in different networks.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
349 / 652
Rule: SLs Multi-homing
The SCTP interface for LCS-AP (SLs) supports local and remote multi-homing with
IPv4, IPv6, or IPv4/IPv6 dual stack addressing.
Rule: SLs Port

The SCTP profile for the SLs interface should use port number 9082.
The GMLC receives UE positioning requests from an LCS external client. An LCS client
is a software and/or hardware entity that interacts with an LCS Server (GMLC) to obtain
location information for one or more Mobile Stations. LCS Clients subscribe to LCS to
obtain location information. GMLC supports verification of identity of a client and clients
subscription data. GMLC forwards a validated request to the MME over the SLg
interface to obtain UE positioning data.
The GMLC obtains the address of the serving MME from the HSS to send client
requests to the right MME serving a UE.
The HSS contains the LCS subscription data and routing information.
The E-SMLC manages the overall co-ordination and scheduling of resources required
for the location of a UE that is attached to E-UTRAN. The E-SMLC interacts with the UE
to exchange location information applicable to UE assisted and UE-based position
methods and interacts with the E-UTRAN to exchange location information applicable to
network assisted and network based position methods. E-SMLC uses LTE Positioning
Protocols (LPP and LPPa) to UE and eNB respectively for UE positioning. The
positioning protocols are transparent to the MME.
The MME is provisioned with the following parameters to allow it to perform Location
Services when a UE sends an Emergency PDN Connectivity Request:
Initiate LCS Request: indicates whether or not the MME shall initiate a Location
Request for UEs sending an Emergency Attach Request or an Emergency PDN
Connectivity Request. (See page 361.)
Horizontal and Vertical Accuracy: a value in meters is derived from the

provisioned integer [0..127] using the formula given in TS 23.032, section 6.2.
Vertical Requested: indicates whether or not vertical accuracy was requested

with the Emergency PDN Connectivity Request.
Response Time: QoS parameter to indicate delay tolerance.
Rule: Initiate LCS Request

By default, the MME will not initiate a Location Request for UEs sending an
Emergency Attach Request or an Emergency PDN Connectivity Request. The
default cannot be changed unless IMS emergency services is enabled.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
350 / 652
Parameter
Horizontal Accuracy
SAM Table Name
Emergency Profile
OSS ID
ltemme.MMEEmergencyProfile.horizontalAccuracy
Range & Unit
Integer
[0..127]
Impact of Change
No service impact.
Value
Operator Dependent; default = 20 (57.3 meters)
Parameter
Vertical Accuracy
SAM Table Name
Emergency Profile
OSS ID
ltemme.MMEEmergencyProfile.verticalAccuracy
Range & Unit
Integer
[0..127]
Impact of Change
No service impact.
Value
Parameter
Vertical Requested
SAM Table Name
Emergency Profile
OSS ID
ltemme.MMEEmergencyProfile.verticalRequested
Range & Unit
Choice List
Not Requested
Requested
Impact of Change
No service impact.
Value
Operator Dependent; default = Not Requested
Parameter
Response Time
SAM Table Name
Emergency Profile
OSS ID
ltemme.MMEEmergencyProfile.responseTime
Range & Unit
Choice List
Low Delay
Delay Tolerant
Impact of Change
Value
No service impact.
Operator Dependent; default = Low Delay
Up to 256 E-SMLC remote endpoints may be configured per MME.

Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
351 / 652
Dedicated E-SMLC endpoints may be provisioned for IMS emergencency services, for
operator location services or value added services. Up to six E-SMLCs can be
provisioned per TAI. for value-added services and service-operator services,
Defining the E-SMLC entities is a 3 step process:
1) the E-SMLC IP address(es) are defined in the Remote End Point Configuration
form (up to 2 for each end point, see Section 6.10),
2) up to 2 Destination IP IDs from the Remote End Point Configuration form are
used in the ESMLC form,
3) up to 2 ESMLC IDs defined in the ESMLC form are used in the TAI form. When
2 ESMLCs are provisioned for a particular TAI, they can be used in either a
load-sharing manner or in a primary/secondary manner.
Parameter
ESMLC Identifier
SAM Table Name
ESM Location Center (ESMLC)
OSS ID
ltemme.MMEESMLCAbs.eSMLCIdentity
Range & Unit
Integer
[0..255]
Impact of Change
No service impact.
Value
Parameter
ESMLC Name
SAM Table Name
OSS ID
ltemme.MMEESMLCAbs.eSMLCName
Range & Unit
Alphanumeric String
Up to 32 ascii characters
Impact of Change
No service impact.
Value
Parameter
ESMLC Destination IP Remote Endpoint IP x
SAM Table Name
OSS ID
ltemme.MMEESMLC.rmtEndPtCfgPointer1
ltemme.MMEESMLC.rmtEndPtCfgPointer2
Integer
Range & Unit

[0..1024]
Issue 11.01
Impact of Change
No service impact.
Value
Operator Dependent; default = 0 (not used)
LTE/DCL/APP/031094
Nokia 2016
352 / 652
Parameter
Selection Algorithm
SAM Table Name
OSS ID
ltemme.MMETAIAbs.selectionAlgorithm
Range & Unit
Choice List
PrimarySecondary
LoadShare
Impact of Change
No service impact.
Value
Operator Dependent; default = PrimarySecondary
These E-SMLCs selection algorithms can be provisioned to support primary/secondary

or load sharing configuration for operator location services or value added services:
Parameter
Operator Location Services Selection Algorithm
SAM Table Name
OSS ID
Range & Unit
Choice List
PrimarySecondary
LoadShare
Impact of Change
No service impact.
Value
feature
m11016-01
Note: Load-sharing for E-SMLC for Emergency services client type is based upon a
pseudo-random algorithm while true round robin algorithm is used for operator location
services and value added services E-SMLCs when load-share option is selected.
Parameter
Value Added Location Services Selection Algorithm
SAM Table Name
OSS ID
Range & Unit
Choice List
PrimarySecondary
LoadShare
Issue 11.01
Impact of Change
No service impact.
Value
feature
m11016-01
LTE/DCL/APP/031094
Nokia 2016
353 / 652
Parameter
ESMLC Identity 1
ESMLC Identity 2
SAM Table Name
OSS ID
ltemme.MMETAIAbs.eSMLCIdentity1
ltemme.MMETAIAbs.eSMLCIdentity2
Range & Unit
Integer
[0..255]
Impact of Change
No service impact.
Value
Rule: ESMLC Identity

An ESMLC Identity (ESMLC Identity 1 & ESMLC Identity 2) must be defined using
the ESMLC form before it can be used to identify an ESMLC in the TAI form.
The Tai E-SMLC List allows operator to provision which E-SMLC a value-added client
type or operator service client type will use for a given Tracking Area or location Service
The existing TAI ESMLC provisioniong values are now considered emergency client
type E-SMLCs.
ESMLC selection priority (primary-secondary or load share) is configured on the MME
TAI screen for all client types.
Parameter
Location Services Type
SAM Table Name
TAI E-SMLC List
OSS ID
ltemme.TaiEsmlcListDetails
Range & Unit
Choice List
Operator Location Services, Value Added Location Services
Impact of Change
No service impact.
Value
Operator Dependent;
feature
m11016-01
Parameter
Location Services Entry Id
SAM Table Name
TAI E-SMLC List
OSS ID
ltemme.TaiEsmlcListDetails
Range & Unit
Integer
1-6
Issue 11.01
Impact of Change
No service impact.
Value
Operator Dependent;
feature
m11016-01
LTE/DCL/APP/031094
Nokia 2016
354 / 652
Parameter
ESMLC Identifier
SAM Table Name
OSS ID
ltemme.TaiEsmlcListDetails.eSMLCIdentifier
Range & Unit
Integer
[0..255]
Impact of Change
No service impact.
Value
A separate E-SMLC provisioning / LCS Option profile can be provisonned on per TA

basis for IMS Emergency services, value added services and operator services.
ESMLC provisioning is only used to identify the EMLC for Emergency client types. For
HSS initiated UE position requests, MME uses the E-SMLC provisioned for the valueadded services to determine UE position. Up to 32 LCS Option Profiles can be
provisioned. A LCS Options Profile is linked to a UE PLMN Service entry and a default
profile is created and assigned to all UE PLMN Service Agreements.
Dedicated E-SMLC LCS option profiles can be provisioned per UE PLMN Service
agreement among the following LCS client type (LCS client type contain the type of
LCS client issuing the positioning request Identifies the type LCS client) :
Emergency Services: Existing E-SMLC provisioning is used for emergency

related location requests. Emergency related location requests are Network
Induced Location Request (NI-LR) procedure or Provide-Location-Request
(PLR) with the type of LCS Client type = emergency.
PLMN Operator Services: Operator services are considered requests ProvideLocation-Request messages where LCS-Client-Type = PLMN OperatorServices. If the global parameter Activate LCS client type PLMN Operator
Services is set to Yes, then MME evolve code maps the existing TAs ESMLC provisioning to the operator services E-SMLC provisioning. If the global
parameter Activate LCS client type PLMN Operator Services is set to No the
no value will be provisioned for the TAs operator services E-SMLC.
Value Added Services: Value Added services are considered any PLR
message where clientType=value-added services or any IDR for EPS Location
Information. If the global parameter Activate LCS Client Type Value Added
Services is to Yes (value-added-services allowed) , then MME evolve code
maps the existing TAs E-SMLC provisioning to the value-added-services ESMLC provisioning. If the global parameter Activate LCS Client Type Value
Added Services is to ( value-added-services not allowed), the no value will be
provisioned for the TAs value-added services E-SMLC.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
355 / 652
LCS Options Profile consists of the following parameters:
Indication whether HSS location request is supported (Report UE State

Location Information if Requested) and if supported what type of UE location
can be returned to the UE (ECGI and TAI Only or UE Geolocation)
Quality of Service values for :

o
horizontal accuracy : a value in meters is derived from the provisioned

integer [0..127] using the formula given in TS 23.032, section 6.2)
vertical accuracy : a value in meters is derived from the provisioned

integer [0..127] using the formula given in TS 23.032, section 6.2
Vertical Requested: indicates whether or not vertical accuracy was

requested
Response Time QoS parameter to indicate delay tolerance
Indication if Mobile Terminated Location Request (MT-LR) client type = value

added is supported
Indication if Mobile Terminated Location Request (MT-LR) client type = operator

services is supported
Parameter
Horizontal Accuracy
SAM Table Name
Location Services Options Profile
OSS ID
ltemme.MME LcsOptionsProfile.horizontalAccuracy
Range & Unit
Integer
[0..127]
Impact of Change
No service impact.
Value
Feature
m11016-01
Parameter
Vertical Accuracy
SAM Table Name
OSS ID
ltemme.MMELcsOptionsProfile.verticalAccuracy
Range & Unit
Integer
[0..127]
Issue 11.01
Impact of Change
No service impact.
Value
Feature
m11016-01
LTE/DCL/APP/031094
Nokia 2016
356 / 652
Parameter
Vertical Requested
SAM Table Name
OSS ID
ltemme. MMELcsOptionsProfile.verticalRequested
Range & Unit
Choice List
Requested , Not REquested
Impact of Change
No service impact.
Value
Feature
m11016-01
Parameter
Response Time
SAM Table Name
OSS ID
ltemme. MMELcsOptionsProfile.responseTime
Range & Unit
Choice List
Low Delay
Delay Tolerant
Impact of Change
No service impact.
Value
Feature
m11016-01
Parameter
Operator Services LCS Client Type
SAM Table Name
OSS ID
ltemme.
MMELcsOptionsProfile.OperatorServiceLCSClientType
Range & Unit
Boolean
Yes or No
Impact of Change
No service impact.
Value
Feature
m11016-01
Parameter
Value Added Services LCS Client Type
SAM Table Name
OSS ID
ltemme. MMELcsOptionsProfile.
Range & Unit
Boolean
Yes or No
Issue 11.01
Impact of Change
No service impact.
Value
Operator Dependent; default = false
Feature
m11016-01
LTE/DCL/APP/031094
Nokia 2016
357 / 652
Defining a GMLC is a 3 step process: 1) the GMLC IP address (es) are defined in the
Remote End Point Configuration form, 2) the Destination IP ID from the Remote End
Point Configuration form is used in the Diameter Connections form for the SLg
connection, 3) the Destination IP ID defined as an SLg connection can be used to
identify a GMLC. Up to 8 GMLCs can be provisioned via the Diameter Connections
form using the following parameters:
Destination IP Id 1, Destination IP Id 2, Destination IP Id 3,
Destination IP Id 4
Parameter
SAM Table Name
OSS ID
Range & Unit
Diameter Connections
ltemme.DiamConnection.rmtEndPtCfgPointer1
Integer
[0..100], where 0 = IP Id is not used
Impact of Change
No service impact.
Value
Operator Dependent; default = 1 for IP Id1, default = 0 for IP Id

2 through 4
Rule: GMLC Identity
Issue 11.01
The ID associated with the GMLC IP address must be defined using the Remote
End Point Configuration form before it can be used to identify the GMLC in the
Diameter Connections form.
The Diameter Connections form associates the SLg application type with GMLC
destinations.
LTE/DCL/APP/031094
Nokia 2016
358 / 652
The Emergency GMLC ID is provisioned via the Emergency Profile form as follows:
Parameter
Emergency GMLC Primary, Emergency GMLC Alternate
SAM Table Name
Emergency Profile
OSS ID
ltemme.MMEEmergencyProfile.emergencyGMLCPrimaryPtr
ltemme.MMEEmergencyProfile.emergencyGMLCAlternatePtr
Range & Unit
Integer
[0, 1..1024], where 0 = GMLC is not used
Impact of Change
No service impact.
Value
Rule: Emergency GMLC Identity

An Emergency GMLC ID must be defined using the Destination IP ID fields in the
Diameter Connections form before it can be used to identify an Emergency GMLC in
the Emergency Profile form.
The Diameter Connections form associates the SLg application type with GMLC
destinations.
Rule: Primary GMLC

The MME will always use the primary GMLC if the SCTP association is available.
Parameter
Endpoint1 Name, Endpoint2 Name, Endpoint3 Name,

Endpoint4 Name, Endpoint5 Name, Endpoint6 Name,
Endpoint7 Name, Endpoint8 Name,
SAM Table Name
Diameter Connections
OSS ID
Range & Unit
String
Long name for Endpoint Id matching the label specified in
Remote End Point Configuration.
Issue 11.01
Impact of Change
No service impact.
Value
Endpoint 5 8 only applies to DiamApplType SLG
LTE/DCL/APP/031094
Nokia 2016
359 / 652
The following parameters are available to support Location Services interactions over
the SLs and SLg interfaces.
T3x01: time to wait to receive Location Response from the E-SMLC via
SLsbefore UE transitions to LCS-IDLE state.
Parameter
SAM Table Name
T3X01
Timer
timerName
ID
OSS
Choice List
T3X01
Range & Unit
timerUnit
timerName)
seconds
Impact
of Change
timerValue
Integer
[1..180] sec
No service impact.
Value
T3x02: time to wait to receive Reset Ack after sending Reset to the E-SMLC via
SLs before resending the LCS-AP Reset Request.
Parameter
T3X02
SAM Table Name
Timer
timerName
Choice List
T3X02
OSS ID
Range & Unit
timerUnit
timerName)
seconds
timerValue
Integer
[1..60] sec
Issue 11.01
Impact of Change
No service impact.
Value
LTE/DCL/APP/031094
Nokia 2016
360 / 652
LCSAP Number of resets without Ack for alarm: total number of Reset Attempts
without an Ack (T3x02 timer expires) before declaring failure and sending an
alarm to the MI subsystem.
Parameter
LCSAP Number of resets without Ack for alarm
SAM Table Name
Global Parameters
OSS ID
Range & Unit
gParmName
String
LCSAP_Number_of_resets_without_Ack_for_alarm
gParmValue
Integer
[1..5]
Impact of Change
No service impact.
Value
TSLR Ack from GMLC (T_LCSN): time to wait to receive Subscriber Location
Report Acknowledgement from GMLC via SLg.
Parameter
TSLR Ack from GMLC
SAM Table Name
Timer
OSS ID
Range & Unit
timerName
Choice List
TSLR_Ack_from_GMLC
timerUnit
timerName)
seconds
timerValue
Integer
[1..60] sec
Issue 11.01
Impact of Change
No service impact.
Value
LTE/DCL/APP/031094
Nokia 2016
361 / 652
Receive Notification Return from UE (TimeToGetNotifyReturn): time to wait to

receive Notification Return Result from UE.
Parameter
Receive Notification Return from UE
SAM Table Name
Timer
OSS ID
timerName
Choice List
Receive_Notification_Return_from_UE
Range & Unit
timerUnit
timerName)
seconds
timerValue
Integer
[1..60] sec
Impact of Change
No service impact.
Value
Rule: Receive Notification Return

The Receive Notification Return from UE timer must be greater than the T3x01
timer.
Finally, LCS is activated using the following parameters:
Activate LCS: indicates whether or not the MME should activate and provide
Location Services.
Parameter
Activate LCS
SAM Table Name
Global Parameters
OSS ID
Range & Unit
gParmName
String
Activate_LCS
gParmValue
Boolean
Yes or No
Impact of Change
No service impact.
Value
Operator Dependent; default = no (LCS is not active)
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
362 / 652
Activate LCS Client Type Emergency Services: indicates whether or not the MME
should activate and provide LCS Client Type for Emergency Services.
Parameter
Activate LCS Client Type Emergency Services
SAM Table Name
Global Parameters
OSS ID
gParmName
Range & Unit
String
Activate_LCS_Client_Type_Emergency_Services
gParmValue
Boolean
Yes or No
Impact of Change
No service impact.
Value
Activate LCS Client Type Value Added Services: indicates whether or not the
MME should activate and provide LCS Client Type for Value Added Services.
Parameter
Activate LCS Client Type Value Added Services
SAM Table Name
Global Parameters
OSS ID
gParmName
Range & Unit
String
Activate LCS Client Type Value Added Services
gParmValue
Boolean
Yes or No
Issue 11.01
Impact of Change
No service impact.
Value
LTE/DCL/APP/031094
Nokia 2016
363 / 652
Activate LCS Client Type PLMN Operator Services: indicates whether or not the
MME should activate and provide LCS Client Type for PLMN Operator Services.
Parameter
Activate LCS Client Type PLMN Operator Services
SAM Table Name
Global Parameters
OSS ID
gParmName
Range & Unit
String
Activate LCS Client Type PLMN Operator Services
gParmValue
Boolean
Yes or No
Impact of Change
No service impact.
Value
Initiate LCS Emergency: every PLMN (Home & Roaming) is provisioned with a
parameter to define the network-induced location request procedures for
emergency calls by UEs belonging to that PLMN.
Parameter
Initiate LCS Emergency
SAM Table Name
OSS ID
ltemme.MMEPLMN.initiate_LCS_EmergencyFromV5_0_0
Range & Unit
Choice List
Do not initiate
Send SLR to GMLC with estimated UE location
Send SLR without location estimate to GMLC
Issue 11.01
Impact of Change
No service impact.
Value
Operator Dependent; default = Do not initiate
LTE/DCL/APP/031094
Nokia 2016
364 / 652
LCS is only used for emergency services. So, LCS will not be invoked unless the
emergency services feature is activated.
Initiate LCS Request: indicates how a Location Request should be fulfilled.
Parameter
Initiate LCS Request
SAM Table Name
Emergency Profile
OSS ID
ltemme.MMEEmergencyProfile.initiateLCSRequest
Range & Unit
Choice List
Do not initiate
Send SLR to GMLC with estimated UE location
Send SLR without location estimate to GMLC
Impact of Change
Value
No service impact.
Operator Dependent; default = Do not Initiate (LCS is not
active)
The following are examples of LCS related call flows.
Figure 8-13: Mobile Terminating Location Request (MT-LR) Procedure
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
365 / 652
1) Mobile Terminating Location Request (MT-LR)
External LCS client requests location for a UE to GMLC.
GMLC verifies LCS client subscription data to validate LCS client allowed to
obtain UE position data.
GMLC obtains the address of the serving MME from the HSS and sends the
Provide Subscriber location request to the MME
MME performs the following checks:

- UE support of LCS
- LCS Client Type global parameter associated with the PLR is enabled (LCS
client is authorized). The supported client types (as indicated by their
Global Parameter names) are as follows:
- Activate LCS Client Type Emergency Services
- Activate LCS Client Type Value Added Services
- Activate LCS Client Type PLMN Operator Services
- Tracking area has E-SMLCs with SLs links up associated with the TA
- If the new global parameter Retrieve Cell-ID is set to No, the MME doesnt
page the UE or perform LCS procedure at this stage. If the UE is ECMIDLE and the global parameter Retrieve Cell-ID is set to Yes, the MME
sends S1AP Locaion-Reporting-Control for the UE current ECGI and TAI
information.
After all these checks are performed, MME selects an E-SMLC based on the last
visited TAI.
MME sends the location request to the selected E-SMLC.
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 eNB respectively. If UE is in IDLE state,
MME pages the UE. If required, MME notifies the UE to obtain UE permission to
allow location.
E-SMLC determines the UE location and sends the results to the MME.
MME sends the location data to the GMLC requested.
The MME responds with a Provide Subscriber Location Answer to the GMLC
from which the PLR was received. If the client type is Value Added Services or
PLMN Operator Services and if the MME is in major or critical overload, MME
responds to a percentage of the MT-LR request with diameter cause specified in
the global parameter MME Overload PLA Result
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
366 / 652
Parameter
MME Overload PLA Result
SAM Table Name
Global Parameters
OSS ID
gParmName
String
MME Overload PLA Result
Range & Unit
gParmValue
Choice List
3004 - too-busy
4002 - Out of Space
4224 - Positioning Denied
4225 - Positioning Failed
5006 - Resources Exceeded
Issue 11.01
Impact of Change
No service impact.
Value
Operator Dependent; default = 4224 - Positioning Denied
Feature
m11016-01
LTE/DCL/APP/031094
Nokia 2016
367 / 652
2) Network Induced Location Request (NI-LR) for emergency calls
The UE initiates emergency attach or emergency PDN attach.
The MME initiates an Network Induced Location Request (NI-LR) procedure it the
following conditions are verified :
The global parameter Activate LCS Client Type Emergency Services is

enabled.
Both parameters IMS Supported and Emergency Supported are set to true
under MME Tracking Area and has E-SMLSs SLs links assigned to it.
An Emergency Profile is configured under the PLMN with the parameter Initiate
LCS Emergency set to Send SLR to GMLC with estimated UE location
The Emergency Profile has the parameter Initiate LCS Request set to Send
SLR to GMLC with estimated UE location
MME selects an E-SMLC based on the last visited TAI of the UE.
MME sends location request to the E-SMLC.
MME uses the provisioned data for specifying the location accuracy to the ESMLC.
E-SMLC determines the UE location and sends it to the MME.
The MME sends the Subscriber Location Report (diameter command LocationReport-Request or LRR) to the GMLC provisioned on the Emergency Profile that
is indicated on the PLMN form.
GMLC responds with Subscriber Location Report Ack (diameter command

Location-Report-Answer or LRA).
MME saves location data in UE context.
Please refer to 3GPP TS 23.271, Section 9.1.17 for additional call flow details.
LCS Client
LRF/
GMLC
HLR/
HSS
E-SMLC
MME
RAN
UE
1. Emergency Attach or Setup Emergency Bearer

2. Location Request
3. Messages for individual positioning methods

4. Location Response
5. Subscriber LCS Report
6. Subscriber LCS Report ACK
7. Location Information
Figure 8-14: Network Induced Location Request (NI-LR) Procedure
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
368 / 652
3) Mobile Originated Location Request (MO-LR):
it allows an UE to request either, its own location and optionally, velocity or location
assistance data. Location assistance data may be used subsequently by the UE to
compute its own location throughout an extended interval using a mobile based position
method.
A mobile originated location request (MO-LR) starts with UE sending location request
for one of the services for example transfer to third party.
UE sends location request to MME with all pertinent data including the address of the
client to which the location data to be sent.
MME verifies the UE subscription data to determine whether MO-LR is allowed or not.
If allowed, MME selects an E-SMLC and sends the request.
E-SMLC determines UE location and sends it to MME.
MME sends the UE location to the client indicated by the UE.
MME saves location data in UE context
Figure 8-15 : Mobile Originated Location Request (MO-LR procedure

Please refer to 3GPP TS 23.271, Section 9.1.15 for additional call flow details.
MME provides the ability to indicate to the HSS in S6a Insert Subscriber Data
Request/Answer (IDR)/IDA whether or not the UE can support UE based or assisted
positioning methods.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
369 / 652
Prior to WMM9.1.0, handling of the HSS request for EPS User state, EPS Location
Information AVPs and Current Location Request in the S6a Insert Subscriber Data
Request message was specified by the global parameter EPS Location Data Request
in IDR. In WM9.1.0 M2 and later release, this capability has moved to the LCS option
Profile per PLMN and the global parameter EPS Location Data Request in IDR has
been removed and replaced by the parameter Report UE State Location Information if
requested under LCS Options Profile.
Parameter
Report UE State Location Information if Requested
SAM Table Name
OSS ID
Report UE State Location Information if Requested
Range & Unit
ParmName
String
ParmValue
not supported, ECGI and TAI support, ue geo-location
Impact of Change
No service impact.
Value
Operator Dependent; default = not supported (disabled)
Feature
m11016-01
The MME indicates support for User State and Location Retrieval to the HSS by setting
the EPS User State/Location Information Retrieval bits in the IDR flags AVP as shown
in Table 9: IDR-Flags :
Bit Pattern
Name
Usage
Bit 7 6 5 4 3 2 1
0
EPS User State.
DETACHED (0) : UE is in EMM-DEREGISTERED state.
00000100
EPS User
State
Request
CONNECTED_NOT_REACHANBLE_FOR_PAGING (3) : ECMIDLE UE suspended state or MME started the MME-initiateddetach-timer and stopped paging UE for any network requests.
CONNECTED_REACHABLE_FOR_PAGING (4) : ECM-IDLE
UE which is not in suspended state or whose MME-initiateddetach timer is not running. See 29.272 7.3.114.
00001000
EPS
Location
Information
Request
00010000
Current
Location
Request
Report EPS Location Information. Returns the AVP

Geographical-Information (OctetString) which is part of the AVP
MME-Location-Information which in turn is part of the AVP EPSLocation-Information.
If bit 4 is set, retrieve the current location.
Invalid if bit 4 is not set (return IDA with
DIAMETER_UNABLE_TO_COMPLY).
Table 9: IDR-Flags
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
370 / 652
Handling of the IDR-Flags, EPS-User-State, and EPS-Location-Information AVPs is
specified in TS 29.272 5.2.2.1.2, 5.2.2.1.3, 7.2.9, and 7.3.103.
The MME checks the provisioning of the parameter Report UE State Location
Information if requested under LCS Options Profile instead of the global parameter
EPS Location Data Request in IDR to determine MME handling of HSS requested UE
status and location.
The following three options are provided:
Not supported: If this option is selected then MME doesnt indicates to the HSS that
MME supports EPS State/Location retrieval in ULR and IDA. The MME sends
DIAMETER-UNABLE-TO-COMPLY if receive IDR-Flag with EPS User State Request,
EPS Location Information Request, Current Location.
Request.ECGI and TAI support: MME indicates to the HSS in ULR and IDA that MME
supports the EPS State/Location. When HSS sends IDR requesting EPS Location
Information then MME only sends the current ECGI and TAI information along with an
age of when the information was collected.to the HSS. In the case current location is
requested and the UE is :
ECM-IDLE, MME pages the UE to get the latest ECGI and TAI information.
ECM-CONNECTED returns the information currently stored for the UE in the MMEs UE
context. In this case MME does not run LCSAP procedures to obtain UE location
Ue geo-location: MME indicates to the HSS in ULR and IDA that MME supports the
EPS State/Location. When HSS sends IDR requesting EPS Location Information then
MME trigger the LCSAP procedures to obtain UE location and sends the obtained UE
geo-location in the Insert-Subscription Data Answer (IDA) message along with the most
recent ECGI and TAI. The MME performs the LCSAP procedure only if eps-statelocation-info-request =UE-geo-location and current location is requested
During an software upgrade, the LCS Option Profile default profile value of the
parameter Report UE State Location Information if Requested will be replaced with the
global parameters value. (ecgi-tai-only or ue-geo-location represent the UE can support
State Retrieval)
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
371 / 652
Starting in WM9.1.0 M2 and later release, the global parameter Retrieve Cell id when
set to Yes enabled retrieval of ECGI from the eNB to be included in the S1-AP
Location Request message sent to the E-SMLC when MME is triggered
either
by
GMLC or by HSS to get UE location. The retrieval of the ECGI applies to all client types.
Parameter
Retrieve Cell id
SAM Table Name
Global Parameters
OSS ID
gParmName
String
Retrieve Cell id
Range & Unit
gParmValue
Boolean
Yes or No
Impact of Change
No service impact.
Value
Setting the the global parameter Retrieve Cell id to No (default) disable the retrieval of
ECGI from the eNB and MME sends the ECGI that was received in the most recent S1AP message.
In WM9.1.0M2 release MME allows provisioning of the LCS Quality of Service values
(LCS QOS was previsously hardcoded.) to be used for HSS requested UE position:
Horizontal Accuracy set to 20
Parameter
Horizontal Accuracy
SAM Table Name
OSS ID
ltemme.MME LcsOptionsProfile.horizontalAccuracy
Range & Unit
Integer
[0..127]
Impact of Change
No service impact.
Value
Feature
m11016-01
Issue 11.01
Response Time set to low delay (default)
Parameter
Response Time
SAM Table Name
OSS ID
ltemme.MMEEmergencyProfile.responseTime
Range & Unit
Choice List
Low Delay
Delay Tolerant
Impact of Change
No service impact.
Value
Feature
m11016-01
LTE/DCL/APP/031094
Nokia 2016
372 / 652
Vertical Accuracy set to 20
Parameter
Vertical Accuracy
SAM Table Name
OSS ID
ltemme.MMELcsOptionsProfile.verticalAccuracy
Range & Unit
Integer
[0..127]
Impact of Change
No service impact.
Value
Feature
m11016-01
Vertical Position Requested set to not requested.
Parameter
Vertical Requested
SAM Table Name
OSS ID
ltemme. MMELcsOptionsProfile.verticalRequested
Range & Unit
Choice List
Requested , Not REquested
Impact of Change
No service impact.
Value
Feature
m11016-01
Note that the IDA message only supports ellipsoid point with uncertainty circle shape.
If the MME receives a latitude/longitude response with a different shape or failure
occurs retrieving data for the UE, the MME will send IDA with only the available ECGI
and TAI information.
This feature assumes that IDR using these new IDRflags will only be sent with that set
of data and not combined with other IDR AVPs.
In WM900M2 and later releases, the MME populates the PS-LCS-Not-Supported-ByUE bit6 of Update-Location-Request flags based upon the value of the UE LTE
Positioning Protocol (LPP) capability (octet 7 bit 4) indicated in the UE network
capability IE received from the UE in either an attach request or TAU
Previously, this bit was always set to 0 (LPP supported).
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
373 / 652
8.1.7.3
Warning Message Delivery (CMAS)
This functionality allows warning messages to be sent to a UE in a particular area.

An MME receives warning messages from a Cell Broadcasting Center (CBC) using the
SBc interface, and the MME forwards these messages to the eNBs. CMAS support on
the eNodeB and Cell Broadcast Center is required.
MME Pool
94xx/99xx
eNB
9471 MME
LTE-Uu
CBC
9471 MME
94xx/99xx
eNB
SBc
SBc-AP
SCTP
IP
GigE
S1-MME
Figure 8-16: Warning Message Delivery Network Architecture

Messages are forwarded to the appropriate eNodeBs and then broadcasted using a
paging channel. The eNodeBs provide state management for the warning messages for
broadcast
repetition
interval,
broadcast
duration,
message
replacement,
and
cancellation. The eNodeBs also manage scenarios where multiple copies ofWriteReplaceWarning Message Request messages are received for the same warning
message (for example from multiple MMEs in the case of MME pooling).
Starting in WM8.0.0 and later release, the MME supports 9,000 cell IDs (current MME
handling of 512 cell IDs) in the Warning Area List sent by the CBC to the MME and
MME to enodeBs for the following messages:
incoming SBc request message (SBcWriteReplaceWarningRequest or SBc

StopWarningRequest)
outgoing S1AP request message (S1APWriteReplaceWarningRequest or S1AP

KillRequest)
The message size of an SBcWriteReplaceWarningRequest or SBcStopWarningRequest

cannot exceed 65K bytes. The MME drops SBcWriteReplaceWarningRequest or
StopWarningRequest message if the message size exceeds 65K bytes.
Provisioning at the MME includes specifying an SCTP profile ID for the SBc interface
and provisioning the SBc interface using the SCTP profile ID of SBc. If the local IP
address for the SBc interface exists, then the interface profile can be created and the
feature can be enabled.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
374 / 652
Rule: SBc Multi-Homing

The SCTP interface for SBc supports multi-homing with IPv4, IPv6, or IPv4/IPv6 dual
stack addressing.
This functionality also uses the TAI to eNodeB mapping that is already contained on the
MME for normal call processing. CMAS message handling has the highest priority in the
MME and is not throttled in overload conditions. The MME has mechanisms to slow
down CMAS broadcasting to avoid causing overload conditions in the MME.
If CMAS broadcasting does cause overload in the MME, the MME starts dropping
mobility management and session management procedures. However, the MME
protects procedures for emergency and high priority calls.
The eNB is responsible for providing state management for warning messages in terms
of broadcast repetition interval, broadcast duration, message replacement and
cancellation. The eNB is also responsible for managing multiple copies of WriteReplace Warning Message Request received for the same warning message.
Starting in WM10.0.0 and later releases:
The MME sends the broadcast completed area list information received from
the eNBs or HeNBs to the CBC if the global parameter Write Replace Warning
Indication is enabled and the Send Write-Replace-Warning-Indication IE is
present in the correspondingWrite-Replace-Warning-Request message. The
MME initiates theWrite ReplaceWarning Indication procedure by sendingWriteReplace-Warning-Indication messages to the CBC after it has previously
received a Broadcast Completed Area List from an eNB or HeNB in aWriteReplace-Warning-Response message.The MME can aggregate Broadcast
Completed Area Lists it receives from eNBs or HeNBs.
The MME sends the Stop-Warning-Indication messages to report the Broadcast

Cancelled Area Lis to the CBC if the global parameter Stop Warning Indication
is enabled and the Send StopWarning Indication parameter is present in the
corresponding Stop-Warning-Request message. The MME initiates the
StopWarning Indication procedure by sending a Stop-Warning-Indication
message to the CBC after it has previously received a Broadcast Cancelled
Area List from an eNB or HeNB. The MME can aggregate Broadcast Cancelled
Area Lists it receives fromeNBs or HeNBs. The Broadcast Empty Area List
contains the Global eNB IDs of the eNBs of which send a Kill-Response with no
Broadcast Cancelled Area List. The MME also initiates the StopWarning
Indication procedure by sending a Stop-Warning-Indication message to the
CBC after it has previously received an S1AP Kill-Response without a
Broadcast Cancelled Area List from an eNB or HeNB.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
375 / 652
The following call flows show normal (sunny day) operation for Warning Message Delivery and Warning
Message Cancellation.
Figure 8-17: Warning Message Delivery
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
376 / 652
Figure 8-18: Warning Message Cancellation

Warning Message Delivery is enabled via the following parameters:
SBc Enabled: every PLMN (Home & Roaming) is provisioned with a parameter
to enable or disable the CBC feature for that PLMN. When the feature is
enabled, Cell Broadcasts are sent to the eNBs in the TAIs of the associated
PLMN(s).
Parameter
SBc Enabled Type
SAM Table Name
OSS ID
ltemme.MMEPLMN.sBcEnabled
Range & Unit
Boolean
Issue 11.01
Impact of Change
No service impact.
Value
Operator Dependent; default = False (SBc is not active)
LTE/DCL/APP/031094
Nokia 2016
377 / 652
Warning Message Timer: the warning message timer is an S1 interface timer. It

indicates the time to wait for the Warning Message Delivery Service. Failure to
receive a Write-Replace Warning Response or Kill Response form the eNB
before the timer expires indicates the broadcast or broadcast cancellation is
unsuccessful in that eNB.
Parameter
SAM Table Name
OSS ID
Range & Unit
Warning Message
Timer
timerName
Choice List
Warning_Message
timerUnit
timerName)
seconds
timerValue
Integer
[1..60] sec
Impact of Change
No service impact.
Value
Warning Retransmissions: the warning restransmission global parameter

specifies how many retransmission attempts will be made on the S1MME link if
the eNB does not reply to a CMAS request.
Parameter
Warning Retransmissions
SAM Table Name
Global parameter
Range & Unit
Integer
[0..10]
Impact of Change
No service impact.
Value
Alert Message Holding Time: the alert message hodling time specifies in
seconds that a SBC CMAS message will be queued for while waiting for a
previously received SBC CMAS message to finish processing.
if a CMAS message arrives while another SBC CMAS message is being
processed then the message will be queued for up to the Alert Message
Holding Time. If a high volume of SBC CMAS messages are being sent over
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
378 / 652
the S1MME links, verify that the Alert Message Holding Time is sufficent to hold
messages long enough.
Parameter
Alert Message Holding Time
SAM Table Name
Timer
OSS ID
Range & Unit
timerUnit
seconds
timerValue
Integer
[1..300] sec
Impact of Change
No service impact.
Value
The following global parameters controls the severity of the CMAS alarms and the type
of CMAS alarms messages that are logged in the Warning System Log :
Issue 11.01
Alarm Fail to Send

CMAS Message
{None, Minor,
Major,
Critical}
Major
Alarm Fail to Receive

CMAS Response
{None, Minor,
Major,
Critical}
Major
Alarm CMAS Failure
{None, Minor,
Major,
Critical}
Major
Warning System Log
{All,SBC_ON
LY,
S1_ONLY,No
ne}
All
LTE/DCL/APP/031094
If a CMAS message is unable

to be sent after all attempts an
Alarm is generated with its
Severity set to this value. If
None is specified then no
Alarm is generated.
If a CMAS response is not
received after all attempts an
Alarm is generated with its
Alarm is generated.
A failure has occurred that will
prevent a CMAS from being
sent or a erroneous CMAS
message has been received,
an Alarm is generated with its
Alarm is generated.
Which received and sent
CMAS messages to be placed
in the warnsys log at
/var/opt/log/warnsys
Nokia 2016
379 / 652
8.1.7.3.1 RESTORATION OF WARNING MESSAGE DELIVERY UPON
ENB FAILURE/RESTART
When an eNB has lost its warning message data (.e.g. after restarting), the eNB sends
a new message called PWS RESTART INDICATION to the CBC via MME to request
the CBC to reload its warning message data if any. The CBC initiates Write Replace
Warning Request procedure to reload the applicable warning message data to the
eNB.Figure 8-18 shows the message sequence of the procedure:
Figure 8-19 PWS Restart indication

Legend;
1. After an eNodeB has restarted, it deletes all its warning message data. If the
warning message service is operational in one or more cell(s) of the eNodeB,
the eNodeB sends a PWS Restart Indication message, which includes the
identity of the eNodeB, the identity of the restarted cell(s), and the TAI(s) and
EAI(s) with which the restarted cell(s) are configured, to the CBC to request the
CBC to re-load its warning message data if applicable. The eNB sends the
PWS Restart Indication message via two MMEs of the MME pool, if possible, to
ensure that the CBC receives the message even if one MME cannot propagate
it to the CBC (e.g. due to an SBc path failure).
2. MME copies the parameters received from the eNB into the PWS RESTART
INDICATION message to the CBC.
3. The CBC reloads the warning message data to the eNB by initiating Write
Replace Warning procedure(s) with the following additions:
a. the CBC copies the Restarted-Cell-List, or the Tracking Area ID List or
the Emergency Area ID List to populate the Warning Area List IE of the
Write-Replace Warning Request message;
b.
the CBC copies the Global eNB ID into the Write-Replace Warning
Request message.
4. If a Global eNB ID IE is present in the WRITE-REPLACE WARNING REQUEST

message, the MME forwards the message only towards the eNB identified by
the Global eNB ID if this IE is supported by the MME.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
380 / 652
The global parameter PWS Restart Procedure controls forwarding of the PWS Restart
indication message received from an eNB to the CBC. (Disabled by default).
Parameter
PWS Restart Procedure
SAM Table Name
Global Parameters
OSS ID
Range & Unit
Boolean
Yes or No
Issue 11.01
Impact of Change
No service impact.
Value
Feature
m11005-09
LTE/DCL/APP/031094
Nokia 2016
381 / 652
8.1.7.4
Multimedia Broadcast/Multicast Service
Multimedia Broadcast/Multicast Service (MBMS or eMBMS) is a broadcast service in

which data is transmitted from a single source entity to multiple recipients. Transmitting
the same data to multiple recipients allows network resources to be shared. The MME
provides for 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) in the eNB nodes. The MCE
initializes the M3 SCTP association with the MME; the MME sends MBMS M3-AP
messages to MCEs that have initialized an M3 SCTP association. Therefore, depending
on SCTP association initialization, each MCE may be connected to several MMEs in the
MME pool.
The MME supports the following to enable MBMS support for E-UTRANs:
Session control of MBMS bearers to the E-UTRAN access (including reliable

delivery of Session Start/Session Stop/Session Update to E-UTRAN
Determines the eNodeB nodes which are in the MBMS Broadcast Service Area
and transmits session control messages toward the appropriate E-UTRAN nodes
using the M3 interface.
Receives MBMS service control messages and the IP Multicast address for
MBMS data reception from MBMS GW function over the Sm interface.
M3-AP
SCTP
IP
GigE
MCE
Function
LTE-Uu
M3
94xx/99xx
eNB
MME Pool
9471 MME
MBMS
GW
94xx/99xx
eNB
MCE
Function
9471 MME
Sm
GTP-c (GTPV2)
UDP
IP
GigE
S1-MME
Figure 8-20: MBMS/eMBMS Network Architecture

Provisioning at the MME for MBMS includes the activation of the new Sm interface to
the MBMS Gateway and the M3 interface to the MCE function.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
382 / 652
Rule: M3 and Sm Multi-homing
The SCTP interface for M3 supports local and remote multi-homing with IPv4, IPv6,
or IPv4/IPv6 dual stack addressing.
Rule: GTP-C Port for Sm

The MME listens for Sm messages on UDP port 2123 (the default port number). The
source port number of the request message is used as the destination port number
of the response message.
Three main events that can happen within an MBMS session: Session Start, Session
Update, and Session Stop. These events are triggered by a Sm message from the
MBMS GW and result in the MME distributing messages out to the MCE.
The following call flow shows an MBMS Session Start.
UE
eNB 1
eNB n
MME
MBMS GW
MBMS GW receives notice of

Broadcast
(M1) Sm: MBMS Session Start Request

(M2) Sm: MBMS Session Start Response
A1: MME forwards an M3 MBMS Session Start
Request to each MCE with an active SCTP association.
A2: MME builds an MBMS Bearer Context with the
attributes from the Session Start
(M3) M3: MBMS Session Start Request
(M4) M3: MBMS Session Start Request
Verifies receipt & validation of Request at the MCE
but does not depend on positive response from UE.
(M5) M3: MBMS Session Start Response
(M6) M3: MBMS Session Start Failure
MBMS Session Start
A3: MME updates the MBMS Bearer Context with successful
MCE responders data.
MCE join the IP multicast group for user plane delivery

VP1: M1: Bearer Path for Broadcast
Figure 8-21: MBMS/eMBMS Session Start
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
383 / 652
Restriction: Sm Interfaces
The MME supports a maximum of 100 Sm interfaces.
Several parameters are used to ensure the proper operation of the MBMS service:
MBMS Enabled: The MBMS service is enabled independently from provisioning

of the Sm and M3 interfaces. The service is enabled or disabled at the MME on a
per-PLMN basis. When the service is disabled on a PLMN, all messages for the
corresponding PLMN received over the Sm and M3 interfaces are
ignored/dropped.
MBMS Response from MCE: indicates the time the MME should wait for a
response from an MCE before declaring it is late.
Min Time to MBMS Data Transfer: indicates the minimum time to allow for data
transfer to the MCE.
Parameter
MBMS Enabled
SAM Table Name
OSS ID
ltemme.MMEPLMN.mBMS_Enabled
Range & Unit
Boolean
Impact of Change
No service impact.
Value
Operator Dependent; default = Disabled

(do not transmit MBMS requests)
Parameter
MBMS Response from MCE
SAM Table Name
Timer
OSS ID
timerName
Choice List
MBMS_Response_from_MCE
Range & Unit
timerUnit
timerName)
seconds
timerValue
Integer
[1..30] sec
Issue 11.01
Impact of Change
No service impact.
Value
LTE/DCL/APP/031094
Nokia 2016
384 / 652
Parameter
SAM Table Name
OSS ID
Min Time to MBMS Data Transfer

Timer
timerName
Choice List
Min_Time_to_MBMS_Data_Transfer
Range & Unit
timerUnit
timerName)
seconds
timerValue
Integer
[1..60] sec
Impact of Change
No service impact.
Value
8.1.8 MULTIMEDIA PRIORITY SERVICE (MPS)

The enhanced multimedia priority services provides UE priority access for public safety
users during overload conditions. This gives government-authorized personnel,
emergency management officials and/or other authorized users priority access to
system resources during periods of congestion. Priority access is based on configurable
ARP ranges and can be enabled or disabled on a per-PLMN basis.
A service provider can provide priority treatment to public safety personnel whose UEs
are assigned ARP high priority values and whose UEs hold high priority access codes.
Sessions initiated by these UEs with high priority access will be given high priority
treatment in the MME, specifically during the MME overload scenarios.
In the rare event that an MME is experiencing overload conditions, sessions for UEs
with high priority access are established and maintained during overload. The MME will
attempt to not shed messages related to high priority UE bearers during the MME
overload, but sustainability of the MME is the highest priority.
MPS supports both UE-initiated priority access and network-initiated priority access. A
user can be assigned one of 15 priority access levels. The MME provides a
provisionable parameter for the operator to specify the ARP High Priority Levels that are
allowed high priority access treatment locally at that MME during overload conditions at
the MME. (Please refer to Section 8.2.3.1.)
MPS is supported for all the shared PLMNs. The MME provides a provisioning option to
activate multimedia priority services per shared PLMN basis. A UE does not get priority
treatment if MPS is not activated for the serving PLMN of the UE. The MME allows
separate provisioning of ARP values for each PLMN.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
385 / 652
8.1.8.1
Determining High Priority Access
The MME uses the following criteria to determine whether a UE bearer has been
granted high priority access treatment during MME overload conditions:
The highPriorityAccess indication in the RRC Establishment Cause parameter of the
Initial UE message sent to the MME by the eNB and presence of MPS-priority AVP
with MPS-EPS-Priority bit and/or MPS-CS-Priority in the UE subscriber data. The
highPriorityAccess indication in the RRC Establishment Cause is set by the UE based
on the access classes stored in its USIM. The MME uses these indications for initial
determination of priority treatment for received Initial UE messages.
The value of the ARP Priority Level field (part of the QoS sent by the HSS/PCRF) is
used to determine whether a UE bearer is given high priority treatment during overload
conditions. It is compared to the locally provisioned ARP High Priority Level parameter
to see if this UE is granted high priority treatment at this MME.
The ARP Priority Level field received in the S11 Downlink Data Notification message
is compared to locally provisioned ARP value to determine whether paging for the UE is
granted high priority treatment during MME overload conditions.
If the MME receives a SGsAP-PAGING-REQUEST message with eMLPP Priority IE
for a UE, irrespective of the UE marking as a high priority UE, the MME provides priority
treatment to the message. The MME sets the Paging Priority IE of the S1AP Paging
message with the provisioned paging priority for eMLPP priority for the UE HPLMN. The
MME also sets the "CS Fallback Indicator" IE to "CS Fallback High Priority". The MME
also provides high priority treatment (that is, sets the "CS Fallback Indicator" IE to "CS
Fallback High Priority") for subsequent ESR messages from the UE within the paging
response timer, irrespective of whether the UE is set for high priority treatment. If
eMLPP priority is not received in SGsAP-PAGING-REQUEST, the MME uses
provisioned Paging Priority for CSFB. If for any reason the MME pages a UE with IMSI,
the MME will not support priority paging. The MME provides the same paging treatment
for both CS call indication and SMS indication.
For a UE ESR, the MME determines that the CSFB request needs priority handling
based on the MPS CS Priority stored in UE's EPS subscription. The MME provides
preferential treatment to this request and also sets priority indication, "CSFB High
Priority", in S1AP message to eNodeB to initiate CSFB procedure with priority. This
applies to both 1xRTT calls and 3GPP CSFB calls.
The MME uses the Initial UE RRC Establishment Cause value of highPriorityAccess
and MPS-EPS-Priority indication (based on either MPS-CS-Priority bit or MPS-EPSPriority bit) as an indication that the UE should receive high priority access treatment
initially.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
386 / 652
8.1.8.2
Roaming
Roamers are given high priority access as defined locally in the visited MME, based on
the per PLMN provisioning to provide priority access or not. Also, the MME determines
high priority access for the following handovers:
Inter-MME S1 Handover with or without SGWrelocation
Intra-MME S1 Handover with or without SGWrelocation
X2 Handover
IRAT HO
SRVCC
Best effort is provided to establish and maintain sessions for UEs identified as high
priority access through any proactive or deliberate action taken to avoid or relieve
overload on the MME.
8.1.8.3
Provisioned Parameters
The MME allows separate provisioning of MPS values for each PLMN. MPS CS priority
and MPS EPS priority can be enabled/disabled per-PLMN. (See below.)
ARP High Priority Access Level - indicates the largest ARP value that can be
assigned to a High Priority Access user. The ARP priority level value received in
the DDN message is compared to this provisioned value. If it is equal to or less
than this provisioned value, the paging is given high priority treatment during
MME overload conditions. (Please refer to Section 8.2.3.1.)
Paging Priority level for a high priority user - the MME provides provisioning of
paging priority level (1 to 8) for an ARP priority level to be used for a UE marked
as a high priority user. The paging priority is sent to eNB in paging message if
ARP is received in DDN message. The MME does not send the paging priority if
no paging priority is provisioned for an ARP priority level.
Paging Priority level for other than high priority user (no-eMLPP) The CSFB
Paging Priority Profile No-eMLPP Paging Priority Level parameter is used when
the SGs-AP paging request message does not contain an eMLPP value.
Different paging priority profiles can be provisioned per eMLPP field.
Parameter
MPS CS Allowed
SAM Table Name
UE PLMN Services,
OSS ID
ltemme.UEPLMNServices.mPSCSAllowed
ltemme.SVCAgreementProfile.mPSCSAllowed
Range & Unit
Boolean
Yes or No
Issue 11.01
Impact of Change
No service impact.
Value
LTE/DCL/APP/031094
Nokia 2016
387 / 652
Parameter
MPS EPS Allowed
SAM Table Name
UE PLMN Services,
OSS ID
ltemme.UEPLMNServices.mPSEPSAllowed
ltemme.SVCAgreementProfile.mPSEPSAllowed
Range & Unit
Boolean
Yes or No
Impact of Change
No service impact.
Value
Parameter
Paging Priority Level
SAM Table Name
CSFB eMLPP Paging Priority Profile
OSS ID
ltemme.CSFBeMLPPPagPriProfile.PagingPriLevel
Range & Unit
Integer
[0..8]
Impact of Change
No service impact.
Value
Parameter
No-eMLPP Paging Priority Level
SAM Table Name
CSFB Paging Priority Profile
OSS ID
ltemme.CSFBPagingPriProfile.noeMLPPPagingPriLevel
Range & Unit
Choice List
Issue 11.01
Impact of Change
No service impact.
Value
Operator Dependent; default = none
LTE/DCL/APP/031094
Nokia 2016
388 / 652
8.1.9 HOME ENODEB
HeNB is a Femto cell, connected to an existing broadband network providing LTE radio
coverage within a home.
A HeNB can be directly connected to the MME or via HeNB Gateway. The overall
architecture with deployed HeNB GW is shown in the following:
The following graphic shows the eUTRAN architecture with deployed HeNBs.
Figure 8-22: eUTRAN architecture with deployed HeNB gateway

The HeNB GW appears to the MME as an eNB.
The HeNB GW appears to the HeNB as an MME. The S1 interface between the HeNB
and the EPC is the same, regardless whether the HeNB is connected to the EPC via a
HeNB GW or not.
To distinguish between macro eNBs and HeNBs, a 28bit global ID is used for HeNBs.
When an HeNB connects directly to MME, the HeNB sends 28bit global HeNB ID in
the Global eNB ID IE of the S1AP SETUP REQUEST message. The MME stores the
global ID in UE context data for sending HO request and paging messages to the target
eNB and also for coding of target ID for type HeNB in S10 Forward Request message.
Issue 11.01
IE/ Group Name
IE type and reference
Description
Macro eNB ID
BIT STRING (20)
Equal to the 20 leftmost bits of the Cell Identity

IE contained in the E-UTRAN CGI IE of each
cell served by the eNB
Home eNB ID
BIT STRING (28)
Equal to the Cell Identity IE contained in the EUTRAN CGI IE of the cell served by the eNB
LTE/DCL/APP/031094
Nokia 2016
389 / 652
8.1.9.1
X2 support
X2 support is for different combinations of HeNB connectivity is as follows:
Between HeNB and macro eNB directly connected to the same MME
Between HeNB connected to a HeNB GW and macro eNB to the same MME
Between HeNB directly connected to MME and HeNB connected via HeNB GW
to the same MME
Between two HeNBs connected to the same HeNB GW connected to the same
MME
Between two HeNB connected to different HeNB GW connected to the same

MME
8.1.9.2
S1 HO SUPPORT
S1 HO is supported for the following scenarios:
Between an HeNB and a macro eNB connected directly to an MME with and
without MME relocation
Between an HeNB connected to a HeNB GW and macro eNB with and without
MME relocation
Between an HeNB connected directly to an MME and HeNB connected via

HeNB GW with and without MME relocation
Between two HeNBs connected to the same HeNB GW
MME relocation is not supported in this scenario; it is assumed that all HeNBs
under the HeNB will be connected to the same MME.
Between two HeNBs connected to different a HeNB GW with and without MME
relocation.
Note: When a HeNB gateway is implemented, multiple S1-MME connections,

each defining a virtual gateway can be established with the MME using a single
IP address.
MME supports some operatorss use of 20 bit HeNB IDs of HeNB connected via GW.
Basically, MME supports routing of S1AP messages based on TAI for target eNBs with
20-bit identifier that is not directly connected with MME.
If target ID received in S1AP HANDOVER REQUIRED (or S10/S3/Gn Forward

Relocation Request) message is a 20 bit eNB ID then MME first determines
whether the target eNB is directly connected to the MME or not
If the eNB is directly connected then MME would send the S1AP HANDOVER
REQUEST message to the eNB.
If the eNB is not directly connected then MME would send the S1AP HANDOVER
REQUEST message to the HeNB GW with TAI matching with the target TAI received in
the S1AP HANDOVER REQUIRED message (or in the S10/S3/Gn Forward Relocation
Request message). The HeNB GW forwards the message to the target HeNB using the
target eNB info in the Target to Source Container IE of the S1AP HANDOVER
REQUEST message.
Issue 11.01
The selection of the target HeNB GW based on the TAI
LTE/DCL/APP/031094
Nokia 2016
390 / 652
imposes a restriction that TAI assigned to HeNB GW must be distinct to enable sending
of the HO messages to one and only one HeNB GW. If there is no TAI matching the
target TAI then MME rejects the HO required message.
For eNBs with 20bit eNB ID (macro eNBs), the global parameter 20-bit-HeNB-ID
enables support of routing of S1AP HO messages based on target TAI when the eNB is
not directly connected with the MME :
Parameter
20-bit-HeNB-ID
SAM Table Name
Global Parameters
OSS ID
Range & Unit
Boolean
Yes or No
Impact of Change
No service impact.
Value
Feature
m14003-01
8.1.9.3
HO with S4 SGSN and Gn/Gp SGSN interactions
If the target ID received in the S1AP HANDOVER REQUIRED (or S10/S3/Gn Forward
Relocation Request) message is an HeNB, the MME first determines whether the target
HeNB is directly connected to the MME or not.
If the HeNB is directly connected, the MME sends the S1AP HANDOVER REQUEST
message to the HeNB. If the HeNB is not directly connected, the MME sends the S1AP
HANDOVER REQUEST message to the HeNB GW with TAI matching with the target
TAI received in the S1AP HANDOVER REQUIRED message (or in the S10/S3/Gn
Forward Relocation Request message).
The HeNB GW forwards the message to the target HeNB using the target eNB info in
the Target to Source Container IE of the S1AP HANDOVER REQUEST message.
The selection of the target HeNB GW based on the TAI imposes a restriction that TAI
assigned to HeNB GW must be distinct to enable sending of the HO messages to one
and only one HeNB GW.
8.1.9.4
Closed Subscriber Group (CSG) access restrictions
for HO scenarios
Closed Subscriber Groups (CSGs) are used to restrict subscriber (UE) access to one
more cells of the PLMN. CSG access restriction uses the CSG Identity that is assigned
to a CSG HeNB. For all the HO scenarios, the MME performs Closed Subscriber Group
(CSG) access restrictions and may reject HO to target eNB ID.
The MME imposes access restrictions based on the following information received from
the Home Subscriber Server (HSS) and eNB:
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
391 / 652
CSG subscription data (CSG-Subscription-Data AVP) of the UE subscription

data received from HSS. CSG ID association with a PLMN is not supported.
The MME considers the CSG membership from HSS as applicable in VPLMN
until CSG membership in a PLMN is supported.
CSG ID and Cell Access Mode IEs in the following S1AP messages
-
INITIAL UE MESSAGE
HANDOVER REQUIRED
PATH SWITCH REQUEST
CSG IDs supported by the HeNB is also sent in the S1 SETUP message and changes
to CSDG ID list is sent in ENB CONFIGURATION message. This CSG ID list is used by
MME to filter paging messages if configurable CSG paging optimization in MME is
activated. The MME supports a maximum of 256 CSG IDs per eNB and four (4) CSG
IDs per subscriber. If configurable CSG paging optimization is activated in HeNB, the
MME includes the UE valid and expired CSG ID in the CSG ID list of the S1AP paging
message.
8.1.9.5
Impact to MME procedures
Cell access mode indicates to the MME whether the cell is a CSG cell or a hybrid cell. A
CSG cell provides access only to members of the CSG ID supported by the CSG cell. A
hybrid cell acts like a CSG cell for the members of CSG ID and at the same provide
access to all other UEs. A hybrid cell can provide preferential treatment to members of
CSG. An open cell provides access to all the UEs. MME CSG member verification and
access control is provided for all the MM procedures.
8.1.10 ATTACH REQUEST

If the initial Attach request is received from a CSG cell, the MME uses CSG subscription
data received from the HSS and CSG ID info received in the S1AP INITIAL UE
MESSAGE to determine if the UE is subscribed to the CSG of the cell and if subscribed,
if membership has expired. If the UE is not subscribed or membership has expired, the
MME rejects the Attach Request with EMM cause Not authorized for this CSG (cause
value #25) or provisioned cause code if a cause code is provisioned.
For emergency attach requests, the MME does not perform CSG restriction checks. If
the initial Attach is received from a hybrid cell, the MME sends CSG Membership status
to the eNB regardless of the CSG membership status in INITIAL CONTEXT REQUEST
message.
8.1.11 TAU REQUEST

If the UE initiates the TAU procedure at a CSG cell, the new MME checks whether the
CSG ID and associated PLMN is contained in the CSG subscription and is not expired.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
392 / 652
If the CSG ID is not present or expired, the MME sends a Tracking Area Update reject
message to the UE EMM cause Not authorized for this CSG (cause value #25) or a
provisioned cause value if a cause code is provisioned.
If the initial TAU request is received from a hybrid cell and the active flag is set, the
MME sends CSG Membership status to the eNB in the INITIAL CONTEXT REQUEST
message, regardless of the CSG membership status.
8.1.12 SERVICE REQUEST

If the UE initiates the service request procedure at a CSG cell, the MME checks
whether the CSG ID and associated PLMN is contained in the CSG subscription and is
not expired. If the CSG ID is not present or expired, the MME sends a Service Reject
message to the UE EMM cause Not authorized for this CSG (cause value #25) or a
provisioned cause value.
If the service request is received from a hybrid cell , MME sends CSG Membership
status to the eNB in INITIAL CONTEXT REQUEST message regardless of CSG
membership status.
8.1.13 PAGING OPTIMIZATION

Paging optimization enables the filtering of paging messages to avoid distribution to
CSG cells where the UE is not registered.
The following global parameters control CSG paging optimization:
Parameter
Paging Optimization in HeNB
SAM Table Name
Global Parameters
OSS ID
Range & Unit
Boolean
Yes or No
Impact of Change
No service impact.
Value
Parameter
Paging Optimization in MME
SAM Table Name
Global Parameters
OSS ID
Range & Unit
Boolean
Yes or No
Issue 11.01
Impact of Change
No service impact.
Value
LTE/DCL/APP/031094
Nokia 2016
393 / 652
If CSG paging optimization is activated in the MME, the MME does not send paging
message to CSG cells that are not in UEs subscriber data; this setting applies to all the
paging policies.
If the CSG paging optimization is activated for the HeNB, the MME includes the list of
CSG IDs from the UE CSG subscription data in paging message for all the macro eNBs
including the HeNB GW. The MME includes both expired CSG IDs and valid CSG IDs
in the CGS ID list. For security reasons, the CSG ID list is never included for directlyconnected HeNBs.
Paging optimization is not used for UEs with emergency bearers. Paging optimization
includes paging triggers due to HSS, Downlink Data Notification (DDN), and
SGsinterface to an MSC/VLR.
8.1.14 DETACH PROCEDURE

If the MME receives a Detach Request via a CSG cell with Switch Off parameter
indicating that detach is not due to a switch off situation, and the CSG subscription for
this CSG ID is absent or expired, the MME triggers a MME-initiated Detach
procedure.In this case, MME sends cause code #25 to UE indicating that UE is not
authorized for this CSG.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
394 / 652
8.1.15 X2 HANDOVER
X2 HO is possible only between closed/hybrid HeNBs with the same CSG ID or if the
target eNB is an open access eNB. However, the MME supports checks on the CSG ID
received in the S1AP PATH SWITCH REQUEST message and takes action as follows:
Case 1: Target cell is a CSG cell and UE does not have any emergency
bearers If the target CSG ID received in the PATH SWITCH REQUEST
message is not in the UE's CSG subscription data or subscription has expired,
the MME rejects the PATH SWITCH REQUEST by sending PATH SWITCH
FAILURE with an indication that UE is not allowed to the CSG. If the UE has
emergency bearers, the MME deactivates all other bearers except for the
emergency bearer.
Case 2: Target cell is a hybrid cell.
The MME does not perform any access restriction, but after sending the PATH
SWITCH ACK, the MME sends S1AP UE CONTEXT MODIFICATION message
if UE membership status is changed.
Case 3: Open access HeNB
Currently X2HO between the macro eNB and the HeNB from one vendor connected to
a HeNB GW from a different vendor is not supported.
The following diagram shows the gaps in supporting X2HO:
Figure 8-23 X2 HO between HeNBs and enodeB
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
395 / 652
-
The Macro eND sends uplink data packets directly to SGW based on SGW
Uplink GTP Tunnel Endpoint
HeNB sends UL data packets to HeNB-GW
HeNB-GW converts HeNB-GW Uplink GTP Tunnel Endpoint to SGW UL GTP

TE and forward the uplink data poackets to SGW.
Issue with Uplink GTP Tunnel during X2 hand over from a source Macro eNB to
an Indoor Metrocell and vice versa :
Case 1 : The Metrocell needs to know the HeNB-GW uplink GTP TE
Case 2 : The Macro eNB needs to know the SGW uplink GTP TE.
The MME can be configured to support X2HO between the macro eNB and the HeNB
connected to a HeNB GW by including the Uplink GTP Tunnel IDs in the S1AP Path
Switch Request Acknowledge message ( e-RAB to be switched in Uplink list IE ),
irrespective of the SGW relocation.
Basically, during X2 HO between the macro eNB and the HeNB the IE is used by the
HeNb GW to set up mapping between SGW Uplink GTP Tunnel Endpoint (UL GTP TE)
and the HeNb GW UL GTP TE to forward the S1-U traffic.
In the second case where the macro eNB needs to know the SGW UL GTP TE , the
macro eNB overwrites the UL GTP TE received from the HeNB GW with the Ul GTP TE
received in the S1AP S1AP PATH SWITCH REQUEST ACKNOWLEDGE message
The global parameter X2 HO Include_SGW_UL controlled the SGWUL Teid to be
included in Path Switch Request Acknowledgement message.
If X2 HO Include_SGW_UL is set to yes, the Path Switch Request Acknowlegement
will include the Sgw UL Teid for the bearers that successfully switched.
Parameter
X2 HO Include SGW UL
SAM Table Name
Global Parameters
OSS ID
Range & Unit
Boolean
Yes or No
Issue 11.01
Impact of Change
No service impact.
Value
Feature
m14002-01
LTE/DCL/APP/031094
Nokia 2016
396 / 652
8.1.16 S1 HO
In S1 HO scenarios, the source MME performs CSG access controls. The source MME
checks the UE's CSG subscription when the CSG ID is provided by the source eNodeB
in the S1AP HANDOVER REQUIRED message. If there is no subscription data for this
CSG
ID, the
source MME rejects
the
handover
by sending
HANDOVER
PREPARATION FAILURE with cause value invalid CSG ID

If the CSG subscription is expired, and the target cell is a CSG cell, the source MME
rejects the handover by sending HANDOVER PREPARATION FAILURE with cause
value CSG subscription expiry. Additionally, the source MME includes the CSG ID in
the Forward Relocation Request when the target cell is a CSG or hybrid cell. If the
target cell is a hybrid cell, or if there are one or several emergency bearers and the
target cell is a CSG cell, the CSG Membership Indication indicating whether the UE is a
CSG member is also included in the Forward Relocation Request message. The target
MME (or the source MME if there is no MME relocation) takes the following actions to
support CSG:
The target MME includes CSG ID IE and CSG Membership Indication IE in the S1AP
HANDOVER REQUEST message if received in the Forward Relocation Request
message.
If the target eNB sends HANDOVER FAILURE message with cause invalid CSG ID,
MME sends Forward Relocation Response with cause Denied in RAT to the source
MME. The target MME includes User CSG Information if the PGW has requested it and
if the configuration flag Support CSG Change Reporting is set in Create Session
Request message or in Modify Bearer Request.
Parameter
SAM Table Name
Support CSG Change Reporting

Global Parameters
OSS ID
Range & Unit
Boolean
Yes or No
Impact of Change
No service impact.
Value
8.1.17 IRAT HO
Only the exchange of CSG related IEs on the S3 interface is supported. The actions
taken by source and target MMEs are identical to S1 HO, except for the use of S10
messages.
In this case, S3 messages are used between the MME and SGSN. HO proceeds only if
the Gn interface is involved with IRAT mobility (HO or TAU), in spite of lack of CSG
related information.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
397 / 652
8.1.18 LIPA ARCHITECTURE
The LIPA feature enables an LTE UE that is connected via an HeNB to access other IPcapable entities (for example, the Internet) in the same residential/enterprise IP
network, without the user plane mobile operators core network. The local IP access is
achieved by using a Local GW (L-GW) collocated with the HeNB.
F
igure 8-24: LIPA Architecture.
A UE is allowed or prohibited LIPA for an APN at a cell is provided by LIPA-Permission
AVP in APN Configuration AVP in UE subscription data and Service-Selection AVP of
CSG subscription data.
If a subscriber is roaming, the VPLMN-LIPA-Allowed AVP in UE subscriber data
indicates to MME to allow or prohibit LIPA in VPLMN where the UE is attached.
Additionally, the MME supports an option of overriding VPLMN LIPA allowed
subscription data. This override is supported for each PLMN in the roaming agreement
table. The MME selection of PGW in core network or a local GW at the eNB is based on
the eNB indication of support LIPA and user subscription data. To indicate to the MME
that it supports LIPA, the eNB includes the GW Transport Layer
Address IE in the S1AP INITIAL UE MESSAGE and S1AP UPLINK NAS TRANSPORT
message. This address is the L-GWs S5 control plane address. If this indication is
included in either message, the MME verifies CSG subscription data to allow LIPA
access. If LIPA-Permission for an APN indicates LIPA-ONLY, the MME allows LIPA for
that APN via authorized CSG according to the CSG subscription data. If LIPAPermission for an APN indicates LIPA-CONDITIONAL, the MME allows non LIPA
access if eNB does not support LIPA access or for certain causes of L-GW create
session failures.
If the eNB supports LIPA, the MME allows LIPA via the authorized CSG cells according
to the CSG subscription data. If the LIPA-Permission for an APN indicates LIPAPROHIBITED, the MME does not allow LIPA access for the APN. If the LIPAPermission AVP is not present for a specific APN, the MME does not allow LIPA access
for the APN. Once the MME selects LIPA, the MME sends S11 Create Session Request
message with PGW S5/S8 Address for Control Plane IE set to the GW Transport Layer
Address IE in the S1AP INITIAL UE MESSAGE and S1AP UPLINK NAS TRANSPORT
message.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
398 / 652
The S5/S8-U PGW FTEID IE of the S11 Create Session Response is the S5-U address
of the L-GW and this address is sent in INITIAL CONTEXT SETUP REQUEST or in
E_RAB SETUP REQUEST to eNB to establish direct user path to LGW.
8.1.18.1
LIPA mobility
Mobility of LIPA connection is not supported. A LIPA PDN connection is released when
a UE moves way from an eNB that is providing LIPA. The LIPA PDN connection
isreleased as follows for HO:
eNB determines that UE has a LIPA PDN by the presence of Correlation ID in

the UE E-RAB context
eNB requests collocated L-GW to release the PDN connection using intra-node
signaling
L-GW then initiates release of PDN connection using the PGW initiated bearer
deactivation procedure as described in clause 5.4.4.1 of TS 23.401.
At the handover, the source MME checks whether the LIPA PDN connection has been
released. If the connection has not yet been released, the MME proceeds as follows:
If the handover is the S1-based handover or the Inter-RAT handover, the

source MME rejects the handover by sending S1AP HANDOVER
PREPARATION FAILURE message with transport/unspecifiedcause value.
If the handover is X2-based handover, the MME sends the PATH SWIATCH
FAILURE message with transport/unspecified cause value and detaches the
UE with reattach required with cause #17 (Network failure).
8.1.18.2
Impact to the idle mode TAU procedure
The source MME releases any LIPA PDN connections by sending Delete Session
Request if a UE has moved from the LIPA-enabled eNB.
The MME considers that the has UE moved to a different eNB if one of the following
conditions is fullfiled:
the S1AP INITIAL UE message does not contain GW Transport Layer Address
IE
the GW Transport Layer Address IE received in the S1AP INITIAL UE

MESSAGE does not match with current GW Transport Layer Address.
If the UE does not have any other PDN connection, the MME detaches the UE with
reattach required using cause # 40 (No EPS bearer context activated). For MME
relocation scenarios, the source MME sends IMSI not known in the S10 Context
Response message.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
399 / 652
8.1.19 GUTI REALLOCATION PROCEDURE
The Globally Unique Temporary Identifier (GUTI) reallocation procedure allocates a
GUTI and optionally provides a new TAI list to a particular UE. This procedure can only
be initiated by the MME when EMM state is EMM-REGISTERED. EMM does not
support standalone GUTI reallocation. GUTI reallocation is usually executed in
conjunction with another procedure.
IEs within the ATTACH ACCEPT and TAU ACCEPT message allow the MME to send a
new GUTI to the UE.
The Public Land Mobile Network (PLMN) identity in the GUTI indicates the current
registered PLMN.
This GUTI Reallocation parameter indicates the percentage of cases in which a GUTI
Reallocation is invoked for the following procedures:
Subsequent Attach
TA Update
UE Initiated Service Request
UE Initiated Extended Service Request
UE Initiated Detach without switch-off
IRAT TA Update
Note: a procedure is selected and then a GUTI Reallocation (see below) and
Authentication Interaction (Section 8.1.20) value are assigned.
Parameter
Procedure Name
SAM Table Name
PLMN Security
OSS ID
Lte.PLMNSecurityAbs.procedureName
Range & Unit
Choice List
SubAttach
TAUpdate
ServiceReq
UEInitDetach
UEInitExtSrvreq
IRAT TA Update
Issue 11.01
Impact of Change
No service impact.
Value
No default.
LTE/DCL/APP/031094
Nokia 2016
400 / 652
Parameter
GUTI Reallocation (%)
SAM Table Name
PLMN Security ProcedureName (Edit)
OSS ID
Lte.PLMNSecurityAbs.gUTIReallocation
Range & Unit
Integer
[0..100]
Impact of Change
No service impact.
Operator Dependent; default varies by procedure (see table
Value
below).
Authentication
Procedure
Interaction %
GUTI Reallocation %
Subsequent Attach
20
20
TA Update
10
20
UE Initiated Detach without Switch-Off
20
IRAT TA Update
10
100
Table 10: PLMN Security Procedure Defaults
The MME must perfom GUTI reallocation to associate the UE to the new MME in all MME relocation cases.
Therefore, the GUTI Reallocation % for IRAT TA Update procedure is 100% and cannot be changed via
provisioning.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
401 / 652
8.1.20 DIRECTED INTER-MME UE MOVE
Directed Inter-MME UE Move refers to scenarios where an inter-system move operation
is invoked with a Target MME code specified. The operator must provision the nonbroadcast TAI with a tracking area code that is not used anywhere within the MME
pools coverage area. This fake TAI is included as the TAI list in the GUTI Reallocation
message, which causes the subject UE to perform a Tracking Area Update immediately
upon being released by the Source MME.

Figure 8-25: Procedure Dual Receiver UE Suspend when Performing LTE to 1xRTT
Cell Reselection
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
402 / 652
Legend:
Step
Description
When performing a Directed inter-MME UE Move procedure, for each UE selected

for the move by the Source MME, if the selected UE is in ECM-IDLE state, the
Source MME first pages the UE to bring it to the ECM-CONNECTED state.
When the UE is in ECM-CONNECTED state (or has transitioned to the ECMCONNECTED state after being paged), the source MME generates a special
MTMSI value with the following properties:
-
it is not in conflict with any normal MTMSI value that can be generated
by an MME for a normal GUTI assignment
it include some encoding of the Source MMEs MME Code value.
includes some indication that can be recognized by the Target MME

that this is a Directed inter-MME UE Move procedure
The Source MME sends a GUTI Reallocation Command NAS message to the
UE. The new GUTI contains the PLMN, MME Group Id, and MME Code of the
Target MME, and the special MTMSI generated as specified above. The TAI list
contains a single entry, which is the provisioned non-broadcast TAI.
During a Directed inter-MME UE Move procedure, upon receiving the GUTI

Reallocation Complete NAS message from the selected UE, the Source MME
sends UE Context Release Command to the serving eNB, with s1ap cause set
to Miscellaneous/O&M Intervention.
After being released by the Source MME, the UE immediately reconnects (either
to the same eNB or a different eNB) and performs a TAU which should be
directed to the Target MME based on the GUTI that had been sent to it. The
special MTMSI value enables the Target MME to recognize the TAU as being
part of a Directed inter-MME UE Move procedure.
When the MME receives a TAU Request from a UE, and the GUTI contains the
MMEs group and code and an MTMSI value which matches the special MTMSI
format, the MME handles the TAU request as the Target MME of a Directed
inter-MME UE Move procedure.
When the MME receives a TAU Request from a UE, and the GUTI contains the
MMEs group and code and an MTMSI value which matches the special MTMSI
format, the MME handles the TAU request as the Target MME of a Directed
inter-MME UE Move procedure.
The Target MME sends the Identity Request NAS message to the UE to obtain
the UEs IMSI . The use of the special MTMSI format to indicate the proprietary
procedure does not leave much flexibility for using the MTMSI in the normal way
for routing the context request at the Source MME. Retrieving the IMSI from the
UE directly in this case gets around that problem. The Target MME extracts the
source MMEs code from the special MTMSI, and since the directed intersystem UE move is limited to a single MME pool, the MME Group ID of the
Source MME is the same as the Target MMEs Group Id.
When the Target MME receives the Identity Response message from the UE
with an IMSI, the Target MME sends S10 Context Request to the Source MME,
containing the IMSI (not the GUTI). The target MME does not perform any
authentication at this point.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
403 / 652
Step
Description
10
When the Target MME receives the Context Response from the source MME,
the Target MME continues the procedure following the normal S10 TAU MME
Relocation.
Note: The special parts of the Directed Inter-MME UE Move procedure are the
initial steps that trigger the move and allow the Source and Target MMEs to
communicate.
Once the UE context can be transferred from Source to Target, the remainder of
the procedure follows the normal TAU with S10 MME relocation. The normal
TAU with S10 MME Relocation may involve authentication handling at the
Target MME after the Context Response has been received.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
404 / 652
8.1.21 AUTHENTICATION
PROCEDURE
AND
KEY
AGREEMENT
(AKA)
The MME uses the ePS Authentication and Key Agreement (ePS-AKA) protocol for
authentication between UE and ePS. ePS-AKA provides mutual authentication between
the user and the network and provides agreement on a key KASME.
The AKA is a challenge-response-based mechanism that uses symmetric cryptography.
AKA is run in the MME as well as in the Universal Subscriber Identity Module (USIM) in
the UMTS IC Card (UICC) in the UE. A shared secret key is stored in both the USIM of
the UE and in the Authentication Center (AuC) located within the Home Subscriber
Server (HSS). The MME initiates Authentication Information Request to the AuC in the
HSS as soon as the UE IMSI is known. After the AKA procedure has completed
successfully, the UE and the MME store the same EPS Security Context with the UE
security capabilities and KSIASME and KASME. A detailed description of the AKA protocol
and parameters for e-UTRAN can be found in 3GPP TS 33.401 and references therein.
The AKA procedure is shown in the figure below, where:
-
The network initiates the authentication procedure by sending an

AUTHENTICATION REQUEST message to the UE and starting the timer
T3460.
The UE processes the authentication challenge data and responds with an

AUTHENTICATION RESPONSE message to the network.
Upon a successful ePS authentication challenge, the new KASME calculated from the
authentication challenge data is stored in a new ePS security context in the volatile
memory of the MME and the network stops the timer T3460.
If the MME receives an AUTHENTICATION FAILURE, the network stops the timer
T3460 and the MME sends an AUTHENTICATION REJECT to the UE. Depending on
the failure reason, the AKA procedure may be re-initiated.
UE
MME
Authentication Request
Authentication Response
or
Authentication Failure
Authentication Reject
Start T3460
Stop T3460
If authentication
failed
Figure 8-26: AKA Procedure
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
405 / 652
The MME can also initiate ePS-AKA:
during Tracking Area Update (TAU), Service Request, or Handover
randomly during subsequent Attach procedures
when the NAS COUNT is close to wrap around. 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 3octet count is initialized at 0 and wraps around when it is in the range of [(224 1000), 224].
Please refer to Section 0 for information regarding the T3460 timer.

The MME supports a provisionable Authentication Interaction parameter that indicates
the percentage of cases in which an Authentication Interaction is invoked for the
following procedures:
Subsequent Attach
TA Update
UE Initiated Detach without switch-off

Parameter
Authentication Interaction
SAM Table Name
PLMN Security ProcedureName (Edit)
OSS ID
ltemme.PLMNSecurityAbs.authInteraction
Range & Unit
Integer
[0..100] percent
Impact of Change
No service impact.
Value
Operator Dependent; default varies by procedure (see

table below).
Procedure
Authentication Interaction %
Subsequent Attach
TA Update
UE Initiated Detach without Switch-Off
IRAT TA Update
20
10
0
0
20
10
Table 11: Authentication Interaction Defaults
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
406 / 652
8.1.22 EMM INFORMATION PROCEDURE
The EMM INFORMATION message allows the MME to provide certain MME
information to the UE. The UE may use the received information if the UE supports
implementing this message.
The MME sends an EMM information message to the UE immediately after:
Receiving Attach Complete and sending TAU Accept messages (in the case of
no GUTI reallocation).
Receiving TAU Complete (in the case of GUTI allocation).
The message is sent for both idle mode and connected mode TAU procedures.
Information in the EMMINFO message is based on provisioning of the EMM
INFORMATION view and also the eNB view. If an eNB is provisioned in a different
timezone then the MME, then the information in the EMMINFO message will contain the
eNB's timezone, not the MMEs. The provisionable (send/do not send) content of the
EMM Information message is as follows:
Time Zone (includes Local time zone, Universal time zone, local time, and
network daylight savings time).
Network name (Full Network Name or Short Network Name).
Country initials.
Name encoding.
Sending of the EMM Information message is dependent upon the provisioning of the
Time Zone and Network Name as indicated in the following table.
Send
Network
Name = True
Send Time Zone

Offset = True
EMM
Information
Message is Sent
Yes
Yes
Yes
Yes
No
Yes
No
Yes
Yes
No
No
No
Table 12: Provisioning for Sending EMM Information Message
The MME can be provisioned to send network and time zone information when the
MME initiates an EMM information procedure. The EMM Information message is not
sent if the Send Network Name field and the Send Time Zone Offset field are set to
False (do not send).
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
407 / 652
Parameter
Send Network Name
SAM Table Name
EPS Mobility Management Information (EMM)
OSS ID
ltemme.EMMInforAbs.sendNetworkName
Range & Unit
Boolean
Impact of Change
No service impact.
Value
Operator Dependent; default = False (do not send)
Parameter
Send Country Init
SAM Table Name
OSS ID
ltemme.EMMInforAbs.sendCountryInit
Range & Unit
Boolean
Impact of Change
No service impact.
Value
Operator Dependent; default = False (do not display)
Parameter
Network Name
SAM Table Name
OSS ID
ltemme.EMMInforAbs.networkName
Range & Unit
3 - 64 ascii characters from the following sets:

[A..Z], [a..z], [0..9], [ - . : _], and the space character.
Impact of Change
No service impact.
Value
Parameter
Network Short Name
SAM Table Name
OSS ID
ltemme.EMMInforAbs.networkShortName
Range & Unit
3 - 32 ascii characters from the following sets:

[A..Z], [a..z], [0..9], [ - . : _], and the space character.
Issue 11.01
Impact of Change
No service impact.
Value
LTE/DCL/APP/031094
Nokia 2016
408 / 652
Parameter
Send Time Zone Offset
SAM Table Name
OSS ID
ltemme.EMMInforAbs.sendTZOffSet
Range & Unit
Boolean
Impact of Change
No service impact.
Value
Operator Dependent; default = False (do not send)
Parameter
Encoding Name
SAM Table Name
OSS ID
ltemme.EMMInforAbs.encodingName
Range & Unit
Choice List
GSM default alphabet, UCS2
Issue 11.01
Impact of Change
No service impact.
Value
Operator Dependent; default = GSM default alphabet
LTE/DCL/APP/031094
Nokia 2016
409 / 652
8.1.23 IDENTIFICATION PROCEDURE
The identification procedure is used by the network to request a particular UE to provide
specific identification parameters, such as the International Mobile Subscriber Identity
(IMSI) or the International Mobile Equipment Identity (IMEI). Note that mobile devices
supporting both 3GPP access and cdma2000 access use a single IMEI to identify the
device.
The Identification procedure is shown in the figure below, where:
The network sends an IDENTITY REQUEST message to the UE and starts the
timer T3470.
The UE sends an IDENTITY RESPONSE message containing the requested

identification parameters to the network.
The network stops the timer T3470 when it receives the IDENTITY RESPONSE.
UE
MME
Identity Request
Identity Response
Start T3470
Stop T3470
Figure 8-27: Identification Procedure
Please refer to 8.1.39.4 for information regarding the T3470 timer.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
410 / 652
8.1.24 SECURITY MODE COMMAND PROCEDURE
The Security Mode Command (SMC) procedure provides integrity protection and
ciphering of the downlink and uplink signaling messages across the Non-Access
Stratum (NAS). The MME uses the NAS SMC to negotiate the integrity protection and
cipher algorithm selection. As a result of the SMC procedure, the UE and the MME will
agree on the NAS signaling integrity protection and encryption algorithms to be used.
The SMC procedure is initiated by the Nokia MME during the Authentication procedure,
at which time the Security Mode Command is sent to the UE. The UE responds to the
MME with the NAS Security Mode Complete message.
NAS ciphering at the MME starts after the MME receives the NAS Security Mode
Complete message from the UE. NAS ciphering in the UE starts when the UE sends the
NAS Security Mode Complete message to the MME.
The Security Mode Command procedure is shown in the figure below, where:
The SMC procedure uses a key obtained from the HSS during authentication to initiate
NAS signaling security between the Nokia MME and the UE.
The ePS NAS security context contains security information that is established between
the UE and the Nokia MME. The security context is stored on both the UE and the
Nokia MME.
eNB
UE
MME
NAS Security Mode Command
(KSIASME, UE security capability, ENEA, ENIA, NAS-MAC)
NAS Security Mode Complete

(NAS-MAC)
Figure 8-28: Security Mode Command Procedure

Note: NAS signaling messages that do not require integrity protection before the secure
exchange of NAS message has been established for the NAS signalling connection are:
Issue 11.01
ATTACH REQUEST
AUTHENTICATION FAILURE
AUTHENTICATION RESPONSE
DETACH ACCEPT
DETACH REQUEST
IDENTITY RESPONSE (if requested parameter is IMSI)
SECURITY MODE REJECT
TRACKING AREA UPDATE REQUEST
LTE/DCL/APP/031094
Nokia 2016
411 / 652
8.1.25 ATTACH PROCEDURE
Network Attachment is the registration of the UE to receive packet services. When a UE
registers with the network, it sends a message that includes the S1-AP UE identity
allocated by the eNB and the tracking area identity where the UE is currently located. If
the UE is within a provisioned TA, the MME receives the NAS ATTACH REQUEST
message in the S1-AP INITIAL UE message as a NAS PDU from the eNB and sets up
the NAS signaling tunnel.
Attach types supported include:
IMSI Attach: The UE sends IMSI in the Attach Request message as UE identity.
The eNB selects the Nokia MME to forward the Attach Request to.
Attach with GUTI to the same Nokia MME: The UE sends a valid GUTI in the
Attach Request message to the Nokia MME identified by the GUTI. The eNodeB
derives the Nokia MME from the Globally Unique MME ID (GUMMEI) portion of
the ID.
Combined EPS/IMSI Attach: The combined attach is used by a Circuit Switch

Fallback (CSFB)-enabled UE and SMS interworking with GSM/UMTS.
EPS Attach: The UE sends the EPS mobile identity in the Attach Request
message as UE identity.
8.1.25.1
Initial Attach Procedure
Network Attachment is the registration of the UE to receive packet services.

Attach types supported:
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 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.
Key Attach messages:
Attach Request
Attach Accept
Attach Complete
Attach Reject
For details about each step of a call flow, refer to the 3GPP Technical Specification
23.401.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
412 / 652
UE
eNodeB
new MME
Old
MME/SGSN
1. Attach Request
PDN GW
Serving GW
HSS
PCRF
EIR
2. Attach
Request
3. Identification Request
3. Identification Response
4. Identity Request
4. Identity Response
5a. Authentication / Security
5b. Identity Request/Response
5b. ME Identity Check
6. Ciphered Options Request

6. Ciphered Options Response
7. Delete Sesion Request
(E)
7. PCEF Initiated IP-CAN

Session Termination
7. Delete Session Response
(A)
8. Update Location Request
9. Cancel Location
9. Cancel Location Ack
10. Delete Session Request

Session Termination
(F)
(B)
11. Update Location Ack

12. Create Session Request
14. PCEF Initiated IP-CAN Session
Establishment/Modification
(C)
15. Create Session Response
First Downlink Data (if not handover)
17. Initial Context Setup Request / Attach Accept
18. RRC Connection Reconfiguration
19. RRC Connection Reconfiguration Complete
20. Initial Context Setup Response
21. Direct Transfer
22. Attach Complete
First Uplink Data
23. Modify Bearer Request
23a. Modify Bearer Request
23b. Modify Bearer Response
(D)
24. Modify Bearer Response
First Downlink Data
25. Notify Request
26. Notify Response
Figure 8-29: Call flow - Initial Attach
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
413 / 652
8.1.25.2
Combined Attach Request
For a combined Attach Request, MME invokes the Location Update for non-EPS
services after receiving the Update Location Answer from the HSS.
If the MME successfully sets up the UE Attach Request for both EPS and non-EPS
services, it sends the UE ATTACH ACCEPT message together with ACTIVATE EPS
DEFAULT BEARER CONTEXT REQUEST message to activate default bearer. The
NAS message is sent in the S1AP Initial Context Setup message.
During the Attach request, the MME identifies if the UE supports A/Gb mode or Iu mode
and if so assigns values for the information element parameters and includes the A/Gb
mode-related and Iu mode-related parameters in the Activate Default EPS Bearer
Context Request ESM message. The MME stores these parameters in UE Bearer
Context.
The MME does not include forbidden TAIs due to regional subscription in the Attach
Accept message. The MME does include the Equivalent PLMNs information in the
Attach Accept message if equivalent PLMNs are provisioned.
If the global parameter Initial Attach Indication in ULR is set to Yes, MME sets bit 5 of
the ULR-Flags AVP (Initial-Attach-Indicator) This bit, when set, indicates that the HSS
shall send Cancel Location to the MME or SGSN if there is the MME or SGSN
registration.
Parameter
Initial Attach Indication in ULR
SAM Table Name
Global Parameters
gParmName
String
OSS ID
Range & Unit
gParmValue
Boolean
Yes/No
Issue 11.01
Impact of Change
No service impact.
Value
Feature
m10099-14
LTE/DCL/APP/031094
Nokia 2016
414 / 652
Figure 8-30: Call flow - Combined Attach with GUTI (steps 16 - 22)
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
415 / 652
8.1.25.3
Message Collision Handling (Attach)
During the Attach procedure, the MME handles message collisions as follows:
When the MME

-
receives another Attach Request message from the UE while waiting for the
Attach Complete message from the same UE on the same S1 connection, or
receives more than one Attach Request message from the UE on the same S1
connection before MME sending the Attach Accept or Attach Reject for a
pending Attach Request,
the MME does not peg the AttachRequests PMC due to the IE of the current Attach
Request not differing from the new Attach Request.
If another Attach request is received from the same UE on a different S1

connection (such as when losing and reestablishing its radio connection), the
current Attach procedure will be aborted and the new Attach procedure is
accepted and MME treats this as a new Attach.
When the MME receives an Attach Request message from the UE in state EMMREGISTERED (regardless of being on same or different S1 connection), MME
invokes the necessary EMM common procedures (GUTI reallocation,
authentication, security mode control, identification, EMM information). The UE
context and EPS bearer contexts, if any, are deleted and the new attach
message is processed.
If the MME receives a TAU request (regardless of being on same or different S1

connection) while waiting for the ATTACH COMPLETE message from the UE,
then the timer T3450 is stopped and the allocated GUTI is considered valid and
TAU procedure is executed.
The MME aborts the Attach procedure if a UE initiated Detach is received

(irrespective of the Detach type and setting of the switch off bit).
MME ignores any SR and ESR messages received during the Attach procedure if
received on the same S1 connection. If the SR and ESR is received on a
different S1 connection (such as when losing and reestablishing its radio
connection), the Attach Procedure is aborted and MME proceeds with SR and
ESR and MME response depends upon the state of the UE at that point.
MME rejects any S11 messages received before the transmission of the Create
Session Request during the Attach procedure. MME ignores any S11 messages
if received after the Create Session Request is sent and before the Modify Bearer
Response is received.
MME ignores any UE initiated ESM messages received after the Initial Context
Setup message and before the reception of the Modify Bearer Response.
Additionally, any ESM messages received before the authentication and security
mode setup are rejected by the MME.
If MME needs to abort the Attach procedure for any errors that occur before
sending the Attach Accept, the MME sends Attach Reject. MME uses the MME
initiated Detach procedure for any errors that occur after sending the Accept.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
416 / 652
MME queues any HSS request during the attach procedure. MME then
processes the HSS request after the completion of the procedure.
8.1.25.4
Roaming
The MME supports Operator-Determined-Barring to restrict UE access to EPS services.

For an Attach Request with GUTI, if the PLMN ID of the GUTI is in the roaming
agreement table and if the LTE Roaming Allowed parameter is set to True in the UE
PLMN Services table and the MME has an active S10/S3 connection to old
MME/SGSN, then the MME uses the Identification Request/Response and/or NAS
Identity Procedure to obtain the IMSI. If the access restriction data field is included in
the EMM Context information received in the Identification Response, MME also
performs access restrictions checks. The new MME includes the Target PLMN ID
information in the S10 Identification Request message. The target PLMN ID is set to the
new MMEs home PLMN ID.
For initial Attach with IMSI as identity, the MME runs the AKA procedure and the SMC
procedure for all roaming UEs.
MME checks roaming, regional subscription and access restriction related Attribute
Value Pairs (AVPs) in the UE subscriber data in the following order:
Roaming-Restricted-Due-To-Unsupported-Feature
Access-Restriction-Data
Operator-Determined-Barring
Regional-Subscription-Zone-Code
Network-Access-Mode.
When the MME receives the following AVPs in either the Update Location
Acknowledgement message or the Insert Subscriber Data Request message, the MME
replaces any stored information with the newly received information:
APN-OI-Replacement data
Operator-Determined-Barring.
The HSS checks ODB (Operator Determined Barring) to determine if the UE is allowed
in the VPLMN (Visited PLMN which is the MMEs home PLMN). If the Use Mapped
Diameter Codes parameter is provisioned to be on (set to Yes), the MME uses the
provisioned NAS cause value from the roaming agreement Diameter NAS Cause
Mapping Profile to map the received diameter code to specific NAS cause value. If the
MME receives one of the following Diameter result codes, the request will be rejected:
Issue 11.01
DIAMETER_ERROR_USER_UNKNOWN (5001)
DIAMETER_ERROR_UNKNOWN_EPS_SUBSCRIPTION (5420)
DIAMETER_ERROR_RAT_NOT_ALLOWED (5421)
LTE/DCL/APP/031094
Nokia 2016
417 / 652
DIAMETER_ERROR_ROAMING_NOT_ALLOWED (5004)
DIAMETER_ERROR_EQUIPMENT_UNKNOWN (5422)
DIAMETER_UNABLE_TO_COMPLY (5012)
The MME checks the Regional-Subscription-Zone-Codes (RSZCs) received from the

HSS and:
Compares County codes (CCs) in the RSZCs with stored MME country codes
(Country Code identifies the country in which the PLMN is located).
Checks National Destination Codes (NDCs) in RSZCs with MME PLMN and
discards RSZCs with different CCs and NDCs/PLMNs (National Destination
Code identifies the PLMN in that country).
The
MME
supports
and
applies
the
values
service_granted
(0)
and
operator_determined_barring (1) received within Subscriber-Status Attribute Value Pair

(AVP) (present in the Subscription-Data AVP when sent within Update Location
Acknowledgement message).
If the value Operator-Determined-Barring is sent, MME applies operator

determined barring restrictions.
If the value "service_granted" is received (for example in IDR), MME clears any
previously saved Operator-Determined-Barring data and MME stops operator
determined barring restrictions on the UE.
When
the
MME
receives
ULA
or
IDR
with
Subscriber-Status
AVP
OPERATOR_DETERMINED_BARRING and Operator-Determined-Barring AVP has bit

1 (Roamer Access HPLMN-AP Barred) or bit 2 (Roamer Access to VPLMN Barred) set,
attach fails if corresponding HPLMN/VPLMN bearer is barred. This is existing
functionality.
For
Roamer
UE
TAU
ULA
with
Subscriber-Status
AVP
OPERATOR_DETERMINED_BARRING and the Operator-Determined-Barring AVP

has either bit 1 or bit 2 set, TAU succeeds, but the WMM immediately deletes
corresponding HPLMN/VPLMN bearers. If no bearer are left, the WMM detaches the
UE.
For IDR, the WMM immediately deletes the corresponding HPLMN/VPLMN bearers. If
no bearers are left, the WMM detaches the UE.
HPLMN/VPLMN bearer is determined by matching the PGW PLMN with UE home
PLMN. If matched, it is the HPLMN bearer; otherwise, it is the VPLMN bearer
The above applies to only roamer because these two ODB bits are for roamer.
MME proceeds with the combined Attach if the Network-Access-Mode AVP is
PACKET_AND_CIRCUIT and the MMEs provisioning enables the Packet and Circuit
for the MME (that is, the MME is provisioned to support either CSFB_2G3G, SMS-Only
or CSFB_NotPreferred). The UEs HPLMN is also provisioned to support CSFB_2G3G,
CSFB_NotPreferred, or SMS-Only. MME performs "EPS only TAU" if the Network-
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
418 / 652
Access-Mode AVP is ONLY_PACKET (irrespective of the provisioned network access
mode for the PLMN).
MME does not include the forbidden TAIs due to regional subscription and any
provisioned forbidden TAI in the TA List of the Attach Accept message. MME includes
the Equivalent PLMNs in the Attach Accept message if equivalent PLMNs are
provisioned. If IMS-over-PS is enabled for a roamer, MME includes the EPS network
feature support information with its IMSVoPS bit set in the Attach Accept message.
Parameter
IMS over PS Supported
SAM Table Name
OSS ID
ltemme. UE PLMN and Served PLMN Service Agreement

Profile. IMS_Over_PS
Range & Unit
IMS_Over_PS_
Boolean
Yes or No
Issue 11.01
Impact of Change
No service impact.
Value
LTE/DCL/APP/031094
Nokia 2016
419 / 652
8.1.25.5
Attach Request Rejection
MME rejects any Attach Request if
The Roaming-Restricted-Due-To-Unsupported-Feature AVP is included.
The Network-Access-Mode reserved value is used (equates to circuit only).
SGW relocation is required and the MME fails to select an SGW.
The ODB-All-APN bit is set.
The ODB-HPLMN-APN bit is set and the PGW accessed is located in HPLMN
(the UEs home network).
The ODB-VPLMN-APN bit is set and the PGW accessed is located in VPLMN
(the MMEs home network).
The MME fails to select a PGW.
The Access-Restriction-Datas E-UTRAN not allowed bit 0 is set.
The UEs HPLMN ID is not allowed. The MME imposes this restriction if the UE's
HPLMN ID is not provisioned on MME, the UE's PLMN is provisioned without a
Roaming Agreement (no UEPLMNServices record) with this served PLMN, or the
UE's PLMN roaming agreement (UEPLMNServices record) for this served PLMN
has LTERoamingAllowed set to false. If the UE has a roaming agreement with
this served PLMN, the MME will send the NAS Cause code defined in
LTEPLMNNotAllowed attribute of RestNasMappingProfile associated with the
UE's roaming aggement; otherwise, the MME will send the NAS cause code
defined in LTEPLMNNotAllowed attribute of RestNasMappingProfile for the
Served PLMN. Refer to Table 22 or Annex A.2 of [R08] for a complete list of
NAS cause values.
The MME determines that TAI is not allowed. (The MME may be provisioned such that
for a given provisioned zone code, tracking area codes (TACs) are assigned, and
tracking area identifier (TAI) access further defined by the Zone Code Type being
provisioned to allow roaming in all tracking areas (TAs), limited TAs, or no TAs. UE
access for a given TAI is based on the Zone Code information from the HSS, combined
with any restrictions the operator has provisioned on the MME for that zone code). In
addition to zone codes, the TAI is not allowed if it is listed as a forbidden TAC in the UE
Roaming TAI and LAI Restriction List provisioned on the MME.
The Forbidden PLMN using Regional Subscription Zone Code feature restricts UE
access to a network based on RSZC in UE subscription data. Based on provisioning
data, the UE can be disallowed to connect to the MME.
In order to mitigate UE-specific failures, the MME supports a service provider
provisioned option to purge the UE Context (VLR) after repeated Attach failures (IMSI
failure or GUTI failure) by a single UE.
The Global parameter "VLR Auto Recovery Purge Count" can be disabled [default], or
can be enabled with a value from 6 to 9.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
420 / 652
When the functionality is enabled (global parameter is set to a non-zero value), the
VLR-per-UE counter (MVLR_SXN's failedMobilityProcCount) is incremented for any
Attach IMSI failure or Attach GUTI failure. When the per-UE counter reaches the
provisioned threshold value, the UE Context is purged and the counter is cleared.
Note that any successful EMM attempt clears the counter as well.
Parameter
VLR Auto Recovery Purge Count
SAM Table Name
Global Parameters
gParmName
OSS ID
Range & Unit
String
VLR_Auto_Recovery_Purge_Count
gParmValue
Integer
0, 6, 7, 8, 9
Issue 11.01
Impact of Change
No service impact.
Value
Operator Dependent; default = 0 (disabled)
LTE/DCL/APP/031094
Nokia 2016
421 / 652
8.1.25.6
Inter-PLMN provisioning for Attach Restrictions
The global parameter Inter-PLMN TAU Attach is used during Attach with foreign GUTI
to determine if the MME can send the appropriate S10/S3/GN inter-PLMN messages to
retrieve UE context information to the old MME/SGSN in a different network. A GUTI is
considered as a foreign GUTI if the PLMN ID of the GUTI does not match with the
PLMN ID of the serving network. If the old MME cannot be contacted for Attach
Request, the new MME will get the UEs information directly from the UE.
Parameter
Inter PLMN TAU Attach
SAM Table Name
Global Parameters
gParmName
String
Inter-PLMN TAU Attach
OSS ID
Range & Unit
gParmValue
Boolean
Yes or No
Impact of Change
No service impact.
Value
Feature
m10151-01
Parameter
Inter PLMN TAU Attach Enable
SAM Table Name
UE PLMN Services Roaming Agreement
OSS ID
ltemme.UE PLMN Service Agreement Profile.
Range & Unit
Inter PLMN TAU Attach Enable

Boolean
Yes or No
Impact of Change
No service impact.
Value
Feature
m10151-01
If the Inter PLMN TAU Attach global parameter is set to Yes (enabled), during MME
relocations scenarios (from either old SGSN or old MME), using the GUTIs PLMN ID
received in the Attach Request Request the MME determines if the old nodes PLMN
matches the PLMN UE is now entering. When the old nodes PLMN and current PLMN
do not match, Inter PLMN TAU Attach provisioning is used.
The default behavior is that the S10/S3/Gn Identification Request will not be sent to the
old node for Attach Request if the PLMN ID of the GUTI matches with the PLMN ID
restricted for inter PLMN Attach.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
422 / 652
If the Inter PLMN TAU Attach global parameter is set to No (default setting ), the UE
PLMN Service Inter PLMN TAU Attach Enable parameter is ignored and the MME
sends S10/S3/Gn NAS Identity Request to the old node.
If the Inter PLMN TAU Attach global parameter is set to Yes, the MME looks at the
Inter PLMN TAU Attach Enable field provisioned under UE-PLMN Service. If the Inter
PLMN TAU Attach Enable field is set to Yes, then the MME contacts the old node,
determines if the old nodes PLMN matches the PLMN UE is now entering (not
applicable when the serving and UE PLMNs are the same) and checks whether interPLMN S10/S3/Gn messages can be sent to the old MME/SGSN by the new MME for
Attach Request with a foreign GUTI.
Note : The MME always looks the setting of the Inter PLMN TAU Attach provisioning
before checking the setting of the parameter lte roaming allowed. ( If Inter PLMN TAU
Attach is enabled and the new MME receives the UE context, the MME checks the
setting for Lte roaming allowed.
MME checks if the PLMN from the foreign GUTI matches the home PLMN and acts
according to the Inter-PLM provisioniong options summarized in Table 11 :
Global Parameter :
Inter PLMN TAU
Attach
UE PLMN Services
provisioning
MME actions :
Inter PLMN TAU

Attach Enable
Normal relocation handling occurs MME
False / disabled
NA
sends Identification Request to source

node (S10/S3/Gn).
MME sends Identification Request to

True / enabled
True/ enabled
source
node
(S10/S3/Gn).
Normal
relocation handling occurs
MME sends NAS identity Request to the

True / enabled
False / disabled
UE instead of sending the identification

request to the source node (S10/S3/Gn).
Table 13 : MME decisions based on Inter-PLMN configuration options.

This feature requires the Roaming PLMN to be provisioned in the UE PLMN services
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
423 / 652
8.1.25.7
S1-AP Reset
If S1-AP RESET is received from the eNodeB before receiving the Attach Complete
from the UE, the MME aborts the Attach procedure and changes the state of the UE to
EMM-DEREGISTRED (only if UE is not already in this state). If bearers are set up, then
the MME deletes the bearers as well. If S1-AP RESET is received after the Attach
Complete (UE is in the ECM-CONNECTED state), the MME deactivates bearers and
changes the state of UE to ECM-IDLE.
8.1.25.8
Queue Network Initiated ESM Requests During Initial
Attach Procedure
MME supports the capability to queue network initiated session management requests
during initial attach and IRAT HO, and execute these requests 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. MME queues up to three network initiated
requests during Attach and IRAT HO procedures.
MME only queues the following requests associated with the PDN connection already
created:
Create Bearer Request
Delete Bearer Request
Update Bearer Request
MME simply drops any requests if it cannot queue the request, either due to full queue
or for any other reason.
During the attach procedure, immediately after the creation of the session, it is possible
to receive the S11 Create Bearer Message and/or the Update Bearer Message. The
Create Bearer Message may be sent by a PGW if piggybacking is not supported and
the Update Bearer Request may be sent by the PGW to change QoS offered to the
subscriber triggered by the charging system. MME starts executing these requests after
the NAS message Attach Complete is received from the UE.
MME handles any new requests once it starts processing the queue as follows:
MME processes the requests on a first-in, first-out basis.
MME queues one additional network initiated request after it starts processing
the queue. Any new requests are dropped until MME processes all three
requests. Basically, MME uses a queue depth of one after processing all the
requests that are queued while MME is in the attach procedure.
If the Attach procedure is aborted due to collisions or any other errors, MME sends a
delete session request to SGW and simply drops the queued messages. If HO is
initiated during the Attach Procedure, MME queues the HO and starts processing the
HO after the Attach Complete. In this case, MME drops any queued requests.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
424 / 652
8.1.25.9
APN correction
During the initial attach procedure, if the MME support for APN correction feature is
enabled, the MME checks if the UE indicated a preferred APN. It checks the preferred
APN sent by the UE against the APNs listed in the subscription profile received from the
HSS. If the preferred APN does not match any of the APNs listed in the subscription
profile, the MME uses the default APN from the subscription profile, so as not to fail a
Request and Create Session Request activation procedure. This feature does not
change the MME behavior for standalone PDN Connectivity Request scenarios.
The global parameter Support APN Correction enables or disables support for the
MME support for APN correction feature.
Parameter
SAM Table Name
Global Parameters
OSS ID
gParmName
String
Support_APN_Correction
Range & Unit
gParmValue
Boolean
Yes or No
Issue 11.01
Impact of Change
No service impact.
Value
LTE/DCL/APP/031094
Nokia 2016
425 / 652
8.1.25.10
UE Power Saving Mode
Power Saving Mode (PSM) feature allows reducing UE power consumption.

A UE supporting Power Saving Mode includes the T3324 value IE in ATTACH
REQUEST to request PSM. This triggers MME to send the T3324 timer value in the
ATTACH ACCEPT message. This timer is also known as "Active Timer". When a UE
transitions from ECM-CONNECTED to ECM-IDLE state, UE starts the T3324 timer
value received from the MME and MME starts the mobile reachable timer set to the
T3324 timer value sent to the UE.
If the global parameter Power Saving Mode is set to Yes (feature enabled), the MME
uses PSM T3412 Timer and PSM T3324 Timer values provisioned under Service
Agreement Profile
Parameter
Power Savings Mode
SAM Table Name
Global Parameters
OSS ID
gParmName
String
Power Savings Mode
Range & Unit
gParmValue
Boolean
Yes or No
Impact of Change
No service impact.
Value
Feature
m10923-01
The MME uses the Power Savings Mode T3324 Timer value it sent to the UE to
determine when the UE is still active, that is, if the UE is still listening for paging. When
the UE becomes ECM-IDLE and the T3324 value expires, the MME considers the UE
no longer able to respond to the page. Any network-initiated request that requires the
UE to be paged will receive its interface specific handling for unable to page UE. The
T3412 Extended Value sent to the UE is used as input for determining when the MME
should implicitly deactivate the UE due to UE inactivity.
MME provides provisioning PSM capability to select UE sent T3324 timer value or
locally provisioned T3324 timer value to be sent to UE in attach accept and TAU accept
messages.
At the expiration of the T3324 timer, UE deactivates its Access Stratum (AS) functions
and goes in to sleep mode to save power. UE stops the timer if it has to initiate any
mobility management request.
At the expiration of the T3324 timer, MME starts T3412 timer. MME provides
provisioning ability to select UE sent T3412 timer, locally provisioned T3412 timer (the
timer value is the T3412 extended timer value) for PSM or HSS provided T3412 timer
value. During this time, it is expected that PSM capable UEs go into "sleep" to save
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
426 / 652
power. So, MME will not page the UEs while the timer is running. The timer is stopped
on any UE initiated mobility management procedure. If the timer expires then MME
implicitly detaches the UE using the current scheme of detaching a UE:
- If the T3412 timer expires then MME starts the mobile reach-ability timer
- If the mobile reach-ability timer expires then MME starts the implicit detach timer
- If the implicit detach timer is expired then MME detaches the UE and starts the purge
timer. MME purges the UE upon the expiration of the purge timer.
Parameter
Power Savings Mode T3412 Timer
SAM Table Name
UE PLMN and Served PLMN Service Agreement

Profile
OSS ID
ltemme. SVCAgreementProfile.PsmT3412Timer
Range & Unit
Integer
1-31 decihours
Issue 11.01
Impact of Change
No service impact.
Value
Feature
m10923-01
Parameter
Power Savings Mode T3412 Timer Unit
SAM Table Name

Profile
OSS ID
ltemme. SVCAgreementProfile. PsmT3412TimerUnit
Range & Unit
2 seconds, 30Seconds, 1 Minute, 10 Minutes, 1 Hour,

10 Hours
Impact of Change
No service impact.
Value
Operator Dependent; default = 10 Minutes
Feature
m10923-01
LTE/DCL/APP/031094
Nokia 2016
427 / 652
Parameter
Power Savings Mode T3412 Timer Source
SAM Table Name

Profile
OSS ID
ltemme. SVCAgreementProfile. PsmT3412TimerSrc
Range & Unit
Local, UE, HSS
Impact of Change
No service impact.
Value
Operator Dependent; default = local
Feature
m10923-01
Parameter
SAM Table Name

Profile
OSS ID
ltemme. SVCAgreementProfile.
Range & Unit
Integer
10 -10800
Issue 11.01
Impact of Change
No service impact.
Value
Feature
m10923-01
Parameter
SAM Table Name

Profile
OSS ID
ltemme. SVCAgreementProfile.
Range & Unit
Local, UE, HSS
Impact of Change
No service impact.
Value
Operator Dependent; default = local
Feature
m10923-01
LTE/DCL/APP/031094
Nokia 2016
428 / 652
8.1.26 EXTENDED SERVICE REQUEST PROCEDURE
8.1.26.1
Support for 3G1X
Transmitter Handset
Voice
on
Dual
Receiver/
The Nokia MME supports UEs that are designed to use a 3G1X network for voice and
SMS and to use an overlying LTE network for data. The UEs supported by this feature
are equipped with dual transceivers (DTR), so that the UE can monitor the 3G1X
network overhead channels while actively connected to LTE. A DTR UE can originate
and terminate voice calls and SMS messages on the 3G1X network without the use of
an S102 interface between the LTE and 3G1X networks.
The Nokia MME may be provisioned such that upon receipt of an Extended Service
Request from a UE in the
ECM-CONNECTED mode, the MME may send an S1 UE Context Modification

Request to inform the E_UTRAN of CSFB request. Based on provisioning of
whether to send a Modification Request or not, the MME sends either the UE
Context Modification Request or the UE Context Release Command.
ECM-IDLE mode, the MME may send an S1 UE Initial Context Setup Request to
inform the E_UTRAN of CSFB request.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
429 / 652
8.1.26.2
DTR Handset Procedures
The following figure describes the process for suspension of Downlink Data
Notifications for a dual-receiver UE when it decides to originate or accept a mobileterminated 1xRTT call (known as cell reselection and redirection).
Figure 8-31: Procedure Dual Receiver UE Suspend when Performing LTE to 1xRTT
Cell Reselection
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
430 / 652
Legend:
Step
Description
UE is E-UTRAN attached. The UE may also be registered in 1xRTT CS.
UE makes a decision that it needs to perform some 1xRTT activity (e.g. in

order to respond to an incoming 1xRTT page, setup a MO call, perform
location management signalling, or perform re-registration).
UE sends an Extended Service Request (CS Fallback Indicator) to the MME.

The figure shows the case the UE is in active state in E-UTRAN but the same
principles applies if the UE is in idle state (as specified in 3GPP TS 23.401).
MME sends UE Context modification Request (CS Fallback Indicator) to EUTRAN. CS Fallback Indicator indicates to the E UTRAN to move the UE to
1xRTT. E-UTRAN responds with UE Context Modification Response.
The E-UTRAN triggers RRC connection release and continues with step 6.
This step may include re-direction information if the E-UTRAN indicates
support for S102. E-UTRAN that indicates support for dual Rx CSFB shall not
include any redirection information towards the UE that indicates dual Rx
configuration but no support for enhanced CS fallback to 1xRTT
E-UTRAN sends an S1 UE Context Release Request (Cause) message to the

MME. Cause indicates that the S1 UE Context Release was caused by CS
fallback to 1xRTT.
The S1-U bearers are released and the MME starts the preservation and
suspension of non-GBR bearers and the deactivation of GBR bearers (if
the global parameter Keep_GBR_when_ENB_Fails is set to false ) towards
S-GW and P-GW(s) by sending Suspend Notification to SGW and PGW
The MME sets the UE context to suspended status.
Issue 11.01
The SGW and PGW(s) acknowledge the bearer updates by responding with
Suspend Acknowledge and marks the UE as suspended in S-GW and P-GW.
When a downlink data arrives at the PGW, the PGW should not send downlink
data if the UE is marked as suspended.
S1 UE Context in the E-UTRAN is released (as specified in 3GPP TS 23.401).
LTE/DCL/APP/031094
Nokia 2016
431 / 652
The following figure describes the process for resuming LTE sessions when the dual
transmitter and dual receiver UE decides to originate or accept a mobile terminated LTE
call, thus leaving the 1xRTT cell. No specific CS fallback mechanisms are needed as
the EPS bearers are automatically reactivated when an LTE-based NAS message
(such as Service Request or TAU) is sent to the UE.
Figure 8-32: Procedure Dual Receiver UE Resume when Performing 1xRTT to LTE
Cell Reselection
Legend:
Step
Description
The UE sends a NAS message, e.g. Service Request or TAU, to the MME.
If the UE context in the MME indicates that UE is in suspended status, the

MME informs the SGW and PGW(s) to reactivate the EPS bearers for the
UE.
If the procedure triggered by the NAS message in step 1 activates Modify
Bearer Request message to the SGW, this message is used as an implicit
resume. The SGW is aware of the suspend state of the bearers and
forwards the Modify Bearer request to the PGW. The PGW and SGW clear
the suspend state and confirm with a Modify Bearer response to the MME.
Issue 11.01
The NAS message is processed accordingly.
LTE/DCL/APP/031094
Nokia 2016
432 / 652
For the following procedures, note that
The UE Context is set to ECM-IDLE as part of the UE Context Release

procedure.
When the UE returns to LTE operation, the MME will send a Resume Notification
to the SGW, allowing it to resume sending Downlink Data Notifications for this
UE.
In the event that the MME receives a Downlink Data Notification after receiving
an Extended Service Request, the MME provides a Downlink Data Notification
Acknowledgement (Unable to Page UE).
If suspended, then Unable to Page Due to Suspension is the cause that will be
used.
The following figure describes the suspension of LTE sessions when the dual
transmitter and dual receiver UE decides to originate or accept a mobile terminated
3G1x call. For a UE in CONNECTED mode, the S1 UE Context Modification Request is
used to inform the E_UTRAN of CSFB request.
Figure 8-33: Procedure - Circuit Switched MO/MT Call with LTE Suspension DTR
Handset - CONNECTED
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
433 / 652
Legend:
Issue 11.01
Step
Description
UE is E-UTRAN attached.
UE makes a decision to perform a mobile originated CS call or receive a

mobile terminated CS call.
UE sends an Extended Service Request to the MME.
Upon receipt of the Extended Service Request MME sends S1-AP: UE

Initial Context Setup Request (CS Fallback Indicator) to request E-UTRAN
to move the UE to 1xRTT.
Upon receipt of S1-AP UE Context Modification Request (CS Fallback

Indicator) E-UTRAN triggers RRC connection release.
E-UTRAN sends an S1 UE Context Modification Response.
Subsequent to sending the S1 UE Context Modification Response the EUTRAN sends an S1 UE Context Release Request (Cause= CSFB
Triggered) message to the MME indicating that the S1 UE Context Release
was caused by CS fallback to 1xRTT.
The MME sends S1: UE Context Release Command (Cause= CSFB

Triggered) to E-UTRAN.
Upon receipt of the S1: UE Context Release Command (Cause= CSFB

Triggered) the E-UTRAN releases the S1 UE Context in the E-UTRAN (as
specified in TS 23.401).
10
Upon Release of the S1 UE Context the E-UTRAN sends S1 UE Context

Release Complete message to the MME.
11
Upon receipt of S1 UE Context Release Complete the MME sets the UE

context to ECM-IDLE.
12
Concurrent with releasing the UE Context in the eNB the MME sends S11
Release Access Bearer Request to SGW to release all S1-U bearer.
Concurrent with releasing the UE Context in the eNB the MME sends S11
Release Access Bearer Request to SGW to release all S1-U bearer.
13
S-GW sends S11: Release Access Bearer Response to MME.
14
The MME sends S11 Delete Bearer Command to SGW to deactivate all
GBR bearer.
15
Upon receipt of the S11: Delete Bearer Command the S-GW & P-GW
deactivate the specified GBR bearers and send the MME S11: Delete
Bearer Request to the MME.
16
The MME sends the S11: Delete Bearer Response indicating the result of
GBR bearer removal.
17
The MME sends a S11 Suspend Notification (IMSI) message to the SGW
requesting it to stop sending Downlink Data Notification.
18
MME marks the sub state to S-GW Suspended.
LTE/DCL/APP/031094
Nokia 2016
434 / 652
Step
Description
19
S-GW acknowledges the Suspend Notification message and marks the UE

as suspended. When a downlink data arrives at the S-GW, the S-GW
should not send a downlink data notification message to the MME if the UE
is marked as suspended.
20
UE moves to 1xRTT and performs the procedure for mobile

originating/terminating call as specified in 3GPP2 A.S0013. This can
happen anytime after step 5.
3G1x call. For a UE in IDLE mode the S1 UE Initial Context Setup Request is used to
inform the E_UTRAN of CSFB request.
Handset - IDLE
Legend:
Issue 11.01
Step
Description


LTE/DCL/APP/031094
Nokia 2016
435 / 652
Issue 11.01
Step
Description

Initial Context Setup Request (CS Fallback Indicator, E-RAB, UE Radio
Capability) to request E-UTRAN to setup initial UE Context and indicate
CSFB.
Upon receipt of S1-AP: UE Initial Context Setup Request E-UTRAN

provides response and does the processing associated with S1-AP: UE
Initial Context Setup Request message.
UE is transitioned to ECM-Connected State.
Based on the receipt of CSFB Indicator in S1-AP: UE Initial Context Setup

Request the E-UTRAN releases the RRC connection.
Subsequent to the above the E-UTRAN sends an S1 UE Context Release

Request (Cause= CSFB Triggered) message to the MME indicating that
the S1 UE Context Release was caused by CS fallback to 1xRTT.
The MME sends S1 UE Context Release Command (Cause=CSFB

Triggered) to E-UTRAN.
10
Upon receipt of the S1 UE Context Release Command Cause=CSFB

Triggered) the E-UTRAN releases the S1 UE Context in the E-UTRAN (as
specified in TS 23.401).
11
Upon Release of the S1 UE Context the E-UTRAN sends S1 UE Context

Release Complete message to the MME.
12
Upon receipt of S1 UE Context Release Complete the MME sets the UE

13
Concurrent with releasing the UE Context in the eNB the MME sends an
S11 Release Access Bearer Request to SGW to release all S1-U bearer.
14
15
The MME sends S11 Delete Bearer Command to SGW to deactivate all
GBR bearer.
16
17
GBR bearer removal.
18
The MME sends a S11 Suspend Notification (IMSI) message to the SGW
19
20

as suspended. When a downlink data arrives at the S-GW, the S-GW
should not send a downlink data notification message to the MME if the UE
is marked as suspended.
21

LTE/DCL/APP/031094
Nokia 2016
436 / 652
3G1x call.
Handset Error - CONNECTED
Legend:
Issue 11.01
Step
Description


Context Modification Request (CS Fallback Indicator) to request E-UTRAN
to move the UE to 1xRTT.
E-UTRAN sends an S1 UE Context Modification Failure (Cause) or MME

times out on S1 UE Context Modification Response.
Upon receipt of S1 UE Context Modification Failure (Cause) or timing out

on S1 UE Context Modification Response in response to a S1-AP: UE
Context Modification Request (CS Fallback Indicator) the MME sets the UE
The MME sends S11: Release Access Bearer Request to SGW to release
all S1-U bearer.
The MME sends S11: Delete Bearer Command to SGW to deactivate all
GBR bearers.
LTE/DCL/APP/031094
Nokia 2016
437 / 652
Step
Description
10
11
GBR bearer removal.
12
The MME sends a S11: Suspend Notification (IMSI) message to the SGW
13
14

as suspended. When downlink data arrives at the S-GW, the S-GW does
not send a downlink data notification message to the MME if the UE is
marked as suspended.
15

The following figure shows the call flow once CS service ends in CS domain and normal
mechanisms are used to move the UE to EUTRAN. When the UE moves to EUTRAN, if
the EPS service was suspended during the CS service, it is resumed.
Figure 8-36: Procedure Resume Procedure Returning from 3G1x Call DTR Handset
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
438 / 652
Legend:
Step
Description
The UE sends a NAS message, for example, Service Request or TAU to the
MME.
2&3
Non-relocation case (utilizes explicit Resume messages):

2. If the UE context in the MME indicates that UE is in ECM-IDLE state with SGW
Suspended substate, the MME sends a Resume Request (IMSI) message to the
SGW that requests the resumption of EPS bearers for the UE.
3. The SGW acknowledges the Resume Request and clears the UE's suspending
status.
2&3
Relocation case (utilizes implicit resume in which the MME communicates with the
SGW/PGW via Modify Bearer Request or Create Session Request because of
SGW/MME relocation per the Service request procedure or Tracking area update
procedure).
2. The MME sends a Modify Bearer Request (in case of Service request
procedure) or Create Session Request (in case of Tracking area update
procedure) to the SGW which requests the establishment of EPS bearers for the
UE.
3. The SGW acknowledges the Request and clears the UE's suspending status.
Issue 11.01
MME clears sub-state SGW Suspended.
The NAS message is processed according to current implementation.
LTE/DCL/APP/031094
Nokia 2016
439 / 652
8.1.26.3
Roaming
Value Pairs (AVPs) in the UE subscriber data in the following order (if the S-TMSI/GUTI
received in the SR/ESR request is assigned by the MME and the MME has valid UE
context):
Provisioned Network
Access Mode
Packet and circuit
Packet and circuit
Packet and circuit
Network Access Mode AVP
Packet and circuit
Packet and circuit
Packet and circuit
Provisioned CSFB_2G3
(per-PLMN)
Enabled
Not Enabled
Not Enabled
Provisioned CSFB_Not
Preferred
(per-PLMN)
Not Enabled
Enabled
Not Enabled
Provisioned SMS-Only
(per-PLMN)
Not Enabled
Not Enabled
Not Enabled
Provisioned SGS_None
(per-PLMN)
Not Enabled
Not Enabled
Not Enabled
Provisioned CSFB_DTR
Not Enabled
Not Enabled
Enabled
Combined Attached UE
Yes (without
SMSOnly in
Additional update
type IE)
Yes (without
SMSOnly in
Additional update
type IE)
NA
ESR Actions
ESR for 2G3G

CSFB is
processed.
ESR for 2G3G

CSFB is
processed.
CSFB DTR ESR

procedure is run.
Table 14: Extended Service Request Roamer Handling

Notes: CSFB_2G3G and CSFB_DTR are supported at the same time on the MME.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
440 / 652
8.1.26.4
Extended Service Request Rejection
The MME rejects any Extended Service Request if
The UEs HPLMN ID is not in the provisioned list of operators (list of PLMN IDs)
who have roaming agreements.
The MME determines that TAI is not allowed. (The MME may be provisioned
such that for a given provisioned zone code, tracking area codes (TACs) are
assigned, and tracking area identifier (TAI) access further defined by the Zone
Code Type being provisioned to allow roaming in all tracking areas (TAs), limited
TAs, or no TAs. UE access for a given TAI is based on the Zone Code
information from the HSS, combined with any restrictions the operator has
provisioned on the MME for that zone code).
In addition to zone codes, the TAI will not be allowed if it is listed as a forbidden
TAC in the UE Roaming TAI and LAI Restriction List provisioned on the MME.
ESR for 2G3G CSFB is rejected if the MME determines that the LAI is
provisioned with CS Capability Supported = NO.
The MME uses the cause CS domain not available in the reject message for all the
reject cases shown in the following table.
Provisioned Network
Access Mode
Packet
only
Packet and
circuit
Packet and
circuit
Packet and
circuit
Network Access Moce

AVP
NA
Packet only
Packet and
circuit
Packet and
circuit
Provisioned
CSFB_2G3G
NA
NA
Enabled
Not Enabled
Provisioned CSFB_Not
Preferred
NA
NA
Not Enabled
Enabled
Provisioned SMS-Only
(per-PLMN)
NA
NA
Not Enabled
Not Enabled
Provisioned SGS_None
(per-PLMN)
NA
NA
Not Enabled
Not Enabled
Provisioned CSFB_DTR
NA
NA
Not Enabled
Not Enabled
Yes (with
SMSOnly in
Additional
update type IE)
ESR is
rejected.
Combined Attached UE
NA
NA
Yes (with
SMSOnly in
Additional
update type IE)
ESR Actions
ESR is
rejected.
ESR is
rejected.
ESR is
rejected.
Table 15: Extended Service Request Rejection Scenarios
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
441 / 652
8.1.26.5
The MME supports UEs that are designed to use a 3G1X network for voice and SMS
and to use an overlying LTE network for data. The UEs supported by this feature are
equipped with dual transceivers (DTR), so that the UE can monitor the 3G1X network
overhead channels while actively connected to LTE. A DTR UE can originate and
terminate voice calls and SMS messages on the 3G1X network without the use of an
S102 interface between the LTE and 3G1X networks.
The MME is provisioned with parameters to indicate whether or not GBR bearers
should be deactivated when the following failures occur:
When paging fails to locate the UE (deactivate all GBR bearers of the UE)
When the S1-MME link to the eNB fails (deactivate all GBR bearers of the eNB)
Parameter
Keep GBR when Paging Fails
SAM Table Name
Global Parameters
OSS ID
gParmName
String
Keep_GBR_when_Paging_Fails
Range & Unit
gParmValue
Boolean
Yes or No
Impact of Change
No service impact.
Value
Parameter
Keep GBR when eNB Fails
SAM Table Name
Global Parameters
OSS ID
gParmName
String
Keep_GBR_when_ENB_Fails
Range & Unit
gParmValue
Boolean
Yes or No
Issue 11.01
Impact of Change
No service impact.
Value
LTE/DCL/APP/031094
Nokia 2016
442 / 652
8.1.27 ENHANCED RESTORATION PROCEDURE FOR EXTANDED
SERVICE REQUEST (ESR)
Starting in WM8.0 and later release MME provides handling of enhanced session
restoration by a different MME that does not have UE context or it cannot obtain UE
context from the old MME. This MME may be a different MME from the registered MME
or registered MME that is restarted. MME updates the SGW of new MME and restores
sessions in the session restoration data on the old SGW
UE
UE sends ESR request. eNB delivers

ESR request to a MME in the pool in
INITIAL UE MESSAGE if S1-MME
connection to the MME identified
by the S-TMSI is down.
SRS
MME
eNB
SGW
1. S1-AP INITIAL UE MESSAGE

2a. Retrieve UE
Restoration Data
Request
2b. Retrieve UE
Restoration Data
Response
3a. Modify Access Bearer Request
3b. Modify Access Bearer Response
4a. GUTI Reallocation Command
4b. GUTI Reallocation Complete

5a. Update Location Request
5b. Update Location Ack
6a. S1-AP INITIAL CONTEXT
SETP REQUEST
6b. S1-AP INITIAL CONTEXT
SETP RESPONSE
7a. Suspend
Notification
Figure 8-37: enhanced restoratioin procedure for Extended Service Request (ESR)
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
443 / 652
8.1.28 DETACH PROCEDURE
The detach procedure is initiated by the UE to inform the network to terminate access to
the ePC. The network (MME or HSS) can also initiate the detach procedure to inform
the UE that its access to the network is terminated.
The MME supports three UE to network detach types:
ePS detach
IMSI detach: MME sends SGs interface IMSI Detach message indication to the
MSC. MME keeps the MME state as EMM_REGISTERED.
Combined ePS/IMSI detach: MME sends SGs interface IMSI Detach message
indication to the MSC. MME changes UE state to EMM_DEREGISTERED.
Network detaches types supported:
IMSI Detach
Re-attach required
Re-attach not required.
For combined UE-initiated ePS/IMSI detach and IMSI detach, MME sends SGs
interface IMSI Detach message indication to the MSC. For combined ePS/IMSI detach,
MME changes the UE state to EMM_DEREGISTERED and for IMSI detach MME keeps
the MME state as EMM_REGISTERED.
Upon detach, all bearers associated with the UE are removed, and the state of the UE
is changed to deregistered.
The UE is detached either explicitly or implicitly:
The network explicitly sends a Detach Request message to UE.
The UE explicitly sends a Detach Request message to the MME.
The network implicitly detaches UE without notifying the UE. The implicit detach
is used if MME determines that it can not communicate with the UE. The UE is
deleted from the UE context data
Implicit IMSI detach from EPS services : This procedure is used by the MME to
indicate when an internal MME timer mechanism has caused the MME to delete
the EMM context of an UE or mark its EMM context as detached.
When the implicit IMSI detach from EPS services procedure is started for a UE
the MME sends an SGsAP-EPS-DETACH-INDICATION message to the VLR
indicating "Network initiated IMSI detach from EPS services".
After the sending of the SGsAP-EPS-DETACH-INDICATION message :
The MME moves the state of the SGs association to SGs-NULL.

The MME starts timer Ts13 (1-32 seconds) upon transmission of the SGsAP-EPSDETACH-INDICATION message.
If no SGsAP-EPS-DETACH-ACK message is received by the MME to a previous
SGsAP-EPS-DETACH-INDICATION message before timer Ts13 expires, the MME
repeats the SGsAP-EPS-DETACH-INDICATION message a maximum of Ns10 times.
The state of the SGs association during the acknowledgement procedure remains SGsNULL.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
444 / 652
The UE can specify:
Normal detach UE is idle; MME sends Detach Accept message; security

context saved.
Switch-off detach -no Detach Accept message sent; security context not saved.
Key tasks performed by MME during Detach:
Accept Detach or initiate Detach message.
Send context release to eNodeB and delete eNodeB-related data.
Keep UE-related static data.
Send Delete Session request to SGW and delete all UE bearers.
Change state of UE to Deregistered.
The figure below shows a call flow for a UE-Initiated Detach. For details about each
step of a call flow, refer to 3GPP Technical Specifications 23.401
UE
eNodeB
MME
SGSN
Serving GW
PDN GW
PCRF
HSS
1. Detach Request
4. Detach Notification
Session Termination
(A)
10. Detach Ack
11. Detach Accept
12. Signalling Connection Release
Figure 8-38: Call flow - UE-initiated Detach
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
445 / 652
8.1.28.1
UE Detach Upon Moving Across Region
In WMM9.0.0 and later release, if the global parameter Detach UE Move Regions LTE
Enable is enabled for LTE, MME detaches a UE with "re-attach required" when a UE
moves from one LA/TA region to a different region after TAU or RAU procedure
completes in order to force the UE to obtain a new IP address associated to the new
region. By default the global parameter Detach UE Move Regions LTE is disabled.
Parameter
Detach UE Move Regions LTE Enable
SAM Table Name
Global Parameters
OSS ID
gParmName
String
Detach UE Move Regions LTE Enable
Range & Unit
gParmValue
Boolean
Yes or No
Impact of Change
No service impact.
Value
Feature
m10143-03
A region can be defined via the table LA and TA region consisting of PLMN (either
MCC/MNC or associated network label). The region can be described via the optional
description field. A list list of LACs and or TACs can then be asociated to a given
region via RegionLaList and RegionTaList respectively:
Issue 11.01
LaTaRegion_label: region name from existing LaTaRegion record
network: either MCC/MNC or network label that region is associated with
RegionListLac/RegionListTac: This is an existing LAC or TAC defined for given

network.
LTE/DCL/APP/031094
Nokia 2016
446 / 652
Rule: Provisioning sequence
1. A maximum of 32 region can be defined per MME indepently of the capacity or
configuration of the MME.
2. A region can be defined in the context of a mobile network with type of home,
shared or mhome only.
3. The associated network must be defined (MMEPLMN) prior to a region being
defined.
4. A region name is globally unique within a WMM. Location areas and tracking
areas in a LA and TA region must be unique.
5. A given LAI can be associated with ONLY one region.
6. The LAI must be defined (MMELAI) prior to associating it with a region.
7. A given TAI must be defined (MMETAI) prior to associating it with a region.
8. A given TAI can be associated with ONLY one region.
9. A given TAI or LAI must be defined for the same mobile network as the region it
is associated with.
10. A maximum of 1024 TACs may be defined region.
11. A maximum of 1024 LACs may be defined region.
12. A region can consist of both a list of TACs and LACs.
13. A network cannot be deleted if there is a region associated with it.
14. A LAI cannot be deleted if contained in a regions LAC list.
15. A TAI cannot be deleted if contained in a regions TAC list.
Restriction:
A region is defined in the context of a mobile network and therefore a region cannot be
shared across networks.
The MME checks whether a TA/LA belongs to the current region or not when the MME
receives a TAU/RAU requestIf the TA/LA is not in the current TA/LA region then MME
detaches the UE with re-attach required. A UE is not detached as long as UE moves
within the region. MME does not detach a UE if it moves from TA/LA that is not
assigned to any region to a TA/LA that is also not assigned to any region.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
447 / 652
If the global parameter Detach UE Move Regions LTE Enable is enabled for LTEand
MME detects that UE has changed regions , the MME acts based upon the following
decision table :
Procedure
Ue Mobility
MME action
Intra-MME
UE mobility within a region
MME doesnt detach the UE
UE mobility between two regions
MME has the knowledge of the
mobility
new TAI and old TAI. So, MME
checks whether the UE moved to
a new region and detaches the
UE with reattach required if UE
moved to a new region
UE mobility between a TAI not
MME detaches the UE with
assigned to a region to a TAI
reattach required.
assigned to a region
UE mobility between a TAI
assigned to a region to a TAI not
reattach required.
UE mobility between two TACs
MME doesnt detach the UE
not assigned to a region

MME Relocation
UE mobility between a TAI not
MME used the Last visited
belonging to a region to a TAI
registered TAI to determine the
region change if the IE is included

to determine to detach the UE or
not. If the IE is not included then
reattach required.
IRAT Mobility
UE is moving from a location area
If the MME and SGSN are
within a region
to a tracking area
collocated, MME doesnt detach

the UE
UE is moving from a non-
The MME used the mapped GUTI
collocated SGSN
to derive LAC (MME group ID

maps to LAC) to detect the region
change and determine to detach
the UE or not with reattach
required.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
448 / 652
In all these cases, if MME cannot determine region change due to lack of knowledge of
the old TAI then MME detaches the UE with reattach required.
In the case of S1HO or X2HO with TAI change, a TAU request is expected. An internal
timer is started to wait for the TAU request. If the timer expires before the reception of
the timer then MME will detach the UE if the old TAI and the new TAI are not in the
same region
To prevent frequent detaches/re-attaches of a UE toggling between two adjacent TA
regions, MME does not detach a UE for a configurable Detach UE Move Regions
Suppress Time " (default= 10 minutes) if the detach exceed the provisioned Detach
UE Move Regions threshold in a configurable duration Detach UE Move Regions
Monitor Time.
The following new global parameters are associated with the detach ue move regions:
Parameter
Detach UE Move Regions Monitor Time
SAM Table Name
Global Parameters
OSS ID
gParmName
String
Detach UE Move Regions Monitor Time
Range & Unit
gParmValue
Integer
1-3600 minutes
Impact of Change
No service impact.
Value
Feature
m10143-03
Parameter
Detach UE Move Regions Suppress Time
SAM Table Name
Global Parameters
OSS ID
gParmName
String
Detach UE Move Regions Suppress Time
Range & Unit
gParmValue
Integer
1 60 minutes
Issue 11.01
Impact of Change
No service impact.
Value
Feature
m10143-03
LTE/DCL/APP/031094
Nokia 2016
449 / 652
Parameter
Detach UE Move Regions Threshold
SAM Table Name
Global Parameters
OSS ID
gParmName
String
Range & Unit
gParmValue
Integer
1 - 16
Impact of Change
No service impact.
Value
Feature
m10143-03
Detach UE Move Regions Suppress Time.
This feature is not applicable if the UE has emergency bearer while they are changing
regions.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
450 / 652
8.1.28.2
Message Collision Handling (Detach)
During the Detach procedure, the MME handles message collisions as follows:
If the network receives a DETACH REQUEST message with switch off

indication, before the network-initiated GPRS detach procedure has been
completed, both procedures are considered completed.
If the network receives a DETACH REQUEST message with switch off

indication, before the network initiated detach procedure has been completed,
the network sends a DETACH ACCEPT message to the UE.
If the network receives an ATTACH REQUEST message before the network

initiated detach procedure with detach type re-attach not requiredhas been
completed, the network ignores the ATTACH REQUEST message. If the Detach
type IE, sent in the DETACH REQUEST message, indicates re-attach required
the detach procedure is aborted and the attach procedure is progressed after the
EPS bearer context(s) have been deleted. If the Detach type IE, sent in DETACH
REQUEST message, indicates IMSI detachthe detach procedure is aborted
and the attach procedure is progressed.
If the Detach type IE, sent in DETACH REQUEST message, indicates re-attach
required or re-attach not requiredand the network receives a TRACKING
AREA UPDATE REQUEST message before the network initiated detach
procedure has been completed, the detach procedure is progressed, that is, the
TRACKING AREA UPDATE REQUEST message is ignored.
If the network receives a SERVICE REQUEST message before the network

initiated detach procedure has been completed (for example the DETACH
REQUEST message is pending to be sent to the UE), the network progresses
the both procedures.
MME rejects UE ESM messages and any S11 messages while Detach is in
progress.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
451 / 652
8.1.28.3
Controlling UE behavior after MME detach
Detach UE parameters can be provisioned to control the behavior of a UE when the UE

is detached by MME. Operator can specifies the actions network should take towards
the UE for 3 types of network initiated detach procedures. The provisioning consists of
detach reason and number of parameters for each detach reason. The provisioning is
provided per UE PLMN Service Profile. Operator provisions the Detach Behavior
Mapping Profile table to use for this service agreement and assign a profile to a UE
PLMN.
A maximum of 8 DetachBehaviorMappingProfiles can be provisioned on the MME.
The detach profile consists of the following parameters:
The Detach Reason parameter specifies the reason for detaching a UE.
The detach reason can be one of the following:
S6a Cancel Location Request with cancelation type Subscription Withdrawal.
SGW failure/SGW restart
Delete Bearer Request with no Cause IE included (applicable only if this is the
lastPDN)
Cancel Location Request (CLR) with cancellation type subscription
IMS Delete Bearer Request.
NOA User Unknown NAS Cause Code User Unknown received in Notify Answer
command (NOA) from HSS.
For each detach reason, MME supports provisioning of the following parameters:
Notify ECM-IDLE UE : If this parameter is set to yes then MME pages the UE.
Once UE responds to the page then MME sends the detach request to the UE
(Explicit Detach). If the parameter is set to no then MME implicitly detaches the
UE i.e. no paging and no sending of detach request message to the UE.
Detach type to be sent to UE in the NAS Detach Request message: re-attach

required and re-attach not required.
Include EMM cause in NAS Detach Request Message : MME includes the EMM
cause with the provisioned cause value if the parameter set to yes. If not MME
does not include the IE.
EMM Cause: The cause code to be included in the detach request if Include
EMM cause in NAS detach message is set to yes. Any cause codes in Table
22: NAS Cause Numeric Values and Description (Annex A.2 of [R08] )
An ECM-CONNECTED UE is always explicitly detached with the provisioned

parameters. For all other detach reasons, existing implementation applies.
8.1.28.4
S1-AP Reset
If MME receives S1-AP RESET from the eNB during an explicit Detach procedure, the
MME completes the procedure treating the Detach as an implicit Detach (that is, the
MME does not send the Detach Accept message).
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
452 / 652
8.1.29 TRACKING AREA UPDATE PROCEDURE
The Tracking Area Update (TAU) procedure is initiated by the UE to notify the network
of its current location. Note that each eNodeB can only be assigned to one Tracking
Area (TA).
Four modes are supported:
Normal - the UE detects that it is within a new tracking area.
Periodic - the UE initiates the TAU Request at defined intervals.
Combined TA/LA update - MME uses the definition of the EPS Update
information in the TAU Request message. MME invokes the location update to
non-EPS services procedure just before sending the TAU Update Accept.
Combined TA/LA updates with IMSI attach - MME uses the definition of the EPS
Update information in the TAU Request message. MME invokes the location
update to non-EPS services procedure just before sending the TAU Update
Accept.
The set of registered tracking areas is sent to the UE during the TAU procedure.
Note: A TAU is also initiated if the Radio Resource Control (RRC) connection was
released with release cause load balancing TAU required.
The following bearer scenarios are supported:
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 SGW interaction required.
This procedure only changes the last seen tracking area and last seen
eNodeB information in the UE context data.
Key tasks performed by MME during TAU:
Perform message integrity check
Perform authentication and security if integrity check fails
Notify HSS of new tracking area
Update UE context
If UE bearers have changed, send Update Bearer Request to SGW.
The MME supports the following TAU request update types:
Combined TA/LA updating
Combined TA/LA updating with IMSI attach
TA update
Periodic update
For a combined TAU request, the MME invokes the location update to non-EPS
services procedure just before sending the TAU Update Accept.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
453 / 652
8.1.29.1
TAU Call Flows
For details about each step of the call flows in Figure 8-38 and Figure 8-38 below, refer
to 3GPP Technical Specification 24.301.
Figure 8-39: Call-flow - Tracking Area Update without bearer change
Figure 8-40: Call flow - Tracking Area Update with bearer change
UE
eNodeB
RNC
new MME
1. Trigger to start
TAU procedure
old MME/ new Serving old Serving PDN GW

GW
GW
old S4
SGSN
HSS
PCRF
2. TAU Request
3. TAU Request
4. Context Request
5. Context Response
6. Authentication / Security
7. Context Acknowledge
9a. PCEF Initiated IP-CAN
Session Modification

(A)
12. Update Location
13. Cancel Location
15. Iu Release Command

16. Iu Release Complete

20. TAU Accept
21. TAU Complete
(B)
Figure 8-41: Call flow - Tracking Area Update with SGW Change and MME Change
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
454 / 652
UE
eNodeB
RNC
BSC
MME
Old MME /
Old S4 SGSN
Serving
GW
PDN
PDN
GW
PCRF
HSS
1. Trigger to start TAU

procedure
2. Tracking Area Update Request
4. Context Request
5. Context Response

(A)

15. Cancel Location
20. Tracking Area Update Accept

21. Tracking Area Update Complete
Figure 8-42: Call flow eUTRAN Tracking Area Update without SGW Change
When the UE moves to a new TA with a new time zone, the MME sends the
provisioned UEs time zone to the SGW in the Create Session Request (for TAU
procedure with SGW change) and Modify Bearer Request (for TAU procedure without
SGW change).
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
455 / 652
8.1.29.2
Enhanced restoration procedure impact on TAU
Request
Figure 8-43: Call flow - Tracking Area Update with enhanced restoration
procedurebelow shows session restoration of a UE associated with an MME that
restarts after failure when the UE initiates TAU request.
This MME may be a different MME from the registered MME or registered MME that is
restarted. MME will update the SGW of new MME and restores sessions in the session
restoration data on the old SGW.
The started MME or a different MME retrieves UE context from the SRS and restores
UE sessions.
eNB
UE
UE sends TAU request. eNB delivers

TAU request to a MME in the pool in
SRS
MME
SGW

2a. Retrieve UE
Restoration Data
Request
2b. Retrieve UE
Restoration Data
Response

SETUP REQUEST with TAU
Accept containing new GUTI
TAU Accept
SETUP COMPLETE
7. TAU Complete
8. UE restoration data
update
Figure 8-43: Call flow - Tracking Area Update with enhanced restoration procedure
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
456 / 652
1. UE sends TAU request message with active flag to MME. If MME recognizes UE and has valid
UE context then the MME proceeds with the TAU request.
2. If the GUTI was allocated by the MME and if the MME does not have UE context then MME
retrieves UE restoration data from the SRS.
If GUTI received in the TAU request message is allocated by a different MME then MME sends
S10 Context Request to the MME pointed by the GUTI if S10 path is available to the MME. If
S10 path is not available then MME retrieves UE restoration data from the SRS. The MME
considers that S10 path is not available for the following conditions:
a) S10 interface is down,
b) S10 interface is locked,
c) Time out waiting for context response,
nd
d) 2 context response with IMSI unknown and
e) DNS query for the MME in the GUTI fails either due to no MME in GUTI or no DNS
response.
3. If there is no SGW relocation then MME first establishes MME control plane with the SGW by
sending MB Request for each PDN connection.
4. MME sends Update Location Request to HSS to update MME and also to obtain entire UE
subscription data
5. MME sends S1-AP INITIAL CONTEXT SETUP REQUEST message populating IEs of the
message using the restoration data with TAU Accept containing new GUTI.
6. MME sends the Modify Access Bearer Request to SGW for each of the PDN to update the
downlink FTEIDs..
7. Not shown in the diagram but MME sends UE restoration data update to the SRS.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
457 / 652
8.1.29.3
Gn-based TAU Procedure
The Gn-based TAU procedure, as per 3GPP TS 23.401, is used when
UE
a UE in the idle state moves from the GERAN into the LTE domain
or a UE in either the CONNECTED or IDLE state moves from UTRAN to LTE.
RNC
BSC
eNodeB
MME
Gn/Gp
SGSN
Old
MME
Serving
GW
PDN
GW
PCRF
HSS
1. Trigger to start
TAU procedure
4. SGSNContext Request
5. SGSN Context Response
6. Security procedures
7. SGSN Context Acknowledge

C1
(A)


13.Create Session Response
15. Cancel Location
17. Cancel Location

24. Procedure as in TS 23.401, steps 2 to 7 of Figure 5.4.2.2-1
Figure 8-44: Call flow Gn-based Tracking Area Update
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
458 / 652
The UE sends a TAU request which includes information about the SGSN in which it
was registered. The MME uses a DNS query to retrieve the SGSNs address and then
sends an SGSN Context Request message via the Gn interface to retrieve the UEs MM
and PDP context from the SGSN.
The SGSN sends an SGSN Context Response, prompting the MME to:
store the address,
map MM and PDP contexts to EPS bearer information, and
Send back a Context Ack message informing the SGSN that it is ready to receive
data packets belonging to the activated PDP contexts.
MME selects SGW and initiates Create Session Request to the SGW, to which the
SGW sends back a Create Session Response.
MME sends an Update Location Request to HSS to ensure the release of all UE
resources in the Gn/Gp SGSN, to which the HSS responds with an Update Location
Ack. At this point the EPS bearer is created.
MME then sends TAU Accept to the UE, to which the UE sends back a TAU Complete.
The MME is provisioned with 2 global parameters to support the SGSN Context
Acknowledge message sent from the MME during a Gn SGSN to MME TAU:
The Tunnel Endpoint Identifier Data II Information Element (TEID) to SGSN

parameter can be set to all ones or all zeros.
The SGSN IPv4 Address for User Traffic parameter can be set to a specific IPv4
address.
Parameter
TEID to SGSN
SAM Table Name
Global Parameters
OSS ID
Range & Unit
gParmName
String
TEID_to_SGSN
gParmValue
Choice List
All Ones
All Zeros
Issue 11.01
Impact of Change
No service impact.
Value
Operator Dependent; default = All Ones
LTE/DCL/APP/031094
Nokia 2016
459 / 652
Parameter
SGSN IPv4 Address for user Traffic
SAM Table
Name
Global Parameters
OSS ID
Range & Unit
gParmName
String
SGSN_IPv4_Address_for_user_Traffic
gParmValue
String
IPv4 IP address
Impact of
Change
No service impact.
Value
8.1.29.4
S3-based TAU
The MME supports and complies with the Tracking Area Update procedure as outlined
in section 5.3.3.1 and 5.3.3.2 of 3GPP TS 23.401 V8.8.0. This includes the support of
the S3 interface to the S4-SGSN and the interworking procedures between E-UTRAN
and UTRAN/GERAN (TAU with or without SGW change, when an UE moves from
UTRAN/GERAN to E-UTRAN).
Refer to 3GPP TS 23.401 for details of the procedure steps.
UE
eNodeB
RNC
new MME
1. Trigger to start
TAU procedure
old MME/ new Serving old Serving PDN GW

GW
GW
old S4
SGSN
HSS
PCRF
2. TAU Request
3. TAU Request
4. Context Request
5. Context Response
9a. PCEF Initiated IP-CAN

(A)
12. Update Location
13. Cancel Location

20. TAU Accept
(B)
21. TAU Complete
Figure 8-45: Call flow S3-based Tracking Area Update with SGW Change
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
460 / 652
UE
eNodeB
RNC
BSC
MME
Old MME /
Old S4 SGSN
Serving
GW
PDN
PDN
GW
HSS
PCRF
1. Trigger to start TAU

procedure
4. Context Request
5. Context Response

(A)

15. Cancel Location

Figure 8-46: Call flow S3-based Tracking Area Update without SGW Change
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
461 / 652
8.1.29.5
Enhanced restoration procedure for TAU requests
Figure 8-47 shows session restoration of a UE associated with an MME that restarts
after failure when the UE initiates TAU request. The restarted MME or a different MME
retrieves UE context from the SRS and restores UE sessions.
eNB
UE
UE sends TAU request. eNB delivers

TAU request to a MME in the pool in
MME
SRS
SGW

2a. Retrieve UE
Restoration Data
Request
2b. Retrieve UE
Restoration Data
Response

SETUP REQUEST with TAU
Accept containing new GUTI
TAU Accept
SETUP COMPLETE
7. TAU Complete
UE
eNB
MME
SRS
SGW
Figure 8-47 :Enhanced Restoration Procedure impact on TAU request.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
462 / 652
8.1.29.6
Enhanced Restoration procedure impact on TAU
with EPS Update.
MME handles a recovery TAU request with EPS Update IE either set to combined
TA/LA updating or Combined TA/LA updating with IMSI attach as shown in Figure
8-49 .
The MME updates the SRS at the completion of the recovery procedure.
UE
MME
eNB
SRS
SGW
UE sends TAU request with EPS update Ie either set to combined TA/LA updating or combined
TA/LA updating with IMSI attach. eNB delivers ESR to a MME in the pool in INITIAL UE MESSAGE if
S1-MME connection to the MME identified by the S-TMSI is down.

2a. Retrieve UE
Restoration Data
Request
2b. Retrive UE
Restoration Data
Response
Authentication/Security
procedures if needed.
4a. Update Location Request to HSS

5a&b. SGs Location Update Request/Response to/

from MSC/VLR
6a. TRACKING AREA UPDATE ACCEPT
New GUTI is sent to the UE
6b. TRACKING AREA UPDATE COMPLETE
UE
eNB
MME
SRS
SGW
Figure 8-48 Procedure of TAU request with EPS Update IE
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
463 / 652
8.1.29.7
Support for A/GB and IU Mode Capable UES
When the old MME sends Context Response message over the S10 interface to the
new MME during the TAU procedure, the old MME includes the necessary A/Gb moderelated and Iu mode-related parameter values for each bearer (if the UE Context
contains the values for these information elements).
When the new MME receives a Context Response message over the Gn or S10
interface from the old SGSN/MME during the TAU procedure, the new MME stores the
necessary A/Gb mode-related and Iu mode-related parameter values received for each
bearer in the UE Bearer Context.
When the UE moves from 2G/3G network to the LTE network and initiates a TAU
Request, if the old SGSN does not include the MS Network Capability parameter in the
Context Response message, then the TAU request is rejected.
8.1.29.8
Determine GUTI Origination
During inter-node mobility, the MME may not be able to determine whether the GUTI it
receives is a native GUTI or a mapped GUTI from GERAN/UTRAN. As a result, the
MME cannot determine which DNS look up to initiate to determine the address of the
old node for inter-node mobility since it can not determine if the old node type is MME or
SGSN from the most significant bit (MSB) of the Location Area Code (LAC). For
example, MSBit=1 indicates a native GUTI allocated by other MMEs and MSBit=0
indicates a mapped GUTI allocated by SGSN. However, some operators have already
configured LACs with a full range value (i.e. MSBit of LAC =1). It can then cause a
wrong indication when this LAC is mapped to an MME Group ID.
Functionality exists on the MME to allow operators who have already configured LACs
using the full value range of the LAC value (LAC values with MSBit=1 already exist in
deployed networks), to use the GPRS Ciphering Key Sequence Number IE in TAU
Request and Attach Request messages to indicate that the UE originated from SGSN
coverage. This is done to help determine the NAPTR query format for an MME or
SGSN.
This functionality works by using the GPRS Ciphering Key Sequence Number IE in a
TAU Request message as an indicator that UE has come from SGSN coverage. The
UE includes this IE if the UE performs an A/Gb mode or Iu mode to S1 mode intersystem change in EMM-IDLE mode and the TIN indicates P-TMSI. If the P-TMSI
Signature and/or Additional GUTI is present then the GPRS Ciphering Key Sequence
Number must be present. Otherwise the TAU message is treated as an invalid
formatted message. If the GPRS Ciphering Key Sequence Number IE is received in
the TAU Request message, the MME formulates a NAPTR query for SGSN for to
retrieve SGSN IP Address. If the TAU Request does not include the GPRS Ciphering
Key Sequence Number IE, the MME formulates a NAPTR query for the MME to
retrieve the MME address.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
464 / 652
8.1.29.9
Roaming
Value Pairs (AVPs) in the UE subscriber data in the following order (if the GUTI
received in the TAU request is assigned by the MME and the MME has valid UE
context):
If the MME does not have the UE subscriber data or access restriction data received in
MM Context, MME uses Context Request/Context Response/Context Acknowledge
messages to obtain UE context (only if the PLMN ID received in the GUTI is in the
roaming agreement table), then runs these checks after obtaining the UEs subscriber
data for the following cases:
TAU with MME relocation
S1HO over with MME relocation,
UE moves from GERAN
UE moves from UTRAN.
The new MME includes the Target PLMN ID in the S10/S3 Context Request message.
The Target PLMN ID is set to the MMEs home PLMN ID. If the access restriction data
field is included in the MM Context received in the Context Response, the MME
performs access restrictions checks. The old MME does not include unused
authentication vectors if the Target PLMN ID received in the Context Request message
is not same as the old MMEs home network. If a new MME does not include the Target
PLMN ID, then the old MME considers the new MME is in the same network as the old
MME.
The MME proceeds with the "combined TAU" if the Network-Access-Mode is
PACKET_AND_CIRCUIT and the MMEs provisioning enables the Packet and Circuit
and CSFB_2G3G for the PLMN. MME performs "EPS only TAU" if the Network-AccessMode AVP is ONLY_PACKET (irrespective of the provisioned network access mode for
the PLMN).
MME does not include the forbidden TAIs due to regional subscription and any
provisioned forbidden TAI in the TA List of the TAU Accept message. MME includes the
Equivalent PLMNs in the TAU Accept message if equivalent PLMNs are provisioned. If
IMS-over-PS is enabled for a roamer (See Section 8.1.25.4.), MME includes the EPS
network feature support information with its IMSVoPS bit set in the TAU Accept
message.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
465 / 652
8.1.29.10
Inter-PLMN provisioning for TAU Restrictions
The parameter Inter-PLMN TAU Attach enable is used during TA Update procedure to
determine if the MME can send the appropriate S10/S3/GN messaging to the old node
MME/SGSN in a different network to retrieve UE context information.
A GUTI is considered as a foreign GUTI if the PLMN ID of the GUTI does not match
with the PLMN ID of the serving network. If the old MME cannot be contacted for Attach
Request, the new MME will get the UEs information directly from the UE.
If the Inter PLMN TAU Attach global parameter is set to Yes (m10151-01
enabled),during MME relocations scenarios (from either old SGSN or old MME), using
the GUTIs PLMN ID received in the TAU Request the MME determines if the old
nodes PLMN matches the PLMN UE is now entering. When the old nodes PLMN and
current PLMN do not match, Inter PLMN TAU Attach provisioning is used.
The default behavior is that the S10/S3/Gn Identification Request will not be sent to the
old node for Attach Request if the PLMN ID of the GUTI matches with the PLMN ID
restricted for inter PLMN Attach.
If the Inter PLMN TAU Attach global parameter is set to No (default setting ), the UE
PLMN Service Inter PLMN TAU Attach Enable parameter is ignored and the MME
sends S10/S3/Gn NAS Identity Request to the old node.
If the Inter PLMN TAU Attach global parameter is set to Yes, the MME looks at the
Inter PLMN TAU Attach Enable field provisioned under UE PLMN Service. If the Inter
PLMN TAU Attach Enable field is set to Yes, then the MME contacts the old node,
determines if the old nodes PLMN matches the PLMN UE is now entering (not
applicable when the serving and UE PLMNs are the same) and checks whether interPLMN S10/S3/Gn messages can be sent to the old MME/SGSN by the new MME for
Attach Request with a foreign GUTI.
Note: The MME always looks the setting of the Inter PLMN TAU Attach provisioning
before checking the setting of the parameter lte roaming allowed. (If Inter PLMN TAU
Attach is enabled and the new MME receives the UE context, the MME checks the
setting for Lte roaming allowed.
If the old node cannot be contacted for TAU Request, the MME will reject the TAU
procedure with the provisioned inter-plmn-tau-reject NAS Cause Code
Global Parameter :
Inter PLMN TAU Attach
UE PLMN provisioning
Inter PLMN TAU
Attach Enable
False / disabled
NA
MME sends Context Request to source node

(S10/S3/Gn). Normal relocation handling occurs
True/ enabled
On TAU with inter PLMN GUTI : WMM sends

Context Request to source node (S10/S3/Gn).
Normal relocation handling occurs
False / disabled
MME rejects the TAU with the provisionable

cause code, defined under table Name of
Access Restriction to NAS Cause Code Profile
ID instead of sending the Context Request to
the source MME (S10/S3/Gn).
True / enabled
True / enabled
MME actions :
Table 16 : TAU procedure with inter PLMN GUTI
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
466 / 652
8.1.29.11
TAU Request Rejection
Throughout the procedure, the MME checks the associated messages for specific IE
content to ensure it meets the procedure criteria. MME may also set timers for requests
to be acknowledged.
MME rejects any TAU Request if
The Network-Access-Mode reserved value is used (equates to circuit only).
SGW relocation is required and the MME fails to select an SGW.
UE HPLMN is not allowed. MME imposes this restriction if the UE's HPLMID is
not provisioned on MME, or the UEs PLMN is provisioned without a Roaming
Agreement ( no UE PLMN Services entry) with this served PLMN, or the UE's
PLMN roaming agreement (UE PLMN Services entry) for this served PLMN has
the parameter LTE Roaming Allowed set to false. If the UE has a roaming
agreement with this served PLMN, the MME will send the NAS Cause code
defined in LTE PLMNNotAllowed profile of RestNasMappingProfile associated
with the UE's roaming agreement; otherwise, the MME will send the NAS cause
code defined in LTEPLMNNotAllowed attribute of RestNasMappingProfile for the
Served PLMN. Refer to Table 22 (Annex A.2 of [R08] ) for a complete list of NAS
cause values.
The Forbidden PLMN using Regional Subscription Zone Code feature restricts
UE access to a network based on RSZC in UE subscription data. Based on
provisioning data, the UE can be disallowed to connect to the MME.
The MME determines that TAI is not allowed. (The MME may be provisioned
provisioned on the MME for that zone code).
In addition to zone codes, the TAI will not be allowed if it is listed as a forbidden TAC in
the UE Roaming TAI and LAI Restriction List provisioned on the MME.
Any check failure or timer timeout results in procedure failure for which a message is
returned to the "requesting" network element with a cause value indicating the failure
type, and the procedure is then terminated.
The MME uses the Access Restriction NAS Cause Mapping Profile associated with this
UE's roaming agreement, to map the access restriction failure reason to a NAS cause
value. MME takes one or more of the following actions whenever it sends a TAU Reject
message to UE:
Release S1 connection.
Send Context Acknowledge message with cause value User authentication

failed to the old MME/SGSN if required to send for the case of MME relocation
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
467 / 652
(Ex. MME determines that PLMN of the UE is not in the roaming agreement
table).
8.1.29.12
Message Collision Handling
During the Tracking Area Update (TAU) procedure, the MME handles message
collisions as follows:
If MME receives TAU message after Context Acknowledge message and before
the timer expires, MME accepts the TAU request, however if attach and service
request is received MME rejects it.
Upon receipt of a Tracking Area Update Request message prior to the MME
sending a Tracking Area Update Accept message for a previous Tracking Area
Update Request message for the same UE, the MME aborts the previously
initiated procedure if there are differences in the information elements included in
the messages. Processing will then proceed for the new request. However, if the
message contents of the two messages are the same, the later Tracking Area
Update Request message is ignored.
Upon receipt of a malformed Tracking Area Update Request message, the MME
responds with a Tracking Area Update Reject message with one of the following
reject causes based upon the type of issue found with the received message:
#96: mandatory information element error
#99: information element non-existent or not implement
#100: conditional IE error
#111: protocol error, unspecified

Upon receipt of another Tracking Area Update Request message before the
Tracking Area Update Complete is received while processing a previous Tracking
Area Update Request for the same UE and if this message is received after the
MME sent a Tracking Area Update Accept message, the MME aborts the
previously initiated procedure if there are differences in the information elements
included in the messages. Process will then proceed for the new request.
However, if the message contents of the two messages are the same, the
Tracking Area Update Accept message is retransmitted and the T3450 timer is
restarted if necessary and no other processing is performed for the later Tracking
Area Update Request message. Please note that aborted or ignored Tracking
Area Update attempts are not pegged in TAU Performance Measurement counts
as a failure of any kind.
MME queues any UE ESM messages and any S11 messages from the network
during the TAU procedure both in ECM-IDLE and ECM-CONNECTED state.
If internal errors cause the TAU procedure to be aborted then MME immediately
Detach the UE.
The MME queues any HSS request during the TAU procedure. MME processes
the HSS request after the completion of the procedure.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
468 / 652
The MME deletes bearer collisions with TAU request that follows an abnormal
release of UE S1 connection. An abnormal UE S1 connection release results in
deactivating the GBR and while MME is in the process of deactivating the GBR
bearer, TAU Request is received from the UE. The collision is handled as follows:
MME does not delete the GBR while waiting for S1AP RELEASE REQUEST
COMPLETE message from the eNB or until the s1ap-ue-context-release-timer
is expired. The timer default value is 8 seconds.
If the MME has not started the S1 release procedure then the MME will not
delete the GBR bearers. The MME will proceed with the TAU/SR request.
If MME has started the S1 release procedure then the MME would wait for the
completion of the procedure and then proceed with the TAU.
ESM collision with TAU request (normal TAU or TAU that follows X2/S1 HO)
If MME determines that TAU request will be received then it wait for a
configurable X2/S1 HO TAU time interval before processing any network
requested ESM procedure. During this X2/S1 HO TAU time interval, any network
initiated bearer requests received are queued. Upon reception and completion of
the TAU procedure or X2/S1 HO TAU timer expiry, the MME de-queues any
network initiated network request if present and process them. The MME queues
up to three ESM requests from the network.
New behavior in WM9.0 with modification of the existing Move VLR handling
scenario based actions (m10714-03) in response to failures in interMME TAU :
It was found that sometimes UE moves out of MME without a notice to MME (i.e. no
timer running or no CLR). This causes the related context can not be deleted correctly
and duplicated VLR records occur when UE moves back to MME with a foreign GUTI.
This feature addresses inappropriate MME handling of UE Context cleanup for some
triggers when a MME relocating procedure is initiated. In the current implementation of
the "Move VLR" action, cleanup of the previously established session(s) is done without
regard to the current triggering procedure. This can lead to inappropriate cleanup
actions which will cause the triggering procedure to fail. Modification of the existing
"Move VLR" handling of old session cleanup addresses response to failures in
interMME TAU at one customer and in interRAT TAU at another customer. This feature
adds the functionality for the source MAF to inform the destination MAF of the scenario
causing the move VLR and therefore to do the appropriate clean up actions.
When the identify of a UE in a procedure triggering message is unknown to the MME, a
MAF is selected and a temporary VLR record is created. During an MME relocating
procedure the MME will request information about the UE from the source MME and will
typically learn the UE IMSI in that exchange. The MME will use the IMSI to determine
whether or not a vlr record for the UE already exists with the UE with the EMM state of
EMM-Registered. If such a record exists, the MME must perform cleanup of the
previously established session(s) and then merge whatever information is appropriate
from the old record into the new record. This cleanup and information merging is called
Move VLR. In the current implementation of the Move VLR action, cleanup of the
previously established session(s) is done without regard to the current triggering
procedure. This can lead to inappropriate cleanup actions which will cause the
triggering procedure to fail. Specifically, the Delete Session request will typically be sent
during the Move VLR action when the triggering procedure is an SGW re-locating
event.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
469 / 652
The Delete Session Request message includes the Indications flags IE and the
operation indication (OI) and scope indication (SI) flag settings determine how the
message is treated with regard to the PGW. If the triggering procedure is an attach, it is
appropriate to delete old session data on both the old SGW and PGW.
If the triggering procedure instead is an interMME TAU, then it is appropriate to delete
old session data on the old SGW but not on the PGW.
Currently the Delete Session request is sent during Move VLR old session cleanup
with the Operation Indication flag set, indicating to the SGW that the DSreq should be
forwarded to the PGW for deletion of session data there.
For an interMME TAU treated in this way, further processing of the procedure will
include sending Create Session request to the new SGW with the Operation Indication
flag set to 1 in the Indication Flags IE of that message. This is intended to indicate to
the PGW that the existing session should be maintained and that an SGW relocation
has occurred. Having just deleted the session data on the PGW during the Move VLR
action, the PGW will reject the request with cause no context found and the triggering
procedure will fail.
The existing treatment of the Delete Service Request during the session cleanup of the
Move VLR action is appropriate when the triggering procedure is the attach request.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
470 / 652
EMM states
Triggering Procedure
MME receives TAU Req with
foreign GUTI. Old/stale SGW does
not match the source SGW in the
received Context Rsp and source
SGW cannot be allocated by MME.
Newly allocated SGW is different
from the stale SGW.

foreign GUTI. Stale SGW does not
match the source SGW in the
SGW cannot be allocated by MME.
Newly allocated SGW is the same
as the stale SGW.
Idle UE
moves out
without
removing
context

foreign GUTI. Stale SGW does not
match the source SGW in the
SGW can be allocated by MME

foreign GUTI. Stale SGW match
the source SGW in the received
Context Rsp and source SGW
cannot be allocated by MME.

foreign GUTI. Stale SGW match
the source SGW in the received
Context Rsp and source SGW can
be allocated by MME
MME receives Attach Req with

foreign GUTI
Issue 11.01
LTE/DCL/APP/031094
MME action
MME sends Delete Session Req with SI bit = 1
to stale SGW followed by normal TAU procedure
with SGW relocation.
The stale SGW has:
Case 1: default bearer only, S10 interface
Case 2: default bearer + one dedicated bearer,
S10 interface
Case 3: two PDN connections, S10 interface
with SGW relocation.
The stale SGW has
Case 1: default bearer only
Case 2: default bearer + one dedicated bearer
Case 3: two PDN connections
Case 4: default bearer only, Gn interface
without SGW relocation.
The stale SGW has
Case 4: default bearer only, Gn interface
MME does not send Delete Session Req to stale
SGW. The normal TAU procedure with SGW
relocation is executed.
The stale SGW has
MME does not send Delete Session Req to stale
SGW. The normal TAU procedure without SGW
relocation is executed. The stale SGW has
MME sends Delete Session Req with OI bit = 1
to the stale SGW followed by normal attach
procedure
Nokia 2016
471 / 652
Figure 8-49 Idle Mode TAU with MME Change and SGW Change
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
472 / 652
8.1.29.13
S1-AP Reset
Handling of old or new MME up on receiving S1AP RESET from the eNB is as follows
for different scenarios:
No MME and SGW relocation - MME aborts the TAU procedure.
No MME relocation but SGW relocation - MME aborts TAU and SGW relocation if
MME is in the middle of the procedure. If the RESET is received after successful
SGW relocation, MME keeps the new SGW and deletes bearers on the old SGW.
MME relocation but no SGW relocation - The new MME aborts the TAU if the
RESET is received before sending the Update Location. If RESET is received
after sending the Update Location Acknowledgement, MME completes the
procedure except for sending the TAU accept. UE state is ECM-IDLE.
MME and SGW relocation - The new MME aborts the TAU if the RESET is
received before sending the Update Location. MME deletes all the sessions on
the new SGW. If RESET is received after sending the Update Location
Acknowledgement, MME completes the procedure except for sending the TAU
accept. UE state is ECM-IDLE.
For all scenarios, if any bearers are activated (UE sets active flag), MME deactivates
the bearers and changes the state of the UE to ECM-IDLE if bearers are activated and
state changed to ECM-CONNECTED, respectively.
8.1.29.14
Power Saving Mode (PSM)
Power Saving Mode (PSM) feature allows reducing UE power consumption.

A UE supporting Power Saving Mode includes the T3324 value IE in Tracking Area
Update to request PSM. This triggers MME to send the T3324 timer value in the TAU
ACCEPT message. This timer is also known as "Active Timer". When a UE transitions
from ECM-CONNECTED to ECM-IDLE state, UE starts the T3324 timer value received
from the MME and MME starts the mobile reachable timer set to the T3324 timer value
sent to the UE.
If the global parameter Power Saving Mode is set to Yes (feature enabled), the MME
uses PSM T3412 Timer and PSM T3324 Timer values provisioned under Service
Agreement Profile
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
473 / 652
Parameter
Power Savings Mode
SAM Table Name
Global Parameters
OSS ID
gParmName
String
Power Savings Mode
Range & Unit
gParmValue
Boolean
Yes or No
Impact of Change
No service impact.
Value
Feature
m10923-01
The MME uses the Power Savings Mode T3324 Timer value it sent to the UE to
determine when the UE is still active, that is, if the UE is still listening for paging. When
the UE becomes ECM-IDLE and the T3324 value expires, the MME considers the UE
no longer able to respond to the page. Any network-initiated request that requires the
UE to be paged will receive its interface specific handling for unable to page UE. The
PSM T3412 Value sent to the UE is used as input for determining when the MME
should implicitly deactivate the UE due to UE inactivity.
MME provides provisioning PSM capability to select UE sent T3324 timer value or
locally provisioned T3324 timer value to be sent to UE in TAU accept message.
At the expiration of the T3324 timer, UE deactivates its Access Stratum (AS) functions
and goes in to sleep mode to save power. UE stops the timer if it has to initiate any
mobility management request.
At the expiration of the T3324 timer, MME starts T3412 timer. MME provides
provisioning ability to select UE sent T3412 timer, locally provisioned T3412 timer (the
timer value is the T3412 extended timer value) for PSM or HSS provided T3412 timer
value. During this time, it is expected that PSM capable UEs go into "sleep" to save
power. So, MME will not page the UEs while the timer is running. The timer is stopped
on any UE initiated mobility management procedure. If the timer expires then MME
implicitly detaches the UE using the current scheme of detaching a UE:
- If the T3412 timer expires then MME starts the mobile reach-ability timer
- If the mobile reach-ability timer expires then MME starts the implicit detach timer
- If the implicit detach timer is expired then MME detaches the UE and starts the purge
timer. MME purges the UE upon the expiration of the purge timer.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
474 / 652
8.1.30 SERVICE REQUEST PROCEDURE
The Service Request procedure establishes the radio and S1 bearers when uplink or
downlink user data need to be sent.
The UE sends the Service Request message in:
ECM-IDLEstate :
The UE can send the service request message in ECM-IDLE state when it or the user
network has data pending. The MME sends a Service Reject message with appropriate
reject cause value if the Service Request can not be accepted by the network.
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 by MME during a Service Request:
Optionally perform authentication if required by network vendor.
Request eNodeB to establish UE context.
Send Modify Bearer Request to SGW with eNodeB IP address.
For details about each step of a call flow, refer to 3GPP Technical Specifications 23.401
and 24.301.
UE
MME
eNodeB
Serving GW
PDN GW
PCRF
HSS
1. NAS: Service Request

2. NAS: Service Request
3. Authentication/Security
4. S1-AP: Initial Context Setup Request
5. Radio Bearer Establishment
6. Uplink Data
7. S1-AP: Initial Context Setup Complete
(A)

Figure 8-50: UE Triggered Service request Procedure
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
475 / 652
8.1.30.1
Message collision handling
During the Service Request (SR) procedure, the MME handles message collisions as
follows:
While an SR or extended service request (ESR) is in progress, if the MME

receives any of the following, then the in-progress SR/ESR is aborted and the
newly-requested procedure initiated:
another service request,
Attach Request,
Tracking Area Update

The MME sends the Downlink Data Notification Acknowledgement with cause
value Request Accepted if the Down Link Data Notification message is received
during SR and ESR procedure. All other S11 messages are ignored.
The MME aborts the SR and ESR procedure if UE requested Detach is received
and processes the UE initiated Detach.
The MME aborts the SR and ESR procedures if the MME needs to implicitly
Detach.
The MME deletes bearer collisions with Service Request that follow an abnormal
release of UE S1 connection. An abnormal UE S1 connection release results in
deactivating the GBR and while MME is in the process of deactivating the GBR
bearer, Service Request is received from the UE.
The collision is handled as follows:
MME does not delete the GBR while waiting for S1AP RELEASE REQUEST
COMPLETE message from the eNB or until the S1ap-ue-context-release-timer
is expired. The timer default value is 8 seconds.
If the MME has not started the S1 release procedure then the MME will not
delete the GBR bearers. The MME will proceed with the Service Request.
If MME has started the S1 release procedure then the MME would wait for the
completion of the procedure and then proceed with the Service Request.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
476 / 652
8.1.30.2
Roaming
Value Pairs (AVPs) in the UE subscriber data in the following order (if the S-TMSI/GUTI
received in the SR/ESR request is assigned by the MME and the MME has valid UE
context):
Provisioned
Network
Access
Mode
NetworkAccessMode AVP
Packet and
circuit
Packet and
circuit
Packet and
circuit
Packet and
circuit
Provisioned
CSFB_2G3G
Enabled
Not Enabled
Provisioned
CSFB_DTR
Not Enabled
Enabled
Combined
Attached
UE
ESR
Actions
Yes
ESR
for
2G3G
CSFB
is
processed
No
CSFB
DTR ESR
procedure
is run.
Table 17: Service Request Roamer Handling
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
477 / 652
8.1.30.3
Service Request Rejection
The MME rejects any Service Request if
UE HPLMN is not allowed. MME imposes this restriction if the UE's HPLMID is
not provisioned on MME, or the UEs PLMN is provisioned without a Roaming
Agreement ( no UE PLMN Services entry) with this served PLMN, or the UE's
PLMN roaming agreement (UE PLMN Services entry) for this served PLMN has
the parameter LTE Roaming Allowed set to false. If the UE has a roaming
agreement with this served PLMN, the MME will send the NAS Cause code
defined in LTE PLMNNotAllowed profile of RestNasMappingProfile associated
with the UE's roaming agreement; otherwise, the MME will send the NAS cause
code defined in LTEPLMNNotAllowed attribute of RestNasMappingProfile for the
Served PLMN. Refer to Table 22 (Annex A.2 of [R08]) for a complete list of NAS
cause values.
The MME determines that TAI is not allowed. The MME may be provisioned
provisioned on the MME for that zone code.
The MME uses the cause CS domain not available in the reject message for all the
reject cases shown in the following table.
Provisioned
Network
Access Mode
NetworkAccess-Mode
AVP
Provisioned
CSFB_2G3G
Provisioned
CSFB_DTR
Combined
Attached UE
Packet Only
NA
NA
NA
NA
Packet
Circuit
and
Packet Only
NA
NA
NA
Packet
Circuit
and
Packet
Circuit
and
Enabled
Not Enabled
No
Packet
Circuit
and
Packet
Circuit
and
Enabled
Enabled
No
Table 18: Service Request Rejection Scenarios
8.1.30.4
S1-AP Reset
If the MME receives an S1-AP RESET during the Service Request procedure, the MME
aborts the procedure and deactivates the bearers if any bearers are activated.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
478 / 652
8.1.31 PAGING PROCEDURE
8.1.31.1
Paging Strategy
Paging is initiated when a packet arrives for an idle endpoint. Figure 8-49 shows the
message flow associated with paging. The paging strategy needs to be a balance of
paging effectiveness (number of paging messages sent per page), paging efficiency
(number of paging attempts made before success), and magnitude of signaling load
associated with each UE (TAU Requests). The MME allows up to four paging attempts
and provides four different paging methods for use on each attempt. Additionally, the
MME supports defining independent paging strategies for basic paging within the LTE
network (basic), SGs-based CSFB (SGS_CS), SMS interworking with GSM/UMTS
(SGS_PS), S102-based CSFB (S102) and a different paging strategy for each QCI
value (Basic_QCI_1 .. Basic_QCI_9).
eNB
MME
eNB
Session
Manager
2
S-GW
1
P-GW
Uplink u-plane
Downlink u-plane
c-plane
INVITE sip:19745500055@ims.
Via: SIP/2.0/UDP 10.10.112.1
Max-Forwards:70
4
eNB
Figure 8-51: Paging Message Flow

Step
Description
Packet (e.g., VoIP call setup) arrives for UE at SGW.
SGW notifies MME that a packet has arrived for an idle UE; SGW queues
packet.
MME sends paging message to each eNB in UEs registered tracking

area(s). Note: this could be a large number of eNBs.
UE requests service from MME and establishes a radio bearer with eNB.
MME signals bearer path to SGW.
SGW forwards packet to UE.
8.1.31.2
Paging Initiated By MME
The Paging procedure is initiated by the MME to establish a NAS signaling connection
to the UE when notification is received from the Serving Gateway (SGW) that data
packets need to be delivered to the UE.
Paging is part of the Network Triggered Service Request procedure such that:
MME sends a Paging message to the eNodeBs

The set of eNodeBs that are sent Paging messages is based upon the current
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
479 / 652
paging method and the last known location of the UE (for example, page all
eNodeBs in the last seen tracking area).
eNodeBs page the UE

When a UE receives the Paging message, a Network Triggered Service Request
Procedure is initiated.
UE responds with a Service Request.
For details about each step of a call flow, refer to 3GPP Technical Specification 23.401.
Figure 8-52: Procedure - Paging

The following Paging methods (along with related timers and number of attempts) may
be provisioned on the MME by the service provider:
Last Seen eNodeB : (pages the eNodeB that sent the last TAU Request or
Service Request). The last seen eNodeB field is set by the Attach, TAU, and
Service Request procedures.
Last Seen eNodeB List : (pages up to five of the last seen eNodeBs based on
the UEs past mobility history. The maximum number of eNodeBs to be paged
during a page attempt can be specified as a parameter with the Paging Policy
table record. If no value is specified, default number of eNodeBs paged is 3.)
The Last Seen eNodeB List paging method can be used in cases where a more
aggressive paging method is desired than the Last Seen eNodeB paging
method. It provides better paging success rate than the existing Last Seen
eNodeB paging method, without resorting to paging an entire tracking area as
with the Last Seen Tracking Area paging method.
Last Seen Tracking Area: (pages eNodeBs in the TA associated with the last
TAU Request or Service Request). The last seen TA field is set by the Attach,
TAU, and Service Request procedures.
Last Seen Tracking Area plus Neighboring Tracking Areas : (pages eNodeBs
associated with the Last Registered TAI, the TAIs of each defined neighbor of
the Last Registered TAI, the Old Last Registered TAI (if available), the Older
Last Registered TAI (if available), and the Last Seen TAI (if different from all
other TAIs already included). This ensures that the UE is paged in all of the
TAIs where the UE is registered.
The list of Neighbor TAs is provisionable at MME.

Note: For roamers, the MME does not send an S1-AP Paging message to any TAI
which is forbidden due to the regional subscription or due to provisioned forbidden
TAIs. A list of Neighbor TAs is provisioned at the MME.
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
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
480 / 652
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.
Note: Each Paging attempt can be individually associated with a Paging method. There
can be up to 4 attempts.
The following key tasks are performed by the MME during Paging:
Send initial Paging message. The UE should respond to a Page with a Service
Request.
If Paging timer expires, increment the number of attempts.
Use Paging Attempt Count to select the method for the next page.
If no response from UE after the provisioned number of attempts have been

made, MME sends a Downlink Data Notification Failure to SGW.
Figure 8-51 below is an example of a paging policy.
Figure 8-53: Paging attempts to eNodeBs

Legend:
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.
In this example, TA2 was the last seen TA, and TA1 and TA3 are neighbors of TA2:
Issue 11.01
Page attempt 1: Last-seen eNodeB.

Page attempt 2: Last-seen TA
Page attempt 3: Last-seen TA + neighbor TAs
LTE/DCL/APP/031094
Nokia 2016
481 / 652
8.1.31.3
Paging Policy Selection Based on QCI
The MME may select different paging strategies for best effort and dedicated bearer
calls, extending the paging strategy provisioning per Quality of Service Class Identifier
(QCI).
The S11 Downlink Data Notification (DDN) message from the SGW may include one or
more bearer IDs (that is, an indication of what bearer(s) has data that needs to be
transmitted to the UE).
The MME obtains the QCI of the bearer ID received in the DDN message from the UE
context data and selects the paging strategy provisioned for that QCI.
Paging Type
Paging Type
Value
Description
Basic
Default paging policy for UE reactivation
Basic_QCI_1
Optional paging policy for bearers with QCI 1
Basic_QCI_2
Basic_QCI_3
Basic_QCI_4
Basic_QCI_5
Basic_QCI_6
Basic_QCI_7
10
Basic_QCI_8
11
Basic_QCI_9
12
If the SGW sends multiple bearer IDs, then the MME selects the paging strategy of the
lowest QCI of the QCIs associated with the bearer received in the DDN message.
If the SGW sends no bearer IDs, or no paging policy has been provisioned for the QCI
value associated with the specified bearer IDs, the MME will select the "basic" paging
policy as a default.
Note that this feature requires both the MME and the SGW to support R10 S11
Downlink Data Notification message (refer to 3GPP TS 29.274) with the EPS Bearer ID
information element (IE). The Allocation/Retention Priority information element is not
used, meaning that the MME ignores the Allocation/Retention Priority IE if it is included
in the DDN message.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
482 / 652
8.1.31.4
Paging Initiated By MSC/VLR
MSC/VLR may send a SGsAP-PAGING-REQUEST message to a UE. This procedure

applies to UEs that are simultaneously attached for EPS services and non-EPS
services or for EPS services and SMS only.
When a MSC/VLR has to page a UE, the MSC/VLR checks whether the MSC/VLR has
an SGs association for that UE.
The MSC/VLR sends SGsAP-PAGING-REQUEST messages to the MME if one of the
conditions following is true:
if the state of the SGs association for the UE is SGs-ASSOCIATED, LAUPDATE-PRESENT, or
if 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 MSC/VLR also
performs a search procedure (as specified in 3GPP TS 23.018).
If the "Confirmed by Radio Contact" restoration indicator is set to "true", the

MSC/VLR includes the Location area identifier information element into the
SGsAP-PAGING-REQUEST message, otherwise (i.e. after a MSC/VLR failure),
the MSC/VLR does not include the Location area identifier information element.
The sending of the SGsAP-PAGING-REQUEST message does not change the state of
the SGs association with the MME.
MME handles the paging request depending on the state of the SGs association and
the EMM context variables at the MME.
If the UE is unknown and the "MME-Reset" restoration indicator at the MME is

set to "false", the MME returns an SGsAP-PAGING-REJECT message to that
MSC/VLR indicating in the SGs cause information element "IMSI unknown".
If the UE is unknown and the "MME-Reset" restoration indicator at the MME is

set to "true"
and the SGsAP-PAGING-REQUEST message includes 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
information element.
and 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, or the tracking areas served by the MME and by the MSC/VLR.
If the IMSI Paging in All MME serving Areas global parameter is enabled and theMMEReset restoration indicator is false, the MME pages the UE with the IMSI and PS
indicator.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
483 / 652
Parameter
IMSI Paging in All MME Serving Areas
SAM Table Name
Global Parameters
OSS ID
gParmName
String
IMSI_Paging_in_All_MME_Serving_Areas
Range & Unit
gParmValue
Boolean
Yes or No
Impact of Change
No service impact.
Value
If the UE is known
and the UE is considered to be IMSI attached for EPS and non-EPS services (i.e. the
SGs association is not in the state SGs-NULL), the MME pages the UE based on the
location information stored in the MME.
and the UE is marked as IMSI detached for EPS services or IMSI (implicitly or explicitly)
detached for non-EPS services (i.e. the state of the SGs association is SGs-NULL), the
MME returns an SGsAP-PAGING-REJECT message to that MSC/VLR indicating in the
SGs cause information element the detach circumstance.
and the UE is marked as unreachable, indicated by Paging Proceed Flag set to "false",
the MME returns an SGsAP-UE-UNREACHABLE message to that MSC/VLR indicating
in the SGs cause information element "UE unreachable". The state of the SGs
association does not change at the MME.
If the UE is known, the Paging Policy used for page requests from the MSC/VLR is
based on the domain type (CS=circuit-switched or PS=packet-switched) as shown in
the following table.
Paging Type
Paging Type
Value
SGS_CS
SGS_PS
Description
Paging policy for SGs paging requests in
circuit-switch mode
Paging policy for SGs paging requests in
packet-switch mode
For roamers, the MME rejects any SGsAP-PAGING-REQUEST message if:
CSFB_2G3G is restricted for the HPLMN of the UE.
CSFB Not Preferred is restricted for the HPLMN of the UE.
SMS only is restricted for the HPLMN of the UE.
This paging procedure ends upon expiry of the timer, receipt of an SGsAP-PAGINGREJECT message, SGsAP-UE-UNREACHABLE message, or SGsAP-SERVICEREQUEST message.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
484 / 652
Several timers are used to define SGs interface behavior. The timers are defined via the
Timer form on the provisioning web interface. The form provides default values for each
of the SGs timers, but the form should be reviewed to determine whether or not the
defaults provide adequate performance. Updates should be made to the Timer form as
required.
Parameter
SAM Table Name
OSS ID

Timer
timerName
Choice List
Range & Unit
timerUnit
timerName)
seconds
timerValue
Integer
Impact of Change
No service impact.
Value
Displayed
Name
timerName
timerValue
(Range)
Default
Value
Purpose
TS6-1
TS6_1
10 90 seconds, 1
second increments
41 seconds
Guards the Location Update

procedure
TS8
TS8
1 30 seconds, 1
second increments
4 seconds
Guards the Explicit IMSI

Detach from EPS Services
procedure
TS9
TS9
1 30 seconds, 1
second increments
4 seconds
Guards the Explicit IMSI

Detach from non-EPS
Services procedure
TS10
1 30 seconds, 1
second increments
4 seconds
Guards the Implicit IMSI

Detach from non-EPS
Services procedure
TS12_1
8 23048
seconds, 60
second increments
11168
seconds
Controls the resetting of the

MME-Reset variable.
TS10
TS12-1
Issue 11.01
TS12-2
TS12_2
1 120 seconds, 1
second increments
4 seconds
Guards the MME Reset

procedure. There is one
Ts12-2 timer per MME SGs
association with a VLR.
TS13
TS13
1 32 seconds, 1
second increments
4 seconds
Guard the implicit IMSI

detach from EPS services.
LTE/DCL/APP/031094
Nokia 2016
485 / 652
Displayed
Name
SGs
Paging
timerName
SGs_Pagin
g
timerValue
(Range)
1 25 seconds, 1
second increments
Default
Value
Purpose
6 seconds
Defines the value for

receiving responses to an
SG paging request. If this
timer expires before the UE
responds with a Service
Request, the PCMD record
can be pegged as ended,
and the PM counts
associated with SGs and
with Paging can be pegged
for the failure to locate the
UE.
Table 19 SGs Timers

Rule: Ts6-1 Relationship to Other Timers
The value of Ts6-1 should be 2 times the max transmission time over SGs, plus the
Supervision Timer of the Update Location procedure, as defined in TS 29.118.

The value of Ts12-1 should be greater than the longest Tracking Area Update time
(T3412) running on the MME, plus the transmission time over the air interface.

The value of Ts12-2 in relationship to other timers is defined in TS 29.118 v8.0.0,
Section 10.
Rule: SGs Paging Relationship to Other Timers
The value of SGs Paging should be less than the paging timer value provisioned in
the MSC/VLR.
The MME is provisioned with two paging profiles to indicate the paging strategy to use
for SGs initiated paging; one profile for paging for CS and one profile for paging for PS.
Paging profiles are indicated by the Paging Type parameter. See Section 8.1.31.9.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
486 / 652
8.1.31.5
SGs Paging Enhancements
When the Retry Paging for SGs Page Request global parameter is set to No, the MME
proceeds with the next page attempt when the MSC sends another SGs Page Request.
In this mode of operation, the MSC controls paging retries. If the Retry Paging for SGs
Page Request global parameter is set to Yes, the MME performs automatic paging
escalation for the SGS_CS and SGS_PS paging types. When the MME receives a SGs
page request, it executes the entire provisioned paging policy for that paging type
(SGS_CS or SGS_PS) to reach the UE, if needed.
The trigger for moving on to the next page attempt is the timeout of the previous
attempt. In this mode of operation, the MME controls paging retries.
The default value for Retry Paging for SGs Page Request is No.
Parameter
Retry Paging for SGs Page Request
SAM Table Name
Global Parameters
OSS ID
gParmName
String
Retry_Paging_for_SGs_Page_Request
Range & Unit
gParmValue
Boolean
Yes or No
Issue 11.01
Impact of Change
No service impact.
Value
LTE/DCL/APP/031094
Nokia 2016
487 / 652
8.1.31.6
Network-Initiated Paging
MME supports a flag indicating whether support for SGW Geo-redundancy is turned ON
or OFF (enabled by default). If the flag is turned OFF, the MME ignores the special
cause code #254 received in the Downlink Data Notification (DDN) message and
processes the DDN message as usual.
Figure 8-54 Network-initiated Paging

When the flag is turned ON, the MME assists the SGW to achieve SGW Georedundancy through resilience approach whereby when the primary SGW fails, adjacent
nodes such as MME and PGW are not made aware of the failure, the IP address is
assumed by backup SGW, path management is kept alive by the backup SGW, and
UEs are all maintained in Idle mode.
When the newly active SGW receives control messages, it sends a Downlink Data
Notification (DDN) to the MME with special cause code #254 to restore the S1-u DL
path and UE is ready to process control plane or data plane traffic.
Upon receiving a DDN message with special cause code #254 from the SGW, the
MME:
1. Sends a DDN Acknowledge message to SGW for Connected UE (if the UE is
Idle then existing behavior is applied).
2. Sends a Modify Access Bearer Request message (containing only the Bearer
Context IE [bearer ID and S1-U eNodeB FTEID]) to the SGW (including all of
the PDN session(s) data in one message).
Note: The MME does not wait for the response from the SGW and ignores the response
if received from SGW. The MME does not retransmit the Modify Access Bearer Request
to SGW since SGW retries the same Downlink Data Notification message if the Modify
Access Bearer is lost or not received.
Due to the existing communication between the MME and the SGW (by virtue of the
DDN, DDN Acknowledge exchange for the special cause code), it is evident that the
SGW supports this functionality. Thus, the MME assumes that the SGW is capable of
also receiving the Modify Access Bearer Request message, and therefore does not
send the Sending Node Features information element in the Echo Request/Response
message.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
488 / 652
8.1.31.7
SGs-AP Paging Request
A new MME or restarted MME handles SGsAP-PAGING-REQUEST as specified in

Figure 8-55 if the CS restoration indicator bit of the Additional paging indicators IE is
set for a signaling only UE.
eNB
UE
SRS
MME
SGW
If IWSSMS detects MME or SGs failure, IWSSMS may

send SGsAP-PAGING-REQUEST message with IMSI
to recover the UE
1. SGsAP-PAGING-REQUEST with IMSI
2a. Retrieve UE
Restoration Data
Request
2b. Retrive UE
Restoration Data
Response
MME Pages the UE using the S-TMSI obtained from

the SRS in the paging area (last seen eNB and last
seen TA) which is also obtained from the SRS.
3. S1-AP PAGING
UE responds to the paging message with

SR. SMS services are recoevered along
with the EPS services.
eNB
UE
SRS
MME
SGW
Figure 8-55 Handling of SGs Paging Request after MME failure or Restart.
8.1.31.8
During the Paging procedure, the MME handles message collisions as follows:
Upon receipt of a Cancel Location Request from HSS, any Paging procedure in
progress for the associated UE is stopped. No further Paging messages is sent
for the current UE connection.
Upon receipt of any NAS message other than Service Request from the UE while
the Paging procedure is in progress, no further page attempts is made for the
current network initiated service request and the MME sends a Downlink Data
Notification Failure message to the Serving Gateway with a cause code of
Service denied.
Upon receipt of a Downlink Data Notification message while a UE triggered

Service Request procedure is in progress, the MME will not page the UE. It
responds with a Downlink Data Notification Ack and proceed with the UE
triggered Service Request procedure.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
489 / 652
If the MME receives Downlink Data Notification (DDN) message with the special
Cause Code #254 during a procedure:
going from ECM_IDLE to ECM_CONNECTED, MME sends Downlink Data

Notification Acknowledge message with cause "Unable to Page UE" and
continues the procedure.
going from ECM_CONNECTED to ECM_IDLE and if Release Access Bearer

Request has already been sent to SGW, MME sends Downlink Data Notification
Acknowledge message with Cause Code Unable to Page UE to SGW.
If the MME receives TAU request with Active Flag indicating Bearer
Establishment, for the paging portion, the MME treats this similar to receiving
Service Request
If the MME has ongoing paging for DDN and receives TAU request with Active
Flag indicating no Bearer Establishment three configurable options are provided
:
The TAU DDN Collision global parameter allows to configure the MME handling
of reception of TAU request while MME processing Downlink Data Notification.
Fail DDN: This option preserves the current behavior (behavior supported until
WM8.1.0). MME sends DDN failure with cause #89 and proceed with TAU.
Re Page: MME stops paging and proceeds with the TAU request. After TAU is
complete and S1 release done, MME pages the UE. MME uses the provisioned
paging procedure just as original page used.
Treat as SR: MME treats the TAU request without the Active Flag set in the
EPS Update IE as a TAU request with the Active Flag set and sends S1AP
INITIAL UE CONTEXT REQUEST to set up the bearers. This option basically
eliminates the need to page the UE.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
490 / 652
8.1.31.9
Provisioned Paging Parameters
The paging method is defined via the Paging Policy page on the provisioning web
interface. 23 paging profiles can be defined; one for SGs initiated paging for CS, one for
SGs initiated paging for PS, one for S102 paging, a basic paging profile, one profile for
each of the QCI values (1 9), one for LPA UEs, one for SxnRestoration (SRS), and 6
for user defined paging profiles. A total of four successive paging attempts can be
defined for each profile. Each paging attempt using one of four methods (last seen TAI,
last seen eNB, or Last seen eNB List, or Last Seen Neighbor TAIs.) A single method
can be used more than once within the paging policy. Each paging attempt is also
provisioned with an indicator of whether of not to use an extended range for paging and
a timer (T3413) defining the time to wait until proceeding to the next paging attempt.
The default paging policy is described below. The Paging Policy form should be
reviewed to determine whether or not the defaults provide adequate performance.
Updates should be made to the Paging Policy form as required.
WM10.0.0 release provides a separate paging policy for LPA devices to allow most
efficient paging for the UEs that are stationary by limiting the paging area to few last
seen eNB. The rationale for this, is that we know LPA uses will not have as much
mobility as regular UEs.
Engineering Recommendation: Paging Policy
Service providers are encouraged to define a paging policy based on their individual
needs and preferences. At this time, the default values listed on the Paging Policy
form are the most benign to the network (but may not be the best overall paging policy
for the provider.) Users are encouraged to review the form to ensure compatibility with
their network.
Engineering Recommendation: Final Paging Attempt

It is strongly recommended that the Last Seen Tracking Area plus Neighboring
Tracking Areas method be utilized for the final page attempt in the MME Paging
Policy. If this method is not used for any page attempt, then it is possible for a UE to
move within its set of registered tracking areas and not receive page messages at its
current location.
Figure 8-56: Paging Policy

Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
491 / 652
Parameter
Paging Type
SAM Table Name
Paging Policy
OSS ID
ltemme.PagingPolicyAbs.pagingType
Range & Unit
Choice List
Basic
Basic_QCI_1
Basic_QCI_2
Basic_QCI_3
Basic_QCI_4
Basic_QCI_5
Basic_QCI_6
Basic_QCI_7
Basic_QCI_8
Basic_QCI_9
LPA
Restricted
S102
S102_CS
SGS_CS
SGS_PS
SxnRestoration
UserDefPaging1
UserDefPaging2
UserDefPaging3
UserDefPaging4
UserDefPaging5
UserDefPaging6
Impact of Change
No service impact.
Value
Parameter
Attempt
SAM Table Name
Paging Policy
OSS ID
ltemme.PagingPolicyAbs.attempt
Range & Unit
Choice List
Attempt 1
Attempt 2
Attempt 3
Attempt 4
Issue 11.01
Impact of Change
No service impact.
Value
LTE/DCL/APP/031094
Nokia 2016
492 / 652
Rule: Adding Paging Attempts

The first paging attempt must be populated with a Paging Method. Subsequent
paging attempts, when populated with a Paging Method other than none, must be
populated in order.
Rule: Deleting Paging Attempts

Only the last paging attempt in a sequence of attempts can be deleted.
The paging method defines the set of eNBs that are paged for the associated paging
attempt. A Paging Method may be assigned to more than one paging attempt.
Parameter
Method
SAM Table Name
Paging Policy
OSS ID
ltemme.PagingPolicyAbs.method
Range & Unit
Choice List
- LastSeenENB (the eNB last seen by the UE)
- LastSeenENBList (up to 5 of the last seen eNB in the UEs
mobility history)
- LastSeenTAI (all eNB in the TAI last seen by the UE)
- LastSeenTAINBTAI (all eNB in the TAI last seen by the UE
plus all eNB in all TAIs provisioned as Neighbor TAI)
Impact of Change
No service impact.
Value
Operator Dependent; default = Last Seen TAI
Parameter
Maximum Number of eNBs Paged
SAM Table Name
Paging Policy
OSS ID
ltemme.PagingPolicyAbs.MaxEnbsPaged
Range & Unit
Integer
[0..5]
Impact of Change
No service impact.
Value
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
493 / 652
Provisioning of the TAI Neighbor List is optional if the only Paging Method is Last
Seen eNB.
The TAI Neighbor List is not utilized with the Last Seen eNB Paging Method. The
values in the list and settings of associated global parameters are irrelevant.
The extended range flag defines the set of TAI values sent in the paging message.
Parameter
Extended Range Flag
SAM Table Name
Paging Policy
OSS ID
ltemme.PagingPolicyAbs.extRangeFlag
Range & Unit
Boolean
Impact of Change
No service impact.
Value
(See Table 17 for definition.)
MME includes the UE Radio Capability for Paging IE in S1AP PAGING message if the
UE CAPABILITY INFO INDICATION MESSAGE for paging information is available in
the UE context.
Internal : As per TS 23.401, the UE paging info needs to be sent to the new/target MME
in MM context in GPTv2 messages. However, IE is not yet defined in TS 29.274.
Parameter
UE Radio Capability for Paging
SAM Table Name
Paging Policy
OSS ID
ltemme.PagingPolicyAbs. UE Radio Capability for Paging
Range & Unit
Boolean
Impact of Change
No service impact.
Value
The following table summarizes the correlation between Paging Method and TAI values
sent in the paging message when the extended range flag is true and false.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
494 / 652
Set of Paged eNBs

(eNB Set)
Paging Method
Last Seen eNB
eNB in which the UE

was last seen
Cells Paged Within the eNB

( TAI Values )
Extended Range =
False
Extended
Range = True
Only cells withTAI

in which the UE
was Last Seen.
All the cells

from the TAIs
associated with
the Last seen
eNB
All the cells
served by each
eNB
Last Seen eNB

List
Up to 5 of the eNBd
in which the UE was
most recently sees
Only cells with

TAIs in UEs
registered tracking
area list (last seen
TA)
Last Seen
Tracking Area
(TA)
All eNBs in the TAI

where the UE was
last seen.
Only cells withTAI

in which the UE
was last seen.
All the cells

served by each
eNB
Cells that have

either the TAI in
which the UE was
last seen, or a
Neighbor TAI.
All TAIs served

by each eNB.
Last Seen TA +
Neighbor TAs
All eNBs in the TA

where the UE was
last seen plus any
provisioned neighbor
TAs .
Table 20: TAI Values in Paging Messages

Each paging attempt is provisioned with its own T3413 timer. The timer defines the
time to wait until proceeding to the next paging attempt. The value of the timer should
exceed the time it takes a UE to respond to a page message.
Parameter
T3413 Timer
SAM Table Name
Paging Policy
OSS ID
ltemme.PagingPolicyAbs.t3413Timer
Range & Unit
Integer
[1..60] sec
Impact of Change
No service impact.
Value
Rule: T3413 Timer Value

The value of the T3413 timer should exceed the time it takes a UE to respond to a
page message.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
495 / 652
A paging gap timer is also available to indicate that the MME should suppress
excessive paging a UE until the timer expires. The timer starts after multiple
consecutive no page response failures have occurred while attempting the reach the
UE. The MME counts the consecutive 'no page response' failures for each UE. This
count increment when all provisioned number of 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 paging attempts, the MME
application begins suppressing new page requests for this UE and continues for the
duration of time specified by the Paging Gap Timer.
After the interval of time specified by the Paging Gap Timer has elapsed, the MME
again performs paging of the UE when new page requests are received from the SGW
and MSC. However, 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 eNB and the MME application
receives an indication of the UE's current location.
Internal:
When paging is being suppressed by the MME due to the Paging Gap feature, the MME
responds to a Downlink Data Notification (DDN) in the same way it does as when
paging is suppressed by UE inactivity. A DDNACK with a cause value of
UNABLE_TO_PAGE_UE is sent to the SGW
Parameter
Paging Gap Timer
SAM Table Name
Timer
OSS ID
timerName
Choice List
Paging_Gap_Timer
Range & Unit
timerUnit
timerName)
minutes
timerValue
Integer
[1..1440] minutes
Issue 11.01
Impact of Change
No service impact.
Value
Operator Dependent; default = 0, functionality is

disabled
LTE/DCL/APP/031094
Nokia 2016
496 / 652
Additionally, the MME is provisioned with a global parameter to indicate the maximum
number of paging attempts to use during UE load balancing (Nbr Page Atts UE Load
Balancing).
Parameter
Nbr Page Atts UE Load Balancing
SAM Table Name
Global Parameters
OSS ID
Range & Unit
gParmName
String
Nbr_Page_Atts_UE_Load_Balancing
gParmValue
Integer
[1..4]
Impact of Change
No service impact.
Value
Rule: Max Value for Nbr Page Atts UE Load Balancing

The value of Nbr Page Atts UE Load Balancing cannot exceed the number of
provisioned paging attempts in the paging policy.
An overload control mechanism that restricts the use of more aggressive paging
methods during major overload. When the Restricted paging during overload is
enabled, only a single of page attempt is allowed and the paging method allowed is
either Last Seen eNB or Last Seen ENB List.
The Restrict Paging during Overload global parameter controls restricted paging and is
disabled by default.
By automatically switching to the restricted paging type during a major overload, the
number of S1 PAGING message generated by the MME application should be
dramatically reduced, because this overload control mechanism avoids S1 PAGING
message fan-out from the use of more aggressive paging methods such as Last Seen
TAI.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
497 / 652
8.1.32 INTER-ENODEB X2-BASED HANDOVER PROCEDURE
The Inter-eNodeB X2-based handover (X2 to X2) make use of X2 connectivity between
eNB to directly exchange handover messages between source and target eNB. In X2
based handovers, the new eNB reconfigures the Radio Resource Control (RRC)
connection and an uplink is established. The new eNB then sends a Path Switch
Request to the MME to initiate the GTP tunnel redirection. The MMEs role is to redirect
GTP tunnels at the SGW to the new target eNB. The MME and SGW are not relocated.
The new eNodeB reconfigures the Radio Resource Control (RCC) Connection and an
uplink is established before the Path Switch Request is sent to the MME. Once the RRC
reconfiguration is complete, the new eNodeB sends a Path Switch Request to the MME
to initiate the GTP-U tunnel redirection.
Figure 8-57: Inter-eNodeB X2-based handover

Legend:
1. UE moves to another eNodeB. The Radio Resource Connection (RCC) is
reconfigured.
2. The new eNode B sends a path switch request to the MME.
3. The MME initiates a GTP-U tunnel redirection to the SGW. The SGW switches the
endpoint to the new eNodeB.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
498 / 652
Key tasks performed by MME during X2-based handover:
Upon the receipt of the Path Switch message from the new eNodeB, send an
Update User Plane Request to the SGW.
The SGW switches the downlink path to the IP address of new eNodeB.
Delete existing bearers not listed in the S1-AP path request.
Update UE context parameters.
Updated parameters for the UE context in the MME include:

Last visited eNodeB
Current eNodeB
eNodeB S1AP ID
Updated Bearer contexts with SGW IP address and Tunnel Endpoint Identifier (TEID)
Bearers that target eNodeB could not set up are deleted
provisioned UEs time zone to the SGW in the Modify Bearer Request message (for an
X2-based handover procedure without SGW relocation) and in the Create Session
Request (for an X2-based handover procedure with SGW relocation).
The UE initiates a Tracking Area Update to inform the MME of its new location.
For details about each step of a call flow, refer to 3GPP Technical Specifications 23.401
and 29.274.
UE
Source
eNodeB
Target
eNodeB
Downlink and uplink data
MME
Serving
GW
PDN GW
Handover preparation
Handover execution
Forwarding of data
Handover completion
Downlink data
Uplink data
1 Path Switch Request
Downlink data
2 Modify Bearer Request

3a Modify Bearer Request
3b Modify Bearer Response
(A)
4 Modify Bearer Response
5. End marker
5. End marker
6 Path Switch Request Ack
7 Release Resource
8. Tracking Area Update procedure
Figure 8-58: Call flow - Inter-eNodeB X2-based Handover without SGW Relocation
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
499 / 652
8.1.32.1
During the Handover (HO) procedure, the MME handles message collisions as follows:
MME ignores any UE ESM (except the UE initiated Detach and EMM) messages
and also S11 network messages during X2 handover. If UE Detach message is
received during the X2 handover, MME aborts the procedure and progresses the
Detach.
MME, if needed to explicitly or implicitly detach the UE for any errors, MME
proceeds with Detach aborting the handover.
MME queues any HSS message received during X2 handover procedure. MME
takes action on the HSS message after the completion of the message.
MME queues any network initiated ESM requests if the eNB rejects any E-RAB
management messages with cause X2 Handover triggered. MME handles X2
HO that may occur at three different stages of the ESM procedure as follows:
8.1.32.2
Neighbor Information Collection
In order to establish SCTP associations with its neighbors, an eNB obtains IP address
of its neighbor eNBs from MME by sending eNB global ID to the MME; thus eliminating
manual provisioning of eNB neighbors. The following figures reflect the flow of the
S1AP class 2 elementary procedures ENB Configuration Transfer and MME
Configuration Transfer used for neighbor information collection.
These procedures are detailed in 3GPP TS 36.413.
Figure 8-59: Call flow Configuration Transfer for Automatic Neighbor Relation (single
MME)
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
500 / 652
Legend:
1
New neighbor relation has been (partially) defined: only PCI and ECGI of
the potential neighbor cell are known. IP address of the hosting eNB needs
to be acquired.
If S1 based solution has been selected, then ENB CONFIGURATION
TRANSFER message is built, including:
Target Global eNB Id and TAI (extracted from the cell ECGI)
Source Global eNB Id and TAI
SON Information Request IE set to X2 TNL Configuration Info to request
X2 IP address
ENB CONFIGURATION TRANSFER message sent to MME.
3, 4
When the message is received by the MME, SON Configuration Transfer

IE is transparently copied to MME CONFIGURATION TRANSFER
message that is sent to the eNB identified through received Target eNB-ID.
When MME CONFIGURATION TRANSFER message is received by the

target eNB, target eNB sends back ENB CONFIGURATION TRANSFER
message to the MME. SON Information Reply IE contains the X2 TNL
Configuration Info that carries the IP address.
As previously, when receiving the message, the MME transparently copies

SON Configuration Transfer IE into MME CONFIGURATION TRANSFER
message that is sent to the source eNB.
Source eNB receives the message and extracts target eNB IP address
from it.
Configuration transfer works similarly when dealing with MME pools. SON information is
transparently sent. The only difference being that a configuration transport tunnel is
established between the MME pools.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
501 / 652
Figure 8-60: Call flow Configuration Transfer for Automatic Neighbor Relation (MME
Pools)
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
502 / 652
8.1.32.3
S1-AP Reset
If an S1-AP RESET message is received from the source eNB during the X2-based
handover, the MME ignores the message.
If an S1-AP RESET message is received from the target eNB during the X2-based
handover, handling is as follows for different scenarios:
No SGW relocation - MME changes the state of UE to ECM-IDLE and

deactivates all the bearers.
SGW relocation - MME completes the SGW relocation, deletes the bearers on
the old SGW, deactivates the bearers, and changes the state of the UE to ECMIDLE.
8.1.32.3.1 EXTENDED QUEUING FOR ALL CSFB SCENARIOS (X2HO

TRIGGERED)
The MME supports resending or requeuing certain messages if a failure is due to an X2
Handover (X2 HO). The MME will not resend the context modification request message
if the eNB responds with a failure message other than X2HO triggered.
The following scenarios apply:
If the eNB rejects a S1AP UE CONTEXT MODIFICATION REQUEST with an

indication that rejection is due because of an X2 HO, the MME will resend the
S1AP UE CONTEXT MODIFICATION REQUEST with a CSFB indicator after the
completion of the X2 HO. Rejection of the S1AP UE CONTEXT MODIFICATION
REQUEST is indicated by the eNB responding with S1AP UE CONTEXT
MODIFICATION FAILURE with cause IE set to X2HO triggered.
During a X2 HO, an MSC sends a SGsAP-PAGING-REQUEST message which

involves sending a NAS message CS Service Notification to a UE. The MME will
send a NAS message CS Service Notification via the target eNB if the handover
is complete. If the MME receives an S1AP NAS NON DELIVERY INDICATION
message with a cause of X2HO triggered, the MME queues and resends the CS
Service Notification to the UE
If the eNB rejects a NAS Downlink NAS Transport message, the MME queues
and resends the up to three SMS messages by way of the target eNB. Rejection
is indicated by an S1AP NAS NON DELIVERY INDICATION message with the
cause set to X2HO triggered.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
503 / 652
8.1.32.3.2 ENHANCED QUEUING NETWORK INITIATED SESSION
REQUESTS FOR X2HO
MME provides queuing capability to avoid rejecting bearer management procedures
((Create Bearer Request, Delete Bearer Request, Update Bearer Request) initiated by
the network while the UE is in a handover procedure without SGW or MME relocation
that would caused delay in establishing or modifying a new bearer and result in poor
user experience.
While the X2 handover procedure is in progress, the MME may receive request for the
dedicated bearer activation / modification / deactivation from SGW, PGW.
Dedicated bearer activation / modification / deactivation procedure that are affected by
a X2-handover "in-progress" will be queued by the MME and replayed to the serving
eNodeB at the completion of the handover procedure. This only applies in the situation
where no MME change (standard behaviour for X2 HO) and SGW relocation are
involved in the HO.
If a procedure is denied or cannot be executed because the source eNodeB is
executing a X2 Handover without SGW, the MME queues the request and resumes the
procedure once the handover has been completed.
Requests are simply dropped once the Queue capacity is exceeded (maximum
supported queue depth = 3).
Following decisions are taken by MME in the following cases:
scenarios
X2 HO completion sucess
X2 HO completion failure
X2 HO without
SGW relocation
MME processes (dequeue) any

queued network-initiated bearer
requests
MME drops any

network-initiated
requests
MME drops any queued network

initiated bearer requests from the
source SGW
X2 HO with SGW
relocation
MME processes (dequeue) any

queued network initiated bearer
requests from the target SGW
queued
bearer
MME drops any queued

network-initiated bearer
requests from the source SGW
Table 21: enhanced queuing behaviors
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
504 / 652
8.1.33 INTER RAT HANDOVER PROCEDURE
The Inter RAT Handover procedure (also referred to as the SRNS Relocation
procedure) is a Handover which is triggered by a UE in CONNECTED mode. The UE
may be going from LTE (E-UTRAN) to UTRAN, or UTRAN to LTE (E-UTRAN),
otherwise known as inter Radio Access Technology (Inter RAT) handover.
The Inter RAT handover procedure relocates the UE's existing UTRAN connection from
the source SGSN and RNC to an E-UTRAN connection at the target eNodeB, MME,
and SGW. The role of the SGSN/MME is to maintain the user session continuity during
the relocation, and to work with both RNCs to complete the relocation as per 3GPP TS
23.401.
Elementary procedures that may be used during this procedure are:
Issue 11.01
Handover Required
Handover Command
Handover Preparation
Handover Preparation Failure
Handover Request
Handover Request Acknowledge
Handover Failure
Handover Notify
Handover Cancel
Handover Cancel Acknowledge
LTE/DCL/APP/031094
Nokia 2016
505 / 652
8.1.33.1
e-UTRAN to UTRAN IRAT Handover
The procedures in this section cover the UE going from LTE (E-UTRAN) to UTRAN (Iu
mode). Refer to 3GPP TS 23.401 and TS 36.413 for individual message details.
Figure 8-61: Call flow E-UTRAN to UTRAN Inter-RAT Handover with SGW Relocation
and RAU
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
506 / 652
The following procedure covers both Direct Forwarding and Indirect Forwarding.
Refer to 3GPP TS 23.401 and TS 36.413 for individual message details.
Figure 8-62: Call flow E-UTRAN to UTRAN Inter-RAT Handover with SGW Relocation
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
507 / 652
The following procedure covers both Direct Forwarding and Indirect Forwarding. Refer
to 3GPP TS 23.401 and TS 36.413 for individual message details.
Figure 8-63: Call flow E-UTRAN to UTRAN Inter-RAT Handover without SGW
Relocation
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
508 / 652
8.1.33.2
UTRAN to E-UTRAN IRAT Handover
The procedures in this section cover the UE going from UTRAN (Iu mode) to LTE (EUTRAN).
UE
Source
eNodeB
Target BSS
Source MME
Target SGSN
Source
Serving GW
Target
Serving GW
PDN GW
HSS
Uplink and Downlink User Plane PDUs

1. Handover Initiation
2. Handover Required
3. Forward Relocation Request
4a. Create Session Response
5. PS Handover Request
5a. PS Handover Request Acknowledge
6. Create Indirect Data Forwarding Tunnel Request
6a. Create Indirect Data Forwarding Tunnel Response
7. Forward Relocation Response
Figure 8-64: Call flow UTRAN Iu Mode to E-UTRAN Inter-RAT Handover, Preparation
Phase
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
509 / 652
The following procedure covers both Direct Forwarding and Indirect Forwarding. Refer
to 3GPP TS 23.401 for individual message details.
UE
Source
RNC
Target
eNodeB
Source SGSN
Target MME
Source
Target
Serving GW Serving GW
PDN
GW
HSS
Uplink and Downlink User Plane PDUs (via Source SGSN if Direct Tunnel is not used)
1. Relocation Command
2. HO from UTRAN Command
4. E-UTRAN Access Procedures

5. HO to E-UTRAN Complete
Downlink Payload User Plane PDUs (via Source SGSN if Direct Tunnel is not used)
Sending of
uplink data
possible
If Direct Forwarding applies

Via Source SGSN in case Direct Tunnel is not used
If Indirect Forwarding applies

6. Handover Notify
7. Forward Relocation Complete Notification
7a. Forward Relocation Complete Acknowledge
For Serving GW relocation Steps 8, 9 and 10,
and the following User Plane path, will be
handled by Target Serving GW
(A)

9a. Modify Bearer Response

11. Tracking Area Update procedure

12b. Iu Release
Command/Completion
(B)
12a. Delete Session Response
13. Delete Indirect Data Forwarding Tunnel Request
13a. Delete Indirect Data Forwarding Tunnel Response
14. Delete Indirect Data Forwarding Tunnel Request
14a. Delete Indirect Data Forwarding Tunnel Response
Figure 8-65: Call flow UTRAN Iu Mode to E-UTRAN Inter-RAT Handover, Execution
Phase
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
510 / 652
Refer to 3GPP TS 23.401 for individual message details.
Figure 8-66: Call flow UTRAN to E-UTRAN Hard Handover with SRNS relocation and
TAU
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
511 / 652
8.1.33.3
E-UTRAN to GERAN A/Gb IRAT Handover
The procedures in this section cover the UE going from LTE (E-UTRAN) to GERAN
(A/Gb mode) and GERAN (A/Gb mode) to LTE (EUTRAN). Procedures are shown in
Figure 8-64 through Figure 8-67. Refer to 3GPP TS 23.401 for individual message
details.
UE
Source
eNodeB
Target BSS
Source MME
Target SGSN
Source
Serving GW
Target
Serving GW
PDN GW
HSS

1. Handover Initiation
2. Handover Required
3. Forward Relocation Request
4a. Create Session Response
5. PS Handover Request
5a. PS Handover Request Acknowledge
7. Forward Relocation Response
Figure 8-67: Call flow E-UTRAN to GERAN Inter-RAT Handover, Preparation Phase
Legend:
Issue 11.01
The source eNodeB decides to initiate an Inter-RAT Handover to the target

GERAN A/Gb mode (2G) system.
The source eNodeB sends a Handover Required message to the Source MME
to request the CN to establish resources in the Target BSS, Target SGSN, and
the Serving GW. Upon receiving the request, the MME determines if the
handover is from E-Utran to Geran by determining the Handover Type IE and
the Target ID IE. If all criteria is met, (Handover Type is LTEtoGERAN, Target
Type is CGI, and GERAN is allowed), the MME continues with the handover.
Otherwise, a Handover Preparation Failure is sent to the eNB.
Based on the CGI IE value, the MME sends a DNS query to determine the
target SGSN that serves the CGI. If the query fails, the MME sends a Handover
Preparation Failure message to the eNB. If the query succeeds, the MME
initiates the PS Handover resource allocation procedure by sending a Forward
Relocation Request message to the new SGSN which contains the following:
IMSI
TEID for Control Plane
Packet Flow ID
Cell Identification
RANAP Cause
PDP Context
SGSN Address for Control Plane
LTE/DCL/APP/031094
Nokia 2016
512 / 652
Issue 11.01
MM Context
BSS Container
Charging Characteristics
Note that the Forward Relocation Request message is rejected if the eNB ID
exceeds 65535, due to a size limitation in Cell Identification IE.
The new SGSN sends a PS Handover Request message to the target BSS.
The target BSS assigns radio resources. The algorithm the BSS uses is
implementation-specific.
The target BSS prepares the target BSS to source BSS Transparent Container
which contains a PS Handover Command including the CN part (NAS container
for PS HO) and the RN part (PS Handover Radio Resources).
The target BSS sends the PS Handover Request Acknowledge message to the
new SGSN. After sending the PS Handover Request Acknowledge message,
the target BSS prepares to receive downlink LLC PDUs from the new SGSN.
The new SGSN passes information that was assigned in the RAB setup
information IE in the Forward Relocation Response to the MME. The MME
expects to receive Tunnel Endpoint Identifier Data, BSSGP Cause, BSS
Container, and the List of Setup PFC in the Forward Relocation Response.
If 'Indirect Forwarding' applies, the source MME sends a Create Indirect Data
Forwarding Tunnel Request message to the Serving Gateway indicating that
the bearer(s) are subject to data forwarding.
9a
The Serving GW returns a Create Indirect Data Forwarding Tunnel Response

message to the target MME. If the Serving GW doesn't support data
forwarding, an appropriate cause value is returned and the Serving
GWAddress(es) and TEID(s) are not included in the message.
LTE/DCL/APP/031094
Nokia 2016
513 / 652
Figure 8-68: Call flow E-UTRAN to GERAN Inter-RAT Handover, Execution Phase
Legend:
1
The MME completes the preparation phase toward the Source eNodeB by
sending the Handover Command message. The command contains:
E-RABs Subject to Forwarding List
Target to Source Transparent Container
E-RABs to Release List
The Source eNB gives a command to the UE to handover to the Target Access
System using the message HO from E-UTRAN Command.
N/A
The handover is executed according to the parameters provided in the

message delivered in step 2.
After accessing the cell using access bursts and receiving timing advance
information from the BSS in step 2, the MS processes the NAS container and
then sends one XID Response message to the new SGSN.
The MME determines, based on the configurable parameter, if direct forwarding
or indirect forwarding applies.
If direct forwarding applies, the MME sends a S1AP Handover Command
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
514 / 652
message to the source eNB.
If indirect forwarding applies, the MME sends a S11 Create Indirect Data
Forwarding Tunnel Request message to the source SGW. The Bearer Contexts
IE contains the SGW F-TEIDs for data forwarding. It expects to receive an S11
Create Indirect Data Forwarding Tunnel Response message from the source
SGW. It also sends an S1AP Handover Command message to the source eNB
either when it receives the S11 Create Indirect Data Forwarding Tunnel
Response message, or if the Create Indirect Data Forwarding Tunnel
Response message is not received.
6
After receiving the first correct RLC/MAC block (sent in normal burst format) the
target BSS sends a PS Handover Complete message to inform the new SGSN
that the MS has arrived in the target cell.
Each uplink N-PDU received by the new SGSN using the target BSS is then
forwarded directly to the GGSN.
After sending the S1AP Handover Command to the source eNB, the MME
starts the IRATHOCompletionTimer and expects to receive the Gn Forward
Relocation Complete Notification message from the Gn/Gp SGSN.
8a
After receiving the Gn Forward Relocation Complete Notification message from

the Gn/Gp SGSN, the MME stops the timer (if it is still running), starts a
RelResourceTimer, and sends a Gn Forward Relocation Complete
Acknowledge message to the Gn/Gp SGSN with Cause IE set to Request
accepted.
The new SGSN sends an Update PDP Context Request (new SGSN Address,
TEID, QoS Negotiated) message to the PDN Gateway
10
N/A
11
The PDP context fields are updated and return an Update PDP Context
Response (TEID) message. Going forward, new incoming downlink IP packets
are sent to the new SGSN.
12
If the new SGSN indicates a Reset (that is, reset to default parameters), then
on receipt of the PS Handover Complete the new SGSN initiates an
LLC/SNDCP XID negotiation for each LLC SAPI used in the LLC ADM. If the
SGSN wants to use the default parameters, it sends an empty XID Command.
If the new SGSN indicates a 'Reset to the old XID parameters', no further XID
negotiation is required for the LLC SAPIs used in LLC ADM only.
The new SGSN (re-)establishes LLC ABM for the PDP contexts which use
acknowledged information transfer. During the exchange of SABM and UA the
SGSN performs LLC/SNDCP XID negotiation.
Issue 11.01
13
The MS sends a Routing Area Update Request message to the new SGSN
informing it that the source cell belongs to a new routing area. The new SGSN
knows that a handover has been performed for this MS and excludes the
SGSN context procedures which normally are used within the RA Update
procedure.
14
When the timer started at step 8 expires, the source MME sends a Release
Resources message to the source eNodeB. The Source eNodeB releases its
resources related to the UE.
15
When the timer started in step 8 expires and if resources for indirect forwarding
LTE/DCL/APP/031094
Nokia 2016
515 / 652
have been allocated, then they are released.
Figure 8-69: Call flow GERAN to E-UTRAN Inter-RAT Handover, Preparation Phase
Legend:
1
Source BSS initiates a PS handover. Both uplink and downlink user data is
transmitted
The source BSS sends the message a PS handover Required to the Source
SGSN to request the CN to establish resources in the Target eNodeB, Target
MME, and the Serving GW.
The Source SGSN determines from the 'Target eNodeB Identifier' IE that the
type of handover is IRAT PS Handover to E-UTRAN. The Source SGSN
initiates the Handover resource allocation procedure by sending a Forward
Relocation Request message to the target MME that contains:
IMSI
Tunnel Endpoint Identifier Control Plane
Packet Flow ID
Target Identification
PDP Context Prioritization
PDP Context
SGSN Address for Control Plane
MM Context
BSS Container
Charging Characteristics
BSSGP Cause
The target MME selects the Serving GW and sends a Create Session Request
message for each PDN connection to the Serving GW which contains:
Issue 11.01
IMSI
LTE/DCL/APP/031094
Nokia 2016
516 / 652
MME Tunnel Endpoint Identifier for Control Plane
MMEAddress for Control Plane
PDN GW TEID(s) for Control Plane
APN-AMBR
Serving Network
4a
The Serving GW allocates its local resources and returns them in a Create
Session Response message for each PDN to the target MME.
After receiving the Create Session Response message from the target SGW,
the Target MME requests the Target eNodeB to establish the Bearer(s) by
sending the Handover Request message that contains:
If the default bearer for that PDN is successfully set up, the E-RABs To Be
Setup List IE includes the S1-U SGW F-TEID in the Bearer Contexts
created IE in the Create Session Response message.
Source to Target Transparent Container is set to the UTRAN Transparent
Container received in the Gn Forward Relocation Request message.
Cause IE is mapped from BSSGP Cause received in the Gn Forward
Relocation Request.
After the Handover Request message is sent, the MME starts the
IRATHOCompletion Timer.
Issue 11.01
5a
The Target eNodeB allocates the request resources and returns the applicable
parameters to the Target MME in the message Handover Request
Acknowledge. After sending the Handover Request Acknowledge message, the
target eNodeB prepares to receive downlink GTP PDUs from the Serving GW
for the accepted EPS bearers.
If 'Indirect Forwarding' applies, the target MME sends a Create Indirect Data
Forwarding Tunnel Request message to the Serving GW indicating that the
bearer(s) are subject to data forwarding.
6a
The Serving GW returns a Create Indirect Data Forwarding Tunnel Response

message to the target MME. If the Serving GW does not support data
forwarding, a cause value is returned and the Serving GWAddress(es) and
TEID(s) are not included in the message.
The Target MME sends the message Forward Relocation Response to the
Source SGSN. The MME then populates the Tunnel Endpoint Control Plane,
Tunnel Endpoint Data II, List of Setup PFCs, BSS Container, RANAP Cause.
LTE/DCL/APP/031094
Nokia 2016
517 / 652
Figure 8-70: Call flow GERAN to E-UTRAN Inter-RAT Handover, Execution Phase
Legend:
1
The Source SGSN completes the preparation phase towards Source BSS by
sending the message PS HO Required Acknowledge.
The Source BSS instructs the UE to handover to the target eNodeB using the
message PS Handover Command. The access system-specific message to UE
includes a transparent container including radio aspect parameters that the
Target eNodeB has set-up in the preparation phase.
After receiving the Forward SRNS Context message from the SGSN, the MME
formats and sends a Forward Context Acknowledge message to the SGSN
with the Cause IE set to 'Request Accepted'.
The UE moves to the E-UTRAN and performs access procedures toward the
Target eNodeB.
When the UE gets access to the Target eNodeB, it sends the message HO to
E-UTRAN Complete. The UE derives the EPS bearers for which an E-RAB was
not established from the PS Handover Command and deactivates them locally
without an explicit NAS message.
When the UE has successfully accessed the Target eNodeB, the Target
eNodeB informs the Target MME by sending the Handover Notify message.
After receiving the Handover Notify message, the target MME:
Stores the received TAI and ECGI in the UE Context.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
518 / 652
Stops the IRATHOCompletionTimer if it is still running.
Starts a S3Gn Indirect Forwarding timer.
Issue 11.01
The MME sends an S11 Modify Bearer Request to the target SGW and sends
a Gn Forward Relocation Complete Notification message to the old SGSN.
7a
The MME Gn Forward Relocation Complete Acknowledge message from the

old SGSN.
The Target MME completes the Handover procedure by informing the Serving
GW that the Target MME is now responsible for all the EPS bearers the UE
have established. This is done in the Modify Bearer Request message.
The Serving GW informs the PDN GW(s) of the request by sending the Modify
Bearer Request message per PDN connection. The Serving Network is
included in this message if it is received in Step 4. For Serving GW relocation,
the Serving GW allocates DL TEIDs on S5/S8 even for non-accepted bearers.
The PDN GW acknowledges the request with the message Modify Bearer
Response (APN Restriction). When the UE moves from old SGSN to the MME,
the PDN GW sends the APN restriction of each bearer context to the Serving
GW.
10
The Serving GW (the Target Serving GW) acknowledges the user plane switch
to the Target MME by sending the Modify Bearer Response message.
11
When the timer started in Step 7 expires, the Source SGSN clean-ups all
resources toward the Source BSS by performing the BSS Packet Flow Delete
procedure. When the timer started in Step 6 expires, the target MME releases
the resources that have been allocated for indirect forwarding.
12
The UE initiates a Tracking Area Update procedure with the target MME. The
target MME knows that an IRAT Handover has been performed for this UE
because it received the bearer context(s) by handover messages. Therefore
the target MME performs only a subset of the TA update procedure (it excludes
the context transfer procedures between the source SGSN and target MME).
13
The target MME calculates UE-AMBR. If this value is different from the UEAMBR computed during step 6, or the APN-AMBR mapped from the
subscribed MBR is different from the subscribed APN-AMBR, or the mapped
subscribed QoS profile (i.e. the subscribed QoS profile mapped according to
Annex E) of the default bearer is different from the EPS Subscribed QoS profile
received from the HSS, the new MME initiates a Subscribed QoS Modification
procedure. Reference TS 23.401 for details.
LTE/DCL/APP/031094
Nokia 2016
519 / 652
8.1.33.4
Queue Network Initiated ESM Requests During IRAT
HO Procedure
MME supports the capability to queue network initiated session management requests
during initial attach and IRAT HO, and execute these requests 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. MME queues up to three network initiated
requests during the attach and IRAT HO procedures.
MME only queues the following requests associated with the PDN connection already
created:
Create Bearer Request
Delete Bearer Request
Update Bearer Request
The MME drops any requests if it cannot queue the request, either due to a full queue
or for any other reason.
During the IRAT HO procedure, immediately after completion of the Create Session
Request or the Modify Bearer Request, it is possible to get the Create Bearer Request
and/or Update Bearer Request before the TAU request is received.
Similar to the Attach procedure (see Queue network initiated ESM requests during initial
attach procedure), MME can queue up to three network initiated session management
requests. MME starts processing these requests after the completion of the TAU
request, as MME has secure communication established at the successful completion
of the TAU request.
MME handles any new requests after the successful completion of the TAU request as
follows:
MME processes the requests on a first-in, first-out basis.
MME queues one additional network initiated request after it starts processing
the queue. Any new requests are dropped until MME processes all three
requests. Basically, MME uses a queue depth of one after processing all the
requests that are queued while MME is in the attach procedure.
If the HO procedure is aborted or MME fails to receive the TAU request, MME sends a
delete session request to SGW and simply drops the queued messages.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
520 / 652
8.1.33.5
Enhanced queuing for network-initiated sessions
IRAT
((Create Bearer Request, Delete Bearer Request, Update Bearer Request) initiated by
the network while the UE is in a handover procedure without SGW or MME relocation
that would caused delay in establishing or modifying a new bearer and result in poor
user experience.
When the maximum queue depth has been reached (maximum supported queue depth
= 3), the 9471 WMM drops (without reject) any additional network-initiated bearer
requests that it receives. Messages are queued only if the HO is already in progress
within the MME.
For the following scenarios, enhanced queuing works as described below:
If the UE remains on the source MME after the HO fails, the MME processes
(dequeue) any queued network-initiated bearer requests.
IRAT 4g/3g HO failure - the MME processes (dequeue) any queued networkinitiated bearer requests after the completion (failure) of IRAT 4g/3g handover.
IRAT4g/3g HO success - the MME drops any queued network-initiated bearer

requests after the completion (success) of IRAT 4g/3g handover
8.1.33.6
Direct Forwarding and Indirect Forwarding
During Inter RAT handover, when the UE disconnects from the source RAT, but not yet
connects to the target RAT, the downlink data packets received in the source RAT for
the UE need to be forwarded to the target RAT. Depending on the configuration in a
service providers network, the data forwarding can either be direct forwarding or
indirect forwarding.
When direct forwarding is supported, the downlink data is forwarded directly to the
target without looping the downlink packets back to an uplink.
The data forwarding path for direct forwarding with SGW relocation is:
Inter RAT between E-UTRAN and UTRAN:
- source eNB -> target RNC, or source RNC -> target eNB.
Inter RAT between E-UTRAN and GERAN:
- source eNB -> target SGSN -> target BSS, or source BSS -> source SGSN ->
target eNB.
The data forwarding path for indirect forwarding with SGW relocation is:
Inter RAT between E-UTRAN and GERAN:
- source eNB -> SGW -> target SGW -> target SGSN -> target BSS, or source
BSS->source SGSN->source SGW->target SGW->target eNB.
Inter RAT between E-UTRAN and UTRAN:
- source eNB -> source SGW -> target SGW -> target RNC , or source RNC ->
source SGW -> target SGW -> target eNB
- source eNB -> source SGW -> target SGW -> SGSN -> target RNC, or source
RNC -> SGSN -> source SGW -> target SGW -> target eNB
For direct/indirect forwarding without SGW relocation, the SGW is removed from the
path.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
521 / 652
8.1.33.7
Support for A/GB and IU Mode Capable UES
During a E-UTRAN to UTRAN Inter RAT handover: When sending a Forward

Relocation Request message over the Gn interface to the target SGSN, the source
MME includes the necessary A/Gb mode-related and Iu mode-related parameter values
(if available) for each Bearer (note that if the UE supports GERAN A/Gb mode and/or
UTRAN Iu mode, then the source MME already has the necessary information elements
stored in the UE Bearer Context).
During a UTRAN to E-UTRAN Inter-RAT handover:
When the target MME receives a Forward Relocation Request message over the
Gn interface from the source SGSN, the target MME stores the received values
for the necessary A/Gb mode-related and Iu mode-related parameters in the UE
Bearer Context for each bearer (SGSN does not store UE Context information).
If the source SGSN does not include the MS Network Capability parameter in the
Forward Relocation Request message, then the target MME rejects the InterRAT handover request.
8.1.33.8
Network Assisted Cell Change (NACC)
Network Assisted Cell Change (NACC) is applicable for inter-RAT cell changes from a
source E-UTRAN cell towards a target GERAN cell. Support for the RAN Information
Management (RIM) procedure (used by NACC) for inter-RAT cell change from a source
E-UTRAN cell to a target UTRAN cell was introduced by 3GPP in release 9.
Refer to 3GPP TS 25.413 and TS 23.060 for further details.
8.1.33.8.1 RIM PROCEDURES

The RAN Information Management (RIM) procedures provide a generic mechanism for
the exchange of information between applications belonging to the RAN nodes. The
RAN information is transferred via the MME and SGSN core network node(s)
transparently within messages that are not interpreted by the Core Network nodes.
The interfaces which will be used are the Gb, Iu, S1, Gn and S3 interfaces. An MME or
SGSN supporting the RIM procedures provides addressing, routing and relaying
functions.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
522 / 652
8.1.33.9
Failure handling
Throughout the procedure, the MME checks the associated messages for specific IE
content to ensure it meets the procedure criteria. MME may also set timers for requests
to be acknowledged. Any check failure/timer timeout results in procedure failure for
which a message is returned to the requestingnetwork element with a cause value
indicating the failure type, and the procedure is then terminated.
If a HANDOVER REQUIRED message is received while another procedure is in
progress over the same connection, the MME may send a HANDOVER
PREPARATION FAILURE message back to the source eNodeB.
During Inter RAT HO, if the MME receives TAU message after the Context
Acknowledge message and before the timer expires, the MME accepts the TAU
request; however, if an Attach or a Service Request is received, the MME rejects it.
8.1.33.10
Inter RAT Provisioned Parameters
The handover timers are defined via the Timer table.

Parameter
SAM Table Name
Timer
OSS ID
Range & Unit
timerName
Choice List
timerUnit
timerName)
Msec, seconds or minutes. See table below.
timerValue : Integer
Issue 11.01
Impact of Change
No service impact.
Value
LTE/DCL/APP/031094
Nokia 2016
523 / 652
Displayed Name
timerName
Timer value
(Range)
Default
Value
Purpose
2 seconds
Used in an EUTRAN to
GERAN CS HO procedure
to time for the receipt of the
Suspent Request message
from the SGSN in the new
network.
120
minutes
Used in an EUTRAN to
GERAN CS HO procedure
to time for the release of UE
resources.
1 second
Used to handle the deletion

of the UE bearers during a
HO to a UTRAN or GERAN
network. The timer is started
when the MME receives the
SGSN Context Request
message from the new
SGSN. The MME deletes
the UE bearers when the
timer expires. S1 bearers as
well as EPS bearers at the
SGW (if SGW relocation)
are deleted.
.5 10
seconds,
SuspendReq
SuspendReq
.5 second
increments
CSoPSBearerDel
CSoPSBearerDel
1 480
minutes
HO2G3GDeletion
HO2G3GDeletion
.1 5
seconds
S3Gn Indirect
Forwarding
S3Gn_Indirect_
Forwarding
.1 5
seconds, in
.1 second
increments
1 second
Time to wait before

releasing resources
allocated for indirect
forwarding of UE data.
S3 Gn HO
Complete
S3_Gn_HO_
Complete
.1 10
seconds, in
.1 second
increments
1 second
Time to wait for Response

messages during Inter-RAT
handover procedures.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
524 / 652
TAU after HO
Del Bearer at src

SGW
Issue 11.01
TAU_After_HO
Del_Bearer_at_
src_SGW
0 10
seconds
0 5000
msec, in 100
msec
intervals
LTE/DCL/APP/031094
5 seconds
Indicates the time to wait to

receive a TAU Request from
the UE after a handovers
occurs from LTE S1,
UTRAN, or GERAN. The
MME detaches the UE if the
timer expires before the
TAU Request is received.
Caution! This value should
only be set to '0' for
troubleshooting purposes,
but it is not recommended
by Nokia for service
operation. If this value is set
to '0', the MME does not
start the timer, does not
Detach the UE, and does
not start a new AKA as part
of the handover procedure.
This can generate security
vulnerabilities in the EPS
that a UE can exploit.
500 msec
Time to wait before deleting

UE bearers at the source
SGW after the MME
receives a Create Session
Response from the target
SGW. A value of 0 indicates
that the UE bearers at the
source SGW are deleted
once the bearers are set up
at the target SGW.
Nokia 2016
525 / 652
The MME is also provisioned with a timer used for timing receipt of the SRNS
completion message from the target SGSN.
Parameter
SRNS Completion
SAM Table Name
Timer
OSS ID
timerName
Choice List
SRNS_Completion
Range & Unit
timerUnit
timerName)
msec
timerValue
Integer
[100..10,000] msec, in 100 msec increments
Impact of Change
No service impact.
Value
The MME is provisioned with a value to indicate whether Inter-RAT Handover via Gn or
S3 always employs indirect data forwarding, does not employ indirect data forwarding,
or employs indirect data forwarding only for inter-PLMN inter-RAT Handover.
Parameter
S3 Gn Indirect Forwarding
SAM Table Name
Global Parameters
OSS ID
gParmName
String
S3_Gn_Indirect_Forwarding
Range & Unit
gParmValue
Choice List
Always
Never
Inter-PLMN/RAT only
Issue 11.01
Impact of Change
No service impact.
Value
Operator Dependent; default = Always
LTE/DCL/APP/031094
Nokia 2016
526 / 652
The MME is provisioned with a value for the number of NAS tokens to compare to
determine whether a UE is authenticated in a handover scenario from UTRAN/GERAN
to LTE (as per TS 33.401).
Parameter
NAS Tokens to Compare
SAM Table Name
Global Parameters
OSS ID
gParmName
String
NAS_Tokens_to_Compare
Range & Unit
gParmValue
Integer
[2..5]
Issue 11.01
Impact of Change
No service impact.
Value
LTE/DCL/APP/031094
Nokia 2016
527 / 652
8.1.34 INTRA-LTE S1-BASED HANDOVER PROCEDURE
The S1 based handovers are used when there is not a direct forwarding path between
source eNB and target eNB (i.e. X2 interface). The S1-based handover procedure is
selected by an eNodeB if X2-based handover cannot be used. The handover between
the source eNB and target eNB is coordinated by the source MME and target MME (if
there is MME relocation). The S1-based handover requires MME to forward messages
between source eNodeB and target eNodeB and also select a new MME if the eNodeB
is served by a different MME.
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.
Elementary procedures (as specified in 3GPP TS 36.413) that may be used during this
procedure are:
Handover Required
Handover Command
Handover Preparation
Handover Preparation Failure
Handover Resource Allocation
Handover Request
Handover Request Acknowledge
Handover Failure
Handover Notification
Handover Cancellation
Handover Cancellation Acknowledge
eNB Status Transfer
MME Status Transfer
For details about each step of these call flows, refer to 3GPP Technical Specification
36.413.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
528 / 652
Figure 8-71: Call flow - S1-based Handover without MME and SGW Relocation with
Direct Forwarding
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
529 / 652
Figure 8-72: Call flow - S1-based Handover without MME and SGW Relocation with
Indirect Forwarding
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
530 / 652
Figure 8-73: Call flow - S1-based Handover without MME and with SGW Relocation
with Indirect Forwarding
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
531 / 652
Figure 8-74: Call flow - S1-based Handover with MME and SGW Relocation with
Indirect Forwarding
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
532 / 652
For all the S1-based handover scenarios, the source eNodeB determines availability of
a forwarding path and alerts the MME whether X2 connectivity is available between the
source and target eNodeBs. Two types of data forwarding from the source eNB to the
target eNB during the handover procedure are supported:
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).
The decision to relocate MME is made by the source MME after receiving the Handover
Required message. If the target eNodeB is not in the source MME serving area then it
selects an MME serving the area of the eNodeB by:
Determining MME pool/pools that are assigned to service the tracking area
identifier (TAI).
Selecting an MME pool (if more than one pool is available) in a round-robin
fashion.
selecting an MME in round robin fashion from the MMEs with an active S10
connection to the source MME.
provisioned UEs time zone to the SGW in the Create Session Request (for S1-based
handover with SGW relocation) and in the Modify Bearer Request message (for S1based handover procedure without SGW relocation).
In support of A/Gb and Iu Mode Capable UEs
When the source MME sends Forward Relocation Request message over the
S10 interface to the target MME, the source MME includes the necessary A/Gb
mode-related and Iu mode-related parameter values for each Bearer (if the UE
Bearer Context contains the values for these information elements). If the UE
supports GERAN A/Gb mode and/or Iu mode, then the old MME already has the
necessary information elements stored in the UE Bearer Context.
When the target MME receives Forward Relocation Request message over the
S10 interface from the source MME, the target MME stores the received values
for the the necessary A/Gb mode-related and Iu mode-related parameters in the
UE Bearer Context for each bearer.
The decision to relocate SGW is made by the MME (source MME if no MME relocation
or target MME if MME relocation) after receiving the Forward Relocation Request
message, but only if the TAI is serviced by the target MME and MME has an active S1
connection to the target eNB. If the tracking area (TA) of the target eNodeB is not
served by the SGW, then the MME selects another SGW that is assigned to serve the
TA.
If the TAI is not serviced by the current SGW then the target MME (this can be the
source MME if MME relocation is not required) selects an SGW by:
Determining SGW pool/pools assigned to service the TAI.
selecting an SGW pool (if more than a single SGW pool is available)
(NOTE: if no SGW is available in the first found pool, then MME goes to the next
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
533 / 652
pool, still searching for an available SGW, then the next pool, etc. until an SGW
is found).
Selecting a SGW with an active S11 connection to the MME within a pool in
round-robin fashion.
After receiving the Handover Request Acknowledge message from the target eNB:
the MME sets up indirect forward path for the downlink data for the bearers with
the DL transport layer address and DL GTP-TEID if the source eNB indicates
indirect data forwarding in the Handover Required message.
the target MME sends the Forward Relocation Response (only if there is MME
relocation).
the source MME sends the Handover Command to the source eNB.
For details about each step of these call flows, refer to 3GPP Technical Specification
36.413.
8.1.34.1
Failure Scenarios
The two possible failure scenarios are:
The source MME is unsuccessful in selecting a target MME.
In this case, the MME sends a Handover Preparation Failure message with the cause
Unknown Target ID to the source eNodeB for the following conditions:
-
TAI is not known (source MME can not find in its service area or other
provisioned pool of MME service areas).
Target or Source eNB does not support the applicable 3GPP standard.
MME does not have an active S1 connection to the target eNB.
The target MME cannot complete the relocation.
In this case, the target MME sends the Forward Relocation Response with cause
Relocation Failure for the following conditions:
-
TAI received is not known.
Target or Source eNB does not support the applicable 3GPP standard.
MME does not have an active S1 connection to the target eNB.
The PLMN ID of the IMSI received in the Forward Relocation Message is

different from the target MMEs PLMN ID, and the PLMN ID is not in the target
MMEs roaming agreement table.
Note: The source MME can only check target-eNB-related conditions if the target eNB
can be serviced by the source MME.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
534 / 652
8.1.34.2
Two timers are used by the MME in the S1 Handover procedure. The timers are defined
via the Timer table. The table provides default values for each of the timers, but should
be reviewed to determine whether or not the defaults provide adequate performance.
Updates should be made to the Timer table as required.
Parameter
SAM Table Name
OSS ID

Timer
timerName
Choice List
Range & Unit
timerUnit
timerName)
msec or seconds. See table below.
timerValue
Integer
See table below for timerValue.
Impact of Change
No service impact.
Value
Displayed
Name
S1 HO
Complete
Issue 11.01
timerName
S1_HO_
Complete
timerValue
(Range)
1 10
seconds
LTE/DCL/APP/031094
Default
Value
Purpose
5
seconds
Indicates the UE is on the target

eNB. MME will receive either
Handover Notify message from
the target eNB or Forward
Relocation Complete message
from the target MME
(depending on MME relocation).
This timer times reception of
either of those messages.
Nokia 2016
535 / 652
Displayed
Name
S1 HO
Resource
Release
timerName
S1_HO_
Resource_
Release
timerValue
(Range)
100 5000
msec
Default
Value
Purpose
2000
msec
During a relocation request

(SGW only or MME and SGW),
the timer starts upon receipt of a
Forward Relocation Complete
Acknowledge. If the release
does not occur before the timer
expires, the target MME sends
a Delete Indirect Data
Forwarding message to the
target SGW to delete it if the
target MME has setup indirect
forward paths on the target
SGW. The source MME deletes
any bearers on the source SGW
(with SGW relocation) and
deletes the tunnel by sending a
Delete Indirect Data Forwarding
message if the source MME has
setup indirect forward paths on
the source SGW. The source
MME also releases S1 UE
connections with the source
eNB.
Rule: Relationship to S1RelocOverall Timer at eNB

The sum of the S1HO_Complete and S1HO_ResourceRelease timers at the MME
should be less than the value of S1RelocOverall timer at the eNB.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
536 / 652
8.1.34.3
Extended Queuing for CSFB Scenarios (S1 HO
triggered)
The MME supports resending or requeuing certain messages if a failure is due to an S1
Handover (S1 HO). The MME will not resend the context request message if eNB
responds with a failure message other than S1intra system HO triggered. The following
scenarios apply:
If the eNB rejects a S1AP UE CONTEXT MODIFICATION REQUEST with an

indication that rejection is due because of an S1 Intra System Handover
(S1HO), the MME will resend the S1AP UE CONTEXT MODIFICATION
REQUEST with a CSFB indicator after the completion of the S1HO. Rejection
of the S1AP UE CONTEXT MODIFICATION REQUEST is indicated by the eNB
responding with S1AP UE CONTEXT MODIFICATION FAILURE with cause IE
set to S1intra system HO triggered.
During a S1 HO, an MSC sends a SGs AP-PAGING-REQUEST message

which involves sending a NAS message CS Service Notification to a UE. The
MME will send a NAS message CS Service Notification via the target eNB if the
handover is complete or via the source eNB when a handover has failed. If the
MME receives an S1AP NAS NON DELIVERY INDICATION message with a
cause of S1 Intra System, the MME queues and resends the CS Service
Notification to the UE.
If the eNB rejects a NAS Downlink NAS Transport message, the MME queues
and resends the up to three SMS messages by way of the target eNB.
Rejection is indicated by an S1AP NAS NON DELIVERY INDICATION
message with the cause set to S1HO triggered.
8.1.34.4
Enhanced Queuing
Requests for S1 HO
Network
Initiated
Session

initiated by the network while the UE is in a handover procedure without SGW or MME
relocation that would cause delay in establishing or modifying a new bearer and result
in poor user experience.
Bearer related procedures (Create Bearer Request, Delete Bearer Request, and
Update Bearer Request) that are affected by a S1-handover "in-progress" are queue by
the MME and replayed to the serving eNodeB at the completion of the handover
procedure. This only applies in the situation where no MME change (standard behavior
for X2 HO) and SGW relocation are involved in the handover.
If a procedure is denied or cannot be executed because the source eNodeB is
executing a X2 HO without SGW, the MME queues the request and resumes the
procedure once the HO has been completed.
Requests are simply rejected once the Queue capacity is exceeded. (Maximum
supported queue depth = 3)
The dequeuing or dropping of queued Network initiated bearer requests is dependent
on whether the S1 HO is Intra-MME or Inter-MME.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
537 / 652
The following conditions applied:
without SGW relocation
with SGW relocation

the MME drops any queued
Intra-MME
S1-Handover
the MME processes (dequeue)

any queued network-initiated
bearer requests after the
completion (success or failure)
network-initiated bearer requests

from the source SGW after the
completion (success)
the MME processes (dequeue) any
requests from the target SGW after
the completion (success)
the MME processes (dequeue) any
requests from the source SGW after
the completion (success or failure)
The source MME drops any queued network initiated bearer requests
after the success of the S1 Inter-MME handover.
Inter-MME
The source MME processes (dequeue) any queued network initiated

bearer requests after the failure of the S1 Inter-MME handover if the
UE remains on the source MME.
S1-Handover
The target MME processes (dequeue) any queued network initiated
bearer requests after the success of the S1 Inter-MME handover.
T
The target MME drops any queued network initiated bearer requests
h
after the failure of the S1 Inter-MME handover.
e
MME queues any network initiated ESM requests if the eNB rejects any E-RAB
management messages with cause S1 intra system handover triggered. The queued
messages will only be processed if there is no MME relocation.
The MME handles S1 HO that may occur at three different stages of the ESM
procedure as follows:
Stage 1- MME has not sent the ESM request to the UE. In this case the MME will queue
the request and processes the request after the completion of the handover.
Stage 2 - If the MME has sent the ESM request to the UE but the MME has not heard
back from the UE and the supervision timer is still running. In this case, the MME puts
the procedure on hold and proceeds with the X2/S1HO. At the completion of the HO,
the MME will send the ESM request again through the new eNB.
Stage 3 MME has received UE response but the MME has not sent response to PGW
or it is waiting for the PGW response. In this case, the MME will send the response and
then proceed with the HOHandling of Create Indirect Data Forwarding (CIDF) error
scenarios
MME ignores any error received for S11 Create Indirect Data Forwarding (CIDF) Tunnel
Request or no response from SGW after all the attempts for the S11 CIDF Tunnel
Request and proceeds with handover for the following error conditions:
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
538 / 652
Any error is received for S11 Create Indirect Data Forwarding (CIDF) Tunnel
Request (that is, Cause value is set to a value other than Request Accept in
the S11 Create Indirect Data Forwarding Tunnel Response).
No response from SGW after all the attempts for the S11 Create Indirect Data
Forwarding Tunnel Request.
These errors indicate that the SGW failed to set up indirect forwarding tunnels.
The forwarding paths are not needed to complete the S1 based HO. User traffic will be
lost until the UE notifies handover complete to the target eNB without the forwarding
paths.
This feature also supports configuration to enable indirect forwarding of user data
during S1HO. MME will not set up indirect forwarding tunnels if the indirect forwarding is
not enabled when required.
8.1.34.5
S11 CIDF configuration Parameters
The global parameter S11 Send CIDF during S1HO enables or disables sending of the
S11 Create Indirect Forwarding Tunnel Request message during an S1HO.
By default, it is set to Yes
Parameter
S11 Send CIDF during S1HO
SAM Table Name
Global Parameters
OSS ID
gParmName
String
S11_Send_CIDF_during_S1HO
Range & Unit
gParmValue
Boolean
Yes or No
Impact of Change
No service impact.
Value
Operator Dependent; default = Yes ( enabled)
Feature
m10915-01
8.1.35 ROUTING AREA UPDATE PROCEDURE

The Gn interface is used for handovers between LTE and UTRAN/GERAN networks via
pre-Release 8 SGSN. Several timers and other provisioned parameters are used by the
MME in the Handover procedure. The MME provisioning GUI provides default values
for each of the fields, but the forms should be reviewed to determine whether or not the
defaults provide adequate performance. Updates should be made to each form as
required. The Gn-based TAU procedure is shown in Section 8.1.29.3.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
539 / 652
8.1.35.1
GN-based RAU
The Routing Area Update (RAU) procedure takes place when
a UE in CONNECTED or IDLE state moves from LTE to a UTRAN cell, or
a UE in IDLE state moves from LTE to a GERAN cell served by a Gn/Gp Serving
GPRS Support Node (SGSN). In this case, the UE changes to a Routing Area
that the UE has not yet registered with the network. This procedure is initiated by
an idle state or by a connected state UE.
In the RAU procedure, the UE moves from the LTE network to the UTRAN/GERAN
network and the MME must translate each of the EPS bearers and the associated QoS
values to the values required to support an equivalent PDP context in the
UTRAN/GERAN network.
The RAU procedure uses the MM Context information element containing the Mobility
Management (MM), the UE and security parameters that are necessary to transfer the
UE from the MME to the SGSN.
Note that the MME explicitly detaches an ECM-CONNECTED UE upon the next
mobility management procedure triggered by either the UE or the network if the TAI
reported by the UE is forbidden in the new zone codes received from HSS.
Refer to 3GPP TS 23.401 for details of the procedure steps.
3GPP CR1393 clarified that while converting the APN-AMB-DL, APN AMBR-UL, GBRDL, GBR UL, and MBR AVPs bit rates received in bits per second over diameter
interfaces to kilo bits per second over GTPv2 interface. If the global parameter
Bandwidth Roundup is enabled, MME/SGSN rounded down or rounded up values n
NAS EPS QoS IE if such conversions result in fractions.
Parameter
Bandwidth Roundup
SAM Table Name
Global Parameters
OSS ID
gParmName
Bandwidth_Roundup
Issue 11.01
Range & Unit
gParmValue
Boolean
Yes or No
Impact of Change
No service impact.
Value
Feature
m10099-14
LTE/DCL/APP/031094
Nokia 2016
540 / 652
UE
RNC/
BSS
SGSN
eNodeB
MME
New
Serving
GW
Old
Serving
GW
PDN
GW
Old
SGSN
HSS
PCRF
1. UE Changes to
UTRAN or GERAN
2a. Routeing Area Update Request
2b. Routeing Area Update Request
3. Context Request
4. Context Response
5. Security Functions

(A)

12. Update Location
13. Cancel Location
14. S1-AP: S1 Release Command
Release E-UTRAN
connection
14. S1-AP: S1 Release Complete

(B)
18. Routeing Area Update Accept
19. Routeing Area Update Complete
20. Service Request
21. RAB Assignment Request
21b. RAB Assignment Response
Figure 8-75: Call flow RAU Procedure with MME Interaction and with SGW Change
(Gn)
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
541 / 652
8.1.35.2
S3-Based RAU
The MME complies with the Routing Area Update procedure as outlined in section
5.3.3.1 and 5.3.3.2 of 3GPP TS 23.401 V8.8.0. This includes the support of the S3
interface to the S4-SGSN and the interworking procedures between E-UTRAN and
UTRAN/GERAN (RAU with or without SGW change, when an UE moves from EUTRAN to UTRAN/GERAN).
The Routing Area Update without SGW change procedure takes place when a UE that
is registered with an MME selects a UTRAN or GERAN cell and the SGW is not
changed by the procedure. When this occurs, the UE changes to a Routing Area that
the UE has not yet registered with the network. Refer to 3GPP TS 23.401 for details of
the procedure steps.
UE
eNodeB
RNC/
BSS
SGSN
MME
Serving
GW
Old
SGSN
PDN
GW
HSS
PCRF
1. UE Changes to
UTRAN or GERAN
2a. Routeing Area Update Request
2b. Routeing Area Update Request
3. Context Request
4. Context Response
5. Authentication

(A)

12. Update Location
13. Cancel Location
14. S1-AP: S1 Release Command
Release E-UTRAN
connection
14. S1-AP: S1 Release Complete

18. Routeing Area Update Accept
19. Routeing Area Update Complete
20. Service Request
21. RAB Assignment Request
21b. RAB Assignment Response
Figure 8-76: Call flow RAU Procedure with MME Interaction and without SGW
Change (S3)
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
542 / 652
The Routing Area Update with SGW change procedure takes place when a UE that is
registered with an MME selects a UTRAN or GERAN cell and the SGW is changed by
the procedure. When this occurs, the UE changes to a Routing Area that the UE has
not yet registered with the network. Refer to 3GPP TS 23.401 for details of the
procedure steps.
Figure 8-77: Call flow RAU Procedure with MME Interaction and with SGW Change
(S3)
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
543 / 652
8.1.36 E-UTRAN RADIO ACCESS BEARER (E-RAB) PROCEDURE
Within the S1AP protocol, the E-UTRAN Radio Access Bearer (E-RAB) management
function is responsible for setting up, modifying and releasing E-RABs, which are
triggered by the MME. The release of E-RABs may be triggered by the eNodeB as well.
This function is comprised of elementary procedures
E-RAB Setup
E-RAB Release
8.1.36.1
E-RAB Setup
The purpose of the E-RAB Setup procedure is to assign resources on Uu and S1 for
one or several E-RABs and to setup corresponding Data Radio Bearers for a given UE.
eNB
MME
E-RAB SETUP REQUEST
E-RAB SETUP RESPONSE
Figure 8-78: Call flow E-RAB Setup Procedure

The MME initiates the procedure by sending an E-RAB SETUP REQUEST message to
the eNodeB. The E-RAB SETUP REQUEST message contains the information required
by the eNodeB to build the E-RAB configuration consisting of at least one E-RAB
including for each E-RAB to setup in the E-RAB to be Setup List IE.
Upon reception of the E-RAB SETUP REQUEST message, and if resources are
available for the requested configuration, the eNodeB executes the requested E-RAB
configuration. For each E-RAB, and based on the E-RAB level QoS parameters IE, the
eNodeB establishes a Data Radio Bearer and allocates the required resources on Uu.
The eNodeB passes the NAS-PDU IE and the value contained in the E-RAB ID IE
received for the E-RAB for each established Data Radio Bearer to the UE. The eNodeB
does not send the NAS PDUs associated to the failed Data radio bearers to the UE.
The eNodeB allocates the required resources on S1 for the E-RABs requested to be
established.
In case of the establishment of an E-RAB, the EPC is prepared to receive user data
before the E-RAB SETUP RESPONSE message has been received.
When the eNodeB reports unsuccessful establishment of an E-RAB, the cause value is
precise enough to enable the MME to know the reason for an unsuccessful
establishment (for example: Radio resources not available, Failure in the Radio
Interface Procedure).
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
544 / 652
If a handover becomes necessary during E-RAB setup, the eNodeB may interrupt the
ongoing E-RAB Setup procedure and initiate the Handover Preparation procedure as
follows:
The eNodeB sends the E-RAB SETUP RESPONSE message in which the
eNodeB indicates, if necessary, all the E-RABs fail with an appropriate cause
value (for example S1 intra system Handover Triggered, S1 inter system
Handover Triggered or X2 Handover Triggered)
The eNodeB triggers the handover procedure.
8.1.36.2
E-RAB Release
The IWF is responsible to initiate the deactivation of the dedicated signaling bearer that
was established by IWF when the UE first registered with the IWF. From MME point of
view, the MME will receive a S11 Delete Bearer Request message from the SGW.
The MME deletes the UE bearer context of this bearer and sends the S11 Delete
Bearer Response message to the SGW. Since the S1 connection and the eNodeB UE
Context have already been released before, there is no need for the MME to send the
S1AP E-RAB RELEASE COMMAND message to the eNodeB.
8.1.37 UE CONTEXT PROCEDURE

S1-AP messages between an eNodeB and the MME are transported over SCTP/IP.
This function is comprised of elementary procedures defined in TS 36-413:
Initial Context Setup
UE Context Release Request - eNodeB initiated
UE Context Release Request - MME initiated
UE Context Modification
As per TS 23.401, MME stores the UE capability information received from the VLR
record and sends it to the eNB on subsequent Initial UE Context Setup and handover
request messages.
WM9.0.0 expand MME stored UE Radio Capability Information up to 2048 octets in size
( 2K) to provide flexibility for UE capability information on RATs that include UE
supported frequency bands and new feature sets.
As per TS 23.401 , The UE Radio Capability information contains information on RATs
that the UE supports (e.g. power class, frequency bands, etc). Consequently, this
information can be sufficiently large (e.g. >50 octets) that it is undesirable to send it
across the radio interface at every transition from ECM-IDLE to ECM-CONNECTED. To
avoid this radio overhead, the MME stores the UE Capability information during
ECM-IDLE state and the MME shall, if it is available, send its most up to date UE Radio
Capability information to the E-UTRAN in the S1 interface INITIAL CONTEXT SETUP
REQUEST message unless the UE is performing an Attach procedure or a Tracking
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
545 / 652
Area Update procedure for the "first TAU following GERAN/UTRAN Attach" or for a "UE
radio capability update".
The UE Radio Access capability sent in the TS 24.008 was initialy defined for 50
octets; TS 23.401 already specified a larger size as stated in paragraph 5.11 : To allow
for the addition of future radio technologies, frequency bands, and other enhancements,
the MME shall store the UE Radio Capability Information even if it is larger than
specified in TS 36.331 up to a maximum size of 510 octets. Yet, the fast mobile growing
trend already demands even larger size for the new UE capability information that has
been put into 3GPP TSG CR0427 to support 8K in the future.
8.1.37.1
Initial Context Setup
The purpose of the Initial Context Setup procedure is to establish the necessary overall
initial UE Context including E-RAB context, the Security Key, Handover Restriction List,
UE Radio capability and UE Security Capabilities etc.
eNB
MME
INITIAL CONTEXT SETUP REQUEST
INITIAL CONTEXT SETUP RESPONSE
Figure 8-79: Call flow Initial Context Setup Procedure

In case of the establishment of an E-RAB the MME is prepared to receive user data
before the INITIAL CONTEXT SETUP RESPONSE message has been received.
The INITIAL CONTEXT SETUP REQUEST message contains (within the E-RAB to be
Setup Listinformation element) the information required by the eNodeB to build the
new E-RAB configuration consisting of at least one additional E-RAB.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
546 / 652
8.1.37.2
UE Context Release Request - ENODEB-initiated
The purpose of this UE Context Release Request procedure is to enable the eNodeB to
request the MME to release the UE-associated logical S1-connection due to E-UTRAN
generated reason (for example TX2RELOCOverall Expiry).
eNB
MME
UE CONTEXT RELEASE REQUEST
Figure 8-80: Call flow UE Context Release Request Procedure (eNodeB-Initiated)

The eNodeB controlling a UE-associated logical S1-connection initiates the procedure
by generating an UE CONTEXT RELEASE REQUEST message towards the affected
MME node.
The UE CONTEXT RELEASE REQUEST message indicates the appropriate cause
value (for example User Inactivity, Radio Connection With UE Lost) for the requested
UE-associated logical S1-connection release.
Note: The UE Context Release procedure is initiated upon reception of an UE
CONTEXT RELEASE REQUEST message when the cause is different than User
Inactivity.
Normally the MME performs the Create Session Request procedure when the UE is in
the ECM-connected state and sends PDN Connectivity request to establish a default
bearer and then sends eRABSetup request to the eNB and Activate Default Bearer
request to the UE. When the MME receives answers to these two requests the MME
informs the SGW of the new S1-U data and the procedure is done. If the eNB dormancy
timer expired while this procedure is being processed. the eNB sends UE Context
Release Request to the MME with S1AP cause "user inactivity".
Previously, the MME uses the UE context release request as a trigger to abort the PDN
request and then carries out the release procedure.
In WM10.0.0 and later releases, the MME examines the S1AP cause of a UE Context
release Request received from the eNB and takes the following actions:
Issue 11.01
during a PDN Connectivity procedure, the MME ignores the UE Context

Release Request if the cause is User Inactivity and allows the PDN
Connectivity procedure to continue
during PDN Disconnect procedure, the MME ignores the UE Context Release
Request if the cause is User Inactivity and allows the PDN Disconnect
procedure to continue.
LTE/DCL/APP/031094
Nokia 2016
547 / 652
The most common outcome with this change is that the PDN procedure completes
successfully before the eNB re-sends UE Context Release Request, which could then
be processed normally. In the event that the PDN procedure is still on-going when the
eNB sends the UE release request the second time; the MME drops the request if the
S1AP cause is "user-inactivity". The eNB will, after the second try is not responded to,
eventually send a release request with an error cause (typically the eNB will use S1AP
cause "release due to reason generated in the eUTRAN"). With this change the roughly
0.5% of PDN request procedures that were aborted previously insteads succeed.
MME upon receiving UE Context Release Request with the Cause Value set to Radio
Connection with UE lost from the eNB when UE is in ECM-IDLE state, MME sets the
Abnormal Release of Radio Link flag Indication IE to 1 in S11 Release Access Bearer
request message that is sent towards SGW.
This setting of the bit to 1 by MME
indicates to SGW that the Access Bearers are released due to abnormal release of the
radio link.
This support for PGW pause of charging solves the mismatched charging in the SGW
and the PGW in scenarios where there is downlink data and the UE is in ECM-IDLE
state (the SGW does not charge for data while the PGW does, no data is being sent
over the radio link, and therefore the CDRs in SGW and PGW may be different).
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
548 / 652
8.1.37.3
UE Context Release Request - MME-initiated
The purpose of this UE Context Release procedure is to enable the MME to order the
release of the UE-associated logical connection due to various reasons, for example:
completion of a transaction between the UE and the EPC,
completion of successful handover,
completion of handover cancellation,
release of the old UE-associated logical S1-connection when two UE-associated

logical S1-connections toward the same UE is detected after the UE has initiated
establishment of a new UE-associated logical S1-connections.
eNB
MME
UE CONTEXT RELEASE COMMAND
UE CONTEXT RELEASE COMPLETE
Figure 8-81: Call flow UE Context Release Request Procedure (MME-Initiated)
The MME initiates the procedure by sending the UE CONTEXT RELEASE COMMAND
message to the eNodeB.
The UE CONTEXT RELEASE COMMAND message contains the UE S1AP ID pair if
available; otherwise the message contains MME UE S1AP ID.
The MME provides the cause IE set to Load Balancing TAU Requiredin the UE
CONTEXT RELEASE COMMAND sent to the eNodeB for all load balancing and offload
cases in the MME.
Upon reception of the UE CONTEXT RELEASE COMMAND message, the eNodeB
releases all related signalling and user data transport resources and reply with the UE
CONTEXT RELEASE COMPLETE message.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
549 / 652
8.1.37.4
UE Context Modification
The purpose of the UE Context Modification procedure is to modify the established UE

Context partly (for example with the Security Key or Subscriber Profile ID for
RAT/Frequency priority).
eNB
MME
UE CONTEXT MODIFICATION REQUEST
UE CONTEXT MODIFICATION RESPONSE
Figure 8-82: Call flow UE Context Modification Procedure (Successful)
eNB
MME
UE CONTEXT MODIFICATION REQUEST
UE CONTEXT MODIFICATION FAILURE
Figure 8-83: Call flow UE Context Modification Procedure (Unsuccessful)

Upon receipt of the UE CONTEXT MODIFICATION REQUEST the eNodeB
Stores the received Security Key IE, takes it into use and associates it with the
initial value of NCC.
Stores the Subscriber Profile ID for RAT/Frequency priority IE and uses it. If the
UE Aggregate Maximum Bit Rate IE is included in the UE CONTEXT
MODIFICATION REQUEST the eNodeB.
Replaces the previously provided UE Aggregate Maximum Bit Rate by the

received UE Aggregate Maximum Bit Rate in the UE context; the eNodeB uses
the received UE Aggregate Maximum Bit Rate for non-GBR Bearers for the
concerned UE. If the UE Aggregate Maximum Bit Rate IE is not contained in the
UE CONTEXT MODIFICATION REQUEST message, the eNodeB uses the
previously provided UE Aggregate Maximum Bit Rate which is stored in the UE
context. If the CS Fallback Indicator IE is included in the UE CONTEXT
MODIFICATION REQUEST message, it indicates that the UE Context is subject
to CS Fallback. The eNodeB reports, in the UE CONTEXT MODIFICATION
RESPONSE message to the MME, the successful update of the UE context:
After sending the UE CONTEXT MODIFICATION RESPONSE message, the
procedure is terminated in the eNodeB.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
550 / 652
8.1.37.5
Collision Handling
In scenarios of DDN collision during the UE context release (S1 release) procedure, the
MME queues the DDN request received if the MME is in the process of UE context
release and proceeds with the DDN request after completing the UE context release
procedure. The UE context release can be triggered by the eNB or MME.
The deactivation of the GBR bearer occurs as follows:
The MME checks the settings for timer Delete Guaranteed Bit Rate
If the "Delete Guaranteed Bit Rate" timer is set to zero, the MME deletes GBR
bearers immediately after receiving the S1AP RELEASE REQUEST
COMPLETE message from the eNB or on the expiration of s1ap-ue-contextrelease-timer.
If the "Delete Guaranteed Bit Rate timer is nonzero, the MME starts the "Delete
GBR Bearer Timer" immediately after receiving the S1AP RELEASE REQUEST
COMPLETE message from the eNB or on the expiration of s1ap-ue-contextreleasetimer.
MME stops the timer for the following events if they occur before the expiration of the
timer:
-
SR, TAU, and Paging: Timer is stopped. Any GBR bearer is preserved.
Attach and Detach: Timer is stopped.
If all the GBRs are deleted due to PGW requests in a single Delete Bearer
Request message. Timer is stopped.
Irrespective of the settings for the "Delete GBR Bearer Timer", the MME determines to
preserve GBR bearers or deactivate them upon paging failure based on the
provisioning of the global parameter Keep GBR when Paging Fails
Note: The MME never starts this timer if the global parameter Keep GBR when eNB
fails is enabled. MME preserved GBR bearers.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
551 / 652
8.1.38 ENHANCED RESTORATION PROCEDURES
8.1.38.1
DDN with IMSI and service request
The MME supports the enhanced restoration procedure for the network-initiated service
requests.
Upon receiving a DDN message with IMSI, the MME obtains UE restoration data from
the SRS for this IMSI. The MME pages the UE with the S-TMSI and paging area data
received in the UE context data for this IMSI from the SRS. The MME uses the paging
policy provisioned for the enhanced restoration procedures. The MME does not page
the UE if MME can not obtain UE context data from the SRS. The MME does not page
the UE if the IMSI is already known to the MME.
If the global parameter Enhanced SGW Restoration Procedures is not set for an MME
getting a request for a restoration procedure, and the MME receives a DDN with IMSI
recovery event, the MME sends DDN failure to the SGW with cause code # 90 (unable
to page UE).
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
552 / 652
eNB
UE
SRS
MME
SGW
2a. DDN with IMSI
1. Data
arrival for
a UE
3a. Retrieve UE
Restoration Data
Request
3b. Retrieve UE
Restoration Data
Response
2b. DDN Ack
MME uses S-TMSI and paging area (last seen
eNB and last seen TA) obtained from the
checkpoint server to page the UE using STMSI in the paging area.
4. S1-AP PAGING with STMSI

If UE is already connected then UE would
ignore the paging. If not, UE would send SR
with S-TMSI. eNB sends SR in S1-AP Initial
UE message to the MME pointed by the STMSI. If S1-MME connection is down to the
MME then eNB would send the Initial UE
message to one of the other MMEs in the
pool.
5. SR

SETUP REQUEST
5a. Retrieve UE
Restoration Data
Request
5b. Retrieve UE
Restoration Data
Response

SETUP COMPLETE

UE
MME
eNB
URS
SGW
Figure 8-84 UE enhanced restoration procedure for the network-initiated

service requests.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
553 / 652
1. PGW sends DL data for a UE to SGW.
2. SGW determines that the UE is associated with the failed MME and sends DDN
message with IMSI to the same MME if it has restarted. If the old MME can not
be reached then SGW shall send DDN message to a different MME in the
same MME pool as the failed MME.
3. The new MME sends a request to its SRS with IMSI as UE identity. The SRS
responds with UE restoration data if it has UE context. MME proceeds with amd
authentication and security procedures as needed (not shown in diagram). The
restoration data obtained contains necessary UE context required to establish
bearers like S-TMSI, paging area (last seen eNB and last seen TAI), security
context and bearer context. (If this UE is already attached on the new MME,
then MME sets the cause value to UE already attached.
4. MME shall send S1AP Paging message with S-TMSI. MME shall use separate
paging policy configured for the restoration procedures.
No page timer is
started and the UE context is removed from the MME after the page message
is sent.
5. If UE is re-attached then the UE would ignore the paging. If not, UE would send
SR in response to the paging to the MME pointed by the S-TMSI. If S1-MME
connection is down to the MME then eNB sends the initial UE message to one
of the other MMEs in the same pool. If MME does not have a valid UE context
then MME checks if recovery is supported. If not, existing MME behavior
applies. If so, MME sends a request to its SRS with S-TMSI as UE identity to
obtain UE restoration data.
6. After MME has UE context obtained from a SRS, it would send S1-AP INITIAL
CONTEXT SETUP REQUEST message to the eNB.
7. In phase 3, if SGW relocation is required, MME shall fail or timeout and initiate
detach procedures. (In the future, if SGW relocation is required, MME will
perform SGW relocation procedure, but this is not supported in phase 3.) If not,
MME sends a Modify Bearer Request message to the SGW per PDN
connection. (Note: Diagram needs to be updated.)
8. Once bearers are established, MME reallocates GUTI by sending NAS GUTI
Reallocation Command message to UE. EMM info will be sent after this step
(not shown in diagram).
9. As restoration data does not contain the entire
Update Location Request to obtain subscription
update MME identity. (Note: SR throttling is
reduce the staggering number of ULR/ULA
handling of SRs.)
subscription data, MME sends

data from the HSS and also to
implemented on the MME to
during restoration procedure
10. Not shown in the diagram but MME sends full restoration data update to its own
SRS and UE location update to other servers in the pool.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
554 / 652
8.1.38.2
Restoration Service Request
A new MME or restarted MME recovers SGs services as a part of the restoration
Service Request (SR) as shown in Figure 8-82 if the UE CSFB enabled or SMS only
indication is true.
The MME updates the SRS at the completion of the recovery procedure
eNB
UE
UE sends SR. eNB delivers SR
to a MME in the pool in
connection to the MME
identified by the S-TMSI is
down.
SRS
MME
SGW

2a. Retrieve UE
Restoration Data
Request
2b. Retrive UE
Restoration Data
Response
SETUP REQUEST
SETUP COMPLETE

7a. DETACH REQUEST

with detach type IMSI detach
Recovery
procedure for
CS Services
7b. DETACH ACCEPT

8a. TRACKING AREA UPDATE REQUEST
EPS Update IE = combined TA/LA updating with
IMSI attach
8b. TRACKING AREA UPDATE ACCEPT
UE
eNB
9a&b. SGs Location Update Request/Response to

MSC/VLR
SRS
MME
SGW
Figure 8-85 Restoration Service Request procedure
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
555 / 652
8.1.38.3
Restoration Extended Service Request
A new MME or restarted MME recovers SGs services as a part of the restoration
Extended Service Request (ESR) as shown in Figure 8-83, if the UE CSFB enabled.
MME shall update the SRS at the completion of the recovery procedure.
eNB
UE
UE sends ESR. eNB delivers
ESR to a MME in the pool in
connection to the MME
identified by the S-TMSI is
down.
SRS
MME
SGW

2a. Retrieve UE
Restoration Data
Request
2b. Retrive UE
Restoration Data
Response

6a. DETACH REQUEST

with detach type IMSI detach
Recovery
procedure for
CS Services
6b. DETACH ACCEPT

7a. TRACKING AREA UPDATE REQUEST
EPS Update IE = combined TA/LA updating with
IMSI attach
7b. TRACKING AREA UPDATE ACCEPT
8a&b. SGs Location Update Request/Response to

MSC/VLR
ESR is aborted, S1 is released. UE is expected to retransmit the ESR.
UE
eNB
MME
SRS
SGW
Figure 8-86 restoration Extended Service Request (ESR) procedure
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
556 / 652
8.1.39 EMM PROCEDURE COMMON PARAMETERS
The following sections describe parameters that are common for several EMM
procedures.
8.1.39.1
MME Relocation
The S10 interface is used for handovers with MME relocation. Two timers are
provisioned for use by the MME in the Handover procedure to remove UE data at the
source MME. One timer is for IMS Emergency calls, the other is for non-emergency
calls. The timers are defined via the Timer table on the MME provisioning GUI. The
table provides default values for each of the timers, but should be reviewed to
determine whether or not the defaults provide adequate performance. Updates should
be made to the Timer table as required.
Parameter
S10 Rm UE Data At Src MME
SAM Table Name
Timer
OSS ID
timerName
Choice List
S10_Rm_UE_Data_At_Src_MME
Range & Unit
timerUnit
timerName)
msec
timerValue
Integer
Impact of Change
No service impact.
Value
Operator Dependent; default = 0 (timer not used)
Parameter
S10 Remove Esrvc UE Data At Source MME Timer
SAM Table Name
Timer
OSS ID
timerName
Choice List
S10_Rm_Esrvc_UE_Data_At_Src_MME
Range & Unit
timerUnit
timerName)
msec
timerValue
Integer
Issue 11.01
Impact of Change
No service impact.
Value
Operator Dependent; default = 0 (timer not used)

LTE/DCL/APP/031094
Nokia 2016
557 / 652
8.1.39.2
Zone Code Parameters
The MME can be provisioned with a set of allowed subscription Zone Codes, where
each zone code is provisioned with a set of TACs where UE roaming is allowed. The
zone code parameters are applicable to the following EMM procedures:
Attach Procedure
Extended Service Request Procedure
Tracking Area Update Procedure
Service Request Procedure
Routing Area Update Procedure
Parameter
Zone Code
SAM Table Name
Zone Code
OSS ID
ltemme.MMEZoneCodeAbs.zoneCode
Range & Unit
Integer
[0..127]
Impact of Change
No service impact.
Value
Parameter
Zone Code Type
SAM Table Name
Zone Code
OSS ID
ltemme.MMEZoneCodeAbs.zoneCodeType
Range & Unit
Choice List
- All TAI (UE can roam in any TAC in the MME Home Network)
- Limited TAI (UE can roam in designated TACs in the MME
Home Network)
- None TAI (UE is restricted from roaming in any TAC in the
MME Home Network)
Impact of Change
No service impact.
Value
Operator Dependent; default = not provisioned
When Limited TAI is selected for the Zone Code Type, one or more TAIs must be
assigned to the zone. Select one or more Mobile Network Codes from the Unassigned
TAI panel and move them to the Assigned TAI panel.
Parameter
Mobile Network Codes
SAM Table Name
Unassigned TAI panel
OSS ID
ltemme.ZoneCode.listOfTAI
Range & Unit
Choice List
- sub-menu showing all currently provisioned TAIs.
Issue 11.01
Impact of Change
No service impact.
Value
Operator Dependent; default = not provisioned
LTE/DCL/APP/031094
Nokia 2016
558 / 652
8.1.39.3
IMEI Parameters
The Obtain IMEISV parameter indicates if/how the MME obtains the IMEI (International
Mobile Equipment Identifier) from the UE.
Parameter
Obtain IMEISV
SAM Table Name
OSS ID
ltemme.MMEPLMN.obtainIMEISV
Range & Unit
Choice list
SMC obtain IMEISV from UE using Security Mode
Command message
IDR obtain IMEISV from UE using Identity Request
procedure
None do not obtain IMEISV
Impact of Change
No service impact.
Value
Operator Dependent; default = SMC
Rule: Obtain IMEISV

This parameter is locally provisioned and is not provisioned on a PLMN basis. Only
the value of the Home PLMN is used for the MME.
Rule: Obtain IMEISV = None

If the MME does not obtain the IMEI from the UE (Obtain IMEISV = none), then the
MME cannot perform a validation of the IMEI in the EIR (Validate IMEI with EIR =
False).
The Validate IMEI with EIR parameter indicates whether or not the MME performs a
validation of the IMEI in the EIR. The validation is performed over the S13 link as part of
the attach procedure. The validation permits the operator(s) of the MME 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) See figure below for IMEI validation. See Section
8.1.25.1 for attach procedure information.
Figure 8-87: Validate IMEI over S13
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
559 / 652
Legend:
1. The MME sends an Identity Request (Identity Type) to the UE. The UE responds
with Identity Response (Mobile Identity).
2. If the MME is configured to check the IMEI against the Equipment Identity Register
(EIR), it sends ME Identity Check (ME Identity, IMSI) to EIR. The EIR responds with
ME Identity Check Ack (Result).
The MME analyzes the result code in the response from the EIR in order to determine
its subsequent actions (such as allowing Attach procedure to continue, or sending an
Attach Reject).
If there is no response from EIR, or the responses result code indicates equipment is
blacklisted or unknown to the MME, the MME sends Attach Reject.
Parameter
Validate IMEI with EIR
SAM Table Name
MME Public Land Mobile Network
OSS ID
ltemme.MMEPLMNAbs.validateIMEIEIR
Range & Unit
Boolean
Impact of Change
No service impact.
Value
Operator Dependent; default = False (do not validate)
Rule: Validate IMEI with EIR

This parameter is locally provisioned and is not provisioned on a PLMN basis. Only
the value of the Home PLMN is used for the MME.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
560 / 652
Depending on the setting of the global parameter Support IMEI Digit Validation to
allow or reject request, MME checks and validates the received IMEI coding to ensure
that it complies to the 3GPP standards (TS.23.003 ) and reject UEs with invalid IMEI
without waiting for the HSS to trigger the rejection.
Particularly, the MME ensures that the IMEI is composed of all decimal digits.
If IMEI is checked and length is 15, the 15th number can be a character f.
If IMEISV is checked, SVN part cannot be 99, 99 is reserved in 3GPP TS 23.003.
If checks pass, MME will include the IMEI received from the UE in the Terminal
Information AVP of the Update Location Request message
The global parameter Support IMEI Digit Validation specifies whether the MME
validates IMEI coding per standards and how to deal with invalid IMEI. One option is to
reject UEs with invalid IMEI.
Following are possible settings:
No (default) : No IMEI validation.
Allow : Validate IMEI and if invalid, do not store in VLR. Proceed with the
request,but if IMEI is required, the procedure is rejected
Reject : Validate IMEI and if invalid, reject request
Parameter
Support IMEI Digit Validation
SAM Table Name
Global Parameters
OSS ID
gParmName
String
Support IMEI Digit Validation
Range & Unit
gParmValue
Choice List
No,Allow,Reject
Issue 11.01
Impact of Change
No service impact.
Value
Operator Dependent; default = No , No IMEI validation.
LTE/DCL/APP/031094
Nokia 2016
561 / 652
8.1.39.4
Mobility Management Timers
Several timers and other provisioned parameters are used by the MME in Mobility
Management procedures. The MME provisioning GUI provides default values for each
of the fields, but the forms should be reviewed to determine whether or not the defaults
provide adequate performance. Updates should be made to each form as required.
Several timers are used by the MME in Mobility Management procedures. The timers
are defined via the Timer form on the provisioning web interface. The form provides
default values for each of the timers. Note: The T3413 timer (time to wait until
proceeding to the next paging attempt) is provisioned via the Paging Policy page.
At this time, the default values listed on the forms are the recommended settings.
However, users are encouraged to review the forms to ensure compatibility with their
network.
Parameter
SAM Table Name
Timer
OSS ID
timerName
Choice List
Range & Unit
timerUnit
timerName)
See table below for timerUnit.
timerValue
Integer
Issue 11.01
Impact of Change
No service impact.
Value
LTE/DCL/APP/031094
Nokia 2016
562 / 652
Displayed
Name
timerName
timerValue
(Range)
Default Value
Purpose
T3422
T3422
1 - 60 sec
6 seconds
Retransmit Detach Request
T3450
T3450
1 - 60 sec
6 seconds
Retransmit Attach Accept, TAU

Accept, or GUTI Reallocation
Command. Timer starts if an
attach request is accepted by
the network and the MME
sends an ATTACH ACCEPT
message to the UE. Timer
stops
after
receiving
an
ATTACH COMPLETE message
and considers the GUTI sent in
the
ATTACH
ACCEPT
message as valid.
T3460
T3460
1 - 60 sec
6 seconds
Retransmit Auth Request, or

Security
Mode
Command.
Timer starts when a Security
Mode Command is sent.
Normal stop occurs when
security mode Complete or
Security
Mode
Reject
is
received.
T3470
T3470
1 - 60 sec
6 seconds
Retransmit Identity Command.

Timer starts when IDENTITY
REQUEST is received. Timer
stops
when
IDENTITY
REQUEST is received.
T3485
T3485
1 - 60 sec
6 seconds
Retransmit Activate Default

Bearer Request, or Activate
Dedicated Bearer Request.
Timer
starts
when
an
ACTIVATE
DEFAULT/DEDICATED
EPS
BEARER
CONTEXT
REQUEST is sent. Timer stops
when ACTIVATE DEFAULT
EPS
BEARER
CONTEXT
ACCEPT/REJECT
or
ACTIVATE DEDICATED EPS
BEARER
CONTEXT
ACCEPT/REJECT is received.
T3486
T3486
1 - 60 sec
6 seconds
Retransmit
Request.
T3489
T3489
1 - 60 sec
4 seconds
Timeout before retransmission

of ESM Information Request.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
Modify
Bearer
563 / 652
Displayed
Name
timerName
timerValue
(Range)
Default Value
Purpose
T3495
T3495
1 - 60 sec
6 seconds
Retransmit Deactivate Bearer

Request. Timer starts when
DEACTIVATE EPS BEARER
CONTEXT REQUEST is sent.
Timer
stops
when
DEACTIVATE EPS BEARER
CONTEXT
ACCEPT
is
received.
T3402
T3402
1 - 60 min
12 minutes
Part of UE Attach Accept

message. Used by UE to initiate
the next Attach or TAU
procedure in case of a failure of
a previous attach or TAU
procedure.
T3412
T3412
31
decihours
20 decihours
Part of UE Attach Accept

message. Used by the UE for
periodic TAU. The MME starts
this timer when the UE state is
changed to the ECM-IDLE
state.
MBReachable
MBReachable
1 60 min
4 minutes
Minutes beyond T3412 for

taking actions when a UE does
not send TAU. Timer starts
when entering an idle state.
Timer stops when a NAS
message is received.
Mobile
Reachable LPA
Mobile
Reachable
LPA
0 3600 min
180 minutes
This timer is started after the

expiration of the T3412 timer.
The MME honors any network
requests before the expiration
of the T3412 timer. The UE is
detached once the timer is
expired. The timer is stopped if
there is any UE MM activity.
MMEInitDetach
MMEInitDetach
60
min
240 minutes
Timer started after T3412 and

Mobile Reachable begin. The
UE is placed into ECM-IDLE by
the MME when the MMEinitiated-Detach timer is started.
Timer starts when 'Mobile
Reachable' timer expires. Timer
stops when a NAS message is
received.
Issue 11.01
1500
LTE/DCL/APP/031094
Nokia 2016
564 / 652
Displayed
Name
timerName
timerValue
(Range)
Default Value
Purpose
Purge Timer
Purge_Timer
hours
48 hours
This timer is started after the

MME initiated detach timer
fires. If this timer fires before
the UE contacts the MME
again, the UE VLR data is
purged.
120
Table 22 Mobility Management Timers
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
565 / 652
8.1.39.5
Number of Message Retransmissions
The MME is provisioned with a retry attempt value for several mobility management
procedures. The value indicates the number of retries before the procedure is declared
Failed. Once the procedure is declared Failed, the MME takes the action specified in TS
24.301, Tables 10.2.2 and 10.3.2.
The number of retransmissions for each procedure is defined via the Message
Retransmissions object in navigation tree of the MME Object Instance. The form
provides default values for each of the procedures, but the form should be reviewed to
determine whether or not the defaults provide adequate performance. Updates should
be made to the form as required.
At this time, the default values listed on the form are the recommended settings.
However, users are encouraged to review the form to ensure compatibility with their
network.
Parameter
SAM Table Name
OSS ID

Message Retransmissions
ltemme.MSGRetriesAbs.mSGName
ltemme.MSGRetriesAbs.MSGmSGNumRetries
mSGName
Choice List
See table below for mSGName.
Range & Unit
MSGmSGNumRetries
Integer
[1..4]
Issue 11.01
Impact of Change
No service impact.
Value
LTE/DCL/APP/031094
Nokia 2016
566 / 652
Issue 11.01
Procedure Name
Displayed
Name
mSGName
MSGmSGNumRetries
(Default)
Detach Procedure
NetDetach
NetDetach
Attach Procedure
Attach
Attach
TAU Procedure
TAU
TAU
GUTI Reallocation
Procedure
GUTIRelocation
GUTIRelocation
Authentication Request
Procedure
AuthRquest
AuthRquest
Security Mode Command

Procedure
SecurityMode
SecurityMode
Identity Command
Procedure
IdentityCom
IdentityCom
Activate Default Bearer

Procedure
ActDefBrr
ActDefBrr
Activate Dedicated Bearer

Procedure
ActDedBrr
ActDedBrr
Modify Bearer Procedure
ModifyBrr
ModifyBrr
Deactivate Bearer
Procedure
DactBrr
DactBrr
ESM Information
Procedure
ESMInfo
ESMInfo
Ns8 (across the SGs

interface)
Ns8
Ns8
Ns9 (across the SGs

interface)
Ns9
Ns9
Ns10 (across the SGs

interface)
Ns10
Ns10
Ns12 (across the SGs

interface)
Ns12
Ns12
Acknowledgement
(across the S102
interface)
Ns102
Ns102
LTE/DCL/APP/031094
Nokia 2016
567 / 652
8.1.39.6
Deleting Dynamically Created Managed Objects
The MME is provisioned with a timer used for deleting dynamically created managed
objects from the system. After a dynamically created interface fails or becomes
disabled, this timer is the time to wait for an Enabled operation state before deleting the
interface.
Parameter
TdynMO
SAM Table Name
Timer
OSS ID
timerName
Choice List
TdynMO
Range & Unit
timerUnit
timerName)
Hours
timerValue
Integer
[1..24] hours
Issue 11.01
Impact of Change
No service impact.
Value
LTE/DCL/APP/031094
Nokia 2016
568 / 652
8.1.39.7
Implicit/Explicit Detach
The MME is provisioned with a value to define MME behavior when all current UE
bearers are to be removed and the UE is in the ECM-idle state. The MME can perform
an explicit detach and page the UE as part of the procedure, or perform an implicit
detach and detach the bearers without paging the UE.
Parameter
SAM Table Name
OSS ID
Use Explicit Detach

Global Parameters
gParmName
String
Use_Explicit_Detach
Range & Unit
gParmValue
Boolean
Yes or No
Impact of Change
No service impact.
Value
Operator Dependent; default = No (Implicit detach without

page)
8.1.39.8
SCTP Delivery
The MME is provisioned with a parameter to indicate whether or not the SCTP protocol
bit in the SCTP DATA chunk is set to Ordered or Unordered. Refer to [R28] for further
information regarding the SCTP protocol. Note: Currently, this parameter cannot be
updated.
Parameter
SAM Table Name
OSS ID
Use S6a SCTP Unordered Delivery

Global Parameters
gParmName
String
Use_S6A_SCTP_Unordered_Delivery
Range & Unit
gParmValue
Boolean
Yes or No
Issue 11.01
Impact of Change
No service impact; parameter cannot be changed.
Value
Operator Dependent; default = No (Ordered)
LTE/DCL/APP/031094
Nokia 2016
569 / 652
8.1.39.9
S1 Timer Provisioning
Several timers are used to define S1-MME interface behavior. The timers are defined
via the Timer form on the provisioning web interface. The form provides default values
for each of the S1-MME timers, but the form should be reviewed to determine whether
or not the defaults provide adequate performance. Updates should be made to the
Timer form as required.
At this time, the default values listed on the Timer form are the
recommended settings. However, users are encouraged to review the
form to ensure compatibility with their network.
Parameter
SAM Table Name
OSS ID

Timer
timerName
Choice List
Range & Unit
timerUnit
timerName)
seconds
timerValue
Integer
Impact of Change
No service impact.
Value
Displayed Name
timerName
timerValue
(Range)
Default
Value
Purpose
InitContextSetup
InitContextSetup
1 - 60 sec
8
seconds
When the MME sends a

message to the eNB for
an Initial Context Setup
Request, it expects to
receive
a
response
message from the eNB
(Initial Context Setup
Response
or
Initial
Context Setup Failure). If
the timer expires while
waiting for this response,
the MME considers that
this class 1 procedure
failed.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
570 / 652
Displayed Name
timerName
timerValue
(Range)
Default
Value
Purpose
SAEBearerSetup
SAEBearerSetup
1 - 60 sec
8
seconds

message to the eNB
related to a bearer
request, it expects to
receive a response. If the
timer
expires
while
failed.
SAEBearerRelease
SAEBearerRelease
1 - 60 sec
8
seconds

message to the eNB
related to a bearer
timer
expires
while
failed.
SAEBearerMobility
SAEBearerMobility
1 - 60 sec
8
seconds

message to the eNB
related to a bearer
timer
expires
while
failed.
UEContextRelease
UEContextRelease
1 - 60 sec
8
seconds

context release message
to the eNB, it expects to
receive
a
release
complete
response
message from the eNB. If
failed.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
571 / 652
Displayed Name
timerName
timerValue
(Range)
Default
Value
Purpose
UEContextModify
UEContextModify
1 - 60 sec
8
seconds

context
modification
message to the eNB, it
expects to receive a
modification
response
message from the eNB. If
failed.
HandoverRequest
HandoverRequest
1 - 60 sec
8
seconds

Handover
Request
expects to receive an
acknowledgment
response message from
the eNB. If the timer
expires while waiting for
this response, the MME
considers that this class 1
procedure failed.
S1Reset
S1Reset
1
sec
45
seconds

S1 Reset message to the
eNB, it expects to receive
a reset acknowledgment
procedure failed.
MMECnfgUpdate
MMECnfgUpdate
1 - 60 sec
8
seconds

configuration
update
expects to receive an
update acknowledgment
procedure failed.
Issue 11.01
LTE/DCL/APP/031094
180
Nokia 2016
572 / 652
8.1.39.10
NAS Provisioning
The MME is provisioned with a set of prioritized NAS signaling integrity protection
algorithms. The EPS Integrity Protection Algorithm table should be reviewed to
determine whether or not the default values provide adequate performance. Updates
should be made to the table as required.
Restriction: Impact of Changing EIA and EEA Priorities

The MME must be in a locked state to change the EIA and EEA priorities. This is
service-affecting as it causes all UEs to detach.
MME supports three EPS Integrity Algorithms (EIA). Up to three EIA Priorities
(ltemme.EIAAlgorithmAbs.eIAPriority) can be set using these values.
Parameter
SAM Table Name
EIA Value
EPS Integrity Protection Algorithm (EIA)
OSS ID
ltemme.EIAAlgorithmAbs.eIAValue
Range & Unit
Choice List
128-EIA1 (SNOW 3G)
128-EIA2 (AES)
128-EIA3 (ZUC)
Impact of Change
The MME must be in a locked state to change the EIA

priorities.
Value
Operator Dependent; see Table 19 for defaults
EIA Priority
Default EIA Value
(ltemme.EIAAlgorithmAbs.eIAPriority)
(ltemme.EIAAlgorithmAbs.eIAValue)
Priority 1
128-EEA1 (Snow 3G)
Priority 2
128-EEA2 (AES)
Priority 3
No Algorithm Selected
Table 23: EPS Integrity Algorithm Defaults
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
573 / 652
Rule: EIA Value Selection
Each EIA value can only be used once in the algorithm. That is, the MME will not
allow selection of an algorithm that has already been selected for one of the previous
priorities.
The MME is provisioned with a set of prioritized EPS Encryption Algorithms (EEA) to
support NAS signaling security. The EPS Encryption Algorithm table should be
reviewed to determine whether or not the default values provide adequate performance.
Updates should be made to the table as required.
MME supports four EPS Encryption Algorithms (EEA). Up to four EEA Priorities
(ltemme.EEAAlgorithmAbs.eEAPriority) can be set using these values.
Parameter
EEA Value
SAM Table Name
EPS Encryption Algorithm (EEA)
OSS ID
ltemme.EIAAlgorithmAbs.eEAValue
Range & Unit
Choice List
128-EEA0 (ciphering not used)
128-EEA1 (SNOW 3G)
128-EEA2 (AES)
128-EEA3 (ZUC)
Impact of Change
The MME must be in a locked state to change the EEA

priorities.
Value
Operator Dependent; see Table 20 for defaults
EEA Priority
Default EEA Value
(ltemme.EEAAlgorithmAbs.eEAPriority)
(ltemme.EEAAlgorithmAbs.eEAValue)
Priority 1
128-EEA1 (Snow 3G)
Priority 2
128-EEA2 (AES)
Priority 3
Priority 4
Table 24: EPS Encryption Algorithm Defaults

Rule: EEA Value Selection
Each EEA value can only be used once in the algorithm. That is, the MME will not
allow selection of an algorithm that has already been selected for one of the previous
priorities.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
574 / 652
8.1.39.11
NAS Cause Code Provisioning
The MME is provisioned with a default set of NAS cause code values to send to the UE
whenever the UE access to the LTE network is rejected because of a specific access
restriction type. Each type of access restriction is assigned a default NAS cause code.
The administrative user may reassign the NAS cause code value by selecting a
different value from among all NAS cause codes listed in Table 22 (Annex A.2 of TS
24.301)
Parameter
Access Restriction To NAS Cause Mapping Profile
SAM Table Name
Access Restriction To NAS Cause Mapping Profile
OSS ID
ltemme.STRING
Range & Unit
Choice List
PLMN of IMSI is not allowed
UE is not allowed in a TAI in HPLMN
Roaming UE is not allowed in the TAI
EUTRAN restricted in the UEs HPLMN
Roaming UE EUTRAN restricted in a VPLMN
Roaming restricted du to unsupported feature
ODB All Packet Oriented Services Barred
CSG restricted
Not allowed LAI in HPLMN
Roaming UE not allowed LAI
GPRS not allowed in HPLMN
Roaming UE GPRS not allowed in VPLMN
2G3G Target Access Restricted by Node
LTE Target Access Restricted by Node
Issue 11.01
Impact of Change
No service impact.
Value
Operator Dependent; default = Null (Use Default Codes)
LTE/DCL/APP/031094
Nokia 2016
575 / 652
Access Restriction
Type
PLMN is Not
Allowed
Non-Roaming UE is
not allowed in a TAI
in the MME Home
PLMN.
Roaming UE is not
allowed in the TAI.
EUTRAN (LTE)
Restricted to a UE
from the MME
Home PLMN
EUTRAN (LTE)
Restricted to a
Roaming UE
Roaming Restricted
Due to
Unsupported
Description
Default NAS
Cause Value
This NAS cause is sent to the UE in the

appropriate Reject message if the UE sends
Attach Request, TAU Request, or Service
Request, but the UE PLMN is not allowed to
operate in the MME Home PLMN. This access
restriction type does not apply to UEs whose
PLMN is the MME Home PLMN.
11 - PLMN Not
allowed
This NAS cause is sent to a UE whose Home

PLMN is the MME Home PLMN, if the UE
sends Attach Request, TAU Request, or
Service Request while in a tracking area that is
not allowed to the UE.
12 Tracking area
is not allowed
This NAS cause is sent to a roaming UE that

sends Attach Request, TAU Request, or
Service Request from a tracking area that is
not allowed.
13 Roaming not
allowed in this
tracking area
This NAS cause is sent to a UE whose IMSI

indicates it is from the MME Home PLMN,
where the UE sends Attach Request, TAU
Request, or Service Request, but its HSS
subscription data (Access-Restriction-Data), or
its provisioned data, indicates that it is not
allowed to operate in the EUTRAN network.
7 - EPS services
not allowed
This NAS cause is sent to a UE whose IMSI

indicates it is a Roaming UE, where the UE
sends Attach Request, or TAU Request, but its
HSS subscription data (Access-RestrictionData), or provisioned data, indicates that is is
not allowed to operate in the EUTRAN
network.
14 - EPS services
not allowed in this
PLMN
This EMM cause is sent to the UE which

requests EPS service in a PLMN which does
not offer roaming for EPS services to that UE.
14 - EPS services
not allowed in this
PLMN
feature
ODB
All Packed Oriented
Services Barred
CSG Restricted
Issue 11.01
This EMM cause is sent to UE in Attach

Reject, TAU Reject and SR/ESR reject if UE
subscription data indicates that ODB-ALLAPN
AVP is set to barred or both ODB-HPLMNAPN and ODBVPLMN-APN AVPs are set to
barred.
08 EPS services
and non-EPS not
allowed
This EMM cause is sent to the UE if it requests

access in a CSG cell with CSG ID where the
UE either has no subscriptionto operate or the
UE's subscription has expired and it should
find another cell in the same PLMN.
25 Not authorized
for this CSG
LTE/DCL/APP/031094
Nokia 2016
576 / 652
Description
Default NAS
Cause Value

tracking area updating in a tracking area where
the HPLMN determines that the UE, by
subscription, is not allowed to operate.
12 Tracking area
is not allowed

tracking area updating in a tracking area where
the UE, by subscription, is not allowed to
operate, but when it should find another
allowed tracking area in the same PLMN.
15 No suitable
cells in tracking
area
This EMM cause is sent to the UE when it is

not allowed to operate EPS services.
7 - EPS services
not allowed
Access Restriction
Type
Not allowed LAI in
HPLMN
Roaming UE Not
Allowed LAI
GPRS Not Allowed

in HPLMN
Roaming UE GPRS
Not Allowed in
VPLMN
2G3G Target
Access Restricted
by Node
LTE Target Access

Restricted by Node
This EMM cause is sent to the UE which

requests EPS service in a PLMN which does
not offer roaming for EPS services to that UE.
14 - EPS services
not allowed in this
PLMN
This EMM cause is sent to the UE when the

target SGSN receive Context Response with
cause code=117 (Target Access restricted for
the subscriber) during RAU/TAU procedure
and UTRAN/GERAN to E-UTRAN/UTRAN
(HSPA) SRVCC procedure.
15 - No suitable
cells in tracking
area
This EMM cause is sent to the UE when the

target MME receive Context Response with
cause code=117 (Target Access restricted for
the subscriber) during RAU/TAU procedure
and UTRAN/GERAN to E-UTRAN/UTRAN
(HSPA) SRVCC procedure.
15 - No suitable
cells in tracking
area
Table 25: Access Restriction Default NAS Cause Values
Parameter
NAS Cause
SAM Table Name
Access Restriction to NAS Cause Mapping
OSS ID
ltemme.MMEAccessRestrictionAbs.nASCause
Range & Unit
Choice List
See Table 22.
Issue 11.01
Impact of Change
No service impact.
Value
LTE/DCL/APP/031094
Nokia 2016
577 / 652
CC#
Description
IMSI unknown in HSS
Illegal UE
IME not accepted
Illegal ME
EPS Services not allowed
EPS services and non-EPS services not allowed
UE identity cannot be derived by the network
10
Implicitly detached
11
PLMN not allowed
12
Tracking area not allowed
13
Roaming not allowed in this tracking area
14
EPS services not allowed in this PLMN
15
No suitable cells in tracking area
16
MSC temporarily not reachable
17
Network failure
18
CS domain not available
19
ESM failure
20
MAC failure
21
Sync failure
22
Congestion
23
UE security capabilities mismatch
24
Security mode rejected, unspecified
25
Not authorized for this CSG
26
Non-EPS authentication unacceptable
35
Requested service option not authorized in this PLMN
38
CS Fallback call established not allowed
39
CS domain Temporarily not available
40
No EPS Bearer Context Activated
42
Syntactical error in the TFT operation
95
Semantically incorrect message
96
Invalid mandatory information
97
Message type non-existent or not implemented
98
Message type not compatible with protocol state
99
Information element non-existent or not implemented
100
Conditional IE error
101
Message not compatible with protocol state
111
Protocol error, unspecified

Table 26 : NAS Cause Numeric Values and Description
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
578 / 652
The MME is provisioned with a global parameter Send NAS RAN Cause on S11 to
indicate whether or not to send the NAS or RAN failure indication code in private
extension IE on the S11 interface to the SGW.
If the global parameter Send RAN NAS Codes on S11 is set to YES, then the MME:
a) sends a provisioned cause value in the Private Extension IE of the following
S11 messages toward the SGW (related to rejection of Attach, TAU, or
SR/ESR), and
b)
the UE state changes to de-registered only if the rejection involves deactivation

of bearers in the EUTRAN and/or in the network:
Create Bearer Response.
Release Access Bearer Request.
Update Bearer Response.

Parameter
Send NAS RAN Cause on S11
SAM Table Name
Global Parameters
OSS ID
Range & Unit
gParmName
String
Send_NAS_RAN_Cause_on_S11
gParmValue
Boolean
Yes or No
Impact of Change
No service impact.
Value
Operator Dependent; default = No (Do Not Send)
feature
m10108-01
To indicate that the MME should send NAS and RAN failure indication codes on the
S11 interface to the SGW, the global parameter Send NAS RAN Cause on S11 field
has to be set to Yes. Sending the NAS or RAN failure indication code allows the SGW
to include the failure code in the CDR records so the operator can adjust charging in
certain cases.
The global parameter Send SGW 3GPP NAS Ran Cause enable/disable the inclusion
of 3GPP NAS/RAN cause value in the S11 Delete Session Request and Delete Bearer
Command messages and adds the flexibility to switch between standard IE and private
extension.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
579 / 652
Parameter
Send SGW 3GPP NAS Ran Cause
SAM Table Name
Global Parameters
OSS ID
Range & Unit
gParmName
String
Send SGW 3GPP NAS Ran Cause
gParmValue
Boolean
Yes or No
Impact of Change
No service impact.
Value
Operator Dependent; default = No (Do Not Send)
feature
m10154-01
The existing global parameter Send NAS RAN Cause on S11 no longer control the
3GPP NAS/RAN cause values in the S11 Delete Session Request and Delete Bearer
Command messages.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
580 / 652
8.1.39.12
Diameter cause code provisioning
Th MME is provisioned with a set of NAS cause code values to send to the UE
whenever the HSS rejects the UE access to the network with any of the S6a Diameter
Result/Experimental-Result cause values.
Each Diameter result is assigned a default NAS cause code (Table 23).
The administrative user may reassign the NAS cause code value by selecting a
different value from among all NAS cause code listed in Table 22
The MME is also provisioned with a value to indicate whether the provisioned NAS
cause code values or the default NAS cause code values should be used when sending
replies to the UE for errors indicated by experimental Diameter cause codes.
Prior to WM7.0 release, if the global parameter Use Mapped Diameter Codes is set
to True, then the provisioned NAS cause code values indicated in the Table 26
Diameter Cause to NAS Cause Mapping are used, otherwise MME uses the default
NAS cause code values , when sending replies to the UE for errors indicated by
experimental Diameter cause codes. (Table 24: Diameter experimental-result code AVP
to NAS Cause Code Mapping)
Parameter
Use Mapped Diameter Codes*
SAM Table Name
Global Parameters
OSS ID
Range & Unit
gParmName
String
Use_Mapped_Diameter_Codes
Impact of Change
gParmValue
Boolean
Yes or No
Value

(Use Default Codes)
From WM7.0 and later release, the table Diameter Code to NAS Cause Code
Mapping replaced the table Diameter cause and used to map a Diameter Cause Code
to the corresponding NAS cause code.
Diameter Causes in the Result-AVP are defined in [R25]; causes in Expermental-Result
AVP are defined in TS 29.272 [R13].
Please refer to [R32] procedure 8-57 for configuring Diameter Cause values.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
581 / 652
Parameter
Diameter Cause*
SAM Table Name
MME Diameter Cause
OSS ID
ltemme.MMEDiameterCauseAbs.diameterCause
Range & Unit
Choice List
3002 Diameter Unable to Deliver
3003 - Diameter Realm Not Served
5001 User Unknown
5003 Authorization Rejected
5004 Roaming Not Allowed
5012 Unable to Comply
5420 Unknown EPS Subscription
5421 RAT Not Allowed
5422 Equipment Unknown
Impact of Change
No service impact.
Value
Parameter
Diameter Result
SAM Table Name
Diameter NAS Cause Code Mapping Profile
OSS ID
ltemme.INT
Range & Unit
Choice List
See Table 23: Diameter result-code AVP to NAS Cause
Code Mapping
Impact of Change
No service impact.
Value
Operator Dependent;
Feature
m10109-02
If the MME receives a Diameter result code that indicates a failure, the request is
rejected with the EMM cause provisioned in the corresponding Diameter NAS Cause
Code Mapping. (Table 26)
[Note: global parameter Use Mapped Diameter Codes becames obsolete and diameter
cause table is no longer used with feature m10109-02 starting in WM7.0 and later
release. MME Diameter Cause is evolved to a corresponding NAS cause value in the
table Diameter NAS Cause Code Mapping Profile]
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
582 / 652
All Diameter answer messages from HSS include either one Result-Code AVP or one
Experimental-Result AVP.
There are two different types of errors in Diameter: protocol and application errors.
A protocol error is one that occurs at the base protocol level, and may require per hop
attention (e.g., message routing error) while application errors occur due to a problem
with a function specified in a Diameter application (e.g., user authentication, Missing
AVP).
Result-Code AVP values that are used to report protocol errors must only be present in
answer messages whose E bit is set. When a request message is received that
causes a protocol error, an answer message is returned with the E bit set, and the
Result-Code AVP is set to the appropriate protocol error value. When a Diameter entity
is reporting an application error, the R bit in the Command Flags is clears and the
Result-Code AVP is adds with the proper error value.
Result-Code AVP: The Result-Code AVP indicates whether a particular request was
completed successfully or whether an error occurred. The Result-Code AVP describes
the error that the Diameter entity encountered in its processing. All Diameter answer
messages include one Result-Code AVP. A non-successful Result-Code AVP (one
containing a non 2xxx value (success)) includes the Error-Reporting-Host AVP. There
are certain Result-Code AVP application errors that require additional AVPs to be
present in the answer. In these cases, the Diameter node that sets the Result-Code
AVP to indicate the error must add the AVPs. The Result-Code AVP are classified in
the following categories of classes of errors and are identified by the thousands digit in
the decimal notation:
1xxx (Informational)
2xxx (Success)
3xxx (Protocol Errors)
4xxx (Transient Failures)
5xxx (Permanent Failure)
Experimental-Result-Code: The Experimental-Result-Code AVP contains the protocol

error value representing the error result of the processing the request. The
Experimental-Result AVP indicates whether a particular 3GPP vendor-specific request
was completed successfully or whether an error has occurred.
As per TS29.272 [R13], when one of the result codes contains AVP value=4181,
5001,5420,5421,5004,5422 and 5423 is included in a response, it shall be inside an
Experimental-Result AVP and the Result-Code AVP shall be absent.
If the Experimental Result indicates "Unknown EPS Subscription", the Error Diagnostic
AVP may be present to indicate whether or not GPRS subscription data are subscribed
(i.e. whether or not Network Access Mode stored in the HSS indicates that only circuit
service is allowed). If the Experimental Result indicates "Roaming Not Allowed", and the
Update Location is rejected due to ODB, Error Diagnostic may be present to indicate
the specific type of ODB.
The specific errors that can be described by this AVP are described in Table 23
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
583 / 652
Result AVP
Categories
Result
AVP
value
Informational
1001
Multiple Round
Authentication
17 Network Failure
3001
Command Unsupported
17 Network Failure
3002
Unable to Deliver
17 Network Failure
3003
Realm Not Served
17 Network Failure
3004
Too Busy
17 Network Failure
3005
Loop Detected
17 Network Failure
3006
Redirection Indication
17 Network Failure
3007
Application Unsupported
17 Network Failure
3008
Invalid Header Bits
17 Network Failure
3009
Invalid AVP Bits
17 Network Failure
3010
Unknown Peer
17 Network Failure
4001
Authentication Rejected
17 Network Failure
4002
Out of Space
17 Network Failure
4003
Election Lost
17 Network Failure
5001
AVP Unsupported
17 Network Failure
5001
User Unknown
8 EPS and non-EPS services not allowed
5002
Unknown Session ID
17 Network Failure
5003
Authorization Rejected
15 No Suitable cells in tracking area
5005
Missing AVP
17 Network Failure
5006
Resources Exceeded
17 Network Failure
5007
Contradicting AVPs
17 Network Failure
5008
AVP Not Allowed
17 Network Failure
5009
AVP Occurs Too Many

Times
17 Network Failure
5010
No Common Application
17 Network Failure
5011
Unsupported Version
17 Network Failure
5012
Unable to Comply
17 Network Failure
5013
Invalid Bit in Header
17 Network Failure
5014
Invalid AVP Length
17 Network Failure
5015
Invalid Message Length
17 Network Failure
5016
Invalid AVP Bit

Combination
17 Network Failure
5017
No Common Security
17 Network Failure
All HSS's are down
15 No Suitable Cells in tracking area
No provisioned HSS
14 EPS services not allowed in this PLMN
Protocol
Errors
Transient
Failures
Permanent
Failures
Result-code AVP
Default NAS Cause Code
Table 27: Diameter result-code AVP to NAS Cause Code Mapping

Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
584 / 652
Experimental
-Result AVP
value
Experimental Result-
Error-Diagnostic
code AVP
Default NAS Cause Coe
4181
Authentication Data
Unavailable
17 Network Failure
5001
AVP Unsupported
17 Network Failure
5001
User Unknown
8 EPS services and

non-EPS services not
allowed
5004
Roaming Not Allowed
No Error-Diagnostic
AVP
11 PLMN not allowed
5004
Roaming Not Allowed
All APN
19 ESM Failure
5004
Roaming Not Allowed
HPLMN APN
5004
Roaming Not Allowed
VPLMN APN
5004
Roaming Not Allowed
Other Error-Diagnostic
Value
5011
Feature Unsupported
17 Network Failure
Overload Retry Not

Allowed To Any
Unknown EPS
Subscription
Unknown EPS
Subscription
17 Network Failure
5198
5420
5420
14 EPS services not

allowed in this PLMN
14 EPS services not
allowed in this PLMN
no Error-Diagnostic
AVP
GPRS_DATA_SUBS
17 Network Failure
15 No suitable cells in
tracking area
7 EPS services not
allowed
5420
Unknown EPS
Subscription
5420
Unknown EPS
Subscription
5421
RAT Not Allowed
5422
Equipment Unknown
tracking area
tracking area
6 Illegal ME
5423
Unknown Serving Node
2 IMSI Unknown in HSS
NO_GPRS_DATA_SU
BS
Other ErrorDiagnostic Value
tracking area
Table 28: Diameter experimental-result code AVP to NAS Cause Code Mapping
Whenever there is an overload condition at the Diameter Servers or DRA and request
times out, the clients are typically unaware of the overload condition and attempt to
send the message on an alternate connection with the Diameter server causing some
more traffic in the network.
In order to handle this overload condition effectively, a new vendor-specific Diameter
Experimental Result-Code 5198
(DIAMETER_OVERLOAD_RETRY_NOT_ALLOWED_TO_ANY) is added in WM10.0.0
and later release to indicate the overload state of Diameter agent.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
585 / 652
8.1.39.13
Extend Procedures to Include ULI Message
The MME can be provisioned to incorporate ULI (User Location Information) information
element and UE time zone IE in the following S11 messages regardless of the ULI flag
setting by PGW:
Create session request
Create bearer response
Modify bearer request
Delete session request
Delete bearer response
Update bearer response
If the ULI Enhancement global parameter is enabled, then:

The ULI IE is always included in S11 messages sent from the MME application to the
SGW regardless of whether PGW has requested it. If the ULI Enhancement global
parameter disabled, the ULI IE is included only if the PGW requests it.
MME always incorporates RAT Type IE and serving network IE in the S11 create
session request and modify bearer request.
Reporting intra-eNB cell change using cell notification request message. ULI
Enhancement must be enabled prior to enabling UE eNB Serving Cell Change
Reporting.
Parameter
ULI Enhancement
SAM Table Name
Global Parameters
OSS ID
Range & Unit
gParmName
String
ULI_Enhancement
gParmValue
Boolean
Yes or No
Issue 11.01
Impact of Change
No service impact.
Value
Operator Dependent; default = No (Disabled)
Feature
m10120-03
LTE/DCL/APP/031094
Nokia 2016
586 / 652
When UE eNB Serving Cell Change Reporting is enabled, the following S1-AP
messages support location reporting:
Location reporting control
Location report
Location report failure indication (only in case of failure)
S11 change notification request (for each active PDN connection for the UE)
S11 change notification response
Location report failure indication (eNodeB to MME message)
Handover request (in the case of S1 handover involving a target eNodeB)
Parameter
UE ENB Serving Cell Change Reporting
SAM Table Name
Global Parameters
OSS ID
Range & Unit
gParmName
String
UE_ENB_Serving_cell_Change_Reportin
g
gParmValue
Boolean
Yes or No
Impact of Change
No service impact.
Value
Operator Dependent; default = No (Disabled)
Feature
The ULI handling in S11 messages for S8 roamers is performed as follows:

User Local Information is included per 29.274 standards in S11 messaging for Home
Routed UEs using an S8 connection to the PGW when the ULI Home Routed UE"
global parameters is set to "YES" (default).
Only when the ULI Home Routed UE" global parameters is set to NO, ULI will be
excluded from S11 messages associated with S8 Home Routed UEs. (Inbound roamer
UEs using S8 interface).
This ULI inclusion can be enabled/disabled via the following ULI Home Routed UE"
global parameter:
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
587 / 652
Parameter
ULI Home Routed UE
SAM Table Name
Global Parameters
OSS ID
Range & Unit
gParmName
String
ULI Home Routed UE
gParmValue
Boolean
Yes or No
Impact of Change
No service impact.
Value
Feature
m10120-05
If the LRA ULI global parameter is enabled (LTE Rural Access ULI Reporting) , the
ULI IE along with the serving network IE are included in the Modify Bearer Request
message across the S11 interface when a UE changes selected PLMN for billing
purposes.
Parameter
LRA ULI
SAM Table Name
Global Parameters
OSS ID
gParmName
String
LRA ULI
Range & Unit
gParmValue
Boolean
Yes or No
Impact of Change
No service impact.
Value
Feature
m10120-07
The setting of the ULI Home routed UE global parameter is mutually exclusive of the
setting for the ULI enhancement global parameter. Even if the ULI enhancement global
parameter is enabled (set to Yes ), if the ULI Home Routed UE global parameter is set
to No the ULI IE will not be included for roamer UEs using the S8 interface.
ULI enhancement also provides capability to directly request the UE location inforration
from the eNB as per 23.401 requirements ("PDN GW initiated bearer modification
without bearer Qos Updates").
The global parameter Retrieve UE Location determines whether UE Location
Information is retrieved from the eNB.
When Retrieve UE Location global parameter is set to "YES", User Location
information will be retrieved from eNB via S1AP_DIRECT action in Location Control
Request.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
588 / 652
When the Retrieve UE Location global parameter is set to NO (default), the User
Location information utilized in S11 messages will be the last known UE location.
Parameter
Retrieve UE Location
SAM Table Name
Global Parameters
OSS ID
gParmName
String
Retrieve UE Location
Range & Unit
gParmValue
Boolean
Yes or No
Impact of Change
No service impact.
Value
Feature
m10120-05
If the global parameter "Support Dedicated Bearer ULI" is enabled (ULI Enhancement
for Dedicated Bearer Activation procedure is enabled) both ECGI and TAI are
incorporated in the Create Bearer Response , Update and Delete bearer messages that
is sent towards SGW across S11 interface. [R14] 3GPP 29.274 specifies that only ECGI
is included within ULI information element in Create Bearer Response message by
MME, however ULI Enhancement for Dedicated Bearer could be activated to deviate
from standards by incorporating both ECGI and TAI in Create Bearer Response
message per customer request.
Parameter
Support Dedicated Bearer ULI
SAM Table Name
Global Parameters
OSS ID
gParmName
String
Support Dedicated Bearer ULI
Range & Unit
gParmValue
Boolean
Yes or No
Issue 11.01
Impact of Change
No service impact.
Value
Operator Dependent; default = disabled
Feature
m10120-09
LTE/DCL/APP/031094
Nokia 2016
589 / 652
8.2 ESM Procedures
8.2.1 ESM OVERVIEW
The ePS Session Management (ESM) procedures support bearer activation,
modification, deactivation, and preservation of data sessions (specifically, ePS bearers
to support communication between the UE and the Evolved Packet Core Network).
The MME plays a major role in all phases of ESM procedures such as creation,
modification and termination of ePS bearers in relation to ESM session management
scenarios/procedures.
The MME :
creates context and assigns bearer identity for default bearer creation for GTP
based S5/S8.
interacts with UE/eNodeB to setup Radio bearers, communicate UL TEID, etc.
gets DL TEID from eNodeB, which it communicates to SGW.
The MME also plays major role in establishing, modifying and deactivating
dedicated/default bearers. For example, if UE is in ECM-IDLE state, MME triggers a
Network Triggered Service Request and sends a Bearer Setup request upon receiving
a response from the UE/eNodeB.
8.2.1.1
ESM Procedures
MME supports the following ESM procedures as defined in 3GPP TS 23.401 and
24.301:
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 modification
HSS-initiated subscribed QoS modification.
ESM procedures are generally comprised of messages sent between two network
elements (such as the MME and the SGW) during EMM procedures (such as Attach,
Detach, and TAU).
ESM cause code Reactivation Requested is received by the MME in the Delete
Bearer Request for the following scenarios:
UE is ECM-IDLE and last PDN connection is not being deleted:
If the UE is in ECM-IDLE, when MME received a PGW initiated Bearer Deactivation

with cause#8 Reactivation Requested and the last PDN connection is not being
deleted, the MME immediately initiates paging via Network Triggered Service Request
Procedure (23.401 5.3.3.3, from step 3a onward) in order to inform the UE about the
bearer(s) deactivation, which allows to transfer the cause value from the SGW/PGW to
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
590 / 652
the UE (especially required from Rel-10 onwards where cause values #8 "Reactivation
Requested" and #9 "PDN reconnection to this APN disallowed" have been introduced).
Upon becoming ECM-CONNECTED, following paging, the MME shall proceed

with the Bearer Deactivation Request. The S11 cause value #8 shall be mapped
into NAS cause #39 "Reactivation Requested"
Note:
Informing the UE of the PDN connection disconnect, allows the UE to re-
establish the EPS bearer/PDN connection upon becoming ECM-CONNECTED

following the paging.
Paging is initiated via Network Triggered Service Require
procedure in 23.401 clause 5.3.4.3, from step 3a onward.UE is ECM-CONNECTED and

last PDN connection is not be deleted
if the UE is in ECM-CONNECTED, when MME received a PGW initiated Bearer
Deactivation with cause#8 Reactivation Requested and the last PDN connection is not
being deleted, the MME), the MME proceeds with the Bearer Deactivation Request.
The S11 cause value #8 shall be mapped into NAS cause #39 "Reactivation
Requested"
The global parameter called Allow Bearer Deactivate Regular Deactivate can be
set to specify the NAS cause code included in Deactivate EPS Bearer Context request
message sent to the UE for PGW initiated PDN disconnection scenario.
MME upon receiving Delete Bearer Request from the network during PGW initiated
PDN disconnection scenario with the cause "Reactivation Requested" sends Deactivate
EPS Bearer Context request message to UE with the cause "regular deactivation" and
upon receiving DEACTIVATE EPS BEARER CONTEXT ACCEPT message from the
UE, MME accordingly send S11 Delete Bearer Response message to the SGW.
If the global parameter Allow Bearer Deactivate Regular Deactivate is set to Yes,
cause code #36 of regular deactivation is sent to UE, otherwise standard cause code
#39, "reactivation requested", is sent, which is by default the reactivation requested
cause value send towards the UE.
Parameter
Allow Bearer Deactivate Regular Deactivate
SAM Table Name
Global Parameters
OSS ID
Range & Unit
gParmName
String
Allow Bearer Deactivate Regular Deactivate
gParmValue
Boolean
Yes or No
Issue 11.01
Impact of Change
No service impact.
Value
Feature
m10538-08
LTE/DCL/APP/031094
Nokia 2016
591 / 652
8.2.1.2
Network Assisted Cell Change EUTRAN to GERAN
Network Assisted Cell Change (NACC) enables better performance for packet data
services upon inter- cell change for those networks that do not support PS Handover by
reducing 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, thus
allowing packet access. NACC is applicable for inter-RAT cell changes from a source EUTRAN cell towards a target GERAN cell. NACC from E-UTRAN to GERAN follows the
principles of the NACC between UTRAN and GERAN as described in TS 25.413 and
TS 23.060 (v8.10.0).
RAN Information Management (RIM) elementary procedures provide a generic
mechanism for the exchange of arbitrary information between applications belonging to
the RAN nodes, such as in this case between the eNB and MME (over S1 interface)
and between the MME and SGSN (over Gn interface).
MME and SGSN supporting the RIM procedures provide addressing, routing and
relaying functions. Specifically, the MME does not interpret the transferred RAN
information; it only performs relaying between S1 and Gn messages as described in
3GPP TS 36.413 and 3GPP TS 29.274 /TS 29.060.
The source RAN node (eNB) sends a message to its MME or SGSN including the
source and destination addresses. 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 interface. The MME/SGSN connected to
the destination RAN node decides which RAN node to send the message to based on
the destination address.
Elementary procedures utilized in this scenario are:
eNB Direct Information Transfer.
MME Direct Information Transfer.
8.2.1.3
Piggybacking
The Piggybacking functionality carries combined messages for the default bearer
activation at Attach and UE requested PDN connectivity procedures and for the
Dedicated Bearer Activation procedure in a single message.
Piggybacking is only applicable if all nodes in the chain (MME, SGW and PGW) support
piggybacking.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
592 / 652
8.2.1.4
Cell Reselection and Redirection
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 (either connected or idle mode).
A UE with single receiver configuration attaches to only one RAT at a time (such as EUTRAN) and maintains registration and mobility procedure handling specific to that
RAT. The UE regularly searches for a better cell as per cell selection criteria. When a
new cell is found, 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
release access bearers and delete bearers for this UE.
A UE with dual receiver configuration attaches separately to each RAT (such as EUTRAN and 1xRTT) 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 reselection, 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.
MME stores the cause of context release due to inter-RAT redirection in PCMD. Refer
to PCMD Reference Guide, 9YZ-05481-0015-RKZZA, for PCMD information.
Refer to 9471 WMM Observation Counters, 9YZ-05481-0006-RKZZA, for performance
measurement(s) related to S1 release, Inter-RAT redirection.
EUTRAN to GERAN/UTRAN cell reselection and redirection (utilizing an eNB to MME
UE context procedure message specifying cause = Inter-RAT Redirection, as defined in
3GPP TS 36.413 and 23.401) was introduced in LM2.0. LTE to CDMA-2000 1xRTT
(utilizing the extended service request procedure with CS fallback for dual-receivers as
defined in 3GPP TS 23.272) is introduced in LM5.0.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
593 / 652
8.2.1.5
Enhanced SGW restoration procedure
In releases earlier than WM8.0.0, upon detection of S11 path loss or SGW restart, the
MME detached UEs associated with the failed SGW
Starting in WMM8.0 and later releases, upon detection of S11 path failure or SGW
restart, MME does not detach UEs associated with the failed SGW as done ealier. MME
retains the UE context.
MME starts releasing S1 connection of the connected UE and starts allocating a new
SGW as soon as they become idle.
MME starts S1 release of UEs in connected mode (ECM-CONNECTED) and as soon
the S1 is released, a UE is assigned a new SGW using the S-NAPTR procedure.
MME releases S1 of UEs in connected mode in the order specified in the following:
UEs with emergency session in ECM-CONNECTED state
UEs with emergency session in ECM-IDLE state
UE in ECM-CONNECTED state with QCI=1 bearers
UE in ECM-CONNECTED state with other GBR bearers
UE in ECM-CONNECTED state without GBR bearers
SGW restoration procedure prioritizes recovery of UE in ECM-IDLE state based on the

provisioned list of APN and subscribed Restoration-Priority per APN.
Home subscribers will always be restored before the restoration of the roamers.
Prioritization is used for the following reasons:
To allow all the affected UEs to be reconnected to the network in a relatively short time
(that is function of the speed of the SGW relocations that the MME/S4-SGSN performs,
based on implementation and the network load) so that downlink packets may be
delivered to the UEs with minimum service interruption.
Prioritizing the restoration of emergency PDN connections allows preserving emergency
calls in progress for authenticated and unauthenticated users, and enabling PSAP to
call back authenticated users with an emergency registration but without an emergency
call in progress.
Details of the MME prioritization algorithm of UE recovery based on the APNs and
APNs restoration priority is presented here after.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
594 / 652
The following diagram shows MME actions upon detecting S11 path failure to a MME:
MME actions upon detecting S11 path failure

Starts the restoration timer
Do not detach connected UEs associated
with SGW
Do not mark implicitly detach idle UEs
No
Echo Response
Received?
Until timer expires or S11 path is restored

Trigger SGW relocation if SR received
Trigger SGW relocation if TAU request
with active flag is received
Trigger SGW relocation for HO.
Continue to monitor S11 path
Yes
Yes
No
4
S11 path is
restored and SGW
has not restarted
Restoration Timer
Expired?
No
3
S11 Path is restored

with SGW restart
Yes
No
Yes
SGW Restart:
MME actions upon if the timer has not expired
Trigger SGW relocation if SR received from
a UE associated with the SGW with S11
path failure
Trigger SGW relocation if TAU request with
active flag is received
Gradually start relocating idle UE to other
SGWs
SGW has not restarted:
MME actions if the timer has not expired
MME assumes that SGW has valid UE
context
Stops triggering of SGW relocation
Resumes normal operation
Stops the timer
Restoration Timer
Expired?
Yes
MME actions if the Restoration timer expired

All remaining UEs will be marked
detached.
Rejects UE initiated requests to force UE to
reattach
Rejects all network requests
Figure 8-88: SGW Restoration algorithm
The Restoration Priority allows restoring with a higher priority users with an IMS voice
subscription over IMS users without an IMS voice subscription.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
595 / 652
The following events take place when restoration priority is configured:
The eNB can initiate S1 release of an ECM-CONNECTED UE. MME proceeds with the
request and as soon as the S1 is released the UE is assigned a new SGW.
The MME scans through the entire UE context database and starts SGW relocations
until the SGW restoration timer is expired. Note that the new SGW selected may be
the original SGW if has restarted.
MME handles any UE MM requests
Request) as they arrive and if the UE
then MME first assigns a new SGW to
This capability to relocate UE to a new
and this capability is extanded to SR
feature or not.
(Trakcing Area Update or Extanded Service

is associated with the failed or restarted SGW
the UE and then continues with the procedure.
or restarted SGW is already supported for TAU
irrespectively of activation of the PGW restart
In the case of TAU that involves MME/SGSN relocation, MME indicates that SGW
change is required in the S10/S3 Context Response message. The new MME may try
the old SGW if it has not detected the SGW failure. If the old SGW does not respond
then the new MME will select a new SGW.
MME prioritization of idle (ECM-IDLE state) UE recovery based on provisioned APN
priority and its subscribed restoration priority is supported as described in the following.
The provisioning can be done per PLMN.
The SGW restoration enhancement is activated via the global parameter Enhanced
SGW Restoration Procedures
Parameter
Enhanced SGW Restoration Procedures
SAM Table Name
Global Parameters
OSS ID
Range & Unit
gParmName
String
Enhanced SGW Restoration Procedures
gParmValue
Boolean
Yes or No
Impact of Change
No service impact.
Value
Feature
m10538-08
A new timer SGW Restoration Timer is used to guard the MME attempt to assign UE
associated with a failed SGW or restarted SGW:
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
596 / 652
Parameter
SGW Restoration Timer
SAM Table Name
Timer
OSS ID
Range & Unit
timerName
SGW Restoration Timer
timerUnit
timerName)
minute
timerValue
Integer
[1..180] min
Impact of Change
No service impact.
Value
Feature
m10538-08
Recovery basically consists of selecting a SGW using S-NAPTR procedure and recreating PDN sessions on the selected SGW.
All the PDN connection of the UE will be created on the selected SGW.
The selected SGW may be a new SGW or the old SGW if it has restarted.
The MME is provisioned with the following APN priority attributes to support the
prioritization of idle non-emergency UE recovery.
Issue 11.01
Parameter
APN Priority List Name
SAM Table Name
UE PLMN Services Detail
OSS ID
ltemme.UEPLMNServices. ApnPriorityListName
Range & Unit
String
Impact of Change
No service impact.
Value
Operator Dependent;
Feature
m10538-08
LTE/DCL/APP/031094
Nokia 2016
597 / 652
Parameter
APN Priority NI
SAM Table Name
APN Priority Details
OSS ID
ltemme. ApnPriority.ApnPriorityNi
Range & Unit
String
Impact of Change
No service impact.
Value
Feature
m10538-08
Parameter
APN Priority Value
SAM Table Name
APN Priority Details
OSS ID
ltemme. ApnPriority.ApnPriorityValue
Integer
Impact of Change
No service impact.
Value
Feature
m10538-08
APN Priority-NI: APN Network Identifier as defined in 3GPP TS 23.007 clause

9.1.
APN Priority MME uses the APN priority to prioritize the UE recovery based
on the APN priority. The priority value ranges from 1 to 8. The priority level 1
has the highest priority and the value 8 has the lowest priority. Any APN that is
not in the list will be assigned the lowest priority 8. Note that this priority is used
for a given subscriber if the subscriber has a PDN connection to an APN in the
priority list at the time of failure.
The subscribed Restoration Priority per APN received from the HSS is used to
determine the relative restoration priority among PDN connections to the same APN.
MME computes a normalized priority of a UE based on the provisioned APN priority and
the subscribed APN restoration priority when MME sets up a PDN connection. Once the
normalized priority is computed, it will only be recomputed whenever MME handles any
UE or network initiated session management requests. So, any provisioning changes
will only take into effect on a subsequent session management procedure. However,
any updates to the APN restoration priority AVP for a UE will take effect immediately.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
598 / 652
8.2.1.6
S11 PGW Restart notification
Before WMM8.1.0 when SGW detecs that a peer PGW has failed or restarted, SGW
sends to the MME a Delete Bearer Request for each associated bearer on the failed
PGW which may lead to in some race condition to a spike in signaling on S11 interface.
In WMM8.1.0, MME support S11 PGW Restart Notification (PRN) message I.E
indication in GTP Echo Request/Response with SGW and appropriate actions on
impacted UEs as specified by 3GPP TS 23.007.
Figure 8-89: PGW failure / PGW Restart

A PGW Restart Notification message is sent by the SGW when it detects that the peer
PGW has restarted or failed but not restarted (i.e. not responding). When SGW detects
that a peer PGW has failed, all PDN connections associated with that PGW are deleted
and a PRN message is sent to the MME.
If the global parameter PGW Restart Notification is enabled (PGW Restart Notification
set to YES), MME sends support of PGW restart notification indication in IE of GTPv2
Echo Request and Echo Response. If the feature is not enabled then MME will not
indicate the support of PGW restart notification to the SGW.
Parameter
PGW Restart Notification
SAM Table Name
Global Parameters
OSS ID
Range & Unit
Boolean
Yes or No
Impact of Change
No service impact.
Value
Feature
m10538-02
When the MME receives the PGW Restart Notification from the SGW, the MME
responds to the SGW with a PGW Restart Notification Acknowledgement.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
599 / 652
The MME cleans up all the PDN connections associated with the SGW and the
restarted PGW.
The MME restores PDN connection based on the UEs ECM state and provisioning as
described in the table below:
UE conditions
MME action
If a UE is ECM connected and

UE has other PDN
connections associated with
other PGWs
sends UE S1AP E-RAB Release Command with NAS

message Deactivate EPS Bearer Context Request with
ESM cause value #39 (Reactivation Requested). After
the PDN connection is released, the UE sends PDN
connectivity procedure to re-establish the PDN
connection if the EPS bearer context was a default EPS
bearer context.
If a UE is ECM connected and

if the deleted PDN connection
is the last PDN connection
MME detaches the UE using the detach profile

provisioned for PGW Restart with new cause PGW
Restart Notification.
(introduced by FIDs m10143-01 and m10143-02)
MME pages the UE.
The provisioned paging policy for PGW restart is used.
If no paging policy was provisioned for PGW Restart,
the last eNB will be paged only once.
If a UE is in ECM-IDLE state
and paging is enabled for PDN
connection restoration
(APN associated with the
restarted PGW is provisioned
in the APN-NI list
When the UE responds with Service Request, if the UE

has other PDN connections associated with other PGWs,
the MME continues the Service Request, but excludes
the bearers of the impacted PDN connection in the S1AP
Initial Context Setup Request
This triggers the UE to delete all the bearers associated
with the impacted PDN and the UE is expected to initiate
re-establishment of the PDN connection.
If the PDN connection deleted is the last PDN connection
then MME implicitly detaches the UE by sending Detach
Request using the provisioned detach profile for the
reason PGW restart notification.
If a UE is in ECM-IDLE state
and the APN associated with
the restarted PGW is not
provisioned in the APN-NI list
MME implicitly deletes the impacted PDN connection

without signaling to the eNB/UE.
When UE later comes back with Service Request:
if there is still a PDN connection, the MME proceeds with
the Service Request
if all PDN connections have been deleted, the Service
Request is rejected with cause value #10 (implicitly
detached) to force UE to re-attach.
Table 29: How the MME restores the PDN connection based on UEs ECM
state and provisioning
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
600 / 652
The MME takes action on the UE with the APN as MM procedures are initiated as
specified in the following table:
MM Procedures
MME action
Service Request :
When Service Request is received for a UE that
has the APN, bearers associated with the APN
on the restarted PGW are excluded in the Initial
UE Context Setup Requestmessage.
No explicit indication of the deletion of the
bearers is required. UE is expected to locally
deactivate all the bearers associated with a
MME rejects service request by sending

Service Reject message with cause value
#10 (implicit detach).
default bearer for which no radio bearer is set up

and initiate re-establishment of PDN connection
by sending the NAS message PDN Connection
Request for the APN.
If the PDN connection is the last connection
Extanded Service Request :
o
If the PDN session deleted is the last PDN
detach profile for the reason PGW
connection,
If UE has other PDN connections :

o
PDN sessions associated with the

restarted PGW are locally deleted
then MME rejects the UE using the
Restart Notification
o
MME shall proceed with the ESR.

MME will not transfer the deleted PDN
connection(s) to the SGSN in the case
CSFB with PSHO
MME indicates the bearers removed using

the EPS bearer status IE in the TAU
accept message. The UE is expected to
delete locally bearers that are marked not
active and initiate re-establishment of PDN
TAU request
with no MME relocation of a UE that has APN,
connection by sending the NAS message

PDN Connection Request for the APN. If
the PDN connection is the last connection
then MME shall reject TAU request by
sending TAU Reject message with cause
value #10 (implicit detach).
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
601 / 652
MM Procedures
MME action
TAU request
MME exclude the bearers associated with
with MME relocation of a UE that has APN
the APN in the Context Response

message.
MME includes bearers associated with the
impacted PGW in the
E_RAB to be
Released List IE of the PATH SWITCH

ACK message.
If the last PDN connection deleted, the
X2 Handover
MME sends the PATH SWITCH

FAILURE message with cause Detach
and detaches the UE with the provisioned
detach profile for PGW Restart.
MME includes bearers associated with the

impacted PGW in the E-RABs to Release
List IE of the S1AP HANDOVER
COMMAND message to source eNB.
S1 Handover with no MME relocation
If the last PDN connection is deleted, the

MME sends the HANDOVER
PREPARATION FAILURE message with
cause Detach and detaches the UE with
the provisioned detach profile for PGW
Restart.
MME does NOT include bearers

associated with the impacted PGW in the
Forward Relocation Request message.
If the last PDN connection is deleted, the
S1 Handover with MME relocation
MME sends the HANDOVER

PREPARATION FAILURE message with
cause Detach and detaches the UE with
the provisioned detach profile for PGW
Restart.
Table 30: MME action on the UE based on MM procedures.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
602 / 652
How the MME prioritizes PDN connection restoration and cleanup:
If there are multiple PDN connections (APNs) associated with a restarted PGW or if
there are multiple PGW restarts then MME prioritizes restoration of sessions in the
following order by identifying UEs that have PDN connections on the restarted PGWs:
1. Restore sessions for a UE in connected state for any MM procedure (like HO)
and any procedure involving the restarted/failed PGW as they occur as long as
WMM is not in overload.
2. Explicitly or implicitly notify UE in idle state that certain PDN connections have
been de-activated when the UE initiates a MM procedure such SR and TAU.
3. UE in connected state with emergency PDN connection.
4. UE in idle state with emergency PDN connection.
5. UE in connected state with GBR bearers.
6. UE in connected state with non-GBR bearers.
Prioritize recovery of UE in ECM-IDLE state based on the provisioned list of APN and
subscribed Restoration-Priority per APN.
Home subscribers will always be restored before the restoration of the roamers.
MME actions to re-establish PDN connections will be done in a provisioned period of
time. Once the timer is expired, MME will stop the recovery of the PDN connection and
delete locally PDN connections of the left over UEs.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
603 / 652
The following parameters are applicable to support the PGW Restart preceding actions:
The provisioned APN-NI list (such as emergency APN, IMS, Internet, etc.) is associated
with the Service Agreement Profile and is used to indicate whether idle UE should be
paged to re-establish the PDN connection associated with a PGW restart. APN list can
have up to 16 APNs. If an APN-NI list is not provisioned then no attempt will be made to
re-establish any PDN connections associated with a PGW restart. A priority can be
defined to indicate the preferential order of restoring the session. Paging is executing
based on APN priority
A PGW restart Detach behavior profile :
o
PGW Restart Send NAS Cc flag : EMM Cause to be included: (default Yes)
PGW Restart Detach type to be used when the UE is detached. (default

Re-attached Required)
PGW Restart Notify Idle UE : (default No)
PGW Restart NAS Cause Code( to be sent to UE if it is detached due to

deletion of the last PDN connection triggered by PGW restart notification
(default Implicit Detach)
The timer PGW Restart Recovery specify the maximum duration in which MME
attempt to re-establish PDN connections. The MME starts the timer after the PRN
Acknowledegement is sent (when it starts the re-establishment procedure) and once
the timer expires the MME stops the re-establishment attempts and deletes PDN
connections associated with the PGW restart of the left over UEs.
The timer is set to 60 minutes by default.
Parameter
PGW Restart Recovery
SAM Table Name
Timer
OSS ID
Range & Unit
timerUnit
Minutes
timerValue
[30..300] minutes
Impact of Change
No service impact.
Value
A non-configurable timer PGW MO inactivity timer is used to monitor if a PGW

Maintenance Object (MO) has been inactive for a long time.. Once the timer expires,
the MO will be deleted. This timer ensures the deletion of unused MO if a PGW is taken
out of service. The timer will be restarted whenever an activity is seen on the MO. The
timer value is left to the design.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
604 / 652
8.2.2 EPS BEARERS
The ePS bearer is a logical association between the UE and the PGW, and aggregates
one or several data flows transported between the two entities.
Figure 8-90: ePS Bearer Components for GTP-based S5/S8

An ePS bearer is composed of three elements:
S5/S8 bearer (implemented by a tunnel that transports packets between the

SGW and PGW [note: this applies only to GTP).
S1 bearer (implemented by a tunnel that transports packets between the SGW

and eNodeB).
Radio bearer (implemented by a Radio Link Control (RLC) connection between

the eNodeB and the UE. There is one RLC protocol machine per radio bearer).
ePS bearer types:
Default bearer the initial bearer.
An ePS bearer that is established when the UE initially attaches to the network and
connects to a PDN is referred to as 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.
Dedicated bearer - any additional bearer established by same UE. May be GBR
or non-GBR.
Each GBR bearer is associated with Guaranteed Bit Rate (GBR) and Maximum Bit Rate
(MBR) QoS attributes. From the PGW to the PDN, the IP packet travels outside of any
tunnel.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
605 / 652
8.2.2.1
Multiple Bearers and Multiple PDNs
The UE may establish multiple bearers.

Multiple EPS Bearers have two sub-categories:
Multiple default EPS bearers: provide connections to different PDNs. Multiple

default EPS bearers are two or more EPS bearers independent from one another
and thereby supporting simultaneous connections to different PDNs (for example,
to the internet for one application, while to a private network for another one).
Note that for each APN / PDN that the UE is connected to, the UE is associated
with a unique IP address for that PDN.
dedicated EPS bearers: provide connections to the same PDN but with different
QoS
Figure 8-91: ePS Bearer UE Connected to Multiple PDNs for a GTP-based S5/S8
Figure 8-92: ePS Bearer UE Connected to a Single PDN for a GTP-based S5/S8
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
606 / 652
Legend:
RB
ePS Radio Bearer
LBI
Linked Bearer Identifier (provides the linkage between the

default bearer and dedicated bearers).
The EPS supports:
Simultaneous exchange of IP traffic to multiple PDNs through the use of separate

PGWs or a single PDN GW. The usage of multiple PDNs is controlled by network
policies and defined in the user subscription.
UE-initiated connectivity establishment in order to allow multiple PDN

connections to one or more PDNs. Note that the UE may also initiate
disconnection from any PDN.
All simultaneous active PDN connections of a UE that are associated with the same
APN are provided by the same PGW.
The first (and default) PDN connection is established as part of the initial UE attach
procedure. Additional PDN connections will be established via standalone PDN
Connectivity Request. All but the last PDN can be torn down via a PDN Disconnection
Request.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
607 / 652
8.2.3 EPS BEARERS AND QOS
An ePS bearer is characterized by the following parameters:
Allocation Retention Priority (ARP) used for the allocation and retention
mechanisms. ARP is typically used for the allocation of the bearer resources at
session setup or during handover. TS 23.401 v8.4.1, Annex E, Tables E.1 and
E.2 (only for the ARP priority mapping).
Guaranteed Bit Rate (GBR) applicable only to bearers that require guaranteed
Quality of Service (examples: voice or streaming). TS 23.401 v8.4.1 specifies
one-to-one mapping in either direction. (GBR is an attribute of the UMTS/GERAN
Conversational and Streaming classes, which map to/are mapped from the GBR
QCIs of EPS bearers. The UMTS/GERAN Interactive and Background Classes
map to/from the non-GBR EPS bearers, and none have a GBR attribute).
Maximum Bit Rate (MBR) help to set a limit on the data rate expected for the
related service. TS 23.401 v8.4.1 specifies one-to-one mapping for the
Conversational and Streaming Classes and the corresponding EPS GBR QCIs
specified in TS 23.401, Annex E.
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. TS 23.401 v8.4.1, Annex E specifies mapping between EPS QoS
values and the QoS values assigned to a PDP context in 3G world. The purpose
of the QCI, and associated parameters, is to provide a representation of QoS
parameters to be shared between core and access parts of the network. Each
QoS class is associated with the following parameters:
Bearer Type
L2 Packet Delay Budget
L2 Packet Loss Rate
Figure 8-93: Basic Default and Dedicated ePS Bearers for QoS
The MME supports the following for bearer management:
Maximum Number of APNs: 6
Maximum Number of PDN-GW IP address in HSS: 6
Maximum Number of bearers per UE: 11 (any combination of default and

dedicated bearers).
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
608 / 652
8.2.3.1
Allocation and Retention Priority (ARP)
Each QCI (1 9) can be provisioned with an ARP pre-emption capability and an ARP
pre-emption vulnerability value to be used during handover from a UTRAN/GERAN to
an LTE network. The ARP pre-emption capability defines whether or not a bearer with a
lower ARP priority level can be dropped to free up resources for this bearer. The ARP
pre-emption vulnerability defines whether or not this bearer can be dropped to free up
resources for a bearer with a higher ARP priority level.
The MME is also provisioned with a global parameter to define the largest ARP value
that can be assigned to high priority access users. For example, if the default value of 3
is used, all bearers with an ARP value of 1, 2, or 3 will be treated as high priority access
users.
Additionally, each ARP priority can be provisioned with a paging priority level.
The MME provides a separate Paging Priority level provisioning per ARP priority
level for UEs other than high priority access users. If provisioned, the MME
includes the paging priority in the S1AP Paging message.
Parameter
QCI
SAM Table Name
Allocation / Retention Priority (ARP)
OSS ID
ltemme.MMEARPAbs.aRPQCI
Range & Unit
Integer
[1..9]
Impact of Change
No service impact.
Value
Parameter
Capability
SAM Table Name
OSS ID
ltemme.MMEARPAbs.capability
Range & Unit
Boolean
Issue 11.01
Impact of Change
No service impact.
Value
LTE/DCL/APP/031094
Nokia 2016
609 / 652
Parameter
Vulnerability
SAM Table Name
OSS ID
ltemme.MMEARPAbs.vulnerability
Range & Unit
Boolean
Impact of Change
No service impact.
Value
Parameter
ARP High Priority Access Level
SAM Table Name
Global Parameters
OSS ID
gParmName
Range & Unit
String
ARP_High_Priority_Access_Level
gParmValue
Integer
[1..15]
Impact of Change
No service impact.
Value
Parameter
Paging Priority Level
SAM Table Name
Paging Priority Profile
OSS ID
ltemme.PagingPriProfile.PagingPriLevel
Range & Unit
Choice List
Issue 11.01
Impact of Change
No service impact.
Value
Operator Dependent; default = none
LTE/DCL/APP/031094
Nokia 2016
610 / 652
8.2.3.2
Operator Defined QoS Class Identifier (QCI)
In WM10.0.0 release and later release, specific operator QCIs values can be specified
beyond the range 1-9 in addition to the standardized QCI values (1 9) in order to
differentiate user for GBR and non-GBR traffic and allows classifying users between
Gold, Silver, Bronze and Standard enterprise priority classes.
Table of provisioned Operator Specific QCIs allows provisioning of up to 6 specific
Operator Defined QCI values using any value in the range of 128-254 through CLI or
SAM5620 GUI. It also includes support for:
-
Provisioning of default QoS parameters for any of the operator defined QCIs
Mapping of any of the Operator defined QCIs to 2G/2G
Mapping/override of QoS parameters for roamers
An operator defined QCI profile can be created and associated to a specific PLMN. If
there isn't an operator defined QCI profile or a specific operator defined QCI value isn't
provisioned, then existing QCI handling is used for the error treatment.
Parameter
Operator Defined QCI Profile Name
SAM Table Name
Operator Defined QCI Profile
OSS ID
ltemme.OprDefQciProfile.OprDefQciProfileName
Range & Unit
Choice List
String
Impact of Change
No service impact.
Value
Feature
m10202-02
Parameter
Operator Defined QCI
SAM Table Name
OSS ID
ltemme.OprDefQciProfile. OprDefQci
Range & Unit
Integer
[128..254]
Issue 11.01
Impact of Change
No service impact.
Value
Feature
m10202-02
LTE/DCL/APP/031094
Nokia 2016
611 / 652
Parameter
SAM Table Name
OSS ID
ltemme.OprDefQciProfile. OprDefQci
Range & Unit
Integer
[1..9]
Impact of Change
No service impact.
Value
Feature
m10202-02
Parameter
SAM Table Name
OSS ID
ltemme.OprDefQciProfile. PagingType
Range & Unit
Choice List
Basic
Basic_QCI_1
Basic_QCI_2
Basic_QCI_3
Basic_QCI_4
Basic_QCI_5
Basic_QCI_6
Basic_QCI_7
Basic_QCI_8
Basic_QCI_9
LPA
Restricted
S102
S102_CS
SGS_CS
SGS_PS
SxnRestoration
UserDefPaging1
UserDefPaging2
UserDefPaging3
UserDefPaging4
UserDefPaging5
UserDefPaging6
Issue 11.01
Impact of Change
No service impact.
Value
Feature
m10202-02
LTE/DCL/APP/031094
Nokia 2016
612 / 652
8.2.3.3
QOS Mapping
When a UE transitions from the LTE network to the UTRAN/GERAN network, each LTE
bearer is mapped to a PDP context and the LTE bearer QCI is mapped to a QoS class
that is assigned to the corresponding PDP context. Each traffic class (Conversational,
Streaming, Interactive, and Background) is provisioned with values for Delivery Order,
Maximum SDU Size, Residual Bit Error Ratio and Delivery of Erroneous SDUs to use in
the mapping.
The MBR assigned to an Interactive Class, or to a Background Class PDP Context has
no counterpart attribute in the non-GBR EPS bearer. Hence, when the UE moves from
the UTRAN/GERAN to LTE, the MBR values are saved for these QoS Classes to allow
their reassignment to an Interactive or Background Class context when the UE moves
back to the UTRAN/GERAN network. If the UE moves to the UTRAN/GERAN without
ever having first moved from those networks, the assignment algorithm specified in
Annex E of TS 23.401 v8.4.1 is used.
The Delivery Order parameter indicates whether or not the UMTS bearer must provide
in-sequence SDU delivery, where the default is to accept out-of-sequence SDUs.
The Max SDU Size parameter indicates the maximum SDU size for which the network
shall satisfy the negotiated QoS. Handling by the network of packets larger than
Maximum SDU size is implementation specific (e.g. they may be dropped or forwarded
with decreased QoS).
The Residual Bit Err Ratio parameter indicates the undetected bit error ratio in the
delivered SDUs. If no error detection is requested, Residual bit error ratio indicates the
bit error ratio in the delivered SDUs.
The Delivery of Err SDU parameter indicates whether SDUs detected as erroneous
shall be delivered or discarded. 'Yes' implies that error detection is employed and that
erroneous SDUs are delivered together with an error indication; 'No' implies that error
detection is employed and that erroneous SDUs are discarded; '-' implies that SDUs are
delivered without considering error detection.
Parameter
Traffic Class
SAM Table Name
QoS Mapping 2G/3G
OSS ID
ltemme.QoSMap2G3GAbs.trafficClass
Range & Unit
Choice List
Conversational
Streaming
Interactive
Background
Issue 11.01
Impact of Change
No service impact.
Value
LTE/DCL/APP/031094
Nokia 2016
613 / 652
Parameter
Delivery Order
SAM Table Name
QoS Mapping 2G/3G
OSS ID
ltemme.QoSMap2G3GAbs.deliveryOrder
Range & Unit
Boolean
Impact of Change
No service impact.
Value
Parameter
Maximum SDU Size
SAM Table Name
QoS Mapping 2G/3G
OSS ID
ltemme.QoSMap2G3GAbs.maxSduSize
Range & Unit
Integer
[10..15,000], increments of 10
Impact of Change
No service impact.
Value
Parameter
Residual Bit Error Ratio
SAM Table Name
QoS Mapping 2G/3G
OSS ID
ltemme.QoSMap2G3GAbs.resBer
Range & Unit
Choice list
10-2, 10-3, 10-4, 10-5, 10-6, 4 * 10-3, 5 * 10-2, 5 * 10-3, 6 * 10-8
Impact of Change
No service impact.
Value
Operator Dependent; default = 10-5
Parameter
Delivery of Error SDU
SAM Table Name
QoS Mapping 2G/3G
OSS ID
ltemme.QoSMap2G3GAbs.deliverErrSdu
Range & Unit
Choice list
No Detection, Yes (Deliver), No (Discard)
Issue 11.01
Impact of Change
No service impact.
Value
Operator Dependent; default = No Detection
LTE/DCL/APP/031094
Nokia 2016
614 / 652
8.2.3.4
Mapping EPS Bearer QOS to 3G UMTS PDP Context
QOS
Note: This section is only applicable in the event of inter-RAT mobility from LTE to 3G
UMTS or 2G GSM access networks.
In 3G UMTS access, 4 QoS classes are specified: conversational, streaming,
interactive, and background classes. Each QoS class has several associated attributes.
Interactive and Background QoS classes has MBR attribute, whereas QCI values of the
corresponding mapped EPS bearers have no associated MBR value. In the LTE world,
MBR attribute is assigned only to GBR bearers; however in the UMTS world, interactive
and background QoS class maps to a non-GBR bearer in the LTE world.
Qualities of Service parameters / attributes are specified in various 3GPP specifications
for different access technologies.
TS 23.107 provides QoS attributes that are used in R97/98 and R99 releases,
TS 23.203 table 6.1.7 specifies values used with each QCI that is assigned to
EPS bearer, and
TS 23.401 Annex E specifies mapping between EPS QoS values and the QoS
values assigned to a PDP context in 3G world.
The MME
Maps / translates each EPS bearer and the associated QoS values to the values
required to support an equivalent PDP context in the UTRAN/GERAN network
Maps EPS bearer ARP to pre-Rel-8 ARP as per the applicable TS.
Uses the subscribed APNAMBR (APN-Aggregate-Max-Bitrate ) to determine

MBR values to assign to interactive and background QoS classes for PDP
contexts when UE originates access in the LTE network and then transitions to
UMTS network since there are no pre-stored MBR values to use for assignment
to interactive and background QoS classes.
Maps between standardized value of EPS bearer parameter QCI and Pre-Rel-8
QoS parameter values as per the applicable TS.
Map EPS bearer parameters GBR and MBR of a GBR EPS bearer one-to-one
to/from pre-Rel-8 bearer parameters GBR and MBR of a PDP context associated
with traffic class conversational or streaming.
for default bearer procedure, uses and interprets subscribed QoS and requested
QoS values from HSS, and uses/interprets negotiated QoS values from Create
Session Response message.
For UE initiated dedicated bearer procedure, uses/interprets subscribed QoS

received from Create Bearer Response message, uses requested QoS values
from Bearer Resource Allocation/modification request message, and
uses/interprets negotiated QoS values from Create Bearer Response message.
For Network Initiated Dedicated bearer procedure, uses subscribed QoS values,
requested QoS values and Negotiated QoS values received from Create Bearer
Request message.
Upon identifying a change to UE-AMBR at the end of the TAU or HO procedure,

the MME validates if UE-AMBR has changed, and if it has, the MME initiate S1-
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
615 / 652
AP UE Context Modification procedure to signal a modified UE-AMBR towards
eNB.
The MME is provisioned with a high and medium priority value to use for ARP
translations, as follows:
Parameter
ArpHValue
SAM Table Name
Global Parameters
OSS ID
gParmName
String
ArpHValue
Range & Unit
gParmValue
Integer
[1..13]
Impact of Change
No service impact.
Value
Parameter
ArpMValue
SAM Table Name
Global Parameters
OSS ID
gParmName
String
ArpMValue
Range & Unit
gParmValue
Integer
[ARP High + 1..14]
Impact of Change
No service impact.
Value
Operator Dependent; default = ARP High +1
The MME is provisioned with a value to use to as a local UE-AMBR until the subscribed
value can be obtained from the HSS. A value of 0 indicates that the UE-AMBR should
be calculated using the algorithm: local APN-AMBR = MBR value of the subscribed
QoS profile.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
616 / 652
Parameter
Obtain UE-AMBR
SAM Table Name
Global Parameters
OSS ID
gParmName
String
Obtain_UE_AMBR
Range & Unit
gParmValue
Integer
[0..50000] Kbps
Impact of Change
No service impact.
Value
Operator Dependent; default = 0 (calculate)
The R99 QoS Mapping Method global parameter specify how the MME maps EPS to
R99 QoS across the Gn interface during a RAU or HO procedure. A value of Standard
indicates that the MME should perform the mapping as specified in Anned E of 3GPP
TS 23.401. A value of Custom 1 indicates a customer-specific QoS mapping.
Parameter
SAM Table Name
OSS ID
R99 QoS Mapping Method

Global Parameters
gParmName
String
R99_QoS_Mapping_Method
Range & Unit
gParmValue
Choice List
Standard
Custom 1
Impact of Change
No service impact.
Value
Operator Dependent; default = Standard
The global parameter Allow UE Initiated Bearer Resource Allocation Request

indicates whether or not a UE initiated bearer resource allocation request is allowed. If
the parameter is set to No, a UE initiated bearer resource allocation request is
rejected by the MME and the MME sends a bearer resource allocation reject message
with the ESM cause value #97 (Message type non-existent or not implemented).
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
617 / 652
Parameter
Allow UE Initiated Bearer Resource Allocation Request
SAM Table Name
Global Parameters
OSS ID
gParmName
String
Allow_UE_Initiated_Bearer_Resource_Allocation_Req
uest
Range & Unit
gParmValue
Boolean
Yes or No
Impact of Change
No service impact.
Value
8.2.4 MESSAGE
COLLISION
PROCEDURES
HANDLING
DURING
ESM
During the ESM procedures, the MME handles message collisions as follows:
While waiting for Bearer Setup Response from the eNodeB, if MME receives
another create dedicated bearer request, MME rejects the dedicated bearer
activation to the SGW with the cause value insufficient resources (#73).
If UE requested bearer resource release results in bearer deactivation and if

deactivation request is received in MME while bearer activation procedure for the
same bearer is in progress, deactivation procedure takes precedence. Activation
procedure is aborted by sending bearer resource modification reject message by
MME.
If bearer activation request is received after deactivation procedure has started,

however the activation procedure proceeds after deactivation procedure
completes. For Deactivation triggered by Detach, deactivation procedure always
takes precedence and activation procedure is aborted no matter its order by
sending bearer modification reject message.
If any collisions of EPS bearers context deactivation procedure and modification

procedure for the same bearer occurs in MME, Deactivation procedures take
precedence, Modification procedure is aborted by sending bearer modification
reject message.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
618 / 652
8.2.5 SGW AND PGW RESELECTION
Three ESM procedures support SGW and PGW re-selection when an SGW/PGW
returns a failure in the Create Session Response or when the MME times out waiting for
a Create Session Response. The 3 ESM procedures are:
Initial Attach
Standalone PDN Connectivity Request
SGW Relocation
8.2.5.1
Reselection Methods
The tables below summarize how the re-selection functions depending upon the
method selected.
NOTE: SGW timers are provisioned smaller than PGW timers; therefore, MME timed
out waiting for a Create Session Response scenario is treated as an SGW failure,
appearing as a case in which no response came back from SGW. For the scenario in
which SGW timed out waiting for Create Session Response from PGW, SGW reports it
as a Peer Not Responding failure.
Using Method 1, either another SGW or PGW is selected, or the request will be rejected
altogether.
Failure Scenario
Attach
Standalone PDN
Connectivity
SGW
Relocation
Request
TypeIE =
Handover
Request
TypeIE =
Other
Request
TypeIE =
Handover
Request
TypeIE =
Other
Request
TypeIE not
applicable
Timed out waiting for

CreateSessRsp
SGW
SGW
Reject
Reject
SGW
Cause value = 73
(no resource avail) &
source = SGW
SGW
SGW
Reject
Reject
SGW
Cause value = 94
(request reject) &
source = SGW
SGW
SGW
Reject
Reject
SGW
Cause value = 100

(remote peer not
responding)
SGW
PGW
Reject
PGW
SGW
Cause value = 64 &

source = PGW
PGW
Reject
PGW
Reject
Reject
Cause value = 73 &

source = PGW
PGW
PGW
PGW
PGW
Reject
Cause value = 94 &

source = PGW
Reject
PGW
Reject
PGW
Reject
Table 31: SGW/PGW Reselection Method 1

Using Method 2, either another (1 or 2) SGW or PGW is selected, or the request will be
rejected altogether.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
619 / 652
Attach
Standalone PDN
Connectivity
SGW Relocation
Timed out waiting for

CreateSessRsp
PGW & SGW pair
Reject
SGW
Cause value = 72
(system failure) &
source = SGW
PGW & SGW pair
Reject
SGW
Cause value = 73 (no

resource avail) &
source = SGW
PGW & SGW pair
Reject
SGW
Cause value = 78
(missing or unknown APN) &
source =SGW
PGW & SGW pair
Reject
Reject
Cause value = 94 (request

reject) & source = SGW
PGW & SGW pair
Reject
SGW
Cause value = 100

(remote peer not responding)
PGW & SGW pair
PGW
SGW
Cause value = 72 &

source = PGW
PGW & SGW pair
PGW
Reject
Cause value = 73 &

source = PGW
PGW & SGW pair
PGW
Reject
Cause value = 78 &

source = PGW
PGW & SGW pair
PGW
Reject
Cause value = 94 &

source = PGW
PGW & SGW pair
PGW
Reject
Failure Scenario
Table 32: SGW/PGW Reselection Method 2
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
620 / 652
8.2.5.1
Provisionable Depth of Retry for SGW/PGW Re-selection
As currently defined for mode1 selection, the MME generally makes the original Create
Session Request attempt and one additional attempt and rejects a subsequent Create
Session Requests after UE is attached.
The global parameter Depth of SGW PGW Retry extends SGW/PGW reselection
attempts after initial failure from one (1) to two (2) when there is no response to N3
number of Create Session Request re-transmissions during mode1 SGW/PGW reselection
The following global parameter is added:
Parameter
Depth of SGW PGW Retry
SAM Table Name
Global Parameters
OSS ID
gParmName
String
Depth of SGW PGW Retry
Range & Unit
gParmValue
Integer from 1 to 2
Issue 11.01
Impact of Change
No service impact.
Value
Feature
m10113-06
LTE/DCL/APP/031094
Nokia 2016
621 / 652
8.2.6 SINGLE RADIO VOICE CALL CONTINUITY
The Single Radio Voice Call Continuity (SRVCC) architecture supports voice call
continuity (session transfer) from IMS voice over packet-switched access to circuitswitched voice access for calls that are anchored in IMS when the UE is capable of
transmitting/receiving on only one of these access networks at a given time.
The Single Radio Voice Call Continuity (SRVCC) procedure supports:
Circuit-switched (CS)-only handover (HO) from E-UTRAN to UTRAN/GERAN. In

this scenario, voice bearers are handed-over to the CS network (via Sv interface
to MSC).
Circuit-switched + packet-switched (CS+PS) handover (HO) from E-UTRAN to

UTRAN/GERAN. In this scenario, voice bearers are handed-over to the CS
network (via Sv interface to MSC), and 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.
CSHO from eUTRAN to 1xRTT. Voice bearers are handed-over to the CS

network via the S102 interface.
The MME supports the following procedures (as specified in 3GPP TS 23.216):
E-UTRAN Attach procedure for SRVCC.
SR procedure for SRVCC.
SRVCC from E-UTRAN to GERAN without DTM support.
SRVCC from E-UTRAN to GERAN with DTM but without DTM HO support.
SRVCC from E-UTRAN to UTRAN without PS HO.
SRVCC from E-UTRAN to UTRAN with PSHO or GERAN with DTM HO.
8.2.6.1
SRVCC Call Flow CS-Only HO
SRVCC for CS-only HO from E-UTRAN to UTRAN/GERAN is performed as follows:
From the eNodeB, the MME receives the handover request with the indication
that this is for SRVCC handling.
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.
The MSC (Server enhanced for SRVCC) then initiates the session transfer
procedure to IMS and coordinates it with the CS HO procedure to the target
UTRAN/GERAN cell.
The MSC Server (enhanced for SRVCC) then sends PS-to-CS Response to the
MME, which includes the necessary CS HO command information (subsequently
forwarded from the MME to the eNodeB) for the UE to access the
UTRAN/GERAN cell.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
622 / 652
8.2.6.2
SRVCC Call Flow CS+PS HO
SRVCC for CS+PS HO from E-UTRAN to UTRAN/GERAN is performed as follows:
From the eNodeB, the MME receives the S1AP Handover Required request with
the indication that this is for SRVCC handling.
If the MME has SRVCC STN-SR information for this UE, the MME triggers the
SRVCC procedure with the target MSC via the Sv interface for voice bearer, and
initiates the packet bearer transfer with the SGSN via the Gn/S3 interface.
The MME coordinates the handling of both voice bearer and packet bearer
transfers to the appropriate entity (that is, MSC and SGSN).
The target SGSN sends a Forward Relocation Response and the MSC sends the
PS-to-CS Response to MME.
If the PS-to-CS response contains cause Request Accepted, then the MME
sends the S1AP_HANDOVER_COMMAND message to the eNodeB. Otherwise,
if the PS-to-CS response does not contain cause Request Accepted, then the
MME sends S1AP_HANDOVER_PREPARATION_FAILURE to the eNodeB.
Note: The packet bearer transfer portion of SRVCC does not determine the outcome of
the SRVCC procedure. The SRVCC outcome is determined by the outcome of voice
session only.
8.2.6.3
SRVCC Provisioned Parameters
Several parameters are used to define SRVCC behavior. The parameters are defined
via tables as indicated below. The tables provide default values for each of the
parameters, but they should be reviewed to determine whether or not the defaults
provide adequate performance. Updates should be made to the tables as required.
Parameter
SRVCC-Based PS to CS Handover
SAM Table Name
UE PLMN Services
OSS ID
ltemme.UEPLMNServices.sRVCC_PS_To_CS
ltemme.SVCAgreementProfile.sRVCC_PS_To_CS
Boolean
Range & Unit

Yes or No
Issue 11.01
Impact of Change
No service impact.
Value
LTE/DCL/APP/031094
Nokia 2016
623 / 652
Parameter
SRVCC PS to CS Complete
SAM Table Name
Timer
OSS ID
Range & Unit
timerName
Choice List
SRVCC_PS_to_CS_Complete
timerUnit
timerName)
msec
timerValue
Integer
[500..10000] msec
Impact of Change
No service impact.
Value
Parameter
SLR Sender During Handover
SAM Table Name
Global Parameters
OSS ID
Range & Unit
gParmName
String
SLR_Sender_During_Handover
gParmValue
Choice List
Target MME
Source MME
Issue 11.01
Impact of Change
No service impact.
Value
Operator Dependent; default = Target MME
LTE/DCL/APP/031094
Nokia 2016
624 / 652
8.2.7 SINGLE RADIO VOICE CALL CONTINUITY ACROSS S102
INTERFACE
MME provides supports of Single Radio Voice Call Continuity (SRVCC) across S102
interface from VoIP to CS voice access for calls that are anchored in IMS. The MME
and the 1xCS IWS are enhanced to support the S102 interface, when the UE is capable
of transmitting and receiving on only one radio access technology at a given time.
8.2.7.1
Reference architecture service for E-UTRAN to
3GPP2 1xCS SRVCC
The following figure shows the reference architecture and major architectural
components that collectively support the Single Radio Voice Call Continuity Service
(SRVCC) for E-UTRAN to 3GPP2 1xCS SRVCC.
1xCS
SRVCC
UE
1xRTT CS
Access
A1
1xRTT
MSC
A1
IMS
1xCS IWS
S102
MME
S11
S1-MME
1xCS
SRVCC
UE
E-UTRAN
Serving/PDN
GW
SGi
S1-U
Bearer before HO
Bearer after HO
SIP signalling
Tunnelled 1xRTT messages
Figure 8-94 reference architecture SRVCC

Initially, the UE has established IMS PS voice session(s) through the EPC.
When the UE moves outside the E-UTRAN coverage area and the target cell does not
support IMS PS voice, the serving eNB triggers a SRVCC handover to handover the
voice session and possibly the non-voice sessions to the target cell by sending the
S1AP Handover Required message to the MME.
The MME interact with the IWS over the S102 interface to handover the IMS anchored
voice sessions to the CS domain in 1xRTT network. The call transfer between the two
technologies is triggered when SR-VCC capable UE measures the signal strength,
based on defined threshold, and sends measurement reports to the eNB.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
625 / 652
8.2.7.2
eUtran-to-voice- service continuity procedure
As it is shown in the High level picture of SR-VCC functionality, the SR-VCC impacts
the device, LTE and CDMA 1x access, IMS and the application servers
SRVCC is triggered when the UE, while having an ongoing IMS VoIP session, moves
out of the LTE coverage, and the eNB determines that the target network does not
support IMS based VoIP. If the UE has concurrent non-voice PS sessions while in the
LTE network, these non-voice PS sessions may or may be handed over to the target
network during the SRVCC handover procedure, depending on the UE and target
network capabilities.
The MME interacts with IWS over the S102 interface to complete the SRVCC
procedure.
This feature covers SRVCC from E-UTRAN to 1xRTT. For SRVCC from E-UTRAN to
1xRTT, the MME first receives the SRVCC-HO indicator request from eNB with the
indication that this is for SRVCC handling. The MME then triggers the SRVCC
procedure with the IWS via the S102 reference point if the MME has SRVCC STN-SR
information for this UE.
SRVCC from UTRAN (HSPA) to UTRAN/GERAN nor SRVCC from EUTRAN to
UTRAN/GERAN are not supported.
E-UTRAN attach or emergency attach procedure for 3GPP2 SRVCC UE is performed
as defined in TS 23.401with the following additions:
SRVCC UE includes the SRVCC capability indication as part of the "UE Network
Capability" in the Attach Request message. MME stores this information for SRVCC
operation.
SRVCC UE capable for IMS emergency calls includes the SRVCC capability indication
as part of the UE network capability in the Emergency Attach Request message. MME
stores this information for emergency SRVCC operation.
MME includes a "SRVCC operation possible" indication in the S1 AP Initial Context
Setup Request, meaning that both UE and MME are SRVCC-capable.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
626 / 652
The Figure 8-77 shows the high-level call flow for the eUTRAN-to-1x voice service
continuity procedure:
1xCS
SRVCC
UE
eNB
MME
S-GW /
PDN GW
1xRTT
MSC
1xCS
IWS
1xRTT
CS
access
1. Ongoing VoIP session over the IMS access leg established over E-UTRA access
2.Measurement Reports
3. Handover decision
4. HO
. - from EUTRA preparation
request (3G1x Parameters)
5. UL Handover prep. transfer
(MEID, 1x Origination)
6. UL S1 cdma2000 tunnelling
(MEID, RAND, 1x Origination) 7. S102 Direct Transfer (1x Air
Interface Signalling (Origination))
9. S102 Direct Transfer (1x Air Interface 8. 1x traffic assignment/handoff initiation
Signalling (Handoff Direction))
10. DL cdma2000 tunnelling
(Handoff Direction)
11. Mobility from EUTRA
command (Handoff Direction)
12. 1x radio interface procedures to acquire a traffic channel
13. 1x handoff completion message
14. 1x handoff done
15. Ongoing voice call over the CS access leg established over 1xRTT access
16. S1 UE Context
Release Request
17. Suspend Request/Ack
18. S1 UE Context Release
19. Subscriber Location Report
GMLC
Figure 8-95 : LTE VoIP-to-1x CS voice service continuity
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
627 / 652
The parameter S102 1x RTT Allowed controls activation of the SRVCC across S102
interface:
Parameter
SAM Table Name
S102 1x RTT Allowed

Profile
OSS ID
ltemme. SVCAgreementProfile. S1021xRTTAllowed
Range & Unit
Boolean
Yes or No
Impact of Change
No service impact.
Value
Operator Dependent; default = false
Feature
m20102-01
The guard timer SRVCC to 1x HO Preparation is started when S1 UL CDMA2000

Tunneling with HO Required IE is received. The timer SRVCC to 1x HO Preparation is
stopped when S102 signaling with HO status IE is received.
Parameter
SRVCC to 1x HO Preparation
SAM Table Name
Timer
OSS ID
Range & Unit
timerValue
Integer
1..5000 ms
Issue 11.01
Impact of Change
No service impact.
Value
Operator Dependent; default = 6 seconds
Feature
m20102-01
LTE/DCL/APP/031094
Nokia 2016
628 / 652
A new provisianable guard timer SRVCC to 1x HO Preparation is started when S102
signaling with HO status IE (SUCCESS) is received and stopped when S1 UE Context
Release Request with cause 1xRTT cell redirection is received.
The Default value is set to 12000 ms.
Parameter
SRVCC to 1x HO Complete
SAM Table Name
Timer
OSS ID
Range & Unit
timerValue
Integer
1..12000 ms
Issue 11.01
Impact of Change
No service impact.
Value
Operator Dependent; default = 12000 ms
Feature
m20102-01
LTE/DCL/APP/031094
Nokia 2016
629 / 652
8.2.8 SRVCC EMERGENCY CALL HANDLING
When UE is attached with only emergency bearer and if MME has both IMSI and IMEI
for the UE, MME relay/sends IMEI to IWS across S102 interface via A21 signaling
message instead of IMSI. A21 signaling message to the IWS can only contain one type
of mobile identity.
MME upon receiving IMEI from IWS internally map IMEI to IMSI for routing.
In this scenario when MME has both IMSI and IMEI, MME send IMEI rather than IMSI.
MME use IMEI as the mobile identity if the IWS need to send a message to the UE.
The following text is copies from the CR 0403:
When UE having on-going emergency IMS session moves out from LTE to 1xRTT area,
the 1xSRVCC procedure can be used to support voice continuity. Since tracking of user
location (or position) is vital for emergency services, source MME shall be able to
provide the location report to GMLC, upon completing the 1xSRVCC procedure for the
emergency session. As the network entity pointed out by the MSC ID would be IxRTT
IWS, not the 1xRTT MSC which will serve the UE after the SRVCC procedure in the
real deployment, the provision of the MSC ID to the GMLC may not appropriate for the
location continuity.
The MME includes the 1xRTT reference cell ID in SLG Location Report Request (LRR)
message to the GMLC for emergency 1xRTT SRVCC call if the global parameter S102
1xRTT RCID in SLR is set to True. MME sets the optional IE Reference Cell ID IE of
the LRR message to the CDMA 2000 sector ID received in in S1AP CDMA2000 S1
UPLINK TUNNELING message. If the global parameter S102 1xRTT RCID in SLR is
set to False, the MME doe not includes the 1xRTT-RCID IE in LRR message to GMLC,
but instead the MME sets the "Target Serving Node Identity" IE of the LRR message to
the provisioned ISDN for emergency 1xRTT SRVCC call
Parameter
S102 1xRTT RCID in SLR
SAM Table Name
Global Parameters
OSS ID
Range & Unit
Boolean
Yes or No
Issue 11.01
Impact of Change
No service impact.
Value
Feature
m10099-14
LTE/DCL/APP/031094
Nokia 2016
630 / 652
8.2.9 SESSION RESTORATION SERVER (SRS)
Actually MME failure results in subscribers not able to access the network or receive
IMS terminating calls until reattaching to the network. This reattach adds extra
signaling over radio network and results in attach storms. WM7.1.0 introduce an
external Session Restoration Server (SRS) to store necessary UE context data required
for restoring UE sessions without reattach.
WMM 9471 Session Restoration Server (SRS) improves MME service resilience by
implementing enhanced restoration procedures which use UE restoration data stored
on SRS.
The following parameters are configured on the MME client:
Interface profile for the RS10 interface, including the TCP interface port
(default=14210).
Restoration Access: Name of SRS and IPv6 addresses of SRS
Parameter
Primary Access
SAM Table Name
Restoration Access table
OSS ID
ltemme.RestorationAcc.sRSPrimaryAcc
Range & Unit
Boolean
Yes or No
Issue 11.01
Impact of
Change
No service impact.
Value
Operator Dependent; default = True
Feature
m10538
Parameter
Remote Node IP Address
SAM Table Name
OSS ID
ltemme.RestorationAcc. rmtNdIP
Range & Unit
SRS IP@
Impact of Change
No service impact.
Value
Operator Dependent; default = 0.0.0.
Feature
m10538
LTE/DCL/APP/031094
Nokia 2016
631 / 652
Parameter
Remote Node Name
SAM Table Name
OSS ID
ltemme.RestorationAcc. rmtNdName
Range & Unit
String
Impact of Change
No service impact.
Value
Operator Dependent;
Feature
m10538
Restoration APN List :

This parameter allows operators to restrict bearer context update to the SRS for
certain critical APNs only. The MME allows provisioning of up to 3 such APNs.
The MME uses this provisioned list to decide if an SRS update is sent at the
end of a procedure.
Parameter
Restoration APN List
SAM Table Name
OSS ID
ltemme.RestorationAcc. rmtNdName
Range & Unit
String
Impact of
Change
No service impact.
Value
Operator Dependent;
Feature
m10538
Support Session Restoration activation flag :

If enabled, the MME sends restoration data to its SRS.
The MME uses the value of this field to populate S11 Echo Request/Response
to indicate MME support of restoration procedures and to determine how to
process the Service Request and DDN with IMSI.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
632 / 652
Parameter
Support Session Restoration
SAM Table Name
Global Parameters
OSS ID
Range & Unit
Boolean
Yes or No
Impact of Change
No service impact.
Value
Feature
m10538
SRS Response Timer:

This timer specifies how long the MME handling recovery should wait for an
SRS response with RUC data for a UE.
The default is 6 seconds.
Parameter
SRS Response Timer
SAM Table Name
Timer
OSS ID
Range & Unit
timerValue
Integer
[1..30 sec
Impact of Change
No service impact.
Value
Operator Dependent; default = 6 seconds
Feature
m10538
Paging Type for Network Initiated Restoration :

This controls the number of page attempts triggered by the reception of DDN
message with IMSI to one attempt. This parameter also limits paging methods
are allowed for restoration paging (for example, the simple methods like Last
Seen eNB and Last Seen TA). 8.1.31.8
WM10.0.0 release provides multiple UE restoration enhancements:
Issue 11.01
MME send bearer context of all the PDN connections of UE including the
dedicated bearers to the SRS so that all the PDN connections and their
dedicated bearers are restored if the global parameter All APNs is set to True,
when a UE is restored due to MME restart or failure.
Restoration of the UE SGs association: MME sends SRS Restoration Updates

messages with SGs IEs if the global parameter SGs is set to True
Store adequate SRVCC information on the SRS : if the global parameter

SRVCC is set to True, the new SRVCC IEs are included in the SRS
Restoration Update message sent by the MME so that SRVCC HO are
supported for a restored UE.
Store adequate S102 information so that S102 CSFB and SRVCC HO for
1xRTT voice are restored: if the global parameter S102 is set to True.
LTE/DCL/APP/031094
Nokia 2016
633 / 652
8.2.10 MACHINE-TYPE COMMUNICATIONS (MTC)
A MTC Device is a UE equipped for Machine Type Communications (machines to
machine communication (M2M)). LTE MTC enables a new, simpler M2M device
capability. Some example of machine-type communication applications are listed in
Table 33 .
Service Area
MTC applications
Security
Tracking & Tracing

Payment
Health
Remote
Maintenance/Control
Metering
Consumer Devices
Surveillance systems, Backup for landline

Control of physical access (e.g. to buildings)
Car/driver security
Fleet Management, Order Management, Pay as you drive,
Asset Tracking, Navigation, Traffic information, Road tolling
Road traffic optimization/steering
Point of sales, Vending machines, Gaming machines
Monitoring vital signs, Supporting the aged or handicapped
Web Access Telemedicine points, Remote diagnostics
Sensors, Lighting, Pumps, Valves, Elevator control,
Vending machine control, Vehicle diagnostics
Power, Gas, Water, Heating, Smart Grid control, Industrial
metering
Digital photo frame, Digital camera, eBook
Table 33 Machine-type-communication Applications

This list is not exhaustive and is intended to be indicative of the scope of machine-type
communication applications.
Readers are suggested to read 3GPP 22.368 and subclause 4.3.17 of 3GPP TS 23.401
to get familiar with UE and network changes to support MTC
8.2.10.1
UE LPA (Low priority access)
MME identifies the UE Low Priority Access devices thanks to the device properties IE
includes in the following NAS messages:
ATTACH REQUEST
EXTENDED SERVICE REQUEST
TRACKING AREA UPDATE REQUEST
BEARER RESOURCE ALLOCATION REQUEST
BEARER RESOURCE MODIFICATION REQUEST
PDN CONNECTIVITY REQUEST
A UE is marked as a LPA UE if the Device Properties IE of the Attach Request, TAU

Request or ESR message is set to MS is configured for NAS signaling low priority
while non-LPA UE is having Device Properties IE set to 'MS is not configured for NAS
signaling low priority' or not having Device Properties IE
MME decide whether to accept UE LPA request based on MME overload control and
also based on APN congestion control. The MME stores the device properties IE
values received in the MM requests in the UE context and also the store device
properties IE received in the SM requests in the default bearer context of a PDN
connection.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
634 / 652
The UE low priority access indication is sent over S11 to the GWs by including the
GTPv2C IE Signaling Priority Indication in the following messages if included by the
UE in the PDN Connectivity Request message:
S11 Create Session Request,
S11 Bearer Resource Command,
S10/S3 Forward Relocation Request (The Signaling Priority Indication IE is

included in the PDN Connection Type IE) and
S10/S3 Context Response (The Signaling Priority Indication IE is included in

the PDN Connection IE).
The following figure shows how the low priority access knowledge is passed from UE to
the eNB and core network:
MME
eNB
UE
SGW/
PGW
1. RRC Connection Setup

Establishment Cause = Delay
Tolerant Access in RRC
Connection Request
2. S1AP INITIAL UE MESSAGE

RRC Establishment Cause =
Delay Tolerant Access
3. NAS Attach/TAU/ESR
Device Properties IE = "MS is configured for NAS signalling
low priority
The RRC Establishment Cause and the Device properties IE in steps 2
and 3 may be used by the MME to restrict traffic from LPA (Low Priority
Access) UE in case of MME overload.
2. PDN CONNECTION REQUEST

Device Properties IE = "MS is configured for NAS signalling
low priority
4. Create Session
Signaling Priority Indication
IE = NAS signaling for low
access priority
MME shall include the Signaing Priority Indication IE in the CS Request

message if the Device properties IE is included in the PDN
CONNECTIVITY REQUEST. The Device properties IE is used by the MME
to reduce SM traffic for APN congestion control or for PGW overload
control.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
635 / 652
8.2.10.2
Dual Priority UE handling:
UE low access priority setting was introduced in 3GPP standards to handle congestion
and overload control when millions of M2M devices are trying to connect to the network.
However, there may be situations in which a LPA UE need to access high priority
services like voice, sending mission critical data, etc. A LPA UE that can override the
default low priority setting on rare occasions are called Dual Priority (DP) UE. The
following describes how MME handles DP UEs that can override LPA setting. The MME
has no knowledge that a UE is configured to be a DP UE other than the LPA indication
in Device Properties IE of the NAS messages. A DP UE may override its default LPA
setting in the following scenarios by setting the Device Properties IE to MS is not
configured for NAS signaling low priority or just omitting the Device Properties IE :
Attach Request,
TAU Request,
ESR,
Bearer Resource Allocation Request,
Bearer Modification request and
PDN Connectivity Request.
MME uses the Device Properties IE received first in congestion and overload control.
if the Device Properties IE is included and its set to MS is configured for NAS signaling
low priority then the device is treated as a LPA device and overload control specific to
the LPA is applied.
If the IE is missing or it is set to MS is not configured for NAS signaling low priority
then the UE is treated as a non-LPA UE irrespective of the UE PDN connections are
LPA or non-LPA.
A LPA UE can attach as a LPA UE but it can override its LPA setting by not including
Device Properties IE or setting the IE to MS is not configured for NAS signaling low
priority.
A UE is marked as a LPA UE if the Device Properties IE of the Attach Request, TAU
Request or ESR message is set to MS is configured for NAS signaling low priority.
This marking is used for counting number of registered LPA UEs.
Note that marking a UE as LPA UE is different from providing LPA treatment. However,
selection of MSC/VLR and sending of LPA UE context to SRS will be based on the
setting of the Device Properties IE at the time of registration:
Attach Request,
Inter-MME TAU,
IRAT TAU and
ESR when MME has no UE context (This may occur due to MME
failure/restart).
If the Device Properties IE is set to MS is configured for NAS signaling low priority at
the registration time then the MME doesnt send the context of a UE marked as a LPA
UE to SRS irrespective change of LPA status at a later time or LPA treatment.
MME enables LPA treatment for a UE only if all bearers of the UE are LPA.
MME treatment of LPA UE consists of the following items:
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
636 / 652
Use of T3412 extended timer and mobile reachable timer.
Use of provisioned LPA paging policy for paging that may triggered by SGW,
MSC/VLR, GMLC or HSS.
DDN throttling.
If any bearer is non-LPA, then UE will be treated as a normal UE when non-DDN

paging, during TAU processing and for DDN throttling.
The global parameter Low Priorioty Access enabled/disabled MME LPA treatment
globally but LPA can be set in SVCAgreementProfile at IMSIRange level (UE PLMN
and Served PLMN Service Agreement Profile); there is the possibility that LPA access
is enabled in the TAI where a UE attaches, and then UE moves to a TAI where LPA
access is disabled
Parameter
Low Priorioty Access
SAM Table Name
Global Parameters
OSS ID
Issue 11.01
Range & Unit
gParmName
Boolean
Impact of Change
No service impact.
Value
Feature
m10115-01
Parameter
SAM Table Name
OSS ID
ltemme.SVCAgreementProfile.LowPriorityAccess
Range & Unit
gParmName
Boolean
Impact of Change
No service impact.
Value
Feature
m10115-01
LTE/DCL/APP/031094
Nokia 2016
637 / 652
9 ANNEXES
9.1 Abbreviations
Abbreviations that are specific to this MME-LPUG are provided here.
Abbreviations that are common to multiple LPUG volumes are provided in Volume 1 of
the eNB LPUG [R30].
3GPP
ACK
AIR
ALU
AMBR
APN
ARP
CPI
CSFB
CSG
DL
DNS
EEA
EIA
EIR
EMM
EMS
eNB
ePC
EPS
E-RAB
ESM
E-SMLC
E-UTRAN
FQDN
GBR
GERAN
GGSN
GMLC
GTP-C V2
GUI
GUTI
HSS
IDR
IMEI
IMSI
IP
LAI
LBI
LCP
LPA
LAPI
LPI
Message
LPUG
LTE
Issue 11.01
Third Generation Partnership Project

Acknowledgement
Authentication Information Request
Nokia
Aggregate Maximum Bit Rate
Access Point Name
Allocation and Retention Priority
Component Performance Indicator
Circuit Switched Fallback
Closed Subscriber Group
Downlink
Domain Name Server
EPS Encryption Algorithms
EPS Integrity Algorithms
Equipment Identity Register
EPS Mobility Management
Element Management System
E-UTRAN NodeB
Evolved Packet Core
Evolved Packet System
E-UTRAN Radio Access Bearer
Evolved Session Management
EPC Serving Mobile Location Center
Evolved Universal Terrestrial Radio Access Network
Fully Qualified Domain Name
Guaranteed Bit Rate
GSM/EDGE Radio Access Network
Gateway GPRS Support Node
Gateway Mobile Location Center
GPRS Tunneling Protocol Control Plane, Version 2
Graphical User Interface
Globally Unique Temporary Identity
Home Subscriber Server
Identity Request (procedure)
International Mobile Equipment Identifier
Internet Mobile Station Identifier
Internet Protocol
Location Area Identifier
Linked EPS Bearer Identity
Linux Control Platform (5400 LCP)
Low Priority Access LPA UE
Low Access Priority Indicator
Low Priority Indicator NAS Message ess Priority Indication GTP
LTE Parameters User Guide
Long Term Evolution
LTE/DCL/APP/031094
Nokia 2016
638 / 652
MAF
MCC
MI
MIF
MM
MME
MNC
MTC
MO
MSC
NACK
NAS
OAM
ODB
OFDM
OFDMA
PDN
PDU
PGW
PLMN
PMIP
QCI
QoS
RAN
RAT
RAU
RB
RFC
RLC
RRC
RTO
S1-AP
SAE
SAM
SC-FDMA
SCTP
SDU
SGSN
SGW
SMC
S-NAPTR
SRNS
TA
TAC
TAI
TAU
TCP
UDP
UE
UL
UMTS
UTRAN
VLR
Issue 11.01
MME Application Function

Mobile Country Code
Maintenance Interface
MME Interface Function
Mobility Management
Mobility Management Element
Mobile Network Code
Machine Time Communication
Managed Object
Mobile Switching Center
Negative Acknowledgement
Non-Access Stratum
Operations, Administration, and Maintenance
Operator Determined Barring
Orthogonal Frequency Division Multiplexing
Orthogonal Frequency Division Multiple Access
Packet Data Network
Protocol Data Unit
PDN Gateway
Proxy Mobile IP
QoS Class Identifier
Quality of Service
Radio Access Network
Radio Access Technology
Routing Area Update
Radio Bearer
Request for Comments
Radio Link Control
Radio Resource Control
Retransmission Timeout
S1 Application Protocol
System Architecture Evolution
Service Aware Manager (5620 SAM)
Single Carrier Frequency Division Multiple Access
Stream Control Transmission Protocol
Service Data Unit
Serving GPRS Support Node
Serving Gateway (7750 SGW)
Security Mode Command
Straightforward - Naming Authority Pointer
Serving Radio Network Subsystem
Tracking Area
Tracking Area Code
Tracking Area Identifier
Tracking Area Update
Transmission Control Protocol
User Datagram Protocol
User Equipment
Uplink
Universal Mobile Telecommunication System
Universal Terrestrial Radio Access Network
Visitor Location Register
LTE/DCL/APP/031094
Nokia 2016
639 / 652
9.2 Definitions
DIAMETER: An upgrade to the RADIUS (Remote Authentication Dial In User Service)
protocol, used to provide centralized AAA management.
X2 (X2-C and X2-U): The key difference between the X2 interface protocol stacks used
for the user plane and the control plane is the use of SCTP for control plane
transmissions between eNBs. SCTP enables reliable delivery of control information.
UDP is used for data forwarding in the user plane.
X2-based handover: The eNBs use X2 messages to directly exchange handover
messages between source and target eNB. The MMEs role is to redirect the GTP-U
tunnel from the SGW to the target eNB.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
640 / 652
9.3 MI-Agent GUI Examples and Indicator Legend
9.3.1 MI-AGENT SCREEN EXAMPLES
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.
Figure 9-1: MI-Agent Screen Layout

In the Management Interface tree, select Network Maps -> <System Name>. 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.
Figure 9-2: MI-Agent Web Network Maps
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
641 / 652
In the Management Interface tree, select Network Maps -> <System Name> ->
<Managed Element Name> -> <Shelf #>. The shelf view shows the all of the
components in the shelf and their status. Note that this screen shot was taken from a
simulator and includes only the OAM Server cards. Normally all of the cards are shown.
Figure 9-3: MI-Agent Web Shelf View

In the Management Interface tree, select Network Maps -> System Name -> Managed
Element Name -> Shelf #-> Node name. 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 ports
are either not functioning or are not used.
Figure 9-4: MI-Agent Card-host View
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
642 / 652
In the Management Interface tree, select Network Maps -> <System Name> -> <Shelf
#>-> Service Members. This menu provides IP addresses and status of services.
Hosts have both fixed and floating IPs when active. MI has an external fixed IP in order
to log in. Internal IP addresses are used by internal services, like log file forwarding.
There is one floating IP for each external connection as part of the standard
configuration (some may not be used).
Figure 9-5: MI-Agent Service Members Menu

In the Management Interface tree, select Fault Management -> Alarms to see 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. In the Management Interface tree, select
Fault Management -> Alarms to view alarms, severity, probable cause, impacted
components. Alarms can be filtered according to various criteria (severity, component,
etc.).
Figure 9-6: MI-Agent Fault Management
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
643 / 652
In the Management Interface tree, select Configuration Management -> Network
Interface. The MME communicates with other network elements in the network using
interface IP addresses.
Figure 9-7: MI-Agent IP Addresses

The Configuration Management tree is mainly used to schedule backups and perform
manual backups (by selecting Configuration Management -> Backup Management).
Other Configuration Management selections are described in the picture.
Figure 9-8: MI-Agent Configuration Management
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
644 / 652
Selecting Performance Management -> Polled Data allows you to view statistical
information about hosts. You can select objects to poll, set thresholds, and view polled
data reports. Selecting Performance Management -> XML Report Scheduling allows
you to schedule regular performance measurements (traffic, SNMP, and TL1) to be
collected at specified intervals. Selecting Performance Management -> XML Reports
allows you to view XML files that contain performance data collected from different subnetwork elements.
Figure 9-9: MI-Agent Performance Management

Selecting Security Management -> Audit Trail allows you to view security logs and
audit trail Logs. Selecting
Security Management -> Alarm Control allows you to specify security alarm triggers.
Figure 9-10: MI-Agent Security Management
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
645 / 652
Selecting Tools -> Managed Objects allows you to view details about managed
objects. Selecting Tools -> SNMP Tools allows you to load and view the system
Management Information Bases (MIBs), set up the SNMP interface the Northbound
interface, and set up SNMPv3 security (normally performed by a security administrator)
Figure 9-11: MI-Agent Tools Tree

Selecting Tools from the MI-Agent menu bar results in a drop-down menu of options
that allows you to perform and track a global discovery, view your permission level,
change runtime defaults and parameters, and change your password.
Figure 9-12: MI-Agent Tools Menu
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
646 / 652
Selecting Help from the MI-Agent menu bar results in a drop-down menu of options that
allows you to view online customer documentation.
Figure 9-13: MI-Agent Help Menu
9.3.2 STATE/STATUS AND ALARM INDICATORS ON THE MIAGENT

This topic describes the state or status indicators and alarms that users can encounter
on MI-Agent screens. All SNEs use the X.731 standard to represent the state or status.
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
647 / 652
9.3.2.1
State or Status Indicators
On various MI-Agent screens, users can view state or status indicators that reflect the
current state of network elements.
Icon
Tooltip
Condition causing icon
Unknown
When the unknown status is set.
Unequipped
When the notInstalled bit (Availability status) is set.
Initializing
When the isInitializing (Procedural status) bit is set.
Growth
When the isSuspended (Control status) and the

isOffline (Availability status) bits are set, and the
Usage state is idle.
In Test
When the inTest (Availability status) bit is set.
Inhibited
When the isOffline (Availability status) bits are set

and the Usage state is set to Active.
Disabled and Failed

Disabled - swversion
Disabled - swversion and Locked
Disabled and Locked
When the Operational state is set to Disabled and

the Administrative state is set to Locked.
Disabled with Dependency
When the Operational state is set to Disabled and

the isDependency (Availability status) bits are set.
Disabled
When the Operational state is set to Disabled.
Overloaded
When the isDegraded (Availability status) bit is set

and the Usage state is set to Busy.
Degraded
When the isDegraded (Availability status) bit is set.
Standby
If the Standby status is set to EITHER Hot Standby

or Cold Standby.
Standby and Cold

Standby Cold and Locked
Standby and Hot
Standby Hot and Locked
Enabled
When the Operational state is set to Enabled.
Enabled and Locked
When the Operational state is set to Enabled and the

Administrative state is set to Locked.
X731 state and status not supported
When the Operational state is set to Not Relevant.
Invalid Combination of State and

Status
When none of the above conditions are true.
Table 34: MI-Agent State/Status Indicators
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
648 / 652
9.3.2.2
Alarm Indicators
The following table shows the alarms that are displayed when a corresponding fault
condition exists:
Icon
Color of icon
Condition
Definition
Red
Critical
This level indicates that a service affecting

condition has occurred that requires an
immediate corrective action.
Yellow
Major
This level indicates that a service affecting

condition has developed that requires an urgent
corrective action.
Gray
Minor
This level indicates the existence of a nonservice affecting fault condition; corrective
action should be taken in order to prevent a
more serious (for example, service affecting)
fault.
Light Blue
Indeterminate
This level indicates that the severity level

currently cannot be determined.
Warning
This level indicates the detection of a potential

or impending service-affecting fault, before any
significant effects have been felt. Action should
be taken to further diagnose (if necessary) and
correct the problem in order to prevent it from
becoming a more serious service-affecting fault.
Dark Blue
Table 35: MI-Agent Alarm Indicators
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
649 / 652
9.4 Parameter Changes
9.4.1 PARAMETER UPDATES FOR WM10.0.0
The following sections contain an exhaustive list of parameters that have changed
from WM9.1.0 to WM10.0.0:
9.4.1.1
New Parameters in Release WM10.0.0
The following table lists the parameters that are new in the WM10.0.0 release.
(WM10.0.0 parameters that are not in WM9.1.0)
Parameter
SAM Table Name
Feature ID
Context Request Due to CSFB
Timer
m10099-14
Global Parameter
m10099-14
PUR-Flags AVP
Global Parameter
m10099-14
S102 1xRTT RCID in SLR
Global Parameter
m10099-14
UE Reach T-ADS in Supported Features
Global Parameter
m10099-14
Bandwidth Roundup
Global Parameter
m10099-14
2G3G Target Access Restricted by Node
Access Restriction To
LTE Target Access Restricted by Node
NAS Cause Mapping
m10099-14
Profile
NOA User Unknown NAS Cause Code
Detach Behavior Mapping
NOA User Unknown Detach Type
Profile Name
m10099-14
Mobile Reachable LPA
Timer
m10115-01
T3412 Extended for LPA UE
Timer
m10115-01
T3396 Max
Timer
m10115-01
T3396 Min
Timer
m10115-01
Low Priority Access
Global Parameter
m10115-01
ARP Low Access Priority Level
Global Parameter
m10115-01
Low Priority Traffic DDN Throttling
Global Parameter
m10115-01
MSC VLR Reselection
Global Parameter
m10115-01
UE Radio Capability for Paging
Paging Policy
m10115-01
LPA SMS Only UE
MSC Server
m10115-01
Low Priority Access
SVC Agreement Profile
Restrict S10 Links to Neighbor MME
Global Parameter
m10533-01
All APNS
Global Parameter
m10538-22
NOA User Unknown Notify Idel UE

NOA User Unknown Send NAS Cause Code
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
650 / 652
Parameter
SAM Table Name
Feature ID
SGs
Global Parameter
m10538-22
S102
Global Parameter
m10538-22
SRVCC
Global Parameter
m10538-22
Redirection Command Rate
Global Parameter
m10538-22
PS CS Coordination
Global Parameter
m10902-03
SGSN Global Core Network ID
MME PLMN
m10902-03
Stop Warning Indication
Global Parameter
m11005-09
Write Replace Warning Indication
Global Parameter
m11005-09
PWS Restart Procedure
Global Parameter
m11005-09
Overload Retry not Allowed to Any
Issue 11.01
Diameter code to NAS

cause code profile ID
m11316-03
Location Update Attempts
Global Parameter
m10408-01
Short Data Service
IMSI Range Services
m10408-01
SGs Lite Detach Indication Ack
Timer
m10408-01
SGs Lite Location Update Ack
Timer
m10408-01
SGs Lite Uplink Data Ack
Timer
m10408-01
GWTS Tcp Link Failure Declaration
Timer
m10408-01
GW-TS Name
GW-TS
m10408-01
GW-TS ID
GW-TS
m10408-01
Minimum TCP Connections
GW-TS
m10408-01
Preference
GW-TS
m10408-01
Power Savings Mode
Global Parameter
m10923-01
m10923-01
Power Savings Mode T3412 Timer Unit
m10923-01
m10923-01
m10923-01
m10923-01
LTE/DCL/APP/031094
Nokia 2016
651 / 652
9.4.1.2
WM9.1.0 Parameters that are obsolete in WM10.0.0
Parameter
SAM Table Name
9.4.1.3
WM9.1.0 tables and Parameters with New label or
Values in WM10.0.0
Parameter
SAM Table Name
END OF VOLUME
Issue 11.01
LTE/DCL/APP/031094
Nokia 2016
652 / 652

Codigos Convolucionales-Carlos Sanchez

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Codigos Convolucionales-Carlos Sanchez

Загружено:

Авторское право:

Доступные форматы

9471 Wireless Mobility Manager LTE Parameters User Guide for MME Application

9471 WIRELESS MOBILITY MANAGER

2016 Nokia. Allrights reserved.

1.2 Scope of this Volume

1.3 Audience for this Document

Operational teams (Trials, FOA, Services, QACC)

The Name of the parameter is provided here

SAM Table Name

The provisioning screen in the SAM Provisioning GUI used to

The parameter is listed in <package.class.property> format in

Range & Unit

The minimum and maximum values of the parameter or the

Most parameters can be updated with no service impact. Some

The default or recommended value of the parameter.

Datafill rules are presented as follows:

System restrictions are presented as follows:

Engineering recommendations for parameter values are presented as follows:

2 RELATED DOCUMENTS AND

2.2 Reference Documents

[R35] 9471 WMM Technical Description, Release WM10.00, 9YZ-06613-0001-DEZZA

Reduced delays, in terms of both connection establishment and transmission

Increased user data rates,

Increased cell-edge bit-rate, for uniformity of service provision,

Greater flexibility of spectrum usage, in both new and pre-existing bands,

Simplified network architecture,

Seamless mobility, including between different radio-access technologies,

Reasonable power consumption for the mobile terminal.

Figure 3-1: Summary of Motivations for LTE

Multicarrier technologies (OFDMA for downlink and SC-FDMA for uplink),

Packet-switched radio interface and evolved pack core.

Figure 3-2: Summary of Motivations for LTE

Figure 3-3 : LTE Network Architecture

IP Transport Network (IP Cloud)

Figure 3-4: EUTRAN Topology

The radio interface protocols are defined in documents TS 36.2xx and

Figure 3-5: S1 and Uu interfaces (signaling control plane)

EPS Bearer Control

Figure 3-6: Functional Split between E-UTRAN and EPC

eNB- contains all radio access functions

Idle mode UE reachability

IP header compression (PDCP)

Bearer management functions

Inter Cell RRM

Policy & Charging Rules Function

Connection Mobility Cont .

Idle State Mobility

Radio Admission Control

EPS Bearer Control

Authorizes QoS resources

IP anchor point for bearers

Local mobility anchor for inter -eNB

Figure 3-7: Description of Node Functions

The eNB hosts the following functions:

Functions for Radio Resource Management: Radio Bearer Control, Radio

IP header compression and encryption of user data stream;

Selection of an MME at UE attachment when no routing to an MME can be

Routing of User Plane data towards Serving Gateway;

Scheduling and transmission of paging messages (originated from the MME);

Scheduling and transmission of broadcast information (originated from the MME

Measurement and measurement reporting configuration for mobility and

The MME hosts the following functions (see 3GPP TS 23.401):

Authenticates and authorizes a UE at the time of initial attachment and

Terminates Non-Access Stratum (NAS) from the UE

Supports NAS message integrity and ciphering