CN1689301A - 首部压缩方法 - Google Patents

首部压缩方法 Download PDF

Info

Publication number
CN1689301A
CN1689301A CNA038239906A CN03823990A CN1689301A CN 1689301 A CN1689301 A CN 1689301A CN A038239906 A CNA038239906 A CN A038239906A CN 03823990 A CN03823990 A CN 03823990A CN 1689301 A CN1689301 A CN 1689301A
Authority
CN
China
Prior art keywords
decompression machine
mode
refusal
header compressed
pattern
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
CNA038239906A
Other languages
English (en)
Other versions
CN100574313C (zh
Inventor
G·佩莱蒂尔
L·E·荣松
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.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
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 Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Publication of CN1689301A publication Critical patent/CN1689301A/zh
Application granted granted Critical
Publication of CN100574313C publication Critical patent/CN100574313C/zh
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
    • H03M7/30—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/04—Protocols for data compression, e.g. ROHC

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Communication Control (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Auxiliary Devices For And Details Of Packaging Control (AREA)
  • Prostheses (AREA)

Abstract

本发明涉及基于分组的通信系统中的首部压缩。提出一种允许压缩器拒绝非期望模式变更的请求的机制。该压缩器向解压器指示模式变更请求被忽略，解压器随后在理解压缩器以有效原因拒绝它的情况下可以中止启动的模式转换。压缩器最好通过链路监视判断拒绝是否成功，如果拒绝成功，压缩器保持其当前模式。最佳实施例通过重新定义了模式值的模式变更拒绝消息执行显式拒绝信令。本发明的拒绝信令使压缩器可以禁止向某个特定模式转换，并允许仅支持所有模式的子集的实现方案。

Description

首部压缩方法
技术领域
本发明一般涉及基于分组的通信系统，更具体地来说，涉及用于首部压缩的方法和装置。
背景技术
因为因特网的巨大成功，因此在所有类型的链路上利用因特网协议(IP)成为一件挑战性的工作。但是，对于窄带链路如蜂窝电话链路，这尤其是个难题，因为较之数据(有效载荷)，IP协议分组首部一般非常大。例如，当通过用于基于IP的语音(VoIP)的协议来传输常规语音数据时，分组首部常常代表了分组70％的部分，这导致链路的利用效率非常低。
首部压缩指在点到点链路上用于基于每一跳将首部中携带的信息所需的带宽减至最小的技术。存在多种首部压缩协议，包括RFC1144[1]、RFC 2507[2]和RFC 2508[3]。首部压缩原理利用了如下事实：一些首部字段在流中不发生改变或者以较小或可预测的值改变。首部压缩方案利用了这些特征，只在开始发送静态信息，而变化的字段则以其绝对值发送或作为分组之间的差值发送。完全随机的信息则必须完全不作任何压缩来传送。
为了使基于无线的VoIP(VoIPoW)成为电路交换语音的经济上可行的替代方案，首部压缩是一个重要的组成部分，为此，已经开发出稳健的首部压缩(ROHC)的解决方案。ROHC(如RFC 3095[4]中的定义)是一种可为其定义各种协议压缩类(profile)的可扩展框架。对于VoIP来说，应用数据在IP/用户数据报协议(UDP)/实时传输协议(RTP)流内以端到端的方式传输。IP/UDP/RTP的首部压缩由ROHC类0x0001(ROHC RTP)定义，并且适用于VoIP服务及其他。已经设计ROHC RTP首部压缩方案是为了在任何类型的链路层上高效压缩首部。大多数功能由ROHC RTP方案本身来处理，除了协商以外，仅组帧和检错需要由链路层实现。
ROHC具有三种不同操作模式，这些模式针对特定的上下文，在首部压缩操作的不同状态期间控制要执行的操作和逻辑以及要使用的分组类型。允许的分组类型和格式可能因模式不同而不同。在可能发生向另一种模式转换之前在任何ROHC压缩开始时采用单向模式(U模式)。双向优化模式(O模式)旨在将压缩效率最大化，它与低反馈信道使用率相关。双向可靠模式(R模式)旨在实现对抗分组丢失和上下文损坏传播(context damage propagation)的最大稳健性。
在U模式下时，分组只从压缩器传送到解压器，因此该模式适用于其上不需要或不可利用从解压器到压缩器的返回路径的链路，此模式中采用周期性刷新。O模式与U模式类似，所不同的是，采用反馈信道将错误恢复请求和(可选的)对重要上下文更新的确认从解压器传送到压缩器。因为它们的特性非常相似，U模式和O模式常常统称为U/O模式。R模式与其他两种模式显著不同，主要是大量使用反馈信道和更严格的逻辑来执行上下文更新。R模式还采用少量仅在此模式下才被理解且有用的不同分组类型。
每种操作模式就压缩效率、稳健性和处理复杂性而言各有不同的特性。ROHC未指定如何以及何时应使用哪种模式(但是ROHC压缩必须以U模式开始)，因此模式转换的逻辑成为一个实现问题。模式转换只可以由解压器来启动，根据稳健的首部压缩的当前规范(RFC3095)，每种ROHC实现方案必须支持所有的操作模式。
现有技术的首部压缩方案的上述特征和需求存在多个缺点。
首部压缩方案供应商可能要针对某种特定操作模式(例如为了使存储需求或必需的处理能力最小)来优化压缩器实现方案。但是，无法保证特定的实现方案实际中会在其优选模式下使用。相反，它可能被迫执行次优操作，而导致压缩效率以及链路性能降低。
另一个问题是，ROHC实现方案需要许多功能来支持所有压缩模式。必须执行大量实现、验证和测试操作，这就意味着较长的实现时间和更高的实现成本。在一个特定环境中，并非所有的模式都一定是有用的。再者，为了将程序占用空间(program footprint)和/或构建可互操作的ROHC算法实现方案所需的时间减至最少，有时希望只支持与特定实现方案的部署策略一致的模式。
因此，常规电信系统的首部压缩难以满足要求，迫切需要一种改进的首部压缩方法，具体来说，需要一种提供压缩模式灵活性的方法。
概述
本发明总的目标是要实现更有效的首部压缩。具体目标是提供考虑压缩模式的灵活首部压缩机制。另一个目标是实现易于实现的首部压缩方案。
这些目标根据所附权利要求来实现。
简而言之，本发明通过一种允许压缩器拒绝解压器的非期望模式变更请求的机制来实现更高效的首部压缩。根据所提出的方法，压缩器最好通过隐式或显式的信令向解压器指示变更请求正被拒绝/忽略。响应该指示，解压器随后在理解压器有拒绝模式转换的有效原因的情况下可以中止所启动的转换。如果解压器认识到所指示的拒绝，则通过拒绝确认操作来响应，这意味着拒绝成功。拒绝确认操作可以包括例如降低模式变更请求的重传频率或停止重传模式变更请求，或发出明确的拒绝确认消息。压缩器最好通过监视并解释解压器信令行为来判断拒绝是否成功，如果拒绝成功，则压缩器保持其当前模式。
本发明的优选实施例通过从压缩器向解压器发送含有重新定义模式值的模式变更拒绝消息来实现显式的拒绝信令，以及通过有意忽略这些请求一段预定时间来实现隐式的拒绝信令。还可以有组合使用显式和隐式拒绝信令的实施例。
因此，通过根据本发明的消息传递方法，首部压缩器可以安全地忽略来自解压器的请求或以明确的方式发送信号指示拒绝模式变更请求。这使压缩器可以在考虑多种不同因素(包括对解压器而言未知的一些因素)的情况下禁止向特定模式转换。这还使压缩器实现方案可以仅支持用于首部压缩的所有操作模式中的一个子集。具体来说，可以提供符合ROHC规范的有利的仅U/O模式实现方案。
根据本发明的其他方面，提供了一种通信系统和首部压缩器单元。
根据本发明的首部压缩方法具有如下优点：
-提高了首部压缩效率
-高效率地利用可用带宽
-减少实现足迹(implementaton footprint)
-降低存储需求
-需要较少功能来实现、验证和测试
-改善了实现时间和成本
-实现更容易部署的ROHC产品
-提供特定于各种模式(例如U/O模式)的实现方案
附图简介
参考如下说明及附图，可以更好地理解本发明及其其他目的和优点，附图中：
图1以示意性框图说明可以采用本发明的示范通信网络；
图2显示可以采用本发明的首部压缩机制；
图3是根据本发明第一示范实施例的首部压缩方法的流程图；以及
图4是根据本发明示范第二实施例的首部压缩方法的流程图。
详细说明
图1以示意性框图说明可以采用本发明的示范全球移动通信系统/通用分组无线业务(GSM/GPRS)通信网络。如图所示，无线电网络包括多个移动台/终端10(如移动电话、膝上型计算机和无线中继器)，它们通过无线链路11与基站子系统(BSS)通信。BSS通常包括大量基站收发器(BTS)12和基站控制器(BSC)13。每个BTS服务于其各自覆盖区内的移动终端，若干BTS由一个BSC控制，该BSC又提供对核心网络的接入，所述核心网络包括移动交换中心(MSC)14和网关移动交换中心(GMSC)15。GSM业务通过MSC14路由，MSC 14与负责移动终端10当前位置的来访位置寄存器(VLR)相关联。与外部网络的通信由GMSC 15处理。现转到分组交换子网，它包括服务GPRS支持节点(SGSN)16和网关GPRS支持节点(GGSN)17。GGSN充当与外部分组数据网络的接口，而SGSN负责与其服务区内终端的分组传输。
实践中，大多数网络包括以比图1的基本实例复杂得多的方式安排的许多网络节点。再者，图1是可以采用本发明的一类通信系统的实例。本发明还适用于其他分组数据通信网络，包括例如cdma2000无线分组数据通信网络以及采用无线IP的其他无线电技术(如WLAN)的系统。
首部压缩通常用于减少所示通信网络中一条或多条链路的必需带宽，从而提高其传输效率和速度。具体来说，无线通信常常有这种减少带宽的需要，但是首部压缩还可以用于其他链路，包括静态/有线链路。一般来说，适用首部压缩的链路每一端都有压缩器和解压器。在无线系统中，它们通常设在移动台10作为链路11的终端，也可以设在例如收发器的每一侧，将接收器用作中继器。在链路11的网络侧，压缩器和解压器可以安排在一个或多个如下节点中：基于GPRS的分组数据系统的SGSN 16或GGSN 17、cdma2000分组数据系统的分组数据服务节点(PDSN)(未显示)，或者安排在基站12中或无线电接入网的另一个节点中。
在图2中，显示了首部压缩的一般原理。其中显示了首部压缩器单元20和首部解压器单元22。这两个单元20和22通过具有前向信道(从压缩器到解压器)以及可选的反馈信道的链路来进行通信。除实际的数据/有效载荷之外，输入到首部压缩器单元的每个IP分组还包含携带源地址和目的地址、错误校验字段和端口及协议字段等的首部部分(图2中条文字段表示的部分)。首部部分常常构成分组中比数据还大的部分。因此，转发完整的分组会需要很大的带宽，因此在经带宽有限链路传输之前要通过在首部压缩器单元20中消除冗余首部信息来压缩分组。首部解压器单元22将分组重构成基本与原始输入分组相同的解压分组。
首部压缩基本基于如下认识：同属一个流的分组的许多首部字段是恒定不变的或很少变化，因此只需偶尔传送完整的首部字段。一些首部压缩器协议中提供了了有关首部压缩的细节和规则。在本发明公开文献中，出于示范说明的目的，关注点主要在ROHC，然而即使本发明非常适用于ROHC，具体为ROHC RTP、UDP和ESP类(RFC3095[4])、ROHC UDP-Lite类[5]、ROHC纯IP类[6]、LLA类(RFC 3242[7])以及LLA类[8]的R模式扩展，但本发明绝不局限于此。其他当前的或将来的首部压缩方案，ROHC的或非ROHC的，均属于本发明的范围。
如背景技术部分所述，稳健的首部压缩规范(RFC3095)说明了“所有ROHC实现方案必须实现和支持所有三种操作模式。模式转换要按如下方式执行。
从U模式到O模式
如果反馈信道可用，则解压器可以通过发送携带向O模式进行模式转换的请求的反馈分组来决定启动从U模式转换为O模式。允许解压器已经处于O模式，因为用于U模式和O模式的分组类型是相同的。一接收到请求，压缩器便会转换到O模式。
从O模式到R模式
解压器可以通过向压缩器发送请求来启动从O模式转换到R模式。一旦启动转换，压缩器便不允许使用任何采用通用标识符但U/O模式与R模式之间解释不同的分组类型，通常采用最高效的分组格式。在解压器从压缩器接收到有关模式变更的确认之前，解压器继续发送对应于从压缩器接收到的每个分组的模式请求。压缩器使用转换期间允许的特定分组类型的“模式”字段，并且将其设为所请求的模式，以确认变更。2位的模式字段的语义按如下定义：
压缩模式  0＝保留
          1＝单向模式(U-模式)
          2＝双向优化模式(O-模式)
          3＝双向可靠模式(R-模式)
从U模式到R模式
规程与从O模式到R模式相同
从R模式到O模式
规程与从O模式到R模式相同
转换回U模式也始终是可能的。
根据ROHC(RFC 3095)，压缩过程必须起始于U模式。U-模式和O-模式实际上彼此非常相似，因此容易同时支持这两种模式。因为R模式与其他两种模式有显著差异，所以在许多情况下出于方便不考虑R模式而采用仅U/O模式实现方案。
显然灵活的ROHC模式实现方案(如仅U/O模式实现方案)可以较少的功能即实现优化的首部压缩器。有时许多压缩器最好不转换到另一种模式，例如R模式，即使在解压器请求时。最好还可以避免对某种特定模式(例如R模式)的实现支持，而仍安全地符合ROHC规范。
但是，ROHC不允许创建仅U/O模式实现方案等。根据文献[4]，仅由解压器来指示模式转换。这对压缩器实现方案施加了要始终支持所有定义的模式的要求。因此压缩器可能被迫执行次优操作，仅仅是因为不同来源的压缩器实现方案可能支持与对压缩器优化的模式不同的模式。
本发明旨在提供一种解决方案，以解除ROHC算法施加的如下限制：要求压缩器实现方案始终且绝对支持所有操作模式，即使可能只须或希望支持其中一个子集。
首先会想到的就是简单地忽略来自解压器的模式变更请求。但是，对于例如从U或O模式到R模式的模式转换，目前的ROHC规范规定“当D_TRANS是I时，解压器对应于每个接收到的分组发送携带有CRC选项的NACK或ACK。换言之，当解压器发送了模式请求时，该解压器会对应于每个接收到的分组不断重发该请求，直到它从压缩器接收到模式变更确认为止。再者，还规定了“只要解压器未接收到模式转换参数设为R的UOR-2、IR-DYN或IR分组，则它必须处于最优模式”。这意味着在从压缩器接收到模式变更确认之前，解压器不允许变更模式(例如变更到R模式)。其结果是，解压器可安全地保持原有模式，直到压缩器实际上执行模式转换并确认请求为止。
因为ROHC解压器必须处于U/O模式，直到从压缩器接收到模式变更确认为止，所以忽略从解压器接收到的到R模式的模式变更请求的压缩器实现方案不会阻止解压器继续执行稳健解压。然而，这会因为解压器重发请求而导致反馈信道上通信量增加，导致带宽利用并非最佳。根据具体的解压器实现方案，此行为可能是永久性的、暂时性的或过渡性的。因此，简单地忽略来自解压器的至R模式的模式变更请求具有如下缺点：反馈信道上的通信量以较不受控的方式在一段不定时间内增加。
作为替代，本发明提供了一种消息传递规程，其中，压缩器可以向解压器指示正在拒绝模式变更请求。响应此指示的拒绝，解压器可以在理解压器以有效原因拒绝模式转换的情况下中止所启动的转换。所述原因可以是例如：压缩器更了解链路状况；就当前操作模式而言压缩器处于最优状态和/或所请求的模式不可用。
根据所建议的方法，收到对非期望模式变更的请求时，压缩器通常通过显式或隐式信令向解压器指示拒绝该模式变更请求。如果解压器认识到所指示的拒绝，则通过确认该拒绝，例如通过改变的信令行为和/或显式消息来响应。此拒绝确认操作被解释为压缩器拒绝成功，从而保持当前模式。
因此，本发明允许压缩器以隐式或显式方式拒绝来自解压器的模式变更请求。这使压缩器可以禁止向某种特定模式转换，甚至无需压缩器实现所有的操作模式。
为了说明本发明的原理，下面将参考图3和图4描述本发明的第一和第二实施例。这些示例主要是解决从U或O模式向R模式的转换问题，并基于发起模式转换请求时以上所述的压缩器行为。但是，使用其他模式变更请求(涉及ROHC模式以及其他首部压缩操作模式)的实施例也属于本发明范围。因此，可以根据本发明来处理任何从第一首部压缩模式向第二首部压缩模式的模式转换请求，例如从下列集合中选择的模式之间的转换请求：单向(U)模式、双向优化(O)模式、双向可靠(R)模式和双向(B)模式。
显 式拒绝信令
根据第一方法的显式拒绝信令，压缩器显式地以信号告知解压器它将忽略/拒绝模式变更请求。解压器随后可以利用该信号来中止启动的转换，保持在U/O模式下并停止发送模式变更请求。
优选实施例采用重新定义的若干模式位来显式地以信号告知拒绝模式变更请求。如上所述，模式值在ROHC(RFC3095中被定义为：
压缩模式  0＝保留
          1＝单向模式(U-模式)
          2＝双向优化模式(O-模式)
          3＝双向可靠模式(R-模式)
根据此方法，来自ROHC(RFC3095)的UOR-2、IR-DYN或IR分组的模式值被重新定义为：
压缩模式  0＝模式变更请求被忽略/取消
          1＝单向模式(U-模式)
          2＝双向优化模式(O-模式)
          3＝双向可靠模式(R-模式)
因此0值(以前保留的，即没有特定的含义，值为0的所有位将被忽略)被用于指示首部压缩器单元拒绝/忽略了该模式变更请求。相应地，压缩器向解压器发送含有模式值0的分组，以响应非期望的模式变更请求。如果解压器理解该新模式定义，则它可以采取适当的操作，如中止重传请求。为了让其他实现方式可以理解该信号，可能需要进行一些标准化工作。
要明确的是，本发明还涵盖采用其他机制来显式地向解压器发送信号(带内或带外)以指示忽略模式变更请求的实施例。因此，取代优选的ROHC模式值重新定义，可将其他位/值用于显示信令，包括特殊的分组类型、不同于模式位的另一个位标志、分组格式内的选项、扩展格式内的选项等。
图3是采用显式拒绝信令的根据本发明示范实施例的首部压缩方法的流程图。在步骤S1，首部解压器单元发起模式转换，并通过分组传输链路向首部压缩器发送变更到新模式的请求。例如如果模式转换涉及变更到R模式，则请求的压缩模式被设为MODE＝3(R-模式)。解压器然后保持当前模式，并等待压缩器的确认。对于确认前收到的每个分组，解压器通过反馈信道重发该请求。
压缩器收到模式变更请求，但宁愿保持在当前操作模式。它显式地向解压器发信号表示拒绝模式变更请求，最好通过在分组传输链路上发送模式变更拒绝消息来执行(步骤S2)。在采用ROHC分组模式值的上述重新定义值的优选实施例中，压缩器发送一个或多个UOR-2、IR-DYN或IR分组，并设置MODE＝0(请求被取消)。
现在，规程根据解压器在收到MODE＝0分组或其他显式信号时是否理解模式变更请求被拒绝采取不同的执行路径。如果解压器理解拒绝信号，例如新定义的模式值语义，则在步骤S4停止通过反馈信道发送模式变更请求。模式转换随后中止，解压器继续保持当前操作模式。最好，解压器还向压缩器发送一个消息，指示拒绝已被确认(步骤S5)。此拒绝确认消息可以包括例如返回的ROHC分组，所述返回的ROHC分组的MODE参数被设为0或解压器发起模式变更请求时的当前有效模式值，即压缩器希望保持的(“第一”/“当前”)模式。
压缩器最好通过解释解压器的信令行为来判断拒绝是否成功。一般来说，这涉及监视分组传输链路，以搜索解压器已理解并确认该拒绝的某种指示。该指示可以是上述的拒绝确认消息。或者，拒绝模式变更请求成功的指示可以表现为压缩器停止在反馈信道上收到新模式的模式变更请求，从而可确信该信号已到达解压器。足够的可信度通常要求至少1个链路往返时间(RTT)，通常在1至2个RTT的范围内。为响应拒绝成功，压缩器继续使用当前模式(步骤S6)。
另一方面，如果解压器不理解拒绝信号，例如重新定义的模式值，则会忽略它，并保持当前的操作模式。解压通常会继续，根据文献[4]，解压器仍会等待来自压缩器的确认。在此情况下，虽然高度确信该信号已经到达解压器，但压缩器仍将在反馈信道上接收新模式的模式变更请求。压缩器推断拒绝信令不成功，并在步骤S7询问是否要接受该请求。如果是的话，压缩器变更压缩器模式，并且最好向解压器返回一个确认，例如含新模式值的分组(步骤S8)，然后解压器变更模式，并中止再发送请求(步骤S9)。或者，无论拒绝是否成功都不接受该请求。作为替代，压缩器最好恢复隐式信令行为，下文将参考图4对此予以说明。
步骤S7的判断由通用的实现特定的特征来确定或根据针对每种具体情况的解释来确定。例如，如果实现方案不支持请求的模式，则接受该模式并非一个选择，因此将忽略对此模式的所有请求。但是压缩器还可以根据情况出于诸如压缩器一方目前处理资源不足、更了解链路特性等原因来拒绝转换。
图3所示方法的优点在于，它是压缩器向解压器发信号指示不会接受模式变更请求的最有效的方式，并且能够解释此信号的解压器将采取相应的操作。这种解压器保持当前的模式，并不会因重发模式变更请求而增加反馈信道上的通信量。
另一个优点是，当支持所有模式但优选U/O模式的压缩器与不理解所建议的重新定义值时，根据本发明的本实施例的方法保持可互操作并符合标准。根据ROHC规范，不理解此重新定义值的解压器会简单地忽略此值。压缩器随后可以采用如下的隐式信令或者接受模式变更请求。
隐式拒绝信令
另一个方法是压缩器以隐式方式指示拒绝模式变更请求。在一个优选实施例中，通过故意忽略来自解压器的模式变更请求并保持当前模式来实现隐式信令，但只持续有限的时间。换言之，建议以受控的方式安全地忽略请求，以便向解压器指示拒绝模式变更请求。如果在反馈信道上发送的模式变更请求停止或某个时间段之后变得断断续续，则压缩器可以保持当前模式，例如U/O模式，而没有性能损失。否则，即如果反馈信道上的通信量依旧，则压缩器可以决定执行模式变更并接受模式变更请求。
压缩器将忽略模式变更请求并等待来自解压器的可能反应的时间间隔长度通常约为1-2个RTT。这是因为解压器一般可以预期在发送请求之后(最少)约1个RTT从压缩器接收到“答复”。这也可能花较长的时间，一些链路的RTT还随时间变化。但是，在大多数情况下，隐式拒绝信令的预定时间间隔可以通过1-2个RTT的范围值表示。
图4是采用隐式拒绝的根据本发明的实施例的首部压缩方法的流程图。如上所述，首部解压器单元发起模式转换，并向首部压缩器单元发送模式变更请求(步骤S10)。解压器保持当前模式并等待压缩器的确认。对于每个在确认前收到的分组，解压器通过反馈信道重发该请求。
压缩器收到模式变更请求，但宁愿保持当前操作模式。因此，在此情况中压缩器通过隐式拒绝信令指示拒绝模式变更。由此，最好忽略该请求并保持当前模式，与此同时，启动计时器并监视反馈信道(步骤S11)。计时器设为压缩器可确信解压器能够注意到缺乏对模式变更请求的响应所需要的时间值，例如1-2个RTT的范围内的某个值。还可以采用计时器的替代机制，例如可以采用基于序列号的机制来实现受控的隐式拒绝。
此后，规程根据解压器是否认识到对该模式变更请求的隐式拒绝而取不同的执行路径(步骤S12)。如果解压器确信该请求已到达压缩器并由此确信模式变更应该已经执行，但仍然注意到来自压缩器的响应消极/缺乏，则将其解释为请求被拒绝，并在步骤S13停止在反馈信道上重发模式变更请求。或者，解压器降低发送模式变更请求的频率。于是模式转换被中止，解压器继续保持当前模式。
至于压缩器单元，它再次判断拒绝是否成功。最好，这种对拒绝结果的解释涉及链路监视和对解压器信令行为的解释。如果压缩器在计时器到期之前注意到反馈信道上发送模式变更请求的频率降低或没有模式变更请求发送，则拒绝成功，并且压缩器保持当前模式(步骤S14)。
另一方面，如果解压器不知道请求被拒绝，则压缩器设置的计时器将会到期，而反馈信道上仍然继续重发模式变更请求。压缩器将此行为解释为拒绝不成功，于是规程继续执行步骤S15，询问是否要接受模式变更请求。如果情况如此，则压缩器变更压缩器模式，且一般向解压器返回一个确认，例如含新模式值的分组(步骤S16)，解压器因此改变模式，并中止再发送请求(步骤S17)。否则，压缩器继续忽略该请求，并保持当前模式(步骤S18)。步骤S15的结果基于与图3中步骤S7类似的考虑。步骤S18通常不会是优选的选择，但可以在压缩器尚未实现解压器所请求的模式的情况下有用。
此方法的优点在于具有互操作性且符合标准。两种情况都不需要对标准作任何更改。图4所示的方法还可以在将显式信号用于拒绝模式变更请求，而解压器不理解压器所发送的信号的语义时用作后退(fallback)机制。但是，该方法会导致反馈信道上的通信量增加，虽然这种增加以受控方式在有限时间间隔内进行。
图3和图4所示的实施例各有各的优点，选择最适合的方法涉及权衡彼此的各种因素如互操作性性能。各自的信令方案可以分别使用或组合使用，例如，如果显式信令(图3)无法使拒绝成功，则采用隐式信令(图4)作为附加的后退机制。
概而言之，本发明允许首部压缩器在考虑不同因素(包括解压器未知的因素)后，在认为适当时拒绝来自首部解压器的模式变更请求并继续使用当前模式。本发明还允许仅支持所有首部压缩操作模式中的一个子集的压缩器实现方案。具体来说，通过本发明，可以创建高效的仅U/O模式实现方案，同时仍然完全符合ROHC规范[4]。
本发明消除了模式转换方面对解压器的压缩器依赖。这导致更佳的首部压缩效率，还可以降低存储需求、实现时间和实现成本。特别是通过显式信令方法，实现了对可用带宽的更有效的利用，而不会对接收器或应用行为及操作有不利影响。再者，本发明还允许复杂性较低且流水化的ROCH实现方案，如仅采用U模式和O模式的实现方案。
虽然本发明是参考所示的特定实施例来描述的，但应强调的是，它还涵盖所公开特征的等效特征，以及对于本领域技术人员显而易见的修改和变化。例如尽管已就ROHC(RFC3095[4])举例说明了本发明，但本发明还可适用于其他首部压缩方案，包括不同于所述示例的与其他操作模式相关的方案。本发明范围仅由所附权利要求来限定。
                    参考文献
[1]“针对低速串行链路压缩TCP/IP首部”(Van Jacobson，Compressing TCP/IP Headers for Low-Speed Serial Links.IETF RFC1144，IETF Networking Group，February 1990)；
[2]“IP首部压缩”(Mikael Degermark，Bjorn Nordgren，StephenPink.IP Header Compression。IETF RFC 2507，IETF NetworkingGroup，February 1999)；
[3]“针对低速串行链路压缩IP/UDP/RTP首部”(Steven Casner，Van Jacobson.Compressing IP/UDP/RTP Headers for Low-Speed SerialLinks.IETF RFC 2508，IETF Networking Group，February 1999)；
[4]“稳健的首部压缩(ROHC)：框架和四个类别：RTP、UDP、ESP和不压缩”(Carsten Bormann etc.RObust HeaderCompression(ROHC)：Framework and four profiles：RTP，UDP，ESP anduncompressed.IETF RFC 3095，April 2001)；
[5]“稳健的首部压缩(ROHC)：UDP-Lite的框架”(GhyslainPelletier.RObust Header Compression (ROHC)：Profiles for UDP-Lite，Internet draft，April 2003).
(http：//www.ietf.org/internet-drafts/draft-ietf-rohc-udp-lite-00.txt)
[6]“稳健的首部压缩(ROHC)：IP的压缩框架”(Lars-ErikJonsson，Ghyslain Pelletier.RObust Header Compression(ROHC)：Acompression profile for IP.Internet draft，June 2003).
(http：//www.ietf.org/internet-drafts/draft-ietf-rohc-ip-only-02.txt)
[7]“稳健的首部压缩(ROHC)：IP/UDP/RTP的链路层辅助的ROHC框架”(Lars-Erik Jonsson，Ghyslain Pelletier.RObust HeaderCompression(ROHC)：A Link-Layer Assisted ROHC Profile forIP/UDP/RTP.IETF RFC 3242，Internet draft，April 2002)；
[8]“扩展链路层辅助的ROHC框架中对R模式的0字节支持”(Zhigang Liu，Khiem Le，0-byte Support for R-mode in Extended Link-Layer Assisted ROHC Profile.Internet draft，April 2002)。

Claims (32)

1.一种用于在包括首部压缩器单元(20)和首部解压器单元(22)的通信系统中进行分组消息传递的方法，所述方法包括如下步骤：
从所述首部解压器单元通过分组传输链路(11)向所述首部压缩器传送模式变更请求，所述模式变更请求涉及从第一压缩模式变更到第二压缩模式；其特征在于所述方法还包括如下步骤：
在所述首部解压器单元上向所述首部解压器单元指示拒绝所述模式变更请求；
如果所述首部解压器单元知道所指示的拒绝，则在所述首部解压器单元上执行拒绝确认操作；所述拒绝确认操作表示拒绝成功；以及
所述首部解压器单元上保持所述第一压缩模式以响应拒绝成功。
2.如权利要求1所述的方法，其特征在于：所述指示步骤包括从所述首部压缩器单元(20)以隐式或显式方式发送信号，以指示拒绝所述移动变更请求。
3.如权利要求2所述的方法，其特征在于：所述指示步骤包括从所述首部压缩器单元(20)向所述首部解压器单元(22)发送模式变更拒绝消息。
4.如权利要求3所述的方法，其特征在于：所述模式变更拒绝消息包含重新定义的模式值。
5.如权利要求2所述的方法，其特征在于：所述指示步骤包括在所述首部压缩器单元(20)上忽略所述模式变更请求一段预定时间间隔。
6.如权利要求3或4所述的方法，其特征在于：如果通过所述模式变更拒绝消息未实现成功拒绝，则进一步通过在所述首部压缩器单元(20)上忽略所述模式变更请求一段预定时间间隔来指示拒绝。
7.如权利要求1所述的方法，其特征在于：所述拒绝确认操作包括：响应所指示的拒绝，降低从所述首部解压器单元(22)发送模式变更请求的频率。
8.如权利要求1所述的方法，其特征在于：所述拒绝确认操作包括：响应所指示的拒绝而中止从所述首部解压器单元(22)再发送模式变更请求。
9.如权利要求8所述的方法，其特征在于：所述拒绝确认操作包括：响应所指示的拒绝，从所述首部解压器单元(22)向所述首部压缩器单元(20)发送拒绝确认消息。
10.如前述任一权利要求所述的方法，其特征在于：所述方法还包括如下步骤：在所述首部压缩器单元(20)上通过监视所述分组传输链路(11)来判断所述拒绝是否成功。
11.如前述任一权利要求所述的方法，其特征在于：所述方法还包括如下步骤：如果整个拒绝程序不成功，则在所述首部压缩器单元(20)上变更到所述第二压缩模式。
12.如前述任一权利要求所述的方法，其特征在于：所述首部压缩器单元(20)设为只支持所有可能操作模式中的一个子集。
13.如前述任一权利要求所述的方法，其特征在于：根据稳健的首部压缩(ROHC)方案实现所述首部压缩器单元(20)和所述首部解压器单元(22)中的至少一个。
14.如权利要求13所述的方法，其特征在于：所述第一和第二压缩模式是下列集合中的一种：单向(U)模式、双向优化(O)模式、双向可靠(R)模式和双向(B)模式以及这些模式的组合模式。
15.一种用于分组消息传递的通信系统，包括首部压缩器单元(20)、首部解压器单元(22)以及用于通过分组传输链路(11)从所述首部解压器单元向所述首部压缩器单元传送模式变更请求的装置，其中所述模式变更请求涉及从第一压缩模式变更到第二压缩模式；其特征在于：
用于执行如下操作的装置：在所述首部解压器单元上向所述首部解压器单元指示拒绝所述模式变更请求；
用于执行如下操作的装置：如果解压器知道所指示的拒绝，则在所述首部解压器单元上执行拒绝确认操作，所述拒绝确认操作表示拒绝成功；以及
用于执行如下操作的装置：所述首部解压器单元上保持所述第一压缩模式以响应拒绝成功。
16.如权利要求15所述的通信系统，其特征在于还包括用于执行如下操作的装置：从所述首部压缩器单元(20)以隐式或显式方式发送信号，以指示拒绝所述模式变更请求。
17.如权利要求16所述的通信系统，其特征在于还包括用于执行如下操作的装置：从所述首部压缩器单元(20)向所述首部解压器单元(22)发送模式变更拒绝消息。
18.如权利要求17所述的通信系统，其特征在于：所述模式变更拒绝消息包含重新定义的模式值。
19.如权利要求16所述的通信系统，其特征在于：所述指示装置包括用于执行如下操作的装置：在所述首部压缩器单元(20)上忽略所述模式变更请求一段预定时间间隔。
20.如权利要求15至19中任何一项所述的通信系统，其特征在于还包括用于执行如下操作的装置：响应所指示的拒绝，中止从所述首部解压器单元(22)再发送模式变更请求。
21.如权利要求20所述的通信系统，其特征在于还包括执行如下操作的装置：响应所指示的拒绝，从所述首部解压器单元(22)向所述首部压缩器单元(20)发送拒绝确认消息。
22.如权利要求15至21中任何一项所述的通信系统，其特征在于还包括用于执行如下操作的装置：在所述首部压缩器单元(20)上通过监视所述分组传输链路(11)来判断拒绝是否成功。
23.如权利要求15至22中任何一项所述的通信系统，其特征在于：所述首部压缩器单元(20)设为只支持所有可能操作模式中的一个子集。
24.如权利要求15至23中任何一项所述的通信系统，其特征在于：根据稳健的首部压缩(ROHC)方案实现所述首部压缩器单元(20)和所述首部解压器单元(22)中的至少一个。
25.如权利要求24所述的通信系统，其特征在于：所述第一和第二压缩模式是下列集合中的一种：单向(U)模式、双向优化(O)模式、双向可靠(R)模式和双向(B)模式以及这些模式的组合模式。
26.一种用于分组数据通信的首部压缩器单元(20)，包括：用于通过分组传输链路(11)从首部解压器单元(22)接收模式变更请求的装置，其中所述模式变更请求涉及从第一压缩模式变更到第二压缩模式；其特征在于：
用于执行如下操作的装置：向所述首部解压器单元指示拒绝所述模式变更请求；
用于执行如下操作的装置：解释所述首部解压器单元的信令行为以判断拒绝是否成功；以及
用于执行如下操作的装置：响应拒绝成功保持在所述第一压缩模式。
27.如权利要求26所述的所述首部压缩器单元，其特征在于：所述指示装置包括用于向所述首部解压器单元(22)发送模式变更拒绝消息的装置。
28.如权利要求27所述的所述首部压缩器单元，其特征在于：所述模式变更拒绝消息包含重新定义的模式值。
29.如权利要求26所述的所述首部压缩器单元，其特征在于：所述指示装置包括用于忽略所述模式变更请求一段预定时间间隔的装置。
30.如权利要求26至29中任何一项所述的首部压缩器单元，其特征在于：所述解释装置包括用于监视所述分组传输链路(11)的装置。
31.如权利要求26至30中任何一项所述的首部压缩器单元，其特征在于它设为只支持所有可能操作模式中的一个子集。
32.如权利要求26至31中任何一项所述的首部压缩器单元，其特征在于：它根据具有所述第一和第二压缩模式的稳健首部压缩(ROHC)方案来实现；所述第一和第二压缩模式是下列集合中的一种：单向(U)模式、双向优化(O)模式、双向可靠(R)模式和双向(B)模式以及这些模式的组合模式。
CNB038239906A 2002-10-11 2003-09-16 首部压缩方法 Expired - Fee Related CN100574313C (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US41782202P 2002-10-11 2002-10-11
US60/417,822 2002-10-11

Publications (2)

Publication Number Publication Date
CN1689301A true CN1689301A (zh) 2005-10-26
CN100574313C CN100574313C (zh) 2009-12-23

Family

ID=32094099

Family Applications (1)

Application Number Title Priority Date Filing Date
CNB038239906A Expired - Fee Related CN100574313C (zh) 2002-10-11 2003-09-16 首部压缩方法

Country Status (10)

Country Link
US (1) US7512716B2 (zh)
EP (1) EP1554858B1 (zh)
JP (1) JP4347810B2 (zh)
CN (1) CN100574313C (zh)
AT (1) ATE363802T1 (zh)
AU (1) AU2003263706A1 (zh)
DE (1) DE60314169T2 (zh)
ES (1) ES2287572T3 (zh)
TW (1) TWI250724B (zh)
WO (1) WO2004034675A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101835196A (zh) * 2010-05-14 2010-09-15 中兴通讯股份有限公司 鲁棒性头压缩中一种模式转换的方法和装置

Families Citing this family (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8619592B2 (en) * 2002-06-12 2013-12-31 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for increased internet protocol (IP) headers compression performance by reporting cause of missing packets
US20050265284A1 (en) * 2003-10-10 2005-12-01 Hsu Liangchi Alan Apparatus, and associated method, for facilitating communication handoff in multiple-network radio communication system
US7430617B2 (en) * 2003-12-19 2008-09-30 Nokia Corporation Method and system for header compression
SE0401346D0 (sv) * 2004-05-24 2004-05-24 Ericsson Telefon Ab L M Methods for Increased Tolerance Against Packet Reordering for the Secure Reference Principle in Robust Header Compression
US8254379B1 (en) * 2004-07-15 2012-08-28 Sprint Spectrum L.P. Method and system for application based compression profile selection
KR100703494B1 (ko) * 2004-08-09 2007-04-03 삼성전자주식회사 이동통신 시스템에서 사용자 데이터 프로토콜 체크섬을 포함하는 음성패킷망의 패킷 송/수신 방법 및 장치
US8804765B2 (en) * 2005-06-21 2014-08-12 Optis Wireless Technology, Llc Dynamic robust header compression
JP2007150911A (ja) * 2005-11-29 2007-06-14 Kyocera Corp 無線通信システム及び方法並びに無線基地局
CN101453298B (zh) * 2007-12-07 2013-06-05 华为技术有限公司 一种无线网络中头压缩的处理方法及系统、装置
US7948913B1 (en) * 2008-10-30 2011-05-24 Clear Wireless Llc Communicating data in various modes using header-compression algorithms
WO2010106663A1 (ja) 2009-03-19 2010-09-23 富士通株式会社 受信装置、送信装置、受信方法、送信方法、通信システムおよび通信方法
CN101848491A (zh) * 2010-04-21 2010-09-29 中兴通讯股份有限公司 鲁棒性头压缩中一种模式转换的方法及装置
CN102860108B (zh) * 2010-05-03 2017-05-24 皇家飞利浦电子股份有限公司 用于操作移动台的方法
CN102137439B (zh) * 2010-09-17 2013-09-11 上海华为技术有限公司 压缩控制方法、设备和系统
CN102571540B (zh) * 2010-12-20 2015-12-16 华为技术有限公司 一种解压的方法及装置
US20130016725A1 (en) 2010-12-24 2013-01-17 Telefonaktiebolaget L M Ericsson (Publ) Method and system for intra-node header compression
JPWO2013001814A1 (ja) * 2011-06-30 2015-02-23 パナソニック株式会社 通信装置、通信システム、サーバ装置及び通信方法
WO2015102406A1 (en) * 2014-01-03 2015-07-09 Lg Electronics Inc. Method and apparatus for transmitting/receiving broadcast signal including robust header compression packet stream
US10405278B2 (en) * 2014-10-31 2019-09-03 Qualcomm Incorporated Low power scheduling
KR102254396B1 (ko) 2014-12-17 2021-05-24 삼성전자주식회사 통신 시스템에서 단말의 헤더 압축 기능을 제어하는 방법 및 장치
JPWO2016208568A1 (ja) * 2015-06-25 2018-04-12 日本電気株式会社 データ圧縮装置及びデータ圧縮承認装置
US11019530B2 (en) * 2017-05-05 2021-05-25 The Regents Of The University Of California Trans-layer bidirectional robust header compression system
CN111092844B (zh) * 2018-10-23 2023-12-01 瑞昱半导体股份有限公司 进行压缩操作的模式转换的方法、及传输装置
CN111507072A (zh) * 2019-01-31 2020-08-07 瑞昱半导体股份有限公司 基于健壮性头压缩的压缩端与解压缩端及其数据处理方法

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5131016A (en) * 1991-01-09 1992-07-14 International Business Machines Corporation Communications network data compression control system and method
US5546395A (en) * 1993-01-08 1996-08-13 Multi-Tech Systems, Inc. Dynamic selection of compression rate for a voice compression algorithm in a voice over data modem
US5535199A (en) * 1994-09-06 1996-07-09 Sun Microsystems, Inc. TCP/IP header compression X.25 networks
US6608841B1 (en) * 1999-12-30 2003-08-19 Nokia Networks Oy System and method for achieving robust IP/UDP/RTP header compression in the presence of unreliable networks
US7539130B2 (en) * 2000-03-28 2009-05-26 Nokia Corporation Method and system for transmitting and receiving packets
JP4520032B2 (ja) * 2000-08-17 2010-08-04 パナソニック株式会社 ヘッダ圧縮装置およびヘッダ圧縮方法
FI111493B (fi) * 2000-09-22 2003-07-31 Nokia Corp Kontekstitunnisteen määrittäminen otsikkokenttien kompressoinnissa
FI110739B (fi) * 2000-10-18 2003-03-14 Nokia Corp Otsikkokenttien kompressoinnin määrittäminen datapakettiyhteydelle
US7069495B2 (en) * 2000-10-30 2006-06-27 Telefonaktiebolaget Lm Ericsson (Publ) Bit error resilience for an internet protocol stack
US7290063B2 (en) * 2001-01-10 2007-10-30 Nokia Corporation Relocating context information in header compression
US8837471B2 (en) * 2001-08-01 2014-09-16 Certicom Corp. Disabling header compression over point-to-point protocol (PPP)
US8619592B2 (en) * 2002-06-12 2013-12-31 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for increased internet protocol (IP) headers compression performance by reporting cause of missing packets

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101835196A (zh) * 2010-05-14 2010-09-15 中兴通讯股份有限公司 鲁棒性头压缩中一种模式转换的方法和装置
CN101835196B (zh) * 2010-05-14 2014-08-13 中兴通讯股份有限公司 鲁棒性头压缩中一种模式转换的方法和装置

Also Published As

Publication number Publication date
CN100574313C (zh) 2009-12-23
AU2003263706A1 (en) 2004-05-04
TWI250724B (en) 2006-03-01
EP1554858A1 (en) 2005-07-20
EP1554858B1 (en) 2007-05-30
WO2004034675A1 (en) 2004-04-22
JP2006502654A (ja) 2006-01-19
TW200419928A (en) 2004-10-01
US7512716B2 (en) 2009-03-31
DE60314169D1 (de) 2007-07-12
ATE363802T1 (de) 2007-06-15
ES2287572T3 (es) 2007-12-16
DE60314169T2 (de) 2008-01-24
JP4347810B2 (ja) 2009-10-21
US20040073711A1 (en) 2004-04-15

Similar Documents

Publication Publication Date Title
CN1689301A (zh) 首部压缩方法
JP6025880B2 (ja) データ伝送方法、装置及びシステム
JP5280465B2 (ja) 拡張されたブロック確認応答
CN1526225B (zh) 无线电资源的动态分配
AU2003225363B2 (en) RLC for realtime multimedia mobile communication system
CN101517996B (zh) 用于降低无线通信系统中的死锁可能性的方法和装置
JP4755173B2 (ja) 後で受信するデータを指示するため更新される圧縮状態レポートを生成する方法及び装置
CN1470120A (zh) 在链路层采用信头压缩密钥的上下文标识
CN1382337A (zh) 移动式无线电网的操作方法
CN1918825A (zh) 发送和接收具有处理时间信息的控制协议数据单元
CN1438809A (zh) 上下文重定位方法
CN1778079A (zh) 用于协调tcp/ip网络与其他网络之间的流控制的方法和设备
CN1894922A (zh) 用于广播/组播服务的报头压缩增强
CN1943205A (zh) 提供协议以实现使用拆分式tcp连接的无线tcp会话的方法和装置
JP2009049993A (ja) 無線通信システムにおいてポーリング機能をトリガーする方法及び装置
CN1545783A (zh) 数据包连接上报头压缩标识符的传输
CN1593051A (zh) 扩展标题压缩
CN1689368A (zh) 电信系统中的比特率控制手段
CN1672373A (zh) 信令信道和数据业务信道上的分组数据单元的通信
CN1177434C (zh) 基于通用陆地无线接入网接口的多播业务的实现方法
CN1783876A (zh) 一种实现分组数据聚合协议功能的系统及方法
CN1875557A (zh) 更新下一个期望的tsn和接收机窗口以避免停顿状态
CN102202347B (zh) 稳健头压缩业务流处理方法及装置
CN1156183C (zh) 在地面无线接入网注册用户设备的无线接口协议建立方法
CN1823510A (zh) 分组通信系统及分组通信方法

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C14 Grant of patent or utility model
GR01 Patent grant
CF01 Termination of patent right due to non-payment of annual fee
CF01 Termination of patent right due to non-payment of annual fee

Granted publication date: 20091223

Termination date: 20190916