Call Handling and Bearer Management

LTE Radio Access, Rel. RL40, Operating Documentation, Issue 02

Call Handling and Bearer Management

DN0943944

Issue 04 Approval Date 2012-10-30

Confidential

Nokia Siemens Networks is continually striving to reduce the adverse environmental effects of its products and services. We would like to encourage you as our customers and users to join us in working towards a cleaner, safer environment. Please recycle product packaging and follow the recommendations for power use and proper disposal of our products and their compo-nents.

If you should have questions regarding our Environmental Policy or any of the environmental services we offer, please contact us at Nokia Siemens Networks for any additional information.

2 DN0943944


Id:0900d8058098ed35Confidential

The information in this document is subject to change without notice and describes only the product defined in the introduction of this documentation. This documentation is intended for the use of Nokia Siemens Networks customers only for the purposes of the agreement under which the document is submitted, and no part of it may be used, reproduced, modified or transmitted in any form or means without the prior written permission of Nokia Siemens Networks. The documentation has been prepared to be used by professional and properly trained personnel, and the customer assumes full responsibility when using it. Nokia Siemens Networks welcomes customer comments as part of the process of continuous development and improvement of the documentation.

The information or statements given in this documentation concerning the suitability, capacity, or performance of the mentioned hardware or software products are given "as is" and all liability arising in connection with such hardware or software products shall be defined conclusively and finally in a separate agreement between Nokia Siemens Networks and the customer. However, Nokia Siemens Networks has made all reasonable efforts to ensure that the instructions contained in the document are adequate and free of material errors and omissions. Nokia Siemens Networks will, if deemed necessary by Nokia Siemens Networks, explain issues which may not be covered by the document.

Nokia Siemens Networks will correct errors in this documentation as soon as possible. IN NO EVENT WILL Nokia Siemens Networks BE LIABLE FOR ERRORS IN THIS DOCUMENTA-TION OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDI-RECT, INCIDENTAL OR CONSEQUENTIAL OR ANY LOSSES, SUCH AS BUT NOT LIMITED TO LOSS OF PROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESS OPPORTUNITY OR DATA,THAT MAY ARISE FROM THE USE OF THIS DOCUMENT OR THE INFORMATION IN IT.

This documentation and the product it describes are considered protected by copyrights and other intellectual property rights according to the applicable laws.

The wave logo is a trademark of Nokia Siemens Networks Oy. Nokia is a registered trademark of Nokia Corporation. Siemens is a registered trademark of Siemens AG.

Other product names mentioned in this document may be trademarks of their respective owners, and they are mentioned for identification purposes only.

Copyright Nokia Siemens Networks 2013. All rights reserved

f Important Notice on Product SafetyThis product may present safety risks due to laser, electricity, heat, and other sources of danger.

Only trained and qualified personnel may install, operate, maintain or otherwise handle this product and only after having carefully read the safety information applicable to this product.

The safety information is provided in the Safety Information section in the Legal, Safety and Environmental Information part of this document or documentation set.

The same text in German:

f Wichtiger Hinweis zur Produktsicherheit Von diesem Produkt knnen Gefahren durch Laser, Elektrizitt, Hitzeentwicklung oder andere Gefahrenquellen ausgehen.

Installation, Betrieb, Wartung und sonstige Handhabung des Produktes darf nur durch geschultes und qualifiziertes Personal unter Beachtung der anwendbaren Sicherheits-anforderungen erfolgen.

Die Sicherheitsanforderungen finden Sie unter Sicherheitshinweise im Teil Legal, Safety and Environmental Information dieses Dokuments oder dieses Dokumentations-satzes.

DN0943944 3



Table of contentsThis document has 63 pages.

Summary of changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1 Introduction to call handling and bearer management. . . . . . . . . . . . . . . 9

2 Call handling and bearer management features . . . . . . . . . . . . . . . . . . 112.1 Functional overview of LTE5: Radio bearer and S1 bearer establishment

and release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.2 Functional overview of LTE20: Admission control . . . . . . . . . . . . . . . . . 132.3 Functional overview of LTE50: UE state management . . . . . . . . . . . . . 132.4 Functional overview of LTE747: Support of UE radio capabilities . . . . . 142.5 Functional overview of LTE905: Non GBR QCI 5, 6, 7, 8 and 9 . . . . . . 15

3 Architecture of call handling and bearer management . . . . . . . . . . . . . 16

4 UE state models in MME and eNB . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.1 EPS mobility management state model . . . . . . . . . . . . . . . . . . . . . . . . . 204.2 EPS connection management state model . . . . . . . . . . . . . . . . . . . . . . 214.3 RRC states in LTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5 EPS bearer services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235.1 EPS bearer service architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255.2 QoS Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

6 QCI characteristic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296.1 LTE518: Operator Specific QCI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316.2 Treatment for bearers with QCI = 2, 3, 4. . . . . . . . . . . . . . . . . . . . . . . . 31

7 Message flows for bearer management procedures . . . . . . . . . . . . . . . 337.1 EPS Bearer establishment and release . . . . . . . . . . . . . . . . . . . . . . . . . 337.2 EPS Bearer events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377.3 LTE519: eRAB Modification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387.4 Physical reconfiguration procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

8 Bearer management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428.1 Basic functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428.2 Enhancements in RL20 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448.3 Bearer Management in RL30. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468.3.1 Supported QCI values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468.3.2 LTE518: Operator specific QCI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468.3.3 LTE572: IMS Emergency Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468.3.4 LTE522: S1 Partial Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468.3.5 LTE450: MME Capacity Value Change . . . . . . . . . . . . . . . . . . . . . . . . . 468.4 Bearer Management in RL40. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478.4.1 Supported QCI values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478.4.2 Deriving the logical channel configuration . . . . . . . . . . . . . . . . . . . . . . . 478.4.3 LTE496: GBR EPS Bearers with QCI 2, 3 and 4 . . . . . . . . . . . . . . . . . . 478.4.4 LTE497: Smart Admission Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488.4.5 LTE519: eRAB Modification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488.4.6 LTE534: ARP Based Admission Control . . . . . . . . . . . . . . . . . . . . . . . . 48

4 DN0943944



8.4.7 LTE587: Multiple GBR EPS Bearers per UE . . . . . . . . . . . . . . . . . . . . . 49

9 Radio admission control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509.1 Basic RAC functions (RL10) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509.2 Interaction of radio admission control with other RRM functions . . . . . . 509.3 Radio admission control mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . 519.3.1 Margin for the maximum number of active UEs in the cell accessing the cell

via handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529.3.2 Maximum bit rate in UL and DL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 539.4 Enhancements of RL20 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 549.4.1 RAC support of multiple DRBs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 549.4.2 RAC limits the amount of GBR-DRBs. . . . . . . . . . . . . . . . . . . . . . . . . . . 549.4.3 Emergency Call handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 549.5 Enhancements of RL40 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 549.5.1 Smart Admission Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 549.5.2 ARP Based Admission Control for E-RABs . . . . . . . . . . . . . . . . . . . . . . 55

10 UE state management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5710.1 IMS Emergency Sessions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5910.2 Support of DRX. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

11 Cell Based Location Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

12 Links to Management data ordered by releases. . . . . . . . . . . . . . . . . . . 6212.1 Management data for RL09 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6212.2 Management data for RL10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6212.3 Management data for RL20 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6212.4 Management data for RL30 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6212.5 Management data for RL40 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

DN0943944 5



List of figuresFigure 1 LTE entities involved in bearer management. . . . . . . . . . . . . . . . . . . . . 16Figure 2 Architecture of RRM and Telecom functions from call handling and bearer

management point of view. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Figure 3 Time scale of RRM functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Figure 4 EPS Mobility Management (EMM). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Figure 5 EPS connection management state model in the UE . . . . . . . . . . . . . . 21Figure 6 EPS connection management state model in the MME. . . . . . . . . . . . . 22Figure 7 RRC states in LTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Figure 8 Data path with one default bearer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Figure 9 Data path with two default and one dedicated bearers . . . . . . . . . . . . . 24Figure 10 Control plane protocol stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Figure 11 User plane protocol stack for the data transmission between UE, eNB, and

S-GW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Figure 12 EPS bearer service architecture (GTP-based S5/S8) . . . . . . . . . . . . . . 26Figure 13 EPS bearer establishment by S1AP: Initial context setup procedure (At-

tach) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Figure 14 EPS bearer establishment by S1AP: Initial context setup procedure (Ser-

vice) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Figure 15 EPS bearer establishment by S1AP:E-RAB setup request . . . . . . . . . . 35Figure 16 EPS bearer release procedure by S1AP:E-RAB release procedure . . . 36Figure 17 EPS Bearer Modification Procedure by S1AP message UE Context Modi-

fication procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Figure 18 EPS bearer fault (single default bearer). . . . . . . . . . . . . . . . . . . . . . . . . 37Figure 19 EPS Bearer Fault for a subset of bearers . . . . . . . . . . . . . . . . . . . . . . . 38Figure 20 E-RAB Modify Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Figure 21 L1 reconfiguration upon PUCCH scheduling request failure . . . . . . . . . 40Figure 22 Overview of ARP based admission control . . . . . . . . . . . . . . . . . . . . . . 56

6 DN0943944



List of tablesTable 1 Call handling and bearer management features . . . . . . . . . . . . . . . . . . 11Table 2 Identifiers for addressing PLMN and MMEs . . . . . . . . . . . . . . . . . . . . . 20Table 3 Standardized QCI characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Table 4 Congestion Handling configured by gbrCongHandling. . . . . . . . . . . . . . 32Table 5 Parameters Mapping for RLC AM parameters . . . . . . . . . . . . . . . . . . . . 44Table 6 Parameter Mapping for PDCP parameters . . . . . . . . . . . . . . . . . . . . . . 44Table 7 Parameter Mapping for logical channel configuration . . . . . . . . . . . . . . 47

DN0943944 7

Call Handling and Bearer Management Summary of changes

Id:0900d8058094dd68Confidential

Summary of changesChanges between issues 03A (2011-11-10, RL30) and 04 (2012-10-30, RL40)

Introduction to call handling and bearer management (1)

New features: LTE496: Support of QCI 2, 3 and 4 LTE497: Smart Admission Control LTE519: eRAB Modification LTE534: ARP Based Admission Control for E-RABs LTE587: Multiple GBR EPS Bearers per UECall handling and bearer management features (2)

LTE496: Support of QCI 2,3 and 4 LTE497: Smart Admission Control LTE519: eRAB Modification LTE534: ARP Based Admission Control for E-RABS LTE587: Multiple GBR EPS Bearers per UE LTE440: S1 Overload HandlingQCI characteristic (6)

Removal of the Workaround from RL30 for QCI 2,3,4 LTE496: Support of QCI 2,3 and 4Message flows for bearer management procedures (7)

LTE519: eRAB ModificationBearer management (8)

LTE587: Multiple GBR EPS Bearers per UE LTE496: Support of QCI 2, 3 and 4 LTE497: Smart Admission Control LTE534: ARP based admission control LTE519: eRAB Modification Treatment of a eRAB Modify RequestLTE587: Multiple GBR EPS Bearers per UE (8.4.7)

New in RL40: LTE587: Multiple GBR EPS Bearers per UERadio admission control (9)

RL40: New feature: LTE497: Smart Admission ControlEnhancements of RL40 (9.5)

New in RL40: LTE497: Smart Admission ControlLinks to Management data ordered by releases (12)

chapter Links to Management data addedChanges between issues 03 (2011-06-10, RL30) and 03A (2011-11-10, RL30)Treatment of a eRAB Modify Request

8 DN0943944


Id:0900d8058094dd68Confidential

Summary of changes

Changes between issues 2A (2011-02-18, RL20) and 03 (2011-06-10, RL30)New features:

LTE68: Support of Cell Based Location Service LTE450: MME Capacity Value Change LTE518: Operator Specific QCI LTE522: S1 Partial Reset LTE572: IMS Emergency Session LTE42: Support of DRX in RRC Connected Mode LTE473: Extended DRX settingsand the workaround for QCI values 2,3,4.

DN0943944 9

Call Handling and Bearer Management Introduction to call handling and bearer management

Id:0900d80580964d99Confidential

1 Introduction to call handling and bearer man-agementCall handling is a function that provides a logical interface for call control and signaling to handle physical resources associated with a call. Call handling is used to seize, modify, release and connect resources.

A bearer is an information transmission path of a defined capacity, delay and bit error rate.

The scope of the document is besides giving some general basic information to outline the NSN features belonging to call handling and bearer management.

The document at hand describes all Evolved Packet System (EPS) bearer management functions needed in the eNB to enable the transmission of user data between a UE and the Evolved Packet Core (EPC). The requests for the establishment of Radio Bearers (RBs) are admitted or rejected on a cell level by the radio admission control.

The eNB supports a number of bearer combinations. The operator can offer and the customer can use a combination of different services for a UE. It is possible to combine SRB1, SRB2 (Signaling Radio Bearer) and up to 6 DRBs .

Individual UE state models are used to describe the status of a UE for EPS connection management (ECM) and EPS mobility management (EMM): ECM-CONNECTED

The RRC connection is established on the air interface and the S1 connection on the S1-MME interface.

ECM-IDLEThe RRC connection is released on the air interface and the S1 connection on the S1-MME interface. The UE is listening on the SRB0 BCCH and PCCH. The UE can be reached by paging.

EMM-REGISTEREDThe registration procedure has been successful for the UE.

EMM-DEREGISTEREDThe UE has been switched off.

The Radio Resource Control (RRC) states in LTE are: RRC_IDLE and RRC_CONNECTED.

One default EPS bearer is established during the initial access between UE and EPC with the following characteristics: The application IP address and the default EPS bearer are maintained with the state

transition from ECM-IDLE to ECM-CONNECTED between UE and EPC. The eNB does not store the UE context in ECM-IDLE state. By UE context is meant

a data structure in memory to store all the information related to specific UE.

More than one default bearer can exist if the UE has several applications running to dif-ferent servers (voice, FTP,..)

One default EPS bearer is supported with a single radio bearer and a single S1 bearer per UE in ECM-CONNECTED state. The default EPS bearer is a non-GBR bearer from LTE point of view.

The basic eNB-related functions are: UE context setup and release between EPC and eNB S1 bearer establishment and release between EPC and eNB

10 DN0943944


Id:0900d80580964d99Confidential

Introduction to call handling and bearer management

Radio bearer establishment and release between eNB and UEThe MME applies a semi-static UE-AMBR value in the default EPS bearer setup with the following characteristics: The Aggregate Maximum Bit Rate (AMBR) has a global value without UE or sub-

scription differentiation. The AMBR is only valid for a complete UE; GBRs have a fixed requested bitrate. The AMBR must be configured below UE capabilities. The eNB applies AMBR as maximum bit rate setting for the packet scheduler.The eNB admits EPS bearers with the QCIs 1, 2, 3, .., 9. Bearers with QCI = 1,2,3,4 are GBR Bearers. Bearers with QCI 1 are recommended to be used for conversational voice over IP. Furthermore, Operator QCIs 128,..,254 are supported.

Radio admission control (RAC) is responsible for controlling the use of radio resources by accepting or rejecting requests on additional resources. RAC is specified via event-driven interactions with associated parameters. The events are triggered by the Telecom control plane.

UE state handling covers those AS (Access Stratum, in a LTE- based system, the access stratum consists of protocols that manage the interaction between the user equipment and the eNB) procedures that are involved in initiation and support of EPC connection management state transitions such as: Paging

triggering the UE to initiate an ECM-IDLE to ECM-CONNECTED transition Initial access

transition to ECM-CONNECTED Signaling connection release

transition to ECM-IDLE Error scenarios

for example RRC connection re-establishment

The eNB retrieves the UE radio access capability parameters via: S1AP initial setup request message the RRC UE capability transfer procedure in case it is not provided via S1AP the X2AP in case of handoverThe UE radio access capability parameters are stored in the eNB. They are evaluated by the related activated and supported functions.

The UE radio access capability parameters consist of: access stratum release UE category PDCP parameters physical layer parameter RF parameter measurement parameter feature group indicator inter RAT-parameters

DN0943944 11

Call Handling and Bearer Management Call handling and bearer management features

Id:0900d80580952084Confidential

2 Call handling and bearer management featuresTable 1 shows all features related to call handling and bearer management per release.

Feature Related documents Release

LTE5: Radio bearer and S1 bearer establishment and release

Call handling and bearer man-agement functional area description

RL09

LTE20: Admission control Call handling and bearer man-agement functional area description

RL09

LTE45: Fair scheduler (UL/DL) Packet scheduler functional area description

RL09

LTE49: Paging Idle mode operations func-tional area description

RL09

LTE50: UE state management Call handling and bearer man-agement functional area description

RL09

LTE747: Support of UE radio capabili-ties

Call handling and bearer man-agement functional area description

RL10

LTE905: Non GBR QCI 5, 6, 7, 8 and 9 Call handling and bearer man-agement functional area description

RL10

LTE37/38: Ciphering/Integrity Protec-tion

LTE37/38: Ciphering and Integ-rity Protection feature descrip-tion

RL10

LTE7: Support of multiple EPS bearer LTE7: Support of Multiple EPS Bearer feature description

RL20

LTE9: Service differentiation LTE9: Service Differentiation feature description

RL20

LTE10: EPS bearers for conversa-tional voice

LTE10: EPS Bearers for Con-versational Voice feature description

RL20

LTE11: Robust header compression LTE11: Robust Header Com-pression feature description

RL20

LTE13: Rate capping LTE13: Rate Capping feature description

RL20

LTE22: Emergency call handling LTE22: Emergency Call Han-dling

RL20

Table 1 Call handling and bearer management features

12 DN0943944



Call handling and bearer management features

2.1 Functional overview of LTE5: Radio bearer and S1 bearer establishment and releaseThe LTE5: Radio bearer and S1 bearer establishment and release feature for end-user services is a part of the basic user data management functionality.

Bearer management procedures establish the default Evolved Packet System (EPS) bearer that provides an always-on service for a user offered data services.

When attached, the default EPS bearer is established between a UE and Evolved Packet Core (EPC). The application IP address and default EPS bearer are maintained with the state transition from ECM_IDLE to ECM_CONNECTED between UE and EPC.

LTE522: S1 partial reset LTE522:S1 partial reset feature description

RL30

LTE68: Support of Cell Based Location Service

LTE68: Support of Cell Based Location Service feature description

RL30

LTE572: IMS Emergency Session LTE572: IMS Emergency Session feature description

RL30

LTE518: Operator Specific QCI LTE518: Operator Specific QCI feature description

RL30

LTE450: MME Capacity Value Change LTE450: MME Capacity Value Change feature description

RL30

LTE42: Support of DRX in RRC con-nected mode

LTE42: Support of DRX in RRC connected mode feature description

RL30

LTE473: Extended DRX settings LTE473: Extended DRX settings feature description

RL30

LTE496: Support of QCI 2,3 and 4 LTE496: Support of QCI 2,3 and 4 feature description

RL40

LTE497: Smart Admission Control LTE497: Smart Admission Control feature description

RL40

LTE519: eRAB Modification LTE519: eRAB Modification feature description

RL40

LTE534: ARP Based Admission Control for E-RABs

LTE534: ARP Based Admis-sion Control for E-RABs feature description

RL40

LTE587: Multiple GBR EPS Bearers per UE

LTE587: Multiple GBR EPS Bearers per UE feature description

RL40

LTE:440 S1 Overload Handling LTE440: S1 Overload Han-dling feature description

RL40

Feature Related documents Release

Table 1 Call handling and bearer management features (Cont.)

DN0943944 13



Currently, one default EPS bearer is supported so that a single data radio bearer and a single S1 bearer is needed per UE in ECM_CONNECTED state. The default EPS bearer is a non-GBR bearer from LTE point of view.

The following eNB-related functions are included: UE context setup and release between EPC and eNB S1 bearer establishment and release between EPC and eNB Radio bearer establishment and release between eNB and UEThe MME applies semi-static UE-AMBR values during the default EPS bearer setup: The AMBR has a global value without UE or subscription differentiation. The AMBR must be configured below the UE capabilities. The eNB applies the AMBR as maximum bit rate setting for the packet scheduler.

2.2 Functional overview of LTE20: Admission controlThe LTE20: Admission control feature introduces a mechanism that decides on the admission of incoming calls based on the number of RRC connections and the number of connected users per cell. Handover requests can be prioritized over initial access requests with individual thresholds.

Connection-based Radio Admission Control (RAC) maintains the eNB in stable opera-tion and ensures a minimum service level for individual end users.

Radio admission control uses separate thresholds for the maximum number of RRC connections and the maximum number of connected users per cell.

An RRC connection is can be established when the Signaling Radio Bearers (SRB1s) have been successfully configured. The UE is considered as RRC connected when a signaling radio bearer is established. The SRB1 establishment is checked against the threshold maxNumRc, SRB2 is admitted together with the default DRB. The number of RRC connected users (only SRB1) includes the number of activated UEs, where the UE has an SRB1, SRB2 and at least 1 DRB. The threshold maxNumRrc is greater than the threshold maxNumActUe.Radio admission control thresholds are operator configurable, see chapter Radio admission control. The upper limit for the maximum number of supported connections depends on the baseband hardware configuration of the eNB and on cell configuration parameters such as the cell bandwidth.

Radio admission control is triggered with SRB1 establishment and for each DRB-Setup or DRB-Release to initial access or due to handover. Possible later resource congestion is handled by the packet scheduler. For more information on packet scheduler function, see Packet scheduler functional area description.

From RL20 on it is possible to admit more than one DRB per UE if LTE7: Support of Multiple EPS bearers is activated.

2.3 Functional overview of LTE50: UE state managementThe LTE50: UE state management feature provides session and RRC connection state management procedures.

14 DN0943944



Call handling and bearer management features

Individual UE state models are used to describe the status of a UE for EPS connection management (ECM) and EPS mobility management (EMM): ECM-CONNECTED

The RRC connection is established on the air interface and the S1 connection on the S1-MME interface.

ECM-IDLEThe RRC connection is released on the air interface and the S1 connection on the S1-MME interface.

EMM-REGISTEREDThe registration procedure has been successful for the UE.

EMM-DEREGISTEREDThe UE has been switched off.

The Radio Resource Control (RRC) states in LTE are RRC_IDLE and RRC_CONNECTED.

UE state handling covers those AS procedures that are involved in initiation and support of EPC connection management state transitions such as: Paging

triggering the UE to initiate a ECM-IDLE to ECM-CONNECTED transition Initial access

transition to ECM-CONNECTED Signaling connection release

transition to ECM-IDLE Error scenarios

for example RRC connection re-establishment

2.4 Functional overview of LTE747: Support of UE radio capa-bilitiesThe LTE747: Support of UE radio capabilities feature introduces the basic function needed to take into account the UE radio capabilities in individual RRM procedures.

The eNB retrieves the UE radio access capability parameters from one of the following sources: the S1AP initial setup request message the RRC UE capability transfer procedure if it is not provided via S1AP the X2AP in the event of a handoverThe UE radio access capability parameters are stored in the eNB and evaluated by indi-vidual RRM functions.

The UE radio access capability parameters include: access stratum release UE category PDCP parameters physical layer parameter RF parameter measurement parameter feature group indicator iInter RAT-parameters

DN0943944 15



The eNB sends the UE radio access capability parameters to: the MME if the UE radio capabilities have been retrieved via RRC the neighbor eNBs in the event of a handover

2.5 Functional overview of LTE905: Non GBR QCI 5, 6, 7, 8 and 9The LTE905: Non GBR QCI 5,6,7,8 and 9 feature introduces the functionality that allows the usages of different QCIs for non GBR bearers. The eNB supports EPS bearers with the QCIs 5, 6, 7, 8, and 9.

In RL40 all QCI=1,2,3, ..,9 are supported. Furthermore, operator- specific QCIs 128,..,254 are supported.

16 DN0943944


Id:0900d8058094ddfaConfidential

Architecture of call handling and bearer management

3 Architecture of call handling and bearer man-agementBearer management is part of the control plane function while radio admission control is part of the radio resource management function. Radio resource management closely cooperates with those control plane and user plane functions that form the Telecom functional area.

Figure 1 provides an overview on the LTE entities involved in bearer management.

Figure 1 LTE entities involved in bearer management

where:

MME: Mobility Management Entity, termination point for control plane protocol stackS-GW: Termination point user plane protocol stackeNB: evolved NodeBS1: Control interface between MME and eNodeB, user plane interface between S-GW and eNB

X2: Interface between two eNBs (not in the scope of bearer management)UE: User EquipmentUu: Air interface between eNB and UEFigure 2 shows the call handling and bearer management function in the overall context of radio resource management functions and their interdependencies with control plane and user plane.

eNB

UE

MME/S-GW MME/S-GW

Uu UuS1

S1 S1

S1

X2

X2

X2

LTE

eNB

eNB

DN0943944 17

Call Handling and Bearer Management Architecture of call handling and bearer management


Figure 2 Architecture of RRM and Telecom functions from call handling and bearer management point of view

The design of radio resource management as functional area in LTE is future proof and easily extensible. RRM in LTE starts with a limited number of basic functions that are continuously upgraded release by release.

The following radio resource management functions are supported: U-Plane Protocol stacks and SIB

L1/L2 configuration System information broadcast

18 DN0943944



Architecture of call handling and bearer management

Support of 16 QAM (UL/DL) and 64 QAM (DL) Transmission modes/MIMO

DRX/DTX algorithm and control Antenna management and MIMO control Dynamic MIMO mode and antenna control

Idle mode operations Inter-cell interference coordination Cell selection and re-selection Paging Idle mode mobility

Call handling and bearer management Radio bearer control Radio admission control UE state management Support of UE radio capabilities Congestion control Ciphering Integrity protection

Packet scheduler Packet scheduling Support of aperiodic CQI reports Rate Capping Support in UL/DL considering AMBR Support of UE Capabilities Service differentiation of non-GBR bearers

Link control Load balancing UL Power control DL Power control/per antenna rate control and physical-resource-block-specific

power loading Closed loop UL power control Outer link quality control Link adaptation by adaptive modulation and coding (AMC) Radio link failure support

Handover Connection mobility control Intra- and inter-eNB handover with X2

The RRM and Telecom functional area descriptions focus on RAN relevant issues excluding for example transport and core/S-GW functions.

High level characteristics of the radio resource management functions are: functional scope

UE scopehandover control, power control, adaptive modulation and coding (UL/DL AMC), outer link quality control, SU-MIMO/Antenna control, and inactivity control

cell scopeadmission control, packet scheduler

DN0943944 19

Call Handling and Bearer Management Architecture of call handling and bearer management


RAN scopeload balancing, inter-cell interference coordination

Inter-RAT scopeinterworking with GERAN, UTRAN, inter-RAT load balancing

time scaleThe time scale is characterized by the typical invocation period by other functions, that is the typical time interval between two successive calls of an individual RRM function referring to a single UE. small time scale

Packet scheduling and DL adaptive modulation and coding/adaptive transmis-sion bandwidth are frequently involved since they act on TTI Basis. RRM func-tions with small time scale are called Layer 2 RRM in the context of this document.

intermediate time scaleUplink link adaptation/adaptive modulation and coding, UL power control, and MIMO control belong to these RRM functions.

large time scaleConnection mobility control and radio admission control are used more sporad-ically. It might last several seconds referring to a single UE. Depending on UE speed and deployment-specific cell sizes, the time period between cell changes (inter handover time) might also last some seconds.

Figure 3 shows the time scale of RRM functions.

Figure 3 Time scale of RRM functions

Layer 3RRMConnection Mobility Control

Layer 2RRM

Time Scale

CallDuration

InterhandoverTime

ChannelFading Time

Burst or PacketDuration

Traffic, Channel andLocation Variations

Traffic, Channel andLocation Variations Radio Admission Control

Intercell Interference Coordination

1 ms

10 ms

100 ms

1 s

10 s

100 s

Load Balancing , Congestion Control

Packet Scheduling (UL/DL), fast DL AMC, fast ATB

L3 SignalingDelay

Slow UL Power Control(open/closed

Loop)


Loop)

Outer Link Quality Control (OLQC)

UE UE

LTE TTI

Slow UL LA/AMC,Slow UL ATB


DynamicMIMOControl

DynamicMIMOControl

Layer 3RRMConnection Mobility Control

Layer 2RRM

Time Scale

CallDuration

InterhandoverTime

ChannelFading Time

Burst or PacketDuration

Radio Admission Control

1 ms

10 ms

100 ms

1 s

10 s

100 s

1 ms

10 ms

100 ms

1 s

10 s

100 s

Packet Scheduling (UL/DL), fast DL AMC, fast ATB

L3 SignalingDelay


Loop)


Loop)

Outer Link Quality Control (OLQC)

LTE TTI



DynamicMIMOControl

DynamicMIMOControl

20 DN0943944


Id:0900d8058090902aConfidential

UE state models in MME and eNB

4 UE state models in MME and eNBThis section introduces the following UE state models: EPS mobility management state model EPS connection management state model RRC states in LTEEPS mobility management and EPS connection management state models are managed in the UE and in the MME, that is, they are not managed in the eNB.

Table 2 shows definitions for the identifiers used for the addressing for PLMNs and MMEs.

4.1 EPS mobility management state modelThe EPS Mobility Management (EMM) states describe the mobility management states that result from the NAS mobility management procedures such as Attach and Tracking Area Update procedures. The EPS mobility management states are: EMM-DEREGIS-TERED and EMM-REGISTERED, see Figure 4.

Identifier Definition

MCC Mobile country code

MNC Mobile Network Code

PLMN Id MCC & MNC

TAI MCC & MNC & TAC (Tracking Area Code)

LAI MCC & MNC & LAC (Location Area Code)

IMSI MCC & MNC & MSIN (Mobile Subscriber Identification Number)

M-TMSI MME Temporary Mobile Subscribe Identity

S-TMSI MME Code & M-TMSI

GUMMEI MCC & MNC & MME Group Id & MME Code

GUTI GUMMEI & M-TSMI = MCC & MNC & MME Group Id & MME Code & M-TMSI

Table 2 Identifiers for addressing PLMN and MMEs

DN0943944 21

Call Handling and Bearer Management UE state models in MME and eNB


Figure 4 EPS Mobility Management (EMM)

The UE enters the EMM-REGISTERED state by a successful registration procedure which is either an Attach procedure or a Tracking Area Update procedure. EMM states are not visible in the Access Stratum. For more information, see 3GPP TS23.401.

4.2 EPS connection management state modelThe EPS Connection Management (ECM) states describe the signaling connectivity between the UE and the Evolved Packet Core (EPC). EPS connection management states are: ECM-IDLE and ECM-CONNECTED.

For a UE in ECM-CONNECTED state, a signaling connection exists between the UE and the MME. This signaling connection consists of two parts: RRC connection, see Figure 5 UE-associated signaling connection across the S1_MME called UE-associated

logical S1-connection, see Figure 6

EPS connection management state transitions are supported by the Access Stratum and therefore are indirectly visible in the eNB. For more information, see 3GPP TS23.401.

Figure 5 EPS connection management state model in the UE

EMM -DEREGISTERED EMM -REGISTERED

Attach accept, TAU accept

Detach,

Attach Reject,

TAU reject All bearers deactivated

ECM-IDLE ECM-CONNECTED

RRC connection established

RRC connection released

22 DN0943944



UE state models in MME and eNB

Figure 6 EPS connection management state model in the MME

4.3 RRC states in LTE The RRC states in LTE are RRC_IDLE and RRC_CONNECTED, see Figure 7. In RRC_IDLE state, the UE monitors a paging channel and non UE-specific context is held in the eNB so that the UE is not known in LTE. For more information on RRC states in E-UTRA, see 3GPP TS36.331.

Figure 7 RRC states in LTE

ECM-IDLE ECM-CONNECTED

S1 connection established

S1 connection released

E-UTRA RRC_CONNECTED

E-UTRA RRC_IDLE

Connection establishment/release

DN0943944 23

Call Handling and Bearer Management EPS bearer services

Id:0900d8058095ecd2Confidential

5 EPS bearer servicesAn Evolved Packet System (EPS) bearer is used to transport user data between the UE and the packet data network gateway (P-GW) or the Serving gateway (S-GW) for S5/S8. An EPS bearer consists of a radio bearer, an S1 bearer and possibly an S5/S8 bearer.

LTE distinguishes between two types of bearers: default bearer

One default bearer is established when the UE connects to a PDN (Packet Data Network) and remains established throughout the lifetime of the PDN connection to provide the UE with always-on IP connectivity to that PDN. There can be more than one default bearer if multiple DRBs are activated.

dedicated bearerEach bearer configured in addition to the default bearer is named dedicated bearer.

For more information, see 3GPP TS23.401.

The UE may request/receive both an IPv4 or an IPv6 address (a UE must be able to work with IPv4 and IPv6 but not at the same time) for a PDN (dual-stack operation). One EPS bearer is able to transport both IPv4-native and IPv6-native packets. From the eNB point of view, the IP address assignment is transparent.

Also the number of dedicated bearers is not restricted to one. Dedicated bearers can be configured and released whenever necessary. The latest point in time to release them is when the UE disconnects from the PDN.

Figure 8 shows an example for the data path between UE and PDN GW with one default bearer.

Figure 8 Data path with one default bearer

Figure 9 shows an example for a data path with two default and one dedicated bearers.

UE eNB S-GW PDN GW1

IP1

Bearer 1default

Packet Filter

Packet Filter

Data Radio Bearer S1 Bearer S5/S8 Bearer

24 DN0943944



EPS bearer services

Figure 9 Data path with two default and one dedicated bearers

Figure 10 shows the control plane protocol stack.

Figure 10 Control plane protocol stack

Figure 11 shows the user plane protocol stack for the data transmission between UE, eNB, and S-GW.

NASRRC

PDCPRLCMACPHY

RRC

PDCPRLCMACPHY

S1-APSCTP

IPData Link

PHY

NASS1-APSCTP

IPData Link

PHY

eNBMMEUE

Transparent transmitted

Control plane

User plane

DN0943944 25



Figure 11 User plane protocol stack for the data transmission between UE, eNB, and S-GW

5.1 EPS bearer service architectureAn Evolved Packet System (EPS) bearer uniquely identifies traffic flows that require a common quality of service between an UE and a packet data network gateway in case of GTP-based S5/S8, see 3GPP TS23.401.

The EPS bearer is used to transport user data between the UE and the P-GW/S-GW. A radio bearer transports the packets of an EPS bearer between the UE and the

eNB. If a radio bearer exists, there is a one-to-one mapping between an EPS bearer and this radio bearer.

A S1 bearer transports the packets of an EPS bearer between the eNB and the Serving-Gateway (S-GW).

A S5/S8a bearer transports the packets of an EPS bearer between the Serving GW and the PDN Gateway (P-GW).

A radio access bearer (E-RAB) refers to the concatenation of an S1 bearer and the cor-responding radio bearer. When a data radio bearer exists, there is a one-to-one mapping between the data radio bearer and the EPS bearer/E-RAB. Figure 12 shows the EPS bearer services layered architecture.

PDCPRLCMACPHY

PDCPRLCMACPHY

IPData Link

PHY

IPData Link

PHY

eNB S-GWUE

User plane

Application layer

UDPGTP-U

UDPGTP-U

26 DN0943944



EPS bearer services

Figure 12 EPS bearer service architecture (GTP-based S5/S8)

Basic principles for the GTP-based S5/S8 bearer service architecture are: In the UE, the UL Traffic Flow Template (TFT) maps a traffic flow aggregate to an

EPS bearer in the uplink direction. In the PDN GW, the DL TFT maps a traffic flow aggregate to an EPS bearer in the

downlink direction. The UE stores the mapping between an uplink packet filter and a radio bearer to

create the mapping between traffic flow aggregate and a radio bearer in the uplink. The PDN GW stores the mapping between a downlink packet filter and a S5/S8a

bearer to create the mapping between an traffic flow aggregate and an S5/S8a bearer in the downlink.

The eNB stores the one-to-one mapping between a data radio bearer and an S1 bearer to create the mapping between a radio bearer and an S1 bearer in both the uplink and downlink.

The Serving GW stores the one-to-one mapping between an S1 bearer and an S5/S8a bearer to create the mapping between an S1 bearer and an S5/S8a bearer in both the uplink and downlink.

5.2 QoS ArchitectureEPS bearer/E-RAB (GBR and non-GBR) levelEach EPS bearer/E-RAB (GBR and non-GBR) is associated with the following bearer level QoS parameters:

QoS Class Identifier (QCI)

P-GWS-GW PeerEntity

UE eNB

EPS Bearer

Radio Bearer S1 Bearer

End-to-end Service

External Bearer

Radio S5/S8

Internet

S1

E-UTRAN EPC

Gi

E-RAB S5/S8 Bearer

DN0943944 27



Allocation and Retention Priority (ARP)A QCI is a scalar that is used as a reference to access node-specific parameters that controls bearer level packet forwarding handling such as scheduling weights, admission thresholds, queue management thresholds, link layer protocol configuration. The access node-specific parameters have been pre-configured by the operator owning the access node, for example the eNB. A one-to-one mapping of standardized QCI values to standardized characteristics is captured, see 3GPP TS 23.203.

The QoS parameter ARP contains information about the priority level, the pre-emption capability and the pre-emption vulnerability. The priority level defines the relative impor-tance of a resource request. This allows deciding whether a bearer establishment or modification request can be accepted or needs to be rejected in case of resource limi-tations (typically used for admission control of GBR traffic). It can also be used to decide which existing bearers to pre-empt during resource limitations.

GBR bearer levelEach GBR bearer is additionally associated with the following bearer level QoS param-eters:

Guaranteed Bit Rate (GBR) Maximum Bit Rate (MBR)The maximum bit rate of a GBR bearer is set equal to the guaranteed bit rate in 3GPP Rel. 8.

If the GBR limit is exceeded then the cause code Invalid QoS Combination is sent from eNB to the MME, as part of either the Initial Context Setup Response or the E-RAB Setup Response.

If an eNB can not longer sustain the guaranteed bit rate of an active GBR bearer, the eNB triggers the release of a low ARP bearer - with the help of LTE:496 Support of QCI 2,3 and 4/LTE497: Smart Admission Control.

PDN connection levelEach PDN connection, that is the IP address, is associated with the following QoS parameter: per APN (access point name) Aggregate Maximum Bit Rate (APN-AMBR).

The APN-AMBR is a subscription parameter stored per APN in the Home Subscriber Server (HSS). It limits the aggregate bit rate that can be expected to be provided across all Non-GBR bearers and across all PDN connections of the same APN, for example excess traffic might get discarded by a rate shaping function. Each of those Non-GBR bearers could potentially use the entire APN-AMBR, for example when the other Non-GBR bearers do not carry any traffic.

GBR bearers are outside the scope of APN-AMBR. The P-GW enforces the APN-AMBR in downlink. Enforcement of APN-AMBR in uplink is done in the UE and additionally in the P-GW.

UE levelEach UE is associated with the following aggregate QoS parameter: per UE Aggregate Maximum Bit Rate (UE-AMBR)

The UE-AMBR is limited by a subscription parameter stored in the Home Subscriber Server (HSS). The Mobility Management Entity (MME) sets the used UE-AMBR to the sum of the APN-AMBR of all active APNs up to the value of the subscribed UE-AMBR.

28 DN0943944



EPS bearer services

The UE-AMBR limits the aggregate bit rate that might be expected to be provided across all Non-GBR bearers of a UE, for example the excess traffic might get discarded by a rate shaping function.

The UE-AMBR is received via S1 interface from the EPC and applies to the PDCP sublayer within eNodeB. As enforcement of the UE AMBR is done in MAC sublayer based on observed throughput of non-GRB bearers, additional headers for RDCP/RLC are accounted for by margin factors (rcAmbrMgnUl in uplink, rcAmbrMgnDl in down-link).

Each of those Non-GBR bearers can potentially use the entire UE-AMBR, for example when the other Non-GBR bearers do not carry any traffic. GBR bearers are outside the scope of UE-AMBR. LTE enforces the UE-AMBR in uplink and downlink.

DN0943944 29

Call Handling and Bearer Management QCI characteristic

Id:0900d8058096004cConfidential

6 QCI characteristicThe QoS Class Identifier (QCI) characteristics describe the bearer level packet forward-ing handling that is expected from an access node, for example the LBTS.

A standardized QCI characteristic comprises (at least) the following elements:1. resource type (GBR or Non-GBR)2. priority3. packet delay budget4. packet loss rateNeither the Evolved Packet Core (EPC), nor the E-UTRAN supports any explicit feedback to trigger a rate adaptation scheme at the application/service/transport layer, see 3GPP TS23.401.

Table 3 lists the standardized QCI definitions specified in 3GPP TS 23.203 v831.

QCI Resource type

Priority Packet delay

budget (NOTE 1)

Packet error loss

rate (NOTE 2)

Example services

1

(NOTE 3)

GBR 2 100 ms 10-2 Conversational voice

2

(NOTE 3)

4 150 ms 10-3 Conversational video (live streaming)

3

(NOTE 3)

3 50 ms 10-3 Real time gaming

4

(NOTE 3)

5 300 ms 10-6 Non-Conversational video (buffered streaming)

5

(NOTE 3)

Non-GBR 1 100 ms 10-6 IMS signaling

6

(NOTE 4)

6 300 ms 10-6 Video (buffered streaming)

TCP-based (e.g., www, e-mail, chat, ftp, p2p file sharing, progressive video, etc.)

7

(NOTE 3)

7 100 ms 10-3 Voice, video (live streaming), interac-tive gaming

8

(NOTE 5)

8 300 ms 10-6 Video (buffered streaming)

TCP-based (e.g., www, e-mail, chat, ftp, p2p file sharing, progressive video, etc.)

9

(NOTE 6)

9

Table 3 Standardized QCI characteristics

30 DN0943944



QCI characteristic

For the eNB-internal QoS handling, the table of standardized QCI characteristics is extended by eNB-internal QCI characteristics. These internal QCI characteristics com-prise: Information on supported QCIs RLC mode (RLC AM or RLC UM) Index to tables of bearer-specific parameters of RLC and PDCP QCI-specific information for schedulers in UE and LBTSAll values (1...9) of the QCI of Table 3 are supported when LTE496: Support of QCI 2,3 and 4, LTE10: EPS bearers for conversational voice and LTE905: Non GBR QCI 5,6,7,8 and 9 are activated. Furthermore, it is possible to define operator specific QCIs.

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.

NOTE 2:The rate of non congestion related packet losses that may occur between a radio base station and a PCEF should be regarded as negligible. A PELR value is specified for a standardized QCI therefore applies completely to the radio interface between a UE and radio base station.

NOTE 3:This QCI is typically associated with an operator controlled service, i.e., a service where the SDF aggregate's uplink / downlink packet filters are known at the point in time when the SDF aggregate is authorized. In case of E-UTRAN this is the point in time when a corresponding dedicated EPS bearer is established / modified.

NOTE 4:This QCI could be used for prioritization of specific services according to operator configuration.

NOTE 5:This QCI could be used for a dedicated "premium bearer" (e.g. associated with premium content) for any sub-scriber / subscriber group. Also in this case, the SDF aggregate's uplink / downlink packet filters are known at the point in time when the SDF aggregate is authorized. Alternatively, this QCI could be used for the default bearer of a UE/PDN for "premium subscribers".

NOTE 6:This QCI is typically used for the default bearer of a UE/PDN for non privileged subscribers. Note that AMBR can be used as a "tool" to provide subscriber differentiation between subscriber groups connected to the same PDN with the same QCI on the default bearer.

QCI Resource type

Priority Packet delay

budget (NOTE 1)

Packet error loss

rate (NOTE 2)

Example services

Table 3 Standardized QCI characteristics (Cont.)

DN0943944 31

Call Handling and Bearer Management QCI characteristic


6.1 LTE518: Operator Specific QCIIn addition to the standardized QCI characteristics of the 3GPP Release 8/9, an operator of a network is free to define QCI characteristics particular to the network in 3GPP. In other words, the operator has the freedom to implement proprietary QCI characteristics whose definitions are only known by and are really meaningful only to the network itself. It is thus possible that the operators of different networks will implement different sets of QCI characteristics. Between the two networks, the least common denominator known by both parties is the common standardized QCI characteristics implemented by both operators. In 3GPP Release 8/9, the QCIs used for standardized QCI characteristics are in the range 19. The QCIs for operator specific characteristics have been restricted to the range 128254 to avoid conflicts if the range of QCIs for standardized QCI charac-teristics is extended in later 3GPP releases.

Examples for the usage of this feature are:

An eNB can be shared by two or more operators, with different QCIs for each of them.

For example (two operators: A and B):

Operator A has configured QCI 140, 141, 142, 143 according his QoS requirements Operator B has configured QCI 160, 161, 162, 163 according his (different) QoS

requirements

Another application of this feature is: the operator can define specific QoS-data for dif-ferent user groups, for example:

For bronze users: QCI 130, 131, 132, 133 For silver users: QCI 140, 141, 142,143 For gold users: QCI 150, 151, 152, 153.

6.2 Treatment for bearers with QCI = 2, 3, 4.With the feature LTE496: Support of QCI 2,3 and 4 bearers with QCI values 2,3 and 4 are supported. These are all GBR-bearers.

The eNB supports different RLC modes (radio link control modes) for QCI = 4. This is configurable via the parameter rlcMode of qciTab4. Possible values are RLC_AM (acknowledged mode) and RLC_UM (unacknowledged mode).

The eNB targets to enforce the delay targets for the QCIs according to 3GPP (Table 3). To reach this goal, the parameter delay_target can be configured for each QCI (as part of the structure qcitab1, qcitab2, qcitab3, qcitab4). This parameter is the maximum packet delay value used by the eNB MAC scheduling algorithm.

The maximum guaranteed bit rate is operator-configurable by the parameter maxGbrDl with the maximum limit DL of 2Mbps and the parameter maxGbrUl with the maximum limit UL of 840 kbps. These values define the maximum GBR values on the S1 interface that will be admitted by the eNB. Requests for the establishment of bearers with higher GBR are rejected.

Furthermore, these high bit rates can cause congestion. Of course, low bit rates can also cause congestion, but you need more UEs. To calculate needed resources of new GBR bearers and compare with available resources the LTE497: Smart admission Control feature is introduced. Smart admission control offers a congesting handling to get rid of traffic (according to ARP priorities) when an overbooking of resources is detected (in the scheduler).

32 DN0943944



QCI characteristic

In addition congestion is detected on cell level (on PDSCH, PUSCH as well on PDCCH) as soon as the resource usage for the guaranteed bit rate bearers exceed a configura-tive load limit (Parameter maxGBRTrafficLimit). The feature LTE496: Support of QCI 2,3 and 4 introduces an additional congestion handling controlled by the parameters gbrCongHandling and congWeightAlg.The congestion handling in the eNB is configurable via the Parameter gbrCongHandling. (Table 4)

The Parameter congWeightAlg defines a priorization behaviour in layer 2 (MAC) until either the congestion situation ends or until the congestion situation is resolved by higher layers. There are two different algorithms possible:

qciPrio: Bearers are prioritized in order of their QCI priority. arpPrioPerVul: First bearers with ARP vulnerability preemptable are prioritized in

order of the ARP priority, then the bearers with ARP vulnerability not preemptable also in order of ARP priority.

The features

LTE496: Support of QCI 2,3 and 4 LTE497: Smart admission Control LTE534: ARP based admission control for E-RABs LTE587: Multiple GBR bearers per UEcan only be enabled together by setting the actEnhAcAndGbrServices (LTE496, LTE497, LTE534) and actMultGbrBearers (LTE587)parameters to true. The feature LTE534: ARP based admission control for E-RABs replaces the permanent admission (from releases before) by a withdrawable acceptance. In case of a resource limitation, the eNB may withdraw the admission from an already admitted E-RAB to use its resources for admission of a more important (that is, with higher ARP priority) E-RAB (evolved radio access bearer).

Value Congestion Handling

0 no congestion handling

1 congestion handling within layer 2 only by applying congestion priorization of bearers according to the congestion weight (Parameter: congWeightAlg)

2 congestion handling on layer 2 and layer 3 by dropping bearers in accordance with selection criteria defined in LTE534: ARP based Admission Control for E-RABs

Table 4 Congestion Handling configured by gbrCongHandling.

DN0943944 33

Call Handling and Bearer Management Message flows for bearer management procedures

Id:0900d8058094df34Confidential

7 Message flows for bearer management pro-ceduresThis section introduces the message flows for the following procedures:

EPS Bearer Establishment EPS Bearer Events eRAB Modification Physical reconfiguration procedures

7.1 EPS Bearer establishment and releaseIn Figure 13 a message flow is shown for establishing of one or more EPS bearers with the S1AP: Initial Context Setup Request (Attach). This procedure is taken as the first action. The EPC can establish default + optional additional bearers. This message can contain UE context data (for example UE radio capabilities, security information).

Figure 13 EPS bearer establishment by S1AP: Initial context setup procedure (Attach)

34 DN0943944



Message flows for bearer management procedures

In Figure 14 you can see the message flow for an EPS bearer establishment with the S1AP: Initial Context Setup Request (Service Request). In contrast to the Attach Proce-dure, several default bearers may be established.

Figure 14 EPS bearer establishment by S1AP: Initial context setup procedure (Ser-vice)

In Figure 15 you can see the message flow for the establishment of an additional single or multiple EPS bearer with the S1AP: E-RAB setup request (E-RAB: E-UTRAN Radio ACCESS). The E-RAB Setup procedure supports:

check of activation of the multi-bearer feature check of the support of the new bearer configuration reconfiguration of the rate capping function, if a new UE-AMBR (aggregated

maximum bit rate) has been provided by MME setup of an additional single or multiple DRBs by the RRC Connection Reconfigura-

tion procedure

DN0943944 35



Figure 15 EPS bearer establishment by S1AP:E-RAB setup request

In Figure 16 another message sequence chart is shown: The release of a bearer with the S1AP: E-RAB release procedure. This S1AP: E-RAB release procedure supports the release of a single or multiple EPS bearers. This includes:

check, whether at least one non-GBR remains reconfiguration of the rate capping functions if a new UE-AMBR (aggregated

maximum bitrate) has been provided by MME release of a single or multiple DBRs by the RRC Connection Reconfiguration proce-

dure.

36 DN0943944




Figure 16 EPS bearer release procedure by S1AP:E-RAB release procedure

The Figure 17 shows the EPS Bearer Modification procedure triggered by the by S1AP message UE CONTEXT MODIFICATION REQUEST.

Figure 17 EPS Bearer Modification Procedure by S1AP message UE Context Modi-fication procedure

The procedure is started in eNB when eNB receives the S1AP message UE CONTEXT MODIFICATION REQUEST from MME and the IE UE Aggregate Maximum Bit Rate is included.

UE eNB MME

Triggering of EPS Bearer deactivation

Delete SessionDelete Bearer Req.

S1AP: E-RAB RELEASE COMMAND

S1AP: E-RAB RELEASE RESPONSE

S1AP: UL NAS TRANSPORT

Delete Bearer Resp.

DRB Release

RRC: RRCConnectionReconfiguration

RRC: RRCConnectionReconfigurationComplete

RRC: ULInformationTransfer

(E-RAB to be Removed List,NAS: DEACTIVATE BEARER CONTEXT REQUESTopt. UE-AMBR)

(E-RAB Removed List)

(NAS: DEACTIVATE BEARER CONTEXT ACCEPT)

(drbToRemoveList,List (NAS: DEACTIVATE EPS BEARER CONTEXTREQUEST))

(NAS: DEACTIVATE EPS BEARER CONTEXTACCEPT)

DN0943944 37



The eNB checks whether the feature UE-AMBR modification is activated. The eNB informs the rate capping function of UL and DL schedulers about the

modified UE-AMBR.

eNB sends the S1AP acknowledgment UE CONTEXT MODIFICATION RESPONSE to MME. MME may start an Update Bearer procedure towards S-GW/PDN-GW (e.g. for APN-AMBR update).

7.2 EPS Bearer eventsThe following EPS bearer events are shown in this chapter:

Figure 18: The fault of one single default bearer or all non-GBR S1 bearers. Figure 19: The fault of only a subset of bearers.

Figure 18 EPS bearer fault (single default bearer)

The procedure comprises the following steps:1. The eNB detects an EPS bearer-related failure such as a GTP-U Error Indication.2. The eNB detects that the single EPS bearer of a UE has failed.3. The eNB sends the S1AP: UE CONTEXT RELEASE REQUEST message to the

MME.4. The MME releases the UE.If only a subset of bearers are faulty, the following Figure 19 is applied.

S1AP: UE CONTEXT RELEASE REQUEST

UE CONTEXT RELEASE procedure

eNB detects bearer -related failure

UE eNB MME

38 DN0943944




Figure 19 EPS Bearer Fault for a subset of bearers

The procedure is started if the eNB detects the failure of one or several DRBs:

The eNB detects a bearer-related failure:GTP-U Error Indication for the S1 bearer(s)

The eNB detects that at least one non-GBR EPS bearer of a UE remains active. The eNB sends the RRC message RRCConnectionReconfiguration to UE to

release the failed DRBs When the eNB has received the RRC message RRCConnectionReconfiguration-

Complete, the eNB releases the DRBs locally at eNB. The eNB sends the S1AP message E-RAB RELEASE INDICATION for all failed

EPS Bearers to the MME. The MME releases the EPS bearer towards S-GW with the Delete Bearer proce-

dure.

7.3 LTE519: eRAB ModificationThe eNB allows changing:

the QCI (QoS class indicator) value of non-GBR (guaranteed bitrate) QCIs the ARP (allocation and retention priority) value of all QCIs the UE-AMBR (aggregate maximum bitrate) of an UEwith the:

S1AP: E-RAB MODIFY REQUEST S1AP: E-RAB MODIFY RESPONSEmessage.

In Figure 20 an example for a E-RAB Modify Request is shown: A change of QCI/ARP is triggered by the S1AP message E-RAB MODIFY REQUEST.

DN0943944 39



Figure 20 E-RAB Modify Request

When the eNB receives the S1AP message E-RAB MODIFY REQUEST from MME (for one or several EPS bearers) the following steps are done:

The eNB analysis the provided QoS parameters to derive the requested type of modification.

The eNB prepares the radio bearer modification for each EPS bearer to be modified. QCI modification: The eNB configures a new scheduling weight for the UL and

DL schedulers and a new transport DSCP for the EPS bearer. For operator-defined QCIs the eNB may change the counter group.

ARP modification: The eNB informs admission and congestion control about the new ARP value. Optionally the eNB configures a new congestion weight for GBR bearers.

No modification of bearer QoS parameters: The eNB accepts the modification without reconfiguring the EPS bearer.

For each EPS bearer for which the modification has been admitted, the eNB repeats the current logical channel configuration. [3GPP 36.331] requires that NAS PDUs can only be transmitted by the RRC message RRCConnectionReconfiguration to UE if bearers are modified (or setup or released).

UE-AMBR modification: The eNB informs UL and DL schedulers about the modified UE-AMBR.

The eNB configures the local U-Plane and T-Plane for the DRB of the modified EPS bearer(s).

The eNB sends the RRC message RRCConnectionReconfiguration to UE. This message contains for each successful modified EPS bearer a logical channel con-figuration and the NAS PDU of the EPS bearer received by the S1AP message E-RAB MODIFY REQUEST.

If the eNB receives the RRC message RRCConnectionReconfigurationComplete, the eNB sends the S1AP acknowledgment E-RAB MODIFY RESPONSE to the MME

The UE sends in parallel NAS-PDU(s) containing the NAS acknowledgment of the EPS bearer modification to the eNB by RRC message(s) ULInformationTransfer.

UE eNB MME

S1AP: E-RAB MODIFY REQUEST

S1AP: E-RAB MODIFY RESPONSE

(E-RAB Mod List (QCI, ARP,

NAS: MODIFY EPS BEARER CONTEXT REQUEST),

opt. UE-AMBR)

S1AP: UL NAS TRANSPORT

RRC: ULInformationTransfer

(NAS: MODIFY EPS BEARER CONTEXT ACCEPT )

(NAS: MODIFY EPS BEARER CONTEXT ACCEPT )

Local reconfigurations


(drbToAddModifyList,

List (NAS: MODIFY EPS BEARER CONTEXT REQUEST))

LCH Reconfiguration &

NAS procedure


40 DN0943944




The eNB forwards this NAS-PDUs (non-access-stratum packet data unit) to MME by the S1AP message UL NAS TRANSPORT.

The MME continues the Update Bearer procedure/Insert Subscriber Data proce-dure.

7.4 Physical reconfiguration proceduresFigure 21 shows the L1 reconfiguration if the scheduling request on PUCCH has failed.

Figure 21 L1 reconfiguration upon PUCCH scheduling request failure

The procedure comprises the following steps: The UE sends several times a PUCCH scheduling request but does not receive a

UL grant. Reasons are for example an insufficient power for the PUCCH. When the threshold specified by the Dedicated SR Transmission Maximum

(dSrTransMax) parameter is reached, the UE releases all its PUCCH and SRS resources and performs the scheduling request via random access. This procedure includes a ramping of UL power so that finally the scheduling request reaches the eNB.

The eNB detects that a random access scheduling request has been received for a UE for which a PUCCH scheduling request has been configured.

The eNB assigns new PUCCH and SRS resources.


UE activates new PUCCH and SRS

resources


PUCCH-SR

dsr-MaxTrans expires and UE

releases all PUCCH and SRS resources

eNB detects RA -SR for UE with PUCCH -SR

PUCCH-SR

PUCCH-SR

RA-SR

RA-SR

RA-SR

UE eNB MME

DN0943944 41



The eNB sends the RRC: RRC CONNECTION RECONFIGURATION message to inform the UE about the new PUCCH and SRS resources.

The UE acknowledges the reconfiguration by the RRC: RRC CONNECTION RECONFIGURATION COMPLETE message.

42 DN0943944


Id:0900d80580961ffbConfidential

Bearer management

8 Bearer managementBearer management is part of the LTE control plane and handles the establishment, modification, and release of bearers.

Bearer management includes: establishment and release of S1 bearers on the S1 interface establishment, modification and release of data radio bearers on the air interface provisioning of UE radio capabilities translation of S1AP QoS parameters to configuration parameters of the user plane

in the eNB and UE radio layer 2 configuration of SRB1 and SRB2 activation of AS security Additionally Bearer Management supports from RL20, RL15TD on:

service differentiation for non-GBR EPS bearers (LTE9: Service Differentiation) establishment and release for multiple default and dedicated EPS bearers (LTE7:

Support of Multiple EPS bearer) support of conversational voice EPS bearer that is mapped to a GBR DRB with RLC

UM (LTE10: EPS Bearers for Conversational Voice) support of ROHC (LTE11: Robust Header Compression) (not for RL15TD) rate capping: Support of the UE AMBR by the S1AP procedure UE context modifi-

cation (LTE13: Rate Capping UL/DL).

From RL30 on, bearer management supports additionally:

Support of emergency conversational services for release 9 UEs (LTE572: IMS Emergency Session)

Support of operator specific QCIs (LTE518: Operator specific QCI) Workaround: Establishment and Release of non GBR EPS bearers with QCI 2,3 and

4.

In RL40, bearer management supports additionally:

Establishment and release of GBR EPS Bearers with QCI 2,3 and 4 (LTE496: Support of QCI 2,3 and 4)

Establishment of multiple GBR EPS bearers with QCI 1,2,3 and 4 (LTE587: Multiple GBR EPS Bearers per UE).

Modification of ARP of EPS bearers and QCI of nonGBR EPS bearers including update of UE related UE-AMBR (LTE519: eRAB Modification)

Admission and preemption of EPS bearers with the ARP parameter (LTE534: ARP Based Admission Control)

Release of GBR EPS bearers in case of congestion on the radio interface (LTE496: Support of QCI 2,3 and 4/ LTE497: Smart Admission Control.)

8.1 Basic functionalityThe basic functions are: Establishment of non-GBR EPS bearer

The eNB supports the establishment of more than non-GBR EPS bearers per UE. The QoS parameters for these bearers are UE-AMBR and QCI.

DN0943944 43

Call Handling and Bearer Management Bearer management


Supported QoS attributes of EPS bearersThe eNB supports the following S1AP QoS attributes: QCI values 1, ... ,9 UE-AMBR

The eNB checks the support of QCIThe eNB checks whether the QCI is enabled or disabled. A QCI is accepted, if the parameter qciSupp is set to enabled. A QCI is rejected, if the parameter qciSupp is set to disabled.

Preparation of non-GBR EPS bearer for handoverFor handover purposes, the eNB prepares a non-GBR EPS bearer per UE as follows: The information container of bearer and UE parameters is built that is to be sent

from the source to the target cell. The UE is configured at the target eNB including its radio bearers. The radio resource configuration for the handover command is built.

Radio bearer configuration of SRB1 and SRB2The eNB supports the radio bearer configuration of SRB1and SRB2.

Bearer fault procedureThe eNB supports a procedure to notify a bearer related fault to the MME. The pro-cedure consists of: the eNB-internal detection of a bearer related fault trigger of the S1AP: UE CONTEXT RELEASE REQUEST message

L1 reconfigurationThe eNB supports the procedure to reconfigure L1 resources. The procedure consists of: eNB- internal detection of a need for the L1 reconfiguration trigger of the RRC: CONNECTION RECONFIGURATION message

S1AP initial context setup procedureThe eNB supports the S1AP initial context setup procedure. The procedure consists of the S1AP messages: S1AP: INITIAL CONTEXT SETUP REQUEST S1AP: INITIAL CONTEXT SETUP RESPONSE S1AP: INITIAL CONTEXT SETUP FAILUREThe release of the single EPS bearer is done by the S1AP UE context release pro-cedure.

RRC connection reconfiguration procedureThe eNB supports the RRC connection reconfiguration procedure. The procedure includes the following RRC messages: RRC CONNECTION RECONFIGURATION RRC CONNECTION RECONFIGURATION COMPLETE

RRC Radio Resource Configuration IE for SRB1 and SRB2The eNB supports the "Radio Resource Configuration" IE for the configuration of SRB1 and SRB2.

Provision of bearer-specific layer 2 parameters for DRBThe eNB provides the bearer specific layer 2 parameters for data radio bearer.

Provision of UE-related parameters upon initial context setupThe eNB provides UE-related parameters for the initial context setup procedure.

44 DN0943944



Bearer management

Provision of bearer-specific layer 2 parameters for SRB1 and SRB2The eNB provides the bearer-specific layer 2 parameters for SRB1 and SRB2.

Configuration of the local user plane for DRBThe eNB configures the local user plane for a new data radio bearer. This includes the reconfiguration of the related MAC entity and the creation of a new RLC and PDCP entity.

Configuration of the local user plane for SRB1 and SRB2The eNB configures the local user plane for an SRB. This includes the reconfigura-tion of the related MAC entity and the creation of a new RLC and PDCP entity.

Deriving the RLC AM parameters for DRBThe eNB provides the RLC AM parameters for the new RLC AM data radio bearer. The input for the parameters is taken by an instance of rlcprof1. It contains the fol-lowing parameters: rlcprofileID,pollPDU,pollRetr,tReorder,tProhib.The mapping of these parameters onto the RLC AM parameters is shown in Table 5

Deriving of PDCP parameters for DRB (RLC AM)The eNB provides the PDCP parameters for the new data radio bearer. The input for the parameters is taken from the instance PdcpProf1. It contains the parameters: PDCPProfileID, StatusRepReq, tDiscard. The mapping of these parame-ters is shown in Table 6.

Treatment of S1AP: eRAB Modify RequestsIt is described in the feature description: LTE519: eRAB Modification

8.2 Enhancements in RL20In the following list the enhancements for the multiple bearers (LTE7: Support of multiple EPS bearer) function are described.

RLC AM parameters O&M parameters

t-pollRetransmit rlcProf -> tpollRetr

pollPDU rlcProf -> pollPDU

pollbyte (for UE configuration) amRlcPollByteTable -> ulPollByte

pollbyte (for local configuration) amRlcPollByteTable -> dlPollByte

t-Reordering rlcProf -> tReorder

t-StatusProhibit rlcProf -> tProhib

Table 5 Parameters Mapping for RLC AM parameters

PDCP parameters O&M parameters

discardTimer pdcpProf -> tDiscard

statusReportRequired pdcpProf -> statusRepReq

Table 6 Parameter Mapping for PDCP parameters

DN0943944 45



Multiple Bearers-Enhancements for Initial Context Setup ProcedureThe eNB supports the establishment of multiple EPS bearers at the Initial Context Setup procedure. This includes the enhancement of radio bearer configuration and RRC Connection Reconfiguration procedure for multiple DRBs.

Multiple Bearers-Support of Addition of EPS Bearers The eNB supports the addition of single or multiple EPS bearers. The addition is trig-gered by the S1AP E-RAB Setup procedure that consists of the S1AP messages: S1AP: E-RAB SETUP REQUEST S1AP: E-RAB SETUP RESPONSEThe radio bearer configuration is enhanced for the addition of single or multiple DRBs. The RRC Connection Reconfiguration procedure is enhanced for the addition of single or multiple DRBs

Multiple Bearers-Support of Release of EPS Bearers The eNB supports the release of single or multiple EPS bearers. The release is trig-gered by the S1AP E-RAB Release that consists of the S1AP messages S1AP: E-RAB RELEASE COMMAND S1AP: E-RAB RELEASE COMPLETEThe RRC Connection Reconfiguration procedure is enhanced for the release of single or multiple DRBs.

Multiple Bearers-Support of S1AP E-RAB RELEASE INDICATIONThe eNB supports the S1AP message E-RAB RELEASE INDICATION to signal the failure of an EPS Bearer to MME.

For service differentiation purposes (LTE9: Service differentiation) the eNB provides dif-ferent QoS settings for non-GBR EPS Bearers depending on the signaled QCI:

Scheduling Weight - set per QCI RLC AM configuration: configuration via 3 profiles of RLC AM parameters

addressed by QCI PDCP configuration: configuration via 3 profiles of PDCP parameters addressed by

QCI

The eNB provides the configuration parameters for the GBR EPS Bearers with QCI 1 (conversational voice, LTE10: EPS bearers for conversational voice):

RLC UM configuration: configuration via 1 profile of RLC UM parameters PDCP configuration: configuration via 1 profile of PDCP parameters for RLC UM

DRB

The eNB supports the Robust Header Compression (LTE11: Robust header compres-sion). Therefore the ROHC configuration parameters for the GBR EPS bearers with QCI 1 are supported.

The eNB provides the UE-AMBR from the S1AP procedures to the U-Plane rate capping function (LTE13: Rate capping).

The eNB supports the intra-LTE handover via S1 interface. In addition to the inter-LTE handover via X2 interface eNB shall consider that MME may release some EPS bearers during hand over (LTE54: Intra-LTE handover via S1).

The eNB supports Feature Group Indicators used for Inter-frequency Handover (LTE55: Inter-frequency handover).

The eNB supports the triggering of the CS Fallback procedure via the S1AP messages INITIAL CONTEXT SETUP REQUEST and UE CONTEXT MODIFICATION REQUEST (LTE562: CSFB to UTRAN or GSM via redirect).

46 DN0943944



Bearer management

For this, the S1AP procedure UE Context Modification is introduced that consists of the S1AP messages:

S1AP: UE CONTEXT MODIFICATION REQUEST S1AP: UE CONTEXT MODIFICATION RESPONSE S1AP: UE CONTEXT MODIFICATION FAILURE

8.3 Bearer Management in RL30

8.3.1 Supported QCI valuesThe eNB supports the QCI values (QCI 2,3,4 by workaround)

1, 2, 3, 4,..,9 128,..,254

8.3.2 LTE518: Operator specific QCIThe eNB handles EPS bearers whose QCIs are in the range from 128 to 254. These QCIs are not standardized QCIs; up to 21 non standardized QCIs for non-GBR EPS bearers are supported.

Further information is given in the LTE518: Operator specific QCI chapter of the QCI characteristics of this FAD.

8.3.3 LTE572: IMS Emergency SessioneNB supports the IMS emergency call in normal and limited service mode.

8.3.4 LTE522: S1 Partial ResetThe LTE522: S1 partial reset feature allows the eNB to perform a bulk release of several UE-associated S1 signaling connections with one message exchange between the eNB and MME.

The reset is used by O&M procedures, for example for automatic lock: in an automatic lock, an eNB cell is deactivated and all UEs served by the cell are released by the eNB according to the S1 partial reset procedure.

The feature provides a performance-optimized release of UE-associated signaling con-nections in situations that require a simultaneous release of several UE-associated sig-naling connections of a cell, without collateral damage in other cells, for example in case of automatic lock.

In addition, the eNB is able to handle several parallel S1 partial reset procedures per one S1 link, which minimizes delays in the clearing of UE-associated logical S1 connec-tions.

For more information (including message sequence charts) see the FD: LTE522: S1 Partial Reset.

8.3.5 LTE450: MME Capacity Value ChangeThe MME can change the initial MME relative capacity value. This can be done with the MME Configuration Update Procedure. Specifically, the relative MME capacity can be

DN0943944 47



set to zero which has the effect that new UEs entering the MME pool will not be assigned to the MME.

In addition, this feature allows modification of the served GUMMEIs (Globally Unique MME Identifiers) and the MME name without release of UE associated connections.

For more information (including message sequence charts) see the feature description LTE450: MME capacity value change.

8.4 Bearer Management in RL40

8.4.1 Supported QCI valuesThe eNB supports the QCI values

1,..,9 128,..,254

8.4.2 Deriving the logical channel configurationThe eNB provides the configuration of the logical channel for the new data bearer. The parameters are mapped according Table 7

8.4.3 LTE496: GBR EPS Bearers with QCI 2, 3 and 4 The eNB provides the configuration parameters for the EPS Bearers with QCI 2, 3 and 4 and resourceType GBR. QCI 2 and 3

RLC UM configuration: configuration via QCI specific profiles of RLC UM param-eters

RRC parameters O&M parameters

priority qciTab -> schedulePrio

priotisedBitrate If the UE supports the priority bit rate feature:

for GBR bearers: prioritisedBitRate is derived from the GBR(UL) signaled by MME

for nonGBR bearers: prioritisedBit Rate is set to the O&M parameter pbrNonGBR

otherwise: the prioBitrate is set to infinity

bucketSizeDuration qciTab -> scheduleBSD

logicalchannelGroup qci lcgid

Table 7 Parameter Mapping for logical channel configuration

48 DN0943944



Bearer management

PDCP configuration: configuration via QCI specific profiles of PDCP parameters for RLC UM DRB

QCI 4 RLC configuration: RLC mode is selected by operator. Depending on the RLC

mode RLC configuration via 1 profile of RLC UM parameters or one of the profiles of RLC AM parameters.

PDCP configuration: depending on the RLC mode PDCP configuration via 1 profile of PDCP parameters for RLC UM DRB or via one of the profiles of PDCP parameters for RLC AM DRB.

8.4.4 LTE497: Smart Admission ControlThe main task of this feature is to do a forecast calculation on needed resources for GBR-DRBs. The admission/rejection of a bearer is based on measurements and not on counters. RAC (radio admission control) needs to predict the load as being caused by each new GBR radio bearer in the cell reflecting the requested transmission rates (UL/DL) under given radio conditions and considering the existing GBR load in the cell.

As second major item Smart admission control offers a congestion handling to get rid of traffic (according to ARP priorities) when an overbooking of resources is detected (in the scheduler):

Overbooking or overload may occur when

radio conditions of high bit rate users getting worse a too optimistic admission was done bursting traffic cannot be served over time

8.4.5 LTE519: eRAB ModificationThe eNB can modify:

The QCIs of a list of non-GBR EPS bearers if the old and new QCI characteristics of this EPS bearer are aligned except for scheduling weight, DSCP and counter group.

The ARP of a list of EPS bearers. The UE-AMBR of the UE.For this, the S1AP procedure E-RAB Modify is introduced that consists of the S1AP messages:

S1AP: E-RAB MODIFY REQUEST S1AP: E-RAB MODIFY RESPONSE

8.4.6 LTE534: ARP Based Admission ControlARP handling is only used in case of insufficient resources. The preemption selection is done according the ARP priorities.

The feature LTE534: ARP based admission control for E-RABs replaces the permanent admittance (from releases before) by a withdrawable acceptance. In case

Documents

Call Handling and Bearer Management