TAC多定义导致切换失败案例
VOLTE异常事件典型案例分析
异常事件典型案例分析未接通对第四轮测试数据进行分析发现未接通常见案例如下：未接通原因分类求和项:统计次数测试软件问题 6被叫振铃未接听 2测试设备断链 4端到端问题 4TAU与QCI建立流程冲突 1TCP链路问题 1切换与QCI1建立流程冲突 1终端在2G侧无响应 1核心网问题 5TAU与切换流程冲突导致TAU失败 4同一个MME下NAS消息sequence number不连续导致承载未建立 1其他原因 3人为挂断 3终端问题 2跨TAC但未发TAU导致服务拒绝 2总计201、测试软件问题（1）11月25日网格8 被叫振铃未接听主叫号码：136******** 被叫号码：136********（Time: 13:57:00.354，Latitude: 39.92886，Lontitude: 116.52397）13:56:25.184主叫占用朝阳平房乡政府南公园西北HLG-3发起呼叫，RSRP -78 dBm，SINR 17dB，无线环境良好，13:56:27.776主叫收到网络侧转发的被叫的invite 180后，由于被叫一直没有摘机导致在13:56:47.988被叫主动挂机上报invite 603，携带原因为decline，主叫判断为未接通，被叫判断为掉话。
此处属于测试软件问题，应该予以剔除。
（2）11月19日网格55 测试设备断链主叫号码：136******** 被叫号码：136********(Time: 12:57:39.940,Latitude: 39.86454,Lontitude: 116.43406) 12:57:30.631主叫占用丰台左安门桥南HLG-5发起呼叫，RSRP -99 dBm，SINR 6dB 空口良好，由于被叫终端设备断链导致未接通，应该予以剔除。
2、端到端问题（1）11月16日网格67 QCI1与TAU流程冲突主叫号码：136******** 被叫号码：136********（Time: 13:13:21.299，Latitude: 39.92329，Lontitude: 116.41997）13:13:11.358主叫占用东城语文出版社HL-1发起呼叫，被叫于13:13:13.870上发invite 183之后，开始建立QCI1承载，UL information transfer还没有上发时发起TAU，流程冲突导致被叫主动上发invite 580，属于端到端问题，需要集团规范协议流程。
VOLTE掉话分析
TOP筛选条件◆当日掉话次数大于3次为TOP小区◆一周内出现3次TOP小区为高掉话TOP小区TOP分析方法手段掉话问题掉话原因分析➢按照掉话分子，按原因值提取相关计数器进行分析；➢检查站点是否存在邻区漏配或者配置不合理，导致无法及时切换出而吊死，引发掉线；➢小区存在异频邻区时，需要核查异频切换类相关A2、A3配置门限是否合理；➢检查小区是否存在超远覆盖，导致覆盖孤岛，无法及时切换到周边基站，可通过后台信令跟踪，观察测量报告，补齐漏配的邻区，随后及时对覆盖进行控制；➢对于弱覆盖引起的掉线，若终端处于覆盖边缘，周围无可用LTE小区，可以合理添加异系统邻区，合理配置重定门限，及时重定向到异系统，减少掉线。
➢关注小区无线环境，分析是否NI过高；➢关注影响业务的故障类告警；掉话Context归类如下：●ENB由于S1链路故障发起释放分为三类◆Context释放，Gtpu ErrInd触发释放：主要是核心网参数问题，部分原因是TAC边界不和导致，可以优化TAC边界◆Context释放，Path故障触发释放：传输故障导致，需核查传输◆Context释放，光口故障触发释放：光口、S1链路故障等原因，推维护处理●Context释放，ENB切换失败引发释放：检查切换参数、功率参数、定时器设置；●Context释放，由于小区关断或复位引发释放：检查掉线对应时间段内基站小区故障类告警●Context释放，ENB由于其他原因引发释放：容量等其他问题；●Context释放，ENB重建立失败导致释放：检查小区NI是否过高，RS功率设置是否偏小，检查现场无线环境，开启X2口进行优化（重建立如果在目标基站没有上下文，重建肯定失败）；●ENB空口失败引发释放次数分四类◆ERAB释放，空口定时器超时：检查CPU负荷，同时在线用户数是否偏高，如是可增加SR信道配置容量进行优化，排除MR开启时间段内计时器增多，提故障交研发处理；◆ERAB释放，空口质量差触发RLF：检查无线环境是否存在弱覆盖、模三干扰、越区覆盖、底噪偏高、基站存在故障；◆ERAB释放和RLC达到最大重传次数：检查RLC参数设置，排除MR开启时间段内计时器增多，提故障交研发处理；◆ERAB释放，PDCP完整性保护失败：检查加密完保参数设置，排除MR开启时间段内计时器增多，提故障交研发处理；Context整理情况如下：切换问题：切换分为切换准备阶段和切换执行阶段切换准备阶段多由外部邻区参数配置错误（邻区配置正确）或者切换准备目标基站故障引起。
LTE切换问题分析
1相关Counter介绍1.1 切换相关KPI公式（L.HHO.IntraeNB.IntraFreq.ExecSuccOut+L.HHO.IntraeNB.InterFreq.ExecSuccOut- L.HHO.IntraeNB.IntraFreq.Succ.ReEst2Src-L.HHO.IntraeNB.InterFreq.Succ.ReEst2Src)/(L.HHO.IntraeNB.IntraFreq.PrepAttOut+L.HHO.IntraeNB.InterFreq.PrepAttOut)*100% ✧eNB间切换出成功率（L.HHO.IntereNB.IntraFreq.ExecSuccOut+L.HHO.IntereNB.InterFreq.ExecSuccOut- L.HHO.IntereNB.IntraFreq.Succ.ReEst2Src-L.HHO.IntereNB.InterFreq.Succ.ReEst2Src)/(L.HHO.IntereNB.IntraFreq.PrepAttOut+L.HHO.IntereNB.InterFreq.PrepAttOut)*100% ✧同频切换出成功率（L.HHO.IntereNB.IntraFreq.ExecSuccOut+L.HHO.IntraeNB.IntraFreq.ExecSuccOut- L.HHO.IntereNB.IntraFreq.Succ.ReEst2Src-L.HHO.IntraeNB.IntraFreq.Succ.ReEst2Src)/(L.HHO.IntereNB.IntraFreq.PrepAttOut+L.HHO.IntraeNB.IntraFreq.PrepAttOut)*100% ✧异频切换出成功率（L.HHO.IntereNB.InterFreq.ExecSuccOut+L.HHO.IntraeNB.InterFreq.ExecSuccOut- L.HHO.IntereNB.InterFreq.Succ.ReEst2Src-L.HHO.IntraeNB.InterFreq.Succ.ReEst2Src)/(L.HHO.IntereNB.InterFreq.PrepAttOut+L.HHO.IntraeNB.InterFreq.PrepAttOut)*100% ✧切换出成功率（L.HHO.IntereNB.IntraFreq.ExecSuccOut+L.HHO.IntereNB.InterFreq.ExecSuccOut+ L.HHO.IntraeNB.IntraFreq.ExecSuccOut+L.HHO.IntraeNB.InterFreq.ExecSuccOut-L.HHO.IntereNB.IntraFreq.Succ.ReEst2Src-L.HHO.IntereNB.InterFreq.Succ.ReEst2Src-L.HHO.IntraeNB.IntraFreq.Succ.ReEst2Src-L.HHO.IntraeNB.InterFreq.Succ.ReEst2Src)/(L.HHO.IntereNB.IntraFreq.PrepAttOut+L.HHO.IntereNB.InterFreq.PrepAttOut+L.HHO.IntraeNB.IntraFreq.PrepAttOut+L.HHO.IntraeNB.InterFreq.PrepAttOut)*100% 1.2 Counter解释Counter解释：✧切换成功率Counter✧切换失败counter原因：1.3 Counter计数位置及说明1.3.1站内切换图（2）1.3.2 X2切换图（3）2.3.3 S1切换图（4）注明：尝试切换Counter都计数在A点位置，准备切换Counter都计数在B点位置，切换成功Counter都计数在C点位置1.3.4 切换失败Counter说明图（5）a). 在S1接口切换及X2接口切换过程中的切换准备阶段，源小区收到来自MME的UE CONTEXT RELEASE COMMAND消息时，如果切换过程中源小区和目标小区为同频或异频，指标L.HHO.Prep.FailOut.MME加1。
切换成功率问题分析总结
切换成功率问题分析总结概述在分析处理日常性能质差小区时，发现切换成功率低的问题小区占据绝大部分，统计诺基亚区域2016年一、二月份EMOS平台性能小区问题类型占比情况，切换成功率低的小区占比高达88.94%，需重点分析总结原因。
诺基亚区域EMOS平台性能小区问题类型统计（一、二月份汇总）指标定义切换成功率<90%且切换失败次数>300。
相关counter切换按切换前后的eNodeB是否相同，可分为eNodeB内切换和eNodeB间切换。
eNodeB间切换:按切换走的路由来分:又可分为S1切换和x2切换。
同样的，切换按切换前后两个小区的频点是否相同,又可分为同频切换和异频切换。
注意的是:同一个站下不同的小区的频点是可以不同的,两个小区为39250,另一个小区为38950。
也就是说:目前eNodeB内的切换又一定是同频切换，问题在于研发在切换准备阶段没有区分同频和异频两种方式,在切换执行阶段区分了，所以要区分切换准备阶段的同频或异频情况,只能取邻区级的切换统计。
eNodeB间的x2切换:x2切换准备请求次数: INTER_ENB_HO_PREP（M8014C0）x2切换准备成功次数: ATT_INTER_ENB_HO（M8014C6）(也是x2切换执行请求次数) x2切换准备失败次数: INTER_ENB_HO_PREP - ATT_INTER_ENB_HOx2切换执行请求次数: ATT_INTER_ENB_HO（M8014C6）x2切换执行成功次数: SUCC_INTER_ENB_HO（M8014C7）x2切换执行失败次数: ATT_INTER_ENB_HO - SUCC_INTER_ENB_HOx2切换准备成功率: ATT_INTER_ENB_HO / INTER_ENB_HO_PREP * 100%x2切换执行成功率: SUCC_INTER_ENB_HO / ATT_INTER_ENB_HO * 100%x2切换总成功率: SUCC_INTER_ENB_HO / INTER_ENB_HO_PREP * 100%eNodeB间的S1切换:S1切换准备请求次数: INTER_ENB_S1_HO_PREP（M8014C14）S1切换准备成功次数: INTER_ENB_S1_HO_ATT（M8014C18）(也是S1切换执行请求次数) S1切换准备失败次数: INTER_ENB_S1_HO_PREP - INTER_ENB_S1_HO_ATTS1切换执行请求次数: INTER_ENB_S1_HO_ATT（M8014C18）S1切换执行成功次数: INTER_ENB_S1_HO_SUCC（M8014C19）S1切换执行失败次数: ATT_INTER_ENB_S1_HO - INTER_ENB_S1_HO_SUCCS1切换准备成功率: INTER_ENB_S1_HO_ATT / INTER_ENB_S1_HO_PREP * 100%S1切换执行成功率: INTER_ENB_S1_HO_SUCC / INTER_ENB_S1_HO_ATT * 100%S1切换总成功率: INTER_ENB_S1_HO_SUCC / INTER_ENB_S1_HO_PREP * 100%eNodeB间的切换总成功率: (X2切换+S1切换)eNodeB间的切换总成功率=(x2切换执行成功+S1切换执行成功)/(x2切换准备请求+S1切换准备请求)= (SUCC_INTER_ENB_HO+ INTER_ENB_S1_HO_SUCC) /(INTER_ENB_HO_PREP + INTER_ENB_S1_HO_PREP) *100%eNodeB内的切换:(定义了切换准备和切换执行)eNodeB内的切换准备请求次数: INTRA_ENB_HO_PREP（M8009C2）eNodeB内的切换准备成功次数: ATT_INTRA_ENB_HO（M8009C6）(也是eNodeB内切换执行请求次数)eNodeB内的切换准备失败次数: INTRA_ENB_HO_PREP - ATT_INTRA_ENB_HOeNodeB内的切换执行请求次数: ATT_INTRA_ENB_HO（M8009C6）eNodeB内的切换执行成功次数: SUCC_INTRA_ENB_HO（M8009C7）eNodeB内的切换执行失败次数: ATT_INTRA_ENB_HO - SUCC_INTRA_ENB_HOeNodeB内的切换准备成功率: ATT_INTRA_ENB_HO/ INTRA_ENB_HO_PREP * 100%eNodeB内的切换执行成功率: SUCC_INTRA_ENB_HO/ATT_INTRA_ENB_HO * 100%eNodeB内的切换总成功率: SUCC_INTRA_ENB_HO/INTRA_ENB_HO_PREP * 100%总切换成功率:由于目前NSN在全国各省算总切换成功率时,不考虑eNodeB内切换的准备过程,eNodeB间切换+eNodeB内切换=x2+S1+eNodeB内切换即总的切换成功率=(x2切换执行成功+S1切换执行成功+eNodeB切换执行成功)/(x2切换准备请求+S1切换准备请求+eNodeB内的切换准备请求)即= (SUCC_INTER_ENB_HO+ INTER_ENB_S1_HO_SUCC + SUCC_INTRA_ENB_HO) / (INTER_ENB_HO_PREP + INTER_ENB_S1_HO_PREP +ATT_INTRA_ENB_HO ) *100%注意分母中是: ATT_INTRA_ENB_HO,而不是INTRA_ENB_HO_PREP（同频和异频的分类只在切换执行中区分,在切换准备中未区分）异频切换执行:异频切换执行请求次数:HO_INTFREQ_ATT（M8021C0）异频切换执行成功次数:HO_INTFREQ_SUCC（M8021C2）异频切换执行失败次数:HO_INTFREQ_ATT- HO_INTFREQ_SUCC异频切换执行成功率:HO_INTFREQ_SUCC / HO_INTFREQ_ATT * 100%同频切换执行:注意:由于没有专门定义同频执行切换的Counter,因此只能用总切换执行次数-异频切换执行次数同频切换执行请求次数:x2切换执行请求+ S1切换执行请求- 异频切换执行请求=INTER_ENB_S1_HO_ATT + ATT_INTER_ENB_HO - HO_INTFREQ_ATT 同频切换执行成功次数:x2切换执行成功 + S1切换执行成功 - 异频切换执行成功 =INTER_ENB_S1_HO_SUCC + SUCC_INTER_ENB_HO - HO_INTFREQ_SUCC同频切换执行成功率:=( INTER_ENB_S1_HO_SUCC + SUCC_INTER_ENB_HO - HO_INTFREQ_SUCC) /(INTER_ENB_S1_HO_ATT + ATT_INTER_ENB_HO - HO_INTFREQ_ATT) / * 100%切换问题主要原因造成小区切换成功率低的因素主要有下面几种：基站（小区）故障告警导致，服务小区及邻小区存在故障，需工程排障处理；干扰导致：是否存在内部干扰（GSP失步）、外部干扰；邻区合理性，是否存在邻区漏配、添加过远邻区，邻区是否存在同频同PCI问题及PCI混淆、是否添加小区切换黑名单等情况；参数设置不合理导致：包含小区基本参数如TAC、切换参数如CIO等、MME核查是否有漏配、ppsTimingOffset参数核查；邻区拥塞导致：目标小区出现拥塞，会导致周边站点出现大量的切换失败；隐性故障：隐性故障休眠，小区会出现无法接入，周边站点切换全部失败的情况。
NR基站TAC配置与核心网配置不一致导致无法上网案例
NR基站TAC配置与核心网配置不一致导致无法上网案例
【问题描述】
SA场景，现场测试中发现占用惠州龙湖大道-HRH信号，信号质量良好，RSRP-72dBm，SINR16dB，有信号但是不能正常上网。
【问题分析】
查询站点无影响业务的故障告警，小区状态正常，经排查基站使用的是支持SA功能的20B版本，终端也是最新版本，排除版本问题。
从信令上分析，终端随机接入成功，已经接入5G网络，无法上网原因是由于PDU会话建立失败，终端收到基站侧下发：PDUSessionEstablishmentReject。
PDU建立主要是终端与核心网的信令交互，从流程上分析与基站侧关系不大。
（注：5GC支持PDU连接业务，PDU连接业务就是UE和DN之间交换PDU数据包的业务；PDU连接业务通过UE发起PDU会话的建立来实现。
一个PDU会话建立后，也就建立了一条UE和DN的数据传输通道）
仔细核查数据配置，发现基站侧TAC9833核心网侧TAC 1331226 TAC不一致，经过核对发现对SA的TAC理解错了。
根据集团规范5GNSA组网时45G配置一致的4位数TAC。
SA组网时TAC按区规划配置，一般为7位数的TAC。
【问题结论】
基站侧TAC9833核心网侧TAC 1331226 TAC不一致
【解决措施】
联系基站侧开站人员对其TAC进行更改，与核心网保持一致后，问题解决。
【效果验证】
基站侧TAC更改与核心网保持一致后，测试能够正常上网。
【推广建议】
对新开站点无法接入，需先对基础参数进行核对，避免出现错配置问题。
LTE优化案例--高铁测试TAC更新失败优化案例
高铁测试TAC更新失败优化案例1、【现象描述】2、【原理分析】TA（跟踪区）是LTE系统为UE的位置管理新设立的概念。
当UE处于空闲状态时，核心网能够知道UE所在的跟踪区，同时处于空闲状态的UE需要被寻呼时，必须在UE所注册的跟踪区的所有小区进行寻呼。
当UE移动发生TA改变时，终端需要向核心网发起跟踪区更新。
一个TA list含有1-16个TA,UE在TA list内移动时不需要执行TA list更新，TA list的引入可以避免在TA边界由于乒乓切换导致频繁TA更新。
跟踪区（TA）规划应遵循以下原则：1）跟踪区划分应利用移动用户的地理分布和行为进行区域划分，减少跟踪区边缘位置更新。
跟踪区边界划分不宜以街道为界，不宜放在话务量较高的地方；跟踪区边界不宜与街道平行或垂直；在市区和城郊交界区域，宜将跟踪区的边界放在外围一线的基站处，而不宜放在话务密集的城郊结合部。
2）跟踪区划分应满足小区寻呼信道的容量要求并适当预留，跟踪区不宜跨越MME区域。
3）需要开通CSFB的区域跟踪区宜与2/3G LAC保持一致。
4）针对高速移动等跟踪区频繁变更的场景，可以通过TA List功能降低跟踪区更新的负荷。
一般来说，TAU发生的场景主要有以下几种：1. 注册状态下TA发生改变（重选或切换之后，新驻留基站的TAC不在原TAL内）；2. 周期TAU定时器T3412超时；3. 注册状态下覆盖区丢失后UE本地EPS承载去激活，重新进入覆盖区；4. UE网络能力参数或DRX参数发生改变时；5. 发生异系统重选，没有缓存用户面数据；6. RRC连接释放原因为：需要加载TAU流程。
3、【处理过程】本次测试的终端型号华为E3292，在其他区域测试时均正常，因此可以排除终端故障的问题。
而干扰会令周边站点的底噪普遍提高，在基站性能指标中并没有发现底噪明显提高的问题，因此干扰问题也可以排除。
综合全路段分析发现，TAC更新失败，多数伴随小区切换失败、重建失败发生，结合TAC更新请求发生场景分析，可分析高铁TAU产生原因有两条：1.注册状态下TA发生改变2.注册状态下覆盖区丢失后UE本地EPS承载去激活，重新进入覆盖区结合这两种情况，我们选取2个较为明显场景详细分析。
POOL边界TAC和LAC不一致导致无法接通案例
POOL边界TAC和LAC不一致导致未接通CSFB业务流程主要包括联合附着、位置更新、主叫(MO)CSFB流程、被叫(MT)CSFB 流程以及去附着等。
启用CSFB功能的用户的附着流程是基于联合GPRS/IMSI附着流程来实现的。
空闲态小区重选：用户挂机后在GSM网络驻留，根据GSM广播消息中的LTE邻区信息执行重选，返回高优先级LTE网络。
重选返回过程中，将引入不可及时间，可能影响用户体验。
网络控制Fast Return方案：用户挂机时，2G网络在释放用户信道的同时下发LTE 邻小区频点，终端按网络指示测量并接入LTE小区，可在通话过程中测量LTE邻区或在挂机后测量LTE邻区。
终端自主Fast Return返回：用户挂机时，终端自主搜索预存的或者通话过程中测量的LTE频点返回。
POOL边界问题•MSC 采用POOL组网，UE在POOL内一个MSC上登记后，正常情况下POOL覆盖范围内所有服务均由此MSC提供•联合位置更新时，MME通过TA -LA -MSC的映射，为UE指定一个SGs MSC •在MT呼叫流程中，如果UE回落后的LA与指定LA不同，需要进行位置更新，增加呼叫建立时延；如果回落MSC与指定MSC不同，会导致被叫失败瑞林工程技术有限公司地下室出现短信呼案例分析：问题现象：用户反映在瑞林工程技术有限公司地下室，会出现接不到电话，收到短信呼提醒，主叫时要多次才能拨通对方电话。
一、分析判断可能原因及处理流程：（1）网络覆盖正常，UE位于不同的LAC区，要进行跨LAC回落，由于2G和4G网络间LAC-TAC未配置正确的对应指配数据，导致CSFB失败。
（2）网络覆盖正常，eNodeB侧CSFB数据配置不正确。
（3）网络覆盖正常，不存在跨MSC、RNC切换及回落，MME侧不支持CSFB。
如部分高通芯片只能设定语音优先或数据优先。
（4）4G网络或者3G网络覆盖弱，CSFB呼叫时延长或语音无法建立成功。
5到4切换未发起TAU切换失败案例分析
5到4切换未发起TAU导致切换失败案例分析1问题现象
5切4之后终端没有发起切换后的TAU，而是立即发起了4G内部的S1切换，并且这次S1切换因目标eNB负荷过高失败。
这个切换后没有发起TAU，导致了后续终端重选回5G带的参数是S1 mode not supported，在此后10分钟里终端发起5切4被AMF拒绝194次。
2问题分析
（1）19:48:33 从5G回落到4G eNB
（2）在4G发起了S1切换，因目标enb负荷过高被拒绝
（3）再查看S1-MME接口，19:48:33没有切换后的UNT TAU，只有19:48:37 Initial TAU(TSC=1)。
（4）19:49:22终端移动性更新注册5G时不支持S1 MODE了
（5）由于用户不支持S1 MODE，AMF清除了用户的EBI，重新创建也不会重新申请，所以在收到handoverRequire时没有会话有EBI，所有会话不支持回落，一直切换失败。
（6）直到20:01:40终端在5G重新初始注册，才恢复正差。
3问题定位
（1）切换后无UNT TAU，而是发起Initial TAU，向AMF要上下文，AMF校验Context Request中TSC和之前在5GTSC=0不一致，会在Context Rsp中回复失败（92 User authentication failed）
（2）用户在5G注册，携带S1 Mode not supported，导致后续用户发起的5切4都被AMF 拒绝，handover preparation failure( 8 ho_target_not_allowed)
4问题优化
需核心网侧配置终端策略，目前xx核心网暂未解决。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
68.89
135
100
35
100
93
7
4600-352070-1
太隔LF1
73.2
153
121
32
121
112
9
从上表可知，SCELL向多个TCELL切换失败。
2、分析SCELL是执行切换失败还是准备切换是失败，从上表分析得知，多个SCELL主要是准备切换时失败较多，根据准备切换失败的可能原因进行逐步排查。
执行切换失败分析思路：
1、告警处理。针对（Scell->多个Tcell差）和（多个Scell->T cell差）两种切换异常，应首先通过指令al查看目标或源站点的即时告警、lga查看历史告警，检查小区是否存在影响切换成功率的相关硬件告警
2、干扰优化。针对多个Scell->Tcell切换差，在排除了目标小区告警因素后，需检查目标小区上行PUSCH底噪。当目标小区上行PUSCH底噪高于-105dBm时，则此切换异常可能为上行强干扰导致，需进行干扰排查并处理。
NAME
切换成功率（邻区对）
准备切换尝试数(邻区对)
准备切换成功数(邻区对)
准备切换失败数(邻区对)
执行切换尝试数(邻区对)
执行切换成功数(邻区对)
执行切换失败数(邻区对)
4600-864065-1
漕桥北LF3
74.11
5280
3959
1321
3959
3913
46
4600-890190-1
杨桥LF1
LF31G46C
太隔LF3
91.79
3220
125
497
14
2015/5/7
LF31I34B
竺山湖水文站LF2
98.59
367
0
1192
13
2015/5/7
LF31H54C
杨桥LF3
95.59
99
0
491
9
2015/5/7
LF31H54A
杨桥LF1
97.06
2097
0
2489
9
2015/5/7
LF31E40A
漕桥熠驰机械联通LF1
95.6
10419
0
2985
8
2015/5/7
LF31G06C
潘家西LF3
99.22
3737
0
1908
4
2015/5/7
LF31A43C
漕桥北LF3
96.71
13613
2
972
2
2015/5/7
LF31E78B
五一度假村联通LF2
98.78
944
0
120
1
2015/5/7
LF31G46A
70.11
445
324
121
324
312
12
4600-863619-1
五一度假村联通LF2
74.81
385
293
92
293
288
5
4600-863590-1
潘家西LF3
75.75
367
291
76
291
278
13
4600-864065-2
漕桥熠驰机械联通LF1
71.32
265
191
74
191
189
2
4600-863603-2
故障案例
TAC多定义导致切换失败案例分析
省公司
江苏
专业
无线
设备类型
设备厂家
爱立信
设备型号
RRUL 62B40A
软件版本
CXP102051/22_R46DK
编制时间
作者
作者电话
入库时间
2015-05-18
审核人
审核人电话
厂商审核人
联系方式
关键字
TAC、MME
故障现象
话务指标统计分析，漕桥北LF3、杨桥LF1、潘家西LF3、竺山湖水文站LF1、漕桥熠驰机械联通LF3、杨桥LF2、太隔LF1、竺山湖水文站LF2、太隔LF3、五一度假村联通LF2、漕桥熠驰机械联通LF1、杨桥LF3全天切换成功率较低，如下图所示（指标统计时段24小时日均）：
557
1517
1487
30
4600-864065-3
漕桥熠驰机械联通LF3
72.75
1978
1465
513
1465
1439
26
4600-890190-2
杨桥LF2
66.77
1315
990
325
990
878
112
4600-864065-1
漕桥熠驰机械联通LF1
71.72
1206
881
325
881
865
邻区关系核查优化，删除冗余邻区，添加必要邻区关系。
MME数据配置、X2定义的检查，避免寻不到目标小区导致准备切换的失败。
处理步骤
1、首先，查看这些小区是切向一个T CELL差还是切向多个T CELL差，指标统计分析发现S CELL切向多个T CELL差，如下图所示：
EUtranCell
Relation
DATE_ID
EUtranCellTDD
NAME
切换成功率（邻区对）
同频准备切换尝试数
同频准备切换失败数
异频准备切换尝试数
异频准备切换失败数
2015/4/27
LF31A43C
漕桥北LF3
88.59%
22980
0
11048
2874
2015/4/27
LF31H54A
杨桥LF1
77.27%
1500
0
3748
漕桥熠驰机械联通LF3
69.35
310
237
73
237
215
22
4600-864063-1
太隔LF3
68.65
252
182
70
182
173
9
4600-863787-2
太隔LF1
66.99
206
146
60
146
138
8
4600-863762-2
漕桥北LF3
65.2
204
145
59
145
133
12
4600-864063-1
1026
2015/4/27
LF31E40C
漕桥熠驰机械联通LF3
87.99%
2868
0
6282
904
2015/4/27
LF31I34A
竺山湖水文站LF1
76.99%
646
0
2587
709
2015/4/27
LF31E40A
漕桥熠驰机械联通LF1
94.81%
12833
0
1650
405
2015/4/27
LF31G06C
3、在进行切换失败分析之前，分析以上多个SCELL是否属于同一处区域，还是比较分散，从而确定优化方案。MCOM地理分析，这些小区均集中在同一片区域，且与无锡—宜兴交界。
4、根据上图，发现切换成功率低小区均集中在同一处区域，且位于无锡—宜兴的边界区域。数据分析，目标小区均无锡—宜兴区域内，TAC均为21149。怀疑可能是宜兴边界小区存在干扰或数据定义错误等问题。
潘家西LF3
91.10%
3575
0
1707
399
2015/4/27
LF31H54B
杨桥LF2
86.51%
2824
0
1343
332
2015/4/27
LF31I34B
竺山湖水文站LF2
78.03%
143
0
895
219
2015/4/27
LF31G46A
太隔LF1
88.72%
1418
0
595
156
2015/4/27
5、与宜兴网络优化人员联系，经检查宜兴TAC:21149在两个MME里均进行了定义，怀疑可能是该问题导致。经对另一个MME的TAC:21149进行删除后，多个时段指标观察，各个小区的切换成功率指标均得到了明显改善。如下表所示：
DATE_ID
EUtran
CellTDD
NAME
切换成功率（邻区对）
同频准备切换尝试数
68.68
3713
2687
1026
2687
2550
137
4600-864065-3
漕桥北LF3
71.45
2841
2081
760
2081
2030
51
4600-863721-2
竺山湖水文站LF1
71.31
2548
1845
703
1845
1817
28
4600-864049-1
漕桥北LF3
71.7
2074
1517
太隔LF1
98.83
1780
0
106
0
故障总结
针对这种多个小区（SCELL）切向多个TCELL均失败的问题，重点排查大面积干扰问题或数据定义问题，从而快速找出切换失败问题，进行优化解决。
16
4600-863721-1
潘家西LF3
74.04
1125
850
275
850
833
17
4600-864065-2
漕桥熠驰机械联通LF3