报头压缩-ROHC基本概念

序言

通过这篇博客总结ROHC的基本要点,接下来的文章还会介绍ROHC的详细过程以及Ubuntu下ROHC协议库的安装和使用等。

1. 现有报头压缩机制介绍

1.1 CTCP

  • 说明:Compressing TCP/IP Headers,IETF RFC1144

  • 应用:用于在可靠的串行线路中压缩TCP分组

  • 效果:CTCP可将40字节的IP+TCP报头压缩至4字节

  • 机制:该修复机制不需要在压缩报头的节点和解压缩的节点之间定义明确的信令

1.2 CRTP

  • 说明:Compressing IP/UDP/RTP Headers,IETF RFC2508

  • 应用:CRTP利用了反馈机制,不能用于单向链路中

  • 效果:当不计算UDP校验和时,CRTP可以压缩40字节的IPv4/UDP/RTP报头最少到2字节;计算UDP校验和时,最小CRTP报头是4字节

  • 机制:因为UDP/RTP不能重发,CRTP不能使用和CTCP相同的修复机制。CRTP使用明确的信令信息,由解压方发向压缩方表明context不同步。链路的往返时间会限制context修复速度

1.3 IPHC

  • 说明:IP Header Compression,IETF RFC2507

  • 应用:可以压缩任意IP、TCP和UDP报头,但是不能压缩RTP报头

  • 效果:当不计算UDP校验和时,CRTP可以压缩40字节的IPv4/UDP/RTP报头最少到2字节;计算UDP校验和时,最小CRTP报头是4字节

  • 机制:IPHC对于压缩/解压TCP报头和非TCP报头的机制是不同的,IPHC和CTCP协议一样没有反馈机制

    • 压缩TCP报头时:CTCP的修复机制被改进为“链路层否定反馈机制(Link-layer nacking scheme)”,可以加速修复;
    • 压缩非TCP报头的时候:IPHC采用慢启动(slow-start)和周期性刷新报头等机制,来缩短修复关联的时间

1.4 ROHC的提出

  • 由来:
    • 无线网络传输误码率高
    • 链路往返时间长(100ms-200ms)
      当压缩/解压方不同步,会引起很多分组丢失,而现有报头压缩机制不能有效检测context被破坏的情况,不适用于无线链路。因此IETF中ROHC工作小组提出了对无线链路具有很强容错能力,包括帧丢失和误码残留的报头压缩机制
  • 说明:Robust Header Compression,IETF RFC3095
  • 其他:ROHC针对不同协议,有不同的压缩子协议(profile),目前规范的子协议有RTP/UDP/IP,UNCOMPRESSED,UDP/IP,ESP/IP报头的模型。

2. ROHC协议

与ROHC 相关的IP/UDP/RTP协议栈

一个数据流中的IP头的许多部分在传输中是静态(static)的并且从不改变,ROHC就是利用这些不同IP包中的固定性,不必每次都传输这些冗余信息,在压缩至解码的过程中把它们存储为关联信息(context)。

下图中的推理域(inferred)可以由其他的报头信息得到,由此可以看出,压缩方法的关键就是如何处理改变了的部分(changing fields)。ROHC将利用基于包序列号的线性函数得到报头动态变化的部分。

静态和动态部分
域名称类型域名称类型
VersionStaticMore Fragments flagStatic-Known
Header LengthStatic-KnownFragment OffsetStatic-Known
DSCPAlternatingTime to LiveChanging
ECN flagChangingProtocolStatic
Packet LengthInferredHeader ChecksumInferred
IdentificationChangingSource AddressStatic-Def
Reserved flagChangingDestination AddressStatic-Def
Don’t Fragment flagChanging
IPv4报头结构
  • Static:即静态域。在同一IP数据流中变化几率很小,只是偶尔才会发生,所以,压缩端和解压缩端之间传输了一次信息头之后,就不需要再次进行传输了。如果静态域发生变化,那么重新传输变化之后的静态域数值即可。
  • Semistatic:半静态域。这些字段的值通常是静态不变的,只是偶尔发生改变,很快它又会恢复成原始值
  • Static-Def:即静态定义域。这些域往往代表了一些固定的信息,比如源地址、目标地址等。同静态域相似,但是静态定义域在同一IP数据流中是不会发生变化的,只在第一次传输即可,之后不需再次进行传输处理。
  • Static-Known:即静态已知域。域的数值是已经定义好的,压缩端和解压缩端都不需要去进行压缩处理,也不需要进行传输。
  • Changing:变化域。顾名思义,即是发生变化的域。这些域是必须要进行压缩处理进行传输的。
  • Rarely Changing:和半静态字段类似,偶尔发生变化,只是不会恢复到原始值,而是保留新值
  • Alternating:这些字段的值在少数几个不同的数值之间交替变化
  • Inferred:推测域。推测域是可以通过其他一些域的数值进行计算得到的,所以在传输处理中,并不需要对推测域进行处理。只需要将其相关域和变化规律进行压缩处理即可。
    我们在进行数据传输的开始阶段,将一个完整的信息头发送给对方,之后则根据各个域的类型,只对发生变化的域进行传输处理。而且也不一定需要把域的所有比特都进行压缩处理,按照WLSB算法,我们只需要处理发生变化的比特,这样就可以实现减少传输数据量的压缩目的了。

2.1 压缩率

C e = ( H + P ) − ( H r o h c + P ) H + P = H − H r o h c H + P C_{e} =\frac {(H + P) - (H_{rohc} + P)} {H + P} = \frac {H - H_{rohc}} {H + P} Ce=H+P(H+P)(Hrohc+P)=H+PHHrohc

  • 当H_rohc = 0,得到理论上最大的包压缩率。

  • 当报头长度恒定时,最大压缩比会随着负荷长度的减小而增大。因此ROHC很适用于以低比特流传输的信号,其报头长度明显长于有效负荷的长度。

IP头压缩协议(IPHC)、实时压缩协议(CRTP)主要为无线链路设计的,可这些协议在有效性和健壮性
方面都有不足。对于通常采用的RTP/UDP/IP协议单元ROHC安装在网络层和链路层,一些Internet应用或许不会注意到报头压缩的用途(在一些有线宽带网上),但无线业务服务的供应商能够利用这一技术获得很客观的带宽节省。

2.2 ROHC的工作模式和工作状态

ROHC协议定义了3种上作模式和3种压缩、解压状态,以便ROHC在不同无线链路状态下对IP分组信头进行压缩和解压,保持压缩和解压数据流同步,保证ROHC协议健壮性。

  • 三种压缩状态
    • IR(initiation and refresh state)初始化和重置状态: 用于初始、更新文景中静态域和动态域信息。在此状态下,压缩方连续发送全部IP信头信息和流关联标识符(PID和CID)。
    • FO(first order)一级压缩状态。此时压缩方仅仪需要传递完整的动态信头域信息。
    • SO(second order)二级压缩状态。SO状态是最高级压缩状态,这时压缩方根据动态域变化规律,仅传递动态域的压缩值,此时压缩方发送最高压缩率的ROHC压缩分组。
  • 三种解压状态
    • NC(no context)无文景状态。NC状态主要足在数据流刚开始传递时解压方所处的状态,解压方没有IP信义静态和动态域信息,需要压缩方在IR状态发送包含完整信头的分组。
    • SC(static context)静态文景状态。SC解压状态指解压方获得了足够的静态域信息,与压缩方的FO状态相对应,希望接收到包含完整动态信头的ROHC压缩分组。
    • FC(full context)全文景状态。FC解压状态指解压方获得了足够的静态域信息和动态域的变化规律信息时所处的状态,与压缩方SO状态相对应,能够接收压缩方在SO状态所发送的ROHC压缩分组。

解压方刚开始工作在NC状态,一旦成功解压一个ROHC分组就进入FC状态;在FC状态下,当最近k1个连续分组解压失败时,解压方转移到SC状态;在SC状态下,当成功解压一个分组时,解压方转移到FC状态;当最近k2个连续分组解压失败的时候,解压方转移到NC状态。(当K1 = K2 = 3时性能最优)

  • 三种工作模式

    • 单向U模式(uni-directional mode):ATSC3.0使用的是这种工作模式。当不存在或不能使用反馈信道时,ROHC工作在U模式,此时解压方不能向压缩方发送反馈信息。为保证压缩健壮性和压缩率,压缩方采用乐观逼近原则和周期性原则进行状态转移。(当n = 3,timeout = 4s时性能最优,文献1)
      • 乐观逼近原则:在IR状态或FO状态时,压缩方向解压方连续发送n个分组时就认为解压方建立了正确的解压文景,于是向高级FO、SO状态转移。
      • 周期性原则:压缩方在FO、SO状态一定时间timeout后,就转移到低级压缩状态。
    • 双向优化O模式(bi-directional optimistic mode):当无线链路存在可以利用的反馈信道时,ROHC工作在O模式,压缩方向高级状态转移采用乐观逼近原则或者正反馈原则,向低级状态转移采用负反馈原则。
      • 正反馈原则:当无线链路允许发送反馈分组的时候,解压方一旦正确解压具有更新文景特性的分组时,就向压缩方发送正反馈分组,允许压缩方向高级压缩状态转移。
      • 负反馈原则:当无线链路允许发送反馈分组的时候,解压方连续错误地解压ROHC分组时,就要向压缩方发送负反馈分组,促使压缩方向低级状态转移,并发送带有完整信息的分组,以便解压方接收到这些分组后更新解压文景信息,保持压缩和解压文景同步。
    • 双向可靠R模式(bi-directional reliable mode):当无线链路质量比较好的时候,状态转移完全采用反馈原则。压缩方向高级状态转移采用正反馈原则,向低级状态转移采用负反馈原则。可靠性模式是在优化模式下通过增加7bit的误码校正位扩展而来。
  • 因为ATSC3.0中采用的是ROHC-U工作模式,这里只对ROHC-U模式下的状态转移做一些说明

    • 压缩状态由IR开始,前向转移有两种模式FAST和Normal,在Fast模式下IR状态可直接转移到最高压缩状态SO;在Normal模式下IR需先转移到FO状态,再由FO状态转移到SO状态。
    • U-Mode的前向转移采用前向优化策略,当压缩方认为解压方收到足够的信息,就会从较低级的压缩模式转移到更高级的压缩模式。
    • 压缩方在较低状态会连续发送n1/n2/n3个含context更新信息的压缩分组,用这种方法让解压方收到足够多的解压信息,然后压缩方的压缩状态前向转移。n1/n2/n3根据情况选择合适的值。
    • 当分组信息的动态部分发生变化的时候,压缩方的状态会由SO转移到FO;另外,U-Mode采用周期性的过期,使压缩状态从较高级转移到较低级,这个周期过期的时间Timeout的值并没有在RFC中明确指明,需要根据实现情况确定。由于U-Mode没有反馈,所以压缩方的参数选择对于整个压缩效率和保证过程的robust尤为重要。
  • 解压的逻辑相对简单,如上图所示
    • 解压方在获得足够的解压信息后总是处于FC(Full Context)状态,只是当最近收到的n1个连续的分组中有k1个解压失败的时候才会由FC状态转移到SC(Static Context)状态。
    • 在SC状态下,当成功的解压一个含有足够更新信息的分组的时候,就会转移到FC。
    • 当最近收到的n2个连续的分组中有k2个解压失败的时候才转移到NC(No Context)状态。

2.3 ROHC的应用场合

  • ROHC的目的是提供一个适合于高误码率和长时延的链路的报头压缩机制。

  • ROHC在使用WCDMA、EDGE、和CDMA2000等技术的无线链路上有较好的性能,差错扩散和额外增加的时延较小,而且在单向链路中也可以进行压缩。

  • ROHC除了进行一般的TCP和UDP/RTP压缩,还有语音和低带宽视频的应用的报头压缩。

  • ROHC为3GPP和3GPP-2等发展无线链路 IP 协议的组织提供技术支持。

  • ROHC也是根据传输过程中分组报头中各个域的变化情况,将分组报头分为静态域和动态域,那些在数据流传输过程中始终保持不变的域称为静态域,动态域在传输过程中会发生变化,静态域只在初始化和刷新的时候发送,动态域经压缩后传输。

2.4 ROHC的新特点

相对于其他报头压缩机制,ROHC有如下新特点

  • 针对不同域不同的变化规律,对不同域采用不同算法进行压缩。其压缩函数都是关于序列号(SN,sequence number)的函数,完全压缩时仅发送SN(4~8bit),由解压方根据其维护的context表项和profile进行解压缩。
  • 在压缩分组中加入CRC确保压缩的健壮性。
  • 采用多级压缩IN压状态,在发送完整信息分组和完全压缩分组之间建立中间状态,增强压缩解压的灵活性,同时提高了压缩效率。
  • 有多种工作模式,可根据链路的实际情况决定使用的工作模式。

2.5 ROHC-U差错校验CRC

U/O-Mode格式中必须含有CRC校验,U-Mode无应答;O-mode在收到更新报头信息的分组时,要发送肯定或否定的应答。

  • CRC原理
    压缩方对原分组报头进行CRC校验,并将结果填入压缩分组的CRC域中,发送给解压方。解压方收到压缩分组后查找其相应的context表项并根据其profile进行解压缩,对解压后的报头进行CRC校验,将校验的结果与压缩分组传来的,CRC域作比较:若相同,则表明解压无误,可传给上层;若不同,则表明解压错误,应根据具体情况进行不同的处理(见参考文献1)。

2.6 ROHC-U编码算法

为了实现高效的压缩率,在信道传输更少的比特,对于有变化的域如SN、IP-ID和TS并不会完整地发送,而是对其编码,再在解压端对其解码还原。其中LSB算法和W-LSB算法足ROHC中最为重要的压缩方法,此外还有“按比例RTP时间戳编码”,“IP-ID偏移编码”,“自描述的可变长度值编码”等。

  • 最低有效位(Least Significant Bits Encoding)LSB编码用于值经常做较小的改变的报头域,如序列号。压缩方发送域值中最末k正整数位,而不是初始的域值,解压方收到k比特后,由原先收到的参考值(r_ref)产生初始的值,压缩函数为f(v_ref,k)。
  • 基于窗口(Window-based LSB Encoding)W-LSB编码对LSB编码作了改进,增加了健壮性,压缩方维护一个包含解压方的待用v_ref参数的滑动窗口,确保压缩方和解压方v_ref参数的同步。

2.7 Profile和Context

  • Profile
    为了能够对多种类型的信息头进行压缩处理,ROHC协议引入了Profile的概念。根据信息头的不同,ROHC协议制定了唯一Profile ID与之相对应,比如说IP/RTP的Profile ID为0x0002。ROHC协议定义的Profile ID如下表所示。
信息头类型Profile IDReference
UNCOMPRESSED0x0000RFC 4995
IP/UDP/RTP0x0001RFC 3095,RFC 4815
IP/UDP0x0002RFC 3095,RFC 4815
IP/ESP0x0003RFC 3095,RFC 4815
IP0x0004RFC 3843,RFC 4815
IP/TCP0x0006RFC 4996
IP/UDP LITE0x0008RFC 3828
IP/UDP/RTP v20x0101RFC 5225
IP/UDP v20x0102RFC 5225
IP/ESP v20x0103RFC 5225
IP v20x0104RFC 5225
  • Context
    ROHC协议为了能够更好的对IP数据流进行区分,在引入Profile ID的同时,提出了Context ID的概念。不同的IP数据流将会分配到唯一的Context ID,用来标识该数据流。而通过Profile ID和Context ID,解压缩端就可以对指定的数据进行解压缩处理。
    • 压缩端在发送IR的时候,将分配给该信息头的Profile ID、Context ID和信息头中各个域的内容全部发送到解压缩端,解压缩端则将其记录下来存到Context中。
    • 解压缩端对于之后收到的压缩数据包,会先进行压缩包内的Profile ID和Context ID的解析,判断该组数据流是否已经存入到Context中,并进行解压缩处理。
Acknowledgements:

[1] 岳仑. 在无线链路上采用ROHC协议传输语音的性能研究[D]. 2004.
[2] 厉群, 王春晓. ROHC 协议分析与建模[J]. 计算机工程与设计, 2008, 29(13): 3309-3312.
[3] 陈阳. 无线通信 ROHC 协议技术研究与实现[D]. 大连海事大学, 2012.

评论 5
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值