CN101248642A

CN101248642A - 信令压缩/解压缩

Info

Publication number: CN101248642A
Application number: CNA2006800214907A
Authority: CN
Inventors: 刘志刚; 萨米·朱迪拉; 伊尔卡·佩森恩
Original assignee: Speed Navigation Co ltd
Current assignee: Intellectual Ventures I LLC
Priority date: 2005-05-17
Filing date: 2006-05-16
Publication date: 2008-08-20
Anticipated expiration: 2026-05-16
Also published as: KR101030469B1; WO2006123221A1; CN101248642B; EP1900174B1; JP2008541643A; EP1900174A1; US20060262812A1; US7765325B2; KR20080014041A

Abstract

本发明涉及一种分组数据网络中压缩或解压缩信令消息的方法，其中参数信息被提供在分组数据网络的协议消息的首标部分。参数信息指定至少一个压缩或加压缩机制的处理细节，并通过分组数据网络与协议消息一起转发到分组数据网络的压缩或解压缩功能。然后，根据参数信息，压缩或解压缩功能的压缩或解压缩机制被设定。由于参数信息是直接获得的，因此可以获得第一或前几个消息的更好的压缩。

Description

信令压缩/解压缩

技术领域

本发明涉及一种分组数据网络中压缩或解压缩信令消息的方法和装置。

背景技术

许多用于多媒体通信的应用协议、例如SIP(会话启动协议)或RTSP(实时流协议)，是基于文本的，并且被设计用于具有宽带宽的链路。因此，它们的消息在尺寸方面没有被最佳化。例如，通常的SIP消息的范围是从几百字节到2千字节甚至更多。SIP是由IETF(互联网工程任务组)在RFC(请求注解：Request for Comment)3261中被定义，并且是用于(除了其他功能之外)建立、处理和释放端到端多媒体会话的应用层协议。由于将这些协议计划用于作为蜂窝网络一部分的无线手持设备，大的消息尺寸是有问题的。由于低速率IP(互联网协议)连接性，传送延迟非常显著。考虑到在一些流中所需要的消息的重传和多样性，至少呼叫建立和特征调用受到不利的影响。

为了消除这个问题，已经为应用消息的鲁棒的、无损的压缩定义了信令压缩(SigComp)架构。在OSI(开放系统互连)模型方面，SigComp架构可以被理解为对传输层的增强。因此，SigComp为消息的传送和压缩提供了更高层的应用。SigComp是在IETF中被标准化的协议，其能够压缩应用层协议消息。特别地，其被发展来压缩用于会话(呼叫)建立的SIP消息和诸如消息收发之类的许多其他应用。SigComp的主要目的是减小SIP消息的尺寸，以便能够以低延迟在带宽受限的链路(例如，蜂窝)上传送SIP消息。在没有SigComp的情况下，传送延迟将导致长的呼叫建立时间，这对于最终用户来说可能是不能接收的。SigComp细节被定义在以下IETF的RFC中：RFC3320，RFC 3321，RFC 3322，RFC 3485和RFC 3486。

由于其在移动通信中的有用性，第三代合作项目(3GPP)已经建议将SigComp至少用于压缩SIP消息。因此，未来的3G移动终端必须支持SigComp。

SigComp架构的传送侧包括压缩器调度器(compressordispatcher)、一个或多个压缩器、和状态处理机。压缩器调度器用作来自应用程序的接口。应用程序向压缩器调度器提供应用消息和分隔标识符(compartment identifier)(即，用于对消息进行特定于应用的分组的标识符)。压缩器调度器调用某个压缩器，该压缩器返回SigComp消息以便转发到远处的端点。状态处理机存储和检索状态信息，其中状态信息被存储在SigComp消息之间，以便避免需要在每个消息的基础上上载数据。

SigComp架构的接收侧包括解压缩器调度器、通用解压缩虚拟机(UDVM)(执行解压缩的虚拟机)以及状态处理机。解压缩器调度器用作到应用程序的接口。解压缩器调度器接收来自传输层的SigComp消息，并调用解压缩SigComp消息的UDVM实例。解压缩器调度器然后将所得到的解压缩后的消息转发到应用程序，其中如果该应用程序希望允许为消息保存状态，则其可以返回分隔标识符。在解压缩处理期间，UDVM可以调用状态处理机以访问现有状态或创造新的状态。

SigComp消息与其它应用消息-例如未压缩SIP和RTSP消息-一起在传输层上作为数据包流被传送。SigComp消息由自己的五比特定界符标识，即例如根据传送控制协议(TCP)，在基于流的传输的情况下，它们以11111比特开始并以0xFFFF比特结束。然而，例如根据用户数据报协议(UDP)，在基于消息的传输中不需要结束标记。传输层数据流被引导到解压缩器调度器，其必须被配置成标识用于解压缩的SigComp消息，并将非SigComp消息传递到特定应用客户，如SIP堆栈或RTSP。

然而，初始请求不被压缩，因为根据RFC 3486，在下一跳(hop)URI(统一资源标识符)包括参数“；comp＝SigComp”并且外出代理(outbound proxy)的SIP-URI不包括这个参数之前，不开始压缩。代理地址在初始注册过程期间被传送设备发现，并且此后不被改变。

SigComp已经定义了一些参数，诸如端点所支持的版本号和存储容量。为了SigComp在消息发射器和接收器之间工作，它们必须对这些参数值达成一致。现行的方法是，SigComp接收器必须支持为每种应用协议-例如在本例中是SIP-定义的SigComp参数的最小值。接收器可以提供比最小值更大。在这种情况下，接收器可以在发送回发射器的SigComp反馈消息中通知该参数值，例如如文献US2005/0086327A1中所述。这也产生了几个问题：

第一，SigComp不够快。当发射器发送第一消息时，可能希望知道接收器是否支持新版本的SigComp，或者是否具有比所指定的最小值更大的容量。当然，发射器可以等待来自接收器的SigComp反馈。但是，这意味着第一消息不能以最优的方式被压缩。可能存在以下情况而使这个问题变得更糟，即在反方向上出现消息之前，发射器不得不发送多个消息。这意味着多个消息--不仅仅是第一个消息--不能被最优地压缩。

第二，SigComp的实施是复杂的。采用现行的SigComp通知方法，可能需要在第一消息之后实施“切换”(例如，从SigComp版本1到版本2，或者从小的存储缓存器到更大的缓存器)，以便将额外的容量用于后续的消息。这种“切换”将给实施增加明显的复杂性。

第三，SigComp不适用于其中SigComp仅被应用到一个信令方向的非对称情形。这是因为上面提到的通知必须作为SigComp信号的一部分被传递。因此，如果SigComp不被应用到另一方向，则可能没有SigComp反馈被发送回发射器。在这一点上，应该注意的是，一些无线电技术是非对称的，例如小的带宽用于上行链路，而大的带宽用于下行链路。在这种情况下，只有在上行链路上传送的SIP信息需要被SigComp压缩。

第四，在SigComp中，利用任何压缩算法进行压缩。RFC 3220中的好的想法在于，不论采用什么压缩算法，解压缩总是可能的。利用运行由进行压缩的端点所提供的字节代码的虚拟机进行解压缩。然而，字节代码的尺寸是几百个字节，因此，经由空中接口传送字节代码就导致降低的压缩比。经常可能发生的是，在一个压缩会话的生命周期(RFC 3320中的分隔生命周期)期间被压缩的消息很少(少于50)，以致于使用SigComp可能实际上使被传送的字节的总量多于没有压缩的情况。应该注意的是，当两个端点都可以自由地选择压缩算法时，字节代码通常在两个方向上被发送。如今，上行链路和下行链路发送字节代码需要各自额外的705字节的有效负荷。

此外，网络不能决定终端设备在压缩中采用什么算法。它可能使用非常低或者效率差的算法。或者，可以采用高效的算法，然而这种算法消耗非常多的处理时间，并且因此限制网络可以服务的用户的数量。

此外，每个终端通常总是使用相同的字节代码，并且甚至来自同一制造商的终端通常使用完全相同的字节代码。因此，相同的字节代码每一个小时经由空中接口被发送多次，这减小了整体容量以及压缩的益处。

网络侧上的一个附加问题在于，当从多个终端接收字节代码时，网络可能需要计算SHA-1值，以便始终获为相同的字节代码获得state-id(状态id)。这在网络服务器中产生不必要的处理负荷，并且可能实际上限制了它能够服务的用户的数量。

另一方面，如果网络已经存储了一组字节代码，则这可以优化UDVM实施，从而所存储的字节代码可以非常有效地被处理。例如，如果已知对于一些比特代码，解压缩使用LZ77算法，那么该比特代码的网络实施可以使得根本不使用虚拟机和比特代码，而是使用更有效的标准方法进行解压缩，例如以一些通用编程语言编写的解压缩例程。从而，与在虚拟机中运行比特代码相比，一个服务器可以服务多得多的用户。

发明内容

因此，本发明的一个目的是提供一种更有效的信令压缩，其至少减轻了上述问题。

该目的通过一种在分组数据网络中压缩或解压缩信令消息的方法实现，所述方法包含以下步骤：

在所述分组数据网络的协议消息的首标部分中提供参数信息，所述参数信息指定压缩或加压缩机制的至少一个处理细节；

通过所述分组数据网络向所述分组数据网络的压缩或解压缩功能转发所述协议消息；以及

根据所述参数信息，在所述压缩或解压缩功能中设置所述压缩或解压缩机制。

此外，上述目的通过一种在分组数据网络中处理信令消息的装置实现，所述装置包含：

用于从所述分组数据网络所接收的协议消息的首标部分提取参数信息的单元，所述参数信息指定压缩或解压缩机制的至少一个处理细节；以及

根据所提取的参数信息，设置在所述装置中所提供的用于压缩或解压缩所述信令消息的压缩或解压缩功能的单元。

此外，上述目的通过一种用于处理来自分组数据网络的信令消息的装置实现，所述装置包含：

用于向所述分组数据网络的协议消息的首标部分添加参数信息的单元，所述参数信息指定压缩或解压缩机制的至少一个处理细节；以及

用于向所述分组数据网络传送具有所添加的参数信息的协议消息的单元。

因此，提出例如在SIP级，通过协议信息的首标部分指示压缩或解压缩参数信息，使得发射器单元可以在发送第一消息之前确定接收器的压缩参数值，或者接收器单元可以在没有任何附加专用信令的情况下直接确定解压缩参数值。

从而，可以实现第一个或前几个消息的更好的压缩。此外，压缩实施可以被简化，因为在了解另一端点的压缩参数信息，例如版本或容量之后，就不需要“切换”。

作为附加优势，提供了相当简单的信令压缩，其可以仅用在一个方向上，并且其可以与现有规范、例如RFC 3486协同工作。

此外，可以扩展通告能力信息(advertised capabilityinformation)，使得可以通告可能已知的字节代码，这就得到协商阶段(negotiation phase)期间的改善的压缩比，并且使得对于上行链路方向也能够选择压缩算法。此外，这提供了更有效地解码解压缩算法的机会，因为可以在不采用虚拟机以及没有字节代码的情况下进行解压缩。从而，还可以引入新的更多的开发的(外部)压缩算法。如果增加新的通告参数，则在单向压缩的情况下也可以接收关于字节代码存储的信息。

通常，在传送端实施的情况下，该装置可以包括用于压缩和传送信令消息的发射器，其中所接收的参数信息是压缩参数信息。可替换地，传送端的装置可以向接收端传送解压缩参数信息。

在接收端实施的情况下，该装置可以包含用于接收和解压缩所述信令消息的接收器，其中所接收的参数信息是解压缩参数信息。可替换地，接收端的装置可以向传送端传送压缩参数信息。

协议信息可以是应用层协议信息，诸如例如SIP消息或RTSP消息。参数信息可以包括SigComp架构的至少一个参数。

协议消息可以是所述信令消息的发送回传送端的反馈消息，作为对于通信初始请求的响应。

此外，可以在统一资源标识符或SIP消息的via-header的至少一个中提供参数信息。参数信息可以在分组数据网络的中间服务器设备处被添加到统一资源标识符。此外，参数信息可以在分组数据网络的客户设备处被添加到Via-header中。特别地，参数信息可以被添加作为指示使用压缩机制的参数的后缀。作为替换，参数信息可以被添加作为与指示使用压缩机制的参数相分隔的数据段。

作为一个实例，参数信息可以包括预先确定的指示参数信息开始的第一字符(character)。此外，参数信息可以包括至少一个后面跟随有相应整数的字符，该整数指示由所述至少一个字符所代表的相应参数值。

更特别地，但不是必要地，参数信息可以指定以下中至少一个：信令压缩版本，状态存储器大小，解压缩存储器大小，每比特的循环次数，以及逻辑上可用的状态。

可选地或附加地，参数信息可以指定压缩或解压缩功能实施的专有信息。

在对于解压缩参数的特定实例中，参数信息可以包含至少一个由虚拟解压缩机使用的字节代码。该至少一个字节代码可以在分组数据网络中被通告。它可以作为via参数被添加到SIP消息的via-header。via参数可以从字节代码状态标识推导得出。

此外，如果不支持该至少一个字节代码，则可以在响应于协议消息而传送的响应消息中修改或替换该至少一个字节代码。然后，修改或替换后的字节代码在不同的参数名下被传送。可选地，该至少一个字节代码可以被存储在接收端。作为一个实例，该至少一个字节代码可以被存储在终端设备的用户身份模块(SIM)中。可以基于分配给该至少一个字节代码的优先级来执行存储，从而可以更好地控制旧字节代码的删除。

可选地或附加地，该至少一个字节代码可以被添加到会话启动协议注册消息的连接首标(contact header)中。

从属权利要求中限定了更多的有利变体。

附图说明

参考附图，基于优选实施例对本发明进行说明，其中：

图1显示了根据优选实施例的网络环境的示意图；

图2显示了根据第二优选实施例的via-header修改的示意信令图；

图3显示了根据第二优选实施例用于传送反馈数据的过程的示意信令图。

具体实施方式

下面，将结合RFC 3320中所定义的SigComp信令压缩方案描述本发明的优选实施例。

在RFC 3320的段落3.3中，描述了5个SigComp参数。它们影响SigComp接收器如何处理所接收的SigComp消息。为了具有成功的SigComp操作，SigComp发射器需要知道接收器的这些参数的值。这5个SigComp参数可以被用来分别限定解压缩存储器大小(decompression_memory_size)、状态存储器大小(state_memory_size)、每比特的循环数量(cycles_per_bit)、压缩版本(SigComp_version)、以及本地可用的状态(包含0或更多状态项的集合)。

图1示出了根据优选实施例的网络环境的示意图。用户设备(UE)10或其它终端设备中所提供的SIP用户代理(user agent)(未示出)经由无线接入网(未示出)而与业务网30的SIP外出代理服务器20(即，第一跳代理服务器)、诸如IP多媒体子系统的代理呼叫状态控制功能(P-CSCF：Proxy Call State Control Function)交换消息，从而接入基于IP的网络40、例如互联网的业务。首先，UE 10和外出代理20交换消息序列，从而建立UE 10和外出代理20之间的安全关联。这些消息被未压缩地发送。

根据优选实施例，引入一个机制，用来在SIP级指示以上SigComp参数中至少之一。

在第一优选实施例中，以上机制可以具有两个成分或选项：

第一，SigComp参数可以被指示作为SIP URI的一部分。SIP URI标识可连接的SIP通信资源(例如用户或业务)。例如，SIP客户发送SIP请求到SIP URI所标识的SIP服务器。在SIP URI中包括SigComp参数就自动地宣告(declare)URI所标识的SIP实体(entity)的SigComp能力。这使得发射器能够以最优的方式在其发送的最先SIP消息上应用SigComp。

第二，SigComp参数可以被指示作为Via-header字段的一部分。Via-header字段在SIP请求中传递。它指示对于请求的SIP响应应该被发送到哪里。通过在Via-header字段中包括SigComp参数，SIP请求的发射器可以向它的对等实体(peer)宣布它的SigComp容量，从而对等实体可以在发送回第一响应时以最优的方式应用SigComp。

应该注意，以上两个选项可以被交替地使用或者作为并行的成分被使用。例如，第一成分允许(代理)服务器在它的URI中宣布它的SigComp参数，从而客户可以利用最优的SigComp配置来压缩发送到服务器的第一请求消息。第二成分可以被同一客户用于在请求的via-header字段中宣称它本身的SigComp容量(其对于服务器可能是事先未知的)。当服务器发送回对于请求的响应时，它能够已经根据客户的SigComp容量压缩了响应。

至于SigComp参数的格式，在实施中可以存在许多不同的化体。但是，它们可以基本上落入以下两个选项：

选项1：

对于URI和Via-header字段，SigComp参数可以作为后缀被添加到RFC 3486中所定义的“comp＝sigcomp”。例如：

sip:alice@Atlanta.com；comp＝sigcomp_VnSnDnCn_Lx

via:SIP/2.0/UDP

pc33.Atlanta.com；branch＝z9hG4bK776asdhds；comp＝sigcomp_VnSnDnCn_Lx

下面解释该选项的格式：

字符串“sigcomp”后的第一个“_”字符指示SigComp参数的开始；

字符“V”，“S”，“D”，“C”和“L”分别代表SigComp_version，state_memory_size，decompression_memory_size，cycles_per_bit，以及本地可用的状态。

字符“V”后面跟随一个整数，该整数指示SigComp_version。该整数可以是一个阿拉伯数字(digit)或多个。例如，“V1”意味着Sigcomp_version＝1，“V10”意味着SigComp_version＝10。

类似地，每个字符“D ”，“S”，“C”后面都跟随一个整数(1个或多个阿拉伯数字)，其指示相应值。然而，该整数的面值(face value)应该做如下解释，其覆盖RFC 3320的段落3.3.1中所定义的可能值的父集(superset)。目的是使SigComp参数字符串尽可能的短、

设n表示整数的面值。

“S”后：如果n等于0，则state_memory_size＝0字节；否则，state_memory_size＝2⁽¹⁰⁺ⁿ⁾字节。

“D”后：与上面相同，除了n不能为0(因为0不是有效的decompression_memory_size)。

“C”后：cycles_per_bit＝2ⁿ。

注意，“V”，“S”，“D”，“C”之间的顺序是任意的。例如“V1S2D3C4”等同于“V1D3C4S2”。二者均表示SigComp_version＝1，state_memory_size＝4KB，decompression_memory_size＝8KB，并且cycles_per_bit＝16。此外，如果相应的参数具有SigComp相关规范所定义的缺省值，则它们中的一些或所有都可以被省略。例如，“S3”表示state_memory_size＝8KB，并且所有其它SigComp参数值与缺省值相同。

“L”后的字符串是本地可用状态的状态标识符(全部或部分)的16进制表示。例如，“L4B7ECDE7DA49”表示SIP实体具有部分状态标识符(最高有效的6个字节)为0x4B7ECDE7DA49的本地可用状态。更多细节请参考RFC 3320中段落3.3.3和7.2。这使得发射器能够在知道状态内容的情况下使用状态项。

注意：可以存在0个或多个“_Lx”实例。特别地，“_Lx”元素的省略意味着SIP实体除了SigComp标准所指定的缺省状态之外不具有任何其他本地可用状态。

注意，“Lx”前的“_”对于语法分析(parsing)的目的是需要的，因为“D”和“C”(简洁的参数名)也可能出现在“Lx”中，如上所示的实例中。

选项2：

SigComp参数可以被添加作为与“comp＝”参数分隔的数据字段。

例如：

sip＝alice@Atlanta.com；comp＝sigcomp；comp-param＝VnSnDnC

n_Lx

via:SIP/2.0/UDP

pc33.Atlanta.com；branch＝z9hG4bK776asdhds；comp＝sigcomp；c

omp-param＝VnSnDnCn_Lx

除了分隔之外，SigComp参数字符串的格式可以与选项1的相同。本选项的优势是与RFC 3486的互用性。也就是，如果实施本发明的SIP端点发送如上的数据字段到仅实施RFC 3486的另一SIP端点，则后者仍可以从“comp＝sigcomp”字段推断出前者支持SigComp。“comp-param＝”字段于是将被接收器忽略。唯一的结果是接收器不知道发射器的(多于缺省的)额外容量，这在没有所提出的增强的情况下无论如何都是这样。此外，该选项-与RFC 3486结合-可以bei用作用于指示除了SigComp之外的压缩特征的一般框架。也就是说，作为RFC RFC 3486的“comp＝”字段指示压缩算法，而建议的“comp-param”可以指示该算法的附加信息(例如压缩参数)。选项2在SIP URI和Via-header中需要附加字段。这还意味着，相比于选项1，需要更多字节(即“comp-param＝”)。然而，选项2提供了互用性和一般性的优势。

应该注意的是，还可以为SIP端点扩展该机制，以指示关于其SigComp实施的专有(proprietary)信息。一个简单的方法是向SigComp参数字段添加“_Xs”，其中“_”是定界符，“X”表示它是专有元素，而“s”代表传递该专有信息的文本字符串。如果接收器不理解它的意思，则其可以忽略“X”字段。

根据第二优选实施例，想法是简单地在终端设备中、并且还在网络侧存储一个或多个字节代码，并且提供用于通告可用字节代码的方法，使得它们不必一再经由空中接口被传送。

在与终端启动压缩会话相关的第一实例中，终端设备可以通过通告它已经知道最可能被网络用于压缩的(多个)字节代码，来开始与网络的压缩会话(即，分隔，例如利用SIP方法REGISTER或INVITE)。于是，当网络开始下行链路方向上的压缩时，如果它想使用与终端设备已经通告的相同的字节代码，则它完全不需要上载字节代码。

在从网络接收到任何字节代码之后，终端设备可以将字节代码还存储在永久存储器中，可能取代旧字节代码中的一些或一个。因此，可以随着压缩算法演变而动态地更新算法，并且不需要像现有技术方法中的情况那样事先固定或协商(agree)算法。

网络还可以通告最可能被终端使用的(多个)字节代码，这或者在终端设备已经通告它知道的字节代码时在未压缩的响应中通告，或者利用公知的在返回参数中通告本地可用状态的方法而在压缩消息中通告(更多细节见RFC 3320)。在任一情况下，如果终端选择使用网络所通告的字节代码，则不必向网络发送字节代码。

在与网络启动压缩会话相关的第二实例中，如何处理新接收的来自终端设备的字节代码可能存在差别。由于存储某个还没有被终端制造商官方验证为正确的代码可能是安全或资源问题，所以不在永久存储器中存储字节代码可能更安全。

应该注意的是，第二优选实施例所基于的想法还支持使字节代码与网络运营商和终端制造商以及必备(mandatory)字节代码等保持一致的概念。终端设备中的一些字节代码可以在绝不会被覆写或由新算法替代的存储器中。在必备算法的情况下，必备算法可以不需要被通告，除非由于某特定原因，网络希望终端设备具体使用该算法(和该字节代码)并且没有其它算法。

RFC 3486中已经描述了SigComp协商方法，它使用；comp＝sigcomp来指示sigcomp解压缩的能力。一个方法是扩展能力信息，使得可以通告可能已知的字节代码。

当发送请求时，只要存在解压缩的能力和愿望，Via：首标就包括；comp＝sigcomp参数。对于还不存在压缩会话的情况，很容易对其进行扩展。对于那些情况，添加新的via-parameter，<compression-bytecodes>。这个新的bc-parameter的格式例如可以如下：

；bc＝bc_state_id_in_hexadecimal。

例如，如果字节代码状态id是0x76 0x94 0x34 0xA3...0x6C，则bc-parameter可以具有值：

；bc＝769434A3...6C

state-id的长度可以是20个字节，从而会有40字节的16进制数(hexdigits)。然而，它可以被缩短，使得参数中需要至少最小访问长度的字节。因此，在最小访问长度6字节的情况下，在bc-parameter中需要至少12个十六进制数字。还可以按优先权顺序为多于一个字节代码通知状态标识符(但不必然是有用的)。

如果具有这个新的bc-parameter的请求被终端设备、诸如例如移动终端接收，则其在知道它的情况下必须使用来自列表的字节代码，而不选择任何其它字节代码。这使得网络可能平衡各服务器的负荷，因为它可以选择用于两个方向(上行链路和下行链路)的压缩算法。

如果bc-parameter包含空的字节代码列表，这意味着没有字节代码被已经发送bc-parameter的传送实体存储或优选。然而，传送实体知道该机制，并且希望另一端通告它知道或优选的字节代码。

在接收到bc-parameter之后，就知道另一端支持所存储的字节代码机制。于是，在发送响应时，可以修改via:header作为响应，从而可以通告所支持的字节代码。然而，对于该参数，应该使用不同的名字，因为否则就不能区分另一端是否只是将via：首标拷贝回我们，或者它是否已经知道字节代码通告方法。作为响应，所接收的be-parameter内容可以被丢弃或忽视，并且可以用bc_resp:parameter来代替。bc_resp-parameter的编码可以与bc-parameter的相同。

另一种提供所支持的字节代码的方式是在压缩消息中使用RFC3320中所描述的返回参数机制。然而，如果消息不被压缩，则这个新的bc_resp-parameter是通告已知字节代码的唯一方式。

此外，如果终端设备知道该字节代码，并且不可以选择其他字节代码以便使网络对于上行链路方向也可以选择压缩，则终端设备必须使用在bc_resp参数中所通告的字节代码。

在接收到be-parameter之后，就知道另一端支持所存储的字节代码机制。于是，在发送响应时，可以改变via-header作为响应，使得可以通告所支持的字节代码。然而，对于那个参数，应该使用不同的名字，因为否则就不能区分另一端是否只是拷贝回via-header，或者它是否已经知道字节代码通告方法。作为响应，所接收的bc-parameter内容可以被丢弃或忽视，并且可以由bc_resp-parameter替代。bc_resp-parameter的编码可以与bc-parameter的相同。

图2显示了根据第二优选实施例的via-header修改的示意性信令图。具有包含“comp＝sigcomp；bc＝e24343...；comp_param＝V2”的via-header的请求被图1中的UE用来通告可能被外出代理20使用的字节代码，从而通知支持sigcomp版本2。在外出代理20的响应中，via-header包含“comp＝sigcom；bc resp＝...”。由于via参数被修改，所以UE 19知道外出代理20实际上理解该参数。在未压缩地发送响应的情况下需要这个机制。有时，不压缩每个响应可能是有用的，或者有时在一个方向上压缩是有用的。在这种情况下，网络不想压缩，但是它希望终端压缩它的消息。相同类型的via-header修改对于其它sigcomp参数、例如“comp_param_resp＝V2”可能也是有用的。所以，以一种简单的方式实现了双向协商。

也就是说，响应中via-header的修改允许在两个方向上交换sigcomp参数。当然，如果在响应中使用SigComp压缩，则进入via-header的sigcomp参数不再是必要的，因为可以使用反馈机制。即使在SigComp期间仍可以使用bc-header，以便改变UE 10在压缩中所使用的算法。例如，UE 10可以首先使用DEFLATE算法，并且一会之后，网络注意到某个其它算法工作得更好。于是它可以在via-header中通告某个其它字节代码。网络可以在两个方向上具有压缩算法的主控制(master control)。

对于字节代码存储，存在许多可能的方案。一个或一些字节代码可以被永久地存储在终端存储器中(例如必备或运营商优选的字节代码)。SIM(用户身份模块)卡可以是一个存储地点，其中字节代码id与它的参数(诸如长度，最小访问长度等)一起被存储，从而指示该字节代码不应该被从终端存储器中删除。SIM卡还可以存储整个字节代码。字节代码可以经由诸如SMS(短消息业务)下载等公知机制而被更新。

当终端设备在SigComp信令中接收到新的字节代码时，它通常将该字节代码也存储在它的终端存储器中，从而可以在下一次终端设备通电时可以将其通告。由于终端设备仅具有有限的存储容量，因此在存储这个新字节代码而需要从存储器中删除一些旧字节代码的情况下，可能需要一些优先权算法。而且，可能的是，如果在存储器中仅存在具有更高优先级的字节代码，则该字节代码不被存储在终端存储器中。高优先级字节代码可能包括被SIM卡指示为高优先级字节代码的那些字节代码、作为优选字节代码而与一些SIP设定链接的那些字节代码等等。优先级机制可以以各种已知方法中任何一种被实施。

对于网络侧，可行的方案可以是，移动终端制造商提供关于在它们的终端中所使用的字节代码的信息(至少状态标识符)，于是网络可以在某处永久地存储那些字节代码，或者选择任何其它策略来确认对于字节代码不需要非必要的存储。可以使用任何合适的机制，以便提供终端制造商的信息，并且提供如何和/或何时存储字节代码。然而，可能地，用于存储新字节代码的策略与终端策略不同。

如果终端设备已经在它的存储器中存储了多个字节代码，则在；bc或；bc_resp字段中通告所有这些字节代码是没有用的。一种简单的策略是通告在压缩中所使用的最后一个。更复杂的策略包括记住对于每个端点使用了什么字节代码或者将字节代码与连接设定相链接。此外，SIM可以包含关于优选字节代码的信息等。还可以通告多个字节代码，但是这需要小心处理，因为如果处理长的通告消息，则这减小压缩比。

对于网络侧，寄存器可以具有关于当前被用户使用的字节代码的信息。这需要将该信息添加到在REGISTER消息中所提供的Contact：首标。此外，网络还可能具有一些其它机制，以便选择它通告的字节代码。在一些情况下，当网络想要所有用户选择某个特定字节代码时，选择是简单的。只有那个字节代码被通告，使得对于解压缩，计算每个用户的负载效应是非常简单的。

如到目前为止所解释的那样，sigcomp参数和关于所存储的字节代码的信息可以被传递。然而，在单方压缩的情况下，还可以在via-header中发送所返回的反馈将是有用的。

图3显示了用于在第一端点A 220和第二端点B 230之间传送反馈数据的过程的示意信令图。如果压缩仅是单向的，则反馈不被递送到端点A 220，因为反馈数据在压缩消息中被递送。

根据图3，端点A 220处的压缩器C向端点B 230处的UDVM发送请求反馈的sigcomp消息(步骤1)。UDVM获取压缩信息(步骤2)，并经由状态处理机SH控制端点B 230的压缩器C，从而生成具有反馈信息的响应(步骤3和4)。通过将反馈添加到via-header，可以改善压缩效率。图2中端点B 230的压缩器C实际上可以不是压缩器，因为如果它发现对于端点A 220的分隔以及对于端点的反馈(步骤5)，它不会生成Sigcomp消息，而是发送未压缩的消息，其中via-header包括新的参数“returned-feedback＝......；”。当端点A 220的UDVM接收具有这个新参数的via-header时(步骤7)，它发现匹配的分隔(如果可能)(步骤6)，并且由于它经由端点A 220中的状态处理机SH被传递到压缩器C，所以可以在端点A 220的压缩器C处使用更先进的压缩算法，例如动态压缩。

然而，应该注意的是，如果压缩一些数据会实际上扩展消息，例如压缩已压缩的数据，或者对于所使用的压缩算法不理想的数据，或者例如在压缩消耗太多资源并暂时被去激活时的重负荷状态期间，单向压缩也是可能的。因此，其可能仅仅是一些没有被压缩的消息，但是反馈仍然可以被递送到另一端点的压缩器。

这个返回的反馈也可以是via-header中sigcomp-param的一部分，诸如“...comp_param＝Fnnnn”，以及通告“bytecode...comp_param＝B...”的另一种方式。

但是，对整体SIP消息大小的影响通常应该被最小化。在多数时候，提出的增强的via-header不需要被添加。理想地，正好在SigComp压缩开始之前需要它们，例如，只在初始REGISTER消息上。因此，在sigcomp协商的大多数消息中可以不需要所提出的额外字段，但是存在例外。作为一个例外，如果想要改变终端所使用的压缩算法，bc-header可以被网络添加。作为另一个例外，当反馈在未压缩消息中被发送时，添加反馈首标，如上面结合图3所述。作为再一个例外，如果由于某个原因，对于远处端点的分隔被损坏，则sigcomp协商被重新开始。这也可以被NACK机制检测。

上述参数中的一些可以是REGISTER消息中连接信息的一部分。它们是REGISTER消息中URI或单独首标字段的一部分。

总之，已经介绍了一种用于分组数据网络中压缩或解压缩信令消息的方法和装置，其中在分组数据网络的协议消息的首标部分中提供参数信息。参数信息指定压缩或解压缩机制的至少一个处理细节，并且与协议消息一起通过分组数据网络被转发到分组数据网络的压缩或解压缩功能。于是，根据参数信息设定压缩或解压缩功能处的压缩或解压缩机制。从而，可以实现第一个或前几个消息的更好的压缩，因为参数信息是直接可获得的。

此外，应该注意的是，本发明不限于上述优选实施例，并且可以在任何分组数据网络中实施，其中压缩或解压缩参数必须被交换。如果可以利用适合潜在目的的任何类型的首标部分来传递或通告参数，则参数信息可以限定任何类型。因此，优选实施例可以在所附权利要求的范围内改变。

Claims

1.一种分组数据网络中压缩或解压缩信令消息的方法，所述方法包括以下步骤：

a)在所述分组数据网络的协议消息的首标部分中提供参数信息，所述参数信息指定压缩或解压缩机制的至少一个处理细节；

b)通过所述分组数据网络向所述分组数据网络的压缩或解压缩功能转发所述协议消息；以及

c)根据所述参数信息，在所述压缩或解压缩功能处设置所述压缩或解压缩机制。

2、根据权利要求1的方法，其中所述协议消息是应用层协议消息。

3、根据权利要求2的方法，其中所述应用层协议消息是会话启动协议消息或实时流协议消息。

4、根据上述权利要求中任一项的方法，其中所述参数信息包括SigComp架构的至少一个参数。

5、根据上述权利要求中任一项的方法，其中所述协议消息是响应于对通信的初始请求，发送回所述信令消息传送端的反馈消息。

6、根据上述权利要求中任一项的方法，其中在会话启动协议消息的Via-header或统一资源标识符中至少一个中提供所述参数信息。

7、根据权利要求6的方法，其中，所述参数信息在所述分组数据网络的中间服务器设备处被添加到所述统一资源标识符。

8、根据权利要求6或7的方法，其中所述参数信息在所述分组数据网络的客户设备处被添加到所述Via-header。

9、根据上述权利要求中任一项的方法，其中所述参数信息作为后缀被添加到指示使用所述压缩机制的参数。

10、根据上述权利要求中任一项的方法，其中参数信息作为与指示使用所述压缩机制的参数相分隔的数据字段而被添加。

11、根据权利要求9或10的方法，其中所述参数信息包括预先确定的用于指示所述参数信息开始的第一字符。

12、根据权利要求11的方法，其中所述参数信息包括至少一个后面跟随有相应整数的字符，其中所述整数指示所述至少一个字符所代表的参数的相应值。

13、根据权利要求12的方法，其中所述参数信息指定以下中至少之一：信令压缩版本，状态存储器大小，解压缩存储器大小，每比特的循环数量，以及逻辑上可用的状态。

14、根据权利要求12的方法，其中所述参数信息指定实施所述压缩或解压缩功能的专有信息。

15、根据权利要求1的方法，其中所述参数信息包括要被虚拟解压缩机使用的至少一个字节代码。

16、根据权利要求15的方法，其中所述至少一个字节代码在分组数据网络中被通告。

17、根据权利要求15或16的方法，其中所述至少一个字节代码作为via参数被添加到会话启动协议消息的via-header。

18、根据权利要求17的方法，其中从字节代码状态标识确定所述via参数。

19、根据权利要求15到18中任一项的方法，其中，如果不支持所述至少一个字节代码，则在响应于所述协议消息而传送的响应消息中修改或替换所述至少一个字节代码。

20、根据权利要求19的方法，其中改变或替换后的字节代码以不同的参数名被传送。

21、根据权利要求15到20中任一项的方法，其中所述至少一个字节代码被存储在接收端。

22、根据权利要求21的方法，其中所述至少一个字节代码被存储在用户身份模块(SIM)中。

23、根据权利要求21或22的方法，其中基于分配给所述至少一个字节代码的优先级来执行所述存储。

24、根据权利要求15或16的方法，其中所述至少一个字节代码被添加到会话启动协议注册消息的连接首标。

25、一种分组数据网络中处理信令消息的装置，所述装置包括：

a)提取单元，用于从自所述分组数据网络所接收的协议消息的首标部分中提取参数信息，所述参数信息指定压缩或解压缩机制的至少一个处理细节；以及

b)设置单元，用于根据所提取的参数信息，设置在所述装置中所提供的用于压缩或解压缩所述信令消息的压缩或解压缩功能。

26、根据权利要求25的装置，其中所述装置包括发射器，用于压缩和传送所述信令消息，其中所述参数信息是压缩参数信息。

27、根据权利要求26所述的装置，其中在会话启动协议消息的via-header或统一资源标识符中至少一个中提供所述参数信息。

28、根据权利要求25所述的装置，其中所述装置包括接收器，用于接收和解压缩所述信令消息，其中所述参数信息是解压缩参数信息。

29、根据权利要求28的装置，其中所述解压缩参数信息包括要被虚拟解压缩机使用的至少一个字节代码。

30、根据权利要求29所述的装置，其中在会话启动协议消息的连接首标或via-header中提供所述参数信息。

31、一种用于处理来自分组数据网络的信令信息的装置，所述装置包括：

a)添加单元，用于将参数信息添加到所述分组数据网络的协议消息的首标部分，所述参数信息指定压缩或解压缩机制的至少一个处理细节；以及

b)发送单元，用于将添加有所述参数信息的协议消息传送到所述分组数据网络。

32、根据权利要求31的装置，其中所述装置包括接收器，用于接收和解压缩所述信令消息，其中所述参数信息是压缩参数信息。

33、根据权利要求32的装置，其中在会话启动协议消息的via-header或统一资源标识符中至少一个中提供所述压缩参数信息。

34、根据权利要求31的装置，其中所述参数信息是解压缩参数信息。

35、根据权利要求34的装置，其中所述解压缩参数信息包括要被虚拟解压缩机使用的至少一个字节代码。

36、根据权利要求29的装置，其中在会话启动协议消息的连接首标或via-header中提供所述参数信息。