td-lte端到端优化交流-北京

《td-lte端到端优化交流-北京》由会员分享，可在线阅读，更多相关《td-lte端到端优化交流-北京（12页珍藏版）》请在金锄头文库上搜索。

1、LTE端到端优化交流 北京移动 网络优化中心 2014年5月 2 概述 在4G和移动互联网时代，业务的实现愈发依赖终端与无线、核心网、智能网、互联网等各个 专业网络及业务平台间的密切配合，任何一个环节出现问题均会对用户感知造成影响，端到端优 化成为LTE时代问题定位的关键。 北京公司现网核心网存在诺西和华为两种设备，无线网存在华为、中兴、诺西三种设备， “核心网-无线网”地理分布上存在5种组合，端到端优化难度较大，在前期LTE集中优化过程中， 通过多部门协同，从终端、无线、传输、核心网等角度深入排查网络异常问题，定位并解决了包 括下载速率异常，互操作感知差，接入成功率低等严重影响用户感知的问题

2、。 3 1、问题现象 由于国漫入用户大多不支持TDS模块，无法从2G网络重选回4G网络问题， 同时为改善本地用户返回4G时延，减少2-3-4G桥接过程带来的不可及风险， 北京现网选取重点区域开启了网络2-4重选功能。功能开启后接到发现在4G 网络下苹果iPhone5S三星Note3等手机下载速率较低，仅为500K左右。 2、问题分析 终端侧：不同型号品牌终端均存下载速率异常问题，排除终端个体问题； 无线侧：在不同eNodeB下均能稳定复现，对Uu口，S1口进行了信令跟踪， 发现核心网为用户分配的AMBR为472Kbps，初步定位为核心网问题。 核心网：在MME侧进行了信令抓取，用户在4G网络下

3、协商速率为472kbps， 为问题症结所在。 基于上述分析，展开了海量测试，测试结果如下： （1）在不同场景下测试，表现有所不同： 4G网络下测试，问题复现概率很低； 当终端从2G网络直接重选回4G网络后，会出现下载速率低的问题。 若CSFB终端通话结束后通过FR返回4G，或空闲态通过2-3-4桥接方 式返回4G，均不存在速率低的问题。 下载速率优化案例-开通2-4重选后下载速率异常（1） 2G 4G 3G 终端侧终端侧 无线侧无线侧 核心侧核心侧 4 （2）流程分析 1)、2G终端在网络数据业务由SGSN、GGSN进行承载; 2)、4G终端在2G网络下，承载路由为SGSN，P-GW ，网络分

4、配的QOS 上下行MBR为(472K,472K)，即2G网络下的最大速率。 3)、（正常情况）MME按照SGSN上报的AMBR为(472K,472K)请求建 立承载，因为是4G终端MME会从HSS获取用户签约QOS，与P-GW协 商后上下行AMBR为(256M, 256M)，正常发起业务。 4)、（异常情况） 4G终端从2G网络迁移到4G网络后，SGSN错误的将 QOS 上下行MBR(256M,472K)传给了MME，实际应为（472k， 472k） 5)、MME按照MBR映射AMBR 上下行(256M,472K)请求建立MME S- GW P-GW通道，但P-GW 存储的AMBR为( 472

5、K,472K)，MME认为 PGW进行了QoS改变，从而使用PGW的QoS AMBR (472K,472K)进行 承载建立，而不再触发根据HSS的4G签约修改QoS的流程，造成异常。 3、解决措施 通过SGSN参数优化来解决这个问题，修改SGSN PRFIlE参数01731 QOS_SUB_BR_2TO3_ISHO为0，使SGSN传给MME的QOS为原来协商的 QOS MBR为( 472K,472K) 从而解决4G下载速率问题。同时修改此参数不会 影响2-3G重选后的下载速率。 下载速率优化案例-开通2-4重选后下载速率异常（2） 正常流程正常流程 异常流程异常流程 5 下载速率优化案例-测速

6、软件速率慢的问题的分析 1、问题现象 北京移动LTE网络上使用测速APP进行测试，在诺西核心网下载速率达不到预期的60M以上，具体情况如下： iphone 5s通过speedtest测试速率稳定，速度稳定在70Mbps-75Mbps 三星7108D、索尼M35t通过speedtest测试速率不稳定，最高下载速率73.05Mbps，最低为47.54Mbps 2、问题分析 1）eNodeB、SGi接口进行联合抓包，对比分析后发现：测速低的用例丢包次数明显多于测速高的用例。丢包导 致TCP发送窗口一直很小，从而降低了下载速率。 2）为进一步确认丢包原因，从终端差异、PTN QoS设置进行排查。 在同

7、一个LTE基站下进行了PTN QoS设置对比测试 随着PIR的增大，测试速率明显提升。PTN网管统计，在PIR=320M的时候 丢包的次数要比600M频繁，而在1G的情况下没有发现有丢包的现象。造成 PTN丢包的原因是：PTN收到超过0.6Mbit/ms的突发流量，超过了PIR值。 iphone 5s测速快且稳定，而采用安卓系统的三星Note2测试不稳定。 对比两种终端抓取的数据包，发现在进入拥塞避免阶段后， iphone 5s会通过发 送tcp windows update消息抑制服务器发包速度，从而避免测速服务器下行发 包速率超过空口理论速率或EPS承载的QoS速率，降低了丢包次数。而安卓

8、平台 的终端没有这种行为，多次因为丢包进入拥塞控制。 终端型号 iphon e 5s 三星 Note2 三星 Note2 测试速度 (Mbps) 76.68 73.05 47.54 重传次数 0 6 10 平均速率（Mbps） CIR:40M PIR:320M CIR:40M PIR:600M CIR:40M PIR:1G CIR:120 M PIR:1G 20.98 45.87 54.75 59.71 3）原因总结：测试软件采用TCP协议进行主动测量，计算网络带宽。4G网络时延较小，造成TCP连接的下行 数据突发流速超过网络的QoS设置，网络侧丢包造成TCP连接的传输效率大大降低，从而影响测

9、速结果。诺西 核心网问题明显，华为核心网有缓存机制，因此问题并不明显。 3、解决措施 已调整部分重点站的峰值PIR，测试速率有明显提升。后续需进一步推进PTN QoS配置和EPC设备的优化。 6 下载速率优化案例-核心网软件缺陷导致下载速率低 1、问题现象 测试发现下载速率不稳定，速率波动变化很大，现象如右图所示， 正常下载的速率很平稳，异常时速率出现针尖状掉零现象。 2、问题分析 1）初步怀疑是FTP服务器问题，更换了FTP服务器之后，问题并没有解决。 2）在随后的测试过程中，进一步发现，并不是每次测试过程中都会出现 上述现象。如果正常，只要不重启终端设备就一直保持正常。只有终端设 备重启后

10、或重新附着网络后，下载速率才可能出现异常。 3）怀疑下载速率异常与SGW服务器分配的IP地址有关（因为终端重启或 重新附着网络会重新获取IP地址），可能是某个SGW服务器存在异常。于 是反复进行了终端设备重启，查看下载速率异常与否与对应的ip地址，并 进行了记录。 4）从统计表中可以发现， IP地址以10.7x 开头，下载速率异常， IP地址 以10.5x开头，则下载速率正常。 5）核心网排查发现，问题由GGSN软件BUG导致。业务node中会偶然出 现正在处理或悬挂的session数在队列中远大于其他node，导致GGSN不 会给该node分配新的业务。如右下图所示，节点AS11-0处理的s

11、ession 数远大于其他正常的节点。 3、解决措施 临时闭锁并重启相关的GGSN上的5个node，涵盖了速率掉零问题涉 及的地址池。最终方案通过NG30 CD2140版本解决。 ip地址 状态 10.50.73.243 正常 10.50.87.77 正常 10.51.211.143 正常 10.71.80.4 掉零 10.70.16.89 掉零 10.51.195.128 正常 10.71.246.139 掉零 10.70.236.240 掉零 10.51.134.216 正常 10.51.91.225 正常 10.71.55.212 掉零 10.71.135.37 掉零 10.70.144

12、.0 掉零 10.71.196.165 掉零 异常IP 正常IP 7 1、问题现象 中兴eNodeB下使用的华为MIFI在场强比较好的地方会偶尔会从 LTE掉落到TDS，影响感知。 2、问题分析 终端侧：终端感知为在LTE覆盖很好的地方，速率突然变慢，mifi显 示为3G网络。同样小区下许多终端均有此现象发生； 无线侧：无线侧排查该时段下同时将34个用户重定向到3G网络； 初步怀疑由于无线侧原因导致异常互操作现象发生： 经在投诉区域测试发现，CRS-RSRP为-87dBm, SINR为29dB, 该区域为 LTE覆盖强场，无线环境良好； 进一步对异系统参数进行了核查： 空闲态：4-3重选门限：

13、-120dBm 连接态：基于测量的异系统A2门限配置为-110dBm，B2为-120dBm；盲 重定向A2门限-122dBm。该场景不满足异系统重定向条件。排除互操作参数问 题。 采集终端侧信令 网络下发RRC Release重定向到3G（而之前终端并未上报任何测量上报信 息），导致终端MiFi在强场下从4G到3G，这说明了如下两点： 1、导致异常重定向的流程不应该是终端触发导致，而是整个小区的异常 2、导致终端异常4-3G是由于连接态下重定向导致，而不是空闲态下终 端的重选 开始时间开始时间 ME ID LTE-UTRAN系统间系统间 重定向请求次数重定向请求次数 (S1断链断链)(次次)

14、2014/5/14 16:15 67160 7 2014/5/14 16:15 67160 10 2014/5/14 16:15 67160 6 2014/5/14 16:15 67160 11 互操作类案例-异常4 - 3重定向问题(1) 无测量消息上报 8 2、问题分析（2） 通过测试发现，平均每天出现一次重定向到3G的情况，且时间不固定。采集终端、eNodeB，MME侧信令进行了联合分 析，发现网络侧下发了带有3G频点的盲重定向消息。 不同于标准的盲重定向流程，之前会上一条测量报告，满足A2门限后才会出发异系统请求。通过排查发现由于S1口传输链 路闪断导致中兴eNodeB发送带有携带3G

15、频点的RRC Connection Release消息，释放了基站下所有连接态的用户，并重定向到 3G网络。 通过后台网管指标统计，发现每次RRC connecion Rel之前S1口都出现了传输链路闪断，通过与中兴核对算法原理，发现 12.5S内S1不通就会通知平台S1断链，此时平台会通知各模块，负责重定向处理的模块就会出现触发由于S1断链导致的重定向。 但是上报告警的模块会等1S看断链是否恢复，如果恢复就不会上报告警，如果没有恢复就上报告警。 3、解决措施 问题的根源是基站与MME侧S1口的传输链路频繁闪断导致，从而异常触发了RRC connecion Rel盲重定向到了3G网络，后 续需

16、解决设备侧S1传输频繁断链的问题。 中兴内部保护算法机制，当S1闪断时，将终端重定向到3G，目前中兴给出的建议是当S1闪断触发时，通过调整优先级的方 式将终端重定向到异频的LTE网络，但需要评估这种基于私有算法调整方式的合理性。 重定向到3G：确保断链后的数据业务连续性，但由于速率差异较大会影响用户数据业务感知； 重定向到4G：数据业务连续性且速率差异较小，但切换到其他4G小区后由于本小区电平较好，会导致乒乓切换现象发生。 互操作类案例-异常4 - 3重定向问题(2) 9 接入优化案例-外省用户漫游导致接入失败问题 1、问题现象 华为ENB在诺西核心网下每天出现大量传输层原因导致 的接入失败，占所有接入失败的51.8%。通过定位发现 问题小区主要分布在北京至河北、天津的高速公路、铁 路沿线。现场测试未发现问题，多款终端接入正常。 2、问题分析 1）传输层配置检查，告警检查均未发现问题，排除无 线侧原因。 2）通过失败信令的分析定位原因。发现核心网在指派 SGW地址时（InitialContextSetupReq）指派的IP地址