由于因特网的巨大成功，在所有种类的链路上利用因特网协议(IP) 成为艰巨的任务。但是，由于IP协议的首标相当大的事实，使其对 于窄带链路、如蜂窝链路成为事实不一定是简单的任务。作为一个 实例，考虑通过用于基于JP的语音(VoIP)的协议(IP、UDP、RTP)所 传送的普通语音数据，在其中，首标可表示大约70％的分组，导致 链路的极低效的使用。
术语“首标压缩”(HC)包含根据每跳通过点到点链路使首标中 携带的信息所用的必要带宽为最小的技术。首标压缩技术在因特网 共同体内一般具有十年以上的历史。存在若干常用的首标压缩协议， 例如下面的协议：(1)Van Jacobson，“为低速串行链路压缩TCP/IP 首标”，IETF RFC 1144，IETF Network Working Group，1990年2 月；(2)Mikael Degermark、Bjrn Nordgren、Stephen Pink，“IP首标 压缩”，IETF RFC 2507，IETF Network Working Group，1999年2 月；以及(3)Steven Casner、Van Jacobson，“为低速串行链路压缩 JP/UDP/RTP首标”，IETF RFC 2508，IETF Network Working Group， 1999年2月，通过引用将它们全部完整地结合到本文中。
首标压缩利用以下事实：首标中的某些字段在流中不改变或者 以小值和/或可预测值改变。首标压缩方案利用这些特性并且仅在最 初发送静态信息，同时，变化字段以其绝对值或者作为差值逐分组 发送。完全随机的信息必须未经任何压缩被发送。
因此，首标压缩是使通过无线的IP服务、如语音和视频服务在 经济上可行的重要成分。首标压缩解决方案已经由因特网工程任务 组(IETF)的健壮首标压缩(ROHC)工作组提出，以便提高这类服务的 效率。
如RFC 3095(Bormann，C.，“健壮首标压缩(ROHC)：框架和四 个协议子集：RTP，UDP，ESP和未压缩”，RFC 3095，Internet Engineering Task Force，2001年7月)中定义的健壮首标压缩(ROHC)是可对其定 义各种协议的压缩的协议子集的可扩展框架。对于实时多媒体服务(例 如语音、视频)，应用数据在IP/UDP/RTP流中端到端地传送。 IP/UDP/RTP的首标压缩由ROHC协议子集0x0001(ROHC RTP)定 义，并且其中还可应用于基于IP的语音(VoIP)服务。ROHC RTP首 标压缩方案设计成有效地压缩通过任意链路层的IP/UDP/RTP首标。
还对压缩定义了多个其它ROHC协议子集。其中还包括：(1) IP/UDP/RTP首标(在Jonsson，L.和G.Pelletier的“健壮首标压缩 (ROHC)：IP/UDP/RTP的链路层辅助ROHC协议子集”(IETF RFC 3242，2002年4月)以及Liu，Z和K.Le的“扩展链路层辅助健壮首 标压缩(ROHC)协议子集中的双向可靠模式(R模式)的零字节支持” (IETF RFC 3408，2002年12月)中描述)；(2)仅IP首标(在Jonsson，L. 和G.Pelletier的“健壮首标压缩(ROHC)：IP的压缩协议子集”(IETF RFC 3843，2004年6月)中描述)；(3)IP/TCP首标(在Pelletier，G.， Jonsson，L.，West，M.和R.Price的“健壮首标压缩(ROHC)：TCP/IP 协议子集(ROHC-TCP)”(Internet Draft(制订中)，，2004年10月)中描述)；以及(4)JP/UDP-Lite/RTP首标(在 Pelletier，G.的“健壮首标压缩(ROHC)：UDP-Lite的协议子集”(Internet Draft(制订中)，，2004年6月)中描述)。 本文引述的所有RFC通过引用完整地结合到本文中。
除了协商之外(又参见Bormann，C.的“基于PPP的健壮首标压缩 (ROHC)”，IETF RFC 3241，2002年4月)，ROHC协议子集仅要求由 链路层提供成帧和检错，而其它所有功能性则由ROHC方案本身来 处理。
RFC 3095、RFC 3242、RFC 3408中定义的ROHC协议子集“仅 IP”(Jonsson，L.和G.Pelletier的“健壮首标压缩(ROHC)：IP的压缩 协议子集”，IETF RFC 3843，2004年6月)和“ROHC-UDPLite”(Pelletier， G.的“健壮首标压缩(ROHC)：UDP-Lite的协议子集”，Internet Draft(制 订中)，，2004年6月)都支持三种不同 的操作模式。简言之，对于特定上下文，操作模式控制在首标压缩 操作的不同状态中要执行的动作和逻辑以及要使用的分组类型。被 允许的分组类型和格式可能逐个模式变化。在可能发生到其它模式 的任何转变之前，在任何ROHC压缩开始时使用单向模式(U模式)。 双向优化模式(O模式)设法使压缩效率以及反馈信道的稀少使用为最 大。双向可靠模式(R模式)设法使对于损失传播和上下文损坏传播的 健壮性为最大。
处于U模式时，分组仅从压缩器发送到解压缩器。因此，U模 式在其中从解压缩器到压缩器的返回路径不需要或不可用的链路上 可使用。定期刷新用于U模式。U模式特别适用于广播或多播信道。
O模式与U模式相似，其中的差别在于，反馈信道用来发送差 错恢复请求以及(可选的)从解压缩器到压缩器的重要上下文更新的确 认。对于大部分ROHC协议子集，U模式和O模式因它们相当相似 的特性-例如两种模式相同的分组格式集合-而往往模糊地采用术 语U/O模式来表示。
R模式与其它两种模式明显不同，主要在于更广泛地利用反馈信 道以及用于执行上下文更新的更严格的逻辑。R模式还采用仅在这种 模式中被理解和有用的几个不同的分组类型。
各操作模式在压缩效率、健壮性和处理复杂度方面具有不同的 属性。模式转变仅可由解压缩器发起。ROHC不规定应当使用各模 式的方式和时间(除了ROHC压缩必须始终以U模式启动之外)。因 此，用于模式转变的逻辑是实现判定，并且可基于链路特性的测量、 链路条件、特定模式的实现优化，或者可基于其它算法。具体来说， 对于广播/多播类型的服务，首标压缩仅以单向模式(U模式)进行操 作，因为通常对于这类服务，从解压缩器到压缩器的反馈信道不可 用或者不需要。
首标压缩方案(例如ROHC协议子集)可概念化和/或实现为状态 机。一个艰巨的任务是保持称作上下文的压缩器和解压缩器状态相 互一致，同时使首标开销尽可能低。压缩器有一个状态机，以及解 压缩器有一个状态机。压缩器状态机直接影响压缩效率等级，因为 它是控制要发送的压缩分组类型的选择的逻辑的重要部分。解压缩 器状态机的目的主要是提供用于反馈的逻辑(如果适用的话)以及标识 可对其尝试解压缩的分组类型。
压缩上下文包含和保存关于过去的分组的相关信息，并且这个 信息用于对后续分组进行压缩和解压缩。如ROHC文献中所述，压 缩器的上下文是它用来压缩首标的状态。解压缩器的上下文是它用 于对首标解压缩的状态。在清楚是指哪一个时，它们中的任一个或 者两个的组合通常称作“上下文”。上下文包含来自分组流中的先 前首标的相关信息，例如压缩和解压缩的静态字段和可能的参考值。 此外，描述分组流的附加信息也是上下文的一部分，例如关于JP标 识符字段如何变化以及序列号或时标中典型分组间增加的信息。
对于RFC 3095、RFC 3242、RFC 3408中定义的ROHC协议子 集“仅JP”(Jonsson，L.和G.Pelletier的“健壮首标压缩(ROHC)：IP 的压缩协议子集”，IETF RFC 3843，2004年6月)和“ROHC-UDPLite” (Pelletier，G.的“健壮首标压缩(ROHC)：UDP-Lite的协议子集”，Internet Draft(制订中)，，2004年6月)，图1 说明压缩器状态机。对于ROHC压缩，三种压缩器状态是初始化和 刷新(IR)、一阶(FO)和二阶(SO)状态。压缩器以最低压缩状态(IR)开 始，并逐渐转变到更高的压缩状态。在压缩器充分确信解压缩器具 有对按照那种状态压缩的首标进行解压缩所需的信息的限制下，压 缩器将始终以最高可能的压缩模式进行操作。例如参见RFC 3095 4.3.1节(Carsten Bormann等人的“健壮首标压缩(ROHC)：框架和四 个协议子集：RTP、UDP、ESP和未压缩”，IETF RFC 3095，2001年 4月)。具体来说，在以U模式进行操作时，关于各种压缩状态之间 的转变的判定通常由压缩器根据分组首标的变化和定期超时来进 行。
根据RFC 3095在4.3.1节中定义初始化和刷新(IR)状态，IR状 态的目的是初始化解压缩器上的上下文的静态部分或者在故障之后 恢复。在这个状态中，压缩器发送完整的首标信息。这包括未压缩 形式的所有静态和非静态字段加上某种附加信息。压缩器停留在IR 状态，直到清楚地确信解压缩器正确地接收到静态信息。
因此，IR状态是压缩等级为最低的状态。摘自RFC 3095的5.3.1 小节的图2描述U模式状态机。在图2的U模式状态机中，Timeout_1 通常对应于解压缩器上下文的静态(以及可能还有动态)参数的定期发 送，而Timeout_2则通常对应于解压缩器上下文的仅动态参数的定期 发送。
另外，ROHC协议子集的上下文复制(CR)机制引入附加状态、 即CR状态。参见Pelletier，G.的“健壮首标压缩(ROHC)：ROHC协 议子集的上下文复制”Internet Draft(制订中)，，2003年10月。至今，只有[ROHC-TCP]协议子集 规定支持上下文复制，但是其它协议子集也可支持上下文复制，只 要它们的对应标准被更新。CR状态还可由以U模式操作的协议子集 使用。图3说明添加到CR状态的前一个状态机的逻辑。在U模式 中，向下转变根据与以上所述相同的逻辑来执行。
摘自RFC 3095的5.3.2小节的图4说明示例U模式解压缩器状 态机。解压缩器的状态规定可对什么类型的压缩分组进行解压缩。 在无上下文(NC)状态中，仅可对初始化静态部分的分组进行解压缩(例 如ROHC IR分组)。在静态上下文(SC)状态中，仅可对包含关于动态 参数的充分信息的分组(例如ROHC IR-DYN或UOR-2分组)解压缩。 在完全上下文(FC)状态中，可对任何分组解压缩。因此，根据信道的 条件以及根据解压缩的成功率，解压缩器状态机将在不同状态之间 转变，并且必须等待接收用于尝试解压缩的适当分组。
在单向操作中，没有回送到压缩器的反馈。因此，在单向操作 中，解压缩器可能(在最坏情况下)具有多达Timeout_1的等待时间而 无法开始所接收分组的解压缩，并且当它可在对动态信息的严重上 下文损坏之后重新开始压缩之前具有多达Timeout_2的等待时间。
至今，首标压缩算法在以下假定之下来设计：分组(其首标经过 压缩)基本上按顺序传递，因而分组在接收时无需实质上重新排序。 根据这种假设，最传统的首标压缩算法在压缩器与解压缩器之间的 首标压缩分组的重新排序不可能的前提下操作。参见例如：Van Jacobson，“为低速串行链路压缩TCP/IP首标”，IETF RFC 1144，IETF Network Working Group，1990年2月；Mikael Degermark、Bjrn Nordgren、Stephen Pink，“IP首标压缩”，IETF RFC 2507，IETF Netwodk Working Group，1999年2月；Steven Casner、Van Jacobson，“为低 速串行链路压缩IP/UDP/RTP首标”，IETF RFC 2508，IETF Network Working Group，1999年2月；以及Carsten Bormann等人，“健壮 首标压缩(ROHC)：框架和四个协议子集：RTP、UDP、ESP和未压 缩”，IETF RFC 3095，2001年4月，通过引用将它们全部结合到本 文中。
几个首标压缩算法仅允许或适应分组的轻微失序传递，因而仅 允许或适应接收时分组的轻微重新排序(具有极少几个分组的深度)。 参见例如：Koren，T.、Casner，S.、Geevarghese，J.、Thompson B.和 P.Ruddy的“具有高延迟、分组丢失和重新排序的链路的增强压缩 RTP(CRTP)”，IETF RFC 3545，IETF Network Working Group，2003 年7月；以及Pelletier，G.、Jonsson，L.和Sandlund，K.的“通过可对 分组重新排序的信道的健壮首标压缩(ROHC)”，Internet Draft(制订 中)，，2004年6月，通过 引用结合到本文中。
压缩算法的设计主要集中于改进通过无线蜂窝链路的属性驱动 的、对于分组丢失的容差。顺序信息的编码已经从累计增量编码改 进到更健壮的窗口最低有效位(W-LSB)编码。在例如下列文献中描述 了累计增量编码：Van Jacobson，“为低速串行链路压缩TCP/IP首 标”，IETF RFC 1144，IETF Network Working Group，1990年2月； Mikael Degermark、Bjrn Nordgren、Stephen Pink，“IP首标压缩”，IETF RFC 2507，IETF Network Working Group，1999年2月；以及Steven Casner、Van Jacobson，“为低速串行链路压缩IP/UDP/RTP首标”， IETF RFC 2508，IETF Network Working Group，1999年2月。窗口最 低有效位(W-LSB)编码在下列文献中描述：Carsten Bormann等人的 “健壮首标压缩(ROHC)：框架和四个协议子集：RTP、UDP、ESP 和未压缩”，IETF RFC 3095，2001年4月。还采用其它方法，例如 减小顺序信息的压缩比(Koren，T.、Casner，S.、Geevarghese，J.、 Thompson B.和P.Ruddy的“具有高延迟、分组丢失和重新排序的链 路的增强压缩RTP(CRTP)”，IETF RFC 3545，IETF Network Working Group，2003年7月)，或者调节现有编码方法的一部分参数(Pelletier， G.、Jonsson，L.和Sandlund，K.的“通过可对分组重新排序的信道的 健壮首标压缩(ROHC)”，Internet Draft(制订中)，，2004年6月)。
与以上观察一致，IETF ROHC工作组(WG)采用以下假定来设计 首标压缩算法(协议子集)：压缩器与解压缩器之间的信道不会对首标 压缩分组重新排序。因此，要求信道保持各压缩流的分组排序。已 采用这个假设来定义编码方法，以便积极地压缩首标并得到高压缩 比。对于某些协议子集，可对逻辑和/或对某些编码方法(例如LSB) 进行修改，以便处理极小(少于5个分组)量的重新排序(Pelletier，G.、 Jonsson，L.和Sandlund，K.的“通过可对分组重新排序的信道的健壮 首标压缩(ROHC)”，Internet Draft(制订中)，，2004年6月))。但是，对于没有采用顺序信 息编码的字段(例如半静态字段)的变更限制对重装排序分组进行解压 缩和/或防止在出现中等(数十个分组)或者高(数百个分组)重新排序时 的严重上下文损坏的能力。
随着具有更高比特率和更低等待时间(对于比特率仍然具有较高 等待时间)的无线链路的即将到来的发展，有序传递假设可能不再有 效。需要首标压缩/解压缩算法，它们不仅对于分组丢失是健壮的， 而且对于失序传递、因而对分组的重新排序是健壮的。
因此，所需的以及本发明的目的是即使对于失序分组也能够进 行首标解压缩的方法及设备。

在各个方面、模式、实施例和实现中，通过远程终端、通过在 远程终端上使用的首标解压缩器以及通过操作远程终端和/或解压缩 器的方法，以及(可选地)在某些方面、模式、实施例和实现中，还通 过考虑首标压缩器的结构和操作方面，来实现首标压缩修复技术。
首标解压缩器适合于与远程单元、如移动台或用户设备单元配 合使用。远程单元通常还包括收发信机等，它通过诸如空中接口之 类的链路接收分组，其中包括具有经过压缩的首标的分组以及可能 失序的分组。根据其配置和操作的一个独立且不同的方面，首标解 压缩器在检测到通过链路的分组流中预计的分组的未收到时，对于 每个未收到，存储未收到时现有的首标解压缩上下文信息的快照。 然后，当首标解压缩器检测到后来接收的分组的首标解压缩失败时， 首标解压缩器确定(例如通过执行修复过程)后来接收的分组的首标解 压缩是否可采用多个已存储快照之一来获得。在努力进行这种获取 时，解压缩器优选地(例如采用修复过程)重试对后来接收的分组的解 压缩，并在这种重试中采用多个已存储快照的每个。如果采用多个 已存储快照中唯一的一个获得了后来接收的分组的首标解压缩，则 首标解压缩器(例如采用修复过程)更决定性地确定后来接收的分组的 首标解压缩的重试取得成功。如果多个快照中的不止一个获得分组 的成功首标解压缩，则多个快照中的哪一个实际上用于分组的选择 可基于其它技术、如(例如)传输协议检验等，例如传输协议校验和或 CRC。
作为配置和操作的第一方面的一个示例实现，对于在流的序列 中丢失的各分组或连续分组的组，首标解压缩器把快照集合中的对 应快照存储在滑动窗口存储器中。在不同的模式中，首标解压缩器 可采用集合中的所有快照或者集合中的快照的子集来重试后来接收 的分组的解压缩。在其中采用快照的子集的模式中，子集的构成可 基于有助于成功解压缩的最可能快照，例如，由分组首标中携带的 分组序列号(例如序列号的最低有效位)所确定的快照。
根据其配置和操作的第二独立且不同的方面，首标解压缩器还 确定首标解压缩对于流中预计的分组的未收到之后所接收的预定数 量的分组是否失败。这种首标解压缩失败可能产生于以下事实：未 收到的分组的一个或多个可能已承载有意义的上下文更新信息，没 有这种信息时，首标解压缩导致“上下文损坏”。如果是这样，则 首标解压缩器(例如采用辅助修复过程)存储在未收到之后所接收的并 且首标解压缩失败的分组(例如“缓冲分组”)，希望在它能够以某种 方式恢复丢失的上下文更新信息时，可采用这种丢失的上下文更新 信息来执行缓冲分组的后续修复。因此，根据第二方面，如果(例如 通过执行修复过程)首标解压缩器采用多个已存储快照之一获得后来 接收的分组的解压缩，则实现首标解压缩的首标解压缩上下文信息 的快照被更新，并(例如由辅助修复过程)用于重试已存储(缓冲)分组 的首标解压缩。
在第二方面，采用多个已存储快照之一实现后来接收的分组的 解压缩的恢复在两个示例情况中是可行的。在第一种这样的情况中， 对已缓冲分组解压缩所需的上下文更新信息是被延迟并且仅在检测 到上下文损坏之后才由首标解压缩器接收的失序分组(当作后来接收 的分组处理)。在第二种这样的情况中，对已缓冲的分组解压缩所需 的上下文更新信息通过另一个分组(当作后来接收的分组处理)中的重 传来获得，如下面结合第三方面所述。
根据其配置和操作的第三独立且不同的方面，在无法(例如采用 修复过程)对分组首标解压缩时，首标解压缩器产生流中预计的分组 的未收到的通知。优选地，未收到的通知包括分组重发信息，以便 实现具有适当的更新首标解压缩上下文信息的分组的重发(例如通过 链路从首标压缩器)，从而使执行成功的首标解压缩的首标解压缩器 的努力(例如采用修复过程)复原。例如，未收到的通知包括作为分组 重发信息的上一次成功解压缩分组的序列号。
作为示例实现，首标解压缩器把快照存储在滑动窗口存储器中。 滑动窗口存储器的大小优选地由链路的带宽和延迟之积来确定。首 标解压缩器通过确保滑动窗口存储器中的最旧快照对应于滑动窗口 存储器可处理的最大重新排序深度，来更新滑动窗口存储器的内容。
根据其配置和操作的第四独立且不同的方面，首标解压缩器(例 如通过执行窗口分配过程)根据在链路上接收的一个或多个窗口参数 为多个已存储快照临时分配可再用存储器。参数可表示以下一项或 多项(优选地为以下全部)：其中存储多个已存储快照的可再用存储器 的大小；分配用于存储多个已存储快照的可再用存储器的时间；对 用于存储多个已存储快照的可再用存储器解除分配的时间。
根据这个第四方面，首标解压缩器仅有选择地、例如在由窗口 参数表明的时间对于滑动窗口存储器施加附加存储器和处理要求。 有利的是，利用这个第四方面，为滑动窗口存储器分配的存储单元 可临时分配，或者在没有调用或预期修复过程时使用。用于调用或 预期首标解压缩器的修复过程的时间、因而滑动窗口存储器的分配 可能包括各种类型的转接和切换或者当分组可能倾向于失序或者倾 向于丢失的其它任何时间或时间段。这类时间可通过测量来确定或 者通过历史(似然)信息来预测。
附图说明
通过以下结合附图对优选实施例的更具体说明，本发明的上述 及其它目的、特征和优点将会非常明显，附图中，参考标号表示各 个视图中的相同部件。附图不一定按照比例，重点在于说明本发明 的原理。
图1是示例压缩器状态机的简图。
图2是示例U模式状态机的简图。
图3是简图，说明添加到CR状态的状态机的逻辑。
图4是简图，说明示例U模式解压缩器状态机。
图5是简图，说明用作用于说明首标解压缩修复的技术的示例 上下文的一般电信系统。
图6A是示意图，说明根据第一示例方面的首标解压缩器的基本 的示例功能实体。
图6B是简图，说明由图6A的首标解压缩器执行的基本的示例 功能过程。
图6C是简图，说明由图6A的首标解压缩器执行的基本的示例 操作。
图6D是简图，说明通过图6A的首标解压缩器的修复过程执行 的基本的示例操作和事件。
图7是简图，说明由窗口管理器维护的示例滑动窗口。
图8A是示意图，说明根据第二示例方面的首标解压缩器的基本 的示例功能实体。
图8B是简图，说明由图8A的首标解压缩器执行的基本的示例 功能过程。
图8C是简图，说明由图8A的首标解压缩器执行的基本的示例 操作。
图8D是简图，说明通过图8A的首标解压缩器的修复过程执行 的基本的示例操作和事件。
图8E是简图，说明通过图8A的首标解压缩器的辅助修复过程 执行的基本的示例操作和事件。
图9是简图，说明在利用辅助修复过程的情况中维护的示例滑 动窗口。
图11是简图，表示一般电信系统，说明第三方面，在其中，向 压缩器提供关于由解压缩器预计的分组的未收到的事实的通知。
图11A是简图，表示一般电信系统，说明第三方面，在其中， 经由来自解压缩器的带内反馈信号提供通知。
图11B是简图，表示一般电信系统，说明第三方面，在其中， 通知经由链路层消息传递来提供。
图12A是示意图，说明根据第三示例方面的首标解压缩器的基 本的示例功能实体，在其中，首标解压缩器包括重传请求器。
图12B是示意图，说明根据第三示例方面的首标解压缩器的基 本的示例功能实体，在其中，首标解压缩器包括链路层丢失通知器。
图12C是简图，说明由图12A或者图12B的任一个的首标解压 缩器执行的所选的基本示例操作。
图12D是简图，说明在接收到反馈通知时由图11的首标压缩器 执行的所选的基本示例操作。
图13是简图，表示一般电信系统，说明第四方面，在其中，首 标解压缩器根据一个或多个窗口参数临时为多个已存储快照分配可 再用存储器。
图14是示意图，说明根据图13的第四示例方面的首标解压缩 器的基本的示例功能实体。
图15A是用作可采用本发明的示例上下文的具体电信系统的示 意图，在其中，首标压缩器包括在通用分组无线电业务(GPRS)服务 (SGSN)节点中。
图15B是用作可采用本发明的示例上下文的具体电信系统的示 意图，在其中，首标压缩器包括在网关通用分组无线电业务(GPRS) 支持节点(GGSN)中。
图15C是用作可采用本发明的示例上下文的具体电信系统的示 意图，在其中，压缩器包括在无线电网络控制器(RNC)中。

为便于说明而不是进行限制，以下描述中提出了诸如特定体系 结构、接口、技术等的具体细节，以便透彻地理解本发明。然而， 本领域的技术人员很清楚，在不同于这些具体细节的其它实施例中 也可实现本发明。在其它情况下，省略对众所周知的装置、电路及 方法的详细说明，以免不必要的细节妨碍对本发明的说明。
图5说明示例电信网络20，在其中，分组流由分组源21提供。 例如，图5说明具有应用于协议栈23的媒体净荷(MPAY)和首标(MH) 的媒体分组22。构成协议栈的具体协议可改变，并且通常包括因特 网协议之下、传输协议之下的应用协议。在具体的所述实例中，协 议栈23用于把协议首标24(例如IP、UDP和RTP)附加到媒体分组22。 具有其附加协议首标24的媒体分组22被施加到分组首标压缩器25。 分组压缩器25压缩协议首标24，产生分组的压缩首标26。首标压 缩器25根据传统的(例如ROHC或SigComp)或其它的许多适当的首 标压缩算法的任一个执行首标压缩。在分组首标由首标压缩器25压 缩之后，分组格式器26把压缩首标加入施加到收发信机29的分组。 收发信机29用于经由链路36通过接口38在分组流34中向远程单 元40传送分组、例如具有其压缩首标26的分组30。可能大多数具 有压缩首标的分组的流34无需是连续的，但可能是零星的，取决于 所涉及的分组服务的类型和分组服务中包含的素材的性质(例如媒体 类型)。
从图5的分组源21发出的分组流可通过各种方式来实现。例如， 分组流可能：(1)由服务器预先记录并发送(在这种情况中，媒体分 组22中的媒体已经过编码)；(2)来自变码器(它使来自源的原始媒体 适应于可能更适合的和/或由终端支持的另一种媒体编码)；或者(3)来 自执行实时媒体的实时编码的源。因此，首标压缩器可接收来自IP 网络中的某个位置上的若干类型的媒体源的任一个的输入媒体分 组。分组源21可能是任何适当的源、例如媒体服务器，并且可位于 与首标压缩器25公共或者远离的节点或网络中。
图5中的接口38的左侧所示的上述电信元件仅表示为与本论述 有密切关系的某些代表元件，并且可理解地不是构成电信网络20的 整体，因为还存在其它许多未示出的元件。此外，所述元件的集合 可分布于一个或多个节点或者网络(例如核心网或无线电接入网)，并 且在部分情况中，单独的元件本身可分布到多个平台和/或多个节点。 因此，为了简洁起见，所述元件表示为按照图5的方式连续地直接 连接在一起。
虽然远程单元40具有多个元件，但是，适合于理解远程单元40 执行的首标解压缩的某些基本的代表元件如图5所示。在这些元件 中是收发信机42，它把通过链路36接收的分组施加到分组去格式器 44。分组去格式器44主要用于从所接收分组中提取压缩首标。在提 取压缩首标之后，压缩首标被发送给首标解压缩器46进行解压缩。 在分组首标由首标解压缩器46解压缩之后，包含其解压缩首标的分 组由缓冲管理器48存储在解压缩分组缓冲器49中。缓冲管理器48 还从解压缩分组缓冲器49检索分组利用应用50、例如涉及接收媒体 流等的特定应用所需的解压缩分组。另外，远程单元40包括分组格 式器52，用于准备要通过链路36(以及自分组格式器52的上游的各种 所示元件)回送的分组。
首标压缩器25用于压缩已由分组源21提供并且还可能经过编 码的分组首标(例如媒体分组)。与其首标压缩结合，首标压缩器25 把上下文信息发送给解压缩器，供解压缩器用于对媒体分组的压缩 首标进行解压缩。如本文所使用的“上下文信息”包含上下文初始 化信息和上下文刷新信息之一或两者。上下文信息可基于定期间隔 包含在送往远程单元40的分组流中，如通常的情况那样(例如RFC 3095(Bormann，C.，的“健壮首标压缩(ROHC)：框架和四个协议子集： RTP、UDP、ESP和未压缩”，RFC 3095，因特网工程任务组，2001 年7月)中那样)，或者，可按照同时提交并通过引用结合到本文的标 题为“采用取决于媒体特性的上下文信息的传送的首标压缩的方法 及设备”的美国专利申请序号(代理人档案号：2380-839)中公开的媒 体分组的媒体特性来包含。
因此，首标解压缩器46适合与远程单元40(它可采取诸如移动 台、移动终端、无线终端或用户设备单元之类的许多装置/应用的任 一个的形式或者被认为是其中的任一个)配合使用。在图5的所述实 施例中，首标解压缩器46出现在无线远程单元40中。因此，远程 单元40通过空中或无线电接口接收射频传送，图5中由虚线38表 示。无线远程单元40的使用例如符合本文引述并通过引用结合的 RFC。但是大家会理解，本文所述的首标解压缩技术不限于与任何具 体类型的远程终端或终端接口配合使用，作为替代或补充，这些技 术可用于非无线的或者是通过无线电波之外的类型的辐射或波的传 送。例如当存在不同的物理路径、因而对于相同的虚拟链路存在不 同的延迟时，失序分组接收可在有线链路网络或系统中进行。
远程单元40通过诸如空中接口之类的链路36接收包括具有已 压缩的首标的分组在内的分组。这些分组一般通过链路依次传送。 但是，依靠首标解压缩器46中包含的处理器54，远程单元40能够 处理包含经过中等重新排序或者高重新排序的分组的失序分组。本 文所使用的经过“中等重新排序”的分组表示该分组失序相当于数 十个分组的数量，而经过“高重新排序”的分组则表示该分组失序 相当于数百个分组的数量。下面通过若干代表性的非限制并且可能 独立的方面来说明这种失序处理。
采用已存储的短暂内容状态的重试解压缩
图6A说明根据第一方面的首标解压缩器46(1)的示例结构和/或 功能单元。首标解压缩器46(1)包括解压缩状态机60，它从分组去格 式器44接收具有需要解压缩的首标的分组。解压缩状态机60(以上 述方式并且如本领域的技术人员理解的那样)例如提供反馈(如果适用 的话)的逻辑，并识别可能尝试对其进行解压缩的分组类型。解压缩 状态机60包括分组首标解压缩器62，它实际上执行或者至少尝试执 行要求解压缩的各分组的解压缩。
首标解压缩器46(1)的失序分组处理器54还包括图6A中所示的 其它各种元件或功能性。这类元件或功能性包括最后上下文快照存 储器63、序列分析器64、窗口管理器66和修复单元68。解压缩失 败单元/例程70包含在首标解压缩器46(1)中，或者是独立的或者作 为失序分组处理器54的一部分。如同下文所述的首标解压缩器的其 它方面那样，这些元件或功能性可采用各个硬件电路、采用结合一 个或多个适当编程的数字微处理器或通用计算机运行的软件、采用 专用集成电路(ASIC)和/或采用一个或多个数字信号处理器(DSP)单独 或共同实现。
根据操作的基本事件或步骤(如图6C所示)，首标解压缩器46(1) 首先检测通过链路36的分组的流34中预计的分组的未收到(事件 6C-1)。在图6A的示例实现中，序列分析器64执行分组的未收到的 检测。在检测到流34中预计的分组的未收到时，作为事件6C-2，首 标解压缩器46(1)对于每个未收到，存储未收到时现有的首标解压缩 上下文信息的快照。本文所使用的“快照”或上下文项是对于特定 分组、即序列号SN＝x的分组的解压缩所需并保存的状态信息。参照 RFC 3095(Bormann，C.，“健壮首标压缩(ROHC)：框架和四个协议 子集：RTP，UDP，ESP和未压缩”，RFC 3095，因特网工程任务组， 2001年7月)的各小节、例如包括小节6.5、小节6.5.1和小节6.5.2 来理解这种信息的身份和性质。
根据该分组，快照可包括当时现有的所有上下文信息，或者(在 更经济的情况中)仅包括分组首标的解压缩所需的动态和/或半静态上 下文信息。对于窗口存储器72中保存的各上下文条目(快照)，与分 组关联的序列号(SN)的值作为该条目的索引来保存。在一种操作模式 中，在窗口存储器72中的快照中存储的上下文信息可能是在丢失分 组时出现或存在的整个上下文信息。在另一种更经济的操作模式中， 在窗口存储器72中的快照中存储的上下文信息可能只是在分组丢失 时当前存在的动态和/或半静态上下文信息。仅保存半静态和动态信 息作为快照是可行的，因为例如静态信息已经存在于上下文中，并 且静态信息对于单个流没有改变。
在未收到时解压缩所需的首标解压缩上下文信息由解压缩状态 机60从远程单元40所接收的上下文更新分组中获得，并存储在最 后上下文快照存储器63中。在所述实现中，首标解压缩上下文信息 的这类快照从最后上下文快照存储器63中获得，并且由窗口管理器 66存储在上下文快照的窗口存储器72中。然后，当首标解压缩器46(1) 检测到后来接收的分组的首标解压缩失败时，作为事件6C-3，首标 解压缩器46(1)确定(例如通过执行由修复单元68执行的修复过程)后 来接收的分组的首标解压缩是否可采用多个已存储快照之一来获 得。
图7说明由窗口管理器66保存在窗口存储器72中的示例滑动 窗口74。图7中的圆圈指示符A表明，在所接收的最近的序列号(SN) 具有值SNcurrent时，序列分析器64在分组接收中检测到五个间隙或孔。 因此，在孔检测的每个时间现有的上下文信息的“快照”插入窗口 存储器72中的五个位置。窗口存储器72中的第一窗口项x0对应于 最旧的孔；窗口存储器72中的第二窗口项x1对应于下一个最旧的孔； 依此类推，其中的窗口项xi被称为具有窗口顺序或窗口项编号i。如 图7所示，窗口项具有基于最旧项(x0)加上索引的索引，其中的索引 表明在最旧项x0与孔的出现之间接收到多少分组。例如，图7的项x3 表明，在项x0(项x0为xref)的孔之后的四十二个分组出现孔。窗口存 储器72中的各项xi产生于检测到的孔，并且对于各项，适当的上下 文更新信息(分组丢失出现时的当前上下文信息)存储在相应项中。
CnWnd间隔大小可在应用首标压缩的链路的带宽-延迟乘积中 作为基础。这可用来导出重新排序深度。当最旧的快照滑出窗口存 储器72时，下一个最旧的快照成为参考。例如，如果在图7中，窗 口存储器72随时间变满以及最旧的快照滑出，则以前作为快照x1的 快照将变成x0，其它快照则相对它来索引。窗口深度告知在我们需 要在窗口存储器72中保存上下文快照的分组的历史中追溯的程度。 这个窗口在其中序列中出现孔的点上开始，以及上限是最后的解压 缩分组(解压缩的当前上下文状态)。重新排序深度可能是在压缩器与 解压缩器之间的链路上分组可经受的最大可能的重新排序，或者可 能只是希望能够处理的(可由存储器限制控制的)重新排序的最大量。
图7的圆圈指示符B、圆圈指示符C、圆圈指示符D和圆圈指 示符E反映事件6C-3的基本子事件以及修复单元68的各个基础操 作。圆圈指示符B表示解压缩失败的后来接收的分组，其中失败的 分组的序列号不是已知的(因而失败的分组被认为失序)。图7的圆圈 指示符C表示修复单元68重试后来接收的分组的解压缩。在重试解 压缩时，首标解压缩器46(1)采用多个已存储快照的每个，例如图7 所示的五个快照的每个。图7的圆圈指示符C反映以下事实：如果 后来接收的分组没有呈现是采用快照的任一个可解压缩的，或者呈 现是采用快照中的不止一个可解压缩的，则后来接收的分组可能不 是可解压缩的，或者可能需要另一个逻辑来决定多个候选快照中哪 一个与后来接收的分组配合使用。另一方面，如图7的圆圈指示符E 所示，如果采用示例滑动窗口74中的快照中唯一的一个对后来接收 的分组解压缩，则修复过程可能是成功的，并且具有关于解决的保 证的增强措施。在图7所示的具体情况中，在圆圈指示符B处解压 缩失败的后来接收的分组的首标呈现是采用74中的上下文快照中唯 一一个、即快照上下文Delta_C_ref2可解压缩的。因此，已经对后来 接收的分组的首标解压缩，并且该分组可施加到缓冲管理器48以便 存储在解压缩分组缓冲器49中。
图6B更详细地说明首标解压缩器46(1)的失序分组处理器54的 功能方面以及它们之间传送的各种通信或信号。在图6B中，各实体 以功能项、例如作为过程或例程来表示。因此，例如，修复过程68 对应于图6A的修复单元68。
根据操作，图6B通过信号S-1表明，分组首标解压缩器62在 分组首标的成功解压缩时通知序列分析器64。序列分析器64接收解 压缩分组，并检验其序列号。如果解压缩分组的序列号具有处于预 计顺序、例如处于带有其它解压缩分组的序列号的序列中的值，则 解压缩分组可被传递(经由信号S-2)给缓冲管理器48以便存储在解压 缩分组缓冲器49中(参见图5)。或者，如果由最后上下文快照存储器 63对其首标进行解压缩的分组的序列号被序列分析器过程64确定为 没有按顺序，则向窗口管理器过程66发送信号S-3。窗口管理器过 程66从最后上下文快照存储器63中获得(经由信号S-4)当时存在的 上下文信息，并且在对应于丢失分组引起的孔的位置上把上下文快 照存储在窗口存储器72中。如果分组首标解压缩器62无法对分组 解压缩，则失败通知信号S-5被发送给修复单元68。
本领域的技术人员会理解，对其首标解压缩的整个分组不一定 需要发送给序列分析器过程64，只要解压缩分组或者其序列号至少 被发送。这还假定序列分析器过程64具有根据它的序列分析的结果 向缓冲管理器48转发成功解压缩的有序分组的能力。
图6D说明修复单元68的基本功能方面以及在接收到失败通知 信号S-5(参见图6B)时由此执行的修复过程。修复单元68的功能方 面基本上对应于图6C所示的主要事件6C-3。因此，图6D所示的列 举修复事件(RE)基本上包含在修复单元68的一个非限制性的示例实 现中。
图6D的修复事件R-1说明修复单元68接收通知。在信号S-5 的解压缩失败通知的情况中，这种通知触发事件R-2。作为事件R-2， 修复单元68确定要用于重试解压缩失败的分组首标的解压缩的窗口 存储器72中的最适合快照的集合。如前面所述，对于在流的序列中 丢失的各分组或连续分组的组，首标解压缩器46(1)把快照集合中的 相应快照存储在滑动窗口存储器72中。在不同的模式中，首标解压 缩器可采用集合中的所有快照或者集合中的快照的子集来重试解压 缩失败的后来接收的分组的解压缩。因此，修复事件R-2包括修复 单元68判定包含窗口存储器72中的所有快照还是快照的子集。在 采用快照的子集的情况中，修复单元68基于哪些快照是帮助成功解 压缩的最可能快照确定子集的构成，例如通过分组序列号(例如序列 号的最低有效位)所确定的快照。因此，作为事件R-2，修复单元68 首先通过向窗口管理器66发送信号S-6来请求或取出项(快照)的集 合(或子集)。窗口管理器66在如信号S-7所示向修复单元68发送项(快 照)的集合(或子集)时，从窗口存储器72中获得项(快照)的集合(或子 集)。从窗口存储器72中得到的项(快照)的集合(或子集)在下文中称 作集合(或子集)的item1至itemlast。
作为事件R-3，修复单元68重试失败的分组的首标的解压缩。 重试解压缩包括一系列解压缩重试，各重试涉及item1至itemlast中不 同的一个。图6D和图6B的信号S-6表示回送到分组首标解压缩器 62供重试解压缩的项中的代表性的一个，例如itemi。作为事件R-4， 采用项itemi的重试解压缩是否具有有意义的结果经由从分组首标解 压缩器62发送并由修复单元68处理的信号S-9报告。
如果在完成失败的分组的所有解压缩重试之后确定只有一项(例 如只有一个上下文快照)得到先前失败的分组的正确解压缩，则作为 事件R-5，修复单元68向缓冲管理器48发送已修复分组(作为信号 S-10)，以便存储在解压缩分组缓冲器49中(参见图5)。另外，作为 事件R-5的一部分，修复单元68向序列分析器64发送已修复分组 的序列号。唯一的一个上下文快照使分组首标可解压缩的事实对解 压缩增加了置信度。
如果在完成失败的分组的所有解压缩重试之后确定不止一项(例 如多个上下文快照)得到先前失败的分组的正确解压缩，则作为事件 R-6，修复单元68采用附加检验机制，希望选择多个上下文快照候 选者之一以确定性地用于后来接收的分组。采用附加检验机制可包 括例如传输协议(例如UPD或TCP)校验。这类校验可包括例如校验 和或循环冗余校验(CRS)。如果附加检验机制的使用得到候选快照中 唯一一个解决该分组的判定，则作为事件R-5，修复单元68向缓冲 管理器48发送已修复分组(作为信号S-10)，以便存储在解压缩分组 缓冲器49中(参见图5)，以及已修复分组的序列号被发送给序列分析 器64。
另一方面，如果没有使用快照项产生分组首标的解压缩，则作 为信号S-12，失败通知被发送给解压缩失败单元/例程70。类似地， 如果在事件R-6，修复单元68(2)无法决定多个快照候选者中哪一个 对于解压缩是最佳的，则作为信号S-12发送失败通知。
为了方便起见，如图6D所示的由修复单元68执行的事件统称 为用于采用上下文快照的窗口重试分组首标解压缩的例程、如例程 76。这种命名描述来自修复单元68可执行的另一个可能的例程、例 如重试缓冲分组的首标的解压缩的例程78的例程76，稍后进行描述。
因此，首标解压缩器46(1)执行例如前面作为结合分组首标解压 缩的失序分组处理的第一方面的事件。因此，首标解压缩器46(1)维 护上下文快照的滑动窗口，窗口中的各项只包含一个短暂上下文快 照。已存储快照反映上下文的状态，如它在丢失分组的时间(序列中 的孔)已经进行的那样(应当已经被接收，并且还可被认为经过重新排 序)。对于在流中的分组的序列中丢失的每个(或者一组连续的)分组， 在滑动窗口中插入一项。首标压缩算法的健壮特性将把这个丢失分 组当作分组丢失，直到它最终被接收为止。当没有维护这样一种滑 动窗口时，以在ROHC的情况中超过大约一个的深度被重新排序的 分组不会被解压缩。
滑动窗口的大小优选地等于解压缩器可处理的重新排序深度。 在一个示例实现中，窗口的大小可基于链路的带宽-延迟乘积。滑动 窗口中最旧的项是可处理的最大重新排序深度。后续项可根据最旧 的参考作为增量编码存储在滑动窗口中。
修复单元68通过假定解压缩失败的分组被重新排序(即失序)， 以一种示例模式进行操作。修复单元68在滑动窗口中查找可用来重 试失败分组的解压缩的最可能的适当窗口项(上下文快照)。查找最可 能的适当窗口项可取决于或基于分组序列号，或者可包括滑动窗口74 中的所有上下文快照。修复单元68逐个采用来自滑动窗口74的一 组上下文快照来重试失败的分组的解压缩。如果对于上下文窗口的 正好一项解压缩成功进行，则修复单元68认为解压缩成功。否则， 尝试修复为失败。在执行修复过程中，滑动窗口被更新，以便使其 大小保持为对应于重新排序深度。
采用滑动窗口的失序分组的解压缩成功率的估算
作为一种操作模式，能够采用失序分组的首标解压缩器46(1)来 估算解压缩成功率。下面进行的是这种估算的推导，其中，表1表 示推导中采用的符号。
表1：用于成功率估算推导的符号   符号   定义   Pr(item)   对于采用窗口项item(包括具有残留误差的首标)的解压   缩尝试，CRC检验成功的概率   Prrepair(item)   对应于窗口项item的重新排序分组的解压缩将成功(没   有包括具有残留误差的首标)的概率 bits(field)   压缩首标中的字段field的位的数量 x   对应于失序接收的分组的窗口项 xi   窗口项的序列号 c_ref   窗口中最旧的上下文参考(xi＝x0) delta(c_ref)i  对于对应于xi的窗口项保存的最旧的上下文参考之间的   差异 wnd_depth   窗口可处理的重新排序深度 cnt_wnd   其中各项包含对应于没有接收到的分组的序列号的短暂   上下文状态的窗口
结合此推导，以下考虑事项适用：
-Pr(xi)＝1/2^y，其中，y是CRC(CRC-y)的位的数量，i！＝0
-Pr(xi)对于各项之间不存在相关性(完全随机数据)时给出-但情 况不是这样，因此实际上Pr(xi)甚至会更小。
-xi是大小为x+1项的窗口中的项，iE[0，x]。
现在查询在窗口中将存在不止一个值的概率Prepair(xo)，从而知 道窗口大小至少与链路的重新排序深度一样大。窗口中的各项xi具 有错误地解释为正确值的P(xi)概率，其中始终存在唯一的值(xo)已知 为正确值(即P(xo)＝1)。因此，设Prepair(xo)是从窗口中保存的多个j 值项中对重新排序分组xo正确解压缩的概率(其中，wnd_size是每个 重新排序深度的链路损耗/重新排序率)：
${\mathrm{Pr}}_{\mathrm{repair}}\left(x\right)=\mathrm{Pr}\left(x\right)-\underset{j=1}{\overset{\mathrm{wnd}\_\mathrm{depth}}{\Sigma }}\mathrm{Pr}\left(x_j\right)$ 等式1a
${\mathrm{Pr}}_{\mathrm{repair}}\left(x\right)=1-\frac{(\mathrm{wnd}\_\mathrm{depth}-1)}{\frac{1}{2}\mathrm{bits}\left(\mathrm{CRC}\right)}$ 等式1b
等式1产生表2：
                       表2

对于每种情况，以上值假定100％的业务量采用CRC-3或CRC- 7中的一个而不是某个组合。假定在某种情况中，90％的分组是PT-0 或PT-1(CRC-3)，以及10％是PT-2(CRC-7)，则Prepair(xo)由等式2 给出。
${{\mathrm{Pr}}_{\mathrm{repair}}\left(x\right)}^{\prime }=\mathrm{\Sigma weight}\left(\mathrm{bits}\left(\mathrm{CRC}\right)\right)*{\mathrm{Pr}}_{\mathrm{repair}}(x,\mathrm{bits}\left(\mathrm{CRC}\right))$ 等式2
等式2产生表3：
表3 损失/重新排序率(％) 权(3)(％) 权(7)(％) Prrepair(x)’ 1 90 10 1 (1) 5 90 10 0.53 (0.81) 10 90 10 0.08 (0.60)
在推导中，还存在SN位的数量的影响，即，这在SN位的数量 产生实际值超出LsB解释间隔之外的这样一种小p时是有效的。
上下文快照的滑动窗口的存储器要求的确定
现在考虑上下文窗口的总的解压缩器存储器要求。为了维护上 下文的滑动窗口，代价是解压缩器希望对其处理重新排序的各上下 文标识符(CD)的一个额外上下文大小加上来自从序列中丢失的各分 组的这个上下文的每个增量的小量，如等式4所示。
$\mathrm{sizeof}\left(\mathrm{wnd}\right)=\underset{i=0}{\overset{\mathrm{acid}}{\Sigma }}[\mathrm{sizeof}\left(\mathrm{contexti}\right)+\underset{j=1}{\overset{\mathrm{wnd}\_\mathrm{depth}}{\Sigma }}\mathrm{sizeof}\left(\mathrm{delta}\left(\mathrm{contexti}\right)j\right)]$
                                         等式4
上下文标识符(CID)标识压缩器流，并将其关联到上下文。这是 需要的，因为在相同的压缩器与解压缩器对之间可能压缩许多不同 的流。CID无法与图7所示的xi位置相关。正是排序信息、通常是SN 字段与图7所示的xi位置相关。在等式4中，acid是活动cid，以及 wnd_depth是插入率(每个窗口大小的项的平均数量)。对于ROHC， 参数Max_CID是acid的上限。最坏情况是当sizeof(delta(context))为 动态字段的大小时。
首标解压缩采用假定重新排序分组(一旦首次解压缩失败)的LSB 编码SN位(采用rohc符号)来查找(估计)窗口中的正确的上下文参考。 如前面所述，在某些模式中，不一定始终需要尝试所有参考。LSB 编码使LSB位的可能值的窗口保持一致。只有一个值在窗口中是可 能的。但是，通过分组(例如失序的分组)的重新排序，LSB位可能对 应于被压缩器认为是旧的并丢弃的值(即窗口向前移动)。因此，首先 采用LSB窗口中的值来尝试解压缩。如果失败并且解压缩器了解重 新排序可能已经发生，则可对解压缩尝试“更旧的”值。
用于缓冲分组的修复的重试解压缩
根据其配置和操作的第二独立且不同的方面，首标解压缩器还 对失序分组执行辅助修复过程。图9说明其中可有利地采用第二方 面及辅助修复过程的情况。
在图9中，圆圈指示符A表示以下事实：作为连续分组x1-x6的 丢失的可能结果，没有接收到重要的上下文更新。由于没有接收到 重要的上下文更新，在丢失分组x1-x6之后接收的分组遇到解压缩失 败，如图9中的圆圈指示符B所示。
对于这样一种情况，并根据如图8A和图8B所示的本文所述的 第二方面，首标解压缩器46(2)的失序分组处理器54(2)包括辅助修复 过程80，以及修复单元68(2)除了例程76之外，还包括用于重试缓 冲分组的首标的解压缩的例程78。
图8C说明由失序分组处理器54(2)除了第一方面执行的步骤(参 照图6C所述)之外根据第二方面执行的基本步骤。作为事件8C-1， 首标解压缩器46(2)确定首标解压缩对于在流中预计的分组的未收到 之后所接收的预定数量的分组是否失败(例如，图9中的圆圈指示符 B所示的事件实际上是否发生)。这种首标解压缩失败可能产生于以 下事实：未收到的分组的一个或多个可能已携带有意义的上下文更 新信息，没有这种信息时，首标解压缩器导致“上下文损坏”。如 果是这样的话，则作为事件8C-2，首标解压缩器46(2)采用辅助修复 过程80来存储在未收到之后所接收的并且首标解压缩失败的分组(例 如“缓冲分组”)。执行失败的分组的这种存储或缓冲，希望在它能 够恢复丢失的上下文更新信息时，修复单元68(2)可采用这种丢失的 上下文更新信息来执行缓冲分组的后续修复。解压缩失败的分组的 这种存储或缓冲如图9中的圆圈指示符C所示。
然后，如事件8C-3以及图9中的圆圈指示符D、E和F所示， 如果首标解压缩器46(2)尝试采用多个已存储快照之一获得后来接收 的分组的解压缩(采用如先前结合第一方面所述的用于利用上下文快 照的窗口重试分组首标解压缩的例程76)。如果后来接收的分组的重 试解压缩采用上下文快照之一是成功的，则作为事件8C-4以及如图 9中的圆圈指示符G所示，实现首标解压缩的首标解压缩上下文信 息的快照被更新并且(例如通过辅助修复过程)用于重试已存储(缓冲) 分组的首标解压缩。
在第二方面，采用多个已存储快照之一实现后来接收的分组的 解压缩的恢复在两个示例情况中是可行的。在第一种这样的情况中， 对已缓冲分组解压缩所需的上下文更新信息是被延迟并且仅在检测 到上下文损坏之后才由首标解压缩器接收的失序分组(当作后来接收 的分组处理)。在第二种这样的情况中，对已缓冲的分组解压缩所需 的上下文更新信息通过另一个分组(当作后来接收的分组处理)中的重 传来获得，如下面结合第三方面所述。
图8A说明根据第二方面的首标解压缩器46(2)的示例结构和/或 功能单元。首标解压缩器46(2)及其关联的失序分组处理器54(2)包括 与先前针对图6A的首标解压缩器46(1)所述的相同实体以及另外还 包括例如辅助修复过程80和管理相对于分组缓冲器84的最初不可 解压缩分组的存储、检索及删除的缓冲管理器82之类的其它这类实 体。由于分组缓冲器84中存储的分组最初表现为不可解压缩的事实， 分组缓冲器84又称作“问题”分组缓冲器。如上所述，首标解压缩 器46(2)的修复单元68(2)不仅包括用于采用上下文快照的窗口来重试 分组首标解压缩的例程76，而且还包括用于重试缓冲分组的首标的 解压缩的例程78。
图8B更详细地说明除已经示出以及先前参照图6B所述的那些 之外的首标解压缩器46(2)的失序分组处理器54(2)的功能方面以及其 间传送的各种通信或信号。与图6B共有的图8B的方面、事件和信 号可通过图6B的论述了解，因而不再赘述。同样在图8B中，如同 图6B那样，各实体以功能项、例如作为过程或例程来表示。图8B 所示的新包含的功能性之中的要素是辅助修复过程80和缓冲管理器 82的那些功能性。
辅助修复过程80执行的基本动作和事件如图8E所示。例如， 图8E表明，作为事件8E-1，辅助修复过程80监测被解压缩的分组 的定序的历史。为了进行这种操作，辅助修复过程80定期与序列分 析器64进行通信(经由信号S-13)，以便确定已经接收到什么序列号 以及丢失了什么预计序列号。
作为事件8E-2，辅助修复过程80还监测由分组首标解压缩器62 作为信号S-5发送的首标解压缩失败的通知。当记录了多个这类首标 解压缩失败、例如图9中的圆圈指示符B所示的重复首标解压缩失 败时，作为事件8E-3，辅助修复过程80确定上下文是否可能已被损 坏。如果存在上下文损坏的概率，则作为事件8E-4，辅助修复过程80 请求缓冲管理器82缓冲其首标刚才解压缩失败的分组。信号S-14表 示辅助修复过程80向缓冲管理器82发送缓冲失败分组的指令。然 后，作为事件8E-5，辅助修复过程80向修复单元68(2)发送设置上 下文损坏指示符。在被“设置”时，上下文损坏指示符通知修复单 元68(2)关于怀疑上下文损坏以及辅助修复过程80正缓冲首标解压缩 失败的分组的情况。设置上下文损坏指示符的发送由信号S-15表示。 然后，作为事件8E-6，辅助修复过程80把信号S-5的失败事件通知 传递给修复单元68(2)。
如果作为事件8E-3确定上下文损坏不可能，则作为事件8E-7， 辅助修复过程80会清除或“复位”上下文损坏指示符，并且会发送 与信号S-16相同的信号。另外，结合事件8E-6，辅助修复过程80 把信号S-5的解压缩失败事件通知传递给修复单元68(2)。类似地， 如果作为事件8E-2确定没有重复的失败，则清除或“复位”的上下 文损坏指示符以及信号S-5的解压缩失败事件通知被发送给修复单元 68(2)。
首标解压缩器46(2)的修复单元68(2)按照基本上与先前所述相同 的方式来执行例程76(用于采用上下文快照的窗口来重试分组首标解 压缩)，并且还结合首标解压缩的第二方面来执行用于重试缓冲分组 的首标的解压缩的例程78。除了例程76的先前所述的事件之外，图 8D还表示例程78的附加事件，下面进行论述。
用于重试缓冲分组的首标的解压缩的例程78的论述以图8D的 事件R-5继续进行，例如在例程76已经采用窗口存储器72中存储 的上下文快照之一对分组首标成功解压缩之后。在进行这种操作之 后，作为事件R-6，例程78检查上下文损坏指示符是“设置”(以及 由此表明辅助修复过程80已经缓冲一个或多个失败的分组)还是“复 位”。作为事件R-7，例程78的上下文损坏指示符被保持，并根据 作为信号S-15从辅助修复过程80发送的“设置”上下文损坏指示符 或者作为信号S-16从辅助修复过程80发送的“复位”上下文损坏指 示符的事件R-1上的接收和处理来更新。如果上下文损坏指示符已 复位，则作为事件R-8，修复单元68(2)完成其执行的这个具体示例。
另一方面，如果在事件R-6确定辅助修复过程80已经确定并传 递关于发生上下文损坏的情况，则作为事件R-9，例程78指导窗口 管理器66(经由信号S-18)来更新窗口存储器72中的成功使用的上下 文快照。然后。作为事件R-10，例程78能够从分组缓冲器84中取 出缓冲分组。相应地，例程78向缓冲管理器82发送缓冲器取信号 S-19。缓冲管理器82通过得到分组缓冲器84中的所有分组(全部是 先前首标解压缩失败的)并向修复单元68(2)的例程78作为信号S-20 返回那些分组来进行响应。
从分组缓冲器84中得到解压缩失败的分组之后，作为事件R-11， 例程78采用对分组解压缩时最近成功的上下文快照来重试所有缓冲 分组、如packet1至packetlast的首标解压缩。图8D表示例程78每次 一个地以信号S-21向分组首标解压缩器62发送每个这样的分组、如 packetj。对于发送给分组首标解压缩器62进行重试首标解压缩的每 个分组，分组首标解压缩器62返回结果信号S-22。作为事件R-12， 例程78分析每个packeti的结果信号S-22，以便确定重试首标解压缩 是否成功。如果分组首标由例程78成功地解压缩，则作为事件R-13， 修复单元68(2)的例程78把成功首标解压缩的分组发送给缓冲管理器 48(经由信号S-23)，以便存储在解压缩分组缓冲器49中(参见图5)。 另外，作为事件R-5的一部分，作为信号S-24，修复单元68向序列 分析器64发送已修复分组的序列号。另外，修复单元68(2)向缓冲管 理器82发送信号S-25，以便从分组缓冲器84中删除成功首标解压 缩的分组。
如果分组首标由例程78不成功地解压缩，则作为事件R-14，修 复单元68(2)必须判定从分组缓冲器84中丢弃(删除)有问题的分组还 是在可进行关于分组实际丢失的更明确的确定之前把该分组保留在 分组缓冲器84中。图8D经由信号S-26表示修复单元68(2)指导缓 冲管理器82从分组缓冲器84中丢弃或删除仍然有问题的分组。
作为事件R-15，例程78确定是否已经采用成功的上下文快照对 分组缓冲器84中的所有分组重试首标解压缩。如果已经对分组缓冲 器84中的所有分组重试首标解压缩，则例程78完成其执行示例， 如事件R-16所示。否则，其余缓冲分组的重试首标解压缩继续进行。
因此，在结合首标解压缩处理失序分组的第二方面，首标解压 缩器46(2)保持参考、如上下文快照的滑动窗口，如第一方面那样。 首标解压缩器46(2)缓冲(例如在分组缓冲器84中)解压缩失败的分 组。缓冲在以下假设下进行：当解压缩在一个或多个连续分组遇到 丢失之后对于多个分组重复失败时，如果没有接收到有效更新，则 可能发生了上下文损坏。有效更新是SN位的编码的健壮属性以及相 对那个字段、如半静态字段或者没有经常改变的字段所建立的函数 没有覆盖的更新。它还可能是表示SN字段和/或为其建立基于SN的 函数的字段(即时标(TS)、JP标识符(IP-ID))中的实质跳跃的更新。在 这种情况中，首标解压缩器46(2)假定丢失的分组因重新排序而延迟， 并且这导致重复失败。还假定，解压缩失败的分组还可能失败，因 为它本身被重新排序，在这种情况中，调用以上参照例程76所述的 基于窗口的修复。如果基于窗口的修复对于某个分组成功进行，则 首标解压缩器46(2)(在滑动窗口中)更新用于对该分组解压缩的上下 文项，然后重试已更新窗口项可能适用于的缓冲项的解压缩。如果 一个或多个缓冲项的修复成功进行，则采用基于窗口的修复解压缩 的重新排序的分组很可能被正确地解压缩。另一方面，如果修复失 败，则缓冲项可丢弃。
涉及图9，在圆圈指示符D、E和F中成功地解压缩的分组是对 于解压缩重复失败、即在上下文被损坏之后所接收的分组失序到达 的分组。这个分组包含把上下文更新到适宜于对先前解压缩失败的 分组正确解压缩的状态的必需信息。注意，如果缓冲分组的解压缩 成功进行，则这提供关于重新排序的分组采用正确参考也被正确地 解压缩的更大保证。
图10说明由窗口管理器66结合首标解压缩器46(2)执行的基本 的示例操作。这些示例操作中的许多也适用于结合首标解压缩器46(1) 的窗口管理器66的操作。作为事件10-1，窗口管理器66处理任何 通知或接口通信。例如，如果窗口管理器66获得来自序列分析器64 关于最近接收的分组的解压缩首标的序列号是失序的指示，则作为 事件10-2，窗口管理器66从最后上下文快照存储器63中获得最后 上下文快照，然后作为事件10-3，把最后上下文快照存储在窗口存 储器72中正确的位置。另一方面，当窗口管理器66接收到来自修 复单元68的例程76的设置取请求(例如信号S-6)时，作为事件10- 4，窗口管理器66从窗口存储器72中取出并返回适当的快照集合(设 置取响应例如是信号S-7)。
作为事件10-5，窗口管理器66例如通过适当地清除特定快照 来更新窗口存储器72。如上所述，滑动上下文窗口74具有指定大小 (例如带宽和延迟之积)，使得当较新的条目进入滑动上下文窗口74 的输入端时，其中最旧的条目移出到滑动上下文窗口74的排出端。 因此，事件10-5管理从滑动上下文窗口74中的最旧快照的清除， 结果是，循环到滑动上下文窗口74的排出端的任何快照被认为与作 为不能挽回的分组丢失的孔相关联。类似地，如果滑动上下文窗口74 中的快照成功地用于对分组解压缩，并且此后确定成功使用的快照 不是依次连续的(例如根据序列号)，其中在分组接收时具有另一个孔 (例如不是与滑动上下文窗口74中的另一个快照相邻)，则也可从窗 口存储器72中清除成功使用的快照。可发生成功使用的快照的清除， 因为不存在可能具有取决于被清除快照的上下文信息的上下文信息 的相邻快照。另外，根据需要，窗口管理器66执行用于控制滑动窗 口74的确定大小的事件10-6以及用于控制内容通过滑动窗口滑动 或移动的事件10-7。
采用解压缩器触发的压缩器重传的上下文损坏的有选择修复
图11一般说明其配置和操作的第三独立且不同的方面，在其中， 当失序分组处理器54(3)无法对一个或多个分组首标解压缩时，远程 单元40(3)产生并向首标压缩器24(3)发送表示首标解压缩器46(3)遇 到或者可能遇到解压缩困难(例如解压缩失败)的事实的通知85。
作为第三方面的第一示例实现，图11A和图12A说明一个示例 实施例，在其中，在首标解压缩器46(3A)对分组首标解压缩失败时， 首标解压缩器46(3)对首标压缩器25(3A)产生关于流中预计的分组的 未收到的事实的通知85A。在这方面，图11A表示首标解压缩器46(3) 配备了产生通知85A的解压缩失败单元/例程70(3)。因此，图11A 所示的通知采取带内反馈通知85A的示例形式。
作为第三方面的第一示例实现，图11B和图12B说明一个示例 实施例，在其中，链路层处理86识别如分组接收失败之类的事件， 并向对应的链路层处理28发送链路层通知85B。对应的链路层处理 28则通知首标压缩器25(3B)实际、预计或预期的分组解压缩困难， 如箭头87所示。
图12A和图12B分别说明图11A和图11B所示的首标解压缩器 46(3A)和首标解压缩器46(3B)的两个示例实现。在图12A的首标解 压缩器46(3)中，解压缩失败单元/例程70(3A)包括重传请求器87。 或者，在图12B的首标解压缩器46(3B)中，解压缩失败单元/例程70(3B) 可以可选地包括重传请求器87(如虚线所示)，但是图12B的实施例 包含图11B的链路层通知。
图11A和图12A的实施例的反馈通知85A以及图11B和图12B 的实施例的链路层通知85B均用于触发从首标压缩器25(3)的分组的 有选择重传。因此，如这两个备选实现所反映的，压缩器有选择重 传可能是或者从链路层到压缩器25(3)的例如发生若干丢失的通知(采 用链路层丢失通知85B)或者解压缩器重传请求、例如反馈(采用重传 请求器87)的结果。
图11A的实施例的首标解压缩器46(3A)采用的修复过程或者图 11B的实施例的首标解压缩器46(3B)采用的修复过程可能是仅采用 例程76的图6D的修复过程或者是除了采用例程76之外还采用例程 78(用于重试缓冲分组的首标的解压缩)的图8D的修复过程。无论首 标解压缩器46(3)采取具有其重传请求器87的图12A的形式还是具 有其链路层丢失通知85B的图12B的形式或者其它任何形式，情况 就是这样。
解压缩失败单元/例程70(3A)执行的基本示例事件或动作如图 12C所示。解压缩失败单元/例程70(3A)的动作作为事件12C-1发起， 它是来自重试解压缩的修复单元68的无法修复通知(例如信号S-21) 的接收和处理。在接收到这种无法修复通知时，作为事件12C-2，解 压缩失败单元/例程70(3A)(从序列分析器64)取其首标被成功解压缩 的最后分组的序列号。其首标被成功解压缩的最后分组的序列号的 取出在图12C中由信号S-27表示，而来自序列分析器64的反馈或 者其它有关序列号的咨询如信号S-28所示。事件12C-3表示解压缩 失败单元/例程70(3A)在经由反馈通知85A(参见图11A)提供给首标 压缩器25(3A)的失败通知中包括其首标被成功解压缩的最后分组的 序列号。
根据这个第三方面，在图11A或者图11B的实现模式中，首标 解压缩器46(3)触发压缩器有选择地重发上下文更新分组。上下文更 新分组的重发通过来自链路层的失败通知(例如采用链路层通知85B) 来触发，或者响应来自解压缩器的否定确认85A(例如采用重传请求 器87)而触发。如参照图12C所述，这种反馈通常包含最后成功解压 缩的分组的序列号。
为了重传正确的压缩分组，压缩器25(3)维护实质上相当于解压 缩器滑动窗口74的压缩器滑动上下文窗口90。滑动上下文窗口74 和压缩器滑动上下文窗口90的相似性和相关性质如图11中的虚线 箭头92所示。
图11以及图11A和图11B表示首标压缩器25(3)维护压缩器滑 动上下文窗口90。压缩器滑动上下文窗口90中的各项包括或包含已 经发送给远程单元40的一个压缩首标。并非首标压缩器25(3)产生的 所有压缩首标都需要包含在压缩器滑动上下文窗口90中。一定包含 在压缩器滑动上下文窗口90中的压缩首标是用于更新上下文的一个 或多个字段(不同于有关对于序列号(SN)所建立的函数的字段)的那些 压缩首标。具体来说，插入压缩器滑动上下文窗口90中的压缩首标 是更新除了SN、IP-ID或RTP时标(TS)字段之外的字段的那些压缩 首标。用于更新对于序列号(SN)所建立的函数的压缩首标也可被插入 压缩器滑动上下文窗口90。
如同首标解压缩器46(3)维护的滑动上下文窗口74那样，压缩器 滑动上下文窗口90的窗口大小等于压缩器25(3)可处理的重新排序深 度。类似地，驻留在压缩器滑动上下文窗口90中的最旧项是可处理 的最大重新排序深度。与滑动上下文窗口74的大小相似，压缩器滑 动上下文窗口90的大小可基于链路带宽-延迟乘积。
图12D说明首标压缩器25(3)在接收到来自首标解压缩器46(3)、 例如来自重传请求器87或者链路层86或者其它任何这种修复失败 通知器的反馈通知85时所执行的基本动作或事件。当首标压缩器25(3) 作为事件12D-1确定接收到反馈通知85时，作为事件12D-2，首标 压缩器25(3)获得反馈通知85中包含的序列号。反馈通知85中包含 的序列号应当是其首标由首标解压缩器46(3)成功地解压缩的最后分 组的序列号。然后，作为事件12D-3，首标压缩器25(3)从其压缩器 滑动上下文窗口90中获得允许首标解压缩器46(3)修复上下文的信 息。这个信息通常涉及来自压缩器滑动上下文窗口90的、在序列中 具有比反馈通知85中接收的序列号更高的序列号的压缩首标的一项 或多项。作为事件12D-4，首标压缩器25(3)在分组中把上下文修复 信息(例如压缩器滑动上下文窗口90中具有更高序列号的一个或两个 快照)传送给远程单元40。
由首标压缩器25(6)进行的更高序列号的分组的重传在高丢失和/ 或重新排序率(例如失序率)的情况中对于解压缩器可能是有用的。在 丢失的情况中，更少的分组将会丢失。在重新排序的情况中，在接 收到延迟分组之前无法被解压缩的分组可更快地被解压缩，假定重 传优于通过链路的延迟分组(它在可能的时候具有低发生概率)。另 外，首标压缩器25(3)在接收到来自解压缩器的反馈时应当执行相同 的修复动作(降低某些分组的压缩)，即，这个逻辑是相加而不是替换。
有关重新排序的对解压缩器的通知
根据其配置和操作的第四独立且不同的方面，图13和图14说 明首标解压缩器46(4)，它按照传送给远程单元40(4)的一个或多个窗 口参数为多个已存储快照临时分配可再用存储器。在图13和图14 所示的实例中，远程单元40经由链路层接收与滑动上下文窗口74 将是需要或者有用的可能时间有关的通知，并通知窗口管理器66的 窗口分配过程92分配窗口存储器72中必要的存储单元。图13具体 表示(通过链路层消息94)网络侧的链路层28通知远程单元40中的链 路层处理86对分配窗口存储器72的需要，以及链路层处理86向窗 口分配过程92转发窗口分配指示和信息(经由信号96)。
为了反映窗口存储器72可根据这个第四方面临时分配的事实， 滑动上下文窗口74如图13和图14中的虚线所示。
在滑动窗口分配消息(例如链路层消息94)中传送的参数可表示以 下一项或多项(优选地为以下全部)：其中存储多个已存储快照的可再 用存储器的大小；分配用于存储多个已存储快照的可再用存储器的 时间；对用于存储多个已存储快照的可再用存储器解除分配的时间。
根据这个第四方面，首标解压缩器仅有选择地、例如在由窗口 参数表明的时间对于滑动窗口存储器施加附加存储器和处理要求。 有利的是，利用这个第四方面，为滑动窗口存储器分配的存储单元 可临时分配，或者在没有调用或预计修复过程时使用。用于调用或 预计首标解压缩器的修复过程的时间、因而滑动窗口存储器的分配 可能包括各种类型的转接和切换，或者当分组可能倾向于失序或者 倾向于丢失的其它任何时间或时间段。这类时间可通过测量来确定 或者通过历史(似然)信息来预测。
因此，链路层或其它网络功能可通知解压缩器关于正发生或者 可能要发生重新排序(或者丢失率可能增加)的时间段。通知应当包 括：关于时间段开始(start_event)的信息；关于时间段结束(start_stop) 的信息；重新排序深度(depth)的程度。当接收到start_event通知时， 解压缩器则可开始采用完整参考来填充大小为depth的窗口，并且当 分组在序列中丢失时采用新的项逐渐对它填充，以便在分组解压缩 失败时执行基于窗口的修复。解压缩器还可缓冲在执行基于窗口的 修复之后仍然解压缩失败的分组，以便稍后在重新排序的分组被成 功解压缩时尝试基于缓冲器的修复。
这个第四方面使得仅在可能发生重新排序(或增加丢失)时才需要 附加存储器和处理要求。例如当转接发生时或者当链路质量下降时 -从而导致更高的FER和/或更多链路层重传，这个信号可能是相关 的。这可提供存储器节省，因为解压缩器可能不希望一直保存上下 文的历史-仅在有用时才保存。
大家会理解，虽然在示例实现中把窗口存储器72和分组缓冲器 84说明为处于分开的存储器中，但情况无需是这样。实际上，窗口 存储器72以及分组缓冲器84在被使用时可在相同存储装置中具有 相应位置。这种存储装置可采取若干形式的任一种，包括随机存取 存储器(RAM)或半导体存储器，仅列举两种非穷举实例。
在示例实现中，远程终端是通过空中接口接收分组(具有压缩首 标)的用户设备单元。如上所述，其它形式或远程单元是可行的。当 远程终端采取用户设备单元的形式时，首标优选地采用U/O模式的 健壮首标压缩(ROHC)来压缩，但也可采用例如SigComp之类的其它 技术来压缩。例如在下列文献(通过引用将它们全部完整地结合到本 文中)中描述了SigComp：Price，R.等人，“信令压缩(SigComp)”， RFC3320，因特网工程任务组，2002年12月；Hannu，H.等人，“信 令压缩(SigComp)-扩展操作”，RFC3321，因特网工程任务组，2002 年12月；美国专利公布US2004/0047301。首标解压缩器通常通过无 法采用循环冗余校验(CRC)或者传输层校验和对后来接收的分组检验 首标解压缩，来确定首标解压缩失败(例如对于后来接收的分组)。
表示具体单元、功能性和信号的以上提供的更详细的说明性实 施例不是约束、强制或限制性的，而只是用作示例实现。
上述网络的实现的非限制示例环境是例如图15A所示之类的电 信网络100。示例电信网络100包括无线电接入网110和核心网112。 核心网112表示为包括电路交换域113和分组交换域114。在具体说 明的实例中，电路交换域113(例如，面向PSTN/ISDN连接的网络) 表示为包括移动交换中心(MSC)/来访位置寄存器节点115和网关 MSC节点116。分组交换域114以示例方式表示为包括通用分组无 线电业务(GPRS)服务(SGSN)节点117，它连接到网关通用分组无线 电业务(GPRS)支持节点(GGSN)118。
网关GPRS支持节点(GGSN)118向分组交换网络(例如因特网、 X.25外部网络)提供接口，因而用于转换数据格式、信令协议和地址 信息，以便允许不同网络之间的通信。在服务GPRS支持节点 (SGSN)117提供对SGSN服务区的分组路由选择，并且服务于物理 上位于SGSN服务区内的GPRS订户。在服务GPRS支持节点 (SGSN)117对用户设备单元提供诸如鉴权、加密、移动性管理、计 费数据和逻辑链路管理之类的功能。GPRS订户可根据位置由网络中 的任何SGSN提供服务。在服务GPRS支持节点(SGSN)117和网关 GRPS支持节点(GGSN)118的功能性可结合到相同节点中，或者可存 在于分开的节点中，如图15A所示。
在图15A的实施例中，核心网节点112的通用分组无线电业务 (GPRS)服务(SGSN)节点117还表示为包括首标压缩器25-15A。首 标压缩器25-15A的结构和操作基本上与先前所述的一般的典型首 标压缩器25相似。
核心网112通过虚线122所示的无线电接入网接口连接到无线 电接入网110。无线电接入网110包括一个或多个控制节点126和一 个或多个无线电基站(BS)128。在其中无线电接入网110为UMTS地 面无线电接入网(UTRAN)的示例的非限制性实现中，虚线122所示 的无线电接入网接口称作Iu接口，以及控制节点126采取无线电网 络控制器(RNC)的形式。本领域的技术人员了解无线电网络控制节点 126的功能和组成，例如分集切换单元、控制器和各种接口。在无线 电接入网110的其它实现中，控制节点126可具有其它名称，例如 基站控制器(BSC)、无线电网络控制节点等。在任何情况中，应当理 解，为了简洁起见，图15A的无线电接入网110仅采用一个控制节 点126来表示，其中控制节点126连接到两个基站(BS)128。如本领 域的技术人员理解的那样，无线电接入网110通常具有可通过未示 出接口(例如Iur接口)连接的许多控制节点126。
同样为了简洁起见，只有两个基站节点128表示为连接到代表 性控制节点126。大家会理解，不同数量的基站128可由各控制节点 126提供服务，以及控制节点126无需服务于相同数量的基站。此外， 本领域的技术人员还会理解，基站在本领域有时又称作无线电基站、 节点B或者B节点。
简言之，在随后的论述中假定各基站128服务于一个小区。但 是，本领域的技术人员会理解，基站可用于通过不止一个小区的空 中接口进行通信。例如，两个小区可利用位于相同基站站点上的资 源。此外，各小区可分为一个或多个扇区，其中的各扇区具有一个 或多个小区/载波。
远程单元140通过无线电或空中接口138与一个或多个小区或 者一个或多个基站(BS)128进行通信。在不同的实现中，远程单元140 可能由不同名称表示，例如远程终端、无线终端或无线单元、移动 台或MS、移动终端或MT或者用户设备单元(UE)。毫无疑问，虽然 为了便于说明，在图15A中仅示出一个远程单元140，但是各基站 通常服务于许多远程单元。
在上述示例UMTS实现中，无线电接入优选地基于宽带码分多 址(WCDMA)，其中的各无线电信道采用CDMA扩频码来分配。当 然也可采用其它接入方法。
远程单元140具有首标解压缩器25-15A，它包含失序分组处 理器54。远程单元140和首标解压缩器的结构和操作例如可能是如 结合各方面的任一个在上面描述的具有其关联失序分组处理器54的 首标解压缩器的任一个。远程单元140的其它未示出组件、包括组 成部分收发信机、协议栈、解码器、缓冲器等的结构和操作是本领 域的技术人员了解的。
在图15B的实施例中，网关通用分组无线电业务(GPRS)支持节 点(GGSN)118表示为包括首标压缩器25-15B来代替SGSN 117上 所包含的。首标压缩器25-15B的结构和操作基本上与先前所述的 相似。
在图15C的实施例中，无线电网络控制器节点126表示为包括 首标压缩器25-15C来代替核心网节点之一。首标压缩器25-15C 的结构和操作基本上与先前所述的一般的代表性首标压缩器25相 似。
虽然诸如图15A、图15B和图14C所示的之类的节点具有无数 其它元件和功能性，但是如本领域的技术人员了解的那样，本文所 述的只是对于说明本文所述的上下文信息传送技术是必要或者有帮 助的那些元件和功能性。
应当注意，甚至一般术语“首标压缩”、“首标压缩器”和“(首 标)解压缩器”用来表示这个概念的适用性不限于任何特定的首标压 缩方案。这特别适用于大多数ROHC协议子集，包括但不限于 ROHC-TCP(0x0006)、ROHC RTP(0x0001)、UDP(0x0002)、IP(0x0004)、 ESP(0x0003)、UDP-Lite(0x0008)、RTP/UDP-Lite(0x0007)首标压缩协 议子集。提出的解决方案的一部分还具有不要求对ROHC标准的任 一个的任何改变的优点。
还应当理解，本文所述的首标解压缩技术和其它活动不需要如 本文说明和/或描述的那样在同样结构化的节点或终端上执行。相反， 各种功能可分布或分散到其它节点或装置或者甚至网络(例如核心网 和无线电接入网)。此外，必要时，甚至首标压缩功能也可分布于多 个节点和/或装置。
例如根据以上所述，本文所使用的术语“网络节点”表示本文 所述的完整或部分执行上下文信息传送控制的任何节点或单元或者 节点或单元的一部分。
此外，包括首标压缩器25的节点或装置可能是或者可能不是位 于远离接收实体的不止一个节点或网络接口。例如，本文关于上下 文信息通过空中或无线电接口发送给接收实体(例如远程单元40)的提 法不要求首标压缩器25位于邻接无线电接口的节点或位置中。
虽然结合目前认为是最可行且优选的实施例对本发明进行了说 明，但是要理解，本发明不限于所公开的实施例，相反，它意在涵 盖各种修改及等效方案。