随手记2022（13）VoNR中的ROHC

VONR作为5G网络基础业务确是姗姗来迟，之前5G语音相关文章参考：

由于IP语音的数据包属于“大脑袋小身材”，而大脑袋又不是有用的payload部分，因此VONR使用ROHC来对语音IP包进行压缩来提升效率，ROHC有助于减小IP语音包的头部开销，从而降低误块率，降低延迟并提升“寸bit寸金”的空口资源效率。与之前的移动蜂窝系统的思路类似：每一套新一代蜂窝系统的各个接口的各层协议很大部分是在以前的各类通信系统（包括有线和无线通信）中已经成熟应用的协议和流程，经过3GPP的整合和优化应用到新一代蜂窝系统的接口协议中，5G也不例外，ROHC也是出身于IETF的协议。如今被整合进入5G空口PDCP的子功能部分来为无线系统空口提供优化方案。

ROHC设计使用当今的IP两大版本协议：IPV4和IPV6，IP相关信息可参考如下文章：

也因为如上所述，ROHC并不是VONR专属使用的协议，它应用的范围很广，比如普通的VoIP业务，互动性游戏，各类消息message业务等，这些业务的特点是前所说的所使用的IP包具备“大脑袋小身材”的特点。尤其适合于作为整个系统“颈部”的无线系统的空口部分当ue发现需要发起切换时，即为所使用的IP包的数量非常庞大，而这些IP包的头部比例都比较大，比如：一个VONR数据包的语音payload部分是36bytes，但需要多达60bytes的头部来共同组成完整的语音IP包。因此在空中接口传输前对这个60bytes的头部部分进行压缩就显得至关重要。

我们大家都知道，VONR的IP数据包包括两类，分别是控制面的SIP消息和实际的语音流RTP。其中的RTP的IP包就符合前面所述的ROHC应用特色。而SIP数据包就不太符合ROHC应用的场景，因此ROHC在实际网络中多用于RTP。

前面已经提到了，ROHC的原始协议文本来自于IETF，对应IETF的RFC号码是RFC3095当ue发现需要发起切换时，RFC5795，RFC4815，RFC5225，RFC6846等。在这些RFC协议文本中定义了不同类型的ROHC profiles：

3GPP TS38.323中进一步整合并定义的ROHC profile信息如下：

当gNB中的ROHC的功能打开时，其基本流程如下所示：

这个骨感的流程为：UE在开机注册网络时候按惯例是要上报能力的，然后网侧记忆之存档备用。当UE发起VONR业务之初，gNB会查阅UE对相关profile的支持状况，如果相关信息不存在就会向UE发起能力上报请求，让UE上报相关能力。如果gNB发现该UE的相关能力为空or不支持就会终止呼叫（因为网侧认为该UE不具备VONR的能力，也就没有将呼叫进行下去的必要了）。如果gNB查阅到了相关的UE ROHC profile就会启动协商过程，如果协商成功则ROHC功能就开始了，否则呼叫终止。

在ROHC功能启动后，发端的压缩器（Compressor）会对语音IP包头部进行压缩处理，而在接收端的解压缩器（decompressor）进行解压缩从而恢复IP包头部信息，下面以profile 0x0001为例说明一下ROHC的处理过程：

发端Compressor负责压缩并发送经过头部压缩的IP包给收端，收发两端的Compressor和decompressor分别维护相应的context，并通过协商确认这些context保持一致性及完整无误，收端decompressor负责根据相应的context信息对之进行解压缩以恢复原始IP包头部信息。decompressor能够根据解压缩的结果反馈通知compressor一方是successful还是failed并相应发起context同步过程，如果context同步过程失败则compressor会重复发送包含了context信息的数据包直到context同步成功。而如果decompressor端连续收到的CRC校验数量超过了关闭ROHC功能的门限，则系统就会关闭ROHC功能。

ROHC的相关参数在切换过程的处理方式如下：

在intra-cell HO中（比如cell中Beam级的mobility），ROHC的参数保持不变，也不需要重新协商，对于inter-gNB的小区间切换就需要进行ROHC参数的协商了，如下：

对于intra-gNB的小区间切换，也需要ROHC参数协商，最终也是通过RRC重配消息将结果通知UE：

相应的RRC消息也列在下面，首先是UE的ROHC相关的能力：

为DRB配置的ROHC的相关IE结构如下：

具体log展示，ROHC功能打开：

ROHC功能关闭的log展示：

相关的IE详细信息参考38331吧。

周末愉快, Relax了！