(57)【要約】  本発明は二つのデバイス間に通信をすることができるよう許与された時間の間、両方向にデータを送受信する方法及び装置に関するものである。  本発明による無線デバイスは、無線媒体を通しＭＡＣフレームを受信するＰＨＹモジュールと、受信されたＭＡＣフレームの第１フィールド（伝送されるデータがさらに存在するのかの可否を示すフィールド）の値を判読するＭＡＣモジュールと、前記第１フィールドの値が伝送されるデータがさらに存在しないことを示すビットであり、前記ＭＡＣフレームが受信された後所定の臨界時間の間チャンネルが空いていれば伝送権が転換されたものと判断する、伝送権判断モジュール、及び伝送権が転換されたものと判断され、受信されたＭＡＣフレームを伝送したデバイスに伝送されるデータが存在すれば、伝送されたデータを含むＭＡＣフレームを伝送されるようＭＡＣモジュール及びＰＨＹモジュールを制御する制御モジュールを含む。
2008512033.tif 000002
【特許請求の範囲】
【請求項１】
無線媒体を介してＭＡＣフレームを受信するＰＨＹモジュールと、
前記受信されたＭＡＣフレームの第１フィールドの値を判読するが、前記第１フィールドは伝送されるデータがさらに存在するのかの可否を表すフィールドであるＭＡＣモジュールと、
前記第１フィールドの値が第１ビットであり、前記ＭＡＣフレームが受信された後、所定の臨界時間の間チャンネルが空いていれば伝送権が転換されたものと判断するが、前記第１ビットは伝送されるデータがさらに存在しないことを表す伝送権判断モジュール、および
前記伝送権が転換されたものと判断され、前記受信されたＭＡＣフレームを伝送したデバイスに伝送するデータが存在すれば、前記伝送するデータを含むＭＡＣフレームを伝送するよう前記ＭＡＣモジュールおよび前記ＰＨＹモジュールを制御する制御モジュールを含むことを特徴とする無線デバイス。
【請求項２】
前記第１フィールドは
ＩＥＥＥ８０２．１５．３のＭＡＣヘッダに存在するＭｏｒｅ  ｄａｔａフィールドであることを特徴とする請求項１に記載の無線デバイス。
【請求項３】
前記臨界時間は
少なくともＩＥＥＥ８０２．１５．３のｒｅｔｒａｎｓｍｉｓｓｉｏｎ  ｉｎｔｅｒｆｒａｍｅ  ｓｐａｃｅ（ＲＩＦＳ）よりは大きいことを特徴とする請求項１に記載の、無線デバイス。
【請求項４】
前記制御モジュールは
前記伝送権が転換されたものと判断され、前記受信されたＭＡＣフレームを伝送したデバイスに伝送するデータが存在しなければ、前記デバイスに伝送権を引き渡すフレームを伝送するよう前記ＭＡＣモジュールおよびＰＨＹモジュールを制御することを特徴とする請求項１に記載の、無線デバイス。
【請求項５】
前記伝送権を引き渡すフレームは
ＭＡＣヘッダのみで構成され、前記第１フィールドは第１ビットと設定されることを特徴とする請求項４に記載の、無線デバイス。
【請求項６】
前記伝送権を引き渡すフレームは
Ｎｏ−ＡＣＫ  ｐｏｌｉｃｙを使用することを特徴とする請求項５に記載の、無線デバイス。
【請求項７】
前記受信されるデータフレームのＡＣＫ  ｐｏｌｉｃｙがＮｏ−ＡＣＫ  ｐｏｌｉｃｙである場合には前記臨界時間は０であることを特徴とする請求項１に記載の、無線デバイス。
【請求項８】
（ａ）無線媒体を介してＭＡＣフレームを受信する段階と、
（ｂ）前記受信されるＭＡＣフレームの第１フィールドの値を判読する段階であって、前記第１フィールドは伝送されるデータがさらに存在するのかの可否を表す段階と、
（ｃ）前記フィールドの値が第１ビットであり、前記ＭＡＣフレームが受信された後、所定の臨界時間の間チャンネルが空いていれば伝送権が転換されたものと判断する段階であって、前記第１ビットは伝送されるデータがさらに存在しないことを表す段階、および
（ｄ）前記伝送権が転換されたものと判断され、前記受信されたＭＡＣフレームを伝送したデバイスに伝送するデータが存在すれば、前記伝送されるデータを含むＭＡＣフレームを前記デバイスに伝送する段階を含むことを特徴とする、割り当てられた時間の間、両方向にデータを送受信する方法。
【請求項９】
前記第１フィールドは
ＩＥＥＥ８０２．１５．３のＭＡＣヘッダに存在するＭｏｒｅ  ｄａｔａフィールドであることを特徴とする請求項８に記載の、割り当てられた時間の間、両方向にデータを送受信する方法。
【請求項１０】
前記臨界時間は
少なくともＩＥＥＥ８０２．１５．３のｒｅｔｒａｎｓｍｉｓｓｉｏｎ  ｉｎｔｅｒｆｒａｍｅ  ｓｐａｃｅ（ＲＩＦＳ）よりは大きいことを特徴とする請求項８に記載の、割り当てられた時間の間、両方向にデータを送受信する方法。
【請求項１１】
（ｅ）前記伝送権が転換されたものと判断され、前記受信されたＭＡＣフレームを伝送したデバイスに伝送するデータが存在しなければ、前記デバイスに伝送権を引き渡すフレームを送る段階をさらに含むことを特徴とする請求項８に記載の、割り当てられた時間の間、両方向にデータを送受信する方法。
【請求項１２】
前記伝送権を引き渡すフレームは
ＭＡＣヘッダのみで構成され、前記第１フィールドは第１ビットと設定されることを特徴とする請求項１１に記載の、割り当てられた時間の間、両方向にデータを送受信する方法。
【請求項１３】
前記伝送権を引き渡すフレームは
Ｎｏ−ＡＣＫ  ｐｏｌｉｃｙを使用することを特徴とする請求項１２に記載の、割り当てられた時間の間、両方向にデータを送受信する方法。
【請求項１４】
前記受信されるデータフレームのＡＣＫ  ｐｏｌｉｃｙがＮｏ−ＡＣＫ  ｐｏｌｉｃｙである場合には前記臨界時間は０であることを特徴とする請求項８に記載の、割り当てられた時間の間、両方向にデータを送受信する方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は無線デバイス間で通信する方法および装置に関するもので、より詳細には二つの無線デバイス間で通信ができるように許与された時間の間、両方向にデータを送受信する方法および装置に関するものである。
【背景技術】
【０００２】
無線デジタルパルスとも知られているＵＷＢ（Ｕｌｔｒａ  ｗｉｄｅｂａｎｄ）は短距離区間において低電力で広いスペクトラム周波数を通し多量のデジタルデータを伝送するための無線技術であり、米国国防省が軍事的目的で開発した無線技術である。
【０００３】
このようなＵＷＢに関する標準化は現在ＩＥＥＥ８０２．１５．３、すなわち無線ＰＡＮ規格制定のためのワーキンググループ（Ｗｏｒｋｉｎｇ  Ｇｒｏｕｐ）で進められている。
【０００４】
ＩＥＥＥ８０２．１５．３にはＰＨＹとＭＡＣに関して扱っているが、現在業界ではこの中でもＭＡＣの改善方案に対する活発な研究を進めている。
【０００５】
ＩＥＥＥ８０２．１５．３  ＭＡＣの特徴は無線ネットワークの形成が迅速だということである。そして、ＡＰ（Ａｃｃｅｓｓ  Ｐｏｉｎｔ）基盤でなくＰＮＣ（Ｐｉｃｏｎｅｔ  Ｃｏｏｒｄｉｎａｔｏｒ）を中心にしたピコネットというアドホックネットワーク（Ａｄ  Ｈｏｃ  Ｎｅｔｗｏｒｋ）を基盤とする。
【０００６】
ＩＥＥＥ８０２．１５．３  ＭＡＣはＴＤＭＡ（時分割多元接続；Ｔｉｍｅ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅ  Ａｃｃｅｓｓ）方式を採択している。図１のようなスーパーフレーム（ｓｕｐｅｒｆｒａｍｅ）という時間的な配置構造内でデバイス間にデータ送受信のためＭＡＣフレームを配置する。スーパーフレームの構成としては制御情報を含んでいるビーコン（ｂｅａｃｏｎ）とバックオフ（ｂａｃｋｏｆｆ）を通じて、データを伝送するＣＡＰ（Ｃｏｎｔｅｎｔｉｏｎ  Ａｃｃｅｓｓ  Ｐｅｒｉｏｄ）区間、そして割り当てられた時間に競合なくデータを送るＣＴＡＰ（Ｃｈａｎｎｅｌ  Ｔｉｍｅ  Ａｌｌｏｃａｔｉｏｎ  Ｐｅｒｉｏｄ）区間がある。この中でＣＡＰはＭＣＴＡ（Ｍａｎａｇｅｍｅｎｔ  ＣＴＡ）で代替されて使用され得る。
【０００７】
この時、ＣＡＰ区間にはＣＳＭＡ／ＣＡ（Ｃａｒｒｉｅｒ  Ｓｅｎｓｅ  Ｍｕｌｔｉｐｌｅ  Ａｃｃｅｓｓ／Ｃｏｌｌｉｓｉｏｎ  Ａｖｏｉｄａｎｃｅ）方式を使用して、競争的接近がなされ、ＭＣＴＡではＳｌｏｔｔｅｄ  Ａｌｏｈａを利用して、チャンネルにアクセスし得る。
【０００８】
ＣＴＡＰは幾個かのＭＣＴＡと幾個かのＣＴＡブロックで構成され得る。ＣＴＡ（Ｃｈａｎｎｅｌ  Ｔｉｍｅ  Ａｌｌｏｃａｔｉｏｎ；チャンネル時間割当）の種類には動的ＣＴＡ（Ｄｙｎａｍｉｃ  ＣＴＡ）と疑似静的ＣＴＡ（Ｐｓｅｕｄｏ  ｓｔａｔｉｃ  ＣＴＡ）の２種類がある。動的ＣＴＡはスーパーフレーム毎にその位置が変わることもあり、ビーコンを逃せば該当スーパーフレームでＣＴＡを使用することができない。これに反して、疑似静的ＣＴＡは位置が変わらず同じ位置に固定されており、ビーコンを逃してもスーパーフレームを逃しても固定された位置でＣＴＡ区間を使用し得る。
【０００９】
しかし、疑似静的ＣＴＡもｍＭａｘＬｏｓｔＢｅａｃｏｎｓに該当する回数以上連続して、ビーコンを逃がせば使用することができないようにしている。このように、ＩＥＥＥ８０２．１５．３  ＭＡＣはＱｏＳ（Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ）を保障し得るＴＤＭＡ基盤で構成されており特にホームネットワーク上でのマルチメディア・オーディオ／ビデオ・ストリーミング（Ａ／Ｖ  Ｓｔｒｅａｍｉｎｇ）に適合する。しかし、ＭＡＣにおいてＱｏＳだけでなくスループットを向上させるためには依然として改善の余地がある。
【００１０】
ＩＥＥＥ８０２．１５．３  ＭＡＣではデータ伝送方式として２種類がある。１番目は同時的データ（ｉｓｏｃｈｒｏｎｏｕｓ  データ）を伝送する方式で２番目は非同期的データを伝送する方式である。
【００１１】
図２で見るように、ＤＥＶ１は同時的データを伝送するために、まずＭＬＭＥ−ＣＲＥＡＴＥ−ＳＴＲＥＡＭ．ｒｅｑｕｅｓｔおよびＭＬＭＥ−ＣＲＥＡＴＥ−ＳＴＲＥＡＭ．ｃｏｎｆｉｒｍを利用してＰＮＣからチャンネル時間（ｃｈａｎｎｅｌ  ｔｉｍｅ）の割当を受ける。
【００１２】
そして、ＭＡＣ−ＩＳＯＣＨ−ＤＡＴＡ．ｒｅｑｕｅｓｔおよびＭＡＣ−ＩＳＯＣＨ−ＤＡＴＡ．ｃｏｎｆｉｒｍを利用して、前記割り当てられたチャンネル時間の間、実際データを伝送する。割り当てられたチャンネル時間はビーコンを解析することによって知り得、この情報を利用して、ピコネットを構成するデバイス（以下「ＤＥＶ」という）は通信が始まる時間と終わる時間を知ることができる。
【００１３】
この時割り当てられたチャンネル時間にはｓｒｃ  ＤＥＶ（ソース  デバイス）とｄｅｓｔ  ＤＥＶ（目的地デバイス）が指定されている。図２を見れば、ＤＥＶ１がｓｒｃ  ＤＥＶになり、ＤＥＶ２がｄｅｓｔ  ＤＥＶになるだろう。割り当てられたチャンネル時間にデータを送信するＤＥＶは必ずｓｒｃ  ＤＥＶでなければならないが、データを受信するＤＥＶは必ずしもＣＴＡ情報で指定したｄｅｓｔ  ＤＥＶである必要はない。ただし、前記データを受信できるＤＥＶは「Ａｌｗａｙｓ  ＡＷＡＫＥ  ｂｉｔ」または「ｌｉｓｔｅｎ  ｔｏ  ｓｏｕｒｃｅ  ｂｉｔ」が１とセッティングされているＤＥＶだけである。
【００１４】
一方、図３はＤＥＶ１が非同期的データを送るための過程を示したものである。ＤＥＶ１は送信するデータがＭＡＣ−ＡＳＹＮＣ−ＤＡＴＡ．ｒｅｑｕｅｓｔを通してＭＡＣ層に到着すれば、ｓｒｃ  ＤＥＶはＰＮＣにｃｈａｎｎｅｌ  ｔｉｍｅ  ｒｅｑｕｅｓｔ  ｃｏｍｍａｎｄフレームを送る。以後ｓｒｃ  ＤＥＶが要請したチャンネル時間が割り当てられたとのことを、ビーコンを介して知ればそのチャンネル時間の間、データを送信する。前記同時的データ伝送の場合と同様に割り当てられたチャンネル時間に対してはｓｒｃ  ＤＥＶおよびｄｅｓｔ  ＤＥＶの対が指定されており、割り当てられたチャンネル時間の間には指定されたｓｒｃ  ＤＥＶだけがデータを送信することができる。
【００１５】
図３でも、ＤＥＶ１がｓｒｃ  ＤＥＶとなり、ＤＥＶ２がｄｅｓｔ  ＤＥＶとなるだろう。これ以外に、非同期的データを送るまた他の方法としてはＣＡＰ（Ｃｏｎｔｅｎｔｉｏｎ  Ａｃｃｅｓｓ  Ｐｅｒｉｏｄ）でバックオフアルゴリズムを利用してフレームを送る方法もある。
【００１６】
ＴＣＰ／ＩＰの場合データ伝送の確実性を保障するためにＤＥＶ１からフレームを伝送すればＤＥＶ２では伝送されたフレームに対するＡＣＫフレーム（図２、図３でのＩｍｍ−ＡＣＫフレームと異なりＴＣＰ／ＩＰレベルのＡＣＫフレームを意味すること）を送る。このようなメカニズムを有するＴＣＰ／ＩＰにＩＥＥＥ８０２．１５．３  ＭＡＣで提供されるデータ伝送メカニズムをそのまま使用する場合に発生する問題点を具体的に察し見れば次のとおり。
【００１７】
１番目として、同時的にＴＣＰ／ＩＰデータを伝送する場合を察し見れば、まずＤＥＶ１はＤＥＶ２と接続を確立するためのフレームを送るだろう。その為にまずＰＮＣにＭＬＭＥ−ＣＲＥＡＴＥ−ＳＴＲＥＡＭ．ｒｅｑｕｅｓｔを送ることによってｓｒｃ  ＤＥＶがＤＥＶ１、ｄｅｓｔ  ＤＥＶがＤＥＶ２であるチャンネル時間割当を要請する。ＰＮＣがチャンネル時間を割り当て、その情報をビーコンにのせて送ればＤＥＶ１はビーコン情報を読んで指定された時間に前記フレームをＤＥＶ２に伝送する。
【００１８】
ＤＥＶ２はそれに対する応答フレームを送るためにｓｒｃ  ＤＥＶがＤＥＶ２であり、ｄｅｓｔ  ＤＥＶがＤＥＶ１であるチャンネル時間の割当を要請する。そして、同様にＰＮＣがチャンネル時間を割り当てこれに関する情報をビーコンにのせて送れば、ＤＥＶ２はビーコン情報を読んで指定された時間に前記応答フレームをＤＥＶ１に伝送する。
【００１９】
ＭＬＭＥ−ＴＥＲＭＩＮＡＴＥ−ＳＴＲＥＡＭ．ｒｅｑｕｅｓｔの伝達を受ける前まではチャンネル時間が継続して割り当てられるため、その次からはＤＥＶ１とＤＥＶ２が互いにやり取りするデータおよびＡＣＫフレームはビーコンのチャンネル時間情報によりｓｒｃ  ＤＥＶおよびｄｅｓｔ  ＤＥＶの対に割り当てられた時間に送られるようになる。
【００２０】
しかし、ＴＣＰ／ＩＰの特性上、送信者はデータフレームを送った後、ＡＣＫフレームを受ける前までは他のフレームを伝送しない。ところで、ＩＥＥＥ８０２．１５．３  ＭＡＣではビーコンで知らせるチャンネル時間割当のｓｒｃ  ＤＥＶのみがそのチャンネル時間の送信者となり得る。
【００２１】
したがってＤＥＶ２がＴＣＰ／ＩＰレベルのＡＣＫフレームを送ろうとするならば、ｓｒｃ  ＤＥＶがＤＥＶ２であるチャンネル時間になる時まで待ってからＡＣＫフレームを送らなければならない。結局、ＤＥＶ１がデータを送った後、ＤＥＶ１およびＤＥＶ２に割り当てられる時間が残るとしてもＤＥＶ１はその残った時間を利用してＤＥＶ２からＡＣＫを受けることはできないためチャンネル時間の浪費が発生するものである。
【００２２】
２番目として、非同期的にＴＣＰ／ＩＰフレームを伝送する場合を察し見る。まず、ＣＡＰに非同期的データを送る場合をみれば、ＰＮＣがＣＡＰをスーパーフレームに割り当てることもでき、割り当てないこともできる。
【００２３】
それだけでなく、もし割り当てられたＣＡＰがあったとしてもＰＮＣが設定した基準にしたがってその区間の間に非同期的データを送ることができるのか否かが決定されるため、ＣＡＰを利用してＴＣＰ／ＩＰフレームを送る方法では確実な伝送を保障することができない。
【００２４】
次に、チャンネル時間割当を利用して、非同期的データを送ろうとすれば、前記したようにＭＡＣ−ＡＳＹＮＣＨ−ＤＡＴＡ．ｒｅｑｕｅｓｔを利用するようになる。しかし図３に示されたように、毎回ｃｈａｎｎｅｌ  ｔｉｍｅ  ｒｅｑｕｅｓｔ  ｃｏｍｍａｎｄをＰＮＣに送り、チャンネル時間の割り当てを受けた後にデータフレームを送らなければならないため継続的にデータを伝達しなければならないとすれば帯域幅の浪費にほかならない。
【００２５】
またチャンネル時間割当を要請したとしても要請した時間がいつ割り当てられるかは保障されておらず一度データフレームを送る時ごとに最小で次のスーパーフレームまで待たなければならないため時間遅延が毎回発生するようになる。
【００２６】
前記した問題点はＩＥＥＥ８０２．１５．３  ＭＡＣの上位層でＴＣＰ／ＩＰ以外に他のプロトコルを使用する場合でも同様に発生し得る。
【発明の開示】
【発明が解決しようとする課題】
【００２７】
本発明は前記した問題点を勘案して、創案されたもので、ＩＥＥＥ８０２．１５．３  ＭＡＣを改善して、二つのデバイス間に割り当てられたチャンネル時間の間、より効率的に通信し得るようにすることを目的とする。これのために本発明は、ＩＥＥＥ８０２．１５．３で定義されるＣＴＡを単方向伝送でない両方向伝送に使用する方法を提供しようとするものである。
【００２８】
本発明の目的は既存の８０２．１５．３  ＭＡＣ明細書に他のどんなものを追加せずとも割り当てられたｃｈａｎｎｅｌ  ｔｉｍｅを両方向で使えるようにすることによってＴＣＰと共に両方向にデータを互いにやり取りしなければならないプロトコルを効率的に支援しようとするものである。
【課題を解決するための手段】
【００２９】
前記した目的を達成するために、本発明による無線デバイスは、無線媒体を介してＭＡＣフレームを受信するＰＨＹモジュール、前記受信されたＭＡＣフレームの第１フィールドの値を判読するのに、前記第１フィールドは伝送されるデータがさらに存在するのかの可否を示すフィールドである、ＭＡＣモジュール、前記第１フィールドの値が第１ビットであり、前記ＭＡＣフレームが受信された後、所定の臨界時間の間チャンネルが空いていれば伝送権が転換されたものと判断するが、前記第１ビットは伝送されるデータがさらに存在しないことを示す伝送権判断モジュール、および前記伝送権が転換されたものと判断され、前記受信されたＭＡＣフレームを伝送したデバイスに伝送するデータが存在すれば、前記伝送するデータを含むＭＡＣフレームを伝送するよう前記ＭＡＣモジュールおよび前記ＰＨＹモジュールを制御する制御モジュールを含む。
【００３０】
前記制御モジュールは、前記伝送権が転換されたものと判断されえ、前記受信されたＭＡＣフレームを伝送したデバイスに伝送するデータが存在しなければ、前記デバイスに伝送権を引き渡すフレームを伝送するよう前記ＭＡＣモジュールおよびＰＨＹモジュールを制御するのが好ましい。
【００３１】
前記した目的を達成するために、本発明による、割り当てられた時間の間、両方向にデータを送受信する方法は、（ａ）無線媒体を介してＭＡＣフレームを受信する段階、（ｂ）前記受信されるＭＡＣフレームの第１フィールドの値を判読する段階であって、前記第１フィールドは伝送されるデータがさらに存在するのかの可否を示す段階と、（ｃ）前記フィールドの値が第１ビットであり、前記ＭＡＣフレームが受信された後、所定の臨界時間の間チャンネルが空いていれば伝送権が転換されたものと判断する段階であって、前記第１ビットは伝送されるデータがさらに存在しないことを示す段階、および（ｄ）前記伝送権が転換されたものと判断され、前記受信されたＭＡＣフレームを伝送したデバイスに伝送するデータが存在すれば、前記伝送するデータを含むＭＡＣフレームを前記デバイスに伝送する段階を含む。
【００３２】
前記第１フィールドは、ＩＥＥＥ８０２．１５．３のＭＡＣヘッダに存在するＭｏｒｅ  ｄａｔａフィールドであるのが好ましい。
【００３３】
前記臨界時間は、少なくともＩＥＥＥ８０２．１５．３のｒｅｔｒａｎｓｍｉｓｓｉｏｎ  ｉｎｔｅｒｆｒａｍｅ  ｓｐａｃｅ（ＲＩＦＳ）よりは大きいのが好ましい。
【００３４】
前記割り当てられた時間の間、両方向にデータを送受信する方法は、（ｅ）前記伝送権が転換されたものと判断され、前記受信されたＭＡＣフレームを伝送したデバイスに伝送されるデータが存在しなければ、前記デバイスに伝送権を引き渡すフレームを伝送する段階をさらに含むのが好ましい。
【００３５】
前記伝送権を引き渡すフレームは、ＭＡＣヘッダのみで構成され、前記第１フィールドは第１ビットと設定されるのが好ましい。
【００３６】
前記伝送権を引き渡すフレームは、Ｎｏ−ＡＣＫ  ｐｏｌｉｃｙを使用するのが好ましい。
【００３７】
前記受信されるデータフレームのＡＣＫ  ｐｏｌｉｃｙがＮｏ−ＡＣＫ  ｐｏｌｉｃｙの場合には前記臨界時間は０であるのが好ましい。
【００３８】
以下、添付された図面を参照して本発明の好ましい一実施形態を詳細に説明する。
【００３９】
ＩＥＥＥ８０２．１５．３標準では４個のＩＦＳ（ｉｎｔｅｒｆｒａｍｅ  ｓｐａｃｅ）を定義しているが、ｍｉｎｉｍｕｍ  ｉｎｔｅｒｆｒａｍｅ  ｓｐａｃｅ（ＭＩＦＳ）、ｓｈｏｒｔ  ｉｎｔｅｒｆｒａｍｅ  ｓｐａｃｅ（ＳＩＦＳ）、ｂａｃｋｏｆｆ  ｉｎｔｅｒｆｒａｍｅ  ｓｐａｃｅ（ＢＩＦＳ）、そしてｒｅｔｒａｎｓｍｉｓｓｉｏｎ  ｉｎｔｅｒｆｒａｍｅ  ｓｐａｃｅ（ＲＩＦＳ）がそのことである。
【００４０】
前記ＩＦＳ等（ＭＩＦＳ、ＳＩＦＳ、ＢＩＦＳ、およびＲＩＦＳ）の実際値は物理層（Ｐｈｙｓｉｃａｌ  ｌａｙｅｒ）にしたがい決定される。例えば、２．４ＧＨｚ物理層を使用する場合に、前記ＩＦＳ等は次の（表１）のように定義される。ここで、ｐＰＨＹＭＩＦＳＴｉｍｅは連続するフレーム間の時間を意味し、ｐＰＨＹＳＩＦＳＴｉｍｅはＲＸ−ｔｏ−ＴＸ転換時間（ｒｅｃｅｉｖｅ−ｔｏ−ｔｒａｎｓｍｉｔ  ｔｕｒｎａｒｏｕｎｄ  ｔｉｍｅ）を意味する。そして、ｐＣＣＡＤｅｔｅｃｔＴｉｍｅはＣＣＡ感知時間（Ｃｌｅａｒ  Ｃｈａｎｎｅｌ  Ａｓｓｅｓｓｍｅｎｔ  ｄｅｔｅｃｔｉｏｎ  ｔｉｍｅ）を意味する。
【００４１】
【表１】
2008512033.tif 000003
Ｉｍｍ−ＡＣＫフレームおよびＤｌｙ−ＡＣＫフレームはＡＣＫを要求する以前フレームの伝送が終わった後、ＳＩＦＳが経過した後に伝送される。そして、ＭＩＦＳはＮｏ−ＡＣＫまたはＤｌｙ−ＡＣＫ  ｐｏｌｉｃｙを有するよう設定されたあるフレームとそれと連続されるフレームの間に許容される時間として使用される。
【００４２】
一方、ＣＴＡＰの間ｓｒｃ  ＤＥＶがＩｍｍ−ＡＣＫを有するよう設定されたフレームを伝送した後、所定のタイムアウト時間の間、Ｉｍｍ−ＡＣＫの伝送を受けなければ前記フレームを再伝送する。ＲＩＦＳはこのように一つのフレームを送ってそのフレームを改めて再伝送されるまで所要されるタイムアウト時間である。
【００４３】
ＩＥＥＥ８０２．１５．３標準によるＭＡＣフレーム４００は図４で図示したように、ＭＡＣヘッダ（ＭＡＣ  ｈｅａｄｅｒ；５００）とＭＡＣフレームボディ（ＭＡＣ  ｆｒａｍｅ  ｂｏｄｙ；６００）で構成されるが、このようにＩＥＥＥ８０２．１５．３標準では時間的に先んじるフィールドを右側から示す。
【００４４】
ＭＡＣフレーム４００はデータフレーム、コントロールフレーム、ＡＣＫなどと同じようにＭＡＣヘッダを具備するすべてのフレームを示す。
【００４５】
ＭＡＣフレームボディ６００は実際データが記録される可変長のＦｒａｍｅｐａｙｌｏａｄフィールド６１０と、ＭＡＣフレーム４００に対するエラーをチェックするＦＣＳ（ｆｒａｍｅ  ｃｈｅｃｋ  ｓｅｑｕｅｎｃｅ）フィールド６２０で構成される。
【００４６】
そして、ＭＡＣヘッダ５００はＦｒａｍｅ  ｃｏｎｔｒｏｌフィールド５１０と、ピコネットに対する固有の識別子が記録されるＰＮＩＤフィールド５２０と、ＭＡＣフレームを受信するデバイスのＩＤが記録されるＤｅｓｔＩＤフィールド５３０と、ＭＡＣフレームを送信するデバイスのＩＤが記録されるＳｒｃＩＤフィールド５４０と、ＭＳＤＵを断片化（ｆｒａｇｍｅｎｔａｔｉｏｎ）と組立（ａｓｓｅｍｂｌｅ）するために使用される情報が記録されるＦｒａｇｍｅｎｔａｔｉｏｎ  ｃｏｎｔｒｏｌフィールド５５０と、ＣＴＡを区分するためにＰＮＣ（Ｐｉｃｏｎｅｔ  Ｃｏｏｒｄｉｎａｔｏｒ）によって付与されるストリームインデックスが記録されるＳｔｒｅａｍ  ｉｎｄｅｘフィールド５６０を含み得る。
【００４７】
Ｆｒａｍｅ  ｃｏｎｔｒｏｌフィールド５１０はまた細部的なフィールドに分けられるが、プロトコルバージョンが記録されるＰｒｏｔｏｃｏｌ  ｖｅｒｓｉｏｎフィールド５１１と、フレームの類型（ビーコンフレーム、ＡＣＫフレーム、ｃｏｍｍａｎｄフレーム、データフレーム等）が記録されるＦｒａｍｅ  ｔｙｐｅフィールド５１２と、ＭＡＣフレームに保安が適用されたのかの可否が記録されるＳＥＣフィールド５１３と、送信するＭＡＣフレームに対するＡＣＫの類型（Ｉｍｍ−ＡＣＫ、Ｎｏ−ＡＣＫ、Ｄｌｙ−ＡＣＫ等）が記録されるＡＣＫ  Ｐｏｌｉｃｙフィールド５１４と、フレームに対する再伝送回収が記録されるＲｅｔｒｙフィールド５１５と、Ｍｏｒｅ  ｄａｔａ  フィールド５１６と、予備フィールドのＲｅｓｅｒｖｅｄフィールド５１７を含み得る。
【００４８】
ここで、Ｍｏｒｅ  ｄａｔａ  フィールド５１６は伝送されるデータがさらに存在するのかの可否（すなわち、現在フレームが最後のフレームなのかの可否）を示し表示するフィールドである。Ｍｏｒｅ  ｄａｔａ  フィールド５１６は一つのビットとして表現されるが、ｓｒｃ  ＤＥＶが残りのＣＴＡ上の残余チャンネル時間を使用しようとしない場合、すなわちｓｒｃ  ＤＥＶが伝送する最後ＭＡＣフレームに対しては０と指定され、これ以外の場合には１と指定される。しかし、これは一つの実施形態であって反対に最後ＭＡＣフレームに対し１と、それ以外の場合に０と指定し得る。したがって、本明細書の詳細な説明では前者の例にしたがい説明するが、本明細書の特許請求範囲では、前記最後ＭＡＣフレームに対し使用されるビットは「第１ビット」と、以降伝送されるフレームがさらに存在する場合は「第２ビット」として表現するものである。
【００４９】
従来のＩＥＥＥ８０２．１５．３標準によれば、Ｍｏｒｅ  ｄａｔａ  フィールド５１６が０と設定されたＭＡＣフレームを受信したｄｅｓｔ  ＤＥＶは該当ＣＴＡの残った時間にこれ以上受信するフレームがないため、電力節約モード（ｐｏｗｅｒ  ｓａｖｅ  ｍｏｄｅ）に転換するようになる。
【００５０】
これとは異なり、本発明では、Ｍｏｒｅ  ｄａｔａ  フィールド５１６が０と設定されたＭＡＣフレームを受信したｄｅｓｔ  ＤＥＶは所定の時間を待機した後に、ｓｒｃ  ＤＥＶに直ちにＭＡＣフレームを伝送し得るようにする。このように、本発明ではＭｏｒｅ  ｄａｔａ  フィールド５１６の使用法を従来のＩＥＥＥ８０２．１５．３標準で定義された内容と異にすることによって、ＭＡＣプロトコルで一部フィールドの変更を加えなくても両方向ＣＴＡを支援し得るようにする。以下で、ｓｒｃ  ＤＥＶが伝送権を有する場合を「モード１」と、ｄｅｓｔ  ＤＥＶが伝送権を有する場合を「モード２」と定義する。本発明ではこのように与えられたＣＴＡの間にモード１とモード２が交代しつつ、データを伝送し得る。
【００５１】
図５は本発明の一実施形態によるデータ伝送過程を図示したフローチャートである。ここで、ｓｒｃ  ＤＥＶであるＤＥＶ１  １００は自身に割り当てられたＣＴＡの間、ｄｅｓｔ  ＤＥＶであるＤＥＶ２  ２００またはピコネット内の他のデバイスにデータを伝送し得る。
【００５２】
ＤＥＶ１  １００がＤＥＶ２  ２００にＭＡＣの上位層データを伝送しようとする状況を仮定する。ＭＡＣの上位層データは図５の例ではＴＣＰデータ１およびＴＣＰデータ２に該当する。
【００５３】
まず、ＤＥＶ１  １００がＤＥＶ２  ２００に２個のデータフレームからなるＴＣＰデータ１を送ろうとする。ＴＣＰデータ１は複数のデータフレームに分けられるため、それぞれのデータフレームをＤＥＶ２  ２００に伝送しなければならない。ＤＥＶ１  １００はＭｏｒｅ  ｄａｔａフィールドが１と設定されたデータフレーム１をＤＥＶ２  ２００に伝送する（Ｓ１）。
【００５４】
もし、データフレーム１がＩｍｍ−ＡＣＫ  ｐｏｌｉｃｙを取れば、ＤＥＶ２  ２００は前記データフレーム１に対するＩｍｍ−ＡＣＫ１を伝送する（Ｓ２）。
【００５５】
続いて、ＤＥＶ１  １００はＤＥＶ２  ２００にＭｏｒｅ  ｄａｔａフィールドが０と設定されたデータフレーム２をＤＥＶ２  ２００に伝送する（Ｓ３）。
【００５６】
Ｍｏｒｅ  ｄａｔａフィールドが０と設定されたのは、ＤＥＶ１  １００がＤＥＶ２  ２００またはピコネット内の他のデバイスにこれ以上送るフレームがないためである。
【００５７】
ＤＥＶ２  ２００は前記データフレーム２に対するＩｍｍ−ＡＣＫ２を伝送する（Ｓ４）。Ｓ１０ないしＳ４０でＩｍｍ−ＡＣＫ  ｐｏｌｉｃｙを利用することにしたが、Ｄｌｙ−ＡＣＫ  ｐｏｌｉｃｙを使用することもできる。もし、Ｄｌｙ−ＡＣＫ  ｐｏｌｉｃｙを使用すれば、Ｓ２０段階は省略され、Ｓ４０段階でＤＥＶ２  ２００はＤｌｙ−ＡＣＫをＤＥＶ１  １００に伝送するようになる。
【００５８】
ＤＥＶ１  １００からＭｏｒｅ  ｄａｔａフィールドが０と設定されたデータフレーム２の伝送を受けたＤＥＶ２  ２００はＩｍｍ−ＡＣＫ２を伝送した時から所定の臨界時間が経過すればデータ伝送権を引き渡される。本発明で、ｓｒｃ  ＤＥＶであるＤＥＶ１が伝送権を有する状態をモード１であると定義すれば、ｄｅｓｔ  ＤＥＶであるＤＥＶ２が伝送権を引き渡された状態をモード２と定義することができる。
【００５９】
前記臨界時間はＴＩＦＳ（Ｔｗｏ−ｗａｙ  Ｉｎｔｅｒｆｒａｍｅ  Ｓｐａｃｅ）と定義される。データフレーム２がＩｍｍ−ＡＣＫ  ｐｏｌｉｃｙを取りＭｏｒｅ  ｄａｔａフィールドが０と設定された場合、ＤＥＶ１  １００これ以上送るデータがないとしてもＤＥＶ２はＴＩＦＳの分だけに待った後にデータフレームを伝送する。その理由はＤＥＶ２  ２００が伝送したＩｍｍ−ＡＣＫ２をＤＥＶ１  １００が受信できない場合、ＤＥＶ１  １００がデータフレーム２の再伝送を試みることができるためである。
【００６０】
したがって、Ｉｍｍ−ＡＣＫ  ｐｏｌｉｃｙが使用される場合には、ＴＩＦＳはＤＥＶ１  １００がデータフレームを再伝送する時間のＲＩＦＳより多少長いように選択されなければならない。本発明ではＴＩＦＳはＲＩＦＳより多少大きい値、例えばＲＩＦＳ＋ｐＰＨＹＳＩＦＳＴｉｍｅと定義し得る。
【００６１】
ただし、このようにＤＥＶ２  ２００がＴＩＦＳの間待機するのは、Ｍｏｒｅ  ｄａｔａフィールドが０でありＩｍｍ−ＡＣＫ  ｐｏｌｉｃｙ、またはＤｌｙ−ＡＣＫ  ｐｏｌｉｃｙを取るデータフレームを受信する場合であり、Ｍｏｒｅ  ｄａｔａフィールドが０であり、Ｎｏ−ＡＣＫ  ｐｏｌｉｃｙを取るデータフレームを受信する場合にはＳＩＦＳ後、必要なデータフレームを直ちに送れば良い。この場合にはＤＥＶ１  １００が再伝送する可能性がないため、データを受信した後伝送するのに要求されるＲＸ−ｔｏ−ＴＸ転換時間、すなわちＳＩＦＳの経過の分だけを待つものである。
【００６２】
このように、ＤＥＶ２  ２００はＡＣＫ  ｐｏｌｉｃｙによってＴＩＦＳまたはＳＩＦＳが経過した後に、現在ＤＥＶ１  １００に送るデータが存在する場合には電力節約モードに入るのではなく、準備されたフレーム、例えば、前記ＴＣＰフレーム１に対するＴＣＰレベルのＡＣＫフレームをＤＥＶ１  １００に伝送する（Ｓ５）。このようなＴＣＰレベルのＡＣＫフレームはＭＡＣ端から見れば単純にＭＡＣデータと見えるためデータフレーム３として表示したものである。この場合ＴＣＰレベルのＡＣＫフレームはその大きさが小さくて分けて送る必要がないため一つのデータフレーム３として伝送され、この時ＭＡＣヘッダのＭｏｒｅ  ｄａｔａフィールドは０と設定される。次に、ＤＥＶ１  １００はデータフレーム３に対するＩｍｍ−ＡＣＫ３を伝送する（Ｓ６）。
【００６３】
そして、ＤＥＶ１  １００は受信したデータフレーム３のＭｏｒｅ  ｄａｔａフィールドが０と設定されているため、改めて伝送権を引き渡される。したがって、ＴＩＦＳ（データフレーム３のＡＣＫ  ｐｏｌｉｃｙがＩｍｍ−ＡＣＫの代わりにＮｏ−ＡＣＫであれば、ＳＩＦＳになる）の間待機した後に改めてデータフレーム４を伝送し（Ｓ７）、ＤＥＶ２  ２００からＩｍｍ−ＡＣＫ４を受信する（Ｓ８）。
【００６４】
以上では、伝送権を引き渡されたデバイスに伝送するデータが存在する場合を例にあげたが、もし送るデータが存在しなければ、Ｍｏｒｅ  ｄａｔａフィールドが０と設定されＭＡＣヘッダのみで構成されたフレーム（以下、ＴＯＫＥＮフレームという）を伝送することによって相手デバイスに伝送権を引き渡す。
【００６５】
この後でもＣＴＡ上の残余時間が存在する間には以上のような過程を繰り返すようになる。
【００６６】
図６は本発明の一実施形態による無線デバイス（ＤＥＶ）の構成を示すブロック図である。無線デバイス１００・２００は伝送権判断モジュール１１０と、ＭＡＣモジュール１２０と、上位層モジュール１３０と、ＰＨＹモジュール１４０と、制御モジュール１５０を含み構成され得る。
【００６７】
伝送権判断モジュール１１０は、データフレームが受信された場合にＭＡＣモジュール１２０で判読されたＭｏｒｅ  ｄａｔａ  フィールド５１６の値の伝達を受け、その値が「現在データフレームが最後のデータであることを示す値」、すなわち０である場合にはＰＨＹモジュール１４０からデータフレームが受信された後、所定の臨界時間の間チャンネルがｉｄｌｅであるのかを判断する。そして、チャンネルがｉｄｌｅである状態で前記臨界時間が経過すれば、モードが転換されたことを制御モジュール１５０に伝達する。
【００６８】
ＭＡＣモジュール１２０はＭＡＣ層（Ｍｅｄｉａ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ  Ｌａｙｅｒ）での動作を管掌する。すなわち、上位層モジュール１３０からＭＳＤＵ（図４のＦｒａｍｅ  ｐａｙｌｏａｄに該当）の伝達を受け、ここに図４に図示したＭＡＣヘッダ５００を付着して、その結果をＰＨＹモジュール１４０に伝達する。
【００６９】
また、ＭＡＣモジュール１２０はＰＨＹモジュール１４０によって受信されたデータフレームのＭＡＣヘッダを判読した後ＭＡＣヘッダを除去し、その結果を上位層モジュール１３０に伝達する。ＰＨＹモジュール１４０によって受信されたフレームがＩｍｍ−ＡＣＫのようにＭＡＣヘッダのみ存在するフレームである場合には上位層モジュール１３０に伝達されることはない。そして、ＭＡＣモジュール１２０はＭＡＣヘッダのうちＭｏｒｅ  ｄａｔａ  フィールド５１６の値を判読して、伝送権判断モジュール１１０に伝達する。
【００７０】
上位層モジュール１３０はＭＳＤＵを生成してＭＡＣモジュール１２０に伝達し、ＭＡＣモジュール１２０からＭＡＣヘッダが除去されたデータの伝達を受ける。このような上位層モジュール１３０はＬＬＣ層（Ｌｏｇｉｃａｌ  Ｌｉｎｋ  Ｌａｙｅｒ）以上のネットワーク層、例えばＴＣＰ／ＩＰ層を管掌する。
【００７１】
ＰＨＹモジュール１４０は物理層（Ｐｈｙｓｉｃａｌ  Ｌａｙｅｒ）での動作を管掌する。すなわち、ＭＡＣモジュール１２０からＭＰＤＵ（ＭＡＣ  Ｐｒｏｔｏｃｏｌ  Ｄａｔａ  Ｕｎｉｔ）の伝達を受けＰＰＤＵ（Ｐａｃｋｅｔ  Ｐｒｏｔｏｃｏｌ  Ｄａｔａ  Ｕｎｉｔ）を生成し、これを含む無線信号を生成して伝送する。
【００７２】
また、無線媒体を介して伝えられる信号を受信して加工した後、これをＭＡＣモジュール１２０に伝達する。ＰＨＹモジュール１４０はまた細分化して、ベースバンドプロセッサとＲＦ（無線周波数）モジュールに細分化され得る。
【００７３】
制御モジュール１５０は無線デバイス１００・２００内の他のモジュールの動作を制御するが、中央処理ユニット（ＣＰＵ）、マイコン（マイクロコンピュータ）等で具現され得る。制御モジュール１５０は伝送権判断モジュール１１０によって伝送権が転換されたものと判断されれば、前記データフレームを伝送した他デバイスで伝送されるデータ、すなわちＭＳＤＵが存在するかを判断し、存在すればＭＡＣモジュール１２０にて前記ＭＳＤＵにＭＡＣヘッダを生成／付加してデータフレームを生成する。
【００７４】
この時、前記生成されたデータフレームが伝送される最後のフレームならばＭｏｒｅ  ｄａｔａ  フィールド５１６は０と設定され、最後のフレームでなければ１と設定される。そして、ＰＨＹモジュール１４０を通して生成されたデータフレームを前記他デバイスに伝送する。
【００７５】
一方、制御モジュール１５０は前記伝送権が転換されたものと判断され、前記伝送されるデータが存在しなければ、前記他デバイスに伝送権を引き渡すフレーム、すなわちＴＯＫＥＮフレームを伝送するよう前記ＭＡＣモジュールおよびＰＨＹモジュールを制御する。
【００７６】
今までの説明で、「モジュール」はソフトウェア構成要素またはＦＰＧＡ（ｆｉｅｌｄ−ｐｒｏｇｒａｍｍａｂｌｅ  ｇａｔｅ  ａｒｒａｙ）またはＡＳＩＣ（ａｐｐｌｉｃａｔｉｏｎ−ｓｐｅｃｉｆｉｃ  ｉｎｔｅｇｒａｔｅｄ  ｃｉｒｃｕｉｔ）のようなハードウェア構成要素を意味し、特定の機能を遂行する。しかし、モジュールはソフトウェアまたはハードウェアに限定される意味ではない。モジュールはアドレッシングすることができる保存媒体にあるように構成され得るが、またはそれ以上のプロセッサを実行させるよう構成され得る。
【００７７】
モジュール内で提供されている機能はさらに細分化されたモジュールによって具現され得、複数のモジュールを合わせて特定の機能を遂行することで具現することもできる。それだけでなく、構成要素およびモジュールはシステム内の一つまたはそれ以上のコンピュータを実行させるように具現され得る。
【００７８】
図７は本発明の全体動作を説明するフローチャートである。
【００７９】
まず、ＤＥＶ１  １００はチャンネル時間を要請するコマンドフレーム、すなわちｃｈａｎｎｅｌ  ｔｉｍｅ  ｒｅｑｕｅｓｔフレームを生成してＰＮＣに伝送する。ＰＮＣは前記伝送を受けたコマンドフレームに存在する情報を利用して、ビーコンフレームを生成しピコネットのメンバであるＤＥＶにビーコンフレームをブロードキャスティングする。この時、ｓｒｃ  ＤＥＶであるＤＥＶ１  １００およびｄｅｓｔ  ＤＥＶであるＤＥＶ２  ２００も前記ビーコンフレームを受信するようになる（Ｓ１０）。
【００８０】
前記ビーコンフレームには図１で図示したように少なくとも一つ以上のＣＴＡブロックが存在し、ＣＴＡブロックには例えば、ＣＴＡ開始時間、ＣＴＡ持続時間、ＣＴＡの間データを送信するｓｒｃ  ＤＥＶ（ＤＥＶ１  １００）と受信するｄｅｓｔ  ＤＥＶ（ＤＥＶ２  ２００）のＩＤなどが含まれる。
【００８１】
この後、ＤＥＶ１  １００とＤＥＶ２  ２００が通信するＣＴＡの開始時間になれば（Ｓ１５のはい）、ＤＥＶ１  １００はＤＥＶ２  ２００にデータフレームを伝送する（Ｓ２５、Ｓ６５）。この時、前記伝送されるフレームが最後のフレームでなければ（Ｓ２０のいいえ）、データフレームのＭＡＣヘッダ５００に存在するＭｏｒｅ  ｄａｔａ  フィールド５１６を１と設定しデータフレームを伝送し（Ｓ６５）、改めて次のデータフレームを伝送するためにＳ２０に戻る。
【００８２】
伝送されるフレームが最後のフレームならば（Ｓ２０の例）、Ｍｏｒｅ  ｄａｔａ  フィールド５１６を０と設定して、データフレームを伝送し（Ｓ２５）、Ｓ２６段階に進行する。
【００８３】
一方、ＤＥＶ１  １００からＭｏｒｅ  ｄａｔａフィールドが０と設定されたデータフレームを受信したＤＥＶ２  ２００は、前記受信されたデータフレームのＡＣＫ  ｐｏｌｉｃｙをチェックしてＮｏ−ＡＣＫ  ｐｏｌｉｃｙでなければ（Ｓ２６のいいえ）、ＤＥＶ１  １００にＡＣＫ（Ｉｍｍ−ＡＣＫ、またはＤｌｙ−ＡＣＫ）を伝送し（Ｓ２７）、ＡＣＫを伝送した以降にＴＩＦＳの間待機して、チャンネルがｉｄｌｅなのかをチェックする（Ｓ３０）。
【００８４】
そして、前記チャンネルがｉｄｌｅある状態で前記ＴＩＦＳが経過すれば始めてＤＥＶ２  ２００はＤＥＶ１  １００に対するデータ伝送権を有するようになる。もし、ＤＥＶ２  ２００がＡＣＫを伝送しＴＩＦＳ時間分だけ待機する間ＤＥＶ１  １００からデータフレームの再伝送があれば、これに対しＡＣＫを再伝送する。
【００８５】
Ｓ２６段階の判断結果、Ｎｏ−ＡＣＫ  ｐｏｌｉｃｙならば（Ｓ２６のはい）、ＤＥＶ２  ２００はＳ２５段階でのデータフレームを受信した後ＤＥＶ１  １００に対するデータ伝送権を有する。ここで、ＤＥＶ２  ２００がデータフレーム受信後、他のデータフレーム伝送時までは少なくともＳＩＦＳ時間分だけ所要される。
【００８６】
データ伝送権を有するようになったＤＥＶ２  ２００は始めてＤＥＶ１  １００にデータを伝送することができるが、もし、送るデータがないならば（Ｓ３５のいいえ）、Ｍｏｒｅ  ｄａｔａフィールドが０と設定されたＭＡＣヘッダのみで形成されたＴＯＫＥＮフレームをＤＥＶ１に伝送する（Ｓ５０）。これはＤＥＶ２  ２００がＤＥＶ１  １００に伝送するデータがないことを知らせるものである。ＴＯＫＥＮフレームに対するＡＣＫ  ｐｏｌｉｃｙはＡＣＫを必要とするものとし得るが、チャンネル内のトラフィック減少のためにＮｏ−ＡＣＫとするのが好ましい。
【００８７】
ＴＯＫＥＮフレームがＮｏ−ＡＣＫ  ｐｏｌｉｃｙを有する場合には、ＴＯＫＥＮフレームを受信した後にＴＩＦＳを待つ必要なく直ちに伝送権を引き渡すようになる。
【００８８】
伝送権を引き渡されたＤＥＶ１  １００も同様に伝送するデータが存在するかを判断し、存在すれば（Ｓ５５のはい）Ｓ２０段階に戻り、存在しなければＭｏｒｅ  ｄａｔａフィールドが０と設定されたＴＯＫＥＮフレームを伝送し（Ｓ６０）、Ｓ３５段階に戻る。
【００８９】
Ｓ３５段階で、ＤＥＶ２  ２００がＤＥＶ１  １００に伝送するデータが存在すれば（Ｓ３５のはい）、ＤＥＶ１  １００はＤＥＶ２  ２００にデータフレームを伝送する（Ｓ４５、Ｓ７０）。この時、前記伝送されるフレームが最後のフレームでなければ（Ｓ４０のいいえ）、Ｍｏｒｅ  ｄａｔａ  フィールド５１６を１と設定しデータフレームを伝送し（Ｓ７０）、改めて次のデータフレームを伝送するためにＳ３５段階に戻る。
【００９０】
伝送されるフレームが最後のフレームならば（Ｓ４０の例）、Ｍｏｒｅ  ｄａｔａ  フィールド５１６を０と設定して、データフレームをＤＥＶ１  １００に伝送する（Ｓ４５）。次いで、ＤＥＶ１  １００は、前記伝送を受けたデータフレームのＭｏｒｅ  ｄａｔａ  フィールド５１６が０と設定されたことで伝送権が引き渡されることを知るようになる。ＤＥＶ１  １００は前記伝送を受けたデータフレームのＡＣＫ  ｐｏｌｉｃｙをチェックしてＮｏ−ＡＣＫ  ｐｏｌｉｃｙでなければ（Ｓ７５のいいえ）、ＤＥＶ２  ２００にＡＣＫ（Ｉｍｍ−ＡＣＫ、またはＤｌｙ−ＡＣＫ）を伝送し（Ｓ７７、前記ＡＣＫを伝送した後にＴＩＦＳの間待機し、チャンネルがｉｄｌｅであるかをチェックして、前記チャンネルがｉｄｌｅである状態で前記ＴＩＦＳ時間が経過した後にはＳ５５段階で進行する。
【００９１】
Ｓ７５段階の判断結果、Ｎｏ−ＡＣＫ  ｐｏｌｉｃｙならば（Ｓ７５のはい）、ＤＥＶ１  １００はＳ４５段階でのデータフレームを受信した後にはまたデータ伝送権を引き渡される。この後にはＳ５５段階で進行する。
【００９２】
以上のＳ１０ないしＳ７８段階は該当ＣＴＡの開始時間から終了時間までのみ進行され、前記段階のうち任意の段階でＣＴＡの終了時間になれば図７での過程は終了する。
【００９３】
以下では、図８および図９を参照して、従来技術によりＣＴＡで単方向伝送をする場合と、本発明によりＣＴＡで両方向伝送を適用した場合に伝送効率の差異を比較しようとする。
【００９４】
図８は従来の技術により単方向伝送をする場合に対するスーパーフレーム９００構造およびデータ伝送過程を説明するための図である。二つのＤＥＶ、すなわちＤＥＶ１  １００およびＤＥＶ２  ２００がピコネットに存在し、ＴＣＰ／ＩＰを利用して、ＤＥＶ１  １００がＤＥＶ２  ２００にストリームを伝送しようとする。そうすると、ＤＥＶ１  １００からＤＥＶ２  ２００にデータフレームが伝送され、これに対するＡＣＫフレームがＤＥＶ２  ２００からＤＥＶ１  １００に伝送されるものである。データフレーム伝送時、ＭＡＣヘッダに設定されるＡＣＫ  ｐｏｌｉｃｙはＩｍｍ−ＡＣＫ  ｐｏｌｉｃｙとし、スーパーフレームｄｕｒａｔｉｏｎは１０ｍｓ、ＣＡＰは１ｍｓと仮定する。そして、ＭＡＣヘッダの伝送率は２２Ｍｂｐｓ、フレームｐａｙｌｏａｄの伝送率は５５Ｍｂｐｓとする。
【００９５】
まずＤＥＶ１  １００とＤＥＶ２  ２００すべてがｒａｔｅ  ｆａｃｔｏｒを１としたスーパーレートＣＴＡ（ｓｕｐｅｒ−ｒａｔｅ  ＣＴＡ）を要請したとすれば、スーパーフレーム９００は図８のように現れるだろう。図８のようにＣＴＡ  ＩＥとＢＳＩＤ  ＩＥ以外に他のＩＥ（ｉｎｆｏｒｍａｔｉｏｎ  ｅｌｅｍｅｎｔ）は有していないと仮定する。
【００９６】
ビーコン９１０は１０ｂｙｔｅのＭＡＣヘッダ、２１ｂｙｔｅのピコネットｓｙｎｃ  ｐａｒａｍｅｔｅｒｓ、１６ｂｙｔｅのＣＴＡ  ＩＥ（本例では二つのＣＴＡ情報を有しているため）、２０ｂｙｔｅのＢＳＩＤ  ＩＥ（ＢＳＩＤの大きさを１０ｂｙｔｅｓと仮定する）で構成される。（表２）のような計算過程の結果ｍ前記のようなビーコンを伝送するには約０．０１２ｍｓが所要される。
【００９７】
【表２】
2008512033.tif 000004
ＣＴＡ１  ９３０とＣＴＡ２  ９４０のｄｕｒａｔｉｏｎは各々ＤＥＶ１  １００とＤＥＶ２  ２００がＰＮＣに要請したＴＵ（Ｔｉｍｅ  Ｕｎｉｔ）の大きさとＤｅｓｉｒｅｄ  ｎｕｍｂｅｒ  ｏｆ  ＴＵｓにより変わるものである。ＴＵは指定したＡＣＫ  ｐｏｌｉｃｙにより最小限一フレームは伝送し得るようにしなければならない。
【００９８】
ビーコン伝送時間とＣＡＰ９２０を除外した残り時間をすべて各ＤＥＶに割り当てるとすれば、ＤＥＶ１  １００、ＤＥＶ２  ２００すべてｒａｔｅ  ｆａｃｔｏｒが１であるスーパーレートＣＴＡを要請したと仮定したため、図８のようにｓｒｃ  ＤＥＶがＤＥＶ１  １００でありｄｅｓｔ  ＤＥＶがＤＥＶ２  ２００であるＣＴＡ１  ９３０と、ｓｒｃ  ＤＥＶがＤＥＶ２  ２００でありｄｅｓｔ  ＤＥＶがＤＥＶ１  １００であるＣＴＡ２  ９４０が配定されるものである。ＣＴＡ１  ９３０とＣＴＡ２  ９４０のｄｕｒａｔｉｏｎは各々のＤＥＶが要請したＴＵおよびＰＮＣのｃｈａｎｎｅｌ  ｔｉｍｅ  ａｌｌｏｃａｔｉｏｎアルゴリズムにより変わり得る。
【００９９】
ＣＴＡ１  ９３０が始まる時間になればまずにＤＥＶ１  １００がＤＥＶ２  ２００にデータフレーム１  ９５０を伝送する。この時データフレーム１  ９５０のペイロードはＴＣＰ／ＩＰのデータフレームである。最大フレーム長が２０４８ｂｙｔｅｓ（ＭＡＣヘッダは除外）であるため、データフレーム１  ９５０を２０４８ｂｙｔｅｓとすれば、データフレーム１  ９５０の伝送時間は次の（表３）のように０．３０１４ｍｓとなる。
【０１００】
【表３】
2008512033.tif 000005
ＡＣＫ１  ９６０はＤＥＶ２  ２００でＤＥＶ１  １００に送るＡＣＫフレームである。これはＭＡＣ層でＭＡＣのＡＣＫ  ｐｏｌｉｃｙにしたがい伝送されるものである。ＩＥＥＥ８０２．１５．３でＡＣＫフレームはＭＡＣヘッダのみでだけなされているためＡＣＫフレームを伝送するには０．００３６ｍｓがかかるだろう。
【０１０１】
本形態でＭＡＣ層の上位層ではＴＣＰ／ＩＰを利用して伝送するため、ＤＥＶ１  １００はＤＥＶ２  ２００からＴＣＰ／ＩＰレベルのＡＣＫフレームを受けられなければ、これ以上新しいフレームを伝送することができない。ＤＥＶ１  １００がＤＥＶ２  ２００にＴＣＰ／ＩＰを利用してフレームを伝送すれば、ＤＥＶ２  ２００はこれに対するＡＣＫフレームを送らなければならない。これはＭＡＣ層で送るＡＣＫ（例えば、前記Ｉｍｍ−ＡＣＫ）とは別途に、ＭＡＣ層の上位層から伝送されるものであるためＭＡＣ層から見れば他のデータフレームと同様な処理となる。
【０１０２】
図８でデータフレーム２はＤＥＶ２  ２００がＤＥＶ１  １００に伝送するＴＣＰ／ＩＰレベルのＡＣＫフレームを表す。このように、ＤＥＶ２  ２００がＤＥＶ１  １００にデータフレーム２を送ろうとしても自身がｓｒｃで指定されたチャンネル時間になる時まで待たなければならない。したがってＣＴＡ２  ９４０が始まる時間なったときにだけデータフレーム２  ９７０を伝送することができる。ＡＣＫ２  ９８０はＭＡＣ層のＡＣＫ  ｐｏｌｉｃｙにより伝送されるＭＡＣ層レベルのＡＣＫフレームである。
【０１０３】
以上で察し見たように、既存のＩＥＥＥ８０２．１５．３のＣＴＡ方式を使用する場合には１０ｍｓというスーパーフレームの間にＤＥＶ１  １００からＤＥＶ２  ２００に２０４８ｂｙｔｅｓの大きさのフレーム一つが伝送され、反対にＤＥＶ２  ２００からＤＥＶ１  １００にも２０４８ｂｙｔｅｓのフレーム一つだけが伝送される。
【０１０４】
図９は与えられたＣＴＡ内で両方向伝送を支援する本発明によるデータ伝送過程を説明するための図である。図８と同様に、ビーコン伝送時間とＣＡＰ９２０を除外した残り時間をすべてＤＥＶに割り当てると仮定する。
【０１０５】
そして、データフレーム１  ９５０はＤＥＶ１  １００からＤＥＶ２  ２００に送るＴＣＰ／ＩＰデータフレームであり、データフレーム２  ９７０はＤＥＶ２  ２００からＤＥＶ１  １００に送るＴＣＰ／ＩＰレベルのＡＣＫフレームである。データフレーム２  ９７０が伝送されるまでの処理時間（ｐｒｏｃｅｓｓｉｎｇ  ｔｉｍｅ）を考慮して、中間にＴＯＫＥＮフレーム９９０一つが伝送されると仮定すれば、ＤＥＶ１  １００からＤＥＶ２  ２００にＴＣＰ／ＩＰデータフレームを一つ送り、これに対してＴＣＰ／ＩＰレベルのＡＣＫフレームを受けるまでかかる時間（Ａ）を計算してみれば（表４）のとおりである。
【０１０６】
【表４】
2008512033.tif 000006
したがって１０ｍｓのスーパーフレーム９００の間ビーコン９１０伝送時間とＣＡＰ９２０を除外した値を前記時間（Ａ）で割れば次の（表５）での結果のとおりである。
【０１０７】
【表５】
2008512033.tif 000007
この結果によれば、単位スーパーフレームの間、ＤＥＶ１  １００はＤＥＶ２  ２００に２０４８ｂｙｔｅｓの大きさのフレームを１３個送ることでき、同様にこの時間の間にＤＥＶ２  ２００もＤＥＶ１  １００に２０４８ｂｙｔｅｓのフレーム１３個送ることができる。
もちろん、前でＣＴＡ  ｒａｔｅ  ｆａｃｔｏｒを１を超過する数に指定してＰＮＣにチャンネル時間を要請すると図８でよりは多い量のデータを伝送し得るものである。
しかし、ｒａｔｅ  ｆａｃｔｏｒやＰＮＣのチャンネル時間割当アルゴリズムによりチャンネル時間の配置が変わることがあり、また常にチャンネル時間を最大で使用し得るという保障がないため、本発明と同じように両方向伝送を支援するチャンネル時間を利用するのがさらに効率的であるといえる。
【０１０８】
以上添付された図面を参照し、本発明の実施形態を説明したが、本発明が属する技術分野の通常の知識を有する者は本発明がその技術的思想や必須的な特徴を変更せず、他の具体的な形態で実施され得るということを理解するであろう。
【０１０９】
そのため以上で記述した実施形態はすべての面で例示的なものであり、限定的ではないものと理解しなければならない。本発明の範囲は前記詳細な説明よりは特許請求の範囲によって示され、特許請求の範囲の意味および範囲そしてその均等概念から導出されるすべての変更または変形された形態が本発明の範囲に含まれると解釈されなければならない。
【発明の効果】
【０１１０】
本発明によれば、既存のＩＥＥＥ８０２．１５．３標準によるＭＡＣプロトコルを変化させなくても与えられたＣＴＡの間二つのデバイスが両方向に通信することができるようになる。
【０１１１】
本発明によれば、ピコネット上のデバイスが、与えられたＣＴＡをより効率的に利用することによってピコネット全体のスループットを向上させるという効果がある。
【図面の簡単な説明】
【０１１２】
【図１】従来のスーパーフレームの構造を示す図である。
【図２】従来のチャンネル時間割当てを要請する過程を示す図である。
【図３】従来の非同期データを伝送する過程を示す図である。
【図４】ＩＥＥＥ８０２．１５．３標準によるＭＡＣフレームの構造を示す図である。
【図５】本発明の一実施形態によるチャンネル時間内にデバイス間に両方向にデータを送受信する例を示す図である。
【図６】本発明の一実施形態による無線デバイスの構成を示すブロック図である。
【図７】本発明の一実施携帯による全体動作を説明するフローチャートである。
【図８】従来の単方向伝送をする場合に対しスーパーフレーム構造及びデータ伝送過程を示す図である。
【図９】本発明による両方向伝送をする場合のデータ伝送過程を示す図である。
【図１】
2008512033.tif 000008
【図２】
2008512033.tif 000009
【図３】
2008512033.tif 000010
【図４】
2008512033.tif 000011
【図５】
2008512033.tif 000012
【図６】
2008512033.tif 000013
【図７】
2008512033.tif 000014
【図８】
2008512033.tif 000015
【図９】
2008512033.tif 000016
【国際調査報告】
2008512033.tif 000017
2008512033.tif 000018