东莞割接MME后无线掉话率恶化问题分析V20

1、文档名称文档密级东莞TAC割接后掉话恶化分析1 问题描述5.15日凌晨将TAC10250和TAC9822割接到新建的MME Pool后，无线掉话率恶化，不能恢复；5月26日对TAC9982和TAC9243进行割接，无线掉话率也恶化，不能恢复，MME为华为设备。2 前期初步分析第一批割接的10250和9822前期分析，TOP小区均是在POOL边界；掉话主因是UE LOST。3 深入详细分析由于第一批割接伴核心网DNS数据映射错误的切换问题，本报告重点以第二批割接TAC9982/9243掉话抬升为例进行分析。3.1 掉话原因第二批于5月26日凌晨割接，即5月29日核心网整改DNS（解决MME间TA

2、U更新成功率问题）后进一步恶化。主因是 UE LOST增加。3.2 掉话TOP站分布经过分析，掉话增多并非整个TAC所有站均有所增多，掉话TOP站分布有一定关系，目前来看属于POOL边界：3.3 挑选新增掉话TOP站挑选条件：l 割接前每天掉话次数少于100次；l 割接后新增掉话次数排序，挑选TOP，确保目前跟到的掉话信令基本都是属于新增的掉话。3.4 掉话信令经过跟踪典型TOP站分析发现，新增的掉话信令具有明显的共性特征：均是S1切换到目标侧后在几百毫秒内掉话。典型信令如下：统计切换入的eNodeBID发现均是其他POOL的TAC切换入本TAC。信令深入分析：用户首先从东莞大新围站点Atta

3、ch接入。通过wireshark解析分析发现给该用户分配的M-TMSI为:D71A1421切换到目标侧手机立马掉话，eNodeB 10秒不活动定时器超时释放 UE LOST。其实该UE切换到国龙工业区后立马掉话后，又立马重新在大新围站点Attach接入。从其携带的M-TMSI信息可以确认是同一个用户。但是UE切换到目标侧国龙工业区后，又立马掉话，原因为UE LOST。POOL边界：整个流程如下：3.5 该问题与已知问题相同掉话率恶化点出现TAC边界区，目前怀疑掉话是因为个别终端被核心网用#15 "no suitable cells in tracking area"拒绝，终

4、端将该TAC记录在forbidden tracking areas for roaming列表中，导致终端后续连接态切换到forbidden TAC区域内的小区后UE自动掉话。针对该怀疑点的理论分析及协议原理摘录如下：（1）终端在发起Initial NAS流程（TAU/Attach/Service request）时，MME可能因为网络侧异常（如：宜昌出现的DRA改造异常，导致MME与HSS间diameter消息交互异常；或者核心网改造恢复过程中时序配合问题等）这里就不要了吧，而发送携带#15原因值的TAU reject/Attach reject/Service reject，此时UE会将当

5、前TAI记入forbidden TA列表:24.301：（2）TA forbidden列表会在UE关机/USIM卡移除/UE内部维护的周期定时器（1224小时间）超时后，才会清除掉24.301：（3）而后处于该forbidden TA边界区的UE可能接入到相邻的TAC小区中进行业务，但forbidden TAC的邻区信号在满足条件后，UE会在连接态切换到forbidden TAC的邻区，切换到目标邻区（UE在目标小区发送切换完成消息RRCConnectionReconfigurationComplete）后，搜索目标小区的SIB（含TAI信息）后，才发现该小区属于forbidden TA小区，

6、所以，UE自行掉网离开了目标小区，导致目标小区掉话。协议规定UE是在切换完成后，才发起SIB消息捕获：36.331：5.3.5.4  Reception of an RRCConnectionReconfiguration including the mobilityControlInfo by the UE (handover)TAI信息是在SIB1消息中发送的：3.6 实验室验证被#15号原因值拒绝终端表现实验室构造模拟复现场景：源站：PCI=159，TAC=1目标站：PCI=158，TAC=5（TAC=5被构造成TAU失败以15号原因拒绝）成功复现出，终端被拒绝后的表现：1)

7、只有158的信号时，被拒绝后终端被释放RRC连接后，无法入网，终端侧显示不停地在搜信号，最后显示无服务。2) 从159切换入158时，网侧必现掉话，概率100%。3.7 禁止TAI列表l 终端被网络以15号原因拒绝后将TAI加入FTAI。l 并启动类似定时器，ds1=MM= Start 87, timeout 43200:0（43200s?/3600=12h?）。3.8 终端芯片公司对此的答复Created By: Onkar Upadhyay (2/11/2015 4:52 AM)Dear Customer, I will answer about the NAS related print

8、s. You understanding is correct. This is timer : EMM_FORBIDDEN_TAI_CLEAR_TIMER This is set for 12 hr in and it is in accordance with NAS 3GPP specification 24.301 = 5.3.2 Lists of forbidden tracking areas The UE shall store a list of "forbidden tracking areas for roaming", as well as a lis

9、t of "forbidden tracking areas for regional provision of service". These lists shall be erased when the UE is switched off or when the UICC containing the USIM is removed, and periodically (with a period in the range 12 to 24 hours). = Regards, Onkar nath3.9 被拒绝后空闲态重新搜网的表现l 终端被网侧以15号原因拒绝，并

10、释放RRC连接进入空闲态。l 终端将被拒绝的TAC加入到FTAI“禁止TAI列表”。l 终端重新搜网，PSS/SSS同步发现，又搜到该小区，还是这个TAC的PCI。l 读取SIB1后发现该PCI的TAC在FTAI“禁止TAI列表”里面，于是将该PCI加入黑名单。l 随后再次同步时，就不再主动搜索该PCI小区信息。3.10 被拒绝后从其他TAC切换入的表现l 终端正常切换，切换的非竞争的随机接入过程正常，MSG1/2/3正常。l 随后开始读取系统消息，MSG3过了20ms后就读取到SIB1。l 读取SIB1后发现该小区的TAC在FTAI“禁止的TAI列表”里面，于是终端释放RRC连接。l 释放R

11、RC连接后终端重新进入搜网ACQ流程，随后的流程同空闲态重新搜网过程一样。3.11 FTAI“禁止TAI列表“的影响总结实验室验证，终端只要被核心网以121315号原因拒绝过一次，终端就将该TAC加入FTAI，时长为43200s即12个小时（其他的终端可能时长不一样，协议规定12小时24小时）。l 此时终端12个小时内一直处于该TAC内，未做移动，那么终端将不再搜索4G网络，无法在4G网络空闲态驻留、以及建立连接，除非插拔USIM卡、或者重启手机才能恢复。l 此时终端从其他TAC正常接入，切换到被拒绝过的TAC小区时，能够正常完成切换流程，但随后几十或几百毫秒（取决于搜索SIB1的快慢）内，U

12、E自行释放RRC连接，重新搜网，此时必然造成无线网侧链路异常；造成无线侧掉话，掉话原因为UE LOST。3.12 东莞核心网#15号原因值拒绝在割接后突增核对核心网的TAU拒绝指标，在割接后出现#15号原因值突增。区分MME来看104/304/305/306在26日（割接）TAU #15有突增，101/102/201/202在5月28日（DNS调整），6月5日有突增。整体来看，东莞所有MME#15号原因值在在割接后呈增加趋势，特别是在28日后突增近2w次。按时间点统计，104/304/305/306在5月26日凌晨突增，跟MME跟割接强相关。按时间点统计，101/102/201/202在5月2

13、8日凌晨之后变多，跟MME的DNS调整强相关。3.13 找异常TOP终端POOL边界只要存在这种被#15拒绝过的用户，就无法避免这个问题。一定会造成无线侧掉话。要把终端找出来，把拒绝的找出来，看是否正常，以及怎么规避。3.13.1 无线核心网联合抓取信令CHR6月11日联合核心网一起抓取异常终端信息：核心网侧：开启时间：14:30-16:00核心网侧打开POO3，MMEGID：0369的MME的正常呼叫的CHR开关。无线侧跟踪：跟踪时间：14:40-15:40目标站：东莞国龙工业区F-HLH-2只跟踪S1，勾选去掉PAGE消息。源站：只跟踪S1和UU信令，勾选去掉PAGE消息3.13.2 PO

14、OL3反复attach，反复切换入POOL5掉话昨天无线侧拼接了不到一分钟的信令，一个用户反复切换到 国龙工业区POO5  不到一分钟的时间里掉话6次，又反复重新attach到源站 东莞李屋 POOL3。已从核心网CHR找到该用户信息：核心网侧对应CHR：3.13.3 POOL5历史CHR显示的确被TAC9243以#15拒绝该终端的确被POOL5的国龙工业区所在TAC：9243被#15TAU拒绝过：6月11日凌晨2:47被MME304以#15拒绝TAC9243的TAU：6月11日中午15:15被MME306以#15拒绝TAC9243的TAU：3.14 核心网TAU#15拒绝分析根据C

15、HR打点信息分析，这个场景是由于TAU新侧在做安全流程时，收到HSS发来的Cancel Location。正常信令消息如下图：冲突场景，在第6步收到第14步的消息。也就是说，该MME作为前一次TAU的老侧，收到HSS的Cancel Location，但实际上，用户此时已经TAU切换回来，正在作为新侧进行安全流程。4 问题根因4.1 无线侧掉话根因POOL边界存在TAU被#15小区不可用 拒绝一次的用户，该用户会将该TAC记录在自身的FTAI（禁止接入TAC列表）中，在不插拔卡/不重启的之后12-24小时，该用户无法接入该TAC，且从可接入的TAC连接态切换至被拒绝的该TAC，切换流程走完后，搜

16、索SIB1，发现当前所处TAC属于FTAI列表中，自行释放空口RRC链路重新搜网，不通知网络侧，必然造成无线侧UE lost掉话。4.2 核心网POOL边界#15根因由于POOL边界频繁切换，TAU流程和Cancel Location冲突，导致MME下发#15。4.3 问题根因POOL边界，无线侧的连续乒乓跨POOL切换，引起MME的TAU鉴权流程与HSS的Cancel Location流程冲突， MME下发#15号原因值拒绝新的TAU流程，导致：l 用户12-24个小时内无法在该TAC接入，影响用户正常进行4G业务。l 从其他TAC连接态切换入该TAC会立即掉话，影响无线侧掉话率。5 规避措

17、施5.1 临时规避措施优化POOL边界的跨POOL切换的小区无线参数，避免乒乓切换，减少冲突的概率，但无法保证完全规避。5.2 根本解决措施核心网对这种流程冲突的错误改写原因值，不能以12/13/15号原因值拒绝，以普通原因值拒绝。6 相关FAQ6.1 MME POOL间/内切换差异POOL内切换，eNB走X2，切换前后MME不会改变。POOL间切换，eNB走S1，切换前后MME改变。6.2 eNB如何判断是否跨POOL切换eNB会通过X2口识别周边的eNB所连接的MME GID信息。如果切换源站与目标站X2链路正常，MMEGID相同判定走X2。6.3 MME POOL改造期间MMEGID相同

18、，但是MME并未组POOL怎么切换？l eNB只根据MMEGID来识别是否组POOL，处于工程态的MME组POOL期间，eNB无法识别是否“真正”的组POOL；依然会走X2切换。l 此时X2切换会切换准备失败，只有当目标侧返回准备失败原因值为 Unknown MME CODE或Unknow MME GID时，源站eNB会再次发起补救流程，尝试再走一次S1切换。l 当然eNB不会记录这种状态，例如，UE1先走X2失败后走S1切换，UE2依然会优先走X2，继续失败，再走S1.6.4 现网中本身就存在大量的#15，UE被#15后处在POOL内TAL边界切换，会掉话吗？对用户来说，肯定会掉话。对eNB来说，此时UE切换到目标侧掉话后，立马重新Attach到源侧，因为目标侧与源侧的MME相同，同一个MME对一个用户只会保存一个上下文，MME会给目标侧eNB下发Normal rel释放掉老的上下文。此过程只要不超过无线侧的10秒不活动定时器，无线侧就不会记录为掉话，如果这个时间超过10秒，无线侧依然会记为掉话。6.5 现网中本身就存在大量的#15，UE被#15后处在POOL间T