JP2007510350A - 無線ｐａｎ上でデバイス間に効率的にデータを送受信する方法 - Google Patents

Abstract

本発明は、無線ＰＡＮ（ワイヤレスパーソナルエリアネットワーク）上で動作するデバイスのＭＡＣを改善することによって、割り当てられたチャンネル時間の間に双方向にデータを送受信する方法及び装置に関する。本発明のデータ送受信方法は、（ａ）データ送信方向が単方向であるか双方向であるかを決定する方向情報を含むチャンネル時間要請フレームを生成して、チャンネル時間の割り当てを担当するデバイスに伝送するステップと、（ｂ）チャンネル時間要請フレームに存在する情報を利用して方向情報が含まれたチャンネル時間の割り当て情報を持つフレームを生成し、生成されたフレームをブロードキャストするステップと、（ｃ）ビーコンフレームでソースデバイスと指定された第１デバイスと、目的地デバイスと指定された第２デバイスとの間に、所定のチャンネル時間の間に方向情報に合わせてデータを送受信するステップと、を含む。

Description

本発明は、無線ネットワークでデバイス間に効率的に通信する方法及び装置に係り、より詳細には、無線ＰＡＮ（ワイヤレスパーソナルエリアネットワーク）上で動作するデバイスのＭＡＣ（メディアアクセスコントロール）を改善することによって、割り当てられたチャンネル時間の間に双方向にデータを送受信する方法及び装置に関する。

無線デジタルパルスとも知られているＵＷＢ（ウルトラワイドバンド）は、短距離区間で低電力で広いスペクトル周波数を通じて多量のデジタルデータを伝送するための無線技術であり、米国国防部が軍事的目的で開発した無線技術である。このようなＵＷＢに関する標準化は、現在ＩＥＥＥ ８０２．１５．３、すなわち、無線ＰＡＮ規格制定のためのワーキンググループで進行しつつある。ＩＥＥＥ ８０２．１５．３にはＰＨＹ及びＭＡＣに関して取り扱われているが、現在業界ではこのうちでもＭＡＣの改善方案についての活発な研究を進めている。

８０２．１５．３ＭＡＣの特徴は、無線ネットワークの形成が迅速であるということである。そして、ＡＰ（アクセスポイント）基盤ではなく、ＰＮＣ（Ｐｉｃｏｎｅｔ Ｃｏｏｒｄｉｎａｔｏｒ）を中心としたピコネットというアドホックネットワークを基盤とする。８０２．１５．３ＭＡＣは、ＴＤＭＡ（時分割多重接続；タイムディビジョンマルチプルアクセス）方式を採択している。図１のようなスーパーフレームという時間的な配置構造中に、デバイス間のデータ送受信のためのＭＡＣフレームを配置する。スーパーフレームの構成では、制御情報を含めているビーコン及びバックオフを通じてデータを伝送するＣＡＰ（Ｃｏｎｔｅｎｔｉｏｎ Ａｃｃｅｓｓ Ｐｅｒｉｏｄ）区間、そして、割り当てられた時間に競合なしにデータを送るＣＴＡＰ（Ｃｈａｎｎｅｌ Ｔｉｍｅ Ａｌｌｏｃａｔｉｏｎ Ｐｅｒｉｏｄ）区間がある。このうち、ＣＡＰは、ＭＣＴＡ（Ｍａｎａｇｅｍｅｎｔ ＣＴＡ）に代替されて使われてもよい。この時、ＣＡＰ区間には、ＣＳＭＡ／ＣＡ（Ｃａｒｒｉｅｒ Ｓｅｎｓｅ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ／Ｃｏｌｌｉｓｉｏｎ Ａｖｏｉｄａｎｃｅ）方式を使用して競争的接近がなされ、ＭＣＴＡでは、Ｓｌｏｔｔｅｄ Ａｌｏｈａを利用してチャンネルをアクセスできる。

ＣＴＡＰは、複数のＭＣＴＡ及び複数のＣＴＡブロックで構成できる。ＣＴＡ（Ｃｈａｎｎｅｌ Ｔｉｍｅ Ａｌｌｏｃａｔｉｏｎ；チャンネル時間の割り当て）の種類には、動的ＣＴＡ（Ｄｙｎａｍｉｃ ＣＴＡ）と擬似静的ＣＴＡ（Ｐｓｅｕｄｏ ｓｔａｔｉｃ ＣＴＡ）の２種がある。動的ＣＴＡは、スーパーフレームごとにその位置が変わり、ビーコンをのがせば該当スーパーフレームでＣＴＡを使用できない。これに対し、擬似静的ＣＴＡは位置が変わらずに同じ位置に固定されており、ビーコンまたはスーパーフレームをのがしても固定された位置でＣＴＡ区間を使用できる。しかし、擬似静的ＣＴＡも、ｍＭａｘＬｏｓｔＢｅａｃｏｎｓに該当する回数以上連続してビーコンをのがせば使用不可にしている。このように、８０２．１５．３ＭＡＣは、ＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）を保証できるＴＤＭＡ基盤に構成されていて、特にホームネットワーク上でのマルチメディアオーディオ／ビデオストリーミング（Ａ／Ｖ Ｓｔｒｅａｍｉｎｇ）に適している。しかし、ＭＡＣにおいて、ＱｏＳだけでなくスループットを効果的に使用するためには、依然として改善の余地がある。

８０２．１５．３ＭＡＣでは、データ伝送方式に２種がある。一つは、等時的データ（ｉｓｏｃｈｒｏｎｏｕｓ ｄａｔａ）を伝送する方式であり、他の一つは、非同期式データ（ａｓｙｎｃｈｒｏｎｏｕｓ ｄａｔａ）を伝送する方式である。

等時的データを伝送するためには、図２に示すように、ＭＬＭＥ−ＣＲＥＡＴＥ−ＳＴＲＥＡＭ．ｒｅｑｕｅｓｔ及びＭＬＭＥ−ＣＲＥＡＴＥ−ＳＴＲＥＡＭ．ｃｏｎｆｉｒｍを利用して、まずＰＮＣからチャンネル時間を割り当てられた後、ＭＡＣ−ＩＳＯＣＨ−ＤＡＴＡ．ｒｅｑｕｅｓｔ及びＭＡＣ−ＩＳＯＣＨ−ＤＡＴＡ．ｃｏｎｆｉｒｍを利用して、前記割り当てられたチャンネル時間の間に実際にデータを伝送する。割り当てられたチャンネル時間はビーコンを解釈することによって分かり、この情報を利用してピコネットを構成するデバイス（以下、‘ＤＥＶ’という）は、通信の開始及び終了時間がわかる。この時、割り当てられたチャンネル時間には、ｓｒｃ ＤＥＶ（ソースデバイス）及びｄｅｓｔ ＤＥＶ（目的地デバイス）が指定されている。割り当てられたチャンネル時間にデータを送信するＤＥＶは必ずｓｒｃ ＤＥＶでなければならないが、データを受信するＤＥＶは必ずしもＣＴＡ情報で指定したｄｅｓｔ ＤＥＶである必要はない。ただし、前記データを受信できるＤＥＶは、‘Ａｌｗａｙｓ ＡＷＡＫＥ ｂｉｔ’または‘ｌｉｓｔｅｎ ｔｏ ｓｏｕｒｃｅ ｂｉｔ’が１にセットされているＤＥＶのみである。

一方、非同期式データを伝送するためには図３に示すように、送信するデータがＭＡＣ−ＡＳＹＮＣ−ＤＡＴＡ．ｒｅｑｕｅｓｔを通じてＭＡＣ層に到着すれば、ｓｒｃ ＤＥＶは、ＰＮＣにチャネルタイムリクエストコマンドフレームを送る。以後、ｓｒｃ ＤＥＶが要請したチャンネル時間が割り当てられたということをビーコンを通じて分かれば、そのチャンネル時間の間にデータを送信する。前記等時的データ伝送の場合と同じく、割り当てられたチャンネル時間についてはｓｒｃ ＤＥＶ及びｄｅｓｔ ＤＥＶ対が指定されており、割り当てられたチャンネル時間の間には指定されたｓｒｃ ＤＥＶのみデータを送信できる。それ以外に、非同期式データを送るさらに他の方法には、ＣＡＰ（Ｃｏｎｔｅｎｔｉｏｎ Ａｃｃｅｓｓ Ｐｅｒｉｏｄ）でバックオフアルゴリズムを利用してフレームを送る方法もある。

ＴＣＰ／ＩＰの場合、データ伝送の確実性を保証するためにＤＥＶ１からフレームを伝送すれば、ＤＥＶ２からは、伝送されたフレームに対するＡＣＫフレーム（図２、図３でのＩｍｍ−ＡＣＫフレームとは異なってＴＣＰ／ＩＰレベルのＡＣＫフレームを意味する）を送る。このようなメカニズムを持つＴＣＰ／ＩＰに、８０２．１５．３ＭＡＣで提供されるデータ伝送メカニズムをそのまま使用する場合に発生する問題点を具体的に説明すれば、次の通りである。

第１に、等時的にＴＣＰ／ＩＰデータを伝送する場合を説明すれば、まずＤＥＶ１は、ＤＥＶ２との連結を確立するためのフレームを送る。そのために、まずＰＮＣにＭＬＭＥ−ＣＲＥＡＴＥ−ＳＴＲＥＡＭ．ｒｅｑｕｅｓｔを送ることによって、ｓｒｃ ＤＥＶがＤＥＶ１、ｄｅｓｔ ＤＥＶがＤＥＶ２であるチャンネル時間の割り当てを要請する。ＰＮＣがチャンネル時間を割り当ててその情報をビーコンに載せて送れば、ＤＥＶ１は、ビーコン情報を読み取って指定された時間に前記フレームをＤＥＶ２に伝送する。ＤＥＶ２は、それに対する応答フレームを送るために、ｓｒｃ ＤＥＶがＤＥＶ２であり、ｄｅｓｔ ＤＥＶがＤＥＶ１であるチャンネル時間の割り当てを要請する。そして、同様に、ＰＮＣがチャンネル時間を割り当ててこれに関する情報をビーコンに載せて送れば、ＤＥＶ２は、ビーコン情報を読み取って指定された時間に前記応答フレームをＤＥＶ１に伝送する。ＭＬＭＥ−ＴＥＲＭＩＮＡＴＥ−ＳＴＲＥＡＭ．ｒｅｑｕｅｓｔを伝達されるまではチャンネル時間が割り当てられ続けるために、その次からは、ＤＥＶ１とＤＥＶ２とが互いに送受信するデータ及びＡＣＫフレームは、ビーコンのチャンネル時間情報によってｓｒｃ ＤＥＶ及びｄｅｓｔ ＤＥＶ対に割り当てられた時間に送られる。しかし、ＴＣＰ／ＩＰの特性上、送信者（ｓｅｎｄｅｒ）はデータフレームを送った後、ＡＣＫフレームを受けるまでは他のフレームを伝送しない。ところが、８０２．１５．３ＭＡＣでは、ビーコンで知らせるチャンネル時間の割り当てのｓｒｃ ＤＥＶのみがそのチャンネル時間の送信者になりうる。したがって、ＤＥＶ２がＴＣＰ／ＩＰレベルのＡＣＫフレームを送るためには、ｓｒｃ ＤＥＶがＤＥＶ２であるチャンネル時間になるまで待っててＡＣＫフレームを送らねばならない。結局、ＤＥＶ１がデータを送った後にＤＥＶ１及びＤＥＶ２に割り当てられた時間が残るとしても、ＤＥＶ１はその残った時間を利用してＤＥＶ２からＡＣＫを受けることはできないので、チャンネル時間の無駄遣いが発生する。

第２に、非同期式にＴＣＰ／ＩＰフレームを伝送する場合を説明する。まず、ＣＡＰに非同期式データを送る場合を見れば、ＰＮＣがＣＡＰをスーパーフレームに割り当ててもよく、割り当てなくてもよい。それだけでなく、もし割り当てられたＣＡＰがあるとしても、ＰＮＣが設定した基準によってその区間の間に非同期式データを送れるかどうかが決定されるために、ＣＡＰを利用してＴＣＰ／ＩＰフレームを送る方法では確実な伝送を保証できない。次いで、チャンネル時間の割り当てを利用して非同期式データを送るためには、前記のようにＭＡＣ−ＡＳＹＮＣＨ−ＤＡＴＡ．ｒｅｑｕｅｓｔを利用する。

しかし、図２及び図３に示すように、毎度チャネルタイムリクエストコマンドをＰＮＣに送ってチャンネル時間を割り当てられた後にデータフレームを伝送せねばならないので、データを伝達し続けるべきことならば帯域幅の無駄遣いになってしまう。また、チャンネル時間の割り当てを要請したしても要請した時間がいつ割り当てられるかは保証されず、一度データフレームを送るたびに最小次のスーパーフレームまで待たねばならないので、時間遅延が毎度発生してしまう。

前記の問題点はＴＣＰ／ＩＰでだけでなく、二つのＤＥＶが互いにデータを送受信するプロトコルが８０２．１５．３ＭＡＣの上位層で駆動される場合ならば、同様に発生できる。

したがって、本発明は前記した問題点に鑑みてなされたものであり、８０２．１５．３ＭＡＣを改善して上位プロトコルでの通信が効率的になされるようにすることを目的とする。そのために、８０２．１５．３でＣＴＡを単方向伝送ではない双方向伝送に使用する方法を提供しようとする。

前記した目的を達成するために、本発明による無線ＰＡＮ上でデバイス間にデータを送受信する方法は、データ送信方向が単方向であるか双方向であるかを決定する方向情報を含むチャンネル時間要請フレームを生成して、チャンネル時間の割り当てを担当するデバイスに伝送する第１ステップと、前記チャンネル時間要請フレームに存在する情報を利用して前記方向情報が含まれたチャンネル時間の割り当て情報を持つフレームを生成し、前記生成されたフレームをブロードキャストする第２ステップと、前記ビーコンフレームでソースデバイスと指定された第１デバイスと、目的地デバイスと指定された第２デバイスとの間に、所定のチャンネル時間の間に前記方向情報に合わせてデータを送受信する第３ステップと、を含むことを特徴とする。

前記チャンネル時間要請フレームは、ＩＥＥＥ ８０２．１５．３で規定するチャネルタイムリクエストコマンドフレームであることが望ましい。

また、前記チャンネル時間の割り当てを担当するデバイスは、ＩＥＥＥ ８０２．１５．３で規定するピコネットコーディネーター（ＰＮＣ）であることが望ましい。

また、前記チャンネル時間の割り当て情報を持つフレームは、ＩＥＥＥ ８０２．１５．３で規定するビーコンフレームであることが望ましい。

前記第３ステップは、前記第１デバイスが前記第２デバイスにデータを伝送するステップと、前記データ伝送結果、前記第１デバイスがこれ以上伝送するデータがなければ前記第２デバイスにＮＵＬＬフレームを伝送するステップと、を含むことが望ましい。

前記無線ＰＡＮ上でデバイス間にデータを送受信する方法は、前記ＮＵＬＬフレームを受信した第２デバイスが前記第１デバイスに伝送するデータがあれば、データを伝送し、伝送するデータがなければ、前記第１デバイスが伝送したデータについての確認フレームを伝送するステップをさらに含むことが望ましい。

前記無線ＰＡＮ上でデバイス間にデータを送受信する方法は、前記確認フレームを受信した第１デバイスが前記第２デバイスに伝送するデータがあれば、データを伝送し、伝送するデータがなければ、前記第２デバイスにＮＵＬＬフレームを伝送するステップをさらに含むことが望ましい。

そして、前記確認フレームは、ＭＡＣ層でのＩｍｍｅｄｉａｔｅ ＡＣＫフレームであることが望ましい。また、前記ＮＵＬＬフレームは、ＭＡＣヘッダのみで構成されることが望ましい。

以下、添付された図面を参照して本発明の望ましい一実施形態を詳細に説明する。

二つのＤＥＶが送信側と受信側とに役割が固定されず、動的に送信側と受信側との役割を取り替えられるチャンネル時間区間を追加し、ＴＣＰ／ＩＰのように二つのＤＥＶが互いにデータを送受信すべきプロトコルがＭＡＣ層の上位で駆動される場合に、前記チャンネル時間をＰＮＣに要請する。前記ＰＮＣは、ピコネット内のＤＥＶに各種サービスを提供するデバイスであるが、無線通信媒体を利用してチャンネル時間を割り当て、ＤＥＶ間に同期化を行い、ＤＥＶをピコネットに加入させるアソシエーション機能などを行う。

前記相互データ送受信のためには、まず８０２．１５．３ＭＡＣで提供するＭＬＭＥ−ＣＲＥＡＴＥ−ＳＴＲＥＡＭ．ｒｅｑｕｅｓｔのパラメータを修正する必要がある。次の（表１）では、既存のパラメータに‘ＤｉｒｅｃｔｉｏｎＴｙｐｅ’というパラメータを追加して、修正されたＭＬＭＥ−ＣＲＥＡＴＥ−ＳＴＲＥＡＭ．ｒｅｑｕｅｓｔのパラメータを示した。ＤｉｒｅｃｔｉｏｎＴｙｐｅは、データ送信方向が単方向であるか、または双方向であるかを決定する方向情報を意味する。

前記ＤｉｒｅｃｔｉｏｎＴｙｐｅパラメータはね次の（表２）のように定義される。

ＤＥＶ１がＤＥＶ２にＴＣＰ／ＩＰプロトコルを利用してデータを送ると仮定しよう。ＤＥＶ１は、ＰＮＣにチャンネル時間を要請するために、まずＭＬＭＥ−ＣＲＥＡＴＥ−ＳＴＲＥＡＭ．ｒｅｑｕｅｓｔを呼び出す。この時、ＤｉｒｅｃｔｉｏｎＴｙｐｅはＴＷＯ＿ＷＡＹと設定する。ＤＥＶ１のＭＬＭＥがＭＬＭＥ−ＣＲＥＡＴＥ−ＳＴＲＥＡＭ．ｒｅｑｕｅｓｔを受ければ、ＰＮＣに図４のようなチャネルタイムリクエストコマンド１００を送る。この時、チャネルタイムリクエストコマンド１００を構成するｃｈａｎｎｅｌ ｔｉｍｅ ｒｅｑｕｅｓｔ ｂｌｏｃｋ １１０には、前記（表１）のように‘ＤｉｒｅｃｔｉｏｎＴｙｐｅ’を定義するビットフィールドが追加される。前記‘ＤｉｒｅｃｔｉｏｎＴｙｐｅ’フィールドは１ｏｃｔｅｔが割り当てられているが、ＯＮＥ＿ＷＡＹである場合には‘０’を持ち、ＴＷＯ＿ＷＡＹである場合には‘１’を持つので、１ビット情報で十分であるので実際に１ビットのみ使用し、残りの７ビットはｒｅｓｅｒｖｅｄと残されている。

ＰＮＣがチャネルタイムリクエストコマンド１００を受けた後、通信媒体のリソースが十分な場合には、前記チャンネル時間をビーコンを通じて該当ＤＥＶに割り当てる。図５では、ビーコンフレーム２００の構造、ビーコンフレームが持つ一つ以上の‘Ｉｎｆｏｒｍａｔｉｏｎｅｌｅｍｅｎｔ’フィールドのうち‘ｃｈａｎｎｅｌ ｔｉｍｅ ａｌｌｏｃａｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎ ｅｌｅｍｅｎｔ’フィールド２１０の構造、そして、前記‘ｃｈａｎｎｅｌ ｔｉｍｅ ａｌｌｏｃａｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎ ｅｌｅｍｅｎｔ’フィールド２１０に存在する一つ以上の‘チャネルタイムアロケーションブロック’フィールド２１１の構造を示した。前記チャネルタイムアロケーションブロックフィールド２１１の構造は、受信側ＤＥＶのＩＤを表すＤｅｓｔＩＤフィールド、送信側ＤＥＶのＩＤを表すＳｒｃＩＤフィールド、データ伝送方向がＯＮＥ＿ＷＡＹであるか、またはＴＷＯ＿ＷＡＹであるかを示す本発明で定義したＤｉｒｅｃｔｉｏｎＴｙｐｅフィールド、伝送するデータストリームの同一性を表すＳｔｒｅａｍ ｉｎｄｅｘフィールド、スーパーフレームでＣＴＡの位置を表すＣＴＡ ｌｏｃａｔｉｏｎフィールド、そして、ＣＴＡの持続時間を表すＣＴＡ ｄｕｒａｔｉｏｎフィールドで構成される。

ＤｉｒｅｃｔｉｏｎＴｙｐｅがＯＮＥ＿ＷＡＹであるチャンネル時間の間にはＳｒｃＩＤと指定された、すなわち、チャネルタイムリクエストコマンド１００を送ったＤＥＶのみが送信者になりうる。これは、既存の８０２．１５．３と同様である。もし、ＤｉｒｅｃｔｉｏｎＴｙｐｅがＴＷＯ＿ＷＡＹであるチャンネル時間が割り当てられれば、その時間の間にはＳｒｃＩＤとＤｅｓｔＩＤと指定された二つのＤＥＶいずれも送信者となって、相手側ＤＥＶに所望のデータを伝送できる。ビーコンには、チャネルタイムリクエストコマンド１００を送ったＤＥＶ１がＳｒｃＩＤであり、ＤＥＶ２がＤｅｓｔＩＤと指定されたチャネルタイムアロケーションブロック２１１が含まれているが、ビーコン情報によってまずＳｒｃＩＤと指定されたＤＥＶ１がまず送信者となる。

以下、図６ないし図９は、本発明の第１実施形態を説明する図面であり、図１０ないし図１３は、本発明の第２実施形態を説明する図面である。

第１実施形態は、送信者がこれ以上送るデータがない時には‘ＮＵＬＬフレーム’を伝送し、これにより受信者側からはデータを伝送でき、受信者がＮＵＬＬフレームを受けても伝送するデータがなければ、再びＩｍｍ−ＡＣＫ（Ｉｍｍｅｄｉａｔｅ ＡＣＫ）を伝送して再びデータ伝送機会を送信者側に渡す方式である。したがって、第１実施形態によれば、ＮＵＬＬフレームの‘ＡＣＫ ｐｏｌｉｃｙ’はＩｍｍ−ＡＣＫになる。

一方、第２実施形態は、送信者がこれ以上送るデータがない時には‘ＴＯＫＥＮフレーム’を伝送し、これにより、受信者側からはデータを伝送でき、受信者がＴＯＫＥＮフレームを受けても伝送するデータがなければ、再びＴＯＫＥＮフレームを伝送して再びデータ伝送機会を送信者側に渡す方式である。したがって、第２実施形態によれば、ＴＯＫＥＮフレームの‘ＡＣＫ ｐｏｌｉｃｙ’はＮｏ−ＡＣＫとなる。以下、図６ないし図９を参照して本発明による第１実施形態を説明する。

図６は、ＤｉｒｅｃｔｉｏｎＴｙｐｅがＴＷＯ＿ＷＡＹであるチャンネル時間を割り当てられた時、そのチャンネル時間にＤＥＶ１とＤＥＶ２とがデータを送受信する過程を示すものである。チャネルタイムリクエストコマンド１００を送ったＤＥＶ１がＳｒｃＩＤと、ＤＥＶ２がＤｅｓｔＩＤと指定されたチャネルタイムアロケーションブロック２１１をビーコンから受けた後、指定された時間になれば、ＤＥＶ１がまず送信者となってＤＥＶ２にデータを伝送する（Ｓ１０）。ＤＥＶ２は、ＤＥＶ１から受けたデータフレームのＡＣＫ ｐｏｌｉｃｙに合わせてＡＣＫフレームを送る。本例では、Ｉｍｍ−ＡＣＫ（Ｉｍｍｅｄｉａｔｅ ＡＣＫ）ｐｏｌｉｃｙを仮定する（Ｓ２０）。現状態でＤＥＶ１がこれ以上送るデータがなければ、ＤＥＶ２にＮＵＬＬフレームを伝送する（Ｓ３０）。前記ＮＵＬＬフレームは、ＭＡＣヘッダ部分のみ存在してフレームボディ部分は存在していないフレームであって、その構造は図７に示す通りである。もし、前記Ｓ３０ステップで送るフレームがあったとすれば、ＮＵＬＬフレームではなく直ちにデータフレームを送るはずである。ＮＵＬＬフレームを受けた時点で、ＤＥＶ２が現在送るデータがなければ直ちにＩｍｍ−ＡＣＫを伝送する（Ｓ４０）。ＤＥＶ１は、自身が送ったＮＵＬＬフレームに対してＩｍｍ−ＡＣＫを受けた後、ＤＥＶ２に送るデータがあればそれを伝送し、送るデータがなければ再びＮＵＬＬフレームを伝送する（Ｓ５０）。ＤＥＶ２が再びＮＵＬＬフレームを受けてその時点にＤＥＶ１に送るデータが準備されたならば、今度はＩｍｍ−ＡＣＫフレームではなくデータフレームをＤＥＶ１に伝送する（Ｓ６０）。ＤＥＶ１は、自身が送ったＮＵＬＬフレームに対してＩｍｍ−ＡＣＫではないデータフレームを受けたので、これに対するＩｍｍ−ＡＣＫをＤＥＶ２に送る（Ｓ７０）。Ｉｍｍ−ＡＣＫを受けたＤＥＶ２は、さらに送るデータがあればＤＥＶ１にそれらを伝送し続け、そうでなければ、ＮＵＬＬフレームをＤＥＶ１に送る（Ｓ８０）。ＤＥＶ１がその時点で送るデータがなければＩｍｍ−ＡＣＫをＤＥＶ２に伝送する（Ｓ９０）。このような過程が二つのＤＥＶに割り当てられたチャンネル時間が終わるまで反復される。

図７は、本発明で提案する前記‘ＮＵＬＬフレーム’の構造を詳細に示すものである。ＮＵＬＬフレームは、ＭＡＣヘッダのみ存在してフレームボディは存在していないフレームであって、従来のＭＡＣヘッダのように１０ｏｃｔｅｔｓの大きさを持ち、それぞれのフィールドは１ｏｃｔｅｔの大きさを持つ。ここで、Ｆｒａｍｅ ｔｙｐｅ フィールド７１０は、ＮＵＬＬフレームのｔｙｐｅ ｖａｌｕｅを記録する所である。各種フィールドフレームのｔｙｐｅ ｖａｌｕｅを定義したテーブルが図８に示されている。このようなｔｙｐｅ ｖａｌｕｅはＭＡＣヘッダのｂ５、ｂ４及びｂ３ビットに記録されるが、各ビットの組み合わせによって該当フレームがいかなるフレームであるかを知らせる。例えば、‘０００’はビーコンフレームを意味し、‘００１’はＩｍｍ−ＡＣＫフレームを意味する。既存のＩＥＥＥ ８０２．１５．３では、それ以外にもＤｅｌａｙｅｄ ＡＣＫフレーム（ｖａｌｕｅ＝‘０１０’）、ｃｏｍｍａｎｄフレーム（ｖａｌｕｅ＝‘０１１’）、データフレーム（ｖａｌｕｅ＝‘１００’）などのｔｙｐｅ ｖａｌｕｅが規定されている。本発明では、前記ｔｙｐｅ ｖａｌｕｅなどと合わせて、ＮＵＬＬフレームのｔｙｐｅ ｖａｌｕｅを新たに追加し、これを‘１０１’と規定した。

再び図７を参照すれば、ＡＣＫ ｐｏｌｉｃｙフィールド７２０にはＡＣＫ ｐｏｌｉｃｙによるＡＣＫフレームのｔｙｐｅ ｖａｌｕｅを記録する。前記ＡＣＫフレームのｔｙｐｅ ｖａｌｕｅは、ＩＥＥＥ ８０２．１５．３によれば、ＭＡＣヘッダのｂ８、ｂ７ビットに記録されるが、Ｎｏ ＡＣＫは‘００’、Ｉｍｍｅｄｉａｔｅ ＡＣＫは‘０１’、Ｄｅｌａｙｅｄ ＡＣＫは‘１０’の値を持つ。したがって、本実施形態によるＡＣＫ ｐｏｌｉｃｙフィールドは‘０１’値を持つ。そして、ＤｅｓｔＩＤフィールド７３０には該当ＮＵＬＬフレームを送信するＤＥＶのＩＤを記録し、ＳｒｃＩＤフィールド７４０には該当ＮＵＬＬフレームを受信するＤＥＶのＩＤを記録する。それ以外のＭＡＣヘッダのフィールド値はいずれも‘０’とする。

図９は、本発明の全体動作を説明するフローチャートである。

まず、第１デバイスは、チャンネル時間を要請するコマンドフレームを生成してＰＮＣに伝送し、伝送されたフレームに対するＡＣＫを受信する（Ｓ８０１）。このためにはまず、第１デバイスのＤＭＥ（Ｄｅｖｉｃｅ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ）でＭＬＭＥ−ＣＲＥＡＴＥ−ＳＴＲＥＡＭ．ｒｅｑｕｅｓｔを生成してＭＡＣのＭＬＭＥに伝達する。前記ＭＬＭＥ−ＣＲＥＡＴＥ−ＳＴＲＥＡＭ．ｒｅｑｕｅｓｔのパラメータは、前記（表１）で定義されたように、既存のパラメータに‘ＤｉｒｅｃｔｉｏｎＴｙｐｅ’をさらに含む。前記ＭＬＭＥに伝達されたＭＬＭＥ−ＣＲＥＡＴＥ−ＳＴＲＥＡＭ．ｒｅｑｕｅｓｔを利用して、ＭＬＭＥではチャンネル時間を要請するコマンドフレーム、すなわち、チャネルタイムリクエストコマンドフレームを生成し、これを物理層を通じてＰＮＣに伝送する。

前記コマンドフレームを伝送されたＰＮＣは、現在チャンネル（無線通信媒体）に使用できるリソース（ａｖａｉｌａｂｌｅ ｒｅｓｏｕｒｃｅｓ）があるかどうかを判断する（Ｓ８０２）。前記判断結果、リソースがなければ、ｃｈａｎｎｅｌ ｔｉｍｅ ｒｅｓｐｏｎｓｅ ｃｏｍｍａｎｄフレームのｒｅａｓｏｎｃｏｄｅを、‘ｐｒｉｏｒｉｔｙ ｕｎｓｕｐｐｏｒｔｅｄ’、‘ｃｈａｎｎｅｌ ｔｉｍｅ ｕｎａｖａｉｌａｂｌｅ’または‘ｕｎａｂｌｅ ｔｏ ａｌｌｏｃａｔｅ ａｓ ｐｓｅｕｄｏ−ｓｔａｔｉｃ ＣＴＡ’などで適当に表示し、第１デバイスにｃｈａｎｎｅｌ ｔｉｍｅ ｒｅｓｐｏｎｓｅ ｃｏｍｍａｎｄフレームを伝送する。そして、ｒｅｓｏｕｒｃｅがある場合には、前記チャンネル時間要請に応答するコマンドフレーム、すなわち、ｃｈａｎｎｅｌ ｔｉｍｅ ｒｅｓｐｏｎｓｅ ｃｏｍｍａｎｄフレームにｒｅａｓｏｎ ｃｏｄｅを‘ｓｕｃｃｅｓｓ’と表示して前記第１デバイスに伝送し、前記第１デバイスからＩｍｍ−ＡＣＫを受信する（Ｓ８０３）。

次いで、ＰＮＣは、前記伝送されたチャネルタイムリクエストコマンドフレームに存在する情報を利用してビーコンフレームを生成し、ピコネットのメンバーであるＤＥＶにビーコンフレームをブロードキャストする（Ｓ８０４）。前記ビーコンフレームにはチャンネル割り当てに関する情報が含まれるが、前記情報としてはＣＴＡ持続時間、スーパーフレーム上でＣＴＡが占める位置、データの同一性を識別するストリームインデックス、データを送信するデバイス（第１デバイス）のＩＤ、データを受信するデバイス（第２デバイス）のＩＤ、そしてデータの伝送方向が単方向であるか双方向であるかを表す‘ＤｉｒｅｃｔｉｏｎＴｙｐｅ’このある。本実施形態では、ＤｉｒｅｃｔｉｏｎＴｙｐｅは双方向、すなわち、‘１’と設定される。前記ＤｉｒｅｃｔｉｏｎＴｙｐｅ情報を持つビーコンフレームを伝送された第１デバイスと第２デバイスとは、両者間に双方向にデータを送受信するということが分かる。

この後、第１デバイスと第２デバイスとが通信するＣＴＡの開始時間になれば（Ｓ８０５のはい）、第１デバイスは第２デバイスにデータフレームを伝送し、第２デバイスからＩｍｍ−ＡＣＫフレームを受信する（Ｓ８０６）。データは、最大フレーム長以下のフレーム単位で割れて伝送されるので、単位より大きいデータを伝送する場合には複数のデータフレームの伝送過程を経ねばならない。また、前記データをいずれも伝送した後にさらに他のデータを伝送する場合にも、追加的なフレーム伝送過程を経ねばならない。

前記のような伝送過程を経て第１デバイスが伝送するデータフレームがこれ以上存在していなければ（Ｓ８０７のいいえ）、第１デバイスは、第２デバイスにこれ以上伝送するデータがないということを表示するＮＵＬＬフレームを伝送する（Ｓ８０８）。

前記ＮＵＬＬフレームを伝送された第２デバイスは、伝送するデータがなければ（Ｓ８０９のいいえ）、第１デバイスにＩｍｍ−ＡＣＫを伝送し（Ｓ８１０）、前記Ｓ８０７ステップに戻る。一方、伝送するデータフレームがあれば（Ｓ８０９のはい）、第２デバイスは、第１デバイスにデータフレームを伝送し、第１デバイスからＩｍｍ−ＡＣＫを受信する（Ｓ８１１）。その後、第２デバイスが伝送するデータフレームがさらにあれば（Ｓ８１２のはい）、追加的なデータフレーム伝送過程（Ｓ８１１）を経て、伝送するデータがさらになければ（Ｓ８１２のいいえ）、第２デバイスは第１デバイスにＮＵＬＬフレームを伝送する（Ｓ８１３）。同様に、前記ＮＵＬＬフレームを伝送された第１デバイスは、伝送するデータフレームがあれば（Ｓ８１４のはい）、前記Ｓ８０６ステップに戻り、伝送するデータがなければ、第２デバイスにＩｍｍ−ＡＣＫを伝送した後（Ｓ８１５）、前記Ｓ８１２ステップに戻る。

前記Ｓ８０６ステップからＳ８１５ステップは、該当ＣＴＡの開始時間から終了時間まで進み、前記ステップのうち任意のステップでＣＴＡの終了時間になれば、図９での過程は終了する。

以下では、図１０ないし図１３を参照して本発明による第２実施形態を説明する。
図１０は、ＤｉｒｅｃｔｉｏｎＴｙｐｅがＴＷＯ＿ＷＡＹであるチャンネル時間を割り当てられた時、そのチャンネル時間にＤＥＶ１とＤＥＶ２とがデータを送受信する過程を示すものである。チャネルタイムリクエストコマンド１００を送ったＤＥＶ１がＳｒｃＩＤと、ＤＥＶ２がＤｅｓｔＩＤと指定されたチャネルタイムアロケーションブロック２１１をビーコンから受けた後、指定された時間になれば、ＤＥＶ１がまず送信者となってＤＥＶ２にデータを伝送する（Ｓ１１０）。ＤＥＶ２は、ＤＥＶ１から受けたデータフレームのＡＣＫ ｐｏｌｉｃｙに合わせてＡＣＫフレームを送る。本例では、データ伝送に対するＡＣＫとしては、Ｉｍｍ−ＡＣＫ（Ｉｍｍｅｄｉａｔｅ ＡＣＫ）ｐｏｌｉｃｙを仮定する（Ｓ１２０）。現状態で、ＤＥＶ１がこれ以上送るデータがなければ、ＤＥＶ２にＴＯＫＥＮフレームを伝送する（Ｓ１３０）。前記ＴＯＫＥＮフレームは、ＭＡＣヘッダ部分のみ存在し、フレームボディ部分は存在していないフレームであって、その構造は図１１に示す通りである。

もし、前記Ｓ１３０ステップで送るフレームがあったとすれば、ＴＯＫＥＮフレームではなく直ちにデータフレームを送ったはずである。ＴＯＫＥＮフレームを受けた時点でＤＥＶ２が現在送るデータがなければ、同様にＴＯＫＥＮフレームを伝送する（Ｓ１４０）。このようにＴＯＫＥＮフレームは、データを伝送できる権利を相手側ＤＥＶに渡す役割を行う。

ＤＥＶ１はＴＯＫＥＮフレームを送り、再びＴＯＫＥＮフレームを受けた後には、ＤＥＶ２に送るデータがあればそれを伝送し、送るデータがなければ再びＴＯＫＥＮフレームを伝送できる（Ｓ１５０）。もし、ＤＥＶ２が再びＴＯＫＥＮフレームを受けて、その時点にＤＥＶ１に送るデータが準備されたならば、今度はデータフレームをＤＥＶ１に伝送する（Ｓ１６０）。ＤＥＶ１は、自身が送ったＴＯＫＥＮフレームに対してＴＯＫＥＮフレームではなく、データフレームを受けたので、これに対するＩｍｍ−ＡＣＫをＤＥＶ２に送る（Ｓ１７０）。Ｉｍｍ−ＡＣＫを受けたＤＥＶ２は、さらに送るデータがあればＤＥＶ１にそれらを伝送し続け、そうでなければ、ＴＯＫＥＮフレームをＤＥＶ１に送る（Ｓ１８０）。このような過程が、二つのＤＥＶに割り当てられたチャンネル時間が終わるまで反復される。

図１１は、本発明で提案する前記‘ＴＯＫＥＮフレーム’の構造を詳細に示すものである。ＴＯＫＥＮフレームは、ＭＡＣヘッダのみ存在してフレームボディは存在していないフレームであって、従来のＭＡＣヘッダのように１０ｏｃｔｅｔｓの大きさを持ち、それぞれのフィールドは１ｏｃｔｅｔの大きさを持つ。ここで、Ｆｒａｍｅｔｙｐｅフィールド１７１０は、ＴＯＫＥＮフレームのｔｙｐｅ ｖａｌｕｅを記録する所である。各種フィールドフレームのｔｙｐｅ ｖａｌｕｅを定義したテーブルが図１２に示されている。

このようなｔｙｐｅ ｖａｌｕｅは、ＭＡＣヘッダのｂ５、ｂ４及びｂ３ビットに記録されるが、各ビットの組み合わせによって該当フレームがいかなるフレームであるかを知らせる。例えば、‘０００’はビーコンフレームを意味し、‘００１’はＩｍｍ−ＡＣＫフレームを意味する。既存のＩＥＥＥ ８０２．１５．３では、それ以外にもＤｅｌａｙｅｄ ＡＣＫフレーム（ｖａｌｕｅ＝‘０１０’）、ｃｏｍｍａｎｄフレーム（ｖａｌｕｅ＝‘０１１’）、データフレーム（ｖａｌｕｅ＝‘１００’）などのｔｙｐｅ ｖａｌｕｅが規定されている。本発明では、前記ｔｙｐｅ ｖａｌｕｅと合わせて、ＴＯＫＥＮフレームのｔｙｐｅ ｖａｌｕｅを新たに追加し、これを‘１０１’と規定した。

再び図１１を参照すれば、ＡＣＫ ｐｏｌｉｃｙフィールド１７２０にはＡＣＫ ｐｏｌｉｃｙによるＡＣＫフレームのｔｙｐｅ ｖａｌｕｅを記録する。前記ＡＣＫフレームのｔｙｐｅ ｖａｌｕｅは、ＩＥＥＥ ８０２．１５．３によれば、ＭＡＣヘッダのｂ８、ｂ７ビットに記録されるが、Ｎｏ ＡＣＫは‘００’、Ｉｍｍｅｄｉａｔｅ ＡＣＫは‘０１’、Ｄｅｌａｙｅｄ ＡＣＫは‘１０’の値を持つ。したがって、第２実施形態によるＡＣＫ ｐｏｌｉｃｙはＮｏ−ＡＣＫであるので、ＡＣＫ ｐｏｌｉｃｙフィールドは‘００’値を持つ。そして、ＤｅｓｔＩＤフィールド１７３０には、該当ＴＯＫＥＮフレームを送信するＤＥＶのＩＤを記録し、ＳｒｃＩＤフィールド１７４０には該当ＴＯＫＥＮフレームを受信するＤＥＶのＩＤを記録する。それ以外のＭＡＣヘッダのフィールド値はいずれも‘０’とする。

図１３は、本発明の全体動作を説明するフローチャートである。まず、第１デバイスは、チャンネル時間を要請するコマンドフレームを生成してＰＮＣに伝送し、伝送されたフレームに対するＡＣＫを受信する（Ｓ９０１）。そのためには、まず、第１デバイスのＤＭＥでＭＬＭＥ−ＣＲＥＡＴＥ−ＳＴＲＥＡＭ．ｒｅｑｕｅｓｔを生成してＭＡＣのＭＬＭＥに伝達する。前記ＭＬＭＥ−ＣＲＥＡＴＥ−ＳＴＲＥＡＭ．ｒｅｑｕｅｓｔのパラメータは、前記（表１）で定義されたように、既存のパラメータに‘ＤｉｒｅｃｔｉｏｎＴｙｐｅ’をさらに含む。前記ＭＬＭＥに伝達されたＭＬＭＥ−ＣＲＥＡＴＥ−ＳＴＲＥＡＭ．ｒｅｑｕｅｓｔを利用して、ＭＬＭＥではチャンネル時間を要請するコマンドフレーム、すなわち、チャネルタイムリクエストコマンドフレームを生成し、これを物理層を通じてＰＮＣに伝送する。

前記コマンドフレームを伝送されたＰＮＣは、現在チャンネル（無線通信媒体）に使用できるｒｅｓｏｕｒｃｅがあるかどうかを判断する（Ｓ９０２）。前記判断結果、リソースがなければ、ｃｈａｎｎｅｌ ｔｉｍｅ ｒｅｓｐｏｎｓｅ ｃｏｍｍａｎｄフレームのｒｅａｓｏｎ ｃｏｄｅを‘ｐｒｉｏｒｉｔｙ ｕｎｓｕｐｐｏｒｔｅｄ’、‘ｃｈａｎｎｅｌ ｔｉｍｅ ｕｎａｖａｉｌａｂｌｅ’または‘ｕｎａｂｌｅ ｔｏ ａｌｌｏｃａｔｅ ａｓ ｐｓｅｕｄｏ−ｓｔａｔｉｃ ＣＴＡ’などで適当に表示し、第１デバイスにｃｈａｎｎｅｌ ｔｉｍｅ ｒｅｓｐｏｎｓｅ ｃｏｍｍａｎｄフレームを伝送する。そして、ｒｅｓｏｕｒｃｅがある場合には、前記チャンネル時間要請に応答するコマンドフレーム、すなわち、ｃｈａｎｎｅｌ ｔｉｍｅ ｒｅｓｐｏｎｓｅ ｃｏｍｍａｎｄフレームにｒｅａｓｏｎ ｃｏｄｅを‘ｓｕｃｃｅｓｓ’と表示して前記第１デバイスに伝送し、前記第１デバイスからＩｍｍ−ＡＣＫを受信する（Ｓ９０３）。

次いで、ＰＮＣは前記伝送されたチャネルタイムリクエストコマンドフレームに存在する情報を利用してビーコンフレームを生成し、ピコネットのメンバーのＤＥＶにビーコンフレームをブロードキャストする（Ｓ９０４）。前記ビーコンフレームにはチャンネル割り当てに関する情報が含まれるが、前記情報としては、ＣＴＡ持続時間、スーパーフレーム上でＣＴＡが占める位置、データの同一性を識別するストリームインデックス、データを送信するデバイス（第１デバイス）のＩＤ、データを受信するデバイス（第２デバイス）のＩＤ、そして、データの伝送方向が単方向であるか、または双方向であるかを表す‘ＤｉｒｅｃｔｉｏｎＴｙｐｅ’がある。第２実施形態では、ＤｉｒｅｃｔｉｏｎＴｙｐｅは双方向、すなわち、‘１’と設定される。前記ＤｉｒｅｃｔｉｏｎＴｙｐｅ情報を持つビーコンフレームを伝送された第１デバイスと第２デバイスとは、両者間に双方向にデータを送受信するということが分かる。

この後、第１デバイスと第２デバイスが通信するＣＴＡの開始時間になれば（Ｓ９０５のはい）、第１デバイスは第２デバイスにデータフレームを伝送し、第２デバイスからＩｍｍ−ＡＣＫフレームを受信する（Ｓ９０６）。データは、最大フレーム長以下のフレーム単位で割れて伝送されるので、単位より大きいデータを伝送する場合には、複数のデータフレームの伝送過程を経ねばならない。また、前記データをいずれも伝送した後、さらに他のデータを伝送する場合にも追加的なフレーム伝送過程を経る必要がある。

前記のような伝送過程を経て第１デバイスが伝送するデータフレームがこれ以上存在していなければ（Ｓ９０７のいいえ）、第１デバイスは、第２デバイスにこれ以上伝送するデータがないことを表示するＴＯＫＥＮフレームを伝送する（Ｓ９０８）。

前記ＴＯＫＥＮフレームを伝送された第２デバイスは、伝送するデータがなければ（Ｓ９０９のいいえ）、第１デバイスにＴＯＫＥＮフレームを伝送し（Ｓ９１０）、前記Ｓ９０７ステップに戻る。一方、伝送するデータフレームがあれば（Ｓ９０９のはい）、第２デバイスは第１デバイスにデータフレームを伝送し、第１デバイスからＩｍｍ−ＡＣＫを受信する（Ｓ９１１）。その後、第２デバイスが伝送するデータフレームがさらにあれば（Ｓ９１２のはい）、追加的なデータフレーム伝送過程（Ｓ９１１）を経、伝送するデータがさらになければ（Ｓ９１２のいいえ）、第２デバイスは第１デバイスにＴＯＫＥＮフレームを伝送する（Ｓ９１３）。同様に、前記ＴＯＫＥＮフレームを伝送された第１デバイスは、伝送するデータフレームがあれば（Ｓ９１４のはい）、前記Ｓ９０６ステップに戻り、伝送するデータがなければ、第２デバイスにＴＯＫＥＮフレームを伝送した後（Ｓ９１５）、前記Ｓ９１２ステップに戻る。

前記Ｓ９０６ステップからＳ９１５ステップまでは、該当ＣＴＡの開始時間から終了時間まで進み、前記ステップのうち任意のステップでＣＴＡの終了時間になれば図１３での過程は終了する。

以下では、図１４及び図１５を参照して、従来技術によってＣＴＡで単方向伝送を行う場合と、本発明によってＣＴＡで双方向伝送を行う場合との伝送効率の差を比較する。

図１４は、従来の技術によって単方向伝送を行う場合について、スーパーフレーム９００の構造及びデータ伝送過程を説明するための図面である。二つのＤＥＶがピコネットに存在し（ＤＥＶ１、ＤＥＶ２）、ＴＣＰ／ＩＰを利用してＤＥＶ１がＤＥＶ２にストリームを伝送しようとすれば、ＤＥＶ１からＤＥＶ２にデータフレームが伝送され、これに対するＡＣＫフレームがＤＥＶ２からＤＥＶ１に伝送される。データ伝送時、ＭＡＣ層で使用するＡＣＫ ｐｏｌｉｃｙはＩＭＭ−ＡＣＫ ｐｏｌｉｃｙとし、スーパーフレームｄｕｒａｔｉｏｎは１０ｍｓ、ＣＡＰは１ｍｓと仮定する。そして、ＭＡＣｈｅａｄｅｒの伝送率は２２Ｍｂｐｓ、フレームｐａｙｌｏａｄの伝送率は５５Ｍｂｐｓとする。

まずＤＥＶ１とＤＥＶ２いずれもｒａｔｅ ｆａｃｔｏｒを１としたスーパーレートＣＴＡを要請したとすれば、スーパーフレーム９００は、図１５のように使われる。図１４のように、ＣＴＡ ＩＥとＢＳＩＤ ＩＥ以外に他のＩＥ（ｉｎｆｏｒｍａｔｉｏｎ ｅｌｅｍｅｎｔ）は持っていないと仮定する。

ビーコン９１０は１０ｂｙｔｅのＭＡＣヘッダ、２１ｂｙｔｅのピコネットｓｙｎｃ ｐａｒａｍｅｔｅｒｓ、１６ｂｙｔｅのＣＴＡ ＩＥ（本例では、二つのＣＴＡ情報を持っているので）、２０ｂｙｔｅのＢＳＩＤ ＩＥ（ＢＳＩＤの大きさを１０ｂｙｔｅｓと仮定する）で構成される。（表３）のような計算過程の結果、前記のようなビーコンを伝送するには約０．０１２ｍｓがかかる。

ＣＴＡ１ ９３０とＣＴＡ２ ９４０とのｄｕｒａｔｉｏｎは、それぞれＤＥＶ１とＤＥＶ２とがＰＮＣに要請したＴＵ（タイムユニット）の大きさとＤｅｓｉｒｅｄ ｎｕｍｂｅｒ ｏｆ ＴＵｓによって変わる。ＴＵは、指定したＡＣＫ ｐｏｌｉｃｙによって最小限一つのフレームは伝送可能にせねばならない。ビーコン伝送時間とＣＡＰ ９２０とを除外した残りの時間をいずれも各ＤＥＶに割り当てるとすれば、ＤＥＶ１、ＤＥＶ２いずれもレートファクタが１であるスーパーレートＣＴＡを要請したと仮定したので、図１４のようにｓｒｃ ＤＥＶがＤＥＶ１であり、ｄｅｓｔ ＤＥＶがＤＥＶ２であるＣＴＡ１ ９３０と、ｓｒｃ ＤＥＶがＤＥＶ２であり、ｄｅｓｔ ＤＥＶがＤＥＶ１であるＣＴＡ２ ９４０が配分される。ＣＴＡ１ ９３０とＣＴＡ２ ９４０とのｄｕｒａｔｉｏｎは、各ＤＥＶが要請したＴＵ及びＰＮＣのｃｈａｎｎｅｌ ｔｉｍｅ ａｌｌｏｃａｔｉｏｎアルゴリズムによって変わりうる。

ＣＴＡ１ ９３０が始まる時間になれば、まずＤＥＶ１がＤＥＶ２にフレーム１ ９５０を伝送する。この時、フレーム１ ９５０のペイロードは、ＴＣＰ／ＩＰのデータフレームである。最大フレーム長さが２０４８ｂｙｔｅｓ（ＭＡＣヘッダは除外）であるため、フレーム１ ９５０を２０４８ｂｙｔｅｓとすれば、フレーム１ ９５０の伝送時間は次の（表４）のように０．３０１４ｍｓとなる。

ＡＣＫ１ ９６０は、ＤＥＶ２からＤＥＶ１に送るＡＣＫフレームである。これは、ＭＡＣ層でＭＡＣのＡＣＫ ｐｏｌｉｃｙによって伝送されることである。ＩＥＥＥ ８０２．１５．３でＡＣＫフレームは、ＭＡＣヘッダのみから形成されているので、ＡＣＫフレームを伝送するには０．００３６ｍｓがかかる。

本例でＭＡＣ層の上位層ではＴＣＰ／ＩＰを利用して伝送するので、ＤＥＶ１は、ＤＥＶ２からＴＣＰ／ＩＰレベルのＡＣＫフレームを受けることができなければ、これ以上新たなフレームを伝送できない。ＤＥＶ１がＤＥＶ２にＴＣＰ／ＩＰを利用してフレームを伝送すれば、ＤＥＶ２はこれに対するＡＣＫフレームを送らねばならない。これは、ＭＡＣ層から送るＡＣＫ（例えば、前記Ｉｍｍ−ＡＣＫ）とは別途に、ＭＡＣ層の上位層で伝送されることであるために、ＭＡＣ層から見れば他のデータフレームと同様に処理される。

図１４で、フレーム２はＤＥＶ２がＤＥＶ１に伝送するＴＣＰ／ＩＰレベルのＡＣＫフレームを表す。このように、ＤＥＶ２がＤＥＶ１にフレーム２を送ろうとしても、自身がｓｒｃと指定されたチャンネル時間になるまで待たねばならない。したがって、ＣＴＡ２ ９４０が始まる時間になって初めてフレーム２ ９７０を伝送できる。ＡＣＫ２ ９８０は、ＭＡＣ層のＡＣＫ ｐｏｌｉｃｙによって伝送されるＭＡＣ層レベルのＡＣＫフレームである。

以上で説明したように、既存の８０２．１５．３のＣＴＡ方式を使用する場合には、１０ｍｓというスーパーフレームの間にＤＥＶ１からＤＥＶ２に２０４８ｂｙｔｅｓサイズのフレーム一つが伝送され、逆にＤＥＶ２からＤＥＶ１にも２０４８ｂｙｔｅｓのフレーム一つのみ伝送される。

図１５は、本発明によって双方向伝送を行う場合についてスーパーフレーム９００構造及びデータ伝送過程を説明するための図面である。ＤＥＶ１がＰＮＣに対してＤｉｒｅｃｔｉｏｎＴｙｐｅがＴＷＯ＿ＷＡＹであるチャンネル時間を要請すれば、これに対するスーパーフレームは図１５のように構成される。図１４と同様に、ビーコン伝送時間とＣＡＰ ９２０を除外した残りの時間をいずれもＤＥＶに割り当てると仮定する。そして、フレーム１ ９５０は、ＤＥＶ１からＤＥＶ２に送るＴＣＰ／ＩＰデータフレームであり、フレーム２ ９７０は、ＤＥＶ２からＤＥＶ１に送るＴＣＰ／ＩＰレベルのＡＣＫフレームである。フレーム２ ９７０が伝送されるまで処理時間を考慮して、中間にＮＵＬＬフレームまたはＴＯＫＥＮフレーム ９９０一つが伝送されると仮定した。すると、ＤＥＶ１からＤＥＶ２にＴＣＰ／ＩＰデータフレームを一つ送り、これについてＴＣＰ／ＩＰレベルのＡＣＫフレームを受けるまでかかる時間Ａを計算すれば、（表５）の通りである。

したがって、１０ｍｓのスーパーフレーム９００の間にビーコン９１０伝送時間とＣＡＰ ９２０とを除外した値を前記時間Ａで割れば、次の（表６）での結果の通りである。

この結果によれば、単位スーパーフレーム間、ＤＥＶ１はＤＥＶ２に２０４８ｂｙｔｅｓフレームを１３個送ることができ、同様にこの時間の間にＤＥＶ２もＤＥＶ１に２０４８ｂｙｔｅｓのフレーム１３個を送ることができる。もちろん、前記でＣＴＡ レートファクタを１を超過する数と指定してＰＮＣにチャンネル時間を要請するならば、図１４よりは多量のデータを伝送できる。しかし、レートファクタやＰＮＣのチャンネル時間の割り当てアルゴリズムによってチャンネル時間の配置が変わり、また常にチャンネル時間を最大に使用できるという保証がないために、本発明のようにＤｉｒｅｃｔｉｏｎＴｙｐｅを持つチャンネル時間を利用することがさらに効率的であるといえる。

以上、添付された図面を参照して本発明の実施形態を説明したが、当業者ならば、本発明がその技術的思想や必須な特徴を変更せずに他の具体的な形態に実施できるということを理解できる。したがって、前述した実施形態はあらゆる面で例示的なものであって限定的でないと理解せねばならない。本発明の範囲は、前記説明よりは特許請求の範囲によって表され、特許請求の範囲の意味及び範囲、そしてその均等概念から導出されるあらゆる変更または変形された形態が本発明の範囲に含まれると解釈されねばならない。

既存の８０２．１５．３ＭＡＣで提供するチャンネル時間は、ソースデバイスと目的地デバイスとが固定されていて、一チャンネル時間の間には１デバイスのみデータを送り、他のデバイスは一方的にそれを受けざるをえない。したがって、前述したように、ＴＣＰ／ＩＰのように相互フレームを送受信せねばならないプロトコルに対しては非効率的に動作する。本発明によれば、このような非効率性を減少させて全体的な伝送効率を向上させることができる。

従来のスーパーフレームの構造を示す図である。 従来のチャンネル時間の割り当てを要請する過程を示す図である。 従来の非同期データを伝送する過程を示す図である。 本発明によるチャネルタイムリクエストコマンドフレームの構造を示す図である。 本発明によるＢｅａｃｏｎ ｆｒａｍｅの構造を示す図である。 第１実施形態によってチャンネル時間内にデバイス間に双方向にデータを送受信する例を示す図である。 第１実施形態によるＮＵＬＬフレームの構造を示す図である。 第１実施形態による各種フレームのＦｒａｍｅ ｔｙｐｅ ｖａｌｕｅを示す表である。 第１実施形態による本発明の全体動作を説明するフローチャートである。 第２実施形態によってチャンネル時間内にデバイス間に双方向にデータを送受信する例を示す図である。 第２実施形態によるＮＵＬＬフレームの構造を示す図である。 第２実施形態による各種フレームのＦｒａｍｅ ｔｙｐｅ ｖａｌｕｅを示す表である。 第２実施形態による本発明の全体動作を説明するフローチャートである。 従来の単方向伝送を行う場合について、スーパーフレーム構造及びデータ伝送過程を示す図である。 本発明による双方向伝送を行う場合について、スーパーフレーム構造及びデータ伝送過程を示す図である。

Claims (13)

1. （ａ）データ送信方向が単方向であるか双方向であるかを決定する方向情報を含むチャンネル時間要請フレームを生成して、チャンネル時間の割り当てを担当するデバイスに伝送するステップと、
   （ｂ）前記チャンネル時間要請フレームに存在する情報を利用して前記方向情報が含まれたチャンネル時間の割り当て情報を持つフレームを生成し、前記生成されたフレームをブロードキャストするステップと、
   （ｃ）前記ビーコンフレームでソースデバイスと指定された第１デバイスと、目的地デバイスと指定された第２デバイスとの間に、所定のチャンネル時間の間に前記方向情報に合わせてデータを送受信するステップと、を含む無線ＰＡＮ上でデバイス間にデータを送受信する方法。
2. 前記チャンネル時間要請フレームは、ＩＥＥＥ ８０２．１５．３で規定するチャネルタイムリクエストコマンドフレームである請求項１に記載のデータ送受信方法。
3. 前記チャンネル時間の割り当てを担当するデバイスは、ＩＥＥＥ ８０２．１５．３で規定するピコネットコーディネーターである請求項１に記載のデータ送受信方法。
4. 前記チャンネル時間の割り当て情報を持つフレームは、ＩＥＥＥ ８０２．１５．３で規定するビーコンフレームである請求項１に記載のデータ送受信方法。
5. 前記（ｃ）ステップは、前記第１デバイスが前記第２デバイスにデータを伝送するステップと、前記データ伝送結果、前記第１デバイスがこれ以上伝送するデータがなければ前記第２デバイスにＮＵＬＬフレームを伝送するステップと、を含む請求項１に記載のデータ送受信方法。
6. 前記（ｃ）ステップは、前記ＮＵＬＬフレームを受信した第２デバイスが前記第１デバイスに伝送するデータがあれば、データを伝送し、伝送するデータがなければ、前記第１デバイスが伝送したデータについての確認フレームを伝送するステップをさらに含む請求項５に記載のデータ送受信方法。
7. 前記（ｃ）ステップは、前記確認フレームを受信した第１デバイスが前記第２デバイスに伝送するデータがあれば、データを伝送し、伝送するデータがなければ、前記第２デバイスにＮＵＬＬフレームを伝送するステップをさらに含む請求項６に記載のデータ送受信方法。
8. 前記確認フレームは、ＭＡＣ層でのＩｍｍｅｄｉａｔｅ ＡＣＫフレームである請求項６に記載のデータ送受信方法。
9. 前記ＮＵＬＬフレームは、ＭＡＣヘッダのみで構成され、Ｉｍｍｅｄｉａｔ ＡＣＫ ｐｏｌｉｃｙを行なう請求項５に記載のデータ送受信方法。
10. 前記（ｃ）ステップは、前記第１デバイスが前記第２デバイスにデータを伝送するステップと、前記データ伝送結果、前記第１デバイスがこれ以上伝送するデータがなければ、前記第２デバイスに第１ ＴＯＫＥＮフレームを伝送するステップを含む請求項１に記載のデータ送受信方法。
11. 前記（ｃ）ステップは、前記ＮＵＬＬフレームを受信した第２デバイスが前記第１デバイスに伝送するデータがあれば、データを伝送し、伝送するデータがなければ、第２ ＴＯＫＥＮフレームを伝送するステップをさらに含む請求項１０に記載のデータ送受信方法。
12. 前記（ｃ）ステップは、前記ＴＯＫＥＮフレームを受信した第１デバイスが前記第２デバイスに伝送するデータがあれば、データを伝送し、伝送するデータがなければ、前記第２デバイスに前記第２ ＴＯＫＥＮフレームを伝送するステップをさらに含む請求項１１に記載のデータ送受信方法。
13. 前記第１ ＴＯＫＥＮフレームは、ＭＡＣヘッダのみで構成され、Ｎｏ ＡＣＫ ｐｏｌｉｃｙを行なう請求項１０に記載のデータ送受信方法。

Images