第3世代パートナーシッププロジェクト(3GPP)コアネットワークのリリース8において採用された多数の種々の移動プロトコルが存在する。そのような通信ネットワークにおける移動管理は、一般に2つのカテゴリに分類される。一方のカテゴリはホストベースの移動管理であり、他方のカテゴリはネットワークベースの移動管理である。
ホストベースの移動管理の一例は、モバイルインターネットプロトコル(MIP、又はモバイルIPv6)である。モバイルIPにより、インターネット等のデータネットワーク上でIPパケットの位置に依存しないルーティングが可能になる。各移動デバイス(すなわち、移動ノード)は、インターネットにおける現在位置に関連のないホームアドレスにより識別される。ホームネットワークから離れている間、移動ノードは、現在位置を識別する気付アドレスと関連付けられ、ホームアドレスは、ホームエージェントへのトンネルを介してローカルエンドポイントと関連付けられる(以下の定義を参照)。モバイルIPは、移動ノードがホームエージェントに登録する方法及びホームエージェントがトンネルを介して移動ノードにパケットをルーティングする方法を指定する。
図1は、ホームネットワーク1及びフォーリンネットワーク3を有するモバイルIPネットワークを示す基本概略図である。移動ノード5のホームネットワーク1は、移動ノード5が識別するIPアドレス(ホームアドレスとして既知である)を受信するネットワークである。移動ノード5のホームアドレスは、ホームネットワーク1内で移動ノード5に割り当てられたIPアドレスである。フォーリンネットワーク3は、移動ノード5がホームネットワーク1から離れている場合に動作しているネットワークである(図1に示す)。
移動ノード5の気付アドレスは、フォーリンネットワーク3において動作する場合のノードの物理IPアドレスである。ホームエージェント(HA)7は、移動ノード5のホームネットワーク1におけるルータであり、移動ノード5がホームネットワーク1から離れている場合に移動ノード5に配信するためのパケットをトンネリングする。HA7は、移動ノード5に対する現在位置情報(IPアドレス情報)を保持し、1つ以上のアクセスルータ(AR)9と共に使用される。AR9は、関連付けられたフォーリンネットワーク3を訪問する移動ノード5に関する情報を格納するルータである。AR9はまた、モバイルIPにより使用される気付アドレスを広告する。ホームアドレスを気付アドレスと関連付けることを「バインディング」と呼ぶ。HA7は、トンネル11を介してAR9にパケットをルーティングし、次にAR9は、パケットを移動ノード5に転送する。
ホームベースの移動管理と異なり、ネットワークベースの移動管理の一例は、GPRSトンネリングプロトコル(GTP)である。ネットワークベースの移動管理の別の例は、インターネット技術タスクフォース(IETF)により開発されている新しい規格であるプロキシモバイルIP(PMIP又はプロキシモバイルIPv6)である。
次に、これらのネットワークベースの移動管理プロトコルを更に簡単に説明するために、LTE(Long Term Evolution)規格を使用するE−UTRAN(発展型UMTS地上無線アクセスネットワーク)として既知である例示的な通信ネットワークを示す更に詳細な概略図である図2を参照する。ネットワークは、各々が1つ以上のセル(不図示)を保持する複数の無線基地局(eNodeB、Node B等としても既知である)21a、21b、21cを含む。各セル内のユーザ機器(「UE」、すなわちモバイル機器又は移動ノード)23a、23b、23c、23dは、そのセルの対応するeNodeB21と通信する。
E−UTRANにおいて、eNodeB21は、X2インタフェース(図2において破線として示される)として既知であるインタフェースを介して互いに通信できる。各eNodeB21は、コアネットワークとの1つ以上のインタフェースを更に有する。これらはS1インタフェースとして既知である。特にeNodeB21は、以下において更に詳細に説明する1つ以上の移動管理エンティティ(MME)25a、25bに対する1つ以上のS1インタフェースを有する。
通信ネットワークは、在圏ゲートウェイ(SGW)29を更に備える。在圏ゲートウェイ29は、S1uインタフェースを介してeNodeB21aに接続され、S11インタフェースを介してMME25aに接続される。在圏ゲートウェイ29は、前記デバイスの各々のうちの1つ以上及び在圏GPRSサポートノード(SGSN、不図示)等の他のノードに接続されることが理解されるだろう。在圏ゲートウェイ29は、特に、ユーザデータパケットをルーティング及び転送し、eNodeB間ハンドオーバ中に(例えば、UE23aがeNodeB21aからeNodeB21cにハンドオーバされる時)ユーザプレーンに対する移動アンカとして更に動作するように構成される。在圏ゲートウェイ29は、LTE技術と他の3GPP技術との間の移動に対するアンカとして更に動作する。更に在圏ゲートウェイ29は、IPベアラサービスのパラメータ等のUEコンテキスト及びネットワーク内部ルーティング情報を管理し、格納する。
在圏ゲートウェイ29は、S5インタフェースを介してパケットデータネットワークゲートウェイ(PDN GW)31に接続される。PDN GW31は、UEに対してトラフィックの出入口のポイントになることにより、インターネット33等の外部パケットネットワークへの接続性をUEに提供する。
MME25aは、特に、アイドルモードのUE追跡処理及びUE呼び出し処理を担う。更にMME25aは、ベアラ起動/停止処理に関与し、UEに対して初期の在圏ゲートウェイ(SGW)を選択することを担う。
上述したように、PDN GW31は、UE23に対してトラフィックの出入口のポイントになることにより、UE23から外部パケットデータネットワーク33(例えば、インターネット)への接続性を提供する(SGiインタフェースを介して)。UE23は、多数のPDN33にアクセスする2つ以上のPDN GW31との同時接続性を有する。PDN GW31は、特に、ポリシー強制、ユーザ毎のパケットフィルタリング、課金サポート、合法的傍受及びパケットスクリーニングを実行する。PDN GW31の別の重要な役割は、S2インタフェース(不図示)を介して3GPP技術と非3GPP技術との間の移動に対するアンカとして動作することである。
プロキシモバイルIPシステムにおける移動管理は、プロキシモバイルIPプロトコルRFC5213により規定されるように、処理に関与する2つのネットワークエンティティ、すなわちローカル移動アンカ(LMA)及びモバイルアクセスゲートウェイ(MAG)を規定する。図2の3GPPアーキテクチャのS5インタフェースに適用される場合、SGW29はMAGとして動作し、PDN GW31はLMAとして動作する。MAGは、アクセスリンクに接続されるモバイルホストに対する移動に関連した信号伝送を管理するアクセスルータ上の機能である。LMAは、プロキシモバイルIPドメインにおいてモバイルホストに対するホームエージェントである。プロトコルは以下のように動作する。
・モバイルホストはPMIPドメインに入る。
・そのリンク上のモバイルアクセスゲートウェイは、ホスト認証を確認する。
・モバイルホストはIPアドレスを取得する。
・モバイルアクセスゲートウェイは、ホストの現在位置に関してローカル移動アンカを更新する。
・MAG及びLMAの双方は双方向トンネルを作成する。
GTP及びPMIPにより提供されたネットワークベースの移動管理は、モバイルIPの機能性に類似した機能性を提供する。しかし、ネットワークベースの移動管理は、モバイルホストのネットワークスタックに対する変更を全く必要としない。換言すると、移動は、その名前が示唆するようにネットワークにより処理される。
しかし、GTPとPMIPとの重要な機能差は、GTPが「ベアラ」(又は3GPP規格の他のバージョンでは「PDPコンテキスト」)として既知である移動セッション内のサブセッションの確立を更にサポートすることである。ベアラは、集中型トラフィック分類を使用することで提供されるサービス品質(QoS)の区別を有効にする。その結果、ダウンリンクパケットは、アンカポイントにおいてのみ(例えば、図2に示されたようにPDN ゲートウェイ31において)特定のQoSクラスに分類され且つ割り当てられる必要がある(3GPP規格において「ベアラにマッピングすること」として既知である)。ベアラは、種々のQoS特性を含む最初のホップルータ(すなわち、PDN GW31)とUE23との間のL2チャネルとして考えられる。新しいベアラが設定される場合、PDN GW31及びUEは、5タプルにより識別されたどのIPマイクロフロー(すなわち、以下において更に説明されるようなサービスデータフロー(SDF))が新しいベアラに配置されるかについて同意する。従って、PDN GW31によりUEに送出された(あるいはUEによりPDN GW31に送出された)全てのパケットは、どのベアラにそのパケットが配置されるべきか分かるように分類される。このような分類は、これらの5タプル値を調べ、パケットのヘッダフィールドと比較することで実行される。パケットの経路上の後続の要素(例えば、SGW29、eNodeB21)は、パケットがどのベアラ上にあるか、及びその結果適用するQoSはどれかを既に認識しているため、再度分類する必要はない。
図3は、LTE通信ネットワークにおけるサービスデータフロー(SDF)とベアラとの関係を示す。サービスデータフローは、ある特定の5タプルのフィルタセットにマッチするIPパケットの集合である。換言すると、SDFはトラフィックの一部であり、ベアラは伝送設備である。SDFはベアラ上に配置される(あるいは、ベアラを通して又は介して伝送される)。ベアラは、それ自体が固有のサービス品質(QoS)クラスを有する仮想接続である。
図3において、第1のQoSクラス(QoS1)を有する第1のベアラ301は、複数のサービスデータフローSDF11〜SDF1Nを伝送するものとして示され、第2のQoSクラス(QoS2)を有する第2のベアラ303は、複数のサービスデータフローSDF21〜SDF2Nを伝送するものとして示される。図2のネットワークにおいて、UE23とPDNゲートウェイ31との間のデータ経路上のベアラは、3つのセグメントを有する。
−UE23aとeNodeB21aとの間の無線ベアラ
−eNodeB21aとSGW29との間のデータベアラ(S1uベアラ)
−SWG29とPDN GW31との間のデータベアラ(S5ベアラ)。
パケットは、特定のQoSクラスに分類されて割り当てられるため、それに応じてマーク付けされる。特にベアラは、(上述したように)ネットワークにおいて全ての後続のノードに分類の結果を伝えるトンネルエンドポイント識別子(TEID)により識別される。TEIDは、S1uインタフェース及びS5インタフェース上でのみ、パケットがどのベアラ上で移動するかを識別するために使用され、この場合GTPプロトコルは、パケットを搬送するために使用される。種々のフィールド/機構(すなわち、無線関連識別子)は、エアインタフェースを介して使用され、この場合、GTPはパケットを搬送するために使用されない。
アップリンクパケットの場合、ネットワーク制御のために、移動ノードは分類及びベアラマッピングを実行し、全ての後続ノードはこの分類に依存することができる(1つのノードは実際にそれを検証する)。
しかし、PMIPベースの解決方法は、ベアラ機能を含まず(すなわち、ベアラを確立できず)、PDN GW31及び在圏ゲートウェイ29の双方においてパケット分類を実行する必要がある。パケット分類を実現するために、ポリシー及び課金ルール機能(PCRF)は、分類ルールを在圏ゲートウェイ29(すなわち、図2に示されたPDN GW31に加えて)にダウンロードする必要がある。また、ポリシールールは、ハンドオーバ等により在圏ゲートウェイが変った後に新しい在圏ゲートウェイにもまたダウンロードされなければならない。このことは、結果としてポリシーに関連した信号伝送が過剰になるという欠点を有し、ポリシーシステムを、移動を意識したものにする。
現在、クライアントモバイルインターネットプロトコル(CMIP)としても既知であるモバイルインターネットプロトコル(MIP)は、非3GPPアクセスに対して一般に使用されることを考慮した唯一のホストベースの移動プロトコルである。PMIPと同様に、MIPはベアラ機能がなく、そのため、非3GPPアクセスのゲートウェイにおいてフロー分類が必要であるという欠点を有する。換言すると、制御ノードは、フロー分類のためにCMIPトンネル内を調査しなければならない。しかし、CMIPトンネルが暗号化されている場合、これは不可能である。
本発明の目的は、上述の欠点のうちの1つ以上の影響を受けない通信ネットワークのための方法及びモバイルインターネットプロトコル(又はクライアントモバイルインターネットプロトコル)、並びにそのような通信プロトコル及び方法を実行するように構成された装置を提供することである。
特に、本発明の目的は、ホストベースの移動管理がベアラサポートを含むモバイルインターネットプロトコル(又はクライアントモバイルインターネットプロトコル)を提供することである。
本発明の第1の態様によれば、モバイルインターネットプロトコル(MIP)を使用してトラフィックを処理するように構成された、ホストベースで移動が管理された通信ネットワークにおける方法が提供される。方法は、移動セッション内でサブセッションが作成されるのを可能にし、且つ移動セッション内でデータパケットを転送する1つ以上のベアラを提供するステップを備える。
方法は、キー値を各ベアラと関連付けるステップを備える。
キー値は、関連付けられたベアラにより転送されているデータパケットのサービス品質(QoS)を表す。
この方法は、ユーザプレーン上でデータパケットをルーティングするために使用される外側ヘッダを各ベアラと関連付けるステップを更に備える。これは、基礎となるデータパケットが暗号化される場合でもパケットを操作できるという利点を有する。
ベアラは、モバイルインターネットプロトコルのバインディングアップデート又はバインディング確認応答メッセージまたはその両方を使用して実行される。ベアラは、通信ネットワークにおいて移動ノード又はホームエージェントにより設定されてもよい。
複数のベアラの第1のベアラ及び第2のベアラにより、所定の移動ノードのトラフィックの第1の部分をその所定の移動ノードのトラフィックの第2の部分から区別できる。
この方法は、IPフローフィルタの集合を提供するステップを更に有し、IPフローフィルタの集合におけるひとつのIPフローフィルタが、データパケットを、対応するベアラとマッチさせるように構成される。
いずれのIPフローフィルタによってもマッチしなかったパケットを搬送するように構成されたデフォルトベアラが提供されてもよい。
この方法はまた、ベアラ中のパケットがネットワーク内の他のノードで処理されるべき方法を記述する記述子フィールドを各ベアラと関連付けるステップを有する。
キー値は、汎用ルーティングカプセル化(GRE)を使用して各パケットに属される。
本発明の別の態様によれば、モバイルインターネットプロトコルを実行するように構成された、ホストベースで移動が管理された通信ネットワークの移動ノードにおける方法が提供される。この方法は、移動ノードにより要求される1つ以上のベアラと関連付けられた1つ以上のダウンリンクキー値を含むバインディング要求メッセージを第2のノードに送出するステップと、それぞれ1つ以上のベアラと関連付けられた1つ以上のアップリンクキー値を含むバインディング確認応答メッセージを第2のノードから受信するステップとを有する。
本発明の別の態様によれば、上述の方法を実行するように構成された移動ノードが提供される。
本発明の別の態様によれば、モバイルインターネットプロトコルをサポートするように構成された、ホストベースで移動が管理された通信ネットワークのホームエージェントノードにおける方法が提供される。この方法は、ホームエージェントノードにより要求される1つ以上のベアラと関連付けられた1つ以上のアップリンクキー値を含むベアラ設定メッセージを第2のノードに送出するステップと、1つ以上のベアラと関連付けられた1つ以上のダウンリンクキー値を含むベアラ設定確認応答メッセージを第2のノードから受信するステップとを有する。
本発明の別の態様によれば、モバイルインターネットプロトコルを実行するように構成された。ホストベースで移動が管理された通信ネットワークのホームエージェントノードにおける方法であって、第2のノードにより要求される1つ以上のベアラと関連付けられた1つ以上のダウンリンクキー値を含むバインディング要求メッセージを第2のノードから受信するステップと、それぞれ1つ以上のベアラと関連付けられた1つ以上のアップリンクキー値を含むバインディング確認応答メッセージを第2のノードに送出するステップとを有することを特徴とする方法が提供される。
本発明の別の態様によれば、上述の2つの段落の方法を実行するように構成されたホームエージェントノードが提供される。
本発明の別の態様によれば、モバイルインターネットプロトコルを実行するように構成された、ホストベースで移動が管理された通信ネットワークのアクセスルータノードにおける方法であって、1つ以上のベアラに対してサービス品質機能を構成するステップと、アクセスルータを通過するパケットにサービス品質機能を適用するステップとを有することを特徴とする方法が提供される。
本発明の別の態様によれば、上述の方法を実行するように構成されたアクセスルータが提供される。
クライアントモバイルインターネットプロトコル(CMIP)としても既知であるモバイルインターネットプロトコル(MIP)ドメインに関連して、実施形態を以下において説明する。
本発明によれば、CMIPシステム等のホストベースの移動管理システムは、ベアラのサポートを提供するように拡張される。ベアラにより、所与の移動セッション内にサブセッションを提供できる。各ベアラは、転送されているデータパケットと関連付けられたサービス品質(QoS)等を示すキー値を割り当てられる。ベアラは、MIPv6規格への拡張等の既存のモバイルIP規格の拡張を使用する移動ノードとホームエージェントとの間でエンドツーエンドに設定される。
従って、本発明のベアラにより、単一の移動ノードのトラフィックの部分を同一の移動ノードのトラフィックの他の部分から分離できる。換言すると、例えばサービス品質(QoS)に基づいて、移動ノードのトラフィック内でベアラによる区別が可能になる。
図4は、本発明を更に簡単に例示するために、種々の段階及びステップを示すメッセージフローを示す。401〜409に示された段階及びステップは、移動ノード(MN)がバインディングを確立し、ホームエージェント(HA)とのトンネルを設定する方法を示す。尚、種々の段階及びステップ401〜409は、既存のCMIP手順に従う標準的な段階及びステップである。
410〜423に示された段階及びステップは、本発明に従ってベアラが設定される方法を示し、424〜433に示された段階及びステップは、ハンドオーバが実行される方法を示す。
段階410でのベアラの設定中、キー値は取り決められ、IPフローフィルタは、所与のベアラ上に転送されるパケットを示す。要するに、各エンドポイントは他のエンドポイントに、このベアラについて受信したいキー値を通知する。例えばステップ411において、MNは、ダウンリンクパケットにおいてHAにより使用されるはずのダウンリンクキーを(特に)HAに通知するバインディングアップデートメッセージをHAに送出する。同様に、ステップ413において、HAは、特にアップリンクパケットにおいてMNにより使用されるアップリンクキーをMNに通知するバインディング確認応答メッセージをMNに送出する。各キー値は、QoS記述子等に対応する。QoS記述子は、信号伝送において使用されるだけである(メッセージ411〜413及び426〜428において「QoS」として示される)。尚、キー値は任意のQoS記述子である。例えば3GPPコンテキストにおいて、キー値は、クラス識別子(QCI)、割り当て及び保持ポリシー(ARP)、最大ビットレート(MBR)又は保証ビットレート(GBR)の値である。
ハンドオーバ段階424の間、ステップ426において、MNは、ベアラの完全なリストを含むバインディングアップデートメッセージをHAに送出する。尚、図4の例において、参照しやすくするために、1つのベアラのみが設定されているものとして示されるため、「完全なリスト」は1つの項目のみに対するものであり、メッセージ426において繰り返される。しかし、複数のベアラがあった場合、複数の(5タプル、ダウンリンクキー、QoS)値がリストされることが理解されるだろう。尚、実際には、あるベアラ(すなわち、サブセッション)内に多数のマイクロフロー(すなわち、SDF)がある場合、5タプルは5タプルのリストを意味する。また、5タプル以外の機構が本発明の範囲から逸脱せずに使用されてもよいことが理解されるだろう。
バインディングアップデートメッセージ内にベアラの完全なリストを含むことにより、移動ノードが到着してそこでバインディングを設定する場合に、新しいアクセスはQoSを設定できる。
第1の構成によれば、アクセスルータ(AR1)は、バインディングアップデートメッセージ及びバインディング確認応答メッセージ(BU/BA)を傍受又は監視し、どのベアラが確立されるかを学習し、QoS及び関連付けられたキーを判定する。次にAR1は、これらの(アップリンク又はダウンリンク)キーでマーク付けされたトンネル内を移動する全てのパケットにQoSを提供する。
第2の構成によれば、プロキシがMIP信号伝送の経路に提供されることにより(すなわち、MNが、HAではなくAR1等のプロキシにバインディングアップデートメッセージを送出する場合)、そのような構成においてAR1は、代理するメッセージを検査することでベアラを学習するように構成される。
第3の構成によれば、ポリシー及び課金サーバ(例えば、ポリシー及び課金ルール機能PCRF)は、本明細書において後で説明されるように、QoSでAR1を明示的に設定するように構成される。これは、AR1とPCRFとの間でQoS提供をネゴシエートすることを含む。
汎用ルーティングカプセル化(GRE)トンネリング等のトンネリングは、パケット毎にキー値を伝送するパケットをトンネリングするためにユーザプレーンにおいて使用される。そのキー値は、パケットが属するベアラを識別する。パケットのペイロードが暗号化される場合、GREトンネルは暗号化されないため、ベアラは、実際には中間ノード(図4のAR1、すなわち「ミドルボックス」)により推定できる。
上述したように、中間ノードは、通過するMIP信号伝送を傍受し、ベアラについて学習する。従って、「プロキシ」(すなわち、AR1)が信号伝送の経路に挿入される(CMIPの拡張として)場合、中間ノードはさらに、ベアラ要求を規制し、また変更する。ベアラを設定する場合、MNは、ネットワークにリソースを効率的に要求する。MNは、「これらのマイクロフローに、この帯域幅までこれらの(適切な)QoS特性を持たせて欲しい」と効率的に要求する。この結果、効果的に、帯域幅が予約され、これらのパケットに低遅延が提供される。これらの要求の規制、すなわちこのユーザがそのような要求及びリソースを受ける資格があるかをチェックすることはネットワークの動作である。課金は、ユーザがリソースを有する長さ又はユーザがこのベアラにおいて送出したトラフィックの量をカウントするカウンタの設定を含むため、課金システムは、後でこれらのカウンタを金銭的価値に変更できる。
図5は、本発明に従ってベアラ上を伝送するようにフォーマットされたパケットの構成を示す。
ベアラ上を伝送するためにフォーマットされたパケットは、以下の特徴により規定される。
・外側IPヘッダ42、
・キー値を含むGREヘッダ44、
・組み合わされたヘッダ46及びペイロード48を含む内側IPパケット。
上述したように、GREヘッダ44に含まれたキー値は、その特定のベアラ上でその特定のパケットのペイロードに割り当てられたサービス品質クラスを示す。外側IPヘッダ42は、パケットをルーティングするためにユーザプレーンにおいて使用される。上記から、内側IPパケット(すなわち、ヘッダ46及びペイロード48を含む)が暗号化されている場合でも、ノードは、依然として外側IPヘッダ42及びキー値を含むGREヘッダ44を傍受又は監視できることが理解されるだろう。従って、ノードは、パケットを復号化する必要なくQoSをパケットに適用できる。
QoS記述子は、ベアラ設定中にMNとHAとの間でやり取りされる。この処理の一部として、アクセスルータはまたそれらを学習する(例えば、上述した3つの異なる構成のうちの1つに従って)。その後、記述子は、それ以上通信されるのではなく、これらの3つのノードに格納される。しかし、ハンドオーバ中に全てのQoS記述子が再送される場合、例外が発生する。
個々のパケットは記述子を搬送しないことが理解されるだろう。そうではなく、キー値はパケットと関連付けられ、前にやり取りされたQoS記述子に対する参照として使用される。
IPフローフィルタの集合は、特定のベアラに割り当てられるパケットにマッチする。フローフィルタは、各々がIP送信元アドレス、IP宛先アドレス、送信元ポート、宛先ポート、プロトコル(例えば、TCP又はUDP)から構成される5タプル値のリストである。これらは、ベアラ設定中にバインディングアップデート信号伝送を使用してMN及びHAにインストールされる。中間ノードは、IPフローフィルタを必ずしも必要としない。また、ユーザプレーンパケットはIPフローフィルタも含まない。パケットは、HA又はMNにより他に送出される場合、フローフィルタに対してチェックされ、パケットが配置されるべきベアラを見つける。その後、そのベアラのキーは、GREヘッダ(MNにより送出される場合はアップリンク、HAにより送出される場合はダウンリンク)に配置される。
記述子フィールドは、特定のベアラのパケットがネットワークにおいて他のノードで処理されるべき方法を記述する。例えば、3GPPシステムの場合、これは、QoSクラス識別子(QCI)、割り当て及び保持ポリシー(ARP)、最大ビットレート(MBR)又は保証ビットレート(GBR)に関連する1つ以上の値を含む。
QCIは、ベアラレベルパケット転送処理(例えば、スケジューリング重み、承認閾値、待ち行列管理閾値、リンクレイヤプロトコル構成等)を制御し、かつアクセスノード(例えば、eNodeB21)を有する事業者により事前設定されているアクセスノード固有のパラメータにアクセスするための参照として使用されるスカラである。
GBRは、GBRベアラにより提供されることが予想されるビットレートを示す。MBRは、GBRベアラにより提供されることが予想されるビットレートを制限する(例えば、過剰なトラフィックはレートシェーピング機能により無視される)。
ARPは、優先レベル(スカラ)に関する情報、並びに横取り(pre-emption)機能及び脆弱性フラグを含む。ARPの主な目的は、ベアラ確立/変更要求が受け入れられるか、あるいはリソース制限の場合に拒否されるべき要求があるかを判断することである。ARPの優先レベル情報はこの判断のために使用され、より高い優先レベルを有するベアラの要求が選択されることを保証する。更にARPは、ハンドオーバ等の例外的なリソース制限中にドロップするベアラを判断するために使用される(例えば、eNodeBにより)。ARPの横取り機能情報は、より低いARP優先レベルを含むベアラが、要求されたリソースを解放するためにドロップされるべきであるかを規定する。ARPの横取り脆弱性情報は、ベアラが、より高いARP優先値を有する横取り対応のベアラによるそのようなドロップに適用可能であるかを規定する。いったん成功裡に確立されると、ベアラのARPは、ベアラレベルパケット転送処理(スケジューリング及びレート制御等)に全く影響を及ぼさない。換言すると、好ましくは、パケット転送処理は、記述子フィールドの他の値、すなわちQCI、GBR及びMBRを使用して判定されるべきである。
ベアラは、CMIPバインディング、すなわち1つのホームアドレス(HoA)と1つの気付アドレス(CoA)とのバインディング内に存在する。HAにおいて、各HoAは登録済みCoAを有しており、これがバインディングである。各バインディングは1つのMNに対応する。各MNは、ゼロ又は1つ以上のベアラを有する。
一実施形態によれば、ベアラのうちの1つはデフォルトベアラとして示される。デフォルトベアラを提供することにより、IPフローフィルタのうちのいずれにもマッチしていない全てのパケットを転送できる。移動ノード又はホームアドレスは、そのようなパケットに対してもパケット処理を指定し、その場合MNは、アドレスに対してプレフィックス長がゼロのIPフローフィルタ及び他の全てのフィールドに対するワイルドカードを指定する。
図6は、移動ノードMNによりベアラの確立中に実行されたステップを開示する簡略化されたフローチャートである。これらは、図4のステップ411〜413に対応し、以下において更に詳細に説明される。尚、同様のメッセージフローがベアラの変更又は削除のために更に使用されてよい。
MNは、新しいベアラを確立するか、既存のベアラを変更するか、あるいはベアラを削除したい場合、ステップ501の新しいバインディングアップデートをHAに送出する。一実施形態において、MNは、バインディングアップデートメッセージ501のパラメータで要求されたベアラを一覧表示する。バインディングアップデートメッセージのパラメータは、フローフィルタ(5タプル)、所望するダウンリンクキー及びフローのQoSを指定する。バインディングアップデートメッセージは、ホームアドレス又は気付アドレス等の他の情報を更に含む。HAがステップ503でバインディング確認応答メッセージを送出することにより要求されたアップリンクキーで応答し、5タプルを繰り返すため、MNは応答が対応するベアラを認識する。
HAは、ベアラパラメータを監視し、バインディング確認応答メッセージ503において受け入れられたベアラのリストを返送する。HAは、要求されたQoSのレベルが高すぎること(例えば、低品質サブスクリプション)を判断し、QoSを格下げする。これは、ステップ503のバインディング確認応答において「受け入れられたQoS」メッセージとして示される。拒否又は変更されたベアラに対して、バインディング確認応答メッセージは、変更又は省略に対する説明として誤りコードを更に含む。
上述したように、MNによるベアラの確立はHAによるベアラの確立に更に適用されることが理解されるだろう。
従って、HAは、ベアラを確立したい場合、更新されたベアラのリストを含む適切に規定された新しい移動メッセージをMNに送出することでベアラを確立する。
図7は、そのようなベアラを設定するHAを示すフローチャートである。MIPにおいてMNのみがメッセージングを開始できるため、これは本発明(ベアラ設定)により採用された新しい種類のメッセージである。しかし、これはベアラの設定方法の一例にすぎないことが理解されるだろう。あるいは、他の何らかの種類のメッセージが再利用される。ステップ435において、HAは、フローフィルタ(5タプル)、所望するアップリンクキー及びフローのQoSを指定するMNに、この「ベアラ設定メッセージ」を送出する。ステップ437でMNが、要求されたダウンリンクキーを応答し、5タプルを反復するため、HAはどのベアラにその応答が対応しているかを認識する。
従って、MN及びHAの双方はベアラの確立を開始できる。特定のネットワークノードがMNに気付かれずにトラフィックの特定の部分にQoSを提供したい場合、HAは有用である。例えば、ユーザがオンラインビデオを見ているとすると、ユーザにデータを送出するウェブサーバは、ユーザに帯域予約を提供するようにHAに要求するため、ビデオは決して再バッファリングしない。これは、ウェブサーバが、要求されたQoS及びビデオを搬送するフローの5タプルを有するメッセージをHAに送出することにより実行される。HAがQoSを設定するため、ユーザのユーザ端末は、実際には何もする必要がない(アプリケーション開発者が気付かないように、通常、ブラウザではなくカーネルにより実行されるメッセージの確認応答以外)。HAにより確立されたベアラは、MNにより確立されたベアラと共存できる。
図4に関連して上述したように、MNがある基地局から別の基地局に移動する場合のハンドオーバ手順中、MNからHAに送出されたバインディングアップデートメッセージは全てのベアラを含む。
新たに規定された拡張、すなわちベアラパラメータの記述(例えば、アップリンク/ダウンリンクパケットで使用されるキー値、ベアラのQoS記述子及びベアラ上に伝送されるSDFのIPフィルタ)を搬送するMIPメッセージ中の情報要素を有さないバインディングアップデートメッセージは、デフォルトベアラを除く全てのベアラを除去する。これは、CMIPにおける従来のバインディングアップデートメッセージ(すなわち、本発明により提供されるようなベアラを全く含まない)の意味により、ベストエフォート型のトンネルを設定できるためである。従って、これらの拡張を含む場合でも、本発明はこれらの意味を維持する。これにより、既存のシステムとの適切な後方互換性が可能になる。
図8は、ユーザプレーン上の挙動を説明する。ベアラ設定中、キー値は、ステップ801でベアラ毎に特定される。その後、パケット伝送中、特定されたキー値は、ステップ803、でその特定のベアラにおいて転送される各データパケットに添付される。上述したように、キー値を各データパケットに添付する1つの技術は、ステップ805で汎用ルーティングカプセル化(GRE)を使用する技術である。キー値を持たないカプセル化を使用してノードに到達するパケットは、デフォルトベアラ上に到達したかのように処理される。IP−in−IPカプセル化を用いて送出されたパケットはデフォルトベアラ上を移動するので、これにより適切な後方互換性が可能になる。またこれにより、デフォルトパケットに対するオーバヘッドの低減が可能になる。
図9は、ミドルボックス(すなわち、中間ノード又は透過性ノードAR)において実行された基本ステップを説明する。非3GPPアクセスネットワークのゲートウェイ(GW)等のミドルボックスは、ステップ901でバインディングアップデートメッセージ/バインディング受け入れメッセージを傍受又は監視する。その傍受に基づいて、ゲートウェイは、ステップ903で、確立されるベアラの種類を推定する。複数の種類のQoSを有する必要があるならば、複数のベアラを確立できる。例えばビデオ/電話の場合、ひとつのベアラは音声に対して開き、別のベアラはビデオに対して開くことができる。双方は、同一ではないが特別なQoSを必要とする(例えば、音声はパケットの損失を許すが、それに対してビデオは許さない)。
次に、ステップ905において、ベアラ上で受信した情報により、アクセスネットワークにおいてサービス品質を設定できる。これは、ミドルボックス又は特定のアプリケーションに依存する他のノードにおいて実行される。例えば、MIPプロキシ(例えば、図4に示されたAR1)上で監視する場合、ミドルボックスはそれ自身でQoSを設定する。ポリシー及び課金サーバ(PCRF)がQoSでARを明示的に設定する場合、これはPCRFにより実行される。そのようなQoS設定が失敗したかをステップ907で判定する場合、ミドルボックスは、ステップ909で、ICMPメッセージ又は移動メッセージをベアラ設定のイニシエータに応答し、QoS失敗をそれに通知する。そのようなQoS設定が可能であることをステップ907で判定する場合、ミドルボックスは、ステップ911で受け入れられたものとしてQoSを処理し、次にこれらの(アップリンク又はダウンリンク)キーでマーク付けされたトンネルにおいて移動する全てのパケットにそのQoSを適用する。
上述において、ミドルボックスは安全なチャネルを使用して移動ノードと通信し、バインディングアップデートメッセージは暗号化されないものとする。本明細書において上述した第1の構成及び第2の構成の例において、バインディングアップデートが暗号化される場合、ミドルボックス(すなわち、図4のAR1)は、ベアラのパラメータを学習しない(ミドルボックスがバインディングアップリンクを解読しないため)。従って、ミドルボックスがQoSを設定できないため、ベアラを有するという概念は機能しない。
尚、上述の実施形態において、アクセスルータ(AR)は、使用される場合にMIPv6にプロキシ機構を提供する。ARは、MIPv4フォーリンエージェントが動作する方法と同様の方法でそのようなプロキシ機能をホストに広告する。次に移動ノードは、バインディングアップデートメッセージをアクセスルータに配置されたこれらのMIPプロキシに送出する結果、バインディングアップデートメッセージをホームエージェントに送出する。
そのようなプロキシ機構がある状態で、プロキシは、確実にベアラ変更要求を読み出し、変更し、それに応答する。CMIP++モバイルノードプロキシ機構は、そのような機構の1つである。
図10及び図11は、本明細書において上述した第3の機構の場合の信号伝送フローを説明する。この場合、(例えば)ポリシー及び課金制御インフラストラクチャは3GPPにより規定されているとする。次に、これを単一のノード、すなわちPCRFにより示す。
MNは、段階438で新しいベアラを確立したい場合、ステップ439で、上述した実施形態と同一の方法でバインディングアップデートメッセージをHAに送出する。しかし、HAは、バインディングアップデートメッセージを受信すると、ステップ440でポリシー要求を送出することでPCRFに通知する。次にPCRFは、ステップ441でポリシー判断を行う。PCRFは、ポリシー要求が受け入れ可能であるか否かを判定し、必要に応じてQoS記述子を変更する。その後、ステップ442〜444において、PCRFは、明示的にミドルボックス(AR2)においてQoSを設定する。次にミドルボックス(AR2)は、容易にステップ452でQoSを適用する。この構成において、第1の構成及び第2の構成と同様に、ミドルボックスはバインディングアップリンクメッセージをスヌープする必要はなく、MIPプロキシもその必要はない。
図11は、3GPP PCCアーキテクチャにおいて規定されたアプリケーション機能に従って、例えば図11のアプリケーション機能ノードAFからネットワークが段階445でベアラを設定する場合にQoS確立のために実行されるステップを示すフローチャートである。ステップ456において、設定QoSメッセージは、AFからPCRFに送出される。次にPCRFは、ポリシー判断を行い、QoSパラメータを導出する。次にPCRFは、QoSルールをHAに送出する。ステップ459〜461において示されるように、HAは、MNと共にベアラを設定する際にQoSルールを使用する。ステップ462でQoSルール確認応答を受信すると、次にPCRFは、ステップ463〜465でAR2のQosを設定する。その後、アクセスルータAR2は、バインディングアップデートメッセージを傍受する必要なく、容易にステップ471でQoSを適用する。
本発明により、移動信号伝送に結合されたアクセスネットワークにQoS情報を配信できる。これにより、ポリシーインフラストラクチャが移動を考慮するようになり且つアクセスネットワークに対する信号伝送を有する必要性を軽減する。本発明は、GTPの特性をクライアントMIPにより提供されたホストベースの移動管理と組み合わせるという利点を有する。
尚、移動セッションは、移動管理のためにCMIPを使用して移動ノード及びホームエージェントにおいて確立された状態を示す。移動セッションは、初期のバインディングアップデートメッセージを使用して確立され、移動ノードに対するキャッシュエントリをホームエージェントから除去するバインディングアップデートにより終了する。移動セッション中、ホームエージェントは、移動ノードの動きを追跡し(後続のバインディングアップデートメッセージを介して)、移動ノードに対してアドレス指定された全てのトラフィックを移動ノードの現在位置(気付アドレスにより識別された)に転送する。
上述の実施形態におけるサブセッションの目的は、異なるQoS処理を可能にすることであることが理解されるだろう。しかし、本発明はこの適応例に限定されず、サブセッションは、移動セッション内で異なるセキュリティ処理をサブセッションに提供する等の他の適応例に対して使用されてよい。
尚、「実行するように構成された」又は「サポートするように構成された」を参照することは、装置が必要な機能を実行するようにあるいは実行されている機能の動作をサポートするように構成された技術的手段を備えることを含むことを意図する。
尚、上述の実施形態は本発明を限定せず、当業者は、添付の請求の範囲の範囲から逸脱せずに多くの別の実施形態を設計できる。「備える」という用語は、請求の範囲において列挙された以外の要素又はステップの存在を除外せず、「単数形」は複数形を除外せず、単一のプロセッサ又は他のユニットは、請求の範囲において説明されたいくつかのユニットの機能を実現する。請求の範囲における図中符号は、いずれも請求の範囲の範囲を限定するように解釈されるべきではない。