JP2009005342A

JP2009005342A - 通信ネットワーク内において複数のトンネルを利用する方法

Info

Publication number: JP2009005342A
Application number: JP2008122811A
Authority: JP
Inventors: D Almon Tang; ディ．タンアーモン; Shreesha Ramanna; ラマンナシュリーシャ
Original assignee: Motorola Inc
Current assignee: Motorola Solutions Inc
Priority date: 2007-05-10
Filing date: 2008-05-09
Publication date: 2009-01-08
Also published as: US20080281978A1

Abstract

【課題】通信ネットワークにおける移動イベント中にリアルタイムサービスをよりよくサポートできるようにする。
【解決手段】アクセス端末（ＡＴ）への順方向およびＡＴからの逆方向の両方におけるデータ転送をサポートするために、通信ネットワーク内の異なる複数のネットワークノードを介して複数のトンネルが確立される。順方向のデータ転送は、一定の期間にわたって複数のトンネルのうちの第１のトンネル１４０，１５０を介してサポートされ、逆方向のデータ転送は、同じ期間にわたって第２の異なるトンネル１６０を介してサポートされる。
【選択図】図１

Description

本発明は通信システムに関する。詳細には、本発明は通信ネットワーク内において複数のトンネルを用いることに関する。

様々な無線通信技術が、ＶｏＩＰ（ボイス・オーバ・インターネット・プロトコル）、テレビ電話（ＶｉｄｅｏＴｅｌｅｐｈｏｎｙ）、音声および映像ストリーミングなどのリアルタイムサービスをサポートするために開発されている。移動体装置にそのようなサービスを提供することによって、特に、通信システムを通じて移動し、１つの基地局（ＢＳ）またはアクセス・ネットワーク（ＡＮ）から次のものへとハンドオフを行っている装置について、多くの課題が生まれる。通常、データトンネルは、移動体装置との間のベアラトラフィックを処理するために、サービングＢＳ／ＡＮからデータゲートウェイ装置へと設定される。この経路は、この経路に沿ったアンカーとして作用する複数のネットワークノード、装置またはその両方を含む場合がある。一連のトンネルが、ベアラ経路を提供するために、複数のアンカーの間に確立され得る。移動体装置はシステムを通じてハンドオフを行うので、ベアラ経路は、移動体に付き従うために、新たなトンネルおよびアンカーを確立することによって変更される必要がある。そのようなデータ経路の切替によって、さらなる遅延、途絶またはその両方がリアルタイムサービスに導入され得る。

したがって、当技術を進歩させるためには、移動イベント中にリアルタイムサービスをよりよくサポートすることの可能な新たな技術が明らかに所望される。

様々な実施形態について記載する。それらの実施形態のうちの一部は、通信ネットワークにおける移動イベント中にリアルタイムサービスをよりよくサポートすることが可能である。一般に、それらの実施形態では、アクセス端末（ＡＴ）への順方向およびＡＴからの逆方向の両方におけるデータ転送をサポートするために、通信ネットワーク内の異なる複数のネットワークノードを介して複数のトンネルが確立される。順方向のデータ転送は、一定の期間にわたって複数のトンネルのうちの第１のトンネルを介してサポートされ、逆方向のデータ転送は、同じ期間にわたって第２の異なるトンネルを介してサポートされる。

開示の実施形態は、図１〜１５を参照することによって、より完全に理解され得る。図１は、本発明の様々な実施形態による、複数のトンネルの使用を示すメッセージフロー１００である。現在、ＯＭＡ（ＯｐｅｎＭｏｂｉｌｅＡｌｌｉａｎｃｅ）、３ＧＰＰ（３ｒｄＧｅｎｅｒａｔｉｏｎＰａｒｔｎｅｒｓｈｉｐＰｒｏｊｅｃｔ）、３ＧＰＰ２（３ｒｄＧｅｎｅｒａｔｉｏｎＰａｒｔｎｅｒｓｈｉｐＰｒｏｊｅｃｔ２）、ＩＥＥＥ（ＩｎｓｔｉｔｕｔｅｏｆＥｌｅｃｔｒｉｃａｌａｎｄＥｌｅｃｔｒｏｎｉｃｓＥｎｇｉｎｅｅｒｓ）８０２およびＷｉＭＡＸフォーラムなどの標準機構が、無線通信システム用の標準仕様を開発している（これらの団体には、それぞれ、ｈｔｔｐ：／／ｗｗｗ．ｏｐｅｎｍｏｂｉｌｅａｌｌｉａｎｃｅ．ｃｏｍ，ｈｔｔｐ：／／ｗｗｗ．３ｇｐｐ．ｏｒｇ／，ｈｔｔｐ：／／ｗｗｗ．３ｇｐｐ２．ｃｏｍ／，ｈｔｔｐ：／／ｗｗｗ．ｉｅｅｅ８０２．ｏｒｇ／，ｈｔｔｐ：／／ｗｗｗ．ｗｉｍａｘｆｏｒｕｍ．ｏｒｇ／を介して連絡することができる）。メッセージフロー１００では、一般に、ネットワークノード１〜３をメッセージ送信の端点として示す。ネットワークノード１〜３によって表される通信ネットワークは、本発明を実装するように適切に修正された、３ＧＰＰ２、３ＧＰＰ、ＷｉＭＡＸフォーラム、およびＩＥＥＥ８０２のうちの１つ以上の技術によるアーキテクチャを有するシステムである。

ネットワークノード１〜３については、非常に一般化して示す。図１には通信ネットワークが動作するのに必要であり得る物理的な固定のネットワーク構成要素のすべてが示されているのではなく、本明細書における実施形態の記載に特に関連するシステム構成要素および論理的なエンティティのみが示されていることが、当業者には認められる。例えば、示してはいないが、ネットワークノード１，３は、無線インタフェースを用いて、アクセス端末（ＡＴ）にネットワーク・サービスを提供する。用いられる無線インタフェースは、各々のネットワークノードによってそれぞれサポートされる特定の接続技術による。例えば、それらの無線インタフェースはすべて、３ＧＰＰ２仕様またはＩＥＥＥ８０２．１６に基づく技術など、同じ技術を利用してもよく、異なる複数の接続技術を利用してもよい。

また、図１には、ネットワークノード１〜３が各々、処理装置およびネットワークインタフェースを備えることを示していない。これに加えて、ネットワークノード１，３は各々、無線トランシーバを備える。一般に、処理装置、トランシーバおよびネットワークインタフェースなどの構成要素は周知である。例えば、処理装置が、マイクロプロセッサ、マイクロコントローラ、メモリ装置、特定用途向け集積回路（ＡＳＩＣ）、および論理回路（これらに限定されず、また必ずしも必要ではないが）のうちの１つ以上などの基本的な構成要素を含むことは周知である。そのような構成要素は、通常、高度設計言語もしくは記述、コンピュータ命令、信号／メッセージフロー図、および論理フロー図のうちの１つ以上を用いて表現された、アルゴリズム、プロトコルまたはその両方を実装するように適合されている。

すなわち、高度記述、アルゴリズム、論理フロー、メッセージ／信号フロー、およびプロトコル仕様のうちの１つ以上が与えられれば、当業者には、その与えられた論理を実行する処理装置を実装するために利用可能な多くの設計・開発技術が認識される。したがって、ネットワークノード１〜３は、本明細書の記載にしたがって、本発明の複数の実施形態を実装するように適合された周知の装置を表す。さらに、本発明の態様は様々な物理的な構成要素において、または様々な物理的な構成要素を通じて実装されてよく、必ずしも単一のプラットフォームの実装に限定されないことが、当業者には認識される。例えば、ネットワークノードは、基地局トランシーバ（ＢＴＳ）、基地局コントローラ（ＢＳＣ）、基地局（ＢＳ）（例えば、強化されたＢＳ（ｅＢＳ））、ノードＢ、無線ネットワークコントローラ（ＲＮＣ）（例えば、シグナリングＲＮＣ（ｓＲＮＣ））、ＨＲＰＤアクセスネットワーク（ＡＮ）、ＨＲＰＤパケット制御機能（ＰＣＦ）、アクセスサービスネットワーク（ＡＳＮ）ゲートウェイ、アクセスゲートウェイ（ＡＧＷ）、ＡＳＮ基地局、アクセスポイント（ＡＰ）、広帯域基地局（ＷＢＳ）、およびＷＬＡＮ（無線ローカルエリアネットワーク）局のうちの１つ以上など、１つ以上の通信ネットワーク構成要素において、または１つ以上の通信ネットワーク構成要素を通じて実装されてよい。

アクセス端末（ＡＴ）、移動体装置、リモートユニット、加入者局（ＳＳ）、およびユーザ機器（ＵＥ）のうちの１つ以上は、移動局（ＭＳ）、移動体加入者局（ＭＳＳ）または移動体ノード（ＭＮ）と考えられてよい。加えて、ＡＴプラットフォームは、次に限定されないが、移動局（ＭＳ）、端末装置、リモートユニット、ゲーム装置、パーソナルコンピュータおよび携帯情報端末（ＰＤＡ）など、多種多様な消費者向け電子プラットフォームを表すものとして知られている。詳細には、ＡＴは各々、処理装置およびトランシーバを備える。実施形態によって、ＡＴは各々、さらに、キーパッド、スピーカ、マイクロホンおよびディスプレイを備える場合がある。ＡＴにおいて用いられる処理装置、トランシーバ、キーパッド、スピーカ、マイクロホンおよびディスプレイはすべて、当技術において周知である。

本発明による実施形態の動作は、ほぼ以下のように行われる。最初に図１を参照する。図１に示すように、ネットワークノード２およびネットワークノード３は、ＡＴのデータ転送をサポートするためのトンネル１１０を有する。図示の目的のため、ネットワークノード３はＡＴのサービングノードであると仮定し、トンネル１１０はアクティブであり、ＡＴへの順方向およびＡＴからの逆方向の両方におけるデータ転送をサポートするために用いられていると仮定する。

ある時点において、ネットワークノード１は、ネットワークノード１とネットワークノード２との間にトンネルを確立させるため、ネットワークノード２へメッセージ１２０を送信する。対象の実施形態および状況に応じて、多くのイベントによってネットワークノード１にメッセージ１２０を送信させることができる。例えば、ネットワークノード１は、ネットワークノード１がＡＴのアクティブセットに追加されたこと、またはＡＴがネットワークノード１へのハンドオフを望むことの表示の受信に応答して、メッセージ１２０を送信してもよい。これに代えて、例えば、近いうちにＡＴがネットワークノード１へハンドオフを行うことを通信ネットワークが予想していてもよく、ＡＴが近い将来にネットワークノード１へハンドオフを行うことの可能性に基づき、通信ネットワークがトンネルを設定していてもよい。

実際に送信されるメッセージの種類は、多分に実施形態による。例えば、メッセージ１２０は、ＰＭＩＰ（ＰｒｏｘｙＭｏｂｉｌｅＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ）メッセージを含み得る。ＰＭＩＰメッセージは、ＰＭＩＰＢＵ（結合の更新）メッセージなど、ＰＭＩＰトンネルを確立させるためのメッセージである。このメッセージによって、または何らかの他のメッセージによっても、逆方向または順方向のデータ転送をサポートするためにトンネルが現在用いられ始めるか否かを示すことができる。例えば、単純にパラメータによってこのことを示してもよく、あるいは、ＧＲＥ（ｇｅｎｅｒｉｃｒｏｕｔｅｅｎｃａｐｓｕｌａｔｉｏｎ）キーなどのパラメータ内において順方向および逆方向に対応するビットが用いられてもよい。

図示の目的のため、メッセージ１２０が、逆方向または順方向のデータ転送をサポートするためにトンネルが用いられ始められないことを示した、と仮定する。したがって、新たなトンネル１３０は、最初はアクティブでないままである。しかしながら、ネットワークノード１がＡＴのサービングネットワークノードとなるなどのイベントによって、新たなトンネルをトンネル１６０のようにアクティブとすることができる。例えば、ネットワークノード１は、逆方向のデータ転送をサポートするために新たなトンネルが用いられることを示すメッセージを、ネットワークノード２へ送信することができる。このメッセージは、トンネル１６０を介して送信されるメッセージ、おそらくは逆方向データを有するメッセージの、ＧＲＥヘッダによる表示の形態を取ることができる。代替の実施形態では、ネットワークノード１は、逆方向のデータ転送をサポートするために新たなトンネルが用いられることを示すメッセージを受信してもよい。

以前のアクティブなトンネル１４０およびトンネル１５０は、ＡＴへの順方向のデータをサポートするために用いられてよい。したがって、データ方向に応じて、一定の期間にわたって、異なる複数のトンネルがＡＴのデータ転送をサポートするために用いられる。次いで、メッセージがおそらくはトンネル１７０を介して送信され（すなわち、ネットワークノード１によって受信され）、新たなトンネルがＡＴとの間の両方向のデータに現在用いられることを示す。

図１では、本発明の様々な実施形態の機能的態様について、より一般的に示しているが、特定の実施形態についてのより詳細な記載によって、より一般的に記載した上述の実施形態を読手が理解し実装することが補助されると考えられる。以下に記載の実施形態を例として提供する。それらの実施形態を、本発明に関する特定の、充分に詳細な、例示の実施形態として提供する。それらの実施形態は、本発明の範囲を限定するものではなく、様々な可能な実施形態についての読手の理解を促進することを意図したものである。

図２〜６は、本発明のより詳細な実施形態による、無線通信システムにおける複数の機能要素間において可能なトンネル構造を示すブロック図である。図の２００，３００，４００，５００，６００のように、無線通信システムにおける異なる複数の機能要素を通じて、多くのデータアンカーおよびトンネルが設定され得る。例えば、ｅＢＳ、移動電話交換局（ＭＴＳＯ）／ＭＳＣ（移動交換局）、ＲＮＣ、ＡＧＷ、およびＬＭＡ（ｌｏｃａｌｍｏｂｉｌｉｔｙａｎｃｈｏｒ）はすべて、データアンカーとして作用することができる。以下は、図の２００に関する説明である。
・ＡＴとｅＢＳとの間を越えてセッションアンカー（ＳｅｓｓｉｏｎＡｎｃｈｏｒ）の経路を延長。
・セッションアンカーはｓＲＮＣ自体であることも、ｅＢＳ以外のｓＲＮＣによって割り当てられることも可能である。
・各々のＡＮはＡＴのＳＡ経路を設定するように構成される、または信号を送信される。
・ＳＡ経路は構成された全範囲内において同じままである。
・各ＡＮは１より多くのＳＡにアクセスを行うことができる。

以下は、図３〜６に関する説明である。
−各々のプロキシ・データ経路アンカー（ＰＤＲＡ）は、標準によって提案されているようなデータアンカーとして作用する、すべてのプロトコルスタック（経路制御プロトコル）を有さなくてもよい。データアンカー経路はサービングｅＢＳによって生成され、割り当てられた「アンカー」経路ＩＤまたはＩＰを介して、ｅＢＳによって認識可能である。
−複数のプロキシデータトンネルは、ＰＤＲＡとＡＧＷとの間において、高速なｅＢＳ間ハンドオフと、アンカーハンドオフとのために、予め設定されることが可能である。
−データ・アンカー・ハンドオフは、１つのＳＲＮＣによって、または複数のｅＢＳの間において、開始されることが可能である。
−ＰＤＲＡ／ＤＡＰはＡＮ自体のうちの一部であってよい。

図７〜１５について詳細に説明する前に、何らかの前書きが有用であり得る。ここでは、ＡＴに直接ＲＦ接続していないｅＢＳがアクティブセットの別のｅＢＳによって生成される経路を有し、同じサブネットまたは複数のサブネットのグループの任意のアクティブなｅＢＳによって維持されることを可能とする、プロキシ経路の概念について記載する。また、そのような経路はネットワークアクセスゲートウェイ（ＡＧＷ）へ接続するためのアンカー経路であり得ることについて記載する。これに加えて、それらのアンカー経路の一覧が、アンカーおよびＡＴによって、また、その一覧に示されるサービングアンカーによって生成および維持され得る。次いで、ＡＴは、ネットワーク内においてｅＢＳからｅＢＳへ移動するとき、サービングアンカーを選択することが可能である。これに加えて、１より多くのアンカー経路が可能とされる。アンカー経路は、サービング経路となる前に、ＡＴのアンカー一覧へ追加されることが可能である。アンカーのネゴシエーションおよびコンテキストの転送は、アンカーハンドオフの前に実行されてもよい。

各々のｅＢＳは、セッションアンカーおよびデータアンカーの経路を生成することが可能である。ｅＢＳは、複数の経路と、セッションアンカーとを生成および維持することが可能である。また、ｅＢＳは、アンカー経路の生成、維持および非アクティブ化を行うために、他のｅＢＳから要求を受信することが可能である。各々のｅＢＳは、セッションおよびデータアンカーとの通信を行うために、１つ以上のトンネルのセットを維持する。

アンカーは、ＡＧＷから分離されるとき、３ＧＰＰ２仕様のＡ１０／Ａ１１と同様のインタフェースを通じて、またはＩＥＴＦプロトコルによって指定される単一のトンネルによって、ＡＴの代わりにデータトンネルの確立を行う。ＡＴが複数のサービングｅＢＳへのアクセスを有するとき、それらのサービングｅＢＳの各々は、ＡＧＷへのアクセスポイントとして作用することが可能である。複数のトンネルが、ＡＧＷを有するそれらのｅＢＳの間に確立されることが可能である。ＡＴは、同じＡＧＷへの逆方向トラフィックのための複数のデータトンネルの各々を利用することが可能である。順方向トラフィックのためのトンネルは、アンカーとＡＴとの間の実際の接続に基づき、開閉される。

これによって、追加のトンネル、特にセッションおよびデータアンカーによって用いられるトンネルが、ＡＴと直接ＲＦ接続していないときであっても、生成および維持されることが可能となる。すなわち、これによって、ＡＴが維持することの可能なアクティブセットの大きさの制限のため、サービングアンカー（ｅＢＳ）が別のアンカーへハンドオフを行わなければならないことは防止される。これによって、さらに、アクティブセットにないｅＢＳがアンカーとして作用することが可能となる。

これらの追加の性能によって、次の利点が得られる。
−アンカー場所の柔軟性。アンカー場所はスイッチ部であっても、ネットワークのいずれの場所であってもよい。
−アンカーのハンドオフの必要の減少。
−ｅＢＳ間トラフィックの減少。
−現行のＢＴＳが存在する場所にアンカーが配置されたとき、スポークバックホールを通じてトロンボーン様に行き来する必要のあるユーザトラフィックおよびシグナリングトラフィックを回避することによる、バックホール容量の必要性の減少。
−バックホールを通じてトロンボーン様に行き来するトラフィックによる追加の遅延の回避。

以下に記載の実施形態は、ＶｏＩＰ、テレビ電話、音声および映像ストリーミングなどのリアルタイムサービスをよりよくサポートすることの可能な最適化された解決策に対する、現行の３ＧＰＰ２ＨＲＰＤパケットデータネットワークの進化型におけるｅＢＳ／ｓＲＮＣインタフェースフレームワークへのアクセスゲートウェイに適用可能である。提案のフレームワークは、３ＧＰＰ２において現在開発されているＵＭＢエアインタフェースを含む複数の多重接続技術を通じて用いることが可能である。詳細には、以下の記載は、アクセスネットワークとゲートウェイとの間のインタフェースにおけるプロキシモバイルＩＰに基づく、高度インタフェースアーキテクチャに適用可能である。

この提案の主な目標は、エアインタフェースの遷移およびイベントのためＡＧＷへ送信される信号の量を最小化することによって、ネットワーク内においてベアラ経路を設定する際の遅延を減少させることである。この提案によって、アクティブ／休止の遷移の切り替えまたは移動性の場合のデータアンカーの再割当の効率的な方法を提供するＰＭＩＰトンネルを、予め設定することが可能となる。この提案によって、アクセスネットワーク、例えば、ｓＲＮＣ、アンカーｅＢＳ（データ割当点）およびサービングｅＢＳからＡＧＷへ向けて、同じＡＴに対する同時のＰＭＩＰ結合が予め確立されることが可能となる。任意の瞬間において、トンネルの任意の方向には、１つのアクティブなトンネルしか存在することができない。トンネルコンテキストは、明示的なＰＭＩＰまたは制御信号送信の必要なく、ｓＲＮＣ／ｅＢＳ（休止遷移中）または別のサービングｅＢＳ（ＤＡＰ再割当）に切り替えられる。トンネルコンテキストは、ペイロードに加え、ＧＲＥヘッダの一定の属性に基づき、切り替えられる。

一部の仮定には、次が含まれる。
・ベアラトランスポートのためのＲＦＣ１７０１に準拠したＰＭＩＰ信号送信およびＧＲＥの使用。
・ＡＧＷに対する順方向・逆方向トラフィックの両方において、所与の時間にはアクティブなデータアンカーは１つのみ。
・ペイロードのないＧＲＥパケットを送信可能。
・ＡＧＷによって、単一のＡＴについて複数の同時の結合が可能となる。
・ＧＲＥのキーまたはシーケンス番号は、３ＧＰＰ２特有のビットフィールドを有する。

以下に記載の実施形態のうちの多くに関するさらなる幾つかの一般的な説明には、次が含まれる。
−データアンカー経路は、より少ない遅延およびデータ損失を保証するため、アクティブセットの変化に基づき選択される。
−サービングＢＳは、トンネルを開くよう、データアンカーに信号を送信することが可能である。データアンカーはトラフィックの二重送信（ｂｉ−ｃａｓｔ）／同時送信をしない。
−データアンカーは、順方向リンクの前であっても、経路を通じて逆方向リンクデータを受信することが可能である。
−複数のトンネルを有することによって、必要な場合、休止中にセッションアンカー（例えば、ｓＲＮＣ）へデータが送信されることが可能となる。

図７〜１４は、本発明のより詳細な実施形態による、複数のトンネルの使用を示すメッセージフロー図である。フロー７００には、高度な、ＡＧＷへのＰＭＩＰコンテキスト確立手順を示す。ｓＲＮＣは、ＰＭＩＰトンネルを確立させるために、アクセス認証の一部として実行されるＥＡＰ手順によるＮＡＩを用いる。ｓＲＮＣは、空のＧＲＥパケットを送信することによって、トンネルが依然としてアクティブでないことをＡＧＷに示すことができる。空のＧＲＥパケットは、０のシーケンス番号を有する、すなわち、ＧＲＥキー内のあるフィールドが０に設定されている（この提案においてはトラフィック属性と呼ぶ）。続いて、アンカーｅＢＳが同時送信ビットの設定された別のＰＭＩＰトンネル結合を確立させると、ベアラを有するアンカーｅＢＳは、０でないシーケンス番号を有する、すなわち、ＧＲＥキーのトラフィック属性が一定の値に設定されたＧＲＥパケットを、ＡＧＷへ送信する。

ＡＧＷへのアクティブなベアラトンネルを示す方法は、ｅＢＳまたはｓＲＮＣからのＧＲＥキー内の０でないシーケンス番号、すなわち、０でないフィールドの存在によることが可能である。コールフロー７００では、ｅＢＳは、そのようなシーケンス番号の存在を介して、またはＧＲＥキー内のトラフィック属性フィールドがないことによって、アクティブなトンネルのピア（ｐｅｅｒ）を示す。ｓＲＮＣ／ＡＧＷは、トラフィック属性が存在しない、またはシーケンス番号が０に設定されている場合、別のピアへＧＲＥパケットを送信しない。

フロー８００には、高度な、ＡＧＷへのＰＭＩＰコンテキスト確立手順を示す。ｅＢＳは、ＰＭＩＰトンネルを確立させるために、アクセスまたは加入（ｓｕｂｓｃｒｉｐｔｉｏｎ）認証の一部として実行されるＥＡＰ手順によるＮＡＩを用いる。ｅＢＳは、０のシーケンス番号を有する、すなわち、ＧＲＥキー内のあるフィールドが０に設定された（この提案においてはトラフィック属性と呼ぶ）空のＧＲＥパケットを送信することによって、トンネルがアクティブでないことをＡＧＷに示すことができる（注：この属性は、ＧＲＥヘッダにおける３ＧＰＰ２特有のフィールドを最小化する意図による、ＧＲＥヘッダの修正の例として提案されている）。続いて、さらなるｅＢＳが同時送信（Ｓ）ビットの設定された別のＰＭＩＰトンネル結合を確立させると、それらのｅＢＳは、ＧＲＥキーのトラフィック属性が０の値に設定された、ペイロードを有する／有しないＧＲＥパケットを、ＡＧＷへ送信する。ＧＲＥキーの長さが短くなったとしても、トンネル当たりの総ユニークＧＲＥキーは依然として大きいままである。

ＡＧＷへのアクティブなベアラトンネルを示す方法は、ｅＢＳからのＧＲＥキー内の０でないトラフィック属性フィールドの存在によることが可能である。コールフロー８００では、ｅＢＳは、ＧＲＥキー内のトラフィック属性フィールドを介して、アクティブなトンネルのピアを示す。ＡＧＷは、トラフィック属性が存在しない場合、別のピアへ（すなわち、別の方向へ）ＧＲＥパケットを送信しない。

ｅＢＳに対するアクティブセットの変化の影響について、以下に示す。ここでは、同時の結合によってＰＭＩＰトンネルを確立させる非データアンカーｅＢＳを含む、すべてのｅＢＳを示す。ネットワークが本明細書の範囲外の一定のトリガに基づきデータアンカーを切り替えるとき、新たなアンカーは、ＧＲＥキーのトラフィック属性によって、または有効なシーケンス番号によって、ＡＧＷに対する切り替えを示すことができる。

この提案では、サービングｅＢＳがＡＧＷ（アンカーとなった）からデータを直接的に送信／受信する最も迅速な代替の方法のうちの１つを提供する。フロー９００では、アクティブセットから現行のアンカーｅＢＳを削除することは、新たなサービングｅＢＳへのデータアンカー移動と同時に起こる。しかしながら、アクティブセットからアンカーｅＢＳを削除することによって、常に新たなサービングｅＢＳへのアンカー点移動が起きる必要はない。この提案では、アンカーｅＢＳ（ＤＡＰ）とアクティブなＧＲＥトンネルとの間の関連が明確に識別される。

この事前設定の機構によって、さらなる遅延およびさらなる３ＧＰＰ２特有の信号送信を追加することなく、逆方向において新たなｅＢＳからデータを送信する効率的な方法が提供される。また、ＦＬＳＡ（順方向リンクサービングＡＮ）およびＲＬＳＡ（逆方向リンクサービングＡＮ）に対し、新たなデータアンカーとの間でベアラ転送が可能となる。

ｅＢＳに対するアクティブセットの変化の代替の影響について、以下に示す。ここでは、同時の結合によってＰＭＩＰトンネルを確立させる非データアンカーｅＢＳを含む、すべてのｅＢＳを示す。フロー１０００には、アクティブセットからＤＡＰが除去された後であっても依然としてＤＡＰを通じてデータのルーティングが行われるシナリオを示す。ネットワークは、ＡＴが新たなサービングｅＢＳへ移動した場合にも、依然としてＤＡＰ機能を係留しておくことが可能である。ネットワークが本明細書の範囲外の一定のトリガに基づきデータアンカーを切り替えるとき、新たなアンカーは、ＧＲＥキーのトラフィック属性によって、ＡＧＷに対する切り替えを示すことができる。フロー１０００では、アクティブセットからアンカーｅＢＳを削除することによって、常に新たなサービングｅＢＳへのアンカー点移動が起きる必要はない。この提案では、アンカーｅＢＳ（ＤＡＰ）とアクティブなＧＲＥトンネルとの間の関連が明確に識別される。

続く提案では、サービングｅＢＳがＡＧＷへデータを直接的に送信し、続いてＡＧＷ（アンカーとなった）からデータを受信する最も迅速な代替の方法のうちの１つを提供する。フロー１１００では、現在のデータアンカーは、ＡＧＷへデータを直接的に送信することによって、新たなサービングｅＢＳへ移動される。また、ＡＧＷは、広汎な信号送信なしで、ペイロードを有して／有しないで、ＧＲＥキーにおける０でないトラフィック属性を新たなサービングｅＢＳに送信することによって、順方向トンネルを切り替えることも可能である。また、既に実行されていない場合、これはＡＴへのＤＡＰ移動のトリガを行うためにも用いられることが可能である。

この事前設定の機構によって、アクティブセットが追加されるとき、さらなる遅延およびさらなる３ＧＰＰ２特有の信号送信を追加することなく、逆方向において新たなｅＢＳからデータを送信する効率的な方法が提供される。また、これによって、ＦＬＳＡおよびＲＬＳＡに対し、新たなデータアンカーとの間のベアラ転送が可能となる。

休止遷移におけるｅＢＳ、ｓＲＮＣおよびＡＧＷに対する影響について、フロー１２００により以下に示す。非データアンカーｅＢＳを含むすべてのｅＢＳが、同時の結合によってＰＭＩＰトンネルを維持する。トンネル維持または受信者からの肯定応答手順では、ＧＲＥキーのトラフィック属性のない空のＧＲＥパケット、すなわち、０のシーケンス番号が用いられることが可能である。アクティブなデータアンカーと休止中のｓＲＮＣとの間の遷移では、追加の信号送信なしで、ＧＲＥキー表示内のトラフィックフィールドまたはシーケンス番号を有する事前設定されたＰＭＩＰトンネルが常に用いられる。休止からアクティブへの遷移の場合、データアンカーポイント（アンカーｅＢＳ）またはサービングｅＢＳは、ＡＧＷへデータを直接的に送信することが可能である。この方法によって、遅延が減少され、サイドホールに対する効率が増大する。アクティブセットのｓＲＮＣ／ｅＢＳとの間のデータ経路を予め確立する方法によって、データアンカーｅＢＳの信頼性および可用性の提供も補助される。

休止遷移におけるｅＢＳおよびＡＧＷに対する代替の影響について、フロー１３００により以下に示す。非データアンカーｅＢＳを含むすべてのｅＢＳが、同時の結合によってＰＭＩＰトンネルを維持する。トンネル維持または受信者からの肯定応答手順では、ＧＲＥキーのトラフィック属性のない空のＧＲＥパケットが用いられることが可能である。次のシナリオでは、ＡＴがページトリガーのために再びアクティブとされるとき、ＡＴが他の潜在的なＦＬＳＡ／ＲＬＳＡメンバとともにＤＡＰカバレッジから移動していない場合について示す（注：ページのバッファ化がＡＧＷにおいて実行されている場合、このトラフィック属性が、休止遷移中のＡＧＷへのフロー制御の目的を提供することも可能である（ＦＦＳ））。

フロー１４００による以下のシナリオでは、ＰＭＩＰトンネルを確立させていない新たなｅＢＳへ移動するＡＴについて示す。休止からアクティブへの遷移の場合、データアンカーポイント（アンカーｅＢＳ）またはサービングｅＢＳは、ＡＧＷへデータを直接的に送信し、データアンカー点を移動させることが可能である。ｅＢＳとの間のデータ経路を確立するこの方法によって、データアンカーｅＢＳの信頼性および可用性の提供が補助される（注：上述のＰＭＩＰ／ＧＲＥの方法は、休止中のｓＲＮＣ−ＡＧＷインタフェースまで拡張されることが可能であり、再アクティブ化中のページのバッファ化はｓＲＮＣにおいて必要とされる。シグナリングメッセージはＦＦＳである）。

上述の実施形態のうちの少なくとも一部に照らして、次の幾つかの利点が可能である。
−ネットワーク信号送信の遅延の減少。
−３ＧＰＰ２特有の信号送信の減少による技術間ハンドオフの容易化。
−ベアラ遅延の減少。
−ｅＢＳ間トラフィックを減少させることによるサイドホール効率の増大の可能性。
−ＤＡＰ可用性に対する依存の低下。

図１５は、本発明のより詳細な実施形態による、修正されたキーフィールドを有するＧＲＥヘッダを示すブロック図である。ＦおよびＲのフィールドは、トラフィックの方向ごとのトラフィック属性である（Ｆは順方向、Ｒは逆方向）。ｅＢＳは、トンネルを両方向に動かすために、ＦおよびＲの両方のビットを設定することが可能である。しかしながら、ｅＢＳがＰＭＩＰトンネルを確立させた後、ＡＧＷはＦビットのみを設定する。

本発明の様々な実施形態による、複数のトンネルの使用を示すメッセージフロー図。本発明のより詳細な実施形態による、無線通信システムにおける複数の機能要素間において可能なトンネル構造を示すブロック図。本発明のより詳細な実施形態による、無線通信システムにおける複数の機能要素間において可能なトンネル構造を示すブロック図。本発明のより詳細な実施形態による、無線通信システムにおける複数の機能要素間において可能なトンネル構造を示すブロック図。本発明のより詳細な実施形態による、無線通信システムにおける複数の機能要素間において可能なトンネル構造を示すブロック図。本発明のより詳細な実施形態による、無線通信システムにおける複数の機能要素間において可能なトンネル構造を示すブロック図。本発明のより詳細な実施形態による、複数のトンネルの使用を示すメッセージフロー図。本発明のより詳細な実施形態による、複数のトンネルの使用を示すメッセージフロー図。本発明のより詳細な実施形態による、複数のトンネルの使用を示すメッセージフロー図。本発明のより詳細な実施形態による、複数のトンネルの使用を示すメッセージフロー図。本発明のより詳細な実施形態による、複数のトンネルの使用を示すメッセージフロー図。本発明のより詳細な実施形態による、複数のトンネルの使用を示すメッセージフロー図。本発明のより詳細な実施形態による、複数のトンネルの使用を示すメッセージフロー図。本発明のより詳細な実施形態による、複数のトンネルの使用を示すメッセージフロー図。本発明のより詳細な実施形態による、修正されたキーフィールドを有するＧＲＥヘッダを示すブロック図。

Claims

通信ネットワーク内において複数のトンネルを用いる方法であって、
アクセス端末（ＡＴ）への順方向およびＡＴからの逆方向の両方におけるデータ転送をサポートするために、通信ネットワーク内の異なる複数のネットワークノードを介して複数のトンネルを確立する工程と、
一定の期間にわたって複数のトンネルのうちの第１のトンネルを介して順方向のデータ転送をサポートする工程と、
同期間にわたって複数のトンネルのうちの第２のトンネルを介して逆方向のデータ転送をサポートする工程と、第１のトンネルは第２のトンネルと異なることと、
を含む方法。
前記同期間にわたってさらに第１のトンネルを介して逆方向のデータ転送をサポートする工程を含む請求項１に記載の方法。
一定の期間にわたって第１のトンネルを介して順方向のデータ転送をサポートする工程は、一定の期間にわたって第１のトンネルのみを介して順方向のデータ転送をサポートする工程を含む請求項１に記載の方法。
同期間にわたって第２のトンネルを介して逆方向のデータ転送をサポートする工程は、同期間にわたって第２のトンネルのみを介して逆方向のデータ転送をサポートする工程を含む請求項１に記載の方法。
前記期間の終わりに、順方向のデータ転送のサポートを第１のトンネルから第２のトンネルへ切り替える工程を含む請求項１に記載の方法。
前記期間の終わりに、逆方向のデータ転送のサポートを第２のトンネルから第１のトンネルへ切り替える工程を含む請求項１に記載の方法。
通信ネットワーク内において複数のトンネルを用いる方法であって、
アクセス端末（ＡＴ）のデータ転送をサポートするために、第１のネットワークノードによるメッセージを第２のネットワークノードへ送信して、第１のネットワークノードと第２のネットワークノードとの間に第１のトンネルを確立する工程と、第２のネットワークノードはＡＴのデータ転送をサポートするために第３のネットワークノードとの第２のトンネルを有することと、
一定の期間にわたって第１のトンネルを介して、ＡＴからの逆方向およびＡＴへの順方向のうちの一方のデータ転送をサポートし、かつ、他方のデータ転送をサポートしない工程と、
前記期間に続き、第１のトンネルを介してＡＴからの逆方向およびＡＴへの順方向の両方のデータ転送をサポートする工程と、を含む方法。
メッセージを送信して第１のトンネルを確立する工程は、第１のネットワークノードがＡＴのアクティブセットに追加されたことの表示の受信に応答して、メッセージを送信して第１のトンネルを確立する工程を含む請求項７に記載の方法。
メッセージを送信して第１のトンネルを確立する工程は、逆方向および順方向のうちの一方または両方のデータ転送をサポートするために第１のトンネルが現在用いられ始めるか否かを示す工程を含む請求項７に記載の方法。
逆方向および順方向のうちの一方または両方のデータ転送をサポートするために第１のトンネルが用いられることを示す第１のネットワークノードによるメッセージを第２のネットワークノードへ送信する工程を含む請求項７に記載の方法。