JP2008035248A - 中継装置 - Google Patents

Abstract

【課題】本発明は、移動局がアイドルモードから一度抜けてノーマルモードへ移行しなくても済むようにできる中継装置を提供することを目的とする。
【解決手段】移動局と無線接続する基地局の管理を行う中継装置において、移動局が電力消費を削減しているアイドルモードであることを検知するアイドルモード検知手段と、アイドルモードの移動局に代わって、定期的にリニューアルに必要なメッセージをサーバと送受信してリニューアルを実行するリニューアル実行手段と、移動局がアイドルモードからノーマルモードに復帰後、互いに合っていない移動局とサーバのタイマの値を同期させるタイマ同期手段を有する。
【選択図】図２

Description

本発明は、中継装置に関し、移動局と無線接続する基地局の管理を行う中継装置に関する。

近年、ＷｉＭＡＸ（Ｗｏｒｌｄｗｉｄｅ Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ ｆｏｒ Ｍｉｃｒｏｗａｖｅ Ａｃｃｅｓｓ）という無線通信方式が、ＩＥＥＥ（Ｉｎｓｔｉｔｕｔｅ ｏｆ Ｅｌｅｃｔｒｉｃａｌ ａｎｄ Ｅｌｅｃｔｒｏｎｉｃ Ｅｎｇｉｎｅｅｒｓ；米国電気電子学会）において標準化中である。

ＷｉＭＡＸには、移動しない加入者局（Ｓｕｂｓｃｒｉｂｅｒ Ｓｔａｔｉｏｎ）を対象とした規格であるＩＥＥＥ ８０２．１６ｄ（標準化済み）と、移動する加入者局（以下、移動局という、Ｍｏｂｉｌｅ Ｓｔａｔｉｏｎ；ＭＳ）を対象とした規格であるＩＥＥＥ ８０２．１６ｅ（標準化中）がある。

後者の移動局を対象としたＷｉＭＡＸにおいては、移動局の消費電力削減、移動局と基地局（Ｂａｓｅ Ｓｔａｔｉｏｎ；ＢＳ）間の使用無線リソース削減を目的にアイドルモードをサポートしている。アイドルモード中の移動局では、必要最小限の回路に電力を供給し、それ以外の回路への電力の供給を停止することで、電池をより長く持たせることができる。

アイドルモード中の移動局は、特定の基地局に登録せず、ページンググループ（＝ページングエリア）の全基地局が周期的に送信するブロードキャストメッセージ（Ｐａｇｉｎｇ）を監視し、移動局宛のトラヒックの有無を一定周期毎に確認する。

移動局は、自分宛のトラフィックがあることを確認すると、アイドルモードから抜けてノーマルモードに移行し、特定の基地局に登録し、該特定の基地局とリンクを確立する。リンク確立後、基地局が該移動局宛のトラフィックを該移動局宛へ送信することで、移動局に対する着信（＝呼び出し）を実現する。
一方、移動局は、ＩＥＥＥ ８０２．１６ｅの上位レイヤに位置するＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）通信を行うために、Ｍｏｂｉｌｅ ＩＰ（ＭＩＰ）クライアントを具備するか、若しくは、ＤＨＣＰ（Ｄｙｎａｍｉｃ Ｈｏｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）クライアントを具備する。標準仕様では、どちらを具備しても良いことになっている。

図１は、従来のネットワークの一例の構成図を示す。同図中、移動局１，２は、ＭＩＰクライアント３、若しくは、ＤＨＣＰクライアント４を具備する。ゲートウェイ（Ｇａｔｅｗａｙ；ＧＷ）５は、複数の基地局６，７を管理する中継装置である。ゲートウェイ５は、ＦＡ（Ｆｏｒｅｉｇｎ Ａｇｅｎｔ）１０、ＤＨＣＰリレー１１、ＰＣ／ＬＲ（Ｐａｇｉｎｇ Ｃｏｎｔｒｏｌｌｅｒ／Ｌｏｃａｔｉｏｎ Ｒｅｇｉｓｔｅｒ）１２を具備する。

ＦＡ１０は、ＭＩＰクライアント３を具備する移動局１とホームエージェント（Ｈｏｍｅ Ａｇｅｎｔ：ＨＡ）１３との間で、ＭＩＰレジストレーション／リプライ・メッセージ（ＭＩＰレジストレーションリクエスト／レジストレーションリプライ・メッセージと呼称する場合もある）を仲介する。ＤＨＣＰリレー１１は、ＤＨＣＰクライアント４を具備する移動局２とＤＨＣＰサーバ１４との間で、ＤＨＣＰリクエスト／アクノリッジ・メッセージを仲介する。ＰＣ／ＬＲ１２は、ページング（＝呼び出し）やアイドルを制御するＷｉＭＡＸの標準で定義される機能ブロックである。

図１では、ゲートウェイと基地局が別装置として分離しているが、同一装置内に基地局の機能と、ゲートウェイの機能を具備しても構わない。以降の本発明の説明においても、同様に、同一装置内に基地局の機能と、ゲートウェイの機能を具備しても構わない。

また、図１では、同一装置内にＦＡ１０，ＤＨＣＰリレー１１，ＰＣ／ＬＲ１２が具備されているが、別々の装置に同じ機能を分散して具備しても構わない。以降の本発明の説明においても、同様に、別々の装置に同じ機能を分散して具備しても構わない。

ＭＩＰクライアント３を具備するアイドルモード中の移動局１は、ＭＩＰセッションを維持するため、定期的（Ｌｉｆｅｔｉｍｅ）にＭＩＰレジストレーション（ＭＩＰリニューアル処理）を行う。

ＤＨＣＰクライアント４を具備するアイドルモード中の移動局２は、リースされたアドレスを維持するため、定期的（ｌｅａｓｅ ｔｉｍｅ）にＤＨＣＰリニューアル処理を行う。

この際、アイドルモード中の移動局は、基地局との間にアップリンクのコネクションを確立していないので、ＭＩＰ／ＤＨＣＰリニューアルを行うために必要なアップリンクのトラフィックを送信するために、アイドルモードから抜けて、レンジング等のネットワークエントリエントリ処理を行う必要がある。ネットワークエントリエントリ処理とは、移動局が、上述の特定の基地局に登録し、該特定の基地局との間に、リンクを確立する処理である。

そして、ＭＩＰ／ＤＨＣＰリニューアルを行った後は、移動局は、またすぐに、アイドルモードへ戻ることになる。

上述のＭＩＰ／ＤＨＣＰリニューアルを行うためにアイドルモードから抜ける処理は、ユーザが、必要があって行う通話等に伴って行われる処理ではなく、ＩＰの制御プロトコルの仕様に従った結果、定期的に発生する処理である。

また、ＭＩＰ及びＤＨＣＰに限らず、移動局が、定期的にタイマ更新処理が必要なプロトコルを具備していた場合、同様に発生する処理である。

また、移動局が、定期的にタイマ更新処理が必要なプロトコルを具備していた場合、一般的に、移動局から見て更新対象となるタイマを具備するサーバが、ネットワーク上に存在することになる。図１では、ＨＡ１３，ＤＨＣＰサーバ１４が該サーバに相当する。

ちなみに、このようなことが起こる根本的な原因は、ＩＥＥＥ ８０２．１６ｅの仕様と、ＩＰの仕様が、それぞれ、独立に定義されたためである。

なお、特許文献１には、スリープモードで動作中の端末に伝送するデータがある場合、基地局は、ＴＲＦ＿ＩＮＤメッセージを該当端末にトラフィック情報を伝送して、該当端末をアクティブモードに制御することが記載されている。
特開２００５−２５３０６２号公報

従来の方法では、タイマ更新処理が必要なプロトコルを具備する移動局は、アイドルモード中にリニューアル処理を行うために、アイドルモードから一度抜けて、ノーマルモードへ移行する必要があり、消費電力削減、使用無線リソース削減の観点から不利であるという問題があった。

本発明は、上記の点に鑑みなされたものであり、移動局がアイドルモードから一度抜けてノーマルモードへ移行しなくても済むようにできる中継装置を提供することを目的とする。

本発明の一実施態様による中継装置は、移動局と無線接続する基地局の管理を行う中継装置において、
移動局が電力消費を削減しているアイドルモードであることを検知するアイドルモード検知手段と、
前記アイドルモードの移動局に代わって、定期的にリニューアルに必要なメッセージをサーバと送受信してリニューアルを実行するリニューアル実行手段と、
前記移動局がアイドルモードからノーマルモードに復帰後、互いに合っていない移動局とサーバのタイマの値を同期させるタイマ同期手段を有することにより、移動局がアイドルモードから一度抜けてノーマルモードへ移行しなくても済むようにできる。

前記中継装置において、
アイドルモード中の移動局が定期的に実行するロケーションアップデイトの完了を検知するロケーションアップデイト完了検知手段を有し、
前記リニューアル実行手段は、前記アイドルモードの移動局に代わって、前記ロケーションアップデイト完了検知を契機として前記リニューアルに必要なメッセージを送受信する構成としても良い。

前記中継装置において、
前記移動局がアイドルモードになる前のタイマ値を取得する初期タイマ値取得手段を有し、
前記リニューアル実行手段は、前記タイマ値に基づいて前記リニューアルに必要なメッセージを送受信する構成としても良い。

前記中継装置において、
前記リニューアル実行手段は、前記リニューアルに必要なメッセージとしてＭＩＰレジストレーション／リプライ・メッセージを送受信する構成としても良い。

前記中継装置において、
前記リニューアル実行手段は、前記リニューアルに必要なメッセージとしてバインディングアップデイト／アクノリッジメント・メッセージを送受信する構成としても良い。

前記中継装置において、
前記タイマ同期手段は、前記ＭＩＰレジストレーション／リプライ・メッセージを送受信していたエージェントとはネットワークプリフィックスが異なるエージェントにルータアドバタイズメントの広報を依頼することで、前記移動局とサーバのタイマの値を同期させる構成としても良い。

前記中継装置において、
前記タイマ同期手段は、前記バインディングアップデイト／アクノリッジメント・メッセージを送受信していたアクセスルータとはネットワークプリフィックスが異なるアクセスルータにルータアドバタイズメントの広報を依頼することで、前記移動局とサーバのタイマの値を同期させる構成としても良い。

前記中継装置において、
無線アクセス認証フェーズにおいて、ＭＩＰキーを取得するＭＩＰキー取得手段を有する構成としても良い。

前記中継装置において、
前記ＭＩＰキー取得手段は、ホームエージェントから前記ＭＩＰキーを取得する構成としても良い。

前記中継装置において、
前記ＭＩＰキー取得手段は、ＡＡＡサーバから前記ＭＩＰキーを取得する構成としても良い。

前記中継装置において、
前記リニューアル実行手段は、前記リニューアルに必要なメッセージとしてＤＨＣＰリクエスト／アクノリッジメント・メッセージを送受信する構成としても良い。

前記中継装置において、
前記タイマ同期手段は、前記移動局へリースされていたアドレスとはネットワークプリフィックスが異なるエージェントにルータアドバタイズメントの広報を依頼することで、前記移動局とサーバのタイマの値を同期させる構成としても良い。

前記中継装置において、
前記タイマ同期手段は、前記移動局へリースされていたアドレスとはネットワークプリフィックスが異なるアクセスルータにルータアドバタイズメントの広報を依頼することで、前記移動局とサーバのタイマの値を同期させる構成としても良い。

前記中継装置において、
前記タイマ同期手段は、前記移動局にＤＨＣＰネガティブ・アクノリッジメント・メッセージを送信することで、前記移動局とサーバのタイマの値を同期させる構成としても良い。

前記中継装置において、
前記ロケーションアップデイトのメッセージを拡張して前記リニューアルに必要な情報を搬送する構成としても良い。

前記中継装置において、
前記アイドルモードの移動局がページンググループを跨って移動するとき、前記アイドルモードの移動局に関する情報を移動前の中継装置から移動後の中継装置に移動する構成としても良い。

前記中継装置において、
移動局に対しルータアドバタイズメントを広報し、前記移動局からの応答メッセージの種別に応じて前記移動局の持つクライアントを判別するクライアント判別手段を有する構成としても良い。

本発明によれば、移動局がアイドルモードから一度抜けてノーマルモードへ移行しなくても済むようにでき、移動局の消費電力、及び、使用無線リソースを削減することができる。

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

本発明では、アイドルモード中だけリニューアル処理を代行するアイドル・プロキシ・クライアントをゲートウェイに設けることで、移動局がリニューアル処理を行うために、アイドルモードから一度抜けて、ノーマルモードへ移行しなくても済むようにする。なお、ゲートウェイの機能が、基地局に具備されている場合、アイドル・プロキシ・クライアントは、基地局に具備されることになる。

<本発明のネットワークの構成>
図２は、本発明を適用したネットワークの一実施例の構成図を示す。同図中、移動局２１，２２は、ＭＩＰクライアント２３、若しくは、ＤＨＣＰクライアント２４を具備する。ゲートウェイ（ＧＷ）２５は、複数の基地局２６，２７を管理する中継装置である。ゲートウェイ２５は、ＶＦＡ（Ｖｉｒｔｕａｌ Ｆｏｒｅｉｇｎ Ａｇｅｎｔ）３１，３２、ＤＨＣＰリレー３３、ＰＣ／ＬＲ３４、アイドル・プロキシ・クライアント３５を具備する。

ＶＦＡ３１，３２は、ＭＩＰクライアント２３を具備する移動局２１とホームエージェント（ＨＡ）４０との間で、ＭＩＰレジストレーション／リプライ・メッセージを仲介する。ＤＨＣＰリレー３３は、ＤＨＣＰクライアント２４を具備する移動局２２とＤＨＣＰサーバ４１との間で、ＤＨＣＰリクエスト／アクノリッジ・メッセージを仲介する。ＰＣ／ＬＲ３４は、ページング（＝呼び出し）やアイドルを制御するＷｉＭＡＸの標準で定義される機能ブロックである。なお、ＡＡＡ（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｚａｔｉｏｎ Ａｃｃｏｕｎｔｉｎｇ）サーバ４２は、移動局２１，２２を認証するために必要な情報を保持するサーバである。

アイドル・プロキシ・クライアント（Ｉｄｌｅ Ｐｒｏｘｙ Ｃｌｉｅｎｔ）３５は、移動局がアイドル中に、移動局の代わりにリニューアル処理を行う。アイドル・プロキシ・クライアント３５は、タイマ更新処理が必要なプロトコル毎に、アイドル・プロキシを具備する。図２では、アイドル・プロキシ・クライアント３５は、ＭＩＰリニューアル処理を代行するアイドルＰＭＩＰ（アイドル Ｐｒｏｘｙ Ｍｏｂｉｌｅ ＩＰ クライアント）３６、または／及び、ＤＨＣＰリニューアル処理を代行するアイドルＰＤＨＣＰ（アイドル Ｐｒｏｘｙ ＤＨＣＰ クライアント）３７を具備する。

図３は本発明の中継装置の機能構成図を示す。本発明では、ゲートウェイ２５に設けたアイドル・プロキシ・クライアント３５に、移動局２１，２２がアイドルモードになったこと、及び、アイドルモードから抜けたことを検知するアイドルモード検知手段３５ａと、移動局２１，２２がアイドルモード中、定期的にリニューアルに必要なメッセージをサーバと送受信するリニューアル実行手段３５ｂと、移動局がアイドルモードからノーマルモードへの復帰後、互いに合っていない移動局とサーバのタイマの値を同期させるタイマ同期手段３５ｃを有する。これにより、アイドルモード中だけリニューアル処理を代行する。

アイドル・プロキシ・クライアント３５は、アイドルモードの開始を検知すると、リニューアル処理の代行を開始し、アイドルモードの終了を検知すると、リニューアル処理の代行を終了する。

アイドル・プロキシ・クライアント３５は、移動局２１，２２がアイドルモード中、定期的にリニューアルに必要なメッセージを送受信する。アイドル・プロキシ・クライアント３５は、単純に、アイドルモード中だけリニューアル処理を代行するだけではなく、移動局２１，２２がアイドルモードからノーマルモードへの復帰後、移動局２１，２２とサーバ４０，４１の間のタイマの値を同期させる必要がある。

例えば、アイドルモードに入る前に、移動局２１，２２のタイマ及びサーバ４０，４１のタイマが残り２分を指し示していたとする。アイドルモード中は、移動局２１，２２のタイマは更新されず、アイドル・プロキシ・クライアント３５が移動局２１，２２の代わりにリニューアル処理を行うので、サーバ４０，４１のタイマは何回か更新されることになる。このため、ノーマルモード復帰のタイミングによっては、移動局のタイマは残り２分、サーバのタイマは残り１分を指し示している可能性がある。

このままの状態を放置すると、サーバ４０，４１のタイマが、移動局２１，２２がリニューアル処理を行う前に、タイムアウトしてしまう。そこで、アイドル・プロキシ・クライアント３５は、移動局２１，２２とサーバ４０，４１のタイマの値を同じ値にする同期処理を行う。

<第１実施形態>
図４は、本発明の第１実施形態のシーケンス図を示す。この実施形態は、移動局がＭＩＰクライアントを持つ場合である。同図中、ＡＡＡサーバ４２は移動局２１を認証するために必要な情報を保持する。一般的に移動局２１がネットワークへ参加するときは、移動局２１を認証する必要があるが、該ネットワークの運用方針によっては、全く認証を行わずに、移動局２１をネットワークに参加させても構わない。

第１実施形態では、ＭＩＰリニューアル処理のメッセージであるＭＩＰレジストレーション／リプライを実行するために必要なＭＩＰキーを取得するＭＩＰキー取得手段をゲートウェイが具備する。

なお、該ネットワークの運用方針によって、ＭＩＰレジストレーション／リプライを認証する必要がない場合には、ＭＩＰキーを取得する必要はない。

また、移動局２１がアイドルモードになる前のタイマ値を取得する初期タイマ値取得手段をゲートウェイ２５が具備する。移動局２１がアイドルモードになる前のタイマ値を取得するのは、アイドルモード後にリニューアルに必要なメッセージを代行して送受信するにあたり、アイドル・プロキシ・クライアント３５が、その契機を特定するためである。なお、初期タイマ値の取得は、必須の機能ではない。

また、ノーマルモード復帰後クライアント―サーバ間タイマ同期手段として、新たにゲートウェイにＶＦＡ３１，３２を設け、たとえ、移動局２１が移動していなくても、ネットワークプリフィックスが異なるルータアドバタイズメント（Ｒｏｕｔｅｒ Ａｄｖｅｒｔｉｓｅｍｅｎｔ；ＲＡ）を、新たに設けたＶＦＡ３１，３２が広報することで、該移動局２１に擬似的に移動したかのように認知させ、該移動局２１がタイマ同期処理を行うようにする。

以下、図４のシーケンスに沿って説明する。

ステップ［ａ］アイドル・プロキシ・クライアント３５であるアイドルＰＭＩＰ３６は、ＷｉＭＡＸで定義された無線アクセスの認証フェーズから、ＭＩＰキーを取得する。ＭＩＰキーとは、ＭＩＰルートキー，ＭＮ―ＨＡキー，ＦＡ―ＨＡキー，ＭＮ―ＦＡキーの総称である。ＭＮ（Ｍｏｂｉｌｅ Ｎｏｄｅ）とは、ＭＩＰ仕様における移動局の呼称である。ＭＮ―ＨＡキーは、ＭＩＰレジストレーション／リプライ・メッセージにおいて、ＭＮ―ＨＡ間の認証に必要なキーである。同様に、ＦＡ―ＨＡキーは、ＦＡ―ＨＡ間の認証に必要なキーである。同様に、ＭＮ―ＦＡキーは、ＭＮ―ＦＡ間の認証に必要なキーである。

ＭＮ―ＨＡキー，ＦＡ―ＨＡキー，ＭＮ―ＦＡキーは、ＭＩＰルートキーを基に導出することもできる。ＭＮ―ＨＡキー，ＦＡ―ＨＡキー，ＭＮ―ＦＡキーを個別に取得してもよいし、ＭＩＰルートキーを取得してもよく、ネットワークの運用方針に依存する。

ステップ［ｂ−１］上述のステップ［ａ］の無線アクセスの認証方法は、様々な方法が標準上定義されており、認証方法によっては、ＭＩＰキーが取得できない可能性もある。そこで、ＭＩＰキーが必要であるにも拘らず、ＭＩＰキー、または、ＭＩＰキーの一部が取得できない場合、アイドルＰＭＩＰ３６は、ＨＡ４０からＭＩＰキーを取得する。

アイドルＰＭＩＰ３６が、ＨＡ４０からＭＩＰキーを取得する方法は、アイドルＰＭＩＰ３６がＨＡ４０にＭＩＰキー要求メッセージを送信し、ＨＡ４０がアイドルＰＭＩＰ３６にＭＩＰキー応答メッセージを送信する。ＭＩＰキー要求応答メッセージは、例えば、ＭＩＰの標準仕様を拡張し、新たなイクステンションヘッダのタイプ値を定義して、実現する方法がある。

また、アイドルＰＭＩＰ３６が、ＨＡ４０からＭＩＰキーを取得する際に、アイドルＰＭＩＰ３６―ＨＡ４０間で認証が必要ならば、例えばＭＩＰキーを取得する前に、予めアイドルＰＭＩＰ３６―ＨＡ４０間で、ＩＰＳｅｃ（ＩＰ Ｓｅｃｕｒｉｔｙ Ｐｒｏｔｏｃｏｌ）を確立しておき、ＭＩＰキー要求／応答メッセージは、ＩＰＳｅｃトンネル上で、送受信する方法がある。

なお、本発明では、ＭＩＰキーが取得できれば良いので、ＭＩＰキーの具体的に取得方法を、上述の方法だけに限定するものではない。

ステップ［ｂ−２］上述のステップ［ａ］の無線アクセスの認証方法は、様々な方法が標準上定義されており、認証方法によっては、ＭＩＰキーが取得できない可能性もある。そこで、ＭＩＰキーが必要であるにも拘らず、ＭＩＰキー、または、ＭＩＰキーの一部が取得できない場合、上述のステップ［ｂ−１］とは違う方法として、アイドルＰＭＩＰ３６は、ＡＡＡサーバ４２からＭＩＰキーを取得する。

アイドルＰＭＩＰ３６が、ＡＡＡサーバ４２からＭＩＰキーを取得する方法は、アイドルＰＭＩＰ３６がＡＡＡサーバ４２にＭＩＰキー要求メッセージを送信し、ＡＡＡサーバ４２が、アイドルＰＭＩＰ３６にＭＩＰキー応答メッセージを送信する。ＭＩＰキー要求応答メッセージは、例えば、ＡＡＡサーバ４２にアクセスする標準のプロトコルであるＲＡＤＩＵＳ（Ｒｅｍｏｔｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｄｉａｌ Ｉｎ Ｕｓｅｒ Ｓｅｒｖｉｃｅ）またはＤＩＡＭＥＴＥＲで実現する。

なお、アイドルＰＭＩＰ３６が、ＨＡ４０から取得できなかったＭＩＰキーの一部を、ＡＡＡサーバ４２から取得しても良い。また、逆に、アイドルＰＭＩＰ３６が、ＡＡＡサーバ４２から取得できなかったＭＩＰキーの一部を、ＨＡ４０から取得してもよい。

ステップ［ｃ〜ｄ］ノーマルモード中の移動局２１は、無線アクセス認証後すぐに、及び、移動して別のネットワークに移動した後すぐに、及び、定期的にＭＩＰレジストレーション／リプライ・メッセージを送受信する。このうち、定期的に行うＭＩＰレジストレーション／リプライをＭＩＰリニューアル処理という。無線アクセス認証後すぐに、及び、移動して別のネットワークに移動した後すぐに行うＭＩＰレジストレーション／リプライ・メッセージの送受信も、定期的に行うＭＩＰレジストレーション／リプライ・メッセージの送受信も、同様の処理である。
ＭＩＰの仕様上、ＭＩＰレジストレーション／リプライ・メッセージの送受信を行うたびに、移動局のタイマとＨＡ４０のタイマは、同じ値にリセットすることになる。

ステップ［ｅ］アイドルＰＭＩＰ３６は、移動局がアイドルモードになる前のタイマ値である初期タイマ値を、移動局２１のＭＩＰクライアント２３―ＨＡ４０間のＭＩＰレジストレーション／リプライ・メッセージから得る。ゲートウェイ２５は初期タイマ値取得手段を具備する。

ＭＩＰレジストレーション／リプライ・メッセージには、ライフタイムフィールドがあり、該フィールドより、初期タイマ値を取得することができる。初期タイマ値を取得すると、アイドルＰＭＩＰ３６は、自身が内部に有するタイマの値を該初期タイマ値にセットし、タイマをスタートさせる。

上述のステップ［ｃ〜ｄ］のＭＩＰリニューアル処理は、定期的に行われるので、ＭＩＰレジストレーション／リプライ・メッセージの送受信のたびに、アイドルＰＭＩＰ３６は初期タイマ値を取得し、自身が内部に有するタイマの値を該初期タイマ値にセットし直し、タイマをスタートさせる。

このようにすることで、移動局２１がアイドルモードになった後、アイドルＰＭＩＰ３６が、初めにＭＩＰレジストレーション／リプライ・メッセージを送受信する契機を、タイマの値を基に決定することができる。アイドルＰＭＩＰ３６は、自身が内部に有するタイマがタイムアウトする前に、ＭＩＰレジストレーション／リプライ・メッセージを送受信すればよい。

なお、初期タイマ値の取得は、必須の機能ではない。初期タイマ値を取得していない場合は、移動局２１がアイドルモードになった後、すぐに、アイドルＰＭＩＰ３６は、ＭＩＰレジストレーション／リプライ・メッセージを送受信すれば、ＭＩＰレジストレーション／リプライ・メッセージの送受信総数は増えるものの、少なくとも、ＨＡ４０のタイマがタイムアウトする前に、ＭＩＰリニューアル処理を行うことが可能である。

アイドルＰＭＩＰ３６は、初期タイマ値を取得する、しないに関係なく、ＭＩＰリニューアルを代行する際に、ＭＩＰレジストレーションが送信できるように、ＭＩＰレジストレーションに格納すべき、各種フィールド値を、上述の無線アクセス認証フェーズ、または、上述のステップ［ｃ〜ｄ］のＭＩＰレジストレーション／リプライから得る。

ステップ［ｆ］移動局２１は、アイドルモードへ移行する。アイドルモードへの詳細な移行手順は、ＩＥＥＥ ８０２．１６ｅの標準仕様に定義されている。アイドルモードへの詳細な移行手順は、本発明に直接関係ないので説明は割愛する。

ＰＣ／ＬＲ３４は、アイドルモード中の移動局を管理する。

ステップ［ｇ］ＰＣ／ＬＲ３４は、アイドルモードの開始をアイドルＰＭＩＰ３６に通知する。アイドル・プロキシ・クライアント３５は、アイドルモードの開始をＰＣ／ＬＲ３４からの通知を受信することで検知する。

ステップ［ｈ〜ｉ］アイドルＰＭＩＰ３６は、自身が内部に有するタイマの値を基に、タイマがタイムアウトする前に、ＭＩＰレジストレーション／リプライ・メッセージの送受信を行い、ＭＩＰリニューアル処理を移動局の代わりに代行する。

上述したように、初期タイマ値を取得していた場合は、アイドルＰＭＩＰ３６は、移動局がアイドルモードになった後、初めのＭＩＰレジストレーション／リプライを、自身が内部に有するタイマがタイムアウトする前に行う。初期タイマ値を取得していない場合は、アイドルＰＭＩＰ３６は、移動局がアイドルモードになった後、初めのＭＩＰレジストレーション／リプライを、アイドルモードの開始を受信後、すぐに行う。

ステップ［ｊ］移動局２１は、アイドルモードから抜けてノーマルモードへ移行する。アイドルモードから抜ける詳細な移行手順は、ＩＥＥＥ ８０２．１６ｅの標準仕様に定義されている。アイドルモードから抜ける詳細な移行手順は、本発明に直接関係ないので説明は割愛する。

ステップ［ｋ］ＰＣ／ＬＲ３４は、アイドルモードの終了をアイドルＰＭＩＰ３６へ通知する。アイドル・プロキシ・クライアント３５は、アイドルモードの終了をＰＣ／ＬＲ３４からの通知を受信することで検知する。

なお、図４のシーケンスでは、移動局２１がノーマルモードへ復帰したため、ＰＣ／ＬＲ３４は、アイドルモードの終了を通知するが、アイドルモードの終了は、このノーマルモードへ復帰するケースだけではない。アイドルモード中の移動局２１が、そのまま電源を落とす場合や、同様に、電波が届かない場所へ長時間移動してしまった場合、ノーマルモードへ復帰せずに、ネットワークから離脱することになる。

そのような移動局２１がノーマルモードへ移行しないで、アイドルモードが終了する場合は、アイドルＰＭＩＰ３６は、ＭＩＰリニューアル処理の代行を止め、ルータアドバタイズメントの依頼も行わずに、該当移動局２１の管理を止める。アイドルＰＭＩＰ３６は、ノーマルモードへ移行するアイドルモードの終了なのか、ノーマルモードに移行しないアイドルモードの終了なのかを、ＰＣ／ＬＲ３４からのアイドルモード終了通知に含まれるパラメータから判断する。

ステップ［ｌ］アイドルＰＭＩＰ３６は、アイドルモードに入る前に、移動局２１のＭＩＰレジストレーション／リプライ・メッセージを仲介していたＶＦＡとは別のＶＦＡに、ルータアドバタイズメントの広報を依頼する。

上述のステップ［ｃ〜ｄ］のＭＩＰレジストレーション／リプライ・メッセージは、ＶＦＡ３１が仲介していたので、アイドルＰＭＩＰ３６は、ＶＦＡ３２にルータアドバタイズメントの広報を依頼する。

ステップ［ｍ］ＶＦＡ３２は、ＶＦＡ３１が広報するルータアドバタイズメントが含むネットワークプリフィックスとは異なる、ネットワークプリフィックスを含むルータアドバタイズメントを広報する。ネットワークプリフィックスとは、サブネットワーク毎に定義されるネットワークアドレスである。

一般的に、移動局２１が、それまでのネットワークプリフィックスとは異なるネットワークプリフィックスを広報によって受信するのは、移動局が、移動したことによって、別のネットワークに接続した場合である。標準仕様上、移動局２１は、移動によって別のネットワークに接続したと認知した場合、すぐに、ＭＩＰレジストレーション／リプライ・メッセージを送受信する。ＭＩＰレジストレーション／リプライ・メッセージの送受信を行うと、移動局２１及びＨＡ４０のタイマは同じ値にリセットされる。

本発明では、上述の標準仕様を流用し、移動局２１が移動していなくても、アイドルモードに入る前とは異なるネットワークプリフィックスを含むルータアドバタイズメントを、移動局に広報することにより、該移動局に擬似的に移動したかのように認知させ、該移動局がＭＩＰレジストレーション／リプライ・メッセージによるタイマ同期処理を行うようにする。

このために、ゲートウェイ２５にネットワークプリフィックスが異なるルータアドバタイズメントを広報するＶＦＡ３１，３２を新たに設ける。

なお、ルータアドバタイズメントの広報は、ブロードキャストアドレス、または、マルチキャストアドレスで送信されるので、通常ならば、アイドルモードから抜けた対象の移動局以外の移動局も、該ルータアドバタイズメントを受信してしまう。しかし、標準上、ゲートウェイ２５と該移動局２１間は、Ｐｏｉｎｔ−ｔｏ−Ｐｏｉｎｔのトンネルを張ることができるので、このトンネル上でルータアドバタイズメントを広報することで、他の移動局が該ルータアドバタイズメントを受信しないようにすることができる。

ゲートウェイ２５と移動局２１間にＰｏｉｎｔ−ｔｏ−Ｐｏｉｎｔのトンネルを張ること自体は、特に本発明の特徴ではなく、標準仕様上、定義されていることである。

ステップ［ｎ〜ｏ］移動局２１のＭＩＰクライアント２３は、ネットワークプリフィックスが異なるルータアドバタイズメントを受信したので、ＭＩＰレジストレーション／リプライ・メッセージの送受信を行う。

ステップ［ｐ］アイドルＰＭＩＰ３６は、上述のステップ［ｅ］と同様に、初期タイマ値を取得し、自身が内部に有するタイマの値を、該初期タイマ値にセットし直し、タイマをスタートさせる。この処理はステップ［ｅ］と同様に、必須ではない。

これにより、移動局２１がＭＩＰクライアント２３を具備していた場合、移動局２１が、リニューアル処理を行うために、アイドルモードから一度抜けて、ノーマルモードへ移行しなくても済むようにできる。

図１１（Ａ）はＭＩＰレジストレーション・メッセージのフォーマットを示し、図１１（Ｂ）はＭＩＰリプライ・メッセージのフォーマットを示し、図１１（Ｃ）はＭＩＰレジストレーション／リプライ・メッセージの付加されるイクステンションフィールドのフォーマットを示す。図１１（Ｃ）は様々存在するイクステンションの中で、Ｍｏｂｉｌｅ−Ｈｏｍｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｅｘｔｅｎｓｉｏｎ、Ｍｏｂｉｌｅ−Ｆｏｒｅｉｇｎ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｅｘｔｅｎｓｉｏｎ、Ｆｏｒｅｉｇｎ−Ｈｏｍｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｅｘｔｅｎｓｉｏｎのフォーマットを示している。

これらは、ＩＰヘッダ、ＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）ヘッダに続き、図１１（Ａ）または図１１（Ｂ）のヘッダが続き、更に必要に応じて、図１１（Ｃ）のイクステンションが、一つ、若しくは、複数個、続く。

図１１（Ａ）において、Ｔｙｐｅは１であり、Ｓ／Ｂ／Ｄ／Ｍ／Ｇ／ｒ／Ｔ／ｘは各種フラグであり、Ｌｉｆｅｔｉｍｅは登録が有効な残り時間［秒］である。Ｈｏｍｅ Ａｄｄｒｅｓｓは移動局のＩＰアドレスであり、Ｈｏｍｅ Ａｇｅｎｔ Ａｄｄｒｅｓｓは移動局のホームエージェントのＩＰアドレスである。Ｃａｒｅ−ｏｆ ＡｄｄｒｅｓｓはトンネルのエンドのＩＰアドレスであり、実施形態では、移動局またはＦＡのアドレスとなる。Ｉｄｅｎｔｉｆｉｃａｔｉｏｎはリプライアタックを防御するために設定するＩＤ（識別子）である。Ｅｘｔｅｎｓｉｏｎはイクステンションフィールドであり、必要に応じて幾つかのイクステンションメッセージが続く。

図１１（Ｂ）において、Ｔｙｐｅは３であり、Ｃｏｄｅはａｃｃｅｐｔｅｄ等のＲｅｓｕｌｔ Ｃｏｄｅである。それ以外は図１１（Ａ）と同様である。

図１１（Ｂ）において、Ｔｙｐｅ＝３２はＭｏｂｉｌｅ−Ｈｏｍｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｅｘｔｅｎｓｉｏｎを示し、Ｔｙｐｅ＝３３は（Ｍｏｂｉｌｅ−Ｆｏｒｅｉｇｎ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｅｘｔｅｎｓｉｏｎ）を示し、Ｔｙｐｅ＝３４はＦｏｒｅｉｇｎ−Ｈｏｍｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｅｘｔｅｎｓｉｏｎを示す。Ｌｅｎｇｔｈはメッセージ長［ｂｙｔｅ］であり、ＳＰＩはＳｅｃｕｒｉｔｙ Ｐａｒａｍｅｔｅｒ Ｉｎｄｅｘである。Ａｕｔｈｅｎｔｉｃａｔｏｒは、Ｍｏｂｉｌｅ−Ｈｏｍｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｅｘｔｅｎｓｉｏｎの場合、ＭＮ―ＨＡキーを使用して算出されるメッセージのダイジェストであり、Ｍｏｂｉｌｅ−Ｆｏｒｅｉｇｎ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｅｘｔｅｎｓｉｏｎの場合、ＭＮ―ＦＡキーを使用して算出されるメッセージのダイジェストであり、Ｆｏｒｅｉｇｎ−Ｈｏｍｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｅｘｔｅｎｓｉｏｎの場合、ＦＡ―ＨＡキーを使用して算出されるメッセージのダイジェストである。

なお、上述では、ＭＩＰｖ４を例に、メッセージフォーマットを記載したが、ＭＩＰｖ６に関しても、フォーマットは異なるものの、同様の更新処理を行うことになる。

<第２実施形態>
図５は、本発明の第２実施形態のシーケンス図を示す。この第２実施形態は、第１実施形態と同様に、移動局がＭＩＰクライアントである場合である。違いは、第１実施形態が、ＭＩＰｖ４（Ｍｏｂｉｌｅ ＩＰ ｖｅｒｓｉｏｎ ４）を想定して記載されているのに対し、第２実施形態は、ＭＩＰｖ６（Ｍｏｂｉｌｅ ＩＰ ｖｅｒｓｉｏｎ ６）の場合である。ＭＩＰｖ６でも、ＭＩＰｖ４の場合と同様に、アイドルＰＭＩＰ３６が、アイドル中の移動局２１の代わりに、ＭＩＰリニューアル処理を代行する。

違う点は、ＭＩＰｖ４では、標準仕様上、ＦＡ（Ｆｏｒｅｉｇｎ Ａｇｅｎｔ）が、ＭＩＰレジストレーション／リプライ・メッセージを仲介していたのに対し、ＭＩＰｖ６では、標準仕様上、ＦＡが定義されておらず、存在しない。また、ＭＩＰｖ６では、ＭＩＰレジストレーション／リプライ・メッセージを、それぞれ、バインディングアップデイト、バインディングアクノリッジメントと呼び、ＭＩＰレジストレーション／リプライ・メッセージと基本的な機能は同じである。

ＭＩＰｖ６では、ＦＡが存在しないので、代わりにゲートウェイ２５のアクセスルータ（Ａｃｃｅｓｓ Ｒｏｕｔｅｒ；ＡＲ）機能が、バインディングアップデイト／アクノリッジメントを中継し、ルータアドバタイズメント（ＲＡ）を広報する。第１実施形態と同様に、第２実施形態でも、ネットワークプリフィックスが異なるルータアドバタイズメントを広報するために、ＶＡＲ（Ｖｉｒｔｕａｌ Ａｃｃｅｓｓ Ｒｏｕｔｅｒ）６１，６２を設ける。

ＭＩＰｖ４においては、移動局２１が送信するＭＩＰレジストレーションの宛先ＩＰアドレス、及び、ＨＡ４０が送信するＭＩＰリプライの宛先ＩＰアドレスは、ＦＡを指していたのに対して、ＭＩＰｖ６においては、移動局２１が送信するバインディングアップデイトの宛先ＩＰアドレスは、ＨＡ４０を指しており、ＨＡ４０が送信するバインディングアクノリッジメントの宛先ＩＰアドレスは、移動局２１を指している。ＩＰレイヤとしては一度終端して再送信するＦＡとは異なり、ＡＲはＩＰレイヤの終端は行わずにＩＰルーティングを行う。

このような中継処理の違いが、ＦＡとＡＲにはあるものの、最終的にゲートウェイ２５が、バインディングアップデイト／アクノリッジメント・メッセージを参照することができれば、バインディングアップデイト／アクノリッジメント・メッセージから、第１実施形態と同様に、必要な情報を取得することが可能である。

図５は、バインディングアップデイト／アクノリッジメント、及び、ルータアドバタイズメントに関係する部分だけを記載してある。既に説明した違い以外については、図４と同様なので、詳細な説明は割愛する。

このようにして、移動局２１がＭＩＰｖ６クライアントを具備する場合、移動局２１はリニューアル処理を行うために、アイドルモードから一度抜けて、ノーマルモードへ移行しなくても済むようにできる。

<第３実施形態>
図６は、本発明の第３実施形態のシーケンス図を示す。この第３実施形態は、移動局がＤＨＣＰクライアントである場合である。

第３実施形態に関しては、第１実施形態と異なる部分を中心に説明する。第３実施形態では、リニューアル実行手段として、ＤＨＣＰリクエスト／アクノリッジメント・メッセージの送受信を行う。

第３実施形態では、ノーマルモード復帰後クライアント―サーバ間タイマ同期手段として、ネットワークプリフィックスが異なるルータアドバタイズメントを広報する方法以外の選択肢として、移動局２２にＤＨＣＰネガティブ・アクノリッジメント・メッセージを送信して、該移動局２２がタイマ同期処理を行うようにすることもできる。

以下、図６のシーケンスに沿って説明する。

ステップ［ａ］無線アクセスの認証フェーズである。

ステップ［ｂ］移動局はＤＨＣＰサーバとの間で、ＤＨＣＰの初期化を行う。ＤＨＣＰサーバ４１は移動局２２にアドレスをリースする。ＤＨＣＰの初期化は、移動局２２からＤＨＣＰディスカバー・メッセージを送信し、ＤＨＣＰサーバがＤＨＣＰオファー・メッセージで応答し、次に、移動局２２からＤＨＣＰリクエスト・メッセージを送信し、ＤＨＣＰサーバ４１がＤＨＣＰアクノリッジメント・メッセージで応答することにより完了する。

移動局２２は、定期的にタイマを更新する際には、ＤＨＣＰリクエスト／アクノリッジメント・メッセージの送受信のみ行う
ステップ［ｃ］第１実施形態と同様に、アイドルＰＤＨＣＰ３７は、移動局２２がアイドルモードになる前のタイマ値である初期タイマ値を、移動局２２のＤＨＣＰクライアント―ＤＨＣＰサーバ４１間のＤＨＣＰメッセージから得る。初期タイマ値は、ＤＨＣＰメッセージのリースタイム・フィールドから得ることができる。なお、第１実施形態と同様に、初期タイマ値の取得は、必須の機能ではない。

アイドルＰＤＨＣＰ３７は、初期タイマ値を取得する、しないに関係なく、ＤＨＣＰリニューアルを代行する際に、ＤＨＣＰリクエストが送信できるように、ＤＨＣＰリクエストに格納すべき、各種フィールド値を、上述の無線アクセス認証フェーズ、または、上述 のステップ［ｂ］のＤＨＣＰの初期化時、または、定期的なＤＨＣＰリクエスト／アクノリッジメント・メッセージから得る。

ステップ［ｄ］第１実施形態と同様に、移動局は、アイドルモードへ移行する。

ステップ［ｅ］第１実施形態と同様に、ＰＣ／ＬＲ３４は、アイドルモードの開始をアイドルＰＤＨＣＰ３７へ通知する。

ステップ［ｆ〜ｇ］アイドルＰＤＨＣＰ３７は、自身が内部に有するタイマの値を基に、タイマがタイムアウトする前に、ＤＨＣＰリクエスト／アクノリッジメント・メッセージの送受信を行い、ＤＨＣＰリニューアル処理を移動局２２の代わりに代行する。

上述したように、初期タイマ値を取得していた場合は、アイドルＰＤＨＣＰ３７は、移動局２２がアイドルモードになった後、初めのＤＨＣＰリクエスト／アクノリッジメント・メッセージを、自身が内部に有するタイマがタイムアウトする前に行う。初期タイマ値を取得していない場合は、アイドルＰＤＨＣＰ３７は、移動局がアイドルモードになった後、初めのＤＨＣＰリクエスト／アクノリッジメント・メッセージを、アイドルモードの開始を受信後、すぐに行う。

ステップ［ｈ］第１実施形態と同様に、移動局は、アイドルモードから抜けてノーマルモードに移行する。

ステップ［ｉ］第１実施形態と同様に、ＰＣ／ＬＲ３４は、アイドルモードの終了をアイドルＰＤＨＣＰ３７へ通知する。第１実施形態と同様に、ノーマルモードへ移行しないアイドルモードの終了の場合は、アイドルＰＤＨＣＰ３７は、以降のタイマ同期処理等は行わず、該当移動局２２の管理を止める。

ステップ［ｊ］アイドルＰＤＨＣＰ３７は、移動局２２にＤＨＣＰネガティブ・アクノリッジメント・メッセージを送信する。

ＤＨＣＰネガティブ・アクノリッジメント・メッセージを受信した移動局２２は、リースが無効になったと認知し、あらためてＤＨＣＰの初期化を行う。これにより、移動局２２がタイマ同期処理を行うようにすることができる。

なお、この際のＤＨＣＰの初期化は、ＤＨＣＰディスカバー／オファー・メッセージを使用せずに、ＤＨＣＰリクエスト／アクノリッジメント・メッセージのみで行う可能性もある。

ステップ［ｋ〜ｌ］ＤＨＣＰネガティブ・アクノリッジメント・メッセージによるタイマ同期処理以外に、第１実施形態または、第２実施形態と同様に、ネットワークプリフィックスが異なるルータアドバタイズメントを、ＶＦＡ３１，３２（またはＶＡＲ６１，６２）が広報することによって、タイマ同期処理を行ってもよい。

ただし、第１実施形態のＭＩＰｖ４、第２実施形態のＭＩＰｖ６の場合と違い、アイドルＰＤＨＣＰ３７は、移動局２２へリースされていたアドレスとはネットワークプリフィックスが異なるＶＦＡ３１，３２（またはＶＡＲ６１，６２）へルータアドバタイズメントの広報を依頼する。

移動局２２は、ＭＩＰクライアントを具備しないので、ＭＩＰレジストレーション／リプライ・メッセージ、及び、バインディングアップデイト／アクノリッジメント・メッセージを送受信しない。

なお、アイドルＰＤＨＣＰ３７は、移動局２２へリースされていたアドレスの上位ビットを参照することで、該アドレスのネットワークプリフィックスが分かる。

ステップ［ｍ］移動局２２は、ＤＨＣＰの初期化を行う。移動局のタイマとＤＨＣＰサーバ４１のタイマが同期する。

ステップ［ｎ］アイドルＰＤＨＣＰ３７は、上述のステップ［ｃ］と同様に、初期タイマ値を取得する。

なお、上述のＤＨＣＰのメッセージ名は、ＤＨＣＰｖ４のメッセージ名を記載したが、ＤＨＣＰｖ６においても、メッセージ名は異なるものの、同様のメッセージが定義されており、ＤＨＣＰｖ４の場合と、同様の処理となる。

このようにして、移動局２２がＤＨＣＰクライアント２４を具備していた場合、移動局２２がリニューアル処理を行うために、アイドルモードから一度抜けて、ノーマルモードへ移行しなくても済むようにできる。

図１２（Ａ）はＤＨＣＰメッセージのフォーマットを示す。ＤＨＣＰメッセージの種類としては、ＤＨＣＰディスカバー，ＤＨＣＰオファー，ＤＨＣＰリクエスト，ＤＨＣＰディクライン，ＤＨＣＰアクノリッジメント，ＤＨＣＰＰネガティブ・アクノリッジメント， ＤＨＣＰリリース，ＤＨＣＰインフォームがあるが、すべて、図１２（Ａ）のメッセージフォーマットであり、メッセージ種別毎に、パラメータの値や、オプションフィールドに格納するオプションが異なる。

図１２（Ａ）において、ｏｐはＭｅｓｓａｇｅ ｏｐ ｃｏｄｅ／Ｍｅｓｓａｇｅ ｔｙｐｅである。ｈｔｙｐｅはＨａｒｄｗａｒｅ ａｄｄｒｅｓｓ ｔｙｐｅであり 例えばｈｔｙｐｅ＝１はＥｔｈｅｒｎｅｔ（登録商標）を表す。ｈｌｅｎはＨａｒｄｗａｒｅ ａｄｄｒｅｓｓ ｌｅｎｇｔｈであり、例えばｈｌｅｎ＝６はＥｔｈｅｒｎｅｔ（登録商標）の場合のＨａｒｄｗａｒｅ ａｄｄｒｅｓｓ ｌｅｎｇｔｈを表す。ｈｏｐｓはｒｅｌａｙ ａｇｅｎｔによって使用されるｏｐｔｉｏｎであり、ｘｉｄはＴｒａｎｓａｃｔｉｏｎ ＩＤである。ｓｅｃｓはクライアントによって指定されるアドレス取得後の経過時間［秒］（リース時間とは異なる）である。ｆｌａｇｓはフラグであり、例えばクライアントがブロードキャストで返答を望む場合、指定するｂｒｏａｄｃａｓｔ ｆｌａｇが定義済みである。ｃｉａｄｄｒはＣｌｉｅｎｔ ＩＰ ａｄｄｒｅｓｓであり、ｙｉａｄｄｒは'ｙｏｕｒ'（ｃｌｉｅｎｔ）ＩＰ ａｄｄｒｅｓｓである。ｓｉａｄｄｒはＤＨＣＰ オファー、または、ＤＨＣＰアクノリッジメント時に、サーバによって指定されるサーバのＩＰアドレスである。

ｇｉａｄｄｒはＲｅｌａｙ ａｇｅｎｔ ＩＰ ａｄｄｒｅｓｓであり、ｃｈａｄｄｒはＣｌｉｅｎｔ ｈａｒｄｗａｒｅ ａｄｄｒｅｓｓである。ｓｎａｍｅはｓｅｒｖｅｒ ｈｏｓｔ ｎａｍｅ（文字列）である。ｆｉｌｅはＢｏｏｔ ｆｉｌｅ ｎａｍｅ（文字列）である。ｏｐｔｉｏｎｓはＯｐｔｉｏｎフィールドであり、メッセージ種別毎に必要に応じて、幾つかのオプションが続く。

図１２（Ｂ）〜（Ｄ）に代表的な、オプションを示す。図１２（Ｂ）に示すＲｅｑｕｅｓｔｅｄ ＩＰ Ａｄｄｒｅｓｓは、クライアントが要求するＩＰアドレスである。図１２（Ｃ）に示すＩＰ Ａｄｄｒｅｓｓ Ｌｅａｓｅ Ｔｉｍｅは、リースされたアドレスのリース時間［秒］である。この時間毎に、定期的に更新を行う。

図１２（Ｄ）に示すＤＨＣＰ Ｍｅｓｓａｇｅ Ｔｙｐｅは、本オプションのＴｙｐｅフィールドの値によって、ＤＨＣＰメッセージ種別を特定する。Ｔｙｐｅ＝１はＤＨＣＰ Ｄｉｓｃｏｖｅｒ（クライアント発信メッセージ）を示し、Ｔｙｐｅ＝２はＤＨＣＰ Ｏｆｆｅｒ（サーバ発信メッセージ）を示し、Ｔｙｐｅ＝３はＤＨＣＰ Ｒｅｑｕｅｓｔ（クライアント発信メッセージ）を示し、Ｔｙｐｅ＝４はＤＨＣＰ Ｄｅｃｌｉｎｅ（クライアント発信メッセージ）を示し、Ｔｙｐｅ＝５はＤＨＣＰ Ａｃｋ（サーバ発信メッセージ）を示し、Ｔｙｐｅ＝６はＤＨＣＰ ＮＡＣＫ（サーバ発信メッセージ）を示し、Ｔｙｐｅ＝７はＤＨＣＰ Ｒｅｌｅａｓｅ（クライアント発信メッセージ）を示し、Ｔｙｐｅ＝８はＤＨＣＰ Ｉｎｆｏｒｍ（クライアント発信メッセージ）を示す。

なお、上述ではＤＨＣＰｖ４を例にメッセージフォーマットを記載したが、ＤＨＣＰｖ６に関しても、フォーマットは異なるものの、同様に更新処理を行うことになる。

<第４実施形態>
図７は、本発明の第４実施形態のシーケンス図を示す。この実施形態は、第１実施形態と異なり、アイドル・プロキシ・クライアント３５が、自身の内部に有するタイマ値をもとに、定期的にリニューアル処理を行うのではなく、定期的なロケーションアップデイトを契機に、リニューアル処理を行う。

ＩＥＥＥ ８０２．１６ｅの標準仕様では、アイドル中の移動局は、定期的にロケーションアップデイトを行うことになっている。第４実施形態では、このロケーションアップデイトが行われた契機を、アイドル・プロキシ・クライアント３５がＰＣ／ＬＲ３４から受信し、リニューアル処理を行う。アイドル・プロキシ・クライアント３５は、ロケーションアップデイト完了検知手段を具備する。

なお、この処理行うためには、少なくとも、ロケーションアップデイトの間隔が、定期的なタイマ更新処理を必要とプロトコルの更新間隔よりも短い必要がある。上述のように、間隔を短くできるかどうかは、ネットワークの運用ポリシに依存する。

以下、図７のシーケンスに沿って説明する。

図７は、移動局２１がＭＩＰクライアント２３である場合を図示しているが、移動局２１が、ＭＩＰｖ６クライアント、または、移動局２１がＤＨＣＰクライアントである場合も同様である。また、図７は、アイドルモードに入るところから、アイドルモードを抜けるところまでを記載している。

ステップ［ａ］第１実施形態と同様に、移動局２１は、アイドルモードへ移行する。

ステップ［ｂ］移動局２１は、定期的にロケーションアップデイトを実行する。ロケーションアップデイトの詳細な手順は、ＩＥＥＥ ８０２．１６ｅ及び、ＷｉＭＡＸ Ｆｏｒｕｍ ＮＷＧの標準仕様に定義されている通りであり、ロケーションアップデイトの詳細な手順は、本発明に直接関係ないので説明は割愛する。

ステップ［ｃ］ＰＣ／ＬＲ３４は、ロケーションアップデイトが成功した場合、ロケーションアップデイト完了通知をアイドルＰＭＩＰ３６に通知する。ＤＨＣＰの場合は、アイドルＰＤＨＣＰ３７に通知する。ロケーションアップデイトは、必ず成功するわけではなく、例えば、認証できなくて、失敗するケースもある。ＰＣ／ＬＲ３４は、ロケーションアップデイトが成功した場合だけ、ロケーションアップデイト完了通知を行う。

ステップ［ｄ〜ｅ］ロケーションアップデイト完了通知を受信した、アイドルＰＭＩＰ３６は、ＭＩＰリニューアル処理を移動局の代わりに代行する。ＤＨＣＰの場合は、アイドルＰＤＨＣＰ３７は、ＤＨＣＰリニューアル処理を移動局２１の代わりに代行する。

なお、上述のように、たとえ、ロケーションアップデイトの間隔が、定期的なタイマ更新処理を必要とプロトコルの更新間隔よりも短く設定されていたとしても、ロケーションアップデイトのタイマは、アイドルモードになった直後からスタートするので、アイドルモードになったタイミングによっては、定期的なタイマ更新処理を必要とするプロトコルのタイマの方が先にタイムアウトしてしまう可能性がある。

このようなケースに対応するため、アイドルモードになった後、初めてのリニューアル処理に関しては、アイドルモードになった直後に、リニューアル処理を行うため、アイドルＰＭＩＰ３６にアイドルモード開始検知手段を設ける。また、ＤＨＣＰの場合は、アイドルＰＤＨＣＰ３７にアイドルモード開始検知手段を設ける。

また、第１実施形態と同様に、初期タイマ値を取得し、アイドルモードになった後、初めてのリニューアル処理に関してだけは、タイマ値に基づいてリニューアル処理を行ってもよい。この場合も、以降のリニューアル処理に関しては、定期的なロケーションアップデイトを契機に、リニューアル処理を行う。

ステップ［ｆ］第１実施形態と同様に、移動局２１は、アイドルモードから抜けてノーマルモードへ移行する。

このように、アイドル・プロキシ・クライアント３５が、ロケーションアップデイトに基づいてリニューアル処理を代行するので、移動局２１がリニューアル処理を行うために、アイドルモードから一度抜けて、ノーマルモードへ移行しなくても済むようにできる。

<第５実施形態>
図８は、本発明の第５実施形態のシーケンス図を示す。この実施形態は、第４実施形態と同様に、定期的なロケーションアップデイトを契機に、リニューアル処理を実行する。ただし、第４実施形態とは異なり、第５実施形態は、ＩＥＥＥ ８０２．１６ｅで規定されているロケーションアップデイトのメッセージを拡張して、ロケーションアップデイトを行う際に、移動局２１がリニューアル処理を行うために必要な情報（リニューアル情報）を搬送できるようにして、該情報を基にゲートウェイ２５がリニューアル処理を行う。

図８は、図７では省略した基地局（ＢＳ）２６を記載し、移動局２１―基地局２６間、基地局２６―ゲートウェイ２５間のメッセージが詳述できるようにしている。前述の実施形態では本発明に直接関係ないので、この部分は省略している。

ステップ［ｂ］〜ステップ［ｆ］が、ロケーションアップデイト処理である。標準仕様を拡張している。ＩＥＥＥ ８０２．１６ｅは、移動局―基地局間のインタフェースを規定する標準仕様である。基地局―ゲートウェイ２５間は、ＷｉＭＡＸ Ｆｏｒｕｍ ＮＷＧにおいて、標準策定中である。

以下、図８のシーケンスに沿って説明する。

図８は、移動局がＭＩＰクライアントである場合を図示しているが、移動局２１が、ＭＩＰｖ６クライアント、または、移動局がＤＨＣＰクライアントである場合も同様である。

ステップ［ａ］第１実施形態と同様に、移動局２１は、アイドルモードへ移行する。

ステップ［ｂ］移動局２１は、ロケーションアップデイトを行うために、標準でＲＮＧ−ＲＥＱ（Ｌｏｃａｔｉｏｎ Ｕｐｄａｔｅ ｆｌａｇ）を送信する。第５実施形態では、このメッセージを拡張して、リニューアル情報も搬送できるようにする。拡張の方法としては、ＲＮＧ−ＲＥＱのパラメータを拡張するか、若しくは、ＲＮＧ−ＲＥＱとは別のメッセージを新たに定義し、移動局２１が、ＲＮＧ−ＲＥＱと同時に送信するかの、２通りの方法で行うことができる。

ステップ［ｃ］基地局２６は、ＷｉＭＡＸ Ｆｏｒｕｍ ＮＷＧで規定されているＬＵ（Ｌｏｃａｔｉｏｎ Ｕｐｄａｔｅ）リクエストをＰＣ／ＬＲ３４へ送信する。第５実施形態では、このメッセージを拡張して、リニューアル情報を搬送できるようにする。

ステップ［ｄ］ＰＣ／ＬＲ３４は、ＬＵリスポンスで、基地局２６へ応答する。

ステップ［ｅ］基地局２６は、ＲＮＧ−ＲＳＰ（Ｌｏｃａｔｉｏｎ Ｕｐｄａｔｅ Ｒｅｓｐｏｎｓｅ）で、移動局２１に応答する。この際、基地局２６は、ＲＮＧ−ＲＥＱのメッセージ認証を行い、最終的に正しく認証できれば、サクセスフラグを含むＬＵコンファームをＰＣ／ＬＲ３４に送信する。該メッセージをＰＣ／ＬＲ３４が受信することで、ロケーションアップデイト処理が完了する。

ステップ［ｇ］ＰＣ／ＬＲ３４は、第４実施形態と同様に、ロケーションアップデイト完了通知をアイドル・プロキシ・クライアント３５へ送信する。ただし、第５実施形態では、該通知でリニューアル情報を搬送できるようにする。

ステップ［ｈ〜ｉ］アイドル・プロキシ・クライアント３５は、受信したリニューアル情報を基に、リニューアル処理を行う。

ステップ［ｊ］第１実施形態と同様に、移動局２１は、アイドルモードから抜けてノーマルモードへ移行する。

このように、アイドル・プロキシ・クライアント３５が、ロケーションアップデイトに基づいてリニューアル処理を代行するので、移動局２１がリニューアル処理を行うために、アイドルモードから一度抜けて、ノーマルモードへ移行しなくても済むようにできる。

図１３（Ａ）はＲＮＧ−ＲＥＱ（ＬＵ ｆｌａｇ）＋Ｒｅｎｅｗａｌ Ｉｎｆｏのメッセージフォーマットを示す。ＲＮＧ−ＲＥＱは、ＩＥＥＥ８０２．１６ｅの標準で決まっており、基本的に発明のフォーマットも該標準に準拠している。本発明での追加は、ＲＮＧ−ＲＥＱ中の標準で定義されているＴＬＶ Ｅｎｃｏｄｅｄ Ｉｎｆｏｒｍａｔｉｏｎフィールドに、Ｒｅｎｅｗａｌ Ｉｎｆｏを追加する点である。

Ｒｅｎｅｗａｌ Ｉｎｆｏは、例えばＭＩＰｖ４ならば、図１１（Ａ）及び、必要に応じて図１１（Ｃ）の情報要素をＴＬＶ Ｅｎｃｏｄｅｄしたものであり、ＤＨＣＰｖ４ならば、図１２（Ａ）及び、必要に応じて図１２（Ｂ）〜図１２（Ｄ）の情報要素をＴＬＶ Ｅｎｃｏｄｅｄしたものである。

図１３（Ｂ）は、ロケーションアップデイトリクエスト＋Ｒｅｎｅｗａｌ Ｉｎｆｏのメッセージフォーマットを示す。ロケーションアップデイトは、ＷｉＭＡＸ Ｆｏｒｕｍ ＮＷＧの標準仕様で定義中であり、基本的に発明のフォーマットも該標準に準拠している。本発明では、ロケーションアップデイト・リクエスト・メッセージ中の標準で定義されているＴＬＶフィールドに、Ｒｅｎｅｗａｌ Ｉｎｆｏを追加する。

図１３（Ａ）において、Ｍａｎａｇｅｍｅｎｔ Ｍｅｓｓａｇｅ Ｔｙｐｅ＝４である。標準で規定済みの代表的なＴＬＶパラメータとして、Ｒａｎｇｉｎｇ Ｐｕｒｐｏｓｅ ＩｎｄｉｃａｔｉｏｎはＢｉｔ＃０＝値'１'の場合、Ｎｅｔｗｏｒｋ Ｒｅ−ｅｎｔｒｙを示し、Ｂｉｔ＃１＝値'１'の場合、Ｌｏｃａｔｉｏｎ Ｕｐｄａｔｅを示す（ＬＵ ｆｌａｇ）。Ｐａｇｉｎｇ Ｃｏｎｔｒｏｌｌｅｒ ＩＤはＰａｇｉｎｇ Ｃｏｎｔｒｏｌｌｅｒ（ＰＣ）のＩＤを示す。

図１３（Ｂ）において、標準で規定済みのＬｏｃａｔｉｏｎ Ｕｐｄａｔｅ Ｒｅｑｕｅｓｔ（ＢＳ―ＧＷ間）の代表的なＴＬＶパラメータとして、ＭＳ ＩＤ、ＢＳ ＩＤ、Ａｎｃｈｏｒ ＰＣ ＩＤがある。本発明で追加するＴＬＶパラメータとして、Ｒｅｎｅｗａｌ Ｉｎｆｏは更新処理が必要なプロトコルのメッセージを送信するために必要な情報要素である。

<第６実施形態>
図９は、本発明の第６実施形態のシーケンス図を示す。この実施形態は、アイドルモード中の移動局２１が、ページンググループ（Ｐａｇｉｎｇ Ｇｒｏｕｐ）を跨って、ゲートウェイ２５間を移動する場合である。ページンググループとは、複数の基地局２６によって構成される範囲であり、ページングエリアと呼称する場合もある。ＩＥＥＥ ８０２．１６ｅの標準仕様では、アイドル中の移動局２１が、ページンググループを跨って移動した場合、該移動局２１は、ロケーションアップデイトを行う。なお、これとは別に、前述の第４、第５実施形態のように、移動局２１は、定期的にロケーションアップデイトを行う。

ページンググループを跨って移動する際に、移動局２１が、ゲートウェイ２５を跨って移動する場合、ＦＡ／ＡＲのリロケーションを行う場合がある。リロケーションとは、移動局２１の移動に伴い、今まで、該移動局２６にサービスしていたゲートウェイ２５ＡのＶＦＡ３１ＡまたはＶＡＲ６１Ａとは、別のゲートウェイ２５ＢのＶＦＡ３１ＢまたはＶＡＲ６１Ｂが、該移動局２１にサービスを提供することである。

ＦＡ／ＡＲのリロケーションを行うか、行わないかは、実装、または、ネットワークの運用方針に依存する。ＦＡ／ＡＲのリロケーションを行わない場合は、第４、第５実施形態と同様の方法で、リニューアル処理を代行することができるので、説明を割愛する。第６実施形態は、リロケーションを行う場合である。

図９において、移動局２１は、サービングゲートウェイ２５Ａ配下から、ターゲットゲートウェイ２５Ｂ配下に移動する。サービングゲートウェイ２５Ａ内の各ブロックは、符号の末尾にＡを付し（例：アイドルＰＭＩＰ３６Ａ）と呼称し、ターゲットゲートウェイ２５Ｂ内の各ブロックは、符号の末尾にＢを付し（例：アイドルＰＭＩＰ３６Ｂ）と呼称する。

第６実施形態は、アイドルモード中の移動局２１の移動に伴い、アイドルＰＭＩＰ３６ＡからアイドルＰＭＩＰ３６Ｂにコンテキストを移し、以降は、アイドルＰＭＩＰ３６Ｂが、リニューアル処理の代行を行う。コンテキストとは、アイドルＰＭＩＰ３６Ａが、該移動局２１に関して保持している情報（例：アドレス、タイマ値、等）のことである。コンテキストを移すことを、一般的にコンテキストトランスファーと言う。

第１実施形態と同様に、ノーマルモード復帰後は、ＶＦＡ３１Ｂがルータアドバタイズメントを広報することで、タイマの同期を実現する。

以下、図９のシーケンスに沿って説明する。図９は、移動局２１がＭＩＰクライアント２３である場合を図示しているが、移動局２１が、ＭＩＰｖ６クライアント、または、移動局２２がＤＨＣＰクライアント２４である場合も同様である。

ステップ［ａ］移動局２１は移動に伴い、ロケーションアップデイトを実行する。この際、ＦＡ／ＡＲのリロケーションを行うかどうか決定される。本実施形態では、リロケーションを行う。

ステップ［ｂ］サービング−アイドルＰＭＩＰ３６Ａからターゲット−アイドルＰＭＩＰ３６Ｂにコンテキストを移す（コンテキストトランスファー）。このコンテキストトランスファーは、ステップ［ｂ］のステップ内で行っても良いし、後述のステップ［ｄ］で行ってもよい。

ステップ［ｃ］ＰＣ／ＬＲ３４Ｂがロケーションアップデイト完了通知をアイドルＰＭＩＰ３６Ｂに送信する。図９では、ターゲット−ＰＣ／ＬＲ３４Ｂがロケーションアップデイト完了通知を送信しているが、これは、ＰＣ／ＬＲ３４ＡからＰＣ／ＬＲ３４Ｂへのリロケーションを行う場合であり、リロケーションを行わない場合は、サービング−ＰＣ／ＬＲ３４Ａが、ロケーションアップデイト完了通知を送信する。ＦＡ／ＡＲのリロケーションと、ＰＣ／ＬＲ３４のリロケーションは、独立の関係にあり、例えば、ＦＡ／ＡＲのリロケーションを行い、かつ、ＰＣ／ＬＲ３４のリロケーションを行わない可能性もある。

ステップ［ｄ〜ｅ］ロケーションアップデイト完了通知に基づき、アイドルＰＭＩＰ３６Ｂは、リニューアル処理を行う。ＭＩＰレジストレーション／リプライ・メッセージを仲介するＶＦＡは、ＶＦＡ３１ＢでもＶＦＡ３２Ｂでも、どちらでも構わない。

ステップ［ｆ〜ｇ］上述のステップ［ｄ〜ｅ］とは別に、アイドル・プロキシ・クライアント３５Ｂは、自身のタイマ、若しくは、定期的なＬＵ（ロケーションアップデイト）を契機にリニューアル処理を行う。自身のタイマで行うか、定期的なＬＵで行うかは、前述のどの実施形態を採用するかに依存する。

ステップ［ｈ］第１実施形態と同様に、移動局２１は、アイドルモードから抜けてノーマルモードへ移行する。

ステップ［ｉ］ＰＣ／ＬＲ３４Ｂは、第１実施形態と同様に、アイドルモード終了通知をアイドルＰＭＩＰ３６Ｂに送信する。

ステップ［ｊ］アイドルＰＭＩＰ３６Ｂは、ターゲット−ＶＦＡ３１Ｂ（図示）、または、ターゲット−ＶＦＡ３２Ｂに、ルータアドバタイズメントの広報を依頼する。ターゲット−ＶＦＡ３１Ｂにしろ、ターゲット−ＶＦＡ３２Ｂにしろ、サービング−ＶＦＡ３１Ａ／３２Ａとは、違うネットワークプリフィックスを広報するので、どちらでも構わない。

ステップ［ｋ］第１実施形態と同様に、ターゲット−ＶＦＡ３１Ｂは、ネットワークプリフィックスが異なるルータアドバタイズメントを広報する。

ステップ［ｌ〜ｍ］ネットワークプリフィックスが異なるルータアドバタイズメントを受信した移動局２１は、リニューアル処理を行い、タイマの同期が実現する。

このように、アイドル中の移動局２１がページンググループを跨って移動した場合でも移動局２１がリニューアル処理を行うために、アイドルモードから一度抜けて、ノーマルモードへ移行しなくても済むようにできる。

<第７実施形態>
図１０は、本発明の第７実施形態のシーケンス図を示す。この実施形態は移動局２１（，２２）がＭＩＰクライアント２３かＤＨＣＰクライアント２４かを判断し、それぞれ、ＭＩＰリニューアル代行処理、若しくは、ＤＨＣＰリニューアル代行処理を行う場合である。なお、ＭＩＰクライアント２３、ＤＨＣＰクライアント２４を混在して運用しない場合は、必要ではない。

第７実施形態においては、無線アクセス認証フェーズ後、移動局２１（，２２）にルータアドバタイズメント（ＩＰｖ４）とルータアドバタイズメント（ＩＰｖ６）を広報し、移動局２１（，２２）からの応答メッセージの種別によって、ＭＩＰクライアントか、ＤＨＣＰクライアントか判断し、その判断結果を、アイドル・プロキシ・クライアント３５へ通知する。このために、アイドル・プロキシ・クライアント３５は、クライアント判別手段を具備する。

以下、図１０のシーケンスに沿って説明する。

ステップ［ａ］ＷｉＭＡＸで定義された無線アクセスの認証フェーズを実行する。

ステップ［ｂ〜ｃ］ゲートウェイ２５は、ルータアドバタイズメント（ＩＰｖ４）、及び、ルータアドバタイズメント（ＩＰｖ６）を広報する。

ステップ［ｄ〜ｆ］移動局２１（，２２）は、自身がＭＩＰｖ４クライアント２３、ＭＩＰｖ６クライアント、ＤＨＣＰクライアント２４かに応じて、それぞれ、ＭＩＰレジストレーション、または、バインディングアップデイト、または、ＤＨＣＰディスカバーを送信する。

ステップ［ｇ〜ｉ］それぞれ、図１０に示すように、ＶＦＡ３１，３２、または、ＶＡＲ６１，６２、または、ＤＨＣＰリレー３３が受信し、それぞれ、アイドルＰＭＩＰ３６にモード通知（ＭＩＰｖ４，ＭＩＰｖ６）、アイドルＰＤＨＣＰ３７にモード通知（ＤＨＣＰ）を行う。

以降は、前述の実施形態のリニューアル代行処理を行うことになる。

このように、移動局２１，２２がＭＩＰクライアント３６かＤＨＣＰクライアント３７かを判断し、それぞれ、ＭＩＰリニューアル代行処理、若しくは、ＤＨＣＰリニューアル代行処理を行うことができる。

本発明によれば、ゲートウェイつまり中継装置でリニューアル処理を行うために、移動局がアイドルモードから一度抜けてノーマルモードへ移行しなくても済むようにでき、移動局の消費電力、及び、使用無線リソースを削減することができる。

従来のネットワークの一例の構成図である。 本発明の中継装置を適用したネットワークの一実施例の構成図である。 本発明の中継装置の機能構成図である。 本発明の第１実施形態のシーケンス図である。 本発明の第２実施形態のシーケンス図である。 本発明の第３実施形態のシーケンス図である。 本発明の第４実施形態のシーケンス図である。 本発明の第５実施形態のシーケンス図である。 本発明の第６実施形態のシーケンス図である。 本発明の第７実施形態のシーケンス図である。 ＭＩＰレジストレーション／リプライ・メッセージのフォーマットを示す図である。 ＤＨＣＰメッセージのフォーマットを示す図である。 ＲＮＧ−ＲＥＱ（ＬＵ ｆｌａｇ）／ロケーションアップデイトリクエスト＋Ｒｅｎｅｗａｌ Ｉｎｆｏのメッセージフォーマットを示す図である。

符号の説明

２１，２２ 移動局
２３ ＭＩＰクライアント
２４ ＤＨＣＰクライアント
２５ ゲートウェイ
２６，２７ 基地局
３１，３２ ＶＦＡ
３３ ＤＨＣＰリレー
３４ ＰＣ／ＬＲ
３５ アイドル・プロキシ・クライアント
４０ ホームエージェント（ＨＡ）
４１ ＤＨＣＰサーバ
４２ ＡＡＡサーバ
３６ アイドルＰＭＩＰ
３７ アイドルＰＤＨＣＰ
６１，６２ ＶＡＲ

Claims (17)

1. 移動局と無線接続する基地局の管理を行う中継装置において、
   移動局が電力消費を削減しているアイドルモードであることを検知するアイドルモード検知手段と、
   前記アイドルモードの移動局に代わって、定期的にリニューアルに必要なメッセージをサーバと送受信してリニューアルを実行するリニューアル実行手段と、
   前記移動局がアイドルモードからノーマルモードに復帰後、互いに合っていない移動局とサーバのタイマの値を同期させるタイマ同期手段を
   有することを特徴とする中継装置。
2. 請求項１記載の中継装置において、
   アイドルモード中の移動局が定期的に実行するロケーションアップデイトの完了を検知するロケーションアップデイト完了検知手段を有し、
   前記リニューアル実行手段は、前記アイドルモードの移動局に代わって、前記ロケーションアップデイト完了検知を契機として前記リニューアルに必要なメッセージを送受信することを特徴とする中継装置。
3. 請求項１または２記載の中継装置において、
   前記移動局がアイドルモードになる前のタイマ値を取得する初期タイマ値取得手段を有し、
   前記リニューアル実行手段は、前記タイマ値に基づいて前記リニューアルに必要なメッセージを送受信することを特徴とする中継装置。
4. 請求項１乃至３のいずれか１項記載の中継装置において、
   前記リニューアル実行手段は、前記リニューアルに必要なメッセージとしてＭＩＰレジストレーション／リプライ・メッセージを送受信することを特徴とする中継装置。
5. 請求項１乃至３のいずれか１項記載の中継装置において、
   前記リニューアル実行手段は、前記リニューアルに必要なメッセージとしてバインディングアップデイト／アクノリッジメント・メッセージを送受信することを特徴とする中継装置。
6. 請求項４記載の中継装置において、
   前記タイマ同期手段は、前記ＭＩＰレジストレーション／リプライ・メッセージを送受信していたエージェントとはネットワークプリフィックスが異なるエージェントにルータアドバタイズメントの広報を依頼することで、前記移動局とサーバのタイマの値を同期させることを特徴とする中継装置。
7. 請求項５記載の中継装置において、
   前記タイマ同期手段は、前記バインディングアップデイト／アクノリッジメント・メッセージを送受信していたアクセスルータとはネットワークプリフィックスが異なるアクセスルータにルータアドバタイズメントの広報を依頼することで、前記移動局とサーバのタイマの値を同期させることを特徴とする中継装置。
8. 請求項４または５記載の中継装置において、
   無線アクセス認証フェーズにおいて、ＭＩＰキーを取得するＭＩＰキー取得手段を有することを特徴とする中継装置。
9. 請求項４または５記載の中継装置において、
   前記ＭＩＰキー取得手段は、ホームエージェントから前記ＭＩＰキーを取得することを特徴とする中継装置。
10. 請求項４または５記載の中継装置において、
    前記ＭＩＰキー取得手段は、ＡＡＡサーバから前記ＭＩＰキーを取得することを特徴とする中継装置。
11. 請求項１乃至３のいずれか１項記載の中継装置において、
    前記リニューアル実行手段は、前記リニューアルに必要なメッセージとしてＤＨＣＰリクエスト／アクノリッジメント・メッセージを送受信することを特徴とする中継装置。
12. 請求項１１記載の中継装置において、
    前記タイマ同期手段は、前記移動局へリースされていたアドレスとはネットワークプリフィックスが異なるエージェントにルータアドバタイズメントの広報を依頼することで、前記移動局とサーバのタイマの値を同期させることを特徴とする中継装置。
13. 請求項１１記載の中継装置において、
    前記タイマ同期手段は、前記移動局へリースされていたアドレスとはネットワークプリフィックスが異なるアクセスルータにルータアドバタイズメントの広報を依頼することで、前記移動局とサーバのタイマの値を同期させることを特徴とする中継装置。
14. 請求項１１記載の中継装置において、
    前記タイマ同期手段は、前記移動局にＤＨＣＰネガティブ・アクノリッジメント・メッセージを送信することで、前記移動局とサーバのタイマの値を同期させることを特徴とする中継装置。
15. 請求項２記載の中継装置において、
    前記ロケーションアップデイトのメッセージを拡張して前記リニューアルに必要な情報を搬送することを特徴とする中継装置。
16. 請求項１乃至３のいずれか１項記載の中継装置において、
    前記アイドルモードの移動局がページンググループを跨って移動するとき、前記アイドルモードの移動局に関する情報を移動前の中継装置から移動後の中継装置に移動することを特徴とする中継装置。
17. 請求項１乃至３のいずれか１項記載の中継装置において、
    移動局に対しルータアドバタイズメントを広報し、前記移動局からの応答メッセージの種別に応じて前記移動局の持つクライアントを判別するクライアント判別手段を
    有することを特徴とする中継装置。

Images