CN101421973B - 具有共享事务处理的多个远程通信功能的方法和装置 - Google Patents

Abstract

一种远程通信网络的节点包含配置成对由该节点处理的包的第一部分执行第一操作的第一功能(30)和配置成对该包的第二部分执行第二操作的第二功能(32)。第一功能(30)与第二功能(32)配置成可使用操作于该包的共享事务处理(34)，因而借助于该共享事务处理(34)，在执行第一操作与第二操作后，该包的可归于第一功能(30)与第二功能(32)的开销比不在第一功能与第二功能的执行中使用共享事务处理(34)时少。

Description

具有共享事务处理的多个远程通信功能的方法和装置

技术领域

1/ 

本发明涉及远程通信中的数据包的处理，包括但不限于在远程通信中执行诸如数据包的加密与压缩的操作。 

背景技术

2/ 

诸如远程通信系统等连网系统一般被分为多层。例如，国际标准化组织(ISO)已经开发了开放系统互联(OSI)连网模型(也称为OSI七层模型)，并在OSI 7498中作了描述，其内容通过引用结合于本文。七层OSI模型(如图38所示)分层(从底层即第一层到顶层即第七层)如下：物理层、数据链路层(即“链路”层)、网络层、传输层、会话层、表示层以及应用层。(原文)说明书中所用的“modellayer(模型层)”与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/ 

报头压缩是使诸如语音业务与视频业务等无线IP业务经济上可行的重要因素。报头压缩(HC)这一术语涵盖在点对点链路上使载运在基于每跳(per-hop)的报头中的信息所用的必要带宽最小化的技术。报头压缩解决方案已经被IETF的鲁棒报头压缩(ROHC)工作组开发来改善这类业务的效率。 

7/ 

一般而言，报头压缩方法在互联网社区已使用了超过十年；现有几个常用的协议，例如RFC 1144(Van Jacobson的《压缩低速串行链路的TCP/IP报头》(Van Jacobson，Compressing TCP/IP Headers forLow-Speed Serial Links，IETF RFC 1144，IETF Network Working Group，February 1990))、RFC 2507(Mikael Degermark、 

Nordgren、Stephen Pink的《IP报头压缩》(Mikael Degermark， 

Nordgren，Stephen Pink；IP Header Compression，IETF RFC 2507，IETFNetwork Working Group，February 1999))以及RFC 2508(StevenCasner、Van Jacobson的《压缩低速串行链路的IP/UDP/RTP报头》(Steven Casner，Van Jacobson，Compressing IP/UDP/RTP Header forLow-Speed Serial Links；IETF RFC 2508，IETF Network Working Group，February 1999))。 

8/ 

报头压缩利用这样的事实，即报头中的一些字段在流中不作改变，或者以小的和/或可预测的值进行改变。报头压缩方案利用这些特征，仅在最初发送静态信息，而变化字段用其绝对值或作为差值从包发送到包。至于完全随机的信息，则必须以不做任何压缩的形式发送。 

9/ 

报头压缩通常表征为两个状态机间的交互作用，一个状态机是压缩器而另一状态机是解压缩器，每个状态机保持一些与在上下文中被压缩的流相关的信息。 

10/ 

压缩上下文包含并保持关于过去包的相关信息，并用这种信息来压缩与解压缩后续包。如2001年4月的IETF RFC 3095中CarstenBormann等人的《鲁棒报头压缩(ROHC)：框架与四个协约(profiles)：RTP、UDP、ESP及未压缩》(Carsten Bormann，et al.RObust HeaderCompression(ROHC)：Framework and four profiles：RTP，UDP，ESPand uncompressed.IETF RFC 3095，April 2001)所述(通过引用而结合于本文)： 

压缩器的上下文是用来压缩报头的状态。解压缩器的上下文是用来解压缩报头的状态。在清楚使用哪一个时，这二者中的任一个或这二者的结合通常被称为“上下文”。上下文含有来自包数据流中的先前报头的相关信息，比如静态字段和用于压缩与解压缩的可能的基准值。此外，描述包数据流的附加信息也是上下文的组成部分，例如关于IP标识符字段如何变化和关于典型的包与包之间序号或时间标记增加的信息。 

11/ 

保持压缩器状态与解压缩器状态(称为上下文)相互一致同时保持报头开销尽可能低是具有挑战性的任务。有一个状态机用作压缩器，并有一个状态机用作解压缩器。压缩器状态机直接影响压缩效率的高低，因为它是用于控制要发送的已压缩包类型的选择的逻辑的重要组成部分；解压缩状态机的作用主要是提供用于反馈(如果可用)的逻辑并识别可尝试进行解压缩的包类型。 

12/ 

给解压缩器提供方法来验证成功解压缩成功的包是上下文更新包。由于解压缩可以被检验，所以这种类型的包可以更新上下文。对 于ROHC，上下文更新包类型在其格式内携带循环冗余码(CRC)；这是在原始未压缩报头上计算出的校验和。该CRC被用来检验每个包的解压缩成功；验证成功时，该上下文可被更新。 

13/ 

依赖其它方法来保证解压缩成功的包，即没有给解压缩器提供方法来验证成功解压缩成功的包格式的包，该包是独立包，只携带自身的解压缩所需的信息，则该包。这些包不更新上下文。 

14/ 

报头压缩使用序号来唯一标识各个包。在报头压缩中，通常基于序号(SN)的功能来压缩字段。既可以从协议中导出这种处于压缩的序号(例如，RTP SN)，也可以由压缩器产生这种序号。在本文中，当二者之间的区别不相关时，这种序号称为主序号(MSN)。 

15/ 

早期报头压缩协约(header compression profile)的设计使用如下假设：压缩器与解压缩器间的信道不对报头压缩包重排序，且要求该信道保持用于每个已压缩流的包排序。这一假设的动因是最初考虑使用RoHC的潜在候选的信道保证包的按序递交；这种假设有助于改善压缩效率与包丢失容限(tolerance against packet loss)，这两项目标在当时被列为最高要求。 

16/ 

除了其它改进，当前正在开发的RoHCv2协约将处理压缩协议内的压缩端点之间的不按次序的递交以及编码方法本身。 

17/ 

许多不同类型的压缩可以在链路层以上使用。这些压缩包括净载荷压缩(例如参见Pereira R.的《使用DEFLATE的IP净载荷压缩》(Pereira R.，IP Payload Compression Using DEFLATE，IETF RFC 2394，December 1998)；以及Friend R.与R.Monsour的《使用LZS的IP净载荷压缩》(Friend R.et R.Monsour，IP Payload Compression Using LZS，IETF RFC 2395，December 1998))、信令压缩(例如参见Price R.等 人的《信令压缩(SigComp)》(Price，R.et al.，Signalling Compression(SigComp)，IETF RFC 3320，January 2003))、报头去除与再造以及报头压缩。例如，关于报头压缩参见Van Jacobson的《压缩低速串行链路的TCP/IP报头》(Van Jacobson，Compressing TCP/IP Headers forLow-Speed Serial Links，IETF RFC 1 144，IETF Network Working Group.February 1990)；Mikael Degermark、 Nordgren、Stephen Pink等人的《IP报头压缩》(Mikael Degermark， 

Nordgren，Stephen Pink；IP Header Compression，IETF RFC 2507，IETF Network Working Group，February 1999)；Steven Casner与Van Jacobson的《压缩低速串行链路的IP/UDP/RTP报头》(Steven Casner，Van Jacobson，CompressingIP/UDP/RTP Headers for Low-Speed Serial Links；IETF RFC 2508，IETFNetwork Working Group，February 1999)；Koren T.、Casner S.、Geevarghese J.、Thompson B.及P.Ruddy等人的《用于高时延、包丢失与重排序的链路的增强压缩RTP(CRTP)》(Koren T.，Casner S.，Geevarghese J.，Thompson B.and P.Ruddy，Enhanced Compressed RTP(CRTP)for Links with High Delay，Packet Loss and Reordering，IETFRFC 3545，IETF Network Working Group，July 2003)；Carsten Bormann等人的《鲁棒报头压缩(ROHC)：框架与四个协约：RTP、UDP、ESP及未压缩》(Carsten Bormann，et al.RObust Header Compression(ROHC)：Framework and four profiles：RTP，UDP，ESP anduncompressed.IETF RFC 3095，April 2001)；Jonsson L.与G.Pelletier的《鲁棒报头压缩(ROHC)：用于IP的压缩协约》(Jonsson L.andG.Pelletier，RObust Header Compression(ROHC)：A compression profilefor IP，IETF RFC 3843，June 2004)；Pelletier G.的《鲁棒报头压缩(ROHC)：用于UDP-Lite的协议》(Pelletier G.，RObust HeaderCompression(ROHC)：Profiles for UDP-Lite，IETF RFC 4019，April2005)；以及Pelletier G.、Sandlund K.与L.Jonsson等人的《鲁棒报头压缩(ROHC)：协约或TCP/IP、Internet草案(进行中)》(Pelletier，G.，Sandlund，K.and L.Jonsson.Robust Header Compression(ROHC)：A Profile or TCP/IP，Internet Draft(work in progress).<draft-ietf-rohc-tcp-1 1.txt>，January 2006)。这些压缩类型的任一类型可被设计成使用序号与校验和。 

18/ 

也可以使用其它最优化(如其它类型的压缩)来进一步增强带宽受限系统的性能。 

B.报头压缩：检验

20/ 

鲁棒报头压缩使用在已压缩报头(例如，在初始化包内)上或者在未压缩报头(例如，在已压缩包中)上算出的校验和(CRC)。使用校验和来验证解压缩器上的正确的解压缩。更具体地说，例如，报头压缩通常使用校验和来验证其解压缩尝试的结果。该校验和可以是对于正被压缩的信息的未压缩状态计算的校验和，或者也可以是对于发送于压缩器与解压缩器之间的信息(已压缩信息、未压缩信息或压缩协议信息或这三种信息的任意组合中的任一种信息)计算的校验和。 

21/ 

同样，通常在解密进程前使用帧校验和序列(FCS)，以确保没有向解密算法递交的信息能够导致不正确的加密上下文。 

22/ 

未检测出的残差可能导致丢失对以上讨论的任何功能的同步，这取决于所使用的算法。 

23/ 

报头压缩可以使用安全基准原理来确保不能由于包丢失而失去压缩器与解压缩器间的上下文同步。基于解压缩器所收到的应答，压缩器确信解压缩器已经成功地从上下文更新包中更新了上下文。然而，以安全基准原理使用的大多数包类型是独立，因此按理不应该更新上下文。 

24/ 

压缩器通常只在接收到来自于解压缩器的用于上下文更新包(用反馈消息中的MSN来标识)的应答后才更新其压缩上下文。

25/ 

解压缩器通常在检验解压缩的结果后用已压缩报头(若出现在包格式中，则在用安全基准原理操作时不一定真实)内携带的循环冗余校验(CRC)来更新其上下文。受到速率限制，解压缩器通常向压缩器应答更新。 

C.安全/加密

27/ 

使用新的体系结构模型的演进与设计倾向于减少传输路径包含的节点数，并倾向于使用公开标准化的接口。这转而又改进了功能间的传统分离，也创建了新的对于安全性的可信模型。尽管互联网范例中安全性一般被视为通信主机之间的端到端功能，但安全机制也常设置在较低模型层中以解决低级安全问题。 

28/ 

就安全性而言，包数据流的加密通常要求发送端与接收端保持加密状态信息。该信息一般被称为加密上下文。 

29/ 

加密密钥可以是这种上下文的组成部分，例如加密转换可以直接使用一个“会话”密钥，而另一个“主”密钥可用来导出该会话密钥。该主密钥通常由密钥管理协议以安全方式给出。在上下文中可找到的其它参数往往是例如加密算法标识符、会话指示符、计数符、密钥长度参数等。这些参数中的许多参数专用于有效密码转换。 

30/ 

有些算法可基于与包关联的排序信息导出用于包的会话密钥。例如，安全实时基准协议(SRTP)(参见图1)基于包内携带的RTP序号来导出该包的索引。SRTP是OSI应用层协议，预定用来在向使用RTP/RTCP协议的实时应用程序提供端对端的安全层，如图2所示。例如，SRTP在Baugher M.等人的《安全实时传输协议(SRTP)》 (Baugher M.et al.，The Secure Real-time Transport Protocol(SRTP)，IETF RFC 3711，March 2004)中有描述。文中肯定了对密钥索引的导出存在限制，因为正确值的导出与加密上下文的更新对于大的包重排序敏感也对残留比特错误敏感。虽然所述的重排序量达到2¹⁵个包的次序且不太可能出现，但这突显了所存在的未检测到的比特错误对于安全层的可能影响，在安全层中错误的包可在错误的时间间隔中用索引错误地更新加密上下文，并破坏后续包的解密。 

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)覆盖被划分为小区的地理区域，基站服务于各个小区。小区是由在基站站点处的无线基站设备提供的无线覆盖范围的地理区域。各个小区由唯一的身份码标识，该身份码在小区内广播。基站在基站覆盖范围内通过空气接口(如射频)与用户设备(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接口”。 

44/ 

图4示出了传统体系结构的示例，这里示出的是使用UTRAN体系结构的范例。在UTRAN体系结构中尤为受关注的是功能之间的分为不同节点的传统分离：当无损重定位被支持(可选)时RNC处理排序，因而增加了用于一个序号的开销。加密在节点B(NodeB)内进行，且加密要求各SDU按序递交以维持加密上下文。为了确保该加密不释放(loose)同步，通常使用L2帧校验和序列(FCS)，增加用以在空气接口上传输的额外的八位组。 

45/ 

混合ARQ(Hybrid-ARQ)机制要求在各个码组的传输期间可靠地检测比特错误，因为它必须为RLC PDU检测传输失败以请求重传。因此，假定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)。S1接口支持包核心中的接入网关(aGW)与eNB节点之间的多对多(many-to-many)联系。S1接口提供对用于用户平面与控制平面业务量的传输的演进RAN无线资源的接入。S1基准点使MME与UPE分离能够进行，也能够实施组合的MME与UPE解决方案。 

50/ 

如图5所示，在SAE/LTE体系结构的当前建议中特别受关注的是RNC的去除。RNC节点的去除导致这样的事实，即加密功能与主持报头压缩功能的PDCP功能现在被设置在同一节点中，例如在aGW中或在eNB节点。加密功能与PDCP功能都端接到另一端的用户设备(UE)中。换句话说，aGW与eNB节点之间的接口被认为是不可信的。不可信意味着eNB节点可能在物理上受损。eNB节点通常处于远端位置，且如果eNB节点受损，那么大量的用户信息就有可能被盗用。因而S1接口要求将加密应用到用户业务，再向UE传播。S1接口上的安全隧道不解决eNB节点的信用问题。 

51/ 

一个关于在加密和/或PDCP实体之间的重排序的问题是S1接口或空气接口(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等人的《鲁棒报头压缩(ROHC)：框架与四个协约：RTP、UDP、ESP及未压缩》(Carsten Bormann，et al.RObust Header Compression(ROHC)：Framework and four profiles：RTP，UDP，ESP anduncompressed.IETF RFC 3095，April 2001)，也参见Pelletier G.、Sandlund K.及L.Jonsson等人的《鲁棒报头压缩框架，Internet草案(进行中)》(Pelletier G.，Sandlund K.and L.Jonsson，The Robust HeaderCompression(ROHC)Framework，Internet Draft(work in progress)，<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典型系统中，甚至在同一节点内的功能分层也会导致显著开销。对于下层的开销，下面的表1示出了层2功能与对应的开销(以八位组为单位)。 

59/ 

表1

60/ 

因此，本发明的目标在于提供用以减少与模型层2的功能(例如，链路层功能)关联的开销的一个或多个节点、装置、系统、方法或技术。 

发明内容

61/ 

一种远程通信网路的节点包括配置成在由该节点处理的包的第一部分上执行第一操作的第一功能与配置成在该包的第二部分上执行第二操作的第二功能。第一功能与第二功能配置成可使用共享事务处理和/或共享业务来对该包进行操作，依靠共享事务处理和/或共享业务，在执行第一操作与第二操作后，该包具有比要是在第一功能与第二功能的执行中不使用该共享事务处理和/或共享业务少的、可归于第一功能与第二功能的开销。 

62/ 

在一个示例实施方案中，该节点是系统体系结构演进/长期演进(SAE/LTE)远程通信网络的接入网关，并且是配置成可执行第一功能、第二功能以及共享事务处理和/或共享业务的链路层协议。 

63/ 

在另一示例实施方案中，该节点是系统体系结构演进/长期演进(SAE/LTE)远程通信网络的演进节点B(eNB)，并且是配置成可执行第一功能、第二功能以及共享事务处理和/或共享业务的链路层协议。 

64/ 

在一个示例实施方案中，该节点是系统体系结构演进/长期演进(SAE/LTE)远程通信网络的移动用户设备(UE)，并且是配置成可执行第一功能、第二功能以及共享事务处理和/或共享业务的链路层协议。 

65/ 

在本技术的一种形态中，共享事务处理和/或共享业务包括由第一功能与第二功能使用的共享信息。例如，在一个示例实施方案中，第一功能是数据压缩功能而第二功能是加密功能，且共享信息是由该压缩功能产生的作为该压缩功能的序号MSN的序号，且该序号也被加密功能用来为加密操作导出会话密钥。在另一示例实施方案中，第一 功能是数据压缩功能而第二功能是加密功能，且共享信息是由加密功能产生的、从中导出会话密钥的序号，且该共享信息也被压缩功能用作序号MSN。 

66/ 

在本技术的一种形态中，共享事务处理和/或共享业务包含也对该包的第一部分进行操作的第二功能。例如，在一个示例实施方案中，第一功能是数据压缩功能而第二功能是加密功能，且该加密功能对该包的报头的至少一部分加密(但不对该报头的压缩信道标识符加密)。 

67/ 

在本技术的一种形态中，共享事务处理和/或共享业务包含对于该包的第一部分的至少一部分与该包的第二部分的至少一部分确定校验和。在一个示例实施方案中，第一功能是数据压缩功能，该包的第一部分是包的报头；第二功能是加密功能，该包的第二部分是包的净载荷；对于包的报头的至少一部分与包的净载荷的至少一部分确定校验和。在另一示例实施方案中，共享事务处理和/或共享业务包含对于该包的第一部分的至少一部分确定校验和，该包的第一部分的校验和被确定的部分包括由在对该包的第二部分的操作中由第二功能使用的参数。例如，在一个其中包的第二部分是包的净载荷的实施方案中，对该包的报头的至少一部分确定校验和，并且在对该包的第二部分上的操作中由第二功能使用的参数是为其加密上下文导出会话密钥的序号。 

68/ 

因此，考虑到共享事务处理和/或共享业务以及实质组合或合并的功能性，提供方法与设备用于工作在相同端点的多项功能之间共享诸如排序信息与校验和信息等事务处理/信息。共享事务处理和/或共享业务技术适用于任意两个适当的发送节点与接收节点(不管它们相邻与否)，且该技术尤其(但非排它地)适用于其中链路层代表共享该同一信息的多个功能/进程维持并传输排序信息与/校验和信息的情形或体系结构。此外，其中使用该共享事务处理和/或共享业务技术的发 送节点无需是单个节点，而可包括可通过它们分配多项功能的多个发送节点。包含于本技术中的功能例如可以是报头压缩、报头去除与再生成、净载荷压缩、信令压缩、加密与重排序等功能中的任意功能，以及上述功能的任意组合。 

69/ 

因此，如上简述与如下进一步所述，报头压缩与加密(以及可能的其它功能)可共享排序信息与校验和，减少单独享有排序与校验和的开销。SAE/LTE体系结构为这种想法提供了候选系统，以应用于接入网关(aGW)、演进节点B(eNB)以及用户设备(UE)内。 

70/ 

这里所述的技术也包括基于RoHC排序在报头压缩协约内部引入安全功能(例如，加密)，并鲁棒地且无开销地实现该安全功能。例如，本技术包括为协约而将加密上下文管理功能绑定到报头压缩上下文管理的现有机制上。此外，本技术包括基于RoHC为信道上的所有协约引入安全功能(加密与鉴权)，以全面保护报头压缩信道。本技术还包括用于RoHC的相对全面的安全解决方案。 

附图说明

71/ 

在以下参照附图阐述的优选实施例的更具体的描述中，本发明前述的及其它的目标、特征和优势显而易见，附图中的附图标记指示遍及不同视图的相同部分。附图不必一定依比例画出，其重点在于阐述本发明的原理上。 

72/ 

图1是说明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是远程通信网络的示意图，其中，共享事务处理和/或共享业务包括不但对包的第二部分执行操作而且对包的第一部分执行操作的第二功能，所述包至少部分地受到第一功能的操作。 

87/ 

图15是远程通信网络的示意图，其中，共享事务处理和/或共享业务包括对包的一部分执行操作的加密功能，所述包至少部分地受到压缩。 

88/ 

图16是远程通信网络的示意图，其中，共享事务处理和/或共享业务包括确定共享校验和。 

89/ 

图17是远程通信网络的示意图，其中，共享事务处理和/或共享业务包括对于包的报头的至少一部分并对于包的净载荷的至少一部分确定校验和。 

90/ 

图18是远程通信网络的示意图，其中，共享事务处理和/或共享业务包括对于包的第一部分(例如，包的报头)的至少一部分确定校验和，该至少一部分包含在对该包的第二部分的操作中由第二功能使用的参数。 

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/ 

在以下的描述中，出于说明而非限制的目的，阐明了诸如特定的体系结构、接口、技术等的具体细节，以提供对本发明的彻底理解。然而，本领域技术人员清楚本发明可以应用到与这些具体细节不同的其它实施方案中。即，本领域技术人员能够设计出各种包含本发明的 原理以及本发明的要旨与范围内的装置，即使所述装置没有在这里明示。在一些实例中，省略了对众所周知的设备、电路与方法的详细描述，以免因非必需的细节而使本发明的描述不清晰。这里描述本发明的原理、形态与实施方式及本发明的具体实施例的所有陈述有意于包括其结构上与功能上的等同者。此外，确定这样的等同者既包括目前已知的等同者又包括在未来将开发的等同者，例如，可执行同一功能而不管其结构如何的任何被开发的单元。 

112/ 

因此，例如，本领域技术人员可以理解方框图在这里可以表示体现本技术原理的说明性电路的概念图。同样，也可以理解任意流程图、状态置换图、伪代码等代表各种进程，所述进程可以被大致表示在计算机易读媒体中，因此可以被计算机或处理器执行，无论这种计算机或处理器是否被明确示出。 

113/ 

通过使用专用硬件及能够执行与适当软件相关联的软件，可以提供包括被标示或描述为“处理器”或“控制器”的功能模块的各种器件的功能。当由处理器提供时，可以由单个专用处理器或多个单独的处理器提供这些功能，其中的一些功能可以是共享的或分布式的。而且，明确使用术语“处理器”或“控制器”不应被解释成排它地指能够执行软件的硬件，而是可以非限制地包括数字信号处理(DSP)硬件、用于存储软件的只读存储器(ROM)、随机存取存储器(RAM)以及非易失性存储器。 

1.0：多个功能共享的事务处理

115/ 

图9A示出了远程通信网络的两个节点20、22，这两个节点通过点划线24表示的接口进行通信。在图9A所示的特定情形中，节点20是发送节点而节点22是接收节点。这种发送节点与接收节点的指定参照包流的图示方向，其中从包源26获得的包被送到发送节点20。送到发送节点20的包由发送节点20处理，然后通过接口24向接收 节点22发送。可以理解包流也可以沿相反方向从接收节点22向发送节点20传播，但是出于描述本技术的显著形态之目的，考虑从发送节点向接收节点22的单向包流已足够。 

116/ 

节点20包括第一功能30与第二功能32，前者用来对由节点20处理的包的第一部分执行第一操作，后者用来对该包的第二部分执行第二操作。第一功能30与第二功能32可处于同一模型层内，且可以被分别认为是同一模型层的不同功能层。例如，第一功能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可以代表一个或多个(成组的)接口，诸如S1接口与Uu(空气)接口。 

121/ 

而且，在图10所述的示例实施方案中，设有并配置链路层协议46来执行第一功能30、第二功能32与共享事务处理34。在其它实施方案中，这些功能不需要全部由该链路层协议执行或主持。 

122/ 

为简明起见，图9A与图10示出包括第一功能30与第二功能32的作为单一节点的发送节点20。然而，这里所用的术语“节点”，尤其是发送节点，涵盖具有参与到共享事务处理技术中的功能的多个节点。换句话说，其中使用共享事务处理技术的发送节点不必是无需为单一节点，而可以包括多个节点，在所述多个节点上可以分配多重功能(例如，第一功能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/ 

基本上，一个包含排序信息的单字段代表多个进程被载运，而不管进程的什么组合是有效的。支持加密和/或报头压缩和/或净载荷压缩和/或信令压缩的层被用来载运排序信息。当一个以上功能层有效时，这种排序信息对多重功能层可以是公用的(例如，报头压缩与加密，或者其它组合)，且该排序信息可以由任一有效进程/算法产生(或者，如果同时执行或激活多个操作那么由多个有效进程/算法产生)。这种排序信息也可以源于在报头压缩进程和/或加密进程和/或净载荷压缩进程和/或信令压缩进程之下的层协议。或者，该排序信息也可以源于链路层之上的其它层，比如源于应用层(例如，源于诸如位于应用层的实时协议RTP的协议)。 

126/ 

例如，在图12所示的一个示例实施方案中，第一功能30是数据压缩功能而第二功能32是加密功能，共享信息34(12)是由压缩功能30起始的作为用于压缩功能30的序号MSN的序号。同一序号也被加密功能32使用来导出用于加密操作的会话密钥。 

127/ 

在如图13所示的另一示例实施方案中，其中第一功能30也还是数据压缩功能且第二功能32是加密功能，共享信息34(13)是由加密功能32起始的、从中导出会话密钥的序号，且该共享信息34也被压缩功能30用作序号MSN。 

128/ 

序号可作为用于压缩算法的共享序号的偏移量而导出。基本上，传输序号信息的压缩算法将此序号编码为从在多个功能层之间共享的序列编号的偏移量。 

129/ 

加密层通常对于连接执行操作，处理所有SDU，与这些SDU属于什么IP流无关。这可能对于压缩算法与压缩协议是相同的，但是这些压缩算法与压缩协议往往代之以对更细的粒度(granularity)级执行操作并按流对包执行处理以获得增强的压缩效率。在这种情况下，与对“连接”执行操作的其它层共享的序号将按SDU而不是按流上的包来改变值——除非该连接恰好映射到唯一的包流。 

130/ 

“按流”的压缩算法所见到的改变模式既依赖于在连接上的每个流的速率(可以是变化的)以及不同流的数目。然而，在序号中跳转的改变模式很可能被限制到有限值，且压缩算法可以基于共享序号(不是基于其绝对值就是基于偏移量)发送压缩比特(LSB或W-LSB)。也可在Carsten Bormann等人的《鲁棒的报头压缩(ROHC)：框架与4个协约：RTP、UDP、ESP以及未压缩》(Carsten Bormann.et al.RObust Header Compression(ROHC)：Framework and four profiles： RTP，UDP，ESP and uncompressed.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是加密功能，包的第二部分是包的净载荷。对于包的报头的至少一部分与包的净载荷的至少一部分确定校验和。以下，进一步描述该实施方案，特别(例如)参考本文的2.1节。 

135/ 

在图18所示的又一示例实施方案中，共享事务处理包括对于包的第一部分(例如，包的报头)的至少一部分确定校验和，且确定了校验和的该包的第一部分的的那部分包含在对该包的第二部分执行的操作中由第二功能使用的参数。例如，在包的第二部分是包的净载荷的实施方案中，对于包的报头的至少一部分确定校验和，并在对于包的第二部分执行的操作中由第二功能使用的参数是序号，用该序号为其加密上下文导出会话密钥。以下，进一步描述该示例实施方案，特别(例如)参考本文的2.2节。 

136/ 

因此，考虑到共享事务处理及一些本质上组合或合并的功能性，提供方法与设备用于在工作在相同端点的多重功能(例如，在同一模型层内操作的多个功能层)之间共享这种诸如排序信息与校验和信息等事务处理/信息。共享事务处理技术可应用到任意两个适当的发送与接收节点(不管所述节点相邻与否)，且特别(但不排他地)适合于其中链路层代表多个共享同一信息的多个功能/进程来保持并传输排序和//或校验和信息的情形或体系结构。而且，如先前参考图10B所解释，内部使用共享事务处理技术的发送节点不必是单一节点，而是可包括多个节点，通过这些接点可分配多个功能。本技术包含或定为目标的一些功能(例如，一些功能层)可以是(比如)报头压缩、报头去除与再生成、净载荷压缩、信令压缩、加密与重排序等功能中的任何功能，以及上述功能的任意组合。 

137/ 

如上简述与如下进一步解释，报头压缩与加密(以及可能的其它功能)可共享排序信息与校验和，减少单独拥有排序与校验和的开销。SAE/LTE体系结构为这种想法提供了候选系统，以被应用于接入网关(aGW)与用户设备(UE)内。 

138/ 

如链路层那样的层代表在相同端点内操作的多功能层(例如，加 密和/或净载荷压缩和/或报头压缩)来载运排序信息与校验和，并共享该同一信息。作为另一形态，当对于加密进程的会话密钥导出算法提供在压缩/加密端点之间的重排序与包丢失的鲁棒性时，至少部分地一起执行加密与报头压缩。而且，为使加密密钥导出的选择更稳健，与报头压缩的上下文管理协同进行加密上下文管理。 

139/ 

使用共享事务处理技术共享功能之间的事务处理可导致开销的减少，例如在哪些可设法使用同一信息并可在相同端点内操作的功能(例如鲁棒的报头压缩、报头去除、净载荷压缩、信令压缩和/或加密的任意组合中的任一)之间共享排序与校验和。例如，使用该共享事务处理技术，在一些实施例和/或实施方案中可以按表2的方式减少开销。 

140/ 

表2 

141/ 

如上所示，在可设法使用同一信息且在相同端点内操作的功能(例如鲁棒的报头压缩、报头去除、净载荷压缩、信令压缩和/或加密的任意组合中的任何功能)之间引入诸如共享的排序与校验和的共享事务处理，可以去除若干开销。接下来，基于但不限于RFC 3095的压缩器与解压缩器排序要求与行为，即Carsten Bormann等人的《鲁棒的报头压缩(ROHC)：框架与4个协约：RTP、UDP、ESP以及未压缩》(Carsten Bormann.et al.RObust Header Compression(ROHC)：Framework and four profiles：RTP，UDP，ESP and uncompressed.IETFRFC 3095，April 2001)，描述一些可能的示范性实施例。 

2.0：压缩上下文与加密上下文的组合管理：概述

143/ 

在其一种形态中，本技术涉及使用组合或共享的事务处理的压缩上下文与加密上下文的组合管理。在使用从压缩协议导出的排序与校验和(例如解压缩验证)来执行加密的时候，压缩算法的上下文管理规则被用于加密上下文的管理。该组合的上下文管理特征在于设有发送节点与接收节点，例如，发送节点在包的报头部分的至少一部分上执行压缩并在包的至少一部分上执行加密，从而压缩与加密被结合到在接收节点处包的解压缩验证与解密验证成为相互依存的程度。 

144/ 

在本形态的第一例方式中，共享的事务处理或组合的子操作包括在将被压缩的包的至少一部分与将被加密的该包的一部分上确定复合校验和。例如，在第一方式中，如在发送节点处所计算的校验和可以覆盖该包的所述部分的将被加密的(原未加密的)部分与将被压缩的(原未压缩的)部分。在接收方，加密层执行包的已加密部分的解密且解压缩器将已压缩部分解压缩(如果没有重叠，则可先进行任一处理)。在第一方式中，接着使用校验和来验证解压缩进程与解密进程这二者的结果，且当校验成功时导致相应的压缩上下文与加密上下文的更新。换句话说，如果验证了解压缩，则完成了解密且隐含地验证了解密。 

145/ 

在压缩上下文与加密上下文的组合管理的本形态的第二例方式中，组合的子操作包含用序号作为共享信息的压缩功能与加密功能，该序号被加密功能用于会话密钥导出。在第二方式中，在加密功能使用压缩主序号来从其加密上下文中导出会话密钥的情况下，校验和只需要覆盖(原未压缩的)将被压缩的、包括序号信息的部分。因此，在该第二例方式中，在将被压缩的包的至少一部分与(可选地)将被加密的包的至少一部分上计算校验和。在第二方式中，校验和仅被用来确认解压缩进程的结果，当成功时就导致对相应的压缩上下文与加密上下文进行更新。序号MSN因此被验证，且这是用于加密上下文 的唯一敏感信息。 

146/ 

在任一方式中，可以使用传输层(例如，UDP、TCP)校验和来进一步确认该进程的结果。上下文更新规则也遵循在第二方式中的压缩的上下文更新逻辑。 

147/ 

在同一节点中与报头压缩一起执行加密，可减少用于排序功能与重排序功能的开销。将加密特征与报头压缩特征组合到一个单一协议内可以是本技术的应用成果。该协议也可以包括对净载荷压缩的支持，同一类型规则也可能被用于此。 

148/ 

上下文管理在这里适用于整个压缩包或仅其子集(例如，仅净载荷被加密)被加密的情况。在这两种方式中，校验和有助于压缩操作与加密操作的验证。 

2.1：压缩上下文与加密上下文的组合管理：

第一方式：概述

150/ 

图19示出了第一例方式所包含的基本的、有代表性的示例动作或事件。动作19-1示出了在发送节点处执行的示例动作。尤其，对于发送节点处的进入包，在该进入包的压缩候选部分与加密候选净载荷部分上确定初始校验和。在至少部分已压缩与至少部分已加密的接口穿越包中包含该初始校验和。随后在接口上以如图9A中接口24的示例方式所述传输该接口穿越包。如先前所示，接口24可以是单一接口(例如在增强节点B的情况下的S1接口或Uu接口)，或者可共同代表诸如S1接口与Uu接口等几个接口。动作19-2示出了在执行解密与解压缩以获得复原包后，在接收节点处的接口穿越包的接收上执行的示例动作。动作19-2的动作包括在恢复包上确定验证校验和。而且，用验证校验和与初始校验和的比较来确定解密与解压缩的验证。 

2.1.1：压缩上下文与加密上下文的组合管理：

第一方式：执行：发送节点

152/ 

发送节点处的图19的第一方式的示例详细实施方案，通过图20的流程图的动作并结合在图21的对应布置的包描述进行说明，图解了在。接收节点处的图19的第一方式的相应的详细实施方案，通过图22的流程图的动作并结合图23的对应布置的包描述进行说明。 

153/ 

对于第一方式的示例实施方案，在发送节点处，动作19-1-a包括对于进入包的压缩候选部分并对于加密候选净载荷部分确定初始校验和ICKSUM。在该示例实施方案中，图21示出了对于进入包的整个压缩候选部分CCP和整个加密候选净载荷部分ECPR计算并确定初始校验和ICKSUM。可以理解能够对于少于整个进入包计算动作19-1-a的校验和ICKSUM，例如对于少于整个压缩候选部分CCP和/或少于整个加密候选净载荷部分ECPR来计算，只要校验和计算逻辑知道发送节点与接收节点双方，即校验和计算逻辑被一致地预配置在发送节点与接收节点二者中。 

154/ 

动作19-1-b包括对进入包的压缩候选部分CCP执行压缩以提供压缩串CS。动作19-1-b的压缩可以是任何适当的压缩方法，包括但不限于这里所描述或所提及的压缩方法。 

155/ 

动作19-1-c包括至少将进入包的加密候选净载荷部分ECPR加密以提供加密串ES。在图21所示的示例实施方案中，加密不仅覆盖加密候选净载荷部分ECPR，而且覆盖压缩候选部分CCP。应知，在变更实施方案中加密也可以覆盖初始校验和ICKSUM。或者，在另一变更实施方案中，加密也可以只覆盖加密候选净载荷部分ECPR(不覆盖压缩候选部分CCP或初始校验和ICKSUM)。无论采用哪一种实施方案或变更实施方案，动作19-1-b可以是任意适当的加密技术，包括但不限于这里所描述或所提及的加密技术。 

156/ 

动作19-1-d包括形成对应于进入包的接口穿越包。动作19-1-d的组包涉及在接口穿越包中至少包含压缩串CS、加密串ES以及初始校验和。当加密只覆盖加密候选净载荷部分ECPR时，这三个组成部分单独设置在接口穿越包内。然而，在加密覆盖超过加密候选净载荷部分ECPR时，加密串ES可以包含接口穿越包的其它组成部分中的一个或多个其他组成部分的全部或一部分。即，如果加密覆盖压缩候选部分CCP，则在接口穿越包中包含加密串ES涵盖在接口穿越包中包含压缩候选部分CCP全部或部分。同样，如果加密覆盖初始校验和ICKSUM，则在接口穿越包中包含加密串ES涵盖在接口穿越包中包含初始校验和ICKSUM。 

2.1.2：压缩上下文与加密上下文的组合管理：

第一方式：执行：接收节点

158/ 

在接收节点处的图19的第一方式的对应的详细实施方案，通过图22的流程图的动作并结合图23的对应布置对应布置的包描述进行说明。图22的动作19-2-a包括对接口穿越包的加密串ES解密以提供解密串。动作19-2-a的解密由在动作19-1-c处所使用的对应的加密技术的逆过程来执行。 

159/ 

考虑到图21所示的具体实施方案，因为加密串ES准备成包含压缩串CS，所以图22将解密表示为将加密串ES拆包来提供压缩串CS和对应于(假定加密与解密成功)加密候选净载荷部分ECPR的净载荷部分。如在另一变更实施方案中压缩串CS未受到加密，则该压缩串CS就可不进行动作19-2-a的解密。而且，如果在再一变更实施方案中初始校验和ICKSUM也未受到加密(如图22的虚线所示)，则初始校验和ICKSUM也可作为动作19-2-a的一部分被解密。 

160/ 

动作19-2-b包括将接口穿越包的压缩串CS解压缩以提供解压串 DS。动作19-2-b的解压缩通过用于动作19-1-b的压缩操作的压缩方法的逆过程来执行。 

161/ 

动作19-2-c包括对于解压串DS与解密串以对应于动作19-1-a中确定初始校验和的方式确定验证校验和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的验证来更新加密上下文。 

压缩上下文与加密上下文的组合管理：

第一方式：结语

165/ 

因此，在压缩上下文与加密上下文的组合管理的第一方式中，加密与压缩使用或共享同一校验和，且校验和的覆盖范围包括(至少部分的)净载荷。 

166/ 

基本上，用于验证解压缩进程的结果的校验和也可确认会话密钥确定的成功(例如，关于解密进程)。如在图19中宽泛所示及图20与图21中以更具体的示例实施方案所示，校验和覆盖包的组成部分的将被加密的(原未加密)部分和将被压缩的(原未压缩)部分。 

167/ 

在发送端(例如，参见图20的动作19-1-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-1示出了在发送节点处所执行的示例动作。尤其，对于发送节点处的进入包，对进入包的压缩候选部分确定初始校验和。在该第二方式中，压缩候选部分包括用于压缩操作的序号。而且，在该第二方式中，该同一序号被用作共享信息以用于导出在进入包的加密候选净载荷部分的加密中使用的会话密钥。在至少部分压缩且至少部分加密的接口穿越包中包含初始校验和。随后在接口上以如图9A中的接口24的示例方式所述传输该接口穿越包。如前所示，接口24可 以是单一接口(例如在增强节点B的情况下的S1接口或Uu接口)，或者可以集体地代表诸如S1接口与Uu接口这二者等几个接口。动作24-2表示在接收接口穿越包后即执行的示例动作，包括获取序号。在执行解密与解压缩而获得恢复包之后，对于恢复包确定验证校验和。使用验证校验和与初始校验和的比较来确定解压缩的验证。 

174/ 

在接收节点处的图24的第二方式的示例的详细实施方案，通过图25的流程图的动作并结合图26的对应布置的包描述进行说明。在接收节点处的图24的第二方式的示例的详细实施方案，通过图27的流程图的动作并结合图28的对应布置的包描述进行说明。 

175/ 

对于第二方式的示例实施方案，在发送节点处，动作24-1-a包括确定初始校验和。尤其，对于进入包的压缩候选部分CCP确定初始校验和。如果序号MSN是作为原始未压缩IP报头的一部分的序号，那么序号MSN应被校验和以图26中对应描述所示的方式覆盖。另一方面，如果序号MSN由压缩算法产生且并不出现在原始未压缩IP报头中，那么其唯一用途是对该报头解压缩，因而序号MSN不必是在解压缩进程与解密进程之后被验证的信息的组成部分(且因此不需要被初始校验和覆盖)。 

176/ 

作为选项(与按照如图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-1-b的加密可以是任意适当的加密技术，包括但不限于这里所描述或所提及的加密技术。 

179/ 

动作24-1-d包括形成对应于进入包的接口穿越包。动作24-1-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将被用于解密，那么它可以不被加密，但是它可以已被压缩。 

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-1-b的压缩操作的压缩方法的逆来执行。 

184/ 

动作24-2-d包括至少对解压缩串以及任选地对解密串用对应于在动作24-1-a中确定初始校验和ICKSUM的方式确定验证校验和VCKSUM。 

185/ 

动作24-2-e包括使用验证校验和与初始校验和的比较来确定动作24-2-c的解压缩验证。 

186/ 

动作24-2-f包括依照动作24-2-e的验证来更新压缩上下文。动作24-2-g包括依照动作24-2-e的验证来更新加密上下文。 

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.的《使用DEFLATE的IP净载荷压缩》(Pereira，R.IP Payload Compression Using DEFLATE，IETF RFC 2394，December 1998)以及Friend R与R.Monsour的《使用LZS的IP净载荷压缩》(Friend，R.et R.Monsour，IPPayload Compression Using LZS，IETF RFC 2395，December 1998)中所定义的)，或者可适用于要求排序与校验和的任意其他操作，用于排序与校验和的这种信息可与其他算法共享，该信息起源并终止于相同节点。 

207/ 

例如，前述的方式可适用于aGW，aGW当前在3GPP RAN 2标准化工作组中被定义为SAE/LTE工作的组成部分。 

30：安全报头压缩：概述

209/ 

依照本技术的另一单独的方面，可在报头压缩协议的组成部分上，例如可文中所述的其它方面的协作下使用，执行加密(encryption)功能或密码(ciphering)功能。即，这里所述的方法允许对包的某些或全部净载荷加密，也允许对压缩报头格式加密(除了具有涉及报头压缩信道的功能的报头字段以外)。 

210/ 

报头压缩算法(例如与现有RoHC框架兼容的鲁棒报头压缩协议)用来将加密与报头压缩有效组合而产生加密的报头压缩流。既在使用(否则可能被压缩的)报头压缩主序号(MSN)的未压缩表示的包括净载荷的整个报头压缩包上执行加密，又在其自身的尽可能多的已压缩报头上执行加密。不能被加密的字段是必须支持下述各项的字段： 

_ 数据流的多路复用                 (例如，RoHC CIDs)， 

_ 包类型标识                       (例如，RoHC包类型)， 

_ (可能压缩的)MSN，以及 

_ 压缩算法的标识符            (例如，RoHC协约八位组) 

在适用时，例如，对于初始包         (例如，RoHC IR包)。 

211/ 

在一个示例的、非限制的实施方案包括两个对应节点(相邻或不 相邻)，其中执行报头压缩与加密(例如在SAE/LTE的3GPP RAN 2中定义的aGW中)。该实施方案中规定“安全压缩报头格式”的哪部分将不被加密，并规定哪部分可以被加密，还规定在发送端与接收端使用的逻辑。 

212/ 

加密可以与同一节点中的报头压缩一起被执行，这减少单独排序的开销并增强用于解密的密钥导出机制的鲁棒性，其特征在于诸如抗包丢失的鲁棒性和重排序得到继承。该协议也可以包含对净载荷压缩的支持。 

213/ 

这种技术可在RoHC框架内适用于新协约(由于必须定义现有RFC 3095的扩充版本)，，又可适用于用于构造加密上下文、重排序等的附加信道协商参数。要求新的协约专用包格式(profile-specificpacket formats)，但是在RoHC的未使用的包类型与IR包类型的空间内有余地可用。因此，提出的解决办法可以在如Carsten Bormann等人的《鲁棒的报头压缩(ROHC)：框架与4个协约：RTP、UDP、ESP以及未压缩的》(Carsten Bormann.et al.RObust HeaderCompression(ROHC)：Framework and four profiles：RTP，UDP，ESPand uncompressed.IETF RFC 3095，April 2001)以及Pelletier G.、Sandlund K.与L.Jonsson的《鲁棒的报头压缩(ROHC)框架：互联网草案(进行中)》(Pelletier，G.，Sandlund，K.and L.Jonsson，The RobustHeader Compression(ROHC)Framework，Internet Draft(work inprogress)，<draft-ietf-rohc-rfc3095bis-framework-00.txt>，December2005)所定义的RoHC框架内兼容，以使加密RoHC流可以与非加密流一样共享同一信道。 

214/ 

先决条件是通过诸如在初始化上下文期间的协商、默认值、带内信令或者通过静态给定值来建立与加密有关的信道参数。这些参数包括通常出现在加密上下文内的项目：(1)要用的密码转换(例如，f8- 模式中的AES，HMAC-SHA)和(2)主密钥。 

215/ 

加密(例如，密码)被用到构建已压缩报头的其后为净载荷的字段，除以下的必须保持为未加密的字段外(例如，含有报头压缩信道信息的报头的字段)： 

●在报头压缩信道(CID)上的流的多路复用标识符。 

●已压缩报头格式类型标识(包类型标识符)。 

●主序号(如果加密会话密钥用MSN来导出)；MSN可以被压缩。 

●压缩算法标识符，当无多路复用标识符与安全报头压缩流关联时(初始已压缩报头的压缩协约标识符)。 

216/ 

因此，文中描述的例如是运行包括发送节点与接收节点的远程通信网络的方法。该方法包括，对于在发送节点处的进入包，对该包的除具有报头压缩信道信息的报头字段以外的已压缩报头加密，并在接口穿越包中包含已加密已压缩报头。该方法还包括，对于在接收节点处收到的接口穿越包，从具有报头压缩信道信息的报头字段中获取信息并解密该接口穿越包的已压缩报头。 

3.1：安全报头压缩：压缩器逻辑

218/ 

图29的流程图示出了示例的、非限制的动作或事件，它们能够以准备具有已加密其压缩报头的包的示例方式执行。可以理解，一个包实际上可以有一个以上的报头，因为不同的协议层可以添加其各自的报头以组成包含多协议的多报头的复合报头。与图29的各个动作对应，图30示出了当一个包涉及压缩操作与解密操作时的包内容描述。 

219/ 

图30示出了未压缩报头UH。未压缩报头UH包括如上所列的不可加密字段(UF)：多路复用标识符(MUX ID)、已压缩报头格式 类型标识(FMT ID)、主序号(MSN)以及压缩算法标识符(CAI)。这四个字段合起来组成这里所述的“不可加密字段”或“UF”。 

220/ 

动作29-1包括确定使用哪个压缩上下文。同样，动作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等人的《安全实时传输协议(SRTP)》(Baugher M.et al.，The Secure Real-time Transport Protocol(SRTP)，IETF 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进行拆包，所述报头压缩信道信息包括诸如多路复用标识符(MUX ID)、压缩报头格式类型标识(FMT ID)、主序号(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.，The Secure Real-time Transport Protocol(SRTP)，IETF RFC 3711，March 2004)的解密。 

236/ 

动作31-7包含将作为结果的已解密数据包拆包，例如通过处理诸如反馈、分割、校验和等的报头压缩信道信息的余下部分进行拆包。 

237/ 

动作31-8包含将已解密包的整个已压缩报头部分解压缩，形成未压缩报头UH。如果适用，动作31-9可包含更新加密上下文中的必要参数。动作31-10包含向上层(例如，网路层，例如，IP协议栈(例如，相对于OSI模型中的层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)使用该序号来导出会话密钥，并对包进行加密处理(processes the packet with encryption)。 

249/ 

在序号共享的第二方式中，加密(密码)功能可以使序号可用，加密(密码)功能将接下来(在其加密操作中)把该序号用于报头压缩器。报头压缩器使用这个序号作为它的MSN并压缩该包，且将已压缩包交给加密进程。然后，加密进程(encryption process)使用该同一序号来导出会话密钥，并进行加密处理(processes withencryption)。如果适用，该排序信息就在加密协议内载运。 

250/ 

换句话说，在第二方式中，排序(例如，序号)由加密功能产生，且加密功能使排序可用于报头压缩功能。在压缩(解压缩)时该压缩(解压缩)功能将该排序用作主序号(MSN)。 

251/ 

加密与压缩一般被视为分开的进程。传统方式中，加密执行于IP终端主机(剩下多数不可压缩的报头)之间、应用程序(不可检测，因而中间系统不能打开/关闭它们自己的加密)之间，或者执行于在物理媒体上的发送器与接收器之间(被定位到相邻节点，除非可保证排序)。 

252/ 

在这里所述的序号共享的任一种方式中，加密适配层可以被视为是报头压缩。图34将加密与压缩的传统分离(如图34左边所示)和这里所述的序号共享和组合或合并的压缩进程与加密进程(如图34右边所示)做了比较。基本上，连同报头压缩而执行净载荷的加密。无论是最终从压缩功能获得还是从加密功能获得，报头压缩主序号(MSN)被用来从加密上下文中导出会话密钥。加密功能使用序号MSN来从加密上下文中隐含地导出会话密钥。用报头压缩排序将加密施加于包的对应于净载荷的部分。同一序号MSN被压缩进程用于压缩报头，如图34的RoHC压缩所示。 

253/ 

在序号共享方面，随着使用用于压缩以导出会话密钥的主序号(MSN)在正被压缩的包的净载荷上执行加密，加密与压缩以SRTP方式有效结合。加密有益于编码的鲁棒性特征，所述编码根据关于其自身同步要求的损失与重排序用于MSN。 

254/ 

示例设备包括两个对应节点(相邻的或不相邻的)，在所述节点内执行压缩与加密(例如在3GPP RAN 2中为SAE/LTE所定义的接入网关)。密码转换与密钥导出算法(如在Baugher M等人的《安全实时传输协议(SRTP)》(Baugher M.et al.，The Secure Real-timeTransport Protocol(SRTP)，IETF RFC 3711，March 2004)中所述的)使用来自于压缩算法(例如，RoHC)的主序号(MSN)来对净载荷加密与解密。这样做意味着密码会话密钥导出算法的鲁棒性另外继承了MSN在压缩/加密端点之间的抗丢失包与重排序的鲁棒性特征。 

255/ 

所以，可以在同一节点中，尤其带RoHC的同一节点中，与报头压缩一起执行加密，从而减少了具有单独排序的开销且增强了解密的密钥导出机制的鲁棒性。 

256/ 

可以有用于加密进程配置的附加的外部协商机制，RFC3095中已 定义的协约及其它派生协约(假如没有ESP扩展报头)可以不作修改就使用。重排序中的可能改进是使若干最小包格式无效。 

4.1：序号共享：示例实施方案

258/ 

在图35为示例的、非限制的实施方案中，示出了对于具有组合的或合并的压缩进程与加密进程的发送节点与接收节点所执行的基本的、有代表性的动作或事件，其中压缩进程与加密进程共享序号。如图35所述的动作系列既可应用于序号共享的第一方式(在此方式中压缩进程选定或选择序号MSN)，又可应用于序号共享的第二方式(在此方式中加密进程选定或选择序号MSN)。图36与图37以流程图形式分别图解了发送节点与接收节点的动作。 

259/ 

图36描述由发送节点的压缩器逻辑执行的基本动作或者管理的基本事件。动作36-1(参见图36)包括确定使用哪个压缩上下文；动作36-2包括确定使用哪些加密上下文。如前所述，压缩上下文的确定与加密上下文的确定可以相联系。 

260/ 

动作36-3包括确定MSN的值。在此形态的第一方式中，压缩进程维持或产生序号MSN(例如，基于报头压缩的协议或根据本地维持的值)。在第二方式中，从加密进程中获取序号MSN作为下一序号，加密进程将该下一序号在加密操作中将用于排序。 

261/ 

动作36-4包括包的报头的实际压缩。如前所述，包可以含有诸如RTP报头、UDP报头以及IP报头的多个报头，所有这多个报头可构成如图398-1所示的包的报头。 

262/ 

动作36-5包括使用MSN(它被用来压缩包的报头)的未压缩表示法，并连同例如滚动计数器(rollover counter)使用密钥导出算法、加密上下文中的最高MSN以及用于压缩包的报头的MSN的未压缩表 示法来确定包索引。 

263/ 

动作36-6包含根据恰好使用的特定加密算法对包的净载荷加密。这就成为该包的被加密部分。该算法可以是类似于例如按照BaugherM等人的《安全实时传输协议(SRTP)》(Baugher M.et al.，The SecureReal-time Transport Protocol(SRTP)，IETF RFC 3711，March 2004)的加密。 

264/ 

动作36-7包含更新加密上下文中的必要参数，如果适用。 

265/ 

动作36-8包含将包的已压缩报头与已加密部分以及诸如反馈、分割、上下文标识、校验和等的剩余报头压缩信道信息组包。 

266/ 

动作36-9包括向下层(例如，媒体接入控制层(MAC)或RLC层)传递结果得到的数据报。 

267/ 

图36中的动作次序可变更。例如，动作36-1与动作36-2间的次序可以调换。同样，动作36-5、动作36-6及动作36-7可以整体与动作36-4调换。 

268/ 

图37描述由接收节点的解压缩器逻辑执行的基本动作或者管理的基本事件。动作37-1(参见图37)包括通过处理诸如反馈、分割、上下文标识、校验和等的报头压缩信道信息，将从下层接收的数据报拆包。 

269/ 

动作37-2包含确定使用哪个压缩上下文。动作37-3包含确定使用哪个加密上下文(压缩上下文的确定与加密上下文的确定可以再次被结合)。 

270/ 

动作37-4包含将序号MSN解压缩。动作37-5包含对整个已压缩报头部分解压缩。 

271/ 

动作37-6包含使用用于对包的报头解压缩的MSN的未压缩表示法，并连同例如滚动计数器(rollover counter)使用密钥导出算法、加密上下文中的最高MSN以及用于压缩包的报头的MSN的未压缩表示法来确定包索引。 

272/ 

动作37-7包含按照解密算法对包的加密部分解密(脱密)。如前所述，加密/解密可以类似于例如按照Baugher M等人的《安全实时传输协议(SRTP)》(Baugher M.et al.，The Secure Real-time TransportProtocol(SRTP)，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/ 

第三例优势是互惠互利并改善加密上下文的鲁棒性。加密功能受益于对于排序信息的报头压缩算法的鲁棒性特征，且因此降低了加密上下文丢失对排序的同步的可能性。要是发生了丢失对于排序的同步，再同步将从报头压缩算法的恢复机制的内部发生。加密功能不会带来报头压缩算法的上下文损害，因为它只处理包的非压缩部分。在这点上，加密功能与报头压缩功能不会相互带来消极影响，而报头压缩代表加密算法照顾到排序鲁棒性并节省开销。 

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/ 

加密和/或报头压缩和/或净载荷压缩和/或信令压缩中的任意进程使用来自于另一功能性进程的排序信息，所述功能性进程是加密和/或报头压缩和/或净载荷压缩和/或信令压缩中的任意进程。 

284/ 

尤其，当加密和/或报头压缩和/或净载荷压缩和/或信令压缩中的任意进程使用排序信息时，该排序信息来自于报头压缩功能。 

285/ 

排序由加密进程产生，并使排序可用于报头压缩算法。压缩使用该排序作为其压缩时的主序号(MSN)。 

286/ 

例如，前述的方法适用于其中根据鲁棒报头压缩(ROHC)协议而执行压缩算法的特定场合，所述鲁棒报头压缩(ROHC)协议包括但不限于ROHC RTP(0x0001)、UDP(0x0002)、IP(0x0004)、ESP(0x0003)、TCP(0x0006)、UDP-Lite(0x0008)、RTP/UDP-Lite(0x0007)报头压缩协议。 

287/ 

例如，前述的方法可适用于其中根据任意其它一般的压缩方案而执行报头压缩器和/或报头解压缩器时的一些特定场合。 

288/ 

例如，前述的方法适用于密码算法与加密算法是序列密码的具体示例，包括但不限于A5、GEA、UEA以及AES。利用排序信息来导 出加(解)密所需的参数的其它密码算法与加密算法也在本发明范围内。 

289/ 

例如，前述的可应用到其它压缩算法，例如诸如SigComp的信令压缩、净载荷压缩算法(例如那些在Pereira R.的《使用DEFLATE的IP净载荷压缩》(Pereira，R.IP Payload Compression Using DEFLATE，IETF RFC 2394，December 1998)以及Friend R与R.Monsour的《使用LZS的IP净载荷压缩》(Friend，R.et R.Monsour，IP PayloadCompression Using LZS，IETF RFC 2395，December 1998)中所定义的)，或者可应用到要求排序与校验和的任意别的操作，用于排序与校验和的这种信息可以被别的算法共享，该信息起源并终止于相同节点。 

290/ 

例如，前述的方法适用于aGW，aGW当前在3GPP RAN 2标准化工作组中被定义为SAE/LTE操作的组成部分。 

291/ 

这里所述的技术、方法、实施方案以及系统有许多优点，包括但不限于(1)开销最小化；(2)对现有标准与体系结构的影响小；(3)与加密上下文的互利互惠及加密上下文的增强鲁棒性；以及(4)对普通报头压缩的可应用性。 

292/ 

尽管以上的描述包含许多特征，但是这些特征不应被解释为限制本发明的范围而应被解释为仅仅提供若干目前优选实施方案的例证。可以理解本发明的范围完全包括对本领域熟练技术人员而言显而易见的其它实施方案，且可以理解该范围因此不是限制性的。与上述优选实施方案的要素对应的结构上、化学上及功能上的、对本领域的普通技术人员而言已知的等同物被明确地合并在这里，且确定为被包含在这里。而且，因此对装置或方法而言，描述所找到的要由本发明解决的每个问题是没有必要的，因为本发明将包括该装置或方法。 

Claims (28)

1.一种操作远程通信网络的节点的装置，包括：

用第一功能（30）对由所述节点处理的包的第一部分执行第一操作的部件；

用第二功能（32）对所述包的第二部分执行第二操作的部件；

所述装置的特征在于：

使用操作于所述包的共享事务处理（34）的部件，所述共享事务处理既用于所述第一操作又用于所述第二操作，借助于所述共享事务处理（34），所述包的归于所述第一功能（30）与所述第二功能（32）的开销比不在所述第一操作与所述第二操作的执行中使用所述共享事务处理（34）时少，

所述共享事务处理（34）包含由所述第一功能（30）和所述第二功能（32）使用的共享信息，其中，所述第一功能（30）是数据压缩功能，所述第二功能（32）是加密功能，所述共享信息是由所述压缩功能起始的作为所述压缩功能的序号MSN的序号MSN，所述序号也被所述加密功能用来导出会话密钥。

2.权利要求1所述的装置，其中，所述共享信息是由所述加密功能起始的从中导出会话密钥的序号，所述信息也被所述压缩功能用作序号MSN。

3.权利要求1-2中任一项所述的装置，其中，所述节点是下述之一：

系统体系结构演进/长期演进（SAE/LTE）远程通信网络的接入网关；以及

系统体系结构演进/长期演进（SAE/LTE）远程通信网络的增强节点B（eNB）。

4.权利要求1-2中任一项所述的装置，其中，所述节点包括多个物理节点，所述装置还包括在第一物理节点中设置所述第一功能（30）并在所述第二物理节点中设置所述第二功能（32）的部件。

5.权利要求1-2中任一项所述的装置，还包括使用同一模型层协议来执行所述第一功能（30）、所述第二功能（32）以及所述共享事务处理（34）的部件。

6.权利要求5所述的装置，还包括使用链路层协议来执行所述第一功能（30）、所述第二功能（32）以及所述共享事务处理（34）的部件。

7.权利要求1-2中任一项所述的装置，其中，所述共享事务处理（34）包含也操作于所述包的所述第一部分的所述第二功能（32）。

8.权利要求7所述的装置，其中，所述第一功能（30）是数据压缩功能且所述第二功能（32）是加密功能，所述加密功能将所述包的报头的至少一部分加密。

9.权利要求8所述的装置，其中，所述加密功能不将所述报头的压缩信道标识符加密。

10.权利要求1-2中任一项所述的装置，其中，所述共享事务处理（34）包含对所述包的第一部分的至少一部分并对所述包的第二部分的至少一部分确定校验和。

11.权利要求10所述的装置，其中，所述第一功能（30）是数据压缩功能，所述包的第一部分是包的报头，所述第二功能（32）是加密功能，所述包的第二部分是包的净载荷，对所述包的所述报头的至少一部分并对所述包的所述净载荷的至少一部分确定所述校验和。

12.权利要求1所述的装置，其中，所述共享事务处理（34）包含对所述包的第一部分的至少一部分确定校验和，所述包的第一部分的被确定所述校验和的所述部分包含由所述第二功能（32）在操作于所述包的第二部分时使用的参数。

13.权利要求12所述的装置，其中，所述第一功能（30）是数据压缩功能，所述包的第一部分是包的报头，其中所述第二功能（32）是加密功能，其中所述包的第二部分是包的净载荷，对所述包的所述报头的至少一部分确定所述校验和，由所述第二功能（32）在操作于所述包的第二部分时使用的所述参数是为其加密上下文导出会话密钥的序号。

14.权利要求1-2和12-13中任一项所述的装置，其中，所述第一功能（30）包含压缩功能，配置成压缩下述部分中的至少其一：所述包的报头、所述包的净载荷以及与所述包关联的信号。

15.一种操作远程通信网络的节点的方法，包括：

用第一功能（30）对由所述节点处理的包的第一部分执行第一操作；

用第二功能（32）对所述包的第二部分执行第二操作；

所述方法的特征在于：

使用操作于所述包的共享事务处理（34），所述共享事务处理既用于所述第一操作又用于所述第二操作，借助于所述共享事务处理（34），所述包的归于所述第一功能（30）与所述第二功能（32）的开销比不在所述第一操作与所述第二操作的执行中使用所述共享事务处理（34）时少，

所述共享事务处理（34）包含由所述第一功能（30）和所述第二功能（32）使用的共享信息，其中，所述第一功能（30）是数据压缩功能，所述第二功能（32）是加密功能，所述共享信息是由所述压缩功能起始的作为所述压缩功能的序号MSN的序号MSN，所述序号也被所述加密功能用来导出会话密钥。

16.权利要求15所述的方法，其中，所述共享信息是由所述加密功能起始的从中导出会话密钥的序号，所述信息也被所述压缩功能用作序号MSN。

17.权利要求15-16中任一项所述的方法，其中，所述节点是下述之一：

系统体系结构演进/长期演进（SAE/LTE）远程通信网络的接入网关；以及

系统体系结构演进/长期演进（SAE/LTE）远程通信网络的增强节点B（eNB）。

18.权利要求15-16中任一项所述的方法，其中，所述节点包括多个物理节点，所述方法还包括在第一物理节点中设置所述第一功能（30）并在所述第二物理节点中设置所述第二功能（32）。

19.权利要求15-16中任一项所述的方法，还包括使用同一模型层协议来执行所述第一功能（30）、所述第二功能（32）以及所述共享事务处理（34）。

20.权利要求19所述的方法，还包括使用链路层协议来执行所述第一功能（30）、所述第二功能（32）以及所述共享事务处理（34）。

21.权利要求15-16中任一项所述的方法，其中，所述共享事务处理（34）包含也操作于所述包的所述第一部分的所述第二功能（32）。

22.权利要求21所述的方法，其中，所述第一功能（30）是数据压缩功能且所述第二功能（32）是加密功能，所述加密功能将所述包的报头的至少一部分加密。

23.权利要求22所述的方法，其中，所述加密功能不将所述报头的压缩信道标识符加密。

24.权利要求15-16中任一项所述的方法，其中，所述共享事务处理（34）包含对所述包的第一部分的至少一部分并对所述包的第二部分的至少一部分确定校验和。

25.权利要求24所述的方法，其中，所述第一功能（30）是数据压缩功能，所述包的第一部分是包的报头，所述第二功能（32）是加密功能，所述包的第二部分是包的净载荷，对所述包的所述报头的至少一部分并对所述包的所述净载荷的至少一部分确定所述校验和。

26.权利要求15所述的方法，其中，所述共享事务处理（34）包含对所述包的第一部分的至少一部分确定校验和，所述包的第一部分的被确定所述校验和的所述部分包含由所述第二功能（32）在操作于所述包的第二部分时使用的参数。

27.权利要求26所述的方法，其中，所述第一功能（30）是数据压缩功能，所述包的第一部分是包的报头，其中所述第二功能（32）是加密功能，其中所述包的第二部分是包的净载荷，对所述包的所述报头的至少一部分确定所述校验和，由所述第二功能（32）在操作于所述包的第二部分时使用的所述参数是为其加密上下文导出会话密钥的序号。

28.权利要求15-16和26-27中任一项所述的方法，其中，所述第一功能（30）包含压缩功能，配置成压缩下述部分中的至少其一：所述包的报头、所述包的净载荷以及与所述包关联的信号。

Images