JP2006080930A - 通信システム、サーバ、ルータ、及び移動体端末 - Google Patents

通信システム、サーバ、ルータ、及び移動体端末 Download PDF

Info

Publication number
JP2006080930A
JP2006080930A JP2004263190A JP2004263190A JP2006080930A JP 2006080930 A JP2006080930 A JP 2006080930A JP 2004263190 A JP2004263190 A JP 2004263190A JP 2004263190 A JP2004263190 A JP 2004263190A JP 2006080930 A JP2006080930 A JP 2006080930A
Authority
JP
Japan
Prior art keywords
terminal
router
network
information
packet
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.)
Pending
Application number
JP2004263190A
Other languages
English (en)
Inventor
Takehiro Morishige
健洋 森重
Takeshi Ono
豪 小野
Kenichiro Tomizawa
健一郎 富澤
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.)
Hitachi Communication Technologies Ltd
Original Assignee
Hitachi Communication Technologies 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 Hitachi Communication Technologies Ltd filed Critical Hitachi Communication Technologies Ltd
Priority to JP2004263190A priority Critical patent/JP2006080930A/ja
Priority to CNA2005100055043A priority patent/CN1747471A/zh
Priority to US11/040,013 priority patent/US7406064B2/en
Publication of JP2006080930A publication Critical patent/JP2006080930A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W48/00Access restriction; Network selection; Access point selection
    • H04W48/17Selecting a data network PoA [Point of Attachment]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W36/00Hand-off or reselection arrangements
    • H04W36/08Reselecting an access point
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W80/00Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/04Network layer protocols, e.g. mobile IP [Internet Protocol]

Abstract

【課題】移動端末は,移動先で新たにルータ広告を受信するまで移動検知および新しいCoA生成を行う契機がなく,ホームエージェントに対しても位置登録を行えないため,移動に伴うパケットロスが多いという問題があった。
【解決手段】本発明は,アクセスルータ装置に近隣アクセスルータ装置のネットワーク情報を自動収集する手段と,ルータ広告内に隣接するアクセスルータ装置の情報を少なくとも1つ以上含めて送信する手段を具備する。また,移動端末は次の移動先となりえるアクセスルータ装置を選択し,HAに対して事前に位置登録を行う手段を要することを最も主要な特徴とする。
【選択図】図6

Description

本発明は,移動体通信において,移動端末の移動に伴うパケットロスを防止する方式に関する。特に移動端末がMobile IPプロトコルを用いて移動通信を行う際の移動検知方法とそれを実現するために用いられるアクセスルータのルータ広告配信方法に関する。
近年移動体通信網のIP(Internet Protocol)化の検討が活発化している。
IETF(Internet Engineering Task Force)は,Mobile IPv6仕様の標準化を進めている。Mobile IPv6の網構成要素は,移動ノード(Mobile Node,以下MNで表す),ホームエージェント(Home Agent,以下HAで表す),通信相手ノード(Correspondent Node,以下CNで表す)とアクセスルータ(Access Router,以下ARで表す)である。
Mobile IPv6の基本的動作を以下で説明する。MN1には,移動しても変わることのない一意のIPアドレス(ホームアドレス,以下HoAで表す)が付与される。そのため,MN上で起動されるアプリケーションは移動しても中断することなく動作が可能である。HoAと同じネットワークプレフィックスを持つ網をホーム網と呼ぶ。MNがホーム網以外の網(在圏網)に移動すると,在圏網において在圏網の通信プロトコルに従うIPアドレスを取得する。このIPアドレスを気付アドレス(Care of Address,以下CoAで表す)と呼ぶ。
MNは,在圏網上に設置されるARから定期的に送信されるルータ広告(Router Advertisement:RA)を受信する。この際,HoAと異なるネットワークプレフィックスを検出することで移動を検知し,CoAを生成する。移動を検知したMNは,ホーム網へ送信されるMN宛のパケットの転送を要求する位置登録要求メッセージ(Binding Update:BU)をHAに送信する。位置登録要求メッセージを受信したHAはMNのホームアドレスと気付アドレスの対応関係(Binding Cache)を作成する。その後,HAは位置登録応答メッセージ(Binding Ack:BA)をMNに送信し,在圏網に移動しているMN宛のパケットを代理受信するためのパケット捕捉メッセージ(Gratuitous Neighbor Advertisement:G−NA)をブロードキャストしてMNのプロキシとして動作する。CNはMNの通信相手ノードである。CNはMNのHoA宛にパケットを送信する。HAは上記MNのHoA宛パケットを代理受信する。HAはBinding Cacheを検索し,MNのHoAに対応するCoAを取得する。HAは受信したオリジナルパケットに該当CoA宛のIPヘッダを付加(カプセル化)して送信する。MNはCoA宛のカプセル化ヘッダを除去(デカプセル化)し,オリジナルパケットであるCNがMNのHoA宛に送信したパケットを受信することができる。
しかし,上記の従来技術では,MNは移動先の在圏網に設置されるARからのルータ広告を受信するまで,移動端末は移動の判別ができない。また,それに伴って新しいCoAの生成および位置登録メッセージ交換も完了しないため,この間CNからのパケットを受信不可能であった。
D. Johnson他,「Mobility Support in IPv6」IETF 2003年,http://www.ietf.org/internet-drafts/draft-ietf-MobileIP-IPv6-24.txt
上記従来技術のハンドオーバに対する課題を説明する。図1に示すように
Mobile IPv6におけるハンドオーバ完了に必要な時間10は,無線リンクセットアップ11とRAを受信してCoAを生成するまでの時間12と位置登録が完了するまでの時間13に大別できる。ハンドオーバを効率化するためには,CoA生成12時間と位置登録完了時間13を短縮することが有効である。
しかし,従来技術では在圏網に設置されるアクセスルータが送信するルータ広告内には,アクセスルータ自身のネットワーク情報しか含まれていないため,移動端末は移動先で新たにルータ広告を受信するまで移動検知および新しいCoA生成を行う契機がなく,ホームエージェントに対しても位置登録を行えず,ハンドオーバ時間の短縮が困難となっていた。これに伴って,従来技術では移動端末の移動に伴うパケットロスが多いという問題があった。上記問題を解決するためには,移動端末が現在接続中のアクセスルータから次に接続するアクセスルータのネットワーク情報を取得可能とし,移動前に位置登録を完了する必要がある。
本発明は,アクセスルータに近隣アクセスルータのネットワークプレフィックス等の情報を自動収集する手段と,ルータ広告メッセージ内に隣接するアクセスルータの情報を少なくとも1つ以上含めて送信する手段を具備する。また,移動端末は受信したルータ広告から次の移動先となりえるアクセスルータを選択して事前に位置登録を行う手段を要することを最も主要な特徴とする。
本発明の移動端末は移動先のネットワーク情報を移動前に取得することが可能となる。これによって,事前に位置登録を行うことが可能になるため,移動後のパケットロスを防止できるという利点がある。
また,アクセスルータは自動で近隣アクセスルータの情報を収集するため,管理者のアクセスルータ増減設に伴う設定等の管理を簡素化できる利点がある。
本発明の実施の形態について図面を用いて説明する。本発明では2つの実施形態がある。形態の差異は,移動端末のネットワーク接続方法であり,それぞれ図2a,図2bにネットワーク構成図を示す。
実施例1のネットワーク構成を示す図2aにおいて,各装置が接続されるネットワークは全てIPネットワークで構成する。MN1のホーム網5aには,MN1宛のパケットの転送処理を行うHA3と,MN1の通信相手となるCN4を接続する。MN1が移動先で接続する無線ネットワークである在圏網5c,5d,5e)とホーム網5aの間には,パケット中継網5bがある。ルータ6はホーム網5aとパケット中継網5bの境界に設置し,アクセスルータ(2a,2b,2c)は,パケット中継網5bとMN1が移動先で接続する在圏網(5c,5d,5e)の境界に設置する。MN1は,AR(2a,2b,2c)に接続されるアクセスポイント(以降APと呼ぶ)を経由して在圏網にIP接続する。
実施例2のネットワーク構成を示す図2bにおいて,各ネットワークに接続する装置は,実施例1と同様である。実施例2では,MN1は移動先で接続する在圏網(5f,5g,5h)からAR(2a,2b,2c)に接続されるAPを経由してAR(2a,2b,2c)にPPP(Point to Point Protocol)を用いて接続した後,該接続上でIP接続を行う。
以降は,本発明において実施の形態に関わらない部分に関して説明する。
図3aは,本発明におけるAR2のハードウェア構成を示した図である。AR2は,少なくとも6つのハードウェアブロックで構成される。以下に各ハードウェアブロックについて説明する。
・IPパケットを送受信する少なくとも2つ以上のIPインタフェース(206a,206b)。
・IPインタフェースを集約するスイッチ205。
・本発明のソフトウェアや本装置の動作を決定する設定ファイル等の情報を格納するハードディスク200。
・本発明のソフトウェアを実行に際して一時的に利用する領域であるメモリ203。
・本装置の制御を司るCPU201。
・本装置に周辺機器を接続する際に利用する拡張インタフェース207。
上記ハードウェアブロックは,全てバス204で接続される。また,本発明では拡張インタフェース207に,AR2の物理的な位置情報を収集することを目的に,GPS受信機208を接続する。ただし,本GPS受信機は,AR2に内蔵する形態でも構わない。また,GPS受信機以外の手段で物理的位置情報を収集して良い。
図3bは,本発明におけるAR2のソフトウェア構成を示した図である。IPパケットがAR2に着信した場合,受信したIPパケットをパケット入出力処理219にて抽出する。パケット入出力処理219は,IPパケットの宛先アドレスを検証し,自宛てである場合はパケット振り分け処理216を行う。そうでない場合は,パケット転送処理217を行う。パケット振り分け処理216は,IPパケットのデータ部を検証し,次に行う処理を選択して適切な処理を行う。パケット転送処理217は,Routingテーブル218を参照し,次のIPパケット転送先を決定し,パケット入出力処理219を経由してIPパケットの転送を行う。
レイヤ2接続管理処理211は,第2の実施形態で必要な処理であり,主にPPPの終端処理や接続管理を司る。経路情報処理212は,ネットワークに接続されるルータ間で図7に例を示すRIPngを代表とするルーティングプロトコルを用いて経路情報を交換する際に利用する。ルータ広告処理213は,AR2から送信する図8に例を示すルータ広告メッセージの配信制御を司る。位置情報管理処理214は,AR2の経度や緯度,高度といった物理的位置情報の収集や管理を司る。本発明では,経路情報処理212とルータ広告処理213と位置情報管理処理214に特徴があり,図10aに例を示すルータ情報管理テーブル215に各処理で取得した情報を格納する。またAR2は,ルータ情報管理テーブル215を参照することでIPパケットに格納する情報の操作やAR2が実施する処理内容の決定を行う。
図4aは,本発明における移動端末であるMN1のハードウェア構成を示した図である。以下に各ハードウェアブロックについて説明する。
・IPパケットを送受信する少なくとも1つ以上のIPインタフェース106。
・IPパケットを送受信する少なくとも1つ以上の無線インタフェース107。
・IPインタフェースを集約するスイッチ105。
・本発明のソフトウェアや本装置の動作を決定する設定ファイル等の情報を格納するハードディスク100。
・本発明のソフトウェアを実行に際して一時的に利用する領域であるメモリ103。
・本装置の制御を司るCPU101。
・本装置に周辺機器を接続する際に利用する拡張インタフェース108。
上記ハードウェアブロックは,全てバス104で接続される。また,本発明では拡張インタフェース108に,MN1の物理的な位置情報を収集することを目的に,GPS受信機109を接続する。ただし,本GPS受信機は,MN1に内蔵する構成でも構わない。また,GPS受信機以外の手段で物理的位置情報を収集して良い。また,ハードディスク100に格納する情報をメモリ103に格納する形態により,ハードディスク100を具備しない構成でもかまわない。
図4bは,本発明におけるMN1のソフトウェア構成を示した図である。IPパケットがMN1に着信した場合,受信したIPパケットをパケット入出力処理121にて抽出する。パケット入出力処理121は,IPパケットの宛先アドレスを検証し,自宛てである場合はパケット振り分け処理118を行う。そうでない場合は,パケット転送処理119を行う。パケット振り分け処理118は,IPパケットのデータ部を検証し,次に行う処理を選択して適切な処理を行う。パケット転送処理119は,Routingテーブル120を参照し,次のIPパケット転送先を決定し,パケット入出力処理121を経由してIPパケットの転送を行う。L2接続管理処理111は,第2の実施形態においてAR2にPPP接続を行うために必要となる。位置情報管理処理112は,MN1の経度や緯度,高度といった物理的位置情報の収集や管理を司り,取得した情報を図10aに例を示すルータ情報管理テーブル116や図10bに例を示す端末情報管理テーブル115に格納する。ルータ広告処理113は,AR2から送信される図8に例を示すルータ広告メッセージの受信とMN1の移動検知制御を司り,取得した情報をルータ情報管理テーブル116および端末情報管理テーブル115に格納する。Mobile IP処理114は,図9に例を示すMobile IPv6位置登録要求メッセージを用いた位置登録処理やIPカプセル化転送を司り,Mobile IPに関連するHoAやCoA等の情報を図11aに例を示すBinding Update管理テーブルにて管理する。
図5aは,本発明におけるHA3およびCN4のハードウェア構成を示した図である。HA3およびCN4は,少なくとも6つのハードウェアブロックで構成される。以下に各ハードウェアブロックについて説明する。
・IPパケットを送受信する少なくとも2つ以上のIPインタフェース(306a,306b)。
・IPインタフェースを集約するスイッチ305。
・本発明のソフトウェアや本装置の動作を決定する設定ファイル等の情報を格納するハードディスク300。
・本発明のソフトウェアを実行に際して一時的に利用する領域であるメモリ303。
・本装置の制御を司るCPU301。
・本装置に周辺機器を接続する際に利用する拡張インタフェース308。
上記ハードウェアブロックは,全てバス304で接続される。また,本発明では拡張インタフェース208に,HA3およびCN4の物理的な位置情報を収集することを目的に,GPS受信機309を接続する。ただし,本GPS受信機は,HA3およびCN4に内蔵する形態でも構わない。また,GPS受信機以外の手段で物理的位置情報を収集して良い。
図5bは,本発明におけるHA3およびCN4のソフトウェア構成を示した図である。IPパケットがHA3およびCN4に着信した場合,受信したIPパケットをパケット入出力処理317にて抽出する。パケット入出力処理317は,IPパケットの宛先アドレスを検証し,自宛てである場合はパケット振り分け処理314を行う。そうでない場合は,パケット転送処理315を行う。パケット振り分け処理314は,IPパケットのデータ部を検証し,次に行う処理を選択して適切な処理を行う。パケット転送処理315は,Routingテーブル316を参照し,次のIPパケット転送先を決定し,パケット入出力処理317を経由してIPパケットの転送を行う。Mobile IP処理312は,図9に例を示すMobile IPv6位置登録要求メッセージを用いた位置登録の受信処理やIPカプセル化転送を司り,Mobile IPに関連するHoAやCoA等の情報を図11bに例を示すBinding Cache管理テーブルにて管理する。
以下より本発明における移動体通信の動作手順を詳細に説明する。代表例として図2aにおけるMN1がAR−2(2b)配下の在圏網5dからAR−3(2c)配下の在圏網5eに移動しながら,ホーム網5aに設置されるCN4と通信を行う動作手順を図6に示す。
図中MN1とAR(2a,2b,2c)は,自身の経路情報と物理的位置情報を保持する手段を具備する。
ここで図10aを例にして経路情報を格納するルータ情報管理テーブル(116,215)を説明する。ルータ情報管理テーブル(116,215)は,ネットワークプレフィックス801とそのプレフィックス長802と,ゲートウェイアドレス803を格納する。これらの情報によってIPパケットの送信または転送を行う際に,IPパケットに含まれる宛先アドレスに対してどのゲートウェイに送信するかを決定する。また,近隣フラグ804は,ネットワークプレフィックス801がAR2またはMN1自身が所属するネットワークであるかを判定するフラグである。本フラグが「0」の場合は,AR2またはMN1自身が所属するネットワークの情報であることを示し,「1」の場合は,ルーティングプロトコルや手動設定で得たネットワークの情報であると判定する。ARフラグ805は,ネットワークプレフィックス801のネットワークがMN1に対してARとして通知可能であるかを判定するフラグである。
本フラグが「0」の場合は,ネットワークプレフィックス801は中継網5bもしくはホーム網5aに所属するネットワーク情報であることを示し,「1」の場合は,MN1の在圏網(5c,5d,5e)に所属するネットワークの情報であることを示す。経度806,緯度807,高度808は,ネットワークプレフィックス801に所属するAR2の物理的な位置情報を示し,ホップ数809は,ネットワークプレフィックス801がいくつのルータを経由して到達可能であるかを示す数値である。参照フラグ810は,ルータ情報管理テーブル(116,215)を参照して動作の制御を決定する際に,重複して参照することを防止するために利用される。以上801から810を1つのレコード800とし複数レコードを格納する。
次に,図10bを例に用いて,物理的位置情報を格納する端末情報管理テーブル115を説明する。端末情報管理テーブル115は,MN1のホームアドレス821と現在使用中のCoAリスト822と在圏網で接続中のAR2のネットワークプレフィックス823とMN1が存在する現在の物理的位置情報である経度824,緯度825,高度826を1つのレコード820として格納している。なお,CoAリスト822は,IPパケット送信時に使用するCoAの優先度順にリスト構造827となっている。
図6に戻り,移動体通信の動作手順の説明を続ける。図中MN1はまずAR−1(2a)に接続する。第2の形態で接続する場合は,無線リンクのセットアップ後,PPPセッションのセットアップを行う(S20)。第1の形態の場合は,直接AR−1(2a)にIP接続を行う。
AR(2a,2b,2c)は,RIPngを代表とするルーティングプロトコルを用いて,それぞれAR2が保持している経路情報を交換する(S30)。本発明では,図7に例を示すRIPngメッセージフォーマットにより経路情報を送信する(F4)。図7に示すRIPngメッセージフォーマットは,IETF RFC2080「RIPng for IPv6」に規定されるフォーマットのルートテーブルエントリ領域515内にAR2の物理的位置情報領域516を追加する。物理的位置情報領域516には,IPv6プレフィックス502に属するAR2の経度506,緯度507,高度508とARフラグ510およびホップ数511が含まれる。
ここで,図7と図12を例に用いてAR2(2b,2c)が行っているRIPngメッセージの送信処理(F4)に関して説明する。まず図7に示すRIPngメッセージフォーマットの生成を行う(600)。次に,ルータ情報管理テーブル215を参照し,1レコード毎の抽出を行う(601)。レコードの抽出ができた場合(602),ルートテーブルエントリ領域515の追加を行った後(603),レコード内のネットワークプレフィックス801やARフラグ805や経度806,緯度807等を抽出して(604)ルートテーブルエントリ領域515の該当領域への書き込みを行う(605)。その後,再度ルータ情報管理テーブル215から1レコード毎の抽出(601)を繰り返すことでAR2(2b,2c)が保持している経路情報がRIPngメッセージフォーマットに展開される。ルータ情報管理テーブル215から抽出するレコードが無くなった時点でRIPngメッセージが完成し,AR2(2b,2c)は,近隣のAR2(2a)に対して生成したRIPngメッセージを送信する(606)。
次に図6に戻り,AR2(2a)においてAR2(2b,2c)が送信したRIPngメッセージ(S30)の受信処理(F5)に関して図7と図13を例に用いて説明する。まず図7に示すRIPngメッセージの受信後(610),該ルートテーブルエントリ領域515の存在確認を行う(611)。ルートテーブルエントリ領域515が存在する場合,該エントリのIPv6プレフィックス502等の各項目を抽出する(613)。次に,ルータ情報管理テーブル215を参照し(614),抽出した項目に一致するレコードが存在するかを確認する(615)。この時,一致するレコードが存在する場合は,ルータ情報管理テーブル215の更新を行った後(616),次のルートテーブルエントリ領域515の存在確認を行う。一致するレコードが存在しない場合は,新規にルータ情報管理テーブル215へ追加で書き込みを行い(617),同時にパケット転送時に必要な経路情報として,図3bに示すパケット転送処理217のルーティングテーブル218に追加書込みを行う(618)。以降,RIPngメッセージに含まれるルートテーブルエントリ領域515を全て抽出することで,近隣のAR2(2b,2c)が保持している経路情報をAR2(2a)のルータ情報管理テーブル215に展開することができる。
以上のようにAR2(2a,2b,2c)は,ルーティングプロトコルを用いて各々が保持する経路情報と物理的位置情報を自動的に収集可能となる。
図6に戻り,移動体通信の動作手順の説明を続ける。通常AR−1(2a)は,MN1が接続する在圏網(5c,5d,5e)に対して,AR2自身が在圏網(5c,5d,5e)に接続するネットワークインタフェースからルータ広告を送信する(S31)。これによって,在圏網(5c,5d,5e)に移動してきたMN1は,移動検知と在圏網(5c,5d,5e)で有効なCoAの生成が可能となる。本発明では,図8に示すようなルータ広告をAR2(2a)から送信することを特徴とする。図8に示すルータ広告メッセージは,IETF「Mobility Support in IPv6」に規定されるフォーマットのPrefix Information Option領域530にAR2の物理的位置情報領域540を追加する。
また,Prefix Information Option領域530に含まれるPrefix532は,AR2自身が所属するネットワーク情報であるか,近隣のネットワーク情報であるかを示すNビット531を追加する。物理的位置情報領域540には,Prefix532に接続しているAR2の物理的位置情報として,経度541,緯度542と高度543を含む。なお,Prefix Information Option領域530は,ルータ広告メッセージ内に複数格納することが可能である。しかし,IPパケットの最大長の範囲内にルータ広告メッセージを収容必要があるため,本発明では,Prefix Information Option領域530の格納数に制限を設ける。制限値の設定方法は,IPパケットの最大長に達しない限り追加する方法や保守者の静的な設定で制限を設ける方法もある。MN1のハンドオーバの効率化を考慮する場合,少なくともAR2(2a)が最も隣接するAR2(2b,2c)とAR2(2a)自身のネットワーク情報の3つを送信することが望ましい。
ここで,図14を用いてAR−1(2a)が送信するルータ広告メッセージの送信処理(F6)に関して説明する。まず図8に示すルータ広告メッセージフォーマットの生成を行う620。次に,図10aに示すルータ情報管理テーブル215を参照し(621),近隣フラグ804が「0」であるレコードを抽出した後,Prefix Information Option領域530の各領域に展開する(622)。この時,Nビット531を「0」に設定し,AR2(2a)自身が所属するネットワーク情報であることを明示する。次に,ルータ情報管理テーブル215に格納される隣接AR2(2b,2c)のネットワーク情報をPrefix Information Option領域530に格納する。本処理は,ルータ情報管理テーブル215から1レコード毎に抽出し最終レコードまで抽出する(623)。さらに,レコードが存在する場合,まず近隣フラグ804が「1」かつARフラグ805が「1」であるかを確認する(626)。
本条件に一致しない場合は,MN1に対して有効なネットワーク情報でないと判定し,次のレコード抽出に移行する。条件に一致した場合,ルータ情報管理テーブル215のレコードから経度806,緯度807,高度808を抽出し,既に格納済みであるPrefix Information Option領域530の経度541,緯度542,高度543と比較する(627)。この時,何れのPrefix Information Option領域530の情報より遠方にある場合は,Prefix Information Option領域530の格納数制限を確認し(629),限界の場合は次のレコード抽出に移行する。格納可能である場合は,新規にPrefix Information Option領域530の追加書き込みを行う。一方,格納済みの位置情報より近隣であると判定した場合(628),Prefix Information Option領域530の格納数制限を確認し(631),格納可能である場合は,新規にPrefix Information Option領域530の追加書き込みを行う(633)。限界の場合は,最も遠方であるレコードと入れ替えて書き込みを行う(632)。以上の動作を繰り返すことでAR2(2a)が送信するルータ広告メッセージが最適に作成できる。ルータ情報管理テーブル215の全てレコードを確認した後,作成したルータ広告メッセージを送信する(624)。
以上の結果,AR2は,自身が送信するルータ広告内に最も近隣のARが接続する在圏網側のネットワーク情報を選択してMN1に送信することが可能になる。
次に図6に戻り,MN1においてAR2(2a)が送信したルータ広告メッセージ(S31)の受信処理(F7)に関して図15と図16を例に用いて説明する。まずMN1は,図8に示すルータ広告を受信する(640)。次に受信したルータ広告メッセージ内に,Prefix Information Option領域530が存在するかを確認する(641)。存在する場合,Prefix Information Option領域530に含まれる情報を抽出する(642)。次に,ルータ情報管理テーブル116を参照し,抽出した情報と比較していく(643)。
まず,Prefix Information Option領域530内のNビット531が「0」であるかを判定する(644)。この時,Nビット531が「0」である場合,該Prefix Information Option領域530に格納されたネットワーク情報は,現在MN1が移動してきた在圏網5dの情報であることが特定できる。Nビット531が「0」である場合,ルータ情報管理テーブル116内で近隣フラグ804が「0」であるレコードの検索を行い,該レコードのネットワークプレフィックス801とプレフィックス長802と,Prefix Information Option領域530内から抽出したネットワークプレフィックス532とプレフィックス長が一致するかを判定する(645)。
一致する場合は,前回受信したルータ広告と変更が無く,MN1は移動を行っていないと判定できる。この後は,該ルータ情報管理テーブル116のレコードの参照フラグ810に参照したことを記録するため「1」を格納し(651),引き続きPrefix Information Option領域530の抽出を行う。ネットワーク情報が一致しない場合は,MN1が移動して前回と異なる在圏網に移動したことを特定できる。このため,移動検知を行ったことをフラグに格納(646)した後,近隣フラグ804が「0」であったレコードの近隣フラグ804を「1」に変更する(647)。次に,ルータ情報管理テーブル116内で近隣フラグ804が「1」であるレコード内で,Prefix Information Option領域530内から抽出したネットワークプレフィックス532とプレフィックス長が一致するかの判定を行い(649),一致するレコードが存在した場合は,該レコードの近隣フラグ804を「0」に変更し(648),一致するレコードが存在しない場合は,新規にルータ情報管理テーブル116へ追加を行う(650)。その後,追加または近隣フラグ804を「0」に変更したレコードの参照フラグ810に,参照したことを記録するため「1」を格納し(651),引き続きPrefix Information Option領域530の抽出を行う。
一方,Prefix Information Option領域530内のNビット531が「0」であるかを判定した際(644)に,Nビット531が「1」である場合,該Prefix Information Option領域530に格納されたネットワーク情報は,次の移動先の候補となる在圏網5cまたは在圏網5eのネットワーク情報であることが特定できる。この場合,ルータ情報管理テーブル116内の近隣フラグ804が「1」であるレコード内で,Prefix Information Option領域530内から抽出したネットワークプレフィックス532とプレフィックス長が一致するかの判定を行い(649),一致するレコードが存在した場合は,該レコードの情報を最新の情報に更新し(648),一致するレコードが存在しない場合は,新規にルータ情報管理テーブル116へ追加を行う(650)。その後,追加または更新したレコードの参照フラグ810に,参照したことを記録するため「1」を格納し(651),引き続きPrefix Information Option領域530の抽出を行う。
この後,抽出できるPrefix Information Option領域530が存在しないと判定した場合(641),前述した,移動検知フラグが立っているかを確認する(652)。移動検知をしなかった場合,ルータ情報管理テーブル116内の参照フラグ810が「0」であるレコードを検索する(653)。該当するレコードは,ルータ広告メッセージ内に存在しなかった情報であるため,ルータ情報管理テーブル116から削除する(654)。また,削除したレコードのネットワークプレフィックス801に一致するCoAは,使用する必要がなくなるため,ネットワークインタフェース(106,107)から削除し,同時に図10bに示す端末情報管理テーブル115内の使用CoAリストからも削除する(656)。
移動検知フラグが立っているかを判定した際(652),移動検知をしていると判定した場合,図16に示すMN1の移動検知処理が実行される(657)。MN1の移動検知処理はCoA生成とホーム網5aに設置されるHA3および経路最適化実施中のCN4への位置登録である。以下より具体的な処理内容を説明する。まず再度ルータ情報管理テーブル116内のレコードを参照する(660)。1レコード毎に抽出し(662),該レコードのネットワークプレフィックス801とプレフィックス長802を元にCoAを生成する(663)。次に,生成したCoAが,既にMN1のネットワークインタフェース(106,107)に設定されているかの確認行う(664)。未設定である場合は,生成したCoAをネットワークインタフェース(106,107)に設定する(665)。
次に,抽出したレコード内の近隣フラグ804が「1」であるかを確認する。近隣フラグ804が「0」である場合,該レコードは,現在MN1が移動してきた在圏網5dの情報であることが特定できるため,該レコード情報で生成したCoAは,最優先で使用される。よって,該レコードから抽出または生成した情報は,図10bに示す端末情報管理テーブル115の使用CoAリスト822の優先度1番目(827a)と接続中ARネットワークプレフィックス823に展開される(667,668)。一方,抽出したレコード内の近隣フラグ804が「1」である場合,該レコードから生成したCoAは,次の移動先の候補となる在圏網5cまたは在圏網5eで有効なIPアドレスであり,端末情報管理テーブル115の使用CoAリスト822には,優先度を判定して格納していく。本処理では,まず端末情報管理テーブル115の経度824,緯度825,高度826からMN1の物理的位置情報を抽出し,端末の移動方向を確認する(669)。
次に,抽出した物理的位置情報と登録済みのCoAが使用可能なAR2の物理的位置情報を比較し(670),MN1の物理的位置情報に近い順にソートして生成したCoA格納する(671)。
ルータ情報管理テーブル116内の全てのレコード抽出からCoAを生成し情報を格納した後,MN1は,HA3および経路最適化中のCN4に対して位置登録要求メッセージを送信する(673)。本処理では,まずIPv6パケットフォーマットのIPv6ヘッダの直後に図9に例を示すMobile IPv6 Binding Updateメッセージを付加したパケットの送信により行われる。本特許では,IETF 「Mobility Support in IPv6」に規定されるMobile IPv6 Binding Updateメッセージフォーマットに対して,Mobility Options領域560に次期CoAに関する情報を格納する領域を新たに追加することに特徴がある。Binding Updateメッセージの生成時,優先度の一番高いCoA(827a)を現在使用中CoAとしてIPv6ヘッダの送信元アドレスに格納する。宛先アドレスはHA3またはCN4のIPアドレスである。
次に,IPv6パケットフォーマットの拡張ヘッダ領域は,図9のIPv6宛先ヘッダ550が格納され,本ヘッダ内のホームアドレスオプション領域に図10bに示すMN1のホームアドレス821が格納される。IPv6 Mobilityヘッダ領域555には,位置登録要求であることを示すMHタイプ556や通知したCoAの有効期間であるLifetime557が格納される。Mobility Options領域560には,端末情報管理テーブル115のCoAリストから優先度が2番目のCoA(827b)を次期CoAとして格納する。また,Mobility Options領域560内のSビット562は,HA3またはCN4がMN1宛のIPパケットを転送する際,現在のCoAと次期CoAの両方に対してIPカプセル化転送を要求するために使用する。MN1は,自身が移動中であるか否かの判定を行い(672),移動中であると判断した場合は,Sビット562に「1」をセットする。また,在圏網に留まって通信を行っている際には,Sビット562に「0」をセットすることで,HA3またはCN4から送信する複製IPパケットを抑制することが可能となる。
以上のようにMN1は,図11aに例を示すBinding Update管理テーブル117を参照し(673),Binding Updateの送信先となるHA3または経路最適化実施中のCN4に対して位置登録要求メッセージの生成および送信を行った後(674), Binding Update管理テーブル117に位置登録の状況を格納する(675)。Binding Update管理テーブル117には,位置登録の送信先IPアドレス831と位置登録要求メッセージに格納したMN1のホームアドレス832,現在CoA833,次期CoA835やCoAの有効期間835やSビットを含む制御フラグ836等が格納される。
Binding Update管理テーブル117の更新後,ルータ情報管理テーブル116内の参照フラグ810が「0」であるレコードを検索する(676)。該当するレコードは,ルータ広告メッセージ内に存在しなかった情報であるため,ルータ情報管理テーブル116から削除する(677)。また,削除したレコードのネットワークプレフィックス801に一致するCoAは,使用する必要がなくなるため,ネットワークインタフェース(106,107)から削除し,同時に図10bに示す端末情報管理テーブル115内の使用CoAリストからも削除する(678)。
以上の結果,MN1はAR2から送信されるルータ広告(S31)の受信を契機に移動検知を行うと共に,次期に移動する在圏網で使用するCoAを生成し,HA3およびCN4に対して双方のCoAを含んだ位置登録要求メッセージを送信(S32)するが可能となる。これによってMN1は,移動を繰り返しおこなってもパケットロスをすることなく通信を継続できる。
次に図6に戻り,HA3および経路最適化を行うCN4においてMN1が送信した位置登録要求メッセージの受信処理(F8)に関して図17を例に用いて説明する。HA3またはCN4は,図9に示す位置登録要求メッセージを受信する(680)。受信後,IPv6ヘッダ領域の送信元アドレスからMN1の現在使用中CoAを抽出する(681)。次に,図9に示すIPv6宛先ヘッダ領域550からMN1のHoAを抽出する(682)。その他Liftime557等の情報を抽出した後(683),Mobility Options領域560に次期CoAオプションが存在するかを確認する(684)。存在する場合は,次期CoA563や制御フラグであるSビット562を抽出する(685)。次に抽出した情報を図11bに示すBinding Cache管理テーブル313に格納していく(686)。本発明では,Binding Cache管理テーブル313にMN1の次期CoAを登録可能であることに特徴がある。格納する際,まず抽出したHoAに一致するレコードがBinding Cache管理テーブル313に存在するかを確認する(687)。存在する場合は,該レコードの現在CoA842や次期CoA843やLifetime844等の更新を行う(688)。一致するレコードが存在しない場合は,新規にBinding Cache管理テーブル313に登録し(689),MN1に対して位置登録応答メッセージを送信する(S33)。
位置登録要求を受諾したHA3はMN1宛のパケットを代理受信し,MN1に転送を行うため,ホーム網5aに対して,MN1のHoAアドレス宛のMACアドレスをHA3のMACアドレスに偽装する不要NAメッセージを送信する(S34)。以降,MN1宛のIPパケットは,HA3で代理受信することが可能となる(S35)。以下よりHA3が行うMN1へのIPパケット転送処理に関して図18を例に示し説明する(F9)。HA3は,CN4がMN1のHoA宛に送信したIPパケットを代理受信する(700)。次に受信したIPパケットの送信先アドレスであるHoAを抽出し(701),図11bに示すBinding Cache管理テーブル313を参照(702)してHoAに一致するHoAが存在するかを確認する(703)。存在しない場合は,HA4では,受信したIPパケットを破棄して終了する(704)。一致するHoAが存在した場合,HA3はMN1にIPパケットのカプセル化転送を行う。
本処理は,まずBinding Cache管理テーブル313からMN1の現在CoA842を抽出する(705)。IPカプセル化転送のため,新規にIPヘッダ領域の送信元アドレスにHA3自身のIPアドレスを格納し,宛先アドレス領域402に抽出したMN1の現在CoAを格納して,IPヘッダを生成する。生成したIPヘッダに受信したIPパケットを付与することでカプセル化パケットが完成する(706)。生成したカプセル化パケットをMN1に転送する(707)。次にHA3は,Binding Cache管理テーブル313からMN1の次期CoA843が登録されているかを確認する(708)。登録されていない場合は,MN1へのパケット転送処理を終了する。次期CoA843が登録されていた場合,さらに制御フラグ845内のSビットに「1」がセットされているかを確認する(709)。Sビットに「1」がセットされている場合,MN1が次期CoAに対してもカプセル化転送を要求していることが特定され,カプセル化転送に必要な時期CoA843を抽出する(710)。前述したカプセル化処理と同様にIPヘッダを新規に作成し,受信したIPパケットを付与してカプセル化パケットを生成する(711)。この時,新規に生成したIPヘッダ領域内の宛先アドレス領域402には,抽出した次期CoA843が格納される。最後に作成したカプセル化パケットをMN1に転送し(712),処理を終了する。
以上のように,HA3はMN1宛のパケットを受信した場合,MN1が登録した現在CoAおよび次期CoAにカプセル化転送を行う(S36,S37)。これによりMN1は,移動先の在圏網5eに移動した直後からIPパケットを受信可能となる。
次に,MN1がHA3からのカプセル化パケット(S36,S37)を受信した場合,通常,MN1はCN4に現在使用中のCoAの通知を行い,以降MN1とCN4間で通信を行う際には,HA3経由でなく,直接通信が可能となる経路最適化処理を実施する。本特許において,MN1はHA3に送信する位置登録メッセージと同様にCN4に送信する位置登録メッセージ内に次期CoAを含むことを特徴とする。この経路最適化処理に関して図19を用いて説明する。MN1は,受信したカプセル化パケットのデカプセル化を行う(720)。
次にBinding Update管理テーブル117の参照を行い(721),オリジナルパケットの送信元アドレスに一致するレコードが存在するかを確認する(722)。存在する場合,既にCN4に対して経路最適化処理が行われていることと判断し本処理を終了する。一致するレコードが存在しない場合,MN1はCN4に現在使用中のCoAを通知するため,経路最適化処理を実施する。まず,位置登録メッセージ送信前にIETF「Mobility Support in IPv6」に規定されるReturn Routability通信を実施する(723,S43)。Return Routability完了後,MN1はHA3への位置登録メッセージ送信処理と同様に,端末情報管理テーブル115を参照し(724),現在CoAと次期CoAを抽出し(725),移動判定を行い(726),位置登録メッセージ生成に必要な情報を抽出する。位置登録メッセージ生成後,CN4に対して送信し(727,S44),Binding Update管理テーブル117を更新後(728),経路最適化処理を終了する。
CN4は,HA3と同様にMN1からの位置登録メッセージの受信処理を行う(F8)。経路最適化処理以降,CN4はMN1へのパケット送信を行う際,MN1の現在CoAと時期CoAに対して直接パケット送信を行う(S46)。CN4がMN1宛にIPパケットを送信する際の処理(F11)に関して,図20を例に説明する。CN4が送信するIPパケットは,まず図5bに示すアプリケーション311で生成される。アプリケーション111が生成したオリジナルパケットのIPヘッダの送信先アドレスには,MN1のHoAが格納され,送信元アドレスにはCN4のIPアドレスが格納される。本パケットはMobile IP処理312へ転送しIPパケットの変換処理を行う。Mobile IP処理312は,送信IPパケットの宛先アドレスを抽出する(730)。
次に,図11bに示すBinding Cache管理テーブル313を参照(731)して宛先アドレスに一致するMN1のHoAが存在するかを確認する(732)。存在しない場合は,送信IPパケットをそのまま送信する。その後,本パケットは,HA経由でMN1に転送される(733)。一致するHoAが存在した場合,MN1とCN4間で経路最適化が実施されていると判断し,Binding Cache管理テーブル313からMN1の現在CoA842を抽出する(734)。抽出した現在CoAはIPヘッダに格納されている送信先アドレス(=HoA)に書き換えを行い,元の送信先アドレスであるHoAは,経路制御拡張ヘッダに格納する(735)。このように,CN4では,自身が送信するIPパケット変換を行って新たに送信IPパケットを生成し,MN1に送信する(736)。
次にCN4は,Binding Cache管理テーブル313からMN1の次期CoA843が登録されているかを確認する(737)。登録されていない場合は,MN1へのパケット転送処理を終了する。次期CoA843が登録されていた場合,さらに制御フラグ845内のSビットに「1」がセットされているかを確認する(738)。Sビットに「1」がセットされている場合,MN1が次期CoAに対してもIPパケット送信を要求していることが特定され,IPパケットに必要な時期CoA843を抽出する(739)。前述したIPパケット変換処理と同様にIPパケットを変換後(740)。IPパケットをMN1に転送し(741),処理を終了する。
以上の結果,MN1とCN4間の経路最適化通信においてもMN1の移動に伴うパケットロス軽減することが可能となる。
次に図6に戻り,MN1はAR−1(2a)からAR−2(2b)配下に移動した際,AR−2(2b)が送信するルータ広告を受信する(S38)。MN1は,上述した移動検知処理や位置登録要求を行う(S39,F7)。HA3も上述した位置登録受信処理(F8)を行った後,MN1へのパケット転送に備える(S40)。
次に,MN1が在圏網からCN4宛にIPパケットを送信する際の処理(F12)に関して,図21を例に説明する。MN1が送信するIPパケットは,まず図4bに示すアプリケーション110で生成される。本パケットはMobile IP処理114に転送されIPカプセル化を行う。Mobile IP処理114は,アプリケーション110が生成したオリジナルパケットを入力する(750)。このオリジナルパケットのIPヘッダの送信元アドレスには,MN1のHoAが格納され,送信先アドレスにはCN4のIPアドレスが格納される。次に,上記オリジナルパケットの送信先アドレスを抽出する(751)。図11aに示すBinding Update管理テーブル117を参照し(752),抽出した送信先アドレスに一致するBU送信先アドレス831が存在するかを確認する(753)。存在しない場合は,送信元アドレスに一致するHoA832が存在するかを確認し(754),存在しない場合は,オリジナルパケットの破棄を行い(755),パケット送信処理を終了する。送信元アドレスに一致するHoA832が存在する場合は,HA4経由での送信と判定する。送信先アドレスに一致するBU送信先アドレス831が存在する場合,CN4と経路最適化が実施されていることを判定し,CN4への送信フラグを立てる(756)。
次に,現在CoA833と次期CoA834を抽出し,(757)。その内,図10bに示す端末情報管理テーブル124の使用CoAリストを参照して(758),優先度の高いCoAを選択する(759)。次にMN1は,オリジナルパケットへの変換処理を実施するため,CN4への送信フラグが立っているかを確認する(760)。ここで,フラグが立っていない場合は,HA3経由での送信処理となるため,前述したカプセル化処理と同様にIPヘッダを新規に作成し,オリジナルIPパケットに付与してカプセル化パケットを生成する(761)。この時,新規に生成したIPヘッダの送信元アドレスには選択したCoAが格納され,宛先アドレスにはHA3のIPアドレスが格納される。最後に生成したカプセル化パケットを送信する(763)。一方,CN4への送信フラグが立っている場合は,CN4への経路最適化送信のため,IPヘッダの変換処理と宛先拡張ヘッダの付与を行う(762)。本処理は選択したCoAをIPヘッダに格納されている送信元アドレス(=HoA)に書き換え,元の送信元アドレスであるHoAは,宛先拡張ヘッダに格納する。その後,変換されたIPパケットを直接CN4へ送信し(763)終了する。
以上の実施の形態から明らかなように,移動端末は,移動直後からパケットの受信が可能となるため,パケット転送遅延やパケットロスの影響を受けやすいリアルタイム通信を円滑に行う用途にも適用できる。また,移動端末が接続しているネットワークの近隣にアクセスルータが存在するかを確認可能となるため,移動端末の利用者は常に通信可能な移動先を選択して移動計画を立てる用途にも適用できる。さらに移動体通信ネットワークの提供者は,アクセスルータの設置状況を容易に把握可能となるため,移動体通信網の構成検討を行う用途にも適用できる。
従来技術であるIETF標準のMobileIPv6のハンドオーバ実施時間の内訳を示した説明図である。 本発明を適用するネットワーク構成を示した説明図である。(実施例1) 本発明を適用するネットワーク構成を示した説明図である。(実施例2) アクセスルータ装置のソフトウェア構成を示した説明図である。 アクセスルータ装置のソフトウェア構成を示した説明図である。 移動端末装置のハード構成を示した説明図である。 移動端末装置のソフトウェア構成を示した説明図である。 ホームエージェントおよび通信相手端末のハード構成を示した説明図である。 ホームエージェントおよび通信相手端末のソフトウェア構成を示した説明図である。 本発明のハンドオーバ方式のシーケンスを示した説明図である。 RIPngメッセージフォーマットを示した説明図である。 IPv6ルータ広告メッセージフォーマットを示した説明図である。 MobileIPv6位置登録要求メッセージフォーマットを示した説明図である。 ルータ情報管理テーブルの構成を示した説明図である。 端末情報管理テーブルの構成を示した説明図である。 Binding Update管理テーブルの構成を示した説明図である。 Binding Cache管理テーブルの構成を示した説明図である。 アクセスルータ装置におけるRIPngメッセージ送信時の処理フローを示した説明図である。 アクセスルータ装置におけるRIPngメッセージ受信時の処理フローを示した説明図である。 アクセスルータ装置におけるルータ広告送信時の処理フローを示した説明図である。 移動端末におけるルータ広告受信時の処理フローを示した説明図である。 移動端末におけるルータ広告受信後の移動検知処理フローを示した説明図である。 ホームエージェントおよび通信相手端末におけるBinding Updateメッセージ受信時の処理フローを示した説明図である。 ホームエージェントにおけるパケット転送時の処理フローを示した説明図である。 移動端末におけるカプセル化パケット受信の処理フローを示した説明図である。 通信相手端末における経路最適化後のパケット送信時処理フローを示した説明図である。 移動端末におけるパケット送信時の処理フローを示した説明図である。
符号の説明
1 移動端末(Mobile Node:MN) ,
2 アクセスルータ(Access Router:AR)
3 ホームエージェント(Home Agent:HA)
4 通信相手端末(Coresponding Node:CN)
5 ネットワーク。

Claims (10)

  1. ネットワークを介して第一及び第二の端末に接続された、サーバ及び複数のパケット転送装置を備えた通信システムであって、
    上記サーバは、
    自サーバが管理する端末の移動先でのアドレスとホーム網でのアドレスの対応を記憶したメモリを有し、
    上記複数のパケット転送装置のうち少なくとも一のパケット転送装置は、
    上記複数のパケット転送装置のうち少なくとも一の他のパケット転送装置が接続するネットワークの情報と、自パケット転送装置が接続するネットワークの情報を上記第一の端末に対して送信する送信部を有し、
    上記第一の端末は、
    上記一のパケット転送装置が接続するネットワークの情報、および上記他のパケット転送装置が接続するネットワークの情報のそれぞれから生成した2つの気付アドレスを上記サーバまたは上記第二の端末に送信する送信部を有し、
    上記2つの気付アドレスを受信した上記サーバまたは上記第二の端末は、
    上記受信した2つの気付アドレスに対して複製した同内容のパケットを送信する送信部を有することを特徴とする通信システム。
  2. 上記一のパケット転送装置が上記第一の端末に対して送信するネットワークの情報はルータ広告であることを特徴とする請求項1記載の通信システム。
  3. 上記第一の端末はMobileIPのモバイルノードであり、上記サーバは該第一の端末のホームエージェントであることを特徴とする請求項1記載の通信システム。
  4. 上記第一の端末は、
    自端末が移動中であるか否かの情報を上記サーバまたは上記第二の端末に送信する送信部を有し、
    上記情報を受信した上記サーバまたは上記第二の端末は、
    上記端末が移動中である場合には、上記2つの気付アドレス宛てに複製した同内容のパケットを送信する送信部を有することを特徴とする請求項1記載の通信システム。
  5. ネットワークを介して端末及び複数のパケット転送装置に接続されたサーバであって、
    自サーバが管理する端末の移動先でのアドレスとホーム網でのアドレスの対応を記憶したメモリと、
    上記端末から、上記複数のパケット転送装置のうち少なくとも二つのパケット転送装置が接続するネットワークの情報から生成された2つの気付アドレスを受信する受信部と、
    上記受信した2つの気付アドレスに対して複製した同内容のパケットを送信する送信部を有するサーバ。
  6. 上記端末はMobileIPのモバイルノードであり、上記サーバは該端末のホームエージェントであることを特徴とする請求項4記載のサーバ。
  7. ネットワークを介して端末及び他のルータに接続されたルータであって、
    自ルータが上記端末から接続可能なルータであることを示すアクセスルータ識別子、自ルータのネットワークプレフィックス、および自ルータの物理的位置情報を、上記他のルータと交換することを特徴とするルータ。
  8. 上記物理的位置情報は経度、緯度および高度であることを特徴とする請求項6記載のルータ。
  9. 上記他のルータから、該他のルータのネットワークプレフィックスおよび物理的位置情報とを受信する受信部と、
    上記自ルータのネットワークプレフィックスおよび物理的位置情報と、上記他のルータのネットワークプレフィックスおよび物理的位置情報とを、ルータ広告に含めて上記端末に送信する送信部とを有する請求項6記載のルータ。
  10. ネットワークを介して、自端末の移動先でのアドレスとホーム網でのアドレスの対応を保持するサーバと、複数のルータに接続された移動体端末であって、
    上記複数のルータのうち少なくとも2つのルータの物理的位置情報およびネットワークプレフィックスを含むルータ広告を受信する受信部と、
    自端末の物理的位置情報および移動方向に基づいて選択された上記複数のルータのうちの2つのルータのネットワークプレフィックスから生成された2つの気付アドレスを上記サーバに送信する送信部とを有する移動体端末。
JP2004263190A 2004-09-10 2004-09-10 通信システム、サーバ、ルータ、及び移動体端末 Pending JP2006080930A (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2004263190A JP2006080930A (ja) 2004-09-10 2004-09-10 通信システム、サーバ、ルータ、及び移動体端末
CNA2005100055043A CN1747471A (zh) 2004-09-10 2005-01-20 通信系统、服务器、路由器及移动体终端
US11/040,013 US7406064B2 (en) 2004-09-10 2005-01-24 Communication system, server, router, and mobile communications terminal

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2004263190A JP2006080930A (ja) 2004-09-10 2004-09-10 通信システム、サーバ、ルータ、及び移動体端末

Publications (1)

Publication Number Publication Date
JP2006080930A true JP2006080930A (ja) 2006-03-23

Family

ID=36033809

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2004263190A Pending JP2006080930A (ja) 2004-09-10 2004-09-10 通信システム、サーバ、ルータ、及び移動体端末

Country Status (3)

Country Link
US (1) US7406064B2 (ja)
JP (1) JP2006080930A (ja)
CN (1) CN1747471A (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010016336A1 (ja) * 2008-08-07 2010-02-11 日本電気株式会社 通信システム、接続装置、情報通知方法、プログラム
JP2010534968A (ja) * 2007-07-26 2010-11-11 サムスン エレクトロニクス カンパニー リミテッド 情報サーバの位置検索方法及び装置、そして情報サーバの位置を利用したハンドオーバー情報受信方法及び装置
WO2016084959A1 (ja) * 2014-11-28 2016-06-02 アイコム株式会社 端末装置、端末設定システム、端末設定プログラムおよび端末設定方法

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100552471B1 (ko) * 2003-10-13 2006-02-15 삼성전자주식회사 무선네트워크에서 억세스포인트를 이용하여 CoA를 미리예약하고 라우팅을 하여 빠른 핸드오프를 수행하는 방법
EP3713264A1 (en) 2005-03-31 2020-09-23 Sun Patent Trust Communication control method, communication node, and mobile node
US7778229B2 (en) * 2005-07-29 2010-08-17 Cisco Technology, Inc. Optimized IP address use in a mobile IP environment
KR100739803B1 (ko) * 2006-04-21 2007-07-13 삼성전자주식회사 이동 노드에서의 핸드오버 장치 및 방법
CN101047674A (zh) * 2006-05-25 2007-10-03 华为技术有限公司 一种收集接入路由器信息的方法及其系统
US20080013539A1 (en) * 2006-06-23 2008-01-17 Nokia Corporation Dynamic radio interface grouping
US8644247B2 (en) * 2006-10-12 2014-02-04 Telefonaktiebolaget L M Ericsson (Publ) Inter-system handoffs in multi-access environments
EP1947819A1 (en) * 2007-01-18 2008-07-23 Matsushita Electric Industrial Co., Ltd. Header reduction of data packets by route optimization procedure
KR100905218B1 (ko) * 2007-04-09 2009-07-01 삼성전자주식회사 애드혹 네트워크에서 콘텐츠 중복 검출 방법
US8045558B2 (en) 2007-04-23 2011-10-25 Cisco Technology, Inc. Extensions to IPv6 neighbor discovery protocol for automated prefix delegation
US8065515B2 (en) * 2007-04-23 2011-11-22 Cisco Technology, Inc. Autoconfigured prefix delegation based on distributed hash
CN101316222B (zh) * 2007-05-29 2013-04-17 华为技术有限公司 移动性管理实体、通信系统及移动ip的路由优化方法
CN101534241B (zh) * 2008-03-14 2012-07-04 华为技术有限公司 一种减轻网络流量的方法、系统及一种会话控制单元
US10558948B2 (en) * 2008-09-15 2020-02-11 Oath Inc. Targeted instant messenger behaviors employed for optimization of a client
TWI381679B (zh) * 2009-02-05 2013-01-01 Handlink Technologies Inc 無線網路架構、無線網路基地台及其通訊方法
JP5366579B2 (ja) * 2009-02-09 2013-12-11 キヤノン株式会社 通信システム、通信装置、その処理方法及びプログラム
US8644189B1 (en) * 2010-02-17 2014-02-04 Sprint Communications Company L.P. Wireless communication device that transmits geographic location information in router advertisement acknowledgement messages
JP5621510B2 (ja) * 2010-10-29 2014-11-12 日本電気株式会社 モバイルルータ情報管理サーバ、モバイルルータ、モバイルルータネットワーク、及びこれらの通信方法
US20140241173A1 (en) * 2012-05-16 2014-08-28 Erik J. Knight Method for routing data over a telecommunications network
CN102905247B (zh) * 2012-10-09 2014-09-10 常熟理工学院 一种基于IPv6的城市车载网移动切换方法
FR3026588A1 (fr) * 2014-09-30 2016-04-01 Orange Technique de determination d'une presence d'un dispositif peripherique dans une zone de service d'un reseau local
CN106658479B (zh) * 2016-11-16 2020-12-11 广东新岸线科技有限公司 一种无线网络融合的实现方法

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7623497B2 (en) * 2002-04-15 2009-11-24 Qualcomm, Incorporated Methods and apparatus for extending mobile IP
JP2004282172A (ja) * 2003-03-12 2004-10-07 Ntt Docomo Inc 移動通信システム、移動通信方法、サーバ装置、転送装置及び移動通信端末
US7120136B2 (en) * 2004-04-26 2006-10-10 Motorola, Inc. Mobile station mobility in a wireless LAN

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010534968A (ja) * 2007-07-26 2010-11-11 サムスン エレクトロニクス カンパニー リミテッド 情報サーバの位置検索方法及び装置、そして情報サーバの位置を利用したハンドオーバー情報受信方法及び装置
WO2010016336A1 (ja) * 2008-08-07 2010-02-11 日本電気株式会社 通信システム、接続装置、情報通知方法、プログラム
JP2010041592A (ja) * 2008-08-07 2010-02-18 Nec Corp 通信システム、接続装置、情報通知方法、プログラム
CN102100102A (zh) * 2008-08-07 2011-06-15 日本电气株式会社 通信系统、连接装置、信息通信方法和程序
WO2016084959A1 (ja) * 2014-11-28 2016-06-02 アイコム株式会社 端末装置、端末設定システム、端末設定プログラムおよび端末設定方法
CN106688223A (zh) * 2014-11-28 2017-05-17 艾可慕株式会社 终端装置、终端设定系统、终端设定程序以及终端设定方法
JPWO2016084959A1 (ja) * 2014-11-28 2017-09-07 アイコム株式会社 端末装置、端末設定システム、端末設定プログラムおよび端末設定方法

Also Published As

Publication number Publication date
US20060056369A1 (en) 2006-03-16
CN1747471A (zh) 2006-03-15
US7406064B2 (en) 2008-07-29

Similar Documents

Publication Publication Date Title
US7406064B2 (en) Communication system, server, router, and mobile communications terminal
JP4572476B2 (ja) 通信処理システム、通信処理方法、および通信端末装置、データ転送制御装置、並びにプログラム
CN103442347B (zh) 移动节点、归属代理和重新定向方法
JP3587984B2 (ja) 移動通信システム、パケットゲートウェイ装置、位置情報管理方法、および、位置情報通知方法
JP4289030B2 (ja) 移動管理方法および移動端末
CN100505739C (zh) 互联网协议层中低架空移动率管理协议的方法与系统
CN101601255B (zh) 轻型移动性体系结构
JP4794520B2 (ja) ネットワーク主導型移動管理プロトコルにおける通信経路を最適化するシステム、アクセスゲートウェイ、ホームエージェント、およびプログラム
JP5893554B2 (ja) 位置管理装置、パケットデータネットワークゲートウェイ装置、移動局装置及び位置管理装置の通信方法
JP5709967B2 (ja) アクセスノードの間でハンドオーバを行う方法及びアクセスノード
US8570976B2 (en) Method and system for fast handover in hierarchical mobile IPv6
JP5226202B2 (ja) 無線通信ネットワークにおけるリロケーション制御装置
JP2004129165A (ja) 通信システム、移動端末、転送装置及び通信方法
JP4494853B2 (ja) 移動ノード、移動制御ノード、パケット通信システム、及び移動検出方法
US20100103876A1 (en) Mobile terminal and communication management device
US20070014262A1 (en) Method for handling over a call involving a mobile node in a macromobility situation in an IP communication network using hierarchical routing
JP2009529265A (ja) 動的ルータ広告を使用する高速ハンドオーバのための方法及びシステム
US7187931B2 (en) Handover of mobile node to a new access router
EP1464151B1 (en) Method for supporting mobility in wireless networks
JPWO2006077835A1 (ja) 通信管理方法及び通信管理装置
TWI321929B (ja)
JP2008541516A (ja) IPv6通信相手ノード及び移動IPv6ノード間の通信方法、並びに通信相手ノードプロキシーゲートウエイ
JP2006005607A (ja) ネットワークシステムおよび移動ルータ
JP4803239B2 (ja) 移動管理方法および移動端末
JP3928443B2 (ja) 移動体通信システム

Legal Events

Date Code Title Description
RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20060509

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20070406

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20070406

A711 Notification of change in applicant

Free format text: JAPANESE INTERMEDIATE CODE: A712

Effective date: 20090916

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20091013

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20091020

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20100302