EUTRAN Cell and Interface Management%2Dv03 12

EUTRAN Cell and Interface Management

Document number: LTE/SYS/DD/026072 Document issue: 03.12 / EN Document status: Approved-Standard Date: 10/Feb/2011

Passing on or copying of this document, use and communication of its contents not permitted 1

without Alcatel�Lucent written authorization 2

Copyright 2009 Alcatel-Lucent, All Rights Reserved 3

Printed in France 4

5

6

7

UNCONTROLLED COPY: The master of this document is stored on an electronic database and is “write 8

protected”; it may be altered only by authorized persons. While copies may be printed, it is not recommended. 9

Viewing of the master electronically ensures access to the current issue. Any hardcopies taken must be 10

regarded as uncontrolled copies. 11

ALCATEL-LUCENT CONFIDENTIAL: The information contained in this document is the property of Alcatel-12

Lucent. Except as expressly authorized in writing by Alcatel-Lucent, the holder shall keep all information 13

contained herein confidential, shall disclose the information only to its employees with a need to know, and 14

shall protect the information from disclosure and dissemination to third parties. Except as expressly authorized 15

in writing by Alcatel-Lucent, the holder is granted no rights to use the information contained herein. If you 16

have received this document in error, please notify the sender and destroy it immediately. 17


Passing on or copying of this document, use and communication of its contents not permitted without Alcatel�Lucent written authorization

LTE/SYS/DD/026072 03.12 / EN Approved-Standard 10/Feb/2011 Page 2/99

PUBLICATION HISTORY 18

Version Date Authors Chapter Change description

03.12 10/Feb/10 J. Wang

Section 4.2.6: Updated to align with LA3 implementation that avoids modem reset due to Cell Lock.

Section 4.2.4.5: Added text to reflect updated (L84876) FPSA that the platform provides a TimeOffset (to 1PPS) to the DL Scheduler.

Section 5.1.2: note added to LteCell State management

03.11 16/Dec/10 M. Gateau Section 4.12.2: clarification on interaction between RESET and ENB CONFIGURATION UPDATE procedures.

03.10 20/Aug/10 M. Gateau

Sections 4.4.3.1 and 4.4.3.2: CR #325845 : clear of S1 Setup failure and no response alarms on SCTP shutdown

Section 4.4.3.1: CR #323751 : a new alarm is sent in case of encoding problem of S1 Setup

Update to add precisions on activation flag related to L97980 (section 4.5 and 4.16.4).

Clarifications on X2 setup and X2 enb configuration update failure cases (section 4.10.2.1 and 4.11.2.1)

03.09 12/Aug/10

Wang Yunhua

Merged version for FDD and TDD

03.08T3 12/July/10 Wang Yunhua

Section 4.4.3.1, 4.4.3.2: updated with CR #321636 : S1 setup infinite retry in case of failure or no response

Section 4.2.3.2: SIB8 size correction

Tag number synchronized to be SRS-026072-x

03.08 06/July/10 M. Gateau

Section 4.2.4.5: figure 4.2.9 and following text updated.

Section 4.2.3.2: SIB5 size calculation updated

Section 4.2.7.3: CR #284246 descoped to further release – value notBarredAutoBarrable restored.

L101845 not supported in LA3.0/TLA3.0 (section 1.2, 4.8, 4.9, 4.14, 4.15

03.07T2 2/Jul/10 Wang Yunhua

Updated for TLA3.0 stream Add the impacts for eMBMS

03.07 19/May/10 M. Gateau

Section 4.15: MME selection algorithm updated

Section 5: update LTE Cell, S1-MME and X2AP data models




Section 4.4.5: updated with CR #269239

Section 4.12.1: precision added on cause value for X2 reset for test purpose

Section 4.2.7.3: CR #284246 - value notBarredAutoBarrable removed for object LteCell::cellBarred

03.06T1 12/May/10 Wang Yunhua

Add the words in section 1.3 to clarify the scope.

eMBMS related is not included in this drop.

03.06T0 23/Apr/10 Wang Yunhua

Draft version for TLA3.0

03.06 23/Mar/10 M. Gateau

Add event names for ENB Configuration Update failure and no response on S1 and X2 interfaces.

Sections 4.2.3.2 and 4.13.2 updated: comments received from Wang Yunhua.

Section 4.15 updated: comments received from Rodolphe Reau.

Section 4.4.2: add Default paging DRX missing in S1 Setup message

CR#269239 : Sys Info broadcast without S1 link (sections 4.2.7.3, 4.2.8 and 5.1.2).

Section 16.1.4 and 17.1.4: reception of Error Indication handling

Section 4.15: introduction of ActivationService->overloadCallRejectNotAllowed

03.05 08/Feb/10 M. Gateau

Updated following drop 2 review

CR#00241909: specific error handling for X2AP HANDOVER REQUEST ACKNOWLEDGE and X2AP HANDOVER PREPARATION FAILURE messages.

03.04 29/Jan/10 M. Gateau

X. Hao

F. Deville

JM Pugeat

C. Collin

New features added in drop 2:

FRS 104002, FRS 108172, FRS 108958, FRS 103792

03.03 26/Jan/10 M. Gateau

Jin Wang

Updated following drop 1 review.

03.02 21/Dec/09 M. Gateau

Jin Wang

Introduction of LA3.0 features : FRS92079

FRS 84876, FRS 97926, FRS 97980, FRS 92025, FRS 92026, FRS 101845

03.01 13/Nov/09 M. Gateau Creation for LA3.0

02.04 30/Oct/09 Jin Wang

…

Added back <SRS-026072-oam-0005> as the decision was to keep WiPS specs in the SRS and real checks in the separate WiPS SRS.




Added WiPS SRS reference.

Updated Sec 5.2.4 for FRS-96760 impact.

Added SRS-level WiPS check specs to support L97933

02.03 13/SEP/09 F. Deville Alignment on June’09 3GPP release: CR R3-091410 and R3-091343 are taken into account.

Corrections regarding SCTP management in case of S1 or X2 link lock.

Addition of cell lock/unlock in state diagram

Removal of S1 messages description (now handle in dedicated document)

02.02 24/JUL/09 JM. Pugeat,

Jin Wang

Prashant Padhy

F. Deville

Updated the document per comments following the review held 22/JUL/09

Number of supported MMEs moved from 8 to 16 (requirement from FRS 97982).

Support of X2/S1 lock/unlock and online creation/deletion

02.01 15/Jul/ 09 Prashant Padhy,

Jin Wang,

M. Gateau, JM. Pugeat

All First draft version created for LA2.0; updated from LA1.x version to support

• FRS-92784 (3GPP March 09 Alignment) by Prashant Padhy;

• FRS-97933 (Dynamic System Info Modification) by Jin Wang;

• FRS-97927 (Multi-vendor S1 IOT Readiness), FRS-97982 (Support of MME Group), FRS-97925 (X2 Operation in Multi-release Sw Environment) by M. Gateau.

• FRS-81872 Automatic Neighbour Relation Configuration and Optimisation by JM. Pugeat

01.07 11/Jun/09 Jin Wang 7.1 LA1.1 WIPS checks update

01.06 25/MAR/09 JM. Pugeat Update following review held on 20/MAR/09

01.05 16/MAR/09 JM. Pugeat All Update due to re-plan of LA1.0 / LA1.1

Addition of LA1.1.0 WiPS checks

Various corrections

01.04 16/JAN/09 JM. Pugeat 5.2.8 5.3.5 5.4 6.3

Approved document following final review

01.03 06/JAN/09 JM. Pugeat 6.2 6.3

Alignment to 3GPP December '08 S1 and X2 standards

01.02 19/DEC/08 JM. Pugeat All Update following review held on 28/NOV/08

01.01 25/NOV/08 JM. Pugeat 2.2 5.2.9 5.3.7 5.4.6

Added reference documents Added LteCell state diagram Updated S1 state diagrams Updated X2 state diagrams




6.2 6.3

Added Paging and missing IEs Added missing IEs

01.00 14/NOV/08 JM. Pugeat All Document creation

19




CONTENTS 20

1. INTRODUCTION ..............................................................................................10 21

1.1. OBJECT .................................................................................................10 22

1.2. FRS.....................................................................................................10 23

1.3. SCOPE OF THIS DOCUMENT ...............................................................................11 24

1.4. AUDIENCE FOR THIS DOCUMENT ..........................................................................11 25

1.5. OPEN POINTS ............................................................................................11 26

2. RELATED DOCUMENTS......................................................................................12 27

2.1. APPLICABLE DOCUMENTS .................................................................................12 28

2.2. REFERENCE DOCUMENTS .................................................................................13 29

3. END-TO-END ANGLE (INFORMATIVE) ....................................................................14 30

4. ENB FUNCTIONS AND PROCEDURE.......................................................................15 31

4.1. GENERAL PRINCIPLES ....................................................................................15 32

4.2. CELL SETUP .............................................................................................15 33

4.2.1 Prerequisites ....................................................................................15 34

4.2.2 Common and Shared Channels Setup ........................................................16 35

4.2.3 System Information Broadcasting ............................................................18 36

4.2.3.1 Introduction ..................................................................................18 37

4.2.3.2 System Information Size ....................................................................19 38

4.2.3.3 Broadcasting Periodicity ....................................................................21 39

4.2.3.4 System Information Broadcasting Procedure ............................................23 40

4.2.4 System Information Modification.............................................................23 41

4.2.4.1 Value Tag Management .....................................................................23 42

4.2.4.2 Class C Parameter Change..................................................................24 43

4.2.4.3 Timing Aspects ...............................................................................24 44

4.2.4.4 Change Notification Paging (CNP) .........................................................25 45

4.2.4.5 modification related to GPS status........................................................26 46

4.2.5 System Information Impacting UE Connectivity, Idle Mode Cell Reselection and Inter-47

RAT Mobility ................................................................................................28 48

4.2.6 Cell Lock/Unlock ...............................................................................29 49

4.2.7 Failure Cases ....................................................................................30 50

4.2.7.1 Cell Setup failure ............................................................................30 51

4.2.7.2 Modem failure................................................................................30 52

4.2.7.3 Cell Barring Due to Loss of S1 Services ...................................................30 53

4.2.8 Interactions with other features .............................................................31 54

4.3. PAGING ................................................................................................32 55

4.3.1 INTRODUCTION..................................................................................32 56

4.3.2 Paging procedure ...............................................................................34 57

4.3.2.1 Frame and subframe computation ........................................................34 58

4.3.2.2 Encoding of the paging record .............................................................35 59

4.3.2.3 Scheduler behavior ..........................................................................35 60

4.4. S1 SETUP ...............................................................................................36 61

4.4.1 Prerequisites ....................................................................................36 62

4.4.2 Successful Case .................................................................................36 63

4.4.3 Failure Cases ....................................................................................38 64

4.4.3.1 S1 Setup Failure..............................................................................38 65

4.4.3.2 No Response To S1 Setup ...................................................................39 66

4.4.3.3 S1 Link Failure ...............................................................................39 67




4.4.4 S1 Flex ...........................................................................................39 68

4.4.5 Interactions with other features .............................................................40 69

4.4.6 S1 link lock/unlock ............................................................................40 70

4.4.6.1 Behavior when locking an S1 link..........................................................40 71

4.4.6.2 Behavior when unlocking an S1 link.......................................................41 72

4.4.7 S1 online creation ..............................................................................41 73

4.4.8 S1 online deletion ..............................................................................41 74

4.5. S1 MME CONFIGURATION UPDATE ..................................................................41 75

4.5.1 Successful Case .................................................................................42 76

4.5.2 Failure Cases ....................................................................................43 77

4.6. S1 ENB CONFIGURATION UPDATE ..................................................................44 78

4.6.1 Successful Case .................................................................................44 79

4.6.2 Failure Cases ....................................................................................45 80

4.6.2.1 S1 eNB CONFIGURATION UPDATE Failure.................................................45 81

4.6.2.2 No Response To S1 eNB CONFIGURATION UPDATE ......................................46 82

4.7. S1 RESET ..............................................................................................47 83

4.7.1 S1 RESET Procedure MME initiated...........................................................48 84

4.7.2 S1 RESET PROcedure eNB initiated ..........................................................50 85

4.8. S1 OVERLOAD START (NOT IN LA3.0/TLA3.0) ......................................................51 86

4.9. S1 OVERLOAD STOP (NOT IN LA3.0/TLA3.0).......................................................52 87

4.10. X2 SETUP ..............................................................................................52 88

4.10.1 SUCCESSFUL Case...............................................................................53 89

4.10.2 FAILURE CaseS ..................................................................................55 90

4.10.2.1 X2 Setup Failure .............................................................................55 91

4.10.2.2 No Response To X2 Setup Request ........................................................56 92

4.10.2.3 X2 Link Failure ...............................................................................57 93

4.10.2.4 X2 Setup Crossover ..........................................................................57 94

4.10.3 MULTIPLE X2 LINKS .............................................................................58 95

4.10.4 INTERACTIONS WITH OTHER FEATURES .....................................................58 96

4.10.5 X2 lock/unlock .................................................................................59 97

4.10.5.1 Behavior when locking an X2 link .........................................................59 98

4.10.5.2 Behavior when unlocking an X2 link.......................................................59 99

4.10.6 X2 black-listing .................................................................................59 100

4.10.7 X2 white-listing .................................................................................59 101

4.10.8 X2 online creation..............................................................................60 102

4.10.9 X2 online deletion..............................................................................60 103

4.11. X2 ENB CONFIGURATION UPDATE ..................................................................61 104

4.11.1 Successful Case .................................................................................61 105

4.11.2 Failure Cases ....................................................................................62 106

4.11.2.1 X2 eNB CONFIGURATION UPDATE Failure.................................................62 107

4.11.2.2 No Response To X2 eNB CONFIGURATION UPDATE ......................................64 108

4.12. X2 RESET PROCEDURE ...............................................................................65 109

4.12.1 X2 RESET EMISSION .............................................................................65 110

4.12.2 X2 RESET RECEPTION...........................................................................66 111

4.13. SUPPORT OF MME GROUP ...........................................................................67 112

4.13.1 Introduction / Overview.......................................................................67 113

4.13.2 Assumptions .....................................................................................68 114

4.13.3 Support for GU Group ID List over X2........................................................68 115

4.13.3.1 Computing GU Group ID List and providing it to X2 neighbors ........................68 116

4.13.3.2 Storing GU Group ID information provided by X2 neighbors ...........................70 117

4.14. MME PRIORITY (NOT IN LA3.0/TLA3.0) .............................................................70 118

4.15. MME SELECTION ALGORITHM .......................................................................71 119




4.16. S1AP ERROR HANDLING .................................................................................74 120

4.16.1 Error handling at procedure level............................................................74 121

4.16.2 Error handling at IE level......................................................................74 122

4.16.3 Protocol error handling........................................................................75 123

4.16.4 Handling of S1AP Error Indication in reception ............................................77 124

4.16.4.1 Erroneous S1AP IDs ..........................................................................78 125

4.16.4.2 Abstract syntax error and logical errors..................................................78 126

4.17. X2AP ERROR HANDLING .................................................................................78 127

4.17.1 Error handling at procedure level............................................................79 128

4.17.2 Error handling at IE level......................................................................79 129

4.17.3 Protocol error handling........................................................................79 130

4.17.4 Handling of X2AP Error Indication in reception ............................................82 131

5. OAM MODEL DESCRIPTION.................................................................................83 132

5.1. LTE CELL ...............................................................................................83 133

5.1.1 Data Model ......................................................................................83 134

5.1.2 Object State Management ....................................................................87 135

5.2. MME ACCESS ..........................................................................................89 136

5.2.1 Data Model ......................................................................................89 137

5.2.2 Object State Management ....................................................................89 138

5.3. X2 ACCESS.............................................................................................91 139

5.3.1 DATA MODEL ....................................................................................91 140

5.3.2 OBJECT STATE MANAGEMENT.................................................................91 141

6. ABBREVIATIONS AND DEFINITIONS.......................................................................93 142

6.1. ABBREVIATIONS ..........................................................................................93 143

6.2. DEFINITIONS .............................................................................................94 144

ANNEX A: MASTER INFORMATION BLOCK AND SFN MASKING ..............................................95 145

ANNEX B: SYSTEM INFORMATION MESSAGE SIZE .............................................................96 146

ANNEX C: PAGING MESSAGE ENCODING ........................................................................98 147

ANNEX D: PAGING MESSAGE SIZE FOR RESOURCE BLOCK RESERVATION................................99 148

149




LIST OF TABLES 150

Table 1a: System Information Block Sizes (in bits) in LA3.0 ...........................................19 151

Table 2: Paging occasion subframe number .............................................................35 152

Table 3: LteCell State Management.......................................................................87 153

Table 4: MmeAccess State Management..................................................................89 154

Table 5: X2Access State Management ....................................................................91 155

156

157

LIST OF DIAGRAMS 158

Figure 1: Downlink transport channel mapping..........................................................16 159

Figure 2: Uplink transport channel mapping .............................................................17 160

Figure 3: Downlink logical channel mapping.............................................................17 161

Figure 4: Uplink logical channel mapping ................................................................17 162

Figure 5: Channels used for System Information ........................................................18 163

Figure 6: Master Information Block periodicity..........................................................21 164

Figure 7: CNP when there is a full paging cycle before the end of Modification Period (N). .....25 165

Figure 8: CNP when there is not a full paging cycle before the end of Modification Period (N). 26 166

Figure 9: Invocation of DSIM & CNP due to eNB internal state change...............................27 167

Figure 10: OAM/ data model where eNB internal state change triggers DSIM & CNP. .............28 168

Figure 11: From IMSI to a paging occasion ...............................................................33 169

Figure 12: S1 Setup Success ................................................................................37 170

Figure 13: S1 Setup Failure.................................................................................38 171

Figure 14: No Response To S1 Setup ......................................................................39 172

Figure 15: MME Configuration Update Success...........................................................42 173

Figure 16: MME Configuration Update Failure ...........................................................43 174

Figure 17: S1 eNB Configuration Update Failure ........................................................46 175

Figure 18: No Response to S1 eNB Configuration Update ..............................................47 176

Figure 19: Reset procedure MME initiated ...............................................................48 177

Figure 20: Reset procedure eNB initiated ................................................................50 178

Figure 21: Overload Start...................................................................................51 179

Figure 22: Overload Stop ...................................................................................52 180

Figure 23: X2 Setup Success ................................................................................53 181

Figure 24: X2 Setup Failure.................................................................................56 182

Figure 25: No Response To X2 Setup ......................................................................57 183

Figure 26: X2 eNB Configuration Success .................................................................61 184

Figure 27: X2 eNB Configuration Update Failure ........................................................63 185

Figure 28: No Response To X2 eNB Configuration Update..............................................64 186

Figure 29: Data Model For LteCell (1/6)..................................................................83 187






Figure 35: LteCell State Diagram ..........................................................................88 193

Figure 36: Data Model For S1-MME ........................................................................89 194

Figure 37: MMEAccess State Diagram .....................................................................90 195

Figure 38: Data Model For X2AP ...........................................................................91 196

Figure 39: X2Access State Diagram........................................................................92 197

198




1. INTRODUCTION 199

1.1. OBJECT 200

This document specifies from the system level point of view the eNB Control 201

procedures for Cell, S1 and X2 common resources management. 202

203

1.2. FRS 204

LA2.0 FRS: 205

FRS-103773 3GPP Alignment (June 09) 206

FRS-97933 Dynamic System Info Modification under Cell Parameter Change 207

FRS-97927 Multi-vendor S1 IOT Readiness 208

FRS-97982 Support of MME Group 209

FRS-97925 X2 Operation in Multi-release Sw Environment 210

FRS-81872 Automatic Neighbour Relation Configuration and Optimisation 211

FRS-96760 eNB Configuration Update Enhancements 212

213

LA3.0 FRS: 214

FRS-92079 EUTRAN Standard Alignment on 3GPP Release 8 December 09 215

FRS-84876 Enhanced Non-Optimized LTE-to-HRPD Inter-RAT Mobility 216

FRS-97926 Multi-vendor X2 IOT Readiness 217

FRS-97980 Improvements over S1 218

FRS-92025 CS Fallback to UTRA for Voice Calls 219

FRS-92026 CS Fallback to GERAN for Voice Calls 220

FRS-101845 eNB MME Selection Evolution (Not in LA3.0/TLA3.0) 221

FRS-108282 eNB Class Parameter change for LA3.0 (only TAC update – other 222

impacts TBC) 223

FRS-104002 Broadcast per cell SIB4 224

FRS-108172 Full ANR 225

FRS-108958 Sysinfo Scheduling improvement 226

FRS-103792 Intra-LTE Inter-Frequency Mobility for FDD-TDD and TDD-TDD 227

228

TLA3.0 FRS: 229

FRS-103894 eUTRAN support of eMBMS Phase -1 230

FRS-113614 X2/S1 lock/unlock for transport management 231




1.3. SCOPE OF THIS DOCUMENT 232

The scope of this document is applicable to both LTE eNB system release LA3.0 and TLA3.0. 233

Specific TLA3.0 handling is mentioned by wording TLA3.0. 234

The following common resources control functions are specified in this document. 235

- Cell setup including common channels, shared channels setup, and System 236

Information broadcast 237

- S1 setup 238

- X2 setup 239

- Paging, 240

- Configuration update and Error Handling on S1 and X2 interfaces 241

- Dynamic invocation of DSIM (dynamic System Info modification L97933) to 242

support L84876 when eNB internal state relating to GPS changes. 243

244

1.4. AUDIENCE FOR THIS DOCUMENT 245

• PLM 246

• System Design 247

• eNB architects 248

• eNB developers 249

• eNB and system testers 250

• Field deployment teams 251

252

1.5. OPEN POINTS 253

Some open points are related to FRS 108282 (eNB Class Parameter change for LA3.0) which 254

is not currently analysed (refer to sections 4.4.7, 4.4.8 and 4.6.1). 255

An optimization of MMEAccess state management at MMEAccessGroup level is also 256

proposed for LA3.0 (refer to section 4.2.7.3. 257

258

Commentaire [ADW1] : <Start: SRS-026072-60, Other>

Feature Number: L84876 Author: Jin Wang

<End: SRS-026072-60>




2. RELATED DOCUMENTS 259

2.1. APPLICABLE DOCUMENTS 260

[A1] LTE/SYS/DD/026052 EUTRAN Call Handling 261

[A2] LTE/SYS/DD/029350 EUTRAN Mobility Control Plane 262

[A3] LTE/SYS/DD/026364 SRS for EUTRAN-to-HRPD/1xRTT Inter-RAT 263

Mobility 264

[A4] LTE/BTS/DD/025965 RRC Excel spreadsheet 265

[A5] LTE/SYS/DD/029664 LTE RRM DL Semi-Static and Semi-Persistent 266

Scheduler 267

[A6] LTE/SYS/DD/030195 EUTRAN Online Parameter Change – Impacts on 268

traffic 269

[A7] LTE/SYS/DD/024773 EUTRAN User Plan specification 270

[A8] LTE/SYS/DD/026110 EUTRAN Transport Traffic Management 271

[A9] LTE/SYS/DD/024855 FN - eUTRAN LA0.x – OAM – General 272

[A10] LTE/BTS/DD/024775 eNB LTE Alarm Dictionary 273

[A11] LTE/SRS/APR/027605 FTS for FRS-97933 (Dynamic SysInfo Modification 274

under Cell Parameter Change) 275

[A12] LTE/SYS/APR/02738 FTS for FRS-92784 (LA2.0 3GPP Standard 276

Compliance) 277

[A13] LTE/SYS/APR/027750 FTS for FRS 97927 “Multi-vendor S1 IOT 278

Readiness”, FRS 97925 “X2 Operation in Multi-279

release Sw Environment” and FRS 97982 280

“Support of MME group” 281

[A14] LTE/SYS/DD/027718 SRS for LTE Self Organizing Network 282

[A15] LTE/SYS/DD/026039 eUTRAN Performance Monitoring 283

[A16] LTE/SYS/DD/028103 EUTRAN Call Trace and PCMD – SRS 284

[A17] LTE/SYS/DD/024185 EUTRAN S1 Interface Specification 285

[A18] LTE/SYS/DD/028693 WiPS Checks Specifications 286

[A19] LTE/SYS/DD/028163 SRS eUTRAN Subscriber and Equipment Traces 287

Function 288

[A20] LTE/SYS/APR/027071 FTS for FRS-84876 (Enhanced Non-Optimized 289

LTE-to-HRPD Inter-RAT Mobility) 290

[A21] LTE/SYS/APR/029003 FTS for FRS-97980 (Improvements over S1) 291

[A22] LTE/SYS/APR/029159 FTS for FRS-097926 (Multi-vendor X2 IOT 292

Readiness) 293

[A23] LTE/SYS/APR/029271 FTS for FRS-101845 (eNB MME Selection 294

Evolution) 295

[A24] LTE/SYS/APR/030195 FTS for FRS-108958 (Sys-info Scheduling 296

Improvements) 297

[A25] LTE/BTS/DD/024775 ENB LTE Alarm Dictionary 298




[A26] LTE/SYS/DD/031890 SRS for eMBMS Control Plane 299

300

2.2. REFERENCE DOCUMENTS 301

3GPP documents 302

[R1] TS 36.331 v8.8.0 (LA3.0), v9.2.0 (TLA3.0) Radio Resource Control (RRC) 303

Protocol Specification 304

[R2] TS 36.211 v8.9.0 Physical Channels and Modulation 305

[R3] TS 36.213 v8.8.0 Physical layer procedures 306

[R4] TS 36.304 v8.8.0 User Equipment (UE) procedures in idle mode 307

[R5] TS 36.321 v8.8.0 Medium Access Control (MAC) protocol specification 308

[R6] TS 36.413 v8.8.0 S1 Application Protocol (S1AP) 309

[R7] TS 36.423 v8.8.0 X2 Application Protocol (X2AP) 310

[R8] TS 23.401 v8.8.0 GPRS enhancements for E-UTRAN access 311

[R9] R2-083733 LS on Change rate of physical layer parameters 312

[R10] R2-083820 Response LS on Change rate of physical layer 313

parameters 314

[R11] R2-083824 LS Response to LS on synchronization of L1 315

parameter from system information 316

317




3. END-TO-END ANGLE (INFORMATIVE) 318

319




4. ENB FUNCTIONS AND PROCEDURE 320

4.1. GENERAL PRINCIPLES 321

There are two high-level principles that found the base for interface management within 322

the eNB: 323

- transport layer independency from the applicative layers, 324

- interface independency one from another. 325

326

Transport layer independency from applicative layers means that the underlying transport 327

services will always attempt to set up without expecting applicative triggers. In other 328

words, after an eNB startup, board reset or link failure, transport must be established 329

regardless of the state of applicative layers. Transport layer independency guarantees the 330

fastest restart or recovery times by enforcing an "always ready" policy rather than 331

conditioning transport setup to higher-level application readiness. Nevertheless, some 332

level of applicative layer control exists: interface locking will cause the transport to be 333

brought down, and X2 black-listing will prevent the transport layer from establishing. 334

Interface independency means that S1, X2 and RRC interfaces shall be established 335

independently (by RRC interface setup it is meant Cell Setup and System Information 336

broadcasting). For example, Cell Setup procedure initiation shall not be conditioned to, for 337

example, the prior setup of the S1 interface. Interface independency guarantees the 338

fastest restart or recovery times by parallelizing rather than serializing interface setup. 339

At eNB start-up the eNB shall therefore launch in parallel: 340

- the Cell Setup procedure for each of the cells belonging to this eNB, as 341

described in section 4.2; 342

- S1 Setup towards one or several MMEs as described in section 4.4; 343

- X2 Setup towards other eNBs as described in section 4.7. 344

345

4.2. CELL SETUP 346

Cell setup consists in common and shared channels setup followed by System Information 347

broadcast. 348

The cell setup procedure is described in section 4.2.2. 349

The System Information procedure is described in section 4.2.3. 350

351

4.2.1 PREREQUISITES 352

Prior to triggering the cell setup procedure, the eNB will have performed the following 353

steps, as defined in[A9]: 354

- internal MIB generation. 355

It is therefore ensured that all configuration parameters required to perform cell setup are 356

available at the time it is launched. 357

358


Feature Number: L108282 Author: Martine Gateau

<End: SRS-026072-230>




4.2.2 COMMON AND SHARED CHANNELS SETUP 359

Based on the configuration parameters received during the eNB startup sequence, the eNB 360

will start the initialization of each of its cells. 361

The following physical channels are established in the cell: 362

• Physical broadcast channel (PBCH) 363

• Physical control format indicator channel (PCFICH) 364

• Physical downlink control channel (PDCCH) 365

• Physical downlink shared channel (PDSCH) 366

• Physical multicast channel (PMCH) Not in LA3.0, supported in TLA3.0 367

• Physical uplink control channel (PUCCH) 368

• Physical uplink shared channel (PUSCH) 369

• Physical Hybrid ARQ Indicator Channel (PHICH) 370

• Physical random access channel (PRACH) 371

372

The following transport channels are established in the cell: 373

• Broadcast Channel (BCH) 374

• Downlink Shared Channel (DL-SCH) 375

• Paging Channel (PCH) 376

• Multicast Channel (MCH) Not in LA3.0, supported in TLA3.0 377

• Uplink Shared Channel (UL-SCH) 378

• Random Access Channel(s) (RACH) 379

380

The mapping of downlink transport channels on physical channels is the following: 381

382

383

Figure 1: Downlink transport channel mapping 384

385

The mapping of the uplink transport channels on physical channels is the following: 386

387

Commentaire [ADW3] : <Start: SRS-026072-430, Requirement>

Feature Number: 103894 Author: Wang Yunhua Release: TDD

<End: SRS-026072-430>




RACH UL-SCH

PUSCHPRACH

UplinkTransport channels

UplinkPhysical channels

PUCCH 388

Figure 2: Uplink transport channel mapping 389

390

The following control logical channels are established in the cell: 391

• Broadcast Control Channel (BCCH) 392

• Paging Control Channel (PCCH) 393

• Common Control Channel (CCCH) in the UL and DL 394

• Multicast Control Channel (MCCH) Not in LA3.0, supported in TLA3.0 395

396

The mapping of downlink logical channels to transport channels is the following: 397

398

399

Figure 3: Downlink logical channel mapping 400

401

The mapping of uplink logical channels to transport channels is the following: 402

403

CCCH DCCH DTCH

UL-SCHRACH

UplinkLogical channels

UplinkTransport channels

404

Figure 4: Uplink logical channel mapping 405

406



<End: SRS-026072-440>




As part of the cell setup procedure after the physical and transport channels are setup in 407

the cell, the eNB will start broadcasting RRC System Information messages on BCCH of the 408

cell. 409

During the Cell setup, the states changes of the LteCell MO are managed as described in 410

section 5.1.2. 411

At the end of the cell setup procedure, the eNB is ready to accept mobile originated or 412

terminated calls in this cell. 413

Failure cases 414

In case of cell setup failure the LteCell MO state is changed as below. In LA3.0 a human 415

intervention via OMC is needed to correct the configuration data and proceed with e.g. a 416

modem board reset. Trace and debug functionality is supported as specified in SRS eUTRAN 417

Subscriber and Equipment Traces Functions (reference [A19]). 418

419

Event LteCell MO states attributes (administrative/operational/availability)

When cell initialization starts Unlocked/Disabled/Dependency When a sector and a modem are available and cell setup fails (Note)

Unlocked/Disabled/Failed

420

Note: The availability “failed” is proposed for cases like invalid configuration parameter or 421

software anomaly for which there is no defense mechanism (e.g. board reset(s) done but 422

error persists or no defense at all). In that case, there is no other object disabled/Failed 423

(board…). 424

425

4.2.3 SYSTEM INFORMATION BROADCASTING 426

4.2.3.1 INTRODUCTION 427

System Information messages are carried over the BCCH logical channel and provide 428

network-related configuration data to the mobiles. The BCCH is mapped onto both: 429

- the BCH transport channel (for the MasterInformationBlock) which is carried by the PBCH 430

physical channel 431

- the DL-SCH transport channel (for all other system information blocks) which is carried 432

on the PDSCH. 433

434

435

Figure 5: Channels used for System Information 436

437



<End: SRS-026072-450>




There are a maximum of 32 System Information Blocks that may be defined, in addition to 438

the MasterInformationBlock. Currently only thirteen have been standardized. Hereafter is 439

a brief description of the current information blocks' content: 440

• MasterInformationBlock or MIB: essential physical layer information. 441

• SystemInformationBlockType1 or SIB1: cell access information and scheduling of 442

other system information messages. 443

• SystemInformationBlockType2 or SIB2: common and shared channel information 444

• SIB3: cell re-selection information 445

• SIB4: intra-frequency neighboring cells 446

• SIB5: inter-frequency neighboring cells 447

• SIB6: inter-RAT cell re-selection towards UTRAN 448

• SIB7: inter-RAT cell re-selection towards GERAN 449

• SIB8: inter-RAT cell re-selection towards CDMA2000 (details are captured in [A3]) 450

• SIB9: home eNB identifier (Not in LA3.0/TLA3.0) 451

• SIB10 and SIB11: Earthquake and Tsunami Warning System or ETWS (Not in 452

LA3.0/TLA3.0) 453

• SIB12: Commercial Mobile Alert Service or CMAS (Not in LA3.0/TLA3.0) 454

• SIB13: acquire the MBMS control information associated with one or more MBSFN 455

areas (Not in LA3.0, supported in TLA3.0) 456

457

4.2.3.2 SYSTEM INFORMATION SIZE 458

System Information size ranges in bits are provided hereafter. Minimum and maximum 459

sizes are derived from the ASN1 constructs, while expected size is estimated based on 460

LA3.0 feature content. The numbers are given to provide an indication of System 461

Information sizes, and must be used with caution. Note that a System Information Message 462

has a size limit of 2216 bits due to the imposed DCI format; since the header has a 14-bit 463

size (cf. Annex B), this implies a maximum size of 2202 bits for System Information Blocks. 464

In LA3.x SIB6/7 (UMTS/GSM) and SIB8 (CDMA2000), if present, are mutually exclusive. The 465

PQ2-PQ3 interface currently does not support SAR (segmentation and reassembly) for a 466

UDP/IP payload size exceeding 1500 bytes even though the CCM-CEM interface supports up 467

to 64K bytes. This lack of SAR support however does not affect LA3.0 since the re-468

estimated SIBs size does not exceed 1500 bytes. 469

With L108958 (Sys Info Scheduling Improvement), multiple SIBs can be mapped to a single 470

System Info message as determined by the DL Scheduler. 471

Table 1a: System Information Block Sizes (in bits) in LA3.0 472

Message / Block Min Size Max Size Expected Size (LA3.0)

MIB 24 24 24

SIB1 114 368 158

SIB2 186 273 205

SIB3 29 75 66

SIB4 4 490 476

SIB5 66 2202 584

SIB6 7 763 763

SIB7 56 2202 522


Feature Number: L104002 Author: XU Hao

<End: SRS-026072-80>




SIB8 9 2202 377

473

The expected size of SIBs is based on the following assumptions: 474

SIB1: only one PLMN is broadcast, and there are a maximum of four SI-Messages scheduled. 475

SIB2: ac-BarringInfo, preamblesGroupAConfig and mbsfn-SubframeConfigList are not 476

included. 477

SIB3: p-Max and allowedMeasBandwidth are not included. 478

SIB4: csg-PhysCellIdRange is not included, 16 physical cell identities are included in the 479

neighbour list (intraFreqNeighCellList) and 16 physical cell identities and ranges are 480

included in the list of black-listed cells (intraFreqBlackCellList). For the min size, assuming 481

not include any real IE, 4 bits is just a structure overhead. 482

SIB5: a WPS and XMS error check will prevent the operator from configuring a number of 483

inter-frequency neighbours that would not fit within the 2202 bit limit. The total size of 484

SIB5 will essentially depend on four parameters: 485

- the number of configured inter-freq frequencies (number of instances of 486

LteNeighboringFreqConf minus one), or nFreq 487

- the total number of configured inter-freq cells (total number of instances of 488

LteNeighboringCellRelation that are not under the LteNeighboringFreqConf object of 489

the cell's frequency), or nInterFreqCell 490

- the total number of configured inter-freq black-list configurations (total number of 491

instances of BlackCellConf that are not under the LteNeighboringFreqConf object of 492

the cell's frequency), or nInterFreqBlackCellConf 493

- the total number of configured inter-freq black-listed ranges (total number of 494

times optional parameter "range" is configured in a BlackCellConf object that is not 495

under the LteNeighboringFreqConf object of the cell's frequency), or 496

nInterFreqBlackCellConfRange 497

Assuming that all optional parameters of SIB5 are present, the total size of SIB5 in 498

bits can be calculated as: 499

Totalsize= 4 + 74 * nFreq + 14 * nInterFreqCell + 10 * nInterFreqBlackCellConf + 4 * 500

nInterFreqBlackCellConfRange 501

For the expected size, we will assume 2 frequencies (nFreq), 20 cells 502

(nInterFreqCell), 12 black-list configurations (nInterFreqBlackCellConf) and 8 ranges 503

(nInterFreqBlackCellConfRange), which translates into a total size of 579 bits. 504

For the min size, we will assume q-OffsetFreq, pMax and cellReselectionPriority are 505

all present. 506

507

SIB6: only UTRA-FDD information is broadcasted (carrierFreqListUTRA-FDD). For the min 508

size, assuming only inlcudes T-Reselection. 509

SIB7: only 4 frequency groups (an element of carrierFreqsInfoList) are broadcast (enforced 510

by a WIPS check that there are a maximum of 4 GeranNeighboringFreqConf objects per 511

LteCell), with a total of maximum 32 frequencies being broadcast across all groups. 512

SIB8: synchronousSystemTime is included; preRegistrationZoneId, 513

secondaryPreRegistrationZoneIdList, and all 1XRTT parameters are not included. The fact 514

that only two bands can be configured in MIM and that TS36.331 limits the number of 515

neighbours broadcast in SIB8 to 32 is also taken into account. Assuming only the 516

searchWindowSize IE is included in SIB8 when calculating SIB8 minimum size. 517

The estimation for SIB sizes in TDD considering TDD-specific IE in SIBs: 518

Table 1b: System Information Block Sizes (in bits) in TLA3.0 519




Message / Block Min Size Max Size Expected Size (TLA3.0)

MIB 24 24 24

SIB1 100 2202 348

SIB2 175 489 257

SIB3 29 74 72

SIB4 4 490 476

SIB5 66 2202 584

SIB6 7 1443 687

SIB7 56 2202 522

SIB8 9 2202 N/A

SIB13 41 237 41

520

The expected size of SIBs is based on the following assumptions in addition to LA3.0: 521

SIB2: mbsfn-SubframeConfigList is included and maxMBSFN-Allocations is 1. 522

SIB13: maxMBSFN-Area is 1. 523

524

4.2.3.3 BROADCASTING PERIODICITY 525

The MasterInformationBlock and SystemInformationBlockType1 use fixed scheduling, 526

whereas all other system information blocks are carried in System Information Messages 527

whose scheduling is defined in SIB1. 528

The MasterInformationBlock is scheduled in subframe 0 of frames with SFN mod 4 = 0, with 529

repetitions in subframe 0 of every radio frame. It therefore has a periodicity of 40ms (a 530

MasterInformationBlock with a new System Frame Number is sent every 40 ms) and a 531

repetition rate of 10ms (the MasterInformationBlock is repeated 3 times at 10ms intervals 532

without changing the SFN). 533

534

MIB withSFN = 4n

MIB withSFN = 4n + 4

3 repetitions

40 ms

10 ms

535

Figure 6: Master Information Block periodicity 536

537

Note: the full system frame number is 10 bits long, composed of 8 bits provided in the 538

MasterInformationBlock and 2 bits acquired implicitly from the BCH decoding. 539



<End: SRS-026072-460>




The SystemInformationBlockType1 is scheduled in subframe 5 of frames with SFN mod 8 = 540

0, and is repeated in subframe 5 of every even frame. It therefore has a periodicity of 541

80ms, with a repetition rate of 20ms. 542

The other System Information Blocks have a periodicity that may be individually set among 543

the following values: 8, 16, 32, 64, 128, 256, or 512 radio frames. The periodicity of 544

System Information Blocks 2 and upwards is indicated to the UEs by the 545

SchedulingInformation IE contained in SystemInformationBlockType1. 546

SIBs 2 and upwards are carried in System Information Messages, which contain one or 547

several SIBs and are broadcast within recurring periods called SI-windows. The duration of 548

the SI-window is common to all SI Messages, and is broadcast in SIB1. SI-windows of 549

different SI Messages do not overlap, in other words only one SI Message is broadcast and 550

eventually repeated within an SI-window. The first SI Message to be scheduled must 551

contain SIB2 in the first position, and an SI Message may only contain SIBs that have the 552

same periodicity. 553

The frame and subframe number at which the SI-window for a given SI Message begins are 554

determined in the manner described hereafter. 555

For the nth SI Message in the schedulingInformation IE of SIB1: 556

- the SI-window begins in the subframe number [(n – 1)*w] mod 10, where w is the si-557

WindowLength broadcast in SIB1; 558

- the frame number in which the SI-window begins verifies SFN mod T = FLOOR([(n – 1)*w] 559

/10), where T is the si-Periodicity of the concerned SI message 560

Note: some combinations of SI-window, number of SI Messages and periodicities are not 561

possible. Typically, the smallest periodicity must be superior to the number of SI Messages 562

multiplied by the size of the SI-window. 563

Resource allocation for System Information Blocks is signaled on the PDCCH channel using 564

the dedicated SI-RNTI (defined as 0xFFFF in [R5] TS 36.321). 565

566




4.2.3.4 SYSTEM INFORMATION BROADCASTING PROCEDURE 567

Once the common and dedicated channel setup procedure has been successfully 568

completed, the eNB will initiate the System Information Broadcasting procedure, which 569

consists in 4 steps: 570

571

- encoding of System Information blocks numbered 2 and higher: 572

- SIB2 and SIB3 are always provided, 573

- rules for providing SIB6, SIB7 and SIB8 can be find in document [A3], 574

- rules for providing SIB4 and SIB5 can be find in document [A2]. 575

576

- rules for providing SIB13 can be find in document [A26] 577

- choice of the number and periodicity of SI Messages that will be used to broadcast system 578

information, based on a configured target periodicity and coding scheme (MCS); the si-579

WindowLength is set by the scheduler (hardcoded value set to 20ms); 580

- encoding of Master Information Block and System Information Block Type1 and necessary 581

SI messages; 582

- broadcasting of all system information blocks. 583

Pre-encoding of the SIBs that are broadcast in SI messages (SIBs 2 and higher) is required in 584

order to calculate their respective sizes. These sizes are used by the Scheduler, along with 585

parameters such as the target periodicity and target coding scheme, to determine the best 586

scheduling scheme for system information: number of SI messages and eventual repetitions 587

of the SI messages within the SI-window. 588

Details of the algorithm are to be found in [A5]. 589

590

591

4.2.4 SYSTEM INFORMATION MODIFICATION 592

There are two mechanisms used to signal to the UEs that System Information has changed 593

and must be read again: 594

- systemInformationValueTag (hereafter referred to as value tag) is a mandatory 595

Information Element in RRC message SystemInformationBlockType1. It takes 596

integer values within a small set of 32 values, and must be updated every time 597

the system information changes. 598

- systemInfoModification may be optionally included in RRC Paging to indicate an 599

upcoming change in System Information 600

601

4.2.4.1 VALUE TAG MANAGEMENT 602

In order for the CallP to know which value was used for the value tag prior to the eNB 603

restart or cell lock, the information will be stored into the semi-persistent memory. It is 604

also saved in the CallP context as a backup. This is a zone in the RAM which survives across 605

an eNB restart. At startup or after cell unlocking, CallP will read the value stored in the 606

semi-persistent memory, add one to it, and then store the updated value in the semi-607

persistent memory and use it to populate the value tag in SIB1. 608


Feature Number: L104002 Author: XU Hao

<End: SRS-026072-90>



<End: SRS-026072-480>


Feature Number: L108958 Author: Jean-Michel Pugeat

<End: SRS-026072-130>


Feature Number: L108958 Author: Jean-Michel Pugeat

<End: SRS-026072-140>




The CallP therefore updates the value tag after each restart and each cell unlocking, 609

regardless of the reason that triggered it. 610

If the CallP fails to read the stored value during cell setup/ re-setup, it will use the backup 611

value saved in the CallP context. After an eNB restart (power on), it will use a random 612

value for the value tag. There is a chance (one out of 32) that the random value is the 613

same as the value prior to eNB restart or cell lock, meaning some UEs may not re-acquire 614

System Info even though SIBs parameters can change across eNB restart. To address this, 615

the eNB self-triggers a DSIM/ CNP shortly after an eNB restart, forcing an update on the 616

value tag with the corresponding CNP to the UEs. 617

618

The service allowing to read and write into the semi-persistent memory needs to be 619

modified for this specific purpose of CallP. The result will be a file system in which the 620

CallP can write and read; the service will have to be fully started before the CallP is 621

launched. It may be necessary to define the file format in order to facilitate upgrades (file 622

version compatibility issues may arise) and prepare future evolutions (SON features for 623

example). 624

625

4.2.4.2 CLASS C PARAMETER CHANGE 626

If there are any changes of “Class C” parameters relating to SIBs in the MIM, the XMS 627

notifies the eNB about the change to support dynamic System Info modification. The value 628

tag in SIB1 is updated to be included in System Info and, prior to the inclusion of the 629

actual change in System Info broadcasting, an optional bit in RRC Paging is used indicate to 630

all UEs about the upcoming change in System Info. This process is referred to as DSIM with 631

CNP (dynamic System Info modification with change notification paging). 632

More details on Class C parameter change can be find in document ref [A6]. 633

634

635

4.2.4.3 TIMING ASPECTS 636

Dynamic modification of the system information is only permitted at specific points in 637

time. These instants are the boundaries of periods called "modification periods", which is 638

somewhat misleading because in fact, no change may occur during a modification period. 639

The duration of the modification period is calculated using two parameters that are 640

broadcast in SIB2: modificationPeriodCoeff which takes its values in the range {2, 4, 8, 16} 641

and defaultPagingCycle which may be set to 32, 64, 128 or 256 radio frames(cf. the 642

paragraph on Paging, 4.3). The duration of the modification period is expressed in numbers 643

of radio frames and is given by the following formula: 644

modificationPeriod = modificationPeriodCoeff * defaultPagingCycle 645

When the value of one or several parameters broadcasted in the System Information 646

messages is changed during a given modification period N, or when there is a growth or de-647

growth of instances in the MIM that are mapped to SIBs parameters, the actual messages 648

being broadcast over the air interface will be updated at the boundary between 649

modification period N and N+1 if there remains a full paging cycle before the end of period 650

N (see Figure 7). Otherwise, the update will be at the boundary of periods N+1 and N+2 651

(see Figure 8). 652

653




4.2.4.4 CHANGE NOTIFICATION PAGING (CNP) 654

655

Modem ( K)

BCCH modification period (N)

Change notification Updated information

BCCH modification period (N+1)

XMS

eNBCallP

DLScheduler

RRC Idle &Connected

UEs

Del

ta U

pdat

e(

SIB

x, C

ell_

ID=K

)

CELL_RLC_M

AC_SYSINFO_

SCHEDULING_REQUEST(SIBx, sizes, etc)

BCCH Modification

Period

N N+1 N+2

CELL_RLC_M

AC_SYSINFO_

UPDATE_REQUEST(e

ncod

edSIBx)

Current SIBx

Next SIBx

Current SIBx

When the ending boundary of Modification Period

(N) is about to be reached, the DL Scheduler

• Copies Next_SIBx to Current_SIBx;

• Deletes the existing SIB pre-booking;

• Re-performs SIB pre-booking.

Broadcast of SI messages carrying the updated

SIBs begins at the starting boundary of

Modification Period (N+1).

Assume 2 DefaultPagingCycle’sin a Modification Period

…

Pag

e(

system

Info

Modification)

SIB1 and SIBx prior to and during “change notification”

(Same or modified) SIB1 with ValueTag change and modified SIBx after “change notification”

Encode the modified SIBx and

set SIB1’s ValueTag += 1

A UE’s Paging Occasion (PO) in DefaultPagingCycle

Send a CNP for

each PO in the last

defaultPagingCycle

656

Figure 7: CNP when there is a full paging cycle before the end of Modification Period (N). 657

658

Next SIBx

Modem ( K)

eNBCallP

DLScheduler N N+1 N+2

Current SIBx

Next SIBx

Current SIBx

Pag

e(

system

Info

Modification

)

BCCH modification period (N)

Change notification Updated information

BCCH modification period (N+1)

RRC Idle &Connected

UEs

BCCH Modification

Period

Assume 2 DefaultPagingCycle’sin a Modification Period

…

In this variation the DSIM trigger arrives after

the start of the last DefaultPagingCycle of

Modification Period (N) such that at least one

PO has been missed for CNP purpose. So

CNP starts in the 1st DefaultPagingCycle of

Modification Period (N+1), as shown.

Del

ta U

pdat

e(

SIB

x, C

ell_

ID=

K)XMS

CELL_RLC_M

AC_SYSINFO_

SCHEDULING_REQUEST(SIBx, sizes, etc)

CELL_RLC_M

AC_SYSINFO_

UPDATE_REQUEST(e

ncod

edSIBx)

Current SIBx

Send a CNP for each PO in

the last defaultPagingCycle.

May repeat CNP in previous

paging cycle(s).

When the ending boundary of Modification

Period (N+1) is about to be reached, the DL

Scheduler

• Copies Next_SIBx to Current_SIBx;

• Deletes the existing SIB pre-booking;

• Re-performs SIB pre-booking.

Broadcast of SI messages carrying the

updated SIBs begins at the starting boundary

of Modification Period (N+2).

659




Figure 8: CNP when there is not a full paging cycle before the end of Modification Period (N). 660

661

The CNP may be repeated in a Modification Period. 662

663

The reason for CNP is that one of the two manners in which the UEs may check for System 664

Information modification is to listen for a Paging message indicating a change in System 665

Information. Since a UE only listens to its own paging occasions and since there is only one 666

during a paging cycle, it is necessary to go through a full paging cycle in order to page all 667

mobiles for a change in System Information. 668

The other manner in which a UE may check for System Information updating is to check 669

the Value Tag at each boundary between modification periods. The eNB must update the 670

value tag every time the System Information that is broadcasted is modified. 671

672

4.2.4.5 MODIFICATION RELATED TO GPS STATUS 673

674

While DSIM invocation in LA2.x is limited to SIB-related “Class C” parameter change via 675

OAM and automatic cell barring by eNB as a result of detection of S1 failure (outage or 676

OAM action) , L84876 in LA3.0 extends the triggers to include certain internal state change 677

that relates to GPS status on the eNB. Specifically, the (CDMA) systemTimeInfo IE in SIB8 678

is optional and, when present, it is based on the primary timing source derived from GPS 679

and can take the form of either a “sync mode” (39 bits for the field) or “async mode” (49 680

bits). The CallP invokes DSIM and CNP dynamically when certain status change relating to 681

GPS (CdmaPhaseSync and GpsTime) occurs; UEs in RRC Connected and RRC Idle acquire the 682

updated info in SIB8. Examples of the state transitions include (see Figure 9): 683

• A change of the “async mode” to “sync mode” for the systemTimeInfo IE in SIB8 684

(refer to the state transition labeled (5) in the figure); 685

• A change from the “sync mode” to the exclusion of the systemTimeInfo IE from 686

SIB8 (refer to label (3) in the figure); 687

• A change from an absence of the systemTimeInfo IE to the inclusion of either the 688

“async mode” in SIB8 (refer to label (4-1) in the figure) or “sync mode” in SIB8 689

(refer to the label (4-3) in the figure); 690

• A change from the “async mode” to the exclusion of the systemTimeInfo IE from 691

SIB8 (refer to label (4-2) in the figure). 692

The above assume, under ActivationService, isSynchCdmaSystemTimeAllowed=True. If 693

isSynchCdmaSystemTimeAllowed=False indicating no L84876 support for UEs requiring MG, 694

the state transitions with labels (4-1) and (4-2) can still occur, but systemTimeInfo is 695

excluded from SIB8 and the fine clock adjustment does not have to take place. 696

The support of the async-mode allows eNB to resume the use of B2 and B1 measurements 697

(for UEs requiring MG) as soon as GPS recovers, rather than wait until the (slow) clock 698

adjustment logic has run its course that can take many hours. The capability can help ALU 699

win tier-2/ tier-3 CDMA customers over the competition since they may choose a 700

“cheaper” version of an on-board oscillator offering a shorter phase holdover interval after 701

GPS loss, significantly increasing the odds that the GPS does not recover within the 702

holdover (i.e. the transition with label 3) and requires many hours of clock adjustments 703

after GPS recovers (the transitions with label 4-1 and label 5). 704

A description of the overall solution can be found in [A20]. 705

706



<End: SRS-026072-65>




CDMA Phase Sync = “Enabled/ degraded”

GPS Time = “Disabled/ failed”

CDMA Phase Sync = “Disabled/ dependency”

GPS Time = “Disabled/ failed”CDMA Phase Sync = “Disabled/ dependency”

GPS Time = “Enabled/ none”

CDMA Phase Sync = “Enabled/ none”

GPS Time = “Enabled/ none”

� Oscillator’s Phase-Sync Holdover End alarm is raised

� Clock Adjustment reduces Phase Drift to less than 10us

�-1 GPS time becomes available & actual drift >= 10 us

�-2 GPS time becomes unavailable

GPS time becomes unavailable

Upon entry (state transition):• Set upsynchronousSystemTime in systemTimeInfo in SIB8;

• Perform DSIM (SIB8 & SIB1);• Start Fine Clock Adj (if not running)Afterward:• Update the IE everysib8Periodicity

Upon entry (state transition):• Set upasynchronousSystemTime in systemTimeInfo in SIB8;

• Perform DSIM (SIB8 & SIB1);• Start Fine Clock Adjustment;Afterward:• Update the IE everysib8Periodicity

Upon entry (state transition):• Remove systemTimeInfo from

SIB8;• Perform DSIM (SIB8 & 1);• Stop Fine Clock Adjustment (if

running).

GPS time becomes available

Upon entry (state transition):• Stop Fine Clock Adjustment.

�-3 GPS time becomes available and actual drift is < 10us

707

Figure 9: Invocation of DSIM & CNP due to eNB internal state change. 708

709

710

711

The eNB supports reception of CdmaPhaseSync and GpsTime state change notification from 712

the OAM, which can trigger a state transition as illustrated in the figure. The state 713

transition is communicated to the DL Scheduler to trigger DSIM & CNP via an enhanced 714

interface between the CallP and DL Scheduler. For the case with label (5) or label (4-3) in 715

the figure, the CallP 716

• Sets cdma-EUTRA-Synchronisation in systemTimeInfo in SIB8 to True; 717

• Does not populate synchronousSystemTime (a 39-bit field with 10ms granularity) in 718

systemTimeInfo since the DL Scheduler is to initialize it based on GPS time from 719

the platform, and subsequently update it every Sib8Periodicity; 720

• Sets a field-size flag to 39 and includes an “offset” parameter where 721

synchronousSystemTime field of 39 bits in systemTimeInfo would start relative to 722

the start of the encoded Sys Info to be sent to the DL Scheduler. 723

For the case with label (4-1) in the figure, the CallP 724

• Sets cdma-EUTRA-Synchronisation in systemTimeInfo in SIB8 to False; 725

• Does not populate asynchronousSystemTime (a 49-bit field with 6.5us granularity) 726

in systemTimeInfo since the DL Scheduler is to initialize it based on both GPS time 727

and an offset to GPS 1PPS from the platform, and subsequently update it every 728

Sib8Periodicity; 729

• Sets the field-size flag to 49 and includes an “offset” parameter where 730

asynchronousSystemTime field of 49 bits in systemTimeInfo would start relative to 731

the start of the encoded Sys Info message to be sent to the DL Scheduler. 732

In the async-mode case: 733

• The time offset to GPS 1PPS message is provided directly by the platform to the DL 734

Scheduler in unit of 500ns (0.5us). At a phase misalignment correction rate of 10 PPB 735

(parts per billion) or 10ns per second, it takes 50 seconds for the platform to correct 736

Mise en forme : Puces etnuméros



<End: SRS-026072-75>




500ns worth of phase misalignment and 13 TimeOffset messages at most to accumulate 737

6.5us (=500ns * 13) worth of misalignment correction that has an actual effect on 738

asynchronousSystemTime in SIB8 since async-mode granularity is 6.5us. 739

• While the DL Scheduler receives the SIB8 update from the CallP via one transport path 740

and receives the TimeOffset message from the platform via another transport path, 741

the actual broadcast of updated SIB8 won’t take place until the start of next 742

Modification Period (at least 320ms if MIM defaultPagingCycle = 320ms), allowing the 743

DL Scheduler to get the TimeOffset value in time to initialize asynchronousSystemTime 744

field in SIB8 ahead of its actual transmission. 745

For the case with labels (3) & (4-2) in the figure, the CallP sets the field-size flag to 0 746

indicating exclusion of systemTimeInfo from SIB8. 747

Note that the bit “offset” parameter has to take into account whether the DL Scheduler is 748

to map multiple SIBs with the same periodicity value to a single Sys Info message. 749

750

751

The optional GpsTime MO is already supported in LA2.x MIM and CdmaPhaseSync sub-MO is 752

added underneath it (see Figure 10). 753

754

Enb

GPS Time(GpsTime)

CDMA Phase Sync(CdmaPhaseSync)

[0..1]

Operational State(operationalState)

Availability Status(availabilityStatus)

ClockSync

755

Figure 10: OAM/ data model where eNB internal state change triggers DSIM & CNP. 756

757

758

759

4.2.5 SYSTEM INFORMATION IMPACTING UE CONNECTIVITY, IDLE MODE CELL 760

RESELECTION AND INTER-RAT MOBILITY 761

With dynamic modification of System Information, the parameters whose modification 762

could affect UE connectivity have been analyzed by RAN1 in [R11] and are listed 763

hereunder: 764

- (2)RBN in [R2] TS 36.211 indicates the number of CQI only RBs. This corresponds to 765

parameter "nRB-CQI" in the pucch-Configuration IE of the SystemInformationBlockType2. 766

- (1)csN in [R2] TS 36.211 indicates the number of CS values used for CQI in mixed RBs of 767

CQI and ACK/NACK or SR. This corresponds to parameter "nCS-An" in the pucch-768

Configuration IE of the SystemInformationBlockType2. 769



<End: SRS-026072-360>



<End: SRS-026072-85>




- (1)PUCCHN in [R3] TS 36.213 indicates the boundary between the resource for ACK/NACKs 770

for persistent scheduling or SR and the resource for ACK/NACK for dynamic scheduling. 771

This corresponds to parameter "n1Pucch-AN" in the pucch-Configuration IE of the 772

SystemInformationBlockType2. 773

- PUCCHshift∆ in [R2] TS 36.211 indicates how to use the PUCCH resource. This corresponds to 774

parameter «deltaPUCCH-Shift" in the pucch-Configuration IE of the 775

SystemInformationBlockType2. 776

At this stage no other parameters are considered to possibly affect UE connectivity when 777

modified dynamically. 778

779

While L97933 supports a standards-compliant mechanism to notify UEs of a change of the 780

content in System Information, it is an independent case-by-case study to determine 781

whether any of the parameters listed above can be changed to “Class C” to take advantage 782

of L97933 capabilities with a minimal impact on UE connectivity. 783

In addition to UE connectivity, dynamic modification of System Info also impacts idle-mode 784

UE cell reselection and active UE inter-RAT mobility. This is because some SIBs-related 785

parameters and MOs/sub-MOs are optional and, if of “Class C” type, can become present or 786

absent dynamically. And once present and included in System Info, both optional and 787

mandatory components of the SIB can change dynamically (if “Class C”). Thus a case-by-788

case study may be necessary to determine whether the corresponding SRS needs any 789

additional requirements for eNB interaction behavior to meet customer’s expectations. 790

As an example, consider LTE-to-HRPD mobility. SIB8 in System Info is optional; if present, it 791

has an influence on idle UE cell reselection. If the IRAT feature control is also activated, the 792

influence of SIB8 extends to active UE IRAT redirection/mobility and the associated KPI. This 793

means once SIB8 is included in System Info, dynamic change of parameters in SIB8 can have 794

an impact on new calls, existing calls, and incoming HO calls. To handle the interaction, 795

• Document ref [A3] specifies CallP behavior in terms of dynamic inclusion or exclusion of 796

SIB8 in System Info and specifies what to do for new/existing calls if SIB8 content 797

changes; 798

• Document ref [A11] (FTS for FRS-97933) specifies the handling of the (cdma2000) 799

systemTimeInfo IE in SIB8 discussed in the next paragraph, which is optional and subject 800

to dynamic transition between “sync mode” and “async mode” as GPS time is lost and 801

regained This is part of L84876. 802

803

804

Note: Periodically modifying the following IEs (e.g. per sib8Periodicity in MIM) is not 805

subject to System Information change notifications or modification of the SIB1 value tag: 806

- cdma2000-SystemTimeInfo (SIB8) 807

- oneXRTT-LongCodeState (SIB8) 808

- any IE of SIB11 809

810

4.2.6 CELL LOCK/UNLOCK 811

The operator has the possibility, from the OMC, to lock or unlock a cell, through 812

“administrativeState” attribute attached to LteCell object class. 813

When a cell is unlocked, it is set up and once the setup procedure is successfully 814

performed, telecom service is offered in the cell. 815




When a cell is locked, all established calls are immediately released and the resources 816

allocated to the cell are freed. In LA3.0 and beyond, this is performed through without a 817

reset of the modem board hosting those resources. Once the modem board has restarted, 818

the The cell will not be setup until the unlock command has been issued. As long as the 819

cell is locked, the cell is not radiating. 820

This administrative state is preserved through an eNB restart, so that a cell that has been 821

locked remains locked after the eNB restart. 822

823

4.2.7 FAILURE CASES 824

4.2.7.1 CELL SETUP FAILURE 825

Cell setup may fail, either because the modem board is not responding or is failing to 826

perform the cell setup procedure. In this case the managed object LteCell's state is 827

changed to Disabled/Failed. 828

If the modem board is not responding, no alarm is raised by CallP and no modem reset is 829

performed. When the modem has restarted, the cell setup procedure is attempted again. 830

If the cell setup procedure is failing in the modem board, it will raise a critical alarm 831

which will trigger its own reset. When the modem has restarted, the cell setup procedure 832

is attempted again. 833

The alarm shall be cleared if the error is removed later. 834

835

4.2.7.2 MODEM FAILURE 836

In the event of a modem failure (in other words a reset), the state of managed object 837

LteCell is changed to Disabled/Dependency. All established calls are released: RRC 838

resources are locally released (in other words no RRC message exchanges occur) and the 839

MME is notified via a UE Context Release Request message. 840

841

4.2.7.3 CELL BARRING DUE TO LOSS OF S1 SERVICES 842

After successful cell setup if S1 service (availability/ connectivity) on the last S1 link is lost 843

from either the eNB side or MME side due to faults or customer OAM actions, UEs in the eNB 844

coverage area attempting calls will keep failing unless the eNB declares all of its cells as 845

“barred” (changing cellAccessRelatedInfo.cellBarred=‘barred’ in SIB1). 846

For UEs in the vicinity of barred eNB coverage area, cell-barring allows the UEs to select 847

neighbor LTE cells on the same freq or perform inter-RAT mobility (if the feature is already 848

activated at the neighboring eNBs), limiting the service impact and corresponding KPI 849

degradation. 850

If LteCell::cellBarred = 'notBarredAutobarrable’, the eNB starts a timer per 851

Enb::cellBarringHysteresisTimer value when the last S1 link is lost and performs self-852

triggered cell barring when the timer expires without S1 link recovery by utilizing the DSIM/ 853

CNP procedure (see section 4.3.1 page 32). Once triggered, the eNB cease to handle any 854

calls including emergency calls. 855

With CR #269239 (interaction of Sys Info broadcast and S1 link status during cell setup): 856

• During cell setup the eNB starts Sys Info broadcast as soon as the cell starts radiating 857

while S1 links setup is being performed in parallel. LteCell is set to “Enabled/ off-duty” if 858

LteCell::cellBarred = ‘barred’ and to “Enabled/ none”, otherwise. 859



<End: SRS-026072-290>




• If LteCell::cellBarred = 'notBarredAutobarrable’ and no S1 link is up when eNB starts Sys 860

Info broadcast, the eNB also starts the Enb::cellBarringHysteresisTimer. If at least one S1 861

link becomes in service prior to the timer expiry, the timer is cleared and LteCell remains 862

in “Enabled/ none”. Otherwise, the eNB auto-bars each cell that has LteCell::cellBarred 863

= 'notBarredAutobarrable’ via DSIM/ CNP and changes LteCell to “Enabled/ off-duty”. 864

865

The eNB will not perform cell barring in case all the MMEs have a capacity set to 0. In this 866

case, Calls for UE providing either S-TMSI or registeredMME in RRC Connection are always 867

accepted. 868

Open point : in LA3.0, RO MMEAccessGroup could be used to determine if there is at least 869

one S1 link available. OAM-C could set the OperState of RO MMEAccessGroup. 870

871

4.2.8 INTERACTIONS WITH OTHER FEATURES 872

With CR #269239 S1 link availability is not a pre-condition for Sys Info broadcast, i.e., 873

during cell setup the Sys Info is broadcast as soon as the cell starts radiating with LteCell 874

set to "Enabled/ none" or “Enabled/ off-duty” based on the settings of LteCell::cellBarred, 875

while the parallel S1 links setup is in progress (see the CR update in Section 4.2.7.3). 876

877

If all S1 links fail at a later stage, the cells shall remain set up and the eNB shall continue 878

to broadcast System Information. This allows the eNB to self-trigger cell-barring via 879

dynamic System Info modification as described in Section 4.2.7.3. 880

881


Feature Number: CR #269239 Author: Jin Wang

<End: SRS-026072-300>


Feature Number: CR 00269239 Author: Jin Wang

<End: SRS-026072-190>




4.3. PAGING 882

4.3.1 INTRODUCTION 883

Paging messages are sent over the PCCH logical channel. PCCH is mapped onto the PCH 884

transport channel, which itself is carried on the PDSCH physical channel. Transport format 885

and resource allocation for the PCH channel is signaled on the PDCCH channel, using the 886

dedicated P-RNTI (defined as 0xFFFE in [R5] TS 36.321). 887

PCCH uses RLC and MAC Transparent Mode, which implies that the RRC layer must perform 888

padding. 889

The moment at which a given UE can be paged in a paging frame (same length as a radio 890

frame) is called a Paging Occasion, as defined in [R4] TS 36.304. The paging occasion for a 891

given UE is calculated using the three following parameters: 892

- the UE_ID, equal to the UE IMSI modulo 1024. This is provided to the eNB in 893

the S1 Paging message by mandatory information element "UE Identity Index 894

Value", 895

- the DRX Paging Cycle; either the default value transmitted in the System 896

Information (defaultPagingCycle in SIB2), or the UE-specific value received in 897

the S1 Paging message if it is shorter. 898

- parameter nB, transmitted in the System Information (in SIB2), which defines a 899

sort of "paging occasion density" within a radio frame. 900

These three parameters participate in creating time diversity for the sending of paging 901

messages. In other words, they spread out in time the opportunities for paging and in this 902

way limit the scheduling conflicts while allowing the UEs to go into DRX mode and reduce 903

their power consumption. 904

The UE_ID splits the UE population into groups with identical paging occasions. All UEs 905

with the same UE_ID (defined as IMSI modulo 1024) shall be paged within the same unique 906

paging occasion. However a given paging occasion is always shared by at least four UE_ID 907

groups, and generally much more (in the "worst" case, all UEs share a single paging 908

occasion). 909

The DRX Paging Cycle defines the period over which paging messages will be spread. A 910

given UE will have one and only one paging occasion during the paging cycle; if the 911

occasion was missed (because the S1 Paging came after the occasion or because there 912

were too many paging records buffered for the given paging occasion), the eNB will have 913

to buffer the “spill-over” paging records until the next paging cycle. The length of the 914

paging cycle is a trade-off between mobile terminating call establishment performance on 915

the one hand (the shorter the cycle the sooner the mobile will be paged) and paging 916

capacity on the other hand (the longer the cycle, the more paging occasions there will be). 917

The per-UE DRX Paging Cycle may be set to 32, 64, 128, or 256 radio frames (note that this 918

parameter is called "T"in [R4] TS 36.304). 919

Parameter nB is expressed as a multiple or divisor of the paging cycle: it defines the ratio 920

of paging occasions to the number of radio frames. It is defined as an enumerated taking 921

its values in the following range: {fourT, twoT, oneT, halfT, quarterT, oneEighthT, 922

oneSixteenthT, oneThirtySecondT}. Note that in LA3.0, in order to allow fixed VoIP and 923

PCCH bandwidth allocation (see [A5] for more details), a maximum of 1 paging sub-frame 924

per frame is supported; this implies that values "fourT", "twoT" and "oneT" are not 925

permitted for nB in LA3.0. If for example nB is set to "twoT", there will be two paging 926

occasions in each radio frame; if it is set to "quarterT", there will be one paging occasion 927

every four radio frames. The trade-off here is between radio resources (the smaller the nB 928

is, the less radio resources may be consumed by paging) and paging capacity (the bigger 929

the nB, the more paging occasions there are for a given paging cycle). 930

931




0

1

2

3

1022

1023

IMSIs

(up to 1021

values)

mod 1024

UE_ID

0

1

n-1

n

Paging Occasions (*):

1 to 1024

(*): depends on the DRX

Paging Cycle and nB 932

Figure 11: From IMSI to a paging occasion 933

934

A paging occasion for a given UE occurs within a given radio frame (referred to as a "paging 935

frame") at a given subframe number. 936

The paging frame for a given UE is characterized by: 937

SFN mod T = (T div N) * (UE_ID mod N) 938

The subframe number of a given UE's paging occasion is retrieved from a table using the 939

index i_s defined as follows: 940

i_s = floor(UE_ID / N) mod Ns 941

The previous formulas use the following parameters: 942

T is the DRX Paging Cycle, expressed in numbers of radio frames. The DRX Paging Cycle is 943

either parameter defaultPagingCycle broadcast in SIB2, or the UE-specific value received 944

in the S1 Paging message if it is shorter (pagingDRX optional information element). Its 945

values are in range {32, 64, 128, 256}. 946

nB is the parameter broadcast in SIB2, taking its values in the range {4T, 2T, T, T/2, T/4, 947

T/8, T/16, T/32}. 948

N is equal to min(T, nB). N defines the number of frames within the paging cycle that will 949

be used for paging, or in other words, the number of paging frames. With the different 950

possible values for T and nB, this may be as little as 1 or can represent all the radio frames 951

within the paging cycle. 952

Ns is equal to max(1, nB/T); given the definitions for T and nB, Ns is therefore in the range 953

{1,2,4}. Ns defines the number of subframes used as paging occasions within a paging 954

frame. 955

UE_ID is equal to IMSI mod 1024, provided to the eNB in the S1 Paging message by 956

mandatory information element "UE Identity Index Value". 957

Index i_s allows looking up in the following table the subframe number depending on the 958

value of Ns. 959

Ns \ i_s 0 1 2 3

1 9 NA NA NA

2 4 9 NA NA

4 0 4 5 9

960




Once the paging occasion has been determined, the ue-Identity (referred to as "UE Paging 961

ID" in the S1 Paging message) and pagingCause are buffered until the time comes for the 962

paging frame and associated subframe pointed to by the paging occasion. 963

When this moment arrives, a maximum of 16 paging records buffered for this paging 964

occasion may be encoded in an RRC Paging message. This will be the responsibility of the 965

DL scheduler. 966

A paging message may also contain a notification of system information change. 967

968

ENB supports dynamic System Info modification (DSIM) using Change Notification Paging 969

(CNP) (Refer to section 4.2.4). For each Paging Occasion (PO) in a paging frame over a full 970

paging cycle, the optional systemInfoModification flag in the Paging message is sent as a 971

standalone page if the PO has no S1-based page records, and is piggybacked with S1 page 972

records, otherwise. 973

Since all UEs in RRC Idle and RRC Connected need to be notified about an upcoming 974

change in System Info, CNP needs to be applied to each and every PO in a paging cycle. 975

This means the eNB can use the defaultPagingCycle and other pre-change parameters nB, 976

Ns etc to determine all the POs without the need to know the UEs IMSIs (in fact the eNB 977

does not know idle UEs IMSIs anyway). 978

As per 3GPP 36.304 (ref [R4]), a UE may provide a per-UE DRX shorter than the 979

defaultPagingCycle of the cell, in this case, this DRX value will be provided to the 980

scheduler. The per-UE DRX paging cycle has to be ½ to 1/32 of the defaultPagingCycle. 981

The UE will wake up two or more times within the defaultPagingCycle to listen to a page 982

destined for it, and one of them will coincide with the PO calculated using the 983

defaultPagingCycle. 984

985

986

4.3.2 PAGING PROCEDURE 987

Upon receiving a Paging message on the S1 interface, the eNB determines the list of cells 988

on which to page the UE from the TAIList IE in the S1 Paging message. 989

For each cell on which the UE must be paged, the CallP shall: 990

- compute the frame number and subframe number of the UE's paging occasion, 991

- encode the paging record for the given UE, 992

- send this data to the Scheduler along with the paging cycle to be used 993

994

4.3.2.1 FRAME AND SUBFRAME COMPUTATION 995

Computing the frame and subframe number will use the following inputs: 996

- the UEIdentityIndexValue received in the S1 Paging message, hereafter 997

referred to as the UE_ID, 998

- the DRX Paging Cycle, hereafter referred to as the drxPagingCycle and 999

expressed in number of radio frames, which shall be either the pagingDRX IE if 1000

received in the S1 Paging message, or the default value from the MIM 1001

(defaultPagingCycle in object Enb) which is used to populate the 1002

defaultPagingCycle in SIB2, 1003

- parameter nB of the MIM (nB in object LteCell), which is also used in SIB2. 1004

1005




The frame number shall be calculated as follows: 1006

frameNumber = (drxPagingCycle div min(drxPagingCycle, nB) * (UE_ID mod 1007

min(drxPagingCycle, nB) 1008

Note that this frame number is relative to the DRX Paging Cycle, therefore the CallP must 1009

provide value of the DRX Paging Cycle along with the frame number for it to be significant. 1010

The subframe number shall be the one pointed by index i_s, which is calculated as follows: 1011

i_s = floor(UE_ID / min(drxPagingCycle, nB)) mod max(1, nB/drxPagingCycle) 1012

The subframe number will be taken from the following table, indexed both by i_s and by 1013

Ns = max(1, nB/drxPagingCycle). 1014

Table 2: Paging occasion subframe number 1015

Ns \ i_s 0 1 2 3

1 9 NA NA NA

2 4 9 NA NA

4 0 4 5 9

1016

4.3.2.2 ENCODING OF THE PAGING RECORD 1017

CallP shall perform the ASN1 encoding of a single paging record, defined as the following 1018

ASN1 type: 1019

SEQUENCE { ue-Identity PagingUE-Identity, 1020

cn-Domain ENUMERATED {ps, cs}, 1021

...} 1022

CallP will use the UEPagingID and CNDomain received in the S1 Paging message to encode 1023

the ue-Identity and cn-Domain. 1024

1025

Once frame and subframe number have been computed, and the paging record encoded, 1026

CallP shall send these along with the DRX paging cycle used in the computations to the 1027

Scheduler (the DRX paging cycle used is either the UE-specific one received in the S1 1028

Paging message or the default paging cycle taken from MIM that is also broadcast in SIB2). 1029

The message sent from CallP to Scheduler shall therefore contain the following 1030

parameters: 1031

- frame number within the DRX paging cycle at which the Paging must be sent, 1032

- subframe number within the radio frame at which the Paging must be sent, 1033

- length of the DRX paging cycle, expressed in number of frames, 1034

- paging record length in bits, 1035

- paging record ASN1-encoded. 1036

1037

4.3.2.3 SCHEDULER BEHAVIOR 1038

Refer to [A5] for detailed Scheduler behavior. Hereafter is a brief summary. 1039

The Scheduler will compute the next SFN that matches the frame number provided by 1040

CallP given the DRX paging cycle. The paging record will be stored in a FIFO buffer 1041

associated to the computed SFN and subframe number provided by CallP. 1042


Feature Number: L92025 / L92026

Author: Jean-Michel Pugeat <End: SRS-026072-150>




Paging records may be stored for a given SFN / subframe couple up to 1 millisecond before 1043

its occurrence in time. 1044

At 1 millisecond prior to the occurrence of SFN and subframe, content of the Paging 1045

message will be frozen and encoded. If there are no UEs to page at the SFN / subframe 1046

occasion, any reserved resources shall be released. Otherwise the Scheduler will 1047

concatenate an RRC Paging message header and up to 16 paging records in order to 1048

constitute the RRC Paging message that will be sent. Bits of padding (set to 0) will be 1049

added for octet-alignment of the RRC Paging message, as well as for alignment to the 1050

chose resource block size. 1051

Details of how the RRC Paging message shall be assembled are provided in Annex C. 1052

1053

1054

4.4. S1 SETUP 1055

The S1 setup procedure consists of: 1056

- S1 SCTP association setup procedure described in[A8]. 1057

- S1-AP S1 setup procedure described in this section. 1058

1059

4.4.1 PREREQUISITES 1060

The S1 SCTP association must be successfully set up, either at eNB startup or following an 1061

S1 link failure. 1062

1063

4.4.2 SUCCESSFUL CASE 1064

The purpose of the S1 Setup procedure is to exchange application level data needed for 1065

the eNB and MME to interoperate correctly over the S1 interface. 1066




ENB MME

S1 SCTP Association is set up

ENB MME

S1 SETUP RESPONSE

MME NameServed GUMMEIs (1 to 8)>Served PLMNs (1 to 32)

>>PLMN Identity>Served GroupIDs (1 to 16)

>>MME GroupID>Served MMECs (1 to 16)

>>MME Code Relative MME Capacity

Criticality Diagnostics

S1 SETUP REQUEST

Global eNB IDeNB NameSupported TAs (1 to 256)>TAC>Broadcast PLMNs (1 to 6) >>PLMN IdentityDefault paging DRX

1067

1068

Figure 12: S1 Setup Success 1069

The eNB initiates the procedure by sending a S1 SETUP REQUEST message including its own 1070

configuration data to the MME. This message shall be the first S1AP message sent after the 1071

TNL association has become operational, i.e. the S1 SCTP association is successfully setup 1072

as specified in [A8]. 1073

The MME responds with S1 SETUP RESPONSE including its own configuration data. 1074

The received data shall be stored in the eNB and used for the duration of the TNL 1075

association. It may be updated by a subsequent MME Configuration Update procedure. It 1076

shall not be erased during a Reset procedure. When this procedure is finished S1 interface 1077

is operational and other S1 messages can be exchanged; in particular, calls can be set up. 1078

The maximum number of Served GroupIDs and Served MMECs are defined in standard with 1079

values respectively 65536 and 256. To avoid memory consumption, the eNB will limit the 1080

number of saved information to 16 Served GroupIDs and 16 Served MMECs. In LTE 1081

networks, one MME should support only one GroupID and one MME code. The potential 1082

issue is with configuration data received for other RATs (2G or 3G) which may exceed our 1083

design values. If more than 16 instances of Served GroupIDs and Served MMECs are 1084

received, they will be ignored by eNB, only the first ones will be stored by eNB. 1085

Please note that according to 3GPP TS 36.413, LTE served group will always be found at 1086

the first place in the list of groups provided by the MME in S1 SETUP RESPONSE. 1087

In case there is at least one X2 instance setup already, on reception of a S1 Setup 1088

Response message from a MME, an eNB shall compute the GU Group ID List (see section 1089

4.13.3.1). 1090

A S1 Setup procedure clears the MME overload action (Not in LA3.0). 1091

1092


Feature Number: L101845 Author: M. Gateau

<End: SRS-026072-340>





4.4.3.1 S1 SETUP FAILURE 1094

1095

ENB MME

S1AP S1 SETUP REQUEST

MME rejects the setup procedure by sendingS1 SETUP FAILURE

ENB MME

S1 SETUP FAILURE

Cause (M)TimeToWait (O)

CriticalityDiagnostics(O)


set s1SetupTimer

set timer T

set s1SetupTimer

if TimeToWait (O) wasn’t present, set timer T with a duration randomly chosen

among possible values

if TimeToWait (O) has been received, set timer T with

duration TimeToWait

ENB resends S1 SETUP REQUEST to the MME until it is successfulAfter three consecutive failures, an alarm is raised to SAM

(The alarm is cleared when the S1 Setup is successful and on SCTP shutdown)


stop s1SetupTimer

timer T expires

1096

1097

Figure 13: S1 Setup Failure 1098

1099

In case of encoding issue of S1 Setup message, due for example to an incorrect parameter, 1100

an alarm MME_S1_SETUP_REQUEST_NOT_SENT is raised. This alarm is cleared when the S1 1101

Setup is successful and on SCTP shutdown. 1102


Feature Number: CR #321636 / CR #325845

Author: Wang Yunhua / Martine Gateau <End: SRS-026072-410>


Feature Number: CR #325845 <End: SRS-026072-500>






4.4.3.2 NO RESPONSE TO S1 SETUP 1103

1104

ENB MME

ENB MME



set s1SetupTimer

set s1SetupTimer


s1SetupTimer expires

ENB resends S1 SETUP REQUEST to the MME until it is successfulAfter three consecutive failures, an alarm is raised to SAM

(The alarm is cleared when S1 Setup is successful and on SCTP shutdown)

1105

1106

Figure 14: No Response To S1 Setup 1107

1108

4.4.3.3 S1 LINK FAILURE 1109

S1 Link failures are detected at SCTP level as described in [A8] and reported via a state 1110

change notification: the underlying MMETransportLayerAccess object becomes 1111

Disabled/Failed. The MMEAccess object state becomes Disabled/Dependency and remains 1112

so while the SCTP association is down. 1113

When the SCTP association is reestablished, the eNB will trigger a new S1 Setup procedure 1114

as specified in section 4.4.2. 1115

If calls are ongoing for the associated MME when the S1 link failure occurs, S1 resources 1116

associated to the calls are locally released (in other words without any S1 messages 1117

exchanged) and the UE are notified via an RRC Connection Release procedure. More details 1118

can be found in [A1]. 1119

1120

4.4.4 S1 FLEX 1121

S1 Flex describes the ability for the eNB to be connected to more than one MME; up to 16 1122

in LA3.0. When the eNB is connected to several MMEs, it must select one MME to establish 1123

an S1 link for a given UE. 1124


Feature Number: CR #321636 / CR #325845

Author: Wang Yunhua / Martine Gateau <End: SRS-026072-420>






Details of the MME selection process are found insection 4.15. 1125

When the eNB is connected to several MME, the S1 Setup procedures will be triggered as 1126

soon as the SCTP association for each MME is available, and may therefore happen in 1127

parallel. They may also run in parallel to X2 Setup procedures. The relative MME capacity 1128

received during the setup procedure will be stored for future use at call establishment, as 1129

specified in[A1]. 1130

Once an S1 connection is set up successfully and System Info broadcasting starts, calls can 1131

be setup through the S1. S1 links can subsequently be lost due to various reasons. If the 1132

last S1 connection on the eNB is lost, the eNB triggers cell-barring as described in Section 1133

4.2.7.3. When any S1 link is recovered, the cells are un-barred. 1134

1135


S1 management has interactions with call setup and inter-eNB handover: 1137

- Call setup interactions: 1138

- when all S1 links are not operational (all MmeAccess managed objects are 1139

in a state different from Enabled/None), RRC connection attempts are 1140

rejected using RRC Connection Reject message 1141

- Inter-eNB handover interactions: 1142

- when the S1 link to the MME designated by the GUMMEI information 1143

element in the X2 Handover Request is not operational, the eNB shall 1144

reject the handover request using Handover Preparation Failure 1145

1146

1147

4.4.6 S1 LINK LOCK/UNLOCK 1148

An S1 link can be locked or unlocked through administrativeState attribute attached to 1149

MMEAccess object instance. 1150

An unlocked S1 link will be established and allowed to operate. 1151

A locked S1 link will not be established. 1152

Note: “shuttingdown” value is not currently supported. 1153

1154

Following chapters specify eNB behavior on transitions from “unlock to lock” and “lock to 1155

unlock”. 1156

1157

4.4.6.1 BEHAVIOR WHEN LOCKING AN S1 LINK 1158

Locking an S1 link is performed by setting MMEAccess administrativeState to “locked”. 1159

In this case, if the S1 link was established, it has to be released. Underlying SCTP 1160

association does not need to be released itself, however, as the only way to release S1 link 1161

is to release also SCTP, when S1 lock command is received, the eNB will shutdown 1162

underlying SCTP association. 1163

As long as S1 link is locked, S1 link will not be established (meaning S1 setup procedure 1164

will not be triggered). 1165

A SCTP INIT may not be received from the MME. MME shall send a SCTP INIT only in case of 1166

MME failure, for redundancy purpose. 1167


Feature Number: L113614 (TLA3.0) / L108282 (LA3.0)

Author: Yunhua Wang <End: SRS-026072-270>




1168

4.4.6.2 BEHAVIOR WHEN UNLOCKING AN S1 LINK 1169

Unlocking an S1 link is performed by setting MMEAccess administrativeState to 1170

“unlocked”. 1171

In this case, it shall be established through S1 setup procedure. Of course, underlying SCTP 1172

association shall be established beforehand if not already up. 1173

1174

4.4.7 S1 ONLINE CREATION 1175

Open point: to be updated for LA3.0 with L108282. Post LA2.0, it is now possible to create 1176

online an MMEAccess instance along with its underlying MMETransportLayerAccess instance 1177

(MMETransportLayerAccess cardinality ensures that if an MMEAccess instance is created, 1178

then associated MMETransportLayerAccess instance will also be). 1179

eNB behavior on MMEAccess instance creation will be: 1180

- If S1 link is unlocked, it will be established 1181

- If S1 link is locked, it will not be established 1182

1183

4.4.8 S1 ONLINE DELETION 1184

Open point: to be updated for LA3.0 with L108282. Post LA2.0, it is also possible to delete 1185

online an MMEAccess instance along with its underlying MMETransportLayerAccess 1186

instance. 1187

eNB behavior in case of S1 link deletion will be 1188

- If S1 link was established, it will be released through SCTP shutdown 1189

- If it was not, it will be simply removed from the MIB 1190

1191

1192

4.5. S1 MME CONFIGURATION UPDATE 1193

The purpose of the MME Configuration Update procedure is to update application level 1194

configuration data needed for the eNB and MME to interoperate correctly on S1 interface. 1195

This procedure doesn’t affect existing UE-related contexts, if any. 1196

S1 MME Configuration procedure can’t be deactivated; it is not related to an activation 1197

flag (CR #344432). 1198

1199





ENB MME

ENB MME

MME CONFIGURATION UPDATE

MME NameServed GUMMEIs (1 to 8)>Served PLMNs (1 to 32)




MME CONFIGURATION UPDATE ACKNOWLEDGECriticality Diagnostics

1201

Figure 15: MME Configuration Update Success 1202

The MME initiates the procedure by sending a MME CONFIGURATION UPDATE message 1203

including the appropriated updated configuration data to each of the eNBs currently 1204

connected with it. 1205

The eNB responds with MME CONFIGURATION UPDATE ACKNOWLEDGE message to 1206

acknowledge that it has successfully updated the configuration data. 1207

The received data shall be stored in the eNB and used for the duration of the TNL 1208

association until reception of a new MME Configuration Update message. It shall not be 1209

erased during a Reset procedure. 1210

If top-level information element(s) is/are not included in the MME Configuration Update 1211

message, the eNB shall interpret that the corresponding configuration data is/are not 1212

changed and shall continue to operate the S1 with the existing related configuration data. 1213

The following configuration data can be updated: 1214

- MME Name: if present it shall be stored by the eNB and used as a human readable 1215

name of the MME, e.g. for alarms. 1216

- Served GUMMEIs: the eNB shall store the Served GUMMEIs and use the first on the 1217

list for L97982 purpose. Per June-2009 36.413 the first one in the list relates to LTE 1218

configuration pool and the rest relate to 2G/3G pools (for example if a UE was in 3G 1219

connected to a pool of "combined" 3G SGSN/ MME and then moves to LTE, eNB 1220

would select the same combined node if possible). The eNB shall compute the GU 1221

Group Id List based on the GUMMEI information received from the MME (see section 1222

4.13 Support of MME group for more details). 1223

- Relative MME Capacity: the new MME Capacity received from MME shall be stored by 1224

the eNB. 1225




In case there is at least one X2 instance setup already, on reception of a MME 1226

Configuration Update message from a MME, an eNB shall compute the GU Group ID List 1227

(see section 4.13.3.1) 1228

It’s possible that the Relative MME Capacity is changed to a lower value or even to 0. 1229

• For new calls, the new Relative MME Capacity info will be taken into account in MME 1230

selection; 1231

• For existing calls, the MME can take CAC action (see above); 1232

• For S1-based HOs, no MME relocation is performed as long as target eNB has S1 1233

connectivity with MME. The decision to perform MME relocation in case there is no 1234

connectivity or in overload condition is MME dependant. If the Target eNB receives an 1235

HO Request message from an MME (with or without MME relocation), it will respond to 1236

the message and let the MME decide whether to reject the HO or not. 1237

Relative MME capacity set to 0 means some OAM action was taken on the MME (e.g. for 1238

maintenance) and ALU MME will, over a time window, gradually release RRC Connected 1239

UEs (not in emergency calls) by sending UE Context Release Request messages to the UEs 1240

via the eNB with the Cause IE set to 'Load Balancing TAU Required'; the affected UEs send 1241

TAU in response. A different MME (if available) is then selected. Other vendor’s MME may 1242

or may not do this. 1243

The configuration received for non supported PLMNs shall be ignored by eNB. 1244

1245


ENB MME

ENB MME

MME CONFIGURATION UPDATEMME Name

Served GUMMEIs (1 to 8)>Served PLMNs (1 to 32)




MME CONFIGURATION UPDATE FAILURE

Cause

Time To Wait


1247

Figure 16: MME Configuration Update Failure 1248

1249




If the eNB can not accept the update or it encounters problems such as ASN1 decoding 1250

errors, it shall respond with an MME CONFIGURATION UPDATE FAILURE message: 1251

- In case none of the PLMN provided by MME matches with supported PLMN(s) of the eNB, it 1252

shall reject the MME Configuration Update procedure with cause “Unknown PLMN”, Time 1253

to wait set to MMEConfigurationUpdateTimeToWait hardcoded value, e.g. 60s (maximum 1254

value allowed as this case is relevant to an incoherent configuration). 1255

4.6. S1 ENB CONFIGURATION UPDATE 1256

The purpose of the S1AP ENB Configuration Update procedure is to update application 1257

level configuration data needed for the eNB and MME to interoperate correctly on S1 1258

interface. This procedure doesn’t affect existing UE-related contexts, if any. 1259

1260


ENB MME

ENB MME

ENB CONFIGURATION UPDATE ACKNOWLEDGE


ENB CONFIGURATION UPDATE

Supported TAs (0 to 256)>TAC>Broadcast PLMNs (1 to 6)>>PLMN IdentityCSG Id List (0 to 256)>CSG IdDefault paging DRX (optional)

1262

1263

eNB behavior 1264

To allow dynamic update of the Tracking Area codes, the MIM parameter LteCell-1265

>trackingAreaCode needs to be a Class C parameter, In case of update of TAC values, the 1266

eNB is expected to provide the new list of Supported TAs including updated TAC values to 1267

all MMEAccess instances in oper/none status, using the S1 eNB CONFIGURATION UPDATE 1268

procedure. The whole list of supported TAs including those that are not to be updated 1269

shall be included in the Supported TAs IE. The S1AP ENB CONFIGURATION UPDATE message 1270

shall be sent concurrently to all MMEs with an operational S1 link: MME Access in 1271

Enabled/None state. 1272




Update of Broadcast PLMNs, CSG Id List and Default paging DRX is not supported in 1273

LA3.0.The eNB may initiate a further eNB Configuration Update procedure only after a 1274

previous eNB Configuration Update procedure has been completed 1275

In case of TAC change, DSIM modification shall be performed in parallel with configuration 1276

update on S1 and X2 interfaces: as per 36.413 ref [R6], even in case of ENB Configuration 1277

Update Failure, both node shall continue to operate the S1 with their respective 1278

configuration data. 1279

Enb->defaultPagingCycle is a class B parameter. In case OAM-C notifies both changes of 1280

Enb->defaultPagingCycle and LteCell->TrackingAreaCode in the same transaction, TAC list 1281

and default paging cycle shall be updated using same S1AP ENB CONFIGURATION UPDATE 1282

procedure. 1283


4.6.2.1 S1 ENB CONFIGURATION UPDATE FAILURE 1285

If the MME can not accept the update it shall respond with an eNB CONFIGURATION 1286

UPDATE FAILURE message and appropriate cause value. 1287

If the eNB CONFIGURATION UPDATE FAILURE message includes the Time To Wait IE the eNB 1288

shall wait at least for the indicated time before reinitiating the eNB Configuration Update 1289

procedure towards the same MME. Both nodes shall continue to operate the S1 with the 1290

existing configuration data. 1291

1292

eNB behavior 1293

Upon reception of the S1 eNB Configuration Update Failure, the eNB shall set a timer at 1294

least equal to either the Time To Wait information element if it was received, or to a 1295

random S1TimeToWait value chosen among the range of values allowed by the standard. 1296

The standard allows following values “v1s, v2s, v5s, v10s, v20s, v60s", a random value may 1297

be chosen in any range between two values, e.g. range [1..2] for value v1s, range [60..80] 1298

for value v60s) . 1299

Once this timer expires, the eNB may trigger a new S1 eNB Configuration Update 1300

procedure by sending the S1 eNB CONFIGURATION UPDATE message. 1301

The eNB will retry the S1 eNB Configuration Update procedure S1ConfigurationUpdateRetry 1302

times (hard coded value set to 3). In case there is no successful answer after the retries, 1303

the eNB will shut down S1 connection and restart the S1 Setup procedure. It will send an 1304

event “MME-S1-ENB-Configuration-Update-Failure-Response” to notify the issue to the 1305

operator. 1306




ENB MME

ENB MME

ENB CONFIGURATION UPDATE FAILURE

CauseTime To Wait



Supported TAs (0 to 256)>TAC>Broadcast PLMNs (1 to 6)>>PLMN IdentityCSG Id List (0 to 256)>CSG IdDefault paging DRX (optional)

1307

1308

Figure 17: S1 eNB Configuration Update Failure 1309

4.6.2.2 NO RESPONSE TO S1 ENB CONFIGURATION UPDATE 1310

If the eNB after initiating eNB Configuration Update procedure receives neither eNB 1311

CONFIGURATION UPDATE ACKNOWLEDGE message nor eNB CONFIGURATION UPDATE 1312

FAILURE message, the eNB may reinitiate the eNB Configuration Update procedure towards 1313

the MME, provided that the content of the new eNB CONFIGURATION UPDATE message is 1314

identical to the content of the previously unacknowledged eNB CONFIGURATION UPDATE 1315

message. 1316

When the eNB sends an eNB Configuration Update message, it sets an internal timer that is 1317

stopped if either eNB Configuration Update Acknowledge or eNB Configuration Update 1318

Failure messages are received. If this timer expires, the eNB may trigger a new S1 eNB 1319

Configuration Update procedure by sending the S1 eNB CONFIGURATION UPDATE message. 1320

The eNB will retry the S1 eNB Configuration Update procedure S1ConfigurationUpdateRetry 1321

times (hard coded value set to 3). In case there is no successful answer after the retries, 1322

the eNB will shut down S1 connection and restart the S1 Setup procedure. It will send an 1323

event “MME-S1-ENB-Configuration-Update-No-Response” to notify the issue to the 1324

operator. 1325

1326

The ENB Configuration Update may be successfully acknowledged by some MMEs and failed 1327

by others. As per TS 36.413 ref [R6], in case of failure or no reponse, both nodes shall 1328

continue to operate with their respective configuration. 1329

DSIM operation shall be performed normally. 1330




1331

1332

1333

ENB MME

ENB MME


ENB CONFIGURATION UPDATEset

S1ENBConfiguration

UpdateTimer

set

S1ENBConfiguration

Update Timer

S1ENBConfiguration

UpdateTimer expires

ENB resends ENB CONFIGURATION UPDATE to MME(3 retries maximum)

1334

Figure 18: No Response to S1 eNB Configuration Update 1335

1336

4.7. S1 RESET 1337

The purpose of the Reset procedure is to initialize or re-initialize the E-UTRAN, or part of 1338

E-UTRAN S1AP UE-related contexts, in the event of a failure in the EPC or vice versa. This 1339

procedure doesn’t affect the application level configuration data exchanged during the S1 1340

Setup procedure. 1341

The procedure uses non-UE associated signaling. 1342

1343



<End: SRS-026072-330>




4.7.1 S1 RESET PROCEDURE MME INITIATED 1344

ENB MME

ENB MME

RESET

CauseReset Type

> S1 interface>> Reset All

> Part of S1 interface>> UE associated logical S1-connection list

>>> MME UE S1AP ID>>> ENB UE S1AP ID

RESET ACKNOWLEDGE

>> UE associated logical S1-connection list>>> MME UE S1AP ID>>> ENB UE S1AP IDCriticality Diagnostics

UE

UE

RRCConnectionRelease

1345

Figure 19: Reset procedure MME initiated 1346

1347

1348

Depending on Reset type, the eNB shall release all allocated resources on S1 and Uu 1349

related to the UE associations of this MME interface or only the resources related to the 1350

UE-associated logical S1-connection list provided in Reset message (case of partial reset). 1351

In case of partial reset, the UE associations to be released are identified with 1352

MME_UE_S1AP_ID and/or eNB-UE_S1AP_ID. 1353

In both cases, it has to release for all concerned UE-associated logical S1-connections the 1354

related UE contexts and S1 AP IDs, and release of radio resources (RRC connections)). 1355

1356

It shall answer to MME with a RESET ACKNOWLEDGE message including each UE association 1357

to be reset in the same order as received in the RESET, including also unknown UE 1358

associations (partial RESET case). 1359

If the RESET message contains the Reset All IE, then the eNB shall not include the UE-1360

associated logical S1-connection list IE in the RESET ACKNOWLEDGE message. 1361

The eNB doesn’t need to wait for the release of all radio resources to be completed before 1362

returning the answer. 1363

1364

However, before answering to the MME, the eNB shall remove all the MME_UE_S1AP_IDs in 1365

the contexts related to the concerned UE-associated logical S1-connections. This will 1366

remove in eNB all the concerned MME_UE_S1AP_IDs and allow to accept new calls 1367

immediately after towards this MME and it will be able to reuse these MME_UE_S1AP_IDs 1368

on reception of the RESET ACKNOWLEDGE message. 1369

Commentaire [gme28] : Clarified in 36.413 CR R3-100126 ENB already compliant in LA2.0




S1 configuration received in S1 Setup procedure or subsequent MME configuration update 1370

procedures shall be kept. 1371

The S1 reset procedure aborts all other ongoing procedures (except another reset 1372

procedure) on the same S1 interface related to a UE association. Common procedures (e.g. 1373

MME Configuration Update) are not impacted. 1374

1375




4.7.2 S1 RESET PROCEDURE ENB INITIATED 1376

In the event of a failure at the eNB, which has resulted in the loss of some or all 1377

transaction reference information, a RESET message shall be sent to the MME. 1378

1379

ENB MME

ENB MME

RESET ACKNOWLEDGE

UE-associated logical S1-connection list (1 to 256)> UE-associated logical S1-connection Item

>> MME UE S1AP ID>> ENB UE S1AP IDCriticality Diagnostics

RESETCauseChoice Reset Type> S1 interface>> reset all> Part of S1 interface>> UE-associated logical S1-connection list (1 to 256)>>> UE-associated logical S1-connection Item>>>> MME UE S1AP ID>>>> ENB UE S1AP ID

1380

Figure 20: Reset procedure eNB initiated 1381

1382

In case of reset of one CEM board, the eNB shall be able to send to MME a partial S1 1383

interface reset with the list of UE associated to this CEM board. 1384

In case multi-MME load balancing is supported, the UE supported by one CEM board may be 1385

associated to different MMEs. eNB shall send Reset messages to all MMEs supporting the UE 1386

associations. 1387

The eNB shall use the MME UE S1AP ID IE and/or the eNB UE S1AP ID to explicitly identify 1388

the UE association(s) to be reset. 1389

It shall handle the RESET ACKNOWLEDGE message received from MME. 1390




4.8. S1 OVERLOAD START (NOT IN LA3.0/TLA3.0) 1391

The purpose of the Overload Start procedure is to inform an eNB to reduce the signaling 1392

load towards the concerned MME. 1393


1395

ENB MME

ENB MME

OVERLOAD START

Overload Response

> Overload Action

1396

Figure 21: Overload Start 1397

1398

Based on Overload Action IE in the OVERLOAD START message, the eNB shall ensure that 1399

only signaling traffic corresponding to permitted RRC connections is sent to the MME and 1400

release non permitted RRC connections (see document [A1] for details). 1401

When receiving an OVERLOAD START message, the eNB shall store the overload action IE in 1402

MME Access List. 1403

If an S1AP OVERLOAD START message is received whereas there is already an ongoing 1404

overload reduction action (S1AP OVERLOAD START message already received), the eNB 1405

shall replace the overload action in MME Access List by the new requested one. 1406

New entering calls, for which no S-TMSI or registeredMME is provided or provided MME 1407

doesn’t match with a known MME, shall not be established towards an overloaded MME. An 1408

overloaded MME shall not be selected by MME selection algorithm (see section 4.15). 1409

1410

Interaction with other procedures: 1411

Handovers are not impacted by Overload procedure: any S1 or X2 Handover related to an 1412

overloaded MME are handled normally. 1413




Mapping performed between overload action and RRCConnection establishment cause 1414

values can be find in document ref [A1]. 1415

1416

1417

4.9. S1 OVERLOAD STOP (NOT IN LA3.0/TLA3.0) 1418

The purpose of the Overload Stop procedure is to signal to an eNB that the overload 1419

situation of a MME has ended and normal operation shall resume. 1420


1422

ENB MME

ENB MME

OVERLOAD STOP

1423

Figure 22: Overload Stop 1424

The eNB receiving the OVERLOAD STOP message shall assume that the overload situation at 1425

the MME from which it receives the message has ended and shall resume normal operation 1426

towards this MME. 1427

When receiving an OVERLOAD STOP message, the overload action shall be reset in MME 1428

access List. 1429

1430

1431

1432

4.10. X2 SETUP 1433

X2 Setup is conditioned to the administrative state of the associated X2Access object , to 1434

the black-listing status of the associated X2Access object, and to the availability of the X2 1435

SCTP association. It is therefore completely independent of both: 1436

- the cell setup procedure, whose status is given by the operationalState and 1437

availabilityStatus of objects LteCell; 1438



<End: SRS-026072-350>




- the S1 interface setup procedure, whose status is given by the operationalState and 1439

availabilityStatus of objects MmeAccess. 1440

In the following sections, the "initiating eNB" refers to the eNB sending the X2 Setup 1441

Request and the "peer eNB" refers to the recipient of the X2 Setup Request. 1442

With the introduction of the Automatic Neighbour Relation function or ANR, in addition to 1443

setting up X2 links for configured neighbour relations, the eNB shall be able to: 1444

- set up an X2 link towards a neighbour eNB that was not previously configured (in this 1445

case it is necessary that ANR be activated on the initiating eNB); 1446

- accept the opening of an X2 link coming from an unknown eNB (in this case it is not 1447

necessary for ANR to be activated on the peer eNB). By unknown eNB what is meant 1448

here is an eNB that was not configured as a neighbour in the eNB's MIM. 1449

1450


ENB ENB2

X2 SCTP Association is set up

ENB ENB2

X2AP X2 SETUP RESPONSE

Global eNB IDServed Cells (1 to 256)

> Served Cell Information> Neighbour Information (0 to 512)

>> ECGI>> PCI

>> EARFCNGU Group ID List (0 to 16)

> GU Group IDCriticality Diagnostics

X2AP X2 SETUP REQUEST

Global eNB IDServed Cells (1 to 256)> Served Cell Information> Neighbour Information (0 to 512)>>ECGI>> PCI>> EARFCNGU GroupID List (0 to 16)> GU Group ID

1452

Figure 23: X2 Setup Success 1453




In the diagram above, only the Information Elements managed in LA3.0 are 1454

represented. 1455

1456

Peer eNB Behaviour 1457

The behaviour of the eNB when the ANR feature is activated is specified in [SRS SON]. The 1458

following applies to an eNB whatever the ANR activation state. 1459

Upon receiving the X2 Setup Request message, the peer eNB checks whether an X2Access 1460

instance exists in the MIM for the eNB that initiated the X2 Setup procedure. If no X2Access 1461

instance exists (or in other words if the neighbour eNB had not been configured) the peer 1462

eNB responds with an X2 Setup Response. 1463

The information received from the initiating eNB (served cell and neighbour information) is 1464

memorized to answer to the requirement of dynamic X2 configuration. The implication is 1465

that the cells served by the initiating eNB will be known to the eNB and outgoing X2 1466

handovers towards those cells will be possible. Incoming handovers from the initiating eNB 1467

will of course also be processed. The management of information exchanged through X2 1468

messages in the context of dynamic X2 configuration is described in [SRS SON]. 1469

1470

If an X2Access instance exists in the MIM for the eNB that initiated the X2 Setup procedure, 1471

the peer eNB checks the received information elements against MIM parameters. 1472

If all the neighbour cells associated in the MIM to the initiating eNB for which the X2 Setup 1473

Request has been received can be matched to a cell in the Served Cells list, the peer eNB 1474

considers the setup to be completely successful and responds with an X2 Setup Response. 1475

Before sending a X2 Setup Response message to a peer eNB, an eNB shall compute the GU 1476

Group ID List based on the GUMMEI information received by MMEs it is connected to (see 1477

section 4.13.3.1) and include it in the X2 Setup Response message. An empty GU Group ID 1478

List shall not prevent the X2 setup procedure from being performed. 1479

If at least one of the neighbour cells associated in the MIM to the initiating eNB for which 1480

the X2 Setup Request has been received cannot be matched to a cell in the Served Cells 1481

list, the peer eNB considers the setup to be partially successful and responds with an X2 1482

Setup Response, while raising an alarm to notify the mismatch in configuration. 1483

If some of the received Served Cells do not match neighbour cells configured in the MIB, 1484

they will be managed as dynamic neighbour relations (please see details in [SRS SON]). If 1485

ANR is not activated, MIM will not be updated with received configuration. However, the 1486

ENB will provide all its neighbours with received information with an ENB Configuration 1487

Update message, as the configuration received from neighbours is considered as more 1488

accurate than MIM configuration,. 1489

In addition, the content of “Served Cells” and “Neighbour Information” IEs is used to 1490

detect PCI allocation conflicts as specified in [SRS SON]. 1491

1492

Initiating eNB behaviour 1493

The behaviour of the eNB when the ANR feature is activated is specified in [SRS SON]. The 1494

following applies to an eNB whatever the ANR activation state . 1495

Before sending a X2 Setup Request message to a peer eNB, an eNB shall compute the GU 1496

Group ID List based on the GUMMEI information received by MMEs it is connected to (see 1497

section 4.13.3.1) and include it in the X2 Setup Request message. An empty GU Group ID 1498

List shall not prevent the X2 setup procedure from being performed. 1499

Upon receiving the X2 Setup Response message, the initiating eNB checks the received 1500

information elements against MIM parameters. 1501


Feature Number: L108172 Author: Frédéric Deville

<End: SRS-026072-100>



<End: SRS-026072-110>



<End: SRS-026072-120>



<End: SRS-026072-170>



<End: SRS-026072-370>




If all the neighbour cells associated in the MIM to the peer eNB for which the X2 Setup 1502

Response has been received can be matched to a cell in the Served Cells list, the X2 Setup 1503

procedure is considered completely successful. 1504

If at least one of the neighbour cells associated in the MIM to the peer eNB for which the 1505

X2 Setup Response has been received cannot be matched to a cell in the Served Cells list, 1506

the X2 Setup procedure is considered partially successful, and an event is raised to notify 1507

the mismatch in configuration. 1508

If some of the received Served Cells do not match neighbour cells configured in the MIB, 1509

they will be managed as dynamic neighbour relations (please see details in [SRS SON]). 1510

In addition, the content of “Served Cells” and “Neighbour Information” IEs is used to 1511

detect PCI allocation conflicts as specified in [SRS SON]. 1512

1513


4.10.2.1 X2 SETUP FAILURE 1515

Peer eNB behavior 1516

There are two use cases for rejecting an X2 Setup procedure in the Alcatel-Lucent 1517

implementation of the eNB. When the X2 link is locked (through the administrative state of 1518

the associated X2Access instance), the eNB will allow the SCTP association to be set up 1519

and reject the X2 Setup procedure by sending an X2 Setup Failure message. Similarly, 1520

when an X2 link has been black-listed (through the noX2 attribute of the associated 1521

X2Access instance), incoming SCTP INIT messages will be accepted by the eNB, but the X2 1522

Setup procedure will be rejected by sending an X2 Setup Failure message. In both cases, 1523

the X2 Setup Failure will contain a Time To Wait IE set to the maximum value (v60s) and 1524

the Cause IE will be set to "om-intervention". 1525

1526

If the peer eNB is in a state to do so, it may initiate an X2 Setup procedure of its own and 1527

become the initiating eNB. 1528

Initiating eNB behavior 1529

Upon reception of the X2 Setup Failure, the initiating eNB shall set a timer to a random 1530

value at least equal to either the Time To Wait information element if is was received, or 1531

to a random X2TimeToWait value chosen among the range of values allowed by the 1532

standard. The standard allows following values "v1s, v2s, v5s, v10s, v20s, v60s ", a random 1533

value may be chosen in any range between two values, e.g. range [1..2] for value v1s, 1534

range [60..80] for value v60s) . 1535

Once this timer expires, the initiating eNB may trigger a new X2 Setup procedure by send 1536

the X2 Setup Request message. While the timer runs, the eNB may respond to an incoming 1537

X2 Setup Request from the peer eNB, in which case it stops the time. 1538

If the X2 Setup procedure fails three times consecutively, the eNB will raise an alarm to 1539

notify the issue to the operator. The operational state of the associated X2Access instance 1540

will be set to Disabled, and its availability status to Failed. The SCTP association will 1541

remain in set up state. 1542

1543



<End: SRS-026072-380>



<End: SRS-026072-180>




ENB ENB2


ENB2 rejects the setup procedure by sendingX2 SETUP FAILURE

ENB ENB2

X2 SETUP FAILURECause (M)

TimeToWait (O)CriticalityDiagnostics(O)


set x2SetupTimer

set timer T

set x2SetupTimer

if TimeToWait (O) wasn’t present, set timer T with a duration randomly chosen

among possible values

if TimeToWait (O) has been received, set timer T with

duration TimeToWait

ENB resends X2 SETUP REQUEST to ENB2 at most two times (for a total of three attempts),

considers the setup failed after three consecutive failuresand raises an alarm to XMS


stop x2SetupTimer

timer T expires

1544

Figure 24: X2 Setup Failure 1545

1546

4.10.2.2 NO RESPONSE TO X2 SETUP REQUEST 1547


If the initiating eNB does not receive either X2 SETUP RESPONSE message or X2 SETUP 1549

FAILURE message, the eNB may reinitiate the X2 Setup procedure towards the same eNB, 1550

provided that the content of the new X2 SETUP REQUEST message is identical to the 1551

content of the previously unacknowledged X2 SETUP REQUEST message. 1552

When the eNB sends an X2 Setup Request message, it sets an internal timer that is stopped 1553

if either X2 Setup Response or X2 Setup Failure messages are received. If this timer 1554

expires, the initiating eNB may trigger a new X2 Setup procedure by sending the X2 Setup 1555

Request message. While the timer is running, the eNB may respond to an incoming X2 1556

Setup Request from the peer eNB, in which case it stops the timer. 1557

If the X2 Setup procedure fails three times consecutively, the eNB will raise an alarm to 1558

notify the issue to the operator. The operational state of the associated X2Access instance 1559

will be set to Disabled, and its availability status to Failed. The SCTP association will 1560

remain in set up state. 1561




ENB ENB2

ENB ENB2



set x2SetupTimer

set x2SetupTimer


x2SetupTimer expires

ENB resends X2 SETUP REQUEST to ENB2at most two times (for a total of three attempts),

considers the setup failed after three consecutive failuresand raises an alarm to XMS

1562

Figure 25: No Response To X2 Setup 1563

1564

4.10.2.3 X2 LINK FAILURE 1565

X2 Link failures are detected at SCTP level as described in [A8] and reported via a state 1566

change notification: the underlying X2TransportLayerAccess object becomes 1567

Disabled/Failed. The X2Access object state becomes Disabled/Dependency and remains so 1568

while the SCTP association is down. 1569

When the SCTP association is reestablished, the eNB will trigger a new X2 Setup procedure 1570

as specified in section 4.10.1. 1571

1572

4.10.2.4 X2 SETUP CROSSOVER 1573

Two eNBs may initiate an X2 Setup procedure at the same time, causing an X2 Setup 1574

crossover. 1575

In LA3.0, the stream identifier used for non-UE associated signaling is hard coded to value 1576

"0". The stream identifier used by the peer eNB will be dynamically discovered on 1577

reception of first message, which shall be a non-UE associated signaling X2 SETUP 1578

message. 1579

Upon receiving a crossover X2 Setup Request, the eNB shall answer as specified in section 1580

4.10.1, but shall not cancel its ongoing X2 setup procedure. In other words, it will not 1581

consider the X2 interface to be operational and will continue to wait for an answer to the 1582

X2 Setup Request it initiated. The peer eNB will behave in a similar fashion, so the eNB 1583

will end up receiving an answer, whether successful or not, to the request it sent. 1584

This behavior is consistent with latest updates brought in TS 36.423, and especially 1585

through CR R3-091410. 1586

1587




4.10.3 MULTIPLE X2 LINKS 1588

An eNB may be connected to up to 32 other eNBs. The X2 Setup procedures will be 1589

triggered as soon as the SCTP association for each eNB is available, and may therefore 1590

happen in parallel. They may also run in parallel to S1 Setup procedures. 1591

1592


When a target cell has been identified for an inter-eNB handover and the X2 link to the 1594

eNB supporting that cell is not operational (managed object X2Access is in a state different 1595

from Enabled/None), the handover may be attempted over the S1 interface if S1 handover 1596

is allowed; otherwise it is abandoned (for details see [A2]). 1597

1598




1599

4.10.5 X2 LOCK/UNLOCK 1600

An X2 link can be locked or unlocked through administrativeState attribute attached to 1601

X2Access object instance. 1602

An unlocked X2 link will be established and allowed to operate (except if black-listed or 1603

released by ANR garbage collection mechanism, refer to following chapters for details). 1604

A locked X2 link will not be established. 1605

Note: “shuttingdown” value is not currently supported. 1606

1607

Following chapters specify eNB behavior on transitions from “unlock to lock” and “lock to 1608

unlock”. 1609

1610

4.10.5.1 BEHAVIOR WHEN LOCKING AN X2 LINK 1611

Locking an X2 link is performed by setting X2Access administrativeState to “locked”. 1612

In this case, if the X2 link was established, it has to be released. Underlying SCTP 1613

association does not need to be released itself, however, as the only way to release X2 link 1614

is to release also SCTP, when X2 lock command is received, the eNB will shutdown 1615

underlying SCTP association. 1616

As long as X2 link is locked, X2 link will not be established (meaning X2 setup will not be 1617

triggered and rejected if received from the peer eNB. 1618

Underlying SCTP may be resumed following SCTP INIT received from the peer eNB. 1619

1620

4.10.5.2 BEHAVIOR WHEN UNLOCKING AN X2 LINK 1621

Unlocking an X2 link is performed by setting X2Access administrativeState to “unlocked”. 1622

In this case, given that the link is not black-listed, it shall be established through X2 setup 1623

procedure. Of course, underlying SCTP association shall be established beforehand if not 1624

already up. 1625

1626

4.10.6 X2 BLACK-LISTING 1627

ANR function introduced the notion of X2 link “black-list”, meaning that the operator has 1628

the possibility to declare that an X2 link shall never be established by the eNB, whatever 1629

the condition. For further details, please refer to[A14]. 1630

In case an X2 link is black-listed, it shall then not be established and in case it was, it shall 1631

be released whatever its administrative state. 1632

This means black-listing will always take precedence over administrative state. 1633

1634

4.10.7 X2 WHITE-LISTING 1635

ANR also introduced the notion of X2 link “white-list”, meaning that the operator has the 1636

possibility to declare that an X2 link shall always be established. For further details, please 1637

refer to[A14]. 1638


Feature Number: L113614 (TLA3.0) / L108282 (LA3.0)

Author: Yunhua Wang <End: SRS-026072-280>




In case an X2 link is white-listed, it shall then be established, except if locked. 1639

This means it will always be possible to lock an X2 link, even if withe-listed. This is 1640

mandatory because locking an X2 link may be needed for maintenance purpose. 1641

1642

4.10.8 X2 ONLINE CREATION 1643

It is now possible to create online an X2Access instance along with its underlying 1644

X2TransportLayerAccess instance (X2TransportLayerAccess cardinality ensures that if an 1645

X2Access instance is created, then associated X2TransportLayerAccess instance will also 1646

be). 1647

eNB behavior on X2Access instance creation will be: 1648

- If X2 link is black-listed, it will not be established 1649

- If X2 link is not black-listed, it will be established only if unlocked 1650

1651

4.10.9 X2 ONLINE DELETION 1652

It is also possible to delete online an X2Access instance along with its underlying 1653

X2TransportLayerAccess instance. 1654

eNB behavior in case of X2 link deletion will be 1655

- If X2 link was established, it will be released through SCTP shutdown 1656

- If it was not, it will be simply removed from the MIB 1657

1658




4.11. X2 ENB CONFIGURATION UPDATE 1659

The purpose of the eNB Configuration Update procedure is to update application level 1660

configuration data needed for two eNBs to interoperate correctly over the X2 interface. 1661

The procedure uses non UE-associated signaling. 1662

1663


ENB1 ENB2

ENB1 ENB2

ENB CONFIGURATION UPDATE ACKNOWLEDGE



Served Cells To Add (1 to 256)> Served Cell Information> Neighbour Information>> ECGI>> PCI>> EARFCNServed Cells To Modify (1 to 256)> Old ECGI> Served Cell Information> Neighbour Information (0 to 512)>> ECGI>> PCI>> EARFCNServed Cells To Delete (1 to 256)> Old ECGIGU Group Id To Add List (1 to 16)GU Group Id To Delete List (1 to 16)

1665

Figure 26: X2 eNB Configuration Success 1666

1667


The reception of new GUMMEI information from an MME instance in an S1 Setup Response 1669

or a S1 MME Configuration Update message may cause the GU Group Id List to change. If it 1670

does change, the eNB is expected to provide the new list to neighboring eNBs using the X2 1671

eNB CONFIGURATION UPDATE procedure towards all its X2 neighbors. 1672

The X2 eNB CONFIGURATION UPDATE procedure requires the eNB to provide a delta of the 1673

GU Group ID List, i.e. the eNB needs to provide the new GU Group IDs, as well as the GU 1674

Group Ids that need to be deleted. These items will be the same across all X2 instances. 1675

The eNB Configuration Update procedure may also be triggered by the ANR function, as 1676

specified in [A14]. 1677

The dynamic update of LteCell->TrackingAreaCode (Class C parameter) shall trigger a eNB 1678

Configuration procedure including corresponding Served Cells To Modify. 1679

1680



<End: SRS-026072-320>





Upon reception of the GU Group Id List in the X2 eNB CONFIGURATION UPDATE message, 1682

the eNB2 shall update the previous list and store the new information so that it can be used 1683

for mobility decisions. 1684

1685


4.11.2.1 X2 ENB CONFIGURATION UPDATE FAILURE 1687

If the eNB2 can not accept the update it shall respond with an eNB CONFIGURATION 1688

UPDATE FAILURE message and appropriate cause value. 1689

If the eNB CONFIGURATION UPDATE FAILURE message includes the Time To Wait IE the eNB 1690

shall wait at least for the indicated time before reinitiating the eNB Configuration Update 1691

procedure towards the same eNB2. Both nodes shall continue to operate the X2 with the 1692

existing configuration data. 1693

1694


The peer eNB may decide to reject an incoming X2 Configuration Update in case X2 1696

connection is in state OAM Locked or is defined with attribute “noX2”. In this case it sends 1697

an X2 eNB CONFIGURATION UPDATE FAILURE, including the Time To Wait information 1698

element set to X2TimeToWait hard coded value (e.g. v60s, maximum value allowed by the 1699

standard). 1700

In case ANR feature is deactivated, the eNB will check the neighbor cells found in the MIM 1701

with the Served Cells indicated in the eNB CONFIGURATION UPDATE and raise an alarm in 1702

case no match is found as in this case, X2 configuration prevails. However, eNB will 1703

complete normally the procedure with an eNB CONFIGURATION UPDATE ACKNOWLEDGE 1704

message 1705


Upon reception of the X2 eNB Configuration Update Failure, the initiating eNB shall set a 1707

timer to a random value at least equal to either the Time To Wait information element if 1708

is was received, or to a random X2TimeToWait value chosen among the range of values 1709

allowed by the standard. The standard allows following values “v1s, v2s, v5s, v10s, v20s, 1710

v60s", a random value may be chosen in any range between two values, e.g. range [1..2] 1711

for value v1s, range [60..80] for value v60s) . 1712

Once this timer expires, the initiating eNB may trigger a new X2 eNB Configuration Update 1713

procedure by sending the X2 eNB CONFIGURATION UPDATE message. 1714

The eNB will retry the X2 eNB Configuration Update procedure 1715

X2ConfigurationUpdateRetry times (hard coded value set to 3). In case there is no 1716

successful answer after the retries, the eNB will shut down X2 connection and restart the 1717

X2 Setup procedure. It will raise an event 1718

“ENB_CANDIDATE_X2_ENB_CONFIGURATION_UPDATE_FAILURE“ to notify the issue to the 1719

operator. 1720

1721



<End: SRS-026072-200>



<End: SRS-026072-210>




ENB1 ENB2

ENB1 ENB2

ENB CONFIGURATION UPDATE FAILURECause

Time To WaitCriticality Diagnostics


Served Cells To Add (1 to 256)> Served Cell Information> Neighbour Information>> ECGI>> PCI>> EARFCNServed Cells To Modify (1 to 256)> Old ECGI> Served Cell Information> Neighbour Information (0 to 512)>> ECGI>> PCI>> EARFCNServed Cells To Delete (1 to 256)> Old ECGIGU Group Id To Add List (1 to 16)GU Group Id To Delete List (1 to 16)

1722

Figure 27: X2 eNB Configuration Update Failure 1723

1724




4.11.2.2 NO RESPONSE TO X2 ENB CONFIGURATION UPDATE 1725

If the eNB after initiating eNB Configuration Update procedure receives neither eNB 1726

CONFIGURATION UPDATE ACKNOWLEDGE message nor eNB CONFIGURATION UPDATE 1727

FAILURE message, the eNB may reinitiate the eNB Configuration Update procedure towards 1728

the same eNB2, provided that the content of the new eNB CONFIGURATION UPDATE 1729

message is identical to the content of the previously unacknowledged eNB CONFIGURATION 1730

UPDATE message. 1731

When the eNB sends an eNB Configuration Update message, it sets an internal timer that is 1732

stopped if either eNB Configuration Update Acknowledge or eNB Configuration Update 1733

Failure messages are received. If this timer expires, the initiating eNB may trigger a new 1734

X2 eNB Configuration Update procedure by sending the X2 eNB CONFIGURATION UPDATE 1735

message. 1736

The eNB will retry the X2 eNB Configuration Update procedure 1737

X2ConfigurationUpdateRetry times (hard coded value set to 3). In case there is no 1738

successful answer after the retries, the eNB will shut down X2 connection and restart the 1739

X2 Setup procedure. It will raise an event 1740

“ENB_CANDIDATE_X2_ENB_CONFIGURATION_UPDATE_NO_RESPONSE” to notify the issue to the 1741

operator. 1742

1743

ENB1 ENB2

ENB1 ENB2


ENB CONFIGURATION UPDATEset

x2ENBConfiguration UpdateTimer

set x2ENBConfiguration

Update Timer

x2ENBConfiguration UpdateTimer expires

ENB resends ENB CONFIGURATION UPDATE to ENB2(3 retries maximum)

1744

Figure 28: No Response To X2 eNB Configuration Update 1745

1746

1747



<End: SRS-026072-400>




1748

4.12. X2 RESET PROCEDURE 1749

The purpose of the Reset procedure is to align the resources between two eNBs in case of 1750

abnormal failure. This procedure resets the X2 interface, but doesn’t affect the 1751

application level configuration data exchanged during the X2 Setup procedure. 1752


1754

Source ENB Target ENB

ENB MME

RESET RESPONSE


RESET REQUEST

Cause

1755

1756

4.12.1 X2 RESET EMISSION 1757

On the contrary of S1 Reset, X2 Reset doesn’t offer the possibility of a partial Reset of X2 1758

interface. 1759

An X2 RESET REQUEST may be generated by eNB in following cases to improve defense 1760

mechanism: 1761

- eNB restart following a critically anomaly detection : during the eNB shutdown 1762

preparation, a X2 reset shall be sent on X2 interfaces to allow peer eNB to release related 1763

X2 contexts. When a critical anomaly is detected in another application than CallP, before 1764

restarting the eNB, the platform shall ask Callp to send X2 reset on all X2 interfaces. 1765

1766

- eNB software upgrade: an X2 reset shall be sent on X2 interfaces during software upgrade 1767

preparation phase, the platform shall ask Callp to send a X2 reset on all X2 interfaces. 1768




ENB doesn’t need to wait for RESET RESPONSE to continue on-going procedures 1769

In LA3.0, platform services are not planned to be implemented, so no X2 RESET 1770

REQUEST will be generated by eNB CallP software. A debug command may be 1771

implemented in CallP to generate a X2 Reset cause Miscellaneous / O&M intervention 1772

for tests purposes. 1773

1774

4.12.2 X2 RESET RECEPTION 1775

On reception of an X2 RESET REQUEST from a source eNB, X2 configuration data is kept, 1776

only X2 UE contexts shall be released. 1777

After completion of release of the resources, the target eNB shall answer with a RESET 1778

RESPONSE message. 1779

As per [R7] TS 36.423, if the RESET REQUEST message is received, any other ongoing 1780

procedure (except another Reset procedure) on the same X2 interface shall be aborted. 1781

As configuration data are not affected by the RESET procedure, there is no need to abort 1782

ENB Configuration Update procedure, it may be processed normally. Aborting the ENB 1783

Configuration Update procedure has no added value, as the initiating eNB then needs to 1784

repeat it just after to send again the updated configuration to the peer node, If the peer 1785

node doesn’t answer to ENB Configuration Update procedure, due to RESET procedure, the 1786

defense timer allows the initiating eNB to resend the ENB Configuration Update message. 1787

Interaction with X2 Handover procedure is described in document [A2]. 1788

1789




4.13. SUPPORT OF MME GROUP 1790

4.13.1 INTRODUCTION / OVERVIEW 1791

As described in [R8] TS 23.401 MMEs can be pooled together in order to allow for better 1792

balance of load between them. When a UE is served by an MME, this serving MME does not 1793

have to change as long as the UE remains in the same MME pool area. This implies that all 1794

the eNBs within this MME pool area are connected to all the MMEs in the pool through an 1795

S1 interface. The concept of MME pooling is depicted in the figure below. 1796

1797

1798

1799

In order to take advantage of MME pooling, the eNB needs to support S1-Flex, i.e. the 1800

ability to connect to multiple MME instances over S1, along with an MME selection scheme 1801

based on MME relative capacity. This MME selection scheme is enhanced with the support 1802

of MME pooling on the eNB side. 1803

1804

Support of MME group introduces the following functionalities in the eNB: 1805

- Support for the GU Group ID List over X2: the eNB will provide this list to 1806

neighboring eNBs based on information provided by the MME instances it is 1807

connected to, as well as store the list provided by neighboring eNBs; 1808

- Target cell selection upon handover: based on the GU Group ID List provided by its 1809

X2 neighbors, the eNB will prevent triggering an X2 handover to a cell in an eNB not 1810

connected to the MME currently serving the UE. Instead, the eNB will trigger the S1 1811

handover; 1812

1813

MME MME …

MME-1

MME-j

…

eNB

eNB

eNB

eNB

eNB

eNB

eNB

eNB

eNB

eNB

eNB

eNB

……

TA1

Border

Pool A Pool B

TA2 TA3 TA4 TA5 TA6

Ba Bb




4.13.2 ASSUMPTIONS 1814

The following system assumptions are made: 1815

• MME Code is assumed to be unique within a pool, or within area of overlapping pools 1816

(see TS23.003 clause 2.8.1); 1817

• When an eNB is connected to an MME pool, it has to be connected to all MMEs in that 1818

pool (see TS36.401 clause 6.1); 1819

• As per [R8] TS 23.401, MME relocation cannot be achieved by an X2 handover. This 1820

implies that two eNBs need to be connected to the MME pool (group) of the MME 1821

handling the call for X2 mobility to work between them; 1822

• An MME can only belong to one MME LTE pool/group; 1823

• The list of MME Groups provided by the MME includes pool information for 2G/3G. Only 1824

the LTE pooling information should be provided to neighboring eNBs over X2; 1825

• The X2 interface setup can be initiated before the S1 Setup. 1826

1827

4.13.3 SUPPORT FOR GU GROUP ID LIST OVER X2 1828

The GU Group ID List provides the MME Pools (also called MME Groups) that an eNB is 1829

connected to through the S1 interface. The eNB needs to manage the GU Group ID List 1830

over X2: 1831

1. Provide its neighboring eNBs with the MME groups (i.e. pools) it is connected to 1832

through the X2-AP SETUP REQUEST or X2-AP SETUP RESPONSE message. Since the 1833

eNB obtains this information from the MME upon S1-AP SETUP RESPONSE or upon 1834

S1-AP MME CONFIGURATION UPDATE, it may not have the GU Group ID list upon X2 1835

Setup (i.e. if S1 Setup is not completed); 1836

2. Update its neighboring eNBs with the MME groups (i.e. pools) it is connected to, 1837

when those change (e.g. following an S1-AP SETUP RESPONSE or S1-AP MME 1838

CONFIGURATION UPDATE), using the X2-AP ENB CONFIGURATION UPDATE 1839

procedure; 1840

3. Store the MME groups a neighboring eNB is connected to, as provided in the X2-AP 1841

SETUP REQUEST, X2-AP SETUP RESPONSE or X2-AP ENB CONFIGURATION UPDATE 1842

message. This information will then be used for handover decisions. 1843

Note: GU Group ID = PLMN ID + MME Group ID. 1844

1845

4.13.3.1 COMPUTING GU GROUP ID LIST AND PROVIDING IT TO X2 NEIGHBORS 1846

The GU Group ID List is a list made of combinations of PLMN ID and MME Group ID (please 1847

refer to [I4] for details on each), which essentially corresponds to the list of MME 1848

pools/groups an eNB is connected to. The GU Group ID List needs to be computed based on 1849

the GUMMEI List provided by the various MME instances the eNB is connected to. 1850

1851

The eNB shall compute the GU Group Id List based on the GUMMEI information received by 1852

MMEs it is connected to. 1853

1854

The GUMMEI IE provided by the MME will provide the following information, as per [R6] 1855

TS36.413: 1856

o Served PLMN IDs 1857

o Served MME Group IDs 1858




o Served MME codes 1859

1860

The served MME Group ID information is provided by RAT to the eNB, and the LTE pooling 1861

information is provided first. Only the LTE-specific pooling information needs to be 1862

provided to X2 neighbors, since 2G/3G pooling information will not be useful (clarified in 1863

CR R3-091343 to TS36.413 June 2009). 1864

1865

When computing the GU Group ID List, the eNB needs to combine PLMN ID information 1866

with MME Group ID information, i.e. all combinations of PLMN ID and MME Group ID for a 1867

single MME instance shall be indicated to X2 neighbors. PLMN ID and MME Group ID 1868

combinations across different MME instances should not be included. 1869

Combinations of PLMN ID and MME Group ID received from 2 different MME could result in 1870

duplicated value. In this case, the resulting combination will be provided only once to X2 1871

neighbors. 1872

1873

When building the GU Group Id List, some S1 interfaces may be in a disabled state, e.g. 1874

because the SCTP connection is down. The eNB should not look at the operational state of 1875

the S1 interface when building the GU Group Id List and providing it to neighbors, i.e. all 1876

MME instances should be considered. In case an eNB triggers a handover request towards 1877

an eNB for which the identified MME is not accessible, the eNB will reject the handover 1878

request. 1879

1880

1881

Various triggers will require the eNB to compute the GU Group ID List: 1882

o When an X2 SETUP REQUEST is initiated by the eNB 1883

o When an X2 SETUP REQUEST is received by the eNB and the X2 SETUP RESPONSE 1884

needs to be sent 1885

o When the eNB receives an S1 SETUP RESPONSE message from an MME instance; 1886

only if there is at least one X2 instance setup already 1887

o When the eNB receives an S1 MME CONFIGURATION UPDATE with GUMMEI 1888

information; only if there is at least one X2 instance setup already 1889

1890

One should note that the X2 Setup procedure may be performed before the eNB has any S1 1891

connection setup. This will result in the GU Group ID List being empty. 1892

1893

1894

The reception of new GUMMEI information from an MME instance in a S1 Setup Response or 1895

S1 MME Configuration Update message may cause the GU Group Id List to change. If it does 1896

change, the eNB is expected to provide the new list to neighboring eNBs using the X2 ENB 1897

CONFIGURATION UPDATE procedure. If the eNB currently has no X2 connection, then there 1898

is no need to compute the GU Group Id List. 1899

To know if the GU Group Id list has changed, the eNB needs to compare the old list with 1900

the new list, using the new GUMMEI information provided by the MME. If the list does not 1901

change, then there is no need to update neighboring eNBs. 1902

1903

The X2 ENB CONFIGURATION UPDATE procedure requires the eNB to provide a delta of the 1904

GU Group ID List, i.e. the eNB needs to provide the new GU Group IDs, as well as the GU 1905

Group Ids that need to be deleted. These items will be the same across all X2 instances. 1906

1907




4.13.3.2 STORING GU GROUP ID INFORMATION PROVIDED BY X2 NEIGHBORS 1908

Upon reception of the GU Group ID List from a neighboring eNB, the eNB will know to 1909

which MME pools this eNB is connected through the S1 interface. The eNB will use this 1910

information for handover decisions (see [A2]). This means that every time the eNB receives 1911

this information (new or updated) from a neighboring eNB, it needs to store it in a context 1912

specific to this eNB neighbor. 1913

The following X2-AP messages can contain the GU Group Id List: X2 SETUP REQUEST, X2 1914

SETUP RESPONSE and X2 ENB CONFIGURATION UPDATE. Since the GU Group Id List IE is 1915

optional in the X2 ASN.1, it may not necessarily be provided by the peer eNB. This should 1916

not stop the procedure from being completed successfully. 1917

1918

4.14. MME PRIORITY (NOT IN LA3.0/TLA3.0) 1919

A notion of MME priority is defined at eNB level. A priority is assigned to each MME by 1920

configuration: a MME can be defined as “primary” or “secondary”. 1921

� eNB MME Selection shall be applied across Primary MMEs while secondary MMEs shall be 1922

declared a MME for backup in case of overload or access problem. 1923

� eNB selects the primary MME(s) first, until all the primary MMEs are not reachable or 1924

overloaded. 1925

� Secondary MME(s) are selected only under abnormal conditions – All primary MME(s) 1926

are not available or in overload condition. 1927

1928

A new attribute is added to MMEAccess object: MMEAccess->priority. Default value of this 1929

attribute is primary. Some operators may not use this priority notion and configure only 1930

primary MMEs. 1931

1932

S1 link and S1 setup are established towards all MMEs, independently of their priority. 1933

1934

Once a secondary MME has been selected for one UE, this UE will always provide this 1935

selected MME for new RRC Connections. To allow the UE to come back to primary MMEs 1936

when normal conditions are filled again (primary MME(s) available again, i.e. in 1937

Enable/none state, not overloaded and with a relativeMMECapacity not set to 0), the eNB 1938

will have following handling: in case of reception of a S1 UE CONTEXT RELEASE from a 1939

secondary MME, and primary MME(s) are available again, the eNB shall set the release 1940

cause to “loadBalancingTAUrequired” in RRCConnectionRelease. This will make the UE 1941

initiate a TAU without providing S-TMSI or registeredMME in RRCConnectionRequest and 1942

will allow eNB to select a primary MME to serve this UE (see document [A1] for details on 1943

S1 UE Context Release procedure). 1944

As this reselection of a primary MME is done on UE context release, it will not cause any 1945

delay for UE connection and any impact on UE service. In addition, this will allow the UEs 1946

to go back gradually to primary MME(s) with the load balancing algorithm and avoid 1947

primary MMEs becoming overloaded again. 1948

1949




4.15. MME SELECTION ALGORITHM 1950

In the case where several S1 links to MMEs are configured, the ENB is expected to dispatch 1951

UEs to the specific MMEs to which they are registered, or to select an MME to which they 1952

will register when they haven't previously done so. 1953

1954

A UE which has previously registered with a given MME will provide the identity of the MME 1955

by including either optional information element S-TMSI containing MME Code in RRC 1956

Connection Request message (when the UE is registered in the Tracking Area of the cell it 1957

is attempting to access) or optional information element registeredMME (GUMMEI that 1958

consists of the PLMN ID, the MME Group ID and the MME Code) in the RRC Connection Setup 1959

Complete message. 1960

In this case, the ENB will attempt to match the provided MME with an MME identity in the 1961

list of GUMMEIs received during S1 Setup procedure (see section 4.4) or MME Configuration 1962

Update procedure (see section 4.5). If no match is found, the ENB will initiate MME 1963

selection as described hereafter. 1964

If a match is found and matched MME is not overloaded (not in LA3.0/TLA3.0) or the RRC 1965

establishment cause can be accepted due to overload action (not in LA3.0/TLA3.0), eNB 1966

will direct the call establishment to the matched MME. If the S1 link of the matched MME is 1967

down (as indicated by a state different than Enabled/None for the MmeAccess object of 1968

the matched MME), a new MME is selected within available MMEs. 1969

1970

Following section is not supported in LA3.0/TLA3.0: 1971

If a match is found and matched MME is overloaded and the RRC establishment cause can’t 1972

be accepted due to overload action, the call will be either rejected with a timeToWait set 1973

to ueTimers->tOverload value in case MME has been provided with S-TMSI of RRC 1974

Connection Request or released with cause “other” in case MME has been provided in 1975

registeredMME of RRC Connection Setup Complete (see document [A1] for details). 1976

TS 23.401 ref [R8] section 4.3.7.3 recommends not to send any additional load to other 1977

MME in case of overload situation, that is why the calls are rejected or released and not 1978

send to another MME. Choosing another MME or using the cause loadBalancingTAUrequired 1979

in the RRC Connection Release will move the UE to another MME. When MMEs are in 1980

overload, they select randomly some eNB to reduce their load. If loadbalancing has been 1981

performed correctly, all the MME should be near the overload state. 1982

However, a non-standard specific overload handling can be activated to decrease call 1983

drops. This shall be limited to special network topologies, e.g. configurations with primary 1984

and secondary MMEs, 1985

In case parameter “ActivationService->overloadCallRejectNotAllowed” is set to true, the 1986

RRC Connection is established in a first step, followed by a RRC Connection release cause 1987

“loadbalancingTAUrequired”. This will allow the UE to establish a new RRC connection 1988

with a TAU, without providing S-TMSI or registeredMME, in which case a new MME is 1989

selected by the eNB. 1990

1991

Note: An MME with relativeMMEcapacity set 0 can’t be selected to establish new calls but 1992

shall be selected for previously registered UEs, providing either S-TMSI or registeredMME in 1993

RRC Connection procedure. 1994

1995

In case no match is found or the S1 link of matched MME is down, an MME selection is 1996

performed within a list of eligible MMEs. 1997

1998




The ENB maintains a list of the GUMMEI (Globally Unique Mobility Management Identity) 1999

received during the S1 Setup or MME Configuration Update procedures. This list is used for 2000

MME matching described above. 2001

In addition, it also maintains a list of MME Access, with associated to each MME: 2002

- MME Access OperState 2003

- priority (primary or secondary) defined by configuration (not in LA3.0/TLA3.0), 2004

- overload action (see 4.8) (not in LA3.0/TLA3.0), 2005

- relativeMMECapacity also received during the S1 Setup or MME Configuration Update 2006

procedures, 2007

2008

When the ENB must perform MME selection for a given UE, it establishes the list of eligible 2009

MMEs. A MME is eligible if: 2010

- MmeAccess managed object is in the state Enabled/None : S1 link is operational (an 2011

S1 link is considered operational when an S1 Setup procedure has been successfully 2012

completed) 2013

- it is not overloaded (no overload action set) (not in LA3.0/TLA3.0) 2014

- relativeMMECapcity is not set to 0 2015

2016

Following section is not supported in LA3.0/TLA3.0: 2017

As long as one primary MME is eligible, the eNB shall perform the MME selection within the 2018

primary MME(s) with a load-balancing algorithm based on Relative MME capacity. In this 2019

case, the list of eligible MMEs shall contain the eligible primary MMEs. 2020

When no primary MME is eligible, the eNB shall perform the MME selection within the 2021

secondary MME(s) if any with the same load-balancing algorithm based on Relative MME 2022

capacity. In this case, the list of eligible MMEs shall contain the eligible secondary MMEs. 2023

In case no MME, either primary or secondary, is eligible, the call shall be released. 2024

However, an overloaded MME with MME Access OperState can be selected if the RRC 2025

establishment cause matches with overload action in following cases: 2026

- when a UE doesn’t provide S-TMSI or registeredMME, . 2027

- the provided MME is not in OperState. 2028

2029

To perform MME selection, the ENB first computes the totalMmeCapacity by summing the 2030

relativeMmeCapacity of all the eligible MMEs (primary MMEs or secondary MMEs (not in 2031

LA3.0/TLA3.0)). The relative MME capacity is typically set according to the capacity of an 2032

MME node relative to other MME nodes ([R8] TS 23.401). This relative capacity is coded as 2033

an integer in the 0 to 255 range and not as a percentage, in order to avoid having to 2034

update all the relative capacities when a new MME is introduced into the network. 2035

It then randomly draws a number between 1 and totalMmeCapacity. Each MME has a 2036

selection range, which starts at one plus the sum of the relativeMMECapacity of all the 2037

MMEs preceding it in the list of eligible MMEs, and ends at the sum of relativeMMECapacity 2038

of all the MMEs preceding it in the list and of its own relativeMmeCapacity. In this manner, 2039

the randomly drawn number falls within a unique MME selection range, and the ENB has 2040

then performed its MME selection. It then pursues normal call establishment towards the 2041

selected MME. 2042

2043

The list of eligible MMEs shall be computed each time MME Access list is updated: 2044

- change of MME Access state (S1 setup, SCTP lost, SCTP recovery) 2045




- change of relative MME capacity (S1 setup, MME configuration update), 2046

- change of MME overload state (overload start, overload stop). (not in LA3.0/TLA3.0) 2047

- OAM update of MMEAccess->Priority (not in LA3.0/TLA3.0) 2048

2049

2050



<End: SRS-026072-70>




4.16. S1AP ERROR HANDLING 2051

Some error handling has to be performed at S1AP level to allow readiness for IOT. 2052

2053

4.16.1 ERROR HANDLING AT PROCEDURE LEVEL 2054

When the eNB receives a S1AP message for a non-supported procedure with a reject 2055

criticality, it shall answer with an ERROR INDICATION message. 2056

This message will contain the following information: 2057

- IE cause set to value “Abstract Syntax Error (reject)” 2058

- IE Criticality Diagnostics will contain the received procedure code, triggering 2059

message and procedure criticality. 2060

If the received non-supported procedure has criticality “ignore”, the eNB shall log and 2061

ignore received message. 2062

2063

4.16.2 ERROR HANDLING AT IE LEVEL 2064

At IE level, “presence” and “criticality” allow to define behaviours for error handling. 2065

To each IE is assigned a presence information. It can take the following values: 2066

• M : IEs marked as mandatory shall always be included in the message 2067

• O : IEs marked as Optional may or may not be included in the message 2068

• C : IEs marked as Conditional shall be included in a message only if the condition is 2069

satisfied. Otherwise the IE shall not be included. 2070

2071

Each IE or group of IE may have criticality information applied to it. Following cases are possible: 2072

• - : No criticality information is applied explicitly. 2073

• YES: Criticality information is applied. This is usable only for non-repeatable IEs 2074

• GLOBAL: The IE and all its repetitions together have one common criticality information. 2075

This is usable only for repeatable IEs. 2076

• EACH: Each repetition of the IE has its own criticality information. It is not allowed to 2077

assign different criticality values to the repetitions. This is usable only for repeatable IEs. 2078

2079

Assigned criticality is set to reject for IEs that are considered as essential to continue with the 2080

procedure. 2081

When an optional IE defined with an assigned criticality set to reject is received in a message but 2082

not supported by the eNB or inconsistent, the procedure shall be considered unsuccessful and a 2083

failure message or ERROR INDICATION message shall be sent in response. 2084

2085

The full ASN1 description of procedures must be supported according to a standard release. 2086

Nevertheless, all IEs are not necessarily supported in terms of functionality. The node shall use 2087

the criticality associated to the non supported IEs to decide its behaviour. Typically, if criticality 2088

is “ignore”, the message may be treated, if it is “reject”, the message must not be treated. 2089




Some IEs are included in most of the S1AP messages. The eNB error handling for these IEs shall be 2090

the following: 2091

2092

IE/Group Name Error handling

Message type The assigned criticality of the message type defines the criticality of the associated procedure (see tables above)

MME UE S1AP ID • Unknown MME UE S1AP ID received : send failure message or ERROR INDICATION message with cause Radio Network Layer Cause, Unknown or already allocated MME UE S1AP ID

eNB UE S1AP ID • Unknown eNB UE S1AP ID received : send failure message or ERROR INDICATION message with cause Radio Network Layer Cause, Unknown or already allocated eNB UE S1AP ID

Mandatory IE missing in a message with assigned criticality reject

The procedure shall be rejected with a failure message if it exists or an ERROR INDICATION message with criticality Diagnostic IE

2093

4.16.3 PROTOCOL ERROR HANDLING 2094

According to TS 36.413, protocol error cases can be divided into three classes: 2095

• Transfer Syntax Error: this error occurs when the receiver is not able to decode the 2096

received physical message. They are detected in the process of ASN1 decoding. 2097

Error handling: when detecting a Transfer Syntax Error the eNB should ignore the 2098

message and send Error Indication (transfer-syntax-error). 2099

Examples of Transfer Syntax Error: 2100

o Value range violation, 2101

o Violation in list element constraints (list longer than allowed…) 2102

o Missing mandatory elements in a sequence 2103

o Wrong order of elements in a sequence 2104

• Abstract Syntax Error : this error occurs when the receiving functional S1AP entity 2105

receives: 2106

1. IEs or IE groups that cannot be understood (unknown IE ID) 2107

2. IEs for which the logical range is violated 2108

3. Missing mandatory IEs or IE groups 2109

4. IEs or IE groups received in wrong order or with too many occurrences 2110

5. Missing conditional IE or IE group when condition is verified or conditional IE or IE 2111

group present when the condition is not verified 2112

Error handling: 2113

Error cases 1 and 2 are handled based on received criticality information 2114

Error case 3 is handled based on criticality and presence information for the missing 2115

IE/IE group specified in the version of the specification used by the receiver. 2116

If criticality is set to “ignore”, the procedure continues as if the IE had not been 2117

received. If criticality is set to “reject”, the handling is the following: 2118

� Initiated message of a procedure with an unsuccessful response message: 2119

send unsuccessful response with cause Abstract Syntax Error (Reject) and 2120

include the Criticality Diagnostic IE. In case the information present in the 2121

initiating message was insufficient to determine a value for all IEs that are 2122

required to be present in the unsuccessful outcome procedure, the 2123

receiving node shall instead initiate an Error Indication procedure. 2124




� Initiated message of a procedure without an unsuccessful response 2125

message: send Error Indication message with cause Abstract Syntax Error 2126

(Reject) and include the Procedure Code IE, the Triggering message IE, 2127

the Procedure Criticality IE and the Criticality Diagnostic IE. 2128

� Response message of a procedure: consider the procedure unsuccessfully 2129

terminated and perform local error handling. 2130

Error cases 4 and 5 result in rejecting the procedure. None of the functional 2131

requests of the message shall be executed. 2132


send unsuccessful response with cause Abstract Syntax Error (Falsely 2134

Constructed Message). In case the information present in the initiating 2135

message was insufficient to determine a value for all IEs that are required 2136

to be present in the unsuccessful outcome procedure, the receiving node 2137

shall instead initiate an Error Indication procedure. 2138



(Falsely Constructed Message) and include the Procedure Code IE, the 2141

Triggering message IE, the Procedure Criticality IE and the Criticality 2142

Diagnostic IE. 2143



2146

• Logical Error : this error occurs when a message is comprehended correctly, but the 2147

information contained within the message is not valid (i.e. semantic error), or describes a 2148

procedure which is not compatible with the state of the receiver 2149

Error handling: depends on class procedure 2150

Class 1 procedures: if the procedure has a message to report an unsuccessful 2151

outcome, it is sent with an appropriate cause value (Semantic Error, Message not 2152

compatible with receiver state). When no unsuccessful outcome message exists, an 2153

Error Indication procedure shall be initiated with an appropriate cause value, 2154

Procedure Code IE, the Triggering message IE and the Criticality Diagnostic IE. 2155

Class 2 procedures: the procedure shall be terminated and the Error Indication 2156

procedure shall be initiated with an appropriate cause value, Procedure Code IE, the 2157

Triggering message IE and the Criticality Diagnostic IE. 2158

2159

The protocol error handling described hereafter shall take precedence over any other error 2160

handling. 2161

• If any type of error (Transfer Syntax Error, Abstract Syntax Error or Logical Error) is 2162

detected in the ERROR INDICATION message, it shall not trigger the Error Indication 2163

procedure in the receiving Node but local error handling. 2164

• In case a response message or Error Indication message needs to be returned, but the 2165

information necessary to determine the receiver of that message is missing, the procedure 2166

shall be considered as unsuccessfully terminated and local error handling shall be 2167

initiated. 2168

• If an error that terminates a procedure occurs, the returned cause value shall reflect the 2169

error that caused the termination of the procedure even if one or more abstract syntax 2170

errors with criticality "ignore and notify" have earlier occurred within the same procedure. 2171

• If an UE S1AP ID error is detected, the following error handling shall be applied : 2172




o If a node receives a first message that includes a remote AP ID which is erroneous 2173

e.g. an AP ID which has been stored previously for another UE-associated logical 2174

connection for the same peer node, the receiving node shall initiate an Error 2175

Indication procedure with inclusion of only the previously received AP ID from the 2176

peer node and an appropriate cause value. In this case, both nodes shall initiate a 2177

local release of any established UE-associated logical connection having the 2178

erroneous AP ID as local or remote identifier. 2179

o If a node receives a first returned message that includes a remote AP ID which has 2180

been stored previously for another UE-associated logical connection for the same 2181

peer node, or that includes an AP ID pair which is inconsistent (e.g. the local AP ID 2182

is unknown or already allocated to another UE-associated logical connection), the 2183

receiving node shall initiate an Error Indication procedure with inclusion of the 2184

received AP IDs from the peer node and an appropriate cause value. Both nodes 2185

shall initiate a local release of any established UE-associated logical connection 2186

(for the same S1 interface) having these AP IDs as local or remote identifier. 2187

o If a node receives a message (other than the first or first returned messages) that 2188

includes AP ID(s) identifying a logical connection which is unknown to the node 2189

(for the same S1 interface): 2190

- if this message is not the last message for this UE-associated logical connection, 2191

the node shall initiate an Error Indication procedure with inclusion of the 2192

received AP ID(s) from the peer node and an appropriate cause value. Both 2193

nodes shall initiate a local release of any established UE-associated logical 2194

connection (for the same S1 interface) having the erroneous AP ID(s) as local or 2195

remote identifier. 2196

- if this message is the last message for this UE-associated logical connection, 2197

the receiving node shall initiate a local release of any established UE-2198

associated logical connection (for the same S1 interface) that have either the 2199

local or remote AP ID(s) as identifiers. 2200

2201

4.16.4 HANDLING OF S1AP ERROR INDICATION IN RECEPTION 2202

The Error Indication procedure is initiated by a node to report detected errors in one incoming 2203

message, provided they cannot be reported by an appropriate failure message. 2204

If the error situation arises due to reception of a message utilising UE associated signalling, then 2205

the Error Indication procedure uses UE associated signalling. Otherwise the procedure uses non-UE 2206

associated signalling. The ERROR INDICATION message shall contain at least either the Cause IE or 2207

the Criticality Diagnostics IE. 2208

2209

On reception of an Error Indication, the eNB shall take appropriate actions, depending on the 2210

ongoing procedure state and on the type of detected error. This applies for both Class 1 and Class 2211

2 S1AP procedures. 2212

Defence mechanism based on supervision timers are already implemented in the eNB and most of 2213

the S1 procedures don’t need a specific handling of Error Indication. Log of Error Indication 2214

message for debug purpose and ignore received message is enough in most of the cases. 2215

Error Indication messages related to non-UE associated procedures are simply logged and ignored. 2216

Transfer Syntax Error, due to error detected in ASN1 decoding are simply logged and ignored. 2217

However, some UE associated procedures can be improved by adding a specific handling of Error 2218

Indication messages, mostly for Handover procedures. The following sections give details on these 2219

specific handling. 2220

An activation flag isS1EnhancementsAllowed enables to activate/deactivate specific Error 2221

Indication handling. 2222


Feature Number: L97980 <End: SRS-026072-520>




4.16.4.1 ERRONEOUS S1AP IDS 2223

In case the Error Indication procedure is triggered by utilising UE associated signalling the MME UE 2224

S1AP ID IE and the eNB UE S1AP IE will be included in the ERROR INDICATION message. If one or 2225

both of MME UE S1AP ID IE and the eNB UE S1AP IE are not correct, the cause shall be set to 2226

appropriate value “Radio Network Layer” / "Unknown or already allocated MME UE S1AP ID", 2227

"Unknown or already allocated eNB UE S1AP" or "Unknown or inconsistent pair of UE S1AP ID". 2228

On reception of an Error Indication message with cause ”Unknown or already allocated MME UE 2229

S1AP ID”, “Unknown or already allocated eNB UE S1AP ID” or “Unknown or inconsistent pair of UE 2230

S1AP ID”, the eNB shall release the call(s) and resources related to these incorrect S1AP IDs. 2231

As per TS 36.413 ref [R6] section 10.6, both nodes shall initiate a local release of any established 2232

UE-associated logical connection having the erroneous AP ID as local or remote identifier. 2233

Consequently, the eNB shall release the Call (and possibly another one) for which the MME 2234

indicated a faulty MME S1AP ID and/or eNB S1AP ID. 2235

2236

4.16.4.2 ABSTRACT SYNTAX ERROR AND LOGICAL ERRORS 2237

On reception of an Error Indication message with cause not related to erroneous S1AP IDs, the eNB 2238

may take appropriate actions depending on the ongoing procedure. 2239

The UE context related to Error Indication message is retrieved with eNB S1AP ID. The procedure 2240

code IE and triggering message IE included in Error Indication identify the failed message and 2241

procedure. 2242

2243

A specific handling is defined in case of reception of an Error Indication in response of following 2244

messages: 2245

o Handover Required: the eNB shall stop the timer TS1RELOCprep and returns to previous 2246

state before handover preparation 2247

o Handover Request Acknowledge: the eNB shall stop the internal defence timer 2248

interEnbS1Ho and behaves as the timer would have expired, i.e. all UE resources are 2249

released 2250

o Path Switch Request: the eNB shall behave as it would have received the Path Switch 2251

Request Failure message, i.e. the call is released 2252

o Handover Cancel: the eNB shall behave as in case of reception of a Handover Cancel 2253

Acknowledge message 2254

2255

4.17. X2AP ERROR HANDLING 2256

To prepare eNB for forward compatibility between two different 3GPP standard levels on X2 2257

interface, the eNB should provide the following functionalities: 2258

� X2 error handling on common and dedicated procedures 2259

� Error handling at procedure level 2260

� Error handling at IE level 2261

� Protocol Error handling 2262

2263




4.17.1 ERROR HANDLING AT PROCEDURE LEVEL 2264

The eNB shall answer to a not supported procedure with an ERROR INDICATION message with 2265

cause set to misc/unspecified and the optional IE criticality diagnostics (procedure 2266

code/triggering message/procedure criticality). 2267

2268

4.17.2 ERROR HANDLING AT IE LEVEL 2269

Some IEs need to be supported to assure compatibility with another eNB release, they are 2270

detailed in related procedures (see documents ref [A1] and [A2]) for details. 2271

The same error handling has to be processed as on S1 interface at IE level (refer to section 2272

4.16.2). 2273

Some IEs are included in most of the X2AP messages. The eNB error handling for these IEs shall be 2274

the following: 2275

2276

IE/Group Name Error handling

Message type The assigned criticality of the message type defines the criticality of the associated procedure (see tables above)

Old eNB UE X2AP ID • Unknown Old eNB UE X2AP ID received : send failure message or ERROR INDICATION message with cause Radio Network Layer Cause, Unknown or already allocated Old eNB UE X2AP ID

New eNB UE X2AP ID • Unknown New eNB UE X2AP ID received : send failure message or ERROR INDICATION message with cause Radio Network Layer Cause, Unknown or already allocated New eNB UE X2AP ID

Mandatory IE missing in a message with assigned criticality reject

The procedure shall be rejected with a failure message if it exists or an ERROR INDICATION message with criticality Diagnostic IE

2277

As per 36.423 ref [R7] section 8.2.1.3, the source eNB shall ignore any HANDOVER REQUEST 2278

ACKNOWLEDGE or HANDOVER PREPARATION FAILURE message received after the initiation of the 2279

Handover Cancel procedure and remove any reference and release any resources related to the 2280

concerned X2 UE-associated signalling. In consequence, any HANDOVER REQUEST ACKNOWLEDGE 2281

or HANDOVER PREPARATION FAILURE message received with an unknown Old eNB UE X2AP ID. 2282

2283

2284

4.17.3 PROTOCOL ERROR HANDLING 2285

According to TS 36.423, protocol error is handled in the same way as for S1 interface. The 2286

protocol error handling defined in section 4.16.3 for S1 interface applies to X2 interface. 2287

2288

• Transfer Syntax Error: this error occurs when the receiver is not able to decode the 2289

received physical message. They are detected in the process of ASN1 decoding. 2290

Error handling: when detecting a Transfer Syntax Error on X2 interface the eNB should 2291

ignore the message and send Error Indication (transfer-syntax-error). 2292

Examples of Transfer Syntax Error: 2293

o Value range violation, 2294

o Violation in list element constraints (list longer than allowed…) 2295


Feature Number: CR 00241909 Author: Martine Gateau

<End: SRS-026072-390>




o Missing mandatory elements in a sequence 2296

o Wrong order of elements in a sequence 2297

• Abstract Syntax Error: this error occurs when the receiving functional X2AP entity 2298

receives: 2299

� IEs or IE groups that cannot be understood (unknown IE ID) 2300

� IEs for which the logical range is violated 2301

� Missing mandatory IEs or IE groups 2302

� IEs or IE groups received in wrong order or with too many occurrences 2303

� Missing conditional IE or IE group when condition is verified or conditional IE or IE 2304

group present when the condition is not verified 2305

Error handling: 2306

Error cases 1 and 2 are handled based on received criticality information 2307

Error case 3 is handled based on criticality and presence information for the missing 2308

IE/IE group specified in the version of the specification used by the receiver. 2309

If criticality is set to “ignore”, the procedure continues as if the IE had not been 2310

received. If criticality is set to “reject”, the handling is the following: 2311


send unsuccessful response with cause Abstract Syntax Error (Reject) and 2313

include the Criticality Diagnostic IE. In case the information present in the 2314

initiating message was insufficient to determine a value for all IEs that are 2315

required to be present in the unsuccessful outcome procedure, the 2316

receiving node shall instead initiate an Error Indication procedure. 2317



(Reject) and include the Procedure Code IE, the Triggering message IE, 2320

the Procedure Criticality IE and the Criticality Diagnostic IE. 2321



Error cases 4 and 5 result in rejecting the procedure. None of the functional 2324

requests of the message shall be executed. 2325


send unsuccessful response with cause Abstract Syntax Error (Falsely 2327

Constructed Message). In case the information present in the initiating 2328

message was insufficient to determine a value for all IEs that are required 2329

to be present in the unsuccessful outcome procedure, the receiving node 2330

shall instead initiate an Error Indication procedure. 2331



(Falsely Constructed Message) and include the Procedure Code IE, the 2334

Triggering message IE, the Procedure Criticality IE and the Criticality 2335

Diagnostic IE. 2336



2339

• Logical Error: this error occurs when a message is comprehended correctly, but the 2340

information contained within the message is not valid (i.e. semantic error), or describes a 2341

procedure which is not compatible with the state of the receiver 2342

Error handling: depends on class procedure 2343




Class 1 procedures: if the procedure has a message to report an unsuccessful 2344

outcome, it is sent with an appropriate cause value (Semantic Error, Message not 2345

compatible with receiver state). When no unsuccessful outcome message exists, an 2346

Error Indication procedure shall be initiated with an appropriate cause value, 2347

Procedure Code IE, the Triggering message IE and the Criticality Diagnostic IE. 2348

Class 2 procedures: the procedure shall be terminated and the Error Indication 2349

procedure shall be initiated with an appropriate cause value, Procedure Code IE, the 2350

Triggering message IE and the Criticality Diagnostic IE. 2351

2352

The protocol error handling described hereafter shall take precedence over any other error 2353

handling. 2354

• If any type of error (Transfer Syntax Error, Abstract Syntax Error or Logical Error) is 2355

detected in the ERROR INDICATION message, it shall not trigger the Error Indication 2356

procedure in the receiving Node but local error handling. 2357

• In case a response message or Error Indication message needs to be returned, but the 2358

information necessary to determine the receiver of that message is missing, the procedure 2359

shall be considered as unsuccessfully terminated and local error handling shall be 2360

initiated. 2361

• If an error that terminates a procedure occurs, the returned cause value shall reflect the 2362

error that caused the termination of the procedure even if one or more abstract syntax 2363

errors with criticality "ignore and notify" have earlier occurred within the same procedure. 2364

• If an UE X2AP ID error is detected, the following error handling shall be applied : 2365

o If a node receives a first message that includes a remote AP ID which is erroneous 2366

e.g. an AP ID which has been stored previously for another UE-associated logical 2367

connection for the same peer node, the receiving node shall initiate an Error 2368

Indication procedure with inclusion of only the previously received AP ID from the 2369

peer node and an appropriate cause value. In this case, both nodes shall initiate a 2370

local release of any established UE-associated logical connection having the 2371

erroneous AP ID as local or remote identifier. 2372

o If a node receives a first returned message that includes a remote AP ID which has 2373

been stored previously for another UE-associated logical connection for the same 2374

peer node, or that includes an AP ID pair which is inconsistent (e.g. the local AP ID 2375

is unknown or already allocated to another UE-associated logical connection), the 2376

receiving node shall initiate an Error Indication procedure with inclusion of the 2377

received AP IDs from the peer node and an appropriate cause value. Both nodes 2378

shall initiate a local release of any established UE-associated logical connection 2379

(for the same X2 interface) having these AP IDs as local or remote identifier. 2380

o If a node receives a message (other than the first or first returned messages) that 2381

includes AP ID(s) identifying a logical connection which is unknown to the node 2382

(for the same X2 interface): 2383

- if this message is not the last message for this UE-associated logical connection, 2384

the node shall initiate an Error Indication procedure with inclusion of the 2385

received AP ID(s) from the peer node and an appropriate cause value. Both 2386

nodes shall initiate a local release of any established UE-associated logical 2387

connection (for the same X2 interface) having the erroneous AP ID(s) as local or 2388

remote identifier. 2389

- if this message is the last message for this UE-associated logical connection, 2390

the receiving node shall initiate a local release of any established UE-2391

associated logical connection (for the same X2 interface) that have either the 2392

local or remote AP ID(s) as identifiers. 2393

2394




4.17.4 HANDLING OF X2AP ERROR INDICATION IN RECEPTION 2395

In LA3.0, Error Indication messages received from peer eNB are simply logged and ignored. 2396

No specific handling is done by ENB on reception of these messages. 2397




5. OAM MODEL DESCRIPTION 2398

5.1. LTE CELL 2399

5.1.1 DATA MODEL 2400

The following figures represent the LteCell data model. 2401

LteCell

[0..1]

[0..1]

FrequencyAnd

BandwidthFDD

FrequencyAnd

BandwidthTDD

LteCell

FDD

LteCell

TDD

TxDivOr

MimoResources

Mimo

Configuration

PowerOffset

Configuration

Uplink

MIMO

Downlink

MIMO

Codebook

Subset

Restriction

[0..1]

[0..1]

[0..1]

Downlink

MIMOFDD

[0..1]

Downlink

MIMOTDD

BeamForming

[0..1]

SimoResources

[0..1]

PowerOffset

Configuration

[0..1]

Uplink

Mimo

2402

2403

Figure 29: Data Model For LteCell (1/6) 2404

2405




LteCell

CellL1L2Control

ChannelsConf

CellL2ULConf

L1Measurement

Conf

CellL2DlConfCellL1ULConf

[0..1]

[0..1]

CellL1Ul

ConfFDD

CellL1Ul

ConfTDD

[0..1]CellL2Dl

ConfTDD

[0..1]CellL2Dl

ConfTDD

ULPowerControl

Conf

CellicicConf

X2Load

IndicationConf[0..1]

2406

2407


2409

LteCell

CellSelectionReselectionConf

AccessBarring

AccessBarringForSignaling

AccessBarringForOriginating

Calls

CellRachConf

[0..1]

[0..1]

CellRachConfFDD

CellRachConfTDD

RadioCacCell

CellActivationService

SysInfoConf

2410

2411





LteCell

[0..48]

LteNeighboring

CellRelation

RRC

MeasurementConf

X2Access

[0..1]

[1..9]

CellReselection

ConfLte

LteNeighboring

FreqConf

[0..1]

[0..1]

LteNeighboring

LteSpeed

DependentConf

[0..16]

BlackCell

Conf

SpeedState

EvalConf

Mobility

PriorityTable

[0..3]

ServiceType

PriorityConf

2413

2414


2416

2417




LteCell

[0..16]

UtraFdd

Neighboring

FreqConf

[0.. 32]

UtraFdd

Neighboring

CellRelation

CellReselection

ConfUtraFddRncAccess

[0..1]

[0..1]

Utra

Neighboring

[0..1]

UtraSpeed

DependentConf

Mobility

PriorityTable

[0..3]

ServiceType

PriorityConf

[0..16]

[0.. 32]

Mobility

PriorityTable

[0..3]

ServiceType

PriorityConf

UtraTdd

Neighboring

FreqConf

CellReselection

ConfUtraTdd

UtraTdd

Neighboring

CellRelation

[0..1]

[0..3]

2418

2419


2421

2422

Commentaire [gme45] : <Start: SRS-026072-CC-160, Other>

Feature Number: L103792 Author: Christian Collin

<End: SRS-026072-CC-160>




2423

LteCell

[0..1]

[0..16]

GeranNeighboring

FreqsConf

Geran

Neighboring

CellReselection

ConfGeran

[0..32]

Geran

Neighboring

CellRelation

BscAccess

[0..1]

GeranSpeed

DependentConf

Mobility

PriorityTable

[0..3]

ServiceType

PriorityConf

HrpdNeighboring

[0..1]

[1..2]

HrpdBand

ClassConf

CellReselection

ConfHrpd

HrpdNeighboring

PerCarrier

[0..1]

HrpdSpeed

DependentConf

Mobility

PriorityTable[0..3]

ServiceType

PriorityConf

[0..3]

2424

2425


2427

5.1.2 OBJECT STATE MANAGEMENT 2428

During the Cell setup, the following states changes of the LteCell MO are sent to the OMC: 2429

Table 3: LteCell State Management 2430

Meaning LteCell MO states attributes (operational/availability)

Supporting hardware is not available Disabled/Dependency

Sector and a modem are available and cell setup can start

Disabled/.

Cell setup is successful and the System Information is broadcast. Cell is not barred.

Enabled/.

Cell setup has failed Disabled/Failed

Cell is locked Disabled/Off line

Cell is barred (refer to section 4.2.7.3 for details) Enabled/ Off-duty

2431

Note 1: LteCell::administrativeState is not propagated to CallP, the manager of LteCell (this is true 2432

in LA2.x/LA3.x), meaning CallP does not know when a cell gets locked. Upon reception of a common 2433

trigger – AVCN(PHY CELL, disabled, off-duty) – the CallP sets the operational and availability status 2434

of the cell to 'Disabled/ Dependency'. 2435

2436




Cell initial state

LteCell

Disabled

Dependency

LteCell

Disabled

(None)

LteCell

Enabled

(None)

LteCell

Disabled

Failed

A sector and modem become

available: cell setup may begin

Sector and modem

become unavailable

Cell setup is successful and

System Information is broadcast (cell not barred)

Sector and modem

become unavailable

Cell setup fails

Sector and modem

become unavailable

LteCell

Disabled

Off line

Cell is locked

LteCell

Enabled

Off duty

Cell is barred

Sector and modem

become unavailable

LteCell

(any state)

Cell is unlocked and modem is available: cell setup may begin

Cell is unlocked and modem is not available

Cell is unbarred

Cell setup is successful and

System Information is broadcast (cell barred by operator)

2437

Figure 35: LteCell State Diagram 2438

2439

After successful cell setup the eNB can self-trigger cell barring (See 4.2.7.3), transition 2440

the state of LteCell to “Enabled/ Off-duty”. 2441

With CR #269239, when no S1 link is operational during the cell setup, the cell will first 2442

be changed from “Disabled/None” to “Enabled/None”. The cell starts radiating and Sys 2443

Info is broadcast while S1 links setup is still in progress. After timer expiry (see 2444

section 4.2.7.3), if no S1 link is operational, the cell will be autobarred by eNB and 2445

becomes “Enabled/Off duty”. 2446

2447

Refer to state description above for details about LteCell state management in this 2448

case. 2449

2450




5.2. MME ACCESS 2451


S1AccessGroup

MmeAccessGroup

MmeQosConf

MmeAccess

MmeSctpLayerConf

MmeTransport

LayerAccess

[1..16]

S1Timers

[1..2]

[0..2]

[0..2]

S1Ho

TimersConf

PsHoTo

Utra

TimersConf

Nacc

TimersConf

availabilityStatus [FM]operationalState [FM]sctpAssocRemAddrsctpAssocRemAddrIpv6

dscpForMmevLanPriority

SctpAccessAssociationMaxRetranssctpAccessEstablishmentMaxRetriessctpAccessEstablishmentRetryIntervalsctpAccessMaxInitRetransmitssctpAccessPathMaxRetranssctpAssocHeartbeatInterval

endS1HoDataFwdTargettS1RelocOverallForS1HandovertS1RelocPrepForS1Handover

availabilityStatus [FM]operationalState [FM]administrativeState [CM]uniqueNamepriority

tS1RelocOverallForPsHandoverToUtratS1RelocPrepForPsHandoverToUtra

timeToWaitForEnbDirectInfoTransfertMobilityFromEutraCots1EnbDirectInfoTransferTrir

Enb

2453

2454

Figure 36: Data Model For S1-MME 2455


Following states are managed for S1 supervision. Associated state changes are sent to the 2457

OMC for display in the supervision view: 2458

Table 4: MmeAccess State Management 2459

Meaning MmeAccess MO states attributes (operational/availability)

MmeTransportLayerAccess (SCTP association) is not enabled

Disabled/Dependency

SCTP association is up, and S1 Setup Request has Disabled/.




been sent

S1 SCTP association is up, and S1 Setup Failure has been received or no answer received to several S1 Setup Request

Disabled/Failed

S1 setup procedure is successful Enabled/.

S1 link is locked (through MMEAccess administrativeState)

Disabled/Offline

2460

MMEAccess

Disabled

Dependency

MMEAccess

Disabled

(None)

MMEAccess

Enabled

(None)

MMEAccess

Disabled

Failed

Trigger: MMETransportLayerAccess becomes Enabled / None

Action: S1 Setup Request sent to MME

Trigger: No response to S1 Setup Request or S1 Setup Failure received

Action: wait before sending next S1 Setup Request

Trigger: S1 Setup Response received from MME

Trigger: S1 Setup Response received from MME

MMEAccess

(any state)

Trigger: MMETransportLayerAccess leaves state Enabled / None

MA4

MA3

MA5

MA2

MA1

No response to S1 Setup Request

or S1 Setup Failure received

MA6

MMEAccess

Disabled

Offline

Trigger: MMEAccess is locked

Trigger: MMEAccess is unlocked

MA7

MA8

2461

Figure 37: MMEAccess State Diagram 2462

2463

State transitions have been numbered (MA1, MA2, etc.) to facilitate cross-referencing in 2464

this and other documents. In the diagram above, transition MA6 differs from the other 2465

transitions in that no state change is generated. The idea is that once the first state 2466

change to Disabled/Failed has been sent, if the S1 setup continues to fail repetitively 2467

(through no response to S1 Setup Request or reception of S1 Setup Failure), the eNB will 2468

not repeat the state change. This avoids duplicating events unnecessarily and flooding the 2469

OAM. 2470




5.3. X2 ACCESS 2471


X2AccessGroup

X2QosConf

X2Access

[0..32]

X2SctpLayerConf

X2GtpConf

LteNeighboring

CellRelation

X2QosMqpping

[1..255]

X2Transport

LayerAccess

S1Ho

TimersConf

availabilityStatus [FM]operationalState [FM]administrativeState [CM]uniqueNamedirectFwdPathAvailabilitymacroEnbIdnoRemovenoX2noX2HOplmnMobileCountryCodeplmnMobileNetworkCode

availabilityStatus [FM]operationalState [FM]sctpAssocRemAddrsctpAssocRemAddrIpv6

sctpAccessEstablishmentMaxRetriessctpAccessEstablishmentRetryIntervalsctpAccessLinkFailureMaxRetriessctpAccessLinkFailureRetryIntervalsctpAssocHeartbeatInterval

endX2HoDataFwdTargetn3Requestt3Responsex2EchoRequestInterval

dscpserviceProfilevLanPriority

Enb

[0.1]

2473

2474

Figure 38: Data Model For X2AP 2475

2476


Following states are managed for X2 supervision. Associated state changes are sent to the 2478

OMC for display in the supervision view: 2479

Table 5: X2Access State Management 2480

Meaning X2Access MO states attributes (operational/availability)

X2TransportLayerAccess (SCTP association) is not enabled

Disabled/Dependency

SCTP association is up, and X2 Setup Request has been sent

Disabled/.




X2 SCTP association is up, and X2 Setup Failure has been received or no answer received to several X2 Setup Request

Disabled/Failed

X2 setup procedure is successful Enabled/.

X2 link is locked (through X2Access administrativeState) or black-listed (through X2Access noX2)

Disabled/Off line

X2 link is released by ANR garbage collection mechanism

Disabled/Off line

2481

X2Access initial stateon creation through X2

SETUP REQUEST received (ANR)

X2Access initial state at eNB start-up or at creation through new neighbour PCI discovered (ANR)

X2Access

DisabledDependency

X2Access

Disabled(None)

X2Access

Enabled(None)

X2Access

DisabledFailed

Trigger: X2TransportLayerAccess becomes Enabled/NoneAction: X2 Setup Request sent to peer eNB

Trigger: No response to X2 Setup Request or X2 Setup Failure receivedAction: wait before sending X2 Setup Request

Trigger: X2 Setup Response received from peer eNB

Trigger: X2 Setup Response received from peer eNB,or X2 Setup Request received from

peer eNB and X2 Setup Response sent

Trigger: X2 Setup Request received from peer eNB and X2 Setup Response sent

X2Access

(any state) Trigger: X2TransportLayerAccess leaves state Enabled / None

XA6

XA3XA5

XA4XA2

XA1

No response to X2 Setup Requestor X2 Setup Failure received

XA7

X2Access

DisabledOffline

Trigger: X2 link is locked or blacklisted, repeated eNB Configuration Update failureAction: send an SCTP SHUTDOWN

XA8

Trigger: X2 link is un-locked or un-blacklisted, SCTP Shutdown following eNB Configuration UpdateAction: send an SCTP INIT

Trigger: an X2 link is not used (e.g. ANR garbage collection) – not whitelisted or blacklistedAction: send an SCTP SHUTDOWN

XA10

XA12

2482

Figure 39: X2Access State Diagram 2483

2484

State transitions have been numbered (XA1, XA2, etc.) to facilitate cross-referencing in 2485

this and other documents. In the diagram above, transition XA7 differs from the other 2486

transitions in that no state change is generated. The idea is that once the first state 2487

change to Disabled/Failed has been sent, if the X2 setup continues to fail repetitively 2488

(through no response to X2 Setup Request or reception of X2 Setup Failure), the eNB will 2489

not repeat the state change. This avoids duplicating events unnecessarily and flooding the 2490

OAM. 2491

2492




6. ABBREVIATIONS AND DEFINITIONS 2493

6.1. ABBREVIATIONS 2494

ASN1 Abstract Syntax Notation One BCCH Broadcast Control Channel BCH Broadcast Channel CCCH Common Control Channel CN Core Network CQI Channel Quality Indicator CR Change Request DL-SCH Downlink Shared Channe DRX Discontinuous Reception (RX) EDGE Enhanced Data Rates for GSM Evolution eNB E-NodeB ETWS Earthquake and Tsunami Warning System FIFO First In First Out GERAN GSM EDGE Radio Access Network GSM Global System for Mobile communications HO Handover IE Information Element IMSI International Mobile Subscriber Identity KPI Key Product Indicator LS Liaison Statement LTE Long Term Evolution MAC Medium Access Control MCCH Multicast Control Channel MCH Multicast Channel MIB Master Information Block MIM Managed Information Model MME Mobility Management Entity MO Managed Object NE Network Element OAM Operation And Maintenance PBCH Physical Broadcast Channel PCCH Paging Control Channel PCFICH Physical Control Format Indicator Channel PCH Paging Channel PDCCH Physical Downlink Control channel PDSCH Physical Downlink Shared channel PHICH Physical Hybrid ARQ Indicator Channel PLMN Public Land Mobile Network PMCH Physical Multicast Channel PRACH Physical random access channel PUCCH Physical Uplink Control Channel PUSCH Physical Uplink Shared Channel RACH Random Access Channel RAT Radio Access Technology RLC Radio Link Control RNTI Radio Network Temporary Identity RRC Radio Resource Control S1AP S1 Application Protocol SCTP Stream Control Transmission Protocol SFN System Frame Number SI System Information SIB System Information Block




TAC Tracking Area Code TAI Tracking Area Identity TMSI Temporary Mobile Subscriber Identity TNL Transport Network Layer UE User Equipment UL-SCH Uplink Shared Channel UMTS Universal Mobile Telecommunications System UTRAN UMTS Terrestrial Radio Access Network X2AP X2 Application Protocol WPS Wireless Provisioning System 2495

2496

6.2. DEFINITIONS 2497

2498




ANNEX A: MASTER INFORMATION BLOCK AND SFN 2499

MASKING 2500

The System Frame Number or SFN is managed in the low layers of the eNB, and unknown 2501

to the application layer (call processing) in charge of performing the ASN1 encoding of the 2502

Master Information Block. The application shall therefore encode the Master Information 2503

Block using a default SFN with all bits set to 1, and the lower layers will replace it with the 2504

actual SFN at the moment of sending the Master Information Block. 2505

Bits 7 to 14 are the bits that must be replaced by the current SFN, as explained below. The 2506

assumption here is that the first and leftmost bit is numbered 1, and the last and 2507

rightmost bit is numbered 24. 2508

Master Information Block is the only message sent on BCCH carried by BCH, so no bits are 2509

required to identify it. The first bit is therefore the first bit of the message itself. 2510

BCCH-BCH-Message ::= SEQUENCE { 2511

message BCCH-BCH-MessageType 2512

} 2513

2514

BCCH-BCH-MessageType ::= MasterInformationBlock 2515

2516

MasterInformationBlock ::= SEQUENCE { 2517

dl-Bandwidth ENUMERATED { 2518

n6, n15, n25, n50, n75, n100, spare2, spare1}, 2519

phich-Configuration PHICH-Configuration, 2520

systemFrameNumber BIT STRING (SIZE (8)), 2521

spare BIT STRING (SIZE (10)) 2522

} 2523

2524

PHICH-Configuration ::= SEQUENCE { 2525

phich-Duration ENUMERATED { normal, extended }, 2526

phich-Resource ENUMERATED { oneSixth, half, one, two } 2527

} 2528

Three bits are required to encode 8 possible values for the dl-Bandwidth (bits 1 to 3 of the 2529

message). 2530

One bit is required to encode the 2 values for phich-Duration, and two bits for the 4 values 2531

of phich-Resource, giving a total of three bits for phich-Configuration (bits 4 to 6 of the 2532

message). 2533

The systemFrameNumber is coded on 8 bits (bits 7 to 14 of the message). 2534

The final 10 spare bits correspond to bits 15 to 24 of the Master Information Block. 2535

2536




ANNEX B: SYSTEM INFORMATION MESSAGE SIZE 2537

Scheduling of System Information blocks (or, in other words, the mapping of System 2538

Information blocks to System Information messages) and the reservation of the necessary 2539

resource blocks requires knowledge of the System Information block sizes and of the total 2540

System Information message size. Call processing pre-encodes System Information blocks 2541

and provides their sizes, and System Information Message size can be calculated based on 2542

the System Information Block sizes. 2543

The System Information message is sent on BCCH carried on DL-SCH. 2544

BCCH-DL-SCH-Message ::= SEQUENCE { 2545

message BCCH-DL-SCH-MessageType 2546

} 2547

2548

BCCH-DL-SCH-MessageType ::= CHOICE { 2549

c1 CHOICE { 2550

systemInformation SystemInformation, 2551

systemInformationBlockType1 SystemInformationBlockType1 2552

}, 2553

messageClassExtension SEQUENCE {} 2554

} 2555

One bit is necessary to encode the choice between "c1" and " messageClassExtension" for 2556

BCCH-DL-SCH-MessageType. 2557

One bit is necessary to encode the choice between " systemInformation" and " 2558

systemInformationBlockType1". 2559

SystemInformation ::= SEQUENCE { 2560

criticalExtensions CHOICE { 2561

systemInformation-r8 SystemInformation-r8-IEs, 2562

criticalExtensionsFuture SEQUENCE {} 2563

} 2564

} 2565

One bit is necessary to encode the choice between " systemInformation-r8" and " 2566

criticalExtensionsFuture". 2567

SystemInformation-r8-IEs ::= SEQUENCE { 2568

sib-TypeAndInfo SEQUENCE (SIZE (1..maxSIB)) OF CHOICE { 2569

sib2 SystemInformationBlockType2, 2570










... 2580

}, 2581

nonCriticalExtension SEQUENCE {} OPTIONAL -- Need OP 2582

} 2583

2584

maxSIB INTEGER ::= 32 -- Maximum number of SIBs 2585

One bit represents the presence of optional "nonCriticalExtension" within the 2586

SystemInformation-r8-IEs sequence. 2587

Five bits are necessary to encode the number of elements (from 1 to 32) in sequence sib-2588

TypeAndInfo. 2589

One bits is necessary to encode the extension marker ("…") in the CHOICE structure of sib-2590

TypeAndInfo. 2591




Four bits are necessary to encode the 10 possible values for the CHOICE structure of sib-2592

TypeAndInfo (sib2 to sib11). 2593

Prior to LA3.0, there is only one System Information Block in each System Information 2594

Message. The total size for the System Information message is therefore 14 bits (identified 2595

above) plus the size of the System Information Block that is contained within it. This total 2596

size is the one to use for resource block reservation. Obviously, the System Information 2597

message may eventually be padded with zeros for octet alignment and / or resource block 2598

size alignment. 2599

L108958 (Sys-Info Scheduling Improvements) in LA3.0 supportsmultiple System Information 2600

Blocks within a single System Information Message as determined by the DL Scheduler. In 2601

this case, the formula for System Information Message size calculation is the following 2602

(assuming no extensions are used): 2603

Total size = (9 bits of non-extended "header") + n * (5 bits of non-extended CHOICE 2604

identifier) + ∑n

(System Information Block size) 2605

Where n is the number of System Information Blocks encoded in a single System Information 2606

Message. 2607

2608




ANNEX C: PAGING MESSAGE ENCODING 2609

As specified in section 4.3.2, CallP encodes individual paging records and it is the 2610

Scheduler's responsibility to assemble the RRC Paging message. Here is how this must be 2611

done. 2612

The RRC Paging message is carried on PCCH. 2613

2614

PCCH-Message ::= SEQUENCE { 2615

message PCCH-MessageType 2616

} 2617

2618

PCCH-MessageType ::= CHOICE { 2619

c1 CHOICE { 2620

paging Paging 2621

}, 2622

messageClassExtension SEQUENCE {} 2623

} 2624

The first bit is set to 0 to indicate choice "c1" in the PCCH-MessageType. The first and 2625

leftmost bit of the RRC Paging message is numbered 1 and the following bits are numbered 2626

2, 3, etc. 2627

Paging ::= SEQUENCE { 2628

pagingRecordList PagingRecordList OPTIONAL, -- Need ON 2629

systemInfoModification ENUMERATED { true } OPTIONAL, -- Need ON 2630

etws-Indication ENUMERATED { true } OPTIONAL, -- Need ON 2631

nonCriticalExtension SEQUENCE {} OPTIONAL -- Need OP 2632

} 2633

Bit number 2 is set to 1 to indicate that the pagingRecordList is present. 2634

Bit number 3 is set to 1 if there is going to be a change in System Information (as specified 2635

in section 4.2.4), and set to 0 otherwise. 2636

Bits number 4 and 5 are set to 0 to indicate that etws-Indication and nonCriticalExtension 2637

are absent (these are not supported in LA3.0). 2638

PagingRecordList ::= SEQUENCE (SIZE (1..maxPageRec)) OF PagingRecord 2639

Bits number 6 to 9 are set to "0000" to indicate that the PagingRecordList contains 1 2640

PagingRecord. In LA3.0, the eNB does not support multiple paging records in the same RRC 2641

Paging message. 2642

In order to assemble an RRC Paging message, in LA3.0 the Scheduler therefore 2643

concatenates 9 bits set to "0100 0000 0" if there is no change in system information or 2644

"0110 0000 0" otherwise, followed by the paging record pre-encoded by CallP. If a Paging 2645

message must be sent to signify an upcoming change in System Information when there are 2646

no paging records to send, the Paging message is simply the sequence "0010 0000 0". The 2647

resulting bitstring is eventually padded with zeros for octet alignment and / or resource 2648

block size alignment. 2649

2650




ANNEX D: PAGING MESSAGE SIZE FOR RESOURCE 2651

BLOCK RESERVATION 2652

The Scheduler pre-reserves resource blocks for the RRC Paging message, based on its 2653

maximum theoretical size. 2654

In LA3.0, the RRC Paging will contain at most one paging record and none of the optional 2655

parameters, therefore the maximum message size is 9 bits (see previous section) plus the 2656

maximum size of one paging record, detailed hereafter. 2657

PagingRecord ::= SEQUENCE { 2658

ue-Identity PagingUE-Identity, 2659

cn-Domain ENUMERATED { ps, cs }, 2660

... 2661

} 2662

2663

PagingUE-Identity ::= CHOICE { 2664

s-TMSI S-TMSI, 2665

imsi IMSI, 2666

... 2667

} 2668

2669

maxPageRec INTEGER ::= 16 2670

2671

S-TMSI ::= SEQUENCE { 2672

mmec MMEC, 2673

m-TMSI BIT STRING (SIZE (32)) 2674

} 2675

2676

MMEC ::= BIT STRING (SIZE (8)) 2677

2678

IMSI ::= SEQUENCE (SIZE (6..21)) OF IMSI-Digit 2679

2680

IMSI-Digit::= INTEGER (0..9) 2681

2682

One bit is needed to encode the extension marker ("…") of the PagingRecord sequence. 2683

One bit is needed to encode the extension marker ("…") of the PagingUE-Identity choice. 2684

One bit is needed to encode the choice between s-TMSI and imsi for the PagingUE-Identity. 2685

An S-TMSI is coded on 40 bits (8 bits for mmec, 32 bits for m-TMSI). 2686

An IMSI is coded on 28 to 88 bits: 4 bits are needed to code the number of digits (from 6 to 2687

21), each digit is coded on 4 bits. 2688

One bit is needed to code the cn-Domain. 2689

The maximum paging record size is therefore obtained with a 21 digit IMSI and equals 92 2690

bits, leading to an RRC Paging message size of 101 bits. 2691

2692

In the future the eNB will support multiple paging records within a single RRC Paging 2693

message. When this happens, resource block reservation will have to be based on a 2694

reasonable paging message size. It would be inefficient to reserve blocks for a hypothetical 2695

message composed of 16 records of 21 digit IMSI each (leading to a total size of 1481 bits – 2696

9 + 16*92), when in reality a UE is most often paged with its 40 bit S-TMSI. In comparison, 2697

a Paging composed of 16 S-TMSI paging records is 713 bits (9 + 16*44). Moreover, in most 2698

currently deployed networks the IMSI is coded on 15 digits. 2699

2700

�� END OF DOCUMENT 2701

Documents

EUTRAN Cell and Interface Management%2Dv03 12