通信ネットワーク内において複数のトンネルを利用する方法
【課題】通信ネットワークにおける移動イベント中にリアルタイムサービスをよりよくサポートできるようにする。
【解決手段】アクセス端末(AT)への順方向およびATからの逆方向の両方におけるデータ転送をサポートするために、通信ネットワーク内の異なる複数のネットワークノードを介して複数のトンネルが確立される。順方向のデータ転送は、一定の期間にわたって複数のトンネルのうちの第1のトンネル140,150を介してサポートされ、逆方向のデータ転送は、同じ期間にわたって第2の異なるトンネル160を介してサポートされる。
【解決手段】アクセス端末(AT)への順方向およびATからの逆方向の両方におけるデータ転送をサポートするために、通信ネットワーク内の異なる複数のネットワークノードを介して複数のトンネルが確立される。順方向のデータ転送は、一定の期間にわたって複数のトンネルのうちの第1のトンネル140,150を介してサポートされ、逆方向のデータ転送は、同じ期間にわたって第2の異なるトンネル160を介してサポートされる。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は通信システムに関する。詳細には、本発明は通信ネットワーク内において複数のトンネルを用いることに関する。
【背景技術】
【0002】
様々な無線通信技術が、VoIP(ボイス・オーバ・インターネット・プロトコル)、テレビ電話(Video Telephony)、音声および映像ストリーミングなどのリアルタイムサービスをサポートするために開発されている。移動体装置にそのようなサービスを提供することによって、特に、通信システムを通じて移動し、1つの基地局(BS)またはアクセス・ネットワーク(AN)から次のものへとハンドオフを行っている装置について、多くの課題が生まれる。通常、データトンネルは、移動体装置との間のベアラトラフィックを処理するために、サービングBS/ANからデータゲートウェイ装置へと設定される。この経路は、この経路に沿ったアンカーとして作用する複数のネットワークノード、装置またはその両方を含む場合がある。一連のトンネルが、ベアラ経路を提供するために、複数のアンカーの間に確立され得る。移動体装置はシステムを通じてハンドオフを行うので、ベアラ経路は、移動体に付き従うために、新たなトンネルおよびアンカーを確立することによって変更される必要がある。そのようなデータ経路の切替によって、さらなる遅延、途絶またはその両方がリアルタイムサービスに導入され得る。
【発明の開示】
【発明が解決しようとする課題】
【0003】
したがって、当技術を進歩させるためには、移動イベント中にリアルタイムサービスをよりよくサポートすることの可能な新たな技術が明らかに所望される。
【課題を解決するための手段】
【0004】
様々な実施形態について記載する。それらの実施形態のうちの一部は、通信ネットワークにおける移動イベント中にリアルタイムサービスをよりよくサポートすることが可能である。一般に、それらの実施形態では、アクセス端末(AT)への順方向およびATからの逆方向の両方におけるデータ転送をサポートするために、通信ネットワーク内の異なる複数のネットワークノードを介して複数のトンネルが確立される。順方向のデータ転送は、一定の期間にわたって複数のトンネルのうちの第1のトンネルを介してサポートされ、逆方向のデータ転送は、同じ期間にわたって第2の異なるトンネルを介してサポートされる。
【発明を実施するための最良の形態】
【0005】
開示の実施形態は、図1〜15を参照することによって、より完全に理解され得る。図1は、本発明の様々な実施形態による、複数のトンネルの使用を示すメッセージフロー100である。現在、OMA(Open Mobile Alliance)、3GPP(3rd Generation Partnership Project)、3GPP2(3rd Generation Partnership Project 2)、IEEE(Institute of Electrical and Electronics Engineers)802およびWiMAXフォーラムなどの標準機構が、無線通信システム用の標準仕様を開発している(これらの団体には、それぞれ、http://www.openmobilealliance.com,http://www.3gpp.org/,http://www.3gpp2.com/,http://www.ieee802.org/,http://www.wimaxforum.org/を介して連絡することができる)。メッセージフロー100では、一般に、ネットワークノード1〜3をメッセージ送信の端点として示す。ネットワークノード1〜3によって表される通信ネットワークは、本発明を実装するように適切に修正された、3GPP2、3GPP、WiMAXフォーラム、およびIEEE 802のうちの1つ以上の技術によるアーキテクチャを有するシステムである。
【0006】
ネットワークノード1〜3については、非常に一般化して示す。図1には通信ネットワークが動作するのに必要であり得る物理的な固定のネットワーク構成要素のすべてが示されているのではなく、本明細書における実施形態の記載に特に関連するシステム構成要素および論理的なエンティティのみが示されていることが、当業者には認められる。例えば、示してはいないが、ネットワークノード1,3は、無線インタフェースを用いて、アクセス端末(AT)にネットワーク・サービスを提供する。用いられる無線インタフェースは、各々のネットワークノードによってそれぞれサポートされる特定の接続技術による。例えば、それらの無線インタフェースはすべて、3GPP2仕様またはIEEE 802.16に基づく技術など、同じ技術を利用してもよく、異なる複数の接続技術を利用してもよい。
【0007】
また、図1には、ネットワークノード1〜3が各々、処理装置およびネットワークインタフェースを備えることを示していない。これに加えて、ネットワークノード1,3は各々、無線トランシーバを備える。一般に、処理装置、トランシーバおよびネットワークインタフェースなどの構成要素は周知である。例えば、処理装置が、マイクロプロセッサ、マイクロコントローラ、メモリ装置、特定用途向け集積回路(ASIC)、および論理回路(これらに限定されず、また必ずしも必要ではないが)のうちの1つ以上などの基本的な構成要素を含むことは周知である。そのような構成要素は、通常、高度設計言語もしくは記述、コンピュータ命令、信号/メッセージフロー図、および論理フロー図のうちの1つ以上を用いて表現された、アルゴリズム、プロトコルまたはその両方を実装するように適合されている。
【0008】
すなわち、高度記述、アルゴリズム、論理フロー、メッセージ/信号フロー、およびプロトコル仕様のうちの1つ以上が与えられれば、当業者には、その与えられた論理を実行する処理装置を実装するために利用可能な多くの設計・開発技術が認識される。したがって、ネットワークノード1〜3は、本明細書の記載にしたがって、本発明の複数の実施形態を実装するように適合された周知の装置を表す。さらに、本発明の態様は様々な物理的な構成要素において、または様々な物理的な構成要素を通じて実装されてよく、必ずしも単一のプラットフォームの実装に限定されないことが、当業者には認識される。例えば、ネットワークノードは、基地局トランシーバ(BTS)、基地局コントローラ(BSC)、基地局(BS)(例えば、強化されたBS(eBS))、ノードB、無線ネットワークコントローラ(RNC)(例えば、シグナリングRNC(sRNC))、HRPDアクセスネットワーク(AN)、HRPDパケット制御機能(PCF)、アクセスサービスネットワーク(ASN)ゲートウェイ、アクセスゲートウェイ(AGW)、ASN基地局、アクセスポイント(AP)、広帯域基地局(WBS)、およびWLAN(無線ローカルエリアネットワーク)局のうちの1つ以上など、1つ以上の通信ネットワーク構成要素において、または1つ以上の通信ネットワーク構成要素を通じて実装されてよい。
【0009】
アクセス端末(AT)、移動体装置、リモートユニット、加入者局(SS)、およびユーザ機器(UE)のうちの1つ以上は、移動局(MS)、移動体加入者局(MSS)または移動体ノード(MN)と考えられてよい。加えて、ATプラットフォームは、次に限定されないが、移動局(MS)、端末装置、リモートユニット、ゲーム装置、パーソナルコンピュータおよび携帯情報端末(PDA)など、多種多様な消費者向け電子プラットフォームを表すものとして知られている。詳細には、ATは各々、処理装置およびトランシーバを備える。実施形態によって、ATは各々、さらに、キーパッド、スピーカ、マイクロホンおよびディスプレイを備える場合がある。ATにおいて用いられる処理装置、トランシーバ、キーパッド、スピーカ、マイクロホンおよびディスプレイはすべて、当技術において周知である。
【0010】
本発明による実施形態の動作は、ほぼ以下のように行われる。最初に図1を参照する。図1に示すように、ネットワークノード2およびネットワークノード3は、ATのデータ転送をサポートするためのトンネル110を有する。図示の目的のため、ネットワークノード3はATのサービングノードであると仮定し、トンネル110はアクティブであり、ATへの順方向およびATからの逆方向の両方におけるデータ転送をサポートするために用いられていると仮定する。
【0011】
ある時点において、ネットワークノード1は、ネットワークノード1とネットワークノード2との間にトンネルを確立させるため、ネットワークノード2へメッセージ120を送信する。対象の実施形態および状況に応じて、多くのイベントによってネットワークノード1にメッセージ120を送信させることができる。例えば、ネットワークノード1は、ネットワークノード1がATのアクティブセットに追加されたこと、またはATがネットワークノード1へのハンドオフを望むことの表示の受信に応答して、メッセージ120を送信してもよい。これに代えて、例えば、近いうちにATがネットワークノード1へハンドオフを行うことを通信ネットワークが予想していてもよく、ATが近い将来にネットワークノード1へハンドオフを行うことの可能性に基づき、通信ネットワークがトンネルを設定していてもよい。
【0012】
実際に送信されるメッセージの種類は、多分に実施形態による。例えば、メッセージ120は、PMIP(Proxy Mobile Internet Protocol)メッセージを含み得る。PMIPメッセージは、PMIP BU(結合の更新)メッセージなど、PMIPトンネルを確立させるためのメッセージである。このメッセージによって、または何らかの他のメッセージによっても、逆方向または順方向のデータ転送をサポートするためにトンネルが現在用いられ始めるか否かを示すことができる。例えば、単純にパラメータによってこのことを示してもよく、あるいは、GRE(generic route encapsulation)キーなどのパラメータ内において順方向および逆方向に対応するビットが用いられてもよい。
【0013】
図示の目的のため、メッセージ120が、逆方向または順方向のデータ転送をサポートするためにトンネルが用いられ始められないことを示した、と仮定する。したがって、新たなトンネル130は、最初はアクティブでないままである。しかしながら、ネットワークノード1がATのサービングネットワークノードとなるなどのイベントによって、新たなトンネルをトンネル160のようにアクティブとすることができる。例えば、ネットワークノード1は、逆方向のデータ転送をサポートするために新たなトンネルが用いられることを示すメッセージを、ネットワークノード2へ送信することができる。このメッセージは、トンネル160を介して送信されるメッセージ、おそらくは逆方向データを有するメッセージの、GREヘッダによる表示の形態を取ることができる。代替の実施形態では、ネットワークノード1は、逆方向のデータ転送をサポートするために新たなトンネルが用いられることを示すメッセージを受信してもよい。
【0014】
以前のアクティブなトンネル140およびトンネル150は、ATへの順方向のデータをサポートするために用いられてよい。したがって、データ方向に応じて、一定の期間にわたって、異なる複数のトンネルがATのデータ転送をサポートするために用いられる。次いで、メッセージがおそらくはトンネル170を介して送信され(すなわち、ネットワークノード1によって受信され)、新たなトンネルがATとの間の両方向のデータに現在用いられることを示す。
【0015】
図1では、本発明の様々な実施形態の機能的態様について、より一般的に示しているが、特定の実施形態についてのより詳細な記載によって、より一般的に記載した上述の実施形態を読手が理解し実装することが補助されると考えられる。以下に記載の実施形態を例として提供する。それらの実施形態を、本発明に関する特定の、充分に詳細な、例示の実施形態として提供する。それらの実施形態は、本発明の範囲を限定するものではなく、様々な可能な実施形態についての読手の理解を促進することを意図したものである。
【0016】
図2〜6は、本発明のより詳細な実施形態による、無線通信システムにおける複数の機能要素間において可能なトンネル構造を示すブロック図である。図の200,300,400,500,600のように、無線通信システムにおける異なる複数の機能要素を通じて、多くのデータアンカーおよびトンネルが設定され得る。例えば、eBS、移動電話交換局(MTSO)/MSC(移動交換局)、RNC、AGW、およびLMA(local mobility anchor)はすべて、データアンカーとして作用することができる。以下は、図の200に関する説明である。
・ATとeBSとの間を越えてセッションアンカー(Session Anchor)の経路を延長。
・セッションアンカーはsRNC自体であることも、eBS以外のsRNCによって割り当てられることも可能である。
・各々のANはATのSA経路を設定するように構成される、または信号を送信される。
・SA経路は構成された全範囲内において同じままである。
・各ANは1より多くのSAにアクセスを行うことができる。
【0017】
以下は、図3〜6に関する説明である。
−各々のプロキシ・データ経路アンカー(PDRA)は、標準によって提案されているようなデータアンカーとして作用する、すべてのプロトコルスタック(経路制御プロトコル)を有さなくてもよい。データアンカー経路はサービングeBSによって生成され、割り当てられた「アンカー」経路IDまたはIPを介して、eBSによって認識可能である。
−複数のプロキシデータトンネルは、PDRAとAGWとの間において、高速なeBS間ハンドオフと、アンカーハンドオフとのために、予め設定されることが可能である。
−データ・アンカー・ハンドオフは、1つのSRNCによって、または複数のeBSの間において、開始されることが可能である。
−PDRA/DAPはAN自体のうちの一部であってよい。
【0018】
図7〜15について詳細に説明する前に、何らかの前書きが有用であり得る。ここでは、ATに直接RF接続していないeBSがアクティブセットの別のeBSによって生成される経路を有し、同じサブネットまたは複数のサブネットのグループの任意のアクティブなeBSによって維持されることを可能とする、プロキシ経路の概念について記載する。また、そのような経路はネットワークアクセスゲートウェイ(AGW)へ接続するためのアンカー経路であり得ることについて記載する。これに加えて、それらのアンカー経路の一覧が、アンカーおよびATによって、また、その一覧に示されるサービングアンカーによって生成および維持され得る。次いで、ATは、ネットワーク内においてeBSからeBSへ移動するとき、サービングアンカーを選択することが可能である。これに加えて、1より多くのアンカー経路が可能とされる。アンカー経路は、サービング経路となる前に、ATのアンカー一覧へ追加されることが可能である。アンカーのネゴシエーションおよびコンテキストの転送は、アンカーハンドオフの前に実行されてもよい。
【0019】
各々のeBSは、セッションアンカーおよびデータアンカーの経路を生成することが可能である。eBSは、複数の経路と、セッションアンカーとを生成および維持することが可能である。また、eBSは、アンカー経路の生成、維持および非アクティブ化を行うために、他のeBSから要求を受信することが可能である。各々のeBSは、セッションおよびデータアンカーとの通信を行うために、1つ以上のトンネルのセットを維持する。
【0020】
アンカーは、AGWから分離されるとき、3GPP2仕様のA10/A11と同様のインタフェースを通じて、またはIETFプロトコルによって指定される単一のトンネルによって、ATの代わりにデータトンネルの確立を行う。ATが複数のサービングeBSへのアクセスを有するとき、それらのサービングeBSの各々は、AGWへのアクセスポイントとして作用することが可能である。複数のトンネルが、AGWを有するそれらのeBSの間に確立されることが可能である。ATは、同じAGWへの逆方向トラフィックのための複数のデータトンネルの各々を利用することが可能である。順方向トラフィックのためのトンネルは、アンカーとATとの間の実際の接続に基づき、開閉される。
【0021】
これによって、追加のトンネル、特にセッションおよびデータアンカーによって用いられるトンネルが、ATと直接RF接続していないときであっても、生成および維持されることが可能となる。すなわち、これによって、ATが維持することの可能なアクティブセットの大きさの制限のため、サービングアンカー(eBS)が別のアンカーへハンドオフを行わなければならないことは防止される。これによって、さらに、アクティブセットにないeBSがアンカーとして作用することが可能となる。
【0022】
これらの追加の性能によって、次の利点が得られる。
−アンカー場所の柔軟性。アンカー場所はスイッチ部であっても、ネットワークのいずれの場所であってもよい。
−アンカーのハンドオフの必要の減少。
−eBS間トラフィックの減少。
−現行のBTSが存在する場所にアンカーが配置されたとき、スポークバックホールを通じてトロンボーン様に行き来する必要のあるユーザトラフィックおよびシグナリングトラフィックを回避することによる、バックホール容量の必要性の減少。
−バックホールを通じてトロンボーン様に行き来するトラフィックによる追加の遅延の回避。
【0023】
以下に記載の実施形態は、VoIP、テレビ電話、音声および映像ストリーミングなどのリアルタイムサービスをよりよくサポートすることの可能な最適化された解決策に対する、現行の3GPP2 HRPDパケットデータネットワークの進化型におけるeBS/sRNCインタフェースフレームワークへのアクセスゲートウェイに適用可能である。提案のフレームワークは、3GPP2において現在開発されているUMBエアインタフェースを含む複数の多重接続技術を通じて用いることが可能である。詳細には、以下の記載は、アクセスネットワークとゲートウェイとの間のインタフェースにおけるプロキシモバイルIPに基づく、高度インタフェースアーキテクチャに適用可能である。
【0024】
この提案の主な目標は、エアインタフェースの遷移およびイベントのためAGWへ送信される信号の量を最小化することによって、ネットワーク内においてベアラ経路を設定する際の遅延を減少させることである。この提案によって、アクティブ/休止の遷移の切り替えまたは移動性の場合のデータアンカーの再割当の効率的な方法を提供するPMIPトンネルを、予め設定することが可能となる。この提案によって、アクセスネットワーク、例えば、sRNC、アンカーeBS(データ割当点)およびサービングeBSからAGWへ向けて、同じATに対する同時のPMIP結合が予め確立されることが可能となる。任意の瞬間において、トンネルの任意の方向には、1つのアクティブなトンネルしか存在することができない。トンネルコンテキストは、明示的なPMIPまたは制御信号送信の必要なく、sRNC/eBS(休止遷移中)または別のサービングeBS(DAP再割当)に切り替えられる。トンネルコンテキストは、ペイロードに加え、GREヘッダの一定の属性に基づき、切り替えられる。
【0025】
一部の仮定には、次が含まれる。
・ベアラトランスポートのためのRFC 1701に準拠したPMIP信号送信およびGREの使用。
・AGWに対する順方向・逆方向トラフィックの両方において、所与の時間にはアクティブなデータアンカーは1つのみ。
・ペイロードのないGREパケットを送信可能。
・AGWによって、単一のATについて複数の同時の結合が可能となる。
・GREのキーまたはシーケンス番号は、3GPP2特有のビットフィールドを有する。
【0026】
以下に記載の実施形態のうちの多くに関するさらなる幾つかの一般的な説明には、次が含まれる。
−データアンカー経路は、より少ない遅延およびデータ損失を保証するため、アクティブセットの変化に基づき選択される。
−サービングBSは、トンネルを開くよう、データアンカーに信号を送信することが可能である。データアンカーはトラフィックの二重送信(bi−cast)/同時送信をしない。
−データアンカーは、順方向リンクの前であっても、経路を通じて逆方向リンクデータを受信することが可能である。
−複数のトンネルを有することによって、必要な場合、休止中にセッションアンカー(例えば、sRNC)へデータが送信されることが可能となる。
【0027】
図7〜14は、本発明のより詳細な実施形態による、複数のトンネルの使用を示すメッセージフロー図である。フロー700には、高度な、AGWへのPMIPコンテキスト確立手順を示す。sRNCは、PMIPトンネルを確立させるために、アクセス認証の一部として実行されるEAP手順によるNAIを用いる。sRNCは、空のGREパケットを送信することによって、トンネルが依然としてアクティブでないことをAGWに示すことができる。空のGREパケットは、0のシーケンス番号を有する、すなわち、GREキー内のあるフィールドが0に設定されている(この提案においてはトラフィック属性と呼ぶ)。続いて、アンカーeBSが同時送信ビットの設定された別のPMIPトンネル結合を確立させると、ベアラを有するアンカーeBSは、0でないシーケンス番号を有する、すなわち、GREキーのトラフィック属性が一定の値に設定されたGREパケットを、AGWへ送信する。
【0028】
AGWへのアクティブなベアラトンネルを示す方法は、eBSまたはsRNCからのGREキー内の0でないシーケンス番号、すなわち、0でないフィールドの存在によることが可能である。コールフロー700では、eBSは、そのようなシーケンス番号の存在を介して、またはGREキー内のトラフィック属性フィールドがないことによって、アクティブなトンネルのピア(peer)を示す。sRNC/AGWは、トラフィック属性が存在しない、またはシーケンス番号が0に設定されている場合、別のピアへGREパケットを送信しない。
【0029】
フロー800には、高度な、AGWへのPMIPコンテキスト確立手順を示す。eBSは、PMIPトンネルを確立させるために、アクセスまたは加入(subscription)認証の一部として実行されるEAP手順によるNAIを用いる。eBSは、0のシーケンス番号を有する、すなわち、GREキー内のあるフィールドが0に設定された(この提案においてはトラフィック属性と呼ぶ)空のGREパケットを送信することによって、トンネルがアクティブでないことをAGWに示すことができる(注:この属性は、GREヘッダにおける3GPP2特有のフィールドを最小化する意図による、GREヘッダの修正の例として提案されている)。続いて、さらなるeBSが同時送信(S)ビットの設定された別のPMIPトンネル結合を確立させると、それらのeBSは、GREキーのトラフィック属性が0の値に設定された、ペイロードを有する/有しないGREパケットを、AGWへ送信する。GREキーの長さが短くなったとしても、トンネル当たりの総ユニークGREキーは依然として大きいままである。
【0030】
AGWへのアクティブなベアラトンネルを示す方法は、eBSからのGREキー内の0でないトラフィック属性フィールドの存在によることが可能である。コールフロー800では、eBSは、GREキー内のトラフィック属性フィールドを介して、アクティブなトンネルのピアを示す。AGWは、トラフィック属性が存在しない場合、別のピアへ(すなわち、別の方向へ)GREパケットを送信しない。
【0031】
eBSに対するアクティブセットの変化の影響について、以下に示す。ここでは、同時の結合によってPMIPトンネルを確立させる非データアンカーeBSを含む、すべてのeBSを示す。ネットワークが本明細書の範囲外の一定のトリガに基づきデータアンカーを切り替えるとき、新たなアンカーは、GREキーのトラフィック属性によって、または有効なシーケンス番号によって、AGWに対する切り替えを示すことができる。
【0032】
この提案では、サービングeBSがAGW(アンカーとなった)からデータを直接的に送信/受信する最も迅速な代替の方法のうちの1つを提供する。フロー900では、アクティブセットから現行のアンカーeBSを削除することは、新たなサービングeBSへのデータアンカー移動と同時に起こる。しかしながら、アクティブセットからアンカーeBSを削除することによって、常に新たなサービングeBSへのアンカー点移動が起きる必要はない。この提案では、アンカーeBS(DAP)とアクティブなGREトンネルとの間の関連が明確に識別される。
【0033】
この事前設定の機構によって、さらなる遅延およびさらなる3GPP2特有の信号送信を追加することなく、逆方向において新たなeBSからデータを送信する効率的な方法が提供される。また、FLSA(順方向リンクサービングAN)およびRLSA(逆方向リンクサービングAN)に対し、新たなデータアンカーとの間でベアラ転送が可能となる。
【0034】
eBSに対するアクティブセットの変化の代替の影響について、以下に示す。ここでは、同時の結合によってPMIPトンネルを確立させる非データアンカーeBSを含む、すべてのeBSを示す。フロー1000には、アクティブセットからDAPが除去された後であっても依然としてDAPを通じてデータのルーティングが行われるシナリオを示す。ネットワークは、ATが新たなサービングeBSへ移動した場合にも、依然としてDAP機能を係留しておくことが可能である。ネットワークが本明細書の範囲外の一定のトリガに基づきデータアンカーを切り替えるとき、新たなアンカーは、GREキーのトラフィック属性によって、AGWに対する切り替えを示すことができる。フロー1000では、アクティブセットからアンカーeBSを削除することによって、常に新たなサービングeBSへのアンカー点移動が起きる必要はない。この提案では、アンカーeBS(DAP)とアクティブなGREトンネルとの間の関連が明確に識別される。
【0035】
続く提案では、サービングeBSがAGWへデータを直接的に送信し、続いてAGW(アンカーとなった)からデータを受信する最も迅速な代替の方法のうちの1つを提供する。フロー1100では、現在のデータアンカーは、AGWへデータを直接的に送信することによって、新たなサービングeBSへ移動される。また、AGWは、広汎な信号送信なしで、ペイロードを有して/有しないで、GREキーにおける0でないトラフィック属性を新たなサービングeBSに送信することによって、順方向トンネルを切り替えることも可能である。また、既に実行されていない場合、これはATへのDAP移動のトリガを行うためにも用いられることが可能である。
【0036】
この事前設定の機構によって、アクティブセットが追加されるとき、さらなる遅延およびさらなる3GPP2特有の信号送信を追加することなく、逆方向において新たなeBSからデータを送信する効率的な方法が提供される。また、これによって、FLSAおよびRLSAに対し、新たなデータアンカーとの間のベアラ転送が可能となる。
【0037】
休止遷移におけるeBS、sRNCおよびAGWに対する影響について、フロー1200により以下に示す。非データアンカーeBSを含むすべてのeBSが、同時の結合によってPMIPトンネルを維持する。トンネル維持または受信者からの肯定応答手順では、GREキーのトラフィック属性のない空のGREパケット、すなわち、0のシーケンス番号が用いられることが可能である。アクティブなデータアンカーと休止中のsRNCとの間の遷移では、追加の信号送信なしで、GREキー表示内のトラフィックフィールドまたはシーケンス番号を有する事前設定されたPMIPトンネルが常に用いられる。休止からアクティブへの遷移の場合、データアンカーポイント(アンカーeBS)またはサービングeBSは、AGWへデータを直接的に送信することが可能である。この方法によって、遅延が減少され、サイドホールに対する効率が増大する。アクティブセットのsRNC/eBSとの間のデータ経路を予め確立する方法によって、データアンカーeBSの信頼性および可用性の提供も補助される。
【0038】
休止遷移におけるeBSおよびAGWに対する代替の影響について、フロー1300により以下に示す。非データアンカーeBSを含むすべてのeBSが、同時の結合によってPMIPトンネルを維持する。トンネル維持または受信者からの肯定応答手順では、GREキーのトラフィック属性のない空のGREパケットが用いられることが可能である。次のシナリオでは、ATがページトリガーのために再びアクティブとされるとき、ATが他の潜在的なFLSA/RLSAメンバとともにDAPカバレッジから移動していない場合について示す(注:ページのバッファ化がAGWにおいて実行されている場合、このトラフィック属性が、休止遷移中のAGWへのフロー制御の目的を提供することも可能である(FFS))。
【0039】
フロー1400による以下のシナリオでは、PMIPトンネルを確立させていない新たなeBSへ移動するATについて示す。休止からアクティブへの遷移の場合、データアンカーポイント(アンカーeBS)またはサービングeBSは、AGWへデータを直接的に送信し、データアンカー点を移動させることが可能である。eBSとの間のデータ経路を確立するこの方法によって、データアンカーeBSの信頼性および可用性の提供が補助される(注:上述のPMIP/GREの方法は、休止中のsRNC−AGWインタフェースまで拡張されることが可能であり、再アクティブ化中のページのバッファ化はsRNCにおいて必要とされる。シグナリングメッセージはFFSである)。
【0040】
上述の実施形態のうちの少なくとも一部に照らして、次の幾つかの利点が可能である。
−ネットワーク信号送信の遅延の減少。
−3GPP2特有の信号送信の減少による技術間ハンドオフの容易化。
−ベアラ遅延の減少。
−eBS間トラフィックを減少させることによるサイドホール効率の増大の可能性。
−DAP可用性に対する依存の低下。
【0041】
図15は、本発明のより詳細な実施形態による、修正されたキーフィールドを有するGREヘッダを示すブロック図である。FおよびRのフィールドは、トラフィックの方向ごとのトラフィック属性である(Fは順方向、Rは逆方向)。eBSは、トンネルを両方向に動かすために、FおよびRの両方のビットを設定することが可能である。しかしながら、eBSがPMIPトンネルを確立させた後、AGWはFビットのみを設定する。
【図面の簡単な説明】
【0042】
【図1】本発明の様々な実施形態による、複数のトンネルの使用を示すメッセージフロー図。
【図2】本発明のより詳細な実施形態による、無線通信システムにおける複数の機能要素間において可能なトンネル構造を示すブロック図。
【図3】本発明のより詳細な実施形態による、無線通信システムにおける複数の機能要素間において可能なトンネル構造を示すブロック図。
【図4】本発明のより詳細な実施形態による、無線通信システムにおける複数の機能要素間において可能なトンネル構造を示すブロック図。
【図5】本発明のより詳細な実施形態による、無線通信システムにおける複数の機能要素間において可能なトンネル構造を示すブロック図。
【図6】本発明のより詳細な実施形態による、無線通信システムにおける複数の機能要素間において可能なトンネル構造を示すブロック図。
【図7】本発明のより詳細な実施形態による、複数のトンネルの使用を示すメッセージフロー図。
【図8】本発明のより詳細な実施形態による、複数のトンネルの使用を示すメッセージフロー図。
【図9】本発明のより詳細な実施形態による、複数のトンネルの使用を示すメッセージフロー図。
【図10】本発明のより詳細な実施形態による、複数のトンネルの使用を示すメッセージフロー図。
【図11】本発明のより詳細な実施形態による、複数のトンネルの使用を示すメッセージフロー図。
【図12】本発明のより詳細な実施形態による、複数のトンネルの使用を示すメッセージフロー図。
【図13】本発明のより詳細な実施形態による、複数のトンネルの使用を示すメッセージフロー図。
【図14】本発明のより詳細な実施形態による、複数のトンネルの使用を示すメッセージフロー図。
【図15】本発明のより詳細な実施形態による、修正されたキーフィールドを有するGREヘッダを示すブロック図。
【技術分野】
【0001】
本発明は通信システムに関する。詳細には、本発明は通信ネットワーク内において複数のトンネルを用いることに関する。
【背景技術】
【0002】
様々な無線通信技術が、VoIP(ボイス・オーバ・インターネット・プロトコル)、テレビ電話(Video Telephony)、音声および映像ストリーミングなどのリアルタイムサービスをサポートするために開発されている。移動体装置にそのようなサービスを提供することによって、特に、通信システムを通じて移動し、1つの基地局(BS)またはアクセス・ネットワーク(AN)から次のものへとハンドオフを行っている装置について、多くの課題が生まれる。通常、データトンネルは、移動体装置との間のベアラトラフィックを処理するために、サービングBS/ANからデータゲートウェイ装置へと設定される。この経路は、この経路に沿ったアンカーとして作用する複数のネットワークノード、装置またはその両方を含む場合がある。一連のトンネルが、ベアラ経路を提供するために、複数のアンカーの間に確立され得る。移動体装置はシステムを通じてハンドオフを行うので、ベアラ経路は、移動体に付き従うために、新たなトンネルおよびアンカーを確立することによって変更される必要がある。そのようなデータ経路の切替によって、さらなる遅延、途絶またはその両方がリアルタイムサービスに導入され得る。
【発明の開示】
【発明が解決しようとする課題】
【0003】
したがって、当技術を進歩させるためには、移動イベント中にリアルタイムサービスをよりよくサポートすることの可能な新たな技術が明らかに所望される。
【課題を解決するための手段】
【0004】
様々な実施形態について記載する。それらの実施形態のうちの一部は、通信ネットワークにおける移動イベント中にリアルタイムサービスをよりよくサポートすることが可能である。一般に、それらの実施形態では、アクセス端末(AT)への順方向およびATからの逆方向の両方におけるデータ転送をサポートするために、通信ネットワーク内の異なる複数のネットワークノードを介して複数のトンネルが確立される。順方向のデータ転送は、一定の期間にわたって複数のトンネルのうちの第1のトンネルを介してサポートされ、逆方向のデータ転送は、同じ期間にわたって第2の異なるトンネルを介してサポートされる。
【発明を実施するための最良の形態】
【0005】
開示の実施形態は、図1〜15を参照することによって、より完全に理解され得る。図1は、本発明の様々な実施形態による、複数のトンネルの使用を示すメッセージフロー100である。現在、OMA(Open Mobile Alliance)、3GPP(3rd Generation Partnership Project)、3GPP2(3rd Generation Partnership Project 2)、IEEE(Institute of Electrical and Electronics Engineers)802およびWiMAXフォーラムなどの標準機構が、無線通信システム用の標準仕様を開発している(これらの団体には、それぞれ、http://www.openmobilealliance.com,http://www.3gpp.org/,http://www.3gpp2.com/,http://www.ieee802.org/,http://www.wimaxforum.org/を介して連絡することができる)。メッセージフロー100では、一般に、ネットワークノード1〜3をメッセージ送信の端点として示す。ネットワークノード1〜3によって表される通信ネットワークは、本発明を実装するように適切に修正された、3GPP2、3GPP、WiMAXフォーラム、およびIEEE 802のうちの1つ以上の技術によるアーキテクチャを有するシステムである。
【0006】
ネットワークノード1〜3については、非常に一般化して示す。図1には通信ネットワークが動作するのに必要であり得る物理的な固定のネットワーク構成要素のすべてが示されているのではなく、本明細書における実施形態の記載に特に関連するシステム構成要素および論理的なエンティティのみが示されていることが、当業者には認められる。例えば、示してはいないが、ネットワークノード1,3は、無線インタフェースを用いて、アクセス端末(AT)にネットワーク・サービスを提供する。用いられる無線インタフェースは、各々のネットワークノードによってそれぞれサポートされる特定の接続技術による。例えば、それらの無線インタフェースはすべて、3GPP2仕様またはIEEE 802.16に基づく技術など、同じ技術を利用してもよく、異なる複数の接続技術を利用してもよい。
【0007】
また、図1には、ネットワークノード1〜3が各々、処理装置およびネットワークインタフェースを備えることを示していない。これに加えて、ネットワークノード1,3は各々、無線トランシーバを備える。一般に、処理装置、トランシーバおよびネットワークインタフェースなどの構成要素は周知である。例えば、処理装置が、マイクロプロセッサ、マイクロコントローラ、メモリ装置、特定用途向け集積回路(ASIC)、および論理回路(これらに限定されず、また必ずしも必要ではないが)のうちの1つ以上などの基本的な構成要素を含むことは周知である。そのような構成要素は、通常、高度設計言語もしくは記述、コンピュータ命令、信号/メッセージフロー図、および論理フロー図のうちの1つ以上を用いて表現された、アルゴリズム、プロトコルまたはその両方を実装するように適合されている。
【0008】
すなわち、高度記述、アルゴリズム、論理フロー、メッセージ/信号フロー、およびプロトコル仕様のうちの1つ以上が与えられれば、当業者には、その与えられた論理を実行する処理装置を実装するために利用可能な多くの設計・開発技術が認識される。したがって、ネットワークノード1〜3は、本明細書の記載にしたがって、本発明の複数の実施形態を実装するように適合された周知の装置を表す。さらに、本発明の態様は様々な物理的な構成要素において、または様々な物理的な構成要素を通じて実装されてよく、必ずしも単一のプラットフォームの実装に限定されないことが、当業者には認識される。例えば、ネットワークノードは、基地局トランシーバ(BTS)、基地局コントローラ(BSC)、基地局(BS)(例えば、強化されたBS(eBS))、ノードB、無線ネットワークコントローラ(RNC)(例えば、シグナリングRNC(sRNC))、HRPDアクセスネットワーク(AN)、HRPDパケット制御機能(PCF)、アクセスサービスネットワーク(ASN)ゲートウェイ、アクセスゲートウェイ(AGW)、ASN基地局、アクセスポイント(AP)、広帯域基地局(WBS)、およびWLAN(無線ローカルエリアネットワーク)局のうちの1つ以上など、1つ以上の通信ネットワーク構成要素において、または1つ以上の通信ネットワーク構成要素を通じて実装されてよい。
【0009】
アクセス端末(AT)、移動体装置、リモートユニット、加入者局(SS)、およびユーザ機器(UE)のうちの1つ以上は、移動局(MS)、移動体加入者局(MSS)または移動体ノード(MN)と考えられてよい。加えて、ATプラットフォームは、次に限定されないが、移動局(MS)、端末装置、リモートユニット、ゲーム装置、パーソナルコンピュータおよび携帯情報端末(PDA)など、多種多様な消費者向け電子プラットフォームを表すものとして知られている。詳細には、ATは各々、処理装置およびトランシーバを備える。実施形態によって、ATは各々、さらに、キーパッド、スピーカ、マイクロホンおよびディスプレイを備える場合がある。ATにおいて用いられる処理装置、トランシーバ、キーパッド、スピーカ、マイクロホンおよびディスプレイはすべて、当技術において周知である。
【0010】
本発明による実施形態の動作は、ほぼ以下のように行われる。最初に図1を参照する。図1に示すように、ネットワークノード2およびネットワークノード3は、ATのデータ転送をサポートするためのトンネル110を有する。図示の目的のため、ネットワークノード3はATのサービングノードであると仮定し、トンネル110はアクティブであり、ATへの順方向およびATからの逆方向の両方におけるデータ転送をサポートするために用いられていると仮定する。
【0011】
ある時点において、ネットワークノード1は、ネットワークノード1とネットワークノード2との間にトンネルを確立させるため、ネットワークノード2へメッセージ120を送信する。対象の実施形態および状況に応じて、多くのイベントによってネットワークノード1にメッセージ120を送信させることができる。例えば、ネットワークノード1は、ネットワークノード1がATのアクティブセットに追加されたこと、またはATがネットワークノード1へのハンドオフを望むことの表示の受信に応答して、メッセージ120を送信してもよい。これに代えて、例えば、近いうちにATがネットワークノード1へハンドオフを行うことを通信ネットワークが予想していてもよく、ATが近い将来にネットワークノード1へハンドオフを行うことの可能性に基づき、通信ネットワークがトンネルを設定していてもよい。
【0012】
実際に送信されるメッセージの種類は、多分に実施形態による。例えば、メッセージ120は、PMIP(Proxy Mobile Internet Protocol)メッセージを含み得る。PMIPメッセージは、PMIP BU(結合の更新)メッセージなど、PMIPトンネルを確立させるためのメッセージである。このメッセージによって、または何らかの他のメッセージによっても、逆方向または順方向のデータ転送をサポートするためにトンネルが現在用いられ始めるか否かを示すことができる。例えば、単純にパラメータによってこのことを示してもよく、あるいは、GRE(generic route encapsulation)キーなどのパラメータ内において順方向および逆方向に対応するビットが用いられてもよい。
【0013】
図示の目的のため、メッセージ120が、逆方向または順方向のデータ転送をサポートするためにトンネルが用いられ始められないことを示した、と仮定する。したがって、新たなトンネル130は、最初はアクティブでないままである。しかしながら、ネットワークノード1がATのサービングネットワークノードとなるなどのイベントによって、新たなトンネルをトンネル160のようにアクティブとすることができる。例えば、ネットワークノード1は、逆方向のデータ転送をサポートするために新たなトンネルが用いられることを示すメッセージを、ネットワークノード2へ送信することができる。このメッセージは、トンネル160を介して送信されるメッセージ、おそらくは逆方向データを有するメッセージの、GREヘッダによる表示の形態を取ることができる。代替の実施形態では、ネットワークノード1は、逆方向のデータ転送をサポートするために新たなトンネルが用いられることを示すメッセージを受信してもよい。
【0014】
以前のアクティブなトンネル140およびトンネル150は、ATへの順方向のデータをサポートするために用いられてよい。したがって、データ方向に応じて、一定の期間にわたって、異なる複数のトンネルがATのデータ転送をサポートするために用いられる。次いで、メッセージがおそらくはトンネル170を介して送信され(すなわち、ネットワークノード1によって受信され)、新たなトンネルがATとの間の両方向のデータに現在用いられることを示す。
【0015】
図1では、本発明の様々な実施形態の機能的態様について、より一般的に示しているが、特定の実施形態についてのより詳細な記載によって、より一般的に記載した上述の実施形態を読手が理解し実装することが補助されると考えられる。以下に記載の実施形態を例として提供する。それらの実施形態を、本発明に関する特定の、充分に詳細な、例示の実施形態として提供する。それらの実施形態は、本発明の範囲を限定するものではなく、様々な可能な実施形態についての読手の理解を促進することを意図したものである。
【0016】
図2〜6は、本発明のより詳細な実施形態による、無線通信システムにおける複数の機能要素間において可能なトンネル構造を示すブロック図である。図の200,300,400,500,600のように、無線通信システムにおける異なる複数の機能要素を通じて、多くのデータアンカーおよびトンネルが設定され得る。例えば、eBS、移動電話交換局(MTSO)/MSC(移動交換局)、RNC、AGW、およびLMA(local mobility anchor)はすべて、データアンカーとして作用することができる。以下は、図の200に関する説明である。
・ATとeBSとの間を越えてセッションアンカー(Session Anchor)の経路を延長。
・セッションアンカーはsRNC自体であることも、eBS以外のsRNCによって割り当てられることも可能である。
・各々のANはATのSA経路を設定するように構成される、または信号を送信される。
・SA経路は構成された全範囲内において同じままである。
・各ANは1より多くのSAにアクセスを行うことができる。
【0017】
以下は、図3〜6に関する説明である。
−各々のプロキシ・データ経路アンカー(PDRA)は、標準によって提案されているようなデータアンカーとして作用する、すべてのプロトコルスタック(経路制御プロトコル)を有さなくてもよい。データアンカー経路はサービングeBSによって生成され、割り当てられた「アンカー」経路IDまたはIPを介して、eBSによって認識可能である。
−複数のプロキシデータトンネルは、PDRAとAGWとの間において、高速なeBS間ハンドオフと、アンカーハンドオフとのために、予め設定されることが可能である。
−データ・アンカー・ハンドオフは、1つのSRNCによって、または複数のeBSの間において、開始されることが可能である。
−PDRA/DAPはAN自体のうちの一部であってよい。
【0018】
図7〜15について詳細に説明する前に、何らかの前書きが有用であり得る。ここでは、ATに直接RF接続していないeBSがアクティブセットの別のeBSによって生成される経路を有し、同じサブネットまたは複数のサブネットのグループの任意のアクティブなeBSによって維持されることを可能とする、プロキシ経路の概念について記載する。また、そのような経路はネットワークアクセスゲートウェイ(AGW)へ接続するためのアンカー経路であり得ることについて記載する。これに加えて、それらのアンカー経路の一覧が、アンカーおよびATによって、また、その一覧に示されるサービングアンカーによって生成および維持され得る。次いで、ATは、ネットワーク内においてeBSからeBSへ移動するとき、サービングアンカーを選択することが可能である。これに加えて、1より多くのアンカー経路が可能とされる。アンカー経路は、サービング経路となる前に、ATのアンカー一覧へ追加されることが可能である。アンカーのネゴシエーションおよびコンテキストの転送は、アンカーハンドオフの前に実行されてもよい。
【0019】
各々のeBSは、セッションアンカーおよびデータアンカーの経路を生成することが可能である。eBSは、複数の経路と、セッションアンカーとを生成および維持することが可能である。また、eBSは、アンカー経路の生成、維持および非アクティブ化を行うために、他のeBSから要求を受信することが可能である。各々のeBSは、セッションおよびデータアンカーとの通信を行うために、1つ以上のトンネルのセットを維持する。
【0020】
アンカーは、AGWから分離されるとき、3GPP2仕様のA10/A11と同様のインタフェースを通じて、またはIETFプロトコルによって指定される単一のトンネルによって、ATの代わりにデータトンネルの確立を行う。ATが複数のサービングeBSへのアクセスを有するとき、それらのサービングeBSの各々は、AGWへのアクセスポイントとして作用することが可能である。複数のトンネルが、AGWを有するそれらのeBSの間に確立されることが可能である。ATは、同じAGWへの逆方向トラフィックのための複数のデータトンネルの各々を利用することが可能である。順方向トラフィックのためのトンネルは、アンカーとATとの間の実際の接続に基づき、開閉される。
【0021】
これによって、追加のトンネル、特にセッションおよびデータアンカーによって用いられるトンネルが、ATと直接RF接続していないときであっても、生成および維持されることが可能となる。すなわち、これによって、ATが維持することの可能なアクティブセットの大きさの制限のため、サービングアンカー(eBS)が別のアンカーへハンドオフを行わなければならないことは防止される。これによって、さらに、アクティブセットにないeBSがアンカーとして作用することが可能となる。
【0022】
これらの追加の性能によって、次の利点が得られる。
−アンカー場所の柔軟性。アンカー場所はスイッチ部であっても、ネットワークのいずれの場所であってもよい。
−アンカーのハンドオフの必要の減少。
−eBS間トラフィックの減少。
−現行のBTSが存在する場所にアンカーが配置されたとき、スポークバックホールを通じてトロンボーン様に行き来する必要のあるユーザトラフィックおよびシグナリングトラフィックを回避することによる、バックホール容量の必要性の減少。
−バックホールを通じてトロンボーン様に行き来するトラフィックによる追加の遅延の回避。
【0023】
以下に記載の実施形態は、VoIP、テレビ電話、音声および映像ストリーミングなどのリアルタイムサービスをよりよくサポートすることの可能な最適化された解決策に対する、現行の3GPP2 HRPDパケットデータネットワークの進化型におけるeBS/sRNCインタフェースフレームワークへのアクセスゲートウェイに適用可能である。提案のフレームワークは、3GPP2において現在開発されているUMBエアインタフェースを含む複数の多重接続技術を通じて用いることが可能である。詳細には、以下の記載は、アクセスネットワークとゲートウェイとの間のインタフェースにおけるプロキシモバイルIPに基づく、高度インタフェースアーキテクチャに適用可能である。
【0024】
この提案の主な目標は、エアインタフェースの遷移およびイベントのためAGWへ送信される信号の量を最小化することによって、ネットワーク内においてベアラ経路を設定する際の遅延を減少させることである。この提案によって、アクティブ/休止の遷移の切り替えまたは移動性の場合のデータアンカーの再割当の効率的な方法を提供するPMIPトンネルを、予め設定することが可能となる。この提案によって、アクセスネットワーク、例えば、sRNC、アンカーeBS(データ割当点)およびサービングeBSからAGWへ向けて、同じATに対する同時のPMIP結合が予め確立されることが可能となる。任意の瞬間において、トンネルの任意の方向には、1つのアクティブなトンネルしか存在することができない。トンネルコンテキストは、明示的なPMIPまたは制御信号送信の必要なく、sRNC/eBS(休止遷移中)または別のサービングeBS(DAP再割当)に切り替えられる。トンネルコンテキストは、ペイロードに加え、GREヘッダの一定の属性に基づき、切り替えられる。
【0025】
一部の仮定には、次が含まれる。
・ベアラトランスポートのためのRFC 1701に準拠したPMIP信号送信およびGREの使用。
・AGWに対する順方向・逆方向トラフィックの両方において、所与の時間にはアクティブなデータアンカーは1つのみ。
・ペイロードのないGREパケットを送信可能。
・AGWによって、単一のATについて複数の同時の結合が可能となる。
・GREのキーまたはシーケンス番号は、3GPP2特有のビットフィールドを有する。
【0026】
以下に記載の実施形態のうちの多くに関するさらなる幾つかの一般的な説明には、次が含まれる。
−データアンカー経路は、より少ない遅延およびデータ損失を保証するため、アクティブセットの変化に基づき選択される。
−サービングBSは、トンネルを開くよう、データアンカーに信号を送信することが可能である。データアンカーはトラフィックの二重送信(bi−cast)/同時送信をしない。
−データアンカーは、順方向リンクの前であっても、経路を通じて逆方向リンクデータを受信することが可能である。
−複数のトンネルを有することによって、必要な場合、休止中にセッションアンカー(例えば、sRNC)へデータが送信されることが可能となる。
【0027】
図7〜14は、本発明のより詳細な実施形態による、複数のトンネルの使用を示すメッセージフロー図である。フロー700には、高度な、AGWへのPMIPコンテキスト確立手順を示す。sRNCは、PMIPトンネルを確立させるために、アクセス認証の一部として実行されるEAP手順によるNAIを用いる。sRNCは、空のGREパケットを送信することによって、トンネルが依然としてアクティブでないことをAGWに示すことができる。空のGREパケットは、0のシーケンス番号を有する、すなわち、GREキー内のあるフィールドが0に設定されている(この提案においてはトラフィック属性と呼ぶ)。続いて、アンカーeBSが同時送信ビットの設定された別のPMIPトンネル結合を確立させると、ベアラを有するアンカーeBSは、0でないシーケンス番号を有する、すなわち、GREキーのトラフィック属性が一定の値に設定されたGREパケットを、AGWへ送信する。
【0028】
AGWへのアクティブなベアラトンネルを示す方法は、eBSまたはsRNCからのGREキー内の0でないシーケンス番号、すなわち、0でないフィールドの存在によることが可能である。コールフロー700では、eBSは、そのようなシーケンス番号の存在を介して、またはGREキー内のトラフィック属性フィールドがないことによって、アクティブなトンネルのピア(peer)を示す。sRNC/AGWは、トラフィック属性が存在しない、またはシーケンス番号が0に設定されている場合、別のピアへGREパケットを送信しない。
【0029】
フロー800には、高度な、AGWへのPMIPコンテキスト確立手順を示す。eBSは、PMIPトンネルを確立させるために、アクセスまたは加入(subscription)認証の一部として実行されるEAP手順によるNAIを用いる。eBSは、0のシーケンス番号を有する、すなわち、GREキー内のあるフィールドが0に設定された(この提案においてはトラフィック属性と呼ぶ)空のGREパケットを送信することによって、トンネルがアクティブでないことをAGWに示すことができる(注:この属性は、GREヘッダにおける3GPP2特有のフィールドを最小化する意図による、GREヘッダの修正の例として提案されている)。続いて、さらなるeBSが同時送信(S)ビットの設定された別のPMIPトンネル結合を確立させると、それらのeBSは、GREキーのトラフィック属性が0の値に設定された、ペイロードを有する/有しないGREパケットを、AGWへ送信する。GREキーの長さが短くなったとしても、トンネル当たりの総ユニークGREキーは依然として大きいままである。
【0030】
AGWへのアクティブなベアラトンネルを示す方法は、eBSからのGREキー内の0でないトラフィック属性フィールドの存在によることが可能である。コールフロー800では、eBSは、GREキー内のトラフィック属性フィールドを介して、アクティブなトンネルのピアを示す。AGWは、トラフィック属性が存在しない場合、別のピアへ(すなわち、別の方向へ)GREパケットを送信しない。
【0031】
eBSに対するアクティブセットの変化の影響について、以下に示す。ここでは、同時の結合によってPMIPトンネルを確立させる非データアンカーeBSを含む、すべてのeBSを示す。ネットワークが本明細書の範囲外の一定のトリガに基づきデータアンカーを切り替えるとき、新たなアンカーは、GREキーのトラフィック属性によって、または有効なシーケンス番号によって、AGWに対する切り替えを示すことができる。
【0032】
この提案では、サービングeBSがAGW(アンカーとなった)からデータを直接的に送信/受信する最も迅速な代替の方法のうちの1つを提供する。フロー900では、アクティブセットから現行のアンカーeBSを削除することは、新たなサービングeBSへのデータアンカー移動と同時に起こる。しかしながら、アクティブセットからアンカーeBSを削除することによって、常に新たなサービングeBSへのアンカー点移動が起きる必要はない。この提案では、アンカーeBS(DAP)とアクティブなGREトンネルとの間の関連が明確に識別される。
【0033】
この事前設定の機構によって、さらなる遅延およびさらなる3GPP2特有の信号送信を追加することなく、逆方向において新たなeBSからデータを送信する効率的な方法が提供される。また、FLSA(順方向リンクサービングAN)およびRLSA(逆方向リンクサービングAN)に対し、新たなデータアンカーとの間でベアラ転送が可能となる。
【0034】
eBSに対するアクティブセットの変化の代替の影響について、以下に示す。ここでは、同時の結合によってPMIPトンネルを確立させる非データアンカーeBSを含む、すべてのeBSを示す。フロー1000には、アクティブセットからDAPが除去された後であっても依然としてDAPを通じてデータのルーティングが行われるシナリオを示す。ネットワークは、ATが新たなサービングeBSへ移動した場合にも、依然としてDAP機能を係留しておくことが可能である。ネットワークが本明細書の範囲外の一定のトリガに基づきデータアンカーを切り替えるとき、新たなアンカーは、GREキーのトラフィック属性によって、AGWに対する切り替えを示すことができる。フロー1000では、アクティブセットからアンカーeBSを削除することによって、常に新たなサービングeBSへのアンカー点移動が起きる必要はない。この提案では、アンカーeBS(DAP)とアクティブなGREトンネルとの間の関連が明確に識別される。
【0035】
続く提案では、サービングeBSがAGWへデータを直接的に送信し、続いてAGW(アンカーとなった)からデータを受信する最も迅速な代替の方法のうちの1つを提供する。フロー1100では、現在のデータアンカーは、AGWへデータを直接的に送信することによって、新たなサービングeBSへ移動される。また、AGWは、広汎な信号送信なしで、ペイロードを有して/有しないで、GREキーにおける0でないトラフィック属性を新たなサービングeBSに送信することによって、順方向トンネルを切り替えることも可能である。また、既に実行されていない場合、これはATへのDAP移動のトリガを行うためにも用いられることが可能である。
【0036】
この事前設定の機構によって、アクティブセットが追加されるとき、さらなる遅延およびさらなる3GPP2特有の信号送信を追加することなく、逆方向において新たなeBSからデータを送信する効率的な方法が提供される。また、これによって、FLSAおよびRLSAに対し、新たなデータアンカーとの間のベアラ転送が可能となる。
【0037】
休止遷移におけるeBS、sRNCおよびAGWに対する影響について、フロー1200により以下に示す。非データアンカーeBSを含むすべてのeBSが、同時の結合によってPMIPトンネルを維持する。トンネル維持または受信者からの肯定応答手順では、GREキーのトラフィック属性のない空のGREパケット、すなわち、0のシーケンス番号が用いられることが可能である。アクティブなデータアンカーと休止中のsRNCとの間の遷移では、追加の信号送信なしで、GREキー表示内のトラフィックフィールドまたはシーケンス番号を有する事前設定されたPMIPトンネルが常に用いられる。休止からアクティブへの遷移の場合、データアンカーポイント(アンカーeBS)またはサービングeBSは、AGWへデータを直接的に送信することが可能である。この方法によって、遅延が減少され、サイドホールに対する効率が増大する。アクティブセットのsRNC/eBSとの間のデータ経路を予め確立する方法によって、データアンカーeBSの信頼性および可用性の提供も補助される。
【0038】
休止遷移におけるeBSおよびAGWに対する代替の影響について、フロー1300により以下に示す。非データアンカーeBSを含むすべてのeBSが、同時の結合によってPMIPトンネルを維持する。トンネル維持または受信者からの肯定応答手順では、GREキーのトラフィック属性のない空のGREパケットが用いられることが可能である。次のシナリオでは、ATがページトリガーのために再びアクティブとされるとき、ATが他の潜在的なFLSA/RLSAメンバとともにDAPカバレッジから移動していない場合について示す(注:ページのバッファ化がAGWにおいて実行されている場合、このトラフィック属性が、休止遷移中のAGWへのフロー制御の目的を提供することも可能である(FFS))。
【0039】
フロー1400による以下のシナリオでは、PMIPトンネルを確立させていない新たなeBSへ移動するATについて示す。休止からアクティブへの遷移の場合、データアンカーポイント(アンカーeBS)またはサービングeBSは、AGWへデータを直接的に送信し、データアンカー点を移動させることが可能である。eBSとの間のデータ経路を確立するこの方法によって、データアンカーeBSの信頼性および可用性の提供が補助される(注:上述のPMIP/GREの方法は、休止中のsRNC−AGWインタフェースまで拡張されることが可能であり、再アクティブ化中のページのバッファ化はsRNCにおいて必要とされる。シグナリングメッセージはFFSである)。
【0040】
上述の実施形態のうちの少なくとも一部に照らして、次の幾つかの利点が可能である。
−ネットワーク信号送信の遅延の減少。
−3GPP2特有の信号送信の減少による技術間ハンドオフの容易化。
−ベアラ遅延の減少。
−eBS間トラフィックを減少させることによるサイドホール効率の増大の可能性。
−DAP可用性に対する依存の低下。
【0041】
図15は、本発明のより詳細な実施形態による、修正されたキーフィールドを有するGREヘッダを示すブロック図である。FおよびRのフィールドは、トラフィックの方向ごとのトラフィック属性である(Fは順方向、Rは逆方向)。eBSは、トンネルを両方向に動かすために、FおよびRの両方のビットを設定することが可能である。しかしながら、eBSがPMIPトンネルを確立させた後、AGWはFビットのみを設定する。
【図面の簡単な説明】
【0042】
【図1】本発明の様々な実施形態による、複数のトンネルの使用を示すメッセージフロー図。
【図2】本発明のより詳細な実施形態による、無線通信システムにおける複数の機能要素間において可能なトンネル構造を示すブロック図。
【図3】本発明のより詳細な実施形態による、無線通信システムにおける複数の機能要素間において可能なトンネル構造を示すブロック図。
【図4】本発明のより詳細な実施形態による、無線通信システムにおける複数の機能要素間において可能なトンネル構造を示すブロック図。
【図5】本発明のより詳細な実施形態による、無線通信システムにおける複数の機能要素間において可能なトンネル構造を示すブロック図。
【図6】本発明のより詳細な実施形態による、無線通信システムにおける複数の機能要素間において可能なトンネル構造を示すブロック図。
【図7】本発明のより詳細な実施形態による、複数のトンネルの使用を示すメッセージフロー図。
【図8】本発明のより詳細な実施形態による、複数のトンネルの使用を示すメッセージフロー図。
【図9】本発明のより詳細な実施形態による、複数のトンネルの使用を示すメッセージフロー図。
【図10】本発明のより詳細な実施形態による、複数のトンネルの使用を示すメッセージフロー図。
【図11】本発明のより詳細な実施形態による、複数のトンネルの使用を示すメッセージフロー図。
【図12】本発明のより詳細な実施形態による、複数のトンネルの使用を示すメッセージフロー図。
【図13】本発明のより詳細な実施形態による、複数のトンネルの使用を示すメッセージフロー図。
【図14】本発明のより詳細な実施形態による、複数のトンネルの使用を示すメッセージフロー図。
【図15】本発明のより詳細な実施形態による、修正されたキーフィールドを有するGREヘッダを示すブロック図。
【特許請求の範囲】
【請求項1】
通信ネットワーク内において複数のトンネルを用いる方法であって、
アクセス端末(AT)への順方向およびATからの逆方向の両方におけるデータ転送をサポートするために、通信ネットワーク内の異なる複数のネットワークノードを介して複数のトンネルを確立する工程と、
一定の期間にわたって複数のトンネルのうちの第1のトンネルを介して順方向のデータ転送をサポートする工程と、
同期間にわたって複数のトンネルのうちの第2のトンネルを介して逆方向のデータ転送をサポートする工程と、第1のトンネルは第2のトンネルと異なることと、
を含む方法。
【請求項2】
前記同期間にわたってさらに第1のトンネルを介して逆方向のデータ転送をサポートする工程を含む請求項1に記載の方法。
【請求項3】
一定の期間にわたって第1のトンネルを介して順方向のデータ転送をサポートする工程は、一定の期間にわたって第1のトンネルのみを介して順方向のデータ転送をサポートする工程を含む請求項1に記載の方法。
【請求項4】
同期間にわたって第2のトンネルを介して逆方向のデータ転送をサポートする工程は、同期間にわたって第2のトンネルのみを介して逆方向のデータ転送をサポートする工程を含む請求項1に記載の方法。
【請求項5】
前記期間の終わりに、順方向のデータ転送のサポートを第1のトンネルから第2のトンネルへ切り替える工程を含む請求項1に記載の方法。
【請求項6】
前記期間の終わりに、逆方向のデータ転送のサポートを第2のトンネルから第1のトンネルへ切り替える工程を含む請求項1に記載の方法。
【請求項7】
通信ネットワーク内において複数のトンネルを用いる方法であって、
アクセス端末(AT)のデータ転送をサポートするために、第1のネットワークノードによるメッセージを第2のネットワークノードへ送信して、第1のネットワークノードと第2のネットワークノードとの間に第1のトンネルを確立する工程と、第2のネットワークノードはATのデータ転送をサポートするために第3のネットワークノードとの第2のトンネルを有することと、
一定の期間にわたって第1のトンネルを介して、ATからの逆方向およびATへの順方向のうちの一方のデータ転送をサポートし、かつ、他方のデータ転送をサポートしない工程と、
前記期間に続き、第1のトンネルを介してATからの逆方向およびATへの順方向の両方のデータ転送をサポートする工程と、を含む方法。
【請求項8】
メッセージを送信して第1のトンネルを確立する工程は、第1のネットワークノードがATのアクティブセットに追加されたことの表示の受信に応答して、メッセージを送信して第1のトンネルを確立する工程を含む請求項7に記載の方法。
【請求項9】
メッセージを送信して第1のトンネルを確立する工程は、逆方向および順方向のうちの一方または両方のデータ転送をサポートするために第1のトンネルが現在用いられ始めるか否かを示す工程を含む請求項7に記載の方法。
【請求項10】
逆方向および順方向のうちの一方または両方のデータ転送をサポートするために第1のトンネルが用いられることを示す第1のネットワークノードによるメッセージを第2のネットワークノードへ送信する工程を含む請求項7に記載の方法。
【請求項1】
通信ネットワーク内において複数のトンネルを用いる方法であって、
アクセス端末(AT)への順方向およびATからの逆方向の両方におけるデータ転送をサポートするために、通信ネットワーク内の異なる複数のネットワークノードを介して複数のトンネルを確立する工程と、
一定の期間にわたって複数のトンネルのうちの第1のトンネルを介して順方向のデータ転送をサポートする工程と、
同期間にわたって複数のトンネルのうちの第2のトンネルを介して逆方向のデータ転送をサポートする工程と、第1のトンネルは第2のトンネルと異なることと、
を含む方法。
【請求項2】
前記同期間にわたってさらに第1のトンネルを介して逆方向のデータ転送をサポートする工程を含む請求項1に記載の方法。
【請求項3】
一定の期間にわたって第1のトンネルを介して順方向のデータ転送をサポートする工程は、一定の期間にわたって第1のトンネルのみを介して順方向のデータ転送をサポートする工程を含む請求項1に記載の方法。
【請求項4】
同期間にわたって第2のトンネルを介して逆方向のデータ転送をサポートする工程は、同期間にわたって第2のトンネルのみを介して逆方向のデータ転送をサポートする工程を含む請求項1に記載の方法。
【請求項5】
前記期間の終わりに、順方向のデータ転送のサポートを第1のトンネルから第2のトンネルへ切り替える工程を含む請求項1に記載の方法。
【請求項6】
前記期間の終わりに、逆方向のデータ転送のサポートを第2のトンネルから第1のトンネルへ切り替える工程を含む請求項1に記載の方法。
【請求項7】
通信ネットワーク内において複数のトンネルを用いる方法であって、
アクセス端末(AT)のデータ転送をサポートするために、第1のネットワークノードによるメッセージを第2のネットワークノードへ送信して、第1のネットワークノードと第2のネットワークノードとの間に第1のトンネルを確立する工程と、第2のネットワークノードはATのデータ転送をサポートするために第3のネットワークノードとの第2のトンネルを有することと、
一定の期間にわたって第1のトンネルを介して、ATからの逆方向およびATへの順方向のうちの一方のデータ転送をサポートし、かつ、他方のデータ転送をサポートしない工程と、
前記期間に続き、第1のトンネルを介してATからの逆方向およびATへの順方向の両方のデータ転送をサポートする工程と、を含む方法。
【請求項8】
メッセージを送信して第1のトンネルを確立する工程は、第1のネットワークノードがATのアクティブセットに追加されたことの表示の受信に応答して、メッセージを送信して第1のトンネルを確立する工程を含む請求項7に記載の方法。
【請求項9】
メッセージを送信して第1のトンネルを確立する工程は、逆方向および順方向のうちの一方または両方のデータ転送をサポートするために第1のトンネルが現在用いられ始めるか否かを示す工程を含む請求項7に記載の方法。
【請求項10】
逆方向および順方向のうちの一方または両方のデータ転送をサポートするために第1のトンネルが用いられることを示す第1のネットワークノードによるメッセージを第2のネットワークノードへ送信する工程を含む請求項7に記載の方法。
【図1】
【図15】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【公開番号】特開2009−5342(P2009−5342A)
【公開日】平成21年1月8日(2009.1.8)
【国際特許分類】
【外国語出願】
【出願番号】特願2008−122811(P2008−122811)
【出願日】平成20年5月9日(2008.5.9)
【出願人】(390009597)モトローラ・インコーポレイテッド (649)
【氏名又は名称原語表記】MOTOROLA INCORPORATED
【Fターム(参考)】
【公開日】平成21年1月8日(2009.1.8)
【国際特許分類】
【出願番号】特願2008−122811(P2008−122811)
【出願日】平成20年5月9日(2008.5.9)
【出願人】(390009597)モトローラ・インコーポレイテッド (649)
【氏名又は名称原語表記】MOTOROLA INCORPORATED
【Fターム(参考)】
[ Back to top ]