51学通信技术论坛

标题: SNDCP协议介绍 [打印本页]

作者: 爱卫生 时间: 2011-5-15 16:00:02 标题: SNDCP协议介绍

本帖最后由爱卫生于 2011-5-15 16:08 编辑

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和上层用户之间的通信。

[attach]374[/attach]

图一 SNDCP的位置

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

[attach]375[/attach]

图二 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之间传输的数据单元。下图描述不同协议的复用：

[attach]376[/attach]

图三 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在发送端的数据流程：

[attach]377[/attach]

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

作者: 爱卫生 时间: 2011-5-15 16:30:16 标题: 五、主要流程

五、主要流程
1. PDP激活
SM在PDP激活后，通过SNSM-ACTIVATE.indication通知SNDCP以下信息:
1) 激活的NSAPI，以及对应的SAPI.
2) 协商的QoS参数，包括LLC的确认模式，以及传输数据的性能要求，比如Throughput、RadioPriority和ProtectMode等。

2. Multiplexing of N PDUs
NSAPI用于标识一对PDP Type和PDP Address. 从5-15共11个值。
在PDP激活时，动态的分配一个。然后，在PDP激活成功后，由SM将NSAPI、PDP Type和PDP Address通过源语SNSM-ACTIVATE indication传到SNDCP。
之后， SNDCP传输应用发下来的的N-PDU时，加上NSAPI。这样，SNDCP对等层可以根据NSAPI，将数据传到对等的上层应用。

PDP type
Allocated NSAPI
PDP address
IPv4
12
133.12.75.111 (4 octets)
IPv6
13
133.12. … .11.123 (16 octets)

Example of the NSAPI allocation

3. Establishment and release of acknowledged peer-to-peer LLC operation.
  包括确认模式下LLC连接的建立，重建和释放( Establishing, Re-establishing and Releasing the acknowledged peer-to-peer LLC operation)，
  以及XID参数的协商（Negotiation of SNDCP XID parameters may be carried out in conjunction with the establishment or re-establishment procedure.） XID参数协商，也可以通过LL XID primitives。
1) Establishment of acknowledged peer-to-peer LLC operation
  在激活PDP时，根据协商的QoS参数，如果LLC是确认模式，SNDCP就让LLC建链。
  另外，在PDP参数修改时，比如QoS参数中LLC从非确认模式修改为确认模式，也需要发起LLC建链。

[attach]378[/attach]

图五 SNDCP发起的建立和重建

2) Re-establishment of the acknowledged peer-to-peer LLC operation
LLC也可以发起连接重建，比如出现错误等。

[attach]379[/attach]

图六 LLC发起的重建

3) Release of acknowledged peer-to-peer LLC operation
为某个SAPI用于确认模式，已经存在连接，在PDP去激活时，需释放。另外，QoS修改为非确认模式时，也释放。还有，LLC也可以发起连接释放。

4. N PDU buffering
  在压缩分段传给LLC之前，N PDUs在SNDCP层缓存。
  在PDP去激活时，根据NSAPI删除其缓存的N-PDUs。
  对于确认模式，在该N-PDU的所有SN-PDUS都被确认后，缓存的N-PDUs才能被删除。
  对于非确认模式，将所有SN-PDUS发送到LLC后，就删除。

5. Segmentation and reassembly
1) SN PDU Formats

Bit
8
7
6
5
4
3
2
1
Oct 1
X
F
T
M
NSAPI
2
DCOMP
PCOMP
3
N‑DU number - acknowledged mode
¼
Data segment
N

SN DATA PDU format(确认模式)

Bit
8
7
6
5
4
3
2
1
Oct 1
X
F
T
M
NSAPI
2
DCOMP
PCOMP
3
Segment number
N‑DU number - unacknowledged mode
4
N‑DU number - unacknowledged mode (continued)
¼
Data segment
N

SN UNITDATA PDU format(非确认模式)

其中各字段含义如下：
- More bit (M):
0 Last segment of N PDU.
1 Not the last segment of N PDU, more segments to follow.
- SN PDU Type (T):
0 SN DATA PDU.
1 SN UNITDATA PDU.
- First segment indicator bit (F):
0 This SN PDU is not the first segment of an N PDU.
  The octet including DCOMP and PCOMP is not included in the SN DATA PDU or SN UNITDATA PDU format. Also the octet for N PDU number for acknowledged mode is not included in the SN DATA PDU format.
1 This SN PDU is the first segment of an N PDU. The octet for DCOMP and PCOMP is included in the SN DATA PDU or SN UNITDATA PDU format. Also the octet for N PDU number for acknowledged mode is included in the SN DATA PDU format.
- Spare bit (X):
0 Shall be set to 0 by the transmitting SNDCP entity and ignored by the receiving SNDCP entity.
- NSAPI:
0  Escape mechanism for future extensions.
1  Point-to-Multipoint Multicast (PTM-M) information.
2-4  Reserved for future use.
5-15 Dynamically allocated NSAPI value.
  SN PDU with an unallocated NSAPI value shall be ignored by the receiving SNDCP entity without error notification.
- Data compression coding (DCOMP):
0  No compression.
1-14 Points to the data compression identifier negotiated dynamically.
15  Reserved for future extensions.
SN PDU with an unallocated DCOMP value shall be ignored by the receiving SNDCP entity without error notification.
- Protocol control information compression coding (PCOMP):
0  No compression.
1-14 Points to the protocol control information compression identifier negotiated dynamically (see subclause 6.5).
15  Reserved for future extensions.
  SN PDU with an unallocated PCOMP value shall be ignored by the receiving SNDCP entity without error notification.
- Segment number:
0-15  Sequence number for segments carrying an N PDU.
- N PDU number - acknowledged mode:
0-255  N PDU number of the N PDU.
- N PDU number - unacknowledged mode:
0-4095    N PDU number of the N PDU.

2) Segmentation
  分段就是将N-PDU分成SN-PDUs. SN-PDUs的长度，在确认模式下，S不超过N201-I；非确认模式下，不超过N201-U。其中N201-I和N201-U通过XID参数协商确定。
  第一个分段的F字段为1，其它分段的F字段为0.
  非确认模式下，对于F为1的第一个分段，DCOMP 和PCOMP字段需填写。
  确认模式下，对于F为1的第一个分段，DCOMP, PCOMP 和 N PDU number字段需填写。
  最后一个分段的M字段为0，其它分段的M字段为1.

3) Reassembly
汇聚时，DCOMP 和PCOMP从第一个分段中获得，确认模式下，N PDU number也从第一个分段中获得。
接收的SNDCP实体，有以下3个状态：
- Receive First Segment state，等待接收F字段为1的第一个分段；
- Receive Subsequent Segment state，等待接收F为0的后续分段；
- Discard state，组合成N-PDU后，丢弃接收的SN-PDUs.

4) Segmentation and reassembly in acknowledged mode

确认模式是可靠传输，只有前面的分段确认后，才发送后面的字段。接收也一样。可以确保所有分段按先后顺序达到。在接收完毕后，直接组合为N-PDU即可。

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状态。

6. XID parameter negotiation
XID参数包括数据压缩和解压缩的参数，以及SN-PDU的长度N201-I和N201-U。(N201是LLC层的最大payload长度，即I帧的信息帧的长度，类似于IP网络中MTU最大传输单元的作用）。
在数据传输前，需要调整XID参数时，先进行XID参数协商。

[attach]380[/attach]

图七 SNDCP XID协商流程

7. Data transfer
1) Acknowledged mode
  The SNDCP entity shall initiate acknowledged data transmission only if the PDP context for the NSAPI identified in the SN DATA.request has been activated and if acknowledged LLC operation has been established.
  确认模式下传输数据要求：NSAPI对应的PDP已经激活，并且确认模式的LLC连接已经建立。
  上层应用在发数据时，通过SN DATA.request源语，将N-PDU number带下来。不同的NSAPI的N-PDU number是独立的。确认模式下，在分段时，将N-PDU number填在第一个分段的SNDCP头部。
  对每一个NSAPI，都有Send N-PDU number和Receive N-PDU number. 在激活确认模式下的数据传输时(PDP激活和LLC建立)，这两个N-PDU number都置为0.
  SN DATA.request源语中如果没有带Send N-PDU number，就把当前的置作为N-PDU number，对数据进行压缩和分段发到LLC。然后Send N-PDU。number加1.
  SN DATA.request源语中如果带了Send N-PDU number，就覆盖当前的值。
  每发送一个N-PDU，Send N-PDU number加1；每接收一个N-PDU，Receive N-PDU number加1。

[attach]381[/attach]

图八 SNDCP确认模式数据传输

2) Unacknowledged mode
The SNDCP entity shall initiate unacknowledged data transmission only if the PDP context for the NSAPI identified in the SN DATA.request has been activated. The SNDCP entity may initiate unacknowledged data transmission even if the acknowledged peer-to-peer operation is not established for that NSAPI.

[attach]382[/attach]

图九 SNDCP非确认模式数据传输

作者: mobileice 时间: 2011-7-25 16:51:24

谢谢分享，写的比较详尽，比看英文的协议好多了，哈哈

作者: samsin 时间: 2011-10-4 18:53:26

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

本文档和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的东东？[attach]882[/attach]

作者: 爱卫生 时间: 2011-10-11 10:30:30

回复 samsin 的帖子

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

[attach]890[/attach]

从图上可以看出。在解封装的时候，假设是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根据就不区分的。

作者: ziseputi 时间: 2011-11-7 19:07:12

请教一个问题：
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状态。）？？？

作者: ziseputi 时间: 2011-11-8 10:59:10

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

作者: ziseputi 时间: 2011-11-10 13:36:40

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

作者: 爱卫生 时间: 2011-11-10 14:21:04

本帖最后由爱卫生于 2011-11-10 14:22 编辑

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的格式。如下：

[attach]938[/attach]

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

作者: 爱卫生 时间: 2011-11-10 15:01:19

回复 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 18:46:59

本帖最后由 ziseputi 于 2011-11-10 18:51 编辑

回复爱卫生的帖子

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

不过我还有疑问：
在确认模式下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是独立的）。
我是新手，可能理解的不太正确。

作者: 爱卫生 时间: 2011-11-10 20:13:34

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 时间: 2011-11-11 09:45:48

回复爱卫生的帖子

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

作者: 爱卫生 时间: 2011-11-11 10:44:33

本帖最后由爱卫生于 2011-11-11 11:09 编辑

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版块求解。
  为更好的说明问题，再转两张图在这。

[attach]940[/attach]

图1 Segmentation mechanism for unacknowledged transmission mode

[attach]939[/attach]

图2：Segmentation mechanism for acknowledged transmission mode

作者: Darcy2011 时间: 2012-4-28 16:43:14

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

作者: 行虚名座画 时间: 2012-7-10 11:01:31

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

作者: admin 时间: 2012-7-10 11:16:23

行虚名座画发表于 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有关联吗？

作者: 行虚名座画 时间: 2012-7-10 11:49:22

不好意思，没仔细看上面的讨论，另外我自己的回复也错了，重新翻了一下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的保护模式以及非保护模式。其他就没什么用处了。

作者: 行虚名座画 时间: 2012-7-10 12:23:19

接上面的回复，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

作者: yuqinwan 时间: 2013-8-22 11:34:20

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

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