JP5680633B2 - バックホールヘッダ圧縮 - Google Patents

Description

本出願は、「ＭＭＥ ＣＯＯＲＤＩＮＡＴＥＤ ＢＡＣＫＨＡＵＬ ＨＥＡＤＥＲ ＣＯＭＰＲＥＳＳＩＯＮ」という名称の２００９年６月１８日付の米国仮特許出願第６１／２１８１０７号の優先権および利益を主張し、この出願は、その全体がここでの言及によって本明細書に援用される。

本発明は、電気通信に関し、特にヘッダ圧縮に関する。

典型的なセルラー無線システムにおいては、無線端末（移動局および／またはユーザ機器ユニット（ＵＥ）としても知られる）が、無線アクセスネットワーク（ＲＡＮ）を介して１つまたは複数のコアネットワークと通信する。無線アクセスネットワーク（ＲＡＮ）は、セル領域へと分割された地理的領域をカバーし、それぞれのセル領域を、一部のネットワークにおいては「ＮｏｄｅＢ」とも称される、例えば無線基地局（ＲＢＳ）などの基地局が担当する。セルは、基地局サイトの無線基地局設備によって無線の範囲が与えられる地理的領域である。それぞれのセルは、セルにおいて送信される局所無線領域内のＩＤによって特定される。基地局は、無線周波数で動作する無線インターフェイスを介して基地局の範囲内のユーザ機器ユニット（ＵＥ）と通信する。

無線アクセスネットワークのいくつかの種類においては、複数の基地局が、（例えば、地上通信線またはマイクロ波によって）無線ネットワークコントローラ（ＲＮＣ）へと典型的に接続される。無線ネットワークコントローラは、基地局コントローラ（ＢＳＣ）と呼ばれることもあるが、自身へと接続された複数の基地局の種々の働きを管理し、調整する。無線ネットワークコントローラは、典型的には、１つまたは複数のコアネットワークへと接続される。

ユニバーサル・モバイル・テレコミュニケーション・システム（ＵＭＴＳ）が、グローバル・システム・フォー・モバイル・コミュニケーション（ＧＳＭ（登録商標））から発展した第３世代の移動体通信システムであり、広帯域符号分割多重アクセス（ＷＣＤＭＡ）アクセス技術にもとづいて改善された移動体通信サービスを提供するように意図されている。ＵＴＲＡＮは、基本的に、ユーザ機器ユニット（ＵＥ）のための広帯域符号分割多重アクセスを使用する無線アクセスネットワークである。

第３世代パートナーシッププロジェクト（３ＧＰＰ）として知られるフォーラムにおいて、電気通信の供給者らは、第３世代ネットワーク（とりわけ、ＵＴＲＡＮ）のための規格について提案および合意し、データレートおよび無線容量の改善を研究している。第３世代パートナーシッププロジェクト（３ＧＰＰ）は、ＵＴＲＡＮおよびＧＳＭベースの無線アクセスネットワーク技術のさらなる発展に取り組んでいる。進化型ユニバーサル地上波無線アクセスネットワーク（Ｅ−ＵＴＲＡＮ）の仕様化が、第３世代パートナーシッププロジェクト（３ＧＰＰ）において進行中である。進化型ユニバーサル地上波無線アクセスネットワーク（Ｅ−ＵＴＲＡＮ）は、ロング・ターム・エボリューション（ＬＴＥ）およびシステム・アーキテクチャ・エボリューション（ＳＡＥ）を含む。

ロング・ターム・エボリューション（ＬＴＥ）は、無線基地局ノードが無線ネットワークコントローラ（ＲＮＣ）ノードにではなくコアネットワークへと直接接続される３ＧＰＰ無線アクセス技術の変形である。一般に、ＬＴＥにおいては、無線ネットワークコントローラ（ＲＮＣ）ノードの機能が、無線基地局ノードによって実行される。したがって、ＬＴＥシステムの無線アクセスネットワーク（ＲＡＮ）は、無線ネットワークコントローラ（ＲＮＣ）ノードへの報告を行わない（、）無線基地局ノードを含む基本的に「フラット」なアーキテクチャを有する。

進化型ＵＴＲＡＮ（Ｅ−ＵＴＲＡＮ）は、ユーザ機器ユニット（ＵＥ）に向けて進化したＵＴＲＡユーザプレーンおよび制御プレーン・プロトコル・ターミネーションを提供する進化した基地局ノード（例えば、進化型ＮｏｄｅＢまたはｅＮｏｄｅＢあるいはｅＮＢ）を含む。ｅＮＢは、以下に挙げられる機能（以下に挙げられない他の機能も）をホストする。すなわち、（１）無線リソースの管理（例えば、無線ベアラ制御、無線アドミッション制御）、接続モビリティ制御、動的リソース割り当て（スケジューリング）のための機能、（２）ＭＭＥへのルーティングがユーザ機器ユニット（ＵＥ）によってもたらされる情報から決定できない場合のモビリティ管理エンティティ（ＭＭＥ）の選択、および（３）ＩＰヘッダ圧縮およびユーザ・データ・ストリームの暗号化ならびにＵＥモビリティのサポートのためのＵプレーンの切り替えを含むユーザプレーン機能である。ｅＮＢは、ユーザプレーンヘッダ圧縮および暗号化の機能を含む物理（ＰＨＹ）、メディアアクセス制御（ＭＡＣ）、無線リンク制御（ＲＬＣ）、およびパケットデータ制御プロトコル（ＰＤＣＰ）の各層をホストする。ｅＮｏｄｅＢは、制御プレーンに対応する無線リソース制御（ＲＲＣ）機能も提供する。ｅＮｏｄｅＢは、無線リソース管理、アドミッション制御、スケジューリング、ネゴシエートしたＵＬ ＱｏＳの行使、セル情報の送信、ユーザおよび制御プレーンデータの暗号化／解読、ならびにＤＬ／ＵＬユーザプレーン・パケット・ヘッダの圧縮／解凍を含む多数の機能を実行する。

上述のモビリティ管理エンティティ（ＭＭＥ）が、進化型パケットコア（ＥＰＣ）における主たるシグナリングノード／エンティティである。モビリティ管理エンティティは、ページングの開始および無線端末（ＵＥ）の認証を担当する。また、モビリティ管理エンティティは、アイドルモードＵＥについてトラッキング・エリア・レベルの位置情報を維持し、初期の登録プロセスの際の正しいゲートウェイの選択に関与する。ＭＭＥは、Ｓ１−ＭＭＥインターフェイスを介してｅＮＢへとつながり、Ｓ１１インターフェイスを介してサービングゲートウェイ（ＳＧＷ）へとつながる。多数のＭＭＥを、ネットワークにおけるシグナリング負荷の増加に対処するために、プールにグループ化することができる。さらに、ＭＭＥは、ＬＴＥと２Ｇ／３Ｇネットワークとの間のハンドオーバーシグナリングにおいて重要な役割を果たす。

進化型パケットコアは、ＬＴＥおよび他のアクセス技術による使用のために３ＧＰＰによってリリース８において定義されたＩＰベースのコアネットワークである。ＥＰＣは、典型的には、モビリティ管理エンティティ、サービングゲートウェイ、およびＰＤＮゲートウェイという下位構成要素を含む。ＥＰＣは、ＩＭＳ（ＩＰマルチメディアサブシステム）において提供されているサービスなど、種々のサービスへのアクセスを与えるための簡単化された全ＩＰコア・ネットワークアーキテクチャを提供する。

ＧＰＲＳトンネリングプロトコル（ＧＴＰ）は、ＧＭＳおよびＵＭＴＳネットワークならびにＳＡＥ／ＬＴＥネットワークワークにおける汎用パケット無線サービス（ＧＰＲＳ）において通信セッションの確立および管理、ならびにカプセル化されたユーザ・データ・パケットを運ぶのに使用されるＩＰベースの通信プロトコルのグループである。

ＷＣＤＭＡネットワークにおいて、ユーザプレーンの暗号化およびヘッダ圧縮（ＨＣ）は、無線ネットワークコントローラノード（ＲＮＣ）において実行される。これは、ＮｏｄｅＢとＲＮＣとの間のトラフィックが、効果的にヘッダ圧縮され、高価なＲＡＮバックホール（ＮｏｄｅＢとＲＮＣとの間の搬送）のトラフィックの削減につながる。しかしながら、ＬＴＥにおいては、ヘッダ圧縮がｅＮｏｄｅＢにおいて実行される。これは、アップストリーム・バックホール・リンク（ｅＮｏｄｅＢと進化型コアネットワークとの間を延びている）が、ヘッダ圧縮されていないユーザＩＰパケットを運ぶことを意味する。アップストリーム・バックホール・リンクにおいてＩＰパケットをヘッダ圧縮無しで搬送することは、かなりのオーバヘッドを呈する。例えば、５００バイトという平均パケットサイズにおいて、圧縮されたＴＣＰ／ＩＰヘッダはパケットのうちの４０バイトを取り除き、結果として機能を低下させることなく８％のトラフィック削減をもたらす。典型的なパケットサイズがさらに小さい場合、利益もさらに大きくなりうる。

一態様において、本明細書に開示される技術は、電気通信ネットワークのモビリティ管理エンティティにおける方法であって、バックホールリンクの少なくとも一部分におけるヘッダ圧縮の使用をネゴシエートするステップを含む方法に関する。別の態様において、本明細書に開示される技術は、電気通信ネットワークの動作方法であって、バックホールリンクの少なくとも一部分におけるヘッダ圧縮の使用をネゴシエートするステップを含む方法に関する。本明細書において使用されるとき、バックホールリンクは、電気通信ネットワークのサービング・ゲートウェイ・ノードと基地局ノードとの間を延びている。

バックホールリンクが、一般に、サービング・ゲートウェイ・ノードと基地局ノードとの間の汎用パケット無線サービス・トンネリング・プロトコル（ＧＴＰ）トンネルを含んでおり、ヘッダ圧縮が、ＧＴＰトンネル内を運ばれるパケットに適用される。

バックホールリンクにおけるヘッダ圧縮の使用のネゴシエーションを、（１）ベアラ確立処理、（２）アタッチ処理、または（３）ハンドオーバ処理のうちのいずれか１つの実行時に行うことができる。

例示的な態様および実施形態においては、ヘッダ圧縮の使用のネゴシエーションが、（１）サービング・ゲートウェイ・ノードがヘッダ圧縮の使用に同意するかどうかを確認するステップと、（２）基地局ノードがヘッダ圧縮の使用に同意するかどうかを確認するステップと、（３）バックホールリンクにおいてヘッダ圧縮を実施するかどうかを決定するために（１）および（２）の確認を使用するステップとを含む。

別の例示的な態様および実施形態においては、ヘッダ圧縮の使用のネゴシエーションが、（１）サービング・ゲートウェイ・ノードからヘッダ圧縮初期化パラメータを取得するステップと、（２）ヘッダ圧縮初期化パラメータに関する基地局ノードからの応答を取得するステップと、（３）バックホールリンクにおいてヘッダ圧縮を実施するかどうかを決定するために行為（２）の応答を使用するステップとをさらに含む。

いくつかの例示的な態様および実施形態においては、バックホールリンクが無線リンクを含む。無線インターフェイスによって運ばれるバックホールリンクを有する特定のベアラカプセル化の実施形態においては、汎用パケット無線サービス・トンネリング・プロトコル（ＧＴＰ）トンネルが、サービング・ゲートウェイ・ノードと中継基地局ノードとの間を横切っている。そのようなベアラカプセル化の実施形態において、本方法は、汎用パケット無線サービス・トンネリング・プロトコル（ＧＴＰ）トンネルにおけるヘッダ圧縮の使用をネゴシエートするために、サービング・ゲートウェイ・ノードと中継基地局ノードとの間のシグナリングを取り扱うステップをさらに含む。

無線インターフェイスによって運ばれるバックホールリンクを有する特定のプロキシの実施形態においては、バックホールリンクが、サービング・ゲートウェイ・ノードとドナー基地局ノードとの間を延びる第１のトンネル、およびドナー基地局ノードと中継基地局ノードとの間を延びるさらなる（例えば、第２の）トンネルを含む。第２のトンネルが、中継基地局ノードとドナー基地局ノードとの間の無線インターフェイスを横切っている。そのような例示的なプロキシの実施形態において、本方法は、第２のトンネルにおけるヘッダ圧縮の使用をネゴシエートするために、中継基地局ノードとドナー基地局ノードとの間のシグナリングを取り扱うステップをさらに含み、（随意により）第１のトンネルにおけるヘッダ圧縮の使用をネゴシエートするために、ドナー基地局ノードとサービング・ゲートウェイ・ノードとの間のシグナリングを取り扱うステップをさらに含む。

別の例示的な態様および実施形態は、バックホールリンクが所定の値を下回る伝送能力しか有さない伝送リンクを含む場合にヘッダ圧縮の使用を開始するステップをさらに含む。

別の態様において、本明細書に開示される技術は、電気通信ネットワークの基地局ノードにおける方法に関する。本方法は、バックホールリンクの少なくとも一部分におけるヘッダ圧縮の使用について、同意が存在するかどうかを判断するステップと、同意を表わすメッセージを送信するステップとを含む。

基地局ノードにおける方法の例示的な態様および実施形態は、サービング・ゲートウェイ・ノードによって提案されたヘッダ圧縮初期化パラメータの提案に対する応答を、メッセージにてもたらすステップをさらに含む。

基地局ノードにおける方法の例示的な態様および実施形態においては、基地局ノードが、中継基地局ノードであり、バックホールリンクが、サービング・ゲートウェイ・ノードと中継基地局ノードとの間を延びる汎用パケット無線サービス・トンネリング・プロトコル（ＧＴＰ）トンネルを含む。汎用パケット無線サービス・トンネリング・プロトコル（ＧＴＰ）トンネルが、中継基地局ノードとドナー基地局ノードとの間の無線インターフェイスを横切っている。基地局ノードにおける方法は、中継基地局ノードからドナー基地局ノードへ汎用パケット無線サービス・トンネリング・プロトコル（ＧＴＰ）トンネルを運ぶパケットのＵＤＰ／ＩＰヘッダを圧縮するステップと、サービング・ゲートウェイ・ノードからドナー基地局ノードへと汎用パケット無線サービス・トンネリング・プロトコル（ＧＴＰ）トンネルを横切るパケットのＴＣＰ／ＵＤＰ／ＩＰインナヘッダを圧縮するステップとをさらに含む。

他の態様において、本明細書に開示される技術は、基地局ノードとサービングゲートウェイ（ＳＧＷ）との間のバックホールリンクにおいてヘッダ圧縮を使用するかどうかをネゴシエートするように構成されたモビリティ管理エンティティ（ＭＭＥ）に関する。

他の態様において、本明細書に開示される技術は、基地局ノードと、サービングゲートウェイ（ＳＧＷ）と、基地局ノードとサービングゲートウェイ（ＳＧＷ）との間のバックホールリンクにおいてヘッダ圧縮を使用するかどうかをネゴシエートするように構成されたモビリティ管理エンティティ（ＭＭＥ）とを備える電気通信ネットワークに関する。

本発明の以上の目的、特徴、および利点、ならびに他の目的、特徴、および利点が、添付の図面に示されるとおりの好ましい実施形態についての以下のさらに詳しい説明から明らかになるであろう。添付の図面において、それぞれの参照符号は、種々の図を通して同じ部分を指し示している。図面は必ずしも比例尺ではなく、むしろ本発明の原理を説明することに強調が置かれている。

図１は、バックホールリンクにおけるヘッダ圧縮のネゴシエーションを示している電気通信ネットワークの一部分の概略図である。 図２は、バックホールリンクにおけるヘッダ圧縮をネゴシエートする方法におけるシグナリングの例示的な実施形態および様態を示した略図である。 図３は、バックホールリンクにおけるヘッダ圧縮をネゴシエートする方法におけるシグナリングの別の例示的な実施形態および様態を示した略図であり、シグナリングにヘッダ圧縮初期化パラメータが含まれる。 図４は、図２および図３のような典型的なシグナリングの実施形態および態様をどのように従来からのベアラ確立処理に取り入れることができるのかを示した略図である。 図５は、図２および図３のような典型的なシグナリングの実施形態および態様をどのように従来からのベアラ確立処理に取り入れることができるのかを示した別の略図である。 図６は、バックホールリンクにおけるヘッダ圧縮の本明細書に包含される実施形態によるネゴシエーションが、専用ベアラ確立処理、アタッチ処理、ハンドオーバ処理、またはベアラを確立すべき他の処理に適用されることを示した図である。 図７は、バックホールリンクにおけるヘッダ圧縮についてネゴシエーションを実行するように構成された典型的なモビリティ管理エンティティの概略図である。 図８は、電気通信ネットワークにおける中継ノードまたはセルフバックホール基地局ノードの使用の一般的な事例の概略図であり、バックホールリンクにおけるヘッダ圧縮のネゴシエーションをさらに示している。 図８Ａは、電気通信ネットワークにおいて中継ノードまたはセルフバックホール基地局ノードを使用する場合のバックホールリンクにおけるヘッダ圧縮のネゴシエーションについて、ベアラカプセル化の実施態様を示した概略図である。 図８Ｂは、電気通信ネットワークにおいて中継ノードまたはセルフバックホール基地局ノードを使用する場合のバックホールリンクにおけるヘッダ圧縮のネゴシエーションについて、プロキシの実施態様を示した概略図である。 図８Ｂは、セルフバックホール基地局ノードにおけるバックホールリンクのヘッダ圧縮について図８Ａのベアラカプセル化の実施態様に適したプロトコルスタックの略図である。 図９Ｂは、セルフバックホール基地局ノードにおけるバックホールリンクのヘッダ圧縮について図９Ａのプロキシの実施態様に適したプロトコルスタックの略図である。 図１０は、モビリティ管理エンティティ（ＭＭＥ）の一部分、ドナー基地局ノードの一部分、およびセルフバックホール中継基地局ノードの一部分の概略図である。 図１１は、無線リンクおよびドナー基地局ノードを含むバックホールリンクにおけるヘッダ圧縮のネゴシエーション方法におけるシグナリングの例示的な実施形態および様態を示した略図である。 図１２は、バックホールリンクにおいてヘッダ圧縮を実行するかどうかを決定する際に実行することができる例示的な工程または行為を示したフロー図である。 図１３は、ヘッダのチェーンを示した略図であり、ＧＴＰトンネリングを説明している。 図１４は、現在のＲＯＨＣプロファイルによるアウタＩＰ／ＵＤＰヘッダだけの圧縮を示した略図である。 図１５は、ＧＴＰ−Ｕヘッダが圧縮されないままであり、一のヘッダ圧縮のインスタンスがＧＴＰ−Ｕトンネルの内部のＩＰヘッダを圧縮する一方で、別のインスタンスがアウタＩＰヘッダを圧縮していることを示す略図である。

以下の説明においては、本発明を限定する目的ではなくて説明する目的において、本発明の完全な理解をもたらすために、特定のアーキテクチャ、インターフェイス、技法などといった具体的詳細を説明する。しかしながら、本発明をこれらの具体的詳細から逸脱する別の実施形態において実施してもよいことは、当業者にとって明らかであろう。すなわち、本明細書において明示的には説明または図示されないが、本発明の原理を具現化し、本発明の技術的思想および技術的範囲に包含される種々の構成を、当業者であれば考案できるであろう。いくつかの場合においては、よく知られている装置、回路、および方法の詳細な説明を、本発明の説明を不要な細事によって不明瞭にしてしまうことがないよう、省略する。本発明の原理、態様、および実施形態、ならびにそれらの具体的な実施例に言及する本明細書におけるすべての陳述は、それらの構造および機能の両方における均等物を包含するものである。さらに、そのような均等物には、現時点において知られている均等物ならびに将来に開発される均等物の両方が含まれ、すなわち構造にかかわらず同じ機能を果たすように開発された任意の構成要素が含まれる。

したがって、例えば、本明細書におけるブロック図が、技術の原理を具現化する例示の回路の概念的な図を表わすことができることを、当業者であれば理解できるであろう。同様に、あらゆるフロー図、状態遷移図、擬似コードなどが、コンピュータにとって読み取り可能な媒体に実質的に表現することができ、したがってコンピュータまたはプロセッサによって（そのようなコンピュータまたはプロセッサが明示的に示されていてもいなくても）実行することができる種々のプロセスを表わすことを、理解されよう。

「コンピュータ」、「プロセッサ」、または「コントローラ」と標記または説明される機能ブロックを含む種々の構成要素の機能を、専用のハードウェアならびにコンピュータにとって読み取り可能な媒体に保存されたコード化されたインストラクションの形態のソフトウェアを実行することができるハードウェアを使用することによって、もたらすことが可能である。コンピュータは、一般に、１つまたは複数のプロセッサを備えるものと理解され、用語「コンピュータ」および「プロセッサ」は、本明細書において交換可能に使用することができる。コンピュータまたはプロセッサによってもたらされる場合、それらの機能を、単一の専用のコンピュータまたはプロセッサによってもたらしても、単一の共有されたコンピュータまたはプロセッサによってもたらしても、あるいは複数の個別のコンピュータまたはプロセッサ（その一部が共有されていても、分散していてもよい）によってもたらしてもよい。そのような機能は、コンピュータによって実現され、したがって機械によって実現されると考えるべきである。さらには、用語「プロセッサ」または「コントローラ」の使用を、そのような機能の実行および／またはソフトウェアの実行が可能な他のハードウェアも指すものと解釈すべきであり、これらに限られるわけではないが、デジタル信号プロセッサ（ＤＳＰ）ハードウェア、縮小命令セットプロセッサ、ハードウェア（例えば、デジタルまたはアナログ）回路、ならびに（妥当であれば）そのような機能を実行することができる状態機械を挙げることができる。

上述した検討から理解されるとおり、ロング・ターム・エボリューション（ＬＴＥ）において、進化型パケットコア（ＥＰＣ）のｅＮｏｄｅＢとサービング・ゲートウェイ・ノードとの間のトラフィックについて、ヘッダ圧縮を導入することが有益であると考えられる。ｅＮｏｄｅＢとサービングゲートウェイ（ＳＧＷ）ノードとの間のアップストリーム・バックホール・リンクのトラフィックは、汎用パケット無線サービス・トンネリング・プロトコル（ＧＴＰ）トンネルの中へと進む。ＩＰパケットがＧＴＰトンネルの中へとトンネルされるとき、元のパケットのＩＰヘッダ（「インナヘッダ」と呼ばれる）は、トンネルの中に「隠され」る。トンネルそのものが、「アウタヘッダ」と呼ばれる自身の固有のＩＰヘッダを有している。このアウタヘッダだけが、トンネルが通過するネットワークノードにとって可視である。したがって、トラフィックがＧＴＰトンネルを通って移動するということが、トンネルされたパケットに加えられるヘッダ圧縮がトンネルの内部を「見る」ことができず、インナヘッダを圧縮することができないため、ヘッダ圧縮にとって問題である。

以上に加え、図１３が、ヘッダのチェーンを示しており、ＧＴＰトンネリングを説明している。ＲＯＨＣの枠組みを使用するヘッダ圧縮は、２つのレベルのＩＰヘッダを効率的に圧縮することができるが、ＧＴＰトンネルの内部のＩＰヘッダの圧縮のための既存のヘッダ圧縮の技術的解決策は存在しない。より具体的には、このヘッダのチェーンをサポートするヘッダ圧縮アルゴリズム（例えば、ＲＯＨＣプロファイル）が存在せず、ＧＴＰトンネルの内部のヘッダ圧縮の使用を構成するための手段が存在しない。現在のＲＯＨＣプロファイルでは、図１４によって示されるように、アウタＩＰヘッダおよびＵＤＰヘッダだけしか圧縮することができない。換言すると、ヘッダ圧縮が、第３世代パートナーシッププロジェクト（３ＧＰＰ）標準化団体によって標準化されておらず、したがってサービング・ゲートウェイ・ノードおよびｅＮｏｄｅＢが、受信したデータがヘッダ圧縮されているか否かを知る術を持たない。

このニーズに応えて、本発明の発明者は、ＧＴＰトンネルの内部でのヘッダ圧縮の使用をネゴシエートするために、サービング・ゲートウェイ・ノード（ＳＧＷ）とｅＮｏｄｅＢとの間の状態交換を管理することを提案する。一例示的な実施形態および態様においては、モビリティ管理エンティティ（ＭＭＥ）などのエージェントが、ＧＴＰトンネルの内部でのヘッダ圧縮の使用をネゴシエートするために、サービング・ゲートウェイ・ノード（ＳＧＷ）とｅＮｏｄｅＢとの間の状態交換を管理するためのエージェントとして働く。他の実施形態においては、ネゴシエータが、特に適切なシグナリングプロトコルがＳＧＷとｅＮｏｄｅＢとの間で確立される場合に、ＳＧＷ自身などの別のエンティティであってもよい。

ＧＴＰトンネルの内部におけるヘッダ圧縮のネゴシエートされた使用は、ヘッダ圧縮可能およびヘッダ圧縮不可能なサービング・ゲートウェイ・ノードおよびｅＮｏｄｅＢが非ヘッダ圧縮モードに確実に戻ることを可能にし、ＭＭＥがヘッダ圧縮の使用についてのポリシー決定を行うことを可能にする。例えば、ＭＭＥがネゴシエートエージェントである状況において、ＭＭＥは、バックホールリンクが無線リンクを含む場合（すなわち、中継、セルフバックホーリング、などの場合）に限ってヘッダ圧縮を有効にするように決定でき、あるいは接続が１つまたは複数の低容量の搬送リンクを通過する場合にヘッダ圧縮を有効にするように決定することができる。

ベアラの確立またはハンドオーバの際に、実際に、汎用パケット無線サービス・トンネリング・プロトコル（ＧＴＰ）トンネルがｅＮｏｄｅＢとサービング・ゲートウェイ・ノードとの間で設定されるたびに、トンネルのパラメータを交換する必要があり、具体的には両端のＴＥＩＤを交換する必要がある。そのような値は、モビリティ管理エンティティを介して交換される。本明細書に開示される技術は、ＴＥＩＤに加えて、それぞれのエンドポイントがヘッダ圧縮可能であるか否か、およびヘッダ圧縮を望むか否かを指定するように、これらの信号または同等の信号へと広がる。

図１は、進化型パケットコア（ＥＰＣ）２０および無線アクセスネットワーク（ＲＡＮ）２２を含む電気通信ネットワークの一部分を示している。進化型パケットコア（ＥＰＣ）２０が、サービングゲートウェイ（ＳＧＷ）２４およびモビリティ管理エンティティ（ＭＭＥ）２６を、他の図示されていないエンティティおよびノードと同様に備えている。進化型パケットコア（ＥＰＣ）２０が、無線アクセスネットワーク（ＲＡＮ）２２へと接続し、この無線アクセスネットワーク（ＲＡＮ）２２は、少なくとも１つの基地局ノード２８（ｅＮｏｄｅＢまたはｅＮＢとしても知られる）を備えている。基地局ノード２８は、気中または無線インターフェイス３２を介して無線端末３０と通信する。基地局ノード２８は、典型的には複数の無線端末（そのような無線端末が１つだけ図示されている）を担当し、複数のセルを担当してもよいことを、理解されたい。

図１に示されるように、モビリティ管理エンティティ（ＭＭＥ）２６は、インターフェイスＳ１−ＭＭＥを介して基地局ノード２８と通信し、モビリティ管理エンティティ（ＭＭＥ）２６は、インターフェイスＳ１１を介してサービングゲートウェイ（ＳＧＷ）２４と通信し、サービングゲートウェイ（ＳＧＷ）２４および基地局ノード２８が、インターフェイスＳ１ｕを介して通信する。Ｓ１−ＭＭＥインターフェイスが、ＥＵＴＲＡＮとＭＭＥとの間の制御プレーンプロトコルのための基準点である。この基準点を越えるプロトコルは、Ｓ１−ＡＰであり、伝送プロトコルとしてストリーム制御転送プロトコル（ＳＣＴＰ）を使用する。Ｓ１ｕインターフェイスが、ハンドオーバの際のベアラ当たりのユーザプレーン・トンネリングおよびｅＮＢ間経路スイッチングのためのＥＵＴＲＡＮとＳＧＷとの間の基準点である。Ｓ１ｕインターフェイスを介する伝送プロトコルは、ＧＰＲＳトンネリングプロトコル−ユーザプレーン（ＧＴＰ−Ｕ）である。

本明細書に開示される技術は、その態様のうちの１つにおいて、電気通信ネットワークの動作方法に関し、いくつかの例示的な実施形態において、特にバックホールリンクの少なくとも一部分におけるヘッダ圧縮の使用をネゴシエートするためのモビリティ管理エンティティ（ＭＭＥ）２６の動作方法に関する。この点に関し、図１は、モビリティ管理エンティティ（ＭＭＥ）２６がバックホールリンク４２の少なくとも一部分におけるヘッダ圧縮（ＨＣ）の使用のネゴシエーションを実行するネゴシエーション行為４０をさらに示している。本明細書において使用されるとき、バックホールリンク４２は、基地局ノード２８をサービングゲートウェイ（ＳＧＷ）２４へと接続するシグナリングリンクを包含し、したがって進化型パケットコア（ＥＰＣ）２０内のシグナリングリンクおよび進化型パケットコア（ＥＰＣ）２０へと向かうシグナリングリンクを含む。すなわち、バックホールリンク４２は、基本的には、電気通信ネットワークのサービング・ゲートウェイ・ノード２４と基地局ノード２８との間を延びている。

図２は、バックホールリンク上のヘッダ圧縮をネゴシエートするネゴシエーション行為４０の実行の例示的な実施形態および態様における例示的なシグナリングを示している。図２において、行為２−３として、サービングゲートウェイ（ＳＧＷ）２４が、ヘッダ圧縮同意通知４４を含むメッセージ（行為２−３のメッセージ）を送信し、このメッセージが、モビリティ管理エンティティ（ＭＭＥ）２６によって受信される。ヘッダ圧縮同意通知４４は、サービングゲートウェイ（ＳＧＷ）２４がヘッダ圧縮可能であり、バックホールリンク４２上のヘッダ圧縮を許すことを望んでいる旨を示している。通知４４は、例えば、新規または既存のメッセージの情報要素であってもよい。

ネゴシエーション処理行為４０−１として、モビリティ管理エンティティ（ＭＭＥ）２６が、ヘッダ圧縮同意通知４４を処理する。例示的な実施態様においては、行為４０−１の部分行為が、ヘッダ圧縮同意通知４４を分析するステップと、モビリティ管理エンティティ（ＭＭＥ）２６がサービングゲートウェイ（ＳＧＷ）２４に関する何らかのポリシーを有しているかを判断するステップと、基地局ノード２８へと送信されるメッセージにヘッダ圧縮同意通知４４の通知を含ませることを決定するステップとを含む。この最後の部分行為の結果として、図２の行為２−４は、モビリティ管理エンティティ（ＭＭＥ）２６がモビリティ管理エンティティ（ＭＭＥ）２６から基地局ノード２８へと送信されるメッセージ（行為２−４のメッセージ）にヘッダ圧縮提案４６を含ませるステップを含む。

処理行為４８として、基地局ノード２８は、行為２−４のメッセージにて届けられるヘッダ圧縮提案４６を処理する。処理行為４８の一部として、基地局ノード２８は、基地局ノード２８が処理行為４２におけるヘッダ圧縮に関与できるかどうか、および関与を望むかどうかを判断する。そのような判断の後で、行為２−７として、基地局ノード２８は、新規または既存のメッセージの情報要素であってもよいヘッダ圧縮承認通知５０を返す。行為２−７のメッセージのヘッダ圧縮承認通知５０は、基地局ノード２８がバックホールリンク４２におけるヘッダ圧縮への参加に同意するか否かを知らせている。

ネゴシエーション決定行為４０−２として、モビリティ管理エンティティ（ＭＭＥ）２６は、ヘッダ圧縮承認通知５０を先に受信したヘッダ圧縮同意通知４４に照らして処理し、バックホールリンク４２においてヘッダ圧縮を実行すべきかどうかについての決定を行う。ネゴシエーション決定行為４０−２に従って、行為２−１０として、モビリティ管理エンティティ（ＭＭＥ）２６は、サービングゲートウェイ（ＳＧＷ）２４へとメッセージ（行為２−１０のメッセージ）を送信する。行為２−１０のメッセージは、ヘッダ圧縮が実際にバックホールリンク４２において試みられることを知らせる開始通知５２を含む。開始通知５２は、新規または既存のメッセージの情報要素であってもよい。

このように、図２の筋書きから理解されるとおり、例示的な態様および実施形態において、ネゴシエーション行為４０（すなわち、ヘッダ圧縮の使用をネゴシエートする行為）は、（１）サービング・ゲートウェイ・ノードがヘッダ圧縮の使用に同意するかどうかを確認するステップ（例えば、ヘッダ圧縮同意通知４４の受信を承けてネゴシエーション処理行為４０−１を実行する）ステップと、（２）基地局ノードがヘッダ圧縮の使用に同意するかどうかを確認するステップ（例えば、ヘッダ圧縮承認通知５０の処理としてネゴシエーション決定行為４０−２に含まれる）と、（３）バックホールリンクにおいてヘッダ圧縮を実行するかどうかを判断するために（１）および（２）の確認を使用するステップ（ネゴシエーション決定行為４０−２に含まれる）とを含む。

図３を参照して理解されるとおり、ヘッダ圧縮初期化時間を節約するために、利用可能なプロファイルなどのヘッダ圧縮のさらなるパラメータを送信することも可能である。これは、ＴＥＩＤの交換の前にいかなるパケットもＧＴＰ接続上を移動することがないがゆえに可能である。

上記の件に関し、図３は、バックホールリンク上のヘッダ圧縮をネゴシエートする方法におけるシグナリングの別の例示的な実施形態および態様を示しており、特にバックホールリンクにおけるヘッダ圧縮の使用をネゴシエートするためのシグナリングにヘッダ圧縮初期化パラメータを含ませることを示している。図３は、図２の例示的な行為を含むが、行為２−３のメッセージが、ヘッダ圧縮同意通知４４に加えて、バックホールリンクにおけるヘッダ圧縮の使用に関してサービングゲートウェイ（ＳＧＷ）２４が提案する１つまたは複数の提案ヘッダ圧縮初期化パラメータ５４をさらに含むことも示している。図３は、モビリティ管理エンティティ（ＭＭＥ）２６から基地局ノード２８へと送信される行為２−４のメッセージが、ヘッダ圧縮に関してサービングゲートウェイ（ＳＧＷ））２４によって提案されたヘッダ圧縮初期化パラメータの通知５６をさらに含むことも示している。さらに図３は、基地局ノード２８からモビリティ管理エンティティ（ＭＭＥ）２６へと送信される行為２−７のメッセージが、提案されたヘッダ圧縮初期化パラメータへの基地局ノードの応答５８をさらに含むことを示している。モビリティ管理エンティティ（ＭＭＥ）２６によってネゴシエートされて同意されたと判断されたヘッダ圧縮初期化パラメータを、行為２−１０のメッセージにてモビリティ管理エンティティ（ＭＭＥ）２６によってサービングゲートウェイ（ＳＧＷ）２４へと供給される開始通知５２に含ませることができる。

提案されるヘッダ圧縮初期化パラメータ５４として含まれるヘッダ圧縮初期化パラメータ情報、サービングゲートウェイ（ＳＧＷ）によって提案されるヘッダ圧縮初期化パラメータの通知５６、提案されたヘッダ圧縮初期化パラメータへの応答５８、ならびにモビリティ管理エンティティ（ＭＭＥ）２６によってネゴシエートされて同意されたと判断されたヘッダ圧縮初期化パラメータの仕様を、例えば、行為２−３、２−４、２−７、および２−１０のそれぞれのメッセージによってそれぞれ反映される新規または既存のメッセージの１つまたは複数の情報要素に含ませることができる。

したがって、図３から見られるように、例示的な態様および実施形態において、ヘッダ圧縮の使用のネゴシエーションは、（１）サービング・ゲートウェイ・ノードからヘッダ圧縮初期化パラメータ（例えば、ヘッダ圧縮初期化パラメータ５４によって示されているとおり）を入手するステップと、（２）ヘッダ圧縮初期化パラメータに関する基地局ノードからの応答（提案されたヘッダ圧縮初期化パラメータに対する基地局ノードの応答５８によって示されるとおり）を入手するステップと、（３）バックホールリンクにおいてヘッダ圧縮を実行するかどうかを判断（例えば、ネゴシエーション決定行為４０−２のとおり）するために行為（２）の応答を使用するステップとをさらに含む。

図４および図５が、図２および図３のようなシグナリングの例示的な実施形態および態様を、どのようにして従来からのベアラ確立手順に取り入れることができるのかについて、例示的な様相で示している。特に、図４が、ここでの言及によって本明細書に援用される３ＧＰＰ ＴＳ ２３．４０１ Ｖ９．２．０（２００９−０９），３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ；Ｔｅｃｈｎｉｃａｌ Ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｇｒｏｕｐ Ｓｅｒｖｉｃｅｓ ａｎｄ Ｓｙｓｔｅｍ Ａｓｐｅｃｔｓ；Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｅｒｖｉｃｅ （ＧＰＲＳ） ｅｎｈａｎｃｅｍｅｎｔｓ ｆｏｒ Ｅｖｏｌｖｅｄ Ｕｎｉｖｅｒｓａｌ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ（Ｅ−ＵＴＲＡＮ） ａｃｃｅｓｓ（Ｒｅｌｅａｓｅ ９）に記載のベアラ確立手順の行為の文脈におけるネゴシエーション処理行為４０−１およびネゴシエーション決定行為４０−２（集合的にネゴシエーション行為４０を構成する）の発生を示している。

そのような説明に対応するために、図４は、進化型パケットコア（ＥＰＣ）２０が、パケット・データ・ネットワーク（ＰＤＮ）ゲートウェイ（ＰＤＮ ＧＷ）およびポリシー／課金ルール機能（ＰＣＲＦ）の両方を備えることをさらに示している。ＰＤＮ ＧＷは、無線端末（ＵＥ）のためのトラフィックの出入りの点になることによって、無線端末（ＵＥ）に外部のパケット・データ・ネットワークへの接続を提供する。無線端末（ＵＥ）は、複数のＰＤＮにアクセスするために２つ以上のＰＤＮ ＧＷに同時に接続することができる。ＰＤＮ ＧＷは、ポリシーの行使、それぞれのユーザについてのパケットフィルタリング、課金のサポート、合法的傍受、およびパケットスクリーニングを実行する。ＰＤＮ ＧＷの他の役目は、３ＧＰＰとＷｉＭＡＸなどの非３ＧＰＰ技術との間のモビリティのためのアンカとして機能することにある。

図４に示され、図５に関して理解することもできる実施例においては、サービングゲートウェイ（ＳＧＷ）２４が、サービングゲートウェイ（ＳＧＷ）２４のヘッダ圧縮の実行可否および要望を通知する目的のために、行為４−３のメッセージに新たな情報要素を加える（図３のヘッダ圧縮初期化パラメータ５４によって示される様相で、ヘッダ圧縮の初期化に必要とされるパラメータとともに）。モビリティ管理エンティティ（ＭＭＥ）２６は、ｅＮｏｄｅＢ（例えば、基地局ノード２８）がヘッダ圧縮をサポートしないことを知っている場合、またはこのベアラについてヘッダ圧縮を適用しないというポリシー決定が存在する場合に、この通知を無視する。ヘッダ圧縮が所望され、サービングゲートウェイ（ＳＧＷ）２４がそのような新規な情報要素を含ませている場合には、モビリティ管理エンティティ（ＭＭＥ）２６は、その要素を行為４−４のメッセージに含ませる。

基地局ノード２８もヘッダ圧縮を行うことが可能であり、ヘッダ圧縮を行うことを望んでおり、かつ提案された初期化パラメータが基地局ノード２８に適合している場合、基地局ノード２８も、基地局ノード２８がヘッダ圧縮を実行可能であってヘッダ圧縮を望んでいる旨を通知する新規な情報要素を、行為４−７のメッセージに（ＴＥＩＤとともに）含ませる。さらに、行為４−７のメッセージに、基地局ノード２８は、サービングゲートウェイ（ＳＧＷ）２４によって提案された初期化パラメータへの自身の応答を含ませることができる（図３の情報要素アップリンク信号プロセッサ５８によって示される様相で）。この時点で、ヘッダ圧縮を行う旨の決定が行われる。そのような決定は、行為４０−２によって反映される。モビリティ管理エンティティ（ＭＭＥ）２６は、応答を受信すると、このベアラにヘッダ圧縮が適用される旨を記録し、基地局ノード２８によって送信された新規な情報要素を行為４−１０のメッセージに含ませることで、サービングゲートウェイ（ＳＧＷ）２４にヘッダ圧縮の開始について知らせる。

モビリティ管理エンティティ（ＭＭＥ）２６は、シグナリングの中間に位置しているため、他端がヘッダ圧縮をサポートしないことを知っている場合、またはこのベアラについてヘッダ圧縮を実行しないというポリシー決定が存在する場合に、これらの信号を変更することができる。

図４によって示されるとおり、行為４−３のメッセージは、行為２−３のメッセージに相当するが、この特定の実施例においては、サービングゲートウェイ（ＳＧＷ）２４からモビリティ管理エンティティ（ＭＭＥ）２６へと送信される専用ベアラ要求メッセージとして知られるメッセージを含む。行為４−４のメッセージは、行為２−４のメッセージに相当するが、この特定の実施例においては、モビリティ管理エンティティ（ＭＭＥ）２６から基地局ノード２８へと送信されるベアラ設定要求／セッション管理要求メッセージとして知られるメッセージを含む。行為４−７のメッセージは、行為２−７のメッセージに相当するが、この特定の実施例においては、ベアラ設定応答メッセージとして知られるメッセージを含む。行為４−１０のメッセージは、行為２−１０のメッセージに相当するが、この特定の実施態様においては、専用ベアラ応答メッセージとして知られるメッセージを含む。

図５は、図３に似ているが、３ＧＰＰ ＴＳ ２３．４０１ Ｖ９．２．０（２００９−０９）の例示的な実施態様に従ってメッセージに名前が割り当てられている。

図２〜図５の以上の説明は、主として専用ベアラ確立手順の文脈において提示されているが、（図６によって示されるように）アタッチ手順、ハンドオーバ手順、またはベアラが確立されるべき他の手順にも当てはまる。

図７は、バックホールリンク上のヘッダ圧縮のネゴシエーションを実行するように構成されたモビリティ管理エンティティ２６の例示的な実施形態を示している。モビリティ管理エンティティ（ＭＭＥ）２６は、ネゴシエータ６０（ネゴシエーション機能またはネゴシエーションユニットとしても知られる）を備えている。ネゴシエータ６０は、コンピュータ、プロセッサ、またはコントローラ（これらの用語は、本明細書において拡張的に説明されているため）の形態をとることができ、したがって実行時に本明細書に記載の方法の各行為を実行するインストラクションを電磁気媒体に保存して含むコンピュータプログラム製品を実行することができる。ネゴシエータ６０は、（モビリティ管理エンティティ（ＭＭＥ）２６をＳ１１インターフェイスを介してサービングゲートウェイ（ＳＧＷ）２４へと接続する）ＳＧＷインターフェイスユニット６２と（モビリティ管理エンティティ（ＭＭＥ）２６をＳ１−ＭＭＥインターフェイスを介して基地局ノード２８へと接続する）ｅＮＢインターフェイスユニット６４との間に接続されている。

図７に示されているようなモビリティ管理エンティティ（ＭＭＥ）２６が、ＬＴＥアクセスネットワークのための制御ノードであり、多数の機能を有する（図７にはそのような機能に対応するユニットまたは機能が必ずしもすべて示されているわけではない）ことを、理解されよう。例えば、モビリティ管理エンティティ（ＭＭＥ）２６は、再伝送を含むアイドルモードのＵＥのトラッキングおよびページングの処理を担当する。モビリティ管理エンティティ（ＭＭＥ）２６は、ベアラの有効化／無効化プロセスに関与し、初期の参加およびコアネットワーク（ＣＮ）ノード再配置を含むＬＴＥ内ハンドオーバのときに、無線端末（ＵＥ）のためのＳＧＷの選択も担当する。モビリティ管理エンティティ（ＭＭＥ）２６は、（ＨＳＳとの相互作用によって）ユーザの認証を担当する。非アクセス層（ＮＡＳ）のシグナリングは、モビリティ管理エンティティ（ＭＭＥ）２６において終了し、モビリティ管理エンティティ（ＭＭＥ）２６は、無線端末（ＵＥ）へのテンポラリＩＤの生成および割り当ても担当する。モビリティ管理エンティティ（ＭＭＥ）２６は、サービスプロバイダの好適地域モバイルネットワーク（ＰＬＭＮ）に陣取り、無線端末（ＵＥ）のローミングの制約を行使するために、無線端末（ＵＥ）の権限をチェックする。モビリティ管理エンティティ（ＭＭＥ）２６は、ＮＡＳ信号の暗号化／完全性保護のためのネットワークの終端点であり、セキュリティキーの管理を取り扱う。信号の合法的傍受も、モビリティ管理エンティティ（ＭＭＥ）２６によってサポートされる。さらに、モビリティ管理エンティティ（ＭＭＥ）２６は、ＬＴＥと２Ｇ／３Ｇアクセスネットワークとの間のモビリティのための制御プレーン機能に、ＳＧＳＮからモビリティ管理エンティティ（ＭＭＥ）２６で終端するＳ３インターフェイスを提供する。また、モビリティ管理エンティティ（ＭＭＥ）２６は、ＵＥのローミングのためのホームＨＳＳへと向かうＳ６ａインターフェイスも終端する。

これまでは、ヘッダ圧縮が、無線インターフェイス（基地局ノード２８とサービングゲートウェイ（ＳＧＷ）２４との間）または無線リンク（基地局ノード２８とサービングゲートウェイ（ＳＧＷ）２４との間）を含まないバックホールリンクにおいて生じる実施形態および態様を説明した。上述した実施形態および態様のヘッダ圧縮技法は、多数の特徴および利点を有している。

伝送汎用パケット無線サービス・トンネリング・プロトコル（ＧＴＰ）トンネルの内部におけるヘッダ圧縮は、セルフバックホーリングとも称される中継の場合においてさらに重要になる。中継においては、中継装置（すなわち、セルフバックホーリングされるｅＮＢ）のバックホール接続が、無線インターフェイスを介してもたらされる。中継の場合には、汎用パケット無線サービス・トンネリング・プロトコル（ＧＴＰ）トンネルが、リソースに乏しいバックホール無線インターフェイスを横切る。中継ノードおよびセルフバックホーリングのリンクを既存のＬＴＥプロトコルおよびネットワークアーキテクチャに一体化させるためのさまざまなアーキテクチャの解決策が存在する。例えば、本出願と同じ譲受人に譲渡済みであり、その内容が考えられる選択肢に関してここでの言及によって本明細書に援用される２００９年９月９日付の「ＳＥＬＦ−ＢＡＣＫＨＡＵＬＩＮＧ ＩＮ ＬＴＥ」という名称の国際出願ＰＣＴ／ＳＥ２００８／０５１００４号明細書を参照されたい。中継ノードへのＧＴＰトンネルがセルフバックホーリングの無線リンクを介して転送され、すなわち追加のＧＴＰ／ＵＤＰ／ＩＰオーバーヘッド・アウタヘッダが、エンドユーザＩＰインナヘッダとともに使用されることが、これらの技術的解決策に共通である。バックホール無線リンクのレガシーＰＤＣＰ層は、アウタヘッダだけしか圧縮することができず、インナヘッダは圧縮されないままである。

図８は、ＧＴＰトンネルの内部のヘッダ圧縮を含む一般的な中継の使用の事例を示している。図８によって示されるとおりの一般的事例は、中継ノード（セルフバックホーリングｅＮｏｄｅＢとも称される）がＬＴＥ無線インターフェイスを介してネットワークへと接続される中継またはセルフバックホーリングの場合に重要になる可能性がある。用語「中継ノード」および「中継基地局」は、本明細書において互いに交換可能に使用される。図８は、モビリティ管理エンティティ（ＭＭＥ）２６と基地局ノード２８との間に配置されたドナー基地局ノード７０（ＤｅＮＢ）が含まれ、ドナー基地局ノード７０が無線インターフェイス３２を介して基地局ノード２８と通信することを示している。

したがって、図８は、バックホールリンクが無線リンクを含む場合にバックホールリンクにおけるヘッダ圧縮をネゴシエートすることを含む本明細書に開示の技術の実施形態、モード、および態様を一般的に示している。以下で、ＬＴＥアーキテクチャへの中継の統合の２つの非限定的で例示的なアーキテクチャの事例／選択肢におけるバックホールリンクの例示的なヘッダ圧縮の使用を説明する。

図８Ａは、全第３層（Ｌ３）中継、すなわちベアラカプセル化手法に対応する第１の例示的な中継アーキテクチャの技術的解決策を示している。図８Ａの全Ｌ３中継のアーキテクチャの選択肢（ベアラカプセル化手法）のヘッダ圧縮機能に注目した簡単なプロトコルスタックが、図９Ａに示されている。

ＵＥベアラに対応する汎用パケット無線サービス・トンネリング・プロトコル（ＧＴＰ）トンネルが、無線端末（ＵＥ）３０に仕えるサービングゲートウェイ（ＳＧＷ）２４から中継ノード２８まで延びている（ドナーｅＮＢ７０を介して透過的に進んでいる）ことが、図９Ａのアーキテクチャの選択肢に特有である。したがって、トンネルのエンドポイントは、サービングゲートウェイ（ＳＧＷ）２４および中継装置（基地局ノード２８）に位置し、すなわち汎用パケット無線サービス・トンネリング・プロトコル（ＧＴＰ）トンネルの内部における追加のヘッダ圧縮器が、図９Ａに示されるように中継装置（基地局ノード２８）およびサービングゲートウェイ（ＳＧＷ）２４に配置される。基地局ノード２８およびサービングゲートウェイ（ＳＧＷ）２４の内部の追加の圧縮器は、図９Ａにおいてプロトコル要素「ＨＣ／ＰＤＣＰ」によって反映されている。これらの圧縮器は、コンピュータによって実現される圧縮ユニットまたは機能の形態をとることができる。

図９Ａの全Ｌ３中継技法において、レガシーＰＤＣＰ層が、ＵＤＰ／ＩＰヘッダを圧縮する。すなわち、バックホールリンクにおけるパケット・データ・コンバージェンス・プロトコル（ＰＤＣＰ）層が、ＬＴＥにおけるレガシーＰＤＣＰプロトコルに相当し、中継ノード（中継基地局）２８とドナー基地局ノード７０との間のＧＴＰパケットのユーザ・データグラム・プロトコル／インターネットプロトコル（ＵＤＰ／ＩＰ）ヘッダの圧縮を実行することができる。しかしながら、今必要なのは、ＧＴＰヘッダの圧縮ではなく、ＧＴＰトンネルの内部で運ばれるパケットのＩＰヘッダまたは「インナヘッダ」の圧縮である。ＴＣＰ／ＵＤＰ／ＩＰインナヘッダが、サービングゲートウェイ（ＳＧＷ）２４および基地局ノード２８の上述の「ＨＣ／ＰＤＣＰ」圧縮器によって圧縮される。

サービングゲートウェイ（ＳＧＷ）２４および中継ノード（基地局ノード２８）のヘッダ圧縮器は、例えばノードのプロトコルスタックの新たな層である必要はなく、該当のノードにおけるヘッダ圧縮器状態機械であってもよい。あるいは、ヘッダ圧縮を、いくつかの追加の情報フィールドを運ぶ必要がある場合には、新たな「薄い」ＰＤＣＰ層として実現してもよい。サービングゲートウェイ（ＳＧＷ）２４および中継ノード（ＲＮ）のヘッダ圧縮器の設定を、先の一般的な事例について説明したように、サービングゲートウェイ（ＳＧＷ）２４から実行することができる。ヘッダ圧縮器の設定は、随意によるパラメータの交換を含む本明細書に記載のネゴシエーションプロセスを含む。

したがって、図８Ａおよび図９Ａの例示的な態様および実施形態においては、バックホールリンクが、サービング・ゲートウェイ・ノード（２４）と中継基地局ノード（基地局ノード２８）との間の汎用パケット無線サービス・トンネリング・プロトコル（ＧＴＰ）トンネルを含む。汎用パケット無線サービス・トンネリング・プロトコル（ＧＴＰ）トンネルは、中継基地局ノード２８とドナー基地局ノード７０との間の無線インターフェイス３２を横切っている。そのような例示的な態様および実施形態において、本方法は、汎用パケット無線サービス・トンネリング・プロトコル（ＧＴＰ）トンネルの内部におけるヘッダ圧縮の使用をネゴシエートするために、サービング・ゲートウェイ・ノード２４と中継基地局ノード７０との間のシグナリングを取り扱うステップをさらに含む。

第２非限定的で、例示的な中継アーキテクチャの技術的解決策は、図８Ｂに示されるようなやり方でプロキシ手法を使用する。プロキシ中継アーキテクチャの手法の場合のプロトコルスタックが、図９Ｂに示されている。第１のトンネル（ＧＴＰトンネルとして知られる）が、サービングゲートウェイ（ＳＧＷ）２４からドナーｅＮＢ７０まで延び、別の（例えば、第２の）トンネルが、ドナーｅＮＢ７０から中継装置（例えば、基地局ノード２８）まで使用される。トンネルスイッチングが、ドナーｅＮＢ７０において行われる。トンネルスイッチングは、１つのトンネルが終わり、別の（第２の）トンネルに続き、この第２のトンネルが別のトンネル識別子（トンネルＩＤ）を有しており、第１のトンネルから第２のトンネルへの切り替えが生じることを意味する。２つの別々のトンネル、すなわちサービングゲートウェイ（ＳＧＷ）２４とドナーｅＮＢ７０との間の１つの（第１の）トンネル、およびドナーｅＮＢ７０と中継装置（例えば、基地局ノード２８）との間の別の（第２の）トンネルを有することで、第２のトンネルおいてのみヘッダ圧縮が所望される実施態様において、ドナーｅＮＢ−中継装置のリンク（例えば、基地局ノード２８とドナー基地局ノード７０との間のリンク）についてのみ追加のヘッダ圧縮を使用することができる。好都合なことに、第２のトンネルにおいてのみヘッダ圧縮を有するこの実施態様は、サービングゲートウェイ（ＳＧＷ）２４を変更せずにそのままにする（すなわち、レガシーＳＧＷノードにヘッダ圧縮のサポートを追加する必要がない）。しかしながら、他の実施態様においては、随意により、ＳＧＷからドナー基地局ノードｅＮＢ７０までの第１のトンネルにも、すなわち先の事例のようにＳＧＷと中継装置との間（図８Ｂに破線で示されているとおり）にも、追加のヘッダ圧縮を展開することができる（第２のトンネルにおけるヘッダ圧縮に加えて、随意により第１のトンネルにおいても採用することができる）。

したがって、図８Ｂおよび図９Ｂに関して説明されるような例示的な態様および実施形態においては、バックホールリンクが、サービング・ゲートウェイ・ノードとドナー基地局ノードとの間の第１のトンネル（例えば、汎用パケット無線サービス・トンネリング・プロトコル（ＧＴＰ）トンネル）およびドナー基地局ノードと中継基地局との間を延びるさらなる（例えば、第２の）トンネルを含む。第２のトンネルもＧＴＰトンネルであってよいが、図８Ｂおよび図９Ｂの実施形態においては、本明細書において特に指定されない限り、「汎用パケット無線サービス・トンネリング・プロトコル（ＧＴＰ）トンネル」という呼称は、第１のトンネル、すなわちサービング・ゲートウェイ・ノードとドナー基地局ノードとの間のトンネルを指している。第２のトンネルは、中継基地局ノードとドナー基地局ノードとの間の無線インターフェイスを横切っている。図８Ｂおよび図９Ｂの実施形態において、本方法は、第２のトンネルの内部におけるヘッダ圧縮の使用をネゴシエートするために、ドナー基地局ノードと中継基地局ノード７０との間のシグナリングを取り扱うステップをさらに含み、さらに随意により、第１のトンネル（例えば、汎用パケット無線サービス・トンネリング・プロトコル（ＧＴＰ）トンネル）の内部におけるヘッダ圧縮の使用をネゴシエートするために、サービング・ゲートウェイ・ノードとドナー基地局ノードとの間のシグナリングを取り扱うステップを含む。

図８Ａおよび図８Ｂなどの「中継」または「セルフバックホーリング」の事例において、ドナー基地局ノード７０（または、サービングゲートウェイ（ＳＧＷ）２４）ならびに中継基地局ノード２８のヘッダ圧縮器を設定するために使用されるシグナリング機構は、上述した一般的な（中継のない）事例と比べて、わずかな変更を必要とするかもしれない。例えば、図１０に示されるように、モビリティ管理エンティティ（ＭＭＥ）２６と中継装置（例えば、２８）との間のシグナリングも、ドナー基地局ノード７０のプロキシ機能７２を介して届けられる。換言すると、モビリティ管理エンティティ（ＭＭＥ）２６が、一方では（ＳＧＷインターフェイスユニット６２を介して）サービングゲートウェイ（ＳＧＷ）２４と通信し、他方では（インターフェイスユニット６４’を介して）ドナー基地局ノード７０と通信する。モビリティ管理エンティティ（ＭＭＥ）２６およびインターフェイスユニット６４’は、モビリティ管理エンティティ（ＭＭＥ）２６が、中継ノード（基地局ノード２８）に直接にではなく、ドナー基地局ノード７０を介して基地局ノード２８と通信することを理解している。ドナーｅＮＢ（あるいは、プロキシ無しの技術的解決策の場合には通常のｅＮＢ）とサービングＧＷとの間のネゴシエーションは、例えばサービングＧＷおよびドナーｅＮＢがお互いの間で直接シグナリングメッセージを交換するのではなく、ＭＭＥを介して取り扱われる。

図１１は、ＧＴＰトンネルのためのヘッダ圧縮がドナー基地局ノード７０と中継基地局ノード２８との間である事例においてシグナリングを変更できる例示的なやり方を反映している。ヘッダ圧縮のための設定を含むモビリティ管理エンティティ（ＭＭＥ）２６からのＳ１シグナリングメッセージ（図１１において行為２−４ａのメッセージと標記されている図２の行為２−４のメッセージなどのメッセージ）の受信時に、ドナー基地局ノード７０は、行為４８ａとして、自身がモビリティ管理エンティティ（ＭＭＥ）２６によって与えられた設定をサポートできるかどうかを判断する。行為４８ａの一部として、ドナー基地局ノード７０が、Ｓ１メッセージのヘッダ圧縮設定を、（メッセージ２−４ｂによって示されているように）中継基地局ノード２８へと転送する前に変更してもよい。中継基地局ノード２８は、ドナー基地局ノード７０から受信されるＳ１メッセージからヘッダ圧縮設定を取得し、中継基地局ノード２８がこの設定をサポートできるかどうかを（行為４８ｂとして）判断し、（行為２−７ａのメッセージによって示されているとおりに）相応に応答する。中継基地局ノード２８からの応答にもとづき、ドナー基地局ノード７０は、行為４８ｃとして、適用するヘッダ圧縮設定を変更する必要があるかもしれない。このようにして、ドナー基地局ノード７０は、行為２−７ｂとして、応答をモビリティ管理エンティティ（ＭＭＥ）２６に向けて送信する。

いくつかの例示的な実施形態および様態においては、ヘッダ圧縮の使用を開始すべきかどうかの判断が、ネットワーク設定に関する偶然性に依存することができる。この点に関し、図１２が、下方のトンネルエンドポイント（例えば基地局ノード２８などの基地局ノードなど）と上方のトンネルエンドポイント（例えばサービングゲートウェイ（ＳＧＷ）２４などのサービングゲートウェイ（ＳＧＷ）など）との間のバックホールリンクにおいてヘッダ圧縮を実行するかどうかの判断において、モビリティ管理エンティティ（ＭＭＥ）２６のネゴシエータ６０によって実行することができる例示的な工程または行為を示している。

行為１２−１として、ネゴシエータ６０は、上方のトンネルエンドポイント（例えば、ＳＧＷ２４）がヘッダ圧縮をサポートしているかどうか、およびヘッダ圧縮への関与を望んでいるかどうかを判断する。上方のトンネルエンドポイントがヘッダ圧縮をサポートしているかどうか、およびヘッダ圧縮への関与を望んでいるかどうかを示す情報を、例えば行為２−３のメッセージなどのメッセージの情報要素または他のフィールドから得ることができる。上方のトンネルエンドポイントが、ヘッダ圧縮のサポートを提供しておらず、あるいはヘッダ圧縮のサポートに同意しない場合、ネゴシエーションを終了でき、ヘッダ圧縮は実行されない。

行為１２−２は、ネゴシエータ６０が、下方のトンネルエンドポイント（例えば、基地局ノード２８）がヘッダ圧縮をサポートしているかどうか、またはヘッダ圧縮への関与を望んでいるかどうかを判断する。下方のトンネルエンドポイントがヘッダ圧縮をサポートしているかどうか、またはヘッダ圧縮への関与を望んでいるかどうかを示す情報を、例えば行為２−７のメッセージなどのメッセージの情報要素または他のフィールドから得ることができる。下方のトンネルエンドポイントが、ヘッダ圧縮のサポートを提供しておらず、あるいはヘッダ圧縮のサポートに同意しない場合、ネゴシエーションを終了でき、ヘッダ圧縮は実行されない。

行為１２−３は、ネゴシエータ６０が、所定のネットワークの状態または設定のもとでのみヘッダ圧縮を実行するという要件が存在するかどうかをチェックするステップを含む。いかなる特定のネットワーク状態またはネットワーク設定も必要とされない場合、行為１２−４によって示されるとおり、ヘッダ圧縮を設定および開始することができる。しかしながら、ヘッダ圧縮の前提条件として特定のネットワークの状態またはネットワーク設定が求められる場合、ネゴシエータ６０は、行為１２−５として、前提の状態または設定が満たされているかどうかをチェックする。前提の状態または設定が満たされていない場合、ネゴシエーションは終わり、ヘッダ圧縮は実行されない。しかしながら、前提の状態または設定が満たされている場合には、行為１２−６によって示されるとおり、ヘッダ圧縮が開始される。

前提の状態または設定の一例は、バックホールリンクが無線リンクを含むことである。換言すると、例示的な態様および実施形態において、ヘッダ圧縮の使用を開始するかどうかの決定が、バックホールリンクが無線リンクを含むかどうかに依存する。そのような決定のための入力を、例えば運営および管理（Ｏ＆Ｍ）システムによってＭＭＥに設定されるネットワーク設定データから入手でき、または知ることができる。

前提の状態または設定の他の実施例は、バックホールリンクが、所定の値を下回る伝送能力しか有さない伝送リンクを含むことである。すなわち、この他の例示的な態様および実施形態は、バックホールリンクが、所定の値を下回る伝送能力しか有さない伝送リンクを含む場合に、ヘッダ圧縮の使用を開始するステップを含む。ＭＭＥは、運営および管理（Ｏ＆Ｍ）システムがネットワークについての情報を集めており、特定の基地局の場合にヘッダ圧縮に関してＭＭＥを設定するため、バックホールリンクを含むリンクの伝送能力を承知している。

別の態様において、本明細書に開示の技術は、電気通信ネットワークの基地局ノードにおける方法に関する。本方法は、基地局ノードがバックホールリンクの少なくとも一部分におけるヘッダ圧縮の使用について同意が存在するかどうかを（例えば図２の行為４８などによって）判断するステップを含む。本方法は、基地局ノードが、例えば図２の行為２−７のメッセージによって反映されているように、同意を表わすメッセージを送信するステップを含む。

基地局ノードにおける方法の例示的な態様および実施形態は、サービング・ゲートウェイ・ノードによって提案されたヘッダ圧縮初期化パラメータの提案に対する応答をメッセージにてもたらすステップをさらに含む。提案へのそのような応答の実施例は、行為２−７のメッセージのパラメータ提案情報５８への応答である。

基地局ノードにおける方法の例示的な態様および実施形態において、基地局ノードが、中継基地局ノードであり、バックホールリンクが、サービング・ゲートウェイ・ノードと中継基地局ノードとの間を延びる汎用パケット無線サービス・トンネリング・プロトコル（ＧＴＰ）トンネルを含む。汎用パケット無線サービス・トンネリング・プロトコル（ＧＴＰ）トンネルが、中継基地局ノードとドナー基地局ノードとの間の無線インターフェイスを横切っている。基地局ノードにおける方法は、中継基地局ノードからドナー基地局ノードへと汎用パケット無線サービス・トンネリング・プロトコル（ＧＴＰ）トンネルを横切るパケットのＵＤＰ／ＩＰヘッダを圧縮するステップと、サービング・ゲートウェイ・ノードから中継基地局ノードへと汎用パケット無線サービス・トンネリング・プロトコル（ＧＴＰ）トンネルを横切るパケットのＴＣＰ／ＵＤＰ／ＩＰインナヘッドを圧縮するステップとをさらに含む。

一態様において、本明細書に開示の技術は、例えばＧＴＰ−Ｕトンネルの内部のＲＯＨＣチャネルをサポートするために、トンネルの内部においてヘッダ圧縮を実行するためのＧＴＰ−Ｕにおけるサポートを提供する。そのようにするにあたり、ＧＴＰ−Ｕヘッダを圧縮されないままにすることができ、一のヘッダ圧縮のインスタンスが、ＧＴＰ−Ｕトンネルの内部でＩＰヘッダを圧縮すると考えられる一方で、別のインスタンスは、図１５に示されるようにアウタＩＰヘッダを圧縮すると考えられる。例示的な実施態様においては、７６／９６バイト（ＩＰｖ４／ＩＰｖ６を仮定）をおよそ１６バイトへと圧縮することができる（インナおよびアウタの両方のレベルにおいて大きなＣＩＤ空間およびＵＤＰチェックサムが使用されると仮定）。ＭＭＥがＧＴＰトンネルの確立を調整し、Ｓ１−ＡＰがｅＮＢへのＧＴＰトンネルの設定に使用され、ＧＴＰ−ＣがサービングＧＷ（Ｓ１１）に向けて使用されることを認識することで、この実施態様は、ＧＴＰ−Ｕにおけるヘッダ圧縮の設定のサポートをＳ１手順およびＧＴＰ−Ｃ手順に追加することを必要とする。これは、該当のインターフェイスにおけるＲＯＨＣパケットのパケット種類の追加しか必要としない（例えば、ＧＴＰメッセージ種類フィールドにおいて新たなパケット種類ＩＤを使用する）。一方向の圧縮に加え、双方向の圧縮（すなわち、フィードバックの使用）が可能であるか否かなどの他の考慮事項も、検証されるべきである（ＥＰＳベアラは双方向である）。ＧＴＰトンネルの内部のヘッダ圧縮のサポートを指定することは、ＧＴＰ−ＣおよびＳ１−ＡＰ手順の変更を必要とする（したがって、ＲＡＮ３を必要とする）。他の態様は、既存のヘッダ圧縮の実施態様を再使用する可能性である。

本出願に開示の技術の例示的な利点の一部として、（１）高価なＳ１バックホールリンクを介するＧＴＰトンネルの内部のヘッダ圧縮の上位互換な設定、（２）非サポートの機器の場合またはエンドの１つがヘッダ圧縮リソースを使い尽くした場合のシームレスなフォールバック、（３）ベアラ当たりの基準にもとづく混合モードの使用、および（４）Ｓ１リンクそのものをＬＴＥ無線インターフェイスを介して運ぶことができる場合にＬＴＥ中継用途における高い有用性が挙げられる。

上述の説明は、多数の特定性を含むが、それらを本発明の技術的範囲を限定するものと解釈してはならず、あくまでも本発明の現時点において好ましい実施形態のうちのいくつかについての説明を提示しているにすぎないと解釈すべきである。したがって、本発明の技術的範囲が、当業者にとって自明となりうる他の実施形態を完全に包含すること、および本発明の技術的範囲が相応に過度に限定されることを、理解されよう。単数形での構成要素への言及は、特にそのようでないと述べられない限りは、「ただ１つだけ」を意味するものではなく、「１つまたは複数」を意味するものである。当業者に知られている上述の好ましい実施形態の構成要素のあらゆる構造的、化学的、および機能的な均等物は、本明細書に包含される。さらに、装置および方法は、必ずしも本発明が解決しようとするすべての課題に対処していなくても、本明細書に包含される。

Claims (14)

1. 電気通信ネットワークにおいてヘッダ圧縮を管理する方法であって、
   バックホールリンク（４２）の少なくとも一部分におけるヘッダ圧縮の使用をネゴシエートするステップであって、前記バックホールリンク（４２）は、（ｉ）第１のトンネル識別子を有し、前記電気通信ネットワークのサービング・ゲートウェイ・ノード（２４）とドナー基地局ノード（７０）との間を延びる第１のトンネルと、（ｉｉ）第２のトンネル識別子を有し、前記ドナー基地局ノード（７０）と中継基地局ノード（２８）との間を延びる第２のトンネルとを含み、前記第２のトンネルが、前記中継基地局ノード（２８）と前記ドナー基地局ノード（７０）との間の無線インターフェイスを横切り、
   モビリティ管理エンティティ（２６）において第１のシグナリングメッセージを受信するステップであって、前記第１のシグナリングメッセージは、前記サービング・ゲートウェイ・ノード（２４）がヘッダ圧縮の使用に同意するかどうかを示す、ステップと、
   前記モビリティ管理エンティティ（２６）において第２のシグナリングメッセージを受信するステップであって、前記第２のシグナリングメッセージは、前記ドナー基地局ノード（７０）がヘッダ圧縮の使用に同意するかどうかを示す、ステップと、
   を含む、ネゴシエートするステップと、
   前記ドナー基地局ノード（７０）において、前記第１のトンネルを介して送信されるパケットを受信するステップであって、受信したパケットはアウタ・インターネット・プロトコル（ＩＰ）・ヘッダとインナＩＰヘッダを含む、ステップと、
   前記ドナー基地局ノード（７０）がヘッダ圧縮の使用に同意する場合に、前記ドナー基地局ノード（７０）が、前記パケットの前記インナＩＰヘッダを圧縮するステップと、および、
   前記中継基地局ノード（２８）へ前記パケットを送信するために、前記ドナー基地局ノード（７０）が、前記第１のトンネルから前記第２のトンネルへ切り替えるステップと、
   を含む方法。
2. サービング・ゲートウェイ・ノード（２４）、ドナー基地局ノード（７０）と、中継基地局ノード（２８）とを含む電気通信ネットワークの動作方法であって、
   前記電気通信ネットワークの前記サービング・ゲートウェイ・ノード（２４）と前記中継基地局ノード（２８）との間を延びるバックホールリンク（４２）の少なくとも一部分におけるヘッダ圧縮の使用をネゴシエートするステップであって、前記バックホールリンク（４２）は、（ｉ）第１のトンネル識別子を有し、前記電気通信ネットワークの前記サービング・ゲートウェイ・ノード（２４）と前記ドナー基地局ノード（７０）との間を延びる第１のトンネルと、（ｉｉ）第２のトンネル識別子を有し、前記ドナー基地局ノード（７０）と前記中継基地局ノード（２８）との間を延びる第２のトンネルとを含み、前記第２のトンネルが、前記中継基地局ノード（２８）と前記ドナー基地局ノード（７０）との間の無線インターフェイスを横切り、
   前記サービング・ゲートウェイ・ノード（２４）がヘッダ圧縮の使用に同意するかどうかを、モビリティ管理エンティティ（２６）が確認するために、前記サービング・ゲートウェイ・ノード（２４）から前記モビリティ管理エンティティ（２６）へのシグナリングメッセージを使用する、ステップと、および、
   前記ドナー基地局ノード（７０）がヘッダ圧縮の使用に同意するかどうかを、前記モビリティ管理エンティティ（２６）が確認するために、前記ドナー基地局ノード（７０）から前記モビリティ管理エンティティ（２６）へのシグナリングメッセージを使用する、ステップと、
   を含む、ヘッダ圧縮の使用をネゴシエートするステップと、
   前記ドナー基地局ノード（７０）において、前記第１のトンネルを介して送信されるパケットを受信するステップであって、受信したパケットはアウタ・インターネット・プロトコル（ＩＰ）・ヘッダとインナＩＰヘッダを含む、ステップと、
   前記ドナー基地局ノード（７０）がヘッダ圧縮の使用に同意する場合に、前記ドナー基地局ノード（７０）が、前記パケットの前記インナＩＰヘッダを圧縮するステップと、および、
   前記中継基地局ノード（２８）へ前記パケットを送信するために、前記ドナー基地局ノード（７０）が、前記第１のトンネルから前記第２のトンネルへ切り替えるステップと、
   を含む方法。
3. ヘッダ圧縮の使用をネゴシエートするステップが、
   （１）前記モビリティ管理エンティティ（２６）が、前記サービング・ゲートウェイ・ノード（２４）がヘッダ圧縮の使用に同意するかどうかを確認するステップと、
   （２）前記モビリティ管理エンティティ（２６）が、前記ドナー基地局ノード（７０）がヘッダ圧縮の使用に同意するかどうかを確認するステップと、および、
   （３）前記モビリティ管理エンティティ（２６）が、（１）および（２）を使用し、前記第１のトンネルにおいて前記ヘッダ圧縮を実施するかどうかを決定するステップと
   を含む請求項１または２に記載の方法。
4. 前記第１のトンネルが、前記サービング・ゲートウェイ・ノード（２４）とドナー基地局ノード（７０）との間の汎用パケット無線サービス・トンネリング・プロトコル（ＧＴＰ）トンネルを含み、ヘッダ圧縮が、ＧＴＰトンネル内を運ばれるパケットに適用される請求項１または２に記載の方法。
5. （ａ）前記モビリティ管理エンティティ（２６）が、前記サービング・ゲートウェイ・ノード（２４）からヘッダ圧縮初期化パラメータを取得するステップと、
   （ｂ）前記モビリティ管理エンティティ（２６）が、前記ヘッダ圧縮初期化パラメータに関する前記ドナー基地局ノード（７０）からの応答を取得するステップと、および、
   （ｃ）前記モビリティ管理エンティティ（２６）が、前記第１のトンネルにおいてヘッダ圧縮を実施するかどうかを決定するために行為（ｂ）の応答を使用するステップと
   をさらに含む請求項１または２に記載の方法。
6. 前記モビリティ管理エンティティ（２６）が、ベアラ確立処理、アタッチ処理、またはハンドオーバ処理のうちのいずれか１つの実行時に前記バックホールリンク（４２）におけるヘッダ圧縮の使用をネゴシエートするステップをさらに含む請求項１または２に記載の方法。
7. 前記第２のトンネルにおけるヘッダ圧縮の使用をネゴシエートするために、前記モビリティ管理エンティティ（２６）が、前記ドナー基地局ノード（７０）と前記中継基地局ノード（２８）との間のシグナリングを取り扱うステップをさらに含む請求項１または２に記載の方法。
8. 前記第１のトンネルにおけるヘッダ圧縮の使用を前記モビリティ管理エンティティ（２６）によってネゴシエートするために、前記モビリティ管理エンティティ（２６）が、前記サービング・ゲートウェイ・ノード（２４）と前記ドナー基地局ノード（７０）との間のシグナリングを取り扱うステップをさらに含む請求項１または２に記載の方法。
9. 前記モビリティ管理エンティティ（２６）が、前記第２のトンネルが無線リンクを含むか判断するステップ、および、
   前記第２のトンネルが無線リンクを含むか判断するステップに応えて、前記第２のトンネルが無線リンクを含む場合に、前記モビリティ管理エンティティ（２６）が、前記第２のトンネルを介してヘッダ圧縮の使用を開始するステップをさらに含む請求項１または２に記載の方法。
10. 前記モビリティ管理エンティティ（２６）が、前記第２のトンネルが所定の値を下回る伝送能力しか有さないか判断するステップ、および、
    前記第２のトンネルが所定の値を下回る伝送能力しか有さないか判断するステップに応えて、前記第２のトンネルが前記所定の値を下回る伝送能力しか有さない場合に、前記モビリティ管理エンティティ（２６）が、前記第２のトンネルを介してヘッダ圧縮の使用を開始するステップをさらに含む請求項１または２に記載の方法。
11. サービング・ゲートウェイ・ノード（２４）と、
    中継基地局ノード（２８）と、
    ドナー基地局ノード（７０）と、および、
    モビリティ管理エンティティ（２６）であって、
    バックホールリンク（４２）においてヘッダ圧縮を使用するかどうかをネゴシエートし、前記バックホールリンク（４２）は、（ｉ）第１のトンネル識別子を有し、前記サービング・ゲートウェイ・ノード（２４）と前記ドナー基地局ノード（７０）との間を延びる第１のトンネルと、（ｉｉ）第２のトンネル識別子を有し、前記ドナー基地局ノード（７０）と前記中継基地局ノード（２８）との間を延びる第２のトンネルとを含み、前記第２のトンネルが、前記中継基地局ノード（２８）と前記ドナー基地局ノード（７０）との間の無線インターフェイスを横切り、
    前記サービング・ゲートウェイ・ノード（２４）がヘッダ圧縮の使用に同意するかどうかを確認するために、前記サービング・ゲートウェイ・ノード（２４）から前記モビリティ管理エンティティ（２６）へのシグナリングメッセージを受信し、および、
    前記ドナー基地局ノード（７０）がヘッダ圧縮の使用に同意するかどうかを確認するために、前記ドナー基地局ノード（７０）から前記モビリティ管理エンティティ（２６）へのシグナリングメッセージを受信するように構成された、前記モビリティ管理エンティティ（２６）と、
    を備える電気通信ネットワークであって、
    前記ドナー基地局ノード（７０）は、前記第１のトンネルを介して送信されるパケットを受信するように構成され、受信したパケットはアウタ・インターネット・プロトコル（ＩＰ）・ヘッダとインナＩＰヘッダを含み、
    前記ドナー基地局ノード（７０）がヘッダ圧縮の使用に同意する場合に、前記ドナー基地局ノード（７０）は、前記パケットの前記インナＩＰヘッダを圧縮するように構成され、および、
    前記ドナー基地局ノード（７０）は、前記中継基地局ノード（２８）へ前記パケットを送信するために、前記第１のトンネルから前記第２のトンネルへ切り替えるように構成される、ネットワーク。
12. 前記モビリティ管理エンティティ（２６）が、さらに、前記第２のトンネルにおけるヘッダ圧縮の使用をネゴシエートするように構成される請求項１１に記載の電気通信ネットワーク。
13. 前記モビリティ管理エンティティ（２６）が、さらに、前記第１のトンネルにおけるヘッダ圧縮の使用をネゴシエートするように構成される請求項１１に記載の電気通信ネットワーク。
14. 前記モビリティ管理エンティティ（２６）が、さらに、ヘッダ圧縮の使用を、前記ドナー基地局ノード（７０）とネゴシエートするように構成される、請求項１１に記載の電気通信ネットワーク。

Images