金华EDGE上行TBF扩展专题报告Word格式.docx
《金华EDGE上行TBF扩展专题报告Word格式.docx》由会员分享,可在线阅读,更多相关《金华EDGE上行TBF扩展专题报告Word格式.docx(16页珍藏版)》请在冰点文库上搜索。
直到MS上发的不是Dummyblock而是RLCBlock,而在这之前上行TBF始终保持激活状态。
在ULTBF扩展模式下调度USF的方式:
●EN_FAST_USF_UL_EXTENDED=Disable
T_EXTENDED_UL_TBF_POL(200ms)用于为所有扩展模式下的MS调度USF。
●EN_FAST_USF_UL_EXTENDED=Enable
PACCH上处于扩展模式的MS:
每20msUSF调度一次
PACCH上处于扩展模式的2个MS:
每40msUSF调度一次
PACCH上处于扩展模式的n个MS:
每nx20msUSF调度一次
2.3.硬件支持要求
实现上行TBF扩展功能,运行环境必须满足以下几个条件:
●OMCR上的GPRS参数EN_EXTENDED_UL_TBF=enabled;
●BSS必须确定MS是否支持这个功能,可以通过GERANFeaturePackage1字段值来是否为support来确认。
该字段可通过GSM层3信令ClassmarkChange中的Classmark3IE获取,或AttachAccept、ActivatePDPcontextaccept和Routingareaupdateaccept消息中获取,如下图所示:
●必须是Rel-4的MS
2.4.手机版本支持情况
目前测试用的SAGEM490/498手机要实现支持上行TBF扩展功能,必须将手机版本设为Release4模式,具体设置路径为:
Testtool——>
Infos&
settings——>
Release——>
Release4
2.5.现网渗透率情况(2008年统计)
为了了解现网手机对该功能的支持情况,对金华市区(BSC002CX)/义乌市区(BSC201CX)/义乌郊区(BSC229NG)进行了Gb口跟踪进行渗透率评估。
方法如下:
1】过滤AttachAccept、ActivatePDPcontextaccept和Routingareaupdateaccept信令
2】同时过滤出以上三条信令的IMSI和GERANFeature指示并导成Excel
3】对重复的IMSI进行过滤,来确定唯一的手机用户,即全网支持数据业务的手机数
4】过滤出GERANFeature指示中为Support消息的用户数,即为支持上行扩展功能的手机数
5】以上两步相除即为上行扩展TBF功能手机渗透率
注:
其中GERANFeature必须是在R99字段内的消息内容
下表为三个BSC统计的渗透率结果,可以看出金华现网支持上行扩展TBF的手机数很少,基本维持在市区15%左右,而郊区仅为7%。
BSCName
手机总数
支持上行TBF扩展功能手机数
渗透率
BSC002CX(金华市区)
9569
1359
14.20%
BSC201CX(义乌市区)
10147
2318
16.86%
BSC229NG(义乌郊区)
4390
343
7.81%
注:
GERANFeature即代表是否支持上行TBF扩展功能。
3.现场测试对比分析
3.1.上行TBF扩展时延分析
上行TBF扩展功能体现在上行TBF的延迟释放,由此来加快下一次上行TBF的接入。
上行TBF延迟的时间是可以在OMCR上进行设置,如果设置不合理,如:
设置过长就会造成无线资源的浪费。
所以本节将以第三方测试的测试项为主,通过测试项的上行TBF的接入时延的分析,来确定合理的上行TBF时延的设置。
3.2.Attach信令时延分析
Attach测试的规范定义如下,Start:
AttachRequest,End:
AttachAccept。
因为金华地区的核心网是在每次附着过程中进行鉴权,所以在此过程中总共会涉及到两次上行TBF的建立,分别为AttachRequest和AuthenticationandCipheringresponse。
下表为Attach过程中在上行TBF扩展参数开启和关闭后每条信令之间的时延分布。
从中可以看出,在该功能开启的情况下,第二条上行信令(AuthenticationandCipheringresponse)的传输时间损耗明显小于功能关闭,这就是因为该条信令无需建立上行TBF而是延用了AttachRequest信令所建立的上行TBF。
下表统计了在Attach过程中两次上行信令:
AttachRequest和AuthenticationandCipheringresponse建立的时延基本是在1.1秒左右。
以上的时延分析扣除了上行TBF的建立时间。
3.3.WAP首页显示信令时延分析
对于WAP首页显示,CDS是统计PDP激活/WAP网关连接/WAP响应三个阶段的时间总和作为WAP首页显示时间。
因此对于时延的统计也是计算这三个阶段的时延情况。
1】PDP激活阶段
由于PDP激活是第一次TBF建立请求,所以无法节省上行TBF的接入时间,为1.2秒左右。
2】WAP网关连接阶段
此阶段涉及到WAP网关的连接时间,由于此阶段仅有Connnect消息会建立上行TBF,所以在开启该功能后,Connect消息可以直接使用PDP建立的上行TBF而无需重新建立。
3】WAP响应阶段
WAP响应阶段涉及到四次上行TBF的建立,分别包括两次用于WAP网址定向的Get消息,以及两次对下行Reply消息响应的Ack消息,并且这四次上行TBF的建立分别可以延用上一次上行TBF所建立的TBF,因而节省了上行TBF建立的时间。
下表统计了在WAP首页显示过程中五次上行TBF建立之间的时延情况,可以看出来时延基本分布在300毫秒~1.4秒之间。
对于WAP页面刷新的测试项基本和WAP首页显示类似,这里不再赘述。
3.4.WAP图铃下载信令时延分析
做一次WAP图铃下载(100K)时,在Get信令之后,会连续有15次左右的下行分包传输过程,且每次都会有上行的Ack消息进行确认,通过统计每次下行数据包传输间隔,即两次上行TBF建立的时延在1秒左右。
通过下图所示统计,在上行TBF扩展功能开启前后,每次上行ACK信令之后的再次数据包传输时间间隔EN_EXTENDED_UL_TBF=Disable时为600ms左右(图一),而EN_EXTENDED_UL_TBF=Enable时仅为300ms左右(图二),因为扩展上行TBF时延的开启,减少了每次分包传输再次建立上行TBF的时间,从而提高了传输速率。
图一:
EN_EXTENDED_UL_TBF=Disable
图二:
EN_EXTENDED_UL_TBF=Enable
由于单位大小的文件下载时间的减少,WAP下载速率也相应提高,100Kbyte大小图铃文件下载时间如下图所示:
EN_EXTENDED_UL_TBF
下载速率(Kbytes/s)
下载时间(s)
Disable
6.32
15.82
Enable
9.25
10.81
EN_EXTENDED_UL_TBF的开启减少了分包传输共15次的上行TBF建立时间约4.5s左右,和上表中两次下载的时间差值相吻合。
3.5.测试对比结果
我们列出了每种业务两次上行TBF建立的时间间隔,如下表:
项目
TBF再次建立间隔时间
EDGEattach平均时间
1.1s
WAP平均首页显示时间
0.3-1.4s
WAP下载速率
1s
针对上述理论分析,我们对金华城区开启上行TBF扩展功能的小区进行了对比测试,测试分为EN_EXTENDED_UL_TBF关闭和开启,T_MAX_EXTENDED_UL为0.5s、1s、1.5s、2s共五种情况,测试结果如下图所示:
从上表可以看出实际测试值和理论分析结果基本吻合,EN_EXTENDED_UL_TBF开启后的测试数据全面好于Disable时的数据。
T_MAX_EXTENDED_UL参数如果设置过小,小于两次上行TBF建立的时间间隔,这样第二次上行TBF建立时上一次的上行TBF已经释放掉了,上行TBF扩展功能实际上没有起作用;
而T_MAX_EXTENDED_UL设置过大,则会造成无线资源的浪费。
T_MAX_EXTENDED_UL设置为1.5s正好顾及到测试项目中WAP首页显示的最大时延1.4s。
测试结果在T_MAX_EXTENDED_UL=1.5s上形成分水岭,虽然设置为2s测试结果有提升,但升幅已不大,考虑到无线资源的开销,T_MAX_EXTENDED_UL最佳值应为1.5s。
3.6.USF调度测试分析
EN_FAST_USF_UL_EXTENDED=Disable时,在扩展模式下BSS下发的USF调度命令每200ms调度一次;
EN_FAST_USF_UL_EXTENDED=Enable时,一个MS每20msUSF调度一次,两个MS每40msUSF调度一次,依次类推。
在扩展模式下EN_FAST_USF_UL_EXTENDED=Disable,当有上行TBF建立时必须等到每200ms的USF调度命令的下发;
而EN_FAST_USF_UL_EXTENDED=Enable时,USF调度命令20ms就下发一次,这样上行TBF建立等待的时间就缩短了,从而测试数据也会相应提高。
根据以上理论分析,在EN_EXTENDED_UL_TBF参数开启和T_MAX_EXTENDED_UL为1.5的情况下,进行了EN_FAST_USF_UL_EXTENDED开关前后测试对比,测试结果如下:
从上表可以看出一台MS时EN_FAST_USF_UL_EXTENDED开启后由于ULTBF建立等待时间的缩短,测试数据好于未开启时的数据。
另从RLC/MAC信令可以看到上行DummyBlock响应USF调度命令的时间间隔和理论一致,具体见下图:
EN_FAST_USF_UL_EXTENDED未开启时DummyBlock间隔200ms:
EN_FAST_USF_UL_EXTENDED开启后一台MSDummyBlock间隔20ms:
EN_FAST_USF_UL_EXTENDED开启后两台MSDummyBlock间隔40ms:
4.网络QoS指标对比评估
4.1.KPI指标对比
2月22日我们开启了金华城区的9个BSC的上行TBF扩展功能,着重对上下行TBF建立成功率、释放率、重传率和PDCH分配成功率等指标进行跟踪关注。
经观察,EN_EXTENDED_UL_TBF参数开启前后BSC的各项指标保持稳定,如下图:
上下行TBF建立成功率、释放率、PDCH分配成功率
上下行RLC数据重传率(CSx/MCSx)
4.2.拥塞情况分析
上行TBF扩展功能开启之后,上行TBF的延迟会增加无线资源的开销,对于已经非常拥塞的BSC而言会造成TBF建立成功率和正常释放率等指标的下降。
由于目前金华城区支持上行TBF扩展功能的手机渗透率只有15%左右,本次实验该功能开启后对整网指标的影响暂时得不到明显体现。
由于该功能的开启增加了无线资源的开销,除了EDGE热点及重点保障区域,不建议全网开启。
5.专题小结
本专题通过对上行TBF扩展原理的介绍和相关实验数据的分析,验证了该功能对第三方测试指标有明显提升作用,并给出其中部分参数值的设置建议,相信对今后EGPRS的优化工作有一定的参考意义。
5.1.附录
●OMC-RParameters
HMIname
Definition
Sub-system
Instance
OMC-Raccess
Type
Defvalue
Range
Unit
EN_EXTENDED_UL_TBF
Flagtodisable/enabletheextendedTBFmodefeatureontheuplink
MFS
cell
Changeable
Flag
[0,1]
None
T_MAX_EXTENDED_UL
MaximumdurationoftheextendeduplinkTBFphase
Timer
2000
[100,4000]
ms
EN_FAST_USF_UL_EXTENDED
Flagtodisable/enablethetransmissionofUSFevery20msinextendedmode
BSS
1
T_EXTENDED_UL_TBF_POL
TocontroltheUSFschedulingontheuplinkwhenaTBFisinextendedTBFmode
None(DLS)
200
[120,500]
●MFSCounters
Counternumber
Name
Definition
P461
CUMULATED_ACT_EXT_UL_CONNECTION_TIME
CumulatedoveralltimeofULTBFconnections(inactivestateorextendedphase).
P462
NB_DUMMY_UL_BLOCKS
NumberofPacketUplinkDummyControlblocksreceivedontheradiointerface.Note:
ThiscounterappliestobothGPRSandEGPRSTBFs.