51学通信技术论坛

标题: SNDCP层数据包分段及重组功能实例详解 [打印本页]

作者: 爱卫生 时间: 2011-5-15 19:17:01 标题: SNDCP层数据包分段及重组功能实例详解

本帖最后由爱卫生于 2012-4-11 22:23 编辑

在GSM和EDGE的接入环境下，SNDCP的功能其中之一就是对上层用户送过来的payload（站在SNDCP层角度，这个payload叫做N-PDU）进行分段，发送给对端SNDCP层实体还需要进行重组。这主要是因为N-PDU可能比较大，例如一张图片，一个小视频，是不可能一个包就传完的。因此需要进行分段切割成很多小包后再发送，另外为了能够正确的重组，还应设置序列号来进行标识。这个功能和IP网络中，网络层根据MTU进行分片的原理是基本类似的。实现了类似的功能。
在这个实例中，我们就来看一下SNDCP的分段功能是怎样实现的。
一共有5个包。#1到#5。MS的IP为10.150.198.170。
1 在#1包中，可以看到目的地址是10.0.0.172。这是WAP网关的地址，所以基本可以判定这个一个基于WAP的APN。通过http层可以发现，实际请求的uri是http://119.147.17.19。请求的是一个gif图片。
来看一下MS的封装顺序，
1）首先是HTTP报头，232字节，包括get请求等HTTP语言格式。交给TCP层处理。
2）TCP为20个字节。再加上可选项部分12个字节，共32个字节。交给IP层处理。
3）IP层为20个字节。（无可选项部分）。
以上就是N-PDU的大小，共计284个字节。这时，作为上层用户，要使用SNDCP层的服务，则需要使用原语进行对SNDCP层功能的调用。根据TS44.065 SNDCP的规范，并且在MS中采用的是未确认模式（特点是快，确认模式和非确认模式的区别有点类似TCP和UDP的区别），所以这个上层用户（272字节）会调用SN UNITDATA.request去要求SNDCP为这种非确认模式报文提供传输服务（SN UNITDATA.request Request used by the SNDCP user for unacknowledged transmission of N PDU. ）。
  SNDCP层收到后，知道上层有这样的需求，就开始工作了。该干什么干什么。
  4）根据规范，SNDCP层执行N-PDU分段的依据是N201（这个值是需要通过XID流程协商出来的），具体来说，针对非确认模式，要根据N201-U来进行分段。（A (possibly compressed) N PDU shall be segmented into one or more SN PDUs. The length of each SN PDU shall not be greater than N201-I (for acknowledged mode) or N201-U (for unacknowledged mode).）。
  这个协商的流程没有抓到，但根据后续分片的结果，我们其实可以看到这个N201-U实际上是500字节。在#2和#3中有描述。
  来看一下SNDCP层的各个bit：
  More bit：为0，代表这个#1这个包是最后一个包。后续没有了。（实际上隐含告诉我们这个包没有被分段）。
  First segment indicator bit：为1，代表这个是第1个。同时More bit也为0.就说明这个包既是第一个也是最后一个，其实就是没分片。
  Type bit: 为1.代表SN-UNITDATA PDU。代表这是一个SNDCP层的非确认模式的PDU数据包。
  NSAPI: 为5.建立了和上层用户之间的关联。即和某一个PDP上下文建立了关联。
  N-PDU ：为40.唯一的标识这个PDU。（主要用于PDU的重组，后面会提到）。
  5）然后再交给LLC层去处理。在本帖中就不讲述了。我们只关注SNDCP的分段功能。

2 在#2中，10.0.0.172这个WAP网关开始响应MS的请求，是一个TCP的确认报文。通过查看TCP的flag就可以看出来，ACK flag被置1了。真正的payload是在#3才开始传送的。

3 在#3中，WAP网关开始将请求的gif图片转发给手机。但这个图片其实超过了N201-U的大小，需要进行分段处理。怎么分段的呢？我们来看一下SNDCP的各个字段。
  More bit：为1，代表这个#3这个包不是最后一个包。后续还有。（实际上隐含告诉我们这个包已经被分段处理）。
  First segment indicator bit：为1，代表这个是第1个。
  N-PDU ：为38.唯一的标识这个PDU。
  Segment:等于0. 这个代表#3这个包是N-PDU为38的这个N-PDU，经过分段后的，第一个分段报文。需要把后续的都收集了就可以进行重组。
  SNDCP的上层是496个字节。但这个其实不是N201-U。因为N201-U指的是LLC-PDU的大小，也就是LLC上层所有的协议+payload的大小，当然也包括SNDCP。所以这里，实际上N201-U的大小应该是500个字节。可以鼠标点击SNDCP层，然后在wireshark最下方，可以看到SNDCP层及以上是500字节。

4 在#4中，看下SNDCP层的各个bit的变化。
F bit：为0.代表不是第一个分段包。
M bit：为1，代表这不是最后一个，后面还有。
N-PDU：为38.和#3的N-PDU相同。代表#3和#4是同一个N-PDU进行分段后得到的两个报文。
Segment：为1.代表这是N-PDU为38的N-PDU分段后的第2个报文。
同时看下SNDCP层的大小，也是500字节，实际上#4也是按照N201-U为500个字节来进行分段的。

5 在#5中，看下SNDCP层的各个bit的变化。
F bit：为0.代表不是第一个分段包。
M bit：为0，代表#5这就是最后一个了，后面没有啦。
N-PDU：为38.和#3和#4的N-PDU相同。代表#3和#4和#5是同一个N-PDU进行分段后得到的三个报文。
Segment：为2.代表这是N-PDU为38的N-PDU分段后的第3个报文。
最后一个报文只有486个字节（同样是点击SNDCP层查看最下方）。所以比N201-U小，不需要分片。
这时候交给手机进行重组就可以了。重组也很简单，有NSAPI对应到相应的PDP上下文。然后N-PDU为38对应#3/#4/#5，分段为0，1和2。这样在SNDCP层重组完成以后，就可以交给上层IP层来处理了。

附件请用wireshark打开。[attach]383[/attach]

作者: tobino1 时间: 2011-5-31 17:21:35

附件是.RF5文件，用recording viewer打不开，用wireshark打开只要no和time ，protocol和info看不到啊

作者: 爱卫生 时间: 2011-5-31 18:54:05

回复 tobino1 的帖子

应该可以啊。如下截图：

[attach]418[/attach]

我用的是Wireshark 1.4.6版本。要不去Wireshark官网下载一个试下？

作者: 爱卫生 时间: 2011-6-5 14:48:53

tobino1 发表于 2011-5-31 17:21
附件是.RF5文件，用recording viewer打不开，用wireshark打开只要no和time ，protocol和info看不到啊

呵呵，tobino1,不好意思啊。今天用了另外一台电脑上。打开这个文件果然是打不开。现说明下解决方案。因为是用的仪器抓的帧中继接口的包，非IP的。到Wireshark上显示的话，需要经过一定设置才可以打开。
分两步：
1 参照Wireshark关于K12抓包文件设置说明来设置好wireshark。具体是在“Edit”菜单中选择Preferences->Protocols->k12xx 。再点Edit，加入一个描述。matching 填gprs_gb，protocol填fr。
2 接第一步，不要关窗口。选择Preferences->Protocols->FR,在右边的Encapsulation中选择“GPRS Network Service”就可以解码了。默认的话，Wireshark将认为你这个包是数据网络中的FR数据包。不给予解析NS层及以上属于GPRS的协议栈。

作者: neoshi 时间: 2011-6-13 17:08:06

[attach]446[/attach]

附上一个Gb over Ip的流程供参考，这样就不会出现解码问题了。

对于SNDCP层的分段，如果是缺省N201U的情况就没有协商的流程。

这里好玩的是，如果理论上都缺省的话，这样网络下行的数据包都会在500字节以下了，但是目前已经有很多手机开始发起这样的协商了，这样可以协商到1500字节，相当于上层的IP数据不会进行分段了。

没想到版主也在研究这个问题，呵呵。

作者: 爱卫生 时间: 2011-6-13 19:41:02

回复 neoshi 的帖子

感谢你的分享哦！非常实用的！谢谢了！
如果这个包有谁打开后看到payload部分没有数据的话，请选择wireshark的菜单----Analyze----Decode As，然后在右边的这一列选择GPRS-NS就可以解码出来了。会看到SNDCP的分段。

作者: hendouse 时间: 2011-6-18 20:02:47

刚刚发现，在第三个分包（也就是最后一个包），SNDCP层在wireshark里面会告诉三个包的大小（#496，#497，#483）
看信令里面各个字段，真的是寓意无穷啊，设计者果然厉害！

作者: 断肠人 时间: 2011-6-24 17:24:08

好东西，谢谢分享

作者: mobileice 时间: 2011-7-25 10:49:20

分析的相当好，谢谢

作者: mobileice 时间: 2011-7-25 16:50:17

看明白了

作者: xray1111 时间: 2011-9-11 17:26:23

看了以上SNDCP包的分析，发现其中并没有用到协议中提到的SNDCP的压缩功能，我想问一下，实际的运营商的设备上，是否会将SNDCP按压缩方式配置，如果是，一般采用何种压缩算法，有没有这方面的例子，谢谢！

作者: ziseputi 时间: 2011-11-6 16:51:17

太感谢了～，让我一下对SNDCP的过程明白了很多～

作者: scrapersky 时间: 2011-11-30 21:42:52

爱总，您讲的这些涉及到哪些协议啊？

作者: 爱卫生 时间: 2011-12-1 22:30:52

回复 scrapersky 的帖子

本帖只涉及到SNDCP协议啊。如果要说N201-U的协商的话，那还牵扯到LLC层协议。

作者: yunfeisaiwai 时间: 2012-4-11 16:15:26

纠正一个问题，以上就是N-PDU的大小，共计272个字节。

应该是284个字节，232+tcp的32（不是20）+20=284

本文摘自: GPRS家园(www.gprshome.com) 详细出处请参考：http://www.gprshome.com/forum.ph ... p;tid=302&extra

作者: 爱卫生 时间: 2012-4-11 22:23:47

回复 yunfeisaiwai 的帖子

非常感谢指出错误，已更新。

作者: h200hh 时间: 2012-4-20 14:14:12

回复 hendouse 的帖子

呵呵，在官网下了一个wireshark-win32-1.4.12，按照楼上说的设置后，都能正确解码了。也基本看明白了。

作者: h200hh 时间: 2012-4-20 15:13:02

回复爱卫生的帖子

请问爱总，为什么我抓得SGSN-POOL的GB接口数据包，UDP以上层解码出错，需要做什么设置吗？我用的是：wireshark-win32-1.4.12

作者: 47790933 时间: 2013-11-19 16:38:57

好东西就是不太明白在哪能看n201—u的值

作者: 小拇指洁洁 时间: 2013-12-25 15:04:14

写得很清晰，适合我这种新手，很快就看明白了，谢谢，

欢迎光临 51学通信技术论坛 (http://51xuetongxin.com/bbs/)