FDDLTE掉话优化指导书-R2.0.docx

FDD LTE掉话优化指导书
R2.0

法律声明

若接收中兴通讯股份有限公司（以下称为“中兴通讯”）的此份文档，即表示您已同意以下条款。若不同意以下条款，请停止使用本文档。

本文档版权所有中兴通讯股份有限公司。保留任何未在本文档中明示授予的权利。文档中涉及中兴通讯的专有信息。未经中兴通讯事先书面许可，任何单位和个人不得复制、传递、分发、使用和泄漏该文档以及该文档包含的任何图片、表格、数据及其他信息。

和是中兴通讯的注册商标。中兴通讯产品的名称和标志是中兴通讯的商标或注册商标。在本文档中提及的其他产品或公司名称可能是其各自所有者的商标或注册商标。在未经中兴通讯或第三方权利人事先书面同意的情况下，阅读本文档并不表示以默示、不可反言或其他方式授予阅读者任何使用本文档中出现的任何标记的权利。

本产品符合有关环境保护和人身安全方面的设计要求，产品的存放、使用和弃置应遵照产品手册、相关合同或相关国法律、法规的要求进行。

本文档按“现状”和“仅此状态”提供。本文档中的信息随着中兴通讯产品和技术的进步将不断更新，中兴通讯不再通知此类信息的更新。
中兴通讯股份有限公司
地址:
中国深圳市科技南路55号
邮编
518057
网站:

邮箱:
800@

版本更新说明

产品版本
资料版本
资料编号
资料更新说明
售后产品通用
1.0
-
模板第一次发布
售后产品通用
1.1

在1.0版本上的小范围修订
售后产品通用
2.0
-
在V1.1版本中进行了大的修订

作者
资料版本
日期
作者
审核者
批准者
1.0
2011-3-14
潘春锦
刘康康、姜冰心
-
1.1
2011-6-27
潘春锦
-
-
2.0
2013-07-23
张三喜

适用对象：LTE网优工程师

使用建议：在阅读本文档之前，建议先了解下面的知识和技能：
序号
知识技能
参考资料
1
LTE基本原理与关键技术
-
2
LTE网优基本技能
-

后继资料：在阅读完本文档之后，你可能需要下面资料：
序号
参考资料
资料说明
1
3GPP TS36.331
3GPP协议（RRC）
关于这篇文档
摘要
章节
描述
2 引言
介绍本文的目的。
3 基础知识
主要介绍掉话的基本概念、RRC连接释放流程、E-RAB释放流程、UE上下文释放流程、网管侧E-RAB掉话率定义及counter、终端侧掉话定义及统计等。
1 4 掉话原因分析
DT/CQT常见掉话原因分析
主要介绍DT/CQT厂家掉话原因分析、网管侧统计的掉话原因分类、CDT掉话原因码分类
Error! Reference source not found. 掉话问题分析流程及方法
主要介绍掉话分析的总体流程、无线侧掉话分析的基本流程、全局掉话率的TOP N分析、基站簇（小区）掉话率高的TOP N分析。
5 掉话优化案例
主要介绍了LTE常见的掉话案例。
附录A 参考资料
本文的参考文献。
目录
1 引言 1
2 基础知识 1
2.1 “连接”与“掉话”的概念 1
2.2 RRC连接释放流程 2
2.2.1 RRC CONNECTION RELEASE流程 2
2.2.2 RRC CONNECTION RELEASE消息内容 3
2.2.3 连接态下几种常见的RRC CONNCETION RELEASE触发场景 6
2.3 E-RAB释放流程 12
2.3.1 MME发起E-RAB释放 12
2.3.2 ENB发起的E-RAB释放 13
2.4 UE上下文释放流程 14
2.4.1 MME发起的UE上下文释放流程 14
2.4.2 ENB发起的UE上下文释放流程 15
2.5 网管侧E-RAB掉话率定义及相关COUNTER 16
2.5.1 网管侧掉话率KPI定义 16
2.5.2 网管侧统计的掉话率计算公式 16
2.5.3 网管侧E-RAB掉话率统计相关的COUNTER 16
2.6 终端侧掉话定义及统计 18
2.6.1 UE侧的RLF检测 18
2.6.2 CNA工具中掉话率的计算 19
2.6.3 路测掉话的几种常见类型 20
3 掉话原因分析 22
3.1 DT/CQT常见掉话原因分析 22
3.1.1 弱覆盖 22
3.1.2 切换失败 24
3.1.3 邻区漏配 26
3.1.4 越区覆盖 27
3.1.5 系统设备异常 29
3.1.6 干扰 30
3.1.7 拥塞 32
3.2 网管侧统计的掉话原因分类 34
3.2.1 网管侧E-RAB释放的采样点 34
3.2.2 网管侧统计的E-RAB异常释放COUNTER 34
3.3 信令流程中S1接口释放原因分类 36
3.4 CDT掉话原因码分类 40
3.4.1 释放原因分类 40
3.4.2 释放原因码分类 41
4 掉话问题的分析流程及方法 42
4.1 掉话分析总体流程 42
4.2 无线侧掉话分析的基本流程 43
4.3 全局掉话率高问题分析（TOP N） 43
4.4 小区（簇）掉话率高问题分析 44
5 掉话优化案例 46
5.1 弱覆盖导致的掉话 46
5.2 无主导小区导致的掉话 46
5.3 邻区漏配导致的掉话 48
5.4 切换失败导致的掉话 49
5.4.1 基站版本不支持异频切换导致的掉话 49
5.4.2 切换不及时导致的掉话 50
5.4.3 PCI复用距离不足导致的掉话 51
5.4.4 同一小区邻区中存在同频同PCI邻区导致的掉话 53
5.5 重配置失败导致的掉话 54
5.6 基站版本缺陷导致的掉话 56
5.7 无可用GTPU隧道导致的掉话 57
附录A 参考资料 60
A.1 附录A.1 《SJ-20121224143652-002-ZXSDR UNIRAN (V3.10.20) PERFORMANCE INDEX REFERENCE》 60
A.2 附录A.2 《SJ-20121224143652-001-ZXSDR UNIRAN (V3.10.20) PERFORMANCE COUNTER REFERENCE》 60
A.3 附录A.3 香港CSL项目网优工作报告 60
A.4 附录A.4 LTE技术规范 60
图目录
图 21 NAS和AS的几种状态 1
图 22 RRC连接释放流程 3
图 23 User Inactivity导致的RRC Connection Release信令流程图 7
图 24 连接态下非关机Detach发起的RRC Connection Release信令流程 11
图 25 重定向到GSM发起的RRC Connection Release流程图 12
图 26 MME发起的E-RAB释放流程 12
图 27 eNB发起的E-RAB释放流程 13
图 28 MME发起的UE Context释放流程 14
图 29 eNB发起的UE上下文释放流程 15
图 210 UE侧RLF相关定时器及计数器 19
图 211 RRC重建失败导致的掉话 21
图 212 空口信号变差等原因导致的掉话-重建信令不完整 21
图 213 其他原因导致的RRC重建立 22
图 31 弱覆盖导致的掉话图示 23
图 32 信令（由于切换失败导致的掉话） 24
图 33 邻区漏配导致的掉话示意图 26
图 34 越区覆盖造成导频污染、并导致掉话示意图 28
图 35 上行干扰导致掉话示意图 31
图 36 下行干扰导致掉话示意图 31
图 37 用于网管统计的E-RAB释放的相关采样点 34
图 41 掉话问题分析的总体流程图 42
图 42 无线侧掉话分析的基本流程图 43
图 51 由于弱覆盖导致的掉话 46
图 52 无主导小区导致的掉话 46
图 53 掉话点的网络拓扑结构 48
图 54 邻区漏配导致的掉话 49
图 55 系统不支持异频切换导致的掉话 50
图 56 切换不及时导致的掉话 51
图 57 PCI冲突示意图 51
图 58 PCI混淆示意图 52
图 59 PCI复用距离不足导致的掉话 52
图 510 重建原因值为handover Failure 53
图 511 13991基站-102小区邻区中存在两个同频同PCI邻区 54
图 512 重配置失败导致的掉话 55
图 513 基站版本缺陷导致的掉话 56
图 514 PCI 58小区没有正常下发邻区 57
图 515 CLA2-103小区掉话统计 57
图 516 核心网侧UE上下文释放原因分析 58
图 517 无线侧S1AP信令分析 59

2 引言
编写本文的目的：
1. 整理了与LTE FDD系统中与保持性（掉话）相关的基本概念、信令流程、所涉及的参数。
2. 指导LTE FDD网络维护、优化过程中，与掉话相关的问题分析和定位（解决）。
3 基础知识
& 知识点：
1、 掉话的定义
2、 掉话后UE、eNodeB的操作
3.1 “连接”与“掉话”的概念
本文所提及的“保持性”，指的是“连接”的“保持性”，更狭义地，是指“RRC连接”的“保持性”。因此，本文所称的“掉话”，具体是指UE异常退出RRC_CONNECTED状态导致的连接中断。
图 31 NAS和AS的几种状态

上图2-1给出了从开机到进入激活（数据传输）状态过程中，从不同角度来看的“状态”的变化情况
从EPS移动性管理（EMM）的角度来看，在UE成功附着之前，都认为是未登记（Deregistered）状态，直至UE发起、并成功登记。
对于EPS连接管理（ECM）来说，只有在激活态时，UE才会跟EPS是连接的，其余时间，UE处于和EPS的空闲状态。
对于RRC来说，只要UE和网络侧（空口、EPS）有连接，即为RRC的连接状态。
从ECM_Idle态转到ECM_Connected态，不仅涉及RRC连接建立、还涉及到S1连接建立。
RRC连接的建立由NAS发起、并先于S1连接建立完成。RRC_Connected态的连接仅限于UE和E-UTRAN的控制信息的交互。
RRC连接的释放由eNB发起、紧随S1连接释放之后。
本文所称的“连接”，通常指的是RRC_Connected状态下的连接。因受目前理解能力和OMC统计数据分析能力的限制，本文暂时只考虑上图中RRC_Connected状态（激活态）、暂不考虑附着过程中的连接状态。通常将在附着过程中发生的RRC连接中断归为“接入失败”进行分析；本文所分析的“掉话”、仅限于RRC_Connected状态下的连接异常中断。
& 知识点：掉话的定义
本文所称的“掉话”，具体是指UE异常退出RRC_CONNECTED状态导致的连接中断。
3.2 RRC连接释放流程
The purpose of this procedure is to release the RRC connection, which includes the release of the established radio bearers as well as all radio resources（RRC Connection Release流程的目的用于释放UE的RRC连接，包括已建立无线承载的和所有无线资源的释放）。
3.2.1 RRC Connection Release流程
在了解“掉话”之前，需要先了解一下RRC Connection Release流程及UE的Action。
3GPP TS 36.331第5.3.8小结介绍了RRC Connection Release流程如图2-2所示。
图 32 RRC连接释放流程

UE在接收到RRCConnectionRelease之后，应该：
1、 从收到RRCConnectionRelease（或者下层指示收到RRCConnectionRelease消息）起，将下列操作延迟60ms；
2、 如果RRCConnectionRelease消息中包含idleModeMobilityControlInfo，存储其中的小区重选优先级信息；如果消息中包含t320，启动该T320定时器（并将定时器取值为t320）；如果没有包含idleModeMobilityControlInfo，UE使用系统信息中广播的小区重选优先级信息。
3、 如果RRCConnectionRelease消息中的releaseCause为loadBalancingTAURequired，UE将在离开RRC_CONNECTED时执行操作，并带上releaseCause为loadBalancingTAURequired；如果releaseCause为other，则在离开RRC_CONNECTED时执行操作，并带上releaseCause为other。
UE在离开RRC_CONNECTED时执行的操作：
1、 重置MAC；
2、 停止除T320以外的所有定时器；
3、 释放全部无线资源，包括释放全部已建立的RB的RLC实体、MAC配置和相关的PDCP实体；
4、 告诉上层RRC连接释放（带上releaseCause）；
5、 如果不是由于收到MobilityFromEUTRACommand消息而触发的离开RRC_CONNECTED状态，UE将（根据离开RRC_CONNECTED的原因）通过执行小区重选过程进入RRC_IDLE，具体见TS36.304[4].
3.2.2 RRC Connection Release消息内容
协议3GPP TS 36.331 V9.3.0中对于RRCConnectionRelease消息内容如下：
RRCConnectionRelease message
-- ASN1START

RRCConnectionRelease ::= SEQUENCE {
rrc-TransactionIdentifier RRC-TransactionIdentifier,
criticalExtensions CHOICE {
c1 CHOICE {
rrcConnectionRelease-r8 RRCConnectionRelease-r8-IEs,
spare3 NULL, spare2 NULL, spare1 NULL
},
criticalExtensionsFuture SEQUENCE {}
}
}

RRCConnectionRelease-r8-IEs ::= SEQUENCE {
releaseCause ReleaseCause,
redirectedCarrierInfo RedirectedCarrierInfo OPTIONAL, -- Need ON
idleModeMobilityControlInfo IdleModeMobilityControlInfo OPTIONAL, -- Need OP
nonCriticalExtension RRCConnectionRelease-v890-IEs OPTIONAL
}

RRCConnectionRelease-v890-IEs ::= SEQUENCE {
lateR8NonCriticalExtension OCTET STRING OPTIONAL, -- Need OP
nonCriticalExtension RRCConnectionRelease-v920-IEs OPTIONAL
}

RRCConnectionRelease-v920-IEs ::= SEQUENCE {
cellInfoList-r9 CHOICE {
geran-r9 CellInfoListGERAN-r9,
utra-FDD-r9 CellInfoListUTRA-FDD-r9,
utra-TDD-r9 CellInfoListUTRA-TDD-r9,
...
} OPTIONAL, -- Cond Redirection
nonCriticalExtension SEQUENCE {} OPTIONAL -- Need OP
}

ReleaseCause ::= ENUMERATED {loadBalancingTAUrequired,
other,spare2,spare1}

RedirectedCarrierInfo ::= CHOICE {
eutra ARFCN-ValueEUTRA,
geran CarrierFreqsGERAN,
utra-FDD ARFCN-ValueUTRA,
utra-TDD ARFCN-ValueUTRA,
cdma2000-HRPD CarrierFreqCDMA2000,
cdma2000-1xRTT CarrierFreqCDMA2000,
...
}

IdleModeMobilityControlInfo ::= SEQUENCE {
freqPriorityListEUTRA FreqPriorityListEUTRA OPTIONAL, -- Need ON
freqPriorityListGERAN FreqsPriorityListGERAN OPTIONAL, -- Need ON
freqPriorityListUTRA-FDD FreqPriorityListUTRA-FDD OPTIONAL, -- Need ON
freqPriorityListUTRA-TDD FreqPriorityListUTRA-TDD OPTIONAL, -- Need ON
bandClassPriorityListHRPD BandClassPriorityListHRPD OPTIONAL, -- Need ON
bandClassPriorityList1XRTT BandClassPriorityList1XRTT OPTIONAL, -- Need ON
t320 ENUMERATED {
min5, min10, min20, min30, min60 min120, min180,
spare1} OPTIONAL, -- Need OR
...
}

FreqPriorityListEUTRA ::= SEQUENCE (SIZE (1..maxFreq)) OF FreqPriorityEUTRA

FreqPriorityEUTRA ::= SEQUENCE {
carrierFreq ARFCN-ValueEUTRA,
cellReselectionPriority CellReselectionPriority
}

FreqsPriorityListGERAN ::= SEQUENCE (SIZE (1..maxGNFG)) OF FreqsPriorityGERAN

FreqsPriorityGERAN ::= SEQUENCE {
carrierFreqs CarrierFreqsGERAN,
cellReselectionPriority CellReselectionPriority
}

FreqPriorityListUTRA-FDD ::= SEQUENCE (SIZE (1..maxUTRA-FDD-Carrier)) OF FreqPriorityUTRA-FDD

FreqPriorityUTRA-FDD ::= SEQUENCE {
carrierFreq ARFCN-ValueUTRA,
cellReselectionPriority CellReselectionPriority
}

FreqPriorityListUTRA-TDD ::= SEQUENCE (SIZE (1..maxUTRA-TDD-Carrier)) OF FreqPriorityUTRA-TDD

FreqPriorityUTRA-TDD ::= SEQUENCE {
carrierFreq ARFCN-ValueUTRA,
cellReselectionPriority CellReselectionPriority
}

BandClassPriorityListHRPD ::= SEQUENCE (SIZE (1..maxCDMA-BandClass)) OF BandClassPriorityHRPD

BandClassPriorityHRPD ::= SEQUENCE {
bandClass BandclassCDMA2000,
cellReselectionPriority CellReselectionPriority

}

BandClassPriorityList1XRTT ::= SEQUENCE (SIZE (1..maxCDMA-BandClass)) OF BandClassPriority1XRTT

BandClassPriority1XRTT ::= SEQUENCE {
bandClass BandclassCDMA2000,
cellReselectionPriority CellReselectionPriority
}

CellInfoListGERAN-r9 ::= SEQUENCE (SIZE (1..maxCellInfoGERAN-r9)) OF CellInfoGERAN-r9

CellInfoGERAN-r9 ::= SEQUENCE {
physCellId-r9 PhysCellIdGERAN,
carrierFreq-r9 CarrierFreqGERAN,
systemInformation-r9 SystemInfoListGERAN
}

CellInfoListUTRA-FDD-r9 ::= SEQUENCE (SIZE (1..maxCellInfoUTRA-r9)) OF CellInfoUTRA-FDD-r9

CellInfoUTRA-FDD-r9 ::= SEQUENCE {
physCellId-r9 PhysCellIdUTRA-FDD,
utra-BCCH-Container-r9 OCTET STRING
}

CellInfoListUTRA-TDD-r9 ::= SEQUENCE (SIZE (1..maxCellInfoUTRA-r9)) OF CellInfoUTRA-TDD-r9

CellInfoUTRA-TDD-r9 ::= SEQUENCE {
physCellId-r9 PhysCellIdUTRA-TDD,
utra-BCCH-Container-r9 OCTET STRING
}

-- ASN1STOP
从上面RRCConnectionRelease消息体可以看出，releaseCause只有两种取值，即loadBalancingTAURequired和other。
loadBalancingTAURequired主要用于MME的负荷均衡，当某个MME负荷过高，MME会在UE上下文释放消息中将此字段带给eNB，eNB给UE发RRC释放时也需要携带此字段。UE通过TAU，eNB为UE重新选择负荷轻的MME。
RRCConnectionRelease消息中的idleModeMobilityControlInfo字段，目前主要用于负荷均衡，例如本小区负荷过高，可以通过此字段，让UE释放后重选到负荷低的频点上。
3.2.3 连接态下几种常见的RRC Conncetion Release触发场景
通常情况下，以下情形会触发EUTRAN下发RRCConnectionRelease消息：
1、 UE发起Detach之后
2、 用户去激活（User Inactivity）
3、 重定向
4、 核心网触发loadBalancingTAURequired之后
5、 eNB负荷均衡
3.2.3.1 User Inactivity导致的RRC Connection Release

图 33 User Inactivity导致的RRC Connection Release信令流程图

说明：
1) 步骤1～5会建立RRC连接，步骤6、9会建立S1连接，完成这些过程即标志着NAS signaling connection建立完成，见24.301。
2) 消息7的说明：UE刚开机第一次attach，使用的IMSI，无Identity过程；后续，如果有有效的GUTI，使用GUTI attach，核心网才会发起Identity过程（为上下行直传消息）。
3) 消息10~12的说明：如果消息9带了UE Radio Capability IE，则eNB不会发送UECapabilityEnquiry消息给UE，即没有10~12过程；否则会发送，UE上报无线能力信息后，eNB再发UE Capability Info Indication，给核心网上报UE的无线能力信息。
Ø 为了减少空口开销，在IDLE下MME会保存UE Radio Capability信息，在INITIAL CONTEXT SETUP REQUEST消息会带给eNB，除非UE在执行attach或者"first TAU following GERAN/UTRAN Attach" or "UE radio capability update" TAU过程（也就是这些过程MME不会带UE Radio Capability信息给eNB，并会把本地保存的UE Radio Capability信息删除，eNB会问UE要能力信息，并报给MME。注："UE radio capability update" TAU is only supported for changes of GERAN and UTRAN radio capabilities in ECM-IDLE.）。
Ø 在CONNECTED下，eNB会一直保存UE Radio Capability信息。
Ø UE的E_UTRAN无线能力信息如果发生改变，需要先detach，再attach。
4) 发起UE上下文释放（即21～25）的条件：
Ø eNodeB-initiated with cause e.g. O&M Intervention, Unspecified Failure, User Inactivity, Repeated RRC signaling Integrity Check Failure, Release due to UE generated signaling connection release, etc.; or
Ø MME-initiated with cause e.g. authentication failure, detach, etc.
5) eNB收到msg3以后，DCM给USM配置SRB1，配置完后发送msg4给UE；eNB在发送RRCConnectionReconfiguration前，DCM先给USM配置DRB/SRB2等信息，配置完后发送RRCConnectionReconfiguration给UE，收到RRCConnectionReconfigurationComplete后，控制面再通知用户面资源可用。
6) 消息13~15的说明：eNB发送完消息13，并不需要等收到消息14，就直接发送消息15。
7) 如果发起IMSI attach时，UE的IMSI与另外一个UE的IMSI重复，并且其他UE已经attach，则核心网会释放先前的UE。如果IMSI中的MNC与核心网配置的不一致，则核心网会回复attach reject。
8) 消息9的说明：该消息为MME向eNB发起的初始上下文建立请求，请求eNB建立承载资源，同时带安全上下文，可能带用户无线能力、切换限制列表等参数。UE的安全能力参数是通过attach request消息带给核心网的，核心网再通过该消息送给eNB。UE的网络能力（安全能力）信息改变的话，需要发起TAU。
3.2.3.2 连接态下非关机Detach发起的RRC Connection Release
图 34 连接态下非关机Detach发起的RRC Connection Release信令流程

3.2.3.3 重定向发起的RRC Connection Release
这里以LTE->GSM的重定向流程为例，见图2-5。
图 35 重定向到GSM发起的RRC Connection Release流程图

3.3 E-RAB释放流程
3.3.1 MME发起E-RAB释放
场景描述：eNB收到MME的E-RAB RELEASE COMMAND消息（E-RAB IDs， AMBR），要求释放指定的E-RAB。
协议3GPP TS 36.413 v9.3.0对于MME发起的E-RAB释放流程见图2-6。
图 36 MME发起的E-RAB释放流程

3.3.2 eNB发起的E-RAB释放
场景触发：过载控制、用户面的错误指示（Error Indication）或者其他原因触发。对于Error Indication，如果错误指示的RB ID 不是SRB，并且当前的E-RAB数目大于1，则eNB发起E-RAB释放指示流程。
协议3GPP TS 36.413 v9.3.0对于eNB发起的E-RAB释放流程见图2-7。
图 37 eNB发起的E-RAB释放流程

协议36.314-930规定：The eNB initiates the procedure by sending an E-RAB RELEASE INDICATION message towards the MME. Upon reception of the E-RAB RELEASE INDICATION message the MME shall normally initiate the appropriate release procedure on the core network side for the E-RABs identified in the E-RAB RELEASE INDICATION message.（eNB通过E-RAB RELEASE INDICATION消息向MME发起此流程，MME接收到E-RAB RELEASE INDICATION消息后，会在核心网侧对指定的E-RABs发起相应的释放流程）。
目前我司网管统计中，与eNB发起的E-RAB释放相关的掉话counter有：
1、 C373210381：过载控制导致的E-RAB异常释放
2、 C373210391：其他原因导致的E-RAB异常释放
3、 C373210441：RLF导致的E-RAB异常释放（包括RLC达到最大重传次数、RRC重配消息或RRC连接重配置完成等消息定时器超时、SR达到最大发送次数）。
3.4 UE上下文释放流程
3.4.1 MME发起的UE上下文释放流程
eNB收到MME的UE CONTEXT RELEASE COMMAND消息触发UE上下文释放流程，用于释放UE的接入层上下文，释放UE的RRC连接和S1连接。
应用场景：UE和EPC的交互结束（Detach、MME的OMS发起的S1释放），MME过载导致的负载平衡发起的S1释放，S1切换完成释放源侧eNB的S1连接，S1切换取消释放目标侧S1连接，UE试图建立第二个S1逻辑连接时释放源S1连接，eNB发起上下文释放请求导致。
协议3GPP TS 36.413 v9.3.0中由MME发起的UE上下文释放流程见图2-8：
图 38 MME发起的UE Context释放流程

协议3GPP TS 36.413 v9.3.0规定：The purpose of the UE Context Release procedure is to enable the MME to order the release of the UE-associated logical connection due to various reasons, for example completion of a transaction between the UE and the EPC, or completion of successful handover, or completion of handover cancellation, or release of the old UE-associated logical S1-connection when two UE-associated logical S1-connections toward the same UE is detected after the UE has initiated the establishment of a new UE-associated logical S1-connection, or the UE is no longer allowed to access the CSG cell (i.e. the UE becomes a non-member of the currently used CSG cell). The procedure uses UE-associated S1 connection.
The MME provides the cause IE set to “Load Balancing TAU Required” in the UE CONTEXT RELEASE COMMAND message sent to the eNB for all load balancing and offload cases in the MME.
Upon