JPWO2004071020A1 - 通信方法及び通信装置、並びにコンピュータプログラム - Google Patents

Abstract

無線ＬＡＮシステムなどの通信システムでの伝送時の、送信側での滞留や受信側での遅延などの問題を解決するために、他の局から送信される信号の検出により、他局とパケットの通信タイミングが衝突しないアクセス制御を行う場合に、ネットワーク内の各通信局は、ネットワークに関する情報を記述したビーコンを送信して、そのビーコン信号の送信に前後する時間帯に受信動作を行う状態を設定するようにした。かかる処理を行うことで、ネットワーク内の各通信局で送受信データが存在しない場合には、最小限の送受信動作にてシステムを構成可能であり、かつ、変動する送受信データ量に従って、送受信動作状態を変遷させることにより、必要最低限の送受信動作にて、極力小さなレイテンシでのデータ転送を可能とすることができる。

Description

本発明は、例えばデータ通信などを行う無線ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ：構内情報通信網）システムに適用して好適な通信方法及び通信装置に関する。特に、マスタ局、スレーブ局の制御、被制御の関係なしに自立分散型のネットワークを構築制御局なしで運用する場合に適用して好適な、通信方法及び通信装置に関する。
さらに詳しくは、本発明は、各通信局がネットワーク情報などを記載したビーコンを所定のフレーム周期毎に報知し合うことにより自律分散型の無線ネットワークを形成する無線通信方法及び無線通信装置、並びにコンピュータプログラムに係り、特に、各通信局が互いに送信するビーコンの衝突を回避しながら自律分散型の無線ネットワークを形成する無線通信方法及び無線通信装置、並びにコンピュータプログラムに関する。

従来、無線ＬＡＮシステムのメディアアクセス制御としては、ＩＥＥＥ（Ｔｈｅ Ｉｎｓｔｉｔｕｔｅ ｏｆ Ｅｌｅｃｔｒｉｃａｌ ａｎｄ Ｅｌｅｃｔｒｏｎｉｃｓ Ｅｎｇｉｎｅｅｒｓ）８０２．１１方式で規定されたアクセス制御などが広く知られている。ＩＥＥＥ８０２．１１方式の詳細については、Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｓｔａｎｄａｒｄ ＩＳＯ／ＩＥＣ ８８０２−１１：１９９９（Ｅ）ＡＮＳＩ／ＩＥＥＥ Ｓｔｄ ８０２．１１，１９９９ Ｅｄｉｔｉｏｎ，Ｐａｒｔ１１：Ｗｉｒｅｌｅｓｓ ＬＡＮ Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ（ＭＡＣ）ａｎｄ Ｐｈｙｓｉｃａｌ Ｌａｙｅｒ（ＰＨＹ）Ｓｐｅｃｉｆｉｃａｔｉｏｎｓなどに記載されている。ＩＩＥＥ８０２．１１方式におけるネットワーキングは、ＢＳＳ（Ｂａｓｉｃ Ｓｅｒｖｉｃｅ Ｓｅｔ）の概念に基づいている。ＢＳＳはアクセスポイント：ＡＰ（Ａｃｃｅｓｓ Ｐｏｉｎｔ）のようなマスタ制御局が存在するインフラモードで定義されるＢＳＳと、複数の端末局：ＭＴ（Ｍｏｂｉｌｅ Ｔｅｒｍｉｎａｌ）のみにより構成されるアドホックモードで定義されるＩＢＳＳ（Ｉｎｄｅｐｅｎｄｅｎｔ ＢＳＳ）の二種類がある。
インフラモード時のＩＥＥＥ８０２．１１の動作について図２７を用いて説明する。インフラモードのＢＳＳにおいては、無線通信システム内にコーディネーションを行うアクセスポイントが存在し、アクセスポイントと、そのアクセスポイントの周辺に存在する端末局ＭＴとの間で通信が行われる。アクセスポイントは適当な時間間隔でビーコンと呼ばれる制御信号を送信し、このビーコンを受信可能である端末局ＭＴはアクセスポイントが近隣に存在することを認識し、さらに該アクセスポイントとの間でコネクション確立を行う。図２７では、図２７（ａ）に示した通信局ＳＴＡ１がアクセスポイントで、図２７（ｂ）に示した通信局ＳＴＡ０が端末局ＭＴである場合を記載している。通信局ＳＴＡ１は、図２７に記したように、一定の時間間隔でビーコン（Ｂｅａｃｏｎ）を送信する。
次回のビーコンの送信時刻は、ターゲットビーコン送信時刻（ＴＢＴＴ：Ｔａｒｇｅｔ Ｂｅａｃｏｎ Ｔｒａｎｓｍｉｔ Ｔｉｍｅ）というパラメータにてビーコン内で報知されており、時刻がＴＢＴＴになると、アクセスポイントはビーコン送信手順を動作させている。また、周辺の端末局ＭＴは、ビーコンを受信し、内部のＴＢＴＴフィールドをデコードすることにより次回のビーコン送信時刻を認識することが可能なため、アクセスポイントと通信する必要がないと思われる時間帯においては、次回あるいは複数回先のＴＢＴＴまで受信部の電源を落としスリープ状態に入ることもある（いわゆる間欠受信動作）。ビーコンには、特定の通信局宛ての情報を保持している場合には、当該通信局にその旨を伝達するフィールドが定義されており、ビーコンを受信した端末局ＭＴは、現在アクセスポイントが自局宛ての情報を保持しているか否かを知ることができる。
図２７では、通信局ＳＴＡ０が通信局ＳＴＡ１のビーコンを２回に１回受信する場合の例を示している。図２７（ｃ）は、通信局ＳＴＡ０の受信部の状態を示してあり、ハイレベルが受信動作中で、ローレベルが受信停止中を示してある。通信局ＳＴＡ１がビーコンＢ１−０を送信するタイミングでは、通信局ＳＴＡ０は受信部を動作させている。しかし、ビーコンＢ１−０では、自局宛ての情報が保持されている旨が記載されていなかったため、通信局ＳＴＡ０はビーコンの受信を終了すると、受信部の動作をストップさせる。通信局ＳＴＡ０は、次回のＢ１−１のビーコン送信時には受信部を動作させず、その次のビーコンであるＢ１−２が送信される時刻を狙い打って受信部を動作させている。図２７では、このビーコンＢ１−２において、通信局ＳＴＡ０宛ての情報が保持されていることが報知されている場合を例にとっている。
ビーコンＢ１−２を受信することにより、自局宛ての情報が保持されていることを認識した通信局ＳＴＡ０は、この情報を認識し受信部を動作させ続けることを通信局ＳＴＡ１に伝達すべく、所定の送信手順にしたがって、ＰＳ−Ｐｏｌｌパケットを送信する。これを受信した通信局ＳＴＡ１は、通信局ＳＴＡ０が受信機の動作を開始したことを認識すると、所定の送信手順にしたがって、情報パケットを通信局ＳＴＡ０宛てに送信する。これを誤りなく受信できた場合には、通信局ＳＴＡ０は、受信確認応答信号としてＡＣＫを送信する。ここで、通信局ＳＴＡ０が受信した情報パケットには、これ以上の情報が現在通信局ＳＴＡ１で保持されていない旨の情報が記載されており、この旨を認識した通信局ＳＴＡ０は、再度受信部をストップさせ、間欠受信動作へと変遷する。
また、アクセスポイントがブロードキャスト情報を送信する際には、アクセスポイントは、今後いつブロードキャストメッセージを送信するかを決定するカウントダウンを行い、このカウント値をビーコンにて報知している。例えば、図２７のビーコンＢ１−２の直後にブロードキャスト情報の送信を行う場合には、ビーコンＢ１−０にはカウント値２、ビーコンＢ１−１にはカウント値１、ビーコンＢ１−３にはカウント値０が記載されており、端末局ＭＴは、当該カウント値を参照し、カウント値がゼロになった時点で受信機を動作させることにより、毎回ビーコンを受信することなく、ブロードキャスト情報を受信することが可能である。
次に、アドホックモード時のＩＥＥＥ８０２．１１の動作について図２８を用いて説明する。アドホックモードのＩＢＳＳにおいては、端末局（通信局）ＭＴは複数の通信局ＭＴ同士でネゴシエーションを行った後に自律的にＩＢＳＳを定義する。ＩＢＳＳが定義されると、通信局郡は、ネゴシエーションの末に、一定間隔毎にＴＢＴＴを定める。各通信局ＭＴは自局内のクロックを参照することによりＴＢＴＴになったことを認識すると、ランダム時間の遅延の後、まだ誰もビーコンを送信していないと認識した場合にはビーコンを送信する。図２８では、通信局ＳＴＡ０と通信局ＳＴＡ１の２台のＭＴがＩＢＢＳを構成する場合の例を示してある。図２８（ａ）は、通信局ＳＴＡ１が送受信するパケットを示してあり、図２８（ｂ）は、通信局ＳＴＡ０が送受信するパケットを示してあり、図２８（ｃ）は、通信局ＳＴＡ０の受信部の動作状態（ハイレベル受信動作中、ローレベル受信停止中）を示している。この場合、ビーコンはＩＢＳＳに属する通信局ＳＴＡ０か通信局ＳＴＡ１いずれかの通信局ＭＴが、ＴＢＴＴが訪れる毎にビーコンを送信することになる。
ＩＢＳＳにおいても、通信局ＭＴは必要に応じて送受信部の電源を落とすスリープ状態に入ることがある。ＩＥＥＥ８０２．１１においては、ＩＢＳＳでスリープモードが適用されている場合には、ＴＢＴＴからしばらくの時間帯がＡＴＩＭ（Ａｎｎｏｕｎｃｅｍｅｎｔ Ｔｒａｆｆｉｃ Ｉｎｄｉｃａｔｉｏｎ Ｍｅｓｓａｇｅ）ウィンドウ（Ｗｉｎｄｏｗ）として定義されている。ＡＴＩＭウィンドウの時間帯は、ＩＢＳＳに属する全ての通信局ＭＴは受信部を動作させており、この時間帯であれば、基本的にはスリープモードで動作している通信局ＭＴも受信が可能である。
各通信局ＭＴは、自局が誰か宛ての情報を有している場合には、このＡＴＩＭウィンドウの時間帯においてビーコンが送信された後に、上記の誰か宛てにＡＴＩＭパケットを送信することにより、自局が上記の誰か宛ての情報を保持していることを受信側に通達する。ＡＴＩＭパケットを受信した通信局ＭＴまたは、ビーコンを送信した通信局ＭＴは、次のＴＢＴＴまで受信部を動作させておく。
図２８において、まず最初のＴＢＴＴになると、ＳＴＡ０、ＳＴＡ１の各通信局ＭＴはランダム時間にわたりメディア状態を監視しながらバックオフのタイマーを動作させる。図２８の例では、通信局ＳＴＡ０のタイマーが最も早期にカウントを終了し、通信局ＳＴＡ０がビーコンを送信した場合を示している。通信局ＳＴＡ０がビーコンを送信したため、これを受信した通信局ＳＴＡ１はビーコンを送信しない。また、通信局ＳＴＡ０は、ビーコンを送信したため、次回のビーコンが送信されるまで受信部を動作させておく。
次のＴＢＴＴでは、ランダムバックオフの手順により通信局ＳＴＡ１がビーコンを送信している。このとき、通信局ＳＴＡ０は、ＡＴＩＭウィンドウで定義される時間帯においては受信部を動作させるものの、この間に誰からも情報を受信しなかったため、ＡＴＩＭウィンドウの期間が過ぎると同時に受信部をストップさせ、次回のＴＢＴＴまでスリープ状態へと変遷する。次回のＴＢＴＴでも、ランダムバックオフの手順により再度通信局ＳＴＡ１がビーコンを送信している。このとき、通信局ＳＴＡ０は、ＡＴＩＭウィンドウで定義される時間帯において受信機を動作させている間に通信局ＳＴＡ１よりＡＴＩＭメッセージを受信したため、ＡＴＩＭウィンドウの期間が過ぎても受信部を動作させ、通信局ＳＴＡ１から送信されてくる情報を受信する。通信局ＳＴＡ１は、ＡＴＩＭメッセージに対して受信確認応答であるＡＣＫを受信したことから、通信局ＳＴＡ０が受信の認識をしている旨を確認した上で、ＡＴＩＭウィンドウが終了した時点を皮切りにランダムバックオフの手順を起動しデータパケットの送信を試みる。この後、通信局ＳＴＡ１、ＳＴＡ０とも、次回のビーコン送信までは受信部を動作させておく。
以上説明したような手順により、既存の無線通信システム（無線ＬＡＮなど）においては、受信すべき情報が存在しない通信局は、次のＴＢＴＴまで送受信部の電源を落とし、消費電力を削減することが可能になっている。
特開平８−９８２５５号公報には、このようなビーコンを使用した無線通信処理の従来の一例についての開示がある。
このような通信制御を行う場合に、以下のような問題が存在する。
・送信側に生じるデータの滞留
図２９に従来のシステムにおいて、パケット伝送遅延が生じている様子を示す。
なお、図２９（ａ）は、通信局ＳＴＡ１の上位レイヤから送られてくるパケットであり、図２９（ｂ）は、通信局ＳＴＡ１のＭＡＣ層で送受信されるパケット（ビーコンを含む）であり、図２９（ｃ）は、通信局ＳＴＡ１のＭＡＣ層で送受信されるパケットであり、図２９（ｄ）は、通信局ＳＴＡ１で受信して上位レイヤに送られるパケットである。また、図２９（ｅ）は、通信局ＳＴＡ１の受信部での受信動作状態を示したものである。通信局は、一旦、受信部をストップさせると、次回のビーコン送信時刻まで受信部を動作させない。したがって、例えば図２９に示したように、通信局ＳＴＡ１から通信局ＳＴＡ０にデータを転送する際に、通信局ＳＴＡ１の上位レイヤから定期的に情報が落とされてくるような場合、一旦、受信部をストップさせた通信局ＳＴＡ０が次回受信部を動作させるのは、通信局ＳＴＡ１がビーコンを送信する時刻であり、この間に通信局ＳＴＡ１の上位レイヤから渡されたデータＤ１からデータＤ５は、通信局ＳＴＡ１内部にて滞留していることになる。この送信部内部でのデータの滞留は、送受信部間でのアプリケーションレベルでのラウンドトリップタイム（ＲＴＴ）の増大（レイテンシの増大）を招き、スライディングウインドウを用いたＡＲＱが行われている場合には、スループットが頭打ちになる問題が生じる。また、オーバーフローを避けるためには、送信局である通信局ＳＴＡ１内部にデータ滞留に耐えうるだけの大きなバッファを必要としてしまい、ハードウェア的制限が大きくなるという問題も内包している。
・受信側に生じるアイドル受信区間の増大
次に受信側に生じるアイドル受信区間について、図３０を用いて説明する。図３０の（ａ）〜（ｅ）は図２９（ａ）〜（ｅ）と同じであり、図３０（ｆ）は、アイドル区間を示す。
また、上記の問題を解決しようとした場合、従来では情報を受信した後も受信部を動作させておく方法が取られるが、この場合、例えば図３０に示したように、受信部は常に動作していることになる。たしかに送信局ＳＴＡ１におけるデータの滞留は解消されるものの、受信側である通信局ＳＴＡ０においては、受信部を動作させてはいるものの実際にデータ受信を行わないアイドル区間（図３０（ｆ）に矢印で示す区間）が多く存在し、無駄に受信部を動作させてしまって消費電力の観点から問題が残る。
・ブロードキャスト情報のレイテンシ
また、インフラモードにおいて送受信されるブロードキャスト情報については、通信局ＭＴが何回かに一度しかビーコン情報を受信しなくても伝達することは可能ではあるものの、アクセスポイントＡＰが上位レイヤから渡されたデータをブロードキャストしたいなどという場合には、上位レイヤからデータを渡されてからカウントダウンが終了するまでブロードキャスト情報の送信を待たせる必要があり、実際にブロードキャスト情報が送信されるまでの遅延量が大きくなるという問題が生じている。
本発明はこれらの点に鑑みてなされたものであり、無線ＬＡＮシステムなどの通信システムでの伝送時の、送信側での滞留や受信側での遅延などの問題を解決することを目的とする。

本発明は、複数の通信局で構成されるネットワーク内での通信であって、他の局から送信される信号の検出により、他局とパケットの通信タイミングが衝突しないアクセス制御を行う場合に、ネットワーク内の各通信局は、ネットワークに関する情報を記述したビーコンを送信して、そのビーコン信号の送信に前後する時間帯に受信動作を行う状態を設定するようにしたものである。
本発明によると、ネットワーク内の各通信局で、例えば、送受信データが存在しない場合には、最小限の送受信動作にてシステムを構成可能であり、かつ、変動する送受信データ量に従って、送受信動作状態を変遷させることにより、必要最低限の送受信動作にて、極力小さなレイテンシでのデータ転送を可能とすることができる。従って、優れた通信方法及び通信装置、並びにコンピュータプログラムを提供することができる。

図１は、本発明の一実施の形態による通信装置の配置例を示す説明図である。
図２は、本発明の一実施の形態による通信装置の構成例を示すブロック図である。
図３は、本発明の一実施の形態による通信装置の詳細な構成例を示すブロック図である。
図４は、本発明の一実施の形態によるビーコン送信間隔の一例を示す説明図である。
図５は、本発明の一実施の形態によるビーコン送信タイミングの一例を示す説明図である。
図６は、本発明の一実施の形態によるビーコン記載情報の一部を示す説明図である。
図７は、本発明の一実施の形態によるＮＯＢＩ及びＮＢＡＩ処理手順の一例を示す説明図である。
図８は、本発明の一実施の形態による送信不許可区間の定義の一例を示す説明図である。
図９は、本発明の一実施の形態による送信優先区間の例を示す説明図である。
図１０は、本発明の一実施の形態によるスーパーフレームの構成例を示す説明図である。
図１１は、本発明の一実施の形態による通信局での通信状態の一例を示すタイミング図である。
図１２は、本発明の一実施の形態による近隣局リストの一例を示す説明図である。
図１３は、本発明の一実施の形態による動作レベルの遷移の例を示す説明図である。
図１４は、本発明の一実施の形態による動作レベル０の送受信手順の一例を示すタイミング図である。
図１５は、本発明の一実施の形態による動作レベル１の送受信手順の一例を示すタイミング図である。
図１６は、本発明の一実施の形態による動作レベル２への変遷手順の一例を示すタイミング図である。
図１７は、本発明の一実施の形態による動作レベル２の送受信手順の一例を示すタイミング図である。
図１８は、本発明の一実施の形態による動作レベル１への変遷手順の一例を示すタイミング図である。
図１９は、本発明の一実施の形態による動作レベル３への変遷手順の一例を示すタイミング図である。
図２０は、本発明の一実施の形態による動作レベル２への変遷手順の一例を示すタイミング図である。
図２１は、本発明の一実施の形態によるブロードキャスト信号伝送状態の例を示す説明図である。
図２２は、本発明の一実施の形態によるブロードキャスト信号送受信手順の一例を示す説明図である。
図２３は、本発明の一実施の形態におけるブロードキャスト信号送受信時の近隣局リストの変遷を示す説明図である。
図２４は、本発明の一実施の形態におけるビーコン信号の記載情報の一部を示す説明図である。
図２５は、本発明の一実施の形態におけるアクティブレベルアップロードのトランザクションを示す説明図である。
図２６は、本発明の一実施の形態におけるアクティブレベルダウンロードのトランザクションを示す説明図である。
図２７は、従来の無線通信システムのインフラモードでの送受信状態の例を示すタイミング図である。
図２８は、従来の無線通信システムのアドホックモードでの送受信状態の例を示すタイミング図である。
図２９は、従来の無線通信システムにおけるパケット伝送遅延の例を示すタイミング図である。
図３０は、従来の無線通信システムにおける受信アイドル時間の例を示すタイミング図である。

以下、本発明の一実施の形態を、図１〜図２５を参照して説明する。
本実施の形態において想定している通信の伝播路は無線であり、かつ単一の伝送媒体（周波数チャネルによりリンクが分離されていない場合）を用いて、複数の機器間でネットワークを構築する場合としてある。但し、複数の周波数チャネルが伝送媒体として存在する場合であっても、同様のことがいえる。また、本実施の形態で想定している通信は蓄積交換型のトラヒックであり、パケット単位で情報が転送される。
図１には、本発明の一実施形態に係る無線通信システムを構成する通信装置の配置例を示している。この無線通信システムでは、特定の制御局を配置せず、各通信装置が自律分散的に動作し、いわゆるアドホック・ネットワークが形成されている。同図では、通信装置＃０から通信装置＃６までが、同一空間上に分布している様子を表わしている。
また、同図において各通信装置の通信範囲を破線で示してあり、その範囲内にある他の通信装置と互いに通信ができるのみならず、自己の送信した信号が干渉する範囲として定義される。すなわち、通信装置＃０は近隣にある通信装置＃１、＃４、と通信可能な範囲にあり、通信装置＃１は近隣にある通信装置＃０、＃２、＃４、と通信可能な範囲にあり、通信装置＃２は近隣にある通信装置＃１、＃３、＃６、と通信可能な範囲にあり、通信装置＃３は近隣にある通信装置＃２、と通信可能な範囲にあり、通信装置＃４は近隣にある通信装置＃０、＃１、＃５、と通信可能な範囲にあり、通信装置＃５は近隣にある通信装置＃４、と通信可能な範囲にあり、通信装置＃６は近隣にある通信装置＃２、と通信可能な範囲にある。
ある特定の通信装置間で通信を行なう場合、通信相手となる一方の通信装置からは聞くことができるが他方の通信装置からは聞くことができない通信装置、すなわち「隠れ端末」が存在する。
図２は、本例のシステムに適用される通信局を構成する無線送受信機の構成例を示したブロック図である。この例では、アンテナ１がアンテナ共用器２を介して受信処理部３と送信処理部４に接続してあり、受信処理部３及び送信処理部４は、ベースバンド部５に接続してある。受信処理部３での受信処理方式や、送信処理部４での受信処理方式については、例えば無線ＬＡＮに適用可能な、比較的近距離の通信に適した各種通信方式が適用できる。具体的には、ＵＷＢ（Ｕｌｔｒａ Ｗｉｄｅｂａｎｄ）方式、ＯＦＤＭ（Ｏｒｔｈｏｇｏｎａｌ Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅｘ：直交周波数分割多重）方式、ＣＤＭＡ（Ｃｏｄｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ：符号分割多元接続）方式などが適用できる。
ベースバンド部５は、インターフェース部６とＭＡＣ（メディアアクセスコントロール）部７とＤＬＣ（データリンクコントロール）部８などを備えて、それぞれの処理部で、この通信システムに実装されるアクセス制御方式における各層での処理が実行される。
図３には、本発明の一実施形態に係る無線ネットワークにおいて通信局として動作する無線通信装置の機能構成をさらに詳細に示している。図示の無線通信装置は、制御局を配置しない自律分散型の通信環境下において、同じ無線システム内では効果的にチャネル・アクセスを行なうことにより、衝突を回避しながらネットワークを形成することができる。
図示の通り、無線通信装置１００は、インターフェース１０１と、データ・バッファ１０２と、中央制御部１０３と、ビーコン生成部１０４と、無線送信部１０６と、タイミング制御部１０７と、アンテナ１０９と、無線受信部１１０と、ビーコン解析部１１２と、情報記憶部１１３とで構成される。
インターフェース１０１は、この無線通信装置１００に接続される外部機器（例えば、パーソナル・コンピュータ（図示しない）など）との間で各種情報の交換を行なう。
データ・バッファ１０２は、インターフェース１０１経由で接続される機器から送られてきたデータや、無線伝送路経由で受信したデータをインターフェース１０１経由で送出する前に一時的に格納しておくために使用される。
中央制御部１０３は、無線通信装置１００における一連の情報送信並びに受信処理の管理と伝送路のアクセス制御を一元的に行なう。中央制御部１０３では、例えば、ビーコン衝突時における衝突回避処理などの動作制御が行なわれる。
ビーコン生成部１０４は、近隣にある無線通信装置との間で周期的に交換されるビーコン信号を生成する。無線通信装置１００が無線ネットワークを運用するためには、自己のビーコン送信位置や周辺局からのビーコン受信位置などを規定する。これらの情報は、情報記憶部１１３に格納されるとともに、ビーコン信号の中に記載して周囲の無線通信装置に報知する。ビーコン信号の構成については後述する。無線通信装置１００は、伝送フレーム周期の先頭でビーコンを送信するので、無線通信装置１００が利用するチャネルにおける伝送フレーム周期はビーコン間隔によって定義されることになる。
無線送信部１０６は、データ・バッファ１０２に一時格納されているデータやビーコン信号を無線送信するために、所定の変調処理を行なう。また、無線受信部１１０は、所定の時間に他の無線通信装置から送られてきた情報やビーコンなどの信号を受信処理する。
無線送信部１０６及び無線受信部１１０における無線送受信方式は、例えば無線ＬＡＮに適用可能な、比較的近距離の通信に適した各種の通信方式を適用することができる。具体的には、ＵＷＢ（Ｕｌｔｒａ Ｗｉｄｅ Ｂａｎｄ）方式、ＯＦＤＭ（Ｏｒｔｈｏｇｏｎａｌ Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅｘｉｎｇ：直交周波数分割多重）方式、ＣＤＭＡ（Ｃｏｄｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ：符号分割多元接続）方式などを採用することができる。
アンテナ１０９は、他の無線通信装置宛に信号を所定の周波数チャネル上で無線送信し、あるいは他の無線通信装置から送られる信号を収集する。本実施形態では、単一のアンテナを備え、送受信をともに並行しては行なえないものとする。
タイミング制御部１０７は、無線信号を送信並びに受信するためのタイミングの制御を行なう。例えば、伝送フレーム周期の先頭における自己のビーコン送信タイミングや、他の通信装置からのビーコン受信タイミング、他の通信装置とのデータ送受信タイミング、並びにスキャン動作周期などを制御する。
ビーコン解析部１１２は、隣接局から受信できたビーコン信号を解析し、近隣の無線通信装置の存在などを解析する。例えば、隣接局のビーコンの受信タイミングや近隣ビーコン受信タイミングなどの情報は近隣装置情報として情報記憶部１１３に格納される。
情報記憶部１１３は、中央制御部１０３において実行される一連のアクセス制御動作などの実行手順命令（衝突回避処理手順などを記述したプログラム）や、受信ビーコンの解析結果から得られる近隣装置情報などを蓄えておく。
本実施形態に係る自律分散型ネットワークでは、各通信局は、本実施形態に係る自律分散型ネットワークでは、各通信局は、所定のチャネル上で所定の時間間隔でビーコン情報を報知することにより、近隣（すなわち通信範囲内）の他の通信局に自己の存在を知らしめるとともに、ネットワーク構成を通知する。ビーコン送信周期のことを、ここではスーパーフレーム（Ｓｕｐｅｒ Ｆｒａｍｅ）と定義し、例えば８０ミリ秒とする。
新規に参入する通信局は、スキャン動作により周辺局からのビーコン信号を聞きながら、通信範囲に突入したことを検知するとともに、ビーコンに記載されている情報を解読することによりネットワーク構成を知ることができる。そして、ビーコンの受信タイミングと緩やかに同期しながら、周辺局からビーコンが送信されていないタイミングに自局のビーコン送信タイミングを設定する。
次に、本例の通信装置を複数台用意して構成される無線ネットワークで実行される通信処理動作について説明する。
本実施の形態において想定している無線通信システムは、各通信局が、用意された伝送路を使用して、一定時間毎にビーコン信号を送信し、自局のプレゼンスを報知しているような場合を例としてある。ただし、本実施の形態で期待される効果は、伝送路を時分割でシェアする無線通信システム全般にも有効である。
図４に、本実施の形態の無線通信システムにおけるビーコン送信間隔の一例を示す。図４の例では、通信局ＳＴＡ０、ＳＴＡ１、ＳＴＡ２、ＳＴＡ３と４つの通信局が存在している場合を例にとっている。ネットワークに参画する各通信局は、通信局の存在を周辺に知らせたりする目的で、スーパーフレーム間隔で周期的にビーコンを送信する。ここでは、周期を８０［ｍｓｅｃ］と仮定し、８０［ｍｓｅｃ］ごとにビーコンを送信する場合を用いて以下説明を行うが、８０［ｍｓｅｃ］に限定しているわけではない。
ビーコンで送信される情報が１００Ｂｙｔｅだとすると、送信に要する時間は１８［ｕｓｅｃ］となる。８０［ｍｓｅｃ］に１回の送信なので、１通信局分のビーコンのメディア占有率は１／４４４４と十分小さい。ステーションに送信信号が到着していない場合でもビーコンは送信するため無駄に見えるが、送信時間率で１／４４４４と十分小さいため、大きな問題とはならない。
各通信局は、周辺の通信局から送信されるビーコンを受信して確認しながら、ゆるやかに同期する。ネットワーク内に新規に通信局が表れた場合、新規通信局は周辺の通信局からビーコンが送信されていないタイミングに、自局のビーコン送信タイミングを設定する。このようにまた、互いの通信局のビーコン送信時刻は、図示されているとおりオフセットされており、互いのビーコン信号が重ならないように周囲のビーコンを受信しながら、自局のビーコン送信タイミングを制御している。
図５には、スーパーフレーム内で配置可能なビーコン送信タイミングの構成例を示している。但し、同図に示す例では、８０ミリ秒からなるスーパーフレーム内における時間の経過を、円環上で時針が右回りで運針する時計のように表している。
図５に示す例では、０からＦまでの合計１６個の位置０〜Ｆがビーコン送信を行なうことができる時刻すなわちビーコン送信タイミングを配置可能な「スロット」として構成されている。図２を参照しながら説明したように、既存の通信局が設定したビーコン間隔のほぼ真中のタイミングで新規参入局のビーコン送信タイミングを順次設定していくというアルゴリズムに従って、ビーコン配置が行なわれたものとする。Ｂｍｉｎを５ミリ秒と規定した場合には、１スーパーフレームにつき最大１６個までしかビーコンを配置することができない。すなわち、１６台以上の通信局はネットワークに参入できない。
なお、図４並びに図５では明示されていないが、各々のビーコンは、各ビーコン送信時刻であるＴＢＴＴ（Ｔａｒｇｅｔ Ｂｅａｃｏｎ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｔｉｍｅ）から故意に若干の時間オフセットを持った時刻で送信されている。これを「ＴＢＴＴオフセット」と呼ぶ。このようにＴＢＴＴオフセットが設定されるＴＢＴＴ Ｏｆｆｓｅｔ Ｉｎｄｉｃａｔｏｒ Ｓｅｑｕｅｎｃｅ（ＴＯＩＳ）フィールドを定義しておく。ＴＯＩＳには、今回のビーコンがＴＢＴＴに比してどのくらい故意にずらして送信が行われたかを示すビーコン送信オフセット値が記されている。本実施形態では、ＴＢＴＴオフセット値は擬似乱数にて決定される。この擬似乱数は、一意に定められる擬似ランダム系列ＴＯＩＳ（ＴＢＴＴ Ｏｆｆｓｅｔ Ｉｎｄｉｃａｔｉｏｎ Ｓｅｑｕｅｎｃｅ）により決定され、ＴＯＩＳはスーパーフレーム周期毎に更新される。
ＴＢＴＴオフセットを設けることにより、２台の通信局がスーパーフレーム上では同じスロットにビーコン送信タイミングを配置している場合であっても、実際のビーコン送信時刻がずらすことができ、あるスーパーフレーム周期にはビーコンが衝突しても、別のスーパーフレーム周期では各通信局は互いのビーコンを聞き合う（あるいは、近隣の通信局は双方のビーコンを聞く）ことができるので、自局のビーコンが衝突したことを認識できる。通信局は、スーパーフレーム周期毎に設定するＴＯＩをビーコン情報に含めて周辺局に報知する。
また、本実施形態では、各通信局は、データの送受信を行なっていない場合には、自局が送信するビーコンの前後は受信動作を行なうことが義務付けられる。また、データ送受信を行なわない場合であっても、数秒（本明細書ではこの時間間隔を”Ｔ＿ＳＣＡＮ”と定義する。）に一度は１スーパーフレームにわたり連続して受信機を動作させてスキャン動作を行ない、周辺ビーコンのプレゼンスに変化がないか、あるいは各周辺局のＴＢＴＴがずれていないかを確認することも義務付けられる。そして、ＴＢＴＴにずれを確認した場合には、自局の認識するＴＢＴＴ群を基準に−Ｂｍｉｎ／２ミリ秒以内をＴＢＴＴと規定しているものを「進んでいる」、＋Ｂｍｉｎ／２ミリ秒以内をＴＢＴＴと規定しているものを「遅れている」ものと定義し、最も遅れているＴＢＴＴに合わせて時刻を修正する。
・ＮＢＯＩフィールド
また、ビーコンで送信される情報の一つとして、Ｎｅｉｇｈｂｏｒｉｎｇ Ｂｅａｃｏｎ Ｏｆｆｓｅｔ Ｉｎｆｏｒｍａｔｉｏｎ（ＮＢＯＩ）フィールドの記述例を図６に示す。ＮＢＯＩには、自局が受信可能なビーコンの位置（受信時刻）を自局のビーコンの位置（送信時刻）からの相対位置（相対時間）でビットマップにて記載する。図６に示す例においては、最小間隔Ｂｍｉｎ＝５［ｍｓｅｃ］で、ビーコン送信位置が１６種類しか存在できない場合を例にとっており、故にＮＢＯＩフィールド長が１６ビットとなっているが、１６ビットに限られるわけではない
図６の例では、図５における通信局〔番号０〕が、「通信局〔番号１〕ならびに通信局〔番号９〕からのビーコンが受信可能である」旨を伝えるＮＢＯＩフィールドの例が示されている。受信可能なビーコンの相対位置に対応するビットに関し、ビーコンが受信されている場合にはマーク、受信されていない場合にはスペースを割り当てる。図６の例では、０ビット目、１ビット目、ならびに９ビット目がマークされている。０ビット目のマークは、自身のビーコンが送信されていることを示し、１ビット目のマークは、該ビーコンのＴＢＴＴからＢｍｉｎ＊１遅れたタイミングでビーコンが受信されていることを示す。同様に、９ビット目のマークは、該ビーコンのＴＢＴＴからＢｍｉｎ＊９遅れたタイミングでビーコンが受信されていることを示す。
なお、詳細は後述するが、例えば、補助ビーコンを送信する場合などのこの他の目的で、ビーコンが受信されていないタイミングに対応するビットに関してマークを行ってもかまわない。
・ＮＢＡＩフィールド
また、ここでは、ＮＢＯＩフィールドと類似して、同じくビーコンで送信される情報の一つとして、Ｎｅｉｇｈｂｏｒｉｎｇ Ｂｅａｃｏｎ Ａｃｔｉｖｉｔｙ Ｉｎｆｏｒｍａｔｉｏｎ（ＮＢＡＩ）フィールドを定義する。ＮＢＡＩフィールドには、自局が実際に受信を行っているビーコンの位置（受信時刻）を自局のビーコンの位置からの相対位置でビットマップにて記載する。即ち、ＮＢＡＩフィールドは、自局が受信可能なアクティブの状態にあることを示す。さらに、前記ＮＢＯＩとＮＢＡＩの二つの情報により、スーパーフレーム内のそのビーコン位置で自局がビーコンを受信する情報を提供する。即ち、ビーコンに含まれるＮＢＯＩ並びにＮＢＡＩフィールドにより、各通信局に関し、下記の２ビット情報を報知することになる。

・ＮＢＯＩ／ＮＢＡＩのＯＲをとる処理
図７には、新規に参入した通信局Ａがスキャン動作により周辺局から受信したビーコンから得た各ビーコンのＮＢＯＩに基づいて自局のＴＢＴＴを設定するまでの様子を示している。
通信局は、スキャン動作によりスーパーフレーム内に３つの局０〜２からのビーコンが受信できたとする。
周辺局のビーコン受信時刻を自局の正規ビーコンに対する相対位置として扱い、ＮＢＯＩフィールドはこれをビットマップ形式で記述している（前述）。そこで、通信局Ａでは、周辺局から受信できた３つのビーコンのＮＢＯＩフィールドを各ビーコンの受信時刻に応じてシフトし、時間軸上でビットの対応位置を揃えた上で、各タイミングのＮＢＯＩビットのＯＲをとることで、ＮＢＯＩを統合して参照する。具体的にその手順を説明する、ビーコン１は、ビーコン０の送信タイミングを基準として３スロット遅れて受信されている。この情報を通信局はメモリなどに保持する。そして、ビーコン１に含まれるＮＢＯＩフィールドの後ろ３スロットを先頭にシフトさせ、この情報をメモリ等に保持する（図７第二段）。ビーコン２についても同様の処理を行う（図７第三段）。
周辺局のＮＢＯＩフィールドを統合して参照した結果、得られている系列が図７中“ＯＲ ｏｆ ＮＢＯＩｓ”で示されている「１１０１，０００１，０１００，１０００」である。１はスーパーフレーム内で既にＴＢＴＴが設定されているタイミングの相対位置を、０はＴＢＴＴが設定されていないタイミングの相対位置を示している。この系列において、スペース（ゼロ）が最長ランレングスとなる場所が新規にビーコンを配置する候補となる。図７に示す例では、最長ランレングスが３であり、候補が２箇所存在していることになる。そして、通信局Ａは、このうち１５ビット目を自局の正規ビーコンのＴＢＴＴに定めている。
通信局Ａは、１５ビット目の時刻を自局の正規ビーコンのＴＢＴＴ（すなわち自局のスーパーフレームの先頭）として設定し、ビーコンの送信を開始する。このとき、通信局Ａが送信するＮＢＯＩフィールドは、ビーコン受信可能な通信局０〜２のビーコンの各受信時刻を、自局の正規ビーコンの送信時刻からの相対位置に相当するビット位置をマークしたビットマップ形式で記載したものである、図７中の“ＮＢＯＩ ｆｏｒ ＴＸ（１ Ｂｅａｃｏｎ ＴＸ）”で示す通りとなる。
なお、通信局Ａが優先送信権利を得るなどの目的で補助ビーコンを送信する際には、さらにこの後、周辺局のＮＢＯＩフィールドを統合した“ＯＲ ｏｆ ＮＢＯＩｓ”で示されている系列のスペース（ゼロ）の最長ランレングスを探し、探し当てたスペースの箇所に補助ビーコンの送信時刻を設定する。図７に示す例では、２つの補助ビーコンを送信する場合を想定しており，“ＯＲ ｏｆ ＮＢＯＩｓ”の６ビット目と１１ビット目のスペースの時刻に補助ビーコンの送信タイミングを設定している。この場合、通信局Ａが送信するＮＢＯＩフィールドは、自局の正規ビーコン並びに周辺局から受信するビーコンの相対位置に加え、さらに自局が補助ビーコンの送信を行なっている箇所（正規ビーコンに対する相対位置）にもマークされ、“ＮＢＯＩ ｆｏｒ ＴＸ（３ Ｂｅａｃｏｎ ＴＸ）”で示されている通りとなる。
各通信局が上述したような処理手順で自局のビーコン送信タイミングＴＢＴＴを設定してビーコンの送信を行なう場合、各通信局が静止して電波の到来範囲が変動しないという条件下では、ビーコンの衝突を回避することができる。また、送信データの優先度に応じて、補助ビーコン（又は複数のビーコンに類する信号）をスーパーフレーム内で送信することにより、優先的にリソースを割り当て、ＱｏＳ通信を提供することが可能である。また、周辺から受信したビーコン数（ＮＢＯＩフィールド）を参照することにより、各通信局がシステムの飽和度を自律的に把握することができるので、分散制御システムでありながら、通信局毎に系の飽和度を加味しつつ優先トラヒックの収容を行なうことが可能となる。さらに、各通信局が受信ビーコンのＮＢＯＩフィールドを参照することで、ビーコン送信時刻は衝突しないように配置されるので、複数の通信局が優先トラヒックを収容した場合であっても、衝突が多発するといった事態を避けることができる。
このように、通信局が、新規にネットワークに参入する際には、各通信局から受信したビーコンから得たＮＢＯＩの和をとった結果、スペースのランレングスが最長となる区間の中心をビーコン送信タイミングとして定める。
上述の説明は、ＮＢＯＩフィールドをＯＲで参照する例を示したが、ＮＢＡＩフィールドも同様の手順により和（ＯＲ）を参照することにより、マークされているタイミングのビーコン送信時刻においては、送信を行わないよう制御を行う。
即ち、通信局が、なんらかの情報を送信する際には、周辺通信局から送信されるビーコンを随時受信しておき、各通信局から受信したビーコンから得たＮＢＡＩフィールドの和（ＯＲ）をとった結果、マークされているタイミングのビーコン送信時刻においては、送信を行わないよう制御を行う。
図８に、この際の処理を示す。ここでは、ＮＢＡＩフィールドが８ビットである場合が示されており、上述した手順で各受信ビーコンのＮＢＡＩフィールドの和（ＯＲ）をとった結果、０ビット目と４ビット目と６ビット目がマークされている場合を例にとっている。０ビット目は自局のビーコンのことでありとくに付加処理は行わない。４ビット目がマークされているので、４ビット目のビーコン送信時刻である時刻Ｔ４においては、自局の送信許可フラグを下げ送信を行わないようにする。また、６ビット目に関しても同様であり、対応する時刻Ｔ６では、自局の送信許可フラグを下げ送信を行わないようにする。これにより、ある通信局がある通信局のビーコンを受信したい場合には、送信局はこの受信を妨げることがなくなり、信頼性の高い送受信を行うことが可能となる。
・送信優先区間ＴＰＰ
各通信局は、ビーコンを一定間隔で送信しているが、本例では、ビーコンを送信した後しばらくの間は、該ビーコンを送信した局に送信の優先権を与える。ビーコン送信局に優先送信権が与えられる様子を図９に示す。図９では、この送信優先区間として４８０［ｕｓｅｃ］が与えられる場合の例を示している。この優先区間をＴｒａｎｓｍｉｓｓｉｏｎ ＰｒｉｏｒｉｔｉｚｅｄＰｅｒｉｏｄ（ＴＰＰ）と定義する。ＴＰＰは、ビーコン送信直後に開始し、ＴＢＴＴからＴ＿ＴＧＰ経過した時刻に終了する。各通信局はスーパーフレームごとにビーコンを送信するため、基本的には各通信局に対して、同時間率のＴＰＰが配布される形となる。一の通信局のＴＰＰが満了すると、他の通信局がビーコンを送信するまでの間がＦａｉｒｌｙ Ａｃｃｅｓｓ Ｐｅｒｉｏｄ（ＦＡＰ）となる。Ｆａｉｒｌｙ Ａｃｃｅｓｓ Ｐｅｒｉｏｄ（ＦＡＰ）では、通常のＣＳＭＡ／ＣＡ方式（若しくは、後述するＰＳＭＡ／ＣＡ方式）による公平なメディア獲得競合が行なわれる。
図１０はスーパーフレームの構成を示している。同図に示すように各通信局からのビーコンの送信に続いて、そのビーコンを送信した通信局のＴＰＰが割り当てられ、ＴＰＰの長さ分だけ時間が経過するとＦＡＰになり、次の通信局からのビーコンの送信でＦＡＰが終わる。なお、ここではビーコンの送信直後からＴＰＰが開始する例を示したが、これには限定されるものではなく、例えば、ビーコンの送信時刻から相対位置（時刻）でＴＰＰの開始時刻を設定してもかまわない。また、ＴＰＰは、ＴＢＴＴから４８０［μ ｓｅｃ］といった形で定義される場合もある。また、図９に示す通り、ＴＰＰの領域は、ＴＢＴＴを基準にした期間Ｔ＿ＴＰＰを持って満了するため、ＴＢＴＴオフセットによりビーコンの送信時刻が遅れた場合には、ＴＰＰの領域は削減されることになる。
典型的な通信局の送受信手順例について図１１を用いて説明する。図１１では、通信局ＳＴＡ０と通信局ＳＴＡ１に関しての説明が、通信局ＳＴＡ０から通信局ＳＴＡ１に対して送信を行う場合を例にとって、なされている。各通信局は、毎回、他局のビーコン信号を受信しているとは限らない。上位レイヤからの指示などにより、受信頻度を落としている場合もある。図１１（ａ）が通信局ＳＴＡ０と通信局ＳＴＡ１の間で送受信されるパケットのシーケンス図を示し、図１１（ｂ）が通信局ＳＴＡ０の送信部の状態、図１１（ｃ）が通信局ＳＴＡ０の受信部の状態を示している。であり、送受信部の状態は、ハイレベルがアクティブ状態（受信又は送信を試みている状態）であり、ローレベルがスリープ状態を示している。
まず、通信局ＳＴＡ０はメディアがクリアなことを確認した後にビーコンを送信する。このビーコン中のＴＩＭと（あるいは）ＰＡＧＥにおいて、通信局ＳＴＡ１が呼び出されているものとする。該ビーコンを受信した通信局ＳＴＡ１は、ページング情報に対するレスポンスを行う（０）。このレスポンスは通信局ＳＴＡ０のＴＰＰ中に相当するため、優先権を得ているためＳＩＦＳ間隔で送信される。以降、ＴＰＰ内での通信局ＳＴＡ１と通信局ＳＴＡ０の間の送受信は優先権を得ているためＳＩＦＳ間隔で送信される。レスポンスを受信した通信局ＳＴＡ０は、通信局ＳＴＡ１が受信可能状態にあることを確認すると、通信局ＳＴＡ１宛てのパケットを送信する（１）。さらに図１８では、通信局ＳＴＡ１宛てのパケットが存在するのでもう一つパケットを送信している（２）。２つ分のパケットを受信した通信局ＳＴＡ１は、これらが正常に受信されたことを確認した上で、ＡＣＫを送信する（３）。その後、通信局ＳＴＡ０は最後のパケットを送信する（４）。ところが、先のＡＣＫを受信した間に通信局ＳＴＡ０のＴＰＰが終了し、（４）の送信時はＦＡＰに突入している。ＦＡＰにおいては、送信優先権がないため（４）のパケットに関してはＬＩＦＳ＋バックオフの間隔で送信を行う。通信局ＳＴＡ１は（４）のパケットに対応するＡＣＫを送信する（５）。
最後の送信が行われてからしばらくの間をリッスンウィンドウ（Ｌｉｓｔｅｎ Ｗｉｎｄｏｗ）と定義し、各通信局は受信機を動作させることを義務付ける。図１１にもこの様子が示されている。リッスンピリオド内で受信パケットが存在しない場合、通信局はスリープ状態へと状態を変更し、送受信機をストップさせ消費電力の削減を試みる。各端末のパワーセーブ動作についての詳細を次に説明する。
・動作レベル（Ａｃｔｉｖｉｔｙ Ｌｅｖｅｌ）の定義
データの送受信が行われない場合には、自動的にパワーセーブが行われ、データの送受信を行う場合には、相応の処理手順が動作する。送受信データの有無により、ＭＡＣレイヤの間欠動作率は変動する。
図１３は、本実施の形態で設定される各通信端末の動作レベル（Ａｃｔｉｖｉｔｙ Ｌｅｖｅｌ）の定義ならびに遷移を示す図である。ここでは、動作率などに基づき、動作レベル０から動作レベル３までの４段階が定義される。各動作レベルの詳細の送受信手順に関しては後述するが、ここでは、簡単に各動作レベルの説明を行う。
動作レベル０は、他局との間で情報や信号を送受信していない状態に相当する。ビーコンの送信とビーコン送信タイミング近辺で受信機を動作させているだけの状態である。この状態にて、上位レイヤから送信すべきデータが発生した場合あるいは他局から呼び出された場合には、動作レベル１へと変遷する。
動作レベル１では、特定局（あるいは近隣の全ての通信局）との間で最低限の帯域で送受信を行う状態に相当する。ビーコンの送受信に関しては互いに送受信処理を行い、これに起因してデータなどが送受信される状態である。送受信すべきデータ量が動作レベル１でハンドルするには多量になったと判断される場合には、動作レベル２へと変遷する。
動作レベル２では、スーパーフレーム毎に送信されるビーコンの送信時刻の合間に離散的に送信トリガを生成し、送信トリガがかかった時点においてもデータの送受信を行う状態である。送受信すべきデータ量が動作レベル２でハンドルするには多量になってきたと判断される場合には、動作レベル３へと変遷する。
動作レベル３では、全時間帯において、データの送受信を行う状態に相当する。送信局ならび受信局は、連続的に送受信動作を行い、送信側で送信すべきデータが発生すると直ちに送信手順を起動する。
各動作レベルにおいて、送信すべきデータ量が少量になってきたと判断される時間が十分長くなったと判断される場合（例えばタイマーで管理）には、一つ下の動作レベルへと変遷する。
・近隣局リスト（Ｎｅｉｇｈｂｏｒ Ｌｉｓｔ）
図１２は、本実施の形態における近隣局リストの一部を示す図である。
各通信局は、隣接局情報を局単位で保持しており、この情報を近隣局リストという形で管理している。近隣局リストには、局単位で、ビーコンの送信タイミングや自局との間の伝播路の状態などが格納されている。
本実施の形態においては、この近隣局リストにおいて、把握している各隣接局の動作レベルを送信ならび受信に分けて管理する。図１２では、図４における通信局ＳＴＡ０（図１２の左側）と通信局ＳＴＡ１（図１２の右側）における近隣局リストの例が示されている。通信局ＳＴＡ０の近隣局リストにおいては、通信局ＳＴＡ０がビーコンを受信可能な通信局ＳＴＡ１、ＳＴＡ２、ＳＴＡ３の３局分がレコードとして登録されており、各局に対する送信時に参照する動作レベルと受信時に参照する動作レベルが記載されている。ここで示した例においては、通信局ＳＴＡ０、ＳＴＡ１とも全局に対して送信ならび受信とも動作レベル０（図中ではＡＣＴ−０にて表記）である場合が記載されている。
・動作レベル０時の動作
図１４は、動作レベル０の場合の送受信手順を示す図である。図では、通信局ＳＴＡ０と通信局ＳＴＡ１に関しての説明を行っている。図１４（ａ）は、通信局ＳＴＡ０での受信動作状態であり、図１４（ｂ）は、通信局ＳＴＡ０での送信状態であり、図１４（ｃ）は、通信局ＳＴＡ１での送信状態であり、図１４（ｄ）は、通信局ＳＴＡ１での受信動作状態である。受信動作状態については、ハイレベルが受信動作中を示し、ローレベルが受信動作停止中を示す（図１５以降の図における受信動作状態も同じ）。以降、同様の図を用いて説明を行っていく。
動作レベル０では、各通信局は、自局のビーコン送信時刻に先立ちメディアがクリアであるか否かを判断するために受信部を動作させ、クリアであればビーコン送信時刻にビーコンを送信し、その後、上述したリッスンウィンドウ（Ｌｉｓｔｅｎ Ｗｉｎｄｏｗ）と呼ばれる時間帯にわたり受信部を動作させ、自局宛てのデータが受信されなければ、次回のビーコン送信まで送受信部をストップさせている。即ち、動作レベル０は、必要最低限の送受信処理を行う状態であり、最大限の低消費電力動作をするモードである。動作レベル０においては、下記の動作を行うことになる。
・スーパーフレーム周期（Ｔ＿ＳＦ）ごとのビーコンの送信動作
・ビーコン送信後Ｌｉｓｔｅｎ Ｗｉｎｄｏｗ間の受信動作
・Ｔ＿ＳＣＡＮごとにスーパーフレーム周期（Ｔ＿ＳＦ）にわたって行われるスキャン動作
動作レベル０においては、データ送受信に要するＬａｔｅｎｃｙは最大片道でスーパーフレーム周期Ｔ＿ＳＦ［ｍｓｅｃ］となる。この動作モードでは、他局のビーコンを受信しないため、ハードウェア部分における低消費電力動作を実現する。
通信局ＳＴＡ０における近隣局リストの通信局ＳＴＡ１に関する受信動作レベルが図１４の最上段（図１４（ａ）の上側）に示されており、これが図１２における通信局ＳＴＡ０の近隣局リストの（Ａ）（２）項目に対応する。通信局ＳＴＡ０における近隣局リストの通信局ＳＴＡ１に関する送信動作レベルが、受信動作レベルの直ぐ下に示されており、これが図１２における通信局ＳＴＡ０の近隣局リストの（Ａ）（１）項目に対応する。
また、通信局ＳＴＡ１における近隣局リストの通信局ＳＴＡ０に関する受信動作レベルが、図１４（ｄ）の受信状態の直ぐ下に示されており、これが図１２における通信局ＳＴＡ１の近隣局リストの（Ａ）（２）項目に対応する。通信局ＳＴＡ１における近隣局リストの通信局ＳＴＡ０に関する送信動作レベルが、図１４の最下段に示されており、これが図１２における通信局ＳＴＡ１の近隣局リストの（Ａ）（１）項目に対応する。以降の説明でも同様の対応関係になっていることを前提として話を進める。即ち、図１２の近隣局リストの中身は、図１４で示した各端末の動作レベルを表記していることになる。
上記の動作レベル０の送受信処理の過程で、送信あるいは受信すべきデータが存在する場合には、動作レベル１へと変遷する。
・動作レベル１時の動作
図１５は、動作レベル１の場合の送受信手順を示す図である。動作レベル１では、動作レベル０の動作に加え、周辺局のビーコンを受信する状態であり、周辺局数に応じて消費電力が変動する。動作レベル１においては、下記の動作を行う。
・スーパーフレーム周期（Ｔ＿ＳＦ）ごとのビーコン送信動作
・ビーコン送信後Ｌｉｓｔｅｎ Ｗｉｎｄｏｗ間の受信処理動作
・自局が認識している周辺局のビーコンの受信処理動作
・Ｔ＿ＳＣＡＮごとにスーパーフレーム周期（Ｔ＿ＳＦ）にわたって行われるスキャン動作
図１５（ａ）は、通信局ＳＴＡ０での受信動作状態であり、図１５（ｂ）は、通信局ＳＴＡ０でのパケットの送受信状態であり、図１５（ｃ）は、通信局ＳＴＡ１でのパケットの送受信状態であり、図１５（ｄ）は、通信局ＳＴＡ１での受信動作状態である。また、図１５（ａ）の上側に、通信局ＳＴＡ０での受信（Ｒｘ）動作レベル及び送信（Ｔｘ）動作レベルを、図１５（ｄ）の下側に、通信局ＳＴＡ１での受信（Ｒｘ）動作レベル及び送信（Ｔｘ）動作レベルを示してある。図１５では、通信局ＳＴＡ０からの送信要求に応じて動作レベル０から動作レベル１に変遷し、その後、動作レベル０に戻る場合を例にとっている。
通信局ＳＴＡ０、ＳＴＡ１ともはじめは送信ならび受信の動作レベルは０であるが、通信局ＳＴＡ０において通信局ＳＴＡ１に送信すべきデータＤ０が発生すると、この時点で、通信局ＳＴＡ０の通信局ＳＴＡ１に関する受信動作レベルがレベル１へと変遷し、通信局ＳＴＡ１のビーコン（Ｂ１−３）送信時刻で通信局ＳＴＡ１のビーコンを受信する。このビーコン受信をトリガに通信局ＳＴＡ１に対して送信要求がある旨のページング情報を送信すると、通信局ＳＴＡ１は、「ＳＴＡ１が自局宛てに送信する情報を有している」旨を認識し、通信局ＳＴＡ０に関する動作レベルを送信／受信ともどもレベル１へと変更する。さらに、通信局ＳＴＡ１は、上記ページング情報を了解した旨のＡＣＫを通信局ＳＴＡ０に返送し、これを受信した通信局ＳＴＡ０は、通信局ＳＴＡ１に関する送信動作レベルをレベル１へと変更する。
その後、通信局ＳＴＡ０のビーコン送信時刻になると、通信局ＳＴＡ０は、近隣局リストにおいて通信局ＳＴＡ１に関する送信動作レベルがレベル１になっていることを確認した上で、ビーコン（Ｂ０−４）にて通信局ＳＴＡ１を呼び出す。通信局ＳＴＡ１は、通信局ＳＴＡ０に関する受信動作レベルがレベル１になっているため、このビーコンを受信しており、この呼出しに応答するＡＣＫを返送する。この呼出しと応答がＲＴＳ／ＣＴＳ手順のＲＴＳとＣＴＳに相当する役割を担い、その後に通信局ＳＴＡ０から通信局ＳＴＡ１に送信すべくデータＤ０が送信される。その後、通信局ＳＴＡ１はＡＣＫを返送する。通信局ＳＴＡ０、ＳＴＡ１ともその後、リッスンウィンドウ（ＬＷ）にわたり受信部を動作させるが、受信データがないため、その後受信部をストップさせる。
動作レベル１では、上記の手順により、基本的には、データ送信側のビーコン送信を皮切りにデータの送受信が行われる。なお、送信データが小さい場合には、通信局ＳＴＡ０は、通信局ＳＴＡ１が送信するビーコン（Ｂ１−３）の直後に当該データを送信することもできる。
また、ここでは、ＳＴＡ０とＳＴＡ１の２局が存在する例を説明しているが、さらに多くの局が周辺に存在する場合、いずれかの局に対する送信動作レベルが１となった局（すなわちデータをいずれかの局に送信する局）は、送信ならび受信動作レベルが０に設定されている局のビーコン受信を行う場合もある。
図１５の例では、さらにその後、動作レベル０へと変遷する過程が示されている。先のデータＤ０が送受信された後、通信局ＳＴＡ１は自局のビーコン送信タイミングでビーコン（Ｂ１−５）を送信する。通信局ＳＴＡ０はこのビーコンを受信しているが何も起こらない。さらに、その後、通信局ＳＴＡ０は自局のビーコン送信タイミングでビーコン（Ｂ０−６）を送信する。通信局ＳＴＡ１はこのビーコンを受信しているが、何も送信されてこない。そこで、通信局ＳＴＡ１は、通信局ＳＴＡ０に関する動作レベルを０に変更させることを決定する。その後、通信局ＳＴＡ１は自局のビーコン送信タイミングで送信するビーコン（Ｂ１−７）あるいはその直後に送信するデータ（図示せず）において、「ＳＴＡ１はＳＴＡ０に関する送受信動作レベルをレベル０へと変更する」旨を通達し、通達どおりに動作レベルをレベル０へと変更する。これを受信した通信局ＳＴＡ０は、通信局ＳＴＡ１に関する送信動作レベルをレベル０へと変更する。さらに、その後、通信局ＳＴＡ０は自局のビーコン送信タイミングで送信するビーコン（Ｂ０−８）において、「ＳＴＡ０はＳＴＡ１に関する受信動作レベルをレベル０へと変更する」旨を報知し、動作レベルをレベル０へと変更する。
上述した例においては、通信局ＳＴＡ１は、ビーコン（Ｂ０−６）に付帯してデータが送信されてこなかったことを理由に動作レベルをレベル０へと変更したが、複数ビーコンを連続して受信したもののデータが送信されてこなかったことを理由に変更する場合もある。
また、トラヒックの送受がない時間を監視するタイマーを保持しておき、このタイマーが満了することをトリガに動作レベルを下げてもよい。このとき、Ｔｘ．Ａｃｔｉｖｅ Ｌｅｖｅｌを下げるタイマーとＲｘ．Ａｃｔｉｖｅ Ｌｅｖｅｌを下げるタイマーを別に設定する必要があり、Ｔｘ．Ａｃｔｉｖｅ Ｌｅｖｅｌを下げるタイマーに設定する時間をＲｘ．Ａｃｔｉｖｅ Ｌｅｖｅｌを下げるタイマーよりも短く設定しておくことによりマージンをもたせ、「送信したものの受信機が受信していない」という無駄なトラヒックの発生を抑えることができる。
また、上述した例においては、動作レベルを下げる旨を通達する手順をふんだが、これを省略する場合もある。この場合、受信側のＳＴＡ１はＮビーコン周期にわたりＳＴＡ０からデータを受信しなかった場合に自動的に変更し、送信側のＳＴＡ０はＮ−１ビーコン周期にわたりＳＴＡ１からデータのＡＣＫ（確認応答）を受信しなかった場合に自動的に変更するといった処理が行われる。送信側の設定ビーコン周期を短くしておくことで無駄な処理を省くことができる。
このほか、「データの送受信が許容値を超えて離散的にしか行われていないこと」を理由に動作レベルをレベル０へと変更する場合もある。
また、上記の例においては、受信側である通信局ＳＴＡ１が「動作レベルをレベル１からレベル０へと変更する」旨を決定したが、送信側である通信局ＳＴＡ０が決定し、受信側がこれに追従する場合もある。この場合の手順は、上記で説明した手順と類似するため、ここでは特に説明は行わない。
動作レベル１においては、データ送受信に要するＬａｔｅｎｃｙは最大片道でスーパーフレーム周期Ｔ＿ＳＦ［ｍｓｅｃ］である。動作レベル１は、シグナリングがたまにやりとりされているがトラヒックは通っていないような状態を想定している。
動作レベル１の送受信処理の過程で、送信あるいは受信すべきデータが定常的に存在することを認識した場合には、動作レベル２へと変遷する。送信あるいは受信すべきデータが定常的に存在するかどうかの判断は、例えば、送信バッファにたまったパケット数が所定の閾値を超えたかどうかを監視することにより行なう。
・動作レベル１から動作レベル２への変遷
動作レベル２では、動作レベル１の動作に加え、定期的に送受信機を動作させる状態であり、データを送受信しながらも間欠送受信による低消費電力動作をするモードである。
動作レベル２においては、下記の動作を行う。
・スーパーフレーム周期Ｔ＿ＳＦごとのビーコン送信動作
・ビーコン送信後Ｌｉｓｔｅｎ Ｗｉｎｄｏｗ間の受信処理動作
・自局が認識している周辺局のビーコンの受信処理動作
・指定した（または指定された）時刻における受信処理動作（必要に応じて送信処理動作も行なう）
・Ｔ＿ＳＣＡＮごとのスーパーフレーム周期Ｔ＿ＳＦにわたって行われるスキャン動作
図１６は、動作レベル１から動作レベル２への変遷を示す図である。図１６（ａ）は、通信局ＳＴＡ０での受信動作状態であり、図１６（ｂ）は、通信局ＳＴＡ０でのパケットの送受信状態であり、図１６（ｃ）は、通信局ＳＴＡ１でのパケットの送受信状態であり、図１６（ｄ）は、通信局ＳＴＡ１での受信動作状態である。また、図１６（ａ）の上側に、通信局ＳＴＡ０での受信（Ｒｘ）動作レベル及び送信（Ｔｘ）動作レベルを、図１６（ｄ）の下側に、通信局ＳＴＡ１での受信（Ｒｘ）動作レベル及び送信（Ｔｘ）動作レベルを示してある。図１６では、通信局ＳＴＡ０からの送信要求に応じて変遷する場合を例にとっている。
図１６の初期状態では、通信局ＳＴＡ０、ＳＴＡ１とも互いに関する送受信レベルはレベル１となっている状態でデータの送受信が行われており、通信局ＳＴＡ０のビーコン（Ｂ０−１０）の送信を皮切りに、通信局ＳＴＡ０に到達している通信局ＳＴＡ１への送信データＤ０が送信される。その後、再度通信局ＳＴＡ０のビーコン送信タイミングが訪れる前に、通信局ＳＴＡ０では、通信局ＳＴＡ１への送信データＤ１ならびＤ２が到達する。このとき、通信局ＳＴＡ０は通信局ＳＴＡ１宛ての送信データが許容値を超えて滞留したと判断し、送信動作レベルをレベル２へと変更することを決定する。
通信局ＳＴＡ０は、通信局ＳＴＡ０のビーコン送信タイミングでビーコン（Ｂ０−１２）を送信すると、ビーコンで通信局ＳＴＡ１を呼び出しつつ動作レベルを２へと変更したい旨を通達する。これを受信した通信局ＳＴＡ１は、通達どおり通信局ＳＴＡ０に関する受信動作レベルをレベル２へと変更し、確認応答のＡＣＫを返送する。これを受信した通信局ＳＴＡ０は、通信局ＳＴＡ１の受信動作レベルが２に変更されたことを確認し、送信動作レベルを２へと変更する。さらに、ビーコン（Ｂ０−１２）を皮切りに、先に滞留していた送信データＤ１ならびＤ２を送信し応答を得ると、通信局ＳＴＡ０ならび通信局ＳＴＡ１ともリッスンウィンドウ（ＬＷ）だけ受信部を動作させるが、データが受信されてこないため受信部をストップさせる。その後、通信局ＳＴＡ０は送信動作レベル２になっていることから、通信局ＳＴＡ０の送信動作レベル２が規定する時刻に送受信機を動作させ、所定の手続きをとった後に、この間に滞留したデータＤ３の送信を試みる。一方、通信局ＳＴＡ１は、通信局ＳＴＡ０の動作レベル２に同期している状態であり、同様に通信局ＳＴＡ０の送信動作レベル２が規定する時刻に受信機を動作させ、送信されてきたデータＤ３を受信し、ＡＣＫを返送する。
また、上記の例においては、送信側である通信局ＳＴＡ０が、「ＳＴＡ１宛ての送信データが許容値を超えて滞留したと判断したこと」に起因して動作レベルをレベル２に変遷させることを決定したが、このほか、「送信すべくデータを自局のビーコン送信直後に開始したとして、ある時間内に送信しきれないと判断したこと」に起因する場合や、「動作レベル１の範疇で行った受信局の呼出しに対する応答が受けられなかったこと」に起因する場合などがある。
・動作レベル２時の動作
図１７は、動作レベル２の場合の送受信手順を示す図である。図１７（ａ）は、通信局ＳＴＡ０での受信動作状態であり、図１７（ｂ）は、通信局ＳＴＡ０での送信トリガ信号の生成状態を示し、図１７（ｃ）は、通信局ＳＴＡ０でのパケットの送受信状態であり、図１７（ｄ）は、通信局ＳＴＡ１でのパケットの送受信状態であり、図１７（ｅ）は、通信局ＳＴＡ１での受信動作状態である。また、図８（ａ）の上側に、通信局ＳＴＡ０での受信（Ｒｘ）動作レベル及び送信（Ｔｘ）動作レベルを、図１７（ｅ）の下側に、通信局ＳＴＡ１での受信（Ｒｘ）動作レベル及び送信（Ｔｘ）動作レベルを示してある。図１７では、通信局ＳＴＡ０から通信局ＳＴＡ１にデータが送信される場合の例を示しており、ビーコン間に発生する送信トリガが２回発生する場合を例にとっている。
動作レベル２では、送信側のビーコン送信タイミングからの相対時刻で規定される時刻に送信トリガが発生し、データの送信は、ビーコンの送信に加えこの送信トリガの発生を皮切りに行われる。送信トリガがいつ発生するかについては後述することとして、まずは、動作レベル２の際に行われるデータ送受信の手順を説明する。
図１７の初期状態では、すでに送受両側の動作レベルがレベル２となっている場合を想定している。送信局である通信局ＳＴＡ０は、ビーコン（Ｂ０−１４）の送信をトリガに、これまでに滞留した送信データであるＤ４ならびＤ５を送信する。Ｄ５を送信し終えた時点では、これ以上の送信データの滞留がないため、一旦送信を打ち切り、通信局ＳＴＡ０、ＳＴＡ１ともリッスンウィンドウ（ＬＷ）の期間受信部を動作させた後に受信部をストップさせる。なお、図示されてはいないが、このリッスンウィンドウ（ＬＷ）の期間に新たな送信データが与えられた場合は、直ちにデータを送信する。
その後、新たに送信データＤ６が通信局ＳＴＡ０に与えられるが、一旦送受信を打ち切っているため、通信局ＳＴＡ０はこのデータを保持しておく。この間、通信局ＳＴＡ０ならび通信局ＳＴＡ１とも自局内に具備するタイマーにより、先の通信局ＳＴＡ０のビーコン（Ｂ０−１４）送信時刻からの経過時間を監視しており、予め定められた時間Ｔ−ＡＬ２（１）［ｕｓｅｃ］が経過すると送信トリガを発生させる。通信局ＳＴＡ０は、この送信トリガの発生を皮切りに通信局ＳＴＡ１宛てに滞留したデータの送信を試みる。一方、通信局ＳＴＡ１も同様に先のビーコン（Ｂ０−１４）送信時刻からＴ−ＡＬ２（１）［ｕｓｅｃ］が経過すると受信機を動作させ、通信局ＳＴＡ０からの送信に備える。
これにより、通信局ＳＴＡ０に滞留したデータＤ６とＤ７が該送信トリガを皮切りに送受信される。通信局ＳＴＡ０ならび通信局ＳＴＡ１は、データＤ７を送受信し終えると、これ以上の送信データの滞留がないため、一旦送信を打ち切り、通信局ＳＴＡ０、ＳＴＡ１ともリッスンウィンドウ（ＬＷ）の期間受信部を動作させた後に受信部をストップさせる。その後、新規データＤ８が通信局ＳＴＡ０に与えられるが、一旦送受信を打ち切っているため、通信局ＳＴＡ０はこのデータを保持しておく。この間も、通信局ＳＴＡ０ならびＳＴＡ１とも自局内に具備するタイマーにより、先の通信局ＳＴＡ０のビーコン（Ｂ０−１４）送信時刻からの経過時間を監視しており、先に発生した送信トリガから予め定められた時間Ｔ−ＡＬ２（２）［ｕｓｅｃ］が経過すると新たな送信トリガを発生させる。通信局ＳＴＡ０と通信局ＳＴＡ１は、この送信トリガの発生を皮切りに再度、上記の手順にしたがいデータの送受信を行う。
以降、同様の処理を、次回の通信局ＳＴＡ０の送信ビーコン（Ｂ０−１６）が発生するまで繰り返す。
・動作レベル２におけるＴ−ＡＬ２（ｉ）の設定例
動作レベル２を定義する目的は、ビーコン間隔であるＴ ＳＦを補完し、より短いレイテンシを提供しつつ、とはいえ若干のレイテンシは許容してもらいながら間欠動作も併用し、消費電力を削減することにある。かつ、この送信トリガ発生時刻は、他局の送信パケットとの衝突を避け、ＭＡＣレベルでのパフォーマンスを向上させる目的から、通信局毎に互いに重ならないことが望ましい。
特にネットワークに収容されている通信局数が少ない場合に、上記の事項を極力満足させることを念頭におき、動作レベル２においては、送信局は、自局のビーコン送信時刻あるいはＴＢＴＴのようなビーコン送信時刻を決定する基準時刻を基準に、Ｔ ＡＬ２ ｉ毎に送信動作を開始できるように送信トリガを発生する。Ｔ ＡＬ２ ｉ（ｉ＝１，２，．．．．）は、下記の式で与える。
Ｔ＿ＡＬ２＿ｉ＝
（Ｎ ＡＬ２ ＳＴＥＰ＋ＡＬ２ ＴＢＬ［ｉ］）^＊Ｔ Ｂｍｉｎ
＋ Ｎ ＡＬ２ ＴＲＸ ＳＴＴ ＯＦＦＳＥＴ
＋ Ｎ ＡＬ２ ＴＲＸ ＳＴＴ ＯＦＦＳＥＴ ＳＴＥＰ^＊ｉ
ただし、
ＡＬ２ ＴＢＬ［ｉ］＝［０，−１，０，０，０，１］
である。
例えば、Ｔ＿ＳＦ＝４０ｍｓｅｃ，Ｔ Ｂｍｉｎ＝６２５［ｕｓｅｃ］、Ｎ ＡＬ２ ＳＴＥＰ＝９、Ｎ ＡＬ２ ＴＲＸ ＳＴＴ ＯＦＦＳＥＴ＝１８０［ｕｓｅｃ］、Ｎ ＡＬ２ ＴＲＸ ＳＴＴ ＯＦＦＳＥＴ ＳＴＥＰ＝１０．０［ｕｓｅｃ］において、上記の動作を行うと、各送信トリガ時刻Ｔ ＡＬ ２［ｉ］は、
Ｔ ＡＬ２［０］＝ＴＢＴＴ
Ｔ ＡＬ２［１］＝ＴＢＴＴ＋５．６２５［ｍｓｅｃ］＋１９０［ｕｓｅｃ］
Ｔ ＡＬ２［２］＝ＴＢＴＴ＋１０．６２５［ｍｓｅｃ］＋２００［ｕｓｅｃ］
Ｔ ＡＬ２［３］＝ＴＢＴＴ＋１６．２５０［ｍｓｅｃ］＋２１０［ｕｓｅｃ］
Ｔ ＡＬ２［４］＝ＴＢＴＴ＋２１．８７５［ｍｓｅｃ］＋２２０［ｕｓｅｃ］
Ｔ ＡＬ２［５］＝ＴＢＴＴ＋２７．５００［ｍｓｅｃ］＋２３０［ｕｓｅｃ］
Ｔ ＡＬ２［６］＝ＴＢＴＴ＋３３．７５０［ｍｓｅｃ］＋２４０［ｕｓｅｃ］
と設定され、およそ６．２５［ｍｓｅｃ］おきに送信可能時刻が出現する。
例えば、ＭＡＸ ＷＩＮ ＳＩＺＥ＝６４ｋＢｙｔｅのＴＣＰ経由で、ＦＴＰなどのバルク転送を行う場合、往復のレイテンシはワースト値で１２．５［ｍｓｅｃ］となり、ＴＣＰのフロー制御に起因するスループットの限界は４０．９６［Ｍｂｐｓ］となる。送受信に要するプロセシング遅延を１．０［ｍｓｅｃ］と見込んでも３５．３１［Ｍｂｐｓ］までは提供可能となる。
また、上記のＴ ＡＬ２［^＊］の設定にすると、Ｔ ＡＬ２［^＊］のマクロ的な衝突は、ＴＢＴＴが０から６３までＴ Ｂｍｉｎおきに存在する場合、ＴＢＴＴ＝０の通信局と衝突するものについてピックアップすると、
ＴＢＴＴ＝８，５６ ×１回
ＴＢＴＴ＝２０，２８，３６，４４ ×１回
ＴＢＴＴ＝１０，１８，２６，３８，４６，５４ ×２回
ＴＢＴＴ＝１７，１９，２７，２９，３５，３７，４５，４７ ×２回
ＴＢＴＴ＝９，５５ ×４回
となる。
通信局数が４までであれば、Ｔ ＡＬ２［^＊］の衝突は発生せず、通信局数が８までだと、２局と１回づつ衝突し、それ以上だと順次衝突の可能性が増えていく感じとなる。受信局は、指示されたＴ ＡＬ２［ｉ］において受信ならび送信が可能な状態になっているが、何も送信されてこない場合には、Ｔ ＬＷの間受信機を動作させた後に再びアイドル状態へと変遷する。また、受信ノードは、指示されたＴ ＡＬ２［ｉ］において受信当該ノード宛てへの情報が送信されてこないことを認識した場合には、Ｔ ＡＬ２［ｉ］のうちいずれかの時刻のみで受信作業を行う旨の通告を送信元通信局に対して行った後に、アクティブ状態の時間率を下げてもかまわない。
また、上述した例においては、動作レベル２として６つの送信トリガ時刻を定義したが、本発明はこれに限定されるものではない。
さらに、動作レベル２を複数段階定義し、動作レベル２−１では３つの送信トリガ時刻を生成し、動作レベル２−２では６つの送信トリガ時刻を生成するような処理も本発明から想像できる範囲内である。
・動作レベル２から動作レベル１への変遷
図１８は、動作レベル２から動作レベル１への変遷を示す図である。図１８（ａ）は、通信局ＳＴＡ０での受信動作状態であり、図１８（ｂ）は、通信局ＳＴＡ０での送信トリガ信号の生成状態を示し、図１８（ｃ）は、通信局ＳＴＡ０でのパケットの送受信状態であり、図１８（ｄ）は、通信局ＳＴＡ１でのパケットの送受信状態であり、図１８（ｅ）は、通信局ＳＴＡ１での受信動作状態である。また、図１８（ａ）の上側に、通信局ＳＴＡ０での受信（Ｒｘ）動作レベル及び送信（Ｔｘ）動作レベルを、図１８（ｅ）の下側に、通信局ＳＴＡ１での受信（Ｒｘ）動作レベル及び送信（Ｔｘ）動作レベルを示してある。図１８では、通信局ＳＴＡ１からの要求に応じて変遷する場合を例にとっている。
図１８の初期状態では、通信局ＳＴＡ０、ＳＴＡ１とも互いに関する送受信レベルはレベル２となっている状態でデータの送受信が行われており、通信局ＳＴＡ０のビーコンあるいは送信トリガの発生を送信を皮切りに、通信局ＳＴＡ０からＳＴＡ１へデータの送受信が行われている。
図では、まず、通信局ＳＴＡ０がビーコン（Ｂ０−１６）を送信し、これを皮切りに通信局ＳＴＡ０に滞留している送信データＤ１０ならびＤ１１が送受される。その後、リッスンウィンドウ（ＬＷ）にわたり受信部を動作させ、一旦送受信を打ち切る。その後、先のビーコン（Ｂ０−１６）の送信時刻からＴ−ＡＬ２（１）［ｕｓｅｃ］が経過し、送信トリガが発生する。この近辺で、通信局ＳＴＡ０、ＳＴＡ１とも受信部を動作させるが、通信局ＳＴＡ０において滞留している送信データが存在しないため何も送受信は行われず、送信トリガ発生からリッスンウィンドウ（ＬＷ）経過すると再度受信部をストップさせる。さらにこの送信トリガ発生からＴ−ＡＬ２（２）［ｕｓｅｃ］が経過し、再度送信トリガが発生し、通信局ＳＴＡ０とＳＴＡ１は同様の動作を行うが、データは送受信されない。
さらにその後、通信局ＳＴＡ０はビーコン（Ｂ０−１８）を送信するが、やはりデータは送受信されない。この時点で、通信局ＳＴＡ１は、１ビーコン送信周期にわたり送信データが存在しなかったことを理由に、通信局ＳＴＡ０に関する受信動作レベルをレベル１に変更することを決定する。その後、通信局ＳＴＡ１は、自局のビーコン送信タイミングで送信するビーコン（Ｂ１−１９）あるいはその直後に送信するデータ（図示せず）において、「ＳＴＡ１はＳＴＡ０に関する送受信動作レベルをレベル１へと変更する」旨を通達し、通達どおりに動作レベルをレベル１へと変更する。これを受信した通信局ＳＴＡ０は、通信局ＳＴＡ１に関する送信動作レベルをレベル１へと変更する。
上記の例においては、通信局ＳＴＡ１は、「１ビーコン送信周期にわたりデータが存在しなかったこと」を理由に動作レベルをレベル１へと変更したが、「複数周期にわたりデータが存在しなかったこと」を理由に変更する場合もある。
また、上述した例においては、動作レベルを下げる旨を通達する手順をふんだが、これを省略する場合もある。この場合、受信側のＳＴＡ１はＮビーコン周期にわたりＳＴＡ０からデータを受信しなかった場合に自動的に変更し、送信側のＳＴＡ０はＮ−１ビーコン周期にわたりＳＴＡ１からデータのＡＣＫ（確認応答）を受信しなかった場合に自動的に変更するといった処理が行われる。送信側の設定ビーコン周期を短くしておくことで無駄な処理を省くことができる。
また、上記の例においては、受信側である通信局ＳＴＡ１が「動作レベルをレベル２からレベル１へと変更する」旨を決定したが、送信側である通信局ＳＴＡ０が決定し、受信側がこれに追従する場合もある。この場合の手順は、上記で説明した手順と類似するため、ここでは特に説明は行わない。
・動作レベル２から動作レベル３への変遷
動作レベル３では、動作レベル１の動作に加え、アイドルの時間帯においても定常的に受信動作を行う状態であり、連続的に他の通信局が送信するキャリア（若しくはプリアンブル）の検出動作を行う。消費電力の低減効果は小さいが、提供可能な限りの広い帯域と短いＬａｔｅｎｃｙを提供するモードである。
動作レベル３においては、下記の動作を行う。
・スーパーフレーム周期Ｔ＿ＳＦごとのビーコン送信動作
・ビーコン送信後Ｌｉｓｔｅｎ Ｗｉｎｄｏｗ間の受信処理動作
・連続的な受信処理動作
図１９は、動作レベル２から動作レベル３への変遷を示す図である。図１９（ａ）は、通信局ＳＴＡ０での受信動作状態であり、図１９（ｂ）は、通信局ＳＴＡ０での送信トリガ信号の生成状態を示し、図１９（ｃ）は、通信局ＳＴＡ０でのパケットの送受信状態であり、図１９（ｄ）は、通信局ＳＴＡ１でのパケットの送受信状態であり、図１９（ｅ）は、通信局ＳＴＡ１での受信動作状態である。また、図１９（ａ）の上側に、通信局ＳＴＡ０での受信（Ｒｘ）動作レベル及び送信（Ｔｘ）動作レベルを、図１９（ｅ）の下側に、通信局ＳＴＡ１での受信（Ｒｘ）動作レベル及び送信（Ｔｘ）動作レベルを示してある。図１９では、通信局ＳＴＡ０からの送信要求に応じて変遷する場合を例にとっている。
図１９の初期状態では、通信局ＳＴＡ０、ＳＴＡ１とも互いに関する送受信レベルはレベル２となっている状態でデータの送受信が行われており、送信トリガの発生を皮切りに、通信局ＳＴＡ０に滞留している通信局ＳＴＡ１への送信データＤ８、Ｄ９、Ｄ１０が送信される。その後、リッスンウィンドウ（ＬＷ）にわたり受信部を動作させるが、新規送信データが発生しないため、一旦送受信を打ち切る。しかし、次回の送信機会である通信局ＳＴＡ０のビーコン（Ｂ０−２０）送信の時刻に先立ち、通信局ＳＴＡ０では、通信局ＳＴＡ１への送信データＤ１１ならびＤ１２が到達する。このとき、通信局ＳＴＡ０は通信局ＳＴＡ１宛ての送信データが許容値を超えて滞留したと判断し、送信動作レベルをレベル３へと変更することを決定する。
通信局ＳＴＡ０は、通信局ＳＴＡ０のビーコン送信タイミングでビーコン（Ｂ０−２０）を送信すると、ビーコンで通信局ＳＴＡ１を呼び出しつつ動作レベルをレベル３へと変更したい旨を通達する。これを受信した通信局ＳＴＡ１は、通達どおり受信動作レベルをレベル３へと変更し、確認応答のＡＣＫを返送する。これを受信した通信局ＳＴＡ０は、通信局ＳＴＡ１の受信動作レベルが３に変更されたことを確認し、通信局ＳＴＡ１に関する送信動作レベルをレベル３へと変更する。さらに、ビーコン（Ｂ０−２０）送信を皮切りに、滞留していた送信データＤ１１以降を順次送信し、通信局ＳＴＡ１はこれを順次受信する。
動作レベル３においては、送信側に新規の送信データが到着すると直ちに送信手順を起動し、できるだけ早期に送信データの配送につとめる。一方、受信側は、常に受信部を動作させ、いつ送信されてくるともわからない自局宛てのデータ受信に備える。
上記の例においては、送信側である通信局ＳＴＡ０が、「ＳＴＡ１宛ての送信データが許容値を超えて滞留したと判断したこと」に起因して動作レベルをレベル２に変遷させることを決定したが、このほか、「滞留している送信データを送信トリガから送信し始めたとして、ある時間内に送信しきれないと判断したこと」に起因する場合や、「動作レベル２の範疇で行った受信局の呼出しに対する応答が受けられなかったこと」に起因する場合などがある。
・動作レベル３から動作レベル２への変遷
図２０は、動作レベル３から動作レベル２への変遷を示す図である。図２０（ａ）は、通信局ＳＴＡ０での受信動作状態であり、図２０（ｂ）は、通信局ＳＴＡ０での送信トリガ信号の生成状態を示し、図２０（ｃ）は、通信局ＳＴＡ０でのパケットの送受信状態であり、図２０（ｄ）は、通信局ＳＴＡ１でのパケットの送受信状態であり、図２０（ｅ）は、通信局ＳＴＡ１での受信動作状態である。また、図２０（ａ）の上側に、通信局ＳＴＡ０での受信（Ｒｘ）動作レベル及び送信（Ｔｘ）動作レベルを、図２０（ｅ）の下側に、通信局ＳＴＡ１での受信（Ｒｘ）動作レベル及び送信（Ｔｘ）動作レベルを示してある。図では、通信局ＳＴＡ１からの要求に応じて変遷する場合を例にとっている。
図２０の初期状態では、通信局ＳＴＡ０、ＳＴＡ１とも互いに関する送受信レベルはレベル３となっている状態でデータの送受信が行われており、通信局ＳＴＡ０に送信データが発生すると直ちにデータの送受が行われている。しかし、図２０においては、このデータの送受が頻繁には行われず、データＤ１８を送受信してからしばらく経過した後にデータＤ１９が送受信され、さらにしばらくデータが送信されないという状態に陥っている。すると、通信局ＳＴＡ１は、データの送受信が許容値を超えて離散的にしか行われていないことを理由に、通信局ＳＴＡ０に関する受信動作レベルをレベル２に変更することを決定する。その後、通信局ＳＴＡ１は、自局のビーコン送信タイミングで送信するビーコン（Ｂ１−２１）あるいはその直後に送信するデータ（図示せず）において、「ＳＴＡ１はＳＴＡ０に関する受信動作レベルをレベル２へと変更する」旨を通達し、通達どおりに動作レベルをレベル２へと変更する。これを受信した通信局ＳＴＡ０は、通信局ＳＴＡ１に関する送信動作レベルをレベル２へと変更する。
動作レベル２へ以降した後は、先に説明した手順で送信トリガを生成し、送信トリガを皮切りにデータの送受信を行う。
上記の例においては、通信局ＳＴＡ１は、「データの送受信が許容値を超えて離散的にしか行われていないこと」を理由に動作レベルをレベル２へと変更したが、より具体的には、「受信動作レベル２でも十分受信できる量のデータしか送受信が行われなかったこと」を理由に変更する場合もある。
また、上述した例においては、動作レベルを下げる旨を通達する手順をふんだが、これを省略する場合もある。この場合、受信側のＳＴＡ１における許容値を送信側のＳＴＡ０における許容値よりも高く設定しておくことで無駄な処理を省くことができる。
また、上記の例においては、受信側である通信局ＳＴＡ１が「動作レベルをレベル３からレベル２へと変更する」旨を決定したが、送信側である通信局ＳＴＡ０が決定し、受信側がこれに追従する場合もある。この場合の手順は、上記で説明した手順と類似するため、とりたてて説明は行わない。
・ネットワークブロードキャスト
上記で説明したように、各通信局は、データの送受信を行わない状態においては、送受信レベルはレベル０になっており、省電力化が行われることになる。
一方、ネットワーク全体に伝達するブロードキャスト情報を送信する際には、例えば図２１Ａ，Ｂ，Ｃに示すような形で順に伝達され、各通信局は隣接する通信局に対して、受信したブロードキャスト情報を伝達していき、ネットワーク内の全ての通信局に伝送する形態がとられる。
送受信レベル０においてブロードキャスト情報を送受信する際には、各通信局の送信ビーコンの直後を狙って複数回にわたりメッセージの送信を行う必要があり、無駄が多い。ブロードキャスト情報が連続して発生するような場合においては、トラヒックが増えてしまい帯域の無駄遣いにもつながる。
・ブロードキャスト送受信手順
そこで、ブロードキャスト情報が発生した場合には、自局の動作状態をＡＣＴ−１ａｌｌとして、全ての隣接通信局に関する受信動作レベルをレベル１に設定した後に、隣接通信局に対して「動作状態をＡＣＴ−１ａｌｌに変更する旨のリクエスト」を送信しながら、各通信局に関する送信動作レベルを変更していき、近隣局リストに登録されている送信動作レベルが１になるまで、自局の送信ビーコン内部あるいはビーコン送信の直後に送信するパケットにおいて、ブロードキャスト情報を報知する。また、送信ビーコンや上記のリクエスト情報には、自局の動作状態を記載する。
具体的な例を図２２に時系列で示す。図２２は、ブロードキャスト情報の送受信手順一例を示す図であり、例えば図２１に示したような通信局の配置において、通信局ＳＴＡ０が通信局ＳＴＡ１と通信局ＳＴＡ２に対してブロードキャスト情報を伝達する場合を例にとっている。図２２（ａ）は、通信局ＳＴＡ０でのパケットの送受信状態であり、図２２（ｂ）は、通信局ＳＴＡ１でのパケットの送受信状態であり、図２２（ｃ）は、通信局ＳＴＡ２でのパケットの送受信状態である。また、図２２（ａ）の上側には、各通信局ＳＴＡ０，ＳＴＡ１，ＳＴＡ２の動作レベルを示してある。
この図２２の時系列各時刻の例における各通信局の動作状態と近隣局リストの状態を、図２３に示す。
図２２の初期状態である時刻Ｔ０においては、各通信局とも動作レベル０であり、自局のビーコンの送信とその直後のリッスンウィンドウ（ＬＷ）にわたる受信処理しか行っていない。このとき、図２３に示したとおり、各局の近隣局リストの項目は全て動作レベル０（ＡＣＴ−０）になっている。
その後、時刻Ｔ１において、通信局ＳＴＡ０に送信すべきブロードキャスト情報が到着する。これをきっかけに、通信局ＳＴＡ０は自局の動作状態をＡＣＴ−１ａｌｌに設定し、近隣局リストに存在する全ての通信局に関する受信動作レベルをレベル１に設定する。この時点で、通信局ＳＴＡ０は各通信局のビーコンを受信するモードへと移行したことになる。
その後、通信局ＳＴＡ０は、通信局ＳＴＡ１のビーコン送信時刻Ｔ２において通信局ＳＴＡ１が送信するビーコンを受信すると、通信局ＳＴＡ１に宛てて「動作状態をＡＣＴ−１ａｌｌに変更してほしい」旨を示すページ情報を送信する。通信局ＳＴＡ１は、これを了解し、報知情報として（すなわち宛先アドレスをブロードキャストアドレスとして）「自局は動作状態をＡＣＴ−１ａｌｌに変更した」旨を示すインディケイション（Ｉｎｄｉｃａｔｉｏｎ）情報を時刻Ｔ３にて送信する。この時点で、通信局ＳＴＡ１は、動作状態をＡＣＴ−１ａｌｌに設定し、近隣局リストに存在する全ての通信局に関する受信動作レベルをレベル１に設定し、かつページ情報の送信元である通信局ＳＴＡ０に対する送信動作レベルをレベル１に設定する。また、通信局ＳＴＡ１が送信した上記インディケイション情報を受信した通信局ＳＴＡ０では、通信局ＳＴＡ１に関する送信動作レベルをレベル１にセットする。
その後、時刻Ｔ４において、通信局ＳＴＡ０のビーコン送信時刻となる。ビーコンには、通信局ＳＴＡ０の動作状態がＡＣＴ−１ａｌｌになっている旨が記載されている。このとき、通信局ＳＴＡ０においては、すでに通信局ＳＴＡ１に関する送信動作レベルがレベル１に設定されているため、通信局ＳＴＡ１が受信を行っているものと認識し、ブロードキャスト情報を送信する。通信局ＳＴＡ１では、これを受信する。しかし、通信局ＳＴＡ０は、自局の近隣局リストにおいては、登録されている通信局ＳＴＡ２に関する送信動作レベルがレベル０であるため、通信局ＳＴＡ２に対してはブロードキャスト情報が配送されていないことを認識する。なお、通信局ＳＴＡ０は、自局の近隣局リストに登録されている全ての通信局に関する送信動作レベルがレベル１以上になるまでブロードキャスト情報を送信しない場合もある。
さらにその後、通信局ＳＴＡ１ならびＳＴＡ０は、時刻Ｔ５で通信局ＳＴＡ２が送信するビーコンを受信すると、通信局ＳＴＡ２に宛てて「動作状態をＡＣＴ−１ａｌｌに変更してほしい」旨を示すページ情報を送信する。図では、たまたま通信局ＳＴＡ０が送信した場合の例が示されている。通信局ＳＴＡ２はこれを了解し、上記と同様の手順で、「自局は動作状態をＡＣＴ−１ａｌｌに変更した」旨を示すインディケイション情報を報知情報として時刻Ｔ６にて送信する。この時点で、通信局ＳＴＡ２は、動作状態をＡＣＴ−１ａｌｌに設定し、近隣局リストに存在する全ての通信局に関する受信動作レベルをレベル１に設定し、かつページ情報の送信元である通信局ＳＴＡ０に対する送信動作レベルをレベル１に設定する。また、通信局ＳＴＡ１が送信した上記インディケイション情報を受信した通信局ＳＴＡ０とＳＴＡ１では、通信局ＳＴＡ２に関する送信動作レベルをレベル１にセットする。
その後、時刻Ｔ７において、通信局ＳＴＡ１のビーコン送信となる。ビーコンには、通信局ＳＴＡ１の動作状態がＡＣＴ−１ａｌｌになっている旨が記載されている。このとき、通信局ＳＴＡ１においては、先ほど通信局ＳＴＡ０からブロードキャスト情報を受信している場合には、ブロードキャスト情報を送信する。この時点で、ブロードキャスト情報は通信局ＳＴＡ１及びＳＴＡ２に対して送信されたことになる。一方、通信局ＳＴＡ２は、通信局ＳＴＡ１のビーコンを受信することにより、通信局ＳＴＡ１の動作状態がＡＣＴ−１ａｌｌになっている旨を認識し、通信局ＳＴＡ−１に関する送信動作レベルをレベル１へと変更する。
その後、時刻Ｔ８において、通信局ＳＴＡ０がビーコンを送信し、この時点で通信局ＳＴＡ０では全隣接局に関する送信動作レベルが１になっているためブロードキャスト情報を送信する。
上記のような手順で、各通信局は、互いに隣接する通信局の動作状態をＡＣＴ−１ａｌｌへと変更させていくことができる。変更された動作状態は、一定時間にわたり受信データなどが存在しないことを理由にＡＣＴ−０へと戻す場合もある。
・ビーコン記載情報
上記の説明で、動作状態をビーコンに記載するという説明を行ったが、ビーコン記載情報に関してもう少し詳細に説明を行う。
図２４は、本システムにおけるビーコン記載情報の一部の例を示す図である。ビーコンには、少なくとも送信局のアドレス（ＳＴＡ−ＩＤ）、受信可能なビーコンの受信時刻を示すフィールド（ＮＢＯＩ）、受信動作レベル１以上で実際に受信を行っているビーコンの受信時刻を示すフィールド（ＮＢＡＩ）、そして、該通信局の動作状態を示すフィールド（Ａｃｔｉｖｉｔｙ Ｓｔａｔｕｓ）が存在する。
ＳＴＡ−ＩＤは、送信局を特定するアドレスが記載されている。通信局の動作状態を示すフィールド（Ａｃｔｉｖｉｔｙ Ｓｔａｔｕｓ）は、上記で説明した動作状態を示すフィールドであり、下記の動作状態のうちのいずれかが示される。
ＡＣＴ−０ａｌｌ：受信動作レベルがレベル０となっている隣接局が一つ以上存在する。
ＡＣＴ−１ａｌｌ：全ての隣接局の受信動作レベルがレベル１以上となっている。
ＡＣＴ−３ａｌｌ：一つ以上の隣接局に関する動作レベルが３になっている。
・動作レベル変更要求メッセージ
ここまでは、通信局が自局の動作レベルの変遷の決定を、ビーコン信号によって通信相手局に伝える実施の形態について説明したが、次に、ビーコン信号以外のメッセージの送信をトリガにして、動作レベルを変更する手順について説明する。
図２５に動作レベルを上げる方向に変遷させる場合の手順を示す。
動作レベルは、トラヒックの存在しない状態においては０であるが、ある通信局のＭＡＣレイヤに他の通信局宛てのトラヒックが届けられると、リンクのＡｃｔｉｖｉｔｙを上げる処理が起動される。その後、さらに多くのトラヒックが送信側のＭＡＣレイヤに届けられるに従い、Ａｃｔｉｖｅ Ｌｅｖｅｌが上げられていく。
図２５では、ノード＃１をトラヒックの送信元ノード、ノード＃２を宛先ノードとした場合を例にとった。図示したように、動作レベルの増加は送信元により指示が出されることをトリガとして起動する。送信側は、宛先ノードに動作レベルを上げて欲しい場合には、該ノードからのＲｘ．Ａｃｔｉｖｅ Ｌｅｖｅｌが１以上になっていることを確認の後、”ＡＬ^＊＿ＲＱ”なるリクエストメッセージを送信し、宛先ノードに動作レベルを上げて欲しい旨を伝える。受信側では、これを受信すると、送信元ノードに関するＲｘ．Ａｃｔｉｖｅ Ｌｅｖｅｌを指示されたレベルに設定し、さらにＴｘ．Ａｃｔｉｖｅ Ｌｅｖｅｌが１以上になっていることを確認の後、”ＡＬ^＊＿ＣＦ”なる応答メッセージを返送し、送信元ノードにＡｃｔｉｖｅ Ｌｅｖｅｌを上げた旨を通達する。送信側では、これを受信すると、宛先Ｎｏｄｅに関する送信Ａｃｔｉｖｅ Ｌｅｖｅｌを指示されたレベルに設定する。
図示したように、全てのＡｃｔｉｖｅ Ｌｅｖｅｌへの上方向の変遷に関して、同様の手順が適用可能である。
なお、Ａｃｔｉｖｅ Ｌｅｖｅｌ＿０→ＡｃｔｉｖｅＬｅｖｅｌ＿１への変遷のトリガは、送信データの発生である。
その後の、Ａｃｔｉｖｅ Ｌｅｖｅｌ＿１→Ａｃｔｉｖｅ Ｌｅｖｅｌ＿２，Ａｃｔｉｖｅ Ｌｅｖｅｌ＿２→Ａｃｔｉｖｅ Ｌｅｖｅｌ＿３への変遷のトリガは、例えば、送信バッファにたまったパケット数の監視し、所定の閾値を超えたことにより起動させてもよい。
次に動作レベルを下げる方向に変遷させる場合の手順を図２６を用いて説明する。
動作レベルは、上げられたもののトラヒックの送受信が途切れてしまった場合に下げる処理が必要になる。トラヒックの送受がない時間を監視するタイマーを保持しておき、このタイマーが満了することをトリガにＡｃｔｉｖｅ Ｌｅｖｅｌを下げる。このとき、Ｔｘ．Ａｃｔｉｖｅ Ｌｅｖｅｌを下げるタイマーとＲｘ．Ａｃｔｉｖｅ Ｌｅｖｅｌを下げるタイマーを別に設定する必要があり、Ｔｘ．Ａｃｔｉｖｅ Ｌｅｖｅｌを下げるタイマーに設定する時間をＲｘ．Ａｃｔｉｖｅ Ｌｅｖｅｌを下げるタイマーよりも短く設定しておくことによりマージンをもたせ、「送信したものの受信機が受信していない」という無駄なトラヒックの発生を抑えるできる。
また、Ａｃｔｉｖｅ Ｌｅｖｅｌを下げる場合の処理としては，上げる場合と同様にメッセージの交換による手順をふむことも考えられる。この場合であっても、突如通信が途絶えたリンクに対応するために，タイマーによりＡｃｔｉｖｅ Ｌｅｖｅｌを下げる機構は必要となる。
なお、上述した実施の形態では、送信や受信を行う専用の通信装置とした構成した例について説明したが、例えば各種データ処理を行うパーソナルコンピュータ装置に、本例の送信部や受信部に相当する通信処理を行うボードやカードなどを装着させた上で、ベースバンド部での処理を、コンピュータ装置側の演算処理手段で実行するソフトウェアを実装させるようにしても良い。
引 用 符 号 の 説 明
１ ‥‥‥ アンテナ
２ ‥‥‥ アンテナ共用器
３ ‥‥‥ 受信処理部
４ ‥‥‥ 送信処理部
５ ‥‥‥ ベースバンド部
６ ‥‥‥ インターフェース部
７ ‥‥‥ ＭＡＣ（メディアアクセスコントロール）部
８ ‥‥‥ ＤＬＣ（データリンクコントロール）部
１００ ‥‥‥ 無線通信装置
１０１ ‥‥‥ インターフェース
１０２ ‥‥‥ データ・バッファ
１０３ ‥‥‥ 中央制御部
１０４ ‥‥‥ ビーコン生成部
１０６ ‥‥‥ 無線送信部
１０７ ‥‥‥ タイミング制御部
１０９ ‥‥‥ アンテナ
１１０ ‥‥‥ 無線受信部
１１２ ‥‥‥ ビーコン解析部
１１３ ‥‥‥ 情報記憶部

Claims (31)

1. 制御局と被制御局の関係を有しない複数の通信局からなるネットワークにおいて無線通信動作を行うための通信方法であって、通信局は、ネットワークに関する情報を記述したビーコンを送信するステップと、
   前記ビーコン信号の送信に前後する時間帯に受信動作を行う状態を設定するステップと、
   を具備することを特徴とする通信方法。
2. 請求の範囲第１項記載の通信方法において、
   前記ビーコン信号は、ネットワーク内の作動状態にある通信局が、定期的に送信する信号である
   通信方法。
3. 請求の範囲第２項記載の通信方法において、
   各通信局は、複数の送信動作レベル又は複数の受信動作レベルを、送信データの有無若しくは通信相手からの動作レベル切換要求に応じて切り換える
   ことを特徴とする通信方法。
4. 請求の範囲第２項記載の通信方法において、
   さらに、所定の周期ごとに、ビーコン信号送信間隔にわたって受信動作を行なう状態を設定するステップ
   とを具備することを特徴とする通信方法。
5. 請求の範囲第１項記載の通信方法において、
   前記通信局は、送信すべき情報が発生する可能性のある相手局がビーコン信号を送信する時間帯及びその周辺時間帯で受信動作を行う状態を設定するステップ
   とを具備することを特徴とする通信方法。
6. 請求の範囲第１項記載の通信方法において、
   前記通信局は、送信すべき情報が発生した場合に、情報を送信すべき通信局との間で情報の伝送を目的とするメッセージの交換を行うステップと、
   前記通信相手局がビーコン信号を送信する時間帯及びその周辺時間帯での受信動作を行なう状態を設定するステップ
   とを具備することを特徴とする通信方法。
7. 請求の範囲第２項記載の通信方法において、
   ビーコン信号送信間隔の間に、１つ以上の送信トリガ時刻を生成するステップと
   前記送信トリガ時刻を基準に送信又は受信の手順を開始する
   通信方法。
8. 請求の範囲第１項記載の通信方法において、
   前記通信局は、送信情報が発生した場合に、情報を送信すべき通信局との間で情報の伝送を目的とするメッセージの交換を行うステップと、
   前記通信相手局がビーコン信号を送信する時間帯及びその周辺時間帯での受信動作を行なう状態を設定するステップと、
   送信局において保持されている送信すべき情報量が増大してきたかどうか判断するステップと、
   送信局において保持されている送信すべき情報量が増大してきた場合にビーコン信号送信間隔の間に、１つ以上の送信トリガ時刻を生成するステップとを備えて、
   送信局において送信すべき情報が存在する場合には、前記送信トリガ時刻を基準に送受信手順を開始する
   通信方法。
9. 請求の範囲第８項記載の通信方法において、
   前記通信局は、送信すべき情報量がさらに増大してきたと判断された場合に、連続的な受信動作又は送信動作を行う
   通信方法。
10. 請求の範囲第１項記載の通信方法において、
    前記ビーコン信号に記述されたネットワークに関する情報は、前記ネットワーク内で通信が可能な通信局の通信状態情報であり、
    通信局は前記通信状態情報を保持する
    ことを特徴とする通信方法。
11. 請求の範囲第１０項記載の通信方法において、
    保持された前記通信状態情報を、送信データの有無若しくは受信した通信状態変更要求情報により変更する
    ことを特徴とする通信方法。
12. 請求の範囲第１項記載の通信方法において、
    ブロードキャスト情報を送信する通信局は、自局から直接送受信が可能であると認識している各通信局に対し、通信相手局がビーコン信号を送信する時間帯及びその周辺時間帯で受信動作を行う状態であることを報知するステップと、
    上記ブロードキャスト情報を送信するステップと
    を具備することを特徴とする通信方法。
13. 請求の範囲第１２項記載の通信方法において、
    前記ブロードキャスト情報は、ビーコン信号又はビーコン信号に続いたパケットにて送信される
    通信方法。
14. 請求の範囲第１２項記載の通信方法において、
    前記ネットワーク内で通信が可能な通信局の通信状態情報をリストとして保持し、保持されたステータスを、送信された変更通知により変更する
    通信方法。
15. 請求の範囲第１２項記載の通信方法において、
    自局の受信状態、又は受信状態に関するステータスを、ビーコン信号にて報知する
    通信方法。
16. 自律分散型の無線通信環境下で構築されるネットワークで動作する通信装置であって、
    無線データを送受信する通信手段と、
    ネットワークに関する情報を記述したビーコン信号を生成して前記通信手段で送信させるビーコン生成手段と、
    前記ビーコン生成手段で生成されたビーコン信号の送信に前後する時間帯に受信動作を行う状態を設定する制御手段と
    を具備することを特徴とする通信装置。
17. 請求の範囲第１６項記載の通信装置において、
    前記ビーコン生成手段で生成されて送信されるビーコン信号は、作動状態にある場合に、定期的に送信する信号である
    通信装置。
18. 請求の範囲第１７項記載の通信装置において、
    前記制御手段は、複数の送信動作レベル又は複数の受信動作レベルを、送信データの有無若しくは通信相手からの動作レベル切換要求に応じて切り換える
    ことを特徴とする通信装置。
19. 請求の範囲第１７項記載の通信装置において、
    さらに前記制御手段は、所定の周期ごとに、ビーコン信号送信間隔にわたって、前記通信手段で受信動作を行なう状態を設定する
    ことを特徴とする通信装置。
20. 請求の範囲第１６項記載の通信装置において、
    前記制御手段は、送信すべき情報が発生する可能性のある相手がビーコン信号を送信する時間帯及びその周辺時間帯で、前記通信手段で受信動作を行う状態を設定する
    ことを特徴とする通信装置。
21. 請求の範囲第１６項記載の通信装置において、
    前記制御手段は、送信すべき情報が発生した場合に、情報を送信すべき相手との間で情報の伝送を目的とするメッセージの交換の制御を行い、前記相手がビーコン信号を送信する時間帯及びその周辺時間帯で、前記通信手段で受信動作を行なう状態を設定する
    とを特徴とする通信装置。
22. 請求の範囲第１７項記載の通信装置において、
    前記制御手段は、ビーコン信号送信間隔の間に、１つ以上の送信トリガ時刻を生成し、前記送信トリガ時刻を基準に前記通信手段での送信又は受信の手順を開始する
    通信装置。
23. 請求の範囲第１６項記載の通信装置において、
    前記制御手段は、送信情報が発生した場合に、情報を送信すべき相手との間で情報の伝送を目的とするメッセージの交換の制御を行い、前記相手がビーコン信号を送信する時間帯及びその周辺時間帯で、前記通信手段で受信動作を行ない、保持されている送信すべき情報量が増大してきたかどうか判断して、送信すべき情報量が増大してきた場合にビーコン信号送信間隔の間に、１つ以上の送信トリガ時刻を生成して、その送信トリガ時刻を基準に前記通信手段での送受信を開始させる
    通信装置。
24. 請求の範囲第２３項記載の通信装置において、
    前記制御手段は、送信すべき情報量がさらに増大してきたと判断された場合に、前記通信手段で連続的な受信動作又は送信動作を実行させる
    通信装置。
25. 請求の範囲第１６項記載の通信装置において、
    前記ビーコン信号に記述されたネットワークに関する情報は、前記ネットワーク内で通信が可能な通信装置の通信状態情報であり、
    前記制御手段は、前記通信手段が受信した前記ビーコン信号に記載された前記通信状態情報を保持する
    ことを特徴とする通信装置。
26. 請求の範囲第１６項記載の通信装置において、
    前記制御手段は、保持された前記通信状態情報を、送信データの有無若しくは受信した通信状態変更要求情報により変更する
    ことを特徴とする通信装置。
27. 請求の範囲第１６項記載の通信装置において、
    制御手段は、前記通信手段からブロードキャスト情報を送信する場合に、当該通信装置と直接送受信が可能であると認識している各通信装置に対し、相手がビーコン信号を送信する時間帯及びその周辺時間帯で受信動作を行う状態であることを報知する
    ことを特徴とする通信装置。
28. 請求の範囲第２７項記載の通信装置において、
    前記ブロードキャスト情報は、ビーコン信号又はビーコン信号に続いたパケットにて送信させる
    通信装置。
29. 請求の範囲第２７項記載の通信装置において、
    前記制御手段は、ネットワーク内で通信が可能な通信装置の通信状態情報をリストとして保持し、保持されたステータスを、前記通信手段で受信した変更通知により変更する
    通信装置。
30. 請求の範囲第２７項記載の通信装置において、
    前記制御手段は、自局の受信状態、又は受信状態に関するステータスを、前記ビーコン生成手段で生成されるビーコン信号に付加して、前記通信手段から送信させる
    通信装置。
31. 複数の通信局で構成されるネットワーク内で、他の局から送信される信号の検出により、他局とパケットの通信タイミングが衝突しないアクセス制御を行うための処理をコンピュータシステム上で実行するようにコンピュータ可読形式で記述されたコンピュータプログラムであって、
    ネットワークに関する情報を記述したビーコンを送信するステップと
    前記ビーコン信号の送信に前後する時間帯に受信動作を行う状態を設定するステップとを具備する
    コンピュータプログラム。

Images