JP2009213108A

JP2009213108A - 移動通信システムにおける移動ノード装置のｉｐアドレスの切替え方法、移動ノード装置およびサーバ

Info

Publication number: JP2009213108A
Application number: JP2008176914A
Authority: JP
Inventors: 正 ▲高▼橋; Tadashi Takahashi; Hiroaki Miyata; 裕章宮田
Original assignee: Hitachi Communication Technologies Ltd
Current assignee: Hitachi Communication Technologies Ltd
Priority date: 2008-02-05
Filing date: 2008-07-07
Publication date: 2009-09-17

Abstract

【課題】通信相手ノードＣＮと通信中に移動ノードＭＮのＩＰアドレスが変更された場合でも、パケット転送遅延を低減できる移動ノードのＩＰアドレスの切替え方法の提供。
【解決手段】ＣＮと通信中のＭＮが、定期的に実行されるビーコン受信処理によって、新たなＩＰサブネットに所属したアクセスポイントを検知したとき、該ＩＰサブネットで使用すべき新たなＩＰアドレスを予め取得しておき、現在接続中のＩＰサブネットから新たなＩＰサブネットへの切替え条件が満たされた時点で、ＣＮにＩＰのアドレス変更を通知して、ＩＰサブネットとＩＰアドレスの切り替えを行う。
【選択図】図１

Description

本発明は、移動通信システムに関し、更に詳しくは、移動ノード装置（移動端末）がＩＰサブネットから割り当てられたＩＰアドレスを使用してパケット通信を行う移動通信システムにおける移動端末のＩＰアドレスの切り替え方法、移動ノード装置およびサーバに関する。

従来、携帯電話やＰＨＳ端末などの移動端末をインターネットに接続する場合、各移動端末は、無線基地局（アクセスポイント）を経由して、ゲートウェイとの間にセッションを確立し、確立されたセッション上でＩＰ通信を行っている。近年では、家庭やオフィスに無線ＬＡＮを敷設し、無線ＬＡＮを経由して移動端末をインターネットに接続できるようにした無線ＬＡＮシステムが実用化されている。また、企業内では、無線ＬＡＮ上で音声通話が行える無線ＩＰ電話（ＶｏＷＬＡＮ）が導入され始めている。

ＩＰ電話では、音声をＩＰパケットで送信するＶｏＩＰ（Voice over Internet Protocol）技術が利用されている。ＩＥＴＦ（Internet Engineering Task Force）では、ＩＰ電話用のセッション制御プロトコルとして、ＲＦＣ３２６１でＳＩＰ（Session Initiation Protocol）を標準化している。ＳＩＰは、テキストベースのプロトコルであり、インターネットと親和性と拡張性が高いため、ＩＰ電話用のプロトコルは、ＳＩＰに統合されつつある。

無線ＬＡＮでは、各移動端末に対して、ＩＰサブネット毎に異なったＩＰアドレスが割当てられる。例えば、無線ＩＰ電話（ＶｏＷＬＡＮ）の場合、端末の移動によってＩＰサブネット間で移動端末のハンドオーバ（またはローミング）が発生すると、移動端末のＩＰアドレスが切り替わり、新たなＩＰアドレスの取得手順と登録手順が実行されるため、通話が一時的に切断されるという問題がある。

また、ＩＰ網を介してＷＥＢサーバやＦＴＰサーバに接続中の移動端末にＩＰサブネット間のハンドオーバが発生した場合も、移動先ＩＰサブネットでの新たなＩＰアドレスの取得とＩＰアドレスの切替えが問題となる。例えば、ＷＥＢサーバから移動端末にデータをダウンロードする場合、一般にＴＣＰ（Transmission Control Protocol）コネクションが利用される。ＴＣＰでは、宛先ＩＰアドレス、送信元ＩＰアドレス、宛先ポート番号、送信元ポート番号、プロトコル番号の組み合わせによって、通信コネクションを識別している。従って、ＩＰサブネット間のハンドオーバによって移動端末のＩＰアドレスが変ると、ハンドオーバ前の旧ＩＰアドレスで確立されたＴＣＰコネクションが使用不能となり、ＷＥＢサーバから旧ＩＰアドレスで送信されたデータが移動端末に届かなくなる。

ＴＣＰを利用した通信では、送信データが通信経路上で紛失、あるいは受信ノード側で正常に受信できなかった場合、同一データを再送することによって、全ての送信データを確実に受信ノードに届ける仕組みとなっている。従って、ＷＥＢサーバと移動端末との間に旧ＩＰアドレスで設定されていたＴＣＰコネクションがクローズされる前に、移動端末のＩＰアドレスが突然切替わった場合、もしＷＥＢサーバが移動端末にデータをダウンロード中であれば、ＷＥＢサーバは、一定の期間、移動端末に届くことのない旧ＩＰアドレスを適用したデータの再送動作を繰り返すため、通信リソースに無駄が発生することになる。ＷＥＢサーバから移動端末へのデータダウンロードを継続するためには、移動端末のＩＰアドレスの変更の都度、新たなＴＣＰコネクションを設定するための通信手順を実行必要がある。

従って、移動端末が、ＷＥＢサーバのようなＩＰ網に接続されたサーバと通信する場合も、無線ＩＰ電話の場合も、通信中の端末ＩＰアドレスの変更が問題となる。ＩＰサブネット間ハンドオーバによるＩＰアドレスの変更回数を少なくするためには、同一ＩＰアドレスで通信可能なエリアを拡張する必要があるが、同一のＩＰサブネットを広範囲にわたって敷設することは容易でない。一般に、企業内あるいは高層ビル内でのＩＰサブネットの管理は、例えば、部署毎、フロア毎、または建屋毎に行われている。そのため、ユーザが移動端末で通話しながら構内を移動すると、必然的にＩＰサブネット間のハンドオーバ（ローミング）が発生し、移動端末が新たなＩＰサブネットに接続されたとき、端末ＩＰアドレスが切り替わる可能性が高い。

ＩＥＴＦ（Internet Engineering Task Force）では、端末がＩＰサブネット間を移動した場合でも、同一ＩＰアドレスを継続的に利用できるモバイルＩＰ仕様として、ＲＦＣ３２２０でＩＰｖ４対応のモバイルＩＰ、ＲＦＣ３７７５でＩＰｖ６対応のモバイルＩＰを標準化している。

モバイルＩＰ仕様のネットワークは、移動ノードＭＮ（Mobile Node）と、ホームエージェントＨＡ（Home Agent）と、通信相手ノードＣＮ（Corresponder Node）とからなり、各ＭＮに、端末位置が移動しても変化することのないホームアドレスＨｏＡを付与している。ＭＮは、ホームエージェントＨＡが所属するホームエリアを離れて他のエリアに移動して、訪問先エリアで有効となる気付アドレスＣｏＡ（Care of Address）を取得すると、ＨＡに対して、ＨｏＡとＣｏＡとの対応関係（バインディング情報）を示す位置登録要求（ＢＵ：Binding Update）メッセージを送信する。

ＨＡは、ＭＮからＢＵメッセージを受信すると、受信メッセージが示すＨｏＡとＣｏＡと関係をバインディングキャッシュ（Binding Cache）管理テーブルに登録する。ＨＡは、通信相手ノードＣＮからＭＮのＨｏＡを宛先アドレスとするパケットを受信すると、Binding Cache管理テーブルからＨｏＡと対応するＣｏＡを検索し、受信パケットにＣｏＡを宛先アドレスとするカプセル化ヘッダを付加して、移動ノードＭＮに転送する。これによって、ＭＮがホームエリア以外の他のＩＰサブネットに移動した場合でも、ＭＮのＨｏＡを利用して、ＭＮとＣＮとの間の通信を継続できる。

しかしながら、モバイルＩＰでは、ＭＮのハンドオーバ（またはローミング）時に、ＭＮとホームエージェントＨＡとの間で位置登録のための手順を実行する必要があり、その後は、ＨＡが、ＨｏＡ宛の受信パケットをカプセル化して、ＭＮに転送する必要がある。このため、結果的に、パケットに転送遅延が発生し、ＩＰ電話サービスのようなリアルタイム通信では、通信品質が劣化するという問題がある。また、ＷＥＢサーバのアクセスにおいては、トラフィックが増加し、スループットが低下するという問題がある。

この問題に対処した従来技術として、例えば、特開２００６−１１５４５３号公報（特許文献１）は、モバイルＩＰとＳＩＰを統合したネットワークにおいて、訪問先ネットワークで新たな気付アドレスＣｏＡを取得した移動ノードＭＮに、送信元ＩＰアドレスとしてＣｏＡを適用して、通信相手ノードＣＮにＳＩＰのセッション接続メッセージ（ＩＮＶＩＴＥ）を送信させることによって、ＭＮとＣＮが、ホームエージェントＨＡを経由することなく直接的に通信することを提案している。

また、特開２００６−９３７５６号公報（特許文献２）は、それぞれが複数のアクセスポイントをもつ複数のサブネットからなる無線ＬＡＮシステムにおいて、移動中の端末が、複数のアクセスポイントＡＰから定期的にブロードキャストされたパケットを受信した時、受信パケットが示す各ＡＰのＩＰ層ネットワークアドレスと移動端末が現在通信中のＡＰのネットワークアドレスとの関係、および各受信パケットの受信電界強度の大小関係をチェックし、移動端末が、現在通信中のＡＰと同一のサブネットワークに接続されたＡＰを優先的に選択することによって、サブネットワークの切り替え回数を低減することを提案している。

特開２００６−１１５４５３号公報特開２００６−９３７５６号公報

モバイルＩＰｖ６では、移動ノードＭＮと通信相手装置（ＣＮ）が、ホームエージェントＨＡを経由せずに通信できるように、通信経路を最適化するための機能も規定している。但し、モバイルＩＰｖ６では、通信相手装置がバインディングキャシュ（Binding cache）を持っていなければ、ＭＮから通信相手装置に新たな気付アドレスＣｏＡを通知できないため、この場合は、ホームエージェントＨＡを経由した通信経路となってしまう。また、未着データについては再送処理する仕組みをもつＴＣＰ通信をモバイルＩＰで実行した場合、受信装置が返送した確認応答に転送遅延が発生すると、送信装置が同一データの再送を繰り返し、ネットワーク負荷が増加する可能性がある。

特許文献１には、移動端末ＭＮが異なるネットワークへ移動した後の通信方法について開示されているが、移動端末の移動に伴って発生するハンドオーバ処理については記載されていない。

また、上記特許文献２では、ローミングの切替え判定時に、受信電界強度を閾値で判定すると共に、ＩＰ層ネットワークアドレスに基づいて、新たなＩＰサブネットと移動端末ＭＮが現在通信中のＩＰサブネットとの一致、不一致を判定することによって、ＭＮが異なるＩＰサブネットに接続されてＩＰアドレスが変わる回数を抑制している。但し、特許文献２には、ローミングの切替え判定時に、移動先に現在と同じＩＰサブネットを検出できなかった場合、モバイルＩＰによってＭＮと通信相手装置との間の通信が継続されるため、前述したモバイルＩＰに付随した問題がある。

本発明の目的は、複数のＩＰサブネットからなる移動通信システムにおいて、移動ノード（ＭＮ）が、現在通信中のＩＰサブネットとは異なるＩＰサブネットに移動して、ＭＮが使用すべきＩＰアドレスが変わった場合でも、ＩＰサブネット間ハンドオーバの所要時間を短縮し、パケット転送遅延を低減できる移動ノードのＩＰアドレスの切替え方法、および移動ノード装置を提供することにある。

本発明の他の目的は、移動ノード（ＭＮ）がＴＣＰコネクションを通してサーバと通信する場合でも、ＩＰサブネット間ハンドオーバの所要時間を短縮でき、通信リソースを有効に利用できる移動ノードのＩＰアドレスの切替え方法、移動ノード装置およびサーバを提供することにある。

上記目的を達成するため、本発明のＩＰアドレスの切替え方法は、固定網に接続された複数のＩＰサブネットを含み、移動ノード（ＭＮ）が現在接続中のＩＰサブネットから移動先のＩＰサブネットにハンドオーバされる移動通信システムにおいて、
上記ＭＮが、通信相手装置と通信中に、定期的に実行されるビーコン信号受信処理によって、新たなＩＰサブネットに所属したアクセスポイントを検知し、該ＩＰサブネットで使用すべき新たなＩＰアドレスを取得するステップと、上記ＭＮが、現在接続中のＩＰサブネットから上記新たなＩＰサブネットへのハンドオーバ条件が成立した時点で、上記通信相手装置に該ＭＮのＩＰアドレスの変更を示す制御パケットを送信するステップと、上記ＭＮが、上記制御パケットを送信した後で、該ＭＮのＩＰアドレスを既に取得済みの新たなＩＰアドレスに変更することによって、送受信パケットの通信経路を上記新たなＩＰサブネットに切替えるステップとからなることを特徴とする。

更に詳述すると、本発明による移動ノード装置（ＭＮ）のＩＰアドレスの切替え方法は、固定網に接続された複数のＩＰサブネットからなり、１つのＩＰサブネットを経由して通信相手装置と通信中の移動ノード（ＭＮ）が、新たなＩＰサブネットに移動したとき、現在接続中のＩＰサブネットから移動先のＩＰサブネットにハンドオーバされる移動通信システムにおいて、
上記通信相手装置と通信中のＭＮが、定期的に実行されるビーコン信号受信処理によって、新たなＩＰサブネットに所属したアクセスポイントを検知し、該ＩＰサブネットで使用すべき新たなＩＰアドレスを取得するステップと、現在接続中のＩＰサブネットから上記新たなＩＰサブネットへのハンドオーバ条件が成立した時点で、上記通信相手装置と通信中のＭＮが、上記通信相手装置に該ＭＮのＩＰアドレスの変更を示す制御パケットを送信し、該ＭＮのＩＰアドレスを既に取得済みの新たなＩＰアドレスに切替えることによって、上記新たなＩＰサブネットにハンドオーバするステップと、上記ＭＮから、上記固定網に接続されたセッション管理サーバに、上記新たなＩＰアドレスを通知するステップとからなることを特徴とする。

具体的には、ＭＮは、ビーコン信号受信処理によって、新たなＩＰサブネットに所属するアクセスポイントから送信されたビーコン信号を検知したとき、該ビーコン信号の送信元となったアクセスポイントに接続した後、該ＩＰサブネットで上記新たなＩＰアドレスの取得手順を実行することによって、バンドオーバ前に上記新たなＩＰサブネットで使用すべきＩＰアドレスを取得しておく。

本発明では、ＭＮは、通信相手装置との通信に先立って、現在接続中のＩＰサブネットを経由して前記セッション管理サーバにセッション接続要求パケットを送信し、上記セッション管理サーバが、上記ＭＮから受信した上記セッション接続要求パケットを上記通信相手装置に転送することによって、上記ＭＮと上記通信相手装置との間にセッションを確立し、通信相手装置との通信中に発生する新たなＩＰサブネットへのハンドオーバの都度、上記セッション管理サーバを経由することなく、上記通信相手装置に該ＭＮのＩＰアドレスの変更を示す制御パケットを送信する。

また、本発明による移動ノード装置（ＭＮ）のＩＰアドレスの切替え方法は、固定網に接続された複数のＩＰサブネットを含み、第１のＩＰサブネットを経由して通信相手装置と通信中の移動ノード（ＭＮ）が、第２のＩＰサブネットに移動したとき、上記第１のＩＰサブネットから上記第２のＩＰサブネットにハンドオーバされる移動通信システムにおいて、
上記ＭＮが、上記第１のサブネットで取得した第１のＩＰアドレスを使用して、上記通信相手装置との間にコネクションの設定のための通信手順を実行するステップと、上記ＭＮが、上記コネクションを通して上記通信相手装置と通信中に、定期的に実行されるビーコン信号受信処理によって、上記第２のＩＰサブネットに所属した無線アクセスポイントを検知し、該第２のＩＰサブネットで使用すべき第２のＩＰアドレスを取得するステップと、上記第１のＩＰサブネットから上記第２のＩＰサブネットへのハンドオーバ条件が成立した時点で、上記ＭＮから上記通信相手装置に、上記コネクションの維持を指令するコネクション維持通知パケットを送信するステップと、上記ＭＮが、上記コネクション維持通知パケットを送信した後、該ＭＮのＩＰアドレスを上記第１のＩＰアドレスから上記第２のアドレスに変更することを示すＩＰアドレス変更通知パケットを上記通信相手装置に送信するステップとからなり、
上記通信相手装置が上記ＩＰアドレスの変更通知パケットを受信した後、上記ＭＮと上記通信相手装置が、上記ＭＮ用のＩＰアドレスを上記第１のＩＰアドレスから上記第２のＩＰアドレスに切り替えて、上記第２のＩＰサブネット経由で通信するようにしたことを特徴とする。

上記ＩＰアドレスの切替え方法は、例えば、上記通信相手装置がＷＥＢサーバ、上記コネクションがＴＣＰコネクションで、上記ＷＥＢサーバからデータをダウンロード中に、ＭＮのＩＰアドレスが変更される場合に有効となる。この場合も、ＭＮは、ビーコン信号受信処理によって、新たなＩＰサブネットに所属するアクセスポイントから送信されたビーコン信号を検知したとき、該ビーコン信号の送信元となったアクセスポイントに接続した後、該ＩＰサブネットで上記新たなＩＰアドレスの取得手順を実行することによって、バンドオーバ前に上記新たなＩＰサブネットで使用すべきＩＰアドレスを取得しておく。

本発明による移動ノード装置（ＭＮ）は、
移動中に定期的に実行されるビーコン信号受信処理によって、通信圏内に位置した新たな無線アクセスポイントを検出したとき、該無線アクセスポイントとの間で所定の接続手順を実行し、新たなＩＰサブネットに所属する無線アクセスポイントに接続されたとき、該ＩＰサブネットで使用すべき新たなＩＰアドレスの取得手順を実行するための第１手段と、
通信相手装置と通信を開始する時、現在接続中のＩＰサブネットで所得したＩＰアドレスを適用して、上記通信相手装置へのセッションの接続手順を実行するための第２手段と、
上記通信相手装置と通信中に、新たなＩＰサブネットに所属する無線アクセスポイントへのハンドオーバ条件が成立した時、上記通信相手装置に対して、該ＭＮのＩＰアドレスの変更を示す制御パケットを送信し、該ＭＮのＩＰアドレスを現在使用中のＩＰアドレスから上記新たなＩＰサブネットで取得済みの新たなＩＰアドレスに切替えるための第３手段を備えたことを特徴とする。

本発明の１実施例によれば、移動ノード装置（ＭＮ）が、複数の無線回線インタフェースと、端末状態管理テーブルとを備え、上記端末状態管理テーブルは、各無線回線インタフェースの識別子と対応付けて、使用すべきＩＰアドレスと、アクセスポイントの識別子と、該無線回線インタフェースの使用状態を示す接続フラグとからなる管理情報を記憶する複数のエントリからなり、
上記第１手段が、上記端末状態管理テーブルで空き状態のエントリと対応する無線回線インタフェースを通して、前記新たな無線アクセスポイントを探索し、新たに検出された無線アクセスポイントの識別子と、新たに取得したＩＰアドレスを上記エントリに記憶し、無線アクセスポイントの識別子が他のエントリよりも先に記憶されたエントリの接続フラグを現用状態、無線アクセスポイントの識別子が後で記憶されたエントリの接続フラグを予備状態に設定し、
上記第２手段が、上記端末状態管理テーブルで接続フラグが現用状態となっているエントリが示すＩＰアドレスと無線回線インタフェースを使用して、前記ＣＮへのセッションの接続手順を実行し、
上記第３手段が、接続フラグが現用状態を示している第１の無線アクセスポイントから、接続フラグが予備状態を示している新たなサブネットの第２の無線アクセスポイントへのハンドオーバ条件が成立したとき、上記第１の無線アクセスポイントと対応する接続フラグを予備状態、上記第２の無線アクセスポイントと対応する接続フラグを現用状態に切替え、該ＭＮのＩＰアドレスを上記第２の無線アクセスポイントと対応するＩＰアドレスに切り替えることを特徴としている。

また、本発明の１実施例では、移動ノード装置（ＭＮ）が、通信相手装置との呼制御の状態を示す接続管理テーブルを有し、上記第２手段が、上記接続管理テーブルに従って通信相手装置と通信中か否かを判定して、上記ＩＰアドレスの変更を示す制御パケットの送信要否を判断することを特徴としている。

本発明の他の実施例によれば、移動ノード装置（ＭＮ）は、
移動中に定期的に実行されるビーコン信号受信処理によって、通信圏内に位置した新たな無線アクセスポイントを検出したとき、該無線アクセスポイントとの間で所定の接続手順を実行し、新たなＩＰサブネットに所属する無線アクセスポイントに接続された場合、該ＩＰサブネットで使用すべき新たなＩＰアドレスの取得手順を実行し、接続状態にある無線アクセスポイントからのビーコン信号の受信レベルが閾値よりも低下したとき、該無線アクセスポイントとの接続を解除するための第１手段と、
通信相手装置と通信を開始する時、現在接続中のＩＰサブネットで所得したＩＰアドレスを適用して、上記固定網に接続されたセッション管理サーバとの間で、上記通信相手装置へのセッションの接続手順を実行するための第２手段と、
上記通信相手装置と通信中に、該ＭＮが新たなＩＰサブネットに所属する無線アクセスポイントにハンドオーバされた時、上記通信相手装置に対して、該ＭＮのＩＰアドレスの変更を示す制御パケットを送信し、該ＭＮのＩＰアドレスを現在使用中のＩＰアドレスから上記新たなＩＰアドレスに切替えるための第３手段とを有し、
上記第２手段が、上記通信相手装置と通信中に上記接続状態にある無線アクセスポイントからのビーコン信号の受信レベルが閾値よりも低下したとき、上記通信相手装置とセッション管理サーバにハンドオーバを予告する制御パケットを送信した後、新たな無線アクセスポイントとの間で所定の接続手順を実行することを特徴とする。

本発明の第２実施例のＩＰアドレス切替え方法によれば、ＭＮから通信相手装置とセッション管理サーバにハンドオーバを予告し、ハンドオーバを予告する制御パケットを受信した通信相手装置（またはセッション管理サーバ）が、呼制御のステータスとしてハンドオーバ中であることを記憶しておくことによって、ＭＮのハンドオーバ中に通話が一時的に途絶えた場合でも、通信相手装置とセッション管理サーバによって呼が切断されるのを回避することが可能となる。また、ＭＮからハンドオーバを予告する制御パケットを受信した通信相手装置（またはセッション管理サーバ）が、セッション管理サーバ（または通信相手装置）に対してステータスを同期させるための制御メッセージを送信させることによって、通信相手装置とセッション管理サーバの何れかが上記ハンドオーバ予告用の制御パケットを受信できなかった場合でも、互いのステータスをハンドオーバ状態に同期させることが可能となる。

また、本発明による移動ノード装置（ＭＮ）は、
移動中に定期的に実行されるビーコン信号受信処理によって、通信圏内に位置した新たな無線アクセスポイントを検出したとき、該無線アクセスポイントとの間で所定の接続手順を実行し、新たなＩＰサブネットに所属する無線アクセスポイントに接続されたとき、該ＩＰサブネットで使用すべき新たなＩＰアドレスの取得手順を実行するための第１手段と、
通信相手装置と通信を開始する時、現在接続中のＩＰサブネットで所得したＩＰアドレスを適用して、上記通信相手装置との間でコネクションの設定手順を実行するための第２手段と、
上記通信相手装置と通信中に、新たなＩＰサブネットに所属する無線アクセスポイントへのハンドオーバ条件が成立した時、上記通信相手装置に対して、上記コネクションの維持を指令するコネクション維持通知パケットを送信し、上記通信相手装置から応答パケットを受信した後で、上記通信相手装置に該ＭＮのＩＰアドレスの変更を示す制御パケットを送信し、該ＭＮのＩＰアドレスを現在使用中のＩＰアドレスから上記新たなＩＰサブネットで取得済みの新たなＩＰアドレスに切替えるための第３手段を備えたことを特徴とする。

更に、本発明のサーバは、複数の無線ＩＰサブネット間を移動する移動ノード装置（ＭＮ）との間にＴＣＰ（Transmission Control Protocol）コネクションを形成し、該ＴＣＰコネクションを通して上記ＭＮにデータを送信するサーバであって、
上記複数の無線ＩＰサブネットと接続される固定網上の１つのルータに接続される回線インタフェースと、
上記回線インタフェースに接続されたプロトコル処理部と、
送信データを宛先ＩＰアドレスと対応付けて一時的に格納するためのバッファメモリと、
上記ＭＮとの間でＴＣＰコネクション設定のための通信手順を実行した後、上記ＭＮからの要求に応じて、上記ＭＮに送信すべき一連のデータを上記バッファメモリに書き込む主制御部とからなり、
上記プロトコル処理部が、上記バッファメモリから読み出したデータを宛先ＩＰアドレスを含むデータパケットとして上記回線インタフェースに送出し、
上記主制御部が、上記ＭＮからコネクション維持通知を受信した時、上記プロトコル処理部に上記ＭＮ宛のデータ送信の停止を指令し、上記ＭＮからＩＰアドレスの変更通知を受信した時、上記プロトコル処理部に、変更されたＩＰアドレスによる上記ＭＮ宛のデータ送信の再開を指令することを特徴とする。

本発明によれば、ＭＮが新たなＩＰサブネットに所属するアクセスポイントを検知したとき、該ＩＰサブネットで使用すべき新たなＩＰアドレスを事前に取得しておき、新たなＩＰサブネットにハンドオーバする時点で、ＭＮから通信相手装置にＩＰアドレスの変更を通知して、ＭＮのＩＰアドレスを新たなＩＰアドレスに切り換えることによって、ハンドオーバを短時間で完了できる。

本発明によれば、モバイルＩＰにおけるホームエージェント（ＨＡ）や訪問先エージェント（ＦＡ）の介在を必要としないため、ＨＡ、ＦＡで行われる受信パケットのカプセル化やデカプセル化に起因したデータ遅延を回避できる。また、本発明は、ＭＮが、ＴＣＰコネクションを通して通信相手装置と通信する場合に、ＩＰアドレスの変更時にＴＣＰコネクションを再設定することなく、新たなＩＰアドレスで通信相手装置との通信を実行できる。

以下、本発明の実施例について、図面を参照して詳細に説明する。
図１は、本発明が適用される無線ＩＰネットワークの１例を示す。
ここに示した無線ＩＰネットワークは、中継網１とＩＰ網２とからなる固定網と、複数の無線ＩＰサブネット（無線ＬＡＮ：ＷＬＡＮ）とからなっている。第１の無線ＬＡＮ（ＷＬＡＮ）１０と、第２の無線ＬＡＮ（ＷＬＡＮ２）２０は、それぞれルータ８１−１、８１−２を介して中継網１に接続され、中継網１はルータ８１−３を介してＩＰ網１に接続されている。

ＷＬＡＮ１０は、ルータ８１−１に接続されたレイヤ２スイッチ（Ｌ２ＳＷ）８０−１と、Ｌ２ＳＷ８０−１に接続された無線基地局（以下、アクセスポイントＡＰと言う）６０−１および６０−２と、Ｌ２ＳＷ８０−１に接続されたＤＨＣＰ（Dynamic Host Configuration Protocol）サーバ７０−１とからなる。ＷＬＡＮ１０は、ＡＰ６０−１が形成する無線ＬＡＮ：ＷＬＡＮ１１と、ＡＰ６０−２が形成する無線ＬＡＮ：ＷＬＡＮ１２によって、１つのＩＰサブネットを形成している。ＤＨＣＰサーバ７０−１は、ＷＬＡＮ１０内に位置した各移動ノード（ＭＮ）３０に対してＩＰアドレスを付与する。

ＷＬＡＮ２０も、ＷＬＡＮ１０と同様に、ルータ８１−２に接続されたＬ２ＳＷ８０−２と、Ｌ２ＳＷ８０−２に接続されたアクセスポイントＡＰ６０−３および６０−４と、Ｌ２ＳＷ８０−２に接続されたＤＨＣＰサーバ７０−２とからなる。ＷＬＡＮ２０は、ＡＰ６０−３が形成する無線ＬＡＮ：ＷＬＡＮ２１と、ＡＰ６０−２が形成する無線ＬＡＮ：ＷＬＡＮ２２によって、ＷＬＡＮ１０とは別のＩＰサブネットを形成している。ＤＨＣＰサーバ７０−２は、ＷＬＡＮ２０内に位置した各移動ノード（ＭＮ）３０に対してＩＰアドレスを付与する。

中継網１には、ＶｏＩＰ（Voice over Internet Protocol）によってＩＰ電話セッションの接続、切断等のセッション制御を行うセッション管理サーバ（ＳＩＰサーバ）５０と、ＩＰ網２に接続された端末装置のＳＩＰＵＲＩとＩＰアドレスとの対応関係を記憶したロケーションサーバ９０が接続されている。ＩＰ網２は、実際には多数のＩＰパケット転送ノードと、各種のサーバおよび通信端末とを含んでいるが、ここでは簡単化のために、ルータ８１−３に接続されたＬ２ＳＷ８０−３と、Ｌ２ＳＷ８０−３に接続された端末装置４０とを示す。

以下の説明では、端末装置４０は、ＶｏＩＰによる電話通信において移動ノード（ＭＮ）３０の通信相手となるため、通信相手ノードＣＮと呼ぶことにする。図１において、ＭＮ３０、ＳＩＰサーバ５０、ＣＮ４０に付随して表示された文字列「xx-xx-xx-xx-xx-xx-xx」と「xxx.xxx.x.x」は、各装置に付与されたＭＡＣアドレスとＩＰアドレスを示している。ここでは、ＭＮ３０のＩＰアドレスが、ＷＬＡＮ１０では「192.168.0.1」、ＷＯＬＡＮ２０では「172.21.22.25」になっている。

図２は、移動ノード（ＭＮ）３０の１実施例を示すブロック構成図である。
ＭＮ３０は、アクセスポイント（ＡＰ）６０（６０−１〜６０−４）と通信するための複数の無線回線インタフェース３１（３１−１、３１−２）と、これらの無線回線インタフェースに接続されたプロトコル処理部３２と、内部バス３９を介してプロトコル処理部３２および無線回線インタフェース３１に接続されたプロセッサ３３と、プロトコル処理部３２に接続された音声信号の符号／復号器：ＣＯＤＥＣ３４と、内部バス３９に接続された表示部３６Ａ、入力部３６Ｂ、メモリ３７および３８とからなる。ＣＯＤＥＣ３４には、マイク３５Ａとスピーカ３５Ｂが接続されている。

メモリ３７には、プロセッサ３３が実行するソフトウェアとして、主制御ルーチン１００、呼制御ルーチン１１０と、ビーコン受信処理ルーチン１５０と、各種のアプリケーションプログラム３００が用意されている。また、メモリ３８には、端末状態管理テーブル３１０と、接続管理テーブル３２０とが形成されている。呼制御ルーチン１１０は、後で説明するように、受信したＳＩＰメッセージの種類によって異なる複数のメッセージ受信処理ルーチンからなっている。

プロセッサ３３は、ビーコン受信処理ルーチン１５０を定期的に実行し、後述するように、各アクセスポイント（ＡＰ）から送信されるビーコン信号を受信して、ＭＮ３０の通信圏内に位置するＡＰの探索、ビーコン受信レベルの監視、無線回線の切替え／解放などの動作を行う。
プロセッサ３３は、例えば、ビーコン受信処理ルーチン１５０によって、ＡＰ６０−１を探索すると、ＡＰ６０−１を介して、ＭＮ３０をＳＩＰサーバ５０に位置登録する。その後は、ＡＰ６０−１からのビーコン信号の受信レベルＳ１を監視し、受信レベルＳ１が所定の閾値ＴＨよりも低下したことを検知すると、ＡＰ６０−１との接続を解除する。

本実施例では、プロセッサ３３は、２つの無線回線インタフェース３１−１、３１−２の一方を現用系インタフェースとして、ＡＰとの交信、ＳＩＰサーバへの位置登録、および後述するＣＮとの接続手順を実行する。ＭＮ３０が、例えば、無線回線インタフェース３１−１を介してＡＰ６０−１に接続されている間、プロセッサ３３は、予備系となる他方の無線回線インタフェース３１−２で他のＡＰ、例えば、ＡＰ６０−２からの送信ビーコンを探索し、ＡＰ６０−２のビーコン受信レベルＳ２がＡＰ６０−１の受信レベルＳ１よりも大きくなった時、接続ＡＰの切替え（ハンドオフ）と、無線回線インタフェースの現用系／予備系の切替えを行う。

プロトコル処理部３２は、無線回線インタフェース３１−１、３１−２からの受信パケットを解析し、音声パケットはＣＯＤＥＣ３４に、音声以外のデータパケットと、呼制御メッセージを含む制御パケットおよびビーコン信号は、プロッサ３３に転送する。ＣＯＤＥＣ３４は、プロトコル処理部３２から音声パケットを受信すると、受信パケットから抽出された符号化音声信号を復号化して、スピーカ３５Ｂに出力すると共に、マイク３５Ａから入力された音声を符号化し、送信音声パケットとして、プロトコル処理部３２に出力する。

プロセッサ３３は、主制御ルーチン１００によって受信パケットを判定し、音声以外のデータパケットは、受信パケットと対応するアプリケーションプログラム３００によって処理する。これによって、表示部３６Ａへのデータ出力、またはメモリ３８に形成された所定のストレージエリアへの受信データの格納が行われる。ビーコン信号は、ビーコン受信処理ルーチン１５０で処理される。プロッサ３３は、呼制御メッセージを含む制御パケットを受信すると、呼制御ルーチン１１０を実行して、制御パケットに応じた応答動作を実行する。符号Ｓ１、Ｓ２は、ビーコン信号の受信レベルを示している。

図３は、端末状態管理テーブル３１０の１実施例を示す。
端末状態管理テーブル３１０は、無線回線インタフェースの識別番号（ポート番号）３１１と対応した複数のテーブルエントリからなり、各テーブルエントリは、移動ノード（ＭＮ）３０自身のＭＡＣアドレスを示すＭＡＣアドレス・フィールド３１２と、ＩＰサブネットで取得したＭＮのＩＰアドレスを示すＩＰアドレス・フィールド３１３と、接続ＡＰフィールド３１４と、接続フラグ・フィールド３１５とからなる。

接続ＡＰフィールド３１４は、ポート番号３１１（＝ｉ）をもつ無線回線インタフェース３１−ｉのアクセスポイントＡＰへの接続状態を示しており、ＭＮ３０が無線回線インタフェース３１−ｉを介して既に特定のＡＰに接続済みの状態では、接続ＡＰフィールド３１４には、接続されているＡＰの識別子が設定され、ＡＰに未接続の状態では、空き状態を示す状態コードが設定される。接続フラグ・フィールド３１５は、無線回線インタフェース３１−ｉの使用状態を示しており、本実施例では、フラグ「１」は、現用系インタフェースとして使用中の状態、フラグ「０」は、未使用中または予備系インタフェースとして使用中の状態を示す。端末状態管理テーブル３１０の利用方法については、後で詳述する。

図４は、接続管理テーブル３２０の１実施例を示す。
接続管理テーブル３２０は、ＳＩＰサーバ５０のＩＰアドレス３２１と対応づけて、通信相手ノード（ＣＮ）４０の識別情報であるＳＩＰＵＲＩ：３２２およびＩＰアドレス３２３と、通信制御における現在のステータス３２４と、ＳＩＰメッセージのコマンド・シーケンス（ＣＳｅｑ）３２５が記憶される。接続管理テーブル３２０の具体的な利用方法については、後で詳述する。

図５は、ＭＮ３０の通信相手となるＣＮ４０の１実施例を示す。
ＣＮ４０は、図１に示すＬ２ＳＷ８０−３と接続するための回線インタフェース４１と、回線インタフェース４１に接続されたプロトコル処理部４２と、内部バス４９を介してプロトコル処理部４２に接続されたプロッセサ４３と、プロトコル処理部４２に接続されたＣＯＤＥＣ４４と、内部バス４９に接続された表示部４６Ａ、入力部４６Ｂ、メモリ４７および４８とからなる。ＣＯＤＥＣ４４には、マイク４５Ａとスピーカ４５Ｂが接続されている。

メモリ４７には、プロセッサ４３が実行するソフトウェアとして、主制御ルーチン４００と、呼制御ルーチン４１０と、各種のアプリケーションプログラム４７０が用意されている。また、メモリ４８には、接続管理テーブル４８０が形成されている。

プロトコル処理部４２は、回線インタフェース４１から受信したパケットを解析し、音声パケットはＣＯＤＥＣ４４に転送し、音声以外のデータパケットと、呼制御メッセージを含む制御パケットは、プロッサ４３に転送する。ＣＯＤＥＣ４４は、プロトコル処理部４２から音声パケットを受信すると、受信パケットから抽出された符号化音声信号を復号化して、スピーカ４５Ｂに出力すると共に、マイク４５Ａから入力された音声を符号化し、送信音声パケットとして、プロトコル処理部４２に出力する。

プロセッサ４３は、主制御ルーチン４７によって受信パケットを判定し、音声以外のデータパケットは、受信パケットと対応するアプリケーションプログラム４７０によって処理する。これによって、表示部４６Ａへのデータ出力、またはメモリ４８に形成された所定のストレージエリアへのデータの格納が行われる。呼制御メッセージを含む制御パケットを受信すると、呼制御ルーチン４１０が実行され、受信した制御パケットに応じた応答動作が行なわれる。呼制御ルーチン４１０は、受信したＳＩＰメッセージの種類によって異なる複数のメッセージ受信処理ルーチンからなっている。

ＣＮの接続管理テーブル４８０には、図６に示すように、ＳＩＰサーバ５０のＭＡＣアドレス４２１およびＩＰアドレス４２２と、移動ノード（ＭＮ）３０のＳＩＰＵＲＩ４８３およびＩＰアドレス４８４と、通信制御における現在のステータス４８５と、ＳＩＰメッセージのコマンド・シーケンス（ＣＳｅｑ）４８６との対応関係が記憶される。接続管理テーブル４８０の具体的な利用方法については、後で詳述する。

図７は、ＳＩＰサーバ５０の１実施例を示す。
ＳＩＰサーバ５０は、中継網１に接続するための回線インタフェース５１と、回線インタフェース５１に接続されたプロトコル処理部５２と、内部バス５９を介してプロトコル処理部５２に接続されたプロッセサ５３と、内部バス５９に接続されたメモリ５４とからなる。メモリ５４には、本発明に関係するソフトウェアとして、ＳＩＰ処理ルーチン５００と、端末位置情報管理テーブル５１０と、接続管理テーブル５２０が用意されている。

端末位置情報管理テーブル５１０は、例えば、図８に示すように、位置登録を要求してきた端末の識別情報であるＳＩＰＵＲＩ５１１と対応づけて、要求元端末の現在のＩＰアドレス５１２と、アドレス変更前の旧ＩＰアドレス５１３を記憶している。端末位置情報管理テーブル５１０の具体的な利用方法については、後で詳述する。

ＳＩＰサーバが備える接続管理テーブル５２０は、図９に示すように、移動ノードＭＮ３０のＳＩＰＵＲＩ５２１、ＩＰアドレス５２２およびＵＤＰポート番号５２３と、通信相手ノード（ＣＮ）４０のＳＩＰＵＲＩ５２４、ＩＰアドレス５２５およびＵＤＰポート番号５２６と、通信制御における現在のステータス５２７と、ＳＩＰメッセージのコマンド・シーケンス（ＣＳｅｑ）５２８との対応関係を示す。接続管理テーブル５２０の具体的な利用方法については、後で詳述する。

図１０は、ＳＩＰメッセージを含む制御パケットのフォーマットを示す。
ＳＩＰメッセージは、ＩＰヘッダ２１０とＴＣＰ／ＵＤＰヘッダ２２０とを含むＩＰパケットのペイロード２３０に設定される。ＳＩＰメッセージは、メッセージ種類と宛先を示すスタートライン（Start-line）２３１と、ＳＩＰパラメータを含むメッセージヘッダ（Message-header）２３２と、端末間に論理的に形成されるコネクションの情報を記述したメッセージボディ（Message-body）２３３とからなっている。

ＩＰヘッダ２１０には、図１１（Ａ）に示ように、送信元ＩＰアドレス（Source Address：ＳＡ）２１１と、宛先ＩＰアドレス（destination Address：ＤＡ）２１２と、その他のヘッダ情報が含まれる。図１１（Ａ）は、ＭＮ３０が、図１に示したＷＬＡＮ１０内において送信元アドレスとして使用するＩＰアドレスの値を示し、図１１（Ｂ）は、ＷＬＡＮ１０からＷＬＡＮ２０に移動したＭＮ３０が、ＷＬＡＮ２０内において使用する新たなＩＰアドレスの値を示している。

次に、図１２〜図３０を参照して、ＭＮ３０が、ＡＰ６０−２を介してＳＩＰサーバ５０に位置登録する際に実行される位置登録フェーズＰＨ１と、ＭＮ３０がＣＮ４０と音声通話を開始する際に実行される接続フェーズＰＨ２におけるＭＮ３０、ＣＮ４０、ＳＩＰサーバ５０の動作について説明する。

図１２は、位置登録フェーズＰＨ１の通信シーケンス、図１３は、接続フェーズＰＨ２の通信シーケンスを示す。図１４〜図１６は、ＭＮ３０が実行するビーコン受信処理処理ルーチン１５０、Association Response受信処理ルーチン１９０、応答パケット（２００ＯＫ）受信処理ルーチン１２０のフローチャートを示す。また、図１７〜図２０は、ＳＩＰサーバ５０が実行するＲＥＧＩＳＴＥＲ受信処理ルーチン５３０、ＩＮＶＩＴＥ受信処理ルーチン５４０、応答パケット（２００ＯＫ）受信処理ルーチン５６０、ＡＣＫ受信処理ルーチン５７０のフローチャート、図２１、図２２は、ＣＮ４０が実行するＩＮＶＩＴＥ受信処理ルーチン４２０およびＡＣＫ受信処理ルーチン４３０のフローチャートを示す。図２３〜図３０は、位置登録フェーズ（ＰＨ１）と接続フェーズ（ＰＨ２）で送信される各種ＳＩＰメッセージのパケットフォーマットを例示している。

まず、位置登録フェーズ（ＰＨ１）について説明する。
ＭＮ３０は、無線ＬＡＮを利用してＣＮ４０との間にセッションを接続する前に、現在位置で通信可能なＡＰを検索する必要がある。そこで、ＭＮ３０（プロセッサ３３）は、図１４に示すビーコン受信処理ルーチン１５０を定期的に実行して（Ｓ１００）、ＡＰが定期的に送出しているビーコン信号（ＳＱ１００）を探索する（Ｓ１００）。

ビーコン受信処理ルーチン１５０では、プロセッサ３３は、端末状態管理テーブル３１０の接続ＡＰ３１４をチェックし、空き状態の無線回線インタフェース（ＩＮＦ）の有無を判定し（１５１）、もし、空きＩＮＦがあれば、このＩＮＦでＡＰ探索処理１６０を実行する。図１２で説明中の位置登録フェーズＰＨ１では、ＭＮ３０は初期状態にあり、図３（Ａ）のエントリＥＮ１、ＥＮ２が示すように、無線回線インタフェース３１−１（ポート番号１）と３１−２（ポート番号２）が、共に空き状態となっている。この場合、プロセッサ３３は、ＡＰ探索処理１６０を実行し、端末状態管理テーブル３１０で最初に検出された空きＩＮＦ、例えば、ポート番号１をもつ無線回線ＩＮＦ３１−１でビーコン信号を受信して（１６１）、受信ビーコン信号から送信元を示すＡＰ情報（ＡＰ識別子）を検出する（１６２）。ＡＰ識別子は、例えば、ＩＰサブネットの識別情報と、ＩＰサブネット内で各ＡＰに割り当てられたＡＰ番号とからなっている。

プロセッサ３３は、ＡＰ情報が検出できなければ、この処理ルーチン１５０を終了し、ＡＰ情報が検出された場合は、ＡＰ情報に基づいて、ビーコン送信元ＡＰが端末状態管理テーブル３１０に接続ＡＰ３１４として登録されたＡＰか否かを判定する（１６３）。初期状態では、ビーコン送信元ＡＰは接続中のＡＰではなく、且つ、ＭＮ３０には接続中のＡＰがないため、プロセッサ３３は、ビーコン送信元ＡＰ６０−２に接続要求（Association Request）を送信して（１６４、図１２のＳＱ１０１）、この処理ルーチンを終了する。空きＩＮＦが無くなった場合、あるいは、ステップ１６３で、既に接続中のＡＰからビーコンを受信した場合の処理については、後で詳述する。

ＭＮ３０は、接続要求（Association Request）を送信した後（ＳＱ１０１）、ＡＰ６０−２からの応答を待つ。接続要求（Association Request）を受信したＡＰ６０−２は、接続を了承したことを示す接続応答（Association Response）をＭＮ３０に返送する（ＳＱ１０２）。ＭＮ３０は、ＡＰ６０−２から接続応答（Association Response）を受信すると、図１５に示すAssociation Response受信処理ルーチン１９０を実行する。

Association Response受信処理ルーチン１９０において、プロセッサ３３は、端末状態管理テーブル３１０を参照して、接続中のＡＰの有無を判定する（１９１）。接続中ＡＰが無ければ、プロセッサ３３は、図３（Ｂ）に示すように、ビーコン送信元のＡＰ情報（ＡＰ６０−２の識別子：ＡＰ−２）を端末状態管理テーブル３１０のエントリＥＮ１に登録し、接続フラグを「１」に設定して（１９２、図１２のＳ１０１）、このルーチンを終了する。この場合、ＡＰ６０−２は、現用系ＡＰとして扱われる。以上の手順によって、ＭＮ３０とＡＰ６０−２との間に、接続（Association）が確立される（ＳＱ１０３）。

尚、無線回線ＩＮＦ３１−１を介してＡＰ６０−２と既に接続中の状態で、例えば、ＡＰ６０−３から接続応答（Association Response）を受信した場合は、プロセッサ３３は、図３（Ｄ）のエントリＥＮ２が示すように、ビーコン送信元ＡＰの識別子をエントリＥＮ２に登録し、接続フラグを「０」に設定する（１９３）。この場合、ＡＰ６０−３は、予備系ＡＰとして扱われる。

ＭＮ３０は、ＡＰ６０−２への接続が完了すると、ＷＬＡＮ１０で使用すべきＩＰアドレスが既に取得済みか否かを判定し、もし、取得していなければ、ＤＨＣＰサーバ７０−１に対して、ＩＰアドレスの取得要求（ＤＨＣＰＲＥＱ）パケットを送信する（ＳＱ１０４）。ＤＨＣＰＲＥＱパケット（ＳＱ１０４）を受信したＤＨＣＰサーバ７０−１は、ＭＮ３０にＩＰアドレス（「192.168.0.1」）を割り当て、上記ＩＰアドレスを示すＤＨＣＰＡＣＫパケットを返送する（ＳＱ１０５）。

ＭＮ３０は、ＤＨＣＰサーバ７０−１からＤＨＣＰＡＣＫパケットを受信すると、図３（Ｃ）に示すように、端末状態管理テーブル３８１のテーブルエントリＥＮ１に、ＤＨＣＰＡＣＫパケットから抽出したＩＰアドレスを登録する（Ｓ１０２）。この後、ＭＮ３０は、ＳＩＰサーバ５０に対して、位置登録のためのＲＥＧＩＳＴＥＲパケットを送信し（ＳＱ１０６）、図４（Ａ）に示すように、接続管理テーブル３２０のＳＩＰサーバ５０と対応するテーブルエントリにおいて、ステータス・フィールド３２４を「２００ＯＫ受信待ち」状態にし、コマンド・シーケンス番号（ＣＳｅｑ）フィールド３２５に、上記ＲＥＧＩＳＴＥＲパケットのＳＩＰメッセージに適用されたコマンド・シーケンス「101 REGISTER」を登録する（Ｓ１１１）。但し、接続管理テーブル３２０の更新は、ＲＥＧＩＳＴＥＲパケットの送信前に行ってもよい。

ＲＥＧＩＳＴＥＲパケットは、図２３に示すように、宛先ＩＰアドレスＤＡとして、ＳＩＰサーバ５０のＩＰアドレス「138.85.28.1」、送信元アドレスＳＡとして、ＭＮ３０のＩＰアドレス「192.168.0.1」を含み、ペイロード部にＲＥＧＩＳＴＥＲ用のＳＩＰメッセージを含む。このＳＩＰメッセージには、スタートラインにメッセージ種類「REGISTER」とＭＮ３０のＳＩＰＵＲＩ「MN＠xxx.com」を含む。

ＳＩＰサーバ５０のプロセッサ５３は、ＭＮ３０からＲＥＧＩＳＴＥＲパケットを受信すると、図１７に示すＲＥＧＩＳＴＥＲ受信処理ルーチン５３０を実行する。
ＲＥＧＩＳＴＥＲ受信処理ルーチン５３０において、プロセッサ５３は、受信パケットから、送信元ＭＮ３０の識別子であるＳＩＰＵＲＩ（「MN＠xxx.com」）とＩＰアドレス（「192.168.0.1」）を抽出し（５３１）、図８に示した端末位置情報管理テーブル５１０に、上記ＳＩＰＵＲＩが既に登録済みか否かを判定する（５３２）。ＲＥＧＩＳＴＥＲパケット送信元のＳＩＰＵＲＩが端末位置情報管理テーブル５６に未登録の場合、プロセッサ５３は、図８（Ａ）に示すように、端末位置情報管理テーブル５６のＳＩＰＵＲＩフィールド５１１と現ＩＰアドレス・フィールド５１２に、ＭＮ３０のＳＩＰＵＲＩとＩＰアドレスを登録し（５３７、図１２のＳ５１１）、応答メッセージ（２００ＯＫ）を含むパケットをＲＥＧＩＳＴＥＲパケットの送信元ＭＮ３０に返送する（５３８、図１２のＳＱ１０７）。

ＳＩＰサーバ５０が送信する２００ＯＫパケットは、図２４に示すように、スタートラインにメッセージ種別「200 OK」を含み、メッセージボディ部にＲＥＧＩＳＴＥＲパケットと同一のＣＳｅｑを含んでいる。尚、ＲＥＧＩＳＴＥＲパケット送信元のＳＩＰＵＲＩが既に登録済みの状態で、ＳＩＰサーバ５０が新たなＲＥＧＩＳＴＥＲパケットを受信した場合の処理については、後で詳述する。

ＭＮ３０のプロセッサ３３は、２００ＯＫパケットを受信すると、呼制御ルーチン１１０の一部となる図１６に示す２００ＯＫ受信処理ルーチン１２０を実行する。２００ＯＫ受信処理ルーチン１２０では、プロセッサ３３は、受信した２００ＯＫパケットから、ＣＳｅｑを抽出し（１２１）、これが接続管理テーブル３２０に記憶されたＣＳｅｑ３２５と一致するか否かを判定し（１２２）、ＣＳｅｑが不一致の場合は、受信した２００ＯＫパケットを廃棄して（１３５）、このルーチンを終了する。

ＣＳｅｑが一致した場合、プロセッサ３３は、ＣＳｅｑの内容から、受信した２００ＯＫパケットがＲＥＧＩＳＴＥＲに対する応答か否かを判定する（１２３）。今回の例では、２００ＯＫパケットは、ＳＱ１０６で送信したＲＥＧＩＳＴＥＲに対する応答となっているため、プロセッサ３３は、接続管理テーブル３２０のステータス３２４をチェックし（１２４）、変更通知応答待ちになっていた場合は、ステータスを通話状態に変更し（１３６）、ステータス３２４が、図４（Ａ）に示すように、２００ＯＫ待ちとなっていた場合は、接続管理テーブル３２０のステータスをクリアする（１３７、図１２のＳ１１２）。プロセッサ３３は、この後、ＳＩＰサーバ５０にＡＣＫパケットを返送して（１３８、図１２のＳＱ１０８）、このルーチンを終了する。

ステータス３２４が変更通知応答待ちになるのは、後述するように、ＭＮ３０がＣＮ４０との通話状態にある期間内に、ＭＮ３０の移動によってＭＡ３０のＩＰアドレスが変更され、ＭＮ３０からＳＩＰサーバ５０に、ＩＰアドレスの変更を示すＩＮＶＩＴＥパケットが送信された場合である。以下の説明では、通話状態にあるＭＮ３０が、ＳＩＰサーバ５０に対して新たなＩＰアドレスを通知するために送信するＩＮＶＩＴＥパケットを特にＲｅ−ＩＮＶＩＴＥパケットと言う。２００ＯＫパケットが、ＲＥＧＩＳＴＥＲ以外のＳＩＰメッセージに対する応答であった場合の処理１２５〜１３５については、後で詳述する。
以上のシーケンスによって、ＭＮ３０の位置登録フェーズＰＨ１が完了する。

図１３は、ＭＮ３０とＣＮ４０との接続フェーズＰＨ２の通信シーケンスを示す。
ＭＮ３０は、ＶｏＩＰ（Voice over Internet Protocol）でＣＮ４０と音声通話をする時、ＳＩＰのセッション接続要求メッセージであるＩＮＶＩＴＥメッセージを含むパケットをＳＩＰサーバ５０に送信し（ＳＱ２００）、接続管理テーブル３２０を更新する（Ｓ１２１）。ＭＮ３０が送信するＩＮＶＩＴＥパケットは、図２５に示すように、ｆｒｏｍヘッダにＭＮ３０のＳＩＰＵＲＩ、ＴｏヘッダにＣＮ４０のＳＩＰＵＲＩを含み、ｃラインにＭＮ３０のＩＰアドレスを含んでいる。ＩＮＶＩＴＥパケットを送信する時、接続管理テーブル３２０は、図４（Ｂ）に示すように、ステータス３２４が「２００ＯＫ待ち」状態を示し、ＣＳｅｑ３２５が、ＩＮＶＩＴＥパケットに設定されたＣＳｅｑの値「102 INVITE」を含むように、更新される。

ＩＮＶＩＴＥパケットを受信した時、ＳＩＰサーバ５０のプロセッサ５３は、図１８に示すＩＮＶＩＴＥ受信処理ルーチン５４０を実行する。
ＩＮＶＩＴＥ受信処理ルーチン５４０において、プロセッサ５３は、受信したＩＮＶＩＴＥパケットから、送信元（ＭＮ）のＳＩＰＵＲＩ、ＩＰアドレス（ＳＡ）およびＵＤＰポート番号（ＵＤＰｓｒｃ）と、宛先（ＣＮ）のＳＩＰＵＲＩおよびＵＤＰポート番号（ＵＤＰｄｓｔ）と、ＣＳｅｑとを抽出し（５４１）、宛先ＳＩＰＵＲＩで端末位置情報管理テーブル５１０を検索して（５４２）、宛先ＳＩＰＵＲＩが、ＳＩＰＵＲＩ５１１として登録済みか否かを判定する（５４３）。

宛先ＳＩＰＵＲＩが端末位置情報管理テーブルに未登録の場合、プロセッサ５３は、例えば、図示しないＳＩＰアドレス管理テーブルを参照して、宛先ＳＩＰＵＲＩを管理している他のＳＩＰサーバが既知か否かを判定し（５４９）、既知の場合は、受信したＩＮＶＩＴＥパケットを他のＳＩＰサーバに転送し（５５０）、そうでなければ、受信したＩＮＶＩＴＥパケットを廃棄して（５５１）、このルーチンを終了する。

宛先ＳＩＰＵＲＩが端末位置情報管理テーブルに登録されていた場合、プロセッサ５３は、宛先端末ＣＮのＩＰアドレスが、宛先ＳＩＰＵＲＩと対応付けて、端末位置情報管理テーブル５１０に登録済みか否かを判定する（５４４）。宛先端末ＣＮのＩＰアドレスが端末位置情報管理テーブル５１０に登録されていた場合、プロセッ５３は、図９（Ａ）に示すように、接続管理テーブル５２０に、ＩＮＶＩＴＥパケットから抽出した送信元（ＭＮ）のＳＩＰＵＲＩ、ＩＰアドレスおよびＵＤＰポート番号をＭＮ情報として登録し、ＩＮＶＩＴＥパケットから抽出した宛先装置（ＣＮ）のＳＩＰＵＲＩおよびＵＤＰポート番号と、端末位置情報管理テーブル５１０が示すＣＮのＩＰアドレスをＣＮ情報として登録し、ステータス５２７を「２００ＯＫ待ち」、ＣＳｅｑ５２８を受信パケットのＣｓｅｑの値「102 INVITE」に設定して（５４７、図１３のＳ５２１）、宛先端末ＣＮにＩＮＶＩＴＥパケットを転送する（５４８、図１３のＳＱ２０１）。

もし、宛先端末ＣＮのＩＰアドレスが端末位置情報管理テーブル５１０に登録されていなかった場合、プロセッ５３は、例えば、ロケーションサーバ９０に宛先ＳＩＰＵＲＩと対応するＩＰアドレスを問合せ（５４５）、ロケーションサーバ９０から通知されたＩＰアドレスを宛先ＳＩＰＵＲＩと対応付けて端末位置情報管理テーブル５１０に登録（５４６）した後、ステップ５４７、５４８を実行する。

ＳＩＰサーバ（５０）が宛先端末ＣＮに転送するＩＮＶＩＴＥパケットは、図２６に示すように、ＩＮＶＩＴＥメッセージにＳＩＰサーバを経由したことを示すＶｉａヘッダを追加し、ＤＡをＣＮ４０のＩＰアドレス、ＳＡをＳＩＰサーバ５０のＩＰアドレスに書き換えたものとなっている。追加されたＶｉａヘッダには、ＳＩＰサーバのＳＩＰＵＲＩが設定されている。

ＣＮ４０のプロセッサ４３は、ＳＩＰサーバ５０からＩＮＶＩＴＥパケットを受信すると、図２１に示すＩＮＶＩＴＥ受信処理ルーチン４２０を実行する。
ＩＮＶＩＴＥ受信処理ルーチン４２０において、プロセッサ４３は、受信したＩＮＶＩＴＥパケットから、ＳＩＰサーバおよび送信元ＭＮのＳＩＰＵＲＩおよびＩＰアドレスと、ＣＳｅｑを抽出（４２１）した後、ＩＮＶＩＴＥメッセージに変更フラグ（Change-Flag）が含まれているか否かを判定する（４２２）。

変更フラグは、後で詳述するように、ＭＮ３０が移動先で新たなＩＰアドレスを取得した時、このＩＰアドレスをＣＮに通知するために送信するＲｅ−ＩＮＶＩＴＥメッセージに設定される情報であり、今回、ＣＮ４０が受信した通常のＩＮＶＩＴＥメッセージは変更フラグを含んでいない。

従って、今回は、プロセッサ４３は、図６（Ａ）に示すように、接続管理テーブル４８０に、ＳＩＰサーバ情報（４８１、４８２）として、受信パケットから抽出したＳＩＰサーバのＳＩＰＵＲＩとＩＰアドレスを含み、ＭＮ情報（４８３、４８４）として、受信パケットから抽出したＭＮ３０のＳＩＰＵＲＩとＩＰアドレスを含み、ステータス５８５を「ＡＣＫ待ち」、ＣＳｅｑ４８６に受信パケットのＣＳｅｑの値「102 INVITE」を含む新たなテーブルエントリを登録し（４２６、図１３のＳ４２１）、ＳＩＰサーバ５０にＩＮＶＩＴＥに対する応答メッセージ２００ＯＫを含むパケットを送信して（４２７、図１３のＳＱ２０２）、このルーチンを終了する。

ＣＮ４０が送信する２００ＯＫメッセージは、図２７に示すように、メッセージ種類（200 OK）を示すスタートラインと、ＣＮ４０のＩＰアドレスを示すｃライン以外は、ＩＮＶＩＴＥメッセージと同じ内容となっている。

ＳＩＰサーバ５０のプロセッサ５３は、ＣＮ４０から２００ＯＫパケットを受信すると、図１９に示す２００ＯＫ受信処理ルーチン５６０を実行する。
２００ＯＫ受信処理ルーチン５６０において、プロセッサ５３は、受信した２００ＯＫパケットのＦｒｏｍヘッダが示す送信元（ＭＮ）のＳＩＰＵＲＩと、Ｔｏヘッダが示す宛先端末（ＣＮ）のＳＩＰＵＲＩと、ＣＳｅｑを抽出し（５６１）、送信元ＳＩＰＵＲＩで図９に示す接続管理テーブル５２０を検索し（５６２）、ＳＩＰＵＲＩ５２１、５２４が送信元のＳＩＰＵＲＩ、宛先端末（ＣＮ）のＳＩＰＵＲＩに一致したテーブルエントリが登録されているか否かを判定する（５６３）。もし、これらのＳＩＰＵＲＩに一致したテーブルエントリが接続管理テーブル５２０に登録されていなかった場合、プロセッサ５３は、受信した２００ＯＫパケットを廃棄し（５６９）、このルーチンを終了する。

接続管理テーブル６２０に目的エントリが登録されていた場合、プロセッサ５３は、受信パケットから抽出したＣＳｅｑが、目的エントリのＣＳｅｑ５２８と一致しているか否かを判定し（５６４）、一致していなければ、受信した２００ＯＫパケットを廃棄し（５６９）、このルーチンを終了する。ＣＳｅｑが一致した場合、プロセッサ５３は、受信パケットから抽出したＣＳｅｑの内容から、今回受信した２００ＯＫパケットが、ＢＹＥメッセージに対する応答パケットか否かを判定する（５６５）。

２００ＯＫパケットが、ＢＹＥメッセージに対する応答パケットの場合、プロセッサ５３は、接続管理テーブル６２０から、今回検索されたテーブルエントリ（目的エントリ）を削除して（５６７）、２００ＯＫパケットをＢＹＥメッセージの送信元（ＭＮ３０）に転送して（５６８）、このルーチンを終了する。２００ＯＫパケットが、ＢＹＥメッセージに対する応答パケットではなかった場合、すなわち、今回の受信パケットのように、２００ＯＫパケットが、ＩＮＶＩＴＥメッセージに対する応答パケットの場合、プロセッサ５３は、図９（Ｂ）に示すように、上記目的エントリのステータス５２７を「ＡＣＫ待ち」に変更して（５６６、図１３のＳ５２２）、２００ＯＫパケットをＩＮＶＩＴＥメッセージの送信元（ＭＮ３０）に転送して（５６８、図１３のＳＱ２０３）、このルーチンを終了する。

ＳＩＰサーバ５０からＭＮ３０に転送される２００ＯＫパケットは、図２８に示すように、ＣＮ４０から受信した２００ＯＫパケットから、ＳＩＰサーバ５０のＶｉａヘッダを除去し、ＩＰヘッダの宛先ＩＰアドレスＤＡと、送信元ＩＰアドレスＳＡを書き換えたものとなっている。

ＭＮ３０のプロセッサ３３は、２００ＯＫパケットを受信すると、図１６に示した２００ＯＫ受信処理ルーチン５６０を実行する。今回受信した２００ＯＫパケットは、通常のＩＮＶＩＴＥに対する応答パケットであるため、ステップ１２３の判定結果が否（ＮＯ）となり、プロセッサ３３は、受信した２００ＯＫパケットが、ＢＹＥに対する応答パケットか否かを判定する（１２５）。２００ＯＫパケットが、ＢＹＥに対する応答パケットの場合は、プロセッサ３３は、接続管理テーブル３２０から、受信した２００ＯＫパケットのＣＳｅｑと一致したテーブルエントリを削除し（１３４）、受信した２００ＯＫパケットを廃棄して（１３５）、このルーチンを終了する。ＢＹＥパケットの発行については、後で詳述する。

２００ＯＫパケットが、ＩＮＶＩＴＥに対する応答パケットの場合、ステップ１２５の判定結果が否（ＮＯ）となるため、プロセッサ３３は、受信した２００ＯＫパケットのＴｏヘッダから、ＣＮのＳＩＰＵＲＩを抽出して（１２６）、ＳＩＰＵＲＩが、接続管理テーブル３２０に記憶されたＣＮのＳＩＰＵＲＩ３２２と一致するか否かを判定する（１２７）。ＣＮのＳＩＰＵＲＩが不一致の場合、プロセッサ３３は、受信した２００ＯＫパケットを廃棄して（１３５）、このルーチンを終了する。

ＣＮのＳＩＰＵＲＩが一致した場合、プロセッサ３３は、受信した２００ＯＫパケットのｃラインが示すＣＮのＩＰアドレスが、接続管理テーブル３２０に登録済みか否かを判定する（１２８）。ＣＮのＩＰアドレスが既に登録済みであれば、プロセッサ３３は、接続管理テーブル３２０のステータス３２４が、変更通知応答待ち状態になっているか否かを判定する（１３０）。変更通知応答待ちは、後で詳述するように、ＭＮ３０が新たなＩＰアドレスをＣＮ４０に通知するためのＲｅ−ＩＮＶＩＴＥパケットを送信した場合に発生する。ＣＮのＩＰアドレスが接続管理テーブル３２０に未登録の場合、プロセッサ３３は、受信した２００ＯＫパケットのｃラインが示すＣＮのＩＰアドレスを接続管理テーブル３２０にＩＰアドレス３２３として登録（１２９）した後、ステータスの判定（１３０）を実行する。

今回は、ＭＮ３０が受信した２００ＯＫパケットは、通常のＩＮＶＩＴＥに対する応答パケットであり、接続管理テーブル３２０のステータス３２４は、図４（Ｂ）に示すように、通常の２００ＯＫ待ち状態となっている。この場合、プロセッサ３３は、図４（Ｃ）に示すように、接続管理テーブル３２０のステータスを通話状態に変更し（１３１、図１３のＳ１２２）、ＳＩＰサーバ５０に、図２９に示すＡＣＫパケットを送信して（１３８、図１３のＳＱ２０４）、このルーチンを終了する。

ＳＩＰサーバ５０のプロセッサ５３は、２００ＯＫに対するＡＣＫパケットを受信すると、図２０に示すＡＣＫ受信処理ルーチン５７０を実行する。
ＡＣＫ受信処理ルーチン５７０において、プロセッサ５３は、受信したＡＣＫパケットから、Ｆｒｏｍヘッダが示す送信元（ＭＮ）のＳＩＰＵＲＩと、Ｔｏヘッダが示す宛先（ＣＮ）のＳＩＰＵＲＩと、ＩＰヘッダのＳＡが示す送信元（ＭＮ）のＩＰアドレスと、ＣＳｅｑを抽出し（５７１）、宛先ＳＩＰＵＲＩで接続管理テーブル５２０を検索する（５７２）。検索の結果（５７３）、接続管理テーブル５２０に、ＣＮのＳＩＰＵＲＩ５２４が宛先ＳＩＰＵＲＩと一致する目的のテーブルエントリがなければ、プロセッサ５３は、受信したＡＣＫパケットを廃棄して（５７７）、このルーチンを終了する。

接続管理テーブル５２０に目的のテーブルエントリがあった場合、プロセッサ５３は、ＡＣＫパケットのＣＳｅｑが、上記テーブルエントリのＣＳｅｑ５２８と一致するか否かを判定し（５７４）、不一致の場合は、受信したＡＣＫパケットを廃棄して（５７７）、このルーチンを終了する。ＣＳｅｑが一致した場合、プロセッサ５３は、図９（Ｃ）に示すように、接続管理テーブルのステータス５２７を「通話」状態に変更し（５７５、図３のＳ５２３）、ＡＣＫパケットを宛先端末（ＣＮ４０）に転送して（５７６、図１３のＳＱ２０５）、このルーチンを終了する。ＳＩＰサーバ５０からＣＮ４０に転送されるＡＣＫパケットは、図３０に示すように、ＭＮ３０から受信したＡＣＫパケットにＶｉａヘッダを追加し、ＩＰヘッダの宛先アドレスＤＡと送信元ＩＰアドレスＳＡを書き換えたものとなっている。

ＣＮ４０のプロセッサ４３は、ＳＩＰサーバ５０からＡＣＫパケットを受信すると、図２２に示すＡＣＫ受信処理ルーチン４３０を実行する。
ＡＣＫ受信処理ルーチン４３０において、プロセッサ４３は、受信したＡＣＫパケットから送信元（ＭＮ）のＳＩＰＵＲＩとＣＳｅｑを抽出し（４３１）、抽出されたＳＩＰＵＲＩを検索キーとして、接続管理テーブル４８０を検索する（４３２）。検索の結果（４３３）、接続管理テーブル４８０に、ＭＮのＳＩＰＵＲＩ４８３が検索キーと一致する目的エントリが存在していなかった場合、プロセッサ４３は、受信したＡＣＫパケットを廃棄して（４３６）、このルーチンを終了する。

接続管理テーブル４８０から目的エントリを検索できた場合、プロセッサ４３は、ＡＣＫパケットから抽出したＣＳｅｑと上記目的エントリのＣＳｅｑ４８６とを照合し（４３４）、ＣＳｅｑが一致していなければ、受信したＡＣＫパケットを廃棄して（４３６）、このルーチンを終了する。ＣＳｅｑが一致した場合、プロセッサ４３は、図６（Ｂ）に示すように、接続管理テーブルのステータス４８５を「通話」状態に変更して（４３５、図１３のＳ４２２）、このルーチンを終了する。

以上の手順によって、接続フェーズＰＨ２が完了し、移動端末ＭＮ３０が、現用系の無線回線インタフェース３１−１（ＩＮＦ１）を介して、通信相手端末ＣＮ４０とＲＴＰの音声通話状態（ＳＱ２０６−１、ＳＱ２０６−２）に移行できる。

次に、図３１、図３２を参照して、ＣＮ４０と音声通話状態にあるＭＮ３０が、ＷＬＡＮ１０からＷＬＡＮ２０に移動中に実行される通信シーケンス（移動中フェーズＰＨ３）について説明する。
ＣＮ４０と音声通話状態にあるＭＮ３０は、図３１に示すように、移動中にも周期的にＡＰ探索を実行している（Ｓ１００）。ＭＮ３０が、ＷＬＡＮ１０からＷＬＡＮ２０に向かって移動すると、ＷＬＡＮ１０内で接続中のＡＰ６０−２から送信されたビーコン信号（ＳＱ３０１）以外に、ＷＬＡＮ２０内に位置したＡＰ６０−３から送信された新たなビーコン信号（ＳＱ３０２）が受信可能となる。

ＭＮ３０がＷＬＡＮ２０に接近すると、ＡＰ６０−３から送信された新たなビーコン信号が、図１４に示したビーコン受信処理ルーチン１５０のＡＰ探索１６０において、空きインタフェース３１−２で受信される（１６１）。ＭＮ３０のプロセッサ３３は、受信したビーコン信号からＡＰ情報（ＡＰ識別子）を抽出し（１６２）、ビーコン送信元（ＡＰ−３）のＡＰ識別子「ＡＰ−３」が、端末状態管理テーブル３１０に接続ＡＰ３１４として登録されたＡＰ６０−２の識別子「ＡＰ−２」とは異なることを検知すると（１６３）、ビーコン送信元のＡＰ６０−３に接続要求（Association Request）を送信する（１６４、図３１のＳＱ３０３）。

接続要求（Association Request）を受信したＡＰ６０−３は、接続を了承すると、ＭＮ３０に接続応答（Association Response）を送信する（ＳＱ３０４）。ＭＮ３０のプロセッサ３３は、ＡＰ６０−３からの接続応答（Association Response）を受信すると、図１５に示したAssociation Response受信処理ルーチン１９０を実行する。

Association Response受信処理ルーチン１９０において、プロセッサ３３は、端末状態管理テーブル３１０の接続ＡＰ３１４を参照して、既に接続中のＡＰがあるか否かを判定する（１９１）。今回は、接続ＡＰ３１４として、ＡＰ６０−２の識別子「ＡＰ−２」が登録されているため、プロセッサ３３は、図３（Ｄ）に示すように、接続管理テーブル３１０の空きＩＮＦ（ポート番号：２）と対応するテーブルエントリＥＮ２の接続ＡＰ３１４に、ビーコン送信元ＡＰ６０−３の識別子「ＡＰ−３」を登録し、接続フラグ３１５に、予備系を示す「０」を設定して（１９３、図３１のＳ１０１）、このルーチンを終了する。以上のシーケンスによって、ＭＮ３０とＡＰ６０−３との間に接続（Association）が確立される（ＳＱ３０５）。

ＭＮ３０は、端末状態管理テーブルに登録されたＡＰ６０−３、ＡＰ６−２のＡＰ識別子から、ＡＰ６０−３がＡＰ６０−２とは異なったＷＬＡＮ（ＩＰサブネット）２０に所属していることが判明すると、ＷＬＡＮ２０内で使用すべき新たなＩＰアドレスを取得するために、ＤＨＣＰサーバ７０−２に対して、ＤＨＣＰＲＥＱパケットを送信する（ＳＱ３０６）。

ＤＨＣＰサーバ７０−２は、ＤＨＣＰＲＥＱに応答して、ＭＮ３０にＩＰアドレス「172.21.22.25」を割り当て、このＩＰアドレスを示すＤＨＣＰＡＣＫパケットをＡＰ６０−３に送信する（ＳＱ３０７）。ＭＮ３０は、ＤＨＣＰＡＣＫパケットを受信すると、図３（Ｅ）に示すように、ＤＨＣＰＡＣＫパケットから抽出した新たなＩＰアドレス「172.21.22.25」を端末状態管理テーブル３１０に登録する（Ｓ１０２）。尚、ＭＮ３０の移動先ＡＰが、例えば、ＡＰ３０−１にように、ＡＰ６０−２と同じＷＬＡＮ１０に所属していた場合、移動先で新たなＩＰアドレスを取得する必要はない。この場合、端末状態管理テーブル３１０のエントリＥＮ１に登録されているＩＰアドレスをエントリＥＮ２にコピーすればよい。

ＭＮ３０のプロセッサ３３は、ＡＰ６０−２および６０−３と接続された状態でも、ビーコン受信処理ルーチン１５０を定期的に実行し、ＡＰ６０−２のビーコン信号（ＳＱ３０８）とＡＰ６０−３のビーコン信号（ＳＱ３０９）を監視する。ＭＮ３０が、ＡＰ６０−２、６０−３と接続状態にある間は、空きインタフェースが無くなっているため、図１４に示したビーコン受信処理ルーチン１５０において、プロセッサ３３は、無線回線切替え判定１７０と無線回線の解放判定１８０を実行する。

無線回線切替え判定１７０では、プロセッサ３３は、現用系ＩＮＦで接続中のＡＰ６０−２からのビーコン受信レベルＳ１と、予備系ＩＮＦで接続中のＡＰ６０−３からのビーコン受信レベルＳ２を検出し（１７１、１７２）、Ｓ１とＳ２を比較する（１７３）。

プロセッサ３３は、現用系の受信レベルＳ１が予備系の受信レベルＳ２以上であれば、無線回線切替え判定１７０を終了して、無線回線解放判定１８０を実行する。予備系の受信レベルＳ２が、現用系の受信レベルＳ１がよりも大きくなった時、プロセッサは、図３（Ｆ）に示すように、端末状態管理テーブル３１０の接続フラグ３１５の状態を書き替えて（１７４）、ＡＰ６０−３を現用系、ＡＰ６０−２を予備系に切替える（図３１のＳ１０３）。このように、現用系となるＡＰを電波状況の良いＡＰに切替えることによって、ＭＮ３０は、電波状態が良好なＡＰを経由してＣＮ４０との音声通話を継続することが可能となる。

端末状態管理テーブル３１０上で現用系と予備系のＡＰを切替えたプロセッサ３３は、接続管理テーブル３２０のステータス３２４をチェックする（１７５）。プロセッサ３３は、ステータス３２４が通話状態でなければ、無線回線解放判定１８０を実行する。ステータス３２４が通話状態となっていた場合、プロセッサ３３は、端末状態管理テーブル３１０に登録されたエントリＥＮ１、ＥＮ２のＩＰアドレス３１３を比較して、ＩＰアドレス切替えの要否を判定する（１７６）。ＩＰアドレス切替えの必要がなければ、プロセッサ３３は、無線回線解放判定１８０を実行し、ＩＰアドレスが切り替わる場合は、音声通話中のＣＮ４０に対して、新たなＩＰアドレスを通知するためのＲｅ−ＩＮＶＩＴＥパケットを送信（１７７、図３２のＳＱ３１０）した後、無線回線解放判定１８０を実行する。Ｒｅ−ＩＮＶＩＴＥパケット送信後の通信シーケンスについては、図３２〜図３６を参照して、後で詳述する。

無線回線解放判定１８０では、プロセッサ３３は、ビーコン受信レベル（Ｓ１またはＳ２）を閾値ＴＨと比較し（１８１）、ビーコン受信レベルがＴＨ以上であれば、今回のビーコン受信処理ルーチン１５０を終了する。ビーコン受信レベルが閾値ＴＨよりも小さくなった時、プロセッサ３３は、端末状態管理テーブル３１０において、ビーコン送信元ＡＰの識別子を接続ＡＰ３１４から削除し、接続フラグ３１５を「０」にして（１８２）、ビーコン送信元ＡＰに接続（Association）解除パケットを送信する（１８３）。

例えば、ＡＰ６０−２からのビーコン受信レベルが閾値ＴＨよりも低下した場合、無線回線解放判定１８０を実行することによって、端末状態管理テーブル３１０は、図３（Ｇ）の状態になる。無線回線解放判定１８０は、ＭＮ３０に空きインタフェースがある時も、空きインタフェースで受信された接続中ＡＰのビーコン信号に対して実行される。

ＭＮ３０が、ＷＬＡＮ１０からＷＬＡＮ２０に移動すると、ＳＩＰＵＲＩとＭＡＣアドレスには変化はないが、ＭＮ３０のＩＰアドレスが、旧ＩＰアドレス「192.168.0.1」から、ＷＬＡＮ２０で有効な新ＩＰアドレス「172.21.22.25」に切り替わる。本実施例では、ＣＮ４０と通話状態にあるＭＮ３０が、端末状態管理テーブル３１０上で現用系ＡＰを切替えたとき（Ｓ１０３）、図３２に示すように、Ｒｅ−ＩＮＶＩＴＥパケットの送信（ＳＱ３１０）によって、ＭＮ３０のＩＰアドレスの変更をＣＮ４０に通知する。

Ｒｅ−ＩＮＶＩＴＥパケットは、例えば、図３３に示すように、ＳＩＰメッセージのスタートラインに、図２５に示した通常のＩＮＶＩＴＥと同様のメッセージ種別を含む。Ｒｅ−ＩＮＶＩＴＥのＳＩＰメッセージには、本実施例では、これがＩＰアドレスの変更を通知するためのものであることを示すために、変更フラグ（Change-Flag）１０００が付加してある。変更フラグには、ＭＮ３０がこれまで使用してきた旧ＩＰアドレス（変更前のＩＰアドレス）の値「192.168.0.1」が記述され、新たなＩＰアドレスの値「172.21.22.25」は、ｃラインに記述されている。また、Ｒｅ−ＩＮＶＩＴＥパケットのＩＰヘッダは、宛先ＩＰアドレスＤＡとして、ＣＮ４０のＩＰアドレスが設定されている。

図３３に示したＲｅ−ＩＮＶＩＴＥパケットでは、ＩＰヘッダの送信元ＩＰアドレス（ＳＡ）１００１として、新ＩＰアドレス「172.21.22.25」が使用されているが、旧ＩＰアドレスを変更フラグ１０００で通知する代わりに、送信元ＩＰアドレス（ＳＡ）に旧ＩＰアドレス「192.168.0.1」を使用して、Ｒｅ−ＩＮＶＩＴＥパケットをＡＰ６０−２経由でＣＮ４０に転送するようにしてもよい。

ＭＮ３０は、Ｒｅ−ＩＮＶＩＴＥパケットを送信（ＳＱ３１０）した後、図４（Ｄ）に示すように、接続管理テーブル３２０のＣＳｅｑ３２５に、Ｒｅ−ＩＮＶＩＴＥで使用されたＣＳｅｑと同じ値「103 INVITE」を設定し、ステータス３２４を「変更通知応答待ち」状態に変更する（Ｓ１２３）。但し、接続管理テーブル３２０の更新（Ｓ１２３）は、Ｒｅ−ＩＮＶＩＴＥパケットの送信に先立って行うようにしてもよい。

ＣＮ４０のプロセッサ４３は、ＭＮ３０からＲｅ−ＩＮＶＩＴＥパケットを受信すると、図２１に示したＩＮＶＩＴＥ受信処理ルーチン４２０を実行する。
ＩＮＶＩＴＥ受信処理ルーチン４２０において、プロセッサ４３は、受信パケットから送信元のＳＩＰＵＲＩおよびＩＰアドレスと、ＣＳｅｑを抽出（４２１）した後、受信パケットのＳＩＰメッセージに変更フラグ（Change-Flag）が付加されているか否かを判定する（４２２）。ＳＩＰメッセージが変更フラグを含み、受信パケットがＲｅ−ＩＮＶＩＴＥパケットと判定された場合、プロセッサ４３は、受信パケットから抽出された送信元（ＭＮ３０）のＳＩＰＵＲＩで、図６に示す接続管理テーブル４８０を検索し、送信元ＳＩＰＵＲＩがＳＩＰＵＲＩ４８３として登録されているか否かを判定する（４２３）。

送信元ＳＩＰＵＲＩが未登録の場合、プロセッサ４３は、受信したＲｅ−ＩＮＶＩＴＥパケットを廃棄して（４２８）、このルーチンを終了する。送信元ＳＩＰＵＲＩが接続管理テーブル４８０に登録されていた場合、プロセッサ４３は、Ｒｅ−ＩＮＶＩＴＥパケットから、ＭＮ３０の新、旧のＩＰアドレスを抽出し（４２４）、図６（Ｃ）に示すように、接続管理テーブル４８０の送信元ＳＩＰＵＲＩと対応するテーブルエントリにおいて、ＭＮのＩＰアドレス４８４を旧ＩＰアドレスから新ＩＰアドレスに変更し、ＣＳｅｑ４８６の値を更新する（４２５、図３２のＳ４２３）。この後、プロセッサ４３は、Ｒｅ−ＩＮＶＩＴＥパケットの送信元ＭＮに対して、図３４に示す応答パケット（２００ＯＫ）を送信して（４２７、図３１のＳＱ３１１）、このルーチンを終了する。

ＭＮ３０のプロセッサ３３は、ＣＮ４０から２００ＯＫパケットを受信すると、図１６に示した２００ＯＫ受信処理ルーチン１２０を実行する。
受信した２００ＯＫパケットが、Ｒｅ−ＩＮＶＩＴＥに対する応答パケットの場合、２００ＯＫ受信処理ルーチン１２０のステップ１２３、１２５の判定結果が否（ＮＯ）となるため、プロセッサ３３は、受信した２００ＯＫパケットのＴｏヘッダから、ＣＮのＳＩＰＵＲＩを抽出し（１２６）、ＣＮのＳＩＰＵＲＩが、接続管理テーブル３２０に記憶されたＳＩＰＵＲＩ３２２と一致するか否かを判定する（１２７）。ＣＮのＳＩＰＵＲＩが不一致の場合、プロセッサ３３は、受信した２００ＯＫパケットを廃棄して（１３３）、このルーチンを終了する。

ＣＮのＳＩＰＵＲＩが一致した場合、プロセッサ３３は、受信した２００ＯＫパケットのｃラインが示すＣＮのＩＰアドレスが、接続管理テーブル３２０にＩＰアドレス３２３として登録済みか否かを判定する（１２８）。本実施例の場合、図４（Ｄ）に示すように、ＣＮのＩＰアドレスが接続管理テーブル３２０に既に登録済みとなっているため、プロセッサ３３は、接続管理テーブル３２０のステータス３２５が、変更通知応答待ち状態か否かを判定する（１３０）。Ｒｅ−ＩＮＶＩＴＥパケットを送信した時、ステータス３２５が変更通知応答待ち状態となっており、ＭＮ３０は、ＣＮ４０からＲｅ−ＩＮＶＩＴＥに対する２００ＯＫパケットを受信したことによって、新たなＩＰアドレスでＣＮ４０と通信することが可能となる（ＳＱ３１２−１、ＳＱ３１２−２）。

本実施例によれば、ＭＮ３０がＷＬＡＮ１０でＣＮ４０と通信中に、ＷＬＡＮ２０で使用すべき新たなＩＰアドレスを取得しておき、ＭＮ３０がＷＬＡＮ１０からＷＬＡＮ２０内に移動した時点で、ＣＮ４０に新たなＩＰアドレスを通知し、ＷＬＡＮ２０内で有効となる新たなＩＰアドレスを使用してＣＮ４０と通信する（ＳＱ３１２−１、ＳＱ３１２−２）ようにしているため、ＷＬＡＮ１０からＷＬＡＮ２０へのＭＮ３０のハンドオーバを短時間で完了することが可能となる。

この場合、ＭＮ３０は、ＳＩＰサーバ５０にも新たなＩＰアドレスを通知（位置登録）しておく必要がある。そこで、ステータス３２５が変更通知応答待ち状態となっていることを確認したＭＮ３０のプロセッサ３３は、ＳＩＰサーバ５０にＲＥＧＩＳＴＥＲパケットを送信し（１３２、図３２のＳＱ３１３）、図４（Ｅ）に示すように、接続管理テーブル３２０のＣＳｅｑ３２５に、ＲＥＧＩＳＴＥＲパケットに適用されたＣＳｅｑの値を設定し（１３３、図３２のＳ１２４）、２００ＯＫパケットの送信元であるＣＮ４０にＡＣＫパケットを返送して（１３８、図３２のＳＱ３１４）、このルーチンを終了する。

ここで送信されるＲＥＧＩＳＴＥＲパケットは、図３５に示すように、スタートラインにＭＮ３０のＳＩＰＵＲＩを含み、メッセージボディに、ＭＮ３０の旧ＩＰアドレスを記述した変更フラグ（Change-Flag）１００２を含み、ＩＰヘッダの送信元アドレスＳＡに新ＩＰアドレスを含んでいる。但し、ＩＰヘッダの送信元アドレスＳＡに旧ＩＰアドレスを適用して、変更フラグに新たなＩＰアドレスを記述するようにしても良い。

ＳＩＰサーバ５０のプロセッサ５３は、ＭＮ３０からＲＥＧＩＳＴＥＲパケットを受信すると、図１７に示したＲＥＧＩＳＴＥＲ受信処理ルーチン５３０を実行する。今回は、図８（Ａ）に示すように、ＲＥＧＩＳＴＥＲパケット送信元（ＭＮ３０）のＳＩＰＵＲＩ「SIP:MN＠xxx.com」が、端末位置情報管理テーブル５６に登録済となっている。

そこで、プロセッサ５３は、受信パケットが変更フラグ付きのＲＥＧＩＳＴＥＲパケットか否かを判定する（５３３）。もし、変更フラグ付きのＲＥＧＩＳＴＥＲパケットでなければ、プロセッサ５３は、ＭＮが新たな位置登録をしたのものと判断して、端末位置情報管理テーブル５６から、ＭＮ３０のＳＩＰＵＲＩと対応する旧エントリを削除（５３６）した後、受信パケットが示すＭＮ３０のＳＩＰＵＲＩとＩＰアドレスとの対応関係を端末位置情報管理テーブル５６に登録して（５３７）、このルーチンを終了する。この場合、ＭＮ３０のＩＰアドレスは、現ＩＰアドレス５１２として、端末位置情報管理テーブル５６に登録される。

ＳＩＰサーバ５０が今回受信したＲＥＧＩＳＴＥＲパケットは、変更フラグ付きのＲｅ−ＩＮＶＩＴＥパケットであるため、プロセッサ５３は、図８（Ｂ）に示すように、端末位置情報管理テーブル５６に現ＩＰアドレス５１２として登録されていたＭＮ３０のＩＰアドレスを旧ＩＰアドレス５１３に記憶し、Ｒｅ−ＲＥＧＩＳＴＥＲパケットから抽出したＭＮ３０の新ＩＰアドレスを現ＩＰアドレス５１２として登録する（５３４、図３２のＳ５２４）。この後、プロセッサ５３は、接続管理テーブル５２０において、図９（Ｄ）に示すように、ＭＮ３０のＩＰアドレス５２２を新ＩＰアドレスに変更し（５３５、図３２のＳ５２５）、Ｒｅ−ＲＥＧＩＳＴＥＲパケットの送信元であるＭＮ３０に、図３６に示す応答パケット（２００ＯＫ）を送信して（５３８、図３２のＳＱ３１５）、このルーチンを終了する。

ＭＮ３０のプロセッサ３３は、ＳＩＰサーバ５０から２００ＯＫパケットを受信すると、図１６に示す２００ＯＫ受信処理ルーチン１２０を実行する。今回受信した２００ＯＫパケットは、ＲＥＧＩＳＴＥＲ（Ｒｅ−ＲＥＧＩＳＴＥＲ）に対する応答パケットであるため、プロセッサ３３は、ステップ１２４で、接続管理テーブル３２０のステータス３２４をチェックする。接続管理テーブル３２０のステータス３２４は、図４（Ｅ）に示すように、変更通知応答待ち状態となっている。そこで、プロセッサ３３は、図４（Ｆ）に示すように、ステータス３２４を通話状態に戻して（１３６、図３２のＳ１２５）、２００ＯＫパケットの送信元であるＳＩＰサーバ５０にＡＣＫパケットを返送して（１３８、図３２のＳＱ３１６）、このルーチンを終了する。

ＭＮ３０がＷＬＡＮ１０からＷＬＡＮ２０にハンドオーバされた後も、プロセッサ３３は、図１４に示したビーコン受信処理ルーチン１５０を定期的に実行している。ＭＮ３０が、ポート番号「１」をもつ無線回線インタフェース３１−１でＷＬＡＮ１０内のＡＰ６０−２と接続された状態で、ＷＬＡＮ２０の内部に移動すると、ＡＰ６０−２から送信されたビーコン信号（ＳＱ３１７）の受信レベルＳ１が次第に低下する。

プロセッサ３３は、ビーコン受信処理ルーチン１５０の実行の都度、無線回線切替え判定１７０と無線回線解放判定１８０を実行し（図３２のＳ１０４）、無線回線解放判定１８０で、ＡＰ６０−２のビーコン受信レベルＳ１が閾値ＴＨよりも低下したことを検出すると（１８１）、図３（Ｇ）に示すように、端末状態管理テーブル３１０のテーブルエントリＥＮ１から、ＷＬＡＮ１０で割り当てられたＩＰアドレス「192.168.0.1」を削除し、接続ＡＰ３１４を空き状態にして（１８２、図３２のＳ１３０）、ＡＰ６０−２に接続解除（Association解除）パケットを送信する（１８３、図３２のＳＱ３１９）。以後、ＭＮ３０は、ＡＰ６０−２を接続ＡＰとして、空き状態となった無線回線インタフェース３１−１でＡＰ探索１６０を実行しながら、ＷＬＡＮ２０内を移動することになる。

次に、図３７〜図４３を参照して、切断フェーズ（ＰＨ４）について説明する。
図３７に示すように、ＭＮ３０のユーザが音声通信（ＳＱ３１２−１、ＳＱ３１２−２）を終了すると、ＭＮ３０からＳＩＰサーバ５０に、ＢＹＥパケットが送信される（ＳＱ４００）。ＢＹＥパケットは、図４０に示すように、スタートラインにＣＮ４０のＩＰアドレス「192.168.100.1」、ＦｒｏｍヘッダとＴｏヘッダにそれぞれＭＮ３０とＣＮ４０のＳＩＰＵＲＩ「SIP:[email protected]」と「SIP:[email protected]」を記述し、ＩＰヘッダの送信元アドレス（ＳＡ）として、ＭＮ３０のＩＰアドレス「172.21.22.25」を含んでいる。

ＭＮ３０のプロセッサ３３は、ＢＹＥパケットを送信すると、図４（Ｇ）に示すように、接続管理テーブル３２０のステータス３２４を「２００ＯＫ待ち」状態にし、ＣＳｅｑ３２５に、ＢＹＥパケットのＳＩＰメッセージに適用したＣＳｅｑの値「105 BYE」を記憶しておく（Ｓ１４１）。但し、接続管理テーブル３２０は、ＢＹＥパケットの送信に先立って更新してもよい。

ＳＩＰサーバ５０のプロセッサ５３は、ＢＹＥパケットを受信すると、図３８に示すＢＹＥ受信処理ルーチン５８０を実行する。ＢＹＥ受信処理ルーチン５８０において、プロセッサ５３は、受信したＢＹＥパケットから、送信元（ＭＮ３０）と宛先端末（ＣＮ４０）のＳＩＰＵＲＩおよびＩＰアドレスと、ＣＳｅｑを抽出し（５８１）、送信元ＳＩＰＵＲＩと宛先端末ＳＩＰＵＲＩを検索キーとして、接続管理テーブル５２０を検索する（５８２）。テーブル検索の結果（５８３）、接続管理テーブル５２０に、ＳＩＰＵＲＩ５２１、５２４が検索キーと一致するエントリが無かった場合、プロセッサ５３は、受信したＢＹＥパケットを廃棄して（５８６）、このルーチンを終了する。

接続管理テーブル５２０から目的のテーブルエントリを検索できた場合、プロセッサ５３は、図９（Ｅ）に示すように、検索されたテーブルエントリのステータス５２７を「２００ＯＫ待ち」状態に変更し、ＣＳｅｑ５２８にＢＹＥパケットから抽出されたＣＳｅｑの値「105 BYE」を記憶する（５８４、図３７のＳ５４１）。この後、プロセッサ５３は、ＢＹＥパケットを宛先端末（ＣＮ４０）に転送して（５８５、図３７のＳＱ４０１）、このルーチンを終了する。ＳＩＰサーバ５０からＣＮ４０に転送されるＢＹＥパケットは、図４１に示すように、ＳＩＰサーバ５０を示すＶｉａヘッダが追加され、ＩＰヘッダの宛先ＩＰアドレス（ＤＡ）と送信元ＩＰアドレス（ＳＡ）が書き換えてある。

ＣＮ４０のプロセッサ４３は、ＢＹＥパケットを受信すると、図３９に示すＢＹＥ受信処理ルーチン４４０を実行する。ＢＹＥ受信処理ルーチン４４０において、プロセッサ４３は、受信したＢＹＥパケットから、送信元ＳＩＰサーバのＩＰアドレスと、ＢＹＥ要求元（ＭＮ）のＳＩＰＵＲＩを抽出し（４４１）、ＢＹＥ要求元ＳＩＰＵＲＩを検索キーとして、接続管理テーブル４８０を検索する（４４２）。検索の結果（４４３）、接続管理テーブル４８０に、ＳＩＰＵＲ４８３が検索キーと一致するエントリが無かった場合、プロセッサ４３は、受信したＢＹＥパケットを廃棄して（４４６）、このルーチンを終了する。

接続管理テーブル４８０から目的のテーブルエントリを検索できた場合、プロセッサ４３は、図６（Ｄ）に示すように、検索されたテーブルエントリから送信元ＭＮの情報（ＳＩＰＵＲＩ４８３、ＩＰアドレス４９４）と、ステータス４８５、ＣＳｅｑを削除し（４４４、図３７のＳ４４１）、送信元ＳＩＰサーバ５０に応答パケット（２００ＯＫ）を送信して（４４５、図３７のＳＱ４０２）、このルーチンを終了する。ＣＮ４０が送信する２００ＯＫパケットは、図４２に示すように、受信したＢＹＥパケットと同じＣＳｅｑを含んでいる。

ＳＩＰサーバ５０のプロセッサ５３は、ＣＮ４０から２００ＯＫパケットを受信すると、図１９に示した２００ＯＫ受信処理ルーチン５６０を実行する。２００ＯＫ受信処理ルーチン５６０において、プロセッサ５３は、ステップ５６１〜ステップ５６４を実行した後、判定ステップ５６５で、受信パケットのＣＳｅｑから、今回の受信パケットをＢＹＥパケットに対する応答パケットと判断する。

この場合、プロセッサ５３は、接続管理テーブル５２０が示すＭＮのＩＰアドレスをＩＰ宛先アドレス（ＤＡ）として記憶した状態で、図９（Ｆ）に示すように、接続管理テーブル５２０から、検索されたエントリを削除し（５６７、図３７のＳ５４２）、ＢＹＥ要求元のＭＮ３０に対して２００ＯＫパケットを送信する（５６８、図３７のＳＱ４０３）。ＳＩＰサーバが送信する２００ＯＫパケットは、図４３に示すように、ＣＮ４０から受信した２００ＯＫパケットから、ＳＩＰサーバ５０のＶｉａヘッダを除去し、送信元ＩＰアドレスと宛先ＩＰアドレスを書き換えたものとなっている。

ＭＮ３０のプロセッサ３３は、ＳＩＰサーバ５０から２００ＯＫパケットを受信すると、図１６に示した２００ＯＫ受信処理ルーチン１２０を実行する。プロセッサ３３は、２００ＯＫ受信処理ルーチン１２０のステップ１２３、１２５で、受信パケットのＣＳｅｑから、今回の受信パケットをＢＹＥパケットに対する応答パケットと判断する。この場合、プロセッサ３３は、接続管理テーブル３２０から、図４（Ｇ）に示したＳＩＰＵＲＩ３２２〜ＣＳｅｑ３２５の登録情報を削除し（１３４、図３７のＳ１４２）、受信した２００ＯＫパケットを廃棄して（１３５）、このルーチンを終了する。これによって、切断フェーズＰＨ４が完了する。

次に、本発明の第２実施例について説明する。
第２実施例では、ＭＮ３０が、無線回線インタフェースを１個だけ備えている。従って、ＭＮ３０の端末状態管理テーブル３１０では、例えば、無線回線インタフェース３１−１と対応した１つのテーブルエントリで、ＩＰアドレス３１３と、接続ＡＰ３１４と、接続フラグ３１５を管理する。ＭＮ３０、ＣＮ４０、ＳＩＰサーバ５０は、第１実施例と同様、それぞれ接続管理テーブル３２０、４８０、５２０を備えている。

本実施例は、ＭＮ３０が、ＣＮ４０と通話中に、ＷＬＡＮ１０からＷＬＡＮ２０にハンドオーバする際の通信シーケンスに特徴がある。以下、図４４を参照して、第２実施例における移動中フェーズＰＨ３（１）の通信シーケンスについて説明する。
ＭＮ３０が、ＣＮ４０と音声通話中（ＳＱ２０６−１、ＳＱ２０６−２）に、図１に示したＷＬＡＮ１０内のＡＰ６０−２の無線エリア（ＷＬＡＮ１２）から、ＷＬＡＮ２０内の無線エリア（ＷＬＡＮ２１）に向かって移動したと仮定する。ＭＮ３０が、ＷＬＡＮ２１に近づくに従って、ＡＰ６０−２からのビーコン信号（ＳＱ３１７）の受信電波が弱くなる。

本実施例では、ＭＮ３０のプロセッサ３３は、図４５に示すビーコン受信処理ルーチン１５００を定期的に実行して、ビーコン信号の受信レベルを監視している。ビーコン受信処理ルーチン１５００において、プロセッサ３３は、無線回線インタフェース３１−１でビーコン信号を受信して（１５２）、受信したビーコン信号から、送信元ＡＰ情報（ＡＰ識別子）を抽出する（１６２）。ビーコン信号からＡＰ情報を抽出できなければ、プロセッサ３３は、このルーチンを終了する。

プロセッサ３３は、抽出されたＡＰ情報を端末状態管理テーブル３１０に登録された接続ＡＰと比較して、ビーコンの送信元ＡＰが、接続中のＡＰか否かを判定する（１６３）。ビーコン送信元ＡＰが、接続中のＡＰでなかった場合、プロセッサ３３は、端末状態管理テーブル３１０の接続フラグ３１５をチェックする（１６５）。プロセッサ３３は、接続フラグが「１」であれば、このルーチンを終了し、接続フラグが「０」の場合、ビーコン送信元ＡＰに対して、接続要求（Association Request）を送信して（１６６）、このルーチンを終了する。これらの動作は、図１４で説明したＡＰ探索１６０に相当している。

ビーコン送信元ＡＰが接続中のＡＰの場合、プロセッサ３３は、ビーコンの受信レベルＳ１を閾値ＴＨと比較し（１８１）、受信レベルＳ１が閾値ＴＨ１以上であれば、このルーチンを終了し、受信レベルＳ１が閾値ＴＨ１より低下していた場合は、端末状態管理テーブル３１０の登録データ３１３〜３１５を初期化する（１８２）。この後、プロセッサ３３は、接続管理テーブル３２０のステータス３２４をチェックし、ＭＮ３０が通話中でなければ、ビーコン送信元ＡＰに対して、接続解除（Association解除）を送信して（１８８）、このルーチンを終了する。

本実施例の１つの特徴は、ＭＮ３０がＣＮ４０と通話中に、接続ＡＰからのビーコン受信レベルが閾値ＴＨ１より低下した場合、プロセッサ３３が、ＣＮ４０とＳＩＰサーバ５０にハンドオーバを予告した後、移動先のＷＬＡＮで、ＡＰへの接続手順と、ＳＩＰサーバ５０へのＲｅ−ＩＮＶＩＴＥパケットの送信を行うようにしたことにある。

本実施例では、ＭＮ３０（プロセッサ３３）が、ハンドオーバ予告のために送信（ＳＱ３２１）するパケットを「Handover Start」パケットと呼ぶ。プロセッサ３３は、ＣＮ４０とＳＩＰサーバ５０にHandover Startパケットを送信（１８５、１８６、図４４のＳＱ３２１）した後、応答パケット（ＯＫ）が受信されるのを待ち（１８７）、ＣＮ４０またはＳＩＰサーバ５０の何れかによって送信された応答パケット（ＳＱ３２２）を受信すると、ビーコンの送信元ＡＰに対して、接続解除（Association解除）を送信して（１８８、図４４のＳＱ３２３）、このルーチンを終了する。但し、ハンドオーバによる呼の中断時間を短縮するために、プロセッサ３３は、応答パケット（ＯＫ）を受信する前に、接続解除（Association解除）を送信するようにしてもよい。

ＭＮ３０のプロセッサ３３は、移動中にも定期的にビーコン受信処理１５００を実行し、ハンドオーバ先となるＡＰを探索している（図４４のＳ１００）。プロセッサ３３は、ＷＬＡＮ２０のＡＰ６０−３から送信されたビーコン信号（ＳＱ３０２）を受信すると、ビーコン受信処理ルーチン１５００の判定ステップ１６２、１６３、１６５を経て、ステップ１６６で、ＡＰ６０−３に接続要求（Association Request）を送信する（図４４のＳＱ３０３）。

接続要求を受信したＡＰ６０−３は、ＭＮ３０に対して接続応答（Association Response）を返送する（ＳＱ３０４）。本実施例では、ＭＮ３０は、ＷＬＡＮ２０に属したＡＰ６０−３にハンドオーバされる前に、ＷＬＡＮ１０に属したＡＰ６０−２との接続が解除されているため、ＭＮ３０が実行するAssociation Response受信処理１９０では、接続応答の送信元となったＡＰが、常に現用系として端末状態管理テーブル３１０に登録される（Ｓ１０１）。

以下、図３１で説明した第１実施例と同様の手順（ＳＱ３０５、ＳＱ３０６、ＳＱ３０７）で、ＭＮ３０がＷＬＡＮ２０で取得した新たなＩＰアドレスが、端末状態管理テーブル３１０に登録される（Ｓ１０２）。移動先のＷＬＡＮ２０で新たなＩＰアドレスを取得したＭＮ３０は、ＣＮ４０に対してＲｅ−ＩＮＶＩＴＥを送信する。その後は、図３２で説明した第１実施例と同様のシーケンスが実行されるため、ここでの詳細説明は省略する。

本実施例では、ＭＮ３０は、Handover Startパケットを送信（ＳＱ３２１）することによって、ＣＮ４０に呼が一時的に途切れることを予告し、通話の途中でＣＮ４０が呼を切断するのを防止することができる。また、ＳＩＰサーバ５０に対して、ハンドオーバのために呼が一時的に途切れることを予告することによって、ＳＩＰサーバ５０が、ハンドオーバ中のＭＮ３０に、他のセッション接続要求を誤って接続するのを防止することを可能となる。

ＣＮ４０は、ＭＮ３０から送信されたHandover Startパケットを受信すると、図６に示した接続管理テーブル４８０のステータス４８５をハンドオーバ状態に書き換え（Ｓ４３１）、ＭＮ３０に応答パケット（ＯＫ）を送信する（ＳＱ３２２）。同様に、ＳＩＰサーバ５０も、ＭＮ３０から送信されたHandover Startパケットを受信すると、図９に示した接続管理テーブル５２０のステータス５２７をハンドオーバ状態に書き換え（Ｓ５３１）、ＭＮ３０に応答パケット（ＯＫ）を返送する（ＳＱ３２２）。

ここで、例えば、ＭＮ３０が、既にＡＰ６０−２との接続を解除し、移動先ＷＬＡＮ２０へのハンドオーバ動作に入っていた場合、ＣＮ４０またはＳＩＰサーバ５０から送信された応答パケット（ＯＫ）が、ＭＮ３０に届かない可能性がある。しかしながら、本実施例で重要なことは、Handover Startパケットの受信によって、ＣＮ４０とＳＩＰサーバ５０が、ＭＮ３０の呼が一時的に中断されることを事前に察知することにあり、ＣＮ４０とＳＩＰサーバ５０から送信された応答パケットがＭＮ３０に正常に受信されるか否かは問題ではない。

本実施例では、ＭＮ３０は、ＡＰ６０−２からのビーコン受信レベルが閾値ＴＨ１よりも低下したことを検知した時、Handover Startパケットを送信しているため、電波状況の劣化によって、ＭＮ３０から送信されたHandover Startパケットが、例えば、ＣＮ４０には届くが、ＳＩＰサーバ５０には届かない可能性も考えられる。そこで、本実施例では、ＳＩＰサーバ５０とＣＮ４０の現在のステータスを互いに一致させる目的で、Handover Startパケットを受信した時、ＳＩＰサーバ５０はＣＮ４０に、ＣＮ４０はＳＩＰサーバ５０に、自分の現在のステータスを示すステータス同期（Status SYNC）パケットを送信させている（ＳＱ３２３）。

ＣＮ４０のプロセッサ４３は、ステータス同期（Status SYNC）パケットを受信すると、図４６に示すＳｔａｔｕｓＳＹＮＣ受信処理ルーチン４５０を実行する。ＳＩＰサーバ５０のプロセッサ５３も、ＣＮ４０からステータス同期（ＳｔａｔｕｓＳＹＮＣ）パケットを受信すると、ＣＮ４０と同様のＳｔａｔｕｓＳＹＮＣ受信処理ルーチンを実行する。従って、ここでは、ＣＮ４０側の動作について説明する。

ＳｔａｔｕｓＳＹＮＣ受信処理ルーチン４５０において、プロセッサ４３は、接続管理テーブル４８０のステータス４８５が、ハンドオーバ状態になっているか否かを判定する（４５１）。もし、ステータス４８５がハンドオーバ状態となっていた場合は、ステータス同期（Status SYNC）パケットの送信元に対して、ＡＣＫパケットを返送して（４５３）、このルーチンを終了する。もし、ステータス４８５がハンドオーバ状態でなかった場合、プロセッサ４３は、ステータス４８５をＳｔａｔｕｓＳＹＮＣパケットが示すハンドオーバ状態に書き換え（４５２、図４３のＳ４３２）、ＡＣＫパケットを返送して（４５３、図４４のＳＱ３２５）、このルーチンを終了する。

ＳＩＰサーバ５０側のプロセッサ５３も、同様のＳｔａｔｕｓＳＹＮＣ受信処理動作を実行し、ＣＮ４０からステータス同期（Status SYNC）パケットを受信すると、接続管理テーブル５２０のステータス５２７をＣＮ４０側のステータスに一致させて（Ｓ５３２）、ＡＣＫパケットを返送する（ＳＱ３２５）。

上述したように、ＭＮ３０からHandover Startパケットを受信した時、ＣＮ４０とＳＩＰサーバ５０のうちの一方から他方に、ステータス同期（Status SYNC）パケットを送信させることによって、例えば、ＣＮ４０だけがHandover Startパケットを受信できた場合でも、ＳＩＰサーバ５０のステータスをハンドオーバ状態に設定することができ、これによって、ＳＩＰサーバ５０とＣＮ４０が、ＭＮ３０の呼をハンドオーバ中に切断するのを防止することができる。

次に、本発明の第３実施例として、ＴＣＰコネクションを介してサーバと通信中の移動ノードＭＮが、現在接続中のＩＰサブネットとは異なる別のＩＰサブネットに移動し、ＭＮで使用すべきＩＰアドレスが変更された場合でも、ＴＣＰコネクションを再設定することなく、上記サーバとの通信を継続できるようにした移動通信システム、および移動ノードのＩＰアドレスの切替え方法について説明する。

図４７は、第３実施例の無線ＩＰネットワークを示す。
ここに示した無線ＩＰネットワークは、基幹ルータ８３に接続された複数のルータ８１（８１−１〜８１−４）からなる固定網と、複数の無線ＩＰサブネット（無線ＬＡＮ：ＷＬＡＮ）とからなっている。ここでは、第１無線ＬＡＮ（ＷＬＡＮ）１０Ａ、第２無線ＬＡＮ（ＷＬＡＮ）１０Ｂ、第３無線ＬＡＮ（ＷＬＡＮ）１０Ｃ、第４無線ＬＡＮ（ＷＬＡＮ）１０Ｄが、それぞれ個別の無線ＩＰサブネットを形成している。

第１無線ＬＡＮ（ＷＬＡＮ）１０Ａは、Ｌ２ＳＷ８０−１に接続された無線基地局（アクセスポイント：ＡＰ）６０Ａ−１によって形成され、Ｌ２ＳＷ８０−１は、ルータ８１−１を介して基幹ルータ８３に接続されている。Ｌ２ＳＷ８０−１に接続されたＤＨＣＰサーバ７０−１は、ＡＰ６０Ａ−１が形成する無線ＬＡＮ１０Ａの通信圏内に位置した各移動ノード（ＭＮ）に対して、ＩＰアドレスを付与する。

第２無線ＬＡＮ（ＷＬＡＮ）１０Ｂは、Ｌ２ＳＷ８０−２に接続された無線基地局（ＡＰ）６０Ｂ−１によって形成され、Ｌ２ＳＷ８０−２は、ルータ８１−２を介して基幹ルータ８３に接続されている。Ｌ２ＳＷ８０−２に接続されたＤＨＣＰサーバ７０−２は、ＡＰ６０Ｂ−１が形成する無線ＬＡＮ１０Ｂの通信圏内に位置した各移動ノード（ＭＮ）に対して、ＩＰアドレスを付与する。

第３無線ＬＡＮ（ＷＬＡＮ）１０Ｃは、Ｌ２ＳＷ８０−３に接続された無線基地局（アクセスポイント：ＡＰ）６０Ｃ−１と６０Ｃ−２とからなり、Ｌ２ＳＷ８０−３は、ルータ８１−３を介して基幹ルータ８３に接続されている。ＷＬＡＮ１０Ｃでは、ＡＰ６０Ｃ−１が形成する無線ＬＡＮ１０Ｃ−１と、ＡＰ６０Ｃ−２が形成する無線ＬＡＮ１０Ｃ−２とで１つのＩＰサブネットが形成されている。Ｌ２ＳＷ８０−３に接続されたＤＨＣＰサーバ７０−３は、無線ＬＡＮ１０Ｃ−１、１０Ｃ−２の通信圏内に位置した各移動ノード（ＭＮ）に対して、ＩＰアドレスを付与する。

第４無線ＬＡＮ（ＷＬＡＮ）１０Ｄは、Ｌ２ＳＷ８０−４に接続された無線基地局（ＡＰ）６０Ｄ−１によって形成され、Ｌ２ＳＷ８０−４は、ルータ８１−４を介して基幹ルータ８３に接続されている。Ｌ２ＳＷ８０−４に接続されたＤＨＣＰサーバ７０−４は、ＡＰ６０Ｄ−１が形成する無線ＬＡＮ１０Ｄの通信圏内に位置した各移動ノード（ＭＮ）に対して、ＩＰアドレスを付与する。

基幹ルータ８３には、有線網８４を介して、各種のサーバ群、例えば、ＷＥＢサーバ７１−１、ＦＴＰサーバ７１−２、ＭＡＩＬサーバ７１−３が接続されている。移動ノード（ＭＮ）３０は、通信圏内にあるＡＰ６０（図４７ではＡＰ６０Ａ−１）を介してＬ２ＳＷ８０に接続され、ルータ８１と基幹ルータ８３を経由して、サーバ群７１をアクセスする。

図４８は、ＷＬＡＮ１０Ａの通信圏内で、例えば、ＷＥＢサーバ７１−１と通信中の移動ノードＭＮ３０が、ＷＬＡＮ１０Ｂの通信圏内に移動した場合の本実施例の通信手順を説明するために用意された図であり、図４７を簡略化した無線ＩＰネットワークを示している。

図４８において、ＷＥＢサーバ７１−１に付随して表示された「192.168.100.1」は、ＷＥＢサーバのＩＰアドレスを示し、ＭＮ３０に付随して表示された文字列「xx-xx-xx-xx-xx-xx-xx」と「xxx.xxx.x.x」は、ＭＮに付与されたＭＡＣアドレスとＩＰアドレスを示している。ここでは、ＭＮ３０が、ＷＬＡＮ１０ＡではＩＰアドレス「192.168.0.1」を使用し、ＷＬＡＮ１０ＢではＩＰアドレス「172.21.22.25」を使用することを示している。

図４９は、ＴＣＰヘッダ２２０のフォーマットを示す。
ＴＣＰヘッダ２２０は、送信元ポート番号２２０１と、宛先ポート番号２２０２と、シーケンス番号２２０３と、ＡＣＫ（Acknowledgement）番号２２０４と、データオフセット２２０５と、予備（Reserved）フィールド２２０６と、制御フラグ２２０７と、ウィンドウ２２０８と、チェックサム２２０９と、緊急ポインタ２２１０と、オプション２２１１と、パッディング２２１２とを含む。ＴＣＰヘッダ２２０は、ＴＣＰペイロード２３０の前に付加され、ＴＣＰヘッダの前には、図１０で示したＩＰヘッダ２１０が付加される。

図５０の（Ａ）−（Ｄ）は、本実施例において移動ノード（ＭＮ）３０が送受信するパケットのフォーマットを示す。
図５０（Ａ）は、ＭＮ３０とＷＥＢサーバ７１−１との間にＴＣＰコネクションが確立される前に、ＭＮ３０が送受信するパケットフォーマットを示す。ＴＣＰコネクションが確立されるまでは、ＭＮ３０は、ＩＰヘッダ２１０とＴＣＰヘッダ２２０とからなるパケットを送受信する。

図５０（Ｂ）は、ＴＣＰコネクションを確立した後で、ＭＮ３０がＷＥＢサーバ７１−１と送受信するデータパケットのフォーマットを示す。データパケットは、ＩＰヘッダ２１０と、ＴＣＰヘッダ２２０と、ＴＣＰペイロード（データ部）２３０とからなる。ＩＰヘッダ２１０は、送信元ＩＰアドレス２１１、宛先ＩＰアドレス２１２、その他のヘッダ情報からなる。その他のヘッダ情報としては、ＩＰヘッダ２１０に続くトランスポート層（ＴＣＰ／ＵＤＰ）ヘッダ２２０を識別するためのプロトコル識別子２１３Ａが含まれる。

図５０（Ｃ）は、ＭＮ３０が、ＷＬＡＮ１０Ａ内でＡＰ６０Ａ−１を介してＷＥＢサーバ７１−１に送信するデータパケットのフォーマット、図５０（Ｄ）は、ＭＮ３０が、ＡＰ６０Ａ−１からＡＰ６０Ｂ−１にハンドオーバされた後、ＷＥＢサーバ７１−１に送信するデータパケットのフォーマットを示している。

本実施例において、移動ノード（ＭＮ）３０は、図２で説明したように、一方が現用系、他方が予備系となる２つの無線回線インタフェース３１（３１−１、３１−２）を備え、プロセッサ３３は、現用系インタフェースを使用して、後述するＷＥＢサーバとのＴＣＰ接続手順を実行する。例えば、ＭＮ３０が現用系インタフェース３１−１を介してＡＰ６０Ａ−１に接続されている間に、プロセッサ３３は、予備系インタフェース３１−２で他のＡＰ、例えば、ＡＰ６０Ｂ−１からの送信ビーコンを探索する。プロセッサ３３は、ＡＰ６０Ｂ−１からのビーコン受信レベルがＡＰ６０Ａ−１からのビーコン受信レベルよりも大きくなった時、接続ＡＰの切替え（ハンドオーバ）と、無線回線インタフェースの現用系／予備系の切替えを行う。

図５１は、ＭＮ３０の通信相手となるサーバ７１の１実施例として、ＷＥＢサーバ７１−１のブロック構成図を示す。
ＷＥＢサーバ７１−１は、有線網８４に接続するための回線インタフェース７７と、回線インタフェース７７に接続されたプロトコル処理部７２と、内部バス７９を介してプロトコル処理部７２に接続されたプロッセサ７３と、内部バス７９に接続されたプログラムメモリ７４、データメモリ７５、およびＷＥＢサービス用の情報を格納したデータベース（ＤＢ）７６とからなる。プロトコル処理部７２は、送信データを蓄積するためのバッファメモリ７２Ｂを備えている。

プログラムメモリ７４には、プロセッサ７３が実行する本発明に関係するソフトウェアとして、主制御ルーチン７１０と、ＳＹＮ受信処理ルーチン７４０と、ＴＣＰコネクション維持処理ルーチン７５０と、ＩＰアドレス変更処理ルーチン７６０と、各種のアプリケーションプログラム７８０が格納されている。また、データメモリ７５には、プロセッサ７３が参照する接続管理テーブル７５と、その他のデータ格納用のメモリ領域が用意されている。

プロトコル処理部７２は、回線インタフェース７７から受信したパケットを解析し、受信パケットをプロッサ７３に転送すると共に、プロセッサ７３がバッファメモリ７２Ｂに書き込んだ送信データを通信相手装置（ＭＮ３０）宛のデータパケットとして、回線インタフェース７７に転送する。プロセッサ７３は、プロトコル処理部７２からの受信したパケットを主制御ルーチン７１０によって処理する。主制御ルーチン７１０は、受信パケットの種類に応じて、ＳＹＮ受信処理ルーチン７４０、ＴＣＰコネクション維持処理ルーチン７５０、ＩＰアドレス変更処理ルーチン７６０、アプリケーションプログラム７８０を選択的に起動する。

図５２の（Ａ）―（Ｆ）は、本実施例の移動ノードＭＮ３０が備える端末状態管理テーブル３１０の構成と状態変化の１例を示す。
端末状態管理テーブル３１０は、図３で説明した第１実施例と同様、無線回線インタフェース（ＩＮＦ）のポート番号３１１と対応した複数のテーブルエントリ（ＥＮ１、ＥＮ２）からなる。各テーブルエントリは、移動ノードＭＮ３０自身のＭＡＣアドレスを示すＭＡＣアドレス・フィールド３１２と、ＩＰサブネットで取得したＭＮ３０のＩＰアドレスを示すＩＰアドレス・フィールド３１３と、接続ＡＰフィールド３１４と、接続フラグ・フィールド３１５とからなる。

接続ＡＰフィールド３１４は、ポート番号３１１（＝ｉ）をもつ無線回線インタフェース３１−ｉのアクセスポイントＡＰへの接続状態を示している。ＭＮ３０が無線回線インタフェース３１−ｉを介して既に特定のＡＰに接続済みの状態では、接続ＡＰフィールド３１４には、接続中のＡＰの識別子が設定され、ＡＰに未接続の状態では、空き状態を示す状態コードが設定される。接続フラグ・フィールド３１５は、無線回線インタフェース３１−ｉの使用状態を示しており、フラグ「１」は、現用系インタフェースとして使用中の状態、フラグ「０」は、未使用中または予備系インタフェースとして使用中の状態を示す。端末状態管理テーブル３１０の利用方法については、後で詳述する。

図５３の（Ａ）−（Ｂ）は、本実施例の移動ノードＭＮ３０が備える接続管理テーブル３２０の構成と状態変化の１例を示す。
接続管理テーブル３２０は、ＭＮ情報３２６と接続先サーバ情報３２７との対応関係を示す。ＭＮ情報３２６は、ＭＮ３０のＩＰアドレス３２６Ａと使用ポート番号３２６Ｂを示し、接続先サーバ情報３２７は、接続先サーバ（この例ではＷＥＢサーバ７１−１）のＩＰアドレス３２７Ａと使用ポート番号３２７Ｂを示す。接続管理テーブル３２０の具体的な利用方法については、後で詳述する。

図５４の（Ａ）−（Ｃ）は、本実施例で移動ノードＭＮ３０の通信相手装置となるサーバ（ＷＥＢサーバ７１−１）が備える接続管理テーブル７２０の構成と状態変化の１例を示す。
接続管理テーブル７２０には、移動ノードＭＮ３０の現用ＩＰアドレス７２１と対応付けて、ＭＮ３０の変更前ＩＰアドレス７２２と、使用ポート番号７２３と、ＷＥＢサーバ７１−１のＩＰアドレス７２４、使用ポート番号７２５、バッファ制御フラグ７２６、ステータス７２７が記憶される。ステータス７２７には、ＭＮ宛にデータを送信したとき、ＭＮからの確認応答待ちを示す情報が記憶される。

本実施例では、ハンドオーバ等によってＭＮ３０のＩＰアドレスが変更された場合に、接続管理テーブル７２０に、現用ＩＰアドレス７２１の他に、変更前ＩＰアドレス７２２も記憶するようになっている。接続管理テーブル７２０の具体的な利用方法については、後で詳述する。

次に、図５５〜図５８を参照して、ＭＮ３０が、ＡＰ６０Ａ−１を介して、ＷＥＢサーバ７０−１との間にＴＣＰコネクションを設定する接続フェーズの通信シーケンスについて説明する。
図５５は、接続フェーズの通信シーケンス、図５６は、本実施例でＭＮ３０のプロセッサ３３が実行するビーコン受信処理ルーチン１５０のフローチャート、図５７は、ＷＥＢサーバ７１−１のプロセッサ７３が実行する接続要求パケット（ＳＹＮ）受信処理ルーチン７４０のフローチャート、図５８は、ＭＮ３０とＷＥＢサーバ７１−１との間のＴＣＰ通信経路の概略説明図を示す。図５５において、図１２と同一符号を付したステップは、図１２と同一のステップを示しているため、説明を簡略化する。

ＭＮ３０は、無線ＬＡＮを利用してＷＥＢサーバ７１−１との間にＴＣＰコネクションを設定する前に、現在位置で通信可能なＡＰを検索する必要がある。そこで、ＭＮ３０（プロセッサ３３）は、図５６に示すビーコン受信処理ルーチン１５０を定期的に実行して、ＭＮ３０と通信可能なＡＰを探索する（Ｓ１００）。

本実施例で実行されるビーコン受信処理１５０において、ＡＰ探索１６０（ステップ１６１〜１６４）と無線回線の解放判定１８０（ステップ１８１〜１８３）は、図１４で説明した第１実施例と同様で、無線回線の切り替え判定１７０は、回線切替え条件（Ｓ１＞Ｓ２）が成立した場合の処理ステップ１７４Ｂ〜１７９Ｂが、第１実施例とは異なっている。

ＭＮ３０は、端末状態管理テーブル３１０に接続中ＡＰが未登録の状態で、例えば、ポート番号＝「１」の無線回線インタフェース３１−１でＡＰ６０Ａ−１からのビーコン信号（ＳＱ１００）を受信すると、図５５に示すＡＰ探索Ｓ１００（図５６のＡＰ探索１６０）を実行する。これによって、ＭＮ３０は、ＡＰ６０Ａ−１に接続要求（Association Request）を送信し（ＳＱ１０１）、ＡＰ６０Ａ−１からの応答を待つ。ＡＰ６０Ａ−１が、ＭＮ３０に接続応答（Association Response）を返送すると（ＳＱ１０２）、ＭＮ３０は、図１５で説明したAssociation Response受信処理１９０を実行する。

Association Response受信処理１９０を実行することによって、ＭＮ３０の端末状態管理テーブル３１０には、図５２の（Ａ）に示すように、無線回線ＩＮＦポート番号＝「１」と対応するエントリＥＮ１の接続ＡＰフィールド３１４にビーコン送信元のＡＰ識別子「ＡＰ−Ａ１」が登録され、接続フラグ３１９が「１」に設定される（Ｓ１０１）。これによって、ＭＮ３０とＡＰ６０Ａ−１との間に接続（Association）が確立され（ＳＱ１０３）、ＭＮ３０は、ＡＰ６０Ａ−１を現用系ＡＰとして扱う。

ＭＮ３０は、ＡＰ６０Ａ−１への接続が完了すると、ＷＬＡＮ１０Ａで使用すべきＩＰアドレスが既に取得済みか否かを判定し、もし、取得していなければ、ＤＨＣＰサーバ７０−１に対して、ＩＰアドレスの取得要求（DHCP Request）パケットを送信する（ＳＱ１０４）。DHCP Requestを受信したＤＨＣＰサーバ７０−１は、ＭＮ３０にＩＰアドレス（「192.168.0.1」）を割り当て、割当てＩＰアドレスを示す応答（DHCP Acknowledge）パケットを返送する（ＳＱ１０５）。

ＭＮ３０は、ＤＨＣＰサーバ７０−１から応答（DHCP Acknowledge）パケットを受信すると、受信パケットから抽出したＩＰアドレスを、図５２（Ｂ）に示すように、端末状態管理テーブル３１０のテーブルエントリＥＮ１にＩＰアドレス３１３として登録（Ｓ１０２）する。この後、ＭＮ３０は、ＷＥＢサーバ７０−１との間にＴＣＰコネクションを設定するために、ＳＹＮフラグをオンにした接続要求ＴＣＰセグメントをＷＥＢサーバ７０−１に送信する（ＳＱ１１０）。このＴＣＰセグメントは、ＭＮ３０からＷＥＢサーバ７０−１に向かう上り通信路でのデータ送信の許可要求となる。

ＷＥＢサーバ７０−１のプロセッサ７３は、ＭＮ３０からＳＹＮフラグをオン状態のＴＣＰセグメントを受信すると、図５７に示すＳＹＮ受信処理ルーチン７４０を実行する。

ＳＹＮ受信処理ルーチン７４０において、プロセッサ７３は、受信したＴＣＰセグメントから、送信元ＩＰアドレスと、送信元および宛先のポート番号を抽出し（７４１）、接続管理テーブル７２０から、ＭＮ現用ＩＰアドレス７２１、ＭＮ使用ポート番号７２３、サーバ使用ポート番号７２５がこれらの抽出データと一致するテーブルエントリを検索する（７４２）。プロセッサ７３は、接続管理テーブルの検索結果を判定し（７４３）、もし、抽出データに該当する目的エントリが検索された場合、受信パケット（ＴＣＰセグメント）を廃棄して（７４６）、このルーチンを終了する。

接続管理テーブル７２９に目的エントリが未登録の場合、プロセッサ７３は、図５８に示すように、アプリケーション７８０−１とＴＣＰ／ＩＰレイヤのソフトウェア７２Ａとの間に、通信路となるソケットＳＫ２０を形成し（７４４）、宛先ポート番号と送信元ＩＰアドレスとを関連付ける（図５５のＳ７０１）。

尚、図５８において、１０１Ｕは、ＭＮ３０からＷＥＢサーバ７１に向かう上り通信路、１０１Ｄは、ＷＥＢサーバ７１からＭＮ３０に向かう下り通信路を示し、ＳＫ３０は、ＭＮ側のアプリケーション３００ＷとＴＣＰ／ＩＰのソフトウェア３２Ａとの間に形成されるソケットを示す。また、７２Ｄは、ＷＥＢサーバ側のＴＣＰ／ＩＰレイヤのソフトウェア７２Ａと回線インタフェース７７との間に位置したデバイスドライバ、３２Ｄは、ＭＮ側のＴＣＰ／ＩＰレイヤのソフトウェア７２Ａと回線インタフェース７７との間に位置したデバイスドライバを示す。

この後、プロセッサ７３は、接続管理テーブル７２０に、図５４の（Ａ）に示すように、ＴＣＰセグメントから抽出した送信元ＩＰアドレスの値「192.168.0.1」と、送信元ポート番号の値「2001」および宛先ポート番号の値「80」をそれぞれＭＮ現用ＩＰアドレス７２１、ＭＮ使用ポート番号７２３、サーバ使用ポート番号７２５として登録し（７４５、図５５のＳ７０２）、ＡＣＫフラグとＳＹＮフラグをオンにした接続応答ＴＣＰセグメントをＭＮ３０へ返信する（ＳＱ１１１）。上記接続応答ＴＣＰセグメントは、ＡＣＫフラグで、ＭＮ３０からＷＥＢサーバ７０−１への通信を許可したことを示すと共に、ＳＹＮフラグで、ＷＥＢサーバ７０−１からＭＮ３０に向かう下り通信路（図５８の１０１Ｄ）でのデータ送信の許可要求している。

ＭＮ３０は、ＷＥＢサーバ７０−１から上記接続応答ＴＣＰセグメントを受信すると、接続管理テーブル３２０に、図５３の（Ａ）が示すように、受信セグメントから抽出した送信元（ＷＥＢサーバ）ポート番号の値「80」を使用ポート番号３２７Ｂとして登録し（Ｓ１１３）、ＷＥＢサーバ７０−１に対して、ＡＣＫフラグをオンにした通信許可ＴＣＰセグメントを送信する（ＳＱ１１２）。

以上の手順によって、ＭＮ３０とＷＥＢサーバ７１−１との間に、上り／下りの双方向方のデータ通信を可能とするＴＣＰコネクション（図５８に示した通信路１０１Ｕ、１０１２Ｄ）が確立され、ＭＮ３０の接続フェーズが完了する。この状態で、ＭＮ３０がＷＥＢサーバ７１−１にデータ要求を送信すると（ＳＱ１１３）、ＷＥＢサーバ７１−１からＭＮ３０に応答パケット（ＯＫ）が返送され（ＳＱ１１４）、ＷＥＢサーバ７１−１とＭＮ３０との間で、データ送信（ＳＱ１２０−１、ＳＱ１２０−２、・・・）と確認応答（ＳＱ１２１−１、ＳＱ１２１−２、・・・）を繰り返す形で、ＴＣＰ通信が実行される。ＴＣＰ通信では、データは、図５０の（Ｂ）に示したパケットフォーマットで送信される。

次に、図５６と、図５９〜図６２を参照して、ＷＥＢサーバ７１−１とデータ通信中のＭＮ３０が、ＷＬＡＮ１０ＡからＷＬＡＮ１０Ｂに移動中に実行される移動中フェーズの通信シーケンスについて説明する。

図５９は、移動中フェーズの通信シーケンスを示す。
ＭＮ３０のプロセッサ３３は、ＷＥＢサーバ７０−１とデータ通信中（ＳＱ１２０−１、ＳＱ１２１−３）も、図５６に示したビーコン受信処理ルーチン１５０を周期的に実行し、ＡＰ探索（Ｓ１００）をしている。ＭＮ３０が、ＷＬＡＮ１０ＡからＷＬＡＮ１０Ｂに向かって移動すると、現在接続中のＡＰ６０Ａ−１から送信されたビーコン信号（ＳＱ３０１）以外に、ＷＬＡＮ１０ＢのＡＰ６０Ｂ−１が送信した新たなビーコン信号（ＳＱ３０２）も受信可能となる。

ＭＮ３０がＷＬＡＮ１０Ｂに接近し、空き状態にある無線回線インタフェース３１−２で、ＡＰ６０Ｂ−１から送信された新たなビーコン信号を受信すると、プロセッサ３３は、ビーコン受信処理ルーチン１５０に従って、受信したビーコン信号の送信元のＡＰ識別子が、端末状態管理テーブル３１０に接続ＡＰ３１４として登録されたＡＰ識別子と一致するか否かを判定する（１６３）。

プロセッサ３３は、受信したビーコン信号の送信元のＡＰ識別子（この例では「ＡＰ−Ｂ１」）が、端末状態管理テーブル３１０に接続ＡＰ３１４として登録されたＡＰ識別子（この例では「ＡＰ−Ａ１」）とは異なることを検知すると、ビーコン送信元ＡＰ６０Ｂ−１に接続要求（Association Request）を送信する（１６４、図５９のＳＱ３０３）。ＡＰ６０Ｂ−１は、上記接続要求（Association Request）が示すＭＮ３０との接続を了承すると、ＭＮ３０に対して接続応答（Association Response）を送信する（ＳＱ３０４）。ＭＮ３０のプロセッサ３３は、ＡＰ６０Ｂ−１から接続応答（Association Response）を受信すると、図１５で説明したAssociation Response受信処理１９０を実行する。

Association Response受信処理１９０において、プロセッサ３３は、端末状態管理テーブル３１０の接続ＡＰフィールド３１４を参照して、既に接続中のＡＰが存在するか否かを判定する（１９１）。今回は、テーブルエントリＥＮ１の接続ＡＰフィールド３１４にＡＰ６０Ａ−１のＡＰ識別子「ＡＰ−Ａ１」が登録されている。そこで、プロセッサ３３は、図５２の（Ｃ）に示すように、端末状態管理テーブル３１における空き無線回線インタフェースのポート番号「２」と対応するテーブルエントリＥＮ２に、接続ＡＰ３１４として、上記ビーコンの送信元ＡＰの識別子「ＡＰ−Ｂ１」を登録し、接続フラグ３１５に予備系を示す値「０」を設定して（１９３、図５９のＳ１０１）、このルーチンを終了する。以上のシーケンスによって、ＭＮ３０とＡＰ６０Ｂ−１との間に接続（Association）が確立される（ＳＱ３０５）。

ＭＮ３０は、端末状態管理テーブル３１０に接続ＡＰ３１４として登録された２つのＡＰ識別子から、移動元ＩＰサブネットと移動先ＩＰサブネットが同一か否かを判定する。この例では、ＡＰ識別子「ＡＰ−Ａ１」と「ＡＰ−Ｂ１」でＩＰサブネットの識別記号（Ａ、Ｂ）が異なっているため、ＭＮ３０は、移動先のＡＰ（ＡＰ６０Ｂ−１）が移動元のＡＰ（ＡＰ６０Ａ−１）とは異なったＩＰサブネットに所属していると判断し、移動先ＷＬＡＮ１０Ｂで使用すべき新たなＩＰアドレスを取得するために、ＡＰ６０Ｂ−１を介してＤＨＣＰサーバ７０−２に、ＩＰアドレスの取得要求（DHCP Request）パケットを送信する（ＳＱ３０６）。

上記ＩＰアドレスの取得要求パケットを受信したＤＨＣＰサーバ７０−２は、ＭＮ３０に対してＩＰアドレス「172.21.22.25」を割り当て、このＩＰアドレスを示す応答（DHCP Acknowledge）パケットをＭＮ３０に送信する（ＳＱ３０７）。ＭＮ３０は、上記応答パケットを受信すると、受信パケットから新たなＩＰアドレス「172.21.22.25」を抽出し、図５２（Ｄ）に示すように、端末状態管理テーブル３１０の接続ＡＰ「ＡＰ−Ｂ１」と対応するテーブルエントリＥＮ２にＩＰアドレス３１３として登録する（Ｓ１０２）。

尚、ＭＮ３０の移動先ＡＰ（ＡＰ６０Ｂ−１）が、移動元ＡＰ（ＡＰ６０Ａ−１）と同一のＩＰサブネットに所属していた場合、移動先での新たなＩＰアドレスを取得する必要はない。この場合、ＭＮ３０のプロセッサ３３は、端末状態管理テーブル３１０において、テーブルエントリＥＮ１に登録されているＩＰアドレス３１３をテーブルエントリＥＮ２にコピーすればよい。

ＭＮ３０のプロセッサ３３は、ＡＰ６０Ａ−１、ＡＰ６０Ｂ−１と接続された状態でも、図５６に示したビーコン受信処理ルーチン１５０を定期的に実行し、ＡＰ６０Ａ−１のビーコン信号（ＳＱ３０８）とＡＰ６０Ｂ−１のビーコン信号（ＳＱ３０９）を監視している。ＭＮ３０が、ＡＰ６０Ａ−１、ＡＰ６０Ｂ−１と接続状態にある間は、空きインタフェースが無くなっているため、プロセッサ３３は、図５６に示したビーコン受信処理ルーチン１５０において、無線回線の切替え判定１７０と無線回線の解放判定１８０を繰り返す。

無線回線の切替え判定１７０（図５９のＳ１３１）では、プロセッサ３３は、現用系インタフェースで接続中のＡＰ６０Ａ−１からのビーコンの受信レベルＳ１と、予備系インタフェースで接続中のＡＰ６０Ｂ−１からのビーコンの受信レベルＳ２を検出し（１７１、１７２）、Ｓ１とＳ２を比較する（１７３）。プロセッサ３３は、現用系ＡＰの受信レベルＳ１が予備系ＡＰの受信レベルＳ２以上であれば、無線回線の切替え判定１７０を終了して、無線回線の解放判定１８０を実行する。

本実施例では、予備系ＡＰの受信レベルＳ２が、現用系ＡＰの受信レベルＳ１よりも大きくなった時、プロセッサ３３は、端末状態管理テーブル３１０からＩＰアドレス３１３を検索し（１７４Ｂ）、テーブルエントリＥＮ１、ＥＮ２が示すＩＰアドレスを比較することによって、ＩＰアドレスの切替えの要否を判定する（１７５Ｂ）。プロセッサ３３は、テーブルエントリＥＮ１、ＥＮ２が示すＩＰアドレスが一致している場合は、ＩＰアドレスは切替え不要と判断して、無線回線の解放判定１８０を実行する。

テーブルエントリＥＮ１、ＥＮ２が示すＩＰアドレスが不一致のとき、ＩＰアドレスが切替わる。この場合、プロセッサ３３は、ＷＥＢサーバ７０−１に対してＴＣＰコネクション維持通知メッセージを送信し（１７６Ｂ、図５９のＳＱ３４０）、予備系となっていた無線回線インタフェースを現用系に切り替え（１７７Ｂ）、図５２（Ｅ）に示すように、端末状態管理テーブル３１０の接続フラグ３１５の状態を書き替え、図５３（Ｂ）に示すように、接続管理テーブル３２０のＭＮ用ＩＰアドレス３２６Ａを移動先ＷＬＡＮで使用すべきＩＰアドレスに書き替える（１７８Ｂ、図５９のＳ１３２とＳ１３３）。

この後、プロセッサ３３は、ＷＥＢサーバ７０−１にＩＰアドレス変更通知メッセージを送信し（１７９Ｂ、図５９のＳＱ３４２）、無線回線の解放判定１８０を実行する。ＩＰアドレス変更通知メッセージは、ＭＮ３０のＩＰアドレスが、「192.168.0.1」から「172.21.22.25」に変わったことを示している。

無線回線の解放判定１８０では、プロセッサ３３は、端末状態管理テーブル３１０に接続ＡＰ３１４として登録されているＡＰからのビーコンの受信レベルを閾値ＴＨと比較し（１８１）、ビーコン受信レベルが閾値ＴＨ以上であれば、今回のビーコン受信処理ルーチン１５０を終了する。ビーコン受信レベルが閾値ＴＨよりも小さくなった時、プロセッサ３３は、端末状態管理テーブル３１０から、ビーコン送信元ＡＰに関する登録情報をリセットして（１８２）、ビーコン送信元ＡＰに対して接続（Association）解除パケットを送信して（１８３、図５９のＳＱ３４４）、今回のビーコン受信処理ルーチン１５０を終了する。

例えば、ＡＰ６０Ａ−１からのビーコンの受信レベルが閾値ＴＨよりも低下した場合、図５２（Ｆ）に示すように、端末状態管理テーブル３１０のテーブルエントリＥＮ１からＡＰ６０Ａ−１の識別子「ＡＰ−Ａ１」と、不要となったＩＰアドレス「192.168.0.1」が削除され、ＡＰ６０Ａ−１に対して接続（Association）解除パケットが送信される（図５９のＳＱ３４４）。尚、ここでは、テーブルエントリＥＮ１の接続フラグ３１５が、ＩＰアドレスの切替え時に「１」から「０」に書き替えられたが、もし、ＡＰ６０Ａ−１が現用系となっている状態で、ビーコンの受信レベルが閾値ＴＨ以下に低下した場合、接続フラグ３１５は、ステップ１８２で「０」に書き替えられる。

本実施例では、上述したように、ＷＥＢサーバ７０−１とデータ通信中のＭＮ３０にＩＰアドレスの切替えが発生した場合、ＭＮ３０からＷＥＢサーバ７０−１に、ＭＮ３０のサブネット間ハンドオーバを予告するＴＣＰコネクション維持通知を送信し（ＳＱ３４０）、次に、ＭＮ３０のＩＰアドレスの変更をＷＥＢサーバ７０−１に通知する（ＳＱ３４２）ようにしている。

ＷＥＢサーバ７０−１のプロセッサ７３は、ＭＮ３０からＴＣＰコネクション維持通知を受信すると、図６０に示すＴＣＰコネクション維持処理ルーチン７５０を実行する（図５９のＳ７０３）。
ＴＣＰコネクション維持処理ルーチン７５０において、プロセッサ７３は、プロトコル処理部７２にデータ送信制御信号（送信停止信号）を与えて、ＴＣＰコネクション維持通知の送信元ＩＰアドレス（ＭＮ３０のＩＰアドレス「192.168.0.1」）に対するデータ送信の停止を指令し（７５１）、ＴＣＰコネクション維持通知の送信元（ＭＮ３０）にＡＣＫパケットを返送し（７５２、図５９のＳＱ３４１）、図５４（Ｂ）に示すように、接続管理テーブル７２０における上記送信元ＩＰアドレス「192.168.0.1」と対応するテーブルエントリのバッファ制御フラグ７２６を「１」に書き換える（７５３）。

この後、プロセッサ７３は、ＴＣＰコネクション維持通知の受信時点で、プロトコル処理部７２にＭＮ３０に送信中のデータがあるか否かを確認する（７５４）。送信中データには、プロトコル処理部７２が現在送信動作中のデータのみならず、既に送信済みのデータであってＭＮ３０からの確認応答待ちのデータも含む。

プロトコル処理部７２に送信中データがなければ、プロセッサ７３は、このルーチンを終了し、プロトコル処理部７２に送信中のデータがあった場合、図５４（Ｂ）に示すように、接続管理テーブルのステータス７２７に「確認応答待ち」を記憶してから（７５５）、このルーチンを終了する。プロトコル処理部７２は、プロセッサ７３から送信停止信号を受けた時、もし、ＭＮ３０宛てにデータを送信中の場合は、送信単位となる一群のデータブロック（例えば、Ｄ１５１〜Ｄ２００）を送信して、ＭＮ３０宛てのその後のデータ送信を停止する。

図６１は、プロトコル処理部７２におけるデータ送信制御の説明図である。
プロトコル処理部７２は、制御部７２Ａとバッファメモリ７２Ｂとを備え、バッファメモリ７２Ｂには、データの宛先ＩＰアドレスと対応付けられた複数の送信バッファエリアが形成されている。

プロセッサ７３は、ＭＮ３０からデータ要求（図５のＳＱ１１３）を受信すると、要求された一連のデータをデータベース（ＤＢ）７６から読出し、ＭＮ３０宛ての送信データ（Ｄ１０１〜Ｄ３００）として、ＭＮ３０のＩＰアドレスと対応付けて形成された送信バッファエリア７２Ｂに書き込む。また、ＭＮ３０からＴＣＰコネクション維持通知（図５９のＳＱ３４０）を受信した時、プロセッサ７３は、プロトコル処理部７２の制御部７２Ａに、ＭＮ３０宛てに送信中のデータの有無を問い合わせると共に、制御部７２Ａに前述したデータ送信制御信号（送信停止信号）を与える。以下、データ送信停止用の制御信号をＣ１、データ送信停止解除要の制御信号をＣ２で表す。

図６１は、送信バッファエリアに書き込まれたデータブロックＤ１０１〜Ｄ１５０、Ｄ１５１〜Ｄ２００、Ｄ２０１〜Ｄ２５０、Ｄ２５１〜Ｄ３００のうち、破線で示したデータブロックＤ１０１〜Ｄ１５０は、既にＭＮ３０から確認応答を受信済みで、送信が完了した状態となっている。データブロックＤ１５１〜Ｄ２００は、ＭＮ３０に送信中（図５９のＳＱ１２０−４）、データブロックＤ２０１〜Ｄ３００は、送信待ちの状態を示している。

ここでは、制御部７２Ａが、データブロックＤ１５１〜Ｄ２００を送信中か、ＭＮ３０からデータブロックＤ１５１〜Ｄ２００に対する確認応答を受信する前に、プロセッサ７３から制御部７２Ａに、ＭＮ３０宛てデータの送信停止を指令する制御信号Ｃ１が発行された場合を想定している。

制御部７２Ａは、送信バッファエリアに格納されている各送信データについて状態を管理している。データブロックＤ１０１〜Ｄ１５０は、送信完了の状態になっているため、バッファ領域を解放して新たなデータの書き込みが可能となっている。データブロックＤ１５１〜Ｄ２００は、ＭＮ３０に送信された時点で確認応答待ち状態となり、ＭＮ３０から確認応答を受信したとき、送信完了状態（バッファ解放状態）に遷移する。

送信待ち状態にある次のデータブロックＤ２０１〜Ｄ２５０は、前のデータブロックＤ１５１〜Ｄ２００が送信完了状態となった時点でＭＮ３０に送信され、その状態が送信待ちから確認応答待ちに遷移する。尚、制御部７２は、例えば、データブロックＤ１５１〜Ｄ２００をＤ１５１、Ｄ１５２、・・・Ｄ２００の順にサブブロック単位で読み出し、無線区間ではサブブロック単位の複数パケットに分割して送信する。

制御部７２Ａは、プロセッサ７３からデータ送信停止の制御信号Ｃ１を受信すると、送信中データ（確認応答待ちのデータ）と送信待ち状態のデータをバッファメモリに保持した状態で、プロセッサ７３からのデータ送信停止解除の制御信号Ｃ２を待つ。プロセッサ７３は、ＭＮ３０からＩＰアドレスの変更通知（ＳＱ３４２）を受信したとき、制御部７２Ａに、ＭＮ３０の旧ＩＰアドレス「192.168.0.1」と新ＩＰアドレス「172.21.22.25」とを指定した形で、データ送信停止解除を示す制御信号Ｓ２を与える。

制御部７２Ａは、プロセッサ７３からデータ送信停止解除用の制御信号Ｓ２を受信すると、ＭＮ３０用送信バッファエリアと対応付けるＩＰアドレスを新ＩＰアドレスに変更した後、ＭＮ３０宛てのデータ送信を再開する。これによって送信再開後のＭＮ３０宛てのデータには、新ＩＰアドレスが適用される。

本実施例では、図５９に示すように、ＭＮ３０が、サーバ７１−１からデータ（Ｄ１５１〜Ｄ２００）を受信する前に、ＷＥＢサーバ７１−１にＴＣＰコネクション維持通知を送信した場合、ＭＮ３０は、データ（Ｄ１５１〜Ｄ２００）に対する確認応答を返送しない。従って、サーバ７１−１の送信バッファ７２Ｂには、送信待ち状態のデータ（Ｄ２０１〜Ｄ３００）以外に、データ（Ｄ１５１〜Ｄ２００）が確認応答待ちの状態で保存されている。

これらのデータは、制御部７２Ａが、データ送信停止解除用の制御信号Ｃ２を受信した後で、ＭＮ３０の新ＩＰアドレスを適用して送信される。従って、本実施例によれば、ＭＮ３０のＩＰアドレスが変った時、ＷＥＢサーバ７１−１は、ＴＣＰに従ったデータ再送手順を実行することなく、ＭＮ３０宛てのデータ送信を再開することが可能となる。

ＷＥＢサーバ７０−１のプロセッサ７３は、ＭＮ３０からＩＰアドレスの変更通知（ＳＱ３４２）を受信すると、図６２に示すＩＰアドレス更新処理ルーチン７６０を実行する。
ＩＰアドレス更新処理ルーチン７６０において、プロセッサ７３は、受信メッセージから新ＩＰアドレスと旧ＩＰアドレスを抽出し（７６１）、接続管理テーブル７２０から、現用ＩＰアドレス７２１が旧ＩＰアドレスと一致するテーブルエントリを検索する（７６２）。プロセッサ７３は、検索結果を判定し（７６３）、旧ＩＰアドレスに該当するテーブルエントリが検索されなかった場合は、受信メッセージを廃棄して（７７４）、このルーチンを終了する。

旧ＩＰアドレスに該当するテーブルエントリが検索された場合、プロセッサ７３は、図５４（Ｃ）に示すように、接続管理テーブル７２０に現用ＩＰアドレス７２１として登録されていた旧ＩＰアドレスを変更前ＩＰアドレス７２２に移し、新ＩＰアドレスを現用ＩＰアドレス７２１に記憶し（７６４）、ソケットに登録されている旧ＩＰアドレスを新ＩＰアドレスに変更する（７６５）。次に、プロセッサ７３は、接続管理テーブル７２０のステータス７２７が確認応答待ちとなっているか否かを判定する（７６６）。

ステータス７２７が確認応答待ちでなければ、プロセッサ７３は、接続管理テーブル７２０のバッファ制御フラグ７２６に「０」を設定し（７６７）、プロトコル処理部の制御部７２Ａに、送信待ち状態にあるＭＮ３０宛てデータの送信停止を解除する制御信号Ｃ２を出力し（７７１）、ＩＰアドレスの変更通知に対する応答（ＯＫ）パケットをＭＮに返送して（７７３）、のルーチンを終了する。ステップ７７３で返送されるＯＫパケット（図５９のＳＱ３４３）は、ＷＥＢサーバ７１−１側でＭＮ３０用ＩＰアドレスの変更が完了したことを示す通知信号となる。ＭＮ３０は、上記応答（ＯＫ）パケットの受信後に、従前のＩＰサブネットであるＷＬＡＮ１０ＡのＡＰ６０Ａ−１との接続を解除できる。

ステータス７２７が確認応答待ちとなっていた場合、プロセッサ７３は、プロトコル処理部の制御部７２Ａが、ＭＮ３０宛てに最後に送信したデータ（図５９の例では、データＤ１５１〜Ｄ２００）について確認応答を受信したか否かをチェックする（７６８）。もし、確認応答が受信されていなければ、プロセッサ７３は、図５４（Ｃ）に示すように、接続管理テーブル７２０のステータス７２７をクリアし、バッファ制御フラグ７２６に「０」を設定して（７７０）、プロトコル処理部の制御部７２Ａに、確認応答待ちデータ以降のＭＮ３０宛てデータの送信停止を解除する制御信号Ｓ２を出力し（７７２）、ＩＰアドレスの変更通知に対する応答（ＯＫ）パケットをＭＮに返送して（７７３）、このルーチンを終了する。

ＭＮ３０宛ての最後の送信データに対する確認応答が、プロトコル処理部の制御部７２Ａで受信済みとなっていた場合、プロセッサ７３は、接続管理テーブル７２０のステータス７２７をクリアし、バッファ制御フラグ７２６に「０」を設定して（７６９）、プロトコル処理部の制御部７２Ａに、送信待ち状態にあるＭＮ３０宛てデータの送信停止を解除する制御信号Ｃ２を出力し（７７１）、ＩＰアドレスの変更通知に対する応答（ＯＫ）パケットをＭＮに返送して（７７３）、このルーチンを終了する。

本実施例では、移動ノードＭＮ３０が、ＷＥＢサーバ７１−１からのデータ受信を現用系の無線回線インタフェースで行うことを前提としている。従って、ＷＥＢサーバ７１−１にＴＣＰコネクション維持通知を送信した後、ＭＮ３０がＡＰ６０Ａ−１からＡＰ６０Ｂ−１にハンドオーバされると、ＭＮ３０では、無線回線インタフェースの切替えによって予備系ＩＰアドレスとなった旧ＩＰアドレス宛てのデータ（図５９ではデータブロックＤ１５１〜Ｄ２００）を受信できない。

そこで、図５９に示した実施例では、ＴＣＰコネクション維持通知の送信後のＭＮ３０に、アドレス変更前の宛先ＩＰアドレスをもつ受信データに対して、確認応答を返信させないようにしておき、ＷＥＢサーバ７０−１が、ＭＮ３０からＩＰアドレスの変更通知を受信した時、確認応答待ち状態にある送信データ（データブロックＤ１５１〜Ｄ２００）（ＳＱ１３１）から送信する形で、ＩＰアドレス変更後のデータ送信を再開させている。

但し、後述する第４実施例のように、ＭＮ３０が、ＷＥＢサーバからの送信データを現用系、予備系の何れの無線回線インタフェースでも受信できるようにしておき、ＴＣＰコネクション維持通知の送信後に、アドレス変更前の宛先ＩＰアドレスをもつ受信データに対しても確認応答を返送するようにしてもよい。このようにすれば、サブネット間ハンドオーバに伴ってＭＮ３０のＩＰアドレスが切り替えられた場合でも、従前のサブネットを経由したデータ通信を一時的に持続することが可能となる。

上述した第３実施例によれば、ＭＮ３０が、ＷＬＡＮ１０ＡでＷＥＢサーバ７０−１と通信中に、移動先となるＷＬＡＮ１０Ｂで新たなＩＰアドレスを取得しておき、ＷＬＡＮ１０ＡからＷＬＡＮ１０Ｂにハンドオーバした時点で、ＷＥＢサーバ７０−１に新ＩＰアドレスを通知することによって、図５９にＳＱ１２０−５、ＳＱ１２１−５で示すように、ＷＬＡＮ１０Ｂ（ＡＰ６０Ｂ−１）を経由して新ＩＰアドレスでＷＥＢサーバと通信するようにしているため、ＷＬＡＮ間でのＭＮ３０のハンドオーバを短時間で完了できる。

また、本実施例のように、ＭＮ３０のＩＰアドレスを変更する前に、ＭＮ３０からＷＥＢサーバ７１−１にＴＣＰコネクション維持通知メッセージを送信した場合、ＷＥＢサーバ７１−１は、ＴＣＰに従ったデータ再送処理の実行を回避することができる。この場合、ＴＣＰコネクション維持通知メッセージを受信した時、サーバ（ＷＥＢサーバ７１−１）が、ＭＮ３０との間のＴＣＰコネクションを維持した状態で、確認応答待ち状態、または送信待ち状態にあるデータを送信バッファに保持することによって、ＭＮ３０のＩＰアドレスが変更されたとき、新たな通信路を形成することなく、新ＩＰアドレスでＭＮ３０宛との間のデータ通信を再開することが可能となる。

尚、上述した実施例では、ＭＮ３０からＴＣＰコネクション維持通知メッセージを受信した時、ＭＮ３０宛てに送信中のデータ（確認応答待ちデータ）があった場合は、ＷＥＢサーバ７１−１のプロセッサ７３が、接続管理テーブル７２０のステータス７２７に確認応答待ちを記憶しておき、ＭＮ３０からＩＰアドレス変更通知を受信した時、上記送信中データについての確認応答が受信済みか否かをチェックして、ＭＮ３０宛てのデータ送信を確認応答待ち状態のデータから再開するか、送信待ち状態のデータから再開するかを判断するようにしている。

しかしながら、中断されたＭＮ３０宛てデータ送信を再開する際に、最初に送信すべきデータの選択はプロトコル処理部の制御部７２Ａに任せてもよい。すなわち、プロセッサ７３からデータ送信停止解除の制御信号Ｃ２を受信した時、制御部７２Ａが、送信バッファに確認応答待ちのデータがあるか否かを判定し、もし確認応答待ちのデータがあれば、確認応答待ちデータから送信を再開し、確認応答待ちのデータがなければ、送信待ち状態にある最初のデータから送信を再開するようにしてもよい。

この場合、プロセッサ７３は、接続管理テーブル７２０にバッファ制御フラグ７２６とステータス７２７を記憶する必要がなくなるため、図６０に示したＴＣＰコネクション維持処理ルーチン７５０から、ステップ７５４、７５５を省略できる。また、図６２に示したＩＰアドレス更新処理ルーチン７６０から、ステップ７６６〜７７０を省略し、ステップ７７１と７７２を統合できる。結果的に、ＩＰアドレス更新処理ルーチン７６０は、ステップ７６５でソケットのＩＰアドレスを更新した後、プロトコル処理部の制御部７２Ａに対して、確認応答待ちデータの有無に関係なく、データ送信停止の解除信号を出力するように簡単化できる。

図６３は、第３実施例における切断フェーズの通信シーケンスを示す。
ＭＮ３０とＷＥＢサーバ７１−１との間でのデータ通信（ＳＱ１２０−１、ＳＱ１２１−１〜ＳＱ１２０−７、ＳＱ１２１−７）が完了し、ＭＮ３０のユーザが通信終了の入力操作を行うと、ＭＮ３０からＷＥＢサーバ７０−１に切断要求パケット（ＦＩＮパケット）が送信される（ＳＱ４１０）。

ＷＥＢサーバ７１−１は、上記ＦＩＮパケットを受信すると、接続管理テーブル７２０から現用ＩＰアドレス７２１がＦＩＮパケットの送信元ＩＰアドレスと対応するテーブルエントリを削除し、ソケットをクローズ（Ｓ７０５）した後、ＦＩＮパケットの送信元であるＭＮ３０に対して、ＷＥＢサーバ７１−１側からの切断要求パケット（ＦＩＮパケット）と、ＭＮ３０から受信したＦＩＮパケットに対する応答パケット（ＡＣＫパケット）とを送信する（ＳＱ４１１、ＳＱ４１２）。

移動ノードＭＮ３０は、ＷＥＢサーバ７１−１からＡＣＫパケットを受信すると、接続管理テーブル３２０から、ＷＥＢサーバ７１−１と対応するテーブルエントリを削除する（Ｓ１３４）。また、ＷＥＢサーバ７１−１からの切断要求パケットに応答して、切断の了承を示すＡＣＫパケットを返送して（ＳＱ４１３）、ＷＥＢサーバ７１−１との通信を終了する。以上の手順によって、ＭＮ３０とＷＥＢサーバ７１−１との間のＴＣＰのコネクションが切断され、切断フェーズが終了する。

次に、図６４〜図６６を参照して、本発明の第４実施例について説明する。
図６４は、第４実施例における移動中フェーズの通信シーケンス、図６５は、第４実施例の移動ノードＭＮ３０が備える接続管理テーブル３２０、図６６は、第４実施例のＭＮ３０が実行するデータ受信処理ルーチン１４０のフローチャートを示す。本実施例の接続管理テーブル３２０は、図５３に示した第３実施例の接続管理テーブル３２０に、ステータス・フィールド３２８を追加した構成となっている。

移動ノードＭＮ３０は、ＷＬＡＮ１０Ａ内でＡＰ６０Ａ−１を介して、ＷＥＢサーバ７１−１とデータ通信中（例えば、ＳＱ１２０−３、ＳＱ１２１−３）に、図５６で説明したビーコン受信処理１５０を定期的に実行している。ＭＮ３０がＷＬＡＮ１０Ｂに接近し、ＡＰ６０Ａ−１からのビーコン信号（ＳＱ３０８）以外に、ＡＰ６０Ａ−２からのビーコン（ＳＱ３０９）を受信できる状況において、ＭＮ３０は、無線回線の切替え判定（Ｓ１３１、図５６の１７０）を実行し、無線回線の切替え条件（Ｓ１＜Ｓ２）が成立した時点で、ＷＥＢサーバ７０−１にＴＣＰコネクション維持通知メッセージを送信する（ＳＱ３４０）。

ＷＥＢサーバ７０−１は、ＴＣＰコネクション維持通知メッセージを受信すると、図６０に示したＴＣＰコネクション維持処理ルーチン７５０を実行し（Ｓ７０３）、ＭＮ３０に応答（ＡＣＫ）パケットを返送する（ＳＱ３４１）。ＴＣＰコネクション維持通知メッセージを受信したＷＥＢサーバ７０−１では、既に説明したように、プロトコル処理部７２が、送信中のデータについては送信動作を続行し、これらのデータが確認応答待ちの状態になった時点で、その後のデータ送信を停止する。この場合、ＭＮ３０には、ＴＣＰコネクション維持通知メッセージの送信後に、変更前のＩＰアドレスを宛先アドレスとしたデータが到着する。

従って、ＭＮ３０が、ＴＣＰコネクション維持通知メッセージを送信した後、直ちにＩＰアドレスの切替えを実行した場合、すなわち、予備系（または現用系）の無線回線インタフェースを現用系（または予備系）の無線回線インタフェースに切り替えた場合は、ＷＥＢサーバ７１−１から最後に送信されたデータが、予備系の切り替えられた無線回線インタフェースで受信される可能性がある。

第３実施例では、ＭＮ３０が、現用系の無線回線インタフェースで受信したデータについてのみ、確認応答を返送するようになっていたため、予備系の切り替えられた無線回線インタフェースが受信したデータについては、確認応答の返送はなかった。
第４実施例では、現用系の無線回線インタフェースのみならず、予備系の無線回線インタフェースで受信された旧ＩＰアドレス宛のデータについても、ＭＮ３０が確認応答を返送するようにしたことを特徴とする。この場合、予備系の無線回線インタフェースで受信された旧ＩＰアドレス宛のデータに対する確認応答は、予備系の無線回線インタフェースで返送してもよいが、予備系の無線回線インタフェースは、通信環境が現用系の無線回線インタフェースよりも劣化しているため、予備系の無線回線インタフェースで受信された旧ＩＰアドレス宛のデータに対する確認応答を現用系無線回線インタフェースから返送するとよい。

図６４では、ＭＮ３０がＴＣＰコネクション維持通知メッセージを送信（ＳＱ３４０）する前に、ＷＥＢ７１−１が、ＷＬＡＮ１０Ａで有効なＩＰアドレス（「192.168.0.1」）を宛先アドレスとして、データＤ１５１〜Ｄ２００（ＳＱ１２０−４）、Ｄ２０１〜Ｄ２５０（ＳＱ１２０−５）を送信し、データＤ１５１〜Ｄ２００は、ＭＮ３０が無線回線インタフェースを切り替える前に受信され、データＤ２０１〜Ｄ２５０は、ＭＮ３０が無線回線インタフェースを切り替えた後に受信された場合を想定している。

本実施例では、ＭＮ３０は、現用系または予備系の無線回線インタフェースからデータを受信すると、アプリケーションプログラムによる受信データの処理と並行して、図６６に示したデータ受信処理ルーチン１４０を実行する。データ受信処理ルーチン１４０では、プロセッサ３３は、データを受信した無線回線インタフェースが現用系か予備系かを判定する（１４１）。

データＤ１５１〜Ｄ２００（ＳＱ１２０−４）の受信時には、無線回線インタフェースは切り替わっていないため、この時点で実行されるデータ受信処理ルーチン１４０（Ｓ１５０）では、上記データを受信した無線回線インタフェースが現用系と判断される。この場合、プロセッサ３３は、ＴＣＰコネクション維持通知メッセージが送信済みか否かを判定する（１４２）。もし、ＴＣＰコネクション維持通知メッセージが送信済みでなければ、ＷＥＢサーバ７０−１に確認応答を返信して（１４６）、このルーチンを終了する。

図６４に示した例では、ＴＣＰコネクション維持通知メッセージが送信済みとなっているため、プロセッサ３３は、図６５に示すように、接続管理テーブル３２０のステータス３２８に確認応答未送信を記憶（１４３）した後、ＩＰアドレス変更通知が既に送信済みか否かを判定し（１４４）、ＩＰアドレス変更通知が送信されていなければ、図５６に示したビーコン受信処理ルーチン１５０によるＩＰアドレス変更通知の送信（無線回線の切替え）が完了するのを待つ。プロセッサ３３は、ＩＰアドレス変更通知の送信が完了すると、接続管理テーブル３２０のステータス３２８をクリアし（１４５）、ＷＥＢサーバ７０−１に確認応答を返信して（１４６）、このルーチンを終了する。

すなわち、本実施例では、図６４に示すように、ＭＮ３０は、現用系の無線回線インタフェースと予備系の無線回線インタフェースとを切り替え（無線回線ＩＮＦ切替え：Ｓ１７７）、接続管理テーブルにおけるＭＮのＩＰアドレスを更新し（Ｓ１７８）、ＷＥＢサーバ７１−１にＩＰアドレスの変更通知を送信（ＳＱ３４２）した後、データＤ１５１〜Ｄ２００（ＳＱ１２０−４）に対する確認応答を返送する（ＳＱ１２１−４）。

データＤ２０１〜Ｄ２５０（ＳＱ１２０−５）が、無線回線インタフェースの切替え後に受信されると、データ受信処理ルーチン１４０（Ｓ１５０）のステップ１４１で、上記データを受信した無線回線インタフェースは予備系と判断される。この場合、プロセッサ３３は、接続管理テーブル３２０のステータス３２８に確認応答未送信を記憶（１４３）した後、ＩＰアドレス変更通知が既に送信済みか否かを判定する（１４４）。
今回は、ＩＰアドレス変更通知が既に送信済みとなっているため、プロセッサ３３は、ステータス３２８をクリア（１４５）した後、データＤ２０１〜Ｄ２５０（ＳＱ１２０−５）に対する確認応答を返送して（１４６、図６４のＳＱ１２１−５）、このルーチン１４０を終了する。

第４実施例では、上述したように、ＡＰと接続中の無線回線インタフェースは、それが現用系か予備系かに関係なく、受信データを有効データとして受信処理しておき、ＩＰアドレス変更の通知後に、受信データに対する確認応答を返送するようにしている。この場合、予備系の無線回線インタフェースで受信されたデータに対しては、新たなＩＰアドレスを適用した確認応答を現用系インタフェースから返信できる。

ＷＥＢサーバ７１−１は、図５４に示したように、ＭＮ３０の現用（新）ＩＰアドレスと変更前（旧）ＩＰアドレスを接続管理テーブル７２０で管理しているため、旧ＩＰアドレスを宛先とした送信データに対して、ＭＮ３０から新ＩＰアドレスを送信元とする確認応答が返送された場合でも、確認応答と送信データとの対応関係を正しく認識できる。

また、第４実施例では、ＭＮ３０のＩＰアドレスの変更前にＷＥＢサーバ７０−１が送信したデータに対して、応答遅れがあるとしても、確認応答を受信できるため、図６２に示したＩＰアドレス更新処理ルーチン７６０において、ステップ７７０と７７２が実行されることはなく、送信バッファメモリで送信待ち状態にあるデータからデータ送信が再開（７７１）されることになる。

第４実施例によれば、ＭＮ３０が、現用系の無線回線インタフェースと予備系の無線回線インタフェースの両方でデータを受信できるようにしているため、ＩＰサブネット間のハンドオーバによってＭＮ３０のＩＰアドレスが変った場合でも、ＷＥＢサーバから送信済みで確認応答待ちのデータを再送する必要がなくなる。従って、ハンドオーバが頻繁に繰り返された場合でも、通信リソースを無駄にしない効率のよいデータ通信が可能となる。

本発明が適用されるネットワーク構成の１例を示す図。移動端末（移動ノードＭＮ）３０の１実施例を示すブロック構成を示す図。ＭＮ３０が備える端末状態管理テーブル３１０の構成を示す図。ＭＮ３０が備える接続管理テーブル３１０の構成を示す図。ＭＮ３０の通信相手となる端末装置ＣＮ４０の１実施例を示すブロック構成を示す図。ＣＮ４０が備える接続管理テーブル４８０の構成を示す図。ＳＩＰサーバ５０の１実施例を示すブロック構成を示す図。ＳＩＰサーバ５０が備える端末位置情報管理テーブル５１０の構成を示す図。ＳＩＰサーバ５０が備える接続管理テーブル５２０の構成を示す図。ＳＩＰメッセージを含むパケットのフォーマットを示す図。ＭＮ３０がＩＰヘッダに適用する送信元アドレスの変化を説明するための図。図１のネットワークで実行されるＭＮ３０の位置登録フェーズにおける通信シーケンスを示す図。図１のネットワークで実行されるＭＮ３０の接続フェーズにおける通信シーケンスを示す図。ＭＮ３０が実行するビーコン受信処理ルーチン１５０の１実施例を示すフローチャート。ＭＮ３０が実行する接続応答（Association Response）受信処理ルーチン１９０の１実施例を示すフローチャート。ＭＮ３０が実行する応答（２００ＯＫ）受信処理ルーチン１２０の１実施例を示すフローチャート。ＳＩＰサーバ５０が実行するＲＥＧＩＳＴＥＲ受信処理ルーチン５３０の１実施例を示すフローチャート。ＳＩＰサーバ５０が実行するＩＮＶＩＴＥ受信処理ルーチン５４０の１実施例を示すフローチャート。ＳＩＰサーバ５０が実行する２００ＯＫ受信処理ルーチン５６０の１実施例を示すフローチャート。ＳＩＰサーバ５０が実行するＡＣＫ受信処理ルーチン５７０の１実施例を示すフローチャート。ＣＮ４０が実行するＩＮＶＩＴＥ受信処理ルーチン４２０の１実施例を示すフローチャート。ＣＮ４０が実行するＡＣＫ受信処理ルーチン４３０の１実施例を示すフローチャート。位置登録フェーズでＭＮ３０からＳＩＰサーバ５０に送信されるＲＥＧＩＳＴＥＲパケットのフォーマット図。位置登録フェーズでＳＩＰサーバからＭＮ３０に送信される応答（２００ＯＫ）パケットのフォーマット図。接続フェーズでＭＮ３０からＳＩＰサーバ５０に送信されるＩＮＶＩＴＥパケットのフォーマット図。接続フェーズでＳＩＰサーバ５０からＣＮ４０に転送されるＩＮＶＩＴＥパケットのフォーマット図。接続フェーズでＣＮ４０からＳＩＰサーバ５０に返送される応答（２００ＯＫ）パケットのフォーマット図。接続フェーズでＳＩＰサーバ５０からＭＮ３０に転送される応答（２００ＯＫ）パケットのフォーマット図。接続フェーズでＭＮ３０からＳＩＰサーバ５０に送信されるＡＣＫパケットのフォーマット図。接続フェーズでＳＩＰサーバ５０からＣＮ４０に転送されるＡＣＫパケットのフォーマット図。図１のネットワークで実行されるＭＮ３０の移動中フェーズにおける通信シーケンスの一部を示すシーケンス図。ＭＮ３０の移動中フェーズにおける通信シーケンスの残り部分を示すシーケンス図。移動中フェーズでＭＮ３０からＣＮ４０に送信されるＲｅ−ＩＮＶＩＴＥパケットのフォーマット図。移動中フェーズでＣＮ４０からＭＮ３０に返送される応答（２００ＯＫ）パケットのフォーマット図。移動中フェーズでＭＮ３０からＳＩＰサーバ５０に送信されるＲＥＧＩＳＴＥＲパケットのフォーマット図。移動中フェーズでＳＩＰサーバ５０からＭＮ３０に返送される応答（２００ＯＫ）パケットのフォーマット図。図１のネットワークにおけるＭＮ３０の切断フェーズの通信シーケンスを示すシーケンス図。ＳＩＰサーバ５０が実行するＢＹＥ受信処理ルーチン５８０の１実施例を示すフローチャート。ＣＮ４０が実行するＢＹＥ受信処理ルーチン４４０の１実施例を示すフローチャート。ＭＮ３０からＳＩＰサーバ５０に送信されるＢＹＥパケットのフォーマット図。ＳＩＰサーバ５０からＣＮ４０に転送されるＢＹＥパケットのフォーマット図。ＣＮ４０からＳＩＰサーバ５０に返送される応答（２００ＯＫ）パケットのフォーマット図。ＳＩＰサーバ５０からＭＮ３０に転送される応答（２００ＯＫ）パケットのフォーマット図。図１のネットワークで実行されるＭＮ３０の移動中フェーズにおける通信シーケンスの第２の実施例を示すシーケンス図。第２の実施例でＭＮ３０が実行するビーコン受信処理ルーチンの１実施例を示すフローチャート。第２の実施例でＣＮ４０とＳＩＰサーバ５０が実行するＳｔａｔｕｓＳＹＮＣ受信処理ルーチン４５０の１実施例を示すフローチャート。本発明の第３実施例の無線ＩＰネットワークを示す図。図４７の無線ＩＰネットワークにおいて、移動ノードＭＮ３０が、ＷＬＡＮ１０ＡからＷＬＡＮ１０Ｂに移動した場合の通信手順を説明するための図。ＴＣＰヘッダ２２０のフォーマットを示す図。第３実施例において移動ノード（ＭＮ）３０が送受信するパケットのフォーマットを示す図。ＭＮ３０の通信相手装置となるＷＥＢサーバ７１−１のブロック構成図。第３実施例の移動ノードＭＮ３０が備える端末状態管理テーブル３１０の構成と状態変化の１例を示す図。第３実施例の移動ノードＭＮ３０が備える接続管理テーブル３２０の構成と状態変化の１例を示す図。ＷＥＢサーバ７１−１が備える接続管理テーブル７２０の構成と状態変化の１例を示す図。ＭＮ３０とＷＥＢサーバ７０−１との間にＴＣＰコネクションを設定する接続フェーズの通信シーケンス図。第３実施例のＭＮ３０が実行するビーコン受信処理ルーチン１５０のフローチャート。ＷＥＢサーバ７１−１が実行する接続要求パケット（ＳＹＮ）受信処理ルーチン７４０のフローチャート。ＭＮ３０とＷＥＢサーバ７１−１との間のＴＣＰ通信経路の概略説明図。第３実施例のＭＮ３０が、ＷＬＡＮ１０ＡからＷＬＡＮ１０Ｂに移動中に実行される移動中フェーズの通信シーケンス図。ＷＥＢサーバ７０−１が実行するＴＣＰコネクション維持処理ルーチン７５０のフローチャート。ＷＥＢサーバ７０−１が備えるプロトコル処理部７２とプロセッサ７３によって行われるデータ送信制御の説明図。ＷＥＢサーバ７０−１が実行するＩＰアドレス更新処理ルーチン７６０のフローチャート。第３実施例における切断フェーズの通信シーケンス図。本発明の第４実施例における移動中フェーズの通信シーケンス図。第４実施例の移動ノードＭＮ３０が備える接続管理テーブル３２０の１例を示す図。第４実施例のＭＮ３０が実行するデータ受信処理ルーチン１４０のフローチャート。

符号の説明

１：中継網、２：ＩＰ網、１０、２０：ＷＬＡＮ，３０：移動端末（移動ノード）ＭＮ、４０：通信相手端末ＣＮ、５０：ＳＩＰサーバ、６０：無線基地局（アクセスポイント：ＡＰ）、７０：ＤＨＣＰサーバ、８０：Ｌ２ＳＷ、８１：ルータ、８３：基幹ルータ、７１：サーバ。

Claims

固定網に接続された複数のＩＰサブネットを含み、移動ノード装置（ＭＮ）が現在接続中のＩＰサブネットから移動先のＩＰサブネットにハンドオーバされる移動通信システムにおける移動ノード装置（ＭＮ）のＩＰアドレスの切替え方法であって、
上記ＭＮが、通信相手装置と通信中に、定期的に実行されるビーコン信号受信処理によって、新たなＩＰサブネットに所属したアクセスポイントを検知し、該ＩＰサブネットで使用すべき新たなＩＰアドレスを取得するステップと、
上記ＭＮが、現在接続中のＩＰサブネットから上記新たなＩＰサブネットへのハンドオーバ条件が成立した時点で、上記通信相手装置に該ＭＮのＩＰアドレスの変更を示す制御パケットを送信するステップと、
上記ＭＮが、上記制御パケットを送信した後で、該ＭＮのＩＰアドレスを既に取得済みの新たなＩＰアドレスに変更することによって、送受信パケットの通信経路を上記新たなＩＰサブネットに切替えるステップとからなることを特徴とするＩＰアドレスの切替え方法。
固定網に接続された複数のＩＰサブネットからなり、１つのＩＰサブネットを経由して通信相手装置と通信中の移動ノード装置（ＭＮ）が、新たなＩＰサブネットに移動したとき、現在接続中のＩＰサブネットから移動先のＩＰサブネットにハンドオーバされる移動通信システムにおける移動ノード装置（ＭＮ）のＩＰアドレスの切替え方法であって、
上記通信相手装置と通信中のＭＮが、定期的に実行されるビーコン信号受信処理によって、新たなＩＰサブネットに所属したアクセスポイントを検知し、該ＩＰサブネットで使用すべき新たなＩＰアドレスを取得するステップと、
現在接続中のＩＰサブネットから上記新たなＩＰサブネットへのハンドオーバ条件が成立した時点で、上記通信相手装置と通信中のＭＮが、上記通信相手装置に該ＭＮのＩＰアドレスの変更を示す制御パケットを送信し、該ＭＮのＩＰアドレスを既に取得済みの新たなＩＰアドレスに切替えることによって、上記新たなＩＰサブネットにハンドオーバするステップと、
上記ＭＮから、上記固定網に接続されたセッション管理サーバに、上記新たなＩＰアドレスを通知するステップとからなることを特徴とするＩＰアドレスの切替え方法。
前記ＭＮが、前記ビーコン信号受信処理によって、前記新たなＩＰサブネットに所属するアクセスポイントから送信されたビーコン信号を検知したとき、該ビーコン信号の送信元となったアクセスポイントに接続した後、該ＩＰサブネットで上記新たなＩＰアドレスの取得手順を実行することを特徴とする請求項２に記載の移動ノード装置のＩＰアドレスの切替え方法。
前記ＭＮが、前記通信相手装置との通信に先立って、現在接続中のＩＰサブネットを経由して前記セッション管理サーバにセッション接続要求パケットを送信し、上記セッション管理サーバが、上記ＭＮから受信した上記セッション接続要求パケットを上記通信相手装置に転送することによって、上記ＭＮと上記通信相手装置との間にセッションを確立し、
上記ＭＮが、上記通信相手装置との通信中に発生する新たなＩＰサブネットへのハンドオーバの都度、上記セッション管理サーバを経由することなく、上記通信相手装置に該ＭＮのＩＰアドレスの変更を示す制御パケットを送信することを特徴とする請求項３に記載の移動ノード装置のＩＰアドレスの切替え方法。
前記ＭＮのＩＰアドレスの変更を示す制御パケットが、前記セッション接続要求パケットで前記セッション管理サーバに送信される制御メッセージと同一種別の制御メッセージを含み、該制御メッセージが、ＩＰアドレスの変更を示すフラグ情報を含むことを特徴とする請求項４に記載の移動ノード装置のＩＰアドレスの切替え方法。
前記セッション管理サーバが、ＳＩＰ（Session Initiation Protocol）サーバであり、前記ＭＮのＩＰアドレスの変更を示す制御パケットが、ＳＩＰのＩＮＶＩＴＥメッセージを含み、前記フラグ情報が切り替え前のＩＰアドレスを含むことを特徴とする請求項５に記載の移動ノード装置のＩＰアドレスの切替え方法。
それぞれが少なくとも１つのアクセスポイントを含み、固定網に接続されている複数のＩＰサブネットからなる移動通信システムで使用される移動ノード装置（ＭＮ）であって、
移動中に定期的に実行されるビーコン信号受信処理によって、通信圏内に位置した新たな無線アクセスポイントを検出したとき、該無線アクセスポイントとの間で所定の接続手順を実行し、新たなＩＰサブネットに所属する無線アクセスポイントに接続されたとき、該ＩＰサブネットで使用すべき新たなＩＰアドレスの取得手順を実行するための第１手段と、
通信相手装置と通信を開始する時、現在接続中のＩＰサブネットで所得したＩＰアドレスを適用して、上記通信相手装置へのセッションの接続手順を実行するための第２手段と、
上記通信相手装置と通信中に、新たなＩＰサブネットに所属する無線アクセスポイントへのハンドオーバ条件が成立した時、上記通信相手装置に対して、該ＭＮのＩＰアドレスの変更を示す制御パケットを送信し、該ＭＮのＩＰアドレスを現在使用中のＩＰアドレスから上記新たなＩＰサブネットで取得済みの新たなＩＰアドレスに切替えるための第３手段を備えたことを特徴とする移動ノード装置。
複数の無線回線インタフェースと、
上記各無線回線インタフェースの識別子と対応付けて、使用すべきＩＰアドレスと、アクセスポイントの識別子と、該無線回線インタフェースの使用状態を示す接続フラグとからなる管理情報を記憶する複数のエントリからなる端末状態管理テーブルとを備え、
前記第１手段が、上記端末状態管理テーブルで空き状態のエントリと対応する無線回線インタフェースを通して、前記新たな無線アクセスポイントを探索し、新たに検出された無線アクセスポイントの識別子と、新たに取得したＩＰアドレスを上記エントリに記憶し、無線アクセスポイントの識別子が他のエントリよりも先に記憶されたエントリの接続フラグを現用状態、無線アクセスポイントの識別子が後で記憶されたエントリの接続フラグを予備状態に設定し、
前記第２手段が、上記端末状態管理テーブルで接続フラグが現用状態となっているエントリが示すＩＰアドレスと無線回線インタフェースを使用して、前記ＣＮへのセッションの接続手順を実行し、
前記第３手段が、接続フラグが現用状態を示している第１の無線アクセスポイントから、接続フラグが予備状態を示している新たなサブネットの第２の無線アクセスポイントへのハンドオーバ条件が成立したとき、上記第１の無線アクセスポイントと対応する接続フラグを予備状態、上記第２の無線アクセスポイントと対応する接続フラグを現用状態に切替え、該ＭＮのＩＰアドレスを上記第２の無線アクセスポイントと対応するＩＰアドレスに切り替えることを特徴とする請求項７に記載の移動ノード装置。
前記第１手段が、接続状態にある無線アクセスポイントから送信されたビーコン信号の受信レベルが所定の閾値より低下したとき、該無線アクセスポイントとの接続を解除し、前記端末状態管理テーブルに記憶されている上記無線アクセスポイントと対応するエントリの管理情報を削除することを特徴とする請求項８に記載移動ノード装置。
前記通信相手装置との呼制御の状態を示す接続管理テーブルを有し、
前記第２手段が、上記接続管理テーブルに従って通信相手装置と通信中か否かを判定して、前記ＩＰアドレスの変更を示す制御パケットの送信要否を判断することを特徴とする請求項７または請求項９に記載の移動ノード装置。
それぞれが少なくとも１つの複数アクセスポイントを含み、固定網に接続されている複数のＩＰサブネットからなる移動通信システムで使用される移動ノード装置（ＭＮ）であって、
移動中に定期的に実行されるビーコン信号受信処理によって、通信圏内に位置した新たな無線アクセスポイントを検出したとき、該無線アクセスポイントとの間で所定の接続手順を実行し、新たなＩＰサブネットに所属する無線アクセスポイントに接続された場合、該ＩＰサブネットで使用すべき新たなＩＰアドレスの取得手順を実行し、接続状態にある無線アクセスポイントからのビーコン信号の受信レベルが閾値よりも低下したとき、該無線アクセスポイントとの接続を解除するための第１手段と、
通信相手装置と通信を開始する時、現在接続中のＩＰサブネットで所得したＩＰアドレスを適用して、上記固定網に接続されたセッション管理サーバとの間で、上記通信相手装置へのセッションの接続手順を実行するための第２手段と、
上記通信相手装置と通信中に、該ＭＮが新たなＩＰサブネットに所属する無線アクセスポイントにハンドオーバされた時、上記通信相手装置に対して、該ＭＮのＩＰアドレスの変更を示す制御パケットを送信し、該ＭＮのＩＰアドレスを現在使用中のＩＰアドレスから上記新たなＩＰアドレスに切替えるための第３手段とを有し、
上記第２手段が、上記通信相手装置と通信中に上記接続状態にある無線アクセスポイントからのビーコン信号の受信レベルが閾値よりも低下したとき、上記通信相手装置とセッション管理サーバにハンドオーバを予告する制御パケットを送信した後、新たな無線アクセスポイントとの間で所定の接続手順を実行することを特徴とする移動ノード装置。
固定網に接続された複数のＩＰサブネットを含み、第１のＩＰサブネットを経由して通信相手装置と通信中の移動ノード（ＭＮ）が、第２のＩＰサブネットに移動したとき、上記第１のＩＰサブネットから上記第２のＩＰサブネットにハンドオーバされる移動通信システムにおける移動ノード装置（ＭＮ）のＩＰアドレスの切替え方法であって、
上記ＭＮが、上記第１のサブネットで取得した第１のＩＰアドレスを使用して、上記通信相手装置との間にコネクションの設定のための通信手順を実行するステップと、
上記ＭＮが、上記コネクションを通して上記通信相手装置と通信中に、定期的に実行されるビーコン信号受信処理によって、上記第２のＩＰサブネットに所属した無線アクセスポイントを検知し、該第２のＩＰサブネットで使用すべき第２のＩＰアドレスを取得するステップと、
上記第１のＩＰサブネットから上記第２のＩＰサブネットへのハンドオーバ条件が成立した時点で、上記ＭＮから上記通信相手装置に、上記コネクションの維持を指令するコネクション維持通知パケットを送信するステップと、
上記ＭＮが、上記コネクション維持通知パケットを送信した後、該ＭＮのＩＰアドレスを上記第１のＩＰアドレスから上記第２のアドレスに変更することを示すＩＰアドレス変更通知パケットを上記通信相手装置に送信するステップとからなり、
上記通信相手装置が上記ＩＰアドレスの変更通知パケットを受信した後、上記ＭＮと上記通信相手装置が、上記ＭＮ用のＩＰアドレスを上記第１のＩＰアドレスから上記第２のＩＰアドレスに切り替えて、上記第２のＩＰサブネット経由で通信するようにしたことを特徴とするＩＰアドレスの切替え方法。
前記通信相手装置が、前記ＩＰアドレスの変更通知パケットに対する応答パケットを前記ＭＮに返送し、
上記ＭＮが、上記応答パケットを受信した後、前記第１のＩＰサブネットとの接続を解除することを特徴とする請求項１２に記載のＩＰアドレスの切替え方法。
前記通信相手装置が、前記ＭＮからの要求に応じて一連のデータを送信するサーバであり、
前記通信相手装置が、前記コネクション維持通知パケットを受信した時、上記ＭＮ宛のデータ送信を停止し、前記ＩＰアドレスの変更通知パケットを受信した後に、前記第２のＩＰアドレスを適用して、上記ＭＮ宛のデータ送信を再開することを特徴とする請求項１２に記載のＩＰアドレスの切替え方法。
前記通信相手装置が、前記コネクション維持通知パケットを受信した時に上記ＭＮに送信中のデータパケットがあった場合、該データパケットを送信した後に上記ＭＮ宛の新たなデータの送信を停止することを特徴とする請求項１４に記載のＩＰアドレスの切替え方法。
前記通信相手装置が、前記コネクション維持通知パケットを受信した時、該ＭＮからの確認応答待ち状態にあるデータから、前記第２のＩＰアドレスを適用したデータ送信を再開することを特徴とする請求項１５に記載のＩＰアドレスの切替え方法。
それぞれが少なくとも１つのアクセスポイントを含み、固定網に接続されている複数のＩＰサブネットからなる移動通信システムで使用される移動ノード装置（ＭＮ）であって、
移動中に定期的に実行されるビーコン信号受信処理によって、通信圏内に位置した新たな無線アクセスポイントを検出したとき、該無線アクセスポイントとの間で所定の接続手順を実行し、新たなＩＰサブネットに所属する無線アクセスポイントに接続されたとき、該ＩＰサブネットで使用すべき新たなＩＰアドレスの取得手順を実行するための第１手段と、
通信相手装置と通信を開始する時、現在接続中のＩＰサブネットで所得したＩＰアドレスを適用して、上記通信相手装置との間でコネクションの設定手順を実行するための第２手段と、
上記通信相手装置と通信中に、新たなＩＰサブネットに所属する無線アクセスポイントへのハンドオーバ条件が成立した時、上記通信相手装置に対して、上記コネクションの維持を指令するコネクション維持通知パケットを送信し、上記通信相手装置から応答パケットを受信した後で、上記通信相手装置に該ＭＮのＩＰアドレスの変更を示す制御パケットを送信し、該ＭＮのＩＰアドレスを現在使用中のＩＰアドレスから上記新たなＩＰサブネットで取得済みの新たなＩＰアドレスに切替えるための第３手段を備えたことを特徴とする移動ノード装置。
複数の無線ＩＰサブネット間を移動する移動ノード装置（ＭＮ）との間にＴＣＰ（Transmission Control Protocol）コネクションを形成し、該ＴＣＰコネクションを通して上記ＭＮにデータを送信するサーバであって、
上記複数の無線ＩＰサブネットと接続される固定網上の１つのルータに接続される回線インタフェースと、
上記回線インタフェースに接続されたプロトコル処理部と、
送信データを宛先ＩＰアドレスと対応付けて一時的に格納するためのバッファメモリと、
上記ＭＮとの間でＴＣＰコネクション設定のための通信手順を実行した後、上記ＭＮからの要求に応じて、上記ＭＮに送信すべき一連のデータを上記バッファメモリに書き込む主制御部とからなり、
上記プロトコル処理部が、上記バッファメモリから読み出したデータを宛先ＩＰアドレスを含むデータパケットとして上記回線インタフェースに送出し、
上記主制御部が、上記ＭＮからコネクション維持通知を受信した時、上記プロトコル処理部に上記ＭＮ宛のデータ送信の停止を指令し、上記ＭＮからＩＰアドレスの変更通知を受信した時、上記プロトコル処理部に、変更されたＩＰアドレスによる上記ＭＮ宛のデータ送信の再開を指令することを特徴とするサーバ。