[go: up one dir, main page]

JP4296201B2 - ベアラ・モビリティを実現するための方法及び装置 - Google Patents

ベアラ・モビリティを実現するための方法及び装置 Download PDF

Info

Publication number
JP4296201B2
JP4296201B2 JP2007020539A JP2007020539A JP4296201B2 JP 4296201 B2 JP4296201 B2 JP 4296201B2 JP 2007020539 A JP2007020539 A JP 2007020539A JP 2007020539 A JP2007020539 A JP 2007020539A JP 4296201 B2 JP4296201 B2 JP 4296201B2
Authority
JP
Japan
Prior art keywords
bearer
endpoint
bearer endpoint
update
state information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2007020539A
Other languages
English (en)
Other versions
JP2007208983A (ja
Inventor
アルフ・ツーゲンマイヤー
ジュリアン・ラガニエ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NTT Docomo Inc
Original Assignee
NTT Docomo Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by NTT Docomo Inc filed Critical NTT Docomo Inc
Publication of JP2007208983A publication Critical patent/JP2007208983A/ja
Application granted granted Critical
Publication of JP4296201B2 publication Critical patent/JP4296201B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W8/00Network data management
    • H04W8/02Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W8/00Network data management
    • H04W8/26Network addressing or numbering for mobility support
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W80/00Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/04Network layer protocols, e.g. mobile IP [Internet Protocol]

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)

Description

本発明は、ベアラ・モビリティ、特に2つのベアラ・エンドポイントを同時に移転させる技術に関する。
ベアラ・モビリティ(bearer mobility)という用語は、異なる物理的装置に存在し得る1つのアプリケーション・エンドポイントから別のアプリケーション・エンドポイントへのデータフローの移転(move)を意味する。それは例えば、PDA上で動画の始まりを視聴し、コンピュータ上でその終わりを視聴することを意味する。
最初に、本明細書で使用されるいくつかの用語について説明する。
・エンドポイント(Endpoint):通信サービスの終端となる論理オブジェクト(logical object)。異なるエンドポイントが異なるレイヤ(例えば、アプリケーションレイヤ、TCPレイヤ、IPレイヤなど)に存在する。
・ホスト/端末:ネットワーク上で通信する物理的装置。
・ベアラ(Bearer):通信し合うアプリケーション(例えば、メディア・ストリーミング)エンドポイントの間の論理結合(Logical association)。
・フロー(Flow):通信し合うネットワークレイヤ(例えばTCP、HIP)エンドポイント同士の間の論理結合。
・セッション:ベアラにより通信し合うアプリケーション(複数)によって共有される状態。
・端末間のエンドポイント・モビリティ:1つの端末から別の端末へのエンドポイントのモビリティ、及び、その結果としての、エンドポイントに結びついたベアラ又はフローのモビリティ。これは、通信のエンドポイントが、アプリケーションが認識することにおいては、通信チャネル及びプロトコルの状態に影響を及ぼすことなく、1つの端末(例えば、ある携帯電話機)から別の端末(例えば、コンピュータ)へ移転するシナリオである。
図1は、“古い”デバイスと“固定された”送り先デバイスとの間の接続を表すベアラが“新しい”デバイスに移転する場合にベアラ・モビリティがどのように働くかを示している。
新しいデバイスから固定されたデバイスへ初期化メッセージが送られた後、固定されたデバイスは、新しいデバイスへリーチアビリティ・リクエスト(reachability request:通信到達可能性リクエスト)を発信し、次に新しいデバイスからリーチアビリティ・リプライ(reachability reply:通信到達可能性応答)が返信される。これらのリーチアビリティ・リクエスト及びリーチアビリティ・リプライ・メッセージは、偽装(なりすまし)攻撃を避けるためにアドレス検査を実行し、更に、リクエストをしているデバイスの主張したアドレスを確認する役割を果たす。
次に、“固定された”デバイスは、古いエンドポイントに合意確認リクエスト(agreement verification request)を送信する。これは、ベアラ・エンドポイントを定義する状態情報(例えば、ホスト識別プロトコル(HIP:Host Identity Protocol)で使用されるホスト識別タグ)の更新をトリガーする。続いて、古いエンドポイントは、固定されたエンドポイントへ合意リプライ(agreement reply)を返信し、次に、固定されたエンドポイントは新しいエンドポイントに対し、移転が今成立し、新しいエンドポイントがベアラを引き継ぐことが可能であることを通知する。
次に図2を参照して、ベアラ・モビリティ・プロトコルについて詳しく説明する。本例では、エンドポイントBは、エンドポイントAが固定されている状態にある間に、新しいエンドポイントCに移転されなくてはならない。本例は、ホスト識別プロトコル(HIP)を利用する。
このメカニズムは、HIPのような交換に基づいており、エンドポイントが移転する前にベアラ・エンドポイントのオーナー同士の間にHIP接続(HIP association)が存在することを仮定する。HIP(ホスト識別プロトコル)は、IPスタックのネットワークレイアとトランスポートレイヤとの間に挿入されるプロトコルである。このHIPプロトコルは一般的に、個々のデバイスの公開鍵のハッシュ値であるHI(Host Identity)の新しい名前空間(name space)を導入することによって、接続(コネクション)のエンドポイントをIPアドレスから切り離す。これらはその後、IPアドレスにマップ(map)される。TCP/IPとのソケットインタフェースでは、ソケットは一般的にはIPアドレス及びポート番号にバインド(結び付け)されている。HIPが使用されるときには、ソケットは、HI(あるいはホスト識別タグ、HIのハッシュ値)及びポート番号にバインドされている。データパケットがある1つのソケットから別のソケットに送られるとき、送信元と送信先のHIは、IPパケットの対応するフィールドに入れるために使用される適切なロケータ(locator)IPアドレスにマップされ、IPネットワークにおけるパケットのルーティングが可能となる。
HIPプロトコルでは、エンドポイントのオーナーは、暗号識別子(すなわち、公開鍵と秘密鍵のペア)で識別される。暗号識別子を利用することで、デジタル署名によるメッセージの認証が可能となり、偽装攻撃から防御することができる。
次に、図2を参照して本プロトコルを説明する。第1のメッセージI1は初期化メッセージであり、第2のメッセージはリーチアビリティ・リクエストR1である。この後に、リーチアビリティ・リプライに相当する第3のメッセージが続く。この第3のメッセージは、ベアラ識別子(Bid)と、エンドポイントB及びCのHIT(ホスト識別タグ)とを含んでいる。これは、更新プロセスを実際にトリガーするメッセージである。メッセージ3に応答して、固定されたエンドポイントから、移転すべき古いエンドポイントへ、更新リクエスト・メッセージ(メッセージ4)が送信される。このメッセージは、ベアラの移転先である新しいエンドポイントCのホスト識別子HITを含んでいる。
更新リクエストに応答して、エンドポイントBにおけるホスト識別子のマッピングが新しいエンドポイントCを反映するよう更新され、次に更新ACK(acknowledgement=確認応答)メッセージが送信される。この更新ACKメッセージ(update acknowledgement message)に応答して、古いベアラ・エンドポイント及び新しいベアラ・エンドポイントの識別子を含む移転(transfer)を終了するための最終メッセージR2が送信される。これにより移転が完了し、新しいエンドポイントCが接続を継続することができる。
図3は、本プロトコルを詳しく説明するためのシーケンス図である。ノード3はここでは図2に示されている新しいノードCを表しており、ノード2は図2のノードBに対応し、ノード1は図2のノードAに対応している。
全体のプロセスは、外部のトリガー・メッセージによって開始される。まずノード3が、初期化メッセージI1を送信する。次に、ノード1がリーチアビリティ・リクエストR1を返信する。続いて、リーチアビリティ・リプライI2が、図3において、ノード1からノード2へのUPDと、ノード2からノード1へのUPDACKメッセージとで示されている更新処理をトリガーする。
最後に、移転を完了するための最終完了メッセージがノード1からノード3へ送信される。
しかしながら、本プロトコルでは2つのベアラ・エンドポイントが同時に移転したい場合に問題が生じる。このケースを図4に示す。本図において、ベアラ・エンドポイントBは、ベアラ・エンドポイントCへの移転を望んでおり、且つ、ベアラ・エンドポイントAは、ベアラ・エンドポイントDへの移転を望んでいる。このようなケースでは、整合性(consistency)の問題が起こる可能性がある。
1つの解決策としては、全体の手続きをシリアル化することが考えられる。いわゆるSIP(session invitation protocol)は、このアプローチに沿ったものである。SIPの場合、両方のエンドポイントがRE−INVITEメッセージを同時に受信したら、それらは両方ともリクエスト保留メッセージ(request pending message)を送信する。次にそれらのどちらか一方は、RE−INVITEを0秒から2秒までのランダムな秒数だけ遅らせる。しかしこのアプローチは、避けるべき望ましくない遅延を含むことは明らかである。
そこで本発明の課題は、両方のエンドポイントが同時に移転する場合においても従来技術の上記欠点を伴うことなくベアラ・モビリティを実現するために適用することができる方法を提供することにある。
上記課題を解決することができる1つの手段として、ベアラ・エンドポイントは通信サービスの終端となる論理オブジェクトであり、ベアラはベアラ・エンドポイント間の論理結合(logical association)であり、前記ベアラと前記ベアラ・エンドポイントとの間の論理結合は状態情報(state information)の中に定義され、前記ベアラが第1のベアラ・エンドポイントと第2のベアラ・エンドポイントとを備えるとき、第1のベアラ・エンドポイントを第3のベアラ・エンドポイントへ引き継ぐための方法であって、第1のベアラ・エンドポイントの移転を開始するためのリクエストを前記第3のベアラ・エンドポイントから前記第2のベアラ・エンドポイントへ送信することによって前記第1のベアラ・エンドポイントの移転を開始するステップと、前記第1のベアラ・エンドポイントに関する論理結合を定義する状態情報の更新を要求するために、状態情報の更新をリクエストするメッセージを前記第2のベアラ・エンドポイントから前記第1のベアラ・エンドポイントへ送信するステップと、これらベアラ・エンドポイントの移転を反映させるため、前記第2のベアラ・エンドポイントから前記第1のベアラ・エンドポイントへ送信された前記状態情報の更新をリクエストするメッセージに応答して、前記第1のベアラ・エンドポイントに関する論理結合を定義する前記状態情報の更新を実行するステップと、前記第1のベアラ・エンドポイントに関する論理結合を定義する前記状態情報の更新のリクエストに確認応答するために、前記第1のベアラ・エンドポイントから前記第2のベアラ・エンドポイントへ更新ACK(確認応答)メッセージを送信するステップとを含んでおり、当該方法は更に、前記第2のベアラ・エンドポイントを第4のベアラ・エンドポイントへ移転することに関連する第2のベアラ・エンドポイントの移転を開始するためのリクエストが、前記状態情報の更新が実行される前に前記第1のベアラ・エンドポイントによって検出された場合において、前記第4のベアラ・エンドポイントのインディケーション(indication:第4のベアラ・エンドポイントを表す情報)を含むメッセージを前記第3のベアラ・エンドポイントへ送信し、前記第4のベアラ・エンドポイントを表す情報が前記第3のベアラ・エンドポイントに伝達されたことを知らせる更なる更新ACKメッセージが、前記第2のベアラ・エンドポイントから送信されて前記第1のベアラ・エンドポイントによって受信されるまでは、前記第1のベアラ・エンドポイントに関する論理結合を定義する前記状態情報の更新を遅らせるステップを更に含んでいる方法が提供される。
第2のベアラ・エンドポイントの移転を開始するためのリクエストは、それと共に第2のベアラ・エンドポイントの移転の移転先に関する情報を、第1のベアラ・エンドポイントの移転の移転先に送信し、且つ、更なる更新ACKメッセージが受信されるまで状態情報の実際の更新が遅らされることにより、従来技術におけるようなシリアル化アプローチに伴う欠点を避けるための、いわゆるダブルジャンプ(double-jump)問題に対する解決策を提供することができる。
本方法の1つの態様として、第1及び第2のベアラ・エンドポイントを定義する前記状態情報は、エンドポイントの論理名(logical name)とロケータ(locator)との間のマッピングを含んでおり、前記エンドポイントに対する論理名は、ホスト識別プロトコル(HIP)で使用されるホスト識別タグであり、前記ロケータはIPアドレスである。
ホスト識別タグとIPアドレスとの間のマッピングを利用することで、いくつかの有利なセキュリティ機能を提供し、これにより、偽装(なりすまし)攻撃又はサービス妨害を困難にするようなHIPプロトコルを利用することが可能となる。
本方法の1つの態様として、第1のベアラ・エンドポイントによって送信される前記更新ACK(確認応答)メッセージは、第4のベアラ・エンドポイントのインディケーションを含んでいる。これにより、第4のベアラ・エンドポイントのインディケーションを転送するための既存のプロトコルにおいて既存のメッセージを利用することが可能となる。
本方法は、1つの態様として、第2のベアラ・エンドポイントから第1のベアラ・エンドポイントへ前記更なる更新ACKメッセージを送信する前に、第2のベアラ・エンドポイントから第3のベアラ・エンドポイントへ更新リクエスト完了メッセージ(update request completion message)を送信することを更に含む。
本方法の1つの態様として、前記更新リクエスト完了メッセージは、第4のベアラ・エンドポイントのインディケーションを含むものである。
第4のベアラ・エンドポイントのインディケーションを転送するのに更新完了メッセージを利用することで、第4のベアラ・エンドポイントのインディケーションを転送するための既存のプロトコルにおいて既存のメッセージを利用することが可能となる。
本方法は、1つの態様として、前記第3のベアラ・エンドポイントから前記第2のベアラ・エンドポイントへ前記第1のベアラ・エンドポイントの移転を開始するためのリクエストを送信した後に、前記第2のベアラ・エンドポイントから前記第3のベアラ・エンドポイントへリーチアビリティ・リプライ・リクエスト・メッセージ(reachability reply request message)を送信し、前記第3のベアラ・エンドポイントから前記第2のベアラ・エンドポイントへリーチアビリティ・リプライ・メッセージ(reachability reply message)を送信するステップを更に含んでいる。
本方法は、1つの態様として、前記第1のベアラ・エンドポイントが前記第4のベアラ・エンドポイントから前記第1のベアラ・エンドポイントへ送信された前記第2のベアラ・エンドポイントの移転を開始するためのリクエスト・メッセージ又はリーチアビリティ・リプライ・メッセージを受信することによって、前記第2のベアラ・エンドポイントの移転を開始するためのリクエストを検出するステップを更に含んでいる。
本方法は、1つの態様として、前記第1のベアラ・エンドポイントによって受信された前記第2のベアラ・エンドポイントの移転を開始するためのリクエストに応答して、前記第1のベアラ・エンドポイントから前記第2のベアラ・エンドポイントへ前記状態情報の更新をリクエストするメッセージを送信するステップと、前記第2のベアラ・エンドポイントから前記第1のベアラ・エンドポイントへ前記更新ACKメッセージを送信するステップと、前記第3のベアラ・エンドポイントのインディケーションを含むメッセージを前記第4のベアラ・エンドポイントへ送信するステップと、前記第2のベアラ・エンドポイントに関する論理結合を定義する前記状態情報の更新を実行するステップとを含んでおり、前記第2のベアラ・エンドポイントに関する論理結合を定義する前記状態情報の更新は、前記第3のベアラ・エンドポイントを表す情報が前記第4のベアラ・エンドポイントに伝達されたことを知らせる前記更なる更新ACKメッセージが、前記第1のベアラ・エンドポイントから送信されて前記第2のベアラ・エンドポイントによって受信されるまで遅らされる。
これにより全体の手続きが対称的になり、更に、異なるベアラ・エンドポイントリクエストに属するメッセージを交互に送信することが可能となる。
本方法の1つの態様として、前記第2のベアラ・エンドポイントによって送信される前記更新ACKメッセージは、前記第3のベアラ・エンドポイントのインディケーションを含むものである。
本方法は、1つの態様として、前記更なる更新ACKメッセージを前記第1のベアラ・エンドポイントから前記第2のベアラ・エンドポイントへ送信する前に、更新リクエスト完了メッセージを前記第1のベアラ・エンドポイントから前記第4のベアラ・エンドポイントへ送信するステップを更に含んでいる。
本方法の1つの態様として、前記更新リクエスト完了メッセージは、前記第3のベアラ・エンドポイントのインディケーションを含むものである。
本方法の1つの態様として、前記第1のベアラ・エンドポイントが前記第3のベアラ・エンドポイントへ引き継がれるような第1のベアラ・エンドポイントの移転に関連するメッセージと、前記第2のベアラ・エンドポイントが第4のベアラ・エンドポイントへ引き継がれるような前記第2のベアラ・エンドポイントの移転に関係するメッセージとは、交互に送信される。
上記課題を解決することができる別の手段として、ベアラ・エンドポイントは通信サービスの終端となる論理オブジェクトであり、ベアラはベアラ・エンドポイント間の論理結合(論理的関連性)であり、前記ベアラと前記ベアラ・エンドポイントとの間の論理結合は状態情報の中に定義され、前記ベアラが第1のベアラ・エンドポイントと第2のベアラ・エンドポイントとを備えるとき、前記第1のベアラ・エンドポイントを第3のベアラ・エンドポイントへ引き継ぐための装置であって、第1のベアラ・エンドポイントの移転を開始するためのリクエストを前記第3のベアラ・エンドポイントから前記第2のベアラ・エンドポイントへ送信することによって、第1のベアラ・エンドポイント移転を開始するためのモジュール(module)と、前記第1のベアラ・エンドポイントに関する論理結合を定義する状態情報の更新を要求するために、状態情報の更新をリクエストするメッセージを前記第2のベアラ・エンドポイントから前記第1のベアラ・エンドポイントへ送信するためのモジュールと、これらベアラ・エンドポイントの移転を反映させるため、前記第2のベアラ・エンドポイントから前記第1のベアラ・エンドポイントへ送信された前記状態情報の更新をリクエストするメッセージに応答して、前記第1のベアラ・エンドポイントに関する論理結合を定義する前記状態情報の更新を実行するためのモジュールと、前記第1のベアラ・エンドポイントに関する論理結合を定義する前記状態情報の更新のリクエストに確認応答するために、前記第1のベアラ・エンドポイントから前記第2のベアラ・エンドポイントへ更新ACKメッセージを送信するためのモジュールとを備えており、当該装置はこれらのモジュールに加えて、前記状態情報の更新が実行される前に、前記第1のベアラ・エンドポイントによって、前記第2のベアラ・エンドポイントを前記第4のベアラ・エンドポイントへ移転することに関する第2のベアラ・エンドポイントの移転を開始するためのリクエストの有無を検出し、該リクエストが検出された場合において、前記第4のベアラ・エンドポイントのインディケーションを含むメッセージを前記第3のベアラ・エンドポイントへ送信し、前記第4のベアラ・エンドポイントをインディケーションする情報が前記第3のベアラ・エンドポイントに伝達されたことを知らせる更なる更新ACKメッセージが、前記第2のベアラ・エンドポイントから前記第1のベアラ・エンドポイントによって受信されるまで、前記第1のベアラ・エンドポイントに関する論理結合を定義する前記状態情報の更新を遅らせるように構成されているモジュールを更に備えている、装置が提供される。
上記課題を解決することができる更にもう1つの手段として、ベアラ・エンドポイントは通信サービスの終端となる論理オブジェクトであり、ベアラはベアラ・エンドポイント間の論理結合(論理的関連性)であり、前記ベアラと前記ベアラ・エンドポイントとの間の論理結合は状態情報の中に定義され、前記ベアラが第1のベアラ・エンドポイントと第2のベアラ・エンドポイントとを備えるとき、前記第1のベアラ・エンドポイントを第3のベアラ・エンドポイントへ引き継ぐための装置であって、ここで、前記第1のベアラ・エンドポイントと前記第2のベアラ・エンドポイントとを備える前記ベアラのベアラ・エンドポイントが、前記第1のベアラ・エンドポイントが第3のベアラ・エンドポイントによって置き換えられるように移転され、この移転の完了には、前記ベアラと前記ベアラ・エンドポイントとの間の論理結合を定義する状態情報の更新が含まれ、これにより、ネットワークにおけるベアラ・モビリティを実現するような装置であり、前記第3のベアラ・エンドポイントから前記第2のベアラ・エンドポイントへ第1のベアラ・エンドポイントの移転を開始するためのリクエストを送信することによって前記第1のベアラ・エンドポイントの移転が開始された後に、前記第1のベアラ・エンドポイントに関する論理結合を定義する状態情報の更新を要求するために前記第2のベアラ・エンドポイントから送信されるような状態情報の更新をリクエストするメッセージを、前記第1のベアラ・エンドポイントによって受信するためのモジュールと、これらのベアラ・エンドポイントの移転を反映させるために、前記第2のベアラ・エンドポイントから前記第1のベアラ・エンドポイントへの前記状態情報の更新をリクエストするメッセージに応答して、前記第1のベアラ・エンドポイントに関する論理結合を定義する前記状態情報の更新を実行するモジュールと、前記第1のベアラ・エンドポイントに関する論理結合を定義する前記状態情報の更新のリクエストに確認応答するために、前記第1のベアラ・エンドポイントから前記第2のベアラ・エンドポイントへ更新ACKメッセージを送信するためのモジュールとを備えており、当該装置はこれらのモジュールに加えて、前記状態情報の更新が実行される前に、前記第1のベアラ・エンドポイントによって、前記第2のベアラ・エンドポイントを前記第4のベアラ・エンドポイントへ移転することに関連する第2のベアラ・エンドポイントの移転を開始するためのリクエストの有無を検出し、該リクエストが検出された場合において、前記第4のベアラ・エンドポイントを表す情報が第3のベアラ・エンドポイントに伝達されたことを知らせる更なる更新ACKメッセージが、前記第2のベアラ・エンドポイントから送信されて前記第1のベアラ・エンドポイントによって受信されるまで、前記第1のベアラ・エンドポイントに関する論理結合を定義する前記状態情報の更新を遅らせるように構成されているモジュールを更に備えている、装置が提供される。
斯かる装置は本発明によれば、第1のベアラ・エンドポイントに実装することが可能である。
上記課題を解決することができる更にもう1つの手段として、ベアラ・エンドポイントは通信サービスの終端となる論理オブジェクトであり、ベアラはベアラ・エンドポイント間の論理結合(論理的関連性)であり、前記ベアラと前記ベアラ・エンドポイントとの間の論理結合は状態情報の中に定義され、前記ベアラが第1のベアラ・エンドポイントと第2のベアラ・エンドポイントとを備えるとき、前記第1のベアラ・エンドポイントを第3のベアラ・エンドポイントへ引き継ぐための装置であって、第1のベアラ・エンドポイントの移転を開始するためのリクエストを前記第3のベアラ・エンドポイントから前記第2のベアラ・エンドポイントへ送信することによって前記第1のベアラ・エンドポイントの移転が開始された後に、前記第2のベアラ・エンドポイントから前記第1のベアラ・エンドポイントへ、状態情報の更新をリクエストするメッセージを送信して、移転を反映させるために前記第2のベアラ・エンドポイントから前記第1のベアラ・エンドポイントへ送信された前記状態情報の更新をリクエストするメッセージに応答して前記第1のベアラ・エンドポイントに関する論理結合を定義する状態情報の更新の実行を要求するためのモジュールと、前記第1のベアラ・エンドポイントに関する論理結合を定義する状態情報の更新のリクエストに確認応答するために、前記第1のベアラ・エンドポイントから前記第2のベアラ・エンドポイントへ送信された更新ACKメッセージを受信するためのモジュールとを備えており、当該装置はこれらのモジュールに加えて、前記状態情報の更新が実行される前に、前記第1のベアラ・エンドポイントによって、前記第2のベアラ・エンドポイントを第4のベアラ・エンドポイントへ移転することに関する第2のベアラ・エンドポイントの移転を開始するためのリクエストの有無を検出し、該リクエストが検出された場合において、前記第4のベアラ・エンドポイントのインディケーションを含むメッセージを前記第3のベアラ・エンドポイントへ送信し、前記第4のベアラ・エンドポイントを表す情報が前記第3のベアラ・エンドポイントに伝達されたことを知らせる更なる更新ACKメッセージを前記第2のベアラ・エンドポイントから前記第1のベアラ・エンドポイントへ送信し、前記第1のベアラ・エンドポイントが前記第2のベアラ・エンドポイントから前記更なる更新ACKメッセージを受信するまで、前記第1のベアラ・エンドポイントに関する論理結合を定義する前記状態情報の更新が遅らされるように構成されているモジュールを更に備えている、装置が提供される。
斯かる装置は、本発明によれば第2のベアラ・エンドポイントに実装することが可能である。
本発明の装置は、1つの態様として、上記いずれか1つの方法を実行するための手段又はモジュールを更に備えている。
上記課題を解決することができる更にもう1つの手段として、コンピュータ上で実行する際に上記いずれか1つの方法を実行するコンピュータ・プログラムが提供される。
以下、本発明の第1の実施形態を、図5を参照して説明する。図5は、2つ(第1及び第2)のベアラ・エンドポイントA及びBを有するベアラが移転されるケースを示している。本図の移転では、エンドポイントB(第1のエンドポイント)は、エンドポイントC(第3のエンドポイント)に移転し、エンドポイントA(第2のエンドポイント)は、エンドポイントD(第4のエンドポイント)に移転することを想定する。
図5は、エンドポイントA及びBが同時に移転すること除けば図2と同様である。また図5の例では、モビリティを処理するためにHIPプロトコルが利用されている。
エンドポイントCからは初期化メッセージ(initialization message)I1がエンドポイントAへ送信され、エンドポイントAは、接続とその通信相手を確認するためにリーチアビリティ・リクエスト(通信到達可能性リクエスト)R1を返信する。エンドポイントCは、エンドポイントBからエンドポイントCへのベアラの移転に直接関与するエンドポイントであるエンドポイントA、B及びCのホスト識別タグを含むリーチアビリティ・リプライ(通信到達可能性応答)I2で応答する。
続いて図2のケースと同様に、ノードCへの移転を反映させるために、エンドポイントBにおける状態情報の更新を要求するために更新リクエスト(メッセージ4、UPD)が送信される。このメッセージは、1つ前のメッセージI2と同様に、エンドポイントA、B及びCのホスト識別タグHITと、ベアラ識別子とを含んでいる。
更新リクエストメッセージに応答して、エンドポイントBは、UPDメッセージの受信を知らせるために、更新ACKメッセージUPDACKを返信する。図2に示している従来技術のケースでは、これはエンドポイントBにおける状態情報が更新されたことを意味する。しかしながら、本実施形態では、エンドポイントAのエンドポイントDへの移転(transfer)を要求する更なるベアラ・エンドポイントの移転リクエストが検出されている。
このメッセージの検出は、図5を分かり難くしないために、図5には顕わには示されてはいない。しかしながら、上述した手続きは、ベアラ・エンドポイントAがベアラ・エンドポイントDに移転するベアラ・エンドポイントの移転に対称的な手順で適用されることは、当業者にすぐに理解されるはずである。これはエンドポイントAからエンドポイントDへの移転リクエストは、エンドポイントDがエンドポイントBへ初期化メッセージI1を送信することを意味する。次にエンドポイントBは、(第1のエンドポイント移転に関連してエンドポイントAがエンドポイントCに対して行ったように)リーチアビリティ・リクエストR1をエンドポイントDへ返信し、続いてエンドポイントDは、エンドポイントA、B及びDの識別子を含むリーチアビリティ・リプライI2をエンドポイントBへ送信する。その結果、リクエストがエンドポイントDによって実際に発行されているような場合には、エンドポイントBは、エンドポイントAからエンドポイントDへの移転リクエストが存在していることを知る。
上述したように、図5は、煩雑さを軽減して分かりやすくために、実際にはベアラ・モビリティ・プロトコルのエンドポイントBのエンドポイントCへの移転に関連する部分だけを示しており、エンドポイントAのエンドポイントDへの移転に関連する対応するメッセージは、省略されていることは当業者であれば既に認識しているはずである。また一方、両方のプロセスが対称的であることは当業者であれば理解されるであろう。すなわち、図5においてエンドポイントBをエンドポイントAで置き換え、エンドポイントAをエンドポイントBで置き換え、エンドポイントCをエンドポイントDで置き換え、そしてエンドポイントDをエンドポイントCで置き換えることによって、エンドポイントAがエンドポイントDに移転するケースにおける対応する手続きの流れを理解することができる。
それゆえ、上述したように、エンドポイントBは、エンドポイントAからエンドポイントDへの移転に関連する移転リクエストも存在しているという事実を知る。このせいでエンドポイントBは(AからDへの移転リクエストの存在を知らなければ)エンドポイントBからエンドポイントCへの移転を実際に既にいま実行していたようなやり方で状態情報(state information)をすぐには更新しない。代わりに、エンドポイントBの論理結合(logical association)を定義する状態情報の実際の更新がまだ実行されず、エンドポイントBにおけるローカルな状態情報は(まだ)削除されない。
それでもなお、更新ACKメッセージUPDACKは、エンドポイントBからエンドポイントAへ送信される。これは例えば、更新がまだ実際に実行されていなくとも、エンドポイントBはベアラ・エンドポイントを定義するローカルな状態情報の更新を実行する準備が完了したことを知らせることができる。
更新ACKメッセージUPDACKと一緒に、第2のエンドポイントの移転(A→D)に関連するエンドポイント、すなわち、移転先であるエンドポイントDのインディケーション(エンドポイントDを表す情報)が送信される。既に言及したように、エンドポイントBは、エンドポイントAからエンドポイントDへのエンドポイントの移転リクエストを検出しているので、このインディケーション(indication)は、例えば、エンドポイントBが知っているこのエンドポイントのホスト識別タグにより与えられることができる。
実際には、エンドポイントBからエンドポイントCへの移転には直接関与しないこの更なるエンドポイントDを知らせることによって、エンドポイントBは、エンドポイントAに対して(エンドポイントBが知るに至った)この更なるエンドポイントの移転リクエストが存在していることを合図する。
エンドポイントAは、従来技術のメカニズム(図2参照)ではエンドポイントBからエンドポイントCへの移転を完了させるために、あとはエンドポイントCに最終完了メッセージを送信するだけである。しかしながら、少なくとも第1の移転(B→C)が完全に完了し終わる前まで、(ほとんど)同時に要求されている更なる移転(A→D)が関与しているため、完了メッセージは、エンドポイントAからの移転先である(第4の)エンドポイントDのインディケーションを余分に含んでいる。このことは、完了メッセージR2により、エンドポイントAが、エンドポイントCに対しエンドポイントAに代わる今後の新たな通信相手について知らせることを意味する。
先に言及したように、エンドポイントBにおける状態情報の実際の更新は、更なるエンドポイントの移転リクエストが原因で遅れることになる。エンドポイントAは、メッセージR2をエンドポイントCへ送信した後、エンドポイントBへ“更なる”更新ACKメッセージUPDACKACKを送信し、そのメッセージを以てエンドポイントBは、その状態情報を更新し、移転は完了する。このことは、エンドポイントBからエンドポイントCへの移転が完了したこと、そしてエンドポイントBはUPDACKACKメッセージに応答してエンドポイントBの論理結合を定義する状態情報を今度は実際に更新することを意味する。このことは、エンドポイントBのHITをそのIPアドレスにマップするホスト識別タグ・マッピング(Host Identity Tag mapping)により、今度はエンドポイントBのHITがエンドポイントCのIPアドレスにマップされるように更新できることを意味する。これは、エンドポイントBからエンドポイントCへの移転が完了したことを意味する。
しかしながら、この手続きは、エンドポイントBからエンドポイントCへの移転を完了にしただけではなく、更にエンドポイントAからエンドポイントDへの“同時の”移転の効果も考慮に入れている。このため実際の更新は、エンドポイントAが更なるACKメッセージUPDACKACKを送信し終わるまで遅らされている。さらに、このUPDACKACKメッセージは、エンドポイントCも今後はエンドポイントAに代わるべき新しいエンドポイント、すなわちエンドポイントDと通信することになることが通知された後になってはじめて送信される。このことは、エンドポイントBにおける第1の移転(エンドポイントBからエンドポイントCへの移転)の(エンドポイントBからエンドポイントCへの移転を可能にするための)準備と、エンドポイントCにおける第1の移転の(エンドポイントCとエンドポイントDとの間の通信に備えるための)準備とが完了した後に、“最終”又は“更なる”ACKメッセージUPDACKACKが送信され、そのメッセージがベアラ・エンドポイントBのベアラ・エンドポイントCへの移転を終了させることを意味する。
図5に示している上述した手続きは、エンドポイントAからエンドポイントDへの移転にも同じような対称的な方法で適用されることは容易に明らかであろう。しかしながら、対応するメッセージは、図5においては分かりやすくするために示されていない。それでも完全を期すため、対応するメッセージを以下に説明する。
エンドポイントAからエンドポイントDへの移転に関しては、最初にノードDからノードBへ初期化メッセージI1が送信され、ノードBはノードDへリーチアビリティ・リクエストR1を返信する。次にエンドポイントDは、ノードA、B及びCのホスト識別タグとベアラ識別子とを含んでいるリーチアビリティ・リプライI2をノードBへ送信することによって応答する。リーチアビリティ・リクエスト及びリーチアビリティ・リプライは、偽装攻撃を避けるために、要求元エンドポイントのアドレス検査を実行する役割を果たす。続いて、エンドポイントBからエンドポイントAへ、エンドポイントA、B及びDの識別子を含む更新リクエストUPDが(図5に示されているものとは正反対の方向に)送信され、次に、エンドポイントAは、新しいエンドポイントDのインディケーション(例えば、そのホスト識別タグHIT)を更に含むACKメッセージUPDACKで応答する。
続いてエンドポイントBは、今度はエンドポイントBの移転先であるエンドポイントCのインディケーションを含む完了メッセージR2を、エンドポイントDに送信する。エンドポイントAは、メッセージI1、R1及びI2(図5に関連して既に説明しているがこれはエンドポイントAがノードCから受信したもの)を通じてノードBによって実行される移転について知っている。それゆえ、ノードAは、ノードAからノードBへ送られるUPDACKメッセージの中にノードCの識別子を含ませることが可能である。そしてノードBは、この情報をノードAへ完了メッセージR2と一緒に転送する。
ノードDは、完了メッセージR2を受信し終わると、今後はエンドポイントCと通信することになっていることが知らされ、それに応じて準備を整えることができる。続いて“更なる”ACKメッセージUPDACKACKがエンドポイントBからエンドポイントAへ送信され、エンドポイントAは、ノードAからノードDへの移転を実際に実行するためにそのローカルな状態情報を実際に更新することができる。
UPDACKACKメッセージが送られた後、本発明の実施の一形態によれば、更なるメッセージO’SETUP?が送信され得る。このメッセージは、エンドポイントDに対してエンドポイントCと通信したいかどうかを確認するために問い合わせるものである。このメッセージは、図5にはO’SETUP?で表示されている。
以上の説明から2つのベアラ・エンドポイントの実質的に同時の移転が上記方法によって可能になることは明らかである。このことは、従来技術におけるようなシリアル化アプローチに従うのではなく2つの移転に関連したメッセージを交互に独立に送ることが可能なアプローチに従うことに起因する。整合性問題は、その受信まで状態情報の更新が遅らされる“更なる”ACKメッセージを導入することで避けられる。さらに、“第2の移転のリクエスト”に係る新しいエンドポイントのインディケーションを、更新ACKメッセージUPDACKと第1のエンドポイントの移転手続きの完了メッセージR2とに含ませることにより、整合性問題をもたらすことなく2つの移転プロセスを完全に対称的に実行することを可能にするようなやり方で2つの移転プロセスをミックスすることが可能となる。
次に、図6を参照してベアラ・エンドポイントの移転の更なる実施形態について説明する。図6は、図3と似ている。しかしながら、図6は、図5に関連して説明してきた実施形態におけるものと同様の2つのエンドポイントが同時に引き継ぐケースのシーケンス図である。
図6において、ノード1は図5のエンドポイントAに対応し、ノード2は図5のエンドポイントBに対応し、ノード3は図5のエンドポイントCに対応し、ノード4は図5のエンドポイントDに対応する。このことは、ノード1とノード2(図5においてエンドポイントAとエンドポイントB)が最初に接続されており、ノード1の役割はノード4に引き継がれ、ノード2の役割はノード3に引き継がれることを意味する。
最初に、ノード4は、例えば外部からの作用によって又はユーザ入力若しくは他の入力によって、役割がノード1と置き換わるよう移転を実行するようにトリガーされる。移転を開始するため、ノード4は、初期化メッセージI1をノード2に送信し、ノード2は。ノード4にリーチアビリティ・リクエスト・メッセージR1を返信する。
その間、ノード3は、ノード2からノード3への移転の着手を開始するように外部から(例えば、ユーザ又は他の外部のトリガー若しくは場合によっては内部のトリガーによって)トリガーされる。結果、ノード3はノード1へ初期化メッセージI1を送信し、それに応答してノード1はリーチアビリティ・リクエスト・メッセージR1をノード3に返信する。ノード3は次に、リーチアビリティ・リプライ・メッセージI2をノード1へ送信するが、図6から分かるように、ノード1とノード3との間で交換されるこれら2つのメッセージR1及びI2の間において、ノード4からノード2へ送られるリーチアビリティ・リプライがインターリーブ(交互的な交換)されている。メッセージI1、R1、及びI2は、図5に関連して既に説明したような情報をそれぞれ含んでおり、例えば、図5に関連して既に説明したように、これらのメッセージは、ホスト識別情報とベアラ識別子とを含んでいる。
ノード2はノード4からメッセージI2を受信した後、ノード2は更新リクエストメッセージUPDをノード1へ送信してノード4へ引き継ぐべきことを知らせる。同様に、ノード1は、ノード3からメッセージI2を受信した後、ノード2へ更新リクエストメッセージUPDを送信してノード2にノード3へ引き継ぐべきことを知らせる。この場合も同様にこれらのメッセージの各々は、図5に関連して説明したようなベアラ識別子とホスト識別子とに関する情報を含んでいる。
更新リクエストメッセージUPDに応答して、ノード1及びノード2は、それぞれ更新ACKメッセージUPDACKを送信する。図6においてこれらのメッセージがどのようにインタリーブされているか理解することができる。
図5のケースと同様に、ノード1及びノード2における状態情報の実際の更新は遅らされていることに留意すべきである。というのは、これらのノードは各々、ノード1及びノード2で既に受信されているメッセージI1、R1及びR2から導き出すことができるような別の移転のリクエストが依然として存在していることを知っているからである。これらのメッセージによって、ノード1及びノード2の各ノードは、UPDリクエストメッセージを受信すると、受信したばかりのUPDリクエストメッセージは実行すべき全体で2つの移転の中の第1の移転の一部に過ぎないことを知ることになる。このことは、これらの2つのノードがUPDリクエストメッセージに応答して更新ACK情報UPDACKを送信するのにもかかわらず、それらのローカルな状態情報の実際の更新を遅らせる原因となっている。
ノード1は、ノード2からUPDメッセージを受信した後、返信として更新ACKメッセージをノード2に送信する。このメッセージはいま受信したばかりのUPDリクエストメッセージに関連した第1の移転(ノード1からノード4への移転)とは異なる第2の移転(ノード2からノード3への移転)の移転先エンドポイントのインディケーションを含んでいる。つまりノード1からノード2へ送信されるUPDメッセージには、ノード3のインディケーションが含まれている。続いて、ノード2がUPDACKメッセージで受信したばかりのノード3のインディケーションを含む完了メッセージR2が、ノード2からノード4へ送信される。これにより、ノード1から役割を引き継ぐ予定のノード4は、その通信相手が今後はノード2の代わりにノード3になることに対し準備することができる。
同様に、ノード2からノード1へ送られるUPDACKメッセージには、“第1の移転”(ノード1からノード4への移転)の移転先のインディケーションが含まれている。これは、ノード4のインディケーションがこのメッセージに含まれていることを意味する。ノード1は、ノード4のインディケーションを含む完了メッセージR2をノード3へ送る。これにより、ノード2から役割を引き継ぐノード3は、その通信相手が今後はノード1の役割を引き継ぐノード4になるという事実に対し準備することが可能となる。
完了メッセージR2が、ノード1からノード3へ、ノード2からノード4へ送られた後、実際の移転の準備が完了する。ノード2に完了を通知するため、ノード1は“更なる”ACKメッセージUPDACKACKを送信する。このメッセージは、ノード2においてローカルな状態情報の実際の更新を更に遅らせる必要がないことをノード2に知らせるものである。同様に、ノード2は、ノード1においてローカルな状態情報の実際の更新を更に遅らせる必要がないことをノード1に知らせるUPDACKACKメッセージを送信する。こうして、ノード1及びノード2は、更なるACKメッセージUPDACKACKを受信した後、それぞれのローカルな状態情報を更新し、以前の状態情報は削除される。これを以て移転は実際に完了する。
図6から、2つの移転(ノード1からノード4への移転とノード2からノード3への移転)に関連したメッセージは、交互に送信されることが可能なことが容易に分かる。このことは、無理矢理なシリアル化に起因すると考えられる、どのような遅延も避けることができることを意味する。
状態情報が上述した実施形態の中で言及される限りでは、この状態情報は、HIPプロトコルに基づくホスト識別タグの端末IPアドレスへのマッピングによって提供することができる。しかしながら、当業者であれば、エンドポイントのその通信相手との関連付けを識別する任意の他の状態情報を使用することが可能なことはすぐに理解されよう。ホスト識別タグの代わりに、エンドポイントの論理結合によってセッション又はフローを定義する他の状態情報が使用され得る。したがって当業者であれば、これまで使用してきた又は特許請求の範囲の請求項の中で使用されている“ベアラ・モビリティ(bearer mobility)”を実現する手続きは、同様にして“フロー・モビリティ(flow mobility)”又は“セッション・モビリティ(session mobility)”を実現するために適用することができるだけでなく、2つのエンドポイントが同時に又は少なくとも完全に順次的にではなく移転するような場合におけるダブルジャンプ(double jump)の問題の解決法を実現するために適用することができることは理解されよう。
上述した実施形態は、ハードウェア、ソフトウェア、又はソフトウェアとハードウェアとの組み合わせによって実施することができることは当業者には理解できるであろう。本発明の実施形態に関連して記述したモジュールの全体又は一部は、本発明の実施形態に関連して説明された方法に従って動作するようにプログラムされたマイクロプロセッサ又はコンピュータによって実施することが可能である。
単一のベアラ・エンドポイントのみが移転する場合のベアラ・モビリティを示している図である。 単一のベアラ・エンドポイントのみが移転する場合のベアラ・モビリティの手続きを詳細に示している概略図である。 単一のベアラ・エンドポイントのみが移転する場合のベアラ・モビリティの手続きをより詳細に示しめしているシーケンス図である。 2つのベアラ・エンドポイントが同時に移転する場合の状況を示している図である。 本発明の実施の一形態によるベアラ・モビリティの手続きを示している概略図である。 本発明の実施の一形態によるベアラ・モビリティの手続きをより詳細に示しているシーケンス図である。
符号の説明
A,B,C,D ベアラ・エンドポイント
I1 初期化メッセージ
I2 リーチアビリティ・リプライ
R1 リーチアビリティ・リクエスト
R2 完了メッセージ
UPD 更新リクエストメッセージ
UPDACK 更新ACKメッセージ
UPDACKACK 更なる更新ACKメッセージ

Claims (17)

  1. ベアラ・エンドポイントは通信サービスの終端となる論理オブジェクトであり、ベアラはベアラ・エンドポイント間の論理結合であり、前記ベアラと前記ベアラ・エンドポイントとの間の論理結合は状態情報の中に定義され、前記ベアラが第1のベアラ・エンドポイントと第2のベアラ・エンドポイントとを備えるとき、前記第1のベアラ・エンドポイントを第3のベアラ・エンドポイントへ引き継ぐための方法であって、
    前記第1のベアラ・エンドポイントの移転を開始するためのリクエストを前記第3のベアラ・エンドポイントから前記第2のベアラ・エンドポイントへ送信することによって前記第1のベアラ・エンドポイントの移転を開始するステップと、
    前記第1のベアラ・エンドポイントに関する論理結合を定義する状態情報の更新を要求するために、状態情報の更新をリクエストするメッセージを、前記第2のベアラ・エンドポイントから前記第1のベアラ・エンドポイントへ送信するステップと、
    これらベアラ・エンドポイントの移転を反映させるため、前記第2のベアラ・エンドポイントから前記第1のベアラ・エンドポイントへ送信された前記状態情報の更新をリクエストするメッセージに応答して、前記第1のベアラ・エンドポイントに関する論理結合を定義する前記状態情報の更新を実行するステップと、
    前記第1のベアラ・エンドポイントに関する論理結合を定義する前記状態情報の更新のリクエストに確認応答するために、前記第1のベアラ・エンドポイントから前記第2のベアラ・エンドポイントへ更新ACK(確認応答)メッセージを送信するステップとを含んでおり、
    当該方法は、
    前記第2のベアラ・エンドポイントを第4のベアラ・エンドポイントへ移転することに関連する前記第2のベアラ・エンドポイントの移転を開始するためのリクエストが、前記状態情報の更新が実行される前に前記第1のベアラ・エンドポイントによって検出された場合において、
    前記第4のベアラ・エンドポイントのインディケーションを含むメッセージを前記第3のベアラ・エンドポイントへ送信し、
    前記第4のベアラ・エンドポイントを表す情報が前記第3のベアラ・エンドポイントに伝達されたことを知らせる更なる更新ACKメッセージが、前記第2のベアラ・エンドポイントから送信されて前記第1のベアラ・エンドポイントによって受信されるまでは、前記第1のベアラ・エンドポイントに関する論理結合を定義する前記状態情報の更新を遅らせるステップを含んでいる、方法。
  2. 前記第1及び第2のベアラ・エンドポイントを定義する前記状態情報は、エンドポイントの論理名とロケータとの間のマッピングを含んでおり、
    前記エンドポイントに対する論理名はホスト識別プロトコル(HIP)で使用されるホスト識別タグであり、前記ロケータはIPアドレスである、請求項1に記載の方法。
  3. 前記第1のベアラ・エンドポイントによって送信される更新ACKメッセージは、前記第4のベアラ・エンドポイントのインディケーションを含むものである、請求項1又は2に記載の方法。
  4. 前記第2のベアラ・エンドポイントから前記第1のベアラ・エンドポイントへ前記更なる更新ACKメッセージを送信する前に、前記第2のベアラ・エンドポイントから前記第3のベアラ・エンドポイントへ更新リクエスト完了メッセージを送信するステップを更に含んでいる、請求項1乃至3のいずれか1項に記載の方法。
  5. 前記更新リクエスト完了メッセージは、前記第4のベアラ・エンドポイントのインディケーションを含むものである、請求項4に記載の方法。
  6. 前記第3のベアラ・エンドポイントから前記第2のベアラ・エンドポイントへ前記第1のベアラ・エンドポイントの移転を開始するためのリクエストを送信した後に、前記第2のベアラ・エンドポイントから前記第3のベアラ・エンドポイントへリーチアビリティ・リプライ・リクエスト・メッセージを送信するステップと、
    前記第3のベアラ・エンドポイントから前記第2のベアラ・エンドポイントへリーチアビリティ・リプライ・メッセージを送信するステップと
    を更に含んでいる、請求項1乃至5のいずれか1項に記載の方法。
  7. 前記第1のベアラ・エンドポイントが、前記第4のベアラ・エンドポイントから前記第1のベアラ・エンドポイントへ送信された前記第2のベアラ・エンドポイントの移転を開始するためのリクエスト・メッセージ又は前記リーチアビリティ・リプライ・メッセージを受信することによって、前記第2のベアラ・エンドポイントの移転を開始するためのリクエストを検出するステップを更に含んでいる、請求項1乃至6のいずれか1項に記載の方法。
  8. 前記第1のベアラ・エンドポイントによって受信された前記第2のベアラ・エンドポイントの移転を開始するためのリクエストに応答して、前記第1のベアラ・エンドポイントから前記第2のベアラ・エンドポイントへ前記状態情報の更新をリクエストするメッセージを送信するステップと、
    前記第2のベアラ・エンドポイントから前記第1のベアラ・エンドポイントへ前記更新ACKメッセージを送信するステップと、
    前記第3のベアラ・エンドポイントのインディケーションを含むメッセージを前記第4のベアラ・エンドポイントへ送信するステップと、
    前記第2のベアラ・エンドポイントに関する論理結合を定義する前記状態情報の更新を実行するステップとを含んでおり、
    前記第2のベアラ・エンドポイントに関する論理結合を定義する前記状態情報の更新は、前記第3のベアラ・エンドポイントを表す情報が第4のベアラ・エンドポイントに伝達されたことを知らせる前記更なる更新ACKメッセージが、前記第1のベアラ・エンドポイントから送信されて前記第2のベアラ・エンドポイントによって受信されるまで遅らされる、請求項1乃至7のいずれか1項に記載の方法。
  9. 前記第2のベアラ・エンドポイントによって送信される前記更新ACKメッセージは、前記第3のベアラ・エンドポイントのインディケーションを含むものである、請求項8に記載の方法。
  10. 前記更なる更新ACKメッセージを第1のベアラ・エンドポイントから第2のベアラ・エンドポイントへ送信する前に、更新リクエスト完了メッセージを前記第1のベアラ・エンドポイントから前記第4のベアラ・エンドポイントへ送信するステップを更に含んでいる、請求項8又は9に記載の方法。
  11. 前記更新リクエスト完了メッセージは、前記第3のベアラ・エンドポイントのインディケーションを含むものである、請求項8乃至10のいずれか1項に記載の方法。
  12. 前記第1のベアラ・エンドポイントが前記第3のベアラ・エンドポイントへ引き継がれるような第1のベアラ・エンドポイントの移転に関連するメッセージと、
    前記第2のベアラ・エンドポイントが前記第4のベアラ・エンドポイントへ引き継がれるような第2のベアラ・エンドポイントの移転に関連するメッセージとは、交互に送信される、請求項1乃至11のいずれか1項に記載の方法。
  13. ベアラ・エンドポイントは通信サービスの終端となる論理オブジェクトであり、ベアラはベアラ・エンドポイント間の論理結合であり、前記ベアラと前記ベアラ・エンドポイントとの間の論理結合は状態情報の中に定義され、前記ベアラが第1のベアラ・エンドポイントと第2のベアラ・エンドポイントとを備えるとき、前記第1のベアラ・エンドポイントを第3のベアラ・エンドポイントへ引き継ぐための装置であって、
    第1のベアラ・エンドポイントの移転を開始するためのリクエストを、前記第3のベアラ・エンドポイントから前記第2のベアラ・エンドポイントへ送信することによって、第1のベアラ・エンドポイントの移転を開始するためのモジュールと、
    前記第1のベアラ・エンドポイントに関する論理結合を定義する状態情報の更新を要求するために、状態情報の更新をリクエストするメッセージを前記第2のベアラ・エンドポイントから前記第1のベアラ・エンドポイントへ送信するためのモジュールと、
    これらベアラ・エンドポイントの移転を反映させるため、前記第2のベアラ・エンドポイントから前記第1のベアラ・エンドポイントへ送信された前記状態情報の更新をリクエストするメッセージに応答して、前記第1のベアラ・エンドポイントに関する論理結合を定義する前記状態情報の更新を実行するためのモジュールと、
    前記第1のベアラ・エンドポイントに関する論理結合を定義する前記状態情報の更新のリクエストに確認応答するために、前記第1のベアラ・エンドポイントから前記第2のベアラ・エンドポイントへ更新ACKメッセージを送信するためのモジュールとを備えており、
    当該装置は、
    前記状態情報の更新が実行される前に、前記第1のベアラ・エンドポイントによって、前記第2のベアラ・エンドポイントを前記第4のベアラ・エンドポイントへ移転することに関連する前記第2のベアラ・エンドポイントの移転を開始するためのリクエストの有無を検出し、該リクエストが検出された場合において、
    前記第4のベアラ・エンドポイントのインディケーションを含むメッセージを前記第3のベアラ・エンドポイントへ送信し、
    前記第4のベアラ・エンドポイントを表す情報が前記第3のベアラ・エンドポイントに伝達されたことを知らせる更なる更新ACKメッセージが、前記第2のベアラ・エンドポイントから送信されて前記第1のベアラ・エンドポイントによって受信されるまで、前記第1のベアラ・エンドポイントに関する論理結合を定義する前記状態情報の更新を遅らせるように構成されているモジュールを更に備えている、
    装置。
  14. ベアラ・エンドポイントは通信サービスの終端となる論理オブジェクトであり、ベアラはベアラ・エンドポイント間の論理結合であり、前記ベアラと前記ベアラ・エンドポイントとの間の論理結合は状態情報の中に定義され、前記ベアラが第1のベアラ・エンドポイントと第2のベアラ・エンドポイントとを備えるとき、前記第1のベアラ・エンドポイントを第3のベアラ・エンドポイントへ引き継ぐための装置であって、ここで、前記第1のベアラ・エンドポイントと前記第2のベアラ・エンドポイントとを備える前記ベアラのベアラ・エンドポイントが、前記第1のベアラ・エンドポイントが第3のベアラ・エンドポイントによって置き換えられるように移転され、この移転の完了には、前記ベアラと前記ベアラ・エンドポイントとの間の論理結合を定義する状態情報の更新が含まれ、これにより、ネットワークにおけるベアラ・モビリティを実現するような装置であり、
    前記第3のベアラ・エンドポイントから前記第2のベアラ・エンドポイントへ第1のベアラ・エンドポイントの移転を開始するためのリクエストを送信することによって前記第1のベアラ・エンドポイントの移転が開始された後に、前記第1のベアラ・エンドポイントに関する論理結合を定義する状態情報の更新を要求するために前記第2のベアラ・エンドポイントから送信されるような状態情報の更新をリクエストするメッセージを、前記第1のベアラ・エンドポイントによって受信するためのモジュールと、
    これらのベアラ・エンドポイントの移転を反映させるために、前記第2のベアラ・エンドポイントから前記第1のベアラ・エンドポイントへの前記状態情報の更新をリクエストするメッセージに応答して、前記第1のベアラ・エンドポイントに関する論理結合を定義する前記状態情報の更新を実行するモジュールと、
    前記第1のベアラ・エンドポイントに関する論理結合を定義する前記状態情報の更新のリクエストに確認応答するために、前記第1のベアラ・エンドポイントから前記第2のベアラ・エンドポイントへ更新ACKメッセージを送信するためのモジュールとを備えており、
    当該装置は、
    前記状態情報の更新が実行される前に、前記第1のベアラ・エンドポイントによって、前記第2のベアラ・エンドポイントを前記第4のベアラ・エンドポイントへ移転することに関連する第2のベアラ・エンドポイントの移転を開始するためのリクエストの有無を検出し、該リクエストが検出された場合において、
    前記第4のベアラ・エンドポイントを表す情報が第3のベアラ・エンドポイントに伝達されたことを知らせる更なる更新ACKメッセージが、前記第2のベアラ・エンドポイントから送信されて前記第1のベアラ・エンドポイントによって受信されるまで、前記第1のベアラ・エンドポイントに関する論理結合を定義する前記状態情報の更新を遅らせるように構成されているモジュールを更に備えている、装置。
  15. ベアラ・エンドポイントは通信サービスの終端となる論理オブジェクトであり、ベアラはベアラ・エンドポイント間の論理結合であり、前記ベアラと前記ベアラ・エンドポイントとの間の論理結合は状態情報の中に定義され、前記ベアラが第1のベアラ・エンドポイントと第2のベアラ・エンドポイントとを備えるとき、前記第1のベアラ・エンドポイントを第3のベアラ・エンドポイントへ引き継ぐための装置であって、
    第1のベアラ・エンドポイントの移転を開始するためのリクエストを前記第3のベアラ・エンドポイントから前記第2のベアラ・エンドポイントへ送信することによって前記第1のベアラ・エンドポイントの移転が開始された後に、前記第2のベアラ・エンドポイントから前記第1のベアラ・エンドポイントへ、状態情報の更新をリクエストするメッセージを送信して、移転を反映させるために前記第2のベアラ・エンドポイントから前記第1のベアラ・エンドポイントへ送信された前記状態情報の更新をリクエストするメッセージに応答して、前記第1のベアラ・エンドポイントに関する論理結合を定義する状態情報の更新の実行を要求するためのモジュールと、
    第1のベアラ・エンドポイントに関する論理結合を定義する状態情報の更新のリクエストに確認応答するために、前記第1のベアラ・エンドポイントから前記第2のベアラ・エンドポイントへ送信された更新ACKメッセージを受信するためのモジュールとを備えており、
    当該装置は、
    前記状態情報の更新が実行される前に、前記第1のベアラ・エンドポイントによって、前記第2のベアラ・エンドポイントを第4のベアラ・エンドポイントへ移転することに関連する第2のベアラ・エンドポイントの移転を開始するためのリクエストの有無を検出し、該リクエストが検出された場合において、
    前記第4のベアラ・エンドポイントのインディケーションを含むメッセージを前記第3のベアラ・エンドポイントへ送信し、
    前記第4のベアラ・エンドポイントを表す情報が前記第3のベアラ・エンドポイントに伝達されたことを知らせる更なる更新ACKメッセージを前記第2のベアラ・エンドポイントから前記第1のベアラ・エンドポイントへ送信し、前記第1のベアラ・エンドポイントが前記第2のベアラ・エンドポイントから前記更なる更新ACKメッセージを受信するまで、前記第1のベアラ・エンドポイントに関する論理結合を定義する前記状態情報の更新が遅らされるように構成されているモジュールを更に備えている、装置。
  16. 請求項2乃至12のいずれか1項に記載された方法を実行するための手段、又はモジュールを更に備えている請求項13乃至15のいずれか1項に記載の装置。
  17. 請求項1乃至12のいずれか1項に記載された方法をコンピュータ上で実行するコンピュータ・プログラム。
JP2007020539A 2006-01-31 2007-01-31 ベアラ・モビリティを実現するための方法及び装置 Expired - Fee Related JP4296201B2 (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP20060101119 EP1814279B1 (en) 2006-01-31 2006-01-31 Method and apparatus for implementing bearer mobility

Publications (2)

Publication Number Publication Date
JP2007208983A JP2007208983A (ja) 2007-08-16
JP4296201B2 true JP4296201B2 (ja) 2009-07-15

Family

ID=36693242

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007020539A Expired - Fee Related JP4296201B2 (ja) 2006-01-31 2007-01-31 ベアラ・モビリティを実現するための方法及び装置

Country Status (3)

Country Link
EP (1) EP1814279B1 (ja)
JP (1) JP4296201B2 (ja)
DE (1) DE602006017162D1 (ja)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101895522A (zh) * 2009-05-22 2010-11-24 华为技术有限公司 主机标识标签获取方法及系统
EP2887733A1 (en) 2013-12-20 2015-06-24 NTT DoCoMo, Inc. Mobility for mobility anchors
EP3122113A4 (en) * 2014-03-20 2017-11-08 Nec Corporation Communication device, communication method, communication system, and program

Also Published As

Publication number Publication date
EP1814279B1 (en) 2010-09-29
JP2007208983A (ja) 2007-08-16
DE602006017162D1 (de) 2010-11-11
EP1814279A1 (en) 2007-08-01

Similar Documents

Publication Publication Date Title
Demmer et al. Delay-tolerant networking tcp convergence-layer protocol
TWI309115B (en) Bitmap manager, method of allocating a bitmap memory, method of generating an acknowledgement between network entities, and network entity implementing the same
CN101667916B (zh) 一种基于分离映射网络使用数字证书验证用户身份的方法
JP4625125B2 (ja) マルチ鍵暗号化生成アドレスを用いたセキュアなアドレスプロキシ
WO2011006324A1 (zh) 文件传输方法及终端
KR20080107250A (ko) 무선 접속 시스템에서 mih 프로토콜 메시지 전송방법
CN1741523B (zh) 一种实现主机移动性和多家乡功能的密钥交换协议方法
CN107612931B (zh) 多点会话方法及多点会话系统
CN111491351B (zh) 一种基于认证信息感知WiFi终端上线的方法及系统
JP4296201B2 (ja) ベアラ・モビリティを実現するための方法及び装置
CN106331198A (zh) Nat穿透方法及装置
JP2008098813A (ja) 情報通信装置、情報通信方法、及びプログラム
WO2008067740A1 (fr) Procédé, système, terminal et dispositif de transfert de message entre terminaux
CN108512833A (zh) 一种防范攻击方法及装置
Demmer et al. RFC 7242: Delay-Tolerant Networking TCP Convergence-Layer Protocol
WO2011044810A1 (zh) 实现多方通信的方法、装置及系统
CN107948165B (zh) 一种基于私有协议的安全送播系统及方法
KR101730405B1 (ko) 네트워크 경로를 관리하는 방법 및 이를 수행하는 네트워크 엔티티
CN102480468B (zh) 一种数据流传输方法、装置及系统
TW201519617A (zh) 網路連線方法及其網路系統
KR100691286B1 (ko) 유비쿼터스 환경에서의 끊김없는 이동성 지원 장치 및 그방법
JP6076018B2 (ja) 呼制御装置、登録処理方法、及びプログラム
JP5450412B2 (ja) モバイルIPv4用の新しいDiameterシグナリング
KR101328028B1 (ko) 세션 기반 메시지 전송 시스템 및 그 방법
CN116760915A (zh) 数据传输方法、装置、处理设备及存储介质

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20090305

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

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20090317

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20090413

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120417

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Ref document number: 4296201

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120417

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130417

Year of fee payment: 4

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130417

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140417

Year of fee payment: 5

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees