明天起，北京市将实施单双号限行临时措施，交管部门将最大限度将警力投入路面，严查违反单双号限行。同时，全市道路上的高清摄像头也将调整记录违法的模式，对违反限行的车辆拍照。限行的规则是单日单号行，双日双号行。熟悉了上下班自驾方式的小伙伴可能得将近有7，8天时间面临无车可开的境地了，别着急，网优小谈为您带来的如下的解决方案:
学习一门技能，总有一天能用的上，你懂的。
VoLTE可以说是IMS主导的舞台，因此接入网层面与VoLTE相关的参数以及特征功能并不太多，可以算是舞台上的配角。VoLTE技术本身涉及的一些无线参数并不多，不过由于话音业务的出现，研究重点会适当的从涉及信令层面的参数转向涉及业务层面的参数，因此诸如PDCP/RLC的一些流程以及相关参数可以被提炼出来咀嚼一番，而这些恰恰是LTE建网初期主流优化中并不太关注的。其实涉及LTE网络，终端的参数名目种类繁多，我们之前对于无线参数有过系统性的介绍，这里不再拘泥于系统性的分类介绍，只是谈谈一些可能涉及VoLTE的参数，这其中有通过网络侧预先配置，并通过信令下发UE的，也有UE本身的一些参数。
由于从R9及之后版本终端可以支持VoLTE，所以在UE无线接入能力上报中UE一些能力字段会改变，这些字段的分析解读有助于后续一些问题的端到端定位，例如，涉及终端的一些问题。
这里值得一提的是PDCP字段与FeatureGroup Indicator（特征组标识，FGI）。pdcp-Parameters里包含的内容说明UE所支持的PDCP包头压缩的能力以及最大能够压缩的包头数量，与网络侧通过RRC重配消息中下发无线专用资源配置IE（RadioResourceConfigDedicated）中所带有的PDCP-Config是不同的。PDCP-Config是网络侧用来配置数据承载（dataradio bear）的PDCP层相关参数的。
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层的资源，影响后续包的发送时延。
statusReportRequired
指示UE在PDCP重建中是否需要发送PDCP状态报告。这个参数标识伴随着RLC-AM模式，即意味着对于AM模式下的SRB或者DRB处理。如果UE高层配置RB在上行中发送PDCP状态报告，需要在处理由于底层重建产生的PDCP数据PDU之后，按照如下要求，将状态报告编译，并向下以第一个PDCP PDU的方式发送至底层：
将FMS域设置成第一个缺失的PDCPSDU的PDCP SN；
如果有至少一个乱序PDCPSDU存在，分配Bit位图的长度等同于PDCP SN的数量，这里不包括第一个缺失的PDCP SDU，但是包括最后乱序的PDCP SDUs，并且补齐为8的整数倍；
针对底层指示的所有没有收到的PDCP SDUs，在Bit位图相应的位置中设为0；对于解压缩失败的PDCP SDUs，可选择性的在Bit位图相应的位置设为0；
对于其他的PDCPSDUs设置为1。
这里说明的是在接收到下行的包，发现有些包是缺失的，因此处于RLC-AM格式下，后续需要通过PDCP Control PDU进行上行反馈，值得一提的是，PDCP层设置的这个控制PDU格式其实对应了RLC-AM的这种保护机制，确保包能够被正确接收，但是这个PDU本身却不具备什么应答确认机制，如果这个包没有被正确收到会怎样呢？有兴趣的读者可以琢磨一下。
图例说明的是一个PDCP控制PDU携带一个PDCP状态报告的格式，适用于RLC-AM模式下的DRB承载。上图每一行是一个8bit的位图，FMS代表第一个丢失的PDCPSN,共12bit。下面的位图代表着从第一个缺失PDCP SN（FMS）开始，即FMS 1，从左至右逐行遍历，如果第n bit置为0，则代表（FMS n）mod4096为缺失PDCP SN，否则（即置为1）为无需重传的PDCP SDU。
当然，这个PDCP Control PDU即可以由UE高层触发进行配置，并通过上行信道发送出去，诚然，有来有往，也可以通过下行信道接收下来，收到之后，如果相应Bitmap置为1或者COUNT值小于FMS对应PDCP SDU的COUNT值，则UE就会将与之对应已发送的PDCP SDU与PDCP PDU丢弃，意味着这些PDCP SDU已经成功被接收并解码。
该参数主要结合了非话音/视频的数据业务承载，相较话音而言，数据业务对于包的丢失更敏感。
pdcp-SN-Size
这里说明的是PDCP-SN串号长度，分为12bit和7bit两种长度。这个串号长度其实与HFN对应，HFN又用来计算解密时候所需要的COUNT值。对于RLC-AM模式下，PDCP-SN设置为12bit,而对于RLC-UM模式，可选择性的设置12bit或者7bit。这两种串号长度设置的区别在于，由于RLC-UM模式下没有对于PDCP SDU是否正确接收到的应答机制，相较于较长的12bit，7bit的设置会一定程度上降低包漏检或者错检的概率（这是理论分析，实际情况还需要网络侧进行评估），因此对于时延较敏感的VoLTE话音来说，能够兼顾降低丢包的概率，这应该也是增加7bit作为UM候选项的一个初衷。
PDCP Data PDU format for DRBs using a 12 bit SN
PDCP Data PDU format for DRBs using 7 bit SN
Profiles
Profile是为ROHC（RobustHeader Compression）结构定义的包头压缩算法，针对不同的网络层，传输层以及上层协议组合而不同，具体算法的含义可参考不同协议文献，这里仅列出协议列表供参考。需要指出的是，Profile 0x0000即使不指明，也会默认存在。
Profile Identifier | Usage: | Reference |
0x0000 | No compression | RFC 4995 |
0x0001 | RTP/UDP/IP | RFC 3095, RFC4815 |
0x0002 | UDP/IP | RFC 3095, RFC4815 |
0x0003 | ESP/IP | RFC 3095, RFC4815 |
0x0004 | IP | RFC 3843, RFC4815 |
0x0006 | TCP/IP | RFC 4996 |
0x0101 | RTP/UDP/IP | RFC 5225 |
0x0102 | UDP/IP | RFC 5225 |
0x0103 | ESP/IP | RFC 5225 |
0x0104 | IP | RFC 5225 |
UE能力上报中还有一个FGI字段（FeatureGroup Indicator）,以下是R10中关于这个字段中对于PDCP SN长度的设置说明，可以将bit3与bit7捆绑起来解读，这里指出如果UE支持VoLTE，则必须将bit7置为1（true），从而连锁导致bit3也应置为1（true），这意味着VoLTE话音必须通过RLC UM模式进行传输，同时PDCP SN也应该支持7bit的能力设置。
这里也遗留一个小问题，如果UE自身的错误设置，将bit7设置为1，bit3设置为0，那么在UE能力上报阶段网络侧会不会禁止UE接入？这就要在现网实际验证一下了，各个LTE主流厂商的的策略可能都不一致。
对于前期所叙述的SRVCC流程，UE的支持能力也可以在bit9进行确认。
未完待续，不定期更新～
张阳，英国布鲁内尔大学（Brunel Univ.）设计与工程学院电子与计算机工程博士，高级工程师，博士阶段主要进行LTE物理层、处理优化算法研究。主要从事TD-LTE/TD-SCDMA网络优化工作。曾参加中国移动无线网络优化技术高级培训，荣获优秀学员称号，参加中国移动LTE维护优化技能竞赛，荣获一等奖。长期关注跟踪一线实际优化工作，具有丰富的理论基础及实践经验。在国内外通信期刊发表学术论文数十篇，并合著有《TD-LTE无线网络优化与应用》一书。
感谢一路陪伴我们的热心粉丝，如果觉得文章还不错，可以通过扫描下面的二维码支持我们，谢谢。
网优小谈 是业内原创为主的通信技术交流平台，欢迎不同意见、新观点或建议。
支持原创，分享智慧！
投稿请发至：wirelessren@163.com
联系客服
