PS业务FTP问题指导手册.doc

内部公开PS业务 FTP下载问题指导手册1 概述TD外场应用中，FTP下载做为PS业务的最常见的应用，在开通阶段通常用来做为衡量系统PS业务是否工作正常的手段。FTP属于应用层范畴，传输层采用TCP，在UTRAN中，通常采用I类业务来承载，链路层采用RLC AM模式发送数据。由于无线应用场景和有线网络环境存在时延、链路稳定性各方面的差异，因此，无线应用场景下FTP业务出现的问题要比有线网络复杂，但基本的分析思路应该是一致的，那就是通过网络分层结构分析排除各个层次可能存在的问题。2 FTP业务数据流向其中，RIBP就是Iub接口处理板，可能是APBE，也可能是SDTB+IMAB，RDMP就是用户面协议处理单板（VTCD），RIPP是IuPS接口处理板，UIM用于资源框内各单板间IP通信。3 TCP性能评估FTP下载采用TCP传输，FTP下载终端采用的操作系统软件各不相同，有Windows，WINNT、Windows XP等，对应的TCP协议实现可能也会存在差异。众所周知，TCP实体使用的基本协议是滑动窗口协议，当发送方传送一个数据段的时候，它会启动一个定时器，当该数据段到达目标端的时候，接收方的TCP实体回送一个携带了确认号的数据段（如果有数据要发送的话，包含数据，否则就是一个空包，不包含数据），其中确认号的数值等于接收方期望接收的下一个序列号。如果发送方的定时器在定时器到达之前超时，则发送方再次重传原来的数据。FTP在建立TCP连接的时候，发送方会给出TCP的MSSMSS含义为最大分段，这个值TCP协议在实现的时候往往用MTU值代替（需要减去IP数据包包头的大小20Bytes和TCP数据段的包头20Bytes）所以往往MSS为1460大小，对于笔记本电脑环境，MSS为1260字节（台式机为1460）。也就是说，每次发送方发送的最大TCP数据段为1260字节。从性能的角度考虑，TCP接收方的窗口必须至少与带宽、延迟之乘积一样大，最好比该乘积值还要大一点，因为接收方可能并不立刻就做出响应。对于PS384K业务，一次IP包的RTT往返传输时间为400ms，单向按200ms计算，FTP为非对称业务，ACK包比较小，相应的传输时延也比较小一点。接收方窗口为384Kbps*200ms/8 = 9600BYTE，基本上应该可以保证TCP传输性能，可以缓冲7包数据。（9600/1260 约为7包）Windows XP操作系统，默认的TcpWindowSize为8760BYTE，可以查看一下注册表中的TCPIP参数配置，如果曾经配置过参数TcpWIndowSize，并且设置的数值比较小，影响发送方滑动窗口的移动，对TCP的性能还是有影响的。打开相关注注册表项：HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpip4 如何定位问题？在这里讨论的问题前提是静止状态下UE的PS业务FTP效果，移动过程中的FTP效果主要取决于移动线路无线条件、外环功控等因素。4.1 PING包是否正常？在进行FTP下载出现问题的时候，可以先尝试PING包，看看FTP下载对应的IP通路是否正常？Windows带的PING程序，默认的数据载荷大小为32字节，对应的IP包大小为32+20(IP头)8（ICMP头）60BYTE。而实际FTP下载时，对应的IP包大小为1300（1260+IP头20TCP头20），因此可以考虑更改PING包的大小，尝试PING大小为1272字节左右的包，看是否正常？PS ping包不通的原因很多，这里要介绍的ping包不通的前提条件是前面的路由配置、ATM配置和NO7配置都是正确的，也就是保证RNC与CN之间的数据通道是通的，可以通过一个简单的方法来判断，PDP激活后，暂时不要立即进行ping 包，使用“showrgupstat”查看RGUP板上的“模块统计信息”中“GTPU消息包数”，如果上下行方向的GTPU消息包数相同，则说明RNC与CN之间是通的；如果只有上行方向的消息包，下行方向没有消息包，则说明RNC与CN之间不通，需要逐步查看接口板RIPP和CN侧的统计来确定问题。这个方法的思路是在PDP激活后，RNC侧的GTPU层会和CN侧SGSN上的GTPU层进行路径不活性检测，也就是互相发送路径检测消息包。4.2 TCP接收窗口大小的影响FTP下载时，表现出一种现象，FTP下载速率到达某一个值之后，不能再上升，与签约的PS业务下载速率相距甚远。比如，无线信道质量很好，签约速率下行384K，但FTP下载时，显示的速率只有70K左右。根据TCP的慢启动算法，当一个连接被建立起来的时候，发送方将拥塞窗口初始化为该连接上当前使用的最大数据段长度。也就是刚开始只发送一个数据段，然后，以数据段的倍速递增，直至发生超时，或达到接收方窗口的大小。因此如果接收窗设置过小，发送方总是处于停等状态，肯定会影响TCP链路的吞吐性能。这种情况下，检查一下笔记本的注册表。HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters下的TcpWindowSize。可以把它设置为最大值65535试试。4.3 客户端软件的影响有些客户端软件，比如FlashFXP，其下载的包大小可以进行配置，因此，这里也可能存在一个分片问题，假设TCP的PDU按1260发送，如果上层指定数据包大小，并且不是1260的整数倍，那么肯定最后一包数据不会满包发送。从应用层的流量统计来看，就会出现非常有规律的掉沟现象。比如4096字节的包，最后一包将只有316字节。这种情况，可以通过更换客户端下载软件或修改上层数据包大小来避免。4.4 多线程的影响目前常用的FTP下载工具Flashget、FlashFXP、CuteFTP Pro等都具备多线程能力，多线程本质上不会提高FTP的下载能力，因为一般而言，CPU的处理能力远远高于TCP链路的吞吐能力，多线程的优势体现在当无线信道质量不好时，利用多条线路的同时接收可以平滑掉单条链路TCP窗口移动带来的影响。4.5 其它可能的原因在无线网络环境下，影响FTP性能的主要因素时无线信道质量导致的丢包，因为TCP是可靠传输，IP包分拆成RLC PDU传送时，RLC的重传会影响到接收方IP包的组装。导致时延加大，如果时延超过了TCP包重传的时延，将导致TCP包重传。因此，主要应该从无线信道质量上来判断查找原因。1) 上行质量是否良好。可以在nodeb调试机使用命令看上行crci错误是否过多；也可以在rnc侧使用命令ShowDfpDetailStat看crci err字段的值；或者直接使用ShowRlcDetailStat，如果Up Process Error有数值，再使用命令ShowRlcErrCode(DWORD DspNo,7)，用后面的数值除以上行逻辑信道数值得出一个百分比。如下图所示：上图中则用1/251*100%=0.3%。如果这个百分比大于10%，表明上行质量不好。2) 下行质量是否良好。下行crci错误RNC和NodeB都没办法看，可以通过rlc的重传估算下行质量，如图所示：重传Pdu比上逻辑信道中的Pdu，百分比不能大于5%。3) 查看PDCP和RLC缓冲区是否满。下面红线部分有增加，说明PDCP缓冲区满。RLC缓冲区可以通过VTCD后台打印察看，如：2005-12-8 10:42:11 模块:RNLU_RLC - DSP12:RLC:HMSG: Rlc -2131071696 VR_R = 2450 VR_H = 2450 VR_MR = 2706 : VT_A = 1014 VT_S = 1040 VT_MS = 1270如果VT_S = =VT_MS 表明RLC缓冲区满了。这时候需要在后台将RLC窗口开大。后台修改参数如下图：RNC发送窗口UE接收窗口4) 是否发过或者收到Reset包。Reset包会将缓冲区中的数据清除，重新开始数据传输。可以从用户面RLC详细统计中察看（ShowRlcDetailStat），或者在后台打印中搜索reset，看是否发过复位命令。RLc统计如下：网络侧发复位包根据打印可以看出异常原因。5 常用工具及其它注意事项为了避免各种不同的工具以及应用软件对问题的定位分析带来影响，建议测试用的电脑以及相关的应用软件的配置都已经在某一