JP2006524024A

JP2006524024A - セッション・エンドポイント管理プロトコル

Info

Publication number: JP2006524024A
Application number: JP2006510043A
Authority: JP
Inventors: ナラヤナンサティア; 大作小宮; カンデルワルラジェシュ
Original assignee: Panasonic Corp; Matsushita Electric Industrial Co Ltd
Current assignee: Panasonic Corp; Panasonic Holdings Corp
Priority date: 2003-04-15
Filing date: 2004-04-15
Publication date: 2006-10-19
Also published as: CN1774893A; WO2004093410A3; CN1774893B; DE602004024666D1; CN102858030A; US7539759B2; EP1614263A2; EP1614263B1; WO2004093410A2; US20040210657A1

Abstract

【課題】アドホック・ネットワークにおいてセッション・エンドポイントを操作するプロトコルを提供する。
【解決手段】アドホック・ネットワーク環境においてセッション・エンドポイントを拡張するプロトコルは、まず装置発見を実行して、この装置のカバーエリア内のローカル装置、及びこれらの装置の能力を特定する。そしてこれらのローカル装置が、エンドポイント装置とセッション記述を交換する。現在のセッションがこれらのローカル装置の１つによってサポート可能であれば、エンドポイント装置はユーザからのコマンドに応答して、セッション・エンドポイントをこのローカル装置に移転して、このエンドポイント装置はセッションにおいてこのローカル装置のプロキシとして作用する。随意的に、前記ローカル装置が、前記エンドポイント装置を通る経路とは独立した経路である応対ノードへの経路を有する場合には、このローカル装置はこの経路に沿ったセッションを確立し、そしてエンドポイント・ノードにそのセッションを終了するよう信号通知する。

Description

（発明の背景）
本発明は、アドホック（特定）ネットワークに関するものであり、特に、特定ネットワーク環境におけるセッション・エンドポイント（セッションの端点）を操作するプロトコルに関するものである。

近年の、コンピュータ技術の能力の向上及びコストの低下に結び付いた無線通信技術における進歩は、以前には携帯装置用には法外に高価であるか大きすぎるかのいずれかであった無線コンピューティング（コンピュータによる演算、制御）の応用を可能にした。こうした応用の多くは、移動アドホック・ネットワーク（MANET：Mobile Ad-hoc Networking）として知られているネットワーク構造上に構築することができる。アドホック・ネットワークは、接続に応じて変化する移動コンピューティング・ノードのグループを用いて動的に形成される。効率的に動作するために、これらのネットワークは、各ノードにおいてルーティング（経路設定）機能を具えることが望ましい。これらの装置が近距離用である性質により、装置間の通信チャンネルは、ソース（送信元）とデスティネーション（宛先）との間にいくつかの中間ノードを越えることがあり得る。この越える動作の各々は「ホップ」として知られているので、これらのネットワークはマルチホップ（多重ホップ）ネットワークと称される。

複数ノードにおけるルーティング機能を実現することによって、これらのネットワークは、ある中間ノードがもはやネットワークの一部となり得ない場合に、接続中の２つのノード間の経路の再確立を可能にする。例えば、ホップの１つに使用した装置がもはやグループ内の他のノードと通信不能であるために通信中のノード間の１つの経路が消失した場合に、欠損したノードを必要としない二次的な経路を迅速に規定することができる。

アドホック・ネットワークを実現するために、多くの可能なプロトコルが規定されてきた。これらのプロトコルは、アドホック・オンデマンド距離ベクトル（AODV：Ad-hoc On-Demand Distance Vector）ルーティング、ダイナミックソース・ルーティング（Dynamic Source Routing：動的な送信元ルーティング）、オプティマイズド・リンクステート・ルーティング（Optimized Link State Routing：最適化されたリンク状態のルーティング）、及びトポロジー・ブロードキャスト・ベースト・オン・リバースパス・ルーティング（Topology Broadcast Based on Reverse Path Routing：逆経路のルーティングに基づくトポロジー放送）を含む。これらのプロトコルのすべてが、Mobile Ad-Hoc Network working group of the Internet Engineering Task Force（ITEF）（インターネット技術特別専門委員会の移動アドホック・ネットワーク作業部会）によって維持されているウェブサイトに掲載されている。

今日、移動の管理は、次の２つの問題：ハンドオフ管理及びロケーション（位置）管理に大いに関係している。ハンドオフ管理は、移動ノードが移動中の、移動ネットワーク内の移動ノードと応対ノードとの間のアクティブ（有効）セッションの維持に関係する。移動ノードが、現在の基地局のカバーエリア（受け持ち領域）を離れて新たな基地局のカバーエリアに入ると、現在の基地局と新たな基地局との間のハンドオフがこのセッションを有効に保つ。この問題には、RFC 2002に記載のモバイルIPプロトコル（Mobile IP Protocol）のような既存のプロトコルが応える。

ロケーション管理は、ネットワーク内の移動ノードが能動的に通信していない際にその位置を求める問題に関係する。このことは、例えば、ネットワークがその移動ノード宛てに向けられた入りの呼び（コール）を受信する際に望まれる。この問題を解決するために、ネットワークは、この移動ノードを含むカバーエリアを有する基地局を見出す。このロケーション管理の問題には、例えばITIFプロトコルのうち上記のモバイルIPプロトコルが応えてきた。

（発明の概要）
本発明は、アドホック・ネットワーク環境におけるセッション・エンドポイントを管理するために使用可能なプロトコルで具現される。本発明によるプロトコルを用いるエンドポイント装置は、そのカバーエリア内のローカル（局在）装置を識別し、そして随意的に、こうした装置との間で装置能力を交換する。そしてこれらのローカル装置は、エンドポイント装置との間でセッション記述を交換する。現在のセッションがローカル装置の１つによってサポート（支援）可能な場合には、エンドポイント装置はセッション・エンドポイントをこのローカル装置に移動することができる。そして前のエンドポイント装置は、このローカル装置のプロキシ（代理）として作用する。

本発明によれば、セッションをローカル装置にコピーして、このローカル装置がセッション中にエンドポイント装置の動作を複製する。

本発明の他の態様によれば、セッションを分割して、セッションの各部分を異なるローカル装置のそれぞれに送信する。

本発明のさらに他の態様によれば、複数のローカル装置間に分けた分割セッションを併合（マージ）して単一のセッションにする。

本発明の他の態様によれば、エンドポイント装置が、ローカルノードに宛てられた入セッションを受信して、このセッション・エンドポイントをこのローカルノードに移動して、この入セッションを完成する。

本発明の他の態様によれば、ローカル装置からの出セッションは、エンドポイント装置にセッションを生成させ、そしてこのセッションをこのエンドポイント装置からこのローカル装置に移動することによる。

本発明は、以下の実施例の詳細な説明を図面を参照して読めば最も良く理解できる。なお慣例のように、図面における種々の図形は一定寸法比で描いたものではない。逆に、種々の図形の寸法は明瞭にするために任意に拡大または縮小されている。

（実施例の詳細な説明）
以下、本発明の実施例について図面を参照しながら説明する。本発明は、アドホック（特定）ネットワーク内のセッション・エンドポイント（セッションの端点）を管理するプロトコルにおいて具現される。セッション・エンドポイントを操作することによって、このプロトコルは、ユーザが装置に依存しない通信を達成することを可能にし、ユーザは、特定環境において利用可能な装置のグループから、セッションのデータを処理するための最良の装置を選択することができる。本発明のプロトコルは次の６つの動作：MOVE（ムーブ：移動）、COPY（コピー：複写）、SPLIT（スプリット：分割）、MERGE（マージ：併合）、INCOMING SESSION（インカミング・セッション：入セッション）、及びOUTGOING SESSION（アウトゴーイング・セッション：出セッション）を含む。このプロトコルは、その下層にありセッション中に使用されるトランスポート（搬送）プロトコルにも、セッション中に使用され得る他のいずれのプロトコルにも影響しない。本発明のプロトコルの各部分は、ブルートゥース（登録商標）デバイス・ディスカバリー・プロトコル（Bluetooth device discovery protocol：ブルートゥース装置発見プロトコル）またはインターネット・セッション・デスクリプション・プロトコル（SDP：Internet Session Description Protocol：インターネットのセッション記述プロトコル）のような他のプロトコルによって実現することができ、これらの両者については以下に説明する。好適なプロトコルは、オープン・システム・インターコネクション（OSI：Open Systems Interconnection：開放型システム相互接続）の７層のうちのセッション層あるいはその上位の層において実現することができる。

図１に、ノード１０４、１０６、１０８及び１１０を含むIP（Internet Protocol：インターネットのプロトコル）ネットワーク１０２のブロック図を示す。本明細書では一次ネットワークと称するこのネットワークは、有線でも無線でもあり得る。この一次ネットワークはアクセスポイント１１２も含み、アクセスポイント１１２を通して、無線装置、例えばビデオ能力を有する無線電話がこのネットワークと通信することができる。以下に説明する例では、ビデオサーバー１００もネットワーク１０２に結合され、移動ノード１１４との応対ノードとして働く。この例では、電話機１１４とビデオサーバー１００との間でセッションが確立される。ビデオサーバー１００は、移動電話機１１４によって要求されたビデオ番組（プログラム）を供給する。この番組を要求して供給するために、接続１０１が応対ノード１００とネットワークのノード１０４との間に確立され、接続１０５、１０７及び１１１が、それぞれノード１０６、１０８及び１１２に対して確立される。アクセスポイント１１２は、移動電話機１１４との無線接続１１３を有する。ビデオサーバー１００と移動電話機１１４との間に確立されたセッションは、電話機１１４をその一次エンドポイントとする。

以下の事柄は、セッション・エンドポイントの操作を可能にするプロトコルによって利用可能ないくつかの動作を説明する。本発明のプロトコルによれば、アドホック・ネットワーク内の１つ以上の二次エンドポイントを確立して、電話機１１４に送信されるビデオ番組をより適切な装置に表示して、ビデオ番組を1つの装置に送信しつつオーディオ番組を他の装置に送信するか、あるいは、それ自体はアクセスポイント１１２に接続不可能なアドホック・ネットワーク装置（図示せず）が、電話機１１４を通してネットワーク１０２を用いたセッションを受信または開始することができる。

本発明のプロトコルの基本的な動作は、セッション・エンドポイントを移動することである。例えば図２では、移動ノード１１４は図１と異なる位置にあるが、アクセスポイント１１２との接続１１３を維持している。この新たな位置では、無線データ接続（図示せず）を有するテレビジョン１１６が電話機１１４のカバーエリア内にある。このことは、例えばセッション・エンドポイントを電話機１１４からテレビジョン１１６に移動して、電話機１１４がテレビジョン１１６のプロキシ（代理）として作用するように構成することによって行うことができる。しかし、このことを行う前に、電話機１１４とテレビジョン１１６とが互いを発見し合ってセッション情報を交換して、テレビジョン１１６が電話機１１４からのデータをサポート（支援）できるか否かを判定することが望ましい。

電話機１１４からテレビジョン１１６にセッションを拡張するプロセスを、図４のフローチャートを参照しながら説明する。本発明の好適な実施例では、ステップ４１０において、電話機１１４及びテレビジョン１１６が共に装置の発見を周期的に実行して、どの装置がそれぞれのカバーエリア内にあるかを判定する。この例では、電話機１１４が装置発見プロトコルを用いてテレビジョン１１６を発見する。このプロトコルは、例えばブルートゥース（登録商標）ワイヤレス・コミュニケーション・スタンダード（Bluetooth Wireless Communication Standard：ブルートゥース無線通信規格）用に規定されたデバイス・ディスカバリー・プロトコル（Device Discovery Protocol）と同様にすることができる。あるいはまた、他の装置発見技術を用いることができる。例えば、各装置が、関連するすべての情報を含む装置記述子を維持して、他の装置からの要求に応答してこの記述子を伝えることができる。あるいはまた、要求を送信する代わりに、各装置が単純に周期的に、記述子を送信し他の装置によって送信される記述子を受信して、そのカバーエリア内にある装置の特性を測定することができる。これらのプロトコルによれば、装置の発見は装置能力の交換を含むことができる。

ステップ４１０において実行した装置発見が装置能力の交換を含まない場合には、ステップ４１２に示すように、装置どうしがその能力を交換することが望ましい。装置能力の交換では、各装置が、例えばこの装置についての情報、例えば表示サイズ、メディア・エンコーダ／デコーダ（コーデック）、及び帯域を送信することができる。この交換は、1つ以上のパケットを、エンドポイントと発見された装置の少なくとも一部との間で転送して、これにより現在のエンドポイント・ノード、例えば電話機１１４が、そのカバーエリア内の他の装置の能力を発見することができる。

以下に説明するように、装置能力の交換によって得られる情報が、ステップ４２０、即ち以下に説明する制御シグナリング（通信制御信号のやり取り）及びセッション記述交渉のステップにおいて得られる場合には、代わりの経路４１１の点線で示すように、装置能力交換のステップ４１２を省略することができる。

本発明の好適例では、各無線装置が装置発見要求パケットを周期的に伝えることができる。カバーエリア内にある各装置がこの要求を受信すると、この装置は要求を出している装置と同期して、この装置自体についての情報を含む発見応答を、要求を出している装置に送信する。図２に示す例では、電話機１１４が装置発見要求パケットを送信すると、このパケットはテレビジョン１１６によって受信されて、テレビジョン１１６は電話機１１４と通信を同期させて、（図３に示す）電話機１１４とのリンク１１５を確立させ、そしてテレビジョン１１６自体についての情報を電話機１１４に送信する。要求を出している装置は、装置発見要求に応答して受信した情報を、この装置のカバー範囲内にあるすべての装置のリスト、及びこれらの装置の能力を含む内部テーブル（表）に記録する。

ブルートゥース・システムでは、装置発見は片方向通信である。各装置は他の装置と独立して、自分のカバーエリア内の装置を発見する。従って、図２に示す例では、電話機１１４がテレビジョン１１６を発見する幾分後（あるいは幾分前）に、テレビジョン１１６が電話機１１４、及びテレビジョン１１６のカバーエリア内にある他のあらゆる装置を発見する。従って、ステップ４１０の後には、電話機１１４の装置リスト内にテレビジョン１１６があり、そしてその逆もなされている。上述したように、装置能力の交換は、装置発見ステップの一部とすることができ、独立したステップ４１２において実行することもでき、そして装置能力の交換が装置発見ステップ４１０の一部として実行される場合、あるいは装置能力交換から得て使用する情報が以下に説明する制御シグナリング及びセッション記述交渉ステップ４２０の期間中に得られる場合には、代わりの経路４１１で示すように不要にすることもできる。

セッション発見ステップ４１４は、各々の装置が、そのカバーエリア内の他の装置が関係するあらゆるセッションの記述を得ることを可能にする。このことはステップ４１２において実現され、このステップでは、各装置が、この装置と共に登録された装置毎の現在のセッション情報を要求する。本発明によれば、各装置が、例えばセッション記述プロトコル（SDP：Session Description Protocol）によって指定されたセッション記述を維持する。このプロトコルはインターネット規格であり、リクエスト・フォー・コメント（RFC：Request for Comment）2327に記載されている。この規格は、装置によって維持されるセッション記述子を規定し、これらの記述子は、この装置が現在関係しているすべてのセッションを、エンドポイントとして、あるいはマルチホップ・リンクにおける転送ノードとして記述する。本発明は、SDPを用いてセッション記述を提供するものとして説明されているが、他のプロトコルを用いてセッション特有の情報をセッション記述子内に維持することも考えられる。本発明の好適な実施例は、通信中の２つの装置にこれらの装置のセッション記述子を交換させることによってセッション発見を実現する。

しかし、図４に点線４１３で結んで示すように、セッション発見ステップ４１４は随意的である。装置能力情報については、以下に説明する制御シグナリング及びセッション記述交渉ステップ４２０においてセッション記述を得ることができる。

ステップ４１４の後に、あるいはそれぞれセッション発見ステップ４１４及び／または装置能力交換ステップ４１２を省略した場合にはステップ４１２または４１０の後に、ユーザがセッションの拡張を要求するステップ４１６を実行する。以下に説明するように、この拡張は移動ノード１１４から反応的（リアクティブ）に要求することもでき、あるいは、移動ノード１１４、ローカルノード１１６、またはさもなければトランザクションに含まれない他のノード（図示せず）から先読み的（プロアクティブ）に要求することもできる。ステップ４１６の後には、ユーザが拡張を要求しない場合にはステップ４１８で動作を終了する。本実施例ではユーザがセッション拡張を要求することを説明しているが、ユーザのソフトウェア・エージェントがこの要求を自動的に行うことも考えられる。

ステップ４１６において、ユーザがセッション・エンドポイントの拡張を要求する場合には、制御はステップ４２０に移動し、ステップ４２０では、移動ノード１１４とローカルノード１１６との間で制御シグナリングが発生する。このステップは、移動ノード１１４とローカルノード１１６との間の通信を確立し、そしてセッション記述を交換する。制御シグナリング及びセッション記述交渉は、以下に説明するセッション・エンドポイント・マネージメント・プロトコル（SEMP：Session Endpoint Management Protocol）である。制御シグナリングは接続が確立される際に発生し、セッション交渉はセッション記述が交換される際に発生する。ローカルノードは、セッション記述を受信した後に、移動ノードによって供給されるデータを受信して適切に処理するように自分自身を構成する。例えば、送信されるデータパケットがMPEG-2データストリームを表現する場合には、テレビジョン１１６は、受信したパケットをMPEG-2トランスポート・デコーダに向けるように自分自身を構成することができる。

ステップ４２０の後に、図４に示すプロセスはステップ４２２を実行し、このステップはエンドポイントを移動ノード１１４からローカルノード１１６に拡張または移動する。エンドポイントを拡張した直後に、ステップ４２４では、移動ノード１１４がローカルノード１１６のプロキシとして構成され、ステップ４２６では、移動ノード１１４は、応対ノード１００から受信したデータパケットをローカルノード１１６に渡すが、さもなければ、応対ノード１００にとってはセッション・エンドポイントとして見える。

なお、上述したエンドポイントのMOVE（移動）動作は、エンドポイントの移転ではなく、一次エンドポイントによる二次エンドポイントの定義である。図３に示す例を参照すれば、応対ノード１００は電話機１１４をエンドポイントとして見続ける。テレビジョン１１６を二次エンドポイントとして確立した後に、電話機１１４はテレビジョン１１６のプロキシとして作用し、応対ノード１００から受信したすべてのデータを、同期接続１１３経由でテレビジョン１１６に送信する。

上述したように、エンドポイントのMOVE動作は、反応的にも先読み的にも開始することができる。反応的な拡張の例は、ユーザが移動電話機１１４上のビデオ・コンテンツを見ながら部屋に入る際である。ユーザはテレビジョン１１６を見ると、反応的に電話機１１４に、セッション・エンドポイントをテレビジョン１１６に拡張する命令をする。このことは例えば、電話機１１４のキーパッド上のボタンを押すことによって、あるいは電話機のディスプレイ（表示部分）の感応領域に触れることによって行うことができる。この反応的なステップは、図４のステップ４１６に相当する。

エンドポイント拡張の先読み的な開始の例は、以下のように説明することができる。ステップ４１４においてセッション記述を交換した後に、テレビジョン１１６が、ビデオデータを表示中のセッションに電話機１１４が係っていることを発見した場合には、テレビジョン１１６はユーザに対して先読み的にメッセージを表示して、セッションを電話機１１４からテレビジョン１１６に移動すべきか否かを問い合わせる。このプロンプト（入力促進）に対するユーザの反応が、上述したステップ４１６の結果である。テレビジョンが先読み的にメニューを表示する代わりに、ユーザからのセッションを転送するコマンドに応答してメニューを表示することもできる。このことはユーザがコマンドを確認することを可能にする。

アドホック・ネットワーク内の電話機１１４でもテレビジョン１１６でもない装置も、エンドポイントのMOVE（移動）動作を開始することができる。例えば、ユーザが、アドホック・ネットワーク内のノードとして構成されたパーソナル・ディジタル・アシスタント（PDA：Personal Digital Assistant：個人用携帯型情報機器）（図示せず）を持つ場合には、このPDAは、電話機１１４及びテレビジョン１１６に直接、セッション・エンドポイントを拡張させるか、あるいは、セッションを電話機１１４からテレビジョン１１６に拡張すべきか否かについてユーザに問い合わせるべく使用することができる。ユーザがセッションを拡張することを決定した場合には、PDAは、ステップ４２０の制御シグナリング及びセッション記述交渉を開始することができる。

上述したように、本発明を具現するプロトコルは、OSIネットワークモデルに準拠して規定されるアプリケーション層の一部として実現することができる。図５に、本発明のプロトコルをエコーネット（Echo Net：登録商標）ネットワーク５１０、ブルートゥース・ネットワーク５１２、またはIPネットワーク５１４で実現可能な方法を示す好適なプロトコル・スタック（積層）を示す。エコーネット及びブルートゥースは共にトランスポート・プロトコルを規定しており、図５には示していない。好適なIPネットワークはユーザ・データグラム・プロトコル（UDP：User Datagram Protocol）５１５をトランスポート・プロトコルとして用いる。UDPはインターネット規格であり、RFC（Request for Comment）７６８に記載されている。IPネットワークでは、トランスポート層は、ユニバーサル・プラグアンドプレイ（UPnP：Universal Plug and Play：家電製品とコンピュータのネットワーク接続規格）を実現するために使用可能な装置発見または装置能力交換（DD／DCE：Device Discovery／Device Capability Exchange）プロトコル５１６も含むことができる。

本発明によるセッション・エンドポイント管理プロトコル５１７は、スタック内において、装置のアプリケーション層内のソフトウェアとして、あらゆるこれらのトランスポート・プロトコルの上位にある。上述したように、アプリケーション層は、セッション記述交換（SDE：Session Description Exchange）プロトコル５２２及び／またはセッション記述プロトコル（SDP）５１８を含むこともできる。他のアプリケーション５２０は、プロトコル・スタック内において、アプリケーション層内の本発明のプログラムの上位に存在する。図には示していないが、考えられることとして、セッション・エンドポイント管理プロトコルを実現するソフトウェアは、アプリケーション層内の他のプログラム５２０がセッション・エンドポイント管理ソフトウェアの特徴的機能（フィーチャ）にアクセスすることを可能にするための適切なアプリケーション・プログラム・インタフェース（API：Application Program Interface：アプリケーション・プログラムとOSとの間のインタフェース）を含むことができる。セッション・エンドポイント管理プロセスをOSIモデルのアプリケーション層内で実現することの代わりに考えられることとして、セッション層がアプリケーション層と区別されている際には、このソフトウェアをセッション層内で実現することができる。

本発明は、拡張中の「セッション」が完全にエンドポイント・ノード１１４内にある際にも用いることができる。このことは例えば、プロセッサ及びトランスデューサを有し、データがプロセッサからトランスデューサに送信される装置において発生し得る。プロセッサからトランスデューサへのデータの送信は、公式なセッションが存在しなくても、論理セッションであると考えられる。このモデルを用いれば、前記プロセッサは論理的な応対ノードであり、前記トランスデューサは論理的なエンドポイントであると考えることができる。例えば、図２に示すノード１１４が無線能力を有する携帯ビデオゲームであったとすれば、このノードは、論理的な応対ノード（即ち、ビデオゲームのソフトウェアを実行するプロセッサ）及び論理的なエンドポイント（即ち、ビデオゲームのディスプレイ（表示装置））を共に含む自己完結論理セッションであると考えることができる。ユーザは、部屋に入る際に、ビデオゲームのキーパッドを使用し続けてゲームをしながら、このビデオゲームをテレビジョン１１６上に表示したいことがある。本発明によれば、ノード１１４は、データパケットがテレビジョン１１６に転送されるようにそのエンドポイントを移動して、このゲームがビデオゲームのディスプレイの代わりにテレビジョン１１６上に表示されるようにすることができる。実際のセッションが存在しなくても、上述したように、移動ノード１１４はなおも、セッション記述を生成してローカルノード１１６に転送し、そしてセッションデータをローカルノード１１６に転送して処理させることができる。

本発明の好適な一実施例では、アドホック・ネットワーク内のあらゆる装置が、セッション・エンドポイント管理プロトコル（SEMP）に準拠した動作を開始することができる。開始装置（イニシエータ）は、ローカルセッションに関連してもしていなくてもよい。好適なSEMPプロトコルには次の６つの動作が規定されている：
MOVE、COPY、SPLIT、MERGE、INCOMING SESSION、及びOUTGOING SESSION。

MOVE（ムーブ：移動）動作は、エンドポイント装置を変更するために用いることができる。この動作は上述したエンドポイント拡張動作であり、ユーザが、自分の環境内にありセッションを継続するのに最も適した装置を選択することを可能にする。

COPY（コピー：複写）動作は、ユーザが複数のエンドポイント装置を１つのセッションに使用したい際に用いることができる。この動作は、他の人または装置が既存のセッションに加わることを可能にする。上述した実施例では、COPY動作は、ユーザがビデオ番組（プログラム）を電話機１１４上で見ながら、このビデオ番組をテレビジョン１１６上にも表示することを可能にする。

SPLIT（スプリット：分割）動作は、１つの既存のセッション・エンドポイントを２つ以上の装置向けに分割するために用いることができる。この動作では、単一のセッションが２つの分割セッションに分割される。この動作はセッション・エンドポイントを他の複数の装置に移動するが、これらの分割セッションの１つを元の装置に残すことができる。上述した例では、テレビジョン１１６に加えて、移動電話機１１４のカバー範囲内にオーディオシステム（図示せず）が存在したとすれば、電話機１１４はセッションを分割して、これによりテレビジョン１１６がビデオデータ用の二次エンドポイントになり、このオーディオシステムがオーディオデータ用の二次エンドポイントとなる。

MERGE（マージ：併合）動作は、複数装置上の２つの分割セッション・エンドポイントを併合して単一装置上の単一のエンドポイントにするために用いることができる。MERGE動作は、２つの独立したセッション・エンドポイントを単一の装置上で併合するためにも用いることができる。上述した例では、テレビジョン１１６がビデオデータ用の二次エンドポイントでありオーディオシステムがオーディオデータ用の二次エンドポイントであるようにセッションが分割されたとすれば、MERGE動作は、オーディオ・セッションをテレビジョン１１６に移転して、テレビジョン１１６がこのセッションのオーディオデータ及びビデオデータを共に取り扱うようにするために用いることができる。

INCOMING SESSION（インカミング・セッション：入セッション）動作は、他のネットワーク（例えばIPネットワーク１０２）に接続されていない装置が、IPネットワーク上に送信されるセッション（例えば電話呼び出し）を取得するために用いることができる。この装置はネットワーク１０２に接続されていないので、この呼びを直接受信することはできない。好適な実施例では、ネットワーク１０２からの入りの呼びを、ある装置のカバーエリア内のあらゆる装置、例えば移動電話機１１４に知らせ、移動電話機１１４はネットワーク１０２に接続することができるが、アドホック・ネットワーク経由で他の装置と通信することもできる。

OUTGOING SESSION（アウトゴーイング・セッション：出セッション）動作は、装置が、直接接続されていないネットワーク（例えばIPネットワーク１０２）上でセッション（例えば電話呼び出し）を開始するために用いることができる。アドホック・ネットワーク内のあらゆる装置が、アドホック・ネットワークに直接接続された装置にアドホック・ネットワークを通して接続することによって、OUTGOING SESSION動作を開始することができる。

これらの動作の各々の詳細な説明を行う前に、SEMPプロトコルの全体的なフォーマットを説明することが有用である。SEMPメッセージは、クライアントからサーバーへの要求とすることも、サーバーからクライアントへの応答とすることもできる。SEMPメッセージのフォーマットは、上述したSIP（Session Initiation Protocol：セッション開始プロトコル）のフォーマットと類似している。両方の種類のメッセージが、開始行（スタートライン）、１つ以上のヘッダフィールド、ヘッダフィールドの終わりを示す空行（エンプティライン）、及び随意的なメッセージ本文を含む。このメッセージ構造を次の表１に示す：
表１
generic-message = start-line （generic message：汎用メッセージ）
*message-header
CRLF
*[message-body]
start-line = Request-Line | Status-Line

この例では、開始行（start-line）、各メッセージ・ヘッダ（message-header）行、及び空行が、キャリッジリターン−ラインフィード（CRLF）のシーケンス（文字列）で終了している。なお、メッセージ本文（message-body）がない際には、空行（即ちCRLF）を送信する。

好適なセッション・エンドポイント管理プロトコルにおける要求は、要求行（Request-Line）を開始行用に持つことによって区別される。要求行は、方法名、要求エンドポイントID（Request-Endpoint-ID）、及び単一の空白文字（SP）によって分離されたプロトコル・バージョンを含む。

要求行はCRLFで終わる。好適なプロトコルでは、行の終わり（end-of-line）のCRLFシーケンス以外ではCRまたはLFが認められない。いずれの要素においても空白の線（LWS：Linear White Space）は認められない。要求行（Request-Line）のフォーマットを次の表２に示す：
表２
Request-Line = Method SP Request-Endpoint-ID SP SEMP-Version CRLF
Method: 好適なSEMPでは次の７つの方法が規定されている：
1) 情報交換用のINFO、2) MOVE、3) COPY、4) SPLIT、5) MERGE、6) セッション・エンドポイントを操作するためのCONNECT（接続）、7) ローカルセッションを終了するためのTERMINATE。
Request-Endpoint-ID：要求エンドポイントID（Request-Endpoint-ID）フィールドはエンドポイント装置の識別子である。この識別子は、この要求が伝えられる装置を示す。好適な実施例では、装置のIPアドレスをRequest-Endpoint-IDとして用いる。
SEMP-Version：要求メッセージ及び応答メッセージは共に、準拠の要求を示すSEMPのバージョンを含む。この仕様に準拠するために、２つの装置間のSEMPメッセージは、互換性のあるSEMPのバージョン、例えば”SEMP／1.0”を含むことが望ましい。

SEMP応答は、その開始行としてStatus-Line（状態行）を持つことによって要求から区別される。Status-Lineは、プロトコルのバージョン、これに続く数字のStatus-Code（状態コード）及びこれに関連する本文の字句（textual phrase）から成り、これらの各要素は単一のSP文字によって分離される。最後のCRLFシーケンス以外はCRまたはLFは認めらない。SEMP応答の構造を次の表３に示す：
表３
Status-Line = SEMP-Version SP Reason-Phrase CRLF
Status-Code：Status-Codeは、要求を理解し満たそうとする試みの結果を示す３桁整数の結果コードである。
Reason-Phrase：Reason-Phrase（理由の字句）は、Status-Codeの短い本文記述を与えることを意図したものである。

Status-Codeはオートマトン（自動装置）による使用を意図したものであり、これに対しReason-Phraseは人間のユーザ用を意図したものである。クライアントはReason-Phraseを検査あるいは表示することは要求されない。

Status-Codeの最初の数字は応答のクラスを規定する。後の２つの数字は分類の役割を持たない。この理由により、200〜299のStatus-Codeを有するあらゆる応答を”2xx応答”と称し、400〜499のStatus-Codeを有するあらゆる応答を”4xx応答”と称する、等である。SEMP／1.0では、前記最初の数字として次の表４に示す３つの数字があり得る：
表４
2xx：Success（成功） -- 動作が良好に受信され、理解され、受け入れられた；
4xx：Client Error（クライアント・エラー） -- 要求が誤った文字を含むか、あるいはこのサーバーで満たすことができない；
5xx：Server Error（サーバー・エラー） -- サーバーが明らかに有効な要求を満たし損なった。

好適なSEMPヘッダフィールドは、構文（シンタックス）及び意味体系（セマンティクス）の両方の点でSIPヘッダに類似している。SEMPは、コンマで区切られたリスト中の、同じフィールド名及びフィールド値を有する複数のヘッダフィールドを組み合わせて１つのヘッダフィールドにすることができることも明記している。特に、次の表５に示す形式の文法を有するあらゆるSEMPヘッダは、同じ名前のヘッダフィールドを組み合わせてコンマで区切られたリストにすることを可能にする：
表５
header = “header-name” HCOLON header-value * (COMMA header-value)
（header：ヘッダ、header-name：ヘッダ名、header-value：ヘッダ値、HCOLON：コロン、COMMA：コンマ）。

好適なヘッダフィールドは、SIPを記述したRFC 2822の2.2章に記載されているのと同じ汎用ヘッダ・フォーマットに準拠する。各ヘッダフィールドは、フィールド名、及びこれに続くコロン（”：”）及びフィールド値から成る。

メッセージ・ヘッダ用の正式な文法は、コロンのどちら側にも任意数の空白文字を許容するが、その実現は、フィールド名とコロンとの間の空白を回避して、コロンとフィールド値との間に単一の空白文字（SP）を用いることが望ましい。許容可能なシンタックスを次の表６に示す：
表６
Content-Length： 1024 （Content Length：コンテント（内容）長）
Content-Length ： 1024
Content-Length ：1024
Content-Length：1024

表６に示すすべてのフォーマットが有効かつ等価であるが、最後のエントリが好ましい形式である。

異なるフィールド名を有する複数のヘッダフィールドの相対的な順序は重要ではない。複数のヘッダの実現は、同じ名前を有する複数のヘッダフィールド行の、１行当たり単一値またはコンマで区切られた値のフォーマットのあらゆる組合せを望ましいように処理することができる。

好適なプロトコルでは、ヘッダフィールド値のフォーマットがヘッダ名向きに規定されている。このフォーマットは、TEXT-UTF8オクテット（８ビット）の不透明な列にすることも、空白、トークン、区切り記号（セパレータ）、及び引用ストリング（文字列）の組合せにすることもできる。既存のヘッダフィールドの多くは、次の表７に示す、値、及びこれに続くセミコロンで区切られたパラメータ名、パラメータ値の対のシーケンスの一般形式を固守している：
表７
field-name：field-value * (;parameter-name=parameter value)
（field-name：フィールド名、field-value：フィールド値、parameter-name：パラメータ名、parameter-value：パラメータ値）。
好適な実施例では、任意数のパラメータ対をヘッダフィールド値に付けることができても、あらゆる所定のパラメータ名は１回しか出現しないことが望ましい。

好適なSEMPは、共通のヘッダフィールド名を省略形で表現するメカニズムも提供する。このことは、さもなければメッセージが利用可能なトランスポート（搬送手段）上で搬送するには大きすぎになった際に有用である。これらのコンパクト（小型化）形は以下に説明する。コンパクト形は、メッセージの意味体系（セマンティクス）を変更することなしに、より長い形式のヘッダフィールド名にいつでも置き換えることができる。好適な実施例では、ヘッダフィールド名は同じメッセージ内に長い形式及び短い形式の双方で出現し得る。

すべてのSEMPメッセージ、即ち要求も応答も、メッセージ本文を含み得る。好適なSEMPは、Content-Number（コンテント（内容）の数）ヘッダフィールドが複数の本文が存在することを示す場合には、メッセージが複数の本文を含むことを可能にする。

好適な実施例では、Content-type（コンテントの種類）ヘッダフィールドが、メッセージ本文のインターネット媒体の種類を示す。本文が圧縮のような何らかの符号化を施されている場合には、そのことはContent-Encoding（コンテント符号化）ヘッダフィールドによって示され、さもなければContent-Encodingは省略されている。適用可能であれば、メッセージ本文の文字の組をContent-Typeヘッダフィールド値の一部として示す。

SEMPメッセージは、二進数（バイナリ）の本文あるいは色々な種類の本文を含むことができる。送信者がcharset（文字セット）パラメータを明示的に指定していない際には、媒体の副種類である”text（テキスト）”型は、デフォルトのcharset値”UTF-8”を持つように規定されている。

Content-Lengthヘッダフィールドは、本文の長さをバイト単位で指定する。好適なSEMPについてのこのヘッダフィールドの内容を以下に説明する。

Content-Number（コンテント数）ヘッダフィールドは、メッセージが複数の本文を持つことを示すために用いられる。メッセージが１つの本文しか持たない場合には、このヘッダフィールドを省略することができる。

上述したように、表２を参照すれば、SEMPはセッション・エンドポイントを管理するためのいくつかの「方法」を規定している。これらの方法は、プロトコルを用いて実行する動作に準拠し、SEMP要求行内で用いられ、SEMP要求に応答してとるべき行動を示す。以下で行う好適な実施例の説明では、SEMPメッセージをその方法名（即ちINFO、MOVE、COPY、SPLIT、MERGE、CONNECT、及びTERMINATE）で参照する。

SEMP_INFO（SEMP情報）メッセージは情報を交換するために用いる。交換可能な情報は、セッション記述、一次エンドポイント・コンテクスト（関係する状況）、及びセッション・コンテクストである。好適な実施例では、このメッセージはInfo-Type（情報の種類）ヘッダフィールド及びInfo-State（情報の状態）ヘッダフィールドを共に含む。Info-Typeフィールドは、このメッセージによって搬送されるセッション記述、一次エンドポイント・コンテクスト、及びセッション・コンテクストを示す。Info-Stateフィールド値は、”Inquire（問合せ）”または”Indicate（指示）”のいずれかとすることができる。Inquire状態では、他のノードから情報を要求し、その返答として、要求した情報を伴った応答メッセージを受信する。Indicate状態では、ノードが他のノードに情報を提供し、その応答メッセージ中で、他のノードがサポート（支援）されていること、あるいはサポートされていないことの指示を受信することができる。システムにおいてこれに代わるプロトコルが利用可能である場合には、このメッセージは不要になり得る。

SEMP_MOVE（SEMP移動）メッセージは、セッション・エンドポイントを他のノードに移動するために用いる。この動作は以上で詳細に説明している。好適な実施例では、このメッセージは、MOVE動作用のソース（移動元）ノード及びデスティネーション（移動先）ノードを指定するそれぞれFrom及びToヘッダフィールドを含む。ソースノードまたはデスティネーションノードのいずれかがこのメッセージを開始することができるが、アドホック・ネットワーク内の他のノードもメッセージを開始することができる。

SEMP_COPY（SEMPコピー）メッセージは、セッションのコピーを他のノード上に作るために用いる。この好適なメッセージは、現在のセッション・エンドポイント、及びセッションをコピーする先の二次エンドポイントを指定するそれぞれFrom及びToヘッダフィールドを含む。このCOPY動作に関係するいずれかのノード、並びにアドホック・ネットワーク内の他のノードがこのメッセージを開始することができる。

SEMP_SPLIT（SEMP分割）メッセージは、既存の単一のセッション・エンドポイントを２つ以上の装置向けに分割するために用いる。この好適なメッセージはFrom及びToヘッダフィールドを含む。いずれのノードもこのメッセージを開始することができる。

SEMP_MERGE（SEMP併合）メッセージは、２つの装置上の２つの分割セッションを併合して単一装置上の単一セッションにするために用いる。好適な実施例では、このメッセージはFrom及びToヘッダフィールドを含む。アドホック・ネットワーク内のあらゆるノードがこのメッセージを開始することができる。

SEMP_CONNECT（SEMP接続）メッセージは、入りの呼びのアドホック内のノードを通知するために、あるいは他のノードに出の呼びを行わせるために用いる。

SEMP_TERMINATE（SEMP終了）メッセージは、装置間のアドホック・ローカルセッションを終了して、単一または分割セッションに割り当てられたリソース（資源）を解放するために用いる。このメッセージは、一次エンドポイント、及びこの一次エンドポイントに関連するセッションを終了するために用いる。好適な実施例では、このメッセージはTerminate-Target（ターゲット（目標）終了）ヘッダフィールドを含む。アドホック・ネットワーク内のあらゆるノードがこのメッセージを開始することができる。

好適なSEMPプロトコルにおいて用いるヘッダフィールド、及びそのコンパクト形は次の表８に記載する通りである：
表８
（Info-Type（情報種類））
Info-TypeヘッダフィールドはSEMP_INFOメッセージの目的を識別する、というのは、セッション記述の交換、一次エンドポイント・コンテクストの交換、及びセッション・コンテクストの交換に使用されるからである。
（Info-State（情報状態））
Info-StateヘッダフィールドはSEMP_INFOメッセージの状態を示す。このフィールドは”Inquire”及び”Indicate”の値を持つことができる。
（Session-ID（セッションID））
Session-IDヘッダフィールドは特定のセッションを一意的に識別する。最初の一次エンドポイントが、この識別子をあらゆるSEMP動作用に割り当てる。Session-Idのコンパクト形はｉである。
（Primary-Endpoint（一次エンドポイント））
Primary-EndpointヘッダフィールドはPE（一次エンドポイント）のアドレス（番地）を保持する。Primary-Endpointヘッダフィールドのコンパクト形はｐである。
（Previous-Node（前のノード））
Previous-Nodeヘッダフィールドは、前のノード、言わばデータを転送するアプリケーションレベルを実行するノードのアドレスを示す。このフィールドは、以下に説明するルート（経路）の最適化に用いることができる。
（From（...から））
Fromヘッダフィールドは、SEMPメッセージを送信したノードのアドレスを保持する。Fromヘッダフィールドのコンパクト式はｆである。
（To（...まで））
ToヘッダフィールドはSEMPメッセージの宛先アドレスを保持する。この値はメッセージを受信するノードを識別する。Toヘッダフィールドのコンパクト形はｔである。
（Terminate-Target（終了ターゲット（目標）））
Terminate-Targetヘッダフィールドは、当該ノードのセッションを終了することになるノードのアドレスを保持する。
（Content-Length（コンテント（内容）長））
Content-Lengthヘッダフィールドはメッセージ本文（message-body）のサイズ（大きさ）を示す。このサイズは１０進数のオクテットとして受信者に送信される。アプリケーションは、実体の媒体種類にかかわらず、このフィールドを用いて転送すべきメッセージ本文のサイズを示すことが望ましい。好適な実施例では、メッセージ本文のサイズは、ヘッダフィールドをメッセージ本文から分離するためのCRLFを含まない。０以上のあらゆるコンテント長（Content-Length）が、このフィールドにとって有効な値である。メッセージ中に本文が存在しない場合には、Content-Lengthヘッダフィールドは０の値を有する。メッセージ中に複数の本文が存在する場合には、Content-Lengthヘッダフィールド値はこれらの本文と同じ順序である。このヘッダフィールドのコンパクト形はｌである。
（Content-Type（コンテントの種類））
Content-Typeヘッダフィールドは、受信者に送信されるメッセージ本文の媒体の種類を示す。Content-Typeヘッダフィールドは、メッセージが本文を有する際に常に存在する。このヘッダフィールドのコンパクト形はｃである。
（Content-Number（コンテント数））
Content-Numberヘッダフィールドは、受信者に送信されるメッセージに含まれるメッセージ本文の数を示す。アプリケーションはこのフィールドを用いて、転送すべきメッセージ本文の数を示すことが望ましい。Content-Numberヘッダフィールドは、メッセージが２つ以上のメッセージ本文を含む場合に存在する。本文どうしの間には区切り記号は存在しない。Content-Numberヘッダフィールドは区切りに使用可能である。このヘッダフィールドのコンパクト形はｎである。

応対ノードがエンドポイントとして認知しているノードを一次エンドポイントと称する。一次エンドポイントは、セッションが有効である間は決して変化しない。一次エンドポイントを他の装置に変更するためには新たなセッションを確立する必要があり、SIPのようなセッション確立プロトコルを用いて新たなセッションを確立することができる。一次エンドポイントを変更するプロセスでは、次の一次エンドポイントとなる新たな装置が、現在の一次エンドポイントと一次エンドポイント・コンテクスト（PEC：Primary Endpoint Context）を交換しなければならない。SEMPメッセージの大部分は一次エンドポイントのアドレスを含む。従って、このセッションに関係するあらゆるノードが一次エンドポイントと通信することができる。

PECは、アドホック・ネットワーク内の情報を記述する情報である。好適なSEMPはPECの内容を規定しない。一次エンドポイントはPECを有し、このPECは、新たなセッションが確立されて一次エンドポイントが変更される際に、あらゆる新たな一次エンドポイントに送信される。

PECは、アドホック・ネットワーク内のいずれかのノードが新たなセッションを確立しようとする前に、応対ノードとの間で交換されることが望ましい。PECの使用はSEMPに限定されないが、SEMP_INFOメッセージはPECを搬送するために用いることができる。

好適なSEMPは、各エンドポイントの論理動作を管理する。しかし、SEMPはアドホック・ネットワーク内の装置間のメッセージのルーティング（経路設定）には影響しない。例えばMOVE動作の後に、アプリケーション層は、一次エンドポイントが受信するあらゆるデータを二次エンドポイントに送信する。この転送を取り扱うために、一次エンドポイントと二次エンドポイントとの間にルーターを持つことが望ましいことがある。しかし、論理的には、二次エンドポイントが直接一次エンドポイントに接続される。好適なSEMPは、この論理接続のみに関係するので、アドホック・ネットワークがルート（経路）最適化メカニズムを含む際にも動作する。

図６Ａ〜６Ｈに、本発明によるルート最適化の２つの例を示す。図６Ａ〜６Ｇは、アドホック・ネットワーク内の４つの装置Ａ、Ｂ、Ｃ、及びＤを示す。この例では、装置Ａが一次エンドポイント（PE）である。図６Ａでは、装置Ｂを二次エンドポイント（SE：Second Endpoint）として定義することによってセッション・エンドポイントを移動する好適なSEMPによるMOVE動作が実行されている。装置ＡとＢとの間のローカルセッションが確立され、装置Ａは単に、アプリケーション層においてセッションデータを装置Ｂに転送する。なお、アドホック・ネットワーク内でノードＢに対する先行ノードである装置Ａはルーターとして動作しない。図６Ｂでは、図６Ａに示す構成から始まって、装置Ｂはセッション・エンドポイントを装置Ｃに移動しようとする。メッセージは装置Ｂから装置Ｃに送信されているが、ルーティング機能を含む装置Ｃは、装置Ａからのセッションに直接アクセスできることを認知している。この例では、装置Ｃは、装置ＢからのMOVEメッセージに応答せずに、このメッセージからPrevious-Nodeフィールドを読み出し、ノードＡを装置Ｃのカバーエリア内にあるノードとして識別してMOVEメッセージをノードＡに送信し、ノードＡがセッションをノードＢの代わりにノードＣに移動することを要求する。結果的に、ルート最適化メカニズムにより、ローカルセッションは装置ＢとＣとの間ではなく、装置ＡとＣとの間に確立される。図６Ｃでは、図６Ｂに示す構成から、装置Ｃはローカルセッションを装置Ｄに移動しようとする。この動作を実行する２つのシナリオを考えることが有用である。装置Ｂまたは装置Ｃのいずれかがルーターとして動作可能な場合には、装置Ｄは論理的に装置Ａへのローカルセッションを確立することができる。装置ＢまたはＣのどちらもルーターとして動作可能でない場合には、セッションは装置Ｃから装置Ｄに移動して、装置Ｄの先行ノードである装置Ｃは、セッションデータを装置Ｄに転送するアプリケーションレベルを実行する。

図６Ｄ〜６Ｇに他のルート最適化の例を示す。これらの図は、パーソナルエリア・ネットワーク（PAN：Personal Area Network：個人所有物間のネットワーク）内の４つのノードを示す。図６Ｄでは、PE、ノードＡ、及びノードＢがそれぞれ、次のノードへのアプリケーション転送を行う。図６Ｄでは、ノードＣがローカルセッションをノードＤに移動しようとする。図６Ｄ〜６Ｇに示すように、ノードＤはノードＡ、Ｂ及びＣのカバーエリア内に位置する。ノードＣからのSEMP MOVEメッセージは、ノードＣの先行ノード、即ちノードＢについての情報を、そのPrevious-Nodeフィールドに含む。結果的に、ノードＤがこのMOVEメッセージを受信すると、ノードＤがノードＢのカバーエリア内にあり、ルート最適化が利用可能であることを認知する。図６Ｅに示すように、この情報を用いて、ノードＤはノードＢにMOVEメッセージを送信して、ノードＢのセッションをノードＤに移動することを要求する。ノードＢは、その先行ノード（即ちノードＡ）のアイデンティティ（身元、正体）を含むアクノレッジ（ACK：確認応答）メッセージでこれに返答する。ノードＤがACKを受信すると、ノードＤがノードＡのカバーエリア内にあり、さらなるルート最適化が利用可能であることを認知する。こうして、図６Ｆに示すように、ノードＤはMOVEメッセージをノードＡに送信する。最後に、図６Ｇに示すように、ローカルセッションがノードＡとＤの間に確立され、ルート最適化が完了する。

図６Ｈに、ルート最適化を促進する上述した好適なSEMPの拡張を示す。この図は、好適なSEMP_MOVE動作を用いることによって作成されたアドホック・ネットワークを示す。ノードＰは一次エンドポイントであり、応対ノードCNへの接続を有する。ノードS1, S2, S3,...,SNは、SEMP_MOVE動作を用いて作成したそれぞれの二次エンドポイントである。図６Ｈに示す例では、ｎ＋１個の二次エンドポイントが存在し、従って、アドホック・ネットワークを規定する一連のノード中のｎ＋１個のノードを規定する。ノードSn+1、即ちこれら一連のノードの最終ノードが、このセッションの実際のエンドポイントである。

上述したように、ノードSnは（Primary-Endpointフィールドから）一次エンドポイント及び（Previous-Nodeフィールドから）ノードSn-1のみを認知することができ、そしてこの情報をMOVEメッセージによりノードSn+1に送信することができる。従って、ノードＰとノードSn-2との間の一連のノードである他のノードの１つ、例えばノードS1は、ノードSn+1のカバーエリア内にあり、ノードSn+1はMOVE動作を開始することができない、というのは、これら他のノードについての情報を何ら有しないからである。

このことは、好適なSEMPプロトコルの拡張により解決することができる。この拡張によれば、MOVE動作が要求される際に常に、一連のノードの新たな最終ノードとなるノードが、後向き問合せパケット（例えばSEMP_ROUTE_OPTパケット）を、反復的なMOVE動作によって生成されたアドホック・ネットワークを規定する一連のノードに対して発行する。この例では、ノードSn+1がSEMP_ROUTE_OPTメッセージをノードSnに送信する。Snがこのパケットを受信した後に、SnはこのパケットをノードSn-1に転送する。最後に、後向き問合せパケットが一次エンドポイントに到来する。後向き問合せパケットはノード情報、例えばメディアアクセス（MAC：Media Access）層のアドレスを含む。この情報はノードがルートを最適化することを可能にする。例えば、ノードS2ではなくノードS1及びS3がノードSn+1のカバーエリア内にある。ノードS3がSEMP_ROUTE_OPTメッセージを受信すると、ノードS3はSnを通ってSn+1に至る経路を遮断し、同時に、SEMP_MOVEメッセージを直接Sn+1に送信する。より効率的な経路が確立される。この新たなMOVE動作の結果として、ノードSn+1はSEMP_ROUTE_OPTメッセージを発行する。この時点ではノードS3がノードSn+1と直接通信しているので、SEMP_ROUTE_OPTパケットはノードS3及びS2を通してノードS1に送信される。ノードS1がSEMP_ROUTE_OPTメッセージを受信すると、ノードS1はノードSn+1からノードS3までの経路を遮断し、同時に、SEMP_MOVEメッセージを直接ノードSn+1に送信する。こうして、最も効率的な経路が確立される。

好適なセッション・エンドポイント管理プロトコルは多種のセッションを取り扱うことができ、「セッション知らず」である。しかし、一部のセッションは、セッションの履歴的なデータを用いる。本明細書では、この履歴的なデータをセッション・コンテクストと称する。例えばセッションが、ファイルをダウンロードするためのファイル転送プロトコル（ftp：file transfer protocol）セッションであるとする。ダウンロード・プロセスの中間でMOVE動作を適用する場合には、ダウンロードされるファイルの前半は前の装置内に留まり、このファイルの後半のみが新たな装置に来る。この例では、このファイルがセッション・コンテクストであり、セッションのMOVE動作を意味あるものとするために、前記ファイルの前半をセッション・コンテクスト転送プロトコルによって前記新たな装置に送信することが望ましい。好適なSEMPはセッション・コンテクスト転送プロトコルを含まないが、１つ以上のSEMP_INFOメッセージを用いてセッション・コンテクストを転送することが考えられる。

図７、８、９、１０、１１及び１２は、SEMP動作におけるメッセージ交換トランザクションの例を示す。説明を簡単にするために、あらゆる要求メッセージが肯定応答を受信するものと仮定する。

図７Ａ〜７ＤにSEMP_MOVE動作の例を示す。これらの図では、ノードＳがソースノードであり、ノードＤがデスティネーションノードである。従って、セッション・エンドポイントはノードＳからノードＤへ移動または拡張される。ノードＯはアドホック・ネットワーク内のノードのうち、この実際の動作に関係しない（即ち、ソースノードでもデスティネーションノードでもない）ノードである。しかし、ノードＯは、動作を開始するメッセージを送信することができる。図７ＡではノードＳがMOVE動作を開始する。図７Ａに示すように、ノードＳはMOVEメッセージをノードＤに送信し、ノードＤは応答メッセージ（即ちACKメッセージ）で応答する。図７Ｂでは、ノードＯがイニシエータ（開始者）であり、ノードＳのセッションをノードＤに拡張することを要求する。ノードＯはまず、MOVEメッセージをノードＳに送信する。次に、ノードＳはMOVEメッセージをノードＤに送信する。ノードＤはノードＳにACKメッセージで応答し、そしてノードＳはノードＯにACKメッセージで応答する。図７ＣはノードＤがイニシエータであるシナリオを示し、図７ＤはノードＯがイニシエータであるシナリオを示すが、MOVEメッセージをノードＳの代わりにノードＤに送信する。

（COPY）
図８Ａ〜８Ｄに、本発明によるSEMP_COPY動作の例を示す。これらの図では、ノードＳがCOPY動作のソースノードであり、ノードＤがデスティネーションノードである。従って、セッション・エンドポイントはノードＳからノードＤにコピーされる。COPY動作が完了すると、ノードＳ及びノードＤが共にセッション・エンドポイントになる。ノードＳは一次エンドポイント（あるいは前のSEMP動作からの二次エンドポイント）であり、ノードＤは、ノードＳにおけるセッション処理をそのまま反映する二次エンドポイントである。ノードＯは、アドホック・ネットワーク内のこの実際の動作に関係しないノードである。しかし、ノードＯは動作を開始するメッセージを送信することができる。図８Ａでは、ノードＳがCOPY動作を開始する。この例では、ノードＳがノードＤにCOPYメッセージを送信し、ノードＤがACK応答メッセージで返答する。図８Ｂでは、ノードＯがイニシエータであり、まずメッセージをノードＳに送信する。ノードＳはCOPYメッセージを受信した後に、メッセージをノードＤに送信する。ノードＤはACKメッセージで応答し、そしてノードＳはノードＯにACKメッセージで応答する。図８Ｃでは、ノードＤがイニシエータである。図８Ｄでは、再びノードＯがイニシエータであるが、メッセージをノードＤに送信して、これによりノードＤはノードＳからのCOPY動作を要求することができる。

（SPLIT）
図９Ａ〜９Ｊに、本発明によるSEMP_SPLIT動作の例を示す。この図では、ノードＳがこのSPLIT動作のソースノードであり、ノードＤ1及びＤ2のそれぞれが、この動作のデスティネーションノードである。例えば、ノードＳを図３に示す移動電話機１１４とし、ノードＤ1をテレビジョン１１６とし、ノードＤ2をオーディオシステム（図示せず）とすることができる。図９Ａに示す例では、セッション・エンドポイントがノードＳからノードＤ1及びＤ2に分割される。図３に示す例の関係では、SPLIT動作において、電話機１１４のスクリーン上に表示されていたセッションのビデオ部分はテレビジョン１１６に移転され、このセッションのオーディオ部分はオーディオシステムに移転される。図９Ｂ、９Ｄ、９Ｆ、９Ｈ及び９Ｊに示す例では、ノードＯは、アドホック・ネットワーク内の、この実際の動作に関係しないが動作を開始するSPLITメッセージを送信可能なノードである。

図９Ａでは、ノードＳがSPLIT動作のイニシエータである。ノードＳはそれぞれのSPLITメッセージをノードＤ1及びＤ2に送信する。図９Ａに示す例では、ノードＤ1及びＤ2がACK応答メッセージで返答する。図９Ｂは、ノードＯがイニシエータであり、まずSPLITメッセージをノードＳに送信すること以外は図９Ａと同様の動作を表わす。このメッセージは、セッション・エンドポイントＳがそのセッションをノードＤ1とＤ2とに分割することを含む。SPLITメッセージを受信した後に、ノードＳはメッセージをノードＤ1及びＤ2に送信する。ノードＤ1及びＤ2はそれぞれのACKメッセージでノードＳに応答し、そしてノードＳはACKメッセージでノードＯに応答する。図９ＣではノードＳがイニシエータである。ノードＳはSPLITメッセージをノードＤ1に送信し、そしてノードＤ1はSPLITメッセージをノードＤ2に送信する。図９Ｃに示す構成では、ノードＤ1とＤ2とが入れ替わることも可能である。図９Ｄは、ノードＯがイニシエータであること以外は図９Ｃと同じ動作を表わす。この例では、ノードＯがまずメッセージをノードＳに送信し、そして図９Ｃを参照して説明した動作が進行する。

図９Ｅでは、ノードＤ1がイニシエータであり、まずSPLITメッセージをノードＳに送信する。次に、ノードＳがSPLITメッセージをノードＤ2に送信する。ノードＤ2はACKメッセージでノードＳに応答し、ノードＳはACKメッセージでノードＤ1に応答し、そしてノードＳからノードＤ1及びノードＤ2へ分割セッションデータの転送が開始される。図９Ｆでは、ノードＯがイニシエータであり、それ以外の動作は図９Ｅと同様である。図９Ｇでは、ノードＤ1がイニシエータであり、まずSPLITメッセージをノードＤ2に送信する。ノードＤ2は、SPLITメッセージをノードＳに送信することによって応答する。ノードＳはノードＤ2にACKメッセージで応答し、そしてノードＤ2はノードＤ1にACKメッセージで応答する。この２番目のACKメッセージの後に、ノードＳからノードＤ1及びＤ2へのデータ転送を開始することができる。図９Ｈは、ノードＯがイニシエータであること以外は図９Ｇと同様である。図９Ｉでは、ノードＤ1がSPLIT動作のイニシエータである。ノードＤ1はSPLITメッセージをノードＳ及びＤ2に送信する。ノードＳ及びＤ2はノードＤ1にACK応答メッセージで返答する。図には示していないが、図９ＩにおけるノードＤ1とＤ2とを入れ替えることも考えられる。図９Ｊは、ノードＯがイニシエータであること以外は図９Ｉと同様である。

（MERGE）
図１０Ａ〜１０Ｊに、本発明によるSEMP_MERGE動作の例を示す。MERGE動作はSPLIT動作の逆であり、２つのセッションを単一のセッションに結合する。SPLIT動作を参照して上述した例を用いれば、MERGE動作は、オーディオシステム（図示せず）に送信されたオーディオセッションとテレビジョン１１６に送信されたビデオセッションとを併合して、電話機１１４に送信される単一のセッションにする。この図では、ノードＳ1及びＳ2がこのMERGE動作のソースノードであり、ノードＤがこの動作のデスティネーションノードである。従って、セッション・エンドポイントはＳ1とＳ2から併合されてノードＤになる。ここでもノードＯは、アドホック・ネットワーク内の、ソースノードまたはデスティネーションノードとしてMERGE動作に関係しないノードである。しかしノードＯは、MERGE動作を開始するメッセージを送信することができる。

図１０Ａでは、ノードＤがMERGE動作のイニシエータである。ノードＤはそれぞれのMERGEメッセージをノードＳ1及びＳ2に送信する。そしてこの例では、ノードＳ1及びＳ2がそれぞれのACK応答メッセージをノードＤに送信する。一旦、ノードＤがACK応答メッセージを受信すると、併合されたデータの転送を開始することができる。図１０Ｂは、ノードＯがイニシエータであり、まずMERGEメッセージをノードＤに送信すること以外は図１０Ａと同様である。図１０ＣではノードＤがイニシエータである。ノードＤはMERGEメッセージをノードＳ1に送信し、そしてノードＳ1はMERGEメッセージをノードＳ2に送信する。ノードＳ2はノードＳ1にACKメッセージで応答し、ノードＳ1はノードＤにACKメッセージで応答する。

ノードＤがACKメッセージを受信した後に、併合されたデータの転送を開始することができる。この例では、ノードＳ1は、そのセッションデータをノードＤに送信することに加えて、ノードＳ2がノードＤに送信するセッションデータ用のプロキシとして作用する。図１０Ｄは、ノードＯがイニシエータであること以外は図１０Ｃと同様である。図１０ＥではノードＳ1がイニシエータである。ノードＳ1はMERGEメッセージをノードＤに送信し、そしてノードＤはMERGEメッセージをノードＳ2に送信する。図１０Ｆは、ノードＯがイニシエータであること以外は図１０Ｅと同様である。図１０Ｇでは、再びノードＳ1がイニシエータであるが、MERGEメッセージをノードＳ2に送信する。そしてノードＳ2はMERGEメッセージをノードＤに送信する。図１０Ｈは、ノードＯがイニシエータであること以外は図１０Ｇと同様である。図１０Ｉでは、ノードＳ1がそれぞれのMERGEメッセージをノードＤ及びＳ2に送信することによってMERGE動作を開始する。ノードＳ及びＤ2はノードＤ1にそれぞれのACK応答メッセージで返答する。図１０では、ノードＳ1とＳ2とを入れ替えることも考えられる。図１０Ｊは、ノードＯがイニシエータであること以外は図１０Ｉに示すのと同じ動作を表わす。

（INCOMING SESSION）
図１１Ａ〜１１Ｄに、本発明によるSEMP_INCOMING SESSION動作の例を示す。これらの図では、ノードＰが一次エンドポイントである。ノードＤ1及びＤ2は、例えば一次エンドポイント・ノードＰとは同じネットワーク内にないという理由で、一次エンドポイントにはなり得ない装置である。上述した例では、ノード１１４が、IPネットワーク１０２及びテレビジョン１１６で形成されるアドホック・ネットワークの両方のメンバー（構成員）である。この例では、テレビジョン１１６はネットワーク１０２からの入りの呼びを受信することができない。しかし、電話機１１４は入りの呼びを受信することができる。SEMPプロトコルのこの動作は、電話機１１４が入りの呼びをテレビジョン１１６のプロキシとして受信することを可能にする。より一般的には、INCOMING SESSION動作は、一次エンドポイントではない二次的装置が、一次エンドポイントにこの二次的装置に代わってセッションを取得させることを可能にする。アドホック・ネットワーク内の一次エンドポイントの存在は、そのカバーエリア内の装置が、当該ネットワーク上でセッションが確立されているネットワーク内になくても、これらの装置が入セッションを受信することを可能にする。しかし、これらの装置は、一次エンドポイントを含むパーソナルエリア・ネットワーク（PAN）内にある。

図１１Ａでは、ノードＰが入セッション（outgoing session）を受信する。そしてノードＰはCONNECTメッセージをそのカバーエリア内のすべての装置に伝える。このカバーエリア内にあるノードＤ1及びＤ2はこのCONNECTメッセージを受信する。ノードＤ1はACK応答メッセージでノードＰに返答して、ノードＰにセッションを取得させる。図１１Ｂでは、再びＰが入セッションを受信し、CONNECTメッセージをそのカバーエリア内のすべての装置に伝える。ノードＤ1はACK応答メッセージで返答する。そしてノードＤ1は即座に、（上述した）MOVEメッセージをＰに送信して、セッション・エンドポイントをノードＰからノードＤ1に移動させる。これらの例では、ノードＤ2は応答しなくても、否定応答（NAK：Negative Acknowledge）メッセージで応答してもよい。図１１Ｃでは、ノードＰは入セッションを受信して、CONNECTメッセージをそのカバーエリア内のすべての装置に伝える。ここでもノードＤ1はACK応答メッセージで返答する。しかしこの例では、ノードＤ1はセッションに参加しようとしないが、その代わりにノードＤ2を参加させようとする。従って、ノードＤ1は即座にMOVEメッセージをノードＰに送信して、ノードＰにセッション・エンドポイントをＤ2に移動させる。そしてノードＰはMOVEメッセージをノードＤ2に送信する。図１１Ｄでは、再びノードＰが入セッションを受信する。ノードＰはここでも、CONNECTメッセージをそのカバーエリア内のすべての装置に伝える。ノードＤ1はACK応答メッセージを返答する。そしてノードＤ1は即座に、MOVEメッセージをノードＤ2に送信して、ノードＤ2にノードＰからのセッション・エンドポイントを要求させる。従って、ノードＤ2はMOVEメッセージをノードＰに送信する。

（OUTGOING SESSION）
図１２Ａ〜１２Ｄに、本発明によるSEMP_OUTGOING SESSION動作の例を示す。図１１Ａ〜１１Ｄと同様に、図１２Ａ〜１２ＤではノードＰが一次エンドポイントである。ノードＤ1及びＤ2は一次エンドポイントにはなり得ない装置である。それにもかかわらず、ノードＤ1は、ノードＰが接続されたネットワーク上でセッションを開始しようとする。好適なSEMP_OUTGOING SESSION動作は、例えばこのネットワークに接続された装置と同じPAN内にある装置が、このネットワーク上でセッションを開始することを可能にする。一次エンドポイントのカバーエリア内のあらゆる装置は、開始装置自体がセッションに参加しなくても、この動作を開始することができる。これらの例では、ノードＰがセッションを開始し、そして確立されたセッションをMOVE動作を用いて一次エンドポイントから二次的な装置に移動する。

図１２Ａでは、ノードＰが出セッション（outgoing session）を受信する。ノードＤ1はノードＰにCONNECTメッセージを送信して、ノードＰにアドホック・ネットワーク外のノードとのセッションを確立させる。ノードＰはACK応答メッセージでＤ1に返答し、そして要求されたセッションを確立する。図１２Ｂでは、再びノードＰが出セッションのイニシエータである。ノードＤ1はCONNECTメッセージをノードＰに送信して、ノードＰにアドホック・ネットワーク外のノードとのセッションを確立させる。そしてノードＰはACK応答メッセージでノードＤ1に返答し、そしてノードＰは要求されたセッションを確立する。ノードＤ1は即座にMOVEメッセージをノードＰに送信して、ノードＰに、確立されたセッション・エンドポイントをノードＤ1に移動させる。図１２Ｃでは、再びノードＰが出セッションのイニシエータである。ここでもノードＤ1はCONNECTメッセージをノードＰに送信して、ノードＰにアドホック・ネットワーク外のノードとのセッションを確立させる。ノードＰはACK応答メッセージでノードＤ1に返答する。そしてノードＰは要求されたセッションを確立する。しかしこの例では、ノードＤ1はノードＤ2をセッション・エンドポイントにしようとする。従って、ノードＤ1は即座に、MOVEメッセージをノードＰに送信して、ノードＰにセッション・エンドポイントをノードＤ2に移動させる。従って上述したように、ノードＰはMOVEメッセージをノードＤ2に送信して、ノードＤ2を二次エンドポイントとして確立させる。図１２Ｄでは、再びノードＰが出セッションのイニシエータである。ノードＤ1はノードＰにCONNECTメッセージを送信して、アドホック・ネットワーク外のノードとのセッションを確立する。ノードＰはACK応答メッセージでノードＤ1に返答して、要求されたセッションを確立する。ノードＤ1は即座にMOVEメッセージをノードＤ2に送信して、セッション・エンドポイントをＰから取得する。従って、ノードＤ2はMOVEメッセージをノードＰに送信する。

本発明は好適な実施例について説明してきたが、請求項の範囲内で上述したように実施可能である。

（従来技術）本発明が動作する環境を説明するのに有用な、無線ローカルエリア・ネットワーク（WLAN）及び移動装置を含むインターネット・プロトコル（IP）のブロック図である。本発明の動作を説明するのに有用な、アドホック・ネットワークの拡張を有する図１に示すIPネットワークのブロック図である。本発明の動作を説明するのに有用な、アドホック・ネットワークの拡張を有する図１に示すIPネットワークのブロック図である。本発明の動作を説明するのに有用なフローチャートである。本発明に用いるのに適したプロトコル・スタックの可能な構成を説明するのに有用なデータ構造図である。図６Ａ〜６Ｇは、ルートの最適化を説明するのに有用なネットワーク・ノード図である。図７Ａ〜７Ｄは、本発明のプロトコルによるMOVE動作を説明するのに有用なネットワーク・ノード図である。図８Ａ〜８Ｄは、本発明のプロトコルによるCOPY動作を説明するのに有用なネットワーク・ノード図である。本発明のプロトコルによるSPLIT動作を説明するのに有用なネットワーク・ノード図である。本発明のプロトコルによるSPLIT動作を説明するのに有用なネットワーク・ノード図である。本発明のプロトコルによるSPLIT動作を説明するのに有用なネットワーク・ノード図である。本発明のプロトコルによるSPLIT動作を説明するのに有用なネットワーク・ノード図である。本発明のプロトコルによるSPLIT動作を説明するのに有用なネットワーク・ノード図である。本発明のプロトコルによるSPLIT動作を説明するのに有用なネットワーク・ノード図である。本発明のプロトコルによるSPLIT動作を説明するのに有用なネットワーク・ノード図である。本発明のプロトコルによるSPLIT動作を説明するのに有用なネットワーク・ノード図である。本発明のプロトコルによるSPLIT動作を説明するのに有用なネットワーク・ノード図である。本発明のプロトコルによるSPLIT動作を説明するのに有用なネットワーク・ノード図である。本発明のプロトコルによるMERGE動作を説明するのに有用なネットワーク・ノード図である。本発明のプロトコルによるMERGE動作を説明するのに有用なネットワーク・ノード図である。本発明のプロトコルによるMERGE動作を説明するのに有用なネットワーク・ノード図である。本発明のプロトコルによるMERGE動作を説明するのに有用なネットワーク・ノード図である。本発明のプロトコルによるMERGE動作を説明するのに有用なネットワーク・ノード図である。本発明のプロトコルによるMERGE動作を説明するのに有用なネットワーク・ノード図である。本発明のプロトコルによるMERGE動作を説明するのに有用なネットワーク・ノード図である。本発明のプロトコルによるMERGE動作を説明するのに有用なネットワーク・ノード図である。本発明のプロトコルによるMERGE動作を説明するのに有用なネットワーク・ノード図である。本発明のプロトコルによるMERGE動作を説明するのに有用なネットワーク・ノード図である。本発明のプロトコルによるINCOMING SESSION動作を説明するのに有用なネットワーク・ノード図である。本発明のプロトコルによるINCOMING SESSION動作を説明するのに有用なネットワーク・ノード図である。本発明のプロトコルによるINCOMING SESSION動作を説明するのに有用なネットワーク・ノード図である。本発明のプロトコルによるINCOMING SESSION動作を説明するのに有用なネットワーク・ノード図である。図１２Ａ〜１２Ｄは、本発明のプロトコルによるOUTGOING SESSION動作を説明するのに有用なネットワーク・ノード図である。

Claims

第１装置及び少なくとも１つのローカル装置を含むアドホック・ネットワーク環境内のセッション・エンドポイントを管理するプロトコルであって、前記セッション・エンドポイントが、前記第１装置と、前記第１装置を含む一次ネットワーク環境内の応対ノードとの間のセッションの一次エンドポイントとして構成された、セッション・エンドポイントを管理するプロトコルにおいて、
前記第１装置によって、前記少なくとも１つのローカル装置のアイデンティティを発見するステップと；
前記第１装置によって、前記少なくとも１つのローカル装置が参加しているあらゆるセッションを記述する情報を、前記少なくとも１つのローカル装置からセッション記述情報メッセージを介して受信するステップと；
MOVEメッセージを送信して、前記少なくとも１つのローカル装置を前記セッションの二次エンドポイントとして確立するステップと
を具えていることを特徴とするセッション・エンドポイント管理プロトコル。
前記少なくとも１つのローカル装置のアイデンティティを発見するステップが、所定の装置発見プロトコルに従って装置発見動作を実行するステップを含むことを特徴とする請求項１に記載のプロトコル。
前記少なくとも１つのローカル装置のアイデンティティを発見するステップがさらに、
前記第１装置によって、装置能力データを要求する装置情報メッセージを送信するステップと；
前記少なくとも１つのローカル装置によって、前記装置情報メッセージに応答して、前記少なくとも１つのローカル装置の装置能力データを含む第２の装置情報メッセージを前記第１装置に送信するステップと
を具えていることを特徴とする請求項１に記載のプロトコル。
前記セッション記述情報情報を前記少なくとも１つのローカル装置から受信するステップがさらに、前記少なくとも１つのローカル装置から前記セッション記述情報メッセージを介して装置能力情報を受信するステップを含むことを特徴とする請求項１に記載のプロトコル。
さらに、前記第１装置によって、前記第１装置と前記応対ノードとの間のセッションを記述する第２のセッション記述情報メッセージを、前記少なくとも１つのローカル装置に送信するステップを含むことを特徴とする請求項１に記載のプロトコル。
さらに、
前記少なくとも１つのローカル装置を、前記MOVEメッセージに応答して前記セッションのデータを受信し処理すべく構成するステップと；
前記第１装置によって、前記セッションのデータを前記少なくとも１つのローカル装置に転送するステップと
を含むことを特徴とする請求項１に記載のプロトコル。
前記少なくとも１つのローカル装置を前記セッションのデータを受信し処理すべく構成するステップを、前記少なくとも１つのローカル装置によってユーザから受信したコマンドに応答して、前記少なくとも１つのローカル装置によって実行することを特徴とする請求項６に記載のプロトコル。
前記少なくとも１つのローカル装置を前記セッションのデータを受信し処理すべく構成するステップを、前記少なくとも１つのローカル装置によって前記第１装置から受信したコマンドに応答して、前記少なくとも１つのローカル装置によって実行することを特徴とする請求項６に記載のプロトコル。
第１装置及び複数のローカル装置を含むアドホック・ネットワーク環境内のセッション・エンドポイントを管理するプロトコルであって、前記セッション・エンドポイントが、前記第１装置と、前記第１装置を含む固定ネットワーク環境内の応対ノードとの間のセッションの一次エンドポイントとして構成された、セッション・エンドポイントを管理するプロトコルにおいて、
前記第１装置及び少なくとも１つの前記ローカル装置の一方によって、前記アドホック・ネットワーク内の前記複数のローカル装置の少なくとも１つに送信され、情報を要求するかあるいは情報を提供する情報メッセージと；
前記複数のローカル装置の１つによって、前記第１装置及び前記複数のローカル装置の他の装置の一方に送信され、前記第１装置に前記他の装置を前記セッションの二次エンドポイントとして確立させるMOVEメッセージと
を含むことを特徴とするセッション・エンドポイント管理プロトコル。
前記情報メッセージが、
要求または提供している情報の種類を識別する情報種類フィールドと；
前記情報メッセージが情報を要求しているか提供しているかを示す情報状態フィールドと；
前記情報メッセージによって提供されるあらゆる情報を含むコンテントフィールドとを含み、
前記MOVEメッセージが、
前記第１装置を示すPRIMARY ENDPOINTフィールドと；
前記複数のローカル装置のうち前記MOVEメッセージを送信している装置を識別するFROMフィールドと；
前記複数のローカル装置のうち前記MOVEメッセージが送信される前記他の装置を識別するTOフィールドとを含み、
前記他の装置が前記セッションの二次エンドポイントとして確立される
ことを特徴とする請求項９に記載のプロトコル。
さらに、前記複数のローカル装置の１つによって送信され、前記複数のローカル装置の１つを二次エンドポイントとして確立させ、前記セッションのコピーを前記二次エンドポイントに提供するCOPYメッセージを含むことを特徴とする請求項９に記載のプロトコル。
前記セッションが複数の部分を含み、前記プロトコルがさらに、前記複数のローカル装置の１つによって送信され、前記複数のローカル装置の第１及び第２の装置を、前記セッションのそれぞれ異なる前記部分の二次エンドポイントとして確立するSPLITメッセージを含むことを特徴とする請求項９に記載のプロトコル。
さらに、前記複数のローカル装置の１つによって送信され、前記複数のローカル装置の１つの装置を、前記複数のローカル装置の第１及び第２の装置において確立された単一セッションの複数部分の二次エンドポイントとして確立するMERGEメッセージを含むことを特徴とする請求項１２に記載のプロトコル。
さらに、前記複数のローカル装置の１つによって前記第１装置に送信され、前記第１装置に入セッションを通知するか、あるいは前記第１装置にセッションを開始させるCONNECTメッセージを含むことを特徴とする請求項９に記載のプロトコル。
さらに、前記複数のローカル装置の１つによって前記第１装置に送信され、前記第１装置に前記セッションを終了させるTREMINATEメッセージを含むことを特徴とする請求項１４に記載のプロトコル。
第１装置における論理セッションのエンドポイントを管理して、前記エンドポイントを前記第１装置のカバーエリア内にある少なくとも１つのローカル装置に選択的に拡張するプロトコルにおいて、
前記第１装置によって、前記少なくとも１つのローカル装置のアイデンティティを発見するステップと；
前記第１装置によって、前記少なくとも１つのローカル装置が参加しているあらゆるセッションを記述する情報を、前記少なくとも１つのローカル装置からセッション記述情報メッセージを介して受信するステップと；
MOVEメッセージを送信して、前記少なくとも１つのローカル装置を前記論理セッションの二次エンドポイントとして確立するステップと
を具えていることを特徴とするセッション・エンドポイントの管理プロトコル。
前記少なくとも１つのローカル装置のアイデンティティを発見するステップが、所定の装置発見プロトコルに従って装置発見動作を実行するステップを含むことを特徴とする請求項１６に記載のプロトコル。
前記少なくとも１つのローカル装置のアイデンティティを発見するステップがさらに、装置能力情報メッセージを前記少なくとも１つのローカル装置から前記第１装置に送信するステップを含むことを特徴とする請求項１７に記載のプロトコル。
先頭ノードから最終ノードまでが結合されて所定のノード列をなす複数のノードを含むアドホック・ネットワーク環境内のセッション・エンドポイントにアクセスするために使用する経路を管理するプロトコルにおいて、
前記最終ノードによって、前記ノード列内に存在せず前記最終ノードにとってローカルノードである新たなノードを発見するステップと；
前記最終ノードによって、前記新たなノードが参加しているあらゆるセッションを記述する情報を、前記新たなノードからセッション記述情報メッセージを介して受信するステップと；
MOVEメッセージを前記最終ノードから前記新たなノードに送信して、前記新たなノードを前記アドホック・ネットワーク内の新たな最終ノードとして確立し、前記MOVEメッセージが、前記ノード列内の中間ノードであって前記最終ノードが当該ノードからデータを受信する中間ノードの識別子を含むステップと；
前記新たな最終ノードによって、前記中間ノードが前記新たな最終ノードにとってローカルノードであるか否かを判定するステップと；
前記中間ノードが前記新たな最終ノードにとってローカルノードである場合には、第２のMOVEメッセージを前記新たな最終ノードから前記中間ノードに送信して、前記新たな最終ノードと前記中間ノードとの直接接続を確立するステップと；
前記新たな最終ノードから前記最終ノードにTERMINATEメッセージを送信して、前記最終ノードと前記中間ノードとの間のあらゆるセッションを終了するステップと
を具えていることを特徴とする経路管理プロトコル。
先頭ノードから最終ノードまでが結合されて所定のノード列をなす複数のノードを含むアドホック・ネットワーク環境内のセッション・エンドポイントにアクセスするために使用する経路を管理するプロトコルにおいて、
前記最終ノードによって、前記ノード列内に存在せず前記最終ノードにとってローカルノードである新たなノードを発見するステップと；
前記最終ノードによって、前記新たなノードが参加しているあらゆるセッションを記述する情報を、前記新たなノードからセッション記述情報メッセージを介して受信するステップと；
MOVEメッセージを前記最終ノードから前記新たなノードに送信して、前記新たなノードを前記アドホック・ネットワーク内の新たな最終ノードとして確立するステップと；
前記新たな最終ノードのアドレスを含む経路最適化メッセージを、前記新たな最終ノードから前記最終ノードに送信するステップと；
前記経路最適化メッセージを、前記最終ノードから、前記所定のノード列内の前記最終ノードの先行ノードに転送するステップと；
前記先行ノードによって、前記新たな最終ノードが前記先行ノードにとってローカルノードであるか否かを判定するステップと；
前記新たな最終ノードが前記先行ノードにとってローカルノードである場合に、第２のMOVEメッセージを前記先行ノードから前記新たな最終ノードに送信して、前記先行ノードと前記新たな最終ノードとの直接接続を確立するステップと；
前記先行ノードから前記最終ノードにTERMINATEメッセージを送信して、前記先行ノードと前記最終ノードとの間のあらゆるセッションを終了するステップと
を具えていることを特徴とする経路管理プロトコル。
さらに、
前記新たな最終ノードのアドレスを含む経路最適化メッセージを、前記新たな最終ノードから前記先行ノードに送信するステップと；
前記経路最適化メッセージを、前記先行ノードから、前記所定のノード列内で前記先行ノードに先行する他のノードに転送するステップと；
前記他のノードによって、前記新たな最終ノードが前記他のノードにとってローカルノードであるか否かを判定するステップと；
前記新たな最終ノードが前記他のノードにとってローカルノードである場合に、第３のMOVEメッセージを前記他のノードから前記新たな最終ノードに送信して、前記他のノードと前記新たな最終ノードとの直接接続を確立するステップと；
前記他のノードから前記先行ノードにTERMINATEメッセージを送信して、前記先行ノードと前記新たな最終ノードとの間のあらゆるセッションを終了するステップと
を具えていることを特徴とする請求項２０に記載のプロトコル。
さらに、
経路最適化メッセージを、前記所定のノード列において前記先行ノードに先行するノード列内の連続する各ノードに送信するステップと；
前記経路最適化メッセージを受信したことに応答して、前記先行するノード列内の連続する各ノードによって、前記新たな最終ノードが前記各ノードにとってローカルノードであるか否かを判定するステップと；
前記新たな最終ノードが前記先行するノード列内のいずれか１つのノードにとってローカルノードである場合には、第４のMOVEメッセージを前記いずれか１つのノードから前記新たな最終ノードに送信して、前記いずれか１つのノードと前記新たな最終ノードとの直接接続を確立するステップと；
前記いずれか１つのノードから、前記先行するノード列内の前記いずれか１つのノードの後続ノードにTERMINATEメッセージを送信して、前記後続ノードと前記新たな最終ノードとの間のあらゆるセッションを終了するステップと
を具えていることを特徴とする請求項２０に記載のプロトコル。