金华EDGE上行TBF扩展专题报告.docx
《金华EDGE上行TBF扩展专题报告.docx》由会员分享，可在线阅读，更多相关《金华EDGE上行TBF扩展专题报告.docx（16页珍藏版）》请在冰点文库上搜索。
金华EDGE上行TBF扩展专题报告
卡特上行TBF扩展
1.概述
随着数据业务资费的不断下降，金华的数据业务流量存在明显的增长趋势，为了提高用户的感知度及满足第三方考核的需要，金华城区开启了上行TBF扩展功能，开启该功能后部分测试项的指标明显改善。
但是该功能缺少相关理论和实验数据的支撑，所以本文通过对上行TBF扩展原理的介绍和相关实验数据的分析，归纳出该功能的使用流程及意义，为今后的EGPRS网络优化工作提供参考作用。
2.理论简介
AlcatelB9版后系统新增了上行TBF扩展功能，该功能通过延长已建立的上行TBF来传输新的数据，减少了上行TBF的重建次数，加快了下一次上行TBF的接入时间。
2.1.上行TBF扩展原理
和一般的上行TBF延迟释放相比，扩展的上行模式下增加了最大上行TBF延时时间T_MAX_EXTENDED_UL，如下图所示：
上行TBF扩展功能通过增加T_MAX_EXTENDED_UL时间，延长了ULTBF以下操作的时间：
●在倒数记秒程序开始以后，如果MS中的较高层传递新的数据，则快速重启UL中的数据传输，而不用重建一个新的ULTBF；
●在最后模块通过网络确认以后，维持已创建的ULTBF状态。
具体流程见下图：
手机接收到最后一个ULLLCPDU时就开始了倒数记秒程序。
当BSS收到最后一个RLCblock（CV＝0）时，上报RRM它接收到的是TBF的最后一个ULLLCPDU，同时向MS发送分组ULAck/Nack消息。
此时BSS启动计时器T_MAX_EXTENDED_UL监控扩展模式下最大持续时间，在这期间BSS下发USF调度命令，同时MS上发Dummyblock予以响应，上行TBF始终保持激活状态。
当T_MAX_EXTENDED_UL超时，MS确认最后一次收到的PACKETULAck/nack消息后上报BSS分组控制确认，ULTBF将被释放。
2.2.USF调度原理
USF调度原理如下图所示：
在扩展模式下BSS下发USF调度命令，同时MS上发Dummyblock予以响应。
直到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秒之间。
注：
以上的时延分析扣除了上行TBF的建立时间。
对于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
[0,1]
None
T_MAX_EXTENDED_UL
MaximumdurationoftheextendeduplinkTBFphase
MFS
cell
Changeable
Timer
2000
[100,4000]
ms
EN_FAST_USF_UL_EXTENDED
Flagtodisable/enablethetransmissionofUSFevery20msinextendedmode
MFS
BSS
Changeable
Flag
1
[0,1]
None
T_EXTENDED_UL_TBF_POL
TocontroltheUSFschedulingontheuplinkwhenaTBFisinextendedTBFmode
MFS
MFS
None（DLS）
Timer
200
[120,500]
ms
●MFSCounters
Counternumber
Name
Definition
P461
CUMULATED_ACT_EXT_UL_CONNECTION_TIME
CumulatedoveralltimeofULTBFconnections（inactivestateorextendedphase）.
P462
NB_DUMMY_UL_BLOCKS
NumberofPacketUplinkDummyControlblocksreceivedontheradiointerface.Note:
ThiscounterappliestobothGPRSandEGPRSTBFs.
升级会员 