HSDPA数据业务早晚忙时下载速率剧变问题分析.docx

HSDPA数据业务早晚忙时下载速率剧变问题分析
1、现象描述：近期对网络使用ATU设备进行HSDPAFTP拉网测试时，采用同样的测试方式和测试设备，发现晚忙时FTP平均下载速率比白天拉网测试平均下载速率低500Kbps左右；晚忙定点CQT测试比白天定点CQT测试，平均下载速率也低500Kbps左右，针对此现象漳州TD网优进行反复的DT和CQT相关对比测试，测试结果如下：

20120214晚拉网DT速率截图 20120215早拉DT网速率截图

14日晚DT拉网与15日DT早拉网统计指标对比
同一地点、同一设备、同一测试方式，白天比晚上速率高；

CQT晚上截图 CQT白天截图
由于GSM晚上拉网速率也偏低，现场通过在竹围移动室分站和土坪站点进行分别采用ATU150设备和大唐8142设备进行HSDPA业务下载测试，后台统计结果如下：

纵观前面反复测试可以得出：无论GSM还是TD进行FTP下载时，早忙时均高于晚忙时，拐点分别出现在18:00左右。
2、 问题分析
1）从上面的截图和指标可以看出白天测试正常，由于漳州网格2均在晚上拉网，近期速率均较低，昨天晚上使用大唐8142进行对比测试，发现不止网格2所归属的RNC6E31，其他RNC6111等都具有共性，此前初步怀疑晚忙时用户数较多，影响下载，但经过晚上后台跟踪和测试，发现大唐8142占用的HSDPA载波，只有一个用户时，下载速率也较低.，排除现网用户影响。详见如下：

晚上定点下载8142终端测试时码数图 定点下载 8142终端测试时速率图1
再通过对早忙时和晚忙时的数据流量、码资源利用率、HSDPA的平均用户数对比，两个时间段相差不大，通过以上方法排除了由于多用户共享资源引起的低速率问题。
2）现场通过对不同的FTP服务器和其他地市对比情况，排除FTP由于不同时间段引起的服务器问题。

3）通过对全网的RNC级参数、CELL级参数、DCCC参数、Psinactive、功控参数定时器等PS相关参数进行核查无异常。
4）排除FTP、参数问题等问题后，对定点测试的大唐8142分别正常和异常跟踪CDT和使用TPCwin跟踪IUBlog
分析漳州土坪小区26972正常时段9:21:29~9:24:14s的CDT发现，RNC从GTPU(也就是核心网侧)上接收到的数据包比较正常，正常下载过程中都在130个左右，两次测试平均数据包每2秒115个，如下：

注：标记处为用户挂断起呼阶段，存在数据启动的过程。
分析土坪小区26973异常时段19:07:45~19:10:03s的CDT发现，RNC本身收到的数据包较正常阶段就少，基本上都不到130个，平均只有81个左右，如下：

注：同样两次下载，RNC以上的数据量波动很大
同时通过CDT，分析RNC传输数据的能力，SDU和PDU数据包没有丢弃的现象，PDU的重传率也很低基本上在1%以下，不影响数据的传输。
分析正常时段的TPCWin，15:11:49~15:12:34s,如下：

NACK次数稍微多点，无线空口质量可能存在不足。调度次数比较满，UE吞吐量比较高，说明NB的调度上不存在问题。
15:14:11~15:15:01s如下：

某一秒内调度不足主要是数据不充足，如下图，PQ缓存比较低，主要原因是业务刚建立不久，存在一个数据传输启动的过程，分析CDT里也有一个稍微低的点。

15:15:01~15:15:16，调度很好，速率很高，就是有些NACK，空口环境可能有些不足。

通过以上CDT和TPCwin分析，基本排除由于RNC、NODEB侧传输引起的速率低问题，所以说，问题的核心还是在异常时段，FTP和CN侧数据量不足。
5） 排除FTP问题后，协调SGSN工程师对SGSN跟踪核查，发现处于速率较低的时间段，CE到SGSN侧的主用链路负荷峰值高达95%以上，由于春节后数据流量的大幅提升，导致峰值负荷偏高，对现网用户的速率造成一定影响；

6） 通过在2月18号凌晨对CE到SGSN的备用链路激活后，将备用链路用于连接CE到SGSN53、SGSN54，市区挂接归属SGSN57主要采用主用链路，使得激活后的备用链路分担改造前主用链路负荷。经过改造后晚忙时HSDPA下载速率已经恢复正常，目前可达1.1Mbps以上。

ATU和大唐8142定点CQT在18点后恢复正常 ATU定点CQT在18点后恢复正常
日期
网格
设备
平均应用层吞吐率(kbit/s)
链路层BLER(%)
掉线率(%)
平均车速(KM/H)
20120218晚忙
2
ATU168
1126.9
0.63
0
18.17
20120218晚忙
2
8142
1035.64
6.78
0
21.3
总结：随着数据业务（包含有GPRS、EDGE、TD、WLAN）的大幅增长，各个网元的负荷都有可能不堪负重，所以在我们平时日常优化中，不定期观察网元或链路负荷显得尤为重要，避免产生各式问题和不必要的数据业务投诉。