lte优化案例高铁测试tac更新失败优化案例要点.docVIP

嘉兴电信华为LTE工程优化后台优化案例 TIME \@ yyyy-M-d 2015-1-29 华为保密信息,未经授权禁止扩散 第PAGE12页, 共 NUMPAGES \* Arabic 13页 高铁测试TAC更新失败优化案例 1、【现象描述】 嘉兴电信2015年1月5日，在对沪杭高铁嘉兴区域段进行DT测试时，发现存在多处TAU更新失败。 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流程。 【处理过程】 本次测试的终端型号华为E3292，在其他区域测试时均正常，因此可以排除终端故障的问题。而干扰会令周边站点的底噪普遍提高，在基站性能指标中并没有发现底噪明显提高的问题，因此干扰问题也可以排除。 综合全路段分析发现，TAC更新失败，多数伴随小区切换失败、重建失败发生，结合TAC更新请求发生场景分析，可分析高铁TAU产生原因有两条： 注册状态下TA发生改变 ?注册状态下覆盖区丢失后UE本地EPS承载去激活，重新进入覆盖区 结合这两种情况，我们选取2个较为明显场景详细分析。 3.1注册状态下TA发生改变 问题区域事件图如下，列车由南往北行驶： 在后台在U2000中并没有发现任何告警信息，但我们核查数据发现TAC配置错误。桐乡上 河头南和桐乡高桥经济开发区域所在区域的TAC规划为22027，桐乡高桥经济开发区错配置为22034。 根据DT测试数据分析，UE从LF_H_桐乡上河头南站切换到LF_H_桐乡经济开发区站点，两站点TAC设置不同（两个站点规划在同一TAC下），切换时存在TAC更新，由于高铁速度较快，且信号覆盖较差，导致TAC更新失败。 信令如下： SIB1中服务小区（桐乡高桥经济开发区）信息（含eNodeB ID和Cellid）， ENodeBID转换为十进制为353876，TAC为22034。 TAU Request中的TACID为前一次使用的小区的TACID，配置为22027，和LF_H_上河头南站点配置一致： 终端上一次更新的TAL并不包含当前服务小区的TAC 22034，因此发起了TAU。 上一次TAU Accept消息下发的TAL 修改TAC后： 问题区域如下：无TAC更新失败事件出现 SIB1中接入小区信息（含eNodeB ID和Cellid） ENodeBID转换为十进制为353876，TAC为22027,与修改值一致。 3.2注册状态下覆盖区丢失后UE本地EPS承载去激活，重新进入覆盖区 问题区域如下： SIB1中接入小区信息（含eNodeB ID和Cellid） TAU Request中的TACID和TAU Accept中一致 TAU更新成功后的TAC列表（和核心网爱立信的产品设置有关，TAL列表为更新最新的6个TAC） 切换过程中UE收到不到目标小区信息，重建RRC无响应（受核心网异厂家因素，无法确认是否是上行还是下行），从而导致上下文丢失而被拒绝，之后终端发起TA-update 由于上下文丢失，TAC更新失败。 RF调整后，没有出现TAC跟新： 从信令上看，已经正常： 4、【总结建议】 嘉兴地区LTE核心网采用爱立信设备，爱立信核心网为每个用户维护一个TAL列表