东莞割接MME后无线掉话率恶化问题V2.0解剖.docxVIP

东莞TAC割接后掉话恶化分析问题描述5.15日凌晨将TAC10250和TAC9822割接到新建的MME Pool后，无线掉话率恶化，不能恢复；5月26日对TAC9982和TAC9243进行割接，无线掉话率也恶化，不能恢复，MME为华为设备。前期初步分析第一批割接的10250和9822前期分析，TOP小区均是在POOL边界；掉话主因是UE LOST。深入详细分析由于第一批割接伴核心网DNS数据映射错误的切换问题，本报告重点以第二批割接TAC9982/9243掉话抬升为例进行分析。掉话原因第二批于5月26日凌晨割接，即5月29日核心网整改DNS（解决MME间TAU更新成功率问题）后进一步恶化。主因是 UE LOST增加。掉话TOP站分布经过分析，掉话增多并非整个TAC所有站均有所增多，掉话TOP站分布有一定关系，目前来看属于POOL边界：挑选新增掉话TOP站挑选条件：割接前每天掉话次数少于100次；割接后新增掉话次数排序，挑选TOP，确保目前跟到的掉话信令基本都是属于新增的掉话。掉话信令经过跟踪典型TOP站分析发现，新增的掉话信令具有明显的共性特征：均是S1切换到目标侧后在几百毫秒内掉话。典型信令如下：统计切换入的eNodeBID发现均是其他POOL的TAC切换入本TAC。信令深入分析：用户首先从东莞大新围站点Attach接入。通过wireshark解析分析发现给该用户分配的M-TMSI为:D71A1421切换到目标侧手机立马掉话，eNodeB 10秒不活动定时器超时释放 UE LOST。其实该UE切换到国龙工业区后立马掉话后，又立马重新在大新围站点Attach接入。从其携带的M-TMSI信息可以确认是同一个用户。但是UE切换到目标侧国龙工业区后，又立马掉话，原因为UE LOST。POOL边界：整个流程如下：该问题与已知问题相同掉话率恶化点出现TAC边界区，目前怀疑掉话是因为个别终端被核心网用#15 no suitable cells in tracking area拒绝，终端将该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会将当前TAI记入forbidden TA列表:24.301：（2）TA forbidden列表会在UE关机/USIM卡移除/UE内部维护的周期定时器（12~24小时间）超时后，才会清除掉24.301：（3）而后处于该forbidden TA边界区的UE可能接入到相邻的TAC小区中进行业务，但forbidden TAC的邻区信号在满足条件后，UE会在连接态切换到forbidden TAC的邻区，切换到目标邻区（UE在目标小区发送切换完成消息RRCConnectionReconfigurationComplete）后，搜索目标小区的SIB（含TAI信息）后，才发现该小区属于forbidden TA小区，所以，UE自行掉网离开了目标小区，导致目标小区掉话。协议规定UE是在切换完成后，才发起SIB消息捕获：36.331：5.3.5.4? Reception of an RRCConnectionReconfiguration including the mobilityControlInfo by the UE (handover)TAI信息是在SIB1消息中发送的：实验室验证被#15号原因值拒绝终端表现实验室构造模拟复现场景：源站：PCI=159，TAC=1目标站：PCI=158，TAC=5（TAC=5被构造成TAU失败以15号原因拒绝）成功复现出，终端被拒绝后的表现：只有158的信号时，被拒绝后终端被释放RRC连接后，无法入网，终端侧显示不停地在搜信号，最后显示无服务。从159切换入158时，网侧必现掉话，概率100%。禁止TAI列表终端被网络以15号原因拒绝后将TAI加入FTAI。并启动类似定时器，ds1=MM= Start 87, timeout 43200:0（43200s?/3600=12h?）。终端芯片公司对此的答复Created By: Onkar Upadhyay (2/11/2015 4:52 AM)Dear Customer, I will answer about the