SNDCP层数据包分段及重组功能实例详解

爱卫生

    在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打开。

爱卫生

回复 tobino1 的帖子

应该可以啊。如下截图：

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

爱卫生

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 的帖子

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

爱卫生

回复 scrapersky 的帖子

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

爱卫生

回复 yunfeisaiwai 的帖子

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