(57)【特許請求の範囲】
【請求項１】
通信装置であって、
他の通信装置と送信側または受信側のいずれでデータ通信するかを切り替える切替部と、
前記送信側の場合は前記他の通信装置に送信データを送信して応答を受信し、前記受信側の場合は前記他の通信装置から受信データを受信して応答を送信する通信部と、
を備え、
前記切替部は、前記通信部により受信された前記応答に切替指示が含まれる場合、前記送信側から前記受信側に切り替え、
前記通信部は、前記通信装置が前記送信側であり、且つ送信すべきデータが無い場合、前記送信データの代わりに、スリープ時間を示す情報を設定した送信権調停フレームを前記他の通信装置に送信して前記応答を受信し、前記応答を受信後に、前記応答に前記切替指示が含まれない場合に前記スリープ時間が経過するまで通信を休止し、
前記切替部は、前記スリープ時間を示す情報を設定した前記送信権調停フレームに対する前記応答に前記切替指示が含まれる場合に前記送信側から前記受信側に切り替える、通信装置。
【請求項２】
前記通信部は、近接無線通信により前記他の通信装置と通信する、請求項１に記載の通信装置。
【請求項３】
前記通信部は、前記切替指示を含む前記応答を前記他の通信装置に送信する、請求項１又は２に記載の通信装置。
【請求項４】
前記切替部は、前記通信装置が前記受信側であり、且つ送信すべきデータが有る場合、前記受信側から前記送信側に切り替え、
前記通信部は、前記切替指示を含む前記応答を送信後、前記送信データを前記他の通信装置に送信する、請求項３に記載の通信装置。
【請求項５】
前記通信装置は、レスポンダまたはイニシエータのいずれかであり、
前記通信部は、前記通信装置がレスポンダであるかイニシエータであるかにかかわらず、同一のフレーム間スペースを用いて前記送信データを送信する、請求項１〜４のいずれか一項に記載の通信装置。
【請求項６】
送信側でデータ通信する第１の通信装置と受信側でデータ通信する第２の通信装置とを備え、
前記第１の通信装置は、
前記送信側から前記受信側に切り替える第１の切替部と、
前記第２の通信装置に送信データを送信して応答を受信する第１の通信部と、
を有し、
前記第２の通信装置は、
前記受信側から前記送信側に切り替える第２の切替部と、
前記第１の通信装置から前記送信データを受信して前記応答を送信する第２の通信部と、
を有し、
前記第２の通信部により切替指示を含めた前記応答が送信される場合、前記第２の切替部は前記受信側から前記送信側に切り替え、前記第１の通信部により当該応答が受信された場合、前記第１の切替部は前記送信側から前記受信側に切り替え、
前記第１の通信部は、前記第１の通信装置が前記送信側であり、且つ送信すべきデータが無い場合、前記送信データの代わりに、スリープ時間を示す情報を設定した送信権調停フレームを前記第２の通信装置に送信して前記応答を受信し、前記応答を受信後に、前記応答に前記切替指示が含まれない場合に前記スリープ時間が経過するまで通信を休止し、
前記第１の切替部は、前記スリープ時間を示す情報を設定した前記送信権調停フレームに対する前記応答に前記切替指示が含まれる場合に前記送信側から前記受信側に切り替える、通信システム。
【請求項７】
通信装置による通信方法であって、
他の通信装置と送信側または受信側のいずれでデータ通信するかを切り替えることと、
前記送信側の場合は前記他の通信装置に送信データを送信して応答を受信し、前記受信側の場合は前記他の通信装置から受信データを受信して応答を送信することと、
受信された前記応答に切替指示が含まれる場合、前記送信側から前記受信側に切り替えることと、
前記通信装置が前記送信側であり、且つ送信すべきデータが無い場合、前記送信データの代わりに、スリープ時間を示す情報を設定した送信権調停フレームを前記他の通信装置に送信して前記応答を受信し、前記応答を受信後に、前記応答に前記切替指示が含まれない場合に前記スリープ時間が経過するまで通信を休止することと、
前記スリープ時間を示す情報を設定した前記送信権調停フレームに対する前記応答に前記切替指示が含まれる場合に前記送信側から前記受信側に切り替えることと、
を備える通信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、通信装置、通信システムおよび通信方法に関する。
【背景技術】
【０００２】
近年、近接無線通信により各種データの送受信を行う無線通信技術が開発されている。【０００３】
例えば、ＴｒａｎｓｆｅｒＪｅｔ（登録商標）は、近接無線通信方式として、デジタルカメラやＰＣ（Ｐｅｒｓｏｎａｌ  Ｃｏｍｐｕｔｅｒ）などに採用されており、情報処理装置間のデータ通信におけるエコシステムを構築している。ＴｒａｎｓｆｅｒＪｅｔの仕様は、ＴｒａｎｓｆｅｒＪｅｔコンソーシアムにて標準化されており、ＴｒａｎｓｆｅｒＪｅｔコンソーシアムによる規格とほぼ同様の国際規格が下記非特許文献１に示すＥＣＭＡ３９８として登録されている。【０００４】
また、特許文献１では、無線通信技術における効率的な無線接続の確立、維持、切断を行うための方法が開示されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特許第４８４００４３号公報
【非特許文献】
【０００６】
【非特許文献１】ＥＣＭＡ−３９８（ｈｔｔｐ：／／ｗｗｗ．ｅｃｍａ−ｉｎｔｅｒｎａｔｉｏｎａｌ．ｏｒｇ／ｐｕｂｌｉｃａｔｉｏｎｓ／ｆｉｌｅｓ／ＥＣＭＡ−ＳＴ／ＥＣＭＡ−３９８．ｐｄｆ）
【発明の概要】
【発明が解決しようとする課題】
【０００７】
上記特許文献および非特許文献に開示された技術は、いずれも半二重通信路での無線通信を行っている。しかし、近年では、全二重通信を要するアプリケーションの増加に伴い、半二重通信路における全二重通信への対応が求められていた。【０００８】
そこで、本開示では、半二重通信路上での全二重通信に対応することが可能な、新規かつ改良された通信装置、通信システムおよび通信方法を提案する。
【課題を解決するための手段】
【０００９】
本開示によれば、他の通信装置と送信側または受信側のいずれでデータ通信するかを切り替える切替部と、前記送信側の場合は前記他の通信装置に送信データを送信して応答を受信し、前記受信側の場合は前記他の通信装置から受信データを受信して応答を送信する通信部と、を備え、前記切替部は、前記通信部により受信された前記応答に切替指示が含まれる場合、前記送信側から前記受信側に切り替える、通信装置が提供される。【００１０】
また、本開示によれば、送信側でデータ通信する第１の通信装置と受信側でデータ通信する第２の通信装置とを備え、前記第１の通信装置は、前記送信側から前記受信側に切り替える第１の切替部と、前記第２の通信装置に送信データを送信して応答を受信する第１の通信部と、を有し、前記第２の通信装置は、前記受信側から前記送信側に切り替える第２の切替部と、前記第１の通信装置から前記送信データを受信して前記応答を送信する第２の通信部と、を有し、前記第２の通信部により切替指示を含めた前記応答が送信される場合、前記第２の切替部は前記受信側から前記送信側に切り替え、前記第１の通信部により当該応答が受信された場合、前記第１の切替部は前記送信側から前記受信側に切り替える、通信システムが提供される。【００１１】
また、本開示によれば、他の通信装置と送信側または受信側のいずれでデータ通信するかを切り替えることと、前記送信側の場合は前記他の通信装置に送信データを送信して応答を受信し、前記受信側の場合は前記他の通信装置から受信データを受信して応答を送信することと、受信された前記応答に切替指示が含まれる場合、前記送信側から前記受信側に切り替えることと、を備える通信方法が提供される。
【発明の効果】
【００１２】
以上説明したように本開示によれば、半二重通信路上での全二重通信に対応することが可能である。なお、上記の効果は必ずしも限定的なものではなく、上記の効果とともに、または上記の効果に代えて、本明細書に示されたいずれかの効果、または本明細書から把握され得る他の効果が奏されてもよい。
【図面の簡単な説明】
【００１３】
【図１】本開示の一実施形態に係る通信システムを構成する２つの機器を示す模式図である。
【図２】ＴｒａｎｓｆｅｒＪｅｔのプロトコルスタックを示す図である。
【図３】ＴｒａｎｓｆｅｒＪｅｔにおけるフレーム間スペースを説明するための図である。
【図４】第１の実施形態に係る通信装置の構成を示すブロック図である。
【図５】ＴｒａｎｓｆｅｒＪｅｔのＡＣＫフレームのフォーマットを示す図である。
【図６】ＴｒａｎｓｆｅｒＪｅｔの管理フレームのフォーマットを示す図である。
【図７】ＴｒａｎｓｆｅｒＪｅｔの管理フレームのフレームボディのフォーマットを示す図である。
【図８】第１の実施形態に係る送信権調停動作の一例を示す図である。
【図９】第１の実施形態に係る送信権調停動作の一例を示す図である。
【図１０】第１の実施形態に係るスリープ動作の一例を示す図である。
【図１１】第１の実施形態に係る通信装置の動作を示すフローチャートである。
【発明を実施するための形態】
【００１４】
以下に添付図面を参照しながら、本開示の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。
【００１５】
なお、説明は以下の順序で行うものとする。
１．本開示の一実施形態に係る通信システムの概要
２．第１の実施形態
２−１．通信装置の構成
２−２．送信権の調停
２−２−１．ＡＣＫフレームによる調停
２−２−２．Ｔｏｋｅｎフレームによる調停
２−２−３．送信権調停動作の一例
２−３．極短時間のスリープ
２−４．動作処理
３．まとめ
【００１６】
＜１．本開示の一実施形態に係る通信システムの概要＞
まず、図１、図２を参照して、本開示の一実施形態に係る通信システムの概要を説明する。具体的には、ＴｒａｎｓｆｅｒＪｅｔに基づく通信システムの概要について説明する。
【００１７】
図１は、本開示の一実施形態に係る通信システムを構成する２つの機器（通信装置）を示す模式図である。図１に示すように、本実施形態に係る通信システムは、一対の機器の間でデータを送受信することを目的とした通信方式であり、近距離の機器間で無線によりデータの送受信を行う。２つの機器は、それぞれレスポンダ（Ｒｅｓｐｏｎｄｅｒ）とイニシエータ（Ｉｎｉｔｉａｔｏｒ）という役割を有する。イニシエータは「接続要求を出す側」であり、レスポンダは「接続要求を受ける側」であり、本実施形態では１対１（Ｐ２Ｐ）の通信が行われる。接続の際、イニシエータは接続要求を出し、レスポンダは持ち受け状態となるが、両者は接続の際の役割が異なるのみで、接続に関係する機器の構成は同一である。イニシエータとしては例えばＰＣ、携帯機器、電子カードなどが該当し、レスポンダとしてはＰＣ、携帯機器、電子カードなどの機器が該当する。
【００１８】
図１では、本実施形態の各機器のそれぞれが備える物理層を介して無線通信が行われる様子を模式的に示している。本実施形態では、ＴｒａｎｓｆｅｒＪｅｔによる物理層を介して近接無線通信が行われるものとするが、物理層はこれに限定されるものではなく、通信用の汎用的な物理層に適用することができる。ＴｒａｎｓｆｅｒＪｅｔによる物理層は、接続層サービスデータユニット（ＣＳＤＵ：Ｃｏｎｎｅｃｔｉｏｎ  ｌａｙｅｒ  Ｓｅｒｖｉｃｅ  Ｄａｔａ  Ｕｎｉｔ）を用いることで、写真、動画などの大容量のデータ通信に特に適したものである。
【００１９】
ここで、ＴｒａｎｓｆｅｒＪｅｔは、４．４８ＧＨｚ帯を用いた近距離無線通信方式である。この通信プロトコル（ＴｒａｎｓｆｅｒＪｅｔ）を用いることにより、４．４８ＧＨｚの電波を−７０ｄＢｍ／ＭＨｚ以下で使用し、最大５６０Ｍｂｐｓの高速近距離データ通信を実現することができる。また、近距離無線通信における通信距離を数ｃｍに限定することにより、通信処理を高速化することができるとともに、通信装置を小規模化することができ、省電力化を達成することができる。続いて、図２を参照して、ＴｒａｎｓｆｅｒＪｅｔのプロトコルスタックを説明する。
【００２０】
図２は、ＴｒａｎｓｆｅｒＪｅｔのプロトコルスタックを示す図である。図２に示すように、ＴｒａｎｓｆｅｒＪｅｔのプロトコルスタックは、ＰＨＹ層（物理層：Ｐｈｙｓｉｃａｌ  Ｌａｙｅｒ）１０、ＣＮＬ層（接続層：Ｃｏｎｎｅｃｔｉｏｎ  Ｌａｙｅｒ）２０、ＰＣＬ層（Ｐｒｏｔｏｃｏｌ  Ｃｏｎｖｅｒｓｉｏｎ  Ｌａｙｅｒ）３０、アプリケーション（Ｕｓｅｒ  Ａｐｐｌｉｃａｔｉｏｎ）４０から成る。
【００２１】
ＰＨＹ層１０は、実際の無線通信を実行する層であり、半二重方式（単方向）の通信を行う。ＣＮＬ層２０は、１対１制御やメディアアクセス制御を行う層であり、半二重方式の通信に最適化されている。ＰＣＬ層３０は、アプリケーション４０をＣＮＬ層２０に適合させる機能を有し、例えばＳＣＳＩ（Ｓｍａｌｌ  Ｃｏｍｐｕｔｅｒ  Ｓｙｓｔｅｍ  Ｉｎｔｅｒｆａｃｅ）やＯＢＥＸ（ＯＢｊｅｃｔ  ＥＸｃｈａｎｇｅ）などの既存のインターフェース規格を変換する。アプリケーション４０は、例えばＳＣＳＩやＯＢＥＸなどの既存のインターフェース規格を用いる。
【００２２】
ＴｒａｎｓｆｅｒＪｅｔ導入初期にあっては、アプリケーション４０にはＳＣＳＩやＯＢＥＸなどの半二重プロトコルが用いられてきた。しかし、近年では、ＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）やＳｅｒｉａｌのＵＡＲＴ（Ｕｎｉｖｅｒｓａｌ  Ａｓｙｎｃｈｒｏｎｏｕｓ  Ｒｅｃｅｉｖｅｒ  Ｔｒａｎｓｍｉｔｔｅｒ）などの、全二重方式（双方向）のプロトコルが用いられる機会が増加している。
【００２３】
しかし、ＣＮＬ層２０は半二重方式の通信を行うため、アプリケーション４０が全二重プロトコルを採用している場合、無線伝送路上でパケットの衝突が発生する場合があり、スループット低下の要因となる。以下、図３を参照して、このようなパケットの衝突について詳細に説明する。
【００２４】
図３は、ＴｒａｎｓｆｅｒＪｅｔにおけるフレーム間スペース（ＩＦＳ：Ｉｎｔｅｒ  Ｆｒａｍｅ  Ｓｐａｃｅ）を説明するための図である。図３に示すように、フレーム間スペースは、直前のフレーム（Ｐｒｅｖｉｏｕｓ  Ｆｒａｍｅ）と次のフレームとの間の時間的間隔を表すものである。ＴｒａｎｓｆｅｒＪｅｔでは、図３に示したように、ＡＣＫフレーム（ＡＣＫ  Ｆｒａｍｅ  Ｔｘ）、イニシエータのＣＳＤＵフレーム（ＤＡＴＡ  （ＣＳＤＵ）  Ｔｘ（Ｉｎｉｔｉａｔｏｒ））、レスポンダのＣＳＤＵフレーム（ＤＡＴＡ  （ＣＳＤＵ）  Ｔｘ（Ｒｅｓｐｏｎｄｅｒ））、イニシエータの管理フレーム（Ｍａｎａｇｅｍｅｎｔ  （ｅｘｃｅｐｔ  Ｃ−Ｒｅｑ）  ＴＸ（Ｉｎｉｔｉａｔｏｒ））、レスポンダの管理フレーム（Ｍａｎａｇｅｍｅｎｔ  （ｅｘｃｅｐｔ  Ｃ−Ａｃｃ）  ＴＸ（Ｒｅｓｐｏｎｄｅｒ））、接続要求管理フレーム（Ｍａｎａｇｅｍｅｎｔ（Ｃ−Ｒｅｑ）  Ｔｘ）、および接続許可応答管理フレーム（Ｍａｎａｇｅｍｅｎｔ  （Ｃ−Ａｃｃ）  Ｔｘ）の各フレームについて規定されている。図３に示す各フレームは、プリアンブルＰｒｅ（Ｐｒｅａｍｂｌｅ）、同期Ｓ（Ｓｙｎｃ）、物理層ヘッダＰＨＹ（ＰＨＹ  Ｈｅａｄｅｒ）を共通して有し、それぞれフレームボディが続く構成となっている。例えば、ＣＳＤＵフレームには、フレームボディに最大で２つのＣＳＤＵが格納される。通信システムは、ＣＳＤＵフレームにより、上位層から渡されたデータのやり取りを行うことができる。
【００２５】
図３に示すように、ＡＣＫフレームは、直前のフレームからＳＩＦＳ間隔で送信が開始される。同様に、イニシエータのＣＳＤＵフレームおよび管理フレームは、ＩＩＦＳ間隔で送信が開始される。ここで、ＩＩＦＳとＳＩＦＳとは同じ間隔である。また、レスポンダのＣＳＤＵフレームおよび管理フレームは、ＳＩＦＳよりもＴｂｓｔだけ長いＲＩＦＳ間隔で送信される。また、接続要求は、１００ｕｓｅｃ間隔を基本として送信される。ただし、接続要求を送信するタイミングで無線伝送路上に他の装置が送信したフレームが検出された場合、他の装置が送信したフレームからＳＩＦＳよりもＴｂｓｔ２つ分だけ長い間隔で送信される。接続許可応答は、ＳＩＦＳよりもＴｂｓｔ２つ分およびランダムバックオフの分（Ｔｂｓｔの定数倍）だけ長い間隔で送信される。以下、表１に、ＳＩＦＳ、ＩＩＦＳ、ＲＩＦＳ、Ｔｂｓｔの具体的な値を示した。
【００２６】
【表１】
0006468190.tif 000002
【００２７】
イニシエータは、図３に示すように、直前のフレームの後ＩＩＦＳ経過した後にＣＳＤＵフレームを送信可能となる。即ち、イニシエータは、表１に示すように、無線メディアのアイドル状態でＩＩＦＳ（最小８．５ｕｓｅｃ（マイクロ秒））経過した後に送信権を取得する。一方で、レスポンダは、図３に示すように、直前のフレームの後ＲＩＦＳ経過した後にＣＳＤＵフレームを送信可能となる。即ち、レスポンダは、表１に示すように、無線メディアのアイドル状態でＲＩＦＳ（最小１５．７ｕｓｅｃ）経過した後に送信権を取得する。
【００２８】
このため、無線メディアのアイドル期間がＲＩＦＳに到達した時点で、イニシエータとレスポンダの両者が送信権を持つことになる。よって、両者が同時にＣＳＤＵフレームの送信を開始した場合に、無線メディア上でフレームの衝突が発生することになる。
【００２９】
そこで、上記事情を一着眼点にして本開示の一実施形態に係る通信システムを創作するに至った。本実施形態に係る通信システムは、半二重通信路上での全二重通信に対応することが可能である。本実施形態に係る通信システムは、全二重化の制御を行い全二重通信に対応することにより、上記説明したフレームの衝突を回避してスループットの低下を防ぐことができる。
【００３０】
本明細書では、無線技術の一例として、ＴｒａｎｓｆｅｒＪｅｔにおいて本開示の一実施形態にかかる技術を適用する例を説明する。以下では、ＥＣＭＡ−３９８（非特許文献１）において規定された通信処理を比較方式とも称し、本開示の一実施形態にかかる技術を適用した通信処理を提案方式とも称する。
【００３１】
以上、本開示の一実施形態に係る通信システムの概要について説明した。続いて、本開示の一実施形態に係る通信システムの詳細な内容について説明する。
【００３２】
＜２．第１の実施形態＞
［２−１．通信装置の構成］
図４は、第１の実施形態に係る通信装置１の構成を示すブロック図である。図４に示すように、通信装置１は、制御部２、切替部３、および通信部４を有する。通信装置１は、レスポンダまたはイニシエータのいずれかの役割により、他の通信装置と通信を行う。通信装置１、および通信装置１と通信する通信装置１と同様の構成を有する他の通信装置を、以下では通信システムとも称する。
【００３３】
（制御部２）
制御部２は、演算処理装置および制御装置として機能し、各種プログラムに従って通信装置１内の動作全般を制御する。制御部２は、例えばＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）、マイクロプロセッサによって実現される。なお、制御部２は、使用するプログラムや演算パラメータ等を記憶するＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）、および適宜変化するパラメータ等を一時記憶するＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）を含んでいてもよい。
【００３４】
本実施形態では、制御部２は、通信部４と接続され、通信部４を介して接続される他の通信装置との間で行われる各種データの送受信の制御を行う。また、制御部２は、切替部３と接続され、切替部３を介して後述するＴａｌｋｅｒ／Ｌｉｓｔｎｅｒの切り替えを行う。以下では、通信部４を介して接続される他の通信装置を、単に相手装置とも称する。
【００３５】
（切替部３）
本実施形態においては、ＴｒａｎｓｆｅｒＪｅｔによる通信が確立した２つの通信装置は、それぞれＴａｌｋｅｒ（送信側）とＬｉｓｔｅｎｅｒ（受信側）という役割を有する。Ｔａｌｋｅｒは、送信権を有しＣＳＤＵフレームを送信する側であり、Ｌｉｓｔｅｎｅｒは、送信権を有さずＣＳＤＵフレームを受信する側である。本実施形態に係る切替部３は、制御部２による制御に基づき、相手装置とＴａｌｋｅｒまたはＬｉｓｔｅｎｅｒのいずれの役割でデータ通信するかを切り替える機能を有する。例えば、切替部３は、送信すべきデータの有無や、通信部４により相手装置からの切替指示（後述のｔａｌｋフラグが設定されたＡＣＫフレーム）の受信有無に基づいて、Ｔａｌｋｅｒ／Ｌｉｓｔｅｎｅｒを切り替える。
【００３６】
（通信部４）
通信部４は、制御部２による制御に基づき近接無線通信を実行する通信モジュールである。例えば、通信部４は、誘導電界結合型カプラにより構成され、ＴｒａｎｓｆｅｒＪｅｔに準じて外部機器との間で近接無線通信を行う。より詳しくは、通信部４は、通信部４から所定の通信範囲内に存在する他の通信装置（近接無線通信機能を備える通信装置）との間で近接無線通信を行う。ここで、通信部４と他の通信装置との間の近接無線通信は、通信部４と他の通信装置とが近接状態である場合にのみ可能となる。ここで、近接状態は、例えば、通信部４と他の通信装置との間の距離が所定範囲（例えば、３ｃｍ）以内に接近または接触している状態を意味する。
【００３７】
通信部４は、図３を参照して説明したＡＣＫフレーム、ＣＳＤＵフレーム、管理フレーム、接続要求フレーム、および接続許可応答管理フレームの各フレームを相手装置と送受信する。特に、本実施形態では、通信部４は、Ｔａｌｋｅｒの場合は相手装置にＣＳＤＵフレーム（送信データ）を送信してＡＣＫフレーム（応答）を受信する。また、通信部４は、Ｌｉｓｔｅｎｅｒの場合は相手装置からＣＳＤＵフレーム（受信データ）を受信してＡＣＫフレーム（応答）を送信する。
【００３８】
以上、本実施形態に係る通信装置１の構成を説明した。続いて、図５〜図７を参照して、本実施形態に係る通信システムによる送信権の調停を説明する。
【００３９】
［２−２．送信権の調停］
本実施形態に係る通信システムは、ＡＣＫフレームによる送信権の調停、または送信権調停用の専用フレーム（Ｔｏｋｅｎフレーム）による送信権の調停を行う。まず、図５を参照して、ＡＣＫフレームによる送信権の調停について説明する。
【００４０】
［２−２−１．ＡＣＫフレームによる調停］
図５は、ＴｒａｎｓｆｅｒＪｅｔのＡＣＫフレームのフォーマットを示す図である。図５に示すように、ＡＣＫフレームは、共通ＣＮＬヘッダ（Ｃｏｍｍｏｎ  ＣＮＬ  Ｈｅａｄｅｒ）、およびサブＣＮＬヘッダ（Ｓｕｂ  ＣＮＬ  Ｈｅａｄｅｒ）を有する。
【００４１】
共通ＣＮＬヘッダは、図５に示すように、Ｒｘ  ＵＩＤ、Ｔｘ  ＵＩＤ、Ｒｓｖ．、ＭＵＸ、およびＨＣＳを有する。Ｒｘ  ＵＩＤは、送信先のＵＩＤ（Ｕｎｉｑｕｅ  ＩＤ）を格納する８バイトのフィールドである。Ｔｘ  ＵＩＤは、受信先のＵＩＤを格納する８バイトのフィールドである。Ｒｓｖ．は、予約領域である１バイトのフィールドである。ＭＵＸは、フレームボディの多重数を格納する１バイトのフィールドである。ＨＣＳは、ヘッダーチェックシーケンスを格納する４バイトのフィールドである。
【００４２】
サブＣＮＬヘッダは、図５に示すように、Ａｔｔｒｉｂｕｔｅ、ＳｅｑＮｕｍ、Ｒｓｖ．、およびＨＣＳを有する。Ａｔｔｒｉｂｕｔｅは、フレームの特性を示す情報を格納するフィールドであり、後に詳しく説明する。また、ＳｅｑＮｕｍは、ＣＮＬ層におけるフレームボディ管理のために割り当てられたシーケンス番号を格納する１バイトのフィールドである。Ｒｓｖ．は、予約領域である２バイトのフィールドである。ＨＣＳは、ヘッダーチェックシーケンスを格納する４バイトのフィールドである。
【００４３】
続いて、Ａｔｔｒｉｂｕｔｅの内容について説明する。図５に示すように、Ａｔｔｒｉｂｕｔｅは、Ｓｅｑ  Ｓｙｎｃ、Ｒｓｖ．、ＦＢＴ、Ｒｅｓｅｒｖｅｄ、Ｆｒａｍｅ  ｔｙｐｅを有する。Ｓｅｑ  Ｓｙｎｃは、同期のためのフラグを格納する１ビットのフィールドである。Ｒｓｖ．は、予約領域である１ビットのフィールドである。ＦＢＴ（Ｆｒａｍｅ  Ｂｏｄｙ  ｔｙｐｅ）は、例えばＣＳＤＵフレームに対するＡＣＫなのか、管理フレームに対するＡＣＫなのかといったフレームボディの種類を格納する１ビットのフィールドである。Ｒｅｓｅｒｖｅｄは、予約領域である３ビットの領域である。Ｆｒａｍｅ  ｔｙｐｅは、ＣＳＤＵフレームなのか、ＡＣＫフレームなのか、管理フレームなのか、といったフレームの種類を格納する２ビットの領域である。
【００４４】
本実施形態に係る通信システムは、サブＣＮＬヘッダのＲｅｓｅｒｖｅｄフィールドを、送信権調停のために用いる。より具体的には、本実施形態に係る通信システムは、ＡＣＫフレームのＲｅｓｅｒｖｅｄフィールドに送信権の要求を示すフラグ（ｔａｌｋフラグ）が設定されているか否かに基づいて、送信権を調停する。
【００４５】
通信装置１は、ＡＣＫフレームにｔａｌｋフラグを設定することにより送信権を取得する。より詳しくは、切替部３は、通信装置１の役割がＬｉｓｔｅｎｅｒであり、且つ送信すべきデータがある場合、役割をＬｉｓｔｅｎｅｒからＴａｌｋｅｒに切り替える。これに伴い、通信部４は、ｔａｌｋフラグ（切替指示）を含むＡＣＫフレームを相手装置に送信する。これにより、通信装置１の役割がＴａｌｋｅｒとなり相手装置の役割がＬｉｓｔｅｎｅｒとなるため、通信部４は、送信すべきデータをＣＳＤＵフレームに格納して、相手装置に送信する。
【００４６】
一方で、通信装置１は、ｔａｌｋフラグが設定されたＡＣＫフレームを受信することにより送信権を相手装置に譲渡する。より詳しくは、切替部３は、通信装置１の役割がＴａｌｋｅｒである場合、通信部４により受信されたＡＣＫフレームにｔａｌｋフラグ（切替指示）が含まれている場合、通信装置１の役割をＴａｌｋｅｒからＬｉｓｔｅｎｅｒに切り替える。これにより、通信装置１の役割がＬｉｓｔｅｎｅｒとなり相手装置の役割がＴａｌｋｅｒとなるため、通信部４は、ＣＳＤＵフレームを相手装置から受信することができる。
【００４７】
通信装置１と相手装置の両者が送信すべきデータを有する場合、両者共に相手からＣＳＤＵフレームを受信した後にｔａｌｋフラグを設定したＡＣＫフレームを送信することで送信権を取得して、自分のＣＳＤＵフレームを送信することになる。即ち、両者は、交互に送信権を取得してＣＳＤＵフレームを送信する、即ち略同時にＣＳＤＵフレームを送信することができる。このように、本実施形態に係る通信システムは、ＡＣＫフレームによる送信権の調停により各通信装置の役割を切り替えることにより、全二重化の制御を実現することができる。
【００４８】
ここで、上位層のアプリケーション（図２におけるアプリケーション４０）は、全二重方式の通信規格を採用する場合がある。例えば、全二重方式の通信規格のひとつであるＴＣＰ／ＩＰプロトコルにおいては、送信側は、データ送信後にＡＣＫ応答を受信することにより到達確認を行う。そして、ＡＣＫ応答がない場合、送信側は、データ送信を遅延させたり、データを再送したりする。
【００４９】
比較方式においては、本実施形態のようにレスポンダが適切なタイミングでＣＳＤＵフレームを送信することができなかった。より詳しくは、図３に示したように、レスポンダからイニシエータにＣＳＤＵフレームを送信するためには、フレーム間スペースＲＩＦＳが経過することを要していた。このため、イニシエータからレスポンダにＩＩＦＳ間隔でＣＳＤＵフレームが送信されている間は、レスポンダからイニシエータにＴＣＰ／ＩＰプロトコルにおけるＡＣＫ応答を格納したＣＳＤＵフレームを送信することが困難であった。よって、比較方式においては、イニシエータのアプリケーションがＴＣＰ／ＩＰパケット送信後にＡＣＫ応答を適切なタイミングで受信できない場合は、データ送信を遅延させたりデータの再送が行われることとなる。
【００５０】
これに対し、本実施形態に係る通信システムは、上記説明した全二重化の制御を行うため、イニシエータがデータ送信を行っている間であっても、レスポンダはＴＣＰ／ＩＰプロトコルにおけるＡＣＫ応答を格納したＣＳＤＵフレームを送信可能である。このため、イニシエータはＡＣＫ応答による到達確認が可能であるので、データ送信の遅延やデータの再送を行う必要がない。よって、本実施形態に係る通信システムは、上位層のアプリケーションが全二重方式の通信規格を採用する場合、比較方式と比較して速い伝送速度を実現することができる。
【００５１】
また、本実施形態に係る通信システムは、ＡＣＫフレームにより送信権の調停を行うため、図３および表１を参照して上記説明したような、両者が送信権を持つ事態が生じないので、フレームの衝突が発生することがない。また、本実施形態に係る通信システムは、既存のフレーム構成の予約領域を用いた送信権の調停により全二重化の制御を行う。よって、本実施形態に係る通信システムは、送信権の調停を行うための専用フレームを追加することによるスループットの低下を防ぐことができる。
【００５２】
以上、ＡＣＫフレームによる送信権の調停について説明した。続いて、Ｔｏｋｅｎフレームによる送信権の調停について説明する。
【００５３】
［２−２−２．Ｔｏｋｅｎフレームによる調停］
本実施形態に係る通信システムは、データ通信が行われていない場合にのみ、送信権の調停を行うための専用フレーム（Ｔｏｋｅｎフレーム）の交換手順を開始する。データ通信が行われていない間にＴｏｋｅｎフレームの交換が行われるため、Ｔｏｋｅｎフレームの交換によってスループットに対して影響を与えることはない。
【００５４】
Ｔｏｋｅｎフレームは、既存の管理フレームを用いて実現される。まず、図６を参照して、ＴｒａｎｓｆｅｒＪｅｔの既存の管理フレームについて説明する。
【００５５】
図６は、ＴｒａｎｓｆｅｒＪｅｔの管理フレームのフォーマットを示す図である。図６に示すように、管理フレームは、共通ＣＮＬヘッダ（Ｃｏｍｍｏｎ  ＣＮＬ  Ｈｅａｄｅｒ）、サブＣＮＬヘッダ（Ｓｕｂ  ＣＮＬ  Ｈｅａｄｅｒ）、フレームボディ（Ｆｒａｍｅ  Ｂｏｄｙ）、およびＦＣＳを有する。共通ＣＮＬヘッダは、図５を参照して上記説明した通りであるので、ここでの詳細な説明は省略する。フレームボディは、制御情報を格納する３２バイトのフィールドであり、ＦＣＳは、フレームチェックシーケンスを格納する４バイトのフィールドである。
【００５６】
サブＣＮＬヘッダは、図６に示すように、Ａｔｔｒｉｂｕｔｅ、ＳｅｑＮｕｍ、Ｌｅｎｇｔｈ、およびＨＣＳを有する。Ａｔｔｒｉｂｕｔｅは、フレームの特性を示す情報を格納するフィールドであり、後に詳しく説明する。Ｌｅｎｇｔｈは、Ｆｒａｍｅ  Ｂｏｄｙの長さを格納する２バイトのフィールドである。なお、ＨＣＳおよびＳｅｑＮｕｍは、図５を参照して上記説明した通りであるので、ここでの詳細な説明は省略する。
【００５７】
続いて、Ａｔｔｒｉｂｕｔｅの内容について説明する。図６に示すように、Ａｔｔｒｉｂｕｔｅは、Ｓｅｑ  Ｓｙｎｃ、ＡＣＫ  ｔｙｐｅ、Ｆｒａｍｅ  Ｂｏｄｙ  ｔｙｐｅ、Ｒｅｓｅｒｖｅｄ、Ｆｒａｍｅ  ｔｙｐｅを有する。ＡＣＫ  ｔｙｐｅは、ＡＣＫ応答を必要とするＩｍＡＣＫか、ＡＣＫ応答を必要としないＮｏＡＣＫかのいずれかを示す情報が格納する１ビットのフィールドである。なお、Ｓｅｑ  Ｓｙｎｃ、Ｆｒａｍｅ  Ｂｏｄｙ  ｔｙｐｅ、Ｒｅｓｅｒｖｅｄ、およびＦｒａｍｅ  ｔｙｐｅは、図５を参照して上記説明した通りであるので、ここでの詳細な説明は省略する。
【００５８】
以上、ＴｒａｎｓｆｅｒＪｅｔの管理フレームのフォーマットについて説明した。続いて、図７を参照して、Ｔｏｋｅｎフレームを実現するための、管理フレームの構成例を説明する。
【００５９】
図７は、ＴｒａｎｓｆｅｒＪｅｔの管理フレームのフレームボディのフォーマットを示す図である。図７に示すように、フレームボディは、ＬｉＣＣ  Ｖｅｒｓｉｏｎ、ＬｉＣＣ、２つのＲｅｓｅｒｖｅｄ、Ｏｗｎ  ＵＩＤ、およびＬｉＣＣ  Ｉｎｆｏｒｍａｔｉｏｎを有する。ＬｉＣＣ（Ｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｃｏｍｍａｎｄ）は、接続制御のためのコマンドを格納する１バイトのフィールドであり、ＬｉＣＣ  ｔｙｐｅはそのバージョンを格納する１バイトのフィールドである。Ｒｅｓｅｒｖｅｄは予約領域である１バイトのフィールドである。Ｏｗｎ  ＵＩＤは、自身のＵＩＤを格納する８バイトのフィールドである。ＬｉＣＣ  Ｉｎｆｏｒｍａｔｉｏｎは、接続制御のためのコマンド（ＬｉＣＣ）に関する各種情報を格納する２０バイトのフィールドである。
【００６０】
続いて、表２に、管理フレームにおけるフレームボディの内容および関連する設定情報を示す。
【００６１】
【表２】
0006468190.tif 000003
【００６２】
本実施形態に係る通信システムは、ＬｉＣＣ  ｔｙｐｅにＴｏｋｅｎフレームのための値として、例えば「０ｘ０Ｂ」を割り振り、ＴｏｋｅｎフレームにおけるＡＣＫ  ｔｙｐｅを、ＡＣＫ応答を必要とするＩｍＡＣＫとする。即ち、本実施形態に係る通信システムは、サブＣＮＬヘッダのＡＣＫ  ｔｙｐｅをＩｍＡＣＫとし、フレームボディのＬｉＣＣを０ｘ０Ｂとした管理フレームを、送信権調停のための専用フレーム（Ｔｏｋｅｎフレーム）として用いる。
【００６３】
以上、Ｔｏｋｅｎフレームの構成例を説明した。
【００６４】
本実施形態に係る通信システムは、以上説明したＴｏｋｅｎフレームにより、送信権の調停を行う。ＴｏｋｅｎフレームのＡＣＫ  ｔｙｐｅはＡＣＫ応答を必要とするＩｍＡＣＫである。よって、本実施形態に係る通信システムは、ＴａｌｋｅｒとＬｉｓｔｅｎｅｒの両者が送信するためのデータを持っていない場合、Ｔｏｋｅｎフレームの送信およびＡＣＫ応答を継続的に行うことで、送信権の調停を行う。
【００６５】
より詳しくは、通信部４は、通信装置１の役割がＴａｌｋｅｒであり、且つ送信すべきデータがない場合、ＣＳＤＵフレーム（送信データ）の代わりにＴｏｋｅｎフレーム（送信権調停フレーム）を相手装置に送信してＡＣＫフレームを受信する。受信したＡＣＫフレームにｔａｌｋフラグが設定されていない場合、通信部４は引き続きＴｏｋｅｎフレームの送信を行う。そして、ｔａｌｋフラグが設定されたＡＣＫフレームを受信しないまま送信すべきデータが発生した場合、通信部４はＣＳＤＵフレームを送信する。
【００６６】
一方で、通信部４は、通信装置１の役割がＬｉｓｔｅｎｅｒであり、且つ送信すべきデータがない場合、Ｔｏｋｅｎフレームの応答としてｔａｌｋフラグを設定しないＡＣＫフレームを相手装置に送信する。そして、送信すべきデータが発生した場合、通信部４はｔａｌｋフラグを設定したＡＣＫフレームを相手装置に送信して送信権を取得する。
【００６７】
このように、本実施形態に係る通信システムは、送信すべきデータが無い場合にＴｏｋｅｎフレームの送信およびＡＣＫ応答を継続的に行い、送信すべきデータが発生した場合に、このやり取りの枠内で送信権の調停を行う。このため、比較方式とは異なり、図３および表１を参照して上記説明したような、アイドル状態で所定時間経過して両者が送信権を持つことがないため、フレームの衝突が発生することがない。
【００６８】
ここで、通信装置１の状態を、何らかのフレームを送信する送信状態、受信する受信状態、送受信のいずれも行わずフレームの先頭にあるプリアンブルを検出するフレーム検出動作状態、の３つに分ける。通信装置１に用いられる電子回路によっては、フレーム検出動作状態が他の状態と比較して消費電力が大きい場合がある。特に、ＴｒａｎｓｆｅｒＪｅｔにおいては、３ｃｍ程度の近接状態で通信を行うため送信電力が微弱であり、かつ受信のための電力も微弱であることから、フレーム検出動作状態が他の状態と比較して消費電力が大きい場合が多い。この点、本実施形態に係る通信システムでは、常に通信装置１および相手装置はＴａｌｋｅｒまたはＬｉｓｔｅｎｅｒとして送信状態または受信状態のいずれかの状態となるので、フレーム検出動作状態になることを回避して消費電力を削減することができる。
【００６９】
また、一般的な無線通信規格においては、混信を避けるため、送信データが無い場合は通信を停止する。しかし、ＴｒａｎｓｆｅｒＪｅｔにおいては、３ｃｍ程度の近接状態で微弱な送信電力で通信を行うため混信の危険性が低いので、本実施形態にかかる技術を適用して常に送受信を行うことができる。
【００７０】
以上、Ｔｏｋｅｎフレームによる送信権の調停について説明した。続いて、図８、図９を参照して、送信権調停動作の一例を説明する。
【００７１】
［２−２−３．送信権調停動作の一例］
図８は、第１の実施形態に係る送信権調停動作の一例を示す図である。図８では、通信装置１−１（第１の通信装置）および通信装置１−２（第２の通信装置）が送信権の調停を行いながらデータ通信を行う例を示している。なお、通信装置１−１はイニシエータであり、通信装置１−２はレスポンダである。役割５−１、５−２は、通信装置１−１、１−２の役割（Ｔａｌｋｅｒ／Ｌｉｓｔｅｎｅｒ）を示す。送信バッファ６−１、６−２は、通信装置１−１、１−２がそれぞれ送信すべきデータの残量を示す。送信バッファ６−１、６−２のひとつのマスは、それぞれＣＳＤＵ２つ分に相当するものとする。なお、図中の星形符号「★」は、比較方式と相違する箇所を示している。
【００７２】
図８に示すように、まず、Ｔａｌｋｅｒである通信装置１−１は、Ｌｉｓｔｅｎｅｒである通信装置１−２に、シーケンス番号＃１、＃２の２つのＣＳＤＵを格納したＣＳＤＵフレーム１０１を送信する。
【００７３】
次いで、通信装置１−２は、ＣＳＤＵフレーム１０１に対する応答として、シーケンス番号＃２のＣＳＤＵまで受信したことを示すＡＣＫフレーム１０３を、通信装置１−１に送信する。このとき、送信バッファ６−２には送信すべきデータが存在するため、通信装置１−２は、ＡＣＫフレーム１０３にｔａｌｋフラグを設定する。これにより、通信装置１−２は、役割５−２をＬｉｓｔｅｎｅｒからＴａｌｋｅｒに変更する。また、ｔａｌｋフラグが設定されたＡＣＫフレーム１０３を受信した通信装置１−１は、役割５−１をＴａｌｋｅｒからＬｉｓｔｅｎｅｒに変更する。また、通信装置１−１は、ＡＣＫフレーム１０３の受信に伴い、送信バッファ６−１から送信完了したデータを削除する。
【００７４】
次に、Ｔａｌｋｅｒとなった通信装置１−２は、Ｌｉｓｔｅｎｅｒとなった通信装置１−１に、シーケンス番号＃１０５、＃１０６の２つのＣＳＤＵを格納したＣＳＤＵフレーム１０５を送信する。
【００７５】
次いで、通信装置１−１は、ＣＳＤＵフレーム１０５に対する応答として、シーケンス番号＃１０６のＣＳＤＵまで受信したことを示すＡＣＫフレーム１０７を、通信装置１−２に送信する。このとき、送信バッファ６−１には送信すべきデータが存在するため、通信装置１−１は、ＡＣＫフレーム１０７にｔａｌｋフラグを設定する。これにより、通信装置１−１は、役割５−１をＴａｌｋｅｒに変更する。また、通信装置１−２は、ｔａｌｋフラグが設定されたＡＣＫフレーム１０７の受信に伴い、役割５−２をＬｉｓｔｅｎｅｒに変更し、送信バッファ６−２から送信完了したデータを削除する。
【００７６】
このように、通信装置１−１と通信装置１−２の両者が送信すべきデータを有する場合、交互にＣＳＤＵフレームの送信を行うことになる。
【００７７】
次に、Ｔａｌｋｅｒとなった通信装置１−１は、Ｌｉｓｔｅｎｅｒとなった通信装置１−２に、シーケンス番号＃３、＃４の２つのＣＳＤＵを格納したＣＳＤＵフレーム１０９を送信する。
【００７８】
次いで、通信装置１−２は、ＣＳＤＵフレーム１０９に対する応答として、シーケンス番号＃４のＣＳＤＵまで受信したことを示すＡＣＫフレーム１１１を、通信装置１−１に送信する。このとき、送信バッファ６−２には送信すべきデータが存在しないため、通信装置１−２は、ＡＣＫフレーム１１１にｔａｌｋフラグを設定しない。通信装置１−１は、ＡＣＫフレーム１１１の受信に伴い送信バッファ６−１から送信完了したデータを削除する。
【００７９】
次に、引き続きＴａｌｋｅｒである通信装置１−１は、Ｌｉｓｔｅｎｅｒである通信装置１−２に、シーケンス番号＃５、＃６の２つのＣＳＤＵを格納したＣＳＤＵフレーム１１３を送信する。このように、Ｔａｌｋｅｒは、ｔａｌｋフラグが設定されていないＡＣＫフレームを受信した場合、連続してＣＳＤＵフレームを送信することができる。
【００８０】
次いで、通信装置１−２は、ＣＳＤＵフレーム１１３に対する応答として、シーケンス番号＃６のＣＳＤＵまで受信したことを示すＡＣＫフレーム１１５を、通信装置１−１に送信する。このとき、送信バッファ６−２には送信すべきデータが存在しないため、通信装置１−２は、ＡＣＫフレーム１１５にｔａｌｋフラグを設定しない。通信装置１−１は、ＡＣＫフレーム１１５の受信に伴い送信バッファ６−１から送信完了したデータを削除する。
【００８１】
次に、通信装置１−１は、役割５−１がＴａｌｋｅｒであり、且つ送信バッファ６−１に送信すべきデータがないため、ＣＳＤＵフレームの代わりにＴｏｋｅｎフレーム１１７を送信する。
【００８２】
次いで、通信装置１−２は、Ｔｏｋｅｎフレーム１１７に対する応答として、ＡＣＫフレーム１１９を、通信装置１−１に送信する。このとき、送信バッファ６−２には送信すべきデータが存在しないため、通信装置１−２は、ＡＣＫフレーム１１９にｔａｌｋフラグを設定しない。なお、このとき通信装置１−１に送信すべきデータが発生したものとする。
【００８３】
次に、引き続きＴａｌｋｅｒである通信装置１−１は、Ｌｉｓｔｅｎｅｒである通信装置１−２に、シーケンス番号＃７、＃８の２つのＣＳＤＵを格納したＣＳＤＵフレーム１２１を送信する。
【００８４】
次いで、通信装置１−２は、ＣＳＤＵフレーム１２１に対する応答として、シーケンス番号＃８のＣＳＤＵまで受信したことを示すＡＣＫフレーム１２３を、通信装置１−１に送信する。このとき、送信バッファ６−２には送信すべきデータが存在しないため、通信装置１−２は、ＡＣＫフレーム１２３にｔａｌｋフラグを設定しない。通信装置１−１は、ＡＣＫフレーム１２３の受信に伴い送信バッファ６−１から送信完了したデータを削除する。
【００８５】
次に、通信装置１−１は、役割５−１がＴａｌｋｅｒであり、且つ送信バッファ６−１に送信すべきデータがないため、ＣＳＤＵフレームの代わりにＴｏｋｅｎフレーム１２５を送信する。なお、このとき通信装置１−２に送信すべきデータが発生したものとする。
【００８６】
次いで、通信装置１−２は、Ｔｏｋｅｎフレーム１２５に対する応答として、ＡＣＫフレーム１２７を、通信装置１−１に送信する。このとき、送信バッファ６−２には送信すべきデータが存在するため、通信装置１−２は、ＡＣＫフレーム１２７にｔａｌｋフラグを設定する。これにより、通信装置１−２は、役割５−２をＴａｌｋｅｒに変更する。また、ｔａｌｋフラグが設定されたＡＣＫフレーム１２７を受信した通信装置１−１は、役割５−１をＬｉｓｔｅｎｅｒに変更する。
【００８７】
次に、Ｔａｌｋｅｒとなった通信装置１−２は、Ｌｉｓｔｅｎｅｒとなった通信装置１−１に、シーケンス番号＃１０７、＃１０８の２つのＣＳＤＵを格納したＣＳＤＵフレーム１２９を送信する。
【００８８】
次いで、通信装置１−１は、ＣＳＤＵフレーム１２９に対する応答として、シーケンス番号＃１０８のＣＳＤＵまで受信したことを示すＡＣＫフレーム１３１を、通信装置１−２に送信する。このとき、送信バッファ６−１には送信すべきデータが存在しないため、通信装置１−１は、ＡＣＫフレーム１３１にｔａｌｋフラグを設定しない。通信装置１−２は、ＡＣＫフレーム１３１の受信に伴い送信バッファ６−２から送信完了したデータを削除する。
【００８９】
次に、通信装置１−２は、役割５−２がＴａｌｋｅｒであり、且つ送信バッファ６−２に送信すべきデータがないため、ＣＳＤＵフレームの代わりにＴｏｋｅｎフレーム１３３を送信する。
【００９０】
次いで、通信装置１−１は、Ｔｏｋｅｎフレーム１３３に対する応答として、ＡＣＫフレーム１３５を、通信装置１−２に送信する。このとき、送信バッファ６−１には送信すべきデータが存在しないため、通信装置１−１は、ＡＣＫフレーム１３５にｔａｌｋフラグを設定しない。
【００９１】
以上、送信権調停動作の一例を説明した。続いて、図８を参照して上記説明した送信権調停動作におけるフレーム間スペースについて、図９を参照して説明する。
【００９２】
図９は、第１の実施形態に係る送信権調停動作の一例を示す図である。図９に示すように、通信装置１−１と通信装置１−２との接続確立後のフレーム間スペースは、すべてＳＩＦＳとなる。つまり、通信装置１−１、１−２は、イニシエータであるかレスポンダであるかにかかわらず、またＴａｌｋｅｒであるかＬｉｓｔｅｎｅｒであるかにかかわらず、同一のフレーム間スペースを用いてフレームを送信する。
【００９３】
ここで、図３および表１を参照して上記説明したように、比較方式のＴｒａｎｓｆｅｒＪｅｔにおいては、レスポンダのフレーム間スペースは、イニシエータのフレーム間スペースと比較して、Ｔｂｓｔだけ長い間隔であった。このため、レスポンダからデータ送信する場合、イニシエータからデータ送信する場合と比較して、長い時間を要する。この点、提案方式では、図９に示したようにフレーム間スペースを一律ＳＩＦＳとするため、レスポンダからデータ送信する場合の送信時間を削減して、イニシエータからデータ送信する場合と送信速度を同一にすることができる。
【００９４】
以上、送信権調停の動作の一例を説明した。
【００９５】
［２−３．極短時間のスリープ］
本実施形態に係る通信システムは、ＣＳＤＵフレームによるデータ通信が行われていない間、極短時間のスリープを行うことにより、消費電力の低減および応答の高速化を実現する。具体的には、ＴａｌｋｅｒがＴｏｋｅｎフレームにスリープ時間を設定してＬｉｓｔｅｎｅｒに通知する。Ｔｏｋｅｎフレームによりスリープ時間の通知を受けたＬｉｓｔｅｎｅｒは、Ｔｏｋｅｎフレームに対するＡＣＫフレームを送信後に、通知された時間分スリープ動作を行う。また、スリープ時間を設定したＴｏｋｅｎフレームを送信したＴａｌｋｅｒは、ＬｉｓｔｅｎｅｒからのＡＣＫフレームを受信後に、通知した時間分スリープ動作を行う。
【００９６】
本実施形態に係る通信装置１は、Ｔｏｋｅｎフレームのフレームボディ（Ｆｒａｍｅ  Ｂｏｄｙ）におけるＬｉＣＣ  Ｉｎｆｏｒｍａｎｔｉｏｎフィールドを用いて、スリープ時間を通知する。以下、表３に、Ｔｏｋｅｎフレームにおけるフレームボディの構成例を示す。
【００９７】
【表３】
0006468190.tif 000004
【００９８】
表３に示すように、ＬｉＣＣ  Ｉｎｆｏｍａｔｉｏｎの３１バイト目のＳｌｅｅｐ  ｐｅｒｉｏｄに、スリープ時間が設定される。以下、表４に、Ｓｌｅｅｐ  ｐｅｒｉｏｄの具体的な設定例を示す。
【００９９】
【表４】
0006468190.tif 000005
【０１００】
以上、Ｔｏｋｅｎフレームにおけるフレームボディの構成例を説明した。
【０１０１】
通信部４がＴｏｋｅｎフレームに表４に示したスリープ時間を示す情報Ｓｌｅｅｐ  ｐｅｒｉｏｄを設定して相手装置に送信することで、通信装置１は、Ｔｏｋｅｎフレームに対するＡＣＫフレーム受信後に、スリープ時間が経過するまで通信を休止する。また、相手装置は、表４に示したＳｌｅｅｐ  Ｐｅｒｉｏｄを設定されたＴｏｋｅｎフレームを受信した場合、ＡＣＫフレーム送信後Ｓｌｅｅｐ  Ｐｅｒｉｏｄが示す時間だけ通信を休止する。なお、スリープ時間が設定されたＴｏｋｅｎフレームに対して、ｔａｌｋフラグを設定したＡＣＫフレームが送信された場合、通信システムはスリープ動作をキャンセルしてもよい。
【０１０２】
ここで、Ｔａｌｋｅｒである通信装置１による、スリープ時間の設定方法、およびスリープ時間通知のタイミングは多様に考えられる。そこで、スリープ時間の設定方法、およびスリープ時間通知のタイミングについて、具体的に説明する。
【０１０３】
通信装置１は、任意のスリープ時間を設定し得る。消費電力を抑制するためには、可能な限り長い時間を設定することが望ましい。上位層のアプリケーション（図２におけるアプリケーション４０）が想定する応答時間が既知の場合、通信装置１は、上位層が想定する応答時間以下の時間をスリープ時間として設定する。なぜならば、上位層のアプリケーションが想定する応答時間以上スリープ動作を行った場合、アプリケーションでタイムアウトなどが発生してしまう可能性があるためである。一方で、上位層のアプリケーションが想定する応答時間が未知の場合、通信装置１は、スリープ時間を極短い時間に設定すべきである。
【０１０４】
また、通信装置１は、任意のタイミングでスリープ時間を相手装置に通知することができる。ここでは、一例として２つの通知タイミングを説明する。
【０１０５】
第１の通知タイミングは、Ｔｏｋｅｎフレームを所定回数送信したタイミングである。具体的には、通信装置１は、ＴｏｋｅｎフレームをＮ回送信後、スリープ時間を設定したＴｏｋｅｎフレームを送信する。これにより、通信システムは、上位層のアプリケーションによるデータの送受信が所定時間以上途切れた場合に、スリープ動作を行うことができる。
【０１０６】
第２の通知タイミングは、Ｔｏｋｅｎフレームを送信するすべてのタイミングである。具体的には、通信装置１は、Ｔｏｋｅｎフレームに常にスリープ時間を設定する。これにより、通信システムは、上位層のアプリケーションによるデータの送受信が少しでも途切れた場合に、スリープ動作を行うことができる。なお、アプリケーションによるデータの送受信がどの程度の期間途切れるかが未知であってもスリープ動作を行うため、スリープ時間は極短い時間に設定すべきである。
【０１０７】
このように、本実施形態に係る通信システムは、ＣＳＤＵフレームによるデータ通信が行われていない間、Ｔｏｋｅｎフレームを用いた極短時間のスリープ動作を実現して、消費電力を削減することができる。さらに、比較方式でのスリープ時間の最小値は５ｍＳｅｃ（ミリ秒）であるところ、提案方式では表４に示したように数ｕＳｅｃ（マイクロ秒）オーダーでのスリープ動作を実現可能である。よって、本実施形態に係る通信システムは、データ送信要求からスリープ解除、データ送信開始までの遅延時間を短縮することができ、応答性を向上させることができる。
【０１０８】
以上、通信装置１によるスリープ時間の設定方法、およびスリープ時間通知のタイミングについて説明した。続いて、図１０を参照して、本実施形態に係る通信システムによるスリープ動作の一例を説明する。
【０１０９】
図１０は、第１の実施形態に係るスリープ動作の一例を示す図である。図１０では、Ｔｏｋｅｎフレームを１回送信後、即ち２回目のＴｏｋｅｎフレームによりスリープ時間を通知して、１００ｕＳｅｃのスリープ動作を行う例を示している。
【０１１０】
図１０に示すように、まず、Ｔａｌｋｅｒである通信装置１−１は、Ｌｉｓｔｅｎｅｒである通信装置１−２に、ＣＳＤＵフレーム２０１を送信する。
【０１１１】
次いで、通信装置１−２は、ＣＳＤＵフレーム２０１を受信してからＳＩＦＳ経過後、ＡＣＫフレーム２０３を通信装置１−１に送信する。
【０１１２】
次に、通信装置１−１は、ＡＣＫフレーム２０３を受信してからＳＩＦＳ経過後、１回目のＴｏｋｅｎフレーム２０５を通信装置１−２に送信する。
【０１１３】
次いで、通信装置１−２は、Ｔｏｋｅｎフレーム２０５を受信してからＳＩＦＳ経過後、ＡＣＫフレーム２０７を通信装置１−１に送信する。
【０１１４】
そして、通信装置１−１は、ＡＣＫフレーム２０７を受信してからＳＩＦＳ経過後、２回目のＴｏｋｅｎフレーム２０９を通信装置１−２に送信する。このとき、通信装置１−１は、Ｔｏｋｅｎフレームの送信が２回目であるため、ＴｏｋｅｎフレームのフレームボディにおけるＬｉＣＣ  ＩｎｆｏｒｍａｎｔｉｏｎフィールドのＳｌｅｅｐ  ｐｅｒｉｏｄに、スリープ時間として１００ｕＳｅｃを設定する。
【０１１５】
次に、通信装置１−２は、Ｔｏｋｅｎフレーム２０９を受信してからＳＩＦＳ経過後、ＡＣＫフレーム２１１を通信装置１−１に送信する。
【０１１６】
そして、ＡＣＫフレーム２１１を受信した通信装置１−１は、Ｔｏｋｅｎフレーム２０９において通知したスリープ時間１００ｕＳｅｃの分、スリープ動作を行う。また、ＡＣＫフレーム２１１を送信した通信装置１−２は、Ｔｏｋｅｎフレーム２０９において通知されたスリープ時間１００ｕＳｅｃの分、スリープ動作を行う。
【０１１７】
１００ｕＳｅｃ経過後、通信装置１−１は、スリープ動作から復帰して、１回目のＴｏｋｅｎフレーム２１３を通信装置１−２に送信する。
【０１１８】
次いで、通信装置１−２は、Ｔｏｋｅｎフレーム２１３を受信してからＳＩＦＳ経過後、ＡＣＫフレーム２１５を通信装置１−１に送信する。
【０１１９】
そして、通信装置１−１は、ＡＣＫフレーム２１５を受信してからＳＩＦＳ経過後、２回目のＴｏｋｅｎフレームとして、Ｓｌｅｅｐ  ｐｅｒｉｏｄに１００ｕＳｅｃを設定したＴｏｋｅｎフレーム２１７を通信装置１−２に送信する。
【０１２０】
次に、通信装置１−２は、Ｔｏｋｅｎフレーム２１７を受信してからＳＩＦＳ経過後、ｔａｌｋフラグを設定したＡＣＫフレーム２１９を通信装置１−１に送信する。これにより、通信装置１−２は、スリープ動作をキャンセルすることができる。
【０１２１】
次いで、通信装置１−２は、ＡＣＫフレーム２１９を送信してからＳＩＦＳ経過後、ＣＳＤＵフレーム２２１を送信する。
【０１２２】
以上、本実施形態に係る通信システムによるスリープ動作の一例を説明した。続いて、図１１を参照して、本実施形態に係る通信装置１の動作を説明する。
【０１２３】
［２−４．動作処理］
図１１は、第１の実施形態に係る通信装置１の動作を示すフローチャートである。図１１に示すように、まず、ステップＳ１０２で、通信装置１は、自身の役割がＴａｌｋｅｒであるかＬｉｓｔｅｎｅｒであるかを判定する。詳しくは、通信開始時においては、制御部２は、イニシエータである場合にＴａｌｋｅｒであると判定し、レスポンダである場合にＬｉｓｔｅｎｅｒであると判定する。その後は、制御部２は、後述のステップＳ１１４、Ｓ１１６、Ｓ１２６、Ｓ１２８における設定を参照して役割を判定する。
【０１２４】
通信装置１の役割がＴａｌｋｅｒであると判定された場合（Ｓ１０２／Ｔａｌｋｅｒ）、ステップＳ１０４で、通信装置１は、送信するデータがあるか否かを判定する。詳しくは、制御部２は、送信バッファに送信すべきデータが存在するか否かに基づいて、送信するデータが有るか否かを判定する。
【０１２５】
送信するデータがあると判定された場合（Ｓ１０４／ＹＥＳ）、ステップＳ１０６で、通信装置１は、ＣＳＤＵフレームを送信する。詳しくは、通信部４は、送信バッファに存在するデータをＣＳＤＵフレームに格納して、Ｌｉｓｔｅｎｅｒである相手装置に送信する。
【０１２６】
一方で、送信するデータがないと判定された場合（Ｓ１０４／ＮＯ）、ステップＳ１０８で、通信装置１は、Ｔｏｋｅｎフレームを送信する。詳しくは、通信部４は、サブＣＮＬヘッダのＡＣＫ  ｔｙｐｅをＩｍＡＣＫとし、フレームボディのＬｉＣＣを０ｘ０Ｂとした管理フレームを、Ｔｏｋｅｎフレームとして相手装置に送信する。
【０１２７】
次いで、ステップＳ１１０で、通信装置１は、ＡＣＫフレームを受信する。詳しくは、通信部４は、上記ステップＳ１０６で送信したＣＳＤＵフレームまたは上記ステップＳ１０８で送信したＴｏｋｅｎフレームの応答として、相手装置からＡＣＫフレームを受信する。
【０１２８】
次に、ステップＳ１１２で、通信装置１は、ＡＣＫフレームにｔａｌｋフラグが設定されているか否かを判定する。詳しくは、制御部２は、上記ステップＳ１１０で受信されたＡＣＫフレームのＲｅｓｅｒｖｅｄフィールドに、ｔａｌｋフラグが設定されているか否かを判定する。
【０１２９】
ｔａｌｋフラグが設定されていると判定された場合（Ｓ１１２／ＹＥＳ）、ステップＳ１１４で、通信装置１は、自らの役割をＬｉｓｔｅｎｅｒに設定する。詳しくは、切替部３は、通信装置１の役割をＴａｌｋｅｒからＬｉｓｔｅｎｅｒに切り替える。この後、処理は再度ステップＳ１０２に戻る。
【０１３０】
一方で、ｔａｌｋフラグが設定されていないと判定された場合（Ｓ１１２／ＮＯ）、ステップＳ１１６で、通信装置１は、自らの役割をＴａｌｋｅｒに設定する。詳しくは、切替部３は、通信装置１の役割をＴａｌｋｅｒのままにする。この後、処理は再度ステップＳ１０２に戻る。
【０１３１】
上記ステップＳ１０２において、通信装置１の役割がＬｉｓｔｅｎｅｒであると判定された場合（Ｓ１０２／Ｌｉｓｔｅｎｅｒ）、ステップＳ１１８で、通信装置１は、ＣＳＤＵフレームまたはＴｏｋｅｎフレームを受信する。詳しくは、通信部４は、Ｔａｌｋｅｒである相手装置から、ＣＳＤＵフレームまたはＴｏｋｅｎフレームを受信する。
【０１３２】
次いで、ステップＳ１２０で、通信装置１は、送信するデータがあるか否かを判定する。
【０１３３】
送信するデータがあると判定された場合（Ｓ１２０／ＹＥＳ）、ステップＳ１２２で、通信装置１は、ｔａｌｋフラグを設定してＡＣＫフレームを送信する。詳しくは、通信部４は、Ｒｅｓｅｒｖｅｄフィールドにｔａｌｋフラグを設定したＡＣＫフレームを、相手装置に送信する。そして、ステップＳ１２６で、通信装置１は、自らの役割をＴａｌｋｅｒに設定する。この後、処理は再度ステップＳ１０２に戻る。
【０１３４】
一方で、送信するデータがないと判定された場合（Ｓ１２０／ＮＯ）、ステップＳ１２４で、通信装置１は、ｔａｌｋフラグを設定せずにＡＣＫフレームを送信する。詳しくは、通信部４は、Ｒｅｓｅｒｖｅｄフィールドにｔａｌｋフラグを設定しないＡＣＫフレームを、相手装置に送信する。そして、ステップＳ１２８で、通信装置１は、自らの役割をＬｉｓｔｅｎｅｒに設定する。この後、処理は再度ステップＳ１０２に戻る。
【０１３５】
以上、本実施形態に係る通信装置１の動作を説明した。
【０１３６】
＜３．まとめ＞
以上説明したように、本実施形態に係る通信システムは、半二重通信路上での全二重通信に対応することが可能である。具体的には、本実施形態に係る通信システムは、ＴｒａｎｓｆｅｒＪｅｔ規格において、ＡＣＫフレームを用いた送信権の調停により、スループットを低下させることなく全二重通信を実現することができる。ここで、本実施形態に係る通信システムは、ＣＮＬ層での制御によって全二重通信を実現するため、ＣＮＬ層よりも上位層における送信権の調停は不要となる。このため、本実施形態に係る通信システムは、上位層の負荷軽減によってスループットの向上を実現することができる。
【０１３７】
また、本実施形態に係る通信システムは、Ｔｏｋｅｎフレームによる送信権の調停により、スループットに対して影響を与えることなく消費電力を削減し、フレーム衝突を回避することができる。さらに、本実施形態に係る通信システムは、極短時間のスリープ動作により、消費電力の低減および応答の高速化を実現することができる。
【０１３８】
以上、添付図面を参照しながら本開示の好適な実施形態について詳細に説明したが、本開示の技術的範囲はかかる例に限定されない。本開示の技術分野における通常の知識を有する者であれば、請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本開示の技術的範囲に属するものと了解される。
【０１３９】
例えば、上記実施形態では、通信装置１はＴｒａｎｓｆｅｒＪｅｔ規格に準じた近接無線通信を行うものとした、本技術はかかる例に限定されない。例えば、通信装置１は、Ｂｌｕｅｔｏｏｔｈ（登録商標）、Ｚｉｇｂｅｅ（登録商標）又はＵＷＢ（Ｕｌｔｒａ  Ｗｉｄｅ  Ｂａｎｄ）などにより外部機器と通信してもよい。
【０１４０】
また、情報処理装置に内蔵されるＣＰＵ、ＲＯＭ及びＲＡＭ等のハードウェアに、上記通信装置の各構成と同等の機能を発揮させるためのコンピュータプログラムも作成可能である。また、当該コンピュータプログラムを記録した記録媒体も提供される。
【０１４１】
また、本明細書に記載された効果は、あくまで説明的または例示的なものであって限定的ではない。つまり、本開示に係る技術は、上記の効果とともに、または上記の効果に代えて、本明細書の記載から当業者には明らかな他の効果を奏しうる。
【０１４２】
なお、以下のような構成も本開示の技術的範囲に属する。
（１）
他の通信装置と送信側または受信側のいずれでデータ通信するかを切り替える切替部と、
前記送信側の場合は前記他の通信装置に送信データを送信して応答を受信し、前記受信側の場合は前記他の通信装置から受信データを受信して応答を送信する通信部と、
を備え、
前記切替部は、前記通信部により受信された前記応答に切替指示が含まれる場合、前記送信側から前記受信側に切り替える、通信装置。
（２）
前記通信部は、近接無線通信により前記他の通信装置と通信する、前記（１）に記載の通信装置。
（３）
前記通信部は、前記送信データの代わりに送信権調停フレームを前記他の通信装置に送信して前記応答を受信する、前記（１）または（２）に記載の通信装置。
（４）
前記通信部は、前記通信装置が送信側であり、且つ送信すべきデータが無い場合、前記送信権調停フレームを前記他の通信装置に送信する、前記（３）に記載の通信装置。
（５）
前記通信部は、前記切替指示を含む前記応答を前記他の通信装置に送信する、前記（１）〜（４）のいずれか一項に記載の通信装置。
（６）
前記切替部は、前記通信装置が受信側であり、且つ送信すべきデータが有る場合、受信側から送信側に切り替え、
前記通信部は、前記切替指示を含む前記応答を送信後、前記送信データを前記他の通信装置に送信する、前記（５）に記載の通信装置。
（７）
前記通信部は、前記送信権調停フレームにスリープ時間を示す情報を設定して前記他の通信装置に送信し、前記応答を受信後に前記スリープ時間が経過するまで通信を休止する、前記（３）または前記（３）を引用する前記（４）〜（６）のいずれか一項に記載の通信装置。
（８）
前記通信装置は、レスポンダまたはイニシエータのいずれかであり、
前記通信部は、前記通信装置がレスポンダであるかイニシエータであるかにかかわらず、同一のフレーム間スペースを用いて前記送信データを送信する、前記（１）〜（７）のいずれか一項に記載の通信装置。
（９）
送信側でデータ通信する第１の通信装置と受信側でデータ通信する第２の通信装置とを備え、
前記第１の通信装置は、
前記送信側から前記受信側に切り替える第１の切替部と、
前記第２の通信装置に送信データを送信して応答を受信する第１の通信部と、
を有し、
前記第２の通信装置は、
前記受信側から前記送信側に切り替える第２の切替部と、
前記第１の通信装置から前記送信データを受信して前記応答を送信する第２の通信部と、
を有し、
前記第２の通信部により切替指示を含めた前記応答が送信される場合、前記第２の切替部は前記受信側から前記送信側に切り替え、前記第１の通信部により当該応答が受信された場合、前記第１の切替部は前記送信側から前記受信側に切り替える、通信システム。
（１０）
他の通信装置と送信側または受信側のいずれでデータ通信するかを切り替えることと、
前記送信側の場合は前記他の通信装置に送信データを送信して応答を受信し、前記受信側の場合は前記他の通信装置から受信データを受信して応答を送信することと、
受信された前記応答に切替指示が含まれる場合、前記送信側から前記受信側に切り替えることと、
を備える通信方法。
【符号の説明】
【０１４３】
１、１−１、１−２    通信装置
２    制御部
３    切替部
４    通信部
５−１、５−２    役割
６−１、６−２    送信バッファ
１０    ＰＨＹ層
２０    ＣＮＬ層
３０    ＰＣＬ層
４０    アプリケーション
【図１】
0006468190.tif 000006
【図２】
0006468190.tif 000007
【図３】
0006468190.tif 000008
【図４】
0006468190.tif 000009
【図５】
0006468190.tif 000010
【図６】
0006468190.tif 000011
【図７】
0006468190.tif 000012
【図８】
0006468190.tif 000013
【図９】
0006468190.tif 000014
【図１０】
0006468190.tif 000015
【図１１】
0006468190.tif 000016