【YD通讯标准】 2GHz TD-SCDMA 数字蜂窝移动通信网多载波高速分组接入 Uu 接口层2技术要求 第3部分:PDCP 协议

ICS33.070.99
中华人民共和国通信行业标准
YD/T2856.3-2015
2GHzTD-SCDMA数字蜂窝移动通信网多载波高速分组接入
Uu接口层2技术要求
第3部分：PDCP协议
2GHzTD-SCDMAdigitalcellularmobiletelecommunicationnetwork-MultiCarrierHSPA-Layer2technicalrequirement-Part 3:Packetdata convergence protocol (PDCP)(3GPPTS25.323v10.1.0,Packetdataconvergenceprotocol，NEQ)2015-07-14发布
2015-10-01实施
中华人民共和国工业和信息化部发布前言
1范围
2规范性引用文件
3缩略语·
4概述
子层结构概述·
5功能-
头压缩·
5.3数据传输…
5.4SRNS重定位
5.5无损DLRLCPDU大小改变·
一般过程
5.7MBMS的头压缩和解压缩·
6.1提供给上层的服务
6.2期望从RLC层获得的服务*
7层到层通信的元素·
7.1PDCP和上层间的原语·
8端到端通信的元素·
8.1协议数据单元…
8.2格式
8.3参数*
处理未知的、未预见的及错误的协议数据9.1无效的PDUtype
9.2无效的PID值·
9.3PDCP不可恢复错误检测
附录A规范性附录）ROHC性能测试次
附录B（资料性附录）产生ROHC性能要求的参考模型.参考文献
YD/T2856.3-2015
YD/T2856.3-2015
YD/T2856《2GHzTD-SCDMA数字蜂窝移动通信网多载波高速分组接入Uu接口层2技术要求》是2GHzTD-SCDMA数字蜂窝移动通信网多载波高速分组接入Uu接口系列标准之一，该系列标准的结构和名称如下：
a）《2GHzTD-SCDMA数字蜂窝移动通信网多载波高速分组接入Uu接口物理层技术要求》；b）YD/T2856《2GHzTD-SCDMA数字蜂窝移动通信网多载波高速分组接入Uu接口层2技术要求》：
c）YD/T2857《2GHzTD-SCDMA数字蜂窝移动通信网多载波高速分组接入Uu接口RRC层技术要求》。
随着技术的发展，还将制定后续的相关标准。YD/T2856《2GHzTD-SCDMA数字蜂窝移动通信网多载波高速分组接入Uu接口层2技术要求》分为三个部分：
a）第1部分：MAC协议；
b）第2部分：RLC协议；
c）第3部分：PDCP协议。
本部分是YD/T2856《2GHzTD-SCDMA数字蜂窝移动通信网多载波高速分组接入Uu接口层2技术要求》的第3部分。
本部分按照GB/T1.1-2009给出的规则起草。本部分对应于3GPPTS25.323《PDCP协议》（版本v10.1.0），一致性程度为非等效，主要差异为删除了FDD相关的内容。
请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任。本部分由中国通信标准化协会提出并归口。本部分起草单位：工业和信息化部电信研究院、大唐电信科技产业集团、中兴通讯股份有限公司、鼎桥通信技术有限公司、中国普天信息产业股份有限公司、重庆重邮信科通信技术有限公司、北京展讯高科通信技术有限公司、新邮通信设备有限公司本部分主要起草人：师延山、段红光、宋爱慧、严杲、张英、徐菲、黄河、贺刚、王梅、申敏、常永宏、宿淑艳。
HiiKAoiKAca
1范围
2GHZTD-SCDMA数字蜂窝移动通信网多载波高速分组接入U接口层2技术要求第3部分：PDCP协议
YD/T2856.3-2015
本部分规定了2GHzTD-SCDMA数字蜂窝移动通信网多载波高速分组接入Uu接口层2中分组数据的汇聚协议，及鲁棒头压缩性能测试用例。本部分适用于2GHzTD-SCDMA数字蜂窝移动通信网多载波高速分组接入Uu接口层2。2规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。YD/T2856.2-20152GHzTD-SCDMA数字蜂窝移动通信网多载波高速分组接入）Uu接口层2技术要求第2部分：RLC协议
YD/T2857-20152GHzTD-SCDMA数字蜂窝移动通信网多载波高速分组接入Uu接口RRC层技术要求
3GPPTS23.060通用分组无线服务业务描述（GeneralPacketRadioService（GPRS)；Servicedescription; Stage2)
3GPPTS25.301无线接口协议架构（RadioInterfaceProtocolArchitecture）3GPPTS26.101AMR语音编解码顿结构，语音编解码处理功能（Mandatoryspeechcodecspeechprocessing functions, Adaptive Multi-Rate (AMR) speech codec frame structure)3GPPTS26.201宽带AMR语音编解码结构，语音编解码处理功能（Speechcodecspeechprocessingfunctions;AdaptiveMulti-Rate-Wideband (AMR-WB)speechcodec;Framestructure)ETFRFC2507IP头压缩（IPHeaderCompression）IETFRFC3095鲁棒头压缩（RObustHeaderCompression(ROHC):Frameworkandfourprofiles:RTP,UDP, ESP, and uncompressed)
IETFRFC3096鲁棒IP/UDP/RTP头压缩的要求（RequirementsforrobustIP/UDP/RTPheadeicompression)
IETFRFC4815鲁棒头压缩：对RFC3095的纠错与澄清（RObustHeaderCompression(ROHC)Corrections andClarificationstoRFC3095)3缩略语
下列缩略语适用于本文件。
AcknowledgedMode
Adaptive Multi-Rate
Access Stratum
Context Identifier
确认模式
自适应多速率
接入层
上下文标识
HiiKAoNiKAca
YD/T2856.3-2015
Control Service Access PointCircuit Switched
Downlink
Discontinuous Transmission
Header Compression
IntermetEngineeringTaskForceInternet Protocol
Layer 2 (data link layer)
Layer 3 (network layer)
Multimedia Broadcast Multicast ServiceMobile Header Compressor
Mobile Header Compressor/DecompressorMobile Header Decompressor
Non Access Stratum
Network Header Compressor
Network Header Compressor/DecompressorNetwork Header Decompressor
Packet Data ConvergenceProtocolProtocol Data Unit
Packet Identifier
Point-to-Point Protocol
Packet Switched
Point-to-Point
Point-to-Multipoint
Radio Access Bearer
Radio Bearer
RequestForComments
Radio Link Control
Radio Network Controller
RObust Header Compression
Real Time Protocol
Service Access Point
Service Data Unit
Serving Radio Network SubsystemTransmission Control ProtocolTransparent Mode
User Datagram Protocol
控制服务接入点
电路交换
不连续发送
头压缩
互联网工程任务组
互联网协议
层2（数据链路层）
层3（网络层）
多媒体广播组播业务
移动头压缩
移动头压缩/解压缩
移动头解压缩
非接入层
网络头压缩
网络头压缩/解压缩
网络头解压缩
分组数据汇聚协议
协议数据单元
数据标识
点对点协议
分组交换
点对点
点对多点
无线接入承载
无线承载
建议请求
无线链路控制
无线网络控制器
鲁棒头压缩
实时协议
业务接入点
服务数据单元
服务无线网络子系统
传输控制协议
透明模式
用户数据报协议
HiiKAoNiKAca
4概述\）
4.1目标
UserEquipment此内容来自标准下载网
Uplink
Unacknowledged Mode
UniversalMobileTelecommunicationsSystemUMTsTerrestrialRadioAccess
UMTsTerrestrialRadioAccessNetwork用户设备
非确认模式
通用移动电信系统
YD/T2856.3-2015
UMTS陆地无线接入
UMTS陆地无线接入网络
本部分描述PDCP的功能。附录A是定义了ROHC性能测试，附录B定义了产生ROHC性能要求的参考模型。
4.2子层结构概述
无线接口协议架构中PDCP模块如图1所示。图1基于3GPPTS25.301中定义的无线接口协议架构。无线承载
PDCP-SDU
PDCP-SAPs
UM-SAP
协段，
SDU计数
AM-SAP
图1PDCP结构
TM-SAP
RLC-SDU
每一个PS域RAB与一个RB相关联，此RB与一个PDCP实体相关联。根据RB特性（即单向或双向）及RLC模式，每个PDCP实体与一个或者两个（每个方向一个）RLC实体相关联。PDCP实体位于PDCP子层。
每个PDCP实体使用零个、一个或者多个不同的头压缩协议。对于每个头压缩协议，每个单独的PDCP实体至多使用一个实例。UE可以定义多个PDCP实体，每个实体使用相同或者不同的头压缩协议集。在本部分版本中，只支持RFC2507（见IETFRFC2507）和ROHC（见IETFRFC3095和IETFRFC4815）两种头压缩协议。
每个CS域语音RAB与一个RB相关联，此RB与一个PDCP实体相关联。由于CS语音RB总是注\为了方便使用者对照阅读及编写者维护后续版本，本部分的章条号与所对应的3GPP标准保持一致。3
HiiKAoiKAca
YD/T2856.3-2015
双向的，因此每个PDCP实体与两个UMRLC实体相关联。PDCP实体位于PDCP子层。服务于CS业务的PDCP实体不使用头压缩。
PDCP子层由上层（见YD/T2857-2015《2GHzTD-SCDMA数字蜂窝移动通信网多载波高速分组接入Uu接口RRC层技术要求》）通过PDCP-C-SAP配置。图1描述了PDCP子层一种可能的结构：这一结构不限制实现。一个PDCP实体被映射到一个AMRLC实体，或者一至二个UM/TMRLC实体。当PDCP实体被映射到两个UM/TMRLC实体时，每个RLC实体被用于不同的方向。
5功能
PDCP向UE侧的NAS或者无线网络控制器（RNC）的中继器提供服务。分组数据汇聚协议应实现如下功能：分别在发送端和接收端实体对IP数据流进行头压缩和解压缩（例如：IPv4和IPv6的TCP/IP和RTP/UDP/IP头）
一用户数据传输。此功能用于在PDCP业务的用户间传送数据。一对于配置为支持无损SRNS重定位或者无损DLRLCPDU大小改变的无线承载进行PDCP序列号的维护。
一如果无线承载连接到一个CS域的无线接入承载上，传输CS计数器。一增加或者移除字节对齐的PDCPPDU填充。PDCP使用无线链路控制（RLC）子层提供的服务。5.1头压缩
头压缩协议与特定的网络层，传输层或者上层协议组合（例如TCP/IP和RTP/UDP/IP）所专用。网络层协议类型（例如IP或PPP）在PDP上下文激活时指定，PDP上下文激活在3GPPTS23.060中进行规定。对于每个PDCP实体，头压缩协议和头压缩协议参数由上层配置。在操作过程中对等PDCP实体间的压缩器和解压器初始信令是通过携带信令完成的。5.1.1映射PID值
依据上层配置（例如使用的PDCPPDU类型和头压缩协议），PDCP子层应能够识别头压缩协议的不同类型：如果是RFC2507：在一个头压缩协议里区分不同的头压缩协议包类型。以上需求通过在PDCPPDU里使用PID域实现。映射PID值的通用规则如下所列：一在每个PDCP实例中，PID值应独立映射到不同的分组类型。一PID值“0”指示“不压缩”。PDCPPDU中应使用PID值“0”指示发送端没有对PDCPPDU数据域中一个PDCPSDU进行改变，且接收端不应进行解压。一对于每个配置的头压缩协议，PID值应以上层配置的顺序，从1开始递增。第一个可用的PID值分配给当前头压缩协议的在本部分里定义的第一个头压缩协议包类型。对于每个头压缩协议，PID值被映射到头压缩协议里所定义的包类型，并且按照5.1.2.2和5.1.3.3节定义的顺序进行映射。PDCP实体重配头压缩协议后，此实体的PID值重映射。表1给出了一个PDCP实体配置了五种头压缩方法时PID值到包类型映射的例子，五种头压缩方法有：RFC2507（见IETFRFC2507)，MethodsA和B，ROHC（见IETFRFC3095和IETFRFC4815）4
HiiKAoNiKAca
和MethodC。MethodA，MethodB和MethodC用于图像压缩。表1PID值映射表示例
PID值
无头压缩
RFC2507
RFC2507
RFC2507
RFC2507
RFC2507
方法A
方法A
方法B
方法B
优化方法
全部头
压缩的TCP
压缩的TCPnondelta
压缩的非TCP
上下文状态
方法A的分组类型1
方法A的分组类型2
方法B的分组类型1
方法B的分组类型2
RFC3095,RFC4815
方法C
方法C
未分配的值
IP头压缩（RFC2507）
ROHC分组格式
方法C的分组类型1
方法C的分组类型2
YD/T2856.3-2015
包类型
RFC2507头压缩协议的详细操作在IETFRFC2507里规定。有关错误恢复和包重排序机制在RFC2507里也有说明。PDCP应在头压缩功能里包含这些机制。本部分里不涉及RFC2507头压缩功能的实现。
上下文标识
RFC2507的上下文标识只应包含在RFC2507包类型格式，如IETFRFC2507中定义。5.1.2.2RFC2507PID值映射
PID值应以表2所示顺序映射到RFC2507头压缩协议包类型。其中“n”为已经映射到其他协议包类型的PID值。
表2RFC2507头压缩协议PID值映射PID值
完整头传送管理
RFC2507
RFC2507
RFC2507
RFC2507
RFC2507
优化方法
完整头包的传送可根据低层信息控制。全部头
压缩的TCP
包类型
压缩的TCPnon-delta
压缩的非TCP
上下文状态
对于一个TCP流，如果PDCP接收到底层单个包失败传送信息，PDCP可在下一个包发送一个完整头。
对于非TCP流，如果PDCP接收到底层指示的完整头包已成功传输的信息，PDCP可以停止发送那些和前一个分组中包含相同完整头信息的完整头包。5.1.3鲁棒头压缩
HiiKAoiKAca
YD/T2856.3-2015
鲁棒头压缩（ROHC）协议详细操作在IETFRFC3095和IETFRFC4815里规定。5.1.3.1上下文标识
ROHC协议的上下文在IETFRFC3095和IETFRFC4815中定义。ROHC能配置支持一个或多个上下文。每个上下文通过上下文标识（CID）值标识。5.1.3.2空
5.1.3.3PID值映射
表3列出PID值应映射到鲁棒头压缩协议，其中n为已经分配给其他协议包类型的PID值。表3RFC3095头压缩协议PID值映射PID值
协议参数
优化方法
RFC3095，RFC4815
ROHC分组格式
ROHC包含两种类型参数（见IETFRFC3095和IETFRFC4815）：配置参数：这些参数是强制的，应在压缩器和解压器之间配置。实现参数：这些参数是可选的，如果使用，规定此压缩协议如何操作。这些参数划分为四种不同组，定义如下。一M：强制的且由上层配置的。
一MO：参数应支持，如果使用只能由上层配置或触发。包类型
一O：可选参数，上层不配置这些参数。只在本地使用（例如UTRAN和/或UE）。N/A：这些参数在ROHC没有使用。使用和定义的参数指定如下：
-MAXCID(M：可以使用最大的CID值。应为未压缩流预留一个CID值。-LARGECIDS：上层不配置这个值，而是通过MAXCID配置值推导出，推导规则如下：如果MAXCID>15则LARGECIDS=TRUE否则LARGECIDS=FALSE。PROFILES(M)：简表用来定义UE在上行链路允许使用哪个简表。在下行链路上，IETFRFC3095中定义的所有简表都应改被支持。FEEDBACKFOR(N/A):
一MRRU(M)：缺省情况不使用分段。-NOOFPACKETSIZESALLOWED(N/A)。-PACKET SIZES_ALLOWED (N/A)。-PAYLOAD_SIZES (O)。
-NO_OFPACKET SIZES_USED(O)。—PACKET_SIZES_USED(O)。
CONTEXT_REINITLALIZATION(MO)。MODE(O)。
CLOCKRESOLUTION(O)
一REVERSEDECOMPRESSION_DEPTH(M)：缺省值为没有使用预留解压器。6
HiiKAoNiKAca
5.1.3.6RRC配置
YD/T2856.3-2015
如果UE存储了“PDCPROHCTARGETMODE”变量，并且应用了ROHC简表，解压器应根据IETFRFC3095中指定的方式进行操作状态迁移，此时只能迁移到存储模式。如果UE没有存储“PDCPROHCTARGETMODE”变量，解压器可以根据IETFRFC3095进行任意操作状态的迁移。
5.3数据传输
如果配置了头压缩，发送端PDCP应在接收到上层PDCPSDU时执行头压缩。如果无线承载被配置为无损SRNS重定位或者无损DLRLCPDU大小改变，按照5.6.1.1节规定维护PDCP序列号，按照从上层接收的顺序递交PDCPPDU到底层。如果无线承载连接到CS域无线接入承载，发送端应如果PDCPSDU长度大于等于1比特：按照5.6.1.4节规定，在PDCPAMR数据PDU中包含CS计数器：在PDUtype域指示PDCPAMRPDU类型用PDCPSDU填充PDCPAMRPDU类型的数据域，按照8.2.4节规定添加填充位。注：如果上层没有生成AMR或者AMRWB慎，没有PDCPPDU向底层递交。当PDCP实体接收端收到底层的PDCPPDU时，一如果接收到的PDCPPDU是PDCPAMR数据PDU：从PDCPAMR数据PDU的数据域获得PDCPSDU。接收端由PDU数据域长度确定位对齐数据的内容和顿类型，当字节对齐时AMR和AMRWB有效负荷大小可能相同。向上层递交PDCPSDU和CS计数器，CS计数器从接收到的PDCP头中获得。否则：
对PDCPPDU执行头解压缩（如果配置了头压缩）以获取PDCPSDU：并且按照从底层接收的顺序递交PDCPSDU到上层·如果接收到的PDCPPDU是PDCPSeqNumPDU：●按照5.6.1.2节步骤执行。
RLC确认模式下的数据传输
图2所示为在RLC确认模式下的PDCP数据传输。发起方
PDCP用户
PDCP-DATALred
RIC-AM-DATA.req
RLC-AM-DATA.CHT
Acknowledgement
接收方
RLC-AM-DATAind
PDCP用户
PDCP-DATA.ind
注：如果原语RLC-AM-DATA.req使用了参数CNF，那么需要传递RLC-AM-DATA.cnf原语。否则，不需要传递RLC-AM-DATA.cnf原语。
图2RLC确认模式下的PDCP数据传输7
YD/T2856.3-2015
5.3.2RLC非确认模式和透明模式下的数据传输图3所示为在RLC非确认模式和透明模式下的PDCP数据传输。发起方
PDCP用户
PDCP-DATA.reC
RLC-UM-DATA.Ieq
RLC-TM-DATA.req
接收方
RLC-UM-DATAind
PDCP用户
RLC-TM-DATAind PDCP-DATA.ind图3RLC非确认模式和透明模式下的PDCP数据传输5.4SRNS重定位
如果发生SRNS重定位，上层指示PDCP对一个RB的压缩协议复位、重定位上下文或者释放。本部分版本中，重定位上下文只适用于RFC3095。每一个头压缩协议单独处理，但是重定位上下文能力对UE而言是可选的，它被作为UE无线接入能力的一部分。复位一个给定的压缩协议需要遵循：一在复位时压缩参数可以被上层重配，否则压缩参数仍然有效。一所有的压缩状态信息都被初始化，例如头压缩上下文。因此，SRNS重定位后第一个“压缩的”包类型为一个完整头。
-PDCP序列号不因PDCP头压缩协议复位而改变一个给定的压缩协议的上下文重定位需要遵循：在重定位上下文时配置的压缩参数仍然有效。压缩状态信息（上下文）的快照信息由源RNC传送到目标RNC，目标RNC根据传输的快照信息初始化头压缩协议。因此，在SRNS重定位后压缩（解压）继续使用重定位前的上下文。一在SRNS重定位时UE和UTRAN需要执行部分额外的动作以保持压缩器（解压器）一致。5.4.1无损SRNS重定位
无损SRNS重定位只适用于RLC配置为按序递交和确认模式下。是否支持无损SRNS重定位由上层配置。
为了支持无损SRNS重定位，PDCP实体需要维护PDCPSDU序列号，如5.6.1.1节描述。PDCP发送端和接收端之间的序列号是同步的，如5.6.1.2节描述。在执行无损SRNS重定位时UE和UTRAN之间的序列号被交换，序列号用来确认已经发送但没有被接收端确认的PDCPSDU，如5.6.1.3节描述。重定位后从第一个没有被确认的PDCPSDU开始传输。5.4.1.1空
5.4.1.2空
5.4.1.3空
5.4.2上下文重定位
头压缩上下文重定位的执行是由源RNC的上层依据UE的无线能力决定的。每次SRNS重定位发生8
YD/T2856.3-2015
时这种判决都是相互独立的，并且与特定的头压缩协议相关。对于UE而言，这意味着判决作为上层SRNS重定位信令的一部分，并且选择重定位的方法是由上层配置给UEPDCP的。如果无线承载配置为支持无损SRNS重定位，那么不应当执行头压缩上下文重定位。在UE端，如果接收到SRNS重定位发生指示：上层配置PDCP（CPDCP-CONFIGReq)或者执行复位（R），或者进行头压缩协议的上下文重定位(C);
一如果上下文重定位应用于RFC3095头压缩协议：如果压缩器(M-HC)操作在R模式：上行数据可正常压缩和传输。
·如果压缩器(M-HC)操作在O模式：假定所有的ROHC上行数据包传输都有可能丢失，按照IETFRFC3095中规定压缩和传输上行数据。当SRNS重定位完成后，M-HC应返回到正常模式。注：当M-HC假定所有的ROHC上行数据包传输都有可能丢失时：■M-HC不能够转移到更高的压缩状态；■对于W-LSB编码，M-HC通过添加新传输的值而不移除旧值的方法来更新解压器使用的候选参考值集。
·如果压缩器(M-HC)操作在U模式：(M-HC)应转移到FO状态，并且发送IR-DYN以同步上行链路上下文的动态部分。·如果解压器(M-HD)应用了反转解压器：通过丢弃缓冲里所有的包来刷新反转解压器缓冲。·对于所有模式的解压器(M-HD)：正常接收和解压下行链路数据。在UTRAN源RNC端，当SRNS重定位发生：一如果上下文重定位应用于RFC3095头压缩协议·上层请求PDCP抓取一个上下文快照(CPDCP-CONTEXT.Req)：·如果压缩器（源N-HC）操作在R模式：源N-HC应当抓取一个其自身头压缩上下文的快照（以N-context-C*标识）：，头压缩上下文不应更新，即使下行数据有可能在非正常情况下压缩和传输。通过发送R-1*包可以完成。
·如果压缩器（源N-HC）操作在O模式：·源N-HC应当抓取一个其自身头压缩上下文的快照（以N-context-C*标识）：抓取之后，源N-HC只可以发送UO-O或UO-1*包。这意味着M-HD解压器上下文中只有RTPSNRTPTS，和IP-ID（只针对IPv4)域被更新。·如果压缩器（源N-HC）操作在U模式：+源N-HC应当抓取一个其自身头压缩上下文静态部分的快照（以N-context-C-static*标识）。·如果解压器（源N-HD）操作在R或O模式：+如果源N-HD确信N-context-D的完整性：9
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。