GPRS-DT测试性能优化

1、GPRS-D测T 试性能优化华为技术有限公司Huawei Technologies Co., Ltd.版权所有 侵权必究All rights reserved日期修订版本修改描述作者DateVersionDescriptionAuthor2008-1-20文档建立庄培灿 /谢红伟修订记录 Revision Record 1修订记录 Revision Record TOC o 1-5 h z HYPERLINK l bookmark6 o Current Document 修订记录 Revision Record 1 HYPERLINK l bookmark8 o Current Documen

2、t 背景 2 HYPERLINK l bookmark10 o Current Document 测试规范 2 HYPERLINK l bookmark12 o Current Document 测试软件及终端 2 HYPERLINK l bookmark14 o Current Document DT 部分 2 HYPERLINK l bookmark16 o Current Document DT-WAP 2 HYPERLINK l bookmark18 o Current Document DT-FTP 3 HYPERLINK l bookmark20 o Current Documen

3、t 覆盖率优化 4 HYPERLINK l bookmark22 o Current Document 掉线优化 4 HYPERLINK l bookmark24 o Current Document 下载速率优化 7 HYPERLINK l bookmark30 o Current Document FTP服务器优化 12 HYPERLINK l bookmark32 o Current Document 设置最优 MTU 值 12 HYPERLINK l bookmark34 o Current Document 关闭 Nagle算法 13 HYPERLINK l bookmark36 o

4、 Current Document 参数调整方法： 14背景GPRS 的DT测试是移动用于衡量 GPRS 网络质量的一个重要手段， 移动集团公司对各个 重点城市网络质量检查工作也包括 GPRS-DT 测试，此次在成都项目做了一些 GPRS 类的DT 优化工作，其中积累一些经验，在本文中做一个简单的总结。测试规范附件是集团公司下发的 GPRS业务测试规范， 这个规范对于全国的 GPRS业务优化非常具 有指导意义，这里不再重复引用规范的具体内容，后面在涉及到关键细节再进行阐述。测试软件及终端一般GPRS-DT使用的测试工具是北京惠捷朗公司的 CDS3.0+SAGEM OT290 手机，该工 具不支

5、持 EDGE功能，并且迎检只测试 GPRS性能。 SAGEM OT290 的多时隙能力为 3下行1 上行。测试软件和测试终端的特性和最终的测试性能密切相关， 详细内容将在后面具体介绍。DT 部分DT测试分两个大项， FTP下载和 WAP 类测试。DT-WAPWAP类测试使用“ CMWAP ”的 APN ，这类业务都必须经过一个关键的网元WAP-GW（WAP网关）， WAPGW 作为协议转换代理，其主要目的就是完成手机到网关之间的WAP协议到 HTTP协议转换。手机和 WAP网关的协议模式有两种： WAP1X 协议和 WAP2.0协议。 两者的不同在于承载协议， WAP1X 承载于 UDP ，W

6、AP2.0承载于 TCP。集团公司 2007年的网 络质量巡检基于 WAP1X 协议进行测试。图1 WAP 网关协议DT-WAP 测试包括 WAP 登录和图铃下载，其中图铃下载的速率在开通CS3/4编码的情况下，一般都能轻松达到。但 WAP 登录和图铃下载成功率对于小区的无线质量比较敏感，需 要保证各个小区的业务正常。 对于无线承载而言， WAP 和FTP优化基本一致， 相关的优化手 段请参考下面的 FTP优化介绍。需要注意的是， WAP 类测试需要临时关闭公司的一些信息安全软件，例如SPES、ACC和Sygate防火墙等。下表是集团定义的 WAP-DT 测试的健康指标：表1 WAP 类DT测

7、试健康指标WAP测试WAP网站登 陆成功率WAP首页显 示时间WAP网页刷 新成功率WAP网页刷 新时长WAP图铃下 载成功率WAP图铃下 载平均速 率99.50%8.5099.50%599.50%1.6DT-FTP下表是 DT-FTP 下载测试的考核指标在优化前后的对比情况， 主要有三个指标需要优化。 包括覆盖率、掉线次数和平均使用层吞吐率。表 2 优化前后 DT-FTP 下载效果对比DT 测试测试 时长 （分 钟）测试 里程 （公 里）速度 （ km/ h）FTP 测试无覆 盖里 程覆盖率尝试 下载 次数掉线 次数掉线率平均使 用层吞 吐率 （KB/s）集团优秀指标0100%002.806

8、年 12 月实测265.9133.430.120100%269003.35第一轮测试 1018349.6128.122.010100%93110.1182.01第二轮测试 1022438.0199.627.340100%218240.111.93第三次测试结果469.399.7%281145.00%2.28第四次测试结果222.489.524.10100%13642.90%2.21第五次测试结果291.999.5%168137.70%2.21优化后最终测试结果444.2191.625.880100%37700.00%3.02覆盖率优化覆盖率的要求

9、比较宽松，下面是判断无GPRS覆盖的判决条件。相对而言，覆盖率的控制较为容易，只需要保证小区的 GPRS属性正常。满足以下条件之一判别为 GPRS无覆盖里程：a. 服务小区电平低于 -94dbm 且最强的邻小区电平低于 -90dbm，并持续 5 秒钟以上的路段b. 手机的 TBF 处于关闭状态且超过 90 秒钟以上没有接收到 System Info13 的路段掉线优化FTP掉线的要求也相对比较宽松，判决条件如下。满足以下条件之一判别为掉线：a. 网络原因造成连接断开，以下行信令 PDP deactivate request 或 RAU reject 作为判断依据。b. 测试过程中超过 3 分钟

10、 FTP没有任何数据传输，且尝试 ping 后数据链路仍不可使用。此时应断开拨 号连接并重新拨号来恢复测试。有两种场景会导致 CDS软件判断 FTP下载掉线。1、 长时间无下载FTP下载使用 TCP 协议，在 TCP数据传输中，为了确保数据传输的准确性，采用 了确认机制：当发送端发送一个报文（IP包）时，启动重传定时器，如果定时器超时前收到接收端发送的该报文的 ACK 消息，那么复位重传定时器，否则重传没有收到 ACK 的报文，具体机制如下图所示：图2 TCP 报文确认机制由于 CDS软件采用单线程模式，在 DT测试中， FTP服务器发送的报文会由于 PCU 间的小区重选丢失，导致服务器一直等

11、不到接收端（测试终端）的 ACK 消息，一直等 待定时器超时， 而在无线环境下的 FTP业务，发送端计算的重发定时器值较长 （ 10s）， 并且呈几何指数增长，重传的时间太久；同时，接收端因为一直没有接受到服务器的 数据块，处于一直等待状态中，不会重复发送ACK 消息，向服务器请求报文，这就导致数据传输一直处于中断中。图3 长时间无数传导致 FTP 下载失败图4 CDS 软件无数传时 ping机制优化措施： 优化 FTP服务器参数配置，尽量规避这种问题，但无法根治这种问题。具体 见FTP服务器优化部分。个别路线上的小区有可能出现拥塞或者故障（CS业务正常，可以正常选入）的情况，这个时候手机选入

12、这类小区就会出现接入不了的情况，通常表现为长时间尝试ping而ping 不通，持续一段时间后超时掉线。优化措施： 保证路线上的小区各种业务正常，对于拥塞的小区增加 PDCH 信道或者调高 信道的复用深度。2、 RAU reject当出现 RAU reject 时，即判断为掉线。当网络中存在两个SGSN时，如果 DNS服务器的数据不准确，很容易出现这样的现象。图5 RAU 失败导致 FTP下载失败下图是跨 SGSN路由区更新时的信令流程，当 DNS的RAI 表信息不准确时，在流程 3那 返回错误的 SGSN IP ，导致 RAU reject 。图6 跨SGSN RAU 信令流程优化措施： 将D

13、NS服务器上的 RAI 和SGSN对应关系进行梳理。下载速率优化下图是 DT-FTP 下载速率优化的主要控制点，这些关键控制点之间并不是孤立的，为了 方便叙述，将这些控制点进行了分类，下面将对每个控制点进行阐述。图7 FTP 下载速率优化关键控制点App/RLC 速率比App/RLC 速率比即使用层速率和 RLC 层速率的比值。 这个指标反映了 Um口的质量。 Um口的质量主要受接收电平、 C/I 、上下行链路平衡的影响， Um口质量对 FTP 速率的 影响主要包括两个方面：一个是编码方式，另一个是空口重传率。编码方式越高， Um 口单信道的吞吐率就越高， Um口质量越好，系统就会使用更高的编

14、码方式，FTP 的吞吐率就越高； 重传率越高， 说明实际的有效吞吐率越低， 空口的带宽都用在了无效的重 传上， Um 口质量越好，其重传率就越低，有效的吞吐率就越高。需要注意的是， 如果测试用的便携机系统没有关闭 windows 自动更新等自动连接网 络的系统进程时， App/RLC 速率比也会比较低。这从 CDS 的网络协议查看器可以比较 方便的检查出来。优化措施：频率优化PDCH 信道配置在载干比较好的载频上，一般是 BCCH 载频PDCH 所在载频不参加跳频 处理上下行不平衡小区 关闭测试使用便携机的无关系统进程， 包括不限于 windows 自动更新、 病毒库更新图8 CDS 数据协议

15、察看器界面占用 PDCH信道数CDS配置测试 GPRS 的是OT290 手机，多时隙能力等级为 4，即支持 3下行 1上行。 从测试数据回放看， 在某些小区，手机一直没有指配三个信道，导致速率一直不高。通 过分析配置可以发现， 这些小区的信道配置都是较少， 或者语音业务量较大， 抢占了动 态PDCH 。优化措施：增加 PDCH 信道数目，信道需要连续分配针对 OT290 手机的多时隙能力，将信道进行分组配置，尽量3 个一组，不同PDCH 组之间间隔一个 TCH 或者 SDCCH对于话统中存在 BSC 回收动态 PDCH 信道次数较多的小区， 可以考虑在测试前 临时配置静态 PDCH 信道CS4

16、使用比例CS4编码方式在测试中使用的比例是影响速率的关键因素。CS4编码方式在测试中的主要受两个方面影响。一个是 C/I ，即重传率，二是基站的空闲时隙配置和 RPPU板的 PCIC资源。优化措施：关闭部分小区的 EDGE 功能，减少 PDCH 信道对空闲时隙和 PCIC 资源的消耗 配置足够的空闲时隙(有副柜组的要分柜组分别配置)，均衡各个 RPPU 单板 的PCIC 负荷每条信道预绑定两条 PCIC ( g_ulPreConnectPcicNum )，使下行接入尽快使用 CS4 的编码方式，命令： pcu cfg add allrppu g_ulPreConnectPcicNum 4 2

17、无线环境好的小区下行编码方式缺省设置为 CS4 无线环境优化避免下载断续比较容易造成丢包的环FTP下载通路上的各个接口和网元都可能会导致下载断续。节在跨 RPPU板小区重选、跨 PCU小区重选和 FTP服务器和 GGSN 之间的 Gi接口。 跨RPPU板小区重选时，在 PCU版本为 R08C01B014SPH002 时，板间转发会存在丢 包现象，需要升级为 R08C01B014SPH007 。跨PCU小区重选是指小区重选前后的 PCU不一致， 这种情况下， 在原 PCU缓存的数 据将被丢弃，新的 PCU 重新到 SGSN获取数据，这种丢包是不可避免的，只能尽量减少 跨PCU小区重选的发生次数。

18、GGSN 和FTP之间传输如果不稳定，可能会导致 IP层丢包。判断方法可以在 GGSN 上ping FTP服务器， ping 1000次，包大小为 500字节。如果返回的统计有明显丢包时， 则需要对这之间的数通设备进行处理。图9 FTP 下载测试涉及网元及接口优化措施：优化 FTP 服务器设置避免核心网网元接口之间丢包确认 PCU版本不存在 RPPU 板转发丢包问题尽量减少跨 PCU 的小区重选次数下行 TBF Open 比例下行TBF Open比例是指测试过程中，手机处于下行TBF建立时间占所有测试时间的比例。 FTP下载速率是按照总下载数据量 /总下载时间来计算的。 如果一次下载过程中 发

19、生小区重选等行为，将会导致总下载时间变长，最终影响下载速率统计。影响下行 TBF Open比例的主要有小区重选、 位置区路由区更新 （LAU RAU ）。 数据业务测试中，小区重选必然会导致数据传输中断。因为测试手机不支持 NACC 等EGPRS的优化功能， 每次小区重选固定需要 4s以上的时间来对新小区的系统消息进行 解码，才能进行接入请求，如果碰到路由区，位置区更新，会浪费更多的时间。所以减 少小区重选的次数是提高 DT 速率关键手段之一。LAU+RAU 更新的时间开销一般为 10s左右，因此避免在路测过程中发生频繁的跨位置区重选是一个优化手段。优化措施：减少小区重选次数（合理控制小区重选

20、，通过合理设置相关重选参数及 BA1 表合理配置来实现） 减少跨 LAC 小区重选次数传输质量各环节比较容易出问题的在于 G-Abis 口。G_Abis 口包括了 Pb 接口、BSC 内部通道、 Abis 接口以及 BTS 的内部通道，这些通道中任何一段出现问题都会导致G_Abis 口链路出现问题最终导致 FTP速率受到影响甚至业务不能正常进行。造成G_Abis 口链路出现问题的主要原因有： 1）工程质量（连线错误或传输接头松动）， 2）传输质量问题（例 如某些小区的 Abis 口传输为卫星链路或者微波链路） 3）基站存在自环或者故障的 Abis 口2M传输。需要根据具体现象逐步排查定位问题。

21、对于第三种原因， 可以通过关闭小区的 EDGE 和 CS3/4 功能， 使小区的 PDCH 只使 用一条Abis的16k时隙，再观察小区的 G-Abis 口误帧率情况，如果有所缓解和消失，则 比较大的可能是由于故障 2M 引入的误码。优化措施：排查基站的 2M 是否存在自环、故障现象。上述的关键控制点中， 部分可以映射为关键控制指标， 各关键控制指标在优化前后的对 比情况如下表所示。表 3 各关键控制指标在优化前后的对比情况测试文 件结果空口质量下载状 态Um口 资源Pb资源（ 编码使用比例)修正系数FTP下 载速 率App/RLC速率比TBFOPEN比 例下行平 均时隙 数量CS1比 例CS

22、2比 例CS3比 例CS4比 例修正 系数 （复 用、重 选恢 复开 销）整网摸 底2.1375%82%2.659.00%26.00%8.00%57.00%59%二环11082.5874%83%2.6421.00%12.00%6.00%62.00%72%草金2.6889%83%2.70721.00%19.00%7.00%53.00%64%1108草金1113am2.2172%61%2.6527.00%18.00%8.00%47.00%94%草金1113pm1.6761%73%2.58520.00%11.00%9.00%60.00%66%一环11243.5993%89%2.9375.60%18.

23、50%6.10%69.70%63%二环11243.4696%84%2.9158.80%7.20%7.30%76.70%61%注：1、 经验公式： FTP下载速率下行平均时隙数量 *（CS1比例*CS1 速率+CS2比例*CS2速率+CS3比例 *CS3速率+CS4比例*CS4速率）/8*TBF OPEN 比例*修正系数（复用、重选恢复开销）*App/RLC速率 比2、上述指标中，除修正系数外，其余从 CDS测试软件可以直接统计生成3、修正系数是经验值，和复用、重选后速率恢复相关FTP 服务器优化对于 DT下载，属于端到端的业务，因此，作为数据发送端的FTP服务器的优化也是提升性能的一个重要因素

24、。 这在成都测试中， 使用WINDOWS Server 2000 作为操作系统， Serv-u 作为 FTP服务器软件，针对这个 FTP服务器做了一些优化措施，这里重点介绍两个比较关键 的参数：设置最优 MTU 值MTU（ MaximumT ransmission Unit ）是指最大传输单元决定了下发数据包的大小（。如 果MTU 值过小，那么会在网络中进行频繁的封包和解包，会造成网络侧的延时；同样，如 果值太大，会在网络中进行拆分重组，同样会造成网络侧的延时。该参数的最优设置需要综合考虑 GGSN 的最大 TCP报文长度和 GGSN 和 SGSN数据封装 特性。 1500是 GGSN 和网关

25、等数通产品支持的最大包大小，但由于Ftp Server 下发的数据包送到 GGSN时，GGS将N会对其进行 GTP的封装然后转发给 SGSN，GTP封装将在 IP包上加上 40bytes 的包头，因此 FTP服务器下发包的最优长度为 1460（有效 TCP载荷1420Byte ），在经过 GGSN 进行 GTP封装后，刚好为 1500，这样可以直接通过各个数通产品而不需要进行拆包。Data1500bytesGGSN1460bytesFTP图10 GGSN 和SGSN 的GTP封装机制关闭 Nagle 算法目前建立在 TCP协议上的网络协议特别多，有 telnet ，ssh ，有ftp ，有ht

26、tp 等等。这些 协议又可以根据数据吞吐量来大致分成两大类：(1) 交互数据类型，例如 telet ，ssh ，这种类型的协议在大多数情况下只是做小流量的数据交换， 比如说按一下键盘， 回显一些文字等 等。 (2) 数 据成块类型，例如 ftp ，这种类型的协议要求 TCP能尽量的运载数据，把数据的 吞吐量做到最大，并尽可能的提高效率。针对这两种情况，TCP 给出了两种不 同的策略来进行数据传输。对于交互性要求比较高的使用， TCP 给出两个策略来提高发送效率和减低网络负担： (1)捎带 ACK 。(2)Nagle 算法(一次尽量多的发数据)。通常，在网络速度很快的情况 下，比如进行 teln

27、et 通信，当按下字母键并要求回显的时候，客户端和服务器将经历 发送 按键数据 -服务器发送按键数据的 ack - 服务器端发送回显数据 - 客户端发送回显数据 的ACK 的过程，而其中的数据流量将是 40bit + 41bit+41bit+40bit = 162bit，如果在广域网里面，这种小分组的 TCP 流量将会造成很大的网络负担。上过bbs 的人应该都会有感受，就是在网络慢的时候发贴，有时键入一串字符串以后， 经过一段时间，客户端 “发疯 ”一样突然回显出很多内容，就好像数据一下子传过来了一样， 这就是 Nagle 算法的作用。很显然， 对于 FTP类型的使用， 应该禁用 Nagle 算法。尤其在 DT测试的场景下， 跨PCU 的小区重选会导致数据丢失，在这种情况下，如果FTP 服务器下发数据不及时，会导致长时间无下载，空口的利用率低下，影响下载速率。Serv-U 安装后默认采用 Nag