专利名称：远程通信网络中的数据包压缩及加密方法、节点与装置的制作方法
技术领域：
1/
本发明涉及远程通信中的数据包的处理，包括但不限于在远程通 信中执行诸如数据包的加密与压缩的操作。
背景技术：
2/
诸如远程通信系统等连网系统一般;故分为多层。例如，国际标准 化组织(ISO)已经开发了开放系统互联(OSI)连网模型(也称为 OSI七层^t型)，并在OSI 7498中作了描述。七层OSI^^莫型(如图 38所示)分层(从底层即第一层到顶层即第七层)如下物理层、数 据链路层(即"链路"层)、网络层、传输层、会话层、表示层以及 应用层。(原文)说明书中所用的"model layer (模型层)"与Model layer (模型层)相当或类似，不管使用这种模型层的网络技术规范是 否明确涉及OSI模型。在每一模型层内，每一层的功能可以由一个或 多个实体或者功能来执行。例如，在这种意义上，在每一才莫型层内可 以存在诸如压缩功能层、加密功能层以及校验和功能层等各种功能 层。
3/
由于互联网的巨大成功，将网际协议(IP)使用于各种各样的链 路已成为具有挑战性的任务。IP协议使用IP包，IP包一般具有净载 荷净载荷载运实质性的用户数据的净载荷以及在IP包的起始位置通 常添加的"净艮头"。报头一般载运有助于处理穿过OSI才莫型的一层或 多层的IP数据包的信息。
4/由于IP协议的报头相当大，将IP协议应用于窄带链路例如如蜂
窝链路往往并不简单易行。例如，考虑由用于IP语音(VoIP: voice-over-IP)的协议(IP， UDP， RTP)传送的普通语音数据，其中 报头可占据包的大约70%，这导致该链路的使用效率很低。
A.报头压缩概述
6/
^Jc压缩是使诸如语音业务与视频业务等无线IP业务经济上可 行的重要因素。报头压缩(HC)这一术语涵盖在点对点链路上使载运 在基于每跳(per-hop )的报头中的信息所用的必要带宽最小化的技术。 报头压缩解决方案已经被正TF的鲁棒报头压縮(ROHC )工作组开发 来改善这类业务的效率。
7/
一般而言，报头压缩方法在互联网社区已使用了超过十年；现有 几个常用的协议，例如RFC 1144 (Van Jacobson的(f在裙效遽声/f遂 濬^ 7U尸/7尸孩关》(Van Jacobson, Cowpm^/"g 7U尸/7尸/or 丄cw-S/ eed Seha/丄/"fe, IETF RFC 1144， IETF Network Working Group, February 1990) ) 、 RFC 2507 (Mikael Deg飄ark、 Bj加Nordgren、 Stephen Pink 的《/尸孩兴在裙》 (Mikael Degermark,Bj6rn Nordgren,Stephen Pink; IP ifeacfer C画pms^/ow,正TF RFC 2507, IETF Network Working Group, February 1999 ))以及RFC 2508 ( Steven Casner、 Van Jacobson的《在裙瓶遽声/f链廖W /P/T/D尸/^r尸孩兴》 (Steven Casner,Van Jacobson, C謂/ ms^'"g /尸/t/ZXP/Rr尸//eo^r /or 丄ow-S/ ee(i Sen'a/IETF RFC 2508, IETF Network Working Group, February 1999))。 8/
报头压缩利用这样的事实，即报头中的 一 些字段在流中不作改 变，或者以小的和/或可预测的值进行改变。才艮头压缩方案利用这些特 征，仅在最初发送静态信息，而变化字段用其绝对值或作为差值从包 发送到包。至于完全随机的信息，则必须以不做任何压缩的形式发送。报头压缩通常表征为两个状态机间的交互作用， 一个状态机^i 缩器而另一状态机是解压缩器，每个状态机保持一些与在上下文中^皮 压缩的流相关的信息。
10/
压缩上下文包含并保持关于过去包的相关信息，并用这种信息来 压缩与解压缩后续包。如2001年4月的IETF RFC 3095中Carsten Borma皿等人的《#举孩关在裙"(9/^义'蕃头。与四,錄々(profiles ), "7P、 UD尸、五S尸及采在裙》(Carsten Borma皿，et al.尺0ZmW T^ora^ Cow/^esw'ow (K(9/7C」Fra/wewor6 /owr / ro力/e&' i 7P， L^D尸，五S尸 W2cpre^e6/. IETF RFC 3095, April 2001 )所述 压缩器的上下文是用来压缩"^艮头的状态。解压缩器的上下文是用 来解压缩才艮头的状态。在清楚使用哪一个时，这二者中的任一个 或这二者的结合通常^^皮称为"上下文"。上下文含有来自包数据 流中的先前报头的相关信息，比如静态字段和用于压缩与解压缩 的可能的基准值。此外，描述包数据流的附加信息也是上下文的 组成部分，例如关于IP标识符字段如何变化和关于典型的包与 包之间序号或时间标记增加的信息。 11/
保持压缩器状态与解压缩器状态(称为上下文)相互一致同时保 持报头开销尽可能低是具有挑战性的任务。有一个状态机用作压缩 器，并有一个状态机用作解压缩器。压缩器状态机直接影响压缩效率 的高低，因为它是用于控制要发送的已压缩包类型的选择的逻辑的重 要组成部分；解压缩状态机的作用主要是提供用于反馈(如果可用) 的逻辑并识别可尝试进行解压缩的包类型。
12/
给解压缩器提供方法来验证成功解压缩成功的包是上下文更新 包。由于解压缩可以^皮;^睑，所以这种类型的包可以更新上下文。对 于ROHC，上下文更新包类型在其格式内携带循环冗余码(CRC);这是在原始未压缩报头上计算出的校验和。该CRC被用来检验每个 包的解压缩成功；验证成功时，该上下文可^皮更新。 13/
依赖其它方法来保证解压缩成功的包，即没有给解压缩器提供方 法来验证成功解压缩成功的包格式的包，该包是独立包，只携带自身 的解压缩所需的信息，则该包。这些包不更新上下文。
14/
报头压缩使用序号来唯一标识各个包。在报头压缩中，通常基于 序号(SN)的功能来压缩字段。既可以从协议中导出这种处于压缩的 序号(例如，RTPSN),也可以由压缩器产生这种序号。在本文中， 当二者之间的区别不相关时，这种序号称为主序号(MSN)。
15/
早期报头压缩协约(header compression profile )的设计使用如下 假设压缩器与解压缩器间的信道不对报头压缩包重排序，且要求该 信道保持用于每个已压缩流的包排序。这一假设的动因是最初考虑使 用RoHC的潜在候选的信道保证包的按序递交；这种4叚设有助于改善 压缩效率与包丟失容限(tolerance against packet loss)，这两项目标在 当时被列为最高要求。
16/
除了其它改进，当前正在开发的RoHCv2协约将处理压缩协议内 的压缩端点之间的不按次序的递交以及编码方法本身。 17/
许多不同类型的压缩可以在链路层以上使用。这些压缩包括净载 荷压缩(例如参见Pereira R.的(T炎^ D五FL/4r五^/尸净裁V芽在裙》 (Pereira R., /尸勿/ood C呻固/ow 《潔凡v4r五，正TF RFC 2394, December 1998 );以及Friend R.与R. Monsour的(f犮^丄ZS W/尸净 ^f"在^^iK Friend R. et R. Monsour, /尸Pay/oad Cow; resw'ow L^/wg丄ZS, 正TFRFC 2395, December 1998))、信令压缩(例如参见Price R.等 人的(T/,令在裙f57gC;7,》(Price, R. et al., 57g a〃/"g Co，ms^/o"「&gOw^人IETF RFC 3320, January 2003 ))、报头去除与再造以及报 头压缩。例如，关于报头压缩参见Van Jacobson的(f在裙效遽声/f遂 濬^ JU尸/7尸孩兴》(Van Jacobson, Com户m^,力g rOY/尸//eat/era /or 丄mv-5^e^&ha/丄z'"fo, IETF RFC 1 144,正TF Network Working Group. February 1990 ) ; Mikael Degermark、 Bj。rn Nordgren、 Stephen Pink 等人的W尸孩关在/,i( Mikael Degermark, Bj6rn Nordgren, St印hen Pink; IP Header Compression, IETF RFC 2507, IETF Network Working Group, February 1999 ) ; Steven Casner与Van Jacobson的(f在裙瓶遽声/f"链 潜^/尸/M)尸/R:r尸孩关》(Steven Casner, Van Jacobson， Co^^e^mg //yWIP/RTP 丄cw-5^ed Ser/a/丄/"&; IETF RFC 2508, IETF
Network Working Group, February 1999 ) ; Koren T.、 Casner S.、 Geevarghese J.、 Thompson B.及P. Ruddy等人的(Ty^;f/^^延、逸^ ^ ^# ##^#^^^^^^^7^ fO r尸J》(Koren T., Casner S., Geevarghese J., Thompson B. and P, Ruddy, 5"/ 朋cet/ Co，ms^e<i WZ!P fC7^7P」ybr Zj力A:s wz'A De/a乂尸ac&C丄<95^ "eonien力g， IETF
RFC 3545, IETF Network Working Group, July 2003 ); Carsten Bormann 等人的《#举孩关在^ ;蕃籴与四,錄^; "7P、 [/D尸、
及采在裙》 (Carsten Bormann， et al.//e"<ier Co，ms^o" fK(9//C」Fn^mewoA^: a"<i /owr prq/ /e5v i r尸，[/D尸，五573 wwc麵/ ms^e(i. IETF RFC 3095, April 2001 ) ; Jonsson L.与 G. Pelletier 的《###关在裙"C^C ; /尸W在裙鈔为》(Jonsson L. and G. Pelletier, A。Z w对//ea射C謂/ m^/ow (KO/7C」J co，mw/o" pra力/e /or IP,正TF RFC 3843, June 2004) ; Pelletier G.的(T,^兽拔关在裙 "Of/Cj .' ^于"D尸扁丄"e (Pelletier G., 7/e<ara^
Cow; m^/ow fK(9/7Q):尸ra/ /es /or "D尸-丄"e, IETF RFC 4019, April 2005 );以及Pelletier G.、 Sandlund K.与L. Jonsson等人的 兴在裙y>;rOV/尸、/"femd ,黄f迷/f哞",(Pelletier, G., Sandlund, K. and L. Jonsson.//ea^fer Co附;^es57o" fKO//C」爿 i^"o力/e or 7UiV/P, T/^e/T " Drq/ fWorA /" /^ogres". <draft- ietf一rohc國tcp-1 l.txt>, January 2006)。这些压缩类型的任一类型可祐二没计成使用序 号与校验和。 18/
也可以使用其它最优化(如其它类型的压缩)来进一步增强带宽 受限系统的性能。
B.才艮头压缩检验
20/
鲁棒报头压缩使用在已压缩报头(例如，在初始化包内)上或者 在未压缩报头(例如，在已压缩包中)上算出的校验和(CRC)。使 用校验和来验证解压缩器上的正确的解压缩。更具体地说，例如，报 头压缩通常使用校验和来验证其解压缩尝试的结果。该校验和可以是
对于正被压缩的信息的未压缩状态计算的校验和，或者也可以是对于 发送于压缩器与解压缩器之间的信息(已压缩信息、未压缩信息或压 缩协议信息或这三种信息的任意组合中的任一种信息)计算的校验 和。
21/
同样，通常在解密进程前使用帧校验和序列(FCS)，以确保没
有向解密算法递交的信息能够导致不正确的加密上下文。 22/
未检测出的残差可能导致丢失对以上讨论的任何功能的同步，这 取决于所使用的算法。 23/
报头压缩可以使用安全基准原理来确保不能由于包丟失而失去 压缩器与解压缩器间的上下文同步。基于解压缩器所收到的应答，压 缩器确信解压缩器已经成功地从上下文更新包中更新了上下文。然 而，以安全基准原理使用的大多数包类型是独立，因此按理不应该更 新上下文。
24/
压缩器通常只在接收到来自于解压缩器的用于上下文更新包(用反々贵消息中的MSN来标识)的应答后才更新其压缩上下文。 25/
解压缩器通常在检验解压缩的结果后用已压缩^^艮头(若出现在包 格式中，则在用安全基准原理操作时不一定真实)内携带的循环冗余 校验(CRC)来更新其上下文。受到速率限制，解压缩器通常向压缩 器应答更新。
C.安全/加密
27/
使用新的体系结构模型的演进与设计倾向于减少传输路径包含 的节点数，并倾向于使用公开标准化的接口。这转而又改进了功能间 的传统分离，也创建了新的对于安全性的可信模型。尽管互联网范例 中安全性一般被视为通信主机之间的端到端功能，但安全机制也常设 置在较低模型层中以解决低级安全问题。
28/
就安全性而言，包数据流的加密通常要求发送端与接收端保持加 密状态信息。该信息一般被称为加密上下文。 29/
加密密钥可以是这种上下文的组成部分，例如加密转换可以直接 使用一个"会话"密钥，而另一个"主，，密钥可用来导出该会话密钥。 该主密钥通常由密钥管理协议以安全方式给出。在上下文中可找到的 其它参数往往是例如加密算法标识符、会话指示符、计数符、密钥长 度参数等。这些参数中的许多参数专用于有效密码转换。
30/
有些算法可基于与包关联的排序信息导出用于包的会话密钥。例 如，安全实时基准协议(SRTP)(参见图l)基于包内携带的RTP 序号来导出该包的索引。SRTP是OSI应用层协议，预定用来在向使 用RTP/RTCP协议的实时应用程序提供端对端的安全层，如图2所示。 例如，SRTP在Baugher M.等人的《安全《##/诊錄议"i r尸J》 (Baugher M. et al., 7T7e Secwre Wea/-"we rra"5"/ oW Pratoco/ f57 ZP」,IETF RFC 3711， March 2004)中有描述。文中肯定了对密钥索引的导 出存在限制，因为正确值的导出与加密上下文的更新对于大的包重排 序敏感也对残留比特错误敏感。虽然所述的重排序量达到215个包的 次序且不太可能出现，但这突显了所存在的未检测到的比特错误对于 安全层的可能影响，在安全层中错误的包可在错误的时间间隔中用索 引错误地更新加密上下文，并破坏后续包的解密。 31/
这些算法保持这种排序信息作为加密上下文的组成部分，因此， 对该信息的正确索引与更新在加密端点之间必须是鲁棒的。为了使用 正确的解密密钥，必须知道完全正确的排序。与使用RoHC的报头压 缩的情况相反，绝大多数时候加密上下文在没有任意形式的操作成功 检验的情况下纟皮更新。这通常需要鲁棒机制来确保排序被正确地维 持。在SRTP中可找到关于这样的加密转换和一旦获知会话密钥这些 加密转换如何，执行加密与解密的示例。
32/
加密功能于是要求已加密包的接收次序与这些包的发送次序相 同，或者至少可以导出这种信息，以拾取正确的解密密钥。否则，已 加密数据将不被正确地解密，且加密上下文将成为不同步，因而将错 误传播给后续包。
D:压缩同步
34/
图3示出了用安全基准原理进行工作的压缩器(上部)与解压缩 器(下部)的典型例子。随着时间推移交换已压缩包(时序轴)，并 跟随具体事件更新安全基准(SN) LSB滑窗。要注意滑窗在某些时刻 可以包含一个以上的值，但是始终只存在一个用于特定字段的压缩与 解压缩的安全基准。
35/
压缩同位体(peers )的目标是始终与用于特定包的压缩/解压缩的 某个基准保持同步。具体而言，下述各项适用且在图3中被反映 解压缩器只能检验上下文更新包(可更新安全基准的包)的 成功解压缩。
*解压缩器不能检验独立包(不更新安全基准的包)的成功解 压缩。
*当收到来自解压缩器的应答时，压缩器更新其安全基准滑窗。 从滑窗中移走先前的基准(应答的和/或未应答的)，只有最 新应答的那个基准被保留为安全基准。
*当收到其LSB比先前的包少的包时，解压缩器更新其安全基 准滑窗，这表明已经用该解压缩器先前已应答的基准作了压 缩。只有其应答被发送的最新基准于是^皮保留为安全基准。
36/
对应于使用该"优化方法"时的当前技术水平，压缩器总是更新 其上下文。这是因为被发送的所有包都包含未压缩报头的计算出的校 验和。这种校验和被解压缩器用来检验解压缩进程的结果。若验证成 功，解压缩器就更新其上下文。
37/
对应于更新加密上下文的当前技术水平，通常使用在解密包时所 见的最高序号，也使用翻转计数符(roll-over counter)及其他参数， 来为所处理的每个包更新加密上下文。当在链路上载运排序信息与其 他加密信息时，加密上下文更新通常严重依赖于按序递交的保证、很 低的残留比特错误概率；加密上下文更新通常没有办法来检验解密进 程的结果。
E:无线接入网络概述
39/
在典型的蜂窝无线系统中，无线用户设备(UE)经由无线接入网 络(RAN)与一个或多个核心网络进行通信。无线用户设备(UE)可 以是诸如移动电话("蜂窝"电话)与带有移动终端的笔记本电脑的 移动台，因此，无线用户设备单元可以是使用无线接入网络进行语音 和/或数据通信的诸如便携式的、袖珍的、手持的、内置于计算机的或车载的移动设备。作为选择，该无线用户设备单元也可以是诸如无线 本地环路的组成部分等的固定蜂窝设备/终端的固定无线设备。
40/
无线接入网络(RAN)覆盖被划分为小区的地理区域，基站服务 于各个小区。小区是由在基站站点处的无线基站设备提供的无线覆盖 范围的地理区域。各个小区由唯一的身4分码标识，该身份码在小区内 广播。基站在基站覆盖范围内通过空气接口 (如射频)与用户设备(UE) 进行通信。在无线接入网络中，若干基站一般连接(例如，通过地面 线或微波)到无线网络控制器(RNC )。有时也称为基站控制器(BSC ) 的无线网络控制器监督并协调多个与其连接的基站的各种工作。无线 网络控制器一般连接到 一个或多个核心网络。
41/
无线接入网络的一个示例是通用移动电信系统(UMTS)地面无 线接入网络(UTRAN) 。 UMTS是第三代系统，其某些方面建立在 被认为是在欧洲开发的全球移动通信系统(GSM)的无线接入技术上。 UTRAN本质是向用户设备(UE)提供宽带码分多址的无线接入网络。 第三代合作伙伴计划(3GPP )已承诺进一步发展UTRAN与基于GSM 的无线接入网络技术。
42/
该核心网络有两个业务领域，RNC具有与这两个业务领域的接 口。通用移动电信系统(UMTS)地面无线接入网络(UTRAN)包括 电路交换连接与包交换连接。就此而言，在UTRAN中，电路交换连 接包括与移动交换中心(MSC)进行通信的无线网络控制器(RNC)， 该中心又连接到面向连接的外部核心网络，该网络可以是(例如)公 共交换电话网(PSTN)和/或组合业务数字网(ISDN)。另一方面， 在UTRAN中，包交换连接包括与服务GPRS支持节点(SGSN)进 行通信的无线网络控制器，服务GPRS支持节点，该接点又通过骨干 网络与网关GPRS支持节点(GGSN)连接到包交换网络(例如，互 联网，X.25外部网络)。43/
在UTRAN中有几个受关注的接口。无线网络控制器(RNC)与 核心网络之间的接口被称为"Iu"接口。无线网络控制器(RNC)与 其基站(BS)之间的接口被称为"Iub"接口。用户接口 (UE)与基 站(BS)之间的接口被称为"空气接口"或"射频接口"或"Uu接 n，，。
44/
图4示出了传统体系结构的示例，这里示出的是使用UTRAN体 系结构的范例。在UTRAN体系结构中尤为受关注的是功能之间的分 为不同节点的传统分离当无损重定位;故支持(可选)时RNC处理 排序，因而增加了用于一个序号的开销。加密在节点B (NodeB)内 进行，且加密要求各SDU按序递交以维持加密上下文。为了确保该 加密不释》文(loose)同步，通常使用L2帧校验和序列(FCS)，增
加用以在空气4^ 口上传输的额外的八位组。 45/
混合ARQ (Hybrid-ARQ)机制要求在各个码组的传输期间可靠 地检测比特错误，因为它必须为RLCPDU检测传输失败以请求重传。 因此，々i定H-ARQ之后的残留误码率(BER)很低。
F.系统演进概述
47/
第三代合作伙伴计划(3GPP)也正在制定第三代小区系统的长期 发展，以满足例如对于更高的用户比特率的需求。在2006年9月， 3GPP最终完成了被称为演进的UTRA与UTRAN的研究项目。该项 研究的目标是对将来3GPP接入技术的长期发展(LTE)加以定义。 还进行了用于系统体系结构演进(SAE)的研究，该项研究的目标是 开发一个将3GPP系统发展成具有更高数据速率、更低等待时间、包 优化的支持多种无线接入技术的系统的框架。
48/
演进UTRAN包括演进基站节点，例如演进节点B即eNB,演进基站节点向用户设备(UE)提供演进UTRA用户平面(U-plane)与 控制平面(C-plane)协议终端。如图5所示，eNB主持以下功能(1) 用于无线资源管理(例如，无线承载控制、无线允许进入控制)、连 接移动性控制、动态资源分配(调度)的功能；(2)包括例如向eNB 分配寻呼消息的移动性管理实体(MME); (3)用户平面实体(UPE), 其中包括用户数据流的IP报头压縮与加密、寻呼原因(paging reasons ) 的U平面包端接以及支持UE移动性的U平面交换。 49/
eNB节点通过X2接口相互连接。eNB节点也通过S1节点连接到 演进包核心(EPC ) 。 Sl接口支持包核心中的接入网关(aGW)与eNB 节点之间的多对多(many-to-many)联系。Sl接口提供对用于用户平 面与控制平面业务量的传输的演进RAN无线资源的接入。Sl基准点 使MME与UPE分离能够进行，也能够实施组合的MME与UPE解
决方案。 50/
如图5所示，在SAE/LTE体系结构的当前建议中特别受关注的 是RNC的去除。RNC节点的去除导致这样的事实，即加密功能与主 持报头压缩功能的PDCP功能现在被设置在同一节点中，例如在aGW 中或在eNB节点。加密功能与PDCP功能都端接到另一端的用户设备 (UE)中。换句话说，aGW与eNB节点之间的接口被认为是不可信 的。不可信意味着eNB节点可能在物理上受损。eNB节点通常处于远 端位置，且如果eNB节点受损，那么大量的用户信息就有可能被盗用。 因而Sl接口要求将加密应用到用户业务，再向UE传播。Sl接口上 的安全隧道不解决eNB节点的信用问题。 51/
一个关于在加密和/或PDCP实体之间的重排序的问题是Sl接口 或空气接口 (H-ARQ)可能会(当PDCP处于aGW中时)产生未排 序的包。由于加密要求准确的排序信息，所以必须在空气接口上维持 或传输用于排序的额外开销。在要支持无损的再定位的情况下，也可以在PDCP中要求额外的排序开销。 52/
图6表示一例关于PCDP功能与SAE/LTE体系结构的第三方建 议。在SAE/LTE体系结构中，PDCP功能也可设在eNB节点中，这 种情况下也涉及同样的问题。
G.多个独立功能层
54/
如前所述，在各个才莫型层内可以存在分为分离的多个独立功能层 的功能分层。在冲莫型层内形成多个功能层会产生相当大的开销。在传 统技术中这是必需的，因为功能经常被分到不同物理节点，如以上简 述的演进UTRAN (E-UTRAN)体系结构的示例中的情况一样。
55/
考虑到常规的分层技术，并针对模型层2加密与当前的 E-UTRAN/SAE/LTE体系结构，各个分层功能(例如加密)使用其本 身的单独机制来维持排序并执行加密，可能与诸如报头压缩等其它功 能无关地与PDCP排序相配合。为了确保维持正确的加密上下文， H-ARQ协议上的残留误差检测通常是必需的；这也与其它层的潜在检 -验才几制无关。
56/
寺艮头压缩方面的当前技术水平是RoHC,参见Carsten Bormann等 人的《##/屋关在^ "OZ/C入'蕃菜与四个鈔为.'尺7P、 f/D尸、￡^尸 及^在裙》 (Carsten Bormann, et al. i (9ZmW //eo<ier Cpms^/o/ (T^/fQ): Fra膨衡rA: 朋d /ot/r / ra,w W7!P, W>P, ￡^尸 朋(i w"com/ m^e<i. IETF RFC 3095, April 2001 ),也参见Pelletier G.、 Sandlund K.及L, Jonsson等人的《##^关在裙蕃束,/"&m"莩黄f遽 /;f ,》 (Pelletier G., Sandlund K. and L. Jonsson, T/2e i o/ 耐//eac/er
<draft-ietf-rohc-rfc3095bis-framework-00.txt>, December 2005 ) 。 RoHC 目前使用其自己的序号和其自己的校验和。RoHC也同样适用于依靠模型层2的排序与校验和的当前技术水平的加密。目前RoHC不处理 重排序，但正在致力于该技术的开发。就对这种想法表示关注的加密 类型而言，代表当前技术水平的是SRTP;但是，SRTP工作于OSI 应用层且不与报头压缩结合。 57/
考虑到常规的分层技术，加密使用其自己的独立机制来维持排 序，加密可能与同报头压缩无关的PDCP排序相结合，且在加密中要 求在H-ARQ协议上检测残留误差以确保从用于加密进程的加密上下 文中鲁棒地选择/导出会话密钥，且加密与"^艮头压缩功能无关。加密与 报头压缩一直被相互独立地处理。 一个可能原因是有些功能往往作用 在连接(例如，加密、重排序)上，除了来自该层自身的请求(例如， 基于QoS的请求)，独立于且不易察觉到它们在处理并向其它层转发 的不同的流，如图7所例示。
58/
图8以示例方式"^兌明当前处理的问题。即使在LTE/SAE典型系 统中，甚至在同一节点内的功能分层也会导致显著开销。对于下层的 开销，下面的表l示出了层2功能与对应的开销(以八位组为单位)。
59/
表1
* 层2 FCS : 3-4八位组(处理比特错误)
* 层2 (加密)2八位组(重排序+加密密钥)
攀层2 PDCP SN : 2八位组(无损的重定位-PDCP序号SeaNum PDU) 总开销 7+八位组
60/
因此，本发明的目标在于提供用以减少与才莫型层2的功能(例如， 链路层功能)关联的开销的一个或多个节点、装置、系统、方法或技 术。
发明内容
61/
一种操作包括发送节点与接收节点的远程通信网络的方法包括， 在发送节点处对包的报头部分的至少 一部分执行压缩并对包的至少 一部分执行解密，从而使该压缩与该加密结合到在接收节点处的包的 解压缩验证与解密确认相互依存的程度。
62/
在其一种形态中，本技术涉及使用组合或共享的事务处理与/共享 业务的压缩上下文与加密上下文的组合管理。在本形态的第一例方式 中，组合或共享的事务处理与/共享业务包括对将纟皮压缩的包的至少一 部分并对将纟皮加密的包的一部分确定复合校验和。在本形态的第二例 方式中，组合的事务处理包括用序号作为共享信息的压缩功能与加密 功能，该序号由加密功能为导出会话密钥而使用。此外，在第二例方 式中，对将被压缩的包的至少一部分并(可选地)对将被加密的包的 至少一部分计算校验和。在这两种方式中，校验和有助于压缩操作与 加密操作的验证。
63/
在第一方式中，对于在发送节点处的进入包，对进入包的压缩候 选部分与加密候选净载荷部分确定初始校验和。该初始校验和;波包含 在一个至少部分已压缩且至少部分已加密的接口穿越包中。其后，在 接收节点处收到接口穿越包时，执行解密与解压缩以获得复原包。对 复原包确定验证校验和，并通过该验证校验和与初始校验和的比较来
确定解密与解压缩这二者的验证。 64/
在第二方式中，对于在发送节点处的进入包，对进入包的压缩候 选部分确定初始冲交,验和。该压缩候选部分包括;故包含在初始校,睑和中 的序号。该序号包含在一个至少部分已压缩且至少部分已加密的接口 穿越包中。其后，在接收节点处收到接口穿越包时获得该序号。在执 行解密与解压缩以获得复原包后，对复原包确定验证校验和。通过该验证校验和与初始校验和的比较来确定解压缩的验证。
65/
在其一种形态中，本技术涉及安全(例如，可加密的)报头压缩。 例如，该形态包括一种操作包括发送节点与接收节点的远程通信网络 的方法。该方法包括，对于在发送节点处的进入包，除具有^艮头压缩 信道信息的报头的字段外加密已压缩报头，并在接口穿越包中包含已 加密的已压缩报头。该方法还包括，对于在接收节点处接收的接口穿 越包，从具有报头压缩信道信息的报头的字段获得信息，并解密接口 穿越包的已压缩报头。
66/
在其一种形态中，本技术的共享事务处理和/或共享业务是共享信 息，诸如共享序号。换句话说，在本技术的这种形态中， 一功能层使 用来自于另一功能层的排序信息。基本上，由加密和/或报头压缩和/ 或净载荷压缩和/或信令压缩中的任意一个使用的排序信息从另 一进 程导出，该另 一进程是力。密和/或报头压缩和/或净载荷压缩和/或信令 压缩和/或用于包的按次序传递中的任意另 一个。
67/
在序号共享的第一方式中，报头压缩器首先压缩包的报头，然后 向加密进程移交其序号。加密进程用该序号来导出会话密钥，并用加 密处理该包。
68/
在序号共享的第二方式中，加密(密码)功能使序号可用，其次
加密功能(在其加密操作中)将把该序号用于报头压缩器。报头压缩 器用该序号作为它的MSN并压缩该包，并将该已压缩包交给加密进 程。然后加密进程用该同一序号来导出会话密钥，并进行加密处理。 如果适用，则该排序信息被载运在加密协议内。 69/
因此，在文中所述的共享事务处理和/或共享业务技术的一种形态 中， 一个层(如链路层)代表多个功能层(例如，加密和/或净载荷压缩和/或报头压缩)载运排序信息与校验和，所述多个功能层在相同端 点内运行并共享同一信息。作为另一形态，至少部分地共同处理加密 与才艮头压缩，以给加密进程的会话密钥导出算法提供在压缩/加密端点 之间的重排序与包丟失上的鲁棒性。而且，为了使加密密钥导出的选 择更鲁棒，在"^艮头压缩的上下文管理的协作下进行加密上下文管理。
70/
文中所述的本技术也包括基于RoHC排序在l艮头压缩协议内部引 入安全功能(例如，加密)，并鲁棒且无开销地实现该安全功能。例 如，本技术包括将加密上下文管理功能结合到协约的报头压缩上下文 管理的现有机制。此外，本技术包括基于RoHC并为该信道上的所有 协议引入安全功能(加密与鉴权)以完全地保护报头压缩信道。本技 术还包括用于RoHC的相对完全的安全解决方案。
71/
在以下参照附图阐述的优选实施例的更具体的描述中，本发明前 述的及其它的目标、特征和优势显而易见，附图中的附图标记指示遍 及不同视图的相同部分。附图不必一定依比例画出，其重点在于阐述
本发明的原理上。 72/
图1 ;^i兌明SRTP密钥的示例导出的示意图。 73/
图2是说明安全实时传输协议(SRTP)的示意图。 74/
图3是说明在3GPP TR 25.813中定义的体系框架的具体示例的使 用中涉及的特定问题的示意图。 75/
图4是这里用UTRAN体系结构示例的常规无线接入网络(RAN) 体系结构的示意图，示出了分层开销。76/
图5是说明用于系统体系结构演进/长期演进(SAE/LTE)的体 系结构的功能分离的示意图。 77/
图6是说明关于PDCP功能与SAT/LTE体系结构的示例第三方 建议的示意图。 78/
图7是说明带校验和、加密及压缩的分层方法的示意图。 79/
图8是说明在远程通信网络中未解决的分层开销问题的示意图。 80/
图9A是远程通信网络的示意图，其中，节点的第一功能与第二 功能使用一般的共享事务处理和/或共享业务来减少包开销。 81/
图9B是远程通信网络的示意图，其中，同一模型层的但分配到 包括单一发送节点的多个节点的第 一功能与第二功能使用 一般的共 享事务处理和/或共享业务来减少包开销。
82/
图10是远程通信网络的示意图，其中，提供并配置链路层协议 来执行第一功能、第二功能与共享事务处理。 83/
图11是远程通信网络的示意图，其中，共享事务处理和/或共享 业务包括由节点的多个功能使用的共享信息。 84/
图12是远程通信网络的示意图，其中，共享事务处理和/或共享
业务包括由压缩功能起始的序号。 85/
图13是远程通信网络的示意图，其中，共享事务处理和/或共享 业务包括由加密功能起始的序号。86/
图14是远程通信网络的示意图，其中，共享事务处理和/或共享 业务包括不但对包的第二部分执行操作而且对包的第 一部分执行操 作的第二功能，所述包至少部分地受到第一功能的4喿作。
87/
图15是远程通信网络的示意图，其中，共享事务处理和/或共享 业务包括对包的一部分执行操作的加密功能，所述包至少部分地受到 压缩。
88/
图16是远程通信网络的示意图，其中，共享事务处理和/或共享
业务包括确定共享校验和。 89/
图17是远程通信网络的示意图，其中，共享事务处理和/或共享 业务包括对于包的报头的至少 一部分并对于包的净载荷的至少 一部 分确定校验和。
90/
图18是远程通信网络的示意图，其中，共享事务处理和/或共享 业务包括对于包的第一部分(例如，包的^R头)的至少一部分确定校 验和，该至少一部分包含在对该包的第二部分的操作中由第二功能使 用的参数。
91/
图19是说明说明所述动作或事件压缩上下文与加密上下文的组 合管理的第一例方式中涉及的作为示例的基本的、代表性的动作或事 件的流程图。
92/
图20是说明在图19的第一方式的示例实施方案中的发送节点处 执行的示例动作的流程图。 93/
图21表示与图20的动作对应的包描述。94/
图22是说明在图19的第一方式的示例实施方案中的接收节点处 执行的示例动作的流程图。 95/
图23表示与图22的动作对应的包描述。 96/
图24是说明压缩上下文与加密上下文的组合管理的第二例方式 中涉及的作为示例的基本的、代表性的动作或事件的流程图。 97/
图25是说明在图24的第二方式的示例实施方案的发送节点处执 行的示例动作的流程图。 98/
图26表示与图25的动作对应的包描述。 99/
图27是说明在图24的第二方式的示例实施方案的接收节点处执 行的示例动作的流程图。 100/
图28表示与图27的动作对应的包描述。 101/
图29是说明作为示例的非限制性动作或事件的流程图，所述动 作或事件可在具有其压缩报头的加密的包的示例准备方式中执行。 102/
图30是对应于图29的各种动作描述当包在压缩与加密操作中演 变时的包内容的流程图。 103/
图31是说明作为示例的、非限制性的、可在处理其压缩^^头已 作加密的被接收包的示例方式中执行的动作或事件的流程图。 104/
图32是对应于图29的各种动作描述当包在压缩与加密操作中演变时的包内容的流程图。
105/
图33表示基于RoHC的示范实施例。 106/
图34是将加密与压缩的常规分离跟组合或合并的压缩进程和加 密进程进行对比的示意图。 107/
图35是说明对于发送节点与接收节点执行的动作或事件的顺序 的示意图，所述发送节点与接收节点具有组合和合并的压缩进程与加 密进程，其中序号由压缩进程与加密进程共享。
108/
图36是说明具有组合或合并的压缩进程与加密进程的发送节点 中涉及的动作或事件的流程图，其中序号一皮共享。 109/
图37是说明具有组合或合并的压缩进程与加密进程的接收节点 中涉及的动作或事件的流程图，其中序号^皮共享。 110/
图38是七层OSI层模型的示意图。
具体实施方式
111/
在以下的描述中，出于说明而非限制的目的，阐明了诸如特定的 体系结构、接口、技术等的具体细节，以提供对本发明的彻底理解。 然而，本领域技术人员清楚本发明可以应用到与这些具体细节不同的 其它实施方案中。即，本领域技术人员能够设计出各种包含本发明的 原理以及本发明的要旨与范围内的装置，即使所述装置没有在这里明 示。在一些实例中，省略了对众所周知的设备、电路与方法的详细描 述，以免因非必需的细节而使本发明的描述不清晰。这里描述本发明 的原理、形态与实施方式及本发明的具体实施例的所有陈述有意于包200780013146.8 括其结构上与功能上的等同者。此外，确定这样的等同者既包括目前 已知的等同者又包括在未来将开发的等同者，例如，可执行同一功能 而不管其结构如何的任何;波开发的单元。
112/
因此，例如，本领域技术人员可以理解方框图在这里可以表示体 现本技术原理的说明性电路的概念图。同样，也可以理解任意流程图、 状态置换图、伪代码等代表各种进程，所述进程可以;波大致表示在计 算机易读媒体中，因此可以被计算机或处理器执行，无论这种计算机
或处理器是否被明确示出。 113/
通过使用专用硬件及能够执行与适当软件相关联的软件，可以提 供包括被标示或描述为"处理器"或"控制器"的功能模块的各种器 件的功能。当由处理器提供时，可以由单个专用处理器或多个单独的 处理器提供这些功能，其中的一些功能可以是共享的或分布式的。而 且，明确使用术语"处理器"或"控制器"不应被解释成排它地指能 够执行软件的硬件，而是可以非限制地包括数字信号处理(DSP)硬 件、用于存储软件的只读存储器(ROM)、随机存取存储器(RAM) 以及非易失性存储器。
1.0:多个功能共享的事务处理
115/
图9A示出了远程通信网络的两个节点20、 22,这两个节点通过 点划线24表示的接口进行通信。在图9A所示的特定情形中，节点 20 U送节点而节点22是接收节点。这种发送节点与接收节点的指 定参照包流的图示方向，其中从包源26获得的包被送到发送节点20。 送到发送节点20的包由发送节点20处理，然后通过接口 24向接收 节点22发送。可以理解包流也可以沿相反方向从接收节点22向发送 节点20传播，但是出于描述本技术的显著形态之目的，考虑从发送 节点向接收节点22的单向包流已足够。
116/节点20包括第一功能30与第二功能32,前者用来对由节点20 处理的包的第一部分执行第 一操作，后者用来对该包的第二部分执行 第二操作。第一功能30与第二功能32可处于同一^t型层内，且可以 被分别认为是同一模型层的不同功能层。例如，第一功能30可以被 认为是在特定才莫型层内的第一功能层，而第二功能32可以被认为是 在该特定模型层内的第二功能层。文中所使用的任何非模型层的"层" 应被理解为是功能层。
117/
虽然属于不同的功能层(可能在同一^^莫型层内)，但是第一功能 30与第二功能32配置成可使用共享事务处理和/或共享业务34来执 行对包的操作。依靠共享事务处理和/或共享业务34，在执行第一操 作与第二操作之后，通过了接口 24的包具有比要是在第一操作与第 二操作的执行中不使用该共享事务处理和/或共享业务34的开销少
的、归于第一功能与第二功能的开销。 118/
图9A还示出接收节点22包括发送节点20的相似功能，或者也 许更准确地说，发送节点20的所选功能的逆。例如，接收节点22包 括第二功能的逆40与第一功能的逆42。此外，以与发送节点20的共 享事务处理和/或共享业务34相关的方式，接收节点22具有共享事务 处理和/或共享业务44,它们可以是在发送节点20处使用的共享事务 处理和/或共享业务34的逆类型事务处理。
119/
在图9A中以非限制的方式对共享事务处理和/或共享业务34进 行了一般阐述。在下文中描述了关于共享事务处理技术的各种示例形 态的共享事务处理和/或共享业务的具体的、有代表性的、非限制性的 实施例。例如，没有一个示例共享事务处理和/或共享业务将^皮当成排 它的或有限制的，所提供的这几个示例并不是穷举的，对它们的详述 仅是为了提供对功能可以怎样被诸如共享事务处理的技术至少部分 地组合或合并的更宽泛的理解。这里所用的术语"共享事务处理"应被理解为包括共享事务处理与共享业务二者或者包括共享事务处理 与共享业务之一。
120/
还应理解诸如这里描述的发送节点20与接收节点22的节点一般 具有许多功能，多于这里具体描述的功能，且这种节点不限于如在这 种节点中包含的所说明的两个功能，或者事实上不限于功能的任何特 定数量与性质。例如，在一个非限制的示例实施方案中，发送节点20 可以是系统体系结构演进/长期演进(SAE/LTE)远程通信网络的接 入网关(aGW)或者演进节点B (eNB)，同样在其它实施方案中发 送节点20可以包含图8所示的示例功能。在SAE/LTE实施方案中， 接口 24可以代表一个或多个(成组的)接口，诸如Sl接口与Uu(空 气)接口。
121/
而且，在图10所述的示例实施方案中，设有并配置链路层协议 46来执行第一功能30、第二功能32与共享事务处理34。在其它实施 方案中，这些功能不需要全部由该链路层协议执行或主持。
122/
为简明起见，图9A与图10示出包括第一功能30与第二功能32 的作为单一节点的发送节点20。然而，这里所用的术语"节点"，尤 其H送节点，涵盖具有参与到共享事务处理技术中的功能的多个节 点。换句话说，其中使用共享事务处理技术的发送节点不必是无需为 单一节点，而可以包括多个节点，在所述多个节点上可以分配多重功 能(例如，第一功能30与第二功能32)。例如，图9B将发送节点 20显示为包括两个物理上截然不同的节点20 (1)与20 (2)的节点。 第一物理节点20 (1)包括第一功能30，而第二物理节点20 (2)包 括第二功能32。第一功能30与第二功能32可以属于或不属于同一才莫 型层协议46B (例如，链路层)，且从属于或涉及共享事务处理34B。 共享事务处理34B可以由第一功能30或者第二功能32或者第一功能 30与第二功能32的组合来执行或实现。因此，图9B说明用于不同功能层时(例如，诸如功能30与功能32的不同功能)的共享事务处理 技术，即使这些功能(例如，功能层)可以在不同的物理节点上存在 或执行。尽管仅在图9B示出在多个物理节点上的共享事务处理技术 的分布，但是这种分布适用于这里所述的所有实施例与实施方式。 123/
在图9A、图9B、图10以及所有随后的普通实施方案中，第一功 能30、第二功能32以及共享事务处理34可以由发送节点20的控制 器或处理器执行，假如宽泛地描述与理解上文提及的词"处理器"与
"控制器"。 124/
在图11所示的技术的一种形态中，共享事务处理包含由第一功 能与第二功能使用的共享信息。该共享信息的 一个非限制示例是公用 的排序信息，该信息将在下面并特别(例如)参考4.0节作进一步描述。
125/
基本上， 一个包含排序信息的单字段代表多个进程^L载运，而不 管进程的什么组合是有效的。支持加密和/或"^艮头压缩和/或净载荷压 缩和/或信令压缩的层^f皮用来载运排序信息。当一个以上功能层有效 时，这种排序信息对多重功能层可以是公用的(例如，《^头压缩与加 密，或者其它组合)，且该排序信息可以由任一有效进程/算法产生(或 者，如果同时执行或激活多个操作那么由多个有效进程/算法产生)。 这种排序信息也可以源于在#^头压缩进程和/或加密进程和/或净载荷 压缩进程和/或信令压缩进程之下的层协议。或者，该排序信息也可以 源于链路层之上的其它层，比如源于应用层(例如，源于诸如位于应 用层的实吋协议RTP的协议)。
126/
例如，在图12所示的一个示例实施方案中，第一功能30是数据 压缩功能而第二功能32是加密功能，共享信息34 (12)是由压缩功 能30起始的作为用于压缩功能30的序号MSN的序号。同一序号也^皮力o密功能32使用来导出用于加密操作的会话密钥。 127/
在如图13所示的另一示例实施方案中，其中第一功能30也还是 数据压缩功能且第二功能32是加密功能，共享信息34 ( 13 )是由加 密功能32起始的、从中导出会话密钥的序号，且该共享信息34也被 压缩功能30用作序号MSN。
128/
序号可作为用于压缩算法的共享序号的偏移量而导出。基本上， 传输序号信息的压缩算法将此序号编码为从在多个功能层之间共享 的序列编号的偏移量。
129/
加密层通常对于连接执行操作，处理所有SDU,与这些SDU属 于什么IP流无关。这可能对于压缩算法与压缩协议是相同的，但是这 些压缩算法与压缩协议往往代之以对更细的粒度(granularity)级执行 操作并按流对包执行处理以获得增强的压缩效率。在这种情况下，与 对"连接"执行操作的其它层共享的序号将按SDU而不是按流上的 包来改变值一一除非该连接恰好映射到唯一的包流。
130/
"按流"的压缩算法所见到的改变模式既依赖于在连接上的每个 流的速率(可以是变化的)以及不同流的数目。然而，在序号中跳转 的改变模式很可能被限制到有限值，且压缩算法可以基于共享序号 (不是基于其绝对值就是基于偏移量)发送压缩比特(LSB或 W-LSB )。也可在Carsten Bormann等人的《#举的孩兴在裙(^0//0人' ^f束与4 ,#、辨,及r尸、WDi5、 SSP以及未在裙i) (CarstenBormann. et al. AOZ)wW //eac/er C鐘/ mw/ow Fra附e衡A朋cf/owr ; rq/ /w
"7P, W)尸，五S尸w"cowpre^e《IETF RFC 3095, April 2001 )中参见 偏移量编》马。 131/
能够"按流"操作的压缩算法的示例包括"^艮头压缩和/或净载荷压缩和/或信令压缩和/或#艮头去除。
132/
在用图14一般说明的技术的另一形态中，共享事务处理34(14) 包含第二功能32,该第二功能32不仅对包的第二部分执行操作，而 且对包的可以至少部分地受到第 一功能30操作的第 一部分执行操作。 例如，在图15所示的一个示例实施方案中，第一功能30是数据压缩 功能而第二功能32是加密功能，且加密功能32对包的报头的至少一 部分加密(但是，如下文所解释，不对压缩信道标识符或报头排序加 密)。以下，进一步描述该示例实施方案，特别(例如)参考本文的 3.0节。
133/
在用图16 —般说明的技术的一种形态中，共享事务处理包含对 于包的第一部分的至少一部分与该包的第二部分的至少一部分确定 校验和，例如确定"共享校验和"。基础层(underlying layer)载运 公用校验和信息，例如，由支持加密和/或报头压缩和/或信令压缩和/ 或净载荷压缩的层来载运校验和信息。当 一个以上的功能层有效时， 这种信息可公用于多个功能层(例如，报头压缩与加密，或者其它组 合)，且这种信息因此可以由任一个有效的进程/算法来产生(或者，
如果多个操作同时^皮执行或激活，那么由多个有效进程/算法产生)。 134/
在如图17所示的示例实施方案中，第一功能30是数据压缩功能， 包的第一部分是包的才艮头；第二功能32是加密功能，包的第二部分 是包的净载荷。对于包的^R头的至少一部分与包的净载荷的至少一部 分确定校验和。以下，进一步描述该实施方案，特别(例如)参考本 文的2.1节。
135/
在图18所示的又一示例实施方案中，共享事务处理包括对于包 的笫一部分(例如，包的^Jc)的至少一部分确定校验和，且确定了 校验和的该包的第 一部分的的那部分包含在对该包的笫二部分执行的操作中由第二功能使用的参数。例如，在包的第二部分是包的净载 荷的实施方案中，对于包的"^艮头的至少一部分确定冲t验和，并在对于 包的第二部分执行的操作中由第二功能使用的参数是序号，用该序号
为其加密上下文导出会话密钥。以下，进一步描述该示例实施方案，
特别(例如)参考本文的2.2节。 136/
因此，考虑到共享事务处理及一些本质上组合或合并的功能性， 提供方法与设备用于在工作在相同端点的多重功能(例如，在同一模 型层内操作的多个功能层)之间共享这种诸如排序信息与校验和信息 等事务处理/信息。共享事务处理技术可应用到任意两个适当的发送与 接收节点(不管所述节点相邻与否)，且特别(但不排他地)适合于 其中链路层代表多个共享同 一信息的多个功能/进程来保持并传输排 序和〃或校验和信息的情形或体系结构。而且，如先前参考图10B所 解释，内部使用共享事务处理技术的发送节点不必是单一节点，而是 可包括多个节点，通过这些接点可分配多个功能。本技术包含或定为 目标的一些功能(例如， 一些功能层)可以是(比如)报头压缩、报 头去除与再生成、净载荷压缩、信令压缩、加密与重排序等功能中的 任何功能，以及上述功能的任意组合。
137/
如上简述与如下进一步解释，报头压缩与加密(以及可能的其它 功能)可共享排序信息与校验和，减少单独拥有排序与校验和的开销。 SAE/LTE体系结构为这种想法提供了候选系统，以#皮应用于接入网关 (aGW)与用户设备(UE)内。 138/
如链路层那样的层代表在相同端点内操作的多功能层(例如，加 密和/或净载荷压缩和/或报头压缩)来载运排序信息与校验和，并共 享该同一信息。作为另一形态，当对于加密进程的会话密钥导出算法 提供在压缩/加密端点之间的重排序与包丟失的鲁棒性时，至少部分地 一起执行加密与报头压缩。而且，为使加密密钥导出的选择更稳健，与:^艮头压缩的上下文管理协同进行加密上下文管理。
139/
使用共享事务处理技术共享功能之间的事务处理可导致开销的 减少，例如在哪些可设法使用同一信息并可在相同端点内操作的功能 (例如鲁棒的报头压缩、报头去除、净载荷压缩、信令压缩和/或加密 的任意组合中的任一)之间共享排序与校验和。例如，使用该共享事 务处理技术，在一些实施例和/或实施方案中可以按表2的方式减少开 销。
140/
表2
公用校验和(如CRC16) : 2+八位组(比特错误、解压缩、验证)
參公用序号:_1八位组(重排序+加密密钥)_
总计 3+ /\位组
141/
如上所示，在可设法使用同一信息且在相同端点内操作的功能 (例如鲁棒的报头压缩、报头去除、净载荷压缩、信令压缩和/或加密 的任意组合中的任何功能)之间？ 1入诸如共享的排序与校验和的共享 事务处理，可以去除若干开销。接下来，基于但不限于RFC 3095的 压缩器与解压缩器排序要求与行为，即Carsten Bormann等人的(T# 举的孩关在^ "0//C>> ;裡束与4Wr尸、OD尸、五S尸"及 或在裙》(Carsten Bormann. et al. WOZmsf //ea<ier C0附/ re5^0w (KCWQ: Fra麼衡rA:朋d/ ra/ /w A7P, t/D尸，五5P a"d w"c細pms^et/. IETF RFC 3095, April 2001 )，描述一些可能的示范性实施例。
2.0:压縮上下文与加密上下文的组合管理积克述
143/
在其一种形态中，本技术涉及使用组合或共享的事务处理的压缩 上下文与加密上下文的组合管理。在使用从压缩协议导出的排序与校 验和(例如解压缩验证)来执行加密的时候，压缩算法的上下文管理规则被用于加密上下文的管理。该组合的上下文管理特征在于设有发 送节点与接收节点，例如，发送节点在包的报头部分的至少一部分上 执行压缩并在包的至少 一部分上执行加密，从而压缩与加密^皮结合到 在接收节点处包的解压缩验证与解密验证成为相互依存的程度。
144/
在本形态的第一例方式中，共享的事务处理或组合的子操作包括 在将被压缩的包的至少一部分与将被加密的该包的一部分上确定复 合校验和。例如，在第一方式中，如在发送节点处所计算的校验和可 以覆盖该包的所述部分的将被加密的(原未加密的)部分与将被压缩 的(原未压缩的)部分。在接收方，加密层执行包的已加密部分的解 密且解压缩器将已压缩部分解压缩(如果没有重叠，则可先进行任一 处理)。在第一方式中，接着使用校验和来验证解压缩进程与解密进 程这二者的结果，且当校验成功时导致相应的压缩上下文与加密上下 文的更新。换句话说，如果验证了解压缩，则完成了解密且隐含地验 证了解密。
145/
在压缩上下文与加密上下文的组合管理的本形态的第二例方式 中，组合的子操作包含用序号作为共享信息的压缩功能与加密功能， 该序号^支加密功能用于会话密钥导出。在第二方式中，在加密功能使 用压缩主序号来从其加密上下文中导出会话密钥的情况下，校验和只 需要覆盖(原未压缩的)将被压缩的、包括序号信息的部分。因此， 在该第二例方式中，在将^^皮压缩的包的至少一部分与(可选地)将4皮 加密的包的至少一部分上计算校验和。在第二方式中，校验和仅净皮用 来确认解压缩进程的结果，当成功时就导致对相应的压缩上下文与加 密上下文进行更新。序号MSN因此^皮-睑证，且这是用于加密上下文 的唯一每文感信息。
146/
在任一方式中，可以使用传输层(例如，UDP、 TCP)校验和来 进一步确认该进程的结果。上下文更新规则也遵循在第二方式中的压缩的上下文更新逻辑。 147/
在同 一节点中与报头压缩一起执行加密，可减少用于排序功能与 重排序功能的开销。将加密特征与才艮头压缩特征组合到一个单一协议 内可以是本技术的应用成果。该协议也可以包括对净载荷压缩的支 持，同一类型规则也可能被用于此。
148/
上下文管理在这里适用于整个压缩包或仅其子集(例如，仅净载 荷被加密)被加密的情况。在这两种方式中，校验和有助于压缩操作 与加密操作的验证。
2.1:压缩上下文与加密上下文的组合管理 第一方式；fe述
150/
图19示出了第一例方式所包含的基本的、有代表性的示例动作 或事件。动作19-1示出了在发送节点处执行的示例动作。尤其，对于 发送节点处的进入包，在该进入包的压缩候选部分与加密候选净载荷 部分上确定初始校验和。在至少部分已压缩与至少部分已加密的接口 穿越包中包含该初始校验和。随后在接口上以如图9A中接口 24的示 例方式所述传输该接口穿越包。如先前所示，接口 24可以是单一接 口 (例如在增强节点B的情况下的Sl接口或Uu接口 )，或者可共同 代表诸如Sl接口与Uu接口等几个接口 。动作19-2示出了在执行解 密与解压缩以获得复原包后，在接收节点处的接口穿越包的接收上执 行的示例动作。动作19-2的动作包括在恢复包上确定验证校验和。而 且，用验证校验和与初始校验和的比较来确定解密与解压缩的验证。 2丄1:压缩上下文与加密上下文的组合管理 第一方式执行发送节点
152/
发送节点处的图19的第一方式的示例详细实施方案，通过图20 的流程图的动作并结合在图21的对应布置的包描述进行说明，图解了在。接收节点处的图19的第一方式的相应的详细实施方案，通过 图22的流程图的动作并结合图23的对应布置的包描述进行说明。 153/
对于第一方式的示例实施方案，在发送节点处，动作19-l-a包括 对于进入包的压缩候选部分并对于加密候选净载荷部分确定初始校 验和ICKSUM。在该示例实施方案中，图21示出了对于进入包的整 个压缩候选部分CCP和整个加密候选净载荷部分ECPR计算并确定初 始校验和ICKSUM。可以理解能够对于少于整个进入包计算动作 19-l-a的校验和ICKSUM,例如对于少于整个压缩候选部分CCP和/ 或少于整个加密候选净载荷部分ECPR来计算，只要校验和计算逻辑 知道发送节点与接收节点双方，即校验和计算逻辑^t一致地预配置在 发送节点与接收节点二者中。
154/
动作19-l-b包括对进入包的压缩候选部分CCP执行压缩以提供 压缩串CS。动作19-l-b的压缩可以是任何适当的压缩方法，包括但 不限于这里所描述或所提及的压缩方法。
155/
动作19-l-c包括至少将进入包的加密候选净载荷部分ECPR加密 以提供加密串ES。在图21所示的示例实施方案中，加密不仅覆盖加 密候选净载荷部分ECPR，而且覆盖压缩候选部分CCP。应知，在变 更实施方案中加密也可以覆盖初始校验和ICKSUM。或者，在另一变 更实施方案中，加密也可以只覆盖加密候选净载荷部分ECPR (不覆 盖压缩候选部分CCP或初始校验和ICKSUM)。无论采用哪一种实 施方案或变更实施方案，动作19-l-b可以是任意适当的加密技术，包 括但不限于这里所描述或所提及的加密技术。
156/
动作19-l-d包括形成对应于进入包的接口穿越包。动作19-l-d的 组包涉及在接口穿越包中至少包^^压缩串CS、加密串ES以及初始校 验和。当加密只覆盖加密候选净载荷部分ECPR时，这三个组成部分单独设置在接口穿越包内。然而，在加密覆盖超过加密候选净载荷部
分ECPR时，加密串ES可以包^^妄口穿越包的其它组成部分中的一 个或多个其他组成部分的全部或一部分。即，如果加密覆盖压縮候选 部分CCP，则在接口穿越包中包含力。密串ES涵盖在接口穿越包中包 含压缩候选部分CCP全部或部分。同样，如果加密覆盖初始校验和 ICKSUM,则在接口穿越包中包含加密串ES涵盖在接口穿越包中包 含初始校验和ICKSUM。
2丄2:压缩上下文与加密上下文的组合管理 第一方式执行接收节点
158/
在接收节点处的图19的第一方式的对应的详细实施方案，通过 图22的流程图的动作并结合图23的对应布置对应布置的包描述进行 说明。图22的动作19-2-a包括对接口穿越包的加密串ES解密以提供 解密串。动作19-2-a的解密由在动作19-l-c处所使用的对应的加密技 术的逆过程来执行。
159/
考虑到图21所示的具体实施方案，因为加密串ES准备成包含压 缩串CS，所以图22将解密表示为将加密串ES拆包来提供压缩串CS 和对应于(假定加密与解密成功)加密候选净载荷部分ECPR的净载 荷部分。如在另一变更实施方案中压缩串CS未受到加密，则该压缩 串CS就可不进行动作19-2-a的解密。而且，如果在再一变更实施方 案中初始校验和ICKSUM也未受到加密(如图22的虚线所示)，则 初始校验和ICKSUM也可作为动作19-2-a的一部分4皮解密。
160/
动作19-2-b包括将接口穿越包的压缩串CS解压缩以提供解压串 DS。动作19-2-b的解压缩通过用于动作19-l-b的压缩操作的压缩方 法的逆过程来执行。
161/
动作19-2-c包括对于解压串DS与解密串以对应于动作19-l-a中确定初始校验和的方式确定验证4文验和VCKSUM。 162/
动作19-2-d包括使用如在动作19-2-c处所执行的验证校验和与初 始校验和的比较来确定动作19-2-a的解密与动作19-2-b的解压缩的验证。
163/
动作19-2-e包括依照动作19-2-d的验证来更新压缩上下文。动作 19-2-f包括依照动作19-2-d的l^证来更新加密上下文。 压缩上下文与加密上下文的组合管理 第一方式结语
165/
因此，在压缩上下文与加密上下文的组合管理的第一方式中，加 密与压缩使用或共享同一校验和，且校验和的覆盖范围包括(至少部
分的)净载荷。 166/
基本上，用于验证解压缩进程的结果的校验和也可确认会话密钥 确定的成功(例如，关于解密进程)。如在图19中宽泛所示及图20 与图21中以更具体的示例实施方案所示，校验和覆盖包的組成部分 的将被加密的(原未加密)部分和将被压缩的(原未压缩)部分。
167/
在发送端(例如，参见图20的动作19-l-a)，计算校验和，使该 校验和覆盖包的组成部分的将纟支加密的(原未加密)部分及将被压缩 的(原未压缩)部分。
168/
在接收端(例如，参见图20)，包先^皮解密(例如，参见动作 19-2-a)。注意排序独立于压缩。接着可以向解压缩器传递解密进程 的结果而不验证解密进程的结果。然后，执行解压缩(动作19-2-b)。
169/
接着使用与已压缩包一起收到的校验和来验证解压缩进程与解密进程的结果。如果验证成功，则分别更新压缩上下文与加密上下文
(动作19-2-e与动作19-2-f)。可适用时，基于压缩格式的上下文更 新属性也基于执行方式更新压缩上下文。要是校验和覆盖至少全部的 被加密的信息，那么只要解压缩是成功的则可以假定解密操作也是成 功的，且能够更新相关状态以处理下一包。
2.2:压缩上下文与加密上下文的组合管理 第二方式概述
171/
在压缩上下文与加密上下文的组合管理方面的第二例方式中，组 合的子操作包括用序号作为共享信息的序号的压缩功能与解密功能， 该序号纟皮加密功能用于会话密钥或用来导出会话密钥。此外，在该形 态的第二例方式中，对于包的要^^皮压缩的至少一部分与(可选地)该
包要^皮加密的部分计算校验和。在这两种方式中，校验和有助于压缩 操作与加密操作的验证。
2.2.1:压缩上下文与加密上下文的组合管理 第二方式执行发送节点的动作
173/
图24示出了涉及第二例方式的基本的、有代表性的示例动作或 事件。动作24-l示出了在发送节点处所执行的示例动作。尤其，对于 发送节点处的进入包，对进入包的压缩候选部分确定初始校验和。在 该第二方式中，压缩候选部分包括用于压缩操作的序号。而且，在该 第二方式中，该同一序号被用作共享信息以用于导出在进入包的加密 候选净载荷部分的加密中使用的会话密钥。在至少部分压缩且至少部 分加密的接口穿越包中包含初始校验和。随后在接口上以如图9A中 的接口 24的示例方式所述传输该接口穿越包。如前所示，接口24可 以是单一接口 (例如在增强节点B的情况下的Sl接口或Uu接口 )， 或者可以集体地代表诸如Sl接口与Uu接口这二者等几个接口 。动作 24-2表示在接收接口穿越包后即执行的示例动作，包括获取序号。在执行解密与解压缩而获得恢复包之后，对于恢复包确定验证校验和。 使用验证校验和与初始校验和的比较来确定解压缩的验证。
174/
在接收节点处的图24的第二方式的示例的详细实施方案，通过 图25的流程图的动作并结合图26的对应布置的包描述进行说明。在 接收节点处的图24的第二方式的示例的详细实施方案，通过图27的 流程图的动作并结合图28的对应布置的包描述进行说明。
175/
对于第二方式的示例实施方案，在发送节点处，动作24-l-a包括 确定初始校验和。尤其，对于进入包的压缩候选部分CCP确定初始才交 验和。如果序号MSN是作为原始未压缩IP报头的一部分的序号，那 么序号MSN应被校验和以图26中对应描述所示的方式覆盖。另一方 面，如果序号MSN由压缩算法产生且并不出现在原始未压缩IP报头 中，那么其唯一用途是对该^^艮头解压缩，因而序号MSN不必是在解 压缩进程与解密进程之后纟支验证的信息的组成部分(且因此不需要祐^ 初始校-睑和覆盖)。
176/
作为选项(与4安照如图26的才交'险和形成(checksum formation) 中的虚线所示)，在一些变更实施方案中，也对于进入包的加密候选 净载荷部分ECPR确定初始校验和，所述进入包的加密候选净载荷部 分ECPR使用用于会话密钥导出的序号。可以理解可对少于整个进入 包计算动作24-1-a的校验和ICKSUM，例如对少于整个压缩候选部分 CCP和/或对少于加密候选净载荷部分ECPR进行计算，只要对序号 MSN计算且只要在发送节点与接收节点双方校验和计算逻辑始终如 一地明白或作了预配置。
177/
动作24-1-b包括对进入包的压缩候选部分CCP执行压缩以提供 压缩串CS。动作24-1-b的压缩可以是任意适合的压缩方法，包括但 不限于这里描述或提及的压缩方法。178/
动作24-1-c包括至少对进入包的加密候选净载荷部分ECPR加密 以提供加密串ES。在图26所示的示例实施方案中，加密不仅覆盖加 密候选净载荷部分ECPR,而且还基本覆盖压缩候选部分CCP,序号 MSN除外。因为这一缘故，序号MSN或其已压缩版本在图26中#皮 单独图解在加密串ES旁边。应知，在一变更实施方案中加密也可以 覆盖初始校验和ICKSUM。作为选择，在另一变更实施方案中，加密 可以只覆盖加密候选净载荷部分ECPR (而不覆盖压缩候选部分CCP 或初始校验和ICKSUM )。无论采用怎样的实施方案或变更实施方案， 动作24-l-b的加密可以是任意适当的加密技术，包括但不限于这里所 描述或所提及的加密技术。
179/
动作24-l-d包括形成对应于进入包的接口穿越包。动作24-l-d的 组包涉及在接口穿越包中包括至少含序号MSN的压缩串CS、加密串 ES以及初始校验和。当加密只覆盖加密候选净载荷部分ECPR时，这 三个组成部分单独设置在接口穿越包内。然而， 一旦加密覆盖超过加 密候选净载荷部分ECPR，加密串ES可以包^^接口穿越包的其它组成 部分中的一个或多个组成成分的全部或部分。即，如果加密覆盖除序 号MSN以外的压缩候选部分CCP,那么在接口穿越包中包含加密串 ES涵盖在接口穿越包中包含压缩候选部分CCP的部分。同样，如果 加密覆盖初始校验和ICKSUM，那么在接口穿越包中包含加密串ES 涵盖在接口穿越包中包含初始校验和ICKSUM。
2.2.2:压缩上下文与加密上下文的组合管理 第二方式执行接收节点
181/
图27的流程图的动作以及图28的对应布置的包描述，图解了在 接收节点处的图24的第二方式的对应的详细实施方案。图27的动作 24-2-a包括从接口穿越包中获得序号MSN。例如，序号MSN可以祐二 解压缩为未^皮加密的压缩串CS的一部分。如果序号MSN将^皮用于解密，那么它可以不祐jo密，但是它可以已^皮压缩。
182/
动作24-2-b包括对接口穿越包的加密串ES解密以提供解密串。 与动作24-2-b对应，图28示出了诸如包含压缩串部分(例如，在动 作24-2-c处被加密的压缩串部分)与包的净载荷的解密串。动作24-2-b 的解密由在动作24-1-c处使用的对应的加密技术的逆来执行。
183/
动作24-2-c包括对接口穿越包的压缩串部分解压缩以提供解压缩 串。与动作24-2-c对应，图28示出了诸如包括序号MSN的解压缩串。 动作24-2-c的解压缩由用于动作24-l-b的压缩操作的压缩方法的逆来
执行。 184/
动作24-2-d包括至少对解压缩串以及可选地对解密串用对应于在 动作24-1-a中确定初始校验和ICKSUM的方式确定验证校验和 VCKSUM。
185/
动作24-2-e包括使用验证校验和与初始校验和的比较来确定动作 24-2-c的解压缩l^证。 186/
动作24-2-f包括依照动作24-2-e的验证来更新压缩上下文。动作 24-2-g包括依照动作24-2-e的验i正来更新加密上下文。 2.3:压缩上下文与加密上下文的组合管理 第二方式结语
188/
在压缩上下文与加密上下文的组合管理的第一方式中，以用于验 证解压缩进程的结果的校验和来确认会话密钥确定的成功(解密进 程)。该校验和最低限度地覆盖包含主序号的(MSN )将被压缩的(原 始未压缩)部分，但是，如果解密进程将同一 MSN用于会话密钥导 出，那么该校验和可以不包括包组成部分中将净支力。密的(原始未力。密)部分。
189/
在发送端，例如在发送节点，计算校验和ICKSUM以使其最低限 度地覆盖将被压缩的(原始未压缩)部分一一包含MSN，但是如果解 密进程将同一 MSN用于会话密钥导出，那么该校验和可以不包括包 组成部分中的将纟皮加密的(原始未加密)部分。
190/
在接收端，例如在接收节点，至少首先解压缩或恢复MSN(动作 24-2-a)。接着执行解密与解压缩(如果压缩部分的至少某一组成部 分被加密，就须在除MSN以外的字段的解压缩之前进行解密)。然 后，校验和仅用来确认解压缩进程的结果。假如成功，那么基于压缩 格式的上下文更新属性也基于操作方式分别更新压缩上下文与加密 上下文，若适用且如压缩算法所定义。于是，序号MSN祐:验证，这 是加密上下文的唯一敏感信息。
2.4:压缩上下文与加密上下文的组合管理
若干优势
192/
如上所述的或如由此所另外包括的压缩上下文与加密上下文的 组合管理具有许多优势，下面列举其中的一些优势。第一例优势是开 销最小化当使用普通校验和时，该技术将加密算法的上下文管理功 能性扩展到包含"^艮头压缩上下文更新的鲁棒性特征。这也可以节省若
干开销。 193/
第二例优势是对现有标准与体系结构的影响该技术不阻止下层 拥有自身的错误检测功能。该技术使用在如所提出的组合中，可以允 许下层关闭(turn off)它们的一些错误检测机制，这通常需要独立加 密层。这可以减少总开销。换句话说，这不是层违规或交叉层综合 (layer violation or cross-layer integration)。
194/第三例优势是互利互惠以及加密上下文的增强鲁棒性加密功能 受益于关于排序信息的报头压缩算法的鲁棒性特征，且因此降低了加 密上下文丟失相对于排序的同步的可能性。要是发生相对于排序的同 步丟失，则再同步将从报头压缩算法的恢复机制的内部发生。
195/
第四例优势是对 一般的报头压缩的适用性这尤其适用于大多数 ROHC协约，包括但不限于ROHC RTP ( 0x0001 ) 、 UDP ( 0x0002 )、 IP ( 0x0004 ) 、 ESP ( 0x0003 ) 、 TCP ( 0x0006 ) 、 UDP國Lite ( 0x0008 )、 RTP/UDP-Lite (0x0007)报头压缩协议。例如，这也特别关联到(但 不限于)诸如序列密码的密码算法与加密算法，这允许例如利用位屏 蔽来只将特定位加密/不加密。这种序列密码的示例包括A5、 GEA、 UEA以及AES。其它相关的密码与加密算法是那些利用排序信息来导 出加(解)密码所需的参数的算法。
196/项。
197/
用于验证解压缩进程的结果的校验和可确认会话密钥确定(解密 进程)的成功。当成功时，该加密上下文^皮更新。 198/
使用覆盖了包组成部分的将^支加密的(原始未加密)部分以及将 被压缩的(原始未压缩)部分的校验和，可实现鲁棒的加密上下文管 理。该校验和可供解压缩进程使用.，且其结果可供加密算法使用。
199/
使用最低限度覆盖了将被压缩的(原始未压缩)部分一一包含 MSN的校验和，可实现鲁棒的加密上下文管理，但是如果解密进程将 同一主序号(MSN)用于会话密钥导出，那么该校验和可以不包括包 组成部分的将被加密的(原始未加密的)部分。该校验和可供解压缩 进程使用，且其结果可供加密算法使用。如果实用，那么当成功时就基于压缩算法的上下文更新与才喿作方式来更新加密上下文。
200/
传输层(例如，UDP、 TCP)校验和可用来提供对进程结果的进 一步确认。 201/
当使用UDP-Lite时，该校验和使用与UDP-Lite校验和相同的覆
盖范围。 202/
假如所述校验和所覆盖的至少有保护传输层的信息，那么该校验 和可取代传输层校验和。首先验证传输层校验和。 203/
例如，前述的方式可适用于依照鲁棒报头压缩(ROHC)协约来 执行压缩算法的场合，包括但不限于ROHC RTP (0x0001 ) 、 UDP (0x0002 ) 、 IP ( 0x0004 ) 、 ESP ( 0x0003 ) 、 TCP ( 0x0006 ) 、 UDP-Lite (0x0008 ) 、 RTP/UDP-Lite ( 0x0007 )才艮头压缩协议。
204/
例如，前述的方式一般可适用于依照任意别的报头压缩方案来执 行报头压缩器和/或解压缩器的场合。 205/
例如，前述的方式可适用于密码算法与加密算法是序列密码的场 合，包括但不限于A5、 GEA、 UEA以及AES。利用排序信息来导出
加(解)密所需的参数的其它密码算法与加密算法也在本发明范围内。 206/
例如，前述的方式可适用于其它压缩算法，例如的信令压缩，诸 如SigComp、净载荷压縮算法(例如那些在Pereira R.的(f炎^Z)五i^47E ^ ZP 净戎岸在裙J) ( Pereira, R. /尸_Pa_y/oa<i C麵戸抓'o" Ws7'"g Z)五F"r五，IETF RFC 2394， December 1998)以及Friend R与R. Monsour的(f炎^ZZS" W/尸净我'#在/,》(Friend, R. et R. Monsour, /尸 尸ay/oat/Co附/7mw,'朋L^/"g丄ZS, IETF RFC 2395, December 1998 )中所定义的)，或者可适用于要求排序与校验和的任意其他操作，用于排 序与校验和的这种信息可与其他算法共享，该信息起源并终止于相同 节点。
207/
例如，前述的方式可适用于aGW， aGW当前在3GPP RAN 2标 准化工作组中^皮定义为SAE/LTE工作的组成部分。
3.0:安全报头压缩概述
209/
依照本技术的另一单独的方面，可在报头压缩协议的组成部分 上，例如可文中所述的其它方面的协作下使用，执行加密(encryption) 功能或密码(ciphering)功能。即，这里所述的方法允许对包的某些或全 部净载荷加密，也允许对压缩报头格式加密(除了具有涉及报头压缩 信道的功能的报头字段以外)。
210/
报头压缩算法(例如与现有RoHC框架兼容的鲁棒报头压缩协议) 用来将加密与报头压缩有效组合而产生加密的报头压缩流。既在使用 (否则可能被压缩的)净良头压缩主序号(MSN)的未压缩表示的包括 净载荷的整个才良头压缩包上执行加密，又在其自身的尽可能多的已压 缩报头上执行加密。不能被加密的字段是必须支持下述各项的字段
— 数据流的多路复用 (例如，RoHCCIDs)，
— 包类型标识 (例如，RoHC包类型)， —(可能压缩的)MSN，以及
— 压缩算法的标识符 (例如，RoHC协约八位组) 在适用时，例如，对于初始包 (例如，RoHCIR包)。
211/
在一个示例的、非限制的实施方案包括两个对应节点(相邻或不 相邻)，其中执行报头压缩与加密(例如在SAE/LTE的3GPPRAN2 中定义的aGW中)。该实施方案中规定"安全压缩报头格式"的哪 部分将不^皮加密，并规定哪部分可以^L加密，还规定在发送端与接收端使用的逻辑。
212/
加密可以与同 一节点中的报头压缩一起被执行，这减少单独排序 的开销并增强用于解密的密钥导出机制的鲁棒性，其特征在于诸如抗 包丟失的鲁棒性和重排序得到继承。该协议也可以包含对净栽荷压缩 的支持。
213/
这种技术可在RoHC框架内适用于新协约(由于必须定义现有 RFC3095的扩充版本)，，又可适用于用于构造加密上下文、重排序 等的附加信道协商参数。要求新的协约专用包格式(profile-specific packet formats),但是在RoHC的未使用的包类型与IR包类型的空 间内有余地可用。因此，提出的解决办法可以在如Carsten Bormann 等人的《#举的孩关在/, .'雍束与4个錄^.' i 7P、 t/DP、
EST5 "及^在裙的》(Carsten Bormann. et al. i^^mW Heotc/er C確pmw/o" fKO/ZC」Frame脚rA:朋c/ /owr pra力/w "r尸，W)尸，五S尸
柳cow; mw^/,正TF RFC 3095, April 2001 )以及Pelletier G.、 SandlundK.与L. Jonsson的《##^孩关在裙 S爽 迷/力哞"X Pelletier, G., Sandlund, K. and L. Jonsson， The Robust Header Compression (ROHC) Framework, Internet Draft (work in progress), <draft-ietf-rohc-rfc3095bis-framework-00.txt>, December 2005 )所定义的RoHC框架内兼容，以使加密RoHC流可以与非加密 流一样共享同一信道。
214/
先决条件是通过诸如在初始化上下文期间的协商、默认值、带内 信令或者通过静态给定值来建立与加密有关的信道参数。这些参数包 括通常出现在加密上下文内的项目(l)要用的密码转换(例如，f8-才莫式中的AES, HMAC-SHA)和(2)主密钥。
215/
加密(例如，密码)^L用到构建已压缩"t艮头的其后为净载荷的字段，除以下的必须保持为未加密的字段外(例如，含有报头压缩信道
信息的^^艮头的字段)
在:R头压缩信道(CID)上的流的多路复用标识符。
*已压缩l艮头格式类型标识(包类型标识符)。
*主序号(如果加密会话密钥用MSN来导出)；MSN可以被压缩。
*压缩算法标识符，当无多路复用标识符与安全报头压缩流关
联时(初始已压缩报头的压缩协约标识符)。 216/
因此，文中描述的例如是运行包括发送节点与接收节点的远程通 信网络的方法。该方法包括，对于在发送节点处的进入包，对该包的 除具有报头压缩信道信息的报头字段以外的已压缩报头加密，并在接 口穿越包中包含已加密已压缩报头。该方法还包括，对于在接收节点 处收到的接口穿越包，从具有报头压缩信道信息的报头字段中获取信 息并解密该接口穿越包的已压缩报头。
3.1:安全报头压缩压缩器逻辑
218/
图29的流程图示出了示例的、非限制的动作或事件，它们能够 以准备具有已加密其压缩报头的包的示例方式执行。可以理解， 一个 包实际上可以有一个以上的报头，因为不同的协议层可以添加其各自 的报头以组成包含多协议的多报头的复合报头。与图29的各个动作 对应，图30示出了当一个包涉及压缩操作与解密操作时的包内容描 述。
219/
图30示出了未压缩寺艮头UH。未压缩报头UH包括如上所列的不 可加密字段(UF):多路复用标识符(MUX ID)、已压缩才艮头格式 类型标识(FMTID)、主序号(MSN)以及压缩算法标识符(CAI)。 这四个字段合起来组成这里所述的"不可加密字段"或"UF"。
220/动作29-l包括确定使用哪个压缩上下文。同样，动作29-2包括 确定使用哪个加密上下文。动作29-1与29-2的上下文确定基于确定 正在进行的事务处理。动作29-1与29-2的确定可以共同地进行。
221/
动作29-3包括基于报头压缩的协议或者根据本地维持的值来确 定主序号(MSN)的值。 222/
动作29-4包括压缩包的报头。图30示出了已压缩报头CH的产 生过程。动作29-4的压缩可以是诸如在文中描述或提及的任意适当的 压缩方法。
223/
动作29-5包括确定包索引以生成用于加密的会话密钥。 224/
动作29-6包括使用例如包的已压缩净艮头与可加密部分(例如，包 的净载荷与任何保持的报头压缩信道信息，诸如反馈、分割、校验和
等)来组包。动作29-6的组包(packetization)中不包括如上所列的 不可加密字段(UF):多路复用标识符(MUX ID)、已压缩报头格 式类型标识(FMT ID )、主序号(MSN)以及压缩算法标识符(CAI)。 225/
动作29-7包括对在动作29-6中形成的包加密，例如，根据正净皮 使用的特定加密算法在包的已压缩报头CP与净载荷上执行加密。图 30示出了包的已加密部分EP,作为加密结果。加密算法可以(例如) 类似于诸如按照Baugher M等人的(T姿全实W传痴t錄议"A5T J》 (Baugher M. et al.， TTie Secwre i^a/-"me TVcrw^port Protoco/ f57^7P」, 正TF RFC 3711 , March 2004 )的加密。动作29-7的加密不包括如上所 述的不可加密字段(UF)。 226/
动作29-8包括在适用时更新加密上下文中的必要参数。 227/动作29-9包括通过添加动作29-6中所列的不可加密字段(UF) 将包的已加密部分组包。这些不可加密字段(UF )必须是未^皮加密的， 但如果要求压缩也可被压缩。相应地，图30示出了基本上备妥向下 层传递的最终包P或数据"^艮的形成。事实上，动作29-10包括向下层 传递结果得到的数据报P (例如，向用于分割与向正确的逻辑信道和/ 或传输队列映射的^某体接入层(MAC),例如它可能是传输的调度程
序)。 228/
图29中的动作次序可以变更。例如，动作29-1与动作29-2之间 的次序可以调^:。动作29-3、动作29-4与动作29-6之间的次序也可 以调换。而且，动作29-8与动作29-10可以整体与动作29-8调换。 3.1:安全报头压缩解压缩器逻辑
230/
图31的流程图示出了示例的、非限制的动作或事件，它们能够 以处理已接收包的示例方式来执行，该包对其已压缩的报头作了加密 (例如，在接收节点处执行的动作)。与图31的各个动作对应，图 32描述当包涉及压缩操作与解密操作时的包内容。 231/
动作31-1包括通过处理报头压缩信道信息将从下层接收到的数 据包P进行拆包，所述报头压缩信道信息包括诸如多路复用标识符 (MUXID)、压缩报头格式类型标识(FMTID)、主序号(MSN) 以及压缩算法标识符(CAI)的不可加密字段(UF)。
232/
动作31-2包括确定使用哪一个压缩上下文。该压缩上下文一旦确 定，动作31-3中就包含对MSN的解压缩。 233/
动作31-4包含确定使用哪个加密上下文。加密上下文的确定可以 与动作31-2关于哪个报头压缩上下文的确定相联系。 234/动作31-5包含确定包索引并导出会话密钥。前文已经解释了会话 密钥的导出，且会话密钥的导出也可以依赖于加密算法。此动作获得 作为输出的反映纟皮加密处理的包的次序的正确排序。
235/
动作31-6包含依照正纟皮使用的特定解密算法对包的加密部分解 密(例如，脱密(decrypting))。如上所述，加密算法可以类似于诸 如按照Baugher M等人的《安全实时传输协议(SRTP)》(Baugher M. et al.， 777e to歸2>薩,,尸ratoco/卩朋巧，IETF RFC 3711 , March 2004)的解密。
236/
动作31-7包含将作为结果的已解密数据包拆包，例如通过处理诸 如反馈、分割、校验和等的报头压缩信道信息的余下部分进行拆包。 237/
动作31-8包含将已解密包的整个已压缩报头部分解压缩，形成未 压缩报头UH。如果适用，动作31-9可包含更新加密上下文中的必要 参数。动作31-10包含向上层(例如，网路层，例如，IP协议栈(例 如，相对于OSH莫型中的层3))传递已解密且已解压缩的数据报。
238/
图31中的动作次序可以变更。例如，动作31-3与动作31-4之间 的次序可以对调。 239/
图33示出了基于RoHC的示例实施方案。这里所述的技术使"安 全协约"在同一RoHC信道上与其它RoHC协约共存成为可能。这意 味着该功能可以由报头压缩流开启/关闭。然而很可能要求指定新的信 道参数，包括用于RoHC信道协商的参数。
3.3:安全报头压缩若千优势
241/
如上所述或文中以其他方式包括的安全报头压缩技术具有许多 优势，下面列举其中的一些优势。第一例优势是开销最小化使用在如所提出的组合中，该技术不要求下层在独立加密层之前引入它们自 己的排序。这减少了在这些下层的开销。
242/
第二例优势是对现有标准与体系结构的影响。此外，安全报头压 缩技术扩展了如这里建议的报头压缩的功能，也不排除下层具有它们 自己的用于解密与重排序的功能。使用在如所提出的组合中，安全报 头压缩技术允许下层在独立加密层之前关闭它们的排序与按序传递 机制。这减少了总开销。换句话说，这不是层违规或交叉层综合。然 而，不需要定义新的压缩算法(例如，RoHC协约)并将之标准化。
243/
第三例优势是对 一 般报头压缩的实用性，尤其适用于大多数 ROHC协议，包括但不限于ROHC RTP ( 0x0001 ) 、 UDP ( 0x0002 )、 IP ( 0x0004 ) 、 ESP ( 0x0003 ) 、 TCP ( 0x0006 ) 、 UDP-Lite ( 0x0008 )、 RTP/UDP-Lite (0x0007)才艮头压缩协议。该技术也特别关联到但不限 于诸如序列密码的密码算法与加密算法，例如利用位屏蔽来允许只对 特定位加密/不加密。这种序列密码的实例包括A5、 GEA、 UEA以及 AES。其它相关的使加密与加密算法是那些利用排序信息来导出加 (解)密所需参数的算法。
4.0:序号共享概述
245/
在其一种形态中，该技术的共享事务处理是诸如序号共享的共享 信息。换句话说，在该技术的本形态中， 一个功能层使用来自另一个 功能层的排序信息。基本上，加密和/或报头压缩和/或净载荷压缩和/ 或信令压缩中的任意进程使用的排序信息均导出于另 一进程，即加密 和/或才艮头压缩和/或净载荷压缩和/或信令压缩中的任意另 一进程。
246/
报头压缩通常使用序号的某一形式，有时被称为主序号(MSN ), 基于所述形式通过建立依照关于该序号的变化模式的功能正常地压 缩其它字段。该序号从正被压缩的协议字段导出，或由压缩器在本地生成。
247/
密码(例如，加密)通常使用排序信息的某一形式，基于所述形 式在加密上下文的协作下导出会话密钥。 248/
在序号共享的第一方式中，报头压缩器首先压缩包的报头，并向 加密进程移交其序号。加密进程(ciphering process)使用该序号来导出 会话密钥，并3于包进4亍力口密处理(processes the packet with encryption)。
249/
在序号共享的第二方式中，加密(密码)功能可以使将^皮加密下 一次(在其加密操作中)用于报头压缩器的序号可用。报头压缩器使 用这个序号作为它的MSN并压缩该包，且将已压缩包交给加密进程。 然后，力口密进程(encryption process)使用该同一序号来导出会话密 钥，并进行加密处理(processes with encryption)。如果适用，该排序 信息就在加密协议内载运。
250/
换句话说，在第二方式中，排序(例如，序号)由加密功能产生， 且加密功能使排序可用于报头压缩功能。在压缩(解压缩)时该压缩 (解压缩)功能将该排序用作主序号(MSN)。 251/
加密与压缩一般被视为分开的进程。传统方式中，加密执行于IP 终端主机(剩下多数不可压缩的净艮头)之间、应用程序(不可检测， 因而中间系统不能打开/关闭它们自己的加密)之间，或者执行于在物 理媒体上的发送器与接收器之间(被定位到相邻节点，除非可保证排 序)。
252/
在这里所述的序号共享的任一种方式中，加密适配层可以^皮视为 是才艮头压缩。图34将加密与压缩的传统分离(如图34左边所示)和 这里所述的序号共享和组合或合并的压缩进程与加密进程(如图34右边所示)做了比较。基本上，连同报头压缩而执行净载荷的加密。 无论是最终从压缩功能获得还是从加密功能获得，报头压缩主序号
(MSN)被用来从加密上下文中导出会话密钥。加密功能使用序号 MSN来从加密上下文中隐含地导出会话密钥。用报头压缩排序将加密 施加于包的对应于净载荷的部分。同一序号MSN^皮压缩进程用于压 缩才艮头，如图34的RoHC压缩所示。 253/
在序号共享方面，随着使用用于压缩以导出会话密钥的主序号 (MSN)在正被压缩的包的净载荷上执行加密，加密与压缩以SRTP 方式有效结合。加密有益于编码的鲁棒性特征，所述编码根据关于其
自身同步要求的损失与重排序用于MSN。 254/
示例设备包括两个对应节点(相邻的或不相邻的)，在所述节点 内执行压缩与加密(例如在3GPPRAN2中为SAE/LTE所定义的接 入网关)。密码转换与密钥导出算法(如在Baugher M等人的(f姿全 美/7,#翁鈔议"i 7P ，》(Baugher M. et al., 77^ Secwre Aea/-">we 7Vamport Pratoco/ (SK7P」，IETF RFC 3711 , March 2004 )中所述的) 使用来自于压缩算法(例如，RoHC)的主序号(MSN)来对净载荷 加密与解密。这样做意味着密码会话密钥导出算法的鲁棒性另外继承 了 MSN在压缩/加密端点之间的抗丟失包与重排序的鲁棒性特征。
255/
所以，可以在同一节点中，尤其带RoHC的同一节点中，与l艮头 压缩一起执行加密，从而减少了具有单独排序的开销且增强了解密的 密钥导出机制的鲁棒性。
256/
可以有用于加密进程配置的附加的外部协商机制，RFC3095中已 定义的协约及其它派生协约(假如没有ESP扩展报头)可以不作修改 就使用。重排序中的可能改进是使若干最小包格式无效。
4.1:序号共享示例实施方案258/
在图35为示例的、非限制的实施方案中，示出了对于具有组合 的或合并的压缩进程与加密进程的发送节点与接收节点所执行的基 本的、有代表性的动作或事件，其中压缩进程与加密进程共享序号。 如图35所述的动作系列既可应用于序号共享的第一方式(在此方式 中压缩进程选定或选择序号MSN)，又可应用于序号共享的第二方式 (在此方式中加密进程选定或选择序号MSN)。图36与图37以流程 图形式分别图解了发送节点与接收节点的动作。
259/
图36描述由发送节点的压缩器逻辑执行的基本动作或者管理的 基本事件。动作36-l (参见图36)包括确定使用哪个压缩上下文；动 作36-2包括确定使用哪些加密上下文。如前所述，压缩上下文的确定 与加密上下文的确定可以相联系。
260/
动作36-3包括确定MSN的值。在此形态的第一方式中，压缩进 程维持或产生序号MSN(例如，基于报头压缩的协议或根据本地维持 的值)。在第二方式中，从加密进程中获取序号MSN作为下一序号， 加密进程将该下 一序号在加密操作中将用于排序。
261/
动作36-4包括包的净艮头的实际压缩。如前所述，包可以含有诸如 RTP报头、UDP报头以及IP报头的多个报头，所有这多个报头可构 成如图398-1所示的包的l良头。
262/
动作36-5包括使用MSN (它#1用来压缩包的净艮头)的未压缩表 示法，并连同例如滚动计数器(rollover counter)使用密钥导出算法、 加密上下文中的最高MSN以及用于压缩包的报头的MSN的未压缩表 示法来确定包索引。
263/
动作36-6包含根据恰好使用的特定加密算法对包的净载荷加密。这就成为该包的4支加密部分。该算法可以是类似于例如按照Baugher M等人的(f安全;^^传,錄议"W7P ", (Baugher M. et al., 27^ Seethe i^"Z-"we rra"^oW尸ratoco/ f5^r尸人IETF RFC 3711 ， March 2004 )的 加密。 264/
动作36-7包含更新加密上下文中的必要参数，如果适用。 265/
动作36-8包含将包的已压缩报头与已加密部分以及诸如反馈、分 割、上下文标识、校验和等的剩余"^艮头压缩信道信息组包。 266/
动作36-9包括向下层(例如，i某体4妄入控制层(MAC)或RLC 层)传递结果得到的数据报。 267/
图36中的动作次序可变更。例如，动作36-1与动作36-2间的次 序可以调换。同样，动作36-5、动作36-6及动作36-7可以整体与动 作36-4调换。
268/
图37描述由接收节点的解压缩器逻辑执行的基本动作或者管理 的基本事件。动作37-l (参见图37)包括通过处理诸如反馈、分割、 上下文标识、校验和等的报头压缩信道信息，将从下层接收的数据报
拆包。 269/
动作37-2包含确定使用哪个压缩上下文。动作37-3包含确定使 用哪个加密上下文(压缩上下文的确定与加密上下文的确定可以再次 被结合)。
270/
动作37-4包含将序号MSN解压缩。动作37-5包^^f整个已压缩 报头部分解压缩。 271/报头解压缩的MSN的未压缩表示 法，并连同例如滚动计数器(rollovercounter)使用密钥导出算法、力口 密上下文中的最高MSN以及用于压缩包的寺艮头的MSN的未压缩表示 法来确定包索引。
272/
动作37-7包含4姿照解密算法对包的加密部分解密(脱密)。如前 所述，加密/解密可以类似于例如按照BaugherM等人的(f安全豸^传 翁錄、议6S7^r尸 》(Baugher M. et al.， Me Secwe i^a/-"we rra"^oW 尸ratoco/ 「SWr", IETF RFC 3711 , March 2004 )的描述。
273/
动作37-8包含更新加密上下文中的必要参数，如果适用。动作 37-9包含向上层传递数据包。 274/
图37的动作次序可更改.。例如，动作37-2与动作37-3间的次序 可以调换。同样，动作37-5、动作37-6及动作37-7可以整体和动作 37-5调换。
4.3:序号共享若干优势
276/
这里所述的序号共享的技术、方法、实施方案以及系统有许多优 点，包括但不限于(1)开销最小化；(2)对现有标准与体系结构的 影响小；(3)互利互惠并改善加密上下文的鲁棒性；以及(4)适用 于普通报头压缩。
277/
第一例优势是开销最小化。序号共享技术可以用来扩展由鲁棒才艮 头压缩提供的功能，以包括向加密功能提供排序信息。当将序号共享 技术与使用不扩展净载荷的密码转换结合起来时，这可能特别有用。
278/
第二例优势是对现有标准与体系结构的影响小。本方案对目前的 系统结构与目标系统的影响也非常小，尤其在才艮头压缩实施方案内的加密适配层不要求对现有报头压缩算法或其规范作任何修改。所要求
的仅仅是应该在基于压缩MSN激活加密之前执行就加密用法(和用
于加密的参数)的协商(可能在带外)。此外，这里所述的报头压缩 的功能扩展并不排除下层拥有它们自己的用于加密与重排序的功能。 使用在如所提出的组合中，它允许下层在独立加密层之前关闭它们的 排序与按序传递机制。这减少了总开销。换句话说，这不是层违规或 交叉层综合。
279/
第三例优势是互惠互利并改善加密上下文的鲁棒性。加密功能受 益于对于排序信息的报头压缩算法的鲁棒性特征，且因此降低了加密 上下文丟失对排序的同步的可能性。要是发生了丟失对于排序的同 步，再同步将从"l艮头压缩算法的恢复机制的内部发生。加密功能不会 带来报头压缩算法的上下文损害，因为它只处理包的非压缩部分。在 这点上，加密功能与报头压缩功能不会相互带来消极影响，而报头压 缩代表加密算法照顾到排序鲁棒性并节省开销。
280/
第四例优势是对一般净艮头压缩的适用性。这种适用性是突出的， 例如，可用到大多数ROHC协约，包括但不限于ROHC RTP( 0x0001 )、 UDP ( 0x0002 ) 、 IP ( 0x0004 ) 、 ESP ( 0x0003 ) 、 TCP ( 0x0006 )、 UDP-Lite (0x0008) 、 RTP/UDP-Lite (0x0007)才艮头压缩协约。该技 术还尤其关系到但不限于诸如序列密码的译成密码算法与加密算法， 例如利用位屏蔽来允许只对特定位加密/不加密。这种序列密码的实例 包括A5、 GEA、 UEA以及AES。其它相关的译成密码与加密算法是 那些利用排序来导出加(解)密所需的参数的算法。
281/
依照序号共享技术，将加密与压缩算法结合应用到包数据。该加 密使用例如基于加密的加法序列密码的密码转换，所述加法序列密码 使用会话密钥导出用的索引。所用的索引是压缩协议的主序号 (MSN)。282/
加密和/或才艮头压缩和/或净载荷压缩和/或信令压缩中的任意进程 使用的排序信息导出于另一进程，即加密和/或才艮头压缩和/或净载荷 压缩和/或信令压缩中的任意另外一个进程。
283/
加密和/或l艮头压缩和/或净载荷压缩和/或信令压缩中的任意进程 使用来自于另 一功能性进程的排序信息，所述功能性进程是加密和/ 或才艮头压缩和/或净载荷压缩和/或信令压缩中的任意进程。
284/
尤其，当加密和/或才艮头压缩和/或净载荷压缩和/或信令压缩中的 任意进程使用排序信息时，该排序信息来自于报头压缩功能。 285/
排序由加密进程产生，并使排序可用于报头压缩算法。压缩使用 该排序作为其压缩时的主序号(MSN)。 286/
例如，前述的方法适用于其中根据鲁棒"^艮头压缩(ROHC)协议 而执行压缩算法的特定场合，所述鲁棒报头压缩(ROHC)协议包括 但不卩艮于ROHCRTP (0x0001 ) 、 UDP (0x0002) 、 IP (0x0004)、 ESP ( 0x0003 ) 、 TCP ( 0x0006 ) 、 UDP國Lite ( 0x0008 ) 、 RTP脂P-Lite (0x0007 )报头压缩协议。
287/
例如，前述的方法可适用于其中根据任意其它 一般的压缩方案而 执行报头压缩器和/或报头解压缩器时的一些特定场合。 288/
例如，前述的方法适用于密码算法与加密算法是序列密码的具体 示例，包括但不限于A5、 GEA、 UEA以及AES。利用排序信息来导 出加(解)密所需的参数的其它密码算法与加密算法也在本发明范围 内。
289/例如，前述的可应用到其它压缩算法，例如诸如SigComp的信令 压缩、净载荷压缩算法(例如那些在PereiraR.的(f炎^7D五i^47E ^ /尸净4'7f在鎵》(Pereira, R. /尸尸a少/oa(i Com; m^o" D￡7^L4r￡", IETF RFC 2394, December 1998)以及Friend R与R. Monsour的(T犮 y5 7 LZS W /尸净我'秀；裙》(Friend, R. et R. Monsour, /尸尸ay/oad Cow; m^,'朋f/y/"g丄ZS, IETF RFC 2395, December 1998 )中所定义 的)，或者可应用到要求排序与校验和的任意别的操作，用于排序与 校验和的这种信息可以被别的算法共享，该信息起源并终止于相同节 点。
290/
例如，前述的方法适用于aGW， aGW当前在3GPP RAN 2标准 化工作组中被定义为SAE/LTE操作的组成部分。 291/
这里所述的技术、方法、实施方案以及系统有许多优点，包括但 不限于(l)开销最小化；(2)对现有标准与体系结构的影响小；(3) 与加密上下文的互利互惠及加密上下文的增强鲁棒性；以及(4)对 普通寺艮头压缩的可应用性。
292/
尽管以上的描述包含许多特征，但是这些特征不应纟皮解释为限制 本发明的范围而应被解释为仅仅提供若干目前优选实施方案的例证。 可以理解本发明的范围完全包括对本领域熟练技术人员而言显而易 见的其它实施方案，且可以理解该范围因此不是限制性的。与上述优
选实施方案的要素对应的结构上、化学上及功能上的、对本领域的普 通技术人员而言已知的等同物被明确地合并在这里，且确定为被包含 在这里。而且，因此对装置或方法而言，描述所找到的要由本发明解 决的每个问题是没有必要的，因为本发明将包括该装置或方法。
权利要求
1. 一种操作包括发送节点(20)与接收节点(22)的远程通信网络的方法，其特征在于在所述发送节点(20)处对包的报头部分的至少一部分执行压缩并对所述包的至少一部分执行加密，从而使所述压缩与所述加密相结合到在所述接收节点(22)处所述包的解压缩验证与解密验证成为相互依存的程度。
2. 权利要求l所述的方法，还包括(1) 对于在所述发送节点(20)处的进入包，对所迷进入包的 压缩候选部分与所述进入包的加密候选净载荷部分确定初始校验和， 并在至少部分已压缩与至少部分已加密的"l妄口穿越包中包含所述初 始校验和；以及(2) 对于在所述接收节点(22)处收到的所述接口穿越包，在 执行所述解密与所述解压缩以获得复原包后，对所述复原包确定验证 校验和，并用所述验证校验和与所述初始校验和的比较来确定所述解 密和所述解压缩这二者的验证。
3. 权利要求2的方法，其中，动作(1)包含在位于所述发送节 点(20)处的所述进入包上执行以下动作(l-a)对所述进入包的所述压缩候选部分与所述进入包的所述加 密候选净载荷部分确定所述初始校验和；(l-b)对所述进入包的所述压缩候选部分执行压缩以提供压缩串；(l-c)至少对所述进入包的所述力口密候选净载荷部分加密以提供 力口密串；(l-d)通过在所述接口穿越包中至少包含所述压缩串、所述加密 串与所述初始校验和，形成对应于所述进入包的所述接口穿越包；以 及其中，动作(2)包含在位于所述接收节点(22)处的所述接口穿越包上执行以下动作(2-a)解密所述接口穿越包的所述加密串以提供解密串； (2-b)解压缩所述接口穿越包的所述压缩串以提供解压缩串； (2-c)以对应于动作(l-a)中确定所述初始才交—验和的方式对所述解压缩串与所述解密串确定所述验证校验和；(2-a)的解密与动作(2-b)的解压縮这二者的验证。
4.权利要求3所述的方法，其中，所述至少对所述进入包的所述 加密候选净载荷部分加密以提供加密串的动作，还包括对所述进入包 的所述压缩候选部分加密以包含在所述加密串中。
5. 权利要求3所述的方法，其中，至少对所述进入包的所述加密 候选净载荷部分加密以提供加密串的所述动作，还包括对所述初始校 一险和加密以包含在所述加密串中。
6. 权利要求3所述的方法，还包括下述动作(2-e)根据动作(2-d)的所述验证更新压缩上下文；以及 (2-f)根据动作(2-d)的所述验证更新加密上下文。
7.权利要求1所述的方法，还包括 (1)对于在所述发送节点(20)处的进入包，对所述进入包的 压缩候选部分的至少一部分确定初始校验和，所述压缩候选部分包含 序号，并在一个至少部分已压缩且至少部分已加密的"t妄口穿越包中包 含所述初始4交-验和；以及(2)对于在所述接收节点(22)处收到的所述接口穿越包，在 获得所述序号并执行解密与解压缩以获得复原包后，对所述复原包确 定验证校验和并用所述验证校验和与所述初始校验和的比较来确定所述解压缩的验证。
8. 权利要求7所述的方法，其中，动作(1)包括在所述发送节点(20)处对所述进入包执行以下动作(l-a)确定所述初始校验和，所述初始校验和对于如下部分确定 所述进入包的所述压缩候选部分，所述压缩候选部分包含所述序 号；以及(可选地)所述进入包的加密候选净载荷部分，所述进入包的所 述加密候选净载荷部分为会话密钥之导出而使用所述序号；(l-b)对所述进入包的所述压缩候选部分执行压缩以提供压缩串；(l-c)至少对所述进入包的所述加密候选净栽荷部分加密以提供加密串；(l-d)通过在所述接口穿越包中至少包含所述压缩串、所述序号与所述初始校验和，形成对应于所述进入包的所述接口穿越包；其中，动作(2)包括在所述接收节点(22)处对所述接口穿越包4丸行以下动作(2-a)从所述接口穿越包获得所述序号； (2-b)解密所述接口穿越包的所述加密串以提供解密串； (2-c)解压缩所述接口穿越包的所述压缩串以提供解压缩串； (2-d)以对应于动作(l-a)中所述初始校验和之确定的方式，至少对所述解压缩串并可选地对所述解密串确定所述验证校验和；(2-c)的所述解压缩的验证。
9. 权利要求8所述的方法，其中，所述至少对所述进入包的所述 加密候选净载荷部分加密以提供加密串的动作，还包括对所述进入包 的所述压缩候选部分的至少一部分加密以包含在所述加密串中。
10. 权利要求8所述的方法，其中，所述至少对所述进入包的所 述加密候选净载荷部分加密以提供所述加密串的动作，还包括对所述 初始校验和加密以包含在所述加密串中。
11. 权利要求8所述的方法，还包括下述动作(2-e)根据动作(2-e)的所述验证更新压缩上下文；以及 (2-f)根据动作(2-e)的所述验证更新加密上下文。
12. —种远程通信网络的包发送节点(20),其特征在于配置 成对包的^艮头部分的至少一部分执行压缩并对包的至少一部分执行 加密，从而使所述压缩与所述加密相结合到所述包的解压缩验证与解 密验证成为相互依存的程度。
13. 权利要求12所述的装置，其中，对于在所述发送节点(20) 处的进入包，所述包发送节点(20)配置成对所述进入包的压缩候选 部分并对所述进入包的加密候选净载荷部分确定初始校验和，并在一 个至少部分已压缩且至少部分已加密的4妄口穿越包中包含所述初始 校验和，以通过接口传输。
14. 权利要求12所述的装置，其中，对于在所述发送节点(20) 处的进入包，所述包发送节点(20)配置成对所述进入包的压缩候选 部分的至少一部分确定初始校验和，所述压缩候选部分包括序号，所 述节点还配置成在至少部分已压缩与至少部分已加密的接口穿越包 中包含所述初始校验和，以通过接口传输。
15. —种远程通信网络的包接收节点(22),其特征在于所述 包接收节点(22)配置成可执行包的解压缩与解密，在所述包上(1) 已对其报头部分的至少一部分执行了压缩并(2)已对其至少一部分 执行了力口密，从而使所述压缩与所述加密相结合到由所述包接收节点(22)执行的解压缩与解密的验证成为相互依存的程度。
16. 权利要求15所述的装置，其中，所述包接收节点(22)配置 成根据所述验证来将压缩上下文与加密上下文这二者更新。
17. —种操作包括发送节点(20)与接收节点(22)的远程通信 网络的方法，其特征在于(1) 对于在所述发送节点(20)处的进入包，加密所述包的已 压缩报头但具有报头压缩信道信息的字段除外，并在接口穿越包中包 含已加密的已压缩才艮头；以及(2) 对于在所述接收节点(22)处收到的所述接口穿越包，从 所述报头的具有报头压缩信道信息的字段获得信息，并将所述接口穿 越包的所述已压缩报头解密。
18. 权利要求17所述的方法，其中，具有报头压缩信道信息的所 述报头的字段包括多路复用标识符(MUX ID)、已压缩l艮头格式 类型标识(FMTID)、主序号(MSN)以及压缩算法标识符(CAI)。
全文摘要
一种操作远程通信网络的方法，包括在发送节点(20)处，对包的报头部分的至少一部分执行压缩并对所述包的至少一部分上执行加密，从而使压缩与加密相结合到在接收节点(22)处所述包的解压缩验证与解密验证成为相互依存的程度。
文档编号H04L29/06GK101421972SQ200780013146
公开日2009年4月29日 申请日期2007年4月11日 优先权日2006年4月12日
发明者G·佩勒蒂尔, K·斯万布罗 申请人:艾利森电话股份有限公司