SNDCP协议介绍

爱卫生

SNDCP：Subnetwork Dependence Converage Protocol，子网相关汇聚协议。
参考协议：3GPP TS 44.065.

一、主要功能:
1) PDP的多路复用
   Multiplexing of several PDPs.
2) 用户数据压缩和解压缩
   Compression / decompression of user data.
3) 协议控制信息的压缩和解压缩
   Compression / decompression of protocol control information.
协议控制信息等。
4) 将网络协议数据单元（N-PDU)的分片成逻辑链路控制协议（LLC）的数据单元(LL-PDU)，以及将逻辑链路控制协议的数据单元(LL-PDU）重组成网络协议数据单元(N-PDU)
   Segmentation of a network protocol data unit (N PDU) into Logical Link Control Protocol Data Units (LL PDUs) and re-assembly of LL PDUs into an N PDU.

二、协议栈中位置
   从SNDCP的功能上看，数据的压缩和解压缩，协议控制信息的压缩和解压缩功能，其实是为了提供信道的效率。而功能4)，又相当于将网络协议单元和LLC的的数据单元进行一个对接，这样实现，使得LLC不必关心它所服务的网络协议，而SNDCP之上的网络协议又不必关心底层的网络连接，基本上就可以实现透明传输。这样一个LLC的SAPI（服务接入点）就可以对应于多个PDP。下图展示了SNDCP在GPRS协议栈中的结构。为了实现充当上层用户和下层LLC之间的接口，SNDCP定义了很多原语用于相邻两层之间的功能调用。每个原语实现不同的功能，例如建立LL连接，XID交换等。其中以LL开头的原语例如LL-ESTABLISH.request，是指SNDCP和LLC之间的通信。而大部分以SN开头的，代表SNDCP和上层用户之间的通信。
   

图一 SNDCP的位置

三、重要的概念
1）NSAPI：Network Layer Service Access Point Identifier
   SNDCP提供及使用的服务接入点结构图如下：

   

图二 SNDCP和相邻层的关系

  网络层使用的协议由动态分配的一个NSAPI来标识（该NSAPI是在PDP激活时在SM层生成的，然后通过SNSM-ACTIVE.indication传递给SNDCP层的，其实相当于在此建立了网络层协议和NSAPI之间的对应关系）。
SNDCP在收到N-PDU后，在向下层发送之前会填上该NSAPI，对等实体收到下层数据后，会根据NSAPI来确定所使用的网络协议。

2) N-PDU和LL-PDU
  N-PDU是SNDCP和GPRS application之间传输的数据单元。SN-PDU是SNDCP和LLC之间传输的数据单元。下图描述不同协议的复用：

图三 SNDCP对N-PDU的复用

  一般，N-PDU包括Header和Data body. 比如IP Header.

3) N201.
  Defines maximum number of octets in the information field of LL PDU. LL-PDU的最大长度，N-PDU按N201的长度进行分段。N-PDU通过XID参数协商确定。
  分为N201-I和N201-U两种：
N201-I：Defines maximum number of octets available to a SN DATA PDU for a specific SAPI.确认模式的分段长度
N201-U：Defines maximum number of octets available to a SN UNITDATA PDU for a specific SAPI.非确认模式的分段长度

四、SNDCP提供的服务
1）将SN-DATA源语映射到LL-DATA源语（确认模式）
   Mapping of SN DATA primitives onto LL DATA primitives.
2）将SN-UNIDATA源语映射到LL-UNIDATA源语（非确认模式）
   Mapping of SN UNITDATA primitives onto LL UNITDATA primitives.
3）复用一个或多个网络层实体的N-PDU到LLC连接
   Multiplexing of N PDUs from one or several network layer entities onto the appropriate LLC connection.
4）建立，重建和释放确认模式的端对端的LLC操作
   Establishment, re-establishment and release of acknowledged peer-to-peer LLC operation.
5）确认模式端对端LLC操作中，通过缓冲和重传机制确保LLC层数据的完整性。
   Supplementing the LLC layer in maintaining data integrity for acknowledged peer-to-peer LLC operation by buffering and retransmission of N PDUs.
6）独立管理每个NSAPI的投递系列号N-PDU Number.
   Management of delivery sequence for each NSAPI, independently.
7）在传输端压缩冗长的协议控制信息，接收端进行解压缩。
   Compression of redundant protocol control information (e.g. TCP/IP header) at the transmitting entity and decompression at the receiving entity. The compression method is specific to the particular network layer or transport layer protocols in use.
8）在传输端压缩冗长的数据信息，在接收端进行解压缩。对每个SAPI，数据压缩独立执行，也可能在PDP上下文间独立执行。压缩参数在MS和SGGN间进行协商。
   Compression of redundant user data at the transmitting entity and decompression at the receiving entity. Data compression is performed independently for each SAPI, and may be performed independently for each PDP context. Compression parameters are negotiated between the MS and the SGSN.
9）分片和重组。压缩功能的输出是分片为LL-PDU的最大长度。独立于使用的网络层协议。
  Segmentation and reassembly. The output of the compressor functions is segmented to the maximum length of LL PDU. These procedures are independent of the particular network layer protocol in use.
10）在对等SNDCP实体间协商XID参数。
   Negotiation of the XID parameters between peer SNDCP entities using XID exchange.
下图描述了SNDCP在发送端的数据流程：

图四 SNDCP在发送端的封装流程(本图可参考TS44.065的Figure 4:SNDCP model)

yuqinwan

视屏讲解的非常了，看过视屏后让我好久的疑惑终于解开了，谢谢爱总

行虚名座画

接上面的回复，llc如何保证确认数据按顺序投递。对于确认数据，llc本地保存了变量V(S),V(R),V(A).  比如上述中sndcp分成了三个分段1,2,3. llc发送一个分段V(S)值加1，则三个分段发送完毕之后V(S)=3. V(R)表示接收到一个I帧，值加1。 这里只考虑发送I帧，则V(S)等于3，V(R)=0。V(A)表示需要peer的ack。即llc发了3个I帧之后，在I帧里面的A bit位设置为1，并启动T201定时器，peer收到带A为的I frame之后，需要给发送端发ack，此时为S帧。此时peer的llc也维护三个本地变量V(S),V(R),V(A)，正好相反，peer的V(S)=0，V(A)=0.V(R)的值就表示发送端发送了几个llc帧，若正常发送，peer的V(R)=3，则peer发送RR帧（S帧的一种），发送端接到RR帧之后，表示peer正常接收。而peer顺序收到之后，就往sndcp发送。  

异常情况下，peer收到了1。而2,3没有收到，又收到了4.则llc在队列里面给2,3预留了两个位置，直到2,3全部收到之后再往sndcp投递。若2,3没有收到，并且发送端要求会ACK（I frame的Abit为1），则peer就根据V(R)与接收到的I frame的N(S)做比较，此刻发送SACK帧，SACK的bitmap里面会告诉发送端哪些frame丢失，发送端再重传，直到peer端正常接收到1,2,3,4,5,6

行虚名座画

不好意思，没仔细看上面的讨论，另外我自己的回复也错了，重新翻了一下44.065. 非确认的每个都需要N-PDU number，还是因为你这个例子，需要区分，我上面输错了。对于确认数据不需要除了第一个分段不需要N-PDU number，因为llc层保证了向上投递的数据块都是顺序的。拿这个例子来说，如果是非确认数据的话，就根据n-pdu number和segment number可以区分出来。如果是确认数据。手机llc收到1和4之后，因为是确认数据，此时llc不会立刻给sndcp，llc再等到2,3,5,6全部收齐之后，才按顺序的将1,2,3,4,5,6送到sndcp。则sndcp可以根据F bit以及M bit以及第一个分段里的N-PDU num将sn-pdu重组成N-PDU投递上去。
sndcp与Qos关系不大，主要是用来区分不同的sapi，sapi的选择在sm层完成。sndcp可以根据reliabilityClass来确定llc和rlc是采用确认模式还是非确认模式进行传输，以及llc的保护模式以及非保护模式。其他就没什么用处了。

admin

行虚名座画 发表于 2012-7-10 11:01
对于非确认模式的N-PDU是否重发的问题，我来说两句，首先，如果不同业务的话，pdp不同，nsapi不同，所以这是 ...

谢谢！不过不好意思没有完全理解，这里主要关注SNDCP层在接收端的重组功能（如果没有N-PDU字段的话）比如说用户同时访问新浪和网易，是属于同一个PDP（APN=cmnet），NSAPI一样，Qos也一样，都算背景类。那这时新浪发个图片给手机，要通过SNDCP分段成1、2、3，网易发个图片给手机分段成4、5、6，那手机收到了1和4，在本端如何重组交给LLC层处理呢（在没有N-PDU字段的情况下）？

另外，请问下，SNDCP层和Qos有关联吗？

行虚名座画

对于非确认模式的N-PDU是否重发的问题，我来说两句，首先，如果不同业务的话，pdp不同，nsapi不同，所以这是可以区分的。如果对于同一个pdp的话，如果QoS等级不同，则可以根据sapi来区分。如果是同一个pdp且Qos等级相同，那肯定就是同一个业务，所以也没问题

Darcy2011

对SNCDP协议不是很熟悉，此贴很有帮助。

爱卫生

ziseputi 发表于 2011-11-11 09:45
回复 爱卫生 的帖子
   在确认模式下：除第一个分片外的其它分片都不携带N-PDU number。如果有多个N-PDU同时发 ...

  好问题。
  如果按照规范的说法反推回去的话。那就是说不允许多个N-PDU同时发送，一定要先发一个，等N-PDU完成重组后再发下一个。这样感觉效率也太低了啊。另外，多个N-PDU确实有需要同时发送的场景啊。例如一个手机QQ或者MSN的群讨论，可能又有声音、又有图片、又有文字要传。肯定需要同时发吧。还有视频会议里的图像、视频、PPT展示等等。不过这些应用在2G里面估计跑不起来，所以SNDCP协议也不需要考虑。
  但即使这样的话，那N-PDU number又有什么存在的必要呢？我觉得都可以去掉了，反正有F bit和Mbit，我就能够区分出这是不是第一个、是不是最后一个，然后就可以完成重组了。然后再等下一个N-PDU。根本就不需要N-PDU number来标识。
  求高手解答，还有前面你的问题。"还有最后一个分片也不一定最后到，为什么：（接收完N-PDU的最后一个分段(M为0)后，进入Receive First Segment状态。）？？？”
  已转入20.1版块求解。
  为更好的说明问题，再转两张图在这。

图1 Segmentation mechanism for unacknowledged transmission mode

图2：Segmentation mechanism for acknowledged transmission mode

ziseputi

回复 爱卫生 的帖子

在确认模式下：除第一个分片外的其它分片都不携带N-PDU number。如果有多个N-PDU同时发送各自的分片，接收后如何区分？

爱卫生

ziseputi 发表于 2011-11-10 18:46
回复 爱卫生 的帖子

非常感谢您那么认真负责的回复！！！不过我还有疑问：

  我还是觉得可能会有同一时刻的多个N-PDU在接收端收到。
  因为，我的理解是，确认模式说的发一个，确认一个，再发下一个。这里是指的Segmeng，而不是指的N-PDU。因为这是6.7的分段和重组功能所提到的。"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)."
  所以，如果源端有多个N-PDU要发送的话，不会等到发完N-PDU1，收到确认后，再发N-PDU2。可以是并行的。接收端也有可能会同时收到这两个N-PDU。所以就需要用N-PDU number区分出来了。
  这样的场景会很多。这是由最常见的HTML语言所造成的。例如用户手机访问www.sina.com.cn。实际上会sina server会在建立TCP连接后同时下发多个用户的数据文件，包括很多图片，以及多版网页文字。因为访问这个首页实际上会调用很多个后台的页面文件，但用户可能感觉只访问了一个首页。那这些图片、网页文字不会封装到一个N-PDU里面的。肯定会是多个。例如图片1有10K，封装到1个N-PDU，然后按分段功能进行分段。网页文字可能只有0.5K，封装到另一个N-PDU，如果需要分段的话也会被独立的分段。这些图片和文字会同时发给手机。手机在接收的时候因为还没有完成重组，所以需要N-PDU number来区分这个收到的Segment是上面提到的图片还是网页文字，进而完成重组。

ziseputi

回复 爱卫生 的帖子

非常感谢您那么认真负责的回复！！！

不过我还有疑问：
在确认模式下N-PDU number只有第一个分片携带，其他分片都不携带。
（For acknowledged peer-to-peer LLC operation, DCOMP, PCOMP andN‑PDUnumber shall be included in the header when the F bit is set to 1, andshallnot be included when the F bit is set to 0.）
所以在同一个 NSAPI 下应该不会存在你所说的（但可能同一时刻有很多个N-PDU在发。所以接收端重组的时候需要知道收的这些segment，哪些是属于同一个N-PDU。就用N-PDU number来区分。）。
（不同的NSAPI之间 N-PDU number是独立的）。
我是新手，可能理解的不太正确。

爱卫生

回复 ziseputi 的帖子

上述红色字体实际上对规范的完全翻译。包括这篇帖子的内容基本上都是。但规范确实只告诉我们该怎么做，至于为什么这样做和考虑并没有说，那是他们在开大会的时候可能各个厂家会讨论的。我们在这里就只能去猜了。
   这个问题我是这么理解的。
   先看下红色字体表达的是什么意思，然后再看为什么规范要这样考虑。
   举一个实例：
--------------------------------------------------------------------------------
   假设两个SNDCP实体进行通信，MS --- SGSN：MS有一个N-PDU要发给SGSN，采用非确认模式，因为N-PDU超过了N201-U的大小，所以分成了10个Segment。Segment的编号为#0 - #9。
1 MS的SNDCP User发送SN-UnitDATA.req给SNDCP层，请求发送编号为0的第一个Segment。SNDCP层通过LL-UNITDATA.req请求LLC进行数据传递（参见TS44065的Figure 14 SNDCP unacknowledged data trasfer)。
2 不用等SGSN的确认，MS的SNDCP User发送SN-UnitDATA.req给SNDCP层，请求发送编号为1的第二个Segment。
同时：
3 SGSN侧如果先收到编号为1的segment（即F-bit为0），则将此segment丢弃。
4 SGSN侧等收到编号为0的segment（即F-bit为1），状态切换到Receive Subsequent Segment state。
5 当SGSN侧收到最后一个编号为9的segment(即M-bit为0），状态切换到Receive First Segment state。也就是等待接收下一个N-PDU。
   根据上述对规范的理解，我尝试回答你的问题。
   规范实际上说非确认模式是乱序的，但对起点的接收是有要求有序的，但中间的数据包可以是无序接收。也就是在接收端，只有在收到了正确的第一个segment后才进行后续处理。这样做的好处应该是有利于设备对包的定界。知道包的开始，是不是会对设备实现有好处呢？
   但这个只回答了你的第一个问题，后面那个问题即“还有最后一个分片也不一定最后到，为什么”还需要再想想。

爱卫生

ziseputi 发表于 2011-11-10 13:36
多谢！
感觉协议中这样规定一定有原因的，但我在协议中没有看到原因。

  实在不好意思。好久没看SNDCP的规范了。我在8楼关于N-PDU的解释是不正确的。为不误导其他人，已经删除。
  我在8楼将N-PDU number记成了非确认模式的segment number。后者相当于是序列号，是用于对分段后的数据包进行重组的。而N-PDU number是对N-PDU的唯一标识，类似于IP包头当中的ID字段。所以在非确认模式下，由于可能是乱序接收的，所以需要通过N-PDU number知道是哪些Segment是同一个N-PDU,然后再根据Segment number的大小进行排序完成重组。这个Segment number从0开始取值，依次加1。
  但在确认模式下，因为N-PDU是按序接收的。发一个，确认一个，再发下一个。所以不需要Segment number,但N-PDU Numer肯定还是一定要有的。这在确认模式下也是个必选字段。和非确认模式的作用一样，也用于唯一的来标识同一个N-PDU。因为虽然确认模式下是有序发送和接收的。但可能同一时刻有很多个N-PDU在发。所以接收端重组的时候需要知道收的这些segment，哪些是属于同一个N-PDU。就用N-PDU number来区分。这里有一个实例介绍重组功能。http://www.gprshome.com/forum.php?mod=viewthread&tid=302&extra=page%3D1 。
   规范44065的6.7章介绍了分段和重组，6.9介绍了两种模式下的数据传递，然后7.2介绍了SN-PDU的格式。如下：

图例：SN-PDU两种模式的PDU格式

ziseputi

多谢！
感觉协议中这样规定一定有原因的，但我在协议中没有看到原因。

ziseputi

还有个问题请教：
在确认模式下 N-PDU number 有什么作用？？

ziseputi

请教一个问题：
5) Segmentation and reassembly in unacknowledged mode
  非确认模式下，由于是不可靠传输，先发的未必先收到。还需引进Segment number，为N-PDU的每一个SN-PDU指定一个序列号，从0开始，依次递增。这样在接收后，按Segment number排序，然后组合成N-PDU.
- Receive First Segment state.
如果接收到F字段为0的分段，不是第一个分段，抛掉。接收完第一个分段后(F为1)，获得DCOMP或者PCOMP，然后进入Receive Subsequent Segment 状态。
- Receive Subsequent Segment state.
  如果再次收到F为1的第一个分段，并且DCOMP或者PCOMP不同，那么之前接收的同一个N-PDU的所有分段都抛掉。接收完N-PDU的最后一个分段(M为0)后，进入Receive First Segment状态。

既然非确认模式下先发的不一定先到，也就是第一个分片不一定先到达，那为什么：（如果接收到F字段为0的分段，不是第一个分段，抛掉。）？
还有最后一个分片也不一定最后到，为什么：（接收完N-PDU的最后一个分段(M为0)后，进入Receive First Segment状态。）？？？

爱卫生

回复 samsin 的帖子

  一个一个说吧。不过别说赐教了。我有很多观点其实也不对，多亏论坛的朋友帮我指正、学到了很多。呵呵！互相交流吧！
  先看下第3个。我虽没找到包。但应该SAPI是相同的。因为协议栈的目的之一就是要完成正确的封装/解封装。而在MS---SGSN这边的协议栈是这样的，如下图（摘自TS44064)：

  从图上可以看出。在解封装的时候，假设是MS发给SGSN，那假设SGSN来解封装。LLC层的SAPI寻址其实很简单，如果SAPI=3，则解封装交给SNDCP层处理，如果SAPI=1，则解封装交给GMM层处理（信令消息）。因此LLC层寻址并不区分用户。只是解封装后交给不同的协议栈处理。这就要求源端在封装数据包的时候，要封装好正确的SAPI值。因此MS侧在发送数据的时候，不管是cmwap还是cmnet，SAPI都是3。因为都是用户数据。只要是信令消息，不管是cmwap的激活还是cmnet的激活，就应该都是1了。

   LLC层完成解封装后，交给SNDCP层去处理，这时候才会有NSAPI，也就是在SNDCP层才会和PDP上下文进行映射。LLC根据就不区分的。

samsin

！！！！
首先提个意见 我写了贴，忽然想带附件，于是点了“高级模式”，结果我刚才写的全都没了，这里最好加个提示吧！

本文档和SNDCP的实例讲解确实不错，非常感谢！
还有几个问题，还请楼主赐教：
1、SNDCP data transfer下，有个 到对端等实体的LLC 连接，比如MS的到2G-SGSN，这个连接和tlli表示的那个LLC连接是否是同一个？如果是，因为tlli总是有（除MS的第一次attach外），所以这个连接也总是有，那在unacknowledged mode下，是相当于没有使用该连接而已，在acknowledged mode下，实际上也不需要再建连接，因为这个时候早有LLC连接了，我的观点有问题吗？

2、由于不同的PDP context使用的NSAPI也不同，因此如果从NSAPI方面来看SNDCP层, 相当于是不同的PDP使用的SNDCP承载不同，比如我发起连接cmwap，于是我有了一个PDP1,我使用了Fetion、MobileQQ、qq浏览器这3个gprs applications，那么我的这3个应用相当于是跑在这个PDP1的context之中，因此可以说这3个应用复用了SNDCP承载，由于每个应用每次调用SNDCP的request原语时，在SNDCP层产生的N-PDU number都不同，或者说SNDCP层能保证在多种应用中每一个N-PDU都能非常正常地分段和重组，在目标实体重组后（比如在sgsn），根据用户部分的IP、port可以寻址到目标机的目标进程，反之可以寻址到手机的比如MobileQQ进程，我的问题是 如果 我再发起一个CMNET的连接，那么服务于CMNET的LLC层的sapi和服务于CMwap的LLC层的sapi可以相同吗？

3、我的附件里有actviate PDP req，这个包里面sapi、nsapi都是需要网络协商的，为啥在response里面只有 nsapi negotiated， 却没有 sapi的东东？