传输相关问题对lte无线网络性能的影响

1、传输相关问题对LTE无线网络性能的影响中国移动浙江公司网优中心2014年12月随着LTE网络架构的扁平化，LTE无线侧设备（eNB）不再通过诸如2/3G一样的BSC和RNC进行汇接，而是通过X2口和S1口直接与邻站和网通过传输设备进行直连；在一定程度上增加了无线设备与传输的配合要求，在如下2大类：情况下的信令风暴风险提高。目前发现主要面对PTN CIR/PIR 设置对于LTE业务速率存在影响：存在配置错误；部分特殊场景按标准配置存在受限可能；传输设备在异常情况下的广播包存在信令风暴风险，甚至导致大面积无线设备传输中断，目前发现的触发场景包括：如ARP老化时间过短导致的ARP信令负荷过高；MAC

2、地址不匹配情况下的广播及转发带来的环回。随着LTE业务不断发展，与传输网的关联度必然会更加密切，关联问题会越来越多。浙江湖州部分组网示意图2二、案例1： CIR/PIR设置导致业务速率异常（1）问题描述单站优化发现个别站点在无线环境很好的情况下，速率较低，如下为衢州双港东路_3小区测试速率，速率始终在40Mbps以下。而该站点的正常测试好点测试至少在50M之上。问题原因分析无线侧分析表明传输侧数据下发数据导致MCS降阶：从层二log来看，UE上报的的MCS很高，基本都是28，link adaption 也没有下调MCS，但是最后下发的MCS 均值在16，但是最后由于数据，mcs被降下来。侧MA

3、C层Log打印，表明UE无线环境正常实际下发MCS平均只有163问题产生机制传输侧配置确认：传输设备在衢州采用的带宽配置方式是单向通道（主备各2通道），而其他地市采用的是双向通道（主备各1通道）。经确认衢州移动PTN6900当前版本是V6R6C00SPC300，该版本单向Tunnel不支持峰值带宽，必须采调整后验证向tunnel配置方式。修改传输侧设置后，通过4个站点的验证，速率87%；结论 PTN PIR/CIR设置问题会导致无线侧业务速率不达标。4站名平均RSRP（dBm）平均SINR（dB）带宽配置方式下行吞吐率（Mbps）衢州飞翔国际-72.726.7单向通道38双向通道80衢州光明电

4、力大楼7226单向通道38双向通道50衢州府东街派出所7923单向通道38双向通道55衢州招商场8222单向通道25双向通道57问题描述杭州广播仅16Mbps。为S11单室分站点，采用CIR=40/PIR=147的配置，但Speedtst实际测试问题原因分析与案例1分析方法相同，在排除无线侧原因后，通过调整PIR，可以发现，当PIR调整至300Mbps时，下行丢包接近于0、5问题产生机制当突发速率PIR速率是，对网络转发的要求如下：1ms内发送数据Y，网络设备无法直接转发（PIR突发）,则缓存必须大于Y值；网络设备必须在下一个突发到来之前或RTT周期内把缓存中的数据转发出去；PTN侧抓包分析显

5、示，1ms内突发速率已大于1Gbs，密集突发模型此时传输链路对于突发的丢弃。度较小，导致部分数据结论 PTN PIR设置与传输链路中对于突发的度有关，部分场景需要调整。6问题描述某地市部分LTE站点指标劣化明显，主要是eRAB建立成功率明显；无线OMC显示LTE基站出现“用户面承载链路故障告警”，业务类型为S1和X2，且处于频繁的翻转状态（每小时约1万条）。从传输PTN680 设备 倒收、等待恢复告警震荡。问题原因分析闪断，发现包出现丢包。传输上陆续出现从PTN680的主控盘提取到大量TTL至为1 的GTP报文，该部分报文属于报文，表明网络中已经出现信令环回；LTE的协议源向目的频繁发起ECH

6、O REQUEST数据包，数据量为：49Mbit，远远超过了烽火PTN680设备主控盘信令通道的带宽，造成信令通道拥塞；7问题产生机制分析PTN设备异常处理机制导致信令：烽火PTN设备二层业务配置为VPLS业务模型，在涉及到同一子网段内业务处理时，若收到同一子网内的X2业务ECHO REQUEST包，但在PTN 680设备同一VPLS组内未查询到该X2数据目的MAC，就无法对该数据基于MAC地址进行直接转发，需要在该VPLS组内进行一次广播，将该数据包患。后发送给VPLS组内所有成员，存在一个数据包泛洪的隐设备报处理机制造成环回转发：目前的数据包中未捕获到异常事件数据包的MAC地址，但是数转发

7、，说明转发的MAC地址为本接口的MAC地址，或非单播MAC地址。从目前捕获的数据包，据这些环回的数据包的目的IP地址为非本的IP地址，因此，这些IP地址被重新转发到L2网络中。MAC层处理策略IP层处理策略结论：网络中存在异常组播包，经的不断转发触发了环路，由于烽火PTN680的VPLS泛洪机制最终导致了网络风暴，引起网络拥塞。8目的IP是否与本地IP相同是否丢弃说明是否说明该IP包是本机IP包，应该被处理。否否非本地 IP 包， 根据 TCP/IP的转发协议进行处理。是否为单播 MAC地址是否与接口 MAC地址相同是否丢弃说明是是否说明数据包是本地应该接收的数据包。所以应该处理该数据包。是否

8、是非本接口应该处理的MAC包，要丢弃。否-否无法确认数据包是否需要本地处理，因此转发给IP层进行判断。问题描述某地市PTN6900下挂部分问题分析11月5日9:47:44开始发生中断，到10:17自动恢复。查看PTN6900的日志,看到9:48:52设备上报安全中心防告警，报文类型为ARP，接口是Virtual-Ethernet8/0/1，表明PTN6900的Virtual-Ethernet8/0/1接口收到大量的arp报文上送。大量APP报文上送CPU的速率超过了保护的阈值限制导致丢弃。PTN防冲击机制： ARP报文默认上送CPU速率安全阈值为512kps，每个ARP报文大小64字节,所以每

9、秒钟可以处理 (512 * 1024) /(64 * 8)= 1024个报文，超过阈值的报文将被丢弃。PTN设备超阈值告警9问题产生机制分析现网的ARP报文分为S1和X2两种业务。从业务类型来看，S1的ARP报文数目应该是相对固定的，和规模线性相关；X2业务是相邻之间的切换，X2 ARP请求是由业务触发的，基站会向周围所有的务活跃程度有关。发出请求，X2的ARP请求和规模类似于指数关系，并且和LTE业贝尔的ARP老化时间是30s，并且报文发送机制是每秒一个，直到学到ARP为止。业务正常的情况下，每秒收到的ARP报文达到了320个；如果发生X2业务激发，ARP报文很可能就瞬间冲高超过1K，超过阈

10、值就会丢包，丢包又反过来触发持续发送报文，形成“越堵越发，越发越堵”的风暴效应。最后，站退服。学不到网关的ARP，无法向MME发送报文，造成基结论：ARP老化时间过短导致超过 PTN设备阈值，造成退服。10贝尔大唐中兴ARP老化时间30s1200s1200s600s厂家（规模）贝尔（1800）中兴（1700）（1800）（1900）报文上送速率321pps34pps30pps21pps传输PTN设备CIR/PIR设置进一步细化已针对CIR/PIR分站型进行规范，但现网中仍存在厂家配置机制（如双向tunnel配置方式在进一步细化。等）差异需注意和澄部分传输链路对于突发流量的度较差，需要通过调整PIR来减少丢率，需要根据实际情况确认。传输链路中的短板定位方法还在摸索中。推进厂家处理机制，确保网络稳定性侧ARP老化时间需要进一步规范，我省已要求厂家设置为1200s(重发间隔5s)；，需要将VPLS业务模型更改为N：1模型，烽火PTN设备通道异常时引起二层数据泛洪与厂家沟通后已承诺在12月完成相关升级；侧是否针对L2广播包在L3进行转发带来的环回风险，需要厂