JP5371987B2 - 移動端末及びネットワークノード - Google Patents

移動端末及びネットワークノード Download PDF

Info

Publication number
JP5371987B2
JP5371987B2 JP2010521601A JP2010521601A JP5371987B2 JP 5371987 B2 JP5371987 B2 JP 5371987B2 JP 2010521601 A JP2010521601 A JP 2010521601A JP 2010521601 A JP2010521601 A JP 2010521601A JP 5371987 B2 JP5371987 B2 JP 5371987B2
Authority
JP
Japan
Prior art keywords
information
mobile terminal
local mobility
multihoming
mobile
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2010521601A
Other languages
English (en)
Other versions
JPWO2010010695A1 (ja
Inventor
純 平野
チュン キョン ベンジャミン リム
チャン ワー ンー
ティエン ミン ベンジャミン コー
モハナ ダマヤンティ ジャヤタラン
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Panasonic Corp
Panasonic Holdings Corp
Original Assignee
Panasonic Corp
Matsushita Electric Industrial Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Panasonic Corp, Matsushita Electric Industrial Co Ltd filed Critical Panasonic Corp
Priority to JP2010521601A priority Critical patent/JP5371987B2/ja
Publication of JPWO2010010695A1 publication Critical patent/JPWO2010010695A1/ja
Application granted granted Critical
Publication of JP5371987B2 publication Critical patent/JP5371987B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W60/00Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration
    • H04W60/005Multiple registrations, e.g. multihoming
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06Authentication
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W8/00Network data management
    • H04W8/02Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/04Registration at HLR or HSS [Home Subscriber Server]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Mobile Radio Communication Systems (AREA)

Description

本発明は、パケット交換型データ通信ネットワークシステムにおける通信技術に関する。本発明は、特に、マルチホーミング機能を有するモバイルノードがローカルモビリティドメインに接続している場合に、マルチホーミングのサービスを受けることができるようにするための移動端末及びネットワークノードに関する。
下記の非特許文献1に記載のモバイルIPv6(MIPv6)によれば、移動端末(MN:Mobile Node、モバイルノード)は、インターネットへの接続ポイントを変更する場合にインターネットプロトコル(IP)アドレスを変更せずに維持することが可能である。
このMIPv6において変更されることのないIPアドレスは、モバイルノードのホームネットワークドメインにおけるアドレスであり、ホームアドレス(home address)と呼ばれている。モバイルノードが外部(foreign)ネットワークドメインに接続されている間は、モバイルノードは、外部ネットワークドメインによって通知されるサブネットプレフィックスから、使用すべきIPアドレスを構成することが可能である。このように構成されたIPアドレスは、気付アドレス(care-of address)と呼ばれ、モバイルノードはこのアドレス経由でも到達可能となる。
モバイルノードは、その接続位置によらずに到達可能性を維持するため、気付アドレスとホームアドレスとを関連付けてホームエージェントに登録する。MIPv6では、ホームエージェントは、モバイルノードのホームネットワークドメイン内のルータであり、モバイルノードの現在の気付アドレスとそのホームアドレスのバインディングを登録する。これは、モバイルノードがバインディングアップデート(BU:Binding Update)メッセージをホームエージェントへ送信することによって実現される。モバイルノードがホームネットワークドメインから離れている場合には、ホームエージェントは、モバイルノードのホームアドレスあてのパケットを受信(intercept)し、関連付けられた気付アドレス経由で受信したパケットをモバイルノードへ向けトンネルする。上述のMIPv6の説明から分かるように、MIPv6では、ホスト(モバイルノード)がモビリティ管理を行う。したがって、MIPv6は、ホストベースのモビリティ管理プロトコルとしても知られている。
一方、モバイルノードがローカルモビリティドメインを移動している際に、モビリティ関連シグナリングを行わないですむ別のモビリティ管理方式が存在する。このモビリティ管理方式では、ローカルモビリティドメイン内に存在するプロキシエンティティが、モバイルノードのモビリティ管理を行う。こうしたモビリティ管理方式は、ネットワークベースのモビリティ管理と呼ばれ、例えば、下記の非特許文献2に記載されている。
ローカルモビリティドメイン内を移動するモバイルノードは、アクセス認証処理の過程で、モバイルノードの識別情報(MN−ID)を提示することによって、プロキシエンティティ)に接続する。このプロキシエンティティは、例えば、非特許文献2に記載されているMAG(Mobile Access Gateway:モバイルアクセスゲートウェイ)である。MN−IDは、ローカルサーバから取得可能なモバイルノードのポリシプロファイルを関連付けるために用いられる。ポリシプロファイルには、提供されるネットワークベースのモビリティサービスの特性やその他の関連するパラメータ(例えば、モバイルノードに割り当てられるネットワークプレフィックス(例えばMN.Prefix)、許可されているアドレス構成モード、移動ポリシ、ネットワークベースのモビリティサービスを提供するために不可欠なその他のパラメータなど)が含まれている。
モバイルアクセスゲートウェイは、アクセス認証に成功した後、ローカルサーバからモバイルノードのポリシプロファイルを取得する。これは、モバイルアクセスゲートウェイが、モバイルノードに関するモビリティシグナリングを実行するために必要なすべての情報を把握できることを意味する。したがって、モバイルアクセスゲートウェイは、モバイルノードのネットワークプレフィックス(MN.Prefix)を通知するルータ通知を周期的にモバイルノードへ送信する。モバイルノードは、MN.Prefixを参照すると、ローカルモビリティドメインに接続されているインタフェースに対して、通信を行うためのIPアドレス(例えば、ホームアドレス)を構成する。モバイルノードがローカルモビリティドメイン内のどの場所を移動しても、接続インタフェースは、常にMN.Prefixを参照することが可能である。これは、モバイルノードが接続する各モバイルアクセスゲートウェイが常にローカルサーバに問い合わせを行って、モバイルノードのプロファイルを取得することによる。その結果、モバイルノードは、ローカルモビリティドメインのどの位置に接続している場合であっても、通信を行うために、常に最初に構成されたIPアドレスを使用することが可能となる。
このネットワークベースのモビリティ管理を実現するため、ローカルモビリティアンカ(LMA:Local Mobility Anchor)と呼ばれるエンティティが、ローカルモビリティドメイン内の各モバイルノードに対して論理的なアンカポイントとして機能する。さらに、ローカルモビリティアンカは、各モバイルノードに関する到達可能状態の管理を行う。したがって、ローカルモビリティアンカは、非特許文献1に記載のホームエージェントと類似していると言える。各モバイルノードに関するアンカポイントとして機能するために、ローカルモビリティアンカには、各モバイルノードの現在位置がアップデートされる必要がある。したがって、モバイルノードがモバイルアクセスゲートウェイに接続する際は常に、モバイルアクセスゲートウェイは、プロキシバインディングアップデート(PBU:Proxy binding Update)メッセージをローカルモビリティアンカへ送信する。このPBUメッセージによって、MN.Prefixとモバイルアクセスゲートウェイの気付アドレスとの関連付けが行われる。そして、このバインディングによって、ローカルモビリティアンカは、適切なモバイルアクセスゲートウェイ経由でパケットをモバイルノードに発送することが可能となる。
図1には、上述のようなネットワークベースのモビリティ管理に用いられるシステムの一例が図示されている。図1では、ローカルモビリティドメイン10は、ローカルモビリティアンカ(LMA)101と複数のモバイルアクセスゲートウェイ(MAG)102、103、104を有している。モバイルノード(MN)11は、アクセス認証処理の過程でその識別情報(MN−ID)を提示して、モバイルアクセスゲートウェイ(MAG)102とインタフェース(IF)110を接続する。
アクセス認証に成功した後、MAG102は、MN11のMN−IDに基づいて、ローカルサーバからMN11のポリシプロファイルを取得する。これは、MAG102が、MN11に関するモビリティシグナリングを実行するために必要なすべての情報を把握できることを意味する。したがって、MAG102は、モバイルノードのネットワークプレフィックス(MN.Prefix)を通知するルータ通知を周期的にMN11へ送信する。MN11は、このMN.Prefixを参照すると、通信に用いられるIF110のIPアドレスを構成する。MN11がローカルモビリティドメイン10内のどの位置に移動するかに関係なく、IF110は、常に同一の割り当てられたネットワークプレフィックスを参照することができる。これは、MN11が接続する各モバイルアクセスゲートウェイが、常にローカルサーバからMN11のプロファイルを検索することによる。例えば、MN11がMAG103へ移動してIF110によって接続を行う場合、MAG103は、認証処理の間に提示されるMN−IDに基づいて、MN11に割り当てられるネットワークプレフィックスをローカルサーバから取得する。したがって、ローカルモビリティドメイン10内のMN11の位置によらず、MN11は、通信を行うために、常に同一のIPアドレスを使用することが可能となる。
上述のように、LMA101は、各モバイルノードに対して論理的なアンカポイントとして機能するとともに、各モバイルノードの到達可能状態も管理する。各モバイルノードのアンカポイントであるため、LMA101には、各モバイルノードの現在位置についてアップデートされる必要がある。したがって、モバイルノードがモバイルアクセスゲートウェイに接続する際はいつも、モバイルアクセスゲートウェイは、プロキシバインディングアップデート(PBU)メッセージをLMA101へ送信する。このPBUによって、LMA101は、モバイルノードのユニークな識別情報(MN−ID)に基づいて、モバイルノードに関するルーティングエントリを作成することができるようになる。LMA101は、このルーティングエントリにおいて、モバイルノードに割り当てられたネットワークプレフィックスを、モバイルアクセスゲートウェイの気付アドレスと関連付ける。このバインディングによって、LMA101は、適切なモバイルアクセスゲートウェイを通じてパケットをモバイルノードに発送することができる。LMAもまた一種のルータであり、バインディング登録によりバインディングエントリ(単にバインディングと呼ぶこともある)を生成する。LMAがパケットをルーティングする際にはルーティングエントリを参照し、パケットを送信するが、そのルーティングエントリの1つとしてバインディングエントリを参照することが可能である。なお、ルーティングエントリは、その他のルーティングプロトコルによっても生成されるため、同様の仕組みとして、バインディングエントリからルーティングエントリを明示的に生成することも可能である。本明細書においては、バインディング登録に基づくものをバインディングエントリ、ルーティングの際に参照する場合にはルーティングエントリとして説明する場合があるが、上述のように、実施の上での区別は当業者の任意の実装に依存するものであり、バインディングエントリとルーティングエントリの読み替えや、バインディングエントリからルーティングエントリの生成を前提とすることができる。
図1において、MN11は、IF110を使用してMAG102と接続し、必要な認証処理を実行する。認証に成功した後、MAG102は、PBUをLMA101へ送信する。LMA101は、このPBUの内容に基づいて、バインディングキャッシュにおいて、モバイルノードのホームネットワークプレフィックス又はホームアドレスを、MAG102の気付アドレスと関連付ける。LMA110がMN11のホームアドレスあてのパケットを受信した場合には、LMA110は、バインディングキャッシュをチェックして、パケットのルーティングパスを調べる。ここでは、LMA110は、このパケットがMN11あてであることを特定し、バインディングキャッシュのエントリに基づいてMAG102にパケットをトンネルし、MAG102はMN11へパケットを転送する。
近年、ネットワークベースのモビリティ管理方式において、マルチインタフェースを有するモバイルノードからの同時アクセスのサポートに関する議論が行われてきた。ここでは主に、現在の携帯電子機器に複数のネットワークインタフェースが組み込まれることから、所定のホームアドレスに対して複数の気付アドレスを登録する機能を導入することに関して議論されてきた。以下、この技術を、モバイルノード/ルータが実現するマルチホーミング機能と呼ぶことにする。この議論の過程において、非特許文献2が改訂され、ローカルモビリティアンカがマルチホーミングをサポートするために考慮すべき問題に関して言及された。この改訂版は下記の非特許文献3として発行されている。
また、下記の非特許文献4には、複数の気付アドレスの登録を行うための方法が説明されている。この方法は、BID(Binding Unique Identification)と呼ばれる識別番号を使用して、あるホームアドレスに対して関連付けられている複数のバインディングの識別を行う。BIDは、モバイルノード/ルータのホームアドレスに関連付けられたインタフェース又は気付アドレスに割り当てられている。したがって、ホームアドレスは、モバイルノード/ルータ自体に関連付けられている一方、BIDは、モバイルノードによって登録された同時アクセスによる各バインディングを識別する。モバイルノードは、バインディングアップデート(BU)メッセージを使用して、ホームエージェントにBIDを通知し、ホームエージェントは、BIDをそのバインディングキャッシュに記録する。また、モバイルノード/ルータがプリファレンスをホームエージェントに設定し、複数の気付アドレスを通じたトラフィックフローの選択的なルーティングを行えるようにすることも可能である。
また、下記の非特許文献5には、非特許文献4の技術を用いてモバイルノードがマルチホーミングを行う際にローカルモビリティドメイン内で発生する問題に基づいて分析が行われている。ここでは、ローカルモビリティアンカにおいて何らかの機能が欠けており、ローカルモビリティドメインがマルチホーミングをサポートできない場合の問題が注目されており、非特許文献3及び非特許文献4の技術の統合が考察されている。
ここで、セルラのオペレータが非特許文献3及び非特許文献4の両方の技術をシステムに導入する場合を考える。第3世代パートナーシッププロジェクト(3GPP:Third Generation Partnership Project )から発展した第4世代(4G)移動通信技術が、セルラネットワークのオールIPシステム化を目指していることは想像に難くない。また同様に、オールIPシステムは、国際モバイルテレコミュニケーションズ−2000(IMT−2000:International Mobile Telecommunications-2000)プロジェクトの第3世代パートナーシッププロジェクト2(3GPP2)においても研究されている。これらのプロジェクトでは、ほとんどのセルラのオペレータが、モバイル通信の迅速性及び容易性を向上させる目的を達成するという条件を満たす候補として、非特許文献3で説明されている技術を考慮している。また、非特許文献3ではローカルモビリティドメインにおけるマルチホーミングのサポートに言及されているので、将来、セルラネットワークはマルチホーミングをサポートする可能性が高いと思われる。さらに、非特許文献3に開示されている技術は、こうしたシステム内でデータのロードバランシングを実行する手段を実現することが可能であり、セルラのオペレータがマルチホーミングをサポートできるという利点がある。
例えば、図1において、MN11のIF110及びIF111の両方のインタフェースが同時にローカルモビリティドメイン10に接続されているとする。ここでは、IF110はMAG102に接続されており、IF111はMAG103に接続されているとする。これらの接続は両方共、LMA101に登録される。LMA101は、MN11あてのパケットが届くと、ローカルモビリティドメイン10のネットワーク条件に基づいて、MAG102又はMAG103のどちらかを経由してMN11へパケットを転送するよう選択することが可能である。MAG102がパケット処理に関して過負荷である場合には、LMA101は、MN11あてのパケットをMAG102に送信する代わりに、MAG103経由で転送することが可能である。これにより、MAG102の処理負荷が低減されるようになる。このように、ローカルモビリティドメイン内でマルチホーミングをサポートする利点として、ローカルモビリティアンカによって負荷バランシングが実行できることが挙げられる。
セルラのオペレータがシステム内でマルチホーミングのサポートを行うよう設定した場合には、注意すべき点が生じるかもしれない。注意すべき点の1つは、マルチホーミングをサポートする際にローカルモビリティアンカが過負荷な状態にならないようにすることである。ローカルモビリティアンカは、ローカルモビリティドメイン内でパケット発送に関する主要装置として動作しており、モバイルノードへの複数のルーティングパスを同時に扱う場合には比較的簡単な構成とすることが望ましい。また、別の注意すべき点として、モバイルアクセスゲートウェイがマルチホーミングをサポートするための複雑な機能を使用する必要はないことが挙げられる。モバイルアクセスゲートウェイが、例えば非特許文献4に記載の技術に従って、マルチホーム状態のモバイルノードのサポートを行えるようにすることが望ましい。
IETF(Internet Engineering Task Force)における現在の作業では、ネットワークベースのモビリティ管理に関するマルチホーミングは、今後作業すべき事項と考えられている。ネットワークベースのモビリティ管理に関する基本プロトコルが完全に構築された場合に、この作業事項が調べられることになる。したがって、セルラのオペレータは、まず基本的なネットワークベースのモビリティ管理方式を配備して、その後、システムにマルチホーミングのサポートを統合する可能性が高い。セルラのオペレータは、この機能の統合に際してシステムを試行するので、最初、マルチホーム状態のモバイルノードをサポートするモバイルアクセスゲートウェイと、マルチホーム状態のモバイルノードをサポートしないモバイルアクセスゲートウェイとがシステムに混在することが予想される。さらに、マルチホーミング機能の利用に際して、各モバイルアクセスゲートウェイに関してライセンス料が徴収される場合には、オペレータは、いくつかのモバイルアクセスゲートウェイのみがマルチホーミング機能を有するようにすることで、維持費を最小限に抑えることが可能となる。
また、セルラのオペレータすべてが必ずしもシステム内でマルチホーミングのサポートを行うことを望んでいないこともあり得る。セルラのオペレータは、特定の地域に対する消費者市場に基づき、その消費者の大半がマルチホーミング機能を使用しないと判断した場合には、マルチホーミングサポートを配備しない可能性がある。このような環境で、特に、オペレータ間のローミング協定が存在する場合は、マルチホーム状態のモバイルノードが、マルチホーミングをサポートするモバイルアクセスゲートウェイ及びマルチホーミングをサポートしないモバイルアクセスゲートウェイに同時に接続することになる可能性がある。
米国特許公開2007/0254677
D. Johnson, C. Perkins and J. Arkko, "Mobility Support in IPv6", Internet Engineering Task Force Request For Comments 3775, June 2004. S. Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury and B. Patil, "Proxy Mobile IPv6", Internet Engineering Task Force Internet Draft: draft-ietf-netlmm-proxymip6-00.txt, April 08, 2007. S. Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury and B. Patil, "Proxy Mobile IPv6", Internet Engineering Task Force Internet Draft: draft-ietf-netlmm-proxymip6-07.txt, November 04, 2007. R. Wakikawa, T. Ernst and K. Nagami, "Multiple Care-of Addresses Registration", Internet Engineering Task Force Internet Draft: draft-ietf-monami6-multiplecoa-00.txt, June 12, 2006. M. Jeyatharan, C. Ng and J. Hirano, "Multiple Interfaced Mobile Nodes in NetLMM", Internet Engineering Task Force Internet Draft: draft-jeyatharan-netlmm-multi-interface-ps-00.txt, September, 2007.
上述のように、マルチホーム状態のモバイルノードが、マルチホーミングをサポートするモバイルアクセスゲートウェイ及びマルチホーミングをサポートしないモバイルアクセスゲートウェイに同時に接続する場合には、マルチホーム状態のモバイルノードに関するバインディングエントリがローカルモビリティアンカで失われてしまう可能性がある。バインディングエントリが無くなる理由は、非特許文献4に述べられているように、モビリティアンカポイント(例えばホームエージェント)がマルチホーム状態のモバイルノードに関する複数のバインディングエントリを保持しており、BIDを含まないバインディング登録を受信した場合には、保持しているすべてのバインディングエントリは消去するとともに新たに受信したBIDを含まないバインディング登録で置き換えてしまうことによる。また、モビリティアンカポイントがマルチホーム状態のモバイルノードに関してバインディングエントリを1つ維持しており、BIDを有するバインディング登録を受信した場合も同様に、保持していたバインディングエントリが、BIDを有する受信バインディング登録のバインディングエントリで置き換えられてしまうことになる。その結果、モバイルノードはマルチホーム状態を失うことになり、マルチホーム状態のモバイルノードに関するサービスエクスペリエンスの低減を引き起こすことになる。
以下、図1を参照しながら、この問題について説明する。図1において、ローカルモビリティドメイン10はマルチホーミングをサポートするエンティティを有している。LMA101は、マルチホーム状態のモバイルノードに関するバインディングの処理方法を把握している。また同様に、MAG102はマルチホーミングのサポート機能を有している。この場合、MAG102は非特許文献4に記載されている技術を実行する。一方、MAG103は、マルチホーミングのサポート機能を有していないとする。
IF110がMAG102に接続する場合、MAG102は、その接続を登録するために、BIDを有するPBUをLMA101へ送信する。この登録はバインディングエントリとしてLMA101に記録される。MN11は、ローカルモビリティドメイン10内で同時バインディングを実現しようとしており、IF111によってMAG103へ接続しようとする。これにより、MAG103は、この接続の登録を行うために、PBUをLMA101へ送信する。MAG103は、マルチホーミングのサポート機能を有していないのでMAG103からのPBUにはBIDは含まれていない。このBIDを含まないPBUの受信によって、LMA101は、MN11に関するすべてのバインディングを削除し、MAG103へのバインディングエントリ1つに置き換えてしまう。その結果、MN11は、LMA101からMAG102への有効なパスを失ってしまうことになる。
また、MAG102がPBUをLMA101へ再送する場合には同一のバインディングエントリの置き換え動作が行われ、LMA101は、MAG103へのバインディングエントリを削除し、MAG102へのバインディングエントリに置き換えてしまう。このような動作は、MN11がこのシステムにおいてマルチホーミングを実現できないことを意味する。
なお、こうした問題を解消するための解決方法の1つが、例えば、上記の特許文献1においても説明されている。特許文献1における方法は、モバイルノードとの通信に使用可能なプロキシノードのIPアドレスを記載したバインディングメッセージをモバイルノードからアンカポイントへ送信させるものである。特許文献1における方法では、モバイルノードがプロキシノードに関する情報をアンカポイントに直接通知するので、アンカポイントが異なるタイプのバインディング登録メッセージを受信する場合が少なくなる。すなわち、モバイルノードからアンカポイントへ通知を行えるようにすることで、プロキシノードがマルチホーミングをサポートしているか否かにかかわらず、プロキシノードを経由してマルチホーミング機能が継続されるようになる。
本発明は、従来のマルチホーミングにおける問題点を解決することを目的とする。本発明は、特に、ローカルモビリティドメイン内で移動する移動端末(モバイルノード)に対して、マルチホーミングをサポートし続けることを可能にする移動端末及びネットワークノードを提供することを目的とする。
上記の目的を達成するため、本発明の移動端末は、ネットワークベースのモビリティ管理を行うとともにマルチホーミングをサポートするローカルモビリティドメイン内で移動を行う移動端末であって、
複数の経路でパケットの送受信を行うことを可能とする、前記複数の経路のそれぞれに対応する複数の通信インタフェースと、
前記複数の通信インタフェースの少なくとも1つによって前記ローカルモビリティドメイン内の接続ポイントとして機能する接続ノードへ接続する場合、前記複数の通信インタフェースのうちの1つ又はすべてが接続する前記接続ノードがマルチホーミングの機能をサポートしているか否かを示す情報を、前記ローカルモビリティドメイン内のエンティティに対して通知する機能情報通知手段とを、
有する。
この構成により、ローカルモビリティドメイン内のエンティティ(ローカルモビリティアンカ)は、ローカルモビリティドメイン内で移動する移動端末(モバイルノード)に対してマルチホーミングをサポートし続けることが可能となる。
さらに、本発明の移動端末では、上記の移動端末に加えて、前記機能情報通知手段が、前記複数の通信インタフェースの少なくとも1つによってまもなく接続しようとしている前記接続ノードがマルチホーミングをサポートしていないことが把握できた場合、前記ローカルモビリティドメイン内のエンティティへ通知するよう構成されている。
この構成により、移動端末が接続しようとしている接続ノード(モバイルアクセスゲートウェイ)がマルチホーミングをサポートしていないことが把握できた場合、その旨をローカルモビリティドメイン内のエンティティへ通知することが可能となる。
さらに、本発明の移動端末では、上記の移動端末に加えて、前記機能情報通知手段が、前記複数の通信インタフェースの少なくとも1つによってまもなく接続しようとしている前記接続ノードへ接続するためのアクセス認証が確立していない場合、前記ローカルモビリティドメイン内のエンティティへ通知するよう構成されている。
この構成により、移動端末が接続しようとしている接続ノードとの間でアクセス認証が完了する前に、移動端末が接続しようとしている接続ノードがマルチホーミングをサポートしていない旨をローカルモビリティドメイン内のエンティティへ通知することが可能となる。
さらに、本発明の移動端末は、上記の移動端末に加えて、前記複数の通信インタフェースの少なくとも1つによってまもなく接続しようとしている前記接続ノードから、前記接続ノードがマルチホーミングをサポートしているか否かを示す情報を受信する機能情報受信手段を有する。
この構成により、例えば、接続ノードから受信するルータ通知メッセージに含まれている接続ノードの機能情報によって、接続ノードがマルチホーミングをサポートしているか否かを把握することが可能となる。
さらに、本発明の移動端末は、上記の移動端末に加えて、前記複数の通信インタフェースの少なくとも1つによってまもなく接続しようとしている前記接続ノードがマルチホーミングをサポートしているか否かを示す情報を、ファストモバイルIPを利用して取得する機能情報取得手段を有する。
この構成により、移動端末は、ファストモバイルIPを利用して、接続ノードがマルチホーミングをサポートしているか否かを把握することが可能となる。
さらに、本発明の移動端末では、上記の移動端末に加えて、前記機能情報通知手段が、前記複数の通信インタフェースの少なくとも1つによってまもなく接続しようとしている前記接続ノードがマルチホーミングをサポートしていないことが把握できた場合、前記ローカルモビリティドメインへ接続しているすべての通信インタフェースの接続に関する情報を、前記ローカルモビリティドメイン内のエンティティへ通知するよう構成されている。
この構成により、移動端末は、接続ノードにまもなく接続しようとしている通信インタフェースを除く、ローカルモビリティドメインへ接続しているすべての通信インタフェースの接続に関する情報を、ローカルモビリティドメイン内のエンティティへ通知することが可能となる。
さらに、本発明の移動端末では、上記の移動端末に加えて、前記機能情報通知手段が、前記複数の通信インタフェースの少なくとも1つによってまもなく接続しようとしている前記接続ノードへ接続するためのアクセス認証が確立している場合、前記ローカルモビリティドメイン内のエンティティへ通知するよう構成されている。
この構成により、移動端末が接続しようとしている接続ノードとの間でアクセス認証が完了した後に、消去されてしまった可能性のあるすべての通信インタフェースに関する接続情報をローカルモビリティドメイン内のエンティティへ通知することが可能となる。
さらに、本発明の移動端末は、上記の移動端末に加えて、前記複数の通信インタフェースのうちの1つ又はすべてが接続する前記接続ノードがマルチホーミングの機能をサポートしているか否かを示す情報に対する処理結果を示す確認メッセージを要求する確認要求手段を有する。
この構成により、移動端末は、ローカルモビリティドメイン内のエンティティにおいて正常な処理が行われたか否かを把握することが可能となる。
さらに、本発明の移動端末は、上記の移動端末に加えて、前記確認メッセージを受信できなかった場合には、前記ローカルモビリティドメイン内のエンティティに対して、前記移動端末の接続に関するルーティング情報の再構築を要求するルーティング再構築要求手段を有する。
この構成により、移動端末は、ローカルモビリティドメイン内のエンティティにおいて正常な処理が行われなかったと判断した場合に、移動端末の接続に関するルーティング情報の再構築を要求することが可能となる。
さらに、本発明の移動端末は、上記の移動端末に加えて、前記ローカルモビリティドメイン内のエンティティから、前記移動端末のマルチホーム状態が失われた旨の通知を受信した場合、前記移動端末のマルチホーム状態を再構成するための情報を前記ローカルモビリティドメイン内のエンティティへ通知する再構成手段を有する。
この構成により、移動端末は、所望のマルチホーム状態を構成することが可能となる。
さらに、本発明の移動端末は、上記の移動端末に加えて、前記ローカルモビリティドメイン内のエンティティにおけるルーティングエントリが削除されたと判断できる場合、削除されたと判断された前記ルーティングエントリの復元を要求する復元要求手段を有する。
この構成により、移動端末は、ルーティングエントリの復元を要求することで、ローカルモビリティドメイン内のエンティティに登録したいルーティングエントリを迅速に登録(復元)することが可能となる。
さらに、本発明の移動端末は、上記の移動端末に加えて、前記復元要求手段が、前記移動端末が接続しているマルチホーミングをサポートしている前記接続ノードに対して、前記ルーティングエントリを再構築させるための登録メッセージの再送を依頼するよう構成されている。
この構成により、移動端末は、マルチホーミングをサポートしている接続ノードに登録メッセージを再送させることで、ローカルモビリティドメイン内のエンティティに登録したいルーティングエントリを迅速に登録(復元)することが可能となる。
さらに、本発明の移動端末は、上記の移動端末に加えて、前記復元要求手段が、前記移動端末が接続している前記接続ノードの中から、前記登録メッセージの再送を依頼する前記接続ノードを選択するよう構成されている。
この構成により、移動端末は、所望の接続ノード(例えば、マルチホーミングをサポートしていることが分かっている接続ノード)を確実に選択して、ローカルモビリティドメイン内のエンティティに登録したいルーティングエントリを迅速に登録(復元)することが可能となる。
さらに、本発明の移動端末は、上記の移動端末に加えて、前記ローカルモビリティドメイン内の前記接続ノードがマルチホーミングの機能をサポートしているか否かを示す情報を収集し、リスト情報として格納する情報収集格納手段を有する。
この構成により、リスト情報を用いて検索手順を効率化することが可能となる。
さらに、本発明の移動端末は、上記の移動端末に加えて、前記機能情報通知手段が、前記複数の通信インタフェースの少なくとも1つによってまもなく接続しようとしている前記接続ノードがマルチホーミングをサポートしていないことが把握できた場合、まもなく接続しようとしている前記接続ノードへの接続によって置き換えられる対象のバインディングを示す情報を通知するバインディング特定情報通知手段を有する。
この構成により、ローカルモビリティドメイン内のエンティティにおいて、更新対象のバインディング情報を正しく特定できるようにすることが可能となる。
さらに、本発明の移動端末は、上記の移動端末に加えて、まもなく接続しようとしている前記接続ノードへの接続によって置き換えられる対象のバインディングを示す情報に、置き換えられる対象のバインディングに関連する通信インタフェースを識別する固有の識別情報が含まれている。
この構成により、ローカルモビリティドメイン内のエンティティにおいて、移動端末のインタフェースの識別情報に基づいて、更新対象のバインディング情報を正しく特定できるようにすることが可能となる。
また、上記の目的を達成するため、本発明のネットワークノードは、ローカルモビリティドメインにおいて、ネットワークベースのモビリティ管理を行うとともに、前記ローカルモビリティドメインに接続する移動端末のマルチホーミングをサポートする前記ローカルモビリティドメイン内のネットワークノードであって、
前記移動端末の通信インタフェースが前記ローカルモビリティドメイン内の接続ポイントとして機能する接続ノードへ接続する場合、前記通信インタフェースと前記接続ノードとの対応をルーティング情報として保持するルーティングキャッシュと、
前記移動端末が保持する複数の通信インタフェースのうちの1つ又はすべてが接続する前記接続ノードがマルチホーミングの機能をサポートしているか否かを示す情報を受信する機能情報受信手段と、
前記機能情報受信手段で受信した前記接続ノードがマルチホーミングの機能をサポートしているか否かを示す情報に基づいて、前記移動端末に関するルーティング情報の更新を行うルーティング更新手段とを、
有する。
この構成により、ローカルモビリティドメイン内のエンティティ(ローカルモビリティアンカ)は、ローカルモビリティドメイン内で移動する移動端末(モバイルノード)に対してマルチホーミングをサポートし続けることが可能となる。
さらに、本発明のネットワークノードは、上記のネットワークノードに加えて、前記機能情報受信手段が前記複数の通信インタフェースの少なくとも1つによってまもなく接続しようとしている前記接続ノードがマルチホーミングをサポートしていない旨を前記移動端末から受信した場合、通知を受けた前記接続ノードとまもなく接続しようとしている前記通信インタフェースとの対応を識別する固有の識別情報を準備する識別情報準備手段と、
通知を受けた前記接続ノードとまもなく接続しようとしている前記通信インタフェースとの対応を示す情報を受信した場合に、前記通信インタフェースと前記接続ノードとの対応を示すルーティング情報に前記固有の識別情報を付加して前記ルーティングキャッシュに格納させるルーティング情報管理手段とを、
有する。
この構成により、ローカルモビリティドメイン内のエンティティは、移動端末が接続しようとしている接続ノードがマルチホーミングをサポートしていない旨を把握し、その接続に関するルーティング情報の登録を行うために、その接続に対応する固有の識別情報を割り当てる準備を行うことが可能となる。
さらに、本発明のネットワークノードは、上記のネットワークノードに加えて、前記機能情報受信手段が前記ローカルモビリティドメインへ接続しているすべての通信インタフェースの接続に関する情報を前記移動端末から受信した場合、前記ローカルモビリティドメインへ接続しているすべての通信インタフェースの接続に関する情報に基づき、前記ローカルモビリティドメインへ接続しているすべての通信インタフェースの接続に対応するルーティング情報を前記ルーティングキャッシュに追加するルーティングキャッシュ更新手段を有する。
この構成により、移動端末がマルチホーミングをサポートしていない接続ノードと接続したことによって、ローカルモビリティドメイン内のエンティティが消去してしまった可能性のあるすべての通信インタフェースに関する接続情報をルーティング情報として登録することが可能となる。
さらに、本発明のネットワークノードは、上記のネットワークノードに加えて、前記複数の通信インタフェースのうちの1つ又はすべてが接続する前記接続ノードがマルチホーミングの機能をサポートしているか否かを示す情報に対する処理結果を示す確認メッセージを前記移動端末へ送信する確認送信手段を有する。
この構成により、ローカルモビリティドメイン内のエンティティは、移動端末から受信した情報に対して正常な処理を行うことができたか否かを移動端末へ通知することが可能となる。
さらに、本発明のネットワークノードは、上記のネットワークノードに加えて、前記移動端末に関するルーティング情報を前記ルーティングキャッシュから消去するとともに、前記移動端末のマルチホーム状態が失われた旨を前記移動端末へ通知するルーティング情報消去通知手段を有する。
この構成により、ローカルモビリティドメイン内のエンティティは、移動端末に所望のマルチホーム状態を改めて構成させることが可能となる。
さらに、本発明のネットワークノードは、上記のネットワークノードに加えて、前記移動端末に関するルーティング情報を消去する場合に、消去対象のルーティング情報に係るルーティングを無効にするとともに一定期間消去を保留し、前記消去対象のルーティング情報に関する復元要求を前記一定期間内に前記移動端末から受信した場合には前記消去対象のルーティング情報を有効にし、前記消去対象のルーティング情報に関する復元要求を前記一定期間内に前記移動端末から受信しなかった場合には前記一定期間経過後に前記消去対象のルーティング情報を完全に削除するルーティング情報消去手段を有する。
この構成により、ローカルモビリティドメイン内のエンティティは、ルーティングエントリの復元の要求を移動端末から受信した場合に、移動端末が所望するルーティングエントリを迅速に登録(復元)することが可能となる。
さらに、本発明のネットワークノードは、上記のネットワークノードに加えて、前記機能情報受信手段が、前記複数の通信インタフェースの少なくとも1つによってまもなく接続しようとしている前記接続ノードへの接続によって置き換えられる対象のバインディングを示す情報を前記移動端末から受信した場合、前記ルーティング更新手段が、前記置き換えられる対象のバインディングを示す情報によって特定されるバインディングを、まもなく接続しようとしている前記接続ノードに関するバインディングに置き換えるよう構成されている。
この構成により、ローカルモビリティドメイン内のエンティティは、更新対象のバインディング情報を正しく特定できるようにすることが可能となる。
本発明は、上記の構成により、従来のマルチホーミングにおける問題点を改善できるという効果を有する。本発明は、上記の構成により、特に、ローカルモビリティドメイン内で移動する移動端末(モバイルノード)に対してマルチホーミングをサポートし続けることを可能にするという効果を有する。
本発明の実施の形態及び従来の技術におけるネットワークベースのモビリティ管理に用いられる通信システムの一例を示す図 本発明の好適な実施の形態におけるルータ機能メッセージのフォーマットの一例を示す図 本発明の好適な実施の形態において、受信した機能情報に基づいてモバイルノードが行う動作の一例を示すフローチャート 本発明の好適な実施の形態において、ローカルモビリティドメイン内のエンティティに通知するために用いられる接続メッセージのフォーマットの一例を示す図 本発明の好適な実施の形態において、ローカルモビリティアンカによって行われる処理の一例を示すフローチャート 本発明の好適な実施の形態における再関連付けメッセージのフォーマットの一例を示す図 本発明の好適な実施の形態において、リカバリ動作をサポートするルーティングキャッシュの一例を示す図 本発明の好適な実施の形態におけるモバイルノードの機能アーキテクチャの一例を示すブロック図
以下、図面を参照しながら、本発明の実施の形態について説明する。なお、以下の説明では、本発明を説明するために、特定の番号や時間、構造、プロトコル名、及びその他のパラメータなどが詳細に説明される場合があるが、本明細書で用いられている特定の条件は、本発明を説明するために用いられているに過ぎず、本発明を限定するものではない。例えば、本発明を明瞭に示すために、周知の構成要素及びモジュールはブロックダイアグラムで表される。
本発明の実施の形態では、マルチホーム状態のモバイルノード(multi-homed mobile node)がローカルモビリティアンカに対して、ローカルモビリティドメインでマルチホーミングをサポートするための情報を提供できるようにする方法について説明する。この方法をサポートするため、モバイルノードは、まず、モバイルノードが接続しようとしているモバイルアクセスゲートウェイの機能(capability)を判断する必要がある。モバイルノードは、モバイルアクセスゲートウェイがマルチホーミングをサポートしていないことを把握できた場合には、これをトリガとして、まもなく行おうとしている接続に関する情報をローカルモビリティアンカへ提供する。ローカルモビリティアンカは、この提供された情報を用いることで、たとえモバイルアクセスゲートウェイにマルチホーミングのサポート機能が備わっていない場合であっても、モバイルノードへのマルチホーミングのサポートを維持することが可能となる。
モバイルノードが判断処理を実行することによって、モバイルノードは、ローカルモビリティドメインにおけるモバイルノードのマルチホーミングのサポートを維持するためにローカルモビリティアンカへ情報を伝える必要があるかどうかを判断することが可能となる。
また、本発明において、モバイルノードに関するマルチホーミングをサポートする機能をモバイルアクセスゲートウェイが実行可能かどうかをモバイルノードが把握するための好適な方法としては、例えば、モバイルアクセスゲートウェイがモバイルノードに対してその機能を保持していることを通知する方法が可能である。この方法を実現可能とするやり方の1つとして、モバイルアクセスゲートウェイがIEEE(Institute of Electrical and Electronics Engineers)802.11で記述されているビーコン送信方法を利用する方法が挙げられる。また、この方法を実現可能とする別のやり方としては、モバイルアクセスゲートウェイがIETF(Internet Engineering Task Force)で記述されているルータ通知送信方法を利用する方法が挙げられる。また、3Gネットワークでは各無線アクセス技術における(レイヤ2技術に相当する)報知情報を利用することもできる。
図2には、本発明の好適な実施の形態におけるルータ機能メッセージ(router capability message)のフォーマットの一例が図示されている。図2において、ルータ機能メッセージ20は、パケットヘッダ200、ルータID(ルータ識別子)201、ルータ機能フィールド202を有している。
パケットヘッダ200は、メッセージの送信元(ルータ機能メッセージの送信者)やあて先に関する情報を伝送するためのフィールドである。パケットヘッダ200には、例えば、送信元やあて先のIPv4アドレス又はIPv6アドレス、メッセージタイプを示すタイプフィールド、メッセージの長さを示す長さフィールドなどが含まれている。
また、ルータID201は、そのルータの機能を通知するルータ識別情報を提供するためのフィールドである。なお、ルータID201は、モバイルアクセスゲートウェイのMACアドレスや、ローカルモビリティドメインのサービスプロバイダによって設定されたモバイルアクセスゲートウェイ固有の名前などを用いて形成されることが望ましい。
また、ルータ機能フィールド202は、モバイルアクセスゲートウェイの特徴(機能情報)を伝送するためのフィールドである。なお、本発明の実施の形態では、ルータ機能フィールド202は、モバイルアクセスゲートウェイがマルチホーミングのサポートを行えること(すなわち、マルチホーミングのサポート機能を有しており、かつ、その機能が実行可能であること)をモバイルノードに知らせるためのフラグ(ここでは、“M”フラグと記載する)2020を有している。
“M”フラグ2020は、例えば、1ビットの2進数の値によって実現可能である。例えば、“1”の値は、モバイルアクセスゲートウェイがマルチホーミングのサポート機能を備えていることを示しており、逆に、“0”の値は、モバイルアクセスゲートウェイがマルチホーミングのサポート機能を備えていないこと(あるいは、マルチホーミングのサポート機能を備えているとしても、その機能を実行できないこと)を示している。
なお、例えば、“M”フラグ2020のデフォルト値は“0”に設定されることが好ましい。これにより、マルチホーミングのサポートが可能なモバイルアクセスゲートウェイだけが、“M”フラグ2020の値を“1”の値に変えればよい。その結果、マルチホーミングのサポート機能を保持していないモバイルアクセスゲートウェイの機能を変更する必要が少なくなり、レガシノードであっても本発明に係るシステムで動作可能となる。なお、この値の設定は、レガシノードが未使用領域として“M”フラグ2020の値に相当する部分を“0”と設定していることを前提としている。
以下、ルータ機能メッセージ20の使用方法の簡単な一例について説明する。図1において、ローカルモビリティドメイン10では、MAG102はマルチホーミングプロトコルを実装している。したがって、MAG102は、“1”の値(マルチホーミングのサポートを行っていることを示す値)にセットされた“M”フラグ2020を有するルータ機能メッセージ20を用いた通知を行う。このルータ機能メッセージ20を受信することによって、MN11は、MAG102がマルチホーミングのサポートを行っていることを把握する。
一方、図1において、MAG103はマルチホーミングプロトコルを実装していないとする。したがって、MAG103は、“0”の値にセットされた“M”フラグ2020を有するルータ機能メッセージ20を用いた通知を行う。このルータ機能メッセージ20を受信することによって、MN11は、MAG103がマルチホーミングのサポートを行っていないことを把握する。
また、モバイルアクセスゲートウェイがマルチホーミングのサポートを行っているかどうかをモバイルノードが把握できるようにするための別の好適な方法として、IEEE802.21の情報サービス(IS:Information Service)に関する手法を用いるやり方が挙げられる。この手法では、モバイルノードは、モバイルアクセスゲートウェイの機能に関して、ISサーバへ問い合わせを行う。ISサーバは、モバイルノードからの問い合わせに対する応答を行う。
以下、IEEE802.21の情報サービスを用いる方法の一例について説明する。図1において、ローカルモビリティドメイン10は、ローカルモビリティドメイン10内に存在するすべてのモバイルアクセスゲートウェイ(MAG102〜104)の機能に関する情報を格納しているISサーバ(図1には不図示)を更に有している。MN11は、MAG103とIF111で接続を行う前に、MAG103がMN11に対してマルチホーミングのサポートを行えるかどうかを問い合わせるISクエリメッセージをISサーバへ送信する。ここで、ISサーバのデータベースにおいて、MAG103がマルチホーミングプロトコルを実装していないと判断されたとする。このとき、ISサーバは、MAG103がマルチホーミングのサポートを行うことができない旨を示す応答をモバイルノードへ行う。
モバイルノードは、モバイルアクセスゲートウェイの機能に関する情報(以下、機能情報と記載する)を受信すると、この受信した機能情報を解析し、この解析結果に基づく動作を行う。図3には、本発明の好適な実施の形態において、受信した機能情報に基づいてモバイルノードが行う動作の一例を示すフローチャートが図示されている。
図3において、モバイルノードは、モバイルアクセスゲートウェイの機能情報を受信すると、その機能情報から、モバイルアクセスゲートウェイがマルチホーミングをサポートしているか否かを特定する(ステップS31)。モバイルアクセスゲートウェイがマルチホーミングをサポートしている場合には、処理は終了となる。この場合、モバイルノードはこれ以上特別な処理を行うことなく、モバイルアクセスゲートウェイとの間でのアクセス認証処理を行うことが可能となる。
一方、モバイルアクセスゲートウェイがマルチホーミングをサポートしていない場合には、モバイルノードは、ローカルモビリティドメインにおけるマルチホーミングを維持するために、ローカルモビリティドメイン内のエンティティに通知を行う必要がある。このエンティティは、例えば、ローカルモビリティアンカであってもよく、モバイルアクセスゲートウェイであってもよい。
モバイルノードがマルチホーミングを維持するためにローカルモビリティドメイン内のエンティティへ通知を行う場合、例えば下記のように、2つのモードのうちのいずれかを採用することが可能である。なお、それぞれのモード(モード1及びモード2)において、モバイルノードは異なるタイプの情報を送信する。
モバイルノードの動作モードがモード1の場合(ステップS32で『モード1』)には、モバイルノードは、ローカルモビリティドメイン内のエンティティに対して、そのモバイルノードがマルチホーミングをサポートしていないモバイルアクセスゲートウェイに接続しようとしている旨を通知する(ステップS33)。その結果、この通知を受けたエンティティは、ローカルモビリティドメインにおいてモバイルノードのマルチホーミングを中断しないようにするための更なるステップを行うことが可能となる。
この方法は、モバイルノードがモバイルアクセスゲートウェイの機能を事前に検出することができる場合に特に有用である。モバイルノードは、この情報に基づいて、マルチホーミングの機能を有していないモバイルアクセスゲートウェイからバインディング登録メッセージが送信されることを事前に把握することが可能となる。なお、モバイルアクセスゲートウェイの機能を事前に検出できるように方法として、例えば、IETFで構築されたファストモバイルIP(Fast Mobile IP)を利用する方法を用いることも可能である。
また、モバイルノードの動作モードがモード2の場合(ステップS32で『モード2』)には、モバイルノードは、ローカルモビリティドメイン内のエンティティに対して、ローカルモビリティドメインでの現在の接続に関する情報を通知する(ステップS34)。この情報の通知を受けたローカルモビリティドメイン内のエンティティは、モバイルノードのルーティングキャッシュを再構築し、マルチホーミングのサービスをモバイルノードへ提供し続けることが可能となる。
この方法は、マルチホーミングの機能を有していないモバイルアクセスゲートウェイがバインディング登録メッセージを送信するよりも前に、モバイルノードがエンティティに通知を行うことができない場合に特に有用である。なお、このような場合が起こり得る状況としては、例えば、モバイルノードのインタフェースが、あるモバイルアクセスゲートウェイから、マルチホーミングをサポートしていない別のモバイルアクセスゲートウェイにハンドオフするシナリオが考えられる。
上述の両方のモード(モード1及びモード2)共、モバイルノードはローカルモビリティドメイン内のエンティティに対して通知を行った後、処理は終了となる。なお、モバイルノードは、この通知を行うためのメッセージ(後述の接続メッセージ40)に、確認メッセージ(AcK)をリクエストする旨を示す情報を挿入してもよい。
次に、上述のフローチャートに示す方法について、図1を参照しながら、より詳細に説明する。図1において、MAG102はマルチホーミングプロトコルを実装しているが、MAG103はマルチホーミングプロトコルを実装していないとする。また、MN11はIF110をMAG102に接続しており、LMA101は、MAG102経由で受信したMN11のバインディングを保持しているとする。このバインディングは、バインディングに固有の識別情報(BID1)で識別される。
このとき、MN11は、同時アクセスによってMAG103へIF111を接続しようとしている場合には、マルチホーミングのサポートに関連するMAG103の情報(MAG103の機能情報)を取得する。
MN11がMAG103との間でアクセス認証を確立する前にこの機能情報(MAG103がマルチホーミングをサポートしていない旨を示す情報)を取得した場合には、MN11は、MAG103への接続が行われようとしている旨を通知するためのメッセージをLMA101へ送信する。なお、このメッセージは、MN11からLMA101に直接送信されてもよく、あるいは、MN11からMAGやその他の任意のエンティティに渡されてからLMA101に到達してもよい。また、このメッセージはMAG102を通じて送信されてもよく、MAG103によって送信されるバインディング登録メッセージに挿入(ピギーバック)されてもよい。
一方、MN11がMAG103との間でアクセス認証を確立した後にこの情報(MAG103がマルチホーミングをサポートしていない旨を示す情報)を取得した場合には、MN11は、MAG102との接続を更に通知する同様のメッセージをLMA101へ送信する。この場合も同様に、MAG102又はMAG103経由でメッセージの送信が可能である。
このようにしてMN11から通知された情報をLMA101が参照することで、MN11がローカルモビリティドメイン10においてマルチホーミングのサービスを確実に受け続けることができるようになる。
以下、いくつかの実施例を挙げて、マルチホーミングを維持するためにモバイルノードからローカルモビリティドメイン内のエンティティに送信されるメッセージ(以下、接続メッセージと記載する)の詳細について説明する。なお、この接続メッセージは、モバイルノードから1つ又は複数のモバイルアクセスゲートウェイ(マルチホーミングサポートを有していてもよく、あるいは有していなくてもよい)を経由して送信可能である。
図4には、本発明の好適な実施の形態において、ローカルモビリティドメイン内のエンティティに通知するために用いられる接続メッセージのフォーマットが示されている。接続メッセージ40は、パケットヘッダ400、モバイルノード識別情報(MN−ID)401、接続ステータスフィールド402を有している。
パケットヘッダ400は、メッセージの送信元(接続メッセージの送信者)やあて先に関する情報を伝送するためのフィールドである。パケットヘッダ400には、例えば、送信元やあて先のIPv4アドレス又はIPv6アドレス、メッセージタイプを示すタイプフィールド、メッセージの長さを示す長さフィールドなどが含まれている。
またMN−ID401は、モバイルノードの識別情報を提供するためのフィールドである。この識別情報によって、ローカルモビリティドメイン内のエンティティは、この接続メッセージ40が適用されるモバイルノードの接続ステータスを識別することが可能となる。
また、接続ステータスフィールド402は、モバイルノードが現在どのモバイルアクセスゲートウェイに接続しているかを示す情報(あるいは、モバイルノードがどのモバイルアクセスゲートウェイに接続しようとしているかを示す情報)を、ローカルモビリティドメイン内のエンティティへ通知するためのフィールドである。なお、接続ステータスフィールド402には、例えば1つ又は複数のルータID(ルータ識別情報)4020が含まれており、このルータID4020によって、どのモバイルアクセスゲートウェイが対象とされているかを接続メッセージ40の受信者が把握できるようにすることが望ましい。
また、各ルータID4020は、そのルータID4020によって特定されるモバイルアクセスゲートウェイがマルチホーミングをサポートすることが可能か否かを接続メッセージの受信者40が識別できるようにするための“M”フラグ4021と関連付けられていることが望ましい。“M”フラグ4021は、1ビットの値によって実現可能である。“1”の値の“M”フラグ4021は、ルータID4020によって特定されるモバイルアクセスゲートウェイがマルチホーミングをサポートしていることを示している。逆に、“0”の値の“M”フラグ4021は、モバイルアクセスゲートウェイがマルチホーミングをサポートしていないことを示している。
以下、本発明の好適な実施の形態(モード1の場合)における接続メッセージ40の具体的な使用方法について説明する。図1において、MAG102はマルチホーミングプロトコルを実装しているが、MAG103はマルチホーミングプロトコルを実装していないとする。また、MN11はIF110をMAG102に接続しており、LMA101は、MAG102経由で受信したMN11のルーティングエントリを保持しているとする。このルーティングエントリは、バインディングに固有の識別情報(BID1)で識別される。LMAもまた一種のルータであり、バインディング登録によりバインディングエントリ(単にバインディングと呼ぶこともある)を生成する。LMAがパケットをルーティングする際にはルーティングエントリを参照し、パケットを送信するが、そのルーティングエントリの1つとしてバインディングエントリを参照することが可能である。なお、ルーティングエントリは、その他のルーティングプロトコルによっても生成されるため、同様の仕組みとして、バインディングエントリからルーティングエントリを明示的に生成することも可能である。本明細書においては、バインディング登録に基づくものをバインディングエントリ、ルーティングの際に参照する場合にはルーティングエントリとして説明する場合があるが、上述のように、実施の上での区別は当業者の任意の実装に依存するものであり、バインディングエントリとルーティングエントリの読み替えや、バインディングエントリからルーティングエントリの生成を前提とすることができる。
このとき、MN11は、同時アクセスによってMAG103へIF111を接続しようとしている場合には、マルチホーミングのサポートに関連するMAG103の情報(MAG103の機能情報)を取得する。
ここで、MN11がMAG103との間でアクセス認証を確立する前にこの機能情報(MAG103がマルチホーミングをサポートしていない旨を示す情報)を含むIEEE802.11ビーコンを受信したとする。この場合には、MN11は、MAG103がMNのプレフィックスとMAG103の気付アドレスとを関連付けるPBUを送信する前に、まもなく行おうとしているMAG103への接続に関する情報をLMA101に通知する旨を決定する。そして、MN11は、MAG103の識別情報を示すルータID4020、及び、“0”の値にセットされた“M”フラグ4021を有する接続ステータスフィールド402を含む接続メッセージ40をLMA101へ送信する。この結果、LMA101は、マルチホーミングをサポートしていないMAG103にMN11が接続しようとしている旨を把握し、ローカルモビリティドメインにおいてMN11のマルチホーミングを中断しないようにするための更なるステップを行うことが可能となる。
また、以下では、本発明の別の実施の形態(モード2の場合)における接続メッセージ40を使用する方法について説明する。図1において、MAG102はマルチホーミングプロトコルを実装しているが、MAG103はマルチホーミングプロトコルを実装していないとする。また、MN11はIF110をMAG102に接続しており、LMA101は、MAG102経由で受信したMN11のルーティングエントリを保持しているとする。このルーティングエントリ(バインディング)は、バインディングに固有の識別情報(BID1)で識別される。
MN11は、IF111をMAG130に接続して同時アクセスを行おうとしている場合に、マルチホーミングのサポートに関連するMAG103の情報を取得する。MAG103とのアクセス認証を完了した後、MN11は、MAG103がマルチホーミングのサポート機能を有していない旨を示すルータ通知を受信したとする。この場合、MN11は、ローカルモビリティドメイン10へのすべての接続に関する情報をLMA101へ通知する旨を決定する。この決定に従って、MN11は、“1”の値がセットされた“M”フラグ4021及びMAG102の識別情報を示すルータID4020と、“0”の値がセットされた“M”フラグ4021及びMAG103の識別情報を示すルータID4020とを有する接続ステータスフィールド402を含む接続メッセージ40をLMA101へ送信する。これにより、LMA101は、MN11のルーティングキャッシュを更新し、MN11がローカルモビリティドメイン10内でマルチホーミングの利益を確実に受け続けられるようにすることが可能となる。
なお、上述した両方の例(モード1及びモード2の両方の例)において、モバイルノードから送信された接続メッセージ40は、モバイルアクセスゲートウェイによってローカルモビリティアンカへ中継される。これにより、モバイルノードは、ローカルモビリティアンカのIPアドレスを探索する必要はなくなり、モバイルノードの限られたバッテリ寿命を保つことが可能となる。
さらに、現在のモバイルアクセスゲートウェイとの接続やまもなく行われるモバイルアクセスゲートウェイとの接続を経由して接続メッセージ40を伝送すべきか否かを、モバイルノードが選択することが可能である。各モバイルアクセスゲートウェイはモバイルノードから受信したパケットをローカルモビリティアンカへ転送するので、ローカルモビリティアンカは、現在のモバイルアクセスゲートウェイとの接続やまもなく行われるモバイルアクセスゲートウェイとの接続のどちらかを利用して接続メッセージ40を受信することが可能である。
まもなく行われるモバイルアクセスゲートウェイとの接続を経由して接続メッセージ40を送信した場合には、この接続メッセージ40が最小の遅延で確実にローカルモビリティアンカに届くという利点がある。なお、まもなく接続しようとしているモバイルアクセスゲートウェイがマルチホーミングをサポートしていない場合には、このモバイルアクセスゲートウェイから送信されるPBUは、モバイルノードがモバイルアクセスゲートウェイの機能を把握する前に、ローカルモビリティアンカに届いてしまう可能性がある。その結果、モバイルノードのすべてのアクティブな接続に関する情報が、ローカルモビリティアンカから削除されてしまう可能性がある。したがって、ローカルモビリティアンカは、こうしたモバイルアクセスゲートウェイからモバイルノードに関連するデータを受信することを予想していないので、モバイルアクセスゲートウェイから受信するモバイルノードに関連するパケットは、ローカルモビリティアンカにおいて廃棄されてしまう可能性がある。
また、モバイルノードがローカルモビリティアンカとの間のアクティブな接続を切断した場合に、ローカルモビリティアンカがバインディング取り消しメッセージを、対応するモバイルアクセスゲートウェイへ送信してしまう可能性もある。これは、事実上、モバイルノードのデータをローカルモビリティアンカへプロキシしないようにモバイルアクセスゲートウェイへ指示するものであり、モバイルノードからモバイルアクセスゲートウェイへ送信される接続メッセージ40が廃棄されてしまうことになりかねない。このような場合でも、マルチホーミングをサポートしているローカルモビリティアンカや、現在接続を維持できているローカルモビリティアンカを、接続メッセージを送信する経由先として優先的に選択することで、状況が改善される可能性がある。
なお、当業者であれば、上述の説明によって、モバイルノードがマルチホーミングの動作を維持できるようになる方法(本発明に係る方法)が、特許文献1に説明されている方法とは異なることが理解できるであろう。特許文献1に開示されている従来の技術では、モバイルノードが、プロキシノードのIPアドレスを示すメッセージをアンカポイント(anchoring point)へ送信するようトリガされる。これによって、アンカポイント(anchoring point)は、モバイルノードとの接続を維持し続けることが可能となる。
また、同様に、トリガを行ってアンカポイントをアップデートする方法に関しては、非特許文献1や非特許文献4にも開示されている。これらの非特許文献1及び非特許文献4の両方における技術では、モバイルノードは、IPアドレスを変更した場合は常にアンカポイントを更新するようトリガされる。また、非特許文献4では、モバイルノードによって使用されている各IPアドレスを識別することが可能となる識別情報が、アンカポイントへ送信されるメッセージに含まれている。
上述の従来の技術及び本発明は共に、新しい接続ポイントに関する情報をアンカポイントにアップデートする動作をモバイルノードに行わせるという点においては同じ概念を用いている。しかしながら、本発明では、アンカポイントへのメッセージには、プロキシノードの機能に関連する情報が更に含まれている。この情報を用いることで、アンカポイントは、モバイルノードとの接続を維持できるようになる。また、本発明は、この情報をより適切なプロキシノードを経由して送信できるようしており、情報を通知する効率、安定性が向上する。以上のように、本発明と従来の技術とは大きく異なっている。
上述においては、本発明によって、モバイルノードがモバイルアクセスゲートウェイの機能に関する情報をローカルモビリティアンカへ送信するようトリガされることによって、ローカルモビリティドメインでのマルチホーミング機能が維持される方法について説明した。モバイルアクセスゲートウェイの機能に関する情報がローカルモビリティアンカに到達した場合には、ローカルモビリティアンカが行うべき次の動作方針を決定するために、この情報の処理が行われる必要がある。
以下、図5に図示されているフローチャートを参照しながら、本発明の実施の形態において、ローカルモビリティアンカによって行われる処理の一例について説明する。ローカルモビリティアンカが接続メッセージ40を受信した場合に、図5の処理が開始される。ローカルモビリティアンカは、処理を開始すると、まず、接続メッセージ40内に含まれている情報のタイプ(モバイルノードの動作モード)を判断する(ステップS51)。
例えば、この情報が、モバイルアクセスゲートウェイがマルチホーミング機能をサポートしていないことを示す情報である場合(上述の図3のステップS33において、モバイルノードの動作モードが、マルチホーミングをサポートしていないモバイルアクセスゲートウェイに接続しようとしている旨を通知するモード1の場合)には、ローカルモビリティアンカは、まもなく行われるモバイルノードとの接続を注目して、この登録を行うためのユニークなバインディング識別子(BID)を準備する(ステップS52)。
一方、例えば、この情報が、モバイルノードが接続されているすべてのモバイルアクセスゲートウェイに関する情報である場合(上述の図3のステップS34において、モバイルノードの動作モードが、MAGとの現在の接続に関する情報を通知するモード2の場合)には、ローカルモビリティアンカは、通知されたこの情報を用いて、モバイルノードのルーティングを定めるバインディングキャッシュエントリ(BCE:Binding Cache Entry)を更新する(ステップS53)。
ステップS52又はステップS53における情報処理が行われた後、ローカルモビリティアンカは、モバイルノードに対して確認メッセージ(Ack)が送信されるべきか否かのチェックを行う(ステップS54)。なお、この確認メッセージのリクエストは、例えば、モバイルノードによって接続メッセージ40内に挿入されてもよい。また、モバイルノードが確認メッセージのリクエストを行っていない場合であっても、ローカルモビリティアンカは、この確認メッセージをモバイルノードへ返してもよい。確認メッセージの送信が必要な場合(例えば、接続メッセージ40に確認メッセージの送信リクエストが挿入されている場合)には、ローカルモビリティアンカは、確認メッセージをモバイルノードへ送信する(ステップS55)。一方、確認メッセージの送信が必要ではない場合には、そのまま何もせずに処理は終了となる。
以下、より詳細に上述の方法を示す例について説明する。図1において、MAG102は、マルチホーミングプロトコルを実装しており、MAG103は、マルチホーミングプロトコルを実装していないとする。LMA101がMN11から接続メッセージ40を受信した場合、LMA101は、接続ステータスフィールド402をチェックして、どんなタイプの情報がメッセージに挿入されているかを判断する。
LMA101が受信した接続メッセージ40に、例えば“0”の値にセットされた“M”フラグ4021と共にMAG103の識別子を示すルータID4020が接続ステータスフィールド402に含まれているとする。この場合、LMA101は、後にMN11に関するPBUをMAG103から受信することになる旨を把握する。したがって、LMA101は、このPBUに関連して、このエントリに関するユニークなバインディング識別子(BID)を準備する。MAG103から送信されたPBUがLMA101に到着すると、MN11のルーティングキャッシュに、準備しておいたBIDを含むエントリが付加される。この結果、LMA101は、ローカルモビリティドメイン10におけるMN11のマルチホーミングをサポートし続けることが可能となる。
一方、LMA101が受信した接続メッセージ40に、例えば“1”の値にセットされた“M”フラグ4021と共にMAG102の識別子を示すルータID4020が接続ステータスフィールド402に含まれているとする。この場合、LMA101は、MN11がローカルモビリティドメイン10内でマルチホーミングのサポートを受けたい旨を把握する。
なお、この接続メッセージ40の受信前に、LMA101は、MAG103からPBUを既に受信している可能性があり、このPBUによって、MAG103へのルーティングエントリを除くルーティングキャッシュ内のMN11に関するすべてのエントリが削除されてしまっている可能性がある。しかしながら、LMA101は、接続メッセージ40内の情報を参照することで、MAG103へのルーティングエントリを削除することなく、MAG102へのルーティングエントリが含まれるようにMN11に関するルーティングキャッシュを修正することが可能となる。
また、LMA101は、接続メッセージ40の受信後にMAG103からPBUを受信した場合においても、マルチホーミングをサポートしていないモバイルアクセスゲートウェイにモバイルノードが接続されていることを考慮して、MN11に関するルーティングキャッシュを維持することが可能となる。ルーティングキャッシュを維持するための方法としては、例えばLMA101が、ルーティングキャッシュをアップデートする際に、特別なBIDをMAG103に関するエントリに割り当てる方法が挙げられる。LMA101は、MN11によるMAG103への接続に関するアップデートを行うためのPBUを受信した場合は常に、MN11のルーティングキャッシュに従ってPBUの処理を行うように特別な配慮を行う。
また、例えば、マルチホーミングプロトコルの機能を実装するモバイルアクセスゲートウェイが、ユニークなBIDを割り当てるプロセスを実行することも可能である。これは、モバイルアクセスゲートウェイがローカルモビリティアンカあてのメッセージを受信(intercept)し、マルチホーミングプロトコルの機能を有していないことが確認されているモバイルアクセスゲートウェイに関連するユニークなBIDを付加することを示している。この動作が行われる場合には、ローカルモビリティアンカがレガシノード(すなわち、ルーティングキャッシュエントリに特別なBIDを割り当てることができないローカルモビリティアンカ)である場合にも本発明が適用可能となるという利点がある。また、ローカルモビリティアンカによって実行される動作のロードバランスを行うために、モバイルアクセスゲートウェイにBIDを割り当てる処理負荷を分散させることが可能となるという利点もある。
以下、この動作を示すより詳細な例について説明する。図1において、MAG102は、マルチホーミングプロトコルを実装しており、MAG103は、マルチホーミングプロトコルを実装していないとする。IF111は、MN11はIF110を通じてMAG102と接続しており、さらに、IF111によってMAG103へ接続しようとしている。
MAG103は、MN11がMAG103とまもなく接続する旨を通知するための接続メッセージ40を、MAG102経由でLMA101へ送信するようMN11に指示する。MN11はこの指示に従って、MAG102経由でLMA101へ接続メッセージ40を送信し、MAG102は、例えば、パケットヘッダ400のパケットタイプを検査することによってMN11から送信された接続メッセージ40を特定すると、この接続メッセージ40にMAG103に関するBIDを付加する。そして、BIDが付加された接続メッセージがMAG102からLMA101に転送され、LMA101において処理される。
さらに、別の好適な実施の形態において、ローカルモビリティアンカが、モバイルノードからの接続メッセージ40を受信すると、確認メッセージをモバイルノードに送信してもよい。なお、確認メッセージの送信は、モバイルノードによってリクエストされてもよい。また、モバイルノードからリクエストされない場合であっても、確認メッセージの送信が行われてもよい。確認メッセージの送信が行われた場合には、ローカルモビリティアンカへの接続メッセージ40内の情報の伝送に成功したことをモバイルノードが把握できるという利点がある。例えば、確認メッセージを受信したモバイルノードは、マルチホーミングプロトコルを実施していないモバイルアクセスゲートウェイとの間で、アクセス認証処理を開始することが可能となる。
以下、この動作を示すより詳細な例について説明する。図1において、MAG102は、マルチホーミングプロトコルを実装しており、MAG103は、マルチホーミングプロトコルを実装していないとする。MN11は、IF110を通じてMAG102と接続しており、さらに、IF111によってMAG103へ接続しようとしている。
MAG103は、MN11がMAG103とまもなく接続する旨を通知するための接続メッセージ40を、MAG102経由でLMA101へ送信するようMN11に指示する。MN11は、LMA101から確認メッセージを受信するまで、MAG103とのアクセス認証処理を行わないよう決定し、これによって、LMA101のルーティングキャッシュに矛盾が生じないようにする。一方、LMA101が接続メッセージ40の受信に成功すると、LMA101は、MN11に確認メッセージを送り返す。MN11は、成功を示す確認メッセージを受信することで、MAG103との間でアクセス認証処理を開始するようIF111に対して指示を行うことが可能となる。
さらに、別の好適な実施の形態において、モバイルノードは、モバイルノードとアクティブな接続を有するマルチホーミングをサポートしているモバイルアクセスゲートウェイに対して、ローカルモビリティアンカへの登録メッセージの再送を依頼することも可能である。なお、本明細書では、ローカルモビリティアンカへの登録メッセージの再送をモバイルノードがモバイルアクセスゲートウェイにリクエストするためのメッセージを、再関連付けメッセージ(rebind message)と呼ぶことにする。
このように、ローカルモビリティアンカへの登録メッセージの再送を要求する理由は、例えば、ローカルモビリティアンカからの確認メッセージがモバイルノードに返されなかった場合に、モバイルアクセスゲートウェイとの間のアクセス認証処理の開始が大きく遅れてしまうからである。この場合、モバイルノードは、マルチホーミングをサポートしていないモバイルアクセスゲートウェイとの間でアクセス認証処理を開始し、次に、マルチホーミングをサポートしているモバイルアクセスゲートウェイに対して登録メッセージの再送を依頼する。このような場合は、ローカルモビリティアンカがマルチホーミングをサポートしていないモバイルアクセスゲートウェイから登録メッセージを受信した場合に、モバイルノードのマルチホーミング機能がローカルモビリティドメイン内ではサポートされていないことにより生じる。
モバイルアクセスゲートウェイから登録メッセージが再送された場合は、モバイルノードが、ローカルモビリティアンカにおけるモバイルノードのルーティングキャッシュの再構築を望んでいることを示している。さらに、モバイルノードがマルチホーミングをサポートしていないモバイルアクセスゲートウェイとアクティブな接続を有している場合には、モバイルアクセスゲートウェイに関する登録を、マルチホーミングをサポートしているモバイルアクセスゲートウェイへ委譲することが可能である。
また、図6には、本発明の好適な実施の形態における再関連付けメッセージのフォーマットの一例が図示されている。再関連付けメッセージ60は、パケットヘッダ600、モバイルノード識別子(MN−ID)601、アシストバインディングフィールド602を有している。
パケットヘッダ600は、メッセージの送信元(再関連付けメッセージの送信者)やあて先に関する情報を伝送するためのフィールドである。パケットヘッダ600には、例えば、送信元やあて先のIPv4アドレス又はIPv6アドレス、メッセージタイプを示すタイプフィールド、メッセージの長さを示す長さフィールドなどが含まれている。
MN−ID601は、モバイルノードの識別子を含むフィールドであり、このモバイルノードの識別子によって、どのモバイルノードのバインディングに関してローカルモビリティアンカへの再送が必要とされているのかをモバイルアクセスゲートウェイが識別できるようになる。
また、アシストバインディングフィールド602は、モバイルノードが、追加バインディング情報を記載できるようにするためのフィールドである。追加バインディング情報は、モバイルノードが、ローカルモビリティアンカへの登録に関してモバイルアクセスゲートウェイの援助を受けようとしていることを示すものである。なお、例えば、アシストバインディングフィールド602には、1つ又は複数のルータ識別子(ルータID)6020が含まれていることが望ましく、このルータ識別子6020によって、モバイルノードは、ローカルモビリティアンカへの登録メッセージに挿入されるべき追加のモバイルアクセスゲートウェイを指定することが可能となる。
以下、より詳細に再関連付けメッセージ60の利用例について説明する。図1において、MAG102は、マルチホーミングプロトコルを実装しており、MAG103は、マルチホーミングプロトコルを実装していないとする。MN11は、MAG103とのアクセス認証処理を遅らせたくないので、この処理をIF111に開始させる。また同時に、LMA101へのPBUの再送を依頼する再関連付けメッセージ60をMAG102へ送信する。なお、MN11は、LMA101への登録を行う際にMAG103に関するBIDの割り当てを行うようMAG102へ依頼するために、アシストバインディングフィールド602にMAG103の識別情報を追加する。MAG102は、自身のバインディングに加えてMAG103のバインディングが記載されたPBUをLMA101へ送信する。これによって、LMA101は、MN11がマルチホーミングをサポートしていないモバイルアクセスゲートウェイに接続されていることを把握できるようになる。また、LMA101は、MN11に関するルーティングキャッシュを維持する際にマルチホーミングに関して配慮するよう注意することが可能となる。
また、別の好適な実施の形態において、モバイルノードは、再関連付けメッセージによって、ローカルモビリティドメインにおける現在のすべての登録を扱うことが可能なマルチホーミングをサポートしているモバイルアクセスゲートウェイの1つを選択することが可能である。この場合、アシストバインディングフィールド602には、マルチホーミングをサポートしているか否かに関係なく、モバイルアクセスゲートウェイの識別子が挿入される。
例えば、図1において、MAG102はマルチホーミングプロトコルを実装しているが、MAG103はマルチホーミングプロトコルを実装していないとする。MN11は、MAG103がマルチホーミングをサポートしていないことを把握し、MAG103に関してLMA101への登録の処理を行うよう依頼する再関連付けメッセージ60をMAG102へ送信する。これにより、MAG102は、LMA101にルーティングエントリを登録するためのPBUを、MAG103に代わって送信する。このエントリは、さらにMAG102によって割り当てられたBIDが付加される。また、MAG102は、MN11がマルチホーミングをサポートしていないモバイルアクセスゲートウェイへ接続する旨をLMA101へ通知することが可能である。この結果、LMA101は、MN11に関するMAG103経由の登録処理をMAG102へ委譲するよう決定してもよい。
さらに別の好適な実施の形態において、ローカルモビリティアンカが、ローカルモビリティドメイン内のモバイルノードのためにマルチホーミングをサポートするために、何らかの特別な機能を実装してもよい。例えば、ローカルモビリティアンカが、モバイルノードのマルチホーミング機能を事実上サポートしていないモバイルアクセスゲートウェイからの登録メッセージを検出した場合、ローカルモビリティアンカは、モバイルノードのルーティングキャッシュを変更せず、代わりにこの新たな登録に関して一時的なエントリを作成する。同時に、ローカルモビリティアンカは、この登録メッセージによってモバイルノードに関するマルチホーミング機能が失われてしまうことが判明した場合には、モバイルノードに確認を行う。
また、別の好適な実施の形態において、ローカルモビリティアンカは、モバイルノードのルーティングキャッシュを変更する処理を行い、これによって、モバイルノードが、ローカルモビリティドメインにおけるマルチホーミング機能を失うようにすることも可能である。このとき、ローカルモビリティアンカは、ローカルモビリティドメインにおけるマルチホーミング機能が失われたことを通知するメッセージをモバイルノードに送信する。さらに、このメッセージによって、ローカルモビリティアンカがマルチホーミングをサポートしていないモバイルアクセスゲートウェイからモバイルノードの登録を受信したという原因によってモバイルノードのマルチホーミング機能が失われる旨を、モバイルノードへ通知してもよい。こうしたメッセージをローカルモビリティアンカから送信することで、モバイルノードが現在接続されているモバイルアクセスゲートウェイの機能をモバイルノードにチェックさせることができるという利点がある。なお、この場合には、モバイルノードは、例えば本発明に係る方法を利用して、ローカルモビリティドメインにおけるマルチホーミング機能の再構成(再登録処理)を行うことが可能である。
さらに、別の好適な実施の形態において、モバイルアクセスゲートウェイの機能をチェックすることで、モバイルノードが、ローカルモビリティドメイン内のモバイルアクセスゲートウェイのリストや各モバイルアクセスゲートウェイの機能に関する情報を集めることも可能である。このリストは、例えば、一定期間あるいは一定のリスト項目数だけ保持されてもよい。また、ローカルモビリティドメイン内のモバイルアクセスゲートウェイの機能を把握するために、このリストがローカルモビリティアンカに送信されてもよい。これは特に、ローカルモビリティアンカ及びモバイルアクセスゲートウェイが同一プロバイダに属していないが、同一のローカルモビリティドメイン内に共設されている場合に有用である。例えば、この一例として、セルラのオペレータ間でローミング協定が行われている場合が挙げられる。このローミング協定では、例えば、モバイルアクセスゲートウェイが、相手オペレータのモバイルノードに関するルーティングパスを相手オペレータのローカルモビリティアンカに登録することが可能である。なお、こうしたリストをローカルモビリティドメイン側(あるいは、1つ又は複数のオペレータ側)で作成してもよい。
例えば、モバイルノードは、このリストを用いて、マルチホーミングをサポートしていないモバイルアクセスゲートウェイの使用に関する優先度(プリファレンス)をローカルモビリティアンカにセットする。例えば、この一例として、モバイルノードがマルチホーミングをサポートしていないモバイルアクセスゲートウェイへの接続を望まず、マルチホーミングをサポートしているモバイルアクセスゲートウェイだけを通知してほしいとローカルモビリティアンカに依頼する場合が挙げられる。
また、別の例として、モバイルノードが、これから接続を予定しているモバイルアクセスゲートウェイの使用に対して低い優先度をローカルモビリティアンカに設定することも可能である。この場合、モバイルノードの近傍に存在する別の適切なモバイルアクセスゲートウェイをモバイルノードが探索する動作を、ローカルモビリティアンカが支援することが可能となる。
モバイルノードのインタフェースがローカルモビリティドメイン内で移動した場合には、モバイルノードのマルチホーミング機能を確実に維持するように更なる配慮が行われる必要がある。例えば、図1において、MAG102及びMAG103は、マルチホーミングプロトコルを実装しており、MAG104はマルチホーミングプロトコルを実装していないとする。また、MN11のIF110はMAG102に接続されており、MN11のIF111はMAG103に接続されているとする。このとき、MN11のIF111がMAG103からMAG104に移動を行おうとしている場合を考える。
本発明の好適な実施の形態において、MN11がMAG104とまもなく接続する旨をLMA101へ通知した場合、LMA101は、まもなく行われる接続によってどのバインディングが置き換えられるのか分からないという問題が生じる。これは特に、例えばMAG102とLMA101との間のネットワーク輻輳などの原因によって、MAG102からの登録削除メッセージ(de-registration message)がMAG104の接続に関する登録よりも遅れてLMA101に届く場合に問題が生じる。このような場合を考慮して、モバイルノードは、まもなく行われる接続によってどのバインディングが置き換えられるのかをローカルモビリティアンカへ通知するためのより詳細な情報を加える必要がある。
このように接続(バインディング)を特定するために追加される情報は、例えば、ローカルモビリティアンカがモバイルノードの複数のインタフェースのそれぞれをユニークに識別できるインタフェース識別子(IF−ID)の形式にすることが可能である。ここで挙げた例の場合、LMA101では、例えば、各ルーティングエントリがMN11のIF−IDと関連付けられる。例えば、MAG102へのルーティングエントリはIF110のIF−IDと関連付けられ、MAG103へのルーティングエントリはIF111のIF−IDと関連付けられる。MN11は、IF111のIF−IDを使用することによって、まもなく行われるMAG104との接続がIF111によって行われることをLMA101へ通知することが可能となる。これにより、LMA101は、まもなく行われるMAG104との接続がMAG103へのルーティングエントリを置き換えるべきものであることを把握することが可能となる。
また、別の好適な実施の形態において、モバイルノードに関する各ルーティングエントリを識別するために使用される識別子(BID)がモバイルアクセスゲートウェイのタイプに関係なく共通のものである場合には、こうしたエントリが予定外に削除されてしまうことによって、モバイルノードがローカルモビリティアンカへのアクティブなルートをいくつか失ってしまう可能性がある。
例えば、上述のシナリオにおいて、IF111がMAG103からMAG104へ移動するという通知をLMA101が受けた場合には、MAG104に関するルーティングエントリに、MAG103へあらかじめ割り当てられているBIDが使用されている可能性がある。このようにBIDを再利用する方法は、ローカルモビリティアンカが保持しなければならないBIDの数を制限する場合に一般的に用いられる。このとき、例えばネットワーク輻輳によってMAG103からの登録削除メッセージがLMA101へ届くのが遅くなった場合には、この登録削除メッセージは、既に置き換えられたルーティングエントリ(MAG104へのルーティングエントリ)を削除することになる。これは、登録削除メッセージに、MAG104に割り当てられたものと同一のBIDが含まれていることによる。
このような状況を回避するためには、モバイルノードの各ルーティングエントリを識別するために使用するユニークなバインディング識別子(BID)が、異なるモバイルアクセスゲートウェイのタイプで区別されるようにする必要がある。例えば、ローカルモビリティドメインでマルチホーミングをサポートしていないモバイルアクセスゲートウェイに対しては、BID#128以上を使用することによって区別する。
また、この問題を解決する別の実施の形態において、動作シーケンスの順序で、バインディング識別子(BID)が使用されるようにしてもよい。例えば、ローカルモビリティアンカは、ローカルモビリティアンカが異なるモバイルアクセスゲートウェイから受信する各登録メッセージに関して、1つずつBIDのカウントを増加させる。例えば、MAG102のエントリがBID#1を使用しており、LMA101が、MN11に関するMAG103からの登録メッセージを受信した場合には、このエントリ(MAG103のエントリ)に対してBID#2を割り当てる。こうしたカウンタは、モバイルノードが一定期間動作していない場合に、最初の開始値に戻るよう再設定することが可能である。
さらに別の好適な実施の形態において、モバイルノードに関するルーティングエントリがすぐには削除されず、その代わり、ある期間経ってから削除されるようにマークが付されてもよい。ルーティングキャッシュから削除されることを示すマークが付されると、このルーティングエントリにはタイマが設定される。タイマが満了した場合には、このルーティングエントリはルーティングキャッシュから完全に削除される。
このリカバリ動作は、モバイルノードが予定外に削除されてしまったバインディングを復元させたいと望む場合に有用である。例えば、ローカルモビリティアンカにおいて、マルチホーミング機能をサポートしていないモバイルアクセスゲートウェイからの登録メッセージを受信することによって、モバイルノードに関するルーティングキャッシュ内のエントリが削除されてしまう場合が挙げられる。この場合、モバイルノードは、リカバリメッセージを送って、削除されたモバイルノードに関するすべてのルーティングエントリ(あるいは、所望のマルチホーム状態を得るために復元が必要な特定のルーティングエントリ)を元に戻すようローカルモビリティアンカに依頼する。このリカバリメッセージは、ローカルモビリティアンカへ送信される任意のメッセージに挿入されたフラグとして実現されてもよい。
図7には、本発明の好適な実施の形態において、リカバリ動作をサポートするルーティングキャッシュの一例が図示されている。なお、本発明を実現する任意のエンティティ(モバイルノードやローカルモビリティアンカなど)内に当該ルーティングキャッシュの機能を配置することが可能である
通常、ルーティングキャッシュ70はモバイルノードの識別子(MN−ID)欄71、バインディング識別子(BID)欄72、気付アドレス(CoA)欄73、パス欄74、非動作タイマ欄75を有している。
MN−ID欄71は、通常、ローカルモビリティドメインで使用するためにモバイルノードに割り当てられたプレフィックスを有している。また、BID欄72も通常、モバイルノードの異なるルーティングエントリを区別するために使用されるユニークなバインディング識別子を有している。また、CoA欄73は、モバイルノードが接続されているモバイルアクセスゲートウェイの気付アドレスを識別するものである。以上の情報によって、モバイルノードへのパケットのルーティングが可能となる。
本発明では、パス欄74によって、エンティティは、そのルーティングがローカルモビリティドメイン内でまだアクティブであるか否かを把握することが可能である。パス欄74においてエントリが“無効”とマークされている場合には、このルーティングパスは使用不可能であることを示している。一方、エントリが“有効”とマークされている場合には、このルーティングパスは使用可能であることを示している。また、非動作タイマ欄75は、エンティティに対して、ルーティングパスがルーティングキャッシュから完全に消去されてしまうまでの残り時間を通知するための情報を含んでいる。非動作タイマ欄75は通常、パス欄74が“非動作”を示す場合に設定される。
以下、上述の本発明に係るリカバリ動作の一例について説明する。図7において、LMA101は、マルチホーミングをサポートしていないモバイルアクセスゲートウェイ(MAG104)から登録メッセージを受信した場合に、図7に示すルーティングキャッシュを構築する。この登録メッセージを受信した場合、MAG102とMAG103の両方のエントリがLMAによって削除対象としてマークされる。これによって、LMA101が両方のエントリを“非動作”とし、それらのエントリに、ルーティングキャッシュから完全に削除されるまでタイマ(例えば60分)をセットする。
一方、MN11は、IF110がMAG102との接続を失っていることを発見し、LMA101のルーティングキャッシュに何らかの問題が生じていることを把握する。MN11は、LMA101とMAG102との間のルーティングパスを再構成するため、非動作バインディングの回復を依頼するリカバリメッセージをLMA101へ送信する。このリカバリメッセージを受信したLMA101は、MAG102及びMAG103の両方のエントリを回復するために“アクティブ”のマークを付ける。なお、LMA101は、“アクティブ”の状態に戻す前に、MAG102及びMAG103に対して、どのエントリがまだアクティブかを判断するための問い合わせを行うことが可能である。あるいは、MN11がLMA101へのリカバリメッセージ内にどのエントリ(この場合には、MAG102に関するエントリ)の回復を望んでいるかを記載し、このエントリのみを“アクティブ"の状態に戻すことも可能である。
また、本発明の別の実施の形態において、モバイルノードと、ローカルモビリティドメイン内のAAA(認証、許可、課金)サーバとの間におけるAAA処理期間中に、本発明に係る情報(の一部)が送信されてもよい。例えば、モバイルノードは、ローカルモビリティドメイン内でマルチホーミングのサポートを望んでいることをAAAサーバに通知してもよい。このモバイルノードからの要望は、AAAサーバからモバイルノードのルーティングキャッシュを取り扱っているローカルモビリティキャッシュへ渡される。これにより、ローカルモビリティアンカは、モバイルノードのマルチホーミング機能を削除してしまうような登録メッセージを受信した場合に、更なる動作を行って、マルチホーミング機能が中断されないようにすることが可能である。なお、ローカルモビリティアンカによって行われるこうした動作は、本発明の方法に従って行われることが望ましい。
また、モバイルノードがAAA処理の間に、モバイルアクセルゲートウェイ及びその機能のリストに関するリクエストを行うことも可能である。これにより、モバイルノードは、接続するためのマルチホーミングをサポートしているモバイルアクセスゲートウェイを検索することが可能となる。例えば、モバイルノードのインタフェースの1つがマルチホーミングをサポートしていないモバイルアクセスゲートウェイを発見した場合には、モバイルノードは、ローカルモビリティドメインでのマルチホーミング機能を維持するために、そのインタフェースに対して、そのモバイルアクセスゲートウェイと接続を行わないように指示する。
次に、本発明を実現可能とする装置について説明する。図8は、本発明の好適な実施の形態におけるモバイルノードの機能アーキテクチャの一例を示すブロック図である。図8において、モバイルノードの機能アーキテクチャ80は、ネットワークインタフェース800、アプリケーション801、データベース802、機能チェックエンジン803、ルータバインディングエンジン804により構成されている。
ネットワークインタフェース800は、任意の通信媒体を介して別のノードと通信を行うために必要なすべてのハードウェア及びソフトウェアを包含する機能ブロックである。関連する周知の技術用語を用いた場合、ネットワークインタフェース800は、レイヤ1(物理層)及びレイヤ2(データリンク層)の通信コンポーネント、ファームウェア、ドライバ、通信プロトコルなどを表している。なお、図8にはネットワークインタフェース800が1つのみ図示されているが、モバイルノードは1つ又は複数のネットワークインタフェース800を有していてもよい。
また、シグナル/データパス810を介して、ネットワークインタフェース800と機能チェックエンジン803とが相互に通信を行うことが可能であり、トリガ/パケットが伝送可能となる。例えば、ネットワークインタフェース800で受信したルータ機能メッセージ20は、シグナル/データパス810を通じて機能チェックエンジン803に伝送され、これにより、機能チェックエンジン803は、特定のモバイルアクセスゲートウェイに関する機能を特定することが可能となる。
また、シグナル/データパス816を介して、ネットワークインタフェース800とルータバインディングエンジン804とが相互に通信を行うことが可能であり、トリガ/パケットが伝送可能となる。例えば、接続メッセージ40は、ルータバインディングエンジン804からネットワークインタフェース800へ伝送され、ネットワークインタフェース800からローカルモビリティドメイン内のエンティティへ送信可能となる。
また、アプリケーション801は、通信プロトコルスタックのネットワークレイヤの上位に位置するプロトコルやプログラムを包含する機能ブロックを示している。このアプリケーション801は、例えば、トランスポートセッションプロトコル(TCP:Transmission Control Protocol)、ストリーム制御トランスポートプロトコル(SCTP:Stream Control Transport Protocol)、ユーザデータグラムプロトコル(UDP:User Datagram Protocol)や、他のノードとの通信に必要なプログラム及びソフトウェアなど、任意のトランスポートレイヤプロトコル又はセッションレイヤを有している。なお、図8にはアプリケーション801が1つのみ図示されているが、モバイルノードは1つ又は複数のアプリケーション801を有していてもよい。
また、シグナル/データパス811を介して、アプリケーション801とルータバインディングエンジン804とが相互に通信を行うことが可能であり、トリガ/パケットが伝送可能となる。例えば、アプリケーション801はシグナル/データパス811を介して、ネットワークインタフェース800近傍に存在する特定のモバイルアクセスゲートウェイの機能情報をリクエストするようルータバインディングエンジン804をトリガする。
また、データベース802は、モバイルノードによって必要とされる情報の格納を行うことが可能である。なお、データベース802は、例えば、加入者ポリシ8020、ルーティングキャッシュ8021、ルータデータベース8022によって構成可能である。
加入者ポリシ8020は、通常、特定のサービスの加入者に関する情報を有している。例えば、特定のサービスの加入者に関する情報として、ローカルモビリティドメインに接続している際にモバイルノードを識別するために使用されるモバイルノード識別子(MN−ID)を用いることが可能である。ルータバインディングエンジン804は、接続メッセージ40を作成する際、シグナル/データパス812を介して、加入者ポリシ8020からMN−IDを参照することが可能である。
また、ルーティングキャッシュ8021は、ローカルモビリティドメイン内でモバイルノードが維持しているモバイルアクセスゲートウェイとのアクティブな接続に関するエントリを有している。ルータバインディングエンジン804は、ローカルモビリティドメインにおけるモバイルノードのマルチホーミング機能を再確立するための接続メッセージ40を作成する際、シグナル/データパス813を介して、ルーティングキャッシュ8021に格納されているすべての接続に関する情報を検索する。
また、ルータデータベース8022は、ローカルモビリティドメインのモバイルアクセスゲートウェイに関する情報を有している。例えば、すべてのモバイルアクセスゲートウェイ及びそれらの対応する機能のリストが、ルータデータベース8022に格納される。機能チェックエンジン803は、シグナル/データパス814を介して、ローカルモビリティドメイン内に存在するモバイルアクセスゲートウェイ及びそれらの対応する機能に関する情報をルータデータベース8022にアップデートすることが可能である。
本発明の実施の形態では、機能チェックエンジン803が、ルータ機能メッセージ20に含まれる機能情報を受信する機能情報受信部として動作し、モバイルアクセスゲートウェイがマルチホーミングをサポートしているか否かをルータ機能メッセージ20から判断することが可能である。ルータ機能メッセージ20から判断されるモバイルアクセスゲートウェイの機能情報は、ルータデータベース8022に格納される。なお、機能チェックエンジン803は、任意の方法(例えば、ファストモバイルIP)を用いて、まもなく接続しようとしているローカルモビリティアンカの機能情報を取得してもよい。
機能チェックエンジン803は、モバイルアクセスゲートウェイの機能情報に従って、シグナル/データパス815を介して、ルータバインディングエンジン804が行うべき適切な動作をトリガすることが可能である。例えば、モバイルアクセスゲートウェイがマルチホーミングをサポートしているのであれば、機能チェックエンジン803は、通常の処理と同様に、ルータバインディングエンジン804に対してアクセス認証処理を開始するよう依頼する。しかしながら、モバイルアクセスゲートウェイがマルチホーミングをサポートしていない場合には、機能チェックエンジン803は、例えば、ルータバインディングエンジン804に対して、まもなく行われる接続をローカルモビリティドメイン内のエンティティに通知するための接続メッセージ40を準備するよう依頼する。
また、本発明の実施の形態では、モバイルノードがローカルモビリティドメイン内でマルチホーミング機能を確実に維持できるようにするために、ローカルモビリティドメイン内のエンティティに対して確実に通知が行われるようにする目的で、ルータバインディングエンジン804が導入される。ルータバインディングエンジン804は、マルチホーミング機能を確実に維持できるようにするための情報として、モバイルノードが接続しているローカルモビリティアンカの機能情報をローカルモビリティドメイン内のエンティティへ通知する機能情報通知部の機能を実現する。さらに、ルータバインディングエンジン804は、この通知とともに、処理結果を要求する確認メッセージの生成及び送信を行う確認要求部としても機能する。
本発明の実施の形態においては、マルチホーミング機能を確実に維持できるようにするための情報は、接続メッセージ40によって通知される。この通知により、ローカルモビリティドメイン内のエンティティは、モバイルノードがマルチホーミング機能をサポートしていないモバイルアクセスゲートウェイにまもなく接続しようとしていることや、ローカルモビリティドメイン内のモバイルアクセスゲートウェイを経由するモバイルノードのすべてのアクティブな接続に関して把握できるようになる。
また、ルータバインディングエンジン804は、ローカルモビリティドメイン内のエンティティへ通知するための様々なメッセージ(モバイルノードの接続に関するルーティング情報の再構築を要求するメッセージ、モバイルノードのマルチホーム状態を再構成するための情報を通知するメッセージモバイルノードのルーティングエントリが削除されたと判断できる場合にそのルーティングエントリの復元を要求するメッセージなど)の生成及び送信を行う機能も有している。
なお、本明細書では、本発明が最も実用的かつ好適な実施例となるように考慮されて図示及び説明されているが、当業者であれば、上述の各装置の構成要素に係る設計やパラメータの詳細において、発明の範囲から逸脱しない程度に様々な変更が行われてもよいことは明らかである。例えば、モバイルルータが図8に図示されている機能アーキテクチャを実装してもよい。これにより、モバイルルータは、ローカルモビリティドメイン内に位置している間は、モバイルネットワーク内のノードに関するマルチホーミングのサービスを維持することが可能となる。
また、当業者であれば、モバイルノードが最初マルチホーミングをサポートしていないモバイルアクセスゲートウェイに接続している際、マルチホーミングをサポートしたモバイルアクセスゲートウェイが別のインタフェースで検出され、ローカルモビリティドメイン内でマルチホーミングを使用しようとする場合においても、本発明が適用可能であることは明らかである。この場合も、マルチホーミングをサポートしているモバイルアクセスゲートウェイからの登録メッセージが、マルチホーミングをサポートしていないモバイルアクセスゲートウェイのルーティングエントリを削除することで、同様の問題が生じる。このとき、モバイルノードはローカルモビリティドメイン内でマルチホーミングのサポートを所望している旨をローカルモビリティアンカに通知する本発明に係る方法を使用することが可能である。
さらに、当業者であれば、本発明に係る方法が、各インタフェースにおいてそれぞれ異なるタイプのモビリティプロトコルを実装しているモバイルノードに関しても有用であることが明らかである。例えば、このような場合の一例として、あるインタフェース(IF1)が、非特許文献1で説明されるようなモバイルIPv6プロトコルに関連付けられており、別のインタフェース(IF2)が非特許文献4で説明されるような拡張モバイルIPv6プロトコルに関連付けられている場合が挙げられる。この場合には、IF1からの登録メッセージによって、同一ホームエージェントに存在するIF2からの登録エントリが削除されてしまう可能性がある。この場合には、モバイルノードは、モバイルノードのマルチホーミングを維持するための詳細な情報をホームエージェントに提供する前に、各インタフェースにおける機能(各インタフェースが接続しているモバイルアクセスゲートウェイの機能)の問い合わせを行ってもよい。なお、アドレス体系の差異を各ノードで整合させる必要があるが、IPv4アドレス(モバイルIPv4プロトコルやプロキシモバイルIPv4プロトコル)との混在や、プレフィックス登録(ネットワークプレフィックスを登録の対象とする)の技術との混在においても、登録するアドレス(プレフィックス)情報のビット長や、対応するアドレスとの関連付けなどの実装の変更を行えば、有用であることは明らかである。
また、本明細書では、モバイルノードのネットワークインタフェースが複数であることを前提に説明を行っている部分があるが、本発明を実施するうえでの論理的なインタフェースが複数あればよい。例えば、1つの無線部を複数の接続方式で共用し、ネットワークインタフェースの観点からはその変化が問題にならない程度の速度で切り替えたり、レイヤ2で論理的なリンクを維持したりすることにより、ネットワーク部からは複数のインタフェースを介してネットワークに接続している場合と同等に動作できるよう構成されていてもよい。
また、ここでは、図示されているような簡単なネットワーク構成に基づいて本発明の説明を行ったが、ローカルネットワークドメインの構成は、複数オペレータ間のローミング関係も含めて多岐に渡ることが考えられる。例えば、モバイルアクセスゲートウェイがモバイルノードの直接的なアクセスルータである構成や、モバイルアクセスゲートウェイが異なるアクセスネットワーク(ローミングを含む)との境界ルータであり、モバイルノードはいったんその異なるアクセスネットワークに接続した後、そのアクセスネットワークを介して境界ルータであるモバイルアクセスゲートウェイに接続するという構成が考えられる。しかしながら、いずれの構成又は条件の場合においても、様々なパラメータやモバイルノードからモバイルアクセスゲートウェイへの到達手順、モバイルノードの通信手順などの設計部分が異なるものの、本発明の動作に関しては同様に適用可能であることは明白である。
また、上述の実施の形態では、ローカルモビリティ管理の環境であることが仮定されているが、モバイルルータ(MR:Mobile Router)(及びその配下のノード)により構成されたモバイルネットワーク(Mobile Network)(若しくは階層化されたモバイルネットワーク)に本発明を適用することも可能である。
例えば、モバイルネットワークの構成方法の1つであるNEMO(NEtwork Mobility)はMRがHA(Home Agent)に移動ネットワーク(及びモバイルノード)の移動登録を行うことにより、移動端末に対するモビリティサポートを提供しているが、本明細書におけるモバイルノードがMRに対応する形で適用可能である。この場合、ローカルモビリティアンカはMRのHAに対応すると考えることができる。さらに、PMIPを用いたネットワークを提供するネットワークオペレータがローミング関係などにより、PMIPで構成しているモバイルアクセスゲートウェイ−ローカルモビリティアンカ間のトンネルを多段に用いるような場合は階層化されたモバイルネットワークに相当する。
さらに、オーバレイネットワークの環境に本発明を適用することも可能である。例えば、モバイルアクセスゲートウェイによるモバイルノードに対するモビリティサポートをpHA(Proxy HA)に対応する形で適用可能である。この場合、モバイルノードの移動の起点(ある時点を基準とするものであったり(相対的)、ネットワークオペレータへの登録の状態(確定的)であったり、様々な場合があり得る)となるホームエージェント若しくはモバイルノードの接続先であるホームエージェントから登録情報を受信する他のホームエージェントはローカルモビリティアンカに対応すると考えることができる。
また、モバイルノードは複数の通信デバイスから構成されるものであってもよく、例えばパーソナルコンピュータなどの電子計算機に外挿型あるいは組み込み型の3GPP通信用デバイスモジュールや非3GPP通信デバイスモジュールを装着する場合などがあり、こうした多様なモバイルノードにおいても本発明は同等の効果を有するものである。
なお、上記の本発明の実施の形態の説明で用いた各機能ブロックは、典型的には集積回路であるLSI(Large Scale Integration)として実現される。これらは個別に1チップ化されてもよいし、一部又はすべてを含むように1チップ化されてもよい。なお、ここでは、LSIとしたが、集積度の違いにより、IC(Integrated Circuit)、システムLSI、スーパーLSI、ウルトラLSIと呼称されることもある。
また、集積回路化の手法はLSIに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。LSI製造後に、プログラムすることが可能なFPGA(Field Programmable Gate Array)や、LSI内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。
さらには、半導体技術の進歩又は派生する別技術によりLSIに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオ技術の適応などが可能性としてあり得る。
本発明は、パケット交換型データ通信ネットワークシステムにおける通信技術に適用可能であり、特に、ネットワークベースのモビリティ管理技術やモバイルノードのマルチホーミング機能を実現するための技術に適用可能である。

Claims (23)

  1. ネットワークベースのモビリティ管理を行うとともにマルチホーミングをサポートするローカルモビリティドメイン内で移動を行う移動端末であって、
    複数の経路でパケットの送受信を行うことを可能とする、前記複数の経路のそれぞれに対応する複数の通信インタフェースと、
    前記複数の通信インタフェースの少なくとも1つによって前記ローカルモビリティドメイン内の接続ポイントとして機能する接続ノードへ接続する場合、前記複数の通信インタフェースのうちの1つ又はすべてが接続する前記接続ノードがマルチホーミングの機能をサポートしているか否かを示す情報を、前記ローカルモビリティドメイン内のエンティティに対して通知する機能情報通知手段とを、
    有する移動端末。
  2. 前記機能情報通知手段が、前記複数の通信インタフェースの少なくとも1つによってまもなく接続しようとしている前記接続ノードがマルチホーミングをサポートしていないことが把握できた場合、前記接続ノードがマルチホーミングの機能をサポートしているか否かを示す情報を、前記ローカルモビリティドメイン内のエンティティへ通知するよう構成されている請求項1に記載の移動端末。
  3. 前記機能情報通知手段が、前記複数の通信インタフェースの少なくとも1つによってまもなく接続しようとしている前記接続ノードへ接続するためのアクセス認証が確立していない場合、前記接続ノードがマルチホーミングの機能をサポートしているか否かを示す情報を、前記ローカルモビリティドメイン内のエンティティへ通知するよう構成されている請求項2に記載の移動端末。
  4. 前記複数の通信インタフェースの少なくとも1つによってまもなく接続しようとしている前記接続ノードから、前記接続ノードがマルチホーミングの機能をサポートしているか否かを示す情報を受信する機能情報受信手段を更に有する請求項2に記載の移動端末。
  5. 前記複数の通信インタフェースの少なくとも1つによってまもなく接続しようとしている前記接続ノードがマルチホーミングの機能をサポートしているか否かを示す情報を、ファストモバイルIPを利用して取得する機能情報取得手段を更に有する請求項2に記載の移動端末。
  6. 前記機能情報通知手段が、前記複数の通信インタフェースの少なくとも1つによってまもなく接続しようとしている前記接続ノードがマルチホーミングをサポートしていないことが把握できた場合、前記ローカルモビリティドメインへ接続しているすべての通信インタフェースの接続に関する情報を、前記ローカルモビリティドメイン内のエンティティへ通知するよう構成されている請求項1に記載の移動端末。
  7. 前記機能情報通知手段が、前記複数の通信インタフェースの少なくとも1つによってまもなく接続しようとしている前記接続ノードへ接続するためのアクセス認証が確立している場合、前記ローカルモビリティドメインへ接続しているすべての通信インタフェースの接続に関する情報を、前記ローカルモビリティドメイン内のエンティティへ通知するよう構成されている請求項2に記載の移動端末。
  8. 前記複数の通信インタフェースのうちの1つ又はすべてが接続する前記接続ノードがマルチホーミングの機能をサポートしているか否かを示す情報に対する処理結果を示す確認メッセージを要求する確認要求手段を更に有する請求項1に記載の移動端末。
  9. 前記確認メッセージを受信できなかった場合には、前記ローカルモビリティドメイン内のエンティティに対して、前記移動端末の接続に関するルーティング情報の再構築を要求するルーティング再構築要求手段を更に有する請求項8に記載の移動端末。
  10. 前記ローカルモビリティドメイン内のエンティティから、前記移動端末のマルチホーム状態が失われた旨の通知を受信した場合、前記移動端末のマルチホーム状態を再構成するための情報を前記ローカルモビリティドメイン内のエンティティへ通知する再構成手段を更に有する請求項1に記載の移動端末。
  11. 前記ローカルモビリティドメイン内のエンティティにおけるルーティングエントリが削除されたと判断できる場合、削除されたと判断された前記ルーティングエントリの復元を要求する復元要求手段を更に有する請求項1に記載の移動端末。
  12. 前記復元要求手段が、前記移動端末が接続しているマルチホーミングをサポートしている前記接続ノードに対して、前記ルーティングエントリを再構築させるための登録メッセージの再送を依頼するよう構成されている請求項11に記載の移動端末。
  13. 前記復元要求手段が、前記移動端末が接続している前記接続ノードの中から、前記登録メッセージの再送を依頼する前記接続ノードを選択するよう構成されている請求項11に記載の移動端末。
  14. 前記ローカルモビリティドメイン内の前記接続ノードがマルチホーミングの機能をサポートしているか否かを示す情報を収集し、リスト情報として格納する情報収集格納手段を更に有する請求項1に記載の移動端末。
  15. 前記機能情報通知手段が、前記複数の通信インタフェースの少なくとも1つによってまもなく接続しようとしている前記接続ノードがマルチホーミングをサポートしていないことが把握できた場合、まもなく接続しようとしている前記接続ノードへの接続によって置き換えられる対象のバインディングを示す情報を通知するバインディング特定情報通知手段を更に有する請求項1に記載の移動端末。
  16. まもなく接続しようとしている前記接続ノードへの接続によって置き換えられる対象のバインディングを示す前記情報に、置き換えられる対象のバインディングに関連する通信インタフェースを識別する固有の識別情報が含まれている請求項15に記載の移動端末。
  17. ローカルモビリティドメインにおいて、ネットワークベースのモビリティ管理を行うとともに、前記ローカルモビリティドメインに接続する移動端末のマルチホーミングをサポートする前記ローカルモビリティドメイン内のネットワークノードであって、
    前記移動端末の通信インタフェースが前記ローカルモビリティドメイン内の接続ポイントとして機能する接続ノードへ接続する場合、前記通信インタフェースと前記接続ノードとの対応をルーティング情報として保持するルーティングキャッシュと、
    前記移動端末が保持する複数の通信インタフェースのうちの1つ又はすべてが接続する前記接続ノードがマルチホーミングの機能をサポートしているか否かを示す情報を受信する機能情報受信手段と、
    前記機能情報受信手段で受信した前記接続ノードがマルチホーミングの機能をサポートしているか否かを示す情報に基づいて、前記移動端末に関するルーティング情報の更新を行うルーティング更新手段とを、
    有するネットワークノード。
  18. 前記機能情報受信手段が前記複数の通信インタフェースの少なくとも1つによってまもなく接続しようとしている前記接続ノードがマルチホーミングをサポートしていない旨を前記移動端末から受信した場合、前記接続ノードと前記接続ノードとまもなく接続しようとしている前記通信インタフェースとの対応を識別する固有の識別情報を準備する識別情報準備手段と、
    前記接続ノードから前記接続ノードと前記接続ノードとまもなく接続しようとしている前記通信インタフェースとの対応を示す情報を受信した場合に、前記通信インタフェースと前記接続ノードとの対応を示すルーティング情報に前記固有の識別情報を付加して前記ルーティングキャッシュに格納させるルーティング情報管理手段とを、
    更に有する請求項17に記載のネットワークノード。
  19. 前記機能情報受信手段が前記ローカルモビリティドメインへ接続しているすべての通信インタフェースの接続に関する情報を前記移動端末から受信した場合、前記ローカルモビリティドメインへ接続しているすべての通信インタフェースの接続に関する情報に基づき、前記ローカルモビリティドメインへ接続しているすべての通信インタフェースの接続に対応するルーティング情報を前記ルーティングキャッシュに追加するルーティングキャッシュ更新手段を更に有する請求項17に記載のネットワークノード。
  20. 前記複数の通信インタフェースのうちの1つ又はすべてが接続する前記接続ノードがマルチホーミングの機能をサポートしているか否かを示す情報に対する処理結果を示す確認メッセージを前記移動端末へ送信する確認送信手段を更に有する請求項17に記載のネットワークノード。
  21. 前記移動端末に関するルーティング情報を前記ルーティングキャッシュから消去するとともに、前記移動端末のマルチホーム状態が失われた旨を前記移動端末へ通知するルーティング情報消去通知手段を更に有する請求項17に記載のネットワークノード。
  22. 前記移動端末に関するルーティング情報を消去する場合に、消去対象のルーティング情報に係るルーティングを無効にするとともに一定期間消去を保留し、前記消去対象のルーティング情報に関する復元要求を前記一定期間内に前記移動端末から受信した場合には前記消去対象のルーティング情報を有効にし、前記消去対象のルーティング情報に関する復元要求を前記一定期間内に前記移動端末から受信しなかった場合には前記一定期間経過後に前記消去対象のルーティング情報を完全に削除するルーティング情報消去手段を更に有する請求項17に記載のネットワークノード。
  23. 前記機能情報受信手段が、前記複数の通信インタフェースの少なくとも1つによってまもなく接続しようとしている前記接続ノードへの接続によって置き換えられる対象のバインディングを示す情報を前記移動端末から受信した場合、前記ルーティング更新手段が、前記置き換えられる対象のバインディングを示す情報によって特定されるバインディングを、まもなく接続しようとしている前記接続ノードに関するバインディングに置き換えるよう構成されている請求項17に記載のネットワークノード。
JP2010521601A 2008-07-23 2009-07-22 移動端末及びネットワークノード Expired - Fee Related JP5371987B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2010521601A JP5371987B2 (ja) 2008-07-23 2009-07-22 移動端末及びネットワークノード

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
JP2008189674 2008-07-23
JP2008189674 2008-07-23
JP2010521601A JP5371987B2 (ja) 2008-07-23 2009-07-22 移動端末及びネットワークノード
PCT/JP2009/003434 WO2010010695A1 (ja) 2008-07-23 2009-07-22 移動端末及びネットワークノード

Publications (2)

Publication Number Publication Date
JPWO2010010695A1 JPWO2010010695A1 (ja) 2012-01-05
JP5371987B2 true JP5371987B2 (ja) 2013-12-18

Family

ID=41570164

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2010521601A Expired - Fee Related JP5371987B2 (ja) 2008-07-23 2009-07-22 移動端末及びネットワークノード

Country Status (3)

Country Link
US (1) US8619629B2 (ja)
JP (1) JP5371987B2 (ja)
WO (1) WO2010010695A1 (ja)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5080487B2 (ja) * 2006-10-30 2012-11-21 パナソニック株式会社 バインディング更新方法、移動端末、ホームエージェント、バインディング更新システム
US8619629B2 (en) * 2008-07-23 2013-12-31 Panasonic Corporation Mobile terminal and network node
US8873507B2 (en) * 2009-10-02 2014-10-28 Futurewei Technologies, Inc. Distributed local mobility anchors for achieving optimized mobility routing
US8824353B2 (en) * 2009-10-02 2014-09-02 Futurewei Technologies, Inc. Mobility route optimization in a network having distributed local mobility anchors
US8842607B2 (en) 2010-01-08 2014-09-23 Futurewei Technologies, Inc. Mobility management system and method
EP2362688B1 (en) 2010-02-23 2016-05-25 Alcatel Lucent Transport of multihoming service related information between user equipment and 3GPP evolved packet core
US8942193B2 (en) * 2011-04-08 2015-01-27 Blackberry Limited Routing different subsets of an internet protocol flow over different points of attachment
CN102833701B (zh) * 2011-06-15 2017-05-10 中兴通讯股份有限公司 多模终端的短信发送方法及多模终端
US8817707B2 (en) * 2012-07-20 2014-08-26 Intel Corporation Mechanisms for roaming between 3GPP operators and WLAN service providers
CA3084410C (en) * 2012-09-29 2023-01-03 Adaptive Spectrum And Signal Alignment, Inc. Optimized control system for aggregation of multiple broadband connections over radio interfaces
US9532396B2 (en) * 2013-09-20 2016-12-27 Broadcom Corporation Relay architectures for mobile wireless networks
CN107210923B (zh) 2014-12-04 2020-12-15 适应性频谱和信号校正股份有限公司 用于预测成功的dsl线路优化的方法和装置
US9467419B2 (en) * 2014-12-22 2016-10-11 Dell Products L.P. System and method for N port ID virtualization (NPIV) login limit intimation to converged network adaptor (CNA) in NPIV proxy gateway (NPG) mode

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006104202A1 (ja) * 2005-03-29 2006-10-05 Matsushita Electric Industrial Co., Ltd. 通信制御方法及びアドレス管理ノード並びにモバイルノード
WO2006111937A2 (en) * 2005-04-22 2006-10-26 Telefonaktiebolaget L M Ericsson (Publ) Mobility support for multihome nodes

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7567503B2 (en) * 2002-12-26 2009-07-28 Panasonic Corporation Mobile network control device and mobile network control method
US7843871B2 (en) * 2004-12-21 2010-11-30 International Business Machines Corporation Method of reestablishing communication by a mobile node upon recovery from an abrupt shut down
US8050217B2 (en) * 2005-03-04 2011-11-01 Panasonic Corporation Communication node and communication control method
US20090019180A1 (en) * 2005-03-31 2009-01-15 Matsushita Electric Industrial Co., Ltd. Communication control method, communication node, and mobile node
US8526463B2 (en) * 2005-06-01 2013-09-03 Qualcomm Incorporated System and method to support data applications in a multi-homing, multi-mode communication device
EP1764970A1 (en) * 2005-09-19 2007-03-21 Matsushita Electric Industrial Co., Ltd. Multiple interface mobile node with simultaneous home- and foreign network connection
US20070254677A1 (en) * 2006-05-01 2007-11-01 Motorola, Inc. Method and system to enable paging for mobile ip nodes
US8626161B2 (en) * 2007-08-16 2014-01-07 Qualcomm Incorporated Idle mode mobility management in a multi-access system using PMIP
CN101940014B (zh) * 2008-02-04 2013-10-23 爱立信电话股份有限公司 用于提供路由优化的方法和设备
EP2272000A4 (en) * 2008-03-19 2012-12-26 Research In Motion Ltd SUPPORT FOR MULTIPLE ACCOMMODATION PROTOCOLS USING TRANSIENT RECORDING AND EXTENSIBLE BINDING REVOCATION MESSAGES
US7948871B2 (en) * 2008-03-26 2011-05-24 Ericsson Ab Method and apparatus for mobility agent recovery
US8619629B2 (en) * 2008-07-23 2013-12-31 Panasonic Corporation Mobile terminal and network node

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006104202A1 (ja) * 2005-03-29 2006-10-05 Matsushita Electric Industrial Co., Ltd. 通信制御方法及びアドレス管理ノード並びにモバイルノード
WO2006111937A2 (en) * 2005-04-22 2006-10-26 Telefonaktiebolaget L M Ericsson (Publ) Mobility support for multihome nodes

Also Published As

Publication number Publication date
US20110116450A1 (en) 2011-05-19
WO2010010695A1 (ja) 2010-01-28
JPWO2010010695A1 (ja) 2012-01-05
US8619629B2 (en) 2013-12-31

Similar Documents

Publication Publication Date Title
JP5371987B2 (ja) 移動端末及びネットワークノード
US9654444B1 (en) Communication control method, communication node, and mobile node
JP5072864B2 (ja) 通信システム及びドメイン管理装置
US20120063428A1 (en) Interface Switching System, Mobile Node, Proxy Node, and Mobile Management Node
EP2107726A1 (en) Communication method, communication system, mobile node, proxy node, and management node
US20100103876A1 (en) Mobile terminal and communication management device
EP2207391A1 (en) Mobile terminal, network node, and packet transfer management node
WO2009116246A1 (ja) 通信方法、通信システム、モバイルノード及びアクセスルータ
US8761119B2 (en) Handover method, and mobile terminal and home agent used in the method
US9148826B2 (en) Handover method and mobile terminal and home agent used in the method
US20100014464A1 (en) Communication method, communication system, home agent, and mobile node
JPWO2009054127A1 (ja) 通信システム及び移動端末並びにネットワークノード
KR20090049130A (ko) 프락시 모바일 IPv6에서 패킷 손실을 줄이기 위한 패킷버퍼링 장치 및 방법
JP2010502036A (ja) 複数のアドレスを登録する際にアドレスを検証するための方法及び装置
Bansal et al. Dual stack implementation of mobile IPv6 software architecture
JP2006261902A (ja) アドホックネットワークにおけるアドホックルータの移動管理方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20120614

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20130827

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20130917

R150 Certificate of patent or registration of utility model

Ref document number: 5371987

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313113

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees