LTE系统中的上行数据压缩技术 .pdfVIP

  1. 1、本文档共11页,可阅读全部内容。
  2. 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
  5. 5、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
  6. 6、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们
  7. 7、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
  8. 8、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多

LTE系统中的上行数据压缩技术

全海洋

【期刊名称】《《移动通信》》

【年(卷),期】2019(043)011

【总页数】7页(P94-100)

【关键词】上行数据压缩;DEFLATE算法;LTE系统;上行资源受限

【作者】全海洋

【作者单位】大唐移动通信设备有限公司标准部北京100083

【正文语种】中文

【中图分类】TN929.5

0引言

在3GPP标准的R15阶段中,为了解决上行资源受限以及VoLTE语音在小区边缘

建立会话成功率低的问题,提出了在接入层对终端的上行数据进行压缩的方式。本

文接下来将对上行数据源的特征进行分析,并选择合适的压缩方法,以及就如何在

LTE中支持相关方法进行分析。

1上行数据压缩在LTE系统中的应用

1.1业务特征

为了获得更全面的UDC(Uplinkdatacompression,上行数据压缩)性能表现,

UDC可以在如下三类业务下分别进行评估。

(1)类型1(非加密业务):主要是在应用层没有加密的数据业务,例如网页浏

览、文本上传、在线视频和即时通讯文本对话等。

(2)类型2(VoLTESIP信令):主要针对VoLTE业务的SIP信令,这些信令是

非加密非压缩的数据,例如INVITE消息、PRACK消息等。

(3)类型3(不经过RoHC(RobustHeaderCompression,健壮报头压缩)

的HTTPS业务):HTTPS是在应用层加密的数据,这些数据包的报头没有经过

RoHC压缩,因此可以使用UDC进行压缩,例如TCP/IP报头可以使用UDC进

行压缩。

在UDC性能评估中,会优先考虑类型1和类型2的业务,因为其带来的增益会更

加明显。

为了更能真实地反映现实中用户数据的压缩效果,需要对混合业务的压缩性能进行

评估,例如网页浏览和视频业务、多IP流业务等。

数据压缩一般是对业务数据包中重复出现内容进行替换和重新编码的过程,因此需

要对业务数据中的固定内容进行分析,以便大概了解数据包中有多少可压缩成分。

通过对应用层数据(HTTP)、SIP信令和TCP/IPACK在传输中的数据进行特征

分析得知,这些业务数据在很大程度上有着重复的特征,这些重复出现的数据就是

后续进行压缩的基础,即它们是可以被压缩的对象。

1.2上行数据压缩方案

在该小节中,将介绍一些上行数据压缩的备选方案,并提供相关的评估结果分析以

及方案的对比,选择相对较好的方案作为LTE系统应用的UDC方案。

(1)方案一(ULonlyRoHC)

RoHC是一种将IP、UDP、RTP和TCP头进行压缩的方法,具体可参考文献[1]。

其中有多重配置profile,包括IP头、IP/UDP头和IP/TCP头等。在3GPPLTE

Rel-14中,引入了只有上行的RoHC,使RoHC只对上行数据报头进行压缩,而

对下行报头禁用压缩功能。RoHC并不能对业务净荷进行压缩。使用RoHC协议

可以去除报头中的冗余,这些冗余成分只会在第一个数据包中传输,后续的数据包

只包含了一些动态信息,例如标识符和序列号等。为了提升性能,数据包被分流到

不同的数据流,不同的数据流可以使用不同的profile进行压缩。

(2)方案二(基于Zlib(RFC1950[2])的UDC方案)

基于ZlibUDC的压缩流程如图1所示:

图1Zlib压缩流程示例

为了跨包查询匹配内容,将每个源数据包都存在一个可配置的缓存中。压缩后的数

据包格式如图2所示:

图2基于Zlib的压缩包格式

Zlib报头各字段定义如下:CMF,压缩窗口长度;FLG,指示是否有字典信息;

DICTID,字典ID。

这里没有使用预置字典。Zlib算法的详细描述和压缩数据格式见文献[2]。

(3)方案三(基于RFC1951的UDC方案:DEFLATE-based)

RFC1951[3]中给出了基于DEFLATE的压缩数据格式规范。DEFLATE是一种结合

了LZ77算法和Huffman编码的无损数据压缩算法,相比RFC1950

您可能关注的文档

文档评论(0)

193****0658 + 关注
实名认证
文档贡献者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档