View
36
Download
9
Category
Preview:
DESCRIPTION
erh
Citation preview
EUTRAN Cell and Interface Management
Document number: LTE/SYS/DD/026072 Document issue: 03.12 / EN Document status: Approved-Standard Date: 10/Feb/2011
Passing on or copying of this document, use and communication of its contents not permitted 1
without Alcatel�Lucent written authorization 2
Copyright 2009 Alcatel-Lucent, All Rights Reserved 3
Printed in France 4
5
6
7
UNCONTROLLED COPY: The master of this document is stored on an electronic database and is “write 8
protected”; it may be altered only by authorized persons. While copies may be printed, it is not recommended. 9
Viewing of the master electronically ensures access to the current issue. Any hardcopies taken must be 10
regarded as uncontrolled copies. 11
ALCATEL-LUCENT CONFIDENTIAL: The information contained in this document is the property of Alcatel-12
Lucent. Except as expressly authorized in writing by Alcatel-Lucent, the holder shall keep all information 13
contained herein confidential, shall disclose the information only to its employees with a need to know, and 14
shall protect the information from disclosure and dissemination to third parties. Except as expressly authorized 15
in writing by Alcatel-Lucent, the holder is granted no rights to use the information contained herein. If you 16
have received this document in error, please notify the sender and destroy it immediately. 17
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 2/99
PUBLICATION HISTORY 18
Version Date Authors Chapter Change description
03.12 10/Feb/10 J. Wang
Section 4.2.6: Updated to align with LA3 implementation that avoids modem reset due to Cell Lock.
Section 4.2.4.5: Added text to reflect updated (L84876) FPSA that the platform provides a TimeOffset (to 1PPS) to the DL Scheduler.
Section 5.1.2: note added to LteCell State management
03.11 16/Dec/10 M. Gateau Section 4.12.2: clarification on interaction between RESET and ENB CONFIGURATION UPDATE procedures.
03.10 20/Aug/10 M. Gateau
Sections 4.4.3.1 and 4.4.3.2: CR #325845 : clear of S1 Setup failure and no response alarms on SCTP shutdown
Section 4.4.3.1: CR #323751 : a new alarm is sent in case of encoding problem of S1 Setup
Update to add precisions on activation flag related to L97980 (section 4.5 and 4.16.4).
Clarifications on X2 setup and X2 enb configuration update failure cases (section 4.10.2.1 and 4.11.2.1)
03.09 12/Aug/10
Wang Yunhua
Merged version for FDD and TDD
03.08T3 12/July/10 Wang Yunhua
Section 4.4.3.1, 4.4.3.2: updated with CR #321636 : S1 setup infinite retry in case of failure or no response
Section 4.2.3.2: SIB8 size correction
Tag number synchronized to be SRS-026072-x
03.08 06/July/10 M. Gateau
Section 4.2.4.5: figure 4.2.9 and following text updated.
Section 4.2.3.2: SIB5 size calculation updated
Section 4.2.7.3: CR #284246 descoped to further release – value notBarredAutoBarrable restored.
L101845 not supported in LA3.0/TLA3.0 (section 1.2, 4.8, 4.9, 4.14, 4.15
03.07T2 2/Jul/10 Wang Yunhua
Updated for TLA3.0 stream Add the impacts for eMBMS
03.07 19/May/10 M. Gateau
Section 4.15: MME selection algorithm updated
Section 5: update LTE Cell, S1-MME and X2AP data models
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 3/99
Section 4.4.5: updated with CR #269239
Section 4.12.1: precision added on cause value for X2 reset for test purpose
Section 4.2.7.3: CR #284246 - value notBarredAutoBarrable removed for object LteCell::cellBarred
03.06T1 12/May/10 Wang Yunhua
Add the words in section 1.3 to clarify the scope.
eMBMS related is not included in this drop.
03.06T0 23/Apr/10 Wang Yunhua
Draft version for TLA3.0
03.06 23/Mar/10 M. Gateau
Add event names for ENB Configuration Update failure and no response on S1 and X2 interfaces.
Sections 4.2.3.2 and 4.13.2 updated: comments received from Wang Yunhua.
Section 4.15 updated: comments received from Rodolphe Reau.
Section 4.4.2: add Default paging DRX missing in S1 Setup message
CR#269239 : Sys Info broadcast without S1 link (sections 4.2.7.3, 4.2.8 and 5.1.2).
Section 16.1.4 and 17.1.4: reception of Error Indication handling
Section 4.15: introduction of ActivationService->overloadCallRejectNotAllowed
03.05 08/Feb/10 M. Gateau
Updated following drop 2 review
CR#00241909: specific error handling for X2AP HANDOVER REQUEST ACKNOWLEDGE and X2AP HANDOVER PREPARATION FAILURE messages.
03.04 29/Jan/10 M. Gateau
X. Hao
F. Deville
JM Pugeat
C. Collin
New features added in drop 2:
FRS 104002, FRS 108172, FRS 108958, FRS 103792
03.03 26/Jan/10 M. Gateau
Jin Wang
Updated following drop 1 review.
03.02 21/Dec/09 M. Gateau
Jin Wang
Introduction of LA3.0 features : FRS92079
FRS 84876, FRS 97926, FRS 97980, FRS 92025, FRS 92026, FRS 101845
03.01 13/Nov/09 M. Gateau Creation for LA3.0
02.04 30/Oct/09 Jin Wang
…
Added back <SRS-026072-oam-0005> as the decision was to keep WiPS specs in the SRS and real checks in the separate WiPS SRS.
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 4/99
Added WiPS SRS reference.
Updated Sec 5.2.4 for FRS-96760 impact.
Added SRS-level WiPS check specs to support L97933
02.03 13/SEP/09 F. Deville Alignment on June’09 3GPP release: CR R3-091410 and R3-091343 are taken into account.
Corrections regarding SCTP management in case of S1 or X2 link lock.
Addition of cell lock/unlock in state diagram
Removal of S1 messages description (now handle in dedicated document)
02.02 24/JUL/09 JM. Pugeat,
Jin Wang
Prashant Padhy
F. Deville
Updated the document per comments following the review held 22/JUL/09
Number of supported MMEs moved from 8 to 16 (requirement from FRS 97982).
Support of X2/S1 lock/unlock and online creation/deletion
02.01 15/Jul/ 09 Prashant Padhy,
Jin Wang,
M. Gateau, JM. Pugeat
All First draft version created for LA2.0; updated from LA1.x version to support
• FRS-92784 (3GPP March 09 Alignment) by Prashant Padhy;
• FRS-97933 (Dynamic System Info Modification) by Jin Wang;
• FRS-97927 (Multi-vendor S1 IOT Readiness), FRS-97982 (Support of MME Group), FRS-97925 (X2 Operation in Multi-release Sw Environment) by M. Gateau.
• FRS-81872 Automatic Neighbour Relation Configuration and Optimisation by JM. Pugeat
01.07 11/Jun/09 Jin Wang 7.1 LA1.1 WIPS checks update
01.06 25/MAR/09 JM. Pugeat Update following review held on 20/MAR/09
01.05 16/MAR/09 JM. Pugeat All Update due to re-plan of LA1.0 / LA1.1
Addition of LA1.1.0 WiPS checks
Various corrections
01.04 16/JAN/09 JM. Pugeat 5.2.8 5.3.5 5.4 6.3
Approved document following final review
01.03 06/JAN/09 JM. Pugeat 6.2 6.3
Alignment to 3GPP December '08 S1 and X2 standards
01.02 19/DEC/08 JM. Pugeat All Update following review held on 28/NOV/08
01.01 25/NOV/08 JM. Pugeat 2.2 5.2.9 5.3.7 5.4.6
Added reference documents Added LteCell state diagram Updated S1 state diagrams Updated X2 state diagrams
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 5/99
6.2 6.3
Added Paging and missing IEs Added missing IEs
01.00 14/NOV/08 JM. Pugeat All Document creation
19
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 6/99
CONTENTS 20
1. INTRODUCTION ..............................................................................................10 21
1.1. OBJECT .................................................................................................10 22
1.2. FRS.....................................................................................................10 23
1.3. SCOPE OF THIS DOCUMENT ...............................................................................11 24
1.4. AUDIENCE FOR THIS DOCUMENT ..........................................................................11 25
1.5. OPEN POINTS ............................................................................................11 26
2. RELATED DOCUMENTS......................................................................................12 27
2.1. APPLICABLE DOCUMENTS .................................................................................12 28
2.2. REFERENCE DOCUMENTS .................................................................................13 29
3. END-TO-END ANGLE (INFORMATIVE) ....................................................................14 30
4. ENB FUNCTIONS AND PROCEDURE.......................................................................15 31
4.1. GENERAL PRINCIPLES ....................................................................................15 32
4.2. CELL SETUP .............................................................................................15 33
4.2.1 Prerequisites ....................................................................................15 34
4.2.2 Common and Shared Channels Setup ........................................................16 35
4.2.3 System Information Broadcasting ............................................................18 36
4.2.3.1 Introduction ..................................................................................18 37
4.2.3.2 System Information Size ....................................................................19 38
4.2.3.3 Broadcasting Periodicity ....................................................................21 39
4.2.3.4 System Information Broadcasting Procedure ............................................23 40
4.2.4 System Information Modification.............................................................23 41
4.2.4.1 Value Tag Management .....................................................................23 42
4.2.4.2 Class C Parameter Change..................................................................24 43
4.2.4.3 Timing Aspects ...............................................................................24 44
4.2.4.4 Change Notification Paging (CNP) .........................................................25 45
4.2.4.5 modification related to GPS status........................................................26 46
4.2.5 System Information Impacting UE Connectivity, Idle Mode Cell Reselection and Inter-47
RAT Mobility ................................................................................................28 48
4.2.6 Cell Lock/Unlock ...............................................................................29 49
4.2.7 Failure Cases ....................................................................................30 50
4.2.7.1 Cell Setup failure ............................................................................30 51
4.2.7.2 Modem failure................................................................................30 52
4.2.7.3 Cell Barring Due to Loss of S1 Services ...................................................30 53
4.2.8 Interactions with other features .............................................................31 54
4.3. PAGING ................................................................................................32 55
4.3.1 INTRODUCTION..................................................................................32 56
4.3.2 Paging procedure ...............................................................................34 57
4.3.2.1 Frame and subframe computation ........................................................34 58
4.3.2.2 Encoding of the paging record .............................................................35 59
4.3.2.3 Scheduler behavior ..........................................................................35 60
4.4. S1 SETUP ...............................................................................................36 61
4.4.1 Prerequisites ....................................................................................36 62
4.4.2 Successful Case .................................................................................36 63
4.4.3 Failure Cases ....................................................................................38 64
4.4.3.1 S1 Setup Failure..............................................................................38 65
4.4.3.2 No Response To S1 Setup ...................................................................39 66
4.4.3.3 S1 Link Failure ...............................................................................39 67
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 7/99
4.4.4 S1 Flex ...........................................................................................39 68
4.4.5 Interactions with other features .............................................................40 69
4.4.6 S1 link lock/unlock ............................................................................40 70
4.4.6.1 Behavior when locking an S1 link..........................................................40 71
4.4.6.2 Behavior when unlocking an S1 link.......................................................41 72
4.4.7 S1 online creation ..............................................................................41 73
4.4.8 S1 online deletion ..............................................................................41 74
4.5. S1 MME CONFIGURATION UPDATE ..................................................................41 75
4.5.1 Successful Case .................................................................................42 76
4.5.2 Failure Cases ....................................................................................43 77
4.6. S1 ENB CONFIGURATION UPDATE ..................................................................44 78
4.6.1 Successful Case .................................................................................44 79
4.6.2 Failure Cases ....................................................................................45 80
4.6.2.1 S1 eNB CONFIGURATION UPDATE Failure.................................................45 81
4.6.2.2 No Response To S1 eNB CONFIGURATION UPDATE ......................................46 82
4.7. S1 RESET ..............................................................................................47 83
4.7.1 S1 RESET Procedure MME initiated...........................................................48 84
4.7.2 S1 RESET PROcedure eNB initiated ..........................................................50 85
4.8. S1 OVERLOAD START (NOT IN LA3.0/TLA3.0) ......................................................51 86
4.9. S1 OVERLOAD STOP (NOT IN LA3.0/TLA3.0).......................................................52 87
4.10. X2 SETUP ..............................................................................................52 88
4.10.1 SUCCESSFUL Case...............................................................................53 89
4.10.2 FAILURE CaseS ..................................................................................55 90
4.10.2.1 X2 Setup Failure .............................................................................55 91
4.10.2.2 No Response To X2 Setup Request ........................................................56 92
4.10.2.3 X2 Link Failure ...............................................................................57 93
4.10.2.4 X2 Setup Crossover ..........................................................................57 94
4.10.3 MULTIPLE X2 LINKS .............................................................................58 95
4.10.4 INTERACTIONS WITH OTHER FEATURES .....................................................58 96
4.10.5 X2 lock/unlock .................................................................................59 97
4.10.5.1 Behavior when locking an X2 link .........................................................59 98
4.10.5.2 Behavior when unlocking an X2 link.......................................................59 99
4.10.6 X2 black-listing .................................................................................59 100
4.10.7 X2 white-listing .................................................................................59 101
4.10.8 X2 online creation..............................................................................60 102
4.10.9 X2 online deletion..............................................................................60 103
4.11. X2 ENB CONFIGURATION UPDATE ..................................................................61 104
4.11.1 Successful Case .................................................................................61 105
4.11.2 Failure Cases ....................................................................................62 106
4.11.2.1 X2 eNB CONFIGURATION UPDATE Failure.................................................62 107
4.11.2.2 No Response To X2 eNB CONFIGURATION UPDATE ......................................64 108
4.12. X2 RESET PROCEDURE ...............................................................................65 109
4.12.1 X2 RESET EMISSION .............................................................................65 110
4.12.2 X2 RESET RECEPTION...........................................................................66 111
4.13. SUPPORT OF MME GROUP ...........................................................................67 112
4.13.1 Introduction / Overview.......................................................................67 113
4.13.2 Assumptions .....................................................................................68 114
4.13.3 Support for GU Group ID List over X2........................................................68 115
4.13.3.1 Computing GU Group ID List and providing it to X2 neighbors ........................68 116
4.13.3.2 Storing GU Group ID information provided by X2 neighbors ...........................70 117
4.14. MME PRIORITY (NOT IN LA3.0/TLA3.0) .............................................................70 118
4.15. MME SELECTION ALGORITHM .......................................................................71 119
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 8/99
4.16. S1AP ERROR HANDLING .................................................................................74 120
4.16.1 Error handling at procedure level............................................................74 121
4.16.2 Error handling at IE level......................................................................74 122
4.16.3 Protocol error handling........................................................................75 123
4.16.4 Handling of S1AP Error Indication in reception ............................................77 124
4.16.4.1 Erroneous S1AP IDs ..........................................................................78 125
4.16.4.2 Abstract syntax error and logical errors..................................................78 126
4.17. X2AP ERROR HANDLING .................................................................................78 127
4.17.1 Error handling at procedure level............................................................79 128
4.17.2 Error handling at IE level......................................................................79 129
4.17.3 Protocol error handling........................................................................79 130
4.17.4 Handling of X2AP Error Indication in reception ............................................82 131
5. OAM MODEL DESCRIPTION.................................................................................83 132
5.1. LTE CELL ...............................................................................................83 133
5.1.1 Data Model ......................................................................................83 134
5.1.2 Object State Management ....................................................................87 135
5.2. MME ACCESS ..........................................................................................89 136
5.2.1 Data Model ......................................................................................89 137
5.2.2 Object State Management ....................................................................89 138
5.3. X2 ACCESS.............................................................................................91 139
5.3.1 DATA MODEL ....................................................................................91 140
5.3.2 OBJECT STATE MANAGEMENT.................................................................91 141
6. ABBREVIATIONS AND DEFINITIONS.......................................................................93 142
6.1. ABBREVIATIONS ..........................................................................................93 143
6.2. DEFINITIONS .............................................................................................94 144
ANNEX A: MASTER INFORMATION BLOCK AND SFN MASKING ..............................................95 145
ANNEX B: SYSTEM INFORMATION MESSAGE SIZE .............................................................96 146
ANNEX C: PAGING MESSAGE ENCODING ........................................................................98 147
ANNEX D: PAGING MESSAGE SIZE FOR RESOURCE BLOCK RESERVATION................................99 148
149
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 9/99
LIST OF TABLES 150
Table 1a: System Information Block Sizes (in bits) in LA3.0 ...........................................19 151
Table 2: Paging occasion subframe number .............................................................35 152
Table 3: LteCell State Management.......................................................................87 153
Table 4: MmeAccess State Management..................................................................89 154
Table 5: X2Access State Management ....................................................................91 155
156
157
LIST OF DIAGRAMS 158
Figure 1: Downlink transport channel mapping..........................................................16 159
Figure 2: Uplink transport channel mapping .............................................................17 160
Figure 3: Downlink logical channel mapping.............................................................17 161
Figure 4: Uplink logical channel mapping ................................................................17 162
Figure 5: Channels used for System Information ........................................................18 163
Figure 6: Master Information Block periodicity..........................................................21 164
Figure 7: CNP when there is a full paging cycle before the end of Modification Period (N). .....25 165
Figure 8: CNP when there is not a full paging cycle before the end of Modification Period (N). 26 166
Figure 9: Invocation of DSIM & CNP due to eNB internal state change...............................27 167
Figure 10: OAM/ data model where eNB internal state change triggers DSIM & CNP. .............28 168
Figure 11: From IMSI to a paging occasion ...............................................................33 169
Figure 12: S1 Setup Success ................................................................................37 170
Figure 13: S1 Setup Failure.................................................................................38 171
Figure 14: No Response To S1 Setup ......................................................................39 172
Figure 15: MME Configuration Update Success...........................................................42 173
Figure 16: MME Configuration Update Failure ...........................................................43 174
Figure 17: S1 eNB Configuration Update Failure ........................................................46 175
Figure 18: No Response to S1 eNB Configuration Update ..............................................47 176
Figure 19: Reset procedure MME initiated ...............................................................48 177
Figure 20: Reset procedure eNB initiated ................................................................50 178
Figure 21: Overload Start...................................................................................51 179
Figure 22: Overload Stop ...................................................................................52 180
Figure 23: X2 Setup Success ................................................................................53 181
Figure 24: X2 Setup Failure.................................................................................56 182
Figure 25: No Response To X2 Setup ......................................................................57 183
Figure 26: X2 eNB Configuration Success .................................................................61 184
Figure 27: X2 eNB Configuration Update Failure ........................................................63 185
Figure 28: No Response To X2 eNB Configuration Update..............................................64 186
Figure 29: Data Model For LteCell (1/6)..................................................................83 187
Figure 30: Data Model For LteCell (2/6)..................................................................84 188
Figure 31: Data Model For LteCell (3/6)..................................................................84 189
Figure 32: Data Model For LteCell (4/6)..................................................................85 190
Figure 33: Data Model For LteCell (5/6)..................................................................86 191
Figure 34: Data Model For LteCell (6/6)..................................................................87 192
Figure 35: LteCell State Diagram ..........................................................................88 193
Figure 36: Data Model For S1-MME ........................................................................89 194
Figure 37: MMEAccess State Diagram .....................................................................90 195
Figure 38: Data Model For X2AP ...........................................................................91 196
Figure 39: X2Access State Diagram........................................................................92 197
198
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 10/99
1. INTRODUCTION 199
1.1. OBJECT 200
This document specifies from the system level point of view the eNB Control 201
procedures for Cell, S1 and X2 common resources management. 202
203
1.2. FRS 204
LA2.0 FRS: 205
FRS-103773 3GPP Alignment (June 09) 206
FRS-97933 Dynamic System Info Modification under Cell Parameter Change 207
FRS-97927 Multi-vendor S1 IOT Readiness 208
FRS-97982 Support of MME Group 209
FRS-97925 X2 Operation in Multi-release Sw Environment 210
FRS-81872 Automatic Neighbour Relation Configuration and Optimisation 211
FRS-96760 eNB Configuration Update Enhancements 212
213
LA3.0 FRS: 214
FRS-92079 EUTRAN Standard Alignment on 3GPP Release 8 December 09 215
FRS-84876 Enhanced Non-Optimized LTE-to-HRPD Inter-RAT Mobility 216
FRS-97926 Multi-vendor X2 IOT Readiness 217
FRS-97980 Improvements over S1 218
FRS-92025 CS Fallback to UTRA for Voice Calls 219
FRS-92026 CS Fallback to GERAN for Voice Calls 220
FRS-101845 eNB MME Selection Evolution (Not in LA3.0/TLA3.0) 221
FRS-108282 eNB Class Parameter change for LA3.0 (only TAC update – other 222
impacts TBC) 223
FRS-104002 Broadcast per cell SIB4 224
FRS-108172 Full ANR 225
FRS-108958 Sysinfo Scheduling improvement 226
FRS-103792 Intra-LTE Inter-Frequency Mobility for FDD-TDD and TDD-TDD 227
228
TLA3.0 FRS: 229
FRS-103894 eUTRAN support of eMBMS Phase -1 230
FRS-113614 X2/S1 lock/unlock for transport management 231
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 11/99
1.3. SCOPE OF THIS DOCUMENT 232
The scope of this document is applicable to both LTE eNB system release LA3.0 and TLA3.0. 233
Specific TLA3.0 handling is mentioned by wording TLA3.0. 234
The following common resources control functions are specified in this document. 235
- Cell setup including common channels, shared channels setup, and System 236
Information broadcast 237
- S1 setup 238
- X2 setup 239
- Paging, 240
- Configuration update and Error Handling on S1 and X2 interfaces 241
- Dynamic invocation of DSIM (dynamic System Info modification L97933) to 242
support L84876 when eNB internal state relating to GPS changes. 243
244
1.4. AUDIENCE FOR THIS DOCUMENT 245
• PLM 246
• System Design 247
• eNB architects 248
• eNB developers 249
• eNB and system testers 250
• Field deployment teams 251
252
1.5. OPEN POINTS 253
Some open points are related to FRS 108282 (eNB Class Parameter change for LA3.0) which 254
is not currently analysed (refer to sections 4.4.7, 4.4.8 and 4.6.1). 255
An optimization of MMEAccess state management at MMEAccessGroup level is also 256
proposed for LA3.0 (refer to section 4.2.7.3. 257
258
Commentaire [ADW1] : <Start: SRS-026072-60, Other>
Feature Number: L84876 Author: Jin Wang
<End: SRS-026072-60>
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 12/99
2. RELATED DOCUMENTS 259
2.1. APPLICABLE DOCUMENTS 260
[A1] LTE/SYS/DD/026052 EUTRAN Call Handling 261
[A2] LTE/SYS/DD/029350 EUTRAN Mobility Control Plane 262
[A3] LTE/SYS/DD/026364 SRS for EUTRAN-to-HRPD/1xRTT Inter-RAT 263
Mobility 264
[A4] LTE/BTS/DD/025965 RRC Excel spreadsheet 265
[A5] LTE/SYS/DD/029664 LTE RRM DL Semi-Static and Semi-Persistent 266
Scheduler 267
[A6] LTE/SYS/DD/030195 EUTRAN Online Parameter Change – Impacts on 268
traffic 269
[A7] LTE/SYS/DD/024773 EUTRAN User Plan specification 270
[A8] LTE/SYS/DD/026110 EUTRAN Transport Traffic Management 271
[A9] LTE/SYS/DD/024855 FN - eUTRAN LA0.x – OAM – General 272
[A10] LTE/BTS/DD/024775 eNB LTE Alarm Dictionary 273
[A11] LTE/SRS/APR/027605 FTS for FRS-97933 (Dynamic SysInfo Modification 274
under Cell Parameter Change) 275
[A12] LTE/SYS/APR/02738 FTS for FRS-92784 (LA2.0 3GPP Standard 276
Compliance) 277
[A13] LTE/SYS/APR/027750 FTS for FRS 97927 “Multi-vendor S1 IOT 278
Readiness”, FRS 97925 “X2 Operation in Multi-279
release Sw Environment” and FRS 97982 280
“Support of MME group” 281
[A14] LTE/SYS/DD/027718 SRS for LTE Self Organizing Network 282
[A15] LTE/SYS/DD/026039 eUTRAN Performance Monitoring 283
[A16] LTE/SYS/DD/028103 EUTRAN Call Trace and PCMD – SRS 284
[A17] LTE/SYS/DD/024185 EUTRAN S1 Interface Specification 285
[A18] LTE/SYS/DD/028693 WiPS Checks Specifications 286
[A19] LTE/SYS/DD/028163 SRS eUTRAN Subscriber and Equipment Traces 287
Function 288
[A20] LTE/SYS/APR/027071 FTS for FRS-84876 (Enhanced Non-Optimized 289
LTE-to-HRPD Inter-RAT Mobility) 290
[A21] LTE/SYS/APR/029003 FTS for FRS-97980 (Improvements over S1) 291
[A22] LTE/SYS/APR/029159 FTS for FRS-097926 (Multi-vendor X2 IOT 292
Readiness) 293
[A23] LTE/SYS/APR/029271 FTS for FRS-101845 (eNB MME Selection 294
Evolution) 295
[A24] LTE/SYS/APR/030195 FTS for FRS-108958 (Sys-info Scheduling 296
Improvements) 297
[A25] LTE/BTS/DD/024775 ENB LTE Alarm Dictionary 298
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 13/99
[A26] LTE/SYS/DD/031890 SRS for eMBMS Control Plane 299
300
2.2. REFERENCE DOCUMENTS 301
3GPP documents 302
[R1] TS 36.331 v8.8.0 (LA3.0), v9.2.0 (TLA3.0) Radio Resource Control (RRC) 303
Protocol Specification 304
[R2] TS 36.211 v8.9.0 Physical Channels and Modulation 305
[R3] TS 36.213 v8.8.0 Physical layer procedures 306
[R4] TS 36.304 v8.8.0 User Equipment (UE) procedures in idle mode 307
[R5] TS 36.321 v8.8.0 Medium Access Control (MAC) protocol specification 308
[R6] TS 36.413 v8.8.0 S1 Application Protocol (S1AP) 309
[R7] TS 36.423 v8.8.0 X2 Application Protocol (X2AP) 310
[R8] TS 23.401 v8.8.0 GPRS enhancements for E-UTRAN access 311
[R9] R2-083733 LS on Change rate of physical layer parameters 312
[R10] R2-083820 Response LS on Change rate of physical layer 313
parameters 314
[R11] R2-083824 LS Response to LS on synchronization of L1 315
parameter from system information 316
317
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 14/99
3. END-TO-END ANGLE (INFORMATIVE) 318
319
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 15/99
4. ENB FUNCTIONS AND PROCEDURE 320
4.1. GENERAL PRINCIPLES 321
There are two high-level principles that found the base for interface management within 322
the eNB: 323
- transport layer independency from the applicative layers, 324
- interface independency one from another. 325
326
Transport layer independency from applicative layers means that the underlying transport 327
services will always attempt to set up without expecting applicative triggers. In other 328
words, after an eNB startup, board reset or link failure, transport must be established 329
regardless of the state of applicative layers. Transport layer independency guarantees the 330
fastest restart or recovery times by enforcing an "always ready" policy rather than 331
conditioning transport setup to higher-level application readiness. Nevertheless, some 332
level of applicative layer control exists: interface locking will cause the transport to be 333
brought down, and X2 black-listing will prevent the transport layer from establishing. 334
Interface independency means that S1, X2 and RRC interfaces shall be established 335
independently (by RRC interface setup it is meant Cell Setup and System Information 336
broadcasting). For example, Cell Setup procedure initiation shall not be conditioned to, for 337
example, the prior setup of the S1 interface. Interface independency guarantees the 338
fastest restart or recovery times by parallelizing rather than serializing interface setup. 339
At eNB start-up the eNB shall therefore launch in parallel: 340
- the Cell Setup procedure for each of the cells belonging to this eNB, as 341
described in section 4.2; 342
- S1 Setup towards one or several MMEs as described in section 4.4; 343
- X2 Setup towards other eNBs as described in section 4.7. 344
345
4.2. CELL SETUP 346
Cell setup consists in common and shared channels setup followed by System Information 347
broadcast. 348
The cell setup procedure is described in section 4.2.2. 349
The System Information procedure is described in section 4.2.3. 350
351
4.2.1 PREREQUISITES 352
Prior to triggering the cell setup procedure, the eNB will have performed the following 353
steps, as defined in[A9]: 354
- internal MIB generation. 355
It is therefore ensured that all configuration parameters required to perform cell setup are 356
available at the time it is launched. 357
358
Commentaire [ADW2] : <Start: SRS-026072-230, Other>
Feature Number: L108282 Author: Martine Gateau
<End: SRS-026072-230>
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 16/99
4.2.2 COMMON AND SHARED CHANNELS SETUP 359
Based on the configuration parameters received during the eNB startup sequence, the eNB 360
will start the initialization of each of its cells. 361
The following physical channels are established in the cell: 362
• Physical broadcast channel (PBCH) 363
• Physical control format indicator channel (PCFICH) 364
• Physical downlink control channel (PDCCH) 365
• Physical downlink shared channel (PDSCH) 366
• Physical multicast channel (PMCH) Not in LA3.0, supported in TLA3.0 367
• Physical uplink control channel (PUCCH) 368
• Physical uplink shared channel (PUSCH) 369
• Physical Hybrid ARQ Indicator Channel (PHICH) 370
• Physical random access channel (PRACH) 371
372
The following transport channels are established in the cell: 373
• Broadcast Channel (BCH) 374
• Downlink Shared Channel (DL-SCH) 375
• Paging Channel (PCH) 376
• Multicast Channel (MCH) Not in LA3.0, supported in TLA3.0 377
• Uplink Shared Channel (UL-SCH) 378
• Random Access Channel(s) (RACH) 379
380
The mapping of downlink transport channels on physical channels is the following: 381
382
383
Figure 1: Downlink transport channel mapping 384
385
The mapping of the uplink transport channels on physical channels is the following: 386
387
Commentaire [ADW3] : <Start: SRS-026072-430, Requirement>
Feature Number: 103894 Author: Wang Yunhua Release: TDD
<End: SRS-026072-430>
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 17/99
RACH UL-SCH
PUSCHPRACH
UplinkTransport channels
UplinkPhysical channels
PUCCH 388
Figure 2: Uplink transport channel mapping 389
390
The following control logical channels are established in the cell: 391
• Broadcast Control Channel (BCCH) 392
• Paging Control Channel (PCCH) 393
• Common Control Channel (CCCH) in the UL and DL 394
• Multicast Control Channel (MCCH) Not in LA3.0, supported in TLA3.0 395
396
The mapping of downlink logical channels to transport channels is the following: 397
398
399
Figure 3: Downlink logical channel mapping 400
401
The mapping of uplink logical channels to transport channels is the following: 402
403
CCCH DCCH DTCH
UL-SCHRACH
UplinkLogical channels
UplinkTransport channels
404
Figure 4: Uplink logical channel mapping 405
406
Commentaire [ADW4] : <Start: SRS-026072-440, Requirement>
Feature Number: 103894 Author: Wang Yunhua Release: TDD
<End: SRS-026072-440>
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 18/99
As part of the cell setup procedure after the physical and transport channels are setup in 407
the cell, the eNB will start broadcasting RRC System Information messages on BCCH of the 408
cell. 409
During the Cell setup, the states changes of the LteCell MO are managed as described in 410
section 5.1.2. 411
At the end of the cell setup procedure, the eNB is ready to accept mobile originated or 412
terminated calls in this cell. 413
Failure cases 414
In case of cell setup failure the LteCell MO state is changed as below. In LA3.0 a human 415
intervention via OMC is needed to correct the configuration data and proceed with e.g. a 416
modem board reset. Trace and debug functionality is supported as specified in SRS eUTRAN 417
Subscriber and Equipment Traces Functions (reference [A19]). 418
419
Event LteCell MO states attributes (administrative/operational/availability)
When cell initialization starts Unlocked/Disabled/Dependency When a sector and a modem are available and cell setup fails (Note)
Unlocked/Disabled/Failed
420
Note: The availability “failed” is proposed for cases like invalid configuration parameter or 421
software anomaly for which there is no defense mechanism (e.g. board reset(s) done but 422
error persists or no defense at all). In that case, there is no other object disabled/Failed 423
(board…). 424
425
4.2.3 SYSTEM INFORMATION BROADCASTING 426
4.2.3.1 INTRODUCTION 427
System Information messages are carried over the BCCH logical channel and provide 428
network-related configuration data to the mobiles. The BCCH is mapped onto both: 429
- the BCH transport channel (for the MasterInformationBlock) which is carried by the PBCH 430
physical channel 431
- the DL-SCH transport channel (for all other system information blocks) which is carried 432
on the PDSCH. 433
434
435
Figure 5: Channels used for System Information 436
437
Commentaire [ADW5] : <Start: SRS-026072-450, Requirement>
Feature Number: 103894 Author: Wang Yunhua Release: TDD
<End: SRS-026072-450>
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 19/99
There are a maximum of 32 System Information Blocks that may be defined, in addition to 438
the MasterInformationBlock. Currently only thirteen have been standardized. Hereafter is 439
a brief description of the current information blocks' content: 440
• MasterInformationBlock or MIB: essential physical layer information. 441
• SystemInformationBlockType1 or SIB1: cell access information and scheduling of 442
other system information messages. 443
• SystemInformationBlockType2 or SIB2: common and shared channel information 444
• SIB3: cell re-selection information 445
• SIB4: intra-frequency neighboring cells 446
• SIB5: inter-frequency neighboring cells 447
• SIB6: inter-RAT cell re-selection towards UTRAN 448
• SIB7: inter-RAT cell re-selection towards GERAN 449
• SIB8: inter-RAT cell re-selection towards CDMA2000 (details are captured in [A3]) 450
• SIB9: home eNB identifier (Not in LA3.0/TLA3.0) 451
• SIB10 and SIB11: Earthquake and Tsunami Warning System or ETWS (Not in 452
LA3.0/TLA3.0) 453
• SIB12: Commercial Mobile Alert Service or CMAS (Not in LA3.0/TLA3.0) 454
• SIB13: acquire the MBMS control information associated with one or more MBSFN 455
areas (Not in LA3.0, supported in TLA3.0) 456
457
4.2.3.2 SYSTEM INFORMATION SIZE 458
System Information size ranges in bits are provided hereafter. Minimum and maximum 459
sizes are derived from the ASN1 constructs, while expected size is estimated based on 460
LA3.0 feature content. The numbers are given to provide an indication of System 461
Information sizes, and must be used with caution. Note that a System Information Message 462
has a size limit of 2216 bits due to the imposed DCI format; since the header has a 14-bit 463
size (cf. Annex B), this implies a maximum size of 2202 bits for System Information Blocks. 464
In LA3.x SIB6/7 (UMTS/GSM) and SIB8 (CDMA2000), if present, are mutually exclusive. The 465
PQ2-PQ3 interface currently does not support SAR (segmentation and reassembly) for a 466
UDP/IP payload size exceeding 1500 bytes even though the CCM-CEM interface supports up 467
to 64K bytes. This lack of SAR support however does not affect LA3.0 since the re-468
estimated SIBs size does not exceed 1500 bytes. 469
With L108958 (Sys Info Scheduling Improvement), multiple SIBs can be mapped to a single 470
System Info message as determined by the DL Scheduler. 471
Table 1a: System Information Block Sizes (in bits) in LA3.0 472
Message / Block Min Size Max Size Expected Size (LA3.0)
MIB 24 24 24
SIB1 114 368 158
SIB2 186 273 205
SIB3 29 75 66
SIB4 4 490 476
SIB5 66 2202 584
SIB6 7 763 763
SIB7 56 2202 522
Commentaire [ADW6] : <Start: SRS-026072-80, Other>
Feature Number: L104002 Author: XU Hao
<End: SRS-026072-80>
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 20/99
SIB8 9 2202 377
473
The expected size of SIBs is based on the following assumptions: 474
SIB1: only one PLMN is broadcast, and there are a maximum of four SI-Messages scheduled. 475
SIB2: ac-BarringInfo, preamblesGroupAConfig and mbsfn-SubframeConfigList are not 476
included. 477
SIB3: p-Max and allowedMeasBandwidth are not included. 478
SIB4: csg-PhysCellIdRange is not included, 16 physical cell identities are included in the 479
neighbour list (intraFreqNeighCellList) and 16 physical cell identities and ranges are 480
included in the list of black-listed cells (intraFreqBlackCellList). For the min size, assuming 481
not include any real IE, 4 bits is just a structure overhead. 482
SIB5: a WPS and XMS error check will prevent the operator from configuring a number of 483
inter-frequency neighbours that would not fit within the 2202 bit limit. The total size of 484
SIB5 will essentially depend on four parameters: 485
- the number of configured inter-freq frequencies (number of instances of 486
LteNeighboringFreqConf minus one), or nFreq 487
- the total number of configured inter-freq cells (total number of instances of 488
LteNeighboringCellRelation that are not under the LteNeighboringFreqConf object of 489
the cell's frequency), or nInterFreqCell 490
- the total number of configured inter-freq black-list configurations (total number of 491
instances of BlackCellConf that are not under the LteNeighboringFreqConf object of 492
the cell's frequency), or nInterFreqBlackCellConf 493
- the total number of configured inter-freq black-listed ranges (total number of 494
times optional parameter "range" is configured in a BlackCellConf object that is not 495
under the LteNeighboringFreqConf object of the cell's frequency), or 496
nInterFreqBlackCellConfRange 497
Assuming that all optional parameters of SIB5 are present, the total size of SIB5 in 498
bits can be calculated as: 499
Totalsize= 4 + 74 * nFreq + 14 * nInterFreqCell + 10 * nInterFreqBlackCellConf + 4 * 500
nInterFreqBlackCellConfRange 501
For the expected size, we will assume 2 frequencies (nFreq), 20 cells 502
(nInterFreqCell), 12 black-list configurations (nInterFreqBlackCellConf) and 8 ranges 503
(nInterFreqBlackCellConfRange), which translates into a total size of 579 bits. 504
For the min size, we will assume q-OffsetFreq, pMax and cellReselectionPriority are 505
all present. 506
507
SIB6: only UTRA-FDD information is broadcasted (carrierFreqListUTRA-FDD). For the min 508
size, assuming only inlcudes T-Reselection. 509
SIB7: only 4 frequency groups (an element of carrierFreqsInfoList) are broadcast (enforced 510
by a WIPS check that there are a maximum of 4 GeranNeighboringFreqConf objects per 511
LteCell), with a total of maximum 32 frequencies being broadcast across all groups. 512
SIB8: synchronousSystemTime is included; preRegistrationZoneId, 513
secondaryPreRegistrationZoneIdList, and all 1XRTT parameters are not included. The fact 514
that only two bands can be configured in MIM and that TS36.331 limits the number of 515
neighbours broadcast in SIB8 to 32 is also taken into account. Assuming only the 516
searchWindowSize IE is included in SIB8 when calculating SIB8 minimum size. 517
The estimation for SIB sizes in TDD considering TDD-specific IE in SIBs: 518
Table 1b: System Information Block Sizes (in bits) in TLA3.0 519
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 21/99
Message / Block Min Size Max Size Expected Size (TLA3.0)
MIB 24 24 24
SIB1 100 2202 348
SIB2 175 489 257
SIB3 29 74 72
SIB4 4 490 476
SIB5 66 2202 584
SIB6 7 1443 687
SIB7 56 2202 522
SIB8 9 2202 N/A
SIB13 41 237 41
520
The expected size of SIBs is based on the following assumptions in addition to LA3.0: 521
SIB2: mbsfn-SubframeConfigList is included and maxMBSFN-Allocations is 1. 522
SIB13: maxMBSFN-Area is 1. 523
524
4.2.3.3 BROADCASTING PERIODICITY 525
The MasterInformationBlock and SystemInformationBlockType1 use fixed scheduling, 526
whereas all other system information blocks are carried in System Information Messages 527
whose scheduling is defined in SIB1. 528
The MasterInformationBlock is scheduled in subframe 0 of frames with SFN mod 4 = 0, with 529
repetitions in subframe 0 of every radio frame. It therefore has a periodicity of 40ms (a 530
MasterInformationBlock with a new System Frame Number is sent every 40 ms) and a 531
repetition rate of 10ms (the MasterInformationBlock is repeated 3 times at 10ms intervals 532
without changing the SFN). 533
534
MIB withSFN = 4n
MIB withSFN = 4n + 4
3 repetitions
40 ms
10 ms
535
Figure 6: Master Information Block periodicity 536
537
Note: the full system frame number is 10 bits long, composed of 8 bits provided in the 538
MasterInformationBlock and 2 bits acquired implicitly from the BCH decoding. 539
Commentaire [ADW7] : <Start: SRS-026072-460, Requirement>
Feature Number: 103894 Author: Wang Yunhua Release: TDD
<End: SRS-026072-460>
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 22/99
The SystemInformationBlockType1 is scheduled in subframe 5 of frames with SFN mod 8 = 540
0, and is repeated in subframe 5 of every even frame. It therefore has a periodicity of 541
80ms, with a repetition rate of 20ms. 542
The other System Information Blocks have a periodicity that may be individually set among 543
the following values: 8, 16, 32, 64, 128, 256, or 512 radio frames. The periodicity of 544
System Information Blocks 2 and upwards is indicated to the UEs by the 545
SchedulingInformation IE contained in SystemInformationBlockType1. 546
SIBs 2 and upwards are carried in System Information Messages, which contain one or 547
several SIBs and are broadcast within recurring periods called SI-windows. The duration of 548
the SI-window is common to all SI Messages, and is broadcast in SIB1. SI-windows of 549
different SI Messages do not overlap, in other words only one SI Message is broadcast and 550
eventually repeated within an SI-window. The first SI Message to be scheduled must 551
contain SIB2 in the first position, and an SI Message may only contain SIBs that have the 552
same periodicity. 553
The frame and subframe number at which the SI-window for a given SI Message begins are 554
determined in the manner described hereafter. 555
For the nth SI Message in the schedulingInformation IE of SIB1: 556
- the SI-window begins in the subframe number [(n – 1)*w] mod 10, where w is the si-557
WindowLength broadcast in SIB1; 558
- the frame number in which the SI-window begins verifies SFN mod T = FLOOR([(n – 1)*w] 559
/10), where T is the si-Periodicity of the concerned SI message 560
Note: some combinations of SI-window, number of SI Messages and periodicities are not 561
possible. Typically, the smallest periodicity must be superior to the number of SI Messages 562
multiplied by the size of the SI-window. 563
Resource allocation for System Information Blocks is signaled on the PDCCH channel using 564
the dedicated SI-RNTI (defined as 0xFFFF in [R5] TS 36.321). 565
566
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 23/99
4.2.3.4 SYSTEM INFORMATION BROADCASTING PROCEDURE 567
Once the common and dedicated channel setup procedure has been successfully 568
completed, the eNB will initiate the System Information Broadcasting procedure, which 569
consists in 4 steps: 570
571
- encoding of System Information blocks numbered 2 and higher: 572
- SIB2 and SIB3 are always provided, 573
- rules for providing SIB6, SIB7 and SIB8 can be find in document [A3], 574
- rules for providing SIB4 and SIB5 can be find in document [A2]. 575
576
- rules for providing SIB13 can be find in document [A26] 577
- choice of the number and periodicity of SI Messages that will be used to broadcast system 578
information, based on a configured target periodicity and coding scheme (MCS); the si-579
WindowLength is set by the scheduler (hardcoded value set to 20ms); 580
- encoding of Master Information Block and System Information Block Type1 and necessary 581
SI messages; 582
- broadcasting of all system information blocks. 583
Pre-encoding of the SIBs that are broadcast in SI messages (SIBs 2 and higher) is required in 584
order to calculate their respective sizes. These sizes are used by the Scheduler, along with 585
parameters such as the target periodicity and target coding scheme, to determine the best 586
scheduling scheme for system information: number of SI messages and eventual repetitions 587
of the SI messages within the SI-window. 588
Details of the algorithm are to be found in [A5]. 589
590
591
4.2.4 SYSTEM INFORMATION MODIFICATION 592
There are two mechanisms used to signal to the UEs that System Information has changed 593
and must be read again: 594
- systemInformationValueTag (hereafter referred to as value tag) is a mandatory 595
Information Element in RRC message SystemInformationBlockType1. It takes 596
integer values within a small set of 32 values, and must be updated every time 597
the system information changes. 598
- systemInfoModification may be optionally included in RRC Paging to indicate an 599
upcoming change in System Information 600
601
4.2.4.1 VALUE TAG MANAGEMENT 602
In order for the CallP to know which value was used for the value tag prior to the eNB 603
restart or cell lock, the information will be stored into the semi-persistent memory. It is 604
also saved in the CallP context as a backup. This is a zone in the RAM which survives across 605
an eNB restart. At startup or after cell unlocking, CallP will read the value stored in the 606
semi-persistent memory, add one to it, and then store the updated value in the semi-607
persistent memory and use it to populate the value tag in SIB1. 608
Commentaire [ADW8] : <Start: SRS-026072-90, Other>
Feature Number: L104002 Author: XU Hao
<End: SRS-026072-90>
Commentaire [ADW9] : <Start: SRS-026072-480, Requirement>
Feature Number: 103894 Author: Wang Yunhua Release: TDD
<End: SRS-026072-480>
Commentaire [ADW10] : <Start: SRS-026072-130, Other>
Feature Number: L108958 Author: Jean-Michel Pugeat
<End: SRS-026072-130>
Commentaire [ADW11] : <Start: SRS-026072-140, Other>
Feature Number: L108958 Author: Jean-Michel Pugeat
<End: SRS-026072-140>
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 24/99
The CallP therefore updates the value tag after each restart and each cell unlocking, 609
regardless of the reason that triggered it. 610
If the CallP fails to read the stored value during cell setup/ re-setup, it will use the backup 611
value saved in the CallP context. After an eNB restart (power on), it will use a random 612
value for the value tag. There is a chance (one out of 32) that the random value is the 613
same as the value prior to eNB restart or cell lock, meaning some UEs may not re-acquire 614
System Info even though SIBs parameters can change across eNB restart. To address this, 615
the eNB self-triggers a DSIM/ CNP shortly after an eNB restart, forcing an update on the 616
value tag with the corresponding CNP to the UEs. 617
618
The service allowing to read and write into the semi-persistent memory needs to be 619
modified for this specific purpose of CallP. The result will be a file system in which the 620
CallP can write and read; the service will have to be fully started before the CallP is 621
launched. It may be necessary to define the file format in order to facilitate upgrades (file 622
version compatibility issues may arise) and prepare future evolutions (SON features for 623
example). 624
625
4.2.4.2 CLASS C PARAMETER CHANGE 626
If there are any changes of “Class C” parameters relating to SIBs in the MIM, the XMS 627
notifies the eNB about the change to support dynamic System Info modification. The value 628
tag in SIB1 is updated to be included in System Info and, prior to the inclusion of the 629
actual change in System Info broadcasting, an optional bit in RRC Paging is used indicate to 630
all UEs about the upcoming change in System Info. This process is referred to as DSIM with 631
CNP (dynamic System Info modification with change notification paging). 632
More details on Class C parameter change can be find in document ref [A6]. 633
634
635
4.2.4.3 TIMING ASPECTS 636
Dynamic modification of the system information is only permitted at specific points in 637
time. These instants are the boundaries of periods called "modification periods", which is 638
somewhat misleading because in fact, no change may occur during a modification period. 639
The duration of the modification period is calculated using two parameters that are 640
broadcast in SIB2: modificationPeriodCoeff which takes its values in the range {2, 4, 8, 16} 641
and defaultPagingCycle which may be set to 32, 64, 128 or 256 radio frames(cf. the 642
paragraph on Paging, 4.3). The duration of the modification period is expressed in numbers 643
of radio frames and is given by the following formula: 644
modificationPeriod = modificationPeriodCoeff * defaultPagingCycle 645
When the value of one or several parameters broadcasted in the System Information 646
messages is changed during a given modification period N, or when there is a growth or de-647
growth of instances in the MIM that are mapped to SIBs parameters, the actual messages 648
being broadcast over the air interface will be updated at the boundary between 649
modification period N and N+1 if there remains a full paging cycle before the end of period 650
N (see Figure 7). Otherwise, the update will be at the boundary of periods N+1 and N+2 651
(see Figure 8). 652
653
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 25/99
4.2.4.4 CHANGE NOTIFICATION PAGING (CNP) 654
655
Modem ( K)
BCCH modification period (N)
Change notification Updated information
BCCH modification period (N+1)
XMS
eNBCallP
DLScheduler
RRC Idle &Connected
UEs
Del
ta U
pdat
e(
SIB
x, C
ell_
ID=K
)
CELL_RLC_M
AC_SYSINFO_
SCHEDULING_REQUEST(SIBx, sizes, etc)
BCCH Modification
Period
N N+1 N+2
CELL_RLC_M
AC_SYSINFO_
UPDATE_REQUEST(e
ncod
edSIBx)
Current SIBx
Next SIBx
Current SIBx
When the ending boundary of Modification Period
(N) is about to be reached, the DL Scheduler
• Copies Next_SIBx to Current_SIBx;
• Deletes the existing SIB pre-booking;
• Re-performs SIB pre-booking.
Broadcast of SI messages carrying the updated
SIBs begins at the starting boundary of
Modification Period (N+1).
Assume 2 DefaultPagingCycle’sin a Modification Period
…
Pag
e(
system
Info
Modification)
SIB1 and SIBx prior to and during “change notification”
(Same or modified) SIB1 with ValueTag change and modified SIBx after “change notification”
Encode the modified SIBx and
set SIB1’s ValueTag += 1
A UE’s Paging Occasion (PO) in DefaultPagingCycle
Send a CNP for
each PO in the last
defaultPagingCycle
656
Figure 7: CNP when there is a full paging cycle before the end of Modification Period (N). 657
658
Next SIBx
Modem ( K)
eNBCallP
DLScheduler N N+1 N+2
Current SIBx
Next SIBx
Current SIBx
Pag
e(
system
Info
Modification
)
BCCH modification period (N)
Change notification Updated information
BCCH modification period (N+1)
RRC Idle &Connected
UEs
BCCH Modification
Period
Assume 2 DefaultPagingCycle’sin a Modification Period
…
In this variation the DSIM trigger arrives after
the start of the last DefaultPagingCycle of
Modification Period (N) such that at least one
PO has been missed for CNP purpose. So
CNP starts in the 1st DefaultPagingCycle of
Modification Period (N+1), as shown.
Del
ta U
pdat
e(
SIB
x, C
ell_
ID=
K)XMS
CELL_RLC_M
AC_SYSINFO_
SCHEDULING_REQUEST(SIBx, sizes, etc)
CELL_RLC_M
AC_SYSINFO_
UPDATE_REQUEST(e
ncod
edSIBx)
Current SIBx
Send a CNP for each PO in
the last defaultPagingCycle.
May repeat CNP in previous
paging cycle(s).
When the ending boundary of Modification
Period (N+1) is about to be reached, the DL
Scheduler
• Copies Next_SIBx to Current_SIBx;
• Deletes the existing SIB pre-booking;
• Re-performs SIB pre-booking.
Broadcast of SI messages carrying the
updated SIBs begins at the starting boundary
of Modification Period (N+2).
659
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 26/99
Figure 8: CNP when there is not a full paging cycle before the end of Modification Period (N). 660
661
The CNP may be repeated in a Modification Period. 662
663
The reason for CNP is that one of the two manners in which the UEs may check for System 664
Information modification is to listen for a Paging message indicating a change in System 665
Information. Since a UE only listens to its own paging occasions and since there is only one 666
during a paging cycle, it is necessary to go through a full paging cycle in order to page all 667
mobiles for a change in System Information. 668
The other manner in which a UE may check for System Information updating is to check 669
the Value Tag at each boundary between modification periods. The eNB must update the 670
value tag every time the System Information that is broadcasted is modified. 671
672
4.2.4.5 MODIFICATION RELATED TO GPS STATUS 673
674
While DSIM invocation in LA2.x is limited to SIB-related “Class C” parameter change via 675
OAM and automatic cell barring by eNB as a result of detection of S1 failure (outage or 676
OAM action) , L84876 in LA3.0 extends the triggers to include certain internal state change 677
that relates to GPS status on the eNB. Specifically, the (CDMA) systemTimeInfo IE in SIB8 678
is optional and, when present, it is based on the primary timing source derived from GPS 679
and can take the form of either a “sync mode” (39 bits for the field) or “async mode” (49 680
bits). The CallP invokes DSIM and CNP dynamically when certain status change relating to 681
GPS (CdmaPhaseSync and GpsTime) occurs; UEs in RRC Connected and RRC Idle acquire the 682
updated info in SIB8. Examples of the state transitions include (see Figure 9): 683
• A change of the “async mode” to “sync mode” for the systemTimeInfo IE in SIB8 684
(refer to the state transition labeled (5) in the figure); 685
• A change from the “sync mode” to the exclusion of the systemTimeInfo IE from 686
SIB8 (refer to label (3) in the figure); 687
• A change from an absence of the systemTimeInfo IE to the inclusion of either the 688
“async mode” in SIB8 (refer to label (4-1) in the figure) or “sync mode” in SIB8 689
(refer to the label (4-3) in the figure); 690
• A change from the “async mode” to the exclusion of the systemTimeInfo IE from 691
SIB8 (refer to label (4-2) in the figure). 692
The above assume, under ActivationService, isSynchCdmaSystemTimeAllowed=True. If 693
isSynchCdmaSystemTimeAllowed=False indicating no L84876 support for UEs requiring MG, 694
the state transitions with labels (4-1) and (4-2) can still occur, but systemTimeInfo is 695
excluded from SIB8 and the fine clock adjustment does not have to take place. 696
The support of the async-mode allows eNB to resume the use of B2 and B1 measurements 697
(for UEs requiring MG) as soon as GPS recovers, rather than wait until the (slow) clock 698
adjustment logic has run its course that can take many hours. The capability can help ALU 699
win tier-2/ tier-3 CDMA customers over the competition since they may choose a 700
“cheaper” version of an on-board oscillator offering a shorter phase holdover interval after 701
GPS loss, significantly increasing the odds that the GPS does not recover within the 702
holdover (i.e. the transition with label 3) and requires many hours of clock adjustments 703
after GPS recovers (the transitions with label 4-1 and label 5). 704
A description of the overall solution can be found in [A20]. 705
706
Commentaire [ADW12] : <Start: SRS-026072-65, Other>
Feature Number: L84876 Author: Jin Wang
<End: SRS-026072-65>
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 27/99
CDMA Phase Sync = “Enabled/ degraded”
GPS Time = “Disabled/ failed”
CDMA Phase Sync = “Disabled/ dependency”
GPS Time = “Disabled/ failed”CDMA Phase Sync = “Disabled/ dependency”
GPS Time = “Enabled/ none”
CDMA Phase Sync = “Enabled/ none”
GPS Time = “Enabled/ none”
� Oscillator’s Phase-Sync Holdover End alarm is raised
� Clock Adjustment reduces Phase Drift to less than 10us
�-1 GPS time becomes available & actual drift >= 10 us
�-2 GPS time becomes unavailable
GPS time becomes unavailable
Upon entry (state transition):• Set upsynchronousSystemTime in systemTimeInfo in SIB8;
• Perform DSIM (SIB8 & SIB1);• Start Fine Clock Adj (if not running)Afterward:• Update the IE everysib8Periodicity
Upon entry (state transition):• Set upasynchronousSystemTime in systemTimeInfo in SIB8;
• Perform DSIM (SIB8 & SIB1);• Start Fine Clock Adjustment;Afterward:• Update the IE everysib8Periodicity
Upon entry (state transition):• Remove systemTimeInfo from
SIB8;• Perform DSIM (SIB8 & 1);• Stop Fine Clock Adjustment (if
running).
GPS time becomes available
Upon entry (state transition):• Stop Fine Clock Adjustment.
�-3 GPS time becomes available and actual drift is < 10us
707
Figure 9: Invocation of DSIM & CNP due to eNB internal state change. 708
709
710
711
The eNB supports reception of CdmaPhaseSync and GpsTime state change notification from 712
the OAM, which can trigger a state transition as illustrated in the figure. The state 713
transition is communicated to the DL Scheduler to trigger DSIM & CNP via an enhanced 714
interface between the CallP and DL Scheduler. For the case with label (5) or label (4-3) in 715
the figure, the CallP 716
• Sets cdma-EUTRA-Synchronisation in systemTimeInfo in SIB8 to True; 717
• Does not populate synchronousSystemTime (a 39-bit field with 10ms granularity) in 718
systemTimeInfo since the DL Scheduler is to initialize it based on GPS time from 719
the platform, and subsequently update it every Sib8Periodicity; 720
• Sets a field-size flag to 39 and includes an “offset” parameter where 721
synchronousSystemTime field of 39 bits in systemTimeInfo would start relative to 722
the start of the encoded Sys Info to be sent to the DL Scheduler. 723
For the case with label (4-1) in the figure, the CallP 724
• Sets cdma-EUTRA-Synchronisation in systemTimeInfo in SIB8 to False; 725
• Does not populate asynchronousSystemTime (a 49-bit field with 6.5us granularity) 726
in systemTimeInfo since the DL Scheduler is to initialize it based on both GPS time 727
and an offset to GPS 1PPS from the platform, and subsequently update it every 728
Sib8Periodicity; 729
• Sets the field-size flag to 49 and includes an “offset” parameter where 730
asynchronousSystemTime field of 49 bits in systemTimeInfo would start relative to 731
the start of the encoded Sys Info message to be sent to the DL Scheduler. 732
In the async-mode case: 733
• The time offset to GPS 1PPS message is provided directly by the platform to the DL 734
Scheduler in unit of 500ns (0.5us). At a phase misalignment correction rate of 10 PPB 735
(parts per billion) or 10ns per second, it takes 50 seconds for the platform to correct 736
Mise en forme : Puces etnuméros
Commentaire [ADW13] : <Start: SRS-026072-75, Other>
Feature Number: L84876 Author: Jin Wang
<End: SRS-026072-75>
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 28/99
500ns worth of phase misalignment and 13 TimeOffset messages at most to accumulate 737
6.5us (=500ns * 13) worth of misalignment correction that has an actual effect on 738
asynchronousSystemTime in SIB8 since async-mode granularity is 6.5us. 739
• While the DL Scheduler receives the SIB8 update from the CallP via one transport path 740
and receives the TimeOffset message from the platform via another transport path, 741
the actual broadcast of updated SIB8 won’t take place until the start of next 742
Modification Period (at least 320ms if MIM defaultPagingCycle = 320ms), allowing the 743
DL Scheduler to get the TimeOffset value in time to initialize asynchronousSystemTime 744
field in SIB8 ahead of its actual transmission. 745
For the case with labels (3) & (4-2) in the figure, the CallP sets the field-size flag to 0 746
indicating exclusion of systemTimeInfo from SIB8. 747
Note that the bit “offset” parameter has to take into account whether the DL Scheduler is 748
to map multiple SIBs with the same periodicity value to a single Sys Info message. 749
750
751
The optional GpsTime MO is already supported in LA2.x MIM and CdmaPhaseSync sub-MO is 752
added underneath it (see Figure 10). 753
754
Enb
GPS Time(GpsTime)
CDMA Phase Sync(CdmaPhaseSync)
[0..1]
Operational State(operationalState)
Availability Status(availabilityStatus)
ClockSync
755
Figure 10: OAM/ data model where eNB internal state change triggers DSIM & CNP. 756
757
758
759
4.2.5 SYSTEM INFORMATION IMPACTING UE CONNECTIVITY, IDLE MODE CELL 760
RESELECTION AND INTER-RAT MOBILITY 761
With dynamic modification of System Information, the parameters whose modification 762
could affect UE connectivity have been analyzed by RAN1 in [R11] and are listed 763
hereunder: 764
- (2)RBN in [R2] TS 36.211 indicates the number of CQI only RBs. This corresponds to 765
parameter "nRB-CQI" in the pucch-Configuration IE of the SystemInformationBlockType2. 766
- (1)csN in [R2] TS 36.211 indicates the number of CS values used for CQI in mixed RBs of 767
CQI and ACK/NACK or SR. This corresponds to parameter "nCS-An" in the pucch-768
Configuration IE of the SystemInformationBlockType2. 769
Commentaire [ADW14] : <Start: SRS-026072-360, Other>
Feature Number: L84876 Author: Jin Wang
<End: SRS-026072-360>
Commentaire [ADW15] : <Start: SRS-026072-85, Other>
Feature Number: L84876 Author: Jin Wang
<End: SRS-026072-85>
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 29/99
- (1)PUCCHN in [R3] TS 36.213 indicates the boundary between the resource for ACK/NACKs 770
for persistent scheduling or SR and the resource for ACK/NACK for dynamic scheduling. 771
This corresponds to parameter "n1Pucch-AN" in the pucch-Configuration IE of the 772
SystemInformationBlockType2. 773
- PUCCHshift∆ in [R2] TS 36.211 indicates how to use the PUCCH resource. This corresponds to 774
parameter «deltaPUCCH-Shift" in the pucch-Configuration IE of the 775
SystemInformationBlockType2. 776
At this stage no other parameters are considered to possibly affect UE connectivity when 777
modified dynamically. 778
779
While L97933 supports a standards-compliant mechanism to notify UEs of a change of the 780
content in System Information, it is an independent case-by-case study to determine 781
whether any of the parameters listed above can be changed to “Class C” to take advantage 782
of L97933 capabilities with a minimal impact on UE connectivity. 783
In addition to UE connectivity, dynamic modification of System Info also impacts idle-mode 784
UE cell reselection and active UE inter-RAT mobility. This is because some SIBs-related 785
parameters and MOs/sub-MOs are optional and, if of “Class C” type, can become present or 786
absent dynamically. And once present and included in System Info, both optional and 787
mandatory components of the SIB can change dynamically (if “Class C”). Thus a case-by-788
case study may be necessary to determine whether the corresponding SRS needs any 789
additional requirements for eNB interaction behavior to meet customer’s expectations. 790
As an example, consider LTE-to-HRPD mobility. SIB8 in System Info is optional; if present, it 791
has an influence on idle UE cell reselection. If the IRAT feature control is also activated, the 792
influence of SIB8 extends to active UE IRAT redirection/mobility and the associated KPI. This 793
means once SIB8 is included in System Info, dynamic change of parameters in SIB8 can have 794
an impact on new calls, existing calls, and incoming HO calls. To handle the interaction, 795
• Document ref [A3] specifies CallP behavior in terms of dynamic inclusion or exclusion of 796
SIB8 in System Info and specifies what to do for new/existing calls if SIB8 content 797
changes; 798
• Document ref [A11] (FTS for FRS-97933) specifies the handling of the (cdma2000) 799
systemTimeInfo IE in SIB8 discussed in the next paragraph, which is optional and subject 800
to dynamic transition between “sync mode” and “async mode” as GPS time is lost and 801
regained This is part of L84876. 802
803
804
Note: Periodically modifying the following IEs (e.g. per sib8Periodicity in MIM) is not 805
subject to System Information change notifications or modification of the SIB1 value tag: 806
- cdma2000-SystemTimeInfo (SIB8) 807
- oneXRTT-LongCodeState (SIB8) 808
- any IE of SIB11 809
810
4.2.6 CELL LOCK/UNLOCK 811
The operator has the possibility, from the OMC, to lock or unlock a cell, through 812
“administrativeState” attribute attached to LteCell object class. 813
When a cell is unlocked, it is set up and once the setup procedure is successfully 814
performed, telecom service is offered in the cell. 815
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 30/99
When a cell is locked, all established calls are immediately released and the resources 816
allocated to the cell are freed. In LA3.0 and beyond, this is performed through without a 817
reset of the modem board hosting those resources. Once the modem board has restarted, 818
the The cell will not be setup until the unlock command has been issued. As long as the 819
cell is locked, the cell is not radiating. 820
This administrative state is preserved through an eNB restart, so that a cell that has been 821
locked remains locked after the eNB restart. 822
823
4.2.7 FAILURE CASES 824
4.2.7.1 CELL SETUP FAILURE 825
Cell setup may fail, either because the modem board is not responding or is failing to 826
perform the cell setup procedure. In this case the managed object LteCell's state is 827
changed to Disabled/Failed. 828
If the modem board is not responding, no alarm is raised by CallP and no modem reset is 829
performed. When the modem has restarted, the cell setup procedure is attempted again. 830
If the cell setup procedure is failing in the modem board, it will raise a critical alarm 831
which will trigger its own reset. When the modem has restarted, the cell setup procedure 832
is attempted again. 833
The alarm shall be cleared if the error is removed later. 834
835
4.2.7.2 MODEM FAILURE 836
In the event of a modem failure (in other words a reset), the state of managed object 837
LteCell is changed to Disabled/Dependency. All established calls are released: RRC 838
resources are locally released (in other words no RRC message exchanges occur) and the 839
MME is notified via a UE Context Release Request message. 840
841
4.2.7.3 CELL BARRING DUE TO LOSS OF S1 SERVICES 842
After successful cell setup if S1 service (availability/ connectivity) on the last S1 link is lost 843
from either the eNB side or MME side due to faults or customer OAM actions, UEs in the eNB 844
coverage area attempting calls will keep failing unless the eNB declares all of its cells as 845
“barred” (changing cellAccessRelatedInfo.cellBarred=‘barred’ in SIB1). 846
For UEs in the vicinity of barred eNB coverage area, cell-barring allows the UEs to select 847
neighbor LTE cells on the same freq or perform inter-RAT mobility (if the feature is already 848
activated at the neighboring eNBs), limiting the service impact and corresponding KPI 849
degradation. 850
If LteCell::cellBarred = 'notBarredAutobarrable’, the eNB starts a timer per 851
Enb::cellBarringHysteresisTimer value when the last S1 link is lost and performs self-852
triggered cell barring when the timer expires without S1 link recovery by utilizing the DSIM/ 853
CNP procedure (see section 4.3.1 page 32). Once triggered, the eNB cease to handle any 854
calls including emergency calls. 855
With CR #269239 (interaction of Sys Info broadcast and S1 link status during cell setup): 856
• During cell setup the eNB starts Sys Info broadcast as soon as the cell starts radiating 857
while S1 links setup is being performed in parallel. LteCell is set to “Enabled/ off-duty” if 858
LteCell::cellBarred = ‘barred’ and to “Enabled/ none”, otherwise. 859
Commentaire [ADW16] : <Start: SRS-026072-290, Other>
Feature Number: L97933 Author: Jin Wang
<End: SRS-026072-290>
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 31/99
• If LteCell::cellBarred = 'notBarredAutobarrable’ and no S1 link is up when eNB starts Sys 860
Info broadcast, the eNB also starts the Enb::cellBarringHysteresisTimer. If at least one S1 861
link becomes in service prior to the timer expiry, the timer is cleared and LteCell remains 862
in “Enabled/ none”. Otherwise, the eNB auto-bars each cell that has LteCell::cellBarred 863
= 'notBarredAutobarrable’ via DSIM/ CNP and changes LteCell to “Enabled/ off-duty”. 864
865
The eNB will not perform cell barring in case all the MMEs have a capacity set to 0. In this 866
case, Calls for UE providing either S-TMSI or registeredMME in RRC Connection are always 867
accepted. 868
Open point : in LA3.0, RO MMEAccessGroup could be used to determine if there is at least 869
one S1 link available. OAM-C could set the OperState of RO MMEAccessGroup. 870
871
4.2.8 INTERACTIONS WITH OTHER FEATURES 872
With CR #269239 S1 link availability is not a pre-condition for Sys Info broadcast, i.e., 873
during cell setup the Sys Info is broadcast as soon as the cell starts radiating with LteCell 874
set to "Enabled/ none" or “Enabled/ off-duty” based on the settings of LteCell::cellBarred, 875
while the parallel S1 links setup is in progress (see the CR update in Section 4.2.7.3). 876
877
If all S1 links fail at a later stage, the cells shall remain set up and the eNB shall continue 878
to broadcast System Information. This allows the eNB to self-trigger cell-barring via 879
dynamic System Info modification as described in Section 4.2.7.3. 880
881
Commentaire [ADW17] : <Start: SRS-026072-300, Other>
Feature Number: CR #269239 Author: Jin Wang
<End: SRS-026072-300>
Commentaire [ADW18] : <Start: SRS-026072-190, Other>
Feature Number: CR 00269239 Author: Jin Wang
<End: SRS-026072-190>
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 32/99
4.3. PAGING 882
4.3.1 INTRODUCTION 883
Paging messages are sent over the PCCH logical channel. PCCH is mapped onto the PCH 884
transport channel, which itself is carried on the PDSCH physical channel. Transport format 885
and resource allocation for the PCH channel is signaled on the PDCCH channel, using the 886
dedicated P-RNTI (defined as 0xFFFE in [R5] TS 36.321). 887
PCCH uses RLC and MAC Transparent Mode, which implies that the RRC layer must perform 888
padding. 889
The moment at which a given UE can be paged in a paging frame (same length as a radio 890
frame) is called a Paging Occasion, as defined in [R4] TS 36.304. The paging occasion for a 891
given UE is calculated using the three following parameters: 892
- the UE_ID, equal to the UE IMSI modulo 1024. This is provided to the eNB in 893
the S1 Paging message by mandatory information element "UE Identity Index 894
Value", 895
- the DRX Paging Cycle; either the default value transmitted in the System 896
Information (defaultPagingCycle in SIB2), or the UE-specific value received in 897
the S1 Paging message if it is shorter. 898
- parameter nB, transmitted in the System Information (in SIB2), which defines a 899
sort of "paging occasion density" within a radio frame. 900
These three parameters participate in creating time diversity for the sending of paging 901
messages. In other words, they spread out in time the opportunities for paging and in this 902
way limit the scheduling conflicts while allowing the UEs to go into DRX mode and reduce 903
their power consumption. 904
The UE_ID splits the UE population into groups with identical paging occasions. All UEs 905
with the same UE_ID (defined as IMSI modulo 1024) shall be paged within the same unique 906
paging occasion. However a given paging occasion is always shared by at least four UE_ID 907
groups, and generally much more (in the "worst" case, all UEs share a single paging 908
occasion). 909
The DRX Paging Cycle defines the period over which paging messages will be spread. A 910
given UE will have one and only one paging occasion during the paging cycle; if the 911
occasion was missed (because the S1 Paging came after the occasion or because there 912
were too many paging records buffered for the given paging occasion), the eNB will have 913
to buffer the “spill-over” paging records until the next paging cycle. The length of the 914
paging cycle is a trade-off between mobile terminating call establishment performance on 915
the one hand (the shorter the cycle the sooner the mobile will be paged) and paging 916
capacity on the other hand (the longer the cycle, the more paging occasions there will be). 917
The per-UE DRX Paging Cycle may be set to 32, 64, 128, or 256 radio frames (note that this 918
parameter is called "T"in [R4] TS 36.304). 919
Parameter nB is expressed as a multiple or divisor of the paging cycle: it defines the ratio 920
of paging occasions to the number of radio frames. It is defined as an enumerated taking 921
its values in the following range: {fourT, twoT, oneT, halfT, quarterT, oneEighthT, 922
oneSixteenthT, oneThirtySecondT}. Note that in LA3.0, in order to allow fixed VoIP and 923
PCCH bandwidth allocation (see [A5] for more details), a maximum of 1 paging sub-frame 924
per frame is supported; this implies that values "fourT", "twoT" and "oneT" are not 925
permitted for nB in LA3.0. If for example nB is set to "twoT", there will be two paging 926
occasions in each radio frame; if it is set to "quarterT", there will be one paging occasion 927
every four radio frames. The trade-off here is between radio resources (the smaller the nB 928
is, the less radio resources may be consumed by paging) and paging capacity (the bigger 929
the nB, the more paging occasions there are for a given paging cycle). 930
931
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 33/99
0
1
2
3
1022
1023
IMSIs
(up to 1021
values)
mod 1024
UE_ID
0
1
n-1
n
Paging Occasions (*):
1 to 1024
(*): depends on the DRX
Paging Cycle and nB 932
Figure 11: From IMSI to a paging occasion 933
934
A paging occasion for a given UE occurs within a given radio frame (referred to as a "paging 935
frame") at a given subframe number. 936
The paging frame for a given UE is characterized by: 937
SFN mod T = (T div N) * (UE_ID mod N) 938
The subframe number of a given UE's paging occasion is retrieved from a table using the 939
index i_s defined as follows: 940
i_s = floor(UE_ID / N) mod Ns 941
The previous formulas use the following parameters: 942
T is the DRX Paging Cycle, expressed in numbers of radio frames. The DRX Paging Cycle is 943
either parameter defaultPagingCycle broadcast in SIB2, or the UE-specific value received 944
in the S1 Paging message if it is shorter (pagingDRX optional information element). Its 945
values are in range {32, 64, 128, 256}. 946
nB is the parameter broadcast in SIB2, taking its values in the range {4T, 2T, T, T/2, T/4, 947
T/8, T/16, T/32}. 948
N is equal to min(T, nB). N defines the number of frames within the paging cycle that will 949
be used for paging, or in other words, the number of paging frames. With the different 950
possible values for T and nB, this may be as little as 1 or can represent all the radio frames 951
within the paging cycle. 952
Ns is equal to max(1, nB/T); given the definitions for T and nB, Ns is therefore in the range 953
{1,2,4}. Ns defines the number of subframes used as paging occasions within a paging 954
frame. 955
UE_ID is equal to IMSI mod 1024, provided to the eNB in the S1 Paging message by 956
mandatory information element "UE Identity Index Value". 957
Index i_s allows looking up in the following table the subframe number depending on the 958
value of Ns. 959
Ns \ i_s 0 1 2 3
1 9 NA NA NA
2 4 9 NA NA
4 0 4 5 9
960
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 34/99
Once the paging occasion has been determined, the ue-Identity (referred to as "UE Paging 961
ID" in the S1 Paging message) and pagingCause are buffered until the time comes for the 962
paging frame and associated subframe pointed to by the paging occasion. 963
When this moment arrives, a maximum of 16 paging records buffered for this paging 964
occasion may be encoded in an RRC Paging message. This will be the responsibility of the 965
DL scheduler. 966
A paging message may also contain a notification of system information change. 967
968
ENB supports dynamic System Info modification (DSIM) using Change Notification Paging 969
(CNP) (Refer to section 4.2.4). For each Paging Occasion (PO) in a paging frame over a full 970
paging cycle, the optional systemInfoModification flag in the Paging message is sent as a 971
standalone page if the PO has no S1-based page records, and is piggybacked with S1 page 972
records, otherwise. 973
Since all UEs in RRC Idle and RRC Connected need to be notified about an upcoming 974
change in System Info, CNP needs to be applied to each and every PO in a paging cycle. 975
This means the eNB can use the defaultPagingCycle and other pre-change parameters nB, 976
Ns etc to determine all the POs without the need to know the UEs IMSIs (in fact the eNB 977
does not know idle UEs IMSIs anyway). 978
As per 3GPP 36.304 (ref [R4]), a UE may provide a per-UE DRX shorter than the 979
defaultPagingCycle of the cell, in this case, this DRX value will be provided to the 980
scheduler. The per-UE DRX paging cycle has to be ½ to 1/32 of the defaultPagingCycle. 981
The UE will wake up two or more times within the defaultPagingCycle to listen to a page 982
destined for it, and one of them will coincide with the PO calculated using the 983
defaultPagingCycle. 984
985
986
4.3.2 PAGING PROCEDURE 987
Upon receiving a Paging message on the S1 interface, the eNB determines the list of cells 988
on which to page the UE from the TAIList IE in the S1 Paging message. 989
For each cell on which the UE must be paged, the CallP shall: 990
- compute the frame number and subframe number of the UE's paging occasion, 991
- encode the paging record for the given UE, 992
- send this data to the Scheduler along with the paging cycle to be used 993
994
4.3.2.1 FRAME AND SUBFRAME COMPUTATION 995
Computing the frame and subframe number will use the following inputs: 996
- the UEIdentityIndexValue received in the S1 Paging message, hereafter 997
referred to as the UE_ID, 998
- the DRX Paging Cycle, hereafter referred to as the drxPagingCycle and 999
expressed in number of radio frames, which shall be either the pagingDRX IE if 1000
received in the S1 Paging message, or the default value from the MIM 1001
(defaultPagingCycle in object Enb) which is used to populate the 1002
defaultPagingCycle in SIB2, 1003
- parameter nB of the MIM (nB in object LteCell), which is also used in SIB2. 1004
1005
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 35/99
The frame number shall be calculated as follows: 1006
frameNumber = (drxPagingCycle div min(drxPagingCycle, nB) * (UE_ID mod 1007
min(drxPagingCycle, nB) 1008
Note that this frame number is relative to the DRX Paging Cycle, therefore the CallP must 1009
provide value of the DRX Paging Cycle along with the frame number for it to be significant. 1010
The subframe number shall be the one pointed by index i_s, which is calculated as follows: 1011
i_s = floor(UE_ID / min(drxPagingCycle, nB)) mod max(1, nB/drxPagingCycle) 1012
The subframe number will be taken from the following table, indexed both by i_s and by 1013
Ns = max(1, nB/drxPagingCycle). 1014
Table 2: Paging occasion subframe number 1015
Ns \ i_s 0 1 2 3
1 9 NA NA NA
2 4 9 NA NA
4 0 4 5 9
1016
4.3.2.2 ENCODING OF THE PAGING RECORD 1017
CallP shall perform the ASN1 encoding of a single paging record, defined as the following 1018
ASN1 type: 1019
SEQUENCE { ue-Identity PagingUE-Identity, 1020
cn-Domain ENUMERATED {ps, cs}, 1021
...} 1022
CallP will use the UEPagingID and CNDomain received in the S1 Paging message to encode 1023
the ue-Identity and cn-Domain. 1024
1025
Once frame and subframe number have been computed, and the paging record encoded, 1026
CallP shall send these along with the DRX paging cycle used in the computations to the 1027
Scheduler (the DRX paging cycle used is either the UE-specific one received in the S1 1028
Paging message or the default paging cycle taken from MIM that is also broadcast in SIB2). 1029
The message sent from CallP to Scheduler shall therefore contain the following 1030
parameters: 1031
- frame number within the DRX paging cycle at which the Paging must be sent, 1032
- subframe number within the radio frame at which the Paging must be sent, 1033
- length of the DRX paging cycle, expressed in number of frames, 1034
- paging record length in bits, 1035
- paging record ASN1-encoded. 1036
1037
4.3.2.3 SCHEDULER BEHAVIOR 1038
Refer to [A5] for detailed Scheduler behavior. Hereafter is a brief summary. 1039
The Scheduler will compute the next SFN that matches the frame number provided by 1040
CallP given the DRX paging cycle. The paging record will be stored in a FIFO buffer 1041
associated to the computed SFN and subframe number provided by CallP. 1042
Commentaire [ADW19] : <Start: SRS-026072-150, Other>
Feature Number: L92025 / L92026
Author: Jean-Michel Pugeat <End: SRS-026072-150>
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 36/99
Paging records may be stored for a given SFN / subframe couple up to 1 millisecond before 1043
its occurrence in time. 1044
At 1 millisecond prior to the occurrence of SFN and subframe, content of the Paging 1045
message will be frozen and encoded. If there are no UEs to page at the SFN / subframe 1046
occasion, any reserved resources shall be released. Otherwise the Scheduler will 1047
concatenate an RRC Paging message header and up to 16 paging records in order to 1048
constitute the RRC Paging message that will be sent. Bits of padding (set to 0) will be 1049
added for octet-alignment of the RRC Paging message, as well as for alignment to the 1050
chose resource block size. 1051
Details of how the RRC Paging message shall be assembled are provided in Annex C. 1052
1053
1054
4.4. S1 SETUP 1055
The S1 setup procedure consists of: 1056
- S1 SCTP association setup procedure described in[A8]. 1057
- S1-AP S1 setup procedure described in this section. 1058
1059
4.4.1 PREREQUISITES 1060
The S1 SCTP association must be successfully set up, either at eNB startup or following an 1061
S1 link failure. 1062
1063
4.4.2 SUCCESSFUL CASE 1064
The purpose of the S1 Setup procedure is to exchange application level data needed for 1065
the eNB and MME to interoperate correctly over the S1 interface. 1066
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 37/99
ENB MME
S1 SCTP Association is set up
ENB MME
S1 SETUP RESPONSE
MME NameServed GUMMEIs (1 to 8)>Served PLMNs (1 to 32)
>>PLMN Identity>Served GroupIDs (1 to 16)
>>MME GroupID>Served MMECs (1 to 16)
>>MME Code Relative MME Capacity
Criticality Diagnostics
S1 SETUP REQUEST
Global eNB IDeNB NameSupported TAs (1 to 256)>TAC>Broadcast PLMNs (1 to 6) >>PLMN IdentityDefault paging DRX
1067
1068
Figure 12: S1 Setup Success 1069
The eNB initiates the procedure by sending a S1 SETUP REQUEST message including its own 1070
configuration data to the MME. This message shall be the first S1AP message sent after the 1071
TNL association has become operational, i.e. the S1 SCTP association is successfully setup 1072
as specified in [A8]. 1073
The MME responds with S1 SETUP RESPONSE including its own configuration data. 1074
The received data shall be stored in the eNB and used for the duration of the TNL 1075
association. It may be updated by a subsequent MME Configuration Update procedure. It 1076
shall not be erased during a Reset procedure. When this procedure is finished S1 interface 1077
is operational and other S1 messages can be exchanged; in particular, calls can be set up. 1078
The maximum number of Served GroupIDs and Served MMECs are defined in standard with 1079
values respectively 65536 and 256. To avoid memory consumption, the eNB will limit the 1080
number of saved information to 16 Served GroupIDs and 16 Served MMECs. In LTE 1081
networks, one MME should support only one GroupID and one MME code. The potential 1082
issue is with configuration data received for other RATs (2G or 3G) which may exceed our 1083
design values. If more than 16 instances of Served GroupIDs and Served MMECs are 1084
received, they will be ignored by eNB, only the first ones will be stored by eNB. 1085
Please note that according to 3GPP TS 36.413, LTE served group will always be found at 1086
the first place in the list of groups provided by the MME in S1 SETUP RESPONSE. 1087
In case there is at least one X2 instance setup already, on reception of a S1 Setup 1088
Response message from a MME, an eNB shall compute the GU Group ID List (see section 1089
4.13.3.1). 1090
A S1 Setup procedure clears the MME overload action (Not in LA3.0). 1091
1092
Commentaire [ADW20] : <Start: SRS-026072-340, Other>
Feature Number: L101845 Author: M. Gateau
<End: SRS-026072-340>
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 38/99
4.4.3 FAILURE CASES 1093
4.4.3.1 S1 SETUP FAILURE 1094
1095
ENB MME
S1AP S1 SETUP REQUEST
MME rejects the setup procedure by sendingS1 SETUP FAILURE
ENB MME
S1 SETUP FAILURE
Cause (M)TimeToWait (O)
CriticalityDiagnostics(O)
S1AP S1 SETUP REQUEST
set s1SetupTimer
set timer T
set s1SetupTimer
if TimeToWait (O) wasn’t present, set timer T with a duration randomly chosen
among possible values
if TimeToWait (O) has been received, set timer T with
duration TimeToWait
ENB resends S1 SETUP REQUEST to the MME until it is successfulAfter three consecutive failures, an alarm is raised to SAM
(The alarm is cleared when the S1 Setup is successful and on SCTP shutdown)
S1 SCTP Association is set up
stop s1SetupTimer
timer T expires
1096
1097
Figure 13: S1 Setup Failure 1098
1099
In case of encoding issue of S1 Setup message, due for example to an incorrect parameter, 1100
an alarm MME_S1_SETUP_REQUEST_NOT_SENT is raised. This alarm is cleared when the S1 1101
Setup is successful and on SCTP shutdown. 1102
Commentaire [ADW21] : <Start: SRS-026072-410, Other>
Feature Number: CR #321636 / CR #325845
Author: Wang Yunhua / Martine Gateau <End: SRS-026072-410>
Commentaire [ADW22] : <Start: SRS-026072-500, Requirement>
Feature Number: CR #325845 <End: SRS-026072-500>
Commentaire [ADW23] : <Start: SRS-026072-510, Requirement>
Feature Number: CR #323751 <End: SRS-026072-510>
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 39/99
4.4.3.2 NO RESPONSE TO S1 SETUP 1103
1104
ENB MME
ENB MME
S1AP S1 SETUP REQUEST
S1AP S1 SETUP REQUEST
set s1SetupTimer
set s1SetupTimer
S1 SCTP Association is set up
s1SetupTimer expires
ENB resends S1 SETUP REQUEST to the MME until it is successfulAfter three consecutive failures, an alarm is raised to SAM
(The alarm is cleared when S1 Setup is successful and on SCTP shutdown)
1105
1106
Figure 14: No Response To S1 Setup 1107
1108
4.4.3.3 S1 LINK FAILURE 1109
S1 Link failures are detected at SCTP level as described in [A8] and reported via a state 1110
change notification: the underlying MMETransportLayerAccess object becomes 1111
Disabled/Failed. The MMEAccess object state becomes Disabled/Dependency and remains 1112
so while the SCTP association is down. 1113
When the SCTP association is reestablished, the eNB will trigger a new S1 Setup procedure 1114
as specified in section 4.4.2. 1115
If calls are ongoing for the associated MME when the S1 link failure occurs, S1 resources 1116
associated to the calls are locally released (in other words without any S1 messages 1117
exchanged) and the UE are notified via an RRC Connection Release procedure. More details 1118
can be found in [A1]. 1119
1120
4.4.4 S1 FLEX 1121
S1 Flex describes the ability for the eNB to be connected to more than one MME; up to 16 1122
in LA3.0. When the eNB is connected to several MMEs, it must select one MME to establish 1123
an S1 link for a given UE. 1124
Commentaire [ADW24] : <Start: SRS-026072-420, Other>
Feature Number: CR #321636 / CR #325845
Author: Wang Yunhua / Martine Gateau <End: SRS-026072-420>
Commentaire [ADW25] : <Start: SRS-026072-490, Requirement>
Feature Number: CR #325845 <End: SRS-026072-490>
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 40/99
Details of the MME selection process are found insection 4.15. 1125
When the eNB is connected to several MME, the S1 Setup procedures will be triggered as 1126
soon as the SCTP association for each MME is available, and may therefore happen in 1127
parallel. They may also run in parallel to X2 Setup procedures. The relative MME capacity 1128
received during the setup procedure will be stored for future use at call establishment, as 1129
specified in[A1]. 1130
Once an S1 connection is set up successfully and System Info broadcasting starts, calls can 1131
be setup through the S1. S1 links can subsequently be lost due to various reasons. If the 1132
last S1 connection on the eNB is lost, the eNB triggers cell-barring as described in Section 1133
4.2.7.3. When any S1 link is recovered, the cells are un-barred. 1134
1135
4.4.5 INTERACTIONS WITH OTHER FEATURES 1136
S1 management has interactions with call setup and inter-eNB handover: 1137
- Call setup interactions: 1138
- when all S1 links are not operational (all MmeAccess managed objects are 1139
in a state different from Enabled/None), RRC connection attempts are 1140
rejected using RRC Connection Reject message 1141
- Inter-eNB handover interactions: 1142
- when the S1 link to the MME designated by the GUMMEI information 1143
element in the X2 Handover Request is not operational, the eNB shall 1144
reject the handover request using Handover Preparation Failure 1145
1146
1147
4.4.6 S1 LINK LOCK/UNLOCK 1148
An S1 link can be locked or unlocked through administrativeState attribute attached to 1149
MMEAccess object instance. 1150
An unlocked S1 link will be established and allowed to operate. 1151
A locked S1 link will not be established. 1152
Note: “shuttingdown” value is not currently supported. 1153
1154
Following chapters specify eNB behavior on transitions from “unlock to lock” and “lock to 1155
unlock”. 1156
1157
4.4.6.1 BEHAVIOR WHEN LOCKING AN S1 LINK 1158
Locking an S1 link is performed by setting MMEAccess administrativeState to “locked”. 1159
In this case, if the S1 link was established, it has to be released. Underlying SCTP 1160
association does not need to be released itself, however, as the only way to release S1 link 1161
is to release also SCTP, when S1 lock command is received, the eNB will shutdown 1162
underlying SCTP association. 1163
As long as S1 link is locked, S1 link will not be established (meaning S1 setup procedure 1164
will not be triggered). 1165
A SCTP INIT may not be received from the MME. MME shall send a SCTP INIT only in case of 1166
MME failure, for redundancy purpose. 1167
Commentaire [ADW26] : <Start: SRS-026072-270, Other>
Feature Number: L113614 (TLA3.0) / L108282 (LA3.0)
Author: Yunhua Wang <End: SRS-026072-270>
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 41/99
1168
4.4.6.2 BEHAVIOR WHEN UNLOCKING AN S1 LINK 1169
Unlocking an S1 link is performed by setting MMEAccess administrativeState to 1170
“unlocked”. 1171
In this case, it shall be established through S1 setup procedure. Of course, underlying SCTP 1172
association shall be established beforehand if not already up. 1173
1174
4.4.7 S1 ONLINE CREATION 1175
Open point: to be updated for LA3.0 with L108282. Post LA2.0, it is now possible to create 1176
online an MMEAccess instance along with its underlying MMETransportLayerAccess instance 1177
(MMETransportLayerAccess cardinality ensures that if an MMEAccess instance is created, 1178
then associated MMETransportLayerAccess instance will also be). 1179
eNB behavior on MMEAccess instance creation will be: 1180
- If S1 link is unlocked, it will be established 1181
- If S1 link is locked, it will not be established 1182
1183
4.4.8 S1 ONLINE DELETION 1184
Open point: to be updated for LA3.0 with L108282. Post LA2.0, it is also possible to delete 1185
online an MMEAccess instance along with its underlying MMETransportLayerAccess 1186
instance. 1187
eNB behavior in case of S1 link deletion will be 1188
- If S1 link was established, it will be released through SCTP shutdown 1189
- If it was not, it will be simply removed from the MIB 1190
1191
1192
4.5. S1 MME CONFIGURATION UPDATE 1193
The purpose of the MME Configuration Update procedure is to update application level 1194
configuration data needed for the eNB and MME to interoperate correctly on S1 interface. 1195
This procedure doesn’t affect existing UE-related contexts, if any. 1196
S1 MME Configuration procedure can’t be deactivated; it is not related to an activation 1197
flag (CR #344432). 1198
1199
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 42/99
4.5.1 SUCCESSFUL CASE 1200
ENB MME
ENB MME
MME CONFIGURATION UPDATE
MME NameServed GUMMEIs (1 to 8)>Served PLMNs (1 to 32)
>>PLMN Identity>Served GroupIDs (1 to 16)
>>MME GroupID>Served MMECs (1 to 16)
>>MME Code Relative MME Capacity
MME CONFIGURATION UPDATE ACKNOWLEDGECriticality Diagnostics
1201
Figure 15: MME Configuration Update Success 1202
The MME initiates the procedure by sending a MME CONFIGURATION UPDATE message 1203
including the appropriated updated configuration data to each of the eNBs currently 1204
connected with it. 1205
The eNB responds with MME CONFIGURATION UPDATE ACKNOWLEDGE message to 1206
acknowledge that it has successfully updated the configuration data. 1207
The received data shall be stored in the eNB and used for the duration of the TNL 1208
association until reception of a new MME Configuration Update message. It shall not be 1209
erased during a Reset procedure. 1210
If top-level information element(s) is/are not included in the MME Configuration Update 1211
message, the eNB shall interpret that the corresponding configuration data is/are not 1212
changed and shall continue to operate the S1 with the existing related configuration data. 1213
The following configuration data can be updated: 1214
- MME Name: if present it shall be stored by the eNB and used as a human readable 1215
name of the MME, e.g. for alarms. 1216
- Served GUMMEIs: the eNB shall store the Served GUMMEIs and use the first on the 1217
list for L97982 purpose. Per June-2009 36.413 the first one in the list relates to LTE 1218
configuration pool and the rest relate to 2G/3G pools (for example if a UE was in 3G 1219
connected to a pool of "combined" 3G SGSN/ MME and then moves to LTE, eNB 1220
would select the same combined node if possible). The eNB shall compute the GU 1221
Group Id List based on the GUMMEI information received from the MME (see section 1222
4.13 Support of MME group for more details). 1223
- Relative MME Capacity: the new MME Capacity received from MME shall be stored by 1224
the eNB. 1225
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 43/99
In case there is at least one X2 instance setup already, on reception of a MME 1226
Configuration Update message from a MME, an eNB shall compute the GU Group ID List 1227
(see section 4.13.3.1) 1228
It’s possible that the Relative MME Capacity is changed to a lower value or even to 0. 1229
• For new calls, the new Relative MME Capacity info will be taken into account in MME 1230
selection; 1231
• For existing calls, the MME can take CAC action (see above); 1232
• For S1-based HOs, no MME relocation is performed as long as target eNB has S1 1233
connectivity with MME. The decision to perform MME relocation in case there is no 1234
connectivity or in overload condition is MME dependant. If the Target eNB receives an 1235
HO Request message from an MME (with or without MME relocation), it will respond to 1236
the message and let the MME decide whether to reject the HO or not. 1237
Relative MME capacity set to 0 means some OAM action was taken on the MME (e.g. for 1238
maintenance) and ALU MME will, over a time window, gradually release RRC Connected 1239
UEs (not in emergency calls) by sending UE Context Release Request messages to the UEs 1240
via the eNB with the Cause IE set to 'Load Balancing TAU Required'; the affected UEs send 1241
TAU in response. A different MME (if available) is then selected. Other vendor’s MME may 1242
or may not do this. 1243
The configuration received for non supported PLMNs shall be ignored by eNB. 1244
1245
4.5.2 FAILURE CASES 1246
ENB MME
ENB MME
MME CONFIGURATION UPDATEMME Name
Served GUMMEIs (1 to 8)>Served PLMNs (1 to 32)
>>PLMN Identity>Served GroupIDs (1 to 16)
>>MME GroupID>Served MMECs (1 to 16)
>>MME Code Relative MME Capacity
MME CONFIGURATION UPDATE FAILURE
Cause
Time To Wait
Criticality Diagnostics
1247
Figure 16: MME Configuration Update Failure 1248
1249
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 44/99
If the eNB can not accept the update or it encounters problems such as ASN1 decoding 1250
errors, it shall respond with an MME CONFIGURATION UPDATE FAILURE message: 1251
- In case none of the PLMN provided by MME matches with supported PLMN(s) of the eNB, it 1252
shall reject the MME Configuration Update procedure with cause “Unknown PLMN”, Time 1253
to wait set to MMEConfigurationUpdateTimeToWait hardcoded value, e.g. 60s (maximum 1254
value allowed as this case is relevant to an incoherent configuration). 1255
4.6. S1 ENB CONFIGURATION UPDATE 1256
The purpose of the S1AP ENB Configuration Update procedure is to update application 1257
level configuration data needed for the eNB and MME to interoperate correctly on S1 1258
interface. This procedure doesn’t affect existing UE-related contexts, if any. 1259
1260
4.6.1 SUCCESSFUL CASE 1261
ENB MME
ENB MME
ENB CONFIGURATION UPDATE ACKNOWLEDGE
Criticality Diagnostics
ENB CONFIGURATION UPDATE
Supported TAs (0 to 256)>TAC>Broadcast PLMNs (1 to 6)>>PLMN IdentityCSG Id List (0 to 256)>CSG IdDefault paging DRX (optional)
1262
1263
eNB behavior 1264
To allow dynamic update of the Tracking Area codes, the MIM parameter LteCell-1265
>trackingAreaCode needs to be a Class C parameter, In case of update of TAC values, the 1266
eNB is expected to provide the new list of Supported TAs including updated TAC values to 1267
all MMEAccess instances in oper/none status, using the S1 eNB CONFIGURATION UPDATE 1268
procedure. The whole list of supported TAs including those that are not to be updated 1269
shall be included in the Supported TAs IE. The S1AP ENB CONFIGURATION UPDATE message 1270
shall be sent concurrently to all MMEs with an operational S1 link: MME Access in 1271
Enabled/None state. 1272
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 45/99
Update of Broadcast PLMNs, CSG Id List and Default paging DRX is not supported in 1273
LA3.0.The eNB may initiate a further eNB Configuration Update procedure only after a 1274
previous eNB Configuration Update procedure has been completed 1275
In case of TAC change, DSIM modification shall be performed in parallel with configuration 1276
update on S1 and X2 interfaces: as per 36.413 ref [R6], even in case of ENB Configuration 1277
Update Failure, both node shall continue to operate the S1 with their respective 1278
configuration data. 1279
Enb->defaultPagingCycle is a class B parameter. In case OAM-C notifies both changes of 1280
Enb->defaultPagingCycle and LteCell->TrackingAreaCode in the same transaction, TAC list 1281
and default paging cycle shall be updated using same S1AP ENB CONFIGURATION UPDATE 1282
procedure. 1283
4.6.2 FAILURE CASES 1284
4.6.2.1 S1 ENB CONFIGURATION UPDATE FAILURE 1285
If the MME can not accept the update it shall respond with an eNB CONFIGURATION 1286
UPDATE FAILURE message and appropriate cause value. 1287
If the eNB CONFIGURATION UPDATE FAILURE message includes the Time To Wait IE the eNB 1288
shall wait at least for the indicated time before reinitiating the eNB Configuration Update 1289
procedure towards the same MME. Both nodes shall continue to operate the S1 with the 1290
existing configuration data. 1291
1292
eNB behavior 1293
Upon reception of the S1 eNB Configuration Update Failure, the eNB shall set a timer at 1294
least equal to either the Time To Wait information element if it was received, or to a 1295
random S1TimeToWait value chosen among the range of values allowed by the standard. 1296
The standard allows following values “v1s, v2s, v5s, v10s, v20s, v60s", a random value may 1297
be chosen in any range between two values, e.g. range [1..2] for value v1s, range [60..80] 1298
for value v60s) . 1299
Once this timer expires, the eNB may trigger a new S1 eNB Configuration Update 1300
procedure by sending the S1 eNB CONFIGURATION UPDATE message. 1301
The eNB will retry the S1 eNB Configuration Update procedure S1ConfigurationUpdateRetry 1302
times (hard coded value set to 3). In case there is no successful answer after the retries, 1303
the eNB will shut down S1 connection and restart the S1 Setup procedure. It will send an 1304
event “MME-S1-ENB-Configuration-Update-Failure-Response” to notify the issue to the 1305
operator. 1306
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 46/99
ENB MME
ENB MME
ENB CONFIGURATION UPDATE FAILURE
CauseTime To Wait
Criticality Diagnostics
ENB CONFIGURATION UPDATE
Supported TAs (0 to 256)>TAC>Broadcast PLMNs (1 to 6)>>PLMN IdentityCSG Id List (0 to 256)>CSG IdDefault paging DRX (optional)
1307
1308
Figure 17: S1 eNB Configuration Update Failure 1309
4.6.2.2 NO RESPONSE TO S1 ENB CONFIGURATION UPDATE 1310
If the eNB after initiating eNB Configuration Update procedure receives neither eNB 1311
CONFIGURATION UPDATE ACKNOWLEDGE message nor eNB CONFIGURATION UPDATE 1312
FAILURE message, the eNB may reinitiate the eNB Configuration Update procedure towards 1313
the MME, provided that the content of the new eNB CONFIGURATION UPDATE message is 1314
identical to the content of the previously unacknowledged eNB CONFIGURATION UPDATE 1315
message. 1316
When the eNB sends an eNB Configuration Update message, it sets an internal timer that is 1317
stopped if either eNB Configuration Update Acknowledge or eNB Configuration Update 1318
Failure messages are received. If this timer expires, the eNB may trigger a new S1 eNB 1319
Configuration Update procedure by sending the S1 eNB CONFIGURATION UPDATE message. 1320
The eNB will retry the S1 eNB Configuration Update procedure S1ConfigurationUpdateRetry 1321
times (hard coded value set to 3). In case there is no successful answer after the retries, 1322
the eNB will shut down S1 connection and restart the S1 Setup procedure. It will send an 1323
event “MME-S1-ENB-Configuration-Update-No-Response” to notify the issue to the 1324
operator. 1325
1326
The ENB Configuration Update may be successfully acknowledged by some MMEs and failed 1327
by others. As per TS 36.413 ref [R6], in case of failure or no reponse, both nodes shall 1328
continue to operate with their respective configuration. 1329
DSIM operation shall be performed normally. 1330
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 47/99
1331
1332
1333
ENB MME
ENB MME
ENB CONFIGURATION UPDATE
ENB CONFIGURATION UPDATEset
S1ENBConfiguration
UpdateTimer
set
S1ENBConfiguration
Update Timer
S1ENBConfiguration
UpdateTimer expires
ENB resends ENB CONFIGURATION UPDATE to MME(3 retries maximum)
1334
Figure 18: No Response to S1 eNB Configuration Update 1335
1336
4.7. S1 RESET 1337
The purpose of the Reset procedure is to initialize or re-initialize the E-UTRAN, or part of 1338
E-UTRAN S1AP UE-related contexts, in the event of a failure in the EPC or vice versa. This 1339
procedure doesn’t affect the application level configuration data exchanged during the S1 1340
Setup procedure. 1341
The procedure uses non-UE associated signaling. 1342
1343
Commentaire [ADW27] : <Start: SRS-026072-330, Other>
Feature Number: L97980 Author: M. Gateau
<End: SRS-026072-330>
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 48/99
4.7.1 S1 RESET PROCEDURE MME INITIATED 1344
ENB MME
ENB MME
RESET
CauseReset Type
> S1 interface>> Reset All
> Part of S1 interface>> UE associated logical S1-connection list
>>> MME UE S1AP ID>>> ENB UE S1AP ID
RESET ACKNOWLEDGE
>> UE associated logical S1-connection list>>> MME UE S1AP ID>>> ENB UE S1AP IDCriticality Diagnostics
UE
UE
RRCConnectionRelease
1345
Figure 19: Reset procedure MME initiated 1346
1347
1348
Depending on Reset type, the eNB shall release all allocated resources on S1 and Uu 1349
related to the UE associations of this MME interface or only the resources related to the 1350
UE-associated logical S1-connection list provided in Reset message (case of partial reset). 1351
In case of partial reset, the UE associations to be released are identified with 1352
MME_UE_S1AP_ID and/or eNB-UE_S1AP_ID. 1353
In both cases, it has to release for all concerned UE-associated logical S1-connections the 1354
related UE contexts and S1 AP IDs, and release of radio resources (RRC connections)). 1355
1356
It shall answer to MME with a RESET ACKNOWLEDGE message including each UE association 1357
to be reset in the same order as received in the RESET, including also unknown UE 1358
associations (partial RESET case). 1359
If the RESET message contains the Reset All IE, then the eNB shall not include the UE-1360
associated logical S1-connection list IE in the RESET ACKNOWLEDGE message. 1361
The eNB doesn’t need to wait for the release of all radio resources to be completed before 1362
returning the answer. 1363
1364
However, before answering to the MME, the eNB shall remove all the MME_UE_S1AP_IDs in 1365
the contexts related to the concerned UE-associated logical S1-connections. This will 1366
remove in eNB all the concerned MME_UE_S1AP_IDs and allow to accept new calls 1367
immediately after towards this MME and it will be able to reuse these MME_UE_S1AP_IDs 1368
on reception of the RESET ACKNOWLEDGE message. 1369
Commentaire [gme28] : Clarified in 36.413 CR R3-100126 ENB already compliant in LA2.0
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 49/99
S1 configuration received in S1 Setup procedure or subsequent MME configuration update 1370
procedures shall be kept. 1371
The S1 reset procedure aborts all other ongoing procedures (except another reset 1372
procedure) on the same S1 interface related to a UE association. Common procedures (e.g. 1373
MME Configuration Update) are not impacted. 1374
1375
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 50/99
4.7.2 S1 RESET PROCEDURE ENB INITIATED 1376
In the event of a failure at the eNB, which has resulted in the loss of some or all 1377
transaction reference information, a RESET message shall be sent to the MME. 1378
1379
ENB MME
ENB MME
RESET ACKNOWLEDGE
UE-associated logical S1-connection list (1 to 256)> UE-associated logical S1-connection Item
>> MME UE S1AP ID>> ENB UE S1AP IDCriticality Diagnostics
RESETCauseChoice Reset Type> S1 interface>> reset all> Part of S1 interface>> UE-associated logical S1-connection list (1 to 256)>>> UE-associated logical S1-connection Item>>>> MME UE S1AP ID>>>> ENB UE S1AP ID
1380
Figure 20: Reset procedure eNB initiated 1381
1382
In case of reset of one CEM board, the eNB shall be able to send to MME a partial S1 1383
interface reset with the list of UE associated to this CEM board. 1384
In case multi-MME load balancing is supported, the UE supported by one CEM board may be 1385
associated to different MMEs. eNB shall send Reset messages to all MMEs supporting the UE 1386
associations. 1387
The eNB shall use the MME UE S1AP ID IE and/or the eNB UE S1AP ID to explicitly identify 1388
the UE association(s) to be reset. 1389
It shall handle the RESET ACKNOWLEDGE message received from MME. 1390
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 51/99
4.8. S1 OVERLOAD START (NOT IN LA3.0/TLA3.0) 1391
The purpose of the Overload Start procedure is to inform an eNB to reduce the signaling 1392
load towards the concerned MME. 1393
The procedure uses non-UE associated signaling. 1394
1395
ENB MME
ENB MME
OVERLOAD START
Overload Response
> Overload Action
1396
Figure 21: Overload Start 1397
1398
Based on Overload Action IE in the OVERLOAD START message, the eNB shall ensure that 1399
only signaling traffic corresponding to permitted RRC connections is sent to the MME and 1400
release non permitted RRC connections (see document [A1] for details). 1401
When receiving an OVERLOAD START message, the eNB shall store the overload action IE in 1402
MME Access List. 1403
If an S1AP OVERLOAD START message is received whereas there is already an ongoing 1404
overload reduction action (S1AP OVERLOAD START message already received), the eNB 1405
shall replace the overload action in MME Access List by the new requested one. 1406
New entering calls, for which no S-TMSI or registeredMME is provided or provided MME 1407
doesn’t match with a known MME, shall not be established towards an overloaded MME. An 1408
overloaded MME shall not be selected by MME selection algorithm (see section 4.15). 1409
1410
Interaction with other procedures: 1411
Handovers are not impacted by Overload procedure: any S1 or X2 Handover related to an 1412
overloaded MME are handled normally. 1413
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 52/99
Mapping performed between overload action and RRCConnection establishment cause 1414
values can be find in document ref [A1]. 1415
1416
1417
4.9. S1 OVERLOAD STOP (NOT IN LA3.0/TLA3.0) 1418
The purpose of the Overload Stop procedure is to signal to an eNB that the overload 1419
situation of a MME has ended and normal operation shall resume. 1420
The procedure uses non-UE associated signaling. 1421
1422
ENB MME
ENB MME
OVERLOAD STOP
1423
Figure 22: Overload Stop 1424
The eNB receiving the OVERLOAD STOP message shall assume that the overload situation at 1425
the MME from which it receives the message has ended and shall resume normal operation 1426
towards this MME. 1427
When receiving an OVERLOAD STOP message, the overload action shall be reset in MME 1428
access List. 1429
1430
1431
1432
4.10. X2 SETUP 1433
X2 Setup is conditioned to the administrative state of the associated X2Access object , to 1434
the black-listing status of the associated X2Access object, and to the availability of the X2 1435
SCTP association. It is therefore completely independent of both: 1436
- the cell setup procedure, whose status is given by the operationalState and 1437
availabilityStatus of objects LteCell; 1438
Commentaire [ADW29] : <Start: SRS-026072-350, Other>
Feature Number: L101845 Author: M. Gateau
<End: SRS-026072-350>
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 53/99
- the S1 interface setup procedure, whose status is given by the operationalState and 1439
availabilityStatus of objects MmeAccess. 1440
In the following sections, the "initiating eNB" refers to the eNB sending the X2 Setup 1441
Request and the "peer eNB" refers to the recipient of the X2 Setup Request. 1442
With the introduction of the Automatic Neighbour Relation function or ANR, in addition to 1443
setting up X2 links for configured neighbour relations, the eNB shall be able to: 1444
- set up an X2 link towards a neighbour eNB that was not previously configured (in this 1445
case it is necessary that ANR be activated on the initiating eNB); 1446
- accept the opening of an X2 link coming from an unknown eNB (in this case it is not 1447
necessary for ANR to be activated on the peer eNB). By unknown eNB what is meant 1448
here is an eNB that was not configured as a neighbour in the eNB's MIM. 1449
1450
4.10.1 SUCCESSFUL CASE 1451
ENB ENB2
X2 SCTP Association is set up
ENB ENB2
X2AP X2 SETUP RESPONSE
Global eNB IDServed Cells (1 to 256)
> Served Cell Information> Neighbour Information (0 to 512)
>> ECGI>> PCI
>> EARFCNGU Group ID List (0 to 16)
> GU Group IDCriticality Diagnostics
X2AP X2 SETUP REQUEST
Global eNB IDServed Cells (1 to 256)> Served Cell Information> Neighbour Information (0 to 512)>>ECGI>> PCI>> EARFCNGU GroupID List (0 to 16)> GU Group ID
1452
Figure 23: X2 Setup Success 1453
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 54/99
In the diagram above, only the Information Elements managed in LA3.0 are 1454
represented. 1455
1456
Peer eNB Behaviour 1457
The behaviour of the eNB when the ANR feature is activated is specified in [SRS SON]. The 1458
following applies to an eNB whatever the ANR activation state. 1459
Upon receiving the X2 Setup Request message, the peer eNB checks whether an X2Access 1460
instance exists in the MIM for the eNB that initiated the X2 Setup procedure. If no X2Access 1461
instance exists (or in other words if the neighbour eNB had not been configured) the peer 1462
eNB responds with an X2 Setup Response. 1463
The information received from the initiating eNB (served cell and neighbour information) is 1464
memorized to answer to the requirement of dynamic X2 configuration. The implication is 1465
that the cells served by the initiating eNB will be known to the eNB and outgoing X2 1466
handovers towards those cells will be possible. Incoming handovers from the initiating eNB 1467
will of course also be processed. The management of information exchanged through X2 1468
messages in the context of dynamic X2 configuration is described in [SRS SON]. 1469
1470
If an X2Access instance exists in the MIM for the eNB that initiated the X2 Setup procedure, 1471
the peer eNB checks the received information elements against MIM parameters. 1472
If all the neighbour cells associated in the MIM to the initiating eNB for which the X2 Setup 1473
Request has been received can be matched to a cell in the Served Cells list, the peer eNB 1474
considers the setup to be completely successful and responds with an X2 Setup Response. 1475
Before sending a X2 Setup Response message to a peer eNB, an eNB shall compute the GU 1476
Group ID List based on the GUMMEI information received by MMEs it is connected to (see 1477
section 4.13.3.1) and include it in the X2 Setup Response message. An empty GU Group ID 1478
List shall not prevent the X2 setup procedure from being performed. 1479
If at least one of the neighbour cells associated in the MIM to the initiating eNB for which 1480
the X2 Setup Request has been received cannot be matched to a cell in the Served Cells 1481
list, the peer eNB considers the setup to be partially successful and responds with an X2 1482
Setup Response, while raising an alarm to notify the mismatch in configuration. 1483
If some of the received Served Cells do not match neighbour cells configured in the MIB, 1484
they will be managed as dynamic neighbour relations (please see details in [SRS SON]). If 1485
ANR is not activated, MIM will not be updated with received configuration. However, the 1486
ENB will provide all its neighbours with received information with an ENB Configuration 1487
Update message, as the configuration received from neighbours is considered as more 1488
accurate than MIM configuration,. 1489
In addition, the content of “Served Cells” and “Neighbour Information” IEs is used to 1490
detect PCI allocation conflicts as specified in [SRS SON]. 1491
1492
Initiating eNB behaviour 1493
The behaviour of the eNB when the ANR feature is activated is specified in [SRS SON]. The 1494
following applies to an eNB whatever the ANR activation state . 1495
Before sending a X2 Setup Request message to a peer eNB, an eNB shall compute the GU 1496
Group ID List based on the GUMMEI information received by MMEs it is connected to (see 1497
section 4.13.3.1) and include it in the X2 Setup Request message. An empty GU Group ID 1498
List shall not prevent the X2 setup procedure from being performed. 1499
Upon receiving the X2 Setup Response message, the initiating eNB checks the received 1500
information elements against MIM parameters. 1501
Commentaire [ADW30] : <Start: SRS-026072-100, Other>
Feature Number: L108172 Author: Frédéric Deville
<End: SRS-026072-100>
Commentaire [ADW31] : <Start: SRS-026072-110, Other>
Feature Number: L108172 Author: Frédéric Deville
<End: SRS-026072-110>
Commentaire [ADW32] : <Start: SRS-026072-120, Requirement>
Feature Number: L108172 Author: Frédéric Deville
<End: SRS-026072-120>
Commentaire [ADW33] : <Start: SRS-026072-170, Requirement>
Feature Number: L108172 Author: Frédéric Deville
<End: SRS-026072-170>
Commentaire [ADW34] : <Start: SRS-026072-370, Requirement>
Feature Number: L108172 Author: Frédéric Deville
<End: SRS-026072-370>
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 55/99
If all the neighbour cells associated in the MIM to the peer eNB for which the X2 Setup 1502
Response has been received can be matched to a cell in the Served Cells list, the X2 Setup 1503
procedure is considered completely successful. 1504
If at least one of the neighbour cells associated in the MIM to the peer eNB for which the 1505
X2 Setup Response has been received cannot be matched to a cell in the Served Cells list, 1506
the X2 Setup procedure is considered partially successful, and an event is raised to notify 1507
the mismatch in configuration. 1508
If some of the received Served Cells do not match neighbour cells configured in the MIB, 1509
they will be managed as dynamic neighbour relations (please see details in [SRS SON]). 1510
In addition, the content of “Served Cells” and “Neighbour Information” IEs is used to 1511
detect PCI allocation conflicts as specified in [SRS SON]. 1512
1513
4.10.2 FAILURE CASES 1514
4.10.2.1 X2 SETUP FAILURE 1515
Peer eNB behavior 1516
There are two use cases for rejecting an X2 Setup procedure in the Alcatel-Lucent 1517
implementation of the eNB. When the X2 link is locked (through the administrative state of 1518
the associated X2Access instance), the eNB will allow the SCTP association to be set up 1519
and reject the X2 Setup procedure by sending an X2 Setup Failure message. Similarly, 1520
when an X2 link has been black-listed (through the noX2 attribute of the associated 1521
X2Access instance), incoming SCTP INIT messages will be accepted by the eNB, but the X2 1522
Setup procedure will be rejected by sending an X2 Setup Failure message. In both cases, 1523
the X2 Setup Failure will contain a Time To Wait IE set to the maximum value (v60s) and 1524
the Cause IE will be set to "om-intervention". 1525
1526
If the peer eNB is in a state to do so, it may initiate an X2 Setup procedure of its own and 1527
become the initiating eNB. 1528
Initiating eNB behavior 1529
Upon reception of the X2 Setup Failure, the initiating eNB shall set a timer to a random 1530
value at least equal to either the Time To Wait information element if is was received, or 1531
to a random X2TimeToWait value chosen among the range of values allowed by the 1532
standard. The standard allows following values "v1s, v2s, v5s, v10s, v20s, v60s ", a random 1533
value may be chosen in any range between two values, e.g. range [1..2] for value v1s, 1534
range [60..80] for value v60s) . 1535
Once this timer expires, the initiating eNB may trigger a new X2 Setup procedure by send 1536
the X2 Setup Request message. While the timer runs, the eNB may respond to an incoming 1537
X2 Setup Request from the peer eNB, in which case it stops the time. 1538
If the X2 Setup procedure fails three times consecutively, the eNB will raise an alarm to 1539
notify the issue to the operator. The operational state of the associated X2Access instance 1540
will be set to Disabled, and its availability status to Failed. The SCTP association will 1541
remain in set up state. 1542
1543
Commentaire [ADW35] : <Start: SRS-026072-380, Requirement>
Feature Number: L108172 Author: Frédéric Deville
<End: SRS-026072-380>
Commentaire [ADW36] : <Start: SRS-026072-180, Requirement>
Feature Number: L108172 Author: Frédéric Deville
<End: SRS-026072-180>
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 56/99
ENB ENB2
X2AP X2 SETUP REQUEST
ENB2 rejects the setup procedure by sendingX2 SETUP FAILURE
ENB ENB2
X2 SETUP FAILURECause (M)
TimeToWait (O)CriticalityDiagnostics(O)
X2AP X2 SETUP REQUEST
set x2SetupTimer
set timer T
set x2SetupTimer
if TimeToWait (O) wasn’t present, set timer T with a duration randomly chosen
among possible values
if TimeToWait (O) has been received, set timer T with
duration TimeToWait
ENB resends X2 SETUP REQUEST to ENB2 at most two times (for a total of three attempts),
considers the setup failed after three consecutive failuresand raises an alarm to XMS
X2 SCTP Association is set up
stop x2SetupTimer
timer T expires
1544
Figure 24: X2 Setup Failure 1545
1546
4.10.2.2 NO RESPONSE TO X2 SETUP REQUEST 1547
Initiating eNB behavior 1548
If the initiating eNB does not receive either X2 SETUP RESPONSE message or X2 SETUP 1549
FAILURE message, the eNB may reinitiate the X2 Setup procedure towards the same eNB, 1550
provided that the content of the new X2 SETUP REQUEST message is identical to the 1551
content of the previously unacknowledged X2 SETUP REQUEST message. 1552
When the eNB sends an X2 Setup Request message, it sets an internal timer that is stopped 1553
if either X2 Setup Response or X2 Setup Failure messages are received. If this timer 1554
expires, the initiating eNB may trigger a new X2 Setup procedure by sending the X2 Setup 1555
Request message. While the timer is running, the eNB may respond to an incoming X2 1556
Setup Request from the peer eNB, in which case it stops the timer. 1557
If the X2 Setup procedure fails three times consecutively, the eNB will raise an alarm to 1558
notify the issue to the operator. The operational state of the associated X2Access instance 1559
will be set to Disabled, and its availability status to Failed. The SCTP association will 1560
remain in set up state. 1561
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 57/99
ENB ENB2
ENB ENB2
X2AP X2 SETUP REQUEST
X2AP X2 SETUP REQUEST
set x2SetupTimer
set x2SetupTimer
X2 SCTP Association is set up
x2SetupTimer expires
ENB resends X2 SETUP REQUEST to ENB2at most two times (for a total of three attempts),
considers the setup failed after three consecutive failuresand raises an alarm to XMS
1562
Figure 25: No Response To X2 Setup 1563
1564
4.10.2.3 X2 LINK FAILURE 1565
X2 Link failures are detected at SCTP level as described in [A8] and reported via a state 1566
change notification: the underlying X2TransportLayerAccess object becomes 1567
Disabled/Failed. The X2Access object state becomes Disabled/Dependency and remains so 1568
while the SCTP association is down. 1569
When the SCTP association is reestablished, the eNB will trigger a new X2 Setup procedure 1570
as specified in section 4.10.1. 1571
1572
4.10.2.4 X2 SETUP CROSSOVER 1573
Two eNBs may initiate an X2 Setup procedure at the same time, causing an X2 Setup 1574
crossover. 1575
In LA3.0, the stream identifier used for non-UE associated signaling is hard coded to value 1576
"0". The stream identifier used by the peer eNB will be dynamically discovered on 1577
reception of first message, which shall be a non-UE associated signaling X2 SETUP 1578
message. 1579
Upon receiving a crossover X2 Setup Request, the eNB shall answer as specified in section 1580
4.10.1, but shall not cancel its ongoing X2 setup procedure. In other words, it will not 1581
consider the X2 interface to be operational and will continue to wait for an answer to the 1582
X2 Setup Request it initiated. The peer eNB will behave in a similar fashion, so the eNB 1583
will end up receiving an answer, whether successful or not, to the request it sent. 1584
This behavior is consistent with latest updates brought in TS 36.423, and especially 1585
through CR R3-091410. 1586
1587
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 58/99
4.10.3 MULTIPLE X2 LINKS 1588
An eNB may be connected to up to 32 other eNBs. The X2 Setup procedures will be 1589
triggered as soon as the SCTP association for each eNB is available, and may therefore 1590
happen in parallel. They may also run in parallel to S1 Setup procedures. 1591
1592
4.10.4 INTERACTIONS WITH OTHER FEATURES 1593
When a target cell has been identified for an inter-eNB handover and the X2 link to the 1594
eNB supporting that cell is not operational (managed object X2Access is in a state different 1595
from Enabled/None), the handover may be attempted over the S1 interface if S1 handover 1596
is allowed; otherwise it is abandoned (for details see [A2]). 1597
1598
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 59/99
1599
4.10.5 X2 LOCK/UNLOCK 1600
An X2 link can be locked or unlocked through administrativeState attribute attached to 1601
X2Access object instance. 1602
An unlocked X2 link will be established and allowed to operate (except if black-listed or 1603
released by ANR garbage collection mechanism, refer to following chapters for details). 1604
A locked X2 link will not be established. 1605
Note: “shuttingdown” value is not currently supported. 1606
1607
Following chapters specify eNB behavior on transitions from “unlock to lock” and “lock to 1608
unlock”. 1609
1610
4.10.5.1 BEHAVIOR WHEN LOCKING AN X2 LINK 1611
Locking an X2 link is performed by setting X2Access administrativeState to “locked”. 1612
In this case, if the X2 link was established, it has to be released. Underlying SCTP 1613
association does not need to be released itself, however, as the only way to release X2 link 1614
is to release also SCTP, when X2 lock command is received, the eNB will shutdown 1615
underlying SCTP association. 1616
As long as X2 link is locked, X2 link will not be established (meaning X2 setup will not be 1617
triggered and rejected if received from the peer eNB. 1618
Underlying SCTP may be resumed following SCTP INIT received from the peer eNB. 1619
1620
4.10.5.2 BEHAVIOR WHEN UNLOCKING AN X2 LINK 1621
Unlocking an X2 link is performed by setting X2Access administrativeState to “unlocked”. 1622
In this case, given that the link is not black-listed, it shall be established through X2 setup 1623
procedure. Of course, underlying SCTP association shall be established beforehand if not 1624
already up. 1625
1626
4.10.6 X2 BLACK-LISTING 1627
ANR function introduced the notion of X2 link “black-list”, meaning that the operator has 1628
the possibility to declare that an X2 link shall never be established by the eNB, whatever 1629
the condition. For further details, please refer to[A14]. 1630
In case an X2 link is black-listed, it shall then not be established and in case it was, it shall 1631
be released whatever its administrative state. 1632
This means black-listing will always take precedence over administrative state. 1633
1634
4.10.7 X2 WHITE-LISTING 1635
ANR also introduced the notion of X2 link “white-list”, meaning that the operator has the 1636
possibility to declare that an X2 link shall always be established. For further details, please 1637
refer to[A14]. 1638
Commentaire [ADW37] : <Start: SRS-026072-280, Other>
Feature Number: L113614 (TLA3.0) / L108282 (LA3.0)
Author: Yunhua Wang <End: SRS-026072-280>
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 60/99
In case an X2 link is white-listed, it shall then be established, except if locked. 1639
This means it will always be possible to lock an X2 link, even if withe-listed. This is 1640
mandatory because locking an X2 link may be needed for maintenance purpose. 1641
1642
4.10.8 X2 ONLINE CREATION 1643
It is now possible to create online an X2Access instance along with its underlying 1644
X2TransportLayerAccess instance (X2TransportLayerAccess cardinality ensures that if an 1645
X2Access instance is created, then associated X2TransportLayerAccess instance will also 1646
be). 1647
eNB behavior on X2Access instance creation will be: 1648
- If X2 link is black-listed, it will not be established 1649
- If X2 link is not black-listed, it will be established only if unlocked 1650
1651
4.10.9 X2 ONLINE DELETION 1652
It is also possible to delete online an X2Access instance along with its underlying 1653
X2TransportLayerAccess instance. 1654
eNB behavior in case of X2 link deletion will be 1655
- If X2 link was established, it will be released through SCTP shutdown 1656
- If it was not, it will be simply removed from the MIB 1657
1658
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 61/99
4.11. X2 ENB CONFIGURATION UPDATE 1659
The purpose of the eNB Configuration Update procedure is to update application level 1660
configuration data needed for two eNBs to interoperate correctly over the X2 interface. 1661
The procedure uses non UE-associated signaling. 1662
1663
4.11.1 SUCCESSFUL CASE 1664
ENB1 ENB2
ENB1 ENB2
ENB CONFIGURATION UPDATE ACKNOWLEDGE
Criticality Diagnostics
ENB CONFIGURATION UPDATE
Served Cells To Add (1 to 256)> Served Cell Information> Neighbour Information>> ECGI>> PCI>> EARFCNServed Cells To Modify (1 to 256)> Old ECGI> Served Cell Information> Neighbour Information (0 to 512)>> ECGI>> PCI>> EARFCNServed Cells To Delete (1 to 256)> Old ECGIGU Group Id To Add List (1 to 16)GU Group Id To Delete List (1 to 16)
1665
Figure 26: X2 eNB Configuration Success 1666
1667
Initiating eNB behavior 1668
The reception of new GUMMEI information from an MME instance in an S1 Setup Response 1669
or a S1 MME Configuration Update message may cause the GU Group Id List to change. If it 1670
does change, the eNB is expected to provide the new list to neighboring eNBs using the X2 1671
eNB CONFIGURATION UPDATE procedure towards all its X2 neighbors. 1672
The X2 eNB CONFIGURATION UPDATE procedure requires the eNB to provide a delta of the 1673
GU Group ID List, i.e. the eNB needs to provide the new GU Group IDs, as well as the GU 1674
Group Ids that need to be deleted. These items will be the same across all X2 instances. 1675
The eNB Configuration Update procedure may also be triggered by the ANR function, as 1676
specified in [A14]. 1677
The dynamic update of LteCell->TrackingAreaCode (Class C parameter) shall trigger a eNB 1678
Configuration procedure including corresponding Served Cells To Modify. 1679
1680
Commentaire [ADW38] : <Start: SRS-026072-320, Other>
Feature Number: L108282 Author: M. Gateau
<End: SRS-026072-320>
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 62/99
Peer eNB behavior 1681
Upon reception of the GU Group Id List in the X2 eNB CONFIGURATION UPDATE message, 1682
the eNB2 shall update the previous list and store the new information so that it can be used 1683
for mobility decisions. 1684
1685
4.11.2 FAILURE CASES 1686
4.11.2.1 X2 ENB CONFIGURATION UPDATE FAILURE 1687
If the eNB2 can not accept the update it shall respond with an eNB CONFIGURATION 1688
UPDATE FAILURE message and appropriate cause value. 1689
If the eNB CONFIGURATION UPDATE FAILURE message includes the Time To Wait IE the eNB 1690
shall wait at least for the indicated time before reinitiating the eNB Configuration Update 1691
procedure towards the same eNB2. Both nodes shall continue to operate the X2 with the 1692
existing configuration data. 1693
1694
Peer eNB behavior 1695
The peer eNB may decide to reject an incoming X2 Configuration Update in case X2 1696
connection is in state OAM Locked or is defined with attribute “noX2”. In this case it sends 1697
an X2 eNB CONFIGURATION UPDATE FAILURE, including the Time To Wait information 1698
element set to X2TimeToWait hard coded value (e.g. v60s, maximum value allowed by the 1699
standard). 1700
In case ANR feature is deactivated, the eNB will check the neighbor cells found in the MIM 1701
with the Served Cells indicated in the eNB CONFIGURATION UPDATE and raise an alarm in 1702
case no match is found as in this case, X2 configuration prevails. However, eNB will 1703
complete normally the procedure with an eNB CONFIGURATION UPDATE ACKNOWLEDGE 1704
message 1705
Initiating eNB behavior 1706
Upon reception of the X2 eNB Configuration Update Failure, the initiating eNB shall set a 1707
timer to a random value at least equal to either the Time To Wait information element if 1708
is was received, or to a random X2TimeToWait value chosen among the range of values 1709
allowed by the standard. The standard allows following values “v1s, v2s, v5s, v10s, v20s, 1710
v60s", a random value may be chosen in any range between two values, e.g. range [1..2] 1711
for value v1s, range [60..80] for value v60s) . 1712
Once this timer expires, the initiating eNB may trigger a new X2 eNB Configuration Update 1713
procedure by sending the X2 eNB CONFIGURATION UPDATE message. 1714
The eNB will retry the X2 eNB Configuration Update procedure 1715
X2ConfigurationUpdateRetry times (hard coded value set to 3). In case there is no 1716
successful answer after the retries, the eNB will shut down X2 connection and restart the 1717
X2 Setup procedure. It will raise an event 1718
“ENB_CANDIDATE_X2_ENB_CONFIGURATION_UPDATE_FAILURE“ to notify the issue to the 1719
operator. 1720
1721
Commentaire [ADW39] : <Start: SRS-026072-200, Requirement>
Feature Number: L108172 Author: Frédéric Deville
<End: SRS-026072-200>
Commentaire [ADW40] : <Start: SRS-026072-210, Other>
Feature Number: L97926 Author: Martine Gateau
<End: SRS-026072-210>
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 63/99
ENB1 ENB2
ENB1 ENB2
ENB CONFIGURATION UPDATE FAILURECause
Time To WaitCriticality Diagnostics
ENB CONFIGURATION UPDATE
Served Cells To Add (1 to 256)> Served Cell Information> Neighbour Information>> ECGI>> PCI>> EARFCNServed Cells To Modify (1 to 256)> Old ECGI> Served Cell Information> Neighbour Information (0 to 512)>> ECGI>> PCI>> EARFCNServed Cells To Delete (1 to 256)> Old ECGIGU Group Id To Add List (1 to 16)GU Group Id To Delete List (1 to 16)
1722
Figure 27: X2 eNB Configuration Update Failure 1723
1724
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 64/99
4.11.2.2 NO RESPONSE TO X2 ENB CONFIGURATION UPDATE 1725
If the eNB after initiating eNB Configuration Update procedure receives neither eNB 1726
CONFIGURATION UPDATE ACKNOWLEDGE message nor eNB CONFIGURATION UPDATE 1727
FAILURE message, the eNB may reinitiate the eNB Configuration Update procedure towards 1728
the same eNB2, provided that the content of the new eNB CONFIGURATION UPDATE 1729
message is identical to the content of the previously unacknowledged eNB CONFIGURATION 1730
UPDATE message. 1731
When the eNB sends an eNB Configuration Update message, it sets an internal timer that is 1732
stopped if either eNB Configuration Update Acknowledge or eNB Configuration Update 1733
Failure messages are received. If this timer expires, the initiating eNB may trigger a new 1734
X2 eNB Configuration Update procedure by sending the X2 eNB CONFIGURATION UPDATE 1735
message. 1736
The eNB will retry the X2 eNB Configuration Update procedure 1737
X2ConfigurationUpdateRetry times (hard coded value set to 3). In case there is no 1738
successful answer after the retries, the eNB will shut down X2 connection and restart the 1739
X2 Setup procedure. It will raise an event 1740
“ENB_CANDIDATE_X2_ENB_CONFIGURATION_UPDATE_NO_RESPONSE” to notify the issue to the 1741
operator. 1742
1743
ENB1 ENB2
ENB1 ENB2
ENB CONFIGURATION UPDATE
ENB CONFIGURATION UPDATEset
x2ENBConfiguration UpdateTimer
set x2ENBConfiguration
Update Timer
x2ENBConfiguration UpdateTimer expires
ENB resends ENB CONFIGURATION UPDATE to ENB2(3 retries maximum)
1744
Figure 28: No Response To X2 eNB Configuration Update 1745
1746
1747
Commentaire [ADW41] : <Start: SRS-026072-400, Other>
Feature Number: L97926 Author: Martine Gateau
<End: SRS-026072-400>
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 65/99
1748
4.12. X2 RESET PROCEDURE 1749
The purpose of the Reset procedure is to align the resources between two eNBs in case of 1750
abnormal failure. This procedure resets the X2 interface, but doesn’t affect the 1751
application level configuration data exchanged during the X2 Setup procedure. 1752
The procedure uses non-UE associated signaling. 1753
1754
Source ENB Target ENB
ENB MME
RESET RESPONSE
Criticality Diagnostics
RESET REQUEST
Cause
1755
1756
4.12.1 X2 RESET EMISSION 1757
On the contrary of S1 Reset, X2 Reset doesn’t offer the possibility of a partial Reset of X2 1758
interface. 1759
An X2 RESET REQUEST may be generated by eNB in following cases to improve defense 1760
mechanism: 1761
- eNB restart following a critically anomaly detection : during the eNB shutdown 1762
preparation, a X2 reset shall be sent on X2 interfaces to allow peer eNB to release related 1763
X2 contexts. When a critical anomaly is detected in another application than CallP, before 1764
restarting the eNB, the platform shall ask Callp to send X2 reset on all X2 interfaces. 1765
1766
- eNB software upgrade: an X2 reset shall be sent on X2 interfaces during software upgrade 1767
preparation phase, the platform shall ask Callp to send a X2 reset on all X2 interfaces. 1768
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 66/99
ENB doesn’t need to wait for RESET RESPONSE to continue on-going procedures 1769
In LA3.0, platform services are not planned to be implemented, so no X2 RESET 1770
REQUEST will be generated by eNB CallP software. A debug command may be 1771
implemented in CallP to generate a X2 Reset cause Miscellaneous / O&M intervention 1772
for tests purposes. 1773
1774
4.12.2 X2 RESET RECEPTION 1775
On reception of an X2 RESET REQUEST from a source eNB, X2 configuration data is kept, 1776
only X2 UE contexts shall be released. 1777
After completion of release of the resources, the target eNB shall answer with a RESET 1778
RESPONSE message. 1779
As per [R7] TS 36.423, if the RESET REQUEST message is received, any other ongoing 1780
procedure (except another Reset procedure) on the same X2 interface shall be aborted. 1781
As configuration data are not affected by the RESET procedure, there is no need to abort 1782
ENB Configuration Update procedure, it may be processed normally. Aborting the ENB 1783
Configuration Update procedure has no added value, as the initiating eNB then needs to 1784
repeat it just after to send again the updated configuration to the peer node, If the peer 1785
node doesn’t answer to ENB Configuration Update procedure, due to RESET procedure, the 1786
defense timer allows the initiating eNB to resend the ENB Configuration Update message. 1787
Interaction with X2 Handover procedure is described in document [A2]. 1788
1789
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 67/99
4.13. SUPPORT OF MME GROUP 1790
4.13.1 INTRODUCTION / OVERVIEW 1791
As described in [R8] TS 23.401 MMEs can be pooled together in order to allow for better 1792
balance of load between them. When a UE is served by an MME, this serving MME does not 1793
have to change as long as the UE remains in the same MME pool area. This implies that all 1794
the eNBs within this MME pool area are connected to all the MMEs in the pool through an 1795
S1 interface. The concept of MME pooling is depicted in the figure below. 1796
1797
1798
1799
In order to take advantage of MME pooling, the eNB needs to support S1-Flex, i.e. the 1800
ability to connect to multiple MME instances over S1, along with an MME selection scheme 1801
based on MME relative capacity. This MME selection scheme is enhanced with the support 1802
of MME pooling on the eNB side. 1803
1804
Support of MME group introduces the following functionalities in the eNB: 1805
- Support for the GU Group ID List over X2: the eNB will provide this list to 1806
neighboring eNBs based on information provided by the MME instances it is 1807
connected to, as well as store the list provided by neighboring eNBs; 1808
- Target cell selection upon handover: based on the GU Group ID List provided by its 1809
X2 neighbors, the eNB will prevent triggering an X2 handover to a cell in an eNB not 1810
connected to the MME currently serving the UE. Instead, the eNB will trigger the S1 1811
handover; 1812
1813
MME MME …
MME-1
MME-j
…
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
eNB
……
TA1
Border
Pool A Pool B
TA2 TA3 TA4 TA5 TA6
Ba Bb
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 68/99
4.13.2 ASSUMPTIONS 1814
The following system assumptions are made: 1815
• MME Code is assumed to be unique within a pool, or within area of overlapping pools 1816
(see TS23.003 clause 2.8.1); 1817
• When an eNB is connected to an MME pool, it has to be connected to all MMEs in that 1818
pool (see TS36.401 clause 6.1); 1819
• As per [R8] TS 23.401, MME relocation cannot be achieved by an X2 handover. This 1820
implies that two eNBs need to be connected to the MME pool (group) of the MME 1821
handling the call for X2 mobility to work between them; 1822
• An MME can only belong to one MME LTE pool/group; 1823
• The list of MME Groups provided by the MME includes pool information for 2G/3G. Only 1824
the LTE pooling information should be provided to neighboring eNBs over X2; 1825
• The X2 interface setup can be initiated before the S1 Setup. 1826
1827
4.13.3 SUPPORT FOR GU GROUP ID LIST OVER X2 1828
The GU Group ID List provides the MME Pools (also called MME Groups) that an eNB is 1829
connected to through the S1 interface. The eNB needs to manage the GU Group ID List 1830
over X2: 1831
1. Provide its neighboring eNBs with the MME groups (i.e. pools) it is connected to 1832
through the X2-AP SETUP REQUEST or X2-AP SETUP RESPONSE message. Since the 1833
eNB obtains this information from the MME upon S1-AP SETUP RESPONSE or upon 1834
S1-AP MME CONFIGURATION UPDATE, it may not have the GU Group ID list upon X2 1835
Setup (i.e. if S1 Setup is not completed); 1836
2. Update its neighboring eNBs with the MME groups (i.e. pools) it is connected to, 1837
when those change (e.g. following an S1-AP SETUP RESPONSE or S1-AP MME 1838
CONFIGURATION UPDATE), using the X2-AP ENB CONFIGURATION UPDATE 1839
procedure; 1840
3. Store the MME groups a neighboring eNB is connected to, as provided in the X2-AP 1841
SETUP REQUEST, X2-AP SETUP RESPONSE or X2-AP ENB CONFIGURATION UPDATE 1842
message. This information will then be used for handover decisions. 1843
Note: GU Group ID = PLMN ID + MME Group ID. 1844
1845
4.13.3.1 COMPUTING GU GROUP ID LIST AND PROVIDING IT TO X2 NEIGHBORS 1846
The GU Group ID List is a list made of combinations of PLMN ID and MME Group ID (please 1847
refer to [I4] for details on each), which essentially corresponds to the list of MME 1848
pools/groups an eNB is connected to. The GU Group ID List needs to be computed based on 1849
the GUMMEI List provided by the various MME instances the eNB is connected to. 1850
1851
The eNB shall compute the GU Group Id List based on the GUMMEI information received by 1852
MMEs it is connected to. 1853
1854
The GUMMEI IE provided by the MME will provide the following information, as per [R6] 1855
TS36.413: 1856
o Served PLMN IDs 1857
o Served MME Group IDs 1858
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 69/99
o Served MME codes 1859
1860
The served MME Group ID information is provided by RAT to the eNB, and the LTE pooling 1861
information is provided first. Only the LTE-specific pooling information needs to be 1862
provided to X2 neighbors, since 2G/3G pooling information will not be useful (clarified in 1863
CR R3-091343 to TS36.413 June 2009). 1864
1865
When computing the GU Group ID List, the eNB needs to combine PLMN ID information 1866
with MME Group ID information, i.e. all combinations of PLMN ID and MME Group ID for a 1867
single MME instance shall be indicated to X2 neighbors. PLMN ID and MME Group ID 1868
combinations across different MME instances should not be included. 1869
Combinations of PLMN ID and MME Group ID received from 2 different MME could result in 1870
duplicated value. In this case, the resulting combination will be provided only once to X2 1871
neighbors. 1872
1873
When building the GU Group Id List, some S1 interfaces may be in a disabled state, e.g. 1874
because the SCTP connection is down. The eNB should not look at the operational state of 1875
the S1 interface when building the GU Group Id List and providing it to neighbors, i.e. all 1876
MME instances should be considered. In case an eNB triggers a handover request towards 1877
an eNB for which the identified MME is not accessible, the eNB will reject the handover 1878
request. 1879
1880
1881
Various triggers will require the eNB to compute the GU Group ID List: 1882
o When an X2 SETUP REQUEST is initiated by the eNB 1883
o When an X2 SETUP REQUEST is received by the eNB and the X2 SETUP RESPONSE 1884
needs to be sent 1885
o When the eNB receives an S1 SETUP RESPONSE message from an MME instance; 1886
only if there is at least one X2 instance setup already 1887
o When the eNB receives an S1 MME CONFIGURATION UPDATE with GUMMEI 1888
information; only if there is at least one X2 instance setup already 1889
1890
One should note that the X2 Setup procedure may be performed before the eNB has any S1 1891
connection setup. This will result in the GU Group ID List being empty. 1892
1893
1894
The reception of new GUMMEI information from an MME instance in a S1 Setup Response or 1895
S1 MME Configuration Update message may cause the GU Group Id List to change. If it does 1896
change, the eNB is expected to provide the new list to neighboring eNBs using the X2 ENB 1897
CONFIGURATION UPDATE procedure. If the eNB currently has no X2 connection, then there 1898
is no need to compute the GU Group Id List. 1899
To know if the GU Group Id list has changed, the eNB needs to compare the old list with 1900
the new list, using the new GUMMEI information provided by the MME. If the list does not 1901
change, then there is no need to update neighboring eNBs. 1902
1903
The X2 ENB CONFIGURATION UPDATE procedure requires the eNB to provide a delta of the 1904
GU Group ID List, i.e. the eNB needs to provide the new GU Group IDs, as well as the GU 1905
Group Ids that need to be deleted. These items will be the same across all X2 instances. 1906
1907
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 70/99
4.13.3.2 STORING GU GROUP ID INFORMATION PROVIDED BY X2 NEIGHBORS 1908
Upon reception of the GU Group ID List from a neighboring eNB, the eNB will know to 1909
which MME pools this eNB is connected through the S1 interface. The eNB will use this 1910
information for handover decisions (see [A2]). This means that every time the eNB receives 1911
this information (new or updated) from a neighboring eNB, it needs to store it in a context 1912
specific to this eNB neighbor. 1913
The following X2-AP messages can contain the GU Group Id List: X2 SETUP REQUEST, X2 1914
SETUP RESPONSE and X2 ENB CONFIGURATION UPDATE. Since the GU Group Id List IE is 1915
optional in the X2 ASN.1, it may not necessarily be provided by the peer eNB. This should 1916
not stop the procedure from being completed successfully. 1917
1918
4.14. MME PRIORITY (NOT IN LA3.0/TLA3.0) 1919
A notion of MME priority is defined at eNB level. A priority is assigned to each MME by 1920
configuration: a MME can be defined as “primary” or “secondary”. 1921
� eNB MME Selection shall be applied across Primary MMEs while secondary MMEs shall be 1922
declared a MME for backup in case of overload or access problem. 1923
� eNB selects the primary MME(s) first, until all the primary MMEs are not reachable or 1924
overloaded. 1925
� Secondary MME(s) are selected only under abnormal conditions – All primary MME(s) 1926
are not available or in overload condition. 1927
1928
A new attribute is added to MMEAccess object: MMEAccess->priority. Default value of this 1929
attribute is primary. Some operators may not use this priority notion and configure only 1930
primary MMEs. 1931
1932
S1 link and S1 setup are established towards all MMEs, independently of their priority. 1933
1934
Once a secondary MME has been selected for one UE, this UE will always provide this 1935
selected MME for new RRC Connections. To allow the UE to come back to primary MMEs 1936
when normal conditions are filled again (primary MME(s) available again, i.e. in 1937
Enable/none state, not overloaded and with a relativeMMECapacity not set to 0), the eNB 1938
will have following handling: in case of reception of a S1 UE CONTEXT RELEASE from a 1939
secondary MME, and primary MME(s) are available again, the eNB shall set the release 1940
cause to “loadBalancingTAUrequired” in RRCConnectionRelease. This will make the UE 1941
initiate a TAU without providing S-TMSI or registeredMME in RRCConnectionRequest and 1942
will allow eNB to select a primary MME to serve this UE (see document [A1] for details on 1943
S1 UE Context Release procedure). 1944
As this reselection of a primary MME is done on UE context release, it will not cause any 1945
delay for UE connection and any impact on UE service. In addition, this will allow the UEs 1946
to go back gradually to primary MME(s) with the load balancing algorithm and avoid 1947
primary MMEs becoming overloaded again. 1948
1949
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 71/99
4.15. MME SELECTION ALGORITHM 1950
In the case where several S1 links to MMEs are configured, the ENB is expected to dispatch 1951
UEs to the specific MMEs to which they are registered, or to select an MME to which they 1952
will register when they haven't previously done so. 1953
1954
A UE which has previously registered with a given MME will provide the identity of the MME 1955
by including either optional information element S-TMSI containing MME Code in RRC 1956
Connection Request message (when the UE is registered in the Tracking Area of the cell it 1957
is attempting to access) or optional information element registeredMME (GUMMEI that 1958
consists of the PLMN ID, the MME Group ID and the MME Code) in the RRC Connection Setup 1959
Complete message. 1960
In this case, the ENB will attempt to match the provided MME with an MME identity in the 1961
list of GUMMEIs received during S1 Setup procedure (see section 4.4) or MME Configuration 1962
Update procedure (see section 4.5). If no match is found, the ENB will initiate MME 1963
selection as described hereafter. 1964
If a match is found and matched MME is not overloaded (not in LA3.0/TLA3.0) or the RRC 1965
establishment cause can be accepted due to overload action (not in LA3.0/TLA3.0), eNB 1966
will direct the call establishment to the matched MME. If the S1 link of the matched MME is 1967
down (as indicated by a state different than Enabled/None for the MmeAccess object of 1968
the matched MME), a new MME is selected within available MMEs. 1969
1970
Following section is not supported in LA3.0/TLA3.0: 1971
If a match is found and matched MME is overloaded and the RRC establishment cause can’t 1972
be accepted due to overload action, the call will be either rejected with a timeToWait set 1973
to ueTimers->tOverload value in case MME has been provided with S-TMSI of RRC 1974
Connection Request or released with cause “other” in case MME has been provided in 1975
registeredMME of RRC Connection Setup Complete (see document [A1] for details). 1976
TS 23.401 ref [R8] section 4.3.7.3 recommends not to send any additional load to other 1977
MME in case of overload situation, that is why the calls are rejected or released and not 1978
send to another MME. Choosing another MME or using the cause loadBalancingTAUrequired 1979
in the RRC Connection Release will move the UE to another MME. When MMEs are in 1980
overload, they select randomly some eNB to reduce their load. If loadbalancing has been 1981
performed correctly, all the MME should be near the overload state. 1982
However, a non-standard specific overload handling can be activated to decrease call 1983
drops. This shall be limited to special network topologies, e.g. configurations with primary 1984
and secondary MMEs, 1985
In case parameter “ActivationService->overloadCallRejectNotAllowed” is set to true, the 1986
RRC Connection is established in a first step, followed by a RRC Connection release cause 1987
“loadbalancingTAUrequired”. This will allow the UE to establish a new RRC connection 1988
with a TAU, without providing S-TMSI or registeredMME, in which case a new MME is 1989
selected by the eNB. 1990
1991
Note: An MME with relativeMMEcapacity set 0 can’t be selected to establish new calls but 1992
shall be selected for previously registered UEs, providing either S-TMSI or registeredMME in 1993
RRC Connection procedure. 1994
1995
In case no match is found or the S1 link of matched MME is down, an MME selection is 1996
performed within a list of eligible MMEs. 1997
1998
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 72/99
The ENB maintains a list of the GUMMEI (Globally Unique Mobility Management Identity) 1999
received during the S1 Setup or MME Configuration Update procedures. This list is used for 2000
MME matching described above. 2001
In addition, it also maintains a list of MME Access, with associated to each MME: 2002
- MME Access OperState 2003
- priority (primary or secondary) defined by configuration (not in LA3.0/TLA3.0), 2004
- overload action (see 4.8) (not in LA3.0/TLA3.0), 2005
- relativeMMECapacity also received during the S1 Setup or MME Configuration Update 2006
procedures, 2007
2008
When the ENB must perform MME selection for a given UE, it establishes the list of eligible 2009
MMEs. A MME is eligible if: 2010
- MmeAccess managed object is in the state Enabled/None : S1 link is operational (an 2011
S1 link is considered operational when an S1 Setup procedure has been successfully 2012
completed) 2013
- it is not overloaded (no overload action set) (not in LA3.0/TLA3.0) 2014
- relativeMMECapcity is not set to 0 2015
2016
Following section is not supported in LA3.0/TLA3.0: 2017
As long as one primary MME is eligible, the eNB shall perform the MME selection within the 2018
primary MME(s) with a load-balancing algorithm based on Relative MME capacity. In this 2019
case, the list of eligible MMEs shall contain the eligible primary MMEs. 2020
When no primary MME is eligible, the eNB shall perform the MME selection within the 2021
secondary MME(s) if any with the same load-balancing algorithm based on Relative MME 2022
capacity. In this case, the list of eligible MMEs shall contain the eligible secondary MMEs. 2023
In case no MME, either primary or secondary, is eligible, the call shall be released. 2024
However, an overloaded MME with MME Access OperState can be selected if the RRC 2025
establishment cause matches with overload action in following cases: 2026
- when a UE doesn’t provide S-TMSI or registeredMME, . 2027
- the provided MME is not in OperState. 2028
2029
To perform MME selection, the ENB first computes the totalMmeCapacity by summing the 2030
relativeMmeCapacity of all the eligible MMEs (primary MMEs or secondary MMEs (not in 2031
LA3.0/TLA3.0)). The relative MME capacity is typically set according to the capacity of an 2032
MME node relative to other MME nodes ([R8] TS 23.401). This relative capacity is coded as 2033
an integer in the 0 to 255 range and not as a percentage, in order to avoid having to 2034
update all the relative capacities when a new MME is introduced into the network. 2035
It then randomly draws a number between 1 and totalMmeCapacity. Each MME has a 2036
selection range, which starts at one plus the sum of the relativeMMECapacity of all the 2037
MMEs preceding it in the list of eligible MMEs, and ends at the sum of relativeMMECapacity 2038
of all the MMEs preceding it in the list and of its own relativeMmeCapacity. In this manner, 2039
the randomly drawn number falls within a unique MME selection range, and the ENB has 2040
then performed its MME selection. It then pursues normal call establishment towards the 2041
selected MME. 2042
2043
The list of eligible MMEs shall be computed each time MME Access list is updated: 2044
- change of MME Access state (S1 setup, SCTP lost, SCTP recovery) 2045
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 73/99
- change of relative MME capacity (S1 setup, MME configuration update), 2046
- change of MME overload state (overload start, overload stop). (not in LA3.0/TLA3.0) 2047
- OAM update of MMEAccess->Priority (not in LA3.0/TLA3.0) 2048
2049
2050
Commentaire [ADW42] : <Start: SRS-026072-70, Other>
Feature Number: L101845 Author: M. Gateau
<End: SRS-026072-70>
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 74/99
4.16. S1AP ERROR HANDLING 2051
Some error handling has to be performed at S1AP level to allow readiness for IOT. 2052
2053
4.16.1 ERROR HANDLING AT PROCEDURE LEVEL 2054
When the eNB receives a S1AP message for a non-supported procedure with a reject 2055
criticality, it shall answer with an ERROR INDICATION message. 2056
This message will contain the following information: 2057
- IE cause set to value “Abstract Syntax Error (reject)” 2058
- IE Criticality Diagnostics will contain the received procedure code, triggering 2059
message and procedure criticality. 2060
If the received non-supported procedure has criticality “ignore”, the eNB shall log and 2061
ignore received message. 2062
2063
4.16.2 ERROR HANDLING AT IE LEVEL 2064
At IE level, “presence” and “criticality” allow to define behaviours for error handling. 2065
To each IE is assigned a presence information. It can take the following values: 2066
• M : IEs marked as mandatory shall always be included in the message 2067
• O : IEs marked as Optional may or may not be included in the message 2068
• C : IEs marked as Conditional shall be included in a message only if the condition is 2069
satisfied. Otherwise the IE shall not be included. 2070
2071
Each IE or group of IE may have criticality information applied to it. Following cases are possible: 2072
• - : No criticality information is applied explicitly. 2073
• YES: Criticality information is applied. This is usable only for non-repeatable IEs 2074
• GLOBAL: The IE and all its repetitions together have one common criticality information. 2075
This is usable only for repeatable IEs. 2076
• EACH: Each repetition of the IE has its own criticality information. It is not allowed to 2077
assign different criticality values to the repetitions. This is usable only for repeatable IEs. 2078
2079
Assigned criticality is set to reject for IEs that are considered as essential to continue with the 2080
procedure. 2081
When an optional IE defined with an assigned criticality set to reject is received in a message but 2082
not supported by the eNB or inconsistent, the procedure shall be considered unsuccessful and a 2083
failure message or ERROR INDICATION message shall be sent in response. 2084
2085
The full ASN1 description of procedures must be supported according to a standard release. 2086
Nevertheless, all IEs are not necessarily supported in terms of functionality. The node shall use 2087
the criticality associated to the non supported IEs to decide its behaviour. Typically, if criticality 2088
is “ignore”, the message may be treated, if it is “reject”, the message must not be treated. 2089
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 75/99
Some IEs are included in most of the S1AP messages. The eNB error handling for these IEs shall be 2090
the following: 2091
2092
IE/Group Name Error handling
Message type The assigned criticality of the message type defines the criticality of the associated procedure (see tables above)
MME UE S1AP ID • Unknown MME UE S1AP ID received : send failure message or ERROR INDICATION message with cause Radio Network Layer Cause, Unknown or already allocated MME UE S1AP ID
eNB UE S1AP ID • Unknown eNB UE S1AP ID received : send failure message or ERROR INDICATION message with cause Radio Network Layer Cause, Unknown or already allocated eNB UE S1AP ID
Mandatory IE missing in a message with assigned criticality reject
The procedure shall be rejected with a failure message if it exists or an ERROR INDICATION message with criticality Diagnostic IE
2093
4.16.3 PROTOCOL ERROR HANDLING 2094
According to TS 36.413, protocol error cases can be divided into three classes: 2095
• Transfer Syntax Error: this error occurs when the receiver is not able to decode the 2096
received physical message. They are detected in the process of ASN1 decoding. 2097
Error handling: when detecting a Transfer Syntax Error the eNB should ignore the 2098
message and send Error Indication (transfer-syntax-error). 2099
Examples of Transfer Syntax Error: 2100
o Value range violation, 2101
o Violation in list element constraints (list longer than allowed…) 2102
o Missing mandatory elements in a sequence 2103
o Wrong order of elements in a sequence 2104
• Abstract Syntax Error : this error occurs when the receiving functional S1AP entity 2105
receives: 2106
1. IEs or IE groups that cannot be understood (unknown IE ID) 2107
2. IEs for which the logical range is violated 2108
3. Missing mandatory IEs or IE groups 2109
4. IEs or IE groups received in wrong order or with too many occurrences 2110
5. Missing conditional IE or IE group when condition is verified or conditional IE or IE 2111
group present when the condition is not verified 2112
Error handling: 2113
Error cases 1 and 2 are handled based on received criticality information 2114
Error case 3 is handled based on criticality and presence information for the missing 2115
IE/IE group specified in the version of the specification used by the receiver. 2116
If criticality is set to “ignore”, the procedure continues as if the IE had not been 2117
received. If criticality is set to “reject”, the handling is the following: 2118
� Initiated message of a procedure with an unsuccessful response message: 2119
send unsuccessful response with cause Abstract Syntax Error (Reject) and 2120
include the Criticality Diagnostic IE. In case the information present in the 2121
initiating message was insufficient to determine a value for all IEs that are 2122
required to be present in the unsuccessful outcome procedure, the 2123
receiving node shall instead initiate an Error Indication procedure. 2124
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 76/99
� Initiated message of a procedure without an unsuccessful response 2125
message: send Error Indication message with cause Abstract Syntax Error 2126
(Reject) and include the Procedure Code IE, the Triggering message IE, 2127
the Procedure Criticality IE and the Criticality Diagnostic IE. 2128
� Response message of a procedure: consider the procedure unsuccessfully 2129
terminated and perform local error handling. 2130
Error cases 4 and 5 result in rejecting the procedure. None of the functional 2131
requests of the message shall be executed. 2132
� Initiated message of a procedure with an unsuccessful response message: 2133
send unsuccessful response with cause Abstract Syntax Error (Falsely 2134
Constructed Message). In case the information present in the initiating 2135
message was insufficient to determine a value for all IEs that are required 2136
to be present in the unsuccessful outcome procedure, the receiving node 2137
shall instead initiate an Error Indication procedure. 2138
� Initiated message of a procedure without an unsuccessful response 2139
message: send Error Indication message with cause Abstract Syntax Error 2140
(Falsely Constructed Message) and include the Procedure Code IE, the 2141
Triggering message IE, the Procedure Criticality IE and the Criticality 2142
Diagnostic IE. 2143
� Response message of a procedure: consider the procedure unsuccessfully 2144
terminated and perform local error handling. 2145
2146
• Logical Error : this error occurs when a message is comprehended correctly, but the 2147
information contained within the message is not valid (i.e. semantic error), or describes a 2148
procedure which is not compatible with the state of the receiver 2149
Error handling: depends on class procedure 2150
Class 1 procedures: if the procedure has a message to report an unsuccessful 2151
outcome, it is sent with an appropriate cause value (Semantic Error, Message not 2152
compatible with receiver state). When no unsuccessful outcome message exists, an 2153
Error Indication procedure shall be initiated with an appropriate cause value, 2154
Procedure Code IE, the Triggering message IE and the Criticality Diagnostic IE. 2155
Class 2 procedures: the procedure shall be terminated and the Error Indication 2156
procedure shall be initiated with an appropriate cause value, Procedure Code IE, the 2157
Triggering message IE and the Criticality Diagnostic IE. 2158
2159
The protocol error handling described hereafter shall take precedence over any other error 2160
handling. 2161
• If any type of error (Transfer Syntax Error, Abstract Syntax Error or Logical Error) is 2162
detected in the ERROR INDICATION message, it shall not trigger the Error Indication 2163
procedure in the receiving Node but local error handling. 2164
• In case a response message or Error Indication message needs to be returned, but the 2165
information necessary to determine the receiver of that message is missing, the procedure 2166
shall be considered as unsuccessfully terminated and local error handling shall be 2167
initiated. 2168
• If an error that terminates a procedure occurs, the returned cause value shall reflect the 2169
error that caused the termination of the procedure even if one or more abstract syntax 2170
errors with criticality "ignore and notify" have earlier occurred within the same procedure. 2171
• If an UE S1AP ID error is detected, the following error handling shall be applied : 2172
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 77/99
o If a node receives a first message that includes a remote AP ID which is erroneous 2173
e.g. an AP ID which has been stored previously for another UE-associated logical 2174
connection for the same peer node, the receiving node shall initiate an Error 2175
Indication procedure with inclusion of only the previously received AP ID from the 2176
peer node and an appropriate cause value. In this case, both nodes shall initiate a 2177
local release of any established UE-associated logical connection having the 2178
erroneous AP ID as local or remote identifier. 2179
o If a node receives a first returned message that includes a remote AP ID which has 2180
been stored previously for another UE-associated logical connection for the same 2181
peer node, or that includes an AP ID pair which is inconsistent (e.g. the local AP ID 2182
is unknown or already allocated to another UE-associated logical connection), the 2183
receiving node shall initiate an Error Indication procedure with inclusion of the 2184
received AP IDs from the peer node and an appropriate cause value. Both nodes 2185
shall initiate a local release of any established UE-associated logical connection 2186
(for the same S1 interface) having these AP IDs as local or remote identifier. 2187
o If a node receives a message (other than the first or first returned messages) that 2188
includes AP ID(s) identifying a logical connection which is unknown to the node 2189
(for the same S1 interface): 2190
- if this message is not the last message for this UE-associated logical connection, 2191
the node shall initiate an Error Indication procedure with inclusion of the 2192
received AP ID(s) from the peer node and an appropriate cause value. Both 2193
nodes shall initiate a local release of any established UE-associated logical 2194
connection (for the same S1 interface) having the erroneous AP ID(s) as local or 2195
remote identifier. 2196
- if this message is the last message for this UE-associated logical connection, 2197
the receiving node shall initiate a local release of any established UE-2198
associated logical connection (for the same S1 interface) that have either the 2199
local or remote AP ID(s) as identifiers. 2200
2201
4.16.4 HANDLING OF S1AP ERROR INDICATION IN RECEPTION 2202
The Error Indication procedure is initiated by a node to report detected errors in one incoming 2203
message, provided they cannot be reported by an appropriate failure message. 2204
If the error situation arises due to reception of a message utilising UE associated signalling, then 2205
the Error Indication procedure uses UE associated signalling. Otherwise the procedure uses non-UE 2206
associated signalling. The ERROR INDICATION message shall contain at least either the Cause IE or 2207
the Criticality Diagnostics IE. 2208
2209
On reception of an Error Indication, the eNB shall take appropriate actions, depending on the 2210
ongoing procedure state and on the type of detected error. This applies for both Class 1 and Class 2211
2 S1AP procedures. 2212
Defence mechanism based on supervision timers are already implemented in the eNB and most of 2213
the S1 procedures don’t need a specific handling of Error Indication. Log of Error Indication 2214
message for debug purpose and ignore received message is enough in most of the cases. 2215
Error Indication messages related to non-UE associated procedures are simply logged and ignored. 2216
Transfer Syntax Error, due to error detected in ASN1 decoding are simply logged and ignored. 2217
However, some UE associated procedures can be improved by adding a specific handling of Error 2218
Indication messages, mostly for Handover procedures. The following sections give details on these 2219
specific handling. 2220
An activation flag isS1EnhancementsAllowed enables to activate/deactivate specific Error 2221
Indication handling. 2222
Commentaire [ADW43] : <Start: SRS-026072-520, Requirement>
Feature Number: L97980 <End: SRS-026072-520>
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 78/99
4.16.4.1 ERRONEOUS S1AP IDS 2223
In case the Error Indication procedure is triggered by utilising UE associated signalling the MME UE 2224
S1AP ID IE and the eNB UE S1AP IE will be included in the ERROR INDICATION message. If one or 2225
both of MME UE S1AP ID IE and the eNB UE S1AP IE are not correct, the cause shall be set to 2226
appropriate value “Radio Network Layer” / "Unknown or already allocated MME UE S1AP ID", 2227
"Unknown or already allocated eNB UE S1AP" or "Unknown or inconsistent pair of UE S1AP ID". 2228
On reception of an Error Indication message with cause ”Unknown or already allocated MME UE 2229
S1AP ID”, “Unknown or already allocated eNB UE S1AP ID” or “Unknown or inconsistent pair of UE 2230
S1AP ID”, the eNB shall release the call(s) and resources related to these incorrect S1AP IDs. 2231
As per TS 36.413 ref [R6] section 10.6, both nodes shall initiate a local release of any established 2232
UE-associated logical connection having the erroneous AP ID as local or remote identifier. 2233
Consequently, the eNB shall release the Call (and possibly another one) for which the MME 2234
indicated a faulty MME S1AP ID and/or eNB S1AP ID. 2235
2236
4.16.4.2 ABSTRACT SYNTAX ERROR AND LOGICAL ERRORS 2237
On reception of an Error Indication message with cause not related to erroneous S1AP IDs, the eNB 2238
may take appropriate actions depending on the ongoing procedure. 2239
The UE context related to Error Indication message is retrieved with eNB S1AP ID. The procedure 2240
code IE and triggering message IE included in Error Indication identify the failed message and 2241
procedure. 2242
2243
A specific handling is defined in case of reception of an Error Indication in response of following 2244
messages: 2245
o Handover Required: the eNB shall stop the timer TS1RELOCprep and returns to previous 2246
state before handover preparation 2247
o Handover Request Acknowledge: the eNB shall stop the internal defence timer 2248
interEnbS1Ho and behaves as the timer would have expired, i.e. all UE resources are 2249
released 2250
o Path Switch Request: the eNB shall behave as it would have received the Path Switch 2251
Request Failure message, i.e. the call is released 2252
o Handover Cancel: the eNB shall behave as in case of reception of a Handover Cancel 2253
Acknowledge message 2254
2255
4.17. X2AP ERROR HANDLING 2256
To prepare eNB for forward compatibility between two different 3GPP standard levels on X2 2257
interface, the eNB should provide the following functionalities: 2258
� X2 error handling on common and dedicated procedures 2259
� Error handling at procedure level 2260
� Error handling at IE level 2261
� Protocol Error handling 2262
2263
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 79/99
4.17.1 ERROR HANDLING AT PROCEDURE LEVEL 2264
The eNB shall answer to a not supported procedure with an ERROR INDICATION message with 2265
cause set to misc/unspecified and the optional IE criticality diagnostics (procedure 2266
code/triggering message/procedure criticality). 2267
2268
4.17.2 ERROR HANDLING AT IE LEVEL 2269
Some IEs need to be supported to assure compatibility with another eNB release, they are 2270
detailed in related procedures (see documents ref [A1] and [A2]) for details. 2271
The same error handling has to be processed as on S1 interface at IE level (refer to section 2272
4.16.2). 2273
Some IEs are included in most of the X2AP messages. The eNB error handling for these IEs shall be 2274
the following: 2275
2276
IE/Group Name Error handling
Message type The assigned criticality of the message type defines the criticality of the associated procedure (see tables above)
Old eNB UE X2AP ID • Unknown Old eNB UE X2AP ID received : send failure message or ERROR INDICATION message with cause Radio Network Layer Cause, Unknown or already allocated Old eNB UE X2AP ID
New eNB UE X2AP ID • Unknown New eNB UE X2AP ID received : send failure message or ERROR INDICATION message with cause Radio Network Layer Cause, Unknown or already allocated New eNB UE X2AP ID
Mandatory IE missing in a message with assigned criticality reject
The procedure shall be rejected with a failure message if it exists or an ERROR INDICATION message with criticality Diagnostic IE
2277
As per 36.423 ref [R7] section 8.2.1.3, the source eNB shall ignore any HANDOVER REQUEST 2278
ACKNOWLEDGE or HANDOVER PREPARATION FAILURE message received after the initiation of the 2279
Handover Cancel procedure and remove any reference and release any resources related to the 2280
concerned X2 UE-associated signalling. In consequence, any HANDOVER REQUEST ACKNOWLEDGE 2281
or HANDOVER PREPARATION FAILURE message received with an unknown Old eNB UE X2AP ID. 2282
2283
2284
4.17.3 PROTOCOL ERROR HANDLING 2285
According to TS 36.423, protocol error is handled in the same way as for S1 interface. The 2286
protocol error handling defined in section 4.16.3 for S1 interface applies to X2 interface. 2287
2288
• Transfer Syntax Error: this error occurs when the receiver is not able to decode the 2289
received physical message. They are detected in the process of ASN1 decoding. 2290
Error handling: when detecting a Transfer Syntax Error on X2 interface the eNB should 2291
ignore the message and send Error Indication (transfer-syntax-error). 2292
Examples of Transfer Syntax Error: 2293
o Value range violation, 2294
o Violation in list element constraints (list longer than allowed…) 2295
Commentaire [ADW44] : <Start: SRS-026072-390, Other>
Feature Number: CR 00241909 Author: Martine Gateau
<End: SRS-026072-390>
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 80/99
o Missing mandatory elements in a sequence 2296
o Wrong order of elements in a sequence 2297
• Abstract Syntax Error: this error occurs when the receiving functional X2AP entity 2298
receives: 2299
� IEs or IE groups that cannot be understood (unknown IE ID) 2300
� IEs for which the logical range is violated 2301
� Missing mandatory IEs or IE groups 2302
� IEs or IE groups received in wrong order or with too many occurrences 2303
� Missing conditional IE or IE group when condition is verified or conditional IE or IE 2304
group present when the condition is not verified 2305
Error handling: 2306
Error cases 1 and 2 are handled based on received criticality information 2307
Error case 3 is handled based on criticality and presence information for the missing 2308
IE/IE group specified in the version of the specification used by the receiver. 2309
If criticality is set to “ignore”, the procedure continues as if the IE had not been 2310
received. If criticality is set to “reject”, the handling is the following: 2311
� Initiated message of a procedure with an unsuccessful response message: 2312
send unsuccessful response with cause Abstract Syntax Error (Reject) and 2313
include the Criticality Diagnostic IE. In case the information present in the 2314
initiating message was insufficient to determine a value for all IEs that are 2315
required to be present in the unsuccessful outcome procedure, the 2316
receiving node shall instead initiate an Error Indication procedure. 2317
� Initiated message of a procedure without an unsuccessful response 2318
message: send Error Indication message with cause Abstract Syntax Error 2319
(Reject) and include the Procedure Code IE, the Triggering message IE, 2320
the Procedure Criticality IE and the Criticality Diagnostic IE. 2321
� Response message of a procedure: consider the procedure unsuccessfully 2322
terminated and perform local error handling. 2323
Error cases 4 and 5 result in rejecting the procedure. None of the functional 2324
requests of the message shall be executed. 2325
� Initiated message of a procedure with an unsuccessful response message: 2326
send unsuccessful response with cause Abstract Syntax Error (Falsely 2327
Constructed Message). In case the information present in the initiating 2328
message was insufficient to determine a value for all IEs that are required 2329
to be present in the unsuccessful outcome procedure, the receiving node 2330
shall instead initiate an Error Indication procedure. 2331
� Initiated message of a procedure without an unsuccessful response 2332
message: send Error Indication message with cause Abstract Syntax Error 2333
(Falsely Constructed Message) and include the Procedure Code IE, the 2334
Triggering message IE, the Procedure Criticality IE and the Criticality 2335
Diagnostic IE. 2336
� Response message of a procedure: consider the procedure unsuccessfully 2337
terminated and perform local error handling. 2338
2339
• Logical Error: this error occurs when a message is comprehended correctly, but the 2340
information contained within the message is not valid (i.e. semantic error), or describes a 2341
procedure which is not compatible with the state of the receiver 2342
Error handling: depends on class procedure 2343
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 81/99
Class 1 procedures: if the procedure has a message to report an unsuccessful 2344
outcome, it is sent with an appropriate cause value (Semantic Error, Message not 2345
compatible with receiver state). When no unsuccessful outcome message exists, an 2346
Error Indication procedure shall be initiated with an appropriate cause value, 2347
Procedure Code IE, the Triggering message IE and the Criticality Diagnostic IE. 2348
Class 2 procedures: the procedure shall be terminated and the Error Indication 2349
procedure shall be initiated with an appropriate cause value, Procedure Code IE, the 2350
Triggering message IE and the Criticality Diagnostic IE. 2351
2352
The protocol error handling described hereafter shall take precedence over any other error 2353
handling. 2354
• If any type of error (Transfer Syntax Error, Abstract Syntax Error or Logical Error) is 2355
detected in the ERROR INDICATION message, it shall not trigger the Error Indication 2356
procedure in the receiving Node but local error handling. 2357
• In case a response message or Error Indication message needs to be returned, but the 2358
information necessary to determine the receiver of that message is missing, the procedure 2359
shall be considered as unsuccessfully terminated and local error handling shall be 2360
initiated. 2361
• If an error that terminates a procedure occurs, the returned cause value shall reflect the 2362
error that caused the termination of the procedure even if one or more abstract syntax 2363
errors with criticality "ignore and notify" have earlier occurred within the same procedure. 2364
• If an UE X2AP ID error is detected, the following error handling shall be applied : 2365
o If a node receives a first message that includes a remote AP ID which is erroneous 2366
e.g. an AP ID which has been stored previously for another UE-associated logical 2367
connection for the same peer node, the receiving node shall initiate an Error 2368
Indication procedure with inclusion of only the previously received AP ID from the 2369
peer node and an appropriate cause value. In this case, both nodes shall initiate a 2370
local release of any established UE-associated logical connection having the 2371
erroneous AP ID as local or remote identifier. 2372
o If a node receives a first returned message that includes a remote AP ID which has 2373
been stored previously for another UE-associated logical connection for the same 2374
peer node, or that includes an AP ID pair which is inconsistent (e.g. the local AP ID 2375
is unknown or already allocated to another UE-associated logical connection), the 2376
receiving node shall initiate an Error Indication procedure with inclusion of the 2377
received AP IDs from the peer node and an appropriate cause value. Both nodes 2378
shall initiate a local release of any established UE-associated logical connection 2379
(for the same X2 interface) having these AP IDs as local or remote identifier. 2380
o If a node receives a message (other than the first or first returned messages) that 2381
includes AP ID(s) identifying a logical connection which is unknown to the node 2382
(for the same X2 interface): 2383
- if this message is not the last message for this UE-associated logical connection, 2384
the node shall initiate an Error Indication procedure with inclusion of the 2385
received AP ID(s) from the peer node and an appropriate cause value. Both 2386
nodes shall initiate a local release of any established UE-associated logical 2387
connection (for the same X2 interface) having the erroneous AP ID(s) as local or 2388
remote identifier. 2389
- if this message is the last message for this UE-associated logical connection, 2390
the receiving node shall initiate a local release of any established UE-2391
associated logical connection (for the same X2 interface) that have either the 2392
local or remote AP ID(s) as identifiers. 2393
2394
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 82/99
4.17.4 HANDLING OF X2AP ERROR INDICATION IN RECEPTION 2395
In LA3.0, Error Indication messages received from peer eNB are simply logged and ignored. 2396
No specific handling is done by ENB on reception of these messages. 2397
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 83/99
5. OAM MODEL DESCRIPTION 2398
5.1. LTE CELL 2399
5.1.1 DATA MODEL 2400
The following figures represent the LteCell data model. 2401
LteCell
[0..1]
[0..1]
FrequencyAnd
BandwidthFDD
FrequencyAnd
BandwidthTDD
LteCell
FDD
LteCell
TDD
TxDivOr
MimoResources
Mimo
Configuration
PowerOffset
Configuration
Uplink
MIMO
Downlink
MIMO
Codebook
Subset
Restriction
[0..1]
[0..1]
[0..1]
Downlink
MIMOFDD
[0..1]
Downlink
MIMOTDD
BeamForming
[0..1]
SimoResources
[0..1]
PowerOffset
Configuration
[0..1]
Uplink
Mimo
2402
2403
Figure 29: Data Model For LteCell (1/6) 2404
2405
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 84/99
LteCell
CellL1L2Control
ChannelsConf
CellL2ULConf
L1Measurement
Conf
CellL2DlConfCellL1ULConf
[0..1]
[0..1]
CellL1Ul
ConfFDD
CellL1Ul
ConfTDD
[0..1]CellL2Dl
ConfTDD
[0..1]CellL2Dl
ConfTDD
ULPowerControl
Conf
CellicicConf
X2Load
IndicationConf[0..1]
2406
2407
Figure 30: Data Model For LteCell (2/6) 2408
2409
LteCell
CellSelectionReselectionConf
AccessBarring
AccessBarringForSignaling
AccessBarringForOriginating
Calls
CellRachConf
[0..1]
[0..1]
CellRachConfFDD
CellRachConfTDD
RadioCacCell
CellActivationService
SysInfoConf
2410
2411
Figure 31: Data Model For LteCell (3/6) 2412
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 85/99
LteCell
[0..48]
LteNeighboring
CellRelation
RRC
MeasurementConf
X2Access
[0..1]
[1..9]
CellReselection
ConfLte
LteNeighboring
FreqConf
[0..1]
[0..1]
LteNeighboring
LteSpeed
DependentConf
[0..16]
BlackCell
Conf
SpeedState
EvalConf
Mobility
PriorityTable
[0..3]
ServiceType
PriorityConf
2413
2414
Figure 32: Data Model For LteCell (4/6) 2415
2416
2417
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 86/99
LteCell
[0..16]
UtraFdd
Neighboring
FreqConf
[0.. 32]
UtraFdd
Neighboring
CellRelation
CellReselection
ConfUtraFddRncAccess
[0..1]
[0..1]
Utra
Neighboring
[0..1]
UtraSpeed
DependentConf
Mobility
PriorityTable
[0..3]
ServiceType
PriorityConf
[0..16]
[0.. 32]
Mobility
PriorityTable
[0..3]
ServiceType
PriorityConf
UtraTdd
Neighboring
FreqConf
CellReselection
ConfUtraTdd
UtraTdd
Neighboring
CellRelation
[0..1]
[0..3]
2418
2419
Figure 33: Data Model For LteCell (5/6) 2420
2421
2422
Commentaire [gme45] : <Start: SRS-026072-CC-160, Other>
Feature Number: L103792 Author: Christian Collin
<End: SRS-026072-CC-160>
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 87/99
2423
LteCell
[0..1]
[0..16]
GeranNeighboring
FreqsConf
Geran
Neighboring
CellReselection
ConfGeran
[0..32]
Geran
Neighboring
CellRelation
BscAccess
[0..1]
GeranSpeed
DependentConf
Mobility
PriorityTable
[0..3]
ServiceType
PriorityConf
HrpdNeighboring
[0..1]
[1..2]
HrpdBand
ClassConf
CellReselection
ConfHrpd
HrpdNeighboring
PerCarrier
[0..1]
HrpdSpeed
DependentConf
Mobility
PriorityTable[0..3]
ServiceType
PriorityConf
[0..3]
2424
2425
Figure 34: Data Model For LteCell (6/6) 2426
2427
5.1.2 OBJECT STATE MANAGEMENT 2428
During the Cell setup, the following states changes of the LteCell MO are sent to the OMC: 2429
Table 3: LteCell State Management 2430
Meaning LteCell MO states attributes (operational/availability)
Supporting hardware is not available Disabled/Dependency
Sector and a modem are available and cell setup can start
Disabled/.
Cell setup is successful and the System Information is broadcast. Cell is not barred.
Enabled/.
Cell setup has failed Disabled/Failed
Cell is locked Disabled/Off line
Cell is barred (refer to section 4.2.7.3 for details) Enabled/ Off-duty
2431
Note 1: LteCell::administrativeState is not propagated to CallP, the manager of LteCell (this is true 2432
in LA2.x/LA3.x), meaning CallP does not know when a cell gets locked. Upon reception of a common 2433
trigger – AVCN(PHY CELL, disabled, off-duty) – the CallP sets the operational and availability status 2434
of the cell to 'Disabled/ Dependency'. 2435
2436
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 88/99
Cell initial state
LteCell
Disabled
Dependency
LteCell
Disabled
(None)
LteCell
Enabled
(None)
LteCell
Disabled
Failed
A sector and modem become
available: cell setup may begin
Sector and modem
become unavailable
Cell setup is successful and
System Information is broadcast (cell not barred)
Sector and modem
become unavailable
Cell setup fails
Sector and modem
become unavailable
LteCell
Disabled
Off line
Cell is locked
LteCell
Enabled
Off duty
Cell is barred
Sector and modem
become unavailable
LteCell
(any state)
Cell is unlocked and modem is available: cell setup may begin
Cell is unlocked and modem is not available
Cell is unbarred
Cell setup is successful and
System Information is broadcast (cell barred by operator)
2437
Figure 35: LteCell State Diagram 2438
2439
After successful cell setup the eNB can self-trigger cell barring (See 4.2.7.3), transition 2440
the state of LteCell to “Enabled/ Off-duty”. 2441
With CR #269239, when no S1 link is operational during the cell setup, the cell will first 2442
be changed from “Disabled/None” to “Enabled/None”. The cell starts radiating and Sys 2443
Info is broadcast while S1 links setup is still in progress. After timer expiry (see 2444
section 4.2.7.3), if no S1 link is operational, the cell will be autobarred by eNB and 2445
becomes “Enabled/Off duty”. 2446
2447
Refer to state description above for details about LteCell state management in this 2448
case. 2449
2450
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 89/99
5.2. MME ACCESS 2451
5.2.1 DATA MODEL 2452
S1AccessGroup
MmeAccessGroup
MmeQosConf
MmeAccess
MmeSctpLayerConf
MmeTransport
LayerAccess
[1..16]
S1Timers
[1..2]
[0..2]
[0..2]
S1Ho
TimersConf
PsHoTo
Utra
TimersConf
Nacc
TimersConf
availabilityStatus [FM]operationalState [FM]sctpAssocRemAddrsctpAssocRemAddrIpv6
dscpForMmevLanPriority
SctpAccessAssociationMaxRetranssctpAccessEstablishmentMaxRetriessctpAccessEstablishmentRetryIntervalsctpAccessMaxInitRetransmitssctpAccessPathMaxRetranssctpAssocHeartbeatInterval
endS1HoDataFwdTargettS1RelocOverallForS1HandovertS1RelocPrepForS1Handover
availabilityStatus [FM]operationalState [FM]administrativeState [CM]uniqueNamepriority
tS1RelocOverallForPsHandoverToUtratS1RelocPrepForPsHandoverToUtra
timeToWaitForEnbDirectInfoTransfertMobilityFromEutraCots1EnbDirectInfoTransferTrir
Enb
2453
2454
Figure 36: Data Model For S1-MME 2455
5.2.2 OBJECT STATE MANAGEMENT 2456
Following states are managed for S1 supervision. Associated state changes are sent to the 2457
OMC for display in the supervision view: 2458
Table 4: MmeAccess State Management 2459
Meaning MmeAccess MO states attributes (operational/availability)
MmeTransportLayerAccess (SCTP association) is not enabled
Disabled/Dependency
SCTP association is up, and S1 Setup Request has Disabled/.
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 90/99
been sent
S1 SCTP association is up, and S1 Setup Failure has been received or no answer received to several S1 Setup Request
Disabled/Failed
S1 setup procedure is successful Enabled/.
S1 link is locked (through MMEAccess administrativeState)
Disabled/Offline
2460
MMEAccess
Disabled
Dependency
MMEAccess
Disabled
(None)
MMEAccess
Enabled
(None)
MMEAccess
Disabled
Failed
Trigger: MMETransportLayerAccess becomes Enabled / None
Action: S1 Setup Request sent to MME
Trigger: No response to S1 Setup Request or S1 Setup Failure received
Action: wait before sending next S1 Setup Request
Trigger: S1 Setup Response received from MME
Trigger: S1 Setup Response received from MME
MMEAccess
(any state)
Trigger: MMETransportLayerAccess leaves state Enabled / None
MA4
MA3
MA5
MA2
MA1
No response to S1 Setup Request
or S1 Setup Failure received
MA6
MMEAccess
Disabled
Offline
Trigger: MMEAccess is locked
Trigger: MMEAccess is unlocked
MA7
MA8
2461
Figure 37: MMEAccess State Diagram 2462
2463
State transitions have been numbered (MA1, MA2, etc.) to facilitate cross-referencing in 2464
this and other documents. In the diagram above, transition MA6 differs from the other 2465
transitions in that no state change is generated. The idea is that once the first state 2466
change to Disabled/Failed has been sent, if the S1 setup continues to fail repetitively 2467
(through no response to S1 Setup Request or reception of S1 Setup Failure), the eNB will 2468
not repeat the state change. This avoids duplicating events unnecessarily and flooding the 2469
OAM. 2470
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 91/99
5.3. X2 ACCESS 2471
5.3.1 DATA MODEL 2472
X2AccessGroup
X2QosConf
X2Access
[0..32]
X2SctpLayerConf
X2GtpConf
LteNeighboring
CellRelation
X2QosMqpping
[1..255]
X2Transport
LayerAccess
S1Ho
TimersConf
availabilityStatus [FM]operationalState [FM]administrativeState [CM]uniqueNamedirectFwdPathAvailabilitymacroEnbIdnoRemovenoX2noX2HOplmnMobileCountryCodeplmnMobileNetworkCode
availabilityStatus [FM]operationalState [FM]sctpAssocRemAddrsctpAssocRemAddrIpv6
sctpAccessEstablishmentMaxRetriessctpAccessEstablishmentRetryIntervalsctpAccessLinkFailureMaxRetriessctpAccessLinkFailureRetryIntervalsctpAssocHeartbeatInterval
endX2HoDataFwdTargetn3Requestt3Responsex2EchoRequestInterval
dscpserviceProfilevLanPriority
Enb
[0.1]
2473
2474
Figure 38: Data Model For X2AP 2475
2476
5.3.2 OBJECT STATE MANAGEMENT 2477
Following states are managed for X2 supervision. Associated state changes are sent to the 2478
OMC for display in the supervision view: 2479
Table 5: X2Access State Management 2480
Meaning X2Access MO states attributes (operational/availability)
X2TransportLayerAccess (SCTP association) is not enabled
Disabled/Dependency
SCTP association is up, and X2 Setup Request has been sent
Disabled/.
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 92/99
X2 SCTP association is up, and X2 Setup Failure has been received or no answer received to several X2 Setup Request
Disabled/Failed
X2 setup procedure is successful Enabled/.
X2 link is locked (through X2Access administrativeState) or black-listed (through X2Access noX2)
Disabled/Off line
X2 link is released by ANR garbage collection mechanism
Disabled/Off line
2481
X2Access initial stateon creation through X2
SETUP REQUEST received (ANR)
X2Access initial state at eNB start-up or at creation through new neighbour PCI discovered (ANR)
X2Access
DisabledDependency
X2Access
Disabled(None)
X2Access
Enabled(None)
X2Access
DisabledFailed
Trigger: X2TransportLayerAccess becomes Enabled/NoneAction: X2 Setup Request sent to peer eNB
Trigger: No response to X2 Setup Request or X2 Setup Failure receivedAction: wait before sending X2 Setup Request
Trigger: X2 Setup Response received from peer eNB
Trigger: X2 Setup Response received from peer eNB,or X2 Setup Request received from
peer eNB and X2 Setup Response sent
Trigger: X2 Setup Request received from peer eNB and X2 Setup Response sent
X2Access
(any state) Trigger: X2TransportLayerAccess leaves state Enabled / None
XA6
XA3XA5
XA4XA2
XA1
No response to X2 Setup Requestor X2 Setup Failure received
XA7
X2Access
DisabledOffline
Trigger: X2 link is locked or blacklisted, repeated eNB Configuration Update failureAction: send an SCTP SHUTDOWN
XA8
Trigger: X2 link is un-locked or un-blacklisted, SCTP Shutdown following eNB Configuration UpdateAction: send an SCTP INIT
Trigger: an X2 link is not used (e.g. ANR garbage collection) – not whitelisted or blacklistedAction: send an SCTP SHUTDOWN
XA10
XA12
2482
Figure 39: X2Access State Diagram 2483
2484
State transitions have been numbered (XA1, XA2, etc.) to facilitate cross-referencing in 2485
this and other documents. In the diagram above, transition XA7 differs from the other 2486
transitions in that no state change is generated. The idea is that once the first state 2487
change to Disabled/Failed has been sent, if the X2 setup continues to fail repetitively 2488
(through no response to X2 Setup Request or reception of X2 Setup Failure), the eNB will 2489
not repeat the state change. This avoids duplicating events unnecessarily and flooding the 2490
OAM. 2491
2492
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 93/99
6. ABBREVIATIONS AND DEFINITIONS 2493
6.1. ABBREVIATIONS 2494
ASN1 Abstract Syntax Notation One BCCH Broadcast Control Channel BCH Broadcast Channel CCCH Common Control Channel CN Core Network CQI Channel Quality Indicator CR Change Request DL-SCH Downlink Shared Channe DRX Discontinuous Reception (RX) EDGE Enhanced Data Rates for GSM Evolution eNB E-NodeB ETWS Earthquake and Tsunami Warning System FIFO First In First Out GERAN GSM EDGE Radio Access Network GSM Global System for Mobile communications HO Handover IE Information Element IMSI International Mobile Subscriber Identity KPI Key Product Indicator LS Liaison Statement LTE Long Term Evolution MAC Medium Access Control MCCH Multicast Control Channel MCH Multicast Channel MIB Master Information Block MIM Managed Information Model MME Mobility Management Entity MO Managed Object NE Network Element OAM Operation And Maintenance PBCH Physical Broadcast Channel PCCH Paging Control Channel PCFICH Physical Control Format Indicator Channel PCH Paging Channel PDCCH Physical Downlink Control channel PDSCH Physical Downlink Shared channel PHICH Physical Hybrid ARQ Indicator Channel PLMN Public Land Mobile Network PMCH Physical Multicast Channel PRACH Physical random access channel PUCCH Physical Uplink Control Channel PUSCH Physical Uplink Shared Channel RACH Random Access Channel RAT Radio Access Technology RLC Radio Link Control RNTI Radio Network Temporary Identity RRC Radio Resource Control S1AP S1 Application Protocol SCTP Stream Control Transmission Protocol SFN System Frame Number SI System Information SIB System Information Block
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 94/99
TAC Tracking Area Code TAI Tracking Area Identity TMSI Temporary Mobile Subscriber Identity TNL Transport Network Layer UE User Equipment UL-SCH Uplink Shared Channel UMTS Universal Mobile Telecommunications System UTRAN UMTS Terrestrial Radio Access Network X2AP X2 Application Protocol WPS Wireless Provisioning System 2495
2496
6.2. DEFINITIONS 2497
2498
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 95/99
ANNEX A: MASTER INFORMATION BLOCK AND SFN 2499
MASKING 2500
The System Frame Number or SFN is managed in the low layers of the eNB, and unknown 2501
to the application layer (call processing) in charge of performing the ASN1 encoding of the 2502
Master Information Block. The application shall therefore encode the Master Information 2503
Block using a default SFN with all bits set to 1, and the lower layers will replace it with the 2504
actual SFN at the moment of sending the Master Information Block. 2505
Bits 7 to 14 are the bits that must be replaced by the current SFN, as explained below. The 2506
assumption here is that the first and leftmost bit is numbered 1, and the last and 2507
rightmost bit is numbered 24. 2508
Master Information Block is the only message sent on BCCH carried by BCH, so no bits are 2509
required to identify it. The first bit is therefore the first bit of the message itself. 2510
BCCH-BCH-Message ::= SEQUENCE { 2511
message BCCH-BCH-MessageType 2512
} 2513
2514
BCCH-BCH-MessageType ::= MasterInformationBlock 2515
2516
MasterInformationBlock ::= SEQUENCE { 2517
dl-Bandwidth ENUMERATED { 2518
n6, n15, n25, n50, n75, n100, spare2, spare1}, 2519
phich-Configuration PHICH-Configuration, 2520
systemFrameNumber BIT STRING (SIZE (8)), 2521
spare BIT STRING (SIZE (10)) 2522
} 2523
2524
PHICH-Configuration ::= SEQUENCE { 2525
phich-Duration ENUMERATED { normal, extended }, 2526
phich-Resource ENUMERATED { oneSixth, half, one, two } 2527
} 2528
Three bits are required to encode 8 possible values for the dl-Bandwidth (bits 1 to 3 of the 2529
message). 2530
One bit is required to encode the 2 values for phich-Duration, and two bits for the 4 values 2531
of phich-Resource, giving a total of three bits for phich-Configuration (bits 4 to 6 of the 2532
message). 2533
The systemFrameNumber is coded on 8 bits (bits 7 to 14 of the message). 2534
The final 10 spare bits correspond to bits 15 to 24 of the Master Information Block. 2535
2536
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 96/99
ANNEX B: SYSTEM INFORMATION MESSAGE SIZE 2537
Scheduling of System Information blocks (or, in other words, the mapping of System 2538
Information blocks to System Information messages) and the reservation of the necessary 2539
resource blocks requires knowledge of the System Information block sizes and of the total 2540
System Information message size. Call processing pre-encodes System Information blocks 2541
and provides their sizes, and System Information Message size can be calculated based on 2542
the System Information Block sizes. 2543
The System Information message is sent on BCCH carried on DL-SCH. 2544
BCCH-DL-SCH-Message ::= SEQUENCE { 2545
message BCCH-DL-SCH-MessageType 2546
} 2547
2548
BCCH-DL-SCH-MessageType ::= CHOICE { 2549
c1 CHOICE { 2550
systemInformation SystemInformation, 2551
systemInformationBlockType1 SystemInformationBlockType1 2552
}, 2553
messageClassExtension SEQUENCE {} 2554
} 2555
One bit is necessary to encode the choice between "c1" and " messageClassExtension" for 2556
BCCH-DL-SCH-MessageType. 2557
One bit is necessary to encode the choice between " systemInformation" and " 2558
systemInformationBlockType1". 2559
SystemInformation ::= SEQUENCE { 2560
criticalExtensions CHOICE { 2561
systemInformation-r8 SystemInformation-r8-IEs, 2562
criticalExtensionsFuture SEQUENCE {} 2563
} 2564
} 2565
One bit is necessary to encode the choice between " systemInformation-r8" and " 2566
criticalExtensionsFuture". 2567
SystemInformation-r8-IEs ::= SEQUENCE { 2568
sib-TypeAndInfo SEQUENCE (SIZE (1..maxSIB)) OF CHOICE { 2569
sib2 SystemInformationBlockType2, 2570
sib3 SystemInformationBlockType3, 2571
sib4 SystemInformationBlockType4, 2572
sib5 SystemInformationBlockType5, 2573
sib6 SystemInformationBlockType6, 2574
sib7 SystemInformationBlockType7, 2575
sib8 SystemInformationBlockType8, 2576
sib9 SystemInformationBlockType9, 2577
sib10 SystemInformationBlockType10, 2578
sib11 SystemInformationBlockType11, 2579
... 2580
}, 2581
nonCriticalExtension SEQUENCE {} OPTIONAL -- Need OP 2582
} 2583
2584
maxSIB INTEGER ::= 32 -- Maximum number of SIBs 2585
One bit represents the presence of optional "nonCriticalExtension" within the 2586
SystemInformation-r8-IEs sequence. 2587
Five bits are necessary to encode the number of elements (from 1 to 32) in sequence sib-2588
TypeAndInfo. 2589
One bits is necessary to encode the extension marker ("…") in the CHOICE structure of sib-2590
TypeAndInfo. 2591
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 97/99
Four bits are necessary to encode the 10 possible values for the CHOICE structure of sib-2592
TypeAndInfo (sib2 to sib11). 2593
Prior to LA3.0, there is only one System Information Block in each System Information 2594
Message. The total size for the System Information message is therefore 14 bits (identified 2595
above) plus the size of the System Information Block that is contained within it. This total 2596
size is the one to use for resource block reservation. Obviously, the System Information 2597
message may eventually be padded with zeros for octet alignment and / or resource block 2598
size alignment. 2599
L108958 (Sys-Info Scheduling Improvements) in LA3.0 supportsmultiple System Information 2600
Blocks within a single System Information Message as determined by the DL Scheduler. In 2601
this case, the formula for System Information Message size calculation is the following 2602
(assuming no extensions are used): 2603
Total size = (9 bits of non-extended "header") + n * (5 bits of non-extended CHOICE 2604
identifier) + ∑n
(System Information Block size) 2605
Where n is the number of System Information Blocks encoded in a single System Information 2606
Message. 2607
2608
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 98/99
ANNEX C: PAGING MESSAGE ENCODING 2609
As specified in section 4.3.2, CallP encodes individual paging records and it is the 2610
Scheduler's responsibility to assemble the RRC Paging message. Here is how this must be 2611
done. 2612
The RRC Paging message is carried on PCCH. 2613
2614
PCCH-Message ::= SEQUENCE { 2615
message PCCH-MessageType 2616
} 2617
2618
PCCH-MessageType ::= CHOICE { 2619
c1 CHOICE { 2620
paging Paging 2621
}, 2622
messageClassExtension SEQUENCE {} 2623
} 2624
The first bit is set to 0 to indicate choice "c1" in the PCCH-MessageType. The first and 2625
leftmost bit of the RRC Paging message is numbered 1 and the following bits are numbered 2626
2, 3, etc. 2627
Paging ::= SEQUENCE { 2628
pagingRecordList PagingRecordList OPTIONAL, -- Need ON 2629
systemInfoModification ENUMERATED { true } OPTIONAL, -- Need ON 2630
etws-Indication ENUMERATED { true } OPTIONAL, -- Need ON 2631
nonCriticalExtension SEQUENCE {} OPTIONAL -- Need OP 2632
} 2633
Bit number 2 is set to 1 to indicate that the pagingRecordList is present. 2634
Bit number 3 is set to 1 if there is going to be a change in System Information (as specified 2635
in section 4.2.4), and set to 0 otherwise. 2636
Bits number 4 and 5 are set to 0 to indicate that etws-Indication and nonCriticalExtension 2637
are absent (these are not supported in LA3.0). 2638
PagingRecordList ::= SEQUENCE (SIZE (1..maxPageRec)) OF PagingRecord 2639
Bits number 6 to 9 are set to "0000" to indicate that the PagingRecordList contains 1 2640
PagingRecord. In LA3.0, the eNB does not support multiple paging records in the same RRC 2641
Paging message. 2642
In order to assemble an RRC Paging message, in LA3.0 the Scheduler therefore 2643
concatenates 9 bits set to "0100 0000 0" if there is no change in system information or 2644
"0110 0000 0" otherwise, followed by the paging record pre-encoded by CallP. If a Paging 2645
message must be sent to signify an upcoming change in System Information when there are 2646
no paging records to send, the Paging message is simply the sequence "0010 0000 0". The 2647
resulting bitstring is eventually padded with zeros for octet alignment and / or resource 2648
block size alignment. 2649
2650
EUTRAN Cell and Interface Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization
LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 99/99
ANNEX D: PAGING MESSAGE SIZE FOR RESOURCE 2651
BLOCK RESERVATION 2652
The Scheduler pre-reserves resource blocks for the RRC Paging message, based on its 2653
maximum theoretical size. 2654
In LA3.0, the RRC Paging will contain at most one paging record and none of the optional 2655
parameters, therefore the maximum message size is 9 bits (see previous section) plus the 2656
maximum size of one paging record, detailed hereafter. 2657
PagingRecord ::= SEQUENCE { 2658
ue-Identity PagingUE-Identity, 2659
cn-Domain ENUMERATED { ps, cs }, 2660
... 2661
} 2662
2663
PagingUE-Identity ::= CHOICE { 2664
s-TMSI S-TMSI, 2665
imsi IMSI, 2666
... 2667
} 2668
2669
maxPageRec INTEGER ::= 16 2670
2671
S-TMSI ::= SEQUENCE { 2672
mmec MMEC, 2673
m-TMSI BIT STRING (SIZE (32)) 2674
} 2675
2676
MMEC ::= BIT STRING (SIZE (8)) 2677
2678
IMSI ::= SEQUENCE (SIZE (6..21)) OF IMSI-Digit 2679
2680
IMSI-Digit::= INTEGER (0..9) 2681
2682
One bit is needed to encode the extension marker ("…") of the PagingRecord sequence. 2683
One bit is needed to encode the extension marker ("…") of the PagingUE-Identity choice. 2684
One bit is needed to encode the choice between s-TMSI and imsi for the PagingUE-Identity. 2685
An S-TMSI is coded on 40 bits (8 bits for mmec, 32 bits for m-TMSI). 2686
An IMSI is coded on 28 to 88 bits: 4 bits are needed to code the number of digits (from 6 to 2687
21), each digit is coded on 4 bits. 2688
One bit is needed to code the cn-Domain. 2689
The maximum paging record size is therefore obtained with a 21 digit IMSI and equals 92 2690
bits, leading to an RRC Paging message size of 101 bits. 2691
2692
In the future the eNB will support multiple paging records within a single RRC Paging 2693
message. When this happens, resource block reservation will have to be based on a 2694
reasonable paging message size. It would be inefficient to reserve blocks for a hypothetical 2695
message composed of 16 records of 21 digit IMSI each (leading to a total size of 1481 bits – 2696
9 + 16*92), when in reality a UE is most often paged with its 40 bit S-TMSI. In comparison, 2697
a Paging composed of 16 S-TMSI paging records is 713 bits (9 + 16*44). Moreover, in most 2698
currently deployed networks the IMSI is coded on 15 digits. 2699
2700
���� END OF DOCUMENT 2701
Recommended