VoLTE可以说是IMS主导的舞台，因此接入网层面与VoLTE相关的参数以及特征功能并不太多，可以算是舞台上的配角。VoLTE技术本身涉及的一些无线参数并不多，不过由于话音业务的出现，研究重点会适当地从涉及信令层面的参数转向涉及业务层面的参数，因此诸如PDCP／RLC的一些流程以及相关参数可以被提炼出来研究一番，而这些恰恰是LTE建网初期主流优化中并不太关注的。其实涉及LTE网络，终端的参数名目种类繁多，我们之前对于无线参数有过系统性的介绍，这里不再拘泥于系统性的分类介绍，只是谈谈一些可能涉及VoLTE的参数，这其中有通过网络侧预先配置，并通过信令下发UE的，也有UE本身的一些参数。

由于从R9版本之后终端可以支持VoLTE，所以在UE无线接入能力上报中UE一些能力字段会改变，这些字段的分析解读有助于后续一些问题的端到端定位，例如，涉及终端的一些问题，如图5-71所示。

这里值得一提的是PDCP字段与Feature Group Indicator（特征组标识，FGI）。pdcp-Pa-rameters里包含的内容说明UE所支持的PDCP包头压缩的能力以及最大能够压缩的包头数量，与网络侧通过RRC重配消息中下发无线专用资源配置（RadioResourceConfigDedicated）IE中所带有的PDCP-Config是不同的。PDCP-Config是网络侧用来配置数据承载（data ra-dio bear）的PDCP层相关参数的，如图5-72所示。

图5-71 UE无线接入能力

图5-72 PDCP-Config信息

1.丢弃定时器

丢弃定时器（discardTimer）伴随上行传输，即控制数据包上传的一个定时器，每一个PDCP SDU对应一个discardTimer。当UE从上层接收到PDCP SDU时，开始启动该SDU对应的定时器。当该定时器超时或者已经通过PDCP状态报告确认将相应PDCP SDU传到下层时，UE需要将PDCP SDU以及相应的PDCP PDU丢弃。如果PDCP PDU被提交到下层，那么丢弃这一状态也应一并通知下层，意味着PDCP这层把相应的包彻底清空了，这就好比搬家一样，把家具从楼上搬到楼下，需告知楼下的搬家公司，楼上已经清空了。不过，UE高层要求数据承载对应的RLC非确认模式（这里比较拗口，一般就是指VoLTE话音业务）下进行PDCP重建立时，在重建之前没发出的PDCP SDU不需要重新触发discardTimer。因此，该定时器如果设置过小，对于PDCP重建成功有一定影响，会影响丢包率，而设置过大，则容易过多地占用PDCP层的资源，影响后续包的发送时延。

2.状态报告要求

状态报告要求（statusReportRequired）指示UE在PDCP重建中是否需要发送PDCP状态报告。这个参数标识伴随着RLC-AM模式，即意味着对于AM模式下的SRB或者DRB处理。如果UE高层配置RB在上行中发送PDCP状态报告，需要在处理由于底层重建产生的PDCP数据PDU之后，按照如下要求，将状态报告编译，并向下以第一个PDCP PDU的方式发送至底层。

将FMS域设置成第一个缺失的PDCP SDU的PDCP SN。

如果有至少一个乱序PDCP SDU存在，分配bit位图的长度等同于PDCP SN的数量，这里不包括第一个缺失的PDCP SDU，但是包括最后乱序的PDCP SDUs，并且补齐为8的整数倍。

针对底层指示的所有没有收到的PDCP SDUs，在bit位图相应的位置中设为0；对于解压缩失败的PDCP SDUs，可选择性地在bit位图相应的位置设为0。

对于其他的PDCP SDUs设置为1。

这里说明的是在接收到下行的包，发现有些包是缺失的，因此处于RLC-AM格式下，后续需要通过PDCP Contro1 PDU进行上行反馈，值得一提的是，PDCP层设置的这个控制PDU格式其实对应了RLC-AM的这种保护机制，确保包能够被正确接收，但是这个PDU本身却不具备什么应答确认机制，如果这个包没有被正确收到会怎样呢？有兴趣的读者可以自己去研究一下。

图5-73说明的是一个PDCP控制PDU携带一个PDCP状态报告的格式，适用于RLC-AM模式下的DRB承载，图中每一行是一个8bit的位图，FMS代表第一个丢失的PDCP SN，共12 bit。下面的位图代表着从第一个缺失PDCP SN（FMS）开始，即FMS+1，从左至右逐行遍历，如果第n bit置为0，则代表（FMS+n）mod4096为缺失PDCP SN，否则（即置为1）为无需重传的PDCP SDU。

图5-73 PDCP控制PDU携带一个PDCP状态报告的格式(www.daowen.com)

这个PDCP Contro1 PDU即可以由UE高层触发进行配置，并通过上行信道发送出去，诚然，有来有往，也可以通过下行信道接收下来，收到之后，如果相应bitmap置为1或者COUNT值小于FMS对应PDCP SDU的COUNT值，则UE就会将与之对应已发送的PDCP SDU与PDCP PDU丢弃，意味着这些PDCP SDU已经成功被接收并解码。

该参数主要结合了非话音／视频的数据业务承载，相较话音而言，数据业务对于包的丢失更敏感。

3.PDCP-SN串号长度

PDCP-SN-Size是指PDCP SN串号长度，分为12 bit和7 bit两种长度。这个串号长度其实与HFN对应，HFN又用来计算解密时候所需要的COUNT值。

对于RLC-AM模式下，PDCP SN设置为12 bit，如图5-74所示，而对于RLC-UM模式，可选择性地设置12 bit或者7 bit，如图5-75所示。这两种串号长度设置的区别在于，由于RLC-UM模式下没有对于PDCP SDU是否正确接收到的应答机制，相较于较长的12bit，7bit的设置会一定程度上降低包漏检或者错检的概率（这是理论分析，实际情况还需要网络侧进行评估），因此对于时延较敏感的VoLTE话音来说，能够兼顾降低丢包的概率，这应该也是增加7bit作为UM候选项的一个初衷。

图5-74 PDCP SN串号长度采用12 bit SN

图5-75 PDCP SN串号长度采用7 bit SN

4.Profiles

Profi1e是为ROHC（Robust Header Compression）结构定义的包头压缩算法，见表5-8，针对不同的网络层，传输层以及上层协议组合而不同，具体算法的含义可参考不同协议文献，这里仅列出协议列表供参考。需要指出的是，Profi1e 0x0000即使不指明，也会默认存在。

表5-8 Profile参数释义

UE能力上报中还有一个FGI（Feature Group Indicator）字段，以下是R10中关于这个字段中对于PDCP SN长度的设置说明，可以将bit3与bit7捆绑起来解读，这里指出如果UE支持VoLTE，则必须将bit7置为1（true），从而联锁导致bit3也应置为1（true），这意味着VoLTE话音必须通过RLC UM模式进行传输，同时PDCP SN也应该支持7 bit的能力设置。

这里也遗留一个小问题，如果UE自身的错误设置，将bit7设置为1，bit3设置为0，那么在UE能力上报阶段网络侧会不会禁止UE接入？这就要在现网实际验证一下了，各个LTE主流厂商的策略可能都不一致。对于前期所叙述的SRVCC流程，UE的支持能力也可以在bit9进行确认。

其他VoLTE无线测试涉及的网络参数见表5-9。

表5-9 VoLTE无线测试涉及的网络参数