tcp灌包来包不够_核心网-QCI为5导致UDP等业务速率极低

核心网－QCI为5导致UDP等业务速率

极低

1 现象描述

测试中发现，UDP下行灌包10Mb/s，UE侧接收流量仅为1.7Mb/s,其他业务速率也不超过1.7Mb/s

2 告警信息

无

3 原因分析

UDP流量受限一般有3种原因：1、开户AMBR限制 2、传输问题，如高丢包率、大时延等。 3、信道质量差和调度因素。

1、首先在核心网侧查看该IMSI开户流量信息，发现最大为100M，因此排除开

户流量限制因素。

2、怀疑是传输问题，做UDP 10M灌包业务时，通过Web LMT使用MML命

令 DSP ETHPORT产看eNodeB端口流量信息,其中，实际接收流量为1262784(字节/秒)，证实eNodeB S1入口流量与Server端发送流量一致，说明核心网到eNodeB侧无丢包。

3、做TCP灌包业务，使用Ethreal在UE侧和Server侧同时抓包，发现大量

Dup ACK 和TCP Retransimission信息，即为大量丢包。然后再做S1口镜像抓包，分析TCP包序号发现丢包位置为eNodeB到UE段。

4、以上几点证明数据流量在eNodeB到UE段受限，怀疑是下行调度问题，查看

工具得知，UE做UDP 10M灌包时，每TTI调度49个RB左右，符合10M带宽小区最大可调用RB数，说明资源调度次数是充足的。

5、但此时MCS却异常显示为1阶，由于RSRP值为65，证明UE处于近点，

正常情况下eNodeB调度使用的MCS阶数应为28阶。而MCS为1的情况一般有两种：①用户处于远点②传输IMS信令。根据RSRP值可以排除远点的情况，所以目前应处于IMS信令传输状态。协议中规定，IMS信令传输使用的QCI等级为5,于是查看该业务的QCI，通过OMT上ESM_ACT_DEFLT_EPS_BEARER_CNTXT_REQ信令确认QCI为5后得知：目前eNodeB对UDP等业务以IMS信令方式进行调度。

6、最终真相大白，该套核心网将默认QCI值设置为5，各种业务建立时QCI都

将被配置为5，而QCI为5仅用于IMS信令传输，eNodeB为其分配的阶数一般为0阶和1阶，编码效率低，TBS小，导致各种业务吞吐率都上不去。