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