3GPPPDCP中文协议36323.docx

1、3GPPPDCP中文协议36323200X XX XX 印发中国通信标准化协会 LTE FDD数字蜂窝移动通信网Uu接口技术要求第8部分：PDCPLTE FDD digital cellular mobile telecommunication network Uu Interface Technical Requirement Part 8: PDCP 1目 次 2前 言YDB XXXX-XXXX LTE FDD数字蜂窝移动通信网 Uu接口技术要求分为九个部分：第1部分：物理层概述；第2部分：物理信道和调制第3部分：物理层复用和信道编码第4部分：物理层过程第5部分：物理层测量第6部分：MAC

2、协议第7部分：RLC协议第8部分：PDCP协议第9部分：RRC协议本部分是第8部分。与3GPP TS 36.323-900的技术内容保持一致。YDB XXXX-XXXX LTE FDD数字蜂窝移动通信网 Uu接口技术要求是LTE FDD数字蜂窝移动通信网系列技术报告之一，该系列技术报告的结构和名称预计如下：a）YDB XXXX-XXXX LTE数字蜂窝移动通信网 无线接入部分总体技术要求b）YDB XXXX-XXXX LTE FDD数字蜂窝移动通信网 Uu接口技术要求第1部分：物理层概述；第2部分：物理信道和调制第3部分：物理层复用和信道编码第4部分：物理层过程第5部分：物理层测量第6部分：M

3、AC协议第7部分：RLC协议第8部分：PDCP协议第9部分：RRC协议c）YDB XXXX-XXXX LTE数字蜂窝移动通信网 X2接口技术要求第1部分：概述；第2部分：层1第3部分：信令传输第4部分：应用协议第5部分：数据传输d）YDB XXXX-XXXX LTE数字蜂窝移动通信网 S12接口技术要求第1部分：概述；第2部分：层1第3部分：信令传输第4部分：应用协议第5部分：数据传输本部分的附录A、附录B均为规范性/资料性附录。为适应信息通信业发展对通信标准文件的需要，在工业和信息化部的统一安排下，对于技术尚在发展中，又需要有相应的标准性文件引导其发展的领域，由中国通信标准化协会组织制定“通

4、信标准类技术报告”，推荐有关方面参考采用。有关对本技术报告的建议和意见，向中国通信标准化协会反映。本部分由中国通信标准化协会提出并归口。本部分起草单位：工业和信息化部电信研究院、中国移动通信集团、大唐电信科技产业集团、中兴通讯股份有限公司、华为技术有限公司、南京爱立信熊猫通信有限公司、诺基亚西门子通信（上海）有限公司、广州新邮通信有限公司、上海贝尔股份有限公司、鼎桥通信技术有限公司、中国普天信息产业股份有限公司、诺基亚通信有限公司、北京天碁科技有限责任公司、重庆重邮信科股份有限公司、北京展讯高科通信技术有限公司本部分主要起草人：LTE FDD数字蜂窝移动通信网 Uu接口技术要求 第8部分：PD

5、CP21范围本部分规定了LTE FDD数字蜂窝移动通信网Uu接口的分组数据汇聚协议（PDCP），包括PDCP架构、PDCP过程、协议数据单元、格式及参数、和变量、常量及定时器。本部分适用于LTE FDD数字蜂窝移动通信网。22规范性引用文件下列文件中的条款通过本部分的引用而成为部分的条款。凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于部分，然而，鼓励根据本部分达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本部分。23术语、定义和缩略语术语和定义下列术语和定义适用于本部分。缩略语下列缩略语适用于本部分。AMAcknowle

6、dged Mode确认模式CIDContext Identifier上下文标识符DRBData Radio Bearer carrying user plane data数据无线承载，携带用户面数据EPSEvolved Packet System演进型分组系统E-UTRAEvolved UMTS Terrestrial Radio Access演进型UMTS全球地面无线接入E-UTRANEvolved UMTS Terrestrial Radio Access Network演进型UMTS全球地面无线接入网eNBE-UTRAN Node BE-UTRAN Node BFMSFirst miss

7、ing PDCP SN第一个缺失的PDCP SNHFNHyper Frame Number超帧号IETFInternet Engineering Task Force因特网工程任务组IPInternet Protocol因特网协议L2Layer 2 (data link layer)层2（数据链路层）L3Layer 3 (network layer)层3（网络层）MACMedium Access Control媒体接入控制MAC-IMessage Authentication Code for Integrity消息完整性认证码PDCPPacket Data Convergence Proto

8、col分组数据汇聚协议PDUProtocol Data Unit协议数据单元RReserved保留RBRadio Bearer无线承载RFCRequest For Comments请求注解RLCRadio Link Control无线链路控制ROHCRObust Header Compression可靠头压缩RRCRadio Resource Control无线资源控制RTPReal Time Protocol实时协议SAPService Access Point业务接入点SDUService Data Unit业务数据单元SNSequence Number序列号SRBSignalling R

9、adio Bearer carrying control plane data信令无线承载，携带控制平面数据TCPTransmission Control Protocol传输控制协议UDPUser Datagram Protocol用户数据协议UEUser Equipment用户设备UMUnacknowledged Mode非确认模式X-MACComputed MAC-IMAC-I计算值24概述PDCP架构PDCP结构图1 描述了PDCP子层一种可能的结构；PDCP子层的结构不宜限制实现。此图基于2中定义的无线接口协议架构。图1 PDCP层，结构视图每个RB（即，DRB和SRB，除去SRB0

10、）关联于一个PDCP实体。根据RB特性（即：单向或双向）及RLC 模式，每个PDCP实体关联于一个或两个（每个方向一个）RLC实体。PDCP实体位于PDCP子层。PDCP子层由上层配置，上层在3中进行规定。PDCP实体PDCP实体位于PDCP子层。可以为一个UE定义多个PDCP实体。可以对携带用户面数据的每个PDCP实体进行配置，来使用头压缩。每个PDCP实体携带一个无线承载的数据。本文档的当前版本只支持可靠头压缩协议（ROHC）。每个PDCP实体使用最多一个ROHC。根据无线承载所携带的数据，PDCP实体对应于控制平面或者用户平面。图2 描述了PDCP子层中PDCP实体的功能视图；其不宜限制

11、实现。此图基于2中定义的无线接口协议架构。图2 PDCP层，功能视图业务提供给上层的服务PDCP向RRC层以及UE侧用户平面的上层提供服务，或向eNB的转发器提供服务。PDCP向上层提供如下服务：-用户平面数据的传输；-控制平面数据的传输；-头压缩；-加密；-完整性保护。支持的最大PDCP SDU为8188 个八位元组。从底层获得的服务下列功能的详细描述见5。-确认数据传输服务，包括PDCP PDU成功传输的标识；-非确认数据传输服务；-按序传输，除了下层的重建；-重复丢弃，除了下层的重建。功能分组数据汇聚协议支持以下功能：-使用ROHC协议对IP数据流进行头压缩和解压缩；-数据传输（用户平面

12、或控制平面）；-对PDCP SN 值的维护；-在下层重建的时候，按序传递上层PDU；-在下层重建的时候，为映射到RLC AM的无线承载重复丢弃下层SDU；-对用户平面数据及控制平面数据的加密及解密； -控制平面数据的完整性保护及完整性验证；-定时丢弃；-副本丢弃。PDCP使用RLC子层提供的服务。PDCP用于映射到DCCH 及DTCH类型逻辑信道的SRB及DRB。PDCP不能用于其它类型的逻辑信道。可传数据为了上报MAC的缓存状态，UE应认为PDCP控制PDU及以下所述数据作为PDCP层中的可传数据： 对于没有向底层传递PDU的SDU：SDU本身，如果SDU还没有被PDCP处理，或PDU，如果

13、SDU已被PDCP处理。另外，对于映射到RLC AM的无线承载，如果PDCP实体之前执行了重建程序，则UE还应视PDCP层的以下数据可传：对于在PDCP重建之前有一个相应PDU传递给底层的SDU，从对应的PDU传输没有被低层确认的第一个SDU开始，除了被标识为PDCP状态传输成功的SDU，如果接收到：SDU，如果此SDU还没有被PDCP处理，或者PDU，一旦此SDU被PDCP处理。25PDCP过程PDCP数据传输过程UL数据传输过程从上层接收到PDCP SDU以后，UE应：-启动与此PDCP相关联的discardTimer（如果已配置）；对于从上层接收到的PDCP SDU，UE应：-关联相应于

14、Next_PDCP_TX_SN 的PDCP SN到PDCP SDU；-按照5.5.4节的说明执行PDCP SDU的头压缩（如果已配置）-执行完整性保护（如适用），并使用基于TX_HFN的COUNT 以及关联于PDCP SDU的PDCP SN 值进行加密，COUNT与PDCP SN值的描述分别见5.7节和5.6节；-将Next_PDCP_TX_SN 增加1；-如果Next_PDCP_TX_SN Maximum_PDCP_SN：将Next_PDCP_TX_SN 置为0；将TX_HFN 增加1；-将最后产生的PDCP Data PDU 传送给低层。DL数据传输过程DRB过程空闲映射到RLC AM的D

15、RB过程对于映射到RLC AM的DRB，在接收到低层的PDCP Data PDU时，UE应：-如果接收到的PDCP SNLast_Submitted_PDCP_RX_SN Reordering_Window 或者 0 = Last_Submitted_PDCP_RX_SN接收到的 PDCP SN Next_PDCP_RX_SN：o使用基于RX_HFN 1的COUNT与接收到的PDCP SN值，解密此PDCP PDU，如5.6节所述；否则：o使用基于RX_HFN的与接收到的PDCP SN值，解密此PDCP PDU，如5.6节所述；执行头压缩（如果已配置），如5.5.5节所述；丢弃此PDCP SD

16、U；-否则如果Next_PDCP_RX_SN 接收的PDCP SN Reordering_Window：将RX_HFN 增加1；使用基于RX_HFN与接收的PDCP SN值解密此PDCP PDU；将Next_PDCP_RX_SN 置为接收到的PDCP SN + 1；-否则如果接受的 PDCP SN Next_PDCP_RX_SN = Reordering_Window：使用基于RX_HFN 1的COUNT值与接收到的PDCP SN值解密此PDCP PDU；-否则如果接收到的PDCP SN = Next_PDCP_RX_SN：使用基于RX_HFN的CONUT值与接收到的PDCP SN值解密此PD

17、CP PDU；将Next_PDCP_RX_SN 置为接收到的PDCP SN + 1；如果Next_PDCP_RX_SN 大于Maximum_PDCP_SN：o将Next_PDCP_RX_SN 置为0；o将RX_HFN 增加1；-否则如果接收到的PDCP SN Next_PDCP_RX_SN：使用基于RX_HFN的COUNT值与接收到的PDCP SN值解密此PDCP PDU；-如果上面没有丢弃此PDCP PDU：执行PDCP PDU的解密与头解压缩（如果配置），分别如5.6节和5.5.5节所述；如果一个具有相同PDCP SN值的PDCP PDU被存储；o丢弃此PDCP SDU；否则：o存储此PD

18、CP SDU；如果由于下层重建导致PDCP 没有接收到此PDCP PDU：o把相关的COUNT值按升序传递给上层：所有存储的，相关COUNT值小于接收PDCP SDU的COUNT值的PDCP SDU；所有存储的，从接收到的PDCP SDU的COUNT值开始，连续COUNT值对应的PDCP SDU；o将Last_Submitted_PDCP_RX_SN 置为最后递交给高层的PDCP SDU的PDCP SN值；否则如果接收到的PDCP SN = Last_Submitted_PDCP_RX_SN + 1，或者接收到的PDCP SN = Last_Submitted_PDCP_RX_SN Maxim

19、um_PDCP_SN：o把相关COUNT值按升序传递给上层：所有存储的，从接收到的PDCP SDU的COUNT值开始，连续COUNT值对应的PDCP SDU；o将Last_Submitted_PDCP_RX_SN 置为最后递交给高层的PDCP SDU的PDCP SN值。映射到RLC UM的DRB过程对于映射到RLC UM的DRB，在接收到低层的PDCP Data PDU以后，UE应：-如果接收到的PDCP SN Maximum_PDCP_SN：将Next_PDCP_RX_SN 置为0；将RX_HFN 增加1；-执行已解密PDCP Data PDU的头解压缩（如果配置），如5.5.5节所述；-将

20、最后产生的PDCP SDU 递交给上层。SRB过程对于SRB，在接收到低层的PDCP Data PDU以后，UE应：-如果接收的PDCP SN Next_PDCP_RX_SN：使用基于RX_HFN + 1的COUNT值与接收到的PDCP SN值来解密PDU及确认PDU的完整性，分别如5.6节及5.7节所述；-否则：使用基于RX_HFN的COUNT值与接收到的PDCP SN值来解密此PDU及确认其完整性（如适用），分别如5.6节和5.7节所述；-如果完整性确认使用，并且成功通过；或者-如果完整性确认不适用：如果接收的PDCP SN Maximum_PDCP_SN：o将Next_PDCP_RX_S

21、N 置为0；o将RX_HFN 增加1；将最后产生的PDCP SDU 递交给上层；-否则，如果完整性确认适用，但是失败：丢弃接收到的PDCP Data PDU；将完整性确认失败报告给上层。重建过程当上层请求一个PDCP重建时，UE应为对应的RLC模式额外再执行一次本节所述的过程。在执行完本节的过程后，UE应接着执行5.1节中的过程。UL数据传输过程映射到RLC AM的DRB过程当上层请求一次PDCP重建时，UE应：-重置上行链路的头压缩协议(如果已配置)；-在重建过程期间，使用加密算法及上层提供的key加密；-从第一个对应的PDCP PDU成功传递但没有被下层确认的PDCP SDU开始，在如下所

22、述的PDCP重建之前，执行所有从此PDCP SDU对应的COUNT值开始，按COUNT值升序排列的PDCP SN值对应的PDCP SDU的重传或传输： -执行PDCP SDU的头压缩（如果已配置），如5.5.4节所述；-使用关联于此PDCP SDU的COUNT值，加密此PDCP SDU，如5.6节所述；-将最后产生的PDCP Data PDU传递给下层。映射到RLC UM的DRB过程当上层请求一次PDCP重建时，UE应：-重置上行链路的头压缩协议（如果已配置）；-置Next_PDCP_TX_SN，及TX_HFN 为0；-在重建进程期间，使用加密算法及上层提供的key加密；-对于每一个已经对应于

23、一个PDCP SN值，但相应的PDU没有事先传递给低层的PDCP SDU：认为此PDCP SDU是从上层接收而来；在PDCP重建之前，在不重启discardTimer的情况下，按照与PDCP SDU关联的COUNT值的升序传输PDCP SDU，如5.1.1节所述。SRB过程当上层请求一个PDCP重建时，UE应：-置Next_PDCP_TX_SN和TX_HFN 为0；-丢弃所有存储的PDCP SDU和PDCP PDU；-在重建进程期间，使用加密及完整性保护算法和上层提供的key进行加密。DL数据传输过程映射到RLC AM的DRB过程当上层请求一个PDCP重建时，UE应：-处理由于下层重建而从下层

24、接收来的PDCP Data PDU，如5.1.2.1.2节所述；-重置下行链路的头压缩协议（如果已配置）；-在重建进程期间，使用加密算法和上层提供的key进行加密。映射到RLC UM的DRB过程当上层请求一个PDCP 重建时，UE应：-处理由于下层重建而从下层接收来的PDCP Data PDU，如5.1.2.1.3节所述；-重置下行链路的头压缩协议(如果已配置)；-置Next_PDCP_RX_SN和RX_HFN 为0；-在重建进程期间，使用加密算法和上层提供的key进行加密。SRB过程当上层请求一个PDCP 重建时，UE应：-丢弃由于下层重建而从下层接收来的PDCP Data PDU；-置Ne

25、xt_PDCP_RX_SN和RX_HFN 为0；-丢弃所有存储的PDCP SDU 和PDCP PDU；-在重建进程期间，使用加密及完整性保护算法和上层提供的key进行加密。PDCP状态上报传输操作对于映射到RLC AM的无线承载，当上层请求一个PDCP重建时，UE应：-如果此无线承载被上层配置用于在上行链路发送一个PDCP 状态上报（statusReportRequired见3），在处理完由于下层重建而从下层接受来的PDCP Data PDU以后，UE按照如下的指示编译此状态上报，如5.2.2.1节所述，并将此状态上报作为此传输的第一个PDCP PDU传递给低层：将FMS域置为第一个丢失的PD

26、CP SDU的PDCP SN值；如果至少有一个失序PDCP SDU被存储，则分配一个Bitmap field，长度等于从第一个丢失的PDCP SDU（但不包括）开始直到最后一个失序的PDCP SDU（包括最后一个）的PDCP SN的个数，四舍五入到下一个8的倍数；将所有底层指示还未接收到的PDCP SDU以及任意解压缩失败的PDCP SDU在Bitmap field中对应的区域置为“0”；对于其他的PDCP SDU，对应的区域置为“1”。接收操作当在下行链路接收到一个PDCP 状态上报时，对于映射到RLC AM的无线承载：-对于每个PDCP SDU，如果在Bitmap中对应的bit位为“1”，

27、或者相关联的COUNT值小于FMS字段确定的PDCP SDU的COUNT值，则相应PDCP SDU的成功传输将被确认，且UE应按5.4节的规定处理此PDCP SDU。PDCP丢弃当用于PDCP SDU的discardTimer终止，或PDCP SDU的成功传输被PDCP状态上报确认，UE应丢弃此PDCP SDU连同对应的PDCP PDU。如果对应的PDCP PDU已经成功传递给下层，则此丢弃需要指示给下层。头压缩与解压缩支持的头压缩协议与简表（profile）头压缩协议基于可靠性头压缩（ROHC）框架7。存在多种头压缩算法，称之为简表，定义用于ROHC框架。每个简表为特定的网络层、传输层或上层

28、集合（例如TCP/IP与RTP/UDP/IP）所专用。ROHC信道的详细定义在7中规定为ROHC框架的一部分。包括在ROHC信道上不同流（头压缩或不压缩）的复用，以及在流压缩算法的初始化期间特定IP流与特定文本状态的关联。本部分不涉及ROHC框架功能的实现以及所支持的头压缩简表功能的实现。本部分描述了如下简表的支持：表1 支持的头压缩协议与简表Profile IdentifierUsage:Reference0x0000No compressionRFC 49950x0001RTP/UDP/IPRFC 3095, RFC 48150x0002UDP/IPRFC 3095, RFC 48150x

29、0003ESP/IPRFC 3095, RFC 48150x0004IPRFC 3843, RFC 48150x0006TCP/IPRFC 49960x0101RTP/UDP/IPRFC 52250x0102UDP/IPRFC 52250x0103ESP/IPRFC 52250x0104IPRFC 5225头压缩的配置与DRB关联的PDCP 实体可被上层配置来使用头压缩。协议参数在压缩端和解压缩端之间，7定义了必须由上层配置的强制配置参数；这些参数定义ROHC信道。ROHC信道是单向信道，即一个信道用于上行，一个用于下行。因此，对于每个信道都有一个参数集，对于属于同一个PDCP实体的信道应使用相同的配置值。这些参数被归类到两个不同的组中，定义如下：-M：强制的且由上层配置的。-N/A：本部分中不适用。