LTE DCL APP 034072 V08 en LTE Transport Engineering Guide For LR14.1 and WMM7

LTE TRANSPORT ENGINEERING GUIDE FOR LR14.
1 & WMM7
LTE TRANSPORT ENGINEERING GUIDE FOR LR14.1 &

WMM7
Document number: LTE/DCL/APP/034072
Document issue: 08.01/EN
Document status: Approved-Preliminary
Date: 27/Jun/2014
Alcatel-Lucent - Proprietary - Use pursuant to applicable agreements
Legal notice
Alcatel, Lucent, Alcatel-Lucent and the Alcatel-Lucent logo are trademarks of Alcatel-Lucent. All
other trademarks are the property of their respective owners
The information presented is subject to change without notice. Alcatel-Lucent assumes no

responsibility for inaccuracies contained herein.
Copyright © 2010 Alcatel-Lucent. All rights reserved.

Contains proprietary/trade secret information which is the property of Alcatel-Lucent and must not
be made available to, or copied or used by anyone outside Alcatel-Lucent without its written
authorization.
Not to be used or disclosed except in accordance with applicable agreements.
LTE/DCL/APP/034072 08.01/EN Approved-Preliminary 27/Jun/2014 Page 1/504

LTE TRANSPORT ENGINEERING GUIDE FOR LR14.1 & WMM7
CONTENTS
1 INTRODUCTION .............................................................................................................................. 17
1.1 OBJECT AND SCOPE OF THIS DOCUMENT ........................................................................... 17
1.2 AUDIENCE FOR THIS DOCUMENT .......................................................................................... 17
1.3 TEG NAMING CONVENTIONS .................................................................................................. 17
2 RELATED DOCUMENTS ................................................................................................................ 19
2.1 APPLICABLE DOCUMENTS ...................................................................................................... 19
2.2 REFERENCE DOCUMENTS ...................................................................................................... 21
3 LTE IP NETWORK TRANSPORT ................................................................................................... 25
3.1 LTE NETWORK ARCHITECTURE ............................................................................................. 25
3.2 LTE/EPS STANDARD REFERENCE POINTS ........................................................................... 25
3.3 LTE PROTOCOL STACKS ......................................................................................................... 26
3.3.1 eUTRAN protocol stack .......................................................................................................... 26
3.3.2 ePC protocol stack ................................................................................................................. 26
3.3.2.1 GTPv2-C Control Plane ..........................................................................26
3.3.2.2 DIAMETER Control Plane ........................................................................27
3.3.2.3 User Plane .........................................................................................27
3.4 LTE PROTOCOLS ...................................................................................................................... 28
3.4.1 SCTP ...................................................................................................................................... 28
3.4.1.1 RTO calculation ..................................................................................31
3.4.1.2 SCTP packet format .............................................................................33
3.4.1.3 Retransmission timer ............................................................................38
3.4.1.4 Fault Management ...............................................................................38
3.4.1.5 Peer Multi-Homing ...............................................................................42
3.5 DIAMETER .................................................................................................................................. 43
3.5.1 Diameter packet format .......................................................................................................... 44
3.5.2 Diameter message flows ........................................................................................................ 47
4 LTE E2E PERFORMANCE & QOS FUNCTIONS ........................................................................... 48
4.1 OVERVIEW OF LTE E2E QOS................................................................................................... 48
4.2 BEARER QOS PARAMETERS ................................................................................................... 49
4.3 E2E FLOW BINDING .................................................................................................................. 50
4.4 E2E QOS FUNCTIONS AND MAPPING TO LTE NETWORK ELEMENTS............................... 52
4.5 TRANSPORT QOS ..................................................................................................................... 53
4.5.1 Traffic Management functions ................................................................................................ 54
4.5.2 Network QoS models ............................................................................................................. 55
4.5.3 Layer 3 QoS: DiFFSERV ....................................................................................................... 56
4.5.3.1 Diffserv marking ..................................................................................57
4.5.3.2 PER HOP BEHAVIOR (PHB) .......................................................................60
4.5.4 Layer 2 QoS : 802.1q ............................................................................................................. 61
5 LTE TRANSPORT REQUIREMENT ................................................................................................ 63
5.1 LAYER2/LAYER3 REQUIREMENT ............................................................................................ 63
5.2 SECURITY REQUIREMENT ....................................................................................................... 63
5.2.1 Generic IPsec Theory ............................................................................................................ 63
5.2.1.1 Security Definitions ..............................................................................64
5.2.1.2 IPsec Components ................................................................................64
5.2.1.3 IPsec Walk Through ..............................................................................68
5.2.1.4 IPsec IKE (Stage 0) ...............................................................................71

5.2.1.5 Stage 1 - IPsec traffic selection and SA database lookup ..................................76

5.2.1.6 Stage 2 - IPsec Encryption and Transmission .................................................77
5.2.1.7 IPsec Transmission and Reception (Stage 3 & 4) ............................................77
5.2.1.8 Receiving Packet Inspection (Stage 5 & 6) ...................................................77
5.2.1.9 Decrypting IPsec Packet (Stage 7 & 8) ........................................................78
5.2.2 Transport Security Gateway................................................................................................... 78
5.2.2.1 General IPsec Compatibility ....................................................................79
5.2.2.2 7750 SR Security Gateway ......................................................................80
5.2.2.3 Fortinet Security Gateway ......................................................................81
5.2.3 Generic IPsec Certificate Theory ........................................................................................... 83
5.2.3.1 Certificate Management System Terminology ...............................................83
5.2.3.2 CMS System Architecture .......................................................................86
5.2.3.3 CMS System Architecture with eUTRAN .......................................................91
5.2.3.4 CMS Theory .......................................................................................93
5.3 RESILIENCY REQUIREMENT ................................................................................................. 100
5.3.1 LAG ...................................................................................................................................... 101
5.4 SYNCHRONISATION REQUIREMENT .................................................................................... 102
5.4.1 Local GPS ............................................................................................................................ 103
5.4.2 Synchronous Ethernet .......................................................................................................... 103
5.4.3 IEEE 1588 v2 – Precision Time Protocol (PTP) ................................................................... 106
5.4.3.1 Principles of time synchronization with PTP ............................................... 115
5.4.3.2 Principles of frequency synchronization with PTP ........................................ 116
5.5 EUTRAN AND EPC IP ADDRESS REQUIREMENT ................................................................ 117
5.6 UE IP ADDRESS REQUIREMENT ........................................................................................... 118
5.6.1 DL UE PDU Routing function ............................................................................................... 118
5.6.2 UL UE PDU Routing function ............................................................................................... 118
5.7 END TO END PERFORMANCE ............................................................................................... 118
5.8 BIDIRECTIONAL FORWARDING DETECTION (BFD) ............................................................ 120
5.8.1 BFD Concept ........................................................................................................................ 120
5.8.1.1 BFD Operating Modes .......................................................................... 121
5.8.1.2 BFD Control, Echo and Timers ............................................................... 121
5.8.1.3 BFD Session ..................................................................................... 123
5.8.1.4 BFD Session Failure ............................................................................ 124
6 MACRO ENB TRANSPORT IMPLEMENTATION ........................................................................ 125
6.1 ETHERNET ............................................................................................................................... 125
6.1.1 Backhaul connectivity ........................................................................................................... 125
6.1.1.1 eCCM ............................................................................................. 127
6.1.1.2 eCCM2 ........................................................................................... 130
6.1.2 Daisy Chaining ..................................................................................................................... 131
6.1.3.1 Simultaneous SyncE+PTP (TDD only) ........................................................ 133
6.1.4 VLAN – single operator ........................................................................................................ 133
6.1.4.1 Supported configuration with no VLAN ..................................................... 134
6.1.4.2 Supported configurations with 1 VLAN ...................................................... 134
6.1.4.3 Supported configurations with 2 VLANs ..................................................... 135
6.1.5 VLAN – eUTRAN sharing ..................................................................................................... 139
6.1.5.1 MOCN architecture ............................................................................. 140
6.1.5.2 GWCN architecture ............................................................................ 142
6.1.6 Ethernet QoS........................................................................................................................ 144

6.1.6.1 IEEE 802.1q interoperability between release 2005 and release 2011 ................. 147
6.1.7 Ethernet frame size .............................................................................................................. 149
6.1.8 LAG ...................................................................................................................................... 149
6.2 IPV4 ........................................................................................................................................... 149
6.2.1 MTU ...................................................................................................................................... 149
6.2.1.1 MTU for C-Plane, OAM & PTP ................................................................. 150
6.2.1.2 MTU for U-Plane ................................................................................ 151
6.2.2 OAM addressing................................................................................................................... 154
6.2.2.1 eNB OAM addressing - without PnP .......................................................... 154
6.2.2.2 eNodeB events time-stamping ............................................................... 155
6.2.3 Telecom addressing ............................................................................................................. 155
6.2.4 Subnetting ............................................................................................................................ 157
6.2.5 eNB private IPv4 addressing................................................................................................ 158
6.2.6 Routing ................................................................................................................................. 158
6.2.6.1 Routing principle at eNodeB .................................................................. 158
6.2.6.2 OAM Routing .................................................................................... 159
6.2.6.3 Telecom Routing ............................................................................... 159
6.2.6.4 Routing table initialisation ................................................................... 161
6.2.7 IP QoS .................................................................................................................................. 162
6.3 DHCPV4 .................................................................................................................................... 166
6.3.1 eNB configuration by DHCPv4 server .................................................................................. 168
6.3.1.1 Vendor Specific Information option format ................................................ 170
6.4 IPV6 ........................................................................................................................................... 172
6.4.1 MTU ...................................................................................................................................... 173
6.4.1.2 MTU for U-Plane ................................................................................ 173
6.4.2 Addressing ........................................................................................................................... 173
6.4.2.1 eNodeB events time-stamping ............................................................... 173
6.4.2.2 eNodeB Link-local address .................................................................... 174
6.4.2.3 eNodeB Global Unicast address .............................................................. 175
6.4.2.4 eNodeB IPv6 interface(s) static configuration ............................................. 176
6.4.2.5 eNodeB IPv6 interface(s) automatic configuration ........................................ 177
6.4.3 OAM interface configuration at initial eNodeB startup ......................................................... 179
6.4.4 OAM interface configuration at non initial eNodeB startup .................................................. 180
6.4.5 Subnetting ............................................................................................................................ 180
6.4.6 Routing ................................................................................................................................. 180
6.4.6.1 Routing table initialisation ................................................................... 181
6.4.7 IP QoS .................................................................................................................................. 183
6.5 DUAL IPV4/IPV6 STACK .......................................................................................................... 183
6.6 IPV4 TO IPV6 MIGRATION ...................................................................................................... 183
6.7 ICMPV6 FOR NEIGHBORING DISCOVERY ........................................................................... 184
6.7.1 Source and destination IP addresses .................................................................................. 184
6.7.2 Router Solicitation ................................................................................................................ 185
6.7.3 Router Advertisement .......................................................................................................... 185
6.7.4 Neighbor Solicitation / Neighbor Advertisement .................................................................. 187
6.8 DHCPV6 .................................................................................................................................... 188
6.8.1 DHCPv6 stateless ................................................................................................................ 188
6.8.2 DHCPv6 stateful ................................................................................................................... 188
6.8.3 Source and destination IP addresses .................................................................................. 189
6.8.4 DHCPv6 message format .................................................................................................... 189

6.8.5 DHCPv6 option format ......................................................................................................... 190

6.8.5.1 Client Identifier ................................................................................ 191
6.8.5.2 Identity Association for Non-temporary Addresses (IA_NA) .............................. 192
6.8.5.3 IA Address ....................................................................................... 193
6.8.5.4 Status Code ..................................................................................... 193
6.8.5.5 Vendor Class .................................................................................... 194
6.8.5.6 Vendor Specific Information .................................................................. 195
6.9 SCTP ......................................................................................................................................... 197
6.9.1 Association initiation failure .................................................................................................. 197
6.9.2 Association failure / Path failure ........................................................................................... 197
6.9.3 SCTP parameters setting at eNodeB ................................................................................... 198
6.9.4 Peer’s Stream Identifiers detection ...................................................................................... 199
6.10 SECURITY ................................................................................................................................ 199
6.10.1 IPsec Feature ....................................................................................................................... 199
6.10.1.1 Dependencies & Assumptions ................................................................ 200
6.10.1.2 Network Connectivity ......................................................................... 200
6.10.1.3 IPsec Configuration & Hard coded Parameters ............................................ 205
6.10.1.4 Supported Parameters ......................................................................... 206
6.10.1.5 IPsec Configuration Parameters.............................................................. 207
6.10.1.6 NON Plug-N-Play IPsec Configurations. ..................................................... 221
6.10.1.7 Multiple Operator Considerations ............................................................ 227
6.10.1.8 ALU 7750 Interoperability with the eNodeb ................................................ 228
6.10.1.9 Fortinet Security Gateway Interoperability with the eNodeB ........................... 228
6.10.1.10 QOS .............................................................................................. 228
6.10.1.11 MTU .............................................................................................. 229
6.10.1.12 Recommendations ............................................................................. 229
6.10.1.13 Scenarios And Examples ....................................................................... 229
6.10.1.14 Considerations .................................................................................. 231
6.10.2 CMS Certificates .................................................................................................................. 232
6.10.2.1 Dependencies and Assumptions .............................................................. 232
6.10.2.2 CMS MIM ......................................................................................... 232
6.10.2.3 CMS eNB Configurations ....................................................................... 233
6.10.2.4 CMS eNB Implementation ..................................................................... 233
6.10.2.5 Security Gateway Implementation .......................................................... 238
6.10.3 eNB Security Plug-N-Play Implementation .......................................................................... 242
6.10.3.1 IPsec Plug-N-Play Pre-Requisits features and capabilities ............................... 243
6.10.3.2 IPsec Plug-N-Play Pre-Deployment configurations ........................................ 245
6.10.3.3 eNB PNP Configurations ....................................................................... 246
6.10.3.4 IPsec Plug-N-Play Walk Through with IPsec and DHCP capability ....................... 247
6.10.4 Automatic Security Gateway Discovery (ASGD) ................................................................. 250
6.10.5 Non Transport specific Related Security Features .............................................................. 253
6.10.5.1 Security DoS Attack Protections ............................................................. 253
6.10.5.2 Security Enhancements ....................................................................... 257
6.11 TRAFFIC MANAGEMENT ........................................................................................................ 258
6.11.1 UL Traffic Shaping................................................................................................................ 258
6.11.1.1 UL traffic scheduling .......................................................................... 259
6.11.1.2 Queue congestion management.............................................................. 265
6.11.1.3 UL traffic shaping .............................................................................. 269
6.11.2 Transport CAC ..................................................................................................................... 273
6.11.2.1 Functional overview ........................................................................... 273
6.11.2.2 Emergency calls ................................................................................ 277
6.11.2.3 High Priority Access calls ..................................................................... 279
6.11.2.4 T-CAC per VLAN in downlink.................................................................. 280

6.11.2.5 T-CAC per VLAN in uplink ..................................................................... 302

6.11.2.6 T-CAC per port in downlink ................................................................... 303
6.11.2.7 T-CAC per port in uplink ...................................................................... 304
6.11.2.8 Interaction with Inter-frequency Load Balancing feature ................................ 305
6.12 X2 INTERFACE ......................................................................................................................... 307
6.12.1 Ethernet ................................................................................................................................ 307
6.12.2 IP .......................................................................................................................................... 307
6.12.2.1 IP addressing .................................................................................... 307
6.12.3 SCTP .................................................................................................................................... 308
6.12.3.1 Association and stream ........................................................................ 309
6.12.3.2 SCTP parameters for RTO calculation ....................................................... 309
6.12.3.3 Association establishment .................................................................... 310
6.12.3.4 SCTP acknowledgment ........................................................................ 311
6.12.3.5 X2 retransmission timer vs. SCTP retransmission timer .................................. 312
6.12.3.6 Failure detection ............................................................................... 313
6.12.3.7 SCTP provisioning .............................................................................. 315
6.12.4 GTP ...................................................................................................................................... 315
6.13 S1 INTERFACE ......................................................................................................................... 316
6.13.1 Ethernet ................................................................................................................................ 316
6.13.2 IP .......................................................................................................................................... 316
6.13.2.1 IP addressing .................................................................................... 316
6.13.2.2 Multiple eNodeBs having same IP address .................................................. 318
6.13.3 SCTP .................................................................................................................................... 318
6.13.3.5 S1 retransmission timer vs. SCTP retransmission timer .................................. 322
6.13.4 GTP ...................................................................................................................................... 325
6.14 IEEE 1588V2 INTERFACE ....................................................................................................... 326
6.14.1 Hardware .............................................................................................................................. 328
6.14.2 Ethernet ................................................................................................................................ 328
6.14.2.1 MAC addressing – Unicast mode .............................................................. 329
6.14.2.2 MAC addressing – Multicast mode ............................................................ 329
6.14.2.3 Ethernet QoS.................................................................................... 329
6.14.3 IP .......................................................................................................................................... 330
6.14.3.1 IPv4 addressing – Unicast mode .............................................................. 330
6.14.3.2 IPv4 addressing – Multicast mode ............................................................ 331
6.14.3.3 IPv6 addressing – Unicast mode .............................................................. 331
6.14.3.4 IPv6 addressing – Multicast mode ............................................................ 332
6.14.4 UDP ...................................................................................................................................... 332
6.14.5 PTP ...................................................................................................................................... 332
6.14.5.1 Unicast mode ................................................................................... 336
6.14.5.2 Multicast mode ................................................................................. 337
6.14.5.3 PTP server redundancy ........................................................................ 338
6.14.5.4 PTP Domain Number ........................................................................... 339
6.14.5.5 On-Path Support................................................................................ 339
6.14.5.6 Delay ............................................................................................. 340
6.14.6 PTP Model Object for configuration ..................................................................................... 340
6.14.7 Simultaneous SyncE+PTP (TDD only) ................................................................................ 343
6.15 M3 INTERFACE ........................................................................................................................ 344

6.15.1 Static configuration ............................................................................................................... 347

6.15.2 Ethernet ................................................................................................................................ 348
6.15.3 IP .......................................................................................................................................... 348
6.15.3.1 IP addressing .................................................................................... 348
6.15.4 SCTP .................................................................................................................................... 349
6.16 IGMPV3 & MLDV2 .................................................................................................................... 350
6.16.1 Ethernet ................................................................................................................................ 352
6.16.2 IP .......................................................................................................................................... 353
6.16.2.1 IP addressing .................................................................................... 354
6.17 M1 INTERFACE ........................................................................................................................ 354
6.17.1 Ethernet ................................................................................................................................ 354
6.17.2 IP .......................................................................................................................................... 355
6.17.3 GTP ...................................................................................................................................... 355
6.17.4 Synchronization .................................................................................................................... 355
6.18 ENB SELF COMMISSIONING WITH PLUG-N-PLAY............................................................... 356
6.18.1 Self Commissioning parameters associated with transport ................................................. 356
6.18.2 Self Commissioning impacts on the transport ...................................................................... 358
6.18.3 High level Self Commissioning description .......................................................................... 359
6.18.4 Self Commissioning Walk through with NON IPsec PNP .................................................... 359
6.18.4.1 NON IPsec Plug and Play Pre-Requisits features and capabilities ....................... 359
6.18.4.2 Plug and Play Pre-Deployment configurations ............................................. 360
6.18.4.3 NON IPsec Plug and Play Walk Through with IPsec and DHCP capability ............... 361
6.19 TRANSPORT COUNTERS ....................................................................................................... 363
6.19.1 Ethernet ................................................................................................................................ 363
6.19.2 SCTP .................................................................................................................................... 365
6.19.3 X2 ......................................................................................................................................... 365
6.19.4 S1 ......................................................................................................................................... 365
6.19.5 M1 ........................................................................................................................................ 366
6.19.6 UL traffic shaping ................................................................................................................. 366
6.19.7 Transport CAC ..................................................................................................................... 367
6.19.8 1588v2 .................................................................................................................................. 368
7 METRO CELL TRANSPORT IMPLEMENTATION ....................................................................... 370
7.1 ETHERNET ............................................................................................................................... 371
7.1.1 Daisy-chain connectivity (MCO FAM only) .......................................................................... 371
7.1.3 VLAN – single operator ........................................................................................................ 375
7.1.3.1 Supported configuration with no VLAN ..................................................... 375
7.1.3.2 Supported configurations with 1 VLAN ...................................................... 375
7.1.4 VLAN – eUTRAN sharing ..................................................................................................... 376
7.1.5 Ethernet QoS........................................................................................................................ 376
7.1.6 Ethernet frame size .............................................................................................................. 376

7.1.7 LAG ...................................................................................................................................... 376

7.2 IPV4 ........................................................................................................................................... 377
7.2.1 MTU ...................................................................................................................................... 377
7.2.1.2 MTU for U-Plane ................................................................................ 377
7.2.2 OAM Addressing .................................................................................................................. 377
7.2.3 Telecom addressing ............................................................................................................. 377
7.2.4 Subnetting ............................................................................................................................ 377
7.2.5 eNB private IPv4 addressing................................................................................................ 377
7.2.6 Routing ................................................................................................................................. 377
7.2.7 IP QoS .................................................................................................................................. 377
7.3 IPV6 ........................................................................................................................................... 377
7.4 DUAL IPV4/IPV6 STACK .......................................................................................................... 377
7.5 IPV4 TO IPV6 MIGRATION ...................................................................................................... 378
7.6 ICMPV6 FOR NEIGHBORING DISCOVERY ........................................................................... 378
7.7 DHCPV6 .................................................................................................................................... 378
7.8 SCTP ......................................................................................................................................... 378
7.9 SECURITY ................................................................................................................................ 378
7.9.1 IPsec .................................................................................................................................... 378
7.9.2 eNB Security Plug-N-Play Implementation .......................................................................... 378
7.9.2.1 Supported PNP Configurations ............................................................... 379
7.9.2.2 Ipsec IPv6 over IPv4 support .................................................................. 380
7.9.2.3 381
7.9.3 Automatic Security Gateway Discovery (ASGD) ................................................................. 381
7.9.4 Node Self Commissioning .................................................................................................... 382
7.9.5 DOS Attack........................................................................................................................... 382
7.9.6 Security Enhancements ....................................................................................................... 382
7.9.7 NAT-T ................................................................................................................................... 382
7.9.8 Secure Boot and Secure Storage ........................................................................................ 384
7.9.9 Migration (164959) ............................................................................................................... 384
7.9.10 (LNG) MCO WIFI AP with IPsec .......................................................................................... 385
7.9.10.1 Required components ......................................................................... 386
7.9.10.2 Factory provisioned ............................................................................ 387
7.9.10.3 Wi-Fi O&AM Connection Flow ................................................................ 387
7.9.10.4 Restrictions ..................................................................................... 388
7.10 TRAFFIC MANAGEMENT ........................................................................................................ 388
7.10.1 UL Traffic Shaping................................................................................................................ 388
7.10.2 Transport CAC ..................................................................................................................... 388
7.11 X2 INTERFACE ......................................................................................................................... 388
7.12 S1 INTERFACE ......................................................................................................................... 389
7.13 IEEE 1588V2 INTERFACE ....................................................................................................... 389
7.13.1 PnP for 1588 IP address(es) acquisition .............................................................................. 390
7.13.2 Support of NAT-T ................................................................................................................. 391
7.13.3 PTP Domain Number ........................................................................................................... 394
7.14 M3 INTERFACE ........................................................................................................................ 394
7.15 IGMPV3 & MLDV2 .................................................................................................................... 394
7.16 M1 INTERFACE ........................................................................................................................ 394
7.17 TRANSPORT COUNTERS ....................................................................................................... 394
8 MME TRANSPORT IMPLEMENTATION ...................................................................................... 395

8.1 CONNECTIVITY ........................................................................................................................ 395

8.1.1 Internal Connectivity ............................................................................................................. 395
8.1.2 Hub Connectivity .................................................................................................................. 396
8.1.2.1 External Connections .......................................................................... 396
8.1.2.2 Internal Product Connections ................................................................ 398
8.1.2.3 Message Path ................................................................................... 398
8.1.3 Internal IP Addresses and Subnetworks .............................................................................. 401
8.1.3.1 Initial Configuration ........................................................................... 401
8.1.3.2 Default Gateway and Static Routes ......................................................... 402
8.1.3.3 Recommendations ............................................................................. 403
8.1.3.4 Internal subnetworks .......................................................................... 404
8.1.3.5 External Subnetworks ......................................................................... 405
8.1.3.6 Multiple IP addresses per component ....................................................... 406
8.1.3.7 Transport connections ......................................................................... 406
8.1.3.8 Virtual Local Area Networks (VLANs) ........................................................ 409
8.1.3.9 Hardware-related Subnetworks and IP Addressing ........................................ 413
8.1.3.10 Internal Service-Related Subnetwork and IP Addressing ................................. 419
8.1.4 Virtual Router Redundancy Protocol (VRRP) ...................................................................... 421
8.1.5 Virtual/Floating IP Address................................................................................................... 421
8.1.5.1 Virtual IP Address .............................................................................. 421
8.1.5.2 Usage of the Virtual IP Address .............................................................. 421
8.1.5.3 Floating IP Address............................................................................. 422
8.2 LOGICAL INTERFACES AND PROTOCOLS ........................................................................... 422
8.2.1 IP .......................................................................................................................................... 424
8.2.1.1 IP QoS ............................................................................................ 424
8.2.1.2 Flexible Mapping of QoS Parameters Between LTE and 2G/3G .......................... 425
8.2.1.3 Configuration of Flexible QoS ................................................................ 425
8.2.2 Diameter ............................................................................................................................... 426
8.2.2.1 WMM Configuration for Support for Diameter Routing Agent ............................ 427
8.2.3 SCTP .................................................................................................................................... 428
8.2.3.1 SCTP Multi-Homing ............................................................................. 428
8.2.3.2 SCTP Profile ..................................................................................... 430
8.2.3.3 SCTP Profile attributes ........................................................................ 430
8.2.3.4 MME SCTP components redundancy ......................................................... 433
8.2.4 S1 interface .......................................................................................................................... 434
8.2.4.1 IP ................................................................................................. 434
8.2.4.2 SCTP ............................................................................................. 436
8.2.4.3 S1 SCTP provisionning model ................................................................. 438
8.2.5 S6a interface ........................................................................................................................ 439
8.2.5.1 IP ................................................................................................. 439
8.2.5.2 SCTP ............................................................................................. 441
8.2.5.3 S6a over SCTP provisionning model ......................................................... 443
8.2.5.4 TCP ............................................................................................... 447
8.2.6 SGs interface........................................................................................................................ 449
8.2.6.1 IP ................................................................................................. 449
8.2.6.2 SCTP ............................................................................................. 450
8.2.6.3 SGs provisionning model ...................................................................... 452
8.2.7 SLg ....................................................................................................................................... 455
8.2.7.1 IP ................................................................................................. 457
8.2.7.2 SCTP ............................................................................................. 458
8.2.7.3 Diameter ........................................................................................ 460
8.2.7.4 SLg provisionning model ...................................................................... 460
8.2.8 SLs ....................................................................................................................................... 465

8.2.8.1 IP ................................................................................................. 468

8.2.8.2 SCTP ............................................................................................. 469
8.2.8.3 SLs provisionning model ....................................................................... 470
8.2.9 M3 ........................................................................................................................................ 473
8.2.9.1 IP ................................................................................................. 475
8.2.9.2 SCTP ............................................................................................. 476
8.2.9.3 M3 provisionning model ....................................................................... 477
8.2.10 SBc ....................................................................................................................................... 478
8.2.10.1 IP ................................................................................................. 479
8.2.10.2 SCTP ............................................................................................. 481
8.2.10.3 SBc provisionning model ...................................................................... 482
8.2.10.4 SBc Link Access Control List .................................................................. 484
8.2.11 GTP ...................................................................................................................................... 484
8.2.11.1 GTP Profile ...................................................................................... 484
8.2.11.2 GTP Profile attributes ......................................................................... 484
8.2.12 Sm ........................................................................................................................................ 486
8.2.12.1 IP ................................................................................................. 487
8.2.12.2 UDP .............................................................................................. 488
8.2.12.3 GTP-C ............................................................................................ 488
8.2.12.4 Sm provisionning model ....................................................................... 489
8.2.13 S102 ..................................................................................................................................... 490
8.2.14 Gn ......................................................................................................................................... 491
8.2.14.1 Provision Gn Interface ......................................................................... 491
8.3 MME BIDIRECTIONAL FORWARDING DETECTION (BFD) IMPLEMENTATION ................. 492
8.3.1 BFD Redundancy and Failover ............................................................................................ 493
8.3.2 BFD Configuration ................................................................................................................ 493
8.3.3 BFD Alarms .......................................................................................................................... 495
8.3.4 BFD Router .......................................................................................................................... 495
8.4 SOURCE BASED ROUTES ...................................................................................................... 495
8.5 PHYSICAL REDUNDANCY ...................................................................................................... 495
8.6 SECURITY ................................................................................................................................ 496
8.6.1 IPsec .................................................................................................................................... 496
8.6.1.2 Network Connectivity for CALEA X1_1 and X2 Interfaces ................................ 497
9 ABBREVIATIONS AND DEFINITIONS ......................................................................................... 502
9.1 ABBREVIATION ........................................................................................................................ 502
9.2 DEFINITION .............................................................................................................................. 503

LIST OF FIGURES
Figure 1: Overview of LTE network architecture ........................................................................................... 25
Figure 2: eUTRAN Protocol Stack .................................................................................................................... 26
Figure 3: SCTP association establishment....................................................................................................... 29
Figure 4: SCTP heartbeating ........................................................................................................................... 30
Figure 5: Delayed SCTP acknowledgement ..................................................................................................... 31
Figure 6: SCTP message structure ................................................................................................................... 33
Figure 7: SCTP INIT format .............................................................................................................................. 35
Figure 8: SCTP heartbeating and peer multi-homed ...................................................................................... 39
Figure 9: Association establishment failure .................................................................................................... 40
Figure 10: SCTP association failure ................................................................................................................. 41
Figure 11: SCTP association failure and peer multi-homed ............................................................................ 42
Figure 12: SCTP path failure and peer multi-homed ...................................................................................... 43
Figure 13: Diameter packet structure ............................................................................................................. 44
Figure 14: Diameter Attribute-Value Pair ....................................................................................................... 46
Figure 15: Diameter message flows................................................................................................................. 47
Figure 16: EPS bearer service layered architecture ....................................................................................... 48
Figure 17: E2E traffic flows and their QoS requirements ............................................................................... 52
Figure 18: Main QOS functions and mapping on LTE NE ................................................................................. 53
Figure 19: QOS functions per level .................................................................................................................. 53
Figure 20: QOS Function .................................................................................................................................. 54
Figure 21: Diffserv domain concept ................................................................................................................ 57
Figure 22: IPv4 header format ........................................................................................................................ 58
Figure 23: IPv6 header format ........................................................................................................................ 58
Figure 24: DiffServ Code Point field details .................................................................................................... 59
Figure 25: Transport and Tunnel Mode Formats ............................................................................................. 65
Figure 26: Transport and Tunnel Mode Formats ............................................................................................. 66
Figure 27: Protection Depending on Transport and Tunnel Mode .................................................................. 66
Figure 28: AH Header ...................................................................................................................................... 67
Figure 29: ESP Header ..................................................................................................................................... 68
Figure 30: IPsec Transport Configuration ........................................................................................................ 69
Figure 31: Host IP Packet Transmission to Security Gateway......................................................................... 70
Figure 32: IKEv2 Phase 1 Negotiation .............................................................................................................. 72
Figure 33: IKE Key calculation with Pre-Shared Key Authentication .............................................................. 73
Figure 34: IKE Key calculation with Digital Signature Authentication ........................................................... 74
Figure 35: IKEv2 Phase 2 Negotiation .............................................................................................................. 75
Figure 36: SPD / SADB Transmission Validation .............................................................................................. 76
Figure 37: SADB / SPD Receiving Validation.................................................................................................... 78
Figure 38: Fortinet Reference Architecture ................................................................................................... 82
Figure 39: Fortinet Virtual Domain Configuration .......................................................................................... 83
Figure 40: CMS Archtitecture .......................................................................................................................... 87
Figure 41: CMS Architecture Model 1 .............................................................................................................. 88
Figure 44: CMS eUTRAN Architecture.............................................................................................................. 92
Figure 45:CMS Root and CA SUB Initialization ................................................................................................ 94
Figure 46: CA SUB and eNB Initialization ........................................................................................................ 95
Figure 47: CMPv2 Protocol Stack ..................................................................................................................... 96
Figure 48: Model 1 Validation Diagram ......................................................................................................... 100
Figure 49: End to End OAM support ............................................................................................................... 101
Figure 50: Synchronous ethernet concept..................................................................................................... 104
Figure 51: Unicast negociation ...................................................................................................................... 106
Figure 52: Request unicast transmission message structure ........................................................................ 107
Figure 53: PTP periodical Unicast negociation and time stamp exchange ................................................... 108

Figure 54: Two-way propagation delay determination in PTP ..................................................................... 115

Figure 55: Principle of frequency synchronization ....................................................................................... 116
Figure 56: PDV impact on frequency synchronization .................................................................................. 116
Figure 57: General Overview of IP Subnets in LTE network ......................................................................... 117
Figure 58: BFD Control Packet ...................................................................................................................... 123
Figure 59: eCCM front panel ......................................................................................................................... 128
Figure 60: eCCM2 front panel........................................................................................................................ 130
Figure 61: VLAN - Model object for configuration ........................................................................................ 138
Figure 62: eUTRAN sharing architecture for MOCN ...................................................................................... 140
Figure 63: eUTRAN sharing architecture for GWCN - example..................................................................... 142
Figure 64: Ethernet QoS - Model object for configuration ........................................................................... 147
Figure 65: MTU - Model object for configuration ......................................................................................... 151
Figure 66: IPv4 addressing - Model object for configuration ....................................................................... 156
Figure 67: IP QoS - Model object for configuration ...................................................................................... 166
Figure 68: DHCP message flow ...................................................................................................................... 167
Figure 69: DHCP message format .................................................................................................................. 168
Figure 70: eNodeB Link Local Address (LLA) format ..................................................................................... 174
Figure 71: Global Unicast Address (GUA) format as per IETF RFC 3587 ...................................................... 175
Figure 72: eNodeB Global Unicast Address (GUA) format............................................................................. 175
Figure 73: IPv6 addressing - Model object for configuration ....................................................................... 177
Figure 74: Stateful DHCPv6 message sequence ............................................................................................ 188
Figure 75: Relayed DHCPv6 message exchange ............................................................................................ 189
Figure 76: Association establishment failure – ALU implementation ........................................................... 197
Figure 77: Path failure & Association failure – case of peer multi-homed ................................................... 198
Figure 78: IPsec Host-to-Network Security Topology .................................................................................... 201
Figure 79: MOCN eUTRAN Sharing ................................................................................................................. 202
Figure 80: eUTRAN Sharing Architecture ...................................................................................................... 203
Figure 81: IPsec Traffic Flow......................................................................................................................... 204
Figure 82: X2 User Plane Traffic .................................................................................................................... 205
Figure 83: IPsec / CMS MIM ........................................................................................................................... 208
Figure 84: Graphical Representation of Table 49 VLAN configuration 1 ...................................................... 226
Figure 85: Worse Case IPsec Overhead Calculation ...................................................................................... 231
Figure 86: Factory Certificate Architecture ................................................................................................. 236
Figure 87: IPsec PNP Network Topology ....................................................................................................... 243
Figure 88: Plug-N-Play Flow (1)..................................................................................................................... 247
Figure 92: Automatic Security Gateway Discovery Network ........................................................................ 251
Figure 93: Traffic Scheduling in WinPath 2 - Strict priority ......................................................................... 260
Figure 94: UL traffic scheduling – per VLAN – Model object for configuration............................................. 263
Figure 95: WRED mechanism ......................................................................................................................... 268
Figure 96: UL congestion management – per VLAN - Model object for configuration.................................. 269
Figure 97: UL traffic shaping – per VLAN - Model object for configuration ................................................. 272
Figure 98: T-CAC - backhaul & VLAN - Model object for configuration ....................................................... 274
Figure 99: T-CAC - per operator - Model object for configuration .............................................................. 277
Figure 100: T-CAC - per VLAN - Model object for configuration .................................................................. 283
Figure 101: T-CAC bandwidth model – per CoS level .................................................................................... 284
Figure 102: T-CAC bandwidth model – per VLAN level ................................................................................. 285
Figure 103: S1 overhead bit rate calculation – example for VoIP in IPv4 with IPsec ................................... 291
Figure 104: T-CAC - per port - Model object for configuration .................................................................... 304
Figure 105: X2 SCTP – peer addressing - Model object for configuration .................................................... 308
Figure 106: X2 retransmission timer vs. SCTP retransmission timer ............................................................ 313
Figure 107: X2 SCTP - Model object for configuration ................................................................................. 315
Figure 108: S1 SCTP – peer addressing - Model object for configuration ..................................................... 317
Figure 109: S1 retransmission timer vs. SCTP retransmission timer ............................................................ 323
Figure 110: S1 SCTP - Model object for configuration .................................................................................. 325

Figure 111: Initial Request Unicast Transmission – ALU implementation ..................................................... 337
Figure 112: 1588 VLAN & IP – Model object for configuration ...................................................................... 341
Figure 113: 1588 – Model object for configuration ....................................................................................... 342
Figure 114: eMBMS architecture ................................................................................................................... 344
Figure 115: M3 Session Start ......................................................................................................................... 346
Figure 116: M3 Session Stop .......................................................................................................................... 347
Figure 117: M3 Session Reset ........................................................................................................................ 347
Figure 118: M3 SCTP – peer addressing - Model object for configuration .................................................... 349
Figure 119: IGMPv3 and MLDv2 – Query and Report ..................................................................................... 352
Figure 120: NON IPsec Plug and Play Flow .................................................................................................... 362
Figure 121: MCO FAM transport components ................................................................................................ 370
Figure 122: Traffic paths for the LTE MCO plus Daisy Chain traffic ............................................................. 373
Figure 123: UL Traffic L2 QoS management for the LTE MCO plus Daisy Chain traffic ............................... 374
Figure 124: NAT - procedure for updating the mapping table ..................................................................... 393
Figure 125: ATCA Connector Zones ............................................................................................................... 395
Figure 126: Cabling Configuration for oRTM and Faceplate ......................................................................... 397
Figure 127: Cabling Configuration for Hub Interconnection......................................................................... 398
Figure 128: MME Hub Connectivity ................................................................................................................ 399
Figure 129: MME Network Connectivity ........................................................................................................ 407
Figure 130: Port Connectivity for oRTM ........................................................................................................ 409
Figure 131: MME VLAN Configuration ............................................................................................................ 410
Figure 132: MME Logical Interfaces ............................................................................................................... 422
Figure 133: SCTP restart on MIF switchover .................................................................................................. 434
Figure 134: S1 SCTP Profile provisionning ..................................................................................................... 438
Figure 135: S1 Interface Profile provisionning .............................................................................................. 439
Figure 136: S6a SCTP Profile ......................................................................................................................... 444
Figure 137: S6a over SCTP - Interface Profile ............................................................................................... 444
Figure 138: S6a Diameter Profile .................................................................................................................. 445
Figure 139: S6a over SCTP - Diameter Connection provisioning ................................................................... 446
Figure 140: S6a over SCTP - Remote End Point Configuration...................................................................... 446
Figure 141: S6a over TCP - Diameter Connection ......................................................................................... 448
Figure 142: S6a over TCP - Remote End Point Configuration ....................................................................... 448
Figure 143: SGs SCTP Profile ......................................................................................................................... 453
Figure 144: SGs Interface Profile .................................................................................................................. 453
Figure 145: SGs –MSC Server provisioning ..................................................................................................... 454
Figure 146: SGs - Remote End Point Configuration ....................................................................................... 454
Figure 147: SLg protocol stack ...................................................................................................................... 455
Figure 148: Mobile Terminated - Location Request (MT-LR) ........................................................................ 456
Figure 149: Network Induced - Location Request (NI-LR) ............................................................................. 457
Figure 150: SLg SCTP Profile.......................................................................................................................... 461
Figure 151: SLg Interface Profile ................................................................................................................... 461
Figure 152: SLg Diameter Profile ................................................................................................................... 462
Figure 153: SLg Diameter Connection ........................................................................................................... 463
Figure 154: SLg Remote End Point Configuration ......................................................................................... 464
Figure 155: SLg primary GMLC vs. alternate GMLC ....................................................................................... 465
Figure 156: SLs protocol stack ....................................................................................................................... 466
Figure 157: LPP signaling between E-SMLC and UE ....................................................................................... 466
Figure 158: UE assisted and UE based positioning procedure....................................................................... 467
Figure 159: LPPa signaling between E-SMLC and eNodeB ............................................................................. 467
Figure 160: Network based positioning procedure ....................................................................................... 468
Figure 161: SLs SCTP Profile .......................................................................................................................... 471
Figure 162: SLs Interface Profile ................................................................................................................... 471
Figure 163: SLs Remote End Point Configuration .......................................................................................... 472
Figure 164: SLs E-SMLC Configuration ........................................................................................................... 472
Figure 165: M3 protocol stack ....................................................................................................................... 474
Figure 166: M3 MBMS Session Management procedures ................................................................................ 474
Figure 167: M3 SCTP Profile .......................................................................................................................... 477

Figure 168: M3 Interface Profile .................................................................................................................... 478

Figure 169: SBc protocol stack ...................................................................................................................... 479
Figure 170: SBc CMAS procedure ................................................................................................................... 479
Figure 171: SBc SCTP Profile ......................................................................................................................... 483
Figure 172: SBc Interface Profile ................................................................................................................... 484
Figure 173: Sm protocol stack ....................................................................................................................... 486
Figure 174: Sm MBMS Session Management procedures ................................................................................ 487
Figure 175: Sm GTP-C Profile ........................................................................................................................ 489
Figure 176: Sm Interface Profile ................................................................................................................... 490
Figure 177: BFD Network Architecture ......................................................................................................... 492
Figure 178: MME Redundant Physical Links ................................................................................................... 496

LIST OF TABLES
Table 1: Meaning of <Nature> ......................................................................................................................... 18
Table 2: Standardized QoS characteristics ..................................................................................................... 50
Table 3: General Security Gateway IPsec Attributes ..................................................................................... 80
Table 4: Fault management mechanism at the Ethernet level .................................................................... 101
Table 5: ESMC PDU format ............................................................................................................................ 105
Table 6: Details of the Data and Padding field............................................................................................. 105
Table 7: syncE Quality Levels........................................................................................................................ 105
Table 8: IEEE 1588v2 message types ............................................................................................................. 109
Table 9: Summary of Defined subnets and associated Vlan(s) ..................................................................... 118
Table 10: User Plane Delay Budgets ............................................................................................................. 119
Table 11: User Plane End to End Delays ....................................................................................................... 119
Table 12: Supported configurations with untagged Ethernet frames .......................................................... 134
Table 13: Supported configurations with 1 VLAN ......................................................................................... 135
Table 14: Supported configurations with 2 VLANs ........................................................................................ 135
Table 17: MOCN - Supported configurations for the master operator ......................................................... 141
Table 18: MOCN - Supported configurations for a non master operator ...................................................... 141
Table 19: GWCN - Supported configurations for the master operator ......................................................... 143
Table 20: GWCN - Supported configurations for non master operator#1 .................................................... 144
Table 21: GWCN - Supported configurations for non master operator#2 .................................................... 144
Table 22: eNodeB support for OAM IPv6 interface automatic configuration ............................................... 179
Table 23: OAM IPv6 interface configuration at initial startup ..................................................................... 180
Table 24: OAM IPv6 interface configuration at non initial startup .............................................................. 180
Table 25: ICMPv6 message supported for neighbor discovery ...................................................................... 184
Table 26: Source and Destination IPv6 addresses for Network Discovery messages.................................... 184
Table 27: Router Solicitation message format ............................................................................................. 185
Table 28: Router Solicitation message format ............................................................................................. 185
Table 29: M and O Flags in RA messages ....................................................................................................... 185
Table 30: Prefix information option format ................................................................................................. 187
Table 31: Source and destination IP addresses of DHCPv6 messages .......................................................... 189
Table 32: DHCPv6 message format ............................................................................................................... 189
Table 33: Supported DHCPv6 messages ........................................................................................................ 190
Table 34: DHCPv6 option format................................................................................................................... 190
Table 35: Supported DHCPv6 options............................................................................................................ 191
Table 36: DHCPv6 Client Identifier format ................................................................................................... 191
Table 37: DUID-EN format ............................................................................................................................. 192
Table 38: IA_NA format ................................................................................................................................. 192
Table 39: IA Address format .......................................................................................................................... 193
Table 40: Status Code format ....................................................................................................................... 193
Table 41: DHCPv6 Status Codes .................................................................................................................... 194
Table 42: Vendor Class .................................................................................................................................. 194
Table 43: Vendor-Class-Data format ............................................................................................................. 194
Table 44: Vendor Specific Information format ............................................................................................. 195
Table 45: DHCPv6 proprietary option for IPv6 router address ..................................................................... 195
Table 46: DHCPv6 proprietary option for EMS IPv6 address/Port number ................................................... 196
Table 47: DHCPv6 proprietary option for Security Gateway IP address ...................................................... 196
Table 48: DHCPv6 proprietary option for EMS FQDN .................................................................................... 196
Table 49: DHCPv6 proprietary option for SEG FQDN .................................................................................... 196
Table 50: DHCPv6 proprietary option for EMS IPv4 address/Port number ................................................... 196
Table 51: SCTP parameters setting at eNodeB ............................................................................................. 199
Table 52: IPsec Configurations for Single Operator (1) ................................................................................ 223

Table 55: IPsec Configurations for Multiple Operators (1) ........................................................................... 227
Table 56: IPsec Overhead example based on Encryption ............................................................................. 231
Table 57: DSCP to scheduling priority mapping derived by eNodeB ............................................................ 265
Table 58: S1 bit rate calculation – example for IMS VoIP & non-GBR in IPv4 with IPsec ............................. 293
Table 59: IMS VoIP & non-GBR without overbooking .................................................................................... 300
Table 60: IMS VoIP & non-GBR with overbooking ......................................................................................... 302
Table 61: IGMPv3 & MLDv2 source & destination IP addresses .................................................................... 354
Table 62: DHCP information set for PNP scenario ........................................................................................ 358
Table 63: MCO Ethernet port mode of operation ......................................................................................... 371
Table 64: Example IP Addresses for MME Application Interfaces ................................................................. 420
Table 65: Example IP Addresses for MME OA&M Interfaces.......................................................................... 420
Table 66: Example IP Addresses for MME Ethernet Interfaces ..................................................................... 421

1 INTRODUCTION
This document introduces the transport engineering guidelines for the eUTRAN (eNodeB) and
partially the ePC (MME), summarizing their scope and requirements for LR14.1 and WMM7.
In this document;
• chapters 3, 4 and 5 cover LTE general aspects such as 3GPP or RFCs specifications,
• chapter 6 covers the description of the macro eNB ALU design
• chapter 7 covers the description of the Metro cell ALU design
• chapter 8 covers the description of the MME ALU design
Each of the LTE nodes has its own release naming:

• eNodeB releases are named LRww, LR for Light Radio
• MME releases are named WMMxx
• S-GW releases are named LSGW_Ryy
• P-GW releases are named LPGW_Rzz
An End to End solution is named LEvv, E for E2E and is built from the products own releases.
1.1 OBJECT AND SCOPE OF THIS DOCUMENT

The purpose of this document is to detail the “transport network layer” (TNL).
This includes the way protocol stacks are configured, monitored, their limitations …
These information are required for architecture and design of an end to end LTE network and
needed to deliver a detailed transport parameters plan.
Restriction:
The detailed transport design and configuration for a LTE network which will include IP nodes
layouts and configuration, IP Planning for core elements, IP dimensioning for WAN links, QoS
planning is out of the scope of this document.
1.2 AUDIENCE FOR THIS DOCUMENT

This document is intended for use by mainly:
• Network Designers
• Engineering team
• Project management
• System test
1.3 TEG NAMING CONVENTIONS

The product associated rules are presented as follows:

Rule: <Domain> <Name> (<Nature>)
Aims at describing what is supported or not
The Engineering Guidelines are presented as follows:

Engineering: <Domain> <Name> (<Nature>)
Recommendations to get the best of the product and/or network within supported space
The restrictions are presented as follows:

Restriction: <Domain> <Name> (<Nature>)
When feature is not supported or is not as described into standards
Where:
<Domain>: Identifies which Node, Network Element, Interface… it is applicable

<Name>: Gives a title to the rule
<Nature>: Indicates the root cause for it
<Nature> Meaning
HC Hard Coded Either Hardware or Software is responsible for this.
M Mandatory Must be followed for the system to operate properly into a supported
environment.
S Standard Required by Standard
D Design Mainly for restriction related with Design
T Test Mainly for restriction related with Tests
R Recommended Design: To follow good Network Design basis and principles.
Availability: To ensure Network robustness.
Performances: To provide with an optimized usage of resources.
Security: To secure network against potential attacks.
Operations: To offer better operational effectiveness for site or network
extension, upgrade, reconfiguration…
Table 1: Meaning of <Nature>

2 RELATED DOCUMENTS
2.1 APPLICABLE DOCUMENTS

LA3.0 (FDD)
FRS 92076 Synchronization: 1588v2
FRS 97926 Multi-vendor X2 IOT Readiness
FRS 101813 Transport Several VLANs
FRS 101805 Transport support of IPv6 for Telecom and OAM, DHCPv6
FRS 92087 IP Ethernet S1 and X2 Enhancement
FRS 101808 Security Support of IPsec enhancement above Ipv4 and Ipv6
FRS 92078 Transport IPsec with IKE v2
TLA3.0 (TDD)
FRS 118470 Transport 3 VLAN: 1VLAN OAM, 1 VLAN telecom S1, 1 VLAN telecom X2
FRS 103894 eMBMS support: 1VLAN OAM, 1 VLAN telecom, 1 VLAN M1
LA4.0 (FDD)
L115544 Transport: configurable SCTP Timer
L115622 Transport 4 VLANs
L114383 Transport eUTRAN Sharing
L101806.1 Transport UL Traffic Shaping
L115887 Support of Multiple GrandMaster reference Sources
LA5.0 (FDD)
L115372 Transport CAC
L116367 Transport 3 VLAN
L115244 GWCN configuration (with shared MME) for eUTRAN Sharing
L114546 Synchronization Support of 1588 v2 above Ipv6 + counter PTPFramePDV
L115527 EMBMS Trial support
L112791 Transport counters (inc. per VLAN counters and 1588 counters)
L101812 IPsec with Certificates
LA6.0 (FDD)
L163336 Security Pnp with IPv4 with Ipsec with Certificate
L112791 Transport counters
L115262 eMBMS Trial Phase 2 with distributed MCE
LR13.1
LR115940 Metro Cell Transport: LA6.0 SW features extension for the metro (Step 1)
161112 Metro Cell Transport: LA6.0 SW features extension for the metro (Step 2)
159959 Metro Cell Transport: Transport Parity with LA7.1 SW features
134100 Metro Cell Transport: SW support for Backhaul configuration (Step 1)
161113 Metro Cell Transport: SW Support for Backhaul Configuration (Step 2)

L114382 Security DOS Attack Protections

L115970 eNB Self Commissioning Improvements
160695 Automatic security gateway discovery for eNB
LR13.3
159440 Security Rel 10 on eNB, CRL on 9981 CMS
163826 Metro Cell Transport IPv6 support over IPv4 IPSec tunnel
Secure Boot and Secure Storage in the Metro Cell Outdoors with the Trust
164959
Architecture
171757 Metro Cell Transport Security PnP enhancement with DNS, and SEG redirection
L115860 High Priority Access Admission Control
134098 Metro Cell Transport with Wifi plus Daisy Chain WCDMA
Metro Cell Transport Outdoors Uplink Traffic Managemnt with LTE or WCDMA
165598
Daisy Chain
T114546 1588 Sync Support for SyncE+1588 and 1588overEth and Multicast
159405 1588v2 Sync support for eMBMS and eICIC
168405 Metro Cell Transport: Transport Parity with Macro (EEE1588v2)
L115850 eCCM2-controlled introduction in FDD
Feature recovery from previous releases for TDD - Transport and Security in
T115976
TDD
LR14.1
170841 Metrocell Transport: DHCP for 1588
168727 Metrocell Transport: eMBMS Transport configurations
178044 Metrocell Transport: IPv6 support in OAM VLAN
168496 Security improvement release over release
174520 Metrocell Transport: 9764 MCO WIFI AP PnP Testing with SeGW
LM4.0
m10402-05 MME Support of SCTP Multi-Homing
m11014-01 MME support for multiple DSCP values on all network interfaces
m11005-01 MME support for Warning Message Delivery
m0402-06 MME support for SCTP Multi-Homing on S1-MME, S6a, and SGs MME
m80152-01 MME GigE Connectivity enhancements MME
m10401-01 MME support of VLANs MME
m80140-03 MME Support for Bidirectional Forward Detection IPv4 only
m80140-06 MME Support for Bidirectional Forward Detection for Dual Stack (IPv4 and IPv6)
m10404-01 Support of Provisioning of Separate SCTP Interfaces for SGs Interface
m10300-14 IPSEC support for X1_1, X2 CALEA interfaces
m10405-02 MME support for source based routing on MPH interfaces – Phase 2
m30107-02 Custom QoS Parameter Mapping from EPS to Release 99
m80152-06 Enhancement to MME Interface Configuration Changes
m10402-10 MME support for Multi-Homing for CMAS

LM5.0
m10300-04 IPsec support for X1_1, X2 CALEA Interfaces – Carry Forward
m80140-07 Bidrectional Forward Detection Enhancement
m0152-07 Enhancement to MME Interface Configuration Changes
LM6.0
m30107-03 MME support for QoS mapping
m11005-03 MME support for Access Control list for SBc link
m11005-03 MME Configuration Management Support for Diameter Routing Agent
m10910-01b MME support for Multiple S1 MME Local IP Address
m10418-01 MME Support for VLAN Growth/De-Growth
WMM7
m11501-02 MME support for Extended GTP Echo Timer
m10423-01 MME support of Source Based Routing
m14000-01 MME support of Home eNB and Local IP Address (LIPA)
m11303-01 WMM Support for Enhanced DRA Support
m11301-01 MME Support for Enhanced DPR/DPA
2.2 REFERENCE DOCUMENTS
[R1] TS23.203 Policy and charging control architecture
[R2] TS23.401 GPRS enhancements for E-UTRAN access
[R3] TS29.060 GPRS Tunneling Protocol (GTP) across the Gn & Gp interface
[R4] TS29.274 Tunnelling Protocol for Control plane (GTPv2-C)
[R5] TS29.281 Tunnelling Protocol User Plane (GTPv1-U)
[R6] TS36.104 Base Station Transmission & Reception
[R7] TS36.300 EUTRAN Overall Description Stage 2
[R8] TS36.401 EUTRAN Architecture
[R9] TS36.410 EUTRAN S1 General Aspects & Principles
[R10] TS36.411 EUTRAN S1 Layer 1
[R11] TS36.412 EUTRAN S1 Signalling Transport
[R12] TS36.413 EUTRAN S1-Application Protocol [S1-AP]
[R13] TS36.414 EUTRAN S1 Data Transport
[R14] TS36.420 EUTRAN X2 General Aspects & Principles
[R15] TS36.421 EUTRAN X2 Layer 1
[R16] TS36.422 EUTRAN X2 Signalling Transport

[R17] TS36.423 EUTRN X2-Application Protocol [X1-AP]
[R18] TS36.424 EUTRAN X2 Data Transport
[R19] TS33.210 Network Domain Security (NDS); IP network layer security
[R20] TS 36.444 M3 Application Protocol (M3AP)

Signalling Transport for interfaces supporting Multimedia Broadcast
[R21] TS 36.442
Multicast Service (MBMS) within E-UTRAN
[R22] TS 23.246 MBMS Architecture and functional description
[R23] IETF RFC 0768 User Datagram Protocol (UDP)
[R24] IETF RFC 0791 Internet Protocol (IP)
[R25] IETF RFC 0792 Internet Control Message Protocol (ICMP)
[R26] IETF RFC 0793 Transmission Control Protocol (TCP)
[R27] IETF RFC 0826 Ethernet Address Resolution Protocol (ARP)
[R28] IETF RFC 0879 TCP maximum Segment size (MSS) and related topics
[R29] IETF RFC 0959 File Transfer Protocol (FTP)
[R30] IETF RFC 1191 Path MTU discovery
[R31] IETF RFC 2030 Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI
[R32] IETF RFC 2131 Dynamic Host Configuration Protocol (DHCP)
[R33] IETF RFC 2401 Security Architecture for the Internet Protocol (IPsec overview)
[R34] IETF RFC 2403 The Use of HMAC-MD5-96 within ESP and AH
[R35] IETF RFC 2404 The Use of HMAC-SHA-1-96 within ESP and AH
[R36] IETF RFC 2405 The ESP DES-CBC Cipher Algorithm With Explicit IV
[R37] IETF RFC 2407 The Internet IP Security Domain of Interpretation for ISAKMP
[R38] IETF RFC 2408 Internet Security Association and Key Management Protocol
[R39] IETF RFC 2409 The Internet Key Exchange (IKEv1)
[R40] IETF RFC 2412 The OAKLEY Key Determination Protocol
[R41] IETF RFC 2451 The ESP CBC-Mode Cipher Algorithms
More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key

[R42] IETF RFC 3526
Exchange (IKE)
A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE)
[R43] IETF RFC 3706
Peers
[R44] IETF RFC 2460 Internet Protocol Version 6 (IPv6)
[R45] IETF RFC 2474 Definition of the Differentiated Services Field in the IPv4/v6 Headers

[R46] IETF RFC 2475 An Architecture for Differentiated Service
[R47] IETF RFC 2597 Assured Forwarding PHB Group
[R48] IETF RFC 2597 Assured Forwarding PHB Group
[R49] IETF RFC 2598 An Expedited Forwarding PHB
[R50] IETF RFC 2836 Per Hop Behavior Identification Codes
[R51] IETF RFC 2960 Stream Control Transmission Protocol
[R52] IETF RFC 3046 DHCP Relay Agent Information Option
[R53] IETF RFC 3168 The addition of Explicit Congestion Notification to IP
[R54] IETF RFC 3246 An Expedited Forwarding PHB (Per-Hop Behavior)
[R55] IETF RFC 3247 Supplemental Information for the New Definition of the EF PHB
[R56] IETF RFC 3260 New terminology and clarifications for DiffServ
[R57] IETF RFC 3309 Stream Control Transmission Protocol (SCTP) Checksum Change
[R58] IETF RFC 3315 DHCPv6
[R59] IETF RFC 3442 The Classless Static Route option for DHCPv4
[R60] IETF RFC 3587 IPv6 Global Unicast Address Format
[R61] IETF RFC 4291 IP Version 6 Addressing Architecture
[R62] IETF RFC 4301 Security Architecture for the Internet Protocol
[R63] IETF RFC 4302 IP Authentication Header
[R64] IETF RFC 4303 IP Encapsulating Security Payload

Extended Sequence Number (ESN) Addendum to IPsec Domain of
[R65] IETF RFC 4304 Interpretation (DOI) for Internet Security Association and Key Management
Protocol (ISAKMP)
[R66] IETF RFC 4306 Internet Key Exchange (IKEv2) Protocol
Cryptographic Algorithms for Use in the Internet Key Exchange Version 2

[R67] IETF RFC 4307
(IKEv2)
[R68] IETF RFC 4308 Cryptographic Suites for IPsec
Using Advanced Encryption Standard (AES) CCM Mode with IPsec

[R69] IETF RFC 4309
Encapsulating Security Payload (ESP)
[R70] IETF RFC 4361 Node-specific Client Identifiers for
[R71] IETF RFC 4861 Neighbor Discovery for IP version 6
[R72] IETF RFC 4862 IPv6 Stateless Address Autoconfiguration
[R73] IETF RFC 4903 Multi-Link Subnet Issues

[R74] IETF RFC 4960 Stream Control Transmission Protocol (SCTP)
[R75] IETF RFC 5061 Stream Control Transmission Protocol – Dynamic Address Reconfiguration
[R76] ITU-T G.8261 Timing and Synchronization Aspects in Packet Networks
IEEE Standard for Precision Clock Synchronization Protocol for Networked
[R77] IEEE 1588 v2
measurement & Control Systems
[R78] IETF RFC 5217 Memorandum for Multi-Domain Public Key Infrastructure Interoperability
Internet X.509 Public Key Infrastructure Certificate and Certificate

[R79] IETF RFC 5280 Revocation List (CRL) Profile
Internet X.509 Public Key Infrastructure Certificate Management Protocol

[R80] IETF RFC 4210
(CMP)
Internet X.509 Public Key Infrastructure Certificate Request Message
[R81] IETF RFC 4211
Format (CRMF)
[R82] IETF RFC 2315 PKCS #7: Cryptographic Message Syntax Version 1.5
[R83] IETF RFC 2986 PKCS #10: Certification Request Syntax Specification Version 1.7
[R84] IETF RFC 5217 Memorandum for Multi-Domain Public Key Infrastructure Interoperability
[R85] IETF RFC 5273 Certificate Management over CMS (CMC): Transport Protocols
[R86] IETF RFC 3376 IGMPv3
[R87] IETF RFC 3810 MLDv2
[R88] IETF RFC 4604 Using IGMPv3 and MLDv2 for Source specific Multicast
[R89] IETF RFC 4607 Source-Specific Multicast for IP

3 LTE IP NETWORK TRANSPORT

This chapter covers LTE general aspects. It is not ALU design oriented.
3.1 LTE NETWORK ARCHITECTURE

The figure below provides an overview of a LTE network which is a Packet switched (PS) only system
and is all-IP, because every standardized interface is based on a protocol stack where L3 is IP.
The Evolved Packet System provides IP connectivity between a UE and a PLMN external packet data
network and is referred to as PDN Connectivity Service.
The LTE architecture can be further described as follow:

• The E-UTRAN consists of set of eNodeBs connected to the EPC through the S1.
• eNodeBs can be interconnected through the X2.
• S1 and X2 are logical interfaces.
• The E-UTRAN is layered into a Radio Network Layer (RNL) and a Transport Network Layer (TNL)
which is the scope of this document.
The transport network layer provides services for user plane transport and signalling transport.
GERAN
SGSN HSS
UTRAN
S3 S6a
S1-MME
MME
PCRF
S4 Rx+
S11 S7
S10
“LTE-Uu”
Serving S5 PDN SGi
UE EUTRAN Operator’s IP Services
SAE SAE (e.g. IMS, PSS etc.)
S1-U Gateway Gateway
Figure 1: Overview of LTE network architecture
3.2 LTE/EPS STANDARD REFERENCE POINTS

• S1-MME: Reference point for the control plane protocol between E-UTRAN and MME.
• S1-U: Reference point between E-UTRAN and Serving GW for the per bearer user plane tunnelling
and inter eNodeB path switching during handover.
• S3: It enables user and bearer information exchange for inter-3GPP access network mobility in
idle and/or active state. It is based on Gn reference point as defined between SGSNs.
• S4: It provides related control and mobility support between GPRS Core and the 3GPP Anchor
function of Serving GW and is based on Gn reference point as defined between SGSN and GGSN. In
addition, if Direct Tunnel is not established, it provides the user plane tunnelling.

• S5: It provides user plane tunneling and tunnel management between Serving GW and PDN GW. It
is used for Serving GW relocation due to UE mobility and in case the Serving GW needs to connect to
a non-collocated PDN GW for the required PDN connectivity.
• S6a: This interface is defined between MME and HSS for authentication and authorization.
• S7 (a.k.a Gx): It provides transfer of (QoS) policy and charging rules from PCRF to Policy and
Charging Enforcement Point (PCEF) ) in the PDN GW. S7 & Gx refere to the same interface.
• S8: It is the roaming interface in case of roaming with home routed traffic. It provides the user
plane with related control between Gateways in the VPLMN and HPLMN.
• S10: This interface is reference point between MMEs for MME relocation and MME to MME
information transfer.
• S11: This interface is reference point between MME and Serving GW.
• SGi: Reference point between the PDN-GW and the packet data network. The packet data
network can be a private or public data (IP) network or an intra-operator packet data network, e.g.
for provision of IMS services.
3.3 LTE PROTOCOL STACKS

See [2].
3.3.1 eUTRAN protocol stack
Control Plane User Plane

Radio
Network (S1 or X2)-AP User Plane PDUs
Layer
Transport
Network
Layer
GTP-U
SCTP UDP
IP IP
Data Link Layer Data Link Layer
Physical Layer Physical Layer
Figure 2: eUTRAN Protocol Stack
3.3.2 ePC protocol stack

3.3.2.1 GTPv2-C Control Plane
GTPv2-C is used on the following standardized interfaces:

• SGSN-MME S3
• SGSN-SGW S4
• SGW-PGW S5-S8
• MME-MME S10
• MME-SGW S11
• MME-MBMS GW Sm
GTPv2-C
UDP
IP
Data Link Layer
Physical Layer
3.3.2.2 DIAMETER Control Plane
Diameter is used on the following standardized interfaces:
• MME-HSS S6A
• MME-EIR S13
• PGW-PCRF S7 (Gx)
• MME-GMLC SLg
Diameter
SCTP
IP
Data Link Layer
Physical Layer
3.3.2.3 User Plane
As described in TS 23.401, GTP-U is used on the following standardized interfaces:
• SGW-PGW S5-S8

User Plane
User Plane PDUs
GTP-U
UDP
IP
Data Link Layer
Physical Layer
3.4 LTE PROTOCOLS

3.4.1 SCTP
Stream Control Transmission Protocol is specified in IETF RFC 4960.
SCTP is the choosen protocol to transport control messages between the eNodeB and the MME over
the S1-MME interface and between eNodeB’s over the X2-C interface.
An SCTP association can be uniquely identified by the transport addresses used by the endpoints in
the association. A transport address is unique to an SCTP endpoint and is defined by the
combination of an IP address and an SCTP port number (case of single-homed SCTP endpoint) or by
the combination of multiple IP addresses and an SCTP port number (case of multi-homed SCTP
endpoint).
Example of an SCTP association between a single-homed endpoint and a multi-homed endpoint.

• Local endpoint single-homed transport address is: a.b.c.d & port1
• Peer endpoint multi-homed transport address is: (1.2.3.4; 10.20.30.40) & SCTP port2
The SCTP association is identified by the pair of (a.b.c.d:port1) & (1.2.3.4; 10.20.30.40:port2).
Two SCTP endpoints must not have more than one SCTP association between them at any given
time.
SCTP associations are :
• created through a 4-way handshake procedure (INIT / INITack and Cookie Echo / Cookie ack)

Local Peer
SCTP endpoint SCTP endpoint
INIT start T1-init timer
State Cookie creation with:

- timestamp = t t INIT ACK stop T1-init timer
- lifespan = Valid.Cookie.Life (State Cookie embedded)
t+δt
COOKIE ECHO start T1-cookie timer
(State Cookie sent back)
COOKIE ACK
If (δt ≤ Valid.Cookie.Life) stop T1-cookie timer
If (δt > Valid.Cookie.Life) ERROR

(cause: Stale Cookie Error)
Figure 3: SCTP association establishment
• re-started if either end sends another INIT later
• terminated if either end sends an ABORT
SCTP supports :
• multiple streams, where a packet error in one stream does not delay data in other streams. This
protocol thus addresses the ‘head-of-line’ blocking issues apparent with TCP
• multi-homing, end-points of an SCTP association may have multiple IP addresses allowing

resiliency of using different routes/media between equipments.
Engineering: <SCTP> <Recommended>
The multi-homed IP addresses should be in different subnets.

This secure the SCTP association from a SCTP path failure due to a network failure (e.g. cable cut,
router/switch failure) that brings down that path.

• end-point and path failures detection through heartbeat mechanism
Local Peer
INIT / INIT ACK

COOKIE / COOKIE ACK
Data transfer DATA
Data ack. SACK
HEARTBEAT
HEARTBEAT ACK
Heartbeat timer
HEARTBEAT
Figure 4: SCTP heartbeating
Heartbeat timer = RTO + HB.interval x (1 + δ), with;

RTO is the RTO of the Heartbeat destination address,
δ randomly choosen in between [-0.5; 0.5] at association establishment.
• retransmission mechanism
• acknowledgement mechanism
Rule: <SCTP> <Standard>
As per IETF RFC 4960:

“An acknowledgement SHOULD be generated for at least every second packet (not every second
DATA chunk) received, and SHOULD be generated within 200 ms of the arrival of any
unacknowledged DATA chunk.”
“An implementation MUST NOT allow the maximum delay to be configured to be more than 500
ms.”
In the above extract ‘packet’ stands for ‘SCTP packet’.

Local Peer
start T3-rtx timer

DATA ack delayed start SCTP SACK timer
DATA
X 2 SCTP packets not ack’ed send SACK
SACK & stop SCTP SACK timer
stop T3-rtx timer
DATA ack delayed start SCTP SACK timer

start T3-rtx timer
stop T3-rtx timer SACK & DATA

start T3-rtx timer & stop SCTP SACK timer
ack delayed start SCTP
SACK timer
SCTP SACK timer expiry SACK

X stop T3-rtx timer
send SACK
Figure 5: Delayed SCTP acknowledgement
The purpose of the SACK timer is to reduce the bandwidth consumed by SACK acknowledgments.
The SACK timer defines the time an SCTP endpoint waits before transmitting an acknowledgement
after a DATA chunk has been received from a peer SCTP endpoint. If a second DATA chunk is
received before the timer times out, then the SACK is transmitted immediately. If a second DATA
chunk is not received then the SACK is transmitted at SACK timer expiry.
If the SACK timer is set to 0 then SACK are not delayed.
3.4.1.1 RTO calculation
An SCTP endpoint uses a retransmission timer T3-rtx to ensure data delivery in the absence of any
feedback from its peer. The duration of this timer is referred to as RTO (Retransmission TimeOut).
The RTO is calculated by the SCTP endpoint. When an endpoint’s peer is multi-homed, the endpoint
calculates a separate RTO for each different SCTP path between the two endpoints.
RTO calculation algorithm is specified in IETF RFC 4960. The SCTP protocol parameters used for
calculating the RTO are described hereafter.
3.4.1.1.1 RTO.Min
The RTO.Min parameter defines the minimum time limit for the retransmission timer. It is used to
trigger the retransmission of a Data chunk for which no acknowledgement has been received.
If the calculated RTO is lower than the RTO.Min parameter, the SCTP end-point rounds-up the RTO
value to RTO.Min.
The RTO at one endpoint must not expire before the SACK was sent by the peer endpoint. Else the
peer endpoint retransmits a packet that has been successfully received but not yet acknowledged.,
between two SCTP endpoints, the RTO.Min at an endpoint must be higher than the SACK timer value
at its peer.

Engineering: <SCTP> <Recommended>
To prevent unnecessary retransmissions the RTO.Min at an endpoint must be higher than the round-
trip delay to the peer endpoint + the SACK timer duration at the peer endpoint.
If the RTO.Min timer is set much larger then unnecessary latency is introduced in the SCTP data
transfer, as SCTP retransmissions are triggered later than necessary.
3.4.1.1.2 RTO.Max
The RTO.Max parameter defines the maximum time limit for the retransmission timer. It is used to
trigger the retransmission of Data chunk for which no acknowledgement has been received.
The RTO is doubled each time the SACK acknowledgment is not received in the RTO. If the
calculated RTO is greater than the RTO.Max parameter, the SCTP end-point rounds-down the RTO
value to RTO.Max.
The RTO.Max value must be set higher than RTO.Min.
3.4.1.1.3 RTO.Init
RTO.Init is the RTO for the INIT messages.

The RTO.Init should be set equal to or greater than RTO.Min. It is acceptable to set RTO.Init greater
than the RTO.Max. RTO.Init is used to define retransmission time for INIT messages until peer has
sent the first ACK, after which the RTT value in the retransmission is initialized and the RTO is then
checked against RTO.Min & RTO.Max. The INIT retransmissions are not subjected to doubling of RTO
time. RTO.Init is constant, and thus should be set to a value which is guaranteed to be longer than
the time taken for INIT_ACK to be received in response to INIT transmission.
3.4.1.1.4 RTO.Alpha & RTO.Beta
RTO.Alpha and RTO.Beta are constants that are part of the algorithm for updating the RTO value.
RTO_Alpha_divisor_exponent
RTO.Alpha may be expressed in the format of 1/RTO_Alpha_divisor or 1/2 .
Same applies for RTO.Beta.
E.g. with RFC default values;
RTO.Alpha = 1/8 may be expressed with RTO_Alpha_divisor = 8 or RTO_Alpha_divisor_exponent = 3.
RTO.Beta = 1/4 may be expressed with RTO_Alpha_divisor = 4 or RTO_Alpha_divisor_exponent = 2.
3.4.1.1.5 SCTP path failure detection time
RTO.Min and RTO.Max setting impacts the SCTP path failure detection duration.
Rule: <SCTP> <Standard>
As per RTO calculation algorithm specified by IETF RFC 4960:

The maximum duration before SCTP reports that a SCTP path is down is:
Path.Max.Re trans  n 
∑ min  2 × RTO.Min; RTO.Max 
n=0  
With the RFC 4960 default recommended setting, the maximum duration before SCTP reports that a
SCTP path is down is:
RTO.Min= 1s / RTO.Max=60s / Path.Max.Retrans=5 => 1+2+4+8+16+32=63s

The first packet transmission failure has RTO = RTO.Min = 1s, the first retransmission has RTO = 2s,
the fifth retransmission has RTO = 32s
This aggregate time is a considerable time to detect a failure of a path and invoke a switchover to
an alternate path in a multi-homed environment. Potentially, the association could be torn-down
before a switchover is invoked.
Note: From here to the end of this chapter, the text is extracted from the SCTP specification [IETF
RFC 4960].
3.4.1.2 SCTP packet format
0-7 8 - 15 16 - 23 24 - 31 bits
Source Port Number Destination Port Number

Verification Tag
Checksum
Type Flags Length e.g. 1 = INIT

Value
...
Type Flags Length
Value
Figure 6: SCTP message structure
Source Port Number: This is the SCTP sender’s port number.
Destination Port Number: This is the SCTP port number to which this packet is destined. The
receiving host will use this port number to de-multiplex the SCTP packet to the correct receiving
endpoint/application.
Verification Tag: The receiver of this packet uses the Verification Tag to validate the sender of this
SCTP packet. On transmit, the value of this Verification Tag MUST be set to the value of the Initiate
Tag received from the peer endpoint during the association initialization
Checksum: This field contains the checksum of this SCTP packet. SCTP uses the CRC32c algorithm
for calculating the checksum.
Chunk Type: This field identifies the type of information contained in the Chunk Value field. It takes
a value from 0 to 254. The value of 255 is reserved for future use as an extension field.
The values of Chunk Types are defined as follows:
ID Value Chunk Type Abbreviation

0 Payload Data DATA
1 Initiation INIT
2 Initiation Acknowledgement INIT ACK
3 Selective Acknowledgement SACK
4 Heartbeat Request HEARTBEAT

ID Value Chunk Type Abbreviation

5 Heartbeat Acknowledgement HEARTBEAT ACK
6 Abort ABORT
7 Shutdown SHUTDOWN
8 Shutdown Acknowledgement SHUTDOWN ACK
9 Operation Error ERROR
10 State Cookie COOKIE ECHO
11 Cookie Acknowledgement COOKIE ACK
12 Reserved for Explicit Congestion Notification Echo ECNE
13 Reserved for Congestion Window Reduced CWR
14 Shutdown Complete SHUTDOWN COMPLETE
15 to 62 available
63 reserved for IETF
64 to 126 available
128 to 190 available
192 to 254 available
Chunk Flags: The usage of these bits depends on the Chunk type as given by the Chunk Type field.
Unless otherwise specified, they are set to 0 on transmit and are ignored on receipt.
Chunk Length: This value represents the size of the chunk in bytes, including the Chunk Type, Chunk
Flags, Chunk Length and Chunk Value fields.
Chunk Value: The Chunk Value field contains the actual information to be transferred in the chunk.
The usage and format of this field is dependent on the Chunk Type.
Chunk values of SCTP control chunks consist of a chunk-type-specific header of required fields,
followed by zero or more parameters.
The optional and variable-length parameters contained in a chunk are defined in a Type-Length-
Value format:
0-7 8 - 15 16 - 23 24 - 31 bits
Parameter Type Parameter Length
Parameter Value
3.4.1.2.1 SCTP INIT Chunk
This chunk is used to initiate an SCTP association between two endpoints.

0-7 8 - 15 16 - 23 24 - 31 bits
Type = 1 Flags Length 1 = INIT
Initiate Tag
Advertised Receiver Window Credit
Number of Number of
Outbound Streams Inbound Streams
Initial TSN
Optional/Variable-Length Parameters
Figure 7: SCTP INIT format
Initiate Tag: The receiver of the INIT (the responding end) records the value of the Initiate Tag
parameter. This value MUST be placed into the Verification Tag field of every SCTP packet that the
receiver of the INIT transmits within this association.
Advertised Receiver Window Credit: This value represents the dedicated buffer space, in number of
bytes, the sender of the INIT has reserved in association with this window.
Number of Outbound Streams (OS): Defines the number of outbound streams the sender of this INIT
chunk wishes to create in this association.
Number of Inbound Streams (MIS): Defines the maximum number of streams the sender of this INIT
chunk allows the peer end to create in this association.
Note: There is no negotiation of the actual number of streams but instead the two endpoints will
use the min(requested, offered).
Initial TSN: Defines the initial TSN that the sender will use. The valid range is from 0 to 4294967295.
Optional/Variable-Length Parameters in INIT:
IPv4 Address: Contains an IPv4 address of the sending endpoint.
0-7 8 - 15 16 - 23 24 - 31 bits
Type = 5 Length = 8
IPv4 address

IPv6 Address: Contains an IPv6 [IETF RFC 2460] address of the sending endpoint.
0-7 8 - 15 16 - 23 24 - 31 bits
Type = 6 Length = 20
IPv6 address
IPv6 address cont’d
Combined with the Source Port Number in the SCTP common header, the value passed in an IPv4 or
IPv6 Address parameter indicates a transport address the sender of the INIT will support for the
association being initiated. That is, during the life time of this association, this IP address can
appear in the source address field of an IP datagram sent from the sender of the INIT, and can be
used as a destination address of an IP datagram sent from the receiver of the INIT.
More than one IP Address parameter can be included in an INIT chunk when the INIT sender is multi-
homed. Moreover, a multihomed endpoint may have access to different types of network; thus,
more than one address type can be present in one INIT chunk, i.e., IPv4 and IPv6 addresses are
allowed in the same INIT chunk.
If the INIT contains at least one IP Address parameter, then the source address of the IP datagram
containing the INIT chunk and any additional address(es) provided within the INIT can be used as
destinations by the endpoint receiving the INIT. If the INIT does not contain any IP Address
parameters, the endpoint receiving the INIT MUST use the source address associated with the
received IP datagram as its sole destination address for the association.
Supported Address Types: The sender of INIT uses this parameter to list all the address types it can
support.
0-7 8 - 15 16 - 23 24 - 31 bits
Type = 12 Length
Address Type #1 Address Type #2
...
Address Type: This is filled with the type value of the corresponding address TLV (e.g., IPv4 = 5,
IPv6 = 6, Host name = 11).
3.4.1.2.2 SCTP INIT ACK Chunk
The INIT ACK chunk is used to acknowledge the initiation of an SCTP association.
The parameter part of INIT ACK is formatted similarly to the INIT chunk. It uses two extra variable
parameters: the State Cookie and the Unrecognized Parameter.
3.4.1.2.3 SCTP SACK Chunk

The Selective Acknowledgement chunk is sent to the peer endpoint to acknowledge received DATA
chunks and to inform the peer endpoint of gaps in the received subsequences of DATA chunks as
represented by their TSNs.
3.4.1.2.4 SCTP HEARTBEAT Chunk
An endpoint should send this chunk to its peer endpoint to probe the reachability of a particular
destination transport address defined in the present association.
The parameter field contains the Heartbeat Information, which is a variable-length opaque data
structure understood only by the sender.
3.4.1.2.5 SCTP HEARTBEAT ACK Chunk
An endpoint should send this chunk to its peer endpoint as a response to a HEARTBEAT chunk. A
HEARTBEAT ACK is always sent to the source IP address of the IP datagram containing the
HEARTBEAT chunk to which this ack is responding.
The parameter field contains the Heartbeat Information parameter of the Heartbeat Request to
which this Heartbeat Acknowledgement is responding.
3.4.1.2.6 SCTP Payload DATA Chunk
0-7 8 - 15 16 - 23 24 - 31 bits
Type = 0 Reserved U B E Length 0 = DATA
TSN
Stream Identifier S Stream Sequence Number n
Payload Protocol Identifier
User Data (seq n of stream S)
U bit: The (U)nordered bit, if set to ’1’, indicates that this is an unordered DATA chunk, and there is
no Stream Sequence Number assigned to this DATA chunk.
B bit: The (B)eginning fragment bit, if set, indicates the first fragment of a user message.
E bit: The (E)nding fragment bit, if set, indicates the last fragment of a user message.
B & E bits Description
1&0 First piece of a fragmented user message
0&0 Middle piece of a fragmented user message
0&1 Last piece of a fragmented user message
1&1 Unfragmented message
Length: This field indicates the length of the DATA chunk in bytes from the beginning of the type
field to the end of the User Data field excluding any padding.

TSN: This value represents the Transmission sequence number for this DATA chunk. When a user
message is fragmented into multiple chunks, the TSNs are used by the receiver to reassemble the
message. The valid range of TSN is from 0 to 4294967295.
Stream Identifier S: Identifies the stream to which the following user data belongs.
Stream Sequence Number n: This value represents the Stream Sequence Number of the following
user data within the stream S. Valid range is 0 to 65535.
When a user message is fragmented by SCTP for transport, the same Stream Sequence Number MUST
be carried in each of the fragments of the message.
Payload Protocol Identifier: This value represents an application (or upper layer) specified protocol
identifier. This value is passed to SCTP by its upper layer and sent to its peer. This identifier is not
used by SCTP but can be used by certain network entities, as well as by the peer application, to
identify the type of information being carried in this DATA chunk.
User Data: This is the payload user data
3.4.1.3 Retransmission timer
An SCTP endpoint uses a retransmission timer T3-rtx to ensure data delivery in the absence of any
feedback from its peer. The duration of this timer is referred to as RTO (retransmission timeout).
When an endpoint’s peer is multi-homed, the endpoint will calculate a separate RTO for each
different destination transport address of its peer endpoint.
3.4.1.4 Fault Management
3.4.1.4.1 Heartbeating
By default, an SCTP endpoint SHOULD monitor the reachability of the idle destination transport
address(es) of its peer by sending a HEARTBEAT chunk periodically to the destination transport
address(es).
A destination transport address is considered "idle" if no new chunk that can be used for updating
path RTT (usually including first transmission DATA, INIT, COOKIE ECHO, HEARTBEAT, etc.) and no
HEARTBEAT has been sent to it within the current heartbeat period of that address. This applies to
both active and inactive destination addresses.
On an idle destination address that is allowed to heartbeat, it is recommended that a HEARTBEAT
chunk is sent once per RTO of that destination address plus the protocol parameter ’HB.interval’,
with jittering of +/- 50% of the RTO value, and exponential backoff of the RTO if the previous
HEARTBEAT is unanswered.

Local Peer
Association establishment
INIT / INIT ACK
Primary path = IP@1
Alternate path = IP@2 COOKIE / COOKIE ACK
Data transfer DATA to/from IP@1
Data ack. SACK to/from IP@1
HEARTBEAT to/from IP@1
HEARTBEAT ACK to/from IP@1

Heartbeat timer
HEARTBEAT
Figure 8: SCTP heartbeating and peer multi-homed
3.4.1.4.2 Association Initiation Failure
If the T1-init timer expires, the endpoint MUST retransmit INIT and restart the T1-init timer without
changing state. This MUST be repeated up to ’Max.Init.Retransmits’ times. After that, the endpoint
MUST abort the initialization process and report the error to the SCTP user.
If the T1-cookie timer expires, the endpoint MUST retransmit COOKIE ECHO and restart the T1-
cookie timer without changing state. This MUST be repeated up to ’Max.Init.Retransmits’ times.
After that, the endpoint MUST abort the initialization process and report the error to the SCTP user.

Local Peer
INIT #1
Start T1-init timer
INIT #2
Start T1-init timer
...
INIT #Max.Init.Retransmits
Start T1-init timer
T1-init timer expiry X
Figure 9: Association establishment failure
3.4.1.4.3 Association Failure
An endpoint shall keep a counter on the total number of consecutive retransmissions to its peer
(this includes retransmissions to all the destination transport addresses of the peer if it is multi-
homed), including unacknowledged HEARTBEAT chunks. If the value of this counter exceeds the
limit indicated in the protocol parameter 'Association.Max.Retrans', the endpoint shall consider the
peer endpoint unreachable and shall stop transmitting any more data to it (and thus the association
enters the CLOSED state).
The counter shall be reset each time a DATA chunk sent to that peer endpoint is acknowledged (by
the reception of a SACK) or a HEARTBEAT ACK is received from the peer endpoint.

Local Peer
INIT / INIT ACK

Association establishment
COOKIE / COOKIE ACK
Start T3-rtx timer DATA
SACK
RTO X Data and/or Data ack.
DATA
T3-rtx timer expires X Error counter is incremented
HEARTBEAT
RTO HEARTBEAT ACK

X
Heartbeat timer expires X Error counter is incremented
...
Error counter exceeds

X
Association.Max.Retrans
Figure 10: SCTP association failure
3.4.1.4.4 Path Failure
When its peer endpoint is multi-homed, an endpoint should keep an error counter for each of the
destination transport addresses of the peer endpoint.
Each time the T3-rtx timer expires on any address, or when a HEARTBEAT sent to an idle address is
not acknowledged within an RTO, the error counter of that destination address will be incremented.
When the value in the error counter exceeds the protocol parameter 'Path.Max.Retrans' of that
destination address, the endpoint should mark the destination transport address as inactive, and a
notification SHOULD be sent to the upper layer.
When an outstanding TSN is acknowledged or a HEARTBEAT sent to that address is acknowledged
with a HEARTBEAT ACK, the endpoint shall clear the error counter of the destination transport
address to which the DATA chunk was last sent (or HEARTBEAT was sent).
When the primary path is marked inactive (due to excessive retransmissions, for instance), the
sender MAY automatically transmit new packets to an alternate destination address if one exists and
is active. If more than one alternate address is active when the primary path is marked inactive,
only ONE transport address SHOULD be chosen and used as the new destination transport address.

Peer
eNodeB SCTP endpoint
Association establishment INIT / INIT ACK

Primary path = IP@1
Alternate path = IP@2 COOKIE / COOKIE ACK
Start T3-rtx timer DATA to IP@1
SACK
RTO X Data and/or Data ack.
DATA
T3-rtx timer X Error counter is incremented
expires for primary path
HEARTBEAT to IP@1
RTO HEARTBEAT ACK

X
Heartbeat timer expires X Error counter is incremented
for primary path
...
X Error counter for primary path

exceeds Path.Max.Retrans
IP@1 is considered an inactive
destination transport address
Figure 11: SCTP association failure and peer multi-homed
3.4.1.5 Peer Multi-Homing
An SCTP endpoint is considered multi-homed if there are more than one transport address that can
be used as a destination address to reach that endpoint.
Moreover, the Upper Layer Protocol of an endpoint shall select one of the multiple destination
addresses of a multi-homed peer endpoint as the primary path.
By default, an endpoint SHOULD always transmit to the primary path, unless the SCTP user explicitly
specifies the destination transport address (and possibly source transport address) to use.
The association Path MTU is the smallest Path MTU of all destination addresses.
When retransmitting data that timed out, if the endpoint is multihomed, it should consider each
source-destination address pair in its retransmission selection policy.

DATA Chunk
or
Heartbeat Chunk
sent to peer
primary path
DATA ack’ed ?
or
Heartbeat Ack received ?
NO YES
Increment error counter Reset error

for primary path counter for
primary path
Error counter for

primary path is ≥
‘Path.Max.Retrans’ ?
NO YES
For DATA retransmission Primary path becomes

an alternate active inactive.
destination @ is used. An alternate active
destination @ is used.
Figure 12: SCTP path failure and peer multi-homed
3.5 DIAMETER
Diameter is an Authentication, Authorization and Accounting (AAA) protocol.
A complete description of the Diameter application is the beyond the scope of this document.
However a brief description of Diameter is presented in the following.
The Diameter base protocol is defined by IETF RFC 3588, and defines the minimum requirements for
an AAA protocol. Diameter Applications can extend the base protocol, by adding new commands
and/or attributes.
AAA is a way of checking user access to a network:

• Authentication: verify the user identity (e.g. user identification with a password).
• Authorization: verify what the user is allowed to do (e.g. which services with which QoS).
• Accounting: bill according to criterion (e.g. time, data volume, application used).
The Diameter protocol consists of a header followed by one or more Attribute-Value Pairs (AVPs).
An AVP includes a header and is used to encapsulate protocol-specific data (e.g. routing
information) as well as AAA information. A Diameter Application reuses the basic mechanisms

defined by the diameter base protocol and it defines additional commands and AVPs to support
specific procedures.
3.5.1 Diameter packet format
0-7 8 - 15 16 - 23 24 - 31 bits
Version Message Length
R P E T Command Code
Application ID
Hop-by-Hop ID
End-to-End ID
AVPs
...
Figure 13: Diameter packet structure
R bit: The Request bit, if set, indicates the message is a request. Else the message is an answer.
P bit: The Proxiable bit, if set, indicates the message MAY be proxied, relayed or redirected. Else
the message MUST be locally processed.
E bit: The Error bit, if set, indicates the message contains a protocol error, and the message will not
conform to the ABNF described for this command. This bit MUST NOT be set in request messages.
T bit: The potentially re-Transmitted message bit, is set after a link failover procedure, to aid the
removal of duplicate requests. It is set when resending requests not yet acknowledged, as an
indication of a possible duplicate due to a link failure.
Command Code: Each command is assigned a command code allocated by IANA.
The values of Diameter Commands Code are defined as follows:
Code Command Name Abbreviation

0 to 255 reserved for RADIUS backward compatibility
265 AA-Request AAR
265 AA-Answer AAA
268 Diameter-EAP-Request DER
268 Diameter-EAP-Answer DEA
274 Abort-Session-Request ASR
274 Abort-Session-Answer ASA
271 Accounting-Request ACR
271 Accounting-Answer ACA
272 Credit-Control-Request CCR
272 Credit-Control-Answer CCA


257 Capabilities-Exchange-Request CER
257 Capabilities-Exchange-Answer CEA
280 Device-Watchdog-Request DWR
280 Device-Watchdog-Answer DWA
282 Disconnect-Peer-Request DPR
282 Disconnect-Peer-Answer DPA
258 Re-Auth-Request RAR
258 Re-Auth-Answer RAA
275 Session-Termination-Request STR
275 Session-Termination-Answer STA
300 User-Authorization-Request UAR
300 User-Authorization-Answer UAA
301 Server-Assignment-Request SAR
301 Server-Assignment-Answer SAA
302 Location-Info-Request LIR
302 Location-Info-Answer LIA
303 Multimedia-Auth-Request MAR
303 Multimedia-Auth-Answer MAA
304 Registration-Termination-Request RTR
304 Registration-Termination-Answer RTA
305 Push-Profile-Request PPR
305 Push-Profile-Answer PPA
306 User-Data-Request UDR
306 User-Data-Answer UDA
307 Profile-Update-Request PUR
307 Profile-Update-Answer PUA
308 Subscribe-Notifications-Request SNR
308 Subscribe-Notifications-Answer SNA
309 Push-Notification-Request PNR
309 Push-Notification-Answer PNA
310 Bootstrapping-Info-Request BIR
310 Bootstrapping-Info-Answer BIA
311 Message-Process-Request MPR
311 Message-Process-Answer MPA
16777214 & reserved for experimental and testing purposes


16777215
Attribute-Value Pair (AVP):
0-7 8 - 15 16 - 23 24 - 31 bits
AVP Code
V M P AVP Length
Vendor ID (optional)
Data
...
Figure 14: Diameter Attribute-Value Pair
V bit: The Vendor-Specific bit, indicates whether the optional ‘Vendor ID’ field is present in the AVP
header. When set the AVP Code belongs to the specific vendor code address space.
M bit: The Mandatory bit, indicates whether support of the AVP is required. If an AVP with the M bit
set is received by a Diameter client, server, proxy, or translation agent and either the AVP or its
value is unrecognized, the message MUST be rejected. Diameter Relay and redirect agents MUST
NOT reject messages with unrecognized AVPs.
P bit: The Protected bit, indicates the need for encryption for end-to-end security.
The values of AVPs Code are defined as follows:
AVP Code Attribute Name AVP Code Attribute Name

85 Acct-Interim-Interval 267 Firmware-Revision
483 Accounting-Realtime-Required 257 Host-IP-Address
50 Acct-Multi-Session-Id 299 Inband-Security-Id
485 Accounting-Record-Number 272 Multi-Round-Time-Out
480 Accounting-Record-Type 264 Origin-Host
44 Accounting-Session-Id 296 Origin-Realm
287 Accounting-Sub-Session-Id 278 Origin-State-Id
259 Acct-Application-Id 269 Product-Name
258 Auth-Application-Id 280 Proxy-Host
274 Auth-Request-Type 284 Proxy-Info
291 Authorization-Lifetime 33 Proxy-State
276 Auth-Grace-Period 292 Redirect-Host
277 Auth-Session-State 261 Redirect-Host-Usage
285 Re-Auth-Request-Type 262 Redirect-Max-Cache-Time
25 Class 268 Result-Code
293 Destination-Host 282 Route-Record

AVP Code Attribute Name AVP Code Attribute Name

283 Destination-Realm 263 Session-Id
273 Disconnect-Cause 27 Session-Timeout
300 E2E-Sequence 270 Session-Binding
281 Error-Message 271 Session-Server-Failover
294 Error-Reporting-Host 265 Supported-Vendor-Id
55 Event-Timestamp 295 Termination-Cause
297 Experimental-Result 1 User-Name
298 Experimental-Result-Code 266 Vendor-Id
279 Failed-AVP 260 Vendor-Specific-Application-Id
3.5.2 Diameter message flows

The communication between two diameter peers starts with the establishment of a transport
connection (TCP or SCTP). The initiator then sends a Capabilities-Exchange-Request (CER) to the
other peer, which responds with a Capabilities-Exchange-Answer (CEA).
The connection is then ready for exchanging application messages. If no messages have been
exchanged for some time either side may send a Device-Watchdog-Request (DWR) and the other
peer must respond with Device-Watchdog-Answer. Either side may terminate the communication by
sending a Disconnect-Peer-Request (DPR) which the other peer must respond to with Disconnect-
Peer-Answer. After that the transport connection can be disconnected.
Local Peer
endpoint endpoint
TCP or SCTP Transport connection

establishment
CER
Diameter setup
CEA
Diameter messages
DWR
Diameter heartbeat
DWA
DPR
Diameter disconnect
DPA
Transport connection
disconnect
Figure 15: Diameter message flows

4 LTE E2E PERFORMANCE & QOS FUNCTIONS

4.1 OVERVIEW OF LTE E2E QOS

Network Services are considered end-to-end, this means from a Terminal Equipment (TE) to another
TE. An End-to-End Service may have a certain Quality of Service (QoS) which is provided for the user
of a network service. It is the user that decides whether he is satisfied with the provided QoS or
not.
To realise a certain network QoS, a Bearer Service with clearly defined characteristics and
functionality is to be set up from the source to the destination of a service.
A bearer service includes all aspects to enable the provision of a contracted QoS. These aspects are
among others the control signalling, user plane transport and QoS management functionality. An EPS
bearer service layered architecture is depicted, each bearer service on a specific layer offers its
individual services using services provided by the layers below.
Application
end-to-end QoS
LTE network QoS
end-to-end QoS
(SAE bearer QoS) Control
eUTRAN QoS: and
- SAE RB QoS
- S1U/X2U QoS Management
eUTRAN Phys QoS:

- LTE-Uu QoS
- Transport QoS
eUTRAN QoS EPC QoS
Figure 16: EPS bearer service layered architecture
An EPS bearer/E-RAB is the level of granularity for bearer level QoS control in the EPC/E-UTRAN.
One EPS bearer/E-RAB is established when the UE connects to a PDN, and that remains established
throughout the lifetime of the PDN connection to provide the UE with always-on IP connectivity to
that PDN. That bearer is referred to as the default bearer. Any additional EPS bearer/E-RAB that is
established to the same PDN is referred to as a dedicated bearer. The initial bearer level QoS
parameter values of the default bearer are assigned by the network, based on subscription data.
The decision to establish or modify a dedicated bearer can only be taken by the EPC, and the bearer
level QoS parameter values are always assigned by the EPC.
An EPS bearer/E-RAB is referred to as a GBR bearer if dedicated network resources related to a
Guaranteed Bit Rate (GBR) value that is associated with the EPS bearer/E-RAB are permanently
allocated (e.g. by an admission control function in the eNodeB) at bearer
establishment/modification. Otherwise, an EPS bearer/E-RAB is referred to as a Non-GBR bearer. A

dedicated bearer can either be a GBR or a Non-GBR bearer while a default bearer shall be a Non-
GBR bearer.
Each EPS bearer can have one or more Service Data Flow (SDFs). These SDFs share the same QoS
treatment and performance characteristics for that bearer
4.2 BEARER QOS PARAMETERS

The bearer level (i.e. per bearer or per bearer aggregate) QoS parameters are QCI, ARP, GBR, and
AMBR.
Each EPS bearer/E-RAB (GBR and Non-GBR) is associated with the following bearer level QoS
parameters:
• QoS Class Identifier (QCI): value used to index node-specific parameters that control bearer level
packet forwarding treatment (e.g. scheduling, admission control, queuing, link layer protocol
configuration (ARQ and HARQ), etc.).
• Allocation and Retention Priority (ARP): the primary purpose of ARP is to decide whether a
bearer establishment / modification request can be accepted or needs to be rejected in case of
resource limitations. In addition, the ARP can be used by the eNodeB to decide which bearer(s) to
drop during exceptional resource limitations (e.g. at handover).
Each GBR bearer is additionally associated with the following bearer level QoS parameter:
• Guaranteed Bit Rate (GBR): the bit rate that can be expected to be provided by a GBR bearer.
Each APN access, by a UE, is associated with the following QoS parameter:
• per APN Aggregate Maximum Bit Rate (APN-AMBR).
Each UE is associated with the following bearer aggregate level QoS parameter:
• per UE Aggregate Maximum Bit Rate (UE-AMBR): the upper limit of the sum of the rates of all the
Non-GBR bearers for a UE.
The GBR denotes bit rate of traffic per bearer while UE-AMBR/APN-AMBR denote bit rate of traffic
per group of bearers. Each of those QoS parameters has an uplink and a downlink component.
The standardized QCI label characteristics describe the packet forwarding treatment through the
network based on the following parameters:
• Resource Type (GBR or non-BR)
• Priority (= ARP)
• Packet Delay Budget (PDB)
• Packet Error Loss Rate (PLR)
A label definition has a per node (e.g. eNodeB) meaning.

Standardized QCI Characteristics from 3GPP TS 23.203 “Policy and Charging Control Architecture”
are described in table below:
Packet
Packet
Resource Delay
QCI Priority Error Loss Example Services
Type Budget
Rate
(Note 1)
1 2 100 ms 10-2 Conversational Voice
2 4 150 ms 10-3 Conversational Video (Live Streaming)
3 GBR 3 50 ms 10-3 Real Time Gaming
Non-Conversational Video (Buffered
4 5 300 ms 10-6
Streaming)
5 1 100 ms 10-6 IMS Signalling
Video (Buffered Streaming), TCP-based
6 6 300 ms 10-6 (e.g., www, e-mail, chat, ftp, p2p file
sharing, progressive video, etc.)
Non-GBR Voice,Video (Live Streaming),
7 7 100 ms 10-3
Interactive Gaming
8 8 300 ms 10-6 Video (Buffered Streaming)
TCP-based (e.g., www, e-mail, chat,
9 9 ftp, p2p file sharing, progressive video,
etc.)
NOTE 1: A delay of 20 ms for the delay between a PCEF and a radio base station should be
subtracted from a given PDB to derive the packet delay budget that applies to the radio
interface. This delay is the average between the case where the PCEF is located "close" to the
radio base station (roughly 10 ms) and the case where the PCEF is located "far" from the radio
base station, e.g. in case of roaming with home routed traffic (the one-way packet delay
between Europe and the US west coast is roughly 50 ms). The average takes into account that
roaming is a less typical scenario. It is expected that subtracting this average delay of 20 ms from
a given PDB will lead to desired end-to-end performance in most typical cases. Also, note that the
PDB defines an upper bound. Actual packet delays - in particular for GBR traffic - should typically
be lower than the PDB specified for a QCI as long as the UE has sufficient radio channel quality.
Table 2: Standardized QoS characteristics

The “Standardized QCI characteristics” defines packet delay and packet loss rate per QCI at access
side from UE to PCEF (Policy and Charging Enforcement Function, in the PDN GW). Jitter is not
addressed by this 3GPP standard.
The 3GPP assumption is that delay from eNodeB to PDN GW should be in average of 20 ms (with
min=10ms and max=50ms).
The goal of standardizing QCI characteristics is to ensure the same minimum level of QoS :
• In multi-vendor network deployments
• In case of roaming
4.3 E2E FLOW BINDING

The present chapter aims at capturing how traffic flows and their QoS requirements are handled in
the system:

• An UL TFT (Traffic Flow Template or packet filter) in the UE binds an SDF to an EPS bearer in the
uplink direction. Multiple SDFs can be multiplexed onto the same EPS bearer by including multiple
uplink packet filters in the UL TFT.
• A DL TFT in the PDN GW binds an SDF to an EPS bearer in the downlink direction. Multiple SDFs
can be multiplexed onto the same EPS bearer by including multiple downlink packet filters in the DL
TFT.
• An E-RAB transports the packets of an EPS bearer between the UE and the EPC. When an E-RAB
exists, there is a one-to-one mapping between this E-RAB and an EPS bearer.
• A data radio bearer transports the packets of an EPS bearer between a UE and an eNodeB. When
a data radio bearer exists, there is a one-to-one mapping between this data radio bearer and the
EPS bearer/E-RAB.
• An S1 bearer transports the packets of an E-RAB between an eNodeB and a Serving GW.
• An S5/S8 bearer transports the packets of an EPS bearer between a Serving GW and a PDN GW.
• A UE stores a mapping between an uplink packet filter and a data radio bearer to create the
binding between an SDF and a data radio bearer in the uplink.
• A PDN GW stores a mapping between a downlink packet filter and an S5/S8a bearer to create the
binding between an SDF and an S5/S8a bearer in the downlink.
• An eNodeB stores a one-to-one mapping between a data radio bearer and an S1 bearer to create
the binding between a data radio bearer and an S1 bearer in both the uplink and downlink.
• A Serving GW stores a one-to-one mapping between an S1 bearer and an S5/S8a bearer to create
the binding between an S1 bearer and an S5/S8a bearer in both the uplink and downlink.

Application
Application/Service layer level
UL Service
Data Flows
DL Service
Data Flows
Service 1
UL packet (e.g. Internet-access) DL packet
filtering filtering
Service 2
(e.g. P2P file sharing)
UL packet DL packet Service
filtering filtering data flow
level
Default EPS bearer (e.g. for BE traffic)
Radio bearer S1 bearer S5 bearer
Dedicated EPS bearer (e.g. for SIP/SDP signalling)

Radio bearer S1 bearer S5 bearer
Bearer
level
Service 3
(e.g. SIP/DSP signaling)
Terminal eNB S-GW P-GW
Figure 17: E2E traffic flows and their QoS requirements
4.4 E2E QOS FUNCTIONS AND MAPPING TO LTE NETWORK ELEMENTS

The end to end QOS functions are performed at four levels; Ue , eNodeB , ePC and the transport
infrastructure level, The figure below resume the main QOS functions which should be assured to
guarantee efficiency when carrying the user data and the control traffic across the LTE network.

Figure 18: Main QOS functions and mapping on LTE NE
Terminal eNB MME Backhauling S-GW P-GW

Packet
inspection
UL+DL packet Functions
flow policing at packet flow level
Radio DL packet
admission filtering
UL packet ARP Network
filtering preemption admission
DL rate
policing ARP
UL rate preemption
policing
UL+DL
scheduling Functions
L1/L2 UL/DL rate at bearer level
configuration policing
Radio
congestion
QCI-to-DSCP DL transport QCI-to-DSCP

QoS control Mapping
Mapping admission?
UL transport Functions
admission at transport level
Transport
congestion
UL traffic
shapping
Figure 19: QOS functions per level
4.5 TRANSPORT QOS

Transport network QoS controls apply to every network node in the end-to-end data flow path,
including LTE nodes, transport routers, switches, and access concentrators/aggregators to ensure
consistent end-to-end QoS behaviour. Key element to define the behaviour when there is a grow
of traffic or an evolution of the network is to determine the traffic modelling, traffic engineering
and monitoring information which guarantee to ensure proper QoS control, and an efficient usage
of the bandwidth .
The QOS parameter defined at the transport layers (Layer 2 and Layer 3) are the following:
• DiffServ dimensioning/control
Ensure proper node resource allocation/reservation for DSCP flow PHB performance guarantee
Remarking/dropping per DiffServ specifications
• IP QoS to L2 mapping
Ensure IP QoS support/interworking with transport schemes
Ethernet, IPoA (legacy) and PoS transport support
• Traffic management
Conventional traffic engineering to ensure efficient bandwidth usage and QoS
Traffic policing to enforce GBR, MBR and AMBR compliance
Traffic shaping to compensate GBR, MBR and AMBR variation/jitter
• MPLS
Prevailing backbone transport scheme
eNodeB to interwork with edge router
Largely operator independent, especially when provided by the third party
4.5.1 Traffic Management functions

Traffic management mechanisms involve four steps starting from the classification of the traffic,
marking, conditioning of traffic (shaping and policing) and at the end queuing of traffic (scheduling
and dropping).
Figure 20: QOS Function
Most QoS mechanisms include some type of classification but only a small number of mechanisms
also include marking capability.
Classification:
Classification is the term used for identifying a Behavior Aggregate to which a packet belongs. A
Behavior Aggregate is a collection of flows requiring the same Quality of service.
Marking:
Marking is the term used for coloring packets by applying a class-identifying Value to one of the
following markers: IP precedence, DSCP, QoS group (value is local to a router), MPLS experimental

bits (can be used only in MPLS-enabled networks), ATM CLP bit (value can be used only within ATM
networks), Frame Relay DE bit (value can be used only within Frame Relay networks), IEEE 802.1q.
Traffic shaping:
The purpose of traffic shaping is to control the rate at which packets are sent out of an interface,
while preventing packet loss.
The key benefit of traffic shaping is that packet buffering, rather than packet drop, is used to
achieve rate control. This is a crucial difference when dealing with drop-sensitive applications.
There is also a potential downside to shaping, however, because shaping is accomplished through
buffering, which introduces delay. Delay-sensitive traffic should not be shaped, unless the potential
impact is fully understood and acceptable in the environment.
Traffic policing:
The purpose of the policer is to control the amount of bandwidth consumed by an individual
microflow, or an aggregate of flows. Policing should not be confused with traffic shaping. Although
traffic shaping limits flows to a specified rate, it buffers nonconforming traffic to ensure the flows
remain within the confines of the configured contract. Policing, on the other hand, does not buffer
nonconforming traffic. As a result, policing does not introduce additional jitter or delay, which
could impact the timely delivery and performance of real-time voice or video applications.
Queuing:
Queues are created at the interface where congestion is expected. Depending on the specific
feature or mechanism being used to provide QOS and the platform on which the QOS is being
configured, there could be only one or several queues.
Packets (or frames, or cells …) are then assigned to these queues, based on classification
characteristics such as DiffServ codepoint (DSCP) value. The classification of packets by
characteristics is typically user-defined, and packets are placed into queues by these predetermined
characteristics. Some examples of packet characteristics that are typically used in classification are
the values in the packet for IP precedence, DSCP, and Layer 2 class of service (CoS). It is also
common to use defined policies to match packets based on more complex criteria, such as port
numbers.
Based on queue filling and “Dropping Precedence” frames can be dropped to avoid congestion.
Inside the queues, different occupancy thresholds may be defined for such purpose.
Scheduling:
Determines order in which queues (and then packets) are served. Determining the scheduling of
packets is specific to every congestion management mechanism, but it can generally be said that
there will be a way to provide for the transmission of more packets out of some queues than some
others. That is, the system is able to give some packets better treatment than others, with regard
to the amount of bandwidth that those packets receive.
Typical examples of such scheduling scheme are:
• Strict Priority Queuing (SPQ)

A queue with higher priority will be served as long it has traffic
• Weighted Round Robin (WRR)

A percentage of the available throughput is assigned to the queues that are WRR scheduled
• Combination of Strict Priority and WRR scheduling

Queues with strict priority scheduling will be served before queues with WRR scheduling
Example: Queue #3 is strict priority, Queue #2 is WRR 70% and Queue #1 is WRR 30% : Queues #1 and
#2 are only served if queue #3 is empty
4.5.2 Network QoS models

Three different models exist for implementing quality of service (QOS) on a network.
• The best effort model designed for no-guarantee delivery pf packets and still predominant model
in Internet best effort means no QOS applied to packet
• The integrated service (IntServ) model was introduced to supplement the best effort delivery by
setting aside some bandwidth for applications that requires bandwidth and delay guarantees.
IntServ expects application to signal their requirements to the network. The signalling uses RSVP
protocol to reserve the network resources.
• The differentiated Service (DiffServ) model was added to provide greater scalability in providing
QOS to IP packets. The main difference between the IntServ and DiffServ models is that in DiffServ,
the network recognize packets (No signalling is needed) and provides the appropriate services to the
packets.
The LTE Network uses the DiffServ model.
4.5.3 Layer 3 QoS: DiFFSERV

The Differentiated Services (Diffserv) architecture [IETF RFC 2475], [IETF RFC 2836] was introduced
as a result of efforts to avoid the scalability and complexity problems of Intserv. Scalability is
achieved by offering services on an aggregate basis rather than per-flow and by pushing the per-
flow states to the edge of the network. The service differentiation is achieved using the six highest
bits of the Type of Service (TOS) field in the IP header. These bits are referred to as the
Differentiated Services codepoint, or DSCP. This value is used to differentiate between different
kinds of traffic. For example, a network operator may assign value X for real-time voice over IP and
value Y for bulk transfers. Then data packets with DSCP set to X is given higher priority than all
other traffic and data packets with DSCP Y is given the lowest possible priority in every node.
To support different traffic types, each node need to behave in the same manner for each traffic
type. Therefore, a set of behaviors is specified and are called per-hop behaviors (PHBs) . An
operator that wants to support a certain PHB must assign a DSCP value for the PHB and then
upgrade and configure all his nodes to support the PHB.
Diffserv defines the concept of a Differentiated Services domain. One operator’s network can be a
Diffserv domain, or he can divide his network into several non-overlapping domains. A domain is a
connected sub-network, such as the one depicted in figure below. The traffic inside the domain is
considered as trusted by its operator, while traffic entering the domain is not. The operator makes
sure that no external customer or operator can misuse the resources of the domain. This is achieved
by policing and shaping at the edge nodes. The edge nodes are routers with a connection to another
node outside the domain and will perform policing, shaping and marking on traffic entering the
domain. The non-edge nodes, which are called interior nodes, only perform packet scheduling based
on the marking done by the edge nodes.

DiffServ DiffServ
Edge Port Interior
Port
DiffServ Egress edge port

removes DSCP
Domain
• Marking : Interior port inspects DSCP in

Edge port writes DiffServ codeword (DSCP) in each frame and treats frame
each frame header, based on provisioned accordingly : scheduling based
policies on DSCP
=> defines Per Hop Behaviour (PHB)
• Policing/Shaping
Figure 21: Diffserv domain concept
Assume that the left host in above figure is the sender and the right host is the receiver of a flow.
For this flow, the left edge node will become the ingress node where the flow data traffic enters
the domain. At that node, it is necessary to perform marking, policing and shaping. The right node
will be the egress node for the same flow and there it might only be necessary to perform remarking
and maybe shaping. What node is ingress and what is egress depends always on which flow is under
consideration. An edge node can act as both ingress and egress at the same time for different flows
and therefore must all edge nodes be able to perform marking, policing and shaping.
4.5.3.1 Diffserv marking
With DiffServ, traffic is divided into classes based on business requirements; each of the classes can
then be assigned a different level of service. As the packets traverse a network, each of the
network devices identifies the packet class and services the packet according to that class. The
identification of this class is based on a 6-bit bit-pattern (called the Differentiated Services Code
Point [DSCP]) in the IPv4 ToS Octet or the IPv6 Traffic Class Octet & is used as shown below:

Figure 22: IPv4 header format
Figure 23: IPv6 header format
The DiffServ Code Point field is further detailed below:

Figure 24: DiffServ Code Point field details

4.5.3.2 PER HOP BEHAVIOR (PHB)
With the introduction of the DSCP markings, there were significantly more possible markings for
packets (63 are the possible markings for packets). Because there were so many more possible
markings, the IETF decided to standardize what some of the codepoints meant. In part, this is to
provide backward compatibility to IP precedence and, in part, this is to facilitate certain types of
behaviors that were seen as fundamental to the DiffServ architecture.
Four different types of DiffServ PHBs have been standardized so far. IETF RFC 2474 which defined
DSCP, itself has defined two types of PHBs : the default PHB and Class Selector (CS) PHBs Later in
1990, IETF RFC 2597 defined Assured Forwarding (AF) PHBs for forwarding data traffic. Also in 1999,
IETF RFC 2598 defined Expedited Forwarding (EF) PHB for forwarding real-time traffic.
• The default Per-Hop Behavior: defined in IETF RFC 2474. The default PHB should offer the
traditional best effort (BE) service Packets that are not explicitly mapped to other behavior
aggregates or forwarding classes belong to default PHB. No explicit delay, jitter or loss
characterization is associated with PHB. However, the traffic belonging to the BE PHB should not be
left to starve.
• Class Selector behavior (CS): defined in IETF RFC 2474 to provide backward compatibility with
legacy nodes using IP precedence, The recommended DSC value for CS PHBs are XXX000.No explicit
delay, jitter, or loss characterization is associated with PHB, the higher a CS is numerically , the
better the service precedence its gets.
Mapping between IP precedence value and DiffServ CS PHBs:
Precedence name binary decimal name

Network Control 111000 56 CS7/NC2
Inter-network Control 110000 48 CS6/NC1
CRITIC/ECP 101000 40 CS5
Flash Override 100000 32 CS4
Flash 011000 24 CS3
Immediate 010000 16 CS2
Priority 001000 8 CS1
Routine 00000 0 CS0/BE
• Assured Forwarding ( AF) PHBs: IETF RFC 2597 defines four Classes of Assured Forwarding PHBs.
These Classes are suitable for carrying data application traffic with minimum assured bandwidth
guarantee.
Priority hierarchy is defined between classes. The traffic in the higher class (AF1 being the highest
class) is given priority. Each of the four Classes of AF PHBs supports three levels of drop
probabilities. Under congestion, the higher the drop probability of a packet, the higher the chances
that the packet will be dropped. No delay, Jitter, or loss characterization is associated with the
PHBs.
The four classes of AF, with their three levels of drop probabilities and resulting 12 PHBs are
summarized in the following table:

Drop Probability
Classes Low (1):010 Medium (2):100 High (3):110
AF1: 001 AF11: 001 010 AF12: 001 100 AF13: 001 110
AF2: 010 AF21: 010 010 AF22: 010 100 AF23: 010 110
AF3: 011 AF31: 011 010 AF32: 011 100 AF33: 011 110
AF4: 100 AF41: 100 010 AF42: 100 100 AF43: 100 110
• Expedited Forwarding PHB (EF): IETF RFC 3246, supplemented by IETF RFC 3247 , replaced IETF
RFC 2598 in defining Expedited Forwarding characteristics. EF PHB is suitable for carrying
application traffic that requires low-loss, low-latency, and low jitter network service. EF PHB is
suitable for carrying time and loss sensitive application traffic at certain configured rate and the
node should service the packet belonging to EF PHB at a rate higher then their arrival rate and
irrespective of the offered load of non-EF traffic at the servicing point. Packet belonging to a flow
going for EF PHB class should not be reordered , such that traffic has strict servicing priority over
any other traffic, for this reason queues belonging to EF can be maintained at an empty or nearly
empty state and thereby queuing latency can be minimized which helps minimizing jitter, latency ,
and packet loss.
DSCP value 101110 is recommended for EF PHB
4.5.4 Layer 2 QoS : 802.1q

A standardized method of marking frames at Layer 2 was developed to allow differentiation of
frames in terms of the characteristics that those frames would receive as they traverse the Ethernet
switched infrastructure.
This is based on the 802.1q standard marking which requires the 802.1q tag to be present in the
MAC frame. The field (3 bits – 8 possible values) is called the Priority Code Point (PCP) as defined
below:
Basic
IEEE802.3
MAC frame IPG
2 Bytes 0x8100
Preamble
CFI
12 Bytes IPG SFD 2 Bytes PCP VID

3 1 12 bit
7 Bytes Preamble DA
1 Byte SFD SA Ethertype = 0x8100 (TPID: Tag
TPID/Ethertype Protocol ID)
6 Bytes DA
VLAN-tag PCP = 8 priorities (Priority Code
6 Bytes SA Point)
2 Bytes L/T L/T CFI = 0 (Canonical Frame
Identifier)
46 – 1500 VID = 12bit VLAN ID (4096 VLANs)
Data Data VID 0: priority untagged
Bytes
VID 1: default
4 Bytes FCS FCS VID FFF (4095): reserved
IEEE does not define how to handle Frames with certain 802.1q markings; however, it makes some
broad recommendations on providing the QOS using the field. A 802.1q compliant switch should be
able to segregate frames, based on their 802.1q marking, into different classes of service.
The highest priority value is 7, and lowest priority is 0

802.1q marking suggested for different types of traffic:
802.1q Marking 802.1q Traffic type

(Decimal) Marking Binary
7 111 Network Control
6 110 Real-Time
5 101 Real-Time
4 100 Controlled Load /Critical Data
3 011 Excellent Effort
2 010 Spare
0 000 Background
1 001 Default : best Effort

5 LTE TRANSPORT REQUIREMENT

5.1 LAYER2/LAYER3 REQUIREMENT

Layer 3:
- Support of IP v4 and possibility to migrate to IPV6
- Qos requirement at Layer 3: DSCP, traffic shaping and policing
- IP header compression
- IP fragmentation and assembly
- IPSec to secure the L3 layer
Layer 2:
- Support of Jumbo frame
- Ethernet 802.1Q for VLAN segregation and security of traffic
- OQS support at layer 2 with PBit (802.3)
5.2 SECURITY REQUIREMENT

The security requirements demand the NE and traffic in the backhaul to be protected when failure
occurs on the network or against security threats created by a shared public network. Additional to
the basic features for IP/Ethernet transport protocol, other recommendations to use transport
mechanisms are necessary to ensure the security of the traffic itself and the transport
infrastructure which carry this traffic, by deploying appropriate solution and design which can offer
the following benefit:
• Security of the traffic: Security of the user traffic by offering confidentiality, authentication and
integrity of the user data at the transport level. To address this problem, protocols as AAA
(Authentication, Authorization and Accounting), IPSec and MPLS are used to offer all the mature
mechanisms and process to guaranty this request.
5.2.1 Generic IPsec Theory
This section of the document will describe the high level basics of Internet Protocol Security
(IPSec). We will describe all the supported options of IPsec even though some optional functionality
is not supported in the eNodeB.
IP communications between two entities are inherently insecure. IP traffic on the public network
can be captured, examined, and altered. Therefore security is the utmost concern when
transferring data over a public network.
The Internet Engineering Task Force (IETF) community had formed the IPsec (IP Security) forum to
develop a methodology to address IP security. IPsec is a protocol suite for securing Internet Protocol
(IP) communications by authenticating and encrypting each IP packet of a communication session

for either IPv4 or IPv6. IPsec also includes protocols for establishing mutual authentication between
agents at the beginning of the session and negotiation of cryptographic keys to be used during the
session.
5.2.1.1 Security Definitions
Security Definitions:
Packet Integrity - is a guarantee that the message that is received is the exact one that was sent,
and that no tampering has occurred.
Data origin Authentication - is a guarantee that the message actually was sent by the apparent
originator of the message and not by another user masquerading as the supposed message
originator.
Replay protection (optional) - is the assurance that the same message is not delivered multiple
times and that messages are not delivered grossly out of order. This capability must be
implemented by the sender; the receiver may optionally enable its use.
Confidentiality - is a guarantee that, even if the message is read by an observer, the contents are
not understandable except to the authorized recipient.
Traffic analysis protection (Tunnel Mode only) - is an assurance that an eavesdropper cannot
determine who is communicating with whom or the frequency and volume of communications
between specific entities.
IPsec Definitions:
Security Association (SA) - Before two communicating entities can exchange secure communications,
they need to agree on the nature of the security to be applied to those communications: which
security headers (AH, ESP, or both) will be applied, the cryptographic algorithms to be used, the
secret keys, and so forth. A security association (SA) consists of all the information needed to
characterize and exchange protected communications.
Security Association DataBase (SADB or SAD) - An list of SAs and their associated information which
can indexed traffic selector rules.
Security Policy Database (SPD) - A security policy is a rule that is programmed into the IPSec
implementation that tells it how to process different datagrams received by the device. For
example, security policies are used to decide if a particular packet needs to be processed by IPSec
or not; those that do not bypass AH and ESP entirely. If security is required, the security policy
provides general guidelines for how it should be provided, and if necessary, links to more specific
detail.
5.2.1.2 IPsec Components
It is important to discuss the various IPSec and cryptographic modes that will be described in the
IPsec Walk Through section of this document. The IPsec and cryptographic modes are value entries
in each SA with the SADB. Transport mode is mainly used for host-to-host configurations. However,
when a security gateway is used to provide protection for multiple hosts on a network, Tunnel Mode
is used. Cryptographic modes AH and ESP security protocols can operate in either transport or
tunnel mode.
5.2.1.2.1 Transport Mode
In transport mode, only the payload (the data you transfer) of the IP packet is encrypted and/or
authenticated. The routing is intact, since the IP header is neither modified nor encrypted
5.2.1.2.2 Tunnel Mode
In tunnel mode, the entire IP packet is encrypted and/or authenticated. It is then encapsulated into
a new IP packet with a new IP header. The original IP packet source and destination address will be

referred to as the Inner Tunnel Address. The new IP headers source and destination IP addresses will
be referred to as the Outer Tunnel Address.
Transport mode will reformat the orig
original
inal IP packet by inserting an IPsec header to form a new IPsec
packet for transmission. The Ipsec header is inserted between the IP header and the payload. The
original header remains unaltered. Tunnel mode will reformat the original IP packet by insertin
inserting a
new IP header and an Ipsec header in front of the original IP packet. The Ipsec header is either the
AH or ESP format.
Figure 25: Transport and Tunnel Mode Formats
Alcatel-Lucent
Lucent - Proprietary - Use pursuant to applicable agreements

Figure 26: Transport and Tunnel Mode Formats
Figure 27: Protection Depending on Transport and Tunnel Mode
Alcatel-Lucent

AH addresses the following security issues:

Packet Integrity
Data origin Authentication
Replay protection (optional)
Figure 28: AH Header
ESP addresses following security issues:

Confidentiality
Traffic analysis protection
Packet Integrity - offered by AH method as well.
Data origin Authentication - offered by AH method as well.
Replay protection (optional) - offered by AH method as well.
Alcatel-Lucent

Figure 29: ESP Header
Since both the AH and ESP method both contain a valid IP header, the encrypted packet can be
routed through an IP network transparently.
5.2.1.3 IPsec Walk Through
IPsec is a peer-to-peer
peer security scheme operating in the Internet layer of the Internet Protocol
Suite. It can be used in protecting data flows between a pair of hosts (host
(host-to-host),
host), between a pair
of security gateways (network-to-network),
network), or between a security gat
gateway
eway and a host (network-to-
(network
host). IPsec protects any application traffic across an IP network. Figure 25 depicts the different
network configurations and the point where traffic is secure.
Alcatel-Lucent

Figure 30: IPsec Transport Configuration
Before we actually discuss the details of the IPsec implementation, we should describe a high level
view of the components of transmitting and receiving secure communications. When we start the
discussion of the IPsec components, it will allow the reader to determine which part of the
communications path we are describing. We will use the host
host-to-gateway
gateway configuration as the
example network, since this is the network configuration specified for LTE deployments.
Alcatel-Lucent

Figure 31: Host IP Packet Transmission to Security Gateway
Figure 26 is an example of the host transmitting a packet to the SEG. Before secure communications
can be established, the Security Association Database (SADB) must be populated with the Security
Association (SA) entries. A SADB contains SA’s for each secure communications tunnel. SA is simply a
contract between two entities to provide a minimum set of services. SAs are unidirectional (as in
phase2). We shall need two phase2 SAs to complete one communication path. One SA is required on
each of the IPsec termination points. Each SA contains the negotiated attributes associated with the
secure tunnel that is uniquely liked to the IPsec peer. The SA contains information on Security
Policy Index (SPI), its state (alive or expired), authentication algorithm, sequence number and SA
life time.
Stage 0 represents the initialization of the (SADB) prior to secure communications transmission.
Stage 1 represented by the green circle with the value of 1 indicates the actual transmission of the
original packet. The packet is examined to determine if there is a matching Security SA in the SADB.
Stage 2 represents the packets after the SADB lookup. The yellow box with label 2 represents the
original transmitted packet because the SADB had failed to locate a SA that matches the packet
criteria. The blue box with label 3 represents a reformatted secure IPsec packet since a valid SA had
been located that matches the transmitted packet. At the end of Stage 2, the packet is examined
and a routing table lookup is performed to determine the next hop, in this example the SEG.
Stage 3 represents the transmittal of the packet to the appropriate interface.
Stage 4 is the packet reception.
Stage 5 forwards the normal packet to the upper layer stack.

Stage 6 forwards the IPsec secure packet to the SADB lookup.
Stage 7 the secure packet SA was found in the receiving SADB, decrypted and forwarded to the
upper layer stack.
Stage 8 is an example where the secure packet had failed a lookup at the SADB and the packet is
dropped. Each step of transmission of secure packets will be discussed in further detail.
5.2.1.4 IPsec IKE (Stage 0)
IPsec consists of several protocols to administer the secure tunnel and perform the encryption of
user traffic. IPsec suite of protocols contains three main protocols, Internet Key Exchange (IKE),
Authentication Header (AH), and Encapsulating Security Payload (ESP). The administrative portion
of IPsec is either performed manually or dynamically. The dynamic method of tunnel negotiation is
performed by the IKE protocol. There are two flavors of IKE (IKEv1 and IKEv2) that may be
supported on a SEG. In case of the eNodeB, IKEv2 is the only supported IKE mechanism. For the
remainder of the IPsec discussion, we will only refer to IKEv2.
IKE is the protocol used to set up a SA in the IPsec protocol suite. IKE builds upon the Internet
Security Association and Key Management Protocol (ISAKMP) and uses a Diffie-Hellman Key exchange
to set up a shared session secret, from which crytographic keys are derived. Public key techniques,
certificates, alternatively, a pre-shared key, are used to mutually authenticate the communicating
parties. IKE is a two phase approach, Phase 1 establishes an ISAKMP SA, which is a secure channel
through which the IPsec SA negotiation can take place. Phase 2 establishes the actual IPsec SA or,
more precisely, a pair of one-way IPsec SAs: an inbound SA and an outbound SA. The ISAKMP SA
should not be confused with the IPsec SA. The ISAKMP SA is meant to secure (encrypt) the remaining
phase 1 and phase 2 negotiations.
IKEv2 Phase 1
ISAKMP defines procedures and packet formats to establish, negotiate, modify and delete Security
Associations. SAs contain all the information required for execution of various network security
services, such as the IP layer services (such as header authentication and payload encapsulation),
transport or application layer services, or self-protection of negotiation traffic. ISAKMP defines
payloads for exchanging key generation and authentication data. These formats provide a consistent
framework for transferring key and authentication data which is independent of the key generation
technique, encryption algorithm and authentication mechanism.
IKEv2 phase 1 has a four message exchange as depicted in the following figure.

Message 1:
IK The initiator sends the IKE Header with
E HDR, SA1,KE,N
possible supported SAs (Crytographic
_ algorithms), KE – Diffe-Hellman Value, and
S HDR, SA1, KE, N, nonce value.
A [CERTREQ] Message 2:
_I The responder sends the IKE Header with
N the SA selected from one of the possible SAs
Responder
IT
Initiator
HDR,IDi,[CERT],[CE provided by the Initiator from message 1.
RTREQ], [IDr], Included as well is the responders KE –
AUTH, SA, TSi, TSr Diffe-Hellman Value, nonce and optionally
IK the Certificate Request.
E Dashed Line:
_ At this stage of the negotiation, the two
HDR,IDi,[CERT],
A participants have exchange Diffe-Hellman
AUTH, SA, TSi, TSr
u Values and they can derive shared secret
t keys. From this point on, all information
h after the IKE Header will be encrypted and
provides Integrity Protection.
Auth Authentication Message 3:
CERT Certificate The Initiator sends the IKE Header,
CERTREQ Certificate Request Identification, Certificate response if there
HDR IKE Header was a request in message 2, optional
IDi Identification - Initiator certificate request, optional ID of
IDr Identification – Responder responder, Authentication – could contain
KE Key Exchange the pre-shared keys or digital certificate
N Nonce verification. SA and traffic selectors for
SA Security Association traffic flow.
TS Traffic Selector Message 4:
The responder sends the IKE Header with an
ID, Certificate response if a certificate
request was present in message 3.
Authentication – could contain the pre-
shared keys or digital certificate
verification. SA and traffic selectors for
traffic flow. Peer Authentication has been
validated after this stage
Figure 32: IKEv2 Phase 1 Negotiation
After the second message, the IKE encryption key is calculated and used to encrypt the remaining
message transfers between the initiator and responder. The Key calculation is dependant on the
negotiated method of authentication. The following examples show the pre-shared key and digital
certificate method. In either case an IKE encryption key, IKE authentication key and IKE derivation
key are produced.

Figure 33: IKE Key calculation with Pre-Shared

Pre Shared Key Authentication
Alcatel-Lucent

Figure 34: IKE Key calculation with Digital Signature Authentication
The IKE Encryption Key, Authentication and Derivation key are valid for all future communications,
unless otherwise renegotiated in the Phase 2 stage.
IKEv2 Phase 2
IKE phase 2 negotiation

ion creates the IPsec SA that will determine if any subsequent packet will be
encrypted prior to transmission or reception of packets.
Alcatel-Lucent

Dashed Line:
All traffic remains encrypted as a result
of the phase 1 negotiation.
Message 5:
The Initiator sends the IKE Header, SA
C HDR, SA, N, [KE], offers, a new nonce value different
r [3GPP TS i, TS] from the phase 1 transmission, optional
e KE if you want to create a new
a calculated key, and optional Traffic
Responder
t
Initiator
selection offers.
e HDR, SA, N, [KE], Message 6:
_ [3GPP TS i, TSr] The responder sends the IKE Header
c with a selected SA from message 5, a
hi new nonce value different from the
ld phase 1 transmission, optional KE if you
_ want to create a new calculated key,
S and optional traffic selector chosen
A from the offers provided in message 5.
Note: [KE] Diffie-Hellman keys are

exchanged if Perfect Forwarding
Auth Authentication Secrecy is selected.
CERT Certificate
CERTREQ Certificate Request Note: A Child SA is a unidirectional
HDR IKE Header connection. Therefore a connection to
IDi Identification - Initiator
an end point will require a TX and RX SA
IDr Identification – Responder for a bidirectional IPsec tunnel. The
KE Key Exchange phase 2 will be repeated for additional
N Nonce
SAs setup.
SA Security Association
TS Traffic Selector
[] Optional Paramter
Figure 35: IKEv2 Phase 2 Negotiation
As part of the phase 2 negotiation, new Diffie-Hellman keys and nonce values different from phase 1
could be exchanged to allow additional security (Perfect Forwarding Secrecy, PFS). The Phase 1
ISAKMP encryption key calculation was performed on values that were passed between the peers in
a non encrypted channel. If an entity were to observe the initial (message 1 & 2) communications,
theoretically the entity could possibly derive the keys (encryption, authentication). Therefore a
second key calculation is allowed in the phase 2 negotiations with new key and nonce values
provided by the peers. The phase 2 key and nonce values (message 5 and 6) are encrypted with the
phase 1 ISAKMP encryption key. The new keys are calculated the same method as described for the
phase 1 ISAKMP keys in Figure 28 and Figure 29. The new keys are referred to as the IPsec Derived,
IPsec authentication, and IPsec Encryption key. All communications after the phase 2 negotiations
will be encrypted with the IPsec encyption key.
IKE negotiation is completed at the end of the Phase 2 negotiation. The Agreed upon SA for each
direction will be entered into the Initiator’s and responder’s local SA database. The agreed upon
traffic selectors will be entered into the Initiator’s and responder’s local security policy database.
The agreed upon SA will contain:
• Encryption Algorithms to protect data
• Hash algorithms to reduce data for signing

• An authentication method for signing data
• Information about a group over which to do a Diffie

Diffie-Hellman exchange.
• A pseudo-random
random function (PRF) to hash certain values during the key exchange.
• Type of protection to use - either ESP or AH.
5.2.1.5 Stage 1 - IPsec traffic selection and SA database lookup
Out going IP traffic are

re examined on a packet basis and compared to the Security Policy Database
(SPD) for a corresponding valid entry. If a valid entry is found, the specified action in the SPD is
followed. If the specified action is IPsec, the corresponding SAD lookup is perf
performed
ormed to determine
the IPsec specifics for encryption.
Figure 36: SPD / SADB Transmission Validation
The SPD rules stage is analogous to an IP firewall filter rules lookup. The SPD filter can examine:
• Source and Destination IP address
Alcatel-Lucent

• Source and Destination Port
• Protocol Type
Depending on the rules validation the transmitted packet can have several possibilities. The packet
can be dropped, transmitted without IPsec encryption or IPsec encryption is enforced. If the IPsec
encryption is required, an SADB lookup is performed to retrieve the corresponding SA. With the
information retrieved from the SPD and SA, the packet encryption can be achieved.
5.2.1.6 Stage 2 - IPsec Encryption and Transmission
The yellow packet (2) represents a packet that is forwarded without encryption. The Blue packet (3)
represents a packet that matched a rule in the SAPD and a corresponding SA was found. The packet
will be encrypted based on the parameters for that specific SA.
Based on the cryptographic modes that were negotiated in the ISAKMP (stage 0) phase, each packet
will be encrypted with the modes described in the IPsec Components section of this document. The
packet will transmitted in either AH or ESP encryption method in either Tunnel or Transport mode.
5.2.1.7 IPsec Transmission and Reception (Stage 3 & 4)
This is a generic step where the route table lookup to send the packet to the proper interface. The
receiving IPsec termination will inspect the packet to determine if the packet is IPsec encrypted.
5.2.1.8 Receiving Packet Inspection (Stage 5 & 6)
Stage 5 represents a NON IPsec protected packet and sent to the internal IP stack for proper
decoding. Stage 6 represents an IPsec protected packet, that requires a SADB/SPD validation. The
IPsec decryption will be performed if a valid SADB/SPD pair has been found and the decryption will
be performed based on entries of the match SA/SP parameters.

Figure 37: SADB / SPD Receiving Validation
5.2.1.9 Decrypting IPsec Packet (Stage 7 & 8)
Stage 7 represents a packet that successfully validated an SADB entry and corresponding SP in the
SPD. The packet was decrypted and sent to the IP stack for further processing. Stage 8 represents a
packet that failed to find a SA entry in the SADB for a SP in the SPD. In either case the packet is
discarded.
5.2.2 Transport Security Gateway
The Security Gateway (SEG) is the central hub of communications between the eNodeB and other
LTE components (i.e. eNodeB, MME, SGW and HSGW). The Network diagram from the eNodeB
section
n of this document has been reproduced for the reader’s convenience.
Alcatel-Lucent

The diagram depicts the logical functionality of the SEG within the network. The physical SEG
component can be the same router that would normally aggregate traffic from the eNodeB’s, given
the router supports IPsec functionality. Most larger core routers that aggregate traffic should
support IPsec tunnels. The SEG will usually contain a robust IPsec feature set to allow compatibility
with a wide variety of vendors IPsec implementation.
5.2.2.1 General IPsec Compatibility
This section describes the general IPsec attributes that the SEG should contain. This is in no
reference to any particular router platform.

Description Specification
IPsec • IPsec (IETF RFC 2401-2409)
• Encapsulating Security Payload (ESP) (IETF RFC 2406)
• Authentication Header (AH) (IETF RFC 2402)
IKE • IKEv1 (IETF RFC 2409)
• IKEv2 (IETF RFC 4306)
Mode • Tunnel
• Transport
Encryption • DES (IETF RFC 2405)
• 3DES
• AES 128 bits and 256 bits
Authentication • Preshared Secret Keys
• X.509 Digital Certificates
• Diffie-Hellman group 1,2,5 and 14
• Radius (IETF RFC 2138)
Integrity Hashed Message Authentication Code with MD5 (HMAC-MD5) and
with Secure Hash Algorithm-1 (HMAC-SHA-1) (IETF RFC 2403 and
2404)
Key Management • Internet Key Exchange (IKE: IETF RFC 2407-2409)
• IKE-XAuth
• IKE-CFG-MODE
Resiliency and High • IPsec Failover
Availability • Dead Peer Detection (DPD)
• Dynamic routing across IPsec
IP Version • IPv4 Support
• IPv6 Support
Table 3: General Security Gateway IPsec Attributes
The Red High lighted values are the minimal required attributes to interoperate with the eNodeB
IPsec implementation.
5.2.2.2 7750 SR Security Gateway
The 7750 SR IPsec functionality is implemented in the MS-ISA module. The MS-ISA module is a hot
swappable component that can be inserted into an Input/Ouput Module-2 (IOM-2) or higher. Multiple
MS-ISA modules used in a redundant scheme can provide failure protection within an ALU 7750
chassis. Multiple MS-ISA modules on separate 7750 chassis can provide redundant IPsec failover
across chassis.
Please refer to the ALU 7750 product documentation for further information.
https://support.alcatel-lucent.com/portal/productContent.do?productId=null&entryId=1-
0000000002238

The MS-ISA will require compatible Hardware and Software components. The 7750 Hardware and
Software requirements are listed below.
Input / Output Module Minimum IOM-2 Hardware or higher
Supported Chassis 7750 SR-7 or 7750 SR-12
Operating System Minimum of Release 8.0R5 (includes IKEv2)
MS-ISA
Encryption DES, 3DES, AES-128, AES-192and AES-256
Authentication HMAC-MD5, HMAC-SHA1
Key Distribution IKE shared secret with PFS support
Encapsulation Encapsulating Security Payload (ESP)
Mode Tunnel
Key Generation Diffe-Hellman
Authentication Method PreShared Keys
Resiliency and High • IPsec Failover (Hard Failover only)
• Dynamic Routing
• BFD (Bidirection forwarding detection)
IP Version • IPv4 Supported
If you have a pre-existing IPsec-ISA module reference (3HE03080AA ISA – 7750 SR IPSec – ISA) this
will now be replaced with a consolidated hardware component (MS-ISA) ISA − 7X50 MULTISERVICE ISA
(3HE04922AA IPU3AL8EAA).
5.2.2.3 Fortinet Security Gateway
The Fortinet Security Gateway is a third party equipment to fill the gap that the ALU 7750 SR
security gateway can not provide. The ALU 7750 limitations are specified in section 6.10.1.8
Engineering Notes. Specifically the Fortinet will handle the customer configuration that requires
IPsec on IPv6. The Fortinet specifications are provided below.
Input / Output Module FortIOS 4.2+
Supported Chassis 310B or Higher
Operating System Minimum of Release 4.2 (includes IKEv2)
Encryption DES, 3DES, AES-128, AES-192and AES-256

Authentication HMAC-MD5, HMAC-SHA1
Encapsulation Encapsulating Security Payload (ESP)
Mode Tunnel
Key Generation Diffe-Hellman

Authentication Method PreShared Keys

Resiliency and High • IPSec Failover
IP Version • IPv4 & IPV6 Supported
The network architecture to support the Fortinet deployment is specified by the following diagram.
The Fortinet Security Gateway is used in conjunction with Layer 3/Layer 2 router/switch. This
device will depend on the network design. All traffic from the eNodeB will be sent through the
L3/L2 device towards the Fortinet gateway for IPsec termination. The Fortinet will send all
decrypted traffic back to the L3/L2 device to be forwarded to the final destination. On the
downlink path, all traffic from the EPC network will be forwarded from the L3/L2 device to the
Fortinet. The Fortinet with the IPsec Tunnels with configured policies will examine each packet to
determine the proper treatment of the packet. Based on the IPsec policies, the Fortinet may or may
not encrypt traffic and send the packets to the L3/L2 device to be forwarded to the eNodeBs.
Figure 38
38: Fortinet Reference Architecture
The Fortinet must be configured for logical Virtual Domains (VDOM). This is required configuration
to support asymmetric traffic flow. The Fortinet is a stateful firewall and requir
requires
es that the traffic
flow must be linked to an interface. Therefore multiple VDOMs are configured to allow this
configuration. The diagram below shows the virtual functional representati
representation.
Alcatel-Lucent

Figure 39:: Fortinet Virtual Domain Configuration
Each Virtual Domain is a logical router. For traffic to flow properly between the VDOMs, IP routes
must be configured to point traffic in either direction. Each VDOM will have logical interfaces (IP
configuration) for proper routing.
5.2.3 Generic IPsec Certificate

Certif Theory
IPsec was introduced in release 3.0. For security reasons, IPsec communications between peers
require each peer entity to authenticate their corresponding peer. In release 3.0 the eNodeB only
supported pre-shared
shared keys method of authentication in the IPsec IKE handshake. The pre-shared
pre key
method required the operator to manually load a known key into the eNodeB and a corresponding
key into the SEG, thus allowing the eNodeB and the SEG to mutually authenticate each other when
performing the IKE negotiation. Starting in Release 5.0 the eNodeB will now be capable to support
Certificate authentication in the IPsec IKE transaction. The certificates are loaded into the eNB via
an automated method by using CMPv2 protocol to acquire the required certifi
certificates
cates from the CMS
server. The acquisition of the certificates is performed prior to the IPsec IKE negotiation.
5.2.3.1 Certificate Management System Terminology
Item Definition
In cryptography, certificates are digital documents attesting the binding of
Certificate
a public key to an individual or other entity. They allow verification of the
Alcatel-Lucent

claim that a specific public key does in fact belong to a specific individual.
In their simplest form, certificates contain a public key and a name. As
commonly used, a certificate also contains an expiration date, the name of
the certifying authority that issued the certificate, a serial number, and
perhaps other information. Most importantly, it contains the digital
signature of the certificate issuer. The most widely accepted format for
certificates is defined by the ITU-T X.509 international standard
http://en.wikipedia.org/wiki/Certificate
In cryptography, X.509 is an ITU-T standard for a public key infrastructure
(PKI). X.509 specifies, amongst other things, standard formats for public
X.509 key certificates, certificate revocation lists, attribute certificates, and a
certification path validation algorithm.
http://en.wikipedia.org/wiki/X509
A digital signature is a mathematical scheme for demonstrating the
authenticity of a digital message or document. A valid digital signature
gives a recipient reason to believe that a known sender created the
Digital signature
message, and that it was not altered in transit.
http://en.wikipedia.org/wiki/Digital_signature
A certificate authority or certification authority (CA) is an entity that issues

digital certificates for use by other parties. It is an example of a trusted
third party. CAs are characteristic of many public key infrastructure (PKI)
schemes.
A CA issues digital certificates that contain a public key and the identity of
the owner. The matching private key is not similarly made available
publicly, but kept secret by the end user who generated the key pair. The
certificate is also an attestation by the CA that the public key contained in
the certificate belongs to the person, organization, server or other entity
CA, Certification Authority
noted in the certificate. A CA's obligation in such schemes is to verify an
applicant's credentials, so that users and relying parties can trust the
information in the CA's certificates. CA uses a variety of standards and tests
to do so. In essence the Certificate Authority is responsible for saying "yes,
this person is who they say they are, and we, the CA, verify that".
If the user trusts the CA and can verify the CA's signature, then he can also
verify that a certain public key does indeed belong to whoever is identified
in the certificate
http://en.wikipedia.org/wiki/Certificate_authority
Trust Anchor is an authoritative entity represented via a public key and
associated data. It is used in the context of public key infrastructures,
X.509 digital certificates.
When there is a chain of trust, usually the top entity to be trusted becomes
the Trust Anchor; it can be for example a certification Authority (CA).
The public key (of the Trust Anchor) is used to verify digital signatures and
Trust Anchor the associated data. Furthermore, the public key is used to constrain the
types of information for which the Trust Anchor is authoritative.
A relying party uses Trust Anchors to determine if a digitally signed object
is valid by verifying a digital signature using the trust anchor's public key,
and by enforcing the constraints expressed in the associated data for the
trust anchor.
http://en.wikipedia.org/wiki/Trust_Anchor
Digital certificates are verified using a chain of trust. The trust anchor for
the digital certificate is the Root Certificate Authority (CA).
The Certificate Hierarchy is a structure of certificates that allows
Chain of trust
individuals to verify the validity of a certificate's issuer. Certificates are
issued and signed by certificates that reside higher in the certificate
hierarchy, so the validity and trustworthiness of a given certificate is

determined by the corresponding validity of the certificate that signed it.

The Chain of Trust of a Certificate Chain is an ordered list of certificates,
containing an end-user subscriber certificate and intermediate certificates
(that represents the Intermediate CA), which enables the receiver to verify
that the sender and all intermediates certificates are trustworthy.
http://en.wikipedia.org/wiki/Chain_of_trust
A self-signed certificate is an identity certificate that is signed by its own
creator. That is, the person that created the certificate also signed off on
its legitimacy.
In typical public key infrastructure (PKI) arrangements, a self-signed
certificate is valid. Users, or their software on their behalf, check that the
private key used to sign some certificate matches the public key in the CA's
Self-signed certificate certificate. Since CA certificates are often signed by other, "higher
ranking," CAs, there must necessarily be a highest CA, which provides the
ultimate in attestation authority in that particular PKI scheme.
Obviously, some other CA can’t attest the highest-ranking CA’s certificate.
So, that certificate can only be "self-signed." Such certificates are also
termed root certificates.
http://en.wikipedia.org/wiki/Self-signed_certificate
In a Public Key Infrastructure PKI the top of the trust path is the Certificate
authority (CA), because is on the top is called the root CA. The CA is able
Root CA
to issue, distribute and revoke digital certificates X.509.
http://en.wikipedia.org/wiki/Off-line_Root_CA
A root certificate is either an unsigned public key certificate or a self-
signed certificate that identifies the Root Certificate Authority (CA). A root
certificate is part of a public key infrastructure scheme. The most common
commercial variety is based on the ITU-T X.509 standard, which normally
includes a digital signature from a certificate authority (CA).
Digital certificates are verified using a chain of trust. The trust anchor for
the digital certificate is the Root Certificate Authority (CA).
A certificate authority can issue multiple certificates in the form of a tree
Root certificate
structure. A root certificate is the top-most certificate of the tree, the
private key of which is used to "sign" other certificates. All certificates
below the root certificate inherit the trustworthiness of the root certificate
- a signature by a root certificate is somewhat analogous to "notarizing" an
identity in the physical world.
The root certificate is usually made trustworthy by some mechanism other
than a certificate; such as by secure physical distribution.
http://en.wikipedia.org/wiki/Root_certificate
Subordinate CA A CA that is not a root CA for the end entity in question.
A certificate revocation list (CRL) is a list of certificates (or more
CRL – Certificate Revocation specifically, a list of serial numbers for certificates) that have been
List revoked or are no longer valid, and therefore should not be relied upon.
http://en.wikipedia.org/wiki/Certificate_revocation_list
The “certification path validation algorithm” is the algorithm which
verifies that a given certificate path is valid under a given public key
infrastructure (PKI). A path starts with the Subject’s certificate and
proceeds through a number of intermediate certificates up to a trusted
Certification path validation
root certificate, typically issued by a trusted Certification Authority (CA).
algorithm
Path validation is necessary for a relying party to make an informed trust
decision when presented with any certificate that is not already explicitly
trusted.
http://en.wikipedia.org/wiki/Certification_path_validation_algorithm
An end entity is an entity that uses keys and certificates for creating or
End Entity verifying digital signatures or for confidentiality. End Entities are key
holders, organizations or relying parties. A CA is not an End-Entity.

A certificate belonging to a non-CA entity, e.g. you, me or the computer on

End Entity Certificate (EEC)
your desk
CMP is an Internet protocol used for obtaining X.509 digital certificates in a
public key infrastructure (PKI). It is described in RFC 4210 and is one of two
protocols so far to use the Certificate Request Message Format (CRMF),
Certificate Management described in RFC 4211, with the other protocol being Certificate
Protocol (CMP) Management over CMS (CMC), described in RFC 5273. An obsolete version of
CMP is described in RFC 2510, the respective CRMF version in RFC 2511.
CMP messages are encoded in ASN.1, using the DER method and usually
encapsulated in HTTP.
5.2.3.2 CMS System Architecture
In release 3.0 the eNodeB only supported pre-shared keys method of authentication in the IPsec IKE
handshake. The pre-shared key method required the operator to manually load a known key into the
eNodeB and a corresponding key into the SEG, thus allowing the eNodeB and the SEG to mutually
authenticate each other when performing the IKE negotiation. Starting in Release 5.0 the eNodeB
will now be capable to support Certificate authentication in the IPsec IKE transaction. Digital
certificates method of authentication will allow the ease of deployment of IPsec trusted entities.
There will be two digital certificates exchanged in the IPsec IKE exchange. The eNodeB will send the
eNodeB certificate to the Security Gateway and in turn the SEG will send the SEG digital certificate
to the eNodeB. The digital Certificates are X.509v3 formatted embedded in the IKE transaction. In
order for the eNodeB and the SEG to transmit the digital certificates, the eNodeB will automatically
acquire their certificates from the CMS server. The main discussion for this section of the document
will only be concerned with the eNodeB acquiring and validating digital certificates. The SEG and
other supporting entities can acquire certificates via automatic or manual methods.
The eNodeB acquires its digital certificates via the CMPv2 protocol from the Certificate Management
System (CMS). The End to End CMS system will consist of several components, one being the
eNodeB, the Security Gateway (SEG), and CMS server. In order to support this feature, a CMS server
must be accessible by the eNodeB to acquire the certificates. The SEG will have an option to
acquire certificates from the CMS server or other means. The ALU implementation of the certificate
authentication requires the eNodeB and SEG to both support Certificate based authentication or Pre
shared key method.
Engineering: <eNodeB> <Transport> (<IPsec/Certificates>)
It is recommended that the eNodeB and the Security Gateway either both support Certificated
based authentication or Pre-shared Keys. The eNodeB shouldn’t support an authentication method
different from the SEG.
Restriction: <eNodeB> <Transport> (<IPsec/Certificates>)
The architecture will only support a single CMS in the network.(159440)
The following diagram is an example of network components required to support the CMS
architecture.

Figure 40: CMS Archtitecture
The distributions of the trusted certificates are based on the ownership and trust model between
the Trust Anchor (the Certificate Authority (CA)) and the end entity (eNodeB or SEG). The ALU CMS
model architecture will support thr
hree different operator scenarios.
The following CMS models were referred in RFC 5217.
• Hierarchical CMS without operator CA: Model 1 - Hierarchical CMS with a common Root CMS.
Model 1 represents a vendor that owns the CMS structure
structure and does not have a dedicated CA
server. The CMS system will also act as the CA (Certificate Authority). The CA is able to
issue, distribute and revoke digital certificates X.509.The CMS server is owned and operated
by the same entity that owns the eNodeB and SEG. The eNB and SEG trusted anchor is the
ROOT CMS.
Alcatel-Lucent

Figure 41: CMS Architecture Model 1
• Hierarchical CMS with operator CA: Model 2 - The Wireless Service Provider owns an
operator CA. The eNB and the SEG trusted anchor
anchor is the operator CA. The value added is
that the CMS infrastructure allows automation of the eNB certificate management of the
operator CA certificates.
Alcatel-Lucent

• Direct Cross-Certification
Certification Model with Operator CA: Model 3 - The eNB and the SEG are
owned by different authorities and they trust different anchors. The operator of the SEG
owns an operator CA. The eNB trust the ROOT CMS and the SEG trust the operator CA. The
value added is that the operator can bridge the communication between the operators CA
and automate the management of the eNB certificates. In this model the Operator CA and
the Root CMS have a mutual agreed trust. Thus the end entities have to only validate the
certificates to their respective
pective trust anchor.
Alcatel-Lucent

In Model 1 and model 2, there is only 1 trusted anchor. In this case the trusted anchor produces a
self signed certificate. A self signed certificate is a certificate whe
where
re the issuer and subject in the
X.509 certificate are the same entity. Since model 3 has two trusted anchors, each trusted anchor
will have certificate associated with the other trusted anchor.
All three scenarios have a common theme where the eNodeB and and SEG have a trusted anchor. The
eNodeB and SEG may have the same or different trusted anchors. The authentication mechanism is
valid if the End entity (eNB) can authenticate the received certificates to the trusted Anchor. Each
received certificate will contain
ontain the Issuer and Subject information. The eNB is responsible to verify
all the certificates and validate the path to the Trusted Anchor. Once the path to the trusted
Anchor has been verified, then the End entity has the proper credentials to participate
participate in the IPsec
IKE authentication handshake.
In model 3, the eNodeB must validate all the certificates to its trust anchor (Root CMS). The eNodeB
will start with the certificate that has itself as the subject within the certificate and identify the
issuer.
er. If the issuer of the certificate is not the trust anchor, the eNodeB will continue with the
validation process. The eNodeB will now use the Issuer (sub CMS) and use the certificate with the
sub CMS as the subject and check that certificate’s issuer. ThisThis process continues until the trusted
anchor is found in the Issuer field in a valid certificate. If this can not be accomplished, the path
validation fails and the IKE negotiation will terminate.
The trust anchors for each model are depicted below.
CMS CA model eNB Trust Anchor SEG Trust

Anchor
Alcatel-Lucent

Model-1 Hierarchical model ROOT CMS ROOT CMS

without Operator CA
Model-2Hierarchical model with Operator CA Operator CA
Operator CA
Model-3 Direct Cross- ROOT CMS Operator CA
Certification with Operator CA
The CMS architecture will support at most a 3 level hierarchy. The will be at most 2 Sub CMS CA
between the CA and the eNB.
5.2.3.3 CMS System Architecture with eUTRAN
Model 3 is best suited to support the shared eUTRAN MOCN IPsec model. In the shared eUTRAN
model, each operator has the capability to have a separate trust anchor within the same eNodeB.
The architecture allows the flexibility for each operator to maintain their own CA. With each
operator with separate CAs, each operator is secure from other operators. The operator’s
certificates are secure from the master operator as well. The separation of certificates is more
secure than the pre shared key method. The pre-shared key method required the leasing operator
to provide the per-shared key to the master operator since the master operator is the only entity
that can manually insert the keys.
The following diagram depicts the network configuration required to support CMS certificates in the
MOCN eUTRAN configuration. All CMS communications are via the OAM link which is controlled by
the Master Operator. For Non Master Operators that use CMS certificates, the Non Master operator
CMS server will communicate with the eNB via the SEG A (owned by the Master Operator).

Figure 44: CMS eUTRAN Architecture
All CMS communications are via the OAM link which is controlled by the Master Operator. For Non
Master Operators that use CMS certificates, the Non Master operator CMS server will communicate
with the eNB via the SEG A (owned by the Master Operator).
Each operator can independently have Certificate or PSK selected as the authentication method if
IPsec is enabled for that operator.
For the master Operator, The OAM tunnel and Telecom tunnel will have the same authentication
method.
Alcatel-Lucent

5.2.3.4 CMS Theory
IPsec tunnels are important in securing communications between two peers. It is also important that
the peers authenticate each other prior to negotiating and configuring the IPsec tunnels. This allows
the IPsec peers to identify and validate the peer they are communicating with is the proper and
valid identity.
The IKE Authentication handshake allows the IPsec peers to transmit the certificates to their
corresponding peers. The certificate allows the peers to authenticate each other by identifying the
trust anchors. The eNodeB will validate the SEG’s transmitted certificates to the trusted anchor. If
the path validation is successful, the ENB now has a valid path from itself to the trust anchor and
from the trust anchor to the SEG. The SEG will in turn perform the same path validation with the
certificates it receives from the eNodeB. After authentication, the IKE process completes and the
peers continue with the IPsec negotiation and configuration.
The Steps required distributing and validating the certificates and IPsec .
1) The CMS components (CMS server, Sub CMS entity, and SEG) will have to create/acquire the
certificates to distribute to end entities. This can be performed dynamically or manually.
The Root CA certificate self certificate and sub CMS certificate are created once when
initializing the CMS system.
2) The eNodeB is configured to use certificates.
3) The End entities (eNodeB and SEG) will have to acquire their certificates prior to IPsec IKE
negotiations. Certificates received by the end entity from the CMS devices are validated to
confirm validity.
4) During IKE negotiations, the eNodeB and SEG send their certificates to each other for
validation. If certificate validation is successful and there are no revocation list criteria
met, then the IPsec negotiation can continue.
5) The eNB and the SEG will setup the IPsec tunnel.
The CMS architecture supports two methods of deploying eNB into the field. The first method that
will be support is the operator provided Certificates via the CMS server on the ePC network. The
second method is the Plug-N-Play method. The Plug-N-Play method will have the appropriate
certificates loaded in the eNB in the factory to allow the eNB to setup an initial OA&M IPsec tunnel
to the SGW. This allows the eNB to be configured remotely with the final parameters for proper
operation.
Model 1, which represents a hierarchical CMS without operator CA will provide a good example for a
walk through (Figure 41: CMS Architecture Model 1). In this example the trusted Anchor is the Root
CMS. The Root CMS is also the operating in a CA capacity. In order to populate the End Entity
(eNodeB) with the certificates, the system has to be properly configured. The Root CMS and Sub
CMS must have valid certificates to send to the eNodeB. Therefore the Root CMS & Sub CMS must
initialize and configured before the eNodeB request certificates.

Figure 45:CMS Root and CA SUB Initialization
Since this system is a single CA system, the Root CMS (CA) will generate a RSA key pair. Generate a
self signed certificate. The self signed certificate is required for path validation by the eNodeB. The
Sub CMS will generate its RSA key pair and send a Certificate request (PKCS #10 or RFC 2986) to the
Root CMS. The Root CMS will generate the SUB CMS certificate and sign the certificate. The Root
CMS will send the Certificate response (PKCS #7 or RFC 2315) to the requesting SUB CMS. This
procedure is required since the eNodeB will require these certificates to perform the trusted anchor
path validation. This exchange of certificates can be performed in a manual or automatic
procedure.
The eNodeB will now be able to acquire its certificate. The example below represent an eNodeB
that does not have a preloaded factory certificate and has been enabled to perform certificate
based IKE negotiations. Configuration aspects will be discussed in the eNode CMS portion of the
document. At this point the SUB CMS will have two certificates, the Root CMS self signed certificate
and the Sub CMS certificate signed by the Root CMS. At this point the Sub CMS is capable of
supporting eNodeB certificate requests.

Figure 46: CA SUB and eNB Initialization
The eNodeB will be configured to support digital certificates. At this time the eNodeB will have the
CMS parameters configured, including the pre-shared key. This is the CMS pre-shared key and NOT
the IPsec pre-shared key. The CMS pre-shared key is used to protect the eNodeB and SUB CMS
certificate communications. The eNodeB will reboot and generate the RSA key pair and eNodeB ID.
The eNodeB will send a CMPv2 (RFC 4210) Initialization request to the Sub CMS with the appropriate
keys, eNB ID with Proof of Possession.
An important message in RFC 4210 is the Initialization Request. This message contains all the
information that the eNB send to CMS to create the X.509 certificate. RFC 4210 defines the
requirements and procedures, but does not specify the certificate request message format, fields
and options. RFC 4211 defines in detail the certificate request message format (CRMF) and the
options supported for several different ways to perform certification requests. One of the options is
Proof of Possession (POP). POP refers to the action of the end entity (eNB) to provide adequate
information to CMS so that CMS can validate that the eNB possesses the private key pair of the
public key to be issued in the CMS certificate.
The CMPv2 initialization message is protected by the pre-shared key. SUB CMS validates the eNB
CMPv2 init message. If the message passes validation and no CRL restrictions, then the SUB CMS will
generate an eNB certificate signed by the SUB CMS. The SUB CMS will send a CMPv2 init response
message to the eNB with three certificates to the eNB (eNB Cert signed by the SUB CMS, Root CMS
cert signed by the Root CMS, and the SUB CMS cert signed by the Root CMS. The eNB will now
perform a path validation on the certificates to determine if the trusted CA can be reached. If the
validation is confirmed, the eNB and SUB CMS will send their corresponding confirmation messages
to terminate the certificate distribution.

The CMPv2 (RFC 4210) messages are sent via the eNB OAM IP address. CMPv2 will be carried over
HTTP/TCP/IP/Ethernet/Physical connection.
CMPv2
HTTP
TCP
IP
Ethernet
PHY
Figure 47: CMPv2 Protocol Stack
The CMPv2 messages are ASN.1 encoded and sent as the body of the HTTP messages.
The following are the supported CMPv2 messages associate to the HTTP Post messages:
Initialization Request
Certificate Request
Key Update Request
Certificate Confirm
The following are the supported CMPv2 messages associate to the HTTP OK messages:
Initialization Response
Certificate Response
Key Update Response
Certificate
Error Message
The CMPv2 message consists of the header, body, protection (optional), Extra Certs (optional). The
specifications were derived from the ETSI TS 133 310 V9.4.0 standard.
CMPv2 (RFC 4210) Header

message header fields RFC 4210 Definition

(Blue indicates used Mandatory/Opt
by eNodeB and ional
required support by
CMS server)
Pvno M Fixed at 2 for CMPv2.
Sender M Name of the sender of the PKIMessage. This name
(in conjunction with senderKID, if supplied)
indicates the appropriate shared secret information
to use to verify the protection on the message.
The sender shall be identical to the subject name
present in the certificate for the public key whose
related private key is used to sign the PKIMessage.
Recipient M The recipient field contains the name of the
recipient of the PKIMessage.
messageTime O Not used
protectionAlg O Specifies the algorithm used to protect the message
with the Protection field (see 3gpp TS 33.310
§9.5.3).
The protectionAlg fields are defined in RFC4210 in
subsections of §5.1.3.
senderKID O senderKID is usable to indicate which keys have
been used to protect the message. This field is used
if more than one key is associated with a given
sender name.
recipKID O recipKID is required where protection of the
message uses Diffie-Hellman (DH) keys (not used by
eNB).
transactionID O Used to correlate a message with an ongoing
transaction. Clients generate a transactionID for the
first request, servers set the transactionID field of
the response to the same value.
This field is optional in RFC 4210 but mandatory in
3GPP TS33.310 and in our eNB implementation.
senderNonce O The senderNonce and recipNonce fields protect the
recipNonce PKIMessage against replay attacks. The (pseudo-)
random senderNonce is generated by the sender,
whereas the recipNonce is copied from the
senderNonce of the previous message in the
transaction (set to 0 in the first message of the
transaction)).
This field is optional in RFC 4210 but mandatory in
3GPP TS33.310 and in our eNB implementation.
freeText O Human-readable message sent to the recipient. Not
used by LTE devices.
generalInfo O Additional machine-processable data sent to the
recipient. The following optional extensions are
defined (not used by LTE devices):

ImplicitConfirm :used by the EE to inform the CA

that it does not wish to send a certificate
confirmation for issued certificates.
ConfirmWaitTime: used by the CA to inform the EE
how long it intends to wait for the certificate
confirmation.
CMPv2 (RFC 4210) Body
Message eNB in CMS (CA/

LA5 RA)
Initialization Request (ir) Y Y
Initialization Response (ip) Y Y
Certification Request (cr) Optional Optional
Certification Response (cp) Optional Optional
Key Update Request (kur) Y Y
Key Update Response (kup) Y Y
Certificate Confirmation Y Y
(certconf)
PKI Confirmation (pkiconf) Y Y
Error Message (error) Y Y
The CMPv2 IP or CP message will contain X.509v3 Certificates from the SUB CMS to the eNodeB. An
example of the X.509v3 parameters are presented below.
Certificate ::= SEQUENCE {

tbsCertificate TBSCertificate,
signatureAlgorithm AlgorithmIdentifier,
[The signatureAlgorithm field contains the identifier for the cryptographic algorithm used
by the CA to sign this certificate.]
signatureValue BIT STRING
[The signatureValue field contains a digital signature computed upon the ASN.1 DER
encoded tbsCertificate.]
TBSCertificate ::= SEQUENCE {

version [0] Value of 3, version 3.
serialNumber CertificateSerialNumber,
[Used to uniquely identify the certificate.]
signature AlgorithmIdentifier,
[The actual signature to verify that it came from the issuer.]
issuer Name,
[The entity that verified the information and issued the certificate. For the
example of the eNodeB certificate the issuer in this example is the SUB CMS]
validity Validity,
[Contains two values, Valid-From: The date the certificate is first valid from,
Valid-To: The expiration date.]
subject Name,

[The person, or entity identified. For the example of the eNodeB certificate
the issuer in this example is the eNodeB.]
subjectPublicKeyInfo SubjectPublicKeyInfo,
[The public key that was provided by the eNB for the certificate generation.]
issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL,
-- If present, version shall be v2 or v3
subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL,
-- If present, version shall be v2 or v3
extensions [3] EXPLICIT Extensions OPTIONAL
-- If present, version shall be v3
[This field is used to carry the public key and identify the algorithm with
which the key is used.]
}
The eNodeB performs path validation on the received certificates that were sent from the SUB CMS
to the eNodeB as part of the certificate initialization response. The path validation is performed
prior to eNodeB sending the CMPv2 Certificate Confirmation.
The validation process will examine the Issuer and Subject fields of a certificate to determine if the
Issuer is the trusted CA. If the Issuer field in the certificate is not the trusted CA, the eNodeB will
take the certificate in the chain to validate. The next certificate in the chain is the certificate that
has the Subject field that is equivalent value of the current certificates Issuer Field. In essence, you
will be taking the certificate of the issuer of the current certificate. This process is repeated until
the Trusted CA certificate is reached. If the validation process is unable to reach the trusted
anchor, the validation fails and the certificates are invalid.
Path Validation table.
SEG
CMS CA model eNB Certification Path Certification
Path
Model-1 Hierarchical model without eNB SUB CMS ROOT CMS SEG ROOT
Operator CA CMS
Model-2 Hierarchical model with eNB SUB CMS ROOT CMS SEG
Operator CA Operator CA Operator CA
Model-3 Direct Cross-Certification eNB SUB CMS ROOT CMS SEG
with Operator CA Operator CA
The eNB certificate signed by the Sub CMS will be the starting point for the path validation. Since
the eNB certificate was signed by the Sub CMS, the CMS certificate will be checked for a validate
certificate. The Sub CMS and Root CMS certificates were sent to the eNB via the Certificate
response message. The Sub CMS certificate will next be validated. The Sub CMS certificate is signed
by the Root CMS. The process continues until the trusted anchor certificate is validated. In this
scenario, the Root CMS certificate is the next certificate to be validated. The Root CMS certificate is
self signed and the validation ends here. If at any point, any of the certificate validation fails, the
certificates will be rejected and the distribution fails.
The following diagram below show the certificate path validation for Model 1.

Figure 48: Model 1 Validation Diagram
After the certificates have been successfully

successfully validated, the eNB IPsec IKE negotiation can now use
the certificates to authenticate the IPsec tunnel peers. This will be explained further in the CMS
section under the eNB specific functionality.
5.3 RESILIENCY REQUIREME

REQUIREMENT
Resiliency of the network is assured
sured at the L2 and L3 Layer. Many issues on link failures has to be
identified by supporting Ethernet OAM protocol: 802.3ah, 802.1ag & Y1731,BFD
End to end connection mechanism are integrated to the OAM solution such as ALU solution 5620 SAM
to test end to end connectivity and the performance of established links at MPLS layer 2 and Layer
3.
Alcatel-Lucent

The listed Ethernet protocol are implemented at the Network element to offer fault management
function summarized in the following table:
Fault management Protocol Mechanism
Fault detection 802.1ag Continuity check message (CCM)
Fault detection 802.3ah Link monitoring
Fault notification 802.1ag Remote defect indication (RDI)
Fault notification y.1731 Alarm indication signal (Eth-AIS)
Remote failure indication (RFI)

Fault notification 802.3ah
Event notification OAM PDU
Fault notification E-LMI Status message
Fault verification 802.1ag Loopback protocol (LBM,LBR)
Fault verification y.1731 Multicast loopback (ETH-LB)
Fault isolation 802.1ag Link trace protocol (LTM,LTC)
Table 4: Fault management mechanism at the Ethernet level

IEEE 802.1 develops standards for 802 LAN/MAN architecture and IEEE 802.3 for Ethernet based
LANs.
Additions to IEEE 802.x are identified by their project number, e.g.:

802.1ag - Connectivity Fault Management
802.3ah - Ethernet in the First Mile
In this drawing the reference to 802.3ag is wrong and it is actually 802.1ag.
Figure 49: End to End OAM support
5.3.1 LAG

The 802.3ad standard defines link aggregation for full-duplex Ethernet links. In this standard, a set
of Ethernet links of the same type between a pair of Ethernet switches can form a logical trunk
called a Link Aggregation Group (LAG). The LAG is used as a single link by the switches at either
end, which balance traffic between the links composing the LAG. The link aggregation control
protocol (LACP) can be used to auto-negotiate the trunk configurations between adjacent switches.
Link aggregation provides both expansion of capacity and protection from link failures: a failure on
one link would cause a reduction in bandwidth but not loss of connectivity. Failure detection works
fastest if both directions of the duplex link fail simultaneously.
In the 1+1 protection scheme, two links, which carry identical copies of the transmitted
information, protect one other. During normal operation the receiving end listens to the status of
both links but only receives data from one of them. In the event of failure, the receiver simply
switches to receiving data from the other link. Given that detection of link failure is a hardware
function, restoration can be accomplished in tens of milliseconds or less. Thus link-level failures
cause minimal service disruption when 1+1 protection is used.
5.4 SYNCHRONISATION REQUIREMENT

Synchronization is the generic concept for distributing common phase, time or frequency to all the
nodes that require it to coordinate their local phase, time or frequency.
Frequency synchronization is the distribution of a common frequency reference to the nodes for
controlling their local oscillator. Those can be frequency synchronized and at the same time have no
common phase.
Phase synchronization implies that all the nodes have access to the reference timing signal of which
rising edges occur at the same time.
Time synchronization means distributing a common time reference to the network.
The reference timing is delivered to the nodes over the backhaul transport network in a master-
slave architecture. The master nodes usually have access to a Primary Reference Clock (PRC)
traceable reference signal. PRC is a high accuracy clock of which long-term frequency stability error
should be below 1 part per 1011 as per ITU-T G.811.
At the receiver of the timing signal a PLL (phase-locked loop) controls the frequency or the phase of
the local oscillator according to the received reference timing signal. The function of PLL is to lock
the local clock to the incoming reference signal.
Radio networks require always frequency stability.
Phase and time synchronization are additional requirements in some technologies as in LTE TDD and
LTE MBMS.
The purpose of synchronization is to make sure that equipments send and receive data at the same
rate and possibly also at the same time.
Accurate frequency synchronization is a crucial requirement on radio interface, for instance for
handovers.
Frequency synchronization requirements are expressed in parts-per notation. Parts-per notation is
the ratio between the observed frequency and the reference frequency ( i.e. = (measured frequency
/ reference frequency) – 1)) expressed in parts-per-million (ppm) or parts-per-billion (ppb).
The clock generator within eNodeB generates the bit, basic frame, hyper frame, CPRI-10ms frame
and BS super frame synchronization signals from a timing source input signals (such as local GPS,
syncE, IEEE1588v2…).

Engineering: <eNodeB> <Synchronization> <Standard>
3GPP TS36.104 [R6] specifies different air interface synchronization accuracy requirements
according to the Base Station class:
BS class Accuracy
Wide Area BS ±0.05 ppm
Local Area BS ±0.1 ppm
Home BS ±0.25 ppm
ALU Macro eNB is classified within the “WideArea BS”.
ALU MetroCell is classified within the “Local Area BS”.

Then the frequency reference source(s) must deliver a signal of sufficient accuracy and the
synchronization network must be designed to ensure the eNodeB RF carrier meets this requirement.
LTE networks require phase synchronization to meet the TDD air interface criterion of ± 1.5us.
RF frame timing delivery to meet the TDD specifications also includes delivery of correct SFN
numbering. This is needed for features which require the RF frames to be aligned across
neighbouring eNodeB’s both in phase and in SFN count.
The eNodeB supports multiple synchronization methods which are presented hereafter.
5.4.1 Local GPS
Using a local GPS receiver for synchronization.
5.4.2 Synchronous Ethernet

The layer 1 Ethernet physical clocks are traceable to a PRC.
The clock is recovered from the physical Ethernet received bit stream.
Each transport node within the Ethernet/IP network automatically lock onto the physical layer clock
and must support traceability to PRC on its egress ports.

Figure 50: Synchronous ethernet concept
There is a synchronization signaling system known as the Synchronization Status Message or SSM.
The SSM is a message which carries an information about the quality level of the source clock from
clock to clock along the branches of the synchronization distribution tree. There are a number of
pre-defined quality levels (QL) corresponding to existing clock specifications i.e. QL-PRC, QL-SSU-A,
QL-SSU-B, QL-SEC and QL-DNU.
This signaling system is used for controlling protection switching in case of link or clock failures.
The communication channel used for transferring the SSM from clock to clock in Synchronous
Ethernet is the so-called Ethernet Synchronization Messaging Channel (ESMC).
The ESMC structure, and the SSM TLV is described in G.8264.
The definition of the Quality Levels of the source clock are defined in G.781.
Ethernet Synchronization Messaging Channel (ESMC):

The ESMC is a communication channel for the Synchronization Status Message (SSM).
The ESMC is based on an Ethernet protocol called Organization Specific Slow Protocol (OSSP) (as
described in G.8264 section 11 and IEEE802.3).
There are two types of ESMC messages;
• the Information Message is sent once per second and acts like a heartbeat.
• the Event Message is sent immediately after an event which causes the SSM value to change.
Both message types convey the SSM.
This system ensures a short reaction time despite the fact that the average message rate is around
one message per second. A clock considers that the incoming ESMC is in failure condition if no
Information Message (heartbeat) has been received within a 5 second period.

Octet number Size (byte) Field Content (hex)

Slow Protocols Multicast address
1-6 6 Destination Address
(01-80-C2-00-00-02)
7-12 6 Source Address Port’s MAC address
13-14 2 Slow Protocol Ethertype 88-09
15 1 Slow Protocol Subtype 0A
16-18 3 ITU OUI 00-19-A7
19-20 2 ITU Subtype 01
4 bits Version 01
0 for Information PDU
21 1 bit Event Flag
1 for Event PDU
3 bits Reserved
Reserved for future standardization
22-24 3 Reserved
25-1532 36 to 1490 Data and padding See details hereafter
Last 4 4 FCS Frame Check Sequence
Table 5: ESMC PDU format
Size Field Content (hex)
1 octet Type 01
2 octets Length 04
4 bits Unused 0
4 bits SSM SSM code
Table 6: Details of the Data and Padding field
The syncE Quality Level are defined in the following table:
SSM QL G.781 PTP clockClass

Option I Option II Option III
0001 QL-PRS 80
0000 QL-STU QL-UNK 82
0010 QL-PRC 84
0111 QL-ST2 86
0011 88
0100 QL-SSU-A QL-TNC 90
0101 92
0110 94
1000 QL-SSU-B 96
1001 98
1101 QL-ST3E 100
1010 QL-ST3/QL-EEC2 102
1011 QL-SEC/QL-EEC1 QL-SEC 104
1100 QL-SMC 106
1110 QL-PROV 108
1111 QL-DNU QL-DUS 110
Table 7: syncE Quality Levels

5.4.3 IEEE 1588 v2 – Precision Time Protocol (PTP)
PTP is a timing over packet (ToP) method for synchronizing a client to a server.
As per IEEE 1588 standard, PTP is supported over protocol stacks UDP/IP/Ethernet and Ethernet.
The 1588 server may support clients in either multicast mode, where all clients receive the
multicast timing messages, or unicast mode where each client has is own targeted timing messages.
Multicast mode allows a server to support more clients, however, unicast mode is considered the
option delivering the best synchronization accuracy.
Master Slave
clock clock
Request unicast transmission

Client sends a Request unicast transmission message to the
grandmaster server(s). A request message is sent for each
type of message the grandmaster transmits (Announce,
Sync, Delay resp, Pdelay resp).
Grant unicast transmission
The Follow up message rate takes the rate of Sync
messages. The Request unicast transmission message
contains information fields which define the intermessage
Cancel unicast transmission interval for the considered message type and the duration
of the unicast grant.
The grandmaster responds with a Grant unicast

transmission message confirming or not the grant requested
Ack cancel unicast transmission by the client (intermessage interval for the considered
message type and duration of the unicast grant).
If the grandmaster can no longer support unicast, it sends a
Cancel unicast transmission message which the client
acknowledges with the Ack cancel unicast transmission
message.
Figure 51: Unicast negociation

7 6 5 4 3 2 1 0 bits
transportSpecific messageType e.g. 0xC = Unicast
reserved versionPTP
MessageLength
domainNumber
Reserved
flagField
correctionField
reserved
sourcePortIdentity
sequenceId
controlField
logMessageInterval interval between message type considered below
targetPortIdentity
tlvType e.g. 0x4 = Request, 0x5 = Grant
lengthField
messageType reserved e.g. 0x0 = Sync, 0xB = Announce, 0x9 = Delay resp
logInterMessagePeriod period between requested unicast messages
durationField duration this message type must be transmitted
Figure 52: Request unicast transmission message structure

Master Slave
clock clock
δt = logMessageInterval
Sync δt = logInterMessagePeriod
durationField Sync
Sync
Figure 53: PTP periodical Unicast negociation and time stamp exchange
logInterMessagePeriod and logMessageInterval are given in the logarithm, to base 2, of the

requested mean period or interval, in seconds, between the messages.
The conversion from interval in second to/from interval in log base 2 are given by the formulae:
• interval in log base 2 = log2 (interval in second)

log2 (interval in second)
• interval in second = 2
1
• message rate =
log 2 (interval in second)
2

Interval in log2(interval) Interval in second message rate
-6 1/64 64 /s
-5 1/32 32 /s
-4 1/16 16 /s
-1 1/2 2 /s
0 1 1 /s
1 2 1 every 2 s
6 64 1 every 64 s
Synchronization is distributed via packets that carry time stamps generated by a master (server)
that has access to a PRC (e.g. GPS). The receiving equipment (slave) recovers the frequency
synchronization by comparing the time provided by the timing packets (time stamps) with its local
time.
The network between the master and the slave introduces packet delay, packet delay variation
(PDV) and packet loss.
To be able to guarantee frequency synchronization in the order of parts-per-billion, the slave must
be able to filter out the effects of PDV. Therefore, selection of the less delayed timing packets or
averaging over relatively long periods are needed at client for stable performance. Beside, the SLA
(Service Level Agreement) between the operator and the backhaul transport network provider must
ensure that the synchronization traffic flow benefits a consistent PDV regarding the ToP
requirements. The link from grandmaster to client should minimize the number of hops since the
forwarding algorithms of intermediate transport equipment introduce PDV. And the synchronization
traffic flow must be marked with the highest QoS priority.
In add of frequency synchronization, IEEE 1588 also supports time and phase synchronization.
PTP messages are divided into two categories:

• event messages are timestamped messages that are generated in both the receiving and the
transmitting end. The instance when the timestamp point passes in or out of the interface is
accurately recorded.
• general messages do not require timestamps but may contain one.
Event messages General messages

Announce server client
Sync server client Follow up server client
Delay req server  client Delay resp server client
Pdelay req peer peer Pdelay resp follow up peer  peer
Pdelay resp peer  peer Management server client
Signaling server client
Table 8: IEEE 1588v2 message types

Announce: The grandmaster server periodically transmits an Announce message to each client. The
Announce message is used to establish the synchronization hierarchy. Announce messages provide
status and characterization information of the transmitting node and its grandmaster. This
information is used by the receiving node when executing the best master clock algorithm. The
client requests the Announce intermessage period in the Request unicast transmission message for
Announce messages.

7 6 5 4 3 2 1 0 bits
transportSpecific messageType 0xB = Announce
reserved versionPTP
MessageLength
domainNumber
Reserved
flagField
correctionField
reserved
sourcePortIdentity
sequenceId
controlField
logMessageInterval
originTimestamp time the Announce was transmitted at origination
currentUtcOffset from timePropertiesDS data set
reserved
grandmasterPriority1 from parentDS data set
(2)
grandmasterClockQuality from parentDS data set
grandmasterPriority2 from parentDS data set
grandmasterIdentity from parentDS data set
stepsRemoved from currentDS data set
(1)
timeSource from timePropertiesDS data set
(1) timeSource indicates the reference time source of the grandmaster clock (e.g. a GPS radio
clock).
(2) grandmasterClockQuality contains as information elements:
• clockClass, which indicates the traceability of the time or frequency distributed by the
grandmaster.
In W-CDMA, the only acceptable clockClass values are:

• 6 (grandmaster is synchronized to a primary reference time source)
• 13 (grandmaster is synchronized to an application-specific time source)
• clockAccuracy which indicates the quality of the grandmaster clock. It is used in the BMC
algorithm (if implemented).

clockAccuracy value
CLK_Q_CLK_EPOCH_BETTER_THAN_25ns 0x20
CLK_Q_CLK_EPOCH_BETTER_THAN_1us 0x23
CLK_Q_CLK_EPOCH_BETTER_THAN_2_5us 0x24
CLK_Q_CLK_EPOCH_BETTER_THAN_1ms 0x29
CLK_Q_CLK_EPOCH_BETTER_THAN_2_5ms 0x2A
CLK_Q_CLK_EPOCH_BETTER_THAN_10ms 0x2B
CLK_Q_CLK_EPOCH_BETTER_THAN_25ms 0x2C
CLK_Q_CLK_EPOCH_BETTER_THAN_100ms 0x2D
CLK_Q_CLK_EPOCH_BETTER_THAN_250ms 0x2E
CLK_Q_CLK_EPOCH_BETTER_THAN_1s 0x2F
CLK_Q_CLK_EPOCH_BETTER_THAN_10s 0x30
CLK_Q_CLK_EPOCH_WORSE_THAN_10s 0x31
CLK_Q_CLK_EPOCH_UNKNOWN 0xFE

An ordinary clock maintains the following clock data sets:
Data Set Description Attributes
twoStepFlag
clockIdentity
numberPorts
defaultDS ordinary clock
clockQuality
priority1
priority2
stepsRemoved
currentDS synchronization offsetFromMaster
meanPathDelay
parentPortIdentity
parentStats
observedParentOffsetScaledLogVariance
observedParentClockPhaseChangeRate
parentDS parent & grandmaster
granmasterIdentity
grandmasterClockQuality
grandmasterPriority1
grandmasterPriority2
currentUtcOffsetValid
leap59
leap61
timePropertiesDS timescale timeTraceable
frequencyTraceable
ptpTimescale
timeSource
Sync (and optionally Follow up): The grandmaster server periodically transmits a Sync (optionally
with Follow up) message to each client. The client requests the Sync intermessage period in the
Request unicast transmission message for Sync messages.

7 6 5 4 3 2 1 0 bits
transportSpecific messageType 0x0 = Sync
reserved versionPTP
MessageLength
domainNumber
Reserved
flagField If twoStepFlag bit is FALSE then no Follow up message is sent
correctionField
reserved
sourcePortIdentity
sequenceId
controlField
logMessageInterval
originTimestamp time the Sync was transmitted at origination
7 6 5 4 3 2 1 0 bits
transportSpecific messageType 0x8 = Follow up

reserved versionPTP
MessageLength
domainNumber
Reserved
flagField
correctionField
reserved
sourcePortIdentity
sequenceId
controlField
logMessageInterval
preciseOriginTimestamp precise time the Sync was transmitted at origination
Delay req (*): The client may request periodically Delay information by invoking the Delay req
message.
Delay req message transmission interval: This value is determined and advertised by a master clock
based on the ability of the master clock to process the Delay req message traffic. The value shall be
an integer with the minimum value being portDS.logSyncInterval, i.e., at the same rate as Sync
messages, and a maximum value of logSyncInterval+5.

7 6 5 4 3 2 1 0 bits
transportSpecific messageType 0x1 = Delay req
reserved versionPTP
MessageLength
domainNumber
Reserved
flagField
correctionField
reserved
sourcePortIdentity
sequenceId
controlField
logMessageInterval Delay req message transmission interval
originTimestamp time the Delay req was transmitted at origination
Delay resp (*): The client requests the Delay_Resp intermessage period in the Request unicast
transmission message for Delay_Resp messages.
7 6 5 4 3 2 1 0 bits
transportSpecific messageType 0x9 = Delay resp
reserved versionPTP
MessageLength
domainNumber
Reserved
flagField
correctionField
reserved
sourcePortIdentity
sequenceId
controlField
logMessageInterval
receiveTimestamp time the Delay req was received
requestingPortIdentity
(*) The use of Delay req and Delay resp offer more timing information to the client. There are
optional in the 1588 protocol for frequency synchronization.
Management: Management messages communicate information and commands used to manage

clocks.
Signaling: Signaling messages carry information, requests, and commands between clocks. It is used
by the client to initiate a Unicast negiciation and to periodically renew unicast grants for each
message type (Announce, Sync, Delay resp, Pdelay resp).

PTP can be implemented with or without On-Path Support. On-Path Support is for removing effects
caused by queuing and other delays in network nodes.
IEEE 1588v2 defines five types of clock devices: ordinary clock, boundary clock, end-to-end
transparent clock, peer-to-peer transparent clock and management node.
Ordinary clocks, either grandmaster or slave, are the end points of synchronization network.
Boundary and transparent clocks are intermediate nodes that provide the On-Path Support for the
end points.
When using boundary clocks, the master-slave architecture is constructed hop-by-hop with all the
intermediate nodes between the end points being boundary clocks. Boundary clock works as a
master for next hop and a slave for previous hop. It terminates and regenerates the packet
timestamps.
Transparent clock is a bridge between the master and the slave. It is transparent to the PTP
messages except that it corrects the timing messages by adding processing time (a.k.a residence
time) into a correction field while forwarding them. The end-to-end transparent clock only adds the
residence time of packet to the correction field, which does not require any hop-by-hop messaging.
Peer-to-peer transparent clock adds also link delay correction information to the header of timing
packets, which requires peer-to-peer messaging.
5.4.3.1 Principles of time synchronization with PTP
It begins by determining the mean propagation delay between master and slave. After which only
one time stamped sync message is needed to make the clock corrections at the slave by adding the
one-way propagation delay in downlink to the time reference delivered within the Sync message.
Master Slave
clock clock
t1: the master sends a Sync to the slave.

t1 Sync (with t1 or not)
t2: the slave receives the Sync.
If t1 is embedded in Sync this a one-step transfer.
t2 If the grandmaster is able to determine the precise t1 only after
Follow up (with t1)
the Sync has been sent then it is sent in the Follow up message.
This a two-step transfer.
t3: the slave sends Delay request (**) to the master.
t4: the master receives the Delay request and responses with
the Delay response (**) with the precise reception time t4.
Delay req. t3
(*)
The use of Delay request and Delay response are optional for
t4 frequency synchronization
Delay resp. (with t4)
Figure 54: Two-way propagation delay determination in PTP
With the (t1..t4) timestamps the slave can determine:

• the Round Trip Time, RTT = (t2-t1)+(t4-t3)
• the mean propagation delay, mpd = RTT/2

• the downlink propagation delay = t2-t1

• the uplink propagation delay = t4-t3
5.4.3.2 Principles of frequency synchronization with PTP
Master sends the Sync timing packets (with timestamps) to the slave at a certain rate in packets per
second (pps) (but not necessarily at fixed intervals).
The receiver records the time when packets are received after which the local interval between two
received packets is compared to the difference between the timestamps. The time stamps inside
the consecutive packets are compared with local arrival times.
Master Slave
clock clock
t0 = 0 s Sync (timestamp = 0 s) f’/f – 1 = [(t1’ – t0’)/(t1– t0)] – 1

= – 0,000001
t0’ = 0 s Slave clock is 1 ppm too slow and must
t1 = 1 s Sync (timestamp = 1 s) increase its frequency clock by 1 ppm.
t1’ = 0,999999 s
Figure 55: Principle of frequency synchronization
Theorically one can determine the frequency error of the local clock compared to the reference by
sending two packets. In reality it is more complex due to PDV.
PTP PTP
server client
1st timing packet delay = 20 ms

t0 = 0 s 2nd timing packet delay = 26 ms
f’/f – 1 = [(t1’ – t0’)/(t1– t0)] – 1
Sync (T1) delay = 20 ms = 0,005999
Slave clock is mistakenly considered 5999 ppm too
t0’ = 0,02 s fast. But as PDV = 6 ms slave clock is actually only 1
ppm too slow.
t1 = 1 s
Sync (T1) delay = 20 ms + 6 ms (PDV)
t1’ = 1,025999 s
Figure 56: PDV impact on frequency synchronization
Constant packet Latency is not an issue for 1588 when delivering Frequency Synchronization.
But PDV introduced by the synchronization transport backhaul requires that packet selection or
averaging methods are implemented at slave PLL, and that PDV is removed or minimized for the PTP
traffic within the network.

5.5 EUTRAN AND EPC IP ADDRESS REQUIREMENT

The size of each subnet depends on the number of network elements existing on the same site and
connected to the same LAN.
Two subnets type are deployed Routable subnets and Non routable ones.
The Routable subnets are the ones which are advertised to the ePC or to the eUTRAN Network.
The non routable subnets are local to the segment and not advertised for the rest of networks.
The routable subnets in the eUTRAN network are the OAM and TELECOM subnets. These two subnets
are transported on different VLANs and terminated on the Access Router and the ePC side.
Static or Dynamic routing can be used to transport these networks to the ePC.
The non routable subnets concerns mainly the interface which communicate only locally and not
need to be advertised to the external network.
The figure below resumes the whole defined subnets and their functional description.
Figure 57: General Overview of IP Subnets in LTE network

NETWORK SUBNET NAME VLAN reference

EUTRAN_OAM 1 VLAN:‘OAM’
eutran EUTRAN_TELECOM 1 VLAN per eNodeB for S1-MME, X2, S1-U: ‘EU-TELECOM’
EUTRAN_PDM-SUB (opt.) 1 VLAN per ENodeB: ’EU-DEBUG’
EPC_MME 1 VLAN for S1-MME, S101, S10, S6a, S11: ‘EPC-MME’
ePC EPC_S1-U 1 VLAN for EPC-S1-U: ‘EPC-S1’
EPC_S5_S8 (Sgi) 1 VLAN: ‘EPC-SGI’
Table 9: Summary of Defined subnets and associated Vlan(s)
5.6 UE IP ADDRESS REQUIREMENT

Address allocation can utilize an external DHCP server or Local DHCP server functions on the PGW.
Alternatively, an IPv4 address can be allocated to a UE at attach from a pool provisioned in the P-
GW.
The pool is defined with a list of private or public IP@ range.
The range may be defined in two ways:
• Range = First IP@, last IP@ and sub network mask, or
• Range = IP@ and sub network mask
5.6.1 DL UE PDU Routing function

The SGI interface is connected to the IP application domaine. A static route should be configured on
the S-GW enabling to route DL UE PDU. The route defines that the next hop for a DL UE PDU is the
sgi IP address of the P-GW.
The DL UE PDU is encapsulated within a GTP-U tunnel. The GTP-U PDU is sent to the next hop router
address connected to the S1-U interface.
Note: in order to enable routing of DL UE PDU within the application service domain, the router
shall advertise the UE subnet IP address. This is out the scope of this document.
Typically, dynamic IP addressing may be configured on the router, and the static route redistributed
within the dynamic routing protocol.
5.6.2 UL UE PDU Routing function
The P-GW receives a UL GTP-U PDU. The UL UE PDU is extracted from the GTP-U packet. The UL UE
PDU is sent to the next hop router connected to the sgi interface, which is able to route the packet
et the external network.
5.7 END TO END PERFORMANCE

The following are the ALU targets/budgets allocated for each of the network elements for delay:

Entity (Delay msec) Min Avg Max

UE(Data) 2 3 5
UE (VOIP Bearer) 32 33 35
eNodeB 2 4 8
Air interface 1 12,8 48
Transport 1 5 10
SGW 0.1 0.1 0.2
PGW 0.1 0.1 0.2
Intra eNodeB HO interruption 24 26 30
Table 10: User Plane Delay Budgets

• UE (data) – This is the (one way UL or DL) delay for processing a user bearer packet (non-VOIP
packets). It includes delays required to receive/transmit the packet (e.g., processing the PDCP,
RLC, MAC, Phys layers for the UL/DL).
• UE (VOIP) – The one way delay (UL) associated with processing VOIP packets (20 msec for
encoding, 10 msec look ahead), plus processing delay to receive/transmit the packet.
• eNodeB – One way Delay associated for processing (including delays with Rx/Tx) a bearer packet
(DL/UL).
• Air Interface – The air interface delay estimate is based on following assumptions:
• Min value assumes no HARQ retransmissions;
• Avg value assumes 1.6 HARQ retransmissions
• Max value assumes 6 HARQ retransmissions.
• Transport - Includes delay associated with backhaul and core transport (e.g., delay from eNodeB
to PDNGW). The assumption is that the EPC core (PGW) will be located in a regional center (for
every 100 miles there is 1 msec of delay)
• SGW/PGW – Delays associated with processing bearer packets in the SGW and PGW are assumed
to be the same (note that this is assuming that the PGW is from ALU).
• Intra-eNodeB HO interruption – This is the interval (during intra-eNodeB HO) starting from the
time the UE disconnects from the source eNodeB until is re-connected with the target eNodeB. Note
that current assumption is that the source eNodeB will not forward packets that are received during
this interval. Given the small interruption time this may not be an issue.
The following table provides delays (one way end to end delay) associated with different
services/scenarios (based on above delay budgets).
One way Delay (msec) Min Avg Max

Data UE to PDN 6 25 71
VOIP UE to PDNGW 36 55 101
VOIP UE to PSTN user 81 100 146
VOIP UE to UE (LTE) 72 110 203
Table 11: User Plane End to End Delays

Data UE to PDN – This is the one way delay for sending a bearer packet from the UE to the PDNGW.
The PDB associated with Real Time Gaming service is the smallest delay required (from all services),
which is 30 msec (excluding transport delay). Our average estimate would be 20 msec (excluding 5
msec transport delay).
VOIP UE to PDSNGW - This is the one way delay for sending a VOIP bearer packet from the UE to the
PDNGWY. Includes the additional overhead in the UE to encode the voice frames.

VOIP UE to PSTN user – This is the one way delay for sending a VOIP packet from the UE to a PSTN
end user. It includes the processing delay in a MGW (25 msec), IP core network (10 msec), and PSTN
(10 msec). Based on ITU-T G.114 VOIP Latency Guidelines, the max allowable end to end delay
should be <= 280 msec (highest quality requires <= 200 msec).
VOIP UE to UE (LTE) – This is the one way delay for sending a VOIP bearer packet from the UE (LTE
network) to another end user (UE) in an LTE network. It assumes that there is no transcoding
required.
5.8 BIDIRECTIONAL FORWARDING DETECTION (BFD)

5.8.1 BFD Concept
An increasingly important feature of networking equipment is the rapid detection of communication
failures between adjacent systems, in order to more quickly establish alternative paths. Detection
can come fairly quickly in certain circumstances when data link hardware comes into play (such as
Synchronous Optical Network (SONET) alarms). However, there are media that do not provide this
kind of signaling (such as Ethernet), and some media may not detect certain kinds of failures in the
path, for example, failing interfaces or forwarding engine components.
The goal of Bidirectional Forwarding Detection (BFD) is to provide low-overhead, short-duration

detection of failures in the path between adjacent forwarding engines, including the interfaces,
data link(s), and, to the extent possible, the forwarding engines themselves.
BFD is designed to detect failures in communication with a forwarding plane next hop. BFD operates
on top of any data protocol (network layer, link layer, tunnels, etc.) being forwarded between two
systems. It is always run in a unicast, point-to-point mode. BFD packets are carried as the payload
of whatever encapsulating protocol is appropriate for the medium and network. BFD may be
running at multiple layers in a system. BFD can provide failure detection on any kind of path
between systems, including direct physical links, virtual circuits, tunnels, MPLS Label Switched
Paths (LSPs), multihop routed paths, and unidirectional links (so long as there is some return path,
of course). Multiple BFD sessions can be established between the same pair of systems when
multiple paths between them are present in at least one direction. The BFD state machine
implements a three-way handshake, both when establishing a BFD session and when tearing it down
for any reason, to ensure that both systems are aware of the state change.
BFD is a simple layer 3 Hello protocol. A pair of systems transmit BFD packets periodically over each
path between the two systems, and if a system stops receiving BFD packets for long enough, some
component in that particular bidirectional path to the neighboring system is assumed to have failed.
A path is only declared to be operational when two-way communication has been established
between systems, though this does not preclude the use of unidirectional links.
A separate BFD session is created for each communications path and data protocol in use between
two systems. A BFD session is established based on the needs of the application that will be making
use of it. It is up to the application to determine the need for BFD, and the addresses to use --
there is no discovery mechanism in BFD.

5.8.1.1 BFD Operating Modes
BFD has two operating modes that may be selected, as well as an additional function that can be
used in combination with the two modes.
The primary mode is known as Asynchronous mode. In this mode, the systems periodically send BFD
Control packets to one another, and if a number of those packets in a row are not received by the
other system, the session is declared to be down.
The second mode is known as Demand mode. In this mode, it is assumed that a system has an
independent way of verifying that it has connectivity to the other system. Once a BFD session is
established, such a system may ask the other system to stop sending BFD Control packets, except
when the system feels the need to verify connectivity explicitly, in which case a short sequence of
BFD Control packets is exchanged, and then the far system quiesces. Demand mode may operate
independently in each direction, or simultaneously.
An adjunct to both modes is the Echo function. When the Echo function is active, a stream of BFD
Echo packet is transmitted in such a way as to have the other system loop them back through its
forwarding path. If a number of packets of the echoed data stream are not received, the session is
declared to be down. The Echo function may be used with either Asynchronous or Demand mode.
Since the Echo function is handling the task of detection, the rate of periodic transmission of
Control packets may be reduced (in the case of Asynchronous mode) or eliminated completely (in
the case of Demand mode).
5.8.1.2 BFD Control, Echo and Timers
BFD consists of control and optional echo packets. Asynchronous mode control packets are used to
maintain state and test the forwarding plane. The Echo packets are optionally used in conjunction
with the control packets to minimize the use of control packets. This reduces overhead. Demand
mode is used in networks that have large number of BFD sessions.
If Echo function is not requested, the control packets are sent at a high rate to achieve the desired
detection time. If the Echo function is negotiated, control packets are sent at a slow rate and the
self directed echo packets are sent at a high rate.

The Control packet consists of 24 bytes with an optional 4 bytes for authentication. Figure below
depicts the control packet format. The first 2 bytes are used for version, diagnostic
agnostic and control bits.
The receiving systems detection time in Asynch
Asynchronous
ronous mode is determined by multiplying the
detection time multiplier and the negotiated transmit interval.
My Descriminator and Your Descriminator fields are nonzero value generated by the transmitting
and receiving system respectively. The values are used to distinguish BFD sessions between the
same hosts. The Desired Minimal TX Interval field is the number if milliseconds that the local system
would like to use when transmitting BFD Control packets, less any jitter applied. The Required Min
RX Intervall is the number of milliseconds between received BFD Control packets that this system is
capable of supporting, less any jitter applied by the sender. If this value is zero, the transmitting
system does not want the remote system to send any periodic BFD C Control
ontrol packets. The Required
Min Echo RX Interval is the minimal interval, in microseconds, between received BFD Echo packets
that this system is capable of supporting, less any jitter applied by the sender. If this value is zero,
the transmitting system does not support the receipt of BFD Echo packets.
The four authentication bytes are detailed in IETF RFC 5880 and will not be discussed in the
document since it will not be implemented in the nodes.
Alcatel-Lucent

Figure 58: BFD Control Packet
The only requirement is that sufficient information is included to demultiplex the received packet
to the correct BFD session after it is looped back to the sender.
5.8.1.3 BFD Session
Both Peers of the BFD session will be manually provisioned. One of the Peers must be taken an
active role while the second
econd BFD peer will take on either a passive or active role. The BFD Peer that
takes the active role will send Control Packets to passive BFD session. The Passive BFD peer will not
send control packets until it receives a control BFD packet from its peer tto
o learn the “My
Descriminator” value. A session begins with the periodic, slow transmission of BFD Control Packets.
When bidirectional communication is achieved, the BFD session becomes up.
Alcatel-Lucent

5.8.1.4 BFD Session Failure
• Asynchronous mode (non-echo)

echo)
– Calculated by (remote Detect Mult) * (TX interval)
– Detect Mult is how many sequential packets
packets can be missed before declaring down
• Asynchronous mode (echo)

– Detection Time Calculated by (local Detect Multiplier) * (local Echo RX interval)
– Loss of ‘local Detect Multiplier’ # of sequential packets causes failure
• Demand mode
– Calculated only during Poll Sequence
– Calculated by (Detect Multiplier) * (local TX interval)
Alcatel-Lucent

6 MACRO ENB TRANSPORT IMPLEMENTATION

This chapter covers the description of the eNB ALU design.
6.1 ETHERNET
6.1.1 Backhaul connectivity
eNB Gigabit Ethernet backhaul interface is provided by eCCM/eCCM2/eCCM2-HR.
Note: eCCM2 and eCCM2-HR boards have exactly the same architecture. eCCM2-HR is a “functional
variant” of eCCM2.
eNB controller type configuration is done through:
• Object: Enb, Parameter: expectedControllerType, Value: [eCCM, eCCM2, MET3C1, SDCAM], Class:
C, Service Impact: None, Update transient impacts details: Immediate-propagation
eCCM/eCCM2/eCCM2-HR backhaul interfaces can provide:

• different kind of media: copper (RJ45 connector) or fiber (SFP connector)
• different transmission mode: half or full duplex
• different speed: 10Mbps, 100Mbps, 1000Mbps.
Auto-negotiation allows to each device to provide an ordered list of speed/operational mode it
supports. It avoids on-site commissioning to configure the PHY layer according to the type of PHY
layer supported by the peer equipment used to access the backhaul. The devices choose the first
common speed/operational mode to establish the link. Auto-negotiation is defined in Clause 28 of
IEEE 802.3.
eCCM/eCCM2/eCCM2-HR backhaul interfaces support the following characteristics:

Connector type RJ45 (2) SFP (2)
Media Electrical Optical Electrical (1)
CCM type
all all eCCM only
(eCCM, eCCM2, eCCM2-HR)
Auto-Negotiation Enabled (3) Enabled (4)

configuration
eN B default
Same as for RJ45

1000 mbps & half+full
Speed & Duplex mode
100 mbps & half+full 1000 mpbs & full (5)(6)
advertisement
10 mbps & half+full
(1) SFP cage allows the use of electrical transceiver.

(2) For RJ45: 1000BASE-T/100 BASE-TX/10 BASE-T. For SFP: 1000BASE-X.
See 802.3 : Section 2: 100 BASE-TX/100BASE-FX Clause 24 & Section 3: 1000BASE-T Clause
28 and 1000BASE-X Clause 37
(3) Note that auto-negotiation is always required for 1000BASE-T
(4) Ethernet standards for optical transceiver (100BASE-FX, 1000BASE-X) use different wavelengths
thus auto-negotiation across them is not possible. Thus no speed auto-negotiation.
(5) 100BASE-FX is not supported on optical port at eNB
(6) Only full duplex mode for 1000 Mbps on optical port.
Duplex mode mismatching considerations:
A link is degraded between a node and its peer if they are configured so that the duplex settings do
not match. That is, one is set to half-duplex and the other to full-duplex. With such configuration
on the link, when both devices send frames simultaneously the following occurs:
• The half-duplex link detects a collision, which corrupts its outgoing frame and discards the
incoming frame. The half-duplex link will attempt to retransmit the frame.
• The full-duplex link will not resend its frame. It determines that the incoming frame is bad
and flags cyclical redundancy check (CRC) errors.
• Applications will timeout and retransmit continuously, causing a very slow connection.
Note:
In case a node is configured with auto-negotiation while its peer is not configured with auto-
negotiation, then autonegotiation device correctly detects the speed of operation, but is unable to
correctly detect the duplex mode. As a result, it sets the correct speed but starts using the half
duplex mode.
If the peer is also set to half-duplex then the nodes interoperate (duplex modes are matching).
If the peer is set to full-duplex then the nodes have an interoperability issue (duplex modes are
mismatching).

Engineering: <eNodeB> <Ethernet>
eNB is configured by default with duplex auto-negotiation.
The table below summarizes all possible combinations of duplex settings between eNB and its peer:
eNB’s eNB’s peer May eNB

Chosen duplex
duplex duplex interoperate with its
mode
configuration configuration peer?
half-duplex or
auto-negotiation
full-duplex
yes
auto-negotiation half-duplex half-duplex
duplex mode
full-duplex no
mismatching
Restriction: <eNodeB> <Ethernet> <Design>
It is not supported at OAM to:

• display backhaul ports characteristics
• configure the backhaul port characteristics
Rule: <eNodeB> <Ethernet> <Design>
eNB supports one MAC address dedicated to 1588 flow, and one MAC address dedicated to
OAM/Telecom… flow.
A dedicated MAC@ for 1588 enforces a dedicated IP@ for 1588: an ARP for 1588 IP@ gives the 1588
MAC@ and an ARP for OAM and/or Telecom gives the OAM and/or Telecom MAC@.
6.1.1.1 eCCM
For eNB equipped with eCCM, the Gigabit Ethernet interface is provided through the use of the GbE
MDA which is the daughterboard of the eCCM.

Figure 59: eCCM front panel
As per eNB design, the eCCM GbE MDA provides 2 GbE ports for connecting to the backhaul:
• 1 SFP module (SFP2), either equipped with optical or electrical TRX (1000BASE-X)
• 1 RJ45 (10/100/1000BASE-T)
eCCM only supports 1 SFP port out of the 2 SFP ports of the GbE MDA.
The only supported SFP port is SFP2.
eCCM does not support SFP1 port.
eCCM only supports 1000BASE-X (1000 Mbit/s Giga Ethernet) over optical SFP TRX.
eCCM does not support 100BASE-FX (100 Mbit/s Fast Ethernet) over optical SFP TRX.
The supported physical interfaces are sum up in the following table:
RJ45 SFP2
Electrical Optical Electrical
10 Mbps 100 Mbps 1000 Mbps 100 Mbps 1000 Mbps 10 Mbps 100 Mbps 1000 Mbps
yes no yes yes

A single GbE port may be used for connection with the backhaul.
In case both SFP2 and RJ45 ports are cabled then SFP2 has precedence over RJ45. That is, SFP2 is
used while RJ45 is invalidated.
The physical interface supports both user and control planes for all S1 & X2 logical connections,
in addition to the OAM traffic.
The GbE MDA also provides 1 RJ45 port for connecting a Local Maintenance Terminal (LMT).
Note: There is an EthernetPort object which parameters are not used in this release.

6.1.1.2 eCCM2
Also see eCCM2

eCCM
Linux Network P4080 ethBh
Interface Devices and
eth0
MAC Addresses.
BOARD_INIT_REQ.ExtMacAddress (from EEPROM )
INTERFACE_CONFIG_REQ(ipAddr , vlanId)[]
ethDebug
eth2
MAC from EEPROM
Port 1 192 .168. 10. 1
(for debug&
LMT access) NOTE: eNB DHCPv 4
server gives out
ethCallp
192.168 .10.2 address
eth3
to attached clients
MAC from EEPROM
192.168 .1.2
PCI
eth1588
1588 00:01:02:03: 04:05
tap
tap0 192.168.1.10
BOARD _INIT_REQ.1588 MacAddress (from
from EEPROM)
EEPROM (for internal ARP to BP ENET )
INTERFACE_CONFIG_REQ(ipAddr , vlanId
vlanId)
Port 2
(for port
mirroring)
Only one is supported at a time.
BH1/SFP
WP3 Ethernet modems
modems
Switch modem
BH3/RJ45
(BCM56334L)
not
WP3 used
192.168 .
BH2/SFP not used [128+LTE_cell_index ].
[Slot _ID]
(Slot_ID = 2, 3 or 4)
BH4/RJ45 not used
not
SYNCE Clock used SYNCE Clock
for BH1 for BH2
to SIB
SIB2
FPGA
BH1/BH2 BH3/BH4
SFP RJ45
Figure 60: eCCM2 front panel
Alcatel-Lucent

eCCM2 has 4 backhaul ports:

• 2 optical (SFP) ports, BH1 & BH2
• 2 electrical (RJ45) ports, BH3 & BH4

Only one backhaul port is supported at a time: either the first SFP port (BH1) or the first RJ45 port
(BH3).
The eCCM2 backhaul port is automatically detected at initialization time.

The selection algorithm for electing between BH1 (SFP) and BH3 (RJ45) is as follows:
BH1 BH3 Backhaul port

(SFP) (RJ45) elected
no signal no signal BH1 (SFP)
signal no signal BH1 (SFP)
no signal signal BH3 (RJ45)
signal signal BH1 (SFP)
6.1.2 Daisy Chaining
eCCM/eCCM2 only supports one Ethernet port that is used for backhaul access.
As consequence, eNB does not support daisy chaining to others equipments.
Note:
“Vlan” object owns a “chained” parameter that is not used in this release.
“Vlan” object owns "SlaPerVlanConfForChain" and "QueueAndSchedulerPerVlanConfForChain"

children that are not used in this release.

Frequency synchronization is required to provide high-quality clock synchronization over Ethernet
ports.
Synchronous Ethernet (SyncE) provides the required synchronization at the physical level. In SyncE,
Ethernet links are synchronized by timing their bit clocks from high-quality, stratum-1-traceable
clock signals.
The backhaul needs to be Ethernet synchronized from the master server till the eNodeB. Each boxes
(switch or router) in the network shall support the Ethernet synchronization from the ingress coming
from the SyncE server to the egress to the eNodeB.
Processing of DL Synchronization Status Messages (SSM) can be activated or de-activated.
SSM is used to follow the accuracy of the Master source.

Engineering: <eNodeB> <SyncE>
If SSM is disabled the eNB receives no indication of a loss of quality of the source SyncE clock, for
example when the upstream equipment Ethernet source clock fails due to a loss of its own
reference clock.
The eNB impact is that the RF carrier can be pulled ‘out-of-spec’.
It is not recommended to disable SSM, whilst allowed given that certain equipments do support
SyncE but not SSM.
A specific alarm is generated when the SSM indicates the upstream equipment can no longer
guarantee a clock of sufficient accuracy. This alarm is ONLY available when SSM functionality is
enabled.
In case of syncE failure an alarm is raised.
RJ45 is SyncE compliant.
Optical SFPs are SyncE compliant while electrical SFPs are not SyncE compliant.
Restriction: <eNodeB> <syncE> <Design>
The only solution for electrical connection with syncE is through the RJ45 port.
The only solution for optical connection with syncE is through the SFP2 port.
The supported physical interfaces for syncE are:
Connector type RJ45 SFP
Media Electrical (copper) Optical (fiber) Electrical (cooper)
syncE supported ? Yes Yes No
The Ethernet ports that support syncE are:
RJ45 SFP
Electrical (copper) Optical (fiber) Electrical (cooper)
eCCM RJ45 SFP2 no
eCCM2 BH3 BH1 no
SyncE configuration is done through:

• Object: Enb/ClockSync,
Parameter: syncEClockEnable, Value: [true, false], Class: A, Service impact: Critical, Update
transient impacts details: full-eNB-reset
Parameter: clockSyncSourcePriorityList, Value: externally-synchronized-mode-1-synce, Class: C,
Service Impact: None, Update transient impacts details: Immediate-propagation
Note: clockSyncSourcePriorityList values are [free-running-internal-oscillator (0), gps-
synchronised-gps (1), externally-synchronised-mode-1-synce (2), externally-synchronised-mode-

2-ptp1588 (3), externally-synchronised-mode-3-ext-clock (4), externally-synchronised-mode-4-

satellite (5), clock-master-bs (6), externally-synchronised-mode-5-1PPSAndTOD(7), externally-
synchronised-mode-6-synceAndptp1588 (8)]
Parameter: syncEsupportSSM, Value: true/false, Class: C, Service Impact: None, Update transient
impacts details: Immediate-propagation
Engineering: <eNodeB> <syncE>
Default setting for SyncE activation is;

Enb/ClockSync:syncEClockEnable = true
Enb/ClockSync:clockSyncSourcePriorityList = {externally-synchronized-mode-1-synce, [gps-
synchronized-gps], free-running-internal-oscillator}
Note: SyncE must be first in the list to have precedence over the others methods in the list. Gps
synchro may back-up SyncE as an option. Internal oscillator must be last in the list.
Enb/SyncEClockSync:syncEsupportSSM = true
6.1.3.1 Simultaneous SyncE+PTP (TDD only)
eNB supports SyncE+PTP. This is covered in § ‘IEEE 1588V2 INTERFACE’.
6.1.4 VLAN – single operator

Note: single operator means eUTRAN sharing between several operators is not activated.
At eNodeB we can have OAM, 1588 & Telecom traffics organized within no VLAN at all, or within 1
to 4 VLANs.
Rule: <eNodeB> <Vlan> <Design>
ALU eNodeB supports up to 4 VLANs.
Restriction: <eNodeB> <Vlan> <Design>
OAM traffic must be mapped on the first TrafficDescriptor instance of the first VLAN instance.
That is, value ‘OAM’ must be in ‘Vlan/1 TrafficDescriptor/0 trafficTypeList’.
Restriction: <eNodeB> <Vlan> <Design>
M1 must be mapped on a dedicated VLAN.

Either IPv4 addresses or IPv6 addresses are supported in a VLAN. It is not possible to have
simultaneously IPv4 and IPv6 addresses in a VLAN.
The traffic flows within one VLAN instance is only IPv4 or IPv6.
IPv4 addresses are supported with untagged and tagged Ethernet frames.
IPv6 addresses are not supported with untagged Ethernet frames.
By default, eNB is pre-configured at factory with a OAM VLAN ID of “no Vlan” (untagged frames).
At I&C, eNodeB may be configured with a OAM VLAN ID.
It is replaced by provisioned OAM VLAN ID value once MIM has been downloaded.
The supported VLAN configurations in terms of combinations of IP version, number of IP addresses

and traffic flow(s) per VLAN are given hereafter.
6.1.4.1 Supported configuration with no VLAN
IP version(s) as well as number of IP @s supported per VLAN are given in the table below.
Traffic type
no VLAN
1588 OAM S1-U S1-C X2-U X2-C M3 M1 IGMPv3 MLDv2
0 IPv4@1 IPv4@2
Table 12: Supported configurations with untagged Ethernet frames
6.1.4.2 Supported configurations with 1 VLAN

Traffic type
VLAN 1
1588 OAM S1-U S1-C X2-U X2-C M3 M1 IGMPv3 MLDv2
1 IPv4@2 IPv4@1 IPv4@3
2 IPv4@1
3 IPv4@1 IPv4@2
4 IPv4@1 IPv4@2
5 IPv6@1 IPv6@2
Table 13: Supported configurations with 1 VLAN
6.1.4.3 Supported configurations with 2 VLANs
The 2 VLANs configuration is supported for separating traffic flows as follows:

Traffic type
VLAN 1
VLAN 2 1588 OAM S1-U S1-C X2-U X2-C M3 M1 IGMPv3 MLDv2
6 IPv4@2 IPv4@1 IPv4@3
7 IPv4@1 IPv4@2
8 IPv6@1 IPv6@2
9 IPv4@1 IPv6@2
10 IPv4@2 IPv4@1 IPv6@3
28 IPv6@2 IPv6@1 IPv4@3
29 IPv6@2 IPv6@1 IPv6@3
47 IPv6@1 IPv6@2 no IP@ IPv6@3
49 IPv6@2 IPv6@1 IPv6@3 IPv6@4 IPv6@3 IPv6@4 no IP@ IPv6@5
52 IPv4@2 IPv4@1 IPv6@3 IPv6@4 IPv6@3 IPv6@4 no IP@ IPv6@5
Table 14: Supported configurations with 2 VLANs

VLAN 1 Traffic type

VLAN 2
16 IPv4@1 IPv4@2 IPv4@3 IPv4@2 IPv4@3
20 IPv4@1 IPv4@2 IPv4@3
21 IPv4@1 IPv6@2 IPv6@3
22 Ipv6@1 IPv4@2 IPv4@3
23 IPv6@1 IPv6@2 IPv6@3
24 IPv4@2 IPv4@1 IPv4@3 IPv4@4 IPv4@3 IPv4@4
26 IPv4@2 IPv4@1 IPv4@3
27 IPv6@2 IPv6@1 IPv6@3
44 IPv4@2 IPv4@1 IPv4@3 IPv4@4
48 IPv6@2 IPv6@1 IPv6@3 no IP@ IPv6@4


VLAN 1 Traffic type

VLAN 2
VLAN 4

An operator is identified by a Public Land Mobile Network (PLMN) identifier which has a 3 digit
Mobile Country Code (MCC) and a 2 digit Mobile Network Code (MNC).
VLAN PLMN identifier configuration is done through:

• Object: Enb/EnbTransportConf/RanBackhaul/Vlan[1-50], Parameter: plmnId, Value: link to a
‘PlmnIdentity’ instance that contains the MCC and MNC of an operator, Class: A, Service impact:
Critical, Update transient impacts details: full-eNB-reset
VLAN instanciation is done through:

• Object: Enb/EnbTransportConf/RanBackhaul/Vlan[1-50], Parameter: vLanId = [2-4080; 4096],
Class: B, Service impact: Partial, Update transient impacts details: Transport-Layers
A friendly name can be associated to a Vlan:

• Object: Enb/EnbTransportConf/RanBackhaul/Vlan[1-50], Parameter: vlanName, Value: ascii
string with 1 to 64 characters (allowed characters: [A-Z-a-z], [0-9], underscore ‘_’), Class: C,
In Ipv4, to have no VLAN extension in the Ethernet header there must be configured at I&C:
Enb/EnbTransportConf/RanBackhaul/Vlan:vLanId = 4096
In this case parameter Enb/EnbTransportConf/RanBackhaul/Vlan:vLanId is ignored.
Traffic flows repartition per VLAN is done through:

• Object: Enb/EnbTransportConf/RanBackhaul/Vlan[1-50]/TrafficDescriptor[0-10], Parameter:
trafficTypeList = {Oam, S1u, S1c, X2u, X2c, 1588, M1], Class: A, Service impact: Critical, Update
transient impacts details: full-eNB-reset
It is possible to support several instances of ‘TrafficDescriptor’ per ‘Vlan’ instance (untagged or

VLAN tagged Ethernet traffic). This allows for configuring several IPv4 @s or IPv6 @s per VLAN with
possibly one subnet per IP address.

eNB
eNBtransportConf
RanBackhaul
Vlan[1-50]
plmnId (link to a PlmnIdentity instance)
vLanId = [2-4080; 4096]

TrafficDescriptor[0-10] vlanName
trafficTypeList = [Oam, S1u, S1c, X2u, X2c, 1588, M1]
ipFormat
ipv6Address / ipv6RoutingPrefixLength
ipv4Address / ipv4SubNetMask
Figure 61: VLAN - Model object for configuration

6.1.5 VLAN – eUTRAN sharing
eUTRAN sharing permits to share eUTRAN resources between several operators.
The L2 backhaul access is shared between the operators but the telecom traffics of the operators
are logically separated logically with VLANs. This allows each operator to manage its own policy for
QoS (see limitations in Ethernet & IP QoS sections) and SLA (see Traffic Management chapter).
Operator’s PLMN configuration is done through:

• Object: Enb/PlmnIdentity,
Parameter: isPrimary , Value: true/false, Class: A, Service impact: Critical, Update transient
impacts details: full-eNB-reset
Parameter: plmnMobileCountryCode, decimal of 3 characters, Class: A, Service impact: Critical,
Update transient impacts details: full-eNB-reset
Parameter: plmnMobileNetworkCode, decimal of 2-3 characters, Class: A, Service impact:
When eUTRAN sharing is activated, there are several instances of PlmnIdentity object.
Amongst the operators, a master operator manages not only its telecom traffic but also the OAM
and 1588 traffics as wells as the X2-C traffics of all the non master operator(s).
A non master operator only manage its S1-U, S1-C and X2-U traffics.
Rule: <eNodeB> <eUTRAN sharing> <Design>
PlmnIdentity instance which parameter ‘isPrimary’ = true defines the PLMN of the master operator.
Each operator has 1 telecom VLAN.

Within its telecom VLAN, the master operator manages its telecom traffic as well as non master
operator X2-C traffic.
In add, the master operator has another VLAN for OAM (and 1588 if used).
Within its telecom VLAN, a non master operator manages its S1-U, S1-C and X2-U traffics.
Restriction: <eNodeB> <eUTRAN sharing> <Design>
The X2-C traffic cannot be split between operators and is carried in the telecom VLAN of the
master operator.
Only the master operator’s telecom address is used for the X2-C traffic type.
The VLAN configurations that are supported by the master operator are a subset of the VLAN
configurations supported by a single operator.
ALU eNodeB supports:

• the Multiple Operators Core Network (MOCN) model where all operators share the RAN
resources (eNodeBs, backhaul) while each operator manages its own core network (MMEs,

SGWs)
• the Gateway Core Network (GWCN) model where the core network is shared by several
operators. MMEs can be shared by several operators (not necessary all operators) and the SGW
can be shared by several operators (not necessary all operators).
6.1.5.1 MOCN architecture
CN (operator A) CN (operator B)
MMEs SGWs MMEs SGWs
Backhaul
eNBs
eUTRAN (shared)
Figure 62: eUTRAN sharing architecture for MOCN
Rule: <eNodeB> <eUTRAN sharing> <MOCN> <Design>
MOCN is supported with up to 4 operators.
Rule: <eNodeB> <eUTRAN sharing> <MOCN> <Design>
In this release, it is supported 1 master operator and 3 non master operator.

6.1.5.1.1 Supported configurations for the master operator
2 VLANs are dedicated to the master operator for separating traffic flows as follows:
• 1 VLAN for OAM (and 1588 if used) traffic
• 1 VLAN for the master operator telecom traffic (S1, X2) and the non master operators X2-C
traffic

VLAN configurations as well as IP version(s) and number of IP @s supported per VLAN are given in
the table below.
Traffic type
VLAN 1
VLAN 2 S1-U S1-C X2-U X2-C
VLAN 3 1588 OAM M3 M1 IGMPv3 MLDv2
all
master operator only
operator
12 IPv4@2 IPv4@1 IPv4@3
13 IPv4@1 IPv4@2
14 IPv4@1 IPv6@2
15 IPv6@1 IPv6@2
Table 17: MOCN - Supported configurations for the master operator
6.1.5.1.2 Supported configurations for a non master operator
1 VLAN is dedicated to a non master operator for its S1 and X2-U traffic flows.
the table below.
Traffic type
VLAN n+2
VLAN n+3
S1-U S1-C X2-U
VLAN n+4 1588 OAM X2-C M3 M1 IGMPv3 MLDv2
(*)
n = [1-3] non master operator
12 IPv4@n+3
13 IPv4@n+2
14 IPv6@n+2
15 IPv6@n+2
Table 18: MOCN - Supported configurations for a non master operator

(*) Up to 3 non master operators. Index ‘n’ in the table designs the nth non master operator. 1st non
master has VLAN 3, 2nd has VLAN 4 and 3rd has VLAN 5.

6.1.5.2 GWCN architecture
CN (operator A) CN (operator B)
MMEs SGWs
Backhaul
eNBs
eUTRAN (shared)
Figure 63: eUTRAN sharing architecture for GWCN - example
Rule: <eNodeB> <eUTRAN sharing> <GWCN> <Design>
GWCN is supported with up to 3 operators.
Rule: <eNodeB> <eUTRAN sharing> <GWCN> <Design>
In this release, it is supported 1 master operator and 2 non master operators.

6.1.5.2.1 Supported configurations for the master operator
the table below.

Traffic type
VLAN 1
VLAN 2 S1-U S1-C X2-U X2-C
VLAN 3 1588 OAM M3 M1 IGMPv3 MLDv2
all
master operator only
operator
31 IPv4@2 IPv4@1 IPv4@3
32 IPv6@2 IPv6@1 IPv6@3
Table 19: GWCN - Supported configurations for the master operator
6.1.5.2.2 Supported configurations for non master operator#1
the table below.

Traffic type
VLAN 3
VLAN 4 S1-U S1-C X2-U
VLAN 5 1588 OAM X2-C M3 M1 IGMPv3 MLDv2
non master operator #1
31 IPv4@4 IPv4@4
32 IPv6@4 IPv6@4
33 IPv4@4
34 IPv6@4
35 IPv4@4
36 IPv6@4
37 IPv4@5 IPv4@6
38 IPv6@5 IPv6@6
39 IPv4@5 IPv4@6
40 IPv6@5 IPv6@6
Table 20: GWCN - Supported configurations for non master operator#1
6.1.5.2.3 Supported configurations for non master operator#2
the table below.
Traffic type
VLAN 4 S1-U S1-C X2-U

1588 OAM X2-C M3 M1 IGMPv3 MLDv2
non master operator #2
35 IPv4@5 IPv4@5
36 IPv6@5 IPv6@5
Table 21: GWCN - Supported configurations for non master operator#2
6.1.6 Ethernet QoS

pbit marking is not mandatory if VLAN tagging is used. But VLAN tagging is needed for pbit marking.

Ethernet QoS is enabled at eNodeB level.

In case of eUTRAN sharing, ethernet QoS is enabled for all operators or disabled for all operators.
Rule: <eNodeB> <Ethernet_QoS> <Design>
eNodeB maps the value of the Pbit from the value of the DSCP of the IP packets according to a
DSCP to Pbit mapping table common for both S1 and X2 interfaces.
In case of eUTRAN sharing, all operators use the same DSCP to Pbit mapping.
Ethernet configuration is done through:

• Object: Enb/EnbTransportConf/GlobalTransportConf,
Parameter: pBitSettingEnable, Value: true/false, Class: C, Service Impact: None, Update
transient impacts details: Immediate-propagation
Parameter: pBitForArp, Value: [0-7], Class: C, Service Impact: None, Update transient impacts
details: Immediate-propagation
• Object: Enb/EnbTransportConf/GlobalTransportConf/DscpToPbitMapping[0-21],
Parameter: dscp, Value: [BE, CS1, AF11, AF12, AF13, CS2, AF21, AF22, AF23, CS3, AF31, AF32,
AF33, CS4, AF41, AF42, AF43, CS5, VOICE-ADMIT, EF, CS6, CS7, NotUsed], Class: C, Service
Impact: None, Update transient impacts details: Immediate-propagation
Parameter: pBit, Value: [0-7], Class: C, Service Impact: None, Update transient impacts details:
Immediate-propagation
Engineering: <eNodeB> <Ethernet_QoS>
The DSCP setting for user plane traffic is configurable with separate mapping tables maintained for
S1 and X2 interfaces. Thus data to be forwarded over the X2 interface may be offered a higher IP
QoS than the same service type data on the S1. This enhances the handover performance by
minimising the latency of forwarded data, and handover control messaging.
If VLAN tagging is used but Ethernet QoS is not needed there must be configured:
Enb/EnbTransportConf/GlobalTransportConf: pBitSettingEnable = false
In this case eNodeB sets pBit = 0 (lowest ethernet priority).

If VLAN tagging is used and Ethernet QoS is needed the recommended VLAN priority mapping per
type of traffic is:
Enb/EnbTransportConf/GlobalTransportConf: pBitSettingEnable = true
Enb/EnbTransportConf/GlobalTransportConf: pBitForArp = 6
Enb/EnbTransportConf/GlobalTransportConf/DscpToPbitMapping[0-21]: dscp & pBit
dscp pBit dscp pBit

CS7 7 AF31 3
CS6 6 CS3 3
EF 5 AF23 2
VOICE-ADMIT 5 AF22 2
CS5 5 AF21 2
AF43 4 CS2 2
AF42 4 AF13 0
AF41 4 AF12 0
CS4 4 AF11 0
AF33 3 CS1 0
AF32 3 BE 1
Rule: <eNodeB> <Ethernet_QoS> <Standard>

p bit 0 is assigned a higher priority than p bit 1 as per following considerations:
1. According to RFC4594, CS1 corresponds to a lower traffic priority than best effort.
2. According to 802.1q; “The default priority used for transmission by end stations is 0.
Changing this default would result in confusion and likely in interoperability problems. At
the same time, the default traffic type is definitely Best Effort. 0 is thus used both for
default priority and for Best Effort, and Background is associated with a priority value of 1.
This means that the value 1 effectively communicates a lower priority than 0.”.

eNB
eNBtransportConf
GlobalTransportConf
pBitSettingEnable = [true/false]
pBitForArp
DscpToPbitMapping/[0-21]
dscp
pBit
Figure 64: Ethernet QoS - Model object for configuration
6.1.6.1 IEEE 802.1q interoperability between release 2005 and release 2011
As per IEEE 802.1q-2005:
The VLAN Tag Control Information (TCI) encodes;
- the vlan_identifier (VID),
- the priority (Priority Code Point (PCP)),
- the Canonical Format Indicator (CFI).
“NOTE 4—The CFI field of the TCI was required for historical reasons, in order to support media
where MAC addresses were carried as data in Non-canonical format. New implementations should
not attempt to support user communication that would require the addition of a tag with the
CFI bit set to a frame; most Bridges will discard frames with this bit set that are to be forwarded
untagged, as permitted by this subclause. Conformance in respect of receipt of frames with this bit
set remains unchanged from previous revisions of this standard.”

As per IEEE 802.1q-2011:
The VLAN TCI field encodes;
- the vlan_identifier,
- the drop_eligible,
- the priority (Priority Code Point (PCP)).
“The priority and drop_eligible parameters are conveyed in the 3-bit Priority Code Point (PCP) field
and the Drop Eligible Indicator (DEI) field as specified in 6.9.3.”
802.1q-2011 § 6.9.3 ‘Priority Code Point encoding’ states that DEI may be used separately or in
conjunction with PCP to indicate frames eligible to be dropped in the presence of congestion:
“6.9.3 Priority Code Point encoding
The priority and drop_eligible parameters are encoded in the Priority Code Point (PCP) field of the
VLAN tag using the Priority Code Point Encoding Table for the Port, and they are decoded from the
PCP using the Priority Code Point Decoding Table. […]
The drop_eligible parameter may also be encoded in and decoded from the Drop Eligible
Indicator (DEI) in the VLAN tag. Use of the DEI allows the VLAN tag to convey eight distinct
priorities, each with a drop eligible indicator. If this capability is provided, it shall be
independently manageable for each Port by means of a Use_DEI parameter. If the Use_DEI is True
for the Port, the drop_eligible parameter is encoded in the DEI of transmitted frames, and the
drop_eligible parameter shall be True for a received frame if the DEI is set in the VLAN tag [or the
Priority Code Point Decoding Table indicates drop_eligible True for the received PCP value]. If the
Use_DEI parameter is False, the DEI shall be transmitted as zero and ignored on receipt.
The default value of the Use_DEI parameter is False.”
Rule: <eNodeB> <Ethernet_QoS> <Design>
In this release, eNodeB supports IEEE 802.1q-2005.

Restriction: <eNodeB> <Ethernet_QoS> <Design>
eNodeB does not interoperate with a peer Ethernet node that supports IEEE 802.1q-2011 and which
encodes the DEI in the VLAN TCI field.
eNodeB would interpret the peer Ethernet node’s DEI field value as a CFI bit set and would discard
the received frame.
If eNodeB’s peer Ethernet node is running IEEE 802.1q-2011, then it must be configured such as the
‘Use_DEI’ parameter is set to ‘False’ so that the DEI be transmitted as zero and ignored on receipt
at eNodeB side.
6.1.7 Ethernet frame size

Standard Ethernet frames are sent when the MTU size is set to a value lower of equal than 1500
bytes. The maximum frame length is 1522 bytes.
Jumbo Ethernet frames are sent when the MTU size is set to a value higher than 1500 bytes.
Rule: <eNodeB> <Jumbo> <Design>
eNodeB supports standard and jumbo Ethernet frames for S1 and X2.
eNodeB supports jumbo Ethernet frames with a MTU size of 2000 bytes maximum.
The maximum ethernet frame length is thus 2022 bytes.
6.1.8 LAG
Restriction: <eNodeB> <LAG> <Design>
LAG is not supported on eNodeB (only one SFP port can be used)
6.2 IPV4
6.2.1 MTU
IPv4 packets are fragmented if they are greater than the MTU, and received packet fragments are
always reassembled. But IPv4 fragmentation by intermediary node has to be avoided for
performance reason (would add delay to the IP packets delivery).

Rule: <eNodeB> <MTU> <Standard>
As per 3GPP TS 36.300 “E-UTRAN Overall description”:

“Configuration of S1-U (X2-U) link MTU in the eNB/ S-GW according to the MTU of the network
domain the node belongs to shall be considered as a choice at network deployment.”
6.2.1.1 MTU for C-Plane, OAM & PTP
These flows terminate in the CCM on the PQ3 Linux processor.
The smallest MTU for all the links in a path from one node to another is called the path MTU, and
the process of determining the smallest MTU along the entire path from the source to the
destination is called path MTU discovery (PMTUD).
Path MTU discovery is supported by the Linux stack for IPv4 (and IPv6), and enabled by default. It
allows the TCP/SCTP protocols to automatically discover the minimum path MTU and adjust the size
of packet payloads to avoid IP fragmentation within intervening routers.
As explained in § “MTU for U-Plane”, the per VLAN configured mTU value represents the lowest MTU
value met on all S1-U and/or X2-U links (GTP flows). So ‘mTU’ value is by definition ≤ of MTU of the
first Ethernet link. Thus, for the OAM, PTP & Telecom C-Plane traffic the eNodeB sends IP packets
initially assuming that the path MTU is equal to the per VLAN parameter ‘mTU’ value. The Don’t
Fragment bit is set in the IPv4 header. If any of the packets are too large to be forwarded by some
router along the path, that router will discard them and return ICMP Packet Too Big messages. Upon
receipt of such message, the eNodeB reduces its assumed path MTU based on the MTU reported in
the Packet Too Big Message.
Rule: <eNodeB> <MTU> <Design>

The MTU for OAM, PTP & Telecom Control Plane (S1-MME & X2-C) is initialized to 1500 or to ‘mTU’
VLAN’s parameter value if this value is lower than 1500 and automatically adjusted through the
Path MTU discovery mechanism.
Engineering: <eNodeB> <MTU>
MTU of the first-hop link (eNodeB first-hop router or eNodeB peer eNodeB if on same link)
must be ≥ ‘mTU’ value (since path MTU discovery initiates at ‘mTU’).
If this is not the case a packet of more than ‘mTU’ bytes is silently discarded at eNodeB egress by
layer 2. Thus the path MTU discovery cannot be initiated.
Note: path MTU discovery is not applicable in a layer 2 network (as it is based on ICMP).
eNB keeps track of dynamically updated PMTU values on a per destination IP address basis.
For instance in the presence of several MMEs the eNB associates one PMTU value with each target
MME IP address.

Rule: <eNodeB> <MTU> <Standard>
For the Telecom Control Plane (S1-MME & X2-C), as per IETF RFC 4960, the eNodeB uses the
smallest Path MTU of all paths to a multi-homed peer as setting of the MTU size for all paths to this
peer.
6.2.1.2 MTU for U-Plane
These flows terminate in the CEM and go through the Winpath2 processor.
Path MTU discovery is not supported by CEM.
Restriction: <eNodeB> <MTU> <Design>
Path MTU discovery mechanism is not supported for the User Plane.
The MTU for User Plane (S1-U & X2-U) is configurable per VLAN.
The MTU is an attribute of a network interface and not of an IP address, so in situations where
multiple IP addresses (e.g., with differing traffic types) share a network interface (e.g., in the same
VLAN), the MTU value cannot be independently set for each IP address.
For U-Plane (S1-U & X2-U) the eNodeB MTU is configured through:
• Object: Enb/EnbTransportConf/RanBackhaul/Vlan, Parameter: mTU, Value: [1280-2000] byte,
Class: A, Service impact: Critical, Update transient impacts details: full-eNB-reset
eNB
eNBtransportConf
RanBackhaul
Vlan
mTU = [1280-2000]
Figure 65: MTU - Model object for configuration
MTU setting must be choosen based on the UE MTU and peers’ eNodeB path MTU, as well as LTE
transport overhead and operator backhaul transport overhead. In the case all of these dependencies
are known then the decision tree here after is given as proposal for setting the eNodeB path MTU.
UeMtu denotes the MTU at UE side (1).

Min(UP paths’ MTU) denotes the minimum MTU of all the eNodeB’s U-Plane paths (eNodeB SGW
and eNodeB peer eNodeB) (2) (3).
TransportOverHead denotes the overhead which is added by X2(S1) transport protocols

(GTP/UDP/IP) as well as operator transport backhaul.

TransportOverHead = LteTransportOverHead + BackhaulTransportOverHead, with;
LteTransportOverHead = Max(8; 13) + 8 + 20 = 41 bytes in IPv4 (4)
BackhaulTransportOverHead depends on the operator transport architecture
IF {(Min(UP paths’ MTU) – TransportOverHead) ≥ UeMtu} THEN

• at eNodeB: set path MTU = MAX(1280; Min(UP paths’ MTU))
• at UE: keep UeMtu
ELSE
/* For a trial network -- (there is possibility to act at UE side)-- */
/* We can accommodate UE MTU for no IP fragmentation neither at eNB nor at transport backhaul
*/
at eNodeB: set path MTU = MAX(1280; Min(UP paths’ MTU))
at UE: modify UeMtu = MIN(UP paths’ MTU) – TransportOverHead
/* For a commercial network -- (not much facility to act at UE side)-- */
/* 1) We can accommodate eNB MTU for IP fragmentation to be at eNB */
• at eNodeB: set path MTU = MAX(1280; Min(UP paths’ MTU) – TransportOverHead)
• at UE: keep UeMtu /* assumption maximum UE MTU may be 1500 */
/ *2) Or we can accommodate eNB MTU for IP fragmentation to be at transport backhaul */
• at eNodeB: set path MTU = 1500 + LteTransportOverHead = 1541
• at UE: keep UeMtu /* assumption maximum UE MTU may be 1500 */
ENDIF
(1) Usually UeMtu = 1500 bytes.
(2) Min(UP paths’ MTU) is ≥ 576 bytes in IPv4
(3) Must be take into account support of multi-homing by eNodeB’s peers (SGW, other vendor
eNodeB) in the eNodeB smallest path MTU determination.
(4) GTP overhead = 8 bytes for S1 and up to 13 bytes for X2.
GTP-U header over X2 is made of: 8 bytes (fixed header fields) + 1 (optional header field for ‘Next
Extension Header Type’) + 4 (for PDCP PDU number extension header) = 13 bytes.

In case eNodeB to peers’ path MTU are unknown then the guideline is to try with :
• Aggressive approach: mTU = (1500 + LteTransportOverHead (1) + BackhaulTransportOverHead)
bytes. This makes assumption that the UE MTU is 1500 bytes and the transport backhaul
supports jumbo Ethernet frames.
• Conservative approach: mTU = (1500 - LteTransportOverHead (1) -
BackhaulTransportOverHead) bytes. This makes assumption that the UE MTU is 1500 bytes and
the transport backhaul supports standard Ethernet frames of 1500 bytes.
(1) LteTransportOverHead = 41 bytes

6.2.2 OAM addressing
Two management protocols are used for communication between the eNodeB and OAM server:
• The Simple Network Management Protocol (SNMP), for the monitoring of the eNodeB (alarms,
state changes, performance monitoring, equipment management). This protocol is UDP-based.
• The Network Configuration Protocol (NetConf) on top of SSH, to manage the (radio and
transport) configuration of the eNodeB.
OAM server is responsible for establishing the communication with eNodeB. OAM server sends the
first SNMP message to the eNodeB. The eNodeB answers using the source IP address of the received
SNMP message.
The eNB OAM IP address information is either:

• provisioned by the operator (when ipConfigAutomatic = False)
• obtained from automatic Plug-n-Play (PNP) procedures (when ipConfigAutomatic = True)
The mode of operation is configured through:
Object: Enb/EnbTransportConf/RanBackhaul, Parameter: ipConfigAutomatic, Value: [true, false],
Class: C, Service impact: None, Update transient impacts details: New-set-ups
The following alternatives are supported:
• false: the eNB uses the OAM IP address provisioned in the ipv4Address (ipv6Address) parameter
of the object instance Vlan/1 trafficDescriptor/0
• true: the eNB uses DHCP to obtain the OAM IP address.
Note: This is eNB default value set at factory for ‘dhcpMode’ I&C parameter. At initial eNB
startup eNB runs DHCP by default (unless the operator has changed ‘dhcpMode’ at
commissioning).
‘Read Only’ parameters display the eNB OAM IPv4 address information currently in use by the eNB:
• Object: Enb/EnbTransportConf/OamTransportConf/currentEnbOamAddressData,
Parameter: currentEnbOamIpv4Address, Class: N/A, Service Impact: N/A, Update transient
impacts details: N/A
Parameter: currentEnbOamIpv4SubnetMask, Class: N/A, Service Impact: N/A, Update transient
impacts details: N/A
6.2.2.1 eNB OAM addressing - without PnP
This section only addresses static eNB IP setting configuration. Refer to the § that describes eNB Self
Commissioning for description of the eNB Plug and Play (PnP) functionality.
eNB OAM IP address may be manually configured when RanBackhaul:: ipConfigAutomatic = false.
eNB OAM static IP addressing configuration is done through I&C parameters; OAM IP Address, OAM
IP Netmask / Prefix Routing Length, OAM IP Gateway. They are replaced by provisioned values once
MIM has been downloaded.
• Object: Enb/EnbTransportConf/RanBackhaul/Vlan[1-50]/TrafficDescriptor[0-10],
Parameter: ipv4Address, Class: C, Service Impact: None, Update transient impacts details:
Parameter: ipv4SubNetMask, Class: C, Service Impact: None, Update transient impacts details:

An internal OMC parameter (not sent to eNodeB) provide the eNodeB IP address for SNMP and SSH
connection. It is used by the OMC for monitoring of the alignment with the eNodeB.
• Object: OamInterface, Parameter: provisionedEnbIdentifier, Class: C, Service Impact: None,

Update transient impacts details: N.A.
Rule: <eNodeB> <IPv4> <Design>
The configured provisionedEnbIdentifier must be the same as the one configured by the
ipv4Address for the TrafficDescriptor which contains ‘OAM’ traffic.
eNodeB performs a full fall back to previous (working) configuration version when no SNMP traffic
from OMC is received after eNodeB reset from configuration change and a fallback timer is expired.
Considered configuration change is OAM Vlan transport parameters modification (e.g. new IPv4
address or new IPv4 subnet or migration to IPv6).
eNodeB fallback timer configuration is done at I&C through:

• Object: Enb/EnbTransportConf, Parameter: timerToWaitForFallbackToPreviousIPversion, Value:
[30-120] (with step = 1), Unit: minute, Default: 30, Class: C, Service impact: None, Update transient
impacts details: New-set-ups
6.2.2.2 eNodeB events time-stamping
eNodeB generated events (alarm, state change) are time-stamped with a clock delivered by the
Network Time Protocol (NTP). NTP is UDP-based and uses port 123.
Two NTP servers are used. The second server is used in case the first one is not accessible.
NTP server IP address configuration is done at I&C through:

• Object: Enb,
Parameter: firstNtpServerIpAddress, Value: IPv4 address (x:x:x:x), Class: C, Service Impact:
None, Update transient impacts details: Immediate-propagation
Parameter: secondNtpServerIpAddress, Value: IPv4 address (x:x:x:x), Class: C, Service Impact:
6.2.3 Telecom addressing

Telecom IP addressing configuration is done through:
Parameter: ipv4SubNetMask, Class: C, Service Impact: None, Update transient impacts details:

eNB
eNBtransportConf
RanBackhaul
Vlan[1-50]
plmnId
vLanId = [2-4080; 4096]

TrafficDescriptor[0-10]
trafficTypeList = [Oam, S1u, S1c, X2u, X2c, 1588]
ipFormat = IPv4
ipv4Address
ipv4SubNetMask
ipv4AddressFirstHopRouter
Figure 66: IPv4 addressing - Model object for configuration
Engineering: <eNodeB> <IPv4>
OAM and Telecom IPv4 addresses should be configured in two different subnets.
Depending on the VLAN configuration there may be:

• 1 IP address only configured for the whole Telecom traffic (S1-MME, S1-U, X2-C, X2-U), or
• 2 IP addresses configured with;
• 1 for the S1 traffic + 1 for the X2 traffic, or
• 1 for the S1 & X2 Control Plane traffic + 1 for the S1 & X2 User Plane traffic.
Only the master operator’s telecom address is used for the X2-C traffic type.
The non master operators’ telecom address is only used for their S1-U, S1-C & X2-U traffic types.

All operators are configured with the same IP format for the telecom traffic, either IPv4 or IPv6.
See VLAN § for more information on supported VLANs configuration as well as IP version(s) and
number of IP @s supported per VLAN.
Restriction: <eNodeB> <IPv4> <Design>
eNodeB does not support SCTP multi-homing.
6.2.4 Subnetting
Within a VLAN, several IPv4 addresses can be assigned within the same subnet.
Within a VLAN, several IPv4 subnets can be assigned but they must not overlap.
There can be one IPv4 subnet per IPv4 address.
A subnet must be used by only one VLAN, i.e. one subnet must not overlap VLANs.
That is, IPv4 addresses of different VLANs must be in different subnets.
An eNodeB supports at least one gateway IPv4 address per subnet.

It is possible to define one gateway IPv4 address per IP address of a subnet
E.g. if there are 3 IP addresses in a subnet, it is possible to define 3 gateways IP addresses in the
subnet.
The first hop router associated to a traffic flow may be unset if the eNB is connected to its peer
through a L2 switch.
In case the eNB is on the same subnet than its peer a connection through a L3 router is not
mandatory.

The first hop router associated to a traffic flow must be set if the eNB is connected to its peer
through a L3 router.
In case the eNB is on a different subnet than its peer a connection through a L3 router is mandatory.
6.2.5 eNB private IPv4 addressing
Private IPv4 addressing is used for internal eNodeB addressing. The IETF RFC 1918 defines the
private addressing. The IANA has reserved the following 3 blocks of the IP address space for private
internets:
• 10.0.0.0 - 10.255.255.255 (10/8 prefix)
• 172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
• 192.168.0.0 - 192.168.255.255 (192.168/16 prefix)
eNodeB uses the private IPv4 192.168.0.0/16 prefix for internal addressing.
This is not configurable.
Restriction: <eNodeB> <IPv4> <Engineering>
eNB source IP @ (OAM, telecom) must not be in eNB internal subnet (192.168/16).
eNB destination IP@ (MME, PTP server) may be set within eNB internal subnet (192.168/16).
6.2.6 Routing
Restriction: <eNodeB> <IPv4>
No routing protocol is supported on eNodeB
6.2.6.1 Routing principle at eNodeB
Each configured subnet has its own routing table, and thus, its own default route.
An outgoing traffic (OAM, 1588 or Telecom) is directed to the appropriate routing table based on
its source address.
All traffic not matching one of the source address routing rules, gets directed to the main routing
table.
The OAM traffic is bound to a main routing table while others traffic are bound to auxiliary routing
tables.

Example: OAM & 1588 in same IPv4 subnet and VLAN, Telecom in a different IPv6 subnet and VLAN.
In this example :
• Telecom traffic which source address = enbTelIpv6 get directed to the 2nd auxiliary routing
table which has a default route to the 2nd router (rt2)
• 1588 traffic traffic which source address = enb1588Ipv4 get directed to the 1st auxiliary routing
table which has a default route to the 1st router (rt1)
• OAM traffic traffic which source address = enbOamIpv4 get directed to the main routing table
which has a default route to the 1st router (rt1)
6.2.6.2 OAM Routing
eNodeB OAM first hop router configuration is either PnP or done at I&C through:
ipv4AddressFirstHopRouter, Class: A, Service impact: Critical, Update transient impacts details: full-
eNB-reset
If VLAN tagging is enabled at L2 but L3 routing is not required for the OAM traffic, then parameter
OAM ipv4AddressFirstHopRouter should be set to 0.0.0.0
6.2.6.3 Telecom Routing
This is achieved thanks to the provisioning of a Telecom first hop router.
Telecom routing configuration is done through:

eNB-reset

If VLAN tagging is enabled at L2 but L3 routing is not required for the Telecom traffic, then
parameter eNobeBfirstHopRouterTelecomIpAddr should be set to 0.0.0.0

6.2.6.4 Routing table initialisation
6.2.6.4.1 eNodeB initial start-up sequence – without PnP
Configured I&C parameters :

− OAM ipv4Address
− OAM ipv4SubNetMask
− OAM ipv4AddressFirstHopRouter
− OAM vLanId
eNodeB performs ARP to discover MAC address of OAM first hop router
eNodeB creates OAM routing table
OAM server polls newly installed eNodeB which learns the OAM server IP
address from the received SNMP request. eNodeB answer is routed through
the specific route via the OAM ipv4AddressFirstHopRouter
eNodeB OAM server connection established
IF OAMSynchControl:enableAutomaticConfiguration=true THEN
OAM server starts downloading to eNodeB the MIB parameters.
ELSE the download must be launched by an operator action.
IP transport parameters downloaded from MIM for Telecom/OAM/1588:

− ipv4Address
− ipv4SubNetMask
− ipv4AddressFirstHopRouter
− vLanId
eNodeB creates auxilary routing tables for Telecom & 1588
eNodeB establishes SCTP connections to MME(s) and peer eNodeBs using

default routing via Telecom ipv4AddressFirstHopRouter

6.2.6.4.2 eNodeB initial start-up sequence – with PnP

− OAM vLanId
− No OAM IPv4 @
eNodeB initiates all possibles methods for auto-configuring its IP address:

Auto-configuration specific
DHCPv4, DHCPv6 and IPv6 SLAAC

• If network is IPv4 only DHCPv4 method is successful
• If network is IPv4 and IPv6 DHCPv4 & (DHCPv6 or IPv6 SLAAC)
methods are successful 1st received OAM packet defines the eNodeB IP
version (IPv4 in this case)
eNodeB obtains OAM IP parameters setting from PnP procedure;

• OAM IP Address / OAM IP Netmask / Prefix Routing Length
• OAM IP Gateway
• EMS IP @
eNodeB performs ARP to discover MAC address of OAM first hop router
OAM server polls newly installed eNodeB.

eNodeB answer is routed through the specific route via the OAM

− ipv4Address
− ipv4SubNetMask
− ipv4AddressFirstHopRouter
− vLanId
eNodeB creates Telecom & 1588 routing tables

default routing via Telecom ipv4AddressFirstHopRouter
In DHCPv4, eNodeB broadcasts ‘DHCP Discover’ message on and authenticates with DHCP server
(IETF RFC 3118)
6.2.7 IP QoS

IP QoS is enabled at eNodeB level.

In case of eUTRAN sharing, IP QoS is enabled for all operators or disabled for all operators.
For the Telecom Control Plane, OAM, PTP and other control flows (GTP echo, ICMP, Call Trace),
eNodeB maps the value of the DSCP according to a Control Flow to DSCP mapping table.
In case of eUTRAN sharing, the DSCP mapping for S1-C, X2-C, OAM, PTP and others control flows is
the same for all operators.
For the Telecom User Plane, eNodeB maps the value of the DSCP from the value of the QCI of the
Radio Access Bearer according to a QCI to DSCP mapping table.
There is 1 QCI to DSCP mapping table for S1 User Plane traffic and 1 QCI to DSCP mapping table for
X2 User Plane traffic.
In case of eUTRAN sharing, the DSCP mapping for S1-U and X2-U is configurable per operator.
IP QoS marking configuration is done through:

• Object: Enb/EnbTransportConf/GlobalTransportConf, Parameter: dscpSettingEnable, Value:
true/false, Class: C, Service Impact: None, Update transient impacts details: Immediate-
propagation
DSCP setting for Telecom Control Plane, OAM, PTP and others:
• Object: Enb/EnbTransportConf/GlobalTransportConf/ControlFlowToDscpMapping[0-7],
Parameter: controlFlow, Value: [SctpS1, SctpX2, GTPuEcho, OAM, PtpEvtMsg, PtpGenMsg, ICMP,
CallTrace, IKE, DDT, M3, AGPS], Class: C, Service Impact: None, Update transient impacts
AF33, CS4, AF41, AF42, AF43, CS5, VOICE-ADMIT, EF, CS6, CS7, NotUsed], Class: A, Service
impact: Critical, Update transient impacts details: full-eNB-reset
The operator PLMN identifier (MCC and MNC) configuration is done through:
• Object: Enb/EnbTransportConf/PerOperatorTransportConf[0-3], Parameter: plmnId, Value: link
to a ‘PlmnIdentity’ instance that contains the MCC and MNC of an operator, Class: A, Service

DSCP setting for S1 User Plane:

• Object: Enb/EnbTransportConf/PerOperatorTransportConf[0-3]/QciToDscpMappingS1[0-7],
Parameter: qci, Value: [Qci1-Qci255], Class: C, Service impact: None, Update transient impacts
details: New-set-ups
impact: None, Update transient impacts details: New-set-ups
DSCP setting for X2 User Plane:

• Object: Enb/EnbTransportConf/PerOperatorTransportConf/QciToDscpMappingX2[0-31],
Parameter: qci, Value: [Qci1-Qci255], Class: C, Service impact: None, Update transient impacts
details: New-set-ups
IP QoS marking is not mandatory.
If Enb/EnbTransportConf/GlobalTransportConf:dscpSettingEnable = false then eNodeB marks all

traffic with DSCP = BE (best effort)

If DSCP marking is needed the recommended DSCP mapping per traffic type is :
Enb/EnbTransportConf/GlobalTransportConf:dscpSettingEnable = true
Enb/EnbTransportConf/GlobalTransportConf/ControlFlowToDscpMapping [0-7]: controlFlow & dscp
controlFlow dscp controlFlow dscp

ICMP CS6 M3 AF41
PtpEvtMsg CS7 AGPS AF41
PtpGenMsg AF41 CallTrace AF12
SctpS1 AF41 Dynamic Debug Trace CS1
SctpX2 AF41 OAM AF11
SctpM3 AF41 Other BE
GTPuEcho (S1) AF41 IKE CS6
Enb/EnbTransportConf/PerOperatorTransportConf[0-3]/QciToDscpMappingS1[0-31]: qci & dscp

Enb/EnbTransportConf/PerOperatorTransportConf[0-3]/QciToDscpMappingX2[0-31]: qci & dscp
qci (1) dscp (S1) dscp (X2)

1 GBR, Low delay, High loss EF EF
2 GBR, Low delay, Medium loss EF EF
3 GBR, Low delay, Medium loss EF EF
4 GBR, Medium delay, Low loss AF42 AF42
5 Non-GBR, Low delay, Low loss CS6 CS6
6 Non-GBR, Low delay, Low loss AF42 AF42
7 Non-GBR, Med delay, Low loss AF22 AF22
8 Non-GBR, Med delay, Low loss AF21 AF21
9 Non-GBR, High delay BE BE
10-255 Non-GBR, High delay BE BE
(1) values 1-9 are 3GPP standard QCIs and values 10-255 are ALU proprietary QCI
The same DSCP mapping is used for both IPV4 and IPV6.

The QoS mappings are OAM configurable with separate mapping tables maintained for S1 and X2
interfaces. Thus data to be forwarded over the X2 interface may be offered a higher QoS than the
same service type data on the S1. This enhances the handover performance by minimising the
latency of forwarded data, and handover control messaging.
eNB
eNBtransportConf
GlobalTransportConf
dscpSettingEnable = [true/false]
ControlFlowToDscpMapping/[0-7]
controlFlow = [SctpS1, SctpX2, GTPuEcho,

OAM, PtpEvtMsg, PtpGenMsg, ICMP, CallTrace,
IKE, DDT, M3, AGPS]
dscp
PerOperatorTransportConf/[0-3]
QciToDscpMappingX2/[0-31]
qci
dscp
QciToDscpMappingS1/[0-31]
qci
dscp
Figure 67: IP QoS - Model object for configuration
6.3 DHCPV4
Dynamic Host Configuration Protocol DHCPv4 is defined in RFC2131 and RFC2132.
There are 3 methods of DHCP allocation:
• Manual allocation
The DHCP server performs the allocation of IP addresses based on a table with a list of client-
identifying information.
• Automatic allocation
The DHCP server assigns an available IP address to the requesting client from a defined IP range.
• Dynamic allocation - not supported by eNB

This provides dynamic re-use of IP addresses. The DHCP has an assigned range of IP addresses and
each client on the LAN requests an IP address from the DHCP server when that client’s interface
card starts up. The IP address becomes available again in the server’s pool of addresses once its
previous lease times out.
DHCP uses UDP to deliver messages and broadcasts.
If a DHCP server is not present on a network, then a DHCP relay agent should forward messages
between a client and a server.
DHCPv4 DHCPv4
client server
DHCPDISCOVER (broadcast)
DHCPOFFER (unicast)
DHCPREQUEST (broadcast)
DHCPACK (unicast)
Figure 68: DHCP message flow

0-7 8-15 16-23 24-31
OP HTYPE HLEN HOPS
TRANSACTION IDENTIFIER
SECONDS ELAPSED FLAGS
CLIENT IP ADDRESS
YOUR IP ADDRESS
SERVER IP ADDRESS
ROUTER IP ADDRESS
CLIENT HARDWARE ADDRESS (16 BYTES)
SERVER HOST NAME (64 BYTES)
BOOT FILE NAME (128 BYTES)
OPTIONS (VARIABLE)
Figure 69: DHCP message format
OP specifies whether the message is a Request or a Response

HTYPE network hardware type
HLEN length of a hardware address
HOPS how many servers forwarded the request
TRANSACTION IDENTIFIER used to match incoming responses with the original request
SECONDS ELAPSED how many seconds have elapsed since the computer booted
FLAGS controls the contents of the OPTIONS field
CLIENT IP ADDRESS populated if the client (HOST) knows its IP address
YOUR IP ADDRESS used by the server to provide the client (HOST) with an IP address
SERVER IP ADDRESS IP address of the next server to be used in “bootstrap” process
ROUTER IP ADDRESS IP address of a relay agent router
CLIENT HARDWARE ADDRESS populated if the client knows its hardware address
SERVER HOST NAME host name of the server
BOOT FILE NAME name of a file on the server containing a suitable boot image
controlled by the FLAGS field
OPTIONS
contains DHCP Vendor Options as defined in RFC2132
6.3.1 eNB configuration by DHCPv4 server

Rule: <eNodeB> <DHCPv4> <Design>
eNodeB supports following DHCPv4 messages:

• DHCPDISCOVER
• DHCPOFFER
• DHCPREQUEST
• DHCPACK
• DHCPNAK
Restriction: <eNodeB> <DHCPv4> <Design>
The following DHCPv4 messages are not supported:

• DHCPDECLINE
• DHCPRELEASE
• DHCPINFORM
Upon power-up eNB sends a broadcast ‘DHCPDISCOVER’ (broadcast) message on the VLAN that
supports OAM (default VID=400) on condition that its ‘ipConfigAutomatic’ parameter is set to ‘true’.
The DHCPv4 server responds with the ‘DHCPOFFER’ (unicast) message containing IP address, IP
subnet, GW IP address and the EMS IP@. eNB host then sends a ‘DHCPREQUEST’ (broadcast) servers,
and receives a ‘DHCPACK’ (unicast) to complete the procedure.
eNB is allocated an Ipv4 address with an infinite ‘lease’ time by the DHCPv4 server.
eNB supports the Client-Identifier option 61 which the server uses to index the IP-allocation table.
The Client-Identifier is based on eNB Cabinet Serialization number.
eNodeB supports following options:
Option code = 1 Subnet Mask
Option code = 3 Gateway router

*
Option code = 6 Domain Name Server
Option code = 43 Vendor Specific Information

**
Option Code = 60 Vendor Class Identifier
***
Option Code = 61 Client Identifier
* The domain name server option specifies either one (no redundancy) or two (primary then
secondary) name servers.
** Set to ‘ENODEBALUTYPE1’
*** Based on eNB serialization number

The eNB OAM parameters delivered by DHCPOFFER are as follows:
Your IP Address (YIADDR) OAM IPv4 address
Option code = 1 OAM subnet mask
Option code = 3 OAM Gateway IPv4 address
Option code = 6 Domain Name Server
Option code = 43 & sub-option 5 EMS IP@
6.3.1.1 Vendor Specific Information option format
The option format is defined in rfc2132. The sub-options are defined by the vendors.
0-7 8-15 16-23 24-31
Option code = 43 Length=variable

Encapsulated Vendor-Specific
Sub-Options (variable length)
eNodeB supports following sub-options:
Sub-option = 1 EMS IPv4 addresses & port numbers
Sub-option = 2 Security GW IPv4 address
Sub-option = 3 EMS FQDN
Sub-option = 4 Security GW FQDN
Sub-option = 5 EMS IPv6 addresses & port numbers
Sub-option = 6 1588v2 Grandmaster IPv4 address(es)
6.3.1.1.1 Sub-option 1: EMS IPv4 addresses & port numbers

When included, this sub-option contains a list of a maximum 10 times 6 bytes (4 bytes for EMS IPv4
address, 2 bytes for port number).
0-7 8-15 16-23 24-31
Sub-Option code = 1 Length = [1..10]*6 EMS 1 IPv4 address (begin)
EMS 1 IPv4 address (end) EMS 1 port number
EMS 2 IPv4 address
EMS 2 port number etc…
6.3.1.1.2 Sub-option 2: Security GW IPv4 address
0-7 8-15 16-23 24-31
Sub-Option code = 2 Length = 4 Security Gateway Ipv4 address (begin)
Security Gateway Ipv4 address (end)
6.3.1.1.3 Sub-option 3: EMS FQDN
0-7 8-15 16-23 24-31
Sub-Option code = 3 Length = 1..64
EMS Fully Qualified Domain Name
6.3.1.1.4 Sub-option 4: Security GW FQDN
0-7 8-15 16-23 24-31
Sub-Option code = 4 Length = 1..64
SEG Fully Qualified Domain Name
6.3.1.1.5 Sub-option 5: EMS IPv6 addresses and port numbers

When included, this sub-option contains a list of a maximum 10 times 18 bytes (16 bytes for EMS
IPv6 address, 2 bytes for port number).
0-7 8-15 16-23 24-31
Sub-Option code = 5 Length = [1..10]*18 EMS 1 IPv6 address (begin)
EMS 1 IPv6 address (end) EMS 1 port number
EMS 2 IPv6 address (begin)
EMS 2 IPv6 address (end)
EMS 2 port number etc…
6.3.1.1.6 Sub-option 6: 1588v2 Grandmaster IPv4 address(es)
When there are two addresses the primary GM is first, the backup is the concatenated address.
0-7 8-15 16-23 24-31
Sub-Option code = 6 Length = 4 or 8 1588v2 primary GM Ipv4 address (begin)
1588v2 primary GM Ipv4 address (end) 1588v2 secondary GM Ipv4 address (begin)
1588v2 secondary GM Ipv4 address (end)
6.4 IPV6
IPv6 as specified in IETF RFC 2460 is supported for the Telecom traffic (S1 & X2) and for OAM.
The eNodeB supports up to 3 IPv6 interfaces (1 interface per VLAN).

See VLAN § for more information on supported VLANs configuration.
IP version selection is done through:

• Object: Enb/EnbTransportConf/RanBackhaul/Vlan[1-50], Parameter: ipFormat, Value:
[IPv4,IPv6], Class: A, Service impact: Critical, Update transient impacts details: full-eNB-reset

In the IPv6 header, eNodeB sets the value of the Flow Label field (20 bits) to the default value of
zero, meaning it is not used. Flow label is used to support additional QoS capabilities.
In the IPv6 header, eNodeB sets the value of the Hop Limit field (8 bits) to 255 for all the IPv6
egress IP packets.
6.4.1 MTU
In IPv6, MTU setting is more sensible than in IPv4 since IPv6 routers can’t perform fragmentation.
Same applies as for IPv4. Refer to dedicated chapter in IPv4 section.
Same applies as for IPv4 with the difference that LteTransportOverHead = 8 + 40 + Max(8; 13) = 61
bytes in IPv6.
Refer to dedicated chapter in IPv4 section.
6.4.2 Addressing
An IPV6 address has 128 bits (16 bytes). The address is shown as eight 16-bit hexadecimal blocks
separated by colon.
The eNodeB recognizes the following addresses to identify itself as per IETF RFC 4291:
• Its required Link-Local Unicast address (LLA) for each interface (mandatory)
• Any additional Global Unicats addresse (GUA) and Anycast addresses that have been configured
for the node's interfaces (manually or automatically).
• The loopback address.
• The all-nodes multicast addresses (FF01:0:0:0:0:0:0:1 & FF02:0:0:0:0:0:0:1)
• The solicited-node multicast address for each of its unicast and anycast addresses.
• Multicast addresses of all other groups to which the node belongs.
6.4.2.1 eNodeB events time-stamping
Same applies as for IPv4. Refer to dedicated chapter in IPv4 section.
NTP server IP address configuration is done at I&C through:

• Object: Enb,
Parameter: firstNtpServerIpAddressv6, Value: IPv6 address (x:x:x:x:x:x:x:x), Class: C, Service
Parameter: secondNtpServerIpAddressv6, Value: IPv6 address (x:x:x:x:x:x:x:x), Class: C, Service

6.4.2.2 eNodeB Link-local address
As per IETF RFC 4903 the term "link" is generally used to refer to a topological area bounded by
routers that decrement the IPv6 Hop Limit when forwarding the packet.
An IPv6 node is required a Link-Local Address (LLA) for each IPv6 interface.
A LLA must be unique on the link where it is used. The uniqueness of the LLA on a link is ensured by
the use of VLANs which create (logically) separated links.
Then an IPv6 node can source IP packets (e.g. Router Solicitation, DHCPv6) with its LLA on one
interface (VLAN1) as well as on another interface (VLAN2).
Rule: <eNodeB> <IPv6> <Standard>
A LLA is not routable and can only be used on a VLAN.

As per IETF RFC 4291: “Routers must not forward any packets with Link-Local source or destination
addresses to other links”
The eNodeB uses auto-configured LLA.

eNodeB’s LLA is not made visible to the OAM
The eNodeB uses a LLA for communicating with an IPv6 router (e.g. for Neighbor Discovery
messages) or with a DHCPv6 relay or server.
The eNodeB does not use a LLA for any other purposes (OAM, S1 and X2 data flows).
Link Local Address format:

• The Prefix part of auto-configured LLAs is always set to FE80::/10.
• The value of the bottom 64 bits (Interface Identifier) of eNodeB auto-configured LLAs is based on
the MAC address of the corresponding VLAN interface. The format is the modified EIU-64 format
defined in IETF RFC 4291 Appendix A.
Prefix Interface ID
10 bits 54 bits 64 bits
1111 1110 10 00 0000 … 0000
EIU-64 based on the MAC @
FE80::/10
Figure 70: eNodeB Link Local Address (LLA) format
The interface ID value of the LLA must be unique at least on the VLAN where it is used.
It may be replicated (same value) over several interfaces when multiple VLANs are configured. As a
result the same LLA value may be found several times within a given IPv6 node on different IP
interfaces.

At eNB, there can be only one LLA (only one usable ethernet port on CP).
The same LLA is replicated over several interfaces when multiple VLANs are configured.
6.4.2.3 eNodeB Global Unicast address
A Global Unicast IPV6 address consists of 64 bits of global routing prefix and subnet ID and 64 bits of
interface ID. The subnet identifies a link within a site. The interface ID identifies an interface
within that sub network.
According to IETF RFC 4291 IPv6 addresses are assigned an IPv6 address prefix. The prefix length is
a decimal value specifying how many of the leftmost contiguous bits of the address comprise the
prefix.
The notion of subnet mask is not used in IPv6. Only prefix-length notation is supported.
IPv6 Prefix Interface ID

Global Routing Prefix Subnet ID Interface ID
n bits 64 – n bits 64 bits
Figure 71: Global Unicast Address (GUA) format as per IETF RFC 3587
The eNodeB is not aware of the Link Prefix sub-structure (Global Routing Prefix and Subnet ID) that
is used only by routers which on the other hand ignores the bottom 64 bits.
Per eNodeB site only 1 subnet is needed.
Global Unicats addresses used by the eNodeB have 64 bit-long prefixes and 64-bit long interface
IDs.
IPv6 Prefix Interface ID

64 bits 64 bits
Figure 72: eNodeB Global Unicast Address (GUA) format
A 64-bit prefix defines 264 128-bit addresses.

The interface ID value of the (GUA) must be unique for a given value of the IPv6 Prefix.
Global Unicast addresses are routable.
In a commercial LTE network there will always be a router between the eNodeB and peer nodes
(MME, SGW, eNodeB), therefore the eNodeB has to source its IPv6 packets towards these peers from
a Global Unicast Address.

Restriction: <eNodeB> <IPv6_Addressing#1> <Design>
The eNodeB supports native IPv6 address only (no embedded IPV4 address).
6.4.2.4 eNodeB IPv6 interface(s) static configuration
The OAM and first hop router IPv6 addresses may be provisioned by OAM.
The Telecom IPv6 address is always provisioned by OAM.
Alternatively, the eNodeB may get its IP address for OAM with DHCPv6.
The eNodeB uses any valid IPv6 GUA to communicate with the MME, SGW and other eNodeBs over
the S1-U, S1-MME, and X2 interfaces respectively. See chapters on X2 interface & S1 interface.
IPv6 address configuration is done through:

Parameter: ipv6RoutingPrefixLength, Class: C, Service Impact: None, Update transient impacts
The provisioned first hop router is used as the default route within eNodeB routing table.
First hop router configuration is done through:

eNB-reset
The IPv6 address of the first hop router can be either the IPv6 LLA of the first hop router or the GUA
of the first hop router.

In trials there may be cases where eNodeBs, MME and SGW are on same VLAN.
L3 routing is then not required for the Telecom traffic and parameter
eNobeBfirstHopRouterTelecomIpAddrIPv6 should be set to ‘::’
eNB
eNBtransportConf
RanBackhaul
Vlan[1-50]
plmnId
vLanId = [2-4080; 4096]
TrafficDescriptor[0-10] ipFormat = Ipv6
trafficTypeList = [Oam, S1u, S1c, X2u, X2c, 1588]
ipv6Address
ipv6RoutingPrefixLength = 64
Figure 73: IPv6 addressing - Model object for configuration
6.4.2.5 eNodeB IPv6 interface(s) automatic configuration
The OAM and first hop router IPv6 addresses may be configured automatically.
The Telecom IPv6 address cannot be configured automatically.
MIM data always supersedes automatic sources of configuration information.
There are two distinct sources for IPv6 interface(s) automatic configuration on a given VLAN:
• ICMPv6 Network Discovery messages (RS, RA and NS, NA),
• DHCPv6 messages (optional).
IPv6 has been designed so that a given configuration parameter cannot be received from both
sources (no duplication).
Two essential IPv6 parameters are found in RA but not in DHCPv6 messages:
• Router IP address
• Link Prefix
Others alternatives are supported;

In the absence of RA messages, ALU implementation of DHCPv6 supports a Vendor Specific

Information Option to pass the router IPv6 address to the eNodeB.
No specific DHCPv6 option is needed for the Prefix value.

The Prefix length is always 64 bits, and the OAM address returned by DHCPv6 is on-link.
The OAM interface Prefix can be set to 64 top bits of the OAM address assigned by DHCPv6.
Another alternative has been defined to cope with the absence of RAs that does not require a
Vendor Specific Information Option for passing the router IPv6 address to eNodeB.
It is based on configuring the same LLA value for all router interfaces, assuming there is a single
router on each VLAN. Redundancy is still supported but only with VRRP without load sharing (a
single interface address is perceived by eNodeB).
In this context eNodeB assumes that:

• the Prefix length is 64 (default value) and the Prefix value is made of the 64 top bits of the
assigned IPv6 OAM address,
• the router address is fixed and set by default to FE80::1:1
6.4.2.5.1 OAM interface automatic configuration
eNodeB does not support SLAAC.
The supported method for automatic configuration of the OAM IPv6 address is:
• DHCPv6 (on the same principle as for DHCPv4 for IPv4 @ allocation)
The OAM IPv6 address is pre-configured in the DHCPv6 server and associated in the server database
with the DUID (DHCP Unique ID) of the eNodeB. The eNodeB DUID includes the eNodeB Serial
Number.
The serialization number is a field of 25 alphanumeric characters. The eNodeB DUID is obtained by
removing all the “space” characters from the “serialization number” and adding a prefix to be
ready for dual technology deployment (for the DHCP server provisioning to be as stable as
possible). The prefix for LTE is the string “LTE”.

The initial OAM exchange is always initiated by OAM server. The OAM IPv6 address of each eNodeB
need therefore to be configured at two different locations: OAM and DHCPv6 servers.
The eNodeB is assigned an IPv6 address with an infinite lifetime (permanent assignment).
The eNodeB supports the Vendor Class Option. It is hard-coded to “ENODEBALUTYPE1”.

This makes possible to distinguish between ALU eNodeBs and other devices (e.g. ALU 3G NodeBs) in
the DHCPv6 server.
DHCPv6 is never used as soon as the MIM already holds valid interface data, MIM data are used
instead.
Any subsequent changes to the OAM IPv6 interface parameters (IPv6 Prefix and/or address) are
performed through OAM.
Supported cases for eNodeB OAM IPv6 interface automatic configuration:
Prefix
RA
with A- Next-Hop router On-link Prefix OAM IPv6 address
message
Flag set in configuration configuration configuration
presence
RA
Source address of RA Advertised Prefix with
Yes No DHCPv6 stateful
messages L-bit set.
DHCPv6 stateful with Top 64 bits of OAM
No n.a. Vendor Specific address returned by DHCPv6 stateful
Information Option. DHCPv6.
Top 64 bits of OAM
FE80::1:1
No n.a. address returned by DHCPv6 stateful
(default value)
DHCPv6.
Table 22: eNodeB support for OAM IPv6 interface automatic configuration
6.4.3 OAM interface configuration at initial eNodeB startup

At initial eNodeB startup the OAM interface is either configured locally using NEM/LMT or auto-
configured:
Configuration Type OAM IPv6 interface configuration at initial startup

Static Local Maintenance Terminal (NEM/LMT).
RAs and stateful DHCPv6, or
Automatic
Stateful DHCPv6 alone with Vendor Specific Information option,

or
Stateful DHCPv6 alone with fixed router IPv6 address.
Table 23: OAM IPv6 interface configuration at initial startup
6.4.4 OAM interface configuration at non initial eNodeB startup
After the initial eNodeB startup and the MIM configuration phase is complete the eNodeB MIM
contains valid parameter values.
OAM gives eNodeB the possibility to always use RAs for router discovery by leaving the router IPv6
address set to “unspecified address” in the MIM. On the contrary if a valid router address is stored
in the MIM it is used by eNodeB for constructing its routing table, the source address of RAs is then
ignored.
OAM IPv6 interface configuration at OAM IPv6 interface configuration at subsequent

initial startup eNodeB startup
Static MIM
MIM + RA for router discovery (1), or
RAs and DHCPv6 stateful
MIM (2)
DHCPv6 stateful alone with Vendor
MIM
Specific Information option
DHCPv6 stateful alone with fixed router
MIM
IPv6 address
(1) Router IPv6 address set to a null address in MIM.

(2) Router IPv6 address set to a non-null address in MIM. The source address of RAs is ignored.
Table 24: OAM IPv6 interface configuration at non initial startup
When RAs advertise a Prefix with the A-flag set and a router IPv6 address is set to a non-null
address in MIM then no auto-configured GUA is used by eNodeB but (as per the generic rule that
MIM data always supersedes automatic sources of configuration information) the OAM-defined GUA
stored in MIM is used instead.
6.4.5 Subnetting
Same rules applies for IPv6 as for IPv4 subnetting.
6.4.6 Routing
Same routing principle applies for IPv6 as for IPv4 routing.

When eNodeB is sending out an IP packet, whether or not the destination is on its local network or
not is determined by checking if the address prefix of both the destination IPv6 address and its
telecom IPv6 address are equal.
The number of bits to compare is 64 (= IpRoutingPrefixLengthTelecom).

6.4.6.1 Routing table initialisation
6.4.6.1.1 eNodeB initial start-up sequence – OAM IP interface is provisioned

− OAM ipv6Address
− OAM ipv6RoutingPrefixLength
− OAM ipv6AddressFirstHopRouter
− OAM vLanId
eNodeB performs NS/NA to discover MAC address of OAM first hop router

− ipv6Address
− ipv6RoutingPrefixLength
− Ipv6AddressFirstHopRouter
− vLanId

default routing via Telecom Ipv6AddressFirstHopRouter

6.4.6.1.2 eNodeB initial start-up sequence – OAM IP interface is auto-configured

− OAM vLanId
autoconfiguration specific − No OAM IPv6 address
eNodeB initiates all possibles methods for auto-configuring its IP address:

(1)
DHCPv4, DHCPv6 and IPv6 SLAAC
• If network is IPv6 only DHCPv6 or IPv6 SLAAC method is successful
• If network is IPv4 and IPv6 DHCPv4 & (DHCPv6 or IPv6 SLAAC)
methods are successful 1st received OAM packet defines the eNodeB IP
version (IPv6 in this case). DHCPv6 has precedence over SLAAC.
OAM ipv6Address is either auto-configured (SLAAC), or obtained from

DHCPv6 server.
OAM Ipv6AddressFirstHopRouter is either obtained from RA source
address, or from DHCPv6 if the Vendor Specific Information option is
used.
eNodeB performs NS/NA to discover MAC address of OAM first hop router

− ipv6Address
− ipv6RoutingPrefixLength
(2)
− Ipv6AddressFirstHopRouter
− vLanId

default routing via Telecom Ipv6AddressFirstHopRouter
(1): The initial start up phase is performed over the configured OAM VLAN ID. If neither IPv4 nor
IPv6 interface setup completes successfully, eNodeB repeats the initialization sequence over
Untagged Ethernet.

(2): If OAM Ipv6AddressFirstHopRouter=”::” in MIM then router address is derived from RA or from
DHCPv6 if the Vendor Specific Information option is used
6.4.7 IP QoS
In the IPv6 header, eNodeB sets the IP QoS (DSCP) in the Traffic Class field (7 bits).
Same DSCP mapping recommendation applies as for IPv4.
6.5 DUAL IPV4/IPV6 STACK
eNodeB does not support dual IP stack.
Telecom traffic is all using IPv4 or IPv6.
To allow for supporting OAM in IPv6 and Telecom in IPv6 while dual stack in not supported, eNodeB
software applications for OAM and Telecom are bound to two separate IP stacks.
6.6 IPV4 TO IPV6 MIGRATION

Reference document for the IPv4 to IPv6 migration is: ‘Alcatel-Lucent Long Term Evolution (LTE)
Radio Access Network (RAN) – Migration to IPv6 (Telecom and/or OAM) Procedure - 418-000-052’.
This procedure provides the steps for migrating one eNodeB at a time or a cluster of eNodeBs. It
mainly relies on a WiPS procedure.
IPv6 addresses are not supported with untagged Ethernet frames. The migration from IPv4 to IPv6
can be performed on condition that IPv4 runs over a VLAN configuration. If this is not the case both
the eNodeB and the next-hop router have to be upgraded to a VLAN configuration.
An eNodeB with IPv4 address on OAM traffic can be reconfigured with IPv6 address(es) for OAM
and/or Telecom remotely from OAM. Then, the eNodeB re-starts and reconfigures the IP interfaces
taking into account the received data.
eNodeB performs a full fall back to previous (working) configuration version when no SNMP traffic
from OMC is received after eNodeB reset from configuration change and the fallback timer
‘timerToWaitForFallbackToPreviousIPversion’ is expired.
When an eNodeB is migrated to IPv6 all of its neighbours still have IPv4 addresses. Thus all of the X2
links remain Disabled/Dependency and therefore all handovers are processed over S1 rather than
over X2.

6.7 ICMPV6 FOR NEIGHBORING DISCOVERY

The eNodeB accomplishes address resolution as per IETF RFC 4861 by using Neighbor Discovery
ICMPv6 messages.
Every ICMPv6 message is preceded by an IPv6 header and zero or more IPv6 extension headers. The
ICMPv6 header is identified by a Next Header value of 58 in the immediately preceding header.
The ICMPv6 message supported by eNodeB for network discovery are:
Message type Comment

Router Solicitation (RS) For SLAAC and router discovery.
Router Advertisement (RA) Periodic and solicited. For SLAAC and router discovery.
Neighbor Solicitation (NS) For DAD and link-layer address resolution.
Neighbor Advertisement (NA) Sent as response to NS or for propagating new information.
Table 25: ICMPv6 message supported for neighbor discovery
6.7.1 Source and destination IP addresses
Message type Source address Destination address Comment

If DAD for LLA is not yet
Router All-routers multicast complete the eNodeB can
eNodeB interface LLA
Solicitation address FF02::2. use the unspecified address
as source address.
eNodeB interface Solicited RA (reply to RS).
Router Periodic RAs (or RS source
Router interface LLA all-nodes multicast
Advertisement address was set to
address FF02::1
unspecified).
Solicited-node multicast
Unspecified address address corresponding DAD case.
to the target address
Neighbor eNodeB interface LLA or Solicited-node multicast
Solicitation preferably the eNodeB address corresponding For Address Resolution.
interface GUA (updates to the target address.
the neighbor cache at Unicast address of the For neighbor unreachability
the destination node) target. detection.
The source address of
the invoking NS when NA for address resolution.
A unicast address non-null.
Neighbor
assigned to the sending
Advertisement NA in this case informs the
interface. The all-nodes multicast
requester of an address
address.
collision.
Table 26: Source and Destination IPv6 addresses for Network Discovery messages

6.7.2 Router Solicitation
0-7 8 - 15 16 - 31
Type = 133 Code = 0 (ICMPv6) Checksum
Reserved = 0
Options
Table 27: Router Solicitation message format

Options:
Source link-layer address: the eNodeB may send this option to advertise its link layer (MAC) address.
6.7.3 Router Advertisement

Router Advertisements are the standard way for an IPv6 Node to build the list of available IPv6
routers (router discovery).
Each time the eNodeB sends a RS it receives RAs from the available router(s) (in this release a single
one is supported) on the link. RAs are also sent periodically by routers. This is the best possible
source of information on routers. Router Advertisements must advertise a LLA as router address.
0-7 8 9 10 - 15 16 - 31
Type = 134 Code = 0 (ICMPv6) Checksum
Cur Hop Limit M O Reserved Router Lifetime
Reachable Time
Retrans Timer
Options
Table 28: Router Solicitation message format

Cur Hop Limit: default value for the ‘Hop Limit’ of outgoing IPv6 packets.
Rule: <eNodeB> <ICMPv6> <Design>
The eNodeB sets the Hop Limit field to 255 in all egress IPv6 packets.
Cur Hop Limit advertised by the IPv6 router in RAs is ignored by eNodeB.
M-bit: the ‘Managed address configuration’ flag is set when DHCPv6 is available.
O-bit: the ‘Other configuration’ flag is set when DHCPv6 is available but address assignment
excepted (stateless).
These two flags convey the following information:
M-bit & Obit flags Available source(s) of information for automatic configuration
M=0 & O=0 Router Advertisements
M=0 & O=1 Router Advertisements and Stateless DHCPv6
M=1 & O=any Router Advertisements and Stateful DHCPv6
Table 29: M and O Flags in RA messages

M-bit and O-bit values in Router Advertisement messages are ignored by eNodeB.
Regardless of their values the eNodeB always initiates both a RS/RA exchange and a DHCPv6
stateful exchange at initial eNodeB start up.
Router Lifetime:
When RAs are present on the link the eNodeB takes into account the ‘Router Lifetime’ timer
advertised by the router in RAs.
The router IPv6 address is invalidated by eNodeB if no RA is received in ‘Router Lifetime’ seconds.
This router invalidation procedure is only supported when the router IP address is set to
“unspecified address” in the MIM. When the router IPv6 address is set by OAM to a non-null value
the associated router lifetime is infinite (RAs are not used for router discovery).
A router lifetime value of 0 immediately invalidates the router IP address that is no longer used by
the eNodeB. When a router resumes sending RAs on the link with a non-null router lifetime the
eNodeB adds the sending router to the router list.
Reachable Time: The time, in milliseconds, that a node assumes a neighbor is reachable after
having received a reachability confirmation.
Reachable Time is ignored by eNodeB.
Retrans Timer: The time, in milliseconds, between retransmitted Neighbor Solicitation messages.
Retrans Timer is ignored by eNodeB.

eNodeB uses the NS/NA procedure whether RAs are available or not. Therefore eNodeB uses in the
presence of RAs the same timer value as when RAs are disabled.
Options:
Source link-layer address: the router may send this option to advertise its link layer (MAC) address.
eNodeB uses NS/NA to learn the router MAC address if it is not advertised in the RA.
MTU: it is assumed that the MTU option is not configured on the router.

The MTU value is set by OAM and needs not be received from the router.
In case of conflict the eNodeB chooses the MTU value set by OAM.
Prefix information: the router advertises one or more on-link Prefixes (L-bit set). Stateless auto-
configuration is optional (0 Prefix with A-bit set).
0-7 8 - 15 16 - 23 24 25 26 - 31
Type = 3 Length = 4 Prefix Length L A 6 bits set to 0
Valid Lifetime
Preferred Lifetime
Reserved2 = 0
Prefix
Table 30: Prefix information option format
L-bit: set when the advertised Prefix is on-link (which should always be the case).
A-bit: set when the advertised Prefix can be used for stateless autonomous address auto-
configuration (SLAAC). When set the L-flag is also set.
Valid Lifetime and Preferred Lifetime: set to infinity.
Prefix Length: set to 64.
eNodeB IPv6 Prefix Length is always 64 bits.
Prefix: A 128-bit field with “Prefix length” (64) meaningful leading bits (the Prefix value) and 64
trailing bits set to 0.
Restriction: <eNodeB> <ICMPv6> <Design>
eNodeB supports RAs only in the “OAM VLAN”.

eNodeB ignores RAs in “Telecom VLAN(s)”.
6.7.4 Neighbor Solicitation / Neighbor Advertisement
The eNodeB accomplishes address resolution as per IETF RFC 4861 by multicasting ICMPv6
Neighbour Solicitation message that asks the target node to return its layer 2 link-layer address.
ICMPv6 Neighbour Solicitation messages are multicast to the solicited-node multicast address of the
target address.
The target returns its layer 2 link-layer address in a unicast ICMPv6 Neighbour Advertisement
message.
For efficiency the eNodeB can also include its own layer 2 address in the ICMPv6 Neighbour
Solicitation that can be used by the target node to update its own cache.

6.8 DHCPV6
eNodeB can use DHCPv6 to get its OAM IPv6 address.
eNodeB supports DHCPv6 only in the “OAM VLAN”.
6.8.1 DHCPv6 stateless

DHCPv6 stateless does not assign IPv6 addresses. It only returns configuration parameters to the
client.
DHCPv6 Stateless is not supported by eNodeB.

There is no parameter to be retrieved from a DHCP server other than the IP address.
6.8.2 DHCPv6 stateful

DHCPv6 stateful returns DHCP options but it also assigns one or more IP addresses to the requesting
client.
eNodeB supports a single IPv6 address assignment by the DHCPv6 server.
ALU DHCPv6 implementation supports optional parameter ‘Vendor Specific Information’ for in add
passing the router IP address.
Figure 74: Stateful DHCPv6 message sequence
SOLICIT message is a multicast message sent out by the DHCP client to verify that there is a DHCP
server available to handle its requests.
ADVERTISE unicast message is sent out by the DHCP server as a reply to the SOLICIT message that
was sent out by the DHCPv6 client that it can handle the requests.
REQUEST multicast message is sent out by the DHCPv6 client to request its configuration
information from the DHCPv6 server.

REPLY unicast message is sent out by the DHCPv6 server to the DHCPv6 client, and it contains the
configuration information that the DHCPv6 client requested.
DHCPv6 DHCPV6 RELAY DHCPV6

CLIENT (eNB) (7705/7750) SERVER
SOLICIT (multicast)
RELAY-FORWARD
RELAY-REPLY
ADVERTISE (unicast)
REQUEST (multicast)
RELAY-FORWARD
RELAY-REPLY
REPLY (unicast)
Figure 75: Relayed DHCPv6 message exchange
The following additional messages are used when a DHCP relay is required:
RELAY-FORWARD message is forwarded towards the DHCPv6 server as a result of the DHCPv6 SOLICIT
or REQUEST message
The DHCPv6 RELAY-REPLY message is forwarded toward the DHCPv6 client as a result of response
from the DHCPv6 server for responses to the SOLICIT and REQUEST requests.
6.8.3 Source and destination IP addresses
Message type Source address Destination address

SOLICIT eNodeB interface LLA All DHCP Relay Agents and Servers multicast address
FF02::1:2
ADVERTISE A Unicast address eNodeB interface LLA
REQUEST eNodeB interface LLA All DHCP Relay Agents and Servers multicast address
FF02::1:2
REPLY A Unicast address eNodeB interface LLA
Table 31: Source and destination IP addresses of DHCPv6 messages
6.8.4 DHCPv6 message format
0-7 8 - 31
Msg-type Transaction-id
Options (variable)
Table 32: DHCPv6 message format

The eNodeB generates the value of the Transaction-id field that is returned by the DHCPv6 server.

DHCPv6 is used for permanent assignment of a single DHCPv6 address.

Therefore the eNodeB only supports the initial DHCPv6 sequence made of the Solicit, Advertise,
Request and Reply messages.
DHCPv6 messages that are related to non-permanent address assignment (Confirm, Renew, Rebind,
Release, Decline, Reconfigure) are not supported.
The Information-Request message (DHCPv6 stateless) is not supported.
Message type Value Comment

SOLICIT 1 Sent by eNodeB
ADVERTISE 2 Received by eNodeB
REQUEST 3 Sent by eNodeB
CONFIRM 4 Not supported
RENEW 5 Not supported
REBIND 6 Not supported
REPLY 7 Received by eNodeB (server replies to a Request message)
RELEASE 8 Not supported
DECLINE 9 Not supported
RECONFIGURE 10 Not supported
INFORMATION-REQUEST 11 Not supported
RELAY-FORW 12 Relay messages, not supported by eNodeB.
RELAY-REPL 13
Table 33: Supported DHCPv6 messages
6.8.5 DHCPv6 option format
0 - 15 16 - 31
Option-code Option-len
Option-data (option-len octets)
Table 34: DHCPv6 option format

DHCPv6 options may appear at DHCPv6 message level or they can be embedded in another option.

Option Code Sent / Comment

Rec.
Client Identifier 1 S, R Option-data field conveys the client’s DUID.
Sent by eNodeB, returned by server.
Server identifier 2 R, S Option-data field conveys the server’s DUID.
Sent by server in Advertise message
Returned by eNodeB in Request message
Identity Association for 3 S, R Sent by eNodeB in Solicit message.
Non-temporary Addresses - Sent by server
IA_NA
Identity Association for 4 Not supported
Temporary Addresses -
IA_TA
IA Address 5 R Encapsulated in IA_NA.
Used by the server to return an IPv6 address.
Option Request 6 Not supported.
The DHCPv6 server is to be configured so as to return
the options the eNodeB needs.
Preference 7 Not supported
Elapsed Time 8 Not supported
Relay Message 9 Not used by eNodeB
Authentication 11 Not supported
Server Unicast 12 Not supported
Status Code 13 R May appear at DHCP message level or embedded in
another option (e.g. an IA_NA option)
Rapid Commit 14 Not supported
User Class 15 Not supported
Vendor Class 16 S Supported.
Vendor Specific 17 R Supported.
Information Conveys the router IPv6 address when no RAs.
Interface-Id 18 Not used by eNodeB
Reconfigure message 19 Not supported
Reconfigure Accept 20 Not supported
Table 35: Supported DHCPv6 options
6.8.5.1 Client Identifier
0 - 15 16 - 31
Option-code = 1 Option-len = variable
eNodeB DHCP Unique ID (DUID) (variable length)
Table 36: DHCPv6 Client Identifier format

The eNodeB uses the DUID-EN format as per IETF RFC 3315:
0 - 15 16 - 31
(1)
DUID Type = 2 (DUID-EN) Enterprise-number = 637 (= ALU)
Enterprise-number (contd)
(2)
Identifier (variable length)
(1)
The enterprise-number of Alcatel-Lucent registered at IANA is 637
(2)
The eNodeB identifier is set to the eNodeB Serial Number.
Table 37: DUID-EN format
6.8.5.2 Identity Association for Non-temporary Addresses (IA_NA)
A DHCP message may include multiple IA_NA options but a single one is supported.
The eNodeB requests a single IPv6 address by sending a single IA_NA option in the initial DHCPv6
SOLICIT message.
0 - 15 16 - 31
IAID (4 octets)
T1
T2
IA_NA-options
Table 38: IA_NA format

• IAID is the IA_NA identifier. It is to be unique among all IAIDs used by a client.
As per eNodeB DHCPv6 client requirement, the IAID is set to the last four octets of the MAC address
of the eNodeB sending interface.
Reminder: MAC addresses are made of 6 bytes: 3 first bytes identify the enterprise which delivers
the interface, while the 3 following bytes identify the interface within the constructor.
Since a single IPv6 address per eNodeB is retrieved using DHCPv6 the DUID alone identifies
unambiguously the pre-configured OAM address binding in the DHCPv6 server then the IAID does not
bring useful identification information to the server.
• T1 and T2 relate to lease renewal.

The eNodeB never renews the lease of the OAM IP address assigned by DHCPv6.
The eNodeB IPv6 OAM address is permanently assigned.
The eNodeB does not indicate a preference for a particular IPv6 address to the server. It leaves the
IA_NA options field empty.
The DHCPv6 server inserts the “IA Address” option and/or the “Status Code” option in the IA_NA-
options field.
6.8.5.3 IA Address
The IA Address Option is always conveyed in the IA_NA-options field of an IA_NA Option instance in
the server-to-client direction.
0 - 15 16 - 31
IPv6 address (16 octets)
preferred-lifetime
valid-lifetime
IAaddr-options
Table 39: IA Address format

The IAaddr-options field may include a status code option (can be omitted if successful).
6.8.5.4 Status Code
0 - 15 16 - 31
Status-code
Status-message (for display to an end user, ignored by eNodeB if present)
Table 40: Status Code format

The absence of a Status Code Option is equivalent to a Success Status.

Status Code Coment

Success 0 Success
UnspecFail 1 Failure, reason unspecified
NoAddrsAvail 2 Server has no addresses available to assign to the IA(s). An
Advertise message that includes this Status Code is ignored by
eNodeB.
NoBinding 3 Client record unavailable
NotOnLink 4 The prefix for the address is not appropriate for the link to
which the client is attached.
UseMulticast 5 Sent by a server to a client to force the client to send messages
using the All DHCP Relay Agents and Servers address.
NoPrefixAvail 6 Delegating router has no Prefixes available to assign to the
IA_PD(s). Not supported.
Table 41: DHCPv6 Status Codes
6.8.5.5 Vendor Class
0 - 15 16 - 31
(1)
Enterprise-number (4 octets)
Vendor-Class-Data
(1) The enterprise-number of Alcatel-Lucent registered at IANA is 637

Table 42: Vendor Class
Each instance of the Vendor-Class-Data field is formatted as per IETF RFC 3315:
Vendor-Class-len = length of opaque-data Opaque-data …
Table 43: Vendor-Class-Data format

The eNodeB includes a single Vendor-Class-Data instance in the Vendor Class Option.
The opaque data field value is identical to the value defined for the DHCPv4 Vendor-Class-Identifier
field (Option 60).

The Vendor-Class-Data is hard-coded in eNodeB to the string “ENODEBALUTYPE1”.
6.8.5.6 Vendor Specific Information
0 - 15 16 - 31
Option-code = 17 Option-len = 24
(1)
Enterprise-number (4 octets) = 637 (= ALU)
Option-data field (20 octets)
(1) The enterprise-number of Alcatel-Lucent registered at IANA is 637

Table 44: Vendor Specific Information format
eNodeB supports following options in the Option-data field:
Option code = 256 Router IPv6 address
Option code = 257 EMS IPv6 address(es) & port number(s)
Option code = 258 SEG IP address
Option code = 259 EMS FQDN
Option Code = 260 SEG FQDN
Option Code = 261 EMS IPv4 address(es) & port number(s) (for IPv4 over IPv6 IPsec)
6.8.5.6.1 Vendor Specific Information - IPv6 router address
This option may be returned by the DHCPv6 server to convey the IPv6 router address.
This option may be used when Router Advertisements are switched off.
0 - 15 16 - 31
Option-code = 256 (router IP@) Option length = 16
IPv6 address of the router on the link that hosts the eNodeB (16 octets)
Table 45: DHCPv6 proprietary option for IPv6 router address

The option-code range 0-255 is reserved (e.g. for use by 3G NodeB).
6.8.5.6.2 Vendor Specific Information - EMS IPv6 address/Port number
This option may be returned by the DHCPv6 server to convey the EMS (SAM) IPv6 address & port
number.

0 - 15 16 - 31
Option-code = 257 (EMS IPv6@) Option length = n x (16 + 2)
IPv6 address of the EMS (16 octets) + Port number (2 octets)
Table 46: DHCPv6 proprietary option for EMS IPv6 address/Port number
One or several concatenated EMS IPv6@/Port number can be sent back in the same Option-data
field.
6.8.5.6.3 Vendor Specific Information - Security Gateway IP address
This option may be returned by the DHCPv6 server to convey the Security Gateway IP address.
0 - 15 16 - 31
Option-code = 258 (SEG IP@) Option length = 16
IPv6 address of the SEG (16 octets)
Table 47: DHCPv6 proprietary option for Security Gateway IP address
6.8.5.6.4 Vendor Specific Information - EMS FQDN
This option may be returned by the DHCPv6 server to convey the EMS FQDN.
0 - 15 16 - 31
Option-code = 259 (EMS FQDN) Option length = max 64
EMS FQDN (max 64 octets)
Table 48: DHCPv6 proprietary option for EMS FQDN
6.8.5.6.5 Vendor Specific Information - SEG FQDN
This option may be returned by the DHCPv6 server to convey the EMS FQDN.
0 - 15 16 - 31
Option-code = 260 (SEG FQDN) Option length = max 64
SEG FQDN (max 64 octets)
Table 49: DHCPv6 proprietary option for SEG FQDN
6.8.5.6.6 Vendor Specific Information - EMS IPv4 address/Port number
This option may be returned by the DHCPv6 server to convey the EMS (SAM) IPv4 address & port
number when the backhaul is IPv6 and the EMS is IPv4 (IPv4 over IPv6 IPsec).
0 - 15 16 - 31
Option-code = 261 (EMS IPv4@) Option length = n x (16 + 2)
IPv4 address of the EMS (16 octets) + Port number (2 octets)
Table 50: DHCPv6 proprietary option for EMS IPv4 address/Port number
One or several concatenated EMS IPv4@/Port number can be sent back in the same Option-data
field.

6.9 SCTP
SCTP is the choosen protocol to transport control messages between the eNodeB and the MME over
the S1-MME interface (S1-AP/SCTP/IP/ETH/PHY) and between eNodeB’s over the X2-C interface (X2-
AP/SCTP/IP/ETH/PHY).
6.9.1 Association initiation failure

The eNodeB after it sends INIT message sets the T1-init timer. If the timer expires before an INIT-
ACK is received from the peer, the eNodeB resends the INIT message a maximum number of times
set by the parameter “max.INIT.Retransmits”.
If the INIT-ACK is not forthcoming on the last re-send the eNodeB raises alarm “SCTP ASSOCIATION
FAILURE”.
The eNodeB requests the SCTP protocol retry to initialize the association a repeated number of
times as defined by ALU proprietary parameter “sctpAssocEstablishmentMaxRetries”.
The value 255 defines ‘infinite’ number of retries.
eNodeB Peer SCTP

endpoint
INIT # 1
start T1-init
INIT # 2
start T1-init
up to Max.Init.Retransmits
INIT # n
start T1-init
T1-init
X SCTP association failure alarm
expiry
sctpAccessEstablishmentRetryInterval
up to sctpAssocEstablishmentMaxRetries (1)
Figure 76: Association establishment failure – ALU implementation
Similarly during Initialisation, if the eNodeB receives the INIT-ACK and sends COOKIE, it starts the
T1-cookie timer. If the timer expires the eNodeB resends the COOKIE message a maximum number
of times set also by the parameter “max.INIT.Retransmits”.
If the COOKIE-ACK is not forthcoming on the last re-send the eNodeB raises alarm “SCTP
ASSOCIATION FAILURE”.
6.9.2 Association failure / Path failure

The eNodeB monitors the SCTP associations for failure based on Heartbeat ACK’s and Data ACK’s
monitoring. Data Chunks are retransmitted based on the RTO Retransmission Timer within the SCTP

stack. If the RTO expires before a Data Chunk is acknowledged then the Data Chunk will be
retransmitted.
The Heartbeat repetition interval is function of parameter “HB.Interval”.

SCTP maintains a retransmission counter per path. When a counter exceeds the “Path.Max.Retrans”
the destination address is marked as inactive.
The only action performed on path failure is the switching of the primary path by the SCTP stack.
No indication is sent to OAM when this occurs.
SCTP also maintains a counter for the total number of retransmissions to the peer over all paths (if
peer is multi-homed). When the counter exceeds the Association.Max.Retrans to the peer the
eNodeB considers the peer unreachable, stops transmitting and raises alarm “SCTP ASSOCIATION
DOWN”.
The eNodeB requests the SCTP protocol retry to initialize the association a repeated number of
times as defined by ALU proprietary parameter “sctpAssocEstablishmentMaxRetries”.
eNodeB Peer (1)

IP@1 &
Data to IP@1
start T3-rtx
RTO
Data and/or SACK
T3-rtx expiry X
error_path1 = +1
Primary path
start HB timer Heartbeat to IP@1 (IP@1)
HB timer (2)
HB timer expiry Heartbeat Ack
X
error_path1 > error_path1 = +1
sctpAccessPathMaxRetrans X switch to secondary path
Data to IP@2
start T3-rtx
Secondary path
RTO (IP@2)
Data and/or SACK
T3-rtx expiry X
error_assoc > error_path2 = +1
sctpAccessAssociationMaxRetrans X alarm - SCTP association down
(1) Peer = eNodeB or MME

(2) HB timer = RTO + HB.interval x (1 + δ)
δ is randomly choosen in [-0.5; 0.5] at association establishment
Figure 77: Path failure & Association failure – case of peer multi-homed
6.9.3 SCTP parameters setting at eNodeB

SCTP parameter (IETF RFC 4960) hard-coded value at eNodeB

Max.Burst 4
Valid.Cookie.Life 60 s
HB.Max.Burst 1
SACK frequency 2
Configurable parameter at eNodeB
RTO.Alpha sctpAlphaDivisor
RTO.Beta sctpBetaDivisor
RTO.Initial sctpRTOInit
RTO.Min sctpRTOMin
RTO.Max sctpRTOMax
HB.Interval sctpAssocHeartbeatInterval
Max.Init.Retransmits sctpAccessMaxInitRetransmits
Association.Max.Retrans sctpAccessAssociationMaxRetrans
Path.Max.Retrans sctpAccessPathMaxRetrans
SACK period sctpSACKTimer
Table 51: SCTP parameters setting at eNodeB
The configurable parameters are to be set per SCTP interface instance.
See chapters on S1 interface and X2 interface for more details.
6.9.4 Peer’s Stream Identifiers detection

3GPP does not define the Stream ID for the streams supporting common and dedicated messages.
ALU eNodeB transmits common procedure messages on Stream ‘0’, and dedicated procedure
messages on stream ‘1’.
A 3rd party Enb/MME supplier may have a different stream allocation.
IETF RFC 4960 defines the number of streams shall be the minimum of the local Outbound streams
(OS), and the Maximum Inbound Streams (MIS) supported by the peer.
ALU eNodeB supports OS=2 and MIS=2. This defines a number of 2 streams, which is the 3GPP
minimum.
ALU eNodeB detects the first message from the peer node (eNodeB or MME) received in a DATA
Chunk following association establishment. Knowing this is supporting a common procedure eNodeB
considers that messages received on this stream ID are related to common procedures and that
messages received on the other stream ID are related to dedicated procedures.
The first X2 (or S1) message received after SCTP association establishment is either X2 (or S1)
Setup Request or X2 (or S1) Setup Response message. It depends on which side of the X2 (or S1)
interface has established the association, the eNodeB or its peer.
6.10 SECURITY
6.10.1 IPsec Feature
This section assumes the reader has prior knowledge of IPsec functionality. A Generic IPsec
Description section has been included in this document for the reader’s reference.

6.10.1.1 Dependencies & Assumptions
• The eNodeB feature can be activated on a per eNodeB basis. In order to activate the eNodeB
IPsec functionality, an IPsec license must be activated for each eNodeB. With the addition of eUtran
sharing the IPsec License is still required as long as any operator on the eNodeB wish to enable
IPsec. The following table gives an example licensing requirement.
Master Operator Operator A IPsec License

Use IPsec Use IPsec Master Operator requires a single
IPsec SW license per eNB
Use IPsec Do not use IPsec Master Operator requires a single
Do not use IPsec Use IPsec Master Operator requires a single
Do not use IPsec Do not use IPsec No SW License required
• Ipsec is dependant on VLAN and IP version (IPv4 or IPv6) address assignment.
• IPsec Activation:
OMC uses a new transport configuration after an OAM IPsec tunnel is setup. This new configuration
is generated with WPS and transferred to the OMC, which downloads it to the eNB. The eNB takes
into account the new transport parameters and restarts. All traffics are lost. After the eNB restart,
the requested IPsec tunnels are setup.
If after a while the OMC-eNB connection is not re-established, the eNB automatically returns to its
previous configuration and restarts.
Object: Enb, Parameter: timerToWaitForFallbackToPreviousIPversion, Value: [30-120] (with step =
1), Unit: minute, Default: 30, Class: C, Service impact: None, Update transient impacts details:
New-set-ups
6.10.1.2 Network Connectivity
IPsec is an end-to-end security scheme operating in the Internet layer of the Internet Protocol Suite.
It can be used in protecting data flows between a pair of hosts (host-to-host), between a pair of
security gateways (network-to-network), or between a security gateway and a host (network-to-
host). IPsec protects any application traffic across an IP network.
The LTE transport network will support the host-to-network configuration. The transport networks
IPsec session peer will be referred to as the Security Gateway (SEG). The eNodeBs will be the hosts
connected to the network SEG. The network SEG will be the communications hub between all IPsec
hosts. Figure 78 depicts the network-to-host topology for a single operator in reference to the LTE
components.
Engineering: <eNodeB> <IPsec> (<Topology>)
The Host-to-Network configuration is the only supported network topolgy
All secured IP communications between eNodeB’s and other LTE components will be forwarded to
the SEG for encryption / decryption prior to the packet being forwarded to the final destination.

Figure 78
78: IPsec Host-to-Network Security Topology
The following diagram depicts the network configuration for multiple operators sharing a common
eNodeB. This is referred to as Multiple Operator Core Netwrok (MOCN) eUTRAN sharing model.
There is a master operator that
hat owns and configures the eNodeB. The MOCN model was intended to
share the eNodeB only. Each operator will have their own core network components. Refer to
section 6.1.5.1for
for complete MOCN operation. This section only pertains to IPsec in reference to
MOCN.
Alcatel-Lucent

Figure 79: MOCN eUTRAN Sharing
A more detailed example of a two operator scenario is depicted in the following picture. In this
configuration the eNB will belong to operator A (master operator). Operator B (non master
operator) will use use the same eNB that is owned by operator A. With the eUTRAN sharing feature,
the IPsec config and supported architecture is slightly modified to accommodate multiple operators
sharing the same eNodeB.

Figure 80: eUTRAN Sharing Architecture
In the eUtran shared architecture the eNodeB will only have one OAM network connconnection.
ection. The OAM
network connection will belong to the master operator. AN IPsec tunnel can be configured for the
OAM or Telecom traffic. Each of the telecom transport commuications will belong to their
respective operator (i.e S1-U, S1-C,
C, X2-U).
X2 It is expected
cted that each operator will have their own
Security gateway and LTE transport network components (i.e. MME, SGW). The X2-U X2 U traffic will only
be transported on the master operators IPsec communications since this is an eNodeB to eNodeB
communications and owned
wned by the master operator. Each Operator can independently
enable/disable IPsec tunnels.
Figure 81 depicts an example of a source eNB has to send X2 traffic to a target eNB. In this example
the Source eNB will encrypt the transmitted packet and forward the packet to the SEG. The SEG will
in turn decrypt the packet sent from the source eNB and determine the proper route to send the
original X2 packet. In this case the original X2 packet will be forwarded to the target eNB. Prior to
the SEG transmitting the packet, the SEG will encrypt the X2 packet with the appropriate algorithm
associated with the IPsec tunnel that the SEG has negotiated with the target eNB. When the target
eNB receives the encrypted eNB packet, it will decrypt the packet and process the packet.
NOTE: The diagram displays the SEG < <-> MME and SEG <->> SGW traffic as IPsec encrypted, This is
not the case. For release LA3.0.2, the eNB <
<->
> SEG is the only optional encrypted path.
Alcatel-Lucent

Figure 81: IPsec Traffic Flow
Alcatel-Lucent

Figure 82: X2 User Plane Traffic
The IKE negotiations have a failure mechanism. When there is a timeout in the IKE negotiation, the
peer will periodically retransmit and wait for acknowledgement. If acknowledgement is not received
in the timeout value, the new timeout value will be derive
derived
d from an exponential algorithm. After
several retries, the IKE negotiation is deemed failed negotiations.
6.10.1.3 IPsec Configuration & Hard coded Parameters
IPsec has two types of methods for protecting IP datagrams. The first protocol is the Encapsulating
Security Protocol (ESP) and the second is the Authentication Header (AH). The ESP provides
confidentiality using an encryption
cryption algorithm and data integrity using an authentication algorithm.
The AH provides data integrity but not confidentiality. Either the ESP or the AH protocol are
negotiated at the time of SA establishment.
Alcatel-Lucent

Rule: <Network> <IPsec> <Standard>
ESP is the only supported IPsec protocol as per standard : 3GPP TS 33.210 V9.1.0 section 5.3.1
The EnodeB and the SEG must be configured with the corresponding protection packet
configuration. IPSec allows either Transport or Tunnel mode. The EnodeB will only support Tunnel
mode and therefore the SEG must have the corresponding functionality.
Rule: <Network> <IPsec> <Standard>
IPsec tunnel mode is the only tranport setting allowed as per standard: 3GPP TS 33.210 V9.1.0
section 5.3.2
The eNodeB will only support certain IPsec configurations as presented below.
Rule: <eNodeB> <IPsec> <Requirement>
eNodeB will only support IKEv2

eNodeB will NOT support IPsec NAT (for the Macro device only)
Feature 163826- 13.3 This applies to MACRO only, For Metro, IPV6 can flow over IPv4. eNodeB will
only support inner and outer tunnel address of the same type (i.e. both IPv4 or both IPv6)
A maximum of 1 IPsec tunnel per VLAN association
The following hard coded taffic that will not be included in IPsec tunnel
• 1588
• IPv6 ND
6.10.1.4 Supported Parameters
The following parameters are hard coded in the eNodeB.

IKE Encryption 3 DES CBC
AES CBC 128 (IETF RFC 3602)
HMAC-SHA-96 (IETF RFC 2404)
IKE Authentication Diffie-Hellman exchange group 2 with 1024 MODP (IETF RFC 2409,
IETF RFC 4307 and IETF RFC 3526).
Diffe-Hellman exchange group 14 with 2048 bit MODP (Network
Transport Security SRS 13.3, 159440).
ESP Authentication NULL
HMAC-MD5-96
HMAC-SHA-1-96 (Mandatory)
AES-XCBC-MAC
ESP Encapsulation ESP
NULL
3 DES CBC
AES-CBC 128 (Default)
AES-CBC
AES-CBC 256
Mode Tunnel
Key Generation Diffie-Hellman
Resiliency and High IPsec Failover
Availability Dead Peer Detection (DPD)
IP Version IPv4 Support
IPv6 Support
6.10.1.5 IPsec Configuration Parameters
In the case of eUTRAN sharing network, the IKE parameters are configurable per operator basis. The
IPsec parameters will be associated per VLAN basis, each operator’s traffic will be on different
VLANs.
The following diagram of the IPsec configuration object modules:

Figure 83: IPsec / CMS MIM
IPsec Service
ActivationService:
isIpsecEnable - IPSec Service Activation. This is a logical parameter must be enabled prior to
setting the IPsec General or specific IPsec tunnel parameters.
IPsec General Parameters (per eNodeB)
These parameters are used in the IPsec IKE optional functionality or negotiated parameters
between IPsec Peers.
Parameter isIpsecEnable
Object ENBEquipment/
ENBEquipment/eNB/ActivationService
Range & Unit Boolean
True/False
Class A - full-NE-reset
reset
Value False
Feature FRS 101808
Alcatel-Lucent

isCertificateEnabled: - Certificate Activation. This is a logical parameter to enable CMS

certificates in the eNB. The value can be set to “True” only if isIPsecEnable is set to true.
Parameter isCertificateEnabled
Object ENBEquipment/eNB/ActivationService
True/False
Value False
Feature FRS 101812
isCertificateRevocationChecksEnabled: This parameter enables or disables support for

Certificate Revocation Lists (CRLs).
Parameter isCertificateRevocationChecksEnabled (Deffered)

True/False
Value False
Feature
TrafficDescriptor:
eNBIPsecpolicy - This parameter specifies whether the in bound traffic will be bypassed,
checked for Integrity or protected by integrity protection and encrypted.
(0) “no-IPsec”
IP packets matching this policy are sent outside the IPsec tunnel.
(1) “integrity protection only”

IP packets matching this policy are sent inside the IPsec tunnel; they are authenticated but
not encrypted.
(2) “integrity protection and encryption”
IP packets matching this policy are sent inside the IPsec tunnel; they are authenticated and
encrypted.

Parameter eNBIPsecpolicy
Object ENBEquipment/eNB/EnbTransportConfig/RanBackhaul/VLAN/TrafficDescriptor
Range & Unit List of elements corresponding to Traffic Type List
List Range
{1, 2, 3 , 4, 5, 6, 7}
Each list element has an enumeration.
Enumerate
{ 0, 1, 2 }
Value (0) No IPsec for each element
Feature FRS 101808
IPsecTunnelConf:
eNBpreSharedSecret – This is a manually loaded key that facilitates the IKE Authentication
process between peer entities. When IKE negotiation begins, the peers exchange keys to
mutually authenticate each other.
Parameter eNBpreSharedSecret
Object ENBEquipment/eNB/EnbTransportConfig/RanBackhaul/VLAN/IPsecTunnelConf
Range & Unit String
[0,40] Characters
Value NULL
Feature FRS 101808
ipsecTunnelname - Logical Name entry to identify the tunnel.
Parameter ipsecTunnelname
Range & Unit String
[0,255] Characters
Value NULL
Feature FRS 101808
ipv4AddressEnbIPsecTunnel - The IPv4 outer tunnel address.

Parameter ipv4AddressEnbIPsecTunnel
Range & Unit IPv4 address
Value N.A.
Feature FRS 101808
ipv4AddressFirstHopRouter - The IPv4 address of the first hop router for the IPsec tunnel. The
first hop router does not have to be the Security Gateway (SEG).
Parameter ipv4AddressFirstHopRouter
Value N.A.
Feature FRS 101808
ipv4AddressSegIPsecTunnel - The IPv4 address of the Security Gateway end point of the IPsec
tunnel.
Parameter ipv4AddressSegIPsecTunnel
Value N.A.
Feature FRS 101808
ipv4SubNetMaskEnbIPsecTunnel - The IPv4 subnet mask to define the size of the subnet.
Parameter ipv4SubNetMaskEnbIPsecTunnel
Value N.A.
Feature FRS 101808
ipv6AddressEnbIPsecTunnel - The IPv6 outer tunnel address.

Parameter ipv6AddressEnbIPsecTunnel
Value N.A.
Feature FRS 101808
ipv6AddressFirstHopRouter - The IPv6 address of the first hop router for the IPsec tunnel. The
first hop router does not have to be the Security Gateway (SEG).
Parameter ipv6AddressFirstHopRouter
Value N.A.
Feature FRS 101808
ipv6AddressSegIPsecTunnel - The IPv6 address of the Security Gateway end point of the IPsec
tunnel.
Parameter ipv6AddressSegIPsecTunnel
Value N.A.
Feature FRS 101808
ipv6RoutingPrefixLengthEnbIPsecTunnel - The IPv6 ptre-fix mask to define the size of the

subnet.
Parameter ipv6RoutingPrefixLengthEnbIPsecTunnel
Range & Unit [0-128]
Value N.A.
Feature FRS 101808
ipFormat - The This parameter specifies the format (IPv4 or IPv6 ) that is applicable to the
traffic described by the “TrafficDescriptor” MO instance.
This parameter can be set for MCI. It is used when the traffic is encapsulated in IPsec and
describes the format of the inner IP header (the format of the outer IP header is described by
the ipFromat parameter of the parent Vlan instance).

Parameter ipFormat
Range & Unit Enumerate
IPv4(0), IPv6(1), IPv6overIPv4 (2)
Class A
Value False
Feature 163456 & 163826
trafficDescriptorIdList parameter refers to the instances of TrafficDescriptor object that describe the
IPsec child SA pairs under the IKE SA pair described by this IPsecTunnelConf MO instance.
This parameter is set for MCI.
Parameter trafficDescriptorIdList (Deffered)

Range & Unit ServiceLink
(1-10)
Value NA
Feature 163456
IPsecConf:
ikeAuthMethod - This parameter is provided to distinguish which method is used to

authenticate IPsec Peers. The choices are (0) pre-shared secret keys (presharedkeys) or (1)
Certificates are allowed.
IPsec Tunnel Specific Parameters (per eNodeB / per tunnel)
The following parameters are specific to each IPsec tunnel.
Parameter ikeAuthMethod
Object ENBEquipment/eNB/EnbTransportConfig/PerOperatorConf/IPsecConf
{0,1}
Value (0) Pre Shared Keys
Feature FRS 101808
IkeRetryBase - This parameter specifies the base of exponential back-off multiplied by 10. The
true exponential back-off used in the calculation will be the IkeRetryBase entered divided by 10.

Parameter IkeRetryBase
Range & Unit [10 – 20 ]
Class C- New-set-ups
Value 13
Feature FRS 101808
IkeRetryCount - This parameter specifies the maximum number of times an IKE

INFORMATIONAL message is retransmitted before detecting an IPsec tunnel failure.
Parameter IkeRetryCount
Range & Unit [1 – 100 ]
Class C - New-set-ups
Value 3
Feature FRS 101808
IkeRetryTime – This parameter specifies the interval to retransmit an INFORMATIONAL message

that has not yet been acknowledged. Then the interval for the next retransmissions increases
exponentially and is controlled by the “ikeRetryBase” parameter. There is no limitation of the
maximum delay.
Parameter IkeRetryTime
Range & Unit [100 – 20000 ]
Value 1300
Feature FRS 101808
ikeSALifeDurationSec - The lifetime indicates the amount of time is left before the Security
Association is re-negotiated. The units are in seconds
Parameter ikeSALifeDurationSec
Range & Unit [100 – 20000 ]
Value 28800
Feature FRS 101808
Ikev2IDType - This parameter specifies the type of identifier for IKE v2. This specifies whether the
IP addrss, Domain Name or Fully Qualified Domain Name is used. A value of (0) IP address, (1)
DN Domain Name or (2) FQDN Fully Qualified Domain Name.

Parameter Ikev2IDType
{0, 1, 2}
Class B - Transport-Layers
Value (0) IPaddress
Feature FRS 101808
ipsecAntiReplaywindowSize - Anti-replay provides protection against an attacker duplicating

encrypted packets by assigning a unique sequence number to each encrypted packet. (Security
association [SA] anti-replay is a security service in which the receiver can reject old or duplicate
packets to protect itself against replay attacks.) The decryptor checks off the sequence
numbers that it has seen before. The encryptor assigns sequence numbers in an increasing
order. The decryptor remembers the value X of the highest sequence number that it has already
seen. N is the window size, and the decryptor also remembers whether it has seen packets
having sequence numbers from X-N+1 through X. Any packet with the sequence number X-N is
discarded. Currently, N is set at 64, so only 64 packets can be tracked by the descriptor.
Parameter ipsecAntiReplaywindowSize
Range & Unit [0-40]
Value 32
Feature FRS 101808
ipsecKeepalivePeriod - This aids in the Dead Peer Detection (DPD). Keepalive administrative
packets are sent between IPsec Peers to determine if the IPsec tunnel is still valid. The units are
in seconds.
Parameter ipsecKeepalivePeriod
Range & Unit [0-120]
Value 10
Feature FRS 101808
ipsecPerfectForwardSecrecyOn - IPsec Perfect Forwarding Secrecy is an optional parameter

that allows the IKEv2 negotiation to perform a Diffie-Hellman exchange. The second Diffie-
Hellman exchange will negotiate a new set of encryption keys if this option is enabled. This
allows the most secure tunnel communications.

Parameter ipsecPerfectForwardSecrecyOn
True/False
Value True
Feature FRS 101808
If the ENB has Perfect Forwarding Secrecy enabled, the SeGW must also have Perfect Forwarding
Secrecy enabled. There have been issues related to rekeying when where is a mismatch in the
Perfect Forwarding Secrecy between the eNB and SeGW.
ipsecSALifeDurationbytes - The lifetime indicates the amount of bytes sent before the Security
Association is re-negotiated. The units are in bytes.
Parameter ipsecSALifeDurationbytes
Range & Unit [1- 4294967295]
Value 1620000
Feature FRS 101808
ipsecSALifeDurationSec - The lifetime indicates the amount of time is left before the Security
Association is re-negotiated. The units are in seconds.
Parameter ipsecSALifeDurationSec
Range & Unit [1- 4294967295]
Value 28800
Feature FRS 101808
strictCrlPolicy: This parameter selects the policy to be followed by the eNodeB for certificate
revocation checks.

Parameter strictCrlPolicy (Deffered)

(0,1,2)
Value NA
Feature FRS 101808
0 (no): eNB checks the received certficate for revocation when an HTTP URI is included in the
CRLDP field of the certificate and the CRL can be retrieved by eNB. If this is not the case the
revocation check is simply skipped.
1 (yes): the received certificate MUST include a CRLDP field and the CRL MUST be retrieved by
eNB otherwise the certificate is rejected.
2 (ifuri): the revocation check is simply skipped when the certificate does not include an HTTP
URI. When it includes one the CRL must be retrieved by eNB otherwise the certificate is
rejected.
Certificate Enrollment:
CertificateUpdateDate: This parameter specifies the date against which eNB checks the issuing
date of the operator-signed certificate for the operator associated with the FIRST
PlmnIdentity Object instance. The string format is YYMMDDHHMMSS (year month day hour
minutes seconds). The certificate is renewed on condition that it was issued before the
specified date. The renewal operation is performed either at the specified date or
immediately if the specified date is already passed.
Parameter CertificateUpdateDate
Object ENBEquipment/eNB/EnbTransportConfig/PerOperatorConf/CertificateEnrollment
Range & The string format is YYMMDDHHMMSS (year month day hour minutes seconds).
Unit
Value
Feature FRS 101812
cmsIPv4Address – This is the IPv4 address of the CA that is directly above the eNB in the CMS
architecture. If this is model 1 architecture, then the IP address would be the Sub CA.
Parameter cmsIPv4Address
Range & IPv4 address
Unit
Class C - Immediate-propagation
Value N.A.
Feature FRS 101812

cmsIPv4Address2 – This is the IPv4 address of the CA that is directly above the eNB in the CMS
Parameter cmsIPv4Address2
Unit
Value N.A.
Feature FRS 159440
Unit
Value N.A.
Feature FRS 159440
Parameter cmsIPv6Address
Unit
Value N.A.
Feature FRS 101812

Unit
Value N.A.
Feature FRS 159440
Unit
Value N.A.
Feature FRS 159440
ENBcaName – This is the name of the Trust Anchor. This allows the eNB to perform path
validation.
Parameter ENBcaName
Range & [0-40] Character String
Unit
Value NULL
Feature FRS 101812
ENBcaName2 – This is the name of the Trust Anchor. This allows the eNB to perform path
validation.
Parameter ENBcaName2
Unit
Value NULL
Feature FRS 159440

ENBcaName3 – This is the name of the Trust Anchor. This allows the eNB to perform path
validation.
Parameter ENBcaName3
Unit
Value NULL
Feature FRS 159440
eNBcmsPreSharedSecret– This parameter registers the Pre-shared secret key to be used for
authenticating CMPv2 messages at eNB-CMS interface if the eNB does not own any certificate yet.
Parameter eNBcmsPreSharedSecret
Unit
Value NULL
Feature FRS 101812
Httpportcmpv2 – This is the same port value configured on the CMS CA that accepts http
protocols.
Parameter Httpportcmpv2
Range & [49152- 65535]
Unit
Value 80
Feature FRS 101812
HttpURLcmpv2 – This is the URL the eNB is required to send to the CA. This value can be
derived from the CMS CA when configuring the CMS HTTP directory.

Parameter HttpURLcmpv2
Unit
Value N.A.
Feature FRS 101812
Rule: <Engineering> <eNB> <CMS>(<HttpURLcmpv2>)
Note: It has been noticed that the entry for the parameter HttpURLcmpv2 with a full name
HttpURLcmpv2=”https://IPaddress:port_number/cmsdir “ will produce a CMP request from the eNB
towards the CMS server with an extra “/” inserted between the port_number and cmsdir. The
actual request will be =”https://IPaddress:port_number//cmsdir .
No adverse behaviour had been observed when the Full name had been used with the
HttpURLcmpv2 parameter.
If the user requires the enb to send the CMP request with one “/”, the HttpURLcmpv2 parameter
should be set to the directory path only. HttpURLcmpv2=”cmsdir “
6.10.1.6 NON Plug-N-Play IPsec Configurations.
IPsec tunnel configuration vary dependant on the VLAN configuration and IP interface configuration
for the OAM and Telecom interface. Each category below represents a supported single and multi
operator configurations.
The OAM (IPv6) and Telecom (IPv4) configuration is not supported
The inner and outer IPsec tunnel address must be of the same type (i.e. both IPv4 or IPv6).
Each row with yellow or green background contains one of the basis VLANs traffic mix. Each row
number represents a VLAN configuration.
When there are several lines in a yellow or green row, each line corresponds to an IP address. The
list of types of traffic mapped to the IP address is listed in the line (e.g. for VLAN combination # 4
there are two lines in green. The traffic S1u/X2u of the first line is mapped to an IP address and the
traffic S1c/X2c of the second line is mapped to another IP address).
# in first column is the VLAN traffic mix. E.g. #13 refers to a VLAN with 3 IP addresses: one IP
address for Oam, one IP address for S1u/S1c/X2u/X2c and one IP address for 1588.

A column below “VLAN configuration reference” identifies a possible association of VLANs that is
defined by the set of grey areas in this column. “4” (respectively “6”) in a column represent an eNB
IP address; “4” means it is an IPv4 address; “6” means it is an IPv6 address.
E.g. the VLAN configuration 7 has 2 VLANs configured as follow:

One VLAN (# 2) with one IPv4 address for OAM
One VLAN (# 3) with one IPv4 address for S1u/S1c/X2u/X2c
Ipsec Policy (eNBIPsecpolicy):

For VLAN topologies 7,8 and 9 the operator will be able to select three independent IPsec policies:
one for OAM, one for S1-C plus X2-C control plane traffic and one for the user plane S1-U plus X2-U
traffic. This exception is represented in the following tables as either “4º” or “6º”.
For all other VLAN topologies supporting IPsec, the operator is able to select one independent IPsec
policy per inner address.
The eNodeB IPsec policy for the 1588 traffic type shall be “No IPsec” for any IPsec configuration
supported.
6.10.1.6.1 Single Operator Configuration
The table below represents the single operator configuration.
The VLAN configuration designated with the symbol “ ⁿ” are new in this release. In the tables below,
VLAN 24ⁿ is new in this release.

VLAN Mapping traffic to IP@ VLANs configuration reference

# 1 2 3 4 5 6 7 8 9 10
1 1588
2 Oam 4 6 4
3 S1u+S1c+X2u+X2c 4 4º 6º 6º 6
4 S1u+X2u (Telecom UP)
S1c+X2c (Telecom CP)
6 S1c+X2c (Telecom CP)
7 S1u+S1c (Telecom S1)
8 X2u+X2c (Telecom X2)
9 Oam 4 4
1588 4 4
10 OAM 4 6
S1u+S1c+X2u+X2c 4 6
11 Oam+S1u+S1c+X2u+X2c 4
1588 4
13 Oam 4
S1u+S1c+X2u+X2c 4
1588 4
14 S1u+S1c+X2u
15 M1
16 S1u+X2u+X2c
17 S1u
18 X2u
19 S1c
Support IPsec with PSK Y Y Y Y Y Y Y Y Y Y
Support IPsec with certificates N Y N Y N N Y Y Y N
Table 52: IPsec Configurations for Single Operator (1)

# 41 42 43 44 45 46 26 27
ⁿ ⁿ
1 1588 4 4 6
2 Oam 4 6 4 4 4 6
3 S1u+S1c+X2u+X2c 4 6


5 S1u+X2u (Telecom UP) 4
6 S1c+X2c (Telecom CP) 4
7 S1u+S1c (Telecom S1) 4 6 6 4 6
8 X2u+X2c (Telecom X2) 4 6 6 4 6
9 Oam 4 4
1588 4 4
10 OAM
S1u+S1c+X2u+X2c
11 Oam+S1u+S1c+X2u+X2c
1588
13 Oam
S1u+S1c+X2u+X2c
1588
14 S1u+S1c+X2u
15 M1
16 S1u+X2u+X2c
17 S1u
18 X2u
19 S1c
Support IPsec with PSK Y Y Y Y Y Y Y Y
Support IPsec with certificates N N N N N N N N

# 16 17 18 19 20 21 22 23 24 25
ⁿ ⁿ ⁿ ⁿ ⁿ ⁿ ⁿ ⁿ ⁿ ⁿ
1 1588 4 6
2 Oam 4 4 6 6 4 4 6 6 4 6
3 S1u+S1c+X2u+X2c
4 S1u+X2u (Telecom UP) 4 6
S1c+X2c (Telecom CP) 4 6
5 S1u+X2u (Telecom UP) 4 6 4 6
6 S1c+X2c (Telecom CP) 4 6 4 6
7 S1u+S1c (Telecom S1) 4 6 4 6
8 X2u+X2c (Telecom X2) 4 6 4 6
9 Oam

1588
10 OAM
S1u+S1c+X2u+X2c
1588
13 Oam
S1u+S1c+X2u+X2c
1588
14 S1u+S1c+X2u
15 M1
16 S1u+X2u+X2c
17 S1u
18 X2u
19 S1c
Support IPsec with PSK Y Y Y Y Y Y Y Y Y Y
Support IPsec with certificates Y N N Y N N N N N N
The following diagram depicts the graphical representation of row 1 from Table 52. Both OAM and
Telecom traffic have a common IPv4 address (Black dot). The 1588 traffic use a separate IPv4
address (green dot). Both traffic types OAM and Telecom have been assigned to IPsec Tunnel T1
(Lime green Line). The diagram shows the OAM (Red line) and Telecom (Violet Line) with in the T1
tunnel. The IPsec Tunnel is associated with the VLAN V1 (Blue Line), therefore the Tunnel T1 is
within the VLAN V1. The 1588 traffic (Black Line) is in bypass mode and therefore does not traverse
within the IPsec Tunnel T1.

Figure 84: Graphical Representation of Table 49 VLAN configuration 1
6.10.1.6.2 Multiple Operator eNodeB Supported Configurations


# 12 13 14 15
1 1588
2 Oam 4 4 6
3 S1u+S1c+X2u+X2c 4 4 6 6
m m m m
6 S1c+X2c (Telecom CP)
7 S1u+S1c (Telecom S1)
8 X2u+X2c (Telecom X2)
9 Oam 4
1588 4
10 OAM
S1u+S1c+X2u+X2c
1588
13 Oam
S1u+S1c+X2u+X2c
1588
14 S1u+S1c+X2u 4 4 6 6
n1 n1 n1 n1
15 M1
16 S1u+X2u+X2c
17 S1u
18 X2u
19 S1c
Support IPsec with PSK Y Y Y Y
Support IPsec with certificates N Y N N
Table 55: IPsec Configurations for Multiple Operators (1)
6.10.1.7 Multiple Operator Considerations
Engineering: <eNodeB> <IPsec> <eUTRAN Sharing>
1. OAM VLAN controlled by the Master operator only.

2. All X2-C traffic will part of the Master Operator Telecom VLAN.
3. Master Operator manages the IPsec configuration for all operators.
a. The Pre-shared Keys for each operator’s IPsec tunnel will have to be given to the
master operator in order to push the keys to the eNodeB.
b. Each operator IPsec configuration parameters must be transmitted to the Master
operator for proper IPsec configuration.
6.10.1.8 ALU 7750 Interoperability with the eNodeb
The following rules apply to the ALU 7750 SR OS version 8.0R5.
Engineering: <Network> <IPsec> (<Topology>)
7750 8.0R5 Implementation will not support IPsec IKEv2 over IPv6. The 8.0R5 Implementation will
only support IPsec IKEv2 over IPv4.
Note: ALU 7750 8.0R5 only supports Static IP assignment (Does not support DHCP) for eNodeB.
The 7750 can NOT provide traffic policy on a protocol level. The 7750 can only provide traffic
policy on an IPaddress or IPaddress range.
The 7750 can NOT support Bypass traffic policy within the IPsec tunnel. The 7750 can only provide
traffic policy Integrity Protection or Integrity Protection with Encryption.
6.10.1.9 Fortinet Security Gateway Interoperability with the eNodeB
Based on the Fortinet specifications, there are no are no restrictions on the eNodeb and Fortinet
configurations.
6.10.1.10 QOS
The DSCP value found in inner header of IPSEC-ed traffic is copied to the outer IPSEC tunnel header,
so this traffic can be shaped.
The VLAN priority will follow recommendations specified in section 0 VLAN Ethernet QOS.

The following rule only applies to the eUTRAN shaing model.
Engineering: <eNodeB> <IPsec> <eUTRAN Sharing>
1. The DSCP of the user plane inner packets shall be configurable per operator.
6.10.1.11 MTU
Engineering: <eNodeB> <IPsec> <MTU>
1. It is best to calculate MTU frame size with consideration for all over to avoid IPsec packet
fragmentation..
6.10.1.12 Recommendations
The outer IPsec address is set to a different value than the Inner IPsec address.
IPsec tunnels pose an interesting problem for debugging communications outages. Interrupted
communications could be a result of either a network component (i.e router issue) or the IPsec
tunnel failure. In order to distinguish one failure from another, an ICMP message is usually sent
to/from the interface in question. If all ICMP messages are sent within the tunnel, then we could
not distinguish a network failure from and IPsec failure. We must have the capability to send ICMP
messages inside and outside the tunnel. When the outer IPsec tunnel address is identical to the
inner IPsec tunnel address, the eNodeB can not distinguish whether to send the ICMP messages to
inside or outside the tunnel and decides to send the ICMP messages inside the tunnel.
Perfect Forwarding Secrecy should be enabled.
The Perfect Forwarding Secrecy is option in the phase 2 stage of the IKE negotiation to perform
another Diffie-Hellman key exchange. This increase the security of the IPsec tunnel since the first
key exchange was performed in a clear context. The phase 2 IKE exchange messages are
sent/received encrypted packets.
6.10.1.13 Scenarios And Examples
As an example we will take the case where the eNodeB is connected to a core 7750 router. The
eNodeB has an OAM and Telecom IPv4 address that are unique. A corresponding VLAN will be
configured for each (OAM, Telecom) domain. For convenience, Table 41 is reproduced with valid
configurations based on the eNodeB and ALU 7750 SR SEG interoperability. Refer to the Security
Gateway section for an explanation of ALU 7750 IPsec implementation.

Vlan Configuration Supported IPsec Configurations
OAM Telecom 1588 Telecom

ROW
IPv4-1 IPv4-2 Configured 1588 OAM
/mask /mask S1-C X2-C S1-U X2-U
2 V1 V2 Yes Bypass T1
3 V1 V2 No NA T1
7 V1 V2 Yes Bypass T1
8 V1 V2 No NA T1
12 V1 V2 No NA T1
16 V1 V2 Yes Bypass T1 T2
17 V1 V2 No NA T1 T2
19 V1 V2 No NA T1 T2
Depending on the security objectives, a particular configuration can be chosen. Assuming that
neither the OAM nor the Telecom traffic is trusted, we are limited to options 16 and 17. If the 1588
interface is provisioned, then we are left with option 16.
The following parameters should be set in order to provision the system to option 16.
ipsecPerfectForwardSecrecy = enabled
ipsecAntiReplaywindowSize = 32
ikeSALifeDurationSec = 28800 (20 days)
ipsecSALifeDurationbytes = 162000
ipsecKeepalivePeriod = 10
ikeAuthMethod = PreSharedKeys
For Tunnel 1 setup:
eNBIPsecpolicy = 2 (assuming we want to encrypt the packet)

ipv4AddressEnbIPsecTunnel = 192.100.101.2 (This example, no intermediate router, eNodeB
connected to SEG).
ipv4AddressSegIPsecTunnel = 192.100.101.1
ipv4SubNetMaskEnbIPsecTunnel = 255.255.255.252 (i.e /30)
ipv6AddressEnbIPsecTunnel = Not Applicable
ipv6AddressSegIPsecTunnel = Not Applicable
ipv6RoutingPrefixLengthEnbIPsecTunnel = Not Applicable
ipv6AddressFirstHopRouter = Not Applicable
vlanId = 20 (This is the VLAN id of an existing VLAN configuration on the eNodeB).
For Tunnel 2 setup:
eNBIPsecpolicy = 2 (assuming we want to encrypt the packet)

ipv4AddressEnbIPsecTunnel = 192.100.102.2
ipv4AddressSegIPsecTunnel = 192.100.102.1
ipv4SubNetMaskEnbIPsecTunnel = 255.255.255.252 (i.e /30)
ipv6AddressEnbIPsecTunnel = Not Applicable
ipv6AddressSegIPsecTunnel = Not Applicable
ipv6RoutingPrefixLengthEnbIPsecTunnel = Not Applicable
ipv6AddressFirstHopRouter = Not Applicable
vlanId = 40 (This is the VLAN id of an existing VLAN configuration on the eNodeB).

6.10.1.14 Considerations
IPsec will add additional bytes to the original transmitted packet. The overhead will depend on
IPsec mode (Transport/Tunnel) and encryption method. The following table displays the various
combinations of an IPv4 1500 byte transmitted packet size after IPsec encryption. The table below
only displays the ESP / Tunnel mode since LTE limits the IPsec configuration.
Security Authentication Method Encryption Methods

Packet Size
Protocol MD5 SHA-1 DES 3DES SEAL AES(128)
ESP Tunnel * * 1552
* * 1552
* * 1554
* * 1560
* * 1552
* * 1552
* * 1544
* * 1560
Table 56: IPsec Overhead example based on Encryption
The table below represents the worse case overhead calculation for using either 3DES or AES (types)
encryption schemes.
Figure 85: Worse Case IPsec Overhead Calculation
There is an additional 52-73 bytes depending on the authentication and encryption Method. Twenty
of the overhead bytes are due to the IPsec outer Ethernet header. The remaining 32-53 bytes are
attributed to the ESP overhead. To avoid frequent IP packet fragmentation, the network should
accommodate the worse case overhead that IPsec imposes on the IP packet
The IPv6 overhead will be an additional 20 bytes (72 – 93 bytes overhead) above the IPv4 values to
accommodate for the length of the IPv6 addresses.

6.10.2 CMS Certificates

This section assumes the reader has prior knowledge of IPsec and CMS functionality. A Generic IPsec
and CMS Description section has been included in this document for the reader’s reference.
6.10.2.1 Dependencies and Assumptions
A Single License is required to activate the Certificate feature for the eNB. The eNB License is
dependant on an available and active IPsec License.
Engineering: <eNodeB> <CMS> (<IPsec/Certificates>)
IPsec License is required prior to activating eNodeB certificate feature.
In the case for eUTRAN a license is required for each operator associated with each eNodeB.
Operator A IPsec Operator B IPsec Software Licensing Requirements

Authentication Method Authentication Method
PSK PSK Software license not required
Digital Certificate PSK Operator A needs a license for certificates
per eNB
PSK Digital Certificate Operator B needs a license for certificates
per eNB
Digital Certificate Digital Certificate Operator A needs a license for certificates
per eNB and Operator B needs a license for
certificates per eNB
6.10.2.2 CMS MIM
The CMS MIM diagram is part of the IPsec MIM description; please refer to Figure 83: IPsec / CMS
MIM. A description were provided in the IPsec section, but duplicated here for ease of search and
comprehension.
ActivationService:
isCertificateEnabled: - Certificate Activation. This is a logical parameter to enable CMS

certificates in the eNB.
Certificate Enrollment:
This parameter specifies the date against which eNB checks the issuing date of the
operator-signed certificate for the operator associated with the FIRST PlmnIdentity
Object instance. The string format is YYMMDDHHMMSS (year month day hour minutes
seconds). The certificate is renewed on condition that it was issued before the specified
date. The renewal operation is performed either at the specified date or immediately if
the specified date is already passed.

ENBvaName – This is the name of the Trust Anchor. This allows the eNB to perform path
validation.
Httpportcmpv2 – This is the same port value configured on the CMS CA that accepts http
protocols.
HttpURLcmpv2 – This is the URL the eNB is required to send to the CA. This value can be
derived from the CMS CA when configuring the CMS HTTP directory.
Spare10 (bit 1) – Future Use.
6.10.2.3 CMS eNB Configurations
The CMS certificates are associated with the IPsec IKE negotiation; therefore the CMS eNB
configurations are included with the IPsec configuration chart. Please refer to section 6.10.1.6.1
Single Operator Configuration and section 6.10.1.6.2 Multiple Operator eNodeB Supported
Configurations for CMS IPsec configurations. The second to the last row of each table has a row
indicating the CMS support. If the entry is “Yes” then CMS is supported in that VLAN-IPsec
Configuration. This is also true for the PSK Row, where PSK represents the Pre-Shared Key method
for IPsec IKE authentication.
6.10.2.4 CMS eNB Implementation
• Operator certificates are supported for both OAM and Telecom tunnels.
• Certificate Revocation List (CRL) is not supported in this release of the eNB.
In LA5.0 IPsec authentication can be performed using Certificates or Pre Shared Keys. The eNB
provisioning parameters were provided in the MIM section. The following table provide a view of the
information set required to support the different variations of the PSK, CMS with factory certificates
or CMS without factory certificates. Factory Certificates will be supported in the future.
Nb CMS IP address, eNB IPsec for IPsec for IPsec for eNB action
CA name (MIM) credentials OAM (MIM) Telecom Telecom
(Master) (Non Master)
(eUTRAN
Sharing)
1 Provisioned No preloaded 1) Ipsec IPsecAuthMethod IPsecAuthMethod 1) Certificate
factory enabled = Certificates, = PSK or enrollment
certificate IPsecAuthMethod Certificates with Master
2) PSK is the same for operator CMS
Enabled OAM and (PSK for CMPv2
with telecom. authentication.
certificates 2) IPsec tunnel
setup using the
Master
operator-
signed

certificate for
IKEv2
authentication.
3) If
IPsecAuthMeth
od =
Certificates,
The Non Master
telecom will
perform
certificate
enrollment
with the non
master
operator CMS.
4) If
IPsecAuthMeth
od = PSK, The
Non Master
telecom will
perform IKEv2
authentication
with the
configured
IPsec PSK.
2 n.a. PSK shared 1) Ipsec IPsecAuthMethod IPsecAuthMethod 1) Master
Keys with enabled = PSK, = PSK or operator IPsec
SeGW (No IPsecAuthMethod Certificates. tunnel setup
CMS) 2)Enabled is the same for using the IPsec
(LA3.0 with PSK OAM and PSK for IKEv2
Feature) (No telecom. authentication.
Certificate 2) If
s) IPsecAuthMeth
od =
Certificates,
The Non Master
telecom will
perform
certificate
enrollment
with the non
master
operator CMS.
3) If
IPsecAuthMeth
od = PSK, The
Non Master
telecom will
perform IKEv2
authentication
with the
configured
IPsec PSK.

• The configuration of the CMS IP address is an indicator to the eNB to perform CMS
certificate requisition.
Certificate enrolment is performed on the field for eNBs (eCCM-U controller card or sBBU). An eNB
receives an Operator-signed certificate (as opposed to an ALU-signed certificate provisioned in the
factory).The associated eNB parameters are in the eNB MIM under SAM control (e.g. SAM provisions
the Operator CMS IP address to eNB and IPsecAuthMethod = certificates).CMS server does not
initiate exchanges with eNBs (it works in server mode). Initial certificate enrolment is performed at
eNB startup after the initial connection with SAM has been established (SAM has to provision the
CMS IP address).
For a new deployment of a CMS system, the following sequence is required.
1) Install and configure the CMS server. The CMS server can operate in Root CA and/or Sub CMS
mode.
a) Generate Root CA certificate
b) Generate Sub CA certificate
2) On the Security Gateway, generate a certificate request in PKCS #10 format.
a) Copy the PKCS #10 certificate request to andexternal media (i.e. USB)
3) On the CMS server, import the PKCS#10 messages and generate a signed SUB CA certificate. The
format for the signed certificate should be PKCS#7. Export the signed SUB CA signed certificate
and Root CA signed CA certificate to an external media (i.e. USB).
4) On the SEG, Import the SUB CA and Root CA certificate.
5) On the SAM, Provision the eNB CMS Parameters.
a) CMS IP address, CA Name, ENBcmsPreSharedKey, CMSUpdateDate, httpportCmpv2 (Value
will depend on the CMS server configuration), HttpUrlCmpv2 (Value will depend on the CMS
server configuration).
b) Set Authentication method to certificates.
The following is an example of an eNB transaction based on the entry 1 from the above table.
The 1B configuration is a single operator eNB with separate VLANs for OAM and telecom. There are
no factory certificates loaded into the eNB. The operator will have to configure the eNB parameters
described in the CMS system configuration:
c) CMS IP address, CA Name, ENBcmsPreSharedKey, CMSUpdateDate, httpportCmpv2 (Value

will depend on the CMS server configuration), HttpUrlCmpv2 (Value will depend on the CMS
server configuration).
d) Set Authentication method to certificates.
The eNB will check for an existing public/private key pair. If public/private key pair does not exist,
then the eNB will generate a new key pair. If Certificates are enabled, the eNB will check if an
existing and non expired certificate is available for the key pair. In the case of and expired or non
existent certificate, the eNB will initiate a CMPv2 certificate request towards the CMS server. As
described in the general section of CMS theory, the CMS server will communicate with the eNB by
sending the required certificates to the eNB in order for the eNB to validate the the certificates to
the trusted anchor. If security is of concern, the operator can configure the eNB
“ENBcmsPreSharedKey” parameter in order to secure the CMPv2 communications between the eNB
and the CMS server. An equivalent Pre-shared Key for CMP communications must be provisioned on
the CMS server to allow bidirectional secure communications. Once the eNB receives the certificates
from the CMS server, the eNB will validate the the certicates. The eNB will now have the eNB
certificate signed by the Root CA or Sub CA depending on the architecture. The certificate is used in
the IKE negotiations to authenticate the IPsec peers.

The eNB will initiate the IPsec IKE negotiations. The diagram below shows the IPsec IKE phase 1
negotiations. This is the same diagram Figure 32: IKEv2 Phase 1 Negotiation taken from the general
IPsec theory section.
As seen in message 2, an optional CERTREQ can be sent from the SEG to the eNB requesting a
certificate. Message 3 and Message 4 are part of the IKE authentication phase. The eNB in message 3
will respond with the digital certificates to the SEG. Message 4 the SEG will send its digital
certificates to the eNB. Both the eNB and the SEG will validate the received certificates prior to
progressing to the IPsec Phase 2 negotiations.
When using ceritificates for authentication the IKEv2 ID Payload type used by eNB could be
e.g. an IP address (IPv4 or IPv6), a FQDN or a “Distinguished Name”.
• For release 13.1 IP address will not be supported Only the FQDN and DN will be
used.
6.10.2.4.1 eNB Factory Certificate Implementation
The factory certificate capability allows the eNB to setup the IPsec tunnels on the OAM without
further CMS communications in the field. The eNB will have an Alcatel-Lucent certificate loaded at
the factory prior to shipment to the customer site. The preloaded certificate (Factory Certificate) is
an eNB certificate signed by the Factory CMS server. When the eNB is installed in the field, the eNB
with the loaded factory certificate will perform IPsec negotiations with the SGW since it has a pre-
configured certificate.
The following diagram depicts the Factory certificate architecture.
ALU’s
Root CMS
Secure central location
manual operations in
PKCS format
(e.g. PKCS#10 &
PKCS#7)
ALU’s ALU’s ALU’s ALU’s

Sub-CMS Sub-CMS Sub-CMS Sub-CMS
1 2a 2m n
CMPv2 CMPv2 CMPv2

over HTTP over HTTP over HTTP
eNB eNB eNB eNB

Cntrl Cntrl Cntrl Cntrl
Factory 1 F actory 2 Factory n
Figure 86: Factory Certificate Architecture
This feature assumes that that a CMS server or Sub CMS server is locally co-resident with the eNB.
The eNB are not required to have CMS pre-shared key setting since the SUB CMS server is local and
therefore trusted. The Root CMS can transfer the Sub CMS certificate via a manual process. This is a

less frequent process and therefore a manual procedure is sufficient. The SUB CMS provides the eNB
with a factory certificate via the CMPv2 protocol.
Engineering: <eNodeB> <CMS> (<IPsec/Certificates/Factory>)
• The Factory CMS server is assumed to be collocated in a secure facility.

• CMS IPsec parameter is not required in the factory scenario, since it is assumed that CMS
server is physically in a secure location near the eNB.
• The Factory certificate is only valid for the OAM tunnel. Telecom tunnels require operator
certificates.
• For the master operator, The OAM and Telecom tunnel use the same certificate. Based on
the restriction that the telecom tunnel requires an operator certificate, the master
operator will have to provide an operator certificate to the factory loaded eNB if they want
to use certificates as an authentication method.
The eNB will download the eNB Certifacte and, sub CMS certificate and the self signed root
certificate. This allows the eNB to be deployed in the field and not perform a CMS certificate
request. The eNB can be atuthencticated by the factory certificate in the field.
The eNB in the factory will have the atuthentication method configured to “certificates”. The CMS
ip address configured with the address of the factory CMS server.
The eNB will have an operatorfactory CMS server IP address and CA name provisioned when
performing factory certificate.
The eNB when provisioned with the authentication method of “certificate”, the eNB will check for a
vendor certificate. If the vendor certificate is not available, the eNB will check for the factory
certificate. If there are no certificates provisioned and the CMS parameters are also not configured,
the eNB will perform a factory certificate initiation.
Nb CMS IP address, eNB IPsec for IPsec for eNB action

CA name (MIM) credentials OAM (MIM) Telecom
(Master)
1 Provisioned No preloaded 1) Ipsec IPsecAuthMethod 1) Factory
Factor factory enabled = Certificates, Certificate
y certificate or IPsecAuthMethod enrollment
Certifi Vendor 2) is the same for 2) When the
cate Certificates IPsecAuthM OAM and eNB is
enroll ethod = telecom. deployed in the
ment Certificate field, the eNB
s will establish
an IPsec tunnel
with the
factory
certificate.
2 CMS server ip Preloaded 1) Ipsec IPsecAuthMethod 1) Factory

Factor address Factory enabled = Certificates, Certificates
y provisioned at Certificate, IPsecAuthMethod installed in the
Certifi factory, Vendor No vendor 2) is the same for factory.
cate CMS Povsioned certificate IPsecAuthM OAM and 2) eNB
enroll after Factory ethod = telecom. deployed in the
ment, certificates Certificate field and
Later were installed. s configured

Vendo with CMS

r IPaddr and
certifi CAname.
cate 3) eNB will
enroll acquire Vendor
ment certificates.
3 No Provisioned No Factory or 1) Ipsec IPsecAuthMethod 1) eNB acquires
Factor Vendor enabled = Certificates, Vendor
y Certificates IPsecAuthMethod certificates
Certifi 2) is the same for 2) eNB will
cates, IPsecAuthM OAM and establish IPsec
Vendo ethod = telecom. tunnel with
r Certificate using
certifi s certificates to
cates authenticate
only the peers.
Vendor Certificates can be used instead of the factory certificates. The vendor certificates can be
acquired after the eNB has been installed in the field with the pre-loaded factory certificates. The
CMS IPaddress configuration and the CAname wil cause the eNB to initiate a CMS request for a
vendor certificate. The vendor certificate will have precedence and will be used once acquired.
6.10.2.5 Security Gateway Implementation
The SEG shall be able to configure IPsec tunnels with the eNB using X.509v3 digital certificates for
IKEv2 authentication for the following IPsec configurations:
1. IKEv2 authentication
2. IPv4 IPsec traffic
3. IPv6 IPsec traffic
4. certificate chain delegation models supported in the CMS application of up to four levels of
hierarchy
5. Simplex mode without SEG redundancy
6. High Availability redundant system of active/standby configuration of SEGs
The redundant SEG can consist of a set of two aplpliances running in HA mode, or a set of redundant
security gateways running in the same chassis (intra-chassis redundancy) or in separate chassis
(inter-chassis redundancy).
6.10.2.5.1 Fortinet Gateway Implementation
Certificate support is available in release FortiOS 4.0 MR3 Patch7.
Refer to the 9981 CMS LA5 (Architecture and Provisioning) documentation for examples of Fortinet
configurations to support CMS.
6.10.2.5.2 CRL (159440)
For SeGW that support CRL capabilitites, the CMS server will now provide CRLDP Field as part of the
SeGW Certificate. The SeGW can be loaded with CRL lists via
• Manual installation.
• Manully configured with the URL of the CRL File.
• Receives the URL and port information from the CRLDP Field within the SeGW certificates.

6.10.2.5.3 CMS Server Implementation
The CMS server is a software component on a HW server. Recommended Hardware server

configuration is:
Redundant server configuration:
X86 Proliant HP. (Configuration 32, ref 1AF41015AAAA in ALU portfolio).

• DL360 G7
• 2 Xeon quad-core E5620 2.4GHz,
• 8GB RAM : 2 x 4 GB DDR-3 registered memory module,
• 2 x 146 GB-10Krpm 2.5" dual-port 6Gbps SAS-2 hotplug disk drive,
• 2 x 460W AC Power Supply
• 512MB BBW cache for Smart Array P410i
2 Ethernet boards
USB port
DVD drive
A is HSM card highly recommended. Thales nShield Solo version nShield 500e F3 for PCI
Express interface with ncipher Security World for Key backup and recovery
Linux CentOS 6.0.
The CMS server hardware has an option for a High Security Module (HSM). This module is meant for
the storage of RSA keys in an encrypted format. It is not mandatory but highly recommended.
Otherwise the software will store the RSA keys in the local hardrive.
The CMS server can be configured as a Root or Sub CA depending on the Architectural model that is
deployed. The CMS server is structured to support the eNB as a server. The CMS server will never
initiate Certificate requests.
For the example of an existing eNB in the field, eNB will not have a factory certificate. In this case
the CSM pre-shared keys is used to secure CMPv2 communications between the eNB and the CMS
server.
This is a sample configuration required to support and existing eNB in the field and the CMS server
acts as the Root CA.
Step 1:
CA Creation: This creates the Certificate Authority and identifies the the CA as a Root CA.
Associated with the configuration are the hash algorithms, Domain name, lease times, and factory
configuration. The example below represents a Root CA, non factory (operator) configuration with
the associated CA parameters of lease time and hash algorithms.
Step 2:
Set Shared Secret for an eNB. As this is a field deployed eNB example and do not contain a factory
Certificate.
o CAname - CA name

o ENBName - eNB name
o SerialNum- eNB serial number.

o SenderKID - sender key ID.
o SharedSecret - shared secret value.
o Format: text.
o SharedSecretFile – full path to file containing shared secret value.
o Default– When this parameter is specified, shared secret will be added as default.
Step 3:
Self-signed certificate generation: This required since this is the Root CA. The Root CA must Create
a self signed certificate that is provided to
o CAname - CA name
o NotBefore - duration before validity of the certificate
o NotAfter - duration of the certificate validity
o Certificate - full path to file where the certificate is to be written.
Step 4
Generating and signing the certificate for a security gateway. The SEG will require a Certificate.
This certificate can be manually transferred to the SEG.
Step 5:
This configures the CMS server information that is required for eNB interoperability. This will
include The Port and IP address configuration to accept CMPv2 requests.
o WebSrvAddr - New server address of the server on which the message is accepted. The
host name or IP address can be used. Several IP addresses can be specified. These
addresses must be used by this machine.
Note: If host name is used as server address then only IPs, wich were successfully
resolved for this host name, will be used (see /etc/hosts file).
o WebSrvPort - port of the server on which the message is accepted.
o CmpURN - CMP location in the server configuration. It's part of address in requested URI
of CMP reqest. For example URI for location "cmp":
http://192.168.5.10/cmp
o WorkerProcNum - Worker process number.

o NtpSrvList – List of Ntp servers.
o NtpTimeAlignPeriod – period of forced time alignment to the NTP servers.

o EnbAnswerTimeout - the timeout for awaiting a CMPv2 answer from eNB.
o CmsSessionTimeout - CMS GUI or CLI session timeout. Values: positive integer values
meaning timeout in minutes from 1 to 1500 or ‘-1’ in case the timeout is not needed.
Default value is 15. In order changes for your working shell (bash) can take effect, you
need to login/logout.
o LoginBanner – login banner. It contains the text which is showed before login to cms-
clitool and before login to server.
o PasswdValidity - CMS user password validity period. This parameter isn’t implemented.
o QosPriority – the value to be assigned to the priority field in the Ethernet header. This
parameter isn’t implemented.
o QosDSCP – the value to be assigned to the DSCP field in the IP header.

o sftpServerIP – SFTP server destination IP address.
o sftpServerPort – SFTP server destination port.

Values: a positive integer up to 65535. Default value is 22.
o sftpUser – SFTP user name.
Values: string without space symbols.
o sftpPasswd – SFTP password.

o sftpPath – Directory path to store the PM files on the SFTP server.

Format: directory path.
o snmpNotifIP – SNMP server IP address.
Format: IPv4 or IPv6.
o snmpNotifPort – SNMP server port.

Values: a positive integer up to 65535. Default value is 162.
o snmpEngineId – Destination SNMP engine ID.

Values: String representing a hexadecimal notation of an SNMP engine ID. Minimum
length is 10 symbols (5 bytes).
o snmpAuthKey – Authentication key to be used for signing an SNMPv3 message.

Values: hex-string without space symbols. Minimum length is 8 symbols.
o snmpEncryptKey – Encryption key to be used for encryption of SNMPv3 message.
Values: hex-string without space symbols. Minimum length is 8 symbols.
o sftpUser – SNMP user name.

<eNBcaName>O=Alcatel Lucent, CN=OPEROOTCA</eNBcaName>
As the CMS server can operate in many modes, there are many associated commands to configure
the CMS server based on the functionality required (i.e. [Factory or operator], Root or Sub CA,). The
commands above are for a specific example. For further information about the CMS server command
set, please refer to the CMS server User Guide.

CMS server with the Certificate Authority will have the capability to include the CRLDP field within
the generated certificates. The CRLDP field will support up to 2 CRL URLs with port numbers. The
CRL URLs are pointers to CRL servers such that the SeGW/eNB can retrieve the CRL list.
Rule: <IPsec> <CMS> <Requirement>
The CRL requests from the eNB or SeGW will be on TCP port 12784 (FRS 159440 ).
The CMS Server will now support the CRLDP Field. The CRLDP field allows the insertion of the CRL
URL and port number within the certificate. This allows the certificate requesting entity to query
for the CRL. (FRS 159440 ). The CMS server will support at most 2 HTTP URLs in the CRLDP field.
6.10.3 eNB Security Plug-N-Play Implementation
The documentation is based on the information obtained prior to the release. Please refer to the
release letter to determine if any restrictions on this feature exist at the time of release.
Restriction: <eNB><IPsec>(<Plug-N-Play>)
Plug-N-Play is meant for initial deployment for eNB with automatic establishment of IPsec OA&M
Connection only. Plug-N-Play capabilitites are not available for Telecom connections.
1. Only IPv4 over IPv4 are supported.
2. No factory customization of FQDNs (SeGW/ SAM FQDNs or IP address). All information are
acquired via DHCP.
3. DNS address resolutions are not supported during the Macro PNP deployments.
4. No SeGW redirection during PNP deployments.
5. Macro eNB will default to No VLAN from the factory.
6.
The SeGW router must support the ability to perform a DHCP request to an external DHCP server
when the SeGW receives the IKEv2 CP Request message. This is a special function that doesn’t exist
in all routers. Fortinet is the certified router.
If the eNB is deployed with PNP capabilities (IpConfigAutomatic = true), it is expected that the eNB
configuration in the SAM for the eNB maintain the PNP capabilities.
The SeGW will have to support dual Trust Anchors for a single connection. This is required since the
initiail IPsec connection.will use factory certificates and operator certificates will be used after
the initial connection.
The IPsec Plug-N-Play feature allows the eNB to automatically establish an OA&M IPsec channel
without extraneous configurations. Currently the eNB will require the user to configure the IPsec

outer and Inner tunnel addresses before communications to the SASAMM can be established. With PNP,
the Outer IPsec Tunnel address can be automatically acquired by enabling the Automatic Security
Gateway Discovery capability. The IPsec PNP will enable the automatic discovery of the IPsec Inner
Tunnel address and complete thehe IPsec tunnel configuration. The ability for the node to
communicate and register with the EMS will be discussed in the Enb Self Commissioning Feature.
The remaining eNB configuration will be configured after the eNB has established communications
established
ished with the SAM. The remaining procedure will be decribed to make the example
complete. A generic Plug-n-Play
Play section will be added to the TEG to describe the capabilities Plug-
Plug
n-Play with and without IPsec.
In order for the the eNB to be installed in the field without any configuration on site (Plug
(Plug-n-Play),
additional network functionally must exist to support information transfer to the eNB.Before we
describe all the functionality required to support the Plug
Plug-N-Play
Play scenario, we will introduce a
network diagram for reference.
Figure 87: IPsec PNP Network Topology
The end to end Plug-n-Play

Play scenario will depend on specific capabilities for each component
specified in Figure 87:: IPsec PNP Network Topology
Topology.. Each component will be listed and the required
functionality specified.
6.10.3.1 IPsec Plug-N-Play Pre-Requisits

Requisits features and capabilities
The following components list the pre-requisit

pre features required to support the Plug-N
N-Play
scenario.
eNB/Metrocell pre-requisits
Alcatel-Lucent

1. Feature 101808 – Ipsec for IPv4 or IPv6

2. Feature 101812 – Certificate Management system for IPsec
a. Factory Certificates
3. Feature 160695 – Security Gateway discovery.
4. Feature L115970 – eNB self Comissioning feature. This feature is required to complete the
Plug-n-Play scenario, but not required to establish the OAM IPsec channel.
L2/3 Device Pre-requisits

1. If this device is a layer 2 device, there are no special capabilities required. The DHCP
server is behind the L2 device and can be reached directly by the eNB.
2. There are several option associated with DHCP if the device is a layer 3 device.
a. The device may have an internal DHCP server capability The Edge DHCP server will
be configure to provide the outer address of the IPsec tunnel, the EMS IP address
(including ports), and the SeGW IP address. Upon receiving a DHCP request, the
edge router will respond with the required IP addresses.
b. The Layer 3 device can act as a DHCP relay to and send a request to a DHCP server
to acquire the outer address of the IPsec tunnel, the EMS IP address (including
ports), and the SeGW IP address.
Restriction: <eNB><IPsec>(Plug-N-Play>)
The nodes DHCP client will not perform DHCP renew requests. The DHCP server should have a
permanent lease time for the Outer IPsec tunnel address.
Core Router (SeGW)

1. The Core router will be the IPsec tunnel termination point, therefore IPsec compatibility is
required.
2. The router will have the capability to support certificates.
3. The router must have the ability to insert inner tunnel IP address in the CP response
message in the IKE negotiations.
4. The router must have the capability to contact an external (network DHCP Server) to
acquire an address on behalf of the eNB/Metrocell.(DHCP relay)
Network DHCP server

1. Configure the eNB/Metrocell serial number to associate the node to an IP address.
Restriction: <eNB><IPsec>(Plug-N-Play>)
The nodes DHCP client will not perform DHCP renew requests. The Core DHCP server should have a
permanent lease time for the Inner IPsec tunnel address.
CMS
The CMS server is provisioned with the Domain information necessary to allocate certificates based
on the certificate requests organization field. The CMS server will allocate certificates to the eNB
via CMP protocol and certificates to the SeGW via a manual process. This follows the CMS
architecture and description provided in the CMS section of this document.
SAM
The SAM is provisioned with the eNB serial number in order to accommodate the 13.3 eNB
registration scheme (Feature L115970, eNB Self Commissioning). Release 13.1 eNB will initiate hello
messages to EMS IP addresses that are pre-configured on the eNB or EMS IP addresses that are

acquired when an eNB sends the hello message to the controlling SAM, the SAM will respond and
continue with the registration process. Once the eNB is registered and Managed, the SAM is used to
provision the eNB/Metrocell with the final configuration once communications to the eNB or
Metrocell is established.
6.10.3.2 IPsec Plug-N-Play Pre-Deployment configurations
The PNP components must be pre-configured to support the deployment of the eNB/Metrocell prior
to the delivery of the equipment. In order to provide a proper explaination of the functionality a
complete walk through the communications between the deployed equipment and the network
components will be discussed. An example of the communications between the eNB and the
network components are provided in this section. The example will be an IPsec tunnel configuration
for the OAM and telecom interfaces.
Factory procedures / configurations

The eNB/Metrocell will be booted in the factory to acquire the CMS factory certificates. The eNB
will be loaded with the eNB signed certificate and the self signed root certificate from the factory
CMS. The parameter RanBackhaul::ipConfigAutomatic is set to “true”. The eNB serial number is
provisioned.
Edge Device
If the edge device is a layer 2 device, then the device should be configured to accept no VLAN
OA&M traffic.
If the device is a layer 3 device, an internal DHCP server should be configured to provide the:
• outer address of the IPsec tunnel
• the EMS IP addresses and ports (Maximum of 10)
• the SeGW IP address.
The assigned IP addresses are associated with the eNB Upon receiving a DHCP request, the edge
router will respond with the appropriate IP addresses.
Core Router (SeGW)

The security Gateway must be pre-loaded with the SeGW signed certificate from the ALU factory
root CMS. The ALU factory root CMS self signed ceritificate will be loaded into the SeGW via a
manual procedure.Configured to respond to IKE CP request messages with the IP address acquired
from the core DHCP server. The Core router must be configured to acquire the IP address on behalf
of the eNB (DHCP Relay).
The SeGW have to be loaded with the SeGW certificate signed by the Core network CMS server.The
Root self signed certificate from the Core network CMS server have to be loaded as well. These
certificates are different than the ALU factory signed certificates.
Core DHCP server

A pool of addresses must be reserved for eNB associated with serial numbers of the eNB. The DHCP
server should allocate the same IP address to the same eNB.
CMS
The CMS is configured to assign certificates to the eNB.Certificates assigned to the SeGW are
performed manually.
SAM
The SAM will have the complete configuration for each eNB. This includes all the parameters a new
communications channel for the OAM if necessary. The SAM is configured with the serial numbers of
all the eNBs that the SAM will manage. The SAM has the self configuration policy set with the
following set:

o Auto Start
o SW Upgrade
o Configuration Deployment
o Administrative Enable
6.10.3.3 eNB PNP Configurations
The following configurations apply to PNP IPsec only.
number represents a VLAN configuration. The N in the VLAN number indicates a NO VLan
configuration.
there are two lines in green. The traffic Oam+S1u+S1c+X2u+X2c of the first line is mapped to an IP
address and the traffic 1588 of the second line is mapped to another IP address).
defined by the set of grey areas in this column. “4”, “6” or (respectively “6over4”) in a column
represent an eNB IP address; “4” means it is an IPv4 address; “6” means it is an IPv6 address, and
“6over4” indicates IPv6 over IPv4.
E.g. the VLAN configuration 5 has 1 VLAN configured as follow:

One VLAN (# 1) with one IPv6 over IPv4 address for OAM+ S1u+S1c+X2u+X2c
One VLAN (# 1) with one IPv4 address for 1588
VLAN Mapping traffic to IP@ PNP VLANS configuration reference

#N 1 2 3 4 5 6 7 8 9 10
inidca
tes
(no
Vlan)
N-1 Oam+S1u+S1c+X2u+X2c
1588 (No Ipsec)
1588 (No Ipsec) 4
2 Oam 4
1588 (No Ipsec) 4
3 S1u+S1c+X2u+X2c 4
Support IPsec with PSK N N N N N N N N N N
Support IPsec with certificates N Y Y N N

6.10.3.4 IPsec Plug-N-Play Walk Through with IPsec and DHCP capability
Figure 88: Plug-N-Play Flow (1),Figure 89: Plug-N-Play Flow (2),Figure 90: Plug-N-Play Flow (3)and
Figure 91: Plug-N-Play Flow (4) represents the flow of communications for Plug-N-Play. All detailed
discussions will refer to these diagrams.
Figure 88: Plug-N-Play Flow (1)
Factory Certificates Pre-loaded
The eNB will be pre-loaded with the ALU factory certificates. The eNB/metrocell will also
configured to automatic configuration. All other components will be pre-configured to support the
eNB deployment. Please refer to section 6.10.3.2 IPsec Plug-N-Play Pre-Deployment configurations.
When the eNB is first deployed in the field, the eNB will first boot and perform a DHCP request for
an outer IPsec tunnel address, SAM IP addresses and SeGW address. The edge device will allocate
the IP addresses. After acquiring the IPsec tunnel address, SAM IP addresses and SeGW address, the
eNB will initiate an IPsec tunnel connection with the SeGW. The eNB will use the factory certificates
as part of the IKEv2 authentication procedure in order to avoid additional manual provisioning.
As part of the Plug-N-Play scenario, the eNB will request the Inner IPsec address via the IKEv2
negotiation. The eNB will send a CP request as part of the IKEv2 negotiation. This will prompt the
SeGW to allocate an IP address via a DHCP request to an external core DHCP server on behalf of the
eNB. When the SeGW receives the DHCP response, the SGW will reply to the eNB with the IP address
via the IKEv2 CP response. The eNB and the SeGW will continue with the IPsec configuration.

The eNB will initiate contact with the SAM addresses that was received in the original DHCP
response from the edge DHCP server. The SAM that is responsible for managing the eNB will reply
and complete the eNB registration. After the OAM IPsec tunnel is established and the SAM is
connected to the eNB, the SAM can load the work order to complete the provisioning of the eNB.
After the eNB is configured, the eNB will have to reboot in order to substantiate the new MIM
parameters. The IpConfigAutomatic parameter should still remain set to true, therefore the eNB will
initiate another DHCP request for IP configuration. Since the startup is via a dynamic method, the
outer and inner IP address should NOT be populated in the MIM. At this point the eNB has not
contacted the operators CMS server and does not have the operator certificates. The eNB will re-
establish the IPsec tunnel using the factory certificates. The eNB will receive the same inner
address from the internal DHCP server via the IKEv2 CP response.
Engineering: <eNodeB> <IPsec><Plug-n-Play>
It is expected that the outer and inner IP addresses are left unconfigured in the SAM for the IPsec
tunnel. The outer and inner addresses are provisioned in the respective DHCP servers.

It is expected that the Factory certificates were only used for the initial OA&M connection. Future
connection to the OA&M will be via the operators CMS domain. The eNB complete the IPsec OA&M
connection. The eNB will request for new operator certificates from the core CMS.The eNB receives
the operator certificates and starts the IKEv2 negotiation with the SeGW. As part of the pre-
configured conditions, the SeGW is preloaded with the operator certificates prior to the eNB
deployment. The eNB will reboot after installing the operator certificates. A new SeGW can NOT be
configured that is different from the SeGW that established the connection for the bootup IPsec
tunnel.

The eNB completes the OA&M tunnel setup. The eNB will setup all the IPsec tunnels that are
configured by the SAM.
6.10.4 Automatic Security Gateway Discovery (ASGD)

The Plug-N-Play capability allows the node to be deployed without manual provisioning at the site.
The ASGD capability will assist the Plug-N-Play functionality for IPsec OAM communications auto
configuration by acquiring the SeGW information by an automated method (DHCP).
The ASGD capability allows the node to automatically acquire the Security Gateway information
IPaddress or Fully Qualified Domain Name (FQDN). As the FQDN suggests, a Domain Name Server
(DNS) functionality can be used to resolve the FQDN to an IPaddress. The use of a DNS to resolve the
IPadddress of the SeGW is currently not supported. Therefore the SeGW IPaddress is the only valid
SeGW information set.
The node requires the SeGW ip address for IPsec tunnel negotiation and configuration.

Restriction: <eNB><IPsec>(< Plug--N-Play/ Automatic SeGW Discovery>)
• DNS is currently not supported in the Automatic Security Gateway Discovery Feature. The SeGW
Fully Qualified Domain name (FQDN) can not be used with a DNS server to resolve
resolve the SeGW IP
address. The current implementation requires the DHCP server to respond with the IP address of
the SeGW. This only applies to Macro only.
Engineering: <eNodeB> <IPsec> (<Aatomatic

(< SeGW Discovery>)
DHCP Vendor Spcific Option 43 is required for DHCP replies containing SeGW information (i.e.
SeGW IPaddress or SeGW FQDN).
Sub Option 3 EMS FQDN
Sub Option 4 SEG FQDN
The Network topology will assume the edge DHCP server or DNS device to reside in the network as
depicted in the following diagram.
Figure 92: Automatic Security Gateway Discovery Network
The edge network device can either be a layer 2 or layer3 device.
1. If this device is a layer 2 device, there are no special capabilities required. The edge DHCP
2. There are several options associated with DHCP if the device is a layer 3 device.
Alcatel-Lucent

a. The device may have an internal DHCP server capability The Edge DHCP server will
be configure to provide the outer address of the IPsec tunnel, the EMS IP address
(including ports), and the SeGW IP address. Upon receiving a DHCP request, the
edge router will respond with the required IP addresses.
b. The Layer device can act as a DHCP relay to send a request to a DHCP server to
acquire the outer address of the IPsec tunnel, the EMS IP addresses (including
ports), and the SeGW IP address.
In the Layer 2 and layer 3 explanation above, the DHCP server return a list of EMS IPaddresses and
the IPsec outer tunnel address in addition to the SeGW address. The IPsec outer tunnel address is
required as part of the PNP capability and the EMS IP address list will be discussed further in the
eNB Slef Commisioning capability.
To enable the Automatic Security Gateway Discovery capability the parameter information are
provided below.
Parameter ipConfigAutomatic
Object ENBEquipment/eNB/EnbTransportConfig/RanBackhaul/
Range & Unit True or False
Value True
Feature 160695 and L115970
If the ipConfigAutomatic parameter is enabled, the node will perform a DHCP discovery. If this
parameter is disabled, the node will use the configuration parameters to set the OA&M link.
Parameter securityGWFqdn
Object ENBEquipment/eNB/
Range & Unit String (1-64) characters
Value N.A.
Feature 160695
This parameter specifies the fully qualified domain name (FQDN) of the Secrity Gateway to use
during the initial OA&M establishment. This parameter is used when ipConfigAutomatic is enabled
and when DNS capabilities are used without DHCP. Due to the restriction of the DNS capability this
parameter is deferred to a later release.
Parameter primaryDnsIpAddress
Value N.A.
Feature 160695

This parameter specifies the IPv4 primary domain name server (DNS) address. Due to the restriction
of the DNS capability this parameter is deferred to a later release.
Parameter primaryDnsIpAddressv6
Value N.A.
Feature 160695
This parameter specifies the IPv6 primary domain name server (DNS) address. Due to the restriction
of the DNS capability this parameter is deferred to a later release.
Parameter secondaryDnsIpAddress
Value N.A.
Feature 160695
This parameter specifies the IPv4 secondary domain name server (DNS) address. Due to the
restriction of the DNS capability this parameter is deferred to a later release.
Parameter secondaryDnsIpAddressv6
Value N.A.
Feature 160695
This parameter specifies the IPv6 secondary domain name server (DNS) address. Due to the
restriction of the DNS capability this parameter is deferred to a later release.
6.10.5 Non Transport specific Related Security Features

6.10.5.1 Security DoS Attack Protections
This feature enhances the nodes ability to protect against various security threats. The node will
limit the susceptibility to layer 2 and layer 3 external threats. All enhancements are local to the
node. The node will filter ingress traffic. The Node determines the acceptable type of ingress traffic
based on the nodes configuration.
The control and management plane connections that are initiated by the node are controlled with a
stateful firewall that uses the following packets attributes: protocol source IP@, destination IP
address, source port, destination port.

The control and management plane connections that can be initiated by remotes node (SNMP, SSH,
X2c, PTP) are controlled with additional static rules that include, when the feature is activated, the
source IP address of the known remote nodes. The node allows the user to configure additional
source IP address/subnets for SNMP, SSH and X2c traffic.
The user plane is controlled with static rules.
Filtering rules are supported with IPv4 and IPv6 and are compatible with IPsec and Non IPsec
interfaces.
This is a licensed feature on a per node basis.
6.10.5.1.1 Hardware compatibiltiy
This capability is Hardware dependant. The following HW controller boards support the capability.
1. ECCM
2. ECCM2
3. Metro
Restriction: <eNB><security>(<DOS Attack Protections>)
• This capability is not available on the Metro controller.
6.10.5.1.2 Packet Filtering Operation
When the packet filtering capability is activated, the Node will begin to inspect and discriminate
traffic against a well known list of acceptable traffic. All ingress traffic that doesn’t match the
known list of acceptable traffic will be discarded. Packet filtering can be enabled/disabled on a per
node IP address basis.
The acceptable traffic list (Known traffic) is automatically determined. The known traffic is derived
from the nodes configuration. Based on the nodes configuration (i.e MME address, EMS address,
etc....), the communications protocols and expected source and destination IP addresses are
deterministic. For each nodes activated IP interface, the filtering mechanism will determine the
source IP address for ingress traffic with the IP addresses of the remote known nodes (S1c, S1u,
NTP, CMS, etc..)
There may be circumstances that require additional communications that are unknown based on the
nodes configuration. The node has configuration parameters to allow the node to accept unknown
traffic.
Rule: <Security> < DOS Attack Protection > (<Initialization>)

When Packet filtering is enabled and there are no known EMS addresses, the node will not create
any rules based on the configuration. Instead the node Will only accept SSH client traffic from any
address. Once the EMS address is populated, the packet filtering rules will be based on
configuration.
6.10.5.1.3 Packet Filtering configuration parameters.

The following parameters allow the node to accept traffic in addition to the known traffic list.
This parameter activates or deactivates the IP Filtering feature.
Parameter isIpFilteringEnabled
Range & Unit Boolean (True or False)
Class C- Immediate-propagation
Value False
Feature 114382
This parameter enables or disables the use of IP filtering for an eNB IPaddress. This is the
destination IP address of an ingress packet.
Parameter ipFilteringActivation
Value False
Feature 114382
This parameter, defines the IPv4 source address(es) used for the filter. The destination address for
the filter will be the IPv4 address configured in the TrafficDescriptor.
Parameter ipv4Address
Object ENBEquipment/eNB/EnbTransportConfig/RanBackhaul/VLAN/TrafficDescriptor/PacketFilteringConf
Range & IPv4 Address
Unit
Value NA
Feature 114382
This parameter specifies the IPv4 subnet mask for the PacketFilteringConf instance.
Parameter ipv4SubNetMask
Unit
Value NA
Feature 114382

This parameter defines the IPv6 source address(es) used for the filter. The destination address for
the filter will be the IPv6 address configured in the TrafficDescriptor.
Parameter ipv6Address
Unit
Value NA
Feature 114382
This parameter specifies the IPv6 subnet mask for the PacketFilteringConf instance.
Parameter ipv6RoutingPrefixLength
Range & [0-128]
Unit
Value NA
Feature 114382
This the relative index to the PacketFilteringConf object instances. There can be 20 additional User
specified IP.
Parameter rdnId
Range & [0-9]
Unit
Class NA
Value NA
Feature 114382 and 168496 (increased to 20)
This parameter specifies whether, or not, the group of counters related to IpFiltering is selected to
be reported.
Parameter ipFilteringReported
Object ENBEquipment/eNB/ PerformanceManagement
Class C
Value False
Feature 114382

This parameter specifies the list of destination ports numbers that are authorized from the IP
address or subnet defined by ipv4Address/ipv4SubNetMask or ipv6Address/ipv6RoutingPrefixLength
parameters of the PacketFilteringConf instance.
Parameter dstPortNumberList
Object ENBEquipment/eNB/EnbTransportConfig/RanBackhaul/VLAN/TrafficDescrip
tor/PacketFilteringConf
Range & Unit IP address
Value N.A.
Feature 168496
6.10.5.2 Security Enhancements
This section of the document contains generic security features associated with the node. This
section will not list all the available features. Instead, we will concentrate on security ascpects that
can be controlled by the operator. Security enhancements include:
1) (LA2) The node will support Role Based Access Control (RBAC) for user and machine interfaces.
a) (14.1) Modification the root password can only performed after user has already logged in
as root.
b) (14.1) the eNB shall support 2 accounts , to differentiate ALU and operator account.
c) (14.1) the eNB shall not support weak hash algorithm for password storage, need to use
SHA-512
2) (LA2) Login banner will be provided for SSH user logins.

a) (14.1) From SAM it shall be possible for the operator to activate or deactivate the pre login
banner with the same text as the post login banner.
b) (LA2) SSH/SNMPv3:
c) (14.1) It shall be possible to change the SNMPv3 keys.
d) (14.1) The eNB is using two keys, one to authenticate and the other to cipher. Keys should
be independent, the discovering of one should not ease the discovering of the other.
e) (14.1) It shall be possible to change the password of initial_snmp – machine account used for
SAM access via SNMPv3 either per eNB or for a set of eNBs.
f) (14.1) the eNB shall not support weak algorithm for the encryption. The eNB shall use AES-
128-cbc or AES 256
g) (14.1) the eNB shall not support weak algorithm for the Integrity. The eNB shall use HMAC
SHA 96.

Interface Integrity Encryption

SSH SHA-1 (LA2) AES-128-cbc (LA2)
HMAC-SHA-96 (14.1) AES-128-ctr (14.1)
AES-256-cbc (14.1)
AES-256-ctr (14.1)
SNMPv3 SHA-1 (LA2) AES-128-cbc (LA2)
HMAC SHA 96 (14.1) AES-128-cfb (LA2)
AES-256-cbc (14.1)
SFTP SHA-1 (LA2) AES-128-cbc (LA2)
This parameter allows to request for pre-login banner display when a user wants to connect to the
eNB through the CLI/SSH.
Parameter displayPreLoginBanner
Object ENBEquipment/eNB
Value False
Feature 168496
This parameter defines the measurement period to detect that a data flow controlled by the policer
is overloaded. When a data flow is overloaded the eNB sends an alarm to the EMS. The value 0
means that the policer overload detection time is disabled.
Parameter policerOverloadDetectionTime
Object ENBEquipment/eNB/EnbTransportConf/GlobalTransportConf
Range & Unit Integer (0 – 360)
Value 15
Feature 168496
6.11 TRAFFIC MANAGEMENT

6.11.1 UL Traffic Shaping
UL traffic shaping is enabled or disabled through:
• Object: Enb/ActivationService, Parameter: isUlTrafficShapingEnabled, Value: [true, false],
Class: B, Service impact: Partial, Update transient impacts details: Transport-Layers

Engineering: <eNodeB> <UL traffic shaping>
It is recommended that Transport-CAC and UL Traffic Shaping features be both configured at eNB.
In downlink, it is assumed that shaping is activated in the backhaul.
Rule: <eNodeB> <UL traffic shaping> <Design>
When the shaper is not used, traffic does not go through the strict priority scheduler but goes to a
specific queue which size is hard coded. Hence, it is not the best way to manage traffic with
different CoS.
Engineering: <eNodeB> <UL traffic shaping>
Even if no SLA is enforced within the transport network provider, ALU recommendation is that UL
Traffic Shaping feature be nonetheless configured at eNB with following CIR setting:
• CIR = PCR = bit rate of the physical interface (whatever the shaping mode ‘per port’ or ‘per
Vlan’)
This is for taking benefit of the scheduler stage that goes with the shaper. This ensures that egress
traffic is scheduled with QoS differentiation onto the physical link.
Note: In case SLA is enforced within the transport network provider, then UL Traffic Shaping feature
must be configured with a CIR setting that complies to the SLA either at port or at Vlan granularity.
6.11.1.1 UL traffic scheduling
eNodeB supports UL traffic scheduling to ensure the QoS differentiation between high priority flows
and low priority flows.
Scheduling functionality is performed by the WinPath 2 (WP2) processing unit.
The assignement of traffic to queues depends on the traffic shaping mode;

• per port: UL traffic is classified per DSCP. A queue is assigned per DSCP flow. Several DSCP flows
can share the same queue.
• per VLAN: UL traffic is first classified per VLAN and for a VLAN it is classidied per DSCP. A queue
is assigned per DSCP flow. Several DSCP flows can share the same queue.
Traffic shaping mode of operation is configured through:
• Object: Enb/EnbTransportConf/RanBackhaul, Parameter: cacAndTrafficShapingMode, Value:
[PerPort, PerVlan], Class: B, Service impact: Partial, Update transient impacts details:
Transport-Layers

queue size, tail drop/ mapping between traffic

WRED discard, WRED type and priority queue
scheduler thresholds
attributes
dscpToPriorityMap
size, discardPolicy, otherDscpPriority
cir, cbs, eir, ebs min/maxThreshold networkControlPriority
Strict highest
priority
priority queue0 VLAN x / DSCP a
queue1
to shaped unshaped from
scheduler classifier
backhaul traffic traffic backplane
...
queueN
VLAN x / DSCP z
lowest
priority
VLAN x
N ≤ 16
Figure 93: Traffic Scheduling in WinPath 2 - Strict priority
16 traffic queues are supported, queue 0 has the highest priority while queue 15 the lowest priority.
All the incoming traffic (eRAB, SCTP, OAM, IEEE1588…) is classified based on its L3 QoS marking and
put into one of these queues on the basis of a DSCP to scheduling priority mapping table.
Each queue is scheduled on a strict priority basis. Whenever there are packets in a queue, they are
scheduled first as compared to others queues with a lower priority. Each queue also maintains the
FIFO discipline.
Rule: <eNodeB> <UL traffic scheduling> <Design>
Up to 16 scheduling queues are supported.
The eNodeB supports only scheduling with strict priority.
The strict priority scheduling ensures the QoS guarantee for all GBR (high DSCP classes) and high
priority flows, provided that at any time the sum of these flows does not exceed the CIR. Any
remaining bandwidth is allocated to the rest of the flows in a strict priority order.
The DSCP to scheduling priority mapping table is derived (built) by eNodeB from two sources;
• the provisioned traffic flows to DSCP mapping through ControlFlowToDscpMapping,
QciToDscpMappingS1 and QciToDscpMappingX2 (see IP QoS section), and
• the provisioned traffic flows to queue mapping through TransportCosConf[PerPort]/x, where
x=[0-15] is a queue number
If cacAndTrafficShapingMode is “PerVlan” then the traffic flows to queue mapping is configured

through:
• Object: Enb/EnbTransportConf/RanBackhaul/Vlan/SlaConf/TransportCosConf,

Parameter: controlFlowList, Value: [SctpS1, SctpX2, GTPuEcho, OAM, PtpEvtMsg, PtpGenMsg,

ICMP, CallTrace, IKE, DDT, M3, AGPS], Class: B, Service impact: Partial, Update transient
impacts details: Transport-Layers
The parameters ControlFlowToDscpMapping[]::controlFlow, TransportCosConf::controlFlowList,
(resp. TransportCosConfPerPort) share a common list of settable values.
But, as far as eNB UL traffic shaping is concerned, it is not useful to assign in the
TransportCosConf::controlFlowList (resp. TransportCosConfPerPort) the ‘PtpEvtMsg’ & ‘PtpGenMsg’
values as PTP traffic is neither going through queuing scheduling nor UL traffic shaping.
In case PTP traffic is nonetheless assigned to a controlFlowList parameter then this has no impact at
eNB which still by-passes PTP traffic from queuing scheduler and traffic shaper stages.
The PTP traffic is not shaped so PtpEvtMsg & PtpGenMsg flows do not go through the shaper.
Parameter: otherFlowList, Value: [Other, NetworkControl], Class: B, Service impact: Partial,

Update transient impacts details: Transport-Layers
Parameter: qciS1List, Value: [Qci1-Qci255], Class: B, Service impact: Partial, Update transient
Parameter: qciX2List, Value: [Qci1-Qci255], Class: B, Service impact: Partial, Update transient
The scheduling priority of the queue is configured through:
• Object: Enb/EnbTransportConf/RanBackhaul/Vlan/SlaConf/TransportCosConf, Parameter:
queuePriorityAndCosId, Value: [0-15] (0 is highest priority), Class: B, Service impact: Partial,
The scheduling mode of the queue is configured through:

• Object:
Enb/EnbTransportConf/RanBackhaul/Vlan/SlaConf/TransportCosConf/QueueAndSchedulerConf,
Parameter: queueSchedulerMode, Value: StrictPriority (only supported mode), Class: B, Service
impact: Partial, Update transient impacts details: Transport-Layers
If cacAndTrafficShapingMode is “PerPort” then the traffic flows to queue mapping is configured

through:
• Object:
Enb/EnbTransportConf/RanBackhaul/EthernetPort/SlaConfPerPort/TransportCosConfPerPort,
Parameter: controlFlowList, Value: [SctpS1, SctpX2, GTPuEcho, OAM, PtpEvtMsg, PtpGenMsg,
ICMP, CallTrace, IKE, DDT, M3, AGPS], Class: B, Service impact: Partial, Update transient
Parameter: otherFlowList, Value: [Other, NetworkControl], Class: B, Service impact: Partial,
Parameter: qciS1List, Value: [Qci1-Qci255], Class: B, Service impact: Partial, Update transient
Parameter: qciX2List, Value: [Qci1-Qci255], Class: B, Service impact: Partial, Update transient
Note: There is a parameter transportCosConfPerPort::dscpList that is unused in this release.
The scheduling priority of the queue is configured through:

• Object:
Enb/EnbTransportConf/RanBackhaul/EthernetPort/SlaConfPerPort/TransportCosConfPerPort,
Parameter: queuePriorityAndCosId, Value: [0-15] (0 is highest priority), Class: B, Service impact:
Partial, Update transient impacts details: Transport-Layers
The scheduling mode of the queue is configured through:

• Object:
Enb/EnbTransportConf/RanBackhaul/EthernetPort/SlaConfPerPort/TransportCosConfPerPort/Qu
eueAndSchedulerConfPerPort, Parameter: queueSchedulerMode, Value: StrictPriority (only
supported mode), Class: B, Service impact: Partial, Update transient impacts details: Transport-
Layers

eNB
ActivationService
isUlTrafficShapingEnabled = true
eNBtransportConf
RanBackhaul
cacAndTrafficShapingMode = PerVlan
Vlan[1-50]
SlaConf
TransportCosConf/[0-15]
controlFlowList = [SctpS1, SctpX2, GTPuEcho, OAM,

PtpEvtMsg, PtpGenMsg, ICMP, CallTrace, IKE, DDT, M3, AGPS]
otherFlowList = [Other, NetworkControl]
qciS1List = [Qci1-255]
qciX2List = [Qci1-255]
QueueAndSchedulerConf/0 queuePriorityAndCosId = [0-15]
queueDiscardPolicy = [TailDrop, WRED]
queueSchedulerMode = [StrictPriority]
queueSize
queueMinThreshold
queueMaxThreshold
maxDropProbability
Figure 94: UL traffic scheduling – per VLAN – Model object for configuration

Engineering: <eNodeB> <UL traffic scheduling>
Default recommendation for the traffic flows to scheduling priority mapping:
Queue Number Traffic Flows Scheduling Priority
ControlFlowList
TransportCosConf/x OtherFlowList TransportCosConf::
qciS1List queuePriorityAndCosId
qciX2List
ICMP, IKE
TransportCosConf/0
NetworkControl (1) 0 (highest priority)
(queue #0) Qci5 (2)
Qci5
unset
TransportCosConf/1
unset 1 (2nd priority)
(queue #1) Qci1, Qci2, Qci3
Qci1, Qci2, Qci3
GTPuEcho, SctpS1, SctpX2, M3,

TransportCosConf/2 AGPS
unset 2 (3rd priority)
(queue #2)
Qci4, Qci6
Qci4, Qci6
OAM (3)
TransportCosConf/3
unset 3 (4th priority)
(queue #3) Qci7, Qci8
Qci7, Qci8
(4)
CallTrace , DDT
TransportCosConf/4
Other (5) 4 (lowest priority)
(queue #4) Qci9
Qci9
(1) Traffic that doesn’t have a DSCP value (i.e. ARP).

(2) As per 3GPP TS 23.203 “Policy and Charging Control Architecture”, QCI 5 traffic is put in a
queue with a higher priority than for the others QCIs (see table ‘Standardized QoS
characteristics’).
If QCI 5 is used for IMS signalling, it should be studied whether the amount of IMS signalling has
significant impact on the conversational class of traffic. If so, then either another QCI with a
lower priority shall be used for the IMS signalling, or the QCI 5 shall be assigned a lower priority
queue than the one for conversational traffic.
(3) OAM uses protocols as SNMP, TFTP, FTP and Telnet that require a low packet loss but are
relatively not sensitive to delay. UL OAM traffic must not be dropped. In case OAM traffic and
the Telecom traffic share the same VLAN, OAM traffic must have priority over telecom BE
traffic. OAM must thus be put in a dedicated queue with higher priority than BE traffic.
(4) Call trace can require high bandwidth. In case of UL congestion due to call trace, the call
trace traffic must be dropped. Call trace traffic must thus be put in the lowest priority queue.
(5) All other flows that contain a DSCP.

It is possible to map different traffic flows onto the same scheduling priority.
The scheduling priority is used as UL traffic scheduler queue ID.

Traffic flow with scheduling priority 0 is assigned to queue 0 and so on.
To avoid that the OAM traffic be starved of bandwidth, it is recommended that either;
• OAM traffic be separated from the user plane in a dedicated Vlan, else that,
• OAM traffic scheduling priority be higher than the best effort traffic
The DSCP to scheduling priority mapping table derived (built) by eNodeB from the provisioned
traffic flows to DSCP mapping and the provisioned traffic flows to scheduling priority mapping as
recommended by ALU is the following:
Traffic flow DSCP scheduling priority
PtpEvtMsg CS7
Qci 5, ICMP, IKE CS6 0
(1)
NetworkControl N.A.
Qci 1, Qci 2, Qci 3 EF 1
GTPuEcho, SctpS1,
AF41
SctpX2, M3, AGPS 2
Qci 4, Qci 6 AF42
OAM AF11
Qci 7 AF22 3
Qci 8 AF21
CallTrace AF12
DDT CS1
(2)
4
Other other
Qci 9 BE
(1) Traffic that doesn’t have a DSCP value (i.e. ARP).

(2) All other flow that contains a DSCP which is not specified in this table.
Table 57: DSCP to scheduling priority mapping derived by eNodeB
If the operator uses a different traffic flows to DSCP mapping and/or a different traffic flows to
scheduling priority mapping than ALU default recommendation, then the DSCP to scheduling priority
mapping will be different than what is shown in the table above.
6.11.1.2 Queue congestion management
If cacAndTrafficShapingMode is “PerVlan” then the queue size is configured through:

• Object:
Enb/EnbTransportConf/RanBackhaul/SlaConf/TransportCosConf/QueueAndSchedulerConf,
Parameter: queueSize, Value: [100-10.000], Unit: packets, Class: C, Service Impact: None,
Update transient impacts details: Immediate-propagation
If cacAndTrafficShapingMode is “PerPort” then the queue size is configured through:
• Object:
eueAndSchedulerConfPerPort, Parameter: queueSize, Value: [100-10.000], Unit: packets, Class:
Default recommendation for the queues size:
Queue Number Queue Size Traffic Flows Scheduling Priority
QueueAndScheduler/0 1: ControlFlowList
2: OtherFlowList TransportCosConf::
TransportCosConf/x queueSize 3: qciS1List queuePriorityAndCosId
(packets) 4: qciX2List
1:ICMP, IKE
TransportCosConf/0 2: NetworkControl
100 3: Qci5
0
(queue #0)
4: Qci5
1: unset
TransportCosConf/1 2: unset
300 3: Qci1, Qci2, Qci3
1
(queue #1)
4: Qci1, Qci2, Qci3
1: GTPuEcho, SctpS1,
SctpX2, M3, AGPS
TransportCosConf/2
8000 2: unset 2
(queue #2) 3: Qci4, Qci6
4: Qci4, Qci6
1 : OAM
TransportCosConf/3 2 : unset
9000 3 : Qci7, Qci8
3
(queue #3)
4 : Qci7, Qci8
1: CallTrace, DDT
TransportCosConf/4 2: Other
10000 3: Qci9
4
(queue #4)
4: Qci9
Two queue congestion management mechanisms are supported at eNodeB; tail drop and WRED.
Per queue, the congestion management mechanism may be based on tail drop or WRED.

Tail drop is recommended for queue handling real time traffic (e.g., UDP traffic).
WRED is recommended for queue handling non real time traffic (e.g.,TCP traffic).
By dropping packets with a certain probability, WRED avoids that many TCP connections decrease
their window at the same time.
There are counters associated to UL traffic management (See Monitoring §) that provide for
average, minimum and maximum packet loss rates. Those rates are obtained by sampling at a
certain period of time the total number of packets accepted and rejected at the queue.
The sampling rate configuration is done through:
• Object: Enb/EnbTransportConf/GlobalTransportConf, Parameter:
packetsLossRateMeasurementPeriod, Value: [10-300], Unit: second, Default: 120, Class: C, Service
If cacAndTrafficShapingMode is “PerVlan” then the queue congestion management is configured

through:
• Object:
Parameter: queueDiscardPolicy, Value: [TailDrop, WRED], Class: B, Service impact: Partial,
If cacAndTrafficShapingMode is “PerPort” then the queue congestion management is configured
through:
• Object:
eueAndSchedulerConfPerPort, Parameter: queueDiscardPolicy, Value: [TailDrop, WRED], Class:
B, Service impact: Partial, Update transient impacts details: Transport-Layers
6.11.1.2.1 Tail Drop
With the tail drop mechanism, once a queue reaches it maximum fill size, the queue discards any
new packets arriving at the queue.
6.11.1.2.2 Weighted Random Early Detection - WRED
There are 3 configurable parameters per queue which govern the WRED mechanism:
• queue minimum threshold
• queue maximum threshold
• maximum drop probability
These three parameters are collectively known as a WRED profile.
The behavior of WRED is as follows:

• When a queue’s fill level is below the minimum threshold, no packets are dropped.
• When a queue’s fill level is between the minimum and maximum thresholds, packets are
dropped with a probability between 0 and the maximum drop probability. The drop
probability is proportional to the queue’s fill level. The more packets in the queue, the
higher the probability an enqueued packet is dropped.
• When a queue level is above the maximum threshold, all packets are dropped.
This can be illustrated as follows:

Figure 95: WRED mechanism
If cacAndTrafficShapingMode is “PerVlan” then the WRED profile is configured through:

• Object:
Parameter: queueMinThreshold, Value: [1-100] it is a percentage, Class: C, Service Impact:
Parameter: queueMaxThreshold, Value: [1-100] it is a percentage, Class: C, Service Impact:
Parameter: queueDropProbability, Value: [1-100] it is a percentage, Class: C, Service Impact:
If cacAndTrafficShapingMode is “PerPort” then the WRED profile is configured through:
• Object:
eueAndSchedulerConfPerPort,
Parameter: queueMinThreshold, Value: [1-100] it is a percentage, Class: C, Service Impact:
Parameter: queueMaxThreshold, Value: [1-100] it is a percentage, Class: C, Service Impact:
Parameter: queueDropProbability, Value: [1-100] it is a percentage, Class: C, Service Impact:
Default recommendation for the WRED profile:

TransportCosConf/x QueueAndScheduler/0 :
queueMinThreshold = 70 (%)
queueMaxThreshold = 90 (%)
queueDropProbability = 100 (%)
mint and maxt values are derived from queueMinThreshold, queueMaxThreshold and queueSize
eNodeB provisioned values as:
mint = queueMinThreshold * queueSize
maxt = queueMaxThreshold * queueSize

eNB
ActivationService
eNBtransportConf
RanBackhaul
Vlan[1-50]
SlaConf
queuePriorityAndCosId = [0-15]
controlFlowList = [SctpS1, SctpX2, GTPuEcho, OAM,

PtpEvtMsg, PtpGenMsg, ICMP, CallTrace, IKE, DDT, M3, AGPS]
otherFlowList = [Other, NetworkControl]
qciS1List = [Qci1-255]
qciX2List = [Qci1-255]
QueueAndSchedulerConf/0
queueDiscardPolicy = [TailDrop, WRED]
queueSchedulerMode = [StrictPriority]
queueSize
queueMinThreshold
queueMaxThreshold
maxDropProbability
Figure 96: UL congestion management – per VLAN - Model object for configuration
6.11.1.3 UL traffic shaping
eNodeB supports UL traffic shaping to adapt to the available backhaul transport bandwidth.
The UL traffic shaping applies either:

• Per-port, on the aggregated traffic which egresses the Ethernet port (only one Ethernet port is
used for all the eNodeB traffic in this release), or

• Per-VLAN, on the aggregated traffic which is managed in a VLAN.
UL traffic shaping applies per-port or per-VLAN.

Per-port and per-VLAN shaping are mutually exclusive.
If UL traffic shaping mode is ‘per VLAN’ with mixity of shaped and non-shaped VLANs then it must
be created one instance of shaper per VLAN, and, for the non-shaped VLAN, egressCir parameter
must be set a value that equals eNB backhaul port bandwidth.
Restriction: <eNodeB> <UL traffic shaping> <Design>
UL traffic shaping per-flow of traffic is not supported.
In case of eUTRAN sharing the uplink traffic cannot be shaped per-port.

The telecom traffic of operators sharing an eNodeB is isolated with VLANs (1 VLAN per operator),
thus the uplink traffic can only be classified and shaped per-VLAN.
The backhaul transport bandwidth is defined at eNodeB through a bandwidth profile which
parameters are CIR/CBS and EIR/EBS. There can be configured a bandwidth profile per port or per
VLAN.
There can be configured a bandwidth profile per VLAN so that;

• the telecom traffic of each operator can be shaped according to its backhaul SLA
• the OAM traffic can be shaped according to its backhaul SLA.
Shaping functionality is performed by the WinPath 2 (WP2) processing unit.

The aggregated flow resulting of the strict priority scheduling is subject to the CIR rate control
when submitted to the Ethernet interface. Also the CBS can be applied.
The shaper transmits CIR/CBS compliant flow.
In this release, the CBS (Committed Burst Size) maximum value actually supported by WP2 is 16 kB
(16384 bytes). If a larger number is provisioned the shaper still uses 16 kBytes.

Rule: <eNodeB> <UL traffic shaping> <Standard>
As per IETF RFC 2698: CBS must be configured to be greater than 0. It is recommended that it is
configured to be equal to or greater than the size of the largest possible IP packet in the stream.
Restriction: <eNodeB> <UL traffic shaping> <Design>
Shaping on EIR/EBS is not supported in this release.
It is recommended that EIR is set to 0.
Dual rate shaping (CIR + EIR) is not recommended because;

• per flow shaping is not implemented in this release,
• remarking of the traffic in excess is not supported by Winpath2
If EIR was allowed there could be drop of high priority traffic by the transport backhaul.
If cacAndTrafficShapingMode is “PerVlan” then the UL shaper is configured through:

• Object: Enb/EnbTransportConf/RanBackhaul/SlaConf,
Parameter: egressCir, Value: [1000-1000000] (with step = 100), Unit: kbit/s, Class: C, Service
Parameter: egressCbs, Value: [10-17], Unit: kByte, Default: 16, Class: C, Service Impact: None,
Parameter: egressEir, Value: [0-0] ], Unit: kbit/s (not supported in this release), Class: C,
Parameter: egressEbs, Value: [0-0], Unit: kByte (not supported in this release), Class: C, Service
If cacAndTrafficShapingMode is “PerPort” then the UL shaper is configured through:

• Object:
eueAndSchedulerConfPerPort,
Parameter: egressCir, Value: [1000-1000000] (with step = 100), Unit: kbit/s, Class: C, Service
Parameter: egressCbs, Value: [10-17], Unit: kByte, Default: 16, Class: C, Service Impact: None,
Parameter: egressEir, Value: [0-0] ], Unit: kbit/s (not supported in this release), Class: C,
Parameter: egressEbs, Value: [0-0], Unit: kByte (not supported in this release), Class: C, Service

eNB
ActivationService
eNBtransportConf
RanBackhaul
Vlan[1-50]
SlaConf
egressCir = [1000-1000000]
egressCbs = [10-17]
QueueAndSchedulerConf/0 egressEir = 0
egressEbs = 0
Figure 97: UL traffic shaping – per VLAN - Model object for configuration

6.11.2 Transport CAC
6.11.2.1 Functional overview
eNB Call Admission Control (CAC) includes Radio CAC and Transport CAC (T-CAC).
When both T-CAC and Radio CAC are applicable, T-CAC is performed first.
T-CAC supports eUTRAN sharing.
T-CAC is enabled through:

• Object: Enb/ActivationService, Parameter: isTransportCacAllowed, Value: [true, false], Class:
B, Service impact: Partial, Update transient impacts details: Transport-Layers
Rule: <eNodeB> <Transport CAC> <Design>
T-CAC applies to the S1-U traffic only.
At RAB set-up (or modify) T-CAC controls if the associated S1-U UL and DL volume of traffic can be
satisfied according to the remaining UL and DL bandwidth of the transport link to the backhaul
network.
A transport link is;

• either a physical link, that is an ethernet port, for which T-CAC applies on the port aggregated
traffic (even if some VLANs are defined),
• or a VLAN, for which T-CAC applies on the VLAN aggregated traffic.
T-CAC may apply in a per port mode or in a per VLAN mode.
Warning: in case the T-CAC mode is changed from ‘per port’ to ‘per VLAN’ (or reversely) then the
setting of parameters dlStaticBandwidth and ingressCir must be reconsidered.
If eUTRAN sharing is activated it is only possible to configure the per VLAN mode.
In case eUTRAN sharing is activated, the number of VLAN and the number of PLMN managed by T-
CAC are the same. There is one VLAN handling S1-U per operator (i.e. per PLMN identified by
VLAN::plmnId). There is one T-CAC runing per VLAN (i.e. per operator).
T-CAC mode of operation is configured through:

• Object: Enb/EnbTransportConf/RanBackhaul, Parameter: cacAndTrafficShapingMode, Value:
[PerPort, PerVlan], Class: B, Service impact: Partial, Update transient impacts details:
Transport-Layers

eNB
eNBtransportConf
RanBackhaul
cacAndTrafficShapingMode = [PerPort, PerVlan]

dlTransportLoadThreshold (1)
ulTransportLoadThreshold
EthernetPort
Vlan[1-50]
SlaConfPerPort plmnId (link to a PlmnIdentity instance)

vLanId = [2-4080; 4096]
vlanName
mtu
ipFormat = [Ipv4, Ipv6]
trafficTypeList = [Oam, S1u, S1c, X2u, X2c, 1588, M1]

ipv6Address / ipv6RoutingPrefixLength
ipv4Address / ipv4SubNetMask
SlaConf
(1): ul/dlTransportLoadThreshold is used by Inter-frequency Load Balancing feature (see this section)
Figure 98: T-CAC - backhaul & VLAN - Model object for configuration
T-CAC applies separately on uplink (egress) and downlink (ingress) direction.
An eRAB is rejected if T-CAC fails in one of the direction (DL or UL).
An eRAB is accepted if T-CAC succeeds in both directions (DL and UL).

Consummed transport link

Event that triggers T-CAC algorithm :
bandwitdh is :
S1-AP INITIAL CONTEXT SETUP REQUEST
S1-AP E-RAB SETUP REQUEST

S1-AP E-RAB MODIFY REQUEST: GBR of eRAB is increased Increased (2)
S1-AP HANDOVER REQUEST: S1 inter-eNB incoming HO
X2-AP HANDOVER REQUEST: X2 inter-eNB incoming HO
S1-AP E-RAB RELEASE COMMAND
S1-AP CONTEXT RELEASE COMMAND

X2-AP CONTEXT RELEASE
S1-AP E-RAB MODIFY REQUEST: GBR of eRAB is decreased

Decreased
S1-AP HANDOVER REQUEST: X2 inter-eNB outgoing HO
X2-AP HANDOVER REQUEST: X2 inter-eNB outgoing HO
X2-AP HANDOVER CANCEL: X2 inter-eNB HO cancel
Call drop without S1-AP CONTEXT RELEASE COMMAND
S1-AP E-RAB MODIFY REQUEST: QCI of eRAB is modified (1)

Increased (2) or Decreased
Intra-eNB HO involving QCI change
(1)
QCI online modification for existing data bearers is possible for QCI in range [6..9].
Note: QCI online modification is enabled at ActivationService::isQciArpOnLineModificationAllowed.
(2)
If the transport bandwidth is not sufficient, the QoS of existing eRABs is maintained by rejecting
the new eRAB.
T-CAC does not modify QoS characteristics of existing eRABs nor pre-empt ressources in case of
transport link bandwidth exhaustion.
T-CAC algorithm operates in an open loop mode. T-CAC does not get feedback from the user-plane
transport layer (i.e. WinPath) of UL and DL bandwidth consumption measurement.
A transport link may carry following types of traffic:

- Common services, amongst;
o S1-C control plane traffic
o X2-C control plane traffic

o OAM traffic
o IEEE 1588 traffic

o M1 & M3 for en services (in downlink only)
o X2-U user plane traffic
- S1-U user-plane traffic.

The bandwidth of a transport link is logically segmented in several transport Classes of Service (CoS)
object(s) (maximum is 16). List of QCIs are allocated to each transport CoS and a bandwidth, called
‘Standard Reserved Bandwidth’, is configured for each transport CoS.
The size of each CoS Standard Reserved Bandwidth corresponds to the maximum bandwidth that can
be allocated for eRABs associated to QCIs affected in the CoS.
At each S1-AP (or X2-AP) procedure that triggers T-CAC algorithm, T-CAC selects the relevant
transport CoS based on the QCI of the eRAB.
To evaluate the needed bandwidth for the eRAB, T-CAC takes into account:
• the GBR for voice and GBR traffic
• the Minimum Bit Rate (minBR) for non-GBR traffic (a.k.a BE)
Note:
1) The Minimum Bit Rate for non-GBR traffic is the minimum IP bit rate that is guaranteed for
each end user in case of S1 load condition. But, in case some S1 bandwidth is left unused then
it is shared amongst the non-GBR users and each non-GBR user may benefit of more bandwidth
than the Minimum Bit Rate.
2) the GBR is provisioned at PCRF and is provided to eNB via S1-AP eRAB Setup Request, while
the Minimum Bit Rate is configured at eNB through OAM.
• for GBR eRAB, a per QCI provisioned UL & DL user plane signaling factor. This is a coefficient
to take into account the RTCP bit rate.
• a per QCI provisionned UL & DL overbooking factor to apply on the eRAB bit rate.
• an overhead bit rate calculated from the protocols header size.

If there is enough bandwidth available in the CoS, the S1-AP (or X2-AP) procedure is accepted
otherwise it is rejected.
UL & DL overbooking factor, user plane signaling factor and packet inter-arrival time are dependant
on the traffic model.
They are configured per operator and per QCI through:

• Object: Enb/EnbTransportConf/PerOperatorTransportConf/TransportCacQciConf,
Parameter: qci, Value: [Qci1-Qci255], Class: C, Service Impact: None, Update transient impacts
Parameter: dlOverbookingFactor, Value: [0-2000], Unit: %, Default: 100, Class: C, Service
Parameter: ulOverbookingFactor, Value: [0-2000], Unit: %, Default: 100, Class: C, Service

dlOverbookingFactor and ulOverbookingFactor new value is taken into account for the already
established eRABs AND the new eRABs.
See “step 4” of T-CAC algorithm description farther for usage of overbooking factors.
• Object: Enb/EnbTransportConf/PerOperatorTransportConf/TransportCacQciConf,
Parameter: dlPacketInterArrivalTime, Value: [1-20000], Unit: ms, Class: C, Service Impact:
Parameter: ulPacketInterArrivalTime, Value: [1-20000], Unit: ms, Class: C, Service Impact:
dlPacketInterArrivalTime and ulPacketInterArrivalTime setting guideline:
- for voice it is the codec period (e.g. 20ms or 30ms)
- for video it is the codec period (e.g. 40ms)
- for non-GBR it is the packet inter-arrival time (e.g. 100ms, it is traffic model
dependant)
• Object: Enb/EnbTransportConf/PerOperatorTransportConf/TransportCacQciConf, Parameter:

userPlaneSigFactor, Value: [0-5], Unit: %, Class: C, Service Impact: None, Update transient
eNB
eNBtransportConf
PerOperatorTransportConf/[0-3]
TransportCacQciConf/[0-31]
qci (Qci1-Qci255)
dlOverbookingFactor
ulOverbookingFactor
dlPacketInterArrivalTime
ulPacketInterArrivalTime
userPlaneSigFactor
Figure 99: T-CAC - per operator - Model object for configuration
6.11.2.2 Emergency calls
6.11.2.2.1 General considerations
Emergency call is always a conversational speech call (i.e Video Telephony may not be an
Emergency call).

There are two kinds of Emergency Calls (EC), Regular EC and CSFB EC.
If IMS VoIP EC is enabled at eNB, an eNB identifies a call as a regular EC if:
RRCConnectionRequest EstablishmentCause is set to “emergency”, or at least one of the E-

RAB(s) has an ARP priority equal to PlmnIdentity::arpPriorityEmergency, for the plmn-
identity associated with this UE, AND,
There is no CSFB indicator received in S1AP Initial Context Setup Request, or CSFB is
disabled at eNB.
Only one Emergency IMS VoIP Call may be initiated per UE.
The data flow to establish a IMS VoIP EC depends on the initial state of the UE (RRC connected, in
idle mode, or in limited service state).
To establish an IMS VoIP EC, the UE has first to establish a PDN connectivity towards the PDN in
charge of Emergency service (using its default bearer for this PDN). eNB then receives the request
to establish a SIP bearer that is being used by the UE to initiate the SIP “INVITE” procedure to the
Core. In return eNB receives the request to establish a VoIP bearer. SIP bearer may be a default
bearer (i.e. first bearer established) or a dedicated bearer. See 3GPP TR 23.869 for IMS Emergency
calls over e-UTRAN use cases.
An emergency IMS VoIP call may coexist with a regular IMS VoIP call. In this case regular IMS VoIP
call has also its own VoIP bearer and SIP bearer.
6.11.2.2.2 eNB considerations
Note: VoIP feature is subject to license per eNB and is activated through:
Object: Enb/LicensingMngtSystem, Parameter: isVoIPEnabled, Value: [true, false], Class: C, Service
impact: None, Update transient impacts details: Immediate-propagation
IMS VoIP Emergency Calls are enabled through:
• Object: Enb/ActivationService, Parameter: isIMSEmergencyCallAllowed, Value: [false, true],
Class: C, Service impact: None, Update transient impacts details: New-set-ups
eNB supports up to two IMS VoIP service per UE to support the combination of 1 emergency IMS VoIP
call + 1 regular IMS VoIP call.
In case ENB receives the request to establish two non Emergency IMS VoIP calls for a given UE, it
accepts the combination.
T-CAC provides a mechanism to accept some extra emergency eRABs in case of transport link
bandwidth reaching exhaustion.
It is based on provisioning a percentage of the transport link bandwidth that is reserved for
emergency calls.
An extra bandwidth, called ‘Extra Reserved Bandwidth’ can be configured in a CoS pool for
emergency calls in case the Reserved Bandwidth is reached.

Engineering: <eNodeB> <Transport CAC>
QCI for RTP/RTCP VoIP traffic is configured by Enb/LteCell/RadioCacCell::qCIforVoipRtpRtcp.

Then the CoS for VoIP emergency calls must contain RadioCacCell::qCIforVoipRtpRtcp within its
allocated QCI(s).
There may be configured an Extra Reserved Bandwidth in the CoS(es) that handle Emergency IMS
VoIP calls. Up to 3 CoS(es) are concerned: CoS for SIP bearer (IMS signaling), CoS for VoIP bearer
and CoS for default bearer.
The other CoS(es) must be configured such that the Extra Reserved Bandwidth equals to the
Standard Reserved Bandwidth.
6.11.2.3 High Priority Access calls
Feature L115860 “High Priority Access Admission Control” does not make any assumption about HPA
service type, although it is probable in the field that HPA calls are VoLTE calls. In the TEG, to
illustrate HPA calls interaction on Transport CAC it is assumed that HPA calls are IMS VoIP calls.
6.11.2.3.1 General considerations
If HPA call is enabled at eNB, an eNB identifies a call as a HPA call if:
RRCConnectionRequest EstablishmentCause is set to “highPriorityAccess”, or at least one of

the E-RAB(s) has an ARP priority equal to PlmnIdentity::arpPriorityHighPriorityAccess, for
the plmn-identity associated with this UE. Any bearer with an ARP value set equal to or less
than this parameter is a High Priority Access bearer.
HPA UEs send RRC Connection Request message with establishment cause “highPriorityAccess”, thus
get UE Connection Setup Priority. This connection priority is independent of bearers ARP value from
the eNB perspective; the assigned ARPs depend on the operator policy configured in the core. This
means that HPA UEs setup E-RABs, for which some will get and some will not get HPA-ARP priority
from the core. Only those bearers that have an ARP value that falls within the HPA-ARP range (ARP
≤ PlmnIdentity::arpPriorityHighPriorityAccess) get overload privileges in the eNB after UE
Connection Setup.
6.11.2.3.2 eNB considerations
HPA Calls are enabled through:

• Object: Enb/ActivationService, Parameter: isHighPriorityAccessUserMgmtEnabled, Value: [false,
true], Class: C, Service impact: None, Update transient impacts details: New-set-ups
T-CAC provides a mechanism to accept some extra HPA eRABs in case of transport link bandwidth
reaching exhaustion.
It is based on provisioning a percentage of the transport link bandwidth that is reserved for HPA

calls.
An extra bandwidth, called ‘Extra Reserved Bandwidth’ can be configured in a CoS pool for HPA
calls in case the Reserved Bandwidth is reached.
In the assumption that HPA calls are IMS VoIP calls, then following rules apply;
QCI for RTP/RTCP VoIP traffic is configured by Enb/LteCell/RadioCacCell::qCIforVoipRtpRtcp.

Then the CoS for VoIP HPA calls must contain RadioCacCell::qCIforVoipRtpRtcp within its allocated
QCI(s).
There may be configured an Extra Reserved Bandwidth in the CoS(es) that handle HPA IMS VoIP
calls. Up to 3 CoS(es) are concerned: CoS for SIP bearer (IMS signaling), CoS for VoIP bearer and CoS
for default bearer.
The other CoS(es) must be configured such that the Extra Reserved Bandwidth equals to the
Standard Reserved Bandwidth.
6.11.2.4 T-CAC per VLAN in downlink
In the following, it is described the T-CAC per VLAN in downlink.

Algorithm description and parameters configuration for the others flavors of T-CAC, that is per VLAN
in uplink or per port in downlink or per port in uplink, are very similar to the per VLAN in downlink
case. There is no duplication of the text for those others cases, but deltas compare to the per VLAN
in downlink are highlighted after.
6.11.2.4.1 T-CAC bandwidth model
The VLAN bandwidth in DL is configured through:

• Object: Enb/EnbTransportConf/RanBackhaul/Vlan/SlaConf, Parameter: ingressCir, Value: [1000-
1000000] (with step = 100), Unit: kbit/s, Class: C, Service Impact: None, Update transient
In downlink, a VLAN may carry possibly common services traffic (S1-C, X2-C, OAM, 1588, S1-U for
eMBMS).
A bandwidth reserved for all those traffic flows is configured through:

• Object: Enb/EnbTransportConf/RanBackhaul/Vlan/SlaConf, Parameter: dlStaticBandwidth,
Value: [10-1000000] (with step = 10), Unit: kbit/s, Default: 10, Class: C, Service Impact: None,
This bandwidth is removed of the bandwidth allocated to the VLAN for the S1-U traffic.

The configuration of a transport CoS provides:
- the QCIs allocated for the transport CoS.

- the reserved bandwidth percentage for the transport CoS within the VLAN.
- the reserved bandwidth percentage for extra emergency eRABs within the CoS. This parameter
tunes the percentage of the bandwidth used for extra emergency eRABs inside the CoS when the
transport CoS bandwidth for any eRAB is reached.
A Transport CoS is configured through a TransportCosConf object. There must be configured as
much TransportCosConf as needed. This is ruled by the operator strategy in terms of traffic flows
allocation per Transport CoS.
A CoS identifier is configured to the Transport CoS through:

• Object: Enb/EnbTransportConf/RanBackhaul /Vlan/SlaConf/TransportCosConf, Parameter:
queuePriorityAndCosId, Value: [0-15], Class: B, Service impact: Partial, Update transient
The QCI to transport CoS mapping is configured through:

• Object: Enb/EnbTransportConf/RanBackhaul/Vlan/SlaConf/TransportCosConf, Parameter:
qciS1List, Value: [Qci1-Qci255], Class: B, Service impact: Partial, Update transient impacts
details: Transport-Layers
An OAM check ensures that each supported QCI is allocated to one and only one transport CoS.
The reserved bandwidth percentage for the CoS is configured through:

• Object:
Enb/EnbTransportConf/RanBackhaul/Vlan/SlaConf/TransportCosConf/TransportCacCosConf,
Parameter: dlReservedBandwidthPercentage, Value: [0-100], Unit: %, Class: C, Service Impact:
This percentage applied on the bandwidth equal to (ingressCIR - StaticBandwidth) provides the
downlink bandwidth allocated to the CoS.
Within the VLAN, there must be verified that:
∑ dlReservedBandwidthPercentage = 100
TransportCacCosConf
This is to ensure that all the available S1-U bandwidth is entirely used over all the configured CoS.
There is a WPS check for ensuring that ∑ dlReservedBandwidthPercentage ≤ 100 .

TransportCacCosConf
The reserved bandwidth percentage for extra emergency eRABs is configured through:
• Object:
Enb/EnbTransportConf/RanBackhaul/Vlan/SlaConf/TransportCosConf/TransportCacCosConf,
Parameter: dlReservedBandwidthForEcAndHpaRabsPercentage, Value: [0-100], Unit: %, Default:
10, Class: C, Service Impact: None, Update transient impacts details: Immediate-propagation

Within a CoS there must be verified that;

dlReservedBandwidthForEmergencyRabsPercentage p dlReservedBandwidthP ercentage
This is to ensure that the CoS bandwidth is not entirely reserved for emergency calls.
There must be configured a non zero dlReservedBandwidthForEcAndHpaRabsPercentage only in the

CoS(es) that handle Emergency IMS VoIP calls and/or HPA calls. Up to 3 CoS(es) are concerned: CoS
for SIP bearer (IMS signaling), Cos for VoIP emergency and/or HPA bearer and CoS for default
bearer.
The other CoS(es) must be configured with dlReservedBandwidthForEcAndHpaRabsPercentage = 0,
such that the Extra Reserved Bandwidth equals to the Standard Reserved Bandwidth.
If “isIMSEmergencyCallAllowed” = false AND “isHighPriorityAccessUserMgmtEnabled” = false then

there must be set TransportCacCosConf::dlReservedBandwidthForEcAndHpaRabsPercentage = 0 for
all CoS(es).

The dimensioning of the dlReservedBandwidthForEcAndHpaRabsPercentage amongst the 3 CoS

handling emergency bearers (IMS, VoIP and default bearers) must be consistent such that, as per T-
CAC perspective;
• the maximum number of simultaneous IMS emergency bearers is not lower than the
maximum number of simultaneous VoIP emergency bearers, AND,
• the maximum number of simultaneous default emergency and/or HPA bearers is not lower
than the maximum number of simultaneous VoIP emergency bearers.
This is to ensure that the maximum number of simultaneous VoIP emergency and/or HPA bearers
can be accepted by T-CAC, and is not limited due to lack of reserved emergency IMS and/or default
bearer(s).
eNB/eNBtransportConf/RanBackhaul
Vlan[1-50]/SlaConf
egressCir
egressCbs
egressEir
egressEbs
ingressCir
ingressCbs – not
used
ulStaticBandwidth
dlStaticBandwidth
qciS1List
qciX2List
controlFlowList
otherFlowList
queuePriorityAndCosId
TransportCacCosConf/0
dlReservedBandwidthPercentage
ulReservedBandwidthPercentage
dlReservedBandwidthForEcAndHpaRabsPercentage
ulReservedBandwidthForEcAndHpaRabsPercentage
Figure 100: T-CAC - per VLAN - Model object for configuration

Per CoS, T-CAC algorithm maintains three variables related to bandwidth that are;
• DL_CoS_Extra_Reserved_Bandwidth: This is the total DL bandwidth for the CoS.
It is denoted as ‘(1)’ in the rest of T-CAC algorithm description when encountered in a formula.
(1) = (SlaConf :: IngressCir − SlaConf :: dlStaticBandwidth) ∗ TransportCacCosConf :: dlReserved

100
BandwidthPercentage
Emergency calls may access (1) entirely while standard calls can only access part of it as defined
by (2) below.
• DL_CoS_Standard_Reserved_Bandwidth: This is the part of the CoS bandwidth that is
accessible for serving any eRABs (standard calls or emergency calls).
(2 ) = (1) ∗  1 − TransportC acCosConf :: dlReserved BandwidthF orEmergenc yRabsPerce ntage 

100

 
• DL_CoS_Consumed_Bandwidth: This is T-CAC perception of the CoS bandwidth consumption

for serving already admitted eRABs.
Illustration of the bandwidth variables managed by T-CAC:
For Emergency calls only

(once (2) is exhausted)
DL_CoS_Extra_Reserved_ Bandwidth
(1) (2) DL_CoS_Standard_Reserved_ Bandwidth (2)
For any eRABs inc. Emergency ones.
DL_CoS_Consumed_Bandwidth.
When DL_CoS_Consumed_Bandwidth crosses this threshold then

only Emergency calls may be accepted.
When DL_CoS_Consumed_Bandwidth crosses this threshold then all

new incoming calls are rejected (included Emergency calls).
Figure 101: T-CAC bandwidth model – per CoS level

VLAN bandwidth = ingressCir
S1-U bandwidth = ingressCir - dlStaticBandwidth

Common services
bandwidth =
dlStaticBandwidth CoS 0 CoS 1 CoS 2
(1) (1) (1)
e.g. S1-C, X2-U,

X2-C, OAM, 1588, (2) (2) (2)
S1-U for eMBMS
e.g. VoIP e.g. SIP e.g. BE
Figure 102: T-CAC bandwidth model – per VLAN level
T-CAC CoS bandwidth consumption vs. S1 bandwidth accessibility per traffic flow:
For illustration, we consider a S1 interface of 100 Mbit/s which is split in 3 transport CoS:
• 1 VoIP CoS of 8 Mbit/s
• 1 GBR CoS of 20 Mbit/s
• 1 non-GBR CoS of 70 Mbit/s
This way this leaves a 2 Mbit/s bandwidth to transport the common services (OAM, CP, X2-U…).
To simplify the illustration we don’t consider bandwidth reservation for emergency calls in this
example (meaning dlReservedBandwidthForEcAndHpaRabsPercentage = 0% for all CoS).
VLAN bandwidth = 100 Mbit/s
S1-U bandwidth = 98 Mbit/s
Common services VoIP GBR non-GBR

2 Mbit/s 8 Mbit/s 20 Mbit/s 70 Mbit/s
From T-CAC, each CoS represent a bandwidth resource from which it decounts a per eRAB cost at
each eRAB establishment. The cost being either based on the GBR data rate received via S1AP
procedure to which may apply for VoIP the overbooking factor (e.g. 50% if silence suppression is
activated for voice), or on the minBitRate provisioned at eNB to which may apply the overbooking
factor chosen in regard of the multiplexing gain that may be used as per the operator call model.
This T-CAC decounting of the S1-U bandwidth must not be mis-interpreted as a static split of the S1-
U bandwidth between the traffic flows. T-CAC acts at call admission for limiting the number of
simultaneous eRABs per traffic type. It does not restrict the accessibility to the S1-U bandwidth by
the traffic flows.

As per VoIP and GBR traffic types engineering recommendation, it is expected that those flows will
load the S1-U at the same load level as the one that has been estimated by T-CAC.
In our example, T-CAC will accept up to 8 Mbit/s of VoIP calls and 20 Mbit/s of GBR calls. And we
expect that the S1-U will be loaded at maximum of 28 Mbit/s by these traffic flows. This will
probably be less depending on the call profile, the time of the day etc…but it must not be higher
than 28 Mbit/s as it is not recommended that this limit is crossed for ensuring SLA of real time
traffic over the transport network.
It is different for non-GBR traffic as the T-CAC is based on a minBitRate that may be adjusted by an
overbooking factor. The overbooking factor must be used when the operator adjusts the
configuration of the T-CAC based on network monitoring. The overbooking factor acts on the
minBitRate value that is taken into account by T-CAC (that is provisioned ‘minBitRate’ x provisioned
‘overbooking factor’). Update of the overbooking factor value will apply not only to evaluate the
cost of the new eRABs establishment but also to update the consumed CoS bandwidth that was
estimated by T-CAC with the previous overbooking factor value (see ‘step 4’ of T-CAC algorithm
farther for more detail).
It can not be predicted what will be the throughput of the cumulated non-GBR traffic on the S1. In
our example, T-CAC will accept up to 70 Mbit/s of non-GBR calls based on the minBitRate and the
overbooking factor. Nonetheless, non-GBR traffic may make use, in add of its engineered CoS
bandwidth of 70 Mbit/s, the S1 bandwidth let unused by others flows (VoIP/GBR/common services).
The throughput of non-GBR traffic over S1 may then range from 70 Mbit/s up to 100 Mbit/s
(maximum S1 throughput) in the case where there is only non-GBR traffic.
The mechanisms that will regulate the non-GBR actual volume of traffic over S1 are;
- the traffic shaping (UL at eNB and DL within the transport network) that enforces QoS amongst the
different traffic flows
- applicative layer, e.g. TCP that will increase/decrease its window size according to the TCP
acknowledgement procedure
- radio scheduler that will allocates radio transmission opportunities according to the volume of
data and the QoS of the data (per eRAB QCI).
As illustration, we consider two use cases:
Use case 1:
VoIP and GBR have consumed 100% of their transport CoS bandwidth, that is 28 Mbit/s, while non-
GBR has consumed 50% of its transport CoS bandwidth, that is 70/2=35 Mbit/s

CoS seen used at CoS seen used at CoS seen used at 50%
100% by T-CAC 100% by T-CAC by T-CAC

The S1 bandwidth for transporting the traffic flows may be partitioned such that:
• VoIP+GBR traffics use their 28 Mbit/s bandwidth
• non-GBR uses at maximum the remaining available S1 bandwidth, that is 100-28=72 Mbit/s
(assuming no common services traffic).
Note that traffic shaping must be set such a way that for non-GBR traffic the CIR is set to the S1 link
rate (in this example 100 Mbit/s).
The S1 bandwidth accessibility per traffic flow is shown in the figure below:
S1 bandwidth accessible to Non-GBR traffic = 2 + 70 Mbit/s
S1 bandwidth accessible to real-time

traffic = 8 + 20 Mbit/s

CoS seen used at CoS seen used at CoS seen used at 50%
100% by T-CAC 100% by T-CAC by T-CAC
Use case 2:
VoIP and GBR have consumed 0% of their transport CoS bandwidth, that is 0 Mbit/s, while non-GBR
has consumed 50% of its transport CoS bandwidth, that is 70/2=35 Mbit/s

CoS seen used at 0% CoS seen used at 0% CoS seen used at 50%
by T-CAC by T-CAC by T-CAC
The S1 bandwidth for transporting the traffic flows may be partitioned such that:
• VoIP+GBR do not use at all their 28 Mbit/s bandwidth
• non-GBR uses at maximum the remaining available S1 bandwidth, that is 100 Mbit/s (assuming
no common services traffic).
Note that traffic shaping must be set such a way that for non-GBR traffic the CIR is set to the S1 link
rate (in this example 100 Mbit/s).
The S1 bandwidth accessibility per traffic flow is shown in the figure below:

S1 bandwidth accessible to Non-GBR traffic = 100 Mbit/s

CoS seen used at 0% CoS seen used at 0% CoS seen used at 50%
by T-CAC by T-CAC by T-CAC
6.11.2.4.2 T-CAC algorithm description
T-CAC algorithm relies on the following steps:

- Step 1: inputs retrieval
- Step 2: transport protocols overhead calculation
- Step 3: eRAB bandwidth consumption calculation

- Step 3.1 - standard call: T-CAC check against DL_CoS_Standard_Reserved_Bandwidth
- Step 3.2 - emergency call: T-CAC check against DL_CoS_Extra_Reserved_Bandwidth
- Step 4: DL_CoS_Consumed_Bandwidth update
Step 1: inputs retrieval
This step is triggered at reception of any S1-AP message to setup/modify/release an eRAB.

Following operations are performed by T-CAC algorithm:
- Retrieval of the Enb/EnbTransportConf/RanBackhaul/Vlan object instance which contains the

TrafficDescriptor object instance with a trafficTypeList parameter indicating that S1-U traffic is
supported
- Use of the Enb/EnbTransportConf/RanBackhaul/Vlan/SlaConf/TransportCacCosConf instance(s)
- Use of the Enb/EnbTransportConf/PerOperatorTransportConf/TransportCacQciConf instances
T-CAC execution for an eRAB relies on:
- the S1AP messages information elements that are the QCI and the e-RAB-GuaranteedBitrateDL
for GBR eRAB. DL_GBR_BIT_RATE = e-RAB-GuaranteedBitrateDL (S1AP)
- the provisioned RadioCacCell::dlMinBitRateForBE ≥ 0 for non-GBR eRAB.
Note: this is a Class C parameter that is taken into account for the new RABs.

RadioCacCell::dlMinBitRateForBE is a common parameter used both by Radio-CAC and T-CAC.
RadioCacCell::dlMinBitRateForBE is a common parameter used across all non-GBR QCIs.
Setting RadioCacCell::dlMinBitRateForBE = 0 implies no Transport CAC is running for non-GBR eRAB.
- the bandwidth consumed for the transport CoS associated to the QCI in DL, that is
DL_CoS_Consumed_Bandwidth
- the bandwidth for the transport CoS on the physical link of the VLAN, that is
DL_CoS_Standard_Reserved_Bandwidth
Step 2: transport protocols overhead calculation
T-CAC algorithm calculates the overhead bit rate as the sum of the protocols headers divided by the
packet inter-arrival time configured for the QCI.
It is denoted as ‘Overhead_Bit_Rate’ in the rest of T-CAC algorithm description when encountered in
a formula.
GTP _ UDP _ IP _ eNB _ Header + IPSec _ UDP _ Security _ Header + Eth _ Phy _ Header
Overhead _ Bit _ Rate =
TransportCacQciConf :: dlPacketInterArrivalTime
Notes:
1 GTP_UDP_IP_eNB_Header is the GTP/UDP/IP eNB header which size depends on the eRAB
Transport Layer Address IP version configured at Vlan::ipFormat:
IP Type IPv4 IPv6
GTP_UDP_IP_eNB_Header (bits) 288 448
2 IPSec_UDP_IP_Security_Header is the IPsec/UDP/IP security header. It is non nil if IPsec is

enabled.
Here is a summary of the best-case, worst-case, and average IPsec overhead for various
configurations:

Best-Case Worst-Case Average (1)

IP Version IPsec Configuration
(bytes) (bytes) (bytes)
3DES encryption + Integrity Protection 50 57 54
IPv4 AES encryption + Integrity Protection 58 73 66 (2)
Integrity Protection Only 42 45 44
3DES encryption + Integrity Protection 70 77 74
IPv6 AES encryption + Integrity Protection 78 93 86 (2)
Integrity Protection Only 62 65 64
(1) Average value are average between best-case and worst-case.

(2) Max average value is chosen as hardcoded IPsec overhead.
There is a single IPsec overhead value used by T-CAC whatever the IPsec flavor:
IP Type IPv4 IPv6
IPSec_UDP_IP_Security_Header (bits) 528 688
3 ETH_PHY_Header is an ETH/PHY header of 336 bits (ETH=22 bytes, PHY=20 bytes)

4 Example of S1U overhead bit rate calculation by eNB:
voice + 31 bytes
AMR 12.2 kbit/s PDU
RTP + 12 VoIP overhead
VoIP overhead (40 bytes) is
UDP + 8 included in the GBR value received
from the signaling plane (S1AP).
VoIP 29.82 kbit/s
IPv4 + 20
inc. + 5% for RTCP
GTP + 8 S1 overhead
UDP + 8
IPv4 + 20
ESP
S1 overhead UDP + 66 (IPsec over IPv4)

bit rate
57.6 kbit/s IPv4 IPSec overhead
VoIP over S1 ETH + 22 (hardcoded)

= 29.82 + 57.6
= 87.42 kbit/s PHY + 20
Figure 103: S1 overhead bit rate calculation – example for VoIP in IPv4 with IPsec

provisioned
input value
parameter
output value
service
GBR non-GBR
type
QCI 1 2 3 4 5 6 7 8 9 Calculation Unit Comment
traffic type VoIP - - - IMS - - - BE
application Kbit/ data = Conversational (VoIP), Video Streaming,
(1) 12,2 - - - n.a.
bit rate s Interactive Gaming
This is the packet inter arrival time (codec
packet period) to be provisioned
(2) inter 20 - - - n.a. ms TransportCacQciConf::dlPacketInterArrivalTi
arrival time me
[1-20000] ms
(3) PDU size 31 - - - (1)x(2)/8 byte function of codec rate & codec period
RTP over
IPv4 or IPv6 IPv4 n.a. RTP over IPv4 or IPv6 ?
?
RTP
(4) 40 (5)+(6)+(7) byte
overhead
n.a.
(5) RTP 12 n.a. byte 12
(6) UDP 8 n.a. byte 8
(7) IP 20 n.a. byte IPv4=20, IPv6=40
GBR DL_GBR_BIT_RATE (S1AP).
Kbit/
(8) (provisione 28,4 - - - [(3)+(4)]*8/(2) This is provisioned at the PCRF and sent by MME
s
d at PCRF) to eNB within the S1AP: eRAB Setup Request.
This is the RTCP bandwidth (in % of data rate)
0 0 0 to be provisioned
(9) RTCP % 5% n.a. %
% % % TransportCacQciConf::userPlaneSigFactor
[0-5]%
(10 traffic data 29,8 Kbit/
- - - (8)x[1+(9)] GBR bit rate included RTCP
) rate 2 s
service
GBR non-GBR
type
minBR is dimensionned based on a call model
(11 Kbit/
minBR 32 RadioCacCell::dlMinBitRateForBE
) s
[0-2048] Kbit/s
(12
PDU size 1500 0 0 0 1500 byte PDU size dimensioned from call model
)
packet
function of minBR/GBR & PDU size
(13 inter
n.a. 375 0 0 0 375 (12)*8/(11) ms packet inter arrival time must be < 20000 ms (it
) arrival time
is a provisioning limitation)
calculated
If above calculated value is > 20000 ms, it must
packet be provisioned max setable value, that is 20000
(14 inter minimum[(13);1000 ms.
375 0 0 0 375 ms
) arrival time ] TransportCacQciConf::dlPacketInterArrivalTi
adjusted me
[1-20000] ms
S1-u over
IPv4 or IPv6 IPv4
? Calculation Unit Comment
IPsec
IPsec
activated ?
(15 S1
36 (16)+(17)+(18) byte
) overhead
(16
GTP S1 8 n.a. byte 8
)
(17
UDP 8 n.a. byte 8
)
(18
IP 20 n.a. byte IPv4=20, IPv6=40
)
(19 IPsec
66 n.a. byte eNB hardcoded value: 66 (IPv4) or 86 (IPv6)
) overhead
(20
ETH 22 n.a. byte 22 with VLAN tagging, or 18 without
)
(21 20 (Preamble: 7 + Start of frame delimiter: 1 +
PHY 20 n.a. byte
) Interframe gap: 12)
(22 Total S1
144 (15)+(19)+(20)+(21) byte
) overhead
service
GBR non-GBR
type
S1 GBR: (22)x8/(2)
(23 57,6 Kbit/ overhead bit rate per eRAB at target
overhead - - - 3,07 - - - 3,07 non-GBR:
) 0 s dlPacketInterArrivalTime
bit rate (22)x8/(13)
S1 overhead bit rate per eRAB at provisioned
(24 Kbit/
overhead n.a. 3,07 - - - 3,07 (22)x8/(14) dlPacketInterArrivalTime
) s
bit rate This is the value for 'Overhead_Bit_Rate' used

adjusted by T-CAC algorithm
(25 87,4 35,0 35,0 GBR: (10)+(23) Kbit/ S1-u bandwidth per eRAB at target
S1 bit rate - - - - - -
) 2 7 7 non-GBR: (11)+(23) s dlPacketInterArrivalTime
(26 S1 bit rate 35,0 35,0 Kbit/ S1-u bandwidth per eRAB at provisioned
n.a. - - - (11)+(24)
) adjusted 7 7 s dlPacketInterArrivalTime
Table 58: S1 bit rate calculation – example for IMS VoIP & non-GBR in IPv4 with IPsec
Note 1: IP fragmentation is not considered in this estimate. In case fragmentation occurs, this
causes a small underestimate of S1 traffic volume as the headers of the fragmented packet are not
taken into account.
Note 2: rows that address ‘target’ and ‘adjusted’ value can be disregard as there of use farther in
the section considering “Overbooking usage for non-GBR eRAB with a ‘low’ minBR”.
Step 3: eRAB bandwidth consumption calculation
T-CAC algorithm calculates the bandwidth consumed by the eRAB within the transport bandwidth
allocated to the CoS associated to the QCI of the eRAB.
It is denoted as ‘DL_CoS_Bandwidth_Consumption_eRAB’ in the rest of T-CAC algorithm description

when encountered in a formula.

IF (Dl_GBR_Bit_Rate is present) THEN

/* GBR eRAB */
Dl_CoS_Bandwidth_Consumption_eRAB =
Overhead_Bit_Rate + (Dl_GBR_Bit_Rate_Delta* (1 + TransportCacQciConf::userPlaneSigFactor ))
ELSEIF (RadioCacCell::dlMinBitRateForBE > 0) THEN

/* non-GBR eRAB */
Dl_CoS_Ban dwidth_Con sumption_e RAB = Overhead_B it_Rate + RadioCacC ell :: dlMinBitRa teForBE
ENDIF
Notes:
1. Dl_GBR_Bit_Rate present means that the information element e-RAB-GuaranteedBitrateDL is
present in S1AP message received for that particular GBR eRAB. In case Dl_GBR_Bit_Rate is not
present the AMBR is not used but rather the RadioCacCell::dlMinBitRateForBE
2. For GBR eRAB, Dl_GBR_Bit_Rate_Delta is calculated as follows;
S1-C procedure Dl_GBR_Bit_Rate_Delta
Dl_GBR_Bit_Rate
eRAB setup or incoming handover
of eRAB to setup or move-in after incoming HO
eRAB GBR increase new Dl_GBR_Bit_Rate – initial Dl_GBR_Bit_Rate
Dl_GBR_Bit_Rate
eRAB release or outgoing handover
of eRAB to release or move-out after outgoing HO
eRAB GBR decrease initial Dl_GBR_Bit_Rate – new Dl_GBR_Bit_Rate
3. If RadioCacCell::dlMinBitRateForBE = 0 then no transport CAC is performed at eRAB setup nor

incoming handover.

• Step 3.1 - standard call: T-CAC check against DL_CoS_Standard_Reserved_Bandwidth
When T-CAC algorithm runs in case of consumed bandwitdh decrease it is always successful and
there’s no additional check. In case of consumed bandwitdh increase, T-CAC succeeds only if there is
a free transport bandwidth to accept the new or modified eRAB.
IF ((Dl_GBR_Bit_Rate is present) AND

((Dl_CoS_Ban dwidth_Con sumption_e RAB ∗ TransportC acQciConf :: dlOverbook ingFactor ) + (3) ≤ (2 )) ) THEN
/* GBR eRAB */
the eRAB to setup/modify is accepted (established) and the TAC succeeds
ELSEIF ((RadioCacCell::dlMinBitRateForBE > 0) AND
((Dl_CoS_Bandwidth_Consumption_eRAB ∗ TransportCacQciConf :: dlOverbookingFactor) + (3) ≤ (2)) ) THEN
/* non-GBR eRAB */
ELSEIF (RadioCacCell::dlMinBitRateForBE = 0) THEN
/* non-GBR eRAB */
ELSE /* in any other case: T-CAC failure */
the eRAB to setup is rejected or the QCI change is rejected

ENDIF
(2) = DL_CoS_Standard_Reserved_Bandwidth
(3) = DL_CoS_Consumed_Bandwidth

• Step 3.2 - emergency call: T-CAC check against DL_CoS_Extra_Reserved_Bandwidth
The step 3.2 triggers the Extra_bandwidth use within transport CoS if the eRAB to setup/modify is an
Regular Emergency eRAB.
IF ((Dl_GBR_Bit_Rate is present) AND

((Dl_CoS_Bandwidth_Consumption_eRAB ∗ TransportCacQciConf :: dlOverbookingFactor) + (3) ≤ (1)) ) THEN
/* GBR eRAB */
ELSEIF ((RadioCacCell::dlMinBitRateForBE > 0) AND
((Dl_CoS_Ban dwidth_Con sumption_eRAB ∗ TransportC acQciConf :: dlOverbookingFactor ) + (3) ≤ (1)) ) THEN
/* non-GBR eRAB */
ELSEIF (RadioCacCell::dlMinBitRateForBE = 0) THEN
/* non-GBR eRAB */
ELSE /* in any other case: T-CAC failure */
the eRAB to setup is rejected or the QCI change is rejected

ENDIF
(1) = DL_CoS_Extra_Reserved_Bandwidth
(3) = DL_CoS_Consumed_Bandwidth
Step 4: DL_CoS_Consumed_Bandwidth update
After eRAB setup or incoming handover or eRAB GBR increase then T-CAC adds the eRAB contribution
from the current DL_CoS_Consumed_Bandwidth for the QCI of the eRAB:
DL_CoS_Con sumed_Band width ( qci ( x )) + = Dl_CoS_Ban dwidth_Con sumption_e RAB
After eRAB release or outgoing handover or eRAB GBR decrease then T-CAC substracts the eRAB
contribution from the current DL_CoS_Consumed_Bandwidth for the QCI of the eRAB:
DL_CoS_Con sumed_Band width ( qci ( x )) − = Dl_CoS_Ban dwidth_Con sumption_e RAB
The contribution of all the eRABs to the consumed bandwidth is modulated by applying the
overboking factor provisonned per QCI:

DL_CoS_Consumed_Bandwidth = ∑ DL_CoS_Consumed_Bandwidth(qci( x))* TransportCacQciConf (qci( x))::dlOverbookingFactor

qci(x)
DL_CoS_Consumed_Bandwidth calculation shows that setting a new value for dlOverbookingFactor

parameter applies for the already established eRABs AND the new eRABs.
6.11.2.4.3 Overbooking factor usage guidelines
The purpose of T-CAC feature is to ensure real time traffic (VoIP, GBR) is guaranteed to be served
its S1 bandwidth in the case where there is mixity of real time traffic with non real time traffic. For
achieving this, T-CAC must be activated in conjunction with traffic shaping. A per eRAB overbooking
factor is used for accepting at call admission an amount of eRABs that will ensure that the per eNB
S1 bandwidth that has been ‘reserved’ on the transport network for backhauling LTE traffic may be
loaded up to its maximum. Given that not all the admitted eRABs will traffic at the same time, it
may be used overbooking factor to lower the weight of eRAB load from CAC perspective.
It is recommended that VoIP and GBR traffic be not overbooked by T-CAC. This means that the
provisioned overbooking factor for those traffic flows is set to 100%. Note that VoIP may be set a
lower overbooking factor in case mechanism for silence suppression is activated.
It is assumed that the VoIP and GBR CoS bandwidth and overbooking factors are set at eNB in
consistency with the SLA that is enforced by the provider of the transport network in order to
preserve the the end-to-end QoS (delay, jitter, loss). Hence, it makes not sense to use overbooking
factor lower than 100%. Else this would signify that the LTE traffic from those CoS could suffer QoS
degradation in case the SLA is not respected.
On the contrary, non-GBR may be overbooked by T-CAC by provisioning overbooking factor lower
than 100%. As these are non guaranteed traffic this is up to the operator to define how much non-
GBR eRABs can be accepted at T-CAC while those traffic flows still be served an acceptable end-to-
end QoS from end user perspective.
In the case of GBR traffic, the overbooking factor must be set to 100%.
Nonetheless, for VoIP, if silence suppression is performed it is recommended to set a an
overbooking factor that is adjusted to the real volume of voice traffic.
Silence suppression can reduce the bandwidth usage by 50%.
In the case of non-GBR traffic, if radio-CAC and T-CAC have different requirements for their minBR
values (while there is a single common parameter) then the overbooking factor must be tuned such
that T-CAC expectation is met.
E.g.: if minBR = 1kbps & overbooking = 2000% => minBR = 1kbps at radio-CAC & 20kbps at T-CAC.
Note that for non-GBR traffic even the minBR is not guaranteed.

Setting TransportCacQciConf::dlOverbookingFactor = 0 implies no Transport CAC is running for the

considered QCI.
Rule: <eNodeB> <ITransport CAC> <Design>
If TransportCacQciConf::dlOverbookingFactor = 0 and
TransportCacCosConf::dlReservedBandwidthPercentage = 0 then eNB accepts all eRABs setup for
the considered QCI.
Example of overbooking factor usage with:
• IMS VoIP without silence suppression (overbooking factor = 100%) vs. IMS VoIP with silence
suppression (overbooking factor = 50%)
• non-GBR without multiplexing factor (overbooking factor = 100%) vs. non-GBR with
multiplexing factor of 20 (overbooking factor = 1/20 = 5%)
Calculation tables hereafter show that in this example:
• with silence suppression (overbooking set to 50%) T-CAC may accept twice the number of
IMS VoIP eRABs vs. without silence suppression.
• with overbooking set to 5% T-CAC may accept 20 time the number of non-GBR eRABs vs.
when overbooking is set to 100%.
Note: rows that address ‘target’ and ‘adjusted’ value can be disregard as there of use farther in the
section considering “Overbooking usage for non-GBR eRAB with a ‘low’ minBR”.
provisione
d input value
parameter
output value
service
GBR non-GBR
type
traffic
VoIP - - - IMS - - - BE
type
applicatio Kbit/ data = Conversational (VoIP), Video Streaming,
(1) 12,2 - - - n.a.
n bit rate s Interactive Gaming
packet This is the packet inter arrival time (codec period)
inter to be provisioned
(2) 20 - - - n.a. ms
arrival TransportCacQciConf::dlPacketInterArrivalTime
time [1-20000] ms
RTP over
IPv4 or IPv4 n.a. RTP over IPv4 or IPv6 ?
IPv6 ?
RTP
(4) 40 (5)+(6)+(7) byte
overhead
(5) RTP 12 n.a. n.a. byte 12
(7) IP 20 n.a. byte IPv4=20, IPv6=40
GBR
DL_GBR_BIT_RATE (S1AP).
(provision Kbit/
(8) 28,4 - - - [(3)+(4)]*8/(2) This is provisioned at the PCRF and sent by MME to
ed at s
eNB within the S1AP: eRAB Setup Request.
PCRF)
This is the RTCP bandwidth (in % of data rate) to
0 0 0 be provisioned
(9) RTCP % 5% n.a. %
[0-5]%
(10 traffic 29,8 Kbit/
) data rate 2 s

service
GBR non-GBR
type
traffic
VoIP - - - IMS - - - BE
type
(11 Kbit/
) s
[0-2048] Kbit/s
(12
)
packet
inter function of minBR/GBR & PDU size
(13 n.a.
arrival 375 0 0 0 375 (12)*8/(11) ms packet inter arrival time must be < 20000 ms (it is
)
time a provisioning limitation)
calculated
packet
If above calculated value is > 20000 ms, it must be
inter
(14 minimum[(13);10 provisioned max setable value, that is 20000 ms.
arrival 375 0 0 0 375 ms
) 00] TransportCacQciConf::dlPacketInterArrivalTime
time
[1-20000] ms
adjusted
S1-u over
IPv4 or IPv4
IPv6 ?
Calculation Unit Comment
IPsec
activated IPsec
?
(15 S1
36 (16)+(17)+(18) byte
) overhead
(16
)
(17
UDP 8 n.a. byte 8
)
(18
)
(19 IPsec
) overhead
(20
)
PHY 20 n.a. byte
(22 Total S1 (15)+(19)+(20)+(2
144 byte
) overhead 1)
service
GBR non-GBR
type
traffic
VoIP - - - IMS - - - BE
type
S1 GBR: (22)x8/(2)
overhead - - - 3,07 - - - 3,07 non-GBR:
(24 overhead Kbit/ dlPacketInterArrivalTime
n.a. 3,07 - - - 3,07 (22)x8/(14)
) bit rate s This is the value for 'Overhead_Bit_Rate' used by
adjusted T-CAC algorithm
GBR: (10)+(23)
(25 87,4 35,0 35,0 Kbit/ S1-u bandwidth per eRAB at target
S1 bit rate - - - - - - non-GBR:
) 2 7 7 s dlPacketInterArrivalTime
(11)+(23)
n.a. - - - (11)+(24)
This is for adjusting provisioned
overbooki dlPacketInterArrivalTime vs. target
(27 100
ng factor n.a. - - - 100% (25)/(26) % dlPacketInterArrivalTime
) %
adjusted This is the value to be provisioned such that there
is actually no overbooking factor.
This is the overbooking factor to be provisioned
for the QCI to reach a given number of
(28 overbooki 100
100% - - - - - - 100% n.a. % simultaneous subscribers.
) ng factor %
TransportCacQciConf::dlOverbookingFactor
[0-2000] %
service
GBR non-GBR
type
traffic
VoIP - - - IMS - - - BE
type
This is the bandwidth accessible to S1-u traffic
provisoned at:
(29 S1-u Kbit/ - SlaConfPerPort::ingressCir if
100000 n.a.
) bandwidth s cacAndTrafficShapingMode = PerPort
- SlaConf::ingressCir of the Vlan handling S1-u if
This is the estimated bandwidth needed for all
others traffic but S1-u traffic, it is provisoned at:
(30 Static Kbit/ - SlaConfPerPort::dlStaticBandwidth if
2000 n.a.
- SlaConf::dlStaticBandwidth of the Vlan handling
S1-u if cacAndTrafficShapingMode = PerVlan

This is the bandwidth for the CoS handling the QCI

(in % of the S1-u bandwidth minus the static
bandwidth).
They may be several QCIs per CoS but we assume
the QCI is given the whole CoS bandwidth.
This is to calculate the maximum # of eRABs that
(31 CoS 0 0 0 0 0 0
15% 5% 70% n.a. % can be accepted by T-CAC for a QCI.
) bandwidth % % % % % %
E.g.: Assuming QCI 1, 2 & 3 belong to the same
CoS.
=> max # eRABs with QCI 1 is calculated when the
CoS bandwidth is only used by QCI 1.
TransportCacCosConf::dlReservedBandwidthPer
centage
Reserved bandwidth for Emergency Calls (in % of
reserved CoS bandwidth)
(32 0 0 0 0 0 0
bandwidth 0% 0% 0% n.a. % TransportCacCosConf::
) % % % % % %
for EC dlReservedBandwidthForEcAndHpaRabsPercenta
ge
(33 CoS 1470 6860
0 0 0 4900 0 0 0 [(29)-(30)]*(31) Kbit bandwidth for this CoS
) bandwidth 0 0
GBR: (33)*[1-
(34 (32)]/[(25)*(28)] # of simultaneous eRABs (standard or emergency)
# eRABs 168 - - - 139 - - - 1955 RAB
) non-GBR: (33)*[1- accepted by T-CAC
(32)]/[(26)*(28)]
GBR:
(33)*(32)/[(25)*(2 # of simultaneous emergency eRABs accepted by
# extra
(35 8)] T-CAC
eRABs for 0 - - - 0 - - - 0 RAB
) non-GBR: SIP bearers >= VoIP bearers AND default bearers
EC
(33)*(32)/[(26)*(2 >= VoIP bearers
8)]
(36 # total # of maximum simultaneous VoIP eRABs accepted
168 - - - 139 - - - 1955 (34)+(35) RAB
) eRABs by T-CAC
Table 59: IMS VoIP & non-GBR without overbooking

provisione
d input value
parameter
output value
service
GBR non-GBR
type
traffic
VoIP - - - IMS - - - BE
type
applicatio Kbit/ data = Conversational (VoIP), Video Streaming,
(1) 12,2 - - - n.a.
n bit rate s Interactive Gaming
packet This is the packet inter arrival time (codec period)
inter to be provisioned
(2) 20 - - - n.a. ms
arrival TransportCacQciConf::dlPacketInterArrivalTime
time [1-20000] ms
RTP over
IPv4 or IPv4 n.a. RTP over IPv4 or IPv6 ?
IPv6 ?
RTP
(4) 40 (5)+(6)+(7) byte
overhead
(5) RTP 12 n.a. n.a. byte 12
(7) IP 20 n.a. byte IPv4=20, IPv6=40
GBR
DL_GBR_BIT_RATE (S1AP).
(provision Kbit/
(8) 28,4 - - - [(3)+(4)]*8/(2) This is provisioned at the PCRF and sent by MME to
ed at s
eNB within the S1AP: eRAB Setup Request.
PCRF)
This is the RTCP bandwidth (in % of data rate) to
0 0 0 be provisioned
(9) RTCP % 5% n.a. %
[0-5]%
(10 traffic 29,8 Kbit/
) data rate 2 s
service
GBR non-GBR
type
traffic
VoIP - - - IMS - - - BE
type
(11 Kbit/
) s
[0-2048] Kbit/s
(12
)
packet
inter function of minBR/GBR & PDU size
(13 n.a.
arrival 375 0 0 0 375 (12)*8/(11) ms packet inter arrival time must be < 20000 ms (it is
)
time a provisioning limitation)
calculated
packet
If above calculated value is > 20000 ms, it must be
inter
(14 minimum[(13);10 provisioned max setable value, that is 20000 ms.
arrival 375 0 0 0 375 ms
) 00] TransportCacQciConf::dlPacketInterArrivalTime
time
[1-20000] ms
adjusted
S1-u over
IPv4 or IPv4
IPv6 ?
Calculation Unit Comment
IPsec
activated IPsec
?
(15 S1
36 (16)+(17)+(18) byte
) overhead
(16
)
(17
UDP 8 n.a. byte 8
)
(18
)
(19 IPsec
) overhead
(20
)
PHY 20 n.a. byte
(22 Total S1 (15)+(19)+(20)+(2
144 byte
) overhead 1)
service
GBR non-GBR
type
traffic
VoIP - - - IMS - - - BE
type
S1 GBR: (22)x8/(2)
overhead - - - 3,07 - - - 3,07 non-GBR:


(24 overhead Kbit/ dlPacketInterArrivalTime
n.a. 3,07 - - - 3,07 (22)x8/(14)
) bit rate s This is the value for 'Overhead_Bit_Rate' used by
adjusted T-CAC algorithm
GBR: (10)+(23)
(25 87,4 35,0 35,0 Kbit/ S1-u bandwidth per eRAB at target
S1 bit rate - - - - - - non-GBR:
) 2 7 7 s dlPacketInterArrivalTime
(11)+(23)
n.a. - - - (11)+(24)
This is for adjusting provisioned
overbooki dlPacketInterArrivalTime vs. target
(27 100
ng factor n.a. - - - 100% (25)/(26) % dlPacketInterArrivalTime
) %
adjusted This is the value to be provisioned such that there
is actually no overbooking factor.
This is the overbooking factor to be provisioned
for the QCI to reach a given number of
(28 overbooki
50% - - - 50% - - - 5% n.a. % simultaneous subscribers.
) ng factor
TransportCacQciConf::dlOverbookingFactor
[0-2000] %
service
GBR non-GBR
type
traffic
VoIP - - - IMS - - - BE
type
This is the bandwidth accessible to S1-u traffic
provisoned at:
(29 S1-u Kbit/ - SlaConfPerPort::ingressCir if
100000 n.a.
- SlaConf::ingressCir of the Vlan handling S1-u if
This is the estimated bandwidth needed for all
others traffic but S1-u traffic, it is provisoned at:
(30 Static Kbit/ - SlaConfPerPort::dlStaticBandwidth if
2000 n.a.
- SlaConf::dlStaticBandwidth of the Vlan handling
S1-u if cacAndTrafficShapingMode = PerVlan
This is the bandwidth for the CoS handling the QCI
(in % of the S1-u bandwidth minus the static
bandwidth).
They may be several QCIs per CoS but we assume
the QCI is given the whole CoS bandwidth.
This is to calculate the maximum # of eRABs that
(31 CoS 0 0 0 0 0 0
15% 5% 70% n.a. % can be accepted by T-CAC for a QCI.
) bandwidth % % % % % %
E.g.: Assuming QCI 1, 2 & 3 belong to the same
CoS.
=> max # eRABs with QCI 1 is calculated when the
CoS bandwidth is only used by QCI 1.
TransportCacCosConf::dlReservedBandwidthPer
centage
Reserved bandwidth for Emergency Calls (in % of
reserved CoS bandwidth)
(32 0 0 0 0 0 0
bandwidth 0% 0% 0% n.a. % TransportCacCosConf::
) % % % % % %
for EC dlReservedBandwidthForEcAndHpaRabsPercenta
ge
(33 CoS 1470 6860
0 0 0 4900 0 0 0 [(29)-(30)]*(31) Kbit bandwidth for this CoS
) bandwidth 0 0
GBR: (33)*[1-
(34 3911 (32)]/[(25)*(28)] # of simultaneous eRABs (standard or emergency)
# eRABs 336 - - - 279 - - - RAB
) 9 non-GBR: (33)*[1- accepted by T-CAC
(32)]/[(26)*(28)]
GBR:
(33)*(32)/[(25)*(2 # of simultaneous emergency eRABs accepted by
# extra
(35 8)] T-CAC
eRABs for 0 - - - 0 - - - 0 RAB
) non-GBR: SIP bearers >= VoIP bearers AND default bearers
EC
(33)*(32)/[(26)*(2 >= VoIP bearers
8)]
(36 # total 3911 # of maximum simultaneous VoIP eRABs accepted
336 - - - 279 - - - (34)+(35) RAB
) eRABs 9 by T-CAC
Table 60: IMS VoIP & non-GBR with overbooking
6.11.2.5 T-CAC per VLAN in uplink
Same as per VLAN T-CAC in downlink by replacing the downlink parameters ‘dl’ by the uplink
parameters ‘ul’ and by replacing the ingressCir parameter by the egressCir parameter.
Parameters to be configured are:
• RadioCacCell::ulMinBitRateForBE
• TransportCacCosConf::ulReservedBandwidthPercentage

• TransportCacCosConf::ulReservedBandwidthForEcAndHpaRabsPercentage
• TransportCacQciConf::ulOverbookingFactor
• TransportCacQciConf::ulPacketInterArrivalTime
• SlaConf::egressCir
• SlaConf::ulStaticBandwidth
Note: There is a parameter SlaConf::egressCbs that is unused by T-CAC algorithm in this release.
In the configuration model, T-CAC and UL Traffic Shaping features work closely.
Nonetheless, T-CAC and UL Traffic Shaping are 2 independent features.
T-CAC and UL Traffic Shaping may either be both configured, or only T-CAC may be configured, or
only UL Traffic Shaping may be configured.
The T-CAC stategy must be the same as the UL Traffic Shaping strategy.
If T-CAC and UL Traffic Shaping are both configured, then;
• both of them apply the same mode of operation: both apply per port or both apply per VLAN.
There is a single parameter for configuring T-CAC and UL Traffic Shaping mode of operation
(RanBackhaul::cacAndTrafficShapingMode).
• both of them apply to the same CoS. That is, both apply to the same per CoS qciS1List. QCIs
scheduled to the same shaping queue share the same CoS_Standard_Reserved_Bandwidth.
At eNB a Transport CoS instance can be viewed as the representation of a queue of the shaper (if UL
traffic shaping is activated) and/or as a bandwidth pool for UL T-CAC (if T-CAC is activated).
If both T-CAC and UL Traffic Shaping are activated, then TransportCosConf::queuePriorityAndCosId
configures both the scheduling priority assigned to the queue and the CoS identifier assigned to the
Transport CoS. Beside, TransportCosConf object must have one TransportCacCosConf child for T-CAC
setting and one QueueAnd SchedulerConf child for UL Traffic Shaping setting.
It is recommended that T-CAC and UL Traffic Shaping features be both configured at eNB.
In downlink, it is assumed that shaping is activated in the backhaul.
6.11.2.6 T-CAC per port in downlink
Same as per VLAN T-CAC in downlink by focusing on the single VLAN that represents the port.

• TransportCacCosConfPerPort::dlReservedBandwidthPercentage
• TransportCacCosConfPerPort::dlReservedBandwidthForEcAndHpaRabsPercentage
• SlaConfPerPort::ingressCir
• SlaConfPerPort::dlStaticBandwidth
• TransportCosConfPerPort::qciS1List
eNB/eNBtransportConf/RanBackhaul
cacAndTrafficShapingMode = PerPort
EthernetPort/SlaConfPerPort
egressCir
egressCbs
egressEir
egressEbs
ingressCir
ingressCbs – not
used
ulStaticBandwidth
dlStaticBandwidth
TransportCosConfPerPort/[0-15]
qciS1List
qciX2List
controlFlowList
otherFlowList
queuePriorityAndCosId
TransportCacCosConfPerPort
dlReservedBandwidthPercentage
ulReservedBandwidthPercentage
dlReservedBandwidthForEcAndHpaRabsPercentage
ulReservedBandwidthForEcAndHpaRabsPercentage
Figure 104: T-CAC - per port - Model object for configuration
6.11.2.7 T-CAC per port in uplink
Same as per PORT T-CAC in downlink by replacing the downlink parameters ‘dl’ by the uplink
parameters ‘ul’.

• TransportCacCosConfPerPort::ulReservedBandwidthPercentage
• TransportCacCosConfPerPort::ulReservedBandwidthForEcAndHpaRabsPercentage
• SlaConfPerPor::egressCir
• SlaConfPerPor::ulStaticBandwidth
6.11.2.8 Interaction with Inter-frequency Load Balancing feature
Inter-frequency Load Balancing feature (ActivationService::isInterFreqLoadBalancingFeatureEnabled)

computes an overload state for the Transport Network Layer (TNL).
This overload state is named “UL/DL S1 TNL Load Indicator”.
It is calculated based on inputs that are provided by T-CAC per VLAN (or per port) and per CoS:
• Consummed Bandwidth
• Reserved Bandwidth
For the CoS that handles VoIP traffic, the Reserved Bandwidth is equal to the Extra Reserved
Bandwidth.
Inter-frequency Load Balancing feature consider the load of an inter-frequency target cell for
mobility purpose.
As example, the eNB may take into account the S1 load of its neighboring eNBs to determine
whether a neighboring is a candidate for offload.
Cell load exchange between eNBs is achieved through an X2 resource status procedure [3GPP 36.423]
which purpose is to request the reporting of load measurements from another eNB.
The types of load measurement to report are amongst;

• Radio Resource Status (DL/UL total/GBR/non-GBR PRB usages as percentages)
• Hardware Load Indicator (LowLoad, MediumLoad, HighLoad, Overload)
• Composite Available Capacity Group
• UL/DL S1 TNL Load Indicator (LowLoad, MediumLoad, HighLoad, Overload)
This procedure includes;

• Subscription for measurement (Resource Status Request/ Resource Status Response).
In the request message, the eNB indicates to the peer eNB the types of load measurement to report,
the cells to report, and the periodicity of report (provisioned at Enb:: x2ResourceReportPeriodicity).
• Periodic updated measurements (Resource Status Update).
The UL/DL S1 TNL Load Indicator is computed based on the eNB average S1 consumption level
compared to provisioned UL/DL load thresholds. If eNB average S1 consumption is below this
threshold then eNB sets the TNL Load Indicator to” LowLoad”, else it is set to “Overload”.

Only “LowLoad” and “Overload” load levels are implemented in this release.
The average S1 consumption level is calculated as the ratio of the S1 Consumption / S1 Reservation
over all CoS of all VLAN that handles S1-U traffic. There are possibly several VLANs if eUTRAN
sharing is activated.
 Plmn(i) 
 


∑
DL_CoS_Consumed_Bandwidth ( plmn(i ); Cos( x)) 

CoS(x)
Dl_ Average_S1_Consumption_Level =   *100
 Plmn(i) 


 CoS(x)
∑
DL_CoS_Reserved_Bandwidth ( plmn (i ); Cos ( x ))



 
The UL/DL load thresholds used to determine the UL/DL S1 TNL load provided to peer eNodeBs over
X2 are configured through:
• Object: Enb/EnbTransportConf/RanBackhaul,
Parameter: ulTransportLoadThreshold, Value: [0-100], Unit: %, Default: 10, Class: C, Service
Parameter: dlTransportLoadThreshold, Value: [0-100], Unit: %, Default: 10, Class: C, Service
Inter-frequency Load Balancing feature determines the “DL S1 TNL Load Indicator” as follows:
IF (ActivationService::isTranportCacAllowed is FALSE) THEN

/* Transport CAC is not enabled */
DL S1 TNL Load Indicator = “lowLoad”
ELSE
/* Transport CAC is enabled */
IF (Dl_Average_S1_Consumption_Level > RanBackhaul::dlTransportLoadThreshold) THEN
DL S1 TNL Load Indicator = “Overload”
ELSE DL S1 TNL Load Indicator = “lowLoad”
ENDIF
ENDIF
Same applies for “UL S1 TNL Load Indicator”.

6.12 X2 INTERFACE
An eNodeB may have multiple X2 interfaces.
Rule: <eNodeB> <X2> <Design>
eNodeB supports up to 32 peer eNodeB (or X2 interfaces).
6.12.1 Ethernet
Information on VLAN, Ethernet QoS and MTU is gathered in a dedicated chapter which addresses all
types of traffic (including X2 traffic) as well as eUTRAN sharing specificities.
6.12.2 IP
Information on IP routing and IP QoS is gathered in a dedicated chapter which addresses all types of
traffic (including X2 traffic) .
6.12.2.1 IP addressing
Peer eNodeB IP address for X2-C traffic is retrieved either from;

• the provisioned peer eNodeB IP address(es),
Error cases related to multi-homing:
When eNB uses MIM-defined IP addresses three mismatch cases between MIM data and SCTP
data can be detected at SCTP association setup:
1. A single IP address is configured for the X2 peer that reports two addresses at SCTP
association setup.
2. Two IP addresses are configured for the X2 peer that reports a single address at
SCTP association setup.
3. The X2 peer indicates more than two SCTP addresses (violates 3gpp TS 36.413).
Mismatches are reported to the operator using events. The intention is not to update the
eNB database but to report the mismatch to the operator. In any case SCTP runs with the
actual list of IP addresses since addresses are negotiated by the protocol, the error if any
lies in eNB configuration data. The SCTP association is not torn down by ALU eNB.
• ANR (Automatic Neighbouring Relation) procedure if activated. The IP address(es) is exchanged

via the messages eNodeB Configuration Transfer and MME Configuration Transfer to and from
eNodeB / peer eNodeB and MME. The IP address(es) are then configured dynamically and stored
in the MIM. A MIM synchronisation procedure ensures that SAM is informed.
Error cases related to multi-homing:
When eNB retrieves dynamically the IP address(es) of an X2 peer using S1-procedures the
peer eNB sends its IP address(es) via MME consequently there should not be any IP address
error.
Peer eNB IP address for X2-U traffic is retrieved during Handover procedure within the GTP Tunnel
Endpoint IE of the Handover Acknowledge message. 3GPP 36.423 – X2AP: “The GTP Tunnel Endpoint
IE identifies an X2 transport bearer or the S-GW endpoint of the S1 transport bearer associated to an
E-RAB. It contains a Transport Layer Address and a GTP Tunnel Endpoint Identifier. The Transport

Layer Address is an IP address to be used for the X2 user plane transport or for the S1 user plane
transport.”
IP addressing provisioning:
An instance of X2Access is generated per X2 interface.
For each peer eNodeB the IPv4 addressing configuration is done through:
• Object: Enb/X2AccessGroup/X2Access/X2TransportLayerAccess, Parameter: sctpAssocRemAddr,
Class: B, Service impact: Partial, Update transient impacts details: X2-interface
For each peer eNodeB the IPv6 addressing configuration is done through:
• Object: Enb/X2AccessGroup/X2Access/X2TransportLayerAccess, Parameter:
sctpAssocRemAddrIpv6, Class: B, Service impact: Partial, Update transient impacts details: X2-
interface
An alarmn ‘Inconsistent IP address / X2 (4007098)’ will be raised by an IPv6 eNodeB per peer IPv4
eNodeB. Operational impact is that the mismatch of IP version between 2 peers eNodeBs prevents
X2 HO between them.
eNB
X2AccessGroup
X2Access/n
X2TransportLayerAccess
sctpAssocRemAddr = 0 to 2 IPv4 @s
sctpAssocRemAddrIpv6 = 0 to 2 IPv6 @s
Figure 105: X2 SCTP – peer addressing - Model object for configuration
6.12.3 SCTP
eNodeB supports multi-homed peer-eNodeB and the provisioning of up to 2 IPv4 or IPv6 addresses
per peer-eNodeB.

Restriction: <eNodeB> <X2> <Design>
SCTP multihoming is not supported on eNodeB
6.12.3.1 Association and stream
Rule: <eNodeB> <X2> <Standard>
There must be only 1 SCTP association established between 2 peer eNodeBs. [3GPP TS 36.422]
Restriction: <eNodeB> <eUTRAN sharing> <Standard>
As a consequence of the rule above, in case of eUTRAN sharing, all operators use the same X2-C
SCTP connection between a eNodeB and its peer eNodeBs.
The X2-C traffic of the non master operators is sent on the telecom VLAN of the master operator.
Within the SCTP association established between 2 eNodeBs a single pair of stream identifiers is
used for X2 common procedures and a single pair of stream identifiers is used for X2 dedicated
procedures.
There are 2 streams within the X2 SCTP association:

• Stream 0 for the common signalling
• Stream 1 for the dedicated signalling
eNodeB source and destination SCTP port for X2 is specified in 3GPP TS 36.422.
IANA has defined the SCTP source and destination port supporting X2-AP traffic as = 36422. [3GPP
TS 36.422]
6.12.3.2 SCTP parameters for RTO calculation
Engineering: <eNodeB> <X2> <Recommended>
To prevent unnecessary retransmissions eNodeB sctpRTOMin must be higher than the round-trip
delay to the peer eNodeB + the SACK timer duration at the peer eNodeB.
The SCTP parameters for RTO calculation are configured through:
• Object: Enb/EnbTransportConf/GlobalTransportConf/CommonSctpLayerConf,
Parameter: sctpAlphaDivisor, Value: [1-10], Class: A, Service impact: Critical, Update transient
sctpAlphaDivisor value refers to the denominator of RFC 4960 RTO.alpha parameter, meaning
that RTO.alpha = 1/sctpAlphaDivisor

Parameter: sctpBetaDivisor, Value: [1-10], Class: A, Service impact: Critical, Update transient
sctpBetaDivisor value refers to the denominator of RFC 4960 RTO.beta parameter, meaning
that RTO.beta = 1/sctpBetaDivisor
• Object: Enb/EnbTransportConf/GlobalTransportConf/X2SctpLayerConf,
Parameter: sctpRTOInit, Value: [10-10000] ms (in 10 ms intervals), Class: B, Service impact:
Parameter: sctpRTOMin, Value: [10-10000] ms (in 10 ms intervals), Class: B, Service impact:
Parameter: sctpRTOMax, Value: [10-60000] ms (in 10 ms intervals), Class: B, Service impact:
Engineering: <eNodeB> <X2>
ALU default recommendation for SCTP parameters for RTO calculation:

sctpAlphaDivisor = 8
sctpBetaDivisor = 4
sctpRTOInit = 3000 ms
sctpRTOMin = 400 ms
sctpRTOMax = 1600 ms
6.12.3.3 Association establishment
An eNodeB can initiate the INIT procedure towards another eNodeB for establishing the SCTP
association. [3GPP TS 36.422]
The maximum number of retransmissions at sctp association establishment is configured through:

• Object: Enb/EnbTransportConf/GlobalTransportConf/X2SctpLayerConf, Parameter:
sctpAccessMaxInitRetransmits, Value: [0-255], Class: B, Service impact: Partial, Update transient
Default recommendation for the maximum number of retransmissions of the INIT (or COOKIE)
message at SCTP association establishment:
sctpAccessMaxInitRetransmits = 8
This is the default value as per IETF RFC 4960.
The maximum number of retries for re-establishing an association which is down is configured
through:
sctpAccessEstablishmentMaxRetries, Value: [0-255], Class: B, Service impact: Partial, Update
transient impacts details: Transport-Layers
The value 255 is interpreted as an infinite number of retries.
An association is terminated when the number of retransmission completes.

The interval between retries of sctp association establishment is configured through:

sctpAccessEstablishmentRetryInterval, Value: [0-1048575] (ms), Class: B, Service impact: Partial,
Default recommendation for SCTP association establishment:

sctpAccessEstablishmentMaxRetries = 255
sctpAccessEstablishmentRetryInterval = 30000
In case the neighboring eNodeB does not acknowledge the X2 association requests from the eNodeB
the alarm “X2 SCTP ASSOCIATION FAILURE” is raised.
6.12.3.4 SCTP acknowledgment
SCTP acknowledgement period is configured through:

• Object: Enb/EnbTransportConf/GlobalTransportConf/CommonSctpLayerConf, Parameter:
sctpSACKTimer, Value: [0-500] (ms), Class: B, Service impact: Partial, Update transient impacts
If sctpSACKTimer = 0 then eNodeB sends a SACK immediately on reception of a Data packet.
ALU default recommendation for SCTP SACK timer:

sctpSACKTimer = 0 ms
SCTP acknowledgement frequency is not configurable.

SCTP Acknowledgement frequency is set to 2.

If a 2nd packet is received before sctpSACKTimer expires then eNodeB sends a SACK.
6.12.3.5 X2 retransmission timer vs. SCTP retransmission timer
When the eNB sends an ‘X2 Setup Request’ message (resp. ‘X2 eNB Configuration Update’), it starts
an X2 timer. When there is no answer by the X2 timer expiration then the X2 message is retried.
Timer duration and number of retries are not configurable but hardcoded to the following values:
Timer duration between retry
# Retry
after initial after a retry
(if initial failed)
X2 Setup Request 8 2s
X2 eNB Configuration Update 2 3s 2s
The SCTP parameters ruling the SCTP association failure detection must be set consistently with
the hardcoded X2 timer value.
That is, SCTP setting must allow multiple SCTP chunks retransmission before ‘X2 Setup Request’
(resp. ‘X2 eNB Configuration Update’) message is retried.
To comply with this constraint, ALU default recommended values for parameters “sctpRTOMin”,
“sctpRTOMin”, “sctpAccessAssociationMaxRetrans” and “sctpAccessPathMaxRetrans” are:
• sctpRTOMin = 400 ms
• sctpRTOMax = 1600 ms
• sctpAccessAssociationMaxRetrans = 4
• sctpAccessPathMaxRetrans = 2
Another set of SCTP values may be used but it must be consistent with the X2 timer duration.
With the ALU recommended setting RTO.Min = 400 ms, RTO.Max = 1600 ms, and Path.Max.Retrans =
2;
• the 1st packet transmission failure has RTO = RTO.Min = 400 ms, the 1st retransmission has
RTO = 800 ms, the 2nd retransmission has RTO = 1600 ms (RTO doubles at each
retransmission, rounded down to RTOMax), etc...

• there are at least 2 SCTP retransmissions before the X2 message is retried given that min(X2
Setup Request timer; X2 eNB Configuration Update timer) = 2 s > 1,2 s (400+800 ms for 2
SCTP retries).
• the maximum duration before eNodeB reports that a SCTP path is down is equal to 2,8 s
(400+800+1600 ms)
eNB Peer eNB
t=0s
SCTP timer = 400 ms initial SCTP (initial ‘X2 Setup Request’)
t = 0,4 s X SCTP chunck lost
1st retry SCTP (initial ‘X2 Setup Request’)
SCTP timer = 2*400 ms
X SCTP chunck lost
t = 1,2 s
2nd retry SCTP (initial ‘X2 Setup Request’)
X2 timer = 2 s X SCTP chunck lost
t=2s
initial SCTP (1st retry ‘X2 Setup Request’)
Figure 106: X2 retransmission timer vs. SCTP retransmission timer
6.12.3.6 Failure detection
SCTP link failure detection is based on Heartbeat ACK’s and Data ACK’s monitoring.
Heartbeat mechanism configuration is done through:

sctpAssocHeartbeatInterval, Value: [0-1048575] (ms), Class: B, Service impact: Partial, Update
Default recommendation for SCTP heartbeat mechanism:

sctpAssocHeartbeatInterval = 1000
6.12.3.6.1 Path failure detection
Maximum number of retransmissions per SCTP path of Data and/or Heartbeat messages is done
through:


sctpAccessPathMaxRetrans, Value: [0-255], Class: B, Service impact: Partial, Update transient
Default recommendation for the maximum number of Data/Heartbeat retransmissions per path:
sctpAccessPathMaxRetrans = 2
For information, the default value as per IETF RFC 4960 is 5.
With the ALU recommended setting, the maximum duration before eNodeB reports that a SCTP path
is down is: RTO.Min= 0,4s / RTO.Max=1,6s / Path.Max.Retrans=2 => 0,4+0,8+1,6=2,8s
The first packet transmission failure has RTO = RTO.Min = 0,4s, the first retransmission has
RTO = 0,8s, the 2nd retransmission has RTO = 1,6s (RTO doubles at each retransmission, rounded
down to RTOMax).
6.12.3.6.2 Endpoint failure detection
Maximum number of total retransmissions of Data and/or Heartbeat messages is done through:
sctpAccessAssociationMaxRetrans, Value: [0-255], Class: B, Service impact: Partial, Update transient
Default recommendation for the maximum number of total Data/Heartbeat retransmissions:

sctpAccessAssociationMaxRetrans = 4
In case the X2 association between the eNodeBs is detected down then the corresponding GTP-U
tunnels are released and alarm “X2 SCTP ASSOCIATION DOWN” is raised.
For ensuring that eNodeB does not consider the peer is reachable while all paths are in failure
there must be verified that;
∑ sctpAccessPathMaxRetrans ≥ sctpAccessAssociationMaxRetrans
SCTP paths
6.12.3.6.3 Considerations for Path and Endpoint failure detection
There is a single managed object for X2 SCTP parameters in the MIM (X2SctpLayerConf). Hence it is
not possible to define different PMR/AMR values (Maximum number of SCTP Retransmissions per
Path/per Association) for cases with and without X2 multi-homing. The PMR/AMR values are to be
defined by OAM for the multi-homing case when the possibility exists that an ALU eNB be associated
with a multi-homed peer eNB at X2-C interface.

In case of multi-homing it is recommended that:

• sctpAccessAssociationMaxRetrans value is set to an even number, and
• sctpAccessPathMaxRetrans is set to sctpAccessAssociationMaxRetrans/2.
Given that Linux SCTP ignores the sctpAccessPathMaxRetrans value when an association is not multi-
homed these values also fit the case of non-multi-homed associations.
The rule above allows for a consistent handling in case there are mixity of ALU eNBs which don’t
support multihoming and other-vendor eNBs which support multihoming”; ALU eNBs run
sctpAccessAssociationMaxRetrans towards peers single-homed ALU eNBs, and
sctpAccessAssociationMaxRetrans/2 per path towards peers multi-homed other-vendor eNBs. The
total number of retransmissions is the same whatever the peer multihoming capability.
6.12.3.7 SCTP provisioning
eNB
EnbTransportConf
GlobalTransportConf
CommonSctpLayerConf
sctpSACKTimer = 0 (ms)
sctpBetaDivisor = 4
X2SctpLayerConf
sctpAccessEstablishmentRetryInterval = 30000 (ms)
sctpAssocHeartbeatInterval = 1000 (ms)
sctpRTOInit = 3000 (ms)
sctpRTOMin = 400 (ms)
sctpRTOMax = 1600 (ms)
Figure 107: X2 SCTP - Model object for configuration
6.12.4 GTP
A GTP path exists between the eNodeB and each of its peer eNodeB with which a GTP tunnel is
established.

As per standard TS 29.281, the GTP echo mechanism is not implemented on X2 interface.
6.13 S1 INTERFACE
The eNodeB supports SCTP associations with multiple MME’s in support of S1-Flex topology.
The SCTP protocol associations are permanently established at the eNodeB start-up.
After successful set up of SCTP association, eNodeB sends S1 Set up message to exchange
application data needed for eNodeB and MME to inter-operate correctly on the S1 interface.
At call admission the eNodeB call processing defines which MME supports each call.
Rule: <eNodeB> <S1> <Design>
eNodeB supports up to 16 peer MMEs (or S1-MME interfaces).
6.13.1 Ethernet
types of traffic (including S1 traffic) .
6.13.2 IP
traffic (including S1 traffic).
eNodeB establishes SCTP association using a provisioned MME IP address.

eNodeB learns the S1-U IP address for each bearer in S1-AP messages (Initial Context Setup, ERAB
Setup/Modify/Release Request).
Peer MME IPv4 addressing configuration is done through:

• Object: Enb/S1AccessGroup/MmeAccessGroup/MmeAccess/MmeTransportLayerAccess,
Parameter: sctpAssocRemAddr, Value: list of 2 IP addresses, Class: B, Service impact: Partial,
Update transient impacts details: S1-interface
Engineering: <eNodeB> <S1>
Multi-homed MME is supported with up to 2 IPv4 or IPv6 addresses.
Restriction: <eNodeB> <S1> <Design>
Only 2 MME IPv4 or IPv6 addresses are supported for multi-homed MME.
Note: in the MIM there is the erroneous information that 4 MME IP addresses may be provisionned.

• Object: Enb/S1AccessGroup/MmeAccessGroup/MmeAccess/MmeTransportLayerAccess,
Parameter: sctpAssocRemAddrIpv6, Value: list of 2 IP addresses, Class: B, Service impact: Partial,
Update transient impacts details: S1-interface
eNB
S1AccessGroup
MMEAccessGroup
MMEAccess/n
plmnId
MmeTransportLayerAccess
Figure 108: S1 SCTP – peer addressing - Model object for configuration
In case of MOCN, the IP addresses of the MMEs are configurable per operator in the eNodeB.
Each operator can be connected to up to 16 MMEs (either IPv4 or IPv6).

eNodeB can be connected to up to 32 MMEs whatever the number of operators sharing the eNodeB.
Even in case of GWCN, at eNB provisioning an MME shared between several operators is associated
with only one of the operators sharing this MME.
The provisioning of the complete list of operators sharing an MME is useless at eNodeB.
Rule: <eNodeB> <eUTRAN sharing> <Standard>
As per S1AP specification [3GPP TS 36.413], eNB learns the list of the PLMNs supported by an MME
from the S1 SETUP REPONSE sent by the MME.
When the selection of the serving MME for a UE is performed after RRC Connection is completed, all
PLMN identities that are supported by connected MMEs are considered.
SGW sharing does not impact eNB provisioning as the IP address of the SGW to which a bearer has to
be established is provided dynamically by the MME.

6.13.2.2 Multiple eNodeBs having same IP address
It is supported to have multiple eNodeBs with the same S1 address. The eNodeBs are uniquely
referenced by the combination of S1 IP address and port number.
6.13.3 SCTP
eNodeB supports multi-homed MME and the provisioning of up to 2 IPv4 or IPv6 addresses per MME.
In case of eUTRAN sharing, the same parameters setting of the SCTP stack apply to all operators.
Those parameters are those defined in RCF 4960 and configured under ‘MmeSctpLayerConf’ object.
Rule: <eNodeB> <S1> <Standard>
There must be only 1 SCTP association established between an eNodeB and an MME. [3GPP TS
36.412]
In case of MOCN, the S1-MME SCTP connections between an eNodeB and the MMEs are per operator
(as each operator manages its own core network).
In case of GWCN with MME sharing, a single S1-MME SCTP connection is setup between eNodeB and
the shared MME [3GPP TS 36.412]. Thus, the traffic type “S1c” must be configured for only one of
the operators amongst those sharing the MME. Others operators’ S1-MME traffic is transported over
the VLAN of the operator that has been provisioned with the “S1c” traffic type.
S1-MME SCTP associations are initiated by eNodeB via INIT message sent from eNodeB.
Within the SCTP association established between an eNodeB and an MME a single pair of stream
identifiers is used for S1 common procedures and a single pair of stream identifiers is used for S1
dedicated procedures.

There are 2 pairs of streams within the S1 SCTP association:

eNodeB destination SCTP port for S1 is specified in 3GPP TS 36.412.
Rule: <eNodeB> <S1> <Standard>
IANA has defined the SCTP destination port supporting S1-AP traffic as = 36412. [3GPP TS 36.412]
eNodeB’s local port is set by the operating system, it is not provisionned.
Note: in the MIM there is the parameter maxHoldOffTimeForS1Reestablishment at eNB object. This
parameter is not used in this release. SCTP parameters for RTO calculation
Engineering: <eNodeB> <S1> <Recommended>
To prevent unnecessary retransmissions eNodeB sctpRTOMin must be higher than the round-trip
delay to the peer MME + the SACK timer duration at the peer MME.

• Object: Enb/EnbTransportConf/GlobalTransportConf/CommonSctpLayerConf,
Parameter: sctpAlphaDivisor, Value: [1-10], Class: A, Service impact: Critical, Update transient
sctpAlphaDivisor value refers to the denominator of RFC 4960 RTO.alpha parameter, meaning
that RTO.alpha = 1/sctpAlphaDivisor
Parameter: sctpBetaDivisor, Value: [1-10], Class: A, Service impact: Critical, Update transient
sctpBetaDivisor value refers to the denominator of RFC 4960 RTO.beta parameter, meaning
that RTO.beta = 1/sctpBetaDivisor
• Object: Enb/EnbTransportConf/GlobalTransportConf/MmeSctpLayerConf,
Parameter: sctpRTOInit, Value: [10-10000] ms (in 10 ms intervals), Class: B, Service impact:
Parameter: sctpRTOMin, Value: [10-10000] ms (in 10 ms intervals), Class: B, Service impact:
Parameter: sctpRTOMax, Value: [10-60000] ms (in 10 ms intervals), Class: B, Service impact:

ALU default recommendation for SCTP parameters for RTO calculation:

sctpBetaDivisor = 4
sctpRTOInit = 3000 ms
sctpRTOMin = 400 ms
sctpRTOMax = 1600 ms
With the RFC 4960 default recommended setting, the maximum duration before SCTP reports that a
SCTP path is down is:
RTO.Min= 1s / RTO.Max=60s / Path.Max.Retrans=5 => 1+2+4+8+16+32=63s
The first packet transmission failure has RTO = RTO.Min = 1s, the first retransmission has RTO = 2s,
the fifth retransmission has RTO = 32s
This aggregate time is a considerable time to detect a failure of a path and invoke a switchover to
an alternate path in a multi-homed environment. Potentially, the association could be torn-down
before a switchover is invoked.
The eNodeB establishes the SCTP association.[3GPP TS 36.412]

• Object: Enb/EnbTransportConf/GlobalTransportConf/MmeSctpLayerConf, Parameter:
sctpAccessMaxInitRetransmits, Value: [0-255], Class: B, Service impact: Partial, Update transient

The maximum number of retries for re-establishing an association which is down is configured
through:
sctpAccessEstablishmentMaxRetries, Value: [0-255], Class: B, Service impact: Partial, Update
The value 255 is interpreted as an infinite number of retries.
An association is terminated when the number of retransmission completes.
The interval between retries of sctp association establishment is configured through:

sctpAccessEstablishmentRetryInterval, Value: [0-1048575] (ms), Class: B, Service impact: Partial,


sctpAccessEstablishmentRetryInterval = 30000
In case the neighboring MME does not acknowledge the S1 association requests from the eNodeB the
alarm “S1 SCTP ASSOCIATION FAILURE” is raised (major with S1 flex or critical without S1 flex).
SCTP acknowledgement period is configured through:

• Object: Enb/EnbTransportConf/GlobalTransportConf/CommonSctpLayerConf, Parameter:
sctpSACKTimer, Value: [0-500] (ms), Class: B, Service impact: Partial, Update transient impacts
If sctpSACKTimer = 0 then eNodeB sends a SACK immediately on reception of a Data packet.
ALU default recommendation for SCTP SACK timer:

sctpSACKTimer = 0 ms
SCTP acknowledgement frequency is not configurable.

SCTP Acknowledgement frequency is set to 2.

If a 2nd packet is received before sctpSACKTimer expires then eNodeB sends a SACK.
6.13.3.5 S1 retransmission timer vs. SCTP retransmission timer
When the eNB sends an ‘S1 Setup Request’ message (resp. ‘S1 eNB Configuration Update’), it starts
an S1 timer. When there is no answer by the S1 timer expiration then the S1 message is retried.
Timer duration and number of retries are not configurable but hardcoded to the following values:
Timer duration between retry
# Retry
after initial after a retry
(if initial failed)
S1 Setup Request 2 2s
S1 eNB Configuration Update 2 2s
The SCTP parameters ruling the SCTP association failure detection must be set consistently with
the hardcoded S1 timer value.
That is, SCTP setting must allow multiple SCTP chunks retransmission before ‘S1 Setup Request’
(resp. ‘S1 eNB Configuration Update’) message is retried.
To comply with this constraint, ALU default recommended values for parameters “sctpRTOMin”,
“sctpRTOMin”, “sctpAccessAssociationMaxRetrans” and “sctpAccessPathMaxRetrans” are:
• sctpRTOMin = 400 ms
• sctpRTOMax = 1600 ms
• sctpAccessAssociationMaxRetrans = 4
• sctpAccessPathMaxRetrans = 2
Another set of SCTP values may be used but it must be consistent with the S1 timer duration.
With the ALU recommended setting RTO.Min = 400 ms, RTO.Max = 1600 ms, and Path.Max.Retrans =
2;
• the 1st packet transmission failure has RTO = RTO.Min = 400 ms, the 1st retransmission has
RTO = 800 ms, the 2nd retransmission has RTO = 1600 ms (RTO doubles at each
retransmission, rounded down to RTOMax), etc...

• there are at least 2 SCTP retransmissions before the S1 message is retried given that min(S1
Setup Request timer; S1 eNB Configuration Update timer) = 2 s > 1,2 s (400+800 ms for 2
SCTP retries).
• the maximum duration before eNodeB reports that a SCTP path is down is equal to 2,8 s
(400+800+1600 ms)
eNB Peer MME
t=0s
SCTP timer = 400 ms initial SCTP (initial ‘S1 Setup Request’)
t = 0,4 s X SCTP chunck lost
1st retry SCTP (initial ‘S1 Setup Request’)
SCTP timer = 2*400 ms
X SCTP chunck lost
t = 1,2 s
2nd retry SCTP (initial ‘S1 Setup Request’)
S1 timer = 2 s X SCTP chunck lost
t=2s
initial SCTP (1st retry ‘S1 Setup Request’)
Figure 109: S1 retransmission timer vs. SCTP retransmission timer
eNodeB uses the SCTP heartbeat mechanism for detecting S1-MME link failure in case of eNodeB or
MME or S1-MME path failure.
If SCTP is detected down then eNodeB will release RRC connections, delete UEs contexts and
release GTP-U tunnels for all UEs associated with the S1-MME link in failure.
Heartbeat mechanism configuration is done through:

sctpAssocHeartbeatInterval, Value: [0-1048575] (ms), Class: B, Service impact: Partial, Update

sctpAssocHeartbeatInterval = 1000

Maximum number of retransmissions per SCTP path of Data and/or Heartbeat messages is done
through:
sctpAccessPathMaxRetrans, Value: [0-255], Class: B, Service impact: Partial, Update transient
With the ALU recommended setting, the maximum duration before eNodeB reports that a SCTP path
is down is: RTO.Min= 0,4s / RTO.Max=1,6s / Path.Max.Retrans=2 => 0,4+0,8+1,6=2,8s
The first packet transmission failure has RTO = RTO.Min = 0,4s, the first retransmission has
RTO = 0,8s, the 2nd retransmission has RTO = 1,6s (RTO doubles at each retransmission, rounded
down to RTOMax).
Maximum number of total retransmissions of Data and/or Heartbeat messages is done through:
sctpAccessAssociationMaxRetrans, Value: [0-255], Class: B, Service impact: Partial, Update transient

In case the S1 association between the eNodeBs is in fault the alarm “S1 SCTP ASSOCIATION DOWN”
is raised (major with S1 flex or critical without S1 flex).
For ensuring that eNodeB does not consider the peer is reachable while all paths are in failure
there must be verified that;
∑ sctpAccessPathMaxRetrans ≥ sctpAccessAssociationMaxRetrans
SCTP paths

eNB
EnbTransportConf
GlobalTransportConf
CommonSctpLayerConf
sctpSACKTimer = 0 (ms)
sctpBetaDivisor = 4
MmeSctpLayerConf
sctpAccessEstablishmentRetryInterval = 30000 (ms)
sctpAssocHeartbeatInterval = 1000 (ms)
sctpRTOInit = 3000 (ms)
sctpRTOMin = 400 (ms)
sctpRTOMax = 1600 (ms)
Figure 110: S1 SCTP - Model object for configuration
6.13.4 GTP
A GTP path exists between the eNodeB and the SGW with which a GTP tunnel is established.
A GTP path verification is provided using GTP Echo and Response messages.
GTP Echo Requests has a TEID of 0.
GTP echo mechanism is used on S1 interface.
After a failure is reported, eNodeB resets the failure count and continues sending Echo Requests.
On the first successfully received Echo Response after a failure, eNodeB notifies OAM with a
message indicating a recovery.
In order to process GTP Echo Requests, eNodeB listens on a UDP socket bound to the eNodeB’s
telecom IP address for traffic destined for the GTP port (port # 2152, as specified by TS 29.281).
In response to GTP Echo Requests received eNodeB builds a GTP Echo Response and sends it to the
source IP and UDP port that it came from.
GTP echo mechanism configuration is done through:
• Object: Enb/S1AccessGroup/SgwAccessGroup/SgwGtpConf,

Parameter: s1EchoRequestInterval, Value: [0-600], (with step = 10), Unit: second, Class: C,
Parameter: t3Response, Value: [1-5], Class: C, Service Impact: None, Update transient impacts
Parameter: n3Request, Value: [1-10], Class: C, Service Impact: None, Update transient impacts
For each active path on the S1-U interface a GTP Echo Request is sent every s1EchoRequestInterval
seconds.
If an Echo Response is not received within t3Response seconds (it is late or lost) then the Echo
Request is considered a failure.
After n3Request consecutive Echo Request failures eNodeB notifies OAM with message indicating a
failure.
Default recommendation for GTP echo mechanism:

s1EchoRequestInterval = 120 (1)
t3Response = 3
n3Request = 5
(1) Normal value should be > 60 s. Value 0 disables the sending of echo request.
With the default recommended setting, the time before GTP echo reports that GTP-U path is down
is: 120 + 3 x 5 = 135s
A value of s1EchoRequestInterval = 0 disables the GTP-U Echo request sending procedure.

Note: this stops both GTP-U Echo request sending and receiving procedures.
eNB does not support GTP-u error handling. That is, in case of path failure eNB does not release
the eRABs associated to the path in failure.
6.14 IEEE 1588V2 INTERFACE

The grandmaster of choice for ALU is the Symmetricom TP5000 server.
Restriction: <TP5000> <IEEE1588> <Design>
Symmetricom TP5000 server only supports PTP over UDP/IP/Ethernet.

Rule: <eNodeB> <IEEE1588> <Design>
Frequency, phase and Time of Day synchronization are supported by eNodeB PTP implementation in
FDD and TDD.
eNB synchronization requirement is done through:

• Object: Enb/ClockSync, Parameter: sfnSyncOption, Value : [FreqSyncOnly,
FreqAndPhaseSyncEnabled, FreqAndPhaseAndTimeOfDaySyncEnabled]; Class: A, Service impact:
eNodeB supports to be synchronized with a grandmaster which has its reference time source
retrieved either from a GPS signal or an E1 signal.
In its Announce messages, the grandmaster feeds the following information about its clocking:
• the reference time source (timeSource)
• the clock traceability (grandmasterClockQuality.clockClass)
• the clock accuracy (grandmasterClockQuality.clockAccuracy)
eNodeB synchronizes with a grandmaster at condition that the grandmasterClockQuality is within

the following values;
timeSource clockClass clockAccuracy
0x20 25ns
_20 GPS 6 primary reference clock 0x21 100ns
0x22 250ns
_60 E1 13 application-specific clock 0xFE unknown
clockClass is set to 7 (or 14) when there is an issue with the GPS (or E1) reference.
In case the grandmasterClockQuality does not match the table above, then the eNodeB does not
use the PTP source as its reference (until the grandmaster clock quality is restored).
PTP may be transported over IP (PTP/UDP/IP/Eth) or over Ethernet (PTP/Eth).
eNB PTP protocol stack selection is done through:
• Object: Enb/ClockSync/PTPClientClockSync, Parameter: ptpStackMode, Value :

[PTPoverUDPoverIP, PTPoverEthernet];Class: C; Service Impact: None, Update transient impacts

eNB supports PTP Unicast as well as PTP Multicast mode of operation.
Recommendation ITU-T G.8261.1/Y.1361.1 depicts synchronization aspects in packet networks

(Frequency synchronization). In particular, it specifies the hypothetical reference model and the
PDV network limits applicable when frequency synchronization is carried via packets.
Rule: <eNodeB> <IEEE1588> <Standard>
For 1588 packet timing FREQUENCY delivery , as per ITU-T G.8261.1 section 8 ‘PDV Network
Limit’, the maximum permissible levels of packet delay variation for Hypothetical Reference
Model-1 (Metro ethernet) that the network must deliver is such that: more than 1% of SYNC timing
packets must arrive within 150us of the link floor-delay over a 200s window.
For 1588 packet timing PHASE delivery, ITU-T G.827x recommends a network design where each
transport equipment between the Grandmaster server and the 1588 client is 1588 aware, and
locally compensates for the variable latency it introduces onto the timing packets.
This is called On-Path Support, and has 2 variants – Transparent Clock and Boundary Clock.
ITU-T only consider the use of Boundary Clock, and reject the use of Transparent Clock. Boundary
Clock requires each Transport element to include a 1588 client which recovers the Sync Clock,
which is then used as the reference for a 1588 Master function.
This means there is only one hop between the end-client and its 1588 Master peer. So the PDV is
low, and so an SLA is not so important.
6.14.1 Hardware
The eNodeB PTP client communicates with the PTP server(s) on a single physical port.
eCCM vs. eCCM2 1588 algorithm differencies:
1588 algorithm Time stamping
eCCM Zarlink Zarlink ZL30320 IC
eCCM2 Bell Labs WinPath3
6.14.2 Ethernet
Information on VLAN and Ethernet QoS is gathered in a dedicated chapter which addresses all types
of traffic (including PTP traffic).

Engineering: <eNodeB> <IEEE1558 >
Since the 1588 traffic occupies the same vlan as OAM traffic, and all eNodeB traffic is supported on
the same physical link, there is a ‘risk’ of interaction between traffic flows (e.g. OMC download of
class ‘C’ parameters) increasing PDV impairments. This must be mitigated by ensuring 1588 packets
have higher priority qos marking than OAM packets.
eNodeB supports PTP over Ethernet.
6.14.2.1 MAC addressing – Unicast mode
In case of PTP over Ethernet in Unicast mode, the MAC address of eNB peer Primary Server is done
through:
• Object: Enb/ClockSync/PTPClientClockSync, Parameter: ptpPrimaryServerMACAddress, Value :
[xx-xx-xx-xx-xx-xx]; Class: C; Service Impact: None, Update transient impacts details: Immediate-
propagation
In case of PTP over Ethernet in Unicast mode, the MAC address of eNB peer Secondary Server is
done through:
• Object: Enb/ClockSync/PTPClientClockSync, Parameter: ptpSecondaryServerMACAddress, Value :
[xx-xx-xx-xx-xx-xx]; Class: C; Service Impact: None, Update transient impacts details: Immediate-
propagation
If there is no Secondary Master, this is set to ‘00-00-00-00-00-00’.
The MAC address of the active peer Grandmaster when in PTP over Ethernet in Unicast mode is
accessible through the Read Only parameter: ‘PTPClientClockSync::ptpActiveMACGrandmaster’.
6.14.2.2 MAC addressing – Multicast mode
Rule: <eNodeB><IEEE1588> <Standard>
In case of PTP over Ethernet in Multicast mode, the Multicast MAC address for PTP messages
generated and received by eNB is defined in IEEE1588 Annex D as: 01-1B-19-00-00-00.
Note: in Multicast mode Primary and Secondary peers have the same Multicast MAC address, and so
they can’t be differentiated through parameter: ‘PTPClientClockSync::ptpActiveMACGrandmaster’.
6.14.2.3 Ethernet QoS
PTP traffic Pbit setting is ruled by a dedicated parameter that:
- in case of PTPoIP, allows to dissociate the Pbit setting policy for PTP from that set through
parameter pBitSettingEnable which applies for all eNB traffic
- in case of PTPoEth, allows in a ‘no Vlan’ topology to activate the Pbit setting for PTP
eNB PTP over Ethernet tag mode is done through:

• Object: Enb/ClockSync/PTPClientClockSync, Parameter: ptpOverEthernetTagEnable, Value:

[true, false]; Class: C; Service Impact: None, Update transient impacts details: Immediate-
propagation
PTP Pbit usage is ruled as follows:
ptpStackMode L2 topology pBitSettingEnable ptpOverEthernetTagEnable Pbit set for PTP ?
(2)
True Yes
True
False No
Vlan
ptpOverEthernet True Yes
or False
PTPoverUDPoverIP False No
(3)
True Yes
(4) (1)
No Vlan N.A.
False No
(1): ‘no Vlan’ is achieved by setting VlanId=4096, and it means eNB does not insert Tag fields at
egress Ethernet frames => pBitSettingEnable parameter cannot control Pbit presence.
(2): Pbit is derived from provisioned PTP DSCP
(3): Pbit is derived from provisioned PTP DSCP that would be used if PTP was over IP. Note: VID=0.
(4): no Vlan topology for PTP may be configured for MCO, not for Macro.
6.14.3 IP
traffic (including PTP traffic).
The 1588 link from server to eNodeB should minimize the number of layer 3 hops since the
forwarding algorithms of intermediate transport equipment introduce Packet Delay Variation (PDV),
which must be bounded for the 1588 synchronization process to reliably deliver in-spec frequency
synchronization.
The affordable maximum number of hop between the eNodeB and the server also depends on the
traffic load in the backhaul.
Restriction: <TP5000> <IEEE1588> <Design>
For DL 1588 traffic, the Symmetricom TP5000 server cannot differentiate the QoS of event
messages and general messages. They are tagged with the same DSCP and Pbits values
(respectively EF and 6).
6.14.3.1 IPv4 addressing – Unicast mode
The eNodeB PTP IP address is configured through:


ipv4Address, Class: A, Service impact: Critical, Update transient impacts details: full-eNB-reset
Restriction: <eNodeB> <IEEE1588> <Standard>
eNodeB PTP IP address must be a dedicated IP address.

As example, it can not be the same IP address as the OAM IP address.
The eNodeB is configured with the IP addresses of both a primary and a secondary grandmaster.
The IP address of the primary PTP server is configured through:

• Object: Enb/ClockSync/PTPClientClockSync, Parameter: ptpPrimaryServerIPaddress, Class: C,
The IP address of the secondary PTP server is configured through:

• Object: Enb/ClockSync/PTPClientClockSync, Parameter: ptpSecondaryServerIPaddress, Class: C,
Engineering: <eNodeB> <IEEE1588>
If there is no secondary PTP server within the network then ptpSecondaryServerIPaddress must be
set to 0.0.0.0
6.14.3.2 IPv4 addressing – Multicast mode
In case of PTP over IPv4 in Multicast mode, IANA has assigned the IPv4 Multicast address
224.0.1.129 for all PTP generated and received messages except peer delay and 224.0.0.107 for
peer delay mechanism. See IEEE1588 Annex D.
6.14.3.3 IPv6 addressing – Unicast mode
Restriction: <eNodeB> <IEEE1588> <Design>
1588v2 over IPv6 is only supported for FDD (not for TDD).
The eNodeB PTP IP address is configured through:

ipv6Address, Class: A, Service impact: Critical, Update transient impacts details: full-eNB-reset
Restriction: <eNodeB> <IEEE1588> <Standard>
eNodeB PTP IP address must be a dedicated IP address.
As example, it can not be the same IP address as the OAM IP address.

The eNodeB is configured with the IP addresses of both a primary and a secondary grandmaster.
The IP address of the primary PTP server is configured through:

• Object: Enb/ClockSync/PTPClientClockSync, Parameter: ptpPrimaryServerIPv6Address, Class: C,
The IP address of the secondary PTP server is configured through:

• Object: Enb/ClockSync/PTPClientClockSync, Parameter: ptpSecondaryServerIPv6Address, Class:
If there is no secondary PTP server within the network then ptpSecondaryServerIPv6Address must
be set to 0:0:0:0:0:0:0:0
6.14.3.4 IPv6 addressing – Multicast mode
PTP over IPv6 in Multicast mode is not supported.
PTP over IPv6 in Unicast mode only is supported.
6.14.4 UDP
eNodeB supports PTP over UDP/IP/Ethernet.
eNodeB listening/sending UDP port for PTP is specified in IEEE1588.
IANA has defined the UDP port supporting PTP traffic as:
319 for an event message
320 for a general message
6.14.5 PTP
1588v2 PTP configuration is done through:

• Object: Enb/ClockSync, Parameter: ptpClientEnable, Value: enabled/disabled, Class: A, Service
• Object: Enb/ClockSync, Parameter: clockSyncSourcePriorityList, Value: externally-synchronized-
mode-2-ptp1588, Class: C, Service Impact: None, Update transient impacts details: Immediate-
propagation

Note: clockSyncSourcePriorityList values are [free-running-internal-oscillator (0), gps-synchronised-

gps (1), externally-synchronised-mode-1-synce (2), externally-synchronised-mode-2-ptp1588 (3),
externally-synchronised-mode-3-ext-clock (4), externally-synchronised-mode-4-satellite (5), clock-
master-bs (6), externally-synchronised-mode-5-1PPSAndTOD(7), externally-synchronised-mode-6-
synceAndptp1588 (8)]
eNodeB PTP client acts as an ordinary clock.
eNodeB PTP client is based on the Zarlink ZL31320 device.
eNB supports Unicast or Multicast mode of operation.

No mixity of UL unicast PTP traffic and DL multicast PTP traffic is supported.
eNB PTP mode of operation is done through:
• Object: Enb/ClockSync/PTPClientClockSync, Parameter: ptpClientMode, Value : [Unicast,

Multicast]; Class: C; Service Impact: None, Update transient impacts details: Immediate-propagation
The eNodeB supports the following PTP messages:
Event messages General messages
Announce server client

Follow up server client
Sync server client
Delay resp server client
Delay req server  client
Management server client
Signaling server client
The eNodeB supports both the one-step and the two-step methods, i.e. timestamp exchange
without or with the Follow up message sent by the master. The eNodeB Zarlink client algorithm
automatically adapts to either method.
The Delay req/resp messaging is activated at eNodeB. This is not configurable.
The eNodeB requested duration for Sync messages is configured through:

• Object: Enb/ClockSync/PTPClientClockSync, Parameter: ptpSyncDuration, Value: [1-2047], Unit:
second, Class: C, Service Impact: None, Update transient impacts details: Immediate-propagation

Default recommended setting for Sync duration:

ptpSyncDuration = 300
This is the IEEE1588 default value for Sync duration.
Sync interval configuration is done through:

• Object: Enb/ClockSync/PTPClientClockSync, Parameter: ptpLogSyncInterval, Value: [-128 to
+127] , Class: C, Service Impact: None, Update transient impacts details: Immediate-propagation
Default recommended setting for Sync interval:

ptpLogSyncInterval = -6
1
That is a Sync message rate of = 64 Sync messages per second.
-6
2
The eNodeB requested duration for Announce messages is configured through:

• Object: Enb/ClockSync/PTPClientClockSync, Parameter: ptpAnnounceDuration, Value: [1-2047],
Unit: second, Class: C, Service Impact: None, Update transient impacts details: Immediate-
propagation
Default recommended setting for Announce duration:

ptpAnnounceDuration = 300
This is the IEEE1588 default value for Announce duration.
Zarlink client API delivers a single duration element which is based on ptpSyncDuration.
The ptpAnnounceDuration parameter is not used by Zarlink client.
Announce interval configuration is done through:

• Object: Enb/ClockSync/PTPClientClockSync, Parameter: ptpLogAnnounceInterval, Value: [-128 to
+127], Class: C, Service Impact: None, Update transient impacts details: Immediate-propagation

There must be verify that: ptpLogSyncInterval < ptpLogAnnounceInterval
Default recommended setting for Announce interval:

ptpLogAnnounceInterval = 1
1
That is an Announce message rate of = 1 Announce message every 2 seconds.
1
2
ptpSyncDuration is used both for Sync and Delay resp
Delay req interval configuration is done through:

• Object: Enb/ClockSync/PTPClientClockSync, Parameter: ptpLogMinDelayReqInterval, Value: [-
128 to +127], Class: C, Service Impact: None, Update transient impacts details: Immediate-
propagation
As per IEEE 1588 standard: The ‘ptpLogMinDelayReqInterval’ value shall be an integer with the
minimum value being portDS.logSyncInterval, i.e., at the same rate as Sync messages, and a
maximum value of logSyncInterval+5.
It must be verified that:
ptpLogSyncInterval ≤ ptpLogMinDelayReqInterval ≤ ptpLogSyncInterval + 5
With default logSyncInterval = -6 then -6 ≤ ptpLogMinDelayReqInterval ≤ -1
This is a minimum ratio of 1 Delay req message every 32 Sync messages.
Default recommended setting for Delay req interval:

ptpLogMinDelayReqInterval = -4
1
That is a message rate of = 16 Delay req message per second.
-4
2
This is a ratio of 1 Delay req message every 4 Sync messages.

The inter message period (logInterMessagePeriod) between Request Unicast Transmission messages
(for Sync, Announce or Delay resp) is a tradeoff between eNB requested value and GM granted
value.
At the 1st sent Request Unicast Transmission:
• eNB requests for a logInterMessagePeriod = ptpSyncDuration
• starts timer for triggering the next (2nd)unicast negociation to δ = ptpSyncDuration – 30 s
At reception of the 1st Grant Unicast Transmission and if granted logInterMessagePeriod < requested
logInterMessagePeriod then eNB:
• stops timer
• re-starts timer to δ = granted logInterMessagePeriod – 30 s
At timer expiration, eNB sends the 2nd Request Unicast Transmission:
• eNB requests for a logInterMessagePeriod = ptpSyncDuration
• re-starts timer for triggering the next (3rd) unicast negociation to same previous δ.
And so on. The 30 s margin is to ensure there are no gaps in the packet timing stream (in particular
Sync). eNB sends the next Request Unicast Negotiation 30 s before the previous 'lease' times out.
This offers opportunity to do multiple requests if messages are lost or errored.
6.14.5.1 Unicast mode
The eNodeB supports a proprietary mechanism for delaying the transmission of the first Request
Unicast Transmission message by a random offset of 0 to ptpSyncDuration with a 100 ms
granularity.
The first eNodeB Request Unicast Transmission message is the first one after the eNodeB is up.
This is for ensuring the PTP master is not flooded by simultaneous Request Unicast Transmission
messages in the case a cluster of eNodeBs is setup at once.

Master Slave
clock clock
eNodeB power-up/reset
t0 : eNodeB PTP client is ready
δt = random delay
t0 + δt : first Request unicast transmission
Sync logInterMessagePeriod
logMessageInterval
durationField Sync
Sync
t0 + δt + logInterMessagePeriod :
repetition of Request unicast transmission
Figure 111: Initial Request Unicast Transmission – ALU implementation
The usage of the offset delay is done through:

• Object: Enb/ClockSync/PTPClientClockSync, Parameter: ptpClientRegToD, Value: [0:00:00 –
00:05:59.90], format is (hh:mm:ssss), Class: C, Service Impact: None, Update transient impacts
The maximum value (00:05:59.90) is for disabling the mechanism.
Any other value is for enabling the mechanism.
6.14.5.2 Multicast mode
Use of Multicast saves the UL/DL bandwidth for periodic Unicast negotiation messages and limits the
DL bandwidth requirements of the 1588v2 messages. The benefit is especially for the backhaul
network while for the final hop to the eNB there is little bandwidth saving.
The drawback is that UL multicast messages from a eNB are broadcast to all other eNB on the LAN,
as well as to the master server.

As in Multicast mode there is no negotiation for message rates, the eNB accepts the message rates
offered by the peer Grandmaster(resp. Boundary Clock).
eNB identifies itself with its clockIdentity that is set in the SourcePortIdentity field.
The ClockIdentity is a 8 bytes identifier built from the 6 bytes of the eNB MAC address to which are
added the 2 bytes “FF FE” in the centre.
The client algorithm only processes messages with the correct ClockIdentity.
Eg. When the eNB transmits a Delay_Req to the GM (resp. BC), it inserts its unique
SourcePortIdentity in the message. The GM (resp. BC) places it back in the Delay_Resp message as
the RequestingPortIdentity field. Therefore even though the messages are multicast to all clients,
the target client captures its own data by comparing its SourcePortIdentity to the
RequestingPortIdentity field in the incoming message.
6.14.5.3 PTP server redundancy
When an alternate grandmaster is installed (optional) the Zarlink client exchanges Sync and Delay
req/resp messaging with both grandmasters. Though only the synchronization messaging with the
primary master is used for synchronizing the eNodeB clock.
eNodeB PTP client exchanges timestamp also with the secondary grandmaster.
The secondary grandmaster is said in warm standby allowing for a quicker switchover in case of
failure of the primary master.
The failure of the primary grandmaster is detected by eNodeB Zarlink client in case of;
• loss of lock to received Sync messages, or
• loss of Sync messages, or
• loss of Announce messages
Zarlink client consideres there is a loss of Sync (Announce) messages when the percentage of
received Sync (Announce) messages is below 50% of the configured Sync (Announce) message rate.
Sync (Announce) message rate is provisionned with ptpLogSyncInterval (ptpLogAnnounceInterval).
An alarm “1588 loss primary server” is raised

This alarm indicates the loss of synchronization from the primary server.
The eNodeB fallbacks in the following priority to:

• secondary PTP server if exists
• another clock reference source if available
• internal clock
The switchover from the primary grandmaster to secondary grandmaster is non revertive.
If the failure of the secondary grandmaster is detected by eNodeB Zarlink client, alarm “1588 loss
secondary server” is raised.
This alarm indicates the loss of synchronization from the secondary server.

The eNodeB fallbacks in the following priority to:

• primary PTP server if accessibility is restored
• another clock reference source if available
• internal clock
eNodeB does not support the Best Master Clock (BMC) algorithm.
6.14.5.4 PTP Domain Number
The DomainNumber field in the 1588 message Common Header received from a Grandmaster is
checked by 1588 receiver. If the DomainNumber from the source is different than the
DomainNumber at the Slave then the received PTP message is discarded by the slave.
As per IEEE1588v2 §7.1: “The domain with domainNumber 0 is known as the default domain. The
value of the domainNumber shall be configurable subject to limits established by a PTP profile.“
The DomainNumber at eNB PTP client it set to the standard default number (0) and cannot be
changed.
6.14.5.5 On-Path Support
Phase delivery with 1588 On-Path Support may be supported either;
• with Boundary Clock topology where there is a single hop between client and peer master
• with Transparent Clock topology where is multiple hops. At each equipment packet latency
compensation is added to the CorrectionField. This allows the 1588 client to compensate for
the added delay.
eNB supports processing of the “correctionField” in received 1588v2 packets.
ITU-T G.827x series of recommendations specify that in order to deliver phase accuracy it is
necessary for every transport node between the master and the client to support 1588v2 On-Path
Support by means of Transparent Clock support (and not by Boundary Clock support).
When the peer is a Boundary Clock, then eNodeB is unaware if its peer is a Grandmaster or a BC.

When the peer is a BC, eNB must be configured with the IP@ of the peer BC as its peer, not the IP@
of the peer GM.
When the peer is a BC, timeserver redundancy from eNB’s point of view is not supported since eNB
supports one First Hop Router, which is the BC.
6.14.5.6 Delay
6.14.5.6.1 PDV characterisation
There is a set of counters which provide the number of SYNC frames received within a delay
window based on the T1 time in SYNC/Follow-Up frame and the T2 time in the eNB. Each ‘ window’
defines a bar in a bar chart capturing the number of SYNC packets received from the active GM
within a particular delay spread.
Delay window width for each counter configuration is done through:
• Object: Enb/ClockSync/PTPClientClockSync, Parameter: ptpPDVCounterStepWidth, Value: [5 to
10000], (with step = 5), Unit: ns, Class: C, Service Impact: None, Update transient impacts details:
Example: ptpPDVCounterStepWidth = 10 ns
There are 20 equal-width windows of 0-10 ns, 10-20 ns, 20-30 ns etc. The values that are captured
are (T2-T1)- (T2-T1)min, where (T2-T1)min represents the fastest packets with the minimum delay.
This measurement generates a baseline of 0 nsecs from which delays are measured.
The distribution of SYNC packets in the windows offers a view on the PDV the SYNC packets are
being subjected to.
Counters related to PDV are reported depending on following activation flag:
Object: Enb/PerformanceManagement, Parameter: pDVReported, Value: [true, false], Class: C,
Service impact: None, Update transient impacts details: Immediate-propagation
6.14.5.6.2 UL vs. DL assymetric delay
The IEEE1588v2 protocol allows for a static network UL to DL asymmetry delay between the eNB and
its remote 1588 peer. Positive value mean the UL has a longer latency than the DL, a negative value
means the DL had a longer latency than the UL. The default is 0, that is symmetrical UL/DL delay.
eNB asymmetric delay delay for 1588v2 algorithm is configurable through:
• Object: Enb/ClockSync, Parameter: ptpNetworkAsymmetry, Value : [10ns-10us]; Class: A, Service

This offset, being configurable, is necessarily a ‘static’ offset, and does not compensate for dynamic
changing asymmetric delays. These must be compensated for by the use of 1588 Boundary Clock or
Transparent Clock topology.
6.14.6 PTP Model Object for configuration

eNB
eNBtransportConf
RanBackhaul
Vlan[1-50]
plmnId
vLanId = [2-4080; 4096]
ipFormat = IPv4 or IPv6
trafficTypeList = 1588
ipv4Address
ipv4SubNetMask
ipv6Address
ipv6RoutingPrefixLength
Figure 112: 1588 VLAN & IP – Model object for configuration

eNB
ClockSync
clockSyncSourcePriorityList = [ptp1588, internal-oscillator]

ptpClientEnable = true
sfnSyncOption = [FreqSyncOnly, FreqAndPhaseSyncEnabled,
FreqAndPhaseAndTimeOfDaySyncEnabled]
PTPClientClockSync
ptpPrimaryServerIPaddress
ptpSecondaryServerIPaddress (1)
ptpPrimaryServerIPv6Address
ptpSecondaryServerIPv6Address (2)
ptpClientRegToD = 0:00:00
ptpSyncDuration 300 s
ptpLogSyncInterval -6 (64 Sync /s)
ptpLogAnnounceInterval 1 (1 Announce every 2 s)
ptpLogMinDelayReqInterval -4 (16 Delay req /s)
ptpPDVCounterWidthStep
(1) 0.0.0.0 if no secondary
(2) 0:0:0:0:0:0:0:0 if no secondary
Figure 113: 1588 – Model object for configuration
PTPClientClockSync object owns parameters that are not used in this release:
• PTPClientConfigParameterx with x=[1-32]

• ptpLogMinPDelayReqInterval
• ptpAnnounceDuration (PTP client uses ptpSyncDuration instead)
• ptpAnnounceReceiptTimeOut
• ptpClientMode
• ptpStackMode
• ptpGMRevertiveSwitchEnabled
• ptpOverEthernetTagEnable
• ptpRevertWaitToRestoreTimer
• ptpTemporaryPrimaryGMExclusion
• ptpTemporarySecondaryGMExclusion
• ptpExcessiveLockLatencyTimer


ptpExcessiveLockLatencyTimer parameter is not used.
eNB uses a hard-coded 15 mn timer for 1588 Frequency lock and 45 mn timer for Phase lock.
This timer specifies the time allowed for the client to attempt to lock to the 1588 messages before
triggering the PTP_UNEXPECTED_LONG_INITIALIZATION alarm.
6.14.7 Simultaneous SyncE+PTP (TDD only)
eNB supports simultaneous use of SyncE and 1588v2:
• SyncE for frequency extraction
• 1588v2 for Phase and Time of Day
SyncE has the advantage of offering robust frequency synchronization with the significant timing
events occurring at every recovered Ethernet clock edge. These significant events occur once every
Ethernet bit at Layer1. However, there is no phase or time of Day facility in SyncE. 1588v2, on the
other hand, offers phase and Time of Day but the synchronization significant events only occur once
per received SYNC packet, much slower than the SyncE rate. Therefore, a scheme using both
techniques simultaneously offers the advantages of both techniques, robust sync plus phase
alignment and Time of Day support.
Further advantages occur since once locked, if one of the reference technologies fails, the other
will offer indefinite holdover, since both technologies are traceable to Primary Reference Sources.
If PTP is lost the SyncE can maintain the already aligned phase and Time of Day whilst continuing to
provide frequency lock. If SyncE fails in ‘1588+SyncE’ mode the eNB migrates to traditional Holdover
mode, flywheeling on the local OCXO to maintain frequency and phase signals.
eNB syncE+PTP configuration is done through:
• Object: Enb/ClockSync, Parameter: syncEAndPTPEnable, Value : [true, false]; Class: A, Service

syncEClockEnable, ptpClientEnable and syncEAndPTPEnable are mutually exclusive.

syncEClockEnable and ptpClientEnable must be disabled if combined option syncEAndPTPEnable is
enabled.
eNB monitors the performance of the recovered syncE clock by monitoring the Quality Level in the
received SSM messages. This information is accessible at OMC through the Read Only parameter
SyncEClockSync::synceQualityLevel.

For syncE+PTP, the only acceptable SSM Quality Level are 0001 and 0010.
SSM QL G.781 PTP clockClass

Option I Option II Option III
0001 QL-PRS 80
0010 QL-PRC 84
If the monitored Quality Level accuracy is sufficiently stable then eNB locks to syncE. This
information is accessible at OMC through the Read Only parameter SyncEClockSync::syncELocked.
If eNodeB is locked to 1588 PTP then eNB enables the use of PTP. This information is accessible
through the Read Only parameter ‘PTPClientClockSync::ptpLocked’.
6.15 M3 INTERFACE
M1
eNB
M2 MBMS-GW
MCE MME
M3 Sm
Figure 114: eMBMS architecture
MBMS is enabled through:

• Object: Enb/ActivationService, Parameter: isMbmsBroadcastModeAllowed, Value: [true, false],
Class: C, Service Impact: None, Update transient impacts details: Immediate-propagation
M3 interface is the interface between the MCE and the MME.

Rule: <eNodeB> <M3> <Design>
In ALU eMBMS solution, the MCE function is distributed in each eNB.
The MCE function is enabled through:

• Object: Enb/ActivationService, Parameter: isMceDistributedModeEnabled, Value: [true, false],
Default: false, Class: C, Service Impact: None, Update transient impacts details: Immediate-
propagation
eMBMS signaling (Session Start/ Session Stop/ Session Update/ Session Reset) is initiated at MBMS-
GW and conveyed to eNB via M3.

Rule: <eNodeB> <M3> <Standard>
According to 3GPP, the Session Update does not change the transport layer parameters.
The MBMS-GW delivers the eMBMS packet data service to eNB via M1 interface.

eNB/MCE LHR MME
MBMS Session Start Request

(MME id, multicast address, source address TEID)
MBMS Session Start Response

(MME id, MCE id)
eNB joins the IP Multicast group for the

user plane data delivery
IGMPv3/MLDv2 Report
(Allow New Sources, Multicast Address, Source Address)
N retransmissions
IGMPv3/MLDv2 Report
(Allow New Sources, Multicast Address, Source Address)
Figure 115: M3 Session Start
eNB/MCE LHR MME
MBMS Session Stop Request

(MME id, MCE id)
MBMS Session Stop Response

(MME id, MCE id)
eNB leaves the IP Multicast group for

the user plane data delivery
IGMPv3/MLDv2 Report
(Block Old Sources, Multicast Address, Source Address)
N retransmissions
IGMPv3/MLDv2 Report
(Block Old Sources, Multicast Address, Source Address)

Figure 116: M3 Session Stop
eNB/MCE LHR MME
MBMS Reset
(list of couples (MME id, MCE id))
MBMS Reset Acknowledge

(list of couplse (MME id, MCE id)
eNB leaves all the IP Multicast groups
listed in the Reset message that it had
joined for the user plane data delivery
IGMPv3/MLDv2 Report
(Block Old Sources, list of (Multicast Address, Source Address))
N retransmissions
IGMPv3/MLDv2 Report
(Block Old Sources, list of (Multicast Address, Source Address))
Figure 117: M3 Session Reset
6.15.1 Static configuration
ALU eNB supports eMBMS static configuration in case the peer-MME does not support M3 interface.
Static configuration of M1 GTP tunnel identifier is done through:

• Object: Enb/Mbms/MbmsBearerService, Parameter: gtpTeID, Value: Hexadecimal String with 8
characters, Class: C, Service Impact: None, Update transient impacts details: Immediate-
propagation
Static configuration of M1 group multicast address in IPv4 is done through:
• Object: Enb/Mbms/MbmsBearerService, Parameter: iPMulticastAddress, Value: [0-255].[0-
255].[0-255].[0-255], Class: C, Service Impact: None, Update transient impacts details:
Static configuration of M1 group multicast address in IPv6 is done through:
• Object: Enb/Mbms/MbmsBearerService, Parameter: iPMulticastAddressV6, Value: [0-255]:[0-
255]:[0-255]:[0-255]:[0-255]:[0-255]:[0-255]:[0-255], Class: C, Service Impact: None, Update
Static configuration of BMSC source address in IPv4 is done through:

• Object: Enb/Mbms/MbmsBearerService, Parameter: iPsourceAddress, Value: [0-255].[0-255].[0-

255].[0-255], Class: C, Service Impact: None, Update transient impacts details: Immediate-
propagation
Static configuration of BMSC source address in IPv6 is done through:
• Object: Enb/Mbms/MbmsBearerService, Parameter: iPsourceAddressV6, Value: [0-255]:[0-
255]:[0-255]:[0-255]:[0-255]:[0-255]:[0-255]:[0-255], Class: C, Service Impact: None, Update
Others static parameters are provided for radio or MBMS service configuration; guaranteedBitRate,
plmnMobileCountryCode, plmnMobileNetworkCode, qCI, serviceId, serviceName, sessionId,
syncPeriodDuration, syncPeriodOffset
When M3 signalling is supported eNB does not take into account the IP addresses of M1 traffic
configured by OAM (if any).
6.15.2 Ethernet
types of traffic (including M3 traffic) .
6.15.3 IP
traffic (including M3 traffic).
eNB IP address and MME IP address are provisioned at OAM.

• Object: EnbEquipment/Mce/M3MmeAccess/M3MmeTransportLayerAccess, Parameter:
sctpAssocRemAddr, Value: list of 2 IP addresses, Class: B, Service impact: Partial, Update transient
impacts details: M3-interface
Engineering: <eNodeB> <M3>
Multi-homed MME is supported with up to 2 IPv4 or IPv6 addresses.
Restriction: <eNodeB> <M3> <Design>
Only 2 MME IPv4 or IPv6 addresses are supported for multi-homed MME.
Note: in the MIM there is the erroneous information that 4 MME IP addresses may be provisionned.

• Object: EnbEquipment/Mce/M3MmeAccess/M3MmeTransportLayerAccess, Parameter:
sctpAssocRemAddrIpv6, Value: list of 2 IP addresses, Class: B, Service impact: Partial, Update
transient impacts details: M3-interface

eNBEquipment
Mce
M3MmeAccess
M3MmeTransportLayerAccess
Figure 118: M3 SCTP – peer addressing - Model object for configuration
6.15.4 SCTP
M3-AP runs on top SCTP. A SCTP protocol association is permanently established by the eNB.
eNodeB supports multi-homed MME and the provisioning of up to 2 IPv4 or IPv6 addresses per MME.
The SCTP procedures used for the M3 interface between the eNB and the MME are the same as for
S1 interface between the eNB and the MME.
The same SCTP parameters with the same values are used.
Those parameters are those defined in RCF 4960 and configured under ‘MmeSctpLayerConf’ object.
There must be only 1 SCTP association established between an MCE and an MME. [3GPP TS 36.442]
M3 SCTP associations are initiated by eNodeB via INIT message sent from eNodeB.
There is only a single pair of SCTP stream identifiers in the SCTP association between the MME and
the eNB.

IANA has defined the SCTP destination port supporting M3-AP traffic as = 36444.
eNodeB’s local port is set by the operating system, it is not provisionned.
6.15.4.2 SCTP parameters for RTO calculation
Same as for S1 interface.
The eNodeB establishes the SCTP association.[3GPP TS 36.442]
6.16 IGMPV3 & MLDV2

The combined usage of the M3-AP and IGMPv3 (IPv4) or MLDv2 (IPv6) signalling allows for dynamic
establishment of multicast channels between the eNB and its First Hop router (last multicast
replication point before the eNB).
eNB determines whether to use IGMPv3 or MLDv2 depending on the version of IP addresses received
for the Multicast group and Multicast source in M3 signalling.
MBMS-GW allocates an IP multicast address to which the eNB should join to receive the MBMS data.
This IP multicast address together with the IP address of the multicast source (and a GTP DL TEID)
are provided to the eNB via MME within M3-AP message ‘MBMS Session Start’.

The IP multicast address and the source address identify the Source Specific Multicast (SSM) channel
used for user plane distribution on the backbone network.
The eNB may accept or reject the proposed IP Multicast distribution in the MBMS Session Start
Response to the MME.
Upon successful ‘MBMS Session Start’ procedure, eNB sends IGMPv3 (IPv4) or MLDv2 (IPv6)
Membership Report message to the Last Hop Router to subscribe to IP SSM channel associated with
the eMBMS bearer, including the MBMS-GW source IP and the destination IP multicast address chosen
by MBMS-GW for this session.
The first hop router to the eNB responsible for IP multicast distribution then propagates this
subscription information upstream. The result of this propagation is the establishment of a shortest
path tree (SPT) from source (MBMS-GW) to receiver (eNB). Then, MBMS-GW sends out M1 packets
with its IP address as source, and the chosen multicast IP address as destination.
At ‘MBMS Session Stop’ the eNB reports to the backbone in order to leave the bearer service
multicast distribution.
IGMPv3 and MLDv2 provide support for source specific multicast. Thus, a receiver of a multicast
group can specify an explicit set of sources from which it is interested or not interested to receive
data.
Two filter modes are used in IGMPv3 and MLDv2:

• include mode: data from the specified sources are filtered and forwarded towards the hosts by
the multicast router.
• exclude mode: data from the specified sources are filtered and not forwarded towards the
hosts.
Rule: <eNodeB> <IGMPv3-MLDv2> <Standard>
The eMBMS service as defined by 3GPP 23.246 uses Source Specific Multicast model with only 1
source address of multicast for a multicast address.
Rule: <eNodeB> <IGMPv3-MLDv2> <Design>
As per 3GPP 23.246, the full support of IGMPv3 and MLDv2 is not needed at the eNB which only uses
the filter mode “Include mode”.
The eNB uses the following messages:

• IGMPv3 “Membership Query” or MLDv2 “Multicast Listener Query”
• IGMPv3 “Version 3 Membership Report” or MLDv2 “Version 2 Multicast Listener Report”

eNB/MCE LHR
Query
Delayed response.
Combined response if pending responses.
Response not sent if Query for a group or a
source that the eNB does not listen to.
IGMPv3/MLDv2 Report
(Mode Is Include, Multicast
Addresses, Source Address)
Figure 119: IGMPv3 and MLDv2 – Query and Report
The following Record types are used:

• "Current-State Record" with value “MODE_IS_INCLUDE”
• "Source-List-Change Record" with value “ALLOW_NEW_SOURCES”
• "Source-List-Change Record" with value “BLOCK_OLD_SOURCES”
The eNB uses the retransmission mechanism of unsolicited Report as described in RFC 3376 and RFC
3810.
The number of retransmissions is not configurable, the hardcoded value is: 2.

The time between retransmission is chosen randomly in the interval [0; Unsolicited Report
Interval].
The ‘Unsolicited Report Interval’ is not configurable, the hardcoded value is: 10s.
The eNB delays its response (Report) to a Query from the router in compliance with RFC 3376 and
RFC 3810. The delay is a random amount of time, bounded by the Max Resp Time value derived from
the Max Resp Code in the received Query message. If there are pending responses to query, the eNB
sends a combined Response (Report).
Rule: <eNodeB> <IGMPv3-MLDv2> <Standard>
Max Resp Time calculation from Max Resp Code is described in RFC 3376 & 3810.
Although the eNB uses a reduced set of IGMPv3 and MLDv2 features, it is fully compatible with full
IGMPv3 router or Lightweight IGMPv3 router and with full MLDv2 router or Lightweight MLDv2
router.
6.16.1 Ethernet

types of traffic (including IGMPv3 and MLDv2 traffic).
In IPv4, the eNB listens to the IP multicast address 224.0.0.1 and the deduced multicast MAC
address.
In IPv6, the eNB listens to the IP multicast address FF02::1 and the deduced multicast MAC address.
6.16.2 IP
traffic (including IGMPv3 and MLDv2 traffic).
The DSCP marking for IGMPv3 and MLDv2 is the same than the one configured for ICMP traffic.
The IGMPv3 messages are characterized by:

• IP protocol number 2
• IP Time-To-Live 1
• IP precedence of Internetwork Control (e.g. Type of Service 0xC0)
• IP Router Alert option (RFC 2113) in IP header
The MLDv2 messages are a subset of ICMPv6 messages and are characterized by:
• A preceding Next header value of 58
• Link-local IPv6 Source Address (or unspecified address)
• IPv6 Hop Limit 1
• IPv6 Router Alert option (RFC 2711) in a Hop-by-Hop Options header

IGMPv3 traffic source IPv4 address destination IPv4 address

eNB Last Hop Router eNB unicast address IP multicast address 224.0.0.22
IP multicast address 224.0.0.1 for General queries
Last Hop Router eNB router unicast address group multicast address (received in M3 Session
Start Request) for Group-Specific Queries and
Group-and-Source-Specific Queries
MLDv2 traffic source IPv6 address destination IPv6 address

eNB link-local source
eNB Last Hop Router link-local multicast address FF02::16
address (1)
link-local multicast address FF02::1 for General
queries
router link-local group multicast address (received in M3 Session
Last Hop Router eNB
address Start Request) for Multicast Address Specific
Queries and Multicast Address and Source Specific
Queries
Table 61: IGMPv3 & MLDv2 source & destination IP addresses

(1) The IP address of MLDv2 in the traffic descriptor of the MIM is not used
6.17 M1 INTERFACE
M1 transports eMBMS traffic.
MBMS is a point-to-multipoint service in which application data (TV and radio channels) is
transmitted from a single source entity to multiple recipients.
No IP @ needs to be configured at eNodeB.
eNodeB listens M1 multicast transport packets over an ethernet multicast @.
eNodeB then broadcasts IP application packets over air interface.
It is only supported eMBMS user plane as downlink multicast flow.
eNodeB does not originate any uplink eMBMS traffic
6.17.1 Ethernet
Multicast M1 packets are sent from Last-Hop-Router to eNB encapsulated in Ethernet frames. The
destination MAC address value is a multicast MAC address (the multicast bit is set).
The destination MAC address value for M1 multicast transport is calculated as follows by the Last
Hop Router:
• In IPv4, the low-order 23 bits of the IPv4 multicast address are placed into the low-order 23 bits
of the special multicast address 01-00-5E-00-00-00. This creates the range of Ethernet MAC
addresses for multicast IPv4 to be 01-00-5E-00-00-00 through 01-00-5E-7F-FF-FF. This mapping is
not unique. The SSM multicast destination IP address is in the subnet 232.0.0.0/8; 24 bits define

a specific service, while only 23 bits are copied to the MAC address. For a given source up to
two SSM multicast groups may map to the same hardware address at the same time. Taking into
account the possibility that many different sources can be used for the same SSM multicast
destination IP address, a large number of SSM channels may map to the same hardware address.
• In IPv6, the last four octets of the IPv6 multicast address are placed into the last four octets of
the special multicast address 33-33-00-00-00-00. This creates the range of Ethernet MAC
addresses for multicast IPv6 to be 33-33-00-00-00-00 through 33-33-FF-FF-FF-FF.
The eNB listens to the multicast MAC address deduced from the group multicast address.
6.17.2 IP
There is no IP address configured for the M1 traffic as it is downlink multicast traffic.
The Source Specific Multicast (SSM) service model is used.
The source address is the source address received from eMBMS GW in M3-AP MBMS Session Start
Request.
The SSM destination address is the group multicast address received in M3-AP MBMS Session Start
Request.
IANA has assigned the addresses range 232.0.0.0/8 (IPv4) and FF3x::/32 (IPv6) for SSM multicast
destination IP address.
The eNB M1 address configured in the traffic descriptor of the MIM is not used.
6.17.3 GTP
A GTP path exists between the eNodeB and the MBMS-GW with which a GTP tunnel is established.
The GTP DL TEID used by the eNB to establish the tunnelling with the MBMS-GW for M1 user plan is
sent by the MME in the MBMS SESSION START REQUEST M3-AP message.
6.17.4 Synchronization
eMBMS traffic requires both radio frame phase synchronization AND aligned SFN on the air interfaces
of neighbouring eNBs.
eMBMS can rely on GPS synchronization or on PTP synchronization.
Engineering: <eNodeB> <M1>
sfnSyncOption parameter must be configured to support frequency and phase and Time of Day
synchronization mode (ClockSync::sfnSyncOption = FreqAndPhaseAndTimeOfDaySyncEnabled)
eMBMS phase tolerance is done through:

• Object: Enb/Mbms, Parameter: mbmsPhaseDriftThreshold, Value : [1,5-40] (with step=0,5), Unit:
us, Default: 10; Class: A, Service impact: Critical, Update transient impacts details: full-eNB-reset
It defines the drift point for eMBMS alarm generation.

6.18 ENB SELF COMMISSIONING WITH PLUG-N-PLAY

It is not the intent for this document to describe the self commissioning document in the various
configurations. This document will cover the basics of the feature and the required interactions of
the core transport network. The main focus will be the requirements and functionality of the core
network to support this feature. A walk through of a PNP scenario is provided for completeness
purposes. This is a separate example from the IPsec PNP scenario described in 6.10.3.4 IPsec Plug-N-
Play Walk Through with IPsec and DHCP capability.
The PNP capabilies allow the node to be deployed without on site configuration of the node. The
Self Commissioning combinedwith the PNP capabilities allows the EMS to configure the node without
the EMS operator intervention. This capability is already available with nodes that are configured
with Static IP addresses and IPsec is disabled on the OAM channel. The ability to manage the nodes
with static IP addresses will still be available. The node will now be discovered by the nodes serial
number. The serial number discovery method supports the PNP mechanisms.
The EMS can be configured to discover each individual node with either the:
1. IP Address method – This capability requires the EMS to poll for the node. Once the node
responds, the EMS starts the registration process.
2. Serial Number method – The Node will send Hello messages to each of the EMS addresses
that the node has been provisioned. The EMS that is configured to manage the node by
configuring the EMS with the nodes serial number. The managing EMS will respond to the
node and start the OA&M link setup.
Engineering: <eNodeB> <Self Commissioning>
Self Commisioning Capabiltities via the serial number are compatible with IPsec and NON IPsec PNP
OA&M communications channels.
Restriction: <eNB><IPsec>(<Plug-N-Play>)
IPv4 traffic only for OA&M traffic.
1. No factory customization of FQDNs (SeGW/ SAM FQDNs or IP address). All information are
acquired via DHCP.
2. DNS address resolutions are not supported during the Macro PNP deployments.
3. No SeGW redirection during PNP deployments.
4. Macro eNB will default to No VLAN from the factory.
6.18.1 Self Commissioning parameters associated with transport

In order to support the self commissioning method, several parameters are introduced.
The parameters listed below are required to support eNB serial number identification method.

Parameter emsFqdn
Object ENBEquipment/eNB/EnbTransportConf/OamTransportConf
Range & Unit String (1-64) characters
Value N.A.
Feature 115970
This parameter specifies the fully qualified domain name (FQDN) of EMS to use during initial OAM
Link Establishment. The emsFqdn/DNS is used during automatic Plug-n-Play procedures to obtain
EMS IP address for DNS option of providing EMS IP address. This parameter is only used when (1)
RanBackhaul.ipConfigAutomatic is set to True which indicates that the OAM Link Establishment
parameters are obtained from automatic Plug-n-Play procedures instead of provisioned by the
operator; (2) Operator does not use DHCP option. If the DNS option is used a default port of 162 is
used since the DNS does not return the port with IP address resolution.
Parameter emsIpv4Address
Object ENBEquipment/eNB/EnbTransportConf/ProvisionedEmsAddressData
Range & Unit IPv4 Address
Value N.A.
Feature 115970
This parameter specifies an EMS IPv4 address provisioned by the operator. This is one of the
parameters in the ProvisionedEmsAddressData object. Up to 10 ProvisionedEmsAddressData objects
may be created by the operator. eNB contacts these EMS IP addresses in order to establish the
initial OAM connection. This parameter is only used when (1) RanBackhaul.ipConfigAutomatic is set
to False which indicates that the OAM Link Establishment parameters are provisioned instead of
obtained from automatic Plug-n-Play procedures AND (2) IPv4 is used for the OAM interface.
Parameter emsIpv6Address
Object ENBEquipment/eNB/ EnbTransportConf/ProvisionedEmsAddressData
Range & Unit IPv6 Address
Value N.A.
Feature 115970
This parameter specifies an EMS IPv6 address provisioned by the operator. This is one of the
parameters in the ProvisionedEmsAddressData object. Up to 10 ProvisionedEmsAddressData objects
may be created by the operator. eNB contacts these EMS IP addresses in order to establish the initial
OAM connection. This parameter is only used when (1) RanBackhaul.ipConfigAutomatic is set to
False which indicates that the OAM Link Establishment parameters are provisioned instead of
obtained from automatic Plug-n-Play procedures AND (2) IPv6 is used for the OAM interface.

Parameter emsOamLinkInitPort
Object ENBEquipment/eNB/ EnbTransportConf/ProvisionedEmsAddressData
Range & Unit (1-65535)
Value N.A.
Feature 115970
This parameter specifies the port on the EMS where eNB sends Hello msgs during OAM Link
Establishment. This is one of the parameters in the ProvisionedEmsAddressData object. Up to 10
ProvisionedEmsAddressData objects may be created by the operator. eNB contacts these EMS IP
addresses in order to establish the initial OAM connection. This parameter is only used when
RanBackhaul.ipConfigAutomatic is set to False which indicates that the OAM Link Establishment
parameters are provisioned instead of obtained from automatic Plug-n-Play procedures.
The emsIpv4Address/ emsIpv6Address and emsOamLinkInitPort parameters are only provisioned if

the values are not acquired through DHCP and ranBackHaul.ipConfigAutomatic enabled. If
ranBackHaul.ipConfigAutomatic enabled and DHCP is used, the DHCP can be configured to return
the EMS IPaddress and Port numbers.
6.18.2 Self Commissioning impacts on the transport

The network topology for the NON IPsec PNP scenario is same to the IPsec PNP. Refer to section
6.10.3 eNB Security Plug-N-Play Implementation. All the transport features and capabiltities are the
same as the IPsec PNP except where noted in this section.
The information and the network component that issues the information will differ between the
NON IPsec and IPsec PNP scenario. As discussed in the IPsec PNP section of the Transport
Engineering Guide, the edge DHCP server returns Outer IPsec tunnel address, the SeGW IP address
and EMS information. For NON IPsec PNP scenario, the DHCP server will return the OAM IP address
instead of the IPsec Tunnel outer address. The IPsec inner tunnel address is not required in this
scenario.
OAM Channel Edge DHCP server Core DHCP server

IPsec 1. DHCP response contains the IP address for 1. DHCP reponse contains the
the nodes OAM interface. IP address for the nodes
2. A list of EMS IP addresses and associated inner IPsec tunnel OAM
ports for EMS communications (Part of interface.
vendor specific option 43)
3. SeGW IP address (Part of vendor specific
option 43)
NON IPsec 1. DHCP response contains the IP address for
the nodes outer IPsec tunnel OAM
interface.
2. A list of EMS IP addresses and associated
ports for EMS communications (Part of
vendor specific option 43)
Table 62: DHCP information set for PNP scenario

Engineering: <eNodeB> <Self Commissioning/DHCP>
The node determines whether the OAM channel is an IPsec OAM or NON IPsec OAM link based on the
information received from the DHCP response
• If the DHCP reponse contain the SeGW IP address in the vendor specific option 43, the node
will be configured for IPsec OAM
• . If the DHCP reponse does not contain the SeGW IP address in the vendor specific option
43, the node will be configured for NON IPsec OAM
The example above represents an example of a fully automatic method to allocate configuration
information to the nodes. It is not mandatory that DHCP be used for allocating configuration
information. Other mechanisms can be used. If certain information isn’t allocated as part of an
automated PNP method, then the information set must be manually provisioned.
The Nodes use the list of EMS IP addresses and ports to establish an OAM Link with the EMS.
6.18.3 High level Self Commissioning description
Once the OAM communications channel have been established, the node will start the OAM link
establishement with EMS. The Serial number case will be described to illustrate the use of the DHCP
response information.
1. eNB sends Hello messages to Candidate EMS IP addresses and ports obtained from PnP
procedures.
2. Managing EMS receives Hello message. The Hello messages contain the nodes serial number
and IP address.
3. EMS determines if it is the Managing EMS for the eNB
4. Managing EMS opens the OAM link using the eNB’s OAM IP address in the Hello message and
registers itself as the Managing EMS.
5. EMS begins link monitoring and sends first valid Heartbeat message to eNB to SNMP port 161.
6.18.4 Self Commissioning Walk through with NON IPsec PNP

The network topology is depicted in Figure 87: IPsec PNP Network Topology
6.18.4.1 NON IPsec Plug and Play Pre-Requisits features and capabilities
The following components list the pre-requisit features required to support the Plug and Play
scenario.
eNB/Metrocell pre-requisits
1. Feature L115970 – eNB self Comissioning feature. This feature is required to complete the
Plug-n-Play scenario, but required to establish the OAM IPsec channel.
2. The parameter ranBackaul.ipConfigAutomatic is enabled. This is the default setting.
L2/3 Device Pre-requisits

1. If this device is a layer 2 device, there are no special capabilities required. The DHCP
2. There are several option associated with DHCP if the device is a layer 3 device.
c. The device may have an internal DHCP server capability The Edge DHCP server will
be configure to provide the OAM address and the EMS IP address (including ports).

Upon receiving a DHCP request, the edge router will respond with the required IP
addresses.
d. The Layer device can act as a DHCP relay to and send a request to a DHCP server to
acquire the OAM address, the EMS IP address (including ports.
Restriction: <eNB>(Plug and Play>)
The nodes DHCP client will not perform DHCP renew requests. The DHCP server should have a
permanent lease time for the OAM IP address.
Core Router (SeGW)
1. There are no special capabilities required.
Network DHCP server
Not Required
CMS
Not Required
SAM
The SAM is provisioned with the eNB serial number in order to accommodate the eNB serial number
registration scheme (Feature L115970, eNB Self Commissioning). Release 13.1 eNB will initiate hello
messages to EMS IP addresses that are pre-configured on the eNB or EMS IP addresses that are
acquired When an eNB sends the hello message to the controlling SAM, the SAM will respond and
continue with the registration process. Once the eNB is registered and Managed, the SAM is used to
provision the eNB/Metrocell with the final configuration once communications to the eNB or
Metrocell is established.
6.18.4.2 Plug and Play Pre-Deployment configurations
The PNP components must be pre-configured to support the deployment of the eNB/Metrocell prior
to the delivery of the equipment. In order to provide a proper explaination of the functionality a
complete walk through the communications between the deployed equipment and the network
components will be discussed. An example of the communications between the eNB/Metrocell and
the network components are provided in this section. The example will be an IPsec tunnel
configuration for the OAM and telecom interfaces.
Factory procedures / configurations

The eNB/Metrocell will be booted in the factory to acquire the CMS factory certificates. The eNB
will be loaded with the eNB signed certificate and the self signed root certificate from the factory
CMS. The parameter RanBackhaul::ipConfigAutomatic is set to “true”. The eNB serial number is
provisioned.
Edge Device
If the edge device is a layer 2 device, then the device should be configured to accept no VLAN
OA&M traffic.
If the device is a layer 3 device, an internal DHCP server should be configured to provide the:
• OAM IPsec address
• the EMS IP addresses and ports (Maximum of 10)

The assigned IP addresses are associated with the eNB/Metrocell. Upon receiving a DHCP request,
the edge router will respond with the appropriate IP addresses.
Core Router (SeGW)
The router will be properly configured for routing traffic to the OAM network.
Core DHCP server –- N/A
CMS -- N/A
SAM
The SAM will have the complete configuration for each eNB. This includes all the parameters for a
communications channel for the OAM if necessary. The SAM is configured with the serial numbers of
all the eNBs that the SAM will manage. The SAM has the self configuration policy set with the
following set:
o Auto Start
o SW Upgrade
o Configuration Deployment
o Administrative Enable
6.18.4.3 NON IPsec Plug and Play Walk Through with IPsec and DHCP capability
Figure 120: NON IPsec Plug and Play Flow represents the communications for Plug and Play. All
discussions will refer to this diagram.

Figure 120: NON IPsec Plug and Play Flow
Factory Certificates Pre-loaded
The Node will be pre-loaded with the ALU factory certificates. The eNB/metrocell will also
configured to automatic configuration. All other components will be pre-configured to support the
eNB deployment.
When the eNB is first deployed in the field, the eNB will first boot and perform a DHCP request for
an AOM IP address, SAM IP addresses and next hop router. The edge device will allocate the IP
addresses. After acquiring the IPsec tunnel address, SAM IP addresses and next hop router address,
the node will initiate connection with the SAM. Te node will initiate communications to all EMS IP
addresses that are known. Only the Managing EMS configured for serial number node identification
will responds to the node initiation. The Node and the managing EMS completes the registration.
The EMS will configure the node based on WPS loaded DB in the EMS system. Once the node has
been configured, the node will reset to instantiate the configured parameters. The node will re-
establish communications channel with the EMS. Telecom communications are established.

6.19 TRANSPORT COUNTERS

Erreur ! Référence de lien hypertexte non valide.Ethernet
Counter Description
Total number of Kbytes received on the

ifInOctets eNodeB external GEthernet interface,
including framing characters.
Number of subnetwork-unicast packets

received on the eNodeB external GEthernet
ifInUcastPkts
interface, delivered to a higher-layer
protocol.
Number of non-unicast (broadcast and

multicast) packets received on the eNodeB
ifInNUcastPkts
external GEthernet interface, delivered to a
higher-layer protocol.
Number of inbound packets received on the

eNodeB external GEthernet interface. These
packets were chosen to be discarded even
though no errors had been detected to
ifInDiscards
prevent their being deliverable to a higher-
layer protocol. One possible reason for
discarding such a packet could be to free up
buffer space.

eNodeB external GEthernet interface. These
ifInErrors
packets containerrors preventing them from
being delivered to a higher-layer protocol.

eNodeB external GEthernet interface, which
ifInUnknownProtos
were discarded because of an unknown or
unsupported protocol.
eNodeB GEthernet link utilisation for the

incoming traffic. This is the division of the
ifInLinkUtilisation bandwidth used by 1 Giga. The result is
shown as a percentage with a granularity of
1%.
ifOutOctets
ifOutUcastPkts
ifOutNUcastPkts
Same as above but for sent traffic
ifOutDiscards
ifOutErrors
ifOutLinkUtilisation

Counter Description
Number of KBytes received on the VLAN

containing the OAM traffic of the eNodeB
OAMInOctets
(Length of the Ethernet frame, including the
Ethernet header).
Total number of packets received on the

OAMInPackets VLAN containging the OAM traffic of the
eNodeB.
OAMOutOctets
OAMOutPackets
Total number of KBytes received on all

Telecom VLANs of the eNodeB (Length of the
TelecomInOctets
Ethernet frame, including the Ethernet
header).
Total number of packets received on all

TelecomInPackets
Telecom VLANs of the eNodeB.
TelecomOutOctets
TelecomOutPackets
Counter Description
Downlink throughput on the VLAN interface

VlanDLThroughput (2)
(including Ethernet header and CRC).
There is a counter created for every traffic

type transported in the VLAN.
VlanTrafficTypeDLPackets (1)(3)
Number of downlink Ethernet frames sent
for the concerned traffic type of the VLAN.
There is a counter created for every traffic

type transported in the VLAN.
VlanTrafficTypeDLOctets (1)(3) Number of Ethernet kbytes received for the
concerned traffic type of the VLAN. The
count includes IP and ethernet headers.
VlanULThroughput
VlanTrafficTypeULPackets Same as above but for uplink traffic
VlanTrafficTypeULOctets
(1) At eNB, counting occurs before fragmentation and after re-assembly in the egress & ingress
respectively, for U-plane traffic. This causes a small underestimate of traffic volume as the headers
of the fragmented packet are not counted.

The implementation estimates the overhead for IPsec since in the U-plane the trafficType cannot
be retrieved from an encrypted packet, therefore decryption is required before trafficType counting
can occur.
(2) Counters related to Vlan are reported depending on following activation flag:
• Object: Enb/PerformanceManagement, Parameter: vlanReported, Value: [true, false], Class: C,
Service impact: None, Update transient impacts details: Immediate-propagation
(3) Counters related to Traffic Type are reported depending on following activation flags:
• PerformanceManagement::vlanReported, and,
• Object: Enb/ActivationService, Parameter: isTransportTrafficTypeCountersEnabled, Value:
[true, false], Class: C, Service impact: None, Update transient impacts details: Immediate-
propagation
6.19.2 SCTP
Counter Description
Number of times that a SCTP association

establishment with the eNodeB is successful
SctpAssociationEstablishment (initiated by the eNodeB or initiated by a peer
eNodeB, consecutive or not to a SCTP
association failure).
Number of times that eNodeB loses the

SctpAssociationFailure
connectivity on a SCTP association.
6.19.3 X2
Counter Description
Throughput received on the X2 interfaces of

X2ReceivedThroughput the eNodeB equipment (including Ethernet
headers).
Total number of packets received on the X2

X2ReceivedPackets
interfaces of the eNodeB equipment.
Total number of KBytes received on the X2

X2SctpInOctets interface from a remote eNodeB (Length of
the SCTP SDU).
Total number of packets received on the X2

X2SctpInPackets
interface from a remote eNodeB.
X2SentThroughput
X2SentPackets
X2SctpOutOctets
X2SctpOutPackets
6.19.4 S1

Counter Description
Throughput received on the S1 interfaces of

S1DLThroughput the eNodeB equipment (including Ethernet
headers).
Total number of packets received on the S1

S1DLPackets
interfaces of the eNodeB equipment .
Total number of KBytes received on the S1

S1SctpInOctets interface from an MME (length of the SCTP
SDU).
Total number of packets received on the S1

S1SctpInPackets
interface from an MME.
S1ULThroughput
S1ULPackets
S1SctpOutOctets
S1SctpOutPackets
6.19.5 M1
Counter Description
Volume in KByte of M1 GTP payload received

M1GtpPayloadKbytesReceived
(does not include the GTP header).
6.19.6 UL traffic shaping
Counters related to UL Traffic Shaping are reported depending on following activation flag:
Object: Enb/PerformanceManagement, Parameter: trafficShapingReported, Value: [true, false],
Class: C, Service impact: None, Update transient impacts details: Immediate-propagation

Counter Description
Per-port counters (1 physical port only is supported).

1 counter instance per queue (max of 16 queues).
PortShaperQueueAcceptedPackets Number of packets accepted into the queue
PortShaperQueueRejectedPackets Number of packets rejected at the queue
Average, minimum and maximum packet loss

rate for the queue.
It is obtained by sampling at
packetsLossRateMeasurementPeriod the
total number of packets accepted and
PortShaperQueuePacketLossRate rejected at the queue. The rate is
calculated by dividing the number of
rejected packets by the sum of the number
of rejected packets plus the number of
accepted packets and multiplying by 106
(unit is ppm).
Per-VLAN counters (max of 10 VLANs).

1 counter instance per queue (max of 16 queues).
VlanShaperQueueRejectedPackets
VlanShaperQueueAcceptedPackets Same as above but per VLAN
VlanShaperQueuePacketLossRate

Those counters are to be used to monitor T-CAC and tune its setting (e.g overbooking factors).
Counter Description
Per-port counters (1 port only is supported).

1 counter instance per CoS (max of 16 CoS).
Average, maximum and minimum number of

bearers per port per CoS. The average value
NbBearersPerPortPerCoSOnS1u is obtained by dividing the cumulative value
of the bearers by the number of events
(bearer setup or release).
Number of times a T-CAC procedure has

PortTransportCACFailureOnS1u
failed (eRAB admission failure).

Counter Description
Per-port counters (1 port only is supported).

1 counter instance per CoS handling emergency calls.
Average, maximum and minimum number of

NbVoiceEmergencyBearersPerPortForCoSVoIPOnS1u Emergency voice bearers per port for CoS
handling VoIP.

PortTransportCACFailureForEmergencyCallOnS1u failed (eRAB admission failure) for
Emergency VoIP call.

PortTransportCACFailureForHPACallOnS1u
failed (eRAB admission failure) for HPA call.
Per-VLAN counters (max of 10 VLANs).

Same as above but per VLAN
NbBearersPerVlanPerCoSOnS1u
VlanTransportCACFailureOnS1u
NbVoiceEmergencyBearersPerVlanForCoSVoIPOnS1u
VlanTransportCACFailureForEmergencyCallOnS1u
VlanTransportCACFailureForHPACallOnS1u
6.19.8 1588v2
Counter Description
PTPFramePDV PTP frame packet delay variation.

Number of SYNC packets received from the
active grandmaster within a PDV window. A
set of screenings provide the number of
SYNC frames received within a set of latency
windows. The delay window width for each
screening is defined by the parameter
ptpPDVCounterWidthStep.
PTPSyncRxPrimaryGM Sync messages received from primary GM
Announce messages received from primary

PTPAnnounceRxPrimaryGM
GM
This counter is incremented when a Sync

message is received but eNodeB PTP client
PTPRejectedSyncRxPrimaryGM algorithm decides not to act on it. E.g. the
algorithm has the capability to ‘ignore’
received packets whose packet delay

Counter Description
exceeds the ‘normal’ range accepted by the
algorithm. The algorithm infers that acting
on this packet will actually create more
error, and so the perfectly good packet is
rejected.
PTPAnnounceRxSecondaryGM
PTPRejectedSyncRxSecondaryGM Same as above for secondary GM
PTPErroredSyncRxSecondaryGM

7 METRO CELL TRANSPORT IMPLEMENTATION

This chapter covers the description of the Metro Cell Outdoor (MCO) eNB ALU design.
MCO includes following variants:

1. MCO TRF where LTE radio functionality is provided by traditional RF internal architecture
2. MCO FAM(ily) where LTE radio functionality is cube-based. The family concept partitions a
metro into two physical entities, one is called the ‘Main Box’ and the other the ‘Metro Dock’.
The Metro Dock’s hosts a L2 Ethernet switch which main function is to provide various backhaul
interfaces:
- a primary backhaul (e.g., Ethernet, GPON, xDSL)
- a daisy-chain backhaul access to another MCO (LTE or WCDMA)
Also, the L2 Ethernet switch may provide a WiFi access by a separate hardware module
connected to a wireless acess point (WAP).
to/from Backhaul
L2 Switch WP3SL P3041
to/from daisy chained equipment
to/from WAP
Figure 121: MCO FAM transport components
In the rest of this chapter, “MCO” refers to the Metro Cell Outdor in general. Where a specific
variant of MCO hardware matters, the terms “MCO TRF” and “MCO FAM” are used.
There is no external interface difference between a MCO and a Macro eNB regarding interconnection
with EPC (MME/SGW), SeGW, neighbor eNB or OAM nodes.
OAM and control plane traffic (S1-C/X2-C) is terminated by the Linux stack running on P3041.
User plane traffic (S1-U/X2-U) is terminated by the WP3-SL.

Wintegra WP3-SL is used to provide following functions:
o Backhaul termination (Ethernet, IPv4/IPv6, IPsec)
o IP packet fragmentation/reassembly
o VLAN priority (Pbit)
o IP DSCP marking
o uplink traffic shaping
o 1588 HW timestamping

Note:
This chapter applies as well to the Metrocell Indoor (MCI) which is based on MCO FAM.
Compared to MCO, MCI does not include any Metro Dock and does not support wifi
AP.ETHERNET
The backhaul interface to the MCO is a Gigabit Ethernet (GbE) interface.

Note: the backhaul port works at 10 Mbps, 100 Mbps or 1 Gbps.
Backhaul port # 10/100/1000BASE-T 1000BASE-X

1
Electrical transceiver Optical transceiver
2 (MCO FAM only)
Table 63: MCO Ethernet port mode of operation
Rule: <MCO> <Vlan> <Design>
ALU MCO Ethernet port(s) support optical and electrical SFP.
Restriction: <MCO TRF> <Ethernet> <Design>
MCO TRF only supports one Ethernet port that is used for backhaul access.
As a consequence, MCO TRF can’t support daisy chaining nor port redundancy.
Restriction: <MCO> <Ethernet> <Design>
There is no Local Maintenance Terminal (LMT) port, and therefore no local NEM access is possible.
Rule: <MCO FAM> <Ethernet> <Design>
eNB supports one MAC address dedicated to 1588 flow, and one MAC address dedicated to
OAM/Telecom… flow.
The WiFi AP also has one MAC address.
A dedicated MAC@ for 1588 enforces a dedicated IP@ for 1588: an ARP for 1588 IP@ gives the 1588
MAC@ and an ARP for OAM and/or Telecom gives the OAM and/or Telecom MAC@.
7.1.1 Daisy-chain connectivity (MCO FAM only)

MCO supports Daisy Chaining.
MCO supports two external GigE ports: one port is used for backhaul access while the other port
may as an option be used to connect another MCO (LTE or WCDMA) which traffic is transported over
the MCO backhaul port.
Restriction: <MCO FAM> <Ethernet> <Design>
MCO supports a maximum of one daisy chain hop.
As an option, MCO may be equipped with a Wi-Fi module which traffic is transported over the MCO
backhaul port.
The support of Wi-Fi is enabled or disabled through:

Object: Enb/ActivationService, Parameter: isWifiBackhaulEnabled, Value: [true, false], Class: C,
The supported combinations are:
Main MCO Daisy chained MCO WiFi module
LTE MCO No
WCDMA MCO No
LTE MCO
No Yes
WCDMA MCO Yes

Metro cell module chained Metro cell module
LTE module LTE or WCDMA

module
L2 switch L2 switch
Optional
WiFi AP
Metro dock module Metro dock module
SFP SFP SFP SFP
chained Metro cell indirect Backhaul

direct Backhaul
access port access port
access port
Backhaul
LTE traffic
LTE or WCDMA daisy chained traffic
WiFi traffic
Figure 122: Traffic paths for the LTE MCO plus Daisy Chain traffic
QoS prioritization and scheduling are performed on the aggregated uplink traffic before forwarding
to the backhaul network. This is done at the L2 Ethernet switch in the LTE MCO. QoS priorities are
based on the L2 p bits in the uplink Ethernet frames. Four queues are available and used to map to
the p bits.
IEEE 802.1p supports 8 priorities while the Ethernet switch supports 4.

Queue Mapping to p bit values in the Ethernet switch applies as follows:
p bit Queue priority
7, 6, 5 First (highest) priority
4, 3, 2 Second priority
0 Third priority
1 & untagged frames Fourth (lowest) priority
The Ethernet switch performs strict priority scheduling.
Metro cell module
LTE module
LTE UL traffic
L2 switch
Queue scheduler p-bit to queue mapping Optional WiFi AP
1st priority p-bit 5, 6 & 7

2nd p-bit 2, 3 & 4
priority
WiFi UL traffic
3rd p-bit 0
priority p-bit 1 &
4th priority
untagged
Metro dock module

direct Backhaul chained Metro cell
SFP SFP
access port access port
Backhaul
chained MCO UL traffic
Figure 123: UL Traffic L2 QoS management for the LTE MCO plus Daisy Chain traffic

LTE MCO does not provide syncE on its daisy chain port.
LTE MCO does not provide policing on its daisy chain port.
LTE MCO does not provide uplink traffic shaping on its backhaul access nor on its daisy chain port.
The L2 Ethernet switch performs L2 switching independent of the VLAN ID tag. Downlink and uplink
traffic are forwarded based on the L2 switch ports.
The VIDs used by the MCO can be shared or not with the daisy chained equipment(s).

Not supported in this release.
7.1.3 VLAN – single operator
Rule: <MCO> <Vlan> <Design>
ALU MCO supports up to 3 VLANs.
7.1.3.1 Supported configuration with no VLAN
Only configurations with IPsec are supported.
7.1.3.2 Supported configurations with 1 VLAN
Only configurations with IPsec are supported.
Supported configurations without IPsec are:

Traffic type
VLAN 1
178044-1 IPv6@1 IPv6@2
168727-1 IPv4@1 IPv6@2 no IP@ IPv6@2
168727-2 IPv6@1 IPv6@2 no IP@ IPv6@2
Supported configurations without IPsec are:
VLAN 1 Traffic type

VLAN 2
178044-2 IPv4@3 IPv6@1 IPv6@2
7.1.4 VLAN – eUTRAN sharing
7.1.5 Ethernet QoS

Same applies as for Macro eNB.
7.1.6 Ethernet frame size
Rule: <MCO TRF> <Jumbo> <Design>
MCO TRF supports jumbo Ethernet frames with a MTU size of 2000 bytes maximum.
The maximum ethernet frame length is thus 2022 bytes.
Rule: <MCO FAM> <Jumbo> <Design>
The maximum frame size supported on the MCO FAM Ethernet switch is 1632 bytes.
MCO FAM supports jumbo Ethernet frames with a MTU size of 1610 bytes maximum.
7.1.7 LAG

7.2 IPV4
7.2.1 MTU
These flows terminate in the MCO on the P3041Linux processor.
These flows terminate in the MCO on the WP3-SL processor.
7.2.2 OAM Addressing

7.2.3 Telecom addressing
7.2.4 Subnetting
7.2.5 eNB private IPv4 addressing

7.2.6 Routing
7.2.7 IP QoS
7.3 IPV6
Restriction: <MCO> <IPv6> <Design>
SLAAC is not supported at MCO.
7.4 DUAL IPV4/IPV6 STACK

7.5 IPV4 TO IPV6 MIGRATION

7.6 ICMPV6 FOR NEIGHBORING DISCOVERY

7.7 DHCPV6
7.8 SCTP
7.9 SECURITY
he Metro security features are identical to the Macro features, unless otherwise specified.
7.9.1 IPsec
Same functionality as the Macro eNB.
The Ike IDI uses the Certificate subject field. As part of the SA authentication.
The certificate subject is a Domain Name of the form ‘O=Alcatel-Lucent, CN=<Serial
Number>.Alcatel-Lucentcom’. The serial number is the Metros serial number.
PNP is mandatory for Metro deployed nodes. Therefore, certificate based IPsec tunnels are
required. IPsec Pre-shared key configurations for IPsec are not supported as compared to the Macro.
IPsec configurations for Metro eNB are not identical to Macro configurations. Specific Metro PNP
configurations are provided in section 7.9.2.1 Supported PNP Configurations.
7.9.2 eNB Security Plug-N-Play Implementation

The Metro security features are identical to the Macro features, unless otherwise specified.
In addition to the plug and play provided in the Macro, additional capabilities are provided in the
Metro platform.

1. Factory customization of FQDNs (SeGW/ SAM FQDNs, VLAN ID or IP address) are allowed.
2. DNS address resolutions are supported during the Macro PNP deployments.
3. SeGW redirection during PNP deployments are supported.
DNS capabilities are supported on Metro Platforms. Please refer to section 6.10.3 eNB Security Plug-
N-Play Implementation for PNP description. In this scenario the Metro cell has the capability to
1.
allow entries of FQDN (Fully Qualified Domain Names) and DNS addresses for IP address resolution.
This can be achieved via manual configuration or the FQDN/DNS information can be obtained via the
DHCP response. If the FQDN and DNS information are received vi the DHCP, the node will acquire
the IPaddresses of the FQDN entries (seGW FQDN, EMS FQDN).
fqdnSegIPsecTunnel: This parameter specifies the FQDN that resolves to the outer IP address
(IPv4 or IPv6) for the IPsec tunnel at the Security Gateway.
It can be set if and only if the eNB is an eNB-MCI..
Parameter fqdnSegIPsecTunnel
Range & Unit String
(0-128)
Class C
Value NA
Feature 159296
The SeGW redirection capability will be supported in 13.3 release. SeGW redirection is the ability to
change the first SeGW the eNB first communicates with the system compared to the final SeGW
after all the eNB is fully configured.This is done when the SAM sends new MIM DB configuration to
the eNB with a different SeGW configuration (Enb/securityGWFqdn parameter or
IPsecTunnelConf/ipv4AddressSegIPsecTunnel parameter). If the SeGW address was configured via
DHCP in the inital bring of the OA&M tunnel, after the connection to SAM, the new MIM parameters
will contain a different SeGW address than the original SeGW address (Re-direction).
7.9.2.1 Supported PNP Configurations
number represents a VLAN configuration. The N in the VLAN number indicates a NO VLan
configuration.
there are two lines in green. The traffic Oam+S1u+S1c+X2u+X2c of the first line is mapped to an IP
address and the traffic 1588 of the second line is mapped to another IP address).

defined by the set of grey areas in this column. “4”, “6” or (respectively “6over4”) in a column
represent an eNB IP address; “4” means it is an IPv4 address; “6” means it is an IPv6 address, and
“6over4” indicates IPv6 over IPv4.
E.g. the VLAN configuration 5 has 1 VLAN configured as follow:

One VLAN (# 1) with one IPv6 over IPv4 address for OAM+ S1u+S1c+X2u+X2c
One VLAN (# 1) with one IPv4 address for 1588

#N 1 2 3 4 5 6 7 8 9 10
inidca
tes
(no
Vlan)
N-1 Oam+S1u+S1c+X2u+X2c 4 6
ove
r4
1588 (No Ipsec) 4 4
1 Oam+S1u+S1c+X2u+X2c 4 6
ove
r4
1588 (No Ipsec) 4 4
2 Oam 4
1588 (No Ipsec) 4
3 S1u+S1c+X2u+X2c 4
Support IPsec with PSK N N N N N N N N N N
Support IPsec with certificates Y Y Y Y Y
7.9.2.2 Ipsec IPv6 over IPv4 support
Please refer to the Macro IPsec PNP of this document for a detailed description of PNP functionality.
This section describes additional PNP functionality.
The Metro will now support IPv6 over IPv4 in the IPsec tunnel configuration for the OA&M. The outer
tunnel will be IPv4 and the inner tunnel address can be IPv6. The support for the outer and inner
tunnel address having identical protocol types remain.
Supported Outer Tunnel Address Inner Tunnel Address

Yes IPv4 IPv4
No IPv6 IPv6
No IPv6 IPv4
Yes IPv4 IPv6

A new entry value will be used with an existing parameter to distinguish the IPv6 over IPv4
funtionality. VLAN::ipFormat is configured with IPv6overIPv4IPsec.
The IPv6 over IPv4 capability will be compatilble with the following features:
1. IPsec Plug and Play
2. IPsec DNS and redirection
Engineering: <eNodeB> <IPsec> (<IPv6 over IPv4>)
• 1588 and PTP traffic may be within the OA&M VLAN but not inside the IPsec Tunnel.
Engineering: <eNodeB> <IPsec> (<IPv6 over IPv4>)
• Unlike the 3 IPsec VLAN configurations allowed for MACRO configurations.The IPv6 over
IPv4 will only be allowed for 0, 1 or 2 VLAN configurations.
An example of Plug and Play for IPv6 over PIv4 is provided for clarity reason. The eample below
does not show all the possible combinations of IPv6 over IPv4 with PNP. There are many
combinations of factory settings, FQDN and SeGW redirection.
7.9.3 Automatic Security Gateway Discovery (ASGD)

7.9.4 Node Self Commissioning
7.9.5 DOS Attack
7.9.6 Security Enhancements
7.9.7 NAT-T
Service providers that use IPv4 addresses in the ePC core may want to save addresses due to the
limited IPv4 addressing space. One method of conserving space is to use a Network Address
Translation. NAT inherently has an issue with IPsec packets. IPsec in ESP mode encrypts the port
number, source IP and destination IP of the original packet. The source and destination IP are
replaced with the IPsec tunnel address. The port number is not replicated in the IPsec packet. The
NAT device in the network will not be able to translate the IPsec packet from the eNB.In this
scenario the eNB will have the capability to assist in the network NAT function by performing a NAT-
T function. The NAT-T function on the eNB will insert a UDP header with the port number of 4500 .
This allows the external network NAT function to properly map the source packet to the ePC core IP
address.

The NAT-T function must exist on either end of the IPsec tunnel. The NAT-T is automatically
enabled on eith end of the tunnel. NAT-Detectio (NAT-D) is performed in the first few transactions
of the IKE negotiations. The first IKE message sent in the negotiations uses the UDP packet with port
500. The response is sent with addition of a HASH payloads containing source IP address, port
number and another HASH payload with the destination port and port number. The peer that sent
the first message will compare the HASH information to the received packet to compare the
source/destination address. If the packet information does not match the HASH information then a
NAT occurred. The peer that sent the first packet will proceed with the IKE negotiations and
respond with a packet containing the HASH payload of the source address, port number and
Destination address and port number. If NAT had been detected from the remote peer, this packet
will be sent with a port number of 4500. The second peer will perform the same check with the
HASH data as compared to the received packet to determine if NAT had occurred. If NAT had
occurred, then all subsequent messages are sent via port 4500.
Assuming NAT is detected, All subsequent IKE messages are sent port 4500. When the tunnel is
configured and the packets are encrypted in teh ESP payload, the NAT-T will now add an UDP
header to the to the payload with port 4500 such that the IPsec packet can be handled by the
network NAT.
Based on RFC 3948 (UDP encapsulation of IPsec packets) a standard UDP header is attached to the
ESP packet. RFC 768 (UDP data), the UDP header is an additional 8 bytes.

Engineering: <eNodeB> <IPsec> (<NAT-T>)
• MTU consideration must be given to NAT-T. An additional 8 bytes of information is added

when NAT is implemented in the core network.
7.9.8 Secure Boot and Secure Storage

This feature is specifically provided for Metro Cells. These capabilities are not available in the
Macro Cell. Metro Cells are more vulnerable to security exploits due to the physical location of the
cells. The feature will provide the following capabiltities:
1. A secure boot mechanism to autehenticate the LTE MCO software image. Secure boot is the
cryptographic mechanism in the LTE MCO used to authenticate the MCO Softwre image
before booting the MCO. This guarantees that the software image has not been tampered
with.
2. A Secure Storage mechanism to store and use the IKEv2 RSA private key that authenticates
the LTE MCO. Secure Storage is the cryptographic mechanism employed to encrypt and
integrity protect the security credentials like the RSA private key used to authenticate the
MCO device to the EPS and the derive the IPsec session keys.The encryption and storage of
the keys are performed immediately after they are generated in the clear. When the RSA
keys are needed in normal operation, the Secure storage will decrypt the encrypted keys
and provide the information in clear text to the process. The clear text information will be
stored in secure RAM.
Activation of Secure Boot and Secure Storage is automatically performed as part of the 13.3 release.
1. Activation will be performed as part of the factory process prior to deployment in the field.
2. If the deployed MCO is release 13.1 and upgraded to 13.3.
7.9.9 Migration (164959)

There are several secenarios that must be considered due to the nature of this feature.
1. The MCO is in the field with release 13.1 and upgraded to release 13.3. Release 13.3 will be
loaded into the passive software partition. When release 13.3 is activated the Secure Boot
and Secure Storage will be automatically activated. As part of the activation, new CMS
certificates are re-established.

Engineering: <eNodeB> <IPsec> (<Secure Boot and Secure Storage >)
• CMS server is required if release 13.1 upgrade to release 13.3 is performed.
After the MCO has been activated to release 13.3, there is a period of time that the user can
evaluate the release before premanately commiting to release 13.3. Permanately commiting to
release 13.3 will disallow fallback to release 13.1. Fallback to release 13.1 can only performed
when the 13.3 release had not been permantely commited.
Engineering: <eNodeB> <IPsec> (<Secure Boot and Secure Storage >)
• Permantely commiting to release 13.3 should be performed at the earliest convience once
the release 13.3 has been deemed acceptable.
The MCO will allow fallback from 13.3 release to release 13.1. This can only performed
2. Newly deployed release 13.3 MCO. The Secure Boot and Secure Storage are active in release
13.3 and greater.The 13.3 release can be upgraded to 14.1 or later release. In this scenario
both the present and previous release support the Secure Boot and Secure Storagefeature
and there are no special considerations for fallback scenarios. Therefore there is no
requirement to permantely to commit to a active release as in the case of scenario 1.
7.9.10 (LNG) MCO WIFI AP with IPsec
Prior to 14.1 release, the MCO had the ability to support an optional WIFI AP adaptor. The WIFI AP
adaptor is connected to the MCO L2 Switch. In all intent and purposes, the WIFI AP is an
independant module managed by a WI-FI AP controller and connects to a WLAN GW. The WI-FI
controller and WLAN GW are separate equipement that connect to the MCO.
The WIFI AP will be able to perform Plug-N-Play in a similar fashion to the method used in MCO.
Please refer to the MCO section for Plug-N-Play. This section assumes that the reader uderstnads
the MCO Plug-N-Play. There following are the supported models.
1. Model 1, Wi-Fi user plane model using GRE tunnels between the Wi-Fi AP and the WLAN GW
with L2oGRE protocol and Wi-Fi user plane is transported inside the Wi-Fi IPsec tunnel.
The following diagram is a depiction of Model1 architecture.

SAR 9772 WiSC Controller

Ethernet Backhaul
SECURITY
GATEWAY LTE EPC
MME
Wi-Fi AP
and
LTE MCO
UE and Wi-Fi
Mobile LTE OAM
Network SGW/PGW
Wi-Fi IPsec Tunnel SAM

7750 SR Wi-Fi
GATEWAY SAM UI
LTE IPsec Tunnel
AAA Server
Wi-Fi EAP/AKA Traffic
Wi-Fi MINT Traffic
Wi-Fi User Plane Internet Traffic

Mobile Content
LTE OAM Traffic Applications
Internet
LTE Telecom Traffic
The MCO and the WI-FI AP have separate IPsec tuunels to transport their respective OA&M
connections. The AI-FI AP and the MCO can connect to the same SeGW. The SeGW will terminate
both IPsec tunnels (MCO and WI-FI AP). The SeGW will route traffic to the respective OA&M
destination based on the IP destination address in the IP packet once the IPsec decryption has been
performed. The MCO traffic will communicate with the SAM management system. The Wi-Fi AP will
communicate with the WiSC (Wi-FI System Controller).
In this Wi-Fi AP configuration, the Wi-Fi AP user plane traffic, Wi-Fi OA&M and Wi-Fi EAP/AKA traffic
are transported in the same IPsec tunnel. The Wi-Fi AP user plane traffic and Wi-Fi EAP/AKA traffic are
transported in a Wi-Fi GRE tunnel. The Wi-Fi GRE tunnel is transported in the Wi-Fi AP IPsec tunnel.
7.9.10.1 Required components
The following table indicates the required network components to support the various
architectures:

Component MCO Wi-Fi Model 1 (WDC)

SeGW Yes Yes
Wi-Fi Gateway No Yes
Local Broadwband GW No No
External DNS Yes Yes
External DHCP Yes Yes
Internal DNS Yes Yes
Internal DHCP Yes Yes
Wi-Fi Controller No Yes
SAM Yes No
CMS Server Yes No
Engineering: <eNodeB> <IPsec> (<Wi-Fi PNP >)
• Vendor specific Certificates are not supported in Wi-Fi deployments. ALU certificates are
the only certificates supported for authentication.
Engineering: <eNodeB> <IPsec> (<Wi-Fi PNP >)
• It is recommended to different SeGW to support the MCO and Wi-Fi independently.
7.9.10.2 Factory provisioned
The following parameters are provisioned into the WI-FI AP.
1. ALU Certificates
2. The FQDN of the SeGW in the field is provisioned in the Wi-Fi AP.
3. The FQDN of the WiSC in the field is provisioned in the Wi-Fi AP.
4. Default VLAN ID for the IPsec tunnel is provisioned in the Wi-Fi AP
7.9.10.3 Wi-Fi O&AM Connection Flow
Te following diagram depicts the connection flow and communication between the Wi-FI AP and
network components.

External DHCP External DNS Internal DNS

Wi-Fi AP SeGW 9772 WiSC
Server Server Server
DHCP Discover (AP serial number)
DHCP Offer: AP Outer IP address

and External DNS server IP address
Wi-Fi AP request SeGW IP address using SeGW FQDN
External DNS server returns SeGW IP address
IPsec tunnel set between Wi-Fi AP and the SeGW using the factory digital certificates
Wi-Fi AP request AP inner IP address and Internal DNS server IP address
Wi-Fi AP receive AP inner IP address and Internal DNS server IP address
Wi-Fi AP request WiSC IP address to the Internal DNS server using WiSC FQDN
Wi-Fi AP receives WiSC IP address
Wi-Fi AP start communication with WiSC
WiSC start provisioning the Wi-Fi AP
WiSC has completed provisioning the Wi-Fi AP. WiSC has adopted the Wi-Fi AP.
Wi-Fi AP can start providing Wi-Fi over the air services to Wi-Fi subscribers.
This is a similar mechanism to the MCO PNP Flow.
7.9.10.4 Restrictions
1. WI-FI AP IPsec tunnels will be IPv4 outer and IPv4 Inner format only.
7.10 TRAFFIC MANAGEMENT

7.10.1 UL Traffic Shaping

7.11 X2 INTERFACE

7.12 S1 INTERFACE
7.13 IEEE 1588V2 INTERFACE

Same applies as for Macro eNB apart the following which is specific to the Metro cell.
Rule: <MCO> <IEEE1588> <Design>
MCO 1588v2 client is based on the Bell Labs software, with Winpath3-SL as the timestamper.
eNodeB synchronizes with a grandmaster at condition that the grandmasterClockQuality is within

the following values;
timeSource clockClass clockAccuracy
_10 ATOMIC
6 0x20 25ns
_20 GPS 80 primary reference clock 0x21 100ns
84 0x22 250ns
_40 PTP
13
_60 E1 80 application-specific clock 0xFE unknown
84
Restriction: <MCO> <IEEE1588> <Design>
MCO does not support 1588v2 over IPv6.
Restriction: <MCO> <IEEE1588> <Design>
Phase synchronization with 1588v2 is supported and may only be used for eCSFB and eMBMS.
Any other feature requiring phase synchronization requires GPS to be used.

Engineering: <MCO> <IEEE1588>
‘ClockSync::sfnSyncOption’ must be set to:

– ‘freqAndPhaseAndTimeOfDayEnabled’ for eMBMS
- ‘freqAndPhaseOnlyEnabled’ or ‘freqAndPhaseAndTimeOfDayEnabled’ for eCSFB
ptpExcessiveLockLatencyTimer parameter is used.
This timer specifies the time allowed for the client to attempt to lock to the 1588 messages before
triggering the PTP_UNEXPECTED_LONG_INITIALIZATION alarm.
7.13.1 PnP for 1588 IP address(es) acquisition
MCO 1588 IP address and MCO 1588 master(s) IP address(es) may be either provisioned or supplied
through a DHCP procedure.
This (second) DHCP procedure comes after the one which supplies the local OAM (outer) IP address.
PTP IP address(es) supply mode configuration is done through:
• Object: Enb/ClockSync/PTPClientClockSync, Parameter: isPTPipAddressByDHCPenabled, Value :
[true, false], Default: false, Class: A, Service impact: Critical, Update transient impacts details:
full-eNB-reset
The MCO first initialization sequence is as follows:

• Switch on
• DHCP procedure to obtain the OAM IP@
• MIM download
• Reboot (in order to process the Class A parameters)
• First DHCP procedure to obtain the OAM IP@
• If ‘isPTPipAddressByDHCPenabled’ = ‘true’ then trigger a second DHCP procedure to obtain the
1588 IP address and possibly its 1588 master(s) IP address(es)
If this DHCP procedure fails then the alarm ‘PTPipAddressByDHCPfail’ is raised and the DHCP
procedure is repeatedly attempted.
At subsequent reboots, both OAM IP@ and 1588 IP@(s) are retrieved using DHCP each time.
MCO provides the DHCP server with its MAC address through the CHADDR (Client Hardware Address)
field to be used as index. At MCO there is a unique MAC address for 1588 traffic and another unique
MAC address for non-1588 traffic. Therefore the use of CHADDR for indexing the DHCP server can be
used to return an IP@ for 1588.
As an alternative to the CHADDR usage, the MCO also populates the ‘Client-Id Vendor Specific
Information’ in the DHCP request. As for the OAM IP@ delivery (‘Client-Id’ used as index), it uses the
MCO Serialization Number but with the addition of prefix ‘0xAA’. This maintains a unique identifier
for indexing the DHCP for the OAM IP@ and the 1588 IP@.
At DHCP, CHADDR takes precedence over Client-Id.

MCO supported DHCP parameters (in the DHCPOFFER) are:
DHCP parameter
Your IP Address (YIADDR) 1588 IP@
DHCP Option code 1 1588 subnet mask
DHCP Option code 3 Gateway IP@ for 1588 traffic
Vendor Specific Information Option 43 Primary master IP@

Sub-option 6 (Secondary master IP@)
The 1588 IP @s delivery through DHCP is applicable for the following topologies:
(OAM server is assumed to be in the public network)
DHCP (3) MCO Master(s) DHCP (3)

MCO (2) Master(s) DHCP (3)
MCO Master(s)
Network
Private Private Public Public
Type (1)
IP@ DHCP or
n.a. DHCP n.a. DHCP provisioning n.a.
acquisition provisioning
(1) Private = private network behind a Network Address Translation

Public = public routed network (each router supporting DHCP-relay)
(2) There is a constraint of supporting just one (1) 1588v2 client in the private network when the
master is in the public network. This is due to the PTP ports numbering constraint (see §
‘Support of NAT-T’)
(3) DHCPv4 only
7.13.2 Support of NAT-T
MCO may synchronize with 1588 behind a NID which is supporting NAT.
The NAT device supports a single public IP@ for all LTE flows, and maintains a mapping database
between the flows on the private network and the flows in the public network. The NAT must not
modify the UDP port numbers (319 for “Event” messages and 320 for “General” messages) used by
the eNB for the 1588 client running over UDP/IP/Eth protocol stack. Therefore Port Address
Translation for 1588 flow is not allowed. The NAT must function in ‘Port-Forwarding’ mode, where
port numbering is preserved.
This means that;

1. in UL, a PTP packet arriving at the NAT with Source port ‘319/320’ must have only its
Source IP@ changed so that the Source port of the UL egress packet transmitted by the NAT
remains ‘319/320’.
2. in DL, a PTP packet arriving at the NAT with Destination port ‘319/320’must have only its
Destination IP@ changed so that the Destination port of the DL egress packet transmitted by
the NAT remains ‘319/320’.
Since Port Address Translation is not allowed, the NAT function is constrained to IP Address
Translation only which restricts the number of 1588 clients behind the NAT function to 1 (one).
Restriction: <MCO> <IEEE1588> <Engineering>
As a consequence of the need for 1588 UDP ‘Port-Forwarding’ mode, daisy chained MCOs may not
be synchronized with 1588 behind a NID which is supporting NAT.
Note: The mapping for the other flows (eg. Telecom, OAM) from the MCO may be configured using
classic NAT, where the port numbers are renumbered.
As per IEEE1588v2:
• the first ‘General’ message (Unicast_Negotiation_Request) is sent from the client (here
MCO) to the master. This allows the NAT to define Address Translation for ‘General’
messages which use UDP port 319.
• the first ‘Event’ message (Sync) is sent from the master to the client. This does not allow
the NAT to define Address Translation for ‘Event’ messages which use UDP port 320. Thus
the NAT device can’t forward this ‘Event’ message downlink to the client since no Address
Translation mapping is available.
MCO may send the UL ‘Event’ message DELAY_REQ prior to the first DL ‘Event’ message upon
cold/warm/power reset.
This allows the NAT to construct the association between the MCO 1588 private and public IP
addresses, so the association exists when the server sends an Event message to the 1588 client in
the MCO.

Master NAT MCO

clock
MCO anticipates the sending of a Delay request message.
Delay req.
Master discards this unexpected received message.
NAT device updates its mapping table at Delay req. reception.
X t1: the master sends a Sync to the slave.
t1 Sync (with t1 or not) t2: the slave receives the Sync.
If t1 is embedded in Sync this a one-step transfer.
If the grandmaster is able to determine the precise t1 only after
t2 the Sync has been sent then it is sent in the Follow up message.
Follow up (with t1)
This a two-step transfer.
t3: the slave sends Delay request to the master.
t4: the master receives the Delay request and responses with
the Delay response with the precise reception time t4.
Delay req. t3
t4
Delay resp. (with t4)
Figure 124: NAT - procedure for updating the mapping table
NAT activation is done through:

• Object: Enb/ClockSync/PTPClientClockSync, Parameter: isPTPoverNATEnable, Value : [true,
false], Default: false, Class: A, Service impact: Critical, Update transient impacts details: full-eNB-
reset
Rule: <MCO><IEEE1588> <Standard>
ITU-T G.827x series of recommendations specify that in order to deliver phase accuracy it is
necessary for every transport node between the master and the client to support 1588v2 On-Path
Support, by means of either Transparent Clock support or Boundary Clock support.
Restriction: <MCO> <IEEE1588> <Engineering>
If the master for eNB 1588 client is upstream of the NAT device and if the NAT device does not
provide 1588 On-Path Support then NAT function and feature 159405 ‘Synchronization 1588V2 for
eMBMS and eCSFB’ (that brings phase delivery using 1588) are mutually exclusive.
Note: It is requested that the NAT device supports 1588 On-Path Support in order to compensate for
latency of 1588 timing packets added due to Address Translation operation.
If the master is downstream of the NAT device (eg. in a private network) then both NAT and 159405
may be supported.

Engineering: <MCO> <IEEE1588>
PTPClientClockSync::isPTPoverNATEnable must be set to ‘false’ when ‘ClockSync::sfnSyncOption’

is not set to ‘FreqSyncOnly’.
7.13.3 PTP Domain Number
The DomainNumber at eNB PTP client it set to the standard default number (0) and may be
configured to another value. This allows for different Domain Numbers used for the packet flows
from 2 Grandmasters (Primary Grandmaster and Secondary Stand-by Grandmaster).
DomainNumber are configured through:

Object: Enb/ClockSync/PTPClientClockSync, Parameter: ptpClientConfigParameter1, Value : It is a
32 character string. Use 3 characters with range [000…255] to define DomainNumber for
GrandMaster #1; Class: C; Service Impact: None, Update transient impacts details: Immediate-
propagation”
Object: Enb/ClockSync/PTPClientClockSync, Parameter: ptpClientConfigParameter2, Value : It is a
32 character string. Use 3 characters with range [000…255] to define DomainNumber for
GrandMaster #2; Class: C; Service Impact: None, Update transient impacts details: Immediate-
propagation”
7.14 M3 INTERFACE
7.15 IGMPV3 & MLDV2

7.16 M1 INTERFACE
7.17 TRANSPORT COUNTERS


8 MME TRANSPORT IMPLEMENTATION

This chapter covers the description of the MME ALU design.
Please note, beginning with release 13.1, the ALU 9471 MME product name will change to the 9471
WMM (Wireless Mobility Manager). The MAF name will change to the Service Board. The MIF name
will change to the Interface Board.
8.1 CONNECTIVITY
8.1.1 Internal Connectivity
Within a shelf, the intra-shelf communications are provided by the ATCA midplane and the
blades.
Figure 125: ATCA Connector Zones
The ATCA midplane architecture is divided in three zones. The connectors in Zone 1
provide redundant -48VDC power and Shelf Management signals to the boards. The
connectors in Zone 2 provide the connections to the Base Interface and Fabric
Interface. The connectors in Zone 3 are user defined and are used to connect the
hub to the Rear Transition Module.
• Zone 1 is comprised of:
Redundant -48V dual power feed
Metallic test

Ringing generator
Management system connections

Hardware addressing.
• Zone 2 is comprised of:
Keying alignment
Synchronization Clocks
Update Channels
Fabric Interface
Base Interface.
• Zone 3 may be defined as needed for a Rear Transition Module (RTM). There is a direct
connection between front board and RTM (not through the midplane). Specifically,
oRTM allows the 10GigE Base or Fabric links from Zone 3 to provide gigabit ethernet
optical links to the RTM front panel.
8.1.2 Hub Connectivity
8.1.2.1 External Connections
The term “Transport Hub” is used to describe the hub blades in the first equipped chassis
(shelf 0). The Transport Hub terminates external transport interfaces for the system. The
left and right LANs grow outward from Transport Hubs.
In the 9471 WMM configuration, the Ethernet Hubs terminate external transport interfaces
for the system. (These are physical connections.) Optical connections should always be used
if available. However, for customer OA&M networks having only electrical connections, the
electrical ports F0 and F1 on the faceplate of the Ethernet hubs may be used for the OA&M
external interface. These ports may only be used for OA&M and/or LI interfaces. These
ports may be configured as 10baseT, 100baseT, GigE (preferred) or Auto-Negotiate and are
always configured for full duplex. A default gateway must be established for subnet routing
to the configured ports (e.g. LTF0 and RTF0).

Figure 126: Cabling Configuration for oRTM and Faceplate
Legend:
oRTM Usage:
• Up to 13 total optical terminations are allowed on each RTM. The exact number and
configuration is customer-dependent.
• The Optical RTM (oRTM) provides up to 13 (thirteen) GigE ports configurable for 9471
WMM signaling and OA&M. All external connections (transport connections for signaling
and OA&M) to the 9471 WMM are to the oRTM (the front panel of the hub in not used for
these connections when the oRTM is present).
OA&M Connections:
• 1000Base-SX/LX connections are terminated on each Optical RTM (oRTM) to provide
OA&M connections.
• Two 1000Base-T physical connections from the customer’s IP network may terminate on
each Hub’s faceplate (supporting OA&M and/or LI) if optical connections are not
available). NOTE: the front panel of the hub is not to be used for OA&M connections
when OAM network optical connectivity to the oRTM is available.
Signaling Connections:
• The physical configuration of the IP network used to support signaling is customer-
dependent. Typically, four or more 1000Base-SX/LX physical connections from the
customer’s IP network terminate on each Hub’s Optical RTM to support signaling flow.
Alarm Card Connection:
• There is an additional Ethernet connection (not shown) from each Hub faceplate to the
smart alarm card in the cabinet PDU.

Transport connections and link configuration restrictions are further explained in

Section 8.1.3.7.
8.1.2.2 Internal Product Connections
All internal cabling is completed at the factory before the cabinet is shipped to the
customer site.
Figure 127, below shows the hub interconnections on Shelf 0. The two Hubs in Shelf 0 are
connected to the two Hubs in Shelf 1 through a 10GBase-CX4 connection on their faceplate
fabric switch ports. This provides the necessary communication between shelves 0 and 1. All
intra-shelf communications (Hubs 7 & 8 and all other boards on the same shelf) are provided
by the chassis midplane.
Figure 127: Cabling Configuration for Hub Interconnection
PDU power cabling, including power to alarm cards, and all power cabling for chassis
operation is pre-wired as part of the cabinet prior to shipment.
8.1.2.3 Message Path
The oRTM of each hub may have one or multiple connections to a pair of adjacent multi-
layer switches (MLS) or edge router (ER). The MLS/ER pairs are deployed in VRRP
configuration for reliability. There are multiple methods to detect line failures. First a
heartbeat mechanism (using either periodic Address Resolution Protocol (ARP) requests or
periodic pinging) is supported between WMM and MLS/ER to monitor WMM connectivity to
the first hop router. A second alternative method is the Bidirectoinal Forwarding Detection
(BFD). BFD is a low overhead protocol for fast detection of line failures. This ensures that a
failure between the oRTM and the MLS/ER does not require a pair of processor blades to
change act/stby state.

Each processor blade and each ShMC has an internal Ethernet link to each hub card via the
midplane. Both hubs are active and may serve any of the blades. Internal messaging can use
either hub to switch messages between blades.
Figure 128, below shows hub connectivity along with examples of message flows. The path
labeled by blue circles shows an initial signaling message flow. The path labeled by purple
circles shows signaling message flow when the link from MLS A to oRTM is down. (The link
could be down due to a failure in the oRTM or the MLS.) The path labeled by orange circles
shows an OAM message flow through the oRTM. Note: the legend following the figure defines
the step-by-step message flow for each path.
Figure 128: MME Hub Connectivity
Legend:
Signaling message flow using active oRTM (denoted by numbers in blue circles):

1 eNodeB sends a message to the L3 switch on MLS A; the message is switched

to L2.
2 Message from MLS A L2 switch arrives at the active S1-MME signaling
interface of the oRTM.
3 The oRTM transfers the message to the HSPP4/MPH, then the HSPP4/MPH
transfers the message to the Hub.
4 MME Hub switches the message over the midplane (internal LAN) to the MIF.
5 Interface Board selects a Service Board (uses previously selected Service
Board if UE is already attached) and sends the message to the Service Board
via the Hub.
The Service Board sends a return message in the reverse direction: to the
Interface Board via the Hub, the Interface Board sends the message to the
oRTM via the Hub, then the messages -050goes out from the active signaling
interface on the oRTM to the L2 switch.
Signaling message flow when the link from MLS A to oRTM is down (denoted by
numbers in purple circles):
1 eNodeB sends a message to the L3 switch on MLS A; the message is switched
to L2.
2 The link from MLS A to the oRTM is down, so the message is sent to MLS B.
MLS B selects a port on the redundant oRTM.
3 Message from MLS B L2 switch arrives at the active S1-MME signaling
interface of the oRTM.
4 The oRTM transfers the message to the HSPP4/MPH, then the HSPP4/MPH
transfers the message to the Hub.
5 MME Hub switches the message over the midplane (internal LAN) to the MIF.
6 Interface Board selects a Service Board (uses previously selected Service
via the Hub.
The Service Board sends a return message in the reverse direction: to the
Interface Board via the Hub, the Inteface Board sends the message to the
oRTM via the Hub, then the messages goes out from the active signaling
interface on the oRTM to the L2 switch.
Signaling message flow when Primary Interface failure occurs (denoted by numbers in
Red circles)
1. eNodeB sends a message to the L3 switch on MLS A.

2. The link from MLS A to the oRTM is down, so the message is sent to MLS B.
MLS B selects a port on the redundant oRTM.
3. Message from MLS B arrives at the active S1-MME signaling interface of the
oRTM.
4. The MPH associated with Hub 7 is the active MPH, so the message is sent
from the oRTM (8) to Hub 8, and than transfers the message to the MPH on
Hub 7.
5. The MPH switches the message over the midplane (internal LAN) to the MIF.
6. Interface Board selects a Service Board (uses previously selected Service
via the Hub. The Service Board sends a return message in the reverse

direction: to the Interface Board via the Hub, the Interface Board sends the
message to the oRTM via the Hub, then the messages goes out from the
active signaling interface on the oRTM to the L3 switch.
OAM message flow through oRTM (denoted by numbers in orange circles):

The OAM message flow to/from the OAM Server follows a similar path from
EMS, except messages go to the OAM Server instead of the blade housing
MIF/MAF.
1 Message from the element management system (EMS) arrives at the MME
Hub via the oRTM on the active OAM interface. (The EMS for the 9471 WMM
is the 5620 SAM.)
2 The MME Hub switches the message to the OAM Server over the midplane
(OAM messages do not use the MIF).
3 Return messages go in the reverse from OAM Server to MME Hub, to the
oRTM, then out from the active OAM interface to the L2 switch.
8.1.3 Internal IP Addresses and Subnetworks
This section provides descriptions of the 9471 WMM

• Internal IP subnetworks
• hardware-related subnetworks and IP addressing
• Internal service-related subnetwork and IP addressing.

See 9471 WMM Configuration Management, 418-111-207, for IP address subnetwork
configuration procedures and additional details.
8.1.3.1 Initial Configuration
For a new installation, the MME application is loaded, the services and internal/external
subnets are configured, and the provisioning is completed based on the customer’s needs.
This is completed as part of the field install procedure. See 9471 WMM Configuration
Management, 418-111-207 for details and procedures.
Rule: <MME> <Install>

Regardless of the internal subnet defined for the MME, always use the
following values for the internet protocol properties of the laptop during field
install:
• IP address = 169.254.15.2
• Subnet mask = 255.255.0.0
• Default gateway = blank

This static IP address is removed once the install is complete.
Meaningful System Name, an Application Name (for MME, the application is always
9471_MME), and a meaningful System Prefix should be selected based on their ability to
distinguish this MME from other MMEs in the network.

The system name and system prefix of the MME should be selected based on
their ability to distinguish this MME from other MMEs in the network.

The application name for MME is always 9471_MME.
A class B subnet is then selected for internal MME communication. The customer is strongly
encouraged to keep the default internal value of 169.254.0.0. The internal subnet allows all
MME elements (ShMC, hub, OAM server, MIF, MAF, alarm card) to communicate with each
other. Internal IP addresses are automatically assigned from the defined subnet.

The customer must select a Class B subnet for internal MME communication.
The customer is strongly encouraged to keep the default internal value of
169.254.0.0.
All redundant MME elements (ShMC, hub, OAM server, MIF, MAF) have a host-active, host-
standby and internal service subnet. Elements also have DHCP and local subnet IP addresses,
and the hubs have an external service subnet.

All diskful services (CNFG, MI) are assigned to the OAM server (slots 1 & 2);
hub services are assigned to the hub slots (slots 7 & 8); ShMC services are
assigned to the ShMC (slot 15).
Note: All MIF and MAF provisioning data is stored on the OAM server disk and
brought down to the MIF or MAF at initialization time.
8.1.3.2 Default Gateway and Static Routes
The MME may be provisioned to have both a default gateway and static routes for outgoing
messages routing functionality. The following describes the configurations that can occur:
• For the OA&M network, one default gateway must be established for subnet routing
terminating to the two MLSs connected to the oRTM ports for OAM. If additional subnet
routes are required (such as for supporting DNS on a separate subnet), then a static
route, to another MLS pair, must be provisioned for each secondary route.

The following is required to properly configure OAM services on the MME:
• Subnet IP (externally routable IPv4 subnet)
• Netmask
• Gateway offset for each service

1 offset from the OAM IP address for a floating CNFG address
3 offsets from the OAM IP address for MI addresses (2 fixed, 1 floating)

• Hub port for transport interface

The OAM subnet may be the same as the signaling subnet, but
the MME does not support IPv6 for OAM interfaces.
• For MME Signaling network, one default gateway must be provisioned for subnet routing
terminating to the two MLSs attached to the oRTM ports for Signaling. If any additional
connections are established using other MLS switches or subnets, then static routes, to
those MLS pair(s), must also be provisioned for those subnet routes.
Note:
For WM7.0.0 and later releases, static routes are no longer needed because of Source Based
Routing

The following is required to properly configure signaling services on the MME:
• Subnet IP (externally routable IPv4 or IPv6 subnet)
• Netmask
• Gateway offset for each service

1 offset from the signaling IP address for each type of signaling interface (S1-
MME, S6a, S10, S11, SGs, Gn, S3, S13) for floating IP addresses
1 additional offset for a default floating IP address

• Hub port for transport interface
Signaling services can be configured to share the same IP
address, but this is not recommended. Unique offsets for each
interface are recommended.
Note: IPv6 is not supported for SGs or Gn interfaces.
8.1.3.3 Recommendations
Several engineering recommendations are listed below. Customers are encouraged to

review their configuration to ensure compatibility with their network.
<Recommendation> <MME> <Config>

The recommended OAM IP subnet is 10.152.2.0/28.
Individual IP addresses are needed for each VLAN interface, the VRRP in the
VLAN, each OAM blade, the floating OAM address, and the floating CNFG
address (7 total IP addresses on OAM blades).

The recommended application IP subnet is 10.152.2.32/27.
Individual IP addresses are needed for each signaling interface type, the

default IP address, each VLAN interface, and the VRRP in the VLAN.

The recommended SOL subnet is 10.152.2.16/29.
Individual IP addresses are needed for SOL on each hub, SSH on each hub, and
each VLAN interface.

Up to 3 NTP servers may be configured.
Each NTP server has a unique IP address.

Signaling interfaces (S1-MME, S6a, S10, S11, S3, S13) support IPV4 and IPv6
floating addresses.
The MME does not support IPv6 for OAM interfaces, SGs or Gn interfaces.

All the IPv6 addresses (example, 2001:DB8:0000:0000:0202:B3B3:EE1E:8320)
should use the same prefix.
An IPv6 address consists of 64 bits of global routing prefix and subnet ID and
64 bits of interface ID. The global routing prefix identifies the network. The
subnet identifies a link within a site. The interface ID identifies an interface
within that sub network.
8.1.3.4 Internal subnetworks
Within the 9471 WMM six internal IP subnetworks (subnets) are used to route internal IP
messages between the different cards and processes that are running on these cards. Each
component has an IP address in each of the hardware subnets (Host, DHCP, LSN subnets)
according to standard formulas.
For example, the following IP addresses are in the Host Subnet. In this example, the fixed IP
address for the first OAM Server host in the first shelf is 169.254.64.16.

Legend:
Formula for the fixed IP address of a Node (host) in the Host Subnet = x.y.(64+s).(cx16+h)
Where:
The recommended value of x.y for internal subnets is 169.254. However, customers may
change this during planning for initial configuration.
c = Card/Slot number
s = Shelf Number
h = Host number.
NOTE: h = 0 for every card except HSPP4 host on the hub and ShMC.
For HSPP4 host on the hub, h = 4.
For ShMC, h = 0 for the virtual IP; h = 1 for the upper card; h = 2 for the lower card.
Internal subnets are used for internal communication among hosts within the 9471
WMM. These subnets do not route out of the 9471 WMM. These subnets are
predefined and are reusable by multiple 9471 WMM systems.
The subnetworks used can be divided into:
• Five hardware-related subnetworks - (Host Subnet, DHCP0 Subnet, DHCP1 Subnet, LSN0
Subnet, and LSN1 Subnet). Refer to Section 8.1.3.9.6 for additional information
regarding IP addressing and naming within the WMM.
• One service-related subnetwork.
8.1.3.5 External Subnetworks
External subnets are assigned to services within the 9471 WMM that need to communicate
with entities outside the 9471 WMM or within the customer network. These subnets are
provided by the customer.
Tip: the externally routable service subnets are sometimes informally called “transport”
subnets.
Calculations for addresses are done automatically by the system once the base is assigned.
Examples of externally routable service subnets are:

• Signaling (control) routable subnet - For communicating with services in the customer
signaling network
• OAM&P routable subnet - For communicating with services in the customer OAM&P
network (element or network management systems)
Notes:
• You might see two service addresses for MI and CNFG on the GUI; though the signaling
address may not be used.
• Externally routable service subnets should be large enough for growth as applicable.
• Each externally routable service subnet MUST be unique if visible to each other.
• Externally routable subnets and transport subnets MUST be different and non-
overlapping.
• The OAM&P subnet usually includes IP addresses for SSH and Serial Over LAN (SOL)
connections. Customers may optionally put these IP addresses in a separate subnet.

• MI and CNFG have IP addresses in the OAM&P Routable subnet; product-specific services
do not.
• MI and CNFG hosts do not need signaling address, but may have them for optional
features like DNS queries.
• Product-specific services have IP addresses in the Signaling Routable subnet. If there are
8 services, there are 8 IP addresses in the subnet.
• On the element management system side, the EMS has two IP addresses: one for the
active EMS and one for the standby EMS. Traps are sent to both IP addresses, since the
MME does not know which is active and which is standby.
8.1.3.6 Multiple IP addresses per component
In order to better understand the functions and necessity of the different subnetwork types,
it is useful to know that within a cabinet each component:
• Can have multiple IP addresses at the same time.

• The IP addresses can belong to different subnetworks.
MME supports assignment of the same IPv4/IPv6 subnet for all the GigE interfaces or a
different IPv4/IPv6 subnet for each GigE interface.
8.1.3.7 Transport connections
Transport connections are Ethernet connections between the MME and the external
network. In the following figures, examples of these connections are shown as colored lines
between the RTMs in the MME and the MLSs (multi-layer switches).
A redundant link group is a set of interfaces that includes an active GigE and its associated
standby link(s). Assignment of MME logical interface traffic to a redundant link group is
supported such that one group can be assigned to carry only S1-MME traffic, another group
can be assigned to carry S6a, and a third group can be assigned to carry all other traffic.
Each redundant link group has a Virtual IP address (VIP) assigned to an MME interface active
link. Each active link and standby link has its own physical IP address. The VIP address is
floated over to the standby link upon failover.
The MME currently supports GigE connectivity enhancements (1+1 GiGe) that reduce the
number of GigE links required and eliminates an MPH switch over if all physical interfaces
carrying an MME traffic fail on a active HUB or oRTM. From previous releases, this
configuration change:
• Reduces the number of GiGE links required by half as redundant GigE links are not
required on the same oRTM.
• Allows traffic of an MME interface on a GigE link on an RTM to be switched to a GigE link
on the other RTM without an MPH switch occurring.
• Allows an MPH switch over without requiring a switchover of GigE links.
Figure 129 shows two GiGE interfaces for redundancy (opposed to 4 interfaces in previous
releases). This figure also shows the use of BFD for fault detection which is introduced in
this release.

Figure 129: MME Network Connectivity
Note: MH-SCTP and BFD links are mutually exclusive.
In the new 1+1 GiGe configuration, there will be one primary GIGE connection from MPH 0
oRTM to MLS A. A second redundant GiGE connection from MPH1 oRTM to MLS B is provided
for failover purposes. The active link is always on the active MPH and transmits and receives
all traffic. One link on each MPH is designated as the primary link. The primary link is
always used as the active link after system initialization on the active MPH. The two Hubs
are connected by way of their internal Fabric switches. The active MPH can connect to both
MLS's. A switchover of the RTM does not require a switchover of MPH (or vice versa) so that
traffic can be forwarded to and from the active MPH from either oRTM.
If the active link fails, MME attempts to failover to the standby link on the same MPH. If the
standby link is down on the active MPH then MPH failover occurs. One port is reserved for
port mirroring (port 12).
The following link configuration is an example of 1+1 GiGe interface mapping:

Left Right Link Function Redundant Scheme

Hub/RTM, Hub/RTM,
Slot 7 Slot 8
0 0 OAM (and/or DNS and/or CALEA
network(s))
1 1 S1-MME
MME SCTP-MH
2 2 S6a SCTP-MH
3 3 SGs SCTP-MH
4 4 Not Used in this example
5 5 SLs SLg SCTP-MH
6 6 S11 DNS BFD
7 7 S10 BFD
8 8 S3 BFD
11 11 Gn BFD
12 12 Debug (port mirroring) NA
Alcatel-Lucent

Figure 130: Port Connectivity for oRTM
Figure 130 shows an example of transport connectivity for a customer with 1 OAM network
and 7 distinct signaling networks.
A Layer 2 cross-connection can be provided in the external network (shown in the “L2”
portion of each MLS) among the ports serving a set of redundant transport connections. The
layer 2 cross connection will be dependant on the redundant scheme used. As an example,
BFD assumes there is no layer 2 cross connection between the oRTMs and MLSs.
• All ports serving the set of transport connections (i.e., all of the same color in the
figure) must be in the same broadcast domain.
Each subnet used for external communication must be configured on exactly one set of
redundant Transport Connections. Multiple subnets can use the same set of connections, but
a subnet cannot be present on more than one set. For example, the IP addresses used for S1
and S11 could be in the same subnet, but the IP addresses used for S1 and S6a must be in
different subnets.
Each subnet used for external communications must be configured with exactly one default
gateway (next hop routing address) that will be used by the MME for associated outbound
packets.
8.1.3.8 Virtual Local Area Networks (VLANs)
8.1.3.8.1 Internal VLANs
A VLAN is a group of hosts that communicate as if they were attached to the Broadcast
domain, regardless of their physical location. Reconfiguration can be done through software
instead of physically relocating devices.
There are different VLANs defined for different purposes. Therefore, each Host will have:
• Untagged interfaces for the use of DHCP and Transport connections
• Tagged interfaces for use of Internal Subnets (Internal Service and Host Active subnets
in the 800 series of VLAN tags)
• Differently tagged interfaces for use of External Subnets (External Service subnets in the
400 and/or 600 series of VLAN tags)
For the untagged and internal VLANs, the Left Hub broadcast areas and the Right Hub
broadcast areas DO NOT INTERCONNECT. That means a Broadcast from an untagged or
internally tagged interface on eth0 will not be seen by any eth1 interface of any host
(exceptions are of the Hosts on the Hubs and ShMCs) irrespective of the number of shelves
in the configuration.

Figure 131: MME VLAN Configuration
The following table lists all of the VLANs defined on the 9471 WMM Hubs:
Alcatel-Lucent

Range Category Use Block Left Hub Right Hub

Untagged (e.g., for DHCP
300 Platform 300 300 301
requests
External Service F-0 –
400 400 401
GE0, Hub Front
External External Service F-1 –
410 410 411
Service – GE1, Hub Front
400
Hub Front External Service F-2 –
Panel 420 420 421
Used for alarm panel
External Service F-3 –
430 430 431
GE3
600 Transport R-0 – GE0 600 600 601
and Transport R-1 – GE1 610 610 611
700
Transport R-2 – GE2 620 620 621
Transport R-3 – GE3 630 630 631
Transport R-4 – GE4 640 640 641
Transport – Transport R-5 – GE5 650 650 651
Hub oRTM Transport R-6 – GE6 660 660 661
Transport R-7 – GE7 670 670 671
Transport R-8 – GE8 680 680 681
Transport R-9 – GE9 690 690 691
Transport R-10 – GE10 700 700 701
Transport R-11 – GE11 710 710 711
Internal
800 Services on ATCA Shelf 800 800 801
ATCA Shelf
Note: Different VLANs are used for different purposes:

• VLAN 300 is used for DHCP requests and responses in the Left Hubs.
• VLAN 301 is used for DHCP requests and responses in the Right Hubs.
• VLANs 400/401 is used in the Left/Right Hubs for External Subnet IP Addresses accessed
from the customer network over the Hub front panel connections in port FP GE0.
from the customer network over Hub front panel connections in port FP GE1.

• VLANs in the 600 and 700 range are used for the Rear Transition Module (RTM) in the
same fashion as the 400 range VLANs. Note that port 12 (Transport R-12 -GE12) is
reserved for port mirroring so VLANs are not assigned.
• VLAN 800/801 is used in the Left/Right Hubs (slots 7 and 8, respectively) for all IP
addresses that stay on the ATCA shelf. Neither of these VLANs is configured on any port
of the Hub connected to the customer network.
• Other VLANs in the 800 range will be configured on the Hubs for use by other
Applications, however 9471 WMM will not use them on their Hosts.
• Recommended OAM VLAN 905
• Recommended application traffic VLAN 906
• Recommended SOL VLAN 907
8.1.3.8.2 External VLANs
In release LM 4.0.1 the MME had introduced a new capability of tagging oRTM external transport
links with VLAN (801.1Q) tag Ids. The MME will receive and transmit 801.1Q tagged packets to/from
the customers MLS A and MLS B routers. Not all interfaces are required to be VLAN tagged. The
customer can choose which interface to VLAN tag or Not tagged.
The external VLAN id can be a resuse of a VLAN Id used in an internal VLAN.
External VLAN tags are assigned per subnet and transport. The same tag can be reused on a per
interface basis.
Restriction: <MME> <VLAN> <Design>
VLAN tags for LAG interfaces are not supported.
Restriction: <MME> <VLAN> <Design>
VLAN configuration is performed during installation. Please refer to the MME Field install guide for
configuration commands.
– Combination of FI/FI GUI, SCDT and IP_adm configuration
Rule: <MME> <VLAN>

The VLAN Value can be between the range of 1 - 4094

It is recommended that the VLAN value be a value of 2 – 4094. In some
systems the VLAN value of 1 is a default broadcast VLAN.
The MME will only send or receive a single tagged ethernet frame and that frame will have a well
defined TPID of 0x8100. MME does not support of mapping of DSCP to the user priority bits in the
802.1Q header.

There are measurement counters for transmitted and received Ethernet frames per VLAN.
8.1.3.8.3 MME Support for VLAN Growth/De-growth
The MME supports the growth of IPv4 and/or IPv6 addresses for IPs configured for multi-homing, BFD
and ACM. Growth of IPv4 and/or IPv6 subnets for specific network interfaces is also supported.
Degrowth for IPv4 addresses and subnets are also supported.
Growth refers to the adding of a new or a secondary IP address or subnet to a pre-configured VLAN
or the creation of a new VLAN with an associated IP address or subnet.
The subnets can be grown on an OAM, MIF or MPH. The same VLAN can also be grown across
different transports. Large packets can be segmented across a VLAN.
The specific procedures for growing and de-growing IP subnets with VLANs in various scenarios are
described in detail in section 7 of the Release 6.0.1 MME OAM guide (Alcatel-Lucent 9471 Wireless
Mobility Manager (WMM) Operations, Administration, and Maintenance 418-111-201WM6.0.1). Please
refer to this documentation to perform the growth and degrowth.
At a high level, the below commands are a sample of the IPv4 and IPv6 growth methods
respectively.
IPv4 Growth:
ip_adm –a add_subnet –e <redundancy mode> -b <subnet base> -m <subnet mask> -n <subnet name> -s
<subnet number> -o <IPv4 gateway offset> -t <transport ID1[,transport ID2]> [-v <vlanid1, vlanid2>]
IPv6 Growth:
ip_adm –a add_subnet –e <redundancy mode> -b <subnet base> -m <prefix length> -n <subnet name> -s
<subnet number> -o <IPv6 gateway> -t <transport ID1[,transport ID2]> [-v <vlanid1, [vlanid2]>]
8.1.3.9 Hardware-related Subnetworks and IP Addressing
The internal hardware-related subnetworks can be divided into the following different
subnetwork types:
• Host Subnet
• DHCP0 Subnet
• DHCP1 Subnet
• LSN0 Subnet
• LSN1 Subnet Host Subnet
8.1.3.9.1 Host Subnet

The Host subnet is used to communicate with Host IP addresses of other hosts. Each host,
including the Hub and ShMC host is associated with a Host IP address and tagged interfaces
in VLANs (eth0.800 and eth1.801). The host IP address exist on both backplane interfaces in
the tagged VLANs.
Note: The host subnet assigns each Host a specific IP address based on the Shelf number,
Slot Number, and Host Number. Host Subnet is also known as Host Active Subnet. The Hub
cards have the host active addresses only on ONE interface, whereas in Node cards host
active addresses are on both interfaces. The Host Active address on Hub 7 is in VLAN 800
while on Hub 8, it is in VLAN 801. The interface to VLAN correlation is opposite between
Hub 7 and Hub 8.
8.1.3.9.2 DHCP0 Subnet
The DHCP0 subnet is used for DHCP requests and responses in the untagged VLAN 300 which
spans the Left Hubs, and does not go out to the customer network.
A booting diskless host or a jumpstarted diskful host would send a DHCP request broadcast.
This broadcast would be untagged and hence interpreted by the switch to be in VLAN 300.
The DHCP server (the OAM Server) would respond to this request if configured to respond to
the hardware MAC address of the requesting host. It would give the requesting device,
among other things, an IP address in the DHCP0 subnet for its eth0 interface. A host will
first attempt a DHCP request on its eth0 interface. If no response is received, a request is
attempted on its eth1 interface.
8.1.3.9.3 DHCP1 Subnet
The DHCP1 subnet is used for DHCP requests and responses in the untagged VLAN 301 which
spans the Right Hubs, and does not go out to the customer network.
A booting diskless host or a jumpstarted diskful host would send a DHCP request broadcast
in VLAN 301. The DHCP server (the OAM Server) would respond to this request if configured
to respond to the hardware MAC address of the requesting host. It would give the requesting
device, among other things, an IP address in the DHCP1 subnet for its eth1 interface.
8.1.3.9.4 LSN0 Subnet
The LSN0 subnet is used for communicating with other LSN0 IP addresses. The path of any
packets using LSN0 IP addresses will only traverse the Left Hub Switches.
The LSN0 subnet is associated with eth0 for all Hosts and tagged interfaces in VLAN 800 on
the Left Hubs. The only exceptions are the slot 8 (Right Hub Host) and the Bottom ShMC, on
which the eth1 interface has a presence in VLAN 800.
Note: All hosts have the same interface/vlan correlation (LSN0 on eth0 vlan 800 and LSN1 on
eth1 vlan 801) EXCEPT for the hub in slot 8 (the right hub) and the bottom ShMC. These two
hosts have the interfaces flipped with respect to the other hosts in the system. The LSN0 IP
is on the eth1.800 interface and the LSN1 IP is on the eth0.801 interface.
8.1.3.9.5 LSN1 Subnet
The LSN1 subnet is used for communicating with other LSN1 IP addresses. The path of any
packets using LSN1 IP addresses will only traverse the Right Hub Switches.
The LSN1 subnet is associated with eth1 for all Hosts and tagged interfaces in VLAN 801 on
the Right Hubs. The only exceptions are the slot 8 (Right Hub Host) and the Bottom ShMC,
on which the eth0 interface has a presence in VLAN 801. These two hosts have the
interfaces flipped with respect to the other hosts in the system.
8.1.3.9.6 IP Addressing and Naming
This table lists the IP addressing and naming convention that is used within the 9471 WMM:

Slot/ Card Type of RCC active IP address Example IP

card interface address for
name shelf 0
Node -eth0
Left N/A x.y.(0+s).(c×16+h) 169.254.0.16
(DHCP0)
Node -eth1
Right N/A x.y.(16+s).(c×16+h) 169.254.16.16
(DHCP1)
Node - AXXXX-
eth0.800 Left s<nn>c01h0- x.y.(32+s).(c×16+h) 169.254.32.16
01 (LSN0) 1
Node - AXXXX-
eth0.801 Right s<nn>c01h0- x.y.(48+s).(c×16+h) 169.254.48.16
(LSN1) r
Node (Host) Left N/A x.y.(64+s).(c×16+h) 169.254.64.16
Node (Host) Right N/A x.y.(64+s).(c×16+h) 169.254.64.16
Node -eth0
Left N/A x.y.(0+s).(c×16+h) 169.254.0.32
(DHCP0)
Node -eth1
Right N/A x.y.(16+s).(c×16+h) 169.254.16.32
(DHCP1)
Node - AXXXX-
02 (LSN0) 1
Node - AXXXX-
(LSN1) r
Node -eth0
Left N/A x.y.(0+s).(c×16+h) 169.254.0.48
(DHCP0)
Node -eth1
Right N/A x.y.(16+s).(c×16+h) 169.254.16.48
(DHCP1)
Node - AXXXX-
03 (LSN0) 1
Node - AXXXX-
(LSN1) r
Node -eth0
Left N/A x.y.(0+s).(c×16+h) 169.254.0.64
(DHCP0)
04
Node -eth1
Right N/A x.y.(16+s).(c×16+h) 169.254.16.64
(DHCP1)


name shelf 0
Node - AXXXX-
(LSN0) 1
Node - AXXXX-
(LSN1) r
Node -eth0
Left N/A x.y.(0+s).(c×16+h) 169.254.0.80
(DHCP0)
Node -eth1
Right N/A x.y.(16+s).(c×16+h) 169.254.16.80
(DHCP1)
Node - AXXXX-
05 (LSN0) 1
Node - AXXXX-
(LSN1) r
Node -eth0
Left N/A x.y.(0+s).(c×16+h) 169.254.0.96
(DHCP0)
Node -eth1
Right N/A x.y.(16+s).(c×16+h) 169.254.16.96
(DHCP1)
Node - AXXXX-
06 (LSN0) 1
Node - AXXXX-
(LSN1) r
Node -eth0
Left N/A x.y.(0+s).(c×16+h) 169.254.0.96
(DHCP0)
Node -eth1
Right N/A x.y.(16+s).(c×16+h) 169.254.16.96
(DHCP1)
07 Node - AXXXX-
(LSN0) 1
Node - AXXXX-
(LSN1) r


name shelf 0
Hub -eth0
Left N/A x.y.(0+s).(c×16+h) 169.254.0.128
(DHCP0)
Hub -eth1
Right N/A x.y.(16+s).(c×16+h) 169.254.16.128
(DHCP1)
Hub -
08 eth0.800 Left N/A x.y.(32+s).(c×16+h) 169.254.32.128
(LSN0)
Hub -
eth0.801 Right N/A x.y.(48+s).(c×16+h) 169.254.48.128
(LSN1)
Hub (Host) Right N/A x.y.(64+s).(c×16+h) 169.254.64.128
Node -eth0
Left N/A x.y.(0+s).(c×16+h) 169.254.0.144
(DHCP0)
Node -eth1
Right N/A x.y.(16+s).(c×16+h) 169.254.16.144
(DHCP1)
Node - AXXXX-
09 (LSN0) 1
Node - AXXXX-
(LSN1) r
Node -eth0
Left N/A x.y.(0+s).(c×16+h) 169.254.0.160
(DHCP0)
Node -eth1
Right N/A x.y.(16+s).(c×16+h) 169.254.16.160
(DHCP1)
Node - AXXXX-
10 (LSN0) 1
Node - AXXXX-
(LSN1) r
Node -eth0
Left N/A x.y.(0+s).(c×16+h) 169.254.0.176
(DHCP0)
11
Node -eth1
Right N/A x.y.(16+s).(c×16+h) 169.254.16.176
(DHCP1)


name shelf 0
Node - AXXXX-
(LSN0) 1
Node - AXXXX-
(LSN1) r
Node -eth0
Left N/A x.y.(0+s).(c×16+h) 169.254.0.192
(DHCP0)
Node -eth1
Right N/A x.y.(16+s).(c×16+h) 169.254.16.192
(DHCP1)
Node - AXXXX-
12 (LSN0) 1
Node - AXXXX-
(LSN1) r
Node -eth0
Left N/A x.y.(0+s).(c×16+h) 169.254.0.208
(DHCP0)
Node -eth1
Right N/A x.y.(16+s).(c×16+h) 169.254.16.208
(DHCP1)
Node - AXXXX-
13 (LSN0) 1
Node - AXXXX-
(LSN1) r
Node -eth0
Left N/A x.y.(0+s).(c×16+h) 169.254.0.224
(DHCP0)
Node -eth1
Right N/A x.y.(16+s).(c×16+h) 169.254.16.224
(DHCP1)
14 Node - AXXXX-
(LSN0) 1
Node - AXXXX-
(LSN1) r


name shelf 0
ShMC –
Virtual N/A x.y.(64+s).(c×16+h) 169.254.64.240
eth0:rmcp
ShMC1 –
Upper N/A x.y.(32+s).(c×16+h) 169.254.32.241
eth0
ShMC2 –
15 Bottom N/A x.y.(48+s).(c×16+h) 169.254.48.242
eth0
ShMC1 –
Upper N/A x.y.(48+s).(c×16+h) 169.254.48.241
eth1
ShMC2 –
Bottom N/A x.y.(32+s).(c×16+h) 169.254.32.242
eth1
Notes:
1. In the RCC active interface name column, <nn> = Shelf number
2. In the RCC active interface name column, c = Card/Slot number
3. In the IP address column, s = Shelf Number
4. In IP address column, c = Slot/Card number
5. In the IP address column, h = Host number. h = 0 for every card except ShMC. For ShMC, h
= 0 for the virtual IP; h = 1 for the upper card; h = 2 for the lower card.
6. In the RCC active interface name column, AXXXX = The Switch or customer site prefix
(where A must be an alphabetic (a-z) and XXXX must be an alphanumeric (a-z, 1-9)).
8.1.3.10 Internal Service-Related Subnetwork and IP Addressing
An internal service subnetwork is a range of private IP addresses that can be assigned to

services running on Processor cards.
IP addresses are assigned by the 9471 WMM.
There is only one service-related subnet.
8.1.3.10.1 Service Subnetwork Types
The service-related subnetwork can be divided into the following different IP address
ranges:
• Internal fixed IP addresses - An internal fixed service IP Address is an IP address that
remains associated with a particular instance of a service, regardless of whether that
instance is active or standby.
• Internal floating IP addresses - An internal floating service IP Address is an IP Address
that is moved (floated) to an instance of a service that is currently in the active state.
NOTE: Provisioning of IPv4 and IPv6 floating addresses is supported for MME interfaces:
S1-MME, S10, S11, S6a, M3, SLs, SLg, SBc, Sm, S13 and S3. MME does not support IPv6 for
OAM interfaces not SGs and Gn interfaces.
8.1.3.10.2 Subnetwork IP Address Ranges

The table lists service subnetwork conventions that are used:
IP Address Range Network Mask

169.254.128.0 - 169.254.191.255 255.255.128.0
169.254.192.0 - 169.254.255.255
8.1.3.10.3 Service-related Subnetwork Mapping
The following table lists examples of the service subnetwork conventions that are used for
application interfaces (resident on the MIF-supporting traffic blades). Note that these are
simply examples and not all interfaces are included. Key takeaway is that each interface
must have a unique IP address (4th digit in address must be unique).
Interface IP address
S1 169.254.249.33/27
S3 169.254.249.34/27
S6a 169.254.249.35/27
S10 169.254.249.36/27
S11 169.254.249.37/27
S13 169.254.249.38/27
Gn 169.254.249.7/27
Default 169.254.249.59/27
First VLAN 901 169.254.249.60/27
Second VLAN 901 169.254.249.61/27
VLAN VRRP 901 169.254.249.62/27
Table 64: Example IP Addresses for MME Application Interfaces

The following table lists the service subnetwork conventions that are used for each of the
OA&M services on the OAM servers.
MME slot 1 OAM server 169.254.249.1/28
MME slot 2 OAM server 169.254.249.2/28
MME OAM floating IP 169.254.249.3/28
MME CNFG floating IP 169.254.249.4/28
first VLAN 900 IP 169.254.249.12/28
second VLAN 900 IP 169.254.249.13/28
VLAN VRRP 900 IP 169.254.249.14/28
Table 65: Example IP Addresses for MME OA&M Interfaces

The following table lists the service subnetwork conventions that are used for each of the
Ethernet Hub card servers (includes SSH and Serial-over-LAN [SOL]).
Slot 7 Ethernet Hub card SSH IP 169.254.249.17/29
Slot 7 Ethernet Hub card SOL IP 169.254.249.18/29
Slot 8 Ethernet Hub card SSH IP 169.254.249.19/29
Slot 8 Ethernet Hub card SOL IP 169.254.249.20/29
7750-2 VLAN 902 IP 169.254.249.21/29
7750 VLAN 902 IP 169.254.249.22/29
Table 66: Example IP Addresses for MME Ethernet Interfaces
8.1.4 Virtual Router Redundancy Protocol (VRRP)

Virtual Router Redundancy Protocol (VRRP) is a non-proprietary redundancy protocol
described in IETF RFC 3768 designed to increase the availability of the default gateway
servicing hosts on the same subnet. This increased reliability is achieved by advertising a
“virtual router” (an abstract representation of master and backup routers acting as a group)
as a default gateway to the host(s) instead of one physical router. Two or more physical
routers are then configured to stand for the virtual router, with only one doing the actual
routing at any given time. If the current physical router that is routing the data on behalf of
the virtual router fails, an arrangement is made for another physical router to automatically
replace it. The physical router that is currently forwarding data on behalf of the virtual
router is called the master router. Physical routers standing by to take over from the master
router in case something goes wrong are called backup routers.
8.1.5 Virtual/Floating IP Address
8.1.5.1 Virtual IP Address
A virtual IP address is an IP address that is shared between the two servers in a redundant
pair. A virtual IP address is not a physical address but a logical address and is maintained by
RCC for the diskful hosts (for diskless hosts the virtual IP addresses are assigned by REM).
The virtual IP address will always point to the active entity. Where for each pair of servers:
• One virtual IP address is available for application signaling
• A unique fixed IP address is assigned to each server, that can be used for any messages
needed to maintain (heartbeating) and configure that particular server.
8.1.5.2 Usage of the Virtual IP Address
The advantage of using a virtual IP address is that clients that use this IP address to talk to
the “active server” do not know which of the servers is currently active.
When the active server fails, its mate becomes active and assumes ownership of this IP
address. Clients with TCP/IP sockets up to the active server detect the failure of this
socket, and try to re-establish the socket. Although the client uses the same IP address, the
new connection is to a different processor.
Under normal operations, synchronization at the application layer must be maintained
between the active and standby servers (by keeping their TCP state machines in sync, for
instance). Otherwise the client connection can be broken as a result of server switchover,
requiring a reconnect from the client.

8.1.5.3 Floating IP Address
The virtual IP address is also known as a Floating IP Address (FLIP).
8.2 LOGICAL INTERFACES AND PROTOCOLS

The 9471 WMM supports multiple interfaces and the protocols that comprise them. The
following figure shows the interfaces supported in LM3.0.
Figure 132: MME Logical Interfaces
The MME interfaces and functionality conform to 3GPP Standards as shown in the table
below. The table lists the supported versions of the Pre-Release 8 3GPP Technical
Specifications (TS), and if applicable, notes any additional TS CRs supported.

MME Interface / 3GPP TS Version(s) Comments

Function Document Supported
Gn 29.060 8.6.0
MME Assisted S1-based 23.401 8.11.0/9.6.0 24.401 September 2010 CRs supported
eNodeB Handoff as well.
24.301 8.7.0/9.4.0 24.301 September 2010 CRs supported
as well.
as well.
36.413 8.7.0/9.4.0
33.401 8.7.0/9.2.0
NAS 23.401 8.9.0 24.401 September 2010 CRs supported
as well.
as well.
S1-MME 36.413 8.7.0/9.4.0 MME can detect the version of the S1-
MME protocol used on an S1 link
automatically.
Once the protocol version is detected
for an S1 link, MME interprets all the
S1-MME messages using that version.
S3 29.274 8.7.0/9.4.0 29.274 September 2010 CRs supported
as well.
as well.
as well.
as well.
as well.
as well.
S6a 29.272 8.8.0/9.4.0 29.272 September 2010 CRs supported
as well.
SGs 29.118 8.7.0/9.3.0 29.118 September 2010 CRs supported
as well.
as well.
SLs 29.171 9.2.0 29.171 September 2010 CRs supported
as well.
SLg 29.172 9.2.0 29.172 September 2010 CRs supported
as well.
SBc 29.168 9.2.0 29.168 September 2010 CRs supported
as well.

MME Interface / 3GPP TS Version(s) Comments

Function Document Supported
M3 36.444 9.2.0 36.444 + CRs supported as well.
Sm 36.444 9.4.0 36.444 + CRs supported as well.
X2 (IRI) not not applicable These interfaces follow the basic
X1_1 applicable principles detailed in TS 33.107
(version 8.8.0, Jun.’09), however the
X1 and X2 interfaces are proprietary
interfaces.
Please refer to 9471 Mobility Management Entity LTE Parameters User Guide,
LTE/DCL/APP/031094 for detailed information on interfaces and protocols.
Through this section, when provisioning is described it refers to local MME GUI (not SAM GUI).
8.2.1 IP
8.2.1.1 IP QoS
In a congested network, GTP-C packets, SCTP packets, and packets generated as part of Lawful
Intercept procedures (via the CALEA X1_1 and X2 interfaces) must be able to get to their intended
endpoints. Hence, GTP-C packets, SCTP packets, and Lawful Intercept packets must be marked with
a high priority DiffServ code point.
Rule: <MME> <IP> <Design>
MME supports the capability to provision DSCP for all its external interface traffic:
• GTP-C packets (S11, S10, Gn, Sv, S3, Sm, and S101),
• S102 packets,
• SCTP packets (S1-MME, S6a, SGs, S13, Gr, IuPS, SBc, SLs, SLg, M3),
• Lawful Intercept packets ( X1_1 and X2).
The DSCP code point is provisioned separately and independently for each of the interface types.
Provisioning of DSCP is acchieved through the “Interface Profile” table and attribute “DSCP Code”.
MME supports the following DSCP code points:

AF11 (DCSP 10 decimal), AF21 (DSCP 18 decimal), AF31 (DSCP 26 decimal), AF33 (DSCP decimal 30),
and AF 41 (DSCP 34 decimal ), CS5 (DSCP decimal 40) and EF (DSCP 46).
MME uses DNS to query for an MME or for an SGSN IP address.

DNS packets marking is the same as the marking for S10.
8.2.1.2 Flexible Mapping of QoS Parameters Between LTE and 2G/3G
This feature provides provisioning of mapping between LTE and R99 QoS to allow operators
flexibility to select QoS mapping to provide the same user experience when a subscriber moves
between LTE and 2G and 3G networks.
In inter-RAT procedures where a UE moves from LTE to UMTS/GERAN, the MME must map the EPS
QoS parameters for each bearer into the set of QoS parameters used in the GPRS core network
(generally referred to as “R99 QoS” or “pre-Rel8 Qos”). The MME must also map R99 QoS parameters
into EPS QoS parameters for each bearer when a UE moves from UMTS/GERAN to LTE. Prior to this
feature, the MME implements this mapping as specified in Annex E of 3GPP TS 23.401. However
some operators desire to override this fixed mapping for various reasons. Therefore this feature
introduces configurable mapping of QoS values between EPS and R99 forms.
The 5620 SAM introduces two new WMM instance properties to support the new tables for QoS
flexibility:
• 2G/3G QoS Parameters to EPS QCI Mapping – provides mapping of QoS parameters for R99 into EPS
• EPS QCI to 2G/3G QoS Parameters Mapping – provides mapping of LTE QoS parameters into R99
8.2.1.3 Configuration of Flexible QoS
Note:
The MME global parameter “R99 QoS Mapping Method” used in pre-LM6.0 releases will be removed.
Note:
The global parameter QoS Mapping High Delay Threshold defines QoS classes of
Conversational_Unknown_HighDelay/LowDelay in the 2G/3G QoS Parameters to EPS QCI Mapping object set.
Any values below the threshold are considered low delay. The default value is set to 150ms.
Note:
If the Global Parameter “R99 QsS Mapping Method” = CUSTOMER 1 in LM405/LM501, all values for
CUSTOMER 1 will be updated to the new tables automatically after software upgrade. Ensure all
tables match “CUSTOM 1” settings after upgrade
The mapping of UTRAN/GERAN QoS parameters to an LTE bearer QCI value shall be
provisionable in the MME. The mapping of the following discrete combinations of QoS parameters
shall be supported, with the indicated default mappings:
Traffic Class = Conversational, SSD = Speech (defaults to QCI 1)
Traffic Class = Conversational, SSD = Unknown, Transfer Delay >= high delay threshold
(defaults to QCI 2)
Traffic Class = Conversational, SSD = Unknown, Transfer Delay < high delay threshold
(defaults to QCI 3)
Traffic Class = Streaming, SSD = Speech (defaults to QCI 4)

Traffic Class = Streaming, SSD = Unknown (defaults to QCI 4)

Traffic Class = Interactive, THP = 1, Signaling Indication = yes (defaults to QCI 5)
Traffic Class = Interactive, THP = 1, Signaling Indication = no (defaults to QCI 6)
Traffic Class = Interactive, THP = 2 (defaults to QCI 7)
Traffic Class = Interactive, THP = 3 (defaults to QCI 8)
Traffic Class = Background (defaults to QCI 9)
The value of the "high delay threshold" to be used in the above mapping shall also be provisionable
in the MME, with a default value of 150ms
8.2.2 Diameter
A complete description of the 3GPP Diameter applications is the beyond the scope of this document.
However pertinent information is presented in the following.
Diameter based MME interfaces are:

• S6a (MME-HSS) for tracking area for mobility, PDN-GW session information, subscriber data
• S13 (MME-EIR) for UE Authentication
• SLg (MME-GMLC) as a vendor specific Diameter application (ELP).
Diameter protocol for S6a & S13 is specified in 3GPP TS 29.272.

ELP Diameter based protocol for SLg is specified in 3GPP TS 29.172.
These Diameter applications are defined as IETF vendor specific Diameter application where the
vendor is 3GPP. The vendor identifier assigned by IANA to 3GPP is 10415.
The Diameter application identifiers assigned by IANA:

S6a application ID is 16777251
S13 application ID is 16777252
SLg application ID is 16777255
The Diameter parameters are configured through:
• DWR Frequency Timer, Value: [100-30000] ms

• DWR Message Time, Value: [100-30000] ms
• DWR Max Retransmissions, Value: [0-5]
• CER Message Timer, Value: [100-10000] ms
• CER Max Retransmissions, Value: [0-5]
• DPR Message Timer, Value: [100-30000] ms
• Connect Timer, Value: [100-10000] ms
• Reconnect Timer, Value: [100-10000] ms

Engineering: <MME> <Diameter>
Default recommendation for Diameter parameters:

DWR Frequency Timer = 10 s
DWR Message Timer = 2 s
DWR Max Retransmissions = 3
CER Message Timer = 2 s
CER Max Retransmissions = 3
8.2.2.1 WMM Configuration for Support for Diameter Routing Agent
The WMM supports functionality for the Diameter Routing Agent (DRA) across the S6a,
S13, and the SLg interfaces. The support for DRA can be enabled or disabled on a per link
basis. Each DRA can have it’s own provisioned Destination-Realm. When the same DRA is
used for routing S6a, S13 and SLg, the Remote End-Point definitions use the same IP address
for each interface, so different ports must be used which results in different SCTP
associations.
When a Diameter request is sent by a WMM to a Diameter Routing Agent/DRA, the DRA
shall determine the HSS/EIR/GMLC identity based on the provided user identity and shall
forward the Diameter request directly to the HSS/EIR/GMLC. The user identity of
HSS/EIR/GMLC is communicated to the WMM in the Origin-Host/Origin-Realm AVPs of
the response. The WMM will store the determined HSS/EIR/GMLC identity/name/Realm and
may use it in further Diameter requests to the same user identity.
With this feature the WMM supports the following routing related AVPs and routing related
errors as specified in RFC 3588 sections 6.1.8 and 6.4.
- Origin-Realm
- Origin-Host
- Destination-Realm
- Destination-Host
- Proxy-Info
- Route-Record
In relation to Route Record and Proxy-Info AVPs, WMM supports up to three records in the
following S6a messages: IDR/A, DSR/A, CLR/A, and RSR/A. This allows WMM to receive
and ignore up to 3 Route-Record AVPs in HSS messages. WMM never sends Route-Record
AVPs in AIR, ULR, NOR, and PUR. When WMM receives Proxy-Info AVPs in the
following HSS request messages: IDR, DSR, CLR, and RSR, WMM echoes back those
Proxy-Info AVPs in the same order with corresponding Protect bit for each Proxy-Info record
and it applies to both success and error answer messages.
The DRA support for S6a, S13, or SLg is enabled or disabled in the Remote-End-Point form.
The Remote End-Point form has support for a Disconnect Peer Request (DPR) cause for
diameter based interfaces. The global parameters S6a DRA Roaming Supported and S13
Retry Different EIR have been added.

8.2.2.1.1 WMM Support for Enhanced Disconnect Peer Request /Disconnect Peer Answer
Messages
When the WMM receives a Disconnect-Peer-Request (DPR) message from the HSS it will
reply with a Disconnect-Peer-Answer (DPA) however the WMM does not close the SCTP
connection since the DPA needs to reach the HSS first and then it is up to the HSS that
initiated the DPR to close the connection. The WMM initiated DPR can be applied to a
provisioning change or a link state change. When the HSS link is blocked, prior to un-
provisioning, the corresponding Diameter connection is put in a Blocked/Not Used mode, and
the WMM sends DPR and waits for DPA (or timeout) before closing the connection. To
reduce the detection time in the case of a loss of Primary HSS via the DWR/DWA monitoring
messages, the default Diameter timers can be adjusted in 100 ms steps to closely match the
timer settings of a peer DRA or HSS.
The WMM disconnect cause can be configured in the Remote End-Point form, the default
value is DO_NOT_WANT_TO_TALK_TO_YOU.
8.2.3 SCTP
MME components involves in SCTP are:
• MIF (MME Interface Function)
• MPH (MME Packet Handler)
The Interface Board terminates and manages all logical interface links to the MME. It receives
(/sends) message payload internally over TCP from (/to) the MPH.
The MPH service runs on the HSPP4 AMC cards on the Ethernet Hubs.
The MPH terminates the external MME signaling SCTP, UDP and TCP stacks.
The payload of the MME signaling messages is sent to the MIF over an internal TCP LAN connection.
Reciprocally MME signalling coming into the MPH from the MIF is sent to the correct MME external
layer SCTP, UDP or TCP.
MIF and MPH use a redundant active/standby principle.

This means that two elements are available; only one is active at a given time, the standby is
periodically updated with the most recent data from the active element. In case of failure of the
active element there is a switchover to the standby one.
Refer to “MME PEG” for more information on MME architecture.
8.2.3.1 SCTP Multi-Homing
Rule: <MME> <SCTP> <Design>
On S1-MME, S6a and SGs the MME supports local Multi-Homing as well as remote Multi-Homing.

Restriction: <MME> <SCTP> <Design>
The MME does not support local Multi-Homing nor remote Multi-Homing on the S13, M3, SBc, SLg
and SLs.
MME supports up to 2 local IPv4 or IPv6 addresses or up to 2 local IPv4 + 2 local IPv6 addresses.
The SGs interface can only be provisioned with 2 local IPv4 addresses
For S6a/SGs interfaces, MME supports the provisioning of up to 2 remote IPv4 or IPv6 addresses or
up to 2 remote IPv4 + 2 remote IPv6 addresses.
For S1-MME interface, eNodeB’s IP adress(es) are learned by MME at SCTP association establishment.
The SGs interface can only be provisioned with 2 remote IPv4 addresses
When MME is the SCTP client, even though up to 2 remote addresses can be provisioned for a
remote multi-homed SCTP peer, it does not prevent the remote SCTP peer from having more than 2
local addresses. The remote SCTP peer will include all its local addresses in the INIT-ACK chunk
(may exclude the address that is in the IP header source IP address field).
If the address(es) returned in the INIT-ACK from the remote SCTP peer is different than the remote
addresses locally provisioned on the MME, the MME generates a event notification to indicate the
mismatch between provisioned and derived (received from far end) IP addresses .
When MME is the SCTP server, the remote SCTP peer may be single-homed or multi-homed with 2 or
more IP addresses. At SCTP establishment, the remote SCTP peer will include all its local addresses
in the INIT chunk. It may exclude the address that is in the IP header source IP address field.
The MME SCTP stack accepts and uses all the remote SCTP peer IP addresses after their respective
paths are verified.
MME uses IP addresses of the same IP version (IPv6 or IPv4) for different paths in the association.
One SCTP associations may use IPv4 or IPv6 independently of the other associations.
Once the MME successfully established a SCTP association with a remote SCTP peer, later if the
remote SCTP peer changes from SH to MH or MH to SH, the remote SCTP peer could send an Address
Configuration Change Chunk (ASCONF) to MME as per IETF RFC 5061 “SCTP Dynamic Address
Reconfiguration”.

MME SCTP stack does not support IETF RFC 5061, the ASCONF chunk is dropped by MME.
Once the MME successfully established a SCTP association with a remote SCTP peer, later the
remote SCTP peer may perform a SCTP association restart by sending an INIT chunk to MME on the
existing association.
Rule: <MME> <SCTP> <Standard>
As per IETF RFC 4960, if an INIT chunk adds new addresses to the association, the MME responds
with an ABORT. The SCTP association is torn down and the MME re-establishes the association.
When the provisioned remote addresses of a remote S6a/SGs SCTP peer is added/deleted/changed,
the MME tears down the existing S6a/SGs SCTP association and re-establishes the S6a/SGs SCTP
association.
8.2.3.2 SCTP Profile
A SCTP Profile is used to provision the SCTP stack to handle the associated interface type(s) that use
SCTP as the transport protocol.
A SCTP Profile is a set of SCTP parameters values characterizing the dialogues between SCTP nodes
in a SCTP IP network.
The customer can assign a SCTP profile to a SCTP stack chosen in the list of provisioned SCTP
Profiles.
For SGs, MME supports the ability to set up SGs SCTP connections with different SCTP profile based
on the remote MSC. Up to 6 different SGs SCTP profiles are supported.
To change the SCTP profile of a stack, all the associations carried by the stack must first be
cancelled.
Refer to customer documentation “MME configuration management - 418-111-207” for more

information on MME provisioning.
8.2.3.3 SCTP Profile attributes
The SCTP multi-homing is configured through:

• Table: STCP Profile, Parameter: Config Type, Value: [Single Homed, Multi Homed]
8.2.3.3.1 SCTP Fragmentation and Reassembly

MME support fragmentation when sending DATA chunks and reassembly when receiving DATA
chunks.
The SCTP association path MTU is configured through:

• Table: STCP Profile, Parameter: MTU Size, Value: [512-65535] bytes
Engineering: <MME> <SCTP>
Default recommendation for SCTP association path MTU size:

MTU Size = 1500 bytes
8.2.3.3.2 SCTP local port
The MME SCTP local (listening) port is configured through:

• Table: STCP Profile, Parameter: SCTP Port, Value: [1024 - 65535]
8.2.3.3.3 SCTP parameters for RTO calculation

• Table: STCP Profile, Parameter: RTO Initial Value, Value: [RTO Minimum - RTO Maximum] ms (in
10 ms intervals)
• Table: STCP Profile, Parameter: RTO Minimum, Value: [10-500] ms (in 10 ms intervals)
• Table: STCP Profile, Parameter: RTO Maximum, Value: [20-600] ms (in 10 ms intervals)
Default recommendation for SCTP parameters for RTO calculation:

RTO Initial Value = 300 ms
RTO Minimum = 50 ms
RTO Maximum = 400 ms
These are the default values as per IETF RFC 4960.
8.2.3.3.4 Association establishment

• Table: STCP Profile, Parameter: Max Init Retrans, Value: [1-15]
Default recommendation for SCTP maximum retransmissions at association establishment:

Max Init Retrans = 8
The valid cookie life time at sctp association establishment is configured through:
• Table: STCP Profile, Parameter: Cookie Life, Value: [5-120] s (in 1-second intervals)

Default recommendation for SCTP valid cookie life time at association establishment:
Cookie Life = 60 s
8.2.3.3.5 Link failure detection
MME uses the SCTP heartbeat mechanism for detecting link failure in case of peer SCTP node failure
or network failure (e.g., cable cut, router/switch failure). The intervals that MME sends Heartbeat
chunks to its SCTP peer are determined by the Retransmission Timeout (RTO) and the Heartbeat
Interval. Since the RTO value may change due to changing transport network conditions, the
successive Heartbeat intervals may not be the same.
Heartbeat mechanism is configured through:

• Table: STCP Profile, Parameter: Heartbeat Interval, Value: [1-300] (s) (in 1-second intervals)

Heartbeat Interval = 30 s
Maximum number of retransmissions per SCTP path of Data and/or Heartbeat messages is configured
through:
• Table: STCP Profile, Parameter: Max Path Retrans, Value: [1-25]
Max Path Retrans = 5
Maximum number of total retransmissions of Data and/or Heartbeat messages is configured through:
• Table: STCP Profile, Parameter: Max Association Retrans, Value: [1-50]

Max Association Retrans = 10

For ensuring that MME does not consider the peer is reachable while all paths are in failure there
must be verified that;
∑ Max Path Retrans ≥ Max Association Retrans

SCTP paths
8.2.3.3.8 SCTP acknowledgments
As per IETF RFC 4960:

“An acknowledgement SHOULD be generated for at least every second packet (not every second
DATA chunk) received, and SHOULD be generated within 200 ms of the arrival of any
unacknowledged DATA chunk.”
“An implementation MUST NOT allow the maximum delay to be configured to be more than 500
ms.”
In the above extract ‘packet’ stands for ‘SCTP packet’.
SCTP Acknowledgement period is configured through:

• Table: STCP Profile, Parameter: SACK Period, Value: [10-500] (ms) (in 10-msecs. intervals)
SCTP Acknowledgement frequency is configured through:

• Table: STCP Profile, Parameter: SACK Frequency, Value: [1-5]
Default recommendation for the SCTP Acknowledgement period and frequency are:
SACK Period = 200 ms
SACK Frequency = 2
These are the default values as per IETF RFC 4960.
8.2.3.4 MME SCTP components redundancy
MME MIF/MPH components have an active/standby redundancy scheme. When the active fails the
standby becomes active and all signalling is switched to the newly active. Switchover to the standby
MIF/MPH is preformed maintaining IP address and SCTP port numbering.
In the case where the MME acts as the SCTP server (S1-MME, SLg, M3, SBc) then 3GPP allows MME to
use the SCTP association restart procedure as defined in IETF RFC 4960.
As per TS36.412 for the S1-MME interface:

“For SCTP endpoint redundancy an INIT may be sent from MME or eNodeB, at any time for an
already established SCTP association, which shall be handled as defined in IETF RFC 4960“

When MIF/MPH switches over, the newly active MIF/MPH sends SCTP INIT chunk to each SCTP peer
end point to initiate a restart of the already established SCTP association with that SCTP peer end
point. The source port of the INIT packet is the MME SCTP listening port, and the destination port is
the SCTP peer’s SCTP source port.
On MME MIF/MPH switchovers, MME sends a SCTP INIT to initiate a restart of an already established
SCTP association, using the same transport address pair as the original SCTP association.
Peer (SCTP client) MME (SCTP server)

S1-MME or
M3 or Active Standby S1-AP
eNodeB or MIF MIF
SBc … M3-AP
MBMS-GW or
(SCTP) (SCTP) SBc-AP …
CBC …
SCTP association established

checkpointing eNodeB IP @
and SCTP port #
Data Req/Ind
DATA, HEARTBEAT
MIF switchover
Acquired floating IP @
SCTP already exists. INIT
MME restart treated as
per RFC 4960.
INIT-ACK
COOKIE-ECHO
COOKIE-ACK
SCTP restart
Data Req/Ind
DATA, HEARTBEAT
Figure 133: SCTP restart on MIF switchover
8.2.4 S1 interface
8.2.4.1 IP
8.2.4.1.1 Dual IPv4/IPv6 stack

Rule: <MME> <S1> <Design>
MME supports dual IP stack for IPv4 and IPv6 for the MME S1 interface.
This provides flexibility so that the eNodeB can change the IP format of the eNodeB Telecom
interface, while the MME operation is not affected.
8.2.4.1.2 MME S1 local IP interface
Engineering: <MME> <S1> <Design>
Using the LCP platform SCDT tool, the MME is configured with a fixed or floating IP address for use
in S1-MME communications
MME uses floating IP addresses for all the MME external interfaces except for the MH-SCTP
S1-MME IP interface terminates on the MPH (as all IP interfaces).
Engineering: <MME> <S1> <Design>
MME supports local multi-homing with up to:

• 2 local IPv4 addresses, or
• 2 local IPv4 addresses and 2 local IPv6 addresses.
8.2.4.1.3 MME S1 remote IP interface
eNodeB starts the communication with the MME. MME learns the eNodeB Telecom IP address and IP
format from the source IP address field in the IP packets at the time the SCTP association between
the eNodeB and the MME is set up.
Rule: <MME> <S1> <Standard>
MME does not need to be provisioned with the eNodeB IPv4 or IPv6 Telecom address(es)
An S1-MME Interface Managed Object (MO) is created when an eNodeB sends an S1 Setup Message
and an MO instance does not yet exist to represent that eNodeB S1 interface.
When an Interface MO is created at the MME, the MME saves the local IP address(es) type and value
plus the remote IP address(es) type and value of the interface instance in the Interface MO. Because
the SAM can read the MO values over the SNMPv3 interface, the SAM will be able to obtain the local
IP address(es) used at the MME as well as the remote IP address(es) used at the eNodeB.

8.2.4.1.4 MME Support for Multiple S1-MME local IP addresses
This feature adds support for separation of S1-MME traffic for clusters of eNB (e.g. eNB owned by
different PLMNs but MME is shared).
The feature supports up to 9 S1-MME local IP addresses and for each instance of S1-MME for which
the MME supports a separate SCTP profile. These IP addresses can be in the same subnet or different
subnets. An eNB can be configured to use one of the 9 IP addresses.
The s1mme links can be multi-homed or single homed (1+1/1+3 connectivity). Also the single home
and multi-home s1mme links can co-exist.
On each MME, up to 12000 eNodeBs can be supported across all S1-MME local interfaces.
The feature also covers the support for 28 bit global Home eNB ID to distinguish between Home eNB
and macro eNB.
Without this feature, every eNodeB attaching to a particular MME would share the same IP address
of the MME (Local address on the MME). With the addition of this feature, it is now possible to
associate a distinct MME IP address with a group of enodeBs. It is up to the customer to create such
a logical grouping: for instance if eNodeBs belonging to different customers are terminating on one
MME, then all of the eNodeBs of one particular customer can be grouped to have one MME IP
address.
The feature is provisioned using the SAM GUI. The basic outline for provisioning the feature is
presented below:
Note: Follow procedures for IP/subnet growth in the Configuration Management chapter of Release 6.0.1 MME OAM
Guide (Alcatel-Lucent 9471 Wireless Mobility Manager (WMM) Operations, Administration, and Maintenance
418-111-201WM6.0.1).
o Create an SCTP profile for each of the new S1-MME interfaces if required. S1-MME interfaces
can share SCTP profiles or can have different S1-MME profiles.
o Create an interface profile for each S1-MME interface and assign SCTP profiles to the
interface profiles.
Note: Multiple S1-MME interfaces have a specific naming convention, such as S1MME_2 and
S1MME_5. The value of the Interface Type specified in the Interface profile must correspond to the
name of the local interface.
o Apply the changes in the WMM Instance (Edit) form, if required.
o As required, choose one of the following options to an eNodeB between S1-MME interfaces:
Update eNodeB S1-MME connections using the 9952 WPS and WO deployment.
Update eNodeB S1-MME connections using a RAN S1-MME profile.
8.2.4.1.5 MME S1 Release Timer
Support for Home eNB and Local IP Access (LIPA) (m14000-01) capabilities introduces a new timer
parameter added to the MME Timers configuration form. The new timer added will be to specify the
time to wait to initiate an S1 Release when Closed Subscriber Group (CSG) registration expires. The
timer is called the S1 Release on CSG Expiration. The default value is 2000 msec with a range of 500
to 5000 msec.
8.2.4.2 SCTP
8.2.4.2.1 SCTP Multi-Homing

MME supports local multi-homing as well as remote multi-homed eNodeBs.
MME supports up to 2 local IPv4 or IPv6 addresses or 2 local IPv4 + 2 local IPv6 addresses.
The peer eNodeB may be single-homed or muti-homed with 2 or more IP addresses.

At SCTP establishment, the eNodeB includes all its local addresses in the INIT chunk. It may exclude
the address that is in the IP header source IP address field.
The MME SCTP stack accepts and uses all the eNodeB IP addresses after their respective path is
verified (as per IETF RFC 4960).
8.2.4.2.2 Association and stream
There must be only 1 SCTP association established between an eNodeB and an MME. [3GPP TS
36.412]
S1-MME SCTP associations are initiated by eNodeB via INIT message sent from eNodeB.
Within the SCTP association established between an eNodeB and an MME a single pair of stream
identifiers is used for S1 common procedures and a single pair of stream identifiers is used for S1
dedicated procedures.
There are 2 pairs ofstreams within the S1 SCTP association:

IANA has defined the eNodeB SCTP destination port supporting S1-AP traffic as = 36412. [3GPP TS
36.412]
eNodeB SCTP destination port for S1-AP is 36412.

MME listening SCTP port for S1-AP is 36412.

Engineering: <MME> <S1>
MME SCTP listening port for S1-AP must be set to 36412.
8.2.4.3 S1 SCTP provisionning model
S1 SCTP is provisionned through the configuration of; 1 S1 SCTP Profile + 1 S1 Interface Profile.
A SCTP Profile is identified by a unique ‘SCTP Profile ID’, Value: [1 - 65535].

The SCTP Profile is configured through:
36412
Figure 134: S1 SCTP Profile provisionning
A S1 Interface Profile is identified by an ‘Interface Type’ = ‘S1MME’.

A S1 Interface Profile points to a SCTP Profile through parameter ‘Interface Profile ID’.

The S1-MME Interface is configured through:
Figure 135: S1 Interface Profile provisionning
8.2.5 S6a interface
Diameter messages on the S6a interface between the MME and a HSS are transported either over
SCTP/IP or over TCP/IP.
Rule: <MME> <S6a> <Design>
ALU MME supports Diameter over TCP/IP and Diameter over SCTP.
The Diameter transport protocol is configured through:

• Table: Remote End Point Configuration, Parameter: USE Sctp, Value: [True, False]
‘USE Sctp’ parameter when checked (true), indicates that SCTP is used to support the diameter
sessions with the HSS using the S6a (or S13) interface. When not checked (false), TCP is used.
The MME acts as a Diameter Client and the HSS acts as a Diameter Server.
MME supports provisioning of up to 4 HHSs.
8.2.5.1 IP
MME supports dual IP stack for IPv4 and IPv6 for the MME S6a interface.
8.2.5.1.2 MME S6a local IP interface

Engineering: <MME> <S6a> <Design>
in S6a communications
S6a IP interface terminates on the MPH (as all IP interfaces).

8.2.5.1.3 MME S6a remote IP interface
MME starts the communication with the HSS. HSS IP address(es) are provisionned through the MME
Provisioning GUI.
MME supports provisioning of up to:

• 2 remote IPv4 addresses, or
• 2 remote IPv4 addresses and 2 remote IPv6 addresses.
Even though up to two remote addresses can be provisioned for a remote multi-homed HSS, it does
not prevent the HSS from having more than two local addresses. The HSS includes all its local
addresses in the INIT-ACK chunk. It may exclude the address that is in the IP header source IP
address field.

The MME SCTP stack accepts and uses all the HSS IP addresses after their respective path is verified
(as per IETF RFC 4960).
8.2.5.2 SCTP
MME supports local multi-homing as well as remote multi-homed HSSs.

MME supports the provisioning of up to 2 remote IPv4 or IPv6 addresses or 2 remote IPv4 + 2 remote
IPv6 addresses.
The peer HSS may be single-homed or muti-homed with 2 or more IP addresses.

At SCTP establishment, the HSS includes all its local addresses in the INIT-ACK chunk. It may exclude
the address that is in the IP header source IP address field.
The MME SCTP stack accepts and uses all the HSS addresses after their respective path is verified
The MME initiates the establishment of the SCTP association toward the HSS via INIT message.
Rule: <MME> <S6a> <Standard>
“A given Diameter instance of the peer state machine MUST NOT use more than one transport
connection to communicate with a given peer.” [IETF RFC 3588]

There is only 1 SCTP association established between an HSS and an MME.
Only 1 SCTP stream is used within the S6a SCTP association:

• Stream 0
A Diameter node MAY initiate connections from a source port other than the one that it declares it
accepts incoming connections on, and MUST be prepared to receive connections on port 3868. [IETF
RFC 3588]
IANA has defined the SCTP port for supporting Diameter traffic as = 3868. [IETF RFC 3588]
HSS listening SCTP port for Diameter is 3868.
Engineering: <MME> <S6a>
MME SCTP destination port for Diameter must be set to 3868.
The MME SCTP destination port for Diameter is configured through:

• Table: Remote End Point Configuration, Parameter: Port, Value: [1024 - 65535]
MME SCTP source port for Diameter may be set to 3868.
An MME at the initialization time sets up an SCTP association with the HSS.
The HSS listens on the S6a SCTP port = 6838 for SCTP INIT chunk from MME.
When no transport connection exists with a peer, an attempt to connect SHOULD be periodically
made. This behavior is handled via the Tc timer, whose recommended value is 30 seconds. [IETF
RFC 3588]

When the SCTP association to an HSS is closed, the MME periodically attempts to re-establish the
SCTP association with that HSS, as long as that HSS is known to the MME.
The periodicity is set to 30 s. It is not configurable.
MME starts a ‘Shutdown Command Timer’ on receipt of a shutdown from HSS.

When timer expires the MME initiates an SCTP association setup to HSS.
The timer is configurable.
The timer is configured through:

• Table: Update Timers, Parameters: Timer Name = “S6a Shutdown Command Timer”, Value: [0-
10] in second, default: 0s.
8.2.5.3 S6a over SCTP provisionning model
8.2.5.3.1 S6a over SCTP provisionning model
S6a SCTP is provisioned through the configuration of; 1 SCTP Profile + 1 S6a Interface Profile + 1
Diameter Profile + 1 Diameter Connection + 1 (to 4) Remote End Point Configuration.

3868
Figure 136: S6a SCTP Profile
A S6a Interface Profile is identified by an ‘Interface Type’ = ‘S6A’.

A S6a Interface Profile points to a SCTP Profile through parameter ‘Interface Profile ID’.
The S6a Interface is configured through:
S6A
Figure 137: S6a over SCTP - Interface Profile
‘Number of Authentication Vectors’ parameter is only used with the S6a interface.
Range: [0-5]. Default: 1 when interface type is S6a. 0 (unused) for other interface types.

A Diameter Profile is identified by a unique ‘Diameter Profile ID’, Value: [1 - 65535].
Figure 138: S6a Diameter Profile
A Diameter Connection points to a Diameter Profile through parameter ‘Profile ID’, Value: [1 -
65535].
A S6a Diameter Connection is identified by an ‘Application Type’ = ‘S6A’.
The Diameter Connection configures which transport protocol is used (SCTP or TCP) and points to
the HSS through the “Destination IP Id [1-4]” identifier(s).

The Diameter Connection is configured through:
Figure 139: S6a over SCTP - Diameter Connection provisioning
When “Use SCTP” button is checked it means that Diameter is over SCTP.
The Remote End Point Configuration is configured through:
S6A
3868
Figure 140: S6a over SCTP - Remote End Point Configuration

It is recommended to use the following ranges when defining Remote End Points:
[0], reserved for an unused profile
[1-100], for S6a and S13 interfaces
[101-200], for SGs interfaces
This allows for enough S6a and S13 entries when converting HSS/EIR from IPv4 to IPv6.
8.2.5.4 TCP
The MME uses the IANA registered Diameter/tcp port number 3868 as the destination port number.
The MME initiates the setup of the TCP connection toward the HSS.
RFC 3588]
IANA has defined the TCP port for supporting Diameter traffic as = 3868. [IETF RFC 3588]
HSS listening TCP port for Diameter is 3868.

MME TCP destination port for Diameter is 3868.
MME TCP destination port for Diameter must be set to 3868.
The MME TCP destination port for Diameter is configured through:

When TCP is the transport protocol and 2 MME local IP addresses were provisioned in the SCDT
database for the S6a interface, then MME uses the first configured local IP address.
8.2.5.4.1 S6a over TCP provisionning model
S6a SCTP is provisioned through the configuration of; 1 Diameter Connection + 1 (to 4) Remote End
Point Configuration.
A Diameter Connection is identified by a unique ‘Profile ID’, Value: [1 - 65535].

A S6a Diameter Connection is identified by an ‘Application Type’ = ‘S6A’.
The Diameter Connection configures which transport protocol is used (SCTP or TCP) and points to
the HSS through the “Destination IP Id [1-4]” identifier(s).

Figure 141: S6a over TCP - Diameter Connection
When “Use SCTP” button is unchecked it means that Diameter is over TCP.
S6A
3868
Figure 142: S6a over TCP - Remote End Point Configuration

8.2.6 SGs interface
SGs-AP messages are used on the SGs interface between MME and the MSC/VLR to:
• coordinate UEs location information that are IMSI attached to both EPS and non-EPS services
• relay messages related to GSM CS services over the EPS system via the MME
This is applicable to UEs with CS Fallback capability activated and to UEs configured for SMS delivery
using the CS core.
MME supports up to 128 MSC/VLR.
SGsAP messages are transported over SCTP/IP.
The MME acts as a SCTP Client and the MSC/VLR acts as a SCTP Server.
8.2.6.1 IP
Restriction: <MME> <SGs> <Design>
MME does not support IPv6 for the MME SGs interface.
8.2.6.1.2 MME SGs local IP interface
Engineering: <MME> <SGs> <Design>
in SGs communications
Rule: <MME> <SGs> <Design>
SGs IP interface terminates on the MPH (as all IP interfaces).


• 2 local IPv4 addresses
8.2.6.1.3 MME SGs remote IP interface
MME starts the communication with the MSC. For each MSC/VLR the MME supports up to 4 pairs of IP
addresses.
MSC IP address(es) are provisionned through the MME Provisioning GUI.
MME supports remote multi-homed MSC with up to:

• 4 pairs remote IPv4 addresses
If pairs of MSC addresses are provisioned, each pair of addresses indicate the two remote end IP
addresses to use in establishing an SCTP multi-homing Association.
Even though up to two remote addresses can be provisioned per pair for a remote multi-homed MSC,
it does not prevent the MSC from having more than two local addresses. The MSC includes all its
local addresses in the INIT-ACK chunk. It may exclude the address that is in the IP header source IP
address field.
The MME SCTP stack accepts and uses all the MSC IP addresses after their respective path is
8.2.6.2 SCTP
MME acts as the client for each SGs interface instance.

MME establishes an SCTP association with each of the provisioned MSC/VLR IP addresses.
MME supports local multi-homing as well as remote multi-homed MSCs.
MME supports up to 2 local IPv4 addresses.
MME supports the provisioning of up to 4 pairs remote IPv4 addresses.

The peer MSC may be single-homed or muti-homed with 2 or more IP addresses.

At SCTP establishment, the MSC includes all its local addresses in the INIT-ACK chunk. It may
exclude the address that is in the IP header source IP address field.
The MME SCTP stack accepts and uses all the MSC addresses after their respective path is verified
The MME initiates the establishment of the SCTP association toward the MSC via INIT message.
Rule: <MME> <SGs> <Standard>
MME may use of multiple SCTP associations with a given MSC [3GPP].
MME supports up to 4 SCTP associations per SGs interface.
MME distributes the UEs across the set of SCTP associations to the MSC/VLR in a round-robin fashion.
One SCTP profile is associated with an MSC regardless of the number of SGs interface instances
(SCTP associations) an MSC will have.
Support of Provisioning Separate SCTP Interfaces for SGs Interface (m10404-01):

MME supports the ability to set up SGs SCTP connections with different SCTP profile based on the
remote MSC.
If a MSC Server is not provision with any SCTP Profile then the one from interface profile is used.
MME supports provisioning of up to 6 SCTP profiles for use of the SGs interface.
A SGs interface can be assigned anyone of these 6 SCTP profiles.
MME supports at least two SCTP stream IDs, 0 and 1, for the transport of SGsAP messages.
MME is prepared to receive SGsAP messages from a MSC/VLR on any of the SCTP streams.
The MME distributes individual UEs over the SCTP streams in a round-robin fashion.

Rule: <MME> <SGs> <Standard>
IANA has defined the MSC SCTP port for supporting SGsAP messages as = 29118. [3GPP TS 29.118]
MSC listening SCTP port for SGsAP is 29118.
Engineering: <MME> <SGs>
MME SCTP destination port for SGsAP must be set to 29118.
The MME SCTP destination port for SGsAP is configured through:

MME SCTP source port for SGsAP may be set to 29118.
An MME at the initialization time sets up an SCTP association with the MSC.
The MSC listens on the SGs SCTP port = 29118 for SCTP INIT chunk from MME.
8.2.6.3 SGs provisionning model
SGs is provisioned through the configuration of; 1 (to 6) SCTP Profile + 1 (to 4) SGs Interface Profile
+ 1 (to 4) Remote End Point Configuration.

29118
Figure 143: SGs SCTP Profile
A SGs Interface Profile is identified by an ‘Interface Type’ = ‘SGS’.

A SGs Interface Profile points to a SCTP Profile through parameter ‘Interface Profile ID’.
The SGS Interface is configured through:
SGS
3
Figure 144: SGs Interface Profile
A peer MSC is provisionned through a ‘MSC server’ table.

Peer MSC is identified by a unique ‘MSC ID’, Value: [1 - 65535].

Up to 4 peer MSC IP addresses may be provisionned through the “MSC IP Id [1-4]” identifier(s).
The MSC Server is configured through:
Figure 145: SGs –MSC Server provisioning
The Remote End Point Configuration (MSC IP Id[1-4]) is configured through:
SGS
29118
Figure 146: SGs - Remote End Point Configuration

8.2.7 SLg
In order to support LoCation Services (LCS) MME supports the SLg interface to Gateway Mobile
Location Center (GMLC).
Restriction: <MME> <SLg> <Standard>
SLg interface is not allowed between a GMLC in one network to an MME in a different network.
GMLC must be in the same PLMN as the MME home PLMN.
GMLC receives UE positioning request from a LCS external client and triggers the MME over the SLg
interface to obtain UE positioning data.
EPC LCS Protocol (ELP) defines procedures and coding of messages over the SLg interface. The
protocol is specified in 3GPP TS 29.172. The ELP is a vendor specific diameter application.
The protocol stack used for the SLg interface is presented in the following figure.
Figure 147: SLg protocol stack
There are four categories of location services:

• Value added
• PLMN
• Emergency
• Lawful intercept
Restriction: <MME> <SLg> <Design>

MME only supports Location Services involving Emergency Services.

The other three types of location services are not supported.
LCS for Emergency Services only requires NI-LR (Network Induced Location Request) and MT-LR
(Mobile Terminated Location Request). MO-LR (Mobile Originated Location Request) is not required.
MT-LR and NI-LR flow charts are shown below. See TS23.271.
UE Uu eNB S1-MME MME SLs
E-SMLC SLg GMLC
Provide Subscriber Location
Location Request
MME starts T3x01
Positioning procedure
Location Report
MME stops T3x01
Provide Subscriber Location Ack
Figure 148: Mobile Terminated - Location Request (MT-LR)
Note: E-SMLC performs the positioning procedure (see SLs interface section).


E-SMLC SLg GMLC
Emmergency Attach
or Setup Emergency Bearer
Location Request
MME starts T3x01
Positioning procedure
Location Report
MME stops T3x01
Subscriber LCS Report
Subscriber LCS Report Ack
Figure 149: Network Induced - Location Request (NI-LR)
Rule: <MME> <SLg> <Design>
For Network Induced Location Request (NI-LR), MME sends the location report to a provisioned
GLMC for emergency calls:
- the emergency primary GMLC if the SCTP association to the primary is available, or
- the emergency alternate GMLC if the SCTP association to the primary is not available.
8.2.7.1 IP
MME supports dual IP stack for IPv4 and IPv6 for the MME SLg interface.
8.2.7.1.2 MME SLg local IP interface
Engineering: <MME> <SLg> <Design>
in SLg communications

SLg IP interface terminates on the MPH (as all IP interfaces).
MME supports up to:


8.2.7.1.3 MME SLg remote IP interface
GMLC IP address(es) are provisionned through the MME Provisioning GUI.


8.2.7.2 SCTP
GMLC establishes SCTP association with MME either at GMLC initialization time (MME allows
connections from a list of provisioned GMLC) or at the time GLMC sends a positioning request to
MME.
MME acts as SCTP server.

Restriction: <MME> <SLg> <Design>
MME SCTP stack does not support local multi-homing as well as remote multi-homed GMLCs.
The GMLC initiates the establishment of the SCTP association toward the MME via INIT message.
Rule: <MME> <SLg> <Standard>
“A given Diameter instance of the peer state machine MUST NOT use more than one transport
connection to communicate with a given peer.” [IETF RFC 3588]
There is only 1 SCTP association established between an GMLC and an MME.
Only 1 SCTP stream is used within the SLg SCTP association:

• Stream 0
RFC 3588]
IANA has defined the SCTP port for supporting Diameter traffic as = 3868. [IETF RFC 3588]
MME listening SCTP port for Diameter is 3868.
Engineering: <MME> <SLg>
MME SCTP destination port for Diameter must be set to 3868.
The MME SCTP destination port for Diameter is configured through:


MME SCTP source port for Diameter may be set to 3868.
A GMLC at the initialization time sets up an SCTP association with the MME.
The MME listens on the SLg SCTP port = 6838 for SCTP INIT chunk from GMLC.
When no transport connection exists with a peer, an attempt to connect SHOULD be periodically
made. This behavior is handled via the Tc timer, whose recommended value is 30 seconds. [IETF
RFC 3588]
This does not apply as MME does not establish the SCTP association with GMLC.

GMLC establishes SCTP association with MME either at GMLC initialization time or at the time GLMC
sends a positioning request to MME. MME allows connections from a list of provisioned GMLC.
8.2.7.3 Diameter
SLg interface protocol is defined as an IETF vendor specific Diameter application.

Following identifiers have been assigned by IANA [3GPP TS 29.272]:

− vendor identifier for 3GPP is 10415
− Diameter identifier for SLg is 16777255
8.2.7.4 SLg provisionning model
SLg SCTP is provisioned through the configuration of; 1 SCTP Profile + 1 SLg Interface Profile + 1
Diameter Profile + 1 Diameter Connection + 1 (to 4) Remote End Point Configuration.

3868
Figure 150: SLg SCTP Profile
A SLg Interface Profile is identified by an ‘Interface Type’ = ‘SLG’.

A SLg Interface Profile points to a SCTP Profile through parameter ‘Interface Profile ID’.
The SLg Interface is configured through:
SLG
4
Figure 151: SLg Interface Profile
A Diameter Profile is identified by a unique ‘Diameter Profile ID’, Value: [1 - 65535].

Figure 152: SLg Diameter Profile
A Diameter Connection points to a Diameter Profile through parameter ‘Profile ID’, Value: [1 -
65535].
A SLg Diameter Connection is identified by an ‘Application Type’ = ‘SLG’.
The Diameter Connection configures which transport protocole is used (SCTP or TCP) and points to
the GMLC through the “Destination IP Id [1-4]” identifier(s).

SLG
Figure 153: SLg Diameter Connection
The Diameter transport protocol is configured through:

• Table: Add Diameter Connection, Parameter: USE Sctp, Value: [True, False]
When “Use SCTP” button is checked it means that Diameter is over SCTP.
Diameter messages on the SLg interface are transported over SCTP/IP.

The ‘USE Sctp’ parameter must thus be checked.
SLg
3868
Figure 154: SLg Remote End Point Configuration
For Emergency services, the primary vs. alternate GMLC is configured through:
• Table: Add Emergency Profile, Parameters: Emergency GMLC Primary & Emergency GMLC
Alternate, Value: [1-1024], 0 (note: 0 is reserved for ‘not used’)
The value must be one of the "Destination IP Id" values populated in the Diameter Connection table
for application type "SLg". Any one of the 4 GMLCs can be specified to be the GMLC to use in support
of Emergency Service Access to the LTE network, namely Emergency GMLC Primary. Same for its
alternate.

Figure 155: SLg primary GMLC vs. alternate GMLC
8.2.8 SLs
In order to support LoCation Services (LCS) MME supports the SLs interface to EPS Serving Mobile
Location Center (E-SMLC).
The protocol stack used for the SLs interface is presented in the following figure.

Figure 156: SLs protocol stack
The MME selects a E-SMLC to serve a location request for a UE. MME provides an ability to configure
a TAI to E-SMLC mapping to select an E-SMLC for a UE positioning based on UE’s last seen Tracking
Area Identity (TAI). It provides load balancing between E-SMLCs.
Rule: <MME> <SLs> <Design>
MME provisioning allows up to two E-SMLC entities for each TAI that is covered by the MME.
Furthermore, the operator can specify whether the two E-SMLCs associated with a particular TAI
are used in a load sharing manner or in Primary/Secondary manner.
E-SMLC manages the overall co-ordination and scheduling of resources required for the location of a
UE that is attached to E-UTRAN. It also calculates the final location and velocity estimate and
estimates the achieved accuracy. The E-SMLC interacts with the UE in order to exchange location
information applicable to UE assisted and UE based position methods and interacts with the E-
UTRAN in order to exchange location information applicable to network assisted and network based
position methods.
E-SMLC uses LTE Positioning Protocol (LPP and LPPa) to UE and eNB respectively for UE positioning.
The positioning protocols are transparent to the MME.
LPP LPP
NAS Relay
Relay
RRC RRC S1-AP S1-AP LCS-AP LCS-AP
PDCP PDCP SCTP SCTP SCTP SCTP
RLC RLC IP IP IP IP
MAC MAC L2 L2 L2 L2
L1 L1 L1 L1 L1 L1
LTE Uu S1-MME SLs
UE eNode B MME E-SMLC
Figure 157: LPP signaling between E-SMLC and UE


E-SMLC SLg GMLC
Positioning
Request (LPP PDU)
S1 AP DL NAS
Transport (LPP PDU)
RRC DL Information
Transfer (LPP PDU)
Positioning
Measurements
RRC UL Information
Transfer (LPP PDU)
S1 AP UL NAS
Transport (LPP PDU)
Positioning
Response (LPP PDU)
Figure 158: UE assisted and UE based positioning procedure
LPPa LPPa
S1-AP S1-AP LCS-AP LCS-AP
SCTP SCTP SCTP SCTP
IP IP IP IP
L2 L2 L2 L2
L1 L1 L1 L1
S1-MME SLs
eNode B MME E-SMLC
Figure 159: LPPa signaling between E-SMLC and eNodeB


E-SMLC SLg GMLC
Positioning Request
(LPPa PDU)
S1 AP Location
Reporting Control
(LPPa PDU)
S1 AP Location
Report (LPPa PDU)
Positioning Response
(LPPa PDU)
Figure 160: Network based positioning procedure
8.2.8.1 IP
MME supports dual IP stack for IPv4 and IPv6 for the MME SLs interface.
8.2.8.1.2 MME SLs local IP interface
Engineering: <MME> <SLs> <Design>
in SLs communications
SLs IP interface terminates on the MPH (as all IP interfaces).

Engineering: <MME> <SLs> <Design>
MME supports up to:


8.2.8.1.3 MME SLs remote IP interface
E-SMLC IP address(es) are provisionned through the MME Provisioning GUI.


8.2.8.2 SCTP
MME establishes SCTP connections with a set of E-SMLCs at the initialization time or when an E-SMLC
is provisioned.
MME acts as SCTP client.
Restriction: <MME> <SLs> <Design>
MME SCTP stack does not support local multi-homing as well as remote multi-homed E-SMLCs.
The MME initiates the establishment of the SCTP association toward the E-SMLC via INIT message.

There is only 1 SCTP association established between an E-SMLC and an MME.
Only 1 SCTP stream is used within the SLs SCTP association:

• Stream 0
Engineering: <MME> <SLs>
MME SCTP destination port for LCSAP must be set to 9082.
The MME SCTP destination port for LCSAP is configured through:

MME SCTP source port for LCSAP may be set to 9082.
A MME at the initialization time sets up an SCTP association with the E-SMLC.
The E-SMLC listens on the SLs SCTP port = 9082 for SCTP INIT chunk from MME.
MME acts as SCTP client.

MME establishes SCTP association with a list of provisioned E-SMLC (up to 2 E-SMLCs per TAI).
8.2.8.3 SLs provisionning model
SLs SCTP is provisioned through the configuration of; 1 SCTP Profile + 1 SLs Interface Profile + 1 (to
4) Remote End Point Configuration.

9082
Figure 161: SLs SCTP Profile
A SLs Interface Profile is identified by an ‘Interface Type’ = ‘SLs’.

A SLs Interface Profile points to a SCTP Profile through parameter ‘Interface Profile ID’.
The SLs Interface is configured through:
SLS
5
Figure 162: SLs Interface Profile


Address 2 is for provisioning remote end point SCTP multi-homing.
SLs
9082
Figure 163: SLs Remote End Point Configuration
The E-SMLC is configured through:

• Table: Add ESMLC, Parameters: ESMLC DESTINATION 1 & ESMLC DESTINATION 2, Value: [1-1024],
0 (note: 0 is reserved for ‘not used’).
The value must be one of the "IP Id" values populated in the Remote End Point Configuration table
for interface type SLs.
ESMLC DESTINATION 1 is for provisioning the primary E-SMLC.
ESMLC DESTINATION 2 is for provisioning the alternate E-SMLC.
Figure 164: SLs E-SMLC Configuration
E-SMLCs per TAI is configured through:

• Table: Add Tracking Area Identity (TAI), Parameters: ESMLC Identity 1 & ESMLC Identity 2, Value:
[0-255]
The value must be one of the "ESMLC Identity" values populated in the ESMLC table.
ESMLC Identity 1 is for provisioning the first E-SMLC serving the TAI.
ESMLC Identity 2 is for provisioning the second E-SMLC serving the TAI.
There may be provisioned 2 E-SMLCs for each TAI that is covered by the MME.
Parameter “Selection Algorithm”, Value: [PrimarySecondary, LoadShare], specifies if the 2 E-SMLCs
are served on load sharing or on primary/secondary basis.

8.2.9 M3
MBMS is a point-to-multipoint service in which data is transmitted from a single source entity to
multiple recipients.
The MBMS bearer service offers two modes:
- Broadcast
- Multicast
Restriction: <MME> <M3> <Standard>
Only MBMS Broadcast mode is supported for LTE.
In order to support Multimedia Broadcast/Multicast Service (MBMS) MME supports the M3 interface to
the Multicast Coordination Entity (MCE) which is within the eNodeB.
The M3 Application Protocol (M3AP) supports the signaling control functions. The protocol is
specified in 3GPP TS36.444. M3AP defines procedures and coding of messages over the M3 interface.
M3AP includes:
• MBMS Session Management (Session Start/Session Stop/Session Update)

• Reset Functionality
• Error Indication Functionality

MME determines the eNodeBs which are in the MBMS Broadcast Service Area and transmits them
MBMS Session Management messages.
The protocol stack used for the M3 interface is presented in the following figure.
Radio
Network M3AP
Layer
SCTP
Transport IP
Network
Layer L2
L1
Figure 165: M3 protocol stack
For information, MBMS Bearer traffic for broadcasting routes directly from MBMS GW to eNodeB over
M1 interface.
MBMS Session Management flow charts are shown below.
UE eNB MME MBMS- BM-SC

Uu M3 Sm SGmb
GW
Session Start
Session Start Session Start Request/Response
Request Request
RAN resource setup
Session Start
Session Start Response
Response
Session Update
Session Update Session Update Request/Response
Request
RAN resource setup Request
or release
Session Update
Session Update Response
Response
Session Stop
Session Stop
Session Stop Request/Response
Request
Request
RAN resource release Session Stop
Response
Session Stop
Response
Figure 166: M3 MBMS Session Management procedures
Note: MBMS-GW triggers MBMS service procedures to MME (see Sm interface section).

8.2.9.1 IP
Rule: <MME> <M3> <Design>
MME supports dual IP stack for IPv4 and IPv6 for the MME M3 interface.
8.2.9.1.2 MME M3 local IP interface
Engineering: <MME> <M3> <Design>
in M3 communications
M3 IP interface terminates on the MPH (as all IP interfaces).
Engineering: <MME> <M3> <Design>
MME supports up to:


8.2.9.1.3 MME M3 remote IP interface
eNodeB starts the communication with the MME. MME learns the eNodeB M3 IP address and IP format
from the source IP address field in the IP packets at the time the SCTP association between the
eNodeB and the MME is set up.
Rule: <MME> <M3> <Standard>
MME does not need to be provisioned with the eNodeB IPv4 or IPv6 M3 address(es)

An M3 Interface Managed Object (MO) is created when an eNodeB establishes a SCTP association
with the MME at the M3 local IP address(es) and an MO instance does not yet exist to represent that
eNodeB M3 interface.
If an M3 interface to a eNodeB fails, then MME set its Operational State to Disabled and sends an
Event to OAM. If the M3 interface is in a failed condition longer than a provisioned timer then MME
deletes the M3 interface.
• Table: Update Timers, Parameters: Timer Name = “MBMS Response from MCE” & Timer Value,
Value: [1-30] in second, default: 5s.
8.2.9.2 SCTP
eNodeB establishes SCTP association with MME.

MME sends MBMS M3AP message only to the eNodeBs which have initialized an M3 SCTP association.
Thus, each eNodeB may, depending on SCTP association initialization, setup a M3 SCTP association
to 1, 2 or all the MMEs in an MME pool.
Restriction: <MME> <M3> <Design>
MME SCTP stack does not support local multi-homing as well as remote multi-homed eNodeBs.
The eNodeB initiates the establishment of the SCTP association toward the MME via INIT message.
There is only 1 SCTP association established between an eNodeB and an MME.
Only 1 SCTP stream is used within the M3 SCTP association:

• Stream 0
Rule: <MME> <M3> <Standard>
IANA has defined the SCTP port supporting M3AP traffic as = 36444. [3GPP TS 36.444]

Engineering: <MME> <M3>
MME SCTP listening port for M3AP must be set to 36444.
An eNodeB at the initialization time sets up an SCTP association with the MME.
The MME listens on the M3 SCTP port = 36444 for SCTP INIT chunk from eNodeB.

eNodeB establishes SCTP association with MME.
8.2.9.3 M3 provisionning model
M3 SCTP is provisioned through the configuration of; 1 SCTP Profile + 1 M3 Interface Profile.

36444
Figure 167: M3 SCTP Profile
A M3 Interface Profile is identified by an ‘Interface Type’ = ‘M3.

A M3 Interface Profile points to a SCTP Profile through parameter ‘Interface Profile ID’.

The M3 Interface is configured through:
M3
Figure 168: M3 Interface Profile
8.2.10 SBc
Warning message delivery is an ability to send warning messages to UE in a particular area. MME
receives warning messages from Cell Broadcasting Center (CBC) and forwards these messages to
eNodeBs.
- CMAS (Commercial Mobile Alert System)
- ETWS (Earthquake & Tsunami Warning System)
Restriction: <MME> <SBc> <Design>
Only North American CMAS is supported. ETWS is not supported.
In order to support Warning Message Delivery MME supports the SBc interface to the CBC (TS
28.268).
The SBc Application Protocol (SBcAP) supports the signaling control functions. The protocol is
specified in 3GPP TS36.413. SBcAP defines procedures and coding of messages over the SBc used to
transport messages associated with Warning Message Delivery function. These messages consist of
text warning of safety events which may impact a geographical region. MME forwards these
messages to the appropriate eNodeB(s) based on the TAI(s) they must be sent to. Finally the
warning messages are broadcast to UEs via the paging channel..
The protocol stack used for the SBc interface is presented in the following figure.

SBcAP
SCTP
IP
L2
L1
Figure 169: SBc protocol stack
CMAS Warning message delivery flow charts are shown below.
UE Uu eNB S1-MME MME SBc CBC
Write-Replace Warning Request

(TAI List, Rep Period,
MME forwards to the eNBs # of broadcast Requested,
which are within ‘TAI List’ Message Contents)
Write-Replace Warning Response
(Cause = “Message Accepted”)
Write-Replace Warning Request
MME starts ’Warning Message’ timer
(Rep Period, # of Broadcast
eNB broadcasts to UEs
Requested, Message Contents)
using paging (SIB12)
Write-Replace Warning Response
(Broadcast Completed Area List: MME stops ’Warning Message’ timer
“Successful Broadcast Areas”)
Broadcast continues at ‘Rep Period’ until:

1. ‘# of Broadcast Requested’ is achieved, or
2. broadcast is cancelled by CBC, or
3. ‘Message Contents’ is updated by CBC
Figure 170: SBc CMAS procedure
The ‘Warning Message’ timer is an S1-MME interface timer. It indicates the time MME waits for the
Warning Message Delivery Service. Failure to receive a Write-Replace Warning Response (or Kill
Response) form the eNodeB before the timer expires indicates the broadcast (or broadcast
cancellation) is unsuccessful with that eNodeB.
• Table: Update Timers, Parameters: Timer Name = “Warning Message” & Timer Value, Value: [1-
60] in second, default: 8s.
8.2.10.1 IP

Rule: <MME> <SBc> <Design>
MME supports dual IP stack for IPv4 and IPv6 for the MME SBc interface.
8.2.10.1.2 MME SBc local IP interface
Engineering: <MME> <SBc> <Design>
in SBc communications
MME uses floating IP addresses for all the SBc external interfaces except for the MH-SCTP
SBc IP interface terminates on the MPH (as all IP interfaces).
Engineering: <MME> <SBc> <Design>

8.2.10.1.3 MME SBc remote IP interface
CBC starts the communication with the MME. MME learns the CBC SBc IP address and IP format from
the source IP address field in the IP packets at the time the SCTP association between the CBC and
the MME is set up.
Rule: <MME> <SBc> <Standard>
MME does not need to be provisioned with the CBC IPv4 or IPv6 SBc address(es)
An SBc Interface Managed Object (MO) is created when a CBC establishes a SCTP association with
the MME at the SBc local IP address(es) and an MO instance does not yet exist to represent that CBC
SBc interface.
IP address(es) used at the MME as well as the remote IP address(es) used at the CBC.
If a SBc interface to a CBC fails, then MME set its Operational State to Disabled and sends an Event
to OAM.

A multi-homed CBC includes all its local addresses in the INIT chunk. It may exclude the address
that is in the IP header source IP address field.
The MME SCTP stack accepts and uses all the CBC IP addresses after their respective path is
8.2.10.2 SCTP
CBC establishes SCTP association with MME.

Restriction: <MME> <SBc> <Design>
MME SCTP stack does not support local multi-homing as well as remote multi-homed eNodeBs.
MME supports local multi-homing as well as remote multi-homed eNodeBs.

MME supports the provisioning of up to 2 remote IPv4 or IPv6 addresses or 2 remote IPv4 + 2 remote
IPv6 addresses.
The peer CBC may be single-homed or muti-homed with 2 or more IP addresses.

At SCTP establishment, the CBC includes all its local addresses in the INIT chunk. It may exclude the
address that is in the IP header source IP address field.
The MME SCTP stack accepts and uses all the eNodeB addresses after their respective path is
The CBC initiates the establishment of the SCTP association toward the MME via INIT message.

There is only 1 SCTP association established between a CBC and an MME.
Only 1 SCTP stream is used within the SBc SCTP association:

• Stream 0
Rule: <MME> <SBc> <Standard>
IANA has defined the SCTP port supporting SBcAP traffic as = 29168. [3GPP TS 29.168]
Engineering: <MME> <SBc>
MME SCTP listening port for SBcAP must be set to 29168.
A CBC at the initialization time sets up an SCTP association with the MME.
The MME listens on the SBc SCTP port = 28168 for SCTP INIT chunk from eNodeB.

CBC establishes SCTP association with MME.
8.2.10.3 SBc provisionning model
SBc SCTP is provisioned through the configuration of; 1 SCTP Profile + 1 SBc Interface Profile.

29168
Figure 171: SBc SCTP Profile
A SBc Interface Profile is identified by an ‘Interface Type’ = ‘SBC’.

A SBc Interface Profile points to a SCTP Profile through parameter ‘Interface Profile ID’.

The SBc Interface is configured through:
SBC
Figure 172: SBc Interface Profile
8.2.10.4 SBc Link Access Control List
This feature adds support for an Access Control list of valid peer IP addresses for the SBc link. The
MME shall accept CMAS alert requests on the transport layer only from the provisioned CBC IP
addresses on the Access Control List. MME shall be provisioned with a global parameter ‘Support
SBc Access Control’ to indicate whether the feature should be turned on or off. The default value
shall be off which indicates that MME shall accept alert requests regardless of provisioned
information.
8.2.11 GTP
8.2.11.1 GTP Profile
A GTP Profile is used to provision the GTP attributes to handle the associated interface type(s) that
use GTP as the transport protocol.
The customer can assign a GTP profile to an interface chosen in the list of provisioned GTP Profiles.
Rule: <MME> <GTP> <Design>
A GTP profile is provisioned per interface in the Interface Profile table. In another word, all GTP
tunnels of an interface type share the same GTP attributes regardless of the remote node it
connects to.
Refer to customer documentation “MME configuration management - 418-111-207” for more

information on MME provisioning.
8.2.11.2 GTP Profile attributes
8.2.11.2.1 Link failure detection
MME uses the GTP echo mechanism for detecting link failure in case of peer GTP node failure or
network failure (e.g., cable cut, router/switch failure).

GTP echo mechanism configuration is done through:

• Table: Add GTP Profile, Parameter: Inter-Echo Request Timer, Value: [60-10800] (s), Default:
60s.
This parameter specifies the periodic interval for sending Echo Requests.
• Table: Add GTP Profile, Parameter: Echo Response Timer, Value: [1-600] (s), Default: 6s.
This is parameter T3-RESPONSE as per TS 29.274. It specifies the time to wait for an Echo Response
to be received before re-transmitting the Echo Request message.
• Table: Add GTP Profile, Parameter: Echo Requests, Value: [9-20] (s), Default: 9.
This is parameter N3-REQUESTS as per TS 29.274. It specifies the total number of Echo Request
messages to be transmitted without receiving a corresponding Echo Response message.
Engineering: <MME> <GTP>
The periodicity of Echo Request message must be higher than the time to wait an Echo Response:
Inter −Echo Re questTimer ≥ (Echo Response Timer ∗ Echo Requests )
MME sends a GTP Echo Request every “Inter-Echo Request Timer” seconds.
If an Echo Response is not received within “Inter-Echo Request Timer” seconds (it is late or lost)
then the Echo Request is considered a failure.
After “Echo Requests” consecutive Echo Request failures MME notifies OAM with message indicating
a failure.
After a failure is reported, MME resets the failure count and continues sending Echo Requests. On
the first successfully received Echo Response after a failure, MME notifies OAM with a message
indicating a recovery.
Default recommendation for GTP echo mechanism:

Inter-Echo Request Timer = 60
Echo Requests = 9
With the default recommended setting, the time before GTP echo reports that Sm interface is down
is: 6 + 6 x 9 = 51s
The ability to turn on and off the sending GTP echoes will be a configurable parameter in an
upcoming SAM release.
8.2.11.2.2 GTP acknowledgments
GTP Acknowledgement period is configured through:

• Table: Add GTP Profile, Parameter: GTP Message Response Timer, Value: [1-60] (s), Default: 2s.
This parameter specifies the time to wait for an ACK to a request message or a response message
that expects an ACK. If the MME sends a GTP-C request message or a response message that expects
an ACK and does not receive the ACK before the timer expires, then the MME resends the request or
response.
GTP re-transmission is configured through:

• Table: Add GTP Profile, Parameter: GTP Message Send Attempts, Value: [1-4], Default: 3.
This parameter is used in conjunction with the Message Response Timer. If MME does not receive an
ACK in response to a request message or a response message that expects an ACK before the timer
expires, the request or response is resent. The message is considered undeliverable after if is sent
the number of times indicated here without receiving an ACK.
Default recommendation for the GTP Acknowledgement timer and re-send are:
GTP Message Response Timer = 2 s
GTP Message Send Attempts = 3
8.2.12 Sm
MBMS is a point-to-multipoint service in which data is transmitted from a single source entity to
multiple recipients.
- Broadcast
- Multicast
Restriction: <MME> <Sm> <Standard>
Only MBMS Broadcast mode is supported for LTE.
In order to support Multimedia Broadcast/Multicast Service (MBMS) MME supports the Sm interface
to the MBMS Gateway (MBMS-GW).
MBMS Session Management messages (Session Start/Session Stop/Session Update) on the Sm

interface are transported over GTP-C/UDP/IP.
MBMS-GW is always the originator of MBMS procedure to the MME.
The protocol stack used for the Sm interface is presented in the following figure.
GTPv2-C
UDP
IP
L2
L1
Figure 173: Sm protocol stack
For information, MBMS Bearer traffic for broadcasting routes directly from MBMS-GW to eNodeB over
M1 interface.

MBMS Session Management flow charts are shown below.
UE eNB MME MBMS- BM-SC

Uu M3 Sm SGmb
GW
Session Start
Session Start Session Start Request/Response
Request Request
RAN resource setup
Session Start
Session Start Response
Response
Session Update
Session Update Session Update Request/Response
Request
RAN resource setup Request
or release
Session Update
Session Update Response
Response
Session Stop
Session Stop
Session Stop Request/Response
Request
Request
RAN resource release Session Stop
Response
Session Stop
Response
Figure 174: Sm MBMS Session Management procedures
Note: MME triggers MBMS service procedures to eNodeB (see M3 interface section).
8.2.12.1 IP
Rule: <MME> <Sm> <Design>
MME supports dual IP stack for IPv4 and IPv6 for the MME Sm interface.
8.2.12.1.2 MME Sm local IP interface
Engineering: <MME> <Sm> <Design>
in Sm communications

Sm IP interface terminates on the MPH (as all IP interfaces).
Engineering: <MME> <Sm> <Design>
MME supports up to:

8.2.12.1.3 MME Sm remote IP interface
MBMS-GW starts the communication with the MME. MME learns the MBMS-GW Sm IP address and IP
format from the source IP address field in the IP packets at the time the GTP tunnel between the
MBMS-GW and the MME is set up.
Rule: <MME> <Sm> <Standard>
MME does not need to be provisioned with the MBMS-GW IPv4 or IPv6 Sm address(es)
An Sm Interface Managed Object (MO) is created when an MBMS-GW establishes a GTP-C tunnel with
the MME at the Sm local IP address(es) and an MO instance does not yet exist to represent that
eNodeB Sm interface.
8.2.12.2 UDP
MME listening/sending UDP port for GTP-C is specified in TS 29.274.
Rule: <MME> <Sm> <Standard>
IANA has defined the UDP port supporting GTP-C traffic as = 2123.
8.2.12.3 GTP-C
MBMS-WG establishes GTP-C tunnel with MME.

MME acts as GTP-C server.
A GTP tunnel exists between the MME and the MBMS-GW.

A GTP link verification is provided using GTP Echo and Response messages.
GTP Echo Requests has a TEID of 0.

GTP echo mechanism is used on Sm interface.
In order to process GTP Echo Requests, MME listens on a UDP socket bound to the MME’s Sm IP
address for traffic destined for the GTP-C UDP port (port # 2123, as specified by TS 29.274).
In response to GTP Echo Requests received MME builds a GTP Echo Response and sends it to the
source IP and UDP port that it came from.
8.2.12.4 Sm provisionning model
Sm SCTP is provisioned through the configuration of; 1 GTP-C Profile + 1 Sm Interface Profile.
A GTP-C Profile is identified by a unique ‘GTP Profile ID’, Value: [1 - 65535].

The GTP-C Profile is configured through:
Figure 175: Sm GTP-C Profile
A Sm Interface Profile is identified by an ‘Interface Type’ = ‘SM.

A Sm Interface Profile points to a GTP-C Profile through parameter ‘Interface Profile ID’.

The Sm Interface is configured through:
SM
Figure 176: Sm Interface Profile
8.2.13 S102
The S102 interface allows CS fallback to 1xRTT to establish voice call in the Cicuit Switch domain through
support of registration over EPS procedures.
The S102 application is based on UDP/IP transport medium and utilizes a registered UDP destionation port
23272, for signalling interconnection between an MME and a 1x Circuit Swiched Inter-Working Solution for the
S102 application.
To provision S102-based CSFB to 3G-1X voice

1 Configure interface profiles for S102 interfaces, as required.
Under WMM Instance, Select Interface Profile and then select S102.
Also change the S102 Tack Timer value if required. The default value is 1000 milliseconds. (this
value is configured in milliseconds)
2 Configure MSC to IWS provision mappings, as required.
1. Open the instance properties form of a 9471 WMM, if required.

2. Right-click on the MSC to IWS provision object and choose Create MSC to IWS provision from
the contextual menu. The MSC to IWS provision (Create) form opens.
3. Configure the parameters:
MSC to IWS Name
MSC Server ID ( The value of “MSC Server ID” must match the value of first 3-byte of
Reference Cell ID IE within CDMA2000Uplink Message.)
1x CS IWS IP (IP address in the field of “1x CS IWS IP” must be IP address of IWS
Server)
Heart Beat
Heart Beat Time Out
4. Click on the OK button.The form closes and a dialog box appears.
5. Click on the OK button.
6. Click on the Apply button in the WMM Instance (Edit) form. A dialog box appears.
7. Click on the Yes button. The changes are saved.
8. Close the WMM Instance (Edit) form, if required.

3 Configure the S102 Services Allowed parameter in UE PLMN and served PLMN service agreement
profiles, as required.
1. In the WMM Instance (Edit) form, navigate to the UE PLMN and Served PLMN Service
Agreement Profile tab. The path is Profiles UE PLMN and Served PLMN Service Agreement
Profile.
2. Select a profile from the list and click on the Properties button. The UE PLMN and Served
PLMN Service Agreement Profile (Edit) form opens with the General tab displayed.
3. Configure the S102 Services Allowed parameter.
4. Click on the OK button. The form closes.
5. Click on the Apply button in the WMM Instance (Edit) form. A dialog box appears.
6. Click on the Yes button. The changes are saved.
5 Associate UE PLMN and served PLMN service agreement profiles with the UE PLMN Services IMSI
range services objects, as required.
[See (Procedure 8-112 in the SAM guide) for information about configuring IMSI range services
objects.]
In the WMM Instance (Edit) form navigation tree, expand the UE PLMN Services object to display
the child objects.
Click on a child object. The WMM Instance (Edit) form displays the object data.
Click on the IMSI Range Services tab to configure the assosiation.
6 Configure other optional parameters such as S102 Paging policy, (If do not provision S102 Paging
Policy for S102 Page Attempts, S102 A21 Signaling message would defer to default Paging Policy.),
S102 Call Priority Paging Profile (this table maps A21 message Priority Level to the Paging Priority IE
in the S1AP Paging message), UE PLMN Services (also has S102 Paging Profile ID), S102 Paging
Priority Profile (Includes S102 Pagning Profile ID, services or S102 Call Priority Pagning Profile), Call
Trace Global Setting(S102 for Call Trace) and Message retransmissions (NS102 parameter).
8.2.14 Gn
The Gn interface is the reference point between the MME and the SGSN.. In the 9471
WMM combined MME-SGSN, the interface is internal.
The Gn interface allows the MME to affect a handover for a user who transitions between
LTE and UTRAN, and also supports reselection between LTE and GERAN (GSM).
The Gn interface allows the MME to affect a handover for a user who transitions between
LTE and UTRAN, and also supports reselection between LTE and GERAN (GSM). The
Gn interface transports both signaling and bearer information. The signaling is directed to
the MME and the bearer is directed to the PGW/GGSN.
8.2.14.1 Provision Gn Interface
Use SAM to provision the Gn Interface
• Define the Gn interface data

o Create a GTP profile or use an existing one
o Create an interface profile for the Gn interface
o Review Gn default values for the following object types and make changes as
required
QoS Mapping – 2G/3G
Global parameters – Configure the following
ArpMValue
ArpHValue
Obtain UE-AMBR
S3 Gn Indirect Forwarding
NAS Tokens to Compare
SGSN Discovery Method

IPv4v6 SGSN
R99 QoS Mapping Method
TEID to SGSN
SGSN IPv4 Addrss for user traffic
Include R7 QoS Extensions Gn
o Timer – Configure values for the following timers as required
HO2G3Deletion
SRNS Completion
S3Gn Indirect Forwarding
S3 Gn HO Complete
TAU After Ho
• Apply the changes in the WMM Instance (Edit) form, if required
8.3 MME BIDIRECTIONAL FORWARDING DETECTION (BFD)

IMPLEMENTATION
Restriction: <MME> <Network> <Design>
MME BFD implementation requires a single network connection between the MME and the primary
and secondary first hop router. A layer 2 failover redundant connectivity network can not be
implemented if BFD is used.
Figure 177: BFD Network Architecture
Engineering: <MME> <BFD>
• Fault Detection is established to the first hop router (only). Multi-hop BFD is not supported.
• Only Asynchronous BFD mode is supported. (Demand Mode is not supported).
– The MME will operate in the Active mode. The First hop router can operate in
either in Active or Passive mode.
• BFD Poll sequence is supported for parameter change.
• BFD Echo functionality is not supported.
• IETF RFC 5880 optional support of Authentication is not required.
• BFD Version 1 support is required.
• BFD over UDP/IP is supported.
• BFD support over IPv4 and IPv6
• Only one fault detection mechanism should be enabled on an external interface. Either
EIPM-BFD, EIPM-ACM or Multi-Homing SCTP (MH-SCTP) can be provisioned mutually
exclusive.
a. It is recommended that MH-SCTP be used whenever possible.

• IETF RFC 5881 recommendation for distinguishing BFD traffic is used in the MME
implementation. The UDP destination port is 3784. The UDP source port can be within the
range of 49152 through 65535.
• TTL timer of 255 to age packets is supported
8.3.1 BFD Redundancy and Failover
As discussed in the BFD general section, the Asynchronous (non echo) mode expiration time is
calculated with the following formula.
• Asynchronous mode (non-echo)

– Local Tx time = max (local Tx interval, remote Rx interval).
– Local Rx Detection time = Calculated by (remote Detect Mult) * max (remote TX
interval, local Rx interval)
– Detect Mult is how many sequential packets can be missed before declaring down
After which the link is declared down and traffic is failed over to the redundant link.
This failure decision is based on each BFD session independent of any other BFD session. If a physical
link has several BFD sessions, each BFD session is treated independently. If a physical link has for
example a IPv4 BFD session and a IPv6 BFD session, and the IPv4 BFD session fails, the IPv4 traffic
will be the only traffic switched. The IPv6 traffic will remain on the primary first hop router.
Rule: <MME> <BFD> <Requirement>
BFD traffic switchover from current outbound path to the alternate path with 500 milliseconds
after detecting a BFD failure.
8.3.2 BFD Configuration
• Each subnet can have at most 1 BFD session
BFD configuration is a multiphase step. The BFD subnet and static route configuration will be
performed on the Field install phase. The BFD session configuration can be performed after the FI
phase via CLI commands.
BFD session parameters are defined for all BFD sessions in the MME.

Parameter Detection Time Multiplier

System
CLI
command
Range & Unit Integer
[3..50]
Impact of
No service impact.
Change
Value Operator Dependent; default = 3
Parameter Desired Min Tx Interval

System
CLI
command
Range & Unit Integer (100 Msec)
[1..1000]
Impact of
No service impact.
Change
Parameter Desired Rx Interval

System
CLI
Command
Range & Unit Integer (100 Msec)
[1..1000]
Impact of
No service impact.
Change
• BFD subnets allow for /31 and /32 prefix lengths for IPv4 and /128 for IPv6.
• If BFD is used in conjunction with external VLAN tagging, the BFD subnet and the service
subnet that BFD is pretecting will have to be in the same VLAN. This is required to ensure
that the BFD traffic will follow the same path as the protected service.

8.3.3 BFD Alarms
A BFD session alarm (major) will be raised when a BFD session is down. The Alarm is cleared when
the session is in the up state.
8.3.4 BFD Router
Engineering: <BFD> <Router>
• The router is a customer piece of equipment that interfaces to the MME for traffic routing.
MME BFD only supports static routes. Therefore the proper weighting should be used to allow for
using BFD primary and secondary routes before using the default routes for the subnets. The order
of preference would be to:
1. Use Primary BFD route.

2. Use the secondary BFD route when the primary BFD is down.
3. Use the Primary paths default route when both primary and secondary BFD sessions are
down.
4. Use the Secondary path default route when the all routes fail.
8.4 SOURCE BASED ROUTES
In WM7.0.0 and later releases, external routing of messages is based on the source, or
local WMM, address. In earlier releases, the WMM did routing based on the remote, or
far end, IP address. The WMM routes to the outgoing RTM port based on the source address in the IP
packet. That is, the WMM will route to the port for S1 based on the S1–MME local IP address,
not the destination IP address of the eNodeB for which the message is destined.
Source Based routes are provided as a benefit for minimizing configuration changes when a new
network component is added to the core network. Source based routes are only available for GTP
interfaces on the MPH as well as SCTP based interfaces. The interfaces include, S11, S10, S3, Gn, Sv
MPH interfaces and SLs, SBc, SLg SCTP interfaces.
The configuration of the source based route is automatic. The source based route is added by using
the CE gateway address that was provisioned in the field install or IP configuration procedures. The
source based route is the only available route for the specified interfaces after release LM4.0.2. All
preexisting routes related to the specified interfaces are deleted in the process (destination and
default routes pertaining to the GTP MPH interfaces and SLs, SBc, SLg SCTP interfaces.
8.5 PHYSICAL REDUNDANCY

The physical redundancy directly supports the process redundancy of the MME. Please refer to MME
Product Engineering guide for a description of the logical redundancy. The MME will now support
1+1 GE redundant external network links towards the next hop router. Currently the MME supports a

2 GIGE LAG configuration. The following diagram depicts a 2 GIGE LAG configuration. If a 1+1
configuration is used, Link 3 and 4 do not exist.
Figure 178: MME Redundant Physical Links
Engineering: <MME> <1+1 GIGE Redundant

Redundant>
• The MME will revert traffic from the secondary oRTM back to the primary oRTM when the
primary oRTM connection is available.
• The 1+1 GIGE configuration will perform physical link switch over based on faults detected
via the EIPM-ACM or EIPM-BFD.
BFD.
Rule: <MME> <1+1 GIGE Redundant> <Requirement>
The 1+1 GEG configuration is only a field installation procedure.
8.6 SECURITY
8.6.1 IPsec
This section assumes the reader has prior knowledge of IPsec functionality. A Generic IPsec
Description section has been included in this document for the reader’s reference.
Alcatel-Lucent

8.6.1.1.1 Dependencies & Assumptions
Restriction: <MME> <X1_1 /X2 IPsec> <Design>
There will be no alarm indication

ion when the IPsec tunnel fails.
]
8.6.1.2 Network Connectivity for CALEA X1_1 and X2 Interfaces
The MME IPsec implementation for the CALEA X1_1 and X2 interfaces support a flexible Network
Architecture where the MME can connect to either a Security Gateway for directly to the CALEA
devices via IPsec. The configuration options for IPsec are flexible to accommodate various Security
Gateways and CALEA devices. The following picture depicts the hub and Spoke IPsec architecture
for Security Gateway configuration. The Security Gateway is the HUB and terminates all IPsec
communications from the MME. All traffic to/from the MME to the CALEA entities are via the
Security Gateway.
The following picture depicts the IPsec architecture to support IPsec Point to Point ccommunications
ommunications
between the MME and CALEA devices.
Alcatel-Lucent

The following diagram depicts the redundant IPsec architect utilizing the Security Gateway.
Alcatel-Lucent

The picture depicts the CALEA X1_1 and X2 interfaces on separate IPsec tunnels. The MME is capable
of supporting
ing X1_1 and X2 traffic over the same IPsec tunnel. The table below further displays the
possible configuration.
Configuration X1_1 X2
1 IP
IPsec T1
2 IPsec T1
3 IP
IPsec T1 IPsec T2
Rule: <MME> <X1_1/X2 IPsec> <Requirement>
The MME can connect to at most 10 Security Gateways.
8.6.1.2.1 IPsec Configuration & Hard Coded Parameters
8.6.1.2.2 Supported Paramters
Alcatel-Lucent

The following table represents the IPsec parameters supported by the MME X1_1 and X2 interfaces.
IKE IKEv1 (Main Mode only) or IKEv2
Encryption AES CBC 128 (IETF RFC 3602)
AES
AES 256
3DES
Authentication Diffie-Hellman exchange group 2 with
1024 MODP (IETF RFC 2409, IETF RFC 4307 and IETF RFC 3526),
MODP1536
MODP2048
MODP3072
MODP4096
Integrity NULL
HMAC-MD5-96
HMAC-SHA-1-96
Encapsulation ESP
AH
NULL
Mode Tunnel
Transport
Key Generation Diffie-Hellman
Resiliency and High IPsec Failover
Availability Dead Peer Detection (DPD)
IP Version IPv4 Support (only)
8.6.1.2.3 MME Supported Configurations
The MME IPsec tunnel configuration will consist of two separate steps. An IPsec profile must be
configured to setup the IKE Parameters. Secondly an IPsec connection must be configured with the
ipsec tunnel specific paramters. An MME IPsec connection is associated with an MME IPsec profile to
define an IPsec Tunnel.
Please refer to CALEA/LI Administration document (418-111-213) for the commands to configure the IPsec
Profile and IPsec Connections.
IPsec Profile Parameters:
IKE Algorithm: This option specifies the encryption alogorithm used (i.e. AES128). This is valid for
the IKE session only, not the IPsec session.
IKE Hash: This is an optional alogorithm used to authenticate the remote end (i.e. md5, SHA1). This
is valid for the IKE session only, not the IPsec session.

IKE PFS Group: This option specifies the Perfect Forwarding Secrecy settings that allow the
renegotiation of keys in the IKE phase two negotiation (i.e. modp1024).
IKE Lifetime: This option specifies the time before IKE re-negotiates new keys.
Phase 2 Algorithm: This option specifies the encryption alogorithm used (i.e. AES128). This is the
encryption method used in the IPsec tunnel.
Phase 2 Hash: is an optional alogorithm used to authenticate the remote end (i.e. md5, SHA1). This
is the encryption method used in the IPsec tunnel.
SA Lifetime: This is the optional Security Association timer that specifies the time before the phase
2 algorithm and phase 2 hash become invalid and require a re-nogotiation.
IPsec Connection Parameters:
IPsec Interface: This parameter specifies the interface associated with this IPsec tunnel (i.e. X1_1
or X2).
IPsec Address: This is the remote Security Gateway address. (Note: IPv4 address only, IPv6 not
supported).
IPsec Key: This is the IPsec Pre-Shared key.
IPsec Enable: This option enables the IPsec connection.
IPsec Disable: This option disables the IPsec connection.
IPsec Name: This is a lable associated with the IPsec connection.
IPsec Profile: The number identifier associated with the IPsec connection.
IPsec Subnet: The network Mask associated with the remote IP network.
IPsec Subnet Length: The remote subnet length for the IPsec Connection.
IPsec Type: The IPsec mode (i.e Tunnel or Transport). Additional information provided in the
general IPsec section of this document.

9 ABBREVIATIONS AND DEFINITIONS
9.1 ABBREVIATION
3GPP Third Generation Partnership Project

DHCP Dynamic Host Configuration Protocol
CBS Committed Burst Size
CCM Core Control Module
CIR Committed Information Rate
DAD Duplicate Address Detection
DNS Dynamic Name resolution
EBS Excess Burst Size
EIR Excess Information Rate
ELSR Edge LSR
EMS Element Management System
eNodeB Evolved NodeB ( eUTRAN BTS )
eUTRAN Evolved UMTS Terrestrial Radio Access Network
FN Functional Note
FRS Feature Requirements Specification
FTP File Transfer Protocol
IANA Internet Assigned Numbers Authority
IGMPv3 Internet Group Management Protocol Version 3
IP Internet Protocol
ITU-T International Telecommunication Union - Telecommunication Standardization Sector
LSR Label Swapping Router
LAG Link Aggregation Group
LHR Last Hop Router
LTE Long-Term Evolution (3GPP Mobile Networks)
MBMS Multimedia Broadcast and Multicast Services
MLDv2 Multicast Listener Discovery Protocol Version 2
MLS Multilayer Switch
MPLS Multiprotocol Label switching
NAT Network Address Translation (rfc1631)
NE Network element
NID Network Interface Device
NTP Network Time Protocol
OAM Operations, Administration and Maintenance

OSPF Open Short Pass First Protocol

PMIP Proxy Mobile Internet Protocol
PQ3 Power Quicc III
PTP Precision Time Protocol
QoS Quality of Service
RIP Routing Information Protocol
RSP Routing Switch Platform
RTO Retransmission Time Out
SE/PE Système Exploité / Poste d’Exploitation ( Managed System / Managing System)
SLAAC StateLess Address Auto Configuration
TN Technical Note
TS Technical Specification
UE User equipment
WiPS Wireless internet Provisioning System
WMS Wireless Management System
XML Extensible Mark-up Language
9.2 DEFINITION
eNodeB parameters are grouped into 3 distinct categories depending on the impact to support
online change:
• Class A (or Class 0) = Full impact: these parameters need a global eNodeB reset to be taken into
account. This means a full service impact.
• Class B (or Class 2) = Partial impact: these parameters change is managed on-line but will impact
the service. This change will not trigger any OAM interface outage, meaning that the eNodeB is kept
under supervision. Transport Layers impact: Reset of the eNodeB's transport network layers.
It implies reset of the SCTP, S1 and X2 layer instance(s) that are mapped to the transport layers.
• Class C (or Class 3) = No impact: these parameters are changed on-line, without any impact on
the service, and without any outage from an OAM supervision point of view (the eNodeB is kept
under supervision during the parameters change).
eNB parameter "Service impact" specifies the temporary impact upon eNB services of an update of
the parameter value.
The possible values of the "Service impact" are as follows:
• none: specifying that there will be no interruption of eNB services.
• partial: specifying that there will be a temporary interruption to some eNB services.
• critical: specifying that there will be a temporary interruption to all eNB services.
eNB parameter "Update transient impacts details" qualifies the "Service impact", providing further
detail as to the temporary impact upon eNB services of an update of the parameter value.

The possible values of the property are given below, together with brief explanations.
For ServiceImpact = critical:
- full-eNB-reset: Reset of entire eNB.
For ServiceImpact = partial:
- Transport-Layers: Reset of the eNB's transport network layers. Implies reset of the SCTP, S1
and X2 layer instance(s) that are mapped to the transport layers.
- S1-interface: Reset of the associated SCTP & S1 interface.
- X2-interface: Reset of the associated SCTP & X2 interface.
- M3-interface: Reset of the associated M3 interface.
For ServiceImpact = none:
- Immediate-propagation: No temporary service impact.
- New-set-ups: No temporary service impact. However, the new parameter value will take effect
for new established activities that are supervised by the eNB.
End of DOCUMENT 

LTE DCL APP 034072 V08 en LTE Transport Engineering Guide For LR14.1 and WMM7

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

LTE DCL APP 034072 V08 en LTE Transport Engineering Guide For LR14.1 and WMM7

Caricato da

Copyright:

Formati disponibili

LTE TRANSPORT ENGINEERING GUIDE FOR LR14.

LTE TRANSPORT ENGINEERING GUIDE FOR LR14.1 &

Alcatel-Lucent - Proprietary - Use pursuant to applicable agreements

The information presented is subject to change without notice. Alcatel-Lucent assumes no

Copyright © 2010 Alcatel-Lucent. All rights reserved.

Alcatel-Lucent - Proprietary - Use pursuant to applicable agreements

LTE/DCL/APP/034072 08.01/EN Approved-Preliminary 27/Jun/2014 Page 1/504

Alcatel-Lucent - Proprietary - Use pursuant to applicable agreements

LTE/DCL/APP/034072 08.01/EN Approved-Preliminary 27/Jun/2014 Page 2/504

5.2.1.5 Stage 1 - IPsec traffic selection and SA database lookup ..................................76

Alcatel-Lucent - Proprietary - Use pursuant to applicable agreements

LTE/DCL/APP/034072 08.01/EN Approved-Preliminary 27/Jun/2014 Page 3/504

Alcatel-Lucent - Proprietary - Use pursuant to applicable agreements

LTE/DCL/APP/034072 08.01/EN Approved-Preliminary 27/Jun/2014 Page 4/504

6.8.5 DHCPv6 option format ......................................................................................................... 190

Alcatel-Lucent - Proprietary - Use pursuant to applicable agreements

LTE/DCL/APP/034072 08.01/EN Approved-Preliminary 27/Jun/2014 Page 5/504

6.11.2.5 T-CAC per VLAN in uplink ..................................................................... 302

Alcatel-Lucent - Proprietary - Use pursuant to applicable agreements

LTE/DCL/APP/034072 08.01/EN Approved-Preliminary 27/Jun/2014 Page 6/504

6.15.1 Static configuration ............................................................................................................... 347

Alcatel-Lucent - Proprietary - Use pursuant to applicable agreements

LTE/DCL/APP/034072 08.01/EN Approved-Preliminary 27/Jun/2014 Page 7/504

7.1.7 LAG ...................................................................................................................................... 376

Alcatel-Lucent - Proprietary - Use pursuant to applicable agreements

LTE/DCL/APP/034072 08.01/EN Approved-Preliminary 27/Jun/2014 Page 8/504

8.1 CONNECTIVITY ........................................................................................................................ 395

Alcatel-Lucent - Proprietary - Use pursuant to applicable agreements

LTE/DCL/APP/034072 08.01/EN Approved-Preliminary 27/Jun/2014 Page 9/504

8.2.8.1 IP ................................................................................................. 468

Alcatel-Lucent - Proprietary - Use pursuant to applicable agreements

LTE/DCL/APP/034072 08.01/EN Approved-Preliminary 27/Jun/2014 Page 10/504

Alcatel-Lucent - Proprietary - Use pursuant to applicable agreements

LTE/DCL/APP/034072 08.01/EN Approved-Preliminary 27/Jun/2014 Page 11/504

Figure 54: Two-way propagation delay determination in PTP ..................................................................... 115

Alcatel-Lucent - Proprietary - Use pursuant to applicable agreements

LTE/DCL/APP/034072 08.01/EN Approved-Preliminary 27/Jun/2014 Page 12/504

Alcatel-Lucent - Proprietary - Use pursuant to applicable agreements

LTE/DCL/APP/034072 08.01/EN Approved-Preliminary 27/Jun/2014 Page 13/504

Figure 168: M3 Interface Profile .................................................................................................................... 478

Alcatel-Lucent - Proprietary - Use pursuant to applicable agreements

LTE/DCL/APP/034072 08.01/EN Approved-Preliminary 27/Jun/2014 Page 14/504

Alcatel-Lucent - Proprietary - Use pursuant to applicable agreements

LTE/DCL/APP/034072 08.01/EN Approved-Preliminary 27/Jun/2014 Page 15/504

Alcatel-Lucent - Proprietary - Use pursuant to applicable agreements

LTE/DCL/APP/034072 08.01/EN Approved-Preliminary 27/Jun/2014 Page 16/504

Each of the LTE nodes has its own release naming:

1.1 OBJECT AND SCOPE OF THIS DOCUMENT

1.2 AUDIENCE FOR THIS DOCUMENT

1.3 TEG NAMING CONVENTIONS

Alcatel-Lucent - Proprietary - Use pursuant to applicable agreements

LTE/DCL/APP/034072 08.01/EN Approved-Preliminary 27/Jun/2014 Page 17/504

The product associated rules are presented as follows:

Aims at describing what is supported or not

The Engineering Guidelines are presented as follows:

The restrictions are presented as follows:

When feature is not supported or is not as described into standards

<Domain>: Identifies which Node, Network Element, Interface… it is applicable

Table 1: Meaning of <Nature>

Alcatel-Lucent - Proprietary - Use pursuant to applicable agreements

LTE/DCL/APP/034072 08.01/EN Approved-Preliminary 27/Jun/2014 Page 18/504

2.1 APPLICABLE DOCUMENTS

Alcatel-Lucent - Proprietary - Use pursuant to applicable agreements