具有共享事務處理的多個遠程通信功能的製作方法

2023-10-08 13:54:49 1

專利名稱：具有共享事務處理的多個遠程通信功能的製作方法
技術領域：
1/
本發明涉及遠程通信中的數據包的處理，包括但不限於在遠程通 信中執行諸如數據包的加密與壓縮的操作。
背景技術：
:2/
., 諸如遠程通信系統等連網系統一般闢皮分為多層。例如，國際標準 化組織(ISO)已經開發了開放系統互聯(OSI)連網模型(也稱為 OSI七層模型)，並在OSI7498中作了描述，其內容通過引用結合於 本文。七層OSI模型(如圖38所示)分層(從底層即第一層到頂層 即第七層)如下物理層、數據鏈路層(即"鏈路"層)、網絡層、 傳輸層、會話層、表示層以及應用層。(原文)說明書中所用的"model layer (才莫型層)"與Model layer (模型層)相當或類似，不管使用這 種模型層的網絡技術規範是否明確涉及OSI模型。在每一模型層內， 每一層的功能可以由一個或多個實體或者功能來執行。例如，在這種 意義上，在每一才莫型層內可以存在諸如壓縮功能層、加密功能層以及 校驗和功能層等各種功能層。 3/
由於網際網路的巨大成功，將網際協議(IP)使用於各種各樣的鏈 路已成為具有挑戰性的任務。EP協議使用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的(f在裙瓶遽聲/f遂 濬^ 7C屍/7屍孩興》(Van Jacobson, Com/ mw,"g TUiV/i5 /or 丄mv-5^eeJ Sena/丄/"&， IETF RFC 1144, IETF Network Working Group, February 1990 ) ) 、 RFC 2507 (Mikael Degermark、 Bj6m Nordgren、 Stephen Pink的《/屍孩興在/症》 (Mikael Degermark,Bj。rn Nordgren，Stephen Pink; /屍/fra^r Compmswo", IETF RFC 2507,正TF Network Working Group, February 1999 ))以及RFC 2508 ( Steven Casner、 Van Jacobson的《在裙錄遽聲/f鏈廖的/屍/L/D屍/R7P孩關》 (Steven Casner,Van Jacobson, Compmw/wg /屍/T/D屍/R7P /or 丄ow-5^e^&ha/丄/"h;正TF RFC 2508， IETF Network Working Group, February 1999)) 8/
報頭壓縮利用這樣的事實，即報頭中的 一 些欄位在流中不作改 變，或者以小的和/或可預測的值進行改變。才良頭壓縮方案利用這些特 徵，僅在最初發送靜態信息，而變化欄位用其絕對值或作為差值從包 發送到包。至於完全隨機的信息，則必須以不做任何壓縮的形式發送。formula see original document page 10
報頭壓縮通常表徵為兩個狀態機間的交互作用， 一個狀態機^(E 縮器而另一狀態機是解壓縮器，每個狀態機保持一些與在上下文中4皮 壓縮的流相關的信息。
10/
壓縮上下文包含並保持關於過去包的相關信息，並用這種信息來 壓縮與解壓縮後續包。如2001年4月的正TF RFC 3095中Carsten Bormann等人的(f,一摔孩興在裙(^(9FC人'蕃染力四,錄/" profiles ); ^7P 、 C/Z1P 、五S屍及採在 》(Carsten Bormann, et al.尺(96wW /7e^/er Co，,e柳.朋fKOM^: Fra廳衡A a"c/ /owr屍ra力/w尺7P, L^Z)屍，五575 朋d朋cow; m^et/.正TF RFC 3095, April 2001 )所述(通過引用而結合
於本文)
壓縮器的上下文是用來壓縮報頭的狀態。解壓縮器的上下文是用 來解壓縮報頭的狀態。在清楚使用哪一個時，這二者中的任一個 或這二者的結合通常被稱為"上下文"。上下文含有來自包數據 流中的先前報頭的相關信息，比如靜態欄位和用於壓縮與解壓縮 的可能的基準值。此外，描述包數據流的附加信息也是上下文的 組成部分，例如關於IP標識符欄位如何變化和關於典型的包與 包之間序號或時間標記增加的信息。 11/
保持壓縮器狀態與解壓縮器狀態(稱為上下文)相互一致同時保 持報頭開銷儘可能低是具有挑戰性的任務。有一個狀態機用作壓縮 器，並有一個狀態機用作解壓縮器。壓縮器狀態機直接影響壓縮效率 的高低，因為它是用於控制要發送的已壓縮包類型的選擇的邏輯的重 要組成部分；解壓縮狀態機的作用主要是提供用於反饋(如果可用) 的邏輯並識別可嘗試進行解壓縮的包類型。
12/
給解壓縮器提供方法來驗證成功解壓縮成功的包是上下文更新 包。由於解壓縮可以糹皮檢一瞼，所以這種類型的包可以更新上下文。對於ROHC,上下文更新包類型在其格式內攜帶循環冗餘碼(CRC); 這是在原始未壓縮報頭上計算出的校驗和。該CRC被用來檢驗每個 包的解壓縮成功； 一驗i正成功時，該上下文可糹支更新。 13/
依賴其它方法來保證解壓縮成功的包，即沒有給解壓縮器提供方 法來驗證成功解壓縮成功的包格式的包，該包是獨立包，只攜帶自身 的解壓縮所需的信息，則該包。這些包不更新上下文。
14/
報頭壓縮使用序號來唯一標識各個包。在淨艮頭壓縮中，通常基於 序號(SN)的功能來壓縮欄位。既可以從協議中導出這種處於壓縮的 序號(例如，RTPSN)，也可以由壓縮器產生這種序號。在本文中， 當二者之間的區別不相關時，這種序號稱為主序號(MSN)。
15/
早期淨良頭壓縮切、約(header compression profile )的設計-使用如下 假設壓縮器與解壓縮器間的信道不對報頭壓縮包重排序，且要求該 信道保持用於每個已壓縮流的包排序。這一假設的動因是最初考慮使 用RoHC的潛在候選的信道保證包的按序遞交；這種假設有助於改善 壓縮效率與包丟失容限(tolerance against packet loss ),這兩項目標在 當時被列為最高要求。
16/
除了其它改進，當前正在開發的RoHCv2協約將處理壓縮協議內 的壓縮端點之間的不按次序的遞交以及編碼方法本身。 17/
許多不同類型的壓縮可以在鏈路層以上使用。這些壓縮包括淨栽 荷壓縮(例如參見Pereira R.的(f炎^D五FL/4T^ W/屍淨戎荷在裙》 (Pereira R., /屍P—ac/ C麵戸肌'ow版"g 正TF RFC 2394,
December 1998 );以及Friend R.與R. Monsour的ff炎y^ ZZS ^ZP淨 ^tV茅在^V/K Friend R. et R. Monsour, /屍Pay/oad Compre^/ow Wy/"g乙ZS1， IETFRFC 2395, December 1998))、信令壓縮(例如參見Price R.等人的(f/(冷^裙f57gCo， J》(Price, R. et al., iS^cr/Z/wg Cow/)ms^ow (^gCowp人正TF RFC 3320, January 2003 ))、報頭去除與再造以及報 頭壓縮。例如，關於報頭壓縮參見Van Jacobson的(T在裙瓶遽f/f"鏈 濬W rCP/ZP孩關》(Van Jacobson, C0m/7mw/"g 7UiV/屍//ea&ra /or 丄ow-5^ed&n'a/ ""fe， IETF RFC 1 144, EETF Network Working Group. February 1990) ; Mikae〗Degermark、 Bj6rn Nordgren、 Stephen Pink 等人的孩關在裙X Mikael Degermark, Bj6rn Nordgren, Stephen Pink; IP Header Compression,正TF RFC 2507, IETF Network Working Group, February 1999 ) ; Steven Casner與Van Jacobson的(f在裙瓶遽聲/f鏈 路W/7V[/D屍/R:rP孩關》(Steven Casner, Van Jacobson, C0w;7reM/"g //WZ^/^TPT/e^/era/orZow-S/^WSeha/Z^fe;正TF RFC 2508， IETF Network Working Group, February 1999 ) ; Koren T.、 Casner S.、 Geevarghese J. 、 Thompson B.及P. Ruddy等人的(T^7 、6^
關與#"#^^鏈潛^#資^^"7^ (T^27V》(Koren T., Casner S., Geevarghese丄，Thompson B. and P. Ruddy, i w/2朋ce(i C麵/ mweti A773 「C7^7Y^ /or Zj'"A:5" vwY/z ///g/z De/"乂屍"c&e/丄ow IETF RFC 3545, IETF Network Working Group, July 2003 ); Carsten Bormann 等人的《#/#孩關在裙O OHC,..凝束與四個錄'為,A7T、 W)P、 M屍及,在裙》 (Carsten Bormann, et al.船Z wW 7fecr血r Compms;s7'o" (KO^C」FrawewoA a"c/ /owr / ra力/w 尺775， [/D屍'五S屍朋c/ zmccw; re度(i. IETF RFC 3095, April 2001 ) ; Jonsson L與G. Pelletier 的(f^/摔疾關在^ MO/7C入'^於/屍殆在裙鈔為》(Jonsson L. and G. Pelletier,船6wW //eacfer C續pms^/朋(^Qf/C」j c謹/7mw7'ow ; ro力/e /or /屍，IETF RFC 3843, June 2004) ; Pelletier G.的《#/#拔關在/# y^C^CV ; f/D屍-丄"e (Pelletier G., ROZwW
Com,e抓'朋(KO^TC」.'屍ra^/^ /or f/AP-Z"e, IETF RFC 4019, April 2005 );以及Pelletier G.、 Sandlund K.與L. Jonsson等人的《#， January 2006)。這些壓縮類型的任一類型可^皮設計成使用序 號與校驗和。 18/
也可以使用其它最優化(如其它類型的壓縮)來進一步增強帶寬 受限系統的性能。
B.淨艮頭壓縮檢驗
20/
魯棒報頭壓縮使用在已壓縮報頭(例如，在初始化包內)上或者 在未壓縮報頭(例如，在已壓縮包中)上算出的校驗和(CRC)。使 用校驗和來驗證解壓縮器上的正確的解壓縮。更具體地說，例如，報 頭壓縮通常使用校驗和來驗證其解壓縮嘗試的結果。該校驗和可以是 對於正被壓縮的信息的未壓縮狀態計算的校驗和，或者也可以是對於 發送於壓縮器與解壓縮器之間的信息(已壓縮信息、未壓縮信息或壓 縮協議信息或這三種信息的任意組合中的任一種信息)計算的校驗 和。
21/
同樣，通常在解密進程前使用幀校驗和序列(FCS)，以確保沒
有向解密算法遞交的信息能夠導致不正確的加密上下文。 22/
未檢測出的殘差可能導致丟失對以上討論的任何功能的同步，這 取決於所使用的算法。 23/
報頭壓縮可以使用安全基準原理來確保不能由於包丟失而失去 壓縮器與解壓縮器間的上下文同步。基於解壓縮器所收到的應答，壓 縮器確信解壓縮器已經成功地從上下文更新包中更新了上下文。然 而，以安全基準原理使用的大多數包類型是獨立，因此按理不應該更 新上下文。
24/壓縮器通常只在接收到來自於解壓縮器的用於上下文更新包(用
反饋消息中的MSN來標識)的應答後才更新其壓縮上下文。 25/
解壓縮器通常在檢驗解壓縮的結果後用已壓縮報頭(若出現在包 格式中，則在用安全基準原理操作時不一定真實)內攜帶的循環冗餘 才交驗(CRC)來更新其上下文。受到速率限制，解壓縮器通常向壓縮 器應答更新。
C.安全/加密
27/
使用新的體系結構模型的演進與設計傾向於減少傳輸路徑包含 的節點數，並傾向於使用公開標準化的接口。這轉而又改進了功能間 的傳統分離，也創建了新的對於安全性的可信模型。儘管網際網路範例 中安全性一般一皮視為通信主機之間的端到端功能，但安全機制也常設 置在較低模型層中以解決低級安全問題。
28/
就安全性而言，包數據流的加密通常要求發送端與接收端保持加 密狀態信息。該信息一般^支稱為加密上下文。 29/
加密密鑰可以是這種上下文的組成部分，例如加密轉換可以直接 使用一個"會話"密鑰，而另一個"主"密鑰可用來導出該會話密鑰。 該主密鑰通常由密鑰管理協議以安全方式給出。在上下文中可找到的 ^'它參數往往是例如加密算法標識符、會話指示符、計數符、密鑰長 度參熬等。這些參數中的許多參數專用於有效密碼轉換。
有些算法可基於與包關聯的排序信息導出用於包的會話密鑰。例 如，安全實時基準協議(SRTP)(參見圖l)基於包內攜帶的RTP 序號來導出該包的索引。SRTP是OSI應用層協議，預定用來在向使 用RTP/RTCP協議的實時應用程式提供端對端的安全層，如圖2所示。 例如，SRTP在Baugher M.等人的《安全 傳—餘錄'議^^7PJ》(Baugher M. et al., 71/^ Seo^e7>""，W屍"otoco/ f57 7P」， 正TF RFC 3711, March 2004)中有描述。文中肯定了對密鑰索引的導 出存在限制，因為正確值的導出與加密上下文的更新對於大的包重排 序敏感也對殘留比特錯誤敏感。雖然所述的重排序量達到215個包的 次序且不太可能出現，但這突顯了所存在的未檢測到的比特錯誤對於 安全層的可能影響，在安全層中錯誤的包可在錯誤的時間間隔中用索 引錯誤地更新加密上下文，並破壞後續包的解密。 31/
這些算法保持這種排序信息作為加密上下文的組成部分，因此， 對該信息的正確索引與更新在加密端點之間必須是魯棒的。為了使用 正確的解密密鑰，必須知道完全正確的排序。與使用RoHC的報頭壓 縮的情況相反，絕大多數時候加密上下文在沒有任意形式的操作成功 檢驗的情況下被更新。這通常需要魯棒機制來確保排序被正確地維 持。在SRTP中可找到關於這樣的加密轉換和一旦獲知會話密鑰這些
加密轉:換如祠1丸^於加密與解密的示例。
32/
加密功能於是要求已加密包的接收次序與這些包的發送次序相 同，或者至少可以導出這種信息，以拾取正確的解密密鑰。否則，已 加密數據將不被正確地解密，且加密上下文將成為不同步，因而將錯 誤傳播給後續包。
D:壓縮同步
34/
圖3示出了用安全基準原理進行工作的壓縮器(上部)與解壓縮 器(.下部)的典型例子。隨著時間推移交換已壓縮包(時序軸)，並 跟隨具體事件更新安全基準(SN) LSB滑窗。要注意滑窗在某些時刻 可以包含一個以上的值，但是始終只存在一個用於特定欄位的壓縮與 解壓縮的安全基準。
35/
壓縮同位體(peers )的目標是始終與用於特定包的壓縮/解壓縮的某個基準保持同步。具體而言，下述各項適用且在圖3中被反映 *解壓縮器只能檢驗上下文更新包(可更新安全基準的包)的 成功解壓縮。
解壓縮器不能檢驗獨立包(不更新安全基準的包)的成功解 壓縮。
*當收到來自解壓縮器的應答時，壓縮器更新其安全基準滑窗。 從滑窗中移走先前的基準(應答的和/或未應答的)，只有最 新應答的那個基準被保留為安全基準。
*當收到其LSB比先前的包少的包時，解壓縮器更新其安全基 準滑窗，這表明已經用該解壓縮器先前已應答的基準作了壓 縮。只有其應答被發送的最新基準於是被保留為安全基準。
36/
對應於使用該"優化方法"時的當前技術水平，壓縮器總是更新 其上下文。這是因為被發送的所有包都包含未壓縮報頭的計算出的校 驗和。這種校驗和被解壓縮器用來檢驗解壓縮進程的結果。若驗證成 功，解壓縮器就更新其上下文。
37/
對應於更新加密上下文的當前技術水平，通常使用在解密包時所 見的最高序號，也使用翻轉計數符(roll-over counter)及其他參數， 來為所處理的每個包更新加密上下文。當在鏈路上載運排序信息與其 他加密信息時，加密上下文更新通常嚴重依賴於按序遞交的保證、很 低的殘留比特錯誤概率；加密上下文更新通常沒有辦法來檢驗解密進 程的結果。
E:無線接入網絡概述
39/
在典型的蜂窩無線系統中，無線用戶設備(UE)經由無線接入網 絡(RAN)與一個或多個核心網絡進行通信。無線用戶設備(UE)可 以是諸如行動電話("蜂窩"電話)與帶有移動終端的筆記本電腦的 移動臺，因此，無線用戶設備單元可以是使用無線接入網絡進行語音和/或數據通信的諸如可攜式的、袖珍的、手持的、內置於計算4幾的或 車載的行動裝置。作為選擇，該無線用戶設備單元也可以是諸如無線 本地環路的組成部分等的固定蜂窩設備/終端的固定無線設備。
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)機制要求在各個碼組的傳輸期間可靠 地檢測比特錯誤，因為它必須為RLCPDU檢測傳輸失敗以請求重傳。 因此，假定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 )
49/
eNB節點通過X2接口相互連接。eNB節點也通過Sl節點連接到 演進包核心(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實體之間的重排序的問題是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等 人的《#/#孩興在/, 入'蕃糴與四個炒^.' i r屍、L/DP、 ￡5屍
及採在裙》 (Carsten Bormann, et al. / OZ)w對股of(ier Compms^/o" (^(9//q;.' Fmwew( A朋d /ow ; ray /w "7P, L P，醜S屍朋J 匿o攀,乂 IETF RFC 3095, April 2001 ),也參見Pelletier G.、 Sandlund K.及L. Jonsson等人的《##孩關在裙喪糴，/"femef #尹"(Pelletier G., Sandlund K. and L. Jonsson, r/2e WoZ wW /fewfer
, December 2005 ) 。 RoHC目前使用其自己的序號和其自己的校驗和。RoHC也同樣適用於依靠 模型層2的排序與校驗和的當前技術水平的加密。目前RoHC不處理 重排序，但正在致力於該技術的開發。就對這種想法表示關注的加密 類型而言，代表當前技術水平的是SRTP;但是，SRTP工作於OSI 應用層且不與報頭壓縮結合。 57/
考慮到常規的分層技術，加密使用其自己的獨立機制來維持排 序，加密可能與同報頭壓縮無關的PDCP排序相結合，且在加密中要 求在H-ARQ協議上檢測殘留誤差以確保從用於加密進程的加密上下 文中魯棒地選擇/導出會話密鑰，且加密與報頭壓縮功能無關。加密與 報頭壓縮一直被相互獨立地處理。 一個可能原因是有些功能往往作用 在連接(例如，加密、重排序)上，除了來自該層自身的請求(例如， 基於QoS的請求)，獨立於且不易察覺到它們在處理並向其它層轉發 的不同的流，如圖7所例示。
58/
圖8以示例方式說明當前處理的問題。即使在LTE/SAE典型系 統中，甚至在同一節點內的功能分層也會導致顯著開銷。對於下層的 開銷，下面的表1示出了層2功能與對應的開銷(以八位組為單位)。
59/
表1
層2 FCS : 3-4八位組(處理比特錯誤)
層2 (加密)2八位組(重排序+加密密鑰)
層2 PDCP SN : 2八位組(無損的重定位-PDCP序號SeqNum PDU ) 總開銷 7+〃\位組
60/
因此，本發明的目標在於提供用以減少與模型層2的功能(例如， 鏈路層功能)關聯的開銷的一個或多個節點、裝置、系統、方法或技 術。

發明內容
61/
一種遠程通信網路的節點包括配置成在由該節點處理的包的第 一部分上執行第 一操作的第 一功能與配置成在該包的第二部分上執 行第二操作的第二功能。第一功能與第二功能配置成可使用共享事務 處理和/或共享業務來對該包進行操作，依靠共享事務處理和/或共享 業務，在執行第一操作與笫二操作後，該包具有比要是在第一功能與 第二功能的執行中不使用該共享事務處理和/或共享業務少的、可歸於
第一功能與第二功能的開銷。 62/
在一個示例實施方案中，該節點是系統體系結構演進/長期演進 (SAE/LTE)遠程通信網絡的接入網關，並且是配置成可執行笫一功 能、第二功能以及共享事務處理和/或共享業務的鏈路層協議。 63/
在另一示例實施方案中，該節點是系統體系結構演進/長期演進 (SAE/LTE)遠程通信網絡的演進節點B (eNB),並且是配置成可 執行第一功能、笫二功能以及共享事務處理和/或共享業務的鏈路層協 議。
64/
在一個示例實施方案中，該節點是系統體系結構演進/長期演進 (SAE/LTE)遠程通信網絡的移動用戶設備(UE),並且是配置成可 執行第一功能、笫二功能以及共享事務處理和/或共享業務的鏈路層協 議。
65/
在本技術的一種形態中，共享事務處理和/或共享業務包括由第一 功能與第二功能使用的共享信息。例如，在一個示例實施方案中，第 一功能是數據壓縮功能而第二功能是加密功能，且共享信息是由該壓 縮功能產生的作為該壓縮功能的序號MSN的序號，且該序號也^皮加 密功能用來為加密操作導出會話密鑰。在另一示例實施方案中，第一功能是數據壓縮功能而第二功能是加密功能，且共享信息是由加密功 能產生的、從中導出會話密鑰的序號，且該共享信息也被壓縮功能用
作序號MSN。 66/
在本技術的一種形態中，共享事務處理和/或共享業務包含也對該
包的笫一部分進行操作的第二功能。例如，在一個示例實施方案中， 第 一功能是數據壓縮功能而第二功能是加密功能，且該加密功能對該 包的報頭的至少一部分加密(但不對該報頭的壓縮信道標識符加密)。 67/
在本技術的一種形態中，共享事務處理和/或共享業務包含對於該
包的第一 部分的至少一部分與該包的第二部分的至少一部分確定氺交
驗和。在一個示例實施方案中，第一功能是數據壓縮功能，該包的第
一部分是包的報頭；第二功能是加密功能，該包的第二部分是包的淨
載荷；對於包的報頭的至少 一部分與包的淨載荷的至少 一部分確定校
驗和。在另一示例實施方案中，共享事務處理和/或共享業務包含對於
該包的第 一部分的至少 一部分確定4吏驗和，該包的第 一部分的4交驗和
被確定的部分包括由在對該包的第二部分的操作中由第二功能使用
的參數。例如，在一個其中包的第二部分是包的淨載荷的實施方案中，
對該包的報頭的至少 一部分確定校驗和，並且在對該包的第二部分上
的操作中由第二功能使用的參數是為其加密上下文導出會話密鑰的
序號。 68/
因此，考慮到共享事務處理和/或共享業務以及實質組合或合併的 功能性，提供方法與設備用於工作在相同端點的多項功能之間共享諸 如排序信息與校驗和信息等事務處理/信息。共享事務處理和/或共享 業務技術適用於任意兩個適當的發送節點與接收節點(不管它們相鄰 與否)，且該技術尤其(但非排它地)適用於其中鏈路層代表共享該 同 一信息的多個功能/進程維持並傳輸排序信息與/校驗和信息的情形 或體系結構。此外，其中使用該共享事務處理和/或共享業務技術的發送節點無需是單個節點，而可包括可通過它們分配多項功能的多個發 送節點。包含於本技術中的功能例如可以是報頭壓縮、報頭去除與再 生成、淨載荷壓縮、信令壓縮、加密與重排序等功能中的任意功能， 以及上述功能的任意組合。
69/
因此，如上簡述與如下進一步所述，"R頭壓縮與加密(以及可能 的其它功能)可共享排序信息與校驗和，減少單獨享有排序與校驗和 的開銷。SAE/LTE體系結構為這種想法提供了候選系統，以應用於接 入網關(aGW)、演進節點B (eNB)以及用戶設備(UE)內。
70/
這裡所述的技術也包括基於RoHC排序在報頭壓縮協約內部引入 安全功能(例如，加密)，並魯棒地且無開銷地實現該安全功能。例 如，本技術包括為協約而將加密上下文管理功能綁定到報頭壓縮上下 文管理的現有機制上。此外，本技術包括基於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是遠程通信網絡的示意圖，其中，共享事務處理和/或共享 業務包括不但對包的第二部分執行操作而且對包的第 一部分執行操 作的第二功能，所述包至少部分地受到第 一 功能的操作。
87/
圖15是遠程通信網絡的示意圖，其中，共享事務處理和/或共享 業務包括對包的一部分執行操作的加密功能，所述包至少部分地受到 壓縮。
88/
圖16是遠程通信網絡的示意圖，其中，共享事務處理和/或共享 業務包括確定共享校驗和。 89/
圖17是遠程通信網絡的示意圖，其中，共享事務處理和/或共享 業務包括對於包的l良頭的至少 一部分並對於包的淨載荷的至少 一部 分確定校驗和。
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的示範實施例。 脂
圖34是將加密與壓縮的常規分離跟組合或合併的壓縮進程和加 密進程進行對比的示意圖。 107/
圖35是說明對於發送節點與接收節點執行的動作或事件的順序 的示意圖，所述發送節點與接收節點具有組合和合併的壓縮進程與加 密進程，其中序號由壓縮進程與加密進程共享。
108/
圖36是說明具有組合或合併的壓縮進程與加密進程的發送節點 中涉及的動作或事件的流程圖，其中序號^L共享。 109/
圖37是說明具有組合或合併的壓縮進程與加密進程的接收節點 中涉及的動作或事件的流程圖，其中序號^皮共享。 110/
圖38是七層OSI層模型的示意圖。
具體實施方式
111/
在以下的描述中，出於"i兌明而非限制的目的，闡明了諸如特定的 體系結構、接口、技術等的具體細節，以提供對本發明的徹底理解。 然而，本領域技術人員清楚本發明可以應用到與這些具體細節不同的 其它實施方案中。即，本領域技術人員能夠設計出各種包含本發明的原理以及本發明的要旨與範圍內的裝置，即使所述裝置沒有在這裡明 示。在一些實例中，省略了對眾所周知的設備、電路與方法的詳細描 述，以免因非必需的細節而使本發明的描述不清晰。這裡描述本發明 的原理、形態與實施方式及本發明的具體實施例的所有陳述有意於包 括其結構上與功能上的等同者。此外，確定這樣的等同者既包括目前 已知的等同者又包括在未來將開發的等同者，例如，可執行同一功能 而不管其結構如何的任何一皮開發的單元。
112/
因此，例如，本領域技術人員可以理解方框圖在這裡可以表示體 現本技術原理的說明性電路的概念圖。同樣，也可以理解任意流程圖、 狀態置換圖、偽代碼等代表各種進程，所述進程可以;波大致表示在計 算機易讀^某體中，因此可以被計算機或處理器執行，無論這種計算機 或處理器是否^f皮明確示出。
113/
通過使用專用硬體及能夠執行與適當軟體相關聯的軟體，可以提 供包括被標示或描述為"處理器"或"控制器"的功能模塊的各種器 件的功能。當由處理器提供時，可以由單個專用處理器或多個單獨的 處理器提供這些功能，其中的一些功能可以是共享的或分布式的。而 且，明確使用術語"處理器"或"控制器"不應被解釋成排它地指能 夠執行軟體的硬體，而是可以非限制地包括數位訊號處理(DSP)硬 件、用於存儲軟體的只讀存儲器(ROM)、隨機存取存儲器(RAM) 以及非易失性存儲器。
1.0:多個功能共享的事務處理
115/
圖9A示出了遠程通信網絡的兩個節點20、 22，這兩個節點通過 點劃線24表示的接口進行通信。在圖9A所示的特定情形中，節點 20 H送節點而節點22是接收節點。這種發送節點與接收節點的指 定參照包流的圖示方向，其中從包源26獲得的包被送到發送節點20。 送到發送節點20的包由發送節點20處理，然後通過接口 24向接收節點22發送。可以理解包流也可以沿相反方向從接收節點22向發送 節點20傳播，但是出於描述本技術的顯著形態之目的，考慮從發送 節點向接收節點22的單向包流已足夠。 116/
節點20包括第一功能30與第二功能32，前者用來對由節點20 處理的包的第一部分執行第一操作，後者用來對該包的第二部分執行 第二才喿作。第一功能30與第二功能32可處於同一模型層內，且可以 被分別認為是同一模型層的不同功能層。例如，第一功能30可以被 認為是在特定模型層內的第一功能層，而第二功能32可以被認為是 在該特定模型層內的第二功能層。文中所使用的任何非模型層的"層" 應被理解為是功能層。
117/
雖然屬於不同的功能層(可能在同一^f莫型層內)，但是第一功能 30與第二功能32配置成可使用共享事務處理和/或共享業務34來4丸 行對包的操作。依靠共享事務處理和/或共享業務34，在執行第一操 作與第二操作之後，通過了接口 24的包具有比要是在第一操作與第 二操作的執行中不使用該共享事務處理和/或共享業務34的開銷少 的、歸於第一功能與第二功能的開銷。
118/
圖9A還示出接收節點22包括發送節點20的相似功能，或者也 許更準確地說，發送節點20的所選功能的逆。例如，接收節點22包 括笫二功能的逆40與第一功能的逆42。此外，以與發送節點20的共 享事務處理和/或共享業務34相關的方式，接收節點22具有共享事務 處理和/或共享業務44,它們可以是在發送節點20處使用的共享事務 處理和/或共享業務34的逆類型事務處理。
119/
在圖9A中以非限制的方式對共享事務處理和/或共享業務34進 行了一般闡述。在下文中描述了關於共享事務處理技術的各種示例形 態的共享事務處理和/或共享業務的具體的、有代表性的、非限制性的實施例。例如，沒有一個示例共享事務處理和/或共享業務將^f皮當成排 它的或有限制的，所提供的這幾個示例並不是窮舉的，對它們的詳述 僅是為了提供對功能可以怎樣被諸如共享事務處理的技術至少部分 地組合或合併的更寬泛的理解。這裡所用的術語"共享事務處理"應 被理解為包括共享事務處理與共享業務二者或者包括共享事務處理 與共享業務之一。
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。然而，這裡所用的術語"節點"，尤 其是發送節點，涵蓋具有參與到共享事務處理技術中的功能的多個節 點。換句話說，其中使用共享事務處理技術的發送節點不必是無需為 單一節點，而可以包括多個節點，在所述多個節點上可以分配多重功 能(例如，第一功能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等人的(f##^孩興在^(^(9/fC人 蕃菜與4A7P、 W1P、五S屍"及^在裙》(CarstenBormann. et al. W(96mW 7/ea<3fer Com/^e^m/o" (7 (9/fC人Fnarmewo/^ /bwr prq/ /e5",W775, LOP, ￡SP w"co附pm^W.正TF RFC 3095, April 2001 )中參見
偏移量編碼。 131/
能夠"按流，，操作的壓縮算法的示例包括報頭壓縮和/或淨載荷壓 縮和/或信令壓縮和/或#艮頭去除。 132/
在用圖14一般說明的技術的另一形態中，共享事務處理34(14) 包含第二功能32，該第二功能32不僅對包的第二部分執行操作，而 且對包的可以至少部分地受到第 一 功能30操作的第 一部分執行操作。 例如，在圖15所示的一個示例實施方案中，第一功能30是數據壓縮 功能而第二功能32是加密功能，且加密功能32對包的報頭的至少一 部分加密(但是，如下文所解釋，不對壓縮信道標識符或報頭排序加 密)。以下，進一步描述該示例實施方案，特別(例如)參考本文的 3.0節。
133/
在用圖16 —般說明的技術的一種形態中，共享事務處理包含對 於包的第一部分的至少一部分與該包的第二部分的至少一部分確定 才交驗和，例如確定"共享4交-瞼和"。基礎層(underlying layer)載運 公用校驗和信息，例如，由支持加密和/或報頭壓縮和/或信令壓縮和/ 或淨載荷壓縮的層來載運校驗和信息。當 一個以上的功能層有效時， 這種信息可公用於多個功能層(例如，^R頭壓縮與加密，或者其它組 合)，且這種信息因此可以由任一個有效的進程/算法來產生(或者， 如果多個操作同時^皮執行或激活，那麼由多個有效進程/算法產生)。
134/
在如圖17所示的示例實施方案中，第一功能30是數據壓縮功能， 包的第一部分是包的才艮頭；第二功能32是加密功能，包的笫二部分 是包的淨載荷。對於包的報頭的至少 一部分與包的淨載荷的至少 一部 分確定校驗和。以下，進一步描述該實施方案，特別(例如)參考本 文的2.1節。135/
在圖18所示的又一示例實施方案中，共享事務處理包括對於包
的笫一部分(例如，包的^jc)的至少一部分確定校驗和，且確定了 校驗和的該包的第 一部分的的那部分包含在對該包的笫二部分執行 的操作中由第二功能使用的參數。例如，在包的第二部分是包的淨載 荷的實施方案中，對於包的報頭的至少一部分確定校驗和，並在對於 包的第二部分執行的操作中由第二功能使用的參數是序號，用該序號 為其加密上下文導出會話密鑰。以下，進一步描述該示例實施方案，
特別(例如)參考本文的2.2節。 136/
因此，考慮到共享事務處理及一些本質上組合或合併的功能性， 提供方法與設備用於在工作在相同端點的多重功能(例如，在同一模 型層內操作的多個功能層)之間共享這種諸如排序信息與校驗和信息 等事務處理/信息。共享事務處理技術可應用到任意兩個適當的發送與 接收節點(不管所述節點相鄰與否)，且特別(但不排他地)適合於 其中鏈路層代表多個共享同 一信息的多個功能/進程來保持並傳輸排 序和〃或校驗和信息的情形或體系結構。而且，如先前參考圖10B所 解釋，內部使用共享事務處理技術的發送節點不必是單一節點，而是 可包括多個節點，通過這些接點可分配多個功能。本技術包含或定為 目標的一些功能(例如， 一些功能層)可以是(比如)報頭壓縮、報 頭去除與再生成、淨載荷壓縮、信令壓縮、加密與重排序等功能中的 任何功能，以及上述功能的任意組合。
137/
如上簡述與如下進一步解釋，報頭壓縮與加密(以及可能的其它 功能)可共享排序信息與校驗和，減少單獨擁有排序與校驗和的開銷。 SAE/LTE體系結構為這種想法提供了候選系統，以被應用於接入網關 (aGW)與用戶設備(UE)內。
138/
如鏈路層那樣的層代表在相同端點內操作的多功能層(例如，加密和/或淨載荷壓縮和/或才艮頭壓縮)來載運排序信息與校驗和，並共 享該同一信息。作為另一形態，當對於加密進程的會話密鑰導出算法 提供在壓縮/加密端點之間的重排序與包丟失的魯棒性時，至少部分地 一起執行加密與報頭壓縮。而且，為使加密密鑰導出的選擇更穩健， 與^^頭壓縮的上下文管理協同進行加密上下文管理。
139/
使用共享事務處理技術共享功能之間的事務處理可導致開銷的 減少，例如在哪些可設法使用同一信息並可在相同端點內操作的功能 (例如魯棒的報頭壓縮、報頭去除、淨載荷壓縮、信令壓縮和/或加密 的任意組合中的任一)之間共享排序與校驗和。例如，使用該共享事 務處理技術，在一些實施例和/或實施方案中可以按表2的方式減少開 銷。
140/
表2
* 公用校驗和(如CRC16) : 2+八位組(比特錯誤、解壓縮、驗證)
攀公用序號:_1八位組(重排序+加密密鑰)_
總計 3+ 八位組
141/
如上所示，在可設法使用同一信息且在相同端點內操作的功能 (例如魯棒的報頭壓縮、報頭去除、淨載荷壓縮、信令壓縮和/或加密 的任意組合中的任何功能)之間？ 1入諸如共享的排序與校驗和的共享 事務處理，可以去除若千開銷。接下來，基於但不限於RFC 3095的 壓縮器與解壓縮器排序要求與行為，即Carsten Bormann等人的 捧的孩興在^ "(9/fC, .' W2T、 OD屍、五575 "及
4在裙》(Carsten Bormann. et al.尺(96組Trader C謂pms^/ow (7 Qf/C」 FrameworA:pra力/es: i 7P， t/D屍，五iS75 wwc謂/ ms^e(i.正TF RFC 3095, April 2001 )，描述一些可能的示範性實施例。
2.0:壓縮上下文與加密上下文的組合管理；fe述143/
在其一種形態中，本技術涉及使用組合或共享的事務處理的壓縮 上下文與加密上下文的組合管理。在4吏用從壓縮協議導出的排序與校 驗和(例如解壓縮驗證)來執行加密的時候，壓縮算法的上下文管理 規則被用於加密上下文的管理。該組合的上下文管理特徵在於設有發 送節點與接收節點，例如，發送節點在包的報頭部分的至少一部分上 執行壓縮並在包的至少 一部分上執行加密，從而壓縮與加密一皮結合到 在接收節點處包的解壓縮驗證與解密驗證成為相互依存的程度。
144/
在本形態的第 一例方式中，共享的事務處理或組合的子操作包括 在將被壓縮的包的至少 一部分與將被加密的該包的 一部分上確定復 合校驗和。例如，在第一方式中，如在發送節點處所計算的校驗和可 以覆蓋該包的所述部分的將糹皮加密的(原未加密的)部分與將4^縮 的(原未壓縮的)部分。在接收方，加密層執行包的已加密部分的解 密且解壓縮器將已壓縮部分解壓縮(如果沒有重疊，則可先進行任一 處理)。在第一方式中，接著使用校驗和來驗證解壓縮進程與解密進 程這二者的結果，且當校驗成功時導致相應的壓縮上下文與加密上下 文的更新。換句話說，如果驗證了解壓縮，則完成了解密且隱含地驗 證了解密。
145/
在壓縮上下文與加密上下文的組合管理的本形態的第二例方式 中，組合的子操作包含用序號作為共享信息的壓縮功能與加密功能， 亥序號被加密功能用於會話密鑰導出。在第二方式中，在加密功能使 用壓縮主序號來從其加密上下文中導出會話密鑰的情況下，校驗和只 需要覆蓋(原未壓縮的)將被壓縮的、包括序號信息的部分。因此， 奪該第二例方式中，在將被壓縮的包的至少一部分與(可選地)將被 加密的包的至少一部分上計算校驗和。在第二方式中，校驗和僅被用 來確認解壓縮進程的結果，當成功時就導致對相應的壓縮上下文與加 密上下文進行更新。序號MSN因此一皮驗證，且這是用於加密上下文的唯一壽文感信息。
146/
在任一方式中，可以使用傳輸層(例如，UDP、 TCP)校驗和來 進一步確認該進程的結果。上下文更新規則也遵循在第二方式中的壓 縮的上下文更新邏輯。
147/
在同 一節點中與報頭壓縮一起執行加密，可減少用於排序功能與 重排序功能的開銷。將加密特徵與報頭壓縮特徵組合到 一個單一協議 內可以是本技術的應用成果。該協議也可以包括對淨載荷壓縮的支 持，同一類型規則也可能被用於此。
148/
上下文管理在這裡適用於整個壓縮包或僅其子集(例如，僅淨載 荷一皮加密)；故加密的情況。在這兩種方式中，校驗和有助於壓縮操作 與加密操作的驗證。
' 2.1:壓縮上下文與加密上下文的組合管理
第一方式 一既述
150/
圖19示出了第一例方式所包含的基本的、有代表性的示例動作 或事件。動作19-1示出了在發送節點處執行的示例動作。尤其，對於 發送節點處的進入包，在該進入包的壓縮候選部分與加密候選淨載荷 部分上確定初始^f交驗和。在至少部分已壓縮與至少部分已加密的4矣口 穿越包中包含該初始校驗和。隨後在接口上以如圖9A中接口 24的示 例方式所述傳輸該接口穿越包。如先前所示，接口 24可以是單一接 口 (例如在增強節點B的情況下的Sl接口或Uu接口 )，或者可共同 代表諸如Sl接口與Uu接口等幾個接口 。動作19-2示出了在執行解 密與解壓縮以獲得復原包後，在接收節點處的接口穿越包的接收上執 行的示例動作。動作19-2的動作包括在恢復包上確定驗證校驗和。而 且，用驗證校驗和與初始校驗和的比較來確定解密與解壓縮的驗證。 2.1.1:壓縮上下文與加密上下文的組合管理第一方式執行發送節點
152/
發送節點處的圖19的第一方式的示例詳細實施方案，通過圖20 的流程圖的動作並結合在圖21的對應布置的包描述進行說明，圖解 了在。接收節點處的圖19的第一方式的相應的詳細實施方案，通過 圖22的流程圖的動作並結合圖23的對應布置的包描述進行說明。
153/
對於第一方式的示例實施方案，在發送節點處，動作19-l-a包括 對於進入包的壓縮候選部分並對於加密候選淨載荷部分確定初始校 驗和ICKSUM。在該示例實施方案中，圖21示出了對於進入包的整 個壓縮候選部分CCP和整個加密候選淨載荷部分ECPR計算並確定初 始校驗和ICKSUM。可以理解能夠對於少於整個進入包計算動作 19-l-a的校驗和ICKSUM,例如對於少於整個壓縮候選部分CCP和/ 或少於整個加密候選淨載荷部分ECPR來計算，只要校驗和計算邏輯 知道發送節點與接收節點雙方，即校驗和計算邏輯;波一致地預配置在 發送節點與接收節點二者中。
154/
動作19-l-b包括對進入包的壓縮候選部分CCP執行壓縮以提供 壓縮串CS。動作19-l-b的壓縮可以是任何適當的壓縮方法，包括但 不限於這裡所描述或所提及的壓縮方法。
155/
動作19-l-c包括至少將進入包的加密候選淨載荷部分ECPR加密 以提供加密串ES。在圖21所示的示例實施方案中，加密不^f又覆蓋加 密候選淨載荷部分ECPR，而且覆蓋壓縮候選部分CCP。應知，在變 更實施方案中加密也可以覆蓋初始校驗和ICKSUM。或者，在另一變 更實施方案中，加密也可以只覆蓋加密候選淨載荷部分ECPR (不覆 蓋壓縮候選部分CCP或初始校驗和ICKSUM)。無論採用哪一種實 施方案或變更實施方案，動作19-l-b可以是任意適當的加密才支術，包 括但不限於這裡所描述或所提及的加密技術。156/
動作19-1-d包括形成對應於進入包的接口穿越包。動作19-1-d的 組包涉及在接口穿越包中至少包含壓縮串CS、力口密串ES以及初始校 驗和。當加密只覆蓋加密候選淨載荷部分ECPR時，這三個組成部分 單獨設置在接口穿越包內。然而，在加密覆蓋超過加密候選淨載荷部 分ECPR時，加密串ES可以包含4矣口穿越包的其它組成部分中的一 個或多個其他組成部分的全部或一部分。即，如果加密覆蓋壓縮4美選 部分CCP，則在接口穿越包中包含加密串ES涵蓋在接口穿越包中包 含壓縮候選部分CCP全部或部分。同樣，如果加密覆蓋初始校驗和 ICKSUM,則在接口穿越包中包含加密串ES涵蓋在接口穿越包中包 含初始才支驗和ICKSUM。
2.1.2:壓縮上下文與加密上下文的組合管理 第一方式執行接收節點
158/
在接收節點處的圖19的第一方式的對應的詳細實施方案，通過 圖22的流程圖的動作並結合圖23的對應布置對應布置的包描述進行 說明。圖22的動作19-2-a包括對接口穿越包的加密串ES解密以提供 解密串。動作19-2-a的解密由在動作19-l-c處所使用的對應的加密技 術的逆過程來才丸4亍。
159/
考慮到圖21所示的具體實施方案，因為加密串ES準備成包含壓 縮串CS，所以圖22將解密表示為將加密串ES拆包來提供壓縮串CS 和對應於(假定加密與解密成功)加密候選淨載荷部分ECPR的淨載 荷部分。如在另一變更實施方案中壓縮串CS未受到加密，則該壓縮 串C.S就可不進行動作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中以更具體的示例實施方案所示，校^r和覆蓋包的組成部分 的蔣被加密的(原未加密)部分和將被壓縮的(原未壓縮)部分。
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-l示出了在發送節點處所執行的示例動作。尤其，對於 發送節點處的進入包，對進入包的壓縮候選部分確定初始一交^r和。在 i亥第二方式中，壓縮候選部分包括用於壓縮操作的序號。而且，在該 第二方式中，該同一序號被用作共享信息以用於導出在進入包的加密 候選淨載荷部分的加密中使用的會話密鑰。在至少部分壓縮且至少部 分加密的接口穿越包中包含初始校驗和。隨後在接口上以如圖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/
作為選項(與按照如圖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的方式確定驗證4交馬t和 VCKSUM。
185/
動作24-2-e包括使用驗證校驗和與初始校驗和的比較來確定動作 24-2-c的解壓縮驗證。 186/
動作24-2-f包括依照動作24-2-e的驗證來更新壓縮上下文。動作 24-2-g包括依照動作24-2-e的驗證來更新加密上下文。 2.3:壓縮上下文與加密上下文的組合管理 第二方式結語
而
在壓縮上下文與加密上下文的組合管理的第一方式中，以用於驗 證解壓縮進程的結果的校驗和來確認會話密鑰確定的成功(解密進程)。該校驗和最低限度地覆蓋包含主序號的(MSN )將被壓縮的(原 始未壓縮)部分，但是，如果解密進程將同一 MSN用於會話密鑰導 出，那麼該校驗和可以不包括包組成部分中將被加密的(原始^。密)
部分。 畫
在發送端，例如在發送節點，計算校驗和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)用於會話密鑰導出，那麼該校驗和可以不包括包 組成部分的將^L加密的(原始未加密的)部分。該校驗和可供解壓縮 進程使用，且其結果可供加密算法使用。如果實用，那麼當成功時就 基於壓縮算法的上下文更新與操作方式來更新加密上下文。 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 )淨艮頭壓縮協i義。
204/
例如，前述的方式一般可適用於依照任意別的報頭壓縮方案來執 行報頭壓縮器和/或解壓縮器的場合。 205/
例如，前述的方式可適用於密碼算法與加密算法是序列密碼的場 合，包括但不限於A5、 GEA、 UEA以及AES。利用排序信息來導出 加(解)密所需的參數的其它密碼算法與加密算法也在本發明範圍內。
206/
例如，前述的方式可適用於其它壓縮算法，例如的信令壓縮，諸 如SigComp、淨載荷壓縮算法(例如那些在Pereira R.的(f炎^7Z^FZ^4r五 W /P淨戎岸在裙》(Pereira, R. ZP P一cx^ Co，，'o" W/"gD5FL/47E,正TF RFC 2394， December 1998)以及Friend R與R. Monsour的(f炎^7丄ZS W /屍淨裁'^f在裙i1( Friend, R. et R. Monsour, ZP i^y/o"dCowpm^/ow 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中)。該實施方案中規定"安全壓縮報頭格式"的哪 部分將不^皮加密，並規定哪部分可以糹支加密，還規定在發送端與接收 端使用的邏輯。 212/
加密可以與同一節點中的報頭壓縮一起被執行，這減少單獨排序 的開銷並增強用於解密的密鑰導出機制的魯棒性，其特徵在於諸如抗 包丟失的魯棒性和重排序得到繼承。該協議也可以包含對淨載荷壓縮
的支持。 213/
這種技術可在RoHC框架內適用於新協約(由於必須定義現有 RFC 3095的擴充版本)，，又可適用於用於構造加密上下文、重排序 等的附加信道協商參數。要求新的協約專用包格式(profile-specific packet formats)，但是在RoHC的未使用的包類型與IR包類型的空 間內有餘地可用。因此，提出的解決辦法可以在如Carsten Bormann 等人的(f,y,^孩關在^ "(9/fC,'喪糴與4個錄'為,"TP, t/D屍、 ES屍"及乂在裙W》 (Carsten Bormann. et al.船to C謹/ ms^,cw (^(9//Q): Fra靴衡rA: a"d /owr / ra力/w A7P， VIXP,五573 朋d M"co/^mw^/. IETF RFC 3095, April 2001 )以及Pelletier G.、 Sandlund K.與L. Jonsson的(f魯舉W^關在^ J喪朿；
河莩襲(^迸/f ^ "A Pelletier, G.， Sandlund, K. and L. Jonsson, The Robust Header Compression (ROHC) Framework, Internet Draft (work in progress), , December 2005 )所定義的RoHC框架內兼容，以使加密RoHC流可以與非加密 流一樣共享同一信道。
2.14/
先決條件是通過諸如在初始化上下文期間的協商、默認值、帶內 信令或者通過靜態給定值來建立與加密有關的信道參數。這些參數包 括通常出現在加密上下文內的項目(l)要用的密碼轉換(例如，f8-才莫式中的AES， HMAC-SHA)和(2)主密鑰。 215/
加密(例如，密碼)；帔用到構建已壓縮報頭的其後為淨載荷的字 段，除以下的必須保持為未加密的欄位外(例如，含有報頭壓縮信道 信息的才良頭的字l殳)
*在報頭壓縮信道(CID)上的流的多路復用標識符。 *已壓縮報頭格式類型標識(包類型標識符)。 *主序號(如果加密會話密鑰用MSN來導出)；MSN可以被 壓縮。
*壓縮算法標識符，當無多路復用標識符與安全報頭壓縮流關
聯時(初始已壓縮l良頭的壓縮協約標識符)。 216/
因此，文中描述的例如是運行包括發送節點與接收節點的遠程通 信網絡的方法。該方法包括，對於在發送節點處的進入包，對該包的 除具有報頭壓縮信道信息的報頭欄位以外的已壓縮報頭加密，並在接 口穿越包中包含已加密已壓縮報頭。該方法還包括，對於在接收節點 處收到的接口穿越包，從具有報頭壓縮信道信息的報頭欄位中獲取信 息並解密該接口穿越包的已壓縮報頭。
3.1:安全報頭壓縮壓縮器邏輯
218/
圖29的流程圖示出了示例的、非限制的動作或事件，它們能夠 以準備具有已加密其壓縮報頭的包的示例方式執行。可以理解， 一個 包實際上可以有一個以上的^^頭，因為不同的協議層可以添加其各自 的報頭以組成包含多協議的多報頭的複合報頭。與圖29的各個動作 對應，圖30示出了當一個包涉及壓縮操作與解密操作時的包內容描 述。'
219/
圖30示出了未壓縮淨艮頭UH。未壓縮報頭UH包括如上所列的不 可加密欄位(UF):多路復用標識符(MUX ID)、已壓縮才良頭衝各式類型標識(FMTID)、主序號(MSN)以及壓縮算法標識符(CM)。 這四個欄位合起來組成這裡所述的"不可加密欄位"或"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的組包(packetizatkm )中不包4舌如上所列的 不可加密欄位(UF):多路復用標識符(MUX ID)、已壓縮報頭格 式類型標識(FMT ID )、主序號(MSN)以及壓縮算法標識符(CAI)。 225/
動作29-7包括對在動作29-6中形成的包加密，例如，衝艮據正一皮 使用的特定加密算法在包的已壓縮報頭CP與淨載荷上執行加密。圖 30示出了包的已加密部分EP,作為加密結果。加密算法可以(例如) 類似於諸如按照Baugher M等人的《安全豸##/診錄議"W77V》 (Baugher M. et al., T7ze Secwre Aea/-"me rra"，W屍ratoco/卩朋7P」， 正TF RFC 3711 , March 2004 )的加密。動作29-7的加密不包括如上所 述的不可加密字l殳(UF)。226/
動作29-8包括在適用時更新加密上下文中的必要參數。 227/
動作29-9包括通過添加動作29-6中所列的不可加密欄位(UF) 將包的已加密部分組包。這些不可加密欄位(UF )必須是未^i。密的， 但如果要求壓縮也可被壓縮。相應地，圖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)的不可加密字l史(UF)。
232/
動作31-2包括確定使用哪一個壓縮上下文。該壓縮上下文一旦確 定，動作31-3中就包含對MSN的解壓縮。 233/動作31-4包含確定^f吏用哪個加密上下文。加密上下文的確定可以 與動作31-2關於哪個報頭壓縮上下文的確定相聯繫。 234/
動作31-5包含確定包索引並導出會話密鑰。前文已經解釋了會話 密鑰的導出，且會話密鑰的導出也可以依賴於加密算法。此動作獲得 作為輸出的反映被力口密處理的包的次序的正確排序。
235/
動作31-6包含依照正^皮使用的特定解密算法對包的加密部分解 密(例如，脫密(decrypting))。如上所述，加密算法可以類似於諸 如按照Baugher M等人的《安全實時傳輸協議(SRTP)》(Baugher M. et al., T/ e ^cw^ T^"/力we 7>""^ort P,otoco/ fSW7P」，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之間 的次序可以對調。 ，/
圖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)， 基於所述形式通過建立依照關於該序號的變化^t式的功能正常地壓 縮其它欄位。該序號從正被壓縮的協議欄位導出，或由壓縮器在本地 生成。
247/
密碼(例如，加密)通常使用排序信息的某一形式，基於所述形 式在加密上下文的協作下導出會話密鑰。 248/
在序號共享的第一方式中，^^良頭壓縮器首先壓縮包的^1頭，並向 加密進程移交其序號。加密進程(ciphering process)使用該序號來導出 會i舌密鑰,並只十包進4亍力口密處理(processes the packet with encryption)。
249/
在序號共享的第二方式中，加密(密碼)功能可以使將糹皮加密下 一次(在其加密操作中)用於報頭壓縮器的序號可用。報頭壓縮器使 用這個序號作為它的MSN並壓縮該包，且將已壓縮包交給加密進程。 然後，力卩密進程(encryption process )使用該同 一序號來導出會話密 鑰，並進4亍力口密處理(processes with encryption )。如果適用，該4非序 信息就在加密協議內載運。
250/
換句話說，在第二方式中，排序(例如，序號)由加密功能產生， 且加密功能使排序可用於報頭壓縮功能。在壓縮(解壓縮)時該壓縮 (解壓縮)功能將該排序用作主序號(MSN)。 251/
加密與壓縮一般被視為分開的進程。傳統方式中，加密執行於IP 終端主機(剩下多數不可壓縮的報頭)之間、應用程式(不可檢測， 因而中間系統不能打開/關閉它們自己的加密)之間，或者執行於在物 理媒體上的發送器與接收器之間(被定位到相鄰節點，除非可保證排
序)。 252/在這裡所述的序號共享的任一種方式中，加密適配層可以糹支;現為 是淨艮頭壓縮。圖34將加密與壓縮的傳統分離(如圖34左邊所示)和 這裡所述的序號共享和組合或合併的壓縮進程與加密進程(如圖34 右邊所示)做了比較。基本上，連同報頭壓縮而執行淨載荷的加密。 無論是最終從壓縮功能獲得還是從加密功能獲得，報頭壓縮主序號 (MSN)被用來從加密上下文中導出會話密鑰。加密功能使用序號 MSN來從加密上下文中隱含地導出會話密鑰。用報頭壓縮排序將加密 施加於包的對應於淨栽荷的部分。同一序號MSN一皮壓縮進程用於壓 縮才艮頭，如圖34的RoHC壓縮所示。
253/
在序號共享方面，隨著使用用於壓縮以導出會話密鑰的主序號 (MSN)在正一皮壓縮的包的淨載荷上執行加密，加密與壓縮以SRTP 方式有效結合。加密有益於編碼的魯棒性特徵，所述編碼根據關於其 自身同步要求的損失與重排序用於MSN。
254/
示例設備包括兩個對應節點(相鄰的或不相鄰的)，在所述節點 內執行壓縮與加密(例如在3GPPRAN2中為SAE/LTE所定義的接 入網關)。密碼轉換與密鑰導出算法(如在Baugher M等人的(f姿全 ,#/長/診錄議"W7P J》(Baugher M. et al., 7Tie Secwre i ra/-"me rra"woWi>otoco/fSWr",IETFRFC3711 , March 2004 )中所述的) 使用來自於壓縮算法(例如，RoHC)的主序號(MSN)來對淨載荷 加密與解密。這樣做意味著密碼會話密鑰導出算法的魯棒性另外繼承 了 MSN在壓縮/加密端點之間的抗丟失包與重排序的魯棒性特徵。
255/
所以，可以在同一節點中，尤其帶RoHC的同一節點中，與才艮頭 壓縮一起執行加密，從而減少了具有單獨排序的開銷且增強了解密的 密鑰導出機制的魯棒性。
256/
可以有用於加密進程配置的附加的外部協商機制，RFC3095中已定義的協約及其它派生協約(假如沒有ESP擴展寺艮頭)可以不作修改 就使用。重排序中的可能改進是使若干最小包格式無效。
4.1:序號共享示例實施方案
258/
在圖35為示例的、非限制的實施方案中，示出了對於具有組合 的或合併的壓縮進程與加密進程的發送節點與接收節點所執行的基 本的、有代表性的動作或事件，其中壓縮進程與加密進程共享序號。 如圖35所述的動作系列既可應用於序號共享的第一方式(在此方式 中壓縮進程選定或選擇序號MSN)，又可應用於序號共享的第二方式 (在此方式中加密進程選定或選擇序號MSN)。圖36與圖37以流程
圖形式分別圖解了發送節點與接收節點的動作。 259/
圖36描述由發送節點的壓縮器邏輯執行的基本動作或者管理的 基本事件。動作36-l (參見圖36)包括確定使用哪個壓縮上下文；動 作36-2包括確定^f吏用哪些加密上下文。如前所述，壓縮上下文的確定 與加密上下文的確定可以相:f關係。
260/
動作36-3包括確定MSN的值。在此形態的第一方式中，壓縮進 程維持或產生序號MSN (例如，基於報頭壓縮的協議或根據本地維持 的值)。在第二方式中，從加密進程中獲取序號MSN作為下一序號， 加密進程將該下一序號在加密操作中將用於排序。
261/
動作36-4包括包的報頭的實際壓縮。如前所述，包可以含有諸如 RTP報頭、UDP報頭以及IP報頭的多個報頭，所有這多個報頭可構 成如風398-1所示的包的報頭。
262/
動作36-5包括使用MSN (它被用來壓縮包的報頭)的未壓縮表 示法，並連同例如滾動計數器(rollover counter) 4吏用密鑰導出算法、 加密上下文中的最高MSN以及用於壓縮包的才艮頭的MSN的未壓縮表示法來確定包索引。
263/
動作36-6包含根據恰好使用的特定加密算法對包的淨載荷加密。 這就成為該包的糹皮加密部分。該算法可以是類似於例如按照Baugher M等人的(f安全,秒傳,鈔議"WTP ,》(Baugher M. et al.， 77ze Secwre i^W-"we rra"^oW iVotoco/ 「S7 7P」，IETF RFC 3711 , March 2004 )的
加密。 264/
動作36-7包含更新加密上下文中的必要參數，如果適用。 265/
動作36-8包含將包的已壓縮^^艮頭與已加密部分以及諸如反^t責、分 割、上下文標識、校驗和等的剩餘才艮頭壓縮信道信息組包。 266/
動作36-9包括向下層(例如，i某體接入控制層(MAC)或RLC 層)傳遞結果得到的數據報。 267/
圖36中的動作次序可變更。例如，動作36-1與動作36-2間的次 序可以調換。同樣，動作36-5、動作36-6及動作36-7可以整體與動 作36-4調換。
268/
圖37播述由接收節點的解壓縮器邏輯執行的基本動作或者管理 的基本事件。動作37-l (參見圖37)包括通過處理諸如反饋、分割、 上下文標識、校驗和等的報頭壓縮信道信息，將從下層接收的數據報
拆包。 269/
動作37-2包含確定4吏用哪個壓縮上下文。動作37-3包含確定佳_ 用哪個加密上下文(壓縮上下文的確定與加密上下文的確定可以再次
被結合)。 270/動作37-4包含將序號MSN解壓縮。動作37-5包^^對整個已壓縮 報頭部分解壓縮。 271/
動作37-6包含使用用於對包的報頭解壓縮的MSN的未壓縮表示 法，並連同例如滾動計數器(rollover counter)使用密鑰導出算法、加 密上下文中的最高MSN以及用於壓縮包的l艮頭的MSN的未壓縮表示 法來確定包索引。
272/
動作37-7包含按照解密算法對包的加密部分解密(脫密)。如前 所述，加密/解密可以類似於例如按照BaugherM等人的《安全豸#/一 y>》(Baugher M. et al., 77ze Secwre Tra"^oW 屍ratoco/ fS^7P」，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協約，包括但不限於ROHCRTP( 0x0001 )、 UDP ( 0x0002 ) 、 IP ( 0x0004 ) 、 ESP ( 0x0003 ) 、 TCP ( 0x0006 )、 UDP-Lite (0x0008) 、 RTP/UDP-Lite (0x0007 )寺艮頭壓縮協約。該技 術還尤其關係到但不限於諸如序列密碼的譯成密碼算法與加密算法， 例如利用位屏蔽來允許只對特定位加密/不加密。這種序列密碼的實例 包括A5、 GEA、 UEA以及AES。其它相關的譯成密碼與加密算法是 那些利用排序來導出加(解)密所需的參數的算法。
281/
依照序號共享技術，將加密與壓縮算法結合應用到包數據。該加密使用例如基於加密的加法序列密碼的密碼轉換，所述加法序列密碼 使用會話密鑰導出用的索引。所用的索引是壓縮協議的主序號
(MSN)。 282/
加密和/或淨艮頭壓縮和/或淨載荷壓縮和/或信令壓縮中的任意進程 使用的排序信息導出於另 一進程，即加密和/或^l良頭壓縮和/或淨載荷 壓縮和/或信令壓縮中的任意另外 一個進程。
283/
加密和/或才艮頭壓縮和/或淨載荷壓縮和/或信令壓縮中的任意進程 使用來自於另 一 功能性進程的排序信息，所述功能性進程是加密和/
或:^艮頭壓縮和/或淨載荷壓縮和/或信令壓縮中的任意進程。
284/
尤其，當加密和/或才艮頭壓縮和/或淨載荷壓縮和/或信令壓縮中的
任意進程使用排序信息時，該排序信息來自於報頭壓縮功能。 285/
排序由加密進程產生，並使排序可用於報頭壓縮算法。壓縮使用 該排序作為其壓縮時的主序號(MSN)。 286/
例如，前述的方法適用於其中根據魯棒報頭壓縮(ROHC)協議 而執行壓縮算法的特定場合，所述魯棒#^頭壓縮(ROHC)協議包括 但不限於ROHCRTP (0x0001 ) 、 UDP (0x0002) 、 IP (0x0004)、 ESP ( 0x0003 ) 、 TCP ( 0x0006 ) 、 UDP畫Lite ( 0x0008 ) 、 RTP/UDP-Lite (0x0007 )才艮頭壓縮協議。
287/
例如，前述的方法可適用於其中根據任意其它一般的壓縮方案而 執行報頭壓縮器和/或報頭解壓縮器時的一些特定場合。 288/
例如，前述的方法適用於密碼算法與加密算法是序列密碼的具體 示例，包括但不限於A5、 GEA、 UEA以及AES。利用排序信息來導出加(解)密所需的參數的其它密碼算法與加密算法也在本發明範圍 內。
289/
例如，前述的可應用到其它壓縮算法，例如諸如SigComp的信令 壓縮、淨載荷壓縮算法(例如那些在PereiraR.的(f炎刀D五i^L4:r五^ /屍淨我V夢在i,》(Pereira, R. /屍Pay/oad Compmw/o" DEFLATE, IETF RFC 2394, December 1998)以及Friend R與R. Monsour的(f炎 ^丄ZS W /屍淨戚#在/#》(Friend, R. et R. Monsour, /屍Pqy/oofd Cow/ m^/o" t/w力g IETF RFC 2395, December 1998 )中所定義 的)，或者可應用到要求排序與校驗和的任意別的操作，用於排序與 校驗和的這種信息可以被別的算法共享，該信息起源並終止於相同節 點。
2卯/
例如，前述的方法適用於aGW, aGW當前在3GPP RAN 2標準 化工作組中^皮定義為SAE/LTE操作的組成部分。 291/
這裡所述的技術、方法、實施方案以及系統有許多優點，包括但 不限於(l)開銷最小化；(2)對現有標準與體系結構的影響小；(3) 與加密上下文的互利互惠及加密上下文的增強魯棒性；以及(4)對 普通報頭壓縮的可應用性。
292/
儘管以上的描述包含許多特徵，但是這些特徵不應被解釋為限制 本發明的範圍而應被解釋為僅僅提供若干目前優選實施方案的例證。 可以理解本發明的範圍完全包括對本領域熟練技術人員而言顯而易 見的其它實施方案，且可以理解該範圍因此不是限制性的。與上述優 選實施方案的要素對應的結構上、化學上及功能上的、對本領域的普 通技術人員而言已知的等同物被明確地合併在這裡，且確定為被包含 在這裡。而且，因此對裝置或方法而言，描述所找到的要由本發明解 決的每個問題是沒有必要的，因為本發明將包括該裝置或方法。
權利要求
1. 一種遠程通信網絡的節點(20)裝置，包括第一功能(30)，配置成對由所述節點(20)處理的包的第一部分執行第一操作；第二功能(32)，配置成對所述包的第二部分執行第二操作；其特徵在於所述第一功能(30)與所述第二功能(32)配置成可使用操作於所述包的共享事務處理(34)，藉助於所述共享事務處理(34)，在執行所述第一操作與所述第二操作後，所述包的歸於所述第一功能(30)與所述第二功能(32)的開銷比不在所述第一操作與所述第二操作的執行中使用所述共享事務處理(34)時少。
2. 權利要求l所述的裝置，其中，所述節點是如下二者之一 系統體系結構演進/長期演進(SAE/LTE )遠程通信網絡的接入網關；以及系統體系結構演進/長期演進(SAE/LTE)遠程通信網絡的增強節 點B ( eNB )。
3. 權利要求1所述的裝置，其中，所述節點(20)包含多個物理 節點，所述第一功能(30)位於第一物理節點(20 (1))，所述第 二功能(32)位於第二物理節點(20 (2))。
4. 權利要求l所述的裝置，其中，所述笫一功能(30)、所述笫 二功能(32)和所述共享事務處理(34)在同一模型層內。
5. 權利要求4所述的裝置，其中，所述第一功能(30)、所述第 二功能(32)與所述共享事務處理(34)由鏈路層協議執行。
6. 權利要求l所述的裝置，其中，所述共享事務處理(34)包括由所述第一功能(30)與所述第二功能(32)使用的共享信息。
7. 權利要求6所述的裝置，其中，所述第一功能(30)是數據壓 縮功能，所述第二功能(32)是加密功能，且所述共享信息是由所述 壓縮功能產生的序號，作為用於所述壓縮功能的序號MSN,所述序號 也4皮所述加密功能用來導出會話密鑰。
8. 權利要求6所述的裝置，其中，所述第一功能(30)是數據壓 縮功能，所述第二功能(32)是加密功能，所述共享信息是由所述加 密功能產生的可從中導出會話密鑰的序號，且所述共享信息也被所述 壓縮功能用作序號MSN。
9. 權利要求l所述的裝置，其中，所述共享事務處理包括也操作 於所述包的第一部分的所述第二功能(32)。
10. 權利要求9所述的裝置，其中，所述第一功能(30)是數據 壓縮功能，所述第二功能(32)是加密功能，所述加密功能對所述包 的報頭的至少 一部分加密。
11. 權利要求10所述的裝置，其中，所述加密功能不對所述報頭 的壓縮信道標識符加密。
12. 權利要求1所述的裝置，其中，所述共享事務處理(34)包 括對所述包的第一部分的至少一部分並對所述包的第二部分的至少 一部分確定一交-險和。
13. 權利要求12所述的裝置，其中，所述第一功能(30)是數據 壓縮功能，所述包的第一部分是包的報頭，所述第二功能(32)是加 密功能，所述包的第二部分是包的淨載荷，對所述包的所述才艮頭的至少一部分並對所述包的所述淨載荷的至少一部分確定所述才交驗和。
14. 權利要求1所述的裝置，其中，所述共享事務處理(34)包 含對所述包的第一部分的至少一部分確定校驗和，所述包的第一部分 的被確定所述校驗和的所述部分包含由所述第二功能(32)在操作於 所述包的第二部分時使用的參數。
15. 權利要求14所述的裝置，其中，所述第一功能(30)是數據 壓縮功能，所述包的第一部分是包的報頭，所述第二功能(32)是加 密功能，所述包的第二部分是包的淨載荷，對所述包的所述寺良頭的至 少一部分確定所述校驗和，由所述第二功能(32)在操作於所述包的 第二部分時使用的所迷參數是為其加密上下文導出會話密鑰的序號。
16. 權利要求1所述的裝置，其中，所述第一功能(30)包括壓 縮功能，配置成可壓縮下述部分中的至少之一所述包的才艮頭、所述 包的淨載荷以及與所述包關聯的信號。
17. —種操作遠程通信網絡節點的方法，包括用第一功能(30)在由所述節點處理的包的第一部分上執行第一操作；用第二功能(32)在所迷包的第二部分上執行第二操作； 其特徵在於使用操作於所述包的共享事務處理(34),藉助子所述共享事務 處理(34)所述共享事務處理既用於所述第一操作又用於所述第二操 作，所述包的可歸於所述第一功能(30)與所述第二功能(32)的開 銷比不在所述第一功能與所述笫二功能的執行中使用所述共享事務 處理(34)時少。
18. 權利要求17所述的方法，其中，所述節點是下述之一系統體系結構演進/長期演進(SAE/LTE)遠程通信網絡的接入 網關；以及系統體系結構演進/長期演進(SAE/LTE)遠程通信網絡的增強 節點B ( eNB )。
19. 權利要求17所述的方法，其中，所述節點包括多個物理節點， 所述方法還包括在第一物理節點上設置所述第一功能(30)並在所述 第二物理節點設置所述笫二功能(32)。
20. 權利要求17所述的方法，還包括使用同一模型層協議來執行 所述第一功能(30 )、所述第二功能(32 )以及所述共享事務處理(34 )。
21. 權利要求20所述的方法，還包括使用鏈路層協議來執行所迷 第一功能(30)、所述第二功能(32)以及所述共享事務處理(34)。
22. 權利要求17所述的方法，其中，所述共享事務處理(34)包 含由所述第一功能(30)與所述第二功能(32)使用的共享信息。
23. 權利要求22所述的方法，其中，所述第一功能(30)是數據 壓縮功能且所述第二功能(32)是加密功能，所述共享信息是由所述 壓縮功能產生的序號，作為用於所述壓縮功能的序號MSN,所述序號 也^皮所述加密功能用來導出會話密鑰。
24. 權利要求22所述的方法，其中，所述第一功能(30)是數據 壓縮功能且所述第二功能(32)是加密功能，所述共享信息是由所述 加密功能產生的從中導出會話密鑰的序號，也被所述壓縮功能用作序 號MSN。
25. 權利要求17所述的方法，其中，所述共享事務處理(34)包含才喿作於所述包的第一部分上的所述第二功能(32)。
26. 權利要求25所述的方法，其中，所述第一功能(30)是數據 壓縮功能，所述第二功能(32)是加密功能，所述加密功能將所述包 的淨艮頭的至少 一部分加密。
27. 權利要求26所述的方法，其中，所述加密功能不將所述報頭 的壓縮信道標識符加密。
28. 權利要求17所述的方法，其中，所述共享事務處理(34)包 含對所述包的第一部分的至少一部分並對所述包的笫二部分的至少 一部分確定4交-險和。
29. 權利要求28所述的方法，其中，所述第一功能(30)是數據 壓縮功能，所述包的第一部分是包的報頭，所述第二功能(32)是加 密功能，所述包的第二部分是包的淨載荷，對所述包的所述才良頭的至 少一部分並對所述包的所述淨載荷的至少一部分確定所述校驗和。
30. 權利要求17所述的方法，其中，所述共享事務處理(34)包 ^^對所述包的第 一部分的至少一部分確定校驗和，被確定所述校驗和 的所述包的第一部分的所述部分包含由所述第二功能(32)在操作於 所述包的第二部分時使用的參數。
31. 權利要求30所述的方法，其中，所述第一功能(30)是數據 壓縮功能，所述包的第一部分是包的報頭，其中所述第二功能(32) 是加密功能，其中所述包的第二部分是包的淨載荷，所述校驗和對所 述包的所述^^頭的至少一部分確定，由所述第二功能(32)在操作於 所述包的第二部分時使用的所述參數是為其加密上下文導出會話密 鑰的序號。
32.權利要求17所述的方法，其中，所述第一功能(30)包含壓 縮功能，配置成可壓縮下述部分中的至少其一所述包的報頭、所述 包的淨載荷以及與所述包關聯的信號。
全文摘要
一種遠程通信網絡的節點包含配置成對由該節點處理的包的第一部分執行第一操作的第一功能(30)和配置成對該包的第二部分執行第二操作的第二功能(32)。第一功能(30)與第二功能(32)配置成可使用操作於該包的共享事務處理(34)，因而藉助於該共享事務處理(34)，在執行第一操作與第二操作後，該包的可歸於第一功能(30)與第二功能(32)的開銷比不在第一功能與第二功能的執行中使用共享事務處理(34)時少。
文檔編號H04W12/02GK101421973SQ200780013166
公開日2009年4月29日 申請日期2007年4月11日 優先權日2006年4月12日
發明者G·佩勒蒂爾, K·斯萬布羅 申請人:艾利森電話股份有限公司