JP2009207042A - 通信装置、通信方法及びデータ構造 - Google Patents

Abstract

【課題】ＷＵＳＢにおいてＷｉＭｅｄｉａ＿Ａｌｌｉａｎｃｅで定義された共通のプラットフォームを用いる場合に、予約規定数内のＭＡＳを確保している他のデバイスに対して、ＭＡＳの譲渡あるいは交換等によって予約されたＭＡＳを調整する手段がなかった。
【解決手段】ＷｉＭｅｄｉａ＿Ａｌｌｉａｎｃｅに基づいてＭＡＳ（Medium Access Slot）を予約して通信を行うデバイス１ｅであって、他のデバイス１ａ〜１ｄが予約したＭＡＳを自装置が利用できるように予約変更することを要求する交渉要求情報を生成する制御部１０と、交渉要求情報を他の通信装置１ａ〜１ｄへ送信し、他の通信装置１ａ〜１ｄから予約変更を承諾する応答を受信するホストコントローラ５０と、を備え、制御部１０は、当該応答後、他の通信装置１ａ〜１ｄが予約したＭＡＳを自装置が利用するＭＡＳとして設定する。
【選択図】図１

Description

本発明は、ＷｉＭｅｄｉａ＿Ａｌｌｉａｎｃｅで定義されているＭＡＳ（Medium Access Slot）の予約方法に関する。

ワイヤレスＵＳＢ（Universal Serial Bus）（以下、適宜、ＷＵＳＢと記す）では、ＷｉＭｅｄｉａ＿Ａｌｌｉａｎｃｅで定義された共通のプラットフォームを用いて、ＷＵＳＢ独自のスケジュールによるアクセス制御方法が定義されている。ＷｉＭｅｄｉａ＿Ａｌｌｉａｎｃｅでは、スーパーフレーム（SuperFrame）は、２５６個のＭＡＳ（以下、適宜、スロットともいう）から構成される。２５６個のＭＡＳは、ビーコン（Beacon）を送受信する領域（ＢＰ：Beacon Period、以下、「ビーコン期間」という）と各デバイスがデータフレームを送受信する領域（データフレーム領域）とに分けられる。２５６個のＭＡＳは、１６のゾーン（Zone）に分割される。

各デバイスは、ゾーンとゾーン内のＭＡＳの位置によって、予約対象となるＭＡＳを指定し、予めＭＡＳを予約してデータフレームの送受信に利用する。各ゾーン内でＭＡＳを予約する場合、予約を要求した順番にＭＡＳが確保されている。すなわち、早い順にＭＡＳが確保されることになる。そのため、複数のデバイスが同じ系にある場合、自デバイスに必要なＭＡＳを確保できない場合がある。ＭＡＳの予約には、一つのデバイスが確保できるＭＡＳの数（以下では、「予約規定数」とする）が決められている。予約規定数を超えて確保しているＭＡＳについては、開放することが可能であった。一方、予約規定数以内の数を確保しているＭＡＳについては、相手が開放するのを待つことになっていた。このため、デバイスが増えた場合に、ＭＡＳを十分確保できないデバイスが発生し、データ転送の効率を低下させていた。

また、ＭＡＳを予約する装置が増える毎に、あるいは、ＭＡＳの追加を要求する毎に、各ゾーンの後ろからＭＡＳを予約することが原則である。このため、ＭＡＳが細切れに予約されるという状況が発生し、データ転送の効率を低下させていた。

例えば、図１６のようにＭＡＳが予約されている場合を想定する。デバイス＃Ｅは、ＭＡＳ１０、１１、１４、１５を予約しているが、非連続の状態である。デバイス＃Ｅは、他のデバイス、ここでは、デバイス＃ＤがＭＡＳを開放することを待つことになる。デバイス＃ＤがいなくなるなどしてＭＡＳ８、９、１２、１３が開放されると、デバイス＃Ｅは、あたらにＭＡＳを予約することが可能になり、例えば１２〜１５のＭＡＳを連続して使用可能となる。また、８〜１１のＭＡＳが開放された状態となる。

特許文献１には、ＷＵＳＢにおいて、ＷｉＭｅｄｉａ＿Ａｌｌｉａｎｃｅで定義された共通のプラットフォームのみの実装を行った場合でも、ＷＵＳＢ独自のマイクロスケジュールによるアクセス制御を実現することが可能な無線通信システムが開示されている。

このように、ＷｉＭｅｄｉａ＿Ａｌｌｉａｎｃｅでは、自デバイスを含む通信系の特徴に関係なくＭＡＳを予約する形式を採用していた。そのため、構成しているデバイスにより最適な予約ができない可能性があった。例えば、プリンタ、外部記録媒体など大容量のデータを転送するデバイスによって適切でない場合があった。

このような状況を解消する手段として、スロットの開け渡しがあるが、優先順位の低いＭＡＳについて明け渡しを要求することができるものの、優先優位の高いＭＡＳの開け渡しを要求することができなかった。細切れの状態で予約されたＭＡＳを交換することによって、データ転送効率が向上する場合であっても、予約されたＭＡＳを調整する手段がなかった。特許文献２には、データスロットの予約過程で起こり得るような予約争いを検出し解決する手法が開示されている。しかし、既に予約されたＭＡＳを調整する手法については言及されていない。
特開２００７−１９６０４号公報 特開２００５−３２３３７５号公報

このように、ＷＵＳＢにおいてＷｉＭｅｄｉａ＿Ａｌｌｉａｎｃｅで定義された共通のプラットフォームを用いる場合に、予約規定数内のＭＡＳを確保している他のデバイスに対して、ＭＡＳの譲渡あるいは交換等によって予約されたＭＡＳを調整する手段がなかった。

本発明に係る通信装置の一態様は、ＷｉＭｅｄｉａ＿Ａｌｌｉａｎｃｅに基づいてＭＡＳ（Medium Access Slot）を予約して通信を行う通信装置であって、他の通信装置が予約したＭＡＳを自装置が利用できるように予約変更することを要求する交渉要求情報を生成する制御部と、前記交渉要求情報を前記他の通信装置へ送信し、他の通信装置から予約変更を承諾する応答を受信するホストコントローラと、を備え、前記制御部は、前記応答後、前記他の通信装置が予約したＭＡＳを自装置が利用するＭＡＳとして設定する。交渉要求情報をビーコンに載せて送信する仕組みを設定することにより、他の通信装置が予約したＭＡＳを自装置で使用できるように働きかけることができる。これにより、他の通信装置がＭＡＳを開放するのを待つだけでなく、積極的に使用できるＭＡＳを増やす、あるいは、効率よく転送するＭＡＳの配列を確保することができる。

また、本発明に係る通信方法の一態様は、ＷｉＭｅｄｉａ＿Ａｌｌｉａｎｃｅに基づいてＭＡＳを予約して通信を行う通信方法であって、第１装置が第２装置によって予約されたＭＡＳを利用できるように予約変更することを要求する交渉要求情報を前記第１装置から送信し、前記交渉要求情報に基づいて、前記第２装置が予約変更の承諾を応答し、前記応答後、前記第２装置が予約したＭＡＳを第１装置が利用する。

さらに、本発明に係るデータ構造は、ＷｉＭｅｄｉａ＿Ａｌｌｉａｎｃｅに基づいてＭＡＳを予約する情報のデータ構造であって、ビーコンに載せるデータフレームを構成し、第１の装置によって予約されたＭＡＳ番号と、第２の装置によって予約された予約ＭＡＳ番号とを相互に交換できるように特定する。このデータ構造を定義することにより、第１装置から第２装置へ予約したＭＡＳの交換を要求する情報要素をビーコンに載せることができる。

本発明によれば、予約規定数内のＭＡＳを確保している他のデバイスに対して、ＭＡＳの譲渡あるいは交換等によって予約されたＭＡＳを調整する手段を提供することが可能となる。これにより、データ転送効率を向上させることができる。

以下、本発明の実施形態について、図面を参照しながら説明する。説明の明確化のため、以下の記載及び図面は、適宜、省略、及び簡略化がなされている。各図面において同一の構成または機能を有する構成要素および相当部分には、同一の符号を付し、その説明を省略する。

本実施形態では、ＷｉＭｅｄｉａ＿Ａｌｌｉａｎｃｅで定義されているＭＡＳ予約の方法に関して、他デバイス（Neighbor）が予約したＭＡＳを自デバイスで使用できるように他デバイスに要求するために、新たにＡｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ ＩＥを定義する。具体的には、Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ ＩＥとして、ＤＲＰ Ｃｈａｎｇｅ ＩＥ（以下、「交渉用ＩＥ」あるいは「交渉要求情報」ともいう）を生成する。交渉用ＩＥを用い、他デバイスが予約したＭＡＳを自デバイスの予約に変えるように交渉し、自デバイスが使用できるＭＡＳを増やす。これにより、自デバイスが転送に必要な帯域あるいは自デバイスの転送の効率を図る帯域を確保する。予約を変える手法として、ＭＡＳを譲渡させる手法と、ＭＡＳを交換する手法との二つを提案する。

ＷｉＭｅｄｉａ＿Ａｌｌｉａｎｃｅでは、ＤＲＰ（分散予約プロトコル）とＰＣＡ（Prioritized Contention Access）の二つの送信方式が規格されている。ＤＲＰは、あらかじめ送信するためにＭＡＳを予約しておき、予約情報をビーコンで他のデバイスに通知し、決められた時間でのみ送信可能な方法である。ＰＣＡは、ビーコン期間とＤＲＰ予約されたＭＡＳ以外で自由に送信できる方法である。ＰＣＡでは、他のデバイスとの送信競合が発生する可能性があり、必ず送信したい時に送信できるとは限らない方法である。ＷＵＳＢでは、ＤＲＰでのデータ転送を使用する。以下、本発明にかかる実施形態の詳細を説明する。

（実施形態１）
図１は、本発明の実施形態１のデバイスの構成例を示す図である。図１では、デバイス１ａ〜１ｅを示し、以降の説明では、デバイス１ｅを自デバイス（自装置）、デバイス１ａ〜１ｄを他デバイス（他の通信装置）として説明する。デバイス１ａ〜１ｅは、ＷＵＳＢを用いて通信を行う通信装置であり、例えば、情報処理装置にＷＵＳＢの通信機能を搭載したものであってもよい。ここでは、デバイス１ｅの詳細な構成例を示しているが、デバイス１ａ〜１ｅは、同様の構成を有するものとする。また、以下の説明では、各デバイスを区別する場合に、デバイス１ａ〜１ｅあるいはデバイス＃Ａ〜＃Ｅというように示すが、区別する必要のない場合、単にデバイス１とする。

デバイス１は、制御部１０、メインメモリ２０、システムチップセット３０、ＰＣＩ（Peripheral Component Interconnect）バス４０、及び、ホストコントローラ５０を備える。制御部１０は、ＷＵＳＢ制御ドライバ１１とＭＡＣ制御ドライバ１２とを含む。メインメモリ２０は、ＩＥ設定領域２１と受信ビーコン格納領域（受信Ｂｅａｃｏｎ格納領域）２２とを含む。システムチップセット３０は、ＰＣＩバスコントローラ３１を含む。ホストコントローラ５０は、内蔵ＣＰＵ（Central Processing Unit）５１、ＰＣＩ Ｉ／Ｆ（インターフェース）５２、ホスト制御レジスタ５３、フレームバッファ５４、デバイス側 Ｉ／Ｆ５５、及び、無線部５６を含む。

制御部１０は、ホストコントローラ５０を含む自デバイス内の各構成要素を制御するＣＰＵである。制御部１０は、自装置のＭＡＳの予約を管理し、必要な帯域を確保するようにＤＲＰ ＩＥ（Distributed Reservation Protocol Information Element）を生成し、ホストコントローラ５０へ送信させる。ＤＲＰ ＩＥについては後述する。また、本実施形態では、制御部１０は、他のデバイスが予約したスロットを利用することを要求する交渉用ＩＥを生成する。交渉用ＩＥの詳細についても後述する。制御部１０は、これらの機能を実現する具体例としてＷＵＳＢ制御ドライバ１１とＭＡＣ制御ドライバ１２とを含む。

ＷＵＳＢ制御ドライバ１１は、データ転送に必要な帯域（ＭＡＳの数量）を算出し、ＭＡＣ制御ドライバ１２へ要求（通知）する。
ＭＡＣ制御ドライバ１２は、ＷＵＳＢ制御ドライバ１１の要求に基づいて、ＭＡＳ予約を行うＤＲＰ ＩＥ及び交渉用ＩＥなどのＩＥ（情報要素）を生成する。

メインメモリ２０は、制御部１０が処理に使う汎用メモリである。ＩＥ設定領域２１は、制御部１０が送信したいＩＥを書き込む領域である。書き込まれたＩＥは、ホストコントローラ５０によって送信される。受信ビーコン格納領域２２は、ホストコントローラ５０が受信したビーコンを書き込む領域である。書き込まれたビーコンは、制御部１０が読み込む。

システムチップセット３０は、制御部１０とメインメモリ２０とのＰＣＩ転送を実行する。ＰＣＩバスコントローラ３１は、ＰＣＩバス４０を制御する。

ＰＣＩバス４０は、汎用バスであり、制御部１０、メインメモリ２０、及び、ホストコントローラ５０との間のデータを転送する。

ホストコントローラ５０は、ＰＣＩバス４０に接続され、自デバイスと他デバイスとのＷＵＳＢ通信を行う。
内蔵ＣＰＵ５１は、ホストコントローラ５０内のＣＰＵ、内部ブロックの制御をおこなう。
ＰＣＩ Ｉ／Ｆ５２は、フレームバッファ５４とＰＣＩバス４０間の転送を実行する。
ホスト制御レジスタ５３は、制御部１０がホストコントローラ５０を制御するためにリード／ライトするレジスタである。

フレームバッファ５４は、デバイス１が送受信するフレーム（データフレーム、ＩＥ）を保持するバッファである。
デバイス側 Ｉ／Ｆ５５は、フレームバッファ５４と無線部５６との転送を実行する。
無線部５６は、ＷＵＳＢの無線通信を行う。

ここで、本発明の実施形態の通信方式の概要について、ＭＡＳの予約方法とＭＡＳの予約におけるコンフリクト解消のメカニズムについて説明する。

＜スーパーフレームとＭＡＳについて＞
ＷｉＭｅｄｉａ＿Ａｌｌｉａｎｃｅでは、スーパーフレームは、６５５３６ｕｓの長さの周期の繰り返しで構成され、２５６個のＭＡＳ（２５６ｕｓ）から構成される。スーパーフレームの単位を繰り返してデータ転送を実現する。スーパーフレームは、冒頭にビーコン期間が設定され、残りがデータフレームとなる。図２にスーパーフレームの構成例を示している。スーパーフレームの先頭、具価的にはスーパーフレームタイマー（Ｓｕｐｅｒ Ｆｒａｍｅ Ｔｉｍｅｒ）がゼロのポイントからからビーコン期間（ＢＰ：Ｂｅａｃｏｎ Ｐｅｒｉｏｄ）が設定されている。ビーコン期間の開始時刻をＢＰＳＴ（Beacon Period Start Time）と呼ぶ。ビーコンは、さまざまな制御用情報を伝達する。

また、データフレーム（DataFrame）は、ビーコン期間以外のＭＡＳが割り当てられ、デバイス間のデータ転送に利用される。

＜ＤＲＰについて＞
分散予約プロトコル（ＤＲＰ）を使って送受信しているすべてのデバイスは、ビーコンにＤＲＰ ＩＥを入れてどのＭＡＳを予約しているかを周辺に通知する。図３に、ＤＲＰ ＩＥのフレームフォーマットを示す。また、図４にゾーンビットマップとＭＡＳビットマップとを説明する構成例を示す。ＭＡＳ予約はＤＲＰ ＩＥ中の次のフィールド値で特定される。Ｔａｒｇｅｔ／Ｏｗｎｅｒ、ＤｅｖＡｄｄｒ、Ｏｗｎｅｒ、Ｒｓｅｒｖａｔｉｏｎ Ｔｙｐｅ、Ｓｔｒｅａｍ Ｉｎｄｅｘ。予約Ｏｗｎｅｒは、予約を開始するデバイスであり、その予約中でフレームトランザクションを開始する。予約Ｔａｒｇｅｔは、予約Ｏｗｎｅｒから、ＭＡＳを予約してもらうデバイスである。ＷＵＳＢでは、予約Ｏｗｎｅｒがホストで、予約Ｔａｒｇｅｔがデバイスに相当することになる。ホストは周囲の他のホストのＢｅａｃｏｎを受信して空いているＭＡＳから自分が使用するＭＡＳを決定してＤＲＰ ＩＥにて周囲に通知する。ＭＡＳ予約が決定すると、ＷＵＳＢ転送（Ｃｏｎｔｒｏｌ転送）にてデバイス＝Ｔａｒｇｅｔが送信するＤＲＰ ＩＥを転送する。デバイスは自信ではＤＲＰ ＩＲは生成せず、ホストから転送されたＤＲＰ ＩＥを自分のＢｅａｃｏｎに入れて送信することになる。従って、ホスト−デバイス間でＮｅｇｏｔｉａｔｉｏｎを行う必要はなく、初めからＲｅｓｅｒｖａｔｉｏｎＳｔａｔｕｓは１になる。

ＤＲＰ ＩＥは、ビーコン中に入れて送信することによって周囲にＭＡＳの使用を宣言するＩＥである。

各デバイス１において、ＭＡＣ制御ドライバ１２とホストコントローラ５０とは、ＤＲＰにおいて次のような役割を果たす。ホストコントローラ５０は、受信ビーコンのＤＲＰ ＩＥを解析する。解析した結果、ＭＡＳのＡｖａｉｌａｂｉｌｉｔｙ情報を作成し、変化があればＭＡＣ制御ドライバ１２に通知する。また、ＤＲＰ予約のＣｏｎｆｌｉｃｔを検出したら、ＭＡＣ制御ドライバ１２に通知する。
ＭＡＣ制御ドライバ１２は、予約するＭＡＳ数（帯域）を決定してホストコントローラ５０に通知する。ホストコントローラ５０は、ＭＡＣ制御ドライバ１２からの通知（要求）に基づいて、送信ビーコンを組み立てて送信する。

次に、本実施形態で新たに定義するＡｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ ＩＥについて説明する。図５は、本実施形態で新たに定義する交渉用ＩＥのフレームフォーマット（ＤＲＰ Ｃｈａｎｇｅ ＩＥ Ｆｒａｍｅ Ｆｏｒｍａｔ）の一例を示す図である。図５に示す交渉用ＩＥのフレームフォーマットは、次の要素を有する。
・Ｅｌｅｍｅｎｔ ＩＤは、ＭＡＳの譲渡または交換を要求するＩＥであることを識別する識別子であり、固定値を用いる。
・Ｌｅｎｇｔｈは、このＩＥ全体のバイト数を示す。
・ＣｏｕｎｔＤｏｗｎは、周囲の他デバイスと同期をとるためのカウントダウン値である。
・Ｏｗｎｅｒ ＤｅｖＡｄｄｒは、交渉を要求しているデバイスのアドレスである。
・Ｔａｒｇｅｔ ＤｅｖＡｄｄｒは，交渉相手のデバイスアドレスである。
・ＤＲＰ Ａｌｌｏｃａｔｉｏｎは、交渉対象のＭＡＳを指定する。２５６個のＭＡＳを１６分割したゾーンとゾーン内の１６ＭＡＳを指定することによって対象を特定する。

デバイスは、図５に示す交渉用ＩＥをビーコン期間に送信することによって、他デバイスへＭＡＳの予約の変更を要求する。ＭＡＳの予約の変更を要求された他デバイスでは、予約の変更に応じる時には、交渉用ＩＥに変更が要求されたＭＡＳを特定する情報をＯｗｎｅｒ ＤｅｖＡｄｄｒともに設定し、応答用ＩＥとして返信することになる。図５に示すデータフォーマットは、交換の予約変更を要求する場合、自デバイスと他デバイスとの間で、それぞれが予約したＭＡＳを交換できるように、予約変更を要求する要求元デバイス、交換が要求される要求先デバイス、交換の対象となるＭＡＳの番号が特定される構造を有する。また、譲渡の場合、予約変更を要求する要求元デバイス、交換が要求される要求先デバイス、譲渡の対象となるＭＡＳの番号が特定される構造を有する。

図６〜図９を用いて自デバイスが他デバイスへ、ＭＡＳの譲渡を要求する動作の概略について説明する。図６は、ＭＡＳの予約状況の一例を示す図である。図６では、一つのゾーンの予約状況を示した図であり、５台のデバイス間でＭＡＳを予約している例を示している。予約の変更を要求するデバイスをデバイス＃Ｅ（図１のデバイス１ｅに相当）、予約の変更を要求されるデバイスをデバイス＃Ｄ（図１のデバイス１ｄに相当）として説明する。上段に示すように、現状の予約状況は、デバイス＃Ｅが１５番目のＭＡＳを予約しているものの、必要なデータ転送の帯域が不足している状態である。中段に示すように、デバイス＃Ｅは、他デバイスがＭＡＳを開放するのを待つのではなく、譲渡交渉を行うことを検討する。ここでは、連続する帯域を確保できるようにデバイス＃Ｄの３つのＭＡＳの譲渡を検討する。下段に示すように、デバイス＃Ｄが交渉に応じて、１２〜１４のＭＡＳの譲渡に応じたため、デバイス＃Ｅは、１２〜１５の４つのＭＡＳを使用することになった。

図７では、デバイス＃Ｅが譲渡交渉するときの交渉用ＩＥの設定と、カウントダウン値（Ｃｏｕｎｔｄｏｗｎ）の様子を示している。デバイス＃Ｅは、交渉用ＩＥのＴａｒｇｅｔ ＤｅｖＡｄｄｒにＭＡＳの譲渡を要求するデバイス＃Ｄのアドレス０１ｈを設定し、ＤＲＰ Ａｌｌｏｃａｔｉｏｎへ譲渡を要求するＭＡＳを設定する。交渉用ＩＥを送信したスーパーフレームをカウントダウン値１０として、カウントダウンを開始する。図７では、カウントダウン値５の時に交渉が成立し、デバイス＃Ｄは、Ｏｗｎｅｒ ＤｅｖＡｄｄｒにデバイス＃Ｅのアドレス０２ｈ設定し、ＤＲＰ Ａｌｌｏｃａｔｉｏｎに譲渡するＭＡＳを設定した応答用ＩＥを送信し始めている。カウントダウン値がゼロになった次のフレームからデバイス＃Ｅはデバイス＃ＤからＭＡＳを譲り受ける。

図８は、交渉成功時のビーコンの更新タイミングを示す図であり、図９は、交渉失敗時のビーコンの更新タイミングを示す図である。デバイス＃Ｅは、スーパーフレーム０の時、カウントダウン値１０であり、ビーコンに交渉用ＩＥを入れて送信し始める。デバイス＃Ｅは、カウントダウン値０になるまで、交渉用ＩＥを入れたビーコンを送信し続ける。図８では、カウントダウン値５において、デバイス＃Ｄが応答用ＩＥをビーコンに入れ、応答し始めている。一度応答した後は、カウントダウン値０になるまで応答を繰り返す。デバイス＃Ｅ、デバイス＃Ｄは、ともにカウントダウン値０でＭＡＳ予約状況を変更したビーコンを送信する。図９では、デバイス＃Ｄからの応答がないため、カウントダウン値０になると、デバイス＃Ｅは、交渉用ＩＥをビーコンに入れるのを止める。また、交渉は成立しなかったので、ビーコンの情報は更新されない。

次に、自デバイスが他デバイスへ予約したＭＡＳの交換を要求する動作の概略について説明する。ＭＡＳを交換する場合について、図１０にＭＡＳの予約状況の一例を示し、図１１に交渉用ＩＥの設定と、カウントダウンの様子を示している。図１０でも図６と同様に５台のデバイス間でＭＡＳを予約している例を示している。図１０において、上段に示すように、デバイス＃Ｅは、非連続のＭＡＳを予約している状況であり、連続するＭＡＳが確保できればデータ転送の効率が向上する。そこで、デバイス＃Ｄが予約しているＭＡＳとの交換を交渉する（図１０の中段）。交換が成立すると、デバイス＃Ｅは、１２〜１５の連続したＭＡＳが使用できることになり、デバイス＃Ｄは、８〜１１の連続したＭＡＳを使用することができるようになる（図１０の下段）。

また、図１１に示すように、デバイス＃Ｅは、交渉用ＩＥのＴａｒｇｅｔ ＤｅｖＡｄｄｒにＭＡＳの交換を要求するデバイス＃Ｄのアドレス０１ｈを設定し、ＤＲＰ Ａｌｌｏｃａｔｉｏｎへ交換を要求するＭＡＳを設定する。また、Ｏｗｎｅｒ ＤｅｖＡｄｄｒに自デバイスのアドレス０２ｈ設定し、ＤＲＰ Ａｌｌｏｃａｔｉｏｎに自デバイスが予約しているＭＡＳであって交換を要求するＭＡＳを設定する。交換用ＩＥを送信したスーパーフレームをカウントダウン値１０として、カウントダウンを開始する。図１１では、カウントダウン値５の時に交渉が成立し、デバイス＃ＤがＴａｒｇｅｔ ＤｅｖＡｄｄｒにデバイス＃Ｅのアドレス０２ｈ設定し、Ｏｗｎｅｒ ＤｅｖＡｄｄｒに自デバイスのアドレス０１ｈを設定し、それぞれのＤＲＰ Ａｌｌｏｃａｔｉｏｎに譲渡するＭＡＳを設定した応答用ＩＥを送信し始めている。カウントダウン値が０になった次のフレームからデバイス＃Ｅとデバイス＃ＤとはＭＡＳを交換する。

続いて、本実施形態の交渉制御動作の詳細を説明する。ここでは、図６または図１０のようなＭＡＳの予約状況を想定して説明する。また、デバイスの構成は、図１に示した構成例を用いる。Ｏｗｎｅｒ側、Ｔａｒｇｅｔ側ともに同様の構成であり、ここでは特に区別せず同じ符号を用いて説明する。

図１２、１３は、ＭＡＳの譲渡または交換を要求するＯｗｎｅｒ側のＭＡＣ制御ドライバの動作例を示すフローチャートである。また、図１４は、ＭＡＳの譲渡または交換を要求されるＴａｒｇｅｔ側のＭＡＣ制御ドライバの動作例を示すフローチャートである。図１５は、Ｏｗｎｅｒ側のホストコントローラの内蔵ＣＰＵの動作例を示すフローチャートである。

まず、Ｏｗｎｅｒ側のＭＡＣ制御ドライバ１２が交渉を要求する動作について説明する。具体的には、図６または図１０におけるデバイス＃Ｅ内の動作である。ＭＡＣ制御ドライバ１２は、メインメモリ２０の受信ビーコン格納領域２２にビーコンが格納されているかを確認する（Ｓ１１）。ビーコンが格納されている場合（Ｓ１１でＹＥＳ）、ＭＡＣ制御ドライバ１２は、受信ビーコンを解析し、ＭＡＳの予約状況を把握しておく（Ｓ１２）。ビーコンが格納されていない場合（Ｓ１１でＮＯ）、ＷＵＳＢ制御ドライバ１１から帯域要求があるか否かを確認する（Ｓ１３）。要求がある場合（Ｓ１３でＹＥＳ）、ＭＡＣ制御ドライバ１２は、現在のＭＡＳの予約状況が要求帯域を満足できるかを判断し（Ｓ１４）、満足できる場合（Ｓ１４でＹＥＳ）、ステップＳ１１へ戻る。

満足できない場合（Ｓ１４でＮＯ）、規定以上にＭＡＳを予約しているデバイスがあるかを確認し（Ｓ１５）、規定以上にＭＡＳを予約しているデバイスがない場合（Ｓ１５でＮＯ）、ステップＳ１１へ戻る。規定以上にＭＡＳを予約しているデバイスがある場合（Ｓ１５でＹＥＳ）、当該デバイスへＭＡＳの譲渡を要求する交渉処理を開始する（Ｓ１６）。譲渡交渉する場合は、次のルールに従って、交渉相手となるデバイスを判断する。ＭＡＳの総数、例えば、２５６個を、ビーコンを送信しているデバイスの総数で割り算した商（交渉可能数）と、自デバイスが予約しているＭＡＳの総和を比較し、予約しているＭＡＳが商より多い場合、譲渡を要求されたデバイスは譲渡交渉に応じなければならない。このルールを適用し、規定以上にＭＡＳを予約しているデバイス、すなわち、交渉可能数を超えてＭＡＳを予約しているデバイスがある場合、交渉相手として選択できることになる。なお、ここでは、ビーコンを送信しているデバイスの総数で割り算した商を交渉可能数としたが、これ以外の数値を用いてもよい。交渉可能数は、予め定めた所定値であってもよい。

ＭＡＣ制御ドライバ１２は、交渉が成立した場合（Ｓ１７でＹＥＳ）、処理を終了し、交渉が成立しなかった場合（Ｓ１７でＮＯ）、他に規定以上にＭＡＳを予約しているデバイスがあるかを確認する（Ｓ１８）。ＭＡＣ制御ドライバ１２は、他に交渉対象となるデバイスがある場合（Ｓ１８でＹＥＳ）、ステップＳ１６からの処理を繰り返し、交渉対象がない場合（Ｓ１８でＮＯ）、ＷＵＳＢ制御ドライバ１１へ要求帯域が確保できないことを通知し（Ｓ１９）、処理を終了する。

また、ＷＵＳＢ制御ドライバ１１から帯域要求がない場合（Ｓ１３でＮＯ）、ＭＡＣ制御ドライバ１２は、ＭＡＳ予約が非連続で、交換交渉ができるデバイスがあるかを確認する（Ｓ２０）。ＭＡＣ制御ドライバ１２は、対象となるデバイスがある場合（Ｓ２０でＹＥＳ）、当該デバイスへＭＡＳの交換を要求する交渉処理を実施して（Ｓ２１）処理を終了し、対象となるデバイスがない場合（Ｓ２０でＮＯ）、ステップＳ１１へ戻る。

続いて、図１３を用いて、図１２のステップＳ１６及びステップＳ２１で行う交渉処理の詳細について説明する。まず、ＭＡＣ制御ドライバ１２は、譲渡または交換の交渉対象となるＭＡＳを決定する（Ｓ３１）。続いて、メインメモリ２０のＩＥ設定領域２１へ、譲渡または交換を要求する交渉用ＩＥを設定する（Ｓ３２）。また、ＭＡＣ制御ドライバ１２は、ＩＥ設定領域２１に格納した交渉用ＩＥのアドレスをホストコントローラ５０内のホスト制御レジスタ５３へ設定し（Ｓ３３）、アドレスが有効であることを示すビット（以下、「有効ビット」ともいう）を１に設定する（Ｓ３４）。有効ビットは、ＭＡＣ制御ドライバ１２及び内蔵ＣＰＵ５１とのいずれもがアクセスできる領域に配置されていればよい。例えば、ホスト制御レジスタ５３内であってもよい。

ＭＡＣ制御ドライバ１２は、有効ビットがホストコントローラ５０の内蔵ＣＰＵ５１によってゼロにクリアされるまで待つ（Ｓ３５）。有効ビットがゼロにクリアされることは、ホストコントローラ５０によって、交渉用ＩＥが送信されたことを示す。ゼロにクリアされたときに（Ｓ３５でＹＥＳ）、ＭＡＣ制御ドライバ１２は、受信ビーコン格納領域２２にビーコンが格納されていることを検出すると、受信ビーコンを読み込む（Ｓ３６）。このとき、ＭＡＣ制御ドライバ１２は、読み込んだ受信ビーコンに交渉相手からの応答が含まれているかを確認することができる。ＭＡＣ制御ドライバ１２は、カウントダウン満了してないとき（Ｓ３７でＮＯ）、ステップＳ３６へ戻る。また、ＭＡＣ制御ドライバ１２は、カウントダウン満了したときであって（Ｓ３７でＹＥＳ）、交渉相手が応答してない場合（Ｓ３８でＮＯ）では、交渉未成立として処理を終了する（Ｓ３９）。さらに、ＭＡＣ制御ドライバ１２は、カウントダウン満了したときであって（Ｓ３７でＹＥＳ）、交渉相手が応答した場合（Ｓ３８でＹＥＳ）、ステップＳ４０へ進む。

ＭＡＣ制御ドライバ１２は、予約更新後のＤＲＰ ＩＥをＩＥ設定領域２１へ設定し（Ｓ４０）、ＩＥ設定領域に格納したＩＥのアドレスをホスト制御レジスタへ設定し（Ｓ４１）、有効ビットを１に設定する（Ｓ４２）。ＭＡＣ制御ドライバ１２は、有効ビットがホストコントローラ５０の内蔵ＣＰＵ５１によってゼロにクリアされるまで待ち（Ｓ４３）、ゼロにクリアされると（Ｓ４３でＹＥＳ）、交渉成立として処理を終了する（Ｓ４４）。

続いて、交渉相手となるデバイスのＭＡＣ制御ドライバ１２の動作を説明する。例えば、図６または図１０におけるデバイス＃Ｄ内の動作である。ＭＡＣ制御ドライバ１２は、受信ビーコン格納領域２２に交渉用ＩＥを含むビーコンがあるか確認する（Ｓ５１）。ＭＡＣ制御ドライバ１２は、交渉用ＩＥを解析し、自分が交渉相手であるかを確認し（Ｓ５２でＹＥＳ）、譲渡、交換のいずれかを判断する（Ｓ５３）。交渉相手ではなく（Ｓ５２でＮＯ）、または、交渉相手であっても譲渡、交換以外が指定されている場合（Ｓ５３でその他）、ステップＳ５１へ戻る。

交渉用ＩＤが譲渡要求であるとき（Ｓ５３で譲渡）、ＭＡＣ制御ドライバ１２は、自デバイスが規定以上にＭＡＳを予約していない場合（Ｓ５４でＮＯ）、ステップ５１に戻る。また、自デバイスが規定以上にＭＡＳを予約している場合（Ｓ５４でＹＥＳ）、譲渡交渉対象のＭＡＳを決定し（Ｓ５５）、ＩＥ設定領域に応答用ＩＥを設定する（Ｓ５６）。また、ＩＥ設定領域に格納した応答用ＩＥのアドレスをホスト制御レジスタ５３へ設定し（Ｓ５７）、有効ビットを１に設定する（Ｓ５８）。ＭＡＣ制御ドライバ１２は、ホストコントローラ５０によって有効ビットがゼロにクリアされるまで待って（Ｓ５９でＹＥＳ）、処理を終了する。

交渉用ＩＤが交換要求であるとき（Ｓ５３で交換）、ＭＡＣ制御ドライバ１２は、交換に応じない場合（Ｓ６０でＮＯ）、ステップ５１に戻る。また、交換に応じる場合（Ｓ６０でＹＥＳ）、交換交渉対象のＭＡＳを決定し（Ｓ６１）、ＩＥ設定領域に応答用ＩＥを設定する（Ｓ６２）。また、ＩＥ設定領域に格納した応答用ＩＥのアドレスをホスト制御レジスタ５３へ設定し（Ｓ６３）、有効ビットを１に設定する（Ｓ６４）。ＭＡＣ制御ドライバ１２は、ホストコントローラ５０によって有効ビットがゼロにクリアされるまで待って（Ｓ６５でＹＥＳ）、処理を終了する。

次に、ホストコントローラ５０内の内蔵ＣＰＵ５１の動作の詳細を図１５を用いて説明する。ここでは、Ｏｗｎｅｒ側の内蔵ＣＰＵ５１の動作を説明する。スーパーフレームの先頭でない場合（Ｓ７１でＮＯ）、内蔵ＣＰＵ５１は、有効ビットが１に設定されているかを確認し（Ｓ７２）、１に設定されてないとき（Ｓ７２でＮＯ）、ステップＳ７１に戻る。有効ビットが１に設定されているとき（Ｓ７２でＹＥＳ）、ＰＣＩ Ｉ／Ｆ５２にＩＥ設定領域２１に格納されているＩＥをフレームバッファ５４に転送するように指示する（Ｓ７３）。ＰＣＩ Ｉ／Ｆ５２は、ホスト制御レジスタ５３に設定されているアドレスを用いてＩＥをフレームバッファ５４へ転送する。内蔵ＣＰＵ５１は、有効アドレスをゼロに設定し（Ｓ７４）、次に送信するビーコンにＩＥを追加しておく（Ｓ７５）。

一方、スーパーフレームの先頭である場合（Ｓ７１でＹＥＳ）、内蔵ＣＰＵ５１は、デバイス側Ｉ／Ｆ５５に自己のスロット（ＭＡＳ）で送信するように指示する（Ｓ７６）。当該応答用のＩＤを次に送信するビーコンをフレームバッファ５４に設定しておく（Ｓ７９）。ビーコン期間が終了していないとき（Ｓ７７でＮＯ）、フレームバッファ５４に受信ビーコンがあるかを確認し（Ｓ８０）、受信ビーコンがない場合（Ｓ８０でＮＯ）、ステップＳ７７に戻る。受信ビーコンがある場合（Ｓ８０でＹＥＳ）、内蔵ＣＰＵ５１は、ＰＣＩ Ｉ／Ｆ５２にフレームバッファ５４に格納されているビーコンを受信ビーコン格納領域２２に転送するように指示し（Ｓ８１）、ステップＳ７７に戻る。

ビーコン期間が終了するとき（Ｓ７７でＹＥＳ）、交渉用ＩＥを送信しているかを確認し（Ｓ７８）、送信している場合（Ｓ７８でＹＥＳ）、カウントダウン値（交渉用ＩＥ内のＴｒａｄｅ Ｃｏｕｎｔｄｏｗｎ）を１デクリメントし（Ｓ８２）、カウントダウン値がゼロ以上である場合（Ｓ８３でＹＥＳ）、次に送信するビーコンに交渉用ＩＥを入れ、ゼロ未満である場合（Ｓ８３でＮＯ）、次に送信するビーコンには交渉用ＩＥを入れない（Ｓ８５）。内蔵ＣＰＵ５１は、次に送信するビーコンをフレームバッファ５４に設定しておく（Ｓ７９）。なお、Ｔａｒｇｅｔ側の内蔵ＣＰＵ５１も図１５と同様の動作を行うが、次の点が異なる。ステップＳ７８で交渉用ＩＥを受信しているかを判断する。また、ステップＳ８４、Ｓ８５において、交渉用ＩＥに替えて、応答用ＩＥを用いる。

以上説明したように、譲渡あるいは交換の交渉をしたいＭＡＳを交渉用ＩＥのＤＲＰ Ａｌｌｏｃａｔｉｏｎに指定してビーコン期間に送信することにより、ＭＡＳの譲渡・交換の交渉を開始することができる。また、交渉用ＩＥにカウントダウン値を含め、スーパーフレーム毎に１デクリメント（カウントダウン）することにより、Ｏｗｎｅｒ側は交渉期間を計測する。また、Ｔａｒｇｅｔ側は、カウントダウン値に基づいて、応答用ＩＥを送信することと、ＭＡＳを譲渡、交換するタイミングとを検知することができる。

Ｏｗｎｅｒ側は、交渉相手となるデバイスから応答用ＩＥを受信することによって、交渉成立となり、カウントダウン値がゼロになった次のスーパーフレームから変更したＭＡＳを使用することになる。応答がなくカウントダウン値がゼロになった場合には交渉不成立である。また、図１４では、説明しなかったが、Ｔａｒｇｅｔ側のデバイスでは、カウントダウン値が３以上で応答用ＩＥを送信し、２以下の場合応答しないことを前提とする。これは、無線伝送路では、転送を失敗する場合を考慮することが前提であり、連続３回までの失敗を想定しているからである。カウントダウン値３で応答を開始するとゼロになるまで４回応答用ＩＥを送信できることになる。

以上のように、本発明に係る好適な実施形態によれば、他のデバイスが予約しているスロットを自デバイスに振り分けることによって、必要帯域を確保することができる。これにより、通信品質を確保することができる。また、スロットを連続するようにまとめることによって、大きなサイズの転送を実行できるようになり、転送効率が向上する。

なお、本発明は上記に示す実施形態に限定されるものではない。本発明の範囲において、上記実施形態の各要素を、当業者であれば容易に考えうる内容に変更、追加、変換することが可能である。

本発明の実施形態１のデバイスの構成例を示す図である。 スーパーフレームの構成例を示す図である。 ＤＲＰ ＩＥのフレームフォーマットを示す図である。 ゾーンビットマップとＭＡＳビットマップとを説明する構成例を示す図である。 交渉用ＩＥのフレームフォーマットの一例を示す図である。 譲渡交渉を行うＭＡＳの予約状況の一例を示す図である。 デバイス＃Ｅが譲渡交渉するときの交渉用ＩＥの設定と、カウントダウン値の様子を示す図である。 交渉成功時のビーコンの更新タイミングを示す図である。 交渉失敗時のビーコンの更新タイミングを示す図である。 交換交渉を行うＭＡＳの予約状況の一例を示す図である。 デバイス＃Ｅが交換交渉するときの交渉用ＩＥの設定と、カウントダウン値の様子を示す図である。 ＭＡＳの譲渡または交換を要求するＯｗｎｅｒ側のＭＡＣ制御ドライバの動作例を示すフローチャートである。 Ｏｗｎｅｒ側のＭＡＣ制御ドライバの交渉処理の詳細を示すフローチャートである。 ＭＡＳの譲渡または交換を要求されるＴａｒｇｅｔ側のＭＡＣ制御ドライバの動作例を示すフローチャートである。 Ｏｗｎｅｒ側のホストコントローラの内蔵ＣＰＵの動作例を示すフローチャートである。 従来のＭＡＳの予約状況の一例を示す図である。

符号の説明

１ａ〜１ｅ デバイス
１０ 制御部
１１ ＷＵＳＢ制御ドライバ
１２ ＭＡＣ制御ドライバ
２０ メインメモリ
２１ ＩＥ設定領域
２２ 受信ビーコン格納領域
３０ システムチップセット
３１ ＰＣＩバスコントローラ
４０ ＰＣＩバス
５０ ホストコントローラ
５１ 内蔵ＣＰＵ
５２ ＰＣＩインターフェース（Ｉ／Ｆ）
５３ ホスト制御レジスタ
５４ フレームバッファ
５５ デバイス側インターフェース
５６ 無線部

Claims (9)

1. ＷｉＭｅｄｉａ＿Ａｌｌｉａｎｃｅに基づいてＭＡＳ（Medium Access Slot）を予約して通信を行う通信装置であって、
   他の通信装置が予約したＭＡＳを自装置が利用できるように予約変更することを要求する交渉要求情報を生成する制御部と、
   前記交渉要求情報を前記他の通信装置へ送信し、他の通信装置から予約変更を承諾する応答を受信するホストコントローラと、を備え、
   前記制御部は、前記応答後、前記他の通信装置が予約したＭＡＳを自装置が利用するＭＡＳとして設定する通信装置。
2. 前記制御部は、前記交渉要求情報として、前記他の通信装置が予約したＭＡＳを譲渡することを要求する情報を生成し、前記応答後、前記他の通信装置と同期をとって、前記他の通信装置が予約したＭＡＳを譲り受けることを特徴とする請求項１記載の通信装置。
3. 前記制御部は、前記交渉要求情報として、自装置が予約したＭＡＳと、前記他の通信装置が予約したＭＡＳとを交換することを要求する情報を生成し、前記応答後、前記他の通信装置と同期をとって、相互にＭＡＳを交換することを特徴とする請求項１記載の通信装置。
4. 前記制御部は、前記交渉要求情報を送信することを所定の期間繰り返し、前記所定の期間経過後に、前記他の通信装置が予約したＭＡＳの利用を開始することを特徴とする請求項１乃至３のいずれか一項に記載の通信装置。
5. 前記交渉要求情報は、自装置が予約したＭＡＳ番号を設定する自ＭＡＳ番号領域と、前記他の通信装置が予約したＭＡＳ番号を設定する他ＭＡＳ番号領域とを含み、
   前記制御部は、前記他ＭＡＳ番号領域に利用することを要求するＭＡＳ番号を設定し、前記他の通信装置とＭＡＳの交換を要求する場合は、前記自ＭＡＳ番号領域を設定することを特徴とする請求項１乃至４のいずれか一項に記載の通信装置。
6. 前記交渉要求情報は、前記所定の期間をカウントするカウントダウン値を含み、
   前記制御部は、前記カウントダウン値に前記交渉要求情報を送信するスーパーフレームの数を設定し、
   前記ホストコントローラは、前記カウントダウン値をスーパーフレームが変わる毎にカウントダウンし、前記カウントダウン値がゼロ以上のときに前記交渉要求情報を送信し、前記カウントダウン値がゼロ未満になったときに、前記交渉要求情報の送信を中止し、
   前記制御部は、前記応答があり、かつ、前記カウントダウン値がゼロ未満になったときに、前記他の通信装置が予約したＭＡＳを自装置が利用するＭＡＳとして設定することを特徴とする請求項４に記載の通信装置。
7. 前記ホストコントローラは、前記他の通信端末から自装置が予約したＭＡＳを前記他の通信装置が利用できるように予約変更することを要求する、他の通信装置から送信された交渉要求情報を受信し、
   前記制御部は、自己が予約しているＭＡＳに応じて、前記他の通信装置から送信された交渉要求情報へ応答するか否かを判断することを特徴とする請求項１乃至６のいずれか一項に記載の通信装置。
8. ＷｉＭｅｄｉａ＿Ａｌｌｉａｎｃｅに基づいてＭＡＳを予約して通信を行う通信方法であって、
   第１装置が第２装置によって予約されたＭＡＳを利用できるように予約変更することを要求する交渉要求情報を前記第１装置から送信し、
   前記交渉要求情報に基づいて、前記第２装置が予約変更の承諾を応答し、
   前記応答後、前記第２装置が予約したＭＡＳを第１装置が利用する通信方法。
9. ＷｉＭｅｄｉａ＿Ａｌｌｉａｎｃｅに基づいてＭＡＳを予約する情報のデータ構造であって、
   ビーコンに載せるデータフレームを構成し、第１の装置によって予約されたＭＡＳ番号と、第２の装置によって予約された予約ＭＡＳ番号とを相互に交換できるように特定するデータ構造。

Images