JPWO2009054127A1 - 通信システム及び移動端末並びにネットワークノード - Google Patents

Abstract

移動端末がホームネットワークドメインではないネットワークベースのモビリティ管理ドメインに接続している場合に、移動端末のプリファレンスに基づいたルーティングを効率良く実現する技術が開示される。移動端末（ＭＮ）１０１は２つのインタフェースを有し、それぞれのインタフェースがＭＡＧ１１１及びＭＡＧ１１２のそれぞれに接続された状態で、モビリティ管理ドメイン（ローカルモビリティドメイン）１１に接続されている。ＭＮ自身が特定のパケットフロー通信に利用するいずれか一方のインタフェースを決定した場合、そのインタフェースにパケットフローがルーティングされるように指示するルーティングプリファレンスをＭＡＧに通知し、ＭＡＧがＬＭＡ（フィルタリングエージェント）１１０に対してルーティングプリファレンスを通知することで、ＬＭＡにおいて、ルーティングプリファレンスに基づくフィルタリングが実行される。

Description

本発明は、インターネットプロトコル（ＩＰ：Internet Protocol）を利用した通信技術に係る通信システム及び移動端末並びにネットワークノードに関し、特に、フィルタルールに応じてパケット転送経路の設定（フローフィルタリング）を行う通信システム及び移動端末並びにネットワークノードに関する。

例えば下記の非特許文献１には、モバイルＩＰｖ６（ＭＩＰｖ６）を使用することで、モバイルノード（ＭＮ：Mobile Node）が、インターネットへの接続ポイントを変更した場合であっても、不変の固定アドレスを使用し続けることを可能とする技術が開示されている。ＭＩＰｖ６におけるＭＮの固定アドレスは、ＭＮのホームネットワークドメインにおけるアドレスであり、ホームアドレス（ＨｏＡ：Home Address）と呼ばれている。また、ＭＮは外部（foreign）ネットワークドメインに接続されている間は、外部ネットワークドメインから通知されるサブネットプレフィックスを用いてＩＰアドレスを構成することが可能である。このように構成されるＩＰアドレスは、気付アドレス（ＣｏＡ：Care-of Address）と呼ばれ、ＭＮはこのアドレスによっても到達可能となる。

ＭＮは、その接続位置によらずに到達可能性を維持するために、自身の気付アドレスとホームアドレスとを関連付けてホームエージェント（ＨＡ：Home Agent）に登録する。ＭＩＰｖ６では、ＨＡはＭＮのホームネットワークドメイン内のルータであり、ＭＮの現在の気付アドレスがＨＡに登録される。この登録は、ＭＮがＨＡに対してバインディングアップデート（ＢＵ：Binding Update）メッセージを送信することで実現される。

ＭＮがホームネットワークドメインから離れた場所に位置している場合には、ＨＡはＭＮのホームアドレスあてのパケットを受信（intercept）し、関連する気付アドレス経由でＭＮにパケットをトンネルする。

ＭＩＰｖ６では、ホストがモビリティ管理機能を有している。したがって、ＭＩＰｖ６は、ホストベース（端末ベース）のモビリティ管理プロトコルと呼ばれることもある。

一方、ＭＮがローカルモビリティドメインを移動する際に行うモビリティ関連のシグナリングを軽減させる別のモビリティ管理の方法も存在する。例えば、ローカルモビリティドメイン内に配置されたプロキシエンティティによって、ＭＮのモビリティ管理が補助されるようにすることが可能である。このようなモビリティ管理の方法は、ネットワークベースのモビリティ管理と呼ばれ、例えば、下記の特許文献１や下記の非特許文献２に記載されている。なお、本明細書では、ＭＩＰｖ６などのホストベースのモビリティ管理プロトコルを実装している移動端末だけではなく、ネットワークベースのモビリティ管理ドメインによってモビリティ管理を受けている移動端末に関してもモバイルノード（ＭＮ）と呼ぶ。

図１には、従来の技術におけるネットワークベースのモビリティ管理システムの一例が図示されている。図１において、モバイルノード（ＭＮ１０１）は、本来ホームネットワークドメイン１０に接続している場合には、ホームアドレスを用いてコレスポンデントノード（ＣＮ：Correspondent Node）１４０との間で通信セッションを有している。

また、ＭＮ１０１は移動可能であり、グローバル通信ドメイン１３を移動する場合には、例えばＭＩＰｖ６を用いることで確実にＣＮ１４０との間で通信を継続することが可能となる。すなわち、ＭＮ１０１は、移動を行った際には、移動先の気付アドレスをホームアドレスに関連付けて、ホームネットワークドメイン１０内のホームエージェント（ＨＡ：Home Agent）１０２に登録することが可能となる。

また、ＭＮ１０１は、ローカルモビリティドメイン１１に移動すると、ＭＮ１０１の固有の識別子（ＭＮ−ＩＤ）を提示してアクセス認証処理を受け、ＭＡＧ（Mobile Access Gateway：モバイルアクセスゲートウェイ）に接続する。なお、ローカルサーバ（ローカルモビリティドメイン１１内の不図示のサーバ）から得られるＭＮ１０１のポリシプロファイル（policy profile）との関連付けが行われる際には、通常はＭＮ−ＩＤが用いられる。

ポリシプロファイルには、例えば、提供されるネットワークベースのモビリティサービスの特性や、モバイルノードに割り当てられるオンリンクプレフィックス、許可されるアドレス構成モード、ローミングポリシ、その他のネットワークベースのモビリティサービスに必須の関連パラメータなどが含まれる。

例えば、ＭＮ１０１がＭＡＧ１１１に接続する際には、ＭＮ１０１のアクセス認証が成功した後、ＭＡＧ１１１は、ローカルサーバからＭＮ１０１のポリシプロファイルを取得する。これにより、ＭＡＧ１１１は、ＭＮ１０１のモビリティシグナリングを実行するために必要な情報を取得することが可能となる。したがって、ＭＡＧ１１１は、例えば、ＭＮ１０１に割り当てられるオンリンクプレフィックスを含むルータ通知（ＲＡ：Router Advertisement）メッセージを周期的にＭＮ１０１に送信する。

ＭＮ１０１は、ＲＡメッセージを受信してオンリンクプレフィックスを発見すると、ローカルモビリティドメイン１１に接続されているインタフェースが行う通信用にＩＰアドレス（例えば気付アドレス）を構成する。ローカルモビリティドメイン１１内の各ＭＡＧは、常にローカルサーバを参照して、ＭＮ１０１のプロファイルを取得することが可能である。したがって、ＭＮ１０１は、ローカルモビリティドメイン１１のどの接続ポイント（ＭＡＧ）に接続されている場合でも、その接続インタフェースから常にオンリンクプレフィックスを把握することが可能となる。

例えば、ＭＮ１０１がＭＡＧ１１２に移動すると、ＭＡＧ１１２は、その認証処理中にＭＮ１０１のＭＮ−ＩＤに基づいてローカルサーバからＭＮ１０１のオンリンクプレフィックスを取得する。したがって、ＭＮ１０１は、ローカルモビリティドメイン１１内の接続位置によらず、最初に構成したＩＰアドレス（ローカルモビリティドメイン１１に最初に接続した際に構成したＩＰアドレス）を常に利用することが可能である。

また、ローカルモビリティドメイン１１内のルーティングに関しては、ローカルモビリティアンカ（ＬＭＡ：Local mobility Anchor）１１０と呼ばれるエンティティが、各モバイルノードのトポロジ的な（論理的な）アンカポイントとして機能する。さらに、ＬＭＡ１１０は、各モバイルノードの到達可能状態の管理を行う。したがって、ＬＭＡ１１０は、非特許文献１に記載されているホームエージェントと類似する面を持っている。すなわち、ＬＭＡ１１０は、各ＭＮ１０１のアンカポイントとして機能するように、各ＭＮ１０１の現在位置に係るアップデートが行われる必要がある。

このアップデートを行うため、ＭＮ１０１がＭＡＧに接続する際には常に、ＭＡＧからＬＭＡ１１０に、プロキシバインディングアップデート（ＰＢＵ：Proxy Binding Update）メッセージが送信される。このＰＢＵメッセージにより、ＬＭＡ１１０には、ＭＮ１０１の固有の識別子であるＭＮ−ＩＤがそのＭＡＧを識別する情報（ＭＡＧの気付アドレス）に関連付けて登録される。ＬＭＡ１１０は、ＰＢＵメッセージによって登録されたバインディングを用いることで、適切なＭＡＧを通じてパケットをＭＮ１０１に発送することが可能となる。

また、ローカルモビリティドメインがＭｏｎａｍｉ６の方法を採用してモバイルノードの同時接続をサポートする場合に生じる問題に関しては、例えば特許文献１の記載においても言及されている。

また、下記の特許文献２では、ユーザ機器に関するポリシを把握するため、ゲートウェイノードがポリシコントロールノードに問い合わせを行えるようにするメカニズムが開示されている。また、このメカニズムを適用することで、ローカルモビリティアンカが、モバイルノードのルーティングプリファレンスに関して、モバイルノードのホームエージェントに問い合わせを行うことが可能となる。

また、モバイルノードが、例えばＩＥＥＥ８０２．２１で定義されている情報サービスのような探索メカニズムを使用することによって、ルーティングプリファレンスを設定すべきローカルモビリティドメイン内の場所（ＬＭＡのアドレス）を探索することが可能である。さらにＭＮ１０１は、例えばＩＥＥＥ８０２．２１を利用して、ＬＭＡ１１０のアドレスを探索することが可能であり、ＬＭＡ１１０のアドレスを把握したＭＮ１０１は、ＬＭＡ１１０と通信を行い、ＣＮ１４０からのトラフィックフローに関するルーティングプリファレンスをＬＭＡ１１０に指示することが可能である。

例えば、図１において、ＭＮ１０１がＭＡＧ１１１に接続し、ＭＮ１０１とＭＡＧ１１１と間で認証処理が実行される。ＭＡＧ１１１は、ＭＮ１０１の認証が成功した後、ＭＮ１０１のＭＮ−ＩＤをＭＡＧ１１１の気付アドレスに関連付けるＰＢＵメッセージをＬＭＡ１１０に送信することによって、ＬＭＡ１１０にＭＮ１０１に係るバインディングが登録される。

ＬＭＡ１１０はパケットを受信すると、自身のキャッシュをチェックして、受信パケットのあて先に一致するＭＮ−ＩＤを探索する。例えば、ＬＭＡ１１０は、受信パケットのあて先がＭＮ１０１のＭＮ−ＩＤに一致することを特定すると、登録されているバインディングに基づいて、ＭＡＧ１１１にパケットをトンネルする。そして、ＭＡＧ１１１からＭＮ１０１にパケットが転送される。

また、現在、複数のネットワークインタフェースを備えた持ち運び可能な電子周辺機器の導入により、モバイルノード／ルータは、所定のホームアドレスに対して複数の気付アドレスを登録する機能を有している。複数の気付アドレスの登録方法に関しては、現在、ＩＥＴＦのＭｏｎａｍｉ６（Mobile Nodes and Multiple Interfaces in IPv6）ワーキンググループで議論が進められている。

例えば、下記の非特許文献３に記載されている技術によれば、１つのホームアドレスに関連付けられる複数のバインディングをＢＩＤ（バインディング固有識別情報）と呼ばれる識別番号を用いて区別することにより、複数の気付アドレスの登録が行われる。ＢＩＤは、モバイルノード／ルータの１つのホームアドレスに関連付けられるインタフェース又は気付アドレスのそれぞれに対して割り当てられる。したがって、ホームアドレスはモバイルノード／ルータ自体に関連付けられている一方、ＢＩＤはモバイルノードによって登録された複数のバインディングのそれぞれを識別できるように関連付けられている。

モバイルノード／ルータは、バインディングアップデート（ＢＵ）メッセージを使用してホームエージェントにＢＩＤを通知し、ホームエージェントは、自身のバインディングキャッシュにＢＩＤを記録する。さらに、複数の気付アドレスの登録によって、モバイルノード／ルータがプリファレンス（preference）をホームエージェントに設定して、複数の気付アドレスを通じてトラフィックフローの選択的なルーティングを実行できるようになる可能性がある。

このプリファレンス設定方法は、例えば、下記の非特許文献４や下記の非特許文献５に記載されているように、各トラフィックフローを固有の識別子（フローＩＤ：ＦＩＤ）で識別することによって実現される。このＦＩＤによって、モバイルノード／ルータは、特定のトラフィックフローをどのように発送してほしいかをホームエージェントに指示することが可能となる。

また、下記の特許文献３では、モバイル機器自身が、ハンドオフ又は起動時にアクセスネットワーク内のルーティングパスの設定を開始させるためのパス設定メッセージを送信する方法が提案されている。この特許文献３に開示されている技術では、モバイル機器が、モバイル機器自身が接続しているアクセスネットワーク内のアクセスルータへパス設定メッセージを送信することで、アクセスルータにモバイル機器のルーティングエントリが作成又は更新される。さらに、アクセスルータからネットワーク階層の上位ルータ（次ホップのルータ）にパス設定メッセージが次々と送信されていくことで、ネットワーク階層の上位ルータにおいてルーティングエントリが作成又は更新される。その結果、アクセスネットワーク内のルータにモバイル機器のルーティングエントリが登録されて、アクセスネットワークにモバイル機器のルーティングパスが設定される。
D. Johnson, C. Perkins and J. Arkko, "Mobility Support in IPv6", Internet Engineering Task Force Request For Comments 3775, June 2004. S. Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury and B. Patil, "Proxy Mobile IPv6", Internet Engineering Task Force Internet Draft: draft-ietf-netlmm-proxymip6-00.txt, April 08, 2007. R. Wakikawa, T. Ernst and K. Nagami, "Multiple Care-of Addresses Registration", Monami6 Working Group Internet Draft: draft-ietf-monami6-multiplecoa-00.txt, June 12, 2006. H. Soliman, et al., "Flow Bindings in Mobile IPv6", Internet Engineering Task Force Internet Draft: draft-soliman-monami6-flow-binding-00.txt, February 27, 2006. C. Larsson, H. Levkowetz, H. Mahkonen and T. Kauppinen, "A Filter Rule Mechanism for Multi-access Mobile IPv6", Internet Engineering Task Force Internet Draft: draft-larsson-monami6-filter-rules-01.txt, October 23, 2006. 米国特許公開２００６／０２０９７５９ 国際特許公開ＷＯ２００７／０３９００６ 米国特許第７２３９６１８号

しかしながら、従来の技術によれば、移動端末がホームネットワークドメインとは異なるネットワークベースのモビリティ管理ドメインに接続している場合に、移動端末のプリファレンスを反映したルーティングが実現されない場合がある。

例えば、図１において、ＭＮ１０１が複数のインタフェースを有している場合、ＭＮ１０１は、ＭＡＧ１１１及びＭＡＧ１１２に同時に接続することが可能である。ここで、例えばローカルモビリティドメイン１１には、ＭＡＧ１１１が接続されているセルラネットワークと、ＭＡＧ１１２が接続されている無線ローカルエリアネットワーク（ＷＬＡＮ）の２つのタイプのネットワークが存在しているとする。この場合、ＭＮ１０１は、ＭＡＧ１１１に接続されているセルラインタフェースと、ＭＡＧ１１２に接続されているＷＬＡＮインタフェースの２つのインタフェースを有している。これにより、ＭＮ１０１は、ローカルモビリティドメイン１１内において複数の気付アドレスを有し、ＣＮ１４０からのトラフィックフローのＭＮ１０１への発送方法に関するプリファレンスをＨＡ１０２に設定する。

また、Ｍｏｎａｍｉ６の方法を使用して、ＭＡＧ１１１及びＭＡＧ１１２は両方共、モバイルノードの固有の識別子（ＭＮ−ＩＤ）をＬＭＡ１１０に登録することが可能である。これにより、ＬＭＡ１１０は、ＭＮ１０１がＭＡＧ１１１及びＭＡＧ１１２の両方に接続されており、ローカルモビリティドメイン１０内においてＭＮ１０１への２つのアクティブな経路が登録されていることを把握する。

しかしながら、ＬＭＡ１１０は、ＭＮ１０１のＭＮ−ＩＤに対応するパケットを受信した場合には、ＭＮ１０１にパケットを届けるためにどちらのＭＡＧにパケットを転送すべきであるかを選択する必要がある。ここで、例えばＭＮ１０１が、ＣＮ１４０からのトラフィックはＭＮ１０１のＷＬＡＮインタフェース経由で発送されるように指示するプリファレンスをＨＡ１０２に設定しているとする。ＨＡ１０２はＬＭＡ１１０にパケットを転送するが、ＬＭＡ１１０はＭＮ１０１によって設定されたプリファレンスを把握しておらず、その結果、ＬＭＡ１１０は、ＣＮ１４０からＭＮ１０１へのトラフィックフローを好ましくないルート（例えば、ＭＡＧ１１１経由）で転送してしまう可能性がある。

また、特許文献１に記載の技術では、モバイルアクセスゲートウェイがローカルモビリティドメインにおいて複数のインタフェースを有するモバイルノードのプロキシとして機能している場合であっても、モバイルアクセスゲートウェイは、モバイルノードに関するルーティングプリファレンスを把握することができないという問題がある。したがって、モバイルアクセスゲートウェイは、モバイルノードがローカルモビリティドメイン内におけるトラフィックフローに関してどのような伝送方法を望んでいるかを、ローカルモビリティアンカに通知することはできない。

また、特許文献２に記載の技術では、ホームネットワークドメインとローカルモビリティドメインとの間に何らかの関係（アソシエーション）が確立されている必要があるが、こうしたアソシエーションは確立していない（あるいは確立できない）可能性がある。

例えば、第３世代パートナーシッププロジェクト（３ＧＰＰ：Third Generation Partnership Project）のコンテキストを用いて、ホームネットワークドメインはオペレータの３ＧＰＰコアネットワークであり、ローカルモビリティドメインは、（オペレータにとって）信頼できない３ＧＰＰアクセスネットワークであるとする。このような場合、オペレータはローカルモビリティドメインを信頼することができないため、両方のネットワークの間にアソシエーションを確立することは困難となる。

また、上述のようなＩＥＥＥ８０２．２１で定義されている情報サービスを利用して、ＭＮ１０１がＬＭＡ１１０のアドレスを把握する方法によれば、モバイルノードは、ルーティングプリファレンスの設定場所（ＬＭＡ１１０）を把握するためにローカルモビリティドメインに問い合わせを行う必要があり、その結果、システムがより複雑になってしまうという問題がある。

また、特許文献３に開示されている技術は、モバイル機器自身が、ネットワークに対してルーティングパスの設定を開始させるためのパス設定メッセージを送信するが、その目的は本発明と大きく異なっている。特許文献３に開示されている技術では、モバイル機器が、例えば基地局間のハンドオフを行った場合に、そのハンドオフによる接続先でパケットを送受信するためのルーティングパスをネットワーク内で設定させるためにパス設定メッセージを送信する。すなわち、特許文献３に開示されている技術では、ハンドオフ直後にモバイル機器がパケットの送受信（特に、モバイル機器あてのパケットの受信）を行えない状態を解消するために、モバイル機器自身がパス設定メッセージを送信することで接続通知を行い、このパス設定メッセージをトリガとするメッセージがネットワーク内の各ルータで転送されることで、モバイル機器のルーティングパスが登録される。したがって、特許文献３に開示されている技術は、あくまでもモバイル機器のルーティングパスの登録を目的としており、あるフローに関して、モバイル機器がパケット受信可能な複数のルーティングパスの中から、モバイル機器が所望するルーティングパスを通るようにフィルタルールの設定が行われるものではない。また、特許文献３に開示されている技術では、ネットワーク内の各ルータ（すべてのルータ）において、パス設定メッセージをトリガとするメッセージに基づくモバイル機器のルーティングエントリの更新機能が導入される必要がある。

本発明は、移動端末がホームネットワークドメインとは異なるネットワークベースのモビリティ管理ドメインに接続している場合に、移動端末のプリファレンスに基づいたルーティングを効率良く実現することを目的とする。

上記の目的を達成するため、本発明の通信システムは、ネットワークベースのモビリティ管理プロトコルが実行されているネットワークを有する通信システムであって、
前記ネットワークに接続されている移動端末の通信のプリファレンス情報が、前記ネットワーク内で前記移動端末の通信に係るフローフィルタリングを行っているフィルタリングエージェントに通知されるように構成されている。
この構成により、移動端末がホームネットワークドメインではないネットワークベースのモビリティ管理ドメインに接続している場合に、移動端末のプリファレンスに基づいたルーティングを効率良く実現することが可能となる。

また、上記の目的を達成するため、本発明の移動端末は、ネットワークベースのモビリティ管理プロトコルが実行されているネットワークに接続する移動端末であって、
１つ又は複数のインタフェースと、
前記インタフェースが前記ネットワークに接続されている状態で、前記インタフェースによる通信のプリファレンス情報に基づくフローフィルタリングが行われるように、前記プリファレンス情報を前記ネットワークに通知するプリファレンス通知手段とを、
有する。
この構成により、移動端末がホームネットワークドメインではないネットワークベースのモビリティ管理ドメインに接続している場合に、移動端末のプリファレンスに基づいたルーティングを効率良く実現することが可能となる。

また、上記の目的を達成するため、本発明のネットワークノードは、ネットワークベースのモビリティ管理プロトコルが実行されているネットワーク内に存在するネットワークノードであって、
前記ネットワークに接続されている移動端末のフローにフィルタルールが設定されていないことを把握するフィルタ未設定把握手段と、
前記フィルタ未設定把握手段で把握された前記フローに対してプリファレンス情報を設定するプリファレンス設定手段とを、
有する。
この構成により、移動端末がホームネットワークドメインではないネットワークベースのモビリティ管理ドメインに接続している場合に、移動端末のプリファレンスに基づいたルーティングを効率良く実現することが可能となる。

本発明は上記の構成を有しており、移動端末がホームネットワークドメインとは異なるネットワークベースのモビリティ管理ドメインに接続している場合に、移動端末のプリファレンスに基づいたルーティングを効率良く実現するという効果を奏する。

従来の技術及び本発明の実施の形態において参照されるネットワークベースのモビリティ管理システムの構成の一例を示す図 本発明の実施の形態におけるモバイルノードの構成の一例を示す図 本発明の実施の形態において、アプリケーションに関連するルートポリシによる処理の一例を示すフローチャート 本発明の実施の形態において、ローカルモビリティドメイン内にルーティングプリファレンスを設定するために使用されるフィルタメッセージのフォーマットの一例を示す図 本発明の実施の形態において、ＭＡＧによって実行されるリバースパケットフロー仮定に関するフローチャート 本発明の実施の形態において、ＭＮに代わってルーティングプリファレンスの設定が可能なＭＡＧ又はフィルタリングエージェントに実装されている機能を示すブロック図 本発明の実施の形態において、パケット経路として選択されるルーティングパスが意図的に変更されたことをモバイルノードへ通知するために使用されるデータパケットのフォーマットの一例を示す図 本発明の実施の形態において、受信したデータパケットの処理の際に、ネットワーク側でルーティングパスが意図的に変更されたかどうかをモバイルノードが判断するための処理の一例を示すフローチャート

以下、図面を参照しながら、本発明の実施の形態について説明する。なお、以下の説明では、本発明を説明するために、特定の番号や時間、構造、プロトコル名、及びその他のパラメータなどが詳細に説明される場合があるが、本明細書で用いられている特定の条件は、本発明を説明するために用いられているにすぎず、本発明を限定するものではない。

本明細書では、複数のインタフェースを有するモバイルノードが、ローカルモビリティドメイン内にルーティングプリファレンス（routing preference）を設定する方法が開示される。この方法によれば、ローカルモビリティドメイン内のルーティングエンティティが、ローカルモビリティドメイン内における特定のトラフィックフロー（そのモバイルノードに関連したトラフィックフロー）の発送方法（ルーティング方法）を把握できるようになる。なお、ルーティングプリファレンス（本明細書では、プリファレンス又はプリファレンス情報と記載することもある）は、モバイルノードが特定のフローに関するパケットに対して、どのインタフェースで受信するか（あるいは、どのアドレス又はどのプレフィックスを有するアドレスで受信するか）を指定する情報である。本発明では、モバイルノードが、ローカルモビリティドメイン内のルーティングエンティティ（例えば、ローカルモビリティアンカ）に対してルーティングプリファレンスを通知することによって、ローカルモビリティドメイン内のルーティングエンティティは、モバイルノードへパケットを転送するための複数のルーティングエントリの中から、ルーティングプリファレンスで指定されたパケット受信を実現するためのルーティングエントリを選択して（フローに関するフィルタルールの設定）、パケットの転送を行う。ローカルモビリティドメイン内のルーティングエンティティにフィルタルールが設定されていない場合には、ローカルモビリティドメイン内のルーティングエンティティは、モバイルノードから通知されたルーティングプリファレンスに基づいて、新たなフィルタルールの設定を行うことが可能である。また、ローカルモビリティドメイン内のルーティングエンティティは、モバイルノードから通知されたルーティングプリファレンスに基づいて、現在保持されているフィルタルールを新たなフィルタルールに変更することが可能である。なお、フィルタルールはルーティングエンティティにおいては主にルートポリシとして扱われる。

また、モバイルノードのすべてのインタフェースがホームネットワークドメインとは異なる１つ若しくは複数のローカルモビリティドメインに接続されている場合には、モバイルノードは、そのローカルモビリティドメインにおけるルーティングプリファレンスを指示することによって、ホームエージェントにルーティングプリファレンスを設定する必要がなくなるという利点がある。この場合、ホームエージェントはモバイルノードあてのパケットをローカルモビリティドメインのフィルタリングエージェントに転送するだけで、フィルタリングノードにおいて、モバイルノードによって定義されたプリファレンスを用いたパケットの発送が行われる。

図２には、本発明の実施の形態におけるモバイルノードの構成の一例が図示されている。モバイルノード（ＭＮ）２００は、１つ又は複数のネットワークインタフェース２０１−１〜２０１−ｎ、１つ又は複数のアプリケーション２０２、データベースモジュール２０３、１つ又は複数のルートポリシ２０４−１〜２０４−ｍ、加入者識別情報２０５、ポリシエンジン２０６を有している。

なお、ネットワークインタフェース２０１−１〜２０１−ｎは、ｎ個（ｎは１以上の整数）のネットワークインタフェースが存在することを表しているが、以下では、ネットワークインタフェース２０１−１〜２０１−ｎのうちの任意のネットワークインタフェースを表す際にネットワークインタフェース２０１という表記を用いることがある。

また、ルートポリシ２０４−１〜２０４−ｍは、ｍ個（ｍは１以上の整数）のルートポリシが存在することを表しているが、以下では、ルートポリシ２０４−１〜２０４−ｍのうちの任意のルートポリシを表す際にルートポリシ２０４という表記を用いることがある。

ネットワークインタフェース２０１は、モバイルノード２００が任意の通信媒体を通じて別のノードと通信を行うために必要なハードウェア及びソフトウェアを包含する機能ブロックである。関連する技術分野で周知の用語を使用すると、ネットワークインタフェース１１は、レイヤ１（物理層）及びレイヤ２（データリンク層）の通信コンポーネント、ファームウェア、ドライバ、通信プロトコルなどを表している。なお、図１では、複数のネットワークインタフェース２０１が図示されているが、モバイルノード２００はネットワークインタフェース２０１を１つのみ有していてもよい。

また、ネットワークインタフェース２０１とポリシエンジン２０６との間では、シグナル／データパス２０７−１〜２０７−ｎを通じて、トリガ／パケットの伝送に係る情報のやり取りが可能である。

また、アプリケーション２０２は、通信プロトコルスタックのネットワーク層の上位に位置するすべてのプロトコル及びプログラムを包含する機能ブロックである。例えば、アプリケーション２０２には、トランスポート制御プロトコル（ＴＣＰ：Transmission Control Protocol）、ストリーム制御トランスポートプロトコル（ＳＣＴＰ：Stream Control Transport Protocol）、ユーザデータグラムプロトコル（ＵＤＰ：User Datagram Protocol）などの他のノードとの通信に必要なトランスポート層プロトコル又はセッション層プロトコルやプログラム及びソフトウェアが含まれる。

なお、シグナル／データパス２０８を通じて、ポリシエンジン２０６からアプリケーション２０２の適切なプログラムに対してパケット転送が可能である。また同様に、シグナル／データパス２０８を通じて、アプリケーション２０２からポリシエンジン２０６へのトリガの送信も可能である。なお、例えばアプリケーション２０２は、こうしたトリガを用いて、特定のプログラムに関連するルートポリシ２０４をポリシエンジン２０６に通知することが望ましい。

また、データベースモジュール２０３は、モバイルノード２００が必要とする情報を格納する機能を有する。なお、好適な構成では、データベースモジュール２０３は、通常、１つ又は複数のルートポリシ２０４を有している。ルートポリシ２０４は、様々なアプリケーション２０２に関連するあらゆるルーティングプリファレンスを格納している。なお、シグナル／データパス２０９を通じて、アプリケーション２０２とルートポリシ２０４との間では、適切なルートポリシの読み出し／アップデートが可能である。また、シグナル／データパス２１０を通じて、ポリシエンジン２０６は各アプリケーション２０２に関連する適切なルートポリシを読み出すことが可能である。

また、好適な構成では、データベースモジュール２０３は、加入者識別情報２０５を更に有している。加入者識別情報２０５には、モバイルノード２００のユーザに関連するあらゆる情報が含まれている。なお、この加入者識別情報の一例としては、セルラのオペレータが加入者の認証を行うために使用する国際モバイル加入者識別子（ＩＭＳＩ：International Mobile Subscriber Identity）が挙げられる。また、ローカルモビリティドメインに対する認証を実行する際、ポリシエンジン２０６は、シグナル／データパス２１０を通じて加入者識別情報２０５を取得することが可能である。

また、ポリシエンジン２０６は、アプリケーション２０２の各プログラムに関して、パケットの発送経路の決定処理を行う。ポリシエンジン２０６は、アプリケーション２０２から受信したトリガ（例えば、特定のプログラムに関連するルートポリシを示す情報を含むトリガ）に基づいてデータベースモジュール２０３を検索し、適切なルートポリシ２０４を読み出す。これによって、ポリシエンジン２０６は、モバイルノード２００によるローカルモビリティドメインのルーティングプリファレンスの設定を補助することが可能となる。

また、ポリシエンジン２０６は、現在受信しているパケットのフローに関して、適切なルーティングパスを経由してパケットを受信しているか否かを判断する機能を有している。例えば、ポリシエンジン２０６は、あるフローに対する適切なルートポリシ２０４を把握するとともに、シグナル／データパス２０７−１〜２０７−ｎを通じて、現在受信しているパケットのフローが、どのネットワークインタフェース２０１、あるいはどのアドレス（又はプレフィックス）を用いているかを把握する。そして、現在のパケット受信が、あるフローに対する適切なルートポリシ２０４と一致しない場合（すなわち、適切なルーとポリシ２０４が実現されていない場合）には、ポリシエンジン２０６は、現在受信しているパケットのフローが適切なルーティングパスを経由していないと判断する。次に、適切なルートポリシ２０４に含まれるルーティングプリファレンスをローカルモビリティドメインに通知することで、ローカルモビリティドメイン内において、所望のルーティングパスが実現されるように設定を行う。

なお、各パケットのフローは、不図示のフロー管理部によって管理されている。フロー管理部は、各パケットのフローをネットワークインタフェース２０１、あるいはモバイルノード２００に割り当てられているアドレス（又はプレフィックス）に関連付けて管理している。すなわち、フロー管理部は、どのフローが、どのネットワークインタフェース２０１、あるいはどのアドレス（又はプレフィックス）を利用しているかを管理している。

また、図３には、本発明の実施の形態において、アプリケーションに関連するルートポリシによる処理の一例を示すフローチャートが図示されている。

図３において、ポリシエンジン２０６がアプリケーション２０２からトリガを受信すると（ステップＳ３０）、処理が開始される。なお、トリガには、例えばルートポリシ２０４の識別情報やアプリケーション２０２のセッション識別情報などが含まれることが好ましいが、これらに限定されるものではない。ステップＳ３０におけるトリガの受信後、まず、データベースモジュール２０３から適切なルートポリシ（関連ルートポリシ）２０４の検索が行われる。

ルートポリシ２０４が取得されると、ポリシエンジン２０６は、このルートポリシ２０４によって規定される要件がいずれかのネットワークインタフェース（Ｉ／Ｆ）２０１において満たされているか否かがチェックされる（ステップＳ３２）。なお、ルートポリシ２０４によって規定される要件は任意であるが、例えば、パケット伝送速度を最大、遅延時間を最小、ジッタを最小、エラーレートを最小、パケットロス率を最小などの通信効率を向上させるための各種要件が規定されることが望ましい。ルートポリシ２０４によって規定される要件を満たすネットワークインタフェース２０１が存在する場合には、ポリシエンジン２０６は、そのネットワークインタフェース２０１を選択し、選択されたネットワークインタフェース（Ｉ／Ｆ）２０１に、フロー（アプリケーション２０２のセッション識別情報）を関連付ける（ステップＳ３３）。

そして、ステップＳ３３における関連付けが完了すると、ポリシエンジン２０６は、その選択されたネットワークインタフェース２０１を使用して、ローカルモビリティドメイン内におけるそのセッションに関するルーティングプリファレンスを設定する（ステップＳ３４）。その結果、セッション識別情報が一致するパケットは、選択されたネットワークインタフェース２０１を通じて送受信されるようになる。

一方、ルートポリシ２０４によって規定される要件を満たすネットワークインタフェース２０１が存在しない場合には、ポリシエンジン２０６は、アプリケーション２０２に対して、このフロー要件は現在サポート不可能である旨を応答する（ステップＳ３５）。なお、このステップＳ３５における動作が行われた場合には、アプリケーション２０２は、その特定のプログラムのフロー要件に関して再交渉を行うことも可能である。

以下、上述の図３に係る動作に関して、具体例を用いて説明する。アプリケーション２０２はＣＮとの間で、遅延による影響を受けやすい（delay sensitive）ＴＣＰセッションを有しているとする。この場合、アプリケーション２０２は、ＴＣＰフローに関するルーティングプリファレンスが反映するようにルートポリシ２０４のアップデートを行う。ルートポリシ２０４がアップデートされると、アプリケーション２０２は、ＴＣＰフローがルートポリシ２０４を用いて発送される必要がある旨を指定するトリガをポリシエンジン２０６に送信する。

このトリガに基づいて、ポリシエンジン２０６はルートポリシ２０４を検索し、その結果、アプリケーション２０２が最小遅延経路を経由したＴＣＰフローの伝送を望んでいる旨を把握する。そして、ポリシエンジン２０６は利用可能なネットワークインタフェース２０１を調べて、ＴＣＰフローの伝送条件（最小遅延）をサポートするための適切な候補を探す。

例えば、図１に図示されている構成において、ＭＮ１０１のセルラネットワークインタフェース（セルラネットワークに接続するインタフェース２０１）がローカルモビリティドメインに接続されている場合には、ポリシエンジン２０６は、このセルラネットワークインタフェースが最小遅延の要件を満たしていると判断する。その結果、ポリシエンジン２０６は、セルラネットワークインタフェース２０１にＴＣＰフローを転送して、ＣＮ１４０への発送を行う。また、さらに、ポリシエンジン２０６は、本発明で規定される方法を使用して、ローカルモビリティドメイン内におけるルーティングプリファレンスを設定する。

上述のように、本発明の目的を実現させるためには、ＭＮがローカルモビリティドメイン内におけるルーティングプリファレンスを設定することが可能な方法が規定される必要がある。この方法によって、ローカルモビリティドメイン内で伝送されるモバイルノードあてのパケットは、所望のパス（ルーティングプリファレンスに従ったパス）を経由してＭＮに到達するようになる。したがって、ＭＮは、ローカルモビリティドメイン内の何らかのエンティティに対して、ルーティングプリファレンスを通知する必要がある。このようなエンティティは、フィルタリングエージェントと呼ばれる。フィルタリングエージェントは、１つ又は複数のローカルモビリティアンカや１つ又は複数のポリシサーバなどによって実現されてもよいが、これらに限定されるものではない。

なお、ＭＮ１０は、必ずしもすべてのＴＣＰフローに対してルーティングプリファレンスを設定する必要はなく、ローカルモビリティドメイン内の何らかのエンティティに対して、必ずしもすべてのＴＣＰフローに関するルーティングプリファレンスを通知する必要はない。この場合、ＭＮは、例えばリバースパケットフロー仮定などを用いて上り方向（ＭＮからの送信方向）の経路と下り方向（ＭＮへの受信方向）の経路とが同一になるように設定することによって、特定のフローに係るパケットを送信するインタフェースと、同一のフローに係るパケットを受信するインタフェースとが同一となるように設定することが可能である。

図４には、本発明の実施の形態において、ローカルモビリティドメイン内にルーティングプリファレンスを設定するために使用されるフィルタメッセージ４０のフォーマットの一例が図示されている。

図４において、フィルタメッセージ４０は、パケットヘッダ４０１、プリファレンスオプション（preference option）４０２、モバイルノード識別子（ＭＮ−ＩＤ）４０３を有している。

パケットヘッダ４０１は、例えば、メッセージの送信者及び受信者を示すＩＰｖ４又はＩＰｖ６アドレス、このメッセージのタイプを示すタイプフィールド、メッセージの長さを示す長さフィールドなどを有しているが、これらに限定されるものではない。

例えば、フィルタメッセージ４０がＭＮからＭＡＧ又はフィルタリングエージェントに送信される場合、パケットヘッダ４０１内のアドレス（送信元（source）アドレス）には、ローカルモビリティドメインに接続されているインタフェースで構成されたＭＮのアドレスが反映される。また、例えば、フィルタメッセージ４０がＭＡＧからフィルタリングエージェントに送信される場合、パケットヘッダ４０１内のアドレス（送信元アドレス）には、ＭＡＧのアドレスが反映される。

また、プリファレンスオプション４０２には、ローカルモビリティドメインのルーティングプリファレンスが記載される。例えば、プリファレンスオプション４０２には、フィルタ識別子（ＦＩＤ）４０４及びフィルタルール４０５が含まれる。

ＦＩＤ４０４は、フィルタリングエージェントに設定される様々なフィルタルールを識別するための識別子情報である。このＦＩＤ４０４により、フィルタリングエージェントは、どのフィルタルールが、ローカルモビリティドメイン内で伝送されるどのパケットに適用されるかを把握することが可能となる。

また、フィルタルール４０５は、このルールに関連するパケットに関してフィルタリングエージェントが遵守しなければならないルールを指定するものである。例えば、ＣＮ１４０のアドレスを送信元アドレスとするパケットは、フィルタメッセージ４０のパケットヘッダ４０１に記載されている送信元アドレス（フィルタメッセージ４０の送信者）に転送されるように指示することによって、単純なフィルタルールが設定可能である。

また、フィルタメッセージ４０がＭＮからフィルタリングエージェントに送信される場合には、ＭＡＧの識別子（ＭＡＧ−ＩＤ）４０６がフィルタメッセージ４０に更に含まれていてもよい。ＭＡＧ−ＩＤ４０６によって、ＭＮは、ＬＭＡ又はポリシサーバが特定のフローをどのＭＡＧに発送すべきかを指定することが可能となる。この場合、ＣＮ１４０のアドレスを送信元アドレスとするパケットはフィルタメッセージ４０のＭＡＧ−ＩＤ４０６に指定されているＭＡＧに転送されるように、フィルタルールが設定される。

また、ＭＮ−ＩＤ４０３によって、フィルタリングエージェントは、フィルタメッセージ４０のフィルタルールが適用されるのはどのＭＮかを把握することが可能となり、ＭＮに関連する適切なフィルタルールの格納又はアップデートが可能となる。なお、ＭＮ−ＩＤ４０３には、例えば加入者識別情報２０５が含まれてもよいが、これに限定されるものではない。

ここで、図１の構成に従って、ＭＮ１０１は２つのインタフェース（セルラネットワークインタフェース及びＷＬＡＮインタフェース）を有しているとする。このとき、セルラネットワークインタフェースは、ＭＡＧ１１１に接続されており、ＣｏＡとしてCoA.Celluarを使用して通信を行うとする。一方、ＷＬＡＮインタフェースは、ＭＡＧ１１２に接続されており、ＣｏＡとしてCoA.WLANを使用して通信を行うとする。

ＭＮ１０１は、ＣＮ１４０との間で進行中のデータセッションを有しており、ローカルモビリティドメイン１１にプリファレンスを設定して、ＣＮ１４０からCoA.WLAN経由でパケットを受信することを決定する。その結果、ＭＮ１０１は、ＣＮ１４０のアドレスを送信元アドレスとするパケットがCoA.WLANに発送されるように指定するフィルタルールを生成する。なお、このフィルタルールは、ＦＩＤ−ＣＮと表記されるＦＩＤで識別されるとする。

なお、ＭＮが、ローカルモビリティドメインにおけるルーティングプリファレンスをＭＡＧに伝えてもよい。ＭＡＧは、モバイルノードのルーティングプリファレンスをローカルモビリティドメイン内のフィルタリングエージェントに転送する。また、ＭＡＧは、ＭＮのルーティングプリファレンスをフィルタリングエージェントに転送する前に、そのルーティングプリファレンスを格納（キャッシュ）してもよい。このように、ＭＡＧがフィルタリングエージェントにルーティングプリファレンスを転送することによって、ＭＮは、ローカルモビリティドメイン内のフィルタリングエージェントにルーティングプリファレンスを設定するために、フィルタリングエージェントを発見するための探索メカニズム（例えば、ＩＥＥＥ８０２．２１の技術）を用いる必要がないという利点がある。これにより、モバイルノードとローカルモビリティドメインとの間におけるシグナリングメッセージ数を減らすことが可能となる。

以下、ＭＡＧがフィルタリングエージェントにルーティングプリファレンスを転送する方法に関して、具体例を用いて説明する。なお、以下では、図１の構成を参照しながら、この具体例の説明を行う。

図１において、ＭＮ１０１は、フィルタルール（ＦＩＤ−ＣＮ）を伝送するフィルタメッセージ４０をＭＡＧ１１２に送信する。ＭＡＧ１１２はＭＮ１０１からフィルタメッセージ４０を受信すると、ＭＮ１０１がローカルモビリティドメイン１１内におけるルーティングプリファレンスの設定を望んでいることを把握する。その結果、ＭＡＧ１１２は、ローカルモビリティドメイン１１内のフィルタリングエージェント（ＬＭＡ１１０又は何らかのポリシサーバ）に対して、ＭＮ１０１のルーティングプリファレンスを通知する。また、ＭＡＧ１１２がフィルタメッセージ４０を使用して、ＭＮ１０１のルーティング設定を伝送してもよい。さらに、ＭＡＧ１１２は、非特許文献４や非特許文献５に記載の方法を使用して、ＭＮ１０１のルーティングプリファレンスを伝送してもよい。

また、ＭＮがローカルモビリティドメイン内にルーティングプリファレンスを設定する動作を、ＭＡＧが補助してもよい。この場合、ＭＡＧは、例えばＭＮとあて先ノードとの間の通信セッションにおいて双方向のパスが同一になると仮定して、逆方向のパケットフローを設定する。したがって、ＭＡＧは、上述のような仮定（リバースパケットフロー仮定）に基づいて、ＭＮに代わってルーティングプリファレンスをフィルタリングエージェントに設定する。このようなＭＡＧがＭＮに代わってルーティングプリファレンスを設定する方法によれば、レガシのモバイルノードもプリファレンスによって定められるルーティングを享受することができるようになるという利点がある。なお、リバースパケットフロー仮定を用いた場合には、双方向のパスが同一になるようにルーティングプリファレンスが設定されるが、その他の任意の条件に基づいてルーティングプリファレンスが設定されてもよい。

また、図５には、本発明の実施の形態において、ＭＡＧによって実行されるリバースパケットフロー仮定に関するフローチャートが図示されている。図５において、ＭＡＧがパケットを受信すると（ステップＳ５０）、処理が開始される。

まず、ＭＡＧは、パケットに関連するルートポリシが存在しているか否かを検証する（ステップＳ５１）。なお、フロー識別子（ＦＩＤ）４０４によって、ＭＡＧは、受信パケットが、既にルートポリシを有するパケットフローの一部か否かを検証することが可能である。受信パケットに関連するルートポリシが存在している場合には、ＭＡＧは、所定のあて先にパケットを転送して（ステップＳ５３）、処理を終了する。

一方、受信パケットに関連するルートポリシが存在していない場合には、ＭＡＧは、このパケットフローに関するルートポリシをフィルタリングエージェントにセットする（ステップＳ５２）。これにより、フィルタリングエージェントは、そのフローのパケットをルートポリシに関連付けることが可能となる。ルートポリシが作成されると、ＭＡＧは、所定のあて先にフローを転送する（ステップＳ５３）。

以下、ＭＡＧによって実行されるリバースパケットフロー仮定の方法に関して、具体例を用いて説明する。なお、以下では、図１の構成を参照しながら、この具体例の説明を行う。

ＭＮ１０１は、ＭＡＧ１１２を経由してＣＮ１４０をあて先とするパケットを送信する。ＭＡＧ１１２は、パケットを受信すると、このパケットフローに関するルートポリシが存在しているか否かを判断するためにキャッシュをチェックする。なお、ここでは、ＭＡＧ１１２は、このパケットフローに関連するルートポリシを発見できないとする。したがって、ＭＡＧ１１２は、ＭＮ１０１に代わって、ＣＮ１４０からのパケットをＭＡＧ１１２経由でＭＮ１０１に発送するように指示するルーティングプリファレンスをＬＭＡ１１０にセットする。

さらに、フィルタリングエージェントが、ＭＮによるルーティングプリファレンスの設定を補助する動作を行ってもよい。この場合、関連するルートポリシが存在しないパケットフローに関して、フィルタリングエージェントが、例えば図５に図示されている方法を実行する。

さらに、パケットフローに関連するルートポリシが存在するか否かをＭＡＧが判断する動作としては、例えば、ＭＡＧがフィルタリングエージェント（ＬＭＡ１１０又は何らかのポリシサーバ）に対して、そのパケットフローのルーティングプリファレンスが存在しているか否かの問い合わせを行ってもよく、あるいは、また、フィルタリングエージェントに転送する前にキャッシュしたＭＮのルーティングプリファレンスを格納してもよいが、これらに限定されるものではない。さらに、ＭＮは、ルーティングプリファレンスの設定に特別なプリファレンスを必要としない場合に、デフォルトのプリファレンス設定としてリバースパケットフロー仮定の方法で設定を行ってもよい。

また、図６には、本発明の実施の形態において、ＭＮに代わってルーティングプリファレンスの設定が可能なＭＡＧ又はフィルタリングエージェントに実装されている機能がブロック図によって図示されている。図６に図示されているプリファレンス代理設定ノード６００は、ＭＡＧ又はフィルタリングエージェントであり、ＭＮによるルーティングプリファレンスの設定を補助する動作（図５に図示されている動作）を行うことが可能である。

図６に図示されているプリファレンス代理設定ノード６００は、フィルタ未設定把握部６０１、プリファレンス設定部６０２を有している。フィルタ未設定把握部６０１は、ＭＮに関連するパケットを受信すると、その受信パケットに関連するルートポリシ（フィルタルール）が存在しているか否かを確認する機能（図５のステップＳ５１の処理を行う機能）を有している。また、ルートポリシ設定部６０２は、フィルタ未設定把握部６０１でその受信パケットに関連するフローのルートポリシが存在しないこと（その受信パケットに関連するフローのフィルタルールが設定されていないこと）が確認された場合、そのフローに関連して、プリファレンス情報に基づくルートポリシ（フィルタルール）を設定する機能（図５のステップＳ５２の処理を行う機能）を有している。なお、ルートポリシ設定部６０２によるルートポリシの設定は、上述のように任意の方法で設定可能であり、例えばリバースパケットフロー仮定に基づいて行われてもよく、また、他のネットワークノード（フィルタリングノードなど）に問い合わせを行った結果に基づいて行われてもよい。

また、プリファレンス代理設定ノード６００がフィルタリングエージェント以外のネットワークノードである場合（例えばＭＡＧの場合）には、ルートポリシ設定部６０２で設定されたプリファレンス情報をフィルタリングエージェントに通知するプリファレンス通知部６０３を有している。

また、ＭＮが、ローカルモビリティドメインにおけるルーティングプリファレンスを直接フィルタリングエージェントに通知してもよい。ＭＮは、何らかの探索メカニズム（例えばＩＥＥＥ８０２．２１に係る技術）を用いて、ローカルモビリティドメイン内のフィルタリングエージェントを探索する。フィルタリングエージェントが発見されると、モバイルノードは、フィルタメッセージ４０を使用して、そのルーティングプリファレンスをフィルタリングエージェントに伝送する。

本発明では、ローカルモビリティドメイン内にルーティングプリファレンスが設定されることで、ＭＮは、確実に所望のパス経由でパケットを受信することができるようになる。以下、具体例を用いて、ルーティングプリファレンスがローカルモビリティドメイン内のパケットのパスにどのような影響を与えるかについて説明する。

ＭＮ１０１は、ＣＮ１４０からのパケットがＭＡＧ１１２経由で発送されるべきである旨を示すフィルタルール（ＦＩＤ−ＣＮ）をＬＭＡ１１０に設定したとする。ＬＭＡ１１０は、グローバル通信ドメイン１３経由でＣＮ１４０からのパケットを受信すると、キャッシュをチェックして、ＭＮ１０１がこのパケットフローに関するルーティング設定をセットしているか否かを検証する。ここで、ＬＭＡ１１０は、このパケットフローに一致するフィルタルール（ＦＩＤ−ＣＮ）を特定した場合には、このフィルタルールを遵守してＭＡＧ１１２経由でＭＮ１０１にパケットを発送する。

一方、ＬＭＡ１１０が、このパケットフローに一致するフィルタルールを発見できない場合には、図５に図示されている方法を使用して、ＭＮ１０１に代わってルーティング設定を作成することが可能である。この場合、ＬＭＡ１１０は、パケットの送信元アドレス及びあて先アドレスを用いて、このフィルタルールを作成する。したがって、ＬＭＡ１１０は、ＣＮ１４０（パケットの送信元アドレス）からのパケットはＭＡＧ１１２（パケットのあて先アドレスに関連するＭＡＧアドレス）経由でＭＮ１０１に発送されるべきである旨を指定するフィルタルールを作成する。

また、本発明は、ホームネットワークドメイン１０及びローカルモビリティドメイン１１の両方が同一の管理ドメイン（例えば両方のドメインが同一オペレータによって管理されている）に属しているシステムにおいても適用可能である。このシステムでは、ＭＮ１０１は、非特許文献４や非特許文献５に記載されているようなＨＡにルーティングプリファレンスを伝送する方法を用いる代わりに、本発明に係る方法を用いてＬＭＡ１１０にルーティングプリファレンスを設定することが可能である。本発明を使用することで、ＨＡ１０２とＬＭＡ１１０との間のシグナリングを低減させることが可能となる。これは、ＨＡ１０２が、ＭＮ１０１からＬＭＡ１１０へのルーティングプリファレンス（ローカルモビリティドメイン内でのルーティングに関するプリファレンス）の転送を補助する必要がないことによる。また、ＨＡ１２０は、ＭＮ１０１のルーティングプリファレンスをＬＭＡ１１０に転送する前に、ＭＮ１０１のルーティングプリファレンスを適切なＭＡＧに関連付けてもよい。また、ＨＡ１２０とＬＭＡ１１０が協同して動作可能な環境の場合には、ルーティングプリファレンスに基づくフィルタルールの設定を行う機能をＨＡ１２０が担い、実際にパケットのフィルタリングを行う機能をＬＭＡ１１０が担うように機能の分担が行われてもよい。

また、本発明は、ホームネットワークドメイン１０及びローカルモビリティドメイン１１の両方が同一の管理ドメインに属しているシステムにおいて、ＨＡ１０２及びＬＭＡ１１０が１つのエンティティによって実現されて、各ノードのルーティングプリファレンスが設定されてもよい。この場合においても、ＭＮ１０１は、本発明に係る方法を用いて、このエンティティにルーティングプリファレンスを設定することが可能である。

また、ホームネットワークドメイン１０及びローカルモビリティドメイン１１の両方が異なる管理ドメイン（例えば両方のドメインが異なるオペレータによって管理されている）に属しているシステムであっても、双方のドメインで通信を行って、一方のドメインで保持されているＭＮのフィルタルールを、他方のドメインのフィルタリングエージェントにおいて作動させるようにしてもよい。

また、ＭＮ１０１が複数のインタフェースを同時に接続する場合に、ＬＭＡ１１０が、接続を行っているＭＮ１０１のインタフェースのそれぞれに対してユニークなプレフィックス（各インタフェースに対して固有のプレフィックス）を割り当てることも可能であり、このようなシステムに対しても本発明を適用することが可能である。なお、以下では、このようにＭＮ１０１の複数のインタフェースのそれぞれに対してユニークなプレフィックスを割り当てるシステムを複数プレフィックスモデルと呼ぶことにする。

例えば、ＭＮ１０１が、ローカルモビリティドメイン１１のＭＡＧ１１１及びＭＡＧ１１２へ同時に接続した場合、複数プレフィックスモデルでは、ＬＭＡ１１０は、ＭＡＧ１１１に対してプレフィックス（Ｐ１）をＭＮ１０１へ通知するよう指示し、同様に、ＭＡＧ１１２に対してプレフィックス（Ｐ２）（プレフィックス（Ｐ１）とは異なるプレフィックス）をＭＮ１０１へ通知するよう指示することが可能である。これにより、ＭＮ１０１は、ローカルモビリティドメイン１１へ接続された状態で、各インタフェースにおいて異なるプレフィックスを検出する。

このような複数プレフィックスモデルのシステムにおいて、ＬＭＡ１１０は、ＭＮ１０１へのプレフィックスの通知を行うエンティティを変更してもよい（すなわち、ＭＡＧと、ＭＡＧが通知するプレフィックスとの対応を変更してもよい）。例えば、上述のようにＭＡＧ１１１がプレフィックス（Ｐ１）を通知し、ＭＡＧ１１２がプレフィックス（Ｐ２）を通知する状態において、ＬＭＡ１１０は、ＭＡＧ１１１に対してプレフィックス（Ｐ２）を通知するよう指示し、ＭＡＧ１１２に対してプレフィックス（Ｐ１）を通知するよう指示してもよい。こうしたプレフィックス通知の変更は、任意の条件に基づいて行われるものであり、例えば、ＬＭＡ１１０又はローカルモビリティドメイン１１内のその他のネットワークエンティティ制御装置が、ローカルモビリティドメイン１１のネットワーク管理を行う必要がある場合に行われる。

このような複数プレフィックスモデルのシステムに本発明を適用し、ＭＮ１０１が、本発明に係る方法を利用して所望のルーティングプリファレンスをネットワーク側へ通知することで、ＭＮ１０１のインタフェースで使用するプレフィックスをＭＮ１０１自身が指定することが可能となる。ＬＭＡ１１０は、ＭＮ１０１が所望するルーティングプリファレンスに基づいてプレフィックス通知の変更を行い、その結果、ＭＮ１０１のルーティングプリファレンスに基づくフィルタルールに従って、ＭＮ１０１へのパケット発送が行われるようになる。

本発明を適用した場合、ＭＮ１０１は、どのインタフェースでどのプレフィックスを使用するかを示す情報を所望のルーティングプリファレンスとしてネットワーク側へ通知することが可能である。例えば、上述のようにＭＡＧ１１１がプレフィックス（Ｐ１）を通知し、ＭＡＧ１１２がプレフィックス（Ｐ２）を通知する状態において、ＭＮ１０１は、ＭＡＧ１１１に接続されているインタフェースでプレフィックス（Ｐ２）を使用し、ＭＡＧ１１２に接続されているインタフェースでプレフィックス（Ｐ１）を使用することを所望するルーティングプリファレンスを、フィルタメッセージ４０を使用してネットワーク側へ通知することが可能である。ＬＭＡ１１０は、ＭＮ１０１によって通知されたルーティングプリファレンスに従って、ＭＡＧ１１１に対してプレフィックス（Ｐ２）をＭＮ１０１へ通知するよう指示するとともに、ＭＡＧ１１２に対してプレフィックス（Ｐ１）をＭＮ１０１へ通知するよう指示する。その結果、ＭＮ１０１は、ＭＡＧ１１１に接続されているインタフェースでプレフィックス（Ｐ２）を使用し、ＭＡＧ１１２に接続されているインタフェースでプレフィックス（Ｐ１）を使用することが可能となる。なお、プレフィックスの対応付けの変更のほかに、特定の条件のパケットのフローのみを変更するためにプリファレンス情報を用いる方法を複数プレフィックスモデルにおいて適用することも可能である。

また、複数プレフィックスモデルにおいて、ＬＭＡ１１０からＭＮ１０１へ割り当てられた複数のプレフィックスの一部又はすべてを、より上位のプレフィックス（よりプレフィックス長の短いプレフィックス）へ関連付けることも可能である。すなわち、ＭＮ１０１へ割り当てられたプレフィックスのうち、共通のビット配列を有する複数のプレフィックスは、この共通のビット配列（上位プレフィックス）によって表されるようにしてもよい。また、ＭＮ１０１へのプレフィックスの割り当てが効率良く行われた場合には、ＭＮ１０１へ割り当てられたすべてのプレフィックスを単一の上位プレフィックスで表すことも可能となり、この場合には単一プレフィックスモデルへ還元可能となる。このような場合には、ＬＭＡ１１０は、上位プレフィックスを使用して、ローカルモビリティドメイン１１内におけるＭＮ１０１へのパケットルーティングを行うことが可能である。

上記のように、ＭＮ１０１へ割り当てられた複数のプレフィックスを単一の上位プレフィックスで表現することで、複数プレフィックスモデルを単一プレフィックスモデルへ還元した場合には、ＬＭＡ１１０が、ＭＮ１０１のルーティングプリファレンスに基づいて設定されたパスとは異なるルーティングパス経由で、ＭＮ１０１へパケットを発送してしまう場合も起こり得る。

例えば、ＭＮ１０１が２つのインタフェースを介してローカルモビリティドメイン１１へ接続されており、各インタフェースに６５ビットのプレフィックス（Ｐａ、Ｐｂ）が割り当てられているとする。２つのインタフェースのそれぞれに割り当てられているプレフィックス（Ｐａ、Ｐｂ）が６４ビットの共通ビット配列（Ｐｃ）を有し、末尾の６５ビット目の値が異なるような場合には、ＭＮ１０１は、ＭＮ１０１へ割り当てられている２つのプレフィックス（Ｐａ、Ｐｂ）を６４ビットの共通ビット配列（Ｐｃ）で表すことが可能である。すなわち、プレフィックス（Ｐａ、Ｐｂ）は、共通する６４ビットの上位プレフィックス（Ｐｃ）と、末尾の６５ビット目（Ｐａ、Ｐｂでそれぞれ異なる値）とを有している。

また、ＭＮ１０１は、この上位プレフィックスを気付プレフィックスとしてＨＡ１０２へ登録することも可能である。しかしながら、例えば、あるフローＩＤ（ＦＩＤａ）がプレフィックス（Ｐａ）を含む気付アドレスへ送信されるようにするプリファレンスをＭＮ１０１がＨＡ１０２へ設定している場合であっても、ＬＭＡ１１０は、そのプリファレンスを把握できないため、ＬＭＡ１１０で、ＭＮ１０１のプリファレンスに従わないパケット発送（例えば、あるフローＩＤ（ＦＩＤａ）に係るパケットを、プレフィックス（Ｐｂ）を通知しているＭＡＧ１１１経由で転送）を行ってしまう可能性がある。

このような場合に対処するため、ＭＮ１０１が、本発明に係る方法を利用して、上位プレフィックスで表されている各プレフィックスに対するルーティングプリファレンスをＬＭＡ１１０へ設定することが有効である。これにより、ＬＭＡ１１０は、ＭＮ１０１が所望するルーティングプリファレンスに基づいたフィルタルールに従って、ＭＮ１０１へのパケット発送を正しく行うことが可能となる。

また、本発明に係る方法を利用して、ローカルモビリティドメイン１１内のフィルタリングエージェント（ＬＭＡ１１０又は何らかのポリシサーバ）がＭＮ１０１のルーティングプリファレンスを把握し、このルーティングプリファレンスに基づいて設定されるフィルタルールに従ってフローフィルタリングを行うことが可能な場合であっても、フィルタリングエージェントは、ＭＮ１０１のルーティングプリファレンスに意図的に従わずに、ＭＮ１０１へパケットを発送する場合も起こり得る。例えば、ＬＭＡ１１０は、ローカルモビリティドメインのネットワーク状態をより正確に把握できる場所に配置されているため、例えばＭＡＧ１１１が過負荷状態にあることを検出できる可能性がある。このような場合に、ＬＭＡ１１０は、ローカルモビリティドメイン１１内の負荷バランスを行うため、ＭＡＧ１１１を経由するパケットの一部をＭＡＧ１１２経由に切り替えるルーティングパスの切り替えを行うことも考えられる。

こうしたネットワーク側におけるルーティングパスの切り替え動作は、ＭＮ１０１にとっては、ＬＭＡ１１０がＭＮ１０１のルーティングプリファレンスを把握できていないように見える。その結果、ＭＮ１０１では、ＬＭＡ１１０におけるフィルタルールの設定（例えば、ルーティングプリファレンスの再通知）の動作が開始される。しかしながら、ＬＭＡ１１０は、ＭＮ１０１のルーティングパスを意図的に変更しているため、ＭＮ１０１の新たなルーティングプリファレンスの通知を受けたとしても、このルーティングプリファレンスの受け入れを拒否するかあるいは無視して、ＭＮ１０１のルーティングプリファレンスとは異なるルーティングパスを経由してパケット発送を行い続ける可能性が高い。

このように、ＭＮ１０１が、ＬＭＡ１１０によってルーティングパスの切り替えが意図的に行われていることを把握できずに、ルーティングプリファレンスを含むフィルタメッセージをネットワーク側へ送信してしまう場合に対処するため、ＬＭＡ１１０は、ルーティングパスの変更を行った場合に、その意図（すなわち、ルーティングパスの変更がＬＭＡ１１０によって意図的に行われた旨）をＭＮ１０１へ通知できるように構成されていてもよい。

このようなＬＭＡ１１０の意図をＭＮ１０１へ通知する方法として、例えばＬＭＡ１１０がＭＮ１０１あてのパケットを転送する前に、そのパケットにマークを付ける方法が可能である。このマークは、ＬＭＡ１１０が意図的にＭＮ１０１へのパケットのルーティングパスを切り替えていることを示しており、ＭＮ１０１は、パケットを受信した際にこのマークが付加されていることを確認することで、ＬＭＡ１１０が意図的にＭＮ１０１へのパケットのルーティングパスを切り替えていることを把握できるようになる。

図７には、本発明の好適な実施の形態において、パケットのルーティングパスが意図的に変更されていることをモバイルノードへ通知するためのマークが付加されたデータパケットのフォーマットの一例が図示されている。

図７において、データパケット７０は、パケットヘッダ７０１、ペイロード７０２、パス変更フィールド７０３を有している。なお、図７では、パス変更フィールド７０３がパケットの最後尾に存在しているが、パス変更フィールド７０３はパケットの内の任意の位置に配置可能であり、例えば、パケットヘッダ７０１内にパス変更フィールド７０３が配置されてもよい。

パケットヘッダ７０１には、ＩＰｖ４アドレス又はＩＰｖ６アドレスによって構成されるメッセージの送信元やあて先の情報（送信者のアドレスや受信者のアドレス）、メッセージのタイプを示すタイプフィールド、メッセージの長さを示す長さフィールドなどが含まれている。

また、ペイロード７０２には、通常はモバイルノードにとって有用なデータが含まれている。ペイロード７０２に含まれるデータは、例えば、音声、動画、メッセージなどであるが、その他の種類のデータであってもよく、また、データが何も含まれていなくてもよい。

また、パス変更フィールド７０３は、パケットのルーティングパスが意図的に変更されていることを示す値を設定するためにＬＭＡ１１０が付加するフィールドである。パス変更フィールド７０３に特定の値が設定されることによって、ＭＮ１０１へのパケットのルーティングパスが意図的に切り替えられていることをＭＮ１０１へ通知することが可能となる。

なお、パス変更フィールド７０３は、デフォルト値を“０”（ビットフラグが設定されていない状態）とする単一のビットフラグによって実現されることが望ましい。パケットのルーティングパスが意図的に変更されたことを示す場合には、このパス変更フィールド７０３に設定される値は“１”に変更される（ビットフラグが設定された状態）。なお、パス変更フィールド７０３における値の設定は、ＭＮ１０１のパケットのルーティングを行うＬＭＡ１１０以外のエンティティ（例えば、ＭＡＧ）などによって行われてもよい。

ＭＮ１０１は、データパケット７０を受信すると、データパケットの処理を行ってパス変更フィールド７０３の設定値（ビットフラグ）を参照することで、ローカルモビリティドメイン１１内でルーティングパスが意図的に変更されているかどうかを確認できるようになる。

また、図８には、本発明の好適な実施の形態において、ルーティングパスが意図的に変更されているかどうかをＭＮ１０１が確認するためのデータパケット処理の一例を示すフローチャートが図示されている。

図８において、ステップＳ８０でＭＮ１０１がデータパケット７０を受信することによって、このデータパケット処理が開始される。データパケットを受信した場合、ＭＮ１０１は、ステップＳ８１において、このデータパケットがＭＮ１０１のルーティングプリファレンスに従って発送されているかどうか（すなわち、ルーティングポリシに係る要件が満たされているかどうか）をチェックする。データパケットがＭＮ１０１のルーティングプリファレンスに従って発送されていることが確認できた場合には、ステップＳ８６において、ＭＮ１０１はこのデータパケット処理を終了し、このデータパケットに関して更なる処理（通常のデータパケット処理）を行う。

一方、データパケットがＭＮ１０１のルーティングプリファレンスに従って発送されていないことが分かった場合には、ＭＮ１０１は、ステップＳ８２において、ルーティングパスの切り替えが意図的に行われていることを示すマークがデータパケットに付加されているかどうか（すなわち、上記のパケットフォーマットの一例において、パス変更フィールド７０３のビットフラグが設定されているか否か）を確認する。

なお、ルーティングプリファレンスに従って発送されているかどうかのチェック（ステップＳ８１）と、ルーティングパスの切り替えが意図的に行われていることを示すマークがデータパケットに付加されているかどうかの確認（ステップＳ８２）は、処理順序が逆であってもよい。

ステップＳ８２において、ルーティングパスの切り替えが意図的に行われていることを示すマークがデータパケットに付加されていることが確認できた場合には、ＭＮ１０１は、ステップＳ８３において、この結果に基づいてルーティングポリシを更新する。

ルーティングポリシの更新を行う方法としては、例えば、現在のルーティングパス（すなわち、ネットワーク側で意図的に切り替えられたルーティングパス）を反映するように、ＭＮ１０１がルーティングポリシの変更を行うことが挙げられる。例えば、ＭＮ１０１のルーティングポリシでは、データパケット７０はＭＡＧ１１１経由でＭＮ１０１に到達するはずであるが、ＬＭＡ１１０が意図的にＭＡＧ１１２経由でデータパケット７０の発送を行っており、ルーティングパスの切り替えが意図的に行われていることを示すマークがデータパケット７０に付けられているとする。この場合、ＭＮ１０１は、このデータパケット７０を受信すると、ＬＭＡ１１０による意図的なルーティングパスの切り替えを把握し、以降データパケット７０として受信する同一フローのパケットに関して、そのルーティングパスがＭＡＧ１１２経由となるようルーティングポリシを更新する。

ＭＮ１０１でルーティングポリシが更新されると、ＭＮ１０１は、ステップＳ８４において、更新されたルーティングポリシに基づくルーティングプリファレンスを作成し、ＬＭＡ１１０におけるフィルタルールを更新するために、このルーティングプリファレンスを含むフィルタメッセージ４０を送信する処理を行う。ＬＭＡ１１０におけるフィルタルールの更新を行うことで、ＬＭＡ１１０で設定されているフィルタルールとＭＮ１０１におけるルーティングポリシとが同期し、ローカルモビリティドメイン１１内におけるＭＮ１０１へのパケットルーティングがより効率的に行われるようになるという利点がある。ＭＮ１０１は、ＬＭＡ１１０におけるフィルタルールの更新を行うと、ステップＳ８６において、このデータパケット処理を終了し、このデータパケットに関して更なる処理（通常のデータパケット処理）を行う。

一方、ステップＳ８２において、ルーティングパスの切り替えが意図的に行われていることを示すマークがデータパケットに付加されていることが確認できなかった場合には、ＭＮ１０１は、ＬＭＡ１１０がＭＮ１０１のルーティングプリファレンスを把握していないと判断する。この場合、ＭＮ１０１は、ステップＳ８５において、ＭＮ１０１のルーティングプリファレンスを含むフィルタメッセージ４０をＬＭＡ１１０へ送信する。なお、この場合のＭＮ１０１のルーティングプリファレンスは、本来はＬＭＡ１１０によって把握及び反映されているはずのものであり、ステップＳ８５の処理は、ＭＮ１０１のルーティングプリファレンスをＬＭＡ１１０に再設定する処理である。そして、フィルタメッセージ４０の送信処理が終了すると、ＭＮ１０１は、ステップＳ８６において、このデータパケット処理を終了し、このデータパケットに関して更なる処理（通常のデータパケット処理）を行う。

なお、ルーティングパスの切り替えが意図的に行われていることを示すマークは、該当するすべてのパケットに付加されるのではなく、一部に付加されてもよい。この場合、上述の図８に示す動作もそれに対応して、複数のパケットをサンプリングしたうえで最終判断を行うようにすることが望ましい。また、ルーティングパスの切り替えが意図的に行われるのは、特定のフローとしてこれまで扱っていたものを一括で変更する場合だけではなく、例えば、負荷分散などを目的としてフローの一部を変更する場合もあり得る。この場合は、プリファレンスに一致するパケットと一致しないパケットが並行して検出されることになるが、それが意図的に行われているかどうかが不明であるときには本発明が同様に動作し、適切な処理を行うことができる。また、ルーティングパスの切り替えが意図的に行われていることが確認できた際に変更するルーティングポリシの変更方法は、変更されたルーティングパスを反映するように変更するほかに、追加のルーティングポリシとして設定することもできる。これにより、ネットワーク側の意図的ではあるが一時的であるような切り替えや、負荷分散のための部分的な変更にも容易に対応できるようになる。また、上述の図８に示す動作では、ＬＭＡ１１０が、ステップＳ８４でＭＮ１０１から送信されたルーティングプリファレンスに基づいてＭＮ１０１に係るフィルタルールを更新しているが、例えば、ＬＭＡ１１０がルーティングパスの意図的な切り替えを行うとともに、ＭＮ１０１に関するフィルタルールを更新することも可能である。この場合、ＬＭＡ１１０は、ＬＭＡ１１０（又はポリシサーバ）においてＭＮ１０１に係るフィルタルールが更新されたことをＭＮ１０１へ通知することが望ましく、例えば、上述の図７に図示されているパケットフォーマットを利用し、データパケット７０のパス変更フィールド７０３を用いてＬＭＡ１１０（又はポリシサーバ）においてＭＮ１０１に係るフィルタルールが更新されたことを通知してもよい。

ＬＭＡ１１０（又はポリシサーバ）においてＭＮ１０１に係るフィルタルールが更新されたことをＭＮ１０１へ通知することによって、ＭＮ１０１は、ローカルモビリティドメイン１１内（例えば、ＬＭＡ１１０又はポリシサーバ）に設定されているＭＮ１０１のフィルタルールが変更されたことを把握することが可能となる。これにより、ＭＮ１０１は、ローカルモビリティドメイン１１内に設定されているＭＮ１０１に係るフィルタルールの更新（フィルタルールの同期化）を行うためにフィルタメッセージ４０を送信する動作（図８のステップＳ８４の処理）を行う必要がないという利点がある。

また、データパケット７０のパス変更フィールド７０３を利用して、ローカルモビリティドメイン１１のネットワーク状態に関する情報がＭＮ１０１へ通知されてもよい。このネットワーク状態に関する情報は、例えば、別の適切なパスを特定するために有用な情報であり、このネットワーク状態に関する情報に基づいて、ＭＮ１０１がより適切なルーティングパスを経由したデータパケットの送受信を行えるようにするために有用な情報である。

例えば、ＭＮ１０１がローカルモビリティドメイン１１内の別のモバイルアクセスゲートウェイへ接続可能であり、ローカルモビリティドメイン１１のネットワーク状態に関する情報として、例えば、別のモバイルアクセスゲートウェイに接続可能であることを示す情報、又は、別のモバイルアクセスゲートウェイ経由のパケット伝送のほうが効率的な伝送が実現されることを示す情報などを受信したとする。ＭＮ１０１は、上記のようなＬＭＡ１１０から通知されたネットワーク状態に関する情報に基づき、ＭＡＧ１１２よりむしろ別のモバイルアクセスゲートウェイを選択して、以降のデータパケット７０の送受信を行うようにすることが可能である。

さらに、データパケット７０内のパス変更フィールド７０３を利用して、ＬＭＡ１１０のフィルタルールを変更するのではなく、ＨＡ１０２のフィルタルールを変更するようＭＮ１０１に要求する旨が通知されるようにしてもよい。このような通知は、例えば、ＭＮ１０１がローカルモビリティドメイン１１内の複数のローカルモビリティアンカに接続されており、これらのローカルモビリティアンカがＭＮ１０１によって設定されるフィルタルールを同期化するリソース又は機能を有していない場合に有用である。ＨＡ１０２のフィルタルールの変更を要求する情報がパス変更フィールド７０３に設定されていた場合には、ＭＮ１０１は、図８のステップＳ８４の処理において、ローカルモビリティドメイン１１内（例えばＬＭＡ１１０）のフィルタルールを更新するためにルーティングプリファレンスを送信する代わりに、ＨＡ１０２のフィルタルールを更新するためにルーティングプリファレンスを送信する処理を行う。

また、ＭＮ１０１側から、ルーティングパスの切り替えが必要となった場合に選択可能なルーティングパス（バックアップルーティングパス）に関する情報をローカルモビリティドメイン１１へ通知できるようにしてもよい。この場合、例えば、ＭＮ１０１は、ルーティングパスの切り替えが必要となった場合に選択可能なバックアップルーティングパスに関する情報をフィルタメッセージ４０内のプリファレンスオプション４０２に挿入することによって、この情報を通知してもよい。

さらに、ＭＮ１０１は、ローカルモビリティドメイン１１内の様々なルーティングパスに優先順位を設定し、ＬＭＡ１１０が、この優先順位に基づいてルーティングパスの選択を行えるようにしてもよい。例えば、ＭＮ１０１は、ＣＮ１４０からの特定のフローに関して、ＭＡＧ１１１経由で発送されることを最優先とする最優先プリファレンス（第１プリファレンス）と、ＭＡＧ１１２経由で発送されることを２番目に優先する第２のプリファレンスとをＬＭＡ１１０へ通知する。この場合、ＬＭＡ１１０は、ＭＮ１０１へ転送すべきＣＮ１４０からのフローに関するパケットを受信すると、ＭＮ１０１が所望する第１プリファレンスに従って（すなわち、ＭＡＧ１１１経由で）パケットを発送する。また、例えばＭＡＧ１１１が過負荷状態となった場合などには、ＬＭＡ１１０は、ＭＮ１０１が所望する第２プリファレンスに従って（ＭＡＧ１１２経由で）パケットを発送する。

このようにＭＮ１０１がルーティングパスに優先順位を設定することによって、ＭＮ１０１は、ＬＭＡ１１０が第１プリファレンス以外のルーティングパスを使用してパケット発送を行った場合には、ローカルモビリティドメイン１１内で何らかのルーティング問題（第１プリファレンスに従ったルーティングが行われなくなるような問題）が生じていることを把握できるようになる。この結果、ＭＮ１０１は、第１プリファレンスに従ったルーティングが行われなくなった場合に、ルーティングパスがＬＭＡ１１０によって意図的に切り替えられていることを把握することが可能となり、また、ローカルモビリティドメイン１１内に設定されているＭＮ１０１に係るフィルタルールの更新（フィルタルールの同期化）を行うためにフィルタメッセージ４０を送信する動作（図８のステップＳ８４の処理）を行う必要がない。

このように、ＬＭＡ１１０が、例えばローカルモビリティドメイン１１内の負荷バランス、又は、ローカルモビリティドメイン内の障害などの様々な問題に応じて、ＭＮ１０１へのパケットのルーティングパスを意図的に切り替える状況も起こり得る。しかしながら本発明では、ルーティングパスの切り替えが意図的なものか否かをＭＮ１０１が把握できるようにし、ローカルモビリティドメイン１１におけるルーティングパスの切り替えの意図をＭＮ１０１が確実に把握できるようにすることが可能である。

なお、ＭＮは、ネットワークドメインの構成がどのようなものであるかを確認したうえで本発明の動作を開始することが望ましい。例えば、接続認証の過程などから、自身がホームドメイン以外のローカルモビリティドメインにいることを検知したり、接続しているローカルモビリティドメインがＨＡとＬＭＡとを分離した構成を有していることを検出したり、また、ネットワークからＨＡとは異なるネットワークノードにルーティングプリファレンスを通知するように指示を受けたりすることによって、ＭＮはその動作を変えることができるように構成されていてもよい。

また、本明細書では、本発明が最も実用的かつ好適な実施例となるように考慮されて図示及び説明されているが、当業者であれば、上述の各ノードの構成要素に係る設計やパラメータの詳細において、発明の範囲から逸脱しない程度に様々な変更が行われてもよいことは明白である。

例えば、本明細書では、ローカルモビリティドメイン内のＬＭＡ又はポリシサーバのどちらかがフィルタリングエージェントである場合を例示しているが、ＬＭＡ及びポリシサーバの両方の機能を備えた単一のエンティティとして、フィルタリングエージェントが実現されてもよい。

また、本明細書では、主に複数のネットワークインタフェース２０１を有するＭＮ２００に関して言及しているが、ネットワークインタフェース２０１を１つしか有さないＭＮ２００に係るフィルタルール（ＭＮ２００のプリファレンスに基づくフィルタルール）が、ネットワークベースのモビリティ管理ドメイン内のフィルタリングエージェントに設定されるようにする場合においても、本発明の適用が可能である。

また、本明細書では、ＭＮのネットワークインタフェース２０１がレイヤ１及びレイヤ２のコンポーネントを含んでいる構成例を挙げて説明を行っているが、各レイヤが分離されていてもよく、その数もそれぞれ独立に構成されていてもよい。例えば、１つの無線部を複数の接続方式で共用し、ネットワークインタフェースの観点からはその変化が問題にならない程度の速度で切り替えたり、レイヤ２で論理的なリンクを維持したりすることにより、ネットワーク部からは複数のインタフェースを介してネットワークに接続している場合と同等に動作できるよう構成されていてもよい。

また、ここでは、図示されているような簡単なネットワーク構成に基づいて本発明の説明を行ったが、ローカルネットワークドメインの構成は、複数オペレータ間のローミング関係も含めて多岐に渡ることが考えられる。例えば、ＭＡＧがＭＮの直接的なアクセスルータである構成や、ＭＡＧが異なるアクセスネットワーク（ローミングを含む）との境界ルータであり、ＭＮはいったんその異なるアクセスネットワークに接続した後、そのアクセスネットワークを介して境界ルータであるＭＡＧに接続するという構成が考えられる。しかしながら、いずれの構成又は条件の場合においても、様々なパラメータや端末からＭＡＧへの到達手順、端末の通信手順などの設計部分が異なるものの、本発明の動作に関しては同様に適用可能であることは明白である。

なお、ＭＮ（移動端末）は複数の通信デバイスから構成されるものであってもよい。例えば、移動端末は、パーソナルコンピュータなどの電子計算機に外挿型あるいは組み込み型の３ＧＰＰ通信用デバイスモジュール及び／又は非３ＧＰＰ通信デバイスモジュールを装着する場合などがあり、こうした多様な移動端末においても本発明は同等の効果を有するものである。

なお、上記の本発明の実施の形態の説明で用いた各機能ブロックは、典型的には集積回路であるＬＳＩ（Large Scale Integration）として実現される。これらは個別に１チップ化されてもよいし、一部又はすべてを含むように１チップ化されてもよい。なお、ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ（Integrated Circuit）、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。

また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。

さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオ技術の適応などが可能性としてあり得る。

本発明は、移動端末がホームネットワークドメインではないネットワークベースのモビリティ管理ドメインに接続している場合に、移動端末のプリファレンスに基づいたルーティングを効率良く実現するという効果を有しており、ＩＰを利用した通信技術や、フィルタルールに基づくフローフィルタリング技術などに適用可能である。

本発明は、インターネットプロトコル（ＩＰ：Internet Protocol）を利用した通信技術に係る通信システム及び移動端末並びにネットワークノードに関し、特に、フィルタルールに応じてパケット転送経路の設定（フローフィルタリング）を行う通信システム及び移動端末並びにネットワークノードに関する。

例えば下記の非特許文献１には、モバイルＩＰｖ６（ＭＩＰｖ６）を使用することで、モバイルノード（ＭＮ：Mobile Node）が、インターネットへの接続ポイントを変更した場合であっても、不変の固定アドレスを使用し続けることを可能とする技術が開示されている。ＭＩＰｖ６におけるＭＮの固定アドレスは、ＭＮのホームネットワークドメインにおけるアドレスであり、ホームアドレス（ＨｏＡ：Home Address）と呼ばれている。また、ＭＮは外部（foreign）ネットワークドメインに接続されている間は、外部ネットワークドメインから通知されるサブネットプレフィックスを用いてＩＰアドレスを構成することが可能である。このように構成されるＩＰアドレスは、気付アドレス（ＣｏＡ：Care-of Address）と呼ばれ、ＭＮはこのアドレスによっても到達可能となる。

ＭＮは、その接続位置によらずに到達可能性を維持するために、自身の気付アドレスとホームアドレスとを関連付けてホームエージェント（ＨＡ：Home Agent）に登録する。ＭＩＰｖ６では、ＨＡはＭＮのホームネットワークドメイン内のルータであり、ＭＮの現在の気付アドレスがＨＡに登録される。この登録は、ＭＮがＨＡに対してバインディングアップデート（ＢＵ：Binding Update）メッセージを送信することで実現される。

ＭＮがホームネットワークドメインから離れた場所に位置している場合には、ＨＡはＭＮのホームアドレスあてのパケットを受信（intercept）し、関連する気付アドレス経由でＭＮにパケットをトンネルする。

ＭＩＰｖ６では、ホストがモビリティ管理機能を有している。したがって、ＭＩＰｖ６は、ホストベース（端末ベース）のモビリティ管理プロトコルと呼ばれることもある。

一方、ＭＮがローカルモビリティドメインを移動する際に行うモビリティ関連のシグナリングを軽減させる別のモビリティ管理の方法も存在する。例えば、ローカルモビリティドメイン内に配置されたプロキシエンティティによって、ＭＮのモビリティ管理が補助されるようにすることが可能である。このようなモビリティ管理の方法は、ネットワークベースのモビリティ管理と呼ばれ、例えば、下記の特許文献１や下記の非特許文献２に記載されている。なお、本明細書では、ＭＩＰｖ６などのホストベースのモビリティ管理プロトコルを実装している移動端末だけではなく、ネットワークベースのモビリティ管理ドメインによってモビリティ管理を受けている移動端末に関してもモバイルノード（ＭＮ）と呼ぶ。

図１には、従来の技術におけるネットワークベースのモビリティ管理システムの一例が図示されている。図１において、モバイルノード（ＭＮ１０１）は、本来ホームネットワークドメイン１０に接続している場合には、ホームアドレスを用いてコレスポンデントノード（ＣＮ：Correspondent Node）１４０との間で通信セッションを有している。

また、ＭＮ１０１は移動可能であり、グローバル通信ドメイン１３を移動する場合には、例えばＭＩＰｖ６を用いることで確実にＣＮ１４０との間で通信を継続することが可能となる。すなわち、ＭＮ１０１は、移動を行った際には、移動先の気付アドレスをホームアドレスに関連付けて、ホームネットワークドメイン１０内のホームエージェント（ＨＡ：Home Agent）１０２に登録することが可能となる。

また、ＭＮ１０１は、ローカルモビリティドメイン１１に移動すると、ＭＮ１０１の固有の識別子（ＭＮ−ＩＤ）を提示してアクセス認証処理を受け、ＭＡＧ（Mobile Access Gateway：モバイルアクセスゲートウェイ）に接続する。なお、ローカルサーバ（ローカルモビリティドメイン１１内の不図示のサーバ）から得られるＭＮ１０１のポリシプロファイル（policy profile）との関連付けが行われる際には、通常はＭＮ−ＩＤが用いられる。

ポリシプロファイルには、例えば、提供されるネットワークベースのモビリティサービスの特性や、モバイルノードに割り当てられるオンリンクプレフィックス、許可されるアドレス構成モード、ローミングポリシ、その他のネットワークベースのモビリティサービスに必須の関連パラメータなどが含まれる。

例えば、ＭＮ１０１がＭＡＧ１１１に接続する際には、ＭＮ１０１のアクセス認証が成功した後、ＭＡＧ１１１は、ローカルサーバからＭＮ１０１のポリシプロファイルを取得する。これにより、ＭＡＧ１１１は、ＭＮ１０１のモビリティシグナリングを実行するために必要な情報を取得することが可能となる。したがって、ＭＡＧ１１１は、例えば、ＭＮ１０１に割り当てられるオンリンクプレフィックスを含むルータ通知（ＲＡ：Router Advertisement）メッセージを周期的にＭＮ１０１に送信する。

ＭＮ１０１は、ＲＡメッセージを受信してオンリンクプレフィックスを発見すると、ローカルモビリティドメイン１１に接続されているインタフェースが行う通信用にＩＰアドレス（例えば気付アドレス）を構成する。ローカルモビリティドメイン１１内の各ＭＡＧは、常にローカルサーバを参照して、ＭＮ１０１のプロファイルを取得することが可能である。したがって、ＭＮ１０１は、ローカルモビリティドメイン１１のどの接続ポイント（ＭＡＧ）に接続されている場合でも、その接続インタフェースから常にオンリンクプレフィックスを把握することが可能となる。

例えば、ＭＮ１０１がＭＡＧ１１２に移動すると、ＭＡＧ１１２は、その認証処理中にＭＮ１０１のＭＮ−ＩＤに基づいてローカルサーバからＭＮ１０１のオンリンクプレフィックスを取得する。したがって、ＭＮ１０１は、ローカルモビリティドメイン１１内の接続位置によらず、最初に構成したＩＰアドレス（ローカルモビリティドメイン１１に最初に接続した際に構成したＩＰアドレス）を常に利用することが可能である。

また、ローカルモビリティドメイン１１内のルーティングに関しては、ローカルモビリティアンカ（ＬＭＡ：Local mobility Anchor）１１０と呼ばれるエンティティが、各モバイルノードのトポロジ的な（論理的な）アンカポイントとして機能する。さらに、ＬＭＡ１１０は、各モバイルノードの到達可能状態の管理を行う。したがって、ＬＭＡ１１０は、非特許文献１に記載されているホームエージェントと類似する面を持っている。すなわち、ＬＭＡ１１０は、各ＭＮ１０１のアンカポイントとして機能するように、各ＭＮ１０１の現在位置に係るアップデートが行われる必要がある。

このアップデートを行うため、ＭＮ１０１がＭＡＧに接続する際には常に、ＭＡＧからＬＭＡ１１０に、プロキシバインディングアップデート（ＰＢＵ：Proxy Binding Update）メッセージが送信される。このＰＢＵメッセージにより、ＬＭＡ１１０には、ＭＮ１０１の固有の識別子であるＭＮ−ＩＤがそのＭＡＧを識別する情報（ＭＡＧの気付アドレス）に関連付けて登録される。ＬＭＡ１１０は、ＰＢＵメッセージによって登録されたバインディングを用いることで、適切なＭＡＧを通じてパケットをＭＮ１０１に発送することが可能となる。

また、ローカルモビリティドメインがＭｏｎａｍｉ６の方法を採用してモバイルノードの同時接続をサポートする場合に生じる問題に関しては、例えば特許文献１の記載においても言及されている。

また、下記の特許文献２では、ユーザ機器に関するポリシを把握するため、ゲートウェイノードがポリシコントロールノードに問い合わせを行えるようにするメカニズムが開示されている。また、このメカニズムを適用することで、ローカルモビリティアンカが、モバイルノードのルーティングプリファレンスに関して、モバイルノードのホームエージェントに問い合わせを行うことが可能となる。

また、モバイルノードが、例えばＩＥＥＥ８０２．２１で定義されている情報サービスのような探索メカニズムを使用することによって、ルーティングプリファレンスを設定すべきローカルモビリティドメイン内の場所（ＬＭＡのアドレス）を探索することが可能である。さらにＭＮ１０１は、例えばＩＥＥＥ８０２．２１を利用して、ＬＭＡ１１０のアドレスを探索することが可能であり、ＬＭＡ１１０のアドレスを把握したＭＮ１０１は、ＬＭＡ１１０と通信を行い、ＣＮ１４０からのトラフィックフローに関するルーティングプリファレンスをＬＭＡ１１０に指示することが可能である。

例えば、図１において、ＭＮ１０１がＭＡＧ１１１に接続し、ＭＮ１０１とＭＡＧ１１１と間で認証処理が実行される。ＭＡＧ１１１は、ＭＮ１０１の認証が成功した後、ＭＮ１０１のＭＮ−ＩＤをＭＡＧ１１１の気付アドレスに関連付けるＰＢＵメッセージをＬＭＡ１１０に送信することによって、ＬＭＡ１１０にＭＮ１０１に係るバインディングが登録される。

ＬＭＡ１１０はパケットを受信すると、自身のキャッシュをチェックして、受信パケットのあて先に一致するＭＮ−ＩＤを探索する。例えば、ＬＭＡ１１０は、受信パケットのあて先がＭＮ１０１のＭＮ−ＩＤに一致することを特定すると、登録されているバインディングに基づいて、ＭＡＧ１１１にパケットをトンネルする。そして、ＭＡＧ１１１からＭＮ１０１にパケットが転送される。

また、現在、複数のネットワークインタフェースを備えた持ち運び可能な電子周辺機器の導入により、モバイルノード／ルータは、所定のホームアドレスに対して複数の気付アドレスを登録する機能を有している。複数の気付アドレスの登録方法に関しては、現在、ＩＥＴＦのＭｏｎａｍｉ６（Mobile Nodes and Multiple Interfaces in IPv6）ワーキンググループで議論が進められている。

例えば、下記の非特許文献３に記載されている技術によれば、１つのホームアドレスに関連付けられる複数のバインディングをＢＩＤ（バインディング固有識別情報）と呼ばれる識別番号を用いて区別することにより、複数の気付アドレスの登録が行われる。ＢＩＤは、モバイルノード／ルータの１つのホームアドレスに関連付けられるインタフェース又は気付アドレスのそれぞれに対して割り当てられる。したがって、ホームアドレスはモバイルノード／ルータ自体に関連付けられている一方、ＢＩＤはモバイルノードによって登録された複数のバインディングのそれぞれを識別できるように関連付けられている。

モバイルノード／ルータは、バインディングアップデート（ＢＵ）メッセージを使用してホームエージェントにＢＩＤを通知し、ホームエージェントは、自身のバインディングキャッシュにＢＩＤを記録する。さらに、複数の気付アドレスの登録によって、モバイルノード／ルータがプリファレンス（preference）をホームエージェントに設定して、複数の気付アドレスを通じてトラフィックフローの選択的なルーティングを実行できるようになる可能性がある。

このプリファレンス設定方法は、例えば、下記の非特許文献４や下記の非特許文献５に記載されているように、各トラフィックフローを固有の識別子（フローＩＤ：ＦＩＤ）で識別することによって実現される。このＦＩＤによって、モバイルノード／ルータは、特定のトラフィックフローをどのように発送してほしいかをホームエージェントに指示することが可能となる。

また、下記の特許文献３では、モバイル機器自身が、ハンドオフ又は起動時にアクセスネットワーク内のルーティングパスの設定を開始させるためのパス設定メッセージを送信する方法が提案されている。この特許文献３に開示されている技術では、モバイル機器が、モバイル機器自身が接続しているアクセスネットワーク内のアクセスルータへパス設定メッセージを送信することで、アクセスルータにモバイル機器のルーティングエントリが作成又は更新される。さらに、アクセスルータからネットワーク階層の上位ルータ（次ホップのルータ）にパス設定メッセージが次々と送信されていくことで、ネットワーク階層の上位ルータにおいてルーティングエントリが作成又は更新される。その結果、アクセスネットワーク内のルータにモバイル機器のルーティングエントリが登録されて、アクセスネットワークにモバイル機器のルーティングパスが設定される。
米国特許公開２００６／０２０９７５９ 国際特許公開ＷＯ２００７／０３９００６ 米国特許第７２３９６１８号 D. Johnson, C. Perkins and J. Arkko, "Mobility Support in IPv6", Internet Engineering Task Force Request For Comments 3775, June 2004. S. Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury and B. Patil, "Proxy Mobile IPv6", Internet Engineering Task Force Internet Draft: draft-ietf-netlmm-proxymip6-00.txt, April 08, 2007. R. Wakikawa, T. Ernst and K. Nagami, "Multiple Care-of Addresses Registration", Monami6 Working Group Internet Draft: draft-ietf-monami6-multiplecoa-00.txt, June 12, 2006. H. Soliman, et al., "Flow Bindings in Mobile IPv6", Internet Engineering Task Force Internet Draft: draft-soliman-monami6-flow-binding-00.txt, February 27, 2006. C. Larsson, H. Levkowetz, H. Mahkonen and T. Kauppinen, "A Filter Rule Mechanism for Multi-access Mobile IPv6", Internet Engineering Task Force Internet Draft: draft-larsson-monami6-filter-rules-01.txt, October 23, 2006.

しかしながら、従来の技術によれば、移動端末がホームネットワークドメインとは異なるネットワークベースのモビリティ管理ドメインに接続している場合に、移動端末のプリファレンスを反映したルーティングが実現されない場合がある。

例えば、図１において、ＭＮ１０１が複数のインタフェースを有している場合、ＭＮ１０１は、ＭＡＧ１１１及びＭＡＧ１１２に同時に接続することが可能である。ここで、例えばローカルモビリティドメイン１１には、ＭＡＧ１１１が接続されているセルラネットワークと、ＭＡＧ１１２が接続されている無線ローカルエリアネットワーク（ＷＬＡＮ）の２つのタイプのネットワークが存在しているとする。この場合、ＭＮ１０１は、ＭＡＧ１１１に接続されているセルラインタフェースと、ＭＡＧ１１２に接続されているＷＬＡＮインタフェースの２つのインタフェースを有している。これにより、ＭＮ１０１は、ローカルモビリティドメイン１１内において複数の気付アドレスを有し、ＣＮ１４０からのトラフィックフローのＭＮ１０１への発送方法に関するプリファレンスをＨＡ１０２に設定する。

また、Ｍｏｎａｍｉ６の方法を使用して、ＭＡＧ１１１及びＭＡＧ１１２は両方共、モバイルノードの固有の識別子（ＭＮ−ＩＤ）をＬＭＡ１１０に登録することが可能である。これにより、ＬＭＡ１１０は、ＭＮ１０１がＭＡＧ１１１及びＭＡＧ１１２の両方に接続されており、ローカルモビリティドメイン１０内においてＭＮ１０１への２つのアクティブな経路が登録されていることを把握する。

しかしながら、ＬＭＡ１１０は、ＭＮ１０１のＭＮ−ＩＤに対応するパケットを受信した場合には、ＭＮ１０１にパケットを届けるためにどちらのＭＡＧにパケットを転送すべきであるかを選択する必要がある。ここで、例えばＭＮ１０１が、ＣＮ１４０からのトラフィックはＭＮ１０１のＷＬＡＮインタフェース経由で発送されるように指示するプリファレンスをＨＡ１０２に設定しているとする。ＨＡ１０２はＬＭＡ１１０にパケットを転送するが、ＬＭＡ１１０はＭＮ１０１によって設定されたプリファレンスを把握しておらず、その結果、ＬＭＡ１１０は、ＣＮ１４０からＭＮ１０１へのトラフィックフローを好ましくないルート（例えば、ＭＡＧ１１１経由）で転送してしまう可能性がある。

また、特許文献１に記載の技術では、モバイルアクセスゲートウェイがローカルモビリティドメインにおいて複数のインタフェースを有するモバイルノードのプロキシとして機能している場合であっても、モバイルアクセスゲートウェイは、モバイルノードに関するルーティングプリファレンスを把握することができないという問題がある。したがって、モバイルアクセスゲートウェイは、モバイルノードがローカルモビリティドメイン内におけるトラフィックフローに関してどのような伝送方法を望んでいるかを、ローカルモビリティアンカに通知することはできない。

また、特許文献２に記載の技術では、ホームネットワークドメインとローカルモビリティドメインとの間に何らかの関係（アソシエーション）が確立されている必要があるが、こうしたアソシエーションは確立していない（あるいは確立できない）可能性がある。

例えば、第３世代パートナーシッププロジェクト（３ＧＰＰ：Third Generation Partnership Project）のコンテキストを用いて、ホームネットワークドメインはオペレータの３ＧＰＰコアネットワークであり、ローカルモビリティドメインは、（オペレータにとって）信頼できない３ＧＰＰアクセスネットワークであるとする。このような場合、オペレータはローカルモビリティドメインを信頼することができないため、両方のネットワークの間にアソシエーションを確立することは困難となる。

また、上述のようなＩＥＥＥ８０２．２１で定義されている情報サービスを利用して、ＭＮ１０１がＬＭＡ１１０のアドレスを把握する方法によれば、モバイルノードは、ルーティングプリファレンスの設定場所（ＬＭＡ１１０）を把握するためにローカルモビリティドメインに問い合わせを行う必要があり、その結果、システムがより複雑になってしまうという問題がある。

また、特許文献３に開示されている技術は、モバイル機器自身が、ネットワークに対してルーティングパスの設定を開始させるためのパス設定メッセージを送信するが、その目的は本発明と大きく異なっている。特許文献３に開示されている技術では、モバイル機器が、例えば基地局間のハンドオフを行った場合に、そのハンドオフによる接続先でパケットを送受信するためのルーティングパスをネットワーク内で設定させるためにパス設定メッセージを送信する。すなわち、特許文献３に開示されている技術では、ハンドオフ直後にモバイル機器がパケットの送受信（特に、モバイル機器あてのパケットの受信）を行えない状態を解消するために、モバイル機器自身がパス設定メッセージを送信することで接続通知を行い、このパス設定メッセージをトリガとするメッセージがネットワーク内の各ルータで転送されることで、モバイル機器のルーティングパスが登録される。したがって、特許文献３に開示されている技術は、あくまでもモバイル機器のルーティングパスの登録を目的としており、あるフローに関して、モバイル機器がパケット受信可能な複数のルーティングパスの中から、モバイル機器が所望するルーティングパスを通るようにフィルタルールの設定が行われるものではない。また、特許文献３に開示されている技術では、ネットワーク内の各ルータ（すべてのルータ）において、パス設定メッセージをトリガとするメッセージに基づくモバイル機器のルーティングエントリの更新機能が導入される必要がある。

本発明は、移動端末がホームネットワークドメインとは異なるネットワークベースのモビリティ管理ドメインに接続している場合に、移動端末のプリファレンスに基づいたルーティングを効率良く実現することを目的とする。

上記の目的を達成するため、本発明の通信システムは、ネットワークベースのモビリティ管理プロトコルが実行されているネットワークを有する通信システムであって、
前記ネットワークに接続されている移動端末の通信のプリファレンス情報が、前記ネットワーク内で前記移動端末の通信に係るフローフィルタリングを行っているフィルタリングエージェントに通知されるように構成されている。
この構成により、移動端末がホームネットワークドメインではないネットワークベースのモビリティ管理ドメインに接続している場合に、移動端末のプリファレンスに基づいたルーティングを効率良く実現することが可能となる。

また、上記の目的を達成するため、本発明の移動端末は、ネットワークベースのモビリティ管理プロトコルが実行されているネットワークに接続する移動端末であって、
１つ又は複数のインタフェースと、
前記インタフェースが前記ネットワークに接続されている状態で、前記インタフェースによる通信のプリファレンス情報に基づくフローフィルタリングが行われるように、前記プリファレンス情報を前記ネットワークに通知するプリファレンス通知手段とを、
有する。
この構成により、移動端末がホームネットワークドメインではないネットワークベースのモビリティ管理ドメインに接続している場合に、移動端末のプリファレンスに基づいたルーティングを効率良く実現することが可能となる。

また、上記の目的を達成するため、本発明のネットワークノードは、ネットワークベースのモビリティ管理プロトコルが実行されているネットワーク内に存在するネットワークノードであって、
前記ネットワークに接続されている移動端末のフローにフィルタルールが設定されていないことを把握するフィルタ未設定把握手段と、
前記フィルタ未設定把握手段で把握された前記フローに対してプリファレンス情報を設定するプリファレンス設定手段とを、
有する。
この構成により、移動端末がホームネットワークドメインではないネットワークベースのモビリティ管理ドメインに接続している場合に、移動端末のプリファレンスに基づいたルーティングを効率良く実現することが可能となる。

本発明は上記の構成を有しており、移動端末がホームネットワークドメインとは異なるネットワークベースのモビリティ管理ドメインに接続している場合に、移動端末のプリファレンスに基づいたルーティングを効率良く実現するという効果を奏する。

以下、図面を参照しながら、本発明の実施の形態について説明する。なお、以下の説明では、本発明を説明するために、特定の番号や時間、構造、プロトコル名、及びその他のパラメータなどが詳細に説明される場合があるが、本明細書で用いられている特定の条件は、本発明を説明するために用いられているにすぎず、本発明を限定するものではない。

本明細書では、複数のインタフェースを有するモバイルノードが、ローカルモビリティドメイン内にルーティングプリファレンス（routing preference）を設定する方法が開示される。この方法によれば、ローカルモビリティドメイン内のルーティングエンティティが、ローカルモビリティドメイン内における特定のトラフィックフロー（そのモバイルノードに関連したトラフィックフロー）の発送方法（ルーティング方法）を把握できるようになる。なお、ルーティングプリファレンス（本明細書では、プリファレンス又はプリファレンス情報と記載することもある）は、モバイルノードが特定のフローに関するパケットに対して、どのインタフェースで受信するか（あるいは、どのアドレス又はどのプレフィックスを有するアドレスで受信するか）を指定する情報である。本発明では、モバイルノードが、ローカルモビリティドメイン内のルーティングエンティティ（例えば、ローカルモビリティアンカ）に対してルーティングプリファレンスを通知することによって、ローカルモビリティドメイン内のルーティングエンティティは、モバイルノードへパケットを転送するための複数のルーティングエントリの中から、ルーティングプリファレンスで指定されたパケット受信を実現するためのルーティングエントリを選択して（フローに関するフィルタルールの設定）、パケットの転送を行う。ローカルモビリティドメイン内のルーティングエンティティにフィルタルールが設定されていない場合には、ローカルモビリティドメイン内のルーティングエンティティは、モバイルノードから通知されたルーティングプリファレンスに基づいて、新たなフィルタルールの設定を行うことが可能である。また、ローカルモビリティドメイン内のルーティングエンティティは、モバイルノードから通知されたルーティングプリファレンスに基づいて、現在保持されているフィルタルールを新たなフィルタルールに変更することが可能である。なお、フィルタルールはルーティングエンティティにおいては主にルートポリシとして扱われる。

また、モバイルノードのすべてのインタフェースがホームネットワークドメインとは異なる１つ若しくは複数のローカルモビリティドメインに接続されている場合には、モバイルノードは、そのローカルモビリティドメインにおけるルーティングプリファレンスを指示することによって、ホームエージェントにルーティングプリファレンスを設定する必要がなくなるという利点がある。この場合、ホームエージェントはモバイルノードあてのパケットをローカルモビリティドメインのフィルタリングエージェントに転送するだけで、フィルタリングノードにおいて、モバイルノードによって定義されたプリファレンスを用いたパケットの発送が行われる。

図２には、本発明の実施の形態におけるモバイルノードの構成の一例が図示されている。モバイルノード（ＭＮ）２００は、１つ又は複数のネットワークインタフェース２０１−１〜２０１−ｎ、１つ又は複数のアプリケーション２０２、データベースモジュール２０３、１つ又は複数のルートポリシ２０４−１〜２０４−ｍ、加入者識別情報２０５、ポリシエンジン２０６を有している。

なお、ネットワークインタフェース２０１−１〜２０１−ｎは、ｎ個（ｎは１以上の整数）のネットワークインタフェースが存在することを表しているが、以下では、ネットワークインタフェース２０１−１〜２０１−ｎのうちの任意のネットワークインタフェースを表す際にネットワークインタフェース２０１という表記を用いることがある。

また、ルートポリシ２０４−１〜２０４−ｍは、ｍ個（ｍは１以上の整数）のルートポリシが存在することを表しているが、以下では、ルートポリシ２０４−１〜２０４−ｍのうちの任意のルートポリシを表す際にルートポリシ２０４という表記を用いることがある。

ネットワークインタフェース２０１は、モバイルノード２００が任意の通信媒体を通じて別のノードと通信を行うために必要なハードウェア及びソフトウェアを包含する機能ブロックである。関連する技術分野で周知の用語を使用すると、ネットワークインタフェース１１は、レイヤ１（物理層）及びレイヤ２（データリンク層）の通信コンポーネント、ファームウェア、ドライバ、通信プロトコルなどを表している。なお、図１では、複数のネットワークインタフェース２０１が図示されているが、モバイルノード２００はネットワークインタフェース２０１を１つのみ有していてもよい。

また、ネットワークインタフェース２０１とポリシエンジン２０６との間では、シグナル／データパス２０７−１〜２０７−ｎを通じて、トリガ／パケットの伝送に係る情報のやり取りが可能である。

また、アプリケーション２０２は、通信プロトコルスタックのネットワーク層の上位に位置するすべてのプロトコル及びプログラムを包含する機能ブロックである。例えば、アプリケーション２０２には、トランスポート制御プロトコル（ＴＣＰ：Transmission Control Protocol）、ストリーム制御トランスポートプロトコル（ＳＣＴＰ：Stream Control Transport Protocol）、ユーザデータグラムプロトコル（ＵＤＰ：User Datagram Protocol）などの他のノードとの通信に必要なトランスポート層プロトコル又はセッション層プロトコルやプログラム及びソフトウェアが含まれる。

なお、シグナル／データパス２０８を通じて、ポリシエンジン２０６からアプリケーション２０２の適切なプログラムに対してパケット転送が可能である。また同様に、シグナル／データパス２０８を通じて、アプリケーション２０２からポリシエンジン２０６へのトリガの送信も可能である。なお、例えばアプリケーション２０２は、こうしたトリガを用いて、特定のプログラムに関連するルートポリシ２０４をポリシエンジン２０６に通知することが望ましい。

また、データベースモジュール２０３は、モバイルノード２００が必要とする情報を格納する機能を有する。なお、好適な構成では、データベースモジュール２０３は、通常、１つ又は複数のルートポリシ２０４を有している。ルートポリシ２０４は、様々なアプリケーション２０２に関連するあらゆるルーティングプリファレンスを格納している。なお、シグナル／データパス２０９を通じて、アプリケーション２０２とルートポリシ２０４との間では、適切なルートポリシの読み出し／アップデートが可能である。また、シグナル／データパス２１０を通じて、ポリシエンジン２０６は各アプリケーション２０２に関連する適切なルートポリシを読み出すことが可能である。

また、好適な構成では、データベースモジュール２０３は、加入者識別情報２０５を更に有している。加入者識別情報２０５には、モバイルノード２００のユーザに関連するあらゆる情報が含まれている。なお、この加入者識別情報の一例としては、セルラのオペレータが加入者の認証を行うために使用する国際モバイル加入者識別子（ＩＭＳＩ：International Mobile Subscriber Identity）が挙げられる。また、ローカルモビリティドメインに対する認証を実行する際、ポリシエンジン２０６は、シグナル／データパス２１０を通じて加入者識別情報２０５を取得することが可能である。

また、ポリシエンジン２０６は、アプリケーション２０２の各プログラムに関して、パケットの発送経路の決定処理を行う。ポリシエンジン２０６は、アプリケーション２０２から受信したトリガ（例えば、特定のプログラムに関連するルートポリシを示す情報を含むトリガ）に基づいてデータベースモジュール２０３を検索し、適切なルートポリシ２０４を読み出す。これによって、ポリシエンジン２０６は、モバイルノード２００によるローカルモビリティドメインのルーティングプリファレンスの設定を補助することが可能となる。

また、ポリシエンジン２０６は、現在受信しているパケットのフローに関して、適切なルーティングパスを経由してパケットを受信しているか否かを判断する機能を有している。例えば、ポリシエンジン２０６は、あるフローに対する適切なルートポリシ２０４を把握するとともに、シグナル／データパス２０７−１〜２０７−ｎを通じて、現在受信しているパケットのフローが、どのネットワークインタフェース２０１、あるいはどのアドレス（又はプレフィックス）を用いているかを把握する。そして、現在のパケット受信が、あるフローに対する適切なルートポリシ２０４と一致しない場合（すなわち、適切なルーとポリシ２０４が実現されていない場合）には、ポリシエンジン２０６は、現在受信しているパケットのフローが適切なルーティングパスを経由していないと判断する。次に、適切なルートポリシ２０４に含まれるルーティングプリファレンスをローカルモビリティドメインに通知することで、ローカルモビリティドメイン内において、所望のルーティングパスが実現されるように設定を行う。

なお、各パケットのフローは、不図示のフロー管理部によって管理されている。フロー管理部は、各パケットのフローをネットワークインタフェース２０１、あるいはモバイルノード２００に割り当てられているアドレス（又はプレフィックス）に関連付けて管理している。すなわち、フロー管理部は、どのフローが、どのネットワークインタフェース２０１、あるいはどのアドレス（又はプレフィックス）を利用しているかを管理している。

また、図３には、本発明の実施の形態において、アプリケーションに関連するルートポリシによる処理の一例を示すフローチャートが図示されている。

図３において、ポリシエンジン２０６がアプリケーション２０２からトリガを受信すると（ステップＳ３０）、処理が開始される。なお、トリガには、例えばルートポリシ２０４の識別情報やアプリケーション２０２のセッション識別情報などが含まれることが好ましいが、これらに限定されるものではない。ステップＳ３０におけるトリガの受信後、まず、データベースモジュール２０３から適切なルートポリシ（関連ルートポリシ）２０４の検索が行われる。

ルートポリシ２０４が取得されると、ポリシエンジン２０６は、このルートポリシ２０４によって規定される要件がいずれかのネットワークインタフェース（Ｉ／Ｆ）２０１において満たされているか否かがチェックされる（ステップＳ３２）。なお、ルートポリシ２０４によって規定される要件は任意であるが、例えば、パケット伝送速度を最大、遅延時間を最小、ジッタを最小、エラーレートを最小、パケットロス率を最小などの通信効率を向上させるための各種要件が規定されることが望ましい。ルートポリシ２０４によって規定される要件を満たすネットワークインタフェース２０１が存在する場合には、ポリシエンジン２０６は、そのネットワークインタフェース２０１を選択し、選択されたネットワークインタフェース（Ｉ／Ｆ）２０１に、フロー（アプリケーション２０２のセッション識別情報）を関連付ける（ステップＳ３３）。

そして、ステップＳ３３における関連付けが完了すると、ポリシエンジン２０６は、その選択されたネットワークインタフェース２０１を使用して、ローカルモビリティドメイン内におけるそのセッションに関するルーティングプリファレンスを設定する（ステップＳ３４）。その結果、セッション識別情報が一致するパケットは、選択されたネットワークインタフェース２０１を通じて送受信されるようになる。

一方、ルートポリシ２０４によって規定される要件を満たすネットワークインタフェース２０１が存在しない場合には、ポリシエンジン２０６は、アプリケーション２０２に対して、このフロー要件は現在サポート不可能である旨を応答する（ステップＳ３５）。なお、このステップＳ３５における動作が行われた場合には、アプリケーション２０２は、その特定のプログラムのフロー要件に関して再交渉を行うことも可能である。

以下、上述の図３に係る動作に関して、具体例を用いて説明する。アプリケーション２０２はＣＮとの間で、遅延による影響を受けやすい（delay sensitive）ＴＣＰセッションを有しているとする。この場合、アプリケーション２０２は、ＴＣＰフローに関するルーティングプリファレンスが反映するようにルートポリシ２０４のアップデートを行う。ルートポリシ２０４がアップデートされると、アプリケーション２０２は、ＴＣＰフローがルートポリシ２０４を用いて発送される必要がある旨を指定するトリガをポリシエンジン２０６に送信する。

このトリガに基づいて、ポリシエンジン２０６はルートポリシ２０４を検索し、その結果、アプリケーション２０２が最小遅延経路を経由したＴＣＰフローの伝送を望んでいる旨を把握する。そして、ポリシエンジン２０６は利用可能なネットワークインタフェース２０１を調べて、ＴＣＰフローの伝送条件（最小遅延）をサポートするための適切な候補を探す。

例えば、図１に図示されている構成において、ＭＮ１０１のセルラネットワークインタフェース（セルラネットワークに接続するインタフェース２０１）がローカルモビリティドメインに接続されている場合には、ポリシエンジン２０６は、このセルラネットワークインタフェースが最小遅延の要件を満たしていると判断する。その結果、ポリシエンジン２０６は、セルラネットワークインタフェース２０１にＴＣＰフローを転送して、ＣＮ１４０への発送を行う。また、さらに、ポリシエンジン２０６は、本発明で規定される方法を使用して、ローカルモビリティドメイン内におけるルーティングプリファレンスを設定する。

上述のように、本発明の目的を実現させるためには、ＭＮがローカルモビリティドメイン内におけるルーティングプリファレンスを設定することが可能な方法が規定される必要がある。この方法によって、ローカルモビリティドメイン内で伝送されるモバイルノードあてのパケットは、所望のパス（ルーティングプリファレンスに従ったパス）を経由してＭＮに到達するようになる。したがって、ＭＮは、ローカルモビリティドメイン内の何らかのエンティティに対して、ルーティングプリファレンスを通知する必要がある。このようなエンティティは、フィルタリングエージェントと呼ばれる。フィルタリングエージェントは、１つ又は複数のローカルモビリティアンカや１つ又は複数のポリシサーバなどによって実現されてもよいが、これらに限定されるものではない。

なお、ＭＮ１０は、必ずしもすべてのＴＣＰフローに対してルーティングプリファレンスを設定する必要はなく、ローカルモビリティドメイン内の何らかのエンティティに対して、必ずしもすべてのＴＣＰフローに関するルーティングプリファレンスを通知する必要はない。この場合、ＭＮは、例えばリバースパケットフロー仮定などを用いて上り方向（ＭＮからの送信方向）の経路と下り方向（ＭＮへの受信方向）の経路とが同一になるように設定することによって、特定のフローに係るパケットを送信するインタフェースと、同一のフローに係るパケットを受信するインタフェースとが同一となるように設定することが可能である。

図４には、本発明の実施の形態において、ローカルモビリティドメイン内にルーティングプリファレンスを設定するために使用されるフィルタメッセージ４０のフォーマットの一例が図示されている。

図４において、フィルタメッセージ４０は、パケットヘッダ４０１、プリファレンスオプション（preference option）４０２、モバイルノード識別子（ＭＮ−ＩＤ）４０３を有している。

パケットヘッダ４０１は、例えば、メッセージの送信者及び受信者を示すＩＰｖ４又はＩＰｖ６アドレス、このメッセージのタイプを示すタイプフィールド、メッセージの長さを示す長さフィールドなどを有しているが、これらに限定されるものではない。

例えば、フィルタメッセージ４０がＭＮからＭＡＧ又はフィルタリングエージェントに送信される場合、パケットヘッダ４０１内のアドレス（送信元（source）アドレス）には、ローカルモビリティドメインに接続されているインタフェースで構成されたＭＮのアドレスが反映される。また、例えば、フィルタメッセージ４０がＭＡＧからフィルタリングエージェントに送信される場合、パケットヘッダ４０１内のアドレス（送信元アドレス）には、ＭＡＧのアドレスが反映される。

また、プリファレンスオプション４０２には、ローカルモビリティドメインのルーティングプリファレンスが記載される。例えば、プリファレンスオプション４０２には、フィルタ識別子（ＦＩＤ）４０４及びフィルタルール４０５が含まれる。

ＦＩＤ４０４は、フィルタリングエージェントに設定される様々なフィルタルールを識別するための識別子情報である。このＦＩＤ４０４により、フィルタリングエージェントは、どのフィルタルールが、ローカルモビリティドメイン内で伝送されるどのパケットに適用されるかを把握することが可能となる。

また、フィルタルール４０５は、このルールに関連するパケットに関してフィルタリングエージェントが遵守しなければならないルールを指定するものである。例えば、ＣＮ１４０のアドレスを送信元アドレスとするパケットは、フィルタメッセージ４０のパケットヘッダ４０１に記載されている送信元アドレス（フィルタメッセージ４０の送信者）に転送されるように指示することによって、単純なフィルタルールが設定可能である。

また、フィルタメッセージ４０がＭＮからフィルタリングエージェントに送信される場合には、ＭＡＧの識別子（ＭＡＧ−ＩＤ）４０６がフィルタメッセージ４０に更に含まれていてもよい。ＭＡＧ−ＩＤ４０６によって、ＭＮは、ＬＭＡ又はポリシサーバが特定のフローをどのＭＡＧに発送すべきかを指定することが可能となる。この場合、ＣＮ１４０のアドレスを送信元アドレスとするパケットはフィルタメッセージ４０のＭＡＧ−ＩＤ４０６に指定されているＭＡＧに転送されるように、フィルタルールが設定される。

また、ＭＮ−ＩＤ４０３によって、フィルタリングエージェントは、フィルタメッセージ４０のフィルタルールが適用されるのはどのＭＮかを把握することが可能となり、ＭＮに関連する適切なフィルタルールの格納又はアップデートが可能となる。なお、ＭＮ−ＩＤ４０３には、例えば加入者識別情報２０５が含まれてもよいが、これに限定されるものではない。

ここで、図１の構成に従って、ＭＮ１０１は２つのインタフェース（セルラネットワークインタフェース及びＷＬＡＮインタフェース）を有しているとする。このとき、セルラネットワークインタフェースは、ＭＡＧ１１１に接続されており、ＣｏＡとしてCoA.Celluarを使用して通信を行うとする。一方、ＷＬＡＮインタフェースは、ＭＡＧ１１２に接続されており、ＣｏＡとしてCoA.WLANを使用して通信を行うとする。

ＭＮ１０１は、ＣＮ１４０との間で進行中のデータセッションを有しており、ローカルモビリティドメイン１１にプリファレンスを設定して、ＣＮ１４０からCoA.WLAN経由でパケットを受信することを決定する。その結果、ＭＮ１０１は、ＣＮ１４０のアドレスを送信元アドレスとするパケットがCoA.WLANに発送されるように指定するフィルタルールを生成する。なお、このフィルタルールは、ＦＩＤ−ＣＮと表記されるＦＩＤで識別されるとする。

なお、ＭＮが、ローカルモビリティドメインにおけるルーティングプリファレンスをＭＡＧに伝えてもよい。ＭＡＧは、モバイルノードのルーティングプリファレンスをローカルモビリティドメイン内のフィルタリングエージェントに転送する。また、ＭＡＧは、ＭＮのルーティングプリファレンスをフィルタリングエージェントに転送する前に、そのルーティングプリファレンスを格納（キャッシュ）してもよい。このように、ＭＡＧがフィルタリングエージェントにルーティングプリファレンスを転送することによって、ＭＮは、ローカルモビリティドメイン内のフィルタリングエージェントにルーティングプリファレンスを設定するために、フィルタリングエージェントを発見するための探索メカニズム（例えば、ＩＥＥＥ８０２．２１の技術）を用いる必要がないという利点がある。これにより、モバイルノードとローカルモビリティドメインとの間におけるシグナリングメッセージ数を減らすことが可能となる。

以下、ＭＡＧがフィルタリングエージェントにルーティングプリファレンスを転送する方法に関して、具体例を用いて説明する。なお、以下では、図１の構成を参照しながら、この具体例の説明を行う。

図１において、ＭＮ１０１は、フィルタルール（ＦＩＤ−ＣＮ）を伝送するフィルタメッセージ４０をＭＡＧ１１２に送信する。ＭＡＧ１１２はＭＮ１０１からフィルタメッセージ４０を受信すると、ＭＮ１０１がローカルモビリティドメイン１１内におけるルーティングプリファレンスの設定を望んでいることを把握する。その結果、ＭＡＧ１１２は、ローカルモビリティドメイン１１内のフィルタリングエージェント（ＬＭＡ１１０又は何らかのポリシサーバ）に対して、ＭＮ１０１のルーティングプリファレンスを通知する。また、ＭＡＧ１１２がフィルタメッセージ４０を使用して、ＭＮ１０１のルーティング設定を伝送してもよい。さらに、ＭＡＧ１１２は、非特許文献４や非特許文献５に記載の方法を使用して、ＭＮ１０１のルーティングプリファレンスを伝送してもよい。

また、ＭＮがローカルモビリティドメイン内にルーティングプリファレンスを設定する動作を、ＭＡＧが補助してもよい。この場合、ＭＡＧは、例えばＭＮとあて先ノードとの間の通信セッションにおいて双方向のパスが同一になると仮定して、逆方向のパケットフローを設定する。したがって、ＭＡＧは、上述のような仮定（リバースパケットフロー仮定）に基づいて、ＭＮに代わってルーティングプリファレンスをフィルタリングエージェントに設定する。このようなＭＡＧがＭＮに代わってルーティングプリファレンスを設定する方法によれば、レガシのモバイルノードもプリファレンスによって定められるルーティングを享受することができるようになるという利点がある。なお、リバースパケットフロー仮定を用いた場合には、双方向のパスが同一になるようにルーティングプリファレンスが設定されるが、その他の任意の条件に基づいてルーティングプリファレンスが設定されてもよい。

また、図５には、本発明の実施の形態において、ＭＡＧによって実行されるリバースパケットフロー仮定に関するフローチャートが図示されている。図５において、ＭＡＧがパケットを受信すると（ステップＳ５０）、処理が開始される。

まず、ＭＡＧは、パケットに関連するルートポリシが存在しているか否かを検証する（ステップＳ５１）。なお、フロー識別子（ＦＩＤ）４０４によって、ＭＡＧは、受信パケットが、既にルートポリシを有するパケットフローの一部か否かを検証することが可能である。受信パケットに関連するルートポリシが存在している場合には、ＭＡＧは、所定のあて先にパケットを転送して（ステップＳ５３）、処理を終了する。

一方、受信パケットに関連するルートポリシが存在していない場合には、ＭＡＧは、このパケットフローに関するルートポリシをフィルタリングエージェントにセットする（ステップＳ５２）。これにより、フィルタリングエージェントは、そのフローのパケットをルートポリシに関連付けることが可能となる。ルートポリシが作成されると、ＭＡＧは、所定のあて先にフローを転送する（ステップＳ５３）。

以下、ＭＡＧによって実行されるリバースパケットフロー仮定の方法に関して、具体例を用いて説明する。なお、以下では、図１の構成を参照しながら、この具体例の説明を行う。

ＭＮ１０１は、ＭＡＧ１１２を経由してＣＮ１４０をあて先とするパケットを送信する。ＭＡＧ１１２は、パケットを受信すると、このパケットフローに関するルートポリシが存在しているか否かを判断するためにキャッシュをチェックする。なお、ここでは、ＭＡＧ１１２は、このパケットフローに関連するルートポリシを発見できないとする。したがって、ＭＡＧ１１２は、ＭＮ１０１に代わって、ＣＮ１４０からのパケットをＭＡＧ１１２経由でＭＮ１０１に発送するように指示するルーティングプリファレンスをＬＭＡ１１０にセットする。

さらに、フィルタリングエージェントが、ＭＮによるルーティングプリファレンスの設定を補助する動作を行ってもよい。この場合、関連するルートポリシが存在しないパケットフローに関して、フィルタリングエージェントが、例えば図５に図示されている方法を実行する。

さらに、パケットフローに関連するルートポリシが存在するか否かをＭＡＧが判断する動作としては、例えば、ＭＡＧがフィルタリングエージェント（ＬＭＡ１１０又は何らかのポリシサーバ）に対して、そのパケットフローのルーティングプリファレンスが存在しているか否かの問い合わせを行ってもよく、あるいは、また、フィルタリングエージェントに転送する前にキャッシュしたＭＮのルーティングプリファレンスを格納してもよいが、これらに限定されるものではない。さらに、ＭＮは、ルーティングプリファレンスの設定に特別なプリファレンスを必要としない場合に、デフォルトのプリファレンス設定としてリバースパケットフロー仮定の方法で設定を行ってもよい。

また、図６には、本発明の実施の形態において、ＭＮに代わってルーティングプリファレンスの設定が可能なＭＡＧ又はフィルタリングエージェントに実装されている機能がブロック図によって図示されている。図６に図示されているプリファレンス代理設定ノード６００は、ＭＡＧ又はフィルタリングエージェントであり、ＭＮによるルーティングプリファレンスの設定を補助する動作（図５に図示されている動作）を行うことが可能である。

図６に図示されているプリファレンス代理設定ノード６００は、フィルタ未設定把握部６０１、プリファレンス設定部６０２を有している。フィルタ未設定把握部６０１は、ＭＮに関連するパケットを受信すると、その受信パケットに関連するルートポリシ（フィルタルール）が存在しているか否かを確認する機能（図５のステップＳ５１の処理を行う機能）を有している。また、ルートポリシ設定部６０２は、フィルタ未設定把握部６０１でその受信パケットに関連するフローのルートポリシが存在しないこと（その受信パケットに関連するフローのフィルタルールが設定されていないこと）が確認された場合、そのフローに関連して、プリファレンス情報に基づくルートポリシ（フィルタルール）を設定する機能（図５のステップＳ５２の処理を行う機能）を有している。なお、ルートポリシ設定部６０２によるルートポリシの設定は、上述のように任意の方法で設定可能であり、例えばリバースパケットフロー仮定に基づいて行われてもよく、また、他のネットワークノード（フィルタリングノードなど）に問い合わせを行った結果に基づいて行われてもよい。

また、プリファレンス代理設定ノード６００がフィルタリングエージェント以外のネットワークノードである場合（例えばＭＡＧの場合）には、ルートポリシ設定部６０２で設定されたプリファレンス情報をフィルタリングエージェントに通知するプリファレンス通知部６０３を有している。

また、ＭＮが、ローカルモビリティドメインにおけるルーティングプリファレンスを直接フィルタリングエージェントに通知してもよい。ＭＮは、何らかの探索メカニズム（例えばＩＥＥＥ８０２．２１に係る技術）を用いて、ローカルモビリティドメイン内のフィルタリングエージェントを探索する。フィルタリングエージェントが発見されると、モバイルノードは、フィルタメッセージ４０を使用して、そのルーティングプリファレンスをフィルタリングエージェントに伝送する。

本発明では、ローカルモビリティドメイン内にルーティングプリファレンスが設定されることで、ＭＮは、確実に所望のパス経由でパケットを受信することができるようになる。以下、具体例を用いて、ルーティングプリファレンスがローカルモビリティドメイン内のパケットのパスにどのような影響を与えるかについて説明する。

ＭＮ１０１は、ＣＮ１４０からのパケットがＭＡＧ１１２経由で発送されるべきである旨を示すフィルタルール（ＦＩＤ−ＣＮ）をＬＭＡ１１０に設定したとする。ＬＭＡ１１０は、グローバル通信ドメイン１３経由でＣＮ１４０からのパケットを受信すると、キャッシュをチェックして、ＭＮ１０１がこのパケットフローに関するルーティング設定をセットしているか否かを検証する。ここで、ＬＭＡ１１０は、このパケットフローに一致するフィルタルール（ＦＩＤ−ＣＮ）を特定した場合には、このフィルタルールを遵守してＭＡＧ１１２経由でＭＮ１０１にパケットを発送する。

一方、ＬＭＡ１１０が、このパケットフローに一致するフィルタルールを発見できない場合には、図５に図示されている方法を使用して、ＭＮ１０１に代わってルーティング設定を作成することが可能である。この場合、ＬＭＡ１１０は、パケットの送信元アドレス及びあて先アドレスを用いて、このフィルタルールを作成する。したがって、ＬＭＡ１１０は、ＣＮ１４０（パケットの送信元アドレス）からのパケットはＭＡＧ１１２（パケットのあて先アドレスに関連するＭＡＧアドレス）経由でＭＮ１０１に発送されるべきである旨を指定するフィルタルールを作成する。

また、本発明は、ホームネットワークドメイン１０及びローカルモビリティドメイン１１の両方が同一の管理ドメイン（例えば両方のドメインが同一オペレータによって管理されている）に属しているシステムにおいても適用可能である。このシステムでは、ＭＮ１０１は、非特許文献４や非特許文献５に記載されているようなＨＡにルーティングプリファレンスを伝送する方法を用いる代わりに、本発明に係る方法を用いてＬＭＡ１１０にルーティングプリファレンスを設定することが可能である。本発明を使用することで、ＨＡ１０２とＬＭＡ１１０との間のシグナリングを低減させることが可能となる。これは、ＨＡ１０２が、ＭＮ１０１からＬＭＡ１１０へのルーティングプリファレンス（ローカルモビリティドメイン内でのルーティングに関するプリファレンス）の転送を補助する必要がないことによる。また、ＨＡ１２０は、ＭＮ１０１のルーティングプリファレンスをＬＭＡ１１０に転送する前に、ＭＮ１０１のルーティングプリファレンスを適切なＭＡＧに関連付けてもよい。また、ＨＡ１２０とＬＭＡ１１０が協同して動作可能な環境の場合には、ルーティングプリファレンスに基づくフィルタルールの設定を行う機能をＨＡ１２０が担い、実際にパケットのフィルタリングを行う機能をＬＭＡ１１０が担うように機能の分担が行われてもよい。

また、本発明は、ホームネットワークドメイン１０及びローカルモビリティドメイン１１の両方が同一の管理ドメインに属しているシステムにおいて、ＨＡ１０２及びＬＭＡ１１０が１つのエンティティによって実現されて、各ノードのルーティングプリファレンスが設定されてもよい。この場合においても、ＭＮ１０１は、本発明に係る方法を用いて、このエンティティにルーティングプリファレンスを設定することが可能である。

また、ホームネットワークドメイン１０及びローカルモビリティドメイン１１の両方が異なる管理ドメイン（例えば両方のドメインが異なるオペレータによって管理されている）に属しているシステムであっても、双方のドメインで通信を行って、一方のドメインで保持されているＭＮのフィルタルールを、他方のドメインのフィルタリングエージェントにおいて作動させるようにしてもよい。

また、ＭＮ１０１が複数のインタフェースを同時に接続する場合に、ＬＭＡ１１０が、接続を行っているＭＮ１０１のインタフェースのそれぞれに対してユニークなプレフィックス（各インタフェースに対して固有のプレフィックス）を割り当てることも可能であり、このようなシステムに対しても本発明を適用することが可能である。なお、以下では、このようにＭＮ１０１の複数のインタフェースのそれぞれに対してユニークなプレフィックスを割り当てるシステムを複数プレフィックスモデルと呼ぶことにする。

例えば、ＭＮ１０１が、ローカルモビリティドメイン１１のＭＡＧ１１１及びＭＡＧ１１２へ同時に接続した場合、複数プレフィックスモデルでは、ＬＭＡ１１０は、ＭＡＧ１１１に対してプレフィックス（Ｐ１）をＭＮ１０１へ通知するよう指示し、同様に、ＭＡＧ１１２に対してプレフィックス（Ｐ２）（プレフィックス（Ｐ１）とは異なるプレフィックス）をＭＮ１０１へ通知するよう指示することが可能である。これにより、ＭＮ１０１は、ローカルモビリティドメイン１１へ接続された状態で、各インタフェースにおいて異なるプレフィックスを検出する。

このような複数プレフィックスモデルのシステムにおいて、ＬＭＡ１１０は、ＭＮ１０１へのプレフィックスの通知を行うエンティティを変更してもよい（すなわち、ＭＡＧと、ＭＡＧが通知するプレフィックスとの対応を変更してもよい）。例えば、上述のようにＭＡＧ１１１がプレフィックス（Ｐ１）を通知し、ＭＡＧ１１２がプレフィックス（Ｐ２）を通知する状態において、ＬＭＡ１１０は、ＭＡＧ１１１に対してプレフィックス（Ｐ２）を通知するよう指示し、ＭＡＧ１１２に対してプレフィックス（Ｐ１）を通知するよう指示してもよい。こうしたプレフィックス通知の変更は、任意の条件に基づいて行われるものであり、例えば、ＬＭＡ１１０又はローカルモビリティドメイン１１内のその他のネットワークエンティティ制御装置が、ローカルモビリティドメイン１１のネットワーク管理を行う必要がある場合に行われる。

このような複数プレフィックスモデルのシステムに本発明を適用し、ＭＮ１０１が、本発明に係る方法を利用して所望のルーティングプリファレンスをネットワーク側へ通知することで、ＭＮ１０１のインタフェースで使用するプレフィックスをＭＮ１０１自身が指定することが可能となる。ＬＭＡ１１０は、ＭＮ１０１が所望するルーティングプリファレンスに基づいてプレフィックス通知の変更を行い、その結果、ＭＮ１０１のルーティングプリファレンスに基づくフィルタルールに従って、ＭＮ１０１へのパケット発送が行われるようになる。

本発明を適用した場合、ＭＮ１０１は、どのインタフェースでどのプレフィックスを使用するかを示す情報を所望のルーティングプリファレンスとしてネットワーク側へ通知することが可能である。例えば、上述のようにＭＡＧ１１１がプレフィックス（Ｐ１）を通知し、ＭＡＧ１１２がプレフィックス（Ｐ２）を通知する状態において、ＭＮ１０１は、ＭＡＧ１１１に接続されているインタフェースでプレフィックス（Ｐ２）を使用し、ＭＡＧ１１２に接続されているインタフェースでプレフィックス（Ｐ１）を使用することを所望するルーティングプリファレンスを、フィルタメッセージ４０を使用してネットワーク側へ通知することが可能である。ＬＭＡ１１０は、ＭＮ１０１によって通知されたルーティングプリファレンスに従って、ＭＡＧ１１１に対してプレフィックス（Ｐ２）をＭＮ１０１へ通知するよう指示するとともに、ＭＡＧ１１２に対してプレフィックス（Ｐ１）をＭＮ１０１へ通知するよう指示する。その結果、ＭＮ１０１は、ＭＡＧ１１１に接続されているインタフェースでプレフィックス（Ｐ２）を使用し、ＭＡＧ１１２に接続されているインタフェースでプレフィックス（Ｐ１）を使用することが可能となる。なお、プレフィックスの対応付けの変更のほかに、特定の条件のパケットのフローのみを変更するためにプリファレンス情報を用いる方法を複数プレフィックスモデルにおいて適用することも可能である。

また、複数プレフィックスモデルにおいて、ＬＭＡ１１０からＭＮ１０１へ割り当てられた複数のプレフィックスの一部又はすべてを、より上位のプレフィックス（よりプレフィックス長の短いプレフィックス）へ関連付けることも可能である。すなわち、ＭＮ１０１へ割り当てられたプレフィックスのうち、共通のビット配列を有する複数のプレフィックスは、この共通のビット配列（上位プレフィックス）によって表されるようにしてもよい。また、ＭＮ１０１へのプレフィックスの割り当てが効率良く行われた場合には、ＭＮ１０１へ割り当てられたすべてのプレフィックスを単一の上位プレフィックスで表すことも可能となり、この場合には単一プレフィックスモデルへ還元可能となる。このような場合には、ＬＭＡ１１０は、上位プレフィックスを使用して、ローカルモビリティドメイン１１内におけるＭＮ１０１へのパケットルーティングを行うことが可能である。

上記のように、ＭＮ１０１へ割り当てられた複数のプレフィックスを単一の上位プレフィックスで表現することで、複数プレフィックスモデルを単一プレフィックスモデルへ還元した場合には、ＬＭＡ１１０が、ＭＮ１０１のルーティングプリファレンスに基づいて設定されたパスとは異なるルーティングパス経由で、ＭＮ１０１へパケットを発送してしまう場合も起こり得る。

例えば、ＭＮ１０１が２つのインタフェースを介してローカルモビリティドメイン１１へ接続されており、各インタフェースに６５ビットのプレフィックス（Ｐａ、Ｐｂ）が割り当てられているとする。２つのインタフェースのそれぞれに割り当てられているプレフィックス（Ｐａ、Ｐｂ）が６４ビットの共通ビット配列（Ｐｃ）を有し、末尾の６５ビット目の値が異なるような場合には、ＭＮ１０１は、ＭＮ１０１へ割り当てられている２つのプレフィックス（Ｐａ、Ｐｂ）を６４ビットの共通ビット配列（Ｐｃ）で表すことが可能である。すなわち、プレフィックス（Ｐａ、Ｐｂ）は、共通する６４ビットの上位プレフィックス（Ｐｃ）と、末尾の６５ビット目（Ｐａ、Ｐｂでそれぞれ異なる値）とを有している。

また、ＭＮ１０１は、この上位プレフィックスを気付プレフィックスとしてＨＡ１０２へ登録することも可能である。しかしながら、例えば、あるフローＩＤ（ＦＩＤａ）がプレフィックス（Ｐａ）を含む気付アドレスへ送信されるようにするプリファレンスをＭＮ１０１がＨＡ１０２へ設定している場合であっても、ＬＭＡ１１０は、そのプリファレンスを把握できないため、ＬＭＡ１１０で、ＭＮ１０１のプリファレンスに従わないパケット発送（例えば、あるフローＩＤ（ＦＩＤａ）に係るパケットを、プレフィックス（Ｐｂ）を通知しているＭＡＧ１１１経由で転送）を行ってしまう可能性がある。

このような場合に対処するため、ＭＮ１０１が、本発明に係る方法を利用して、上位プレフィックスで表されている各プレフィックスに対するルーティングプリファレンスをＬＭＡ１１０へ設定することが有効である。これにより、ＬＭＡ１１０は、ＭＮ１０１が所望するルーティングプリファレンスに基づいたフィルタルールに従って、ＭＮ１０１へのパケット発送を正しく行うことが可能となる。

また、本発明に係る方法を利用して、ローカルモビリティドメイン１１内のフィルタリングエージェント（ＬＭＡ１１０又は何らかのポリシサーバ）がＭＮ１０１のルーティングプリファレンスを把握し、このルーティングプリファレンスに基づいて設定されるフィルタルールに従ってフローフィルタリングを行うことが可能な場合であっても、フィルタリングエージェントは、ＭＮ１０１のルーティングプリファレンスに意図的に従わずに、ＭＮ１０１へパケットを発送する場合も起こり得る。例えば、ＬＭＡ１１０は、ローカルモビリティドメインのネットワーク状態をより正確に把握できる場所に配置されているため、例えばＭＡＧ１１１が過負荷状態にあることを検出できる可能性がある。このような場合に、ＬＭＡ１１０は、ローカルモビリティドメイン１１内の負荷バランスを行うため、ＭＡＧ１１１を経由するパケットの一部をＭＡＧ１１２経由に切り替えるルーティングパスの切り替えを行うことも考えられる。

こうしたネットワーク側におけるルーティングパスの切り替え動作は、ＭＮ１０１にとっては、ＬＭＡ１１０がＭＮ１０１のルーティングプリファレンスを把握できていないように見える。その結果、ＭＮ１０１では、ＬＭＡ１１０におけるフィルタルールの設定（例えば、ルーティングプリファレンスの再通知）の動作が開始される。しかしながら、ＬＭＡ１１０は、ＭＮ１０１のルーティングパスを意図的に変更しているため、ＭＮ１０１の新たなルーティングプリファレンスの通知を受けたとしても、このルーティングプリファレンスの受け入れを拒否するかあるいは無視して、ＭＮ１０１のルーティングプリファレンスとは異なるルーティングパスを経由してパケット発送を行い続ける可能性が高い。

このように、ＭＮ１０１が、ＬＭＡ１１０によってルーティングパスの切り替えが意図的に行われていることを把握できずに、ルーティングプリファレンスを含むフィルタメッセージをネットワーク側へ送信してしまう場合に対処するため、ＬＭＡ１１０は、ルーティングパスの変更を行った場合に、その意図（すなわち、ルーティングパスの変更がＬＭＡ１１０によって意図的に行われた旨）をＭＮ１０１へ通知できるように構成されていてもよい。

このようなＬＭＡ１１０の意図をＭＮ１０１へ通知する方法として、例えばＬＭＡ１１０がＭＮ１０１あてのパケットを転送する前に、そのパケットにマークを付ける方法が可能である。このマークは、ＬＭＡ１１０が意図的にＭＮ１０１へのパケットのルーティングパスを切り替えていることを示しており、ＭＮ１０１は、パケットを受信した際にこのマークが付加されていることを確認することで、ＬＭＡ１１０が意図的にＭＮ１０１へのパケットのルーティングパスを切り替えていることを把握できるようになる。

図７には、本発明の好適な実施の形態において、パケットのルーティングパスが意図的に変更されていることをモバイルノードへ通知するためのマークが付加されたデータパケットのフォーマットの一例が図示されている。

図７において、データパケット７０は、パケットヘッダ７０１、ペイロード７０２、パス変更フィールド７０３を有している。なお、図７では、パス変更フィールド７０３がパケットの最後尾に存在しているが、パス変更フィールド７０３はパケットの内の任意の位置に配置可能であり、例えば、パケットヘッダ７０１内にパス変更フィールド７０３が配置されてもよい。

パケットヘッダ７０１には、ＩＰｖ４アドレス又はＩＰｖ６アドレスによって構成されるメッセージの送信元やあて先の情報（送信者のアドレスや受信者のアドレス）、メッセージのタイプを示すタイプフィールド、メッセージの長さを示す長さフィールドなどが含まれている。

また、ペイロード７０２には、通常はモバイルノードにとって有用なデータが含まれている。ペイロード７０２に含まれるデータは、例えば、音声、動画、メッセージなどであるが、その他の種類のデータであってもよく、また、データが何も含まれていなくてもよい。

また、パス変更フィールド７０３は、パケットのルーティングパスが意図的に変更されていることを示す値を設定するためにＬＭＡ１１０が付加するフィールドである。パス変更フィールド７０３に特定の値が設定されることによって、ＭＮ１０１へのパケットのルーティングパスが意図的に切り替えられていることをＭＮ１０１へ通知することが可能となる。

なお、パス変更フィールド７０３は、デフォルト値を“０”（ビットフラグが設定されていない状態）とする単一のビットフラグによって実現されることが望ましい。パケットのルーティングパスが意図的に変更されたことを示す場合には、このパス変更フィールド７０３に設定される値は“１”に変更される（ビットフラグが設定された状態）。なお、パス変更フィールド７０３における値の設定は、ＭＮ１０１のパケットのルーティングを行うＬＭＡ１１０以外のエンティティ（例えば、ＭＡＧ）などによって行われてもよい。

ＭＮ１０１は、データパケット７０を受信すると、データパケットの処理を行ってパス変更フィールド７０３の設定値（ビットフラグ）を参照することで、ローカルモビリティドメイン１１内でルーティングパスが意図的に変更されているかどうかを確認できるようになる。

また、図８には、本発明の好適な実施の形態において、ルーティングパスが意図的に変更されているかどうかをＭＮ１０１が確認するためのデータパケット処理の一例を示すフローチャートが図示されている。

図８において、ステップＳ８０でＭＮ１０１がデータパケット７０を受信することによって、このデータパケット処理が開始される。データパケットを受信した場合、ＭＮ１０１は、ステップＳ８１において、このデータパケットがＭＮ１０１のルーティングプリファレンスに従って発送されているかどうか（すなわち、ルーティングポリシに係る要件が満たされているかどうか）をチェックする。データパケットがＭＮ１０１のルーティングプリファレンスに従って発送されていることが確認できた場合には、ステップＳ８６において、ＭＮ１０１はこのデータパケット処理を終了し、このデータパケットに関して更なる処理（通常のデータパケット処理）を行う。

一方、データパケットがＭＮ１０１のルーティングプリファレンスに従って発送されていないことが分かった場合には、ＭＮ１０１は、ステップＳ８２において、ルーティングパスの切り替えが意図的に行われていることを示すマークがデータパケットに付加されているかどうか（すなわち、上記のパケットフォーマットの一例において、パス変更フィールド７０３のビットフラグが設定されているか否か）を確認する。

なお、ルーティングプリファレンスに従って発送されているかどうかのチェック（ステップＳ８１）と、ルーティングパスの切り替えが意図的に行われていることを示すマークがデータパケットに付加されているかどうかの確認（ステップＳ８２）は、処理順序が逆であってもよい。

ステップＳ８２において、ルーティングパスの切り替えが意図的に行われていることを示すマークがデータパケットに付加されていることが確認できた場合には、ＭＮ１０１は、ステップＳ８３において、この結果に基づいてルーティングポリシを更新する。

ルーティングポリシの更新を行う方法としては、例えば、現在のルーティングパス（すなわち、ネットワーク側で意図的に切り替えられたルーティングパス）を反映するように、ＭＮ１０１がルーティングポリシの変更を行うことが挙げられる。例えば、ＭＮ１０１のルーティングポリシでは、データパケット７０はＭＡＧ１１１経由でＭＮ１０１に到達するはずであるが、ＬＭＡ１１０が意図的にＭＡＧ１１２経由でデータパケット７０の発送を行っており、ルーティングパスの切り替えが意図的に行われていることを示すマークがデータパケット７０に付けられているとする。この場合、ＭＮ１０１は、このデータパケット７０を受信すると、ＬＭＡ１１０による意図的なルーティングパスの切り替えを把握し、以降データパケット７０として受信する同一フローのパケットに関して、そのルーティングパスがＭＡＧ１１２経由となるようルーティングポリシを更新する。

ＭＮ１０１でルーティングポリシが更新されると、ＭＮ１０１は、ステップＳ８４において、更新されたルーティングポリシに基づくルーティングプリファレンスを作成し、ＬＭＡ１１０におけるフィルタルールを更新するために、このルーティングプリファレンスを含むフィルタメッセージ４０を送信する処理を行う。ＬＭＡ１１０におけるフィルタルールの更新を行うことで、ＬＭＡ１１０で設定されているフィルタルールとＭＮ１０１におけるルーティングポリシとが同期し、ローカルモビリティドメイン１１内におけるＭＮ１０１へのパケットルーティングがより効率的に行われるようになるという利点がある。ＭＮ１０１は、ＬＭＡ１１０におけるフィルタルールの更新を行うと、ステップＳ８６において、このデータパケット処理を終了し、このデータパケットに関して更なる処理（通常のデータパケット処理）を行う。

一方、ステップＳ８２において、ルーティングパスの切り替えが意図的に行われていることを示すマークがデータパケットに付加されていることが確認できなかった場合には、ＭＮ１０１は、ＬＭＡ１１０がＭＮ１０１のルーティングプリファレンスを把握していないと判断する。この場合、ＭＮ１０１は、ステップＳ８５において、ＭＮ１０１のルーティングプリファレンスを含むフィルタメッセージ４０をＬＭＡ１１０へ送信する。なお、この場合のＭＮ１０１のルーティングプリファレンスは、本来はＬＭＡ１１０によって把握及び反映されているはずのものであり、ステップＳ８５の処理は、ＭＮ１０１のルーティングプリファレンスをＬＭＡ１１０に再設定する処理である。そして、フィルタメッセージ４０の送信処理が終了すると、ＭＮ１０１は、ステップＳ８６において、このデータパケット処理を終了し、このデータパケットに関して更なる処理（通常のデータパケット処理）を行う。

なお、ルーティングパスの切り替えが意図的に行われていることを示すマークは、該当するすべてのパケットに付加されるのではなく、一部に付加されてもよい。この場合、上述の図８に示す動作もそれに対応して、複数のパケットをサンプリングしたうえで最終判断を行うようにすることが望ましい。また、ルーティングパスの切り替えが意図的に行われるのは、特定のフローとしてこれまで扱っていたものを一括で変更する場合だけではなく、例えば、負荷分散などを目的としてフローの一部を変更する場合もあり得る。この場合は、プリファレンスに一致するパケットと一致しないパケットが並行して検出されることになるが、それが意図的に行われているかどうかが不明であるときには本発明が同様に動作し、適切な処理を行うことができる。また、ルーティングパスの切り替えが意図的に行われていることが確認できた際に変更するルーティングポリシの変更方法は、変更されたルーティングパスを反映するように変更するほかに、追加のルーティングポリシとして設定することもできる。これにより、ネットワーク側の意図的ではあるが一時的であるような切り替えや、負荷分散のための部分的な変更にも容易に対応できるようになる。また、上述の図８に示す動作では、ＬＭＡ１１０が、ステップＳ８４でＭＮ１０１から送信されたルーティングプリファレンスに基づいてＭＮ１０１に係るフィルタルールを更新しているが、例えば、ＬＭＡ１１０がルーティングパスの意図的な切り替えを行うとともに、ＭＮ１０１に関するフィルタルールを更新することも可能である。この場合、ＬＭＡ１１０は、ＬＭＡ１１０（又はポリシサーバ）においてＭＮ１０１に係るフィルタルールが更新されたことをＭＮ１０１へ通知することが望ましく、例えば、上述の図７に図示されているパケットフォーマットを利用し、データパケット７０のパス変更フィールド７０３を用いてＬＭＡ１１０（又はポリシサーバ）においてＭＮ１０１に係るフィルタルールが更新されたことを通知してもよい。

ＬＭＡ１１０（又はポリシサーバ）においてＭＮ１０１に係るフィルタルールが更新されたことをＭＮ１０１へ通知することによって、ＭＮ１０１は、ローカルモビリティドメイン１１内（例えば、ＬＭＡ１１０又はポリシサーバ）に設定されているＭＮ１０１のフィルタルールが変更されたことを把握することが可能となる。これにより、ＭＮ１０１は、ローカルモビリティドメイン１１内に設定されているＭＮ１０１に係るフィルタルールの更新（フィルタルールの同期化）を行うためにフィルタメッセージ４０を送信する動作（図８のステップＳ８４の処理）を行う必要がないという利点がある。

また、データパケット７０のパス変更フィールド７０３を利用して、ローカルモビリティドメイン１１のネットワーク状態に関する情報がＭＮ１０１へ通知されてもよい。このネットワーク状態に関する情報は、例えば、別の適切なパスを特定するために有用な情報であり、このネットワーク状態に関する情報に基づいて、ＭＮ１０１がより適切なルーティングパスを経由したデータパケットの送受信を行えるようにするために有用な情報である。

例えば、ＭＮ１０１がローカルモビリティドメイン１１内の別のモバイルアクセスゲートウェイへ接続可能であり、ローカルモビリティドメイン１１のネットワーク状態に関する情報として、例えば、別のモバイルアクセスゲートウェイに接続可能であることを示す情報、又は、別のモバイルアクセスゲートウェイ経由のパケット伝送のほうが効率的な伝送が実現されることを示す情報などを受信したとする。ＭＮ１０１は、上記のようなＬＭＡ１１０から通知されたネットワーク状態に関する情報に基づき、ＭＡＧ１１２よりむしろ別のモバイルアクセスゲートウェイを選択して、以降のデータパケット７０の送受信を行うようにすることが可能である。

さらに、データパケット７０内のパス変更フィールド７０３を利用して、ＬＭＡ１１０のフィルタルールを変更するのではなく、ＨＡ１０２のフィルタルールを変更するようＭＮ１０１に要求する旨が通知されるようにしてもよい。このような通知は、例えば、ＭＮ１０１がローカルモビリティドメイン１１内の複数のローカルモビリティアンカに接続されており、これらのローカルモビリティアンカがＭＮ１０１によって設定されるフィルタルールを同期化するリソース又は機能を有していない場合に有用である。ＨＡ１０２のフィルタルールの変更を要求する情報がパス変更フィールド７０３に設定されていた場合には、ＭＮ１０１は、図８のステップＳ８４の処理において、ローカルモビリティドメイン１１内（例えばＬＭＡ１１０）のフィルタルールを更新するためにルーティングプリファレンスを送信する代わりに、ＨＡ１０２のフィルタルールを更新するためにルーティングプリファレンスを送信する処理を行う。

また、ＭＮ１０１側から、ルーティングパスの切り替えが必要となった場合に選択可能なルーティングパス（バックアップルーティングパス）に関する情報をローカルモビリティドメイン１１へ通知できるようにしてもよい。この場合、例えば、ＭＮ１０１は、ルーティングパスの切り替えが必要となった場合に選択可能なバックアップルーティングパスに関する情報をフィルタメッセージ４０内のプリファレンスオプション４０２に挿入することによって、この情報を通知してもよい。

さらに、ＭＮ１０１は、ローカルモビリティドメイン１１内の様々なルーティングパスに優先順位を設定し、ＬＭＡ１１０が、この優先順位に基づいてルーティングパスの選択を行えるようにしてもよい。例えば、ＭＮ１０１は、ＣＮ１４０からの特定のフローに関して、ＭＡＧ１１１経由で発送されることを最優先とする最優先プリファレンス（第１プリファレンス）と、ＭＡＧ１１２経由で発送されることを２番目に優先する第２のプリファレンスとをＬＭＡ１１０へ通知する。この場合、ＬＭＡ１１０は、ＭＮ１０１へ転送すべきＣＮ１４０からのフローに関するパケットを受信すると、ＭＮ１０１が所望する第１プリファレンスに従って（すなわち、ＭＡＧ１１１経由で）パケットを発送する。また、例えばＭＡＧ１１１が過負荷状態となった場合などには、ＬＭＡ１１０は、ＭＮ１０１が所望する第２プリファレンスに従って（ＭＡＧ１１２経由で）パケットを発送する。

このようにＭＮ１０１がルーティングパスに優先順位を設定することによって、ＭＮ１０１は、ＬＭＡ１１０が第１プリファレンス以外のルーティングパスを使用してパケット発送を行った場合には、ローカルモビリティドメイン１１内で何らかのルーティング問題（第１プリファレンスに従ったルーティングが行われなくなるような問題）が生じていることを把握できるようになる。この結果、ＭＮ１０１は、第１プリファレンスに従ったルーティングが行われなくなった場合に、ルーティングパスがＬＭＡ１１０によって意図的に切り替えられていることを把握することが可能となり、また、ローカルモビリティドメイン１１内に設定されているＭＮ１０１に係るフィルタルールの更新（フィルタルールの同期化）を行うためにフィルタメッセージ４０を送信する動作（図８のステップＳ８４の処理）を行う必要がない。

このように、ＬＭＡ１１０が、例えばローカルモビリティドメイン１１内の負荷バランス、又は、ローカルモビリティドメイン内の障害などの様々な問題に応じて、ＭＮ１０１へのパケットのルーティングパスを意図的に切り替える状況も起こり得る。しかしながら本発明では、ルーティングパスの切り替えが意図的なものか否かをＭＮ１０１が把握できるようにし、ローカルモビリティドメイン１１におけるルーティングパスの切り替えの意図をＭＮ１０１が確実に把握できるようにすることが可能である。

なお、ＭＮは、ネットワークドメインの構成がどのようなものであるかを確認したうえで本発明の動作を開始することが望ましい。例えば、接続認証の過程などから、自身がホームドメイン以外のローカルモビリティドメインにいることを検知したり、接続しているローカルモビリティドメインがＨＡとＬＭＡとを分離した構成を有していることを検出したり、また、ネットワークからＨＡとは異なるネットワークノードにルーティングプリファレンスを通知するように指示を受けたりすることによって、ＭＮはその動作を変えることができるように構成されていてもよい。

また、本明細書では、本発明が最も実用的かつ好適な実施例となるように考慮されて図示及び説明されているが、当業者であれば、上述の各ノードの構成要素に係る設計やパラメータの詳細において、発明の範囲から逸脱しない程度に様々な変更が行われてもよいことは明白である。

例えば、本明細書では、ローカルモビリティドメイン内のＬＭＡ又はポリシサーバのどちらかがフィルタリングエージェントである場合を例示しているが、ＬＭＡ及びポリシサーバの両方の機能を備えた単一のエンティティとして、フィルタリングエージェントが実現されてもよい。

また、本明細書では、主に複数のネットワークインタフェース２０１を有するＭＮ２００に関して言及しているが、ネットワークインタフェース２０１を１つしか有さないＭＮ２００に係るフィルタルール（ＭＮ２００のプリファレンスに基づくフィルタルール）が、ネットワークベースのモビリティ管理ドメイン内のフィルタリングエージェントに設定されるようにする場合においても、本発明の適用が可能である。

また、本明細書では、ＭＮのネットワークインタフェース２０１がレイヤ１及びレイヤ２のコンポーネントを含んでいる構成例を挙げて説明を行っているが、各レイヤが分離されていてもよく、その数もそれぞれ独立に構成されていてもよい。例えば、１つの無線部を複数の接続方式で共用し、ネットワークインタフェースの観点からはその変化が問題にならない程度の速度で切り替えたり、レイヤ２で論理的なリンクを維持したりすることにより、ネットワーク部からは複数のインタフェースを介してネットワークに接続している場合と同等に動作できるよう構成されていてもよい。

また、ここでは、図示されているような簡単なネットワーク構成に基づいて本発明の説明を行ったが、ローカルネットワークドメインの構成は、複数オペレータ間のローミング関係も含めて多岐に渡ることが考えられる。例えば、ＭＡＧがＭＮの直接的なアクセスルータである構成や、ＭＡＧが異なるアクセスネットワーク（ローミングを含む）との境界ルータであり、ＭＮはいったんその異なるアクセスネットワークに接続した後、そのアクセスネットワークを介して境界ルータであるＭＡＧに接続するという構成が考えられる。しかしながら、いずれの構成又は条件の場合においても、様々なパラメータや端末からＭＡＧへの到達手順、端末の通信手順などの設計部分が異なるものの、本発明の動作に関しては同様に適用可能であることは明白である。

なお、ＭＮ（移動端末）は複数の通信デバイスから構成されるものであってもよい。例えば、移動端末は、パーソナルコンピュータなどの電子計算機に外挿型あるいは組み込み型の３ＧＰＰ通信用デバイスモジュール及び／又は非３ＧＰＰ通信デバイスモジュールを装着する場合などがあり、こうした多様な移動端末においても本発明は同等の効果を有するものである。

なお、上記の本発明の実施の形態の説明で用いた各機能ブロックは、典型的には集積回路であるＬＳＩ（Large Scale Integration）として実現される。これらは個別に１チップ化されてもよいし、一部又はすべてを含むように１チップ化されてもよい。なお、ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ（Integrated Circuit）、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。

また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。

さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオ技術の適応などが可能性としてあり得る。

本発明は、移動端末がホームネットワークドメインではないネットワークベースのモビリティ管理ドメインに接続している場合に、移動端末のプリファレンスに基づいたルーティングを効率良く実現するという効果を有しており、ＩＰを利用した通信技術や、フィルタルールに基づくフローフィルタリング技術などに適用可能である。

従来の技術及び本発明の実施の形態において参照されるネットワークベースのモビリティ管理システムの構成の一例を示す図 本発明の実施の形態におけるモバイルノードの構成の一例を示す図 本発明の実施の形態において、アプリケーションに関連するルートポリシによる処理の一例を示すフローチャート 本発明の実施の形態において、ローカルモビリティドメイン内にルーティングプリファレンスを設定するために使用されるフィルタメッセージのフォーマットの一例を示す図 本発明の実施の形態において、ＭＡＧによって実行されるリバースパケットフロー仮定に関するフローチャート 本発明の実施の形態において、ＭＮに代わってルーティングプリファレンスの設定が可能なＭＡＧ又はフィルタリングエージェントに実装されている機能を示すブロック図 本発明の実施の形態において、パケット経路として選択されるルーティングパスが意図的に変更されたことをモバイルノードへ通知するために使用されるデータパケットのフォーマットの一例を示す図 本発明の実施の形態において、受信したデータパケットの処理の際に、ネットワーク側でルーティングパスが意図的に変更されたかどうかをモバイルノードが判断するための処理の一例を示すフローチャート

Claims (18)

1. ネットワークベースのモビリティ管理プロトコルが実行されているネットワークを有する通信システムであって、
   前記ネットワークに接続されている移動端末の通信のプリファレンス情報が、前記ネットワーク内で前記移動端末の通信に係るフローフィルタリングを行っているフィルタリングエージェントに通知されるように構成されている通信システム。
2. 前記移動端末が、前記移動端末のパケットのフローが所望のルーティングパスを経由しているか否かを判断し、前記移動端末のパケットのフローが前記所望のルーティングパスを経由していないと判断された場合には、前記所望のルーティングパスを実現するフィルタルールを設定するための前記プリファレンス情報を前記フィルタリングエージェントに通知するように構成されている請求項１に記載の通信システム。
3. 前記フィルタリングエージェントにおいて前記移動端末のパケットのフローにフィルタルールが設定されていない場合には、前記フィルタリングエージェントが、前記パケットのフローに対して前記プリファレンス情報に基づくフィルタルールを設定するように構成されている請求項２に記載の通信システム。
4. 前記フィルタリングエージェントにおいて前記移動端末から通知された前記プリファレンス情報を実現するフィルタルールとは異なるフィルタルールが設定されている場合に、前記フィルタリングエージェントが、前記ルートポリシ設定手段が、前記パケットのフローに対するフィルタルールを、前記プリファレンス情報に基づくフィルタルールに変更するように構成されている請求項２に記載の通信システム。
5. 前記移動端末が、複数のパケットのフローをそれぞれインタフェース単位又はプレフィックス単位で管理しており、前記プリファレンス情報として、パケットのフローの受信を所望するインタフェース又はプレフィックスを用いるように構成されている請求項１に記載の通信システム。
6. ネットワークベースのモビリティ管理プロトコルが実行されているネットワークに接続する移動端末であって、
   １つ又は複数のインタフェースと、
   前記インタフェースが前記ネットワークに接続されている状態で、前記インタフェースによる通信のプリファレンス情報に基づくフローフィルタリングが行われるように、前記プリファレンス情報を前記ネットワークに通知するプリファレンス通知手段とを、
   有する移動端末。
7. 前記プリファレンス情報が存在しない場合には、パケットの送受信が同一インタフェースで行われるように設定を行う送受信設定手段を有する請求項６に記載の移動端末。
8. 前記プリファレンス通知手段が、前記インタフェースが接続されている接続ゲートウェイであって、前記ネットワーク内で前記移動端末の通信に係るフローフィルタリングを行っているフィルタリングエージェントに前記プリファレンス情報を転送する機能を有する前記接続ゲートウェイに対して、前記プリファレンス情報を通知するように構成されている請求項６に記載の移動端末。
9. 前記ネットワーク内で前記移動端末の通信に係るフローフィルタリングを行っているフィルタリングエージェントを探索する探索手段を有し、
   前記プリファレンス通知手段が、前記探索手段で探索された前記フィルタリングエージェントに対して前記プリファレンス情報を直接通知するように構成されている請求項６に記載の移動端末。
10. 自身のホームドメインとは異なるローカルモビリティドメインに接続されているか否かを確認する接続ドメイン確認手段と、
    前記接続ドメイン確認手段によって自身のホームドメインとは異なるローカルモビリティドメインに接続されていることが確認された場合に、前記プリファレンス通知手段による前記プリファレンス情報の通知を行うように制御する通知制御手段とを、
    有する請求項６に記載の移動端末。
11. 接続している自身のホームドメインであるローカルモビリティドメインにおいて、モバイルＩＰによるモビリティ管理を行うホームエージェントと、前記移動端末の通信に係るフローフィルタリングを行っているフィルタリングエージェントとが同一の装置によって実現されているか、あるいは、別々の装置によって実現されているかを確認する構成確認手段と、
    前記構成検出手段によって前記ホームエージェントと前記フィルタリングエージェントとが別々の装置によって実現されていることが確認された場合に、前記プリファレンス通知手段による前記プリファレンス情報の通知を行うように制御する通知制御手段とを、
    有する請求項６に記載の移動端末。
12. パケットのフローが前記プリファレンス情報に一致する所望のルーティングパスを経由しているか否かを判断するフロー判断手段と、
    前記パケットのフローが前記所望のルーティングパスを経由していないと判断された場合には、前記プリファレンス通知手段が、前記所望のルーティングパスを実現するフィルタルールを設定するための前記プリファレンス情報を前記フィルタリングエージェントに通知するように構成されている請求項６に記載の移動端末。
13. 複数のパケットのフローをそれぞれインタフェース単位又はプレフィックス単位で管理するフロー管理手段を有し、
    前記プリファレンス通知手段が、前記プリファレンス情報として、パケットのフローの受信を所望するインタフェース又はプレフィックスを用いるように構成されている請求項６に記載の移動端末。
14. ネットワークベースのモビリティ管理プロトコルが実行されているネットワーク内に存在するネットワークノードであって、
    前記移動端末から通知されたプリファレンス情報を受信するプリファレンス受信手段と、
    前記プリファレンス受信手段で受信した前記プリファレンス情報に基づいて、前記移動端末のパケットのフローに対してフィルタルールを設定するルートポリシ設定手段とを、
    有するネットワークノード。
15. 前記ネットワークに接続されている移動端末のパケットのフローにフィルタルールが設定されていないことを把握するフィルタ未設定把握手段を有し、
    前記ルートポリシ設定手段が、前記フィルタ未設定把握手段で把握された前記パケットのフローに対して、前記移動端末から通知された前記プリファレンス情報に基づくフィルタルールを設定するよう構成されている請求項１４に記載のネットワークノード。
16. 前記移動端末から通知された前記プリファレンス情報を実現するフィルタルールとは異なるフィルタルールが設定されている場合に、前記ルートポリシ設定手段が、前記パケットのフローに対するフィルタルールを、前記プリファレンス情報に基づくフィルタルールに変更するように構成されている請求項１４に記載のネットワークノード。
17. 前記ルートポリシ設定手段が、前記パケットのフローに関して、前記移動端末からパケットが送信されるフロー方向と、前記移動端末にパケットが到達するフロー方向とが同一となるように前記フィルタルールを設定するように構成されている請求項１４に記載のネットワークノード。
18. 前記ネットワークノードが前記フローの通信に係るフローフィルタリングを行っているフィルタリングエージェント以外のノードの場合には、前記移動端末から通知された前記プリファレンス情報を前記フィルタリングエージェントに通知・登録するプリファレンス通知手段を有する請求項１４に記載のネットワークノード。

Images