(57)【要約】【課題】  ベアラの両方のエンドポイントを同時に遅延なく移転させることができる方法を提供する。【解決手段】  ベアラがエンドポイントＡとエンドポイントＢとを備えるとき、エンドポイントＢをエンドポイントＣへ引き継ぐための方法であって、第１の移転開始リクエストをＣからＡへ送信することによってＢの移転を開始し、Ｂに関する論理結合を定義する状態情報の更新を要求するために状態情報更新リクエストをＡからＢへ送信し、これに応答してＢの論理結合を定義する状態情報の更新し、ＢからＡへ更新ＡＣＫメッセージを送信し、更に、エンドポイントＡをエンドポイントＤへ移転することに関連する第２の移転開始リクエストがＢによって検出された場合、Ｄのインディケーションを含むメッセージをＣへ送信し、エンドポイントＤを表す情報がＣに伝達されたことを知らせる更なる更新ＡＣＫメッセージが、Ａから送信されてＢによって受信されるまでは、Ｂの状態情報の更新を遅らせる。【選択図】  図５
2007208983.tif 000002
【特許請求の範囲】
【請求項１】
ベアラ・エンドポイントは通信サービスの終端となる論理オブジェクトであり、ベアラはベアラ・エンドポイント間の論理結合であり、前記ベアラと前記ベアラ・エンドポイントとの間の論理結合は状態情報の中に定義され、前記ベアラが第１のベアラ・エンドポイントと第２のベアラ・エンドポイントとを備えるとき、前記第１のベアラ・エンドポイントを第３のベアラ・エンドポイントへ引き継ぐための方法であって、
前記第１のベアラ・エンドポイントの移転を開始するためのリクエストを前記第３のベアラ・エンドポイントから前記第２のベアラ・エンドポイントへ送信することによって前記第１のベアラ・エンドポイントの移転を開始するステップと、
前記第１のベアラ・エンドポイントに関する論理結合を定義する状態情報の更新を要求するために、状態情報の更新をリクエストするメッセージを、前記第２のベアラ・エンドポイントから前記第１のベアラ・エンドポイントへ送信するステップと、
これらベアラ・エンドポイントの移転を反映させるため、前記第２のベアラ・エンドポイントから前記第１のベアラ・エンドポイントへ送信された前記状態情報の更新をリクエストするメッセージに応答して、前記第１のベアラ・エンドポイントに関する論理結合を定義する前記状態情報の更新を実行するステップと、
前記第１のベアラ・エンドポイントに関する論理結合を定義する前記状態情報の更新のリクエストに確認応答するために、前記第１のベアラ・エンドポイントから前記第２のベアラ・エンドポイントへ更新ＡＣＫ（確認応答）メッセージを送信するステップとを含んでおり、
当該方法は、
前記第２のベアラ・エンドポイントを第４のベアラ・エンドポイントへ移転することに関連する前記第２のベアラ・エンドポイントの移転を開始するためのリクエストが、前記状態情報の更新が実行される前に前記第１のベアラ・エンドポイントによって検出された場合において、
前記第４のベアラ・エンドポイントのインディケーションを含むメッセージを前記第３のベアラ・エンドポイントへ送信し、
前記第４のベアラ・エンドポイントを表す情報が前記第３のベアラ・エンドポイントに伝達されたことを知らせる更なる更新ＡＣＫメッセージが、前記第２のベアラ・エンドポイントから送信されて前記第１のベアラ・エンドポイントによって受信されるまでは、前記第１のベアラ・エンドポイントに関する論理結合を定義する前記状態情報の更新を遅らせるステップを含んでいる、方法。
【請求項２】
前記第１及び第２のベアラ・エンドポイントを定義する前記状態情報は、エンドポイントの論理名とロケータとの間のマッピングを含んでおり、
前記エンドポイントに対する論理名はホスト識別プロトコル（ＨＩＰ）で使用されるホスト識別タグであり、前記ロケータはＩＰアドレスである、請求項１に記載の方法。
【請求項３】
前記第１のベアラ・エンドポイントによって送信される更新ＡＣＫメッセージは、前記第４のベアラ・エンドポイントのインディケーションを含むものである、請求項１又は２に記載の方法。
【請求項４】
前記第２のベアラ・エンドポイントから前記第１のベアラ・エンドポイントへ前記更なる更新ＡＣＫメッセージを送信する前に、前記第２のベアラ・エンドポイントから前記第３のベアラ・エンドポイントへ更新リクエスト完了メッセージを送信するステップを更に含んでいる、請求項１乃至３のいずれか１項に記載の方法。
【請求項５】
前記更新リクエスト完了メッセージは、前記第４のベアラ・エンドポイントのインディケーションを含むものである、請求項４に記載の方法。
【請求項６】
前記第３のベアラ・エンドポイントから前記第２のベアラ・エンドポイントへ前記第１のベアラ・エンドポイントの移転を開始するためのリクエストを送信した後に、前記第２のベアラ・エンドポイントから前記第３のベアラ・エンドポイントへリーチアビリティ・リプライ・リクエスト・メッセージを送信するステップと、
前記第３のベアラ・エンドポイントから前記第２のベアラ・エンドポイントへリーチアビリティ・リプライ・メッセージを送信するステップと
を更に含んでいる、請求項１乃至５のいずれか１項に記載の方法。
【請求項７】
前記第１のベアラ・エンドポイントが、前記第４のベアラ・エンドポイントから前記第１のベアラ・エンドポイントへ送信された前記第２のベアラ・エンドポイントの移転を開始するためのリクエスト・メッセージ又は前記リーチアビリティ・リプライ・メッセージを受信することによって、前記第２のベアラ・エンドポイントの移転を開始するためのリクエストを検出するステップを更に含んでいる、請求項１乃至６のいずれか１項に記載の方法。
【請求項８】
前記第１のベアラ・エンドポイントによって受信された前記第２のベアラ・エンドポイントの移転を開始するためのリクエストに応答して、前記第１のベアラ・エンドポイントから前記第２のベアラ・エンドポイントへ前記状態情報の更新をリクエストするメッセージを送信するステップと、
前記第２のベアラ・エンドポイントから前記第１のベアラ・エンドポイントへ前記更新ＡＣＫメッセージを送信するステップと、
前記第３のベアラ・エンドポイントのインディケーションを含むメッセージを前記第４のベアラ・エンドポイントへ送信するステップと、
前記第２のベアラ・エンドポイントに関する論理結合を定義する前記状態情報の更新を実行するステップとを含んでおり、
前記第２のベアラ・エンドポイントに関する論理結合を定義する前記状態情報の更新は、前記第３のベアラ・エンドポイントを表す情報が第４のベアラ・エンドポイントに伝達されたことを知らせる前記更なる更新ＡＣＫメッセージが、前記第１のベアラ・エンドポイントから送信されて前記第２のベアラ・エンドポイントによって受信されるまで遅らされる、請求項１乃至７のいずれか１項に記載の方法。
【請求項９】
前記第２のベアラ・エンドポイントによって送信される前記更新ＡＣＫメッセージは、前記第３のベアラ・エンドポイントのインディケーションを含むものである、請求項８に記載の方法。
【請求項１０】
前記更なる更新ＡＣＫメッセージを第１のベアラ・エンドポイントから第２のベアラ・エンドポイントへ送信する前に、更新リクエスト完了メッセージを前記第１のベアラ・エンドポイントから前記第４のベアラ・エンドポイントへ送信するステップを更に含んでいる、請求項８又は９に記載の方法。
【請求項１１】
前記更新リクエスト完了メッセージは、前記第３のベアラ・エンドポイントのインディケーションを含むものである、請求項８乃至１０のいずれか１項に記載の方法。
【請求項１２】
前記第１のベアラ・エンドポイントが前記第３のベアラ・エンドポイントへ引き継がれるような第１のベアラ・エンドポイントの移転に関連するメッセージと、
前記第２のベアラ・エンドポイントが前記第４のベアラ・エンドポイントへ引き継がれるような第２のベアラ・エンドポイントの移転に関連するメッセージとは、交互に送信される、請求項１乃至１１のいずれか１項に記載の方法。
【請求項１３】
ベアラ・エンドポイントは通信サービスの終端となる論理オブジェクトであり、ベアラはベアラ・エンドポイント間の論理結合であり、前記ベアラと前記ベアラ・エンドポイントとの間の論理結合は状態情報の中に定義され、前記ベアラが第１のベアラ・エンドポイントと第２のベアラ・エンドポイントとを備えるとき、前記第１のベアラ・エンドポイントを第３のベアラ・エンドポイントへ引き継ぐための装置であって、
第１のベアラ・エンドポイントの移転を開始するためのリクエストを、前記第３のベアラ・エンドポイントから前記第２のベアラ・エンドポイントへ送信することによって、第１のベアラ・エンドポイントの移転を開始するためのモジュールと、
前記第１のベアラ・エンドポイントに関する論理結合を定義する状態情報の更新を要求するために、状態情報の更新をリクエストするメッセージを前記第２のベアラ・エンドポイントから前記第１のベアラ・エンドポイントへ送信するためのモジュールと、
これらベアラ・エンドポイントの移転を反映させるため、前記第２のベアラ・エンドポイントから前記第１のベアラ・エンドポイントへ送信された前記状態情報の更新をリクエストするメッセージに応答して、前記第１のベアラ・エンドポイントに関する論理結合を定義する前記状態情報の更新を実行するためのモジュールと、
前記第１のベアラ・エンドポイントに関する論理結合を定義する前記状態情報の更新のリクエストに確認応答するために、前記第１のベアラ・エンドポイントから前記第２のベアラ・エンドポイントへ更新ＡＣＫメッセージを送信するためのモジュールとを備えており、
当該装置は、
前記状態情報の更新が実行される前に、前記第１のベアラ・エンドポイントによって、前記第２のベアラ・エンドポイントを前記第４のベアラ・エンドポイントへ移転することに関連する前記第２のベアラ・エンドポイントの移転を開始するためのリクエストの有無を検出し、該リクエストが検出された場合において、
前記第４のベアラ・エンドポイントのインディケーションを含むメッセージを前記第３のベアラ・エンドポイントへ送信し、
前記第４のベアラ・エンドポイントを表す情報が前記第３のベアラ・エンドポイントに伝達されたことを知らせる更なる更新ＡＣＫメッセージが、前記第２のベアラ・エンドポイントから送信されて前記第１のベアラ・エンドポイントによって受信されるまで、前記第１のベアラ・エンドポイントに関する論理結合を定義する前記状態情報の更新を遅らせるように構成されているモジュールを更に備えている、
装置。
【請求項１４】
ベアラ・エンドポイントは通信サービスの終端となる論理オブジェクトであり、ベアラはベアラ・エンドポイント間の論理結合であり、前記ベアラと前記ベアラ・エンドポイントとの間の論理結合は状態情報の中に定義され、前記ベアラが第１のベアラ・エンドポイントと第２のベアラ・エンドポイントとを備えるとき、前記第１のベアラ・エンドポイントを第３のベアラ・エンドポイントへ引き継ぐための装置であって、ここで、前記第１のベアラ・エンドポイントと前記第２のベアラ・エンドポイントとを備える前記ベアラのベアラ・エンドポイントが、前記第１のベアラ・エンドポイントが第３のベアラ・エンドポイントによって置き換えられるように移転され、この移転の完了には、前記ベアラと前記ベアラ・エンドポイントとの間の論理結合を定義する状態情報の更新が含まれ、これにより、ネットワークにおけるベアラ・モビリティを実現するような装置であり、
前記第３のベアラ・エンドポイントから前記第２のベアラ・エンドポイントへ第１のベアラ・エンドポイントの移転を開始するためのリクエストを送信することによって前記第１のベアラ・エンドポイントの移転が開始された後に、前記第１のベアラ・エンドポイントに関する論理結合を定義する状態情報の更新を要求するために前記第２のベアラ・エンドポイントから送信されるような状態情報の更新をリクエストするメッセージを、前記第１のベアラ・エンドポイントによって受信するためのモジュールと、
これらのベアラ・エンドポイントの移転を反映させるために、前記第２のベアラ・エンドポイントから前記第１のベアラ・エンドポイントへの前記状態情報の更新をリクエストするメッセージに応答して、前記第１のベアラ・エンドポイントに関する論理結合を定義する前記状態情報の更新を実行するモジュールと、
前記第１のベアラ・エンドポイントに関する論理結合を定義する前記状態情報の更新のリクエストに確認応答するために、前記第１のベアラ・エンドポイントから前記第２のベアラ・エンドポイントへ更新ＡＣＫメッセージを送信するためのモジュールとを備えており、
当該装置は、
前記状態情報の更新が実行される前に、前記第１のベアラ・エンドポイントによって、前記第２のベアラ・エンドポイントを前記第４のベアラ・エンドポイントへ移転することに関連する第２のベアラ・エンドポイントの移転を開始するためのリクエストの有無を検出し、該リクエストが検出された場合において、
前記第４のベアラ・エンドポイントを表す情報が第３のベアラ・エンドポイントに伝達されたことを知らせる更なる更新ＡＣＫメッセージが、前記第２のベアラ・エンドポイントから送信されて前記第１のベアラ・エンドポイントによって受信されるまで、前記第１のベアラ・エンドポイントに関する論理結合を定義する前記状態情報の更新を遅らせるように構成されているモジュールを更に備えている、装置。
【請求項１５】
ベアラ・エンドポイントは通信サービスの終端となる論理オブジェクトであり、ベアラはベアラ・エンドポイント間の論理結合であり、前記ベアラと前記ベアラ・エンドポイントとの間の論理結合は状態情報の中に定義され、前記ベアラが第１のベアラ・エンドポイントと第２のベアラ・エンドポイントとを備えるとき、前記第１のベアラ・エンドポイントを第３のベアラ・エンドポイントへ引き継ぐための装置であって、
第１のベアラ・エンドポイントの移転を開始するためのリクエストを前記第３のベアラ・エンドポイントから前記第２のベアラ・エンドポイントへ送信することによって前記第１のベアラ・エンドポイントの移転が開始された後に、前記第２のベアラ・エンドポイントから前記第１のベアラ・エンドポイントへ、状態情報の更新をリクエストするメッセージを送信して、移転を反映させるために前記第２のベアラ・エンドポイントから前記第１のベアラ・エンドポイントへ送信された前記状態情報の更新をリクエストするメッセージに応答して、前記第１のベアラ・エンドポイントに関する論理結合を定義する状態情報の更新の実行を要求するためのモジュールと、
第１のベアラ・エンドポイントに関する論理結合を定義する状態情報の更新のリクエストに確認応答するために、前記第１のベアラ・エンドポイントから前記第２のベアラ・エンドポイントへ送信された更新ＡＣＫメッセージを受信するためのモジュールとを備えており、
当該装置は、
前記状態情報の更新が実行される前に、前記第１のベアラ・エンドポイントによって、前記第２のベアラ・エンドポイントを第４のベアラ・エンドポイントへ移転することに関連する第２のベアラ・エンドポイントの移転を開始するためのリクエストの有無を検出し、該リクエストが検出された場合において、
前記第４のベアラ・エンドポイントのインディケーションを含むメッセージを前記第３のベアラ・エンドポイントへ送信し、
前記第４のベアラ・エンドポイントを表す情報が前記第３のベアラ・エンドポイントに伝達されたことを知らせる更なる更新ＡＣＫメッセージを前記第２のベアラ・エンドポイントから前記第１のベアラ・エンドポイントへ送信し、前記第１のベアラ・エンドポイントが前記第２のベアラ・エンドポイントから前記更なる更新ＡＣＫメッセージを受信するまで、前記第１のベアラ・エンドポイントに関する論理結合を定義する前記状態情報の更新が遅らされるように構成されているモジュールを更に備えている、装置。
【請求項１６】
請求項２乃至１２のいずれか１項に記載された方法を実行するための手段、又はモジュールを更に備えている請求項１３乃至１５のいずれか１項に記載の装置。
【請求項１７】
請求項１乃至１２のいずれか１項に記載された方法をコンピュータ上で実行するコンピュータ・プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ベアラ・モビリティ、特に２つのベアラ・エンドポイントを同時に移転させる技術に関する。
【背景技術】
【０００２】
ベアラ・モビリティ（bearer mobility）という用語は、異なる物理的装置に存在し得る１つのアプリケーション・エンドポイントから別のアプリケーション・エンドポイントへのデータフローの移転（move）を意味する。それは例えば、ＰＤＡ上で動画の始まりを視聴し、コンピュータ上でその終わりを視聴することを意味する。
【０００３】
最初に、本明細書で使用されるいくつかの用語について説明する。
・エンドポイント（Endpoint）：通信サービスの終端となる論理オブジェクト（logical object）。異なるエンドポイントが異なるレイヤ（例えば、アプリケーションレイヤ、ＴＣＰレイヤ、ＩＰレイヤなど）に存在する。
・ホスト／端末：ネットワーク上で通信する物理的装置。
・ベアラ（Bearer）：通信し合うアプリケーション（例えば、メディア・ストリーミング）エンドポイントの間の論理結合（Logical association）。
・フロー（Flow）：通信し合うネットワークレイヤ（例えばＴＣＰ、ＨＩＰ）エンドポイント同士の間の論理結合。
・セッション：ベアラにより通信し合うアプリケーション（複数）によって共有される状態。
・端末間のエンドポイント・モビリティ：１つの端末から別の端末へのエンドポイントのモビリティ、及び、その結果としての、エンドポイントに結びついたベアラ又はフローのモビリティ。これは、通信のエンドポイントが、アプリケーションが認識することにおいては、通信チャネル及びプロトコルの状態に影響を及ぼすことなく、１つの端末（例えば、ある携帯電話機）から別の端末（例えば、コンピュータ）へ移転するシナリオである。
【０００４】
図１は、“古い”デバイスと“固定された”送り先デバイスとの間の接続を表すベアラが“新しい”デバイスに移転する場合にベアラ・モビリティがどのように働くかを示している。
【０００５】
新しいデバイスから固定されたデバイスへ初期化メッセージが送られた後、固定されたデバイスは、新しいデバイスへリーチアビリティ・リクエスト（reachability request：通信到達可能性リクエスト）を発信し、次に新しいデバイスからリーチアビリティ・リプライ（reachability reply：通信到達可能性応答）が返信される。これらのリーチアビリティ・リクエスト及びリーチアビリティ・リプライ・メッセージは、偽装（なりすまし）攻撃を避けるためにアドレス検査を実行し、更に、リクエストをしているデバイスの主張したアドレスを確認する役割を果たす。
【０００６】
次に、“固定された”デバイスは、古いエンドポイントに合意確認リクエスト（agreement verification request）を送信する。これは、ベアラ・エンドポイントを定義する状態情報（例えば、ホスト識別プロトコル（ＨＩＰ：Host Identity Protocol）で使用されるホスト識別タグ）の更新をトリガーする。続いて、古いエンドポイントは、固定されたエンドポイントへ合意リプライ（agreement reply）を返信し、次に、固定されたエンドポイントは新しいエンドポイントに対し、移転が今成立し、新しいエンドポイントがベアラを引き継ぐことが可能であることを通知する。
【０００７】
次に図２を参照して、ベアラ・モビリティ・プロトコルについて詳しく説明する。本例では、エンドポイントＢは、エンドポイントＡが固定されている状態にある間に、新しいエンドポイントＣに移転されなくてはならない。本例は、ホスト識別プロトコル（ＨＩＰ）を利用する。
【０００８】
このメカニズムは、ＨＩＰのような交換に基づいており、エンドポイントが移転する前にベアラ・エンドポイントのオーナー同士の間にＨＩＰ接続（HIP association）が存在することを仮定する。ＨＩＰ（ホスト識別プロトコル）は、ＩＰスタックのネットワークレイアとトランスポートレイヤとの間に挿入されるプロトコルである。このＨＩＰプロトコルは一般的に、個々のデバイスの公開鍵のハッシュ値であるＨＩ（Host Identity）の新しい名前空間（name space）を導入することによって、接続（コネクション）のエンドポイントをＩＰアドレスから切り離す。これらはその後、ＩＰアドレスにマップ（map）される。ＴＣＰ／ＩＰとのソケットインタフェースでは、ソケットは一般的にはＩＰアドレス及びポート番号にバインド（結び付け）されている。ＨＩＰが使用されるときには、ソケットは、ＨＩ（あるいはホスト識別タグ、ＨＩのハッシュ値）及びポート番号にバインドされている。データパケットがある１つのソケットから別のソケットに送られるとき、送信元と送信先のＨＩは、ＩＰパケットの対応するフィールドに入れるために使用される適切なロケータ（locator）ＩＰアドレスにマップされ、ＩＰネットワークにおけるパケットのルーティングが可能となる。
【０００９】
ＨＩＰプロトコルでは、エンドポイントのオーナーは、暗号識別子（すなわち、公開鍵と秘密鍵のペア）で識別される。暗号識別子を利用することで、デジタル署名によるメッセージの認証が可能となり、偽装攻撃から防御することができる。
【００１０】
次に、図２を参照して本プロトコルを説明する。第１のメッセージＩ１は初期化メッセージであり、第２のメッセージはリーチアビリティ・リクエストＲ１である。この後に、リーチアビリティ・リプライに相当する第３のメッセージが続く。この第３のメッセージは、ベアラ識別子（Ｂid）と、エンドポイントＢ及びＣのＨＩＴ（ホスト識別タグ）とを含んでいる。これは、更新プロセスを実際にトリガーするメッセージである。メッセージ３に応答して、固定されたエンドポイントから、移転すべき古いエンドポイントへ、更新リクエスト・メッセージ（メッセージ４）が送信される。このメッセージは、ベアラの移転先である新しいエンドポイントＣのホスト識別子ＨＩＴを含んでいる。
【００１１】
更新リクエストに応答して、エンドポイントＢにおけるホスト識別子のマッピングが新しいエンドポイントＣを反映するよう更新され、次に更新ＡＣＫ（acknowledgement＝確認応答）メッセージが送信される。この更新ＡＣＫメッセージ（update acknowledgement message）に応答して、古いベアラ・エンドポイント及び新しいベアラ・エンドポイントの識別子を含む移転（transfer）を終了するための最終メッセージＲ２が送信される。これにより移転が完了し、新しいエンドポイントＣが接続を継続することができる。
【００１２】
図３は、本プロトコルを詳しく説明するためのシーケンス図である。ノード３はここでは図２に示されている新しいノードＣを表しており、ノード２は図２のノードＢに対応し、ノード１は図２のノードＡに対応している。
【００１３】
全体のプロセスは、外部のトリガー・メッセージによって開始される。まずノード３が、初期化メッセージＩ１を送信する。次に、ノード１がリーチアビリティ・リクエストＲ１を返信する。続いて、リーチアビリティ・リプライＩ２が、図３において、ノード１からノード２へのＵＰＤと、ノード２からノード１へのＵＰＤＡＣＫメッセージとで示されている更新処理をトリガーする。
【００１４】
最後に、移転を完了するための最終完了メッセージがノード１からノード３へ送信される。
【００１５】
しかしながら、本プロトコルでは２つのベアラ・エンドポイントが同時に移転したい場合に問題が生じる。このケースを図４に示す。本図において、ベアラ・エンドポイントＢは、ベアラ・エンドポイントＣへの移転を望んでおり、且つ、ベアラ・エンドポイントＡは、ベアラ・エンドポイントＤへの移転を望んでいる。このようなケースでは、整合性（consistency）の問題が起こる可能性がある。
【００１６】
１つの解決策としては、全体の手続きをシリアル化することが考えられる。いわゆるＳＩＰ（session invitation protocol）は、このアプローチに沿ったものである。ＳＩＰの場合、両方のエンドポイントがＲＥ−ＩＮＶＩＴＥメッセージを同時に受信したら、それらは両方ともリクエスト保留メッセージ（request pending message）を送信する。次にそれらのどちらか一方は、ＲＥ−ＩＮＶＩＴＥを０秒から２秒までのランダムな秒数だけ遅らせる。しかしこのアプローチは、避けるべき望ましくない遅延を含むことは明らかである。
【発明の開示】
【発明が解決しようとする課題】
【００１７】
そこで本発明の課題は、両方のエンドポイントが同時に移転する場合においても従来技術の上記欠点を伴うことなくベアラ・モビリティを実現するために適用することができる方法を提供することにある。
【課題を解決するための手段】
【００１８】
上記課題を解決することができる１つの手段として、ベアラ・エンドポイントは通信サービスの終端となる論理オブジェクトであり、ベアラはベアラ・エンドポイント間の論理結合（logical association）であり、前記ベアラと前記ベアラ・エンドポイントとの間の論理結合は状態情報（state information）の中に定義され、前記ベアラが第１のベアラ・エンドポイントと第２のベアラ・エンドポイントとを備えるとき、第１のベアラ・エンドポイントを第３のベアラ・エンドポイントへ引き継ぐための方法であって、第１のベアラ・エンドポイントの移転を開始するためのリクエストを前記第３のベアラ・エンドポイントから前記第２のベアラ・エンドポイントへ送信することによって前記第１のベアラ・エンドポイントの移転を開始するステップと、前記第１のベアラ・エンドポイントに関する論理結合を定義する状態情報の更新を要求するために、状態情報の更新をリクエストするメッセージを前記第２のベアラ・エンドポイントから前記第１のベアラ・エンドポイントへ送信するステップと、これらベアラ・エンドポイントの移転を反映させるため、前記第２のベアラ・エンドポイントから前記第１のベアラ・エンドポイントへ送信された前記状態情報の更新をリクエストするメッセージに応答して、前記第１のベアラ・エンドポイントに関する論理結合を定義する前記状態情報の更新を実行するステップと、前記第１のベアラ・エンドポイントに関する論理結合を定義する前記状態情報の更新のリクエストに確認応答するために、前記第１のベアラ・エンドポイントから前記第２のベアラ・エンドポイントへ更新ＡＣＫ（確認応答）メッセージを送信するステップとを含んでおり、当該方法は更に、前記第２のベアラ・エンドポイントを第４のベアラ・エンドポイントへ移転することに関連する第２のベアラ・エンドポイントの移転を開始するためのリクエストが、前記状態情報の更新が実行される前に前記第１のベアラ・エンドポイントによって検出された場合において、前記第４のベアラ・エンドポイントのインディケーション（indication：第４のベアラ・エンドポイントを表す情報）を含むメッセージを前記第３のベアラ・エンドポイントへ送信し、前記第４のベアラ・エンドポイントを表す情報が前記第３のベアラ・エンドポイントに伝達されたことを知らせる更なる更新ＡＣＫメッセージが、前記第２のベアラ・エンドポイントから送信されて前記第１のベアラ・エンドポイントによって受信されるまでは、前記第１のベアラ・エンドポイントに関する論理結合を定義する前記状態情報の更新を遅らせるステップを更に含んでいる方法が提供される。
【００１９】
第２のベアラ・エンドポイントの移転を開始するためのリクエストは、それと共に第２のベアラ・エンドポイントの移転の移転先に関する情報を、第１のベアラ・エンドポイントの移転の移転先に送信し、且つ、更なる更新ＡＣＫメッセージが受信されるまで状態情報の実際の更新が遅らされることにより、従来技術におけるようなシリアル化アプローチに伴う欠点を避けるための、いわゆるダブルジャンプ（double-jump）問題に対する解決策を提供することができる。
【００２０】
本方法の１つの態様として、第１及び第２のベアラ・エンドポイントを定義する前記状態情報は、エンドポイントの論理名（logical name）とロケータ（locator）との間のマッピングを含んでおり、前記エンドポイントに対する論理名は、ホスト識別プロトコル（ＨＩＰ）で使用されるホスト識別タグであり、前記ロケータはＩＰアドレスである。
【００２１】
ホスト識別タグとＩＰアドレスとの間のマッピングを利用することで、いくつかの有利なセキュリティ機能を提供し、これにより、偽装（なりすまし）攻撃又はサービス妨害を困難にするようなＨＩＰプロトコルを利用することが可能となる。
【００２２】
本方法の１つの態様として、第１のベアラ・エンドポイントによって送信される前記更新ＡＣＫ（確認応答）メッセージは、第４のベアラ・エンドポイントのインディケーションを含んでいる。これにより、第４のベアラ・エンドポイントのインディケーションを転送するための既存のプロトコルにおいて既存のメッセージを利用することが可能となる。
【００２３】
本方法は、１つの態様として、第２のベアラ・エンドポイントから第１のベアラ・エンドポイントへ前記更なる更新ＡＣＫメッセージを送信する前に、第２のベアラ・エンドポイントから第３のベアラ・エンドポイントへ更新リクエスト完了メッセージ（update request completion message）を送信することを更に含む。
【００２４】
本方法の１つの態様として、前記更新リクエスト完了メッセージは、第４のベアラ・エンドポイントのインディケーションを含むものである。
【００２５】
第４のベアラ・エンドポイントのインディケーションを転送するのに更新完了メッセージを利用することで、第４のベアラ・エンドポイントのインディケーションを転送するための既存のプロトコルにおいて既存のメッセージを利用することが可能となる。
【００２６】
本方法は、１つの態様として、前記第３のベアラ・エンドポイントから前記第２のベアラ・エンドポイントへ前記第１のベアラ・エンドポイントの移転を開始するためのリクエストを送信した後に、前記第２のベアラ・エンドポイントから前記第３のベアラ・エンドポイントへリーチアビリティ・リプライ・リクエスト・メッセージ（reachability reply request message）を送信し、前記第３のベアラ・エンドポイントから前記第２のベアラ・エンドポイントへリーチアビリティ・リプライ・メッセージ（reachability reply message）を送信するステップを更に含んでいる。
【００２７】
本方法は、１つの態様として、前記第１のベアラ・エンドポイントが前記第４のベアラ・エンドポイントから前記第１のベアラ・エンドポイントへ送信された前記第２のベアラ・エンドポイントの移転を開始するためのリクエスト・メッセージ又はリーチアビリティ・リプライ・メッセージを受信することによって、前記第２のベアラ・エンドポイントの移転を開始するためのリクエストを検出するステップを更に含んでいる。
【００２８】
本方法は、１つの態様として、前記第１のベアラ・エンドポイントによって受信された前記第２のベアラ・エンドポイントの移転を開始するためのリクエストに応答して、前記第１のベアラ・エンドポイントから前記第２のベアラ・エンドポイントへ前記状態情報の更新をリクエストするメッセージを送信するステップと、前記第２のベアラ・エンドポイントから前記第１のベアラ・エンドポイントへ前記更新ＡＣＫメッセージを送信するステップと、前記第３のベアラ・エンドポイントのインディケーションを含むメッセージを前記第４のベアラ・エンドポイントへ送信するステップと、前記第２のベアラ・エンドポイントに関する論理結合を定義する前記状態情報の更新を実行するステップとを含んでおり、前記第２のベアラ・エンドポイントに関する論理結合を定義する前記状態情報の更新は、前記第３のベアラ・エンドポイントを表す情報が前記第４のベアラ・エンドポイントに伝達されたことを知らせる前記更なる更新ＡＣＫメッセージが、前記第１のベアラ・エンドポイントから送信されて前記第２のベアラ・エンドポイントによって受信されるまで遅らされる。
【００２９】
これにより全体の手続きが対称的になり、更に、異なるベアラ・エンドポイントリクエストに属するメッセージを交互に送信することが可能となる。
【００３０】
本方法の１つの態様として、前記第２のベアラ・エンドポイントによって送信される前記更新ＡＣＫメッセージは、前記第３のベアラ・エンドポイントのインディケーションを含むものである。
【００３１】
本方法は、１つの態様として、前記更なる更新ＡＣＫメッセージを前記第１のベアラ・エンドポイントから前記第２のベアラ・エンドポイントへ送信する前に、更新リクエスト完了メッセージを前記第１のベアラ・エンドポイントから前記第４のベアラ・エンドポイントへ送信するステップを更に含んでいる。
【００３２】
本方法の１つの態様として、前記更新リクエスト完了メッセージは、前記第３のベアラ・エンドポイントのインディケーションを含むものである。
【００３３】
本方法の１つの態様として、前記第１のベアラ・エンドポイントが前記第３のベアラ・エンドポイントへ引き継がれるような第１のベアラ・エンドポイントの移転に関連するメッセージと、前記第２のベアラ・エンドポイントが第４のベアラ・エンドポイントへ引き継がれるような前記第２のベアラ・エンドポイントの移転に関係するメッセージとは、交互に送信される。
【００３４】
上記課題を解決することができる別の手段として、ベアラ・エンドポイントは通信サービスの終端となる論理オブジェクトであり、ベアラはベアラ・エンドポイント間の論理結合（論理的関連性）であり、前記ベアラと前記ベアラ・エンドポイントとの間の論理結合は状態情報の中に定義され、前記ベアラが第１のベアラ・エンドポイントと第２のベアラ・エンドポイントとを備えるとき、前記第１のベアラ・エンドポイントを第３のベアラ・エンドポイントへ引き継ぐための装置であって、第１のベアラ・エンドポイントの移転を開始するためのリクエストを前記第３のベアラ・エンドポイントから前記第２のベアラ・エンドポイントへ送信することによって、第１のベアラ・エンドポイント移転を開始するためのモジュール（module）と、前記第１のベアラ・エンドポイントに関する論理結合を定義する状態情報の更新を要求するために、状態情報の更新をリクエストするメッセージを前記第２のベアラ・エンドポイントから前記第１のベアラ・エンドポイントへ送信するためのモジュールと、これらベアラ・エンドポイントの移転を反映させるため、前記第２のベアラ・エンドポイントから前記第１のベアラ・エンドポイントへ送信された前記状態情報の更新をリクエストするメッセージに応答して、前記第１のベアラ・エンドポイントに関する論理結合を定義する前記状態情報の更新を実行するためのモジュールと、前記第１のベアラ・エンドポイントに関する論理結合を定義する前記状態情報の更新のリクエストに確認応答するために、前記第１のベアラ・エンドポイントから前記第２のベアラ・エンドポイントへ更新ＡＣＫメッセージを送信するためのモジュールとを備えており、当該装置はこれらのモジュールに加えて、前記状態情報の更新が実行される前に、前記第１のベアラ・エンドポイントによって、前記第２のベアラ・エンドポイントを前記第４のベアラ・エンドポイントへ移転することに関する第２のベアラ・エンドポイントの移転を開始するためのリクエストの有無を検出し、該リクエストが検出された場合において、前記第４のベアラ・エンドポイントのインディケーションを含むメッセージを前記第３のベアラ・エンドポイントへ送信し、前記第４のベアラ・エンドポイントをインディケーションする情報が前記第３のベアラ・エンドポイントに伝達されたことを知らせる更なる更新ＡＣＫメッセージが、前記第２のベアラ・エンドポイントから前記第１のベアラ・エンドポイントによって受信されるまで、前記第１のベアラ・エンドポイントに関する論理結合を定義する前記状態情報の更新を遅らせるように構成されているモジュールを更に備えている、装置が提供される。
【００３５】
上記課題を解決することができる更にもう１つの手段として、ベアラ・エンドポイントは通信サービスの終端となる論理オブジェクトであり、ベアラはベアラ・エンドポイント間の論理結合（論理的関連性）であり、前記ベアラと前記ベアラ・エンドポイントとの間の論理結合は状態情報の中に定義され、前記ベアラが第１のベアラ・エンドポイントと第２のベアラ・エンドポイントとを備えるとき、前記第１のベアラ・エンドポイントを第３のベアラ・エンドポイントへ引き継ぐための装置であって、ここで、前記第１のベアラ・エンドポイントと前記第２のベアラ・エンドポイントとを備える前記ベアラのベアラ・エンドポイントが、前記第１のベアラ・エンドポイントが第３のベアラ・エンドポイントによって置き換えられるように移転され、この移転の完了には、前記ベアラと前記ベアラ・エンドポイントとの間の論理結合を定義する状態情報の更新が含まれ、これにより、ネットワークにおけるベアラ・モビリティを実現するような装置であり、前記第３のベアラ・エンドポイントから前記第２のベアラ・エンドポイントへ第１のベアラ・エンドポイントの移転を開始するためのリクエストを送信することによって前記第１のベアラ・エンドポイントの移転が開始された後に、前記第１のベアラ・エンドポイントに関する論理結合を定義する状態情報の更新を要求するために前記第２のベアラ・エンドポイントから送信されるような状態情報の更新をリクエストするメッセージを、前記第１のベアラ・エンドポイントによって受信するためのモジュールと、これらのベアラ・エンドポイントの移転を反映させるために、前記第２のベアラ・エンドポイントから前記第１のベアラ・エンドポイントへの前記状態情報の更新をリクエストするメッセージに応答して、前記第１のベアラ・エンドポイントに関する論理結合を定義する前記状態情報の更新を実行するモジュールと、前記第１のベアラ・エンドポイントに関する論理結合を定義する前記状態情報の更新のリクエストに確認応答するために、前記第１のベアラ・エンドポイントから前記第２のベアラ・エンドポイントへ更新ＡＣＫメッセージを送信するためのモジュールとを備えており、当該装置はこれらのモジュールに加えて、前記状態情報の更新が実行される前に、前記第１のベアラ・エンドポイントによって、前記第２のベアラ・エンドポイントを前記第４のベアラ・エンドポイントへ移転することに関連する第２のベアラ・エンドポイントの移転を開始するためのリクエストの有無を検出し、該リクエストが検出された場合において、前記第４のベアラ・エンドポイントを表す情報が第３のベアラ・エンドポイントに伝達されたことを知らせる更なる更新ＡＣＫメッセージが、前記第２のベアラ・エンドポイントから送信されて前記第１のベアラ・エンドポイントによって受信されるまで、前記第１のベアラ・エンドポイントに関する論理結合を定義する前記状態情報の更新を遅らせるように構成されているモジュールを更に備えている、装置が提供される。
【００３６】
斯かる装置は本発明によれば、第１のベアラ・エンドポイントに実装することが可能である。
【００３７】
上記課題を解決することができる更にもう１つの手段として、ベアラ・エンドポイントは通信サービスの終端となる論理オブジェクトであり、ベアラはベアラ・エンドポイント間の論理結合（論理的関連性）であり、前記ベアラと前記ベアラ・エンドポイントとの間の論理結合は状態情報の中に定義され、前記ベアラが第１のベアラ・エンドポイントと第２のベアラ・エンドポイントとを備えるとき、前記第１のベアラ・エンドポイントを第３のベアラ・エンドポイントへ引き継ぐための装置であって、第１のベアラ・エンドポイントの移転を開始するためのリクエストを前記第３のベアラ・エンドポイントから前記第２のベアラ・エンドポイントへ送信することによって前記第１のベアラ・エンドポイントの移転が開始された後に、前記第２のベアラ・エンドポイントから前記第１のベアラ・エンドポイントへ、状態情報の更新をリクエストするメッセージを送信して、移転を反映させるために前記第２のベアラ・エンドポイントから前記第１のベアラ・エンドポイントへ送信された前記状態情報の更新をリクエストするメッセージに応答して前記第１のベアラ・エンドポイントに関する論理結合を定義する状態情報の更新の実行を要求するためのモジュールと、前記第１のベアラ・エンドポイントに関する論理結合を定義する状態情報の更新のリクエストに確認応答するために、前記第１のベアラ・エンドポイントから前記第２のベアラ・エンドポイントへ送信された更新ＡＣＫメッセージを受信するためのモジュールとを備えており、当該装置はこれらのモジュールに加えて、前記状態情報の更新が実行される前に、前記第１のベアラ・エンドポイントによって、前記第２のベアラ・エンドポイントを第４のベアラ・エンドポイントへ移転することに関する第２のベアラ・エンドポイントの移転を開始するためのリクエストの有無を検出し、該リクエストが検出された場合において、前記第４のベアラ・エンドポイントのインディケーションを含むメッセージを前記第３のベアラ・エンドポイントへ送信し、前記第４のベアラ・エンドポイントを表す情報が前記第３のベアラ・エンドポイントに伝達されたことを知らせる更なる更新ＡＣＫメッセージを前記第２のベアラ・エンドポイントから前記第１のベアラ・エンドポイントへ送信し、前記第１のベアラ・エンドポイントが前記第２のベアラ・エンドポイントから前記更なる更新ＡＣＫメッセージを受信するまで、前記第１のベアラ・エンドポイントに関する論理結合を定義する前記状態情報の更新が遅らされるように構成されているモジュールを更に備えている、装置が提供される。
【００３８】
斯かる装置は、本発明によれば第２のベアラ・エンドポイントに実装することが可能である。
【００３９】
本発明の装置は、１つの態様として、上記いずれか１つの方法を実行するための手段又はモジュールを更に備えている。
【００４０】
上記課題を解決することができる更にもう１つの手段として、コンピュータ上で実行する際に上記いずれか１つの方法を実行するコンピュータ・プログラムが提供される。
【発明を実施するための最良の形態】
【００４１】
以下、本発明の第１の実施形態を、図５を参照して説明する。図５は、２つ（第１及び第２）のベアラ・エンドポイントＡ及びＢを有するベアラが移転されるケースを示している。本図の移転では、エンドポイントＢ（第１のエンドポイント）は、エンドポイントＣ（第３のエンドポイント）に移転し、エンドポイントＡ（第２のエンドポイント）は、エンドポイントＤ（第４のエンドポイント）に移転することを想定する。
【００４２】
図５は、エンドポイントＡ及びＢが同時に移転すること除けば図２と同様である。また図５の例では、モビリティを処理するためにＨＩＰプロトコルが利用されている。
【００４３】
エンドポイントＣからは初期化メッセージ（initialization message）Ｉ１がエンドポイントＡへ送信され、エンドポイントＡは、接続とその通信相手を確認するためにリーチアビリティ・リクエスト（通信到達可能性リクエスト）Ｒ１を返信する。エンドポイントＣは、エンドポイントＢからエンドポイントＣへのベアラの移転に直接関与するエンドポイントであるエンドポイントＡ、Ｂ及びＣのホスト識別タグを含むリーチアビリティ・リプライ（通信到達可能性応答）Ｉ２で応答する。
【００４４】
続いて図２のケースと同様に、ノードＣへの移転を反映させるために、エンドポイントＢにおける状態情報の更新を要求するために更新リクエスト（メッセージ４、ＵＰＤ）が送信される。このメッセージは、１つ前のメッセージＩ２と同様に、エンドポイントＡ、Ｂ及びＣのホスト識別タグＨＩＴと、ベアラ識別子とを含んでいる。
【００４５】
更新リクエストメッセージに応答して、エンドポイントＢは、ＵＰＤメッセージの受信を知らせるために、更新ＡＣＫメッセージＵＰＤＡＣＫを返信する。図２に示している従来技術のケースでは、これはエンドポイントＢにおける状態情報が更新されたことを意味する。しかしながら、本実施形態では、エンドポイントＡのエンドポイントＤへの移転（transfer）を要求する更なるベアラ・エンドポイントの移転リクエストが検出されている。
【００４６】
このメッセージの検出は、図５を分かり難くしないために、図５には顕わには示されてはいない。しかしながら、上述した手続きは、ベアラ・エンドポイントＡがベアラ・エンドポイントＤに移転するベアラ・エンドポイントの移転に対称的な手順で適用されることは、当業者にすぐに理解されるはずである。これはエンドポイントＡからエンドポイントＤへの移転リクエストは、エンドポイントＤがエンドポイントＢへ初期化メッセージＩ１を送信することを意味する。次にエンドポイントＢは、（第１のエンドポイント移転に関連してエンドポイントＡがエンドポイントＣに対して行ったように）リーチアビリティ・リクエストＲ１をエンドポイントＤへ返信し、続いてエンドポイントＤは、エンドポイントＡ、Ｂ及びＤの識別子を含むリーチアビリティ・リプライＩ２をエンドポイントＢへ送信する。その結果、リクエストがエンドポイントＤによって実際に発行されているような場合には、エンドポイントＢは、エンドポイントＡからエンドポイントＤへの移転リクエストが存在していることを知る。
【００４７】
上述したように、図５は、煩雑さを軽減して分かりやすくために、実際にはベアラ・モビリティ・プロトコルのエンドポイントＢのエンドポイントＣへの移転に関連する部分だけを示しており、エンドポイントＡのエンドポイントＤへの移転に関連する対応するメッセージは、省略されていることは当業者であれば既に認識しているはずである。また一方、両方のプロセスが対称的であることは当業者であれば理解されるであろう。すなわち、図５においてエンドポイントＢをエンドポイントＡで置き換え、エンドポイントＡをエンドポイントＢで置き換え、エンドポイントＣをエンドポイントＤで置き換え、そしてエンドポイントＤをエンドポイントＣで置き換えることによって、エンドポイントＡがエンドポイントＤに移転するケースにおける対応する手続きの流れを理解することができる。
【００４８】
それゆえ、上述したように、エンドポイントＢは、エンドポイントＡからエンドポイントＤへの移転に関連する移転リクエストも存在しているという事実を知る。このせいでエンドポイントＢは（ＡからＤへの移転リクエストの存在を知らなければ）エンドポイントＢからエンドポイントＣへの移転を実際に既にいま実行していたようなやり方で状態情報（state information）をすぐには更新しない。代わりに、エンドポイントＢの論理結合（logical association）を定義する状態情報の実際の更新がまだ実行されず、エンドポイントＢにおけるローカルな状態情報は（まだ）削除されない。
【００４９】
それでもなお、更新ＡＣＫメッセージＵＰＤＡＣＫは、エンドポイントＢからエンドポイントＡへ送信される。これは例えば、更新がまだ実際に実行されていなくとも、エンドポイントＢはベアラ・エンドポイントを定義するローカルな状態情報の更新を実行する準備が完了したことを知らせることができる。
【００５０】
更新ＡＣＫメッセージＵＰＤＡＣＫと一緒に、第２のエンドポイントの移転（Ａ→Ｄ）に関連するエンドポイント、すなわち、移転先であるエンドポイントＤのインディケーション（エンドポイントＤを表す情報）が送信される。既に言及したように、エンドポイントＢは、エンドポイントＡからエンドポイントＤへのエンドポイントの移転リクエストを検出しているので、このインディケーション（indication）は、例えば、エンドポイントＢが知っているこのエンドポイントのホスト識別タグにより与えられることができる。
【００５１】
実際には、エンドポイントＢからエンドポイントＣへの移転には直接関与しないこの更なるエンドポイントＤを知らせることによって、エンドポイントＢは、エンドポイントＡに対して（エンドポイントＢが知るに至った）この更なるエンドポイントの移転リクエストが存在していることを合図する。
【００５２】
エンドポイントＡは、従来技術のメカニズム（図２参照）ではエンドポイントＢからエンドポイントＣへの移転を完了させるために、あとはエンドポイントＣに最終完了メッセージを送信するだけである。しかしながら、少なくとも第１の移転（Ｂ→Ｃ）が完全に完了し終わる前まで、（ほとんど）同時に要求されている更なる移転（Ａ→Ｄ）が関与しているため、完了メッセージは、エンドポイントＡからの移転先である（第４の）エンドポイントＤのインディケーションを余分に含んでいる。このことは、完了メッセージＲ２により、エンドポイントＡが、エンドポイントＣに対しエンドポイントＡに代わる今後の新たな通信相手について知らせることを意味する。
【００５３】
先に言及したように、エンドポイントＢにおける状態情報の実際の更新は、更なるエンドポイントの移転リクエストが原因で遅れることになる。エンドポイントＡは、メッセージＲ２をエンドポイントＣへ送信した後、エンドポイントＢへ“更なる”更新ＡＣＫメッセージＵＰＤＡＣＫＡＣＫを送信し、そのメッセージを以てエンドポイントＢは、その状態情報を更新し、移転は完了する。このことは、エンドポイントＢからエンドポイントＣへの移転が完了したこと、そしてエンドポイントＢはＵＰＤＡＣＫＡＣＫメッセージに応答してエンドポイントＢの論理結合を定義する状態情報を今度は実際に更新することを意味する。このことは、エンドポイントＢのＨＩＴをそのＩＰアドレスにマップするホスト識別タグ・マッピング（Host Identity Tag mapping）により、今度はエンドポイントＢのＨＩＴがエンドポイントＣのＩＰアドレスにマップされるように更新できることを意味する。これは、エンドポイントＢからエンドポイントＣへの移転が完了したことを意味する。
【００５４】
しかしながら、この手続きは、エンドポイントＢからエンドポイントＣへの移転を完了にしただけではなく、更にエンドポイントＡからエンドポイントＤへの“同時の”移転の効果も考慮に入れている。このため実際の更新は、エンドポイントＡが更なるＡＣＫメッセージＵＰＤＡＣＫＡＣＫを送信し終わるまで遅らされている。さらに、このＵＰＤＡＣＫＡＣＫメッセージは、エンドポイントＣも今後はエンドポイントＡに代わるべき新しいエンドポイント、すなわちエンドポイントＤと通信することになることが通知された後になってはじめて送信される。このことは、エンドポイントＢにおける第１の移転（エンドポイントＢからエンドポイントＣへの移転）の（エンドポイントＢからエンドポイントＣへの移転を可能にするための）準備と、エンドポイントＣにおける第１の移転の（エンドポイントＣとエンドポイントＤとの間の通信に備えるための）準備とが完了した後に、“最終”又は“更なる”ＡＣＫメッセージＵＰＤＡＣＫＡＣＫが送信され、そのメッセージがベアラ・エンドポイントＢのベアラ・エンドポイントＣへの移転を終了させることを意味する。
【００５５】
図５に示している上述した手続きは、エンドポイントＡからエンドポイントＤへの移転にも同じような対称的な方法で適用されることは容易に明らかであろう。しかしながら、対応するメッセージは、図５においては分かりやすくするために示されていない。それでも完全を期すため、対応するメッセージを以下に説明する。
【００５６】
エンドポイントＡからエンドポイントＤへの移転に関しては、最初にノードＤからノードＢへ初期化メッセージＩ１が送信され、ノードＢはノードＤへリーチアビリティ・リクエストＲ１を返信する。次にエンドポイントＤは、ノードＡ、Ｂ及びＣのホスト識別タグとベアラ識別子とを含んでいるリーチアビリティ・リプライＩ２をノードＢへ送信することによって応答する。リーチアビリティ・リクエスト及びリーチアビリティ・リプライは、偽装攻撃を避けるために、要求元エンドポイントのアドレス検査を実行する役割を果たす。続いて、エンドポイントＢからエンドポイントＡへ、エンドポイントＡ、Ｂ及びＤの識別子を含む更新リクエストＵＰＤが（図５に示されているものとは正反対の方向に）送信され、次に、エンドポイントＡは、新しいエンドポイントＤのインディケーション（例えば、そのホスト識別タグＨＩＴ）を更に含むＡＣＫメッセージＵＰＤＡＣＫで応答する。
【００５７】
続いてエンドポイントＢは、今度はエンドポイントＢの移転先であるエンドポイントＣのインディケーションを含む完了メッセージＲ２を、エンドポイントＤに送信する。エンドポイントＡは、メッセージＩ１、Ｒ１及びＩ２（図５に関連して既に説明しているがこれはエンドポイントＡがノードＣから受信したもの）を通じてノードＢによって実行される移転について知っている。それゆえ、ノードＡは、ノードＡからノードＢへ送られるＵＰＤＡＣＫメッセージの中にノードＣの識別子を含ませることが可能である。そしてノードＢは、この情報をノードＡへ完了メッセージＲ２と一緒に転送する。
【００５８】
ノードＤは、完了メッセージＲ２を受信し終わると、今後はエンドポイントＣと通信することになっていることが知らされ、それに応じて準備を整えることができる。続いて“更なる”ＡＣＫメッセージＵＰＤＡＣＫＡＣＫがエンドポイントＢからエンドポイントＡへ送信され、エンドポイントＡは、ノードＡからノードＤへの移転を実際に実行するためにそのローカルな状態情報を実際に更新することができる。
【００５９】
ＵＰＤＡＣＫＡＣＫメッセージが送られた後、本発明の実施の一形態によれば、更なるメッセージＯ’ＳＥＴＵＰ？が送信され得る。このメッセージは、エンドポイントＤに対してエンドポイントＣと通信したいかどうかを確認するために問い合わせるものである。このメッセージは、図５にはＯ’ＳＥＴＵＰ？で表示されている。
【００６０】
以上の説明から２つのベアラ・エンドポイントの実質的に同時の移転が上記方法によって可能になることは明らかである。このことは、従来技術におけるようなシリアル化アプローチに従うのではなく２つの移転に関連したメッセージを交互に独立に送ることが可能なアプローチに従うことに起因する。整合性問題は、その受信まで状態情報の更新が遅らされる“更なる”ＡＣＫメッセージを導入することで避けられる。さらに、“第２の移転のリクエスト”に係る新しいエンドポイントのインディケーションを、更新ＡＣＫメッセージＵＰＤＡＣＫと第１のエンドポイントの移転手続きの完了メッセージＲ２とに含ませることにより、整合性問題をもたらすことなく２つの移転プロセスを完全に対称的に実行することを可能にするようなやり方で２つの移転プロセスをミックスすることが可能となる。
【００６１】
次に、図６を参照してベアラ・エンドポイントの移転の更なる実施形態について説明する。図６は、図３と似ている。しかしながら、図６は、図５に関連して説明してきた実施形態におけるものと同様の２つのエンドポイントが同時に引き継ぐケースのシーケンス図である。
【００６２】
図６において、ノード１は図５のエンドポイントＡに対応し、ノード２は図５のエンドポイントＢに対応し、ノード３は図５のエンドポイントＣに対応し、ノード４は図５のエンドポイントＤに対応する。このことは、ノード１とノード２（図５においてエンドポイントＡとエンドポイントＢ）が最初に接続されており、ノード１の役割はノード４に引き継がれ、ノード２の役割はノード３に引き継がれることを意味する。
【００６３】
最初に、ノード４は、例えば外部からの作用によって又はユーザ入力若しくは他の入力によって、役割がノード１と置き換わるよう移転を実行するようにトリガーされる。移転を開始するため、ノード４は、初期化メッセージＩ１をノード２に送信し、ノード２は。ノード４にリーチアビリティ・リクエスト・メッセージＲ１を返信する。
【００６４】
その間、ノード３は、ノード２からノード３への移転の着手を開始するように外部から（例えば、ユーザ又は他の外部のトリガー若しくは場合によっては内部のトリガーによって）トリガーされる。結果、ノード３はノード１へ初期化メッセージＩ１を送信し、それに応答してノード１はリーチアビリティ・リクエスト・メッセージＲ１をノード３に返信する。ノード３は次に、リーチアビリティ・リプライ・メッセージＩ２をノード１へ送信するが、図６から分かるように、ノード１とノード３との間で交換されるこれら２つのメッセージＲ１及びＩ２の間において、ノード４からノード２へ送られるリーチアビリティ・リプライがインターリーブ（交互的な交換）されている。メッセージＩ１、Ｒ１、及びＩ２は、図５に関連して既に説明したような情報をそれぞれ含んでおり、例えば、図５に関連して既に説明したように、これらのメッセージは、ホスト識別情報とベアラ識別子とを含んでいる。
【００６５】
ノード２はノード４からメッセージＩ２を受信した後、ノード２は更新リクエストメッセージＵＰＤをノード１へ送信してノード４へ引き継ぐべきことを知らせる。同様に、ノード１は、ノード３からメッセージＩ２を受信した後、ノード２へ更新リクエストメッセージＵＰＤを送信してノード２にノード３へ引き継ぐべきことを知らせる。この場合も同様にこれらのメッセージの各々は、図５に関連して説明したようなベアラ識別子とホスト識別子とに関する情報を含んでいる。
【００６６】
更新リクエストメッセージＵＰＤに応答して、ノード１及びノード２は、それぞれ更新ＡＣＫメッセージＵＰＤＡＣＫを送信する。図６においてこれらのメッセージがどのようにインタリーブされているか理解することができる。
【００６７】
図５のケースと同様に、ノード１及びノード２における状態情報の実際の更新は遅らされていることに留意すべきである。というのは、これらのノードは各々、ノード１及びノード２で既に受信されているメッセージＩ１、Ｒ１及びＲ２から導き出すことができるような別の移転のリクエストが依然として存在していることを知っているからである。これらのメッセージによって、ノード１及びノード２の各ノードは、ＵＰＤリクエストメッセージを受信すると、受信したばかりのＵＰＤリクエストメッセージは実行すべき全体で２つの移転の中の第１の移転の一部に過ぎないことを知ることになる。このことは、これらの２つのノードがＵＰＤリクエストメッセージに応答して更新ＡＣＫ情報ＵＰＤＡＣＫを送信するのにもかかわらず、それらのローカルな状態情報の実際の更新を遅らせる原因となっている。
【００６８】
ノード１は、ノード２からＵＰＤメッセージを受信した後、返信として更新ＡＣＫメッセージをノード２に送信する。このメッセージはいま受信したばかりのＵＰＤリクエストメッセージに関連した第１の移転（ノード１からノード４への移転）とは異なる第２の移転（ノード２からノード３への移転）の移転先エンドポイントのインディケーションを含んでいる。つまりノード１からノード２へ送信されるＵＰＤメッセージには、ノード３のインディケーションが含まれている。続いて、ノード２がＵＰＤＡＣＫメッセージで受信したばかりのノード３のインディケーションを含む完了メッセージＲ２が、ノード２からノード４へ送信される。これにより、ノード１から役割を引き継ぐ予定のノード４は、その通信相手が今後はノード２の代わりにノード３になることに対し準備することができる。
【００６９】
同様に、ノード２からノード１へ送られるＵＰＤＡＣＫメッセージには、“第１の移転”（ノード１からノード４への移転）の移転先のインディケーションが含まれている。これは、ノード４のインディケーションがこのメッセージに含まれていることを意味する。ノード１は、ノード４のインディケーションを含む完了メッセージＲ２をノード３へ送る。これにより、ノード２から役割を引き継ぐノード３は、その通信相手が今後はノード１の役割を引き継ぐノード４になるという事実に対し準備することが可能となる。
【００７０】
完了メッセージＲ２が、ノード１からノード３へ、ノード２からノード４へ送られた後、実際の移転の準備が完了する。ノード２に完了を通知するため、ノード１は“更なる”ＡＣＫメッセージＵＰＤＡＣＫＡＣＫを送信する。このメッセージは、ノード２においてローカルな状態情報の実際の更新を更に遅らせる必要がないことをノード２に知らせるものである。同様に、ノード２は、ノード１においてローカルな状態情報の実際の更新を更に遅らせる必要がないことをノード１に知らせるＵＰＤＡＣＫＡＣＫメッセージを送信する。こうして、ノード１及びノード２は、更なるＡＣＫメッセージＵＰＤＡＣＫＡＣＫを受信した後、それぞれのローカルな状態情報を更新し、以前の状態情報は削除される。これを以て移転は実際に完了する。
【００７１】
図６から、２つの移転（ノード１からノード４への移転とノード２からノード３への移転）に関連したメッセージは、交互に送信されることが可能なことが容易に分かる。このことは、無理矢理なシリアル化に起因すると考えられる、どのような遅延も避けることができることを意味する。
【００７２】
状態情報が上述した実施形態の中で言及される限りでは、この状態情報は、ＨＩＰプロトコルに基づくホスト識別タグの端末ＩＰアドレスへのマッピングによって提供することができる。しかしながら、当業者であれば、エンドポイントのその通信相手との関連付けを識別する任意の他の状態情報を使用することが可能なことはすぐに理解されよう。ホスト識別タグの代わりに、エンドポイントの論理結合によってセッション又はフローを定義する他の状態情報が使用され得る。したがって当業者であれば、これまで使用してきた又は特許請求の範囲の請求項の中で使用されている“ベアラ・モビリティ（bearer mobility）”を実現する手続きは、同様にして“フロー・モビリティ（flow mobility）”又は“セッション・モビリティ（session mobility）”を実現するために適用することができるだけでなく、２つのエンドポイントが同時に又は少なくとも完全に順次的にではなく移転するような場合におけるダブルジャンプ（double jump）の問題の解決法を実現するために適用することができることは理解されよう。
【００７３】
上述した実施形態は、ハードウェア、ソフトウェア、又はソフトウェアとハードウェアとの組み合わせによって実施することができることは当業者には理解できるであろう。本発明の実施形態に関連して記述したモジュールの全体又は一部は、本発明の実施形態に関連して説明された方法に従って動作するようにプログラムされたマイクロプロセッサ又はコンピュータによって実施することが可能である。
【図面の簡単な説明】
【００７４】
【図１】単一のベアラ・エンドポイントのみが移転する場合のベアラ・モビリティを示している図である。
【図２】単一のベアラ・エンドポイントのみが移転する場合のベアラ・モビリティの手続きを詳細に示している概略図である。
【図３】単一のベアラ・エンドポイントのみが移転する場合のベアラ・モビリティの手続きをより詳細に示しめしているシーケンス図である。
【図４】２つのベアラ・エンドポイントが同時に移転する場合の状況を示している図である。
【図５】本発明の実施の一形態によるベアラ・モビリティの手続きを示している概略図である。
【図６】本発明の実施の一形態によるベアラ・モビリティの手続きをより詳細に示しているシーケンス図である。
【符号の説明】
【００７５】
Ａ，Ｂ，Ｃ，Ｄ  ベアラ・エンドポイント
Ｉ１  初期化メッセージ
Ｉ２  リーチアビリティ・リプライ
Ｒ１  リーチアビリティ・リクエスト
Ｒ２  完了メッセージ
ＵＰＤ  更新リクエストメッセージ
ＵＰＤＡＣＫ  更新ＡＣＫメッセージ
ＵＰＤＡＣＫＡＣＫ  更なる更新ＡＣＫメッセージ
【図１】
2007208983.tif 000003
【図２】
2007208983.tif 000004
【図３】
2007208983.tif 000005
【図４】
2007208983.tif 000006
【図５】
2007208983.tif 000007
【図６】
2007208983.tif 000008
【外国語明細書】
2007208983.tif 000009
2007208983.tif 000010
2007208983.tif 000011
2007208983.tif 000012
2007208983.tif 000013
2007208983.tif 000014
2007208983.tif 000015
2007208983.tif 000016
2007208983.tif 000017
2007208983.tif 000018
2007208983.tif 000019
2007208983.tif 000020
2007208983.tif 000021
2007208983.tif 000022
2007208983.tif 000023
2007208983.tif 000024
2007208983.tif 000025
2007208983.tif 000026
2007208983.tif 000027
2007208983.tif 000028
2007208983.tif 000029
2007208983.tif 000030
2007208983.tif 000031
2007208983.tif 000032
2007208983.tif 000033
2007208983.tif 000034
2007208983.tif 000035
2007208983.tif 000036
2007208983.tif 000037
2007208983.tif 000038
2007208983.tif 000039
2007208983.tif 000040
2007208983.tif 000041
2007208983.tif 000042
2007208983.tif 000043