3GPPPDCP中文协议36323.docx
《3GPPPDCP中文协议36323.docx》由会员分享，可在线阅读，更多相关《3GPPPDCP中文协议36323.docx（25页珍藏版）》请在冰豆网上搜索。
3GPPPDCP中文协议36323
200X–XX–XX印发
中国通信标准化协会
LTEFDD数字蜂窝移动通信网
Uu接口技术要求
第8部分：
PDCP
LTEFDDdigitalcellularmobiletelecommunicationnetwork
UuInterfaceTechnicalRequirement–Part8 :
PDCP
1目次
2前言
YDBXXXX-XXXX《LTEFDD数字蜂窝移动通信网Uu接口技术要求》分为九个部分：
─第1部分：
物理层概述；
─第2部分：
物理信道和调制
─第3部分：
物理层复用和信道编码
─第4部分：
物理层过程
─第5部分：
物理层测量
─第6部分：
MAC协议
─第7部分：
RLC协议
─第8部分：
PDCP协议
─第9部分：
RRC协议
本部分是第8部分。
与3GPPTS36.323-900的技术内容保持一致。
YDBXXXX-XXXX《LTEFDD数字蜂窝移动通信网Uu接口技术要求》是LTEFDD数字蜂窝移动通信网系列技术报告之一，该系列技术报告的结构和名称预计如下：
a）YDBXXXX-XXXX《LTE数字蜂窝移动通信网无线接入部分总体技术要求》
b）YDBXXXX-XXXX《LTEFDD数字蜂窝移动通信网Uu接口技术要求》
─第1部分：
物理层概述；
─第2部分：
物理信道和调制
─第3部分：
物理层复用和信道编码
─第4部分：
物理层过程
─第5部分：
物理层测量
─第6部分：
MAC协议
─第7部分：
RLC协议
─第8部分：
PDCP协议
─第9部分：
RRC协议
c）YDBXXXX-XXXX《LTE数字蜂窝移动通信网X2接口技术要求》
─第1部分：
概述；
─第2部分：
层1
─第3部分：
信令传输
─第4部分：
应用协议
─第5部分：
数据传输
d）YDBXXXX-XXXX《LTE数字蜂窝移动通信网S12接口技术要求》
─第1部分：
概述；
─第2部分：
层1
─第3部分：
信令传输
─第4部分：
应用协议
─第5部分：
数据传输
本部分的附录A、附录B均为规范性/资料性附录。
为适应信息通信业发展对通信标准文件的需要，在工业和信息化部的统一安排下，对于技术尚在发展中，又需要有相应的标准性文件引导其发展的领域，由中国通信标准化协会组织制定“通信标准类技术报告”，推荐有关方面参考采用。
有关对本技术报告的建议和意见，向中国通信标准化协会反映。
本部分由中国通信标准化协会提出并归口。
本部分起草单位：
工业和信息化部电信研究院、中国移动通信集团、大唐电信科技产业集团、中兴通讯股份有限公司、华为技术有限公司、南京爱立信熊猫通信有限公司、诺基亚西门子通信（上海）有限公司、广州新邮通信有限公司、上海贝尔股份有限公司、鼎桥通信技术有限公司、中国普天信息产业股份有限公司、诺基亚通信有限公司、北京天碁科技有限责任公司、重庆重邮信科股份有限公司、北京展讯高科通信技术有限公司
本部分主要起草人：
LTEFDD数字蜂窝移动通信网Uu接口技术要求第8部分：
PDCP
21 范围
本部分规定了LTEFDD数字蜂窝移动通信网Uu接口的分组数据汇聚协议（PDCP），包括PDCP架构、PDCP过程、协议数据单元、格式及参数、和变量、常量及定时器。
本部分适用于LTEFDD数字蜂窝移动通信网。
22 规范性引用文件
下列文件中的条款通过本部分的引用而成为部分的条款。
凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于部分，然而，鼓励根据本部分达成协议的各方研究是否可使用这些文件的最新版本。
凡是不注日期的引用文件，其最新版本适用于本部分。
。
。
。
。
。
。
23 术语、定义和缩略语
术语和定义
下列术语和定义适用于本部分。
缩略语
下列缩略语适用于本部分。
AM
AcknowledgedMode
确认模式
CID
ContextIdentifier
上下文标识符
DRB
DataRadioBearercarryinguserplanedata
数据无线承载，携带用户面数据
EPS
EvolvedPacketSystem
演进型分组系统
E-UTRA
EvolvedUMTSTerrestrialRadioAccess
演进型UMTS全球地面无线接入
E-UTRAN
EvolvedUMTSTerrestrialRadioAccessNetwork
演进型UMTS全球地面无线接入网
eNB
E-UTRANNodeB
E-UTRANNodeB
FMS
FirstmissingPDCPSN
第一个缺失的PDCPSN
HFN
HyperFrameNumber
超帧号
IETF
InternetEngineeringTaskForce
因特网工程任务组
IP
InternetProtocol
因特网协议
L2
Layer2（datalinklayer）
层2（数据链路层）
L3
Layer3（networklayer）
层3（网络层）
MAC
MediumAccessControl
媒体接入控制
MAC-I
MessageAuthenticationCodeforIntegrity
消息完整性认证码
PDCP
PacketDataConvergenceProtocol
分组数据汇聚协议
PDU
ProtocolDataUnit
协议数据单元
R
Reserved
保留
RB
RadioBearer
无线承载
RFC
RequestForComments
请求注解
RLC
RadioLinkControl
无线链路控制
ROHC
RObustHeaderCompression
可靠头压缩
RRC
RadioResourceControl
无线资源控制
RTP
RealTimeProtocol
实时协议
SAP
ServiceAccessPoint
业务接入点
SDU
ServiceDataUnit
业务数据单元
SN
SequenceNumber
序列号
SRB
SignallingRadioBearercarryingcontrolplanedata
信令无线承载，携带控制平面数据
TCP
TransmissionControlProtocol
传输控制协议
UDP
UserDatagramProtocol
用户数据协议
UE
UserEquipment
用户设备
UM
UnacknowledgedMode
非确认模式
X-MAC
ComputedMAC-I
MAC-I计算值
24 概述
PDCP架构
PDCP结构
图1描述了PDCP子层一种可能的结构；PDCP子层的结构不宜限制实现。
此图基于[2]中定义的无线接口协议架构。
图1PDCP层，结构视图
每个RB（即，DRB和SRB，除去SRB0）关联于一个PDCP实体。
根据RB特性（即：
单向或双向）及RLC模式，每个PDCP实体关联于一个或两个（每个方向一个）RLC实体。
PDCP实体位于PDCP子层。
PDCP子层由上层配置，上层在[3]中进行规定。
PDCP实体
PDCP实体位于PDCP子层。
可以为一个UE定义多个PDCP实体。
可以对携带用户面数据的每个PDCP实体进行配置，来使用头压缩。
每个PDCP实体携带一个无线承载的数据。
本文档的当前版本只支持可靠头压缩协议（ROHC）。
每个PDCP实体使用最多一个ROHC。
根据无线承载所携带的数据，PDCP实体对应于控制平面或者用户平面。
图2描述了PDCP子层中PDCP实体的功能视图；其不宜限制实现。
此图基于[2]中定义的无线接口协议架构。
图2PDCP层，功能视图
业务
提供给上层的服务
PDCP向RRC层以及UE侧用户平面的上层提供服务，或向eNB的转发器提供服务。
PDCP向上层提供如下服务：
-用户平面数据的传输；
-控制平面数据的传输；
-头压缩；
-加密；
-完整性保护。
支持的最大PDCPSDU为8188个八位元组。
从底层获得的服务
下列功能的详细描述见[5]。
-确认数据传输服务，包括PDCPPDU成功传输的标识；
-非确认数据传输服务；
-按序传输，除了下层的重建；
-重复丢弃，除了下层的重建。
功能
分组数据汇聚协议支持以下功能：
-使用ROHC协议对IP数据流进行头压缩和解压缩；
-数据传输（用户平面或控制平面）；
-对PDCPSN值的维护；
-在下层重建的时候，按序传递上层PDU；
-在下层重建的时候，为映射到RLCAM的无线承载重复丢弃下层SDU；
-对用户平面数据及控制平面数据的加密及解密；
-控制平面数据的完整性保护及完整性验证；
-定时丢弃；
-副本丢弃。
PDCP使用RLC子层提供的服务。
PDCP用于映射到DCCH及DTCH类型逻辑信道的SRB及DRB。
PDCP不能用于其它类型的逻辑信道。
可传数据
为了上报MAC的缓存状态，UE应认为PDCP控制PDU及以下所述数据作为PDCP层中的可传数据：
对于没有向底层传递PDU的SDU：
•SDU本身，如果SDU还没有被PDCP处理，或
•PDU，如果SDU已被PDCP处理。
另外，对于映射到RLCAM的无线承载，如果PDCP实体之前执行了重建程序，则UE还应视PDCP层的以下数据可传：
对于在PDCP重建之前有一个相应PDU传递给底层的SDU，从对应的PDU传输没有被低层确认的第一个SDU开始，除了被标识为PDCP状态传输成功的SDU，如果接收到：
•SDU，如果此SDU还没有被PDCP处理，或者
•PDU，一旦此SDU被PDCP处理。
25 PDCP过程
PDCP数据传输过程
UL数据传输过程
从上层接收到PDCPSDU以后，UE应：
-启动与此PDCP相关联的discardTimer（如果已配置）；
对于从上层接收到的PDCPSDU，UE应：
-关联相应于Next_PDCP_TX_SN的PDCPSN到PDCPSDU；
-按照5.5.4节的说明执行PDCPSDU的头压缩（如果已配置）
-执行完整性保护（如适用），并使用基于TX_HFN的COUNT以及关联于PDCPSDU的PDCPSN值进行加密，COUNT与PDCPSN值的描述分别见5.7节和5.6节；
-将Next_PDCP_TX_SN增加1；
-如果Next_PDCP_TX_SN>Maximum_PDCP_SN：
•将Next_PDCP_TX_SN置为0；
•将TX_HFN增加1；
-将最后产生的PDCPDataPDU传送给低层。
DL数据传输过程
DRB过程
空闲
映射到RLCAM的DRB过程
对于映射到RLCAM的DRB，在接收到低层的PDCPDataPDU时，UE应：
-如果接收到的PDCPSN–Last_Submitted_PDCP_RX_SN>Reordering_Window或者0<=Last_Submitted_PDCP_RX_SN–接收到的PDCPSN•如果接收到的PDCPSN>Next_PDCP_RX_SN：
o使用基于RX_HFN–1的COUNT与接收到的PDCPSN值，解密此PDCPPDU，如5.6节所述；
•否则：
o使用基于RX_HFN的与接收到的PDCPSN值，解密此PDCPPDU，如5.6节所述；
•执行头压缩（如果已配置），如5.5.5节所述；
•丢弃此PDCPSDU；
-否则如果Next_PDCP_RX_SN–接收的PDCPSN>Reordering_Window：
•将RX_HFN增加1；
•使用基于RX_HFN与接收的PDCPSN值解密此PDCPPDU；
•将Next_PDCP_RX_SN置为接收到的PDCPSN+1；
-否则如果接受的PDCPSN–Next_PDCP_RX_SN>=Reordering_Window：
•使用基于RX_HFN–1的COUNT值与接收到的PDCPSN值解密此PDCPPDU；
-否则如果接收到的PDCPSN>=Next_PDCP_RX_SN：
•使用基于RX_HFN的CONUT值与接收到的PDCPSN值解密此PDCPPDU；
•将Next_PDCP_RX_SN置为接收到的PDCPSN+1；
•如果Next_PDCP_RX_SN大于Maximum_PDCP_SN：
o将Next_PDCP_RX_SN置为0；
o将RX_HFN增加1；
-否则如果接收到的PDCPSN•使用基于RX_HFN的COUNT值与接收到的PDCPSN值解密此PDCPPDU；
-如果上面没有丢弃此PDCPPDU：
•执行PDCPPDU的解密与头解压缩（如果配置），分别如5.6节和5.5.5节所述；
•如果一个具有相同PDCPSN值的PDCPPDU被存储；
o丢弃此PDCPSDU；
•否则：
o存储此PDCPSDU；
•如果由于下层重建导致PDCP没有接收到此PDCPPDU：
o把相关的COUNT值按升序传递给上层：
▪所有存储的，相关COUNT值小于接收PDCPSDU的COUNT值的PDCPSDU；
▪所有存储的，从接收到的PDCPSDU的COUNT值开始，连续COUNT值对应的PDCPSDU；
o将Last_Submitted_PDCP_RX_SN置为最后递交给高层的PDCPSDU的PDCPSN值；
•否则如果接收到的PDCPSN=Last_Submitted_PDCP_RX_SN+1，或者接收到的PDCPSN=Last_Submitted_PDCP_RX_SN–Maximum_PDCP_SN：
o把相关COUNT值按升序传递给上层：
▪所有存储的，从接收到的PDCPSDU的COUNT值开始，连续COUNT值对应的PDCPSDU；
o将Last_Submitted_PDCP_RX_SN置为最后递交给高层的PDCPSDU的PDCPSN值。
映射到RLCUM的DRB过程
对于映射到RLCUM的DRB，在接收到低层的PDCPDataPDU以后，UE应：
-如果接收到的PDCPSN•将RX_HFN增加1；
-使用基于RX_HFN的COUNT值与接收到的PDCPSN值，解密此PDCPDataPDU，如5.6节所述；
-将Next_PDCP_RX_SN置为接收到的PDCPSN值+1；
-如果Next_PDCP_RX_SN>Maximum_PDCP_SN：
•将Next_PDCP_RX_SN置为0；
•将RX_HFN增加1；
-执行已解密PDCPDataPDU的头解压缩（如果配置），如5.5.5节所述；
-将最后产生的PDCPSDU递交给上层。
SRB过程
对于SRB，在接收到低层的PDCPDataPDU以后，UE应：
-如果接收的PDCPSN•使用基于RX_HFN+1的COUNT值与接收到的PDCPSN值来解密PDU及确认PDU的完整性，分别如5.6节及5.7节所述；
-否则：
•使用基于RX_HFN的COUNT值与接收到的PDCPSN值来解密此PDU及确认其完整性（如适用），分别如5.6节和5.7节所述；
-如果完整性确认使用，并且成功通过；或者
-如果完整性确认不适用：
•如果接收的PDCPSNo将RX_HFN增加1；
•将Next_PDCP_RX_SN置为接收到的PDCPSN值+1；
•如果Next_PDCP_RX_SN>Maximum_PDCP_SN：
o将Next_PDCP_RX_SN置为0；
o将RX_HFN增加1；
•将最后产生的PDCPSDU递交给上层；
-否则，如果完整性确认适用，但是失败：
•丢弃接收到的PDCPDataPDU；
•将完整性确认失败报告给上层。
重建过程
当上层请求一个PDCP重建时，UE应为对应的RLC模式额外再执行一次本节所述的过程。
在执行完本节的过程后，UE应接着执行5.1节中的过程。
UL数据传输过程
映射到RLCAM的DRB过程
当上层请求一次PDCP重建时，UE应：
-重置上行链路的头压缩协议（如果已配置）；
-在重建过程期间，使用加密算法及上层提供的key加密；
-从第一个对应的PDCPPDU成功传递但没有被下层确认的PDCPSDU开始，在如下所述的PDCP重建之前，执行所有从此PDCPSDU对应的COUNT值开始，按COUNT值升序排列的PDCPSN值对应的PDCPSDU的重传或传输：
-执行PDCPSDU的头压缩（如果已配置），如5.5.4节所述；
-使用关联于此PDCPSDU的COUNT值，加密此PDCPSDU，如5.6节所述；
-将最后产生的PDCPDataPDU传递给下层。
映射到RLCUM的DRB过程
当上层请求一次PDCP重建时，UE应：
-重置上行链路的头压缩协议（如果已配置）；
-置Next_PDCP_TX_SN，及TX_HFN为0；
-在重建进程期间，使用加密算法及上层提供的key加密；
-对于每一个已经对应于一个PDCPSN值，但相应的PDU没有事先传递给低层的PDCPSDU：
•认为此PDCPSDU是从上层接收而来；
•在PDCP重建之前，在不重启discardTimer的情况下，按照与PDCPSDU关联的COUNT值的升序传输PDCPSDU，如5.1.1节所述。
SRB过程
当上层请求一个PDCP重建时，UE应：
-置Next_PDCP_TX_SN和TX_HFN为0；
-丢弃所有存储的PDCPSDU和PDCPPDU；
-在重建进程期间，使用加密及完整性保护算法和上层提供的key进行加密。
DL数据传输过程
映射到RLCAM的DRB过程
当上层请求一个PDCP重建时，UE应：
-处理由于下层重建而从下层接收来的PDCPDataPDU，如5.1.2.1.2节所述；
-重置下行链路的头压缩协议（如果已配置）；
-在重建进程期间，使用加密算法和上层提供的key进行加密。
映射到RLCUM的DRB过程
当上层请求一个PDCP重建时，UE应：
-处理由于下层重建而从下层接收来的PDCPDataPDU，如5.1.2.1.3节所述；
-重置下行链路的头压缩协议（如果已配置）；
-置Next_PDCP_RX_SN和RX_HFN为0；
-在重建进程期间，使用加密算法和上层提供的key进行加密。
SRB过程
当上层请求一个PDCP重建时，UE应：
-丢弃由于下层重建而从下层接收来的PDCPDataPDU；
-置Next_PDCP_RX_SN和RX_HFN为0；
-丢弃所有存储的PDCPSDU和PDCPPDU；
-在重建进程期间，使用加密及完整性保护算法和上层提供的key进行加密。
PDCP状态上报
传输操作
对于映射到RLCAM的无线承载，当上层请求一个PDCP重建时，UE应：
-如果此无线承载被上层配置用于在上行链路发送一个PDCP状态上报（statusReportRequired见[3]），在处理完由于下层重建而从下层接受来的PDCPDataPDU以后，UE按照如下的指示编译此状态上报，如5.2.2.1节所述，并将此状态上报作为此传输的第一个PDCPPDU传递给低层：
•将FMS域置为第一个丢失的PDCPSDU的PDCPSN值；
•如果至少有一个失序PDCPSDU被存储，则分配一个Bitmapfield，长度等于从第一个丢失的PDCPSDU（但不包括）开始直到最后一个失序的PDCPSDU（包括最后一个）的PDCPSN的个数，四舍五入到下一个8的倍数；
•将所有底层指示还未接收到的PDCPSDU以及任意解压缩失败的PDCPSDU在Bitmapfield中对应的区域置为“0”；
•对于其他的PDCPSDU，对应的区域置为“1”。
接收操作
当在下行链路接收到一个PDCP状态上报时，对于映射到RLCAM的无线承载：
-对于每个PDCPSDU，如果在Bitmap中对应的bit位为“1”，或者相关联的COUNT值小于FMS字段确定的PDCPSDU的COUNT值，则相应PDCPSDU的成功传输将被确认，且UE应按5.4节的规定处理此PDCPSDU。
PDCP丢弃
当用于PDCPSDU的discardTimer终止，或PDCPSDU的成功传输被PDCP状态上报确认，UE应丢弃此PDCPSDU连同对应的PDCPPDU。
如果对应的PDCPPDU已经成功传递给下层，则此丢弃需要指示给下层。
头压缩与解压缩
支持的头压缩协议与简表（profile）
头压缩协议基于可靠性头压缩（ROHC）框架[7]。
存在多种头压缩算法，称之为简表，定义用于ROHC框架。
每个简表为特定的网络层、传输层或上层集合（例如TCP/IP与RTP/UDP/IP）所专用。
ROHC信道的详细定义在[7]中规定为ROHC框架的一部分。
包括在ROHC信道上不同流（头压缩或不压缩）的复用，以及在流压缩算法的初始化期间特定IP流与特定文本状态的关联。
本部分不涉及ROHC框架功能的实现以及所支持的头压缩简表功能的实现。
本部分描述了如下简表的支持：
表1支持的头压缩协议与简表
ProfileIdentifier
Usage:
Reference
0x0000
Nocompression
RFC4995
0x0001
RTP/UDP/IP
RFC3095,RFC4815
0x0002
UDP/IP
RFC3095,RFC4815
0x0003
ESP/IP
RFC3095,RFC4815
0x0004
IP
RFC3843,RFC4815
0x0006
TCP/IP
RFC4996
0x0101
RTP/UDP/IP
RFC5225
0x0102
UDP/IP
RFC5225
0x0103
ESP/IP
RFC5225
0x0104
IP
RFC5225
头压缩的配置
与DRB关联的PDCP实体可被上层配置来使用头压缩。
协议参数
在压缩端和解压缩端之间，[7]定义了必须由上层配置的强制配置参数；这些参数定义ROHC信道。
ROHC信道是单向信道，即一个信道用于上行，一个用于下行。
因此，对于每个信道都有一个参数集，对于属于同一个PDCP实体的信道应使用相同的配置值。
这些参数被归类到两个不同的组中，定义如下：
-M：
强制的且由上层配置的。
-N/A：
本部分中不适用。
升级会员 