予約ベースのＭＡＣプロトコル
【課題】アド・ホック・マルチホップ・ネットワークにおいて通信をスケジューリングする。
【解決手段】ソースから宛先への経路に沿ってスケジュールされたリソースを有する予約ベースの媒体アクセス制御（ＭＡＣ）プロトコルが含まれる。新たな通信を許可するために、マルチホップ経路に沿って十分なリソースが存在するのであれば、ホップ毎のベースで許可制御が行われ、分散方式で、決定がなされる。
【解決手段】ソースから宛先への経路に沿ってスケジュールされたリソースを有する予約ベースの媒体アクセス制御（ＭＡＣ）プロトコルが含まれる。新たな通信を許可するために、マルチホップ経路に沿って十分なリソースが存在するのであれば、ホップ毎のベースで許可制御が行われ、分散方式で、決定がなされる。
【発明の詳細な説明】
【技術分野】
【０００１】
以下の説明は、一般に、無線通信に関し、さらに詳しくは、超広帯域無線通信ネットワークおよびアド・ホック無線通信ネットワークに関する。
【背景技術】
【０００２】
無線ネットワーキング・システムは、世界中の多くの人々が通信する普及手段になった。無線通信デバイスは、カスタマ・ニーズを満足するためにより小型かつ強力になり、向上された可搬性および利便性を含んでいる。ユーザは、例えば、セルラ電話、携帯情報端末等のような無線通信デバイスのための多くの用途を発見した。そして、そのようなユーザは、信頼できるサービスと拡大された有効範囲領域とを要求している。
【０００３】
無線通信ネットワークは一般に、ユーザがどこに（建物の内部または外部に）位置しているか、および、ユーザが静止しているか移動しているか（例えば、車の中や歩行中）に関わらず、情報を通信するために利用される。一般に、無線通信ネットワークは、基地局またはアクセス・ポイントと通信するモバイル・デバイスを介して確立される。アクセス・ポイントは、地理的地域すなわちセルをカバーする。そして、モバイル・デバイスは、操作されている間、これら地理的なセル中に、およびセル外に移動しうる。途切れのない通信を達成するために、モバイル・デバイスは、モバイル・デバイスが入ったセルのリソースが割り当てられ、モバイル・デバイスが出たセルのリソースが解除される。
【０００４】
ネットワークは、アクセス・ポイントを利用せずに、単独でピア・ツー・ピア通信を利用して構築されることができる。更なる実施形態では、ネットワークは、アクセス・ポイント（インフラストラクチャ・モード）およびピア・ツー・ピア通信の両方を含むことができる。インフラストラクチャのこれらのタイプは、アド・ホック・ネットワークあるいは独立基本サービス・セット（ＩＢＳＳ）と呼ばれる。アド・ホック・ネットワークは自己形成することができる。それによって、モバイル・デバイス（あるいはアクセス・ポイント）が他のモバイル・デバイスから通信を受信すると、他のモバイル・デバイスがこのネットワークに加えられる。モバイル・デバイスがその領域を出ると、モバイル・デバイスは、そのネットワークから動的に除外される。したがって、ネットワークのトポグラフィは、絶えず変わりうる。マルチホップ・トポロジでは、送信者から受信者へと直接的ではなく、多くのホップまたはセグメントを介して送信が転送される。
【０００５】
例えば超広帯域（ＵＷＢ）アド・ホック・ネットワークのようなネットワークにおける無線通信の効率および性能に、様々な要因が影響を与えうる。例えば、有効範囲領域で生じる多くのトラフィックまたはデータ通信は、データ送信時間を減らし、干渉を引き起こす。したがって、通信のサービス品質（ＱｏＳ）は、ネットワークにおいて実質的に同時に生じる他の通信によって影響を受ける。例えば、無線ＬＡＮで用いられるCarrier Sense Multiple Access with Collision Avoidance (CSMA/CA)（ＩＥＥＥ ８０２．１１）のような除外ベース（exclusion-based）のスキームでは、データ・スループットおよび同時送信の数は、ネットワーク内に干渉がある場合には、低減されうる。
【０００６】
他の欠点同様、上述した欠点を克服するために必要なものは、ネットワーク内の他の通信によって引き起こされる干渉を低減しながら、アド・ホック・ネットワークにおけるＱｏＳ通信を確立するための技術である。それは、極めて多くの同時データ伝送のスケジューリングを可能にし、ネットワークのデータ・スループットを増加させる。
【発明の概要】
【０００７】
下記は、開示された実施形態の幾つかの局面の基本的な理解を提供するために、単純化された概要を示す。この概要は広範囲な概観ではなく、主要な要素または決定的な要素を特定するものでも、そのような実施形態の範囲を線引きすることも意図されていない。その唯一の目的は、後に示されるより詳細な記述に対する前置きとして、示される実施形態の幾つかの局面を、簡略化した形式で示すことである。
【０００８】
１または複数の実施形態およびそれに対応する開示に従って、予約ベースの媒体アクセス制御（ＭＡＣ）プロトコルが、ソースから宛先への経路に沿ってスケジュールされたリソースを持つＵＷＢアド・ホック・ネットワークと関連して様々な局面が記述される。
【０００９】
幾つかの実施形態によれば、アド・ホック・ネットワークにおいてサービス品質（ＱｏＳ）通信を確立する方法がある。この方法は、宛先デバイスへの経路を突き止めることと、この経路に沿って特定される少なくとも第１の中間デバイスへと予約要求（ＲＴＲ：Request-to-Reserve）制御パケットを送ることとを含む。ＲＴＲパケットに応答して、この少なくとも第１の中間デバイスから、第１の予約確認（ＲＣ）パケットが受信される。この第１のＲＣパケットは、スケジュールを含んでいる。この第１のＲＣパケットに応答して、この少なくとも第１の中間デバイスへと第２のＲＣパケットが送信される。
【００１０】
幾つかの実施形態に従って、アド・ホック・ネットワークにおいてＱｏＳ通信を確立する装置がある。この装置は、宛先デバイスへの経路に含まれている第１のデバイスへとＲＴＲ制御パケットを送る送信機を含む。この装置はまた、ＲＴＲ制御パケットに応答して第１のＲＣパケットを受信する受信機を含む。この送信機は、第１のＲＣパケットに応答して、第１のデバイスへと、第２のＲＣパケットを送る。
【００１１】
幾つかの実施形態によれば、アド・ホック・ネットワークにおいてＱｏＳ通信を確立する装置がある。この装置は、宛先デバイスへの経路を決定する手段と、予約テーブルを備えるＲＴＲパケットを第１のデバイスへ伝送する手段とを含む。さらにこの装置には、伝送されたＲＴＲ制御パケットに応答して、スケジュールを備えたＲＣパケットを受信する手段と、ＲＣパケットを受信することに応答して、返信ＲＣパケットを送る手段とが含まれる。この返答ＲＣパケットは、スケジュールを確認する。
【００１２】
幾つかの実施形態によれば、アド・ホック・ネットワークにおいてＱｏＳ通信を確立する方法を組み込んだコンピュータ読取可能媒体がある。この方法は、ソース・デバイスと宛先デバイスとの間の通信経路を決定することと、この通信経路に沿って位置している第１のデバイスへと、ＲＴＲパケットを送信することとを含む。このＲＴＲパケットが送信されたことに応答して、この第１のデバイスから、第１のＲＣパケットが受信され、第２のＲＣパケットが、第１のデバイスへ送信され、第１のＲＣパケットで情報が受信されたことが確認される。
【００１３】
幾つかの実施形態にしたがって、アド・ホック・ネットワークにおいてＱｏＳ通信を確立するプロセッサがある。このプロセッサは、ソース・デバイスと宛先デバイスとの間の通信経路を決定し、この通信経路に位置する第１のデバイスへとＲＴＲパケットを伝送するように構成される。このＲＴＲパケットは、ソース・デバイスの予約テーブルを含む。このプロセッサはさらに、ＲＴＲパケットに応答してＲＣパケットを受信し、受信したＲＣパケットにおけるスケジュールを確認する返信ＲＣパケットを送るように構成される。このＲＣパケットは、ソース・デバイスのためのスケジュールを含んでいる。
【００１４】
幾つかの実施形態にしたがって、アド・ホック通信ネットワークにおいて通信をスケジューリングする方法がある。この方法は、少なくとも第１の無線デバイスからＲＴＲ制御パケットを受信することと、少なくとも第１の無線デバイスから宛先デバイスへのスケジュールを決定することとを含む。少なくとも第１の無線デバイスと宛先デバイスとの間の通信のための最も早いスケジュールが、許可制御ポリシーに基づいて選択され、ＲＴＲパケットが宛先デバイスへ送られる。このＲＴＲパケットに応答して、宛先デバイスからＲＣパケットが受信され、このＲＣパケットは、少なくとも第１の無線デバイスへと送信される。このＲＣパケットは、通信スケジュールを含んでいる。
【００１５】
幾つかの実施形態にしたがって、アド・ホック通信ネットワークにおいて通信をスケジュールする装置がある。この装置は、少なくとも第１のノードから、ＲＴＲ制御パケットを受信する受信機と、利用可能なスケジュールを分析し、許可制御ポリシーに基づいて、ソース・ノードと宛先ノードとの間の通信のための最も早いスケジュールを選択するスケジューラとを含む。さらにまた、宛先ノードへＲＴＲパケットを送信する送信機が含まれる。ＲＴＲパケットは、最も早い通信スケジュールを含んでいる。
【００１６】
幾つかの実施形態にしたがって、アド・ホック通信ネットワークにおいて通信をスケジューリングする装置がある。この装置は、ソース・デバイスから宛先デバイスへの経路を含むＲＴＲ制御パケットを受信する手段と、この経路のために利用可能なスケジュールを分析する手段とを含む。さらにまたこの装置には、最も早いスケジュールを選択する手段と、ＲＴＲパケットを宛先デバイスへ伝送する手段とが含まれる。このＲＴＲパケットは、最も早いスケジュールを含んでいる。
【００１７】
幾つかの実施形態によれば、超広帯域アド・ホック通信ネットワークにおいて通信をスケジューリングする方法を組み込んだコンピュータ読取可能媒体がある。この方法は、ソース・デバイスから宛先デバイスへの経路を含むＲＴＲ制御パケットを受信することと、この経路のために利用可能なスケジュールを分析することとを含む。最も早いスケジュールが選択され、宛先デバイスへＲＴＲパケットが伝送される。このＲＴＲパケットは、最も早いスケジュールを含んでいる。
【００１８】
幾つかの実施形態によれば、アド・ホック通信ネットワークにおいて通信をスケジューリングするプロセッサがある。このプロセッサは、少なくとも第１の無線デバイスから、ＲＴＲ制御パケットを受信し、許可制御ポリシーに基づいて、少なくとも第１の無線デバイスから宛先デバイスへのスケジュールを決定するように構成される。このプロセッサはさらに、少なくとも第１の無線デバイスと宛先デバイスとの間の通信のための最も早いスケジュールを選択するように構成される。宛先デバイスにはＲＴＲパケットが送られ、このＲＴＲパケットに応答して、宛先デバイスからのＲＣパケットが受信される。このプロセッサはさらに、少なくとも第１の無線デバイスへとＲＣパケットを送信するように構成される。このＲＣパケットは、通信スケジュールを含んでいる。
【００１９】
幾つかの実施形態にしたがって、アド・ホック通信をスケジューリングする方法がある。この方法は、少なくとも第１のデバイスからＲＴＲパケットを受信することと、許可制御ポリシーを利用する通信スケジュールに部分的に基づいて、実現可能なスケジュールを決定することとを含む。ＲＴＲパケットは、通信スケジュールを含んでいる。この実現可能なスケジュールを含むＲＣパケットは、少なくとも第１のデバイスへ送信される。
【００２０】
幾つかの実施形態にしたがって、超広帯域アド・ホック通信をスケジューリングする装置がある。この装置は、少なくとも第１のデバイスからＲＴＲパケットを受信する受信機と、ＲＴＲパケットに含まれる情報に部分的に基づいてスケジュールを決定するスケジューラとを含む。さらに、この装置には、ＲＴＲパケットを受信することに応答してＲＣパケットを送信する送信機が含まれている。このＲＣパケットは、スケジュールのうちの１つ、またはスケジュールが実現不可能であることを含んでいる。
【００２１】
幾つかの実施形態によれば、超広帯域アド・ホック通信をスケジューリングする装置がある。この装置は、ＲＴＲパケットを受信する手段と、スケジュールされた少なくとも１つの通信と干渉しないスケジュールを決定する手段とを含む。さらに、この装置には、ＲＴＲパケットを受信することに応答して、スケジュールを含むＲＣパケットを送る手段が含まれる。
【００２２】
幾つかの実施形態によれば、アド・ホック通信をスケジューリングする方法を組み込んだコンピュータ読取可能媒体がある。この方法は、少なくとも第１のデバイスからＲＴＲパケットを受信することと、ＲＴＲパケットに含まれる情報に部分的に基づいてスケジュールを決定することとを含む。ＲＴＲパケットを受信することに応答して、スケジュールのうちの１つ、このスケジュールが実現不可能であることを含むＲＣパケットが送信される。
【００２３】
幾つかの実施形態にしたがって、アド・ホック通信をスケジューリングするためのプロセッサがある。このプロセッサは、ＲＴＲパケットを受信し、スケジューリングされた少なくとも１つの通信と干渉しないスケジュールを決定するように構成される。このプロセッサはさらに、ＲＴＲパケットを受信することに応答して、スケジュールを含むＲＣパケットを送るように構成される。
【００２４】
幾つかの実施形態にしたがって、マルチホップ・アド・ホック・ネットワークにおいて通信をスケジューリングする方法がある。この方法は、近隣デバイス間で通信されるＲＣパケットを探索することと、ＲＣパケットに含まれる情報を用いて、中間デバイスの予約テーブルを更新することとを含む。この方法はさらに、ソース・デバイスからのＲＴＲパケットを、第１の中間デバイスにおいて受信することを含む。このＲＴＲパケットは、ソース・デバイスの予約テーブルを含んでいる。この更新された予約テーブルと、ソース・デバイス予約テーブルとが分析され、分析された予約テーブルに部分的に基づいて、ソース・デバイスと宛先デバイスとの間の通信スケジュールが決定される。
【００２５】
幾つかの実施形態にしたがって、マルチホップ・アド・ホック・ネットワークにおいて通信をスケジューリングする装置がある。この装置は、アクティブな近隣ノード間で生じている通信を監視するオブサーバと、監視された通信に含まれる情報を用いて、リソース予約テーブルを更新するコンフィギャラとを含む。さらにこの装置には、ソース・デバイスからＲＴＲパケットを受信する受信機が含まれている。このＲＴＲパケットは、ソース・デバイスと宛先デバイスとの間の経路を含んでいる。ソース・デバイスから宛先デバイスまでの経路に沿った通信をスケジューリングするスケジューラも含まれている。
【００２６】
幾つかの実施形態によれば、マルチホップ・アド・ホック・ネットワークにおいて通信をスケジューリングする装置がある。この装置は、近隣デバイス間で通信されるＲＣパケットを探索する手段と、ＲＣパケットに含まれる情報を用いて、中間デバイスの予約テーブルを更新する手段とを含む。さらにはソース・デバイスからのＲＴＲパケットを、第１の中間デバイスにおいて受信する手段と、更新された予約テーブルと、ソース・デバイス予約テーブルとを分析する手段とが含まれる。ＲＴＲパケットは、ソース・デバイスの予約テーブルを含んでいる。この装置には、分析された予約テーブルに部分的に基づいて、ソース・デバイスと宛先デバイスとの間の通信スケジュールを決定する手段も含まれる。
【００２７】
幾つかの実施形態にしたがって、マルチホップ・アド・ホック・ネットワークにおいて通信をスケジューリングする方法を組み込んだコンピュータ読取可能媒体がある。この方法は、アクティブな近隣ノード間で生じる通信を監視することと、監視された通信に含まれる情報を用いて、リソース予約テーブルを更新することとを含む。ソース・デバイスからは、ソース・デバイスと宛先デバイスとの間の経路を含むＲＴＲパケットが受信される。通信は、ソース・デバイスから宛先デバイスへの経路に沿ってスケジューリングされる。
【００２８】
幾つかの実施形態にしたがって、マルチホップ・アド・ホック・ネットワークにおいて通信をスケジューリングするプロセッサがある。このプロセッサは、近隣デバイス間で通信されているＲＣパケットを探索し、ＲＣパケットに含まれる情報を用いて、中間デバイスの予約テーブルを更新するように構成される。このプロセッサはさらに、ソース・デバイスからのＲＴＲパケットを第１の中間デバイスにおいて受信し、更新された予約テーブルと、ソース・デバイス予約テーブルとを分析し、分析された予約テーブルに部分的に基づいて、ソース・デバイスと宛先デバイスとの間の通信スケジュールを決定するように構成される。このＲＴＲパケットは、ソース・デバイスの予約テーブルを含んでいる。
【００２９】
上述した目的および関連する目的を達成するために、１または複数の実施形態は、以下に完全に記載され、特許請求の範囲で述べられている特徴を備える。以下の記載および添付図面は、ある例示的な局面を詳細に述べており、実施形態の原理が適用される様々な方式のうちのごく少数を示しているにすぎない。その他の利点および斬新な特徴が、これら図面と連携して考慮された場合に以下の詳細説明から明らかになるだろう。そして、開示された実施形態は、そのような全ての局面およびそれらの等化物を含むことが意図される。
【図面の簡単な説明】
【００３０】
【図１】図１は、マルチホップ・アド・ホック無線ネットワークにおいて通信をルーティングすることを例示する。
【図２】図２は、ＵＷＢアド・ホック無線ネットワーク内でスケジューリングすることを例示する。
【図３】図３は、ＵＷＢ環境における予約ベースのＭＡＣプロトコルのための典型的なスケジュールを例示する。
【図４】図４は、開示された実施形態にしたがった無線デバイスを例示する。
【図５】図５は、開示された実施形態にしたがった予約更新タイムラインを例示する。
【図６】図６は、ＵＷＢアド・ホック・ネットワークにおけるＱｏＳ音声コールの確立のための方法論を例示する。
【図７】図７は、超広帯域アド・ホック通信ネットワークにおいて通信をスケジューリングするための方法論を例示する。
【図８】図８は、超広帯域アド・ホック通信をスケジューリングするための方法論を例示する。
【図９】図９は、近隣デバイス間で交換された情報に部分的に基づいて通信をスケジューリングする方法論を例示する。
【図１０】図１０は、ＵＷＢアド・ホック・ネットワークにおいてＱｏＳ通信を確立するためのシステムを例示する。
【図１１】図１１は、超広帯域アド・ホック通信ネットワークにおいて通信をスケジューリングするためのシステムを例示する。
【図１２】図１２は、超広帯域アド・ホック通信スケジューリングのためのシステムを例示する。
【図１３】図１３は、マルチホップ・アド・ホック・ネットワークにおいて通信をスケジューリングするためのシステムを例示する。
【図１４】図１４は、端末の可能な構成概念を示すブロック図を例示する。
【発明を実施するための形態】
【００３１】
様々な実施形態が、図面を参照して記載される。以下の説明では、説明の目的で、１または複数の局面の完全な理解を提供するために、多くの具体的な詳細が述べられる。しかしながら、そのような実施形態は、これら具体的詳細なしで実現されうることが明白である。他の事例では、周知の構成およびデバイスが、これらの実施形態の記載を容易にするために、ブロック図形式で示される。
【００３２】
本願で用いられるように、用語「構成要素」、「モジュール」、「システム」等は、ハードウェア、ソフトウェア、ハードウェアとソフトウェアとの組み合わせ、ソフトウェア、実行中のソフトウェアのうちの何れかであるコンピュータ関連エンティティを称することが意図される。例えば、構成要素は、限定される訳ではないが、プロセッサ上で実行しているプロセス、プロセッサ、オブジェクト、実行形式、実行スレッド、プログラム、および／または、コンピュータでありうる。実例として、計算デバイス上で動作するアプリケーションと、計算デバイスとの両方が、構成要素になりえる。１または複数の構成要素は、プロセスおよび／または実行スレッド内に存在することができ、構成要素は、１つのコンピュータ上に局在化されるか、および／または、２またはそれ以上のコンピュータに分散されうる。さらに、これらの構成要素は、様々なデータ構造を格納して有している様々なコンピュータ読取可能媒体から実行されうる。これらの構成要素は、（例えば、ローカル・システムや分散システムと相互作用する１つの構成要素からのデータ、および／または、例えば信号を介して他のシステムと通信するインターネットのようなネットワークを介したデータのような）１または複数のデータ・パケットを有する信号にしたがって、ローカル処理および／または遠隔処理によって通信することができる。
【００３３】
さらに、本明細書では、様々な実施形態がユーザ・デバイスに関して記載される。ユーザ・デバイスはまた、システム、加入者ユニット、加入者局、移動局、モバイル・デバイス、遠隔局、アクセス・ポイント、基地局、遠隔端末、アクセス端末、ハンドセット、ホスト、ユーザ端末、端末、ユーザ・エージェント、無線端末、無線デバイス、またはユーザ機器と称されうる。ユーザ・デバイスは、セルラ電話、コードレス電話、セッション開始プロトコル（ＳＩＰ）電話、無線ローカル・ループ（ＷＬＬ）局、パーソナル・デジタル・アシスタント（ＰＤＡ）、無線接続機能を有するハンドヘルド・デバイス、または、無線モデムに接続されたその他の処理デバイスでありうる。
【００３４】
さらに、本明細書に記載の様々な局面または特徴は、標準的なプログラミング技術および／またはエンジニアリング技術を用いた方法、装置、または製造物品として実現されうる。本明細書で使用される用語である「製造物品」は、任意のコンピュータ読取可能デバイス、キャリア、または媒体からアクセスすることが可能なコンピュータ・プログラムを含むことが意図されている。例えば、コンピュータ読取可能媒体は、限定される訳ではないが、磁気記憶装置（例えば、ハードディスク、フロッピー（登録商標）ディスク、磁気ストライプ等）、光ディスク（例えばコンパクト・ディスク（ＣＤ）、ＤＶＤ等）、スマート・カード、およびフラッシュ・メモリ・デバイス（例えば、カード、スティック、キー・ドライブ等）を含むことができる。
【００３５】
様々な実施形態が、多くのデバイス、構成要素、モジュール等を含みうるシステムの観点から示されるだろう。様々なシステムが、追加のデバイス、構成要素、モジュール等を含み、および／または、図面と関連して説明されたデバイス、構成要素、モジュール等のうちの全てを必ずしも含む訳ではないことが理解され認識されるべきである。これらのアプローチの組み合わせも使用されうる。
【００３６】
図示するように、図１は、マルチホップ・アド・ホック無線ネットワーク１００において通信をルーティングすることを例示する。例示目的であって、限定するのではなく、以下は、無線マルチホップ・アド・ホック・システムにおける通信のルーティングを説明する。システム１００は、無線通信している任意の数のモバイル・デバイスまたはノードを含むことができ、うち６個が例示されている。モバイル・デバイスは、例えば、セルラ電話、スマート電話、ラップトップ、ハンドヘルド通信デバイス、ハンドヘルド計算デバイス、衛星ラジオ、全地球測位システム、パーソナル・デジタル・アシスタント（ＰＤＡ）、および／または、無線ネットワーク１００を介して通信するためのその他適切なデバイスでありうる。無線ネットワーク１００はまた、１または複数の基地局またはアクセス・ポイント（図示せず）を含むことができる。
【００３７】
送信者すなわちソース・ノード１０２は、受信者すなわち宛先ノード１０４と通信することを望んでいる。送信ノード１０２と受信ノード１０４との間のパケット転送を可能にするために、１または複数の中間ノード１０６，１０８、１１０、および／または１１２を利用することができる。任意のノード１０２−１１２が送信ノード、受信ノード、および／または中間ノードになりえることが理解されるべきである。
【００３８】
送信ノード１０２と受信ノード１０４との間のパケット転送は、様々な経路をとりうる。例えば、パケットは、送信ノード１０２から中間ノード１０８、１１２へと転送され、最終的に、その宛先である受信ノード１０４に到着する。しかしながら、例えばノード１０２からノード１０６、ノード１１０、ノード１１２、そして最終的にノード１０４へ行くようなその他の経路も可能である。パケットは、その目的地に到達するために多くの異なるルートまたは経路をとることができ、そのようなルートの全てを説明することは不可能であることが理解されるべきである。
【００３９】
ノード１０２−１１２は、モバイル・デバイスでありえるので、システム１００に入ることも、システム１００から出ることもできる。ノードが移動し、他のノードと通信することができない場合、異なる経路および通信スケジュールがネゴシエートされうる。ノードは、システム１００に入り、新たに追加されたノードを含む経路および通信スケジュールが、生成またはネゴシエートされうる。
【００４０】
したがって、アド・ホック・ネットワークは本質的に動的であって、（新たなセッションによって）新たなリンクが形成される一方、他のリンクがネットワークから離脱しうる。リンクのこの動的な性質はまた、信号成分のうちの１つまたは全てにおける信号強度の低減またはフェージングのようなチャネル特性によって生じる。この動的な性質は、リソース割り当てを選択する。例えば、グローバル・リソース・アロケーション（ＧＲＡ）スキームでは、新たなリンクが生成または終了する毎に、全て（出てゆくものを含む）のリンクのリソースがネゴシエートされる。インクリメント・リソース・アロケーション（ＩＲＡ）スキームでは、セッションの開始時に一度、リソースが割り当てられる。したがって、ＩＲＡスキームでは、ネットワークは、既存のリンクに割り当てられたリソースを維持しながら、リソースを新たなリンクに割り当てる。
【００４１】
システム１００は、通信がデータ・レートおよび遅れ、またはサービス品質（ＱｏＳ）要件を満足しているか否かを確認するように構成されうるＭＡＣプロトコルを利用することができる。ＵＷＢ物理レイヤに基づいて、ＭＡＣは、限定的に制限すると、ＣＤＭＡベースのＭＡＣでありうる。さらに、システム１００は、動的なアド・ホック性質を持っているので、既存のリンクを保護しながら、新たなリンクへリソースを割り当てるインクリメントおよび分散スキームにしたがうべきである。
【００４２】
本明細書で開示された様々な実施形態は、双方向リンクを有する音声トラフィックに関連することができる。したがって、スケジューリングされるデータは、固定ビット・レートを持つことができる。例えば、おのおののリンクは、９．６Ｋｂｐｓ（Ｒｖｏｉｃｅ）で送信されうる。ソースから受信側へと発生する遅延（口／耳遅延としても知られている）が、制御されるべきである。この遅延は、許容できる音声品質のために１５０ミリ秒から２００ミリ秒にわたることができる。音声通信は、計算に係る（例えば、符合化、復号）遅延およびバッファリング遅延に加えて、多くのホップを介した送信遅延をもたらす。したがって、ホップ毎の遅延ＴＲＥＰは、例えば２０ミリ秒のように、便利な値に制限されるべきである。さらに、データ・レートＲｖｏｉｃｅと、約１５０ミリ秒でありうる遅延からなるＱｏＳパラメータを維持しながら、ソースから宛先へとリソースがスケジュールされねばならない。様々な実施形態は、音声トラフィックに関して記載されているが、その他の様々な通信（例えば、データ、ビデオ、音楽等）にも適用可能であることが理解されるべきである。
【００４３】
システム１００によって利用されるＭＡＣプロトコルは、予約ベースのＭＡＣであり、リソースが、ソースから宛先へと全体経路に沿ってスケジュールされている。すなわち、予約は、リンクの何れかが許可される前に、経路内の全てのリンクに沿って生じる。これは、ＱｏＳが保証されない場合、音声コールを確立できないという結果になりうる。予約されたリソースは、反復期間ＴＲＥＰを持つ（可変サイズまたは可変長の）時間スロットのものである。許可制御と組み合わされたこの反復期間は、通信のためのＱｏＳを満足することを支援する。システム１００は、干渉マージン（Ｍ）の概念とＣＤＭＡとを利用して、同時送信を許可する（例えば、除外ではなくスケジューリングする）こと等によって、ＵＷＢ物理レイヤの拡散スペクトル特性を導入する。ハイブリッドＡＲＱの時間スロット復元技術はまた、リソース利用を向上するためにも用いられうる。
【００４４】
それぞれのノードは、その近辺にあるノードに関する情報を、例えばリソース予約テーブル（ＲＴ）内に保持する。そのようなテーブルは、ＩＥＥＥ ８０２．１１スキームで使用されるネットワーク・アロケーション・ベクトル（ＮＡＶ）の拡張版でありうる。リソース予約テーブルは、対象ノードの近傍内の他のアクティブ・ノード（例えば、受信および送信を行っているか、何れかの機能を実行するようにスケジュールされたノード）に関する情報を用いて、対象ノードを符合化することができる。近傍にある全てのアクティブ・ノードについて、リソース予約テーブルは、各アクティブ・ノードのスケジュール（例えば、送信の時間スロット）、干渉マージン、送信電力、および、ノード間の経路喪失を含むことができる。
【００４５】
（例えば、予約要求（ＲＴＲ：Request To Reserve）パケットや、予約確認（ＲＣ：Reservation Confirm）パケット交換による）リソース予約要求は、アド・ホック・ネットワークをもたらす非効率を緩和するために複数の対策を講じる通知された制御メカニズムの利用をもたらす。そのような対策は、共通予約チャネル（例えば、予約パケットのために利用されている共通ＰＮコード）を聞くことを含む。これによって、ノードは、その近傍に関する情報を取得できるようになる。その近傍に関して得られた知識を用いて、ノードは、パケットが、スケジュールされた送信と干渉しないように予約パケットを送信することができる。
【００４６】
別の対策は、適切な範囲を得るために、予約パケット（ＲＴＲ／ＲＣ）をレートＲＲＣで送ることを含むことができる。この範囲は、干渉範囲（ＩＲ）または干渉近傍と考えることができる。この範囲内のリンクは、他の通信と干渉する場合、個別のリソースを割り当てられうる。予約チャネルのために異なるレートを用いることによって、隠れ端末問題（hidden terminal problems）を緩和することができる。なぜなら、干渉範囲は、送信範囲とは異なるからである。その後、スケジュールを決定するために、許可制御ポリシーを用いることができる。決定されたスケジュール、または、リンクを実行できないことが、ＲＣパケットによって送信ノードへと伝送される。
【００４７】
選択された範囲であるレートＲＲＣでＲＴＲ／ＲＣパケットを送信することは、各ノードの広い近傍を提供し、各ノードが、（スケジュールされねばならない）潜在的に干渉しているリンクに関する情報を取得できるようにする。したがって、隠れ端末問題あるいは露出ノード問題は、存在しない。
【００４８】
さらに、予約パケットの範囲が固定されているので、より短いリンクは、より大きな干渉半径／送信半径比を持つはずである。より短いリンクは、一般により強いリンクであり、より少ない干渉しか許容しないに違いない。したがって、ＲＣ／ＲＴＲパケットの範囲を、可能な限り大きな範囲に設定することによって、適応性のある特性をネットワークに与えることができ、より強いリンクは、より広い周辺領域に関する情報を持つので、低い干渉しかなく、より良好なスケジュールを選択できるに違いない。
【００４９】
図２は、様々な実施形態にしたがったＵＷＢアド・ホック無線ネットワーク２００におけるスケジューリングを例示する。無線ネットワーク２００は、ノードＡ２０２、ノードＢ２０４、ノードＬ２０６、ノードＣ２０８、ノードＥ２１０およびノードＤ２１２として表される複数のノードを含んでいる。特定のネットワークに依存して、これより多くまたはこれより少ないノードとなりうることが理解されるべきである。
【００５０】
以下の例は、開示された実施形態を利用する典型的なネットワークを示す。ノードＡ２０２は、ノードＢ２０４とのセッションを始めることを望む。ノードＡ２０２は、ノードＡ２０２と、ノードＢ２０４との間の経路を探索または識別することによって始まる。この経路は、ノードＡ２０２と、ノードＢ２０４との間のセッションを確立するために十分なリソース（例えば、ＱｏＳルーティング・プロトコルをオーバレイすることによって提供される粗い推定値）を持つに違いない。これは、プロトコル・スタックのネットワーク・レイヤにおいて動作するサービス品質（ＱｏＳ）ルーティング・プロトコルの一部でありうる。例示目的で、ＭＡＣレイヤにおいて、そのような経路が発見されたと仮定される。この経路は、例えばＡ−Ｌ−Ｂと命名することができる。ＵＷＢ環境における予約ベースのＭＡＣプロトコルのための典型的なスケジュール３００が、図３に例示される。この典型的なスケジュール３００は、長さが１９２ビットであり、１５３．６Ｋｂｐｓ（例えば、２つのパケットまたは双方向リンクからなるセットのおのおのが２．５ミリ秒をとる）のレートで送られる音声パケットを利用して構築された。しかしながら、開示された実施形態で、その他の音声パケットの長さおよびレートが利用されうることが理解されるべきである。
【００５１】
送信の構造は、ネットワークを介した別の双方向リンク（例えばＡ−Ｌ、Ｌ−Ａ、Ｅ−Ｃ、Ｃ−Ｅなど）に割り当てられた適切な持続期間からなる時間スロット（３０２、３０４において代表的に示す）からなる。おのおのの双方向リンクは、スケジュールされた持続時間の間送信し、ＴＲＥＰ毎に送信を繰り返す。図示するように、おのおののリンクは自分自身の周期的な送信を有する。これは、ネットワーク内の１つおきのリンクの送信からディザ（dither）されうる。したがって、明確なフレーム構造はない。ＱｏＳを保証するのに役立つために、全てのリンクが、両方向において、（Ｒｖｏｉｃｅ＊ＴＲＥＰ）個のビットを送信すべき（例えば、合計して［２＊Ｒｖｏｉｃｅ＊ＴＲＥＰ］個のビットを交換するべき）である。リンクＲＯＰの運用上のデータ・レートに基づいて、時間スロットは、持続時間（２＊Ｒｖｏｉｃｅ＊ＴＲＥＰ／ＲＯＰ）でありうる。明確なフレーム構造がないので、ネットワークを介して必要とされる精密に調節された同期は存在せず、アド・ホック・ネットワークの低オーバヘッド分布特性に一致する。
【００５２】
経路Ａ−Ｌ−Ｂを特定した後、ノードＡ２０２は、予約要求（ＲＴＲ）制御パケット３０６を、共通のコードで、中間ノードＬ２０６へ送信する。ＲＴＲパケット３０６は、ノードＡ２０２のリソース予約テーブルを含まねばならない。最初に、ノードＡ２０２の予約テーブルは空であるので、ノードＡ２０２の観点から、送信Ａ−Ｌについての制約はない。ノードＣ２０８は、ＲＴＲパケット３０８を聞き、解釈することができるが、ＲＴＲパケット３０６に関していかなる機能（例えば、テーブの解釈、更新など）も実行しない。
【００５３】
予約テーブルは、おのおののノードにおいて保持されるべきである。テーブルは、ＩＥＥＥ ８０２．１１スキームで利用された、ネットワーク・アロケーション・ベクトル（ＮＡＶ）の拡張と考えることができる。予約テーブルは、ノードの近傍内にある他のアクティブ・ノード（例えば、それぞれの機能を実行するために受信し、送信し、あるいはスケジュールされたノード）に関する知識を用いて、適切なノードを符合化する。特定のノードの近傍内にあるすべてのアクティブ・ノードについて、予約テーブルは、アクティブ・ノード・スケジュール（例えば、送信の時間スロット）、干渉マージンＭ（ｊ）、送信電力、アクティブ・ノードｊからノードｉへの経路喪失Ｇｉｕを含む。したがって、予約テーブルｉは、近傍内における全てのノードに含まれるローカル・スケジュールおよびトポロジ情報を示す。
【００５４】
このパケットを受信するのと実質的に同時に、ノードＬ２０６は、その予約テーブルと、ＲＴＲパケット３０６に含まれるノードＡ２０２の予約テーブルとを調べる。ノードＬ２０６は、通信Ａ−Ｌ ３０２のために実行可能なスケジュールの発見を試みる。実行可能にするために、許可制御ポリシーがアクセスされ、スケジュールの様々な条件（例えば、近隣のアクティブ・ノード、ネットワーク内のスケジュールされた他の送信、送信レートに関する情報）が確認される。最初の送信のために、ノードＡ２０２とノードＬ２０６の予約テーブルが空にされ、これによって、条件が満たされる。
【００５５】
ノードＬ２０６は、通信Ａ−Ｌのため（Ｔ１中）、最も早期のスケジュールを選択することができる。ノードＬ２０６は、その予約テーブルを更新し、更新された予約テーブルを含むＲＴＲパケット３０８を、ノードＢ２０４に送る。ＲＴＲパケット３０８を受信するのと実質的に同時に、ノードＢ２０４は、ノードＬ２０６とノードＢ２０４の予約テーブルを調べ、実行可能なスケジュールの発見を試みる。もしもスケジュール３０４が発見されると、ノードＢ２０４は、予約確認（ＲＣ）パケット３１０をもって応答し、スケジュールＬ−Ｂ ３０４をアナウンスする。
【００５６】
ＲＣパケットは、近隣ノード（例えば、ノードＥ２１０、ノードＣ２０８等）によってパケットを聞くことを可能にする共通のコードを用いて送信されねばならない。ＲＣパケットには、ノード受信の干渉マージンＭが含まれうる。この干渉マージンによって、近傍内のノードは、そのようなノードが、同時通信をスケジュールできるかを判定することが可能となる。ＲＣパケットはまた、ノードの電力および送信スケジュールを含むべきである。そのような情報によって、近傍にあるノードは、スケジュールされたセッションから、予期された干渉を判定できるようになる。
【００５７】
ＲＣパケット３１０を受信するのと実質的に同時に、ノードＬ２０６は、ノードＡ２０４にＲＣパケット３１２を送り、スケジュールＬ−Ｂ ３０４およびスケジュールＡ−Ｌ ３０２をアナウンスする。ノードＡ２０２は、ＲＣパケット３１２を受信するのとほぼ同時に、ＲＣパケット３１４をノードＬ２０６に送り、スケジュールＡ−Ｌ ３０２をアナウンスする。
【００５８】
近傍におけるノード（例えば、この例ではノードＣ２０８、ノードＥ２１０、およびノードＤ２１２である近隣ノード）は、そのようにして、それぞれの予約テーブルを更新する。ノードＡ２０２とノードＢ２０４との間の実際のデータ送信は、時間Ｔ２において３１６および３１８に示すように、決定されたスケジュールにしたがって進む。
【００５９】
例を続けると、ノードＥ２１０は、経路Ｅ−Ｃ−Ｌ−Ｄを介してノードＤ２１２とのセッションを開始したいと思っている。ノードＥ２１０は、ノードＣ２０８にＲＴＲパケット３２０を送る。ＲＴＲパケット３２０は、ノードＥ２１０の予約テーブルを含まねばならない。通信Ａ−Ｌ ３１６および通信Ｌ−Ｂ ３１８に気づいているノードＣ２０８は、ノードＥ２１０からの通信を同時にスケジューリングできるかを判定することができる。通信Ｃ−Ｌ ３２２の送信電力が、（例えば、ノードＬ２０６において）スケジューリングされた通信Ａ−Ｌ ３１６を妨害するが、スケジューリングされた通信Ｌ−Ｂ ３１８を妨害しないと仮定する。したがって、ノードＣ２０８は、Ｅ−Ｃ ３２２をＬ−Ｂ ３１８と同時にスケジュールすることができ、この情報を、ＲＴＲパケット３２２で、ノードＬ２０６へ通信しなくてはならない。必要ならば、ノードＣは、３２４に示すように、ノードＬ２０６がアイドルになるまで待機し、ノードＬ２０６が通信を受信する準備ができたときにＲＴＲパケット３２２を送る。ノードＬ２０６は、通信Ｃ−Ｌ ３２６をスケジューリングし、ノードＤ２１２にＲＴＲパケット３２８を送ることができる。ノードＤ２１２は、ＲＣパケット３３０をもってＲＴＲパケット３２８に応答し、スケジュールＬ−Ｄ ３３２をアナウンスする。例示するように、ノードＬ２０６は、ＲＣパケットをもって応答するための十分な時間を持っていない。したがって、ノードＬ２０６は、次の期間Ｔ３まで、ＲＣパケット３３４を送るのを待つ。その後、ノードＣ２０８が、ＲＣパケット３３６を送る。ＲＣパケットを受信すると、ノードＥ２１０は、ＲＣパケット３３８を送る。このように、データは、スケジューリングされた経路Ｅ−Ｃ−Ｌ−Ｄに沿って送られる。
【００６０】
対象デバイスの近傍または近辺にあるおのおののアクティブ・ノードについて、対象デバイスの予約テーブルの以下のエントリーが送られる。送信／受信フラグ、スケジュール、最大許容干渉、および送信電力。送信／受信フラグは、説明したリンクについて近隣ノードが送信機であるか受信機であるかを示すことができ、約１バイトの長さでありうる。スケジュールは、近隣ノードのアクティビティ（例えば、受信、送信）の持続時間および開始時間を含む。このスケジュールは、キャラクタを用いた約２バイトであることができ、時間スロットでありうる。近隣ノードが受信中、Ｍ（ｕ）によって示される近隣ノードの最大許容干渉（Ｍ）は、約１バイトの長さでありうる。これは、近隣ノードが、例えば（近隣ノードによって通知された）対象デバイスのような干渉ノードから許容できる最大の追加干渉である。これらのエントリは、それぞれの予約制御パケット内の近隣ノードによって通知される情報を利用して、および、そのような制御パケットの信号強度を測定することによって計算されうる。スケジュールされた送信中、近隣ノードの送信電力は、およそ１バイトの長さでありうる。
【００６１】
（約６バイトでありうる）近隣デバイスのアドレスと、（約６バイトの長さでありうる）宛先デバイスのアドレスとは、予約テーブル・エントリに含まれうるが、ＲＴＲパケットで送られる必要はないことに注目されるべきである。したがって、予約テーブル・エントリは、約５バイトのデータを含むことができる。
【００６２】
ＲＴＲパケットは、予約テーブルを含んでいるので、ＲＴＲパケットは、可変長である。さらに、ＲＴＲパケットは、以下のフィールドを含むことができる。送信元アドレス（約６バイト）、受信アドレス（ＭａｃＤｅｓ）（約６バイト）、パケット・タイプを含む約１バイト、およびエントリ数を含む約１バイトのフィールド。
【００６３】
ＲＴＲパケットの推定サイズは、約７バイトかそれ以上になるが、プリアンブル、物理ヘッダ、および予約テーブルにおけるエントリ数は含んでいない。２つの送信について、その他２つのノードを聞いたり、あるいは観察するリンクの場合、予約テーブルに関して着目される推定値を利用することによって、おのおののＲＴＲパケットは、合計３４バイト（１４＋（４＊５））のサイズを持つが、これはＰＨＹヘッダ（２４バイト）と、プリアンブル（１０マイクロ）を含んでいない。これは、１５３．６Ｋｂｐｓにおいて３．０３ミリ秒、５００Ｋｂｐｓにおいて０．９８ミリ秒のオーバヘッドを表しうる。したがって、送信機は、オーバヘッドを最小化するＲＴＲパケットを送るための最良のレートを知っている。しかしながら、このレートは一般に、ＲＴＲ受信が成功した後に決定されるので、ＲＴＲは、Ｒｍｉｎで送られる。なぜなら、リンクは、少なくともこのレートをサポートしなくてはならないからである。
【００６４】
ＲＣパケットは、固定長であり、比較的小さいオーバヘッドしか有さない。例示目的のために、ノードＢ２０４がノードＡ２０２からＲＴＲパケットを受信し、ノードＢ２０４が、ＲＣパケットをもって応答することを望んでいると仮定する。ノードＢ２０４は、約２バイトでありうる送信フィールドの開始および終了を含む様々なフィールドをＲＣパケットに含めるだろう。コールを識別するソース・アドレス・フィールドもまた含まれる。これは、約６バイトでありリンクの送信元を識別することができる送信元アドレスと同様に、約６バイトでありうる。ＲＣパケットはまた、長さ約６バイトである宛先アドレス・フィールドを含む。ＲＣパケットには、送信元および受信側における送信電力および干渉マージン（約４バイト）、パケット・タイプを含む（およそ）１バイトのフィールド、エントリ数を示す（およそ）１バイトが含まれる。ＲＣパケットは、約２６バイトであり、ＰＨＹヘッダ（２４バイト）およびプリアンブル（１０マイクロ）が含まれていないことが注目されるべきである。これは、１５３．６Ｋｂｐｓにおいて２．５ミリ秒、５００Ｋｂｐｓにおいて０．７７ミリ秒を表す。
【００６５】
ノードは、同じ時間リファレンスを持つ必要がないことに注目されるべきである。例えば、ノードＡ２０２が、ＲＴＲパケットを含む予約テーブルを、ノードＢ２０４に送る場合、その予約テーブルに含まれる持続時間値は、ノードＡ２０２における第１のＲＴＲビットの送信時間に関連している。伝播時間が無視できる（例えば、１ミリ秒未満）と仮定すると、この時間は、ノードＢ２０４における第１のビットの受信時間に実質的に近い。おのおののリンクは、自身の基準時間（例えば２０ミリ秒）を持つべきである。ネットワークは、リンク近傍を通って接続されているので、クロック・ドリフトは、予約期間が更新されるごとに、数マイクロ秒超えるはずがない。
【００６６】
図４は、開示された実施形態にしたがった無線デバイス４００を例示する。無線デバイス４００は、ソース・デバイス、宛先デバイス、あるいは、通信経路に沿った中間デバイスまたはノードでありうるが、１つの特定の機能に限定されないことが注目されるべきである。すなわち、この通信経路に沿って、無線デバイスは、実質的に同時に、複数の機能を実行することができる。
【００６７】
無線デバイス４００は、通信（例えば、音声、データ、テキスト、画像、ビデオ等）、ＲＣパケット、およびＲＴＲパケットを送信するように構成された送信機４０２と、受信するように構成された受信機４０４とを含む。そのような送信、受信、あるいは両方は、通信ネットワークにおいて生じるトラフィックに依存して、別々の時間、あるいは実質的に同時に起こりうる。
【００６８】
オブザーバ４０６は、近隣デバイスのトラフィックを観察または監視するように構成されうる。例えば、近隣デバイスは、ＲＣパケット、ＲＴＲパケット、またはこれら両方のパケットを、送信、受信、または送信と受信との両方を行うことができる。オブザーバ４０６は、オブサーバ４０６によって理解される共通のコードを用いて送信されるパケットおよびトラフィックを観察することができる。そのようなパケットは、近隣デバイス、近隣デバイス間の通信のスケジューリング、あるいは、ネットワーク内の通信をスケジュールするために無線デバイス４００によって利用されうるその他の情報に関連する予約テーブルを含めることができる。
【００６９】
無線デバイス４００にはさらに、ＮＡＶの拡張版でありうるリソース予約テーブル４０８が含まれる。予約テーブル４０８は、アクティブ（例えば、受信中、送信中等）である近隣ノードに関連する情報を用いて、無線デバイス４００を符合化することができる。そのような情報は、スケジュール（例えば、送信の時間スロット）、干渉マージンＭ（ｊ）、送信電力、経路喪失、および、近隣ノードのスケジューリングおよびローカルなトポロジに関連する情報を予約テーブル４００が持つことを可能にするその他の情報、を含むことができる。
【００７０】
無線デバイス４００に含まれるスケジューラ４１０は、受信したＲＴＲパケットに含まれる情報に部分的に基づいてスケジューリングを決定するように構成されうる。そのような情報は、近隣デバイスのスケジューリングを含むことができる。スケジューラ４１０はさらに、利用可能なスケジュールを分析し、かつ、通信経路における対象リンクのための最も早い通信を選択するように構成されうる。許可制御ポリシー４１２は、選択されたスケジュールが、基準を満足しているか、あるいは実現可能であるかを判定するために構成されうる。リンクのスケジュールまたは実現不可能であることは、送信４０２を介して送信ノードへ通信されうる。メッセージまたはパケットが近隣デバイスへ送信される前に、情報をメッセージ、パケット、またはメッセージとパケットの両方に設定または追加することが可能なコンフィギュラ４１４が含まれうる。
【００７１】
ＲＴＲパケットは、コール・セットアップ・パケットであると考えられ、正しく受信されねばならない。したがって、ＲＴＲの送信は、それがあたかもＤＡＴＡパケットであるかのようにスケジュールされうる。これが可能でない場合、ＲＴＲは、たとえ進行中の通信（例えば、音声通信）に干渉を引き起こしても、送られうる。幾つかの実施形態では、送信前のレート情報の欠如、および、ＲＴＲパケットのサイズによって、高度なメカニズムが必要でありうる。幾つかの実施形態では、ノードは、経路における次のホップを予約するために、その受信機が自身のＲＴＲパケットを送ることをパッシブに確認することができよう。しかしながら、ＲＴＲパケットが得る能力が確認されるべきである。
【００７２】
ＲＣは、小さなパケットであり、ＲＣ送信前に、リンクによってサポートされているレートが知られているので、高度なメカニズムによって取り扱うことができる。したがって、ＲＣは、予約を確認した同じスロットで送信されうる。例えば、ノードＢがノードＡのＲＴＲに対して、例えば０ミリ秒から５ミリ秒の間で、ノードＡとノードＢとの間のデータ送信を可能にする予約エントリを有するＲＣパケットをもって応答した場合、ＲＣがこのスロットで送信されうる。ＲＣサイズがＤＡＴＡパケット・サイズ未満である場合、これは可能である。
【００７３】
メモリ４１６は、無線デバイス４００と動作可能に接続されうる。メモリ４１６は、無線デバイスのスケジュールと予約テーブル、近隣デバイスのスケジュールまたは複数の予約テーブル、あるいは、通信ネットワーク内のデバイスおよびトラフィックに関するその他の情報に関する情報を格納することができる。プロセッサ４１８は、通信をスケジューリングすることに関連する情報の分析を容易にするスケジューラ４１０（および／またはメモリ４１６）と動作可能に接続されうる。プロセッサ４１８は、受信機４０４またはスケジューラ４１０によって受信される情報の分析および／または生成に特化されたプロセッサ、無線デバイス４００の１または複数の構成要素を制御するプロセッサ、および／または、受信機４０４によって受信された情報の分析および生成と、無線デバイス４００の１または複数の構成要素の制御との両方を行うプロセッサでありうる。
【００７４】
メモリ４１６は、ＡＣＫ／ＮＡＣＫプロトコルにしたがってアクノレッジメントを生成することと、干渉を低減することと、通信をスケジュールすることと、ソース・デバイスと宛先デバイスとの間の通信を制御する動作を講じることとに関連するプロトコルを格納し、もって、無線デバイス４００が、格納したプロトコルおよび／またはアルゴリズムを用いて、本明細書で記載したように、無線ネットワークにおける向上された通信を達成できるようにする。本明細書で記載したようなデータ格納（例えば、メモリ）構成要素は、揮発性メモリまたは不揮発性メモリの何れであってもよいか、あるいは、揮発性メモリと不揮発性メモリとの両方を含むことができることが認識されるべきである。限定ではなく一例として、不揮発性メモリは、読取専用メモリ（ＲＯＭ）、プログラマブルＲＯＭ（ＰＲＯＭ）、ＥＰＲＯＭ（ＥＰＲＯＭ）、ＥＥＲＯＭ（ＥＥＰＲＯＭ）、あるいはフラッシュ・メモリを含むことができる。揮発性メモリは、ランダム・アクセス・メモリ（ＲＡＭ）を含むことができる。それは、外部キャッシュ・メモリの役割をする。限定ではなく一例として、ＲＡＭは、シンクロナスＲＡＭ（ＤＲＡＭ）、ダイナミックＲＡＭ（ＤＲＡＭ）、シンクロナスＤＲＡＭ（ＳＤＲＡＭ）、ダブル・データ・レートＳＤＲＡＭ（ＤＤＲ ＳＤＲＡＭ）、エンハンストＳＤＲＡＭ（ＥＳＤＲＡＭ）、Ｓｙｎｃｈｌｉｎｋ ＤＲＡＭ（ＳＬＤＲＡＭ）、およびダイレクト・ラムバスＲＡＭ（ＤＲＲＡＭ（登録商標））のような多くの形式で利用可能である。開示された実施形態のメモリ４１６は、限定されることなく、これらおよびその他の適切なタイプのメモリを含むことが意図される。
【００７５】
無線デバイス４００はさらに、適切な無線通信プロトコル（例えば、ＯＦＤＭ、ＯＦＤＭＡ、ＣＤＭＡ、ＴＤＭＡ、ＧＳＭ（登録商標）、ＨＳＤＰＡ等）にしたがって信号を変調および／または符合化することができる。これら信号は、その後、宛先デバイスへ送信されうる。エンコーダは、アナログ波形をデジタル信号に変換する音声アナライザを利用するボイス・コーダ（ボコーダ）であるか、あるいは、別のタイプのエンコーダでありうる。
【００７６】
無線デバイス４００にはさらに、処理のために、受信した信号および／またはその中の信号を復号することができるデコーダ要素（図示せず）でありうる。データ・パケットの復号が成功すると、アクノレッジメント（ＡＣＫ）要素（図示せず）が、データ・パケットの正しい復号を示すアクノレッジメントを生成することができる。これは、（送信機４０２によって）ソース・デバイスへ送られ、このデータが受信され復号されたので、再送信する必要がないことがソース・デバイスへ通知される。
【００７７】
図５は、開示された実施形態に従った予約更新スケジュール５００を例示する。予約セッションの経路は、モビリティ、チャネル挙動、ノード失敗等を含む様々な要因によるＱｏＳ違反を被る。したがって、効率的なリソース・リリース・メカニズムは、予約済みの既存の経路が使用されなくなった場合に、おのおののノードにおいて、予約されたリソースを解放することができる。さらに、端末または無線デバイスにおいて、もはや古くなった予約テーブルが、削除されるべきである。予約更新メカニズムが適用され、これによって、予約要求が、予め定めた間隔で、あるいは、要求があった場合に更新される。ノードが、予め定めた間隔後に、セッションのための新たな予約更新パケットを受信していなのであれば、その予約に対応する情報は、解放されたか、あるいは除去されたものと考えられる。
【００７８】
おのおのの予約エントリは、有効性の持続時間を持っており、この持続時間が経過すると、予約テーブルから除去される。ＲＣ更新（ＲＣアップデート）パケットは、例えば２０ミリ秒またはその他の間隔であるＮＲＣ期間ごとに一度送られる。この間隔は、新たなリンクが、どれくらい頻繁にネットワークに入るかに依存しうる。早期の終了期間（例えば、データが正しく送信された後、スケジュールされた時間間隔における残り時間）は、ＲＣ更新のために利用することができる。そのようなやり方で、リンクが早期に終了すると、リソースが解放され、スケジュール・スロットとなる。これは、進行中の送信との干渉の発生を緩和する。
【００７９】
ＲＣ更新期間ＮＲＣは、５０２に例示されている。これは、新たなＲＣ５０４が利用可能になるのとほとんど同時に始まる予め定めた間隔でありうる。予め定めた間隔５０６（例えば、周期的なＲＣ更新タイマ）が終了すると、ノードは、第１の利用可能なフリー・スロット５１０においてスケジュールされるべきＲＣ更新５０８を送信する準備ができる。５１２に示すように、実質的に同時にタイマがリセットされる。
【００８０】
リンクが早期に終了すると、送信機は、ＲＣ更新パケットを送信するための十分な時間があるかどうかを判定する。ＲＣ更新は、高レートで送られるので、時間は、利用可能でありうる。その後、現在の時間が、例えば２０ミリ秒のように、ＲＣ更新タイマ有効期間の予め定めたマージン内である場合には、２次チェックが実行される。これが真である場合、ＲＣ更新が、早期終了時間で送られ、タイマがリセットされる。ランダムなディザが、更新期間に追加され、ＲＣ更新が少ない潜在的な干渉物がないことを緩和することができる。潜在的な干渉物は、例えば、ＲＣ更新が送られ、ランダムなディザが、そのような干渉物にＲＣ更新を提供することを助ける場合にビジーである。
【００８１】
ＲＴＲパケットと同様に、ＲＣアップデート（ＲＣ更新）のオーバヘッドが計算されうる。ＲＣアップデート（ＲＣ更新）の場合、ＲＣアップデート（ＲＣ更新）パケットは、早期終了領域に適合され、小さくなくてはならない。ＲＣアップデート（ＲＣ更新）は、エントリ毎に以下のフィールドを含まねばならない。約６バイトである宛先フィールド。ＲＣアップデート（ＲＣ更新）は、ソースがノードであるリンクに関する情報を提供するので、ソース・アドレスは必要ではない。約２バイトである開始時間および終了時間が含まれねばならない。約２バイトである送信機電力および干渉マージンも提供されねばならない。
【００８２】
各エントリについて以下の情報も含まれねばならない。約６バイトである送信元アドレス。約６バイトである受信側アドレス（ＭａｃＤｅｓ）。パケット・タイプを含む約１バイトのフィールドと、エントリ数を含む約１バイトのフィールド。従って、４つのエントリを持つノードのＲＣアップデート（ＲＣ更新）サイズは、５４バイト（１４＋（４＊１０））である。これは、ＰＨＹヘッダ（約２４バイト）およびプリアンブル（約１０マイクロ）を含んでいない。ＲＣアップデート（ＲＣ更新）レートは、約１Ｍｂｐｓであり、０．６２５ミリ秒のオーバヘッドを表すＲＲＣであるように設定される。
【００８３】
図示され記述された典型的なシステムを考慮すると、開示された主題にしたがって実施される方法は、図６乃至図９のフロー・チャートを参照してより良く理解されるだろう。説明を簡単にする目的のために、これら方法は、連続したブロックとして示され記述されているが、特許請求された主題は、これらブロックの数または順序によって制限されず、幾つかのブロックが、本明細書で示され説明されたものとは、異なる順序で、および／または、他のブロックと同時に生じうることが理解され認識されるべきである。さらに、後に示す方法を実施するために、例示された全てのブロックが必要とされる訳ではない。これらブロックに関連付けられた機能は、ソフトウェア、ハードウェア、これらの組み合わせ、あるいは、その他任意の適切な手段（例えば、デバイス、システム、プロセッサ、構成要素等）によって実施されうることが理解されるべきである。さらに、以下に示す開示および本明細書全体にわたって開示された方法は、そのような方法を様々なデバイスへ伝送および転送することを容易にするために、製造物品に格納されることが可能であることが認識されるべきである。当業者であれば、方法は、例えば状態図のような相互関連した状態やイベントのシリーズとしても表すことができることを理解し認識するだろう。
【００８４】
図６は、ＵＷＢアド・ホック・ネットワークにおいてＱｏＳ音声コールを確立する方法６００を例示する。方法６００は、宛先デバイスへの経路が突き止められる６０２で始まる。この経路は、ソース・デバイス（例えば、無線端末）と、意図されている通信の受取人（例えば、無線端末または宛先デバイス）との間の通信経路である。選択された経路は、ソース・デバイスと宛先デバイスとの間のセッションを確立するための十分なリソース（例えば、ルーティング・プロトコルによって発見された粗い推定値）を持っている。このデバイス間の経路は、共通ノードまたは中間デバイス（１または複数）を含むことができる。６０４では、予約要求（ＲＴＲ：Request-to-Reserve）制御パケットが、中間デバイスへ送られる。ＲＴＲパケットは、ソース・デバイスの予約テーブルを含むことができる。
【００８５】
予約テーブルは最初は空である。したがって、ソース・デバイスの観点から、ソース・デバイスから中間デバイスへの送信について制約はない。
【００８６】
６０６では、ＲＴＲ制御パケットに対する応答が、中間デバイスから、予約確認（ＲＣ：reservation confirmation）パケットの形態で受信される。このＲＣパケットは、中間デバイスを介したスケジューリングを提供する。このＲＣパケットに応答して、６０８では、ＲＣパケットが中間デバイスへ送られ、ソース・デバイスから中間デバイスへのスケジュールがアナウンスされる。そのようなＲＣパケットは、ソース・デバイスの干渉マージンＭと、受信および／または送信スケジュールと、ソース・デバイスの電力とを含みうる。
【００８７】
図７は、超広帯域アド・ホック通信ネットワークにおいて通信をスケジューリングする方法７００を例示する。無線デバイスからのＲＴＲ制御パケットが、中間デバイスにおいて受信されると、７０２において、方法７００が始まる。このパケットは、別のデバイス（例えば、宛先デバイス）との通信を望んでいる無線デバイス（例えば、ソース・デバイス）から受信され、この通信は、中間デバイスとの相互作用を通じて達成される。ＲＴＲパケットは、無線デバイスの予約テーブルを含んでいる。このテーブルは、最初は空であり、つまり、ヌル値しか持っていない。
【００８８】
７０４では、ＲＴＲパケットが調べられ、無線デバイスと中間デバイスとの間のスケジュールが決定される。このスケジュールは、実現可能なスケジュールであり、例えば、ネットワークにおいて実質的に同時に引き起こる他の通信のようなある条件について、許可制御ポリシーが検証される。無線デバイスの予約テーブルと、中間デバイスの予約テーブルとはともに最初は空であるので、条件が満たされる。多くのスケジュールが発見される。そして、７０６では、無線デバイスと中間ノードとの間の通信のための最も早いスケジュールが選択される。最も早いスケジュールを選択するのと実質的に同時に、中間ノードは、その予約テーブルを更新し、７０８において、ＲＴＲパケットを宛先デバイスへ送る。
【００８９】
７１０において、送られたＲＴＲパケットに応答して、宛先デバイスからのＲＣパケットを受信すると、方法７００は継続する。ＲＣパケットは、中間デバイスと宛先デバイスとの間のスケジュールを、中間デバイスに通知する。ＲＣパケットは、共通のコードを用いて送られる。近隣デバイスは、この共通のコードを用いて、パケットを聞いたり、解釈することが可能となる。７１２では、ＲＣパケット（共通のコード）が、無線デバイスへ送られ、無線デバイスと中間デバイスとの間のスケジュールがアナウンスされる。
【００９０】
図８は、超広帯域アド・ホック通信をスケジューリングする方法８００を例示する。方法８００は、ＲＴＲパケットが宛先デバイスにおいて受信される８０２で始まる。ＲＴＲパケットは、ソース・デバイスからの通信が経路付けられる中間デバイスから受信されうる。ＲＴＲパケットは、ソース・デバイスと中間デバイスとの間の通信のための最も早いスケジュールを含む、中間デバイスのための予約テーブルを含んでいる。
【００９１】
８０４に進み、ＲＴＲパケットが調べられ、中間デバイスの予約テーブルと、宛先デバイスの予約テーブルとが検査され、実現可能なスケジュールが決定される。８０６では、ＲＴＲパケットが受信されたことに応答して、予約確認（ＲＣ）パケットが中間デバイスへ送信される。このＲＣパケットは、中間デバイスと宛先デバイスとの間のスケジュールをアナウンスする。ＲＣパケットは、ＲＣパケットに含まれる情報を近隣デバイスが理解するために、共通のコードを用いて送られねばならない。
【００９２】
図９は、近隣デバイス間で交換される情報に部分的に基づいて通信をスケジュールするための方法９００を例示する。この方法９００は、デバイスが、近隣デバイス間の通信を聞くこと９０２で始まる。そのような通信は、共通のコードを用いて送られたＲＣパケットを含むことができる。ＲＣパケットは、例えば、ノード受信の干渉マージン、ノードの送信スケジュールおよび電力、あるいはそれら両方を含むことができる。通信を聞くデバイスは、通信を同時にスケジュールできるか、あるいは、干渉マージンに基づくことなくスケジュールできるかを判定することができる。デバイスは、送信スケジュールおよびノードの電力に基づいて、スケジュールされたセッションから、予期される干渉を決定することができる。９０４では、近隣デバイスのＲＣパケットに含まれる情報を含めるように、中間デバイスの予約テーブルが更新される。
【００９３】
９０６では、１または複数の中間デバイスを介して宛先デバイスへと通信することを望むソース・デバイスから、ＲＴＲパケットが受信される。９０８では、ＲＴＲパケットに含まれる予約テーブルと、中間デバイスの更新された予約テーブルとが分析される。９１０では、そのような分析に部分的に基づいて、実現可能な条件を満足する通信スケジュールが決定される。これら実現可能な条件は、セッションをサポートするための十分な時間スロットがあるか、計算された新たなセッションによって引き起こされた干渉が、既にスケジュールされ進行しているセッションの全ての干渉マージンよりも小さいこと、スケジュールされたセッションが、既にスケジュールされ進行しているセッションからの干渉が存在していても良好に動作していること、および、少なくともＲｍｉｎである最小レートをサポートできることを含む。そのような通信スケジュールは、近隣デバイス間のスケジュールされた通信と、ソース・デバイスと中間デバイスとの間の送信電力が、近隣デバイス間の通信を妨害するかと、に部分的に基づきうる。９１２において、次のデバイス（例えば、中間デバイス、宛先デバイス）に、通信スケジュールが通知されうる。
【００９４】
図１０乃至図１３を参照して、システムが、機能ブロックまたは論理モジュールとして例示される。これらの機能ブロックは、プロセッサ、ソフトウェア、またはこれらの組み合わせ（例えば、ファームウェア）によって実現される機能を表す。システムは、アクセス・ポイント内、またはユーザ・デバイス内に存在することができる。
【００９５】
図１０は、アド・ホック・ネットワークにおいてＱｏＳ通信を確立するシステム１０００を例示する。システム１０００は、宛先デバイスへの経路を決定するための論理モジュール１００２を含む。この経路は、ソース・デバイスで始まり、宛先デバイスが受け取られるまで、この経路に沿ったマルチホップにしたがって進む。第１のデバイスにＲＴＲパケットを伝送する論理モジュール１００４も提供される。この第１のデバイスは、ソース・デバイスと宛先デバイスとの間の経路に沿って位置するデバイス（例えば、無線端末、ノード、基地局）でありうる。ＲＴＲパケットは、スケジュール情報と、アクティブな近隣ノードに関する情報とを含む予約テーブルを含みうる。
【００９６】
システム１０００はまた、ＲＣパケットを受信するための論理モジュール１００６を含む。このＲＣパケットは、ＲＴＲ制御パケットの伝送に応答して受信され、通信スケジュール情報を含む。応答ＲＣパケットを送るための論理モジュール１００８が含まれる。そのような論理モジュール１００８は、ＲＴＲ制御パケットに応答して、受信されたスケジュールを確認するためにＲＣパケットを送信することができる。
【００９７】
幾つかの実施形態にしたがって、近隣デバイス情報を含むリソース予約テーブルを保持したオプションの論理モジュール１０１０が含まれる。そのような論理モジュール１０１０は、更新された情報がアクティブな近隣デバイスから受信された場合、または、新たなスケジューリング情報が利用可能である場合、リソース予約テーブルを自動的に更新することができる。
【００９８】
例えば、装置は、宛先デバイスへの経路を決定するための、論理モジュール１００２でありうる手段と、ＲＴＲパケットを第１のデバイスへ伝送するための、論理モジュール１００４でありうる手段とを含む。ＲＴＲ制御パケットが伝送されることに応答して、スケジュールを備えたＲＣパケットを受信する、論理モジュール１００６でありうる手段と、ＲＣパケットを受信することに応答して、応答ＲＣパケットを送信する、論理モジュール１００８でありうる手段ともまた、装置に含まれうる。
【００９９】
図１１は、アド・ホック通信網ネットワークにおいて通信をスケジューリングするためのシステム１１００を例示する。システム１１００は、ＲＴＲ制御パケットを受信する論理モジュール１１０２を含むことができる。ＲＴＲ制御パケットは、ソース・デバイスと宛先デバイスとの間の経路のための経路情報を含むことができる。論理モジュール１１０４は、経路のための利用可能なスケジュールを分析することができる。また、論理モジュール１１０６は、通信のために最も早いスケジュールを選択することができる。また、システム１１００には、ＲＴＲパケットを宛先デバイスへ伝送するための論理モジュール１１０８が含まれている。ＲＴＲパケットは、最も早いスケジュールに関する情報を含んでなければならない。
【０１００】
幾つかの実施形態に従って、システム１１００はまた、経路に沿って位置している第１の中間デバイスのための第１の予約テーブルと、ソース・デバイスの第２の予約テーブルとに、ＲＴＲパケットを追加するための論理モジュール１１１０をも含む。幾つかの実施形態は、宛先デバイスから第１のＲＣパケットを受信するための論理モジュール１１１２を含む。ＲＣパケットは、通信スケジュールを含んでいる。また、第２のＲＣパケットをソース・デバイスへ送るための論理モジュール１１１４も含まれている。この第２のＲＣパケットは、通信スケジュールを含むことができる。
【０１０１】
例えば、アド・ホック通信ネットワークにおける通信をスケジュールする装置は、ソース・デバイスから宛先デバイスへの経路を含むＲＴＲ制御パケットを受信するための、論理モジュール１１０２でありうる手段を含むことができる。さらには、経路のために利用可能なスケジュールを分析するための、論理モジュール１１０４でありうる手段を含むこともできる。最も早いスケジュールを選択するための、論理モジュール１１０６でありうる手段と、ＲＴＲパケットを宛先モジュールに伝送するための、論理モジュール１１０８でありうる手段ともまた、装置に含まれうる。
【０１０２】
図１２は、アド・ホック通信をスケジューリングするためのシステム１２００を例示する。システム１２００は、ＲＴＲパケットを受信する論理モジュール１２０２と、ネットワーク内でスケジュールされた少なくとも１つの通信と干渉しないスケジュールを決定するための論理モジュール１２０４とを含む。システム１２００はまた、ＲＴＲパケットを受信することに応じて、ＲＣパケットを送信するための論理モジュール１２０６を含むことができる。このＲＣパケットは、スケジュールを含むことができる。幾つかの実施形態によれば、システム１２００は、このスケジュールを用いてルーティング・テーブルを更新するための論理モジュール１２０８を含むことができる。
【０１０３】
例えば、アド・ホック通信をスケジューリングする装置は、ＲＴＲパケットを受信するための、論理モジュール１２０２でありうる手段を含むことができる。装置はまた、スケジュールされた少なくとも１つの通信と干渉しないスケジュールを決定するための、論理モジュール１２０４でありうる手段と、ＲＴＲパケットを受信することに応答して、ＲＣパケットを送信するための、論理モジュール１２０６でありうる手段とを含むこともできる。
【０１０４】
図１３は、マルチホップ・アド・ホック・ネットワークにおいて通信をスケジューリングするシステム１３００を例示する。システム１３００は、近隣デバイス間の通信を聞くための論理モジュール１３０２を含むことができる。その通信は、共通のコード上で送られるＲＣパケットを含むことができる。さらに、通信に含まれる情報を用いてルーティング・テーブルを更新するための論理モジュール１３０４と、予約テーブルを含むＲＴＲパケットを受信するための論理モジュール１３０６とも含まれる。さらに、ルーティング・テーブルを分析するための論理モジュール１３０８と、ルーティング・テーブルに部分的に基づいて通信スケジュールを決定するための論理モジュール１３１０ともまた含まれている。
【０１０５】
幾つかの実施形態にしたがって、システム１３００はさらに、通信スケジュールを含むＲＴＲパケットを送信するための論理モジュール１３１２と、ＲＴＲパケットが送信されたことに応答して、ＲＣパケットを受信するための論理モジュール１３１４とを含む。さらにまた、更新されたＲＣパケットをソース・デバイスへ送信するための論理モジュール１３１６と、ＲＣパケットが送信されたことに応答して、ソース・デバイスからＲＣパケットを受信するための論理モジュール１３１８ともまた含まれうる。
【０１０６】
例えば、装置は、近隣デバイス間で通信されるＲＣパケットを聞くための、論理モジュール１３０２でありうる手段と、ＲＣパケットに含まれる情報を用いて、中間デバイスの予約テーブルを更新するための、論理モジュール１３０４でありうる手段とを含むことができる。第１の中間デバイスにおいて、ソース・デバイスからＲＴＲパケットを受信するための、論理モジュール１３０６でありうる手段もまた含まれうる。このＲＴＲパケットは、ソース・デバイスの予約テーブルを含んでいる。この装置はさらに、更新された予約テーブルと、ソース・デバイスの予約テーブルとを分析するための、論理モジュール１３０８でありうる手段と、分析された予約テーブルに部分的に基づいて、宛先デバイスとソース・デバイスとの間の通信スケジュールを決定するための、論理モジュール１３１０でありうる手段ともまた含みうる。
【０１０７】
図１４に示すように、端末１４００の可能な構成の概念ブロック図が例示されている。当業者によって認識されるように、端末１４００の正確な構成は、具体的な用途および全体的な設計制約に依存して変わりうる。プロセッサ１４０２は、本明細書で開示されたシステムおよび方法を実現することができる。
【０１０８】
端末１４００は、アンテナ１４０６に接続されたフロント・エンド・トランシーバ１４０４を用いて実装されうる。ベース・バンド・プロセッサ１４０８が、トランシーバ１４０４に接続されうる。ベース・バンド・プロセッサ１４０８は、ソフトウェア・ベースのアーキテクチャ、あるいはその他のタイプのアーキテクチャを用いて実現されうる。マイクロプロセッサは、制御および全体的なシステム管理機能を提供するソフトウェア・プログラムを実行させるためのプラットフォームとして利用されうる。デジタル信号プロセッサ（ＤＳＰ）が、組込式の通信ソフトウェア・レイヤとともに実装されうる。このプロセッサは、アプリケーション特有のアルゴリズムを実行して、マイクロプロセッサ上の処理要求を低減することができる。ＤＳＰは、例えば、パイロット信号獲得、時間同期、周波数追跡、スペクトラム拡散処理、変調および復調機能、および順方向誤り訂正のような様々な信号処理機能を提供するために利用されうる。
【０１０９】
端末１４００はまた、ベース・バンド・プロセッサ１４０８に接続された様々なユーザ・インタフェース１４１０を含むことも可能である。ユーザ・インタフェース１４１０は、キーパッド、マウス、タッチ・スクリーン、ディスプレイ、リンガ、バイブレータ、オーディオ・スピーカ、マイクロホン、カメラおよび／またはその他の入力／出力デバイスを含むことができる。
【０１１０】
ベース・バンド・プロセッサ１４０８は、プロセッサ１４０２を備える。ベース・バンド・プロセッサ１４０８のソフトウェア・ベースの実装では、プロセッサ１４０２は、マイクロプロセッサ上で動作するソフトウェア・プログラムでありうる。しかしながら、当業者であれば容易に認識するように、プロセッサ１４０２はこの実施形態には限定されず、本明細書に記載の様々な機能を実行することができる任意のハードウェア構成、ソフトウェア構成、またはこれらの組み合わせを含む当該技術で周知の任意の手段によって実現されうる。プロセッサ１４０２は、データ記憶用のメモリ１４１２に接続されうる。
【０１１１】
本明細書に記載の実施形態は、ハードウェア、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、あるいはこれらの任意の組み合わせによって実現されうることが理解されるべきである。これらシステムおよび／または方法が、ソフトウェア、ファームウェア、ミドルウェアまたマクロコード、プログラム・コードまたはコード・セグメントで実現される場合、例えば記憶素子のような機械読取可能媒体内に格納されうる。コード・セグメントは、手順、関数、サブプログラム、プログラム、ルーチン、サブルーチン、モジュール、ソフトウェア・パッケージ、クラス、あるいは命令群の任意の組み合わせ、データ構造、またはプログラム・ステートメントを示すことができる。コード・セグメントは、情報、データ、引数、パラメータ、あるいは記憶内容を渡したり、および／または、受信することによって、別のコード・セグメントまたはハードウェア回路に接続されうる。情報、引数、パラメータ、データ等は、メモリ共有、メッセージ引渡し、トークン引渡し、ネットワーク送信等を含む任意の適切な手段を用いて引渡し、転送、あるいは送信がなされうる。
【０１１２】
ソフトウェアで実現する場合、本明細書に記載の技術は、本明細書に記載の機能を実行するモジュール（例えば、手順、関数等）を用いて実現されうる。これらソフトウェア・コードは、メモリ・ユニット内に格納され、プロセッサによって実行されうる。メモリ・ユニットは、プロセッサ内に実装されるか、あるいはプロセッサの外部に実装される。プロセッサの外部に実装された場合、当該技術分野で周知の様々な手段によって、プロセッサに通信可能に接続されうる。
【０１１３】
上述したものは、１または複数の実施形態の例を含む。もちろん、上述した実施形態を記述する構成要素または方法の、考えられる全ての組み合わせを記述することは不可能であるが、当業者であれば、様々な実施形態のさらなる多くの組み合わせおよび置き換えが可能であることを認識するこができる。したがって、記述された実施形態は、特許請求の範囲の精神およびスコープ内にあるそのような変更、修正、および変形例の全てを含むものと意図される。さらに、用語「含む」が、詳細な説明または特許請求の範囲の何れか一方において用いられている限りにおいては、そのような用語は、用語「備える」が、特許請求の範囲において適用されている場合、「備える」と解釈されるのと同様に、包括的であると意図される。
【技術分野】
【０００１】
以下の説明は、一般に、無線通信に関し、さらに詳しくは、超広帯域無線通信ネットワークおよびアド・ホック無線通信ネットワークに関する。
【背景技術】
【０００２】
無線ネットワーキング・システムは、世界中の多くの人々が通信する普及手段になった。無線通信デバイスは、カスタマ・ニーズを満足するためにより小型かつ強力になり、向上された可搬性および利便性を含んでいる。ユーザは、例えば、セルラ電話、携帯情報端末等のような無線通信デバイスのための多くの用途を発見した。そして、そのようなユーザは、信頼できるサービスと拡大された有効範囲領域とを要求している。
【０００３】
無線通信ネットワークは一般に、ユーザがどこに（建物の内部または外部に）位置しているか、および、ユーザが静止しているか移動しているか（例えば、車の中や歩行中）に関わらず、情報を通信するために利用される。一般に、無線通信ネットワークは、基地局またはアクセス・ポイントと通信するモバイル・デバイスを介して確立される。アクセス・ポイントは、地理的地域すなわちセルをカバーする。そして、モバイル・デバイスは、操作されている間、これら地理的なセル中に、およびセル外に移動しうる。途切れのない通信を達成するために、モバイル・デバイスは、モバイル・デバイスが入ったセルのリソースが割り当てられ、モバイル・デバイスが出たセルのリソースが解除される。
【０００４】
ネットワークは、アクセス・ポイントを利用せずに、単独でピア・ツー・ピア通信を利用して構築されることができる。更なる実施形態では、ネットワークは、アクセス・ポイント（インフラストラクチャ・モード）およびピア・ツー・ピア通信の両方を含むことができる。インフラストラクチャのこれらのタイプは、アド・ホック・ネットワークあるいは独立基本サービス・セット（ＩＢＳＳ）と呼ばれる。アド・ホック・ネットワークは自己形成することができる。それによって、モバイル・デバイス（あるいはアクセス・ポイント）が他のモバイル・デバイスから通信を受信すると、他のモバイル・デバイスがこのネットワークに加えられる。モバイル・デバイスがその領域を出ると、モバイル・デバイスは、そのネットワークから動的に除外される。したがって、ネットワークのトポグラフィは、絶えず変わりうる。マルチホップ・トポロジでは、送信者から受信者へと直接的ではなく、多くのホップまたはセグメントを介して送信が転送される。
【０００５】
例えば超広帯域（ＵＷＢ）アド・ホック・ネットワークのようなネットワークにおける無線通信の効率および性能に、様々な要因が影響を与えうる。例えば、有効範囲領域で生じる多くのトラフィックまたはデータ通信は、データ送信時間を減らし、干渉を引き起こす。したがって、通信のサービス品質（ＱｏＳ）は、ネットワークにおいて実質的に同時に生じる他の通信によって影響を受ける。例えば、無線ＬＡＮで用いられるCarrier Sense Multiple Access with Collision Avoidance (CSMA/CA)（ＩＥＥＥ ８０２．１１）のような除外ベース（exclusion-based）のスキームでは、データ・スループットおよび同時送信の数は、ネットワーク内に干渉がある場合には、低減されうる。
【０００６】
他の欠点同様、上述した欠点を克服するために必要なものは、ネットワーク内の他の通信によって引き起こされる干渉を低減しながら、アド・ホック・ネットワークにおけるＱｏＳ通信を確立するための技術である。それは、極めて多くの同時データ伝送のスケジューリングを可能にし、ネットワークのデータ・スループットを増加させる。
【発明の概要】
【０００７】
下記は、開示された実施形態の幾つかの局面の基本的な理解を提供するために、単純化された概要を示す。この概要は広範囲な概観ではなく、主要な要素または決定的な要素を特定するものでも、そのような実施形態の範囲を線引きすることも意図されていない。その唯一の目的は、後に示されるより詳細な記述に対する前置きとして、示される実施形態の幾つかの局面を、簡略化した形式で示すことである。
【０００８】
１または複数の実施形態およびそれに対応する開示に従って、予約ベースの媒体アクセス制御（ＭＡＣ）プロトコルが、ソースから宛先への経路に沿ってスケジュールされたリソースを持つＵＷＢアド・ホック・ネットワークと関連して様々な局面が記述される。
【０００９】
幾つかの実施形態によれば、アド・ホック・ネットワークにおいてサービス品質（ＱｏＳ）通信を確立する方法がある。この方法は、宛先デバイスへの経路を突き止めることと、この経路に沿って特定される少なくとも第１の中間デバイスへと予約要求（ＲＴＲ：Request-to-Reserve）制御パケットを送ることとを含む。ＲＴＲパケットに応答して、この少なくとも第１の中間デバイスから、第１の予約確認（ＲＣ）パケットが受信される。この第１のＲＣパケットは、スケジュールを含んでいる。この第１のＲＣパケットに応答して、この少なくとも第１の中間デバイスへと第２のＲＣパケットが送信される。
【００１０】
幾つかの実施形態に従って、アド・ホック・ネットワークにおいてＱｏＳ通信を確立する装置がある。この装置は、宛先デバイスへの経路に含まれている第１のデバイスへとＲＴＲ制御パケットを送る送信機を含む。この装置はまた、ＲＴＲ制御パケットに応答して第１のＲＣパケットを受信する受信機を含む。この送信機は、第１のＲＣパケットに応答して、第１のデバイスへと、第２のＲＣパケットを送る。
【００１１】
幾つかの実施形態によれば、アド・ホック・ネットワークにおいてＱｏＳ通信を確立する装置がある。この装置は、宛先デバイスへの経路を決定する手段と、予約テーブルを備えるＲＴＲパケットを第１のデバイスへ伝送する手段とを含む。さらにこの装置には、伝送されたＲＴＲ制御パケットに応答して、スケジュールを備えたＲＣパケットを受信する手段と、ＲＣパケットを受信することに応答して、返信ＲＣパケットを送る手段とが含まれる。この返答ＲＣパケットは、スケジュールを確認する。
【００１２】
幾つかの実施形態によれば、アド・ホック・ネットワークにおいてＱｏＳ通信を確立する方法を組み込んだコンピュータ読取可能媒体がある。この方法は、ソース・デバイスと宛先デバイスとの間の通信経路を決定することと、この通信経路に沿って位置している第１のデバイスへと、ＲＴＲパケットを送信することとを含む。このＲＴＲパケットが送信されたことに応答して、この第１のデバイスから、第１のＲＣパケットが受信され、第２のＲＣパケットが、第１のデバイスへ送信され、第１のＲＣパケットで情報が受信されたことが確認される。
【００１３】
幾つかの実施形態にしたがって、アド・ホック・ネットワークにおいてＱｏＳ通信を確立するプロセッサがある。このプロセッサは、ソース・デバイスと宛先デバイスとの間の通信経路を決定し、この通信経路に位置する第１のデバイスへとＲＴＲパケットを伝送するように構成される。このＲＴＲパケットは、ソース・デバイスの予約テーブルを含む。このプロセッサはさらに、ＲＴＲパケットに応答してＲＣパケットを受信し、受信したＲＣパケットにおけるスケジュールを確認する返信ＲＣパケットを送るように構成される。このＲＣパケットは、ソース・デバイスのためのスケジュールを含んでいる。
【００１４】
幾つかの実施形態にしたがって、アド・ホック通信ネットワークにおいて通信をスケジューリングする方法がある。この方法は、少なくとも第１の無線デバイスからＲＴＲ制御パケットを受信することと、少なくとも第１の無線デバイスから宛先デバイスへのスケジュールを決定することとを含む。少なくとも第１の無線デバイスと宛先デバイスとの間の通信のための最も早いスケジュールが、許可制御ポリシーに基づいて選択され、ＲＴＲパケットが宛先デバイスへ送られる。このＲＴＲパケットに応答して、宛先デバイスからＲＣパケットが受信され、このＲＣパケットは、少なくとも第１の無線デバイスへと送信される。このＲＣパケットは、通信スケジュールを含んでいる。
【００１５】
幾つかの実施形態にしたがって、アド・ホック通信ネットワークにおいて通信をスケジュールする装置がある。この装置は、少なくとも第１のノードから、ＲＴＲ制御パケットを受信する受信機と、利用可能なスケジュールを分析し、許可制御ポリシーに基づいて、ソース・ノードと宛先ノードとの間の通信のための最も早いスケジュールを選択するスケジューラとを含む。さらにまた、宛先ノードへＲＴＲパケットを送信する送信機が含まれる。ＲＴＲパケットは、最も早い通信スケジュールを含んでいる。
【００１６】
幾つかの実施形態にしたがって、アド・ホック通信ネットワークにおいて通信をスケジューリングする装置がある。この装置は、ソース・デバイスから宛先デバイスへの経路を含むＲＴＲ制御パケットを受信する手段と、この経路のために利用可能なスケジュールを分析する手段とを含む。さらにまたこの装置には、最も早いスケジュールを選択する手段と、ＲＴＲパケットを宛先デバイスへ伝送する手段とが含まれる。このＲＴＲパケットは、最も早いスケジュールを含んでいる。
【００１７】
幾つかの実施形態によれば、超広帯域アド・ホック通信ネットワークにおいて通信をスケジューリングする方法を組み込んだコンピュータ読取可能媒体がある。この方法は、ソース・デバイスから宛先デバイスへの経路を含むＲＴＲ制御パケットを受信することと、この経路のために利用可能なスケジュールを分析することとを含む。最も早いスケジュールが選択され、宛先デバイスへＲＴＲパケットが伝送される。このＲＴＲパケットは、最も早いスケジュールを含んでいる。
【００１８】
幾つかの実施形態によれば、アド・ホック通信ネットワークにおいて通信をスケジューリングするプロセッサがある。このプロセッサは、少なくとも第１の無線デバイスから、ＲＴＲ制御パケットを受信し、許可制御ポリシーに基づいて、少なくとも第１の無線デバイスから宛先デバイスへのスケジュールを決定するように構成される。このプロセッサはさらに、少なくとも第１の無線デバイスと宛先デバイスとの間の通信のための最も早いスケジュールを選択するように構成される。宛先デバイスにはＲＴＲパケットが送られ、このＲＴＲパケットに応答して、宛先デバイスからのＲＣパケットが受信される。このプロセッサはさらに、少なくとも第１の無線デバイスへとＲＣパケットを送信するように構成される。このＲＣパケットは、通信スケジュールを含んでいる。
【００１９】
幾つかの実施形態にしたがって、アド・ホック通信をスケジューリングする方法がある。この方法は、少なくとも第１のデバイスからＲＴＲパケットを受信することと、許可制御ポリシーを利用する通信スケジュールに部分的に基づいて、実現可能なスケジュールを決定することとを含む。ＲＴＲパケットは、通信スケジュールを含んでいる。この実現可能なスケジュールを含むＲＣパケットは、少なくとも第１のデバイスへ送信される。
【００２０】
幾つかの実施形態にしたがって、超広帯域アド・ホック通信をスケジューリングする装置がある。この装置は、少なくとも第１のデバイスからＲＴＲパケットを受信する受信機と、ＲＴＲパケットに含まれる情報に部分的に基づいてスケジュールを決定するスケジューラとを含む。さらに、この装置には、ＲＴＲパケットを受信することに応答してＲＣパケットを送信する送信機が含まれている。このＲＣパケットは、スケジュールのうちの１つ、またはスケジュールが実現不可能であることを含んでいる。
【００２１】
幾つかの実施形態によれば、超広帯域アド・ホック通信をスケジューリングする装置がある。この装置は、ＲＴＲパケットを受信する手段と、スケジュールされた少なくとも１つの通信と干渉しないスケジュールを決定する手段とを含む。さらに、この装置には、ＲＴＲパケットを受信することに応答して、スケジュールを含むＲＣパケットを送る手段が含まれる。
【００２２】
幾つかの実施形態によれば、アド・ホック通信をスケジューリングする方法を組み込んだコンピュータ読取可能媒体がある。この方法は、少なくとも第１のデバイスからＲＴＲパケットを受信することと、ＲＴＲパケットに含まれる情報に部分的に基づいてスケジュールを決定することとを含む。ＲＴＲパケットを受信することに応答して、スケジュールのうちの１つ、このスケジュールが実現不可能であることを含むＲＣパケットが送信される。
【００２３】
幾つかの実施形態にしたがって、アド・ホック通信をスケジューリングするためのプロセッサがある。このプロセッサは、ＲＴＲパケットを受信し、スケジューリングされた少なくとも１つの通信と干渉しないスケジュールを決定するように構成される。このプロセッサはさらに、ＲＴＲパケットを受信することに応答して、スケジュールを含むＲＣパケットを送るように構成される。
【００２４】
幾つかの実施形態にしたがって、マルチホップ・アド・ホック・ネットワークにおいて通信をスケジューリングする方法がある。この方法は、近隣デバイス間で通信されるＲＣパケットを探索することと、ＲＣパケットに含まれる情報を用いて、中間デバイスの予約テーブルを更新することとを含む。この方法はさらに、ソース・デバイスからのＲＴＲパケットを、第１の中間デバイスにおいて受信することを含む。このＲＴＲパケットは、ソース・デバイスの予約テーブルを含んでいる。この更新された予約テーブルと、ソース・デバイス予約テーブルとが分析され、分析された予約テーブルに部分的に基づいて、ソース・デバイスと宛先デバイスとの間の通信スケジュールが決定される。
【００２５】
幾つかの実施形態にしたがって、マルチホップ・アド・ホック・ネットワークにおいて通信をスケジューリングする装置がある。この装置は、アクティブな近隣ノード間で生じている通信を監視するオブサーバと、監視された通信に含まれる情報を用いて、リソース予約テーブルを更新するコンフィギャラとを含む。さらにこの装置には、ソース・デバイスからＲＴＲパケットを受信する受信機が含まれている。このＲＴＲパケットは、ソース・デバイスと宛先デバイスとの間の経路を含んでいる。ソース・デバイスから宛先デバイスまでの経路に沿った通信をスケジューリングするスケジューラも含まれている。
【００２６】
幾つかの実施形態によれば、マルチホップ・アド・ホック・ネットワークにおいて通信をスケジューリングする装置がある。この装置は、近隣デバイス間で通信されるＲＣパケットを探索する手段と、ＲＣパケットに含まれる情報を用いて、中間デバイスの予約テーブルを更新する手段とを含む。さらにはソース・デバイスからのＲＴＲパケットを、第１の中間デバイスにおいて受信する手段と、更新された予約テーブルと、ソース・デバイス予約テーブルとを分析する手段とが含まれる。ＲＴＲパケットは、ソース・デバイスの予約テーブルを含んでいる。この装置には、分析された予約テーブルに部分的に基づいて、ソース・デバイスと宛先デバイスとの間の通信スケジュールを決定する手段も含まれる。
【００２７】
幾つかの実施形態にしたがって、マルチホップ・アド・ホック・ネットワークにおいて通信をスケジューリングする方法を組み込んだコンピュータ読取可能媒体がある。この方法は、アクティブな近隣ノード間で生じる通信を監視することと、監視された通信に含まれる情報を用いて、リソース予約テーブルを更新することとを含む。ソース・デバイスからは、ソース・デバイスと宛先デバイスとの間の経路を含むＲＴＲパケットが受信される。通信は、ソース・デバイスから宛先デバイスへの経路に沿ってスケジューリングされる。
【００２８】
幾つかの実施形態にしたがって、マルチホップ・アド・ホック・ネットワークにおいて通信をスケジューリングするプロセッサがある。このプロセッサは、近隣デバイス間で通信されているＲＣパケットを探索し、ＲＣパケットに含まれる情報を用いて、中間デバイスの予約テーブルを更新するように構成される。このプロセッサはさらに、ソース・デバイスからのＲＴＲパケットを第１の中間デバイスにおいて受信し、更新された予約テーブルと、ソース・デバイス予約テーブルとを分析し、分析された予約テーブルに部分的に基づいて、ソース・デバイスと宛先デバイスとの間の通信スケジュールを決定するように構成される。このＲＴＲパケットは、ソース・デバイスの予約テーブルを含んでいる。
【００２９】
上述した目的および関連する目的を達成するために、１または複数の実施形態は、以下に完全に記載され、特許請求の範囲で述べられている特徴を備える。以下の記載および添付図面は、ある例示的な局面を詳細に述べており、実施形態の原理が適用される様々な方式のうちのごく少数を示しているにすぎない。その他の利点および斬新な特徴が、これら図面と連携して考慮された場合に以下の詳細説明から明らかになるだろう。そして、開示された実施形態は、そのような全ての局面およびそれらの等化物を含むことが意図される。
【図面の簡単な説明】
【００３０】
【図１】図１は、マルチホップ・アド・ホック無線ネットワークにおいて通信をルーティングすることを例示する。
【図２】図２は、ＵＷＢアド・ホック無線ネットワーク内でスケジューリングすることを例示する。
【図３】図３は、ＵＷＢ環境における予約ベースのＭＡＣプロトコルのための典型的なスケジュールを例示する。
【図４】図４は、開示された実施形態にしたがった無線デバイスを例示する。
【図５】図５は、開示された実施形態にしたがった予約更新タイムラインを例示する。
【図６】図６は、ＵＷＢアド・ホック・ネットワークにおけるＱｏＳ音声コールの確立のための方法論を例示する。
【図７】図７は、超広帯域アド・ホック通信ネットワークにおいて通信をスケジューリングするための方法論を例示する。
【図８】図８は、超広帯域アド・ホック通信をスケジューリングするための方法論を例示する。
【図９】図９は、近隣デバイス間で交換された情報に部分的に基づいて通信をスケジューリングする方法論を例示する。
【図１０】図１０は、ＵＷＢアド・ホック・ネットワークにおいてＱｏＳ通信を確立するためのシステムを例示する。
【図１１】図１１は、超広帯域アド・ホック通信ネットワークにおいて通信をスケジューリングするためのシステムを例示する。
【図１２】図１２は、超広帯域アド・ホック通信スケジューリングのためのシステムを例示する。
【図１３】図１３は、マルチホップ・アド・ホック・ネットワークにおいて通信をスケジューリングするためのシステムを例示する。
【図１４】図１４は、端末の可能な構成概念を示すブロック図を例示する。
【発明を実施するための形態】
【００３１】
様々な実施形態が、図面を参照して記載される。以下の説明では、説明の目的で、１または複数の局面の完全な理解を提供するために、多くの具体的な詳細が述べられる。しかしながら、そのような実施形態は、これら具体的詳細なしで実現されうることが明白である。他の事例では、周知の構成およびデバイスが、これらの実施形態の記載を容易にするために、ブロック図形式で示される。
【００３２】
本願で用いられるように、用語「構成要素」、「モジュール」、「システム」等は、ハードウェア、ソフトウェア、ハードウェアとソフトウェアとの組み合わせ、ソフトウェア、実行中のソフトウェアのうちの何れかであるコンピュータ関連エンティティを称することが意図される。例えば、構成要素は、限定される訳ではないが、プロセッサ上で実行しているプロセス、プロセッサ、オブジェクト、実行形式、実行スレッド、プログラム、および／または、コンピュータでありうる。実例として、計算デバイス上で動作するアプリケーションと、計算デバイスとの両方が、構成要素になりえる。１または複数の構成要素は、プロセスおよび／または実行スレッド内に存在することができ、構成要素は、１つのコンピュータ上に局在化されるか、および／または、２またはそれ以上のコンピュータに分散されうる。さらに、これらの構成要素は、様々なデータ構造を格納して有している様々なコンピュータ読取可能媒体から実行されうる。これらの構成要素は、（例えば、ローカル・システムや分散システムと相互作用する１つの構成要素からのデータ、および／または、例えば信号を介して他のシステムと通信するインターネットのようなネットワークを介したデータのような）１または複数のデータ・パケットを有する信号にしたがって、ローカル処理および／または遠隔処理によって通信することができる。
【００３３】
さらに、本明細書では、様々な実施形態がユーザ・デバイスに関して記載される。ユーザ・デバイスはまた、システム、加入者ユニット、加入者局、移動局、モバイル・デバイス、遠隔局、アクセス・ポイント、基地局、遠隔端末、アクセス端末、ハンドセット、ホスト、ユーザ端末、端末、ユーザ・エージェント、無線端末、無線デバイス、またはユーザ機器と称されうる。ユーザ・デバイスは、セルラ電話、コードレス電話、セッション開始プロトコル（ＳＩＰ）電話、無線ローカル・ループ（ＷＬＬ）局、パーソナル・デジタル・アシスタント（ＰＤＡ）、無線接続機能を有するハンドヘルド・デバイス、または、無線モデムに接続されたその他の処理デバイスでありうる。
【００３４】
さらに、本明細書に記載の様々な局面または特徴は、標準的なプログラミング技術および／またはエンジニアリング技術を用いた方法、装置、または製造物品として実現されうる。本明細書で使用される用語である「製造物品」は、任意のコンピュータ読取可能デバイス、キャリア、または媒体からアクセスすることが可能なコンピュータ・プログラムを含むことが意図されている。例えば、コンピュータ読取可能媒体は、限定される訳ではないが、磁気記憶装置（例えば、ハードディスク、フロッピー（登録商標）ディスク、磁気ストライプ等）、光ディスク（例えばコンパクト・ディスク（ＣＤ）、ＤＶＤ等）、スマート・カード、およびフラッシュ・メモリ・デバイス（例えば、カード、スティック、キー・ドライブ等）を含むことができる。
【００３５】
様々な実施形態が、多くのデバイス、構成要素、モジュール等を含みうるシステムの観点から示されるだろう。様々なシステムが、追加のデバイス、構成要素、モジュール等を含み、および／または、図面と関連して説明されたデバイス、構成要素、モジュール等のうちの全てを必ずしも含む訳ではないことが理解され認識されるべきである。これらのアプローチの組み合わせも使用されうる。
【００３６】
図示するように、図１は、マルチホップ・アド・ホック無線ネットワーク１００において通信をルーティングすることを例示する。例示目的であって、限定するのではなく、以下は、無線マルチホップ・アド・ホック・システムにおける通信のルーティングを説明する。システム１００は、無線通信している任意の数のモバイル・デバイスまたはノードを含むことができ、うち６個が例示されている。モバイル・デバイスは、例えば、セルラ電話、スマート電話、ラップトップ、ハンドヘルド通信デバイス、ハンドヘルド計算デバイス、衛星ラジオ、全地球測位システム、パーソナル・デジタル・アシスタント（ＰＤＡ）、および／または、無線ネットワーク１００を介して通信するためのその他適切なデバイスでありうる。無線ネットワーク１００はまた、１または複数の基地局またはアクセス・ポイント（図示せず）を含むことができる。
【００３７】
送信者すなわちソース・ノード１０２は、受信者すなわち宛先ノード１０４と通信することを望んでいる。送信ノード１０２と受信ノード１０４との間のパケット転送を可能にするために、１または複数の中間ノード１０６，１０８、１１０、および／または１１２を利用することができる。任意のノード１０２−１１２が送信ノード、受信ノード、および／または中間ノードになりえることが理解されるべきである。
【００３８】
送信ノード１０２と受信ノード１０４との間のパケット転送は、様々な経路をとりうる。例えば、パケットは、送信ノード１０２から中間ノード１０８、１１２へと転送され、最終的に、その宛先である受信ノード１０４に到着する。しかしながら、例えばノード１０２からノード１０６、ノード１１０、ノード１１２、そして最終的にノード１０４へ行くようなその他の経路も可能である。パケットは、その目的地に到達するために多くの異なるルートまたは経路をとることができ、そのようなルートの全てを説明することは不可能であることが理解されるべきである。
【００３９】
ノード１０２−１１２は、モバイル・デバイスでありえるので、システム１００に入ることも、システム１００から出ることもできる。ノードが移動し、他のノードと通信することができない場合、異なる経路および通信スケジュールがネゴシエートされうる。ノードは、システム１００に入り、新たに追加されたノードを含む経路および通信スケジュールが、生成またはネゴシエートされうる。
【００４０】
したがって、アド・ホック・ネットワークは本質的に動的であって、（新たなセッションによって）新たなリンクが形成される一方、他のリンクがネットワークから離脱しうる。リンクのこの動的な性質はまた、信号成分のうちの１つまたは全てにおける信号強度の低減またはフェージングのようなチャネル特性によって生じる。この動的な性質は、リソース割り当てを選択する。例えば、グローバル・リソース・アロケーション（ＧＲＡ）スキームでは、新たなリンクが生成または終了する毎に、全て（出てゆくものを含む）のリンクのリソースがネゴシエートされる。インクリメント・リソース・アロケーション（ＩＲＡ）スキームでは、セッションの開始時に一度、リソースが割り当てられる。したがって、ＩＲＡスキームでは、ネットワークは、既存のリンクに割り当てられたリソースを維持しながら、リソースを新たなリンクに割り当てる。
【００４１】
システム１００は、通信がデータ・レートおよび遅れ、またはサービス品質（ＱｏＳ）要件を満足しているか否かを確認するように構成されうるＭＡＣプロトコルを利用することができる。ＵＷＢ物理レイヤに基づいて、ＭＡＣは、限定的に制限すると、ＣＤＭＡベースのＭＡＣでありうる。さらに、システム１００は、動的なアド・ホック性質を持っているので、既存のリンクを保護しながら、新たなリンクへリソースを割り当てるインクリメントおよび分散スキームにしたがうべきである。
【００４２】
本明細書で開示された様々な実施形態は、双方向リンクを有する音声トラフィックに関連することができる。したがって、スケジューリングされるデータは、固定ビット・レートを持つことができる。例えば、おのおののリンクは、９．６Ｋｂｐｓ（Ｒｖｏｉｃｅ）で送信されうる。ソースから受信側へと発生する遅延（口／耳遅延としても知られている）が、制御されるべきである。この遅延は、許容できる音声品質のために１５０ミリ秒から２００ミリ秒にわたることができる。音声通信は、計算に係る（例えば、符合化、復号）遅延およびバッファリング遅延に加えて、多くのホップを介した送信遅延をもたらす。したがって、ホップ毎の遅延ＴＲＥＰは、例えば２０ミリ秒のように、便利な値に制限されるべきである。さらに、データ・レートＲｖｏｉｃｅと、約１５０ミリ秒でありうる遅延からなるＱｏＳパラメータを維持しながら、ソースから宛先へとリソースがスケジュールされねばならない。様々な実施形態は、音声トラフィックに関して記載されているが、その他の様々な通信（例えば、データ、ビデオ、音楽等）にも適用可能であることが理解されるべきである。
【００４３】
システム１００によって利用されるＭＡＣプロトコルは、予約ベースのＭＡＣであり、リソースが、ソースから宛先へと全体経路に沿ってスケジュールされている。すなわち、予約は、リンクの何れかが許可される前に、経路内の全てのリンクに沿って生じる。これは、ＱｏＳが保証されない場合、音声コールを確立できないという結果になりうる。予約されたリソースは、反復期間ＴＲＥＰを持つ（可変サイズまたは可変長の）時間スロットのものである。許可制御と組み合わされたこの反復期間は、通信のためのＱｏＳを満足することを支援する。システム１００は、干渉マージン（Ｍ）の概念とＣＤＭＡとを利用して、同時送信を許可する（例えば、除外ではなくスケジューリングする）こと等によって、ＵＷＢ物理レイヤの拡散スペクトル特性を導入する。ハイブリッドＡＲＱの時間スロット復元技術はまた、リソース利用を向上するためにも用いられうる。
【００４４】
それぞれのノードは、その近辺にあるノードに関する情報を、例えばリソース予約テーブル（ＲＴ）内に保持する。そのようなテーブルは、ＩＥＥＥ ８０２．１１スキームで使用されるネットワーク・アロケーション・ベクトル（ＮＡＶ）の拡張版でありうる。リソース予約テーブルは、対象ノードの近傍内の他のアクティブ・ノード（例えば、受信および送信を行っているか、何れかの機能を実行するようにスケジュールされたノード）に関する情報を用いて、対象ノードを符合化することができる。近傍にある全てのアクティブ・ノードについて、リソース予約テーブルは、各アクティブ・ノードのスケジュール（例えば、送信の時間スロット）、干渉マージン、送信電力、および、ノード間の経路喪失を含むことができる。
【００４５】
（例えば、予約要求（ＲＴＲ：Request To Reserve）パケットや、予約確認（ＲＣ：Reservation Confirm）パケット交換による）リソース予約要求は、アド・ホック・ネットワークをもたらす非効率を緩和するために複数の対策を講じる通知された制御メカニズムの利用をもたらす。そのような対策は、共通予約チャネル（例えば、予約パケットのために利用されている共通ＰＮコード）を聞くことを含む。これによって、ノードは、その近傍に関する情報を取得できるようになる。その近傍に関して得られた知識を用いて、ノードは、パケットが、スケジュールされた送信と干渉しないように予約パケットを送信することができる。
【００４６】
別の対策は、適切な範囲を得るために、予約パケット（ＲＴＲ／ＲＣ）をレートＲＲＣで送ることを含むことができる。この範囲は、干渉範囲（ＩＲ）または干渉近傍と考えることができる。この範囲内のリンクは、他の通信と干渉する場合、個別のリソースを割り当てられうる。予約チャネルのために異なるレートを用いることによって、隠れ端末問題（hidden terminal problems）を緩和することができる。なぜなら、干渉範囲は、送信範囲とは異なるからである。その後、スケジュールを決定するために、許可制御ポリシーを用いることができる。決定されたスケジュール、または、リンクを実行できないことが、ＲＣパケットによって送信ノードへと伝送される。
【００４７】
選択された範囲であるレートＲＲＣでＲＴＲ／ＲＣパケットを送信することは、各ノードの広い近傍を提供し、各ノードが、（スケジュールされねばならない）潜在的に干渉しているリンクに関する情報を取得できるようにする。したがって、隠れ端末問題あるいは露出ノード問題は、存在しない。
【００４８】
さらに、予約パケットの範囲が固定されているので、より短いリンクは、より大きな干渉半径／送信半径比を持つはずである。より短いリンクは、一般により強いリンクであり、より少ない干渉しか許容しないに違いない。したがって、ＲＣ／ＲＴＲパケットの範囲を、可能な限り大きな範囲に設定することによって、適応性のある特性をネットワークに与えることができ、より強いリンクは、より広い周辺領域に関する情報を持つので、低い干渉しかなく、より良好なスケジュールを選択できるに違いない。
【００４９】
図２は、様々な実施形態にしたがったＵＷＢアド・ホック無線ネットワーク２００におけるスケジューリングを例示する。無線ネットワーク２００は、ノードＡ２０２、ノードＢ２０４、ノードＬ２０６、ノードＣ２０８、ノードＥ２１０およびノードＤ２１２として表される複数のノードを含んでいる。特定のネットワークに依存して、これより多くまたはこれより少ないノードとなりうることが理解されるべきである。
【００５０】
以下の例は、開示された実施形態を利用する典型的なネットワークを示す。ノードＡ２０２は、ノードＢ２０４とのセッションを始めることを望む。ノードＡ２０２は、ノードＡ２０２と、ノードＢ２０４との間の経路を探索または識別することによって始まる。この経路は、ノードＡ２０２と、ノードＢ２０４との間のセッションを確立するために十分なリソース（例えば、ＱｏＳルーティング・プロトコルをオーバレイすることによって提供される粗い推定値）を持つに違いない。これは、プロトコル・スタックのネットワーク・レイヤにおいて動作するサービス品質（ＱｏＳ）ルーティング・プロトコルの一部でありうる。例示目的で、ＭＡＣレイヤにおいて、そのような経路が発見されたと仮定される。この経路は、例えばＡ−Ｌ−Ｂと命名することができる。ＵＷＢ環境における予約ベースのＭＡＣプロトコルのための典型的なスケジュール３００が、図３に例示される。この典型的なスケジュール３００は、長さが１９２ビットであり、１５３．６Ｋｂｐｓ（例えば、２つのパケットまたは双方向リンクからなるセットのおのおのが２．５ミリ秒をとる）のレートで送られる音声パケットを利用して構築された。しかしながら、開示された実施形態で、その他の音声パケットの長さおよびレートが利用されうることが理解されるべきである。
【００５１】
送信の構造は、ネットワークを介した別の双方向リンク（例えばＡ−Ｌ、Ｌ−Ａ、Ｅ−Ｃ、Ｃ−Ｅなど）に割り当てられた適切な持続期間からなる時間スロット（３０２、３０４において代表的に示す）からなる。おのおのの双方向リンクは、スケジュールされた持続時間の間送信し、ＴＲＥＰ毎に送信を繰り返す。図示するように、おのおののリンクは自分自身の周期的な送信を有する。これは、ネットワーク内の１つおきのリンクの送信からディザ（dither）されうる。したがって、明確なフレーム構造はない。ＱｏＳを保証するのに役立つために、全てのリンクが、両方向において、（Ｒｖｏｉｃｅ＊ＴＲＥＰ）個のビットを送信すべき（例えば、合計して［２＊Ｒｖｏｉｃｅ＊ＴＲＥＰ］個のビットを交換するべき）である。リンクＲＯＰの運用上のデータ・レートに基づいて、時間スロットは、持続時間（２＊Ｒｖｏｉｃｅ＊ＴＲＥＰ／ＲＯＰ）でありうる。明確なフレーム構造がないので、ネットワークを介して必要とされる精密に調節された同期は存在せず、アド・ホック・ネットワークの低オーバヘッド分布特性に一致する。
【００５２】
経路Ａ−Ｌ−Ｂを特定した後、ノードＡ２０２は、予約要求（ＲＴＲ）制御パケット３０６を、共通のコードで、中間ノードＬ２０６へ送信する。ＲＴＲパケット３０６は、ノードＡ２０２のリソース予約テーブルを含まねばならない。最初に、ノードＡ２０２の予約テーブルは空であるので、ノードＡ２０２の観点から、送信Ａ−Ｌについての制約はない。ノードＣ２０８は、ＲＴＲパケット３０８を聞き、解釈することができるが、ＲＴＲパケット３０６に関していかなる機能（例えば、テーブの解釈、更新など）も実行しない。
【００５３】
予約テーブルは、おのおののノードにおいて保持されるべきである。テーブルは、ＩＥＥＥ ８０２．１１スキームで利用された、ネットワーク・アロケーション・ベクトル（ＮＡＶ）の拡張と考えることができる。予約テーブルは、ノードの近傍内にある他のアクティブ・ノード（例えば、それぞれの機能を実行するために受信し、送信し、あるいはスケジュールされたノード）に関する知識を用いて、適切なノードを符合化する。特定のノードの近傍内にあるすべてのアクティブ・ノードについて、予約テーブルは、アクティブ・ノード・スケジュール（例えば、送信の時間スロット）、干渉マージンＭ（ｊ）、送信電力、アクティブ・ノードｊからノードｉへの経路喪失Ｇｉｕを含む。したがって、予約テーブルｉは、近傍内における全てのノードに含まれるローカル・スケジュールおよびトポロジ情報を示す。
【００５４】
このパケットを受信するのと実質的に同時に、ノードＬ２０６は、その予約テーブルと、ＲＴＲパケット３０６に含まれるノードＡ２０２の予約テーブルとを調べる。ノードＬ２０６は、通信Ａ−Ｌ ３０２のために実行可能なスケジュールの発見を試みる。実行可能にするために、許可制御ポリシーがアクセスされ、スケジュールの様々な条件（例えば、近隣のアクティブ・ノード、ネットワーク内のスケジュールされた他の送信、送信レートに関する情報）が確認される。最初の送信のために、ノードＡ２０２とノードＬ２０６の予約テーブルが空にされ、これによって、条件が満たされる。
【００５５】
ノードＬ２０６は、通信Ａ−Ｌのため（Ｔ１中）、最も早期のスケジュールを選択することができる。ノードＬ２０６は、その予約テーブルを更新し、更新された予約テーブルを含むＲＴＲパケット３０８を、ノードＢ２０４に送る。ＲＴＲパケット３０８を受信するのと実質的に同時に、ノードＢ２０４は、ノードＬ２０６とノードＢ２０４の予約テーブルを調べ、実行可能なスケジュールの発見を試みる。もしもスケジュール３０４が発見されると、ノードＢ２０４は、予約確認（ＲＣ）パケット３１０をもって応答し、スケジュールＬ−Ｂ ３０４をアナウンスする。
【００５６】
ＲＣパケットは、近隣ノード（例えば、ノードＥ２１０、ノードＣ２０８等）によってパケットを聞くことを可能にする共通のコードを用いて送信されねばならない。ＲＣパケットには、ノード受信の干渉マージンＭが含まれうる。この干渉マージンによって、近傍内のノードは、そのようなノードが、同時通信をスケジュールできるかを判定することが可能となる。ＲＣパケットはまた、ノードの電力および送信スケジュールを含むべきである。そのような情報によって、近傍にあるノードは、スケジュールされたセッションから、予期された干渉を判定できるようになる。
【００５７】
ＲＣパケット３１０を受信するのと実質的に同時に、ノードＬ２０６は、ノードＡ２０４にＲＣパケット３１２を送り、スケジュールＬ−Ｂ ３０４およびスケジュールＡ−Ｌ ３０２をアナウンスする。ノードＡ２０２は、ＲＣパケット３１２を受信するのとほぼ同時に、ＲＣパケット３１４をノードＬ２０６に送り、スケジュールＡ−Ｌ ３０２をアナウンスする。
【００５８】
近傍におけるノード（例えば、この例ではノードＣ２０８、ノードＥ２１０、およびノードＤ２１２である近隣ノード）は、そのようにして、それぞれの予約テーブルを更新する。ノードＡ２０２とノードＢ２０４との間の実際のデータ送信は、時間Ｔ２において３１６および３１８に示すように、決定されたスケジュールにしたがって進む。
【００５９】
例を続けると、ノードＥ２１０は、経路Ｅ−Ｃ−Ｌ−Ｄを介してノードＤ２１２とのセッションを開始したいと思っている。ノードＥ２１０は、ノードＣ２０８にＲＴＲパケット３２０を送る。ＲＴＲパケット３２０は、ノードＥ２１０の予約テーブルを含まねばならない。通信Ａ−Ｌ ３１６および通信Ｌ−Ｂ ３１８に気づいているノードＣ２０８は、ノードＥ２１０からの通信を同時にスケジューリングできるかを判定することができる。通信Ｃ−Ｌ ３２２の送信電力が、（例えば、ノードＬ２０６において）スケジューリングされた通信Ａ−Ｌ ３１６を妨害するが、スケジューリングされた通信Ｌ−Ｂ ３１８を妨害しないと仮定する。したがって、ノードＣ２０８は、Ｅ−Ｃ ３２２をＬ−Ｂ ３１８と同時にスケジュールすることができ、この情報を、ＲＴＲパケット３２２で、ノードＬ２０６へ通信しなくてはならない。必要ならば、ノードＣは、３２４に示すように、ノードＬ２０６がアイドルになるまで待機し、ノードＬ２０６が通信を受信する準備ができたときにＲＴＲパケット３２２を送る。ノードＬ２０６は、通信Ｃ−Ｌ ３２６をスケジューリングし、ノードＤ２１２にＲＴＲパケット３２８を送ることができる。ノードＤ２１２は、ＲＣパケット３３０をもってＲＴＲパケット３２８に応答し、スケジュールＬ−Ｄ ３３２をアナウンスする。例示するように、ノードＬ２０６は、ＲＣパケットをもって応答するための十分な時間を持っていない。したがって、ノードＬ２０６は、次の期間Ｔ３まで、ＲＣパケット３３４を送るのを待つ。その後、ノードＣ２０８が、ＲＣパケット３３６を送る。ＲＣパケットを受信すると、ノードＥ２１０は、ＲＣパケット３３８を送る。このように、データは、スケジューリングされた経路Ｅ−Ｃ−Ｌ−Ｄに沿って送られる。
【００６０】
対象デバイスの近傍または近辺にあるおのおののアクティブ・ノードについて、対象デバイスの予約テーブルの以下のエントリーが送られる。送信／受信フラグ、スケジュール、最大許容干渉、および送信電力。送信／受信フラグは、説明したリンクについて近隣ノードが送信機であるか受信機であるかを示すことができ、約１バイトの長さでありうる。スケジュールは、近隣ノードのアクティビティ（例えば、受信、送信）の持続時間および開始時間を含む。このスケジュールは、キャラクタを用いた約２バイトであることができ、時間スロットでありうる。近隣ノードが受信中、Ｍ（ｕ）によって示される近隣ノードの最大許容干渉（Ｍ）は、約１バイトの長さでありうる。これは、近隣ノードが、例えば（近隣ノードによって通知された）対象デバイスのような干渉ノードから許容できる最大の追加干渉である。これらのエントリは、それぞれの予約制御パケット内の近隣ノードによって通知される情報を利用して、および、そのような制御パケットの信号強度を測定することによって計算されうる。スケジュールされた送信中、近隣ノードの送信電力は、およそ１バイトの長さでありうる。
【００６１】
（約６バイトでありうる）近隣デバイスのアドレスと、（約６バイトの長さでありうる）宛先デバイスのアドレスとは、予約テーブル・エントリに含まれうるが、ＲＴＲパケットで送られる必要はないことに注目されるべきである。したがって、予約テーブル・エントリは、約５バイトのデータを含むことができる。
【００６２】
ＲＴＲパケットは、予約テーブルを含んでいるので、ＲＴＲパケットは、可変長である。さらに、ＲＴＲパケットは、以下のフィールドを含むことができる。送信元アドレス（約６バイト）、受信アドレス（ＭａｃＤｅｓ）（約６バイト）、パケット・タイプを含む約１バイト、およびエントリ数を含む約１バイトのフィールド。
【００６３】
ＲＴＲパケットの推定サイズは、約７バイトかそれ以上になるが、プリアンブル、物理ヘッダ、および予約テーブルにおけるエントリ数は含んでいない。２つの送信について、その他２つのノードを聞いたり、あるいは観察するリンクの場合、予約テーブルに関して着目される推定値を利用することによって、おのおののＲＴＲパケットは、合計３４バイト（１４＋（４＊５））のサイズを持つが、これはＰＨＹヘッダ（２４バイト）と、プリアンブル（１０マイクロ）を含んでいない。これは、１５３．６Ｋｂｐｓにおいて３．０３ミリ秒、５００Ｋｂｐｓにおいて０．９８ミリ秒のオーバヘッドを表しうる。したがって、送信機は、オーバヘッドを最小化するＲＴＲパケットを送るための最良のレートを知っている。しかしながら、このレートは一般に、ＲＴＲ受信が成功した後に決定されるので、ＲＴＲは、Ｒｍｉｎで送られる。なぜなら、リンクは、少なくともこのレートをサポートしなくてはならないからである。
【００６４】
ＲＣパケットは、固定長であり、比較的小さいオーバヘッドしか有さない。例示目的のために、ノードＢ２０４がノードＡ２０２からＲＴＲパケットを受信し、ノードＢ２０４が、ＲＣパケットをもって応答することを望んでいると仮定する。ノードＢ２０４は、約２バイトでありうる送信フィールドの開始および終了を含む様々なフィールドをＲＣパケットに含めるだろう。コールを識別するソース・アドレス・フィールドもまた含まれる。これは、約６バイトでありリンクの送信元を識別することができる送信元アドレスと同様に、約６バイトでありうる。ＲＣパケットはまた、長さ約６バイトである宛先アドレス・フィールドを含む。ＲＣパケットには、送信元および受信側における送信電力および干渉マージン（約４バイト）、パケット・タイプを含む（およそ）１バイトのフィールド、エントリ数を示す（およそ）１バイトが含まれる。ＲＣパケットは、約２６バイトであり、ＰＨＹヘッダ（２４バイト）およびプリアンブル（１０マイクロ）が含まれていないことが注目されるべきである。これは、１５３．６Ｋｂｐｓにおいて２．５ミリ秒、５００Ｋｂｐｓにおいて０．７７ミリ秒を表す。
【００６５】
ノードは、同じ時間リファレンスを持つ必要がないことに注目されるべきである。例えば、ノードＡ２０２が、ＲＴＲパケットを含む予約テーブルを、ノードＢ２０４に送る場合、その予約テーブルに含まれる持続時間値は、ノードＡ２０２における第１のＲＴＲビットの送信時間に関連している。伝播時間が無視できる（例えば、１ミリ秒未満）と仮定すると、この時間は、ノードＢ２０４における第１のビットの受信時間に実質的に近い。おのおののリンクは、自身の基準時間（例えば２０ミリ秒）を持つべきである。ネットワークは、リンク近傍を通って接続されているので、クロック・ドリフトは、予約期間が更新されるごとに、数マイクロ秒超えるはずがない。
【００６６】
図４は、開示された実施形態にしたがった無線デバイス４００を例示する。無線デバイス４００は、ソース・デバイス、宛先デバイス、あるいは、通信経路に沿った中間デバイスまたはノードでありうるが、１つの特定の機能に限定されないことが注目されるべきである。すなわち、この通信経路に沿って、無線デバイスは、実質的に同時に、複数の機能を実行することができる。
【００６７】
無線デバイス４００は、通信（例えば、音声、データ、テキスト、画像、ビデオ等）、ＲＣパケット、およびＲＴＲパケットを送信するように構成された送信機４０２と、受信するように構成された受信機４０４とを含む。そのような送信、受信、あるいは両方は、通信ネットワークにおいて生じるトラフィックに依存して、別々の時間、あるいは実質的に同時に起こりうる。
【００６８】
オブザーバ４０６は、近隣デバイスのトラフィックを観察または監視するように構成されうる。例えば、近隣デバイスは、ＲＣパケット、ＲＴＲパケット、またはこれら両方のパケットを、送信、受信、または送信と受信との両方を行うことができる。オブザーバ４０６は、オブサーバ４０６によって理解される共通のコードを用いて送信されるパケットおよびトラフィックを観察することができる。そのようなパケットは、近隣デバイス、近隣デバイス間の通信のスケジューリング、あるいは、ネットワーク内の通信をスケジュールするために無線デバイス４００によって利用されうるその他の情報に関連する予約テーブルを含めることができる。
【００６９】
無線デバイス４００にはさらに、ＮＡＶの拡張版でありうるリソース予約テーブル４０８が含まれる。予約テーブル４０８は、アクティブ（例えば、受信中、送信中等）である近隣ノードに関連する情報を用いて、無線デバイス４００を符合化することができる。そのような情報は、スケジュール（例えば、送信の時間スロット）、干渉マージンＭ（ｊ）、送信電力、経路喪失、および、近隣ノードのスケジューリングおよびローカルなトポロジに関連する情報を予約テーブル４００が持つことを可能にするその他の情報、を含むことができる。
【００７０】
無線デバイス４００に含まれるスケジューラ４１０は、受信したＲＴＲパケットに含まれる情報に部分的に基づいてスケジューリングを決定するように構成されうる。そのような情報は、近隣デバイスのスケジューリングを含むことができる。スケジューラ４１０はさらに、利用可能なスケジュールを分析し、かつ、通信経路における対象リンクのための最も早い通信を選択するように構成されうる。許可制御ポリシー４１２は、選択されたスケジュールが、基準を満足しているか、あるいは実現可能であるかを判定するために構成されうる。リンクのスケジュールまたは実現不可能であることは、送信４０２を介して送信ノードへ通信されうる。メッセージまたはパケットが近隣デバイスへ送信される前に、情報をメッセージ、パケット、またはメッセージとパケットの両方に設定または追加することが可能なコンフィギュラ４１４が含まれうる。
【００７１】
ＲＴＲパケットは、コール・セットアップ・パケットであると考えられ、正しく受信されねばならない。したがって、ＲＴＲの送信は、それがあたかもＤＡＴＡパケットであるかのようにスケジュールされうる。これが可能でない場合、ＲＴＲは、たとえ進行中の通信（例えば、音声通信）に干渉を引き起こしても、送られうる。幾つかの実施形態では、送信前のレート情報の欠如、および、ＲＴＲパケットのサイズによって、高度なメカニズムが必要でありうる。幾つかの実施形態では、ノードは、経路における次のホップを予約するために、その受信機が自身のＲＴＲパケットを送ることをパッシブに確認することができよう。しかしながら、ＲＴＲパケットが得る能力が確認されるべきである。
【００７２】
ＲＣは、小さなパケットであり、ＲＣ送信前に、リンクによってサポートされているレートが知られているので、高度なメカニズムによって取り扱うことができる。したがって、ＲＣは、予約を確認した同じスロットで送信されうる。例えば、ノードＢがノードＡのＲＴＲに対して、例えば０ミリ秒から５ミリ秒の間で、ノードＡとノードＢとの間のデータ送信を可能にする予約エントリを有するＲＣパケットをもって応答した場合、ＲＣがこのスロットで送信されうる。ＲＣサイズがＤＡＴＡパケット・サイズ未満である場合、これは可能である。
【００７３】
メモリ４１６は、無線デバイス４００と動作可能に接続されうる。メモリ４１６は、無線デバイスのスケジュールと予約テーブル、近隣デバイスのスケジュールまたは複数の予約テーブル、あるいは、通信ネットワーク内のデバイスおよびトラフィックに関するその他の情報に関する情報を格納することができる。プロセッサ４１８は、通信をスケジューリングすることに関連する情報の分析を容易にするスケジューラ４１０（および／またはメモリ４１６）と動作可能に接続されうる。プロセッサ４１８は、受信機４０４またはスケジューラ４１０によって受信される情報の分析および／または生成に特化されたプロセッサ、無線デバイス４００の１または複数の構成要素を制御するプロセッサ、および／または、受信機４０４によって受信された情報の分析および生成と、無線デバイス４００の１または複数の構成要素の制御との両方を行うプロセッサでありうる。
【００７４】
メモリ４１６は、ＡＣＫ／ＮＡＣＫプロトコルにしたがってアクノレッジメントを生成することと、干渉を低減することと、通信をスケジュールすることと、ソース・デバイスと宛先デバイスとの間の通信を制御する動作を講じることとに関連するプロトコルを格納し、もって、無線デバイス４００が、格納したプロトコルおよび／またはアルゴリズムを用いて、本明細書で記載したように、無線ネットワークにおける向上された通信を達成できるようにする。本明細書で記載したようなデータ格納（例えば、メモリ）構成要素は、揮発性メモリまたは不揮発性メモリの何れであってもよいか、あるいは、揮発性メモリと不揮発性メモリとの両方を含むことができることが認識されるべきである。限定ではなく一例として、不揮発性メモリは、読取専用メモリ（ＲＯＭ）、プログラマブルＲＯＭ（ＰＲＯＭ）、ＥＰＲＯＭ（ＥＰＲＯＭ）、ＥＥＲＯＭ（ＥＥＰＲＯＭ）、あるいはフラッシュ・メモリを含むことができる。揮発性メモリは、ランダム・アクセス・メモリ（ＲＡＭ）を含むことができる。それは、外部キャッシュ・メモリの役割をする。限定ではなく一例として、ＲＡＭは、シンクロナスＲＡＭ（ＤＲＡＭ）、ダイナミックＲＡＭ（ＤＲＡＭ）、シンクロナスＤＲＡＭ（ＳＤＲＡＭ）、ダブル・データ・レートＳＤＲＡＭ（ＤＤＲ ＳＤＲＡＭ）、エンハンストＳＤＲＡＭ（ＥＳＤＲＡＭ）、Ｓｙｎｃｈｌｉｎｋ ＤＲＡＭ（ＳＬＤＲＡＭ）、およびダイレクト・ラムバスＲＡＭ（ＤＲＲＡＭ（登録商標））のような多くの形式で利用可能である。開示された実施形態のメモリ４１６は、限定されることなく、これらおよびその他の適切なタイプのメモリを含むことが意図される。
【００７５】
無線デバイス４００はさらに、適切な無線通信プロトコル（例えば、ＯＦＤＭ、ＯＦＤＭＡ、ＣＤＭＡ、ＴＤＭＡ、ＧＳＭ（登録商標）、ＨＳＤＰＡ等）にしたがって信号を変調および／または符合化することができる。これら信号は、その後、宛先デバイスへ送信されうる。エンコーダは、アナログ波形をデジタル信号に変換する音声アナライザを利用するボイス・コーダ（ボコーダ）であるか、あるいは、別のタイプのエンコーダでありうる。
【００７６】
無線デバイス４００にはさらに、処理のために、受信した信号および／またはその中の信号を復号することができるデコーダ要素（図示せず）でありうる。データ・パケットの復号が成功すると、アクノレッジメント（ＡＣＫ）要素（図示せず）が、データ・パケットの正しい復号を示すアクノレッジメントを生成することができる。これは、（送信機４０２によって）ソース・デバイスへ送られ、このデータが受信され復号されたので、再送信する必要がないことがソース・デバイスへ通知される。
【００７７】
図５は、開示された実施形態に従った予約更新スケジュール５００を例示する。予約セッションの経路は、モビリティ、チャネル挙動、ノード失敗等を含む様々な要因によるＱｏＳ違反を被る。したがって、効率的なリソース・リリース・メカニズムは、予約済みの既存の経路が使用されなくなった場合に、おのおののノードにおいて、予約されたリソースを解放することができる。さらに、端末または無線デバイスにおいて、もはや古くなった予約テーブルが、削除されるべきである。予約更新メカニズムが適用され、これによって、予約要求が、予め定めた間隔で、あるいは、要求があった場合に更新される。ノードが、予め定めた間隔後に、セッションのための新たな予約更新パケットを受信していなのであれば、その予約に対応する情報は、解放されたか、あるいは除去されたものと考えられる。
【００７８】
おのおのの予約エントリは、有効性の持続時間を持っており、この持続時間が経過すると、予約テーブルから除去される。ＲＣ更新（ＲＣアップデート）パケットは、例えば２０ミリ秒またはその他の間隔であるＮＲＣ期間ごとに一度送られる。この間隔は、新たなリンクが、どれくらい頻繁にネットワークに入るかに依存しうる。早期の終了期間（例えば、データが正しく送信された後、スケジュールされた時間間隔における残り時間）は、ＲＣ更新のために利用することができる。そのようなやり方で、リンクが早期に終了すると、リソースが解放され、スケジュール・スロットとなる。これは、進行中の送信との干渉の発生を緩和する。
【００７９】
ＲＣ更新期間ＮＲＣは、５０２に例示されている。これは、新たなＲＣ５０４が利用可能になるのとほとんど同時に始まる予め定めた間隔でありうる。予め定めた間隔５０６（例えば、周期的なＲＣ更新タイマ）が終了すると、ノードは、第１の利用可能なフリー・スロット５１０においてスケジュールされるべきＲＣ更新５０８を送信する準備ができる。５１２に示すように、実質的に同時にタイマがリセットされる。
【００８０】
リンクが早期に終了すると、送信機は、ＲＣ更新パケットを送信するための十分な時間があるかどうかを判定する。ＲＣ更新は、高レートで送られるので、時間は、利用可能でありうる。その後、現在の時間が、例えば２０ミリ秒のように、ＲＣ更新タイマ有効期間の予め定めたマージン内である場合には、２次チェックが実行される。これが真である場合、ＲＣ更新が、早期終了時間で送られ、タイマがリセットされる。ランダムなディザが、更新期間に追加され、ＲＣ更新が少ない潜在的な干渉物がないことを緩和することができる。潜在的な干渉物は、例えば、ＲＣ更新が送られ、ランダムなディザが、そのような干渉物にＲＣ更新を提供することを助ける場合にビジーである。
【００８１】
ＲＴＲパケットと同様に、ＲＣアップデート（ＲＣ更新）のオーバヘッドが計算されうる。ＲＣアップデート（ＲＣ更新）の場合、ＲＣアップデート（ＲＣ更新）パケットは、早期終了領域に適合され、小さくなくてはならない。ＲＣアップデート（ＲＣ更新）は、エントリ毎に以下のフィールドを含まねばならない。約６バイトである宛先フィールド。ＲＣアップデート（ＲＣ更新）は、ソースがノードであるリンクに関する情報を提供するので、ソース・アドレスは必要ではない。約２バイトである開始時間および終了時間が含まれねばならない。約２バイトである送信機電力および干渉マージンも提供されねばならない。
【００８２】
各エントリについて以下の情報も含まれねばならない。約６バイトである送信元アドレス。約６バイトである受信側アドレス（ＭａｃＤｅｓ）。パケット・タイプを含む約１バイトのフィールドと、エントリ数を含む約１バイトのフィールド。従って、４つのエントリを持つノードのＲＣアップデート（ＲＣ更新）サイズは、５４バイト（１４＋（４＊１０））である。これは、ＰＨＹヘッダ（約２４バイト）およびプリアンブル（約１０マイクロ）を含んでいない。ＲＣアップデート（ＲＣ更新）レートは、約１Ｍｂｐｓであり、０．６２５ミリ秒のオーバヘッドを表すＲＲＣであるように設定される。
【００８３】
図示され記述された典型的なシステムを考慮すると、開示された主題にしたがって実施される方法は、図６乃至図９のフロー・チャートを参照してより良く理解されるだろう。説明を簡単にする目的のために、これら方法は、連続したブロックとして示され記述されているが、特許請求された主題は、これらブロックの数または順序によって制限されず、幾つかのブロックが、本明細書で示され説明されたものとは、異なる順序で、および／または、他のブロックと同時に生じうることが理解され認識されるべきである。さらに、後に示す方法を実施するために、例示された全てのブロックが必要とされる訳ではない。これらブロックに関連付けられた機能は、ソフトウェア、ハードウェア、これらの組み合わせ、あるいは、その他任意の適切な手段（例えば、デバイス、システム、プロセッサ、構成要素等）によって実施されうることが理解されるべきである。さらに、以下に示す開示および本明細書全体にわたって開示された方法は、そのような方法を様々なデバイスへ伝送および転送することを容易にするために、製造物品に格納されることが可能であることが認識されるべきである。当業者であれば、方法は、例えば状態図のような相互関連した状態やイベントのシリーズとしても表すことができることを理解し認識するだろう。
【００８４】
図６は、ＵＷＢアド・ホック・ネットワークにおいてＱｏＳ音声コールを確立する方法６００を例示する。方法６００は、宛先デバイスへの経路が突き止められる６０２で始まる。この経路は、ソース・デバイス（例えば、無線端末）と、意図されている通信の受取人（例えば、無線端末または宛先デバイス）との間の通信経路である。選択された経路は、ソース・デバイスと宛先デバイスとの間のセッションを確立するための十分なリソース（例えば、ルーティング・プロトコルによって発見された粗い推定値）を持っている。このデバイス間の経路は、共通ノードまたは中間デバイス（１または複数）を含むことができる。６０４では、予約要求（ＲＴＲ：Request-to-Reserve）制御パケットが、中間デバイスへ送られる。ＲＴＲパケットは、ソース・デバイスの予約テーブルを含むことができる。
【００８５】
予約テーブルは最初は空である。したがって、ソース・デバイスの観点から、ソース・デバイスから中間デバイスへの送信について制約はない。
【００８６】
６０６では、ＲＴＲ制御パケットに対する応答が、中間デバイスから、予約確認（ＲＣ：reservation confirmation）パケットの形態で受信される。このＲＣパケットは、中間デバイスを介したスケジューリングを提供する。このＲＣパケットに応答して、６０８では、ＲＣパケットが中間デバイスへ送られ、ソース・デバイスから中間デバイスへのスケジュールがアナウンスされる。そのようなＲＣパケットは、ソース・デバイスの干渉マージンＭと、受信および／または送信スケジュールと、ソース・デバイスの電力とを含みうる。
【００８７】
図７は、超広帯域アド・ホック通信ネットワークにおいて通信をスケジューリングする方法７００を例示する。無線デバイスからのＲＴＲ制御パケットが、中間デバイスにおいて受信されると、７０２において、方法７００が始まる。このパケットは、別のデバイス（例えば、宛先デバイス）との通信を望んでいる無線デバイス（例えば、ソース・デバイス）から受信され、この通信は、中間デバイスとの相互作用を通じて達成される。ＲＴＲパケットは、無線デバイスの予約テーブルを含んでいる。このテーブルは、最初は空であり、つまり、ヌル値しか持っていない。
【００８８】
７０４では、ＲＴＲパケットが調べられ、無線デバイスと中間デバイスとの間のスケジュールが決定される。このスケジュールは、実現可能なスケジュールであり、例えば、ネットワークにおいて実質的に同時に引き起こる他の通信のようなある条件について、許可制御ポリシーが検証される。無線デバイスの予約テーブルと、中間デバイスの予約テーブルとはともに最初は空であるので、条件が満たされる。多くのスケジュールが発見される。そして、７０６では、無線デバイスと中間ノードとの間の通信のための最も早いスケジュールが選択される。最も早いスケジュールを選択するのと実質的に同時に、中間ノードは、その予約テーブルを更新し、７０８において、ＲＴＲパケットを宛先デバイスへ送る。
【００８９】
７１０において、送られたＲＴＲパケットに応答して、宛先デバイスからのＲＣパケットを受信すると、方法７００は継続する。ＲＣパケットは、中間デバイスと宛先デバイスとの間のスケジュールを、中間デバイスに通知する。ＲＣパケットは、共通のコードを用いて送られる。近隣デバイスは、この共通のコードを用いて、パケットを聞いたり、解釈することが可能となる。７１２では、ＲＣパケット（共通のコード）が、無線デバイスへ送られ、無線デバイスと中間デバイスとの間のスケジュールがアナウンスされる。
【００９０】
図８は、超広帯域アド・ホック通信をスケジューリングする方法８００を例示する。方法８００は、ＲＴＲパケットが宛先デバイスにおいて受信される８０２で始まる。ＲＴＲパケットは、ソース・デバイスからの通信が経路付けられる中間デバイスから受信されうる。ＲＴＲパケットは、ソース・デバイスと中間デバイスとの間の通信のための最も早いスケジュールを含む、中間デバイスのための予約テーブルを含んでいる。
【００９１】
８０４に進み、ＲＴＲパケットが調べられ、中間デバイスの予約テーブルと、宛先デバイスの予約テーブルとが検査され、実現可能なスケジュールが決定される。８０６では、ＲＴＲパケットが受信されたことに応答して、予約確認（ＲＣ）パケットが中間デバイスへ送信される。このＲＣパケットは、中間デバイスと宛先デバイスとの間のスケジュールをアナウンスする。ＲＣパケットは、ＲＣパケットに含まれる情報を近隣デバイスが理解するために、共通のコードを用いて送られねばならない。
【００９２】
図９は、近隣デバイス間で交換される情報に部分的に基づいて通信をスケジュールするための方法９００を例示する。この方法９００は、デバイスが、近隣デバイス間の通信を聞くこと９０２で始まる。そのような通信は、共通のコードを用いて送られたＲＣパケットを含むことができる。ＲＣパケットは、例えば、ノード受信の干渉マージン、ノードの送信スケジュールおよび電力、あるいはそれら両方を含むことができる。通信を聞くデバイスは、通信を同時にスケジュールできるか、あるいは、干渉マージンに基づくことなくスケジュールできるかを判定することができる。デバイスは、送信スケジュールおよびノードの電力に基づいて、スケジュールされたセッションから、予期される干渉を決定することができる。９０４では、近隣デバイスのＲＣパケットに含まれる情報を含めるように、中間デバイスの予約テーブルが更新される。
【００９３】
９０６では、１または複数の中間デバイスを介して宛先デバイスへと通信することを望むソース・デバイスから、ＲＴＲパケットが受信される。９０８では、ＲＴＲパケットに含まれる予約テーブルと、中間デバイスの更新された予約テーブルとが分析される。９１０では、そのような分析に部分的に基づいて、実現可能な条件を満足する通信スケジュールが決定される。これら実現可能な条件は、セッションをサポートするための十分な時間スロットがあるか、計算された新たなセッションによって引き起こされた干渉が、既にスケジュールされ進行しているセッションの全ての干渉マージンよりも小さいこと、スケジュールされたセッションが、既にスケジュールされ進行しているセッションからの干渉が存在していても良好に動作していること、および、少なくともＲｍｉｎである最小レートをサポートできることを含む。そのような通信スケジュールは、近隣デバイス間のスケジュールされた通信と、ソース・デバイスと中間デバイスとの間の送信電力が、近隣デバイス間の通信を妨害するかと、に部分的に基づきうる。９１２において、次のデバイス（例えば、中間デバイス、宛先デバイス）に、通信スケジュールが通知されうる。
【００９４】
図１０乃至図１３を参照して、システムが、機能ブロックまたは論理モジュールとして例示される。これらの機能ブロックは、プロセッサ、ソフトウェア、またはこれらの組み合わせ（例えば、ファームウェア）によって実現される機能を表す。システムは、アクセス・ポイント内、またはユーザ・デバイス内に存在することができる。
【００９５】
図１０は、アド・ホック・ネットワークにおいてＱｏＳ通信を確立するシステム１０００を例示する。システム１０００は、宛先デバイスへの経路を決定するための論理モジュール１００２を含む。この経路は、ソース・デバイスで始まり、宛先デバイスが受け取られるまで、この経路に沿ったマルチホップにしたがって進む。第１のデバイスにＲＴＲパケットを伝送する論理モジュール１００４も提供される。この第１のデバイスは、ソース・デバイスと宛先デバイスとの間の経路に沿って位置するデバイス（例えば、無線端末、ノード、基地局）でありうる。ＲＴＲパケットは、スケジュール情報と、アクティブな近隣ノードに関する情報とを含む予約テーブルを含みうる。
【００９６】
システム１０００はまた、ＲＣパケットを受信するための論理モジュール１００６を含む。このＲＣパケットは、ＲＴＲ制御パケットの伝送に応答して受信され、通信スケジュール情報を含む。応答ＲＣパケットを送るための論理モジュール１００８が含まれる。そのような論理モジュール１００８は、ＲＴＲ制御パケットに応答して、受信されたスケジュールを確認するためにＲＣパケットを送信することができる。
【００９７】
幾つかの実施形態にしたがって、近隣デバイス情報を含むリソース予約テーブルを保持したオプションの論理モジュール１０１０が含まれる。そのような論理モジュール１０１０は、更新された情報がアクティブな近隣デバイスから受信された場合、または、新たなスケジューリング情報が利用可能である場合、リソース予約テーブルを自動的に更新することができる。
【００９８】
例えば、装置は、宛先デバイスへの経路を決定するための、論理モジュール１００２でありうる手段と、ＲＴＲパケットを第１のデバイスへ伝送するための、論理モジュール１００４でありうる手段とを含む。ＲＴＲ制御パケットが伝送されることに応答して、スケジュールを備えたＲＣパケットを受信する、論理モジュール１００６でありうる手段と、ＲＣパケットを受信することに応答して、応答ＲＣパケットを送信する、論理モジュール１００８でありうる手段ともまた、装置に含まれうる。
【００９９】
図１１は、アド・ホック通信網ネットワークにおいて通信をスケジューリングするためのシステム１１００を例示する。システム１１００は、ＲＴＲ制御パケットを受信する論理モジュール１１０２を含むことができる。ＲＴＲ制御パケットは、ソース・デバイスと宛先デバイスとの間の経路のための経路情報を含むことができる。論理モジュール１１０４は、経路のための利用可能なスケジュールを分析することができる。また、論理モジュール１１０６は、通信のために最も早いスケジュールを選択することができる。また、システム１１００には、ＲＴＲパケットを宛先デバイスへ伝送するための論理モジュール１１０８が含まれている。ＲＴＲパケットは、最も早いスケジュールに関する情報を含んでなければならない。
【０１００】
幾つかの実施形態に従って、システム１１００はまた、経路に沿って位置している第１の中間デバイスのための第１の予約テーブルと、ソース・デバイスの第２の予約テーブルとに、ＲＴＲパケットを追加するための論理モジュール１１１０をも含む。幾つかの実施形態は、宛先デバイスから第１のＲＣパケットを受信するための論理モジュール１１１２を含む。ＲＣパケットは、通信スケジュールを含んでいる。また、第２のＲＣパケットをソース・デバイスへ送るための論理モジュール１１１４も含まれている。この第２のＲＣパケットは、通信スケジュールを含むことができる。
【０１０１】
例えば、アド・ホック通信ネットワークにおける通信をスケジュールする装置は、ソース・デバイスから宛先デバイスへの経路を含むＲＴＲ制御パケットを受信するための、論理モジュール１１０２でありうる手段を含むことができる。さらには、経路のために利用可能なスケジュールを分析するための、論理モジュール１１０４でありうる手段を含むこともできる。最も早いスケジュールを選択するための、論理モジュール１１０６でありうる手段と、ＲＴＲパケットを宛先モジュールに伝送するための、論理モジュール１１０８でありうる手段ともまた、装置に含まれうる。
【０１０２】
図１２は、アド・ホック通信をスケジューリングするためのシステム１２００を例示する。システム１２００は、ＲＴＲパケットを受信する論理モジュール１２０２と、ネットワーク内でスケジュールされた少なくとも１つの通信と干渉しないスケジュールを決定するための論理モジュール１２０４とを含む。システム１２００はまた、ＲＴＲパケットを受信することに応じて、ＲＣパケットを送信するための論理モジュール１２０６を含むことができる。このＲＣパケットは、スケジュールを含むことができる。幾つかの実施形態によれば、システム１２００は、このスケジュールを用いてルーティング・テーブルを更新するための論理モジュール１２０８を含むことができる。
【０１０３】
例えば、アド・ホック通信をスケジューリングする装置は、ＲＴＲパケットを受信するための、論理モジュール１２０２でありうる手段を含むことができる。装置はまた、スケジュールされた少なくとも１つの通信と干渉しないスケジュールを決定するための、論理モジュール１２０４でありうる手段と、ＲＴＲパケットを受信することに応答して、ＲＣパケットを送信するための、論理モジュール１２０６でありうる手段とを含むこともできる。
【０１０４】
図１３は、マルチホップ・アド・ホック・ネットワークにおいて通信をスケジューリングするシステム１３００を例示する。システム１３００は、近隣デバイス間の通信を聞くための論理モジュール１３０２を含むことができる。その通信は、共通のコード上で送られるＲＣパケットを含むことができる。さらに、通信に含まれる情報を用いてルーティング・テーブルを更新するための論理モジュール１３０４と、予約テーブルを含むＲＴＲパケットを受信するための論理モジュール１３０６とも含まれる。さらに、ルーティング・テーブルを分析するための論理モジュール１３０８と、ルーティング・テーブルに部分的に基づいて通信スケジュールを決定するための論理モジュール１３１０ともまた含まれている。
【０１０５】
幾つかの実施形態にしたがって、システム１３００はさらに、通信スケジュールを含むＲＴＲパケットを送信するための論理モジュール１３１２と、ＲＴＲパケットが送信されたことに応答して、ＲＣパケットを受信するための論理モジュール１３１４とを含む。さらにまた、更新されたＲＣパケットをソース・デバイスへ送信するための論理モジュール１３１６と、ＲＣパケットが送信されたことに応答して、ソース・デバイスからＲＣパケットを受信するための論理モジュール１３１８ともまた含まれうる。
【０１０６】
例えば、装置は、近隣デバイス間で通信されるＲＣパケットを聞くための、論理モジュール１３０２でありうる手段と、ＲＣパケットに含まれる情報を用いて、中間デバイスの予約テーブルを更新するための、論理モジュール１３０４でありうる手段とを含むことができる。第１の中間デバイスにおいて、ソース・デバイスからＲＴＲパケットを受信するための、論理モジュール１３０６でありうる手段もまた含まれうる。このＲＴＲパケットは、ソース・デバイスの予約テーブルを含んでいる。この装置はさらに、更新された予約テーブルと、ソース・デバイスの予約テーブルとを分析するための、論理モジュール１３０８でありうる手段と、分析された予約テーブルに部分的に基づいて、宛先デバイスとソース・デバイスとの間の通信スケジュールを決定するための、論理モジュール１３１０でありうる手段ともまた含みうる。
【０１０７】
図１４に示すように、端末１４００の可能な構成の概念ブロック図が例示されている。当業者によって認識されるように、端末１４００の正確な構成は、具体的な用途および全体的な設計制約に依存して変わりうる。プロセッサ１４０２は、本明細書で開示されたシステムおよび方法を実現することができる。
【０１０８】
端末１４００は、アンテナ１４０６に接続されたフロント・エンド・トランシーバ１４０４を用いて実装されうる。ベース・バンド・プロセッサ１４０８が、トランシーバ１４０４に接続されうる。ベース・バンド・プロセッサ１４０８は、ソフトウェア・ベースのアーキテクチャ、あるいはその他のタイプのアーキテクチャを用いて実現されうる。マイクロプロセッサは、制御および全体的なシステム管理機能を提供するソフトウェア・プログラムを実行させるためのプラットフォームとして利用されうる。デジタル信号プロセッサ（ＤＳＰ）が、組込式の通信ソフトウェア・レイヤとともに実装されうる。このプロセッサは、アプリケーション特有のアルゴリズムを実行して、マイクロプロセッサ上の処理要求を低減することができる。ＤＳＰは、例えば、パイロット信号獲得、時間同期、周波数追跡、スペクトラム拡散処理、変調および復調機能、および順方向誤り訂正のような様々な信号処理機能を提供するために利用されうる。
【０１０９】
端末１４００はまた、ベース・バンド・プロセッサ１４０８に接続された様々なユーザ・インタフェース１４１０を含むことも可能である。ユーザ・インタフェース１４１０は、キーパッド、マウス、タッチ・スクリーン、ディスプレイ、リンガ、バイブレータ、オーディオ・スピーカ、マイクロホン、カメラおよび／またはその他の入力／出力デバイスを含むことができる。
【０１１０】
ベース・バンド・プロセッサ１４０８は、プロセッサ１４０２を備える。ベース・バンド・プロセッサ１４０８のソフトウェア・ベースの実装では、プロセッサ１４０２は、マイクロプロセッサ上で動作するソフトウェア・プログラムでありうる。しかしながら、当業者であれば容易に認識するように、プロセッサ１４０２はこの実施形態には限定されず、本明細書に記載の様々な機能を実行することができる任意のハードウェア構成、ソフトウェア構成、またはこれらの組み合わせを含む当該技術で周知の任意の手段によって実現されうる。プロセッサ１４０２は、データ記憶用のメモリ１４１２に接続されうる。
【０１１１】
本明細書に記載の実施形態は、ハードウェア、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、あるいはこれらの任意の組み合わせによって実現されうることが理解されるべきである。これらシステムおよび／または方法が、ソフトウェア、ファームウェア、ミドルウェアまたマクロコード、プログラム・コードまたはコード・セグメントで実現される場合、例えば記憶素子のような機械読取可能媒体内に格納されうる。コード・セグメントは、手順、関数、サブプログラム、プログラム、ルーチン、サブルーチン、モジュール、ソフトウェア・パッケージ、クラス、あるいは命令群の任意の組み合わせ、データ構造、またはプログラム・ステートメントを示すことができる。コード・セグメントは、情報、データ、引数、パラメータ、あるいは記憶内容を渡したり、および／または、受信することによって、別のコード・セグメントまたはハードウェア回路に接続されうる。情報、引数、パラメータ、データ等は、メモリ共有、メッセージ引渡し、トークン引渡し、ネットワーク送信等を含む任意の適切な手段を用いて引渡し、転送、あるいは送信がなされうる。
【０１１２】
ソフトウェアで実現する場合、本明細書に記載の技術は、本明細書に記載の機能を実行するモジュール（例えば、手順、関数等）を用いて実現されうる。これらソフトウェア・コードは、メモリ・ユニット内に格納され、プロセッサによって実行されうる。メモリ・ユニットは、プロセッサ内に実装されるか、あるいはプロセッサの外部に実装される。プロセッサの外部に実装された場合、当該技術分野で周知の様々な手段によって、プロセッサに通信可能に接続されうる。
【０１１３】
上述したものは、１または複数の実施形態の例を含む。もちろん、上述した実施形態を記述する構成要素または方法の、考えられる全ての組み合わせを記述することは不可能であるが、当業者であれば、様々な実施形態のさらなる多くの組み合わせおよび置き換えが可能であることを認識するこができる。したがって、記述された実施形態は、特許請求の範囲の精神およびスコープ内にあるそのような変更、修正、および変形例の全てを含むものと意図される。さらに、用語「含む」が、詳細な説明または特許請求の範囲の何れか一方において用いられている限りにおいては、そのような用語は、用語「備える」が、特許請求の範囲において適用されている場合、「備える」と解釈されるのと同様に、包括的であると意図される。
【特許請求の範囲】
【請求項１】
アド・ホック・ネットワークにおいてサービス品質（ＱｏＳ）通信を確立する方法であって、
宛先デバイスへの経路を突き止めることと、
前記経路に沿って特定された少なくとも第１の中間デバイスへ、予約要求（ＲＴＲ）制御パケットを送ることと、
前記ＲＴＲ制御パケットに応答して、前記少なくとも第１の中間デバイスから、スケジュールを含む第１の予約確認（ＲＣ）パケットを受信することと、
前記第１のＲＣパケットに応答して、前記少なくとも第１の中間デバイスへ、第２のＲＣパケットを送信することと
を備える方法。
【請求項２】
前記ＲＴＲ制御パケットは、無線デバイスのための予約テーブルを備える請求項１に記載の方法。
【請求項３】
前記第１のＲＣパケットに応答して、前記少なくとも第１の中間デバイスへ、第２のＲＣパケットを送信することは、
無線デバイスの受信の干渉マージンを、前記ＲＣパケット内に含めることと、
前記無線デバイスの電力と、送信スケジュールとを、前記ＲＣパケットに追加することと
を備える請求項１に記載の方法。
【請求項４】
前記ＲＴＲ制御パケットと、前記第１のＲＣパケットおよび前記第２のＲＣパケットとは、共通のコードを用いて送信される請求項１に記載の方法。
【請求項５】
前記宛先デバイスへの経路を突き止めることは、前記宛先デバイスと無線デバイスとの間のセッションを確立するために、適切なリソースを備えた経路を選択することを備える請求項１に記載の方法。
【請求項６】
アド・ホック・ネットワークにおいてＱｏＳ通信を確立する装置であって、
宛先デバイスへの経路に含まれる第１のデバイスへ、予約要求（ＲＴＲ）制御パケットを送る送信機と、
前記ＲＴＲ制御パケットに応答して、第１の予約確認（ＲＣ）パケットを受信する受信機とを備え、
前記送信機は、前記第１のＲＣパケットに応答して、前記第１のデバイスへ第２のＲＣパケットを送信する装置。
【請求項７】
アクティブな近隣ノードに関する情報を備えたリソース予約テーブルをさらに備える請求項６に記載の装置。
【請求項８】
前記装置の受信の干渉マージンと、前記装置の電力と送信スケジュールとを、前記第２のＲＣパケット内に含めるコンフィギュラをさらに備える請求項６に記載の装置。
【請求項９】
近隣デバイスが前記パケットを聞くことができるように、前記送信機はさらに、前記ＲＴＲ制御パケットと前記第２のＲＣパケットとを共通のコードで送信する請求項６に記載の装置。
【請求項１０】
アド・ホック・ネットワークにおいてサービス品質（ＱｏＳ）通信を確立する装置であって、
宛先デバイスへの経路を決定する手段と、
予約テーブルを備えた予約要求（ＲＴＲ）パケットを第１のデバイスへ伝送する手段と、
前記ＲＴＲパケットが伝送されることに応答して、スケジュールを備えた予約確認（ＲＣ）パケットを受信する手段と、
前記ＲＣパケットを受信することに応答して、前記スケジュールを確認する応答ＲＣパケットを送る手段と
を備える装置。
【請求項１１】
近隣デバイス情報を含むリソース予約テーブルを保持する手段をさらに備える請求項１０に記載の装置。
【請求項１２】
前記ＲＴＲパケットを伝送する手段と、前記応答ＲＣパケットを送る手段とは、パケットを共通のコードで送る請求項１０に記載の装置。
【請求項１３】
アド・ホック・ネットワークにおいてサービス品質（ＱｏＳ）通信を確立する方法を組み込んだコンピュータ読取可能媒体であって、
前記方法は、
ソース・デバイスと宛先デバイスとの間の通信経路を決定することと、
前記通信経路に沿って位置する第１のデバイスに予約要求（ＲＴＲ）パケットを送信することと、
前記ＲＴＲパケットが送信されることに応じて、前記第１のデバイスから第１の予約確認（ＲＣ）パケットを受信することと、
前記第１のＲＣパケットで受信された情報を確認する第１のデバイスへ、第２のＲＣパケットを送信することと
を備えるコンピュータ読取可能媒体。
【請求項１４】
前記方法はさらに、前記ソース・デバイスの電力と送信スケジュールと受信の干渉マージンとを、前記第２のＲＣパケット内に含めることを備える請求項１３に記載のコンピュータ読取可能媒体。
【請求項１５】
前記ＲＴＲパケットおよび前記第２のＲＣパケットは、共通のコードで送信される請求項１３に記載のコンピュータ読取可能媒体。
【請求項１６】
アド・ホック・ネットワークにおいてサービス品質（ＱｏＳ）通信を確立するためのプロセッサであって、
ソース・デバイスと宛先デバイスとの間の通信経路を決定し、
前記通信経路上に位置する第１のデバイスへ、前記ソース・デバイスの予約テーブルを備える予約要求（ＲＴＲ）パケットを伝送し、
前記ＲＴＲパケットに応答して、前記ソース・デバイスのスケジュールを備えた予約確認（ＲＣ）パケットを受信し、
前記受信したＲＣパケットに含まれる前記スケジュールを確認する応答ＲＣパケットを送る
ように構成されたプロセッサ。
【請求項１７】
前記受信したＲＣパケットに含まれるスケジュール情報を用いて、前記ソース・デバイスの予約テーブルを更新するようにさらに構成された請求項１６に記載のプロセッサ。
【請求項１８】
前記応答ＲＣパケットを前記共通のコードを用いて送るようにさらに構成された請求項１６に記載のプロセッサ。
【請求項１９】
アド・ホック通信ネットワークにおいて通信をスケジューリングする方法であって、
少なくとも第１の無線デバイスから、予約要求（ＲＴＲ）パケットを受信することと、
前記少なくとも第１の無線デバイスから宛先デバイスへのスケジュールを決定することと、
前記少なくとも第１の無線デバイスと、前記宛先デバイスとの間の通信のための最も早いスケジュールを、許可制御ポリシーに基づいて選択することと、
前記宛先デバイスへＲＴＲパケットを送ることと、
前記ＲＴＲパケットに応答して、前記宛先デバイスからの予約確認（ＲＣ）パケットを受信することと、
通信スケジュールを含む前記ＲＣパケットを、前記少なくとも第１の無線デバイスへ送信することと
を備える方法。
【請求項２０】
前記少なくとも第１の無線デバイスからＲＴＲ制御パケットを受信した後、前記ＲＴＲパケットに、第１の中間デバイスの第１の予約テーブルと、前記少なくとも第１の無線デバイスの第２の予約テーブルとを追加することをさらに備える請求項１９に記載の方法。
【請求項２１】
前記少なくとも第１の無線デバイスから宛先デバイスへのスケジュールを決定することはさらに、前記スケジュールが、許可制御ポリシー条件に一致することを確認することを備える請求項１９に記載の方法。
【請求項２２】
前記許可制御ポリシー条件は、データ・レート、データ遅延、サービス品質、およびスケジュールされた送信のうちの少なくとも１つを含む請求項２１に記載の方法。
【請求項２３】
前記少なくとも第１の無線デバイスと前記宛先デバイスとの間の通信のための最も早いスケジュールを選択した後に、
少なくとも第１の中間デバイスの予約テーブルを更新することと、
前記ＲＴＲパケットに、前記少なくとも第１の中間デバイスの予約テーブルを追加することと
をさらに備える請求項１９に記載の方法。
【請求項２４】
前記ＲＴＲパケットを送り前記ＲＣパケットを送信するために、共通のコードを用いることをさらに備える請求項１９に記載の方法。
【請求項２５】
前記受信されたＲＴＲパケットは、アクティブなノード・スケジュール、干渉マージン、送信電力、および、ノード間の経路喪失のうちの少なくとも１つを含む予約テーブルを備える請求項１９に記載の方法。
【請求項２６】
アド・ホック通信ネットワークにおいて通信をスケジューリングする装置であって、
少なくとも第１のノードから予約要求（ＲＴＲ）制御パケットを受信する受信機と、
利用可能なスケジュールを分析し、ソース・ノードと宛先ノードとの間の通信のための最も早い通信スケジュールを、許可制御ポリシーに基づいて選択するスケジューラと、
前記最も早い通信スケジュールを含むＲＴＲパケットを、前記宛先ノードへ送信する送信機と
を備える装置。
【請求項２７】
前記受信機はさらに、前記ＲＴＲ制御パケットが送信されることに応じて、第１の予約確認（ＲＣ）パケットを受信し、前記送信機は、第２のＲＣパケットを、前記第１のノードに送る請求項２６に記載の装置。
【請求項２８】
前記第２のＲＣパケットに、前記通信スケジュールを追加するコンフィギュラをさらに備える請求項２７に記載の装置。
【請求項２９】
アクティブな近隣デバイスに関する情報を含む予約テーブルをさらに備え、前記予約テーブルは、前記通信スケジュールを用いて更新される請求項２６に記載の装置。
【請求項３０】
選択されたスケジュールが実現可能かどうかを判定する判定ポリシーをさらに備える請求項２６に記載の装置。
【請求項３１】
前記送信機は、前記ＲＴＲ制御パケットおよび前記第２のＲＣパケットを送信するために共通のコードを用いる請求項２６に記載の装置。
【請求項３２】
アド・ホック通信ネットワークにおいて通信をスケジューリングする装置であって、
ソース・デバイスから宛先デバイスへの経路を含む予約要求（ＲＴＲ）制御パケットを受信する手段と、
前記経路のために利用可能なスケジュールを分析する手段と、
最も早いスケジュールを選択する手段と、
前記最も早いスケジュールを含むＲＴＲ制御パケットを、前記宛先デバイスへ伝送する手段と
を備える装置。
【請求項３３】
第１の中間デバイスの第１の予約テーブルと、前記ソース・デバイスの第２の予約テーブルとを前記ＲＴＲ制御パケットに追加する手段をさらに備える請求項３２に記載の装置。
【請求項３４】
通信スケジュールを含む第１の予約確認（ＲＣ）パケットを前記宛先デバイスから受信する手段と、
前記ソース・デバイスへの通信スケジュールを含む第２のＲＣパケットを送る手段と
をさらに備える請求項３２に記載の装置。
【請求項３５】
超広帯域アド・ホック通信ネットワークにおいて通信をスケジュールする方法を組み込んだコンピュータ読取可能媒体であって、
前記方法は、
ソース・デバイスから宛先デバイスへの経路を含む予約要求（ＲＴＲ）制御パケットを受信することと、
前記経路のために利用可能なスケジュールを分析することと、
最も早いスケジュールを選択することと、
前記最も早いスケジュールを含むＲＴＲ制御パケットを、前記宛先デバイスへ伝送することと
を備えるコンピュータ読取可能媒体。
【請求項３６】
第１の中間デバイスの第１の予約テーブルと、前記ソース・デバイスの第２の予約テーブルとを前記ＲＴＲ制御パケットに追加することをさらに備える請求項３５に記載のコンピュータ読取可能媒体。
【請求項３７】
前記方法は、
通信スケジュールを含む第１のＲＣパケットを、前記宛先デバイスから受信することと、
前記通信スケジュールを含む第２のＲＣパケットを前記ソース・デバイスへ送ることと
をさらに備える請求項３５に記載のコンピュータ読取可能媒体。
【請求項３８】
アド・ホック通信ネットワークにおいて通信をスケジューリングするプロセッサであって、
少なくとも１つの第１の無線デバイスから予約要求（ＲＴＲ）制御パケットを受信し、
少なくとも１つの第１の無線デバイスから宛先デバイスへのスケジュールを、許可制御ポリシーに基づいて決定し、
前記少なくとも第１の無線デバイスと前記宛先デバイスとの間の通信のため、最も早いスケジュールを選び、
前記宛先デバイスへＲＴＲ制御パケットを送り、
前記ＲＴＲ制御パケットに応答して、前記宛先デバイスからＲＣパケットを受信し、
通信スケジュールを含む予約確認（ＲＣ）パケットを、前記少なくとも第１の無線デバイスへ送信する
ように構成されたプロセッサ。
【請求項３９】
第１の中間デバイスの第１の予約テーブルと、前記少なくとも第１の無線デバイスの第２の予約テーブルとを、前記ＲＴＲパケットに追加するようにさらに構成された請求項３８に記載のプロセッサ。
【請求項４０】
前記スケジュールが、許可制御ポリシー条件に一致することを確認するようにさらに構成された請求項３８に記載のプロセッサ。
【請求項４１】
アド・ホック通信をスケジューリングする方法であって、
通信スケジュールを含む予約要求（ＲＴＲ）パケットを、少なくとも第１のデバイスから受信することと、
許可制御ポリシーを利用し、前記通信スケジュールに部分的に基づいて、実現可能なスケジュールを決定することと、
前記実現可能なスケジュールを含む予約確認（ＲＣ）パケットを、前記少なくとも第１のデバイスへ送信することと
を備える方法。
【請求項４２】
実現可能なスケジュールを決定することはさらに、
近隣デバイスの通信と干渉しない通信をスケジュールすることと、
前記スケジュールされた通信が、進行中の通信が存在する場合に正しく進むことを判定することと、
前記スケジュールされた通信が、少なくとも、最小レートＲｍｉｎをサポートできると判定することと
を備える請求項４１に記載の方法。
【請求項４３】
近隣デバイスが、前記ＲＣパケットを聞くことができるように、前記ＲＣパケットを送信するために共通のコードを使用することをさらに備える請求項４１に記載の方法。
【請求項４４】
実現可能なスケジュールが決定されない場合、実現できないとの通知を、前記少なくとも第１のデバイスへ送ることをさらに備える請求項４１に記載の方法。
【請求項４５】
適切な通信範囲を得るレートで前記ＲＣパケットが送られる請求項４１に記載の方法。
【請求項４６】
前記通信スケジュールに部分的に基づいて、実現可能なスケジュールを決定することはさらに、
前記スケジュールのための少なくとも１つの条件を含む許可制御ポリシーへアクセスすることと、
前記少なくとも１つの条件を、前記実現可能なスケジュールに一致させることと、
前記実現可能なスケジュールが、前記少なくとも１つの条件と一致する場合、前記スケジュールを許可することと
を備える請求項４１に記載の方法。
【請求項４７】
超広帯域アド・ホック通信をスケジューリングする装置であって、
少なくとも第１のデバイスから、予約要求（ＲＴＲ）パケットを受信する受信機と、
前記ＲＴＲパケットに含まれる情報に部分的に基づいてスケジュールを決定するスケジューラと、
前記ＲＴＲパケットを受信することに応答して、前記スケジュールまたは前記スケジュールがのうちの１つが実現可能ではないことを含む予約確認（ＲＣ）パケットを送信する送信機と
を備える装置。
【請求項４８】
前記スケジュールを用いて更新されるリソース予約テーブルをさらに備える請求項４７に記載の装置。
【請求項４９】
前記送信機は、近隣デバイスによって聞くことができる前記ＲＣパケットを、共通のコードを使用して送信する請求項４７に記載の装置。
【請求項５０】
前記スケジュールが実現可能かどうかを、少なくとも１つのネットワーク条件に基づいて判定する制御ポリシーをさらに備える請求項４７に記載の装置。
【請求項５１】
前記送信機は、適切な通信範囲を得るレートで、前記ＲＣパケットを送信する請求項４７に記載の装置。
【請求項５２】
超広帯域アド・ホック通信をスケジューリングする装置であって、
予約要求（ＲＴＲ）パケットを受信する手段と、
スケジュールされた少なくとも１つの通信と干渉しないスケジュールを決定する手段と、
前記ＲＴＲパケットが受信されたことに応答して、前記スケジュールを含む予約確認（ＲＣ）パケットを送る手段と
を備える装置。
【請求項５３】
前記スケジュールを用いて予約テーブルを更新する手段をさらに備える請求項５２に記載の装置。
【請求項５４】
アド・ホック通信をスケジューリングする方法を組み込んだコンピュータ読取可能媒体であって、
前記方法は、
予約要求（ＲＴＲ）パケットを、少なくとも第１のデバイスから受信することと、
前記ＲＴＲパケットに含まれる情報に部分的に基づいてスケジュールを決定することと、
前記ＲＴＲパケットを受信することに応答して、前記スケジュールまたは前記スケジュールのうちの１つが実現不可能であることを含む予約確認（ＲＣ）パケットを送信することと
を備えるコンピュータ読取可能媒体。
【請求項５５】
前記方法はさらに、前記スケジュールを用いてリソース経路を更新することを備える請求項５４に記載のコンピュータ読取可能媒体。
【請求項５６】
近隣デバイスによって聞くことができる前記ＲＣパケットを、共通のコードで送ることをさらに備える請求項５４に記載のコンピュータ読取可能媒体。
【請求項５７】
前記方法はさらに、前記スケジュールが実現可能であるかを、少なくとも１つのネットワーク条件に基づいて判定することを備える請求項５４に記載のコンピュータ読取可能媒体。
【請求項５８】
アド・ホック通信をスケジューリングするためのプロセッサであって、
前記プロセッサは、
予約要求（ＲＴＲ）パケットを受信し、
スケジューリングされた少なくとも１つの通信と干渉しないスケジュールを決定し、
前記ＲＴＲパケットが受信されたことに応答して、前記スケジュールを含む予約確認（ＲＣ）パケットを送る
ように構成されたプロセッサ。
【請求項５９】
前記スケジュールを用いて予約テーブルを更新するようにさらに構成された請求項５８に記載のプロセッサ。
【請求項６０】
マルチホップ・アド・ホック・ネットワークにおいて通信をスケジューリングする方法であって、
近隣デバイス間で通信された予約確認（ＲＣ）パケットを聞くことと、
前記ＲＣパケットに含まれる情報を用いて、中間デバイスの予約テーブルを更新することと、
ソース・デバイスの予約テーブルを含む予約要求（ＲＴＲ）パケットを、第１の中間デバイスにおいて、前記ソース・デバイスから受信することと、
前記更新された予約テーブルと前記ソース・デバイスからの予約テーブルとを分析することと、
前記分析された予約テーブルに部分的に基づいて、前記ソース・デバイスと宛先デバイスとの間の通信スケジュールを決定することと
を備える方法。
【請求項６１】
前記通信スケジュールを含むＲＴＲパケットを、少なくとも第２の中間デバイスへ送ることと、
前記ＲＴＲパケットが送られたことに応答して、ＲＣパケットを受信することと、
更新されたＲＣパケットを、前記ソース・デバイスへ送ることと、
前記ＲＣパケットが送信されたことに応答して、前記ソース・デバイスからＲＣパケットを受信することと
をさらに備える請求項６０に記載の方法。
【請求項６２】
前記ＲＴＲパケットを送る前に、前記少なくとも第２の中間デバイスが、ビジーではなくなるまで待機することをさらに備える請求項６０に記載の方法。
【請求項６３】
近隣ノード間で通信されたＲＣパケットを聞くことは共通のコード上である請求項６０に記載の方法。
【請求項６４】
近隣デバイス間で通信されたＲＣパケットを聞くことはさらに、スケジュール、干渉マージン、送信電力、およびノード間の経路喪失のうちの少なくとも１つを用いて、前記ソース・デバイスの予約テーブルを更新することを備える請求項６０に記載の方法。
【請求項６５】
前記ＲＴＲパケットが、スケジュールされた送信と干渉しない場合、前記ＲＴＲパケットが、少なくとも第２の中間デバイスへ送られる請求項６０に記載の方法。
【請求項６６】
マルチホップ・アド・ホック・ネットワークにおいて通信をスケジューリングする装置であって、
アクティブな近隣ノード間で生じる通信を監視するオブザーバと、
前記監視された通信に含まれる情報を用いてリソース予約テーブルを更新するコンフィギュラと、
ソース・デバイスと宛先デバイスとの間の経路を含む予約要求（ＲＴＲ）パケットを、前記ソース・デバイスから受信する受信機と、
前記ソース・デバイスから前記宛先デバイスへの経路に沿って通信をスケジュールするスケジューラと
を備える装置。
【請求項６７】
前記スケジュールされた通信を含む通信を、少なくとも第２の中間デバイスへ送信する送信機をさらに備え、
前記受信機は、前記通信が送信されたことに応答して、前記少なくとも第２の中間デバイスからの通信を受信し、
前記コンフィギュラは、前記受信された通信に含まれる情報を用いて、前記リソース予約テーブルを更新する請求項６６に記載の装置。
【請求項６８】
前記送信機は、近隣デバイスによって聞かれる通信を、共通のコードを用いて送る請求項６６に記載の装置。
【請求項６９】
マルチホップ・アド・ホック・ネットワークにおいて通信をスケジューリングする装置であって、
近隣デバイス間で通信された予約確認（ＲＣ）パケットを聞く手段と、
前記ＲＣパケットに含まれる情報を用いて、中間デバイスの予約テーブルを更新する手段と、
前記ソース・デバイスの予約テーブルを含む予約要求（ＲＴＲ）パケットを、第１の中間デバイスにおいて、ソース・デバイスから受信する手段と、
前記更新された予約テーブルと前記ソース・デバイスからの予約テーブルとを分析する手段と、
前記分析された予約テーブルに部分的に基づいて、前記ソース・デバイスと宛先デバイスとの間の通信スケジュールを決定する手段と
を備える装置。
【請求項７０】
前記通信スケジュールを含むＲＴＲパケットを、少なくとも第２の中間デバイスへ送る手段と、
前記ＲＴＲパケットが送られたことに応答して、ＲＣパケットを受信する手段と、
更新されたＲＣパケットを、前記ソース・デバイスへ送る手段と、
前記ＲＣパケットが送信されたことに応答して、前記ソース・デバイスからＲＣパケットを受信する手段と
をさらに備える請求項６９に記載の装置、
【請求項７１】
マルチホップ・アド・ホック・ネットワークにおいて通信をスケジューリングする方法を組み込んだコンピュータ読取可能媒体であって、
前記方法は、
アクティブな近隣ノード間で生じる通信を監視することと、
前記監視された通信に含まれる情報を用いてリソース予約テーブルを更新することと、
ソース・デバイスと宛先デバイスとの間の経路を含む予約要求（ＲＴＲ）パケットを、前記ソース・デバイスから受信することと、
前記ソース・デバイスから前記宛先デバイスへの経路に沿って通信をスケジュールすることと
を備えるコンピュータ読取可能媒体。
【請求項７２】
前記スケジュールされた通信を含む通信を、少なくとも第２の中間デバイスへ送信することと、
前記通信が送信されたことに応答して、前記少なくとも第２の中間デバイスからの通信を受信することと、
前記受信された通信に含まれる情報を用いて、前記リソース予約テーブルを更新することと
をさらに備える請求項７１に記載のコンピュータ読取可能媒体。
【請求項７３】
マルチホップ・アド・ホック・ネットワークにおいて通信をスケジューリングするためのプロセッサであって、
前記プロセッサは、
近隣デバイス間で通信された予約確認（ＲＣ）パケットを聞き、
前記ＲＣパケットに含まれる情報を用いて、中間デバイスの予約テーブルを更新し、
前記ソース・デバイスの予約テーブルを含む予約要求（ＲＴＲ）パケットを、第１の中間デバイスにおいて、ソース・デバイスから受信し、
前記更新された予約テーブルと前記ソース・デバイスからの予約テーブルとを分析し、
前記分析された予約テーブルに部分的に基づいて、前記ソース・デバイスと宛先デバイスとの間の通信スケジュールを決定する
ように構成されたプロセッサ。
【請求項７４】
前記通信スケジュールを含むＲＴＲパケットを、少なくとも第２の中間デバイスへ送り、
前記ＲＴＲパケットが送られたことに応答して、ＲＣパケットを受信し、
更新されたＲＣパケットを、前記ソース・デバイスへ送り、
前記ＲＣパケットが送信されたことに応答して、前記ソース・デバイスからＲＣパケットを受信する
ようにさらに構成された請求項７３に記載のプロセッサ。
【請求項１】
アド・ホック・ネットワークにおいてサービス品質（ＱｏＳ）通信を確立する方法であって、
宛先デバイスへの経路を突き止めることと、
前記経路に沿って特定された少なくとも第１の中間デバイスへ、予約要求（ＲＴＲ）制御パケットを送ることと、
前記ＲＴＲ制御パケットに応答して、前記少なくとも第１の中間デバイスから、スケジュールを含む第１の予約確認（ＲＣ）パケットを受信することと、
前記第１のＲＣパケットに応答して、前記少なくとも第１の中間デバイスへ、第２のＲＣパケットを送信することと
を備える方法。
【請求項２】
前記ＲＴＲ制御パケットは、無線デバイスのための予約テーブルを備える請求項１に記載の方法。
【請求項３】
前記第１のＲＣパケットに応答して、前記少なくとも第１の中間デバイスへ、第２のＲＣパケットを送信することは、
無線デバイスの受信の干渉マージンを、前記ＲＣパケット内に含めることと、
前記無線デバイスの電力と、送信スケジュールとを、前記ＲＣパケットに追加することと
を備える請求項１に記載の方法。
【請求項４】
前記ＲＴＲ制御パケットと、前記第１のＲＣパケットおよび前記第２のＲＣパケットとは、共通のコードを用いて送信される請求項１に記載の方法。
【請求項５】
前記宛先デバイスへの経路を突き止めることは、前記宛先デバイスと無線デバイスとの間のセッションを確立するために、適切なリソースを備えた経路を選択することを備える請求項１に記載の方法。
【請求項６】
アド・ホック・ネットワークにおいてＱｏＳ通信を確立する装置であって、
宛先デバイスへの経路に含まれる第１のデバイスへ、予約要求（ＲＴＲ）制御パケットを送る送信機と、
前記ＲＴＲ制御パケットに応答して、第１の予約確認（ＲＣ）パケットを受信する受信機とを備え、
前記送信機は、前記第１のＲＣパケットに応答して、前記第１のデバイスへ第２のＲＣパケットを送信する装置。
【請求項７】
アクティブな近隣ノードに関する情報を備えたリソース予約テーブルをさらに備える請求項６に記載の装置。
【請求項８】
前記装置の受信の干渉マージンと、前記装置の電力と送信スケジュールとを、前記第２のＲＣパケット内に含めるコンフィギュラをさらに備える請求項６に記載の装置。
【請求項９】
近隣デバイスが前記パケットを聞くことができるように、前記送信機はさらに、前記ＲＴＲ制御パケットと前記第２のＲＣパケットとを共通のコードで送信する請求項６に記載の装置。
【請求項１０】
アド・ホック・ネットワークにおいてサービス品質（ＱｏＳ）通信を確立する装置であって、
宛先デバイスへの経路を決定する手段と、
予約テーブルを備えた予約要求（ＲＴＲ）パケットを第１のデバイスへ伝送する手段と、
前記ＲＴＲパケットが伝送されることに応答して、スケジュールを備えた予約確認（ＲＣ）パケットを受信する手段と、
前記ＲＣパケットを受信することに応答して、前記スケジュールを確認する応答ＲＣパケットを送る手段と
を備える装置。
【請求項１１】
近隣デバイス情報を含むリソース予約テーブルを保持する手段をさらに備える請求項１０に記載の装置。
【請求項１２】
前記ＲＴＲパケットを伝送する手段と、前記応答ＲＣパケットを送る手段とは、パケットを共通のコードで送る請求項１０に記載の装置。
【請求項１３】
アド・ホック・ネットワークにおいてサービス品質（ＱｏＳ）通信を確立する方法を組み込んだコンピュータ読取可能媒体であって、
前記方法は、
ソース・デバイスと宛先デバイスとの間の通信経路を決定することと、
前記通信経路に沿って位置する第１のデバイスに予約要求（ＲＴＲ）パケットを送信することと、
前記ＲＴＲパケットが送信されることに応じて、前記第１のデバイスから第１の予約確認（ＲＣ）パケットを受信することと、
前記第１のＲＣパケットで受信された情報を確認する第１のデバイスへ、第２のＲＣパケットを送信することと
を備えるコンピュータ読取可能媒体。
【請求項１４】
前記方法はさらに、前記ソース・デバイスの電力と送信スケジュールと受信の干渉マージンとを、前記第２のＲＣパケット内に含めることを備える請求項１３に記載のコンピュータ読取可能媒体。
【請求項１５】
前記ＲＴＲパケットおよび前記第２のＲＣパケットは、共通のコードで送信される請求項１３に記載のコンピュータ読取可能媒体。
【請求項１６】
アド・ホック・ネットワークにおいてサービス品質（ＱｏＳ）通信を確立するためのプロセッサであって、
ソース・デバイスと宛先デバイスとの間の通信経路を決定し、
前記通信経路上に位置する第１のデバイスへ、前記ソース・デバイスの予約テーブルを備える予約要求（ＲＴＲ）パケットを伝送し、
前記ＲＴＲパケットに応答して、前記ソース・デバイスのスケジュールを備えた予約確認（ＲＣ）パケットを受信し、
前記受信したＲＣパケットに含まれる前記スケジュールを確認する応答ＲＣパケットを送る
ように構成されたプロセッサ。
【請求項１７】
前記受信したＲＣパケットに含まれるスケジュール情報を用いて、前記ソース・デバイスの予約テーブルを更新するようにさらに構成された請求項１６に記載のプロセッサ。
【請求項１８】
前記応答ＲＣパケットを前記共通のコードを用いて送るようにさらに構成された請求項１６に記載のプロセッサ。
【請求項１９】
アド・ホック通信ネットワークにおいて通信をスケジューリングする方法であって、
少なくとも第１の無線デバイスから、予約要求（ＲＴＲ）パケットを受信することと、
前記少なくとも第１の無線デバイスから宛先デバイスへのスケジュールを決定することと、
前記少なくとも第１の無線デバイスと、前記宛先デバイスとの間の通信のための最も早いスケジュールを、許可制御ポリシーに基づいて選択することと、
前記宛先デバイスへＲＴＲパケットを送ることと、
前記ＲＴＲパケットに応答して、前記宛先デバイスからの予約確認（ＲＣ）パケットを受信することと、
通信スケジュールを含む前記ＲＣパケットを、前記少なくとも第１の無線デバイスへ送信することと
を備える方法。
【請求項２０】
前記少なくとも第１の無線デバイスからＲＴＲ制御パケットを受信した後、前記ＲＴＲパケットに、第１の中間デバイスの第１の予約テーブルと、前記少なくとも第１の無線デバイスの第２の予約テーブルとを追加することをさらに備える請求項１９に記載の方法。
【請求項２１】
前記少なくとも第１の無線デバイスから宛先デバイスへのスケジュールを決定することはさらに、前記スケジュールが、許可制御ポリシー条件に一致することを確認することを備える請求項１９に記載の方法。
【請求項２２】
前記許可制御ポリシー条件は、データ・レート、データ遅延、サービス品質、およびスケジュールされた送信のうちの少なくとも１つを含む請求項２１に記載の方法。
【請求項２３】
前記少なくとも第１の無線デバイスと前記宛先デバイスとの間の通信のための最も早いスケジュールを選択した後に、
少なくとも第１の中間デバイスの予約テーブルを更新することと、
前記ＲＴＲパケットに、前記少なくとも第１の中間デバイスの予約テーブルを追加することと
をさらに備える請求項１９に記載の方法。
【請求項２４】
前記ＲＴＲパケットを送り前記ＲＣパケットを送信するために、共通のコードを用いることをさらに備える請求項１９に記載の方法。
【請求項２５】
前記受信されたＲＴＲパケットは、アクティブなノード・スケジュール、干渉マージン、送信電力、および、ノード間の経路喪失のうちの少なくとも１つを含む予約テーブルを備える請求項１９に記載の方法。
【請求項２６】
アド・ホック通信ネットワークにおいて通信をスケジューリングする装置であって、
少なくとも第１のノードから予約要求（ＲＴＲ）制御パケットを受信する受信機と、
利用可能なスケジュールを分析し、ソース・ノードと宛先ノードとの間の通信のための最も早い通信スケジュールを、許可制御ポリシーに基づいて選択するスケジューラと、
前記最も早い通信スケジュールを含むＲＴＲパケットを、前記宛先ノードへ送信する送信機と
を備える装置。
【請求項２７】
前記受信機はさらに、前記ＲＴＲ制御パケットが送信されることに応じて、第１の予約確認（ＲＣ）パケットを受信し、前記送信機は、第２のＲＣパケットを、前記第１のノードに送る請求項２６に記載の装置。
【請求項２８】
前記第２のＲＣパケットに、前記通信スケジュールを追加するコンフィギュラをさらに備える請求項２７に記載の装置。
【請求項２９】
アクティブな近隣デバイスに関する情報を含む予約テーブルをさらに備え、前記予約テーブルは、前記通信スケジュールを用いて更新される請求項２６に記載の装置。
【請求項３０】
選択されたスケジュールが実現可能かどうかを判定する判定ポリシーをさらに備える請求項２６に記載の装置。
【請求項３１】
前記送信機は、前記ＲＴＲ制御パケットおよび前記第２のＲＣパケットを送信するために共通のコードを用いる請求項２６に記載の装置。
【請求項３２】
アド・ホック通信ネットワークにおいて通信をスケジューリングする装置であって、
ソース・デバイスから宛先デバイスへの経路を含む予約要求（ＲＴＲ）制御パケットを受信する手段と、
前記経路のために利用可能なスケジュールを分析する手段と、
最も早いスケジュールを選択する手段と、
前記最も早いスケジュールを含むＲＴＲ制御パケットを、前記宛先デバイスへ伝送する手段と
を備える装置。
【請求項３３】
第１の中間デバイスの第１の予約テーブルと、前記ソース・デバイスの第２の予約テーブルとを前記ＲＴＲ制御パケットに追加する手段をさらに備える請求項３２に記載の装置。
【請求項３４】
通信スケジュールを含む第１の予約確認（ＲＣ）パケットを前記宛先デバイスから受信する手段と、
前記ソース・デバイスへの通信スケジュールを含む第２のＲＣパケットを送る手段と
をさらに備える請求項３２に記載の装置。
【請求項３５】
超広帯域アド・ホック通信ネットワークにおいて通信をスケジュールする方法を組み込んだコンピュータ読取可能媒体であって、
前記方法は、
ソース・デバイスから宛先デバイスへの経路を含む予約要求（ＲＴＲ）制御パケットを受信することと、
前記経路のために利用可能なスケジュールを分析することと、
最も早いスケジュールを選択することと、
前記最も早いスケジュールを含むＲＴＲ制御パケットを、前記宛先デバイスへ伝送することと
を備えるコンピュータ読取可能媒体。
【請求項３６】
第１の中間デバイスの第１の予約テーブルと、前記ソース・デバイスの第２の予約テーブルとを前記ＲＴＲ制御パケットに追加することをさらに備える請求項３５に記載のコンピュータ読取可能媒体。
【請求項３７】
前記方法は、
通信スケジュールを含む第１のＲＣパケットを、前記宛先デバイスから受信することと、
前記通信スケジュールを含む第２のＲＣパケットを前記ソース・デバイスへ送ることと
をさらに備える請求項３５に記載のコンピュータ読取可能媒体。
【請求項３８】
アド・ホック通信ネットワークにおいて通信をスケジューリングするプロセッサであって、
少なくとも１つの第１の無線デバイスから予約要求（ＲＴＲ）制御パケットを受信し、
少なくとも１つの第１の無線デバイスから宛先デバイスへのスケジュールを、許可制御ポリシーに基づいて決定し、
前記少なくとも第１の無線デバイスと前記宛先デバイスとの間の通信のため、最も早いスケジュールを選び、
前記宛先デバイスへＲＴＲ制御パケットを送り、
前記ＲＴＲ制御パケットに応答して、前記宛先デバイスからＲＣパケットを受信し、
通信スケジュールを含む予約確認（ＲＣ）パケットを、前記少なくとも第１の無線デバイスへ送信する
ように構成されたプロセッサ。
【請求項３９】
第１の中間デバイスの第１の予約テーブルと、前記少なくとも第１の無線デバイスの第２の予約テーブルとを、前記ＲＴＲパケットに追加するようにさらに構成された請求項３８に記載のプロセッサ。
【請求項４０】
前記スケジュールが、許可制御ポリシー条件に一致することを確認するようにさらに構成された請求項３８に記載のプロセッサ。
【請求項４１】
アド・ホック通信をスケジューリングする方法であって、
通信スケジュールを含む予約要求（ＲＴＲ）パケットを、少なくとも第１のデバイスから受信することと、
許可制御ポリシーを利用し、前記通信スケジュールに部分的に基づいて、実現可能なスケジュールを決定することと、
前記実現可能なスケジュールを含む予約確認（ＲＣ）パケットを、前記少なくとも第１のデバイスへ送信することと
を備える方法。
【請求項４２】
実現可能なスケジュールを決定することはさらに、
近隣デバイスの通信と干渉しない通信をスケジュールすることと、
前記スケジュールされた通信が、進行中の通信が存在する場合に正しく進むことを判定することと、
前記スケジュールされた通信が、少なくとも、最小レートＲｍｉｎをサポートできると判定することと
を備える請求項４１に記載の方法。
【請求項４３】
近隣デバイスが、前記ＲＣパケットを聞くことができるように、前記ＲＣパケットを送信するために共通のコードを使用することをさらに備える請求項４１に記載の方法。
【請求項４４】
実現可能なスケジュールが決定されない場合、実現できないとの通知を、前記少なくとも第１のデバイスへ送ることをさらに備える請求項４１に記載の方法。
【請求項４５】
適切な通信範囲を得るレートで前記ＲＣパケットが送られる請求項４１に記載の方法。
【請求項４６】
前記通信スケジュールに部分的に基づいて、実現可能なスケジュールを決定することはさらに、
前記スケジュールのための少なくとも１つの条件を含む許可制御ポリシーへアクセスすることと、
前記少なくとも１つの条件を、前記実現可能なスケジュールに一致させることと、
前記実現可能なスケジュールが、前記少なくとも１つの条件と一致する場合、前記スケジュールを許可することと
を備える請求項４１に記載の方法。
【請求項４７】
超広帯域アド・ホック通信をスケジューリングする装置であって、
少なくとも第１のデバイスから、予約要求（ＲＴＲ）パケットを受信する受信機と、
前記ＲＴＲパケットに含まれる情報に部分的に基づいてスケジュールを決定するスケジューラと、
前記ＲＴＲパケットを受信することに応答して、前記スケジュールまたは前記スケジュールがのうちの１つが実現可能ではないことを含む予約確認（ＲＣ）パケットを送信する送信機と
を備える装置。
【請求項４８】
前記スケジュールを用いて更新されるリソース予約テーブルをさらに備える請求項４７に記載の装置。
【請求項４９】
前記送信機は、近隣デバイスによって聞くことができる前記ＲＣパケットを、共通のコードを使用して送信する請求項４７に記載の装置。
【請求項５０】
前記スケジュールが実現可能かどうかを、少なくとも１つのネットワーク条件に基づいて判定する制御ポリシーをさらに備える請求項４７に記載の装置。
【請求項５１】
前記送信機は、適切な通信範囲を得るレートで、前記ＲＣパケットを送信する請求項４７に記載の装置。
【請求項５２】
超広帯域アド・ホック通信をスケジューリングする装置であって、
予約要求（ＲＴＲ）パケットを受信する手段と、
スケジュールされた少なくとも１つの通信と干渉しないスケジュールを決定する手段と、
前記ＲＴＲパケットが受信されたことに応答して、前記スケジュールを含む予約確認（ＲＣ）パケットを送る手段と
を備える装置。
【請求項５３】
前記スケジュールを用いて予約テーブルを更新する手段をさらに備える請求項５２に記載の装置。
【請求項５４】
アド・ホック通信をスケジューリングする方法を組み込んだコンピュータ読取可能媒体であって、
前記方法は、
予約要求（ＲＴＲ）パケットを、少なくとも第１のデバイスから受信することと、
前記ＲＴＲパケットに含まれる情報に部分的に基づいてスケジュールを決定することと、
前記ＲＴＲパケットを受信することに応答して、前記スケジュールまたは前記スケジュールのうちの１つが実現不可能であることを含む予約確認（ＲＣ）パケットを送信することと
を備えるコンピュータ読取可能媒体。
【請求項５５】
前記方法はさらに、前記スケジュールを用いてリソース経路を更新することを備える請求項５４に記載のコンピュータ読取可能媒体。
【請求項５６】
近隣デバイスによって聞くことができる前記ＲＣパケットを、共通のコードで送ることをさらに備える請求項５４に記載のコンピュータ読取可能媒体。
【請求項５７】
前記方法はさらに、前記スケジュールが実現可能であるかを、少なくとも１つのネットワーク条件に基づいて判定することを備える請求項５４に記載のコンピュータ読取可能媒体。
【請求項５８】
アド・ホック通信をスケジューリングするためのプロセッサであって、
前記プロセッサは、
予約要求（ＲＴＲ）パケットを受信し、
スケジューリングされた少なくとも１つの通信と干渉しないスケジュールを決定し、
前記ＲＴＲパケットが受信されたことに応答して、前記スケジュールを含む予約確認（ＲＣ）パケットを送る
ように構成されたプロセッサ。
【請求項５９】
前記スケジュールを用いて予約テーブルを更新するようにさらに構成された請求項５８に記載のプロセッサ。
【請求項６０】
マルチホップ・アド・ホック・ネットワークにおいて通信をスケジューリングする方法であって、
近隣デバイス間で通信された予約確認（ＲＣ）パケットを聞くことと、
前記ＲＣパケットに含まれる情報を用いて、中間デバイスの予約テーブルを更新することと、
ソース・デバイスの予約テーブルを含む予約要求（ＲＴＲ）パケットを、第１の中間デバイスにおいて、前記ソース・デバイスから受信することと、
前記更新された予約テーブルと前記ソース・デバイスからの予約テーブルとを分析することと、
前記分析された予約テーブルに部分的に基づいて、前記ソース・デバイスと宛先デバイスとの間の通信スケジュールを決定することと
を備える方法。
【請求項６１】
前記通信スケジュールを含むＲＴＲパケットを、少なくとも第２の中間デバイスへ送ることと、
前記ＲＴＲパケットが送られたことに応答して、ＲＣパケットを受信することと、
更新されたＲＣパケットを、前記ソース・デバイスへ送ることと、
前記ＲＣパケットが送信されたことに応答して、前記ソース・デバイスからＲＣパケットを受信することと
をさらに備える請求項６０に記載の方法。
【請求項６２】
前記ＲＴＲパケットを送る前に、前記少なくとも第２の中間デバイスが、ビジーではなくなるまで待機することをさらに備える請求項６０に記載の方法。
【請求項６３】
近隣ノード間で通信されたＲＣパケットを聞くことは共通のコード上である請求項６０に記載の方法。
【請求項６４】
近隣デバイス間で通信されたＲＣパケットを聞くことはさらに、スケジュール、干渉マージン、送信電力、およびノード間の経路喪失のうちの少なくとも１つを用いて、前記ソース・デバイスの予約テーブルを更新することを備える請求項６０に記載の方法。
【請求項６５】
前記ＲＴＲパケットが、スケジュールされた送信と干渉しない場合、前記ＲＴＲパケットが、少なくとも第２の中間デバイスへ送られる請求項６０に記載の方法。
【請求項６６】
マルチホップ・アド・ホック・ネットワークにおいて通信をスケジューリングする装置であって、
アクティブな近隣ノード間で生じる通信を監視するオブザーバと、
前記監視された通信に含まれる情報を用いてリソース予約テーブルを更新するコンフィギュラと、
ソース・デバイスと宛先デバイスとの間の経路を含む予約要求（ＲＴＲ）パケットを、前記ソース・デバイスから受信する受信機と、
前記ソース・デバイスから前記宛先デバイスへの経路に沿って通信をスケジュールするスケジューラと
を備える装置。
【請求項６７】
前記スケジュールされた通信を含む通信を、少なくとも第２の中間デバイスへ送信する送信機をさらに備え、
前記受信機は、前記通信が送信されたことに応答して、前記少なくとも第２の中間デバイスからの通信を受信し、
前記コンフィギュラは、前記受信された通信に含まれる情報を用いて、前記リソース予約テーブルを更新する請求項６６に記載の装置。
【請求項６８】
前記送信機は、近隣デバイスによって聞かれる通信を、共通のコードを用いて送る請求項６６に記載の装置。
【請求項６９】
マルチホップ・アド・ホック・ネットワークにおいて通信をスケジューリングする装置であって、
近隣デバイス間で通信された予約確認（ＲＣ）パケットを聞く手段と、
前記ＲＣパケットに含まれる情報を用いて、中間デバイスの予約テーブルを更新する手段と、
前記ソース・デバイスの予約テーブルを含む予約要求（ＲＴＲ）パケットを、第１の中間デバイスにおいて、ソース・デバイスから受信する手段と、
前記更新された予約テーブルと前記ソース・デバイスからの予約テーブルとを分析する手段と、
前記分析された予約テーブルに部分的に基づいて、前記ソース・デバイスと宛先デバイスとの間の通信スケジュールを決定する手段と
を備える装置。
【請求項７０】
前記通信スケジュールを含むＲＴＲパケットを、少なくとも第２の中間デバイスへ送る手段と、
前記ＲＴＲパケットが送られたことに応答して、ＲＣパケットを受信する手段と、
更新されたＲＣパケットを、前記ソース・デバイスへ送る手段と、
前記ＲＣパケットが送信されたことに応答して、前記ソース・デバイスからＲＣパケットを受信する手段と
をさらに備える請求項６９に記載の装置、
【請求項７１】
マルチホップ・アド・ホック・ネットワークにおいて通信をスケジューリングする方法を組み込んだコンピュータ読取可能媒体であって、
前記方法は、
アクティブな近隣ノード間で生じる通信を監視することと、
前記監視された通信に含まれる情報を用いてリソース予約テーブルを更新することと、
ソース・デバイスと宛先デバイスとの間の経路を含む予約要求（ＲＴＲ）パケットを、前記ソース・デバイスから受信することと、
前記ソース・デバイスから前記宛先デバイスへの経路に沿って通信をスケジュールすることと
を備えるコンピュータ読取可能媒体。
【請求項７２】
前記スケジュールされた通信を含む通信を、少なくとも第２の中間デバイスへ送信することと、
前記通信が送信されたことに応答して、前記少なくとも第２の中間デバイスからの通信を受信することと、
前記受信された通信に含まれる情報を用いて、前記リソース予約テーブルを更新することと
をさらに備える請求項７１に記載のコンピュータ読取可能媒体。
【請求項７３】
マルチホップ・アド・ホック・ネットワークにおいて通信をスケジューリングするためのプロセッサであって、
前記プロセッサは、
近隣デバイス間で通信された予約確認（ＲＣ）パケットを聞き、
前記ＲＣパケットに含まれる情報を用いて、中間デバイスの予約テーブルを更新し、
前記ソース・デバイスの予約テーブルを含む予約要求（ＲＴＲ）パケットを、第１の中間デバイスにおいて、ソース・デバイスから受信し、
前記更新された予約テーブルと前記ソース・デバイスからの予約テーブルとを分析し、
前記分析された予約テーブルに部分的に基づいて、前記ソース・デバイスと宛先デバイスとの間の通信スケジュールを決定する
ように構成されたプロセッサ。
【請求項７４】
前記通信スケジュールを含むＲＴＲパケットを、少なくとも第２の中間デバイスへ送り、
前記ＲＴＲパケットが送られたことに応答して、ＲＣパケットを受信し、
更新されたＲＣパケットを、前記ソース・デバイスへ送り、
前記ＲＣパケットが送信されたことに応答して、前記ソース・デバイスからＲＣパケットを受信する
ようにさらに構成された請求項７３に記載のプロセッサ。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【公開番号】特開２０１２−１７８８４５（Ｐ２０１２−１７８８４５Ａ）
【公開日】平成２４年９月１３日（２０１２．９．１３）
【国際特許分類】
【外国語出願】
【出願番号】特願２０１２−８９１８９（Ｐ２０１２−８９１８９）
【出願日】平成２４年４月１０日（２０１２．４．１０）
【分割の表示】特願２００９−５１８６０３（Ｐ２００９−５１８６０３）の分割
【原出願日】平成１９年７月２日（２００７．７．２）
【出願人】（５９５０２０６４３）クゥアルコム・インコーポレイテッド (7,166)
【氏名又は名称原語表記】ＱＵＡＬＣＯＭＭ ＩＮＣＯＲＰＯＲＡＴＥＤ
【Ｆターム（参考）】
【公開日】平成２４年９月１３日（２０１２．９．１３）
【国際特許分類】
【出願番号】特願２０１２−８９１８９（Ｐ２０１２−８９１８９）
【出願日】平成２４年４月１０日（２０１２．４．１０）
【分割の表示】特願２００９−５１８６０３（Ｐ２００９−５１８６０３）の分割
【原出願日】平成１９年７月２日（２００７．７．２）
【出願人】（５９５０２０６４３）クゥアルコム・インコーポレイテッド (7,166)
【氏名又は名称原語表記】ＱＵＡＬＣＯＭＭ ＩＮＣＯＲＰＯＲＡＴＥＤ
【Ｆターム（参考）】
[ Back to top ]