JP5485345B2 - 移動端末並びに移動端末により実行される方法 - Google Patents

Description

本発明は、インターネットプロトコル（ＩＰ：Internet Protocol）を利用した通信技術に係る移動端末並びに移動端末により実行される方法に関し、特に、フローの経路を変更する処理を行うための移動端末並びに移動端末により実行される方法に関する。

例えば下記の非特許文献１には、モバイルＩＰｖ６（ＭＩＰｖ６）を使用することで、モバイルノード（ＭＮ：Mobile Node）が自身のホームエージェント（ＨＡ：Home Agent）に対して、気付アドレス（ＣｏＡ：Care-of Address）とホームアドレス（ＨｏＡ：Home Address）とを関連付けて登録する技術が開示されている。この技術によれば、モバイルノードがホームネットワークから離れた位置に存在している場合であっても、そのモバイルノードの到達可能性が実現される。

一方、複数のネットワークインタフェースが組み込まれた携帯電子機器が実装されることで、現在、モバイルノードにおいて、所定のホームエージェントアドレスに対して複数のＣｏＡ（multiple CoA）を登録する機能が実現されている。この登録方法に関しては、現在、ＩＥＴＦ（Internet Engineering Task Force）のＭｏｎａｍｉ６（Mobile Nodes and Multiple Interfaces in IPv6）ワーキンググループで議論されている。

また、下記の非特許文献２には、１つのＨｏＡに対する複数のバインディングを区別するための識別番号（ＢＩＤ：Binding Unique Identification）を導入することによって複数ＣｏＡの登録を可能にする技術が開示されている。ＢＩＤは、モバイルノードのある１つのホームアドレス（ＨｏＡ）に関連付けられているインタフェース又はＣｏＡのいずれかに対して割り当てられる。したがって、ＨｏＡはモバイルノードに関連付けられている一方、ＢＩＤはモバイルノードによって登録された各バインディングを識別する。モバイルノードは、バインディングアップデート（ＢＵ：Binding Update）によって、自身のホームエージェントにＢＩＤの通知を行い、ホームエージェントはバインディングキャッシュ内にＢＩＤを記録する。

さらに、下記の非特許文献３には、モバイルノード／ルータがホームエージェントにプレファレンス情報を設定することで、複数のＣｏＡを用いたトラフィックフローのルーティングを選択的に行うことが可能となる旨が記載されている。各トラフィックフローをユニークなフロー識別情報（ＦＩＤ：Flow Identification）で識別することによって、モバイルノード／ルータは、特定のトラフィックフローがルーティングされるべきＣｏＡを選択し、適切なＢＩＤに対してＦＩＤを関連付けてＨＡに登録することが可能である。

しかしながら、トラフィックフロー経路に関するプレファレンスの設定は、常にモバイルノード／ルータによって行われるわけではない。ある状況においては、トラフィックフローの適切な経路を選択する動作が、モバイルノード／ルータと通信を行っているサービスプロバイダによって行われる場合がある。例えば、モバイルノードのユーザがサービスプロバイダからｉモード（登録商標）を受けているとする。ｉモード（登録商標）のトラフィックは、ドメイン内に制限されたトラフィックフローであり、このトラフィックフローはサービスプロバイダの信頼ネットワーク内でのみ伝送される。なお、後述のように、本明細書では、あるドメイン内でのみ伝送が行われるように制限されたトラフィックフローをドメイン限定フローと呼ぶ。このような場合には、例えばサービスプロバイダに属するエンティティ（例えばＨＡ）が、ドメイン限定フローの発送方法を規定してモバイルノードに通知する。このような情報の通知によって、サービスプロバイダは、モバイルノードによるドメイン限定フローの発送を制御することが可能である。

また、モバイルノードのインタフェースは、異なるアクセスネットワークに移動（接続の変更又は切り換え）することが可能である。したがって、モバイルノードのインタフェースが信頼ネットワークから非信頼ネットワークに移動する可能性もある。なお、後述のように、本明細書では、あるサービスプロバイダが直接管理しているか、信頼関係を有するオペレータによって管理されているようなネットワークを信頼ネットワークと呼び、信頼ネットワーク以外のネットワークを非信頼ネットワークと呼ぶ。

しかしながら、非信頼ネットワークに移動した場合、サービスプロバイダによって生成されたネットワークフロープロファイルが最新の情報にアップデートされていない可能性がある。例えばモバイルノードの移動中のインタフェースがドメイン限定フローを転送している場合、モバイルノードは、サービスプロバイダによって生成されたネットワークプロファイルに従ってドメイン限定フローに関するフィルタルールを構成する必要があるので、アップデートされていないネットワークフロープロファイルを参照してドメイン限定フローを非信頼ネットワークにおいても発送してしまう可能性がある。

すなわち、従来のネットワーク側（例えばＨＡ）からモバイルノードに対してフロー情報を通知する方法においては、モバイルノードの移動などによって、インタフェースが接続するネットワークが切り換わった後でも、そのインタフェースを引き続き、そのフローに関するパケットを送受信するインタフェースとして使用し続けてよいかどうかの判断を、モバイルノード自身が正確に行うことはできない。また、ハンドオーバ中のパケットロスを防ぐため、他のインタフェースを使ってフローを送受信したい場合、フロー情報で指定されていないインタフェースからそのフローを送信してよいかどうかの判断に関しても、モバイルノード自身が正確に行うことはできない。

このような問題を解決する解決方法としては、モバイルノードのインタフェースが接続ポイントを切り換える前に送信されるネットワークトリガを利用する方法が挙げられる。例えば、モバイルノードは、３Ｇ（第３世代）セルラインタフェース及びＷＬＡＮ（Wireless Local Area Network）インタフェースを有し、両方のインタフェースが信頼アクセスネットワーク内に存在しているとする。

ＷＬＡＮインタフェースが接続されているアクセスポイントは、常にＷＬＡＮインタフェースの接続を監視している。例えば、アクセスポイントはＷＬＡＮインタフェースの電力／シグナル強度の閾レベルを監視する。アクセスポイントは、ＷＬＡＮインタフェースからの電力／シグナル強度が閾レベル以下に達したことを検出すると、ＷＬＡＮインタフェースがアクセスポイントの通信範囲外に移動したと判断する。これにより、アクセスポイントはモバイルノードにトリガを送信する。このトリガは、例えばＩＥＥＥ８０２．２１で使用される“link going down”トリガである。

モバイルノードは、ＷＬＡＮインタフェースがアクセスポイントの通信範囲外に移動してしまうことを示すトリガをアクセスポイントから受信すると、例えば、下記の非特許文献４に定義されているファストモバイルＩＰｖ６（ＦＭＩＰｖ６）に係る方法を実行して、近隣のアクセスポイントとの接続を試みる。モバイルノードはＦＭＩＰｖ６を使用して、インタフェースの移動先のアクセスポイントにおける新たなＣｏＡを取得することが可能である。

モバイルノードは、このＣｏＡを用いて、ＨＡにおけるモバイルノードのバインディングエントリをアップデートするためのバインディングアップデート（ＢＵ：Binding Update）をＨＡに送信することが可能である。ＨＡは、ＢＵを受信すると、モバイルノードから提供されたＣｏＡがサービスプロバイダのプレフィックスを使用して構成されていないかをチェックする。

ＨＡは、モバイルノードが非信頼アクセスネットワークに移動したと判断した場合には、モバイルノードのネットワークフロープロファイルをアップデートし、まだ信頼アクセスネットワーク内に存在しているモバイルノードのインタフェース経由でドメイン限定フローが伝送されるようにする。したがって、ＨＡは、例えばモバイルノードのネットワークプロファイルのアップデートを行うことによって、３ＧインタフェースのＨｏＡ／ＣｏＡ経由でドメイン限定フローを伝送するようモバイルノードに通知する。このアップデートされたネットワークプロファイルは、例えば、ＨＡからモバイルノードへのバインディングアクノレッジメント（ＢＡ：Binding Acknowledgment）によって送信される。

また、モバイルノードのネットワークフロープロファイルをＨＡがアップデートする代わりに、モバイルノードがネットワークフロープロファイルのアップデート機能を有し、ネットワークフロープロファイルの変更をＨＡに通知する方法が考えられる。

例えば、下記の特許文献１には、複数インタフェースを有するモバイルノードに実装されているアプリケーションの構成が開示されている。ここでは、モバイルノードはプロファイルサーバに対して、モバイルノードに実装されているアプリケーションを動作させるためのアプリケーション特有のプロファイルを要求する。プロファイルサーバは、アプリケーション特有のプロファイルを作成するか又は読み出して、アプリケーション特有のプロファイルをモバイルノードに返信する。モバイルノードは、このようにして提供されたアプリケーション特有のプロファイルを、アプリケーションの動作中においてモバイルノードの１つ以上の通信インタフェースの選択制御を行うためのポリシルールとして解釈することが可能となる。

以上のように、従来の技術では、ＭＮがＨＡに対し複数のＣｏＡの登録を行っている場合には、ＭＮはＨＡに対して、パケットの転送先として使用するＣｏＡを指定するために、ＨＡへフロー情報を通知する。このフロー情報は、ＭＮが送受信している特定のフローを、どのＣｏＡあてに転送してほしいかを指定するための情報である。ＨＡは、ＭＮから通知されたこのフロー情報に基づいて、ＭＮあてのパケットの転送先を選択する。

一方、ＨＡからＭＮに対しても同様のフロー情報を通知することが可能である。この場合には、フロー情報はネットワーク側のポリシに基づいて生成されるものとなる。ＭＮは、パケットを送信する際に、ＨＡから通知されたフロー情報に基づいて使用するインタフェースを選択する。

米国特許公開２００７／０００４３９３

D. Johnson, C. Perkins and J. Arkko, "Mobility Support in IPv6", Internet Engineering Task Force Request For Comments 3775, June 2004. R. Wakikawa, T. Ernst and K. Nagami, "Multiple Care-of Addresses Registration", Monami6 Working Group Internet Draft, March 05, 2007. H. Soliman, K. ElMalki, and C. Castelluccia, "Flow Bindings in Mobile IPv6 and Nemo Basic Support", Internet Engineering Task Force Internet Draft, February 2007. R. Koodli, Editor, "Fast Handovers for Mobile IPv6", Internet Engineering Task Force Request For Comments 4068, July 2005.

しかしながら、上述の接続ポイントの切り換え前に受信するネットワークトリガを利用する方法では、アクセスポイントがモバイルノードのインタフェースの接続性を検知できる機能（モバイルノードとの接続の切断を事前に検知してトリガを出す機能）を有する必要があり、また、モバイルノードも、例えばハンドオーバ前にＣｏＡの取得処理を行うＦＭＩＰｖ６を実装する必要があるという問題が生じる。例えばアクセスポイントがモバイルノードのインタフェースの接続性を検知できる機能を有していない場合には、モバイルノードがアップデートされたネットワークフロープロファイルを受信するまでに遅延が生じ、この遅延によって、モバイルノードはドメイン限定フローを非信頼ネットワーク経由で発送してしまう可能性がある。

また、この解決方法には、モバイルノードのインタフェースの電力／シグナル強度がアクセスポイントで定義されている閾レベル付近で変動する場合には、アクセスポイントは、インタフェースのリンクが切れることを示すネットワークトリガをモバイルノードに連続して送信してしまうという問題もある。

その結果、アクセスポイントからモバイルノードに対して多数のネットワークトリガが連続して送信されてしまうという問題や、多数のネットワークトリガに基づいてモバイルノードが冗長なバインディングエントリのアップデートを行うとともに、ＨＡから多数のネットワークフロープロファイルがモバイルノードに送信されてしまう問題などが生じ、ネットワーク帯域や各装置の処理負荷が無駄に消費されることになる。

また、特許文献１に開示されている技術では、モバイルノードは、モバイルノード内に格納されるアプリケーション特有のプロファイルを参照してインタフェースの選択を行うものの、ハンドオーバやネットワーク環境の変化に応じてネットワーク状態が変化した場合におけるプロファイルのアップデート方法やインタフェースの切り換え方法に関してはまったく言及されていない。

上記の問題を解決するため、本発明は、オペレータがポリシに基づいて規定したフロー情報に従って通信を行っている複数のインタフェースを有するモバイルノード（移動端末）が、フローにとって適切なインタフェースを選択して通信を行うことができるようにすることを目的とする。

上記の目的を達成するため、本発明の移動端末は、複数のインタフェースでトラフィックフローをルーティング可能な場合に、前記トラフィックフローをルーティングするためのアクセスネットワークを選択することができる移動端末であって、
特定の前記アクセスネットワークでのみ送受信可能な前記トラフィックフローを識別するためのフロー識別情報と前記アクセスネットワークを識別するためのネットワーク識別情報を含むフロー情報であって、前記移動端末に与えられている前記フロー情報に基づいて、前記複数のインタフェースの１つを介して送受信を行っている前記トラフィックフローがルーティングされることが可能なアクセスネットワークを選択する選択手段と、
前記トラフィックフローを元のアクセスネットワークから前記選択されたアクセスネットワークに移す移動手段とを、
有する。

また、上記目的を達成するために、本発明の方法は、複数のインタフェースでトラフィックフローをルーティング可能な移動端末が前記トラフィックフローをルーティングするためのアクセスネットワークを選択する方法であって、
特定の前記アクセスネットワークでのみ送受信可能な前記トラフィックフローを識別するためのフロー識別情報と前記アクセスネットワークを識別するためのネットワーク識別情報を含むフロー情報であって、前記移動端末に与えられている前記フロー情報に基づいて、前記複数のインタフェースの１つを介して送受信を行っている前記トラフィックフローがルーティングされることが可能なアクセスネットワークを選択するステップと、
前記トラフィックフローを元のアクセスネットワークから前記選択されたアクセスネットワークに移すステップとを、
有する。

本発明は、上記の構成を有しており、オペレータがポリシに基づいて規定したフロー情報に従って通信を行っている複数のインタフェースを有するモバイルノードが、フローにとって適切なインタフェースを選択して通信を行うことができるようになるという効果を有している。

本発明の第１の実施の形態におけるモバイルノードの構成の一例を示すブロック図 本発明の第１の実施の形態におけるネットワーク構成の一例を示す図 本発明の第１の実施の形態におけるネットワークフロープロファイルの概略を模式的に示す図 本発明の第１の実施の形態におけるフローコントロール情報の概略を模式的に示す図 本発明の第１の実施の形態において、モバイルノードの接続ポイントの変更を示すトリガを受信したプロファイルプロセッサの動作の一例を示すフローチャート 本発明の第１の実施の形態におけるバインディングアップデートメッセージのフォーマットの一例を示す図 本発明の第２の実施の形態におけるネットワーク構成の一例を示す図 本発明の第２の実施の形態におけるモバイルノードの構成の一例を示すブロック図 本発明の第２の実施の形態におけるモバイルノードの構成の一例を示すブロック図 本発明の第２の実施の形態におけるホームエージェントの構成の一例を示すブロック図 本発明の第２の実施の形態において、自身のインタフェースにおける接続切り換えが検出された際のモバイルノードの判断処理の一例を示すフローチャート 本発明の第２の実施の形態において、フロー情報に付加されているフロータイプフラグを確認する場合のモバイルノードの判断処理の一例を示すフローチャート 本発明の第２の実施の形態におけるバインディングアップデートメッセージを用いたフロー確認用メッセージのフォーマットの一例を示す図

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

本明細書では、複数のインタフェースを有するモバイルノード（ＭＮ）が、適切なインタフェースを通じてトラフィックフローを送受信するための方法が開示される。

なお、以下では、本発明の説明を分かりやすくするため、『ネットワークフロープロファイル（Network Flow Profile）』という用語を用いる。このネットワークフロープロファイルは、モバイルノードのトラフィックフローの発送方法（モバイルノードのトラフィックフローがモバイルノードから（又はモバイルノードに）発送される方法）を指示するためにモバイルノードのサービスオペレータによって定義されるフィルタルールを表している。

さらに、本明細書では、特定のフローが特定のネットワークを経由し伝送されるという両者の関係を説明するために、『ドメイン限定フロー（Domain Limited Flow）』という用語を用いる。このドメイン限定フローは、サービスプロバイダが信頼できるネットワーク（trusted network：以下、信頼ネットワークと記載することもある）内でのみ伝送される必要があるトラフィックフローを表している。信頼ネットワークは、このサービスプロバイダによって承認されているネットワークであり、例えばセキュリティに関して保証されているネットワークである。なお、本明細書では、上記のように、特定のフローとそのフローを伝送するネットワークとの関係を表すために、ドメイン限定フローと信頼ネットワークとの関係を一例として用いているが、両者の関係はこれに限定されない。つまり、特定のフローに対し、そのフローの伝送に適したネットワークが決定される場合であれば、両者を関係付ける理由は問わない。以下の説明では、一例として、信頼という共通の理由で関係付けされた、信頼フローリスト３１０及び信頼アクセスリスト３１１を用いる。

なお、信頼ネットワークは、例えばサービスプロバイダが直接管理しているネットワークであり、更にはサービスプロバイダとの間でセキュリティアソシエーションが確立されているオペレータによって管理されているネットワークが含まれていてもよい。また、本明細書では、サービスプロバイダとの間で信頼関係が確立されていないネットワーク（すなわちサービスプロバイダが信頼できないネットワーク）を『非信頼ネットワーク』と記載することがある。

また、ドメイン限定フローが信頼ネットワーク内でのみ伝送される必要がある理由としては、例えば、信頼ネットワーク外部にフローが流出することによるセキュリティの低下やＱｏＳ（Quality of Service：サービス品質）の低下を回避することなどが挙げられるが、その他の任意の理由であってもよく、本発明ではその理由は限定されない。

＜第１の実施の形態＞
まず、本発明の第１の実施の形態について説明する。図１には、本発明の第１の実施の形態におけるモバイルノードの構成の一例が図示されている。モバイルノード（ＭＮ）１０は、１つ又は複数のネットワークインタフェース１１、プロファイルプロセッサ１２、フローキャッシュ１３を有している。また、フローキャッシュ１３には、ネットワークフロープロファイル１３ａ及びフローコントロール情報１３ｂが格納される。

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

また、ネットワークインタフェース１１とプロファイルプロセッサ１２との間では、シグナル／データパス１４０を通じて、トリガ／パケットの伝送に係る情報のやり取りが行われる。

また、プロファイルプロセッサ１２は、ネットワークフロープロファイル１３ａのチェックやアップデートを行う機能を有している。プロファイルプロセッサ１２がネットワークインタフェース１１からトリガを受けると、プロファイルプロセッサ１２のチェック機能が作動する。なお、トリガとしては、１つ又は複数のネットワークインタフェース１１が接続ポイントを変更した場合やネットワーク状態の悪化が検出された場合が挙げられるが、これらに限定されるものではない。

プロファイルプロセッサ１２が有するチェック機能は、接続を変更したインタフェースがサービスプロバイダの信頼アクセスネットワーク外部にドメイン限定フローを発送しているか否か（あるいは、発送してしまうことになるか否か）を判断するためのものである。

信頼アクセスネットワーク外部にドメイン限定フローが伝送されていることが検出された場合には、プロファイルプロセッサ１２のアップデート機能が作動し、ネットワークフロープロファイル１３ａのアップデートが行われる。このアップデートによって、ドメイン限定フローに関するネットワークフロープロファイル１３ａがアップデートされ、ドメイン限定フローがサービスプロバイダの信頼アクセスネットワーク外部に流出しないように設定することが可能となる。

また、プロファイルプロセッサ１２とフローキャッシュ１３との間では、シグナル／データパス１４１を通じて、プロファイル／情報の伝送に係る情報のやり取りが行われる。

また、フローキャッシュ１３は、トラフィックフローに関する情報を格納することが可能であり、例えばフローキャッシュ１３にはネットワークフロープロファイル１３が格納可能である。ネットワークフロープロファイル１３ａは、上述のように、モバイルノード１０のトラフィックフローの発送方法を指示するフィルタルールであり、このネットワークフロープロファイル１３ａはモバイルノード１０のサービスオペレータによって定義され、任意のタイミングでネットワークからモバイルノードに１０に提供される。なお、ネットワークフロープロファイル１３ａは、例えば１つ又は複数のフィルタルールを有していてもよい。

さらに、フローキャッシュ１３には、本発明で導入されるフローコントロール情報１３ｂが格納可能である。上述のように、ドメイン限定フローがサービスプロバイダの信頼アクセスネットワークの外部に伝送されていることが検出された場合にネットワークフロープロファイル１３ａのアップデートが行われるが、フローコントロール情報１３ｂには、プロファイルプロセッサ１２がネットワークフロープロファイル１３ａのアップデートを行う際に必要とする情報が含まれている。フローコントロール情報１３ｂの一例としては、例えばネットワーク側のホームエージェントから提供される後述の信頼フローリスト３１０や信頼アクセスリスト３１１などが挙げられる。

また、図２には、本発明の第１の実施の形態におけるネットワーク構成の一例が図示されている。図２に図示されているネットワーク構成において、ホームエージェント（ＨＡ）２２、セルラネットワーク（信頼セルラネットワーク）２００、ＷＬＡＮ（信頼ＷＬＡＮ）２０１が信頼ネットワークを形成している。なお、こうした信頼ネットワークは、単一のサービスプロバイダによって所有されていてもよく、信頼関係にある複数のサービスプロバイダによって所有されていてもよい。

ＨＡ２２及びセルラネットワーク２００は、シグナル／データパス２１０を介して接続されている。また、ＨＡ２２及びＷＬＡＮ２０１は、シグナル／データパス２１１を介して接続されている。

さらに、このネットワーク構成において、上記のＨＡ２２、セルラネットワーク２００、ＷＬＡＮ２０１によって形成された信頼ネットワークに属さないＷＬＡＮ（非信頼ＷＬＡＮ）２０２が存在している。

また、図２に図示されているように、セルラインタフェース（ＩＦ１）１１０及びＷＬＡＮインタフェース（ＩＦ２）１１１の２つのネットワークインタフェースを有するモバイルノード（ＭＮ）１０が存在している。なお、初期状態では、セルラインタフェース１１０及びＷＬＡＮインタフェース１１１は、それぞれセルラネットワーク２００及びＷＬＡＮ２０１に接続されているものとする。したがって、セルラインタフェース１１０はセルラネットワーク２００からＣｏＡ（セルラ信頼ＣｏＡ：Trusted-CoA-Celluar）を取得し、ＷＬＡＮネットワーク２０１からＣｏＡ（ＷＬＡＮ信頼ＣｏＡ：Trusted-CoA-WLAN）を取得する。

なお、セルラ信頼ＣｏＡはバインディング識別子（ＢＩＤ１）に対応し、ＷＬＡＮ信頼ＣｏＡはバインディング識別子（ＢＩＤ２）に対応しているとする。ＭＮ１０は、ＭＮ１０のＨｏＡ（ホームアドレス）にＢＩＤ１が付加されたセルラ信頼ＣｏＡ、及びＢＩＤ２が付加されたＷＬＡＮ信頼ＣｏＡの両方を関連付けたバインディングをＨＡ２２に登録する。また、ＭＮ１０及びＨＡ２２は、ＢＩＤ２を経由するドメイン限定フローを有しているとする。なお、以下の説明では、セルラインタフェース１１０がＣｏＡを使用する場合を想定しているが、セルラインタフェース１１０はセルラネットワーク２００からＣｏＡではなくＨｏＡを取得して使用していてもよい。この場合、ＭＮ１０がＨＡ２２に登録する位置情報は、ＨｏＡとＷＬＡＮインタフェース１１１に割り当てられているＣｏＡの２つのアドレスを転送先として示しており、ＢＩＤ１はＨｏＡを指す位置情報に対応する。

本発明では、モバイルノードが非信頼ネットワークに移動した場合、モバイルノードがネットワークフロープロファイル１３ａをアップデートしてドメイン限定フローのパスを信頼ネットワーク内部に維持することができる必要がある。したがって、モバイルノードはネットワークフロープロファイルを受信して保持するだけではなく、ドメイン限定フローの経路をアップデートするための『フローコントロール情報（ＦＣＩ：フローコントロール Information）』を必要とする。

次に、ネットワークフロープロファイル１３ａ及びフローコントロール情報１３ｂのフォーマットについて説明する。図３Ａには、本発明の第１の実施の形態におけるネットワークフロープロファイルの概略が模式的に図示されている。ネットワークフロープロファイル１３ａは、ネットワークフロープロファイルタイプ３０１及びフローポリシ３０２を有している。

ネットワークフロープロファイルタイプ３０１は、ネットワークフロープロファイルの用途を表している。なお、ネットワークフロープロファイル１３ａの用途としては、例えばドメイン限定フローのルーティング制御や、ネットワークへのアクセス制御などが挙げられるが、これに限定されるものではない。

また、ネットワークフロープロファイル１３ａ内に存在するフローポリシ３０２によって、ＨＡ２２は、ＭＮ１０に対して１つ又は複数のポリシを定義することが可能となる。なお、フローポリシ３０２は、例えばＭＮ１０がドメイン限定フローを発送する方法を指示するために、ＨＡ２２によってセットされるルーティングポリシや、ＭＮ１０がアクセス可能なネットワーク（例えばＣＳＧ：Closed Subscriber Group）を表すリストであってもよいが、これに限定されるものではない。

例えば、ＨＡ２２は、通常はセルラネットワーク経由で伝送されるべきデータパケット（例えばＭＮ１０のｉモード（登録商標）のデータパケット）をＷＬＡＮ信頼ＣｏＡ（ＢＩＤ２）経由で発送するようＭＮ１０に指示するフローポリシをセットする。なお、このデータパケットはＦＩＤ１のフロー識別情報を有しているとする。

また、図３Ｂには、本発明の第１の実施の形態におけるフローコントロール情報の概略が模式的に図示されている。フローコントロール情報１３ｂは、信頼フローリスト３１０及び信頼アクセスリスト３１１が含まれている。

信頼フローリスト３１０によって、ＨＡ２２は、ＭＮ１０のどのフローが信頼アクセスネットワーク経由で発送されるべきかをＭＮ１０に示すことが可能となる。例えば、ＨＡ２２は、ｉモード（登録商標）のデータパケット（ＦＩＤ１）が信頼アクセスネットワーク内でのみ伝送可能である旨をＭＮ１０に通知するエントリを信頼フローリスト３１０に追加する。なお、ここでは、フローを指定する情報として、ＦＩＤ（フローＩＤ）を用いているが、ＭＮ１０が行う通信を識別できる任意の情報を用いてもよい。例えば、通信相手のアドレスや、プロトコル番号、セッションＩＤ，コネクションＩＤなどがある。特に、３ＧＰＰネットワークへ接続している場合には、ＰＤＮゲートウェイとのコネクションを識別するＩＤ（PDN connection ID、ＡＰＮ）などが用いられる。

さらに、信頼アクセスリスト３１１によって、ＨＡ２２は、どのアクセスネットワークがサービスオペレータの信頼ネットワークとして分類されているかをＭＮ１０に通知することが可能となる。例えば、ＨＡ２２は、サービスオペレータの信頼アクセスネットワークを特定するネットワーク識別情報（ネットワークＩＤ）を信頼アクセスリスト３１１に記載する。すなわち、信頼アクセスリスト３１１を参照することによって、サービスプロバイダの信頼ネットワークを特定することが可能となる。

なお、ネットワークフロープロファイル１３ａ及びフローコントロール情報１３ｂのレイアウトは、例えば、ＸＭＬ（eXtensible Markup Language）スキームを使用して生成すればよく、JavaScript（登録商標）言語などを始めとするその他のプログラミング言語を使用することも可能である。

ここで、ＭＮ１０は、ＷＬＡＮ２０１に接続されているＷＬＡＮインタフェース１１１を用いてドメイン限定フローの送受信を行っているとする。例えば、ＭＮ１０がドメイン限定フローであるｉモード（登録商標）サービスをサービスプロバイダから要求したとする。ｉモード（登録商標）のデータパケット（ＦＩＤ１）は信頼ネットワークのみを経由して発送される必要があるので、ＨＡ２２は、ＷＬＡＮ信頼ＣｏＡ（ＢＩＤ２）経由でデータパケット（ＦＩＤ１）が伝送されるように、ＭＮ１０に関するネットワークフロープロファイル１３ａをセットする。

一方、ＭＮ１０が異なるネットワーク間を移動している場合には、ＭＮ１０のＷＬＡＮインタフェース１１１がＷＬＡＮ（信頼ＷＬＡＮ）２０１の通信エリアからＷＬＡＮ（非信頼ＷＬＡＮ）２０２の通信エリアに移動する可能性がある。なお、ＭＮ１０おける接続ポイントの変更によって、ネットワークインタフェース１１からプロファイルプロセッサ１２にトリガが送信される。

図４には、本発明の第１の実施の形態において、モバイルノードの接続ポイントの変更を示すトリガを受信したプロファイルプロセッサの動作の一例が図示されている。

図４において、プロファイルプロセッサ１２はネットワークインタフェース１１からトリガを受信すると（ステップＳ４０）、ＭＮ１０に関するネットワークフロープロファイル１３ａ及びフローコントロール情報１３ｂをフローキャッシュ１３から読み出す（ステップＳ４１）。なお、受信したトリガには、ＭＮ１０のどのネットワークインタフェース１１が移動中（接続切り換え中）であるかが示されている。

続いて、トリガからの情報やフローキャッシュ１３から取得した情報を用いて、プロファイルプロセッサ１２は、ＭＮ１０の移動中のインタフェースに関連したアクティブなドメイン限定フローが存在するか否かをチェックする（ステップＳ４２）。

移動中のインタフェースに関連したアクティブなドメイン限定フローが存在しない場合には、プロファイルプロセッサ１２は、ＭＮ１０の新たなＣｏＡ（ＷＬＡＮ非信頼ＣｏＡ）に関してＨＡ２２へのバインディング動作を行うよう、ＭＮ１０内のモバイルＩＰスタックに依頼し、ＢＵが生成される（ステップＳ４７）。

一方、ＷＬＡＮ２０１に接続されているＷＬＡＮインタフェース１１１を用いてドメイン限定フローの送受信を行っており、ＷＬＡＮインタフェース１１１の接続をＷＬＡＮ（信頼ＷＬＡＮ）２０１からＷＬＡＮ（非信頼ＷＬＡＮ）２０２に切り換えるような場合には、プロファイルプロセッサ１２は、ＭＮ１０の移動中のインタフェースに関連したドメイン限定フローの存在を検出する。

この場合、プロファイルプロセッサ１２は、ネットワークインタフェースから移動中のインタフェースが接続するアクセスネットワークのネットワーク識別情報（ネットワークＩＤ）を提供するように要求する（ステップＳ４３）。プロファイルプロセッサ１２は、アクセスネットワークのネットワーク識別情報に基づいて、移動中のインタフェースが依然としてサービスプロバイダの信頼ネットワーク内に位置しているか否かを特定する処理を行う（ステップＳ４４）。

なお、移動中のインタフェースがサービスプロバイダの信頼ネットワーク内に位置しているか否かを特定する方法としては、例えば、新たなアクセスネットワークのネットワーク識別情報と、信頼アクセスリスト３１１内の情報との比較を行う方法が挙げられるが、これに限定されるものではない。

移動中のインタフェースが依然としてサービスプロバイダの信頼ネットワーク内に位置している場合には、プロファイルプロセッサ１２は、ＭＮ１０の新たなＣｏＡ（ＷＬＡＮ信頼ＣｏＡ）に関してＨＡ２２へのバインディング動作を行うよう、ＭＮ１０内のモバイルＩＰスタックに依頼し、ＢＵが生成される（ステップＳ４７）。

また、上述のように、ＭＮ１０がＷＬＡＮインタフェース１１１の接続をＷＬＡＮ（信頼ＷＬＡＮ）２０１からＷＬＡＮ（非信頼ＷＬＡＮ）２０２に切り換えるような場合には、プロファイルプロセッサ１２は、接続切り換え後のＷＬＡＮインタフェース１１１がサービスプロバイダの信頼ネットワーク内に位置していないことを検出する。したがって、この場合には、プロファイルプロセッサ１２はフローコントロール情報１３ｂを用いて、ＭＮ１０のネットワークフロープロファイル１３ａをアップデートする（ステップＳ４５）。

例えば、フローコントロール情報１３ｂに含まれている信頼フローリスト３１０に基づいて、プロファイルプロセッサ１２は、ＢＩＤ２に関連付けられているｉモード（登録商標）のデータパケット（ＦＩＤ１）が信頼アクセスネットワーク経由で発送される必要があることを把握する。また、プロファイルプロセッサ１２は、同じくフローコントロール情報１３ｂに含まれている信頼アクセスリスト３１１から、利用可能な信頼アクセスネットワークが、セルラ信頼ＣｏＡ（ＢＩＤ１）を用いたセルラネットワーク２００であることを確認する。その結果、プロファイルプロセッサ１２は、ＭＮ１０のネットワークフロープロファイル１３ａ内で、ＦＩＤ１の経路をＢＩＤ２経由からＢＩＤ１経由に変更するアップデートを行う。

ＭＮ１０のネットワークフロープロファイル１３ａのアップデートが完了すると、プロファイルプロセッサ１２は、ＭＮ１０の新たなＣｏＡ（ＷＬＡＮ非信頼ＣｏＡ）に関してＨＡ２２へのバインディング動作を行うよう、ＭＮ１０内のモバイルＩＰスタックに依頼し、ＢＵが生成される（ステップＳ４６）。

なお、このバインディング動作では、アップデートされたＭＮ１０のネットワークフロープロファイル１３ａがＢＵのペイロードに更に挿入され、また、ＨＡ２２に提供されたＭＮ１０のフローコントロール情報１３ｂに基づいてＭＮ１０のネットワークフロープロファイル１３ａが変更された旨が、ＢＵのフラグによって明示される。

なお、ステップＳ４６及びステップＳ４７のどちらのＢＵ生成処理においても、ＭＮ１０内のモバイルＩＰスタックはＢＵをネットワークインタフェース１１に転送して、ＢＵがＨＡ２２に送信される（ステップＳ４８）。

なお、別の実施例として、ＭＮ１０の移動中のインタフェースが依然としてサービスプロバイダの信頼ネットワークに存在していると判断された場合に、プロファイルプロセッサ１２がＨＡ２２へのバインディング動作に係るＢＵを生成するよう、ＭＮ１０内のモバイルＩＰスタックに依頼するとともに、このＢＵに追加フラグが付加されるようにしてもよい。このフラグ（後述のＢフラグ５３）は、たとえＭＮ１０の移動中のインタフェースに関連するドメイン限定フローが存在している場合であっても、インタフェースは依然として信頼ネットワーク内に存在しており、ドメイン限定フローのルートが再設定される必要があるか否かをＨＡ２２がチェックする必要がないことをＨＡ２２に明示的に示すものである。この方法によれば、ＭＮ１０のインタフェースが信頼アクセスネットワーク内で移動した場合に、ＭＮ１０に関するネットワークフロープロファイル１３ａ及びフローコントロール情報１３ｂのＨＡ２２による処理を減らすことが可能となる。

また、図５には、本発明の第１の実施の形態におけるバインディングアップデートメッセージのフォーマットの一例が図示されている。図５に図示されているバインディングアップデートメッセージは、バインディングアップデートヘッダ５１、Ｖフラグ５２、Ｂフラグ５３、ネットワークフロープロファイル領域５４を有している。

バインディングアップデートヘッダ５１には、モバイルノードが新たな気付アドレスを他のノードに通知するために必要な情報が含まれている。また、Ｖフラグ５２は、ＭＮ１３のネットワークフロープロファイル１３ａがＨＡ２２から提供されたＭＮ１０のフローコントロール情報１３ｂに基づいて変更された旨をＨＡ２２に通知するためのものである。さらに、Ｂフラグ５３によって、ＨＡ２２は、ＭＮ１０が信頼ネットワーク内を移動しているので、ドメイン限定フローの再ルーティングを行う必要がないことが把握できる。

また、ネットワークフロープロファイル領域５４には、アップデートされたＭＮ１０のネットワークフロープロファイル１３ａが含まれている。なお、Ｖフラグ５２、及びＢフラグ５３は任意の位置に配置可能であり、バインディングアップデートヘッダ５１内のフラグとして実現されてもよく、ネットワークフロープロファイル５４を通知する領域内のフラグとして実現されてもよい。また、ネットワークフロープロファイル領域５４は任意の位置に配置可能であり、例えば任意のヘッダのオプションとして実現されてもよく、ペイロードによって実現されてもよい。ＨＡ２２は、ネットワークフロープロファイル領域５４に含まれているアップデートされたネットワークフロープロファイル１３ａを参照することで、ＭＮ１０による変更が正しいか否かを検証することが可能である。

ＨＡ２２はＭＮ１０からＢＵ５０を受信すると、ＢＵ５０の処理を行って、実行すべき必要な動作を判断する。例えば、ＨＡ２２は、ＢＵ５０にＶフラグ５２がセットされているとともに、アップデートされたＭＮ１０のネットワークフロープロファイル１３ａがネットワークフロープロファイル領域５４に格納されていることを認識する。この場合、ＨＡ２２はＭＮ１０がネットワークフロープロファイル１３ａを正しくアップデートしているか否かを検証する。なお、このＨＡ２２による検証方法としては、例えば、ＨＡ２２がネットワークフロープロファイル１３ａを参照して、すべてのドメイン限定フローが信頼アクセスネットワーク内で伝送されることを確認する方法が挙げられるが、これに限定されるものではない。

ＭＮ１０によるネットワークフロープロファイル１３ａのアップデートに関する検証が完了すると、ＨＡ２２は、ＨＡ２２自身に格納されているＭＮ１０に関するネットワークフロープロファイル１３ａを、ＢＵ５０によるアップデートで送られてきたＭＮ１０のネットワークフロープロファイル（ネットワークフロープロファイル領域５４内に含まれているネットワークフロープロファイル１３ａ）で置き換える。

なお、ＨＡ２２が受信したＢＵ５０において、Ｖフラグ５２がセットされずに、アップデートされたＭＮ１０のネットワークフロープロファイル１３ａがネットワークフロープロファイル領域５４に含まれている場合もあり得る。こうした場合には、ＭＮ１０がフローコントロール情報１３ｂを参照せずにネットワークフロープロファイル１３ａを変更したと判断され、ＨＡ２２はＢＵ５０を拒絶することが望ましい。

また、ＨＡ２２が受信したＢＵ５０に、Ｂフラグ５３がセットされていてもよい。このＢフラグ５３がセットされていることによって、ＨＡ２２は、ＭＮ１０が信頼ネットワーク内で移動しており、ＨＡ２２がＭＮ１０のネットワークフロープロファイル１３ａを変更する必要がないことを即座に把握できる。

本発明では、例えば、ＭＮ１０が接続ポイントを変更した場合、ＭＮ１０が新たなドメイン限定サービスを要求した場合、ＭＮ１０がドメイン限定サービスを終了した場合などに、ＭＮ１０のフローコントロール情報１３ｂがＨＡ２２によってアップデートされる。このとき、ＨＡ２２は、例えばドメイン限定フローの信頼フローリスト３１０や信頼ネットワークの信頼アクセスリスト３１１などのようなフローコントロール情報１３ｂに含まれる適切なエントリのアップデートを行う。

また、ＨＡ２２は、ＭＮ１０が信頼アクセスネットワーク内で移動している旨を把握しているのであれば、アップデートされたフローコントロール情報１３ｂをＭＮ１０に送信しないように選択することも可能である。なお、サービスプロバイダの原則はドメイン限定フローが信頼ネットワーク内でのみ伝送されるようにすることなので、信頼アクセスネットワーク内で移動しているＭＮ１０が、この原則を破ることはない。このような選択的な動作によって、特にＨＡ２２がドメイン限定サービスを利用している多くの加入者を抱えている場合に、ＨＡ２２のネットワークリソースを効率良く使用できるようになる。

また、グループ識別情報を使用して、モバイルノードの複数のドメイン限定フローを識別することも可能である。例えば、ＭＮ１０は、ＦＩＤ１、ＦＩＤ２、ＦＩＤ３のフロー識別情報をそれぞれ有する３つのドメイン限定サービスに加入しており、これら３つのドメイン限定フローは、ＭＮ１０の同一のＢＩＤを通じて伝送されるとする。

ＨＡ２２は、信頼グループ識別情報（ＴＧＩＤ：Trusted Group Identification）と呼ばれるグループ識別情報によって、これら３つのドメイン限定フローを分類することができる。そして、ＨＡ２２は、ＭＮ１０が使用すべきネットワークフロープロファイル１３ａ及びフローコントロール情報１３ｂにＴＧＩＤを付加する。

ＭＮ１０は、ＴＧＩＤを使用することで、１つのＢＵを送信するだけですべての関連するドメイン限定フロー（同一ＴＧＩＤに属するドメイン限定フロー）のアップデートを行うことが可能となり、ＢＵによるオーバヘッドが軽減される。また、ＭＮ１０及びＨＡ２２は、様々なドメイン限定フローを複数のＴＧＩＤのどれに分類するかの取り決めを行うことが可能である。これにより、ＭＮ１０は、ドメイン限定フローの分類方法を柔軟に定めることが可能となる。

以上、説明したように、本発明の第１の実施の形態によれば、モバイルノードがドメイン限定フロー及び信頼ネットワークを認識できるようになり、ドメイン限定フローが信頼ネットワーク内でのみ送受信されるようにモバイルノード自身が制御を行うことが可能となる。これにより、特定のフローに適したネットワークの選択、ネットワークフロープロファイルの変更及びその通知が可能となり、モバイルノードによる効率的なフローの転送が可能となる。

＜第２の実施の形態＞
次に、本発明の第２の実施の形態について説明する。図６には、本発明の第２の実施の形態におけるネットワーク構成の一例が図示されている。図６において、ＭＮ６１０はＩＦ１とＩＦ２の２つのインタフェースを有しており、ＩＦ１はネットワーク６２０に接続され、ＩＦ２はネットワーク６３０に接続されている。ＩＦ１とＩＦ２は、ＭＮ６１０の移動などによって接続するネットワークを変更することが可能であり、その移動管理はＨＡ６４０を使用したモバイルＩＰによって実現されている。

また、ＭＮ６１０はＨＡ６４０から、フロー情報が与えられており、そのフロー情報では、ＭＮ６１０が通信相手との間でやり取りするフローに対して、その送受信に使用するインタフェースが指定されている。例えばＭＮ６１０が送信しようとしているフローに関して、ＨＡ６４０から通知されたフロー情報が存在する場合には、ＭＮ６１０は、そのフロー情報によって指定されたインタフェースを使用してパケットを送信する。なお、本発明の第２の実施の形態では図７に示すように、ＭＮ６１０は、ＦＩＤ１（フロー１）に対してＢＩＤ１（ＩＦ１）を使用することが指定されたフロー情報（上述の本発明の第１の実施の形態におけるネットワークフロープロファイル１３ａに対応）をＨＡ６４０から取得しているとする。また、ここでは、フローを指定する情報として、ＦＩＤ（フローＩＤ）を用いているが、ＭＮ６１０が行う通信を識別できる任意の情報を用いてもよい。例えば、通信相手のアドレスや、プロトコル番号、セッションＩＤ，コネクションＩＤなどがある。特に、３ＧＰＰネットワークへ接続している場合には、ＰＤＮゲートウェイとのコネクションを識別するＩＤ（PDN connection ID、ＡＰＮ）などが用いられる。

また、図８には、本発明の第２の実施の形態におけるモバイルノードの構成の一例が図示されている。図８に図示されているＭＮ６１０は、２つのインタフェース８０１、８０２、送信部８０３、受信部８０４、ハンドオーバ検出部８０５、フロー情報管理部８０６、ネットワーク状態監視部８０７、フロー情報保持部８０８、ＢＵメッセージ生成部８０９、ＢＡメッセージ処理部８１０、パケット転送部８１１、登録済み位置情報保持部８１２を有している。

インタフェース８０１、８０２の存在は、ＭＮ６１０が２つのインタフェースを有することを示している。なお、２つのインタフェース８０１、８０２は、それぞれ図６におけるＩＦ１とＩＦ２の２つのインタフェースに対応するものである。また、送信部８０３及び受信部８０４は、インタフェース８０１、８０２のそれぞれを通じてパケットの送受信を行う機能を有している。

また、ハンドオーバ検出部８０５は、インタフェース８０１又はインタフェース８０２においてハンドオーバが行われそうなことを予測あるいはハンドオーバの発生を検出し、フロー情報管理部８０６に対して、対象となるインタフェースに関する情報を通知する機能を有する。

また、フロー情報管理部８０６は、ハンドオーバ検出部８０５又はネットワーク状態監視部８０７から、インタフェース８０１又はインタフェース８０２がハンドオーバを行いそうな状態であることや、実際にハンドオーバが起きている状態、さらには、ネットワークの状態が悪化してきていることなどの通知を受けたとき、その対象であるインタフェースの使用が指定されているフローが存在するかどうか、さらにはそのフローを別のインタフェースで送受信すべきかどうかを、フロー情報保持部８０８内の情報を参照して判断する機能を有している。

例えば、インタフェース８０１に関するハンドオーバの検出がハンドオーバ検出部８０５から通知された場合、フロー情報管理部８０６は、インタフェース８０１を使用するように指定されているフローが存在し、このフローに対して指定されているインタフェース８０１とは別のインタフェース（インタフェース８０２）を使用できるかどうかを確認すべきと判断すると、ＢＵメッセージ生成部８０９に対してフロー確認用メッセージを生成し、インタフェース８０２から送信するよう指示する。このフロー確認用メッセージには、フローを特定する情報（例えばフローＩＤ）と、インタフェースを特定する情報（ＢＩＤ）とが挿入される。例えば、ここでは、フロー１の送受信にＩＦ２（ＢＩＤ２）が使用可能であるかを確認するためのフロー確認用メッセージが生成される。なお、フローに対して指定されているインタフェースが存在しない場合であっても、そのフローを別のインタフェースを使用できるかどうかを確認するべきと判断してもよい。また、フロー確認用メッセージに含める情報として、インタフェースを特定する情報（ＢＩＤ）の代わりに、そのインタフェースが接続しているネットワークを識別できる情報を含めてもよい。例えば、そのネットワークで使用しているプレフィックスまたはアドレスや、アクセス技術タイプ、アクセスネットワーク識別子（例：ＷＬＡＮのＳＳＩＤ）などが利用できる。

なお、フロー確認用メッセージの送信に使用するインタフェースとしては、インタフェース８０１に関するハンドオーバの検出が実際のハンドオーバ処理が開始される以前に発生した場合、つまりハンドオーバの検出が、インタフェース８０１がハンドオーバしそうであることを示す場合（Link going down）には、まだ接続中状態にあるインタフェース８０１を使用してもよい。また、ハンドオーバの検出が、非接続状態にあったインタフェース８０１がネットワークに接続しそうであることを示す場合（Link going up）には、接続中状態にあるインタフェース８０２を使用してもよい。また、インタフェース８０１がハンドオーバ処理を完了した直後にフロー確認用メッセージを送信してもよい。

また、ネットワーク状態監視部８０７は、ネットワーク状態を監視し、ネットワーク状態が悪化してきていることを予測又は検出した場合に、フロー情報管理部８０６に対して、ネットワークの状態の悪化によって影響を受けるインタフェースに関する情報を通知する機能を有する。なお、ネットワーク状態監視部８０７により、インタフェースの接続切り換え時だけではなく、ネットワーク状態が悪化した場合においてもフロー経路の再設定を行うことが可能となる。例えば、ネットワーク状態監視部８０７は、あるフローが使用中のインタフェースの負荷又は接続しているネットワークの負荷が高い、フローに適した通信品質が確保できない（遅延、ジッタの発生）、さらには、通信に要するコストが高いなどの条件を満たすことができていない、あるいは満たすことができなくなる可能性があると判断した場合に、そのフローの送受信を別のインタフェースへ切り替えるべき（フローのハンドオーバ／移動を実行するべき）と判断してもよい。また、ＩＦ１のみが接続されている状態から、ＩＦ１とＩＦ２の両方が接続された状態に変わった時に、ＩＦ１を引き続き利用することができたとしても、ＩＦ１よりもＩＦ２の方が適切であると判断できる場合には、ＩＦ１を使用して通信していたフローをＩＦ２へ移動させるべきと判断してもよい。

また、フロー情報保持部８０８は、例えば、あるフローに対して特定のインタフェースの使用を指定する情報や、そのフローを別のインタフェースで送受信可能かどうかを示す情報（あるいは、そのフローの送受信が可能な別のインタフェースを特定する情報）を保持する機能を有する。こうしたフロー情報保持部８０８内の情報は、フロー情報管理部８０６がフロー確認用メッセージを生成する際に参照される。

また、ＢＵメッセージ生成部８０９は、フロー情報管理部８０６の指示を受け、渡されたフローＩＤとＢＩＤを含むＢＵメッセージを生成する。このＢＵメッセージは、ＢＵメッセージに含まれるフローＩＤが、同じくＢＵメッセージに含まれるＢＩＤが割り当てられているインタフェースで送受信可能かどうかをホームエージェントに確認するためのフロー確認用メッセージとしての用途を有する。

また、ＢＡメッセージ処理部８１０は、送信したＢＵメッセージ（フロー確認用メッセージ）に対する応答としてＨＡから受信したＢＡメッセージ（フロー確認応答用メッセージ）に関する処理を行い、通知されたフロー情報をフロー情報保持部８０８に保持させる機能を有する。ＨＡから通知されるフロー情報には、例えば、あるフローが既存のフロー情報では指定されていない別のインタフェースで送受信可能であるかどうか（ＢＵメッセージに含まれるフローＩＤが、同じくＢＵメッセージに含まれるＢＩＤが割り当てられているインタフェースで送受信可能かどうか）を示す情報が含まれる。

また、パケット転送部８１１は、パケット転送に係る制御機能を有しており、あるフローの送信に使用するインタフェースを指定することが可能である。パケット転送部８１１は、フロー確認応答メッセージにおいて、あるフローが別のインタフェースで送受信可能である旨が通知された場合には、フロー確認用メッセージで確認された結果である新たなフロー情報を参照し、フローの送信に使用するインタフェースとして別のインタフェース（フロー情報によって許可されたインタフェース）を選択して、パケット転送を行う。

また、登録済み位置情報保持部８１２は、ＣｏＡ（あるいはＢＩＤ）とＨｏＡとのバインディングや、そのバインディングを登録した対象ノードなどに関する情報を保持する機能を有している。

また、図１２には、本発明の第２の実施の形態におけるバインディングアップデートメッセージを用いたフロー確認用メッセージのフォーマットの一例が図示されている。フロー確認用メッセージは、例えば、図１２に図示されているように、モビリティヘッダ内のモビリティオプション（フロー確認オプション）によって実現することが可能である。フロー確認オプションの中には、フローＩＤ及びＢＩＤが挿入される。

なお、フロー確認用メッセージは任意の方法及び任意のフォーマットよって実現可能であり、例えば、モビリティオプションの代わりに、ＭＮがＨＡへフロー情報を通知する際に使用するフローＩＤオプションを使用してフロー確認用メッセージを実現してもよい。また、フロー確認用メッセージとして、ＢＵメッセージの代わりに、ＭＮが複数のＣｏＡをＨＡへ登録しているときに、ＨＡが転送先として使用するＣｏＡを指定するためのフロー情報を通知するためのメッセージ（ＭＮからＨＡにフロー情報を通知するためのメッセージ）を用いてもよく、他のメッセージとは異なる専用のフロー確認用メッセージや、情報サーバへのネットワーク情報要求メッセージなどを用いてもよい。

また、図１０には、本発明の第２の実施の形態において、自身のインタフェースにおける接続切り換え（ハンドオーバ）が検出された際のＭＮの判断処理の一例が図示されている。

図１０において、例えば、ハンドオーバ検出部８０５においてＭＮのインタフェース（ＩＦ１）におけるハンドオーバが検出された場合（ステップＳ１００１）には、ＩＦ１を使用することが指定されているフローが存在するかどうかを確認し（ステップＳ１００２）、そのようなフロー情報が存在する場合には、さらに、そのフローが、パケットロスや遅延、ジッタなどの影響をできるだけ抑えたいフローであるかどうか、つまり、そのフローの送受信を別のインタフェース（ＩＦ２）に切り換えるべきかどうかを確認する（ステップＳ１００３）。

その結果、別のインタフェース（ＩＦ２）で送受信すべきという判断がなされた場合には、その別のインタフェース（ＩＦ２）に関する位置情報がＨＡに登録済みであるかどうかを確認する（ステップＳ１００４）。位置情報が登録済みである場合には、別のインタフェース（ＩＦ２）を使って送受信可能なフローであるかどうかを確認するためのフロー確認用メッセージを送信し（ステップＳ１００５）、位置情報が登録済みではない場合には、位置情報の登録を行うためのＢＵメッセージを送信してから（ステップＳ１００６）、フロー確認用メッセージを送信する（ステップＳ１００５）。なお、ステップＳ１００５で送信されるフロー確認用メッセージとステップＳ１００６で送信されるＢＵメッセージとをまとめて１つのＢＵメッセージで実現してもよい。

なお、ステップＳ１００２でＩＦ１を使用することが指定されているフローが存在しないと判断された場合や、ステップＳ１００３で別のインタフェース（ＩＦ２）に切り換えるべきではないと判断された場合には、特別な処理を行うことなく処理は終了となる（ステップＳ１０９９）。

また、フロー情報保持部８０８に保持される各フロー情報にフロータイプが付加されて管理されてもよい。すなわちこの場合、フロー情報保持部８０８内にフロー情報が保持されるとともに、各フロー情報のフロータイプも保持されるようになる。

このフロータイプは、ＨＡがＭＮへ送信するフロー情報にセットされる情報であり、例えば２種類のタイプが存在する。第１のタイプでは、インタフェースが接続するネットワークに対してフローが関連付けられている。すなわち、第１のタイプは、ハンドオーバして接続ネットワークが切り換わった場合、そのフロー情報で指定されたフローが、接続切り換え後のネットワークで送受信できなくなる可能性があるフローである。なお、この第１のタイプのフローは、ＣｏＡの変更によってフロー情報が変更する可能性があるものであり、以降、CoA-bindフローと呼ぶことにする。

一方、第２のタイプでは、インタフェースに対してフローが関連付けられている。すなわち、第２のタイプは、ハンドオーバして接続ネットワークが切り換わった場合でも、指定されているインタフェースを変更できないフローである。なお、この第２のタイプのフローは、ＣｏＡが変更されてもそのまま使用可能なフロー情報であり、以降、BID-bindフローと呼ぶことにする。

このフロータイプの違いは、ＨＡからＭＮに送信されるフロー情報通知メッセージの中の各フロー情報に対してフラグ（フロータイプフラグ）をセットすることで表現可能である。例えば、フロータイプフラグがセットされている場合はCoA-bindフロー、フロータイプフラグがセットされていない場合はBID-bindフローと判断できるようにする。

フロー情報管理部８０６は、ハンドオーバ検出部８０５又はネットワーク状態監視部８０７からインタフェースの状態に変化が生じた旨の通知を受けると、そのインタフェースを使用するよう指定されているフロー情報の存在を確認する。このようなフロー情報が存在する場合には、フロー情報管理部８０６は、そのフロー情報のフロータイプフラグを確認する。

そして、このフロー情報のフロータイプフラグがセットされている場合（すなわち、CoA-bindフローの場合）には、接続するネットワークによってはそのフローが送受信できなくなる可能性があることが分かり、ハンドオーバが行われそうな段階やハンドオーバの完了前の段階で、ハンドオーバ中のパケットロスなどの影響を抑えるためだけでなく、ハンドオーバ後にパケットの送受信ができなくなることを未然に防ぐために、ＭＮはそのフローに対して使用するインタフェースを切り換えることができると判断することが可能となる。

一方、このフロー情報のフロータイプフラグがセットされていない場合（すなわち、BID-bindフローの場合）には、そのフローは、接続するネットワークによらずそのインタフェースを使用して送受信するフローであることが分かり、ＭＮはそのフローに対して使用するインタフェースを切り換える必要がないと判断することが可能となる。

また、図１１には、本発明の第２の実施の形態において、フロー情報に付加されているフロータイプフラグを確認する場合のＭＮの判断処理の一例が図示されている。

図１１において、例えば、ハンドオーバ検出部８０５においてＭＮのインタフェース（ＩＦ１）におけるハンドオーバが検出された場合（ステップＳ１１０１）には、ＩＦ１を使用することが指定されているフローが存在するかどうかを確認し（ステップＳ１１０２）、そのようなフロー情報が存在する場合には、そのフローのフロータイプフラグがセットされているか（CoA-bindフローか）を確認し（ステップＳ１１０３）、CoA-bindフローの場合には、さらに、そのフローが、パケットロスや遅延、ジッタなどの影響をできるだけ抑えたいフローであるかどうか、つまり、そのフローの送受信を別のインタフェース（ＩＦ２）に切り換えるべきかどうかを確認する（ステップＳ１１０４）。

その結果、別のインタフェース（ＩＦ２）で送受信すべきという判断がなされた場合には、その別のインタフェース（ＩＦ２）に関する位置情報がＨＡに登録済みであるかどうかを確認する（ステップＳ１１０５）。位置情報が登録済みである場合には、別のインタフェース（ＩＦ２）を使って送受信可能なフローであるかどうかを確認するためのフロー確認用メッセージを送信し（ステップＳ１１０６）、位置情報が登録済みではない場合には、位置情報の登録を行うためのＢＵメッセージを送信してから（ステップＳ１１０７）、フロー確認用メッセージを送信する（ステップＳ１１０６）。なお、ステップＳ１１０６で送信されるフロー確認用メッセージとステップＳ１１０７で送信されるＢＵメッセージとをまとめて１つのＢＵメッセージで実現してもよい。

なお、ステップＳ１１０２でＩＦ１を使用することが指定されているフローが存在しないと判断された場合、ステップＳ１１０３でフローフラグタイプがBID-bindフローの場合、ステップＳ１１０４で別のインタフェース（ＩＦ２）に切り換えるべきではないと判断された場合には、特別な処理を行うことなく処理は終了となる（ステップＳ１１９９）。

また、１つのフローに対して複数のＢＩＤが関連付けられているフロー情報（例えばフロー１に対してＢＩＤ１とＢＩＤ２が関連付けられている）がＨＡから通知された場合、ＭＮは、ハンドオーバなどの理由によって、ＢＩＤ１が示すＩＦ１を使用して送受信していたフロー１を別のＩＦに切り換えたいと判断した場合に、ＢＩＤ２が示すＩＦ２を切り換え先のインタフェースとして使用可能であると判断することができる。

このとき、ＢＩＤ２が示すＩＦ２の接続状態やネットワーク状態が頻繁に変化する場合には、たとえ第２のＩＦとしてＢＩＤ２が付加されていたとしても、第２のＩＦとしてのＢＩＤ２に何らかの変化が生じた場合には、その都度ＨＡがＭＮへ通知する必要がある。このため、このような状態になったときには、ＨＡから通知を受けるのではなく、ＭＮは、第２のＩＦの存在を知る必要が生じた場合にフロー確認用メッセージを送信し、その時点でＩＦ２がフロー１の送受信インタフェースとして使用可能であるかを確認するように動作を切り換えることも可能である。この動作の切り換えは、ＭＮ側の判断でＨＡに対してフロー情報通知の停止を要求してもよく、ＨＡ側の判断でＭＮ６１０に対して、ＭＮ６１０側からフロー確認用メッセージの送信が必要であることを通知してもよい。

また、図９には、本発明の第２の実施の形態におけるホームエージェントの構成の一例が図示されている。図９に図示されているＨＡ６４０は、インタフェース９０１、送信部９０２、受信部９０３、ＢＵメッセージ処理部９０４、フロー情報制御部９０５、ＢＡメッセージ生成部９０６、ＭＮ管理情報保持部９０７を有している。

インタフェース９０１は、ＨＡ６４０が有するインタフェースであり、送信部９０２及び受信部９０３は、インタフェース９０１を通じてパケットの送受信を行う機能を有している。

また、ＢＵメッセージ処理部９０４は、ＭＮから受信したフロー確認用メッセージとしての役割を果たすＢＵメッセージに関する処理を行う機能を有している。例えば、ＭＮから受信したＢＵメッセージがフロー確認用メッセージとしての役割を有している場合には、ＢＵメッセージ処理部９０４は、ＢＵメッセージに含まれているフローＩＤ及びＢＩＤをフロー情報制御部９０５へ渡し、フローＩＤが示すフローを、ＢＩＤが示すＭＮのインタフェースを使用して送受信することが可能かどうかを判断するよう指示する。

また、フロー情報制御部９０５は、ＨＡが管理するＭＮに通知するフロー情報に関する制御を行い、ＭＮから通知されたフローＩＤ及びＢＩＤから、そのフローＩＤが示すフローを、ＢＩＤが示すインタフェースを使用して送受信することが可能かどうかを判断する機能を有している。

あるフローＩＤが示すフローを、ＢＩＤが示すインタフェースを使用して送受信することが可能であると判断されると、フロー情報制御部９０５は、ＢＡメッセージ生成部９０６に対して、送受信可能であることを示す情報を含むＢＡメッセージを生成するよう指示する。一方、送受信が不可能であると判断されると、フロー情報制御部９０５は、ＢＡメッセージ生成部９０６に対して、送受信不可であることを示す情報を含むＢＡメッセージを生成するよう指示する。

なお、ＭＮから通知されたＢＩＤが示すインタフェースでは送受信不可であると判断された場合に、ＭＮの他のインタフェース（例えば、ＩＦ１やＩＦ２以外に第３のインタフェースなど）で送受信可能である場合には、そのインタフェースが使用可能であることをＭＮへ通知するために、そのインタフェースを示すＢＩＤをＢＡメッセージに含めるよう指示してもよい。

また、あるフローがあるＢＩＤが示すインタフェースを使用して送受信可能かどうかの判断は、例えば、ＭＮ管理情報保持部９０７が保持するＭＮ６１０の位置情報を参照し、ＢＩＤが関連付けられているＭＮのＣｏＡのプレフィックスから接続しているネットワークを識別し、そのネットワーク上で通知されたフローの送受信が許可されるかどうかをチェックすることにより行うことが可能である。

また、フロー情報制御部９０５は、ＭＮ６１０からのＢＵメッセージ（フロー確認用メッセージ）を受信していなくても、新規のフロー情報や、変更のあったフロー情報をＭＮへ通知するためのフロー情報通知メッセージを生成するようＢＡメッセージ生成部９０６に対して指示することが可能である。

また、ＢＡメッセージ生成部９０６は、フロー情報制御部９０５からの指示に従って、あるフローＩＤが示すフローをあるＢＩＤが示すインタフェースを使用して送受信することが可能かどうかを示す情報を含むＢＡメッセージ（フロー確認応答メッセージ）を生成する機能を有している。

なお、ＢＵメッセージ処理部９０４及びＢＡメッセージ生成部９０６は、ＭＮから受信した通常のモバイルＩＰに係るＢＵメッセージの処理やＢＡメッセージの生成を行う機能も有しており、ＭＮ管理情報保持部９０７においてＭＮの位置情報を管理することで、ホームエージェント機能が実現される。

以上、説明したように、本発明の第２の実施の形態によれば、例えばホームエージェントから通知されているフロー情報に従ってＩＦ１を使用してパケットの送受信を行っていたフロー１に関して、モバイルノードのＩＦ１がハンドオーバする際に、フロー１をＩＦ２で送受信するべきかどうかを判断し、さらに、ＨＡに対して、フロー１をＩＦ２が接続するネットワーク経由で送受信することが可能であるかどうかを確認したうえで、使用するＩＦを切り換えることができるため、ＩＦ１がハンドオーバ中に発生するパケットロスや、遅延、ジッタなどの影響を軽減することができる。また、モバイルノードが、ＣｏＡの変更によってフロー情報が変更する可能性があるフロー（CoA-bindフロー）と、ＣｏＡが変更されてもそのまま使用可能なフロー（BID-bindフロー）とを判別することで、ＣｏＡの変更の影響を受けるフロー（CoA-bindフロー）をフロー再構成の対象として選択することが可能となる。なお、本発明の第２の実施の形態におけるＨＡ６４０がＭＮ６１０の位置情報を保持する機能は、ネットワーク上に存在する情報サーバによって実現されてもよい。

＜第３の実施の形態＞
次に、本発明の第３の実施の形態について説明する。本発明の第３の実施の形態と第２の実施の形態の主な違いは、第２の実施の形態では、あるフローの送受信に、ＭＮ６１０が知得しているネットワークを用いることが可能か否かを確認する方法が行われるのに対して、第３の実施の形態では、ＭＮ６１０はフロー情報のみを通知し、そのフローに対して利用可能なネットワークに関する情報を取得する方法が行われるという点である。なお、第３の実施の形態では、フローに関する情報としては、ＭＮ６１０が行う通信を識別できる任意の情報を用いることができる。例えば、フローＩＤや、通信相手のアドレス、プロトコル番号、セッションＩＤ、コネクションＩＤなどがある。特に、３ＧＰＰネットワークへ接続している場合には、ＰＤＮゲートウェイとのコネクションを識別するＩＤ（PDN connection ID、ＡＰＮ）などを用いることができる。

本発明の第３の実施の形態におけるＭＮ６１０は、１つ又は複数のインタフェースを用いてネットワークに接続しており、自身が送受信している、あるいはこれから送受信を開始するフローに関する情報をネットワーク情報管理サーバ（ＨＡ６４０、あるいはネットワーク上の情報サーバ）へ送信し、そのフローを送受信するのに適切なネットワークを選択する際に有効な情報（アクセスネットワーク情報）を要求する。ここでは、この要求をするメッセージをアクセスネットワーク情報要求メッセージと呼ぶ。ＭＮ６１０は、本発明の第２の実施の形態におけるハンドオーバ検出部８０５及びネットワーク状態監視部８０７と同様の判断基準でアクセスネットワーク情報要求メッセージを送信する。

例えば、ＭＮ６１０は、あるフローが使用中のインタフェースの負荷又は接続しているネットワークの負荷が高いと判断した場合に、そのインタフェースを使用している任意のフローを別のネットワークへ移動させるべきと判断し、そのフローに関する情報を含むアクセスネットワーク情報要求メッセージをネットワーク情報管理サーバへ送信する。メッセージを受信したネットワーク情報管理サーバは、通知されたフローの送受信に適切なネットワークを選択し、そのネットワークに関する情報をＭＮ６１０へ送信する。一方、ＭＮ６１０は、取得したアクセスネットワーク情報に基づいて、別のネットワークへのハンドオーバ、又は別のネットワークに接続しているインタフェースへのフローの切り替えを行う。

ここで、ＭＮ６１０がある３ＧＰＰネットワークへの接続が可能、あるいは接続中である場合を想定すると、その接続を用いて通信をしているフローを別のネットワークへ移動させると判断した場合、アクセスネットワーク情報で取得できる情報の中には、３ＧＰＰインタフェースが利用可能な別のネットワークについての情報が含まれている。また、ＭＮ６１０が３ＧＰＰネットワークと非３ＧＰＰネットワークの両方への接続が可能、あるいは接続中であるときに、３ＧＰＰネットワーク側のフローを別のネットワークへ移動させると判断した場合、取得するアクセスネットワーク情報は、非３ＧＰＰネットワークが利用可能なネットワークについての情報も含むことができる。またその逆として、非３ＧＰＰネットワーク側のフローを別のネットワークへ移動させると判断した場合、取得するアクセスネットワーク情報は、３ＧＰＰネットワークが利用可能なネットワークについての情報も含むことができる。

また、別の例として、ＭＮ６１０は、あらかじめ任意のタイミングであるフローに対するアクセスネットワーク情報を取得し、その後、そのフローの送受信を開始するときや、そのフローを送受信しているインタフェースの負荷が高まった場合などに、あらかじめ取得していたアクセスネットワーク情報を使用してもよい。例えば、アクセス認証が完了して通信が可能となった直後に、特定のフローに関するアクセスネットワーク情報を取得しておいてもよいし、通信相手からあるフローの通信が開始された後に、そのフローに関するアクセスネットワーク情報を取得しておいてもよい。

なお、上記の２つの例においては、アクセスネットワーク情報を要求した時点で、実際に接続可能なネットワークの情報を取得すること想定しているが、以下に説明するように、取得するアクセスネットワーク情報によっては、その後のネットワーク環境に変化があった場合でも、ネットワーク／インタフェースの選択に有効な情報であることも想定することができる。

取得するアクセスネットワーク情報としては、例えば、通知したフローの送受信が許可されているアクセステクノロジータイプ、またはアクセスネットワークの情報などがある。また、通知したフローに対して最も適切なアクセステクノロジータイプの情報や、優先順位付けされた複数のアクセステクノロジータイプの情報などがある。さらには、通知したフローに対して最も適切なアクセスネットワークについての情報や、優先順位付けされた複数のアクセスネットワークについての情報などもある。なお、アクセスネットワークとしては、セルラネットワークや、ＷｉＭＡＸネットワーク、ＷＬＡＮネットワーク、ＣＳＧセルなどが含まれる。

アクセスネットワーク情報要求メッセージとしては、任意のメッセージを用いることができる。例えば、モバイルＩＰのＢＵメッセージやＭＮが複数のＣｏＡをＨＡへ登録しているときに、ＨＡが転送先として使用するＣｏＡを指定するためのフロー情報を通知するためのメッセージ（ＭＮからＨＡにフロー情報を通知するためのメッセージ）を用いてもよく、専用のメッセージとして情報サーバへのネットワーク情報要求メッセージなどを用いてもよい。また、３ＧＰＰにおけるＡＮＤＳＦ（Access Network Discovery and Selection Function）によって用いられるリクエストメッセージ及びレスポンスメッセージを用いてもよい。

以上説明したように、本発明の第３の実施の形態によれば、ＭＮ６１０は、任意のフローに関する情報をアクセスネットワーク情報管理サーバへ通知して、そのフローにとって適切なネットワークの情報を取得することで、そのフローを送受信するネットワークとして適切なネットワークを使用することができ、不適切なネットワークに対してフローを送信してしまうことを防ぐことが可能となる。

なお、上述の本発明の第１〜第３の実施の形態において説明されている動作や構成を組み合わせて用いることも可能である。例えば、第１の実施の形態では、ＭＮがＨＡからフローコントロール情報を受信して保持し、必要に応じてこの情報を参照することによって、フローの再構成の要否や適切なフロー変更動作などを行っているが、第２の実施の形態ように、逐次ＨＡに問い合わせを行って必要な情報を取得することで、ドメイン限定フローが信頼ネットワーク内で伝送されるように制御することも可能である。また、例えば、第１の実施の形態において、各フローに関してCoA-bindフローか否かを示す情報がフローコントロール情報としてＲＡメッセージなどによって提供されてもよい。また、本明細書では、ＭＮのあるインタフェースがハンドオーバして別のネットワークに接続する場合について説明しているが、非接続状態であったインタフェースがネットワークに接続する場合に対しても適用可能である。さらに、本発明の第２の実施の形態と第３の実施の形態との組み合わせとして、ＭＮは、自身で検出した接続可能なネットワークに関する情報と共に、自身が送受信している、あるいは送受信するフローに関する情報をネットワーク情報管理サーバへ送信し、それらのネットワークの中から通知したフローを送受信するのに適切なネットワークを選択するよう要求することもできる。

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

例えば、ネットワークフロープロファイル１３ａ及びフローコントロール情報１３ｂに記載されるパラメータは、本明細書で言及されているものに限定される必要はない。ネットワークフロープロファイル１３ａ及びフローコントロール情報１３ｂには、フロー要件やネットワーク特性が記録されてもよい。

また、上述の実施の形態では、ＢＩＤを用いて、対象となるインタフェース及びそのインタフェースが接続しているネットワークを特定しているが、ＢＩＤの代わりにＣｏＡや接続先ネットワークを示すＩＤなどを用いてもよい。また、ＨＡが有する機能を、フロー情報を管理・保持する情報サーバやＡＡＡサーバ、あるいは通信相手などが保持していてもよい。

さらに、上述の実施の形態では、ＭＮ１０がＢＵ内のフラグ（Ｖフラグ５２）を用いて、ネットワークフロープロファイル１３ａがフローコントロール情報１３ｂを参照してアップデートされた旨をＨＡ２２に通知しているが、ＢＵ内のフラグの代わりに、ノンス（nonce）や秘密の数字（secret number）、クッキー（cookie）などが用いられてもよい。

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

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

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

本発明の移動端末並びに移動端末により実行される方法は、オペレータがポリシに基づいて規定したフロー情報に従って通信を行っている複数のインタフェースを有するモバイルノードが、フローにとって適切なインタフェースを選択して通信を行うことができるようになるという効果を有しており、ＩＰを利用した通信技術や、フローの経路を変更するルーティング技術などに適用可能である。

Claims (2)

1. 複数のインタフェースでトラフィックフローをルーティング可能な場合に、前記トラフィックフローをルーティングするためのアクセスネットワークを選択することができる移動端末であって、
   特定の前記アクセスネットワークでのみ送受信可能な前記トラフィックフローを識別するためのフロー識別情報と前記アクセスネットワークを識別するためのネットワーク識別情報を含むフロー情報であって、前記移動端末に与えられている前記フロー情報に基づいて、前記複数のインタフェースの１つを介して送受信を行っている前記トラフィックフローがルーティングされることが可能なアクセスネットワークを選択する選択手段と、
   前記トラフィックフローを元のアクセスネットワークから前記選択されたアクセスネットワークに移す移動手段とを、
   有する移動端末。
2. 複数のインタフェースでトラフィックフローをルーティング可能な移動端末が前記トラフィックフローをルーティングするためのアクセスネットワークを選択する方法であって、
   特定の前記アクセスネットワークでのみ送受信可能な前記トラフィックフローを識別するためのフロー識別情報と前記アクセスネットワークを識別するためのネットワーク識別情報を含むフロー情報であって、前記移動端末に与えられている前記フロー情報に基づいて、前記複数のインタフェースの１つを介して送受信を行っている前記トラフィックフローがルーティングされることが可能なアクセスネットワークを選択するステップと、
   前記トラフィックフローを元のアクセスネットワークから前記選択されたアクセスネットワークに移すステップとを、
   有する方法。