《金华edge上行tbf扩展专题报告》由会员分享，可在线阅读，更多相关《金华edge上行tbf扩展专题报告（15页珍藏版）》请在金锄头文库上搜索。
1、卡特上行 TBF 扩展1. 概述随着数据业务资费的不断下降，金华的数据业务流量存在明显的增长趋势，为了提高用户的感知度及满足第三方考核的需要，金华城区开启了上行 TBF 扩展功能，开启该功能后部分测试项的指标明显改善。但是该功能缺少相关理论和实验数据的支撑，所以本文通过对上行 TBF 扩展原理的介绍和相关实验数据的分析，归纳出该功能的使用流程及意义，为今后的 EGPRS 网络优化工作提供参考作用。2. 理论简介Alcatel B9 版后系统新增了上行 TBF 扩展功能，该功能通过延长已建立的上行 TBF 来传输新的数据，减少了上行 TBF 的重建次数，加快了下一次上行TBF 的接入时间。2.1
2、.上行 TBF 扩展原理和一般的上行 TBF 延迟释放相比，扩展的上行模式下增加了最大上行 TBF延时时间 T_MAX_EXTENDED_UL，如下图所示：上行 TBF 扩展功能通过增加 T_MAX_EXTENDED_UL 时间，延长了 UL TBF 以下操作的时间： 在倒数记秒程序开始以后，如果 MS 中的较高层传递新的数据，则快速重启 UL 中的数据传输，而不用重建一个新的 UL TBF； 在最后模块通过网络确认以后，维持已创建的 UL TBF 状态。具体流程见下图：手机接收到最后一个 UL LLC PDU 时就开始了倒数记秒程序。当 BSS 收到最后一个 RLC block（ CV0）时
3、，上报 RRM 它接收到的是 TBF 的最后一个 UL LLC PDU，同时向 MS 发送分组 UL Ack/Nack 消息。此时 BSS 启动计时器 T_MAX_EXTENDED_UL 监控扩展模式下最大持续时间，在这期间 BSS下发 USF 调度命令，同时 MS 上发 Dummy block 予以响应，上行 TBF 始终保持激活状态。当 T_MAX_EXTENDED_UL 超时，MS 确认最后一次收到的PACKET UL Ack/nack 消息后上报 BSS 分组控制确认， UL TBF 将被释放。下 行 延 时 特 性 下 的 数 据 交 互 过 程典ULDL下 行 延 时 释 放 &
4、扩 展 上 行TBF的 模扩 展 的 上 行 TBF 模 式2.2.USF 调度原理USF 调度原理如下图所示：在扩展模式下BSS下发USF调度命令，同时MS上发Dummy block予以响应。直到MS上发的不是Dummy block而是RLC Block，而在这之前上行TBF始终保持激活状态。在 UL TBF 扩展模式下调度 USF 的方式： EN_FAST_USF_UL_EXTENDEDDisableT_EXTENDED_UL_TBF_POL (200 ms)用于为所有扩展模式下的MS调度USF。 EN_FAST_USF_UL_EXTENDEDEnablePACCH上处于扩展模式的MS ：
5、每20ms USF调度一次PACCH上处于扩展模式的2个MS：每40ms USF调度一次PACCH上处于扩展模式的n个MS：每n x 20ms USF调度一次2.3.硬件支持要求实现上行TBF扩展功能，运行环境必须满足以下几个条件： OMCR 上的 GPRS 参数 EN_EXTENDED_UL_TBF = enabled； BSS 必须确定 MS 是否支持这个功能，可以通过 GERAN Feature Package 1 字段值来是否为 support 来确认。该字段可通过 GSM 层 3信令 Classmark Change 中的 Classmark 3 IE 获取，或 Attach Acc
6、ept、Activate PDP context accept 和 Routing area update accept消息中获取，如下图所示： 必须是Rel-4 的MS2.4.手机版本支持情况目前测试用的 SAGEM 490/498 手机要实现支持上行 TBF 扩展功能，必须将手机版本设为 Release 4 模式，具体设置路径为：Test toolInfos & settings Release Release 42.5.现网渗透率情况（2008 年统计）为了了解现网手机对该功能的支持情况，对金华市区（BSC002CX）/义乌市区（BSC201CX ）/义乌郊区（BSC229NG ）进行了
7、 Gb 口跟踪进行渗透率评估。方法如下：1】 过滤 Attach Accept、Activate PDP context accept 和 Routing area update accept 信令2】 同时过滤出以上三条信令的 IMSI 和 GERAN Feature 指示并导成 Excel3】 对重复的 IMSI 进行过滤，来确定唯一的手机用户，即全网支持数据业务的手机数4】 过滤出 GERAN Feature 指示中为 Support 消息的用户数，即为支持上行扩展功能的手机数5】 以上两步相除即为上行扩展 TBF 功能手机渗透率注：其中 GERAN Feature 必须是在 R99 字
8、段内的消息内容下表为三个 BSC 统计的渗透率结果，可以看出金华现网支持上行扩展 TBF的手机数很少，基本维持在市区 15左右，而郊区仅为 7%。BSC Name 手机总数 支持上行 TBF扩展功能手机数 渗透率BSC002CX（金华市区）9569 1359 14.20%BSC201CX（义乌市区）10147 2318 16.86%BSC229NG（义乌郊区）4390 343 7.81%注：GERAN Feature 即代表是否支持上行 TBF 扩展功能。3. 现场测试对比分析3.1.上行 TBF 扩展时延分析上行 TBF 扩展功能体现在上行 TBF 的延迟释放，由此来加快下一次上行TBF 的
9、接入。上行 TBF 延迟的时间是可以在 OMCR 上进行设置，如果设置不合理，如：设置过长就会造成无线资源的浪费。所以本节将以第三方测试的测试项为主，通过测试项的上行 TBF 的接入时延的分析，来确定合理的上行 TBF时延的设置。3.2.Attach 信令时延分析Attach 测试的规范定义如下，Start：Attach Request，End：Attach Accept。因为金华地区的核心网是在每次附着过程中进行鉴权，所以在此过程中总共会涉及到两次上行 TBF 的建立，分别为 Attach Request 和Authentication and Ciphering response。下表为
10、Attach 过程中在上行 TBF 扩展参数开启和关闭后每条信令之间的时延分布。从中可以看出，在该功能开启的情况下，第二条上行信令（Authentication and Ciphering response）的传输时间损耗明显小于功能关闭，这就是因为该条信令无需建立上行 TBF 而是延用了 Attach Request 信令所建立的上行 TBF。下表统计了在 Attach 过程中两次上行信令： Attach Request 和Authentication and Ciphering response 建立的时延基本是在 1.1 秒左右。注：以上的时延分析扣除了上行 TBF 的建立时间。3.3.
11、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 响应阶段涉及到四次
12、上行 TBF 的建立，分别包括两次用于 WAP网址定向的 Get 消息，以及两次对下行 Reply 消息响应的 Ack 消息，并且这四次上行 TBF 的建立分别可以延用上一次上行 TBF 所建立的 TBF，因而节省了上行 TBF 建立的时间。下表统计了在 WAP 首页显示过程中五次上行 TBF 建立之间的时延情况，可以看出来时延基本分布在 300 毫秒1.4 秒之间。注：以上的时延分析扣除了上行 TBF 的建立时间。对于 WAP 页面刷新的测试项基本和 WAP 首页显示类似，这里不再赘述。3.4.WAP 图铃下载信令时延分析做一次 WAP 图铃下载（100K）时，在 Get 信令之后，会连续有
13、 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
14、_EXTENDED_UL_TBF=Enable由于单位大小的文件下载时间的减少，WAP 下载速率也相应提高，100Kbyte 大小图铃文件下载时间如下图所示：EN_EXTENDED_UL_TBF 下载速率（Kbytes/s) 下载时间(s)Disable 6.32 15.82Enable 9.25 10.81EN_EXTENDED_UL_TBF 的开启减少了分包传输共 15 次的上行 TBF 建立时间约 4.5s 左右，和上表中两次下载的时间差值相吻合。3.5.测试对比结果我们列出了每种业务两次上行 TBF 建立的时间间隔，如下表：项目 TBF 再次建立间隔时间EDGE attach 平均时间
15、 1.1sWAP 平均首页显示时间 0.3-1.4sWAP 下载速率 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 建立时上一次的上行 TB
16、F 已经释放掉了，上行 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_EXTENDEDDisable时，在扩展模式下BSS下发的USF调度命令每200ms 调度一次；EN_FAST_USF_UL_EXTENDEDEnable时，一个MS每20ms USF调度一次，两个MS每40ms USF调度一次，依次类推。在扩展模式下EN_FAST_USF_UL_EXTENDED Disable，当有上
