(57)【要約】巡回ビーコンを用いてリモート・デバイスがワイヤレス・ネットワークを監視し、そのネットワークと通信するための方法を提供する。リモート・デバイスは、ビーコンを受信する（１４０５）。このビーコンは、スーパーフレームを規定するビーコン情報を含む。ビーコン情報から、リモート・デバイスは、受信したビーコンおよび関連するスーパーフレームがネットワーク・デバイスに割り当てられているか、または未割り当てか判定を行う（１４１０）。ネットワーク内で許容されているデバイスと同じ数のビーコンを受信することにより、リモート・デバイスは、ネットワークが満杯か否か判断することができる（１４３０）。リモート・デバイスがビーコンの全てを調べ、それに関連するスーパーフレームが割り当てられていることをその全てのビーコンが示す場合、リモート・デバイスは、ネットワークが満杯であると判断し、ネットワーク満杯機能を実行する。リモート・デバイスが受信したビーコンが、それに関連するスーパーフレームが未割り当てであることを示す場合、ネットワークは満杯でないと判断し、未割り当てのスーパーフレームの間にアソシエーション要求を行う（１４１５）。
2005538574.tif 000002
【特許請求の範囲】
【請求項１】
リモート・デバイスが、ワイヤレス・ネットワークを監視し、そのネットワークと通信する方法であって、
前記リモート・デバイスにおいてスーパーフレームを規定するビーコン情報を含むビーコンを受信し、
前記ビーコン情報から、前記受信したビーコンおよび関連するスーパーフレームがネットワーク・デバイスに割り当てられているか、または割り当てられていないかを判定し、
前記リモート・デバイスが、Ｍ個の割り当て済みビーコンを受信するまで、または１つの未割り当てスーパーフレームを受信するまで、前記受信および判定ステップを繰り返し、
前記リモート・デバイスが未割り当てスーパーフレームを受信した場合、アソシエーション要求を行い、
前記リモート・デバイスがＭ個の割り当て済みスーパーフレームを受信した場合、ネットワーク満杯機能を実行することを備え、
Ｍが１よりも大きい整数である、方法。
【請求項２】
リモート・デバイスが、ワイヤレス・ネットワークを監視し、そのネットワークと通信する方法であって、
前記リモート・デバイスにおいてスーパーフレームを規定するビーコン情報を含むビーコンを受信し、
前記ビーコン情報から、前記受信したビーコンおよびスーパーフレームが完全にＮ個のネットワーク・デバイスに割り当てられているか、または割り当てられていないかを判定し、
前記リモート・デバイスが、Ｍ個の完全割り当て済みスーパーフレームまたは１つの未割り当てスーパーフレームを受信するまで、前記受信および判定ステップを繰り返し、
前記リモート・デバイスが未割り当てスーパーフレームを受信した場合、アソシエーション要求を行い、
前記リモート・デバイスがＭ個の完全割り当て済みスーパーフレームを受信した場合、ネットワーク満杯機能を実行することを備え、
Ｍが１よりも大きい整数であり、
Ｎが１よりも大きい整数である、方法。
【請求項３】
スーパーフレーム構造を採用したワイヤレス・ネットワークにおいて、コーディネータが情報を通信する方法であって、
その各々がＭ個の各スーパーフレームの１つを規定するビーコン情報を含む、Ｍ個のビーコンを生成し、
前記Ｍ個の各スーパーフレームの間に、前記Ｍ個のビーコンを順次送信することを備え、
前記ビーコン情報は、前記ビーコンが前記ネットワーク内のデバイスに割り当てられているかまたは割り当てられていないかを示すデータを含み、Ｍは１よりも大きな整数である、方法。
【請求項４】
スーパーフレーム構造を採用したワイヤレス・ネットワークにおいて、コーディネータが情報を通信する方法であって、
その各々がＭ個の各スーパーフレームの１つを規定するビーコン情報を含む、Ｍ個のビーコンを生成し、
前記Ｍ個の各スーパーフレームの間に、前記Ｍ個のビーコンを順次送信することを備え、
前記ビーコン情報は、前記ビーコンが前記ネットワークにおいてＮ個のデバイスに割り当てられているかまたは割り当てられていないかを示すデータを含み、
Ｍは１よりも大きな整数であり、
Ｎは１よりも大きな整数である、方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ワイヤレス・パーソナル・エリア・ネットワークおよびワイヤレス・ローカル・エリア・ネットワークに関する。詳しくは、本発明は、ワイヤレス・パーソナル・エリア・ネットワークまたはワイヤレス・ローカル・エリア・ネットワーク環境においてデータの送信を制御するためのシステム、方法、デバイス、およびコンピュータ・プログラム生産物に関する。
【背景技術】
【０００２】
本願は、２００１年１０月３日に出願され、「ミニマックＴＤＭＡプロトコル」（ＭｉｎｉＭＡＣ  ＴＤＭＡ  Ｐｒｏｔｏｃｏｌ）と題する米国仮特許出願第６０／３２６，４２５号の優先権を主張するものである。その開示内容は、引用によって、その全体が本願にも含まれるものとする。
【０００３】
国際標準機構（ＩＳＯ）のオープン・システム相互接続（ＯＳＩ）規格は、エンド・ユーザと物理デバイスとの間に７層の階層を設け、これらを通じて異なるシステムが通信することができるようになっている。各層は異なるタスクを担当し、ＯＳＩ規格により、層間の交信、および当該規格に準拠するデバイス間の交信が指定される。
【０００４】
図１は、７層化ＯＳＩ規格の階層を示す。図１に示すように、ＯＳＩ規格１００は、物理層１１０、データ・リンク層１２０、ネットワーク層１３０、トランスポート層１４０、セッション層１５０、プレゼンテーション層１６０、およびアプリケーション層１７０を含む。
【０００５】
物理（ＰＨＹ）層１１０は、電気的、機械的、機能的、および手続き的レベルで、ビット・ストリームをネットワークを通じて伝達する。これは、キャリア上でデータを送受信するハードウエア手段を設ける。データ・リンク層１２０は、物理媒体上のビット表現、及び（フレーム等の）データ・ブロックを適正な同期化を伴って送信する際の媒体上のメッセージのフォーマットを記述する。ネットワーキング層１３０は、接続を維持および終了するデータの適正な宛先への導出および転送を行う。トランスポート層１４０は、二点間制御およびエラー・チェックを管理し、完全なデータ転送を保証する。セッション層１５０は、各終端におけるアプリケーション間で会話、交換、およびダイアログを設定し、調整し、そして終了させる。プレゼンテーション層１６０は、一方のプレゼンテーション・フォーマットから他方に、着信および発信データを変換する。アプリケーション層１７０では、通信相手が特定され、サービス品質が確認され、ユーザ認証およびプライバシが考慮され、データ・シンタックスに関するあらゆる制約が確認される。
【０００６】
ＩＥＥＥ８０２委員会は、ＯＳＩ規格１００の物理層１１０およびデータ・リンク層１２０に概算的に対応するローカル・ネットワークのために、３層アーキテクチャを開発した。図２は、ＩＥＥＥ８０２規格２００を示す。
【０００７】
図２に示すように、ＩＥＥＥ８０２規格２００は、物理（ＰＨＹ）層２１０、メディア・アクセス制御（ＭＡＣ）層２２０、および論理リンク制御（ＬＬＣ）層２２５を含む。ＰＨＹ層２１０は、ＯＳＩ規格１００におけるＰＨＹ層１１０のように動作する。ＭＡＣおよびＬＬＣ層２２０、２２５は、ＯＳＩ規格１００におけるデータ・リンク層１２０の機能を共有する。ＬＬＣ層２２５は、データを、ＰＨＹ層２１０において通信することができるフレーム内に置く。ＭＡＣ層２２０は、データ・リンク上の通信を管理し、データ・フレームを送出し、承認（ＡＣＫ）フレームを受信する。ＭＡＣおよびＬＬＣ層２２０、２２５は共に、エラー・チェック、および受信されず、がつ承認されないフレームの再送出を担当する。
【０００８】
図３は、ＩＥＥＥ８０２．１５規格２００を使用可能なワイヤレス・ネットワーク３００のブロック図である。好適な実施形態では、ネットワーク３００は、ワイヤレス・パーソナル・エリア・ネットワーク（ＷＰＡＮ）、即ち、ピコネットである。しかしながら、本発明は、例えば、ワイヤレス・ローカル・エリア・ネットワーク（ＷＬＡＮ）、またはその他の適したワイヤレス・ネットワークのように、帯域幅を数人のユーザ間で共有する、その他の設定にも適用されることは言うまでもない。
【０００９】
ピコネットという用語を用いる場合、これは、アドホック方式でデバイスを接続し、１つのデバイスをコーディネータ（即ち、サーバとして機能する）として作用させ、一方他のデバイス（局と呼ぶ場合もある）がコーディネータの時間割り当て命令に従う（即ち、これらはクライアントとして機能する）ようにしたネットワークを意味する。コーディネータは、指定したデバイスとするか、単に、コーディネータとして機能するように選択したデバイスの１つとすることができる。コーディネータと非コーディネータ・デバイスとの間の主要な相違の１つは、コーディネータはネットワーク内にあるデバイスの全てと通信できなければならないのに対して、種々の非コーディネータ・デバイスは、他の非コーディネータ・デバイスの全てと通信できる必要はないことである。
【００１０】
図３に示すように、ネットワーク３００は、コーディネータ３１０、および複数のデバイス３２１〜３２５を含む。コーディネータ３１０は、ネットワーク３００の動作を制御するように機能する。上記したように、コーディネータ３１０およびデバイス３２１〜３２５から成るシステムは、ピコネットと呼ぶこともでき、この場合、コーディネータ３１０をピコネット・コーディネータ（ＰＮＣ）と呼ぶこともできる。非コーディネータ・デバイス３２１〜３２５の各々は、主ワイヤレス・リンク３３０を通じてコーディネータ３１０に接続しなければならず、更に、副ワイヤレス・リンク３４０を通じて１つ以上の別の非コーディネータ・デバイス３２１〜３２５と接続することもできる。これは、ピア・ツー・ピア・リンクとも呼ばれる。
【００１１】
図３ではデバイス間における双方向リンクが示されているが、これらは一方向でも可能である。その場合、各双方向リンク３３０、３４０は、２つの単一方向リンクとして示すことができ、第１リンクが一方向に向かい、第２リンクが反対方向に向かう。
【００１２】
実施形態によっては、コーディネータ３１０は、システムを調整するための追加機能性、およびネットワーク３００内のあらゆるデバイス３２１〜３２５と通信する必要性を除いて、非コーディネータ・デバイス３２１〜３２５のいずれとでも、同じ種類のデバイスとすることもできる。他の実施形態では、コーディネータ３１０は、独立した指定の制御ユニットであり、デバイス３２１〜３２５の１つとして機能しないようにしてもよい。
【００１３】
以下の開示全体を通じて、コーディネータ３１０は、非コーディネータ・デバイス３２１〜３２５と同じようなデバイスであると見なすこととする。
しかしながら、代替実施形態では、専用のコーディネータ３１０を用いることもできる。更に、個々の非コーディネータ・デバイス３２１〜３２５は、コーディネータ３１０の機能要素を含むこともできるが、それらを用いず、非コーディネータ・デバイスとして機能することもできる。これは、いずれかのデバイスがコーディネータ３１０であるが、１つのみが実際に任意のネットワーク内でその機能を供与するようなケースがあり得る。
【００１４】
ネットワーク３００の各デバイスは、異なるワイヤレス・デバイス、例えば、ディジタル静止カメラ、ディジタル・ビデオ・カメラ、パーソナル・データ・アシスタント（ＰＤＡ）、ディジタル音楽プレイヤ、またはその他のパーソナル・ワイヤレス・デバイスとすることもできる。
【００１５】
種々の非コーディネータ・デバイス３２１〜３２５は、使用可能物理エリア３５０に制限される。これは、コーディネータ３１０が非コーディネータ・デバイス３２１〜３２５の各々と良好に通信できる範囲に基づいて設定されている。コーディネータ３１０と通信することができる非コーディネータ・デバイス３２１〜３２５のいずれも（そしてその逆も）、ネットワーク３００の使用可能エリア３５０内部にある。しかしながら、上記したようにネットワーク３００内のあらゆる非コーディネータ・デバイス３２１〜３２５が、他のあらゆる非コーディネータ・デバイス３２１〜３２５と通信する必要はない。
【００１６】
図４は、図３のネットワーク３００のデバイス３１０、３２１〜３２５のブロック図である。図４に示すように各デバイス（即ち、各コーディネータ３１０または非コーディネータ・デバイス３２１〜３２５）は、物理（ＰＨＹ）層４１０、メディア・アクセス制御（ＭＡＣ）層４２０、１組の上位層４３０、および管理部４４０を含む。
【００１７】
ＰＨＹ層４１０は、主または副ワイヤレス・リンク３３０または３４０を通じて、ネットワーク３００の残り部分と通信する。その通信では、送信可能なデータ・フォーマットでデータが生成および受信され、そのデータがＭＡＣ層４２０によって使用可能なフォーマットに変換され、かつフォーマットから変換される。ＭＡＣ層４２０は、ＰＨＹ層４１０が求めるデータ・フォーマットと、上位層４３０が求めるデータ・フォーマットとの間のインターフェースとして役立つ。上位層２０５は、デバイス３１０、３２１〜３２５の機能性を含む。これら上位層４３０は、ＴＣＰ／ＩＰ、ＴＣＰ、ＵＤＰ、ＲＴＰ、ＩＰ、ＬＬＣ等を含むことができる。
【００１８】
通例、ＷＰＡＮ内のコーディネータ３１０および非コーディネータ・デバイス３２１〜３２５は、同じ帯域幅を共有する。したがって、コーディネータ３１０はその帯域幅の共有を調整する。ワイヤレス・パーソナル・エリア・ネットワーク（ＷＰＡＮ）の設定において帯域幅を共有するためのプロトコルを確立するための規格が開発されている。例えば、ＩＥＥＥ規格８０２．１５．３は、このような設定におけるＰＨＹ層４１０およびＭＡＣ層４２０の仕様を設けており、ここでは、時分割多元接続（ＴＤＭＡ）を用いて帯域幅を共有する。この規格を用いると、ＭＡＣ４２０は、フレームおよびスーパーフレームを規定し、これらを通じて、デバイス３１０、３２１〜３２５による帯域幅の共有が、コーディネータ３１０および／または非コーディネータ・デバイス３２１〜３２５によって管理される。
【発明の開示】
【発明が解決しようとする課題】
【００１９】
特に関心が高いのは、個々のデバイス３２１〜３２５がどのようにして既存のネットワーク３００に加入することができるか、そしてどのようにしてこれらが、ネットワーク３００の動作中に、コーディネータ３１０と通信するかである。これは、異なるデバイス間の衝突を避けるために行うことが好ましい。この衝突は、２つ以上のデバイス３２１〜３２５が同時に（互いにまたはコーディネータ３１０と）通信しようとした場合に発生する可能性がある。
【００２０】
本発明の目的は、他のデバイスと衝突せずに、既存のワイヤレス・ネットワークに加入するデバイスおよび方法を提供することである。
本発明の別の目的は、衝突を避けるようにデバイス群およびコーディネータ間の通信を適応させる方法を提供することである。
【００２１】
本発明の別の特徴は、従来の通信システムおよび方法について先に特定した欠点およびその他の欠点を解決することである。
【課題を解決するための手段】
【００２２】
この章の題名にしたがって、本発明の選択した特徴についての簡潔な説明をこれより提示する。本発明の更に詳しい説明は、この文書全体の主題である。
これらの目的の一部を達成するにあたって、リモート・デバイスがワイヤレス・ネットワークを監視し、そのネットワークと通信する方法を提供する。この方法は、リモート・デバイスにおいてスーパーフレームを規定するビーコン情報を含むビーコンを受信し、ビーコン情報から、受信したビーコンおよび関連するスーパーフレームがネットワーク・デバイスに割り当てられているか、または割り当てられていないかを判定し、リモート・デバイスが、Ｍ個の割り当て済みビーコンを受信するまで、または１つの未割り当てスーパーフレームを受信するまで、受信および判定ステップを繰り返し、リモート・デバイスが未割り当てスーパーフレームを受信した場合、アソシエーション要求を行い、リモート・デバイスがＭ個の割り当て済みスーパーフレームを受信した場合、ネットワーク満杯機能を実行することを含み、Ｍは１よりも大きい整数である。
【００２３】
この方法では、ビーコン情報は、スーパーフレームが割り当てられているかまたは割り当てられていないかを示すスーパーフレーム割り当て情報を含み得る。スーパーフレーム割り当て情報は、スーパーフレームが割り当てられているかまたは割り当てられていないかを示す単一のビットで構成してもよいし、あるいはスーパーフレーム割り当て情報は、デバイス識別（ＩＤ）情報を含む。デバイスＩＤ情報は、スーパーフレームが割り当てられている場合には、関連するネットワーク・デバイスのデバイスＩＤであることが好ましく、デバイスＩＤは、スーパーフレームが割り当てられていない場合、いずれのネットワーク・デバイスにも対応しないが、未割り当てスーパーフレームを示すように設定した未割り当て値であることが好ましい。
【００２４】
ネットワーク満杯機能は、エラー・メッセージを上位層に送ることを含み得る。
また、リモート・デバイスが、ワイヤレス・ネットワークを監視し、そのネットワークと通信する方法も提供する。この方法は、リモート・デバイスにおいてスーパーフレームを規定するビーコン情報を含むビーコンを受信し、ビーコン情報から、受信したビーコンおよびスーパーフレームが完全にＮ個のネットワーク・デバイスに割り当てられているか、または割り当てられていないかを判定し、リモート・デバイスが、Ｍ個の完全割り当て済みスーパーフレームまたは１つの未割り当てスーパーフレームを受信するまで、受信および判定ステップを繰り返し、リモート・デバイスが未割り当てスーパーフレームを受信した場合、アソシエーション要求を行い、リモート・デバイスがＭ個の完全割り当て済みスーパーフレームを受信した場合、ネットワーク満杯機能を実行することを含み、Ｍは１よりも大きい整数であり、Ｎは１よりも大きい整数である。
【００２５】
ビーコン情報は、スーパーフレームが完全に割り当てられているかまたは割り当てられていないかを示すスーパーフレーム割り当て情報を含むことができる。
スーパーフレーム割り当て情報は、第１から第Ｎまでのデバイス識別（ＩＤ）情報を含むことができる。第１乃至第ＮデバイスＩＤ情報は、関連するネットワーク・デバイスのデバイスＩＤ、およびいずれのネットワーク・デバイスにも対応しないが、未割り当てスーパーフレームを示すように設定された未割り当て値の一方であることが好ましい。スーパーフレームが完全に割り当てられたと見なされるのは、第１乃至第Ｎデバイス情報の全てがデバイスＩＤである場合であり、スーパーフレームが未割り当てであると見なされるのは、第１乃至第Ｎデバイス情報のいずれかが、設定された未割り当て値である場合である。
【００２６】
ネットワーク満杯機能は、エラー・メッセージを上位層に送ることを含み得る。
加えて、スーパーフレーム構造を採用したワイヤレス・ネットワークにおいて、コーディネータが情報を通信する方法を提供する。この方法は、各々、Ｍ個の各スーパーフレームの１つを規定するビーコン情報を含むＭ個のビーコンを生成し、Ｍ個の各スーパーフレームの間に、Ｍ個のビーコンを順次送信することを含み、ビーコン情報は、ビーコンがネットワーク内のデバイスに割り当てられているかまたは割り当てられていないかを示すデータを含み、Ｍは１よりも大きな整数である。
【００２７】
Ｍ個のビーコンを生成し、これらＭ個のビーコンを順次送信するステップは、ネットワークの動作期間中連続的に繰り返すことが好ましい。
Ｍは、ネットワーク内で許容可能なデバイスの最大数に等しくするとよく、あるいは、Ｍはネットワークにおいて割り当てられたデバイスの数にある設定値を加算した合計に等しくしてもよい。設定値は１にするとよい。
【００２８】
スーパーフレーム構造を採用したワイヤレス・ネットワークにおいて、コーディネータが情報を通信する別の方法も提供する。この方法は、各々、Ｍ個の各スーパーフレームの１つを規定するビーコン情報を含むＭ個のビーコンを生成し、Ｍ個の各スーパーフレームの間に、Ｍ個のビーコンを順次送信することを含む。ビーコン情報は、ビーコンがネットワークにおいてＮ個のデバイスに割り当てられているかまたは割り当てられていないかを示すデータを含む。Ｍは１よりも大きな整数であり、Ｎは１よりも大きな整数である。
【００２９】
Ｍ個のビーコンを生成し、これらＭ個のビーコンを順次送信するステップは、ネットワークの動作期間中連続的に繰り返すことが好ましい。
量（Ｍ×Ｎ）は、ネットワークにおけるデバイスの許容最大数に等しくするとよい。  
【００３０】
本発明の更に深い理解およびその付随する利点の多くは、以下の詳細な説明を参照し、添付図面と関連付けて検討すればこれらが一層よく理解され、容易に得られるであろう。これらの図面では、同様の参照番号は、種々の図を通じて同一のまたは対応する部分を示す。
【発明を実施するための最良の形態】
【００３１】
本発明の好適な実施形態について、以下に説明する。更に、ここに記載する実施形態はＷＰＡＮ（即ち、ピコネット）に関して行うが、本発明は、例えば、ワイヤレス・ローカル・エリア・ネットワーク（ＷＬＡＮ）、またはその他の該当するあらゆるワイヤレス・ネットワークのように、数人のユーザ間で帯域幅を共有するようにしたその他の設定にも適用されることは言うまでもない。
【００３２】
本発明は、ネットワーク３００を通じたデータ経路を規定するスーパーフレーム内部にある巡回ビーコンの仕様により、ネットワーク３００内において動作中のデバイス３１０、３２１〜３２４、またはネットワーク３００に加入しようとしているデバイス３１０、３２１〜３２４を調整する方法を提供する。
［デバイスＩＤおよびＭＡＣアドレス］
ネットワーク３００におけるデバイス３１０、３２１〜３２５を調整する重要な側面の１つは、デバイス３１０、３２１〜３２５の各々を一意に特定することである。これを達成可能な方法にはいくつかある。
【００３３】
所属するいずれのネットワークから独立して、各デバイス３１０、３２１〜３２５は、一意のＭＡＣアドレスを有し、これを用いれば、当該デバイスを特定することができる。このＭＡＣアドレスは、一般に、２つのデバイス３１０、３２１〜３２５が同じＭＡＣアドレスを有することがないように、製造者によって割り当てられる。ＭＡＣアドレスを統括するために本発明の好適な実施形態において用いられる規格集は、ＩＥＥＥ  Ｓｔｄ．８０２−１９９０、「ローカルおよび都市エリア・ネットワーク用ＩＥＥＥ規格：概要およびアーキテクチャ」（ＩＥＥＥ  Ｓｔａｎｄａｒｄｓ  ｆｏｒ  Ｌｏｃａｌ  ａｎｄ  Ｍｅｔｒｏｐｏｌｉｔａｎ  Ａｒｅａ  Ｎｅｔｗｏｒｋｓ：  Ｏｖｅｒｖｉｅｗ  ａｎｄ  Ａｒｃｈｉｔｅｃｔｕｒｅ）にて見出すことができる。
【００３４】
動作の容易性のために、ネットワーク３００は、デバイスＩＤをネットワーク３００内の各デバイス３１０、３２１〜３２５に割り当てて、その一意のＭＡＣアドレスとともに用いることもできる。好適な実施形態では、ＭＡＣ４２０は、アドホック・デバイスＩＤを用いて、デバイス３１０、３２１〜３２５を特定する。これらのデバイスＩＤは、例えば、ＭＡＣヘッダにおいて用いることができる。デバイスＩＤは、一般に、デバイス３１０、３２１〜３２５毎のＭＡＣアドレスよりも遥かに小さい。好適な実施形態では、デバイスＩＤは４ビットであり、ＭＡＣアドレスは４８ビットである。
【００３５】
各デバイス３１０、３２１〜３２５は、デバイスＩＤとＭＡＣアドレスとの間の対応関係をマップするマッピング表を保持しているとよい。この表は、コーディネータ３１０がデバイス３２１〜３２５に供給するデバイスＩＤおよびＭＡＣアドレス情報に基づいて作成される。これによって、各デバイス３１０、３２１〜３２５は、ネットワーク３００内において、デバイスＩＤまたはＭＡＣアドレスのいずれかによって、それら自体およびその他のデバイスを参照することが可能となる。
【００３６】
本発明は、高速ＷＰＡＮ用のＩＥＥＥ８０３．１５．３規格と共に用いることができる。高速ＷＰＡＮは、現在ＩＥＥＥ８０２．１５ＷＰＡＮTMタスク・グループ３（ＴＧ３）によって開発中である。８０２．１５．３グループの保管資料を含む、現在の草案８０２．１５．３の詳細は、ｈｔｔｐ：／／ｗｗｗ．ｉｅｅｅ８０２．ｏｒｇ／１５／ｐｕｂ／ＴＧ３．ｈｔｍｌにおいて見ることができる。この開示内容におけるいずれも、ＩＥＥＥ８０２のＬＡＮ／ＭＡＮ規格委員会のウェブ・ページに明記されている草案８０２．１５．３規格と互換性がないとは見なさないこととする。
［スーパーフレーム］
任意のネットワーク３００において利用可能な帯域幅は、コーディネータ３１０によって、時間的に一連のスーパーフレームの繰り返しに分割される。これらのスーパーフレームは、種々のタスク間で、利用可能な送信時間をどのように分割するかを定義する。次いで、これらのスーパーフレーム内において、当該スーパーフレームに定義されているタイミングにしたがって、個々のデータ・フレームを転送する。
【００３７】
図５は、本発明の好適な実施形態によるスーパーフレームのブロック図である。図５に示すように、各スーパーフレーム５００は、ビーコン期間５１０、競合アクセス期間（ＣＡＰ）５２０、および競合解放期間（ＣＦＰ）５３０を含むことができる。
【００３８】
ビーコン期間５１０は、コーディネータ３１０がネットワーク３００内の非コーディネータ・デバイスにビーコン・フレーム（例えば、図６および図８Ｈ参照）を送り出すために確保されている。各デバイス３２１〜３２５は、ネットワーク３００に加入する前に、どのようにビーコン５１０を認識するかを知っており、既存のネットワーク３００を識別するため、そしてネットワーク３００内部における通信を調整するための双方にビーコン５１０を用いる。
【００３９】
ＣＡＰ５２０は、ネットワークを通じてコマンドまたは非同期データを送信するために用いられる。ＣＡＰ５２０は、多くの実施形態では削除されてもよく、その場合、システムは、ＣＦＰ５３０の間だけでコマンドを受け渡す。
【００４０】
ＣＦＰ５３０は、複数のタイム・スロット５４０を含む。これらのタイム・スロット５４０は、コーディネータ３１０によって、デバイス３１０、３２１〜３２５の対に割り当てられ、それらの間で情報を送信する（即ち、各タイム・スロット５４０は、特定の送信機−受信機対に割り当てられる）。
【００４１】
タイム・スロット５４０は、管理タイム・スロット（ＭＴＳ）または保証タイム・スロット（ＧＴＳ）とすることもできる。ＭＴＳは、コーディネータ３１０と非コーディネータ・デバイス３２１〜３２５の１つとの間で管理運用情報を送信するために用いられる。したがって、コーディネータ３１０を、送信対の１メンバにさせなければならない。ＭＴＳは、更に、コーディネータ３１０が受信デバイスである場合には、アップリンクＭＴＳ（ＵＭＴＳ）として定義し、コーディネータ３１０が送信デバイスである場合、ダウンリンクＭＴＳ（ＤＭＴＳ）として定義することができる。
【００４２】
ＧＴＳは、ネットワーク３００において、デバイス３１０、３２１〜３２５間で非管理運用データを送信するために用いられるタイム・スロットである。これは、２つの非コーディネータ・デバイス３２１〜３２５間で送信されるデータ、またはコーディネータ３１０と非コーディネータ・デバイス３２１〜３２５との間で送信される非管理運用データを含むことができる。
【００４３】
本願においては、ストリームとは、発信元デバイスと１つ以上の宛先デバイスとの間の通信である。発信元および宛先デバイスは、ネットワーク３００におけるいずれのデバイス３１０、３２１〜３２５とすることもできる。多数の宛先へのストリームでは、宛先デバイスは、ネットワーク３００におけるデバイス３１０、３２１〜３２５の全部または一部とすることができる。
【００４４】
実施形態によっては、アップリンクＭＴＳを、ＣＦＰ５３０の前に配置し、ダウンリンクＭＴＳをＣＦＰ５３０の端部に配置して、コーディネータ３１０に、同じスーパーフレーム５００のダウンリンクＭＴＳにおいてアップリンクＭＴＳに応答する機会を与えるようにしてもよい。しかしながら、コーディネータ３１０が同じスーパーフレーム５００において要求に応答することは必要ではない。むしろ、コーディネータ３１０は、後のスーパーフレーム５００において、当該非コーディネータ・デバイス３２１〜３２５に割り当てられた別のダウンリンクＭＴＳにおいて応答すればよい。
【００４５】
スーパーフレーム５００は、時間的に繰り返えされる固定時間構造である。スーパーフレーム５００の具体的な期間は、ビーコン５１０に記述されている。実際、ビーコン５１０は、ビーコン５１０が繰り返される頻度に関する情報を一般に含んでおり、これは、事実上スーパーフレーム５００の期間に対応する。また、ビーコン５１０は、各タイム・スロット５４０の送信機および受信機のアイデンティティ、コーディネータ３１０のアイデンティティのような、ネットワーク３００に関する情報も収容する。
【００４６】
ネットワーク３００のシステム・クロックは、ビーコン５１０の発生および受信によって同期を取ることが好ましい。各非コーディネータ・デバイス３２１〜３２５は、有効なビーコン５１０を受信することができたときに同期点時刻を格納し、次いで、この同期点時刻を用いて自己のタイミングを調節する。
【００４７】
図５には示されていないが、ＣＦＰ５３０内のタイム・スロット５４０間に、ガード・タイムを介挿することが好ましい。ＴＤＭＡシステムでは、ガード・タイムは、クロック精度の不可避な誤差や、空間位置に基づく伝搬時間の差に起因して、２回の送信が時間的に重複するのを防止するために用いられる。
【００４８】
ＷＰＡＮでは、伝搬時間は、クロックの精度と比較すると、一般に重要ではない。したがって、必要なガード・タイム量は、主にクロック精度および前回の同期動作以来の期間に基づくことが好ましい。かかる同期動作が行われるのは、一般的に、デバイス３２１〜３２５がコーディネータ３１０からビーコンを受信することができたときである。
【００４９】
簡略化のために、フレーム全体に、単一のガード・タイム値を用いることもできる。ガード・タイムは、各ビーコン・フレーム、ＧＴＳ、およびＭＴＳの端部に配置することが好ましい。
［フレーム］
各スーパーフレーム５００内では、情報は、フレームを通じてデバイス３１０、３２１〜３２５間で受け渡される。フレームは信号をどのように送るか規定する。即ち、フレームは、信号を構成するビットを認識可能なフォーマットで送るようにするには、ビットをどのように編成するかを規定する。
【００５０】
図６は、本発明の好適な実施形態によるフレームのブロック図である。図６に示すように、フレーム６００は、プリアンブル６１０、ヘッダ６２０、ヘッダ・チェック・シーケンス（ＨＣＳ）６３０、ペイロード６４０、フレーム・チェック・シーケンス（ＦＣＳ）４５０、およびポストアンブル６６０を含むことができる。ヘッダ６２０は、物理ヘッダ６２２とＭＡＣヘッダ６２４とに分割することが好ましい。これらの要素については、以下で更に詳しく論ずることにする。
プリアンブル
プリアンブル６１０は、２つの通信デバイス３１０、３２１〜３２５間で送信タイミングの同期を取るために用いられるセット・ビット・パターンである。これにより、均一で既知の開始点を与えることによって、データ送信が開始されるときを受信機が正しく解釈することの確証が得られる。加えて、プリアンブル６１０は、開始フレーム区切り（ＳＦＤ）を含めば、これを用いて種々のデバイス３１０、３２１〜３２５においてクロックを同期させることができる。
ヘッダ
上記したように、ヘッダ６２０は、物理ヘッダ６２２とＭＡＣヘッダ６２４とに分割されている。物理ヘッダ６２２は、デバイス３１０、３２１〜３２５間で送られる物理的な信号に関する情報を提供し、少なくとも現ペイロード６４０の長さを含むことが好ましい。また、物理ヘッダ６２２は、ペイロード６４０を送るデータ・レートに関する情報、またはその他の情報も含むことができる。
【００５１】
ＭＡＣヘッダ６２４は、デバイス３１０、３２１〜３２５間のフレーム転送に関するデータを含むことが好ましい。図７Ａおよび図７Ｂは、本発明の好適な実施形態による、図６のＭＡＣヘッダを示すブロック図である。図７Ａは、第１の好適な実施形態によるＭＡＣヘッダを示すブロック図であり、図７Ｂは、第２の好適な実施形態によるＭＡＣヘッダを示すブロック図である。
【００５２】
図７Ａに示すように、ＭＡＣヘッダ６２４は、バージョン・インディケータ７０５、ＡＣＫポリシー・インディケータ７１０、シーケンス番号７１５、フレーム種別７２０、宛先デバイスＩＤ７２５、および発信元デバイスＩＤ７３０を含む。
【００５３】
バージョン・インディケータ７０５は、どのバージョンのヘッダ６２０を用いているのかを示す。好適な実施形態では、バージョン・インディケータ７０５は単一のビットである。代替実施形態では、単一ビットよりも大きくすることもできる。
【００５４】
ＡＣＫポリシー・インディケータ７１０は、現フレーム６００を送った後、いつ承認（ＡＣＫ）を要求するかを設定する際に用いられる。この好適な実施形態では、ＡＣＫポリシー・インディケータは、単一のビットであり、ＡＣＫを要求するときには真値（例えば、「１」）に、ＡＣＫを要求しないときには偽値（例えば、「０」）に設定する。ブロードキャストおよびマルチキャスト・フレームでは、これを偽値に設定し、受信機は全くＡＣＫフレームを発生しないようにするとよい。加えて、承認フレームは、偽値に設定されたＡＣＫポリシー・インディケータ７１０を有するとよい。何故なら、それら承認フレームは承認されないからである。
【００５５】
シーケンス番号７１５は、データ・フレームの送信を追跡し、重複フレームに対処するために用いられる。シーケンス番号７１５は、Ｆ個の値で巡回し、これらは連続する送信データ・フレームに割り当てられる。受信機が同じシーケンス番号７１５を有する２つのフレームを連続して受信した場合、再送信による重複フレームを受信したことがわかる。重複フレームは、承認するが破棄すればよい。好適な実施形態（Ｆ＝３）では、他の全てのフレーム６００について、シーケンス番号は０のままである。
【００５６】
フレーム種別７２０は、どの種別のフレーム６００が送られているのかを示す。好適な実施形態では、フレーム種別７２０は４ビットである。フレーム種別７２０は、ビーコン、ステータス要求、アソシエーション要求、アソシエーション応答、アソシエーション解除指示、ＡＣＫ、データ、ストリーム割り当て要求、ストリーム割り当て応答、ストリーム割り当て解除、ストリーム再割り当てを含む。
【００５７】
ビーコン・フレーム種別は、フレームがビーコン５１０であることを示し、各スーパーフレーム５００の先頭においてコーディネータ３１０により生成される。ステータス要求フレームは、コーディネータ３１０によってＭＴＳにおいて送られ、宛先デバイスのステータスをチェックする。アソシエーション要求フレームは、コーディネータ３１０にネットワーク３１０への加入を要求する新たなデバイスによって送られる。アソシエーション応答フレームは、アソシエーション要求フレームに応答して、コーディネータ３１０によって新たなデバイスに送られる。アソシエーション解除指示フレームは、現デバイス３２１〜３２５によってコーディネータ３１０に送られ、ネットワーク３００からの離脱を示す。ＡＣＫフレームは、以前のフレームの即時承認（ＡＣＫ）を示す。データ・フレームはいずれか２つのデバイス間で送られ、ストリームに沿ってアイソクロナス・データを受け渡す。ストリーム割り当て要求フレームは、現デバイス３２１〜３２５によってコーディネータ３１０に送られ、ストリームの割り当てを要求する。ストリーム割り当て応答フレームは、ストリーム要求フレームに応答して、コーディネータ３１０から現デバイス３２１〜３２５に送られる。ストリーム割り当て解除フレームは、現デバイス３２１〜３２５からコーディネータ３１０に送られ、現デバイス３２１〜３２５がもはやストリームを必要としないことを示す。ストリーム再割り当てフレームは、デバイス３２１〜３２５からコーディネータ３１０に送られ、既に割り当てられているストリームの変更を要求する。
【００５８】
宛先デバイスＩＤ７２５は、フレーム６００を送ろうとしているデバイス３１０、３２１〜３２５のデバイスＩＤである。
発信元デバイスＩＤ７３０は、フレーム６００を送っている元のデバイス３１０、３２１〜３２５のデバイスＩＤである。
【００５９】
図７Ｂは、本発明の第２の好適な実施形態によるＭＡＣヘッダ６２４を示す。この実施形態は、ＩＥＥＥ８０２．１５．３規格におけるヘッダ・フォーマットに準拠する。図７Ｂに示すように、ＭＡＣヘッダ６２４は、フレーム制御７５５、ネットワークＩＤ７６０、宛先デバイスＩＤ７２５、発信元デバイスＩＤ７３０、断片化制御７６５、およびストリーム制御７７０を含む。
【００６０】
フレーム制御７５５は、バージョン、フレーム種別、承認ポリシー、再試行ポリシー等に関する情報を提供する。好適な実施形態では、フレーム制御７５５は、１６ビットであり、多数のフィールドに分割されている。プロトコル・バージョン・フィールドは、ヘッダ・フォーマットのバージョンを示す。フレーム種別フィールドは、送られるフレームの種別を示す。ＳＥＣフィールドは、セキュリティ・プロトコルを用いるか否かについて示す。ＡＣＫポリシー・フィールドは、フレームに用いられる承認ポリシーを示す。遅延ＡＣＫ要求フィールドは、現フレームに対して承認を遅らせて行うか否かについて示す。再試行フィールドは、当該フレームが以前のフレームの再送信であるか否かについて示す。残りデータ・フィールドは、送信デバイスが、同じＧＴＳにおける現フレームの後に、なおも送信するデータがあるか否かについて示す。
【００６１】
ネットワークＩＤ７６０は、ネットワーク３００に対する識別番号を示す。好ましくは、この番号は、ネットワーク３００の存続期間中、一定であることが好ましく、任意のコーディネータ３１０によって作成されたいずれのネットワーク３００についても、固定させることもできる。
【００６２】
宛先デバイスＩＤ７２５は、フレーム６００が送られている先のデバイス３１０、３２１〜３２５のデバイスＩＤである。
発信元デバイスＩＤ７３０は、フレーム６００を送っている元のデバイス３１０、３２１〜３２５のデバイスＩＤである。
【００６３】
断片化制御７６５は、ネットワーク３００におけるサービス・データ単位（ＳＤＵ）の断片化および再組立を援助するために用いられる。好ましくは、現サービス・データ単位、現断片番号、および直前の断片番号に関する情報を収容する。
【００６４】
ストリーム制御７７０は、現フレーム６００が用いるストリームに対する一意のストリーム識別子を示す。
第１の好適な実施形態では、ヘッダ６２０は３２ビットである。ヘッダ６２０の任意の部分に必要なビットがこれよりも少なくて済む場合、未使用ビットを保存しておくことができる。言い換えると、これらはヘッダ長内であると見なし、各フレームと共に送信することができるが、受信デバイスが用いることはできない。その結果、実際に用いられているビットが何であるかは重要ではない。
【００６５】
例えば、第１の好適な実施形態（図６および図７Ａ参照）では、以下の値を選択する。物理ヘッダ６２２およびＭＡＣヘッダ６２４は双方とも１６ビットである。物理ヘッダ６２２内部では、フレーム長は１５ビットであり、１ビットが保存されている。ＭＡＣヘッダ６２４内部では、バージョン・インディケータ７０５が１ビット、ＡＣＫポリシー・インディケータ７１０が１ビット、シーケンス番号７１５が２ビット、フレーム種別７２０が４ビット、宛先アドレス７２５が４ビット、そして発信元アドレス７３０が４ビットである。
ヘッダ・チェック・シーケンス（ＨＣＳ）
ＨＣＳ６３０は、ヘッダ６２０を確認するために用いられる巡回冗長チェック（ＣＲＣ）を収容するフィールドである。第１の好適な実施形態では、ＨＣＳは１６ビットであり、ＣＲＣ−ＣＣＩＴＴとして知られている、以下の標準的な１６度の発生多項式を用いて計算することが好ましい。
【００６６】
Ｇ（ｘ）＝ｘ16＋ｘ12＋ｘ5＋１              （１）
ＨＣＳ６３０は、以下の（１）及び（２）の和（モジュロ２）の１の補数である。（１）ｘk×（ｘ12＋ｘ11＋ｘ10＋ｘ8＋ｘ3＋ｘ2＋ｘ1＋１）をＧ（ｘ）で除算（モジュロ２）した剰余。ここで、ｋは計算フィールドにおけるビット数である。（２）計算フィールドの内容（多項式として扱う）をｘ32と乗算し、次いでＧ（ｘ）で除算した後の剰余。
【００６７】
ＨＣＳ６３０は、最も高い次数の項の係数から開始して送信することが好ましい。
好適な実施形態では、除算の初期の剰余が送信機において全て１に予め設定され、次いで計算フィールドの発生多項式Ｇ（ｘ）による除算によって変更される。この剰余の１の補数をＨＣＳ６３０として、高次のビットから先に送信する。
【００６８】
受信機では、初期の剰余が全て１に予め設定され、計算フィールドおよびＨＣＳ６３０のシリアル着信ビットをＧ（ｘ）で除算すると、送信エラーが生ずることなく、一意の非ゼロの剰余値が得られる。この一意の剰余値は次の多項式となる。
【００６９】
ｘ12＋ｘ11＋ｘ10＋ｘ8＋ｘ3＋ｘ2＋ｘ＋１        （２）
または、０ｘ１Ｄ０Ｆ
第１の好適な実施形態では、ＨＣＳ６３０におけるＣＲＣは１６ビットである。これは、代替実施形態では、必要に応じて増減することもできる。
ペイロード
ペイロード６４０は、現フレーム６００が要求するデータ（ある場合）を収容する。図８Ａ乃至図８Ｈは、本発明の第１の好適な実施形態による、図６におけるペイロード６４０の例を示すブロック図である。即ち、図８Ａは、アソシエーション要求ペイロードであり、図８Ｂはアソシエーション応答ペイロードであり、図８Ｃはストリーム要求ペイロードであり、図８Ｄはストリーム応答ペイロードであり、図８Ｅはストリーム解放ペイロードであり、図８Ｆはストリーム再割り当てペイロードであり、図８Ｇはデータ・ペイロードであり、図８Ｈはビーコン・ペイロードである。
【００７０】
図８Ａは、第１の好適な実施形態によるアソシエーション要求ペイロードを示すブロック図である。これが用いられるのは、新たなデバイスにおけるＭＡＣ４２０がネットワーク３００のメンバになることを要求するときである。図８Ａに示すように、アソシエーション要求ペイロード８１０は、要求元８１２のＭＡＣアドレスを含む。
【００７１】
図８Ｂは、第１の好適な実施形態によるアソシエーション応答ペイロードのブロック図である。これが用いられるのは、コーディネータ３１０がアソシエーション要求フレーム８２０に応答するときである。図８Ｂに示すように、アソシエーション応答ペイロード８２０は、ＭＡＣアドレス８２２、パディング・ブロック８２４、およびデバイスＩＤ８２６を含む。
【００７２】
ＭＡＣアドレス８２２は、要求元のアドレスであり、いずれのユニキャスト・アドレスでもよい。
パディング・ブロック８２４は、使用されていないが応答ペイロード８２０に割り当てられているビット集合である。これは、フレームをオクテット単位で合わせることが好ましく、正しい位置合わせを行うにはパディング・ブロック８２４が必要となるからである。代替実施形態において、オクテット毎の位置合わせを用いない場合、またはオクテット毎の位置合わせを維持するためにパディングを行う必要がない場合、パディング・ブロックをなくすることもできる。好ましくは、パディング・ブロック８２４内に格納する値は０とする。即ち、これは０のストリングである。
【００７３】
デバイスＩＤ８２６は、コーディネータ３１０によって要求元デバイスに割り当てられるアドレスである。これは、図７Ａの好適な実施形態では、４ビットのデバイスＩＤである。デバイスＩＤ８２６は、コーディネータ３１０が参入を拒絶した場合、非割り当てを意味する値と共に返送される。
【００７４】
図８Ｃは、第１の好適な実施形態によるストリーム要求ペイロードのブロック図である。これが用いられるのは、デバイス３２１〜３２５が他のデバイスと通信するためのストリームを要求するときである。図８Ｃに示すように、ストリーム要求ペイロード８３０は、宛先アドレス８３２、ＧＴＳ下位値８３４、ＧＴＳ上位値８３６、および保存ブロック８３８を含む。
【００７５】
宛先アドレス８３２は、現データ・ストリームにおけるパケットの受信機のＭＡＣアドレスである。宛先アドレス８３２は、いずれのユニキャスト・アドレスまたはブロードキャスト・アドレスとすることもできる。これは、マルチキャスト・アドレスにはしない方がよい。
【００７６】
ＧＴＳ下位値８３４は、送られるデータに割り当てることができる、ＧＴＳの最少許容量である。ＧＴＳ上位値８３６は、データ転送に対する最大要求ＧＴＳである。この実施形態では、ＧＴＳ下位値８３４およびＧＴＳ上位値８３６は、１乃至６４の間とするとよい。加えて、ＧＴＳ下位値８３４は、ＧＴＳ上位値８３６以下であるのは当然である。
【００７７】
保存ブロック８３８は、この実施形態では用いられないペイロード６４０におけるビットを表す。代替実施形態では、他のパラメータを変更し、保存ブロック８３８を削減または削除することもできる。
【００７８】
図８Ｄは、第１の好適な実施形態によるストリーム応答ペイロードのブロック図である。これが用いられるのは、コーディネータ３１０が、デバイス３２１〜３２５からのストリーム要求ペイロード８４０に応答するときである。図８Ｄに示すように、ストリーム応答ペイロード８４０は、ストリームＩＤ８４２、宛先ＩＤ８４４、ＧＴＳスロット値８４６、および保存ブロック８４８を含む。
【００７９】
ストリームＩＤ８４２は、要求元デバイス３２１〜３２５に割り当てられるストリームに与えられる一意の識別子である。この値は、割り当てが行われなかった場合、指定のストリーム障害(Stream Failure）値に設定される（例えば、第１の好適な実施形態では、０ｘＦとしてコード化される）。
【００８０】
宛先ＩＤ８４４は、指定した受信側デバイスのデバイスＩＤである。受信機を発見することができない場合、この値は、未割り当てとして返送される。
割り当てが行われた場合、ＧＴＳスロット値８４６は、割り当てられたスロットの数を示す。割り当てが行えなかった場合、ＧＴＳスロット値８４６は、割り当てに利用可能なスロット量を収容する。
【００８１】
保存ブロック８３８は、この実施形態では用いられないペイロード６４０におけるビットを表す。代替実施形態では、他のパラメータを変更し、保存ブロック８３８を削減または削除することもできる。
【００８２】
図８Ｅは、第１の好適な実施形態によるストリーム解放ペイロードのブロック図である。これは、デバイス３２１〜３２５によって、もはやストリームを用いようとはしないこと、および対応するＧＴＳを再利用してもよいことを、コーディネータ３１０に知らせるために用いられる。図８Ｅに示すように、ストリーム解放ペイロード８５０は、パディング・ブロック８５２、ストリームＩＤ８５４、および保存ブロック８５６を含む。
【００８３】
パディング・ブロック８５２は、未使用であるがストリーム解放ペイロード８５０に割り当てられたビット集合である。これは、フレームをオクテット単位で合わせることが好ましく、正しい位置合わせを行うにはパディング・ブロック８５２が必要となるからである。代替実施形態において、オクテット毎の位置合わせを用いない場合、またはオクテット毎の位置合わせを維持するためにパディングを行う必要がない場合、パディング・ブロックをなくすることもできる。好ましくは、パディング・ブロック８５２内に格納する値は０とする。即ち、これは０のストリングである。
【００８４】
ストリームＩＤ８５４は、関連するストリーム応答ペイロード８４０において返送されるのと同じストリームＩＤ８４２である。これは、割り当てられたストリームに一意の識別子を設ける。
【００８５】
保存ブロック８５６は、この実施形態では用いられないペイロード４０におけるビットを表す。代替実施形態では、他のパラメータを変更し、保存ブロック８５６を削減または削除することもできる。
【００８６】
図８Ｆは、第１の好適な実施形態によるストリーム再割り当てペイロードのブロック図である。これは、デバイスが、あるストリームのためにＧＴＳ量の増加または減少を要求するために用いられる。代替実施形態では、これは、他のパラメータの変更を要求するためにも用いることができる。図８Ｆに示すように、ストリーム再割り当てペイロード８６０は、パディング・ブロック８６２、ストリームＩＤ８６４、およびＧＴＳ要求値８６６を含む。
【００８７】
パディング・ブロック８６２は、未使用であるがストリーム解放ペイロード８６０に割り当てられたビット集合である。これは、フレームをオクテット単位で合わせることが好ましく、正しい位置合わせを行うにはパディング・ブロック８６２が必要となるからである。代替実施形態において、オクテット毎の位置合わせを用いない場合、またはオクテット毎の位置合わせを維持するためにパディングを行う必要がない場合、パディング・ブロックをなくすることもできる。好ましくは、パディング・ブロック８６２内に格納する値は０とする。即ち、これは０のストリングである。
【００８８】
ストリームＩＤ８６４は、関連するストリーム応答ペイロード８４０において返送されるのと同じストリームＩＤ８４２である。これは、割り当てられたストリームに一意の識別子を設ける。
【００８９】
ＧＴＳ要求値８６６は、要求元が望む、新たなＧＴＳの所望量である。コーディネータ３１０は、要求を否定し、ＧＴＳ割り当てを変更しないままにしておくことができ、あるいは要求を許可し、それに応じてＧＴＳの割り当てを増減させることもでき、あるいは要求を部分的に許可し、要求量未満でＧＴＳ割り当てを増減させることもできる。
【００９０】
図８Ｇは、第１の好適な実施形態によるデータ・ペイロードのブロック図である。これが用いられるのは、２つのデバイス３１０、３２１〜３２５間でデータを送らなければならないときである。図８Ｇに示すように、データ・ペイロード８７０は、データ・ブロック８７２を含む。このデータ・ブロック８７２は、単に、物理ヘッダ６２２内に定義された長さのデータ・ビットから成るストリングに過ぎない。
【００９１】
図８Ｈは、第１の好適な実施形態によるビーコン・ペイロードのブロック図である。これは、各スーパーフレーム５００の開始時に送られるビーコン・フレーム５２０のために用いられる。図８Ｈに示すように、ビーコン・ペイロード８８０は、ＭＴＳカウント・ブロック８８１、ＭＴＳフラグ８８２、遮断値８８４、関連アドレス８８７、およびＲｘＴｘ表を含む。好適な実施形態では、遮断値８８４と関連アドレス８８７との間には保存部分８８５もある。
【００９２】
ＭＴＳカウント・ブロック８８１は、ビーコン・サイクルにおける現ビーコンの番号を示す。これは、スーパーフレーム５００に現在割り当てられているデバイスがある場合、これを識別するために用いられる。即ち、当該スーパーフレーム５００におけるＭＴＳの使用を付与されているデバイスである。
【００９３】
ＭＴＳフラグ８８２は、現ビーコン５１０がデバイスに割り当てられているか否かを示す。これについては、以下で更に詳しく説明する。第１の好適な実施形態では、ＭＴＳフラグ８８２は単一ビットである。
【００９４】
遮断値８８４は、ネットワーク３００が遮断する準備をしているか否かを示す値である。これは、通常動作時には偽値に設定し、ネットワーク３００の遮断に先だって、スーパーフレーム５００のある設定数に対して真値に設定する。図７Ａで引用した好適な実施形態では、遮断値は、単一ビットであり、正常動作では偽値（例えば、「０」）に設定されるが、ネットワーク３００の遮断に先だって、３つのスーパーフレームに対して真値（例えば、「１」）に設定される。コーディネータがネットワーク遮断手順を開始している期間は、それ以上の要求は許可されない。
【００９５】
関連アドレス８８７は、現ビーコンに割り当てられているデバイスがある場合、そのＩＥＥＥ８０２ＭＡＣアドレスである。
ＲｘＴｘ表８８８は、現スーパーフレーム５００におけるＧＴＳをどのように割り当てるかについて指示を与える。図７Ａで引用した実施形態では、各スーパーフレームは６４個のＧＴＳを含む（図９参照）。ＲｘＴｘ表８８８（他の実施形態ではチャネル時間割り当て（ＣＴＡ）と呼ぶ）は、各ＧＴＳに割り当てられた送信機−受信機対のデバイスＩＤを格納する。つまり、これは、１２８個の４ビット・デバイスＩＤ、即ち、６４個の送信側デバイスＩＤおよび６４個の関連する受信側デバイスＩＤを格納する。代替実施形態では、数、期間、配置、およびタイム・スロットの割り当てに関する情報を含むチャネル時間割り当て（ＣＴＡ）を用いることができる。
【００９６】
加えて、フレーム種別の一部には、ペイロード６４０を必要としないものもある。例えば、承認（ＡＣＫ）フレームは、ペイロード６４０を必要としない。かかるフレーム６００では、ペイロード６４０およびＦＣＳ６５０双方を削除してもよい。
フレーム・チェック・シーケンス（ＦＣＳ）
ＦＣＳ６５０は、ペイロード６４０を確認するために用いられる巡回冗長チェック（ＣＲＣ）を収容する。第１の好適な実施形態では、ＦＣＳフィールドは３２ビットであり、３２ビットのＣＲＣを収容する。これに関するこれ以上の詳細は、米国規格協会（Ａｍｅｒｉｃａｎ  Ｎａｔｉｏｎａｌ  Ｓｔａｎｄａｒｄ  Ｉｎｓｔｉｔｕｔｅ）の「高度データ通信手順（ＡＤＣＣＰ：Ａｄｖａｎｃｅｄ  Ｄａｔａ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｐｒｏｃｅｄｕｒｅｓ）」、ＡＮＳＩ  Ｘ３．６６，１９７９において見ることができる。
【００９７】
ＦＣＳは、ペイロード６４０全体に対して計算され、計算フィールドとここでは呼ぶことにする。ＦＣＳを計算するには、以下の度数３２の標準的な発生多項式を用いる。
Ｇ（ｘ）＝ｘ32＋ｘ26＋ｘ23＋ｘ22＋ｘ16＋ｘ12＋ｘ11＋ｘ10＋ｘ8＋ｘ7＋ｘ5＋ｘ4＋ｘ2＋ｘ＋１                                    （３）
ＦＣＳは、以下（１）及び（２）の和（モジュロ２）の１の補数である。（１）ｘk×（ｘ31＋ｘ30＋ｘ29＋ｘ8＋・・・＋ｘ2＋ｘ＋１）をＧ（ｘ）で除算（モジュロ２）した剰余。ここで、ｋは計算フィールドにおけるビット数である。（２）計算フィールドの内容（多項式として扱う）をｘ32と乗算し、次いでＧ（ｘ）で除算した後の剰余。
【００９８】
ＦＣＳフィールド６５０は、最も高い次数の項の係数から初めて、送信する事が好ましい。
第１の好適な実施形態では、除算の初期の剰余が送信機において全て１に予め設定され、次いで計算フィールドの発生多項式Ｇ（ｘ）による除算によって変更される。この剰余の１の補数をＦＣＳフィールド６５０として、高次のビットから先に送信する。
【００９９】
受信機では、初期の剰余を全て１に予め設定し、計算フィールドおよびＦＣＳのシリアル着信ビットをＧ（ｘ）で除算すると、送信エラーが生ずることなく、一意の非ゼロの剰余値が得られる。この一意の剰余値は次の多項式となる。
【０１００】
ｘ31＋ｘ30＋ｘ26＋ｘ25＋ｘ24＋ｘ18＋ｘ15＋ｘ14＋ｘ12＋ｘ11＋ｘ10＋ｘ8＋ｘ6＋ｘ5＋ｘ4＋ｘ3＋ｘ＋１                      （４）
ポストアンブル
フレーム６００は、ポストアンブル６６０も含むことができ、これは、各フレーム６００の終端に設定されるビット・シーケンスであり、同期を取ったり、その他の管理運用上の機能を実行する際の補助となる。ポストアンブル６６０は、実施形態によっては削除することもできる。実際、以下で図７Ａに関して説明する好適な実施形態では、ポストアンブル６６０を用いない。
【０１０１】
尚、上述のフレームは一例であり、限定を意図してはいないことは言うまでもない。他のフレーム・フォーマットを有する他のフレームも使用可能である。即ち、本発明は、ＩＥＥＥ８０２．１５．３規格において用いられるフレーム・フォーマットとともに使用可能である。
［スーパーフレームの実施形態］
スーパーフレーム５００の正確な設計は、実施態様によって変更することができる。図９および図１０は、具体的なスーパーフレームの設計の好適な実施形態を２つ示す。図９は、本発明の第１の好適な実施形態によるスーパーフレームにおけるエレメントの配列を示すブロック図である。図１０は、本発明の第２の好適な実施形態によるスーパーフレームにおけるエレメントの配列を示すブロック図である。
第１の好適な実施形態
図９に示すように、送信方式９００は、利用可能な送信時間を複数のスーパーフレーム９１０に分割することを含む。この実施形態では、図７Ａに開示したＭＡＣヘッダ６２２、および図８Ａないし図８Ｈに開示したペイロード６４０を用いる。
【０１０２】
この実施形態では、個々のスーパーフレーム９１０は、ビーコン・フレーム９２０、アップリンクＭＴＳ９３０、複数のＧＴＳ９４０、およびダウンリンクＭＴＳ９５０を含む。
【０１０３】
ビーコン・フレーム９２０は、図８Ｈに示すように、ペイロード６４０がビーコン・ペイロード８８０であるフレーム６００である。これは、アソシエーションＩＤ（ＩＥＥＥ８０２．１５．３草案規格ではデバイスＩＤと呼んでいる）によって、現スーパーフレーム９１０に割り当てられているデバイス３２１〜３２５を示す。また、これは、ＲｘＴｘ表８８８を介して、個々のＧＴＳ９４０に割り当てられている送信機／受信機対も示す。
【０１０４】
代替実施形態では、ストリーム・インデックスを追加すれば、同じ発信元−宛先対間で多数のストリーミングが可能となる。これは、例えば、草案の８０２．１５．３規格ではＣＴＡにおいて見ることができ、かかる多重ストリーミングを可能にする。
【０１０５】
アップリンクＭＴＳ９３０は、現スーパーフレーム９１０に割り当てられているデバイス３２１〜３２５が信号をコーディネータ３１０にアップロードするために、確保されている。このタイム・スロットの間、現チャネル上では他の全てのデバイス３２１〜３２５は静止状態(silent)のままでいる。多数のチャネルを用いる代替実施形態では、そのチャネル上の他の全ての局は、アップリンクＭＴＳ９３０の間、静止状態のままでいなければならないが、これらは代わりのチャネル上で引き続き送信することもできる。
【０１０６】
複数のＧＴＳ９４０（第１の好適な実施形態では６４個）は、デバイス３１０、３２１〜３２５の各々が互いに通信するために確保されているタイム・スロットである。これらは、ビーコン９２０内にあるＲｘＴｘ表８８８に定義されている情報にしたがってこれを行う。各ＧＴＳ９４０は、１つ以上のデータ・フレームを送信するに十分な大きさがあることが好ましい。デバイス対に多数のＧＴＳ９４０を割り当てる場合、これらは隣接していることが好ましい。
【０１０７】
ダウンリンクＭＴＳ９５０は、コーディネータ３１０が、現スーパーフレーム９１０に割り当てられているデバイス３２１〜３２５に信号をダウンロードするために確保されている。他の全てのデバイス３２１〜３２５は、このタイム・スロットの間、全ての送信を無視することができる。
【０１０８】
スーパーフレーム９１０の長さは固定であり、データをバッファする必要性を極力抑えるために、１０乃至３０ｍｓの間の期間を有するように選択することが好ましい。
アップリンクおよびダウンリンクＭＴＳ９３０および９５０の長さは、可能な限り最大の管理フレーム、即時ＡＣＫフレーム、および送信機−受信機往復時間を処理するように選択しなければならない。ＧＴＳ９４０について、長さおよび数は、送信するフレーム６００の具体的な要件、例えば、短いＭＰＥＧフレーム、最大許容長の大きなフレーム、およびストリーミング対即時ＡＣＫ動作に対処するように選択しなければならない。
【０１０９】
いずれの任意のペイロード６４０であっても、その長さは、物理ヘッダ６２２およびＦＣＳ６５０における長さフィールドによって限定される。第１の好適な実施形態では、物理ヘッダ６２２における長さフィールドは１５ビットであり、ＦＣＳ６５０は４バイトである。したがって、ペイロード６４０は、２15−４＝３２７６６バイトよりも大きくすることは決してできない。
【０１１０】
第１の好適な実施形態では６４個のＧＴＳを用いているが、ＧＴＳの前に配置される１つのＵＭＴＳと、ＧＴＳの後ろに配置される１つのＤＭＴＳと、ＧＴＳ、ＵＭＴＳ、およびＤＭＴＳの数、分散、および配置とは、代替実施形態では、異なる実施態様による必要に応じて、変更することもできる。
第２の好適な実施形態
図１０に示すように、送信方式１０００は、利用可能な送信時間を複数のスーパーフレーム１０１０に分割することを含む。この実施形態では、図７Ｂに開示したＭＡＣヘッダ６２４を用いる。用いられるペイロード６４０は、ＩＥＥＥ８０２．１５．３規格において用いられているものであることが好ましい。
【０１１１】
この実施形態では、データ送信方式１０００は、ネットワーク３００を通じて連続するスーパーフレーム１０１０を適時に送信することを含む。各スーパーフレーム１０１０は、ビーコン１０２０、オプションの競合アクセス期間（ＣＡＰ）１０３０、および競合解放期間（ＣＦＰ）１０４０を含む。競合解放期間１０４０は、１つ以上の管理タイム・スロット（ＭＴＳ）１０５０、および１つ以上の保証タイム・スロット（ＧＴＳ）１０６０を含むことができる。
【０１１２】
管理タイム・スロット１０５０は、ダウンリンク管理タイム・スロット（ＤＭＴＳ）とし、このスロットで情報をコーディネータ３１０から非コーディネータ・デバイス３２１〜３２５に送ることができ、あるいはアップリンク管理タイム・スロット（ＵＭＴＳ）とし、このスロットで非コーディネータ・デバイス３２１〜３２５からコーディネータ３１０に情報を送ることができる。
【０１１３】
この好適な実施形態では、スーパーフレーム１０１０、１つのアップリンク、および１つのダウンリンク毎に２つの管理タイム・スロット１０５０を用いるが、代替実施形態では、異なる数の管理タイム・スロット１０５０や、アップリンクおよびダウンリンクの混合を選択することもできる。ＭＴＳは、多数のデバイス３２１〜３２５間で共有することもできる。この場合、ｓｌｏｔｔｅｄ  Ａｌｏｈａのような従来の解法を用いなければならない。加えて、ＣＡＰ１０３０を用いて管理運用情報を受け渡す場合、ＭＴＳ１０５０の使用は、減らすかまたはなくすこともできる。
【０１１４】
第２の好適な実施形態では、アクティブな一次および二次ワイヤレス・リンク３３０および３４０と同じ数の保証タイム・スロット１０６０がある。しかしながら、代替実施形態では、これを変更することもできる。いずれの任意のスーパーフレーム５００でも、保証タイム・スロット１０６０は、実際の一次および二次ワイヤレス・リンク３３０および３４０よりも多い場合も少ない場合もあり得る。この場合、コーディネータ３１０は、デバイス３１０、３２１〜３２５がどのように利用可能な保証タイム・スロット１０６０を用いればよいか指定する。
【０１１５】
この実施形態では、保証タイム・スロット１０６０のサイズは、動的であることが好ましい。ＧＴＳ１０６０が割り当てられる各送信機−受信機対には、当該対がビーコンに割り当てられるＧＴＳ１０６０の期間も通知される。これらの期間は、単一のスーパーフレーム１０１０の中でも、ＧＴＳが異なれば、その長さは異なる場合もある。更に、任意のＧＴＳ１０６０の長さおよび位置は、異なるスーパーフレーム群１０１０にわたって変更することができ、コーディネータ３１０が非コーディネータ・デバイス３２１〜３２５に変更を通知できる能力によってのみ制限される。保証タイム・スロット１０６０の開始時間および期間は、コーディネータ３１０によって決定され、実施態様に応じて、競合アクセス期間１０３０または管理タイム・スロット１０５０の１つの間に、デバイス３２１〜３２５に送られる。
【０１１６】
第２の好適な実施形態では、コーディネータ３１０は、ビーコン１０２０（いかなるフォーマットであろうが構わない）およびＭＴＳを用いて、個々のデバイス３１０、３２１〜３２５のスケジューリングを調整し、それぞれの保証タイム・スロット１０６０に組み込む。全てのデバイス３１０、３２１〜３２５は、ビーコン期間１０２０の間、コーディネータ３１０を監視(listen)している。各デバイス３２１〜３２５は、ビーコン期間１０２０中に、０個以上のタイム・スロット１０５０、１０６０を受信し、コーディネータ３１０から各開始時刻および期間を通知される。コーディネータ３１０は、管理タイム・スロット１０５０を各デバイス３２１〜３２５に自動的に割り当てる。しかしながら、保証タイム・スロット１０６０が割り当てられるのは、デバイス３２１〜３２５がそれらを要求したときのみである。
【０１１７】
ビーコン１０２０におけるチャネル時間割り当て（ＣＴＡ）フィールドは、開始時刻、パケット期間、発信元デバイスＩＤ、宛先デバイスＩＤ、およびストリーム・インデックスを含む。このビーコン情報は、ＴＬＶフォーマットと呼ばれるものを用いる。これは、種別、長さ、および値を表す。その結果、各デバイスは、いつ送信し、いつ受信するか把握している。他の全ての時間中、デバイス３１０、３２１〜３２５は、監視を中止し、電力保存モードに入ることもできる。したがって、ビーコン期間１０２０は、デバイス３１０、３２１〜３２５の送信および受信を調整するために用いられる。
【０１１８】
コーディネータ３１０は、各スーパーフレーム１０１０の開始時に、ビーコン１０２０を非コーディネータ・デバイス３２１〜３２５に送る。ビーコン１０２０により、各非コーディネータ・デバイス３２１〜３２５に、スーパーフレーム１０１０の期間、およびそのＭＡＣアドレスに関するその他の情報が通知される。各ビーコン１０２０は、正確にはＣＴＡではない情報も収容する。１つの情報片は、ビーコン期間１０２０を規定し、このビーコン期間１０２０の開始時刻および期間を記述する。別のものは、競合アクセス期間１０３０（ある場合）を規定し、この競合アクセス期間１０３０の開始時刻および期間を記述する。また、各ビーコンは多数のＣＴＡを有することもできる。タイム・スロット１０５０、１０６０（ＭＴＳかＧＴＳ）毎に１つのＣＴＡとなる。動的なタイム・スロットを用いると、スロットの割り当てにより、各スーパーフレーム毎にＣＴＡを変更することができる。
【０１１９】
送信中、各デバイス３１０、３２１〜３２５は、ビーコン１０２０を取り込み、どのタイム・スロット１０５０、１０６０が送信機または受信機のいずれかとして各デバイスに割り当てられたかを知る必要がある。デバイスがビーコン１０２０を逸した場合、データを受信している場合のように、スーパーフレーム１０１０全体を監視しなければならない。更に、実施態様によっては、スーパーフレーム１０１０の期間中は送信を許可されない場合もある。何故なら、いつ送信が許可されるかわからないからである。これは、データ送信の中断を招く虞れがあるので、システムにとっては有害である。
【０１２０】
ネットワークは、オプションの競合アクセス期間１０３０、管理タイム・スロット１０５０、または双方を通じて、コーディネータ３１０および種々のデバイス３２１〜３２５間で制御および管理運用情報を受け渡すことができる。例えば、これは、ネットワーク３００に加入したい新たなデバイスに関する情報も含むことができる。個々の選択肢のどれを用いるかは、個々の実施態様によって決められる。競合アクセス期間１０３０、１つ以上の管理タイム・スロット１０５０、または双方の何らかの組み合わせを含むこともできる。
【０１２１】
個々のデバイス３１０、３２１〜３２５は、競合解放期間１０４０中に、ビーコン１０２０に定義されているスケジュールにしたがって、フレームを送信する。任意の保証タイム・スロット１０６０に割り当てられている１対のデバイス３１０、３２１〜３２５は、それらに割り当てられているＧＴＳ１０６０を用いて、互いの間でフレーム１０７０を送信する。これらは、指定された送信機から指定された受信機へのデータ・フレーム、または指定された受信機から指定された送信機への承認（ＡＣＫ）フレームとすることができる。
【０１２２】
上記したように、ガード・タイム１０８０をフレーム間に設けて、クロック精度の誤差や、デバイス３１０、３２１〜３２５の空間位置に基づく伝搬遅延の相違に対処することが好ましい。
【０１２３】
ＣＡＰ１０３０やＭＴＳ１０５０がないスーパーフレームでは、ビーコン１０２０および最初のＧＴＳ１０５０間に遅延を設け、個々のデバイス３２１〜３２５にビーコン１０２０を処理する時間を与えるようにすることが望ましい。そうでない場合、最初のＧＴＳ１０６０に割り当てられたデバイス３２１〜３２５が定刻に送信／聴取モードに入り、指定のスロット１０６０を用いることができなくなる場合もある。
［巡回ビーコン］
アドホック・ネットワーク３００における問題の１つは、デバイスのネットワーク３００への加入および離脱、ならびにコーディネータ３１０およびデバイス３２１〜３２５間における管理運用フレームの受け渡しの調整である。本発明はこの問題に取り組むにあたって、巡回ビーコンを用いて、ネットワーク３００およびその中にあるデバイス３１０、３２１〜３２５を監視するようにした。
【０１２４】
各ネットワークは、ある設定した数、Ｎ個の許容デバイス３１０、３２１〜３２５を有することが好ましい。好適な実施形態では、Ｎは、４、８のような２の累乗であるが（例えば、１つのコーディネータ３１０および３つの非コーディネータ・デバイス３２１〜３２５、または１つのコーディネータ３１０および７つの非コーディネータ・デバイス３２１〜３２５）、許容可能なデバイスの正確な数は変化する可能性がある。Ｎに対するネットワークの最大値を決定できるようにするには、ネットワーク３００が利用可能な送信時間を広げることができ、それでもなお各々に、所望の動作レベルを維持できるのに最大限そして十分な頻度で通信させることが可能な、デバイス３１０、３２１〜３２５の数を求める。２の累乗が好ましいが、必ずしもそうでなくてもよい。
【０１２５】
スーパーフレーム５００を互いにまとめて、Ｎ個のスーパーフレームの束にする。このグループ内では、１つのスーパーフレーム５００を、その時点でネットワーク３００内にある各デバイス３１０、３２１〜３２５に割り当てる。好ましくは、１組のスーパーフレーム（例えば、最初のスーパーフレーム）を常にコーディネータ３１０に割り当てる。
【０１２６】
一方、非コーディネータ・デバイス３２１〜３２５の各々は、それに割り当てられたスーパーフレーム５００を用いて、コーディネータ３１０からの管理運営コマンドを（例えば、管理タイム・スロットにおいて）送信および受信することができる。コーディネータ３１０に割り当てられたスーパーフレーム５００を用いることによって、ネットワーク外部のデバイスがコーディネータと通信し、例えば、ネットワーク３００への加入を要求することができる。また、これらを用いると、コーディネータが全ての非コーディネータ・デバイス３２１〜３２５に情報を送ることが可能となる。加えて、実施形態によっては、割り当てられていないスーパーフレーム５００も、ネットワーク外部のデバイスがコーディネータ３１０と通信するために用いることが可能となる。
【０１２７】
コーディネータ３１０は、ビーコン５１０の中で、どのデバイス３１０、３２１〜３２５が任意のスーパーフレーム５００に割り当てられているかを示す。このために、スーパーフレーム５００の任意のデバイス３１０、３２１〜３２５への割り当てを、ビーコン５１０の任意のデバイス３１０、３２１〜３２５への割り当てと呼ぶこともある。
【０１２８】
代替実施形態では、コーディネータ３１０は、多数のデバイスを単一のスーパーフレームに割り当てることもできる。例えば、スーパーフレームは、２つのデバイスに対する管理タイム・スロットを含むこともできる。その結果、２つのデバイスを当該スーパーフレームと関連付けることができ、その後にこれが「割り当てられる」。
【０１２９】
図１１および図１２Ａ乃至図１２Ｄは、本発明の好適な実施形態による巡回ビーコン・スーパーフレーム構造を示すブロック図である。図１１は、巡回ビーコン・スーパーフレーム構造としたスーパーフレームの繰り返しを示すブロック図である。図１２Ａ乃至図１２Ｄは、図１１のスーパーフレームの構造を示すブロック図である。
【０１３０】
図１１および図１２Ａ乃至図１２Ｄに開示した実施形態では、４つのデバイス３１０、３２１〜３２５がネットワーク３００に許可されている。これが意味するのは、ネットワーク３００は最大１つのコーディネータ３１０と３つの非コーディネータ・デバイスを許容するということである。代替実施形態では、この数が変わることもあり得る。例えば、代替実施形態では、８つまたは１６個のデバイスを有することもあり得る。
スーパーフレーム構造
図１１に示すように、各デバイス３１０、３２１〜３２５にはスーパーフレームが割り当てられる。コーディネータにはコーディネータ・スーパーフレーム１１０１が割り当てられ、第１デバイスには第１非コーディネータ・デバイス・スーパーフレーム１１０２が割り当てられ、第２非コーディネータ・デバイスには第２デバイス・スーパーフレーム１１０３が割り当てられ、第３非コーディネータ・デバイスには第３デバイス・スーパーフレーム１１０４が割り当てられている。これらのスーパーフレーム１１０１、１１０２、１１０３、および１１０４は、ネットワーク３００が動作している限り、直列に繰り返される。
【０１３１】
これは、ネットワーク３００内のデバイス３１０、３２１〜３２５が４つ未満になっても、変わらない。例えば、ネットワーク３００内に２つのデバイスしかない場合（即ち、コーディネータ３１０および１つの非コーディネータ・デバイス３２１〜３２５）でも、送信時間はなおも４つのスーパーフレーム１１０１、１１０２、１１０３、および１１０４に分割され、各デバイス３１０、３２１〜３２５が単一のスーパーフレームに割り当てられる。
【０１３２】
しかしながら、代替実施形態では、ネットワーク３００内の、充填されていない、未割り当てスーパーフレームの数を、最大許容スーパーフレーム数までの設定数のみとするように、コーディネータ３１０がサイクルを選択することができる。例えば、上述の状況では、最大数のデバイスが４つであり、２つのデバイスしかない場合、コーディネータ３１０は３つのスーパーフレーム１１０１、１１０２、および１１０３を巡回させ、２つが割り当て済みで１つが未割り当てのスーパーフレームとすることができる。
【０１３３】
図１２Ａに示すように、コーディネータ・スーパーフレーム１１０１は、コーディネータ・ビーコン１２１１および競合解放期間１２３１を含む。競合解放期間１２３１は、コーディネータ・アップリンクＭＴＳ（ＵＭＴＳ）１２５１、コーディネータ・ダウンリンクＭＴＳ（ＤＭＴＳ）１２６１、および複数のＧＴＳ１２７１を含む。
【０１３４】
コーディネータ・ビーコン１２１１は、それがコーディネータ３１０に割り当てられていることを示す情報を含む（いずれのネットワークにもコーディネータ３１０が常に存在する）。コーディネータＵＭＴＳ１２５１は、コーディネータのネットワーク全体へのブロードキャストのため、またはネットワークに加入しようとするデバイスからのアソシエーション要求のために用いられる。コーディネータＤＭＴＳ１２６１は、コーディネータのネットワーク全体へのブロードキャストのために用いられる。ＧＴＳ１２７１は、デバイス３１０、３２１〜３２５間で情報フレームを送信するために用いられる。
【０１３５】
図１２Ｂに示すように、第１デバイス・スーパーフレーム１１０２は第１デバイス・ビーコン１２１２、および第１デバイス解放期間１２３２を含む。競合解放期間１２３２は、第１デバイスアップリンクＭＴＳ（ＵＭＴＳ）１２５２、第１デバイス・ダウンリンクＭＴＳ（ＤＭＴＳ）１２６２、および複数のＧＴＳ１２７２を含む。
【０１３６】
第１デバイス・ビーコン１２１２は、第１デバイス・スーパーフレーム１１０２がデバイス３１０、３２１〜３２５に割り当てられているか否かを示す情報を含み、割り当てられている場合、どのデバイス３１０、３２１〜３２５にそれが割り当てられているかを示す情報も含む。第１デバイスＵＭＴＳ１２５２は、第１デバイス（割り当てられた場合）からコーディネータ３１０に管理運営要求を送るために用いられる。第１デバイスＤＭＴＳ１２６２は、コーディネータ３１０から第１デバイス（割り当てられた場合）に管理運営命令を送るために用いられる。ＧＴＳ１２７２は、デバイス３１０、３２１〜３２５間で情報フレームを送信するために用いられる。
【０１３７】
図１２Ｃに示すように、第２デバイス・スーパーフレーム１１０３は、第２デバイス・ビーコン１２１３および第２デバイス解放期間１２３３を含む。競合解放期間１２３３は、第２デバイス・アップリンクＭＴＳ（ＵＭＴＳ）１２５３、第２デバイス・ダウンリンクＭＴＳ（ＤＭＴＳ）１２６３、および複数のＧＴＳ１２７３を含む。
【０１３８】
第２デバイス・ビーコン１２１３は、第２デバイス・スーパーフレーム１１０３がデバイス３１０、３２１〜３２５に割り当てられているか否かを示す情報を含み、割り当てられている場合、どのデバイス３１０、３２１〜３２５にそれが割り当てられているかを示す情報も含む。第２デバイスＵＭＴＳ１２５３は、第２デバイス（割り当てられた場合）からコーディネータ３１０に管理運営要求を送るために用いられる。第２デバイスＤＭＴＳ１２６３は、コーディネータ３１０から第２デバイス（割り当てられた場合）に管理運営命令を送るために用いられる。ＧＴＳ１２７３は、デバイス３１０、３２１〜３２５間で情報フレームを送信するために用いられる。
【０１３９】
図１２Ｄに示すように、第３デバイス・スーパーフレーム１１０４は、第３デバイス・ビーコン１２１４、および第３デバイス解放期間１２３４を含む。競合解放期間１２３４は、第３デバイス・アップリンクＭＴＳ（ＵＭＴＳ）１２５４、第３デバイス・ダウンリンクＭＴＳ（ＤＭＴＳ）１２６４、および複数のＧＴＳ１２７４を含む。
【０１４０】
第３デバイス・ビーコン１２１４は、第３デバイス・スーパーフレーム１１０４がデバイス３１０、３２１〜３２５に割り当てられているか否かを示す情報を含み、割り当てられている場合、どのデバイス３１０、３２１〜３２５にそれが割り当てられているかを示す情報も含む。第３デバイスＵＭＴＳ１２５４は、第３デバイス（割り当てられた場合）からコーディネータ３１０に管理運営要求を送るために用いられる。第３デバイスＤＭＴＳ１２６４は、コーディネータ３１０から第３デバイス（割り当てられた場合）に管理運営命令を送るために用いられる。ＧＴＳ１２７４は、デバイス３１０、３２１〜３２５間で情報フレームを送信するために用いられる。
【０１４１】
この実施形態は、設計によってはＣＡＰ５２０を除去してもよいことを例示するために、ＣＡＰ５２０を有さないものとして示した。この実施形態では、コーディネータ３１０と非コーディネータ・デバイス３２１〜３２５との間の運用管理は、ＭＴＳ１２５１、１２６１、１２５２、１２６２、１２５３、１２６３、１２５４、および１２６４の使用のみによって行われる。しかしながら、代替実施形態では、各スーパーフレーム１１０１、１１０２、１１０３、および１１０４にＣＡＰ５２０を含むこともできる。
【０１４２】
加えて、この実施形態は、２つのＭＴＳ、ＵＭＴＳ１２５１、１２５２、１２５３、１２５４、およびＤＭＴＳ１２６１、１２６２、１２６３、１２６４を有するものとして示した。上記したように、ＭＴＳの数、分散、および配置は、代替実施形態では変更可能である。
ビーコン情報
上記したように、各ビーコンは、その割り当てステータスに関して、２つの重要な情報片、即ち、（１）それがデバイス３１０、３２１〜３２５に割り当てられているか、（２）割り当てられている場合、どのデバイス３１０、３２１〜３２５にそれが割り当てられているか、を含む。これら２つの情報片は、種々の異なる方法で開示することができる。
【０１４３】
例えば、第１の好適な実施形態では、ビーコン・フレームは、スーパーフレームが割り当てられているとき、およびそれが空いているときを示すビット（ＭＴＳフラグ８８２）、および当該ビーコンに関連するスーパーフレームに割り当てられている（ものがある場合）デバイス３１０、３２１〜３２５のデバイスＩＤを示すカウンタ（ＭＴＳカウンタ８８１）を含む。
【０１４４】
任意のスーパーフレームを監視しているデバイスは、ＭＴＳフラグ８８２をチェックすることによって、それが割り当てられているか否か通知することができる。そして、ＭＴＳフラグ８８２が、スーパーフレームが割り当てられていることを示す場合、デバイスはＭＴＳカウント８８１をチェックし、どのデバイスがスーパーフレームに割り当てられているのかをチェックする。ネットワーク３００内のデバイスは、この情報を用いて、デバイスに割り当てられているスーパーフレームを見つけることができる。ネットワーク３００外部のデバイスがこの情報を用いると、要求のための空のスーパーフレームや、他の管理運用情報をコーディネータ３１０に受け渡すためのコーディネータ・スーパーフレームを見つけることができる。
【０１４５】
代替実施形態では、ビーコン・フレームは、任意のスーパーフレームに割り当てられているデバイスに関連する識別子（デバイスＩＤ、ＭＡＣアドレスなど）を保持するレジスタを単に含むだけとすることもできる。スーパーフレームに割り当てられているデバイスがない場合、レジスタには、許容デバイスがないことに対応するが、未割り当てのスーパーフレームを示す、ファントム・アドレス(phantom address)を入れておくことができる。
【０１４６】
任意のスーパーフレームを確認しているデバイスは、この識別子レジスタをチェックすることによって、それが割り当てられているか否か通知することができる。レジスタが有効な識別子（例えば、有効なデバイスＩＤ）を有する場合、デバイスは、スーパーフレームが割り当てられたことがわかる。即ち、レジスタが、コーディネータに割り当てられた識別子を有する場合、デバイスは、この特定のスーパーフレームがコーディネータに割り当てられていることがわかる。識別子レジスタがファントム・アドレスを有する場合、デバイスは、スーパーフレームが未割り当てであったことがわかり、それに応じて動作することができる。
【０１４７】
前述のように、ネットワーク３００内では、デバイスはこの情報を用いて、それが割り当てられているスーパーフレームを見つけることができる。ネットワーク外部のデバイスがこの情報を用いると、要求のための空のスーパーフレームや、他の管理運用情報をコーディネータ３１０に受け渡すためのコーディネータ・スーパーフレームを見つけることができる。また、この情報を用いると、あるビーコンに割り当てられているデバイスに対するＭＡＣアドレスを発見することもできる。
【０１４８】
非コーディネータ・デバイス３２１〜３２５に割り当てられているスーパーフレーム１１０２、１１０３、１１０４の間、ＵＭＴＳおよびＤＭＴＳを用いると、コーディネータ３１０との間で管理運用フレームの受け渡しを行うことができる。割り当てられていないスーパーフレームの間、任意のデバイスは、スーパーフレームのＭＴＳの間、静止状態のままでいる。しかしながら、そのスーパーフレームの間、それに割り当てられたＧＴＳを自由に用いることができる。
【０１４９】
新たなデバイスがネットワークに加入することを望む場合、ビーコンを求めて監視することから開始する。一旦ビーコンを発見すると、未割り当てのスーパーフレームに遭遇するまで待つ。未割り当てのフレームを発見した場合、当該スーパーフレームのアップリンクＭＴＳの間に、加入要求を送る。
【０１５０】
しかしながら、Ｎ個のスーパーフレームの束全体を調べても未割り当てのスーパーフレームを検出できなかった場合、ネットワークが満杯であることがわかり、適切な処置を講ずる。例えば、エラー・メッセージをそのユーザまたは上位の層に送る、ある設定時間期間の後に再試行する、チャネルを変更する等である。
【０１５１】
上記したように、代替実施形態では、多数のデバイスを単一のスーパーフレームに割り当てることができ、それに応じて管理タイム・スロットを割り当てることができる。この場合、スーパーフレームは、その最大数のデバイスに割り当てられるまで、未割り当てのままでいる。新たなデバイスがスーパーフレームの割り当てステータスをチェックする場合、スーパーフレーム内には全く空き空間がないか否か調べるためにチェックする必要がある。前述のように、このチェックは、スーパーフレームに割り当てられているデバイスを示すフラグ、または一連のデバイスＩＤによって行うことができる。
［ネットワークの加入または開始］
図１３乃至図１６は、デバイスがネットワークが存在するか否か判定し、続いてネットワークに加入しようとするか、または存在しない場合はネットワークを作成する過程を示す。図１３は、本発明の好適な実施形態にしたがって、既存のネットワークがあるか否かを識別する開始プロセスのフロー・チャートである。図１４は、本発明の好適な実施形態によるアソシエーション・プロセスのフロー・チャートである。図１５は、本発明の好適な実施形態による、ネットワークを開始する新たなデバイスのＳＤＬメッセージのシーケンス図である。図１６は、本発明の好適な実施形態による開始およびアソシエーション・プロセスの一例のＳＤＬメッセージのシーケンス図である。
【０１５２】
図１３に示すように、新たなデバイスが以下の開始手順１３００を遂行し、ネットワークが存在するか否か判定を行う。この開始手順１３００では、新たなデバイスは、まず設定されているビーコン間隔だけ待機し、既存のネットワークからのビーコン５１０を検出したか否か調べるためにチェックする（ステップ１３０５）。ビーコン間隔は、少なくともスーパーフレーム５００の期間とするとよい。何故なら、ビーコンは一般にスーパーフレーム５００毎に１回繰り返すからである。
【０１５３】
ビーコン間隔の終了時に、信号が受信されなかった場合（ステップ１３１０）、デバイスは、追加のランダムな間隔だけビーコンを求めて監視することが好ましい（ステップ１３１５）。このランダムな間隔は、ビーコン間隔よりも短いが、ビーコン送信期間よりも長いことが好ましい。
【０１５４】
ランダムな間隔の終了時に、信号が受信されなかった場合（ステップ１３２０）、デバイスは、ネットワーク３００がないと見なし、それ自体がコーディネータ３１０として、新たなネットワーク３００を開始する（ステップ１３２５）。次いで、デバイス（既にコーディネータ３１０）は、続いて新たなビーコン５１０を送出し（ステップ１３３０）、コーディネータ３１０としての通常の動作を行う。
【０１５５】
逆に、ビーコン間隔（ステップ１３１０）またはランダムな間隔（ステップ１３２０）のいずれかの後に、デバイスが信号を受信した場合、デバイスは、その信号がビーコン５１０であるか否か判定を行う（ステップ１３３５）。
【０１５６】
受信した信号がビーコン５１０である場合、デバイスは既存のネットワーク３００が存在すると判断し、そのネットワークのコーディネータ３１０との参入手順を実行し、加入を要求する（ステップ１３４０）。
【０１５７】
しかし、受信した信号がビーコン５１０ではない場合、デバイスは、エラー状態に入る。何故なら、所望の帯域幅が他の信号によって塞がれているからである（ステップ１３４５）。この場合、デバイスは、個々の実施態様に応じて、チャネルを切り替え、その後に、再度試行する、諦める、そのユーザまたは上位レベルにエラー・メッセージを送る等を行うことができる。
【０１５８】
ランダム間隔は必須ではないが、動作を促進するために好適な実施形態では含まれている。これは、多数のデバイスが同時に開始手順１３００に入るような事態が起こり得るからである。例えば、ネットワーク３００を解体する場合、多数のデバイスが全て、ネットワーク３００の解体時に直ちに開始手順１３００を開始する。ランダム間隔を含ませることにより（ステップ１３１５）、この手順は、多数のデバイスが同時に新たなビーコンを送ろうとする（ステップ１３３０）可能性、即ちビーコンの衝突が発生する可能性を低下させる。
【０１５９】
図１４に示すように、各デバイスは、それが既存のネットワーク３００に加入したいときに、参入手順を実行する。参入手順は、デバイスがビーコン５１０を受信すると開始する（ステップ１４０５）。
【０１６０】
図１１に関して上記したように、ネットワーク３００におけるスーパーフレーム５００は、Ｎ個のスーパーフレーム１１０１、１１０２、１１０３、１１０４（ネットワーク３００内にある可能性のあるデバイス毎に１つ）に分割されており、ネットワーク動作の間、巡回的に繰り返される。これらのスーパーフレーム１１０１、１１０２、１１０３、１１０４は、各デバイス位置に割り当てられ、各々、その関連するビーコン５１０におけるデバイスのステータスを示す。
【０１６１】
ステップ１４０５においてビーコン５１０を受信すると、デバイスは、ビーコン５１０が、現スーパーフレーム１１０１、１１０２、１１０３、１１０４が割り当てられていることを示すか否か判定を行う（ビーコン５１０が割り当てられていると言うこともある）（ステップ１４１０）。
【０１６２】
受信したビーコン５１０が、現スーパーフレーム１１０１、１１０２、１１０３、１１０４が未割り当てであることを示す場合、デバイスはアソシエーション要求フレームを、次の適切な時点、例えば、未割り当てスーパーフレームのＵＭＴＳの間に、コーディネータ３１０に送る（ステップ１４１５）。２つのデバイスが衝突した（即ち、これらが同時にコーディネータ３１０に送信しようとした）場合、これらは競合解消アルゴリズム、例えば、ｓｌｏｔｔｅｄ  Ａｌｏｈａを用いる。
【０１６３】
ステップ１４１０において、受信したビーコン５１０が、それが既に割り当てられていることを示す場合、デバイスは、可能なビーコン全てを一巡したか否か判定を行う（ステップ１４２０）。言い換えると、ネットワーク３００においてＮ個の連続するビーコン３２１〜３２５をチェックし終えたか否か判定を行う。ここで、Ｎは許容デバイス３１０の総数である。
【０１６４】
デバイスが未だ可能なビーコン全てを一巡していない場合、次のビーコンを待ち（ステップ１４２５）、次いでそのビーコンを、以前のビーコンに行ったように、処理する（ステップ１４１０およびその後のステップ）。
【０１６５】
一旦全てのビーコンを処理し終え、これらが全て割り当てられていると判定した場合、デバイスは、ネットワークが満杯であると判断し、必要な「ネットワーク満杯」プロセスを実行する（ステップ１４３０）。これは、デバイスのオペレータまたは上位層に、ネットワークが満杯であることを報告し、チャネルを切り替えること、または後の時点まで待機して再度試行することを含むことができる。
【０１６６】
図１５は、開始プロセスを実行する新たなデバイスのＳＤＬメッセージのシーケンス図の一例である。図１５に示すように、新たなデバイス１５０５は、開始プロセスを実行する際、新たなデバイス・タイムライン１５１０に沿って進む。
【０１６７】
最初に、新たなデバイス１５０５は、ビーコン・タイマ１５１５をビーコン間隔に設定し、その時間期間だけ待ち、着信するビーコンを探す（図１３のステップ１３０５を実行する）。
【０１６８】
ビーコン間隔の終了時に、新たなデバイス１５０５は、着信ビーコンを受信していないので、ランダム・タイマ１５２０をランダム間隔に設定し、その時間時間だけ待ち、再度着信するビーコンを探す（ステップ１３１０から分岐「Ｎ」をたどり、図１３のステップ１３１５を実行する）。
【０１６９】
ランダム間隔の終了時に、新たなデバイス１５０５は未だ着信ビーコンを受信していないので、コーディネータ状態１５２５に入り、それ自体がコーディネータ３１０となって、新たなネットワーク３００を開始する（ステップ１３２０から分岐「Ｎ」をたどり、図１３のステップ１３２５を実行する）。
【０１７０】
一旦コーディネータ状態１５２５に入ると、新たなデバイス１５０５は、ビーコン１５３０を送り始め、新たなネットワーク３００のコーディネータ３１０として動作し続ける（図１３のステップ１３３０を実行する）。
【０１７１】
図１６は、開始および参入プロセスの一例のＳＤＬメッセージのシーケンス図である。このプロセスでは、許容ネットワーク・サイズを４個のデバイスとする。
図１６に示すように、新たなデバイス１６０５は、開始プロセス１５００を開始する際に、新たなデバイス・タイムライン１６１０に沿って進み、参入プロセスに続く。最初に、新たなデバイス１５０５は、ビーコン・タイマ１５１５をビーコン間隔に設定し、その時間期間だけ待ち、着信するビーコンを探す（図１３のステップ１３０５を実行する）。
【０１７２】
この場合、ビーコン間隔が終了する前に、新たなデバイス１５０５は、コーディネータ１６４０がコーディネータ・タイムライン１６４５に沿って送ったビーコン１６３５を受信する（図１３のステップ１３１０から「Ｙ」の分岐をたどる）。これによって、ビーコン間隔タイマ１５１５を中断し、新たなデバイス１５０５は、着信ビーコンの処理を開始する。この場合、新たなデバイス１５０５は、着信信号がビーコンであると判断し、参入手順を開始する（ステップ１３３５を実行し、図１３の「Ｙ」分岐をたどる）。
【０１７３】
新たなデバイスは、最初の着信ビーコン１６３５が割り当て済みのビーコンであると判定する。これは、受信した最初のビーコンに過ぎないので、引き続き次のビーコンを待つ（ステップ１４１０から「Ｙ」の分岐をたどり、ステップ１４２０から「Ｎ」の分岐をたどり、図１４のステップ１４２５を実行する）。
【０１７４】
次に、新たなデバイス１５０５は、次のビーコン１６５０を受信し、このビーコンも割り当て済みであると判断する。これまでビーコンを一巡した回数をチェックし（２回）、未だ全ての許容ビーコンに巡り合っていないと判断する。したがって、引き続き次のビーコンを待つ（ステップ１４０５を実行し、ステップ１４１０から「Ｙ」の分岐をたどり、ステップ１４２０から「Ｎ」の分岐をたどり、図１４のステップ１４２５を実行する）。
【０１７５】
次で、新たなデバイス１５０５は次のビーコン１６５５を受信し、このビーコンが未割り当てであると判断する。次いで、コーディネータが監視する次の適切な時点まで待ち、アソシエーション要求１６６０をコーディネータ１６４０に送る（ステップ１４０５を実行し、ステップ１４１０から「Ｎ」の分岐をたどり、図１４のステップ１４１５を実行する）。
【０１７６】
新たなデバイス１５０５からのアソシエーション要求１６６０を受信すると、コーディネータ１６４０は、承認（ＡＣＫ）１６７０およびアソシエーション応答１６７５を新たなデバイス１５０５に送る。この場合、コーディネータ１６４０は、未割り当てのビーコンおよびそれに関連するスーパーフレームを新たなデバイス１５０５に割り当てる。新たなデバイス１５０５は、ＡＣＫ１６８０をコーディネータ１６４０に送り、ネットワーク３００における通常動作を続ける。
【０１７７】
以上の教示を参照すれば、本発明の各種の変更や改良が可能であることは明らかである。例えば、ワイヤレス・ネットワークの場合について説明したが、本開示の方法は、有線ネットワークにも適用可能である。したがって、添付した特許請求の範囲内において、本発明は、ここに具体的に記載した以外でも実施可能であることは理解されるべきである。
【図面の簡単な説明】
【０１７８】
【図１】コンピュータ通信アーキテクチャのＯＳＩ規格のブロック図。
【図２】コンピュータ通信アーキテクチャのＩＥＥＥ８０２規格のブロック図。
【図３】ワイヤレス・ネットワークのブロック図。
【図４】図３のワイヤレス・ネットワークにおけるデバイス即ちコーディネータのブロック図。
【図５】本発明の好適な実施形態によるスーパーフレームのブロック図。
【図６】本発明の好適な実施形態によるフレームのブロック図。
【図７Ａ】本発明の好適な実施形態による図６のＭＡＣヘッダを示すブロック図。
【図７Ｂ】本発明の好適な実施形態による図６のＭＡＣヘッダを示すブロック図。
【図８Ａ】本発明の第１の好適な実施形態による、図６におけるペイロードの一例を示すブロック図。
【図８Ｂ】本発明の第１の好適な実施形態による、図６におけるペイロードの一例を示すブロック図。
【図８Ｃ】本発明の第１の好適な実施形態による、図６におけるペイロードの一例を示すブロック図。
【図８Ｄ】本発明の第１の好適な実施形態による、図６におけるペイロードの一例を示すブロック図。
【図８Ｅ】本発明の第１の好適な実施形態による、図６におけるペイロードの一例を示すブロック図。
【図８Ｆ】本発明の第１の好適な実施形態による、図６におけるペイロードの一例を示すブロック図。
【図８Ｇ】本発明の第１の好適な実施形態による、図６におけるペイロードの一例を示すブロック図。
【図８Ｈ】本発明の第１の好適な実施形態による、図６におけるペイロードの一例を示すブロック図。
【図９】本発明の第１の好適な実施形態によるスーパーフレームにおけるエレメントの構成を示すブロック図。
【図１０】本発明の第２の好適な実施形態によるスーパーフレームにおけるエレメントを示すブロック図。
【図１１】巡回ビーコン・スーパーフレーム構造におけるスーパーフレームの繰り返しを示すブロック図。
【図１２Ａ】図１１のスーパーフレームの構造を示すブロック図。
【図１２Ｂ】図１１のスーパーフレームの構造を示すブロック図。
【図１２Ｃ】図１１のスーパーフレームの構造を示すブロック図。
【図１２Ｄ】図１１のスーパーフレームの構造を示すブロック図。
【図１３】本発明の好適な実施形態による既存のネットワークがあるか否か特定する開始7プロセスのフロー・チャート。
【図１４】本発明の好適な実施形態によるアソシエーション・プロセスのフロー・チャート。
【図１５】本発明の好適な実施形態にしたがってネットワークを開始する新たなデバイスのＳＤＬメッセージ・シーケンス・チャート。
【図１６】本発明の好適な実施形態による開始およびアソシエーション・プロセスの一例のＳＤＬメッセージ・シーケンス・チャート。
【図１】
2005538574.tif 000003
【図２】
2005538574.tif 000004
【図３】
2005538574.tif 000005
【図４】
2005538574.tif 000006
【図５】
2005538574.tif 000007
【図６】
2005538574.tif 000008
【図７Ａ】
2005538574.tif 000009
【図７Ｂ】
2005538574.tif 000010
【図８Ａ】
2005538574.tif 000011
【図８Ｂ】
2005538574.tif 000012
【図８Ｃ】
2005538574.tif 000013
【図８Ｄ】
2005538574.tif 000014
【図８Ｅ】
2005538574.tif 000015
【図８Ｆ】
2005538574.tif 000016
【図８Ｇ】
2005538574.tif 000017
【図８Ｈ】
2005538574.tif 000018
【図９】
2005538574.tif 000019
【図１０】
2005538574.tif 000020
【図１１】
2005538574.tif 000021
【図１２Ａ】
2005538574.tif 000022
【図１２Ｂ】
2005538574.tif 000023
【図１２Ｃ】
2005538574.tif 000024
【図１２Ｄ】
2005538574.tif 000025
【図１３】
2005538574.tif 000026
【図１４】
2005538574.tif 000027
【図１５】
2005538574.tif 000028
【図１６】
2005538574.tif 000029
【国際調査報告】
2005538574.tif 000030
2005538574.tif 000031
2005538574.tif 000032