JPWO2010016241A1

JPWO2010016241A1 - プレフィックス割り当て管理システム及び移動端末並びにプレフィックス割り当て管理装置

Info

Publication number: JPWO2010016241A1
Application number: JP2010523758A
Authority: JP
Inventors: 平野　純; 純平野; ンー　チャン　ワー; チャンワーンー; チュンキョンベンジャミンリム; モハナダマヤンティジャヤタラン
Original assignee: Panasonic Corp; Matsushita Electric Industrial Co Ltd
Current assignee: Panasonic Corp; Panasonic Holdings Corp
Priority date: 2008-08-06
Filing date: 2009-08-04
Publication date: 2012-01-19
Also published as: EP2312875A1; CN102113357A; WO2010016241A1; US20110134869A1

Abstract

複数のアクセス技術を有する移動端末がローカルネットワークのモビリティ管理ドメイン内を移動する場合に、移動端末に割り当てられるプレフィックス数をできるだけ少なくする技術が開示され、その技術によれば移動端末（ＭＮ１００）が通信を行うために必要なプレフィックスがＭＮへ割り当てられるように管理し、モビリティ管理ドメイン１１０は、ＭＮが通信を行うために必要なプレフィックスのみを維持する。例えば、ＭＮはプレフィックス変更が必要となる状態を検出すると（ステップＳ１２０）、ＭＮにとって必要なネットワークプレフィックスがＭＮへ割り当てられる状態を判断し、この状態を実現するためのプレフィックスプリファレンスをモビリティ管理ドメインへ通知する（ステップＳ１５０）。プレフィックスプリファレンスには、不要なプレフィックスの削減要求、別のインタフェースでの再利用要求、別のＭＮでの使用を示すリサイクル要求等が含まれる。

Description

本発明は、パケット交換型データ通信ネットワークにおける通信技術に関する。本発明は、特に、通信相手ノードと通信を行う移動端末が複数のアドレスを有する場合と、ネットワークドメインがネットワークベースのローカルモビリティ管理を行っている場合におけるプレフィックス割り当て管理システム及び移動端末並びにプレフィックス割り当て管理装置に関する。

現在、多数のモバイル機器（ＵＥ：ユーザ機器、以下、モバイルノードも同義の用語とする）が、インターネットプロトコル（ＩＰ；Internet Protocol）を用いて相互に通信を行っている。モバイル機器のモビリティサポートを実現するため、ＩＥＴＦ（Internet Engineering Task Force）では、モビリティサポートに関する技術（下記の非特許文献１を参照）が進展してきた。

非特許文献１に開示されているモバイルＩＰでは、各モバイルノードは不変のホームドメインを有している。モバイルノードがホームネットワークに接続されている場合には、ホームアドレス（ＨｏＡ：Home Address）と呼ばれるプライマリグローバルアドレスがモバイルノードに割り当てられる。一方、モバイルノードがホームネットワークから離れている場合、すなわち、別の外部ネットワーク（foreign network）に接続されている場合には、通常、気付アドレス（ＣｏＡ：Care-of Address）と呼ばれる一時的なグローバルアドレスがモバイルノードに割り当てられる。

モビリティサポートの考え方は、モバイルノードが別の外部ネットワークに接続されている場合であっても、ホームアドレスによってモバイルノードに到達可能となるようにすることである。これは、非特許文献１において、ホームネットワークへのホームエージェント（ＨＡ：Home Agent）と呼ばれるエンティティの導入によって実現される。モバイルノードは、バインディングアップデート（ＢＵ：Binding Update）と呼ばれるメッセージを用いて、自身の気付アドレスをホームエージェントへ登録する。これにより、ホームエージェントは、モバイルノードのホームアドレスと気付アドレスとの関連（バインディング）を作成することが可能となる。ホームエージェントは、モバイルノードのホームアドレスあてのメッセージを受信（intercept）し、パケットカプセル化を利用してモバイルノードの気付アドレスへパケットを転送する機能を有する。なお、パケットカプセル化は、パケットを新たなパケットのペイロードに配置することであり、パケットトンネリングとも呼ばれる。

モバイルＩＰによってモビリティの問題は解決するが、別の問題が生じることになる。例えば、モバイルノードは、ＢＵメッセージをホームエージェントへ送信する必要が生じ、モバイルノードが速い速度で移動している場合には接続ポイントの変更も頻繁に起こるため、生成及び送信されるＢＵメッセージの数がかなり多くなってしまう。また、モバイルノードからホームエージェントまでの距離が長くなってしまう可能性があり、その結果、モバイルノードから送信されたＢＵメッセージがホームエージェントに到達するまでに時間を要してしまう可能性がある。ホームエージェントが、ＢＵメッセージによるモバイルノードの更新後の気付アドレスへのパケット転送を開始するまでに、モバイルノードは、その場所（ＢＵメッセージによって更新される気付アドレス）から離れてしまうかもしれない。

このような理由から、下記の非特許文献２や下記の特許文献１、２に記載されているようなネットワークベースのローカルモビリティ管理（ＮｅｔＬＭＭ：network based local mobility management）を利用する提案が行われている。このＮｅｔＬＭＭでは、モバイルノードは、ローカルネットワークドメイン内で接続ポイントを変更する場合に同一のアドレスを使用し続けることが可能であり、ＢＵメッセージをモバイルノードのホームエージェントへ頻繁に送信する必要がなくなる。

ここでは、ローカルモビリティアンカ（ＬＭＡ：Local Mobility Anchor）、多数のモバイルアクセスゲートウェイ（ＭＡＧ：Mobile Access Gateway）、ＡＡＡ（Authentication, Authorization and Accounting：認証、認可及び課金処理）サーバがローカルネットワークドメインに配置されることで、ネットワークベースのローカルモビリティ管理が提供される。

ＭＡＧは、モバイルノードが接続するアクセスルータとして機能する。モバイルノードがＭＡＧへ接続するたびに、ＭＡＧは、まずＡＡＡサーバによって資格の検証を行い、モバイルノードがローカルモビリティドメインのサービスの利用に関して認可されているか否かを確認する。次に、ＡＡＡサーバは、モバイルノードが割り当てられるべきアドレス又はプレフィックス（ネットワークプレフィックス）に関する情報をＭＡＧへ通知する。これにより、ＭＡＧは、ホームネットワークプレフィックス（ＨＮＰ：Home Network prefix）と呼ばれるモバイルノード固有のプレフィックスをモバイルノードへ通知することが可能となる。

同時に、ＭＡＧは、ローカルモビリティアンカのアップデートを行うことで、モバイルノードへ割り当てられたプレフィックスあてのパケットが、モバイルノードが現在接続されている適切なＭＡＧへトンネル可能となるようにする必要がある。これは、ＭＡＧがプロキシバインディングアップデート（ＰＢＵ：Proxy Binding Update）メッセージをＬＭＡへ送信することによって行われる。ＬＭＡは、このＰＢＵメッセージに基づいて、モバイルノードが使用するアドレスとＭＡＧのアドレスとの関連付けを行う。この方法は、ＭＡＧがモバイルノードのプロキシとしてＢＵメッセージの送信を行い、ＬＭＡがローカルネットワークドメインにおけるモバイルノードのホームエージェントとして機能することから、プロキシモバイルＩＰと呼ばれることもある。

このように、モバイルノードが現在どのＭＡＧに接続されているかにかかわらず、モバイルノードは、常に同一のホームネットワークプレフィックスの通知を受けるため、アドレスを変更する必要がない。その結果、モバイルノードは、ローカルモビリティドメイン内に存在している限りは、ＢＵメッセージをホームエージェントへ頻繁に送信する必要がなくなる。実際、モバイルノードが異なるネットワークドメイン間を移動する際にアドレスの到達可能性を維持しなくてもよい場合又は、同一のローカルネットワークドメイン内でのみ移動を行う場合（同一のローカルネットワークドメインから離れない場合）には、モバイルノードは、グローバルホームエージェントを有する必要もなく、また、ＢＵメッセージを送信する必要もない。

また、ネットワークベースのローカルモビリティ管理と同様の考え方は、例えば、下記の特許文献３、４又は下記の非特許文献３に記載されている階層的モバイルＩＰｖ６（Hierarchical Mobile IPv6）のように、モバイルノードがローカルアンカポイントへバインディングアップデートを送信することによっても実現可能である。

一方、様々な無線技術が現在進展しており、例えば、ＵＭＴＳ（Universal Mobile Telecommunications System）セルラーインタフェース（cellular interface）、無線イーサネット（登録商標）８０２．１１インタフェース、ＷｉＭａｘ８０２．１６インタフェース、ブルートゥース（登録商標）インタフェースなどの多数の様々なアクセスインタフェースを備えるモバイル機器が増加するであろう。こうした複数のインタフェースを有する機器をローカルモビリティ管理においてサポートするための方法として、例えば、下記の特許文献５に記載の技術のように、複数のアドレスや複数のプレフィックスを割り当てる方法が挙げられる。

また、一般的に、負荷バランスのために、ＮｅｔＬＭＮドメインのようなローカルモビリティ管理ドメインには複数のＬＭＡが配置されることがある。例えば、配置された各ＬＭＡが、ＮｅｔＬＭＮドメインに接続されている１つ又は複数のパケットデータネットワーク（ＰＤＮ：Packet Data Network）を管理し、また、ＮｅｔＬＭＮドメインにはＰＭＩＰｖ６プロトコルが実装される場合が考えられる。これらのパケットデータネットワークによって、モバイルノードは、ＮｅｔＬＭＮドメインで異なるタイプのデータサービスを取得することが可能となる。また、モバイルノードは１つ又は複数のＰＤＮからサービスを取得することができる。

このようなＰＤＮサービスの使用は、静的に構成されてもよく、モバイルノードによって動的に交渉されてもよい。静的に構成された場合には、静的な構成に関連したサービス（デフォルトのサービス）に関して、モバイルノードが明示的に要求することなく、デフォルトのサービスに関するＰＤＮの接続がシステムによって確立される。一方、非デフォルトのＰＤＮサービス又は動的に取り決められた（追加の）サービスに関しては、モバイルノードは、特別なサービス又は接続時にＰＤＮとの接続を要求する必要があるかもしれない。要求されたサービスは、モバイルノードに提供されることになる。

このようなタイプのＰＤＮ又はサービス要求モデルは、例えば、第３世代パートナーシッププロジェクト（３ＧＰＰ）などの標準化団体で使用されている。複数のＬＭＡ及び複数のＰＤＮのシナリオでは、後述の２つの負荷バランスモデル（負荷バランスを考慮したネットワークの構成方法）が存在する。こうした負荷バランスモデルを使用することで、ＮｅｔＬＭＮドメイン内の負荷を複数のローカルモビリティアンカへ等しく（あるいは、意図的に不均等に）分散することができると考えられる。

上記の第１のモデルでは、１つ以上のＰＤＮが単一のＬＭＡによって管理され、ＬＭＡがＮｅｔＬＭＮドメイン内に配置される。この負荷分散モデルは、システム内のモバイルノードが、ある時間内、又は、ある期間の任意の点において異なるサービスを使用しており、その結果、異なるＬＭＡによって管理されることに基づいて負荷バランスが実現される。したがって、ＰＤＮサービスにアクセスする期間に異なるＬＭＡを使用することによって、複数のＬＭＡにおける負荷バランスが実現される。この負荷バランスモデルでは、ある種類のＰＤＮサービスが、常に単一のＬＭＡによって提供される。

一方、別の負荷バランスモデルは、１つ以上のＰＤＮが１群のＬＭＡによって管理されるものであり、ＮｅｔＬＭＮドメインには複数のＬＭＡ群が含まれている。このような複数のＬＭＡ群が含まれるモデル（群モデル：farm model）では、群内のすべてのＬＭＡが、その郡内の任意のＬＭＡに接続されているＰＤＮの管理を行う。この群モデルと上述のモデルとの主な違いは、群モデルでは、モバイルノードの接続状態に変更がない場合であっても、モバイルノードに関連するバインディングキャッシュが郡内のＬＭＡ間で動的に渡されるという点である。基本的に、群モデルでは、モバイルノードに提供されるＰＤＮサービス又はＰＤＮサービスへアクセスするためのプレフィックスが、複数のＬＭＡによって管理される。しかしながら、時間内の任意な点において、ＬＭＡは１つのみサービスを担当し、ＮｅｔＬＭＮドメイン内におけるモバイルノードの移動時間において郡内の様々なＬＭＡへ制御が渡される。こうした群モデルによる動作が必要な場合には、ＬＭＡに関連するバインディングキャッシュは別のＬＭＡ及びモバイルノードのインタフェースが接続されているＭＡＧへ渡されて、新たなＬＭＡへ通知される必要がある。

非特許文献４に記載されている現在のＰＭＩＰｖ６プロトコルでは、モバイルノードへ割り当てられるホームネットワークプレフィックスが複数の異なるＬＭＡによって管理され得る場合や、複数の異なるＬＭＡ間で転送され得る場合の動作は明示的にはサポートされていない。ＮｅｔＬＭＭドメインで取り扱われるプレフィックスが単一のトップレベルプレフィックスから得られるものであるならば、データルーティングに何ら影響を与えることなく、ＬＭＡ間でプレフィックスの受け渡しが行われ得る。ＬＭＡに割り当てられるプレフィックスがトポロジ的に独立したプレフィックスグループであるならば、ＬＭＡ間でのプレフィックスの受け渡しは、そのプレフィックス宛のパケットの効率的なルーティングにより実現される。

３ＧＰＰにおいては、モバイルノードのモビリティを管理する複数のＬＭＡがＮｅｔＬＭＭドメイン内に配置されることが検討されている。３ＧＰＰでの複数のＬＭＡの配置に関する詳細及びユースケースは、非特許文献５及び非特許文献６で言及されている。非特許文献５では、３ＧＰＰアクセス経由及び非３ＧＰＰアクセス経由でのモバイルノードの接続が説明されており、非特許文献６では３ＧＰＰ特有のアクセス経由でのモバイルノードの接続が説明されている。

この３ＧＰＰ特有のアクセスは、ＬＴＥ（ロングタームエヴォルーション；Long Term Evolution）アクセス、ＵＴＲＡＮ（Universal Terrestrial Radio Access network）アクセス、ＧＰＲＳ（General Packet Radio Service）アクセス、ＣＤＭＡ（Code Division Multiple Access）２０００アクセスなどである。また、上記の非３ＧＰＰアクセスは、ＷＬＡＮアクセスやＷｉＭＡＸアクセスなどである。

３ＧＰＰサービスアーキテクチャのフレームワークにおいて、３ＧＰＰコアネットワークにおけるＰ−ＧＷ（PDN Gateway）と呼ばれるＬＭＡ（Local Mobility Anchor：ローカルモビリティアンカ）が、ＰＤＮからのサービスをモバイルノードに提供するゲートウェイとして機能する。複数のＬＭＡが配置される３ＧＰＰアーキテクチャにおいても、ＬＭＡの配置やそのシナリオは３ＧＰＰのみに限定されるものではなく、任意のネットワーク（複数ＬＭＡ配置を使用し、ＰＭＩＰｖ６と同様のローカルモビリティ管理メカニズムを使用するネットワーク）に適用可能である。また、現在、３ＧＰＰシステムに対して規定されるＬＭＡの負荷バランスのアーキテクチャは多数存在する。

また、３ＧＰＰに関するアーキテクチャの一例として、例えば、単一のパケットデータネットワークが任意のＬＭＡによって管理されてもよく、複数のＬＭＡがＮｅｔＬＭＭドメインに存在してもよい。また、複数のパケットデータネットワークが単一のＬＭＡによって管理され、ＮｅｔＬＭＭドメインが複数のＬＭＡによって構成されている別のアーキテクチャも存在する。３ＧＰＰで想定される別のアーキテクチャにおいては、複数のＬＭＡの群が単一のパケットデータネットワークを管理することが可能であり、ＮｅｔＬＭＭドメインは複数のＰＤＮを管理する複数のＬＭＡ群によって構成される。また、別のアーキテクチャとして、複数のＬＭＡ群がＮｅｔＬＭＭドメインに存在しており、各ＬＭＡ群が複数のＰＤＮを管理する構成も存在する。

上述のすべてのアーキテクチャにおいて、ＮｅｔＬＭＭドメイン内の各ＭＡＧは、各ＬＭＡに対して確立されるトンネルを有しているか、あるいは、各ＬＭＡへのトンネルを動的に確立することが可能である。

複数インタフェースのモバイルノードがＮｅｔＬＭＭドメインへ接続する場合、モバイルノードは、同一ＬＭＡ又は異なるＬＭＡへ複数インタフェースを介して接続されてもよい。これは、システム内で使用される負荷バランスモデル、モバイルノードが加入するサービス（又はＰＤＮ）、群ケースのシステムによるＬＭＡ割り当てポリシー、特定のアクセス技術タイプに関連するサービスタイプに対するモバイルノードのプリファレンスなどに依存する。

複数のＬＭＡが存在する場合における同時接続動作を更に理解するため、図７Ａにおいて、複数インタフェースを有するモバイルノードがＮｅｔＬＭＭドメインへ接続しており、インタフェースに適切なプレフィックスが割り当てられている状態が図示されている。

図７Ａに図示されているＮｅｔＬＭＭドメインには、ＰＭＩＰｖ６プロトコルが実装されている。図７Ａに図示されているＮｅｔＬＭＭドメイン７０２Ａは、例えば、３ＧＰＰ特有のＰＬＭＮ（Public Land Mobile Network）である。ＮｅｔＬＭＭドメイン７０２Ａが３ＧＰＰ内のサブドメイン（すなわち、ＰＬＭＮ）の場合には、図７Ａに図示されているＭＡＧ７０７Ａは、３ＧＰＰアクセスのＭＡＧとして機能するサービングゲートウェイ（Ｓ−ＧＷ：Serving Gateway）であってもよく、あるいは、ＷｉＭＡＸアクセスネットワークのＭＡＧとして機能するアクセスゲートウェイであってもよく、非信頼ＷＬＡＮ（untrusted WLAN）アクセスのＭＡＧとして機能するｅＰＤＧ（evolved Packet Data Gateway）であってもよい。

図７Ａに示すＭＡＧ７０８Ａは、ＭＡＧ７０７Ａが管理する無線アクセスネットワーク７０４Ａとは異なるタイプの無線アクセスネットワーク７０３Ａを管理する。ＮｅｔＬＭＭドメイン７０２Ａが３Ｇに特化しているなら、ＭＡＧ７０３Ａは、例えばＳ−ＧＷ、ｅＰＤＧ、ＡＧＷなどのゲートウェイである。図７Ａでは、ＭＮ７０９Ａは２つのインタフェース（例えば、ＬＴＥインタフェースとＷｉＭＡＸインタフェース）を有しており、ＮｅｔＬＭＭドメイン７０２Ａに接続している。

ＭＮ７０９Ａは、ポイントトゥーポイント又はトンネルにより、インタフェースの一方を介してＭＡＧ７０７Ａへ直接接続する。また、ＭＮ７０９Ａは、別のインタフェース（例えば、ＷｉＭＡＸインタフェース）によってＭＡＧ７０８Ａへ接続し、さらに、ＭＡＧ７０８Ａに対して直接リンク、ポイントトゥーポイントリンク、又は、トンネルなどを保持し得る。なお、本明細書では、アクセスネットワーク７０４Ａへ接続するインタフェースは、第１インタフェース（ＩＦ１）と記載し、アクセスネットワーク７０３Ａへ接続するインタフェースは第２インタフェース（ＩＦ２）と記載することがある。

このＮｅｔＬＭＭドメイン７０２Ａでは、ＭＮ７０９Ａは、複数のＰＤＮ（例えば、ＰＤＮ７００Ａ及びＰＤＮ７０１Ａ）からサービスを取得する申し込みを行っている。これらのＰＤＮ（すなわち、ＰＤＮ７００Ａ及びＰＤＮ７０１Ａ）によって提供されるサービスは、モバイルノードが必要とするデフォルトのサービスであると考えられる。しかしながら、当業者であれば、モバイルノードが明示的な方法でサービスを要求する場合であっても、ここで説明する動作が実現されてもよいことは明らかである。

また、ＰＤＮ７００Ａは、ＬＭＡ７０５Ａによって管理されており、ＰＤＮ７０１ＡはＬＭＡ７０６Ａによって管理されていると考えられる。最初に、ＭＮ７０９ＡはＩＦ１を通じてＮｅｔＬＭＭドメイン７０２Ａに接続し、ＭＡＧ７０７に接続する。例えば拡張ＵＴＲＡＮ（Ｅ−ＵＴＲＡＮ又はＬＴＥ）におけるアクセス技術特有の動作によって接続処理がトリガされた場合には、認証に成功した後、ＭＮ７０９Ａが加入しているサービスがモビリティマネジメントエンティティ（ＭＭＥ）からＭＡＧ７０７Ａへ通知される。このＭＭＥは、ホーム加入者サーバ（ＡＡＡサーバとして機能するＨＳＳ）へのインタフェースを有しており、加入者情報（例えば、サービス）及び認証成功を示す情報が、このインタフェース経由でホーム加入者サーバからＭＭＥへ渡される。なお、ＭＮ７０９Ａが、最初ＮｅｔＬＭＭドメイン７０２Ａへ接続していると仮定すると、アクセス認証中に送信されるＨＳＳ情報には、ＭＮ７０９Ａに関連するＬＭＡのアドレスが必ずしも含まれているわけではない。

また、３ＧＰＰでは、サービス加入者情報又はサービス情報は、通常、アクセスポイントネーム（ＡＰＮ：Access Point Name）と呼ばれるパラメータによって表される。このＡＰＮ情報は、通常ＨＳＳに格納されており、認証に成功するとＭＭＥ経由でＭＡＧへ通知される。なお、ＮｅｔＬＭＭドメイン７０２ＡのＰＤＮに関連するＡＰＮ値はデフォルトのＡＰＮであり、モバイルノードは接続処理の間にこうしたＡＰＮ値を明示的に要求する必要はない。ＡＰＮ値の通知を受けると、ＭＡＧは、ＡＰＮによって特定されるサービスに関連した正しいＰ−ＧＷアドレスを特定するために、ＭＡＧに実装されている解析機能を用いてＡＰＮを解析することが可能である。

図７Ａにおいて、ＭＮ７０９Ａは、両方のＰＤＮ（ＰＤＮ７００Ａ及びＰＤＮ７０１Ａ）からのサービスに加入しているので、ＭＡＧ７０７Ａには、両方のＰＤＮに関連する両方のＡＰＮ値が通知される。ここで、ＰＤＮ７００ＡにはＡＰＮ１が対応しており、ＰＤＮ７０１ＡにはＡＰＮ２が対応しているとする。ＭＡＧ７０７Ａは、これらのＡＰＮ値（ＡＰＮ１及びＡＰＮ２）を解析してＬＭＡのアドレスを特定すると、これがインタフェースＩＦ１経由による新たな接続であることを示す適切なプロキシバインディングアップデート（ＰＢＵ）メッセージをＬＭＡへ送信する。

図７Ａに図示されている環境では、ＡＰＮ（すなわち、サービス）は単一のＰＤＮにマッピングされており、さらに、ＰＤＮが単一のＬＭＡにマッピングされている。あらかじめ実装されている機能を用いてＡＰＮの解析を行うと、ＰＤＮは単一のＬＭＡ又はＰ−ＧＷアドレスへマッピングされているので、ＡＰＮ１及びＡＰＮ２は、２つのＬＭＡアドレス（例えば、ＬＭＡ７０５Ａのアドレス及びＬＭＡ７０６Ａのアドレス）であると特定される。これにより、ＭＡＧ７０７Ａは、各ＬＭＡに対して１つずつ、２つのＰＢＵを送信して、ＮｅｔＬＭＭドメイン７０２Ａに関連するＰＤＮからのサービスへアクセスするためのプレフィックスを取得する。

これらのＰＢＵには、非特許文献４に開示されているようなハンドオフインディケータオプション（Handoff Indicator Option）が付加されており、その値がＩＦ１経由の初期接続を示す“１”にセットされている。このＰＢＵメッセージを送信した後、ＬＭＡからの応答又はプロキシバインディングアクノレッジメント（ＰＢＡ）として、シグナリングメッセージ７１０Ａ及び７１１Ａを受信する。なお、この接続はＩＦ１経由の初期接続であるため、通常は、ＰＢＵで送信されたホームネットワークプレフィックスオプションには、プレフィックス情報が埋め込まれていない。

ＬＭＡは、受信したＰＢＵのハンドオフインディケータオプションを調べる。ＰＢＵのハンドオフインディケータオプションには初期接続を示す“１”の値がセットされているので、それぞれのＰＢＡシグナリングによって、新たなプレフィックスが送信される。すなわち、ＬＭＡ７０５Ａは、ＰＢＡシグナリング７１１Ａを送信し、新たなプレフィックスをプレフィックス情報オプションに埋め込んで割り当てる。また同様に、ＬＭＡ７０６Ａは、ＰＢＡシグナリング７１０Ａを送信し、新たなプレフィックスをプレフィックス情報オプションに埋め込んで割り当てる。ＭＡＧ７０７ＡからＭＮ７０９Ａへ送信されるルータアドバタイズメント（ＲＡ）メッセージ７１４Ａには、ＰＤＮ７００ＡへアクセスするためにＬＭＡ７０５Ａから取得されたＨＮＰ、及び、ＰＤＮ７０１ＡへアクセスするためにＬＭＡ７０６Ａから取得されたＨＮＰが含まれる。

ここで、ＭＮ７０９ＡがＩＦ２をＭＡＧ７０８Ａへ接続すると仮定する。ＭＡＧ７０８Ａは、ＭＮ７０９Ａの接続に関するアクセス認証を行う。一方、ＭＡＧ７０８Ａには、ＨＳＳから送信された認証シグナリングによって、適切なＡＰＮ（ＡＰＮ１及びＡＰＮ２）が通知される。これらのＡＰＮから、ＬＭＡ７０５及びＬＭＡ７０６Ａのアドレスが解析され、ＭＡＧ７０８Ａは、図７Ａに示す各ＬＭＡへＰＢＵを送信する。

ＩＦ２が接続を行う際に、ＨＳＳが、ＩＦ１の接続完了処理によってＭＮ７０９Ａに関連するＬＭＡのアドレスを既に持っている可能性があることが重要である。図７Ａに示すＬＭＡは、通常、ＭＮ７０９Ａに関するバインディングキャッシュを作成した後に、ＨＳＳにそのアドレスを登録すると考えられる。しかしながら、ＩＦ２経由の接続が新たな接続であることから、ＭＡＧ７０８Ａは、アクセス認証及び認証処理中にＨＳＳから返ってきたＬＭＡのアドレスを、ＩＦ２に関する接続用のＬＭＡアドレスの選択処理には考慮しない。垂直ハンドオフの場合には、ＭＡＧは、ＨＳＳから返ってきたこれらのアドレスを、セッション継続性を実現するために考慮する。

また、ＰＭＩＰｖ６プロトコルアーキテクチャによって、異なるプレフィックスが異なるインタフェースに任意のＬＭＡから割り当てられるので、ＭＡＧ７０８Ａは、ＰＢＡ７１２Ａ及びＰＢＡ７１３Ａによって２つの異なるプレフィックスを受信する。ＭＡＧ７０８Ａから受信した２つのプレフィックスは、ＭＡＧ７０７Ａが取得したプレフィックスとは異なっている。

これらのプレフィックスを受信すると、ＭＡＧ７０８ＡはＲＡ７１５Ａを送信する。ＲＡ７１５Ａのプレフィックスオプションには、これらのプレフィックスが埋め込まれる。ＭＮ７０９Ａは、ＲＡ７１４Ａによって提供されたプレフィックス（例えばＰ１及びＰ３）、及び、ＲＡ７１５Ａによって提供されたプレフィックス（例えばＰ２及びＰ４）を使用して、インタフェースＩＦ１、ＩＦ２のアドレスを構成する。

図７Ａに示されているようなシナリオでは、モバイルノードは複数のインタフェースを介してシステムへ接続し、複数のインタフェース経由で任意のＰＤＮからサービスを取得しようとしている。例えば、モバイルモードは、両方のインタフェースを通じてＰＤＮのフローの通信を行うことを望んでおり、複数のインタフェース経由で任意のＰＤＮからサービスを取得しようとしているかもしれない。これにより、別のインタフェースを接続することによって、モバイルノードは、代替インタフェースを通じてＰＤＮへのフローをセットアップすることが可能である。

次に、モバイルノードが、図７Ａに示すような状態から図７Ｂに示す別の状態へ移動して、その結果、モバイルノードがＩＦ２へ接続されているアクセスネットワークへのアクセスを失ってしまった状態となるシナリオを考える。図７Ｂに示すようにＩＦ２経由の接続性を失った場合には、モバイルノードは、垂直ハンドオフのトリガを、既存のインタフェースＩＦ１に接続されているＭＡＧへ送信する。その結果、ＩＦ２に関連するフローのセッションの連続性が、ＩＦ１経由で得られるようになる。

さらにこのシナリオを理解するために、図７Ｂを参照しながら詳細に説明する。モバイルノードは、ＩＦ２を経由するアクセスネットワークへの接続性を失ってしまった場合には、そのインタフェースをシャットダウンすることが考えられる。図７Ｂには、ＭＮ７０９Ｂが最初ＩＦ１及びＩＦ２経由でＮｅｔＬＭＭドメイン７０２Ｂへ接続した状態で、ＰＤＮ７００Ｂ及びＰＤＮ７０１Ｂからサービスを取得するためにＩＦ１経由で２つのプレフィックスを取得し、さらに、ＰＤＮ７００Ｂ及びＰＤＮ７０１Ｂからサービスを取得するためにＩＦ２経由で２つのプレフィックスを取得して、アクセスネットワーク７０３Ｂへの接続性を失ったＩＦ２をシャットダウンするシナリオが図示されている。この場合、ＭＮ７０９Ｂは、ＭＡＧ７０７Ｂへ垂直ハンドオフのトリガを送信する。なお、図７Ｂでは、シグナリングの図示を単純にするために、この垂直ハンドオフのトリガは明示されていない。

ＭＡＧ７０７Ｂは、ＭＮ７０９Ｂから垂直ハンドオフのトリガを取得すると、ＭＮ７０９ＢのＩＦ１に関して、保持されているバインディングリストをチェックし、バインディングリストの検査によってＬＭＡ７０５Ｂのアドレス及びＬＭＡ７０６Ｂのアドレスを取得する。

ＬＭＡのアドレスを特定した後、ＭＡＧ７０７Ｂは、ハンドオフインディケータオプションを“２”にセットして、特定された各ＬＭＡへ１つずつ、２つのＰＢＵを送信する。ＬＭＡ７０５Ｂは、垂直ハンドオフのトリガを有するＰＢＵを受信すると、ＭＮ７０９ＢのＩＦ２へ割り当てられているプレフィックスを、ＭＮ７０９ＢのＩＦ１に関連するバインディングキャッシュエントリへ移動する。なお、同様の手続きが、ＬＭＡ７０６Ｂによっても実行される。

シャットダウンされたインタフェースに関連するプレフィックスを、ＩＦ１に関連するモビリティセッションへ移動した後、ＬＭＡ７０５Ｂは、ＰＢＡシグナリング７１０Ｂを送信する。また同様に、ＬＭＡ７０６Ｂは、ＰＢＡシグナリング７１１Ｂを送信する。ＰＢＡシグナリング７１０Ｂは、垂直ハンドオフの処理によってＩＦ１へ提供される２つのプレフィックスを有している。また同様に、ＰＢＡシグナリング７１１Ｂは、このシグナリングによって送信される２つのプレフィックスを有している。ＰＢＡシグナリングのそれぞれによって送信されたこの２つのプレフィックスは、ＩＦ１へ最初に割り当てられたプレフィックスと、垂直ハンドオフ処理によってＩＦ２からＩＦ１へ移されたプレフィックスである。

ＭＡＧ７０７Ｂは、ＰＢＡ７１０Ｂからの２つのプレフィックスとＰＢＡ７１１Ｂからの２つのプレフィックスを受信すると、４つのプレフィックスを埋め込んだＲＡシグナル７１２Ｂを送信する。ＭＮ７０９ＢからＭＡＧ７０７Ｂへ送信された上述の垂直ハンドオフのシグナリングには、ＰＤＮ７００Ｂ（ＡＰＮ１）及びＰＤＮ７０１Ｂ（ＡＰＮ２）に関連した２つのＡＰＮ値が含まれている。しかしながら、ＭＮ７０９Ｂが、ＩＦ２に関連するすべてのプレフィックスをＩＦ１経由となるよう移す場合には、このＡＰＮ情報は垂直ハンドオフのトリガに必ずしも必要となるものではない。

図７Ｂに示すようにＩＦ１へ垂直ハンドオフを実行した後、ＭＮ７０９Ｂが、ＩＦ１から新たに起動したインタフェース（すなわちＩＦ２）へ任意のサブセットのプレフィックスの垂直ハンドオフを実行しようとした場合には、ＩＦ１において複数のプレフィックスが単一のＡＰＮへ割り当てられているので、ＩＦ２へ接続されているＭＡＧへＡＰＮ情報のみを提供するだけではＩＦ２から移すべき正しいプレフィックスは特定できない。例えば、モバイルノードが図７Ａの状態から図７Ｂの状態へ移動した場合に、このような単一のＡＰＮに対して複数のプレフィックスが割り当てられる状態が起こる。基本的に、図７Ｂにおいて、ＩＦ１には、ＡＰＮ１（ＰＤＮ７００Ｂ）に関連して２つのプレフィックスが割り当てられており、ＡＰＮ２（ＰＤＮ７０１Ｂ）に関連して２つのプレフィックスが割り当てられている。したがって、プレフィックスのサブセットがＩＦ２経由で再利用される場合には、明示的なプレフィックス情報が垂直ハンドオフのトリガにおいて提供される必要がある。また、複数のＬＭＡが存在するシナリオでは、プレフィックスのサブセットを提供することによって、垂直ハンドオフのトリガが、ＮｅｔＬＭＭドメイン内の適切なＬＭＡに対して送信される必要がある。以上のことから、複数のＬＭＡが存在するシナリオにおいては、プレフィックスのサブセットを新たなインタフェースへ移すために適切な手順が行われる必要がある。

また、下記の特許文献６には、米国特許2009/0040964には、ＤＨＣＰのＲＳ又は新たなメッセージを用いてモバイルノードからＭＡＧへ送信されるアドレス割り当てのトリガとして、ＡＰＮ及び新たなモビリティ関連シグナリングを利用する方法が開示されている。このモビリティに関連するシグナリングは、すべてのモバイルノードのインタフェースに、同一のアドレスが構成される必要があることを示している。同一のアドレスを構成するための要求は、ＭＡＧからＬＭＡへ送信される。特許文献６に記載の技術は、ＬＭＡがモバイルノードのインタフェースへアドレス割り当てを行うというＰＭＩＰｖ６モデルに密接に関係している。さらに、同一アドレス割り当ての要求によって、所定のＨＮＰに関連するフローに対してマルチホームの効果が実現される。基本的に、特許文献６に記載の技術では、ＡＰＮはサービスを特定するために使用され、複数のインタフェースで同一のアドレスを構成するための要求を通知するために追加のモビリティトリガが埋め込まれる。

また、下記の特許文献７にはPCT特許出願WO 2006/010382A1には、ＭＩＰｖ４又はＭＩＰｖ６の動作を行おうとするモバイルノードが望ましいサービスを指定することによって、ホームエージェントの選択を行う方法が開示されている。この特許文献７に開示されている方法は、サービス識別子又はＡＰＮを提供することによってＰ−ＧＷの選択を可能とするものである。

国際公開公報ＷＯ２００３／１０７６００国際公開公報ＷＯ２００６／０５８２０６国際公開公報ＷＯ２００４／０３６７８６国際公開公報ＷＯ２００１／０６７７９８米国特許公開２００６／０２２７７９２米国特許公開２００９／００４０９６４国際公開公報ＷＯ２００６／０１０３８２

Johnson, D. B., Perkins, C. E., and Arkko, J., "Mobility Support in IPv6", Internet Engineering Task Force Request For Comments 3775, June 2004. Gundavelli, S., et al., "Proxy Mobile IPv6", Internet Engineering Task Force Draft draft-ietf-netlmm-proxymip6-11.txt, Feb 2008. Soliman, H. et al., "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", Internet Engineering Task Force Request For Comments 4140, August 2005. Gundavelli, S., et. al., "Proxy Mobile IPv6", Internet Engineering Task Force (IETF) Internet Engineering Task Force Request For Comments 5213, August 2008. "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Architecture enhancements for non-3GPP accesses", 3GPP TS 23.402, V8.4.1, January 2009. "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access", 3GPP TS 23.401, V8.4.1, December 2008. Muhanna, A. et. al., "Binding Revocation for IPv6 Mobility", Internet Engineering Task Force Draft, draft-ietf-mext-binding-revocation-03.txt, January 2009.

非特許文献２によれば、モバイルノードは各インタフェースにおいて様々なプレフィックスを検出し、モバイルノードが同一ネットワークドメイン内を移動する限り、プレフィックスは維持されることになる。

ネットワークベースのローカルモビリティ管理ドメイン内で異なるプレフィックスを配布するドメインへの出入りを繰り返すと、モビリティ管理ドメインに接続されている限りはネットワークプレフィックスを維持しなければならないため、モバイルノードは多数のプレフィックスを溜め込むことになる。これにより、ネットワークリソース（特にプレフィックス）が無駄に消費されることになる。

また、ＮｅｔＬＭＭドメインなどのネットワークベースのローカルモビリティ管理を行っているドメインにおいて、プレフィックスの管理を行うエンティティ（例えば、ＬＭＡ）が複数存在する場合には、そのドメインから移動端末へ割り当てられるプレフィックスを管理する本来の管理エンティティがどのエンティティであるかが迅速かつ容易には判断できなくなってしまう場合がある。

また、特許文献６に記載の技術は、ＡＰＮが複数のプレフィックスにマッピングされており、垂直ハンドオフのトリガに関連するプレフィックスのサブセットがＮｅｔＬＭＭドメイン内のＬＭＡのサブセットに属する複数のＬＭＡが存在する環境において、プレフィックスのサブセットの垂直ハンドオフを実現するために使用することはできない。

また、特許文献７に記載の技術では、初期接続に関してＰ−ＧＷの選択は可能となるが、垂直ハンドオフの際にプレフィックスのサブセットを再利用するためのＰ−ＧＷを特定する処理は行われない。ＭＩＰｖ４、ＭＩＰｖ６又はＰＭＩＰｖ６を使用して初期接続のＰ−ＧＷを選択する場合には、サービス情報又はＡＰＮ情報のみを利用すればよい。

本発明は、上述の問題を解決するため、複数のアクセス技術を有する移動端末がローカルネットワークのモビリティ管理ドメイン内を移動する場合に、移動端末に割り当てられるプレフィックス数をできるだけ少なくし、プレフィックスが効率的に利用されるようにするためのプレフィックス割り当て管理システム及び移動端末並びにプレフィックス割り当て管理装置を提供することを目的とする。また、本発明は、ローカルネットワークのモビリティ管理ドメイン内にプレフィックスの管理エンティティが複数存在している場合に、移動端末へ割り当てられるプレフィックスを管理する本来の管理エンティティがどのエンティティであるかを迅速かつ容易に判断できるようにすることで、例えば、あるインタフェースへ割り当てられているプレフィックスのサブセットを別のインタフェースで再利用できるようにすることを目的とする。

上記の目的を達成するため、本発明のプレフィックス割り当て管理システムは、ネットワークベースのローカルモビリティドメインに接続されている移動端末へのネットワークプレフィックスの割り当てを管理するプレフィックス割り当て管理システムであって、
前記移動端末が通信を行うために不要なネットワークプレフィックスが前記移動端末へ割り当てられる状態を維持しないように構成されている。
この構成により、複数のアクセス技術を有する移動端末がローカルネットワークのモビリティ管理ドメイン内を移動する場合に、移動端末にとって必要なプレフィックスが割り当てられるよう管理することで、移動端末に割り当てられるプレフィックス数をできるだけ少なくすることが可能となる。

また、上記の目的を達成するため、本発明の移動端末は、ネットワークベースのローカルモビリティドメインに接続されており、前記ローカルモビリティドメインから割り当てられるネットワークプレフィックスを用いて通信を行う移動端末であって、
前記移動端末が通信を行うために必要なネットワークプレフィックスが前記移動端末へ割り当てられる状態を検出するプレフィックス使用最適化検出手段と、
前記ネットワークプレフィックス使用最適化検出手段で検出された、前記移動端末にとって必要なネットワークプレフィックスが割り当てられた状態を実現するための情報を含むプレフィックスプリファレンス情報を、前記ローカルモビリティドメインへ通知するプレフィックスプリファレンス情報通知手段とを、
有する。
この構成により、複数のアクセス技術を有する移動端末がローカルネットワークのモビリティ管理ドメイン内を移動する場合に、移動端末にとって必要なプレフィックスが割り当てられるよう管理することで、移動端末に割り当てられるプレフィックス数をできるだけ少なくすることが可能となる。

また、上記の目的を達成するため、本発明のプレフィックス割り当て管理装置は、ネットワークベースのローカルモビリティドメインに接続されている移動端末へのネットワークプレフィックスの割り当てを管理するためのプレフィックス割り当て管理装置であって、
前記移動端末へのネットワークプレフィックスの割り当てを管理し、前記移動端末に対して割り当てられたネットワークプレフィックスと前記移動端末との対応関係を維持するプレフィックス対応維持手段と、
前記移動端末にとって必要なネットワークプレフィックスが割り当てられた状態を実現するための情報を含むプレフィックスプリファレンス情報を前記移動端末から受信した場合に、前記プレフィックスプリファレンス情報に基づいて、前記移動端末に対して割り当てられたネットワークプレフィックスと前記移動端末との対応関係を変更するプレフィックス管理手段とを、
有する。
この構成により、複数のアクセス技術を有する移動端末がローカルネットワークのモビリティ管理ドメイン内を移動する場合に、移動端末にとって必要なプレフィックスが割り当てられるよう管理することで、移動端末に割り当てられるプレフィックス数をできるだけ少なくすることが可能となる。

本発明は、上記の構成を有し、複数のアクセス技術を有する移動端末がローカルネットワークのモビリティ管理ドメイン内を移動する場合に、移動端末に割り当てられるプレフィックス数をできるだけ少なくし、プレフィックスが効率的に利用されるようにするという効果を有する。

本発明の実施の形態における動作例を示すシーケンスチャート本発明の実施の形態におけるモバイルノードの好適な機能アーキテクチャの一例を示す図本発明の実施の形態におけるプレフィックス削減モードの動作例を示すシーケンスチャート本発明の実施の形態におけるプレフィックス削減モードの動作例であり、ネットワークインタフェースのシャットダウンによって、余分なプレフィックスが発生した場合の動作例を示すシーケンスチャート本発明の実施の形態におけるプレフィックス再利用モードの動作例を示すシーケンスチャート本発明の実施の形態におけるプレフィックス再利用モードの動作例であり、１つのネットワークインタフェースに複数のプレフィックスが割り当てられており、別のネットワークインタフェースが起動する場合の動作例を示すシーケンスチャート本発明の実施の形態におけるプレフィックスリサイクルモードの動作例を示すシーケンスチャート本発明の実施の形態におけるプレフィックスリサイクルモードの別の動作例を示すシーケンスチャート本発明の実施の形態におけるシステム構成の一例を示す図図６Ａにおける動作例を示すシーケンスチャート従来の技術におけるネットワーク構成の一例を示す図図７Ａの状態からモバイルノードが移動して、ＩＦ２の接続が切断された状態を示す図本発明の実施の形態におけるプレフィックス再利用モードの動作の別の一例を示すシーケンスチャート本発明に係る拡張プレフィックス再利用方法の動作に関連するネットワークエンティティを含むネットワーク構成の一例を示す図本発明の実施の形態における拡張プレフィックス再利用モードの動作例を示すシーケンスチャート本発明の実施の形態における拡張プレフィックス再利用モードの動作の別の一例を示すシーケンスチャート本発明の実施の形態において、単一のＬＭＡに複数のＡＰＮが関連している場合のネットワーク構成の一例を示す図本発明の実施の形態において、モバイルノードによる拡張プレフィックス再利用モードの動作の一例を示すフローチャート本発明の実施の形態におけるＭＡＧの構成の一例を示す図本発明の実施の形態における拡張プレフィックス再利用モードの動作の更に別の一例を示すシーケンスチャート本発明の実施の形態におけるプレフィックスプリファレンスメッセージを含むメッセージ構造の一例を示す図

以下、本発明の実施の形態について説明する。

本発明は、上述のように、モビリティ管理ドメインに接続されているモバイルノードに割り当てられるネットワークプレフィックスが維持され続け、その結果、ネットワークリソース（特に、プレフィックス）が無駄に消費されることになるという問題に対処するものである。このような問題は、例えば、下記のような構成及び動作が行われた場合に生じる。

例えば、ＵＭＴＳインタフェースと８０２．１１インタフェースとを有するモバイルノードが、ネットワークベースのローカルモビリティ管理ドメイン（例えば、ＮｅｔＬＭＭドメイン）内を移動している状態を考える。なお、本明細書では、ＮｅｔＬＭＭドメイン及びＰＭＩＰドメインを始めとするネットワークベースのモビリティ管理ドメインを、モビリティ管理ドメインと呼ぶことにする。モバイルノードは、最初、ＵＭＴＳインタフェースに第１プレフィックスが与えられている。モバイルノードがＷｉＦｉホットスポットに入ると、モバイルノードは、その８０２．１１インタフェースを起動し、８０２．１１インタフェースには第２プレフィックスが割り当てられる。モバイルノードがモビリティ管理ドメインに接続されている限り、ネットワークプレフィックスは維持されなければならないので、モバイルノードがＷｉＦｉホットスポットを離れた場合には、第２プレフィックスは、例えばＵＭＴＳインタフェースへ移される。その結果、ＵＭＴＳインタフェース上において両方のプレフィックス（第１及び第２プレフィックス）が検出される。

続いて、モバイルノードが別のＷｉＦｉホットスポットに入った場合には、８０２．１１インタフェースに第３プレフィックスが与えられる。さらに、モバイルノードがそのホットスポットを離れると、第３プレフィックスがモバイルノードのＵＭＴＳインタフェースへ移される。その結果、ＵＭＴＳインタフェースには３つのプレフィックスが存在することになる。この処理は、モバイルノードが別のホットスポットに入るたびに繰り返し行われ、モバイルノードは、ＵＭＴＳインタフェース上に多数のプレフィックスを溜め込むことになる。

これにより、ネットワークリソース（特に、ネットワークプレフィックスのリソース）が無駄に使用されているかもしれないことは明らかである。第１に、モバイルノードは、これほどたくさんのプレフィックスを必要とせず、使用しないかもしれない。第２に、モバイルノードがモバイルＩＰｖ６ノードであれば、モバイルＩＰｖ６を使用してこれらの各プレフィックスから構成される気付アドレスをホームアドレス（ホームアドレスは、これらのプレフィックスのうちの１つから構成されてもよい）と関連付けようとするかもしれないが、モバイルノードがモビリティ管理ドメインに接続されている場合には、すべてのプレフィックスが維持される必要はないかもしれない。第３に、複数インタフェースを有するノードに対して、インタフェース数より多くの複数プレフィックスが与えられた場合には、モビリティ管理ドメインにおけるネットワークプレフィックスの利用可能リソースはすぐに使い果たされてしまい、モビリティ管理ドメインは更なるモバイルノードの接続を許容できなくなる可能性がある。

本発明では、ネットワークベースのローカルモビリティ管理ドメイン（モビリティ管理ドメイン）に接続されているモバイルノードに対して割り当てられるネットワークプレフィックスに関して、モバイルノードが通信を行うために必要なネットワークプレフィックスがモバイルノードへ割り当てられるように管理することで、モバイルノードが通信を行うために必要なネットワークプレフィックスのみを効率的にモバイルノードに割り当てるようにし、移動端末に対してできるだけ少ないプレフィックスを割り当て、かつ効率的に利用できるように維持する。なお、モバイルノードが通信を行うために必要なネットワークプレフィックスとは、モバイルノードが現在の通信に使用しているプレフィックスに加え、現在は使用されていないが予備などの目的として意図的に保持している冗長なプレフィックスも含まれる。一方、モバイルノードが通信を行うために不要なネットワークプレフィックスとは、上記以外のプレフィックスを指し、モバイルノードがどのような用途においても使用することのないプレフィックスを表している。また、本発明の方法は可能な限り、モバイルノードの通信を行うために必要最小限のネットワークプレフィックスを割り当てることを目指しているが、必要最小限であることの判断は必ずしもネットワークエンティティ単体、若しくはモバイルノード単体で（また、通信におけるある時点のみの判断で）正確に最小と判断できるものではないかもしれない（例えば、別のエンティティから見れば、又は、後になって見れば、最小ではないかもしれない）。したがって、本発明の方法では、確定的な判断だけではなく、判断に基づくプリファレンスの送受信を主に使用する。つまり、モバイルノード及びネットワークエンティティの判断の違いにより、モバイルノードの要求メッセージを否決したり、ネットワーク側の処理に対してモバイルノードが異なる要求メッセージを再送信したりすることなどが考えられる。しかしながら、このような動作は、通信におけるエラーケースの一般的なやり取りの範囲であるので、以下では説明を簡素にするため、このような動作の説明を省略する。

このようなネットワークプレフィックス割り当ての管理は、主にモビリティ管理ドメイン側の処理で実現することも可能であり、また、モバイルノードがモビリティ管理ドメインに対して通知を行うことによって実現することも可能である。

主にモビリティ管理ドメイン側で管理を行う場合には、例えば、モビリティ管理ドメイン内のネットワークノード（例えば、ＬＭＡ）がモバイルノードに割り当てられた各プレフィックスのパケットフローを監視することによって、本発明を実現することが可能である。この方法では、ＬＭＡが、パケットに使用されているアドレスのプレフィックスを監視し、一定の時間が経過しても、あるプレフィックスに関して送受信されるパケットが存在しない場合には、そのプレフィックスは削除されてもよいと判断する。これにより、モバイルノードで使用されなくなったプレフィックスをモビリティ管理ドメイン側で判断し、モバイルノードにとって必要なプレフィックスを割り当てるように管理するとともに、モバイルノードにとって不要なネットワークプレフィックスがモバイルノードへ割り当てられる状態を維持しないようにすることが可能となる。

また、モビリティ管理ドメイン側におけるポリシーコントロール（Policy Control）によって、本発明を実現することが可能である。例えば、モバイルノードのネットワークインタフェースに対して割り当てられるプレフィックスの数を制限するポリシー（Policy）を設定することで、各ネットワークインタフェースに割り当てられるプレフィックス数に上限を設け、モバイルノードに対して過剰なプレフィックス割り当てが行われないように管理することが可能である。ただし、モビリティ管理ドメインは、モビリティ管理ドメイン内を移動するモバイルノードに関するプレフィックスの連続性を維持する必要があるため、モビリティ管理ドメイン内を移動するモバイルノードの通信状態によっては、上限を超えるプレフィックス数がモバイルノードに対して割り当てられる条件が発生してしまう場合も考えられる。この場合には、例えば、モバイルノードとモビリティ管理ドメインとの間で、プレフィックスの連続性を管理するために使用されるポリシーの取り決めを行ったり、そのときの状況に応じて、削除可能なプレフィックスの交渉を行ったりすることが望ましい。

一方、モバイルノードがモビリティ管理ドメインに対して通知を行うことによってネットワークプレフィックス割り当ての管理を行う場合には、モバイルノードが、通信を行うために必要なネットワークプレフィックスが割り当てられる状態（不要なネットワークプレフィックスが割り当てられていない状態）を検出し、この状態を実現するための情報（後述のプレフィックスプリファレンス情報）を、モビリティ管理ドメインへ通知する。

例えば、図１において、モバイルノード（ＭＮ）１００はモビリティ管理ドメイン１１０内を移動している。ＭＮ１００は、まずステップＳ１２０において、プレフィックスの割り当てが間もなく変更されること（すなわち、プレフィックス変更が必要となること）を検出し、ステップＳ１５０において、プレフィックス割り当てのプリファレンスをモビリティ管理ドメイン１１０へ通知するシグナル（プレフィックスプリファレンス）を送信する。このとき、モビリティ管理ドメイン１１０は、ステップＳ１８０において、プレフィックスプリファレンスに従って、実際にプレフィックス割り当てることで応答を行ってもよい。

上述のステップＳ１２０において、ＭＮ１００は、様々な方法を用いて、間もなくプレフィックスの割り当てが変更されることを検出することが可能である。例えば、プレフィックスの割り当て変更を検出する好適な方法として、ＭＮ１００のネットワークインタフェースの起動のオン／オフを検出する方法が用いられてもよい。ＭＮ１００の接続ネットワークインタフェース数が変わった場合には、ＭＮ１００へ割り当てられるプレフィックスも変更される可能性がある。例えば、新たに接続されたネットワークインタフェース（動作がオンになるネットワークインタフェース）は新しいプレフィックスを受信する場合があり、また、動作がオフになるネットワークインタフェースに割り当てられていたプレフィックスは、ＭＮ１００の別の接続インタフェースへ再割り当てされる場合がある。

また、ステップＳ１５０でＭＮ１００から送信されるプレフィックスプリファレンスを示すシグナルは、様々な形式を取ることが可能である。

例えば、プレフィックスプリファレンスの好適な形式として、ＭＮ１００がそのネットワークインタフェースに割り当てられるプレフィックスを減らすように要求してもよい。この場合の動作に関しては、後述のプレフィックス削減モード（Reduce Prefix Mode）として後述する。

また、例えば、プレフィックスプリファレンスの別の好適な形式として、ＭＮ１００が、そのネットワークインタフェースのうちの１つに割り当てられているプレフィックスを別のネットワークインタフェースに再割り当てするよう要求してもよい。この場合の動作に関しては、後述のプレフィックス再利用モード（Reuse Prefix Mode）として後述する。

また、例えば、プレフィックスプリファレンスの更に別の好適な形式として、ＭＮ１００が、モビリティ管理ドメイン１１０内の別のモバイルノードによってプレフィックスの再利用が行われるよう要求してもよい。この場合の動作に関しては、後述のプレフィックスリサイクルモード（Recycle Prefix Mode）として後述する。

次に、本発明を実現するための装置の機能アーキテクチャについて説明する。図２には、本発明の実施の形態におけるモバイルノードの好適な機能アーキテクチャの一例が図示されている。図２に図示されているＭＮ１００は、パケットの送受信を行うための１つ又は複数のネットワークインタフェース２１０、ＭＮ１００内のプログラム（例えば、上位レイヤブロック２３０に含まれるプログラム）や適切なネットワークインタフェース２１０へのパケット転送に関する決定を行うルーティング部２２０、ネットワーク層より上位に位置するすべてのプロトコルやプログラムを包含する上位レイヤブロック２３０を有している。なお、以下では、ネットワークインタフェース２１０の表記によって１つ又は複数のネットワークインタフェース２１０を表し、ネットワークインタフェース２１０−ｎによって、複数のネットワークインタフェース２１０のうちの１つを表すことにする。

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

また、ルーティング部２２０は、上位レイヤブロック２３０の存在する適切なプログラムや、パケットを送信するための適切なネットワークインタフェース２１０へのパケット発送を決定する機能を有している。関連する技術分野で周知の用語を用いた場合、ルーティング部２２０は、ＩＰｖ４やＩＰｖ６などのレイヤ３（ネットワーク層）プロトコルを実装していることを表している。

ルーティング部２２０は、シグナル／データパス２９２を介して、適切なネットワークインタフェース２１０との間でパケットの送受信を行うことが可能である。また同様に、ルーティング部２２０は、シグナル／データパス２９４を介して、上位レイヤブロック２３０の適切なプログラムとの間でパケットの送受信を行うことが可能である。

また、上位レイヤブロック２３０は、通信プロトコルスタックにおけるネットワーク層の上位に位置するすべてのプロトコル及びプログラムを包含する機能ブロックである。上位レイヤブロック２３０には、ＴＣＰ（Transmission Control Protocol）、ＳＣＴＰ（Stream Control Transport Protocol）、ＵＤＰ（User Datagram Protocol）などの任意のトランスポートレイヤプロトコル又はセッションレイヤプロトコルや、他のノードとの通信に必要なプログラム及びソフトウェアが含まれている。上述のように、上位レイヤブロック２３０は、シグナル／データパス２９４を介して、ルーティング部２２０との間でパケットの送受信を行うことが可能である。

また、ルーティング部２２０には、ルーティングテーブル２４０、プレフィックス検出部２５０、プレフィックス管理部２６０が存在している。なお、プレフィックス検出部２５０及びプレフィックス管理部２６０は、本発明の主要な追加機能である。

ルーティングテーブル２４０にはルーティングエントリが含まれており、このルーティングエントリによって、パケットのパラメータ（例えば、パケットの送信元アドレス及びあて先アドレス）に基づくパケットの発送方法（例えば、どのネットワークインタフェース２１０からパケットを転送すべきか）がルーティング部２２０に示される。

また、プレフィックス検出部２５０は、ＭＮ１００に対するプレフィックス割り当ての変更が行われることを検出する機能を有している。プレフィックス検出部２５０によるプレフィックス割り当ての変更の検出は、例えば、ネットワークインタフェース２１０の動作がオフになる場合、ネットワークインタフェース２１０が起動する場合、上位レイヤブロック２３０からプレフィックスが不要であることを示すシグナルが送信された場合などを検出することによって可能であるが、これらに限定されるものではなく、その他の任意のプレフィックス割り当ての変更を検出する方法を用いることが可能である。

また、プレフィックス管理部２６０は、各ネットワークインタフェース２１０に割り当てられるプレフィックスを管理するとともに、必要に応じてプレフィックスプリファレンスをモビリティ管理ドメイン１１０へ送信する機能を有している。なお、上述のように、プレフィックス管理部２６０からモビリティ管理ドメイン１１０へ通知されるＭＮ１００のプレフィックスプリファレンスは、複数の好適なモードのそれぞれに応じて異なる要求を含んでいる。

プレフィックス検出部２５０は、ＭＮ１００が通信を行うために必要な最小限のネットワークプレフィックスがＭＮ１００へ割り当てられる状態を検出する（あるいは、ＭＮ１００にとって不要なネットワークプレフィックスを検出する）ことが可能であり、プレフィックス管理部２６０は、ＭＮ１００に対して必要な最小限のネットワークプレフィックスが割り当てられた状態（あるいは、ＭＮ１００にとって不要なネットワークプレフィックスが削除された状態）を実現するためのプレフィックスプリファレンス情報をモビリティ管理ドメイン１１０へ通知することが可能である。

例えば、後述のプレフィックス削減モード（Reduce Prefix Mode）では、プレフィックス検出部２５０が、ＭＮ１００の通信で不要となったプレフィックスを検出し（すなわち、不要なプレフィックスを削減することで、必要な最小限のネットワークプレフィックスが割り当てられた状態が実現されることを検出し）、プレフィックス管理部２６０が、その不要なネットワークプレフィックスをＭＮ１００に対するプレフィックス割り当てから削除するよう要求するプレフィックスプリファレンス情報をモビリティ管理ドメイン１１０へ送信する。

また、後述のプレフィックス再利用モード（Reuse Prefix Mode）では、プレフィックス検出部２５０が、ＭＮ１００の複数のネットワークインタフェース２１０のうちの１つ（第１ネットワークインタフェース）に対して既に割り当てられているプレフィックスが別のネットワークインタフェース２１０（第２ネットワークインタフェース）で再利用可能であることを検出し（すなわち、別のネットワークインタフェース２１０でプレフィックスを再利用することで、必要な最小限のプレフィックスが割り当てられた状態が実現されることを検出し）、プレフィックス管理部２６０が、再利用可能なネットワークプレフィックスを別のネットワークインタフェース（第２ネットワークインタフェース）へ割り当てるよう要求するプレフィックスプリファレンス情報をモビリティ管理ドメイン１１０へ送信する。

また、後述のプレフィックスリサイクルモード（Recycle Prefix Mode）では、プレフィックス検出部２５０が、ＭＮ１００に対して割り当てられるプレフィックスが一時的に利用されるものであることを検出し（すなわち、プレフィックスが一時的に割り当てられることによって、必要な最小限のプレフィックスが割り当てられた状態が実現されることを検出し）、プレフィックス管理部２６０が、ＭＮ１００に対して割り当てられるプレフィックスを一時的に利用することを示すプレフィックスプリファレンス情報をモビリティ管理ドメイン１１０へ送信する。

なお、プレフィックス検出部２５０及びプレフィックス管理部２６０は、プレフィックス削減モード、プレフィックス再利用モード、プレフィックスリサイクルモードのうちの１つのモードのみ実行可能であってもよく、また、複数（あるいはすべて）のモードの実行が可能であってもよい。また、例えば、プレフィックス検出部２５０は、あるプレフィックスに関して、上記の各モードのうちのいずれのモードが適切かを判断するモード判断部を有し、各プレフィックスに対して各モードを使い分けてもよい。さらに、モード判断部は、上記の各モードのうちのいずれのモードも適用しないプレフィックスを選別し、このプレフィックスに関しては、通常のプレフィックス割り当て処理が行われるようにすることも可能である。

以下、これらの各モードに関する詳細について説明する。

＜プレフィックス削減モード（Reduce Prefix Mode）＞
例えば、第１の好適なモードにおいて、ＭＮ１００はネットワークインタフェース２１０に割り当てられているプレフィックスの数の減少を要求してもよい。なお、本明細書では、この第１の好適なモードをプレフィックス削減モード（Reduce Prefix Mode）と呼ぶことにする。

図３Ａには、本発明の実施の形態におけるプレフィックス削減モードの動作例が図示されている。図３Ａにおいて、ＭＮ１００は、ステップＳ３２０で未使用のネットワークインタフェース２１０に余分なプレフィックス（使用していないプレフィックス）が割り当てられていることを検出し、ステップＳ３５０において、プレフィックス削減要求をモビリティ管理ドメイン１１０へ送信する。

図３ＡのステップＳ３５０で送信されるプレフィックス削減要求は、図１に示すプレフィックスプリファレンス（ステップＳ１５０で送信）の特定な形式であり、割り当てられている１つ以上のプレフィックスをリリース（解放）する要求を示すプレフィックスプリファレンスである。プレフィックス削減要求には、リリース対象となる特定のプレフィックスを示す情報が含まれていることが望ましい。

モビリティ管理ドメイン１１０がこのプレフィックス削減要求に同意すると、ステップＳ３８０において、プレフィックス削減要求に応じた新たなプレフィックス割り当てがプレフィックス割り当てメッセージによって通知される。具体的には、例えば、リリース対象となる特定のプレフィックスがリリースされることがプレフィックス割り当てメッセージによってＭＮ１００へ通知される。また、リリース対象のプレフィックスの有効期間（ライフタイム）が０に設定された状態でのプレフィックスの報知又は、リリース対象のプレフィックスを削除した状態での（残りの）プレフィックスの報知などによって、この通知が実現されてもよい。

なお、余分なプレフィックスが割り当てられていることをプレフィックス検出部２５０が検出するための条件は多数存在する。例えば、上位レイヤブロック２３０が、現在保持しているプレフィックスのうちの１つを使用しなくなった場合（例えば、あるプレフィックスを用いたセッションが終了した場合又は、モバイルＩＰにおいてＭＮ１００がバインディングアップデートをホームエージェントへ送信し、あるプレフィックスによって構成される気付アドレスがもはや使用されなくなった場合）を、余分なプレフィックスが発生した条件として用いてもよい。

また、例えば、モバイルノードが１つ以上のネットワークインタフェース２１０をシャットダウンした場合に、このネットワークインタフェース２１０に割り当てられているプレフィックスが余分なプレフィックスになったことを条件として用いてもよい。ＭＮ１００の通信に係るどのセッションにおいても、あるプレフィックスから構成されているアドレスが使用されていない場合には、ＭＮ１００はこの余分なプレフィックスの割り当ての削除を示すプレフィックス削減要求をモビリティ管理ドメイン１１０へ送信してもよい。図３Ｂには、ネットワークインタフェース２１０のシャットダウンによって、余分なプレフィックスが発生した場合の一例が図示されている。

図３Ｂにおいて、ＭＮ１００は、ネットワークインタフェース２１０−１（ＩＦ１）及びネットワークインタフェース２１０−２（ＩＦ２）を有している。ステップＳ３１０のＲＡ（Router Advertisement：ルータ通知）メッセージに示されているように、プレフィックスＰ１は最初ＩＦ１に割り当てられており、ステップＳ３１２のＲＡメッセージに示されているように、プレフィックスＰ２は最初ＩＦ２に割り当てられている。

ステップＳ３１４において、ＭＮ１００がＩＦ２をシャットダウンすると、モビリティ管理ドメイン１１０は、ステップＳ３１６のＲＡメッセージに示されているように、ＩＦ１に対してプレフィックスＰ２の再割り当てを行う。その結果、ＭＮ１００のＩＦ１には、２つのプレフィックスＰ１、Ｐ２が割り当てられることになる。なお、この動作は、ＭＮ１００がモビリティ管理ドメイン１１０内を移動する場合にプレフィックスの連続性を維持するためのモビリティ管理ドメイン１１０の基本的な機能である。

ここで、ＭＮ１００がプレフィックスＰ２から構成されたアドレスを実際には使用していなかった場合には、ＭＮ１００のプレフィックス検出部２５０が、ステップＳ３２０ｂに示されているように、余分なプレフィックス（すなわち、プレフィックスＰ２）が割り当てられていることを検出する。その結果、ＭＮ１００のプレフィックス管理部２６０は、ステップＳ３５０ｂにおいて、ＭＮ１００に割り当てられているプレフィックスからプレフィックスＰ２を削除するよう要求するプレフィックス削減要求をモビリティ管理ドメイン１１０へ送信する。

ステップＳ３５０ｂで送信されたプレフィックス削減要求に同意できる場合には、モビリティ管理ドメイン１１０は、ステップＳ３８０ｂにおいて、プレフィックスＰ２をＩＦ１へ割り当てないことを示す新たなルータ通知メッセージをＭＮ１００へ通知する。その結果、プレフィックスＰ２は削除され、ＭＮ１００のＩＦ１にはプレフィックスＰ１のみが割り当てられることになる。

このように、ＭＮ１００が余分なプレフィックスを必要としないことをモビリティ管理ドメイン１１０へ示すことで、モビリティ管理ドメイン１１０は、ＭＮ１００に対するプレフィックスの割り当てから余分なプレフィックスを削除することが可能となり、ネットワークリソース（プレフィックスのリソース）が節約される。以上のように、上述の本発明の実施の形態におけるプレフィックス削減モードによって、本発明の目的は達成される。

また、例えば、プレフィックス削減要求メッセージは、ＭＮ１００が３ＧＰＰアクセスネットワークからＷＬＡＮのような非３ＧＰＰアクセスネットワークにハンドオーバするときに使用してもよい。３ＧＰＰアクセスネットワークの普及状況によっては、３ＧＰＰアクセスネットワーク（例えばＬＴＥやＵＭＴＳなど）経由で３ＧＰＰコアネットワークに接続する場合に、ＭＮ１００は複数プレフィックスを保持することができる（各々のプレフィックスは対応するＰＤＮコネクションに結びつけられる）が、非３ＧＰＰアクセスネットワーク（例えばＷＬＡＮなど）経由で３ＧＰＰコアネットワークに接続する場合、ＭＮ１００は１つしかＰＤＮコネクションを生成できない。プレフィックス検出部２５０は、こうした状況からプレフィックス削減の必要性を検出してもよい。この場合、３ＧＰＰアクセスネットワークから非３ＧＰＰアクセスネットワークへのハンドオーバ（垂直ハンドオーバ）に先立ち、ＭＮ１００は３ＧＰＰアクセスネットワーク越しに取得したプレフィックスの数を１つに削減してもよく、残ったプレフィックスを非３ＧＰＰアクセスネットワークにハンドオーバさせることができる。すなわち、ハンドオーバ対象のプレフィックス（ＰＤＮコネクションに相当）をネットワークシステムによって任意に選択されることなく、ＭＮ１００が望んだプレフィックスを正しくハンドオーバさせることができ、ユーザの利便性向上を図ることができる。

＜プレフィックス再利用モード（Reuse Prefix Mode）＞
また、例えば、第２の好適なモードにおいて、ＭＮ１００は、ネットワークインタフェース２１０の１つに割り当てられているプレフィックスをＭＮ１００の別のネットワークインタフェース２１０へ再割り当てするよう要求してもよい。なお、本明細書では、この第２の好適なモードをプレフィックス再利用モード（Reuse Prefix Mode）と呼ぶことにする。

図４Ａには、本発明の実施の形態におけるプレフィックス再利用モードの動作例が図示されている。図４Ａにおいて、ＭＮ１００は、ステップＳ４２０で１つ以上のプレフィックスが別のネットワークインタフェース２１０で再利用される可能性があることを検出し、ステップＳ４５０において、プレフィックス再利用要求をモビリティ管理ドメイン１１０へ送信する。

図４ＡのステップＳ４５０で送信されるプレフィックス再利用要求は、図１に示すプレフィックスプリファレンス（ステップＳ１５０で送信）の特定な形式であり、あるネットワークインタフェース２１０に割り当てられている１つ以上のプレフィックスを別のネットワークインタフェース２１０で再利用する要求を示すプレフィックスプリファレンスである。プレフィックス再利用要求には、再利用対象となる特定のプレフィックスを示す情報が含まれていることが望ましい。

モビリティ管理ドメイン１１０がこのプレフィックス再利用要求に同意すると、ステップＳ４８０において、プレフィックス再利用要求に応じた新たなプレフィックス割り当てがプレフィックス割り当てメッセージによってＭＮ１００へ通知される。具体的には、例えば、再利用対象となる特定のプレフィックスが別のネットワークインタフェース２１０で再利用されることがプレフィックス割り当てメッセージによって通知される。

なお、プレフィックスが再利用可能であることをプレフィックス検出部２５０が検出するための条件は多数存在する。例えば、複数のプレフィックスが１つのネットワークインタフェース２１０（例えば、ネットワークインタフェース２１０−ｘ）に割り当てられており、別のネットワークインタフェース２１０（例えば、ネットワークインタフェース２１０−ｙ）が起動しようとしている場合に、ネットワークインタフェース２１０−ｘに割り当てられている複数のプレフィックスのうちの１つがネットワークインタフェース２１０−ｙに移されてもよいことをプレフィックスが再利用可能であることの条件として用いることが可能である。図４Ｂには、このように、１つのネットワークインタフェース２１０−１に複数のプレフィックスが割り当てられており、別のネットワークインタフェース２１０−２が起動する場合の一例が図示されている。

図４Ｂにおいて、ＭＮ１００は、ネットワークインタフェース２１０−１（ＩＦ１）及びネットワークインタフェース２１０−２（ＩＦ２）を有している。ステップＳ４１０のＲＡメッセージに示されているように、２つのプレフィックスＰ１、Ｐ２は最初ＩＦ１に割り当てられている。

ステップＳ４１２において、ＭＮ１００がＩＦ２を起動すると、ＭＮ１００のプレフィックス検出部２５０は、ＩＦ２上でＩＦ１のプレフィックスの再利用が可能であることを検出する。その結果、ＭＮ１００のプレフィックス管理部２６０は、ステップＳ４５０ｂにおいて、ＩＦ１に割り当てられているプレフィックスＰ２をＩＦ２上で再利用することを要求するプレフィックス再利用要求をモビリティ管理ドメイン１１０へ送信する。なお、アクティブなネットワークインタフェース（ＩＦ１及びＩＦ２）が２つ存在するので、ステップＳ４５０ｂで送信されるプレフィックス再利用要求は、ＩＦ１及びＩＦ２のどちらから送信されてもよい。

ステップＳ４５０ｂで送信されたプレフィックス再利用要求に同意できる場合には、モビリティ管理ドメイン１１０は、プレフィックスの再割り当てを行う。このプレフィックスの再割り当ては、例えば図４Ｂに図示されているように、ステップＳ４８０ｂで送信されるＲＡメッセージによってプレフィックスＰ１のみがＩＦ１へ割り当てられるとともに、ステップＳ４８０ｃで送信されるＲＡメッセージによってプレフィックスＰ２がＩＦ２へ割り当てられる。

このように、ＭＮ１００は、以前に割り当てられたプレフィックスが別のネットワークインタフェース２１０で使用されてもよいことをモビリティ管理ドメイン１１０へ示すことで、モビリティ管理ドメイン１１０は、新たなプレフィックスのリソースを使用せずに新たなネットワークインタフェース２１０に対してプレフィックスを割り当てることが可能となる。以上のように、上述の本発明の実施の形態におけるプレフィックス再利用モードによって、本発明の目的は達成される。

また、例えば、プレフィックス再利用要求メッセージは、ＭＮ１００が３ＧＰＰアクセスネットワークからＷＬＡＮのような非３ＧＰＰアクセスネットワークにハンドオーバするときに使用してもよい。３ＧＰＰアクセスネットワークの普及状況によっては、３ＧＰＰアクセスネットワーク（例えばＬＴＥやＵＭＴＳなど）経由で３ＧＰＰコアネットワークに接続する場合に、ＭＮ１００は複数プレフィックスを保持することができる（各々のプレフィックスは対応するＰＤＮコネクションに結びつけられる）が、非３ＧＰＰアクセスネットワーク（例えばＷＬＡＮなど）経由で３ＧＰＰコアネットワークに接続する場合、ＭＮ１００は１つしかＰＤＮコネクションを生成できない。プレフィックス検出部２５０は、こうした状況からプレフィックス再利用の必要性を検出してもよい。この場合、非３ＧＰＰアクセスネットワークに接続した時に、ＭＮ１００はプレフィックス再利用メッセージを非３ＧＰＰアクセスネットワーク経由で送信してもよく、これによって３ＧＰＰアクセスネットワーク経由の接続時に保有していたプレフィックスのうち、どのプレフィックスを再利用するか（ＭＮ１００がどのプレフィックスを再利用させたいのか）をネットワークに通知することができる。このようにして、ＭＮ１００は所望のＰＤＮコネクションを非３ＧＰＰアクセスネットワークにハンドオーバさせることができ、ネットワークシステムが任意に（ＭＮ１００が意図しない）ハンドオーバ対象のＰＤＮコネクションを選択する事態を回避することができる。したがって、非３ＧＰＰアクセスネットワークへのハンドオーバ時に、例えばアプリケーションが必要とするＰＤＮコネクション（プレフィックスに相当）を正しく選択することができるようになり、ユーザの利便性向上を図ることができる。

＜プレフィックスリサイクルモード（Recycle Prefix Mode）＞
また、例えば、第３の好適なモードにおいて、ＭＮ１００に割り当てられているプレフィックスをモビリティ管理ドメイン１１０内の他のＭＮ１００で使用するよう合意できるようにしてもよい。なお、本明細書では、この第３の好適なモードをプレフィックスリサイクルモード（Recycle Prefix Mode）と呼ぶことにする。

図５Ａには、本発明の実施の形態におけるプレフィックスリサイクルモードの動作例が図示されている。図５Ａにおいて、ＭＮ１００は、ステップＳ５２０でプレフィックスがプレフィックスリサイクルモードで割り当てられる必要性を検出し、ステップＳ５５０において、プレフィックスリサイクル要求をモビリティ管理ドメイン１１０へ送信する。

なお、プレフィックスがリサイクルモードで割り当てられる必要性とは、例えば、ＭＮ１００がそのプレフィックスを一時的に使用するだけで、ＭＮ１００においてそのプレフィックスが不要になった場合にはプレフィックスの連続性が維持される必要がなく（すなわち、ＭＮ１００に対して割り当てられているプレフィックスであることをそのまま維持する必要がない）、別のＭＮ１００で使用されてもよいことを示している。したがって、このプレフィックスリサイクルモードで割り当てられたプレフィックスは、ＭＮ１００に対するプレフィックスの連続性が維持されることなく、別のＭＮ１００へリサイクルされる。

図５ＡのステップＳ５５０で送信されるプレフィックスリサイクル要求は、図１に示すプレフィックスプリファレンス（ステップＳ１５０で送信）の特定な形式であり、１つ以上のプレフィックスをプレフィックスリサイクルモードで割り当てるよう要求することを示すプレフィックスプリファレンスである。

なお、モビリティ管理ドメイン１１０は、プレフィックスリサイクルモードでＭＮ１００へ割り当てるプレフィックスの種類によって、プレフィックスリサイクルモードでＭＮ１００へ割り当てたプレフィックスを回収するタイミング（例えば、後述のステップＳ５９０において発生するイベント直後）を把握することが可能であるが、より確実にそのタイミングを把握できるようにするため、ＭＮ１００がプレフィックスリサイクルモードで要求するプレフィックスの用途（あるいは、どのようなイベントの発生時にプレフィックスの返還が行われるかを示す情報）をプレフィックスリサイクル要求に含ませてもよい。また、後述の方法を用いて、最初にモビリティ管理ドメイン１１０からＭＮ１００に対してすべての割り当て可能なタイプ（用途）のプレフィックスを割り当て、ＭＮ１００が必要なプレフィックスを選別してもよい。このようにして、ＭＮ１００で使用されるプレフィックスの用途又は種類が特定されることで、モビリティ管理ドメイン１１０は、プレフィックスリサイクルモードでＭＮ１００へ割り当てたプレフィックスを回収するタイミングを確実に把握できるようになる。なお、ＭＮ１００からモビリティ管理ドメイン１１０に対して、プレフィックスリサイクルモードでＭＮ１００へ割り当てたプレフィックスの回収可能なタイミング（ＭＮ１００でそのプレフィックスが不要になったタイミング）を通知してもよい。

モビリティ管理ドメイン１１０がこのプレフィックスリサイクル要求に同意すると、ステップＳ５８０において、プレフィックスリサイクル要求に応じた新たなプレフィックス割り当てがプレフィックス割り当てメッセージによってＭＮ１００へ通知される。具体的には、プレフィックスリサイクルモードによるプレフィックス割り当てが行われることがプレフィックス割り当てメッセージによって通知される。

プレフィックスリサイクルモードでプレフィックスがＭＮ１００へ割り当てられた場合には、ステップＳ５９０において何らかのイベントが発生したとき、モビリティ管理ドメイン１１０は、ステップＳ５９５においてプレフィックス割り当てメッセージをＭＮ１００へ送信することによって、別のＭＮ１００で使用可能となるように（後に別のＭＮ１００に割り当て可能となるように）リサイクルされる対象のプレフィックスの割り当てを削除することが可能となる。ただし、リサイクルされる対象のプレフィックスの割り当てを削除する時点において確実に元のＭＮ１００とは異なる別のＭＮ１００で使用されることが確定していない場合もあり、最終的に、元のＭＮ１００が新たなプレフィックスを要求した際に、このプレフィックスが割り当てられることもあり得る（プレフィックス再利用モードを使用した場合とほぼ等価の結果となる）。

プレフィックスリサイクルモードによるプレフィックスの割り当ての一例としては、例えば、ＭＮ１００がモバイルＩＰｖ６ノードである場合が挙げられる。この場合、ＭＮ１００は、割り当てられているプレフィックス（第１プレフィックス）をホームプレフィックスとして使用し、さらに、別に割り当てられているプレフィックス（第２プレフィックス）から構成した気付アドレスを（若しくは第２プレフィックスそのものを）、ＭＮ１００のホームアドレス（ホームプレフィックスから構成されているアドレス、若しくはホームプレフィックスそのもの）と関連付ける場合がある。この場合、第２プレフィックスは気付アドレスを構成するためにのみ使用されているので、第２プレフィックスの連続性は維持される必要はない。したがって、ＭＮ１００は、第２プレフィックスがプレフィックスリサイクルモードで割り当てられるように要求することが可能である。

このとき、例えばモビリティ管理ドメイン１１０におけるプレフィックスのリソースが枯渇した場合に、ＭＮ１００への第２プレフィックスの割り当てが削除されてもよく、また、ＭＮ１００が第２プレフィックスを割り当てられたネットワークインタフェースをシャットダウンした場合には、第２プレフィックスがモビリティ管理ドメイン１１０へリリースされてもよい。なお、あらかじめリサイクルモードでプレフィックスの割り当てを受けた場合でも、何らかの理由で、そのアドレスを再利用したいような状況になるかもしれない。このような場合は、途中で（若しくはプレフィックス／ネットワークインタフェース変更時に）対応するプレフィックスについてプレフィックス再利用要求を送信してもよい。プレフィックス再利用モードでの使用が可能となった場合は、その後の動作はプレフィックス再利用モードの動作と同等となる。また、プレフィックス削減モードとの違いの１つに、対象となるプレフィックスをネットワーク側で維持しておく必要性がないことをＭＮ１００が明示することで、ネットワーク側の管理に要する処理を更に低減できるという効果がある。

また、図５Ｂには、本発明の実施の形態におけるリサイクルモードによるプレフィックス割り当ての別の動作例が図示されている。図５Ｂにおいて、ＭＮ１００は、ネットワークインタフェース２１０−１（３ＧＰＰインタフェースＩＦ１）及びネットワークインタフェース２１０−２（非３ＧＰＰインタフェースＩＦ２）を有している。ステップＳ５１０のＲＡメッセージに示されているように、プレフィックスＰ１は最初ＩＦ１に割り当てられており、ＩＦ２は最初シャットダウンされている。

ここで、ＭＮ１００が、３ＧＰＰ特有のサービスへのアクセスを行うことを決定したとする。この場合、ＭＮ１００には、３ＧＰＰ特有のプレフィックス（例えば、３ＧＰＰオペレータから渡されるプレフィックス）が割り当てられる必要がある。この３ＧＰＰ特有のプレフィックスは３ＧＰＰ特有のサービスにアクセスするためだけに用いられるので、このとき、ＭＮ１００のプレフィックス検出部２５０は、ステップＳ５２０ｂにおいて、プレフィックスリサイクルモードによるプレフィックス割り当ての必要性を検出する。その結果、ＭＮ１００のプレフィックス管理部２６０は、ステップＳ５５０ｂにおいて、プレフィックスリサイクルモードでプレフィックスを割り当てるよう要求するプレフィックスリサイクル要求をＭＮ１００へ送信する。

モビリティ管理ドメイン１１０がこのプレフィックスリサイクル要求に同意すると、ステップＳ５８０ｂにおいて、ＩＦ１に最初から割り当てられているプレフィックスＰ１に加えて、３ＧＰＰ特有のプレフィックスＰｓがＲＡメッセージによってＭＮ１００のＩＦ１へ割り当てられる。

ここで、ＭＮ１００は、ステップＳ５９０ｂにおいて、ＩＦ１からＩＦ２へ垂直ハンドオフなどを行うとする（図５ＡのステップＳ５９０におけるイベント発生に対応）。ＩＦ２は非３ＧＰＰインタフェースであり、この垂直ハンドオフによって３ＧＰＰ特有のサービスへのアクセスは行われなくなるとすると、３ＧＰＰ特有のプレフィックスＰｓも不要となる。したがって、３ＧＰＰ特有のプレフィックスＰｓはプレフィックスリサイクルモードでＩＦ１へ割り当てられているので、垂直ハンドオフではその連続性は維持されない。その結果、ステップＳ５９５ｂにおいて、垂直ハンドオフ後には、プレフィックスＰ１のみがＲＡメッセージによってＩＦ２に割り当てられる。

なお、図５Ａ及び図５Ｂに図示されている例では、新たに割り当てられるプレフィックスに対してプレフィックスリサイクル要求が行われる場合が示されているが、既にＭＮ１００で保持されているプレフィックスに対してプレフィックスリサイクル要求が用いられてもよい。この場合には、プレフィックスリサイクル要求には、プレフィックスリサイクルモードの対象となる特定のプレフィックスを示す情報が含まれていることが望ましい。

このように、ＭＮ１００が、割り当てられているプレフィックスを使用しなくなった場合に他のＭＮ１００で使用可能となるようにプレフィックスを削除してもよい（すなわち、他のＭＮ１００へリサイクルしてもよい）ことをモビリティ管理ドメイン１１０へ示すことで、モビリティ管理ドメイン１１０は、プレフィックスを効率良くＭＮ１００へ割り当てることが可能となり、ネットワークリソース（プレフィックスのリソース）が節約される。以上のように、上述の本発明の実施の形態におけるプレフィックスリサイクルモードによって、本発明の目的は達成される。

また、トラフィックの一部あるいはすべてをＭＡＧやアクセスネットワーク（すなわちＭＡＧとは異なるノード）からＰＭＩＰドメインのＬＭＡ（すなわち３ＧＰＰコアネットワークや、オペレータのコアネットワークドメイン）を通過させることなく、宛先ノードにオフロードさせる選択的ＩＰトラフィックオフローディング（Selective IP Traffic Offload）をＭＮ１００が適用していることを、プレフィックスリサイクルモードの実施条件としてもよい。特定のプレフィックスが、選択的ＩＰトラフィックオフローディング用途で割り当てられる場合、ハンドオーバによってそのプレフィックスを用いたセッションの継続は困難となる。したがって、そのような場合、ＭＮ１００は当該プレフィックスに対して単にリサイクルモードを要求するだけであってもよい。または、ＭＮ１００がリサイクルモードにあるプレフィックスを要求してきたときに、ネットワークが選択的ＩＰトラフィックオフローディング用のプレフィックスを割り当てるものであってもよい。

さらには、例えば、プレフィックスリサイクル要求メッセージは、ＭＮ１００が３ＧＰＰアクセスネットワークからＷＬＡＮのような非３ＧＰＰアクセスネットワークにハンドオーバするときに使用してもよい。３ＧＰＰアクセスネットワークの普及状況によっては、３ＧＰＰアクセスネットワーク（例えばＬＴＥやＵＭＴＳなど）経由で３ＧＰＰコアネットワークに接続する場合に、ＭＮ１００は複数プレフィックスを保持することができる（各々のプレフィックスは対応するＰＤＮコネクションに結びつけられる）が、非３ＧＰＰアクセスネットワーク（例えばＷＬＡＮなど）経由で３ＧＰＰコアネットワークに接続する場合、ＭＮ１００は１つしかＰＤＮコネクションを生成できない。プレフィックス検出部２５０は、こうした状況からプレフィックスリサイクルの必要性を検出してもよい。

この場合、ＭＮ１００はプレフィックスリサイクル要求メッセージを用いて、３ＧＰＰアクセスネットワークで取得したプレフィックスのうち、どのプレフィックスをリサイクルモードにするかをネットワークに通知することができる。上述したように、リサイクルモードのプレフィックスは、垂直ハンドオーバ処理の間はネットワークによって管理されないことがあるため、ＭＮ１００が有するプレフィックスのうちリサイクルモードに指定していないプレフィックスが１つだけある場合、ＭＮ１００は、そのプレフィックスが非３ＧＰＰアクセスネットワークにハンドオーバされるものとして確信することができる。このようにして、ＭＮ１００は所望のＰＤＮコネクションを非３ＧＰＰアクセスネットワークにハンドオーバさせることができ、ネットワークシステムが任意に（ＭＮ１００が意図しない）ハンドオーバ対象のＰＤＮコネクションを選択する事態を回避することができる。したがって、非３ＧＰＰアクセスネットワークへのハンドオーバ時に、例えばアプリケーションが必要とするＰＤＮコネクション（プレフィックスに相当）を正しく選択することができるようになり、ユーザの利便性向上を図ることができる。

なお、上述の本発明の実施の形態では、プレフィックス削減要求（プレフィックス削減モード）、プレフィックス再利用要求（プレフィックス再利用モード）、プレフィックスリサイクル要求（プレフィックスリサイクルモード）などのプレフィックスプリファレンスの実際のメッセージ形式に関しては説明を行わなかったが、当業者であれば、このプレフィックスプリファレンスは、任意の形式によって伝送可能であることが分かるであろう。

例えば、プレフィックスプリファレンスは、モビリティ管理ドメイン１１０のアクセスルータへ送信されるＩＣＭＰ（Internet Control Message Protocol）の近隣探索（ＮＤ：Neighbor Discovery）メッセージ（例えば、近隣通知メッセージ（Neighbor Advertisement）又はルータ要請メッセージ（Router Solicitation message）など）に挿入される特別なオプションに基づいて実現されてもよい。

また、プレフィックスプリファレンスは、モビリティ管理ドメイン１１０内のＤＨＣＰ（Dynamic Host Configuration Protocol）中継装置又はＤＨＣＰサーバへ送信されるＤＨＣＰメッセージに挿入されてもよい。これは、例えば、モビリティ管理ドメイン１１０がＤＨＣＰを利用してモバイルノードへプレフィックスの割り当てを行う場合に有用である。

さらに、プレフィックスプリファレンスは、ＭＮ１００とモビリティ管理ドメイン１１０との間で実行されるＡＡＡ（Authentication, Authorization and Accounting）シグナリングメッセージに挿入されてもよい。なお、例えば、ＤＩＡＭＥＴＥＲ又はＲＡＤＩＵＳなどを始めとする任意の認証プロトコルを拡張して、プレフィックスプリファレンスがシグナリングメッセージへ挿入されてもよい。これは、例えば、ネットワークインタフェースが起動する際にプレフィックスプリファレンスを送信する場合に有用である。ＡＡＡシグナリングメッセージは、通常は、ネットワークインタフェースが起動した直後の最初の数メッセージにおいて送信されるので、ＡＡＡメッセージにプレフィックスプリファレンスを付加することで、不必要なオーバーヘッド（Overhead)及び処理遅延を減らすことが可能となる。

さらに、プレフィックスプリファレンスは、レイヤ２接続確立シグナリングのフレーム（例えば、ＭＮ１００とｅＮｏｄｅＢ（evolved NodeB）との間の３ＧＰＰシグナリングメッセージや、ＭＮ１００とｅＰＤＧ（evolved Packet Data Gateway）との間のＰＰＰ（ポイントトゥーポイントプロトコル）やＥＡＰ（拡張認証プロトコル）のセットアップメッセージなど）に挿入されてもよい。この場合も、ネットワークインタフェースの起動時又はシャットダウン時などのようなレイヤ２接続確立シグナリングが行われる際にプレフィックスプリファレンスを送信する場合に有用である。

また、図１３には、本発明の実施の形態におけるプレフィックスプリファレンスメッセージ１５０のメッセージ構造の一例が図示されている。

図１３には、ＩＣＭＰｖ６ヘッダとして実現されるプレフィックスプリファレンスメッセージのパケット１３０８のメッセージ構造が図示されている。なお、プレフィックスプリファレンスメッセージは、ＩＣＭＰｖ６の新たなタイプによって実現されてもよく、あるいは、新たなコード値を有する既存のタイプによって実現されてもよい。

パケット１３０８の最初のフィールドは、ＩＰｖ６ヘッダ１３０９を示している。ＩＰｖ６ヘッダ１３０９の送信元アドレスフィールドは、モバイルノードがプレフィックスプリファレンスメッセージを送信するインタフェースに関連付けられているＩＰｖ６アドレスであり、あて先アドレスフィールドはＭＡＧのＩＰｖ６アドレスとなる。

また、続くＩＣＭＰｖ６パケット１３１０には、タイプ情報（タイプ値）を含むフィールド１３１１が存在する。なお、新たなＩＣＭＰｖ６メッセージが使用される場合には、新たなタイプ値が設定されてプレフィックスプリファレンス情報が送信されてもよい。タイプ情報を含むフィールド１３１１に使用されるタイプ値は、ＩＣＭＰｖ６メッセージの構造を決定する。

続いて、コード値を含むフィールド１３１２が存在する。なお、タイプ値に既存の値が用いられ、コード値によってプレフィックスプリファレンスが含まれていることが示されてもよい。すなわち、コード値が、メッセージ情報の違いを示してもよい。例えば、プレフィックスプリファレンスメッセージが近隣探索シグナリングのＲＳ（Router Solicitation）によって送信される場合、コード値を含むフィールド１３１２にプレフィックスプリファレンスメッセージを示す新たなコード値が用いられてもよい。

続いて、パケットのデータ改ざんを検出するためのチェックサムフィールド１３１３である。さらに、プレフィックスプリファレンスメッセージを含むパケット１３０８には、本発明に係るプレフィックスプリファレンスメッセージの必要な情報（例えば、再利用されるプレフィックス、削除されるプレフィックス、リサイクルされるプレフィックスなど）を挿入するためのプレフィックスプリファレンス値フィールド１３１４が含まれる。

なお、プレフィックスプリファレンスメッセージは、ＩＫＥｖ２開始（initiation）メッセージ（あるいは、その他のＩＫＥｖ２メッセージ）によって実現されてもよい。一般に、ＩＫＥｖ２開始メッセージは、暗号化アルゴリズムの取り決め、ノンス値の交換、ピア（相手）とディフィー・へルマン鍵を交換するためなどに用いられ、通常、ＩＫＥｖ２ヘッダ部と、１つ以上のＩＫＥｖ２ペイロード部とを有している。

ＩＫＥｖ２開始メッセージがプレフィックスプリファレンスメッセージの送信に使用される場合には、例えば、既存のペイロードを有する標準のＩＫＥｖ２開始メッセージに加えて、プレフィックスプリファレンス情報を運ぶための新たなＩＫＥｖ２ペイロードが付加される。さらに、プレフィックスプリファレンス情報の伝送に既存のＩＫＥｖ２ペイロードタイプが使用される場合には、ＩＫＥｖ２ヘッダ部に、ＩＫＥｖ２開始メッセージに既存のタイプの追加ペイロードが埋め込まれていることを示す新たなフラグが用いられる。

なお、当業者にとって、ＩＫＥｖ２開始メッセージに新たなプレフィックスプリファレンスメッセージを埋め込む方法が多数存在することは明らかである。例えば、図１３に図示されているパケット１３１５は、ＩＫＥｖ２開始メッセージを使用してプレフィックスプリファレンスメッセージを実現する好適な一例である。

パケット１３１５には、３つの主要部が存在する。第１の部分はＩＰｖ６ヘッダ１３１６である。ＩＰｖ６ヘッダ１３１６には、ＩＫＥｖ２開始メッセージが正しく発送されるように送信元及びあて先の情報が含まれる。また、第２の部分はＩＫＥｖ２パケットのＩＫＥｖ２ヘッダ部１３１７であり、第３の部分はＩＫＥｖ２ペイロード部１３２２である。

ＩＫＥｖ２ヘッダ部１３１７には、ＩＫＥ＿ＳＡイニシエータＳＰＩフィールド１３１８、ＩＫＥ＿ＳＡレスポンだＳＰＩフィールド１３１９、標準フィールド１３２０、メッセージＩＤフィールド１３２１が含まれる。これらの４つのフィールドは、ＩＫＥｖ２ヘッダに標準的なフィールドである。

ＩＫＥ＿ＳＡイニシエータＳＰＩフィールド１３１８には、固有のＩＫＥセキュリティアソシエーション（ＳＡ：セキュリティアソシエーション）を識別するためのイニシエータの識別子が含まれ、ＩＫＥ＿ＳＡレスポンダＳＰＩフィールド１３１９には、固有のＩＫＥセキュリティアソシエーションを識別するためのレスポンダの識別子が含まれる。

また、標準フィールド１３２０には、例えば、交換メッセージのタイプやフラグなどのようなＩＫＥｖ２ヘッダで使用される多数の標準フィールドが含まれる。なお、標準フィールド１３２０には、プレフィックスプリファレンスメッセージの存在を示す新たなフラグタイプが埋め込まれる。また、メッセージＩＤフィールド１３２１はメッセージの識別子を含むメッセージ識別子フィールドである。

また、ＩＫＥｖ２ペイロード部１３２２には、複数のペイロードフィールドが含まれる。通常、ＩＫＥｖ２シグナリングには１つ以上のペイロードが用いられる。なお、図示を明瞭にするため、例えば、再利用されるプレフィックス、削除されるプレフィックス、リサイクルされるプレフィックスなどのような、本発明に係るプレフィックスプリファレンスメッセージの必要な情報を運ぶ新たなペイロードのみが図示されている。

さらには、ＩＫＥｖ２ペイロード部１３２２には、通知するプレフィックスと関連するＡＰＮ（Access Point Name）の情報が含まれることもある。ＡＰＮ情報がＩＫＥｖ２ペイロード部１３２２に含まれる場合、メッセージを受信するエンティティは、ＡＰＮ情報からＰ−ＧＷ識別子（PDN Gateway ID）を取得するために用いる。

例えば、３ＧＰＰシステムにおいては、ＭＮ１００が３ＧＰＰコアネットワークに配備された拡張パケットシステム（EPS：Evolved Packet System）に接続する際、インターネットブラウジング用のＡＰＮ情報としてインターネット接続のためのＡＰＮ値と対応するプレフィックスが通知される。ＭＮ１００は、非信頼ＷＬＡＮ（untrusted WLAN）アクセスシステム経由でＥＰＳに接続するために、ＷＬＡＮインタフェースを使用することを決定する。ＷＬＡＮアクセスシステムが非信頼ＷＬＡＮであることを検出すると（例えば、ＷＬＡＮシステムのアクセスポイントから受信したルータ広告メッセージを通じてＷＬＡＮアクセスシステムが非信頼ＷＬＡＮであることが通知されたり、あるいは、信頼できるＷＬＡＮアクセスシステムではないことが検出されたり、あらかじめＭＮ１００が該情報を保有していたり、ＷＬＡＮアクセスシステムに接続する際の返り値として通知されたりする、などの方法により）、ＭＮ１００は、ｅＰＤＧ（enhanced Packet Data Gateway）経由でＷＬＡＮアクセスシステムからＥＰＳに接続する手続きを開始する。したがって、ＭＮ１００は、インターネット接続用ＡＰＮとプレフィックスを記載したＩＫＥｖ２ペイロード部１３２２を含むＩＫＥｖ２パケット１３１５を送信する。ｅＰＤＧは、ＩＫＥｖ２ペイロード部１３２２から抽出したＡＰＮ情報をもとに、Ｐ−ＧＷ識別子をＡＡＡサーバに問い合わせる。Ｐ−ＧＷ識別子は、Ｐ−ＧＷのアドレスであってもよいし、Ｐ−ＧＷのアドレスを導出するための情報（例えばＰ−ＧＷのホスト名やＵＲＩなど）であってもよい。ｅＰＤＧは、ＭＮ１００に代わって、取得したアドレスのＰ−ＧＷへの接続を実施する。

さらに、プレフィックスプリファレンスメッセージは、例えば、図１３に図示されているレイヤ２フレーム１３０７のような、レイヤ２（Ｌ２）メカニズムあるいはレイヤ２メッセージを使用して実現されてもよい。

例えば、このプレフィックスプリファレンスメッセージは、ＭＮがＩｎｔｅｒｗｏｒｋｉｎｇＷＬＡＮ（Ｉ-ＷＬＡＮ）やＷｉＭＡＸ、他セルラシステム（３ＧＰＰ２で規定するｃｄｍａ２０００など）のようなｔｒｕｓｔｅｄ非３ＧＰＰアクセスネットワーク経由で３ＧＰＰコアネットワークに接続する場合などに適用できる。

図１３のレイヤ２フレーム１３０７の最初のフィールドはフレームの始めを示す第１フラグフィールド１３００であり、続いて、メディアアクセスコントロール（ＭＡＣ：Media Access Control）アドレスフィールド１３０１が含まれる。このＭＡＣアドレスフィールド１３０１には、フレームのソースアドレス及びあて先アドレスが含まれる。

また、続いて、特定のタイプのフレームが使用されていることを識別するための制御フィールド１３０２、プロトコルＩＤフィールド１３０３が含まれる。このプロトコルＩＤフィールド１３０３には、上位レイヤで送られたパケットに関する値が含まれる。例えば、プレフィックスプリファレンス情報がＬ２で発送された場合には、プロトコルＩＤフィールド１３０３はＮＵＬＬ（ヌル）となる。なお、プレフィックスプリファレンス情報がＬ２で発送可能であっても、このシグナリングやこのシグナリングに埋め込まれる関連パラメータを送信する決定は、レイヤ３（Ｌ３）から行われる必要がある。

続いて、情報フィールド１３０４が存在する。この情報フィールド１３０４は、例えば、再利用されるプレフィックス、削除されるプレフィックス、リサイクルされるプレフィックスなど、本発明に係るプレフィックスプリファレンスメッセージの必要な情報を伝送するために使用される。この情報フィールド１３０４の後に、フレームを改ざんされることなく伝送するため（エラー識別及び修正のため）のフレームチェックシーケンスフィールド１３０５が存在する。そして、最後に、フレームの区切り（終わり）に用いられる第２のフラグフィールド１３０６が存在する。

３ＧＰＰシステムにおいては、レイヤ２メカニズムの一例としてベアラリソース修正要求メッセージ（Request Bearer Resource Modification Message）が挙げられる。本メッセージは、移動管理エンティティ（ＭＭＥ：Mobility Management Entity）に送信された後、ベアラリソースコマンド（Bearer Resource Command）としてＳ-ＧＷ（Serving Gateway）に転送される。ここで、ＭＮ１００は、プレフィックス・プリファレンス・メッセージ（プレフィックス削減要求や、プレフィックス再利用要求、プレフィックスリサイクル要求）を運ぶための情報要素（Information Element）あるいはプロトコル構成オプション（Protocol Configuration Option）を、ベアラリソース修正要求メッセージに追加してもよい。各ベアラにプレフィックスが一つずつ対応づけられる場合、ベアラリソース修正要求メッセージに含まれるプレフィックス・プリファレンス・メッセージで、削除／再利用／リサイクルを要求するプレフィックスを特に指定する必要はない。

他のレイヤ２メカニズムの例として、ＭＮ１００からネットワークに送信される、ＰＤＰコンテキスト修正要求メッセージ（Modify PDP(Packet Data Protocol) Context Request Message）が挙げられる。ベアラリソース修正要求メッセージと同様、ＭＮ１００は、プレフィックス・プリファレンス・メッセージ（プレフィックス削減要求や、プレフィックス再利用要求、プレフィックスリサイクル要求）を運ぶための情報要素あるいはプロトコル構成オプションを、ＰＤＰコンテキスト修正要求メッセージに追加することができる。

また、特に、プレフィックスプリファレンスメッセージは、プレフィックススコープのバインディングアップデートメッセージを用いて実現可能である。プレフィックススコープのバインディングアップデートメッセージは、現在、モバイルノードが３ＧＰＰ内のモビリティアンカ（例えば、Ｐ−ＧＷ）へプレフィックス継続を要求するために用いられている。これを、プレフィックスの削減要求又はプレフィックスの再利用要求を運ぶために用いることも可能である。

例えば、バインディングアップデートメッセージのフラグに“Ｒ”ビットが存在する場合には、このメッセージの受信者に対して、モバイルノードがプレフィックススコープのバインディングアップデートメッセージに含まれるプレフィックスの使用継続を要求していることを示しているまた、Ｒビットを削除するか、バインディングアップデートメッセージ内のプレフィックスを省略することで、モバイルノードは、プレフィックスの削減要求をとして用いることも可能である。また同様に、第１インタフェースに割り当てられていたプレフィックスを、第２インタフェースに関連して送信されるバインディングアップデートメッセージに挿入することによって、第１インタフェースのプレフィックスを第２インタフェースで利用するためのプレフィックス再利用要求が実現される。

また、上述の本発明の実施の形態では、ＭＮ１００によるプレフィックスプリファレンスの送信先をモビリティ管理ドメイン１１０（モビリティ管理ドメイン１１０内の任意のエンティティ）として説明を行ったが、プレフィックスプリファレンスの実際の送信先（物理的なノード）は、モビリティ管理ドメイン１１０のシステム構成に依存する。

例えば、モビリティ管理ドメイン１１０が十分に管理されたクローズな構成の場合、モビリティ管理ドメイン１１０のオペレータは、ＭＮ１００に対して、モビリティ管理ドメイン１１０内のコアノードのアドレスを明らかにしたくないことがある。この場合、ＭＮ１００にはＭＡＧのアドレスのみが明らかにされるので、プレフィックスプリファレンスは常にＭＡＧへ送信され、ＭＡＧが、プレフィックスプリファレンスを含むメッセージの処理や別のノード（例えば、ＤＨＣＰサーバ若しくはＡＡＡサーバ）への転送を行う。

また、モビリティ管理ドメイン１１０がＤＨＣＰを利用してＭＮ１１０へプレフィックスの割り当てを行う場合には、プレフィックスプリファレンスは、ＤＨＣＰ要求メッセージのオプションやその他の形式によってＤＨＣＰサーバへ送信されてもよい。ＤＨＣＰサーバは、ＭＮ１００へのプレフィックス割り当て管理を行うノードであるため、これによって、シグナリングメッセージのオーバーヘッドは大幅に軽減される。

また、ＭＮ１００は、プレフィックスプリファレンスをＬＭＡへ送信してもよい。ＬＭＡはＭＮ１００へ割り当てられたプレフィックスに関する情報をバインディングキャッシュ内に保持する必要があり、この点から、プレフィックスプリファレンスをＬＭＡへ送信することは有用であると言える。

さらに、モビリティ管理ドメイン１１０の構成上、ＬＭＡが、ＭＮ１００へプレフィックスを割り当てる機能を有する場合がある。このような場合には、ＬＭＡがプレフィックスの管理を行っている可能性があり、ＬＭＡへのプレフィックスプリファレンスの送信は有用である。

さらに、ＭＮ１００が、ＡＡＡシグナリングメッセージにオプションとしてプレフィックスプリファレンスを挿入して、ＡＡＡサーバへ送信することも可能である。ネットワークインタフェースが起動した際にプレフィックスプリファレンスが送信される場合には、同じくネットワークインタフェースが起動した際に送信されるＡＡＡシグナリングメッセージにプレフィックスプリファレンスを挿入することは有用である。さらに、モビリティ管理ドメイン１１０の構成上、ＡＡＡサーバがプレフィックス割り当て及びプレフィックス管理の制御を行う場合もある。

なお、モビリティ管理ドメイン１１０内の任意のエンティティは、例えば、ＭＮ１００へのネットワークプレフィックスの割り当てを管理し、ＭＮ１００に対して割り当てられたネットワークプレフィックスとＭＮ１００との対応関係を維持するプレフィックス対応維持部と、ＭＮ１００にとって必要なネットワークプレフィックスが割り当てられた状態を実現するための情報を含むプレフィックスプリファレンス情報をＭＮ１００から受信した場合に、プレフィックスプリファレンス情報に基づいて、ＭＮ１００に対して割り当てられたネットワークプレフィックスとＭＮ１００との対応関係を変更するプレフィックス管理部とを有している。また、プレフィックス管理部は、移動端末における上記の各モードに応じて、不要なプレフィックスの削減、別のインタフェースでの再利用、別のＭＮにおける使用を示すリサイクルなどが行われるように、ＭＮ１００に対して割り当てられたネットワークプレフィックスとＭＮ１００との対応関係の変更を行う。

また、３ＧＰＰの構成では、プレフィックスプリファレンスメッセージが、Ｓ−ＧＷ（サービングゲートウェイ）、ｅＰＤＧ（拡張パケットデータゲートウェイ）、Ｐ−ＧＷ（パケットデータネットワークゲートウェイ）へ送信されてもよい。モバイルノードは、ＡＡＡサーバ（すなわち、３ＧＰＰのＨＳＳ）と直接通信することが許可されていないかもしれないが、プレフィックスプリファレンスメッセージがＡＡＡ交換メッセージに埋め込まれてＨＳＳへ渡されてもよい。

また、モビリティ管理ドメイン１１０におけるプレフィックス割り当てに関する別の問題を解決するために本発明を適用することも可能である。以下、図６Ａ及び図６Ｂを参照しながら、モビリティ管理ドメイン１１０におけるプレフィックス割り当てに関する別の問題を解決する本発明の適用例について説明する。

図６Ａには、ＭＮ１００がモビリティ管理ドメイン１１０内を移動する場合のシナリオが示されている。最初、ＭＮ１００はアクティブなＵＭＴＳ接続６０２のみを有しており、ＵＭＴＳのｅＮｏｄｅＢであるＭＡＧ６２０に接続している。ＨＡ／ＬＭＡ６１５は、第１のプレフィックスＰ１をＵＭＴＳインタフェースへ割り当て、ＭＮ１００は、このプレフィックスをホームプレフィックスとして使用する。

その後しばらくして、ＭＮ１００は、ＷＬＡＮアクセスネットワーク６１８でＷＬＡＮインタフェースを起動し、ＭＡＧ６２５に対して新たな接続を行う。ＷＬＡＮアクセスネットワーク６１８が非信頼ＷＬＡＮ（untrusted WLAN）の場合には、ＷＬＡＮ接続６０４はＰＰＰ又はＥＡＰ接続となり、ＭＡＧ６２５がｅＰＤＧとなる。

ここで、このＷＬＡＮ接続６０４に対して、どのような種類のプレフィックスがＭＮ１００へ割り当てられるべきか考慮される必要があり、以下の幾つかの例が考えられる。

第１に、ＭＮ１００がこのプレフィックスを用いて気付アドレスを構成することができるようにするため、ＭＡＧ６２５が、モビリティ管理ドメイン１１０の第２のプレフィックスＰ２（既に割り当てられているプレフィックスＰ１とは異なるプレフィックス）をＭＮ１００へ割り当てることが可能である。ＭＮ１００がモビリティ管理ドメイン１１０へ接続している限り、モビリティ管理ドメイン１１０から割り当てられたプレフィックスは維持される。

第２に、ＭＡＧ６２５は、モビリティ管理ドメイン１１０のプレフィックスとして維持されないローカルプレフィックスをＭＮ１００へ割り当てることが可能である。このプレフィックスは、一般に経路最適化に使用される（このプレフィックスに基づいて構成されたアドレスあてのパケットは、ＨＡ／ＬＭＡ６１５へ転送される必要がないので)。

第３に、モビリティ管理ドメイン１１０が同一のＭＮ１００の複数のネットワークインタフェースに対して１つのプレフィックスを割り当てることをサポートしている場合には、同一のプレフィックスＰ１をＭＮ１００のＷＬＡＮインタフェースへ割り当てることが可能である。この場合、ＭＮ１００は、プレフィックスＰ１から構成されたホームアドレスに関連するデータフローに関して、ＵＭＴＳインタフェース及びＷＬＡＮインタフェースのどちらを用いてもよい。

しかしながら、いずれの場合においても、ＭＮ１００が必要としている（あるいは望んでいる）プレフィックスの種類をモビリティ管理ドメイン１１０が把握する必要がある。このように、ＭＮ１００が必要としている（あるいは望んでいる）プレフィックスの種類をモビリティ管理ドメイン１１０が把握できるようにするため、本発明に基づいて、ＭＮ１００がその必要性（ＭＮ１００が必要とするプレフィックスの種類）を通知することが可能である。

これを実現する好適な方法の１つは、ＭＮ１００がＭＡＧ６２５に接続した際に、ＭＡＧ６２５が最初にＭＮ１００に対してすべての割り当て可能なタイプのプレフィックスを割り当て、ＭＮ１００にプレフィックス削減要求の送信を行わせて、不必要なすべてのプレフィックスをリリースさせるとともに、必要なプレフィックスのみ保持させることである。なお、この方法に関しては、後で図６Ｂを参照しながら説明する。

また、別の方法として、ＭＮ１００がプレフィックスリサイクル要求を用いてローカルプレフィックスを取得し、プレフィックス再利用要求を用いてホームプレフィックスを取得し、通常の接続処理においてモビリティ管理ドメイン１１０の第２のプレフィックスＰ２を取得するなどのように、ＭＮ１００が、モビリティ管理ドメイン１１０から割り当てられるプレフィックスに関して本発明に係る各モードのいずれが適切かを判断してモードを使い分けることも可能である。

以下、図６Ｂを参照しながら、最初にＭＮ１００に対してすべての割り当て可能なタイプのプレフィックスを割り当て、ＭＮ１００に必要なプレフィックスを選別させる方法について説明する。

図６Ｂにおいて、ＭＮ１００は、まずステップＳ６３０で、ＵＭＴＳインタフェースにおいてプレフィックスＰ１をＲＡメッセージによって受信する。その後、ＭＮ１００は、ステップＳ６３５において、ＷＬＡＮインタフェースを起動してＭＡＧ６２５へ接続する。このとき、モビリティ管理ドメイン１１０は、まずすべての異なるタイプのプレフィックスをＭＮ１００へ割り当てる。例えば、モビリティ管理ドメイン１１０は、ステップＳ６４０において、プレフィックスＰ１、プレフィックスＰ２（例えば、ローカルプレフィックス）、プレフィックスＰ３（例えば、モビリティ管理ドメイン１１０から割り当てられる別のプレフィックス）を含むＲＡメッセージをＭＮ１００へ送信する。

ＭＮ１００は、ステップＳ６４０ですべての異なるタイプのプレフィックスを受信すると、ステップＳ６５０において、ＭＮ１００のプレフィックス検出部２５０が、余分なプレフィックスの検出処理を開始する。ここで、ＭＮ１００はローカルプレフィックス（上記のプレフィックスＰ２）の使用を望んでいるとする。この場合、ＭＮ１００は、ステップＳ６６０においてプレフィックス削減要求をＷＬＡＮインタフェースからモビリティ管理ドメイン１１０へ送信し、プレフィックスＰ１及びプレフィックスＰ３をリリースする。この結果、ＭＮ１００には、ステップＳ６７０のＲＡメッセージに示されているように、ＷＬＡＮインタフェースにプレフィックスＰ２が割り当てられ、ステップＳ６８０のＲＡメッセージに示されているように、ＵＭＴＳインタフェースにプレフィックスＰ１が割り当てられる状態となる。

次に、複数のＬＭＡが存在する環境でのプレフィックス再利用方法の動作について説明する。また、本発明に係るメカニズムは、複数のＬＭＡが配置されているＮｅｔＬＭＭドメインにおいても適用可能である。以下、図７Ａに示すような構成の場合を考慮しながら説明する。

プレフィックス再利用メカニズムが用いられた場合には、例えば、図７Ｃに図示されているメッセージシーケンスの動作が行われる。図７Ｃでは、ＭＮ７００Ｃは、２つのＬＭＡ（例えば、ＬＭＡ７０３Ｃ及びＬＭＡ７０４Ｃ）を有するＮｅｔＬＭＭドメインに接続されている。ＭＮ７００ＣのＩＦ１はＭＡＧ７０１Ｃに接続されており、ＭＮ７００ＣのＩＦ２は接続されていないと仮定する。さらに、ＬＭＡ７０３Ｃ及びＬＭＡ７０４Ｃは、ＭＮ７００Ｃに割り当てられたプレフィックスに関して、ＭＡＧ７０１Ｃを経由するプレフィックスの経路を有していると考える。

ＭＮ７００ＣはＭＡＧ７０１Ｃに接続されているので、ＭＡＧ７０１Ｃは、ＬＭＡ７０３ＣへＰＢＵ７０６Ｃを送信し、ＰＢＡ７０７Ｃを受信する。図７Ａに示す状態から図７Ｂに示す状態へ変化する際に生じるＩＦ２の垂直ハンドオフ動作によれば、ＰＢＡ７０７Ｃは２つのプレフィックス（プレフィックスＰ１及びＰ２）を有している。これらのプレフィックスは、ＬＭＡ７０３Ｃに接続されているＰＤＮからのサービスにアクセスするために使用される。

同様に、ＭＡＧ７０１ＣはＬＭＡ７０４ＣへＰＢＵ７０８Ｃを送信し、その応答であるＰＢＡ７０９ＣによってＬＭＡ７０４Ｃからプレフィックスを受信する。これにより、２つのプレフィックス（プレフィックスＰ３及びＰ４）がＰＢＡ７０９Ｃによって受信される。このプレフィックス割り当ては従来のハンドオフの結果生じるものであってもよい。

例えば、プレフィックスＰ２は最初ＩＦ２に割り当てられ、ＬＭＡ７０３Ｃで管理されていたとする。そして、垂直ハンドオフ動作によってＩＦ１へハンドオフが行われたとする。また同様に、プレフィックスＰ４は最初ＩＦ２に割り当てられ、ＬＭＡ７０４Ｃによって管理されていたとする。そして、垂直ハンドオフ動作によってＩＦ１へハンドオフが行われたとする。さらに、プレフィックスＰ１は、ＬＭＡ７０３ＣによってＩＦ１に割り当てられており、プレフィックスＰ３は、ＬＭＡ７０４ＣによってＩＦ１へ割り当てられていたとする。その結果、ＲＡ７１０Ｃには、プレフィックスオプションによって送信されるプレフィックスＰ１、Ｐ２、Ｐ３、Ｐ４が含まれる。

ここで、ＩＦ２をアクセスネットワークへ接続した後、ＭＮ７００ＣがプレフィックスＰ４に関連するフローをＩＦ２へ移すよう決定したとする。例えば、ＭＮ７００Ｃは、例えば負荷バランスのために（あるいは、例えば、プレフィックスＰ４に関連するフローが新たに探索されたアクセス技術のタイプ経由のほうが適しているなどの他の理由で）、ＩＦ２に適したアクセスネットワークを探索したなどの可能性がある。このとき、ＭＮ７００Ｃは、ＩＦ２に接続するＭＡＧ７０２Ｃへプレフィックス再利用要求メッセージ７１１Ｃを送信する。

プレフィックス再利用要求メッセージ７１１Ｃは、例えば、アクセス技術固有の接続メッセージに埋め込まれてもよい。プレフィックス再利用要求メッセージ７１１Ｃには、プレフィックスＰ４が含まれている。

ＭＡＧ７０２Ｃは、このプレフィックス再利用要求メッセージ７１１Ｃを受信すると、アクセス認証を開始し、ＨＳＳ／ＡＡＡエンティティ７０５Ｃと認証シグナル交換を行う。
ＨＳＳ７０５Ｃは、アクセス認可の成功を示す情報、ＬＭＡ７０３Ｃ及びＬＭＡ７０４Ｃのアドレス、ＭＮ７００Ｃに関連するサービス加入者情報を提供する。

ここで、ＭＡＧ７０２Ｃは、ＬＭＡ７０３Ｃを選んでプレフィックス再利用要求メッセージ７１３Ｃ（ＰＢＵ−再利用要求）を送信すると仮定する。このメッセージ７１３Ｃには、ＨＮＰ（Home Network Prefix）オプションにプレフィックスＰ４が埋め込まれているとともに、これがプレフィックスのサブセットの垂直ハンドオフであることを示す新たなハンドオフインディケータオプションが含まれている。ＬＭＡ７０３Ｃは、このメッセージ７１３Ｃを受信した場合、バインディングキャッシュ内のプレフィックスＰ４を特定できず、プレフィックスＰ４がＬＭＡ７０３Ｃによってサポートされていないこと、又は、要求されたプレフィックスＰ４をＭＮ７００Ｃへ割り当てられないことを通知するエラー通知７１４ＣをＭＡＧ７０２Ｃへ送信する。

ＭＡＧ７０２Ｃは、このメッセージ７１４Ｃを受信すると、ＬＭＡ７０４ＣへＰＢＵメッセージ７１５Ｃの送信を試みる。ＬＭＡ７０４Ｃは、ＰＢＵ７１５Ｃを受信すると、バインディングキャッシュを検索し、プレフィックスＰ４に関連するモビリティセッションを特定する。この場合、ＬＭＡ７０４Ｃは、プレフィックス再利用の成功を示す適切なＰＢＡ７１６Ｃを送信する。プレフィックス再利用の確認メッセージであるＰＢＡ７１６ＣをＭＡＧ７０２Ｃへ送信する前に、ＬＭＡ７０４Ｃは、ＩＦ１に関連して作成されているモビリティセッションに関連したＰ４を削除し、ＩＦ２に関する新たなモビリティセッションを作成するとともに、作成された新たなモビリティセッションにプレフィックスＰ４を割り当てる。

ＭＡＧ７０２Ｃは、ＰＢＡメッセージ７１６Ｃを受信すると、ＭＮ７００ＣのＩＦ２へＲＡを送信し、ＭＮ７００ＣがプレフィックスＰ４を使用してアドレスを構成できるようにする。これにより、使用されているプレフィックス再利用要求メッセージによって、あるインタフェースから別のインタフェースへプレフィックスを移すという目的が実現される。しかしながら、ＭＡＧ７０２Ｃが、最初に誤ったＬＭＡを選択してしまうと、シグナリングの遅延（例えば、エラー通知）が発生する。以下、図７Ｃにおいて、ＭＮ７００ＣがプレフィックスＰ１及びＰ４の両方をＩＦ２へ移すことを決定した場合について説明する。

上述のように、プレフィックスＰ１がＬＭＡ７０３Ｃに属し、プレフィックスＰ４がＬＭＡ７０４Ｃに属する場合を仮定する。上述のように、ＭＡＧ７０２Ｃは、プレフィックス再利用要求メッセージ７１７Ｃを取得すると、認証処理において、ＬＭＡ７０３Ｃ及びＬＭＡ７０４のアドレスをＨＳＳ／ＡＡＡ７０５Ｃから取得する。しかしながら、ＭＡＧ７０２Ｃは、どのＬＭＡがプレフィックスＰ１及びＰ４を有しているのかを把握できない。ＭＡＧ７０２Ｃは、ＰＢＵによってプレフィックスＰ４に関するプレフィックス再利用要求メッセージ７１８Ｃ（ＰＢＵ−再利用要求）をＬＭＡ７０３Ｃへ送信した場合には、エラー通知７１９ＣをＬＭＡ７０３Ｃから受信する。また、ＭＡＧ７０２Ｃは、プレフィックスＰ１を再利用するためのプレフィックス再利用要求メッセージ７２０Ｃ（ＰＢＵ−再利用要求）をＬＭＡ７０４Ｃへ送信すると、エラー通知７２１ＣをＬＭＡ７０４Ｃから受信する。このようなエラー通知によって生じる遅延を削除するためにプレフィックス再利用要求メカニズムを拡張した場合について説明する。

次に、複数のＬＭＡが配置されている場合に、各プレフィックスに関連するＡＰＮ情報をＭＮから提供することでプレフィックス再利用要求を実現することについて説明する。プレフィックス再利用要求を送信する場合に、モバイルノードが関連するＡＰＮを提供する拡張を行うことが可能である。

別のインタフェースに移す必要があるプレフィックスに関連したＡＰＮをモバイルノードから提供することで、ＭＡＧは、プレフィックスにマッピングされたＡＰＮを解析し、各プレフィックスに関連するＰ−ＧＷ又はＬＭＡのアドレスを特定することが可能である。ＭＡＧはＡＰＮを解析すると、同一のＡＰＮ（すなわち、同一のＬＭＡ）に属するプレフィックスをグループ化する。その結果、ＭＡＧは、グループ化されたプレフィックスが関連するＬＭＡへプレフィックス再利用要求のＰＢＵを送信することが可能である。

この方法では、複数のＬＭＡが存在する場合に、プレフィックス再利用要求メッセージによってプレフィックス及び関連するＡＰＮが提供される。以下、この方法を拡張プレフィックス再利用要求方法と呼ぶことにし、図８Ａ、８Ｂ、８Ｃを用いて説明する。

図８Ａには、本発明に係る拡張プレフィックス再利用方法の動作に関連するネットワークエンティティを含むネットワーク構成の一例が図示されている。図８Ａにおいて、ＭＮ８０９は、新たに起動したインタフェース又は既存のインタフェース経由でプレフィックス再利用要求を行うとする。

図８Ａでは、ＭＮ８０９は、ＭＡＧ８０７に接続されているインタフェースＩＦ１を介してＮｅｔＬＭＭドメイン８０２に接続されている。ＭＡＧ８０７は、ＩＦ１に関するモビリティを管理し、２つのＬＭＡ（ＬＭＡ８０５及びＬＭＡ８０６）にＭＮ８０９のＩＦ１に接続されているモビリティセッションに関するバインディングを設定する。また、ＬＭＡ８０５は、ＰＤＮ８００に接続されており、ＬＭＡ８０６は、ＰＤＮ８０１に接続されているとする。

ＰＤＮ８００によって提供されるサービスは、ＡＰＮ１によって特定され、ＰＤＮ８０１に関連するサービスはＡＰＮ２によって特定される。上述の図７Ａ、７Ｂ、７Ｃに示す例の場合には、ＭＡＧ８０７は、ＬＭＡ８０５から取得された２つのプレフィックスＰ１及びＰ２、ＬＭＡ８０６から取得された２つのプレフィックスＰ３及びＰ４を、ＲＡメッセージによってＭＮ８０９へ通知する。

ＭＮ８０９は、第２インタフェースＩＦ２を使用し、無線スキャンメカニズムによって無線アクセスネットワーク８０３を探索する。そして、前述の例と同様に、ＭＮ８０９は、ＩＦ１から、新たに起動したＩＦ２へプレフィックスのサブセットを移すことを決定したとする。本発明の好適な実施の形態によれば、ＭＮ８０９は、あるインタフェース（例えばＩＦ１）に割り当てられたプレフィックスの一部のみをＭＡＧ８０８に接続している別のインタフェース（例えばＩＦ２）に移すために、関連するＡＰＮ情報を含むプレフィックス再利用要求を送信することが可能である。

以下、図８Ｂに図示されているメッセージシーケンスチャートを参照しながら、拡張プレフィックス再利用要求方法の動作の一例について説明する。図８Ｂにおいて、ＭＮ８０９はＭＡＧ８０７に接続されており、例えば、ＲＡ８１１内に４つのプレフィックス（Ｐ１、Ｐ２、Ｐ３、Ｐ４）を確認したとする。割り当てられるプレフィックスは、例えば、ＬＭＡ８０５及びＬＭＡ８０６などの異なるＬＭＡに対する２つのＰＢＵ／ＰＢＡ動作によって取得される。

ここで、ＭＮ８０９は、プレフィックスＰ１を新たに起動したインタフェースへ移そうとしているとする。プレフィックスＰ１は、ＬＭＡ８０５に接続されたＰＤＮからのサービスへアクセスできるように割り当てられているので、ＭＮ８０９は、関連するＡＰＮ情報が付加されたプレフィックス再利用要求メッセージ８１２（一部のプレフィックスをハンドオフさせるトリガ）をＭＡＧ８０８へ送信する。すなわち、このメッセージ８１２には、ＡＰＮ１の情報が含まれているとともに、関連するプレフィックスＰ１の情報が埋め込まれている。

ＭＡＧ８０８は、メッセージ交換８１３に示されているように、まず、ＨＳＳ／ＡＡＡ８１０との間で新たな接続のためのアクセス認証及び認可を実行する。認証に成功すると、ＭＡＧ８０８は、メッセージ８１２内のＡＰＮ１の情報からＬＭＡ８０５を正しく特定し、プレフィックス再利用要求メッセージ８１４（ＰＢＵ−再利用要求）をＬＭＡ８０５へ送信することが可能である。

なお、ここでは、ＭＮ８０９が１つのプレフィックスのみ（プレフィックスＰ１）を新たなインタフェース（ＩＦ２）へ移す場合がについて説明したが、ＭＮ８０９は、より多くのプレフィックス（例えば、プレフィックスＰ１及びＰ４）を移すことを決定した場合には、レイヤ２のトリガ８１６（一部のプレフィックスをハンドオフさせるトリガ）にプレフィックスＰ１及びＰ４に関連するＡＰＮ情報を含ませることが可能である。なお、上述のように、プレフィックスＰ１はＬＭＡ８０５を論理的な基点とし、プレフィックスＰ４はＬＭＡ８０６を論理的な基点とする。

ＭＡＧ８０８は、ＡＰＮ１及びＡＰＮ２の情報を解析してＬＭＡのアドレスを特定すると、２つのセットのプレフィックス再利用要求のＰＢＵをＬＭＡ８０５及びＬＭＡ８０６へ送信する（ＰＢＵ８１７をＬＭＡ８０５へ送信し、ＰＢＵ８１９をＬＭＡ８０６へ送信）。なお、図８Ｂにおいて、各ＬＭＡ８０５、８０６からの応答は、ＰＢＡ８１８及びＰＢＡ８２０に示されている。

なお、この例では、ＡＰＮの情報は単一のＬＭＡに帰着される場合を考慮しており、ＬＭＡ群（すなわち、ＡＰＮの情報から複数のＬＭＡが特定される場合）は考慮されていない。しかしながら、ここで説明した拡張プレフィックス再利用要求方法は、ＬＭＡ群の場合においても利用可能である。この場合、ＭＡＧ８０８は、ＡＰＮを解析して単一のＡＰＮに関連するＬＭＡ群のアドレスを特定し、さらにＨＳＳ情報を待機及び参照して、プレフィックスに関連する正しいＬＭＡアドレスを特定する。このとき、認証／認可の交換８１３の間に、モバイルノードが使用していたＬＭＡのアドレスがＭＡＧ８０８へ提供されてもよい。ＭＡＧ８０８は個々のＡＰＮを解析して、ＨＳＳ／ＡＡＡ８１０から提供される正しいＬＭＡのアドレスと照合することが可能である。

例えば、ＡＰＮ１がＬＭＡ８０５Ａ、８０５Ｂ、８０５Ｃに帰着され、ＨＳＳ／ＡＡＡ８１０が認証交換８１３の間にＬＭＡ８０５及びＬＭＡ８０６のアドレスを提供した場合、ＭＡＧ８０８は、ＬＭＡ８０５として正しいＬＭＡのアドレスを特定でき、特定されたＬＭＡに対してプレフィックスＰ１に関するプレフィックス再利用要求ＰＢＵを送信することが可能となる。

次に、複数のインタフェースが完全に接続された場合のＡＰＮ情報を用いた拡張プレフィックス再利用要求方法について説明する。複数のＬＭＡが使用されている構成において、モバイルノードが複数の接続インタフェースを有している場合に、ＡＰＮ情報を含む拡張プレフィックス再利用要求方法を用いることができる。以下、図８Ｃを参照しながら説明する。

図８Ｃでは、ＭＮ８０９がすべてのインタフェースを同時に使用して、図８Ａに示すＮｅｔＬＭＭドメイン８０２へ接続する場合を考える。また、ＭＮ８０９は、ＰＤＮ（例えば、ＬＭＡ８０５に接続されているＰＤＮ８００、ＬＭＡ８０６に接続されているＰＤＮ８０１）からのサービスを取得しようとしているとする。さらに、ＭＮ８０９のＩＦ１は、無線アクセスネットワーク８０４を通じてＭＡＧ８０７に接続されており、ＭＮ８０９のＩＦ２は、無線アクセスネットワーク８０３を通じてＭＡＧ８０８に接続されている。

なお、この実施の形態では、ＭＮ８０９が複数のインタフェースを介して無線アクセスネットワークに接続されているが、当業者であれば、本明細書に記載されている方法は、アクセスネットワークのタイプに制限されるものではなく、さらには、モバイルノードが有線アクセスネットワークに直接接続される場合においても適用可能であることは明らかである。

この例では、ＭＮ８０９は、第１インタフェースＩＦ１上で２つのプレフィックスＰ１及びＰ３をＭＡＧ８０７から受信し、ＰＤＮ８００及びＰＤＮ８０１のそれぞれからＰＤＮサービスへアクセスすると仮定する。これらのプレフィックスは、ＰＢＵ／ＰＢＡメッセージ８２１、８２２のそれぞれによって提供される。さらに、ＭＮ８０９は、第２インタフェースＩＦ２上で２つのプレフィックスＰ２及びＰ４をＭＡＧ８０８から受信し、ＰＤＮ８００及びＰＤＮ８０１のそれぞれからＰＤＮサービスへアクセスすると仮定する。これらのプレフィックスは、ＰＢＵ／ＰＢＡメッセージ８２４、８２５のそれぞれによって提供される。これは、プレフィックスＰ１、Ｐ２がＬＭＡ８０５を論理的な基点にし、プレフィックスＰ３、Ｐ４がＬＭＡ８０６を論理的な基点とすることから明らかである。

ＭＡＧ８０７は、ＬＭＡ８０５、８０６からＰＢＡを受信した後、プレフィックスＰ１、Ｐ２を通知するＲＡ８２３を送信する。また同様に、ＭＡＧ８０８は、ＬＭＡ８０５及びＬＭＡ８０６からＰＢＡを受信した後、プレフィックスＰ３、Ｐ４を通知するＲＡ８２６を送信する。

ここで、接続インタフェースが完全に接続している場合においてプレフィックス再利用要求を実行する決定を行うことを説明する前に、複数インタフェースを同時に使用して異なるＬＭＡによって管理されている複数のＰＤＮからのサービスへアクセスするユースケースについて考察する。例えば、ＭＮ８０９は、図８Ａに示される２つのＰＤＮ８００、８０１に配置されている複数のピアノードとの間で複数のフローを開始しようとしているかもしれない。例えば、このようなフローとして、４つのフロー（２つはＰＤＮ８００に接続されており、別の２つはＰＤＮ８０１に接続されている）を考える。

この場合、４つすべてのフローがあるインタフェースに割り当てられて特定のアクセス技術経由での負荷を増加させるより、ＭＮ８０９の複数のインタフェース間でこれらのフローの負荷バランスを行うほうが有益であると考えられる。フローに関する基本的な負荷バランスを実現した後、ＭＮ８０９が接続されているアクセスネットワークの条件が変化した場合には、ＭＮ８０９は、フロー性能又はフローに関連するＱｏＳを改善するため、及び／又は、負荷バランスの動作を改善するために更なる最適化を望む可能性がある。このとき、ＭＮ８０９は、あるプレフィックスに関連するフローを、接続状態にある別のインタフェースへ移すことを望むかもしれない。これによって、ネットワーク輻輳によるフローの遅延やハンドオーバによる遅延を避けることができるかもしれない。

また、ＭＮ８０９のインタフェースにおける均一ではないアクセスネットワーク状態のために負荷バランスを行うものであってもよい。例えば、あるアクセスネットワークが別のアクセスネットワークより利用可能な帯域幅が大きい場合には、ＭＮ８０９は、あるプレフィックスに関連するフローをより余裕のある帯域幅を持ったアクセス技術へ移すことで、非均一な環境における負荷バランスの実現を望むかもしれない。なお、非均一な環境は、例えば、モバイルノードが特定のインタフェースを通じて接続されている任意のアクセス技術が、モバイルノードが別のインタフェースを通じて接続されている他のアクセス技術よりも輻輳している状態などである。

その結果、ＭＮ８０９は、元々はＩＦ１へ割り当てられていたプレフィックスＰ１をＩＦ２経由となるように移すことを決定すると、図８Ｃに示されているプレフィックス再利用要求メッセージ８２７を送信する。このメッセージ８２７には、プレフィックスＰ１とＡＰＮ１の情報とが含まれている。

ＭＡＧ８０８は、このメッセージ８２７を受信すると、ＡＰＮ１を解析してＬＭＡ８０５のアドレスを特定する。ＭＡＧ８０８は、プレフィックス再利用要求ＰＢＵ８２８をＬＭＡ８０５へ送信し、プレフィックスＰ１を移すよう要求することが可能である。ＬＭＡ８０５は、プレフィックスＰ１を移すことを承認すると、その応答であるＰＢＡ８２９をＭＡＧ８０８へ送信し、ＩＦ１からプレフィックスＰ１を取り除く取り消しメッセージ８３０（プレフィックスＰ１のみを部分的に取り消すためのメッセージ）をＭＡＧ８０７へ送信する。

この取り消しメッセージは、プレフィックスのサブセットの削除を示すフラグがセットされたＰＢＡを利用して送信されてもよく、あるいは、非特許文献７に開示されているバインディング取り消しメッセージに、プレフィックスのサブセットの削除を示す新たなフラグを設けたものを利用して送信されてもよい。

なお、この場合には、ある接続インタフェースから別のインタフェースへ１つのプレフィックスを移す場合を示しているので、ＡＰＮ情報を使用することが有用である。このように、ＨＳＳに関連するシグナリングを行わずにプレフィックスを移す場合には、モバイルノードが送信するＡＰＮとプレフィックスとのマッピングは、正しいＬＭＡを特定するために非常に有用である。

次に、複数のＰＤＮがＡＰＮを共有する場合のＡＰＮを用いた拡張再利用プレフィックス要求方法について説明する。本発明の好適な実施の形態において、ＡＰＮ情報を用いた拡張プレフィックス再利用要求方法は、単一のＡＰＮに関連して複数のＰＤＮが存在する環境においても利用可能である。このような環境は、非特許文献５に開示されているが、非特許文献５では、複数のＰＤＮに単一のＡＰＮが割り当てられている場合に、同一のＡＰＮが割り当てられているＰＤＮが同一のＬＭＡ又はＰ−ＧＷによって管理される必要があると記載されている。

１つのシナリオ例は、ＭＮが１つのＡＰＮで指定されるＰＤＮドメインに、複数のＰＤＮコネクションを確立してサービスを享受するものである。こうした単一ＰＤＮへの複数ＰＤＮコネクションは、３ＧＰＰアクセス手段を持たない複数の端末がＭＮに関連付けられている場合に、ＭＮによって確立されることがある（例えば、それらの端末はＵＳＩＭ（Universal Subscriber Identity Module）のような契約情報などを含み端末認証を実施するための媒体を有していなかったりする場合など）。

他のシナリオ例は、それまで（例えば、ハンドオーバ前など）ＭＮがＩＰｖ４アドレスとＩＰｖ６プレフィックスを含むＰＤＮコネクションを有していたが、それぞれのアドレス／プレフィックスに基づくコネクションを、別々のＰＤＮコネクションとして扱いたい場合が挙げられる。

以下、図９を参照しながら、単一のＡＰＮに関連して複数のＰＤＮが存在する場合に本発明を使用する場合について説明する。図９では、最初に、ＭＮ９１１がインタフェースの１つ（例えばＩＦ１）を介してＭＡＧ９０９に接続されているとする。ＭＮ９１１は、ＰＤＮ９０１、９０２、９０４、９０５からサービスを受信するようサービスに加入しているとする。

ＰＤＮ９０１、９０２は同一のＡＰＮ群（APN cloud）９００に属している。これは、ＰＤＮ９０１、９０２に同一のＡＰＮ（例えば、ＡＰＮ１）が割り当てられていることを意味している。また、ＰＤＮ９０４、９０５は同一のＡＰＮ群９０３に属している。これは、ＰＤＮ９０４、９０５に同一のＡＰＮ（例えば、ＡＰＮ２）が割り当てられていることを意味している。

ＭＮ９１１は４つのＰＤＮ９０１、９０２、９０４、９０５からサービスを受信するようサービスに加入しているので、ＩＦ１を介してＮｅｔＬＭＭドメイン（ＰＭＩＰｖ６ドメイン）９０８に接続する際には、ＭＡＧ９０９がＬＭＡ９０６及びＬＭＡ９０７のそれぞれに１つのＰＢＵを送信する。ＬＭＡ９０６は、ＰＤＮ９０１、９０２からのサービスにアクセスするためのゲートウェイである。ＬＭＡ９０７は、ＰＤＮ９０４、９０５からのサービスにアクセスするためのゲートウェイである。

上述のように、最初の接続で、ＭＡＧ９０９は、ＬＭＡの情報（例えば、ＬＭＡ９０６及びＬＭＡ９０５のアドレス）を、ＨＳＳから提供されるＡＰＮ１情報及びＡＰＮ２情報から取得する。なお、図９では、図面を簡素化するため、このような最初の接続に係るＰＢＵシグナリングの詳細については明示していない。

例えば、ＬＭＡ９０６へ送信されたＰＢＵにはＡＰＮ１情報が含まれており、ＬＭＡ９０７へ送信されたＰＢＵにはＡＰＮ２情報が含まれている。
さらに、上述のＬＭＡ９０６、９０７のいずれかがＰＢＵを受信すると、そのＬＭＡ９０６、９０７は、ＰＢＵに挿入されているＡＰＮ（ＡＰＮ１、ＡＰＮ２）が複数のＰＤＮに対応することを把握する。そして、ＬＭＡ９０６、９０７は、必要なプレフィックス（すなわち、２つのプレフィックス）をＰＢＡによって提供する。ＰＢＡ９１４、９１５に正しいプレフィックスを割り当てる前に、ＬＭＡ９０６は、例えば、ＰＢＵに挿入されているＡＰＮ１をＰＤＮ１、ＰＤＮ２にマッピングし、同様に、ＬＭＡ９０７はＰＢＵに挿入されているＡＰＮ２をＰＤＮ４、ＰＤＮ５にマッピングする。

ＭＡＧ９０９から送信されるＰＢＵは、通常の初期接続トリガ又は再登録トリガである。ＬＭＡ９０６、９０７はＰＢＵを受信した後、対応するＰＢＡ９１４、９１５をＭＡＧ９０９へ返信する。ＰＢＡ９１４には、ＨＮＰオプションにプレフィックスＰ１、Ｐ２が含まれており、同様に、ＰＢＡ９１５には、ＨＮＰオプションにプレフィックスＰ４、Ｐ５が含まれている。プレフィックスＰ１、Ｐ２、Ｐ４、Ｐ５は、それぞれＰＤＮ１、ＰＤＮ２、ＰＤＮ４、ＰＤＮからのサービスにアクセスするために使用される。ＭＡＧ９０９は、これらのプレフィックスをＰＢＡ９１４、９１５によって受信すると、すべてのプレフィックス（プレフィックスＰ１、Ｐ２、Ｐ４、Ｐ５）を通知できるＲＡ９１６を送信する。

ここで、ＭＮ９１１は、第２インタフェースＩＦ２をＭＡＧ９１０に接続する際に、プレフィックス再利用要求を使用することを決定したとする。例えば、ＭＮ９１１は、プレフィックスＰ５及びＡＰＮ２を有するプレフィックス再利用要求メッセージ９１７を送信する。ＭＡＧ９１０は、このメッセージ９１７を受信すると、プレフィックスＰ５に関連するＬＭＡ（ＬＭＡ９０７）を特定することが可能である。すなわち、ＭＡＧ９１０は、ＡＰＮ２を解析してＬＭＡ９０７のアドレスを取得する。この場合、ＭＡＧ９１０は、プレフィックス再利用要求ＰＢＵ９１８をＬＭＡ９０７へ送信し、これによって、１つのＡＰＮが複数のＰＤＮに割り当てられている場合においても、プレフィックス再利用要求が実現される。

次に、ＡＰＮ情報を用いた拡張プレフィックス再利用要求メカニズムの実行に必要なモバイルノードの機能アーキテクチャについて説明する。図２に示すルーティング部２２０は、例えば、ＩＣＭＰｖ６やＩＫＥｖ２プロトコルなど、様々なタイプ（プロトコル）のシグナリングに関するＩＰｖ６ルーティングサポートを提供する。これら様々なタイプのシグナリングをサポートすることによって、拡張プレフィックス再利用要求メッセージは、ＩＣＭＰｖ６やＩＫＥｖ２シグナリングメッセージなどを用いて送信可能となる。

また、図２に示すルーティングテーブル２４０を使用して、プレフィックス再利用要求メッセージが埋め込まれた上記シグナリングメッセージが発送される。ここでは、図２に示すプレフィックス検出モジュール２５０は、２つの追加機能を有している。第１の追加機能は、プレフィックス再利用要求メッセージを実現する際にＡＰＮ情報を必要とすることを決定するための決定機能である。第２の追加機能は、プレフィックス再利用要求メッセージを送信する際に、プレフィックス再利用要求メッセージ内に用いられるべきプレフィックスを特定し、ＡＰＮとプレフィックスとをマッチングする機能である。

また、プレフィックス再利用要求メッセージを送信するプレフィックス管理部２６０は、Ｌ３シグナル又はＬ２シグナルを用いてメッセージを送信するかどうかを決定する機能を有している。さらに、プレフィックス管理部２６０は、プレフィックス及びＡＰＮをグループ化し、ルーティング部２２０又は機能モジュール（ネットワークインタフェース２１０）に実装されているＬ２レイヤ２２０におけるルーティングメカニズムを用いて、関連するシグナリングを構築する追加機能を有している。

また、図２に示すシグナリングインタフェース２９２は、特にプレフィックス再利用要求メッセージをＬ２経由で送信する必要がある際にプレフィックス再利用要求メッセージを処理するシグナリングインタフェースである。例えば、適切かつセキュアなＬ３のモバイルノード−ＭＡＧインタフェースが存在しない場合には、接続シグナリング又は新たなＬ２シグナリングなどのＬ２シグナリングによってプレフィックス再利用要求メッセージを送信することが有用な場合もある。このような場合、プレフィックスとＡＰＮとのマッピングは、シグナリングインタフェース２９２を通じて、プレフィックス管理部２６０からネットワークインタフェース２１０に実装されているＬ２機能へ直接送信される。なお、当業者であれば、上述したネットワークインタフェース２１０内の追加機能は、ＡＰＮを有するプレフィックス再利用要求メッセージを実現する一例であることは明らかであり、その他の方法によって、本発明を実現することも可能である。

また、図１０には、本発明の好適な実施の形態における拡張プレフィックス再利用要求メカニズムを実行するための好適なモバイルノードの動作の一例が図示されている。

モバイルノードは、最初のステップＳ１０００において、プレフィックスのサブセットに関連するハンドオフに関して、プレフィックス再利用要求方法を実行する必要があるかどうかをモバイルノードが確認を行う。上述のように、モバイルノードは、プレフィックスのサブセットに関連するフローに関して、負荷バランスやより良いＱｏＳを実現するためにプレフィックス再利用要求のハンドオフを実行してもよい。

このステップＳ１０００においてプレフィックス再利用要求方法を実行する必要がないと判断された場合には、ステップＳ１００１において、通常の垂直ハンドオフ処理が実行される。この通常の垂直ハンドオフ処理では、垂直ハンドオフにおいて、あるインタフェースから別のインタフェースへすべてのプレフィックスを移すことを示している。

一方、ステップＳ１０００においてプレフィックス再利用要求方法を実行すると判断された場合には、ステップＳ１００２における別の判断処理が行われる。すなわち、ステップＳ１００２において、モバイルノードは、複数インタフェースのモバイルノードがプレフィックス再利用要求メッセージにＡＰＮ情報を付加すべきかどうかを判断する。なお、モバイルノードは、複数のＬＭＡを使用してＮｅｔＬＭＭドメインのサービスにアクセスすることが予測できる場合に、プレフィックス再利用要求メッセージにおいてＡＰＮを提供するかどうかを判断してもよい。ＲＡ内のフラグによって複数のＬＭＡが使用されるという情報がＭＡＧから提供される場合や、モバイルノードが静的にあらかじめ構成された情報（モバイルノードに関連したサービスに関して複数のＬＭＡの使用を特定するＰＬＭＮの識別子又はＮｅｔＬＭＭドメインの識別子）を有している場合などに、モバイルノードは、複数のＬＭＡの使用を予測することができる。また、複数のＬＭＡを使用する環境において、ＭＡＧが異なるＰＢＵからプレフィックスを取得することによって、ＭＡＧから送信されるＲＡが異なる時間にモバイルノードに届けられてもよい。

同一インタフェースに割り当てられたプレフィックスを運ぶＲＡが、時間をずらして到着によって、モバイルノードは、複数のＬＭＡを使用してＮｅｔＬＭＭドメイン内のサービスにアクセスすることを予測することが可能となる。なお、モバイルノードがこのＮｅｔＬＭＭドメイン内のＭＩＰｖ６モードを使用し、異なるホームエージェントを使用している場合には、モバイルノードは、このドメインで複数のサービスにアクセスするために複数のＬＭＡが使用されていることを把握することが可能となる。この場合、ＬＭＡはＨＡ機能も有しており、実際には、１つの物理的なエンティティにおいてＬＭＡ／ＨＡのように機能が共設されている。このように、モバイルノードは、多数の種類の情報のいずれかに基づいて複数のＬＭＡの使用を予測することが可能である。モバイルノードは、例えば、ネットワークから提供される情報、静的に構成された情報、あるいは、短時間のうちに同一インタフェースで受信した複数のＲＡ（あるいは、複数のプレフィックスのセットを運ぶＲＡ）に基づいて、複数のＬＭＡが使用されていることを決定することが可能である。こうした予測機能によって、モバイルノードはステップＳ１００２の処理を実行することが可能である。

ステップＳ１００２で、複数のＬＭＡが使用されておらず、プレフィックス再利用要求メッセージにＡＰＮ情報を付加する必要はないと判断された場合には、モバイルノードは、ステップＳ１００３において、あるプレフィックスのサブセットをメッセージ（トリガメッセージ）に埋め込んでプレフィックス再利用要求を実行する。一方、ステップＳ１００２で、複数のＬＭＡが使用されており、プレフィックス再利用要求メッセージにＡＰＮ情報を付加すべきと判断された場合には、ステップＳ１００４において、どのプレフィックスがどのＡＰＮに関連しているかを分類し、ステップＳ１００５において、プレフィックスとＡＰＮとのマッピングを有するシグナリングメッセージ（トリガメッセージ）を構成して送出する。

なお、このトリガメッセージは、拡張プレフィックス再利用要求メッセージが送信されるアクセスネットワークに依存し、Ｌ２メッセージであってもよく、Ｌ３メッセージであってもよい。また、アクセス技術においてＬ３セキュリティがサポートされている場合には、プレフィックス再利用要求メッセージと共に、ＩＣＭＰｖ６タイプのＬ３メッセージが送信されてもよい。また、アクセス技術がＩＫＥｖ２に関連する場合には、ＩＫＥｖ２シグナリングを使用してプレフィックス再利用要求メッセージが伝送されてもよい。また、アクセスネットワーク内でＬ３メッセージが利用できない場合には、Ｌ２メッセージの送信が行われる必要がある。

次に、本発明の好適な実施の形態において、ＡＰＮ情報を有するプレフィックス再利用要求メッセージを処理するためのＭＡＧのアーキテクチャの一例について説明する。この機能アーキテクチャは、例えば、図１１に示される機能モジュールによって実現される。

図１１に図示されているＭＡＧ１１００は、ＡＰＮ情報を有するプレフィックス再利用要求メッセージを処理するためのＭＡＧ機能を実現するすべてのソフトウェア、ハードウェア、ファームウェアを示している。図１１では、ＭＡＧ１１００は、２つのサブモジュール（下位レイヤプロトコル部１１０２及びレイヤ３プロトコル部１１０１）によって実現され得るとする。下位レイヤプロトコル部１１０２は、複数の下位レイヤプロトコル部１１０２によって構成されている。各下位レイヤプロトコル部１１０２は、ＭＡＧ１１００が接続する任意のアクセスネットワークに関連している。この下位レイヤプロトコル部１１０２は主にデータリンクレイヤ及び物理レイヤに関連するモジュールである。

一方、レイヤ３プロトコル部１１０１は、図１１に図示されているように、４つのサブモジュールによって構成される。これらのサブモジュールは、ＩＰｖ６ルーティング部１１０３、サブセットプレフィックストリガ処理部１１０４、バインディングリスト部１１０５、ＰＭＩＰｖ６シグナリング処理部１１０６である。これらのレイヤ３プロトコル部１１０１のサブモジュールは、図１１に示すように、各サブモジュール間で、シグナリングメッセージを渡すための適切なシグナリングインタフェースを有している。

ＩＰｖ６ルーティング部１１０３は、近隣探索、アドレス構成などを始めとして、基本的なＩＰｖ６ルーティングメカニズムの機能を有している。このＩＰｖ６ルーティング部１１０３では、標準のＩＰｖ６ヘッダがメッセージに付加され、メッセージから削除され、あるいは検出される。

また、サブプレフィックストリガ処理部１１０４は、プレフィックス再利用要求メッセージに埋め込まれているプレフィックス及び関連するＡＰＮを抽出、収集する機能を有している。サブプレフィックストリガ処理部１１０４は、プレフィックス再利用要求メッセージ内のプレフィックス及び関連するＡＰＮを抽出すると、すべてのＡＰＮを解析し、各プレフィックスに関して正しく対応したＬＭＡのアドレスを特定することが可能である。このサブプレフィックストリガ処理部１１０４は、例えば、ＬＭＡのアドレスや関連するプレフィックスなどのようなＡＰＮから解析された情報をＰＭＩＰｖ６シグナリング処理部１１０６へ渡し、適切なＬＭＡに対して適切なＰＢＵを作成することが可能である。

ＰＭＩＰｖ６シグナリング処理部１１０６は、ＰＢＵに関する新たなハンドオフインディケータオプション値を準備し、さらに、プレフィックス再利用のハンドオフ処理を完了する機能や、ＬＭＡから送信された取り消しメッセージのサブセットを処理する機能を有している。この取り消しメッセージは上述の実施の形態で説明したものである。取り消しメッセージの主な機能は、任意のモバイルノードに関してＭＡＧで処理されたプレフィックスのサブセットがもはや妥当ではなくＬＭＡによって取り消された旨をＭＡＧに通知することである。

プレフィックス再利用要求メッセージのためのすべての準備オプションがＰＭＩＰｖ６シグナリング処理部１１０６で形成されると、このＰＭＩＰｖ６シグナリング処理部１１０６は、適切なハンドオフインディケータオプション値を有する通常のＰＢＵを構築する。プレフィックス再利用要求メッセージが接続インタフェースを通じて送信される場合、ＰＢＵには、基本的に新たなタイプのハンドオフインディケータオプションが存在する。このオプションは、その前に接続していたインタフェースからプレフィックスを削除し、接続インタフェースに関連するバインディングキャッシュエントリにそのプレフィックスを追加することを示している。

また、プレフィックス再利用要求メッセージが新たに起動したインタフェースを通じて送信される際には、ＰＭＩＰｖ６シグナリング処理部１１０６は、別の新たなタイプのハンドオフインディケータオプション値をＰＢＵへ追加し、新たに起動したインタフェースに関して作成されたバインディングキャッシュエントリへプレフィックスを割り当てるようＬＭＡへ要求する。

ＰＭＩＰｖ６シグナリング処理部１１０６は、バインディングリストモジュール１１０５との間で相互に通信を行う。バインディングリスト１１０５には、ＭＡＧに接続されているインタフェースに関して、モビリティに関連するダウンリンク及びアップリンクのデータパケットを発送するために必要な情報が含まれる。このバインディングリスト１１０５には、プレフィックス再利用要求メッセージの処理によって伝送されたプレフィックスとＬＭＡとの関連が格納される。

また、下位レイヤプロトコル部１１０２は、Ｌ３プロトコル部１１０１へのシグナリングインタフェース１１１３を有している。通常、シグナリングインタフェース１１１３を介して、下位レイヤプロトコル部１１０２とＬ３レイヤプロトコル部１１０１との間ですべてのシグナリング情報が渡される。シグナリングインタフェース１１１３を介して渡されるシグナリングは、近隣探索メッセージなどのような帯域外シグナリングであってもよく、データペイロードに付加されるプロトコルヘッダのような帯域内シグナリングであってもよい。

シグナリングインタフェース１１１３は、さらに、Ｌ３プロトコルモジュール１１０１内の任意のシグナリングインタフェース（例えば、図１１に示すシグナリングインタフェース１１０７、１１１０など）に接続されている。

インタフェース１１０７は、下位プロトコルレイヤ部１１０２においてＩＣＭＰｖ６メッセージ又はＩＫＥｖ２メッセージのいずれかを受信し、ＩＰｖ６ルーティング部１１０３へそのメッセージを渡すために使用される。ＩＰｖ６ルーティング部１１０３は、このシグナリングメッセージを受信すると、ＩＰｖ６ヘッダを削除して、シグナリングインタフェース１１０９を介してサブセットプレフィックストリガ処理部１１０４へ渡す。また、シグナリングインタフェース１１１１は、プレフィックス及びＬＭＡのアドレスのパラメータをＰＭＩＰｖ６シグナリング処理部１１０６へ渡す。また、シグナリングインタフェース１１１２は、ＰＭＩＰｖ６シグナリング処理部１１０６がバインディングリスト部１１０５からＰＢＵを構成するためのパラメータを取得するために使用される。

また、Ｌ２を通じてプレフィックス再利用要求メッセージを受信した場合に、インタフェース１１１０は、Ｌ２メッセージからプレフィックス再利用要求メッセージを受信するために使用される。また、シグナリングインタフェース１１０８は、ＰＭＩＰｖ６シグナリング処理部１１０６がＩＰｖ６ルーティング部１１０３へＰＢＵを渡すために使用され、これにより、プレフィックス再利用要求を伝送するＰＢＵは、適切なＩＰｖ６ヘッダを用いて構成されるようになる。なお、当業者であれば、上述のＭＡＧ１１００の機能アーキテクチャは、ＡＰＮを有するプレフィックス再利用要求メッセージの処理を実行する一例に過ぎないことは明らかであり、その他の構成によって、本発明を実現することが可能である。

次に、さらに別の好適な実施の形態として、プレフィックス再利用要求メッセージに関連するＬＭＡがＨＳＳへ通知される派生例について説明する。以下、図１２を参照しながら、この派生例に係る方法や適切なシナリオ、この派生例の利点などについて説明する。

図１２において、ＭＮ１２００が第１インタフェースＩＦ１を介してＭＡＧ１２０１に接続されており、ＬＭＡ１２０３へ接続されているＰＤＮ及びＬＭＡ１２０４へ接続されているＰＤＮからサービスへアクセスするために、ＬＭＡ１２０３及びＬＭＡ１２０４からプレフィックスを取得しているとする。また、ＬＭＡ１２０３に接続されているＰＤＮがＡＰＮ１によって特定され、ＬＭＡ１２０４に接続されているＰＤＮがＡＰＮ２によって特定されるとする。

ＭＮ１２００は、両方のインタフェース（ＩＦ１及びＩＦ２）を介してＮｅｔＬＭＭドメインへ接続されており、ＩＦ２をシャットダウンした結果、すべてのプレフィックスがＩＦ１に割り当てられる。すなわち、ＭＡＧ１２０１からのＲＡメッセージ１２１０には、４つのプレフィックス（Ｐ１、Ｐ２、Ｐ３、Ｐ４）が含まれる。また、プレフィックスＰ１及びＰ２は論理的にＬＭＡ１２０３を基点とし、プレフィックスＰ３及びＰ４は論理的にＬＭＡ１２０４を基点とする。

ここで、ＭＮ１２００は、第２インタフェースＩＦ２を起動してＭＡＧ１２０２に接続し、ＩＦ２へプレフィックスＰ１のみを移すとする。この場合、ＭＮ１２００は、プレフィックス再利用要求メッセージ１２１１をＭＡＧ１２０１へ送信することが可能である。メッセージ１２１１には、プレフィックスＰ１に関連付けられているＬＭＡがプレフィックスＰ１を取り扱っていることをＨＳＳ／ＡＡＡ１２０５へ通知するための新たなシグナリングが含まれている。なお、ＨＳＳ／ＡＡＡ１２５に対してＬＭＡの情報を通知する目的は、ＭＮ１２００が新たなＭＡＧへ接続する際に、プレフィックスＰ１を取り扱っているＬＭＡを新たなＭＡＧへ通知することにある。

図１２において、ＭＡＧ１２０１は、メッセージ１２１１を受信すると、まず、プレフィックスＰ１に関連するＬＭＡ１２０３を特定する。なお、この情報は既にバインディングリストに存在している。ＬＭＡ１２０３のアドレスを特定した後、ＭＡＧ１２０１は、登録解除メッセージ（ＰＢＵ）１２１２をＬＭＡ１２３へ送信する。登録解除メッセージ１２１２には、プレフィックスのサブセット（すなわち、プレフィックスＰ１）の登録解除を示す新たなハンドオフインディケータオプションが埋め込まれている。なお、通常の登録解除と同様に、登録解除メッセージ１２１２では、バインディングライフタイムがゼロにセットされる。また、登録解除メッセージ１２１２のモビリティヘッダには、ＬＭＡ１２０３のアドレスをＨＳＳに通知するなどの更なる処理を示すフラグが含まれていてもよい。

ＬＭＡ１２０３は、登録解除メッセージ１２１２を受信すると、２つの主要な動作を実行する。第１の動作は、ＬＭＡ１２０３がＩＦ１に関連するバインディングキャッシュからプレフィックスＰ１を削除することである。また、第２の動作は、例えばメッセージ１２１３のような新たなメッセージをＨＳＳ１２０５へ送信することである。この新たなメッセージ１２１３は、例えばＩＦ２に関するアクセス認証を送信する際にＨＳＳ／ＡＡＡ１２０５へ通知され、プレフィックス再利用要求においてＬＭＡ１２０３が使用されることを明示するためのものである。

ＨＳＳ１２０５は、このメッセージ１２１３を受信すると、応答のシグナリング（ＡＣＫメッセージ）１２１４を送信し、これに続いて、ＬＭＡ１２０３からＭＡＧ１２０１へメッセージ１２１５が伝送される。なお、当業者であれば、ＰＢＡメッセージ１２１５は必ずしもＡＣＫメッセージ１２１４の後で送信される必要がないことは明らかである。ＭＮ１２００は、ＩＦ１へ接続されていたＭＡＧを使用して、ＩＦ１からプレフィックスＰ１の再利用を要求した後、ＩＦ２をＭＡＧ１２０２へ接続する。また、ＭＮ１２００は、ＩＦ２を介して接続すると通常の垂直ハンドオフのトリガメッセージ１２１６を送信する。ＭＡＧ１２０２は、メッセージ１２１６に埋め込まれた新たなプレフィックス再利用要求メッセージの処理を行う際、メッセージ１２１７に示されているような通常のアクセス認証処理を開始する。

ＨＳＳ／ＡＡＡ１２０５は、アクセス認証の成功を示す情報を返す際に、さらに、このプレフィックス再利用要求メッセージに関係していることを示す特別なマークを付加してＬＭＡ１２０３のアドレスを通知する（例えば、メッセージ１２１７によって）。ＭＡＧ１２０２は、この新たなトリガをＨＳＳ／ＡＡＡ１２０５から受信すると、ＭＡＧ１２０２がＰＢＵを送信する必要があるＬＭＡを把握する。そして、ＭＡＧ１２０２は、通常の垂直ハンドオフのトリガメッセージ１２１８をＬＭＡ１２０３へ送信する。このメッセージ１２１８をＭＮ１２００から受信すると、ＬＭＡ１２０３はプレフィックスＰ１をＩＦ２へ移すか、あるいは、ＩＦ２に関して作成されたモビリティセッションへ割り当て、さらに、ＭＡＧ１２０２経由のプレフィックスＰ１に関するプレフィックス経路を作成するためにＰＢＡメッセージ１２１９を送信する。ＭＡＧ１２０２は、ＰＢＡメッセージ１２１９を受信すると、ＲＡ１２２０を送信してＩＦ２経由でプレフィックスＰ１を通知する。

この派生例は、プレフィックスＰ１に関して登録削除が行われるので、プレフィックスＰ１の垂直ハンドオフの間に、ＭＡＧ１２０１への不要なパケットの伝送を防ぐことが可能となるという第１の利点を有する。インタフェースをシャットダウンするとともに別のインタフェースを起動することによってプレフィックス再利用方法を使用する場合には、選択的にプレフィックスの登録削除を行うことが有用である。

この派生例のようなシナリオをサポートするユースケースは、例えば、ＰＭＩＰｖ６モビリティ管理メカニズムによるプレフィックスのセッション連続性が別のインタフェースで必要とされないことをモバイルノードが発見する場合である。これは、１つ又は複数のプレフィックスが最早使用されなくなる場合や、１つ又は複数のプレフィックスのセッション連続性が必要とされない場合（例えば、ウェブ閲覧の場合のみ）などである。例えば、プレフィックスＰ１に向けて送信されるパケットが、アクセスネットワークでの大きな輻輳の影響によってＭＡＧ１２０１で破棄され手しまうかもしれないが、この派生例によれば、こうした望ましくない状況を避けることができる。

また、無線媒体を介してＬＭＡ情報又はＡＰＮ情報が提供されないので、無線媒体を介するシグナリング量を少なくすることができるという第２の利点がある。また、ＬＭＡ１２０３のアドレスがＨＳＳ／ＡＡＡ１２０５から通知されるので、複数のＬＭＡがＰＤＮを処理し、ＡＰＮから１つのＬＭＡが解析できないＬＭＡ群のケースに対して適切に処理が行われるという第３の利点がある。また、ＬＭＡ群のケースにおいて、正しいＬＭＡを特定するためにＭＡＧがＡＰＮを解析してＨＳＳ情報とのマッチングを実行する必要がないので、ＭＡＧで必要とされる処理負荷が少なくなるという第４の利点がある。

次に、モバイルノードが以前のＭＡＧからＬＭＡを取得する派生例について説明する。本発明の好適な実施の形態において、モバイルノードが、プレフィックス再利用要求メッセージ内のプレフィックスに関するＬＭＡのアドレスを、その前にプレフィックスが割り当てられていたインタフェースが接続していたＭＡＧ（以前のＭＡＧ）から取得し、新たなＭＡＧ又はターゲットのＭＡＧへ渡すことが可能である。

新たなＭＡＧ又はターゲットのＭＡＧは、移されるプレフィックス又はプレフィックスのサブセットが見出される必要があるインタフェースに接続されている。また、以前のＭＡＧは、プレフィックスのサブセットが削除されるインタフェース（プレフィックスが移される元のインタフェース）に接続されている。なお、モバイルノードが、あるインタフェースから別のインタフェースへプレフィックスのサブセットを移すことを決定してもよい。

このような場合に、モバイルノードは、以前のＭＡＧへ問い合わせ、プレフィックスのサブセットに関連するＬＭＡのアドレスを取得してもよい。このプレフィックスのサブセットは、まもなく以前のＭＡＧへ接続されているインタフェースから削除され、別のインタフェースへ移される。

モバイルノードは、以前のＭＡＧによって提供される応答からプレフィックスのサブセットに関するＬＭＡのアドレスを取得した後、プレフィックスのサブセットが新たに設定される必要があるインタフェースに接続されている新たなＭＡＧへプレフィックス再利用要求メッセージを送信する。

このとき、モバイルノードは、プレフィックス及び関連するＬＭＡのアドレス情報をターゲットのＭＡＧへ提供する。例えば、ターゲットのＭＡＧへ送信されるプレフィックス再利用要求メッセージに関連付けるプレフィックスが２つ存在する場合には、モバイルノードは、２つのＬＭＡアドレス（各プレフィックスに付加されているアドレス）を提供する。その結果、ターゲットのＭＡＧは、どのプレフィックス再利用ＰＢＵがどのＬＭＡへ送信される必要があるかを把握する。

ターゲットのＭＡＧへ提供されるプレフィックス再利用要求メッセージに、例えば［Ｐ１、ＬＭＡ１］及び［Ｐ２、ＬＭＡ２］のような情報が含まれている場合には、ターゲットのＭＡＧは、ＨＮＰオプション及びプレフィックス再利用要求を示すための新たなＨＩ（Handover Initiation）オプションにプレフィックスＰ１を挿入したプレフィックス再利用要求ＰＢＵをＬＭＡ１へ送信する。また同様に、ターゲットのＭＡＧは、ＨＮＰオプション及びプレフィックス再利用要求を示すための新たなＨＩオプションにプレフィックスＰ２を挿入したプレフィックス再利用要求ＰＢＵをＬＭＡ２へ送信する。

この方法では、アクセス認証に関連するＨＳＳ／ＡＡＡが必要ではない。したがって、あるインタフェースから別のインタフェースへプレフィックスを移す場合に、コアネットワークでのシグナリングが低減され、有用である。また、モバイルノードは、ＣＭＩＰｖ６の動作が可能であり、ＬＭＡのアドレス（すなわち、ＨＡのアドレス）を把握している場合には、ＬＭＡのアドレスを取得するための追加のシグナリングは必要ない。また、正しいＬＭＡアドレスを特定するためにＡＰＮが解析される必要はないので、ターゲットのＭＡＧにおける処理負荷も低減される。

なお、ＬＭＡ群のケースでは、ターゲットのＭＡＧはＨＳＳ／ＡＡＡから情報を取得して、正しいＬＭＡのアドレスを特定する必要があるが、ＬＭＡのアドレスがモバイルノードから通知される場合には、ターゲットＭＡＧにおいて追加の処理は必要なくなる。また、モバイルノードは、コンテキストトランスファーメカニズムを利用して新たなＭＡＧへプレフィックス再利用要求メッセージを伝送させる際に、以前のＭＡＧがＬＭＡのアドレスを通知するようにしてもよい。

なお、上記の本発明の実施の形態において、プレフィックスの種類を３つ挙げて説明したが、他にも様々な特性のプレフィックスを扱うことが考えられ、このような様々な特性のプレフィックスに対して本発明は適用可能である。例えば、ローカルブレイクアウト用プレフィックスは、ＭＮ１００が来訪ドメイン（visited domain）に接続している際にホームドメイン経由ではなく、直接、来訪ドメインの管理するプレフィックスを得ることで、ネットワーク接続を行うためのものである、一般に、ローカルブレイクアウト用プレフィックスは維持されないローカルプレフィックスに類似しているが、ローミング関係の構成によってはプレフィックスの維持が可能なものがあるかもしれない。ローカルブレイクアウト用プレフィックスに関しては、詳細な扱い方の差異も含め、アドレスの要求ができるようにすることが望ましい。

また、同一モビリティ管理ドメインでの複数プレフィックス利用に関わるプレフィックスが存在する。それぞれのプレフィックスは主に異なるＰＤＮ（Packet Data Network）から、異なるサービス用途（音声、映像、データ、アップロード、ダウンロードなどの各用途）で提供される。これらのサービスと、プレフィックスの維持の必要性、サービス（セッション）のネットワークインタフェースをまたぐハンドオーバー（同一プレフィックスの割り当て）などの利用方法によって、使い分けが可能である。さらには、ＭＮ１００のネットワークインタフェースがネットワークに接続して初めて割り当てられるプレフィックス（デフォルトのプレフィックス）のほかに、あらかじめ必要と思われるプレフィックスの割り当て（準デフォルトのプレフィックス）及び、使用予定のないプレフィックスの削除においても、本発明を適用することが可能である。

なお、ここでは、本発明は、最も実用的かつ好適であると考えられる実施の形態で開示及び説明されているが、当業者であれば、本発明の範囲から逸脱しない程度において、設計事項やパラメータの詳細に関して様々な変更が加えられてもよいことが分かることは明白である。

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

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

ＭＮ１００は、複数の通信デバイスから構成されるものであってもよく、例えばパーソナルコンピュータなどの電子計算機に外挿型あるいは組み込み型の３ＧＰＰ通信用デバイスモジュール又は非３ＧＰＰ通信デバイスモジュールを装着する場合などがあり、こうした多様なＭＮ１００においても本発明は同等の効果を有するものである。また、上記の本発明の実施の形態では、ＭＮ１００が送受信部を介して基地局と無線通信を行うことを前提に説明を行っているが、ＭＮ１００が基地局相当のアクセスポイントと有線通信を行うものであってもよく、アクセスポイント間の切り替えにおいて同等の効果を有するものである。

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

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

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

本発明は、複数のアクセス技術を有する移動端末がローカルネットワークのモビリティ管理ドメイン内を移動する場合に、移動端末に割り当てられるプレフィックス数をできるだけ少なくし、プレフィックスが効率的に利用されるようにするという効果を有し、パケット交換型データ通信ネットワークにおける通信技術に適用可能であり、特に、通信相手ノードと通信を行う移動端末が複数のアドレスを有する場合における通信技術や、ネットワークドメインがネットワークベースのローカルモビリティ管理を行っている場合における通信技術に適用可能である。

Johnson, D. B., Perkins, C. E., and Arkko, J., "Mobility Support in IPv6", Internet Engineering Task Force Request For Comments 3775, June 2004. Gundavelli, S., et al., "Proxy Mobile IPv6", Internet Engineering Task Force Draft draft-ietf-netlmm-proxymip6-11.txt, Feb 2008. Soliman, H. et al., "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", Internet Engineering Task Force Request For Comments 4140, August 2005. Gundavelli, S., et. al., "Proxy Mobile IPv6", Internet Engineering Task Force (IETF) Internet Engineering Task Force Request For Comments 5213, August 2008. "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Architecture enhancements for non-3GPP accesses", 3GPP TS 23.402, V8.4.1, January 2009. "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; General Packet Radio Service(GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access", 3GPP TS 23.401, V8.4.1, December 2008. Muhanna, A. et. al., "Binding Revocation for IPv6 Mobility", Internet Engineering Task Force Draft, draft-ietf-mext-binding-revocation-03.txt, January 2009.

また、上記の目的を達成するため、本発明のプレフィックス割り当て管理装置は、ネットワークベースのローカルモビリティドメインに接続されている移動端末へのネットワークプレフィックスの割り当てを管理するためのプレフィックス割り当て管理装置であって、
前記移動端末へのネットワークプレフィックスの割り当てを管理し、前記移動端末に対して割り当てられたネットワークプレフィックスと前記移動端末との対応関係を維持するプレフィックス対応維持手段と、前記移動端末にとって必要なネットワークプレフィックスが割り当てられた状態を実現するための情報を含むプレフィックスプリファレンス情報を前記移動端末から受信した場合に、前記プレフィックスプリファレンス情報に基づいて、前記移動端末に対して割り当てられたネットワークプレフィックスと前記移動端末との対応関係を変更するプレフィックス管理手段とを、
有する。
この構成により、複数のアクセス技術を有する移動端末がローカルネットワークのモビリティ管理ドメイン内を移動する場合に、移動端末にとって必要なプレフィックスが割り当てられるよう管理することで、移動端末に割り当てられるプレフィックス数をできるだけ少なくすることが可能となる。

本発明の実施の形態における動作例を示すシーケンスチャート本発明の実施の形態におけるモバイルノードの好適な機能アーキテクチャの一例を示す図本発明の実施の形態におけるプレフィックス削減モードの動作例を示すシーケンスチャート本発明の実施の形態におけるプレフィックス削減モードの動作例であり、ネットワークインタフェースのシャットダウンによって、余分なプレフィックスが発生した場合の動作例を示すシーケンスチャート本発明の実施の形態におけるプレフィックス再利用モードの動作例を示すシーケンスチャート本発明の実施の形態におけるプレフィックス再利用モードの動作例であり、１つのネットワークインタフェースに複数のプレフィックスが割り当てられており、別のネットワークインタフェースが起動する場合の動作例を示すシーケンスチャート本発明の実施の形態におけるプレフィックスリサイクルモードの動作例を示すシーケンスチャート本発明の実施の形態におけるプレフィックスリサイクルモードの別の動作例を示すシーケンスチャート本発明の実施の形態におけるシステム構成の一例を示す図図６Ａにおける動作例を示すシーケンスチャート従来の技術におけるネットワーク構成の一例を示す図図７Ａの状態からモバイルノードが移動して、ＩＦ２の接続が切断された状態を示す図本発明の実施の形態におけるプレフィックス再利用モードの動作の別の一例を示すシーケンスチャート本発明に係る拡張プレフィックス再利用方法の動作に関連するネットワークエンティティを含むネットワーク構成の一例を示す図本発明の実施の形態における拡張プレフィックス再利用モードの動作例を示すシーケンスチャート本発明の実施の形態における拡張プレフィックス再利用モードの動作の別の一例を示すシーケンスチャート本発明の実施の形態において、単一のＬＭＡに複数のＡＰＮが関連している場合のネットワーク構成の一例を示す図本発明の実施の形態において、モバイルノードによる拡張プレフィックス再利用モードの動作の一例を示すフローチャート本発明の実施の形態におけるＭＡＧの構成の一例を示す図本発明の実施の形態における拡張プレフィックス再利用モードの動作の更に別の一例を示すシーケンスチャート本発明の実施の形態におけるプレフィックスプリファレンスメッセージを含むメッセージ構造の一例を示す図発明を実施するための形態

以下、本発明の実施の形態について説明する。

以下、これらの各モードに関する詳細について説明する。

ＭＡＧ７０２Ｃは、このプレフィックス再利用要求メッセージ７１１Ｃを受信すると、アクセス認証を開始し、ＨＳＳ／ＡＡＡエンティティ７０５Ｃと認証シグナル交換を行う。ＨＳＳ７０５Ｃは、アクセス認可の成功を示す情報、ＬＭＡ７０３Ｃ及びＬＭＡ７０４Ｃのアドレス、ＭＮ７００Ｃに関連するサービス加入者情報を提供する。

例えば、ＬＭＡ９０６へ送信されたＰＢＵにはＡＰＮ１情報が含まれており、ＬＭＡ９０７へ送信されたＰＢＵにはＡＰＮ２情報が含まれている。さらに、上述のＬＭＡ９０６、９０７のいずれかがＰＢＵを受信すると、そのＬＭＡ９０６、９０７は、ＰＢＵに挿入されているＡＰＮ（ＡＰＮ１、ＡＰＮ２）が複数のＰＤＮに対応することを把握する。そして、ＬＭＡ９０６、９０７は、必要なプレフィックス（すなわち、２つのプレフィックス）をＰＢＡによって提供する。ＰＢＡ９１４、９１５に正しいプレフィックスを割り当てる前に、ＬＭＡ９０６は、例えば、ＰＢＵに挿入されているＡＰＮ１をＰＤＮ１、ＰＤＮ２にマッピングし、同様に、ＬＭＡ９０７はＰＢＵに挿入されているＡＰＮ２をＰＤＮ４、ＰＤＮ５にマッピングする。

Claims

ネットワークベースのローカルモビリティドメインに接続されている移動端末へのネットワークプレフィックスの割り当てを管理するプレフィックス割り当て管理システムであって、
前記移動端末が通信を行うために不要なネットワークプレフィックスが前記移動端末へ割り当てられる状態を維持しないように構成されているネットワークプレフィックス割り当て管理システム。
前記ローカルモビリティドメイン内のネットワークエンティティが、前記移動端末に対して既に割り当てられており前記移動端末の通信に不要となったネットワークプレフィックスを検出し、前記移動端末の通信に不要となったネットワークプレフィックスを前記移動端末に対するネットワークプレフィックス割り当てから削除するよう構成されている請求項１に記載のネットワークプレフィックス割り当て管理システム。
前記移動端末が、前記移動端末が通信を行うために必要なネットワークプレフィックスが前記移動端末へ割り当てられる状態を検出し、前記ネットワークプレフィックス使用最適化検出手段で検出された、前記移動端末にとって必要なネットワークプレフィックスが割り当てられた状態を実現するための情報を含むプレフィックスプリファレンス情報を、前記ローカルモビリティドメインへ通知するよう構成されている請求項１に記載のネットワークプレフィックス割り当て管理システム。
前記移動端末が、前記移動端末に対して既に割り当てられており前記移動端末の通信で不要となったネットワークプレフィックスを検出し、前記移動端末の通信において不要なネットワークプレフィックスを前記移動端末に対するネットワークプレフィックス割り当てから削除するよう要求する前記プレフィックスプリファレンス情報を前記ローカルモビリティドメインへ送信することで、前記ローカルモビリティドメイン内のネットワークエンティティが、前記移動端末の通信で不要となったネットワークプレフィックスを前記移動端末に対するネットワークプレフィックス割り当てから削除するよう構成されている請求項３に記載のネットワークプレフィックス割り当て管理システム。
複数のネットワークインタフェースによって前記ローカルモビリティドメインへ接続されている前記移動端末が、前記移動端末の複数のネットワークインタフェースのうちの第１ネットワークインタフェースに対して既に割り当てられており、前記移動端末の複数のネットワークインタフェースのうちの前記第１ネットワークインタフェースとは異なる第２ネットワークインタフェースで再利用可能なネットワークプレフィックスを検出し、前記再利用可能なネットワークプレフィックスを前記第２ネットワークインタフェースへ割り当てるよう要求する前記プレフィックスプリファレンス情報を前記ローカルモビリティドメインへ送信することで、前記ローカルモビリティドメイン内のネットワークエンティティが、前記移動端末の前記第１ネットワークインタフェースから前記第２ネットワークインタフェースへ前記再利用可能なネットワークプレフィックスの割り当てを変更するよう構成されている請求項３に記載のネットワークプレフィックス割り当て管理システム。
前記移動端末へ割り当てる前記ネットワークプレフィックスの管理及び割り当てを行う複数のプレフィックス管理エンティティが前記ローカルネットワークドメインに存在する場合に、前記複数のプレフィックス管理エンティティのうちから、前記再利用可能なネットワークプレフィックスの割り当て変更を行えるプレフィックス管理エンティティが特定される請求項５に記載のネットワークプレフィックス割り当てシステム。
前記移動端末が、前記再利用可能なネットワークプレフィックスに関連するアクセスポイントネームを前記ローカルモビリティドメインへ送信することによって、前記再利用可能なネットワークプレフィックスの割り当て変更を行えるプレフィックス管理エンティティが特定される請求項６に記載のネットワークプレフィックス割り当てシステム。
前記移動端末が、前記再利用可能なネットワークプレフィックスの割り当てを行ったプレフィックス管理エンティティを特定し、前記再利用可能なネットワークプレフィックスを前記第２ネットワークインタフェースへ割り当てるよう要求する際に、前記特定されたプレフィックス管理エンティティの情報を送信するよう構成されている請求項６に記載のネットワークプレフィックス割り当てシステム。
前記移動端末が、前記再利用可能なネットワークプレフィックスが割り当てられた際に接続していたネットワークノードに対して、前記再利用可能なネットワークプレフィックスの割り当てを行ったプレフィックス管理エンティティの特定を要求するよう構成されている請求項６に記載のネットワークプレフィックス割り当てシステム。
前記移動端末が、前記移動端末に対して割り当てられるネットワークプレフィックスが一時的に利用されるものであることを検出し、前記移動端末に対して割り当てられるネットワークプレフィックスを一時的に利用することを示す前記プレフィックスプリファレンス情報を前記ローカルモビリティドメインへ送信することで、前記ネットワークプレフィックスの一時的な使用が終了した場合に、前記ローカルモビリティドメイン内のネットワークエンティティが、前記移動端末による一時的な使用が終了したネットワークプレフィックスを前記移動端末に対するネットワークプレフィックス割り当てから削除するよう構成されている請求項３に記載のネットワークプレフィックス割り当て管理システム。
ネットワークベースのローカルモビリティドメインに接続されており、前記ローカルモビリティドメインから割り当てられるネットワークプレフィックスを用いて通信を行う移動端末であって、
前記移動端末が通信を行うために必要なネットワークプレフィックスが前記移動端末へ割り当てられる状態を検出するプレフィックス使用最適化検出手段と、
前記ネットワークプレフィックス使用最適化検出手段で検出された、前記移動端末にとって必要なネットワークプレフィックスが割り当てられた状態を実現するための情報を含むプレフィックスプリファレンス情報を、前記ローカルモビリティドメインへ通知するプレフィックスプリファレンス情報通知手段とを、
有する移動端末。
前記プレフィックス使用最適化検出手段が、前記移動端末に対して既に割り当てられており前記移動端末の通信で不要となったネットワークプレフィックスを検出し、
前記プレフィックスプリファレンス情報通知手段が、前記移動端末の通信において不要なネットワークプレフィックスを前記移動端末に対するネットワークプレフィックス割り当てから削除するよう要求する前記プレフィックスプリファレンス情報を前記ローカルモビリティドメインへ送信するよう構成されている請求項１１に記載の移動端末。
前記プレフィックス使用最適化検出手段が、前記ネットワークインタフェースのシャットダウンを検出することで、前記シャットダウンするネットワークインタフェースに割り当てられているネットワークプレフィックスを、前記移動端末に対して既に割り当てられており前記移動端末の通信で不要となったネットワークプレフィックスとして検出するよう構成されている請求項１２に記載の移動端末。
前記ローカルネットワークドメインから複数の異なる種類のプレフィックスが割り当てられ、前記プレフィックス使用最適化検出手段が、前記複数の異なる種類のプレフィックスの中から不要なネットワークプレフィックスを検出するよう構成されている請求項１２に記載の移動端末。
前記移動端末が、複数のネットワークインタフェースによって前記ローカルモビリティドメインへ接続されており、
前記プレフィックス使用最適化検出手段が、前記移動端末の複数のネットワークインタフェースのうちの第１ネットワークインタフェースに対して既に割り当てられており、前記移動端末の複数のネットワークインタフェースのうちの前記第１ネットワークインタフェースとは異なる第２ネットワークインタフェースで再利用可能なネットワークプレフィックスを検出し、
前記プレフィックスプリファレンス情報通知手段が、前記再利用可能なネットワークプレフィックスを前記第２ネットワークインタフェースへ割り当てるよう要求する前記プレフィックスプリファレンス情報を前記ローカルモビリティドメインへ送信するよう構成されている請求項１１に記載の移動端末。
前記プレフィックス使用最適化検出手段が、前記第２ネットワークインタフェースの起動を検出した場合に、前記第１ネットワークインタフェースに対して既に割り当てられているネットワークプレフィックスが、前記第２ネットワークインタフェースで再利用可能か否かを判断するよう構成されている請求項１５に記載の移動端末。
前記移動端末へ割り当てる前記ネットワークプレフィックスの管理及び割り当てを行う複数のプレフィックス管理エンティティが前記ローカルネットワークドメインに存在する場合に、前記複数のプレフィックス管理エンティティのうちから、前記再利用可能なネットワークプレフィックスの割り当て変更を行えるプレフィックス管理エンティティが特定される請求項１６に記載の移動端末。
前記再利用可能なネットワークプレフィックスに関連するアクセスポイントネームを前記ローカルモビリティドメインへ送信することによって、前記再利用可能なネットワークプレフィックスの割り当て変更を行えるプレフィックス管理エンティティが特定される請求項１７に記載の移動端末。
前記再利用可能なネットワークプレフィックスの割り当てを行ったプレフィックス管理エンティティを特定し、前記再利用可能なネットワークプレフィックスを前記第２ネットワークインタフェースへ割り当てるよう要求する際に、前記特定されたプレフィックス管理エンティティの情報を送信するよう構成されている請求項１７に記載の移動端末。
前記再利用可能なネットワークプレフィックスが割り当てられた際に接続していたネットワークノードに対して、前記再利用可能なネットワークプレフィックスの割り当てを行ったプレフィックス管理エンティティの特定を要求するよう構成されている請求項１７に記載の移動端末。
前記プレフィックス使用最適化検出手段が、前記移動端末に対して割り当てられるネットワークプレフィックスが一時的に利用されるものであることを検出し、
前記プレフィックスプリファレンス情報通知手段が、前記移動端末に対して割り当てられるネットワークプレフィックスを一時的に利用することを示す前記プレフィックスプリファレンス情報を前記ローカルモビリティドメインへ送信するよう構成されている請求項１１に記載の移動端末。
前記プレフィックス使用最適化検出手段が、前記移動端末が通信を行うために維持される必要があるか否かを判断するよう構成されている請求項２１に記載の移動端末。
前記プレフィックス使用最適化検出手段が、前記移動端末に対して割り当てられるネットワークプレフィックスが特定の通信サービスのみで使用されるものであるか否かを判断するよう構成されている請求項２１に記載の移動端末。
前記プレフィックス使用最適化検出手段が、これから前記移動端末に対して割り当てられるネットワークプレフィックスが一時的に利用されるものであるか否かを判断するよう構成されている請求項２１に記載の移動端末。
前記プレフィックス使用最適化検出手段が、既に前記移動端末に対して割り当てられているネットワークプレフィックスが一時的に利用されるものであるか否かを判断するよう構成されている請求項２１に記載の移動端末。
前記移動端末による前記ネットワークプレフィックスの一時的な利用が終了した場合に、前記プレフィックスプリファレンス情報通知手段が、前記ネットワークプレフィックスの一時的な利用が終了したことを前記ローカルモビリティドメインへ通知するよう構成されている請求項１１に記載の移動端末。
前記プレフィックスプリファレンス情報通知手段が、近隣探索メッセージ、ＤＨＣＰメッセージ、レイヤ２接続確立シグナリングメッセージ、ＡＡＡシグナリングメッセージのいずれかに前記プレフィックスプリファレンス情報を挿入して、前記ローカルモビリティドメインへ通知するよう構成されている請求項１１に記載の移動端末。
前記プレフィックス使用最適化検出手段が、
前記移動端末に対して既に割り当てられており前記移動端末の通信で不要となったネットワークプレフィックスを検出する第１の検出機能と、
前記移動端末が、複数のネットワークインタフェースによって前記ローカルモビリティドメインへ接続されており、前記移動端末の複数のネットワークインタフェースのうちの第１ネットワークインタフェースに対して既に割り当てられており、前記移動端末の複数のネットワークインタフェースのうちの前記第１ネットワークインタフェースとは異なる第２ネットワークインタフェースで再利用可能なネットワークプレフィックスを検出する第２の検出機能と、
前記プレフィックス使用最適化検出手段が、前記移動端末に対して割り当てられるネットワークプレフィックスが一時的に利用されるものであることを検出する第３の検出機能とを、
有し、
前記プレフィックスプリファレンス情報通知手段が、
前記第１の検出機能で検出された前記移動端末の通信において不要なネットワークプレフィックスを前記移動端末に対するネットワークプレフィックス割り当てから削除するよう要求する前記プレフィックスプリファレンス情報を前記ローカルモビリティドメインへ送信する第１の通知機能と、
前記第２の検出機能で検出された前記再利用可能なネットワークプレフィックスを前記第２ネットワークインタフェースへ割り当てるよう要求する前記プレフィックスプリファレンス情報を前記ローカルモビリティドメインへ送信する第２の通知機能と、
前記第３の検出機能で検出された一時的に利用される前記ネットワークプレフィックスに関して、前記移動端末に対して割り当てられるネットワークプレフィックスを一時的に利用することを示す前記プレフィックスプリファレンス情報を前記ローカルモビリティドメインへ送信する第３の通知機能とを、
有し、
前記移動端末に対して割り当てられるネットワークプレフィックスに関して、前記第１の検出機能及び前記第１の通知機能、前記第２の検出機能及び前記第２の通知機能、前記第３の検出機能及び前記第３の通知機能のいずれを適用するかを選択するモード選択手段を更に有する請求項１１に記載の移動端末。
前記モード選択手段が、ホームプレフィックスに関しては前記第２の検出機能及び前記第２の通知機能、ローカルプレフィックスに関しては前記第３の検出機能及び前記第３の通知機能の適用を選択するよう構成されている請求項２８に記載の移動端末。
ネットワークベースのローカルモビリティドメインに接続されている移動端末へのネットワークプレフィックスの割り当てを管理するためのプレフィックス割り当て管理装置であって、
前記移動端末へのネットワークプレフィックスの割り当てを管理し、前記移動端末に対して割り当てられたネットワークプレフィックスと前記移動端末との対応関係を維持するプレフィックス対応維持手段と、
前記移動端末にとって必要なネットワークプレフィックスが割り当てられた状態を実現するための情報を含むプレフィックスプリファレンス情報を前記移動端末から受信した場合に、前記プレフィックスプリファレンス情報に基づいて、前記移動端末に対して割り当てられたネットワークプレフィックスと前記移動端末との対応関係を変更するプレフィックス管理手段とを、
有するプレフィックス割り当て管理装置。
前記移動端末の通信において不要なネットワークプレフィックスを前記移動端末に対するネットワークプレフィックス割り当てから削除するよう要求する前記プレフィックスプリファレンス情報を前記移動端末から受信した場合に、前記プレフィックス管理手段が、前記移動端末に対して割り当てられたネットワークプレフィックスと前記移動端末との対応関係において、前記移動端末の通信において不要なネットワークプレフィックスの割り当てを削除するよう構成されている請求項３０に記載のプレフィックス割り当て管理装置。
前記ローカルモビリティドメインへ接続されている前記移動端末の複数のネットワークインタフェースのうちの第１ネットワークインタフェースに対して既に割り当てられており、前記移動端末の複数のネットワークインタフェースのうちの前記第１ネットワークインタフェースとは異なる第２ネットワークインタフェースで再利用可能なネットワークプレフィックスを前記第２ネットワークインタフェースへ割り当てるよう要求する前記プレフィックスプリファレンス情報を前記移動端末から受信した場合に、前記プレフィックス管理手段が、前記移動端末に対して割り当てられたネットワークプレフィックスと前記移動端末との対応関係において、前記第１ネットワークインタフェースへの前記再利用可能なネットワークプレフィックスの割り当てを削除するとともに、前記再利用可能なネットワークプレフィックスを前記第２ネットワークインタフェースへ割り当てるよう構成されている請求項３０に記載のプレフィックス割り当て管理装置。
前記移動端末に対して割り当てられるネットワークプレフィックスが前記移動端末において一時的に利用されることを示す前記プレフィックスプリファレンス情報を前記移動端末から受信した場合に、前記プレフィックス管理手段が、前記移動端末に対して割り当てられたネットワークプレフィックスと前記移動端末との対応関係において、前記一時的に使用されるネットワークプレフィックスに対して、一時的に利用されることを示す情報を付加するよう構成されている請求項３０に記載のプレフィックス割り当て管理装置。
前記プレフィックス管理手段が、前記一時的に使用されるネットワークプレフィックスの種類に応じて、前記移動端末に対して割り当てられたネットワークプレフィックスと前記移動端末との対応関係において、前記一時的に使用されるネットワークプレフィックスの割り当てを削除するタイミングを決定するよう構成されている請求項３３に記載のプレフィックス割り当て管理装置。
前記移動端末による前記ネットワークプレフィックスの一時的な利用が終了した場合に、前記プレフィックスプリファレンス情報通知手段が、前記移動端末による前記ネットワークプレフィックスの一時的な利用が終了したことを示す情報を前記移動端末から受信した場合に、前記プレフィックス管理手段が、前記移動端末に対して割り当てられたネットワークプレフィックスと前記移動端末との対応関係において、前記一時的に使用されるネットワークプレフィックスの割り当てを削除するよう構成されている請求項３３に記載のプレフィックス割り当て管理装置。