JP2003516033A - ルート探索に基づいたピコネットの確立方法 - Google Patents

Abstract

(57)【要約】 アドホック・ネットワークにおいて、発信元ノードから宛先ノードへと送信されるデータパケットの経路を確立する方法。宛先ノードへと送信されるべきパケットを保持している発信元は、宛先ノードへの経路を処理してない場合に、反応ルーティングプロトコルを使用する。はじめに、発信元ノードが、既存のピコネットのメンバーであるかどうかを決定してもよい。もし、発信元ノードがピコネットのメンバーであれば、ROUTE 要求メッセージが、既存のピコネットのノードへと放送され、一方で、発信元ノードは、適当な時間、REPLYメッセージを待つ。もし、発信元ノードが既存のピコネットのメンバーでなければ、あるいは、時間内に、REPLYメッセージが受信されなければ、発信元ノードは、新規の経路探索処理を開始する。発信元ノードは、この処理において、発信元ノードと宛先ノートとの間の通信をより効率よくすることが可能な新規なピコネットを確立しようと試みる。

Description

【発明の詳細な説明】

【０００１】 発明の属する技術分野 本願発明は、通信分野に関連するものである。とりわけ、アドホック・ネット
ワーク通信に関する。

【０００２】 背景 「Ｂｌｕｅｔｏｏｔｈ（ブルートゥース）」は、アドホック無線ネットワーク
に係る技術の一例であり、免許不用の２．４ＧＨｚＩＳＭ（Industrial-Scienti
fic-Medical：産業・科学・医療）バンドにおいて周波数ホッピングを使用する
ものである。Ｂｌｕｅｔｏｏｔｈの当初の意図は、短距離無線環境において、電
話、ＰＣカード、無線ヘッドセットその他などの総置換のケーブルを取り去って
しまおうとするものであった。しかしながら、今日、Ｂｌｕｅｔｏｏｔｈは、音
声などの同期トラヒックとＩＰベースのデータトラヒックなどの非同期トラヒッ
クとの双方に適用することを意図した真のアドホック無線ネットワーク技術とな
っている。その目的は、Ｂｌｕｅｔｏｏｔｈ用の無線チップとそれに付随するソ
フトウエアを使用することで、電話機、ＰＤＡ、ラップトップ、デジタルカメラ
、ビデオモニター、プリンタ、ファクシミリ機、その他などの如何なるデジタル
通信装置をも無線インタフェースを介して通信可能とすることである。

【０００３】 図１は、例示的な３つのピコネットを示している。Ｂｌｕｅｔｏｏｔｈ技術に
よれば、同一のチャネルを占有している２以上のＢｌｕｅｔｏｏｔｈ（ＢＴ）ユ
ニットによりピコネットが形成される。ＢＴユニットは、ピコネット内において
マスタかスレーブになることができるが、各ピコネットにマスタは１台だけであ
り、スレーブは７台までである。

【０００４】 図２は、スキャッタネットを示している。スキャッタネットは、２以上のピコ
ネットの相互接続を通して形成される。２以上のピコネットは、共通に占有され
るＢＴユニットを経由して相互に接続される。すなわち、このＢＴユニットは、
双方のピコネットのメンバーになる。ＢＴユニット２０５は、ピコネット１、２
及び３からなる３つのピコネットによって占有されるＢＴユニットを例示するも
のである。

【０００５】 図２は、さらに、２以上のピコネットにより占有されるＢＴユニットであって
、ある複数のピコネットではスレーブユニットとして動作し、一方で、１つのピ
コネットでだけマスタユニットとして動作するものが例示されている。例えば、
ＢＴユニット１２０は、ピコネット１０のマスタユニットであるが、ピコネット
１１と１２ではスレーブユニットとなるだけである。加えて、２以上のピコネッ
トのメンバーになっているＢＴユニットは、同時に、１つのピコネットにおいて
だけ、送信及び受信が許可されている。従って、複数のピコネットへの参加は、
時分割多重規則に準拠していなければならない。

【０００６】 各ＢＴユニットは、グローバルに固有な４８ビットのＩＥＥＥ８０２アドレス
を割り当てられている。このアドレスは、Ｂｌｕｅｔｏｏｔｈデバイスアドレス
（ＢＤ＿ＡＤＤＲ）と呼ばれており、ＢＴユニットの製造時に割り当てられ、決
して変更されることはない。加えて、ピコネットのマスタは、ローカルなアクテ
ィブ・メンバー・アドレス（ＡＭ＿ＡＤＤＲ）をピコネット内のアクティブなメ
ンバーのそれぞれに割り当てる。ＡＭ＿ＡＤＤＲは、たったの３ビット長である
が、動的に割り当てられ、かつ、動的に割当が解除されるものであり、単一のピ
コネット内でだけ固有に割り当てられるものである。マスタは、ピコネット内の
特定のスレーブをポーリングするためにＡＭ＿ＡＤＤＲを使用する。マスタから
のポーリングパケットによってトリガーされたスレーブが、パケットをマスタに
送信するときは、パケットヘッダー内に自己のＡＭ＿ＡＤＤＲを搭載して送信す
る。

【０００７】 すべてのデータはパケットに搭載されて送信されるが、これらのパケットには
、ＳＣＯリンク上の主に音声トラヒック向け同期データや非同期コネクションレ
ス（ＡＣＬ）リンク上の非同期データの少なくとも一方が搭載されている。もし
、パケットが非同期データを搭載しているのであれば、確認応答及び再送方式を
採用することで送信データの信頼性を確保することになる。これは前方誤り訂正
（ＦＥＣ）などのチャネル符号化を使用する例である。

【０００８】 図３は、Ｂｌｕｅｔｏｏｔｈパケットの標準フォーマットを示しているが、例
外としてある種の制御パケットが含まれている。ＡＭ＿ＡＤＤＲはパケットヘッ
ダーに位置しており、その後に、制御パラメータ（例えば、ビットを表示した確
認応答又は再送要求など、なおヘッダー誤り検出が適用される場合にはヘッダー
誤り検査（ＨＥＣ）符号など）が続いている。

【０００９】 ペイロードのフォーマットは、パケットの種類に依存する。ＡＣＬパケットの
ペイロードには、ヘッダー、データフィールド、及び、最も例示的な巡回冗長検
査（ＣＲＣ）符号が含まれている。ＳＣＯパケットのペイロードにはデータフィ
ールドだけが含まれている。加えて、２つのデータフィールドを有するハイブリ
ッドパケットも存在する。これは、１つには同期データがもう１つには非同期デ
ータが搭載される。ＣＲＣを含まないパケットは、確認応答もされなければ再送
されることもない。

【００１０】 図４は、Ｂｌｕｅｔｏｏｔｈシステムのプロトコルレイヤーを示している。ベ
ースバンド、ＬＭＰ及びＬ２ＣＡＰが、Ｂｌｕｅｔｏｏｔｈ特別のプロトコルに
存在しており、「ハイレベルプロトコル又はアプリケーション」レイヤーは、Ｂ
ｌｕｅｔｏｏｔｈ特別のプロトコルであってもなくてもよいプロトコルを示して
おり、一方で、ネットワークレイヤーは、現在のＢｌｕｅｔｏｏｔｈ規格におい
ては存在していない。

【００１１】 Ｂｌｕｅｔｏｏｔｈにおける顕著な制限は、あるピコネットのＢＴユニットか
ら他のピコネットのＢＴユニットへのパケットをアドレスしてルーティングする
方法が未だ定義されていないことである。換言すれば、現在のＢｌｕｅｔｏｏｔ
ｈ規格では、スキャッタネットにおいてピコネット間の通信をどのように実行す
るかについては未だ規格化されていないのである。

【００１２】 アドホック・ネットワーク技術における重要な機能は、周辺探索機能である。
これはまたＢｌｕｅｔｏｏｔｈにおいてもそうである。この周辺探索機能なしで
は、ＢＴユニットは、通信の対象となる他のＢＴユニットを見るけることはでき
ない。従って、アドホック・ネットワークが形成されることもない。Ｂｌｕｅｔ
ｏｏｔｈにおける周辺探索プロシージャには、ＩＮＱＵＩＲＹ（問い合わせ）メ
ッセージとＩＮＱＵＩＲＹ ＲＥＳＰＯＮＳＥ（問い合わせに対する応答）メッ
セージが含まれている。無線カバレッジ内において隣接するＢＴユニットを探索
したいと望むＢＴユニットは、規定されたタイミングと周波数シーケンスに従っ
て、繰り返しＩＮＱＵＩＲＹメッセージを送信し、ＩＮＱＵＩＲＹ ＲＥＰＯＮ
ＳＥメッセージをリッスンする。ＩＮＱＵＩＲＹメッセージには、問い合わせア
クセスコードだけが含まれている。問い合わせアクセスコードには、一般問い合
わせアクセスコード（ＧＩＡＣ）又は専用問い合わせアクセスコード（ＤＩＡＣ
）とがある。ＧＩＡＣは近隣のいずれかのＢＴユニットを探索するために送信さ
れ、ＤＩＡＣは、特定のＤＩＡＣが割り当てられたあるタイプのＢＴユニットを
探索するために送信される。

【００１３】 ＧＩＡＣ又はＤＩＡＣを含んだＩＮＱＵＩＲＹメッセージを受信するとＢＴユ
ニットは、ＩＮＱＵＩＲＹ ＲＥＳＰＯＮＳＥメッセージを用いて応答する。Ｉ
ＮＱＵＩＲＹ ＲＥＳＰＯＮＳＥメッセージは、実際のところ、周波数ホッピン
グ同期（ＦＨＳ）パケットである。Ｂｌｕｅｔｏｏｔｈでは、ＦＨＳパケットを
様々な目的に使用しており、例えば、名称が示すように周波数ホップチャネルシ
ーケンスの同期に使用している。ＩＮＱＵＩＲＹ ＲＥＳＰＯＮＳＥメッセージ
を受信することによって、ＩＮＱＵＩＲＹ（問い合わせ）処理を開始したＢＴユ
ニットは、隣接ＢＴユニットのＢＤ＿ＡＤＤＲと内部クロック値を収集する。こ
れらは、ともにＦＨＳパケットに含まれている。

【００１４】 ＩＮＱＵＩＲＹプロシージャに関連するものとして、ＰＡＧＥ（呼び出し）プ
ロシージャがある。ＰＡＧＥプロシージャは、２つのＢＴユニット間で実際のコ
ネクションを確立するために使用されるプロシージャである。ＩＮＱＵＩＲＹプ
ロシージャの実行結果として、一旦、隣接ＢＴユニットのＢＤ＿ＡＤＤＲが取得
できれば、ＰＡＧＥメッセージを使用することで隣接ＢＴユニットを呼び出すこ
とが可能となる。呼び出されているＢＴユニットの内部クロック値を知ることで
、ＰＡＧＥプロシージャをスピードアップできる。これは、隣接ＢＴユニットが
ＰＡＧＥメッセージをリッスンするタイミングと周波数ホップチャネルとを、呼
び出す側のユニットが推定できるようになるからである。ＰＡＧＥメッセージは
、デバイスアクセスコード（ＤＡＣ）を含んでおり、これは呼び出されるＢＴユ
ニットのＢＤ＿ＡＤＤＲから導き出される。ＤＡＣを含むＰＡＧＥメッセージを
受信したＢＴユニットは、同一のパケットを用いて応答する。呼び出す側のＢＴ
ユニットは、ＦＨＳパケットを用いて返答する。このＦＨＳパケットには、呼び
出す側のＢＴユニットのＢＤ＿ＡＤＤＲ、その現在の内部クロック値、呼び出さ
れる側のＢＴユニットに割り当てられたＡＭ＿ＡＤＤＲ及び他のパラメータが含
まれている。呼び出されるＢＴユニットは、もう一度ＤＡＣを用いて応答し、二
つのＢＴユニット間のコネクションが確立される。

【００１５】 呼び出しを行ったＢＴユニットが既に既存のピコネットにおいてマスタとなっ
ていれば、呼び出されたＢＴユニットは、新規のスレーブユニットとしてこの既
存のピコネットへと参加することになる。あるいは、呼び出しを行ったＢＴユニ
ットがマスタとなることで、二つのＢＴユニットが新規のピコネットを形成して
もよい。ＩＮＱＵＩＲＹメッセージには送り手についての情報を何も含んではい
ないので、ＩＮＱＵＩＲＹプロシージャを開始したＢＴユニットは、その後に続
くＰＡＧＥプロシージャを開始できる唯一のＢＴユニットとなる。それゆえ、Ｉ
ＮＱＵＩＲＹプロシージャを開始したＢＴユニットは、その後に続くＰＡＧＥプ
ロシージャの実行結果として形成されるいずれかのピコネットのマスタとなるの
である。しかしながら、必要であるなら、Ｂｌｕｅｔｏｏｔｈのマスタ・スレー
ブ変換機構を用いることで、マスタとスレーブの役割を変換することができる。
しかしながら、これは、そのピコネットに含まれる他のスレーブユニットも巻き
込んでピコネットの全体を再構築するといった、複雑で大規模なプロシージャで
ある。

【００１６】 ＩＮＱＵＩＲＹプロシージャとＰＡＧＥプロシージャとは、現時点でのＢｌｕ
ｅｔｏｏｔｈ標準において十分に規格化されている。これらは、新規のＢｌｕｅ
ｔｏｏｔｈピコネットを形成したり、既存のピコネットに新規にＢＴユニットを
追加したりするために必要とされるツールのすべてを備えている。これらのツー
ルは良く規格化されてはいるが、しかしながら、これらの使用の仕方についての
ガイドラインや規則といったものが存在してはいない。すなわち、隣接している
ＢＴユニットの発見時に、適切なピコネットを形成するためには、どのユニット
に接続すればよいかを把握する手段が存在していない。さらに、マスタ・スレー
ブ変換機構が存在してはいるが、これを使用することは上述のように大規模なプ
ロシージャとなる。また、ピコネットの効率を改善するためには、このプロシー
ジャを何時使用すればよいかを把握することが困難である。よって、ピコネット
は多かれ少なかれランダムに形成されてしまい、その結果、しばしば、最適なピ
コネット構造や最適なスキャッタネット構造とはほど遠いものが形成されてしま
う。なお、ＩＮＱＵＩＲＹプロシージャを開始したＢＴユニットが、接続したい
と希望するＢＴユニットのＢＤ＿ＡＤＤＲを既に知っているときは例外である。

【００１７】 Ｂｌｕｅｔｏｏｔｈにおける重要な観点は、Ｂｌｕｅｔｏｏｔｈプロトコルス
タックの頂上においてＩＰをサポートする機能である。これを達成すべく、現時
点では二つの提案がなされている。第１の提案は、各ピコネットをＩＰサブネッ
トとみなし、各ピコネットのＬ２ＣＡＰの最上位においてＩＰを動作させるもの
である。第２の提案は、Ｂｌｕｅｔｏｏｔｈスキャッタネットの全体をＩＰサブ
ネットとみなすものである。これは、ネットワーク・アダプテーション・レイヤ
ー（ＮＡＬ）と呼ばれる適用レイヤーを必要とするものであり、図５において示
されているように、Ｌ２ＣＡＰとＩＰレイヤーとの間に挿入されるものである。
ＮＡＬの目的は、ＩＰレイヤーにおいて想定されている共有媒体ネットワーク（
すなわち放送媒体）をエミュレーションするものである。

【００１８】 第１の提案は多数の問題にさらされている。これは、Ｂｌｕｅｔｏｏｔｈピコ
ネットが共有媒体ネットワークではないという事実に依拠している。第２の提案
は、もちろん問題がないわけではないが、より将来性のあるアプローチであると
思われる。本発明は、第２の提案に適用されるものである。したがって、本発明
は、図５に示されたＮＡＬを含むプロトコルレイヤーを想定している。

【００１９】 ＮＡＬレイヤーは多数の機能をサポートする必要がある。例えば、ＩＰレイヤ
ーによって仮定されている単一の共有媒体ネットワークをスキャッタネットがエ
ミュレーションする一方で、スキャッタネット内でパケットをルーティングする
ためのルーティング機構をサポートしなければならない。スキャッタネットを通
してパケットをルーティングするために使用されるルーティング方式に依存しな
いが、あるピコネットから他のピコネットへとパケットを転送する際に使用され
る一以上のピコネットのメンバーであるＢＴユニットらにルーティング方式は依
存することになる。これらのＢＴユニットを以下では転送ノードと称することに
する。

【００２０】 一般的に、ルーティングプロトコルは、プロアクティブタイプ（事前型）とリ
アクティブタイプ（反応型）に大別できる。プロアクティブ型のルーティングプ
ロトコルでは、現在必要とされていないルートであっても、ノード間のルートを
維持することになっている。プロアクティブ・ルーティング・プロトコルは、ト
ポロジーの変更によって影響を受けるトラヒックが存在しない場合であっても、
ネットワークトポロジーの変更に適合する。プロアクティブ・ルーティング・プ
ロトコルは、オーバヘッドの観点から非常にコストがかかる。なぜなら、ネット
ワークにおけるすべてのノードが他のノードへと周期的に制御情報を送信しなけ
ればならないからである。

【００２１】 他のアプローチはリアクティブ型のルーティングプロトコルを使用するもので
ある。リアクティブ型のルーティング手法によれば、特定の宛先へとパケットを
ルーティングする明確な必要性が生じたときにルートが確立される。これは、デ
ータを送信するために実際に必要とされるルートの軌跡（トラック）を、ルーテ
ィングプロトコルが維持するだけでよいことを意味する。従って、ルートを維持
するためのオーバヘットの観点からはコストが低くて済むのである。

【００２２】 発信元ノードから宛先ノードへのルートを確立するためには、典型的に、発信
元ノードが、記述されている宛先へのルートを要求するＲＥＱＵＥＳＴ（要求）
メッセージを放送することになる。一定の範囲内にあるすべてのノードがＲＥＱ
ＵＥＳＴメッセージを受信する。このＲＥＱＵＥＳＴメッセージを、宛先ノード
への有効なルート上のノード及び宛先ノードのどちらでもない他のノードが受信
すると、ＲＥＱＵＥＳＴメッセージを近隣のノードへと再放送する。宛先ノード
又は宛先ノードへの有効なルート上のノードのどちらかがこのＲＥＱＵＥＳＴメ
ッセージを受信すると、ＲＥＱＵＥＳＴメッセージを再放送しないことにより、
ネットワークへの氾濫を制限し、ユニキャストＲＥＰＬＹ（返答）メッセージを
送信元のノードへと送信し返す。

【００２３】 典型的に、送信元のノードは、受信した第１の返信メッセージを使用し、また
、実際のルートが破断したときにだけ新規のルートを要求する。ルーティングは
、以下に示す規則の１つに従って達成されうる。第１は、送信元ノードが存在し
、ルートの全体がＲＥＰＬＹメッセージを受信することにより明らかになるもの
である。中間ノードにおいては何らの情報も必要ではないが、送信元のノードだ
けは、ルートの軌跡を維持することが必要となる。ルートの全体は、パケットが
送信されるごとに特定される。第２は、距離ベクターに関するものである。距離
ベクターでは、ＲＥＰＬＹメッセージによって、情報が中間ノードのルーティン
グテーブルに蓄積される。宛先は、送信されるパケット内においてのみ必要とさ
れる。

【００２４】 Ｂｌｕｅｔｏｏｔｈ規格は、上述したように、ピコネットを確立するためのＩ
ＮＱＵＩＲＹプロシージャとＰＡＧＥプロシージャとを備えているが、効率的な
スキャッタネットを形成するためにどのようにしてこれらのプロシージャを使用
するかについては何も開示してはいない。さらに、いずれのピコネットのメンバ
ーでもないこれらのノードが、宛先に送信すべきパケットを有している場合の解
決策となるようなプロシージャは提供されてはいない。

【００２５】 発明の概要 現在の技術におけるこれらの課題及び他の課題、欠点及び制限は本願発明に従
って克服されるものであり、すなわち、通信ネットワークにおける送信元ノード
（すなわち、パケットを送信する側のノード）が、予め定められた事象に基づい
て一以上のネットワークコネクションを形成できる。

【００２６】 従って、本願発明の目的は、発信元ノードと宛先ノードとの間のルートを形成
すべく、新規のネットワークコネクションを形成しうるかどうかの決定をリアク
ティブ型のアドホック・ルーティング・プロトコルにより可能ならしめるもので
ある。

【００２７】 本願発明の他の目的は、予め定められた事象の発生に基づいて、発信元ノード
と宛先ノードとの間のルートを形成する新規のネットワークコネクションを生成
する手段を送信元ノードに提供することである。

【００２８】 本願発明のある観点によれば、上述の及び他の目的は、通信ネットワークにお
いて、送信元ノードから宛先ノードへと送信されるべきデータパケットを搬送す
るためのルートを確立する方法によって達成される。この方法では、既存のネッ
トワークコネクションを介する送信元ノードと宛先ノード間のルート探索を要求
する。最終的には、ルート探索要求が失敗したかどうかの決定がなされる。もし
、ルート探索要求が失敗すれば、一以上の新規のネットワークコネクションを生
成することにより、送信元ノードと宛先ノード間のルートが形成される。

【００２９】 発明の詳細な説明 Ｂｌｕｅｔｏｏｔｈが主たるターゲットであるので、Ｂｌｕｅｔｏｏｔｈ用語
を用いて本発明を説明することにする。しかしながら、本発明が、他の有線又は
無線のネットワーク技術にも適用可能である。どのようにして一般化できるにつ
いても簡潔に説明する。

【００３０】 一般的に、本発明は、ピコネットの形成に用いるリアクティブ・ルーティング
に関する。以下に、本発明がこれを達成することについて説明する。

【００３１】 宛先ノードへと送信されるべきパケットを有する送信元ノードは、宛先ノード
へのルートを処理していないときに、リアクティブ・ルーティングを使用する。
このリアクティブ・ルーティング・プロトコルを通して、発信元ノードはルート
を取得することになるが、送信元ノードが一以上の現在するピコネットのメンバ
ーであるか又はいずれのピコネットのメンバーでもないかに依存して、ことなる
動作が実行されてもよい。

【００３２】 図６は、本願発明の例示的な実施形態に関連する技術を説明する図である。は
じめに、図示されるステップ６０５において、送信元ノードが既存のピコネット
のメンバーであるかどうかが判定される。もし、送信元ノードが既存のピコネッ
トのメンバーでないならば、ステップ６０５の決定パスである「ＮＯ」にしたが
って、以下に説明するステップ６３５へと移行する。一方、送信元ノードが既存
のピコネットのメンバーであれば、ステップ６０５の決定パスである「ＹＥＳ」
にしたがってステップ６１０と移行する。ステップＳ６１０に示されるように、
送信元ノードは、既存のピコネットを介してルート探索処理を開始する。もちろ
ん、これは、既存のピコネットを通して接続されるノードへとＲＯＵＴＥ要求メ
ッセージを放送することによって達成される。

【００３３】 図示されるステップ６１５において、送信元ノードは、適時（タイムリー）な
ＲＥＰＬＹメッセージを待つ。タイムリーな応答が受信されなければ、判定ステ
ップ６１５の出力パス「ＮＯ」に従って、再度、ステップ６３５へと移行する。
一方、タイムリーな応答が受信されれば、判定ステップ６１５の出力パス「ＹＥ
Ｓ」に従って、送信元ノードは、ＲＥＰＬＹメッセージによって定義されるルー
トを介して、送信元ノードが保有しているパケットを送信すべきかどうかを決定
する。判定ステップ６２０からの出力パス「ＮＯ」に従って、送信元ノードは、
ＲＥＰＬＹメッセージによって定義されるルートに沿った宛先ノードへとパケッ
トをより効率よく送信することを決定してもよい。もし、このケースであれば、
ステップ６２５において、送信元ノードが、ＲＥＰＬＹメッセージによって定義
されるルートに沿った宛先ノードへとパケットをより効率よく送信することを決
定する。これとは対照的に、ルートの最適化が必要であると決定すると、判定ス
テップ６２０からの出力パス「ＹＥＳ」に従って、送信元ノードがより効率のよ
いルートを新規に定義してもよい。この場合は、ステップ６３０において示され
ているように、ＲＥＰＬＹメッセージによって定義されたルートを介してパケッ
トの送信を開始することができる。しかしながら、同時に、送信元ノードは、ス
テップ６３５において新規のルート探索処理を開始し、送信元ノードと宛先ノー
ド間のより効率のより通信を可能とするであろう新規のピコネットの確立を試行
してもよい。より効率の良いルートを確立できるものと仮定すると、送信元ノー
ドは、新規に形成された一以上のピコネットのルートを介してパケットの送信を
開始する。従って、当業者であれば、本発明に係るルート探索が新規ピコネット
への形成に影響することを明確に理解できるであろう。

【００３４】 新規のピコネットの確立を即座に開始することは必ずしも最良でないことの理
由は、ピコネットの確立処理は相対的にゆっくりとした処理であり、既存の一以
上のピコネットを介した宛先ノードへの有効なルートを使用したＲＥＰＬＹメッ
セージを現実的に受信するよりも多くの時間を必要とする可能性があるからであ
る。従って、送信元ノードは、既存のピコネットを通して宛先ノードへと到達可
能であれば、より高速なルートを取得することができる。しかしながら、第１の
ルート確立が成功した後にピコネットの再構築を送信ノードが実行することを禁
止するものではない。他の理由は、ルート探索中のピコネットの形成が、維持が
必要でかつピコネットのスケジューリングに含ませることも必要となる、多数の
不要なピコネットを増加させてしまうからである。

【００３５】 既存ピコネットの使用 上述したように、送信元ノードが１以上の既存ピコネットのメンバーとなって
いる場合には、ネットワーク内に行き渡って行く通常のＲＯＵＴＥ ＲＥＱＵＥ
ＳＴメッセージの送出をルーティングプロトコルに開始させてしまう。よって、
ルート要求パケットだけが、既存のピコネット内に行き渡って行く。最悪のシナ
リオでは、宛先ノードが到達不可能となってしまう。なぜなら、例えば、宛先ノ
ードが既存ピコネットのいずれのメンバーでもなくなるからであり、あるいは、
送信ノードを宛先ノードと通信可能とする如何なるコネクションも有しないピコ
ネットのメンバーに、宛先ノードがなってしまうからである。実際に、送信元ノ
ードと宛先ノードとが相互に電波の届く位置にありながら、必要なピコネットが
、単純にも未だに形成されていないことがある。

【００３６】 図７は、本発明に係る他の実施形態を示している。図示されるように、送信ノ
ードは、タイムリーＲＥＰＬＹメッセージの受信に失敗した後に（例えば、図６
に示されている判定ステップ６１５の出力パス「ＮＯ」に従って）、ステップ７
０５において、新規ピコネットの形成を通じて、新規ルートの探索処理を即座に
開始する。しかしながら、もし、新規ピコネットを通じたルートを確立する前に
、オリジナルのＲＯＵＴＥ ＲＥＱＵＥＳＴメッセージへの返答であるＲＥＰＬ
Ｙメッセージが受信された場合には、このＲＥＰＬＹメッセージは適時なもので
はないが、判定ステップ７１０の出力パス「ＹＥＳ」に従って、ステップ７１５
において、この非適時なＲＥＰＬＹメッセージによって定義されるルートを介し
て、宛先ノードに対するパケットの送信を送信元ノードが開始してもよい。新規
に形成されたピコネットを通してより効率のよいルートが形成されるまで、又は
、すべてのパケットを宛先ノードに対して送信が完了するまで、ステップ７２０
の出力パス「ＮＯ」に従って、この処理を継続する。

【００３７】 新規ピコネットの生成 上述したように、本発明は、ルーティング処理が希望する宛先ノードへのルー
トを発見しようと試行する際に、新規のピコネットを形成することを可能にする
ものである。この処理は、既存のピコネット上でのルート要求処理が失敗しとき
、又は、送信元ノードが、既存ピコネットのいずれのメンバーにも属していない
ときに実行される。

【００３８】 リクエストを受信したノードに新規ピコネットの確立を許可することを通知す
るためには、特別な要求が必要である。これは、ＲＥＱＵＥＳＴメッセージパケ
ットのヘッダーに１ビットの表示を用いて達成することができる。この要求は、
他のノードが新規なピコネットの形成を所望する場合に、他のノードが新規なピ
コネットを形成することができることを何らかの意味において当該他のノードに
通知する特別なものとなろう。この要求を受信するノードはいくつかのオプショ
ンを有している。第１は、ピコネットの形成が発生した際に、既存のピコネット
上でこの要求を再度放送するものである。第二は、ノードらが新規のピコネット
を形成し、そして要求を再度放送するものである。あるいは、ノードらが、既存
のピコネット上で再度放送するだけのものである。一方のＢＴユニットのために
新規なピコネットを形成することによって、他のＢＴユニットがリソースを無駄
にすることは望ましくないので、最後の案が必要とされる。ノードはまた、自身
によって、他のいくつかのノードからピコネットの確立（ＰＡＧＥに対するＰＡ
ＧＥ ＲＥＱＵＥＳＴ）を受け入れられるか受け入れられないかを判定すること
ができる。

【００３９】 ルート探索処理を実行する一方で、新規ピコネットを形成するといったコンセ
プトは、原理的に、送信元ノードがネットワーク内における他のすべてのノード
へと到達できるようなピコネットを形成するものである。従って、多少なりとも
宛先ノードへの到達が可能である場合に、宛先ノードへのルートが得られること
になろう。

【００４０】 実際のピコネット確立プロシージャは、ノードら（送信元ノードと要求を転送
するノードと）が、周辺環境をスキャンするＩＮＱＵＩＲＹモード、すなわち隣
接探索処理に移行しなければならないことを意味する（他のノードはＩＮＱＵＲ
Ｙスキャンモードに移行していなければならない）。その後、どのノードに接続
すべきであるか及びどのようにして新規のピコネットを形成すべきであるかに関
して、ある種のスマートな決定をすることができる。ノードは、新規なピコネッ
トらを全体的に生成するか又は既に存在するピコネットらを統合するためのオプ
ションを有している。これは、ノードに対しどの位の量の情報が有効であるかに
依存している。これには、ピコネットのメンバーアドレスや、どのピコネットが
パケットを転送する能力があるか、どのノードがスレーブで、どのノードがマス
タで、どのノードがスレーブ及びマスタの双方であるかのような情報を含むこと
ができよう。

【００４１】 スマート決定が実行されると、ノードは実際にＰＡＧＥモードに移行すること
によりコネクションを確立し、接続の相手となるノードへとＰＡＧＥパケットが
送信されることになろう。デフォルトでは、新規ピコネットのマスタは、役割を
変更するためのマスタ／スレーブ変換処理を選択することができる。ノードは、
ピコネットの形成の対象となるすべてのノードとマスタ／スレーブ変換処理を実
行できる。結果として、多数の新規ピコネットが形成されたり、既存のピコネッ
トの再構築がなされたりすることになろう。

【００４２】 上位プロトコルレイヤーの放送 上述の記述は、送信元ノードが宛先ノードのＢＤ＿ＡＤＤＲについての知識を
有しているときに説明として成り立つものであった。しかしながら、米国特許出
願第０９／４５５，４６０号にいて開示されている放送により起動されるルート
探索処理が用いられ、かつ、ＮＡＬの上位プロトコルによって取り扱われる（例
えば、ＡＲＰやＤＨＣＰなどの）上位プロトコルレベル放送に関して用いられる
場合には、少々の相違点が生じることになる。主たる相違点は、宛先アドレスが
放送アドレスであり、特定ノードのアドレスではない点である。これは、これま
でに説明してきたプロシージャと以下に説明するプロシージャとが、いささか相
違することを意味する。

【００４３】 送信元ノードは最初に既存のピコネット上で要求を試行すると説明してきたが
、このケースでは、ルート要求パケット内における放送データをピギーバックし
、送信元ノードにおいて情報をバッファリングすることにする。この情報は、多
少の時間が経過した後にルートを要求できるようにすべく、バッファリングされ
るものである。

【００４４】 タイムアウト機能についても少々異なることになろう。宛先ノードへのルート
要求が、予め定められた時間内に宛先ノードに受信されない場合に、ＢＤ＿ＡＤ
ＤＲアドレスが既知であるノードへのルート要求はタイムアウトするだろう。し
かしながら、放送によるシナリオでは、この処理は上手く動作しないであろう。
なぜなら、ルート要求は、放送アドレスを含んでいるのであって、特定の宛先ノ
ードのＢＤ＿ＡＤＤＲアドレスを含んではいないという事実があるからである。
よって、送信元ノードにおいて上位レベル放送のトラックを維持することが解決
策になる。これらの放送に対する応答は、ピギーバックされたデータを用いたル
ート応答である（ルート応答はピギーバックのルート応答になろう。）。ゆえに
、ピギーバックのルート応答が受信されなければ送信元ノードはタイムアウトを
実行でき、そして、新規ピコネットの形成を許可するルート要求プロシージャを
開始することができよう。

【００４５】 しかしながら、この解決方法に関するひとつの課題がある。それは、ピギーバ
ック要求を、収集したピギーバック応答にどのようにしてマッピングするかであ
る。ＮＡＬは、上位レベルプロトコルとは独立しており、これらのレイヤーから
の情報を使用することができない。宛先ノードでさえも収集要求を収集応答にマ
ッピングすることができないという事実に問題は依拠している。この問題の解決
方法は、データをピギーバックする、放送によりトリガーをかけられたルート要
求を、ノードごとに同時にただ１つだけを許可することである。これは、ノード
が、収集された要求に対し、応答を容易にマッピングする（１対１に対応付ける
）ことが可能なことを意味する。従って、この解決方法は、新規のピコネットの
形成を許可するための放送の数を制限することになろう。とにかく、同時に複数
のピコネットを形成するための複数の放送を備える必要はないことに注意すべき
である。あるいは、上位レベル放送はピコネットの確立を抑制してもよく、すな
わち、データをピギーバックする通常のルート要求を使用するだけである。

【００４６】 ピギーバックデータによる応答が受信されない場合には、第２のフェーズを起
動し、例えば、新規のルート要求において放送データをピギーバックし、このと
きにピコネットの形成が可能となる。

【００４７】 この種の上位レベル放送は、新規のピコネットの形成を許可するものであるが
、放送の数は制限されなければならず、例えば、どの位の頻度で放送すべきかを
定義するいくつかの時間間隔が存在しなければならない。その理由は、簡単で、
不要な数の放送を制限するためである。なお、放送間の時間間隔が十分に短けれ
ば、ピコネットの形成を許可するための複数の放送を送信することに利点はない
。

【００４８】 データパケットの取り扱い処理 パケットをルーティングするためのルートをルーティングプロトコルが検索す
る一方で、ルーティングプロトコルへと搬送されるすべてのデータパケットにど
のような処理が施されるべきであろうか。ここでは２つの重要な案を紹介する。
第１は、パケットを予めバッファリングしておき、有効なルートを使用して応答
が受信されるや否や、バッファリングされていたパケットを送信するものである
。使用されるバッファはサイズが制限されており、バッファが一杯になったとき
にパケットを出力（ドロップ）する。どれをドロップするかを決定するためには
、ＦＩＦＯポリシーを使用することになろう。第２は、パケットをドロップし、
ドロップされたパケットをＴＣＰのような上位レイヤーが処理することを可能に
することである。

【００４９】 この問題は、リクエストメッセージが既存のピコネットを使用する際だけでな
く、新規のピコネットが確立される際の双方のケースにおいて重要である。しか
しながら、二つのケースは、タイムスケールが異なる点で相違している。新規ピ
コネットを形成する必要があるならば、ルーティングするためには、よりずっと
長い時間が必要となろう。

【００５０】 放送についての上述の機構をノードが使用するといったケースでは、ノードは
上位レイヤーからのデータ、例えば、要求メッセージにおいてピギーバックされ
るデータを、バッファリングしなければならない。これは、ノードが要求を再度
試行することを補償するものである。

【００５１】 本発明の主たる対象はＢｌｕｅｔｏｏｔｈであるが、本発明はＢｌｕｅｔｏｏ
ｔｈシステムに適用が限定されるものではない。本発明の主たる適用対象は、複
数のネットワークを含むデジタルパケットベースの(有線又は無線の）通信シス
テムである。各ネットワークは、ポイント・ツー・ポイント回線により相互に接
続される複数のノードにより構成される。ネットワークにおける転送処理は、ネ
ットワークレイヤーか、又は、リンクレイヤーとネットワークレイヤーとの間に
配置されるアダプテーションレイヤーにおいて実行され、また、対応する各レイ
ヤーに含まれるルーティング情報を基礎としている。そのようなシステムで使用
されているルーティングプロトコルは、オンデンマンド型のプロトコルであり、
要求メッセージと応答メッセージを用いて、必要とされる場合にルートの探索が
実行されるものである。本発明は、ある宛先ノードへとルーティングを希望する
ときに、ノードらによって実行される機構を提供するものである。

【００５２】 ２ステップの処理は以下のように要約することができる。第１に、ある宛先ノ
ードへとパケットをルーティングする必要性がノードに存在するときに、ルーテ
ィングプロトコルが起動される。送信元ノードは、ＲＯＵＴＥ ＲＥＱＵＥＳＴ
メッセージをネットワーク内に行き渡らせる。ここので重要な観点は、第１のル
ート要求は、既存のネットワーク内のノードにだけ行き渡らせる点である。従っ
て、いずれのネットワークにも所属していないノードがこのメッセージを受信す
ることはない。ノードは、第１のルート要求に失敗すると、新規のルート要求を
ネットワーク内に行き渡らせる。この新規のルート要求は、既存のネットワーク
に新規のノードを接続できる点において、特別な要求メッセージである。従って
、宛先ノードへと到達可能であれば、送信元ノードは宛先ノードへのルートを確
保できる。

【００５３】 上述のように、本発明は、多数の例示的な実施形態を用いて説明されてきた。
しかしながら、当業者であれば、上述の特定の例示的な実施形態とは異なる特定
の形態において本発明を適用可能であることが理解できよう。これは、本発明の
技術思想から乖離することなく実行可能である。これらの例示的な実施形態はま
さに説明目的のためのものであり、どのような場合にも限定であると解釈しては
ならない。本発明の技術的範囲は添付のクレームによって確定されるのであって
、前述の説明によっては限定されず、特許請求の範囲内に含まれうる設計変更及
び本発明と均等なものは、本発明の技術的範囲として含まれることが意図されて
いる。

【図面の簡単な説明】

本発明の目的と有利な効果は、以下の図面と関連付けて詳細な説明を読むこと
により理解できるであろう。

【図１】 ３つの例示的なピコネットを示す図である。

【図２】 例示的なスキャッタネットを示す図である。

【図３】 Ｂｌｕｅｔｏｏｔｈデータパケット用の標準フォーマットを示す図である。

【図４】 Ｂｌｕｅｔｏｏｔｈベースのネットワークに関連するプロトコルレイヤーを示
す図である。

【図５】 ネットワーク・アダプテーション・レイヤーを含む、Ｂｌｕｅｔｏｏｔｈベー
スのネットワークに関連するプロトコルレイヤーを示す図である。

【図６】 本願発明の例示的な実施形態に関するルート探索の達成技術を示した図である
。

【図７】 本願発明の例示的な実施形態に関するルート探索の他の達成技術を示した図で
ある。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ，ＴＲ)，ＯＡ(ＢＦ ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ， ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，Ｇ Ｍ，ＫＥ，ＬＳ，ＭＷ，ＭＺ，ＳＤ，ＳＬ，ＳＺ，ＴＺ ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ， ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＥ，ＡＧ，ＡＬ，ＡＭ， ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，Ｂ Ｚ，ＣＡ，ＣＨ，ＣＮ，ＣＲ，ＣＵ，ＣＺ，ＤＥ，ＤＫ ，ＤＭ，ＤＺ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＤ，ＧＥ， ＧＨ，ＧＭ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，ＩＮ，ＩＳ，Ｊ Ｐ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＡ，ＭＤ，ＭＧ，ＭＫ， ＭＮ，ＭＷ，ＭＸ，ＭＺ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，Ｒ Ｏ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ ，ＴＭ，ＴＲ，ＴＴ，ＴＺ，ＵＡ，ＵＧ，ＵＺ，ＶＮ， ＹＵ，ＺＡ，ＺＷ (72)発明者 セレンセン， ヨハン スウェーデン国 エスレヴ エス−241 91， エストラ ストレ 25 ホルマ Ｆターム(参考） 5K030 HA08 HC14 HD07 JL01 LB05 LD02 5K033 CB01 CB06 CB13 DA05 DA19

Claims (12)

【特許請求の範囲】
1. 【請求項１】 通信ネットワークにおいて、送信元ノードから宛先ノードへと送信されるデー
   タパケットのルートを確立する方法であって、 前記送信元ノードと前記宛先ノードとの間の既存のネットワークコネクション
   上でのルート探索を要求するステップと、 前記送信元ノードと前記宛先ノードとの間の既存のネットワークコネクション
   上でのルート探索処理が失敗したかを判定するステップと、 前記送信元ノードと前記宛先ノードとの間の既存のネットワークコネクション
   上でのルート探索処理が失敗したと判定されると、一以上の新規のネットワーク
   コネクションを形成することにより、前記送信元ノードと前記宛先ノードとの間
   にルートを確立するステップと を含む方法。
2. 【請求項２】 前記送信元ノードと前記宛先ノードとの間の既存のネットワークコネクション
   上でのルート探索処理が失敗したかを判定するステップは、さらに、 前記ルート探索の要求に対する適時の応答を前記送信元ノードが受信したかを
   判定するステップをさらに含む請求項１に記載の方法。
3. 【請求項３】 前記通信ネットワークは、アドホック・ネットワークである請求項２に記載の
   方法。
4. 【請求項４】 前記通信ネットワークは、Ｂｌｕｅｔｏｏｔｈ技術を基礎としたネットワーク
   である請求項３に記載の方法。
5. 【請求項５】 一以上の既存のサブネットワークを含むアドホック型の無線通信ネットワーク
   において、送信元ノードと宛先ノードとの間でデータパケットを送信するための
   ルートを確立する方法であって、 一以上の既存サブネットワークに関連する一以上のコネクションを介し、前記
   送信元ノードと前記宛先ノードとの間のルートを探索するためのルート探索要求
   メッセージを放送するステップと、 前記放送されたルート探索要求メッセージに対する応答として前記送信元ノー
   ドによって受信された応答メッセージが適時であったかを判定するステップと、 前記応答メッセージが適時に受信されなかったと判定された場合には、一以上
   の新規に形成されたサブネットワークに関する一以上の新規なコネクションを介
   して、前記送信元ノードと宛先ノードとの間にルートを確立するステップと を含む方法。
6. 【請求項６】 前記送信元ノードが、前記一以上の既存のサブネットワークのメンバーでない
   場合に、一以上の新規に形成されたサブネットワークに関連する一以上の新規な
   コネクションを介して、前記送信元ノードと宛先ノードとの間にルートを確立す
   るステップをさらに含む請求項５に記載の方法。
7. 【請求項７】 前記宛先ノードが、前記一以上の既存サブネットワークのメンバーでない場合
   に、一以上の新規に形成されたサブネットワークに関連する一以上の新規なコネ
   クションを介して、前記送信元ノードと宛先ノードとの間にルートを確立するス
   テップをさらに含む請求項５に記載の方法。
8. 【請求項８】 前記ルート探索要求メッセージに対する適時な応答が前記送信モードによって
   受信された場合に、一以上の新規に形成されたサブネットワークに関連する一以
   上の新規なコネクションを介した前記送信元ノードと宛先ノードとの間のルート
   が好ましいかを判定するステップをさらに含む請求項５に記載の方法。
9. 【請求項９】 前記応答メッセージが適時に受信されたと判定され、かつ、一以上の新規に形
   成されたサブネットワークに関連する一以上の新規なコネクションを介した前記
   送信元ノードと宛先ノードとの間のルートが好ましくないと判定された場合に、
   一以上の新規に形成されたサブネットワークに関連する一以上の新規なコネクシ
   ョンを介して、前記送信元ノードと宛先ノードとの間にルートを確立するステッ
   プをさらに含む請求項８に記載の方法。
10. 【請求項１０】 前記応答メッセージが適時に受信されたと判定され、かつ、一以上の新規に形
    成されたサブネットワークに関連する一以上の新規なコネクションを介した前記
    送信元ノードと宛先ノードとの間のルートが好ましいと判定された場合に、一以
    上の新規に形成されたサブネットワークに関連する一以上の新規なコネクション
    を介して、前記送信元ノードと宛先ノードとの間にルートを確立するステップと
    、 同時に、一以上の新規に形成されたサブネットワークに関連する一以上の新規
    なコネクションを介した前記送信元ノードと宛先ノードとの間のルートを探索す
    るためのルート探索処理を開始するステップと をさらに含む請求項８に記載の方法。
11. 【請求項１１】 前記アドホック型の無線通信ネットワークは、Ｂｌｕｅｔｏｏｔｈ技術を基礎
    としたネットワークである請求項５に記載の方法。
12. 【請求項１２】 前記既存のサブネットワーク及び新規に形成されたサブネットワークはピコネ
    ットであることを特徴とする請求項１１に記載の方法。