应就其此PDCP SDU及其对应的PDCP PDU。如果对应的PDCP PDU已经成功传递给下层，则丢弃需要指示给下层。
5.5 头压缩与解压缩
5.5.1 协议与简表
头压缩协议基于可靠性头压缩（ROHC）框架，存在多种头压缩算法，成为简表，定义用于ROHC框架。每个简表为特定的网络层、传输层或上层集合所专用。 5.5.2 头压缩配置
与DRB关联的PDCP实体可被上层配置来使用头压缩 5.5.3 协议参数
压缩与解压缩端之间定义了必须有上层配置的强制配置参数，定义ROHC信道（单行信道，上行或下行），属于同一个PDCP实体的信道使用相同的配置。 M、N/A、LARGE_CIDs、PROFILES（M）、FEEDBACK_FOR(N/A)、MRRU（N/A） 5.5.4 头压缩
生成两种类型的输出数据包：
（1）压缩包，各自关联于一个PDCP SDU（与相关PDCP SDU相同的PDCP SN和COUNT关联） （2）独立数据包，为关联于PDCP SDU，即零散的ROHC反馈包（不与PDCP SDU关联，不与PDCP SN关联，不加密） 5.5.5 头解压缩
如果上层为关联与用户平面数据的PDCP实体配置了头解压缩，则PDCP PDU将在执行解密程序后由头解压协议进行解压缩
5.6 加密和解密
1、对于控制平面，加密的数据单元是PDCP PDU以及MAC-I的部分数据 2、对于用户平面，加密的数据单元是PDCP PDU的部分数据 3、加密不适用于PDCP控制PDU 4、加密算法和密钥由上层配置
5、加密功能由上层激活，激活后，应用于所有上层指示的上下行PDCP PDU 6、加密功能请求的输入：COUNT、DIRECTION
7、PDCP请求的，由上层提供的参数：BEARER、KEY（控制面/用户面） （1）BEARER：承载的标识，用于RB身份的标识
（2）DIRECTION：标识传输的方向，0用于上行、1用于下行
（3）KEY：控制平面和用户平面的加密密钥分别为KRRCenc与KUPenc
5.7 完整性保护及确认
1、完整性保护+完整性确认 2、用于与SRB关联的PDCP
3、受完整性保护的数据单元为：PDU头和加密前的PDU部分数据 4、完整性保护算法和密钥由上层提供
5、完整性保护功能由上层激活，激活后，应用于从上层指定的PDU之后的上下行PDCP PDU 6、完整性保护算法的输入：COUNT、DIRECTION 7、PDCP请求的，由上层提供的数：BEARER、KEY
8、传输时，UE计算MAC-I字段的值
接收时，UE通过基于以上指定的输入参数计算X-MAX来确认PDCP PDU的完整性。如果计算得到的X-MAC与接收的MAC-I值相对应，则完整性保护确认成功
5.8 未知的、意外的以及错误的协议数据的处理
PDCP收到一个包括保留值或非法值的PDCP PDU时，PDCP实体应丢弃收到的PDU
补充PDCP实现LTE 接入层安全性过程
PDCP层通过接受高层的安全配置信令，进入相应的状态后才能对数据和信令进行加密及完整性保护，在正常的RRC连接建立完成并且通过层三的鉴权完成后，启动接入层的安全模式命令。网络端首先获得由非介入层的AKA（Authentication and Key Agreement）过程产生密钥KASME，然后RRC由该参数计算得到KeNB，再由KeNB计算得到控制平面的完整性保护密钥KRRCint，以及用户平面和控制平面需要的密钥KUPenc、KRRCenc，在组装成安全模式命令（SecurityModiCommand），发送给终端，配置中端的安全性参数。当网络端发出SecurityModeCommand消息后开始对下行数据进行加密，终端的PDCP层接收到
SecurityModeCommand消息后，先将其发送到RRC进行解码操作，得出网络端配给终端的完整性保护算法，再将完整性保护算法和相应的密钥发给PDCP层，PDCP就可以对
SecurityModeCommand消息进行完整性校验。如果没有通过完整性校验，则向网络端发送安全模式失败（SecurityModeFailure）；如果通过，则取出里面包含的加密算法，并向网络发送安全模式完成（SecurityModeComplete）消息，对其进行完整性保护但是不加密，自此后开始对上行数据加密，下行数据解密。网络端收到该消息后开始对上行数据解密，安全性建好后，开始对信令进行完整性保护。
接入层的安全性是通过加密算法和完整性保护算法来实现的。 接收时，UE通过基于以上指定的输入参数计算X-MAX来确认PDCP PDU的完整性。如果计算得到的X-MAC与接收的MAC-I值相对应，则完整性保护确认成功
QCI
QCI (QoS Class Identifier)是一个标度值，用于衡量特定的提供给SDF（服务数据流）的包转发行为（如丢包率，包延迟预算），它同时应用于GBR和Non-GBR承载，用于指定访问节点内定义的控制承载级分组转发方式(如调度权重、接纳门限、队列管理门限、链路层协议配置等)，这些都由运营商预先配置到接入网节点中。
根据QoS的不同， 承载（Bear）可以划分为两大类： GBR(Guranteed Bit Rate) 和 Non－GBR。所谓GBR，是指承载要求的比特速率被网络“永久”恒定的分配，即使在网络资源紧张的情况下，相应的比特速率也能够保持。MBR(Maximum Bit Rate)参数定义了GBR Bear在资源充足的条件下，能够达到的速率上限。MBR的值有可能大于或等于GBR的值。相反的，Non－GBR指的是在网络拥挤的情况下，业务（或者承载）需要承受降低速率的要求，由于Non－GBR承载不需要占用固定的网络资源，因而可以长时间地建立。而GBR承载一般只是在需要时才建立。
在接口上使用QCI而不是传输一组QoS参数主要是为了减少接口上的控制信令数据传输量，并且在多厂商互连环境和漫游环境中使得不同设备/系统间的互连互通更加容易，由此，需要规定一定数量的处理行为(类似于DiffServ中规定的Per-Hop行为)。
以下是LTE里关于不同QCI的说明： GBR:
QCI=1: Example Services: Conversational voicemscbsc QCI=2: Conversational Video (Live streaming) QCI=3: Real Time Gaming
QCI=4: Non-conversational voice (buffered streaming) Non-GBR:
QCI=5: IMS signaling
QCI=6: Video (buffered streaming), TCP-based (e.g. www, email, chat, ftp, p2p file sharing, progressive video,etc)
QCI=7: Voice, Video (live streaming), interactive gaming
QCI=8: Video (buffered streaming), TCP-based (e.g. www, email, chat, ftp, p2p file sharing, progressive video,etc)
QCI=9: Video (buffered streaming), TCP-based (e.g. www, email, chat, ftp, p2p file sharing, progressive video,etc)