研究与探讨
９４
2019年第11期
收稿日期：2019-09-17
LTE系统中的上行数据压缩技术
Uplink Data Compression in L TE Systems
3GPP LTE 系统存在上行资源受限，以及VoLTE 语音在小区边缘的建立会话成功率低等问题，为了分析如何通过上行数据压缩来解决这些问题，介绍了在接入层对终端的上行数据进行压缩的方式，包括分析上行数据源的特征，选择合适的压缩方法，以及如何在LT E 中支持相关方法等，从而提供了完整的支持上行数据压缩的解决方案。
上行数据压缩；DEFLATE 算法；LTE 系统；上行资源受限
In 3GPP LTE system, there are some problems, such as limited uplink resources and low success rate of
sessions in the cell edge. In order to analyze how to solve these problems through uplink data compression, this paper introduces to compress the uplink data of terminals at the access layer, including analyzing the characteristics of uplink data source, selecting the suitable compression method, and how to support the relevant methods in LTE systems. Hence a complete solution to support uplink data compression is provided.uplink data compression; DEFLATE algorithm; LTE system; limited uplink resources
（大唐移动通信设备有限公司标准部，北京 100083）
(Datang Mobile Communications Equipment Co., Ltd., Beijng 100083, China)
【摘  要】
【关键词】
全海洋
QUAN Haiyang
doi:10.3969/j.issn.1006-1010.2019.11.015        中图分类号：TN929.5 文献标志码：A        文章编号：1006-1010(2019)11-0094-07
引用格式：全海洋. LTE系统中的上行数据压缩技术[J]. 移动通信, 2019,43(11): 94-100.
OSID ：
0  引言
在3GPP 标准的R15阶段中，为了解决上行资源受限以及VoLTE 语音在小区边缘建立会话成功率低的问题，提出了在接入层对终端的上行数据进行压缩的方式。本文接下来将对上行数据源的特征进行分析，并选择合适的压缩方法，以及就如何在LTE 中支持相关方法进行分析。[Abstract]
[Key words]
1  上行数据压缩在LTE 系统中的应用
1.1  业务特征
为了获得更全面的UDC （Uplink data compres-sion ，上行数据压缩）性能表现，UDC 可以在如下三类业务下分别进行评估。
（1）类型1（非加密业务）：主要是在应用层没有加密的数据业务，例如网页浏览、文本上传、在线视频和即时通讯文本对话等。
扫描二维码与作者交流
研究与探讨
输入数据输出数据
（2）类型2（VoLTE SIP 信令）：主要针对VoLTE 业务的SIP 信令，这些信令是非加密非压缩的数据，例如INVITE 消息、PRACK 消息等。
（3）类型3（不经过R o H C （R o b u s t  H e a d e r C o m p r e s s i o n ，健壮报头压缩）的H T T P S 业务）：HTTPS 是在应用层加密的数据，这些数据包的报头没有经过RoHC 压缩，因此可以使用UDC 进行压缩，例如TCP/IP 报头可以使用UDC 进行压缩。
在UDC 性能评估中，会优先考虑类型1和类型2的业务，因为其带来的增益会更加明显。
为了更能真实地反映现实中用户数据的压缩效果，需要对混合业务的压缩性能进行评估，例如网页浏 览和视频业务、多IP 流业务等。
数据压缩一般是对业务数据包中重复出现内容进行替换和重新编码的过程，因此需要对业务数据中的固定内容进行分析，以便大概了解数据包中有多少可压缩成分。通过对应用层数据（HTTP ）、SIP 信令和TCP/IP ACK 在传输中的数据进行特征分析得知，这些业务数据在很大程度上有着重复的特征，这些重复出现的数据就是后续进行压缩的基础，即它们是可以被压缩的对象。
1.2  上行数据压缩方案
在该小节中，将介绍一些上行数据压缩的备选方案，并提供相关的评估结果分析以及方案的对比，选择相对较好的方案作为LTE 系统应用的UDC 方案。字符串长度压缩
（1）方案一（UL only RoHC ）
R o H C 是一种将I P 、U D P 、RT P 和T C P 头进行压缩的方法，具体可参考文献[1]。其中有多重配置profile ，包括IP 头、IP/UDP 头和IP/TCP 头等。在3GPP LTE Rel-14中，引入了只有上行的RoHC ，使RoHC 只对上行数据报头进行压缩，而对下行报头禁用压缩功能。RoHC 并不能对业务净荷进行压缩。使用RoHC 协议可以去除报头中的冗余，这些冗余成分只会在第一个数据包中传输，后续的数据包只包含了一些动态信息，例如标识符和序列号等。为了提升性能，数据包被分流到不同的数据流，不同的数据流可以使用不同的profile 进行压缩。
（2）方案二（基于Zlib （RFC 1950[2]）的UDC 方案）基于Zlib UDC 的压缩流程如图1所示：
和匹配重复出现的字符串，并用编码进行替换。在滑动窗口中到和当前字符串相同的字符串时，算法会将当前字符串用（length, distance ）的二元组进行替
换，其中“length “distance 字符距离。很多情况下，DEFLATE 中使用贪婪匹配寻最大长度的匹配字符
串，以达到最高的压缩比例。另外，没有匹配的字符都定义“literal ”。
研究与探讨
９６
2019年第11期
基于DEFLATE 的上行压缩方案中，采用了跨包压缩的思想，即之前的数据包会放入一个固定大小的缓
存（压缩缓存），当前数据包根据缓存中的内容即之前的数据包内容进行匹配压缩。DEFLATE 使用了自适应Huffman 编码选择，会对静态Huffman 和动态Huffman 进行自适应选择，以达到最佳的压缩效率。
由于要在P D C P 层进行U D C 操作，是否执行了UDC 的操作还需要额外的指示信息，所以预留了1字节长度的UDC 头。该UDC 头中可以包括与UDC 相关的各种指示信息（如是否进行压缩的指示、是否重置以及校验信息等）。UDC 头的内容并不影响仿真结果，具体设计在后文将会详细介绍。
（4）方案四（APDC （
pression ，自适应包压缩））
A P D C 方案是高通公司提出案，UE 和eN
B 各自维护一个APD
C 录之前未经压缩的数据包内容。达时，UE 部分或完全匹配。如果存在匹配的内容，U E 将向e N B 发送指针（匹配的数据块在缓存和数据包中的地址或位置），而不是实际的数据。解压缩算法和著名的C 语言库函数“memcpy （srcaddr, destaddr, length ）”类似，解压器简单地将指针指向的数据从压缩缓存拷贝至当前数据包中，用来恢复原始数据包。
A P D C 报头处于压缩数据之前，报头中指示了解压器该如何解压。如图3所示，APDC 报头由A P D C 公共报头、（0个或1个）PMCR 报头和（0个或1个）CPCR 报头组成。如果A P D C 公共报头中的“E ”比特设为1，则后面有P M C R 报头；否则，公共报头后面没有PMCR 报头。如果有PMCR 报头，则P M C R 报头总在C P C R
报头之 前。这表示数据包的一部分用PMCR 报头来解压，剩余部分使用CPCR 报头来解压。
1）CPCR （Current Packet Compression Refe-rence ）：压缩/解压机制，指示APDC 压缩缓存中单独的匹配部分。CPCR 报头中指示了数据包中和压缩缓存中匹配的内容。
2）PMCR （Packet Match Compressed Refe-rence ）：这种报头指示出数据包中不匹配的部分。PMCR 报头是可选报头，当公共报头中的“E ”比特置为1时才会存在PMCR 报头。
1.3  上行数据压缩仿真结果与方案选择
（1）仿真假设和指标
针对1.2节中的四种方案，为了让仿真评估结果公平可靠，使用相同的业务数据作为仿真输入，针对这些方案分别进行仿真评估。仿真所用的业务数据均由实际网络抓包获取。
仿真评估使用的仿真假设如下：
1）目标是设计一种用户上行用户面DRB 数据的压
Bit 1
Bit 2
Bit 3Bit 4Bit 5Bit 6Bit 7Bit 8PMCR 头
CPCR PMCR UDC 头CPCR 头UDC 公共报头
CPCR 公共头
PMCR
公共头
输入数据
输出数据
图3    APDC 压缩数据格式
研究与探讨
缩方案，例如HTTP 数据、ACK 等。因此，仿真只考虑用户面2）压缩缓存的大小可能会对压缩效果起一定作用，因此仿真考虑了8k 和32k 3）评估中因为涉及了终端侧和网络侧的压缩缓存和解压缓存的一致性，模式。
4）在仿真中，UDC 同时对报头和净荷进行压缩。
5）为了减少终端的复杂度，不考虑净荷部分的方式。
6）UDC 图4给出了UDC UDC 模块后，经过UDC 图4    UDC 处理框图
仿真中使用了压缩效率作为仿真评估指标：除此之外，因为高运算复杂度会对算法的实际应
用产生影响，另外也会增加系统存储开销，所以，除了压缩效率之外，还需要考虑压缩器和解压器对于每种方案的处理复杂度。尽管复杂度无法精确量化，但可以在一定程度上给出定性分析。同时，仿真评估中应该考虑输入和输出数据的可
读性和字节对齐问题。）仿真结果与综合分析
案一）只能对T C P /I P 、U D P /
，而其他上行数据压缩方案）可以同时对数据报头和RoHC 对于SIP 信令的压RoHC 的压缩性能和TCP/I P 头在P D C P S D U 数据包中占的比例强相关。如果TCP/IP 头占用比例高，则上行RoHC 也可以达到很高的压缩效率。
基于Zlib 的方案、基于DEFLATE 的方案和APDC 方案在压缩效率（1-压缩数据大小/原数据大小）方面
表现出了类似的性能趋势。对于Bit 1Bit 2Bit 3Bit 4Bit 5Bit 6Bit 7Bit 8PMCR 头
CPCR 头元数据PMCR
头元数据
UDC 头
CPCR 头
UDC 公共报头
CPCR 公共头
PMCR 公共头
输入数据
输出数据
基于DEFLATE （RFC 1951）的UDC 方案从压缩缓存
中查并替换字符（LZ77）
Huffman 编码
基于Zlib （RFC 1950）的UDC 方案
Huffman 编码
添加Zlib 头; 计算Checksum
用于解压器验证
APDC 的UDC 方案
将匹配和非匹配信息写入APDC 头（类似于指针），将非匹配内容拷贝至压缩数据包中
计算Checksum 用于解压器验证
表2    解压器各种方案的处理复杂度对比
解压器各种方案
步骤1步骤2
步骤3基于DEFLATE （RFC 1951）的UDC 方案Huffman 解码根据length,distance 进行-
研究与探讨
９８
2019年第11期
网页浏览业务，压缩效率也能超过60%。
仿真评估考虑了8 kbyte 、16 kbyte 和32 kbyte 的压缩缓存大小。但压缩缓存的增大并不能导致压缩效率的显著提升，例如32 kbyte 缓存配置的压缩性能仅比8 kbyte 缓存的压缩效率有略微提升。
对于混合业务，所有的上行压缩方案都表现出了显著的压缩性能。
表1、表2分别为压缩端和解压段对Zlib 、DEFLATE 和APDC 三种方案的处理对比。
综合考虑各种因素，如压缩效率、实现的复杂度、算法的应用广泛度、专利风险等，更推荐选择使用基于DEFLATE 的上行压缩方法。因为DEFLATE 是已经被最广泛应用的压缩算法，静态Huffman 编码的压缩效率与自适应的Huffman 编码的压缩效率相差无几，但其复杂度要更低。APDC 虽然也有这类似的压缩效率，但其专利风险性比较高，另外应用也不是很广泛。对于Zlib 的方案，其算法本质仍然是DEFLATE 的算法，只是包装了Zlib 的头和尾。为了提高压缩效率，该方案跟DEFLATE 的方案进行融合，将其头和尾中必要的信息放到1字节的UDC 的头中，以减少头尾的开销。
1.4  LTE 系统中支持上行数据压缩的其他关键技术
在选定了UDC 的方案之后，下面需考虑在LTE 系统中如何支持该基于DEFLATE 的UDC 方案。主要考虑如下的一些关键技术点为：UDC 的header 的设计；UDC 的配置、激活与去激活；错误处理流程等。
以下逐一解决这些问题。（1）UDC 的header 的内容设计
根据前面的分析，UDC 能够对大部分现有业务提供较高的压缩增益，其主要原因是数据包之间的数据重复性。但是在实际网络中，也有一些业务是不需要进行UDC 压缩的，例如一些已经经过了高层压缩的业务，一些已经经过了加密的业务数据包。对这些业务来说，UDC 仅仅能够通过对TCP/IP 头部的压缩带来很小的增益。另一方面，UDC 功能是基于无线承载粒度来配置的，在一个承载里，既有可能包含已经经过高层压缩的数据流，也有可能包含未经过高层压缩的数
据流。因此，我们需要1比特指示来明确地区分是否该数据包进行UDC 压缩。
对于一个会商用的UDC 方案，还需要解决的一个关键问题就是其可靠性。对于UDC ，由于其压缩缓存和解压缩缓存就是其压缩字典和解压缩字典，保证两边缓存的一致性和正确性就非常关键，一个比特的差异就会导致解压错误。缓存验证的基本原理是：在发送端根据当前的缓存状况，计算出一个校验和值（通常叫Checksum ），将这个校验和值携带在数据包里，带到接收端，接收端也根据自己当前的缓存状况以相同的方式计算出一个校验和值，如果两端的值相同，则说明两端的缓存是同步的，如果不同，则说明发生了异常导致缓存不同步，此时无法进行正确的解压缩操作，需要启动复位流程。
计算校验和值的时候，应该以之前缓存为主，即待发的这个数据包不应该计算在内，而之前的数据包都已经包含在缓存里。这样对于接收端来说，能够尽快地发现校验错误。缓存校验值的算法有很多惯用的方法可以参考，例如CRC 等。而且缓存校验值也可以截短到4比特，4比特对于UDC 校验来说已经足够，因为为了保证不丢数据包，UDC 只适用于RLC AM ，由于传输错误而引起的压缩缓存和解压缓存的不同步情况是比较少见的。
可以参考将TCP/IP 协议中已有的一些现成的关于16 bit/8 bit Checksum 值的计算方法应用于UDC 中。其大体的思路都是对缓冲区的数据进行二进制求和，再对一些特殊进位以及取反处理等。由于需考虑将该方案商用，因此需考虑其处理上的开销。为了进一步降低计算Checksum 数值的复杂度，不需要对所有缓冲区中的数据进行二进制求和操作，而仅需要对部分关键数据进行计算即可。选取的规则可以是缓存开头、缓存结尾、缓存中间，甚至是满足一定p a t t e r n 的数据，比如将缓存中的最初4个字节和最末尾4个字节的数据作为计算Checksum 的输入，参与计算，其他数据不涉及。当缓存为空时，相应的位置以0替代。当计算了缓存中的最初4个字节和最末尾4个字节的数据的所有位数上的二进制和之后，需要从中截取4 bit 的

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。