CN118215076A - 一种rohc解压失败控制方法、***及通讯终端 - Google Patents

Abstract

本发明公开了一种ROHC解压失败控制方法、***及通讯终端，其方法应用于通讯终端，包括步骤：在所述通讯终端处于No‑context状态下丢弃Non‑IR包时，发送Static‑NACK信息至基站；接收所述基站重新下发的Initial and Refresh数据包。本发明可以针对ROHC连续解压失败情况下快速恢复解压流程，提高通讯效率。

Description

一种ROHC解压失败控制方法、***及通讯终端

技术领域

本发明涉及通信技术领域，特别涉及一种ROHC解压失败控制方法、***及通讯终端。

背景技术

5G/LTE终端在通话或数据传输过程中使用鲁棒头压缩(RObust HeaderCompression，ROHC)方案时，受到移动过程中或者网络环境突然急剧突变差的影响，会使正常网络环境变为弱网环境，进而导致ROHC context未建立使ROHC长时间解压失败。

因此目前需要一种ROHC解压失败控制方法，使ROHC解压失败情况下快速恢复解压流程，提高通讯效率。

发明内容

为解决ROHC长时间解压失败的技术问题，本发明提供一种ROHC解压失败控制方法、***及通讯终端，具体的技术方案如下：

本发明提供一种ROHC解压失败控制方法，应用于通讯终端，包括步骤：

在所述通讯终端处于No-context状态下丢弃Non-IR包时，发送Static-NACK信息至基站；

接收所述基站重新下发的Initial and Refresh数据包。

本发明提供的ROHC解压失败控制方法通过控制通讯终端在NC状态下收到non-IR包除了丢弃之外，还会向基站反馈static-NACK以告知基站重发IR包建立、刷新ROHCcontext，避免后续所有数据包都解压失败出现ROHC长时间解压失败的情况，使ROHC解压失败情况下快速恢复解压流程，提高通讯效率。

在一些实施方式中，所述的在所述通讯终端处于No-context状态下丢弃Non-IR包之后，还包括步骤：

根据RTT时延限制所述通讯终端的ROHC NACK发送频率。

本发明提供的ROHC解压失败控制方法考虑网络时延波动场景以及网络RTT时间，控制解压端解压失败时不需要每次都回复NACK数据，通过参考RTT限制NACK频率，起到节约上行资源的效果。

在一些实施方式中，所述的根据RTT时延限制所述通讯终端的ROHC NACK发送频率，具体包括：

每个所述RTT时延内首次ROHC解压失败时，所述通讯终端回复ROHC NACK；

每经过连续预设次数ROHC解压失败时所述通讯终端回复ROHC NACK。

在一些实施方式中，所述的接收所述基站重新下发的Initial and Refresh数据包之后，还包括：

根据连续解压失败时长、连续解压失败数量、预设时长门限值和预设数量门限值，控制所述通讯终端执行对应的RRC re-establish控制方案。

本发明提供的ROHC解压失败控制方法针对连续解压失败场景，设置根据连续解压失败时间和个数与门限值进行判定，进而主动触发RRC重建流程的方案，使基站可以快速重新下发IR包执行重建任务，快速刷新ROHC context，提高解压进程恢复效率。

在一些实施方式中，所述的控制所述通讯终端执行对应的RRC re-establish控制方案，具体包括：

在所述连续解压失败时长大于所述预设时长门限值，且所述连续解压失败数量大于所述预设数量门限值时，控制所述通讯终端执行RRC re-establish并重置所述连续解压失败时长和所述连续解压失败数量；

在所述连续解压失败时长不大于所述预设时长门限值，或所述连续解压失败数量不大于所述预设数量门限值时，控制所述通讯终端不执行RRC re-establish。

在一些实施方式中，根据本发明的另一方面，本发明还提供一种ROHC解压失败控制方法，应用于通信基站，包括步骤：

向通讯终端发送Initial and Refresh数据包；

在所述通讯终端处于No-context状态下丢弃Non-IR包时，接收所述通讯终端发送的Static-NACK信息；

向所述通讯终端重新下发所述Initial and Refresh数据包。

在一些实施方式中，根据本发明的另一方面，本发明还提供一种ROHC解压失败控制***，包括基站和至少一个通讯终端，

所述基站在ROHC解压失败后向所述通讯终端发送Initial and Refresh数据包；

所述通讯终端判断自身是否处于No-context状态，并在处于No-context状态下丢弃Non-IR包时，发送Static-NACK信息至所述基站；

所述基站根据所述Static-NACK信息重新向所述通讯终端下发所述Initial andRefresh数据包。

在一些实施方式中，根据本发明的另一方面，本发明还提供一种通讯终端，所述通讯终端包括处理器和存储器，所述处理器根据所述存储器中存储有控制指令以实现上述的一种ROHC解压失败控制方法所执行的操作。

在一些实施方式中，根据本发明的另一方面，本发明还提供一种存储介质，所述存储介质中存储有至少一条指令，所述指令由处理器加载并执行以实现上述的ROHC解压失败控制方法所执行的操作。

本发明提供的ROHC解压失败控制方法、***及通讯终端，至少包括以下一项技术效果：

(1)通过控制通讯终端在NC状态下收到non-IR包除了丢弃之外，还会向基站反馈static-NACK以告知基站重发IR包建立、刷新ROHC context，避免后续所有数据包都解压失败出现ROHC长时间解压失败的情况，使ROHC解压失败情况下快速恢复解压流程，提高通讯效率；

(2)考虑网络时延波动场景以及网络RTT时间，控制解压端解压失败时不需要每次都回复NACK数据，通过参考RTT限制NACK频率，起到节约上行资源的效果；

(3)针对连续解压失败场景，设置根据连续解压失败时间和个数与门限值进行判定，进而主动触发RRC重建流程的方案，使基站可以快速重新下发IR包执行重建任务，快速刷新ROHC context，提高解压进程恢复效率。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简要介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本发明一种ROHC解压失败控制方法应用于通讯终端的流程图；

图2为本发明一种ROHC解压失败控制方法中限制通讯终端的ROHC NACK发送频率的流程图；

图3为本发明一种ROHC解压失败控制方法中限制通讯终端的ROHC NACK发送频率的另一个的流程图；

图4为本发明一种ROHC解压失败控制方法中执行RRC re-establish控制方案的流程图；

图5为本发明一种ROHC解压失败控制方法中执行RRC re-establish控制方案的另一个流程图；

图6为本发明一种ROHC解压失败控制方法应用于基站的流程图。

具体实施方式

以下描述中，为了说明而不是为了限定，提出了诸如特定***结构、技术之类的具体细节，以便透彻理解本申请实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其他实施例中也可以实现本申请。在其他情况中，省略对众所周知的***、装置、电路以及方法的详细说明，以免不必要的细节妨碍本申请的描述。

应当理解，当在本说明书和所附权利要求书中使用时，术语“包括”指示所述描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其他特征、整体、步骤、操作、元素、组件和/或集合的存在或添加。

为使图面简洁，各图中只示意性地表示出了与本发明相关的部分，它们并不代表其作为产品的实际结构。另外，以使图面简洁便于理解，在有些图中具有相同结构或功能的部件，仅示意性地绘出了其中的一个，或仅标出了其中的一个。在本文中，“一个”不仅表示“仅此一个”，也可以表示“多于一个”的情形。

还应当进一步理解，在本申请说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。

另外，在本申请的描述中，术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对照附图说明本发明的具体实施方式。显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图，并获得其他的实施方式。

在5G/LTE通讯终端在通话或数据传输过程中，TCP/UDP/IP/RTP Header的静态部分数据通常是不会改变的，为了减少数据的冗余传输节约资源和提高传输速率，会使用ROHC压缩方案，其中ROHC协议定义了3种工作模式和3种压缩状态和解压状态，以便ROHC在不同无线链路状态下对IP分组信头进行压缩和解压，保持压缩和解压数据流同步进一步保证ROHC协议健壮性。

其中压缩状态包括IR(initiation and refresh state)初始化和重置状态、FO(first order)一级压缩状态和SO(second order)二级压缩状态，IR初始化和重置状态用于初始、更新文景中静态域和动态域信息，在IR初始化和重置状态下，压缩方连续发送全部IP信头信息和流关联标识符PID和CID；FO一级压缩状态下压缩方仅仅需要传递完整的动态信头域信息；SO二级压缩状态下压缩方根据动态域变化规律，仅传递动态域的压缩值，此时压缩方发送最高压缩率的ROHC压缩分组。

解压状态包括NC(no context)无文景状态、SC(static context)静态文景状态和FC(full context)全文景状态，其中NC状态主要是在数据流刚开始传递时解压方所处的状态，解压方没有IP信义静态和动态域信息，需要压缩方在IR状态发送包含完整信头的分组；SC静态文景状态指解压方获得了足够的静态域信息，与压缩方的FO状态相对应，希望接收到包含完整动态信头的ROHC压缩分组；FC全文景状态指解压方获得了足够的静态域信息和动态域的变化规律信息时所处的状态，与压缩方SO状态相对应，能够接收压缩方在SO状态所发送的ROHC压缩分组。解压方刚开始工作在NC状态，一旦成功解压一个ROHC分组就进入FC状态；在FC状态下，当最近k1个连续分组解压失败时，解压方转移到SC状态；在SC状态下，当成功解压一个分组时，解压方转移到FC状态；当最近k2个连续分组解压失败的时候，解压方转移到NC状态。

压缩状态由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状态，只是当最近收到的n1个连续的分组中有k1个解压失败的时候才会由FC状态转移到SC状态，在SC状态下当成功的解压一个含有足够更新信息的分组的时候，就会转移到FC，当最近收到的n2个连续的分组中有k2个解压失败的时候才转移到NC状态。

协议规定初始过程中基站需要发送进行ROHC处理的初始和刷新(Initial andrefresh,IR)包，用于建立ROHC上下文。在NC(no-context)状态下，收到所有的non-IR包时会被丢弃。信号质量下降，或者干扰造成的信号质量抖动，可能伴随压缩包内容错误、解压过程中携带关键信息的压缩包丢失导致ROHC context被破坏问题(例如RTP包中更新TS_STRIDE、TS_OFFSET等，会导致之后的包都没法解压)导致后续所有non-IR包解压失败。解压失败后UE会发送NACK给基站。协议还规定，RRC重建流程(radio resource control re-establish)会执行PDCP(Pakcet Data Convergence Protocol)重建并reset ROHCcontext，基站和UE回到U(Unidirectional mode)模式下的NC状态，从IR包开始发送。

但是在移动过程中或者网络环境突然急剧突变差的场景下，由于弱网环境导致的数据包内容错误、解压过程中关键信息包(例如RTP包中更新TS_STRIDE、TS_OFFSET等)丢包导致ROHC(RObust Header Compression)context破坏、UE解压失败回复NACK但是网络没收到、基站不响应或UE实现是不回复NACK给网络、或者IR(Initial and refresh)包丢失导致ROHC context未建立而后续所有non-IR包无法解压，进而带来的连续的长时间解压失败问题。

基于上述问题，本发明的一个实施例，如图1所示，本实施例提供一种ROHC解压失败控制方法，应用于通讯终端，包括步骤：

S100在通讯终端处于No-context状态下丢弃Non-IR包时，发送Static-NACK信息至基站。

S200接收基站重新下发的Initial and Refresh数据包。

本实施例提供的ROHC解压失败控制方法通过控制通讯终端在NC状态下收到non-IR包除了丢弃之外，还会向基站反馈static-NACK表示解压器的静态上下文无效或没有建立，以告知基站重发IR包建立、刷新ROHC context，避免后续所有数据包都解压失败出现ROHC长时间解压失败的情况，使ROHC解压失败情况下快速恢复解压流程，提高通讯效率。

在一个实施例中，步骤S100在通讯终端处于No-context状态下丢弃Non-IR包之后，还包括步骤：

S110根据RTT时延(round-trip time)限制通讯终端的ROHC NACK发送频率。

本实施例提供的ROHC解压失败控制方法考虑网络时延波动场景以及网络RTT时间，控制解压端解压失败时不需要每次都回复NACK数据，通过参考RTT限制NACK频率，起到节约上行资源的效果。

在一个实施例中，步骤S110根据RTT时延限制所述通讯终端的ROHC NACK发送频率具体包括：

S111每个RTT时延内首次ROHC解压失败时，通讯终端回复ROHC NACK。

S112每经过连续预设次数ROHC解压失败时通讯终端回复ROHC NACK。

其中，在判断解压失败过程中对预设次数的设置参考RTT时延和网络连续下发数据包的频率，通常来讲为保证回复ROHC NACK的及时性，应将预设次数设计在RTT时延内，举例来说可以将预设次数设计为(RTT时延/网络连续下发数据包频率)/2，这个方案中在每个RTT时延内首次ROHC解压失败时发送ROHC NACK，在连续半个周期均ROHC解压失败时，也发送ROHC NACK。

在一个实施例中，步骤S200接收基站重新下发的Initial and Refresh数据包之后，还包括：

S300根据连续解压失败时长、连续解压失败数量、预设时长门限值和预设数量门限值，控制通讯终端执行对应的RRC re-establish控制方案。

本实施例提供的ROHC解压失败控制方法针对连续解压失败场景，设置根据连续解压失败时间和个数与门限值进行判定，进而主动触发RRC重建流程的方案，使基站可以快速重新下发IR包执行重建任务，快速刷新ROHC context，提高解压进程恢复效率。

在一个实施例中，步骤S300根据连续解压失败时长、连续解压失败数量、预设时长门限值和预设数量门限值，控制通讯终端执行对应的RRC re-establish控制方案中控制通讯终端执行对应的RRC re-establish控制方案，具体包括：

S310在连续解压失败时长大于预设时长门限值，且连续解压失败数量大于预设数量门限值时，控制通讯终端执行RRC re-establish并重置连续解压失败时长和连续解压失败数量。

S320在连续解压失败时长不大于预设时长门限值，或连续解压失败数量不大于预设数量门限值时，控制通讯终端不执行RRC re-establish。

在一个实施例中，根据本发明的另一方面，本发明还提供一种ROHC解压失败控制方法，应用于通信基站，包括步骤：

S400向通讯终端发送Initial and Refresh数据包。

S500在通讯终端处于No-context状态下丢弃Non-IR包时，接收通讯终端发送的Static-NACK信息。

S600向通讯终端重新下发Initial and Refresh数据包。

在一个实施例中，根据本发明的另一方面，本发明还提供一种ROHC解压失败控制***，包括基站和至少一个通讯终端，基站在ROHC解压失败后向通讯终端发送Initial andRefresh数据包；通讯终端判断自身是否处于No-context状态，并在处于No-context状态下丢弃Non-IR包时，发送Static-NACK信息至基站；基站根据Static-NACK信息重新向通讯终端下发Initial and Refresh数据包。

在一个实施例中，根据本发明的另一方面，本发明还提供一种通讯终端，通讯终端包括处理器和存储器，处理器根据存储器中存储有控制指令以实现上述的一种ROHC解压失败控制方法所执行的操作。

在一个实施例中，根据本发明的另一方面，本发明还提供一种存储介质，存储介质中存储有至少一条指令，指令由处理器加载并执行以实现上述的ROHC解压失败控制方法所执行的操作。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详细描述或记载的部分，可以参见其他实施例的相关描述。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

在本申请所提供的实施例中，应该理解到，所揭露的一种ROHC解压失败控制方法、***及通讯终端，可以通过其他的方式实现。例如，以上所描述的一种ROHC解压失败控制方法、***及通讯终端实施例仅仅是示意性的，例如，所述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如，多个单元或模块可以结合或者可以集成到另一个***，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的通讯连接可以是通过一些接口，装置或单元的通讯连接或集成电路，可以是电性、机械或其他的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可能集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

应当说明的是，以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (7)

1.一种ROHC解压失败控制方法，其特征在于，应用于通讯终端，包括步骤：

在所述通讯终端处于No-context状态下丢弃Non-IR包时，发送Static-NACK信息至基站；

接收所述基站重新下发的Initial and Refresh数据包；

所述的在所述通讯终端处于No-context状态下丢弃Non-IR包之后，还包括步骤：

根据RTT时延限制所述通讯终端的ROHC NACK发送频率；

所述的根据RTT时延限制所述通讯终端的ROHC NACK发送频率，具体包括：

每个所述RTT时延内首次ROHC解压失败时，所述通讯终端回复ROHC NACK；

每经过连续预设次数ROHC解压失败时所述通讯终端回复ROHC NACK，所述预设次数根据所述RTT时延和网络数据包下发频率计算。

2.根据权利要求1所述的一种ROHC解压失败控制方法，其特征在于，所述的接收所述基站重新下发的Initial and Refresh数据包之后，还包括：

根据连续解压失败时长、连续解压失败数量、预设时长门限值和预设数量门限值，控制所述通讯终端执行对应的RRC re-establish控制方案。

3.根据权利要求2所述的一种ROHC解压失败控制方法，其特征在于，所述的控制所述通讯终端执行对应的RRC re-establish控制方案，具体包括：

在所述连续解压失败时长大于所述预设时长门限值，且所述连续解压失败数量大于所述预设数量门限值时，控制所述通讯终端执行RRC re-establish并重置所述连续解压失败时长和所述连续解压失败数量；

在所述连续解压失败时长不大于所述预设时长门限值，或所述连续解压失败数量不大于所述预设数量门限值时，控制所述通讯终端不执行RRC re-establish。

4.一种ROHC解压失败控制方法，其特征在于，应用于通信基站，包括步骤：

向通讯终端发送Initial and Refresh数据包；

在所述通讯终端处于No-context状态下丢弃Non-IR包时，接收所述通讯终端发送的Static-NACK信息；

向所述通讯终端重新下发所述Initial and Refresh数据包；

所述通讯终端的ROHC NACK发送频率由RTT时延限制，每个所述RTT时延内首次ROHC解压失败时，所述通讯终端回复ROHC NACK；每经过连续预设次数ROHC解压失败时所述通讯终端回复ROHC NACK，所述预设次数根据所述RTT时延和网络数据包下发频率计算。

5.一种ROHC解压失败控制***，包括基站和至少一个通讯终端，其特征在于，

所述基站在ROHC解压失败后向所述通讯终端发送Initial and Refresh数据包；

所述通讯终端判断自身是否处于No-context状态，并在处于No-context状态下丢弃Non-IR包时，发送Static-NACK信息至所述基站；

所述基站根据所述Static-NACK信息重新向所述通讯终端下发所述Initial andRefresh数据包；

所述通讯终端发送Static-NACK信息至所述基站，具体包括：

每个RTT时延内首次ROHC解压失败时，所述通讯终端回复ROHC NACK；

每经过连续预设次数ROHC解压失败时所述通讯终端回复ROHC NACK，所述预设次数根据所述RTT时延和网络数据包下发频率计算。

6.一种通讯终端，其特征在于，所述通讯终端包括处理器和存储器，所述处理器根据所述存储器中存储有控制指令以实现上述权利要求1～3中任一项所述的一种ROHC解压失败控制方法所执行的操作。

7.一种存储介质，其特征在于，所述存储介质中存储有至少一条指令，所述指令由处理器加载并执行以实现如权利要求1～3中任意一项所述的ROHC解压失败控制方法所执行的操作。