CN111328104A - 数据包的解压缩方法和装置 - Google Patents

数据包的解压缩方法和装置 Download PDF

Info

Publication number
CN111328104A
CN111328104A CN201811535588.5A CN201811535588A CN111328104A CN 111328104 A CN111328104 A CN 111328104A CN 201811535588 A CN201811535588 A CN 201811535588A CN 111328104 A CN111328104 A CN 111328104A
Authority
CN
China
Prior art keywords
data packet
packet
timestamp
period
timestamps
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN201811535588.5A
Other languages
English (en)
Other versions
CN111328104B (zh
Inventor
居双双
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to CN201811535588.5A priority Critical patent/CN111328104B/zh
Priority to PCT/CN2019/124546 priority patent/WO2020119718A1/zh
Publication of CN111328104A publication Critical patent/CN111328104A/zh
Application granted granted Critical
Publication of CN111328104B publication Critical patent/CN111328104B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • H04W28/0205Traffic management, e.g. flow control or congestion control at the air interface
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/0001Systems modifying transmission characteristics according to link quality, e.g. power backoff
    • H04L1/0006Systems modifying transmission characteristics according to link quality, e.g. power backoff by adapting the transmission format
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/004Arrangements for detecting or preventing errors in the information received by using forward error control
    • H04L1/0056Systems characterized by the type of code used
    • H04L1/0061Error detection codes
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/0078Avoidance of errors by organising the transmitted data in a format specifically designed to deal with errors, e.g. location
    • H04L1/0079Formats for control data
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • H04W28/06Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • H04W28/06Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • H04W28/065Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information using assembly or disassembly of packets
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W56/00Synchronisation arrangements

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Quality & Reliability (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Telephonic Communication Services (AREA)

Abstract

本申请实施例的数据包的解压缩方法和装置,在当前数据包的包头解压缩失败时,通过确定包头解压缩失败是否发生在通话期和静默期转换过程,当包头解压缩失败发生在通话期和静默期转换过程,根据报文序号差值、数据包解压缩上下文的时间戳步长和最近一个正确解压缩的数据包的时间戳获取多个待校验时间戳,使用多个待校验时间戳中CRC正确的时间戳更新上下文。本申请实施例可以减少因关键数据包丢失或者压缩编码方式的兼容性问题导致的解压缩失败,进而避免由于解压缩失败所引起的连续丢包或反复丢包,保证语音质量。

Description

数据包的解压缩方法和装置
技术领域
本申请实施例涉及通信技术领域,尤其一种数据包的解压缩方法和装置。
背景技术
健壮的包头压缩(Robust Header Compression,RoHC)是一种高效的包头压缩技术,在无线通信中应用于链路层中的分组数据汇聚协议(Packet Data ConvergenceProtocol,PDCP)层,可以大大提高空口传输效率,节省空口资源,提升小区边缘覆盖和系统容量。
压缩端在PDCP层对原始报文进行包头压缩,压缩后的报文经无线链路控制(Radio Link Control,RLC)层、媒体接入控制(Media Access Control,MAC)层和物理层(PHY)进行相关处理后,经空口传输到接收端,解压端收到后将压缩包经PHY 层、MAC层和RLC层递交到PDCP层,在PDCP层由解压端对压缩报文进行解压缩恢复出原始报文,从而完成压缩解压缩过程。其中,当一个新的数据流到来时,压缩端首先进入压缩初始化状态,将数据流的分组包头信息保存在压缩端相应的上下文中,并将完整的包头信息发送给解压缩端,解压缩端将该包头信息保存到解压缩端相应的上下文中,当解压缩端收到所有上下文后,压缩端进入压缩状态,开始发送压缩报文。压缩端每发送一个压缩报文,都可以有选择的更新上下文,以保证压缩端上下文中保存的是压缩端最后发送成功的包头信息,相应的,解压缩端接收到压缩报文后,可以更新相应的解压缩端的上下文,以保证压缩端和解压缩端的上下文同步。
由于解压缩端对当前接收到的压缩报文进行解压缩所使用的上下文,都是基于最近一次正确解压的报文获取的,如果承载时间戳步长(Ts_stride)跳变信息和时间戳步长系数(TS_scaled)变更信息的重要压缩报文丢失(如:空口波动、弱覆盖丢包),或者出现连续多个压缩报文(包含重要压缩报文)丢失,压缩端和解压缩端的上下文中的时间戳(Timestamp)相关信息会不一致,如时间戳步长(Ts_stride)、时间戳步长系数(TS_scaled)等。后续进入新的通话期或者静默期的压缩报文(如0型包)就会出现连续解压失败,从而引起语音质量恶化。
发明内容
本申请实施例提供一种数据包的解压缩方法和装置,以减少因关键数据包丢失或者压缩编码方式的兼容性问题导致的解压缩失败,提升语音质量。
一方面,本申请实施例提供一种数据包的解压缩方法,包括:在当前数据包的包头解压缩失败时,确定所述包头解压缩失败是否发生在通话期和静默期转换过程;当所述包头解压缩失败发生在通话期和静默期转换过程,根据报文序号差值、数据包的时间戳步长和最近一个正确解压缩的数据包的时间戳获取多个待校验时间戳,所述报文序号差值为所述当前数据包解码后的报文序号与所述最近一个正确解压缩的数据包的报文序号的差值;使用所述多个待校验时间戳中,使得所述当前数据包的包头循环冗余校验CRC正确的时间戳更新上下文,所述上下文用于对后续接收到的数据包进行解压缩。
本方面,可以减少因关键数据包丢失或者压缩编码方式的兼容性问题导致的解压缩失败,提升语音质量。
需要说明的是,本申请实施例的方法步骤的执行主体是解压缩端,该解压缩端可以是终端设备或者终端设备中的芯片、也可以是接入网设备或者接入网设备中的芯片。例如,对于上行传输,该执行主体是终端设备或者终端设备中的芯片,对于下行传输,该执行主体是接入网设备或者接入网设备中的芯片。
在一种可能的设计中,所述使用所述多个待校验时间戳中,使得所述当前数据包的包头循环冗余校验CRC正确的时间戳更新上下文,包括:使用所述多个待校验时间戳分别和所述当前数据包的包头的其他字段信息进行CRC,确定是否存在校验正确的时间戳;当存在校验正确的时间戳时,根据所述校验正确的时间戳确定时间戳步长系数,使用所述校验正确的时间戳和所述时间戳步长系数更新所述上下文。
本设计中,通过校验正确的时间戳进一步确定时间戳步长系数,使用校验正确的时间戳和时间戳步长系数更新上下文,从而提升对后续接收到的数据包解压缩的正确率。
在一种可能的设计中,当存在多个校验正确的时间戳时,所述方法还包括:使用多个更新后的上下文分别对后续接收到的数据包进行解压缩,将连续k次解压缩成功的更新后的上下文,作为用于对后续接收到的数据包进行解压缩的上下文;其中,所述多个更新后的上下文为根据多个校验正确的时间戳分别确定的,k取大于1的整数。
本设计中,由于不能比特数的CRC校验位存在不同的误码率,当存在多个校验正确的时间戳,可以进一步使用更新后的上下文进行多次解压缩,以实现正确更新上下文,保证正确解压缩后续接收到的数据包,提升语音通话质量。
在一种可能的设计中,所述多个待校验时间戳包括:{前Timestamp+Ts_stride*delta_sn,前Timestamp+Ts_stride*(delta_sn+1),……,前Timestamp+Ts_stride*delta_sn*8};其中,前Timestamp表示所述最近一个正确解压缩的数据包的时间戳,Ts_stride表示所述数据包的时间戳步长,delta_sn表示所述报文序号差值。
在一种可能的设计中,所述方法还包括:从步长集合中选取一个作为所述数据包的时间戳步长,所述步长集合包括通话期步长、静默期步长和零中一项或者多项;执行根据所述报文序号差值、所述数据包的时间戳步长和最近一个正确解压缩的数据包的时间戳获取多个待校验时间戳步骤;在确定所述多个待校验时间戳中不存在校验正确的时间戳时,则从所述步长集合中选择一个不同的步长取值作为所述数据包的时间戳步长,直至获取的多个待校验时间戳中存在校验正确的时间戳。
在一种可能的设计中,所述方法还包括:在对接收到的数据包进行解压缩过程中,根据解压缩正确的相邻数据包的时间戳差值确定所述步长集合。
在一种可能的设计中,所述根据解压缩正确的相邻数据包的时间戳差值确定所述步长集合,包括:在所述当前数据包之前出现过解压缩正确的通话期数据包时,将相邻通话期数据包的时间戳之差作为所述通话期步长,所述静默期步长等于通话期步长*8;在所述当前数据包之前出现过解压缩正确的静默期数据包时,将相邻静默期数据包的时间戳之差作为所述静默期步长,所述通话期步长等于静默期步长/8。
在一种可能的设计中,所述确定所述包头解压缩失败是否发生在通话期和静默期转换过程,包括:根据当前数据包的包类型与所述最近一个正确解压缩的数据包的包类型,确定所述包头解压缩失败是否发生在通话期和静默期转换过程。
在一种可能的设计中,所述根据当前数据包的包类型与所述最近一个正确解压缩的数据包的包类型,确定所述包头解压缩失败是否发生在通话期和静默期转换过程,包括:当前数据包的包类型与所述最近一个正确解压缩的数据包的包类型不同时,确定所述包头解压缩失败发生在通话期和静默期转换过程;当前数据包的包类型与所述最近一个正确解压缩的数据包的包类型相同时,根据语音数据包和静默数据包的丢包个数,确定所述包头解压缩失败是否发生在通话期和静默期转换过程。
在一种可能的设计中,所述根据语音数据包和静默数据包的丢包个数,确定所述包头解压缩失败是否发生在通话期和静默期转换过程,包括:根据所述报文序号差值和接收时间间隔确定所述语音数据包的丢包个数和所述静默数据包的丢包个数,所述接收时间间隔为所述当前数据包与所述最近一个正确解压缩的数据包之间的时间间隔;在满足以下任一条件时,确定所述包头解压缩失败发生在通话期和静默期转换过程:所述语音数据包的丢包个数和所述静默数据包的丢包个数均不等于0;或者,所述语音数据包的丢包个数等于 0,所述静默数据包的丢包个数不等于0,且所述当前数据包为语音数据包;或者,所述语音数据包的丢包个数不等于0,所述静默数据包的丢包个数等于0,且所述当前数据包为静默数据包。
在一种可能的设计中,所述方法还包括:根据所述当前数据包的净荷长度确定所述当前数据包的包类型;根据所述最近一个正确解压缩的数据包的净荷长度确定所述最近一个正确解压缩的数据包的包类型。
另一方面,本申请实施例提供了一种数据包的解压缩装置,该数据包的解压缩装置具有实现上述方法的功能。所述功能可以通过硬件实现,也可以通过硬件执行相应的软件实现。所述硬件或软件包括一个或多个与上述功能相对应的模块。在一个可能的设计中,上述数据包的解压缩装置的结构中包括处理器和收发器,所述处理器被配置为处理该数据包的解压缩装置执行上述方法中相应的功能。所述收发器用于实现上述数据包的解压缩装置与压缩端之间的通信。所述数据包的解压缩装置还可以包括存储器,所述存储器用于与处理器耦合,其保存该数据包的解压缩装置必要的程序指令和数据。
又一方面,本申请实施例提供了一种通信装置,包括:接收模块和处理模块;所述处理模块,用于在通过所述接收模块接收到的当前数据包的包头解压缩失败时,确定所述包头解压缩失败是否发生在通话期和静默期转换过程;所述处理模块,还用于当所述包头解压缩失败发生在通话期和静默期转换过程,根据报文序号差值、数据包的时间戳步长和最近一个正确解压缩的数据包的时间戳获取多个待校验时间戳,所述报文序号差值为所述当前数据包解码后的报文序号与所述最近一个正确解压缩的数据包的报文序号的差值;所述处理模块,还用于使用所述多个待校验时间戳中,使得所述当前数据包的包头循环冗余校验CRC正确的时间戳更新上下文,所述上下文用于对后续接收到的数据包进行解压缩。
在一种可能的设计中,所述处理模块用于:使用所述多个待校验时间戳分别和所述当前数据包的包头的其他字段信息进行CRC,确定是否存在校验正确的时间戳;当存在校验正确的时间戳时,根据所述校验正确的时间戳确定时间戳步长系数,使用所述校验正确的时间戳和所述时间戳步长系数更新所述上下文。
在一种可能的设计中,所述处理模块还用于当存在多个校验正确的时间戳时,使用多个更新后的上下文分别对后续接收到的数据包进行解压缩,将连续k次解压缩成功的更新后的上下文,作为用于对后续接收到的数据包进行解压缩的上下文;其中,所述多个更新后的上下文为根据多个校验正确的时间戳分别确定的,k取大于1的整数。
在一种可能的设计中,所述多个待校验时间戳包括:{前Timestamp+Ts_stride*delta_sn,前Timestamp+Ts_stride*(delta_sn+1),……,前Timestamp+Ts_stride*delta_sn*8};其中,前Timestamp表示所述最近一个正确解压缩的数据包的时间戳,Ts_stride表示所述数据包的时间戳步长,delta_sn表示所述报文序号差值。
在一种可能的设计中,所述处理模块还用于:从步长集合中选取一个作为所述数据包的时间戳步长,所述步长集合包括通话期步长、静默期步长和零中一项或者多项;执行根据所述报文序号差值、所述数据包的时间戳步长和最近一个正确解压缩的数据包的时间戳获取多个待校验时间戳步骤;在确定所述多个待校验时间戳中不存在校验正确的时间戳时,则从所述步长集合中选择一个不同的步长取值作为所述数据包的时间戳步长,直至获取的多个待校验时间戳中存在校验正确的时间戳。
在一种可能的设计中,所述处理模块还用于:在对接收到的数据包进行解压缩过程中,根据解压缩正确的相邻数据包的时间戳差值确定所述步长集合。
在一种可能的设计中,所述处理模块用于:在所述当前数据包之前出现过解压缩正确的通话期数据包时,将相邻通话期数据包的时间戳之差作为所述通话期步长,所述静默期步长等于通话期步长*8;在所述当前数据包之前出现过解压缩正确的静默期数据包时,将相邻静默期数据包的时间戳之差作为所述静默期步长,所述通话期步长等于静默期步长/8。
在一种可能的设计中,所述处理模块用于:根据当前数据包的包类型与所述最近一个正确解压缩的数据包的包类型,确定所述包头解压缩失败是否发生在通话期和静默期转换过程。
在一种可能的设计中,所述处理模块用于:当前数据包的包类型与所述最近一个正确解压缩的数据包的包类型不同时,确定所述包头解压缩失败发生在通话期和静默期转换过程;当前数据包的包类型与所述最近一个正确解压缩的数据包的包类型相同时,根据语音数据包和静默数据包的丢包个数,确定所述包头解压缩失败是否发生在通话期和静默期转换过程。
在一种可能的设计中,所述处理模块用于:根据所述报文序号差值和接收时间间隔确定所述语音数据包的丢包个数和所述静默数据包的丢包个数,所述接收时间间隔为所述当前数据包与所述最近一个正确解压缩的数据包之间的时间间隔;在满足以下任一条件时,确定所述包头解压缩失败发生在通话期和静默期转换过程:所述语音数据包的丢包个数和所述静默数据包的丢包个数均不等于0;或者,所述语音数据包的丢包个数等于0,所述静默数据包的丢包个数不等于0,且所述当前数据包为语音数据包;或者,所述语音数据包的丢包个数不等于0,所述静默数据包的丢包个数等于0,且所述当前数据包为静默数据包。
在一种可能的设计中,所述处理模块还用于:根据所述当前数据包的净荷长度确定所述当前数据包的包类型;根据所述最近一个正确解压缩的数据包的净荷长度确定所述最近一个正确解压缩的数据包的包类型。
又一方面,本申请实施例提供了一种通信装置,包括:处理器,该处理器用于执行上述第一方面或第一方面的任一种可能的设计所述的方法。该通信装置还可以包括存储器,该存储器用于存储指令或者数据,处理器可以调用该指令或者数据执行上述第一方面或第一方面的任一种可能的设计所述的方法。
在一种可能的设计中,该通信装置可以是终端设备、接入网络设备、终端设备中的芯片或者接入网设备中的芯片。
又一方面,本申请实施例提供一种计算机可读存储介质,其上存储有指令,该指令被执行时执行上述一方面的所述方法。
又一方面,本申请实施例提供了一种包含指令的计算机程序产品,当其在计算机上运行时,使得计算机执行上述一方面所述的方法。
又一方面,本申请提供了一种芯片系统,该芯片系统包括处理器,用于支持上述数据包的解压缩装置或终端设备实现上述方面中所涉及的功能,例如,生成或处理上述方法中所涉及的信息。在一种可能的设计中,所述芯片系统还包括存储器,所述存储器,用于保存数据包的解压缩装置或终端设备必要的程序指令和数据。该芯片系统,可以由芯片构成,也可以包含芯片和其他分立器件。
本申请实施例的数据包的解压缩方法和装置,在当前数据包的包头解压缩失败时,通过确定包头解压缩失败是否发生在通话期和静默期转换过程,当包头解压缩失败发生在通话期和静默期转换过程,根据报文序号差值、数据包的时间戳步长和最近一个正确解压缩的数据包的时间戳获取多个待校验时间戳,使用多个待校验时间戳中CRC正确的时间戳更新上下文,从而减少因关键数据包丢失或者压缩编码方式的兼容性问题导致的解压缩失败,进而避免由于解压缩失败所引起的连续丢包或反复丢包,保证语音质量。
附图说明
图1为本申请实施例的一种系统架构示意图;
图2A为本申请实施例的RoHC基本压缩原理示意图;
图2B为本申请实施例的数据包的包头所包括的字段的示意图;
图2C为本申请实施例的压缩端状态变化示意图;
图2D为本申请实施例的压缩端状态变化示意图;
图2E为本申请实施例的不同的压缩解压缩状态转化过程中包头的变化示意图;
图3为本申请实施例的一种应用场景的示意图;
图4为本申请实施例的一种数据包的解压缩方法的流程图;
图5为本申请实施例的另一种数据包的解压缩方法的流程图;
图6为本申请实施例的另一种数据包的解压缩方法的流程图;
图7A为本申请实施例的一种数据包的解压缩装置的结构示意图;
图7B为本申请实施例的另一种数据包的解压缩装置的结构示意图。
具体实施方式
下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述。
本文所涉及的“多个”是指两个或两个以上。“和/或”,描述关联对象的关联关系,表示可以存在三种关系,例如,A和/或B,可以表示:单独存在A,同时存在A和B,单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。
本申请实施例的技术方案可以应用于各种数据处理的通信系统,例如:例如码分多址 (code division multiple access,CDMA)、时分多址(time division multipleaccess,TDMA)、频分多址(frequency division multiple access,FDMA)、正交频分多址(orthogonal frequency-division multiple access,OFDMA)、单载波频分多址(singlecarrier FDMA, SC-FDMA)和其它系统等。术语“系统”可以和“网络”相互替换。CDMA系统可以实现例如通用无线陆地接入(universal terrestrial radio access,UTRA),CDMA2000等无线技术。UTRA可以包括宽带CDMA(wideband CDMA,WCDMA)技术和其它CDMA变形的技术。CDMA2000可以覆盖过渡标准(interim standard,IS)2000(IS-2000),IS-95 和IS-856标准。TDMA系统可以实现例如全球移动通信系统(global system for mobilecommunication,GSM)等无线技术。OFDMA系统可以实现诸如演进通用无线陆地接入(evolved UTRA,E-UTRA)、超级移动宽带(ultra mobile broadband,UMB)、IEEE 802.11(Wi-Fi),IEEE 802.16(WiMAX),IEEE 802.20,Flash OFDMA等无线技术。UTRA 和E-UTRA是UMTS以及UMTS演进版本。3GPP在长期演进(long term evolution,LTE) 和基于LTE演进的各种版本是使用E-UTRA的UMTS的新版本。第五代(5Generation, 5G)通信系统、新空口(NewRadio,NR)是正在研究当中的下一代通信系统。此外,所述通信系统还可以适用于面向未来的通信技术,都适用本申请实施例提供的技术方案。
终端设备(terminal device),也可以称之为用户设备(User Equipment,UE)、移动终端(Mobile Terminal,MT)、移动用户设备等,可以经无线接入网(例如,Radio AccessNetwork,RAN)与一个或多个核心网进行通信。用户设备可以是移动终端,如移动电话 (或称为“蜂窝”电话)和具有移动能力的计算机,例如,可以是便携式、袖珍式、手持式、计算机内置的或者车载的移动装置。也可以是机器类通信MTC中的通信设备。
接入网设备可以是一种部署在无线接入网中为终端设备提供无线通信功能的装置。所述接入网设备可以包括各种形式的宏基站,微基站(也称为小站),中继站,接入点等,也可以包括各种形式的控制节点,如网络控制器。所述控制节点可以连接多个基站,并为所述多个基站覆盖下的多个终端设备配置资源。在采用不同的无线接入技术的系统中,具备基站功能的设备的名称可能会有所不同,如LTE中的eNB或e-NodeB,也可以是5G 或NR中的基站或发射接收端点,如gNB,本申请实施例对此并不限定。
图1为本申请实施例的一种系统架构示意图,如图1所示,本实施例的系统架构可以压缩端1和解压缩端2。
其中,例如,对于上行传输,该压缩端1可以是上述任一种终端设备,该解压缩端2可以是上述任一种接入网设备。对于下行传输,该压缩端1可以是上述任一种接入网设备,该解压缩端2可以是上述任一种终端设备。
本申请实施例的压缩端1和解压缩端2采用RoHC技术,以提高空口传输效率,节省空口资源,提升小区边缘覆盖和容量。
压缩端的RoHC压缩器(RoHC Compressor)对数据包的包头进行压缩,该包头可以是IP字段+TCP字段、IP字段+UDP字段、IP字段+UDP字段+RTP字段,其中,IP字段可以是IPv4字段或IPv6字段。图2A为本申请实施例的RoHC基本压缩原理示意图,如图2A所示,压缩端的包头为IPv4字段或IPv6字段(即如图2A所示的IPv4/6)+UDP 字段+RTP字段,经过RoHC压缩器,该包头可以被压缩成一个较少字节数的包头,以语言业务为例,可以将40个字节的IPv4字段+UDP字段+RTP字段的包头压缩至1个字节,压缩效率高达90%以上。对不同字段的压缩效率可以参见表1所示。压缩端进行压缩后得到如图2A所示的数据包,该数据包包括较少字节数的包头字段(即如图2A所示的H) 和净荷(payload)。
表1压缩效率表
Figure BDA0001906769600000071
解压缩端接收到该数据包后,通过RoHC解压缩器(RoHC Compressor)进行解压缩,恢复出数据包的原始包头,即如图2A所示的IPv4字段或IPv6字段(即如图2A所示的 IPv4/6)+UDP字段+RTP字段。
上述数据包的包头所包括的字段的具体内容可以参见图2B,如图2B所示,IPv4字段可以包括版本号字段、源地址字段、目的地址字段等,以携带相应的信息。
RoHC压缩器之所以能够实现头压缩,是因为同一数据流的连续包头中存在有意义的冗余。以语音业务为例,同一语音数据流内连续包头中不变字段(如斜纹字段)占62%,由其他字段可推算出的字段(如图竖纹字段)占13%,变化字段(如图空白背景字段)占 25%,其中,变化字段中的IP-ID字段、SN字段、时间戳字段所携带的信息还呈一定规律变化。例如,相邻语音数据包的RTP SN按序递增1,IP-ID按序递增1。
上述不变化字段所携带的信息可以称之为静态域信息,上述可推算出的字段和变化字段所携带的信息称之为动态域信息。
压缩端有3种工作状态:
压缩端初始上下文(Initialization and Refresh,IR)状态,压缩端发送数据包(如IR 包(42字节)),携带完整的静态域信息、动态域信息给解压缩端以建立初始解压缩的上下文。
一级压缩(First Order,FO)状态,压缩端动态域不稳定变化,压缩端发送数据包(如, UO-1*(6字节),R-1*(6字节),UOR-2*(13字节),IR-Dyn包(20字节)),携带变化的动态域信息给解压缩端以更新上下文。
二级压缩(Second Order,SO)状态,压缩端动态域稳定变化,压缩端发送数据包(如, UO-0(1字节),R-0(1字节)),携带最少的SN压缩信息给解压缩端以恢复整个数据包。
图2C为本申请实施例的压缩端状态变化示意图,如图2C所示,压缩端初始处于IR状态,逐渐向FO状态和SO状态迁移,处于高级压缩状态时,当收到不确认(Nack)会向低级压缩状态回迁。通过压缩状态的转换实现高效可靠的压缩。
解压缩端有3种工作状态:
无上下文(No Context,NC)状态,处于该NC状态的解压缩端只能接收IR包,以建立初始解压缩的上下文。
静态上下文(Static Context,SC)状态,解压缩端静态上下文已经建立,但动态上下文未建立或者与压缩端不同步,解压缩端需要接收UOR-2*,IR动态(IR-Dyn)包。
全上下文(Full Context,FC)状态,解压缩端静态上下文和动态上下文都已经建立且和压缩端同步,解压缩端可接收UO-0,R-0,UO-1*,R-1*。
图2D为本申请实施例的压缩端状态变化示意图,如图2D所示,解压缩端初始处于NC状态,建立好解压缩静态上下文和动态上下文后;一旦解对1个压缩包,即可跃迁到 FC状态;在FC状态,如果n个包解错k1个包则回退到SC状态;在SC状态,一旦解对 1个包可立即跃迁到FC状态;在SC状态,如果n个包解错k2个包则回退到NC状态。通过解压缩状态的转换实现正确解压缩,k1和k2为整数。
图2E为本申请实施例的不同的压缩解压缩状态转化过程中包头的变化示意图,左侧为压缩端,右侧为解压缩端,如图2E所示,压缩端初始时发送携带完整静态域信息和动态域信息的数据包(可称为压缩报文),即如图中从上至下的第一个数据包,该第一数据包携带静态域信息和动态域信息,解压缩端接收到该第一个数据包后进行解压缩,解压缩端确认解压缩端正确解压缩,并建立上下文后,向压缩端反馈解压缩成功(如图2E所示的ACK),压缩端对于后面发送的第二个数据包和第三个数据包可以不再携带静态域信息,如果动态域字段稳定变化,那么可以携带压缩的动态域信息,即如图中的第二个数据包;如果动态域字段不规律变化,那么携带完整的动态域信息,即如图中的第三个数据包。压缩报文中携带CRC校验位,解压缩端如果CRC校验正确,表示解压缩成功(如图2E 所示的ACK),否则解压缩失败(如图2E所示的NACK)。
压缩后的数据包类型可以包括:0型包(1字节),1型包(2~11字节),2型包(3~13字节),IR-dyn包(21字节),IR包(42字节)。
其中,0型包携带W-LSB编码后的报文序号(sn),例如,上述UO-0(1字节), R-0(1字节)。1型包携带W-LSB编码后的报文序号(sn)、基于步长编码后的时间戳步长系数(TS_scaled)和W-LSB编码后的时间戳(Timestamp),例如,上述UO-1*(6 字节),R-1*(6字节)。2型包携带W-LSB编码后的报文序号(sn)、基于步长编码后的时间戳步长系数(TS_scaled)和W-LSB编码后的时间戳(Timestamp),例如,上述UOR-2* (13字节),IR-Dyn包(20字节)。其中,2型包的压缩效率低于1型包。
图3为本申请实施例的一种应用场景的示意图,如图3所示,以8k采样率为例,在通话期,相邻数据包的时间戳(Timestamp)每次按规律递增160(20ms*8000/s=160),适合采用基于步长的压缩编码,Timestamp=Ts_scaled*Ts_stride+Ts_offset,Ts_stride=160,Ts_scaled每次递增1。由于时间戳步长(Ts_stride)和报文序号(sn)的变化规律一致,每次递增1,所以,压缩端在通话期可以处于SO状态,向解压缩端发送0型包,只携带报文序号(sn)的压缩编码和CRC校验位,不携带时间戳步长(Ts_stride)的编码值,解压缩端基于上下文和解码该报文序号(sn),可以还原出数据包的时间戳(Timestamp)。在通话期和静默期转换过程中,相邻数据包的时间戳(Timestamp)增长量会发生跳变,如图3所示,相邻数据包间隔时长可以为20ms~160ms,以8k采样频率为例,时间戳增长量可以是160、320、……..、1120、或1280,此时,压缩端从SO状态回退至FO状态。压缩端向解压缩端发送1型包、2型包或者IR-dyn包,以携带数据包的时间戳步长(Ts_stride) 的压缩编码。
解压缩端如果将携带时间戳步长(Ts_stride)的数据包丢失,则解压缩端无法获取到该发生变化的时间戳步长(Ts_stride),从而导致解压缩端和压缩端的上下文中的时间戳信息不一致,该时间戳信息可以包括时间戳(Timestamp)和时间戳步长(Ts_stride),进而导致后续进入通话期或静默期的0型包解压缩失败,以造成丢包,引起语音质量恶化。
上述解压缩端将携带时间戳步长(Ts_stride)的数据包丢失的原因可以包括:1)由于空口波动、弱覆盖率导致该携带时间戳步长(Ts_stride)的数据包丢失。2)由于静默期和通话期转换时,压缩端和解压缩端对数据包的时间戳信息的压缩编码处理方式不一致,例如,压缩端采用基于步长的编码方式对时间戳步长(Ts_stride)进行编码后,再做W-LSB编码,而解压缩端直接对时间戳信息采用自适应变长编码进行解压缩,因兼容性问题引起解压缩失败导致该携带时间戳步长(Ts_stride)的数据包丢失。
本申请实施例的数据包的解压缩方法,可以解压缩端利用报文序号(SN)信息、数据包的间隔特点和循环冗余校验(Cyclic Redundancy Check,CRC)机制,对时间戳字段进行修复,进而恢复出正确的上下文,以正确解压缩后续接收到的数据包,避免丢包。其具体解释说明可以参见下述实施例的说明。
其中,本申请实施例的数据包的解压缩方法的执行主体可以是通信装置或通信装置的内部芯片,该通信装置可以是如上所述的压缩端,例如,对于上行传输,该通信装置可以是上述任一种终端设备,对于下行传输,该通信装置可以是上述任一种接入网设备。
图4为本申请实施例的一种数据包的解压缩方法的流程图,如图4所示,本实施例的方法可以包括:
步骤101、在当前数据包的包头解压缩失败时,确定该包头解压缩失败是否发生在通话期和静默期转换过程。
其中,压缩端向解压缩端发送数据包,解压缩端对数据包进行解压缩,解压缩端在当前数据包的包头解压缩失败时,确定该包头解压缩失败是否发生在通话期和静默期转换过程。本发明实施例中压缩端接收到的数据包均指压缩包,解压缩端需要对接收到的数据包进行解压缩。解压缩包括对数据包的包头所包括的各个字段信息进行解码,把解码后的各个字段信息进行拼接,再进行CRC校验。其中,如果校验不正确,则数据包的包头解压缩失败,如果校验正确,则数据包的包头解压缩正确。导致解压缩失败的原因可以是包头中部分字段信息解码错误,例如,时间戳(Timestamp)解码错误,可以通过本发明实施例的下述步骤对该时间戳(Timestamp)进行恢复。
本文所涉及的通话期和静默期转换过程包括通话期转换为静默期过程(可以参见图3 所示),和/或,静默期转换为通话期过程(可以参见图3所示)。其具体可以是通话期转换为静默期过程中,或者,静默期转换为通话期过程中。通话期转换为静默期过程中可以包括前一个包是通话期数据包,后一个包是静默期数据包;静默期转换为通话期过程中可以包括前一个包是静默期数据包,后一个包是通话期数据包,可以理解为如图3所示的任一圆圈处的数据包的包头解压缩失败。
可选的,通话期转换为静默期过程可以包括通话期转换为静默期之后,但在静默期连续丢包。静默期转换为通话期过程可以包括静默期转换为通话期之后,但在通话期连续丢包。可以理解为如图3所示的任一圆圈处之后的数据包的包头解压缩失败。此时,该当前数据包之前的多个数据包均丢失,其中包括在通话期和静默期转换过程中的数据包。例如,当前数据包是静默期的第4个数据包,此时静默期的第1个数据包、第2个数据包和第3个数据包均丢失;或者,例如,当前数据包是第2个通话期的第3个数据包,此时第2个通话期的第1个数据包和第2个数据丢失。
本文所涉及的数据包可以是通话期数据包或者静默期数据包。
该当前数据包括可以是通话期数据包,也可以是静默期数据包。
步骤102、当包头解压缩失败发生在通话期和静默期转换过程,根据报文序号差值、数据包的时间戳步长和最近一个正确解压缩的数据包的时间戳获取多个待校验时间戳。
其中,该报文序号差值为当前数据包解码后的报文序号(SN)与最近一个正确解压缩的数据包的报文序号(SN)的差值。该数据包的时间戳步长可以是最近一个正确解压缩的数据包的时间戳步长,或者可以是当前数据包的包类型对应的时间戳步长,其可以是静默期步长或通话期步长,其具体解释说明可以参见下述实施例的说明。
以当前数据包为图3所示的第一个圆圈里的第一个静默期数据包,最近一个正确解压缩的数据包是第一个通话期的最后一个数据包,为例进行举例说明,当前数据包的包头解压缩失败,且该包头解压缩失败发生在通话期和静默期转换过程中,两个数据包的报文序号差值(delta_sn)等于1,即中间没有丢包,通话期和静默期转换过程中,时间戳(Timestamp) 的增长量发生跳变,该当前数据包携带时间戳的压缩字段,在压缩端和解压缩端对时间戳的编码处理方式不一致时,会出现如上所述的当前数据包的包头解压缩失败,本实施例根据报文序号差值(delta_sn)、数据包的时间戳步长((Ts_stride)=160)和最近一个正确解压缩的数据包的时间戳以确定该解压缩失败的当前数据包携带的时间戳,例如,将最近一个正确解压缩的数据包的时间戳表示为前Timestamp,那么当前数据包的时间戳的取值范围为:{前Timestamp+160,前Timestamp+160*2,前Timestamp+160*3,前Timestamp+160*4,前Timestamp+160*5,前Timestamp+160*6,前Timestamp+160*7,前Timestamp+160*8},该取值范围内的多个数即为本实施例所描述的多个待校验时间戳。解压缩端可以通过对该时间戳的取值范围内的各个待校验时间戳进行CRC校验,以找到 CRC校验正确的时间戳,即为该解压缩失败的当前数据包所携带的时间戳。
delta_sn表示报文序号差值,该delta_sn可以是大于或等于1的任意整数,Ts_stride 表示时间戳步长,本实施例的当前数据包的时间戳的取值范围为:{前 Timestamp+Ts_stride*delta_sn,前Timestamp+Ts_stride*(delta_sn+1),……,前Timestamp+ Ts_stride*delta_sn*8}。
需要说明的是,如果该多个待校验时间戳中存在解压缩失败所使用的时间戳,则可以对该当前数据包的时间戳的取值范围内,除该解压缩失败所使用的时间戳之外的时间戳进行CRC校验。
步骤103、使用所述多个待校验时间戳中,使得当前数据包的包头CRC正确的时间戳更新上下文,所述上下文用于对后续接收到的数据包进行解压缩。
对多个待校验时间戳分别进行CRC校验,以确定是否存在CRC正确的时间戳,若存在,则使用该CRC正确的时间戳更新上下文(contex),该上下文用于解压缩端对后续接收到的数据包进行解压缩。
需要说明的是,本文所描述的对待校验时间戳进行CRC校验指:将待校验时间戳和包头其他字段信息一起进行CRC,如果CRC正确,则将该校验正确的时间戳和包头其他字段信息进行拼接便可以得到该当前数据包的原始包头。其中,该包头其他字段信息可以包括版本号、源地址、目标地址等信息。
在一些实施例中,会存在多个校验正确的时间戳,则使用多个更新后的上下文分别对后续接收到的数据包进行解压缩,将连续k次解压缩成功的更新后的上下文,作为用于对后续接收到的数据包进行解压缩的上下文,其中,多个更新后的上下文为根据多个校验正确的时间戳分别确定的,k取大于1的整数,例如,k=3。
例如,当前数据包携带的CRC校验位为3bit,3bit误校验的概率为1/8,这种情况下,可能出现多个校验正确的时间戳,则可以通过上述方式,分别用每个校验正确的时间戳计算得到更新后的上下文,用各个更新后的上下文对后续接收到的数据包进行解压缩,以选取可以连续多次成功解压缩的更新后的上下文,作为用于对后续接收到的数据包进行解压缩的上下文。
本实施例,在当前数据包的包头解压缩失败时,通过确定包头解压缩失败是否发生在通话期和静默期转换过程,当包头解压缩失败发生在通话期和静默期转换过程,根据报文序号差值、数据包的时间戳步长和最近一个正确解压缩的数据包的时间戳获取多个待校验时间戳,使用多个待校验时间戳中CRC正确的时间戳更新上下文,从而减少因关键数据包丢失或者压缩编码方式的兼容性问题导致的解压缩失败,进而避免由于解压缩失败所引起的连续丢包或反复丢包,保证语音质量。
并且可以避免终端设备在小区边缘或者由于空口质量波动,发生关键数据包的丢失而使得终端设备退出RoHC引起语音中断丢包,以及退出RoHC后,上行调度的每个语音包从原本45字节突然膨胀为100字节,出现的语音分片和抖动丢包,充分发挥RoHC提升远点覆盖能力。
在一些实施例中,解压缩端还可以根据CRC正确的时间戳确定时间戳步长系数(Ts_scaled),使用CRC正确的时间戳和时间戳步长系数(Ts_scaled)对上下文中的相应元素进行更新。时间戳步长系数(Ts_scaled)的计算方式可以是对CRC正确的时间戳除以时间戳步长所得到的商取整。还可以根据CRC正确的时间戳确定时间戳偏置 (Ts_offset),其计算方式可以是CRC正确的时间戳对时间戳步长取余。
在一些实施例中,多个待校验时间戳包括:{前Timestamp+Ts_stride*delta_sn,前 Timestamp+Ts_stride*(delta_sn+1),……,前Timestamp+Ts_stride*delta_sn*8}。
其中,前Timestamp表示所述最近一个正确解压缩的数据包的时间戳,Ts_stride表示所述数据包的时间戳步长,delta_sn表示所述报文序号差值。
上下文可以包括如上所述的静态域信息和/或动态域信息,即可以包括如上所述的时间戳步长系数(Ts_scaled)、时间戳步长(Ts_stride)等。
图5为本申请实施例的另一种数据包的解压缩方法的流程图,如图5所示,本实施例的方法可以包括:
步骤201、压缩端向解压缩端发送数据包。
解压缩端接收压缩端发送的数据包。解压缩端对接收到的数据包的包头进行解压缩以获取完整的包头信息。
步骤202、解压缩端对当前数据包进行解压缩,在当前数据包的包头解压缩失败时,解压缩端确定该包头解压缩失败是否发生在通话期和静默期转换过程。若是,则执行步骤 203。
其中,解压缩端确定该包头解压缩失败是否发生在通话期和静默期转换过程的具体实现方式可以参见图6所示实施例的解释说明,此处不再赘述。
步骤203、当所述包头解压缩失败发生在通话期和静默期转换过程,从步长集合中选取一个作为所述数据包的时间戳步长。
该步长集合可以包括通话期步长、静默期步长和零中一项或者多项。
该通话期步长可以为20ms*采样率,该静默期步长可以为160ms*采样率,以8k采样率为例,该通话期步长可以为20ms*8000/s,该静默期步长可以是160ms*8000/s。
对于步长集合的获取方式进行解释说明,一种可实现方式,该步长集合是预设的数值集合,其中包括通话期步长、静默期步长和零。另一种可实现方式,该步长集合的初始状态仅包括0,在解压缩端开始对接收到的数据包进行解压缩后,解压缩端根据解压缩正确的相邻数据包的时间戳得到通话期步长和/或静默期步长,使用计算得到的通话期步长和/或静默期步长对步长集合进行更新,以在数据包接收过程中对步长集合进行更新。
其中,根据解压缩正确的相邻数据包的时间戳差值通话期步长和/或静默期步长的一种可实现方式,在所述当前数据包之前出现过解压缩正确的通话期数据包时,将相邻通话期数据包的时间戳之差作为所述通话期步长,所述静默期步长等于通话期步长*8;在所述当前数据包之前出现过解压缩正确的静默期数据包时,将相邻静默期数据包的时间戳之差作为所述静默期步长,所述通话期步长等于静默期步长/8。
一种可实现方式,解压缩端可以在该步长集合中随机选取一个步长作为数据包的时间戳步长,以执行下述步骤204至步骤205,确定该数据包的时间戳步长对应的多个待校验时间戳中是否存在CRC正确的时间戳,若不存在,则通过步骤206对数据包的时间戳步长进行更新,并使用更新后的数据包的时间戳步长,执行下述步骤204至步骤205,直至获取校验正确的时间戳。
另一种可实现方式,解压缩端可以先选取当前的时间戳步长作为数据包的时间戳步长,例如,该当前的时间戳步长为静默期步长,以执行下述步骤204至步骤205,确定该数据包的时间戳步长对应的多个待校验时间戳中是否存在CRC正确的时间戳,若不存在,则通过步骤206对数据包的时间戳步长进行更新,并使用更新后的时间戳步长,以执行下述步骤204至步骤205,直至获取校验正确的时间戳。
在通过CRC校验寻找校验正确的时间戳过程中,可以先使用静默期步长或通话期步长,在该静默期步长对应的待校验时间戳和通话期步长对应的待校验时间戳中均不存在CRC正确的时间戳时,将0作为数据包的时间戳步长,即使用最近一个正确解压缩的数据包的时间戳进行CRC校验,确定是否可以CRC校验正确。即0可以是在步长集合中其他取值对应的待校验时间戳中均不存在CRC正确的时间戳时,使用0作为数据包的时间戳步长。
步骤204、根据所述报文序号差值、所述数据包的时间戳步长和最近一个正确解压缩的数据包的时间戳获取多个待校验时间戳。
其中获取多个待校验时间戳的具体实现方式可以参见图4所示实施例的步骤102的解释说明,此处不再赘述。
步骤205、确定所述多个待校验时间戳中是否存在校验正确的时间戳,若不存在,则执行步骤206。若存在,则执行步骤207。
步骤206、从所述步长集合中选取一个不同的步长取值作为所述数据包的时间戳步长。
并执行步骤204至步骤205,直至获取的多个待校验时间戳中存在校验正确的时间戳。
步骤207、使用所述多个待校验时间戳中,使得当前数据包的包头CRC正确的时间戳更新上下文,所述上下文用于对后续接收到的数据包进行解压缩。
其中,步骤207的解释说明可以参见图4所示实施例的步骤103的解释说明,此处不再赘述。
本实施例,在当前数据包的包头解压缩失败时,通过确定包头解压缩失败是否发生在通话期和静默期转换过程,当包头解压缩失败发生在通话期和静默期转换过程,根据报文序号差值、多个不同的时间戳步长和最近一个正确解压缩的数据包的时间戳获取多个待校验时间戳,使用多个待校验时间戳中,使得当前数据包的包头CRC正确的时间戳更新上下文,从而减少因关键数据包丢失或者压缩编码方式的兼容性问题导致的解压缩失败,进而避免由于解压缩失败所引起的连续丢包或反复丢包,保证语音质量。
并且可以避免终端设备在小区边缘或者由于空口质量波动,发生关键数据包的丢失而使得终端设备退出RoHC引起语音中断丢包,以及退出RoHC后,上行调度的每个语音包从原本45字节突然膨胀为100字节,出现的语音分片和抖动丢包,充分发挥RoHC提升远点覆盖能力。
在上述任一实施例中,确定所述包头解压缩失败是否发生在通话期和静默期转换过程的一种可实现方式可以为:根据当前数据包的包类型与所述最近一个正确解压缩的数据包的包类型,确定所述包头解压缩失败是否发生在通话期和静默期转换过程。
图6为本申请实施例的另一种数据包的解压缩方法的流程图,本实施例在上述任一实施例的基础上对确定包头解压缩失败是否发生在通话期和静默期转换过程进行具体解释说明,如图6所示,本实施例的方法可以包括:
步骤301、获取当前数据包和最近一个正确解压缩的数据包的包类型。
一种可实现方式,根据所述当前数据包的净荷长度确定所述当前数据包的包类型,根据所述最近一个正确解压缩的数据包的净荷长度确定所述最近一个正确解压缩的数据包的包类型。静默期数据包的净荷长度<8字节,通话期数据包的净荷长度为14~180字节。
步骤302、判断当前数据包和最近一个正确解压缩的数据包的包类型是否相同,若否,则执行步骤303,若是,则执行步骤304。
步骤303、当前数据包的包类型与所述最近一个正确解压缩的数据包的包类型不同时,确定所述包头解压缩失败发生在通话期和静默期转换过程。
如果当前数据包的包类型与所述最近一个正确解压缩的数据包的包类型不同,即可以确定包头解压缩失败发生在通话期和静默期转换过程,例如,如图3所示的第一个圆圈处后,或,第一个圆圈处之后且第二个圆圈处之前。
步骤304、当前数据包的包类型与所述最近一个正确解压缩的数据包的包类型相同时,根据语音数据包和静默数据包的丢包个数,确定所述包头解压缩失败是否发生在通话期和静默期转换过程。
如果当前数据包的包类型与所述最近一个正确解压缩的数据包的包类型相同,则可以确定丢包数较多,例如,最近一个正确解压缩的数据包为如图3所示的第一个圆圈处的通话期数据包,当前数据包为第二个圆圈处的通话期数据包。其具体可以通过如下方式确定包头解压缩失败是否发生在通话期和静默期转换过程。
其中,可以根据所述报文序号差值和接收时间间隔确定所述语音数据包的丢包个数和所述静默数据包的丢包个数,该接收时间间隔为所述当前数据包与所述最近一个正确解压缩的数据包之间的时间间隔。在满足以下任一条件时,确定所述包头解压缩失败发生在通话期和静默期转换过程:所述语音数据包的丢包个数和所述静默数据包的丢包个数均不等于0;或者,所述语音数据包的丢包个数等于0,所述静默数据包的丢包个数不等于0,且所述当前数据包为语音数据包;或者,所述语音数据包的丢包个数不等于0,所述静默数据包的丢包个数等于0,且所述当前数据包为静默数据包。
delta_sn表示报文序号差值,具体可以计算当前数据包的SN和该最近一个正确解压缩的数据包的SN之差,假设通话期数据包的丢包个数为x个,静默期数据包的丢包个数为y个,结合delta_sn、接收时间间隔之差delta_ts,便可以确定出x和y的值。如果x和 y都不等于0,则表示发生了通话和静默期转换。如果x=0,y≠0,当前包为语音包,则表示发生了通话和静默期转换。如果x≠0,y=0,当前包为静默包,则表示发生了通话和静默期转换。
计算x和y的一种可实现方式,解二元一次方程:
x+y=delta_sn-1
20x+160y=delta_ts-T
其中,如果当前数据包为通话期数据包,T=20;如果当前数据包为静默期数据包,T=160。如果delta_ts-T<0,那么x=0,y=delta_sn-1。
本实施例,通过根据当前数据包的包类型与所述最近一个正确解压缩的数据包的包类型,确定所述包头解压缩失败是否发生在通话期和静默期转换过程,进而当包头解压缩失败发生在通话期和静默期转换过程,根据报文序号差值、多个不同的时间戳步长和最近一个正确解压缩的数据包的时间戳获取多个待校验时间戳,使用多个待校验时间戳中CRC 正确的时间戳更新上下文,从而减少因关键数据包丢失或者压缩编码方式的兼容性问题导致的解压缩失败,进而避免由于解压缩失败所引起的连续丢包或反复丢包,保证语音质量。
并且可以避免终端设备在小区边缘或者由于空口质量波动,发生关键数据包的丢失而使得终端设备退出RoHC引起语音中断丢包,以及退出RoHC后,上行调度的每个语音包从原本45字节突然膨胀为100字节,出现的语音分片和抖动丢包,充分发挥RoHC提升远点覆盖能力。
在上述任一实施例的基础上,当通过本发明上述实施例未能找到使得包头CRC校验正确的时间戳时,解压缩端可以从FC状态回退至SC状态,并向压缩端发送不确认(Nack),使得压缩端向解压缩端发送UOR-2*包或IR-Dyn包,若解压缩端仍不能正确解压缩数据包,解压缩端可以从SC状态回退至NC状态,并向压缩端发送静态不确认(Static Nack),使得压缩端向解压缩端发送IR包。
上述本申请提供的实施例中,分别从解压缩端本身、以及从解压缩端与压缩端之间交互的角度对本申请实施例提供的数据包的解压缩方法的各方案进行了介绍。可以理解的是,解压缩端、以及压缩端为了实现上述功能,其包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到,结合本文中所公开的实施例描述的各示例的单元及算法步骤,本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本申请的范围。
例如,当上述解压缩端通过软件模块来实现相应的功能。作为解压缩端的数据包的解压缩装置可包括接收模块701和处理模块702,如图7A所示。
在一个实施例中,该数据包的解压缩装置可用于执行上述图3中解压缩端的操作。例如:
所述处理模块702,用于在通过所述接收模块701接收到的当前数据包的包头解压缩失败时,确定所述包头解压缩失败是否发生在通话期和静默期转换过程;
所述处理模块702,还用于当所述包头解压缩失败发生在通话期和静默期转换过程,根据报文序号差值、数据包的时间戳步长和最近一个正确解压缩的数据包的时间戳获取多个待校验时间戳,所述报文序号差值为所述当前数据包解码后的报文序号与所述最近一个正确解压缩的数据包的报文序号的差值;
所述处理模块702,还用于使用所述多个待校验时间戳中,使得所述当前数据包的包头循环冗余校验CRC正确的时间戳更新上下文,所述上下文用于对后续接收到的数据包进行解压缩。
由此,本申请实施例中数据包的解压缩装置能够减少因关键数据包丢失或者压缩编码方式的兼容性问题导致的解压缩失败,进而避免由于解压缩失败所引起的连续丢包或反复丢包,保证语音质量。
可选的,所述处理模块702用于:使用所述多个待校验时间戳分别和所述当前数据包的包头的其他字段信息进行CRC,确定是否存在校验正确的时间戳;当存在校验正确的时间戳时,根据所述校验正确的时间戳确定时间戳步长系数,使用所述校验正确的时间戳和所述时间戳步长系数更新所述上下文。
可选的,所述处理模块702还用于当存在多个校验正确的时间戳时,使用多个更新后的上下文分别对后续接收到的数据包进行解压缩,将连续k次解压缩成功的更新后的上下文,作为用于对后续接收到的数据包进行解压缩的上下文;其中,所述多个更新后的上下文为根据多个校验正确的时间戳分别确定的,k取大于1的整数。
可选的,所述多个待校验时间戳包括:{前Timestamp+Ts_stride*delta_sn,前Timestamp+Ts_stride*(delta_sn+1),……,前Timestamp+Ts_stride*delta_sn*8};其中,前Timestamp表示所述最近一个正确解压缩的数据包的时间戳,Ts_stride表示所述数据包的时间戳步长,delta_sn表示所述报文序号差值。
可选的,所述处理模块702还用于:从步长集合中选取一个作为所述数据包的时间戳步长,所述步长集合包括通话期步长、静默期步长和零中一项或者多项;执行根据所述报文序号差值、所述数据包的时间戳步长和最近一个正确解压缩的数据包的时间戳获取多个待校验时间戳步骤;在确定所述多个待校验时间戳中不存在校验正确的时间戳时,则从所述步长集合中选择一个不同的步长取值作为所述数据包的时间戳步长,直至获取的多个待校验时间戳中存在校验正确的时间戳。
可选的,所述处理模块702还用于:在对接收到的数据包进行解压缩过程中,根据解压缩正确的相邻数据包的时间戳差值确定所述步长集合。
可选的,所述处理模块702用于:在所述当前数据包之前出现过解压缩正确的通话期数据包时,将相邻通话期数据包的时间戳之差作为所述通话期步长,所述静默期步长等于通话期步长*8;在所述当前数据包之前出现过解压缩正确的静默期数据包时,将相邻静默期数据包的时间戳之差作为所述静默期步长,所述通话期步长等于静默期步长/8。
可选的,所述处理模块702用于:根据当前数据包的包类型与所述最近一个正确解压缩的数据包的包类型,确定所述包头解压缩失败是否发生在通话期和静默期转换过程。
可选的,所述处理模块702用于:当前数据包的包类型与所述最近一个正确解压缩的数据包的包类型不同时,确定所述包头解压缩失败发生在通话期和静默期转换过程;当前数据包的包类型与所述最近一个正确解压缩的数据包的包类型相同时,根据语音数据包和静默数据包的丢包个数,确定所述包头解压缩失败是否发生在通话期和静默期转换过程。
可选的,所述处理模块702用于:根据所述报文序号差值和接收时间间隔确定所述语音数据包的丢包个数和所述静默数据包的丢包个数,所述接收时间间隔为所述当前数据包与所述最近一个正确解压缩的数据包之间的时间间隔;在满足以下任一条件时,确定所述包头解压缩失败发生在通话期和静默期转换过程:所述语音数据包的丢包个数和所述静默数据包的丢包个数均不等于0;或者,所述语音数据包的丢包个数等于0,所述静默数据包的丢包个数不等于0,且所述当前数据包为语音数据包;或者,所述语音数据包的丢包个数不等于0,所述静默数据包的丢包个数等于0,且所述当前数据包为静默数据包。
可选的,所述处理模块702还用于:根据所述当前数据包的净荷长度确定所述当前数据包的包类型;根据所述最近一个正确解压缩的数据包的净荷长度确定所述最近一个正确解压缩的数据包的包类型。
可选的,该数据包的解压缩装置还可以包括发送模块703,用于向压缩端反馈如上述实施例中所述的不确认(Nack)或确认(Ack)。
此外,基于该数据包的解压缩装置中的接收模块701、处理模块702和发送模块703还可实现上述方法中解压缩端的其他操作或功能,此处不再赘述。
图7B示出了上述实施例中所涉及的数据包的解压缩装置的另一种可能的结构示意图。该数据包的解压缩装置也可以称之为通信装置,该通信装置可以包括处理单元705,该处理器可以执行上述任一实施例的技术方案。可选的,该通信装置还可以包括存储单元706,该存储单元706与处理单元705耦合,该存储单元706用于存储指令,该指令用于处理单元705读取,并执行如上述任一实施例所述的数据包的解压缩方法。
例如,在一个实施例中,处理单元705被配置为解压缩端的其他操作或功能。该通信装置还可以包括收发单元704用于实现数据包的解压缩装置与压缩端之间的通信。
可选的,处理单元705可以包括一个或者多个处理器;可选的,存储单元706可以包括一个或者多个存储器。
可选的,该通信装置可以是终端、接入网设备、终端中的芯片或者接入网设备中的芯片,当该通信装置是终端或者接入网设备中的芯片时,收发单元704可以包括输入或者输出接口、管脚或者电路等;当该通信装置是终端或者接入网设备时,收发单元704可以包括天线和收发机。
用于执行本申请上述数据包的解压缩方法的控制器/处理器可以是中央处理器(CPU),通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC),现场可编程门阵列(FPGA) 或者其他可编程逻辑器件、晶体管逻辑器件,硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框,模块和电路。所述处理器也可以是实现计算功能的组合,例如包含一个或多个微处理器组合,DSP和微处理器的组合等等。
结合本申请公开内容所描述的方法或者算法的步骤可以硬件的方式来实现,也可以是由处理器执行软件指令的方式来实现。软件指令可以由相应的软件模块组成,软件模块可以被存放于RAM存储器、闪存、ROM存储器、EPROM存储器、EEPROM存储器、寄存器、硬盘、移动硬盘、CD-ROM或者本领域熟知的任何其它形式的存储介质中。一种示例性的存储介质耦合至处理器,从而使处理器能够从该存储介质读取信息,且可向该存储介质写入信息。当然,存储介质也可以是处理器的组成部分。处理器和存储介质可以位于ASIC中。另外,该ASIC可以位于视频监控网络的任意节点中。当然,处理器和存储介质也可以作为分立组件存在于视频监控网络的任意节点中。
在上述实施例中,可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时,可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时,全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中,或者从一个计算机可读存储介质向另一个计算机可读存储介质传输,例如,所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质,(例如,软盘、硬盘、磁带)、光介质(例如,DVD)、或者半导体介质(例如固态硬盘Solid State Disk(SSD))等。
以上所述的具体实施方式,对本申请的目的、技术方案和有益效果进行了进一步详细说明,所应理解的是,以上所述仅为本申请的具体实施方式而已,并不用于限定本申请的保护范围,凡在本申请的技术方案的基础之上,所做的任何修改、等同替换、改进等,均应包括在本申请的保护范围之内。

Claims (12)

1.一种数据包的解压缩方法,其特征在于,包括:
在当前数据包的包头解压缩失败时,确定所述包头解压缩失败是否发生在通话期和静默期转换过程;
当所述包头解压缩失败发生在通话期和静默期转换过程,根据报文序号差值、数据包的时间戳步长和最近一个正确解压缩的数据包的时间戳获取多个待校验时间戳,所述报文序号差值为所述当前数据包解码后的报文序号与所述最近一个正确解压缩的数据包的报文序号的差值;
使用所述多个待校验时间戳中,使得所述当前数据包的包头循环冗余校验CRC正确的时间戳更新上下文,所述上下文用于对后续接收到的数据包进行解压缩。
2.根据权利要求1所述的方法,其特征在于,所述使用所述多个待校验时间戳中,使得所述当前数据包的包头循环冗余校验CRC正确的时间戳更新上下文,包括:
使用所述多个待校验时间戳分别和所述当前数据包的包头的其他字段信息进行CRC,确定是否存在校验正确的时间戳;
当存在校验正确的时间戳时,根据所述校验正确的时间戳确定时间戳步长系数,使用所述校验正确的时间戳和所述时间戳步长系数更新所述上下文。
3.根据权利要求2所述的方法,其特征在于,当存在多个校验正确的时间戳时,所述方法还包括:
使用多个更新后的上下文分别对后续接收到的数据包进行解压缩,将连续k次解压缩成功的更新后的上下文,作为用于对后续接收到的数据包进行解压缩的上下文;
其中,所述多个更新后的上下文为根据多个校验正确的时间戳分别确定的,k取大于1的整数。
4.根据权利要求1至3任一项所述的方法,其特征在于,所述多个待校验时间戳包括:{前Timestamp+Ts_stride*delta_sn,前Timestamp+Ts_stride*(delta_sn+1),……,前Timestamp+Ts_stride*delta_sn*8};
其中,前Timestamp表示所述最近一个正确解压缩的数据包的时间戳,Ts_stride表示所述数据包的时间戳步长,delta_sn表示所述报文序号差值。
5.根据权利要求1至4任一项所述的方法,其特征在于,所述方法还包括:
从步长集合中选取一个作为所述数据包的时间戳步长,所述步长集合包括通话期步长、静默期步长和零中一项或者多项;
执行根据所述报文序号差值、所述数据包的时间戳步长和最近一个正确解压缩的数据包的时间戳获取多个待校验时间戳步骤;
在确定所述多个待校验时间戳中不存在校验正确的时间戳时,则从所述步长集合中选择一个不同的步长取值作为所述数据包的时间戳步长,直至获取的多个待校验时间戳中存在校验正确的时间戳。
6.根据权利要求5所述的方法,其特征在于,所述方法还包括:
在对接收到的数据包进行解压缩过程中,根据解压缩正确的相邻数据包的时间戳差值确定所述步长集合。
7.根据权利要求6所述的方法,其特征在于,所述根据解压缩正确的相邻数据包的时间戳差值确定所述步长集合,包括:
在所述当前数据包之前出现过解压缩正确的通话期数据包时,将相邻通话期数据包的时间戳之差作为所述通话期步长,所述静默期步长等于通话期步长*8;
在所述当前数据包之前出现过解压缩正确的静默期数据包时,将相邻静默期数据包的时间戳之差作为所述静默期步长,所述通话期步长等于静默期步长/8。
8.根据权利要求1至7任一项所述的方法,其特征在于,所述确定所述包头解压缩失败是否发生在通话期和静默期转换过程,包括:
根据当前数据包的包类型与所述最近一个正确解压缩的数据包的包类型,确定所述包头解压缩失败是否发生在通话期和静默期转换过程。
9.根据权利要求8所述的方法,其特征在于,所述根据当前数据包的包类型与所述最近一个正确解压缩的数据包的包类型,确定所述包头解压缩失败是否发生在通话期和静默期转换过程,包括:
当前数据包的包类型与所述最近一个正确解压缩的数据包的包类型不同时,确定所述包头解压缩失败发生在通话期和静默期转换过程;
当前数据包的包类型与所述最近一个正确解压缩的数据包的包类型相同时,根据语音数据包和静默数据包的丢包个数,确定所述包头解压缩失败是否发生在通话期和静默期转换过程。
10.根据权利要求9所述的方法,其特征在于,所述根据语音数据包和静默数据包的丢包个数,确定所述包头解压缩失败是否发生在通话期和静默期转换过程,包括:
根据所述报文序号差值和接收时间间隔确定所述语音数据包的丢包个数和所述静默数据包的丢包个数,所述接收时间间隔为所述当前数据包与所述最近一个正确解压缩的数据包之间的时间间隔;
在满足以下任一条件时,确定所述包头解压缩失败发生在通话期和静默期转换过程:
所述语音数据包的丢包个数和所述静默数据包的丢包个数均不等于0;或者,
所述语音数据包的丢包个数等于0,所述静默数据包的丢包个数不等于0,且所述当前数据包为语音数据包;或者,
所述语音数据包的丢包个数不等于0,所述静默数据包的丢包个数等于0,且所述当前数据包为静默数据包。
11.根据权利要求8至10任一项所述的方法,其特征在于,所述方法还包括:
根据所述当前数据包的净荷长度确定所述当前数据包的包类型;
根据所述最近一个正确解压缩的数据包的净荷长度确定所述最近一个正确解压缩的数据包的包类型。
12.一种通信装置,其特征在于,包括:至少一个处理器,所述处理器与存储器耦合,所述处理器用于读取存储器中的指令,并根据所述指令执行如权利要求1至11任一项所述的数据包的解压缩方法。
CN201811535588.5A 2018-12-14 2018-12-14 数据包的解压缩方法和装置 Active CN111328104B (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN201811535588.5A CN111328104B (zh) 2018-12-14 2018-12-14 数据包的解压缩方法和装置
PCT/CN2019/124546 WO2020119718A1 (zh) 2018-12-14 2019-12-11 数据包的解压缩方法和装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201811535588.5A CN111328104B (zh) 2018-12-14 2018-12-14 数据包的解压缩方法和装置

Publications (2)

Publication Number Publication Date
CN111328104A true CN111328104A (zh) 2020-06-23
CN111328104B CN111328104B (zh) 2022-03-04

Family

ID=71075851

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201811535588.5A Active CN111328104B (zh) 2018-12-14 2018-12-14 数据包的解压缩方法和装置

Country Status (2)

Country Link
CN (1) CN111328104B (zh)
WO (1) WO2020119718A1 (zh)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111954248A (zh) * 2020-07-03 2020-11-17 京信通信系统(中国)有限公司 一种音频数据报文处理方法、装置、设备及存储介质
CN112333047A (zh) * 2020-11-16 2021-02-05 展讯通信(上海)有限公司 数据传输方法、装置及设备
CN114499750A (zh) * 2021-11-30 2022-05-13 华为技术有限公司 一种数据包的处理方法、通信装置及通信系统
CN114679300A (zh) * 2022-02-28 2022-06-28 福思(杭州)智能科技有限公司 一种数据校验方法、装置、电子设备及存储介质

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170091014A1 (en) * 2015-09-24 2017-03-30 Qualcomm Incorporated Timestamp repair mechanism in case of decompression failure
CN108737349A (zh) * 2017-04-24 2018-11-02 大唐移动通信设备有限公司 一种语音数据包的处理方法及装置

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102571540B (zh) * 2010-12-20 2015-12-16 华为技术有限公司 一种解压的方法及装置
CN105791228B (zh) * 2014-12-22 2019-12-03 中兴通讯股份有限公司 一种压缩时间戳的方法和装置
CN108574684B (zh) * 2017-03-14 2020-08-28 大唐移动通信设备有限公司 一种解压缩的方法和装置

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170091014A1 (en) * 2015-09-24 2017-03-30 Qualcomm Incorporated Timestamp repair mechanism in case of decompression failure
CN108141790A (zh) * 2015-09-24 2018-06-08 高通股份有限公司 在解压缩失败的情况下的时间戳修复机制
CN108737349A (zh) * 2017-04-24 2018-11-02 大唐移动通信设备有限公司 一种语音数据包的处理方法及装置

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111954248A (zh) * 2020-07-03 2020-11-17 京信通信系统(中国)有限公司 一种音频数据报文处理方法、装置、设备及存储介质
CN112333047A (zh) * 2020-11-16 2021-02-05 展讯通信(上海)有限公司 数据传输方法、装置及设备
CN112333047B (zh) * 2020-11-16 2022-04-26 展讯通信(上海)有限公司 数据传输方法、装置及设备
CN114499750A (zh) * 2021-11-30 2022-05-13 华为技术有限公司 一种数据包的处理方法、通信装置及通信系统
CN114679300A (zh) * 2022-02-28 2022-06-28 福思(杭州)智能科技有限公司 一种数据校验方法、装置、电子设备及存储介质
CN114679300B (zh) * 2022-02-28 2023-10-13 福思(杭州)智能科技有限公司 一种数据校验方法、装置、电子设备及存储介质

Also Published As

Publication number Publication date
CN111328104B (zh) 2022-03-04
WO2020119718A1 (zh) 2020-06-18

Similar Documents

Publication Publication Date Title
CN111328104B (zh) 数据包的解压缩方法和装置
US10194349B2 (en) Header compression optimization method during and after handovers in cellular communication network
US7155173B2 (en) Method and system for providing a context for message compression
US7907609B2 (en) Method and apparatus for enhancing RoHC performance when encountering silence suppression
JP2011024215A (ja) 無線チャンネルでヘッダを復号する方法とシステム
CN110958646B (zh) 通信方法与设备
EP3584977B1 (en) Method and device for information transmission
CN109088702B (zh) 通信方法、网络设备和终端
KR20170004598A (ko) 헤더 압축을 이용한 패킷 통신 방법 및 장치
CN111556506B (zh) 异常链路的处理方法及设备
CN112469083A (zh) 数据传输方法、装置、设备和存储介质
US9350592B2 (en) Decompressing method and apparatus
CN102318282B (zh) 一种压缩数据包的传输方法及装置
CN111355564B (zh) 处理压缩错误的方法和装置
CN115022922A (zh) 用于lte系统中的呼叫处理方法和装置
CN114389758A (zh) 一种数据传输方法和装置
CN113784389B (zh) 一种数据处理的方法和装置
CN114365470B (zh) 用于传输以太网压缩包的方法和设备
CN108574684A (zh) 一种解压缩的方法和装置
CN115334588A (zh) 一种数据传输方法及装置
CN109672707B (zh) 数据传输方法及装置、计算机存储介质
CN108737349B (zh) 一种语音数据包的处理方法及装置
CN112787980B (zh) 反馈的方法和设备
CN110958647A (zh) 一种数据传输方法及装置
CN113678501B (zh) 一种以太网数据包头压缩方法、处理方法及其装置

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant