JP3840197B2 - ブルートゥースオンデマンドルーティング方法及びブルートゥースグループアドホックネットワークにおける通信方法 - Google Patents
ブルートゥースオンデマンドルーティング方法及びブルートゥースグループアドホックネットワークにおける通信方法 Download PDFInfo
- Publication number
- JP3840197B2 JP3840197B2 JP2003121433A JP2003121433A JP3840197B2 JP 3840197 B2 JP3840197 B2 JP 3840197B2 JP 2003121433 A JP2003121433 A JP 2003121433A JP 2003121433 A JP2003121433 A JP 2003121433A JP 3840197 B2 JP3840197 B2 JP 3840197B2
- Authority
- JP
- Japan
- Prior art keywords
- node
- slave
- master
- bluetooth
- route
- 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
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/26—Route discovery packet
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/46—Cluster building
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W40/00—Communication routing or communication path finding
- H04W40/24—Connectivity information management, e.g. connectivity discovery or connectivity update
- H04W40/28—Connectivity information management, e.g. connectivity discovery or connectivity update for reactive routing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W48/00—Access restriction; Network selection; Access point selection
- H04W48/08—Access restriction or access information delivery, e.g. discovery data delivery
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/10—Connection setup
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W84/00—Network topologies
- H04W84/18—Self-organising networks, e.g. ad-hoc networks or sensor networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
- H04W88/02—Terminal devices
- H04W88/04—Terminal devices adapted for relaying to or from another terminal or user
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D30/00—Reducing energy consumption in communication networks
- Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Mobile Radio Communication Systems (AREA)
- Small-Scale Networks (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明はブルートゥースグループにおける通信方法に関し、さらに詳しくはピコネットの数を最小化しネットワークを形成するブルートゥースオンデマンドルーティング方法、並びにブルートゥースグループアドホックネットワークにおける通信方法に関する。
【０００２】
【従来の技術】
まず、ブルートゥースネットワークにおける従来のネットワークフォメーションアルゴリズムについて説明する。
Salonidis等はスキャタネットフォーメーションのためのブルートゥーストポロジコンストラクションプロトコル(Bluetooth Topology Construction Protocol:BTCP)を提案した。このＢＴＣＰでは、３つの段階がある。一番目の段階では、対称リンクフォメーションのための状態変更技術を用いて、全てのノードについて情報を有している調整者(コーディネータ)が選択される。二番目の段階において、選択された調整者は各ノードの役目を決める。三番目の段階において、実質的な連結が行なわれる。ＢＴＣＰでは、全てのノードが互いの無線範囲内に位置するという条件に基づく。
【０００３】
このような条件の下で、そして規定された全てのノードに基づき、Aggarwal等は、ネットワークを個別的なピコネットクラスタにグループ化した。全てのノードに対する情報を有している、いわゆる「スーパマスタ(super-master)」が選択されれば、ピコネットの再構成過程及びピコネット間の連結がこのスーパリーダーの監視により、または調整により行なわれる。
【０００４】
Law等は、Ｏ(log n)倍の複合度及びＯ(ｎ)のメッセージ複合度を有する一段階スキャタネットフォメーションアルゴリズムを開示した。これによれば、全てのノードがただ一つのリーダーを有するよう分離される。その構成要素は、互いに連結されたノード群である。リーダーは、「シーク/スキャン(seek and scan)」段階に入り、選択的に「連結(connection)」、「マージ(merge)」、「ミティゲート(mitigate)」または装置移動などのプロセスを実行する。しかし、Law等が開示したことによると、全てのノードが互いの通信範囲内になければならないという制限が問題である。
【０００５】
ブルーツリーアルゴリズム(Blue-tree algorithm)では、ノードは、自分がルートノード(root node)であるか否かと、自分のワンホップ(one hop)周辺機器を知っていなければならない。
【０００６】
Tan等はそれぞれルート及びループフリー経路(loop free path)を一つずつ具備することにより、パケットのルーティング及びスケジュール調整を単純化した。しかし、このようなツリー型構造では、ジョイントノードが一つのピコネットではマスタであり、別のピコネットではスレーブなので二つのピコネットが互いに密接になる場合がある。
【０００７】
ところが、前述した全てのアルゴリズムが実際のトラフィック状況(traffic condition)とトラフィックリクエスト(traffic request)は考慮しないまま、データリンク層における単独の動作にのみスキャタネットフォーメーションの焦点を合わせている。１対１接続（point-to-point link）が、物理的リンクのレベルでスキャタネット全体で接続されたかを確かめるため、トラフィックがほとんどないようなときにも、「アクティブ」状態は、初期のスキャタネットフォーメーションの間、またはその後に周期的に再開されなければならない。
【０００８】
つまり、不要なリンク維持によって、無線通信機器において大事な存在である電力が浪費されている。このような問題に気づいたRaman等はオンデマンド型(on-demand)ルーティングを備えたスキャタネットリンクフォメーションの層間最適化理論を出してきた。しかし、これまでのところ、さらなる詳細な分析や見解については報告されていない。
【０００９】
【特許文献１】
特表２０００−５０２２２２号公報
【００１０】
BhagwatとSegallは形成されたスキャタネットでパケットのトラフィックをルーティングできるルーティングベクトル方法を提案した。Liu Y．は新たに定義されたLMP命令言語を使用したネットワークフォメーションを使った。しかし、模擬テストで発見された通り、ブルートゥース内の多くのインクワイアリによりトラフィックの待機時間がかなり延びた。
【００１１】
【発明が解決しようとする課題】
本発明は前述した問題点を解決するために案出されたもので、本発明に係る第１目的は、ネットワークフォメーションとルートを独立的に維持しつつピコネットの数も最小化できるブルートゥースグループアドホックネットワークにおける通信方法を提供する。
【００１２】
また、本発明に係る第２目的は、ブルートゥースのアドホックネットワークシステムでソースが希望する場合だけルートが形成されると共に、バッテリパワーを節約するブルートゥースオンデマンドルーティング方法を提供する。
【００１３】
【課題を解決するための手段】
前述した第１目的を達成するための本発明に係るブルートゥースグループアドホックネットワークにおける通信方法は、互いに隣接した複数個の無線通信装置よりなるブルートゥースグループアドホックネットワークにおける通信方法において、一つのピコネットでだけスレーブであるスレーブノード、一つのピコネットでだけマスタであるマスタノード、２個のピコネットにおいて全てスレーブで動作するスレーブ−スレーブジョイントノード、及び一のピコネットにおいてスレーブで動作すると共に他のピコネットにおいてマスタで動作するマスタ−スレーブジョイントノードを含む複数のピコネットで構成され、少なくとも２個以上のピコネットがスレーブ−スレーブジョイントノードにより連結されるようにしてネットワークを形成する段階と、前記ジョイントノードが、Ｌ２ＣＡＰ上位層から通知されるルーティングトリガーを受信すれば、前記ジョイントノードは前記形成されたネットワークに属する前記ピコネットをブリッジングする段階とを備え、前記ネットワークを形成する段階が、Ｌ２ＣＡＰとＢＮＥＰとの間に位置しているネットワークフォメーションプロトコルによって、ＩＰ層に位置しているネットワークルーティングプロトコルの案内の下で、いずれのノードが、前記スレーブノード、前記マスタノード、前記スレーブ−スレーブジョイントノードおよび前記マスタ−スレーブジョイントノードであるかを決める段階を含むことを特徴とする。
【００１４】
また、前記スレーブノードは新たなマスタにより発見されるようインクワイアリスキャンを規則的に行ない、ルーティングトリガー信号を受信すれば、近くのネットワークを探すためにインクワイアリを行なうことが望ましい。
【００１５】
そして、前記スレーブノードは新たなマスタにより発見され新たなリンクが追加されればジョイントノードになることが望ましい。
【００１６】
また、前記マスタノードは通信可能範囲に位置するフリーノードを発見するために規則的にインクワイアリを行ない、前記マスタノードが別のマスタノードと互いに無線範囲にある際、別のマスタノードにより発見されるよう規則的にインクワイアリスキャンを行ない、他のマスタノードによって発見されればスレーブノードに転換されることが望ましい。
【００１７】
また、前記ルーティングトリガーはルーティングプロトコルまたは管理部で発生する信号であって、少なくとも Route REQuest(RREQ) 、 Route REPly(RREP) または Route ERRor(RERR) のうちの一つであることが望ましい。
【００１８】
また、同一のピコネットまたは同一のネットワークに属するノードのデータ構造は、テーブルで記録されており、前記テーブルに基づきルーティングが行なわれることが望ましい。
【００１９】
また、前記テーブルは新たなノードまたは新たなネットワークが発見されたときに更新され、リンクが失われれば該当ノードを前記テーブルから削除することが望ましい。
【００２０】
そして、前記テーブルには、少なくともマスタノードＢＤ−ＡＤＤＲ、スレーブノードＢＤ−ＡＤＤＲ、コネクション寿命、ピコネットまたはネットワーク寿命、及びスレーブ−スレーブジョイントノードのＢＤ−ＡＤＤＲが記録されていることが望ましい。
【００２１】
前述した第２目的を達成するための本発明に係るブルートゥースオンデマンドルーティング方法は、請求項１ないし請求項８のいずれか一項に記載の通信方法で形成されたネットワークを利用したブルートゥースオンデマンドルーティング方法において、前記ネットワークは、前記スレーブノード、マスタノード、スレーブ−スレーブジョイントノード、及びマスタ−スレーブジョイントノードのいずれかであるソースノードと宛先ノード及び互いに独立した複数個のノードを備え、前記ソースノードがルート要求メッセージを送信して前記ソースノードから前記宛先ノードへの全ての中間ノードが前記マスタ−スレーブジョイントノードである多重フォワード経路を設定する段階と、前記ルート要求メッセージを受信した宛先ノードが前記多重設定されたフォワード経路のうちいずれか一つに沿って前記ソースノードにルート応答メッセージを送信して、前記多重設定されたいずれか１つのフォワード経路を構成する隣接した２つのマスタノードの間に前記スレーブ−スレーブジョイントノードを介在させたバックワード経路を設定する段階とを含み、前記設定されたバックワード経路を通して前記ソースノードと宛先ノードとの間に最適の経路であるルートが形成され、前記多重フォワード経路に予め定められたライフタイムが尽きると、前記多重フォワード経路で前記バックワード経路を形成しない経路の連結がパークされることを特徴とする。
【００２２】
望ましくは、前記フォワード経路設定段階は、前記ソースノードが宛先ノードへのルートを必要とし、前記ルートが少なくとも一つ以上利用可能な場合、ルート要求メッセージをブロードキャストする段階と、前記ソースノードで次にホッピングされる少なくとも一つ以上の中間ノードが、前記ルート要求メッセージが前記宛先ノードに到達するまで、前記ブロードキャストされたルート要求メッセージを受信し、さらに次のホッピングノードに前記ルート要求メッセージを伝達する段階とを含む。
【００２３】
ここで、前記ソースノードと前記宛先ノードとの間に連結が設定されれば、ソースノードはマスタとなり、その隣接する中間ノードはスレーブとなり、前記ルート要求メッセージは前記マスタからスレーブに転送されることが望ましい。
【００２４】
また、フォワード経路に沿う全ての中間ノードはマスタスレーブジョイントノードであることが望ましい。
【００２５】
また、前記ルート要求メッセージはその隣接ノードを発見して連結するためにソースノードでインクワイアリ動作を開始するルーティングトリガーであることが望ましい。
【００２６】
一方、前記バックワード経路設定段階は、前記ルート要求メッセージを受信した宛先ノードが前記形成されたフォワード経路のうちいずれか一つに沿って前記ソースノードに向かってルート応答メッセージを転送する段階と、前記宛先ノードで前記ソース方向にホッピングされる中間ノードが、前記ルート応答メッセージが前記ソースノードに到達するまで、前記ルート応答メッセージを受信し、さらに次のホッピングノードに前記ルート応答メッセージを伝達する段階とを含むことができる。
【００２７】
また、前記ルート応答メッセージは、マスタノードの間にスレーブ−スレーブジョイントノードを介在させるために、マスタ／スレーブスイッチングを開始するルーティングトリガーの役目を果たすことが望ましい。
【００２８】
さらに、前記マスタ／スレーブスイッチングは、前記宛先ノードから偶数離隔されたノードとその次のホッピングノードとの間で行なわれることが望ましい。
【００２９】
【発明の実施の形態】
以下、添付した図面に基づき本発明を詳述する。
ＩＥＥＥ８０２．１１ｂでは、同期化はフレーム別になされ事前リンク設定過程がないため、いずれのノードも互いの無線範囲内に位置すれば通信が行なえると記述している。これによれば、ネットワークは常に使用できるということである。マルチ−ホッピングの場合を挙げれば、ネットワーキングはルーティングアルゴリズムのために施される。ネットワーク形成システムのための８０２．１１における下部層(sub-layer)プロトコルスタックはない。
しかし、ブルートゥースノードはパケットを転送する前にまずピコネットを形成すべきである。簡単に説明すれば、ルーティングプロトコルと定義されたプロファイルは、ネットワークが構成された以降は主にソース(source)と宛先(destination)に重点をおいている一方、ネットワーク形成(network formation)は、ルートだけではなく、このソースと宛先との間におけるデータリンク層を基準に「より良質」なルートを提供し維持させるところにも重点をおいている。
【００３０】
二つのノード間には多数個の経路が存在でき、そのうち経路とルートを選択することがルーティングアルゴリズムと定義されたプロファイルの目的である(ここで、「経路」と「ルート」とに用語を分離して使用するのは、「経路」は二つのノード間の全てのネットワーク連結を、「ルート」はパケット転送のためにルーティングプロトコルにより選択された一つの経路を指すためである)。勿論、ルーティングアルゴリズムと定義されたプロファイルもネットワークの構成を助けることができる。この目的で知られているものが「オンデマンド型(on-demand)」ＭＡＮＥＴルーティングアルゴリズムの「ルートディスカバリー(Route Discovery)」である。また、マルチキャスティングとＱｏＳ保証(QoS guarantee)もルーティングプロトコル上でなされる。一方、全てのノードを選択されたルートを通して再構成することにより、ブルートゥース物理層及びデータリンクの次元でより良質のパケット転送を行なうようにすることがネットワーク形成の目的である。ここで、その重点は、「より良質」なネットワークである。従って、いつ、そしていずれのノードがマスタになり、スレーブになるべきか、またはソースと宛先の間のルート上にいずれの種類のジョイントノードがあるかを決定するのが非常に重要になる。
【００３１】
図１は、ブルートゥースグループアドホックネットワークで使用されるプロトコルスタックを示す。
【００３２】
ブルートゥースＳＩＧは、ブルートゥースノードとアプリケーションのネットワーキング能力を提供するため、ＢＮＥＰ(Bluetooth Network Encapsulation Protocol)層を定義している。
【００３３】
ネットワークフォメーション２６は、Ｌ２ＣＡＰ(Logical Link Control & Adaptation Protocol)２８とＢＮＥＰ２５の間に位置している。ネットワークフォメーション２６の主な目的は、ブルートゥースのデータリンク層及び物理層の観点から、早く、より良質のブルートゥースピコネット及びスキャタネットを実現するところにある。ネットワークフォメーション２６は、ルーティングプロトコルと通信可能である。
【００３４】
図１に示すように、ルーティングプロトコルはＩＰ層２４内に位置すると仮定する。これは、ルーティングプロトコルなどの上位層でブルートゥースを実行することを隠している。
【００３５】
一般に、ルーティングプロトコルは既存のネットワークトポロジのうち最善のルートを探し出すためのものである。ルーティングプロトコルの案内の下で、ネットワークフォメーション２６は、いずれのノードがマスタであり、いずれのノードがスレーブであるか、またはいずれの種類のジョイントノードであるかを決める。
【００３６】
与えられたネットワーク直径において最小限のピコネットを使用してネットワークを形成すれば、ピコネット間に干渉が少なくなり、隣接ピコネットとのパケットスケジューリングが少なくなる。その結果、ネットワークの維持が容易になる。
【００３７】
それぞれ動作は違うが、ルーティングプロトコルとネットワークフォメーションは、ブルートゥースグループアドホックネットワーク(Bluetooth Group Ad hoc network)に基づいて密接に関連している。
【００３８】
ここで、「Ｌ３トリガー(L3 trigger)」を、ネットワークフォメーションがルーティングプロトコルやその他の上位層のプロファイルと通信するためのメカニズムと定義する。Ｌ３トリガーの詳細については後述する。
【００３９】
図１の矢印はプロファイル、ルーティングプロトコル、及び管理部をネットワークフォメーションと連結するための信号線を示す。ネットワークフォメーションは、メッセージや命令を上位層のプロトコルまたはプロファイルと交換できる。
【００４０】
ネットワークフォメーション２６は、定義されたプロファイルまたはルーティングプロトコルの制御によって、より良質のネットワーク、ひいてはマルチホッピングネットワーク形成のためのユーティリティを提供する。一般に、小直径であり、パケット間の衝突が少なく、周辺ピコネットとの重複が少なく、ピコネット間スケジュールが多いネットワークであるほど、ピコネットの数も少なくなることは当然である。そして、ネットワークのメンテナンス費用は、できるだけ低価格にするべきである。
【００４１】
図２は、アドホックネットワークにおいてブルートゥースノードのプロトコルスタックを簡略に示す図である。
【００４２】
同図を参照すれば、ブルートゥースグループアドホックネットワーク環境下で、ルーティングプロトコルとネットワークフォメーションがどのように協調しているのかが分かる。ネットワーキングアプリケーション層２１、ルーティングプロトコル３３、及びネットワークフォメーションプロトコル２６の間に信号管(signaling pipe)が存在する。ネットワークアプリケーション層２１が二つのノード間の通信を初期化する。ルーティングプロトコルが宛先へのルートを分かっている場合なら、データパケットは直接に宛先に転送される。ルーティングプロトコルが宛先へのルートを分かっていない場合なら、ルーティングプロトコルは下に位置したネットワークフォメーション層２６に宛先への利用可能な経路を問い合わせる。ネットワークフォメーションプロトコルでソースと宛先の間で利用可能な経路があるならば、すべての利用可能な経路がルーティングプロトコルとして報告される。ルーティングプロトコルとネットワークフォメーションプロトコル間ではそれぞれストラテジと考慮要素が違うので、それぞれ記憶するネットワークトポロジは違ってくる。
【００４３】
ネットワークフォメーションプロトコル２６は、ルーティングプロトコル３３に比べてネットワークトポロジについてさらに情報を持つべきである。ルーティングプロトコル３３は、それらのうち一つのルートを選択する。もし、ネットワークフォメーションプロトコル２６に宛先への利用可能な経路がなければ、ルーティングプロトコル３３は、ＨＣｌ要求を通じて「インクワイアリ/ページ(Inquiry and page)」プロセスを開始し、近接したノードとの連結を設定する。すると、ネットワークトポロジ情報または宛先要求は、２個の近接ノードのネットワークフォメーションプロトコル間で交換される。このプロセスは宛先が発見されるか、別の条件により停止するまで繰り返される。
【００４４】
次に、ブルースターネットワークで使用される用語について定義する。
●フリーノード：別のノードと連結されないノード
●スレーブノード：一つのピコネットでだけスレーブメンバーであるノード
●マスタノード：一つのピコネットでだけマスタメンバーであるノード
●ジョイントノード：少なくとも二つ以上のピコネットでメンバーであるノード。ノードが加入できる最大ピコネットの数はＭである。ノードがＭ＋１番目のピコネットに加入した後、Ｍ個のピコネットのうち一つのリンクはダウンされるべきである。スキャタネットには、２種類のジョイントノード、すなわちＳ−ＳジョイントノードとＭ−Ｓジョイントノードがある。
●Ｓ−Ｓジョイントノード：両ピコネットにおいてスレーブで動作するジョイントノード
●Ｍ−Ｓジョイントノード：一のピコネットにおいてスレーブで動作すると共に他のピコネットにおいてマスタで動作するジョイントノード
●中間ノード：別のノードへ予定されたパケットを転送するのに同意したノード
●フォワード経路：ルートディスカバリー動作を開始したノードから所望の宛先に向かってデータパケットを転送するために設定された経路
●リバース(バックワード)経路：宛先ノードまたは宛先へのルートを有する中間ノードからソースにＲＲＥＰパケットを転送するために設定された経路
●ルーティングトリガー：特定イベントが発生したり、または発生しようとすることを知らせるオンデマンドルーティングプロトコルからの通知。この通知はパラメータ情報を含むことができ、ブルートゥースベースバンドで動作が開始される。ルーティングプロトコルはＩＰ層、管理者部、またはブルートゥースデータリンク層に位置することができる。
●インクワイアリ状態：ノードがインクワイアリトレインに応答すれば、２個のノード間にリンクを形成するようページ進行が行なわれる。
●休止(dormant)状態：コネクション状態及び待機状態、例えばホールドモード、スニフモード、及びパークモードなどのバッテリパワーを節約するためのブルートゥースノードの省電力状態
●ブルースターアイランド：ジョイントノードがＳ−Ｓジョイントノードであるピコネットまたはスキャタネット。ブルースターにおいて「スター」はスター型ネットワークトポロジ(topology)を示す。
●ピコネットにおいてマスタは中央である。Ｓ−Ｓジョイントノードを有するスキャタネットでは２個の中央がある。
【００４５】
図３は、本発明に係るオンデマンドルーティング方法において、フォワード経路とバックワード経路でのノードの機能を示す図である。
【００４６】
図３に示すように、ノードはフリーノード、マスタノード、スレーブノード、及びジョイントノードの４つの機能を果たすことが出来る。全てのノードは初期にフリーノードである。ルートの観点から説明すれば、パケットフォワードルートに沿って、ノードはソースノード、中間ノードまたは宛先ノードと称される。
【００４７】
全てのノードは、いずれの状態にあっても規則的にインクワイアリスキャン状態に入る。これは、ノードの状態にかかわらず発見できるようにするためである。
【００４８】
オンデマンドネットワーク形成は、ソースノードにより要求される時だけ可能である。その前は、全てのノードは独立している。ソースノードがパケットをある宛先ノードへ転送しようとし、宛先ノードへの有効なルートを有していなければ、ルーティングアルゴリズムは宛先を発見するために経路発見プロセスを開始する。
【００４９】
この経路発見プロセスは、宛先ノードへの経路が発見されるか、全ての可能な経路交換が検索されれば終了する。
【００５０】
ソースノードは、ＲＲＥＱメッセージをブロードキャストする。ルーティングプロトコルにおけるＲＲＥＱメッセージは、その隣接ノードを発見して連結するためにソースノードのベースバンドでインクワイアリ動作をトリガーする。
【００５１】
ルーティングプロトコルにおいて、宛先へのルートが必要であり、一つも利用可能なルートがない場合、ＲＲＥＱメッセージはブロードキャストされる。ノードはＲＲＥＱメッセージをその連結されたノードに送信する。
【００５２】
そのノードにとって、ＲＲＥＱメッセージは、ベースバンドでインクワイアリ動作を開始する「ルーティングトリガー」である。しかし、次の四種の場合は除外する。
【００５３】
第１に、Ｎ(Ｎ≦７)個のアクティブスレーブがマスタノードについて予め連結されている場合であり、第２に、ジョイントノードにより連結されているＭ個のピコネットがある場合である。第３に、ＲＲＥＱメッセージのＴＴＬ(time-to-leave)フィールドがルーティングプロトコルで終了する場合である。第４に、複写されたＲＲＥＱメッセージが受信される場合である。
【００５４】
インクワイアリ動作において新たなノードが発見されるイベントにおいて、ノードはマスタになり、新たなノードは新たに形成されたピコネットでスレーブになる。ＲＲＥＱメッセージはＢＮＥＰ連結が形成された後、新たなノードに転送される。もし、新たなノードがＭ＋１番目のピコネットに加わる場合、新たなノードは以前の連結のうちいずれかを切るべきである。
【００５５】
フォワード経路はライフタイム属性を有する。これは、限られた時間内でフォワード経路が確認されるべきであることを意味する。詳しくいうと、ライフタイム属性には、パークライフタイム(park lifetime)とディスコネクトライフタイム(disconnect lifetime)の二つがある。経路ライフタイムはネットワークで連結の属性である一方、ルートライフタイムはルーティングプロトコルでルーティングテーブルの属性である。
【００５６】
フォワード経路に沿って、全ての中間ノードはマスタスレーブジョイントノードである。
【００５７】
次いで、バックワード経路について図３を参照して説明する。
【００５８】
ルーティングプロトコルにおいて、宛先に対するＲＲＥＱメッセージを受信すれば、要求を満たすのに十分なルートを有しており、それ自身が宛先の場合、ノードはＲＲＥＰメッセージを発生する。フォワード経路に沿って、全ての中間ノードはＭ−Ｓジョイントノードである。
【００５９】
ＲＲＥＰメッセージは、進行中のインクワイアリ動作を中止し、バックワード経路に沿ってネットワーク再形成を開始して形成されたピコネットの数を減らすルーティングトリガーである。
【００６０】
一方、ＲＲＥＰパケットは、マスタノードの間にＳ−Ｓジョイントノードを介在させるためにマスタ／スレーブスイッチを開始するルーティングトリガーである。
【００６１】
ネットワーク再形成の原則は、マスタノードの間に可能なＳ−Ｓジョイントノードをインタリーブ(interleave)することである。これは、ピコネットの数を最小化する。
【００６２】
ネットワーク再形成セグメントは開始ノードと終了ノードとの間にある。終了ノードはＲＲＥＰメッセージが発生されるノードである。一方、開始ノードは、マスタで動作する際、空中にＲＲＥＱメッセージが最初に転送された場所である。また、開始ノードは、スレーブで動作する際、空中にＲＲＥＱメッセージが最初に転送された次ホップのノードである。
【００６３】
開始ノードはマスタで動作し、終了ノードはスレーブで動作する。
【００６４】
ネットワーキングアプリケーションプロファイルは、ノードの役目を決めるために高い優先順位を有しうる。マスタ−スレーブスイッチは、偶数離隔されたノードとその次のホップノード間でだけ行なわれる。
【００６５】
他の経路に対するそのルートテーブルは、ＴＴＬが経過しないノードであるか、または存在するネットワークの影響を最小化するためにノードの機能は変化できない。また、固定された機能をピコネットで維持することを希望するノードについては、ノードの機能が変化できない。
【００６６】
図４は、本発明に係るオンデマンドルーティング方法における、多重フォワード経路のうちバックワード経路のルーティングを示す図である。
【００６７】
図４に示したように、転送は、ソースノードＮ０から宛先ノードＮ８へ二つの経路に沿って行われる。しかし、ＲＲＥＰメッセージは、ノードＮ４〜ノードＮ６に沿っては進行しない。これは、ルーティングプロトコルは、それらからルートを一つだけ選択するからである。パークライフタイムが経過すれば、選択されないフォワード経路上のリンクはパークされ、ＡＭ−ＡＤＤＲを返還してバッテリパワーを節約する。ディスコネクトライフタイムが経過すれば、フォワード経路上のリンクは切れ、バッテリパワーをさらに節約するようになる。
【００６８】
次は、ルートエラー及びルートの終了について説明する。
【００６９】
ルーティングプロトコルにおいては、リンクが切れるか、ルートが終了すればＲＥＲＲ(Route ERRor)メッセージが発生されブロードキャストされる。ＲＥＲＲメッセージは、残った連結されたリンクについてパーク動作を開始する「ルーティングトリガー」である。ルーティングプロトコルにおいては、宛先へのルートが終了すれば、経路に沿った連結はパークされ、バッテリパワーを節約する。スレーブノードは、リンクを感知するために周期的に起きている必要がある。宛先へのルートがルートテーブルから削除されれば、経路に沿った連結が切れる。
【００７０】
ブルースターアイランドネットワークフォメーションは、２段階プロトコルである。ブルースターアイランドネットワークフォメーションの第１段階は、フリーノードで自動的に形成される。ブルースターアイランドは、ジョイントノードが両ピコネットでスレーブになるピコネットになることができ、またはスキャタネットとなることができる。電源が供給されたとき、ノードのデフォルトの機能は、フリーノードである。その後、ノードはインクワイアリ状態、インクワイアリスキャン状態、及び休止状態などにその状態を転換する。ノードはそれぞれ独立的であり、互いについて無知の状態である。各ノードはスレーブ資格で接続してスレーブノードになれ、マスタ資格で接続してマスタノードになれる。スレーブノードは、定期的にインクワイアリスキャン状態に入って別のピコネットに発見されることにより、ブルースターアイランドが形成されうる。マスタノードは、他のマスタに発見されるように、インクワイアリ状態に入る。このようにして、二つのマスタノードが互いの無線範囲内に進入することが防止される。全てのブルートゥースノードは自律構成されるので、個別的なマルチブルースターアイランドの形成も可能である。
【００７１】
図５は、二つの隣接したブルースターアイランドが互いに連結できない場合の例を示す図である。
【００７２】
ブルースターアイランドネットワークフォメーションの第２段階は、「Ｌ３トリガー」の開始によりブルースターアイランドをブリッジングすることである。ここで、「Ｌ３トリガー」はルーティングプロトコル、プロファイルあるいは管理部などから転送された短い通知である。例えば、「Ｌ３トリガー」はルーティングアルゴリズムの"Route REQuest"や、"HELLO"のようなメッセージである。また、プロファイルから転送された命令、例えば「サービスディスカバリー」命令も「Ｌ３トリガー」の一例と言える。「Ｌ３トリガー」があった後、全てのエッジノード、スレーブノードなどがインクワイアリ状態を行って無線範囲内に別のスレーブノードがあるかをチェックする。新たなブルースターアイランドが発見されれば、新たなピコネットが形成される。この場合、ジョイントノードは、Ｍ−Ｓジョイントノードを指す。
【００７３】
図６は、ブルースターネットワークフォメーションにおいてノードの役割の転換を示す図であり、図７はそれぞれのノードの状態を示す図である。
【００７４】
図６において、フリーノード５３は、ネットワークが形成される前に存在するノードであって、別のノードと連結を有しないノードと定義される。
【００７５】
フリーノード５３は、パワーオンされた後のデフォルトノードである。フリーノード５３は、別のノードと連結を有せず、連結状態にならない。フリーノード５３は、インクワイアリ状態、インクワイアリスキャン状態、及び休止状態に入る(段階Ｓ５０２)。パワーオンした後、または休止状態から覚めた後、フリーノードは[０，１]間で乱数(Rnode)を発生する。
【００７６】
Rnode<R０ならば、ノードはインクワイアリ状態に入る。
【００７７】
Rnode>R０ならば、ノードはインクワイアリスキャン状態に入る。
【００７８】
インクワイアリとインクワイアリスキャン後にいずれの連結設定もなければ、ノードは休止状態に入る。
【００７９】
トラフィックが発生すれば、フリーノード５３は、インクワイアリ動作を開始する。Ｒ０は、固定された臨界値である（Ｒ０の値はシミュレーションを通してＴＢＤである)。フリーノード５３は、インクワイアリ状態になる確率よりインクワイアリスキャン状態になる確率のほうが高くなくてはならない。フリーノード５３は、トラフィックパケットソースまたはパケット宛先でありうる。式のノードの役割の設定時までフリーノード５３はその役割を維持する。
【００８０】
役割が設定される時、フリーノード５３は、形成されたリンクの状態に応じてマスタノードまたはスレーブノードになれる(段階Ｓ５０４及び段階Ｓ５０５)。そして、スレーブノードまたはマスタノードのリンクが切れれば、スレーブノードまたはマスタノードは、フリーノードに転換される(段階Ｓ５０９、Ｓ５１０)。
【００８１】
スレーブノードは、一つのピコネットでだけスレーブメンバーノードと定義される。
【００８２】
スレーブノード５４は、トラフィックパケットソースまたはパケット宛先になれる。スレーブノード５４は、さらに大きいブルースターアイランドを形成するため新たなマスタにより発見されるようインクワイアリスキャン状態に規則的に入り、トラフィックがなければバッテリパワーを節約するために休止状態に入る(段階Ｓ５０６)。
【００８３】
上位層から「Ｌ３トリガー」を受信すれば、スレーブノード５４は近接したブルースターアイランドを発見するためにインクワイアリ状態に入る(段階Ｓ５０８)。スレーブノード５４のインクワイアリスケジュールは、注意深く配列されるべきである。全てのスレーブノード５４がインクワイアリを同時に行うと、深刻なＩＰパケット衝突が発生するおそれがある。これは、インクワイアリ動作の性能を低下させる。たとえば、連結設定を長くし、帯域幅の浪費を引き起こす。
【００８４】
別のピコネットとのリンクがダウンされるか、新たなリンクが追加されるまで、スレーブノード５４は、その機能を維持する。リンクがダウンされれば、スレーブノード５４はフリーノード５３になるよう転換され、リンクを失う(段階Ｓ５１０)。新たなリンクが追加されれば、スレーブノードはジョイントノードになるよう転換される。
【００８５】
一方、マスタノード５１はパケットソース、パケット宛先及びトラフィックパケットリレーノードになれる。マスタノード５１は、インクワイアリ状態とインクワイアリスキャン状態に規則的に入る(段階Ｓ５１２)。
【００８６】
マスタノード５１は、Ｎ個のアクティブスレーブ(Ｎ<=７)が発見されるまで、その範囲でフリーノードを発見するようインクワイアリ状態に規則的に入る。また、マスタノード５１は、インクワイアリスキャン状態に規則的に入る。これは、互いに無線領域に存する場合、別のマスタにより発見されることを可能にするためである。
【００８７】
第１マスタノードが第２マスタノードにより発見されれば、第１マスタノードは第２マスタノードのピコネットにおいてジョイントノード（Ｍ−Ｓジョイントノード）になる。すると、第１マスタノードは一つのスレーブノードとマスタ−スレーブスイッチングを行い、Ｓ−Ｓジョイントノードになる。
【００８８】
一方、第１マスタノードに属する別のスレーブノードは、新たなピコネットに加わろうとしてジョイントノードになる(段階Ｓ５１４)。スレーブノードは新たなピコネットに加わり、フリーノードになれない。
【００８９】
マスタノードはそれぞれの連結の寿命を記録し、連結を通して転送される全てのパケットについて寿命を更新する。連結寿命が経過した後、連結ノード（スレーブ）は、スレーブ資源になるため休止状態に入るよう命令される。
【００９０】
全てのリンクが切れるか、別のマスタにより発見されるまで、マスタノードはその役割を維持する。全てのリンクが切れるイベントにおいて、マスタノードはフリーノードに転換され、別のマスタにより発見されるイベントで、発見されたマスタノードはスレーブとの全てのリンクを切り、新たなピコネットでスレーブノードに転換される。
【００９１】
ジョイントノード５２は、パケットソース、パケット宛先、及びブルースターアイランドの間でトラフィックパケットリレーノードになれる。ジョイントノードは、近接したブルースターアイランドにより規則的に発見されるようインクワイアリスキャン状態に入れる。上位層において「Ｌ３トリガー」を受信すれば、ジョイントノードはインクワイアリ状態に入って、近接したブルースターアイランドを発見する。
【００９２】
Ｍ＋１番目のピコネットにジョインした後、ジョイントノードは結合寿命とピコネット寿命に基づき、現在のアクティブ連結を切るべきである。いずれにしても、ジョイントノードは、確実にルートボトルノード(bottle node)にならなければならない。Ｍ値はＴＢＤである。バッテリパワーを節減するため、トラフィックがなければジョイントノードは休止状態になる(段階Ｓ５１６)。
【００９３】
ジョイントノード５２は、一つのリンクが切れるまでその役割を維持する。Ｓ−Ｓジョイントノードリンクが切れれば、ジョイントノードはスレーブノードになる(段階Ｓ５１８)。Ｍ−Ｓジョイントノードリンクが切れれば、ジョイントノードは、いずれのノードが切れているのかによってマスタノードまたはスレーブノードになる。
【００９４】
次に、Ｌ３トリガーについて詳述する。
【００９５】
「Ｌ２トリガー」がＬ２層のためだけにＩＥＴＦドラフトで使用されたため、上位層を報告するために「Ｌ３トリガー」と命名された。ＩＥＴＦにおいて、Ｌ２トリガーは、Ｌ２から特定イベントが発生したかあるいは発生しようとするのかの通知の約束である(潜在的にパラメータ情報を含んで)。トリガーは多様な方法で実行できる。ここで、Ｌ３トリガーは、Ｌ２ＣＡＰ上位層から通知を示すよう使用する。
【００９６】
ルーティングプロトコルから、Ｌ３トリガーは、オンデマンドプロトコルでRREQタイプのメッセージであるか、テーブルドリブン及びオンデマンドプロトコルで"HELLO"タイプのメッセージでありうる。ＲＲＥＱメッセージはＩＰアドレスでラベルされたノードを発見するために使用される一方、HELLOメッセージは近接したノードが未だ利用可能なのかを感知するために使われる。別のノードからＲＲＥＱメッセージを受信すれば、スレーブノードは、ソースノードと宛先ノードとの中間に位置して、その到達可能な範囲に宛先があるかをチェックする。これは、ルーティングプロトコルにより行われる。
【００９７】
もし、到達可能な範囲に宛先があれば、ルーティングプロトコルでRREP(Route REPly)メッセージがルーティングアルゴリズムにより発生する。ノードはソースへのバックワード経路に沿ってＲＲＥＰメッセージを送信する。
【００９８】
もし、到達可能な範囲に宛先がなければ、ノードはＬ３トリガー信号を発生して全ての到達可能なスレーブノードに知らせて、アルゴリズムに基づき近接したブルースターアイランドを求めるようインクワイアリを行う。
【００９９】
インクワイアリに応答ノードがなければ、ノードはインクワイアリを中断する。
【０１００】
インクワイアリに応答するノードがあれば、それらの間にＢＮＥＰ連結が発生した後、RREQメッセージはノードに送信される。
【０１０１】
このプロセスは、宛先が発見されるか、最大ホップ(hop)数ｉｄに到達するまで繰り返される。
【０１０２】
このように、RREQメッセージは中間のブルースターアイランドにリレーされる。これとは逆に、HELLOメッセージは近接ノードを感知するためにだけ使用される。いずれの宛先ノードも定義されない。従って、HELLOメッセージは、リレーなしで、かつソースブルースターアイランドでだけ、トリガーを開始することができる。
【０１０３】
Ｌ３トリガーは管理部、限定的なプロファイル、またはサービスディスカバリーから来る場合がある。この場合、ネットワークフォメーションからルーティングプロトコルへの上向インタフェースだけがある。サービスディスカバリーと管理タイプのメッセージはＬ３トリガーでありうる。
【０１０４】
ネットワークトポロジを記録するため、全てのノードは、同一なピコネット及び同一なブルースターアイランドで到達可能なノードリストを維持すべきである。全てのノードはＭ−Ｓジョイントノードを介して通信することができる。ノードの可能なデータ構造は、表１のリストの通りである。新たなノードまたはブルースターアイランドが発見されると、ノードはその記録を加え、全ての到達可能なノードに情報を知らせる。リンクが失われれば、ノードは一つまたは１グループのノードをその記録から削除する。表１は、ルーティングプロトコルからベースバンドへの経路をマッピングしたものである。同一なものがルーティングプロトコルで発生する。コネクション寿命属性は、連結のアクティブ時間を記録するために使われる。リンクにおける全てのパケットは、寿命属性を新しくされる。ブルースターアイランド寿命は、二つのマスタが互いに無線範囲にある時、いずれがスレーブになるのか決めるために使用される。
【０１０５】
【表１】
【０１０６】
テーブル駆動されたルーティングプロトコルは、ネットワーク情報と組み合わせるよう駆動される。ノード記録及びルーティングテーブルは殆んど同一である。オンデマンドルーティングプロトコルの場合、ルーティングテーブル及びノード記録は違う。
【０１０７】
【発明の効果】
以上述べた通り、本発明に係るブルートゥースオンデマンドルーティング方法によれば、バッテリパワーを節約することができ、進行中のトラフィックについて大きい帯域幅を提供することができる。また、バックワード経路に沿うマスタ／スレーブスイッチングにより、より良質のスキャタネット構成が実行できる。
【０１０８】
ネットワークフォメーションとルーティングを互いに重畳させず独立して維持することができ、テーブル駆動及びオンデマンドプロトコルのように全種類のルーティングプロトコルを受け入れられる。また、ジョイントノードがピコネットをブリッジングするので、ピコネットの数を最小化できる。そして、スレーブノードはただインクワイアリスキャンだけ行うため、管理を最小化し、バッテリパワー消費を最小化する。
【０１０９】
以上では本発明の望ましい実施例について説明したが、本発明は、前述した特定の実施例に限らず、請求の範囲で請求する本発明の要旨を逸脱しない限りにおいて、当該発明の属する技術分野において通常の知識を持つ者ならば誰でも多様な変形実施が可能なことは勿論、そのような変更は請求の範囲の記載の範囲内にある。
【図面の簡単な説明】
【図１】ブルートゥースグループアドホックネットワークで使用されるプロトコルスタックを示す図である。
【図２】アドホックネットワークでブルートゥースノードのプロトコルスタックを概略的に示す図である。
【図３】 本発明に係るブルートゥースオンデマンドルーティング方法において、フォワード経路及びバックワード経路時のノードの役割を説明するための図である。
【図４】 本発明に係るブルートゥースオンデマンドルーティング方法において、多重フォワード経路中バックワード経路のルートを説明するための図である。
【図５】二つの隣接したブルースターアイランドが互いに連結されていない場合の例を示す図である。
【図６】ブルースターネットワークフォメーションでノードの役割と役割の転換を示す信号流れ図である。
【図７】それぞれのノードの状態を示す図である。
【発明の属する技術分野】
本発明はブルートゥースグループにおける通信方法に関し、さらに詳しくはピコネットの数を最小化しネットワークを形成するブルートゥースオンデマンドルーティング方法、並びにブルートゥースグループアドホックネットワークにおける通信方法に関する。
【０００２】
【従来の技術】
まず、ブルートゥースネットワークにおける従来のネットワークフォメーションアルゴリズムについて説明する。
Salonidis等はスキャタネットフォーメーションのためのブルートゥーストポロジコンストラクションプロトコル(Bluetooth Topology Construction Protocol:BTCP)を提案した。このＢＴＣＰでは、３つの段階がある。一番目の段階では、対称リンクフォメーションのための状態変更技術を用いて、全てのノードについて情報を有している調整者(コーディネータ)が選択される。二番目の段階において、選択された調整者は各ノードの役目を決める。三番目の段階において、実質的な連結が行なわれる。ＢＴＣＰでは、全てのノードが互いの無線範囲内に位置するという条件に基づく。
【０００３】
このような条件の下で、そして規定された全てのノードに基づき、Aggarwal等は、ネットワークを個別的なピコネットクラスタにグループ化した。全てのノードに対する情報を有している、いわゆる「スーパマスタ(super-master)」が選択されれば、ピコネットの再構成過程及びピコネット間の連結がこのスーパリーダーの監視により、または調整により行なわれる。
【０００４】
Law等は、Ｏ(log n)倍の複合度及びＯ(ｎ)のメッセージ複合度を有する一段階スキャタネットフォメーションアルゴリズムを開示した。これによれば、全てのノードがただ一つのリーダーを有するよう分離される。その構成要素は、互いに連結されたノード群である。リーダーは、「シーク/スキャン(seek and scan)」段階に入り、選択的に「連結(connection)」、「マージ(merge)」、「ミティゲート(mitigate)」または装置移動などのプロセスを実行する。しかし、Law等が開示したことによると、全てのノードが互いの通信範囲内になければならないという制限が問題である。
【０００５】
ブルーツリーアルゴリズム(Blue-tree algorithm)では、ノードは、自分がルートノード(root node)であるか否かと、自分のワンホップ(one hop)周辺機器を知っていなければならない。
【０００６】
Tan等はそれぞれルート及びループフリー経路(loop free path)を一つずつ具備することにより、パケットのルーティング及びスケジュール調整を単純化した。しかし、このようなツリー型構造では、ジョイントノードが一つのピコネットではマスタであり、別のピコネットではスレーブなので二つのピコネットが互いに密接になる場合がある。
【０００７】
ところが、前述した全てのアルゴリズムが実際のトラフィック状況(traffic condition)とトラフィックリクエスト(traffic request)は考慮しないまま、データリンク層における単独の動作にのみスキャタネットフォーメーションの焦点を合わせている。１対１接続（point-to-point link）が、物理的リンクのレベルでスキャタネット全体で接続されたかを確かめるため、トラフィックがほとんどないようなときにも、「アクティブ」状態は、初期のスキャタネットフォーメーションの間、またはその後に周期的に再開されなければならない。
【０００８】
つまり、不要なリンク維持によって、無線通信機器において大事な存在である電力が浪費されている。このような問題に気づいたRaman等はオンデマンド型(on-demand)ルーティングを備えたスキャタネットリンクフォメーションの層間最適化理論を出してきた。しかし、これまでのところ、さらなる詳細な分析や見解については報告されていない。
【０００９】
【特許文献１】
特表２０００−５０２２２２号公報
【００１０】
BhagwatとSegallは形成されたスキャタネットでパケットのトラフィックをルーティングできるルーティングベクトル方法を提案した。Liu Y．は新たに定義されたLMP命令言語を使用したネットワークフォメーションを使った。しかし、模擬テストで発見された通り、ブルートゥース内の多くのインクワイアリによりトラフィックの待機時間がかなり延びた。
【００１１】
【発明が解決しようとする課題】
本発明は前述した問題点を解決するために案出されたもので、本発明に係る第１目的は、ネットワークフォメーションとルートを独立的に維持しつつピコネットの数も最小化できるブルートゥースグループアドホックネットワークにおける通信方法を提供する。
【００１２】
また、本発明に係る第２目的は、ブルートゥースのアドホックネットワークシステムでソースが希望する場合だけルートが形成されると共に、バッテリパワーを節約するブルートゥースオンデマンドルーティング方法を提供する。
【００１３】
【課題を解決するための手段】
前述した第１目的を達成するための本発明に係るブルートゥースグループアドホックネットワークにおける通信方法は、互いに隣接した複数個の無線通信装置よりなるブルートゥースグループアドホックネットワークにおける通信方法において、一つのピコネットでだけスレーブであるスレーブノード、一つのピコネットでだけマスタであるマスタノード、２個のピコネットにおいて全てスレーブで動作するスレーブ−スレーブジョイントノード、及び一のピコネットにおいてスレーブで動作すると共に他のピコネットにおいてマスタで動作するマスタ−スレーブジョイントノードを含む複数のピコネットで構成され、少なくとも２個以上のピコネットがスレーブ−スレーブジョイントノードにより連結されるようにしてネットワークを形成する段階と、前記ジョイントノードが、Ｌ２ＣＡＰ上位層から通知されるルーティングトリガーを受信すれば、前記ジョイントノードは前記形成されたネットワークに属する前記ピコネットをブリッジングする段階とを備え、前記ネットワークを形成する段階が、Ｌ２ＣＡＰとＢＮＥＰとの間に位置しているネットワークフォメーションプロトコルによって、ＩＰ層に位置しているネットワークルーティングプロトコルの案内の下で、いずれのノードが、前記スレーブノード、前記マスタノード、前記スレーブ−スレーブジョイントノードおよび前記マスタ−スレーブジョイントノードであるかを決める段階を含むことを特徴とする。
【００１４】
また、前記スレーブノードは新たなマスタにより発見されるようインクワイアリスキャンを規則的に行ない、ルーティングトリガー信号を受信すれば、近くのネットワークを探すためにインクワイアリを行なうことが望ましい。
【００１５】
そして、前記スレーブノードは新たなマスタにより発見され新たなリンクが追加されればジョイントノードになることが望ましい。
【００１６】
また、前記マスタノードは通信可能範囲に位置するフリーノードを発見するために規則的にインクワイアリを行ない、前記マスタノードが別のマスタノードと互いに無線範囲にある際、別のマスタノードにより発見されるよう規則的にインクワイアリスキャンを行ない、他のマスタノードによって発見されればスレーブノードに転換されることが望ましい。
【００１７】
また、前記ルーティングトリガーはルーティングプロトコルまたは管理部で発生する信号であって、少なくとも Route REQuest(RREQ) 、 Route REPly(RREP) または Route ERRor(RERR) のうちの一つであることが望ましい。
【００１８】
また、同一のピコネットまたは同一のネットワークに属するノードのデータ構造は、テーブルで記録されており、前記テーブルに基づきルーティングが行なわれることが望ましい。
【００１９】
また、前記テーブルは新たなノードまたは新たなネットワークが発見されたときに更新され、リンクが失われれば該当ノードを前記テーブルから削除することが望ましい。
【００２０】
そして、前記テーブルには、少なくともマスタノードＢＤ−ＡＤＤＲ、スレーブノードＢＤ−ＡＤＤＲ、コネクション寿命、ピコネットまたはネットワーク寿命、及びスレーブ−スレーブジョイントノードのＢＤ−ＡＤＤＲが記録されていることが望ましい。
【００２１】
前述した第２目的を達成するための本発明に係るブルートゥースオンデマンドルーティング方法は、請求項１ないし請求項８のいずれか一項に記載の通信方法で形成されたネットワークを利用したブルートゥースオンデマンドルーティング方法において、前記ネットワークは、前記スレーブノード、マスタノード、スレーブ−スレーブジョイントノード、及びマスタ−スレーブジョイントノードのいずれかであるソースノードと宛先ノード及び互いに独立した複数個のノードを備え、前記ソースノードがルート要求メッセージを送信して前記ソースノードから前記宛先ノードへの全ての中間ノードが前記マスタ−スレーブジョイントノードである多重フォワード経路を設定する段階と、前記ルート要求メッセージを受信した宛先ノードが前記多重設定されたフォワード経路のうちいずれか一つに沿って前記ソースノードにルート応答メッセージを送信して、前記多重設定されたいずれか１つのフォワード経路を構成する隣接した２つのマスタノードの間に前記スレーブ−スレーブジョイントノードを介在させたバックワード経路を設定する段階とを含み、前記設定されたバックワード経路を通して前記ソースノードと宛先ノードとの間に最適の経路であるルートが形成され、前記多重フォワード経路に予め定められたライフタイムが尽きると、前記多重フォワード経路で前記バックワード経路を形成しない経路の連結がパークされることを特徴とする。
【００２２】
望ましくは、前記フォワード経路設定段階は、前記ソースノードが宛先ノードへのルートを必要とし、前記ルートが少なくとも一つ以上利用可能な場合、ルート要求メッセージをブロードキャストする段階と、前記ソースノードで次にホッピングされる少なくとも一つ以上の中間ノードが、前記ルート要求メッセージが前記宛先ノードに到達するまで、前記ブロードキャストされたルート要求メッセージを受信し、さらに次のホッピングノードに前記ルート要求メッセージを伝達する段階とを含む。
【００２３】
ここで、前記ソースノードと前記宛先ノードとの間に連結が設定されれば、ソースノードはマスタとなり、その隣接する中間ノードはスレーブとなり、前記ルート要求メッセージは前記マスタからスレーブに転送されることが望ましい。
【００２４】
また、フォワード経路に沿う全ての中間ノードはマスタスレーブジョイントノードであることが望ましい。
【００２５】
また、前記ルート要求メッセージはその隣接ノードを発見して連結するためにソースノードでインクワイアリ動作を開始するルーティングトリガーであることが望ましい。
【００２６】
一方、前記バックワード経路設定段階は、前記ルート要求メッセージを受信した宛先ノードが前記形成されたフォワード経路のうちいずれか一つに沿って前記ソースノードに向かってルート応答メッセージを転送する段階と、前記宛先ノードで前記ソース方向にホッピングされる中間ノードが、前記ルート応答メッセージが前記ソースノードに到達するまで、前記ルート応答メッセージを受信し、さらに次のホッピングノードに前記ルート応答メッセージを伝達する段階とを含むことができる。
【００２７】
また、前記ルート応答メッセージは、マスタノードの間にスレーブ−スレーブジョイントノードを介在させるために、マスタ／スレーブスイッチングを開始するルーティングトリガーの役目を果たすことが望ましい。
【００２８】
さらに、前記マスタ／スレーブスイッチングは、前記宛先ノードから偶数離隔されたノードとその次のホッピングノードとの間で行なわれることが望ましい。
【００２９】
【発明の実施の形態】
以下、添付した図面に基づき本発明を詳述する。
ＩＥＥＥ８０２．１１ｂでは、同期化はフレーム別になされ事前リンク設定過程がないため、いずれのノードも互いの無線範囲内に位置すれば通信が行なえると記述している。これによれば、ネットワークは常に使用できるということである。マルチ−ホッピングの場合を挙げれば、ネットワーキングはルーティングアルゴリズムのために施される。ネットワーク形成システムのための８０２．１１における下部層(sub-layer)プロトコルスタックはない。
しかし、ブルートゥースノードはパケットを転送する前にまずピコネットを形成すべきである。簡単に説明すれば、ルーティングプロトコルと定義されたプロファイルは、ネットワークが構成された以降は主にソース(source)と宛先(destination)に重点をおいている一方、ネットワーク形成(network formation)は、ルートだけではなく、このソースと宛先との間におけるデータリンク層を基準に「より良質」なルートを提供し維持させるところにも重点をおいている。
【００３０】
二つのノード間には多数個の経路が存在でき、そのうち経路とルートを選択することがルーティングアルゴリズムと定義されたプロファイルの目的である(ここで、「経路」と「ルート」とに用語を分離して使用するのは、「経路」は二つのノード間の全てのネットワーク連結を、「ルート」はパケット転送のためにルーティングプロトコルにより選択された一つの経路を指すためである)。勿論、ルーティングアルゴリズムと定義されたプロファイルもネットワークの構成を助けることができる。この目的で知られているものが「オンデマンド型(on-demand)」ＭＡＮＥＴルーティングアルゴリズムの「ルートディスカバリー(Route Discovery)」である。また、マルチキャスティングとＱｏＳ保証(QoS guarantee)もルーティングプロトコル上でなされる。一方、全てのノードを選択されたルートを通して再構成することにより、ブルートゥース物理層及びデータリンクの次元でより良質のパケット転送を行なうようにすることがネットワーク形成の目的である。ここで、その重点は、「より良質」なネットワークである。従って、いつ、そしていずれのノードがマスタになり、スレーブになるべきか、またはソースと宛先の間のルート上にいずれの種類のジョイントノードがあるかを決定するのが非常に重要になる。
【００３１】
図１は、ブルートゥースグループアドホックネットワークで使用されるプロトコルスタックを示す。
【００３２】
ブルートゥースＳＩＧは、ブルートゥースノードとアプリケーションのネットワーキング能力を提供するため、ＢＮＥＰ(Bluetooth Network Encapsulation Protocol)層を定義している。
【００３３】
ネットワークフォメーション２６は、Ｌ２ＣＡＰ(Logical Link Control & Adaptation Protocol)２８とＢＮＥＰ２５の間に位置している。ネットワークフォメーション２６の主な目的は、ブルートゥースのデータリンク層及び物理層の観点から、早く、より良質のブルートゥースピコネット及びスキャタネットを実現するところにある。ネットワークフォメーション２６は、ルーティングプロトコルと通信可能である。
【００３４】
図１に示すように、ルーティングプロトコルはＩＰ層２４内に位置すると仮定する。これは、ルーティングプロトコルなどの上位層でブルートゥースを実行することを隠している。
【００３５】
一般に、ルーティングプロトコルは既存のネットワークトポロジのうち最善のルートを探し出すためのものである。ルーティングプロトコルの案内の下で、ネットワークフォメーション２６は、いずれのノードがマスタであり、いずれのノードがスレーブであるか、またはいずれの種類のジョイントノードであるかを決める。
【００３６】
与えられたネットワーク直径において最小限のピコネットを使用してネットワークを形成すれば、ピコネット間に干渉が少なくなり、隣接ピコネットとのパケットスケジューリングが少なくなる。その結果、ネットワークの維持が容易になる。
【００３７】
それぞれ動作は違うが、ルーティングプロトコルとネットワークフォメーションは、ブルートゥースグループアドホックネットワーク(Bluetooth Group Ad hoc network)に基づいて密接に関連している。
【００３８】
ここで、「Ｌ３トリガー(L3 trigger)」を、ネットワークフォメーションがルーティングプロトコルやその他の上位層のプロファイルと通信するためのメカニズムと定義する。Ｌ３トリガーの詳細については後述する。
【００３９】
図１の矢印はプロファイル、ルーティングプロトコル、及び管理部をネットワークフォメーションと連結するための信号線を示す。ネットワークフォメーションは、メッセージや命令を上位層のプロトコルまたはプロファイルと交換できる。
【００４０】
ネットワークフォメーション２６は、定義されたプロファイルまたはルーティングプロトコルの制御によって、より良質のネットワーク、ひいてはマルチホッピングネットワーク形成のためのユーティリティを提供する。一般に、小直径であり、パケット間の衝突が少なく、周辺ピコネットとの重複が少なく、ピコネット間スケジュールが多いネットワークであるほど、ピコネットの数も少なくなることは当然である。そして、ネットワークのメンテナンス費用は、できるだけ低価格にするべきである。
【００４１】
図２は、アドホックネットワークにおいてブルートゥースノードのプロトコルスタックを簡略に示す図である。
【００４２】
同図を参照すれば、ブルートゥースグループアドホックネットワーク環境下で、ルーティングプロトコルとネットワークフォメーションがどのように協調しているのかが分かる。ネットワーキングアプリケーション層２１、ルーティングプロトコル３３、及びネットワークフォメーションプロトコル２６の間に信号管(signaling pipe)が存在する。ネットワークアプリケーション層２１が二つのノード間の通信を初期化する。ルーティングプロトコルが宛先へのルートを分かっている場合なら、データパケットは直接に宛先に転送される。ルーティングプロトコルが宛先へのルートを分かっていない場合なら、ルーティングプロトコルは下に位置したネットワークフォメーション層２６に宛先への利用可能な経路を問い合わせる。ネットワークフォメーションプロトコルでソースと宛先の間で利用可能な経路があるならば、すべての利用可能な経路がルーティングプロトコルとして報告される。ルーティングプロトコルとネットワークフォメーションプロトコル間ではそれぞれストラテジと考慮要素が違うので、それぞれ記憶するネットワークトポロジは違ってくる。
【００４３】
ネットワークフォメーションプロトコル２６は、ルーティングプロトコル３３に比べてネットワークトポロジについてさらに情報を持つべきである。ルーティングプロトコル３３は、それらのうち一つのルートを選択する。もし、ネットワークフォメーションプロトコル２６に宛先への利用可能な経路がなければ、ルーティングプロトコル３３は、ＨＣｌ要求を通じて「インクワイアリ/ページ(Inquiry and page)」プロセスを開始し、近接したノードとの連結を設定する。すると、ネットワークトポロジ情報または宛先要求は、２個の近接ノードのネットワークフォメーションプロトコル間で交換される。このプロセスは宛先が発見されるか、別の条件により停止するまで繰り返される。
【００４４】
次に、ブルースターネットワークで使用される用語について定義する。
●フリーノード：別のノードと連結されないノード
●スレーブノード：一つのピコネットでだけスレーブメンバーであるノード
●マスタノード：一つのピコネットでだけマスタメンバーであるノード
●ジョイントノード：少なくとも二つ以上のピコネットでメンバーであるノード。ノードが加入できる最大ピコネットの数はＭである。ノードがＭ＋１番目のピコネットに加入した後、Ｍ個のピコネットのうち一つのリンクはダウンされるべきである。スキャタネットには、２種類のジョイントノード、すなわちＳ−ＳジョイントノードとＭ−Ｓジョイントノードがある。
●Ｓ−Ｓジョイントノード：両ピコネットにおいてスレーブで動作するジョイントノード
●Ｍ−Ｓジョイントノード：一のピコネットにおいてスレーブで動作すると共に他のピコネットにおいてマスタで動作するジョイントノード
●中間ノード：別のノードへ予定されたパケットを転送するのに同意したノード
●フォワード経路：ルートディスカバリー動作を開始したノードから所望の宛先に向かってデータパケットを転送するために設定された経路
●リバース(バックワード)経路：宛先ノードまたは宛先へのルートを有する中間ノードからソースにＲＲＥＰパケットを転送するために設定された経路
●ルーティングトリガー：特定イベントが発生したり、または発生しようとすることを知らせるオンデマンドルーティングプロトコルからの通知。この通知はパラメータ情報を含むことができ、ブルートゥースベースバンドで動作が開始される。ルーティングプロトコルはＩＰ層、管理者部、またはブルートゥースデータリンク層に位置することができる。
●インクワイアリ状態：ノードがインクワイアリトレインに応答すれば、２個のノード間にリンクを形成するようページ進行が行なわれる。
●休止(dormant)状態：コネクション状態及び待機状態、例えばホールドモード、スニフモード、及びパークモードなどのバッテリパワーを節約するためのブルートゥースノードの省電力状態
●ブルースターアイランド：ジョイントノードがＳ−Ｓジョイントノードであるピコネットまたはスキャタネット。ブルースターにおいて「スター」はスター型ネットワークトポロジ(topology)を示す。
●ピコネットにおいてマスタは中央である。Ｓ−Ｓジョイントノードを有するスキャタネットでは２個の中央がある。
【００４５】
図３は、本発明に係るオンデマンドルーティング方法において、フォワード経路とバックワード経路でのノードの機能を示す図である。
【００４６】
図３に示すように、ノードはフリーノード、マスタノード、スレーブノード、及びジョイントノードの４つの機能を果たすことが出来る。全てのノードは初期にフリーノードである。ルートの観点から説明すれば、パケットフォワードルートに沿って、ノードはソースノード、中間ノードまたは宛先ノードと称される。
【００４７】
全てのノードは、いずれの状態にあっても規則的にインクワイアリスキャン状態に入る。これは、ノードの状態にかかわらず発見できるようにするためである。
【００４８】
オンデマンドネットワーク形成は、ソースノードにより要求される時だけ可能である。その前は、全てのノードは独立している。ソースノードがパケットをある宛先ノードへ転送しようとし、宛先ノードへの有効なルートを有していなければ、ルーティングアルゴリズムは宛先を発見するために経路発見プロセスを開始する。
【００４９】
この経路発見プロセスは、宛先ノードへの経路が発見されるか、全ての可能な経路交換が検索されれば終了する。
【００５０】
ソースノードは、ＲＲＥＱメッセージをブロードキャストする。ルーティングプロトコルにおけるＲＲＥＱメッセージは、その隣接ノードを発見して連結するためにソースノードのベースバンドでインクワイアリ動作をトリガーする。
【００５１】
ルーティングプロトコルにおいて、宛先へのルートが必要であり、一つも利用可能なルートがない場合、ＲＲＥＱメッセージはブロードキャストされる。ノードはＲＲＥＱメッセージをその連結されたノードに送信する。
【００５２】
そのノードにとって、ＲＲＥＱメッセージは、ベースバンドでインクワイアリ動作を開始する「ルーティングトリガー」である。しかし、次の四種の場合は除外する。
【００５３】
第１に、Ｎ(Ｎ≦７)個のアクティブスレーブがマスタノードについて予め連結されている場合であり、第２に、ジョイントノードにより連結されているＭ個のピコネットがある場合である。第３に、ＲＲＥＱメッセージのＴＴＬ(time-to-leave)フィールドがルーティングプロトコルで終了する場合である。第４に、複写されたＲＲＥＱメッセージが受信される場合である。
【００５４】
インクワイアリ動作において新たなノードが発見されるイベントにおいて、ノードはマスタになり、新たなノードは新たに形成されたピコネットでスレーブになる。ＲＲＥＱメッセージはＢＮＥＰ連結が形成された後、新たなノードに転送される。もし、新たなノードがＭ＋１番目のピコネットに加わる場合、新たなノードは以前の連結のうちいずれかを切るべきである。
【００５５】
フォワード経路はライフタイム属性を有する。これは、限られた時間内でフォワード経路が確認されるべきであることを意味する。詳しくいうと、ライフタイム属性には、パークライフタイム(park lifetime)とディスコネクトライフタイム(disconnect lifetime)の二つがある。経路ライフタイムはネットワークで連結の属性である一方、ルートライフタイムはルーティングプロトコルでルーティングテーブルの属性である。
【００５６】
フォワード経路に沿って、全ての中間ノードはマスタスレーブジョイントノードである。
【００５７】
次いで、バックワード経路について図３を参照して説明する。
【００５８】
ルーティングプロトコルにおいて、宛先に対するＲＲＥＱメッセージを受信すれば、要求を満たすのに十分なルートを有しており、それ自身が宛先の場合、ノードはＲＲＥＰメッセージを発生する。フォワード経路に沿って、全ての中間ノードはＭ−Ｓジョイントノードである。
【００５９】
ＲＲＥＰメッセージは、進行中のインクワイアリ動作を中止し、バックワード経路に沿ってネットワーク再形成を開始して形成されたピコネットの数を減らすルーティングトリガーである。
【００６０】
一方、ＲＲＥＰパケットは、マスタノードの間にＳ−Ｓジョイントノードを介在させるためにマスタ／スレーブスイッチを開始するルーティングトリガーである。
【００６１】
ネットワーク再形成の原則は、マスタノードの間に可能なＳ−Ｓジョイントノードをインタリーブ(interleave)することである。これは、ピコネットの数を最小化する。
【００６２】
ネットワーク再形成セグメントは開始ノードと終了ノードとの間にある。終了ノードはＲＲＥＰメッセージが発生されるノードである。一方、開始ノードは、マスタで動作する際、空中にＲＲＥＱメッセージが最初に転送された場所である。また、開始ノードは、スレーブで動作する際、空中にＲＲＥＱメッセージが最初に転送された次ホップのノードである。
【００６３】
開始ノードはマスタで動作し、終了ノードはスレーブで動作する。
【００６４】
ネットワーキングアプリケーションプロファイルは、ノードの役目を決めるために高い優先順位を有しうる。マスタ−スレーブスイッチは、偶数離隔されたノードとその次のホップノード間でだけ行なわれる。
【００６５】
他の経路に対するそのルートテーブルは、ＴＴＬが経過しないノードであるか、または存在するネットワークの影響を最小化するためにノードの機能は変化できない。また、固定された機能をピコネットで維持することを希望するノードについては、ノードの機能が変化できない。
【００６６】
図４は、本発明に係るオンデマンドルーティング方法における、多重フォワード経路のうちバックワード経路のルーティングを示す図である。
【００６７】
図４に示したように、転送は、ソースノードＮ０から宛先ノードＮ８へ二つの経路に沿って行われる。しかし、ＲＲＥＰメッセージは、ノードＮ４〜ノードＮ６に沿っては進行しない。これは、ルーティングプロトコルは、それらからルートを一つだけ選択するからである。パークライフタイムが経過すれば、選択されないフォワード経路上のリンクはパークされ、ＡＭ−ＡＤＤＲを返還してバッテリパワーを節約する。ディスコネクトライフタイムが経過すれば、フォワード経路上のリンクは切れ、バッテリパワーをさらに節約するようになる。
【００６８】
次は、ルートエラー及びルートの終了について説明する。
【００６９】
ルーティングプロトコルにおいては、リンクが切れるか、ルートが終了すればＲＥＲＲ(Route ERRor)メッセージが発生されブロードキャストされる。ＲＥＲＲメッセージは、残った連結されたリンクについてパーク動作を開始する「ルーティングトリガー」である。ルーティングプロトコルにおいては、宛先へのルートが終了すれば、経路に沿った連結はパークされ、バッテリパワーを節約する。スレーブノードは、リンクを感知するために周期的に起きている必要がある。宛先へのルートがルートテーブルから削除されれば、経路に沿った連結が切れる。
【００７０】
ブルースターアイランドネットワークフォメーションは、２段階プロトコルである。ブルースターアイランドネットワークフォメーションの第１段階は、フリーノードで自動的に形成される。ブルースターアイランドは、ジョイントノードが両ピコネットでスレーブになるピコネットになることができ、またはスキャタネットとなることができる。電源が供給されたとき、ノードのデフォルトの機能は、フリーノードである。その後、ノードはインクワイアリ状態、インクワイアリスキャン状態、及び休止状態などにその状態を転換する。ノードはそれぞれ独立的であり、互いについて無知の状態である。各ノードはスレーブ資格で接続してスレーブノードになれ、マスタ資格で接続してマスタノードになれる。スレーブノードは、定期的にインクワイアリスキャン状態に入って別のピコネットに発見されることにより、ブルースターアイランドが形成されうる。マスタノードは、他のマスタに発見されるように、インクワイアリ状態に入る。このようにして、二つのマスタノードが互いの無線範囲内に進入することが防止される。全てのブルートゥースノードは自律構成されるので、個別的なマルチブルースターアイランドの形成も可能である。
【００７１】
図５は、二つの隣接したブルースターアイランドが互いに連結できない場合の例を示す図である。
【００７２】
ブルースターアイランドネットワークフォメーションの第２段階は、「Ｌ３トリガー」の開始によりブルースターアイランドをブリッジングすることである。ここで、「Ｌ３トリガー」はルーティングプロトコル、プロファイルあるいは管理部などから転送された短い通知である。例えば、「Ｌ３トリガー」はルーティングアルゴリズムの"Route REQuest"や、"HELLO"のようなメッセージである。また、プロファイルから転送された命令、例えば「サービスディスカバリー」命令も「Ｌ３トリガー」の一例と言える。「Ｌ３トリガー」があった後、全てのエッジノード、スレーブノードなどがインクワイアリ状態を行って無線範囲内に別のスレーブノードがあるかをチェックする。新たなブルースターアイランドが発見されれば、新たなピコネットが形成される。この場合、ジョイントノードは、Ｍ−Ｓジョイントノードを指す。
【００７３】
図６は、ブルースターネットワークフォメーションにおいてノードの役割の転換を示す図であり、図７はそれぞれのノードの状態を示す図である。
【００７４】
図６において、フリーノード５３は、ネットワークが形成される前に存在するノードであって、別のノードと連結を有しないノードと定義される。
【００７５】
フリーノード５３は、パワーオンされた後のデフォルトノードである。フリーノード５３は、別のノードと連結を有せず、連結状態にならない。フリーノード５３は、インクワイアリ状態、インクワイアリスキャン状態、及び休止状態に入る(段階Ｓ５０２)。パワーオンした後、または休止状態から覚めた後、フリーノードは[０，１]間で乱数(Rnode)を発生する。
【００７６】
Rnode<R０ならば、ノードはインクワイアリ状態に入る。
【００７７】
Rnode>R０ならば、ノードはインクワイアリスキャン状態に入る。
【００７８】
インクワイアリとインクワイアリスキャン後にいずれの連結設定もなければ、ノードは休止状態に入る。
【００７９】
トラフィックが発生すれば、フリーノード５３は、インクワイアリ動作を開始する。Ｒ０は、固定された臨界値である（Ｒ０の値はシミュレーションを通してＴＢＤである)。フリーノード５３は、インクワイアリ状態になる確率よりインクワイアリスキャン状態になる確率のほうが高くなくてはならない。フリーノード５３は、トラフィックパケットソースまたはパケット宛先でありうる。式のノードの役割の設定時までフリーノード５３はその役割を維持する。
【００８０】
役割が設定される時、フリーノード５３は、形成されたリンクの状態に応じてマスタノードまたはスレーブノードになれる(段階Ｓ５０４及び段階Ｓ５０５)。そして、スレーブノードまたはマスタノードのリンクが切れれば、スレーブノードまたはマスタノードは、フリーノードに転換される(段階Ｓ５０９、Ｓ５１０)。
【００８１】
スレーブノードは、一つのピコネットでだけスレーブメンバーノードと定義される。
【００８２】
スレーブノード５４は、トラフィックパケットソースまたはパケット宛先になれる。スレーブノード５４は、さらに大きいブルースターアイランドを形成するため新たなマスタにより発見されるようインクワイアリスキャン状態に規則的に入り、トラフィックがなければバッテリパワーを節約するために休止状態に入る(段階Ｓ５０６)。
【００８３】
上位層から「Ｌ３トリガー」を受信すれば、スレーブノード５４は近接したブルースターアイランドを発見するためにインクワイアリ状態に入る(段階Ｓ５０８)。スレーブノード５４のインクワイアリスケジュールは、注意深く配列されるべきである。全てのスレーブノード５４がインクワイアリを同時に行うと、深刻なＩＰパケット衝突が発生するおそれがある。これは、インクワイアリ動作の性能を低下させる。たとえば、連結設定を長くし、帯域幅の浪費を引き起こす。
【００８４】
別のピコネットとのリンクがダウンされるか、新たなリンクが追加されるまで、スレーブノード５４は、その機能を維持する。リンクがダウンされれば、スレーブノード５４はフリーノード５３になるよう転換され、リンクを失う(段階Ｓ５１０)。新たなリンクが追加されれば、スレーブノードはジョイントノードになるよう転換される。
【００８５】
一方、マスタノード５１はパケットソース、パケット宛先及びトラフィックパケットリレーノードになれる。マスタノード５１は、インクワイアリ状態とインクワイアリスキャン状態に規則的に入る(段階Ｓ５１２)。
【００８６】
マスタノード５１は、Ｎ個のアクティブスレーブ(Ｎ<=７)が発見されるまで、その範囲でフリーノードを発見するようインクワイアリ状態に規則的に入る。また、マスタノード５１は、インクワイアリスキャン状態に規則的に入る。これは、互いに無線領域に存する場合、別のマスタにより発見されることを可能にするためである。
【００８７】
第１マスタノードが第２マスタノードにより発見されれば、第１マスタノードは第２マスタノードのピコネットにおいてジョイントノード（Ｍ−Ｓジョイントノード）になる。すると、第１マスタノードは一つのスレーブノードとマスタ−スレーブスイッチングを行い、Ｓ−Ｓジョイントノードになる。
【００８８】
一方、第１マスタノードに属する別のスレーブノードは、新たなピコネットに加わろうとしてジョイントノードになる(段階Ｓ５１４)。スレーブノードは新たなピコネットに加わり、フリーノードになれない。
【００８９】
マスタノードはそれぞれの連結の寿命を記録し、連結を通して転送される全てのパケットについて寿命を更新する。連結寿命が経過した後、連結ノード（スレーブ）は、スレーブ資源になるため休止状態に入るよう命令される。
【００９０】
全てのリンクが切れるか、別のマスタにより発見されるまで、マスタノードはその役割を維持する。全てのリンクが切れるイベントにおいて、マスタノードはフリーノードに転換され、別のマスタにより発見されるイベントで、発見されたマスタノードはスレーブとの全てのリンクを切り、新たなピコネットでスレーブノードに転換される。
【００９１】
ジョイントノード５２は、パケットソース、パケット宛先、及びブルースターアイランドの間でトラフィックパケットリレーノードになれる。ジョイントノードは、近接したブルースターアイランドにより規則的に発見されるようインクワイアリスキャン状態に入れる。上位層において「Ｌ３トリガー」を受信すれば、ジョイントノードはインクワイアリ状態に入って、近接したブルースターアイランドを発見する。
【００９２】
Ｍ＋１番目のピコネットにジョインした後、ジョイントノードは結合寿命とピコネット寿命に基づき、現在のアクティブ連結を切るべきである。いずれにしても、ジョイントノードは、確実にルートボトルノード(bottle node)にならなければならない。Ｍ値はＴＢＤである。バッテリパワーを節減するため、トラフィックがなければジョイントノードは休止状態になる(段階Ｓ５１６)。
【００９３】
ジョイントノード５２は、一つのリンクが切れるまでその役割を維持する。Ｓ−Ｓジョイントノードリンクが切れれば、ジョイントノードはスレーブノードになる(段階Ｓ５１８)。Ｍ−Ｓジョイントノードリンクが切れれば、ジョイントノードは、いずれのノードが切れているのかによってマスタノードまたはスレーブノードになる。
【００９４】
次に、Ｌ３トリガーについて詳述する。
【００９５】
「Ｌ２トリガー」がＬ２層のためだけにＩＥＴＦドラフトで使用されたため、上位層を報告するために「Ｌ３トリガー」と命名された。ＩＥＴＦにおいて、Ｌ２トリガーは、Ｌ２から特定イベントが発生したかあるいは発生しようとするのかの通知の約束である(潜在的にパラメータ情報を含んで)。トリガーは多様な方法で実行できる。ここで、Ｌ３トリガーは、Ｌ２ＣＡＰ上位層から通知を示すよう使用する。
【００９６】
ルーティングプロトコルから、Ｌ３トリガーは、オンデマンドプロトコルでRREQタイプのメッセージであるか、テーブルドリブン及びオンデマンドプロトコルで"HELLO"タイプのメッセージでありうる。ＲＲＥＱメッセージはＩＰアドレスでラベルされたノードを発見するために使用される一方、HELLOメッセージは近接したノードが未だ利用可能なのかを感知するために使われる。別のノードからＲＲＥＱメッセージを受信すれば、スレーブノードは、ソースノードと宛先ノードとの中間に位置して、その到達可能な範囲に宛先があるかをチェックする。これは、ルーティングプロトコルにより行われる。
【００９７】
もし、到達可能な範囲に宛先があれば、ルーティングプロトコルでRREP(Route REPly)メッセージがルーティングアルゴリズムにより発生する。ノードはソースへのバックワード経路に沿ってＲＲＥＰメッセージを送信する。
【００９８】
もし、到達可能な範囲に宛先がなければ、ノードはＬ３トリガー信号を発生して全ての到達可能なスレーブノードに知らせて、アルゴリズムに基づき近接したブルースターアイランドを求めるようインクワイアリを行う。
【００９９】
インクワイアリに応答ノードがなければ、ノードはインクワイアリを中断する。
【０１００】
インクワイアリに応答するノードがあれば、それらの間にＢＮＥＰ連結が発生した後、RREQメッセージはノードに送信される。
【０１０１】
このプロセスは、宛先が発見されるか、最大ホップ(hop)数ｉｄに到達するまで繰り返される。
【０１０２】
このように、RREQメッセージは中間のブルースターアイランドにリレーされる。これとは逆に、HELLOメッセージは近接ノードを感知するためにだけ使用される。いずれの宛先ノードも定義されない。従って、HELLOメッセージは、リレーなしで、かつソースブルースターアイランドでだけ、トリガーを開始することができる。
【０１０３】
Ｌ３トリガーは管理部、限定的なプロファイル、またはサービスディスカバリーから来る場合がある。この場合、ネットワークフォメーションからルーティングプロトコルへの上向インタフェースだけがある。サービスディスカバリーと管理タイプのメッセージはＬ３トリガーでありうる。
【０１０４】
ネットワークトポロジを記録するため、全てのノードは、同一なピコネット及び同一なブルースターアイランドで到達可能なノードリストを維持すべきである。全てのノードはＭ−Ｓジョイントノードを介して通信することができる。ノードの可能なデータ構造は、表１のリストの通りである。新たなノードまたはブルースターアイランドが発見されると、ノードはその記録を加え、全ての到達可能なノードに情報を知らせる。リンクが失われれば、ノードは一つまたは１グループのノードをその記録から削除する。表１は、ルーティングプロトコルからベースバンドへの経路をマッピングしたものである。同一なものがルーティングプロトコルで発生する。コネクション寿命属性は、連結のアクティブ時間を記録するために使われる。リンクにおける全てのパケットは、寿命属性を新しくされる。ブルースターアイランド寿命は、二つのマスタが互いに無線範囲にある時、いずれがスレーブになるのか決めるために使用される。
【０１０５】
【表１】
テーブル駆動されたルーティングプロトコルは、ネットワーク情報と組み合わせるよう駆動される。ノード記録及びルーティングテーブルは殆んど同一である。オンデマンドルーティングプロトコルの場合、ルーティングテーブル及びノード記録は違う。
【０１０７】
【発明の効果】
以上述べた通り、本発明に係るブルートゥースオンデマンドルーティング方法によれば、バッテリパワーを節約することができ、進行中のトラフィックについて大きい帯域幅を提供することができる。また、バックワード経路に沿うマスタ／スレーブスイッチングにより、より良質のスキャタネット構成が実行できる。
【０１０８】
ネットワークフォメーションとルーティングを互いに重畳させず独立して維持することができ、テーブル駆動及びオンデマンドプロトコルのように全種類のルーティングプロトコルを受け入れられる。また、ジョイントノードがピコネットをブリッジングするので、ピコネットの数を最小化できる。そして、スレーブノードはただインクワイアリスキャンだけ行うため、管理を最小化し、バッテリパワー消費を最小化する。
【０１０９】
以上では本発明の望ましい実施例について説明したが、本発明は、前述した特定の実施例に限らず、請求の範囲で請求する本発明の要旨を逸脱しない限りにおいて、当該発明の属する技術分野において通常の知識を持つ者ならば誰でも多様な変形実施が可能なことは勿論、そのような変更は請求の範囲の記載の範囲内にある。
【図面の簡単な説明】
【図１】ブルートゥースグループアドホックネットワークで使用されるプロトコルスタックを示す図である。
【図２】アドホックネットワークでブルートゥースノードのプロトコルスタックを概略的に示す図である。
【図３】 本発明に係るブルートゥースオンデマンドルーティング方法において、フォワード経路及びバックワード経路時のノードの役割を説明するための図である。
【図４】 本発明に係るブルートゥースオンデマンドルーティング方法において、多重フォワード経路中バックワード経路のルートを説明するための図である。
【図５】二つの隣接したブルースターアイランドが互いに連結されていない場合の例を示す図である。
【図６】ブルースターネットワークフォメーションでノードの役割と役割の転換を示す信号流れ図である。
【図７】それぞれのノードの状態を示す図である。
Claims (18)
- 互いに隣接した複数個の無線通信装置よりなるブルートゥースグループアドホックネットワークにおける通信方法において、
一つのピコネットでだけスレーブであるスレーブノード、一つのピコネットでだけマスタであるマスタノード、二つのピコネットにおいて全てスレーブで動作するスレーブ−スレーブジョイントノード、及び一のピコネットにおいてスレーブで動作すると共に他のピコネットにおいてマスタで動作するマスタ−スレーブジョイントノードを含む複数のピコネットで構成され、少なくとも２個以上のピコネットがスレーブ−スレーブジョイントノードにより連結されるようにしてネットワークを形成する段階と、
前記ジョイントノードが、Ｌ２ＣＡＰ上位層から通知されるルーティングトリガーを受信すれば、前記ジョイントノードは前記形成されたネットワークに属する前記ピコネットをブリッジングする段階とを備え、
前記ネットワークを形成する段階は、Ｌ２ＣＡＰとＢＮＥＰとの間に位置しているネットワークフォメーションプロトコルによって、ＩＰ層に位置しているネットワークルーティングプロトコルの案内の下で、いずれのノードが、前記スレーブノード、前記マスタノード、前記スレーブ−スレーブジョイントノードおよび前記マスタ−スレーブジョイントノードであるかを決める段階を含むことを特徴とするブルートゥースグループアドホックネットワークにおける通信方法。 - 前記スレーブノードは新たなマスタにより発見されるようインクワイアリスキャンを規則的に行ない、
ルーティングトリガー信号を受信すれば、近くのネットワークを探すためにインクワイアリを行なうことを特徴とする請求項１に記載のブルートゥースグループアドホックネットワークにおける通信方法。 - 前記スレーブノードは新たなマスタにより発見され新たなリンクが追加されればジョイントノードになることを特徴とする請求項１に記載のブルートゥースグループアドホックネットワークにおける通信方法。
- 前記マスタノードは通信可能範囲に位置するフリーノードを発見するために規則的にインクワイアリを行ない、
前記マスタノードが別のマスタノードと互いに無線範囲にある際、別のマスタノードにより発見されるよう規則的にインクワイアリスキャンを行ない、
他のマスタノードによって発見されればスレーブノードに転換されることを特徴とする請求項１に記載のブルートゥースグループアドホックネットワークにおける通信方法。 - 前記ルーティングトリガーはルーティングプロトコルまたは管理部から発生される信号であって、少なくともRoute REQuest(RREQ)、RouteREPly(RREP)またはRoute ERRor(RERR)のうちいずれか一つであることを特徴とする請求項１に記載のブルートゥースグループアドホックネットワークにおける通信方法。
- 同一のピコネットまたは同一のネットワークに属するノードのデータ構造は、テーブルで記録されており、前記テーブルに基づきルーティングが行なわれることを特徴とする請求項１に記載のブルートゥースグループアドホックネットワークにおける通信方法。
- 前記テーブルは新たなノードまたは新たなネットワークが発見されたときに更新され、リンクが失われれば該当ノードを前記テーブルから削除することを特徴とする請求項６に記載のブルートゥースグループアドホックネットワークにおける通信方法。
- 前記テーブルには少なくともマスタノードＢＤ−ＡＤＤＲ、スレーブノードＢＤ−ＡＤＤＲ、コネクション寿命、ピコネットまたはネットワーク寿命、及びスレーブ−スレーブジョイントノードのＢＤ−ＡＤＤＲが記録されていることを特徴とする請求項６に記載のブルートゥースグループアドホックネットワークにおける通信方法。
- 請求項１ないし請求項８のいずれか一項に記載の通信方法で形成されたネットワークを利用したブルートゥースオンデマンドルーティング方法において、
前記ネットワークは、前記スレーブノード、マスタノード、スレーブ−スレーブジョイントノード、及びマスタ−スレーブジョイントノードのいずれかであるソースノードと宛先ノード及び互いに独立した複数個のノードを備え、
前記ソースノードがルート要求メッセージを送信して前記ソースノードから前記宛先ノードへの全ての中間ノードが前記マスタ−スレーブジョイントノードである多重フォワード経路を設定する段階と、
前記ルート要求メッセージを受信した宛先ノードが前記多重設定されたフォワード経路のうちいずれか一つに沿って前記ソースノードにルート応答メッセージを送信して、前記多重設定されたいずれか１つのフォワード経路を構成する隣接した２つのマスタノードの間に前記スレーブ−スレーブジョイントノードを介在させたバックワード経路を設定する段階とを含み、
前記設定されたバックワード経路を通して前記ソースノードと宛先ノードとの間に最適の経路であるルートが形成され、前記多重フォワード経路に予め定められたライフタイムが尽きると、前記多重フォワード経路で前記バックワード経路を形成しない経路の連結がパークされることを特徴とするブルートゥースオンデマンドルーティング方法。 - 前記フォワード経路設定段階は、
前記ソースノードが宛先ノードへのルートを必要とし、前記ルートが少なくとも一つ以上利用可能な場合、ルート要求メッセージをブロードキャストする段階と、
前記ソースノードから次にホッピングされる少なくとも一つ以上の中間ノードが、前記ルート要求メッセージが前記宛先ノードに到達するまで、前記ブロードキャストされたルート要求メッセージを受信し、さらに次のホッピングノードに前記ルート要求メッセージを伝達する段階と、を含むことを特徴とする請求項９に記載のブルートゥースオンデマンドルーティング方法。 - 前記ソースノードと前記宛先ノードとの間に連結が設定されればソースノードはマスタとなり、その隣接する中間ノードはスレーブとなり、前記ルート要求メッセージは前記マスタからスレーブに転送されることを特徴とする請求項９に記載のブルートゥースオンデマンドルーティング方法。
- フォワード経路に沿う全ての中間ノードはマスタスレーブジョイントノードであることを特徴とする請求項９に記載のブルートゥースオンデマンドルーティング方法。
- 前記ルート要求メッセージは、隣接ノードを発見して連結するためにソースノードでインクワイアリ動作を開始するルーティングトリガーであることを特徴とする請求項９に記載のブルートゥースオンデマンドルーティング方法。
- 前記ルーティングトリガーは、ブルートゥースのプロトコルでルーティング階層または管理部から提供されることを特徴とする請求項１３に記載のブルートゥースオンデマンドルーティング方法。
- 前記バックワード経路設定段階は、
前記ルート要求メッセージを受信した宛先ノードが前記形成されたフォワード経路のうちいずれか一つに沿って前記ソースノードに向かってルート応答メッセージを転送する段階と、
前記宛先ノードで前記ソース方向にホッピングされる中間ノードが、前記ルート応答メッセージが前記ソースノードに到達するまで、前記ルート応答メッセージを受信し、さらに次のホッピングノードに前記ルート応答メッセージを伝達する段階と、を備えることを特徴とする請求項９に記載のブルートゥースオンデマンドルーティング方法。 - 前記ルート応答メッセージは、マスタノードの間にスレーブ−スレーブジョイントノードを介在させるためにマスタ／スレーブスイッチングを開始するルーティングトリガーであることを特徴とする請求項１５に記載のブルートゥースオンデマンドルーティング方法。
- 前記マスタ／スレーブスイッチングは、前記宛先ノードから偶数離隔されたノードとその次のホッピングノードの間で行なわれることを特徴とする請求項１６に記載のブルートゥースオンデマンドルーティング方法。
- ブルートゥースのプロトコルにおいてルーティング機能を行なうルーティングは、ネットワーク形成と独立して、ＢＮＥＰ階層またはＩＰ階層のうちいずれか一つに形成されることを特徴とする請求項１５に記載のブルートゥースオンデマンドルーティング方法。
Applications Claiming Priority (6)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| KR20020022824 | 2002-04-25 | ||
| KR2002-022824 | 2002-04-25 | ||
| KR10-2002-0034673A KR100485774B1 (ko) | 2002-04-25 | 2002-06-20 | 블루투스 온-디맨드 라우팅 및 네트워크 형성방법 |
| KR2002-034673 | 2002-06-20 | ||
| KR10-2002-0072841A KR100512984B1 (ko) | 2002-04-25 | 2002-11-21 | 블루투스 그룹 애드 호크 네트워크에서의 통신방법 |
| KR2002-072841 | 2002-11-21 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003324447A JP2003324447A (ja) | 2003-11-14 |
| JP3840197B2 true JP3840197B2 (ja) | 2006-11-01 |
Family
ID=28794804
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003121433A Expired - Fee Related JP3840197B2 (ja) | 2002-04-25 | 2003-04-25 | ブルートゥースオンデマンドルーティング方法及びブルートゥースグループアドホックネットワークにおける通信方法 |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US8351339B2 (ja) |
| EP (1) | EP1357712A1 (ja) |
| JP (1) | JP3840197B2 (ja) |
| CN (1) | CN100428711C (ja) |
Families Citing this family (68)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8144671B2 (en) | 2005-07-01 | 2012-03-27 | Twitchell Jr Robert W | Communicating via nondeterministic and deterministic network routing |
| EP1586176B1 (en) * | 2003-01-10 | 2007-02-21 | Philips Intellectual Property & Standards GmbH | Dynamic network formation for wireless adhoc networks |
| US7298761B2 (en) * | 2003-05-09 | 2007-11-20 | Institute For Information Industry | Link path searching and maintaining method for a bluetooth scatternet |
| US7466665B2 (en) * | 2003-06-25 | 2008-12-16 | Motorola, Inc. | Method and apparatus for route discovery within a communication system |
| US7706282B2 (en) * | 2003-06-25 | 2010-04-27 | Leping Huang | Bluetooth personal area network routing protocol optimization using connectivity metric |
| US7394826B2 (en) * | 2003-09-09 | 2008-07-01 | Harris Corporation | Mobile ad hoc network (MANET) providing quality-of-service (QoS) based unicast and multicast features |
| US7068605B2 (en) * | 2003-09-09 | 2006-06-27 | Harris Corporation | Mobile ad hoc network (MANET) providing interference reduction features and related methods |
| EP1524619A2 (en) * | 2003-10-14 | 2005-04-20 | Rf Monolithics, Inc. | System and method for wireless data communication |
| US7463612B2 (en) * | 2003-10-30 | 2008-12-09 | Motorola, Inc. | Method and apparatus for route discovery within a communication system |
| DE10354877B4 (de) * | 2003-11-24 | 2005-12-01 | Siemens Ag | Verfahren zur Herstellung einer Verbindung zwischen einem Dienstanforderer (Client) und einem Dienstanbieter (Server) in einem dezentralen Mobilfunknetz |
| TWI234970B (en) * | 2003-12-05 | 2005-06-21 | Inst Information Industry | Method and system for route selection and method for route reconstruction |
| CN100346618C (zh) * | 2003-12-10 | 2007-10-31 | 联想(北京)有限公司 | 无线网格的最佳路由选择方法 |
| AU2003290491A1 (en) * | 2003-12-23 | 2005-07-14 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and system for routing traffic in ad hoc networks |
| WO2005088913A1 (en) * | 2004-03-08 | 2005-09-22 | Philips Intellectual Property & Standards Gmbh | Dynamic network fusion in wireless ad-hoc networks |
| JP2005269059A (ja) * | 2004-03-17 | 2005-09-29 | Fujitsu Ltd | データ中継装置、データ中継方法およびデータ中継プログラム |
| US7937088B2 (en) * | 2004-03-26 | 2011-05-03 | Qualcomm Incorporated | Routing communications in an ad hoc network |
| JP4586521B2 (ja) * | 2004-04-02 | 2010-11-24 | ソニー株式会社 | ネットワークシステムおよび通信機器 |
| US7142107B2 (en) | 2004-05-27 | 2006-11-28 | Lawrence Kates | Wireless sensor unit |
| DE102004040070B3 (de) * | 2004-08-18 | 2006-03-02 | Siemens Ag | Aufbau eines drahtungebundenen Netzes unter Ermittlung und Nutzung lokaler Topologie-Information |
| KR100555711B1 (ko) * | 2004-08-31 | 2006-03-03 | 삼성전자주식회사 | 애드 혹 네트워크에서 플러딩 방법 |
| US7398408B2 (en) | 2004-11-24 | 2008-07-08 | Conexant Systems, Inc. | Systems and methods for waking up wireless LAN devices |
| US7848768B2 (en) | 2004-12-08 | 2010-12-07 | Sony Corporation | Network system and communication device |
| US20070104123A1 (en) * | 2005-11-08 | 2007-05-10 | Interdigital Technology Corporation | Method to provide centrally coordinated contention-free channel access within a wireless mesh network |
| US20090129306A1 (en) * | 2007-02-21 | 2009-05-21 | Terahop Networks, Inc. | Wake-up broadcast including network information in common designation ad hoc wireless networking |
| JP4911402B2 (ja) * | 2006-03-20 | 2012-04-04 | 沖電気工業株式会社 | 移動無線通信システム及びその通信制御方法、移動端末、並びにプログラム |
| ES2302438B1 (es) * | 2006-07-10 | 2009-05-21 | Universitat Politecnica De Catalunya | Sistema y procedimiento para enrutar un paquete de datos en una red inalambrica, sistema de computacion en un sistema para enrutar un paquete de datos en una red inalambrica, y procedimiento para enrutar un paquete de datos en un sistema de computacion. |
| US20080101325A1 (en) * | 2006-10-31 | 2008-05-01 | Qi Bao | Wireless relay device deployment methods and apparatus |
| US20080240116A1 (en) * | 2007-03-26 | 2008-10-02 | Motorola, Inc. | Method and Apparatus for Determining the Locating of Nodes in a Wireless Network |
| WO2009140669A2 (en) | 2008-05-16 | 2009-11-19 | Terahop Networks, Inc. | Securing, monitoring and tracking shipping containers |
| JP5564774B2 (ja) * | 2008-09-24 | 2014-08-06 | ソニー株式会社 | 情報処理装置および方法、並びに、プログラム |
| EP2351440A4 (en) * | 2008-10-24 | 2014-11-26 | Samsung Electronics Co Ltd | METHOD AND SYSTEM FOR SYNCHRONIZING PROPERTIES UNDER MULTIPLE ELECTRONIC DEVICES |
| US8391435B2 (en) | 2008-12-25 | 2013-03-05 | Google Inc. | Receiver state estimation in a duty cycled radio |
| KR101598886B1 (ko) * | 2009-10-13 | 2016-03-03 | 삼성전자주식회사 | 이동통신 단말기에서 무선랜을 이용한 피어투피어 연결 방법 및 장치 |
| CN102148717B (zh) * | 2010-02-04 | 2013-08-21 | 明仲 | 一种二分网络中社团检测方法及装置 |
| US9106580B2 (en) | 2010-07-08 | 2015-08-11 | Nec Europe Ltd. | Method of supporting power control in a communication network |
| US8774833B2 (en) * | 2010-11-30 | 2014-07-08 | GM Global Technology Operations LLC | Navigation system destination entry |
| CN102811076B (zh) * | 2011-06-03 | 2016-06-29 | 希姆通信息技术（上海）有限公司 | 蓝牙连接方法 |
| US9226219B2 (en) * | 2011-12-21 | 2015-12-29 | Silver Spring Networks | System and method for route learning and auto-configuration |
| EP2936786B1 (fr) * | 2012-12-21 | 2021-02-24 | Airbus Ds Sas | Procede de fusion de deux sous-reseaux en un unique reseau ad hoc implementant le protocole d2hcp |
| US9668297B2 (en) * | 2013-05-29 | 2017-05-30 | Texas Instruments Incorporated | BLE scatternet system and method |
| CN104426776B (zh) * | 2013-08-26 | 2018-09-07 | 西北工业技术研究院 | 一种空地大规模自组网路由方法 |
| US9756549B2 (en) | 2014-03-14 | 2017-09-05 | goTenna Inc. | System and method for digital communication between computing devices |
| CN104661251B (zh) * | 2015-02-10 | 2018-05-01 | 深圳市盛路物联通讯技术有限公司 | 基于移动终端的无线自组网方法及装置 |
| CN104902503A (zh) * | 2015-04-27 | 2015-09-09 | 深圳市民展科技开发有限公司 | 一种基于蓝牙技术的多设备自动避让方法及系统 |
| CN104853307A (zh) * | 2015-04-27 | 2015-08-19 | 深圳市民展科技开发有限公司 | 一种基于蓝牙技术的自组网方法及系统 |
| US9923965B2 (en) | 2015-06-05 | 2018-03-20 | International Business Machines Corporation | Storage mirroring over wide area network circuits with dynamic on-demand capacity |
| GB201516673D0 (en) * | 2015-09-21 | 2015-11-04 | Nicoventures Holdings Ltd | Topology |
| GB201516674D0 (en) | 2015-09-21 | 2015-11-04 | Nicoventures Holdings Ltd | Topology |
| US9923784B2 (en) | 2015-11-25 | 2018-03-20 | International Business Machines Corporation | Data transfer using flexible dynamic elastic network service provider relationships |
| US9923839B2 (en) | 2015-11-25 | 2018-03-20 | International Business Machines Corporation | Configuring resources to exploit elastic network capability |
| US10057327B2 (en) | 2015-11-25 | 2018-08-21 | International Business Machines Corporation | Controlled transfer of data over an elastic network |
| US10177993B2 (en) | 2015-11-25 | 2019-01-08 | International Business Machines Corporation | Event-based data transfer scheduling using elastic network optimization criteria |
| US10216441B2 (en) | 2015-11-25 | 2019-02-26 | International Business Machines Corporation | Dynamic quality of service for storage I/O port allocation |
| US10581680B2 (en) | 2015-11-25 | 2020-03-03 | International Business Machines Corporation | Dynamic configuration of network features |
| US9887919B2 (en) | 2016-04-01 | 2018-02-06 | Intel Corporation | Techniques and systems for logical mesh networks |
| CN105827282A (zh) * | 2016-05-24 | 2016-08-03 | 卧槽科技（深圳）有限公司 | 一种蓝牙设备组网方法、装置及蓝牙设备 |
| CN106658368A (zh) * | 2016-12-01 | 2017-05-10 | 九阳股份有限公司 | 一种蓝牙组网方法和系统 |
| GB201707050D0 (en) | 2017-05-03 | 2017-06-14 | British American Tobacco Investments Ltd | Data communication |
| CN107949107A (zh) * | 2017-11-26 | 2018-04-20 | 四川蓝景光电技术有限责任公司 | 基于蓝牙mesh技术的led智能照明控制系统及其实现方法 |
| GB201722278D0 (en) | 2017-12-29 | 2018-02-14 | British American Tobacco Investments Ltd | Device identification and method |
| GB201722241D0 (en) | 2017-12-29 | 2018-02-14 | British American Tobacco Investments Ltd | Data capture across devices |
| CN112075102B (zh) * | 2018-06-13 | 2024-04-09 | 卧安科技(深圳)有限公司 | 低功耗蓝牙组网方法、电子设备、网络和存储介质 |
| CA3107919A1 (en) | 2018-07-27 | 2020-01-30 | GoTenna, Inc. | Vinetm: zero-control routing using data packet inspection for wireless mesh networks |
| CN109246671B (zh) | 2018-09-30 | 2020-12-08 | Oppo广东移动通信有限公司 | 数据传输方法、装置及系统 |
| WO2020081207A1 (en) | 2018-10-19 | 2020-04-23 | Carrier Corporation | Energy-balanced and latency-constrained routing methods in wireless network |
| US11729696B2 (en) | 2018-11-20 | 2023-08-15 | Carrier Corporation | Robust multipath routing methods in wireless network |
| CN113207113B (zh) * | 2021-04-20 | 2023-01-13 | 上海富芮坤微电子有限公司 | 多连接组网系统、方法、存储介质及电子设备 |
| CN115529577A (zh) * | 2022-07-08 | 2022-12-27 | 青岛海尔智能家电科技有限公司 | 用于蓝牙网络中数据传输的方法、装置、设备及存储介质 |
Family Cites Families (23)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GB2332809A (en) * | 1997-12-24 | 1999-06-30 | Northern Telecom Ltd | Least cost routing |
| US6321271B1 (en) * | 1998-12-22 | 2001-11-20 | Lucent Technologies Inc. | Constrained shortest path routing method |
| US6691173B2 (en) * | 1999-07-06 | 2004-02-10 | Widcomm, Inc. | Distributed management of an extended network containing short-range wireless links |
| US6788702B1 (en) * | 1999-10-15 | 2004-09-07 | Nokia Wireless Routers, Inc. | Protocol for neighborhood-established transmission scheduling |
| US6683886B1 (en) * | 1999-10-19 | 2004-01-27 | Koninklijke Philips Electronics N.V. | Bluetooth communication units, wireless communication systems, wireless communication devices, bluetooth communications methods, and wireless communication methods |
| CN1408159A (zh) | 1999-12-06 | 2003-04-02 | 艾利森电话股份有限公司 | 作为对于路由发现的触发机制的广播 |
| EP1107522B1 (en) * | 1999-12-06 | 2010-06-16 | Telefonaktiebolaget LM Ericsson (publ) | Intelligent piconet forming |
| US6751200B1 (en) * | 1999-12-06 | 2004-06-15 | Telefonaktiebolaget Lm Ericsson (Publ) | Route discovery based piconet forming |
| EP1236315A1 (en) | 1999-12-06 | 2002-09-04 | Telefonaktiebolaget LM Ericsson (publ) | Route discovery based piconet forming |
| US6704293B1 (en) * | 1999-12-06 | 2004-03-09 | Telefonaktiebolaget Lm Ericsson (Publ) | Broadcast as a triggering mechanism for route discovery in ad-hoc networks |
| US6535498B1 (en) * | 1999-12-06 | 2003-03-18 | Telefonaktiebolaget Lm Ericsson (Publ) | Route updating in ad-hoc networks |
| US20020044549A1 (en) | 2000-06-12 | 2002-04-18 | Per Johansson | Efficient scatternet forming |
| US6876643B1 (en) * | 2000-08-08 | 2005-04-05 | International Business Machines Corporation | Clustering in wireless ad hoc networks |
| US7016336B2 (en) * | 2000-11-22 | 2006-03-21 | Telefonaktiebolaget L M Ericsson (Publ) | Administrative domains for personal area networks |
| US7058050B2 (en) * | 2000-12-01 | 2006-06-06 | Telefonaktiebolaget L M Ericsson (Publ) | Flexible inter-network communication scheduling |
| US6954438B2 (en) * | 2001-02-21 | 2005-10-11 | 3Com Corporation | Wireless callback access control for a LAN network access point |
| US6745038B2 (en) * | 2001-04-30 | 2004-06-01 | Motorola, Inc. | Intra-piconet location determination and tomography |
| AU2002313823B2 (en) * | 2001-08-25 | 2008-01-10 | Nokia Corporation | System and method for collision-free transmission scheduling using neighborhood information and advertised transmission times |
| US7161923B2 (en) * | 2001-08-31 | 2007-01-09 | Sharp Laboratories Of America, Inc. | System and method for establishing bluetooth communications |
| US7215976B2 (en) * | 2001-11-30 | 2007-05-08 | Symbol Technologies, Inc. | RFID device, system and method of operation including a hybrid backscatter-based RFID tag protocol compatible with RFID, bluetooth and/or IEEE 802.11x infrastructure |
| US6795421B1 (en) * | 2002-02-12 | 2004-09-21 | Nokia Corporation | Short-range RF access point design enabling services to master and slave mobile devices |
| US6968153B1 (en) * | 2002-03-13 | 2005-11-22 | Nokia Corporation | Apparatus, method and system for a Bluetooth repeater |
| US7580394B2 (en) * | 2002-11-27 | 2009-08-25 | Nokia Corporation | System and method for collision-free transmission scheduling in a network |
-
2003
- 2003-04-09 US US10/409,164 patent/US8351339B2/en not_active Expired - Fee Related
- 2003-04-10 EP EP20030008012 patent/EP1357712A1/en not_active Withdrawn
- 2003-04-24 CN CNB031232477A patent/CN100428711C/zh not_active Expired - Fee Related
- 2003-04-25 JP JP2003121433A patent/JP3840197B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| CN100428711C (zh) | 2008-10-22 |
| JP2003324447A (ja) | 2003-11-14 |
| EP1357712A1 (en) | 2003-10-29 |
| US20030202477A1 (en) | 2003-10-30 |
| CN1453963A (zh) | 2003-11-05 |
| US8351339B2 (en) | 2013-01-08 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3840197B2 (ja) | ブルートゥースオンデマンドルーティング方法及びブルートゥースグループアドホックネットワークにおける通信方法 | |
| Van Hoesel et al. | Prolonging the lifetime of wireless sensor networks by cross-layer interaction | |
| US9386504B2 (en) | Energy-efficient network protocol and node device for sensor networks | |
| JP6323856B2 (ja) | 通信制御方法および移動端末 | |
| KR101515202B1 (ko) | 통신시스템, 통신장치 및 통신방법과 컴퓨터·프로그램 | |
| US20040018839A1 (en) | Protocol and structure for mobile nodes in a self-organizing communication network | |
| US7532594B2 (en) | Method and system of bluetooth network | |
| WO2017101575A1 (zh) | 一种无线自组网的路由方法及装置 | |
| KR100512984B1 (ko) | 블루투스 그룹 애드 호크 네트워크에서의 통신방법 | |
| IL175144A (en) | Wireless data network | |
| JP2008283675A (ja) | 順方向および逆方向のマルチポイントリレー（ｍｐｒ）スパニングツリー経路を用いるアドホックネットワーク経路制御プロトコル | |
| Yujun et al. | The research on an AODV-BRL to increase reliability and reduce routing overhead in MANET | |
| KR100927536B1 (ko) | 위치 정보 기반 라우팅 방법 및 시스템 | |
| US8355380B1 (en) | Mesh power conservation | |
| JP2004312729A (ja) | ブルートゥース高速サブネットにおけるスーパバイザハンドオーバ方法 | |
| JP2006325142A (ja) | 無線端末およびその通信方法 | |
| EP2482589B1 (en) | Method and system for flooding and multicast routing in an AD-HOC network | |
| CN114374639B (zh) | 基于空中唤醒的LoRa-Mesh组网方法及移动终端入网方法 | |
| JP5003900B2 (ja) | 無線ネットワークシステム | |
| GB2468065A (en) | Energy-efficient network protocol and node device for sensor networks | |
| Kim et al. | Optimizing power-aware routing using zone routing protocol in MANET | |
| Patil et al. | Intelligent Energy Efficient Routing Protocol based on Biological Agents for MANETS | |
| Sirilar et al. | OHO: overhearing on-demand route repair mechanism for mobile ad hoc networks | |
| Divya et al. | Energy efficient routing protocols in mobile Ad Hoc network (MANET)–a review | |
| KR100770878B1 (ko) | 모바일 애드 혹 네트워크에서 라우팅 경로 설정 방법 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20051013 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20051019 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060119 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060329 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060629 |
|
| 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: 20060726 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060804 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| LAPS | Cancellation because of no payment of annual fees |