(57)【要約】【課題】  ＤＥＶの消費電力低減を実現するとともに、通信システム全体のスループットを向上することが可能な、時分割多元接続通信を行う無線通信技術を提供する。【解決手段】  制御局端末と子局端末とを備える通信システムであって、子局端末は、予め設定された周期を示す第１周期情報を記憶手段から読み出す読出手段と、第１周期情報に基づいて、省電力モードにおいて制御局端末との接続状態を維持するために行う制御局端末との通信周期を決定する決定手段と、決定手段において決定された通信周期を示す第２周期情報を制御局端末へ送出する送出手段と、を備え、制御局端末は、子局端末から受信した第２周期情報に基づいて、当該子局端末が省電力モードであるときに通信を行うための期間を割り当てる割当手段と、割当手段において割り当てられた期間を子局端末へ通知する通知手段と、を備える。【選択図】  図１６
2008187289.tif 000002
【特許請求の範囲】
【請求項１】
制御局端末と子局端末とを備える通信システムであって、
前記子局端末は、
予め設定された周期を示す第１周期情報を記憶手段から読み出す読出手段と、
前記第１周期情報に基づいて、省電力モードにおいて前記制御局端末との接続状態を維持するために行う前記制御局端末との通信周期を決定する決定手段と、
前記決定手段において決定された前記通信周期を示す第２周期情報を前記制御局端末へ送出する送出手段と、
を備え、
前記制御局端末は、
前記子局端末から受信した前記第２周期情報に基づいて、当該子局端末が省電力モードであるときに通信を行うための期間を割り当てる割当手段と、
前記割当手段において割り当てられた期間を前記子局端末へ通知する通知手段と、
を備える
ことを特徴とする通信システム。
【請求項２】
前記決定手段は、
前記第１周期情報により示される周期が、通信がなくても前記制御局端末との接続状態を維持する予め設定されたタイムアウト値よりも大きい場合は、該タイムアウト値を前記通信周期として決定し、
前記第１周期情報により示される周期が、前記タイムアウト値以下である場合は、前記第１周期情報により示される周期を前記通信周期として決定する
ことを特徴とする請求項１に記載の通信システム。
【請求項３】
前記制御局端末と前記子局端末とは時分割多元接続通信をフレーム単位で行い、
前記決定手段は、
前記通信周期として、前記フレームの期間の、２の冪乗倍又は自然数倍の期間を決定する
ことを特徴とする請求項１又は２に記載の通信システム。
【請求項４】
前記制御局端末は、
前記子局端末から前記第２周期情報を受信した場合は、前記割当手段が前記期間を割り当てるために当該第２周期情報を用いるか否かを判定する判定手段と、
前記判定手段において受信した前記第２周期情報を用いないと判定された場合は、受信した前記第２周期情報を用いない旨を前記制御局端末へ送信する送信手段と、
を更に備え、
前記決定手段は、送出した前記第２周期情報について、前記制御局端末から用いない旨を前記制御局端末から受信した場合、前記通信周期として前記フレームの期間の２の冪乗倍の期間をさらに決定し、
前記送出手段は、前記決定手段においてさらに決定された前記通信周期を示す第２周期情報を前記制御局端末へ送出する
ことを特徴とする請求項３に記載の通信システム。
【請求項５】
制御局端末と通信する子局端末であって、
予め設定された周期を示す第１周期情報を記憶手段から読み出す読出手段と、
前記第１周期情報に基づいて、省電力モードにおいて前記制御局端末との接続状態を維持するために行う前記制御局端末との通信周期を決定する決定手段と、
前記決定手段において決定された前記通信周期を示す第２周期情報を前記制御局端末へ送出する送出手段と、
前記第２周期情報を送出したことに応じて前記制御局端末から通知される、前記制御局端末と当該子局端末との間で通信を行うための期間を示す情報を受信する受信手段と、
省電力モードにおいて、前記制御局端末から通知された前記期間に前記制御局端末と通信する通信制御手段と、
を備えることを特徴とする子局端末。
【請求項６】
子局端末と通信する制御局端末であって、
省電力モードにおいて前記子局端末との接続状態を維持するために前記子局端末が行う通信周期を示す第２周期情報を前記子局端末から受信する受信手段と、
前記子局端末から受信した前記第２周期情報に基づいて、当該子局端末との通信を行うための期間を割り当てる割当手段と、
前記割当手段において割り当てられた期間を前記子局端末へ通知する通知手段と、
を備えることを特徴とする制御局端末。
【請求項７】
制御局端末と通信する子局端末の制御方法であって、
読出手段が、予め設定された周期を示す第１周期情報を記憶手段から読み出す読出工程と、
決定手段が、前記第１周期情報に基づいて、省電力モードにおいて前記制御局端末との接続状態を維持するために行う前記制御局端末との通信周期を決定する決定工程と、
送出手段が、前記決定工程において決定された前記通信周期を示す第２周期情報を前記制御局端末へ送出する送出工程と、
受信手段が、前記第２周期情報を送出したことに応じて前記制御局端末から通知される、前記制御局端末と当該子局端末との間で通信を行うための期間を示す情報を受信する受信工程と、
通信制御手段が、省電力モードにおいて、前記制御局端末から通知された前記期間に前記制御局端末と通信する通信制御工程と、
を備えることを特徴とする子局端末の制御方法。
【請求項８】
子局端末と通信する制御局端末の制御方法であって、
受信手段が、省電力モードにおいて前記子局端末との接続状態を維持するために前記子局端末が行う通信周期を示す第２周期情報を前記子局端末から受信する受信工程と、
割当手段が、前記子局端末から受信した前記第２周期情報に基づいて、当該子局端末との通信を行うための期間を割り当てる割当工程と、
通知手段が、前記割当工程において割り当てられた期間を前記子局端末へ通知する通知工程と、
を備えることを特徴とする制御局端末の制御方法。
【請求項９】
コンピュータを、請求項５に記載の子局端末、又は、請求項６に記載の制御局端末として機能させるためのプログラム。
【請求項１０】
請求項９に記載のプログラムを格納したコンピュータで読み取り可能な記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信システム、子局端末及びその制御方法、制御局端末及びその制御方法、プログラム、記憶媒体に関する。
【背景技術】
【０００２】
無線ネットワークを形成する時分割多元接続通信を行う無線通信システムにおいては、種々の無線通信の規格で省電力モードが定義されている（例えば、非特許文献１、非特許文献２）。省電力モードに移行する場合、子局は、制御局へ子局自身が省電力モードであることを伝え、制御局は、子局からの要求を受け入れると子局からのアクセスタイミングを変更する。
【０００３】
例えば、IEEE802.15.3規格では次の４種類の電源管理モードが存在する。
・起動（ＡＣＴＩＶＥ）。
・Asynchronous Power Save（ＡＰＳ）。
・Device Synchronous Power Save（ＤＳＰＳ）。
・Piconet Synchronous Power Save（ＰＳＰＳ）。
このうち、ＡＣＴＩＶＥを除く後半の３つは省電力モードである。
【０００４】
IEEE802.15.3規格のＡＰＳモードにおいては、ＤＥＶ（子局端末）は、ＡＴＰ期間内で任意の時間にＰＮＣ（制御局端末）へアクセスすることで通信状態を維持する。なお、ＡＴＰは、通信維持期限（Association Timeout Period）の略称であり、通信相手から信号を受け取らないままアソシエーション（接続状態）を継続する時間（タイムアウト値）である。即ち、通信相手から信号を受け取らない場合において、信号を受け取らない時間がＡＴＰを超えるまではアソシエーションが維持されるが、信号を受け取らない時間がＡＴＰを超えるとアソシエーションが解消されることになる。同規格において、ＤＥＶがＰＮＣと通信状態を保つためのフレームはContention Access Period（ＣＡＰ）または自分宛のChannel Time Allocation（ＣＴＡ）である。
【０００５】
ＣＡＰはCarrier Sense Multiple Access with Collision Avoidance（ＣＳＭＡ／ＣＡ）プロトコルを使用する。このため、ＣＡＰ内にＤＥＶがＰＮＣとアクセスする場合、他のＤＥＶとの競合のためアクセスに失敗した場合、ＤＥＶは、アクセスが成功するまで再試行する必要がある。
【０００６】
また、ＣＡＰを使用する場合、ＤＥＶは、自分宛のＣＴＡについて、ビーコンフレームを解析してそのアクセスタイミングを取得する必要がある。このため、ＤＥＶは、受信したフレームに自分宛のＣＴＡが存在しない場合、自分宛のＣＴＡを探し出す迄ビーコンフレームを受信して解析する作業を継続しなければならない。
【０００７】
このような場合において、ＤＥＶの消費電力が増大してしまうという問題があった。特許文献１では、基地局が期間を指定し、その期間の終了時に、活動を休止して省電力化モードになっている移動端末機が基地局からの呼出メッセージを聞く頻度を指定するシステムが開示されている。
【非特許文献１】IEEE Std 802.15.3-2003
【非特許文献２】Bluetooth Specification Version 1.0B
【特許文献１】特表２００３−５１７７４１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
特許文献１に記載の構成では、基地局からの呼び出しメッセージを聞く頻度をスーパーフレームの整数倍としている。無線ＬＡＮ規格であるＩＥＥＥ８０２．１１規格などにおいては通信維持時間のタイムアウトが規定されていないので、この頻度を制限無く設定することができる。しかしながらＩＥＥＥ８０２．１５．３規格のように、ＰＮＣとＤＥＶの間の通信維持時間にタイムアウトがあるシステムでは、基地局からの呼び出しメッセージを聞く頻度を任意の値に設定することができなかった。
【０００９】
このため、従来の構成では、ＤＥＶは、所望とするタイミングで通信を行うことができず、ＤＥＶが起動するために要する時間の削減に限界があり、従って、ＤＥＶの消費電力を十分低下させることができなかった。また、ＰＮＣが不要なアクセスタイミングを設定することがあり、通信システムのスループット向上に限界があった。
【００１０】
本発明は上記問題に鑑みなされたものであり、ＤＥＶの消費電力低減を実現するとともに、通信システム全体のスループットを向上することが可能な、時分割多元接続通信を行う無線通信技術を提供することを目的とする。
【課題を解決するための手段】
【００１１】
上記目的を達成するため、本発明による通信システムは以下の構成を備える。即ち、
制御局端末と子局端末とを備える通信システムであって、
前記子局端末は、
予め設定された周期を示す第１周期情報を記憶手段から読み出す読出手段と、
前記第１周期情報に基づいて、省電力モードにおいて前記制御局端末との接続状態を維持するために行う前記制御局端末との通信周期を決定する決定手段と、
前記決定手段において決定された前記通信周期を示す第２周期情報を前記制御局端末へ送出する送出手段と、
を備え、
前記制御局端末は、
前記子局端末から受信した前記第２周期情報に基づいて、当該子局端末が省電力モードであるときに通信を行うための期間を割り当てる割当手段と、
前記割当手段において割り当てられた期間を前記子局端末へ通知する通知手段と、
を備える。
【００１２】
また、本発明による子局端末は以下の構成を備える。即ち、
制御局端末と通信する子局端末であって、
予め設定された周期を示す第１周期情報を記憶手段から読み出す読出手段と、
前記第１周期情報に基づいて、省電力モードにおいて前記制御局端末との接続状態を維持するために行う前記制御局端末との通信周期を決定する決定手段と、
前記決定手段において決定された前記通信周期を示す第２周期情報を前記制御局端末へ送出する送出手段と、
前記第２周期情報を送出したことに応じて前記制御局端末から通知される、前記制御局端末と当該子局端末との間で通信を行うための期間を示す情報を受信する受信手段と、
省電力モードにおいて、前記制御局端末から通知された前記期間に前記制御局端末と通信する通信制御手段と、
を備える。
【００１３】
また、本発明による制御局端末は以下の構成を備える。即ち、
子局端末と通信する制御局端末であって、
省電力モードにおいて前記子局端末との接続状態を維持するために前記子局端末が行う通信周期を示す第２周期情報を前記子局端末から受信する受信手段と、
前記子局端末から受信した前記第２周期情報に基づいて、当該子局端末との通信を行うための期間を割り当てる割当手段と、
前記割当手段において割り当てられた期間を前記子局端末へ通知する通知手段と、
を備える。
【００１４】
また、本発明による子局端末の制御方法は以下の構成を備える。即ち、
制御局端末と通信する子局端末の制御方法であって、
読出手段が、予め設定された周期を示す第１周期情報を記憶手段から読み出す読出工程と、
決定手段が、前記第１周期情報に基づいて、省電力モードにおいて前記制御局端末との接続状態を維持するために行う前記制御局端末との通信周期を決定する決定工程と、
送出手段が、前記決定工程において決定された前記通信周期を示す第２周期情報を前記制御局端末へ送出する送出工程と、
受信手段が、前記第２周期情報を送出したことに応じて前記制御局端末から通知される、前記制御局端末と当該子局端末との間で通信を行うための期間を示す情報を受信する受信工程と、
通信制御手段が、省電力モードにおいて、前記制御局端末から通知された前記期間に前記制御局端末と通信する通信制御工程と、
を備える。
【００１５】
また、本発明による制御局端末の制御方法は以下の構成を備える。即ち、
子局端末と通信する制御局端末の制御方法であって、
受信手段が、省電力モードにおいて前記子局端末との接続状態を維持するために前記子局端末が行う通信周期を示す第２周期情報を前記子局端末から受信する受信工程と、
割当手段が、前記子局端末から受信した前記第２周期情報に基づいて、当該子局端末との通信を行うための期間を割り当てる割当工程と、
通知手段が、前記割当工程において割り当てられた期間を前記子局端末へ通知する通知工程と、
を備える。
【発明の効果】
【００１６】
本発明によれば、消費電力低減を実現するとともに、通信システム全体のスループットを向上することができる。
【発明を実施するための最良の形態】
【００１７】
以下、添付図面を参照して本発明に係る実施の形態を詳細に説明する。ただし、この実施の形態に記載されている構成要素はあくまでも例示であり、本発明の範囲をそれらのみに限定する趣旨のものではない。
【００１８】
＜＜実施形態１＞＞
本実施形態について、IEEE802.15.3規格を想定して説明する。本実施形態の通信装置と通信システムの構成を、図１と図２を参照して説明する。通信装置は単一の通信装置で実現しても良いし、必要に応じた複数の機能追加した形態で実現しても良い。
【００１９】
（通信システム）
まず、本実施形態に係る通信装置の構成について図１を参照して説明する。図１は、本実施形態に係る通信装置のハードウェア構成を模式的に示したブロック図である。図１において、１１０は通信装置全体を制御する制御手段としてのCentral Processing Unit（ＣＰＵ）である。１２０は外部装置などから供給されるプログラムやデータを一時記憶するRandom Access Memory（ＲＡＭ）である。１３０は変更を必要としないプログラムやパラメータを格納するRead Only Memory（ＲＯＭ）である。１４０は無線通信機能を実現する無線通信インターフェイス（送受信手段）である。１５０は無線通信インターフェイス１４０に使用するアンテナである。無線通信装置は上記の構成で実現しても良いし、必要に応じて記憶装置、表示装置などの機能を追加した形態で実現しても良い。
【００２０】
尚、以上の各装置と同等の機能を実現するソフトウェアにより、ハードウェア装置の代替として構成することもできる。
【００２１】
本実施形態では、ＲＯＭ１３０から本実施形態に係るプログラム及び関連データをＲＡＭ１２０にロードして実行させる例を示すが、これに限られない。例えば、本実施形態に係るプログラムを動作させる度に、既にプログラムがインストールされているハードディスク装置やメモリ装置等からＲＡＭ１２０にロードするようにしてもよい。或いは、本実施形態に係るプログラムをＲＯＭ１３０に記録しておき、これをメモリマップの一部をなすように構成し、直接ＣＰＵ１１０で実行することも可能である。
【００２２】
また、本実施形態では、説明の便宜のため、本実施形態に係る通信装置を１つの装置で実現した構成について述べるが、複数の装置にリソースを分散した構成によって実現してもよい。例えば、記憶や演算のリソースを複数の装置に分散した形に構成してもよい。或いは、通信装置上で仮想的に実現される構成要素毎にリソースを分散し、並列処理を行うようにしてもよい。
【００２３】
次に、本実施形態における通信システムの構成について図２を参照して説明する。図２は、本実施形態における通信システムの構成を模式的に示す図である。図２において、２１０は、ピコネット制御局（制御局端末）としての機能を持つPiconet Coordinator（ＰＮＣ）である。２２０は、子局端末としての機能を持つDevice（ＤＥＶ）である。２００は、ＰＮＣ２１０とＤＥＶ２２０で構成されるピコネットである。ＰＮＣ２１０、ＤＥＶ２２０は、それぞれ図１に例示したハードウェア構成を有する。図２では、ＰＮＣが制御するＤＥＶが一台だけであるが、必要に応じてＤＥＶが複数存在しても良い。本実施形態の通信システムはＰＮＣとＤＥＶで構成されるピコネットを形成して実現される。これらの端末は、ＴＤＭＡ（時分割多元接続通信）に基づいて通信を行う。
【００２４】
（フレーム構成）
次に、IEEE802.15.3規格のフレーム構成について、図３を参照して説明する。図３は、IEEE802.15.3規格のフレーム構成を模式的に示す図である。同規格はスーパーフレームと呼ばれるフレーム単位で、ＰＮＣがピコネット内のＤＥＶを制御する。各フレームはMedium Access Controller（ＭＡＣ）ヘッダ、及び、ＭＡＣフレームボディから構成され、詳細は後述する。
【００２５】
図３において、３００、３１０及び３２０はスーパーフレームである。ス−パーフレーム３１０の構成を以下に説明する。３１１はビーコンフレーム、３１２はＣＡＰフレーム、３１３はChannel Time Allocation Period（ＣＴＡＰ）フレームである。ビーコンフレーム３１１については図７を参照して後述する。ＣＡＰフレーム３１２にはＣＳＭＡ／ＣＡプロトコルを用いる。このフレームはオプションであるので、ＰＮＣによっては使用しないこともある。ＣＴＡＰフレーム３１３はＤＥＶ同士の通信に用いられるＣＴＡフレームとＰＮＣとＤＥＶでの通信に用いられるManagement Channel Time Allocation（ＭＣＴＡ）で構成される。ＣＴＡフレームとＭＣＴＡフレームの個数、配置はＰＮＣが任意に配置することができる。
【００２６】
（ＭＡＣヘッダ）
次に、IEEE802.15.3規格のフレームを構成するＭＡＣヘッダについて、図４を参照して説明する。図４は、ＭＡＣヘッダの構成を示す模式図である。
【００２７】
図４においては、データの先頭は右側である。以下その他のフレームフォーマットもこの規則で記述する。４００はそのフレーム自身の情報を示すＭＡＣヘッダであって以下のフィールドで構成される。４１０は２オクテットで構成されるフレームコントロールフィールドであり図５を参照して後述する。４２０は２オクテットで構成されるピコネットＩＤを示すＰＮＩＤフィールドである。４３０は１オクテットで構成されるフレームの送信先を示すＤｅｓｔＩＤフィールドである。４４０は１オクテットで構成されるフレームの送信元を示すＳｒｃＩＤフィールドである。４５０はフレームが分割されているときの制御に用いるフラグメンテーションコントロールフィールドであり３オクテットで構成される。４６０は同期／非同期データなどの識別に使用されるストリームインデックスフィールドであり１オクテットで構成される。
【００２８】
（フレームコントロールフィールド）
次に、ＭＡＣヘッダに含まれるフレームコントロールフィールド４１０の詳細について、図５を参照して説明する。図５はフレームコントロールフィールドのフィールド構成を示す模式図である。
【００２９】
図５において、５０１は３ビットで構成されるプロトコルバージョンフィールドである。５０２は３ビットで構成されるフレームタイプフィールドであり、そのフレームがビーコンフレームであるか、データフレームであるかなどを記述している。図２４は、フレームタイプフィールド５０２の値とフレームタイプとの関係を示す図である。５０３は１ビットで構成されるＳＥＣビットであり、フレームが暗号化されているときには１、されていない時には０に設定されなければならない。５０４は２ビットで構成されるAcknowledge（ＡＣＫ）ポリシーフィールドであってＡＣＫ手順のタイプを定義する。図２５は、ＡＣＫポリシーフィールド５０４の値とタイプとの関係を示す図である。５０５は１ビットで構成されるリトライビットであり、再送されたフレームは１に設定されなければならず、それ以外は０である。５０６は１ビットで構成されるモアデータビットであって、延長されたフレームの時には１に設定され、延長されない若しくは延長された最後のフレームの時には０に設定されなければならない。５０７は５ビットで構成される予約ビットである。
【００３０】
（ＭＡＣフレームボディ）
次に、IEEE802.15.3規格のフレームを構成するＭＡＣフレームボディについて、図６を参照して説明する。図６は、ＭＡＣフレームボディの構成を示す模式図である。
【００３１】
ＭＡＣフレームボディの暗号化／非暗号化はＭＡＣヘッダ４００中のＳＥＣビット５０３によって定義される。本実施形態では説明の簡単のため非暗号化ＭＡＣフレームボディを用いて以下説明する。６００は非暗号化ＭＡＣフレームボディであって、以下のフィールドで構成される。６０１はフレームのデータ部分であるフレームペイロードであり、その長さはＬｎオクテットである。６０２は４オクテットで構成されるFrame Check Sequence（ＦＣＳ）フィールドであり、ＡＮＳＩ Ｘ３．６６−１９７９相当のCyclic Redundancy Check（ＣＲＣ）が格納される。
【００３２】
（非暗号化ビーコンフレームボディ）
図７は非暗号化ビーコンフレームボディ７００（図３の３１１に相当）のフォーマットを示す模式図である。ＭＡＣヘッダ４００によってビーコンであることが示されると、フレームボディは７００のように各フィールドで構成される。７０１はピコネット同期パラメータフィールドであり、図８を参照して後に詳述する。７０２−７０３はインフォメーションエレメント（ＩＥ）フィールドであり、図１１を参照して後に詳述する。ＩＥフィールドは任意の個数を持つことができる。７０４はＦＣＳフィールドである。
【００３３】
（ピコネット同期パラメータフィールド）
次に、非暗号化ビーコンフレームボディ７００に含まれるピコネット同期パラメータフィールド７０１について、図８を参照して説明する。図８はピコネット同期パラメータフィールド７０１の構成を示す模式図である。
【００３４】
図８のように、ピコネット同期パラメータフィールド７０１は、以下のフィールドで構成される。８０１はビーコンごとに増加されるロールオーバカウンタ値を保持するタイムトークンフィールドであり６オクテットで構成される。８０２は現在のスーパーフレーム時間長を1ms単位で示すスーパーフレーム期間フィールドであり２オクテットで構成される。８０３はスーパーフレームにおけるＣＡＰ終了時間を示すＣＡＰ終了時間フィールドであって２オクテットで構成される。８０４はピコネット内のＰＮＣによって許可された現在のスーパーフレームでの最大送信電力レベルを示す最大送信電力レベルフィールドであり１オクテットで構成される。８０５は１オクテットで構成されるピコネットモードフィールドであり、詳細は図９を参照して後に説明する。８０６は１オクテットで構成されるＰＮＣレスポンスフィールドであり詳細は図１０を参照して後に説明する。８０７はＰＮＣのＤＥＶアドレスを示すＰＮＣアドレスフィールドであり８オクテットで構成される。
【００３５】
（ピコネットモードフィールド）
次に、ピコネット同期パラメータフィールド７０１に含まれるピコネットモードフィールド８０５について、図９を参照して説明する。図９は、ピコネットモードフィールド８０５のフォーマットを示す模式図である。
【００３６】
９０１は、現在のスーパーフレーム中のＣＡＰ期間にデータを送信することができるかを示すＣＡＰデータビットであり１ビットで構成される。データ送信が許可される場合にはＣＡＰデータビットは１にセットされる。９０２は現在のスーパーフレーム中のＣＡＰ期間にコマンドを送信することができるかを示すＣＡＰコマンドビットであり１ビットで構成される。アソシエーション要求以外のコマンド送信が許可される場合にはＣＡＰデータビットは１にセットされる。９０３は現在のスーパーフレーム中のＣＡＰ期間にアソシエーションコマンド送信することができるかを示すＣＡＰアソシエーションビットであり１ビットで構成される。データ送信が許可される場合にはＣＡＰアソシエーションビットは１にセットされる。
【００３７】
（ＰＮＣレスポンスフィールド）
次に、ピコネット同期パラメータフィールド７０１に含まれるＰＮＣレスポンスフィールド８０６のフィールド構成について、図１０を参照して説明する。図１０は、ＰＮＣレスポンスフィールド８０６のフィールド構成を示す模式図である。
【００３８】
１００１は、オープンＭＣＴＡあるいは各ＤＥＶに対するアップリンクＭＣＴＡをＰＮＣが割り当てる頻度を示すＭＣＴＡ配置率フィールドであり４ビットで構成される。値が０の場合にはＰＮＣへのアクセスはＣＡＰ期間中のみ使用する事を示し、値が１５の時にはＰＮＣがＭＣＴＡ割当時間を保証しないことを示す。１００２は予約フィールドであり４ビットで構成される。
【００３９】
（ＩＥフィールド）
次に、非暗号化ビーコンフレームボディ７００に含まれるＩＥフィールド７０２について、図１１を参照して説明する。図１１は、ＩＥフィールド７０２のフォーマットを示す模式図である。
【００４０】
１００１はＩＥフィールドのタイプを示すエレメントＩＤフィールドであり１オクテットで構成される。図２６は、エレメントＩＤフィールド１００１の値とタイプの関係とを示す図である。１１０２はＩＥフィールドの長さを示すレンクスフィールドであり１オクテットで構成される。１１０３はＩＥフィールドのデータを示すＩＥペイロードフィールドでありレンクスフィールド１１０２で示されるオクッテット長で構成される。
【００４１】
（コマンドフォーマット）
次に、IEEE802.15.3規格においてＤＥＶがＡＰＳモードに移行するのに必要となるコマンドフォーマットについて説明する。コマンドフレームはＭＡＣヘッダ４００のフレームコントロールフィールド４１０の値を０１１にセットすることで実現できる。
【００４２】
図１２は、非暗号化コマンドフレームのフォーマットを示す模式図である。１２０１はＭＡＣヘッダであり２オクテットで構成される。１２０２は長さ４＋Ｌオクテットで構成されるコマンドブロックであり、図１３を参照して後に詳細を説明する。１２０３はＦＣＳである。
【００４３】
（コマンドブロック）
次に、非暗号化コマンドフレームのフォーマットに含まれるコマンドブロック１２０２について、図１３を参照して説明する。図１３は、コマンドブロック１２０２のフォーマットを示す模式図である。
【００４４】
図１３において、１３０１は２オクテットから構成されるコマンドタイプフィールドである。図２７は、コマンドタイプフィールド１３０１の値と、そのタイプとの関係を示す図である。１３０２はコマンドブロックのペイロード長を表すレンクスフィールドあり２オクテットで構成される。１３０３はコマンドペイロードフィールドである。
【００４５】
（アソシエーション動作）
次に、ＤＥＶ２２０がＰＮＣ２１０にアソシエーションするときの動作について、図１４を参照して説明する。図１４は、アソシエーションするときのメッセージのシーケンスを示すメッセージシーケンスチャート（ＭＳＣ：Message Sequence Chart）である。
【００４６】
Ｓ１４０１では、ＤＥＶ２２０は、ＰＮＣ２１０へＤＥＶＩＤ＝ｕｎａｓｓｏｃＩＤ，ＤＥＶ  ａｄｄｒｅｓｓ＝ＤＥＶ２２０に設定してアソシエーション要求コマンドを送信している。Ｓ１４０１により、アソシエーション要求コマンドを受信すると、ＰＮＣ２１０は、新たなＤＥＶをサポートするだけのリソースが存在することをＰＮＣ２１０が管理するリストを参照して確認しなければならない。
【００４７】
Ｓ１４０２では、ＰＮＣ２１０はImmediate（Ｉｍｍ）  ＡｃｋをＤＥＶ  ＩＤ＝ｕｎａｓｓｏｃＩＤに設定して返信する。ＰＮＣ２１０がもしもＤＥＶ２２０に十分なリソースがあると判断した場合、Ｓ１４０３において、ＰＮＣ２１０は、アソシエーションが可能であることを意味するアソシエーション応答コマンドをＤＥＶ２２０に送信する。即ち、アソシエーションコマンドをＤＥＶＩＤ＝ｘｘ（１６進値）、ＤＥＶ  ａｄｄｒｅｓｓ＝ＤＥＶ２２０、Ｒｅａｓｏｎ  Ｃｏｄｅ＝Ｓｕｃｃｅｓｓに設定してＤＥＶ２２０に送信する。この時にＡＴＰ（通信維持期限）も同時に送信される。なお、上述のように、ＡＴＰは、通信がなくてもＰＮＣ２１０とＤＥＶ２２０との間の接続状態を維持する予め設定されたタイムアウト値である。
【００４８】
Ｓ１４０３においてアソシエーション応答コマンドをＰＮＣ２１０が送信した時点では、ＤＥＶ２２０がアソシエーションされたことを意味しないので、ＤＥＶ２２０はＡＴＰ期間内に次のコマンドフレームを送信しなければならない。ＤＥＶ２２０は自分自身のＤＥＶアドレスに一致するＤＥＶアドレスを持ったアソシエーション返答コマンドを受信すると、Ｓ１４０４の処理を行わなければならない。即ち、Ｓ１４０４において、ＳｒｃＩＤフィールドに新たに割り当てられたＤＥＶＩＤを設定した第２のアソシエーション要求コマンドをＣＡＰあるいはアソシエーションＭＣＴＡ期間中に送信しなければならない。Ｓ１４０４において第２のアソシエーション要求コマンドを受信したＰＮＣ２１０は、ＤＥＶ２２０のＤＥＶＩＤ，ＤＥＶアドレス等を初期化しなければならない。Ｓ１４０５において、ＰＮＣ２１０は、この第２のアソシエーション要求コマンドに対するＡｃｋを送信し、ＤＥＶ２２０が受信することによって、ＤＥＶ２２０は自分がアソシエーションされたとみなす。
【００４９】
（ＡＰＳモードへの移行）
ＤＥＶがＡＰＳ（Asynchronous Power Save）モードに移行するときの動作について、図１５を参照して説明する。図１５は、ＤＥＶがＡＰＳモードに移行するときのメッセージシーケンスチャート（ＭＳＣ）である。
【００５０】
図１４に示す通りＤＥＶ２２０とＰＮＣ２１０がアソシエーションしてピコネット２００を形成しているとする。Ｓ１５０１でＤＥＶ２２０のPower Management（ＰＭ）モードがＡＣＴＩＶＥ設定されていた場合、Ｓ１５０２において、ＤＥＶ２２０はＰＮＣへＰＭモードチェンジコマンドを送信する。Ｓ１５０３でImmediate（Ｉｍｍ．）ＡＣＫが返信されると、Ｓ１５０４において、ＤＥＶ２２０は、ＰＭモードをＡＰＳにセットする。Ｓ１５０５で、ＰＮＣ２１０が、ＰＳ  Ｓｔａｔｕｓ  ＩＥのＰＳ  Ｓｅｔ＝０に設定されたビーコンフレームを送信することでＡＰＳモードへの移行が完了する。
【００５１】
（ＣＴＡ  Ｒａｔｅ  Ｆａｃｔｏｒの算出）
次に、図１５においてＡＰＳモードであるＤＥＶ２２０がＣＴＡ  Ｒａｔｅ  Ｆａｃｔｏｒを算出する手順について、図１６を参照して説明する。図１６は、ＣＴＡ  Ｒａｔｅ  Ｆａｃｔｏｒを算出するときの処理手順を示すフローチャートである。ただし、ＣＴＡ  Ｒａｔｅ  Ｆａｃｔｏｒは、ＤＥＶ２２０がＰＮＣ２１０へアクセスする周期を示す値であり、ＣＴＡの間隔をスーパーフレームの期間単位で表したものである。この周期は、省電力モードにおいてＰＮＣ２１０との接続状態を維持するために行うＰＮＣ２１０との通信周期に該当する。例えば、ＣＴＡ  Ｒａｔｅ  Ｆａｃｔｏｒ＝２は２つのスーパーフレーム期間毎にＣＴＡが配置されることを示しており、ＣＴＡ  Ｒａｔｅ  Ｆａｃｔｏｒ＝５は５つのスーパーフレーム期間毎にＣＴＡが配置されることを示す。
【００５２】
本実施形態では同規格でＣＴＡ  Ｒａｔｅ  Ｆａｃｔｏｒが規定値である２のべき乗値である場合について例示的に説明する。まず、ステップＳ１６０１において、ＤＥＶ２２０は、以下のデータが一時記憶されている記憶手段としてのＲＡＭ１２０からＣＰＵ１１０のレジスタに読み出す（ロード(load)する、読出を行う）。
・Ｓ１４０３で得られたＡＴＰ。
・Ｓ１５０５などのビーコンフレームから得られたスーパーフレーム時間長（Superframe duration）。
・ＤＥＶ２２０自身に設定されている、ＤＥＶが所望とする起動周期を示すＡＰＳＷａｋｅＢｅａｃｏｎＩｎｔｅｒｖａｌ（第１周期情報）。
【００５３】
次に、ステップＳ１６０２において、ＡＰＳＷａｋｅＢｅａｃｏｎＩｎｔｅｒｖａｌとスーパーフレーム時間長とを比較して、ＡＰＳＷａｋｅＢｅａｃｏｎＩｎｔｅｒｖａｌがスーパーフレーム時間長以上であるか否かを判定する。ＡＰＳＷａｋｅＢｅａｃｏｎＩｎｔｅｒｖａｌがスーパーフレーム時間長より小さい場合（ステップＳ１６０２でＮＯ）にはステップＳ１６０３へ進む。スーパーフレーム時間長より大きい又は等しい場合（ステップＳ１６０２でＹＥＳ）はステップＳ１６０４へ進む。
【００５４】
ステップＳ１６０３においては、ＣＴＡ  Ｒａｔｅ  Ｆａｃｔｏｒ＝０に設定する。そして処理を終了する。
【００５５】
一方、ステップＳ１６０４においては、ＡＴＰとＡＰＳＷａｋｅＢｅａｃｏｎＩｎｔｅｒｖａｌを比較して、ＡＴＰがＡＰＳＷａｋｅＢｅａｃｏｎＩｎｔｅｒｖａｌ以上であるか否かを判定する。ＡＴＰがＡＰＳＷａｋｅＢｅａｃｏｎＩｎｔｅｒｖａｌよりも小さい場合（ステップＳ１６０４でＮＯ）はステップＳ１６０５へ進む。つまり、ＷａｋｅＢｅａｃｏｎＩｎｔｅｒｖａｌが、ＡＴＰの値以下である場合はステップＳ１６０５へ進む。ＡＰＳＷａｋｅＢｅａｃｏｎＩｎｔｅｒｖａｌより大きい又は等しい場合（ステップＳ１６０４でＹＥＳ）はステップＳ１６０６へ進む。
【００５６】
ステップＳ１６０５では、ＡＴＰの値がＣＰＵ１１０のレジスタＸの値として書き込まれる。そして、ステップＳ１６０７へ進む。
【００５７】
一方、ステップＳ１６０６では、ＡＰＳＷａｋｅＢｅａｃｏｎＩｎｔｅｒｖａｌの値がレジスタＸの値として書き込まれる。そして、ステップＳ１６０７へ進む。
【００５８】
ステップＳ１６０７では、ＣＰＵ１１０のレジスタＸの値をスーパーフレーム時間長で除算し、その結果について基底数２の対数を取り、小数点以下を切り捨てる。そして、得られた値について２を底とする指数の冪乗を演算し、得られた値をＣＴＡ  Ｒａｔｅ  Ｆａｃｔｏｒとする。そして、処理を終了する。
【００５９】
（ＣＴＡ  Ｒａｔｅ  Ｆａｃｔｏｒの設定）
次に、図１６の手順を用いてＣＴＡ  Ｒａｔｅ  Ｆａｃｔｏｒを算出したＤＥＶ２２０がＰＮＣ２１０へＣＴＡ  Ｒａｔｅ  Ｆａｃｔｏｒを設定する処理について、図１７を参照して説明する。図１７は、ＤＥＶ２２０がＰＮＣ２１０へＣＴＡ  Ｒａｔｅ  Ｆａｃｔｏｒを設定するメッセージシーケンスチャート（ＭＳＣ）である。本実施形態ではＤＥＶ２２０がＰＮＣ２１０へアクセスするのにＭＣＴＡを用いる場合について例示的に示す。
【００６０】
Ｓ１７０１において、ＤＥＶ２２０は、ＭＣＴＡ  Ｒａｔｅ  Ｆａｃｔｏｒを決定する。この処理は、例えば、図１６のフローチャートで示される流れに沿って行われる。
【００６１】
Ｓ１７０２でＤＥＶ２２０はＣＴＡ  Ｒａｔｅ  Ｆａｃｔｏｒを送信するために、チャネル時間要求コマンドを送出して自分宛のＭＣＴＡ間隔をＰＮＣ２１０に要求する。Ｓ１７０２を受信したＰＮＣ２１０はＳ１７０３でＩｍｍ  ＡｃｋをＤＥＶ２２０へ返信する。このとき、Ｓ１７０２の要求を受け入れることができた場合は、Ｓ１７０４において、ＰＮＣ２１０はチャネル時間応答（Channel Time Resp.）のＲｅａｓｏｎ  Ｃｏｄｅを成功（Success）としてＤＥＶ２２０へ送信する。
【００６２】
ＰＮＣ２１０から、Ｒｅａｓｏｎ  Ｃｏｄｅが成功とされたチャネル時間応答を受信すると、ＤＥＶ２２０は、Ｓ１７０５においてＩｍｍ  ＡｃｋをＰＮＣ２１０へ返信する。Ｓ１７０５を受信したＰＮＣ２１０はＳ１７０６でＣＴＡ  Ｒａｔｅ  Ｆａｃｔｏｒに基づいてＭＣＴＡを配置する。つまり、ＣＴＡ  Ｒａｔｅ  Ｆａｃｔｏｒで示されるフレーム間隔にＭＣＴＡを配置する。このＭＣＴＡは、ＤＥＶ２２０が省電力モードであるときに通信を行うための期間に相当する。例えば、ＣＴＡ  Ｒａｔｅ  Ｆａｃｔｏｒ＝２の場合は、２フレーム毎にＭＣＴＡを配置するようにする。
【００６３】
そして、Ｓ１７０７において、ＰＮＣ２１０はＤＥＶ２２０がアクセスできるＭＣＴＡ情報を含んだビーコンフレームをＤＥＶ２２０へ送信する。このＭＣＴＡ情報には、フレーム中のどこにＭＣＴＡが配置されたかを示す情報が含まれる。従って、この処理は、割り当てられたＭＣＴＡをＤＥＶ２２０へ通知することに相当する。このビーコンフレームの受信に応じて、Ｓ１７０８でＤＥＶ２２０はこの場合には空のプローブ要求コマンドを送信する。そして、Ｓ１７０９でＰＮＣ２１０からＤＥＶ２２０へＩｍｍ  Ａｃｋが返信されることで通信状態が保たれる。
【００６４】
図１８は、ＭＣＴＡがＣＴＡ  Ｒａｔｅ  Ｆａｃｔｏｒに基づいて配置された例を示す模式図である。１８０１−１８０３はＭＣＴＡを示し、１８０４−１８０８はスーパーフレームを示す。このときのＣＴＡ  Ｒａｔｅ  Ｆａｃｔｏｒ＝２であり、従ってＭＣＴＡはスーパーフレーム１つおきに配置されている。
【００６５】
上記のように、本実施形態に係る構成においては、ＤＥＶ２２０が適切なＣＴＡ Ｒａｔｅ Ｆａｃｔｏｒを算出してＰＮＣ２１０に通知し、ＰＮＣ２１０は、当該ＣＴＡ Ｒａｔｅ Ｆａｃｔｏｒに基づいてアクセスタイミングを決定する。そして、ＤＥＶ２２０は、このアクセスタイミングにＰＮＣ２１０と通信するように通信制御する。このため、ＤＥＶ２２０は、所望とするタイミングで無駄なく通信でき、省電力化が可能である。また、ＰＮＣ２１０はＤＥＶ２２０に不要なアクセスタイミングを設定することが無いので、通信システム全体のスループットが向上することができる。
【００６６】
なお、本実施形態においてＤＥＶがＰＮＣへアクセスする時間割当にＭＣＴＡを使用したが、ＤＥＶ機能を持つＰＮＣの場合にはＭＣＴＡの替わりにＣＴＡを用いることができるのは言うまでも無い。
【００６７】
＜＜実施形態２＞＞
本実施形態で用いられる通信装置と通信システムの構成は、実施形態１と同様、それぞれ図１と図２に示される。本実施形態においては、ＣＴＡ  Ｒａｔｅ  Ｆａｃｔｏｒとして任意の値をＤＥＶ２２０が算出する。
【００６８】
（ＣＴＡ  Ｒａｔｅ  Ｆａｃｔｏｒの算出）
まず、ＣＴＡ  Ｒａｔｅ  Ｆａｃｔｏｒの算出手順について図１９を参照して説明する。図１９は、ＣＴＡ  Ｒａｔｅ  Ｆａｃｔｏｒを算出するときの処理手順を示すフローチャートである。なお、ＭＣＴＡ  Ｒａｔｅ  Ｆａｃｔｏｒを算出するときも同様の手順を適用することが可能である。
【００６９】
図１９では、図１５に示すようにＤＥＶ２２０がＡＰＳモードである事を前提とする。ステップＳ１６０１−Ｓ１６０６は実施形態１における図１６と同じ手順であるので説明を省略する。
【００７０】
図１９では、ステップＳ１６０５の処理を終了したとき、及び、ステップＳ１６０６の処理を終了したときに、ステップＳ１９０１へ進む点が図１６と相違する。Ｓ１９０１では、ＣＰＵ１１０のレジスタＸの値をスーパーフレーム時間長で除算し、その結果を切り捨てた値をＣＴＡ  Ｒａｔｅ  Ｆａｃｔｏｒとして算出する。そして、ステップＳ１９０１の処理を終えると、処理を終了する。
【００７１】
（ＣＴＡ  Ｒａｔｅ  Ｆａｃｔｏｒの設定）
図２０は、本実施形態において、ＤＥＶがＰＮＣへＣＴＡ  Ｒａｔｅ  Ｆａｃｔｏｒを設定するメッセージシーケンスチャートである。図２０において、図１９の手順を用いてＣＴＡ  Ｒａｔｅ  Ｆａｃｔｏｒを算出したＤＥＶ２２０がＰＮＣ２１０へＣＴＡ  Ｒａｔｅ  Ｆａｃｔｏｒを設定するＭＳＣを示す。本実施形態ではＤＥＶ２２０がＰＮＣ２１０へアクセスするのにＭＣＴＡを用いる場合について説明する。
【００７２】
まず、Ｓ２００１において、ＤＥＶ２２０は、ＭＣＴＡ  Ｒａｔｅ  Ｆａｃｔｏｒを決定する。Ｓ２００１の処理は、例えば、図１９のフローチャートで示される手順に基づいて行われる。ＭＣＴＡ  Ｒａｔｅ  Ｆａｃｔｏｒを決定すると、ＤＥＶ２２０は、Ｓ２００２でベンダースペシフィック要求コマンドを用いて、ＭＣＴＡ  Ｒａｔｅ  Ｆａｃｔｏｒを送信し、自分宛のＭＣＴＡ間隔を要求する。
【００７３】
Ｓ２００２を受信したＰＮＣ２１０は、Ｓ２００３でＩｍｍ  Ａｃｋを返信する。Ｓ２００２の要求を受け入れることができた場合、Ｓ２００４においてＰＮＣ２１０は、チャネル時間応答のＲｅａｓｏｎ  Ｃｏｄｅを成功として、ＤＥＶ２２０へベンダースペシフィック応答コマンドを用いて送信する。Ｓ２００５でＤＥＶ２２０は、チャネル時間応答の受信に応じて、Ｉｍｍ  ＡｃｋをＰＮＣ２１０へ返信する。
【００７４】
Ｓ２００５でＩｍｍ  ＡｃｋをＤＥＶ２２０から受信すると、ＰＮＣ２１０は、Ｓ２００６でＭＣＴＡ  Ｒａｔｅ  Ｆａｃｔｏｒに従ったＭＣＴＡを配置する。そして、Ｓ２００７でＰＮＣ２１０は、ＤＥＶ２２０がアクセスできるＭＣＴＡ情報を含んだビーコンフレームをＤＥＶ２２０へ送信する。
【００７５】
Ｓ２００８でＤＥＶ２２０はこの場合には空のプローブ要求コマンドをＰＮＣ２１０へ送信する。Ｓ２００９でＰＮＣ２１０からＤＥＶ２２０へＩｍｍ  Ａｃｋが返信されることで通信状態が保たれることになる。
【００７６】
上記のように、本実施形態に係る構成によれば、ＤＥＶ２２０は、２の冪乗に限られない適切な値（フレーム期間の自然数倍の期間）をＣＴＡ  Ｒａｔｅ  Ｆａｃｔｏｒとして決定することが可能となる。
【００７７】
本実施形態においてＤＥＶがＰＮＣへアクセスする時間割当にＭＣＴＡを使用したが、ＤＥＶ機能を持つＰＮＣの場合にはＭＣＴＡの替わりにＣＴＡを用いることができるのは言うまでも無い。
【００７８】
＜＜実施形態３＞＞
本実施形態で用いられる通信装置と通信システムの構成は、実施形態１および実施形態２と同様、それぞれ図１と図２に示される。本実施形態においては、ＤＥＶ２２０がＰＮＣ２１０へＣＴＡ  Ｒａｔｅ  Ｆａｃｔｏｒに任意の値を用いて設定する場合にＰＮＣ２１０に拒否された場合、ＤＥＶ２２０はＰＮＣ２１０へＣＴＡ  Ｒａｔｅ  Ｆａｃｔｏｒが２のべき乗値を用いて設定する。
【００７９】
本実施形態に係る構成が実行する処理手順について、図２１を参照して説明する。図２１は、ＤＥＶ２２０がＰＮＣ２１０へＣＴＡ  Ｒａｔｅ  Ｆａｃｔｏｒを設定するメッセージシーケンスチャートである。なお、本実施形態ではＤＥＶ２２０がＰＮＣ２１０へアクセスするのにＭＣＴＡを用いる場合について例示的に説明する。
【００８０】
図２１では、図１５に示す通りＤＥＶ２２０がＡＰＳモードである事を前提とする。ＣＴＡ  Ｒａｔｅ  Ｆａｃｔｏｒが２のべき乗で無い値の算出手順はＳ２１０１で行われ、図１９のフローチャートで示される通りである。Ｓ２１０２でＤＥＶ２２０はＣＴＡ  Ｒａｔｅ  Ｆａｃｔｏｒを送信するのにベンダースペシフィック要求コマンドを用いて自分宛のＭＣＴＡ間隔を要求する。
【００８１】
Ｓ２１０２を受信したＰＮＣ２１０はＳ２００３でＩｍｍ  Ａｃｋを返信する。Ｓ２１０２の要求を受け入れられない場合、Ｓ２１０４ではＰＮＣ２１０は、チャネル時間応答のＲｅａｓｏｎ  Ｃｏｄｅを失敗としてＤＥＶ２２０へベンダースペシフィック応答コマンドを用いて送信する。後に、Ｓ１７０１−Ｓ１７０９までのステップは図１７と同様なので説明を省略する。
【００８２】
上記のように、本実施形態に係る構成においては、ＰＮＣ２１０は、ＤＥＶ２２０からＭＣＴＡ  Ｒａｔｅ  Ｆａｃｔｏｒを受信すると、ＭＣＴＡを割り当てるために通知された値を用いるか否かを判定する。そして、用いないと判定した場合は、受信したＭＣＴＡ  Ｒａｔｅ  Ｆａｃｔｏｒを用いない旨をＤＥＶ２２０へ送信する。ＭＣＴＡ  Ｒａｔｅ  Ｆａｃｔｏｒを用いない旨をＰＮＣ２１０から受信すると、ＤＥＶ２２０は、ＭＣＴＡ  Ｒａｔｅ  Ｆａｃｔｏｒとしてスーパーフレーム期間の２の冪乗倍の期間を決定し、ＰＮＣ２１０へ送出する。このため、本実施形態に係る構成によれば、ＭＣＴＡの間隔をスーパーフレーム期間の２の冪乗倍とすることが可能である。
【００８３】
なお、本実施形態においてＤＥＶがＰＮＣへアクセスする時間割当にＭＣＴＡを使用したが、ＤＥＶ機能を持つＰＮＣの場合にはＭＣＴＡの替わりにＣＴＡを用いることができるのは言うまでも無い。
【００８４】
＜＜その他の実施形態＞＞
上記の実施形態では、ＤＥＶ２２０側で、ＣＴＡ  Ｒａｔｅ  Ｆａｃｔｏｒを決定する構成を説明したが、図２２、２３に示すように、用途や目的に応じてＰＮＣ２１０側で決定してもよいことはいうまでもない。図２２、２３は、ＰＮＣ２１０側でＭＣＴＡ  Ｒａｔｅ  Ｆａｃｔｏｒを決定した場合における、ＣＴＡ  Ｒａｔｅ  Ｆａｃｔｏｒを設定するメッセージシーケンスチャートである。
【００８５】
以上、本発明の実施形態例について詳述したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記憶媒体等としての実施態様を取ることが可能である。具体的には、複数の機器から構成されるシステムに適用してもよいし、また、一つの機器からなる装置に適用してもよい。
【００８６】
尚、本発明は、前述した実施形態の機能を実現するプログラムを、システムあるいは装置に直接あるいは遠隔から供給し、そのシステムあるいは装置のコンピュータが該供給されたプログラムコードを読み出して実行することによっても達成される場合を含む。
【００８７】
従って、本発明の機能処理をコンピュータで実現するために、該コンピュータにインストールされるプログラムコード自体も本発明の技術的範囲に含まれる。つまり、本発明は、本発明の機能処理を実現するためのコンピュータプログラム自体も含む。
【００８８】
その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等の形態であってもよい。
【００８９】
プログラムを供給するための記録媒体としては、例えば、次のものが含まれる。即ち、フロッピー（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ）等が含まれる。
【００９０】
その他、プログラムの供給形態としては、次のようなものも考えられる。即ち、クライアント装置のブラウザを用いてインターネットのホームページに接続し、該ホームページから本発明に係るコンピュータプログラム、或いは、圧縮され自動インストール機能を含むファイルをＨＤ等の記録媒体にダウンロードする形態も考えられる。また、本発明に係るプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明に含まれるものである。
【００９１】
また、次のような供給形態も考えられる。即ち、まず、本発明に係るプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布する。そして、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせ、その鍵情報の使用により暗号化されたプログラムを実行してコンピュータにインストールさせて本発明に係る構成を実現する。このような供給形態も可能である。
【００９２】
また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される他、次のような実現形態も想定される。即ち、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部または全部を行ない、その処理によっても前述した実施形態の機能が実現され得る。
【００９３】
さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムの指示に基づいても前述した実施形態の機能が実現される。即ち、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によっても前述した実施形態の機能が実現される。
【図面の簡単な説明】
【００９４】
【図１】通信装置のハードウェア構成を模式的に示したブロック図である。
【図２】通信システムの構成を模式的に示す図である。
【図３】IEEE802.15.3規格のフレーム構成を模式的に示す図である。
【図４】ＭＡＣヘッダの構成を示す模式図である。
【図５】フレームコントロールフィールドのフィールド構成を示す模式図である。
【図６】ＭＡＣフレームボディの構成を示す模式図である。
【図７】非暗号化ビーコンフレームボディのフォーマットを示す模式図である。
【図８】ピコネット同期パラメータフィールドの構成を示す模式図である。
【図９】ピコネットモードフィールドのフォーマットを示す模式図である。
【図１０】ＰＮＣレスポンスフィールドのフィールド構成を示す模式図である。
【図１１】ＩＥフィールドのフォーマットを示す模式図である。
【図１２】非暗号化コマンドフレームのフォーマットを示す模式図である。
【図１３】コマンドブロックのフォーマットを示す模式図である。
【図１４】アソシエーションするときのメッセージのシーケンスを示すメッセージシーケンスチャートである。
【図１５】ＤＥＶがＡＰＳモードに移行するときのメッセージシーケンスチャートである。
【図１６】ＣＴＡ  Ｒａｔｅ  Ｆａｃｔｏｒを算出するときの処理手順を示すフローチャートである。
【図１７】ＤＥＶがＰＮＣへＣＴＡ  Ｒａｔｅ  Ｆａｃｔｏｒを設定するメッセージシーケンスチャートである。
【図１８】ＭＣＴＡがＣＴＡ  Ｒａｔｅ  Ｆａｃｔｏｒに基づいて配置された例を示す模式図である。
【図１９】ＣＴＡ  Ｒａｔｅ  Ｆａｃｔｏｒを算出するときの処理手順を示すフローチャートである。
【図２０】ＤＥＶがＰＮＣへＣＴＡ  Ｒａｔｅ  Ｆａｃｔｏｒを設定するメッセージシーケンスチャートである。
【図２１】ＤＥＶがＰＮＣへＣＴＡ  Ｒａｔｅ  Ｆａｃｔｏｒを設定するメッセージシーケンスチャートである。
【図２２】、
【図２３】ＰＮＣ側でＭＣＴＡ  Ｒａｔｅ  Ｆａｃｔｏｒを決定した場合における、ＣＴＡ  Ｒａｔｅ  Ｆａｃｔｏｒを設定するメッセージシーケンスチャートである。
【図２４】フレームタイプフィールドの値とフレームタイプとの関係を示す図である。
【図２５】ＡＣＫポリシーフィールドの値とタイプとの関係を示す図である。
【図２６】エレメントＩＤフィールドの値とタイプの関係とを示す図である。
【図２７】コマンドタイプフィールドの値と、そのタイプとの関係を示す図である。
【図１】
2008187289.tif 000003
【図２】
2008187289.tif 000004
【図３】
2008187289.tif 000005
【図４】
2008187289.tif 000006
【図５】
2008187289.tif 000007
【図６】
2008187289.tif 000008
【図７】
2008187289.tif 000009
【図８】
2008187289.tif 000010
【図９】
2008187289.tif 000011
【図１０】
2008187289.tif 000012
【図１１】
2008187289.tif 000013
【図１２】
2008187289.tif 000014
【図１３】
2008187289.tif 000015
【図１４】
2008187289.tif 000016
【図１５】
2008187289.tif 000017
【図１６】
2008187289.tif 000018
【図１７】
2008187289.tif 000019
【図１８】
2008187289.tif 000020
【図１９】
2008187289.tif 000021
【図２０】
2008187289.tif 000022
【図２１】
2008187289.tif 000023
【図２２】
2008187289.tif 000024
【図２３】
2008187289.tif 000025
【図２４】
2008187289.tif 000026
【図２５】
2008187289.tif 000027
【図２６】
2008187289.tif 000028
【図２７】
2008187289.tif 000029