鲁棒头压缩(ROHC)在4G应用.docx
鲁棒头压缩(ROHC)在4G应用#鲁棒头压缩#RoHC#4G#Vo1TE鲁棒头压缩(RoHe-RObUStHeaderComPreSSiOn)是一种报头压缩协议(算法),可用于压缩不同的IP数据包报头。通常在没有进行压缩情况下IPv4报头是40字节,IPv6报头是60字节;通过ROHC压缩,这些报头可以压缩到1或3字节。头压站酉算1''jIP协议是一种有线和无线网络传输协议。随着网络发展、应用程序增多、业务类型及这些应用程序和服务的消费者需提供更多带宽，所有这些都争相获取更大的带宽。对于网络运营商来说,提供高质量的服务(QOS)以吸引更多客户并鼓励他们尽可能多地使用他们的网络，以实现更高平均收入用户(ARPU)非常重要。在诸如IP语音、互动游戏、消息传递等服务和应用程序中P数据包的有效载荷几乎与报头大小相同甚至更小。在由多跳组成的端到端连接中,这些协议包头非常重要，但仅在一个链接(跳到跳)上，这些包头可以被压缩并且必须在另一端解压缩；在很多情况下可以将这些报头压缩到90%,从而节省带宽并有效地使用昂贵的资源。IP报头压缩还提供了其他重要的好处，例如减少数据包丢失和改进交互响应时间。头压缩原理 在会话开始时,发送端和接收端发送未压缩的完整包头信息； 发射端和接收端都提取和存储(包头)信息； 对所有进一步交互发送者只发送与第一次交互时的信息,交换那些不同的信息。由于在整个会话期间标头中大量信息保持不变，因此只有一小部分发生了变化,通常只有1或3个字节； 进一步压缩PDU/SDU的有效载荷和其他部分。为了更清楚了解,以IPv4和UDP数据包为例,下图显示了两者包头信息：SoorcPortD*tir4BtiofiPort1*rgthMDPCKck<MmDtUOPOaUgramHdrInformation-利好而一远学5G通过查看上图,可很容易地找出哪些部分可以更改,哪些部分保持不变。例如源IP,目标IP,版本,报头长度,服务类型,源端口，目标端口等事务将保持静态。简单地通过不再进一步交易传输此信息，标题大小显着减少。其他部分如校验和和数据可以使用ROHC算法进行压缩。RoHC管理系统ROHC在RFC3095下管理,共有四种不同类型的RoHC配置文件。配置文件ORoHC未压缩):压缩数据包,不能被以下任何配置文件压缩;配置文件KROHCRTP):使用IPUDPRTP协议标头压缩数据包；配置文件2(ROHCUDP):使用IP/UDP协议标头压缩数据包；配置文件3(ROHCESP):使用IP/ESP协议标头压缩数据包；根据3GPP规范36.323,鲁棒头压缩(Rc)HC)共定义了以下配置文件：Profi1eIdentifierUsaeReference0x0000NocompressionRFC49950x0001RTP/UDP/IPRFC3095,RFC48150x0002UDP/IPRFC3095.RFC48150x0003ESP/IPRFC3095.RFC48150x0004IPRFC3843,RFC48150x0006TCP/IPRFC4996OxO1O1RTP/UDP/IPRFC52250x0102UDP/IPRFC52250x0103ESP/IP产J5双一厂0x0104IPRoHC在1TE应用1TE中的ROHC应用是终端(UE)和基站(eNB)用户面的层二(Iayer2)部分。UE和eNB都充当下行(D1)和上行(U1)中用户面数据包的压缩器和解压缩器。压缩效率取决于ROHC操作模式和应用层数据包头动态部分的变化。ROHC可将包头压缩为一个字节，从而有效地减小语音数据包的大小。1TE中ROHC的工作有以下三种模式,这些模式的可靠性和用于传输反馈的开销各不相同： U-MOde(单向Unidirectiona1):在U-Mode下,数据包只能从压缩器发送到解压缩器使用;没有强制性的反馈渠道。U-MOde具有最低可靠性，但需要最少反馈开销； O-MOde(双向乐观-BidireCtiOna1oPtimiSti)：在O-Mode中解压器可以发送反馈以指示解压失败或上下文更新成功，因此它提供比U-Mode更高的可靠性，但生成与R模式相比的更少反馈； RMode(双向可靠-BidireCtioiIaIRe1iab1e):在R-Mode中,压缩器和解压缩器之间的上下文同步只有反馈才能保证。压缩器反复发送上下文更新包,直到从解压缩器接收确认。因此,R-Mode提供最高,可靠性,但由于强制确认而产生的开销最大。ROHC与VO1TEROHC可以应用于我们有非常频繁的小数据包事务的任何应用程序,如IP语音、互动游戏、消息传递。在1TE网络语音即Vo1TE中,ROHC对VO1TE应用非常有用，因为它是由巨大IP数据包承载的大量小数据。如可能存在只有大约32字节的语音数据（编码数据）带有60字节的报头。在这种情况下报头部分比实际数据占用更多资源，因此这种数据包可能是ROHC一个很好的候选者。正如我们所知,Vo1TE有两种类型的数据包:一种用于S1P信令,另一种用于语音流量数据包。语音流量的数据量非常小，但传输非常频繁。所以ROHC是一个非常有效节省网络资源的解决方案。至于SIP信令数据包与报头大小相比较大,并且传输不是很频繁,因此报头压缩可能不那么有效;虽然对SIP数据包的压缩可以节省一点资源，但是头压缩导致的处理开销可能更大;因此这不是一个明智的解决方案。所以ROHC不适用于实际场景中的SIP信令消息包。ROHC信令基站(eNodeB)通过终端上报的UE能力，了解对ROHC的支持情况；21z1ttyTafttfM<f1B-rWI11tyIamtimriw>-<4ebiHtVMT-CQMaimr1iKt1ttMItM10OBYf1(eM“IyMff<Qt41M<Mt*T)e;wuaISwC9ebiIitfMT-CoMaiaftf:c9X>00MCw1fMCeirMfdfc3*fr>M.*OBWMCeraCMttatw*Immt*HJw-Ct9<y7，ycyX,4etr1和港冠一起乎56<op>rt4KBiIm.>ft>t11QB0M1:TffW.gtft>Ci1e8M1:tno¢eofi1OO0):Fa1M1.mCi10M4;1MprvtiaM:1mMom<osHn；riMamg+i"riM.m0*21:PaIm*eoCUta1M:Z”当ROHCaeNodeB被激活时,使用RRC重新配置消息通知UE此数据无电承载(DRB)可支持的压缩；c1:rrcCoo&ect1onfte<ctif1gur«t.1M-fe<0)rrcCmcawrrfWTionrrdio*eourceCftfgOedicatd4rb-TM*iod1iat:1IteaIt0DfiBIaAd(MOddrb-Idntity:1pdcpConfxgr1cAN.0.>t<tu*portqurvd:Fa1whdrCMprtBion:robeU)robepcot11s1prof110s0001:TnM1profi1e0x0002;True.0profI1eOvOOO):Fa1se.0.pxofi100004:Fa1se.O.profi10B0004z119.Q.roft10*D101rra1*0.pofi100102:1m。a：UBM至薪0profi10v0104!d
