JP4975806B2 - 共有トランザクション（群）を有する複数通信機能 - Google Patents

Description

本発明は、限定されるものではないが、通信におけるデータパケットの暗号化および圧縮等の動作のパフォーマンスを含む通信におけるデータパケットの処理に関するものである。

通信システム等のネットワーク化システムは、典型的にレイヤに分割される。例えば、国際標準化機構（International Organization for Standardization：ＩＳＯ）は、ＯＳＩ（Open Systems Interconnection：オープンシステム相互接続）７レイヤモデルとしても既知であり、かつＯＳＩ７４９８に記載されているＯＳＩネットワークキングモデルを開発している。これは、参照により本明細書に組み込まれる。７レイヤＯＳＩモデルのレイヤ（図３８に示される）は、以下の通りである。（下または第１のレイヤから上または第７のレイヤへ向けて）物理レイヤ、データリンクレイヤ（または「リンク」レイヤ）、ネットワークレイヤ、トランスポートレイヤ、セッションレイヤ、プレゼンテーションレイヤ、およびアプリケーションレイヤである。本明細書で使用されるように、「モデルレイヤ」は、そのようなモデルレイヤを採用するネットワークの／ための仕様がＯＳＩモデルを明確に参照するか否かに関わらず、モデルレイヤに匹敵するまたは類似するレイヤである。各モデルレイヤ内には、各レイヤの機能（群）を１つまたは複数のエンティティユニットあるいは機能ユニットによって実現することができる。この意味で、各モデルレイヤ内には、例えば、圧縮、暗号化およびチェックサム機能レイヤ等の種々の機能レイヤが存在し得る。

インターネットの大いなる成功により、あらゆる種類のリンクを経てインターネットプロトコル（Internet Protocol：ＩＰ）を使用することが試行すべきタスクとなっている。ＩＰプロトコルはＩＰパケットを採用し、ＩＰパケットは、典型的には、実質的なユーザデータを搬送するペイロードと、並びにＩＰパケットの先頭に通常付加される「ヘッダ」を有している。ヘッダは、一般的には、１つまたは複数のＯＳＩモデルレイヤによりＩＰパケットを処理するために有用な情報を搬送する。

ＩＰプロトコルのヘッダが幾分大きいという事実のため、狭帯域リンク、例えば、セルラーリンク用にＩＰプロトコルを使用することは必ずしも簡単なタスクではない。例として、ボイスオーバＩＰ（voice-over-IP：ＶｏＩＰ）用に使用されるプロトコル（ＩＰ、ＵＤＰ、ＲＴＰ）によって伝送される通常の音声データを考慮すると、この場合、ヘッダはパケットの約７０％に相当し、これは、非常に非能率的なリンクの使用となるであろう。

Ａ．ヘッダ圧縮：概要
無線を介して音声およびビデオサービス等のＩＰサービスを経済的に実行可能にするために、ヘッダ圧縮は重要な構成要素である。用語としてのヘッダ圧縮（header compression：ＨＣ）は、ポイントツーポイントリンクを介してホップ毎を基本とするヘッダで搬送される情報に必要な帯域幅を最小にする技術を備えている。ヘッダ圧縮の解決策は、そのようなサービス効率を改善するために、ＩＥＴＦのロバストヘッダ圧縮（Robust Header Compression：ＲＯＨＣ）ワーキンググループにより開発されている。

ヘッダ圧縮技術は、一般に、インターネット社会の中で１０年以上の歴史を有し、以下のようないくつかの一般に使用されるプロトコルが存在する：ＲＦＣ１１４４［ファン ヤコブソン著、低速シリアルリンク用のＴＣＰ／ＩＰヘッダ圧縮（Van Jacobson, Compressing TCP/IP Headers for Low-Speed Serial Links）、ＩＥＴＦ ＲＦＣ１１４４、ＩＥＴＦネットワークワーキンググループ、１９９０年２月］、ＲＦＣ２５０７［ミカエル デジャマーク、ビヨルン ノードグレン、ステファン ピンク著、ＩＰヘッダ圧縮（Mikael Degermark, Bjoern Nordgren, Stephen Pink, IP Header Compression）、ＩＥＴＦ ＲＦＣ２５０７、ＩＥＴＦネットワークワーキンググループ、１９９９年２月］およびＲＦＣ２５０８［スティーブン キャスナー、ファン ヤコブソン著、低速シリアルリンク用のＩＰ／ＵＤＰ／ＲＴＰヘッダ圧縮（Stephen Casner, Van Jacobson, Compressing IP/UDP/RTP Headers for Low-Speed Serial Links）、ＩＥＴＦ ＲＦＣ２５０８、ＩＥＴＦネットワークワーキンググループ、１９９９年２月］。

ヘッダ圧縮は、ヘッダのいくつかのフィールドがフローの中で変化しない、または小さな値でおよび／または予測しうる値で変化するという事実を利用する。ヘッダ圧縮スキームは、これらの特性を使用して、静的情報を最初だけ送信し、一方、変化するフィールドはその絶対値またはパケット毎の差分で送信される。完全にランダムな情報は、全く圧縮することなく送信されなければならない。

ヘッダ圧縮は、２つの状態マシーン間の相互動作として特徴付けられることが多い。この状態マシーンとしては、１つが圧縮マシーンであり、もう１つは解凍マシーンである。そして、それぞれが、コンテキストにおいて圧縮されるフローに関係するある情報を保持している。

圧縮コンテキストは、過去のパケットに関する関連情報を含み、かつ保持し、この情報は、後続パケットの圧縮および解凍を行うために使用される。カールステン ボーマン他著「ロバストヘッダ圧縮（ＲＯＨＣ）：フレームワークおよび４つのプロファイル：ＲＴＰ、ＵＤＰ、ＥＳＰおよび非圧縮（Carsten Bormann, et al. ,RObust Header Compression（ROHC） : Framework and four profiles:RTP, UDP, ESP and uncompressed）」、ＩＥＴＦ ＲＦＣ３０９５、２００１年４月（参照により本明細書に組み込まれる）において説明されるように、
「圧縮器のコンテキストは、圧縮器がヘッダを圧縮するために使用する状態である。解凍器のコンテキストは、解凍器がヘッダを解凍するために使用する状態である。結合するこれらまたは２つのいずれかは、どちらを意図するかが明確な場合、通常「コンテキスト」として参照される。コンテキストは、静的フィールド並びに圧縮および解凍に可能な参照値等のパケットストリームにおける以前のヘッダの関連情報を含んでいる。その上、パケットストリームを記述する追加情報は、また、コンテキストの一部、例えば、ＩＰ識別子フィールドがどのように変化するかについての情報、およびシーケンス番号またはタイムスタンプの典型的なパケット間の増加に関する情報である。

試行すべきタスクは、ヘッダオーバヘッドを可能な限り少なく保つ一方、コンテキストと呼ばれる圧縮器および解凍器の状態を相互に矛盾なく維持することである。圧縮器に対して１つの状態マシーンが存在し、解凍器に対して１つの状態マシーンが存在する。圧縮器状態マシーンは、送信対象の圧縮パケットタイプの選択を制御するロジックの重要な部分であるので、圧縮効率のレベルに直接影響する。解凍器状態マシーンの目的は主としてフィードバック（適用可能である場合）用のロジックを提供すること、および解凍を試行することができるパケットタイプを識別することである。

解凍器にとって、解凍の成功を検証するための手段を提供するパケットがコンテキスト更新パケットである。解凍は検証することができるので、このタイプのパケットはコンテキストを更新することができる。ＲＯＨＣに対しては、コンテキスト更新パケットタイプはそのフォーマット内に巡回冗長符号（Cyclic Redundancy Code：ＣＲＣ）を搬送し、これは元の非圧縮ヘッダに対して計算されるチェックサムである。このＣＲＣは、各パケットの解凍の成功を検証するために使用され、成功すると、コンテキストを更新することができる。

解凍の成功を保証するためにその他の手段に依存する−即ち、解凍器に対して解凍の成功を検証する手段をパケットフォーマットが提供せず、解凍それ自体に必要な情報のみを搬送するパケットは、自己完結（self-contained）パケットである。これらのパケットはコンテキストを更新しない。

ヘッダ圧縮はシーケンス番号を使用して、個々のパケットを固有に識別する。ヘッダフィールドの圧縮は通常シーケンス番号（Sequence Number：ＳＮ）機能に基づいて圧縮する。このＳＮ番号は、圧縮（例えば、ＲＴＰ ＳＮ）されているプロトコルから導出することができる、または圧縮器によって生成することができる。本書類の中では、両者間を区別することが適切でない場合、このようなシーケンス番号をマスタシーケンス番号（Master Sequence Number：ＭＳＮ）と呼んでいる。

以前のヘッダ圧縮プロファイルは、圧縮器と解凍器との間のチャネルがヘッダ圧縮パケットを再順序化しないであろうと想定して設計されていた。チャネルは各圧縮フローのパケット順序を維持することが要求される。この想定の動機となる理由は、ＲＯＨＣを使用する可能性のある候補として当初考えられたチャネルがパケットの順序配信を保証したからである。当時の要件リストにおいて最高位にランクされた目的である圧縮効率およびパケット損失に対するトレーランスを改善するために、この想定は有用であった。

その他の改善の中では、現在開発中であるＲｏＨＣｖ２プロファイルが圧縮プロトコル内の圧縮エンドポイント間の順不同配信および符号化法自身を扱うことになるであろう。

いくつかの異なるタイプの圧縮をリンクレイヤより上で使用することができる。これらはペイロード圧縮（例えば、ペレイラ，Ｒ．著「ＤＥＦＬＡＴＥを使用するＩＰペイロード圧縮（Pereira, R, IP Payload Compression Using DEFLATE）」、ＩＥＴＦ ＲＦＣ２３９４、１９９８年１２月、およびフレンド，ＲおよびＲ．モンスール著「ＬＺＳを使用するＩＰペイロード圧縮（Friend, R et R. Monsour, IP Payload Compression Using LZS）」、ＩＥＴＦ ＲＦＣ２３９５、１９９８年１２月参照）、シグナリング圧縮（例えば、プライス，Ｒ他著「シグナリング圧縮（ＳｉｇＣｏｍｐ）（Price, R et al., Signaling Compressing（SigComp））」、ＩＥＴＦ ＲＦＣ３３２０、２００３年１月参照）、ヘッダ除去および再生、およびヘッダ圧縮を含んでいる。ヘッダ圧縮に関しては、以下を参照されたい：例えば、ファン ヤコブソン著「低速シリアルリンク用のＴＣＰ／ＩＰヘッダ圧縮（Van Jacobson, Compressing TCP/IP Headers for Low-Speed Serial Links）」、ＩＥＴＦ ＲＦＣ１１４４、ＩＥＴＦネットワークワーキンググループ、１９９０年２月、ミカエル デジャマーク、ビヨルン ノードグレン、ステファン ピンク著「ＩＰヘッダ圧縮（Mikael Degermark, Bjoern Nordgren, Stephen Pink, IP Header Compression）」、ＩＥＴＦ ＲＦＣ２５０７、ＩＥＴＦネットワークワーキンググループ、１９９９年２月、スティーブン キャスナー、ファン ヤコブソン著「低速シリアルリンク用のＩＰ／ＵＤＰ／ＲＴＰヘッダ圧縮（Stephen Casner, Van Jacobson, Compressing IP/UDP/RTP Headers for Low-Speed Serial Links）」、ＩＥＴＦ ＲＦＣ２５０８、ＩＥＴＦネットワークワーキンググループ、１９９９年２月、コーレン．Ｔ、キャスナー．Ｓ、ジーバーギース．Ｊ、トンプソン．ＢおよびＰ．ラディ著「長い遅延のあるリンク用の高度圧縮ＲＴＰ（ＣＲＴＰ）、パケット損失および再順序化（Koren.T., Casner. S., Geevarghese.J., Thompson B. and P. Ruddy, Enhanced Compressed RTP（CRTP） for Links with High Delay, Packet Loss and Reordering）」、ＩＥＴＦ ＲＦＣ３５４５、ＩＥＴＦネットワークワーキンググループ、２００３年７月、カールステン ボーマン他著「ロバストヘッダ圧縮（ＲＯＨＣ）：フレームワークおよび４つのプロファイル：ＲＴＰ、ＵＤＰ、ＥＳＰおよび非圧縮（Carsten Bormann, et al.,RObust Header Compression（ROHC）:Framework and four profiles:RTP, UDP, ESP and uncompressed）」、ＩＥＴＦ ＲＦＣ３０９５、２００１年４月、ジョンソン，Ｌ．およびＧ．ペレチエ著「ロバストヘッダ圧縮（ＲＯＨＣ）：ＩＰ用の圧縮プロファイル（Jonsson, L. and G. Pelletier, RObust Header Compression（ROHC）:A compression profile for IP）」、ＩＥＴＦ ＲＦＣ３８４３、２００４年６月、ペレチエ，Ｇ．著「ロバストヘッダ圧縮（ＲＯＨＣ）：ＵＤＰ−ライト用のプロファイル（Pelletier,G., RObust Header Compression（ROHC）:Profiles for UDP-Lite）」、ＩＥＴＦ ＲＦＣ４０１９、２００５年４月およびペレチエ，Ｇ．、サンドランド，Ｋ．およびＬ．ジョンソン著「ロバストヘッダ圧縮（ＲＯＨＣ）：プロファイルまたはＴＣＰ／ＩＰ（Pelletier,G., G.,Sandlund K. and L. Jonsson, Robust Header Compression（ROHC）:A Profile or TCP/IP）」、インターネットドラフト（作業中）、＜draft-ietf-rohc-tcp-11.txt.＞、２００６年１月。これらのタイプの圧縮は、何れもシーケンス番号およびチェックサムを使用するように設計することができる。

その他のタイプの圧縮等他の最適化をまた使用して、さらに帯域幅に制限のあるシステムの性能を増すことができる。

Ｂ．ヘッダ圧縮：検証
ロバストヘッダ圧縮は圧縮ヘッダ（例えば、初期化パケット内の）に対してまたは非圧縮ヘッダ（例えば、圧縮パケットにおける）に対して計算されるチェックサム（ＣＲＣ）を使用する。これは、解凍器における正しい解凍を検証するために使用される。より詳細には、一例として、ヘッダ圧縮は通常チェックサムを使用して、その解凍試行結果を検証する。チェックサムは圧縮される情報の非圧縮状態に対して計算されるチェックサム、または圧縮器と解凍器との間で送信される情報、即ち、圧縮情報、非圧縮情報または圧縮プロトコル情報またはその任意の組み合わせのいずれかに関して計算されるチェックサムであり得る。

同様に、暗号解読アルゴリズムに配信される情報が不正な暗号コンテキストになりえないことを保証するために、フレームチェックサムシーケンス（Frame Checksum Sequence、ＦＣＳ）が暗号解読処理前に使用してたびたび使用される。

未検出残存誤りは、使用されるアルゴリズムに依存して、上述した機能のいずれかに対する同期損失になることがある。

ヘッダ圧縮器は、セキュアリファレンス原理（secure reference principle）を使用して、パケット損失により圧縮器と解凍器との間のコンテキスト同期が失われえないことを保証することができる。圧縮器は、解凍器によって受信される応答確認に基づくコンテキスト更新パケットから、解凍器がコンテキストの更新に成功したことの確信を得る。一方、セキュアリファレンス原理が使用される大部分のパケットタイプは自己完結であり、従ってコンテキストの更新を意味しない。

圧縮器は、通常、コンテキスト更新パケットに対する解凍器の応答確認（フィードバックメッセージのＭＳＮを使用して識別される）の受信後にのみ、その圧縮コンテキストを更新する。

解凍器は、通常、圧縮ヘッダ内で搬送される巡回冗長チェック（cyclical redundancy check：ＣＲＣ）（パケットフォーマットに存在する場合、セキュアリファレンス原理を使用して動作する場合、必ずしも真とは限らない）を使用して、解凍結果を検証後にそのコンテキストを更新する。

Ｃ．セキュリティ／暗号化
新しい構成モデルを使用する展開および設計は伝送経路に含むノード数を削減し、公開標準インタフェースを使用する傾向にある。これは、次いで、従来の機能間分離を変更し、また、セキュリティに関して新しい信頼モデルを作成する。セキュリティはインターネットパラダイムでは通信ホスト間のエンドツーエンド機能と見られることが多いが、セキュリティメカニズムは、低位レベルセキュリティ問題を扱う下位モデルレイヤに見られることが多い。

セキュリティに関して、パケットデータフローの暗号化は、送信側および受信側に暗号状態情報を保持することを要求とすることが多い。この情報は、暗号コンテキストと呼ばれることが多い。

暗号キーは、このコンテキストの一部であり、例えば、１つの「セッション」キーを直接的な暗号変換によって使用することができ、一方で、セッションキーを導出するために、別の「マスタ」キーを使用することができる。このマスタキーは、通常、セキュアな方法でキー管理プロトコルにより与える。コンテキストで検出される他のパラメータは、例えば、暗号化アルゴリズム用の識別子、例えば、セッション用の識別子、カウンタ、キー用の長さパラメータ等であることが多い。これらのパラメータの多くは、アクティブな暗号変換への専用となる。

いくつかのアルゴリズムは、パケットに関連付けられているシーケンス化情報に基づいて、パケット用に使用するためのセッションキーを導出する。例えば、セキュアリアルタイムリファレンスプロトコル（Secure Real-Time Reference Protocol：ＳＲＴＰ）（図１参照）は、パケット内で搬送されるＲＴＰシーケンス番号に基づいて、パケット用のインデックスを導出する。図２に示されるように、ＳＲＴＰは、ＯＳＩアプリケーションレイヤプロトコルであり、ＲＴＰ／ＲＴＣＰプロトコルを使用するリアルタイムアプリケーションへのエンドツーエンドセキュリティレイヤの提供を意味する。ＳＲＴＰは、例えば、バウアー、Ｍ．他著「セキュアリアルタイムトランスポートプロトコル（ＳＲＴＰ）（Baugher, M., The Secure Real-time Transport Protocol（SRTP））」、ＩＥＴＦ ＲＦＣ３７１１、２００４年３月に記載されている。暗号コンテキストの正しい値の導出および更新は比較的大きなパケットの再順序化並びに残存ビット誤りに敏感であるので、キーインデックスの導出には限界があることを本明細書で認めている。上述の再順序化量は、２＾１５パケットのオーダであり、発生しそうにはないが、これはセキュリティレイヤに対して提示される非検出ビット誤りのありうる影響を強調し、ここで、セキュリティレイヤでは、誤りパケットは誤り区間におけるインデックスにより暗号コンテキストを誤って更新し、後続パケットの暗号解読を混乱させ得る。

これらのアルゴリズムは、暗号コンテキストの一部として、このシーケンス情報を維持し、従って、この情報への正しいインデックス付けおよび更新は暗号化エンドポイント間でロバストでなければならない。的確で正しいシーケンス化は、正しい暗号解読キーを使用するために既知でなければならない。ＲｏＨＣによるヘッダ圧縮に反して、暗号コンテキストはいかなる形式の動作成功検証を伴うことなく最も頻繁に更新される。これは、通常、シーケンスが適切に維持されていることを保証するためのロバスト機構を要求する。このような暗号変換の例、および暗号変換が暗号化および暗号解読を実施する方法は、一旦セッションキーが分かると、ＳＲＴＰで検出することができる。

従って、正しい暗号解読キーを抜き取るために、暗号化機能は、暗号化パケットが受信される順序が、暗号化パケットが送信される順序と同一であること、または少なくともこの情報を導出できることを必要とする。そうでなければ、暗号化データを正しく暗号解読しないであろうし、潜在的には、暗号コンテキストは、非同期となり、従って、後続パケットに誤りを伝播することになるであろう。

Ｄ．圧縮：同期
図３はセキュアリファレンス原理を使用して動作する圧縮器（上部）および解凍器（下部）の典型的な例を示している。圧縮パケットは、時間とともに交換され（シーケンス軸）、セキュアリファレンス（Secure Reference：ＳＲ）ＬＳＢのスライディングウィンドウは特定のイベントに従って更新される。ここで、スライディングウィンドウは、ある瞬間には２つ以上の値を含むことができるが、特定フィールドの圧縮および解凍用に使用されるセキュアリファレンスである１つの値のみは常に存在することに留意されたい。

圧縮ピア（peer）の目的は、特定パケットの圧縮／解凍用に使用されるリファレンス（参照）に関して常に同期するようにすることである。特に、以下を適用し、図３で反映されている。

○解凍器のみがコンテキスト更新パケット（セキュアリファレンスを更新することができるパケット）の解凍の成功を確認することができる。

○解凍器は、自己完結パケット（セキュアリファレンスを更新しないパケット）の解凍の成功を確認することができない。

○圧縮器は、解凍器から応答確認を受信すると、そのセキュアリファレンスのスライディングウィンドウを更新する。以前のリファレンス（群）（応答確認されているおよび／または未応答確認されている）がウィンドウから除去され、直近の応答確認されているリファレンスのみをセキュアリファレンスとして保持される。

○パケットが受信され、そのＬＳＢが以前のパケットより小さく、解凍器が以前に応答確認しているリファレンスによりパケットが圧縮されていることを示す場合、解凍器はそのセキュアリファレンスのスライディングウィンドウを更新する。応答確認を送信した直近のリファレンスのみを次いでセキュアリファレンスとして保持する。

従来技術に従えば、「楽観的手法」を使用する場合、圧縮器は常にそのコンテキストを更新する。これは、送信される全パケットが非圧縮ヘッダに関して計算されるチェックサムを含んでいるからである。このチェックサムは、解凍処理の結果を検証するために、解凍器によって使用される。成功する場合、解凍器は、そのコンテキストを更新する。

従来の暗号コンテキストを更新する技術に従えば、暗号コンテキストは、暗号コンテキストが処理する各パケットについて、通常、パケットを暗号解読する場合に見られる最大のシーケンス番号並びに巡回カウンタおよびその他のパラメータにより更新する。シーケンス情報およびその他の暗号化がリンクを経て搬送される場合、暗号コンテキストの更新は、通常、残存ビット誤りの確率が非常に低い、順序配信の保証に強く依存する。この暗号コンテキストの更新は、通常、暗号解読処理の結果を検証する手段を持たない。

Ｅ．無線アクセスネットワーク：概要
典型的なセルラー無線システムでは、無線ユーザ装置ユニット群（user equipment units：ＵＥｓ）は無線アクセスネットワーク（radio access network：ＲＡＮ）を経由して１つまたは複数のコアネットワークと通信する。無線ユーザ装置ユニット群（ＵＥｓ）は移動電話（「セルラー」電話）および移動端末を備えるラップトップ等の移動局であり得る。従って、例えば、携帯、ポケット、ハンドヘルド、コンピュータを含むデバイス、または車載移動デバイスであり得る。そして、これらのデバイスは、無線アクセスネットワークと、音声および／またはデータを通信する。選択的には、無線ユーザ装置ユニットは、固定無線デバイス、例えば、固定セルラーデバイス／端末であり得る。そして、これらは、無線ローカルループまたはその類の一部である。

無線アクセスネットワーク（ＲＡＮ）は、セルエリアに分割される地理的エリアをカバーし、各セルエリアは基地局によってサービスの提供を受ける。セルは地理的エリアであり、これは、基地局サイトの無線基地局装置によって無線通信範囲が提供される。各セルは、セルにおいてブロードキャストされる固有のアイデンティティによって識別される。基地局は、エアインタフェース（例えば、無線周波数）を経て基地局の範囲内のユーザ装置ユニット（ＵＥ）と通信する。無線アクセスネットワークでは、いくつかの基地局は、典型的には、無線ネットワークコントローラ（radio network controller：ＲＮＣ）に（例えば、地上回線またはマイクロウエーブにより）接続される。無線ネットワークコントローラは、また、時には、基地局コントローラ（base station controller：ＢＳＣ）とも呼ばれ、それに接続される複数の基地局の種々の活動を管理し、および調整する。無線ネットワークコントローラは、典型的にじゃ、１つまたは複数のコアネットワークに接続される。

無線アクセスネットワークの一例は、ユニバーサル移動通信（Universal Mobile Telecommunications：ＵＭＴＳ）地上無線アクセスネットワーク（Terrestrial Radio Access Network：ＵＴＲＡＮ）である。ＵＭＴＳは第３世代システムであり、これは、いくつかの点で、ヨーロッパにおいて開発されている移動通信用グローバルシステム（Global System for Mobile communications：ＧＳＭ）として既知の無線アクセス技術を基本としている。ＵＴＲＡＮは、本質的には、ユーザ装置ユニット群（ＵＥｓ）に広帯域符号分割多元接続（wideband code division multiple access：ＷＣＤＭＡ）を提供する無線アクセスネットワークである。第３世代パートナシッププロジェクト（The Third Generation Partnership Project：３ＧＰＰ）は、ＵＴＲＡＮおよびＧＳＭを基本とする無線アクセスネットワーク技術をさらに進化させることを取り組んでいる。

コアネットワークは２つのサービスドメインを有し、ＲＮＣはこれら両ドメインに対するインタフェースを有している。ユニバーサル移動通信（ＵＴＲＡＮ）地上無線アクセスネットワーク（ＵＴＲＡＮ）は、回線交換およびパケット交換接続の両方を収容する。この点に関して、ＵＴＲＡＮでは、回線交換接続は、移動交換局（mobile switching center：ＭＳＣ）と通信する無線ネットワークコントローラ（ＲＮＣ）を含み、ＭＳＣは次いで接続指向の外部コアネットワークに接続され、接続指向の外部コアネットワークは（例えば）公衆交換電話ネットワーク（Public Switched Telephone Network：ＰＳＴＮ）および／またはサービス統合ディジタルネットワーク（Integrated Services Digital Network：ＩＳＤＮ）であり得る。他方、ＵＴＲＡＮでは、パケット交換接続は、在圏（サービスを提供する）ＧＰＲＳサポートノード（Serving GPRS Support Node：ＳＧＳＮ）と通信する無線ネットワークコントローラを含み、このＳＧＳＮは、次いで、バックボーンネットワークおよびゲートウェイＧＰＲＳサポートノード（Gateway GPRS support node：ＧＧＳＮ）を通じてパケット交換ネットワーク（例えば、インターネット、Ｘ．２５外部ネットワーク）に接続される。

ＵＴＲＡＮに関係のあるいくつかのインタフェースが存在する。無線ネットワークコントローラ（ＲＮＣｓ）とコアネットワーク（群）との間のインタフェースは、「ｌｕ」インタフェースと呼ばれる。無線ネットワークコントローラ（ＲＮＣ）とその基地局（base stations：ＢＳｓ）との間のインタフェースは、「ｌｕｂ」インタフェースと呼ばれる。ユーザ装置ユニット（ＵＥ）と基地局との間のインタフェースは、「エアインタフェース」または「無線インタフェース」または「Ｕｕインタフェース」として知られている。

図４は、ここではＵＴＲＡＮアーキテクチャを使用して例示される従来構成の例を示している。ＵＴＲＡＮアーキテクチャに特に関係があるのは、種々のノードへの従来の機能間の分離である。ＲＮＣは、損失のない再配置がサポートされる（オプション）場合のシーケンス化を扱い、従って、１つのシーケンス番号に対してオーバヘッドを加える。暗号化は、ノードＢにおいて発生し、暗号コンテキストを維持するために各ＳＤＵの順序配信を必要とする。暗号化が同期を失わないことを保証するために、Ｌ２フレームチェックサムシーケンス（ＦＣＳ）が通常使用され、エアインタフェースを介する送信用に追加オクテットを追加する。

ハイブリッドＡＲＱメカニズムは、再送信を要求するために、ＲＬＣ ＰＤＵ用の伝送障害を検出しなければならないので、個々のブロックの伝送中に信頼性のあるビット誤り検出を必要とする。従って、Ｈ−ＡＲＱ後の残存ビット誤り（bit error rate：ＢＥＲ）率は非常に低いと想定される。

Ｆ．システム進化：概要
第３世代パートナシッププロジェクト（３ＧＰＰ）は、また、第３世代セルラーシステムの長期的進化を明記し、例えば、より高いユーザビットレートに対する要求を満足する。２００６年９月に、３ＧＰＰは、ＵＴＲＡおよび進化ＵＴＲＡＮと呼ばれる検討項目を終了している。検討の目的は、将来のために、３ＧＰＰアクセス技術の長期的進化（long-term evolution：ＬＴＥ）を定義することであった。また、取り組まれたのは、システムアーキテクチャ進化（System Architecture Evolution：ＳＡＥ）の検討であり、その目的は、多元無線アクセス技術をサポートするデータレートがより高く、遅延のより少ない、パケット最適化システムへの３ＧＰＰシステム進化あるいは移行用のフレームワークの開発である。

進化ＵＴＲＡＮは、ユーザ装置ユニット（ＵＥ）へ進化ＵＴＲＡＵ−プレーンおよびＣ−プレーンプロトコルの終端を提供する、進化基地局ノード、例えば、先進ノードＢあるいはｅＮＢ群を備えている。図５に示されるように、ｅＮＢは、次の機能をホストする：（１）無線リソース管理（例えば、無線ベアラ制御、無線アドミッション制御）用機能、接続移動制御用機能、動的リソース割当（スケジューリング）用機能、（２）例えば、ｅＮＢ群へのページングメッセージの配信を含む移動管理エンティティ（mobility management entity：ＭＭＥ）および（３）ＩＰヘッダ圧縮およびユーザデータストリームの暗号化、ページングを理由とするＵ−プレーンパケットの終端およびＵＥの移動サポートのためのＵ−プレーンのスイッチングを含むユーザプレーンエンティティ（User Plane Entity、ＵＰＥ）である。

ｅＮＢ群は、Ｘ２インタフェースによって相互に接続される。ｅＮＢ群は、また、Ｓ１インタフェースによって、進化パケットコア（Evolved Packet Core：ＥＰＣ）に接続される。Ｓ１インタフェースは、パケットコアにおけるアクセスゲートウェイ（access gateway：ａＧＷ）とｅＮＢ群との間の多対多関係をサポートする。Ｓ１インタフェースは、ユーザプレーンの伝送および制御プレーントラフィックのための進化ＲＡＮ無線リソースへのアクセスを提供する。Ｓ１リファレンスポイントは、ＭＭＥとＵＰＥの分離を可能にし、およびまたＭＭＥとＵＰＥを結合するソリューションの配備を可能にする。

図５に示されるように、ＳＡＥ／ＬＴＥアーキテクチャ用の現在の提案に特に関係のあるのは、ＲＮＣの廃止である。ＲＮＣノードの廃止により、ヘッダ圧縮機能をホストする暗号化機能およびＰＤＣＰ機能が、次いで、同一ノード、例えば、ａＧＷまたはｅＮＢに配置されることになる。暗号化およびＰＤＣＰ機能は、共に他端のユーザ装置（ＵＥ）に終端する。換言すれば、ａＧＷノードとｅＮＢノードとの間のインタフェースは信頼されていない（未信頼である）と考えられる。信頼されていないということは、ｅＮＢが物理的に不正に変更され得ることを意味する。ｅＮＢは、通常、遠隔地に有り、ｅＮＢが危険にさらされれば、多くのユーザ情報は潜在的に濫用されかねない。従って、Ｓ１インタフェースは、暗号化をユーザトラフィックに適用し、これをＵＥにまで伝播することを必要とする。Ｓ１インタフェースを介するセキュアトンネルは、ｅＮＢノードの信頼問題を解決しないであろう。

暗号化および／またはＰＤＣＰエンティティ間の再順序化に関する１つの問題は、Ｓ１インタフェースまたはエアインタフェース（Ｈ−ＡＲＱ）が（ＰＤＣＰがａＧＷにある場合）、順不同パケットを生成しうることである。暗号化は正しいシーケンス情報を必要とするので、シーケンス化の追加オーバヘッドは維持され、かつエアインタフェースを経て送信されなければならない。損失のない再配置をサポートする場合、シーケンス化の追加オーバヘッドは、ＰＤＣＰにおいても必要であり得る。

図６は、ＰＤＣＰ機能およびＳＡＥ／ＬＴＥアーキテクチャに関するサードパーティの提案例を示している。ＰＤＣＰ機能は、また、ＳＡＥ／ＬＴＥアーキテクチャでは、ｅＮＢに配置することができ、その場合、同一の問題がそこでもまた当てはまる。

Ｇ．複数の独立機能レイヤ
上述のように、各モデルレイヤ内に、分離した複数の独立機能レイヤへの機能（群）のレイヤ化がある。モデルレイヤ内における複数の機能レイヤの作成は、かなりのオーバヘッドを引き起こす。以上で簡単に説明した進化ＵＴＲＡＮ（evolved UTRAN：Ｅ−ＵＴＲＡＮ）アーキテクチャ例のように、これまで、これは種々の物理ノードにたいていは分離されている機能として必要とされている。

従来のレイヤ化技術の観点では、モデルレイヤ２暗号化および現在のＥ−ＵＴＲＡＮ／ＳＡＥ／ＬＴＥアーキテクチャに関して、各レイヤ化機能（暗号化等）は、それ自体の個別メカニズムを使用して、シーケンスを維持し、ヘッダ圧縮等のその他の機能とは独立して、おそらくは、ＰＤＣＰシーケンス化と一緒に暗号化を実行する。正しい暗号コンテキストが維持されることを保証するために、Ｈ−ＡＲＱプロトコルより上の残存誤りの検出が必要とされることが多い。これは、また、その他のレイヤの潜在的検証メカニズムとは無関係である。

ヘッダ圧縮に関する従来技術はＲｏＨＣであり、これに関しては、以下の文献がある：カールステン ボーマン他著「ロバストヘッダ圧縮（ＲＯＨＣ）：フレームワークおよび４つのプロファイル：ＲＴＰ、ＵＤＰ、ＥＳＰおよび非圧縮」、ＩＥＴＦ ＲＦＣ３０９５、２００１年４月、およびペレチエ，Ｇ．、サンドランド，Ｋ．およびＬ．ジョンソン著「ロバストヘッダ圧縮（ＲＯＨＣ）フレームワーク（Pelletier,G., G.,Sandlund K. and L. Jonsson, Robust Header Compression（ROHC） Framework）」、インターネットドラフト（作業中）、＜draft-ietf-rohc-rfc3095bis-framework-00.txt.＞、２００５年１２月。ＲｏＨＣは、現在、それ自体のシーケンス番号およびそれ自体のチェックサムを使用する。モデルレイヤ２のシーケンス化およびチェックサムに依存する従来技術の暗号化に同じことが当てはまる。再順序化は取り組まれているが、ＲｏＨＣは、現在これを取り扱わない。この考え方に関係のあるタイプの暗号化に関しては、ＳＲＴＰは、従来技術となる。しかしながら、ＳＲＴＰは、ＯＳＩアプリケーションレイヤにおいて、ヘッダ圧縮と結合することなく動作する。

従来のレイヤ化技術の観点では、暗号化はそれ自体の個別メカニズムを使用して、ヘッダ圧縮とは独立して、おそらくは、ＰＤＣＰシーケンス化と一緒にシーケンス化を維持し、その場合、暗号化処理用の暗号コンテキストからのセッションキーのロバストな選択／導出を保証するために、Ｈ−ＡＲＱプロトコルより上の残存誤り検出が必要とされ、これはヘッダ圧縮機能とは無関係である。暗号化およびヘッダ圧縮は常に互いに独立して取り扱われている。１つのありうる理由は、図７の例示の方法で示されるように、処理し、そのレイヤ自体の（おそらく）共通の要件とは別に（例えば、ＱｏＳ要件に基づいて）他のレイヤに転送する種々のフローとは独立して、かつその種々のフローを知ることなく、いくつかの機能が結合して（例えば、暗号化、再順序化）動作することがよくあるからである。

図８は、例として、ここで取り扱う問題を示している。ＬＴＥ／ＳＡＥタイプのシステムにおいても、同一のノード内においてさえ機能のレイヤ化は大きなオーバヘッドになる。下位レイヤのオーバヘッドに対して、以下の表１は、レイヤ２機能および対応するオーバヘッドを（オクテットで）示している。

表 １
・レイヤ２ＦＣＳ ：３−４オクテット（ビット誤りを扱う）
・レイヤ２（暗号化） ：２オクテット（再順序化＋暗号化キー）
・レイヤ２ＰＤＣＰ ＳＮ ：２オクテット（ロスレス再配置−ＰＤＣＰシーケンス番号ＰＤＵ）
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
総オーバヘッド ：７＋オクテット
ＯＳＩ７４９８ ファン ヤコブソン著、低速シリアルリンク用のＴＣＰ／ＩＰヘッダ圧縮（Van Jacobson, Compressing TCP/IP Headers for Low-Speed Serial Links）、ＩＥＴＦ ＲＦＣ１１４４、ＩＥＴＦネットワークワーキンググループ、１９９０年２月 ミカエル デジャマーク、ビヨルン ノードグレン、ステファン ピンク著、ＩＰヘッダ圧縮（Mikael Degermark, Bjoern Nordgren, Stephen Pink, IP Header Compression）、ＩＥＴＦ ＲＦＣ２５０７、ＩＥＴＦネットワークワーキンググループ、１９９９年２月 スティーブン キャスナー、ファン ヤコブソン著、低速シリアルリンク用のＩＰ／ＵＤＰ／ＲＴＰヘッダ圧縮（Stephen Casner, Van Jacobson, Compressing IP/UDP/RTP Headers for Low-Speed Serial Links）、ＩＥＴＦ ＲＦＣ２５０８、ＩＥＴＦネットワークワーキンググループ、１９９９年２月 カールステン ボーマン他著「ロバストヘッダ圧縮（ＲＯＨＣ）：フレームワークおよび４つのプロファイル：ＲＴＰ、ＵＤＰ、ＥＳＰおよび非圧縮（Carsten Bormann, et al.,RObust Header Compression（ROHC）:Framework and four profiles:RTP, UDP, ESP and uncompressed）」、ＩＥＴＦ ＲＦＣ３０９５、２００１年４月 ペレイラ，Ｒ著「ＤＥＦＬＡＴＥを使用するＩＰペイロード圧縮（Pereira, R, IP Payload Compression Using DEFLATE）」、ＩＥＴＦ ＲＦＣ２３９４、１９９８年１２月 フレンド，ＲおよびＲ．モンスール著「ＬＺＳを使用するＩＰペイロード圧縮（Friend, R et R. Monsour, IP Payload Compression Using LZS）」、ＩＥＴＦ ＲＦＣ２３９５、１９９８年１２月 プライス，Ｒ他著「シグナリング圧縮（ＳｉｇＣｏｍｐ）（Price, R et al., Signalling Compressing（SigComp））」、ＩＥＴＦ ＲＦＣ３３２０、２００３年１月 コーレン．Ｔ、キャスナー．Ｓ、ジーバーギース．Ｊ、トンプソン．ＢおよびＰ．ラディ著「長い遅延のあるリンク用の高度圧縮ＲＴＰ（ＣＲＴＰ）、パケット損失および再順序化（Koren.T., Casner. S., Geevarghese.J., Thompson B. and P. Ruddy, Enhanced Compressed RTP（CRTP） for Links with High Delay, Packet Loss and Reordering）」、ＩＥＴＦ ＲＦＣ３５４５、ＩＥＴＦネットワークワーキンググループ、２００３年７月 ジョンソン，Ｌ．およびＧ．ペレチエ著「ロバストヘッダ圧縮（ＲＯＨＣ）：ＩＰのための圧縮プロファイル（Jonsson, L. and G. Pelletier, RObust Header Compression（ROHC）:A compression profile for IP）」、ＩＥＴＦ ＲＦＣ３８４３、２００４年６月 ペレチエ，Ｇ．著「ロバストヘッダ圧縮（ＲＯＨＣ）：ＵＤＰ−ライト用のプロファイル（Pelletier,G., RObust Header Compression（ROHC）:Profiles for UDP-Lite）」、ＩＥＴＦ ＲＦＣ４０１９、２００５年４月 ペレチエ，Ｇ．、サンドランド，Ｋ．およびＬ．ジョンソン著「ロバストヘッダ圧縮（ＲＯＨＣ）：プロファイルまたはＴＣＰ／ＩＰ（Pelletier,G., G.,Sandlund K. and L. Jonsson, Robust Header Compression（ROHC）:A Profile or TCP/IP）」、インターネットドラフト（作業中）、＜draft-ietf-rohc-tcp-11.txt.＞、２００６年１月 バウアー，Ｍ．他著「セキュアリアルタイムトランスポートプロトコル（ＳＲＴＰ）（Baugher, M., The Secure Real-time Transport Protocol（SRTP））」、ＩＥＴＦ ＲＦＣ３７１１、２００４年３月 ペレチエ，Ｇ．、Ｇ．サンドランド，Ｋ．およびＬ．ジョンソン著「ロバストヘッダ圧縮（ＲＯＨＣ）フレームワーク（Pelletier,G., G.,Sandlund K. and L. Jonsson, Robust Header Compression（ROHC） Framework）」、インターネットドラフト（作業中）、＜draft-ietf-rohc-rfc3095bis-framework-00.txt.＞、２００５年１２月

それゆえ、要望されること、および本発明の目的は、モデルレイヤ２機能（例えば、リンクレイヤ機能）に関連付けられているオーバヘッドを削減するための、１つまたは複数のノード、装置、システム、方法または技術である。

通信ネットワークのノードは、ノードによって取り扱われるパケットの第１の部分において第１の動作を実行するように構成されている第１の機能、およびパケットの第２の部分において第２の動作を実行するように構成されている第２の機能を備えている。第１の機能および第２の機能は、パケットにおける動作に共有トランザクションおよび／または共有サービスを使用するように構成され、第１の動作および第２の動作の実行において共有トランザクションおよび／または共有サービスが使用されない場合より、第１の動作および第２の動作の実行後、共有トランザクションおよび／または共有サービスによって、パケットが有するオーバヘッドを、第１の機能および第２の機能に起因するオーバヘッドをより少なくする。

実装例では、ノードは、システムアーキテクチャ進化／長期的進化（ＳＡＥ／ＬＴＥ）通信ネットワークのアクセスゲートウェイであり、第１の機能、第２の機能および共有トランザクションおよび／または共有サービスを実行するように、リンクレイヤプロトコルが構成される。

別の実装例では、ノードは、システムアーキテクチャ進化／長期的進化（ＳＡＥ／ＬＴＥ）通信ネットワークの先進ノードＢ（ｅＮＢ）であり、第１の機能、第２の機能および共有トランザクションおよび／または共有サービスを実行するように、リンクレイヤプロトコルが構成される。

実装例では、ノードは、システムアーキテクチャ進化／長期的進化（ＳＡＥ／ＬＴＥ）通信ネットワークの移動体ユーザ装置（ＵＥ）であり、第１の機能、第２の機能および共有トランザクションおよび／または共有サービスを実行するように、リンクレイヤプロトコルが構成される。

技術の一側面では、共有トランザクションおよび／または共有サービスは、第１の機能および第２の機能によって使用される共有情報を含んでいる。例えば、一実装例では、第１の機能はデータ圧縮機能であり、第２の機能は暗号化機能であり、共有情報は圧縮機能用のシーケンス番号（ＭＳＮ）として圧縮機能によって発生されるシーケンス番号であり、シーケンス番号はまた暗号化動作用のセッションキーを導出するために、暗号化機能によって使用される。別の実装例では、第１の機能はデータ圧縮機能であり、第２の機能は暗号化機能であり、共有情報はセッションキーを導出する暗号化機能によって発生されるシーケンス番号であり、また、シーケンス番号ＭＳＮとして圧縮機能によって使用される。

技術の一側面では、共有トランザクションおよび／または共有サービスは、パケットの第１の部分においてまた動作する第２の機能を含んでいる。例えば、一実装例では、第１の機能はデータ圧縮機能、第２の機能は暗号化機能であり、暗号化機能はパケットヘッダの少なくとも一部を暗号化する（但し、ヘッダの圧縮チャネル識別子は暗号化しない）。

技術の一側面では、共有トランザクションおよび／または共有サービスは、パケットの第１の部分の少なくとも一部に対する、およびパケットの第２の部分の少なくとも一部に対する、チェックサムの判定を含んでいる。実装例では、第１の機能はデータ圧縮機能であり、パケットの第１の部分はパケットのヘッダであり、第２の機能は暗号化機能であり、パケットの第２の部分はパケットのペイロードであり、パケットのヘッダの少なくとも一部に対し、およびパケットのペイロードの少なくとも一部に対して、チェックサムが判定される。別の実装例では、共有トランザクションおよび／または共有サービスは、パケットの第１の部分の少なくとも一部に対するチェックサムの判定を含み、チェックサムが判定されるパケットの第１の部分の一部はパケットの第２の部分における動作において第２の機能によって利用されるパラメータを含んでいる。例えば、パケットの第２の部分がパケットのペイロードである実装では、パケットヘッダの少なくとも一部に対してチェックサムが判定され、パケットの第２の部分における動作において第２の機能によって利用されるパラメータは、その暗号コンテキストのセッションキーを導出するためのシーケンス番号である。

このように、共有トランザクションおよび／または共有サービスおよび本質的に結合されるまたはマージされる機能の観点では、同一エンドポイントにおいて動作する複数機能間のシーケンス化情報およびチェックサム情報等のトランザクション／情報を共有する方法および装置が提供される。共有トランザクションおよび／または共有サービス技術は、隣接するかしないかにかかわらず、任意の２つの適切な送信ノードおよび受信ノードに適用可能であり、同一情報を共有する複数の機能／処理のために、リンクレイヤがシーケンス化情報および／またはチェックサム情報を保持し、伝送する状況またはアーキテクチャに、特にではあるが排他的ではなく適合する。その上、共有トランザクションおよび／または共有サービス技術が使用される送信ノードは、単一ノードである必要はなく、それよりも複数の機能を分散することができる複数の送信ノードを含むことができる。本技術に含まれる機能は、例えば、ヘッダ圧縮、ヘッダ除去および再生、ペイロード圧縮、シグナリング圧縮、暗号化および再順序化機能のいずれかおよびそれらの任意の組み合わせであり得る。

従って、上述のように要約され、かつ以下でさらに説明されるように、ヘッダ圧縮および暗号化（およびおそらくはその他の機能）は、シーケンス化情報およびチェックサムを共有することができ、個別シーケンス化およびチェックサムを有するオーバヘッドを削減する。ＳＡＥ／ＬＴＥアーキテクチャは、アクセスゲートウェイ（ａＧＷ）内、先進ノードＢ（ｅＮＢ）およびユーザ装置（ＵＥ）内において適用されるこの考え方に対する候補システムを提供する。

本明細書に記載される技術は、また、ＲｏＨＣシーケンス化に基づき、このようにロバストで、かつオーバヘッドなく実現するセキュリティ機能（例えば、暗号化）のヘッダ圧縮プロファイル内への導入を包含する。例えば、本技術は、暗号コンテキスト管理機能の、プロファイル用のヘッダ圧縮コンテキスト管理の既存のメカニズムへのバインドを包含している。さらに、本技術は、ＲｏＨＣに基づき、かつ、チャネルにおける全プロファイルに対する、ヘッダ圧縮チャネルを完全に保護するために、セキュリティ（暗号化および認証）機能の導入を包含している。本技術は、また、比較的完全なＲｏＨＣ用のセキュリティソリューションを包含している。

本発明の上述の、およびその他の目的、特徴および利点は、参照文字が種々の図を通じて同一部分を参照する添付する図面に示されるような、好ましい実施形態の以下のより詳細な説明から明らかであろう。図面は必ずしも一定のスケールではなく、それよりも本発明の原理を示す上で強調を行っている。

以下の記載では、本発明の完全な理解を提供するために、説明のためであり、限定するためでなく、特定のアーキテクチャ、インタフェース、技術等のような特定の詳細が説明する。一方、本発明は、これらの特定の詳細から離れて他の実施形態において実行しうることは当業者には明らかであろう。即ち、本明細書には明示的には記述しないか、または示さないが、本発明の原理を実施し、本発明の精神および範囲内に含まれる種々の装置を、当業者は考案できるであろう。いくつかの例では、不要な詳細により本発明の記載を不明瞭にしないようにするために、周知のデバイス、回路および方法の詳細な説明は省略する。本発明の原理、態様および実施形態、並びにそれらの特定例を列挙する本明細書における全ての記述は、本発明の構成および機能の等価物の両方を包含することを意図している。加えて、このような等価物は、現在、既知の等価物、並びに将来開発される等価物の両方、即ち、構成に関わらず、同一の機能を実行する、開発されるあらゆる要素を含んでいることが意図されている。

従って、例えば、本明細書におけるブロック図は、本技術の原理を実施する例示の回路の概念図を示すことができることが当業者により理解されるであろう。同様に、コンピュータ可読媒体において実質的に表現され、コンピュータまたはプロセッサの明確な図示の有無に関わらず、このようなコンピュータまたはプロセッサにより実質的に実行することができる種々の処理を、任意のフローチャート、状態遷移図、擬似コードおよびその類を示すことが理解されるであろう。

「プロセッサ］または「コントローラ」とラベルが付けられるまたは記載される機能ブロックを含む種々の要素の機能は、専用ハードウェア並びに適切なソフトウェアと関連するソフトウェアを実行することができるハードウェアの使用によって提供されることができる。プロセッサによって提供される場合、これらの機能は、単一の専用プロセッサによって、単一の共有プロセッサによって、または複数の、その内のいくつかは共有される、または分散される個々のプロセッサによって提供することができる。また、用語「プロセッサ」または「コントローラ」の明確な使用は、ソフトウェアを実行することができるハードウェアを排他的に意味すると解釈されるべきでなく、制限することなく、ディジタル信号プロセッサ（digital signal processor：ＤＳＰ）のハードウェア、ソフトウェアを記憶する読出専用メモリ（read only memory：ＲＯＭ）、ランダムアクセスメモリ（random access memory：ＲＡＭ）および不揮発性記憶装置を含むことができる。

１．０ 複数の機能によって共有されるトランザクション（群）
図９Ａは、一点鎖線２４によって示されるインタフェースを介して通信する通信ネットワークの２つのノード２０、２２を示している。図９Ａに示される特定の状況では、ノード２０は送信ノードであり、ノード２２は受信ノードである。送信ノードおよび受信ノードに関するこの指定は、パケットソース２６から取得されるパケットが送信ノード２０に適用される、図示のパケットフローの方向を参照して適用される。送信ノード２０に適用されるパケットは送信ノード２０によって処理され、次いで、インタフェース２４を介して受信ノード２２に送信される。パケットストリームは、また、逆方向に受信ノード２２から送信ノード２０にも伝わりうるが、本技術の顕著な側面を記載するために、送信ノード２０から受信ノード２２への一方向ストリームを考慮することで十分であることは理解されるであろう。

ノード２０は、ノード２０によって取り扱われるパケットの第１の部分における第１の動作を実行するように構成されている第１の機能３０およびパケットの第２の部分における第２の動作を実行するように構成されている第２の機能３２を備えている。第１の機能３０および第２の機能３２は、同一のモデルレイヤ内に存在することができ、それぞれ同一モデルレイヤの異なる機能レイヤであると考えることができる。例えば、第１の機能３０は特定モデルレイヤ内の第１の機能レイヤであると考えることができ、第２の機能３２は特定モデルレイヤ内の第２の機能レイヤであると考えることができる。本明細書において使用されるように、モデルレイヤでない任意の「レイヤ」は機能レイヤであると理解される。

異なる（おそらく同一モデルレイヤ内の）機能レイヤに属するが、第１の機能３０および第２の機能３２は、パケットにおける動作を実行するための共有トランザクションおよび／または共有サービス３４を使用するように構成されている。第１の動作および第２の動作のパフォーマンスに共有トランザクションおよび／または共有サービス３４が使用されていない場合に比べて、第１の動作および第２の動作の実行後、共有トランザクションおよび／または共有サービス３４によって、インタフェース２４を通過するパケットには第１の機能および第２の機能に帰属し得るオーバヘッドはより少なくなる。

図９Ａは、さらに、受信ノード２２と同程度の機能、あるいは、より正確には送信ノード２０の選択される機能の逆機能を備えていることを示している。例えば、受信ノード２２は第２の機能の逆機能４０および第１の機能の逆機能４２を備えている。加えて、送信ノード２０の共有トランザクションおよび／または共有サービス３４に相関するように、受信ノード２２は、送信ノード２０において使用される共有トランザクションおよび／または共有サービス３４の逆のタイプのトランザクションであり得る共有トランザクションおよび／または共有サービス４４を有している。

共有トランザクションおよび／または共有サービス３４が、限定しない一般的な方法で図９Ａに示されている。共有トランザクションおよび／または共有サービスの、特定かつ代表的な、限定しない例を、共有トランザクション技術の様々な側面の例に関して以下で説明する。共有トランザクションおよび／または共有サービスの一例は、排他的または限定的と取られるべきでなく、提供されるいくつかの例は、網羅的ではなく、少なくとも部分的に、例えば、共有トランザクション等の技術によって機能がどのようにして組み合わされるまたはマージされるかについてのより広い範囲に関する理解に資するためのみに詳述される。本明細書において使用されるように、用語「共有トランザクション（shared transaction）」は、共有トランザクションおよび／または共有サービスの両方またはいずれかを包含すると理解される。

本明細書に記載される送信ノード２０および受信ノード２２等のノードは、特に、本明細書に記載される機能を越えるいくつかの機能を典型的には有すること、およびこのようなノードが本明細書に含まれるように示される２つの機能、または、実際、任意の特定の数または性質の機能に限定されないことがさらに理解されるべきである。例えば、限定するものではない一実装例では、送信ノード２０は、システムアーキテクチャ進化／長期的進化（ＳＡＥ／ＬＴＥ）通信ネットワークのアクセスゲートウェイ（ａＧＷ）または先進ノードＢ（ｅＮＢ）であり得り、また、このようなものとして、中でも図８に示される機能例を含むことができる。ＳＡＥ／ＬＴＥの実装では、インタフェース２４は、Ｓ１インタフェースおよびＵｕ（エア）インタフェース等の１つまたは複数の（集約的）インタフェースを示すことができる。

さらに図１０に示す実装例では、リンクレイヤプロトコル４６は第１の機能３０、第２の機能３２および共有トランザクション３４を実行するように準備し、構成する。その他の実装では、これらの機能を全てリンクレイヤプロトコルにより実行するかまたはホストする必要はない。

簡単に説明するために、図９Ａおよび図１０は、第１の機能３０および第２の機能３２を備える送信ノード２０を単一ノードであるものとして示している。一方、本明細書で使用されるように、用語「ノード」および特に送信ノードは、共有トランザクション技術に関係する機能を有する複数のノードを包含している。換言すれば、共有トランザクション技術が使用される送信ノードは、単一ノードである必要はなく、それよりも、複数の機能（例えば、第１の機能３０および第２の機能３２）に分散することができる複数のノードを備えることができる。例えば、図９Ｂは、送信ノード２０は、２つの物理的な別個のノード２０（１）および２０（２）を備えるように示している。第１の物理ノード２０（１）は第１の機能３０を備え、一方、第２の物理ノード２０（２）は第２の機能３２を備えている。第１の機能３０および第２の機能３２は、同一モデルレイヤプロトコル４６Ｂ（例えば、リンクレイヤ）に属していても属していなくても良く、また、これらは、共有トランザクション３４Ｂの対象となっている、あるいは共有トランザクション３４Ｂに関係している。共有トランザクション３４Ｂは、第１の機能３０または第２の機能３２のいずれか、またはそれらの組み合わせによって実行されるまたは提供されても良い。従って、機能（例えば、機能レイヤ）が異なる物理ノードにおいて存在するまたは実行されるとしても、図９Ｂは、異なる機能レイヤ（例えば、機能３０および機能３２等の異なる機能）に共有トランザクション技術を適用可能であるように示している。複数の物理ノードへの共有トランザクション技術のこの分散のみが図９Ｂで示されるが、このような分散は、本明細書に記載される全ての実施形態およびモードに適用する。

汎用の図９Ａの実施形態、図９Ｂの実施形態、図１０の実施形態および全ての後続の実施形態では、本明細書において上述のように用語「プロセッサ」および「コントローラ」の広義の説明と理解が与えられる、送信ノード２０のコントローラまたはプロセッサによって、第１の機能３０、第２の機能３２および共有トランザクション３４を実行することができる。

図１１に示す技術の一側面では、共有トランザクションは第１の機能および第２の機能によって使用される共有情報を備えている。この共有情報の非限定例は、共通シーケンス化情報であり、以下で、特に（例えば）本明細書のセクション４．０を参照してさらに説明する。

基本的に、シーケンス化情報を含む１つの単独フィールドを、どの処理の組み合わせがアクティブとなるかとは無関係に、複数のこれらの処理のために搬送される。暗号化および／またはヘッダ圧縮および／またはペイロード圧縮および／またはシグナリング圧縮をサポートするレイヤは、シーケンス化情報を搬送するために使用される。複数のレイヤがアクティブである場合、このシーケンス化情報は複数の機能レイヤ（例えば、ヘッダ圧縮と暗号化、または別の組み合わせ）に共通であり得り、アクティブな処理／アルゴリズムのいずれか１つによって（または複数の動作が、実装されるまたは共にアクティベートされる場合には、その複数の動作により）生成することができる。このシーケンス化情報は、また、ヘッダ圧縮処理および／または暗号化処理および／またはペイロード圧縮処理および／またはシグナリング圧縮処理の下のレイヤプロトコルから発生し得る。選択的には、シーケンス化情報は、アプリケーションレイヤから等のリンクレイヤより上の別のレイヤ（例えば、アプリケーションレイヤにあるリアルタイムプロトコル（Real Time Protocol：ＲＴＰ）等のプロトコルから）から発生し得る。

例えば、図１２に示される一実装例では、第１の機能３０はデータ圧縮機能、第２の機能３２は暗号化機能であり、共有情報３４（１２）は、圧縮機能３０用のシーケンス番号ＭＳＮとして、圧縮機能３０によって発生するシーケンス番号である。同一シーケンス番号は、また、暗号化動作用のセッションキーを導出するために、暗号化機能３２によって使用される。

第１の機能３０が再度データ圧縮機能であり、第２の機能３２が暗号化機能である、図１３に示す別の実装例では、共有情報３４（１３）はセッションキーを導出する暗号化機能３２によって発生するシーケンス番号であり、また、これは、シーケンス番号ＭＳＮとして圧縮機能３０によって使用される。

シーケンス番号は、圧縮アルゴリズム用の共有シーケンス番号に対するオフセットとして導出することができる。基本的には、シーケンス番号情報を送信する圧縮アルゴリズムは、このシーケンス番号を、複数の機能レイヤ間で共有される、シーケンス番号付与からのオフセットとして符号化する。

暗号化レイヤは、通常、接続に関して実行し、ＳＤＵがどのＩＰフローに属するかには無関係に全てのＳＤＵを処理する。これは圧縮アルゴリズムおよびプロトコルに対して同一であっても良いが、これらは、それよりもより細かな粒度レベルにおいて動作することが多く、圧縮効率の向上を得るためにパケットをフロー毎に処理する。このような場合、「接続」において動作する別のレイヤと共有されるシーケンス番号は、接続が正確に１つであって、かつ唯一のパケットフローに対応しない限り、フローのパケット毎ではなく、ＳＤＵ毎に値を変更することになるであろう。

「フロー毎」の圧縮アルゴリズムによって見られる変化パターンは、接続を介する各フローのレート（これは変動しうる）、並びに異なるフロー数に依存することになる。一方、シーケンス番号がジャンプする変化パターンは、制限値に達する可能性があり、また、圧縮アルゴリズムは、その絶対値に基づく、またはオフセットに基づく、共有シーケンス番号に基づいて、圧縮ビット（ＬＳＢまたはＷ−ＬＳＢ）を送信することができる。カールステン ボーマン他著「ロバストヘッダ圧縮（ＲＯＨＣ）：フレームワークおよび４つのプロファイル：ＲＴＰ、ＵＤＰ、ＥＳＰおよび非圧縮」、ＩＥＴＦ ＲＦＣ３０９５、２００１年４月におけるオフセット符号化をまた参照されたい。

「フロー毎」に動作することができる圧縮アルゴリズムの例は、ヘッダ圧縮および／またはペイロード圧縮および／またはシグナリング圧縮および／またはヘッダ除去を含んでいる。

図１４に一般的に示される技術の別の側面では、共有トランザクション３４（１４）はパケットの第２の部分において動作するのみならずまた、少なくとも部分的に第１の機能３０による動作の対象となるパケットの第１の部分においても動作する第２の機能３２を備えている。例えば、図１５に示される一実装例では、第１の機能３０はデータ圧縮機能、第２の機能３２は暗号化機能であり、暗号化機能３２はパケットヘッダの少なくとも一部を暗号化する（但し、以下で説明するように、ヘッダの圧縮チャネル識別子またはシーケンス化を暗号化しない）。この実装例は、さらに以下で、特に（例えば）本明細書のセクション３．０を参照して説明する。

図１６に一般的に示される技術の一側面では、共有トランザクションは、パケットの第１の部分の少なくとも一部に対する、およびパケットの第２の部分の少なくとも一部に対する、チェックサムの判定、例えば、「共有チェックサム」の判定を含んでいる。基盤レイヤは共通チェックサム情報を搬送し、例えば、暗号化および／またはヘッダ圧縮および／またはシグナリング圧縮および／またはペイロード圧縮をサポートするレイヤは、チェックサム情報を搬送する。この情報は、複数のレイヤがアクティブである場合に、複数の機能レイヤ（例えば、ヘッダ圧縮と暗号化、または別の組み合わせ）に共通であり得り、従って、アクティブな処理／アルゴリズムのいずれか１つによって（または複数の動作が実装されるまたは共にアクティベートされる場合、その複数の動作により）生成される。

図１７に示される実装例では、第１の機能３０はデータ圧縮機能、パケットの第１の部分はパケットヘッダであり、第２の機能３２は暗号化機能、パケットの第２の部分はパケットペイロードである。パケットヘッダの少なくとも一部に対しおよびパケットペイロードの少なくとも一部に対して、チェックサムが判定される。この実装例を、さらに、以下で、特に（例えば）本明細書のセクション２．１を参照して説明する。

図１８に示される別の実装例では、共有トランザクションは、パケットの第１の部分の少なくとも一部（例えば、パケットヘッダ）に対するチェックサムの判定を含み、チェックサムが判定されるパケットの第１の部分の一部は、パケットの第２の部分における動作において第２の機能によって利用されるパラメータを含んでいる。例えば、パケットの第２の部分がパケットペイロードである実装では、パケットヘッダの少なくとも一部に対してチェックサムが判定され、パケットの第２の部分における動作において第２の機能によって利用されるパラメータは、自身の暗号コンテキスト用のセッションキーを導出するためのシーケンス番号である。この実装例をさらに以下で、特に（例えば）本明細書のセクション２．２を参照して説明する。

このように、共有トランザクションおよび本質的に組み合わされるまたはマージされる機能の観点では、同一エンドポイントにおいて動作する複数の機能、例えば、同一モデルレイヤ内において動作する複数の機能レイヤ間のシーケンス化情報およびチェックサム情報等のトランザクション／情報を共有する方法および装置が提供される。共有トランザクション技術は、隣接する否かに関わらず、任意の２つの適切な送信ノードおよび受信ノードに適用可能であり、同一情報を共有する複数の機能／処理のために、リンクレイヤは、シーケンス化および／またはチェックサム情報を保持し、伝送（トランスポート）する状況またはアーキテクチャに特にではあるが必ずしも排他的ではなく適合する。その上、上述の図１０Ｂを参照して説明されるように、共有トランザクション技術が使用される送信ノードは、単一ノードである必要はなく、それよりも複数の機能に分散されていても良い複数の送信ノードを含むことができる。本技術によって含まれる、または目標とされる機能群（例えば、機能レイヤ群）は、（例えば）ヘッダ圧縮、ヘッダ除去および再生、ペイロード圧縮、シグナリング圧縮、暗号化および再順序化機能のいずれかおよびそれらの任意の組み合わせであり得る。

上述で要約され、かつさらに以下で説明されるように、ヘッダ圧縮および暗号化（およびおそらくその他の機能）は、シーケンス化情報およびチェックサムを共有することができるので、個別のシーケンス化およびチェックサムを有するオーバヘッドを削減する。ＳＡＥ／ＬＴＥ構成は、この考え方をアクセスゲートウェイ（ａＧＷ）およびユーザ装置（ＵＥ）内において適用するための候補システムを提供する。

リンクレイヤのようなレイヤは、同一エンドポイント内において動作し、かつこの同一情報を共有する複数の機能レイヤ（例えば、暗号化および／またはペイロード圧縮および／またはヘッダ圧縮）のために、シーケンス化情報およびチェックサム（群）を搬送する。別の態様として、暗号化およびヘッダ圧縮は、少なくとも一部と共に取り扱われ、一方、暗号化処理のセッションキー導出アルゴリズムに対する圧縮／暗号化エンドポイント間の再順序化およびパケット損失にロバスト性を提供する。また、暗号キー導出の選択をよりロバストにするために、暗号コンテキスト管理は、ヘッダ圧縮用のコンテキスト管理と協同して取り扱われる。

共有トランザクション技術を使用して、同一情報を使用するようにすることができ、かつ同一エンドポイント（任意の組み合わせにおける、ロバストヘッダ圧縮、ヘッダ除去、ペイロード圧縮、シグナリング圧縮および／または暗号化のいずれか等）内において動作する機能間のシーケンス化およびチェックサムの共有のような、機能間のトランザクションの共有は、オーバヘッドの削減になる。例えば、いくつかの実施形態および／または実装において、共有トランザクション技術を使用すると、オーバヘッドを表２のように削減することができる。

表 ２
・共通チェックサム（例えば、ＣＲＣ１６）：２＋オクテット（ビット誤り、解凍、検証）
・共通シーケンス番号 ： １オクテット（再順序化＋暗号化キー）
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
総計： ３＋オクテット
上述のように、オーバヘッドをいくらか除去するために、同一情報を使用するようにすることができ、かつ同一エンドポイント（任意の組み合わせにおけるロバストヘッダ圧縮、ヘッダ除去、ペイロード圧縮、シグナリング圧縮および／または暗号化のいずれか等）内において動作する機能間に、共有シーケンス化およびチェックサムのようなの共有トランザクションが導入される。限定しないが、ＲＦＣ３０９５、カールステン ボーマン他著「ロバストヘッダ圧縮（ＲＯＨＣ）：フレームワークおよび４つのプロファイル：ＲＴＰ、ＵＤＰ、ＥＳＰおよび非圧縮」、ＩＥＴＦ ＲＦＣ３０９５、２００１年４月の圧縮器および解凍器のシーケンス化要件および動作、並びに暗号化アルゴリズムの汎用プロパティに基づき、次に可能性のある実施形態を説明する。

２．０：圧縮コンテキストと暗号コンテキストの結合（合同：combined）管理：概要
１つのその側面において、本技術は、複合または共有トランザクションを使用する圧縮コンテキストと暗号コンテキストの合同管理に関係する。圧縮プロトコルから導出されるシーケンス化およびチェックサムを使用して、暗号化が実行される場合（即ち、解凍の検証）、圧縮アルゴリズムのコンテキスト管理ルールが暗号コンテキスト管理に適用される。合同コンテキスト管理は、送信ノードおよび受信ノードの特徴を備え、ここで、送信ノードが、例えば、パケットのヘッダ部の少なくとも一部における圧縮およびそのパケットの少なくとも一部における暗号化を実行することによって、受信ノードにおいて、パケットの解凍と暗号解読の検証が相互依存である範囲に圧縮と暗号化がバインドされる。

この側面の第１のモードの例では、共有トランザクションまたは複合サブ動作は、圧縮対象のパケットの少なくとも一部および暗号化対象のパケットの一部に対する複合チェックサムの判定を含んでいる。この第１のモードでは、例えば、送信ノードにおいて計算されるように、チェックサムは、暗号化されることになるパケット部の（元の非暗号化）一部並びに圧縮されることになる（元の非圧縮）一部を含んでいても良い。受信側では、暗号化レイヤは、パケットの暗号化部の暗号解読を実行し、解凍器は圧縮部を解凍する（重複が存在しない場合、何れの処理も最初にすることができる）。第１のモードでは、次いで、チェックサムを使用して、解凍および暗号解読処理の両方の結果を検証し、成功する場合、この結果は、圧縮コンテキストおよび暗号コンテキストそれぞれを更新することになる。換言すれば、解凍が検証される場合、その場合、暗号解読も成功し、従って、暗号解読は暗黙的に検証される。

圧縮コンテキストと暗号コンテキストの合同管理の態様に関する第２のモード例では、複合サブ動作は、共有情報としてシーケンス番号を使用する圧縮機能および暗号化機能を含んでいて、このシーケンス番号は、セッションキーの導出用に暗号化機能によって使用される。第２のモードでは、暗号化機能が圧縮マスタシーケンス番号を使用して、その暗号コンテキストからセッションキーを導出する場合には、シーケンス番号情報を含む圧縮されることになる（元の非圧縮）部分のみがチェックサムによってカバーされる必要がある。このように、第２のモード例では、圧縮対象のパケットの少なくとも一部に対し、および暗号化対象のパケット部に対して、（オプションで）チェックサムが計算される。第２のモードでは、チェックサムを使用して、解凍処理の結果のみを検証し、成功する場合、これは圧縮コンテキストおよび暗号コンテキストそれぞれの更新になる。このシーケンス番号ＭＳＮがこのようにして検証され、これが、暗号コンテキストに対する唯一の敏感な情報となる。

いずれかのモードにおいて、トランスポートレイヤ（例えば、ＵＤＰ、ＴＣＰ）チェックサムを使用して、さらに処理結果の確認を提供することができる。コンテキスト更新ルールは、また、第２のモードにおける圧縮のコンテキスト更新ロジックに従う。

暗号化が同一ノードにおけるヘッダ圧縮と共に実行されると、シーケンス化および再順序化機能に対するオーバヘッドを削減する。暗号化とヘッダ圧縮の特徴の１つの単独プロトコルへの結合は、この技術の実質的な結果となり得る。プロトコルは、また、ペイロード圧縮用のサポートを含むことができ、同一タイプのルールは、これにも適用することができる。

本明細書におけるコンテキスト管理は、すべての圧縮パケットが暗号化される、またはそのサブセットのみが暗号化される（例えば、ペイロードのみが暗号化される）場合に対して適用する。両モードにおいて、チェックサムは、圧縮動作および暗号化動作の検証を容易にする。

２．１：圧縮コンテキストと暗号コンテキストの合同管理：第１のモード：概要
図１９は第１のモード例に含まれる、基本的、代表的な動作またはイベント例を示している。動作１９−１は、送信ノードにおいて実行される動作例を示している。特に、送信ノードにおける入力パケットに対して、入力パケットの圧縮候補部に対しておよび入力パケットの暗号化候補ペイロード部に対して初期チェックサムが判定される。初期チェックサムは、少なくとも部分的に圧縮され、かつ少なくとも部分的に暗号化されている、インタフェース通過パケットに含まれている。インタフェース通過パケットは、図９Ａのインタフェース２４として例示される、インタフェースを介してその後に送信される。上述のように、インタフェース２４は、単独インタフェースであり得る（例えば、先進ノードＢの場合のＳ１インタフェースまたはＵｕインタフェース）、または、Ｓ１インタフェースおよびＵｕインタフェースの両方等のいくつかのインタフェースを集約的に示すことができる。動作１９−２は、暗号解読および解凍が実行されて回復パケットを取得した後の、受信ノードにおいてインタフェース通過パケットの受信時に実行される動作例を示している。動作１９−２の動作は、回復パケットに対する検証チェックサムの判定を含んでいる。さらに、検証チェックサムと初期チェックサムとの比較は、暗号解読および解凍の両方の検証を判定するために使用される。

２．１．１：圧縮コンテキストと暗号コンテキストの合同管理：第１のモード：実装：送信ノード
対応して配置される図２１のパケットの図と共に図２０のフローチャートの動作によって、送信ノードにおける図１９の第１のモードの詳細な実装例が示される。対応して配置される図２３のパケットの図と共に図２２のフローチャートの動作によって、受信ノードにおける図１９の第１のモードの対応する詳細な実装が示される。

第１のモードの実装例の送信ノードでは、動作１９−１−ａは、入力パケットの圧縮候補部に対するおよび入力パケットの暗号化候補ペイロード部に対する初期チェックサムＩＣＫＳＵＭの判定を含んでいる。実装例において、図２１は、入力パケットの全圧縮候補部ＣＣＰおよび全暗号化候補ペイロード部ＥＣＰＲに対して計算される、または判定される初期チェックサムＩＣＫＳＵＭを示している。チェックサム計算ロジックが理解する、または送信ノードおよび受信ノードの両方においてチェックサム計算ロジックが矛盾なく予め構成される限り、全入力パケットより少ないパケットに対して、例えば、全圧縮候補部ＣＣＰより少ない部分に対しておよび／または全暗号化候補ペイロード部ＥＣＰＲより少ない部分に対して、動作１９−１−ａのチェックサムＩＣＫＳＵＭを計算することできることが理解されるであろう。

動作１９−１−ｂは、圧縮ストリングＣＳを提供するために、入力パケットの圧縮候補部ＣＣＰにおける圧縮の実行を含んでいる。動作１９−１−ｂの圧縮は、限定されるものではないが、本明細書において記載または言及されるものを含む任意の適切な圧縮技術であり得る。

動作１９−１−ｃは、暗号ストリングＥＳを提供するために、入力パケットの少なくとも暗号化候補ペイロード部ＥＣＰＲの暗号化を含んでいる。図２１に示す実装例では、暗号化は、暗号化候補ペイロード部ＥＣＰＲだけでなく、圧縮候補部ＣＣＰをもカバーしている。変形実装では、暗号化は、また、初期チェックサムＩＣＫＳＵＭをカバーすることができることが理解されるべきである。選択的には、別の変形では、暗号化は暗号化候補ペイロード部ＥＣＰＲのみをカバーすることができる（圧縮候補部ＣＣＰまたは初期チェックサムＩＣＫＳＵＭを含まない）。実装または変形の如何に関わらず、動作１９−１−ｃの暗号化は、限定されるものではないが、本明細書において記載または言及されるものを含む、任意の適合する暗号化技術であり得る。

動作１９−１−ｄは、入力パケットに対応するインタフェース通過パケットの形成を含んでいる。動作１９−１−ｄのパケット形成は、インタフェース通過パケットに含む、少なくとも圧縮ストリングＣＳ、暗号ストリングＥＳおよび初期チェックサムを含んでいる。暗号化が暗号化候補ペイロード部ＥＣＰＲのみをカバーする場合、これら３つの構成要素は個別にインタフェース通過パケットにアセンブルされる。一方、暗号化が暗号化候補ペイロード部ＥＣＰＲより多くをカバーする場合、インタフェース通過パケットの１つまたは複数のその他の構成要素の全てまたは一部は、暗号ストリングＥＳによって包含されても良い。即ち、暗号化が圧縮候補部ＣＣＰをカバーする場合、インタフェース通過パケットに暗号ストリングＥＳを含めることは、インタフェース通過パケットに圧縮候補部ＣＣＰの全てまたは一部を含めることを包含する。同様に、暗号化が初期チェックサムＩＣＫＳＵＭをカバーする場合、インタフェース通過パケットに暗号ストリングＥＳを含めることは、インタフェース通過パケットに初期チェックサムＩＣＫＳＵＭを含めることを包含する。

２．１．２：圧縮コンテキストと暗号コンテキストの合同管理：第１のモード：実装：受信ノード
対応して配置される図２３のパケットの図と共に図２２のフローチャートの動作によって、受信ノードにおける図１９の第１のモードの対応する詳細な実装が示される。図２２の動作１９−２−ａは、暗号解読ストリングを提供するために、インタフェース通過パケットの暗号ストリングＥＳの暗号解読を含んでいる。動作１９−２−ａの暗号解読は、動作１９−１−ｃにおいて利用される、対応する暗号化技術の逆技術によって実行される。

図２１に示される特定の実装の観点では、圧縮ストリングＣＳを含むように暗号ストリングＥＳが準備されているので、図２２は、圧縮ストリングＣＳ、および暗号化候補ペイロード部ＥＣＰＲに対応する（暗号化および暗号解読が成功したことを想定して）ペイロード部を提供するために、暗号ストリングＥＳを展開する際の暗号解読を示している。別の変形では、圧縮ストリングＣＳが暗号化対象でない場合、ここでは、圧縮ストリングＣＳは、動作１９−２−ａの暗号解読の対象にならないであろう。さらになお別の変形では、初期チェックサムＩＣＫＳＵＭをまた暗号化対象でない場合（図２２の破線によって示されるように）、初期チェックサムＩＣＫＳＵＭはまた動作１９−２−ａの一部としての暗号解読となるであろう。

動作１９−２−ｂは、解凍ストリングＤＳを提供するために、インタフェース通過パケットの圧縮ストリングＣＳの解凍を含んでいる。動作１９−２−ｂの解凍は、動作１９−１−ｂの圧縮動作用に使用された圧縮技術の逆技術によって実行される。

動作１９−２−ｃは、動作１９−１−ａにおける初期チェックサムの判定に対応するように、解凍ストリングＤＳおよび暗号解読ストリングに対する検証チェックサムＶＣＫＳＵＭの判定を含んでいる。

動作１９−２−ｄは、動作１９−２−ａの暗号解読および動作１９−２−ｂの解凍の両方の検証を判定するために、動作１９−２−ｃにおいて実行されるような検証チェックサムと初期チェックサムとの比較の使用を含んでいる。

動作１９−２−ｅは、動作１９−２−ｄの検証に従う圧縮コンテキストの更新を含んでいる。動作１９−２−ｆは、動作（２−ｄ）の検証に従う暗号コンテキストの更新を含んでいる。

圧縮コンテキストと暗号コンテキストの合同管理：第１のモード：エピローグ
このように、圧縮コンテキストと暗号コンテキストの合同管理の第１のモードでは、暗号化および圧縮は、ペイロード（の少なくとも一部）を含むチェックサム適用範囲と同一のチェックサムを使用するまたは共有する。

基本的には、解凍処理の結果を検証するために使用されるチェックサムは、また、セッションキーの判定の（例えば、暗号解読処理の）成功を検証する。図１９で概して説明され、かつ図２０および図２１でのより特定的な実装例で示されるように、チェックサムは、暗号化されることになるパケット部の（元の非暗号化）一部、並びに圧縮されることになる（元の非圧縮）部分をカバーしている。

送信側では（例えば、図２０の動作１９−１−ａを参照）、チェックサムは、暗号化されることになるパケット部の（元の非暗号化）一部、並びに圧縮されることになる（元の非圧縮）部分をカバーするように計算される。

受信側では（例えば、図２０を参照）、パケットはまず暗号解読される（例えば、動作１９−２−ａを参照）。ここで、シーケンス化は圧縮とは無関係であることに留意されたい。暗号解読処理の結果は、次いで、暗号解読処理の結果を検証することなく解凍器に渡されても良い。解凍が、次いで実行される（動作１９−２−ｂ）。

解凍および暗号解読処理の両方の結果を検証するために、圧縮パケットと共に受信されるチェックサム（初期チェックサムＩＣＫＳＵＭ）が次いで使用される。成功する場合、それぞれ圧縮コンテキストおよび暗号コンテキストが更新される（動作１９−２−ｅおよび動作１９−２−ｆ）。圧縮コンテキストは、適用可能である場合、圧縮フォーマットのコンテキスト更新プロパティに基づき並びに動作モードに基づき更新される。チェックサムが暗号化された少なくとも全ての情報をカバーしていることが提供されると、解凍が成功する場合、暗号解読動作も成功であると想定することができ、関係する状態は、次パケットの処理用に更新することができる。

２．２：圧縮コンテキストと暗号コンテキストの合同管理：第２のモード：概要
圧縮コンテキストと暗号コンテキストの合同管理の態様に関する第２のモードの例では、複合サブ動作は、共有情報としてシーケンス番号を使用する圧縮機能および暗号化機能を含み、このシーケンス番号は、セッションキーの導出用に、またはセッションキーを導出するために、暗号化機能によって使用される。加えて、この態様に関する第２のモードの例では、圧縮対象のパケットの少なくとも一部に対しおよび暗号化対象のパケットの一部に対し（オプションで）チェックサムが計算される。両モードにおいて、チェックサムは、圧縮動作および暗号化動作の検証を容易にする。

２．２．１：圧縮コンテキストと暗号コンテキストの合同管理：第２のモード：実装：送信ノードの動作
図２４は、第２のモードの例に含まれる、基本的、代表的な動作あるいはイベント例を示している。動作２４−１は、送信ノードにおいて実行される動作例を示している。特に、送信ノードにおける入力パケットに対し、その入力パケットの圧縮候補部に対する初期チェックサムが判定される。この第２のモードでは、圧縮候補部は、圧縮動作用に使用されるシーケンス番号を含んでいる。また、第２のモードでは、同一シーケンス番号が、入力パケットの暗号化候補ペイロード部の暗号化に使用するためのセッションキーを導出するための共有情報として使用される。初期チェックサムは、少なくとも部分的に圧縮され、また、少なくとも部分的に暗号化されるインタフェース通過パケットに含まれている。インタフェース通過パケットは、図９Ａのインタフェース２４として例示されるインタフェースを介してその後に送信される。上述のように、インタフェース２４は、単独インタフェース（例えば、先進ノードＢの場合のＳ１インタフェースまたはＵｕインタフェース）であり得る、または、Ｓ１インタフェースおよびＵｕインタフェース両方等のいくつかのインタフェースを集約的に示すことができる。動作２４−２は、シーケンス番号の取得を含むインタフェース通過パケットの受信時に実行される動作例を示している。暗号解読および解凍を実行し、回復パケットを取得した後に、検証チェックサムは、回復パケットに対して判定される。検証チェックサムと初期チェックサムとの比較は、解凍の検証を判定するために使用される。

対応して配置される図２６のパケットの図と共に図２５のフローチャートの動作によって、送信ノードにおける図２４の第２のモードに関する詳細の実装例が示される。対応して配置される図２８のパケットの図と共に図２７のフローチャートの動作によって、受信ノードにおける図２４の第２のモードの対応する詳細な実装が示される。

第２のモードの実装例のための送信ノードでは、動作２４−１−ａは、初期チェックサムの判定を含んでいる。特に、入力パケットの圧縮候補部ＣＣＰに対して初期チェックサムが判定される。シーケンス番号ＭＳＮが元の非圧縮ＩＰヘッダの一部であるシーケンス番号である場合、シーケンス番号ＭＳＮは、図２６において対応する例示によって示されるチェックサムによってカバーされるべきである。他方、シーケンス番号ＭＳＮが圧縮アルゴリズムによって生成され、かつ元の非圧縮ＩＰヘッダに存在しない場合、その唯一の目的はヘッダを解凍することであり、それゆえ、解凍および暗号解読の両処理の後に検証される情報の一部である必要はない（そして、従って、初期チェックサムによってカバーされる必要はない）。

オプションとして（そして、従って、図２６のチェックサムの形成において破線で示されるように）、いくつかの変形において、また、入力パケットの暗号化候補ペイロード部ＥＣＰＲ、セッションキーの導出用のシーケンス番号を使用する入力パケットの暗号化候補ペイロード部に対して初期チェックサムが判定される。シーケンス番号ＭＳＮに対して計算される限り、およびチェックサム計算ロジックが理解する、またはチェックサム計算ロジックを送信ノードおよび受信ノードの両方において矛盾なく予め構成される限り、全入力パケットより少ないパケットに対して、例えば、全圧縮候補部ＣＣＰより少ない部分に対しておよび／または全暗号化候補ペイロード部ＥＣＰＲより少ない部分に対して、動作２４−１−ａのチェックサムＩＣＫＳＵＭを計算することができることが理解されるであろう。

動作２４−１−ｂは、圧縮ストリングＣＳを提供するために、入力パケットの圧縮候補部ＣＣＰにおける圧縮の実行を含んでいる。動作２４−１−ｂの圧縮は、限定されるものではないが、本明細書において記載または言及されるものを含む任意の適切な圧縮技術であり得る。

動作２４−１−ｃは、暗号ストリングＥＳを提供するために、入力パケットの少なくとも暗号化候補ペイロード部ＥＣＰＲの暗号化を含んでいる。図２６に示す実装例では、暗号化は、暗号化候補ペイロード部ＥＣＰＲだけでなく、実質的には、シーケンス番号ＭＳＮを除く全圧縮候補部ＣＣＰをもカバーしている。この理由のために、シーケンス番号ＭＳＮまたはその圧縮バージョンが、暗号ストリングＥＳの横に個別に図２６で示されている。変形実装では、暗号化は、また、初期チェックサムＩＣＫＳＵＭをカバーすることができることが理解されるべきである。選択的には、別の変形では、暗号化は暗号化候補ペイロード部ＥＣＰＲのみをカバーすることができる（圧縮候補部ＣＣＰまたは初期チェックサムＩＣＫＳＵＭを含まない）。実装または変形の如何に関わらず、動作２４−１−ｃの暗号化は、限定されるものではないが、本明細書において記載または言及されるものを含む、任意の適合する暗号化技術であり得る。

動作２４−１−ｄは、入力パケットに対応するインタフェース通過パケットの形成を含んでいる。動作２４−１−ｄのパケット形成は、インタフェース通過パケットに含む、シーケンス番号を含む少なくとも圧縮ストリングＣＳ、暗号ストリングＥＳおよび初期チェックサムを含んでいる。暗号化が暗号化候補ペイロード部ＥＣＰＲのみをカバーする場合、これら３つの構成要素は個別にインタフェース通過パケットにアセンブルされる。一方、暗号化が暗号化候補ペイロード部ＥＣＰＲより多くをカバーする場合、インタフェース通過パケットの１つまたは複数のその他の構成要素の全てまたは一部が、暗号ストリングＥＳによって包含されても良い。即ち、暗号化がシーケンス番号ＭＳＮを除く圧縮候補部ＣＣＰをカバーする場合、インタフェース通過パケットに暗号ストリングＥＳを含めることは、インタフェース通過パケットに圧縮候補部ＣＣＰの一部を含めることを包含する。同様に、暗号化が初期チェックサムＩＣＫＳＵＭをカバーする場合、インタフェース通過パケットに暗号ストリングＥＳを含めることは、インタフェース通過パケットに初期チェックサムＩＣＫＳＵＭを含めることを包含する。

２．２．２：圧縮コンテキストと暗号コンテキストの合同管理：第２のモード：実装：受信ノード
対応して配置される図２８のパケットの図と共に図２７のフローチャートの動作によって、受信ノードにおける図２４の第２のモードに関する対応する詳細な実装が示される。図２７の動作２４−２−ａは、インタフェース通過パケットからのシーケンス番号ＭＳＮの取得を含んでいる。例えば、暗号化されなかった圧縮ストリングＣＳの一部として、シーケンス番号ＭＳＮを解凍することができる。シーケンス番号ＭＳＮが暗号解読用に使用される場合、シーケンス番号ＭＳＮは暗号化されていないであろうが、圧縮されていることはあり得る。

動作２４−２−ｂは、暗号解読ストリングを提供するために、インタフェース通過パケットの暗号ストリングＥＳの暗号解読を含んでいる。動作２４−２−ｂに対応して、図２８は、暗号解読ストリングを、圧縮ストリングＣＳの一部（例えば、動作２４−１−ｃにおいて暗号化された圧縮ストリングＣＳの一部）およびパケットペイロードを含むように示している。動作２４−２−ｂの暗号解読は、動作２４−１−ｃにおいて利用される対応する暗号化技術の逆技術によって実行される。

動作２４−２−ｃは、解凍ストリングを提供するために、インタフェース通過パケットの圧縮ストリングの一部の解凍を含んでいる。動作２４−２−ｃに対応して、図９−図１０は、解凍ストリングを、シーケンス番号ＭＳＮを含むように示している。動作２４−２−ｃの解凍は、動作２４−１−ｂの圧縮動作に対して使用された圧縮技術の逆技術によって実行される。

動作２４−２−ｄは、動作２４−２−ａにおける初期チェックサムＩＣＫＳＵＭの判定に対応するように、少なくとも解凍ストリングに対しておよびオプションとして暗号解読ストリングに対して検証チェックサムＶＣＫＳＵＭの判定を含んでいる。

動作２４−２−ｅは、動作２４−２−ｃの解凍の検証を判定するために、検証チェックサムと初期チェックサムとの比較の使用を含んでいる。

動作２４−２−ｆは、動作（２−ｆ）の検証に従う圧縮コンテキストの更新を含んでいる。動作２４−２−ｇは、動作２４−２−ｃの検証に従う暗号コンテキストの更新を含んでいる。

２．３：圧縮コンテキストと暗号コンテキストの合同管理：第２のモード：エピローグ
このように、圧縮コンテキストと暗号コンテキストとの合同管理の第２のモードでは、解凍処理の結果の検証用に使用されるチェックサムは、セッションキーの判定（暗号解読処理）の成功を検証する。チェックサムは、マスタシーケンス番号（ＭＳＮ）を含むように圧縮されることになる（元の非圧縮）部分を最小限カバーするが、暗号解読処理がセッションキーの導出用に同一のＭＳＮを使用する場合、チェックサムは暗号化されることになるパケット部の（元の非暗号化）一部を除外しても良い。

送信側、例えば、送信ノードでは、チェックサムＩＣＫＳＵＭが、―ＭＳＮを含むように圧縮されることになる（元の非圧縮）部分を最小限カバーするようにチェックサムＩＣＫＳＵＭが計算されるが、暗号解読処理がセッションキーの導出用に同一のＭＳＮを使用する場合、チェックサムＩＣＫＳＵＭは、暗号化されることになるパケット部の（元の非暗号化）一部を除外しても良い。

受信側、例えば、受信ノードでは、少なくともＭＳＮがまず解凍される、あるいは回復される（動作２４−２−ａ）。次いで、暗号解読および解凍が実行される（圧縮部の少なくともある部分が暗号化される場合、暗号解読はＭＳＮ以外のフィールドの解凍の前にこなければならない）。チェックサムが、次いで、解凍処理の結果のみを検証するために使用される。成功する場合、圧縮パケットフォーマットのコンテキスト更新プロパティに基づき、並びに適用可能である場合、圧縮アルゴリズムによって定義される動作モードに基づき、それぞれ圧縮コンテキストおよび暗号コンテキストが更新される。シーケンス番号ＭＳＮはこのようにして検証され、これが、暗号コンテキストに対する唯一の敏感な情報となる。

２．４：圧縮コンテキストと暗号コンテキストの合同管理：いくつかの利点
圧縮コンテキストと暗号コンテキストとの合同管理は、上述のようにまたはその他の方法により、本明細書により包含するように数多くの利点を有し、そのいくつかを以下に掲げる。第１の利点の例は、オーバヘッドの最小化である。この技術は、共通チェックサムが使用される場合に、ヘッダ圧縮コンテキスト更新のロバスト特性を含めるために、暗号化アルゴリズムのコンテキスト管理機能を拡張する。これは、またいくらかオーバヘッドを減じることができる。

第２の利点の例は、既存の規格およびアーキテクチャへの影響である。この技術は、下位レイヤが自身の誤り検出機能を有することを妨げない。提案されるような組み合わせを使用すると、通常、独立の暗号化レイヤで必要とされる、その誤り検出メカニズムのいくらかを下位レイヤが作成することを許容することができる。これは全体としてのオーバヘッドを削減することができる。換言すれば、これは、レイヤ侵害、あるいはレイヤ横断統合（cross-layer integration）ではない。

第３の利点の例は、暗号コンテキストに対する相互利益およびロバスト性の改善である。暗号化機能は、シーケンス化情報に関するヘッダ圧縮アルゴリズムのロバスト性の特徴から利益を得るので、従って、暗号コンテキストがシーケンス化に関して同期を失う確率を下げる。これが生じると、ヘッダ圧縮アルゴリズムの回復メカニズム内から再同期が生じることになる。

第４の利点の例は、一般のヘッダ圧縮への適用性である。これは、特に、大部分のＲＯＨＣプロファイルに適用可能であり、大部分のＲＯＨＣプロファイルには、―限定されるものではないが、ＲＯＨＣ ＲＴＰ（０ｘ０００１）、ＵＤＰ（０ｘ０００２）、ＩＰ（０ｘ０００４）、ＥＳＰ（０ｘ０００３）、ＴＣＰ（０ｘ０００６）、ＵＤＰ−Ｌｉｔｅ（０ｘ０００８）、ＲＴＰ／ＵＤＰ−Ｌｉｔｅ（０ｘ０００７）ヘッダ圧縮プロファイルが含まれる。ヘッダ圧縮への適用性はまた限定されるものではないが、例えば、ビットマスクを使用して、特定のビットのみを非暗号化／暗号化することを可能にするストリーム暗号法等の暗号化および暗号化アルゴリズムにまた特に関係する。このようなストリーム暗号法の例は、Ａ５、ＧＥＡ、ＵＥＡおよびＡＥＳを含んでいる。関係するその他の暗号化および暗号アルゴリズムは、シーケンス化情報を使用して、暗号化（解除）に必要なパラメータを導出することである。

この技術のその他の非限定的、例示的な特徴および利点はさらに以下を含んでいる。

解凍処理の結果の検証用に使用されるチェックサムは、セッションキーの判定の成功（暗号解読処理）を検証する。成功する場合、暗号コンテキストが更新される。

ロバストな暗号コンテキスト管理は、暗号化されることになるパケット部の（元の非暗号化）一部、並びに圧縮されることになる（元の非圧縮）部分をカバーするチェックサムを使用して達成することができる。チェックサムは、解凍処理に利用可能にし、その結果を暗号化アルゴリズムに利用可能にする。

ロバストな暗号コンテキスト管理は、ＭＳＮを含むように圧縮されることになる（元の非圧縮）部分を最小限カバーするが、暗号解読処理がセッションキーの導出用に同一のマスタシーケンス番号（ＭＳＮ）を使用する場合に暗号化されることになるパケット部の（元の非暗号化）一部を除外することができる、チェックサムを使用して達成することができる。このチェックサムを解凍処理に利用可能にし、その結果を暗号化アルゴリズムに利用可能にする。成功する場合、適用可能である場合、圧縮アルゴリズムのコンテキスト更新および動作モードに基づき暗号コンテキストが更新される。

トランスポートレイヤ（例えば、ＵＤＰ、ＴＣＰ）チェックサムが、さらに処理の結果の検証を提供するために使用されても良い。

ＵＤＰ−Ｌｉｔｅが使用される場合、チェックサムは、ＵＤＰ−Ｌｉｔｅチェックサムと同一の適用範囲を使用する。

チェックサムは、トランスポートレイヤが保護する情報を少なくともチェックサムがカバーすることが提供される、トランスポートレイヤチェックサムに置き換わる。トランスポートレイヤチェックサムがまず検証される。

限定されるものではないが、ＲＯＨＣ ＲＴＰ（０ｘ０００１）、ＵＤＰ（０ｘ０００２）、ＩＰ（０ｘ０００４）、ＥＳＰ（０ｘ０００３）、ＴＣＰ（０ｘ０００６）、ＵＤＰ−Ｌｉｔｅ（０ｘ０００８）、ＲＴＰ／ＵＤＰ−Ｌｉｔｅ（０ｘ０００７）ヘッダ圧縮プロファイルを含むロバストヘッダ圧縮（ＲＯＨＣ）プロファイルに従って、圧縮アルゴリズムを実装する、例えば、特定の場合に、上述の事項を適用することができる。

例えば、ヘッダ圧縮器および／または解凍器が一般の任意のその他のヘッダ圧縮スキームに従って実装される特定の場合に、上述の事項を適用することができる。

例えば、暗号化および暗号化アルゴリズムが、限定されるものではないが、Ａ５、ＧＥＡ、ＵＥＡおよびＡＥＳを含むストリーム暗号法である特定の場合に、上述の事項を適用することができる。シーケンス化情報を使用して、暗号化（解除）に必要なパラメータを導出するためのその他の暗号化および暗号化アルゴリズムもまた範囲内にある。

ＳｉｇＣｏｍｐ等のシグナリング圧縮、ペイロード圧縮アルゴリズム（ペレイラ、Ｒ著「ＤＥＦＬＡＴＥを使用するＩＰペイロード圧縮」、ＩＥＴＦ ＲＦＣ２３９４、１９９８年１２月およびフレンド，ＲおよびＲ．モンスール著「ＬＺＳを使用するＩＰペイロード圧縮」、ＩＥＴＦ ＲＦＣ２３９５、１９９８年１２月において定義されるもの等）またはシーケンス化およびチェックサムを必要とし、この情報をその他のアルゴリズムと共有することができ、同一ノードにおいて発生、終了する、任意のその他の動作等の、例えば、その他の圧縮アルゴリズムに、上述の事項を適用することができる。

例えば、ＳＡＥ／ＬＴＥ作業の一部として、３ＧＰＰ ＲＡＮ２標準化ワーキンググループにおいて現在定義中のａＧＷに、上述の事項を適用することができる。

３．０：セキュアヘッダ圧縮：概要
別の個別の技術の側面に従えば、本明細書に記載されるその他の態様と共に使用することができる（例えば）暗号化、あるいは、暗号化機能は、ヘッダ圧縮プロトコルの一部について実行される。即ち、本明細書に記載される技術は、パケットのペイロードのいくらかまたは全ておよび圧縮ヘッダフォーマット（ヘッダ圧縮チャネルに関係する機能を有するヘッダフィールドを除く）の暗号化を可能にする。

ヘッダ圧縮と暗号化を効率的に組み合わせて、暗号化ヘッダ圧縮フローを作成するために、ヘッダ圧縮アルゴリズム（既存ＲｏＨＣフレームワークと互換のあるロバストヘッダ圧縮プロファイル等）が作成される。ヘッダ圧縮マスタシーケンス番号（ＭＳＮ）の非圧縮（そうでなければ、おそらく圧縮されている）表現を使用して、ペイロードを含む全ヘッダ圧縮パケットについて、並びにできるだけ多くの圧縮ヘッダ自体について、暗号化が実行される。暗号化できないフィールドは、以下をサポートするために必要なフィールドである：
−フロー多重化 （例えば、ＲｏＨＣ ＣＩＤｓ）
−パケットタイプの識別 （例えば、ＲｏＨＣパケットタイプ）
−（おそらく圧縮）ＭＳＮ
−圧縮アルゴリズム用識別子 （例えば、ＲｏＨＣプロファイルオクテット）
−例えば、初期パケットに適用可能な場合（例えば、ＲｏＨＣ ＩＲパケット）
非限定的な実施形態の例は、ヘッダ圧縮および暗号化の両方が実行される（ＳＡＥ／ＬＴＥ用の３ＧＰＰ ＲＡＮ２に定義されるａＧＷにおける等）、２つの対応するノード（隣接するまたはしない）を含んでいる。この実施形態は、暗号化されないであろう「セキュア圧縮ヘッダフォーマット」の部分、および暗号化されるであろう部分、並びに送信および受信側において使用されるロジックを定義する。

暗号化は同一ノードにおけるヘッダ圧縮と共に実行されるので、個別シーケンス化オーバヘッドを削減し、かつパケット損失および再順序化に対するロバスト性等の特性を継承する場合の暗号解読のためのキー導出メカニズムのロバスト性を改善する。

既存のＲＦＣ３０９５の拡張を定義しなければならない場合に、ＲｏＨＣフレームワーク内で、新しいプロファイル、並びに暗号コンテキストの構成のため、再順序化のため、等のための追加チャネル交渉済パラメータに、この技術は適用することができる。新しいプロファイル専用パケットフォーマットが必要とされるが、ＲｏＨＣの未使用パケットタイプの空間内およびＩＲパケットタイプ内の空間を利用することができる。従って、提案される解決策は、カールステン ボーマン他著「ロバストヘッダ圧縮（ＲＯＨＣ）：フレームワークおよび４つのプロファイル：ＲＴＰ、ＵＤＰ、ＥＳＰおよび非圧縮」、ＩＥＴＦ ＲＦＣ３０９５、２００１年４月およびペレチエ，Ｇ．、サンドランド，Ｋ．およびＬ．ジョンソン著「ロバストヘッダ圧縮（ＲＯＨＣ）フレームワーク」、インターネットドラフト（作業中）、＜draft-ietf-rohc-rfc3095bis-framework-00.txt.＞、２００５年１２月において定義されるように，ＲｏＨＣ内において両立できるようにすることができ、そうすることで、暗号化ＲｏＨＣフローは、非暗号化フローと同一チャネルを共有することができる。

交渉、デフォルト値、例えば、コンテキスト初期化中の帯域内シグナリング、または静的に提供される値のいずれかによって、暗号化に関係するチャネルパラメータの確立が予め必要である。これらのパラメータは、通常、暗号コンテキスト内に存在する事項を含んでいる：（１）使用する暗号変換（例えば、ｆ８モードのＡＥＳ，ＨＭＡＬＣ−ＳＨＡＩ）および（２）マスタキー。

非暗号化のままでいなければならない以下のフィールド（例えば、ヘッダ圧縮チャネル情報を有するヘッダフィールド）を除く、ペイロードが後続する圧縮ヘッダを構成するフィールドに、暗号化（例えば、文字暗号化（ciphering））が適用される：
・ヘッダ圧縮チャネルを経るフロー用の多重化識別子（ＣＩＤ）
・圧縮ヘッダフォーマットタイプの識別（パケットタイプ識別子）
・マスタシーケンス番号（ＭＳＮを使用して、暗号化セッションキーが導出される場合）：ＭＳＮを圧縮することができる。

・圧縮アルゴリズム識別子、多重化識別子がセキュアヘッダ圧縮フローと未だ関連していない場合（初期圧縮ヘッダ用の圧縮プロファイル識別子）。

従って、本明細書では、例えば、送信ノードおよび受信ノードを含む通信ネットワークの運用方法が記載される。この方法は、送信ノードにおける入力パケットに対するヘッダ圧縮チャネル情報を有するヘッダフィールドを除き、インタフェース通過パケットにおける暗号化圧縮ヘッダを含む圧縮パケットヘッダの暗号化を含んでいる。この方法は、さらに、受信ノードにおいて受信されるインタフェース通過パケットに対するヘッダ圧縮チャネル情報を有するヘッダフィールドからの情報の取得、およびインタフェース通過パケットの圧縮ヘッダの暗号解読を含んでいる。

３．１：セキュアヘッダ圧縮：圧縮器ロジック
図２９は、圧縮ヘッダ（群）を暗号化するパケットを準備するモード例において実行することができる非限定的動作またはイベント例を示すフローチャートである。異なるプロトコルレイヤがそれぞれそのヘッダを加えることで、複数のプロトコルの複数のヘッダを備える複合ヘッダを形成することができるので、パケットは実際は２つ以上のヘッダを有することができることが理解されるであろう。図２９の動作の種々のものに対応して、図３０は、パケットが圧縮動作および暗号化動作に発展する際のパケットコンテンツの図を示している。

図３０は非圧縮ヘッダ（群）（uncompressed header：ＵＨ）を示している。非圧縮ヘッダ（群）ＵＨは、以下に掲げる暗号化不可能フィールド（unencryptable fields：ＵＦ）を含んでいる：多重化識別子（multiplexing identifier：ＭＵＸ ＩＤ）；圧縮ヘッダフォーマットタイプ識別情報（format type identification：ＦＭＴ ＩＤ）；マスタシーケンス番号（ＭＳＮ）；および圧縮アルゴリズム識別子（compression algorithm identifier：ＣＡＩ）。これら４つのフィールドは、本明細書では纏めて「暗号化不可能フィールド」あるいは「ＵＦ」として知られている。

動作２９−１は、使用する圧縮コンテキストの判定を含んでいる。同様に、動作２９−２は、使用する暗号コンテキストの判定を含んでいる。動作２９−１および動作２９−２のコンテキストの判定は、進行中のトランザクションに基づいている。動作２９−１および動作２９−２の判定は、纏めて行うことができる。

動作２９−３は、ヘッダ圧縮されるプロトコルに基づく、またはローカルに保持される値からの、マスタシーケンス番号（ＭＳＮ）の値の判定を含んでいる。

動作２９−４は、パケットヘッダの圧縮を含んでいる。図３０は、圧縮ヘッダＣＨの生成を示している。動作２９−４の圧縮は、本明細書に記載されるまたは言及されるもの等の任意の適切な圧縮技術によるものであり得る。

動作２９−５は、暗号化セッションキーを生成するパケットのインデックスの判定を含んでいる。

動作２９−６は、例えば、パケットの圧縮ヘッダおよび暗号化可能部（例えば、パケットペイロードおよび任意の残存ヘッダ圧縮チャネル情報、例えば、フィードバック、セグメンテーション、チェックサム（群）、等）を使用するパケットの形成を含んでいる。動作２９−６のパケット化から除外するのは、以下に掲げる暗号化不可能フィールド（ＵＦ）である：多重化識別子（ＭＵＸ ＩＤ）；圧縮ヘッダフォーマットタイプの識別情報（ＦＭＴ ＩＤ）；マスタシーケンス番号（ＭＳＮ）；および圧縮アルゴリズム識別子（ＣＡＩ）である。

動作２９−７は、動作２９−６において形成されるパケットの暗号化、例えば、利用される特定の暗号化アルゴリズムに従う、パケットの圧縮ヘッダＣＨおよびペイロードにおける暗号化の実行を含んでいる。図３０は、暗号化の結果として、パケットの暗号化部分ＥＰを示している。暗号化アルゴリズムは、例えば、バウアー Ｍ．他著「セキュアリアルタイムトランスポートプロトコル（ＳＲＴＰ）」、ＩＥＴＦ ＲＦＣ３７１１、２００４年３月によるような暗号化に（例えば）類似し得る。動作２９−７の暗号化から除外するものは、上述の暗号不可能フィールド（ＵＦ）である。

適用可能である場合、動作２９−８は、暗号コンテキストにおいて必要なパラメータの更新を含んでいる。

動作２９−９は、動作２９−６に掲げる暗号化不可能フィールド（ＵＦ）の追加によるパケットの暗号化部分のパケット化を含んでいる。これら暗号化不可能フィールド（ＵＦ）は、暗号化することなく残さねばならないが、所望である場合、圧縮することはできる。従って、図３０は、本質的に下位レイヤへの配信準備が整っている最終パケットＰあるいはデータグラムの形成を示している。実際、動作２９−１０は、下位レイヤ（例えば、セグメンテーションと、および、例えば、送信用のスケジューラであり得る、正しいロジックチャネルおよび／または送信キューへのマッピングと、に使用されるメディアアクセス制御（medium access control：ＭＡＣ）レイヤ）への得られるデータグラムＰの配信を含んでいる。

図２９の動作順序の変更は可能である。例えば、動作２９−１と動作２９−２との間の順序を逆にすることができる。また、動作２９−３、動作２９−４と動作２９−６との間の順序を逆にすることができる。さらに、一方の動作２９−８と他方の動作２９−８および動作２９−１０との間の順序を逆にすることができる。

３．１：セキュアヘッダ圧縮：解凍器ロジック
図３１は、自身の圧縮ヘッダ（群）の暗号化を受けている受信パケットを処理するモード例において実行することができる非限定動作またはイベント例（例えば、受信ノードにおいて実行される動作）を示すフローチャートである。図３２は、図３１の動作の種々のものに対応して、パケットが暗号解読および解凍動作に発展する際のパケットコンテンツの図を示している。

動作３１−１は、データグラムＰのデパケット化を含み、このデータグラムＰは、暗号化不可能フィールド（ＵＦ）、例えば、多重化識別子（ＭＵＸ ＩＤ）、圧縮ヘッダフォーマットタイプの識別情報（ＦＭＴ ＩＤ）、マスタシーケンス番号（ＭＳＮ）および圧縮アルゴリズム識別子（ＣＡＩ）を含むヘッダ圧縮チャネル情報を処理することにより下位レイヤから受信される。

動作３１−２は、使用する圧縮コンテキストの判定を含んでいる。一旦、圧縮コンテキストが判定されると、動作３１−３は。ＭＳＮの解凍を含んでいる。

動作３１−４は、使用する暗号コンテキストの判定を含んでいる。暗号コンテキストの判定は、注目するヘッダ圧縮コンテキストに関する動作３１−２の判定と連結することができる。

動作３１−５は、パケットインデックスの判定およびセッションキーの導出を含んでいる。セッションキーの導出は、上述の通りであり、また、暗号アルゴリズムに依存し得る。暗号アルゴリズムは、入力としての暗号によってパケット処理順序を反映する正しいシーケンス化を取得する。

動作３１−６は、使用する特定の暗号化アルゴリズムによる暗号化パケット部の暗号解読（例えば、暗号解読）を含む。上述のように、暗号化アルゴリズムは、例えば、バウアー Ｍ．他著「セキュアリアルタイムトランスポートプロトコル（ＳＲＴＰ）」、ＩＥＴＦ ＲＦＣ３７１１、２００４年３月によるような暗号解読に類似し得る。

動作３１−７は、例えば、残りのヘッダ圧縮チャネル情報、例えば、フィードバック、セグメンテーション、チェックサム等を処理することによって得られる暗号解読データグラムのデパケット化を含んでいる。

動作３１−８は、暗号解読パケットの全圧縮ヘッダ部の解凍、非圧縮ヘッダＵＨの生成を含んでいる。適用可能である場合、動作３１−９は、暗号コンテキストにおける所要パラメータの更新を含んでいる。動作３１−１０は、暗号解読し、かつ解凍したデータグラムの上位レイヤ（例えば、ネットワークレイヤ、例えば、ＩＰプロトコルスタック（例えば、ＯＳＩモデルのレイヤ３に同等））への配信を含んでいる。

図３１の動作順序の変更は可能である。例えば、動作３１−３と動作３１−４との間の順序を逆にすることができる。

図３３は、ＲｏＨＣに基づく実施形態を示している。本明細書に記載される技術は、「セキュアプロファイル」が同一ＲｏＨＣチャネルにおける他のＲｏＨＣプロファイルと共存することを可能にする。これは、ヘッダ圧縮フロー単位に機能のオン／オフが可能であることを意味する。しかしながら、ＲｏＨＣチャンネル交渉に含む新しいチャネルパラメータが指定される必要があり得る。

３．３：セキュアヘッダ圧縮：いくつかの利点
セキュアヘッダ圧縮技術は、上述のように、または他の方法によって、本明細書に包含するように数多くの利点を有し、そのいくつかを以下に掲げる。第１の利点の例は、オーバヘッドの最小化である：提案されるような組み合わせを使用すると、また、独立の暗号化レイヤの前に下位レイヤがそれ自体のシーケンス化を導入する必要性は排除する。これは、下位レイヤのオーバヘッドを削減する。

第２の利点の例は、既存の規格およびアーキテクチャへの影響である。加えて、本明細書で示唆されるように、ヘッダ圧縮機能の拡張は、下位レイヤが自身の暗号化機能および再順序化機能を有することを妨げない。提案されるような組み合わせを使用すると、独立の暗号化レイヤの前に、下位レイヤがそのシーケンス化および順序配信メカニズムを作成することを許容することができる。これは全体としてのオーバヘッドを削減することができる。換言すれば、これは、レイヤ侵害、あるいはレイヤ横断統合ではない。一方で、新しい圧縮アルゴリズム（例えば、ＲｏＨＣプロファイル）を定義し、規格化する必要はない。

第３の利点の例は、一般のヘッダ圧縮への適用性である。これは、特に、大部分のＲＯＨＣプロファイルに適用可能であり、この大部分のＲＯＨＣプロファイルには、―限定されるものではないが、ＲＯＨＣＲＴＰ（０ｘ０００１）、ＵＤＰ（０ｘ０００２）、ＩＰ（０ｘ０００４）、ＥＳＰ（０ｘ０００３）、ＴＣＰ（０ｘ０００６）、ＵＤＰ−Ｌｉｔｅ（０ｘ０００８）、ＲＴＰ／ＵＤＰ−Ｌｉｔｅ（０ｘ０００７）ヘッダ圧縮プロファイルを含んでいる。ヘッダ圧縮への適用性は、また、限定されるものではないが、例えば、ビットマスクを使用して、特定のビットのみを非暗号化／暗号化することを可能にするストリーム暗号法等の暗号化および暗号化アルゴリズムに特に関係する。このようなストリーム暗号法の例は、Ａ５、ＧＥＡ、ＵＥＡおよびＡＥＳを含む。関係するその他の暗号化および暗号アルゴリズムは、シーケンス化情報を使用して暗号化（解除）に必要なパラメータを導出するものである。

４．０：シーケンス番号の共有：概要
側面の１つでは、技術の共有トランザクションは、共有情報、例えば、シーケンス番号の共有である。換言すれば、この技術の側面では、１つの機能レイヤは、別の機能レイヤからのシーケンス化情報を使用する。基本的には、暗号化および／またはヘッダ圧縮および／またはペイロード圧縮および／またはシグナリング圧縮のいずれかによって使用されるシーケンス化情報が、別の処理、暗号化および／またはヘッダ圧縮および／またはペイロード圧縮および／またはシグナリング圧縮のいずれか他の処理から導出する。

ヘッダ圧縮は、通常、マスタシーケンス番号（ＭＳＮ）と時には呼ばれるいくつかの形式のシーケンス番号を使用し、シーケンス番号に関するその変更パターンに基づく機能の確立によって、他のフィールドが、通常、シーケンス番号に基づいて圧縮される。このシーケンス番号は、圧縮されるプロトコルフィールド（群）から導出される、または圧縮器によって局所的に生成され得る。

暗号化（例えば、暗号化）は、通常、ある形式のシーケンス情報を使用し、そのシーケンス情報に基づき、暗号コンテキストと共にセッションキーが導出される。

シーケンス番号共有の第１のモードでは、ヘッダ圧縮器は、まず、パケットのヘッダを圧縮し、そのシーケンス番号を暗号化処理に渡す。暗号化処理は、このシーケンス番号を使用して、セッションキーを導出し、パケットの暗号化を処理する。

シーケンス番号共有の第２のモードでは、暗号化（暗号化）機能は、次に（その暗号化動作において）使用することになるシーケンス番号をヘッダ圧縮器に利用可能にすることができる。ヘッダ圧縮器は、そのＭＳＮとしてこのシーケンス番号を使用して、パケットを圧縮し、圧縮パケットを暗号化処理に渡す。暗号化処理は、次いで、この同一シーケンス番号を使用して、セッションキーを導出し、暗号化の処理を行う。適用可能である場合、シーケンス化情報は、暗号化プロトコル内において搬送される。

換言すれば、第２のモードでは、シーケンス化（例えば、シーケンス番号）は、暗号化機能によって作成され、ヘッダ圧縮機能に利用可能にする。圧縮（解除）する場合に、圧縮（解除）機能は、そのマスタシーケンス番号（ＭＳＮ）としてこのシーケンス化を使用する。

典型的には、暗号化および圧縮は、個別処理としいて見なされる。従来、暗号化は、ＩＰエンドホスト間（圧縮不可能なヘッダの大部分を残して）、アプリケーション間（検出不可能であるので、中間システムは、自身の暗号化をオン／オフすることができない）、または物理メディアを介する送信機と受信機との間（順序化を保証できない限り、隣接ノードにローカル化される）のいずれかで実行する。

本明細書に記述するシーケンス番号共有のいずれのモードにおいても、暗号化適合レイヤは、ヘッダ圧縮であると見ることができる。図３４は、従来の暗号化と圧縮の分離（図３４中の左側に示される）を、本明細書で記載される（図３４の右側に示される）シーケンス番号共有、および結合されたあるいはマージされた圧縮と暗号化処理と対比する。基本的には、ペイロードの暗号化は、ヘッダ圧縮と共に実行される。究極的に、圧縮機能または暗号化機能から取得されるヘッダ圧縮マスタシーケンス番号（ＭＳＮ）は、暗号コンテキストからセッションキーを導出する。暗号化機能は、シーケンス番号ＭＳＮを使用して、暗黙的に暗号コンテキストからセッションキーを導出するために使用される。ヘッダ圧縮シーケンス化を使用して、ペイロードに対応するパケット部に暗号化が適用される。図３４のＲｏＨＣ圧縮によって示されるように、同一シーケンス番号ＭＳＮは、ヘッダ（群）圧縮のための圧縮処理によって使用される。

シーケンス番号共有の態様では、暗号化は、効率的に圧縮と結合され、この暗号化は、ＳＲＴＰにおけるセッションキーの導出用に、圧縮に対して使用されるマスタシーケンス番号（ＭＳＮ）を使用して、圧縮されるパケットペイロードにおいて実行される。この暗号化は、それ自体の同期要件に関して損失および再順序化に関するＭＳＮに対して使用される符号化のロバスト性特性の利益を得る。

装置の例は、圧縮および暗号化が実行される（ＳＡＥ／ＬＴＥ用の３ＧＰＰ ＲＡＮ２において定義されるアクセスゲートウェイ等）、２つの対応するノード（隣接するまたはしない）を備えている。暗号変換およびキー導出アルゴリズム（バウアー Ｍ．他著「セキュアリアルタイムトランスポートプロトコル（ＳＲＴＰ）」、ＩＥＴＦ ＲＦＣ３７１１、２００４年３月に記載されるもの等）は、圧縮アルゴリズム（例えば、ＲｏＨＣ）からのマスタシーケンス番号（ＭＳＮ）を使用して、ペイロードを暗号化および暗号解読する。そうすることは、暗号セッションキー導出アルゴリズムのロバスト性がさらに損失パケットおよび圧縮／暗号化エンドポイント間の再順序化に対するＭＳＮのロバスト性性を継承することを意味する。

従って、暗号化は、同一ノードにおいてヘッダ圧縮と共に、特に、ＲｏＨＣにより実行することができ、これにより、個別シーケンス化を有することのオーバヘッドを削減し、暗号解読用のキー導出メカニズムのロバスト性を改善する。

追加の外部交渉メカニズムは、暗号化処理の構成のために存在することができ、ＲＦＣ３０９５で既に定義されるプロファイル並びにその他の派生プロファイル（ＥＳＰ拡張ヘッダが存在しないことが提供される）を修正することなく使用することができる。再順序化の場合に可能な改善は、最小パケットフォーマットのいくつかを不能にすることである。

４．１：シーケンス番号共有：実装例
図３５は、例えば、非限定的実装であって、結合されているまたは融合されている圧縮および暗号化処理を有し、シーケンス番号が圧縮および暗号化処理によって共有されている送信ノードおよび受信ノードの両方に関して実行される基本的、かつ代表的な動作またはイベントを示している。図３５に示される一連の動作は、シーケンス番号共有の第１のモード（シーケンス番号ＭＳＮが圧縮処理によって選定されるまたは選択される）、またはシーケンス番号共有の第２のモード（シーケンス番号ＭＳＮが暗号化処理によって選定されるまたは選択される）のいずれにも適用可能である。図３６および図３７は、それぞれ送信ノードおよび受信ノードの動作をフローチャートの形式で示している。

図３６は、従って、送信ノードの圧縮器ロジックによって実行される基本的動作または処理されるイベントを記載している。動作３６−１（図３６参照）は、使用する圧縮コンテキストの判定を含んでいる。動作３６−２は、使用する暗号コンテキストの判定を含んでいる。以前の態様において指示されるように、圧縮コンテキストの判定および暗号コンテキストの判定は連結することができる。

動作３６−３は、ＭＳＮの値の判定を含んでいる。この態様の第１のモードでは、シーケンス番号ＭＳＮは、圧縮処理によって保持されるまたは生成される（例えば、ヘッダ圧縮されているプロトコルに基づいて、またはローカルに保持される値から）。第２のモードでは、暗号化動作におけるシーケンス化に使用することになる次の番号として暗号化処理からシーケンス番号ＭＳＮが取得される。

動作３６−４は、パケットヘッダの実際の圧縮を含んでいる。上述で示されるように、パケットは、ＲＴＰヘッダ、ＵＤＰヘッダおよびＩＰヘッダ等の複数のヘッダ（群）を有することができ、その全てが、図３８に示されるようなパケットヘッダ（群）を構成することができる。

動作３６−５は、（パケットヘッダを圧縮するために使用された）ＭＳＮの非圧縮表現を使用し、かつ、例えば、巡回カウンタ（rollover counter）と共にキー導出アルゴリズムを使用するパケットインデックス、暗号コンテキストにおける最大ＭＳＮ、およびパケットヘッダを圧縮するために使用されるＭＳＮの非圧縮表現の判定を含んでいる。

動作３６−６は、偶然使用される、特に、暗号化アルゴリズムに従うパケットのペイロードの暗号化を含んでいる。これは、パケットの暗号化部分である。このアルゴリズムは、バウアー Ｍ．他著「セキュアリアルタイムトランスポートプロトコル（ＳＲＴＰ）」、ＩＥＴＦ ＲＦＣ３７１１、２００４年３月によるような、例えば、暗号化に類似し得る。

適用可能である場合、動作３６−７は、暗号コンテキストにおける必要なパラメータの更新を含んでいる。

動作３６−８は、残存ヘッダ圧縮チャネル情報、例えば、フィードバック、セグメンテーション、コンテキストの識別、チェックサム（群）、等によるパケットの圧縮ヘッダおよびパケットの暗号化部分のパケット化を含んでいる。

動作３６−９は、下位レイヤ（例えば、メディアアクセス制御（ＭＡＣ）レイヤまたはＲＬＣレイヤ）への得られるデータグラムの配信を含んでいる。

図３１の動作順序の変更は可能である。例えば、動作３６−１と動作３６−２との間の順序を逆にすることができる。また、一方の動作３６−４と他方の動作３６−５、動作３６−６および動作３６−７との間の順序を逆にすることができる。

図３７は、受信ノードの解凍器ロジックによって実行される基本的動作、または処理されるイベントを記載していする。動作３７−１（図３７参照）は、ヘッダ圧縮チャネル情報、例えば、フィードバック、セグメンテーション、コンテキストの識別、チェックサム、等の処理によって、下位レイヤから受信されるデータグラムのデパケット化を含んでいる。

動作３７−２は、使用する圧縮コンテキストの判定を含んでいる。動作３７−３は、使用する暗号コンテキストの判定を含んでいる（再度、ヘッダ圧縮コンテキストの判定と暗号コンテキストの判定を連結することができる）。

動作３７−４は、シーケンス番号ＭＳＮの解凍を含んでいる。動作３７−５は、全圧縮ヘッダ部の解凍を含んでいる。

動作３７−６は、パケットヘッダを解凍するために使用されるＭＳＮの非圧縮表現を使用し、かつ、例えば、巡回カウンタと共にキー導出アルゴリズムを使用するパケットインデックス、暗号コンテキストにおける最大ＭＳＮ、およびパケットヘッダを解凍するために使用されるＭＳＮの非圧縮表現の判定を含んでいる。

動作３７−７は、暗号化アルゴリズムによるようなパケット暗号化部の暗号解読（暗号解読）を含んでいる。上述のように、暗号化／暗号解読は、例えば、バウアー Ｍ．他著「セキュアリアルタイムトランスポートプロトコル（ＳＲＴＰ）」、ＩＥＴＦ ＲＦＣ３７１１、２００４年３月によるような暗号解読に類似し得る。

適用可能である場合、動作３７−８は、暗号コンテキストにおいて必要なパラメータの更新を含んでいる。動作３７−９は、データグラムの上位レイヤへの配信を含んでいる。

図３２の動作順序の変更は可能である。例えば、動作３７−２と動作３７−３との間の順序を逆にすることができる。また、一方の動作３７−５と他方の動作３７−５、動作３７−６および動作３７−７との間の順序を逆にすることができる。

４．３：シーケンス番号の共有：いくつかの利点
本明細書に記載されるシーケンス番号共有技術、方法、実施形態およびシステムは、限定されるものではないが、（１）オーバヘッドの最小化、（２）既存の規格およびアーキテクチャへの影響の少なさ、（３）相互利益および暗号コンテキストのロバスト性の改善、および（４）一般のヘッダ圧縮への適用性を含む数多くの長所を有する。

第１の利点の例は、オーバヘッドの最小化である。ロバストヘッダ圧縮によって提供される機能を拡張するために、また、暗号化機能へシーケンス化情報のプロビジョンを包含するために、シーケンス番号共有技術を適用することができる。これは、ペイロード拡張の寄与とならない暗号変換を使用して結合される場合に、特に、有用であり得る。

第２の利点の例は、既存の規格およびアーキテクチャへの影響の少なさである。このソリューションは、また、現状のアーキテクチャおよび目的のシステムへの影響が非常に少なく、特に、ヘッダ圧縮実施形態内における暗号化適合レイヤは、既存のヘッダ圧縮アルゴリズムまたはその仕様への修正を何ら必要としない。唯一必要なことは、暗号化（およびそのパラメータ）の使用のその交渉（おそらく帯域外）が、圧縮ＭＳＮに基づく暗号化のアクティベートに先立ち実行されることである。加えて、本明細書で記載されるようにヘッダ圧縮の機能を拡張すると、下位レイヤが自身の暗号化機能および再順序化機能を有することを疎外しない。提案される組み合わせを使用すると、独立の暗号化レイヤの前に、下位レイヤがそのシーケンス化および順序配信メカニズムを作成することを可能にする。これは全体としてのオーバヘッドを削減する。換言すれば、これはレイヤ侵害、あるいはレイヤ横断統合ではない。

第３の利点の例は、相互利益および暗号コンテキストのロバスト性の改善である。暗号化機能は、シーケンス化情報に関するヘッダ圧縮アルゴリズムのロバスト性の特徴から利益を得るので、従って、暗号コンテキストがシーケンス化に関して同期を失う確率を下げる。同期損失が生じることがあると、ヘッダ圧縮アルゴリズムの回復メカニズム内から再同期化が発生することになる。暗号化機能は、パケットの非圧縮部のみを処理するので、暗号化機能は、ヘッダ圧縮アルゴリズムに対するコンテキスト損傷の一因になりえない。この点に関して、暗号化機能およびヘッダ圧縮機能は、互に負の影響を与えることはありえず、一方、ヘッダ圧縮は、暗号化アルゴリズムのためにシーケンス化のロバスト性に配慮し、オーバヘッドを減じる。

第４の利点の例は、一般のヘッダ圧縮への適用性である。例えば、このような適用性は大部分のＲＯＨＣプロファイルに顕著であり、大部分のＲＯＨＣプロファイルには、限定されるものではないが、ＲＯＨＣ ＲＴＰ（０ｘ０００１）、ＵＤＰ（０ｘ０００２）、ＩＰ（０ｘ０００４）、ＥＳＰ（０ｘ０００３）、ＴＣＰ（０ｘ０００６）、ＵＤＰ−Ｌｉｔｅ（０ｘ０００８）、ＲＴＰ／ＵＤＰ−Ｌｉｔｅ（０ｘ０００７）ヘッダ圧縮プロファイルを含んでいる。ヘッダ圧縮への適用性は、また、限定されるものではないが、例えば、ビットマスクを使用して特定のビットのみを非暗号化／暗号化することを可能にするストリーム暗号法等の暗号化および暗号化アルゴリズムにまた特に関係する。このようなストリーム暗号法の例は、Ａ５、ＧＥＡ、ＵＥＡおよびＡＥＳを含んでいる。関係するその他の暗号化および暗号アルゴリズムは、シーケンス化情報を使用して暗号化（解除）に必要なパラメータを導出するものである。

シーケンス番号共有技術に従えば、暗号化は、圧縮アルゴリズムと結合してパケットデータに適用される。暗号化は、セッションキー導出インデックスを使用する暗号化用の追加ストリーム暗号法に、例えば、基づく暗号変換を使用する。使用されるインデックスは、圧縮プロトコルのマスタシーケンス番号（ＭＳＮ）である。

暗号化および／またはヘッダ圧縮および／またはペイロード圧縮および／またはシグナリング圧縮のいずれかによって使用されるシーケンス化情報は、別の処理、暗号化および／またはヘッダ圧縮および／またはペイロード圧縮および／またはシグナリング圧縮のいずれか他の処理から導出される。

暗号化および／またはヘッダ圧縮および／またはペイロード圧縮および／またはシグナリング圧縮のいずれかは、暗号化および／またはヘッダ圧縮および／またはペイロード圧縮および／またはシグナリング圧縮のいずれかである別の機能処理からのシーケンス化情報を使用する。

特に、暗号化および／またはペイロード圧縮および／またはシグナリング圧縮のいずれかがシーケンス化情報を使用する場合、シーケンス化情報はヘッダ圧縮機能からくる。

シーケンス化は、暗号化処理によって作成され、ヘッダ圧縮アルゴリズムに対し利用可能になる。圧縮は、圧縮する場合、これをそのマスタシーケンス番号（ＭＳＮ）として使用する。

限定されるものではないが、ＲＯＨＣ ＲＴＰ（０ｘ０００１）、ＵＤＰ（０ｘ０００２）、ＩＰ（０ｘ０００４）、ＥＳＰ（０ｘ０００３）、ＴＣＰ（０ｘ０００６）、ＵＤＰ−Ｌｉｔｅ（０ｘ０００８）、ＲＴＰ／ＵＤＰ−Ｌｉｔｅ（０ｘ０００７）ヘッダ圧縮プロファイルを含むロバストヘッダ圧縮（ＲＯＨＣ）プロファイルに従って、圧縮アルゴリズムが実装される、例えば、特定の場合に、上述の事項を適用することができる。

ヘッダ圧縮および／または解凍を一般の任意のその他のヘッダ圧縮スキームに従って実装される、例えば、特定の場合に、上述の事項を適用することができる。

暗号化および暗号化アルゴリズムが、限定されるものではないが、Ａ５、ＧＥＡ、ＵＥＡおよびＡＥＳを含むストリーム暗号法である、例えば、特定の場合に、上述の事項を適用することができる。シーケンス化情報を使用して、暗号化（解除）に必要なパラメータを導出するその他の暗号化および暗号化アルゴリズムもまた範囲内にある。

ＳｉｇＣｏｍｐ、ペイロード圧縮アルゴリズム（ペレイラ、Ｒ著「ＤＥＦＬＡＴＥを使用するＩＰペイロード圧縮」、ＩＥＴＦ ＲＦＣ２３９４、１９９８年１２月およびフレンド、ＲおよびＲ．モンスール著「ＬＺＳを使用するＩＰペイロード圧縮」、ＩＥＴＦ ＲＦＣ２３９５、１９９８年１２月において定義されるもの等）等のシグナリング圧縮またはシーケンス化およびチェックサムを必要とし、この情報をその他のアルゴリズムと共有することができ、同一ノードにおいて発生、終了する、任意のその他の動作等の、例えば、その他の圧縮アルゴリズムに、上述の事項を適用することができる。

ＳＡＥ／ＬＴＥ作業の一部として、３ＧＰＰ ＲＡＮ２標準化ワーキンググループにおいて現在定義中の、例えば、ａＧＷに、上述の事項を適用することができる。

本明細書に記載される技術、方法、実施形態およびシステムは、限定されるものではないが、（１）オーバヘッドの最小化、（２）既存の規格およびアーキテクチャへの影響の少なさ、（３）相互利益および暗号コンテキストのロバスト性の改善、および（４）一般のヘッダ圧縮への適用性を含む数多くの長所を有する。

以上の記載は、多くの特定事項を含むが、これらは本発明の範囲を制限すると解釈されるべきでなく、現時点で好ましい実施形態のいくつかの例示を単に提供するものと解釈されるきである。本発明の範囲は、当業者に明らかになるであろうその他の実施形態を完全に包含し、その範囲は従って制限されるものではないことが理解されるであろう。通常の当業者に既知の上記の好ましい実施形態の要素に全ての構成上、化学的および機能的等価物は、本明細書に明確に組み込まれ、本明細書に包含されることが意図される。また、デバイスまたは方法に対して、本発明によって解決されるべき問題に取り組むことが必要がないのは、それによってその問題が包含されるからである。

ＳＲＴＰキーの導出例を示す概略図である。 セキュアリアルタイムトランスポートプロトコル（ＳＲＴＰ）を示す概要図である。 ３ＧＰＰ ＴＲ２５．８１３において定義される具体的なアーキテクチャ例の使用に含まれる特定の問題を示す概要図である。 ＵＴＲＡＮアーキテクチャを使用して例示され、かつレイヤ化オーバヘッドを示す従来の無線アクセスネットワーク（ＲＡＮ）構成例の概要図である。 システムアーキテクチャ進化／長期的進化（ＳＡＥ／ＬＴＥ）構成に関する機能分離を示す概要図である。 ＰＤＣＰ機能およびＳＡＥ／ＬＴＥアーキテクチャに関するサードパーティの提案例を示す概要図である。 チェックサム、暗号化および圧縮を伴うレイヤ化手法を示す概要図である。 通信ネットワークにおいて問題とするレイヤ化オーバヘッドを示す概要図である。 ノードの第１の機能および第２の機能においてパケットオーバヘッドの削減のために汎用共有トランザクションおよび／または共有サービスを使用する通信ネットワークの概要図である。 同一モデルレイヤであるが、単一送信ノードを含む複数のノードに分散されている第１の機能および第２の機能においてパケットオーバヘッドの削減のために汎用共有トランザクションおよび／または共有サービスを使用する通信ネットワークの概要図である。 リンクレイヤプロトコルが提供され、かつ第１の機能、第２の機能および共有トランザクションを実行するように構成されている通信ネットワークの概要図である。 共有トランザクションおよび／または共有サービスが、ノードの複数の機能によって使用される共有情報を含む通信ネットワークの概要図である。 共有トランザクションおよび／または共有サービスが、圧縮機能によって発生されるシーケンス番号を含む通信ネットワークの概要図である。 共有トランザクションおよび／または共有サービスが、暗号化機能によって発生されるシーケンス番号を含む通信ネットワークの概要図である。 共有トランザクションおよび／または共有サービスが、パケットの第２の部分において動作するのみならず、少なくとも一部の第１の機能による動作対象となるパケットの第１の部分においても動作する第２の機能を含む通信ネットワークの概要図である。 共有トランザクションおよび／または共有サービスが、少なくとも一部の圧縮対象となるパケットの部分において動作する暗号化機能を含む通信ネットワークの概要図である。 共有トランザクションおよび／または共有サービスが、共有チェックサムの判定を含む通信ネットワークの概要図である。 共有トランザクションおよび／または共有サービスが、パケットのヘッダの少なくとも一部に対する、およびパケットのペイロードの少なくとも一部に対する、チェックサムの判定を含む通信ネットワークの概要図である。 共有トランザクションおよび／または共有サービスが、パケットの第２の部分に関する動作において第２の機能によって利用されるパラメータを含むパケットの第１の部分の少なくとも一部（例えば、パケットヘッダ）に対するチェックサムの判定を含む通信ネットワークの概要図である。 圧縮コンテキストと暗号コンテキストとの合同管理の第１のモード例に含まれる、基本的、代表的な動作またはイベント例を示すフローチャートである。 図１９の第１のモードの実装例における送信ノードにおいて実行される動作例を示すフローチャートである。 図２０の動作に対応するパケットの図を示す概要図である。 図１９の第１のモードの実装例における受信ノードにおいて実行される動作例を示すフローチャートである。 図２２の動作に対応するパケットの図を示す概要図である。 圧縮コンテキストと暗号コンテキストとの合同管理の第２のモード例に含まれる、基本的、代表的な動作またはイベント例を示すフローチャートである。 図２４の第２のモードの実装例における送信ノードにおいて実行される動作例を示すフローチャートである。 図２５の動作に対応するパケットの図を示す概要図である。 図２４の第２のモードの実装例における受信ノードにおいて実行される動作例を示すフローチャートである。 図２７の動作に対応するパケットの図を示す概要図である。 圧縮ヘッダ（群）を暗号化するパケットを準備するモード例において実行することができる非限定動作またはイベント例を示すフローチャートである。 図２９の種々の動作に対応してパケットが圧縮および暗号化動作に発展する際のパケットコンテンツの図を示す概要図である。 圧縮ヘッダ（群）の暗号化がなされている受信パケットを処理するモード例において実行することができる非限定動作またはイベント例を示すフローチャートである。 図２９の種々の動作に対応してパケットが、暗号解読および解凍動作に発展する際のパケットコンテンツの図を示す概要図である。 ＲｏＨＣに基づく実施形態を示す図である。 従来の暗号化と圧縮の分離を、結合されているあるいはマージされている圧縮処理と暗号化処理と対比する概要図である。 結合されているあるいはマージされている圧縮処理および暗号処理を有し、圧縮処理および暗号処理によってシーケンス番号が共有されている送信ノードおよび受信ノードの両方に関して実行される動作またはイベントのシーケンスを示す概要図である。 結合されているあるいはマージされている圧縮処理および暗号処理を有し、シーケンス番号が共有される送信ノードに含まれる動作またはイベントを示すフローチャートである。 結合されているあるいはマージされている圧縮処理および暗号処理を有し、シーケンス番号が共有されている受信ノードに含まれる動作またはイベントを示すフローチャートである。 ７レイヤＯＳＩレイヤモデルを示す概要図である。

Claims (28)

1. 通信ネットワークのノード（２０）であって、
   前記ノード（２０）によって取り扱われるパケットの第１の部分における第１の動作を実行するように構成されている第１の機能（３０）と、
   前記パケットの第２の部分において第２の動作を実行するように構成されている第２の機能（３２）とを備え、
   前記第１の機能（３０）および前記第２の機能（３２）は、前記パケットにおける動作に対して共有トランザクション（３４）を使用するように構成され、これにより、前記第１の動作および前記第２の動作の実行において前記共有トランザクション（３４）が使用されない場合より、前記第１の動作（３０）および前記第２の動作（３２）の実行後、前記共有トランザクション（３４）によって、前記パケットが有する、前記第１の機能（３０）および前記第２の機能（３２）に起因するオーバヘッドをより少なくし、
   前記共有トランザクション（３４）は、前記第１の機能（３０）及び前記第２の機能（３２）で使用される共有情報を備え、
   前記第１の機能（３０）は、データ圧縮機能であり、前記第２の機能（３２）は、暗号化機能であり、
   前記共有情報は、前記圧縮機能用のシーケンス番号ＭＳＮとして、前記圧縮機能によって発生されるシーケンス番号であり、
   前記シーケンス番号は、更に、セッションキーを導出するために、前記暗号化機能によって使用される
   ことを特徴とするノード。
2. 前記共有情報は、セッションキーを導出する前記暗号化機能によって発生されるシーケンス番号であり、かつシーケンス番号ＭＳＮとして前記圧縮機能によって使用される
   ことを特徴とする請求項１に記載のノード。
3. 前記ノードは、
   システムアーキテクチャ進化／長期的進化（ＳＡＥ／ＬＴＥ）通信ネットワークのアクセスゲートウェイと、
   システムアーキテクチャ進化／長期的進化（ＳＡＥ／ＬＴＥ）通信ネットワークの先進ノードＢ（ｅＮＢ）と
   の内の１つである
   ことを特徴とする請求項１または２に記載のノード。
4. 前記ノード（２０）は、第１の物理ノード（２０（１））に配置されている前記第１の機能（３０）と、第２の物理ノード（２０（２））に配置されている前記第２の機能（３２）とを備える、複数の物理ノードを備える
   ことを特徴とする請求項１乃至３のいずれか１項に記載のノード。
5. 前記第１の機能（３０）、前記第２の機能（３２）及び前記共有トランザクション（３４）は、同一モデルレイヤ内に存在する
   ことを特徴とする請求項１乃至４のいずれか１項に記載のノード。
6. 前記第１の機能（３０）、前記第２の機能（３２）及び前記共有トランザクション（３４）は、リンクレイヤプロトコルによって実行される
   ことを特徴とする請求項５に記載のノード。
7. 前記共有トランザクション（３４）は、前記パケットの前記第１の部分において動作する前記第２の機能（３２）を備える
   ことを特徴とする請求項１乃至６のいずれか１項に記載のノード。
8. 前記第１の機能（３０）は、データ圧縮機能であり、前記第２の機能（３２）は、暗号化機能であり、
   前記暗号化機能は、前記パケットのヘッダの少なくとも一部を暗号化する
   ことを特徴とする請求項７に記載のノード。
9. 前記暗号化機能は、前記ヘッダの圧縮チャネル識別子は暗号化しない
   ことを特徴とする請求項８に記載のノード。
10. 前記共有トランザクション（３４）は、前記パケットの第１の部分の少なくとも一部に対する、および前記パケットの第２の部分の少なくとも一部に対する、チェックサムの判定を含んでいる
    ことを特徴とする請求項１乃至９のいずれか１項に記載のノード。
11. 前記第１の機能（３０）は、データ圧縮機能であり、
    前記パケットの第１の部分は、前記パケットのヘッダであり、
    前記第２の機能（３２）は、暗号化機能であり、
    前記パケットの第２の部分は、前記パケットのペイロードであり、
    前記チェックサムは、前記パケットのヘッダの少なくとも一部に対して、および前記パケットのペイロードの少なくとも一部に対して、判定される
    ことを特徴とする請求項１０に記載のノード。
12. 前記共有トランザクション（３４）は、前記パケットの第１の部分の少なくとも一部に対するチェックサムの判定を含み、
    前記チェックサムが判定される前記パケットの第１の部分の一部は、前記パケットの第２の部分における動作において前記第２の機能（３２）によって利用されるパラメータを含んでいる
    ことを特徴とする請求項１に記載のノード。
13. 前記第１の機能（３０）は、データ圧縮機能であり、
    前記パケットの第１の部分は、前記パケットのヘッダであり、
    前記第２の機能（３２）は、暗号化機能であり、
    前記パケットの第２の部分は、前記パケットのペイロードであり、
    前記チェックサムは、前記パケットのヘッダの少なくとも一部に対して判定され、
    前記パケットの第２の部分における動作において前記第２の機能（３２）によって利用される前記パラメータは、その暗号コンテキスト用のセッションキーを導出するためのシーケンス番号である
    ことを特徴とする請求項１２に記載のノード。
14. 前記第１の機能（３０）は、前記パケットのヘッダ、前記パケットのペイロード、前記パケットに関連付けられている信号の少なくとも１つを圧縮するように構成されている圧縮機能を備える
    ことを特徴とする請求項１乃至１３のいずれか１項に記載のノード。
15. 通信ネットワークのノードを動作させる方法であって、
    第１の機能（３０）を使用して、前記ノードによって取り扱われるパケットの第１の部分における第１の動作を実行し、
    第２の機能（３２）を使用して、前記パケットの第２の部分において第２の動作を実行し、
    共有トランザクション（３４）を使用して、前記パケットを処理することを特徴とし、 前記共有トランザクションは、前記第１の動作および前記第２の動作の両方において使用され、これにより、前記第１の動作および前記第２の動作の実行において前記共有トランザクション（３４）が使用されない場合より、前記共有トランザクション（３４）によって、前記パケットが有する、前記第１の機能（３０）および前記第２の機能（３２）に起因するオーバヘッドをより少なくし、
    前記共有トランザクション（３４）は、前記第１の機能（３０）及び前記第２の機能（３２）で使用される共有情報を備え、
    前記第１の機能（３０）は、データ圧縮機能であり、前記第２の機能（３２）は、暗号化機能であり、
    前記共有情報は、前記圧縮機能用のシーケンス番号ＭＳＮとして、前記圧縮機能によって発生されるシーケンス番号であり、
    前記シーケンス番号は、更に、セッションキーを導出するために、前記暗号化機能によって使用される
    ことを特徴とする方法。
16. 前記共有情報は、セッションキーを導出する前記暗号化機能によって発生されるシーケンス番号であり、かつシーケンス番号ＭＳＮとして前記圧縮機能によって使用される
    ことを特徴とする請求項１５に記載の方法。
17. 前記ノードは、
    システムアーキテクチャ進化／長期的進化（ＳＡＥ／ＬＴＥ）通信ネットワークのアクセスゲートウェイと、
    システムアーキテクチャ進化／長期的進化（ＳＡＥ／ＬＴＥ）通信ネットワークの先進ノードＢ（ｅＮＢ）と
    の内の１つである
    ことを特徴とする請求項１５または１６に記載の方法。
18. 前記ノードは、複数の物理ノードを含み、
    当該方法は、更に、第１の物理ノードに配置されている前記第１の機能（３０）を配置し、第２の物理ノードに配置されている前記第２の機能（３２）を配置することを含む
    ことを特徴とする請求項１５乃至１７のいずれか１項に記載の方法。
19. 更に、同一モデルレイヤプロトコルを使用して、前記第１の機能（３０）、前記第２の機能（３２）及び前記共有トランザクション（３４）を実行する
    ことを特徴とする請求項１５乃至１８のいずれか１項に記載の方法。
20. 更に、リンクレイヤプロトコルを使用して、前記第１の機能（３０）、前記第２の機能（３２）及び前記共有トランザクション（３４）を実行する
    ことを特徴とする請求項１９に記載の方法。
21. 前記共有トランザクション（３４）は、前記パケットの前記第１の部分において動作する前記第２の機能（３２）を備える
    ことを特徴とする請求項１５乃至２０のいずれか１項に記載の方法。
22. 前記第１の機能（３０）は、データ圧縮機能であり、前記第２の機能（３２）は、暗号化機能であり、
    前記暗号化機能は、前記パケットのヘッダの少なくとも一部を暗号化する
    ことを特徴とする請求項２１に記載の方法。
23. 前記暗号化機能は、前記ヘッダの圧縮チャネル識別子は暗号化しない
    ことを特徴とする請求項２２に記載の方法。
24. 前記共有トランザクション（３４）は、前記パケットの第１の部分の少なくとも一部に対する、および前記パケットの第２の部分の少なくとも一部に対する、チェックサムの判定を含んでいる
    ことを特徴とする請求項１５乃至２３のいずれか１項に記載の方法。
25. 前記第１の機能（３０）は、データ圧縮機能であり、
    前記パケットの第１の部分は、前記パケットのヘッダであり、
    前記第２の機能（３２）は、暗号化機能であり、
    前記パケットの第２の部分は、前記パケットのペイロードであり、
    前記チェックサムは、前記パケットのヘッダの少なくとも一部に対して、および前記パケットのペイロードの少なくとも一部に対して、判定される
    ことを特徴とする請求項２４に記載の方法。
26. 前記共有トランザクション（３４）は、前記パケットの第１の部分の少なくとも一部に対するチェックサムの判定を含み、
    前記チェックサムが判定される前記パケットの第１の部分の一部は、前記パケットの第２の部分における動作において前記第２の機能（３２）によって利用されるパラメータを含んでいる
    ことを特徴とする請求項１５に記載の方法。
27. 前記第１の機能（３０）は、データ圧縮機能であり、
    前記パケットの第１の部分は、前記パケットのヘッダであり、
    前記第２の機能（３２）は、暗号化機能であり、
    前記パケットの第２の部分は、前記パケットのペイロードであり、
    前記チェックサムは、前記パケットのヘッダの少なくとも一部に対して判定され、
    前記パケットの第２の部分における動作において前記第２の機能によって利用される前記パラメータは、その暗号コンテキスト用のセッションキーを導出するためのシーケンス番号である
    ことを特徴とする請求項２６に記載の方法。
28. 前記第１の機能（３０）は、前記パケットのヘッダ、前記パケットのペイロード、前記パケットに関連付けられている信号の少なくとも１つを圧縮するように構成されている圧縮機能を備える
    ことを特徴とする請求項１５乃至２７のいずれか１項に記載の方法。

Images