(57)【特許請求の範囲】
【請求項１】
ホームエージェントノードと移動ノードとの間でモバイルインターネットプロトコル（ＭＩＰ）を使用してトラフィックを処理するように構成された、ホストベースで移動管理された通信ネットワークにおける方法であって、
前記ホームエージェントノードと前記移動ノードとの間で、移動セッション内でデータパケットを転送するための１つ以上のベアラを提供するステップと、
キー値を各ベアラと関連付けるステップであって、前記キー値は、前記関連付けられたベアラにより転送されているデータパケットのサービス品質（ＱｏＳ）を表すステップと、
前記１つ以上のベアラを用いて前記移動セッション内でサブセッションを作成するステップと
を有し、
前記キー値は、ダウンリンクキー値とアップリンクキー値とを含み、
前記ダウンリンクキー値は、前記移動ノードにより送信されるバインディング要求メッセージにより前記ホームエージェントノードに送出され、
前記アップリンクキー値は、前記ホームエージェントノードにより送信されるバインディング確認応答メッセージにより前記移動ノードに送出されることを特徴とする方法。
【請求項２】
ユーザプレーン上で前記データパケットをルーティングするために使用される外側ヘッダを各ベアラと関連付けるステップを有することを特徴とする請求項１記載の方法。
【請求項３】
複数のベアラのうちの第１のベアラ及び第２のベアラにより、所与の移動ノードのトラフィックの第１の部分を前記所与の移動ノードのトラフィックの第２の部分から区別できることを特徴とする請求項１または２に記載の方法。
【請求項４】
モバイルインターネットプロトコルを実行するように構成された、ホストベースで移動が管理された通信ネットワークの移動ノードにおける方法であって、
前記移動ノードにより要求されている１つ以上のベアラと関連付けられた１つ以上のダウンリンクキー値を含むバインディング要求メッセージをホームエージェントノードに送出するステップと、
前記１つ以上のベアラとそれぞれ関連付けられた１つ以上のアップリンクキー値を含むバインディング確認応答メッセージを前記ホームエージェントノードから受信するステップとを有し、
前記１つ以上のベアラは、前記移動ノードと前記ホームエージェントノードとの間の移動セッション内で、前記移動セッション内でサブセッションの作成を可能とすべく、データパケットを転送するよう構成され、前記１つ以上のアップリンクキー値及びダウンリンクキー値は、前記関連付けられたベアラにより転送されているデータパケットのサービス品質（ＱｏＳ）記述子を表すことを特徴とする方法。
【請求項５】
請求項４に記載の方法を実行するように構成されることを特徴とする移動ノード。
【請求項６】
モバイルインターネットプロトコルをサポートするように構成された、ホストベースで移動が管理された通信ネットワークのホームエージェントノードにおける方法であって、
前記ホームエージェントノードにより要求されている１つ以上のベアラと関連付けられた１つ以上のアップリンクキー値を含むベアラ設定メッセージを移動ノードに送出するステップと、
前記１つ以上のベアラと関連付けられた１つ以上のダウンリンクキー値を含むベアラ設定確認応答メッセージを前記移動ノードから受信するステップとを有し、
前記１つ以上のベアラは、前記移動ノードと前記ホームエージェントノードとの間の移動セッション内で、前記移動セッション内でサブセッションの作成を可能とすべく、データパケットを転送するよう構成され、前記１つ以上のアップリンクキー値及びダウンリンクキー値は、前記関連付けられたベアラにより転送されているデータパケットのサービス品質（ＱｏＳ）記述子を表すことを特徴とする方法。
【請求項７】
モバイルインターネットプロトコルを実行するように構成された、ホストベースで移動が管理された通信ネットワークのホームエージェントノードにおける方法であって、
移動ノードにより要求されている１つ以上のベアラと関連付けられた１つ以上のダウンリンクキー値を含むバインディング要求メッセージを前記移動ノードから受信するステップと、
前記１つ以上のベアラとそれぞれ関連付けられた１つ以上のアップリンクキー値を含むバインディング確認応答メッセージを前記移動ノードに送出するステップとを有し、
前記１つ以上のベアラは、前記移動ノードと前記ホームエージェントノードとの間の移動セッション内で、前記移動セッション内でサブセッションの作成を可能とすべく、データパケットを転送するよう構成され、前記１つ以上のアップリンクキー値及びダウンリンクキー値は、前記関連付けられたベアラにより転送されているデータパケットのサービス品質（ＱｏＳ）記述子を表すことを特徴とする方法。
【請求項８】
請求項６又は７に記載の方法を実行するように構成されることを特徴とするホームエージェントノード。
【請求項９】
モバイルインターネットプロトコルを実行するように構成された、ホストベースで移動が管理された通信ネットワークのアクセスルータノードにおける方法であって、
請求項１乃至８のいずれか１項に記載の方法を用いて確立された１つ以上のベアラに対してサービス品質機能を設定するステップと、
前記アクセスルータを通過するパケットに前記サービス品質機能を適用するステップと
を有することを特徴とする方法。
【請求項１０】
前記サービス品質機能を設定する前記ステップは、１つ以上のバインディングアップデートメッセージ又はバインディング確認応答メッセージ又はその両方を監視するステップを含むことを特徴とする請求項９記載の方法。
【請求項１１】
前記サービス品質を設定する前記ステップは、前記通信ネットワークのポリシー及び課金ルール機能とサービス品質提供をネゴシエートするステップを含むことを特徴とする請求項９記載の方法。
【請求項１２】
前記アクセスルータはプロキシアクセスルータであり、前記プロキシアクセスルータにより処理されるメッセージを検査することで１つ以上のベアラを学習するステップを更に有することを特徴とする請求項９記載の方法。
【請求項１３】
請求項９から１２のいずれか１項に記載の方法を実行するように構成されることを特徴とするアクセスルータ。
【請求項１４】
請求項１から４、請求項６又は７、あるいは請求項９から１２のいずれか１項に記載の方法を実行するように構成されることを特徴とする、移動ノード及びホームエージェントノードを含む通信ネットワーク。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信方法、通信プロトコル及び通信装置に関し、特に改善されたモバイルインターネットプロトコル（ＭＩＰ）に関連する方法、プロトコル及び装置に関する。
【背景技術】
【０００２】
第３世代パートナーシッププロジェクト（３ＧＰＰ）コアネットワークのリリース８において採用された多数の種々の移動プロトコルが存在する。そのような通信ネットワークにおける移動管理は、一般に２つのカテゴリに分類される。一方のカテゴリはホストベースの移動管理であり、他方のカテゴリはネットワークベースの移動管理である。
【０００３】
ホストベースの移動管理の一例は、モバイルインターネットプロトコル（ＭＩＰ、又はモバイルＩＰｖ６）である。モバイルＩＰにより、インターネット等のデータネットワーク上でＩＰパケットの位置に依存しないルーティングが可能になる。各移動デバイス（すなわち、移動ノード）は、インターネットにおける現在位置に関連のないホームアドレスにより識別される。ホームネットワークから離れている間、移動ノードは、現在位置を識別する気付アドレスと関連付けられ、ホームアドレスは、ホームエージェントへのトンネルを介してローカルエンドポイントと関連付けられる（以下の定義を参照）。モバイルＩＰは、移動ノードがホームエージェントに登録する方法及びホームエージェントがトンネルを介して移動ノードにパケットをルーティングする方法を指定する。
【０００４】
図１は、ホームネットワーク１及びフォーリンネットワーク３を有するモバイルＩＰネットワークを示す基本概略図である。移動ノード５のホームネットワーク１は、移動ノード５が識別するＩＰアドレス（ホームアドレスとして既知である）を受信するネットワークである。移動ノード５のホームアドレスは、ホームネットワーク１内で移動ノード５に割り当てられたＩＰアドレスである。フォーリンネットワーク３は、移動ノード５がホームネットワーク１から離れている場合に動作しているネットワークである（図１に示す）。
【０００５】
移動ノード５の気付アドレスは、フォーリンネットワーク３において動作する場合のノードの物理ＩＰアドレスである。ホームエージェント（ＨＡ）７は、移動ノード５のホームネットワーク１におけるルータであり、移動ノード５がホームネットワーク１から離れている場合に移動ノード５に配信するためのパケットをトンネリングする。ＨＡ７は、移動ノード５に対する現在位置情報（ＩＰアドレス情報）を保持し、１つ以上のアクセスルータ（ＡＲ）９と共に使用される。ＡＲ９は、関連付けられたフォーリンネットワーク３を訪問する移動ノード５に関する情報を格納するルータである。ＡＲ９はまた、モバイルＩＰにより使用される気付アドレスを広告する。ホームアドレスを気付アドレスと関連付けることを「バインディング」と呼ぶ。ＨＡ７は、トンネル１１を介してＡＲ９にパケットをルーティングし、次にＡＲ９は、パケットを移動ノード５に転送する。
【０００６】
ホームベースの移動管理と異なり、ネットワークベースの移動管理の一例は、ＧＰＲＳトンネリングプロトコル（ＧＴＰ）である。ネットワークベースの移動管理の別の例は、インターネット技術タスクフォース（ＩＥＴＦ）により開発されている新しい規格であるプロキシモバイルＩＰ（ＰＭＩＰ又はプロキシモバイルＩＰｖ６）である。
【０００７】
次に、これらのネットワークベースの移動管理プロトコルを更に簡単に説明するために、ＬＴＥ（Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ）規格を使用するＥ−ＵＴＲＡＮ（発展型ＵＭＴＳ地上無線アクセスネットワーク）として既知である例示的な通信ネットワークを示す更に詳細な概略図である図２を参照する。ネットワークは、各々が１つ以上のセル（不図示）を保持する複数の無線基地局（ｅＮｏｄｅＢ、Ｎｏｄｅ  Ｂ等としても既知である）２１ａ、２１ｂ、２１ｃを含む。各セル内のユーザ機器（「ＵＥ」、すなわちモバイル機器又は移動ノード）２３ａ、２３ｂ、２３ｃ、２３ｄは、そのセルの対応するｅＮｏｄｅＢ２１と通信する。
【０００８】
Ｅ−ＵＴＲＡＮにおいて、ｅＮｏｄｅＢ２１は、Ｘ２インタフェース（図２において破線として示される）として既知であるインタフェースを介して互いに通信できる。各ｅＮｏｄｅＢ２１は、コアネットワークとの１つ以上のインタフェースを更に有する。これらはＳ１インタフェースとして既知である。特にｅＮｏｄｅＢ２１は、以下において更に詳細に説明する１つ以上の移動管理エンティティ（ＭＭＥ）２５ａ、２５ｂに対する１つ以上のＳ１インタフェースを有する。
【０００９】
通信ネットワークは、在圏ゲートウェイ（ＳＧＷ）２９を更に備える。在圏ゲートウェイ２９は、Ｓ１ｕインタフェースを介してｅＮｏｄｅＢ２１ａに接続され、Ｓ１１インタフェースを介してＭＭＥ２５ａに接続される。在圏ゲートウェイ２９は、前記デバイスの各々のうちの１つ以上及び在圏ＧＰＲＳサポートノード（ＳＧＳＮ、不図示）等の他のノードに接続されることが理解されるだろう。在圏ゲートウェイ２９は、特に、ユーザデータパケットをルーティング及び転送し、ｅＮｏｄｅＢ間ハンドオーバ中に（例えば、ＵＥ２３ａがｅＮｏｄｅＢ２１ａからｅＮｏｄｅＢ２１ｃにハンドオーバされる時）ユーザプレーンに対する移動アンカとして更に動作するように構成される。在圏ゲートウェイ２９は、ＬＴＥ技術と他の３ＧＰＰ技術との間の移動に対するアンカとして更に動作する。更に在圏ゲートウェイ２９は、ＩＰベアラサービスのパラメータ等のＵＥコンテキスト及びネットワーク内部ルーティング情報を管理し、格納する。
【００１０】
在圏ゲートウェイ２９は、Ｓ５インタフェースを介してパケットデータネットワークゲートウェイ（ＰＤＮ  ＧＷ）３１に接続される。ＰＤＮ  ＧＷ３１は、ＵＥに対してトラフィックの出入口のポイントになることにより、インターネット３３等の外部パケットネットワークへの接続性をＵＥに提供する。
【００１１】
ＭＭＥ２５ａは、特に、アイドルモードのＵＥ追跡処理及びＵＥ呼び出し処理を担う。更にＭＭＥ２５ａは、ベアラ起動／停止処理に関与し、ＵＥに対して初期の在圏ゲートウェイ（ＳＧＷ）を選択することを担う。
【００１２】
上述したように、ＰＤＮ  ＧＷ３１は、ＵＥ２３に対してトラフィックの出入口のポイントになることにより、ＵＥ２３から外部パケットデータネットワーク３３（例えば、インターネット）への接続性を提供する（ＳＧｉインタフェースを介して）。ＵＥ２３は、多数のＰＤＮ３３にアクセスする２つ以上のＰＤＮ  ＧＷ３１との同時接続性を有する。ＰＤＮ  ＧＷ３１は、特に、ポリシー強制、ユーザ毎のパケットフィルタリング、課金サポート、合法的傍受及びパケットスクリーニングを実行する。ＰＤＮ  ＧＷ３１の別の重要な役割は、Ｓ２インタフェース（不図示）を介して３ＧＰＰ技術と非３ＧＰＰ技術との間の移動に対するアンカとして動作することである。
【００１３】
プロキシモバイルＩＰシステムにおける移動管理は、プロキシモバイルＩＰプロトコルＲＦＣ５２１３により規定されるように、処理に関与する２つのネットワークエンティティ、すなわちローカル移動アンカ（ＬＭＡ）及びモバイルアクセスゲートウェイ（ＭＡＧ）を規定する。図２の３ＧＰＰアーキテクチャのＳ５インタフェースに適用される場合、ＳＧＷ２９はＭＡＧとして動作し、ＰＤＮ  ＧＷ３１はＬＭＡとして動作する。ＭＡＧは、アクセスリンクに接続されるモバイルホストに対する移動に関連した信号伝送を管理するアクセスルータ上の機能である。ＬＭＡは、プロキシモバイルＩＰドメインにおいてモバイルホストに対するホームエージェントである。プロトコルは以下のように動作する。
・モバイルホストはＰＭＩＰドメインに入る。
・そのリンク上のモバイルアクセスゲートウェイは、ホスト認証を確認する。
・モバイルホストはＩＰアドレスを取得する。
・モバイルアクセスゲートウェイは、ホストの現在位置に関してローカル移動アンカを更新する。
・ＭＡＧ及びＬＭＡの双方は双方向トンネルを作成する。
【００１４】
ＧＴＰ及びＰＭＩＰにより提供されたネットワークベースの移動管理は、モバイルＩＰの機能性に類似した機能性を提供する。しかし、ネットワークベースの移動管理は、モバイルホストのネットワークスタックに対する変更を全く必要としない。換言すると、移動は、その名前が示唆するようにネットワークにより処理される。
【００１５】
しかし、ＧＴＰとＰＭＩＰとの重要な機能差は、ＧＴＰが「ベアラ」（又は３ＧＰＰ規格の他のバージョンでは「ＰＤＰコンテキスト」）として既知である移動セッション内のサブセッションの確立を更にサポートすることである。ベアラは、集中型トラフィック分類を使用することで提供されるサービス品質（ＱｏＳ）の区別を有効にする。その結果、ダウンリンクパケットは、アンカポイントにおいてのみ（例えば、図２に示されたようにＰＤＮ  ゲートウェイ３１において）特定のＱｏＳクラスに分類され且つ割り当てられる必要がある（３ＧＰＰ規格において「ベアラにマッピングすること」として既知である）。ベアラは、種々のＱｏＳ特性を含む最初のホップルータ（すなわち、ＰＤＮ  ＧＷ３１）とＵＥ２３との間のＬ２チャネルとして考えられる。新しいベアラが設定される場合、ＰＤＮ  ＧＷ３１及びＵＥは、５タプルにより識別されたどのＩＰマイクロフロー（すなわち、以下において更に説明されるようなサービスデータフロー（ＳＤＦ））が新しいベアラに配置されるかについて同意する。従って、ＰＤＮ  ＧＷ３１によりＵＥに送出された（あるいはＵＥによりＰＤＮ  ＧＷ３１に送出された）全てのパケットは、どのベアラにそのパケットが配置されるべきか分かるように分類される。このような分類は、これらの５タプル値を調べ、パケットのヘッダフィールドと比較することで実行される。パケットの経路上の後続の要素（例えば、ＳＧＷ２９、ｅＮｏｄｅＢ２１）は、パケットがどのベアラ上にあるか、及びその結果適用するＱｏＳはどれかを既に認識しているため、再度分類する必要はない。
【００１６】
図３は、ＬＴＥ通信ネットワークにおけるサービスデータフロー（ＳＤＦ）とベアラとの関係を示す。サービスデータフローは、ある特定の５タプルのフィルタセットにマッチするＩＰパケットの集合である。換言すると、ＳＤＦはトラフィックの一部であり、ベアラは伝送設備である。ＳＤＦはベアラ上に配置される（あるいは、ベアラを通して又は介して伝送される）。ベアラは、それ自体が固有のサービス品質（ＱｏＳ）クラスを有する仮想接続である。
【００１７】
図３において、第１のＱｏＳクラス（ＱｏＳ１）を有する第１のベアラ３０１は、複数のサービスデータフローＳＤＦ１１〜ＳＤＦ１Ｎを伝送するものとして示され、第２のＱｏＳクラス（ＱｏＳ２）を有する第２のベアラ３０３は、複数のサービスデータフローＳＤＦ２１〜ＳＤＦ２Ｎを伝送するものとして示される。図２のネットワークにおいて、ＵＥ２３とＰＤＮゲートウェイ３１との間のデータ経路上のベアラは、３つのセグメントを有する。
−ＵＥ２３ａとｅＮｏｄｅＢ２１ａとの間の無線ベアラ
−ｅＮｏｄｅＢ２１ａとＳＧＷ２９との間のデータベアラ（Ｓ１ｕベアラ）
−ＳＷＧ２９とＰＤＮ  ＧＷ３１との間のデータベアラ（Ｓ５ベアラ）。
【００１８】
パケットは、特定のＱｏＳクラスに分類されて割り当てられるため、それに応じてマーク付けされる。特にベアラは、（上述したように）ネットワークにおいて全ての後続のノードに分類の結果を伝えるトンネルエンドポイント識別子（ＴＥＩＤ）により識別される。ＴＥＩＤは、Ｓ１ｕインタフェース及びＳ５インタフェース上でのみ、パケットがどのベアラ上で移動するかを識別するために使用され、この場合ＧＴＰプロトコルは、パケットを搬送するために使用される。種々のフィールド／機構（すなわち、無線関連識別子）は、エアインタフェースを介して使用され、この場合、ＧＴＰはパケットを搬送するために使用されない。
【００１９】
アップリンクパケットの場合、ネットワーク制御のために、移動ノードは分類及びベアラマッピングを実行し、全ての後続ノードはこの分類に依存することができる（１つのノードは実際にそれを検証する）。
【００２０】
しかし、ＰＭＩＰベースの解決方法は、ベアラ機能を含まず（すなわち、ベアラを確立できず）、ＰＤＮ  ＧＷ３１及び在圏ゲートウェイ２９の双方においてパケット分類を実行する必要がある。パケット分類を実現するために、ポリシー及び課金ルール機能（ＰＣＲＦ）は、分類ルールを在圏ゲートウェイ２９（すなわち、図２に示されたＰＤＮ  ＧＷ３１に加えて）にダウンロードする必要がある。また、ポリシールールは、ハンドオーバ等により在圏ゲートウェイが変った後に新しい在圏ゲートウェイにもまたダウンロードされなければならない。このことは、結果としてポリシーに関連した信号伝送が過剰になるという欠点を有し、ポリシーシステムを、移動を意識したものにする。
【００２１】
現在、クライアントモバイルインターネットプロトコル（ＣＭＩＰ）としても既知であるモバイルインターネットプロトコル（ＭＩＰ）は、非３ＧＰＰアクセスに対して一般に使用されることを考慮した唯一のホストベースの移動プロトコルである。ＰＭＩＰと同様に、ＭＩＰはベアラ機能がなく、そのため、非３ＧＰＰアクセスのゲートウェイにおいてフロー分類が必要であるという欠点を有する。換言すると、制御ノードは、フロー分類のためにＣＭＩＰトンネル内を調査しなければならない。しかし、ＣＭＩＰトンネルが暗号化されている場合、これは不可能である。
【発明の概要】
【発明が解決しようとする課題】
【００２２】
本発明の目的は、上述の欠点のうちの１つ以上の影響を受けない通信ネットワークのための方法及びモバイルインターネットプロトコル（又はクライアントモバイルインターネットプロトコル）、並びにそのような通信プロトコル及び方法を実行するように構成された装置を提供することである。
【００２３】
特に、本発明の目的は、ホストベースの移動管理がベアラサポートを含むモバイルインターネットプロトコル（又はクライアントモバイルインターネットプロトコル）を提供することである。
【課題を解決するための手段】
【００２４】
本発明の第１の態様によれば、モバイルインターネットプロトコル（ＭＩＰ）を使用してトラフィックを処理するように構成された、ホストベースで移動が管理された通信ネットワークにおける方法が提供される。方法は、移動セッション内でサブセッションが作成されるのを可能にし、且つ移動セッション内でデータパケットを転送する１つ以上のベアラを提供するステップを備える。
【００２５】
方法は、キー値を各ベアラと関連付けるステップを備える。
【００２６】
キー値は、関連付けられたベアラにより転送されているデータパケットのサービス品質（ＱｏＳ）を表す。
【００２７】
この方法は、ユーザプレーン上でデータパケットをルーティングするために使用される外側ヘッダを各ベアラと関連付けるステップを更に備える。これは、基礎となるデータパケットが暗号化される場合でもパケットを操作できるという利点を有する。
【００２８】
ベアラは、モバイルインターネットプロトコルのバインディングアップデート又はバインディング確認応答メッセージまたはその両方を使用して実行される。ベアラは、通信ネットワークにおいて移動ノード又はホームエージェントにより設定されてもよい。
【００２９】
複数のベアラの第１のベアラ及び第２のベアラにより、所定の移動ノードのトラフィックの第１の部分をその所定の移動ノードのトラフィックの第２の部分から区別できる。
【００３０】
この方法は、ＩＰフローフィルタの集合を提供するステップを更に有し、ＩＰフローフィルタの集合におけるひとつのＩＰフローフィルタが、データパケットを、対応するベアラとマッチさせるように構成される。
【００３１】
いずれのＩＰフローフィルタによってもマッチしなかったパケットを搬送するように構成されたデフォルトベアラが提供されてもよい。
【００３２】
この方法はまた、ベアラ中のパケットがネットワーク内の他のノードで処理されるべき方法を記述する記述子フィールドを各ベアラと関連付けるステップを有する。
【００３３】
キー値は、汎用ルーティングカプセル化（ＧＲＥ）を使用して各パケットに属される。
【００３４】
本発明の別の態様によれば、モバイルインターネットプロトコルを実行するように構成された、ホストベースで移動が管理された通信ネットワークの移動ノードにおける方法が提供される。この方法は、移動ノードにより要求される１つ以上のベアラと関連付けられた１つ以上のダウンリンクキー値を含むバインディング要求メッセージを第２のノードに送出するステップと、それぞれ１つ以上のベアラと関連付けられた１つ以上のアップリンクキー値を含むバインディング確認応答メッセージを第２のノードから受信するステップとを有する。
【００３５】
本発明の別の態様によれば、上述の方法を実行するように構成された移動ノードが提供される。
【００３６】
本発明の別の態様によれば、モバイルインターネットプロトコルをサポートするように構成された、ホストベースで移動が管理された通信ネットワークのホームエージェントノードにおける方法が提供される。この方法は、ホームエージェントノードにより要求される１つ以上のベアラと関連付けられた１つ以上のアップリンクキー値を含むベアラ設定メッセージを第２のノードに送出するステップと、１つ以上のベアラと関連付けられた１つ以上のダウンリンクキー値を含むベアラ設定確認応答メッセージを第２のノードから受信するステップとを有する。
【００３７】
本発明の別の態様によれば、モバイルインターネットプロトコルを実行するように構成された。ホストベースで移動が管理された通信ネットワークのホームエージェントノードにおける方法であって、第２のノードにより要求される１つ以上のベアラと関連付けられた１つ以上のダウンリンクキー値を含むバインディング要求メッセージを第２のノードから受信するステップと、それぞれ１つ以上のベアラと関連付けられた１つ以上のアップリンクキー値を含むバインディング確認応答メッセージを第２のノードに送出するステップとを有することを特徴とする方法が提供される。
【００３８】
本発明の別の態様によれば、上述の２つの段落の方法を実行するように構成されたホームエージェントノードが提供される。
【００３９】
本発明の別の態様によれば、モバイルインターネットプロトコルを実行するように構成された、ホストベースで移動が管理された通信ネットワークのアクセスルータノードにおける方法であって、１つ以上のベアラに対してサービス品質機能を構成するステップと、アクセスルータを通過するパケットにサービス品質機能を適用するステップとを有することを特徴とする方法が提供される。
【００４０】
本発明の別の態様によれば、上述の方法を実行するように構成されたアクセスルータが提供される。
【図面の簡単な説明】
【００４１】
次に、本発明をより理解し、本発明が実施される方法をより明確に示すため、単なる例として以下の図面を参照する。
【図１】図１は、モバイルＩＰネットワークを示す基本概略図である。
【図２】図２は、ＬＴＥ（Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ）規格を使用する通信ネットワークを示す概略図である。
【図３】図３は、ネットワークベースの移動管理ドメインにおけるベアラとサービスデータフロー（ＳＤＦ）との関係を示す図である。
【図４】図４は、本発明の一実施形態に係るフローチャートである。
【図５】図５は、本発明に係るベアラを示す図である。
【図６】図６は、移動ノードによりベアラの確立、変更又は削除中に実行されるステップを示す図である。
【図７】図７は、ホームエージェントによりベアラの確立、変更又は削除中に実行されるステップを示す図である。
【図８】図８は、移動ノード又はホームエージェントにより実行されるステップを示す図である。
【図９】図９は、中間ノードにより実行されるステップを示す図である。
【図１０】図１０は、本発明の別の実施形態に係るフローチャートを示す図である。
【図１１】図１１は、本発明の更に別の実施形態に係るフローチャートを示す図である。
【発明を実施するための形態】
【００４２】
クライアントモバイルインターネットプロトコル（ＣＭＩＰ）としても既知であるモバイルインターネットプロトコル（ＭＩＰ）ドメインに関連して、実施形態を以下において説明する。
【００４３】
本発明によれば、ＣＭＩＰシステム等のホストベースの移動管理システムは、ベアラのサポートを提供するように拡張される。ベアラにより、所与の移動セッション内にサブセッションを提供できる。各ベアラは、転送されているデータパケットと関連付けられたサービス品質（ＱｏＳ）等を示すキー値を割り当てられる。ベアラは、ＭＩＰｖ６規格への拡張等の既存のモバイルＩＰ規格の拡張を使用する移動ノードとホームエージェントとの間でエンドツーエンドに設定される。
【００４４】
従って、本発明のベアラにより、単一の移動ノードのトラフィックの部分を同一の移動ノードのトラフィックの他の部分から分離できる。換言すると、例えばサービス品質（ＱｏＳ）に基づいて、移動ノードのトラフィック内でベアラによる区別が可能になる。
【００４５】
図４は、本発明を更に簡単に例示するために、種々の段階及びステップを示すメッセージフローを示す。４０１〜４０９に示された段階及びステップは、移動ノード（ＭＮ）がバインディングを確立し、ホームエージェント（ＨＡ）とのトンネルを設定する方法を示す。尚、種々の段階及びステップ４０１〜４０９は、既存のＣＭＩＰ手順に従う標準的な段階及びステップである。
【００４６】
４１０〜４２３に示された段階及びステップは、本発明に従ってベアラが設定される方法を示し、４２４〜４３３に示された段階及びステップは、ハンドオーバが実行される方法を示す。
【００４７】
段階４１０でのベアラの設定中、キー値は取り決められ、ＩＰフローフィルタは、所与のベアラ上に転送されるパケットを示す。要するに、各エンドポイントは他のエンドポイントに、このベアラについて受信したいキー値を通知する。例えばステップ４１１において、ＭＮは、ダウンリンクパケットにおいてＨＡにより使用されるはずのダウンリンクキーを（特に）ＨＡに通知するバインディングアップデートメッセージをＨＡに送出する。同様に、ステップ４１３において、ＨＡは、特にアップリンクパケットにおいてＭＮにより使用されるアップリンクキーをＭＮに通知するバインディング確認応答メッセージをＭＮに送出する。各キー値は、ＱｏＳ記述子等に対応する。ＱｏＳ記述子は、信号伝送において使用されるだけである（メッセージ４１１〜４１３及び４２６〜４２８において「ＱｏＳ」として示される）。尚、キー値は任意のＱｏＳ記述子である。例えば３ＧＰＰコンテキストにおいて、キー値は、クラス識別子（ＱＣＩ）、割り当て及び保持ポリシー（ＡＲＰ）、最大ビットレート（ＭＢＲ）又は保証ビットレート（ＧＢＲ）の値である。
【００４８】
ハンドオーバ段階４２４の間、ステップ４２６において、ＭＮは、ベアラの完全なリストを含むバインディングアップデートメッセージをＨＡに送出する。尚、図４の例において、参照しやすくするために、１つのベアラのみが設定されているものとして示されるため、「完全なリスト」は１つの項目のみに対するものであり、メッセージ４２６において繰り返される。しかし、複数のベアラがあった場合、複数の（５タプル、ダウンリンクキー、ＱｏＳ）値がリストされることが理解されるだろう。尚、実際には、あるベアラ（すなわち、サブセッション）内に多数のマイクロフロー（すなわち、ＳＤＦ）がある場合、５タプルは５タプルのリストを意味する。また、５タプル以外の機構が本発明の範囲から逸脱せずに使用されてもよいことが理解されるだろう。
【００４９】
バインディングアップデートメッセージ内にベアラの完全なリストを含むことにより、移動ノードが到着してそこでバインディングを設定する場合に、新しいアクセスはＱｏＳを設定できる。
【００５０】
第１の構成によれば、アクセスルータ（ＡＲ1）は、バインディングアップデートメッセージ及びバインディング確認応答メッセージ（ＢＵ／ＢＡ）を傍受又は監視し、どのベアラが確立されるかを学習し、ＱｏＳ及び関連付けられたキーを判定する。次にＡＲ1は、これらの（アップリンク又はダウンリンク）キーでマーク付けされたトンネル内を移動する全てのパケットにＱｏＳを提供する。
【００５１】
第２の構成によれば、プロキシがＭＩＰ信号伝送の経路に提供されることにより（すなわち、ＭＮが、ＨＡではなくＡＲ1等のプロキシにバインディングアップデートメッセージを送出する場合）、そのような構成においてＡＲ1は、代理するメッセージを検査することでベアラを学習するように構成される。
【００５２】
第３の構成によれば、ポリシー及び課金サーバ（例えば、ポリシー及び課金ルール機能ＰＣＲＦ）は、本明細書において後で説明されるように、ＱｏＳでＡＲ1を明示的に設定するように構成される。これは、ＡＲ1とＰＣＲＦとの間でＱｏＳ提供をネゴシエートすることを含む。
【００５３】
汎用ルーティングカプセル化（ＧＲＥ）トンネリング等のトンネリングは、パケット毎にキー値を伝送するパケットをトンネリングするためにユーザプレーンにおいて使用される。そのキー値は、パケットが属するベアラを識別する。パケットのペイロードが暗号化される場合、ＧＲＥトンネルは暗号化されないため、ベアラは、実際には中間ノード（図４のＡＲ1、すなわち「ミドルボックス」）により推定できる。
【００５４】
上述したように、中間ノードは、通過するＭＩＰ信号伝送を傍受し、ベアラについて学習する。従って、「プロキシ」（すなわち、ＡＲ1）が信号伝送の経路に挿入される（ＣＭＩＰの拡張として）場合、中間ノードはさらに、ベアラ要求を規制し、また変更する。ベアラを設定する場合、ＭＮは、ネットワークにリソースを効率的に要求する。ＭＮは、「これらのマイクロフローに、この帯域幅までこれらの（適切な）ＱｏＳ特性を持たせて欲しい」と効率的に要求する。この結果、効果的に、帯域幅が予約され、これらのパケットに低遅延が提供される。これらの要求の規制、すなわちこのユーザがそのような要求及びリソースを受ける資格があるかをチェックすることはネットワークの動作である。課金は、ユーザがリソースを有する長さ又はユーザがこのベアラにおいて送出したトラフィックの量をカウントするカウンタの設定を含むため、課金システムは、後でこれらのカウンタを金銭的価値に変更できる。
【００５５】
図５は、本発明に従ってベアラ上を伝送するようにフォーマットされたパケットの構成を示す。
【００５６】
ベアラ上を伝送するためにフォーマットされたパケットは、以下の特徴により規定される。
【００５７】
・外側ＩＰヘッダ４２、
・キー値を含むＧＲＥヘッダ４４、
・組み合わされたヘッダ４６及びペイロード４８を含む内側ＩＰパケット。
【００５８】
上述したように、ＧＲＥヘッダ４４に含まれたキー値は、その特定のベアラ上でその特定のパケットのペイロードに割り当てられたサービス品質クラスを示す。外側ＩＰヘッダ４２は、パケットをルーティングするためにユーザプレーンにおいて使用される。上記から、内側ＩＰパケット（すなわち、ヘッダ４６及びペイロード４８を含む）が暗号化されている場合でも、ノードは、依然として外側ＩＰヘッダ４２及びキー値を含むＧＲＥヘッダ４４を傍受又は監視できることが理解されるだろう。従って、ノードは、パケットを復号化する必要なくＱｏＳをパケットに適用できる。
【００５９】
ＱｏＳ記述子は、ベアラ設定中にＭＮとＨＡとの間でやり取りされる。この処理の一部として、アクセスルータはまたそれらを学習する（例えば、上述した３つの異なる構成のうちの１つに従って）。その後、記述子は、それ以上通信されるのではなく、これらの３つのノードに格納される。しかし、ハンドオーバ中に全てのＱｏＳ記述子が再送される場合、例外が発生する。
【００６０】
個々のパケットは記述子を搬送しないことが理解されるだろう。そうではなく、キー値はパケットと関連付けられ、前にやり取りされたＱｏＳ記述子に対する参照として使用される。
【００６１】
ＩＰフローフィルタの集合は、特定のベアラに割り当てられるパケットにマッチする。フローフィルタは、各々がＩＰ送信元アドレス、ＩＰ宛先アドレス、送信元ポート、宛先ポート、プロトコル（例えば、ＴＣＰ又はＵＤＰ）から構成される５タプル値のリストである。これらは、ベアラ設定中にバインディングアップデート信号伝送を使用してＭＮ及びＨＡにインストールされる。中間ノードは、ＩＰフローフィルタを必ずしも必要としない。また、ユーザプレーンパケットはＩＰフローフィルタも含まない。パケットは、ＨＡ又はＭＮにより他に送出される場合、フローフィルタに対してチェックされ、パケットが配置されるべきベアラを見つける。その後、そのベアラのキーは、ＧＲＥヘッダ（ＭＮにより送出される場合はアップリンク、ＨＡにより送出される場合はダウンリンク）に配置される。
【００６２】
記述子フィールドは、特定のベアラのパケットがネットワークにおいて他のノードで処理されるべき方法を記述する。例えば、３ＧＰＰシステムの場合、これは、ＱｏＳクラス識別子（ＱＣＩ）、割り当て及び保持ポリシー（ＡＲＰ）、最大ビットレート（ＭＢＲ）又は保証ビットレート（ＧＢＲ）に関連する１つ以上の値を含む。
【００６３】
ＱＣＩは、ベアラレベルパケット転送処理（例えば、スケジューリング重み、承認閾値、待ち行列管理閾値、リンクレイヤプロトコル構成等）を制御し、かつアクセスノード（例えば、ｅＮｏｄｅＢ２１）を有する事業者により事前設定されているアクセスノード固有のパラメータにアクセスするための参照として使用されるスカラである。
【００６４】
ＧＢＲは、ＧＢＲベアラにより提供されることが予想されるビットレートを示す。ＭＢＲは、ＧＢＲベアラにより提供されることが予想されるビットレートを制限する（例えば、過剰なトラフィックはレートシェーピング機能により無視される）。
【００６５】
ＡＲＰは、優先レベル（スカラ）に関する情報、並びに横取り(pre-emption)機能及び脆弱性フラグを含む。ＡＲＰの主な目的は、ベアラ確立／変更要求が受け入れられるか、あるいはリソース制限の場合に拒否されるべき要求があるかを判断することである。ＡＲＰの優先レベル情報はこの判断のために使用され、より高い優先レベルを有するベアラの要求が選択されることを保証する。更にＡＲＰは、ハンドオーバ等の例外的なリソース制限中にドロップするベアラを判断するために使用される（例えば、ｅＮｏｄｅＢにより）。ＡＲＰの横取り機能情報は、より低いＡＲＰ優先レベルを含むベアラが、要求されたリソースを解放するためにドロップされるべきであるかを規定する。ＡＲＰの横取り脆弱性情報は、ベアラが、より高いＡＲＰ優先値を有する横取り対応のベアラによるそのようなドロップに適用可能であるかを規定する。いったん成功裡に確立されると、ベアラのＡＲＰは、ベアラレベルパケット転送処理（スケジューリング及びレート制御等）に全く影響を及ぼさない。換言すると、好ましくは、パケット転送処理は、記述子フィールドの他の値、すなわちＱＣＩ、ＧＢＲ及びＭＢＲを使用して判定されるべきである。
【００６６】
ベアラは、ＣＭＩＰバインディング、すなわち１つのホームアドレス（ＨｏＡ）と１つの気付アドレス（ＣｏＡ）とのバインディング内に存在する。ＨＡにおいて、各ＨｏＡは登録済みＣｏＡを有しており、これがバインディングである。各バインディングは１つのＭＮに対応する。各ＭＮは、ゼロ又は１つ以上のベアラを有する。
【００６７】
一実施形態によれば、ベアラのうちの１つはデフォルトベアラとして示される。デフォルトベアラを提供することにより、ＩＰフローフィルタのうちのいずれにもマッチしていない全てのパケットを転送できる。移動ノード又はホームアドレスは、そのようなパケットに対してもパケット処理を指定し、その場合ＭＮは、アドレスに対してプレフィックス長がゼロのＩＰフローフィルタ及び他の全てのフィールドに対するワイルドカードを指定する。
【００６８】
図６は、移動ノードＭＮによりベアラの確立中に実行されたステップを開示する簡略化されたフローチャートである。これらは、図４のステップ４１１〜４１３に対応し、以下において更に詳細に説明される。尚、同様のメッセージフローがベアラの変更又は削除のために更に使用されてよい。
【００６９】
ＭＮは、新しいベアラを確立するか、既存のベアラを変更するか、あるいはベアラを削除したい場合、ステップ５０１の新しいバインディングアップデートをＨＡに送出する。一実施形態において、ＭＮは、バインディングアップデートメッセージ５０１のパラメータで要求されたベアラを一覧表示する。バインディングアップデートメッセージのパラメータは、フローフィルタ（５タプル）、所望するダウンリンクキー及びフローのＱｏＳを指定する。バインディングアップデートメッセージは、ホームアドレス又は気付アドレス等の他の情報を更に含む。ＨＡがステップ５０３でバインディング確認応答メッセージを送出することにより要求されたアップリンクキーで応答し、５タプルを繰り返すため、ＭＮは応答が対応するベアラを認識する。
【００７０】
ＨＡは、ベアラパラメータを監視し、バインディング確認応答メッセージ５０３において受け入れられたベアラのリストを返送する。ＨＡは、要求されたＱｏＳのレベルが高すぎること（例えば、低品質サブスクリプション）を判断し、ＱｏＳを格下げする。これは、ステップ５０３のバインディング確認応答において「受け入れられたＱｏＳ」メッセージとして示される。拒否又は変更されたベアラに対して、バインディング確認応答メッセージは、変更又は省略に対する説明として誤りコードを更に含む。
【００７１】
上述したように、ＭＮによるベアラの確立はＨＡによるベアラの確立に更に適用されることが理解されるだろう。
【００７２】
従って、ＨＡは、ベアラを確立したい場合、更新されたベアラのリストを含む適切に規定された新しい移動メッセージをＭＮに送出することでベアラを確立する。
【００７３】
図７は、そのようなベアラを設定するＨＡを示すフローチャートである。ＭＩＰにおいてＭＮのみがメッセージングを開始できるため、これは本発明（ベアラ設定）により採用された新しい種類のメッセージである。しかし、これはベアラの設定方法の一例にすぎないことが理解されるだろう。あるいは、他の何らかの種類のメッセージが再利用される。ステップ４３５において、ＨＡは、フローフィルタ（５タプル）、所望するアップリンクキー及びフローのＱｏＳを指定するＭＮに、この「ベアラ設定メッセージ」を送出する。ステップ４３７でＭＮが、要求されたダウンリンクキーを応答し、５タプルを反復するため、ＨＡはどのベアラにその応答が対応しているかを認識する。
【００７４】
従って、ＭＮ及びＨＡの双方はベアラの確立を開始できる。特定のネットワークノードがＭＮに気付かれずにトラフィックの特定の部分にＱｏＳを提供したい場合、ＨＡは有用である。例えば、ユーザがオンラインビデオを見ているとすると、ユーザにデータを送出するウェブサーバは、ユーザに帯域予約を提供するようにＨＡに要求するため、ビデオは決して再バッファリングしない。これは、ウェブサーバが、要求されたＱｏＳ及びビデオを搬送するフローの５タプルを有するメッセージをＨＡに送出することにより実行される。ＨＡがＱｏＳを設定するため、ユーザのユーザ端末は、実際には何もする必要がない（アプリケーション開発者が気付かないように、通常、ブラウザではなくカーネルにより実行されるメッセージの確認応答以外）。ＨＡにより確立されたベアラは、ＭＮにより確立されたベアラと共存できる。
【００７５】
図４に関連して上述したように、ＭＮがある基地局から別の基地局に移動する場合のハンドオーバ手順中、ＭＮからＨＡに送出されたバインディングアップデートメッセージは全てのベアラを含む。
【００７６】
新たに規定された拡張、すなわちベアラパラメータの記述（例えば、アップリンク／ダウンリンクパケットで使用されるキー値、ベアラのＱｏＳ記述子及びベアラ上に伝送されるＳＤＦのＩＰフィルタ）を搬送するＭＩＰメッセージ中の情報要素を有さないバインディングアップデートメッセージは、デフォルトベアラを除く全てのベアラを除去する。これは、ＣＭＩＰにおける従来のバインディングアップデートメッセージ（すなわち、本発明により提供されるようなベアラを全く含まない）の意味により、ベストエフォート型のトンネルを設定できるためである。従って、これらの拡張を含む場合でも、本発明はこれらの意味を維持する。これにより、既存のシステムとの適切な後方互換性が可能になる。
【００７７】
図８は、ユーザプレーン上の挙動を説明する。ベアラ設定中、キー値は、ステップ８０１でベアラ毎に特定される。その後、パケット伝送中、特定されたキー値は、ステップ８０３、でその特定のベアラにおいて転送される各データパケットに添付される。上述したように、キー値を各データパケットに添付する１つの技術は、ステップ８０５で汎用ルーティングカプセル化（ＧＲＥ）を使用する技術である。キー値を持たないカプセル化を使用してノードに到達するパケットは、デフォルトベアラ上に到達したかのように処理される。ＩＰ−ｉｎ−ＩＰカプセル化を用いて送出されたパケットはデフォルトベアラ上を移動するので、これにより適切な後方互換性が可能になる。またこれにより、デフォルトパケットに対するオーバヘッドの低減が可能になる。
【００７８】
図９は、ミドルボックス（すなわち、中間ノード又は透過性ノードＡＲ）において実行された基本ステップを説明する。非３ＧＰＰアクセスネットワークのゲートウェイ（ＧＷ）等のミドルボックスは、ステップ９０１でバインディングアップデートメッセージ／バインディング受け入れメッセージを傍受又は監視する。その傍受に基づいて、ゲートウェイは、ステップ９０３で、確立されるベアラの種類を推定する。複数の種類のＱｏＳを有する必要があるならば、複数のベアラを確立できる。例えばビデオ／電話の場合、ひとつのベアラは音声に対して開き、別のベアラはビデオに対して開くことができる。双方は、同一ではないが特別なＱｏＳを必要とする（例えば、音声はパケットの損失を許すが、それに対してビデオは許さない）。
【００７９】
次に、ステップ９０５において、ベアラ上で受信した情報により、アクセスネットワークにおいてサービス品質を設定できる。これは、ミドルボックス又は特定のアプリケーションに依存する他のノードにおいて実行される。例えば、ＭＩＰプロキシ（例えば、図４に示されたＡＲ1）上で監視する場合、ミドルボックスはそれ自身でＱｏＳを設定する。ポリシー及び課金サーバ（ＰＣＲＦ）がＱｏＳでＡＲを明示的に設定する場合、これはＰＣＲＦにより実行される。そのようなＱｏＳ設定が失敗したかをステップ９０７で判定する場合、ミドルボックスは、ステップ９０９で、ＩＣＭＰメッセージ又は移動メッセージをベアラ設定のイニシエータに応答し、ＱｏＳ失敗をそれに通知する。そのようなＱｏＳ設定が可能であることをステップ９０７で判定する場合、ミドルボックスは、ステップ９１１で受け入れられたものとしてＱｏＳを処理し、次にこれらの（アップリンク又はダウンリンク）キーでマーク付けされたトンネルにおいて移動する全てのパケットにそのＱｏＳを適用する。
【００８０】
上述において、ミドルボックスは安全なチャネルを使用して移動ノードと通信し、バインディングアップデートメッセージは暗号化されないものとする。本明細書において上述した第１の構成及び第２の構成の例において、バインディングアップデートが暗号化される場合、ミドルボックス（すなわち、図４のＡＲ1）は、ベアラのパラメータを学習しない（ミドルボックスがバインディングアップリンクを解読しないため）。従って、ミドルボックスがＱｏＳを設定できないため、ベアラを有するという概念は機能しない。
【００８１】
尚、上述の実施形態において、アクセスルータ（ＡＲ）は、使用される場合にＭＩＰｖ６にプロキシ機構を提供する。ＡＲは、ＭＩＰｖ４フォーリンエージェントが動作する方法と同様の方法でそのようなプロキシ機能をホストに広告する。次に移動ノードは、バインディングアップデートメッセージをアクセスルータに配置されたこれらのＭＩＰプロキシに送出する結果、バインディングアップデートメッセージをホームエージェントに送出する。
【００８２】
そのようなプロキシ機構がある状態で、プロキシは、確実にベアラ変更要求を読み出し、変更し、それに応答する。ＣＭＩＰ＋＋モバイルノードプロキシ機構は、そのような機構の１つである。
【００８３】
図１０及び図１１は、本明細書において上述した第３の機構の場合の信号伝送フローを説明する。この場合、（例えば）ポリシー及び課金制御インフラストラクチャは３ＧＰＰにより規定されているとする。次に、これを単一のノード、すなわちＰＣＲＦにより示す。
【００８４】
ＭＮは、段階４３８で新しいベアラを確立したい場合、ステップ４３９で、上述した実施形態と同一の方法でバインディングアップデートメッセージをＨＡに送出する。しかし、ＨＡは、バインディングアップデートメッセージを受信すると、ステップ４４０でポリシー要求を送出することでＰＣＲＦに通知する。次にＰＣＲＦは、ステップ４４１でポリシー判断を行う。ＰＣＲＦは、ポリシー要求が受け入れ可能であるか否かを判定し、必要に応じてＱｏＳ記述子を変更する。その後、ステップ４４２〜４４４において、ＰＣＲＦは、明示的にミドルボックス（ＡＲ2）においてＱｏＳを設定する。次にミドルボックス（ＡＲ2）は、容易にステップ４５２でＱｏＳを適用する。この構成において、第１の構成及び第２の構成と同様に、ミドルボックスはバインディングアップリンクメッセージをスヌープする必要はなく、ＭＩＰプロキシもその必要はない。
【００８５】
図１１は、３ＧＰＰ  ＰＣＣアーキテクチャにおいて規定されたアプリケーション機能に従って、例えば図１１のアプリケーション機能ノードＡＦからネットワークが段階４４５でベアラを設定する場合にＱｏＳ確立のために実行されるステップを示すフローチャートである。ステップ４５６において、設定ＱｏＳメッセージは、ＡＦからＰＣＲＦに送出される。次にＰＣＲＦは、ポリシー判断を行い、ＱｏＳパラメータを導出する。次にＰＣＲＦは、ＱｏＳルールをＨＡに送出する。ステップ４５９〜４６１において示されるように、ＨＡは、ＭＮと共にベアラを設定する際にＱｏＳルールを使用する。ステップ４６２でＱｏＳルール確認応答を受信すると、次にＰＣＲＦは、ステップ４６３〜４６５でＡＲ2のＱｏｓを設定する。その後、アクセスルータＡＲ2は、バインディングアップデートメッセージを傍受する必要なく、容易にステップ４７１でＱｏＳを適用する。
【００８６】
本発明により、移動信号伝送に結合されたアクセスネットワークにＱｏＳ情報を配信できる。これにより、ポリシーインフラストラクチャが移動を考慮するようになり且つアクセスネットワークに対する信号伝送を有する必要性を軽減する。本発明は、ＧＴＰの特性をクライアントＭＩＰにより提供されたホストベースの移動管理と組み合わせるという利点を有する。
【００８７】
尚、移動セッションは、移動管理のためにＣＭＩＰを使用して移動ノード及びホームエージェントにおいて確立された状態を示す。移動セッションは、初期のバインディングアップデートメッセージを使用して確立され、移動ノードに対するキャッシュエントリをホームエージェントから除去するバインディングアップデートにより終了する。移動セッション中、ホームエージェントは、移動ノードの動きを追跡し（後続のバインディングアップデートメッセージを介して）、移動ノードに対してアドレス指定された全てのトラフィックを移動ノードの現在位置（気付アドレスにより識別された）に転送する。
【００８８】
上述の実施形態におけるサブセッションの目的は、異なるＱｏＳ処理を可能にすることであることが理解されるだろう。しかし、本発明はこの適応例に限定されず、サブセッションは、移動セッション内で異なるセキュリティ処理をサブセッションに提供する等の他の適応例に対して使用されてよい。
【００８９】
尚、「実行するように構成された」又は「サポートするように構成された」を参照することは、装置が必要な機能を実行するようにあるいは実行されている機能の動作をサポートするように構成された技術的手段を備えることを含むことを意図する。
【００９０】
尚、上述の実施形態は本発明を限定せず、当業者は、添付の請求の範囲の範囲から逸脱せずに多くの別の実施形態を設計できる。「備える」という用語は、請求の範囲において列挙された以外の要素又はステップの存在を除外せず、「単数形」は複数形を除外せず、単一のプロセッサ又は他のユニットは、請求の範囲において説明されたいくつかのユニットの機能を実現する。請求の範囲における図中符号は、いずれも請求の範囲の範囲を限定するように解釈されるべきではない。
【図１】
0005570611.tif 000002
【図２】
0005570611.tif 000003
【図３】
0005570611.tif 000004
【図４】
0005570611.tif 000005
【図５】
0005570611.tif 000006
【図６】
0005570611.tif 000007
【図７】
0005570611.tif 000008
【図８】
0005570611.tif 000009
【図９】
0005570611.tif 000010
【図１０】
0005570611.tif 000011
【図１１】
0005570611.tif 000012